Difference between revisions of "Simulink Tester for T-VEC"

From T-VEC Wiki
Jump to: navigation, search
 
(Test Driver Generation)
 
Line 13: Line 13:
 
* Statement Coverage
 
* Statement Coverage
 
* Interface Coverage
 
* Interface Coverage
 +
 +
See [[Simulink/T-VEC Examples|Simulink/T-VEC Examples]] for details.
 +
 +
There are potential [[Simulink Tester Issues|limitations, usage issues, and guidelines]] associated with the integration of  Simulink/Stateflow with T-VEC.
 +
 +
==Recent Changes==
 +
<p>
 +
<b>T-VEC Tester for Simulink and Stateflow 4.5.0 is now generally available.</b>
 +
</p>
 +
<p>
 +
New and improved features in the Simulink Tester include:<ul><li>Improvements in the support of the following Simulink blocks - matrix concatenation, if, relay, sum, gain, product, lookup tables, data type conversion, initial condition, for,
 +
multiport switch, subsystem, and discrete time integrator blocks.</li>
 +
<li>Stateflow chart and truth table support has been enhanced.</li>
 +
<li>Additional checks warn of model problems or issues detected during translation</li>
 +
<li>Improved Simulink simulator test driver support in default schema.</li>
 +
<li>Improved C/C++ test driver support in default schema.</li>
 +
<li>Enhanced Embedded Matlab (EML) support</li>
 +
<li>Corrected issues with default support of Matlab R14 SP2</li>
 +
<li>Sl2tvec GUI now provides explicit indications of the inline vs atomic function status of each subsystem. All Simulink subsystems that are non-atomic, or atomic-auto, or atomic-inline will be indicated as "inlined into Parent".</li>
 +
</ul>
 +
 +
Please see the [https://www.t-vec.com/support/secure/readme.php?ID=147 Release Notes] for more details on the changes in this release.
 +
</p>
 +
 +
==Design Model==
 +
The [http://www.mathworks.com Mathworks' Simulink and Stateflow] allow users to develop behavioral specification used as basis of for simulation or code generation, and more. When used for code generation, the models represents "what’s in the box."
 +
 +
===Hybrid Model===
 +
Simulink was originally used for control system modeling, but with the addition of Stateflow and other features, it now provides hybrid modeling support for integrating control system and state machine models.
  
 
==Model Analysis==
 
==Model Analysis==
Line 35: Line 64:
  
 
Comprehensive testing is only feasible with a bottom up approach that fundamentally requires both unit and integration level testing support. When automatically generating test vectors for every condition and decision in a system, only the lowest level subsystems of the system can be tested in isolation. All higher-level subsystems must be tested in the context of the lower level subsystems on which they depend. Otherwise, there may be paths or threads in the higher-level subsystems that are not supported by the lower levels. This is especially true when multiple subsystems are related and changes could result in feature interaction problems. Some test tools generate tests based on the premise that unit testing a subsystem can ignore or stub out all subsystems on which it depends. This is a fundamentally incorrect and dangerous assumption.
 
Comprehensive testing is only feasible with a bottom up approach that fundamentally requires both unit and integration level testing support. When automatically generating test vectors for every condition and decision in a system, only the lowest level subsystems of the system can be tested in isolation. All higher-level subsystems must be tested in the context of the lower level subsystems on which they depend. Otherwise, there may be paths or threads in the higher-level subsystems that are not supported by the lower levels. This is especially true when multiple subsystems are related and changes could result in feature interaction problems. Some test tools generate tests based on the premise that unit testing a subsystem can ignore or stub out all subsystems on which it depends. This is a fundamentally incorrect and dangerous assumption.
 +
 +
==Test Sequence Vectors==
 +
 +
==Assertions==
 +
 +
==Test Driver Generation==
 +
 +
The Simulink Tester provide test driver schemas for the ERT and GRT code generators supported by the Mathworks RTW, as well as the Matlab Simulator. Howevever, target execution environments have differences, and the tools provide a general purpose test driver template/schema language for describing a generic test driver that can then be instantiated with test vector information by running the test driver generator. An organization can create any number of test driver scripts/programs that are targeted to specific target environments. Schemas can be created from scratch or tailored from schemas provided with the tool installation.
 +
 +
These are located in the install area, normally in the directory
 +
 +
  C:\t-vec\translators\sl2tvec\test_drivers
 +
 +
In the case of LDRA's TBRun environment, the Simulink Tester for T-VEC installation provides a few default test driver schemas that are designed to produce .tcf  files.
 +
 +
There are other schema examples with the TTM training examples that are normally located in the directory
 +
 +
  C:\t-vec\examples\ttm\course\exercise_answers
 +
 +
Specific differences in build environments require customization of one of these general purpose schema. To illustrate, one of these example schemas (testbed_tcf_ghs.sch) was created specifically for a Greenhills Compiler environment. The only other task is configuring the object mapping files that are descriptions of how to relate model names with target code names. Some of the object mapping information is automatically set up by the translator, but some of it needs to be identified and added to the mapping information. In a Simulink environment, only some of the necessary information is available to the translator to help in automatically creating the necessary object mappings for the ERT or GRT code generators. Simulink/Stateflow does not provide any form of API for querying this kind of information, but some of it is extracted by executing functions against the RTW. If a different coder is used, or a customization of the default GRT or ERT coder is used, this mapping information needs to be completed by the user.
 +
 +
There is information in the manuals and user's guide about the test driver generator mechanism, but it is also covered in training classes or workshops.

Latest revision as of 10:25, 21 May 2010