Difference between revisions of "Simulink Tester Issues"

From T-VEC Wiki
Jump to: navigation, search
(Model Coverage vs. Code Coverage)
Line 3: Line 3:
 
==Guidance==
 
==Guidance==
 
===Test Vector Generation Failures===
 
===Test Vector Generation Failures===
If test vector failures occur there are some general guidelines that apply any type of model (TTM or Simulink). See [[VGS Issues and Guidelines|VGS Issues and Guidelines]].
+
If test vector failures occur there are some general guidelines that apply to any type of model (TTM or Simulink). See [[VGS Issues and Guidelines|VGS Issues and Guidelines]].
  
 
==Limitations==
 
==Limitations==
Line 30: Line 30:
  
 
===Test Vector Generation Failures===
 
===Test Vector Generation Failures===
T-VEC VGS analysis is exhaustive in the sense that for every [http://www.t-vec.com/wiki/index.php/Modeling#Model_Representation DCP] throughout the hierarchy of systems it is model-checked, and a test vector is them produced. Most test vector generation failures results from model defects where the constraints of the DCP are not satisfiable throughout the hierarchy of DCPs of the subsystems.
+
T-VEC VGS analysis is exhaustive in the sense that for every [[Modeling#Model_Representation|DCP]] throughout the hierarchy of systems is model-checked, and a test vector is them produced. Most test vector generation failures results from model defects where the constraints of the DCP are not satisfiable throughout the hierarchy of DCPs of the subsystems.
  
However, there are possible situations where test vector generation fails when it is possible to find vectors, for example when signal domains are left to their defaults. There are [http://www.t-vec.com/wiki/index.php/Simulink/T-VEC_Examples default settings for ranges values], but these may not be adequate for the application.
+
However, there are possible situations where test vector generation fails when it is possible to find vectors, for example when signal domains are left to their defaults. There are [[Simulink/T-VEC_Examples|default settings for ranges values]], but these may not be adequate for the application.
  
 
T-VEC does cover a large percentage of models that use standard blocks (see View | Library... from Simulink Tester GUI for the supported blocks), however, there are other situations where T-VEC may not produce vectors, for example
 
T-VEC does cover a large percentage of models that use standard blocks (see View | Library... from Simulink Tester GUI for the supported blocks), however, there are other situations where T-VEC may not produce vectors, for example
Line 46: Line 46:
  
 
===Model Coverage vs. Code Coverage===
 
===Model Coverage vs. Code Coverage===
Test vector generation attempts to find test vectors for all of the paths (DCPs) in the model. Complete coverage means complete [http://www.t-vec.com/wiki/index.php/Model_Coverage model coverage], however, complete model coverage does not guarantee coverage of code (e.g., MCDC coverage), for example: code generators can put in code (e.g., safety code around square root function). The Simulink Testers provides mechanisms such as assertions and coverage predicates that can be used to produce additional tests to cover many possible situations. Tools such as LDRA TBrun is integrated with the Simulink Tester and can provide test [http://www.t-vec.com/wiki/index.php/Model_Coverage coverage measures] to support organizations that may need evidence to support FAA certification.
+
Test vector generation attempts to find test vectors for all of the paths (DCPs) in the model. Complete coverage means complete [[Model_Coverage|model coverage]], however, complete model coverage does not guarantee coverage of code (e.g., MC/DC coverage), for example: code generators can put in code for checking and handling exceptional conditions (e.g., safety code around square root function). The Simulink Testers provides mechanisms such as assertions and coverage predicates that can be used to produce additional tests to cover many possible situations. Tools such as LDRA TBrun is integrated with the Simulink Tester and can provide test [[Model_Coverage#Code Coverage|coverage measures]] to support organizations that may need evidence to support FAA certification.
  
 
===Test Sequence Vectors: State Variable Initialization===
 
===Test Sequence Vectors: State Variable Initialization===
Test Sequence Vectors are created by referencing the target subsystem multiple times.
+
Test Sequence Vectors (TSVs) are created by referencing the target subsystem multiple times.
Special T-VEC subsystems are created based on a configuration file supplied to the translator.
+
Special T-VEC subsystems are created based on a configuration file supplied to the translator. These TSV subsystems include one or more test sequences. Each test sequence
These TSV subsystems include one or more test sequences. Each test sequence
+
 
includes one or more references to the target subsystem (i.e., the number of sample times
 
includes one or more references to the target subsystem (i.e., the number of sample times
being tested). It also includes a set of the target subsystem’s inputs for each time that the
+
being tested). It includes also a set of the target subsystem’s inputs for each time that the
 
target subsystem is referenced. These input values have their respective subsystem reference
 
target subsystem is referenced. These input values have their respective subsystem reference
 
appended to their name. Therefore, if a subsystem has two inputs, inputA and inputB,
 
appended to their name. Therefore, if a subsystem has two inputs, inputA and inputB,
Line 64: Line 63:
 
[[Image:State_Variable_Inits.jpg|center|VGS Property: State Variable Inits]]
 
[[Image:State_Variable_Inits.jpg|center|VGS Property: State Variable Inits]]
  
The default is to generate vectors for both cases, 2 vectors per DCP when no state variables are available, but T-VEC produces 4 vectors when state variables are available.
+
The default is to generate vectors for both cases, 2 vectors per DCP when no state variables are available, and 4 test vectors when state variables are available.
  
 
===Test Driver Generation===
 
===Test Driver Generation===
 
There are some situations where the object mapping information that relates a signal name to an implementation name must be defined manually to support test driver generation. This is applicable to a few types of Simulink blocks and some Stateflow modeling constructs. There are cases where it is simply not possible to predict variable names, function parameter orders, etc. There is no API for determining the choices made by the RTW to fully automate all aspects of test driver map file creation.  
 
There are some situations where the object mapping information that relates a signal name to an implementation name must be defined manually to support test driver generation. This is applicable to a few types of Simulink blocks and some Stateflow modeling constructs. There are cases where it is simply not possible to predict variable names, function parameter orders, etc. There is no API for determining the choices made by the RTW to fully automate all aspects of test driver map file creation.  
  
There is a work around with the current schemas - all mapping descriptors are passed through a Perl function before going into the target file. The perl script parses in an external file that contains new replacement mapping information. The mapping can be either by the descriptor itself or the mapping key. If the perl script finds a match then it uses the replacement from the file.  This function can be extended directly through the Perl script.
+
There is a work around with the current schemas - all mapping descriptors are passed through a Perl function before going into the target file. The perl script parses in an external file that contains new replacement mapping information. The mapping can be defined with the descriptor or a mapping key. If the perl script finds a match then it uses the replacement from the file.  This function can be extended directly through the Perl script.

Revision as of 10:35, 26 February 2007