5. The Reactis Info File Editor#

Reactis does not modify the .slx file for a model. Instead it stores any model-specific information it requires in an .rsi file. The primary way to view and edit the data in an .rsi file is via the Reactis Info File Editor, as described in this chapter.

The information stored in the .rsi file is grouped into categories which are each controlled from a different pane of the Info File Editor. These categories (described in detail in subsequent sections) are named as follows:

Harness.

This panel contains information and settings for the current test harness.

Inports.

This panel contains constraints on the values that the inports may assume during simulation, test generation, and validation.

Configuration Variables.

This panel lists workspace variables or data dictionary items tagged as configuration variables. Their value may change between tests, but not during a test.

Test Points.

This panel lists model data items which will be used as test points during testing.

Outports.

This panel specifies the tolerance for Simulator to use when comparing an outport value computed by the model against the corresponding value in a test suite. It also includes a list of intervals for each output for tracking interval coverage.

General.

This panel contains parameters which control how a model executes in Reactis (e.g. conditional input branch execution, short circuiting, etc.).

Error Checking.

This panel specifies how Reactis will respond to various types of errors (e.g. overflow, NaN, etc.).

Coverage Metrics.

This panel specifies the coverage metrics to be used when working with a model.

Excluded Coverage Targets.

This panel lists targets to be ignored when measuring the coverage of a model.

Validator Objectives.

This panel lists all Validator objectives (assertions, user-defined targets, virtual sources).

C Code.

If using the Reactis for C Plugin, this panel will contain a list of places C code is used in the model under test (S-Functions and Stateflow custom code) and settings which control the white-box analysis of each S-Function.

External EML Functions.

This panel lists .m files which contain Embedded MATLAB functions called from the model (e.g. from MATLAB Function blocks, Stateflow, Truth Tables).

Callbacks.

This panel specifies callbacks to be executed before and/or after a model is loaded.

Search Path.

This panel contains the model-specific search path.

File Dependencies.

This panel lists files on which the model depends.

Note that the contents of an .rsi file may only be modified when Simulator is disabled. When Simulator is running, the Info File Editor operates in read-only mode as indicated by [read only] in the editor window’s title bar.

Although not necessary, the default naming convention assumes that the .slx file and .rsi file of a model share the same base name. For example, if the model file is named cruise.slx, then the name of the associated .rsi file is assumed to be cruise.rsi. An .rsi file named differently may be associated with a model by loading the model in Reactis and selecting File > Select Info File…

5.2. Toolbar#

The following buttons are available in the Info File Editor toolbar. Note that whether a button is enabled or not may depend on which pane is currently active.

Save any changes to the currently loaded .rsi file.

Equivalent to menu item Edit > Add….

Equivalent to menu item Edit > Edit….

Equivalent to menu item Edit > Remove.

Cut the selected item and copy it to the clipboard.

Copy the selected item into the clipboard.

Paste the item in the clipboard into the selected row.

Undo last editing operation.

Redo last undone edit operation.

Select harness.

Get help.

5.3. Test Harness Pane#

A test harness configures how a model is tested. The default harness named Top-Level is for testing the full model. If you wish to test only an isolated component of your model, you can right-click on any subsystem in the main Reactis window or model hierarchy tree and select Create New Harness…. When you create a harness for a subsystem, its inputs and outputs are treated as top-level inputs and outputs for the purpose of testing the subsystem on its own. When Reactis Tester generates a test suite for a model configured to use a harness, Tester will directly select values for the inputs of the harness subsystem and capture the output values computed by the harness subsystem to store them in the generated test suite. When a model with harness is run in Reactis Simulator, coverage and data values can be tracked in the harness subsystem, while other parts of the model are grayed out and not executed.

The Harness pane is shown in Figure 5.2. The drop-down menu in the toolbar lets you select the harness to be used for testing and simulation. If you wish to test the harness subsystem at a sample rate different from the parent model, you can specify that in this pane also. When you switch between harnesses, the contents of the Inports pane and the Outports pane change to reflect the inputs and outputs of the selected subsystem harness. The settings in all other panes are shared by all harnesses.

_images/rsifeHarnessPane.png

Fig. 5.2 The Reactis Info File Editor with the Harness pane selected.#

5.4. Inports Pane#

Inport type constraints are used by Reactis to constrain the set of values fed into harness inports during simulation, test generation, and model validation. The types that may be used are: base Simulink/Stateflow types extended by notation to specify ranges and subsets within a base type, rate-of-change (or delta) constraints, resolution constraints, and constraints on vector and bus elements.

The Info File Editor with the Inports pane selected is shown in Figure 5.3. The pane displays a row for each harness inport of your model. Double-clicking on a row opens the type editor dialog for the item in the row. As detailed in the following section, the dialog offers a user-friendly interface to construct a type constraint for the input.

_images/rsifeInportPane.png

Fig. 5.3 The Reactis Info File Editor with the Inports pane selected.#

5.4.1. The Type Editor Dialog#

The Type Editor Dialog, shown in Figure 5.4, helps you construct type constraints for harness inports (as well as for configuration variables and test points). These types constrain the set of values Reactis will assign to inports during testing. In the following discussion, we use TUC to denote the type under construction, i.e. the type being defined with the dialog.

_images/typeEditorA.png

Fig. 5.4 The dialog for specifying type constraints for inports, configuration variables, or test points. As shown here a default type of double {0.0, 1.0} is specified for port onOff, meaning that during random simulation, after time zero, onOff will be assigned the values 0.0 and 1.0 with equal probability. The list of conditions (item 1) lets you specify different constraints be used at different times. As shown, when simulation time is zero (indicated by the first condition t == 0), a constraint is specified that is different from the currently displayed default.#

5.4.1.1. Invoking the Type Editor#

The Type Editor may be invoked for an inport in several different ways:

  • From the main panel of the Reactis window, by either:

    • double-clicking on a harness inport, or

    • right-clicking on a harness inport and selecting Edit Type, or

  • From the Inports pane of the Reactis Info File Editor, by either:

    • double clicking on an inport row, or

    • selecting an inport row with a single click, and then right-clicking in the body of the Info File Editor and selecting Edit Type, or selecting menu item Edit > Edit…

5.4.1.2. Using the Type Editor#

A type may be constructed with the dialog by performing the following steps. Window items refer to the labels in Figure 5.4. Recall that TUC denotes type under construction (for the currently selected condition), i.e. the type being defined with the dialog.

  1. Should the type constraint stay the same throughout a simulation or should different constraints apply at different simulation times? The condition list (window item 1) lets you specify this using a list of conditions. Each condition is a simple boolean expression that can reference the current simulation time denoted as t. To determine the constraint to be used at a given simulation time, Reactis evaluates the condition expressions in the list from top to bottom. The constraint associated with the first expression that evaluates to true will be used. The final element of the list default will be used if no other condition evaluates to true. Add, edit, remove, or reorder the conditions using the buttons under the list (window item 2). Clicking on an a condition in the list will cause the constraint associated with that condition to be displayed in the panel to the right of the condition list.

  2. Should the type include all values in the base type, only a subrange of the base type, or only a set of specific values in the base type?

    All values in base type.

    Select the Complete range of base type radio button (window item 5) and proceed to step 3.

    Only a subrange of the base type.

    Select the Subrange of base type radio button (window item 6) and specify a lower and upper bound for the range using window items 7 and 8 respectively. If the port has a base type of double, single, or an integer type, then you may specify a resolution for the values in the TUC. To do so click the Resolution check box (window item 9) and enter a resolution value in the text box to the right (window item 10). When a resolution is specified, a variable of the TUC will only assume values that differ from the lower bound specified in window item 7 by some multiple of the resolution value in window item 10. Proceed to step 3.

    A specific set of values in the base type.

    Select the Set of specific values radio button (window item 11) and use the Add, Edit, and Remove buttons (window item 14) to create a list of values. Each value must be an element of the base type of the TUC and may be assigned a probability weight. See Type Constraint Syntax for a description of probability weights. Proceed to step 3.

  3. Do you wish to constrain how the values arriving over the inport may change from one step to the next during simulation?

    No.

    Select the No limitation radio button (window item 16) and proceed to step 4.

    Yes.

    Select the Limits radio button (window item 17) and enter values in the Minimum and Maximum text entry boxes (window items 18 and 19). If min and max are the values specified here, then values arriving over ports with the TUC will be constrained as follows. If \(v_1\) and \(v_2\) are values for such a port in consecutive simulation steps, then \(v_1 + min \le v_2 \le v_2 + max\). Proceed to step 4.

  4. When you are satisfied with the type you have constructed click the Ok button to update type and dismiss the Type Editor dialog.

  5. Select File > Save to save your changes to the .rsi file.

5.4.1.3. Labeled Window Items#

This section describes the labeled items in Figure 5.4. Recall that TUC denotes type under construction (for the currently selected condition), i.e. the type being defined with the dialog.

  1. Condition list that lets you specify different constraints for different simulation times. Each condition in the list is a simple boolean expression that can reference the current simulation time (denoted as t). When a condition is selected, the constraint associated with that condition is displayed in the right portion of the dialog.

    To determine the constraint to be used at a given simulation time, Reactis evaluates the condition expressions in the list from top to bottom. The constraint associated with the first expression that evaluates to true will be used. The final element of the list default will be used if no other condition in the list evaluates to true.

    Conditions are constructed from relational operators (<, <=, ==, !=, >, >= ), logical operators ( &&, ||, !), the current simulation time t, and time values (non-negative double values). The complete syntax of conditions is defined by the timeExpr variable in the grammar in Type Constraint Syntax. The following table gives some sample conditions:

    t == 0

    Simulation time is zero.

    (t > 1) && (t < 1.5)

    Simulation time is greater than 1 and less than 1.5.

  2. Buttons used to add, edit, remove or reorder elements of the condition list.

  3. The textual version (as described in Type Constraint Syntax) of the TUC is displayed here. The string here may not be edited. It is read-only. It is updated by Reactis when you click the Apply button.

  4. The radio buttons in this group (window items 5, 6, and 11) enable you to specify the values from the base type to be include in the TUC.

  5. Selecting this radio button indicates that all values from the base type should be included in the TUC.

  6. Selecting this radio button indicates that only a subrange of values from the base type should be included in the TUC.

  7. When the Subrange of base type radio button is selected, this entry box enables you to specify a lower bound for the subrange.

  8. When the Subrange of base type radio button is selected, this entry box enables you to specify an upper bound for the subrange.

  9. If the Subrange of base type radio button is selected and the TUC has a base type of double, single, or an integer type, then this check box may be checked in order to specify a resolution for the TUC.

  10. When the Resolution check box (window item 7) is checked, a resolution value may be entered in this text box. When a resolution is specified, a variable of the TUC will only assume values that differ from the lower bound specified in window item 5 by some multiple of the resolution value here.

  11. Selecting this radio button indicates that only a specified set of values from the base type should be included in the TUC. The buttons in window item 14 are used to specify the set of values.

  12. The entries in this column specify the values in the TUC.

  13. The entries in this column associate a probability weight with each value in the TUC. See Type Constraint Syntax for a description of probability weights.

  14. Buttons used to add, edit, or remove values to/from a set of specific values. Items are added using the dialog shown in Figure 5.5.

_images/addEnum.png

Fig. 5.5 Dialog for adding one or more values (with optional probability weight) to an enumerated set of values. The entry shown will add the values 0 and 1; with 0 having a probability weight of 1 and 1 having a probability weight of 3.#

  1. The radio buttons in this group enable you to specify whether or not the type has a delta constraint. For an inport with the TUC, such a constraint limits the allowable changes in value from one simulation step to the next.

  2. The TUC has no delta constraint.

  3. The TUC has the delta constraint indicated by window items 18 and 19.

  4. The value for an inport with the TUC may change by no less than the value specified here. If \(v_1\) and \(v_2\) are the values of the inport in consecutive simulation steps then \(v_2 - v_1 \ge min\).

  5. The value for an inport with the TUC may change by no more than the value specified here. If \(v_1\) and \(v_2\) are the values of the inport in consecutive simulation steps then \(v_2 - v_1 \le max\).

  6. View help on the type editor dialog.

  7. Update the TUC and dismiss the dialog. The revised TUC will appear in the appropriate row of the Info File Editor and [modified] will appear in the title bar. Selecting File > Save will write the .rsi file to disk and cause the [modified] tag in the title bar to disappear.

  8. Discard any changes to the TUC and dismiss the dialog. Note that if the Apply button was previously clicked, any changes prior to the click will not be discarded.

  9. Apply any changes made to the TUC and update the text in window item

  10. Any changes prior to the click will be retained even if the dialog is dismissed with the Cancel button or clicking the X in the upper right corner of the dialog. After the dialog is closed, the revised TUC will appear in the appropriate row of the Info File Editor and [modified] will appear in the title bar. Selecting File > Save will write the .rsi file to disk and cause the [modified] tag in the title bar to disappear.

5.4.1.4. Editing Vector Types#

As shown in Figure 5.6, a left panel appears in the type editor dialog when editing a inport with a vector type. The left panel includes a matrix such that each element of the matrix specifies a type for one element of the vector signal. In the case of one-dimensional vectors the matrix has a single column. To specify the type for an element of the vector, select it with the mouse and then use the controls in the right portion of the dialog to specify a type in the same manner described above for scalar types. Multiple elements may be set to the same type as follows:

  1. Select one element and configure it as desired.

  2. Click the copy button .

  3. Select some number of other elements by one of the following methods:

    Consecutive elements

    Select the first element in the desired range of elements, then hold down the shift key and left-click on the last element of the desired range.

    Non-consecutive elements

    Hold down the control key and select any number of elements by left-clicking on them.

  4. Click the paste button .

_images/typeEditorArray.png

Fig. 5.6 When an inport has a vector type, the left portion of the type editor includes a matrix in which each element specifies the type for an element of the vector.#

5.4.1.5. Editing Bus Types#

As shown in Figure 5.7, a left panel appears in the type editor dialog when editing an inport with a bus type. The left panel includes a hierarchical display of the bus elements. To specify the type for a leaf element of the bus, select it with the mouse and then use the controls in the right portion of the dialog to specify a type in the same manner described above for scalar types.

_images/typeEditorBus.png

Fig. 5.7 When an inport has a bus type, the left portion of the type editor includes a hierarchical display of the bus elements. When a leaf bus element is selected in the left panel, a type may be configured for the element using the right panel.#

5.4.2. Type Constraint Syntax#

Although you typically construct type constraints with the graphical editor, a textual language formally defines the set of valid type constraints. This language is defined by the following grammar.

intType

:

int8, int16, int32, uint8, uint16, uint32

floatType

:

double, single

fixedPointType

:

sfixbitsSlopeBias

|

ufixbitsSlopeBias

numberType

:

intType

|

floatType

|

fixedPointType

baseType

:

numberType

|

boolean

|

Enum:enumTypeName

rsiType

:

baseType

|

baseType { val1 , val2 , … , valn }

|

numberType [ min, max ]

|

numberType delta [ min, max ]

|

numberType [ min, max ] delta [ min, max ]

|

numberType [ min : step : max ]

|

numberType [ min : step : max ] delta [ min, max ]

|

vectorType

|

busType

|

if timeExpr then rsiType1 else rsiType2

vectorType

:

<| rsiType1 * rsiType2 * … * rsiTypen |>

:

<| rsiType ^ int |>

busType

:

{ fieldName1 : rsiType1 , … , fieldNamen : rsiTypen }

|

busName -> { fieldName1 : rsiType1 , … , fieldNamen : rsiTypen }

val

:

value

|

value : weight

timeExpr

:

t relationalOp timeVal

|

timeExpr1 logicalOp timeExpr2

|

! timeExpr

|

( timeExpr )

The variables in this grammar are defined as follows:

  • min, max, step, and value are elements of the given base type.

  • weight is an integer greater than zero and less than one thousand.

  • t is the current simulation time.

  • timeVal is a non-negative double value.

  • relationalOp is a relational operator: <, <=, ==, !=, >, >= .

  • logicalOp is a logical operator: &&, || .

For a vector type <| rsiType1 * rsiType2 * … * rsiTypen |>, the base types of all rsiTypei must be identical. For a bus type, the base types of the different field types may be different.

The shorthand vector type syntax <| rsiType ^ int |> defines a vector type with int repetitions of type rsiType. For example, <| int8 ^ 4|> is equivalent to <|int8 * int8 * int8 * int8|>.

Fixed point types are strings that specify a set of parameters for the generalized slope-bias encoding scheme for representing real numbers using integers. These strings consist of a prefix of either sfix (signed) or ufix (unsigned) followed by a suffix of the form bitsSlopeBias. The suffix is further divided into one required substring bits and two optional substrings slope and bias. These three substrings are defined as described below. Note that fpDecimal is a string that encodes a decimal value by replacing a negative sign - with n and the decimal point . with p. For example, -4.9 is represented as n4p9 and 2.3 as 2p3. Similarly fpInt is a string that encodes an integer value by replacing a negative sign - with n.

bits

is a positive integer indicating the number of bits to be used to represent values of the type.

slope

is a decimal specified in one of two ways

  • as _SfpDecimal such that slope = fpDecimal

  • as _FfpDecimal_EfpInt such that slope = fpDecimalx2fpInt

bias

is a decimal specified as _BfpDecimal.

If the slope substring is omitted a default value of 1 is used. If the bias substring is omitted a default value of 0 is used.


The following examples show some legal types and the sets of values they specify.

RSI Type

Values in Type

double [0.0,4.0]

All double-precision floating-point numbers x, where 0.0 <= x <= 4.0

double [-10.0:0.25:10.0]

10.0, -9.75, -9.5, …, 9.5, 9.75, 10.0

int16 [-1,1]

-1, 0, 1

int32 {0, 4, 7}

0, 4, 7

uint8 {0:1, 1:3}

0, 1

double delta [-1.0,1.0]

All double-precision floating-point numbers, but inport values of this type can increase or decrease by at most 1.0 during successive simulation steps.

<| double { 1.0,2.0,3.0 } * double {10.0} |>

<| 1.0, 10.0 |>, <| 2.0, 10.0 |>, <| 3.0, 10.0 |>

{ x : uint8 { 1, 2 }, y : unit8 { 3, 4} }

{ x = 1, y = 3 }, { x = 1, y = 4 }, { x = 2, y = 3 }, { x = 2, y = 4 }

In range types (i.e. those of form t [ l , u ]), the lower and upper bounds are inclusive. In subset types (i.e. those of form t { x1 , … , xn }) the probability weights in the xi enable you to influence the probabilities of the different values in the type being selected during simulation, test generation, and model validation. For example, an inport having type uint8 {0:1, 1:3} would be assigned the value 0 in 25% of random simulation steps and the value 1 in 75% of random simulation steps, on average. In general, if inport A is assigned the type t { v1 : w1 , v2 : w2 , … , vn : wn }, then the probability of each value in the type being assigned to A is computed as follows. Let W = w1 + w2 + … + wn, where wi denotes the probability weight assigned to vi (a weight of 1 is assumed if no explicit weight is given). During random simulation or test generation, the probability of an inport A being assigned the value vi is wi/W.

Using delta types (i.e. those of form t delta [ l , u ]) you may constrain how the values fed into inports change from one simulation step to the next. For example, an inport representing a sensor measuring temperature might have the type double delta [-1.0,1.0] to specify that temperature can increase or decrease by at most 1 degree between any consecutive simulation steps. In general, if inport A has type t delta [ l , u ] and the current value of A is v1 then in the next simulation step the new value of A, v2, must satisfy: v1 + l \(\le\) v2 \(\le\) v1 + u.

Using resolution types (i.e. those of form double [ i : j : k ] where i is a lower bound, j is a resolution, and k is an upper bound) users may specify that each value that a variable of this type may assume will differ from i by some multiple of j. A delta constraint may also be added to a resolution type.

5.5. Configuration Variables Pane#

If you tag a workspace or data dictionary variable as a configuration variable, you indicate that Reactis may change its value in between tests, but not during a test. In Simulink / Stateflow, expressions involving such variables can be used to initialize blocks, for example Constant blocks. These expressions are evaluated before simulation begins. When these expressions are workspace or data dictionary variables, they may be declared to be configuration variables. Note, that variables appearing in larger expressions may not be declared configuration variables. For example, if MINTEMP is a workspace or data dictionary variable then:

  • If a Constant block is initialized by the expression MINTEMP, then MINTEMP may be tagged a configuration variable.

  • If a Constant block is initialized by the expression MINTEMP - 1, then MINTEMP may not be tagged a configuration variable.

A configuration variable is created by clicking on Edit > Configuration Variables… in the main Reactis window, then selecting Edit > Add… in the menu bar of the Info File Editor window that comes up. Reactis will display a list of all candidate configuration variables from which users may select. Data dictionary variables in this list are shown as dictionaryname.variablename, for example cruiseDict.InitialSpeed specifies variable InitialSpeed within dictionary cruiseDict. The types associated with these configuration variables in .rsi files are the same as those that may be assigned to inports and are manipulated in the same way using the Type Editor dialog as describe in Type Editor Dialog. Note, however, that configuration variables may not be given delta types, since the variables are not allowed to change during a test or simulation run.

The Type Editor may be invoked for a configuration variable in several different ways:

  • From the main panel of the Reactis window, by either:

    • selecting “Configuration Variables” in the hierarchy panel to display the configuration variables panel, and then either: right-clicking on a configuration variable and selecting Edit Type, or

    • double-clicking on a configuration variable

  • From the Configuration Variable pane of the Reactis Info File Editor, by either:

    • double clicking on a configuration variable row, or

    • selecting a configuration variable row with a single click, and then right-clicking in the body of the Info File Editor and selecting Edit…, or selecting menu item Edit > Edit…

Note that if you intend for the changes of a configuration variable to propagate into an S-Function via a parameter, then you must ensure that your S-Function defines the mdlProcessParameters function as described in S-Functions.

The specification of configuration variables of type array or structure may be done using the text version of the type editor. To edit the type for such a variable, right-click on the row and select Edit Type Text. A text entry dialog will come up in which the array or structure type may be specified. The syntax is as follows:

One-Dimensional Arrays

basetype array [ numElts ] { instance1, … , instancen } where numElts is a positive integer and each instancei has the form [ elt1 , … , eltnumElts ].

Two-Dimensional Arrays

basetype array [ numRows , numCols ] { instance1 , … , instancen } where numRows and numCols are positive integers and each instancei has the form [ row1 ; … ; rownumRows ] and each rowi has the form elt1 , … , eltnumCols.

Structures

{fieldName1 : fieldType1 , … , fieldNamen : fieldTypen } { instance1, …, instancem } where each instancei has the form { fieldName1 = value1, … , fieldNamen = valuen}.

The following examples demonstrate the notation.

Three instances of a four-element array of doubles:

double array [4] 
{ 
  [1,2,3,4], 
  [11,12,13,14], 
  [21,22,23,24]
}

Two instances of a structure for initializing a 2-D Lookup Table:

% configuration variable type
{ table  : double array [3,3], 
  row    : double array [3], 
  column : double array [3] }

{
% first Look-Up-Table configuration
  { table  = [4,5,6;16,19,20;10,18,23],
    row    = [1,2,3],
    column = [1,2,3] },

% second Look-Up-Table configuration
  { table  = [4,5,6;16,19,20;10,18,23],
    row    = [16,18,20],
    column = [11,12,13] }
}

5.5.1. Configuration Variable Sets#

Configuration variable sets let you specify multiple constraints for each configuration variable in your model. This feature offers a convenient way to capture dependencies among configuration variables. For example, in a configurable model of an automotive transmission the maximum expected RPMs might depend on the number of gears. In such a case, different configuration variable sets can be created to capture each allowed combination.

_images/rsifeConfigVarPane.png

Fig. 5.8 The Configuration Variables pane of the Reactis Info File Editor.#

Figure 5.8 shows the Info File Editor with the Configuration Variables pane selected. Within the Configuration Variables pane, the Configuration variable set pull-down (item 1 in Figure 5.8) is used to manipulate configuration variable sets. The menu contains the following items:

ConfigVarSet1 … ConfigVarSetn. Selecting ConfigVarSeti switches to that configuration variable set. In Figure 5.8 the configuration variable sets are named Any Initial Speed, Fast Initial Speed, and Slow Initial Speed. The constraints for ConfigVarSeti will appear in the main configuration variable pane and can be modified.

Create a copy of current set…

Creates a copy of the current configuration variable set. You will be queried for the name of the new set and the constraints for each configuration variable will be copied to the new set.

Create new set…

Create a new configuration variable set. You will be queried for the name of the new set and the constraint for each configuration variable will simply be the type of the underlying workspace or data dictionary variable.

Delete current set…

Delete the current configuration variable set.

Rename current set…

Change the name of the current configuration variable set.

Note that the name of the current configuration variable set is always displayed as the value of the Configuration variable set pull-down. This lets you know which set you are currently editing.

To the right of the Configuration variable set pull-down is the Enabled check box (item 2 of Figure 5.8). When Enabled is checked, the current configuration variable set is eligible for use by Reactis Tester and Reactis Simulator.

Note that all configuration variable sets contain the same member variables. Hence, adding or removing a variable will change the membership of all sets, not just the current set. What does differ between sets is the type constraint of each configuration variable. For example, in Figure 5.8, each constraint variable set contains a single variable InitialSpeed. The value of InitialSpeed is constrained to a different range in each set:

0 ≤ InitialSpeed ≤ 10 in Slow Initial Speed, 40 ≤ InitialSpeed ≤ 50 in Fast Initial Speed, and 0 ≤ InitialSpeed ≤ 50 in Any Initial Speed.

When Reactis Tester generates tests, at the start of each new test, Tester randomly selects one of the enabled configuration variable sets and then selects a value for each configuration variable that is allowed by the constraints in the selected set. If no set is enabled, then Tester works as if no configuration variables are defined (the values for workspace variable will come from the workspace).

5.6. Test Points Pane#

This pane displays a list of test points currently associated with the model. Test points are internal data items (Simulink signals or Stateflow variables) that Reactis subjects to user-specified checks during simulation and test generation. For example, Reactis can be configured to record values for test points in test suites and have Reactis Simulator flag any differences between the values computed by a model for a test point and those stored in a test suite. Additionally, a type constraint can be assigned to a test point and Reactis can be configured to monitor if a test point is ever assigned a value outside the set of expected values specified by the constraint.

5.6.1. Adding and Removing Test Points#

To add or remove a test point, Simulator must be turned off.

A test point can be added by right-clicking on a data item in the Reactis main panel and selecting Add To Test Points. After a test point is added, a visual indicator appears in the Reactis main panel as shown in Figure 5.9. If the test point is in Simulink, the indicator is a pair of eyeglasses appearing above a signal. If the test point is in Stateflow, the indicator is a box at the bottom of the Stateflow diagram containing the eyeglasses symbol and the test point name.

A test point can be removed by right clicking on the test point in the main panel (when Simulator is off) and selecting Remove Test Point. Alternatively, a test point can be removed from the Test Points pane of the Info File Editor by:

  1. selecting a row in the pane, and

  2. selecting Edit > Remove from the Info File Editor menu or clicking the remove button in the Info File Editor toolbar.

5.6.3. Interacting with the Test Points Pane#

The Test Points pane of the Info File Editor lists each test point created for a model as shown in Figure 5.11. Test points may be removed using this pane as described above. Double-clicking on the name of a test point in this pane causes the test point to be displayed and highlighted (with yellow flashing) in the main Reactis panel. The Tolerance and Type Constraint columns list aspects of how each test point is configured as described in the next section. Double-clicking in the Tolerance or Type Constraint column for a test point opens the Test Point Properties Editor for the test point.

_images/testPointsPane.png

Fig. 5.11 The Test Points pane.#

5.6.4. Configuring a Test Point with the Test Point Properties Editor#

The Test Point Properties Editor (Figure 5.12) lets you configure the checks that Reactis will perform on a test point during test generation and simulation. It can be opened from both the Reactis main panel and the Reactis Info File editor.

  • From the Reactis main panel:

    • Double-click on a test point symbol, or

    • Right-click on a test point symbol and then select Edit Test Point Properties…,

  • From the Test Points pane of the Reactis Info File editor:

    • Double-click on the Tolerance or Type Constraint column for a test point, or

    • Select a test point row, then click the edit button in the toolbar, or

    • Select a test point row, then select menu item Edit > Edit….

_images/testPointProperties.png

Fig. 5.12 The Test Point Properties Editor for configuring test point behavior.#

The labeled items of Figure 5.12 configure a test point as follows:

  1. The name of the test point. This need not match the underlying signal or variable name.

  2. Clicking the Highlight button will cause the test point to be displayed in the main Reactis panel and be highlighted by flashing yellow.

  3. The location of the test point within the model hierarchy.

  4. When checked, Reactis will record a value for the test point whenever it constructs a test (in Tester, Simulator, Validator) in the same manner as is done for computed harness output values.

  5. When checked, before storing a test point value in a test suite, Reactis will check whether the computed value is within the set of acceptable values specified by the type constraint for the test point. If not it will convert the computed value to the nearest value within the set specified by the type constraint and then store the converted value in the test suite.

  6. If checked, whenever a test is executed in Reactis Simulator, at each simulation step the value computed by the model for a test point will be compared against the value stored in the test step for the test point. If the difference exceeds the tolerance specified by item 7, then the difference will be flagged.

  7. If item 6 is checked, this section specifies the tolerance to be used when comparing a computed test point value against the value in a test suite. The pull-down lets you select one of five methods for computing a tolerance. How the methods work is described in Tolerance Methods.

  8. When checked, Reactis will create coverage targets for the boundary values of the test point’s type constraint. For example, targets will be created for the minimum and maximum values if a range constraint is given for a test point. For a description of the boundary value targets inferred from a type constraint see Boundary Values for Inports, Test Points, and Configuration Variables.

  9. When checked, Reactis will create and track an assertion that will be violated if the test point is assigned a value outside the set of values specified by its type constraint. For example, if a range is specified, the assertion will be violated if the test point ever assumes a value outside the given range.

  10. When checked, Reactis will generate either a warning or error if a test point is assigned a value outside the set specified by its type constraint.

  11. Clicking this button opens a dialog for specifying the type constraint for the test point. See The Type Editor Dialog for instructions on using the dialog.

  12. Displays the type constraint for the test point. Note, that specifying a constraint is only necessary if one of the operations using type constraints is enabled. When no type constraint is specified, this box will display <not set>.

  13. Clicking this button opens a dialog for specifying the test point intervals.

  14. Displays the intervals for the test point. See Interval Coverage.

  15. Display help for the Test Point Properties Editor.

  16. Save any changes and close the editor.

  17. Discard any changes and close the editor.

When exporting a test suite to CSV format, users have the option to export test point data in addition to inport and outport values.

5.7. Outports Pane#

_images/rsifeOutportTolerances.png

Fig. 5.13 The Reactis Info File Editor with the Outports pane selected.#

When executing a test suite in Reactis Simulator, at each simulation step, for each outport, Reactis compares the value computed by the model for the outport against the value stored in the test suite for the outport. The Outports pane, shown in Figure 5.13, lets you specify a tolerance for each outport to be used in these comparisons. Additionally, the pane lets you specify a list of intervals for each outport. Interval coverage tracks whether an outport has assumed a value within each interval specified for it.

The Outports pane displays six properties for each outport, labeled in Figure 5.13:

  1. The port number.

  2. The port name.

  3. The tolerance method.

  4. The relative tolerance value. If the method does not use relative tolerance, this will be blank.

  5. The absolute tolerance value. If the method does not use absolute tolerance, this will be blank.

  6. The intervals to be tracked by interval coverage for the outport.

The tolerance or intervals for a port are changed by either (1) double-clicking on the row for the port, or (2) left-clicking on the row for the port and then right-clicking and selecting Edit…. Either of these actions will open the Outport Properties editor dialog for the selected port. Note that changing the port-specific tolerance will override the global tolerance for the model set within the Error Checking pane of the Info File Editor. See The Outport Properties Editor Dialog for an explanation of the dialog.

5.7.1. Tolerance Methods#

Reactis offers five tolerance methods for comparing values computed by the model against those stored in a test suite for outports and test points: Absolute, Relative, Max, Min, and Inherit.

The absolute tolerance method flags a difference between a computed value and a test value if the absolute value of the difference exceeds a given amount. More precisely, given two values x and y and an absolute tolerance ε, the difference between x and y is flagged if and only if |x-y| > ε.

The relative tolerance method flags a difference between a computed value and a test value if it exceeds an amount determined by multiplying the tolerance by either the computed or test value. More precisely, given two values x and y and a relative tolerance ε, the difference between x and y is flagged if and only if any of the following conditions are true:

|x-y| > ε × | x |

when

x ≠ 0

|x-y| > ε × | y |

when

y ≠ 0

|x-y| > ε2

when

x = 0 or y = 0

A relative or absolute tolerance of zero will require that the model and test values always be the same, a relative tolerance of 0.1 will allow a difference of 10%.

The max tolerance method uses both a relative and absolute tolerance. A difference is flagged if it is flagged by both the absolute and relative tolerance methods.

The min tolerance method uses both a relative and absolute tolerance. A difference is flagged if it is flagged by either the absolute or relative tolerance method.

If the tolerance method is set to Inherit, then the tolerance method is inherited from the model’s global tolerance setting (set in the Error Checking pane of the Info File Editor).

In addition to their use in flagging differences when running a test suite in Simulator, the tolerances specified here are also used in the following places:

5.7.2. The Outport Properties Editor Dialog#

_images/toleranceEditorA.png

Fig. 5.14 The dialog for specifying (1) the tolerance to use when comparing computed and test suite values and (2) the intervals for tracking interval coverage. As shown, an absolute tolerance of 0.1 is specified, which means that differences which are less than or equal to 0.1 will be ignored.#

Tolerances are specified via the Outport Properties dialog, which is shown in Figure 5.14. The labeled items in the figure are explained as follows:

  1. This pulldown menu lets you choose the tolerance method. The possible choices are Inherit, Relative, Absolute, Min, or Max. These are explained in Tolerance Methods.

  2. This data entry box contains the relative tolerance value used by the selected method, which must be non-negative. If the method does not use relative tolerance, it will be disabled.

  3. This data entry box contains the absolute tolerance value used by the selected method, which must be non-negative. If the method does not use absolute tolerance, it will be disabled.

  4. This button opens a dialog to modify the intervals for interval coverage tracking. See Interval coverage.

  5. This section lists the intervals for interval coverage tracking. See Interval coverage.

  6. This button opens the help dialog for the Outport Properties dialog.

  7. This button accepts the displayed settings and closes the Outport Properties dialog.

  8. This button ignores any changes made and closes the Outport Properties dialog.

5.8. General Pane#

The General pane lets you configure the following model-specific settings. When a new .rsi file is created, the values for these settings are taken from the Default Model-Specific Settings dialog (invoked by File > Default Model-Specific Settings…).

Model file encoding.

Character encoding used by the model.

Conditional input branch execution.

Conditional input branch execution is an optimization that causes some blocks in a model not to execute when they are not necessary to compute the outputs of the model. The options for this menu are:

On

Use conditional input branch execution.

Off

Do not use conditional input branch execution.

Inherit from model settings

Enable or disable conditional input branch execution according to the settings in the .slx file.

Indicate when signal values were not computed

For signals that have not (yet) been computed in the current simulation step, Reactis Simulator can either show “[not computed]” or show the signal’s value from when it was last computed (see Non-Executed Blocks and Signals). This setting controls when Reactis shows non-computed signals:

Never

Reactis will always show the signal’s previous value.

For conditional input branch execution only

Show “[not computed]” if a signal has not been computed because of conditional input branch execution.

For all Simulink signals

Show “[not computed]” for any signal that has not (yet) been computed (some exceptions apply, see Non-Executed Blocks and Signals).

Bus element name visibility.

Reactis V2012 introduced substantial enhancements for models that use bus types. One of the central improvements includes the visibility of bus element names in many new places (e.g. when editing type constraints for top-level bus inports using a new user-friendly graphical editor, when adding a watched variable, or when opening a scope).

This setting lets you disable the new bus-related feature and configure Reactis to internally treat buses as it did prior to V2012. Due to the substantial loss of new capabilities that occurs, we suggest you do not disable the feature unless the Reactive Systems support team suggests you do so to work around an issue that arises when your model uses the new functionality. The settings are as follows:

Show element names for all buses

the recommended setting that enables the new set of bus-related features.

Do not show element names (legacy)

disable the new bus-related features.

If lookup table uses internal rule priority ‘speed’

This setting determines the behavior for lookup tables which have been set to use the Speed option for the internal rule priority. Note that due to the undocumented behavior of lookup tables in MATLAB when the Speed option is used, there may be differences between the outputs computed by Reactis and those computed by MATLAB. There are three choices:

Use rule priority ‘precision’

Simulate the lookup table as if the rule priority were set to precision. Do not produce a warning.

Use rule priority ‘precision’ and produce warning.

Simulate the lookup table as if the rule priority were set to precision. Produce a warning when Simulator is started for the first time.

Produce error

Produce an error when attempting to start Simulator.

Create and use cache files (with extension ‘.mwi’).

Instructs Reactis to create a file containing intermediate information it has computed about a model. These files can significantly improve subsequent load times. If you modify your model, Reactis will detect the changes and re-generate the .mwi file. Clicking the Flush Cache button causes the cache to be emptied. Subsequently intermediate information will be recomputed as needed. Note, however, that .mwi files are not deleted on disk.

Create and use binary cache files (with extension ‘.mwib’).

Instructs Reactis to create a file containing runtime information it has computed about a model. These files can significantly improve Simulator startup times. If you modify your model, Reactis will detect the changes and re-generate the .mwib file. Clicking the Flush Cache button causes the cache to be emptied. Subsequently runtime information will be recomputed as needed. Note, however, that .mwib files are not deleted on disk.

When creating a test suite, also create a parameters file (extension .rtp).

Instructs Reactis Tester to store launch parameters and the .rsi file used for a given run in a Reactis Tester Parameter file (.rtp file). Subsequently:

  • the .rsi file may be extracted from the .rtp file by selecting File > Extract Info File…;

  • the Tester parameters may be loaded into the Tester launch dialog by clicking the Load button.

Re-running Tester with the same .rsi file and same parameters on the same model will regenerate the test suite produced by the original Tester run.

Propagate set_param changes by saving the model to a temporary file.

Models using self-modification commands (e.g. set_param, add_block,etc. ) could previously cause problems because Reactis would not see the changes made by them. This setting has been added to deal with this scenario. If this setting is enabled, Reactis will cause Simulink to apply all the changes to the model, then automatically save them to a temporary file. Reactis then imports the temporary model file, allowing Reactis to see the applied changes.

Ignore ToFile and ToWorkspace blocks.

Checking this box enables Reactis to process models that include these blocks by ignoring them. If not checked, Reactis reports an error whenever it simulates a model containing such blocks.

Short-circuit Simulink boolean operators.

Checking this box indicates that evaluation of logic blocks should be short-circuited, i.e. should be halted as soon as its output value has been determined. For example, once one input to an AND block has been found to be false, it is known that the output of the AND block should be false; if this box is checked, then the remaining inputs are not examined. Short-circuiting affects coverage analysis and reporting for condition, decision and MC/DC coverage metrics, as unexamined inputs are treated as “don’t care” points. More information about coverage may be found in Reactis Coverage Metrics.

Short-circuit Stateflow boolean operators.

Checking this box indicates that boolean operators in Stateflow conditions should be short-circuited. See the previous item for a discussion of short-circuiting.

Prepend Reactis search path to MATLAB path.

When this box is checked, every time Reactis launches MATLAB it will prepend the Reactis search path to the MATLAB path.

Execute startup.m and pathdef.m scripts in model folder.

When this box is checked, every time Reactis launches MATLAB it will look for pathdef.m and startup.m files residing in the same folder as the model. If a pathdef.m file is found, Reactis will set the MATLAB path according to its contents. If a startup.m file is found, Reactis will direct MATLAB to execute it prior to loading the model.

Remove unused MATLAB workspace variables before model import.

If enabled, Reactis will instruct MATLAB to delete any unused workspace variables after loading a model during import. This can significantly speed up import times for models that use a generic workspace setup from which only a few variables are actually used. However, in some cases MATLAB may remove variables that are actually used by the model which can lead to errors about undefined variables during import.

When referenced, inherit import parameters from parent model.

When this box is checked and the current model is referenced by another model, the referenced model will inherit import-related parameters such as Reactis callback functions and search path from the parent model.

5.9. Error Checking Pane#

The Error Checking pane lets you configure the following model-specific settings related to which types of errors Reactis will flag. When a new .rsi file is created, the values for these settings are taken from the Default Model-Specific Settings dialog (invoked by File > Default Model-Specific Settings…).

5.9.1. General#

If harness input value does not match constraint

Reactis lets you associate a constraint with each harness inport of a model from the Edit > Inports pane of the Info File Editor. For example, you can specify a range for a given input, and then, when Reactis Tester generates tests it will only select values within the range for the tests it constructs. However, if external test data is brought into Reactis (e.g. via importing a .csv file), it is possible for the data to contain input values that violate the constraints set for the corresponding input in Reactis. The If harness input value does not match constraint setting allows you to set the desired behavior for the case that an input value is encountered during simulation that does not match the input’s constraint. The possible settings are:

Use value.

Proceed and produce no error or warning.

Use value and produce warning.

Proceed but produce a warning.

Produce error.

Produce an error and stop test generation or simulation.

Note that Produce error is the recommended setting because it allows Reactis to use harness input constraints to improve both static reachability analysis and constraint solving during test case generation.

If configuration variable value does not match constraint

Each configuration variable can be given a constraint from the Edit > Configuration Variables pane of the Info File Editor. For example, a range constraint can be specified and then Reactis Tester will only select values within that range. However, if external test data is brought into Reactis (e.g. via importing a .csv file), it is possible for the data to contain configuration variable values that violate the constraints set for the configuration variable. The If configuration variable value does not match constraint setting allows you to set the desired behavior for the case that an configuration variable value is encountered during simulation that does not match the variable’s constraint. The possible settings are:

Use value.

Proceed and produce no error or warning.

Use value and produce warning.

Proceed but produce a warning.

Produce error.

Produce an error and stop test generation or simulation.

Note that Produce error is the recommended setting because it allows Reactis to use harness input constraints to improve both static reachability analysis and constraint solving during test case generation.

If delta constraint exceeds type range.

A delta constraint for a harness inport limits how much values on the inport can change from one simulation step to the next. A delta constraint that sets the maximum allowed change to be bigger than the entire range of the type most likely indicates an erroneous delta constraint. This setting lets you configure whether and how Reactis should flag such constraints with a size error.

To define how the setting works assume a delta constraint:

double [min,max] delta [dmin,dmax]

Let range = max - min. Then a delta constraint size error occurs if dmin < -range or dmax > range. When such an error occurs, Reactis clips the dmin and/or dmax values so no change is bigger than range. If you start Simulator or Tester using an .rsi file containing a delta constraint size error, then Reactis does the following according to the setting in this dialog:

Clip delta.

Proceed and produce no error or warning.

Clip delta and produce warning.

Proceed but produce a warning.

Produce error.

Produce an error and stop test generation or simulation.

Tolerance for output and test point differences

When running a test suite, Reactis Simulator compares the harness outputs and values for test points produced by the model to those stored in the test suite and produces a warning if a difference is detected. Since small differences might be acceptable, a tolerance can be specified here that will be used for the comparison. To require an exact match, the tolerance can be set to absolute or relative zero. Note that the global tolerance specified here can be overridden for a particular outport or test point as described in Test Points Pane and Outports Pane.

5.10. Coverage Metrics Pane#

Reactis supports a number of different coverage metrics and assertion categories. The Coverage Metrics pane lets you individually enable or disable each metric and assertion category. These settings are model-specific. When a new .rsi file is created, the values for the settings are taken from the Default Model-Specific Settings dialog (invoked by File > Default Model-Specific Settings…). If a metric is disabled:

  • the metric will not be targeted by Tester when generating tests, and

  • Simulator will not include the targets from the metric in the Coverage Summary dialog, the Coverage Report Browser, and the highlighting in the main panel.

The following dependencies exist between the coverage metrics:

  • Enabling condition coverage requires that decision coverage be enabled

  • Enabling MC/DC or MCC require that Condition coverage be enabled

Additionally, the meaning of several of the metrics (CSEPT, Decision, and Boundary Value) can be adjusted in this dialog as follows.

Child State Exit via Parent Transition (CSEPT)

See Child State Exit via Parent Transition for a description of how these settings configure what constitutes CSEPT targets.

C-specific Decision Metrics

See C Code Coverage Metrics for an explanation of these settings.

Decisions
Multi-block Decision, Condition, MC/DC and MCC.

Switches between single-block and multi-block coverage tracking for Simulink logical operator blocks. For more details about this feature see Decision, Condition, MC/DC and MCC Metrics.

Multiple Condition Coverage (MCC)
Maximum number of conditions per decision.

If the actual number of conditions for a decision exceeds the number given here then MCC coverage will not be tracked for that decision. If this happens a warning will be shown when enabling Simulator or generating test cases. A warning will also appear in coverage reports.

Boundaries
Boundary coverage for relational operators.

As described in Boundary Values for Relational Operators, Reactis tracks boundary value coverage for Relational Operator blocks. Since this coverage metric has the potential to introduce a large number of very hard to cover targets, some users might prefer to not track these targets. This check box enables and disables boundary value coverage tracking for relational operators.

Include relational operators comparing floating-point values.

Toggles whether relational operators with floating point inputs are included in the set of relational operator boundary value targets.

Relative tolerance.

When relational operators comparing floating-point values are included, this entry box enables you to specify a relative tolerance as described in Boundary Values for Relational Operators. To generate the smallest increment that can be represented in floating-point, type the term next.

Track coverage for ‘equals’ case.

When relational operators comparing floating-point values are included, this box toggles whether a coverage target should be created for the ‘equals’ case, i.e. a=b as described in Boundary Values for Relational Operators

Boundary coverage for integer saturation.

When enabled, targets are created for blocks which are set to saturate on integer overflow. See Boundary Values for Integer Saturation.

Include targets for no saturation.

Toggles whether or not a target is created which is covered when integer saturation does not occur for blocks which are set to saturate on integer overflow. See Boundary Values for Integer Saturation.

Interval Targets
Track whether outputs have changed from initial value.

Toggle whether a special interval denoted (~y0) should be created for every outport to track whether the outport has assumed a value different from its initial value.

Validator Objectives
Track coverage for contents of Validator Objectives.

Toggles whether or not the targets within diagram-based Validator Objectives are tracked. The objective itself (assertion or UDT) is tracked even when the targets within the objective are not.

5.11. Excluded Coverage Targets Pane#

_images/rsifeExcludedTargets.png

Fig. 5.16 The Reactis Info File Editor with the Excluded Coverage Targets pane selected.#

The Excluded Coverage Targets pane lists all coverage targets which have been excluded from coverage. Every excluded target occupies one row within the pane, which contains 5 columns, labeled 1 through 5 in Figure 5.16.

  1. Metric. The coverage metric which the excluded target measures.

  2. Item. The name of the immediate item (block, state, transition, etc.) where the target is located.

  3. Target. A description of the target (e.g., Condition 1 true).

  4. Status. The status of the target, which has three possible values:

    excluded

    The target is excluded without monitoring.

    [excluded]

    The target is excluded and monitored by assertion, and the target has not been covered.

    [covered]

    The target is excluded and monitored by assertion, and the target is covered.

  5. System. The path to the subsystem where the target is located.

  6. Model. The referenced model whose .rsi file excludes the target. (Empty for targets excluded in the current .rsi file.)

Most targets are added to the Excluded Coverage Targets pane by right-clicking on them in the main panel and selecting Track Coverage. Boundary, condition, decision, lookup table element, MC/DC, and MCC targets are added to the pane by first right-clicking and selecting View coverage details, and then right-clicking on the target within the Coverage Details dialog and selecting Track Coverage.

The status of a target listed in the Excluded Coverage Targets pane can be edited when Simulator is enabled by left-clicking on the row containing the target, then right-clicking in the Status column and selecting Edit… Note that enabling coverage tracking for the target will cause it to disappear from the Excluded Coverage Targets pane, and currently the only way to undo such a change is to find the target in the main panel and exclude it from coverage a second time. See Excluding Coverage Targets for details.

Double-clicking on any row of the Excluded Coverage Targets pane will cause the corresponding target to be highlighted in the main panel with a yellow flashing background for a few seconds.

Clicking on the header for any column will sort the targets by the entries in that column. Clicking a second time on the same column header will reverse the order.

5.12. Validator Objectives Pane#

Reactis Validator gives the user a set of tools to check whether a model captures the intended behavior. User-defined targets and virtual sources are used to specify scenarios that should be tested. Assertions can be used to check that a model responds to tests as expected. Collectively, these three types of virtual instrumentation are called Validator objectives.

The Validator Objectives pane of the Info File Editor enables you to view and manipulate the Validator objectives that have been inserted into a model. Each objective has a row in the pane with entries for the following columns:

Type

Assertion, user-defined target, or virtual source.

Status

This field reports different information depending on the type of the objective and whether Simulator is currently on or off. When Simulator is off, this column simply reports whether the objective is enabled, disabled, or orphaned. An objective is orphaned when the subsystem in which it is located is removed from the model or the path to the subsystem changes (e.g. A/B/C changes to A/D/C). Orphaned objectives remain visible in the Validator Objectives pane to facilitate their reinsertion into a model. To reinsert an objective simply select the row of the objective, then select Edit > Copy, and then in the main panel of Reactis right-click at the appropriate location and select paste. When Simulator is on, for non-orphaned objectives, the column reports whether assertions have been violated and user-defined targets have been covered.

Objective Type

Simulator off

Simulator on

Assertion

enabled/disabled/orphaned

okay/violated/orphaned

User-Defined Target

enabled/disabled/orphaned

covered/not covered/orphaned

Virtual Source

enabled/disabled/orphaned

enabled/disabled/orphaned
Name

Name of the objective.

System

Location of the objective in the model.

Double-clicking on a row highlights the corresponding objective in the main panel. Objectives may be edited or removed by selecting the row and using the Edit menu or right-clicking on the row.

You can specify whether the coverage targets within diagram-based Validator Objectives should be tracked using the Track coverage for contents of Validator Objectives setting in the Coverage Metrics pane. The objective itself (assertion or UDT) is tracked even when the targets within the objective are not.

5.13. C Code Pane#

When using the Reactis for C Plugin, this pane displays a list of places in a model that reference C code (C Caller blocks, S-Functions, and Stateflow custom code) and gives the user the ability to adjust the settings for white-box analysis of each S-Function. Please see Reactis for C Plugin for details.

5.14. External EML Functions Pane#

When using the Reactis for EML Plugin, this pane lets you specify a list of external EML functions (stored outside the model in .m files) that are used by the model. Coverage targets within the external functions will be tracked and targeted by Reactis Tester. You can also step into the external functions when running the model in Reactis Simulator.

5.15. Callbacks Pane#

The Callbacks pane gives users a way to specify fragments of MATLAB code that Reactis will run before or after loading a model in Simulink. Note that these callbacks are distinct from those maintained by Simulink.

5.16. Search Path Pane#

This pane gives users a way to specify a model-specific search path. This path is prepended to the global search path to specify the list of folders (for the current model) in which Reactis will search for files such as Simulink model libraries (.slx), MATLAB scripts (.m), and S-Functions (.dll, .mexw32, .m).

The model-specific path is manipulated in exactly the same manner as the global path is manipulated from the Path pane of the Reactis Global Settings dialog. For a description of how the operations work, please see Path Global Settings. Note that the one difference between the two path panes is that the Import button of the model-specific pane first loads the model in MATLAB before importing the MATLAB path. This causes any pathdef.m or setup.m files in the model folder to execute. Any model callbacks (pre-load, post-load functions) will also be executed, and perhaps modify the MATLAB path, prior to importing it into Reactis. The net result is that the imported MATLAB path is the one that results after the model is loaded in MATLAB.

5.17. File Dependencies Pane#

Models may contain references to items defined in auxiliary .m files. To enhance performance, Reactis computes and stores information about models when they are loaded in order to speed up subsequent loads[4]. If a .m file that a model depends on changes, the stored information needs to be re-computed. The dependency information given in this pane tells Reactis which .m files, when changed, should trigger this re-computation. Any changes to these files will cause any preprocessing information that Reactis has cached about the model to be discarded and recomputed. Note that .slx files need not be listed here; the .slx files on which a model depends are inferred automatically.

Note that users should include all .m files that their model depends on, including those referenced from:

  • Any Simulink model callback or block callback that is executed when loading or running the model (PreLoadFcn, PostLoadFcn, InitFcn, StartFcn).

  • A “startup.m” file located in the folder where the model file is located.

  • The “Callbacks” tab of the Reactis Info File Editor.