sltest.harness.create

Create test harness

Syntax

sltest.harness.create(harnessOwner)

sltest.harness.create(harnessOwner,Name,Value)

Description

sltest.harness.create(harnessOwner) creates a test harness for the model component harnessOwner, using default properties.

sltest.harness.create(harnessOwner,Name,Value) uses additional options specified by one or more Name,Value pair arguments.

Examples

Create Harness for a Model

Create harness for the f14 model. The harness is called sample_harness and has a Signal Editor block source and a scope sink.

f14;
sltest.harness.create('f14','Name','sample_harness','Source',...
'Signal Editor','Sink','Scope')

Create Harness for a Subsystem

Create a harness for the Controller subsystem of the f14 model.

f14;
sltest.harness.create('f14/Controller');

Create a Harness That Uses a Chart Scheduler

Create a harness that uses a Stateflow^® Chart as the test harness scheduler for the Controller subsystem of the f14 model.

f14;
sltest.harness.create('f14/Controller','SchedulerBlock','Chart');

Input Arguments

harnessOwner — Model or component

character vector | double

Model or component handle or path, specified as a character vector or double.

Example: 1.9500e+03

Example: 'model_name'

Example: 'model_name/Subsystem'

Data Types: double | char

Name-Value Pair Arguments

Specify optional comma-separated pairs of Name,Value arguments. Name is the argument name and Value is the corresponding value. Name must appear inside quotes. You can specify several name and value pair arguments in any order as Name1,Value1,...,NameN,ValueN.

Example: 'Name','controller_harness','Source','Signal Editor','Sink','To File' specifies a harness named controller_harness, with a signal editor block source and To File block sinks for the component under test.

'Name' — Harness name

character vector

The name for the harness you create, specified as the comma-separated pair consisting of 'Name' and a valid MATLAB file name.

Example: 'Name','harness_name'

Data Types: char

'Description' — Harness description

character vector

The harness description, specified as the comma-separated pair consisting of 'Description' and a character vector.

Example: 'Description','A test harness'

Data Types: char

'Source' — Component under test input

'Inport' (default) | 'Signal Editor' | 'From Workspace' | 'From File' | 'Test Sequence' | 'Signal Editor' | 'Chart' | 'None' | 'Custom'

The input to the component, specified as the comma-separated pair consisting of 'Source' and one of the possible source values.

Example: 'Source','Signal Editor'

Data Types: char

'CustomSourcePath' — Path to library block for custom source

character vector

For a custom source, the path to the library block to use as the source, specified as the comma-separated pair consisting of 'CustomSourcePath' and the path.

Example: 'CustomSourcePath','simulink/Sources/Sine Wave'

Data Types: char

'Sink' — Harness output

'Outport' (default) | 'Scope' | 'To Workspace' | 'To File' | 'Terminator' | 'None' | 'Custom'

The output of the component, specified as the comma-separated pair consisting of 'Sink' and one of the possible sink values.

If your test harness contains a To Workspace block, the block variable is not saved in the base workspace after the test finishes running. Upon test completion, the base workspace is restored to its original state.

Example: 'Sink','Scope'

Data Types: char

'CustomSinkPath' — Path to library block for custom sink

character vector

For a custom sink, the path to the library block to use as the sink, specified as the comma-separated pair consisting of 'CustomSinkPath' and the path.

Example: 'CustomSinkPath','simulink/Sinks/Display'

'SeparateAssessment' — Separate Test Assessment block

false (default) | true

Option to add a separate Test Assessment block to the test harness, specified as a comma-separated pair consisting of 'SeparateAssessment' and false or true.

Example: 'SeparateAssessment',true

Data Types: logical

'SynchronizationMode' — Specifies the synchronization behavior of the component under test

'SyncOnOpenAndClose' (default) | 'SyncOnOpen' | 'SyncOnPushRebuildOnly'

Option to specify when the component under test synchronizes the main model and the test harness. Subsystem model test harnesses are always synchronized with their underlying model.

• 'SyncOnOpenAndClose' rebuilds the component under test from the main model when the test harness opens, and pushes changes from the component under test to the main model when the test harness closes.

• 'SyncOnOpen' rebuilds the component under test from the main model when the test harness opens. It does not push changes from the component under test to the main model when the test harness closes.

• 'SyncOnPushRebuildOnly' rebuilds and pushes changes only when you manually initiate rebuild or push for the entire test harness. For more information, see Synchronize Changes Between Test Harness and Model.

Example: 'SynchronizationMode','SyncOnOpen'

Data Types: char

'CreateWithoutCompile' — Option to create harness without compiling main model

false (default) | true

Option to specify harness creation without compiling the main model, specified as a comma-separated pair consisting of 'CreateWithoutCompile' and false or true. This option is set to true for Subsystem model test harnesses.

false compiles the model and runs other operations to support the harness build. true creates the harness without model compilation.

Example: 'CreateWithoutCompile',false

Data Types: logical

'VerificationMode' — Option to use normal (model), software-in-the-loop (SIL), or processor-in-the-loop (PIL) block as component under test

'Normal' (default) | 'SIL' | 'PIL'

Option to specify what type of block to use in the test harness, specified as a comma-separated pair consisting of 'VerificationMode' and the type of block to use. SIL and PIL blocks require Simulink Coder. This option is set to normal for Subsystem models.

Example: 'VerificationMode','SIL'

Data Types: char

'ExistingBuildFolder' — Path to folder of existing generated code verified using SIL/PIL

string | character vector

Path to main build folder of existing generated code verified using SIL/PIL, specified as a string or character vector. If you specify a build folder, the existing code in that folder is used, which enables faster harness creation time. If you do not specify a build folder, the code is regenerated.

Example: 'ExistingBuildFolder','C:\TestMdl\SILHarness\Amplifier_ert_rtw'

Data Types: string | char

'RebuildOnOpen' — Sets the harness rebuild command to execute when the harness opens

false (default) | true

Option to have the harness rebuild when it opens, specified as the comma-separated pair consisting of 'UseDefaultName' and false or true.

Example: 'RebuildOnOpen',true

Data Types: logical

'RebuildModelData' — Sets configuration set and model workspace entries to be updated during the test harness rebuild

false (default) | true

Option to have the configuration set and model workspace entries updated during test harness rebuild, specified as the comma-separated pair consisting of 'RebuildModelData' and true or false. This option is set to true for Subsystem model test harnesses.

Example: 'RebuildModelData',true

Data Types: logical

'SaveExternally' — Test harnesses saved as separate SLX files

false (default) | true

Option to have each test harness saved as a separate SLX file, specified as the comma-separated pair consisting of 'SaveExternally' and true or false. A model cannot use both external and internal test harness storage. If a model already has test harnesses, a new test harness follows the storage type of the existing harnesses, which this option does not override. See Manage Test Harnesses.

Example: 'SaveExternally',true

Data Types: logical

'HarnessPath' — Path to external test harness file

character vector

If 'SaveExternally' is specified, you can specify a location for the external harness SLX file using a comma-separated pair consisting of 'HarnessPath' and a character vector..

Example: 'HarnessPath','C:\MATLAB\SafetyTests'

Data Types: char

'LogHarnessOutputs' — Log all harness output signals

false (default) | true

Log all harness output signals for the component under test, specified as false or true. When the value is true, all signals are logged, except for signals incompatible with logging. Signals are logged during test case execution and return test results. If an output signal does not have a name or a propagated name, it is assigned one in the harness using the format <component under test name>:<output port number>. To remove a signal from being logged, you can remove its badge manually.

Example: 'LogHarnessOutputs',true

Data Types: logical

'PostCreateCallback' — Harness customization after creation

character vector

Use a post create callback function to customize a test harness. The post create callback function executes after the harness is created. For more information, see Customize Test Harnesses.

Example: 'PostCreateCallback','HarnessCustomization'

Data Types: char

'PostRebuildCallback' — Harness customization after rebuild

character vector

Use a post rebuild callback function to customize a test harness. The post rebuild callback function executes after the harness rebuild. For more information, see Customize Test Harnesses.

Example: 'PostRebuildCallback','HarnessCustomization'

Data Types: char

'ScheduleInitTermReset' — Drive model initialize, reset, and terminate ports

false (default) | true

Option to drive model initialize, reset, and terminate ports with the chosen test harness source, specified as the comma-separated pair consisting of 'ScheduleInitTermReset' and false or true. This option only applies to harnesses created for a block diagram. This option is set to false for Subsystem models.

Example: 'ScheduleInitTermReset',true

Data Types: logical

'SchedulerBlock' — Include scheduler block for periodic signals and function calls

'Test Sequence' | 'MATLAB Function' | 'Chart' | 'None'

Option to include a scheduler block in the test harness, specified as the comma-separated pair consisting of 'SchedulerBlock' and the type of block to use. The block is included if the test harness is created for a model block diagram or a Model block and contains function calls or periodic event ports. To include no scheduler block and connect all ports to harness source blocks, use 'None' .

Example: 'SchedulerBlock','Test Sequence'

Example: 'SchedulerBlock','None'

Data Types: char

'AutoShapeInputs' — Match scalar and double value source to input signal dimension

false (default) | true

Option to shape scalar and double values to match the dimension of the input signals to the component under test, specified as the comma-separated pair consisting of 'AutoShapeInputs' and false or true. This option only applies to harnesses with Inport, Constant, Signal Editor, From Workspace, or From File blocks. This option is set to false for Subsystem models.

Example: 'AutoShapeInputs',true

Data Types: logical

'FunctionInterfaceName' — Name of reusable library subsystem function interface

string | character vector

Name of reusable library subsystem function interface, specified as a string or character vector. The test harness is created for the function interface of the reusable library subsystem.

Example: 'FunctionInterfaceName','double_RLS'

Data Types: string | char

Compatibility Considerations

DriveFcnCallWithTestSequence in sltest.harness.create is not recommended

Not recommended starting in R2018b

Starting with the R2018b release, you can use the 'SchedulerBlock' option to include a scheduler block when creating a test harness. The name-value pair 'SchedulerBlock','Test Sequence' uses a Test Sequence scheduler block and replaces 'DriveFcnCallWithTestSequence',true.

'SchedulerBlock' provides more scheduler options, and creates a simplified block interface compared to 'DriveFcnCallWithTestSequence'. To update your code, for instances of sltest.harness.create, replace 'DriveFcnCallWithTestSequence',true with 'SchedulerBlock','Test Sequence'.