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

From T-VEC Wiki
Jump to: navigation, search
(Recent Changes)
(Test Driver Generation)
 
(One intermediate revision by one user not shown)

Latest revision as of 11:25, 21 May 2010

Simulink Tester for T-VEC

The Simulink Tester for T-VEC integrates Simulink/Stateflow the the T-VEC VGS to automate much of the testing process by analyzing the Simulink model to determine the best test cases for validating the model and testing implementations of the model. When used with the Real-Time Workshop™ Generic and Embedded Coders, the T-VEC Tester generates test drivers (harnesses) for executing the test vectors against auto-generated source code. Comprehensive Test Suites

Test generation for Simulink models produces unit, integration and system level test vectors and test drivers necessary to fully verify implementations of models. The test selection process produces the set of test vectors most effective in revealing both decision and computational errors in logical, integer and floating-point domains.

VGS generates test vectors for every path through every atomic subsystem. Each test vector is determined from the constraints in the subsystem under test and the constraints of any lower-level subsystems it references. These tests produce

  • Structured Path Coverage
  • Decision (Branch) Coverage
  • Modified Condition / Decision Coverage
  • Statement Coverage
  • Interface Coverage

See Simulink/T-VEC Examples for details.

There are potential limitations, usage issues, and guidelines associated with the integration of Simulink/Stateflow with T-VEC.

Contents

Recent Changes

T-VEC Tester for Simulink and Stateflow 4.5.0 is now generally available.

New and improved features in the Simulink Tester include:

  • 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.
  • Stateflow chart and truth table support has been enhanced.
  • Additional checks warn of model problems or issues detected during translation
  • Improved Simulink simulator test driver support in default schema.
  • Improved C/C++ test driver support in default schema.
  • Enhanced Embedded Matlab (EML) support
  • Corrected issues with default support of Matlab R14 SP2
  • 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".

Please see the Release Notes for more details on the changes in this release.

Design Model

The 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

The analysis performed prior to test vector generation identifies model errors, such as contradictions or feature interaction problems. These model errors can result in dead code or other undesirable effects.

Complete Verification Artifacts

The T-VEC Tester produces a complete set of artifacts for verifying Simulink models

  • Model Analysis Report identifies model errors
  • Test Vectors
    • Input values
    • Expected output values
    • Traceability from each test to the Simulink model
  • Test Coverage Report
  • Test Harnesses for GRT and ERT code generators
  • Test results report that details test successes and failures
  • Makefiles to fully automate the process

Scalable, Hierarchical Test Generation

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.