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.

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:

  1. Source blocks that can generate signals with the compiled attributes are configured to do so.

  2. 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 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',...

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 harnesses configuration for bus inputs and outputs depends on the bus connection ability of the source or sink blocks:

  1. Sources and sinks that can accept a bus signal are directly connected to the component without modification.

  2. If a source cannot output a bus signal, bus signals are automatically constructed from individual bus elements in the signal conversion subsystem.

  3. If a sink cannot accept a bus signal, bus signal elements are expanded from the bus signal in the signal conversion subsystem.

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 SelectionSource Block for String Inputs
Signal BuilderGround
Signal EditorGround
From WorkspaceGround
From FileGround
Test SequenceGround

String Constant (individual string input)

Ground (bus containing string)


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 SelectionSink Block for String Outputs
To WorkspaceTerminator
To FileTerminator

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.

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 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.

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:

  1. Copies configuration parameter settings from the main model into the test harness.

  2. Copies required parameter definitions from the main model workspace into the test harness model workspace.

  3. Copies data dictionary settings from the main model into the test harness.

  4. 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.

See Also