Test Harness Construction for Specific Model Elements

A test harness consists of one or more source blocks that drive the component under test, which drives one or more sink blocks. Test harness construction configures signal attributes, function calls, data stores, and execution semantics. When possible, the test harness matches signal attributes at the sources, sinks, and component interface. For more information on selecting sources and sinks, see Sources and Sinks.

Elements of a test harness

Signal Conversion

Signal conversion subsystems adapt the signal interface of the source and sink blocks to the graphical interface of the component. The graphical interface of the component includes input signals, output signals, and action, trigger, or enable inputs. The test harness compiles the main model to determine signal attributes:

Data type
Dimensions
Complexity

Signal attributes are adapted to the sources during harness construction in one of two ways:

Source blocks that can generate signals with the compiled attributes are configured to do so.
If a source block cannot generate signals with the compiled attributes, signal attribute blocks in the signal conversion subsystem adapt the output of the source blocks. Signal attribute blocks include Reshape, Rate Transition and Data Type Conversion blocks.

By default, signal conversion subsystems are locked from editing.

Function Calls

Function Call Drivers

If the component under test has function call inputs, a Test Sequence block, MATLAB Function block, or Stateflow^® chart source generates function call inputs to the component, even if you select a different source during harness creation. To override this behavior and connect function call inputs to your selected source type, create the test harness with the sltest.harness.create function, and set 'DriveFcnCallWithTestSequence' to false. For example:

sltest.harness.create('Model/FcnCallSubsystem','Source','From File',...
'DriveFcnCallWithTestSequence',false)

Function Call Outputs

Function call outputs of the component under test connect to Terminator blocks.

Physical Signal Connections

Components that accept or output physical signals are supported during harness construction, but sources and sinks are not generated. You can add physical modeling blocks to the test harness after construction.

Bus Signals

Test harness configuration for bus inputs and outputs depends on the bus connection ability of the source or sink blocks:

Sources and sinks that can accept a bus signal are directly connected to the component without modification.
If a source cannot output a bus signal, bus signals are automatically constructed from individual bus elements in the signal conversion subsystem.
If a sink cannot accept a bus signal, bus signal elements are expanded from the bus signal in the signal conversion subsystem. For a top-level model, subsystem, or model reference that receives or outputs a bus of messages, if you select a Scope block as the sink, the test harness adds a terminator instead of the Scope block because Scope blocks do not support multiple messages.

String Signals

If the component under test uses string data inputs, and your test harness source does not support string data, string inputs are connected to Ground blocks.

String Inputs

Harness Source Selection	Source Block for String Inputs
Inport	Inport
Signal Editor	Ground
From Workspace	Ground
From File	Ground
Test Sequence	Ground
Chart	Ground
Constant	String Constant (individual string input) Ground (bus containing string)
Ground	Ground

If the component under test uses string data outputs, and your test harness sink does not support string data, string outputs are connected to Terminator blocks.

String Outputs

Harness Sink Selection	Sink Block for String Outputs
Outport	Outport
Scope	Terminator
To Workspace	Terminator
To File	Terminator
Terminator	Terminator

Non-Graphical Connections

In addition to the graphical interface of a component, Simulink supports several non-graphical connections. Test harness construction also supports non-graphical connections.

Goto–From Connections

Goto-From block pairs that cross the component boundary are considered component inputs or outputs.

A From block without a corresponding Goto block in the component is considered a component input signal. The test harness includes a source block with a corresponding Goto block.
A Goto block without the corresponding From block in the component is considered a component output signal. The test harness includes a sink block with a corresponding From block.

Data Store Memory

Data Store Read and Data Store Write blocks require a complete data store definition in the test harness.

If a Data Store Read or Data Store Write block lacks a corresponding Data Store Memory block in the component, the test harness adds a Data Store Memory block.
For a component containing only Data Store Read blocks, the test harness adds a source block driving a Data Store Write block.
For a component containing only Data Store Write blocks, the test harness adds a Data Store Read block driving a sink block.
These blocks inside a referenced model can access data stored in a Data Store Memory block defined at a higher level in the model hierarchy: Data Store Read, Data Store Write, S-Function, MATLAB Function, MATLAB System, and Chart (Stateflow) blocks. To allow these blocks to access the data stored in the Data Store Memory block at a higher level in the model hierarchy:
- Place a Data Store Memory block inside the referenced model. For more information about supported locations of the Data Store Memory block, see Description in Data Store Memory.
- In the Data Store Memory block dialog box, select Data store reference.
- On the Signal Attributes tab, specify the Data type, Dimensions and Signal type. When you select Data store reference, these options are not available: Inherit for Data type, -1 for Dimensions and auto for Signal type.

If global data store memory read or write usage cannot be determined, then Data Store Read and Data Store Write blocks are not included in the test harness.

Simulink Function Definitions

If the component calls a Simulink Function that is not defined in the component, the test harness adds a stub Simulink Function block matching the function call signature.

Export Function Models

Test harnesses contain a function-call scheduler for components that use the export-function modeling style. The scheduler is a Test Sequence block, MATLAB Function block, or Stateflow chart that contains prototype calls to the functions in your model.

The scheduler Test Sequence block includes a test step containing:

A catalog of globally scoped Simulink Function blocks in the component.
A list of function-call triggers accessible at the component interface.

Harness construction honors periodic function-call triggers with appropriate decimation of the function-call event in the Test Sequence block, MATLAB Function block, or Stateflow chart.

Test harnesses include Initialize, Terminate, and Reset steps for models that contain Initialize, Terminate, and Reset event subsystems. You can include Initialize, Terminate, and Reset steps for other export-function models using the 'ScheduleInitTermReset' property of sltest.harness.create.

Execution Semantics

The execution behavior of a component depends on factors such as computed sample times, solver settings, model configuration, and parameter settings. Execution behavior also depends on run-time events such as function-call triggers and asynchronous events. To handle these execution semantics, test harness construction:

Copies configuration parameter settings from the main model into the test harness.
Copies required parameter definitions from the main model workspace into the test harness model workspace.
Copies data dictionary settings from the main model into the test harness if the harness owner is not a Subsystem Reference block, or if the harness owner is a Subsystem Reference block that does not have an attached data dictionary.
Honors a limited subset of sample time settings using explicit source block specifications and Rate Transition blocks.

Other factors, such as additional blocks in the harness and solver heuristics, can cause test harness execution to differ from the main model. The graphical and compiled interface of the component takes precedence over other execution semantics.

Sample Time Specification

Simulink^® supports an array of sample times, including types that are derived during model compilation. Test harness construction supports periodic discrete, continuous, and fixed-in-minor-step sample times with these considerations:

Source blocks that support the desired rate are configured to do so, and the signal conversion subsystem contains a Signal Specification block with the rate specification.
Test harness construction does not configure source blocks that cannot support the desired rate.
- If the desired rate is periodic discrete or fixed-in-minor-step, the test harness contains a Rate Transition block in the signal conversion subsystem.
- If the desired rate is continuous, the execution semantics are determined by the solver. The signal conversion subsystem does not contain a Rate Transition block.
Other sample time specifications are ignored during test harness construction. In those cases, solver settings determine execution behavior.