Reactis User's Guide   Contents  |  Index
 Chapters:  1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | A | B | C

Chapter 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 a .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 is 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 which workspace or data dictionary data items will be used as configuration variables.
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 rsifile named differently may be associated with a model by loading the model in Reactis and selecting File > Select Info File...

5.1  Menus

The menu entries of the Info File Editor are described in this section. Note, that the set of enabled entries and the meaning of some entries vary depending on which pane is currently displayed.

File menu.
The File menu contains the following entries.
Save
Save the current .rsi file.
Save As...
Rename and save the current .rsi file.
Exit.
Exit Info File Editor.
Edit menu.
The Edit menu contains the following entries. Entries are enabled or disabled according to the currently selected pane.
Undo.
Undo the last edit operation.
Redo.
Redo the last undone edit operation.
Cut.
Delete the currently selected item and place it into the clipboard.
Copy.
Copy the selected item into the clipboard.
Paste.
Paste the item in the clipboard into the selected location.
Add...
When the Configuration Variables pane is selected, this menu item is enabled and allows you to add a new configuration variable. When the menu item is selected you are presented with a list of variables from which to chose. The elements of the list are:
  • Variables initialized within the Simulink or Reactis pre-load callback of the model, e.g. by executing .m file script(s) or loading .mat file(s).
  • Variables defined in a Simulink data dictionary attached to the model. Data dictionary variables are shown as [dictionaryname].[variablename].

When the External EML Functions pane is selected, this menu item is enabled and lets you add an external EML function that resides in an .m file and is called by EML code within the model (e.g a MATLAB Function block).

When the Search Path pane is selected, this menu item is enabled and allows you to add an entry to the model-specific search path.

When the File Dependencies pane is selected, this menu item is enabled and allows you to add a new file to the list of files on which the model depends. When the menu item is selected, a file selection dialog appears, allowing you to specify a file.

Edit...
Edit the currently selected item. The panes for which this menu entry is enabled include Inports, Configuration Variables, Test Points, Outports, Validator Objectives, C Code, and Search Path. In the case of inport types and configuration variables the dialog shown in Figure 5.4 is used for editing. The edit dialogs for Validator objectives and C code are described in Chapters 9 and 16 respectively. The entry is disabled when one of the other panes is selected.
Edit Text...
Edit the type of the currently selected port or configuration variable by directly entering a textual type specification according to the syntax defined in Section 5.4.2. The entry is disabled when one of the other panes is selected.
Remove
Remove the currently selected item.
Tools.
The availability and contents of this menu vary depending on the currently displayed pane. The panes that offer a Tools menu are below along with the entries available with each pane.
Inports Pane
Synchronize, Inports, Outports and Test Points
The current .rsi file is modified as follows. Inports, outports, or test points deleted from the .slx file will have their entry in the .rsi file removed; new inports, outports, or test points in the .slx file will have entries introduced in the .rsi file with the full range of the base data type. If an item exists in both the .slx file and .rsi file and the base data type differs between the two, Reactis will display a dialog to resolve the type conflict as shown in Figure 5.1. If minimum or maximum values for the inport are given in the model then those are also imported. Reactis recognizes the following settings:
  • Minimum/Maximum set in the input port’s properties dialog.
  • Minimum/Maximum set via a Simulink.Signal object attached to the signal line connected to the input port.
  • Minimum/Maximum set for bus elements in a Simulink.Bus object that is set as the data type for the input port.
Synchronize Inport Ranges with TargetLink Data Dictionary
Each inport type in the .rsi file is constrained to match the corresponding TargetLink production code type and Min/Max limits. If the TargetLink type is numeric, the range of the inport type is constrained to match the TargetLink Min/Max limits. If the TargetLink type is integer or fixed-point, the resolution of the inport type is set to match the resolution of the TargetLink type. If the TargetLink type is Boolean, the inport type is constrained to the set {0,1}.
Reset to Defaults
Revert the type of each port to the type inferred for it in the .slx file (i.e. drop any added constraints such as ranges, enumerated sets, probabilities, delta constraints, etc.).
Test Points Pane
Synchronize, Inports, Outports and Test Points
See description above of this menu item for Inports Pane.
Import from Simulink
If the model includes any signals specified as test points within Simulink, then import these Simulink test points as Reactis test points. It is also possible to import Simulink signals with a Simulink.Signal object attached as Reactis test points.
Outports Pane
Synchronize, Inports, Outports and Test Points
See description above of this menu item for Inports Pane.
Reset Outports to Defaults
Revert each outport tolerance to Inherit.
General, Error Checking, Coverage Metrics, C Code Panes
Reset to Defaults
Reset the model-specific settings in the current pane to the values specified in the Default Model-Specific Settings dialog (invoked via File > Default Model-Specific Settings).
Help menu.

Contents.
Go to the table of contents in the documentation.
Index.
Go to the index in the documentation.
Info File Editor.
Display Info File Editor help.

Figure 5.1: The type conflict resolution dialog.
images/typeConflict_web.png

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.

images/saveBtn_web.png Save any changes to the currently loaded .rsi file.
images/addBtn_web.png Equivalent to menu item Edit > Add....
images/editBtn_web.png Equivalent to menu item Edit > Edit....
images/removeBtn_web.png Equivalent to menu item Edit > Remove.
images/cutBtn_web.png Cut the selected item and copy it to the clipboard.
images/copyBtn_web.png Copy the selected item into the clipboard.
images/pasteBtn_web.png Paste the item in the clipboard into the selected row.
images/undoBtn_web.png Undo last editing operation.
images/redoBtn_web.png Redo last undone edit operation.
images/harnessSelector_web.png Select harness.
images/helpBtn_web.png 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 current harness. 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.


Figure 5.2: The Reactis Info File Editor with the Harness pane selected.
images/rsifeHarnessPane_web.png

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.


Figure 5.3: The Reactis Info File Editor with the Inports pane selected.
images/rsifeInportPane_web.png

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.


Figure 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.
images/typeEditorA_web.png

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 Section 5.4.2 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 v1 and v2 are values for such a port in consecutive simulation steps, then v1 + min <= v2 <= v1 + 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 Section 5.4.2. The following table gives some sample conditions:

    t == 0Simulation 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 Section 5.4.2) 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 Section 5.4.2 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.

    Figure 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.
    images/addEnum_web.png

  15. 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.
  16. The TUC has no delta constraint.
  17. The TUC has the delta constraint indicated by window items 18 and 19.
  18. The value for an inport with the TUC may change by no less than the value specified here. If v1 and v2 are the values of the inport in consecutive simulation steps then v2v1 >= min .
  19. The value for an inport with the TUC may change by no more than the value specified here. If v1 and v2 are the values of the inport in consecutive simulation steps then v2v1 <= max .
  20. View help on the type editor dialog.
  21. 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.
  22. 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.
  23. Apply any changes made to the TUC and update the text in window item 3. 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.

Figure 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.
images/typeEditorArray_web.png

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.


Figure 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.
images/typeEditorBus_web.png

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 ]
 |floatType [ min : step : max ]
 |floatType [ min : step : max ] delta [ min, max ]
 |vectorType
 |busType
 |if timeExpr then rsiType1 else rsiType2
          vectorType:<| rsiType1 * rsiType2 * ... * rsiTypen |>
 |<| rsiType ^ int |>
          busType:{ fieldName1 : rsiType1 , ... , fieldNamem : rsiTypem }
 |busName -> { fieldName1 : rsiType1 , ... , fieldNamem : rsiTypem }
          val:value
 |value : weight
timeExpr:t
 |timeVal
 |timeExpr1     relOp     timeExpr2
 |timeExpr1     logOp     timeExpr2
 |!    timeExpr
 |(   timeExpr   )

The variables/symbols 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.
  • relOp is a relational operator: <, <=, ==, !=, >, >= .
  • logOp 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 rsiTypei 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 = fpDecimal×2fpInt
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 TypeValues 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{u1, …, un}) the probability weights in the ui 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 x is assigned the type t{ v1:w1, v2:w2, ..., vn:wn}, then the probability of each value in the type being assigned to x 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 x 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 x has type t delta [l,u] and the current value of x is v1 then in the next simulation step the new value, v2, of x must satisfy: v1 + l <= v2 <= 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 Section 5.4.1. 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 Section 14.2.1.

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.


Figure 5.8: The Configuration Variables pane of the Reactis Info File Editor.
images/rsifeConfigVarPane_web.png

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:

ConfigVarSet1ConfigVarSetn.
Selecting ConfigVarSeti switches to the configuration variable set named ConfigVarSeti. In Figure 5.8 the configuration variable sets are named Slow Initial Speed, Fast Initial Speed, and All Initial Speeds. 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.

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 ≤ 10inSlow Initial Speed,
40 ≤ InitialSpeed ≤ 50inFast Initial Speed, and
0 ≤ InitialSpeed ≤ 50inAny Initial Speed.

When generating tests at the start of each new test, Reactis Tester will randomly select one of the enabled configuration variable sets and then select 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.


Figure 5.9: Visualization in the Reactis main panel of test points located in Simulink and Stateflow portions of a model.
images/testPointVisualization_web.png

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 ( images/removeBtn_web.png ) button in the Info File Editor toolbar.

5.6.2  Importing Test Points from a Simulink model

Reactis allows you to import test points defined in the Simulink model by selecting Tools > Import from Simulink from within the Test Points pane on the Info File Editor. Selecting that item brings up the dialog in Figure 5.10. The labeled items of Figure 5.10 configure the import parameters as follows:

  1. When checked, import test points defined in Simulink by right-clicking on a signal line, selecting “Signal Properties” and checking the “Test Point” box.
  2. When checked, import test points defined in Stateflow by checking the “Test Point” box in the variable’s properties dialog in Stateflow.
  3. When checked, import a Simulink signal as a Reactis test point if “Signal name must resolve to Simulink signal object” is checked in the “Signal Properties” dialog.
  4. When checked, import a Stateflow variable as a Reactis test point if “Data name must resolve to Simulink signal object” is checked in the variable’s properties dialog in Stateflow.
  5. If not checked, Reactis uses the name of the block from which the signal emerges as the test point name. If checked, Reactis uses the name of the Simulink.signal object as the test point name.
  6. If either of the “must resolve to Simulink.signal object” options is checked, checking this box will assign the minimum and maximum ranges from the Simulink.signal object to the imported test point.
  7. If the “Import Min/Max range...” option is checked, checking this box will set up the imported test point to track boundary coverage for the imported minimum and maximum.
  8. If the “Import Min/Max range...” option is checked, checking this box will set up the imported test point to create an assertion that will be violated if the value of the test point exceeds be imported maximum or minimum.
  9. If the “Import Min/Max range...” option is checked, checking this box will set up the imported test point to produce either a warning or error message if its value exceeds the imported minimum or maximum.
  10. If the “Check test point values against range” option is checked, selecting this will produce a warning message and continue test case generation or simulation if the test point value exceeds the imported minimum or maximum.
  11. If the “Check test point values against range” option is checked, selecting this will produce an error message and stop test case generation or simulation if the test point value exceeds the imported minimum or maximum.

Figure 5.10: The Test Point inport dialog.
images/testPointImport_web.png

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


Figure 5.11: The Test Points pane.
images/testPointsPane_web.png

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 ( images/editBtn_web.png ) button in the toolbar, or
    • Select a test point row, then selecting menu item Edit > Edit....

Figure 5.12: The Test Point Properties Editor for configuring test point behavior.
images/testPointProperties_web.png

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 Section 5.7.1.
  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 in general see Section 6.3.2.1.
  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 Section 5.4.1 for instructions on operating the type editor 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 test point intervals for the test point.
  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.

Simulink Test Points in a model can be imported into Reactis by selecting Info File Editor menu item Tools > Import from Simulink.

5.7  Outports Pane


Figure 5.13: The Reactis Info File Editor with the Outports pane selected.
images/rsifeOutportTolerances_web.png

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 and step. 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. See Section 6.3.3 for a full description of interval coverage.

The Outports pane displays five properties for each outport, labeled one through five in Figure 5.13:

  1. The port number.
  2. The port name.
  3. The tolerance method (see Section 5.7.1).
  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 defined for the outport
  7. 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. The Outport Propertieseditor dialog is explained in Section 5.7.2.

5.7.1  Tolerance Methods

There are five methods for computing the tolerance: Absolute, Relative, Max, and 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 |xy| > є.

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:

•    |xy| > є × | x |whenx ≠ 0
•    |xy| > є × | y |wheny ≠ 0
•    |xy| > є2whenx = 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%, and a relative tolerance of 1 will allow the model value to be at most twice the test value.

The max tolerance method uses both a relative and absolute tolerance. A difference is flagged only 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:

  • When highlighting tolerances and differences within a Difference Scope (see Section 7.5.5)
  • When executing a test suite generated by Reactis within Simulink using the rsRunTests utility (see Section 12.2.1)

5.7.2  The Outport Properties Editor Dialog


Figure 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 for port speed, which means that differences which are less than or equal to 0.1 will be ignored.
images/toleranceEditorA_web.png

Tolerances are specified via the tolerance editor dialog, which is shown in Figure 5.14. The labeled items in Figure 5.14 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 Section 5.7.1.
  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 Section 6.3.3.
  5. This section lists the intervals for interval coverage tracking. See Section 6.3.3.
  6. This button opens the help dialog for the tolerance editor dialog.
  7. This button accepts the displayed tolerance value and closes the tolerance editor dialog.
  8. This button ignores any changes made to the tolerance and closes the tolerance editor 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. Please see Section 15.1 for a description of this optimization. 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 Section 7.5.6). 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 conditiona input branch execution.
For all Simulink signals
Show “[not computed]” for any signal that has not (yet) been computed (some exceptions apply, see Section 7.5.6).
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.
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 Chapter 6.
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 worspace 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...).
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]
    

and let range = maxmin. 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 the 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 minor differences for floating point values due to small rounding errors are common, a tolerance can be specified here that will be used when comparing floating point values. 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 Sections 5.7 and 5.6.

In Simulink and Stateflow:

On integer overflow.
Integer overflow can occur during the evaluation of some blocks. These blocks typically have a SaturateOnIntegerOverflow parameter. When set to ’on’, this parameter specifies that the block should evaluate to the maximum value for the type on overflow and the minimum value on underflow. When SaturateOnIntegerOverflow is set to ’off’ Simulink uses the model parameter IntegerOverflowMsg 1 to determine how overflows are handled. There are three possible settings:
None.
Return the wrapped around value 2.
Warning.
Return the wrapped around value but also issue a warning.
Error.
Raise an error and halt simulation.

Reactis gives users a way to override the IntegerOverflowMsg parameter with the ’On Integer Overflow’ setting which may have one of three possible values:

Wrap over.
Return the wrapped around value.
Wrap over and produce warning.
Return the wrapped around value but also issue a warning.
Produce error.
Raise an error and halt simulation or test-generation. In the case of interrupted test-generation, Reactis Tester returns a test suite that includes a test leading to the overflow.
Inherit from model settings.
Use the IntegerOverflowMsg setting from the model; however, Reactis does not currently generate warnings. When IntegerOverflowMsg is set to ’warning’, Reactis behaves as if it is set to ’none’.

When detecting Inf or NaN values.
Inf (Infinity) and NaN (not-a-number) are values that can arise during floating point computations as a model executes. These result from unexpected inputs to a mathematical operation; for example, dividing by zero or taking the square root of a negative number. Often, these values indicate a modeling error that should be corrected. To help detect such errors, Simulink offers a setting to specify what happens if such an Inf or Nan value is detected. 3 There are three possible settings:
none.
Continue with simulation, possibly propagating the Inf/NaN value through the model.
warning.
Continue with simulation, but produce a warning.
error.
Raise an error and halt simulation.

Reactis gives the user a way to override the Simulink Inf/NaN behavior. The Reactis When detecting Inf or NaN values setting may have one of three possible values:

No action.
Continue simulation or test-generation.
Produce warning.
Continue simulation or test-generation, but also issue a warning.
Produce error.
Raise an error and halt simulation or test-generation. In the case of interrupted test-generation, Reactis Tester returns a test suite that includes a test leading to the Inf/NaN.
Inherit from model settings.
Use the Simulink setting from the model; however, Reactis does not currently generate warnings. When the Simulink setting is ’warning’, Reactis behaves as if it is set to ’none’.
When detecting subnormal floating-point values.
Configure what happens if Reactis detects a subnormal floating-point value:
No action.
Continue simulation or test-generation.
Produce warning.
Continue simulation or test-generation, but also issue a warning.
Produce error.
Raise an error and halt simulation or test-generation.
When detecting conversion of Inf or NaN values to integer.

Configure what happens if a model attempts to convert an Inf or NaN value to an integer as follows:

No action.
Emulate the Simulink/Stateflow behavior: for fixed-point values convert to the value that has a stored integer of zero, otherwise convert to zero.
Produce warning.
Emulate the Simulink/Stateflow behavior, but also produce a warning.
Produce error.
Raise an error if such a conversion is attempted.
Inherit from “When detecting Inf or NaN values”.
Inherit from the previous setting.
When shifting by more than word size.

Simulink includes a Shift block and Stateflow includes a shift function. If either operation results in a shift larger than the word size you have specified for your model, most likely this indicates a modeling error. This setting lets you direct Reactis to flag such illegal shift operations as follows:

No action.
Do not flag shifts larger than the word size.
Produce warning.
Generate a warning if a shift larger than the word size is detected.
Produce error.
Raise an error if a shift larger than the word size is detected.
Inherit from model (error otherwise).
For Simulink Shift blocks respond to a shift larger than the word size as configured in the block. For Stateflow raise an error.
When comparing enumerated values of different types.

In Stateflow, comparing two expressions of different enumerated types is allowed. However, allowing such comparisons can result in unexpected behavior. Stateflow compares the underlying integer value of the enumerated types in that case, which may be different from the literal enumeration names. In many cases such comparisons are the result of typos or copy/paste errors and are not intentional. Reactis by default flags such comparisons as errors but in cases where they are intentional this setting allows you to specify the desired behavior:

No action.
Do not flag comparisons of different enumerated types as errors.
Produce warning.
Generate a warning if a comparison of different enumerated types is detected.
Produce error.
Raise an error if a comparison of different enumerated types is detected.
When Detecting Stateflow outport merge.
This setting configures Reactis to issue a warning or error when a model contains a particular configuration of Stateflow charts and merge blocks that can yield unexpected behavior. Note that even for models with this unexpected behavior, Reactis implements the same semantics as the MathWorks Simulink / Stateflow engine.

Figure 5.15: Unexpected back-propagation of a value through an outport of a Stateflow diagram. In this example, the value output by the digital clock is propagated back into Chart2 via out1. The value is then output on out2, yielding the matching scopes for the clock and out2.
images/sfOutportMerge_web.png

We now describe how the unexpected behavior can occur. If an outport of a Stateflow chart is directly connected to a merge block and the outport is read within the chart, then an unexpected back-propagation of values from outside the chart into the chart via the outport can occur. This setting enables you to configure Reactis to produce a warning or error when such a construct is detected. The example in Figure 5.15 shows a model in which this back-propagation occurs.

When detecting undirected local event broadcast in Stateflow.
Undirected local event broadcasts can cause infinite recursion in a Stateflow chart. This setting configures Reactis to produce a warning or error when an undirected local event broadcast occurs.
When detecting multiple trigger event outputs.
If an edge-triggered output event is triggered multiple times in a single step then the events are queued and output during subsequent simulation steps. This can cause the chart’s output to change in a step where no action occurs within the chart. The When detecting multiple trigger event outputs setting configures Reactis to produce a warning or error when an edge-triggered output event is triggered multiple times during a single step.
Stateflow infinite loop timeout (seconds).
Maximum time for Reactis to compute a simulation step. If the computation of a simulation step takes longer, Reactis assumes there is an infinite loop; the simulation is then terminated and an error message printed.

In C Code:

The settings in this section are enabled when using the Reactis for C Plugin (which is enabled from the Reactis for C pane of the Global Settings dialog). For a description of these settings, see Section 16.2.

5.10  Coverage Metrics Pane

The different coverage metrics supported by Reactis are defined in Chapter 6. The model-specific settings in the coverage pane let you enable or disable each metric. 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...). 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 Section 6.2.4 for a description of how these settings configure what constitutes CSEPT targets.
C-specific Decision Metric
See Section 16.5 for an explanation.
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 Section 6.3.1.
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 Section 6.3.2.2, 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 Section 6.3.2.2. To generate the smallest increment representable 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 Section 6.3.2.2.
Boundary coverage for integer saturation.
When enabled, targets are created for blocks which are set to saturate on integer overflow. See Section 6.3.2.3 for details.
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 Section 6.3.2.3 for details.
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


Figure 5.16: The Reactis Info File Editor with the Excluded Coverage Targets pane selected.
images/rsifeExcludedTargets_web.png

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.

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 Section 6.5 for details.

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

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

5.12  Validator Objectives Pane

Chapter 9 describes the Validator component of 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.

Table 5.1: Possible values of the Status column.

Objective TypeSimulator offSimulator on
Assertionenabled/disabled/orphanedokay/violated/orphaned
User-Defined Targetenabled/disabled/orphanedcovered/not covered/orphaned
Virtual Sourceenabled/disabled/orphanedenabled/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 (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 Chapter 16 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 Section 4.8.5. 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

In general, 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.

1
To set the IntegerOverflowMsg parameter, from the Simulink main menu select Simulation > Configuration Parameters. In the resulting dialog, select the ’Data Validity’ item from group ’Diagnostics’ and then set via ’detect overflow’.
2
Wrapping around works in the usual fashion. Incrementing the maximum value in a type by one yields the minimum value in the type. Decrementing the minimum value in a type yields the maximum value in the type.
3
To set the Inf/Nan behavior in Simulink, from the Simulink main window select Simulation > Configuration Parameters. In the resulting dialog, select the ’Data Validity’ item from group ’Diagnostics’ and then set behavior via ’Inf or NaN block output’.
4
This caching feature may be disabled from the General pane of the Info File Editor by unchecking the check box Create and use cache files.