The referenced schema produces a .tcf file in the test_drivers directory. If the particular subsystem is related to a state chart, then those dependent subsystems are include in the parent's .tcf file. This allows one file to be executed for verification of test coverage. The reference to a dependent subsystem is defined by the user-defined variable dependencies as shown in the following example.

+

+

<dependencies> = '__triggerRisingB,signal_light__sf__a';

+

+

===Execute LDRA===

+

The LDRA tool provides a significant number of features. This description provides the following minimal steps to execute the generated LDRA script .tcf file against the generated code.

+

+

====Load Code File====

+

The code is generated the auto generated code file that is the target of the test.

+

+

[[Image:LDRA_Select_File.png‎|Select the file to be tested]]

+

+

====Start TBrun and Load New Test Sequence

+

This is where the generated .tcf file is loaded into TBrun. If you copied the .tcf file to the code directory. Load that .tcf file as the test sequence. Otherwise load it from the test drivers directory where it was produced by VGS.

+

+

Execute the Run Drivers command or execute the commands separately:

+

*Generate Driver

+

*Build Driver

+

+

If successful

+

*Execute Driver

+

*Process Driver Output

+

+

Note: during the Generate Driver process, you might see the following LDRA Question - Answer None:

Simulink Tester Test Driver Issues

There are some Test Driver Generation issues related to determining object mapping information and parameter ordering, and this can limit fully automated test driver generation for RTW auto-generated code.

Function Parameter Ordering

In the release Simulink/Stateflow 2007a there is additional information now provided to support additional automated test driver generation for both Simulink and Stateflow. Support for these capabilities will be incorporated into upcoming releases.

LDRA Integration for Model References

The Simulink/Stateflow code generation process for model references is different from that of non-model reference code. The follow briefly describes how to use capabilities in T-VEC Tester for Simulink and Stateflow 4.1.0.

An easy way to use the program is to put it in the c:\t-vec\bin directory. This is usually defined as one of your path variables. Then use the VGS Toolbox under Tools | Toolbox and set up as shown below:

Simply select the subsytem from the VGS Project window and then execute the get_rtw_types from the Tools menu. It will update the object mappings. Do this for each subsystem that needs to have the object mappings updated.

What the get_rtw_types program does

This is a perl program that takes two parameters:

Project Directory

Subsystem Name

It then updates the object mapping associated with that subsystem by looking through the .h file associated with the subsystem. The object mapping provides the name of the code in the user-defined variable called: <simulinkSubsystemName>. It updates two key user defined variable:

Build Test Drivers

The referenced schema produces a .tcf file in the test_drivers directory. If the particular subsystem is related to a state chart, then those dependent subsystems are include in the parent's .tcf file. This allows one file to be executed for verification of test coverage. The reference to a dependent subsystem is defined by the user-defined variable dependencies as shown in the following example.

<dependencies> = '__triggerRisingB,signal_light__sf__a';

Execute LDRA

The LDRA tool provides a significant number of features. This description provides the following minimal steps to execute the generated LDRA script .tcf file against the generated code.

Load Code File

The code is generated the auto generated code file that is the target of the test.

====Start TBrun and Load New Test Sequence
This is where the generated .tcf file is loaded into TBrun. If you copied the .tcf file to the code directory. Load that .tcf file as the test sequence. Otherwise load it from the test drivers directory where it was produced by VGS.

Execute the Run Drivers command or execute the commands separately:

Generate Driver

Build Driver

If successful

Execute Driver

Process Driver Output

Note: during the Generate Driver process, you might see the following LDRA Question - Answer None: