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.
- Inport Types.
- 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 test points during testing.
- Outport Tolerances.
- 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.
- 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 Inport Types, Configuration
Variables, Test Points, Outport Tolerances,
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.
-
Inport Types 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 Inport Types 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.
- Outport Tolerances Pane
-
-
Synchronize, Inports, Outports and Test Points
- See description
above of this menu item for Inport Types 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. |
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 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
Inport Types pane and the Outport Tolerances
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. |
5.4 Inport Types 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 Inport Types 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 Inport Types 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.
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. |
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 Inport Types 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.
- 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. - 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 or single , 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.
- 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.
- When you are satisfied with the type you have
constructed click the Ok button to update type and dismiss
the Type Editor dialog.
- 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. -
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 == 0 | Simulation time is zero. |
(t > 1) && (t < 1.5) | Simulation time is greater than 1 and less than 1.5. |
- Buttons used to add, edit, remove or
reorder elements of the condition list.
- 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.
- 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.
- Selecting this radio button indicates
that all values from the base type should be included in the TUC.
- Selecting this radio button indicates that only a subrange
of values from the base type should be included in the TUC.
- When the Subrange of base type
radio button is selected, this entry box enables you to specify a
lower bound for the subrange.
- When the Subrange of base type
radio button is selected, this entry box enables you to specify
an upper bound for the subrange.
- If the Subrange of base
type radio button is selected and the TUC has a base type of
double or single , then this check box may be checked
in order to specify a resolution for the TUC. - 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.
- 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.
- The entries in this column specify the values in the TUC.
- 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.
- 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. |
- 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.
- The TUC has no delta constraint.
- The TUC has the delta constraint indicated by window items
18 and 19.
- 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
v2 − v1
>= min . - 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
v2 − v1
<= max . - View help on the type editor dialog.
- 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.
- 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.
- 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:
-
Select one element and configure it as desired.
- Click the Copy button.
- 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.
- 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. |
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. |
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 | : | sfix bitsSlopeBias |
| | | ufix bitsSlopeBias |
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
_S fpDecimal such that slope = fpDecimal
- as
_F fpDecimal_E fpInt
such that slope = fpDecimal×2fpInt
- bias
- is a decimal specified as
_B fpDecimal.
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{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
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. |
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 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 ≤ 10 | in | Slow Initial Speed, |
40 ≤ InitialSpeed ≤ 50 | in | Fast Initial Speed, and |
0 ≤ InitialSpeed ≤ 50 | in | Any 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
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. |
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:
-
selecting a row in the pane, and
- selecting Edit > Remove from the Info File
Editor menu or clicking the Remove (
) 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: -
When checked, import test points defined in Simulink by right-clicking on a signal
line, selecting “Signal Properties” and checking the “Test Point” box.
- When checked, import test points defined in Stateflow by checking the “Test Point”
box in the variable’s properties dialog in Stateflow.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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. |
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. |
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 selecting menu item Edit > Edit....
Figure 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:
-
The name of the test point. This need not match the underlying signal or variable name.
- Clicking the Highlight button will cause the test point to be displayed
in the main Reactis panel and be highlighted by flashing yellow.
- The location of the test point within the model hierarchy.
- 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.
- 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.
-
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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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> . - Display help for the Test Point Properties Editor.
- Save any changes and close the editor.
- 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 Outport Tolerances
Figure 5.13: The Reactis Info File Editor with the
Outport Tolerances 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 and step.
The Outport Tolerances pane, shown in Figure 5.13,
lets you specify a tolerance for
each outport to be used in these comparisons. The Outport Tolerances pane
displays five properties for each outport, labeled one through five in
Figure 5.13: -
The port number.
- The port name.
- The tolerance method (see Section 5.7.1).
- The relative tolerance value. If the method does
not use relative tolerance, this will be blank.
- The absolute tolerance value. If the method does
not use absolute tolerance, this will be blank.
The tolerance for a port is 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 tolerance 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 tolerance editor dialog is explained in Section 5.8.
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 |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%, 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.8 The Tolerance Editor Dialog
Figure 5.14: The dialog for specifying the tolerance to use
when comparing computed and test suite values. 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. |
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: -
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.
- 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.
- 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.
- This button opens the help dialog for the tolerance editor dialog.
- This button accepts the displayed tolerance value and closes the tolerance
editor dialog.
- This button ignores any changes made to the tolerance and closes the tolerance editor
dialog.
5.9 General
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.
- 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.
- 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. - Use new fixed-step sample time computation.
- Enabling this option
will slightly change the way Reactis computes time values for models
configured to use the fixed-step solver, especially those with sample times
that have poor floating point representations such as 0.1, 0.01 or similar.
The new behavior makes the rounding errors in the Reactis sample time
computations line up better with Simulink’s rounding errors for such models.
Note that after enabling this option, test suites created with the legacy
approach employed prior to Reactis V2010 can show different behavior in
cases where a small change in sample time can cause the model to
significantly change its execution.
- 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.
5.10 Error Checking
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 > Inport Types 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 = 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
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. |
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.11 Coverage Metrics
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.
- 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.12 Excluded Coverage Targets
Figure 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. -
Metric.
The coverage metric which the excluded target measures.
- Item.
The name of the immediate item (block, state, transition, etc.) where the
target is located.
- Target.
A description of the target (e.g., Condition 1 true).
- 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.
- 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.13 Validator Objectives
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 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.14 C Code
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.15 External EML Functions
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.16 Callbacks
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.17 Search Path
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 (.mdl), 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.18 File Dependencies
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.
|
|