Chapter 3 Getting Started with Reactis

This chapter provides a quick overview of Reactis. It contains a brief description of each main component of the tool suite in the form of an extended “guided-tour” of the different features of the tool suite. Each “stop” in the tour is indicated by a §. The tour uses as a running example a simple Simulink / Stateflow model of an automobile cruise control that is included in the Reactis distribution.

3.1 A Note on Model Preparation

The cruise-control example included with the distribution does not require any special processing before you run Reactis on it; you may load the file immediately and start the guided tour. However, there is an important preparation step that you should undertake when you are building models for use with Reactis. This section describes this preparatory step and discusses the Simulink operations needed to perform it.

Reactis supports a large portion of the discrete-time subset of Simulink and Stateflow. As it processes a Simulink / Stateflow model, it also interacts with MATLAB in order to evaluate MATLAB expressions, including references to workspace data items, that a model may contain.

In order for Reactis to process a model, the associated .mdl file must contain links to all MATLAB files used in the model. This may be done using Simulink’s preload-function (PreLoadFcn) facility. Chapter 14 addresses this, and other model-preparation issues, in more detail. In general, including these links in your .mdl file is good modeling practice, since once these links are established a .mdl file may also be loaded into Simulink without having to hand-load the relevant .m files in MATLAB first.

This process of associating .m files with a .mdl file typically needs to be done only once, although it should be redone if there is a change in the set of .m files used by a .mdl file. Modifying an .m file that is already linked to a .mdl file does not require updating the links in the .mdl file.

Below we describe how the relevant links were established in the cruise-control model file included in the Reactis release. In that example the MATLAB file cruise_constants.m defines two workspace variables that are used in the Simulink / Stateflow model file cruise.mdl. The cruise_constants.m file was attached to cruise.mdl using the following steps.

Load cruise.mdl into Simulink.
In the Simulink window, select the File -> Model Properties menu item.
In the resulting dialog, select the Callbacks tab.
In the Model preload function section enter cruise_constants (note that the .m suffix is not included).
Save the model.

This saved cruise.mdl file is distributed with Reactis, so you do not need to undertake the above steps yourself in order to load and process this file in Reactis. The above steps are cited only for illustrative purposes.

3.2 Reactis Top Level

Figure 3.1: The Reactis window.

The Reactis top-level window contains menus and a tool bar for launching applications on Simulink / Stateflow models. Reactis is invoked as follows.

§1 Select Start -> Programs -> Reactis V2008 -> Reactis from the Windows Start menu (or double-click on the desktop shortcut if you installed one).

You now see a Reactis window like the one as shown in Figure 3.1. A model may be selected for analysis as follows.

§2 Click the (file open) button located at the leftmost position on the tool bar. Then use the resulting file-selection dialog to choose the file cruise.mdl from the examples folder of the Reactis distribution.

Loading the model causes the top-level window to change as shown in Figure 3.2. The panel to the right shows the top-level Simulink diagram of the model; the panel to the left shows the model hierarchy. In addition, the title bar now reports the model currently loaded, namely cruise.mdl, and the Reactis info file (.rsi file ) cruise.rsi that contains auxiliary model information used by Reactis. The info file is explained in more detail in the next section (Section 3.3).

Nodes in the model hierarchy may be “opened” as follows.

§3 Click on the + to the left of CruiseMain in the model hierarchy panel to display its subsystems.

You may click on the + next to subsystems to explore their structure. Subsystems are also tagged with icons indicating whether they are Simulink (SL), Stateflow ( SF), Validator objectives ( , ), or configuration variables (•). Validator objectives and configuration variables are discussed in more detail later. Additionally, if you are using the Reactis for C Plugin (see Chapter 16 for details), then you may also see C source files (C), C libraries (LIB), and S-Functions (FN) in the hierarchy panel.

Figure 3.2: Reactis after loading cruise.mdl.

3.3 The Info File Editor

Reactis does not modify the .mdl file for a model. Instead the tool stores model-specific information that it requires in a .rsi file. The primary way for you to view and edit the data in these files is via the Reactis Info File Editor, as described briefly in this section and in more detail in Chapter 5.

The next stop in the guided tour explains how this editor may be invoked on cruise.rsi.

§4 Select the Edit -> Port Types... menu item.

This starts the Reactis Info File Editor, as shown in Figure 3.3. Note that the contents of the .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.

Figure 3.3: The Reactis Info File Editor.

.rsi files contain directives that specify the following.

Types for top-level inports.: The type information is used by Reactis to constrain the set of values fed into top-level inports during simulation, test-case generation, and model validation.
Types for configuration variables.: Configuration variables are workspace data items tagged by the user to be changed in between tests in a test suite (but not during a test).
Test Points.: Test Points are internal signals tagged by the user to be stored in test suites.
Custom callbacks.: These are 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.
Model-specific search path.: The model-specific search 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).
Dependencies.: This specifies the list of files on which the current model depends. The file-dependency information enables Reactis to track changes in auxiliary model files so that information obtained from them for the purposes of processing the current model may be kept up to date. Typically, files listed here would include any .m files loaded as a result of executing the current model’s preload function. For example, a .m file mentioned in the preload function might itself load another .m file; this second .m file (along with the first) should be listed as a dependency in order to ensure that Reactis behaves properly should this .m file change.

§5 To modify the type for a port, select the appropriate row, then right-click on it and select Edit Type, and make the desired change in the resulting dialog. Save the change and close the type editor by clicking Ok or close without saving by clicking Cancel.

The types that may be specified are the base Simulink / Stateflow types extended with notations to define ranges, subsets and resolutions, and to constrain the allowable changes in value from one simulation step to the next. More precisely, acceptable types can have the following basic forms.

Complete range of base type:: By default the type associated with an inport is the Simulink / Stateflow base type inferred from the model. Allowed base types include: int8, int16, int32, uint8, uint16, uint32, boolean, single, double, sfix*, and ufix*.
Subrange of base type:: t[i, j], where t is a Simulink / Stateflow base type, and i and j are elements of type t, with i being a lower bound and j an upper bound.
Subrange with resolution type:: t [i:j:k], where t is either double or single, i is a lower bound, j is a resolution, and k is an upper bound; all of i, j and k must be of type t. The allowed values that a variable of this type may have are of form i + n × j, where n is a positive integer such that i + n × j ≤ k. In other words, each value that a variable of this type may assume must fall between i and k, inclusive, and differ from i by some integer multiple of j.
Set of specific values:: t{ e₁, … e_n }, where t is a base type and e₁, … e_n are either elements of type t, or expressions of form v:w, where v is an element of type t and w, a positive integer, is a probability weight. These weights may be used to influence the relative likelihood that Reactis will select a particular value when it needs to select a value randomly to assign to a variable having an enumeration type. If the probability weight is omitted it is assumed to be “1”. For example, an inport having type uint{0:1, 1:3} would get the value 0 in 25% of random simulation steps and the value 1 in 75% of random simulation steps, on average. See Chapter 5 for more details.
Delta type:: t delta [i,j], where t is either a base type, a range type, or a resolution type, and i and j are elements of the underlying base type of t. Delta types allow bounds to be placed on the changes in value that variables may undergo from one simulation step to the next. The value i specifies a lower bound, and j specifies an upper bound, on the size of this change between any two simulation steps. More precisely, if a variable has this type, and v and v′ are values assumed by this variable in successive simulation steps, with v′ the “later” value, then the following mathematical relationship holds: i ≤ v′ − v ≤ j. Note that if i is negative then values are allowed to decrease as simulation progresses.
Vector type:: <| t₁ * t₂ * ... * t_n |> where t₁, …, t_n may be any of the types mentioned above, or vector types themselves, provided the base types contained in the t_i are the same. The elements of a vector type are vectors whose i^th component has type t_i.

Table 3.1 gives examples of types and the values they contain.

Table 3.1: Type examples.

RSI Type Values in Type

double [0.0,4.0] All double-precision floating-point numbers between 0.0 and 4.0, inclusive.

int16 [-1,1] -1, 0, 1

int32 {0,4,7} 0, 4, 7

uint8 {0:1,1:3} 0, 1

double [0.0:0.5:2.0] 0.0, 0.5, 1.0, 1.5, 2.0

int16 [0,3] delta [-1, 1] 0, 1, 2, 3; inports of this type can increase or decrease by at most 1 in 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 |>

If any change is made to a port type, then “[modified]” appears in the title bars of the Info File Editor and the top-level Reactis window. You may save changes to disk by selecting File -> Save from the Info File Editor or File -> Save Info File from the top-level window.

If no .rsi file exists for a model, Reactis will create a default file the first time you open the Info File Editor, or start Simulator or Tester. The default type for each inport is the base type inferred for the port from the model. If you add or remove an inport to your model you can synchronize your .rsi file with the new version of the model by selecting Tools -> Synchronize from the Info File Editor.

§6 Select the File -> Exit menu item on the editor’s tool bar to close the Reactis Info File Editor.

3.4 Simulator

Reactis Simulator provides a rich array of facilities for viewing the execution of models. The tool can execute both closed-loop and open-loop models (the latter being models that contain inports at the top level).

To continue with the guided tour:

§7 Click the (enable simulator) button in the tool bar to start Reactis Simulator.

This causes a number of the tool-bar buttons that were previously disabled to become enabled.

The simulator performs simulations in a step-by-step manner: at each simulation step inputs are generated for each inport, and resultant outputs reported on each outport. In the case of open-loop models, such as the running cruise-control example, you can control how Simulator computes top-level inport values.

The tool may be directed to generate values randomly (this is the default).
The tool may be directed to query the user.
The tool may be directed to read inputs from a Reactis test suite. Such tests may be generated automatically by Reactis Tester, constructed manually in Reactis Simulator, or imported from a file storing test data in a comma-separated-value format.

To set the source of inputs, use the Inputs Source dialog located to the left of in the tool bar (see Figure 3.4). The next part of the guided tour illustrates the use of each of these input sources; interspersed with this discussion are asides on coverage tracking, data-value tracking, and other useful features.

Figure 3.4: The Inputs Source dialog allows you to control how Reactis Simulator generates values for top-level inports when executing a model.

3.4.1 Generating Random Inputs

As the random input source is the default, no action needs to be taken to set this input mode.

§8 In the model hierarchy panel on the left of the Simulator window, click on CruiseMain/CruiseMDL/Mode in order to display the Stateflow diagram in the main window. Then, click the (Run Simulation) button.

During simulation, blocks, signals, states, and transitions in the diagram are highlighted in green as they are entered and executed. The simulation stops automatically when the number of simulation steps reaches the figure contained in the entry box to the left of the Inputs Source dialog. Before then, you may halt the simulation by clicking the (Stop) button. Simulation is then suspended at the end of the current simulation step.

3.4.2 Tracking Model Coverage

While Simulator is running you may also track coverage information regarding which parts of your model have been executed and which have not. These coverage-tracking features work for all input-source modes. The next portion of the guided tour illustrates how these features are used.

§9 Select menu items Coverage -> Show Details and Coverage -> Show Summary.

Figure 3.5: The Reactis coverage tracking features convey which parts of a model have been exercised. Note that the coverage information you see at this point will be different than that shown above. This is because a different sequence of inputs (from the random ones you used) brought the simulation to the displayed state.

A dialog summarizing coverage (which blocks / states have been entered and which transitions have fired) now appears, and elements of the diagram not yet exercised are drawn in red, as shown in Figure 3.5. Note that poor coverage is not uncommon with random simulation. You may hover over a covered element to determine the (1) test (in the case being considered here, the “test” is the current simulation run and is rendered as . in the hovering information) and (2) step within the test that first exercised the item. This type of test and step coverage information is displayed with a message of the form test/step. You may view detailed information for the Condition, Decision and MC/DC coverage measures, which involve Simulink logic blocks and Stateflow transition segments whose label includes an event and/or condition, as follows.

§10 Perform the following.
In the model hierarchy panel on the left of the Simulator window, click on CruiseMain/CruiseMdl/Mode to display the Stateflow diagram in the main window. Note, this was done in a previous step, so it may not be necessary here.
Right-click on the transition from state Init to state Active, and select View Coverage Details. A dialog similar to that shown in Figure 3.6 will appear.

Figure 3.6: The dialog for viewing MC/DC related coverage information.

Details for decision coverage, condition coverage, and MC/DC are conveyed using a table as shown in Figure 3.6. The table in this figure gives information for the decision — set == 1 && deactivate == 0 — which includes two conditions — set == 1 and deactivate == 0. Conditions are the atomic boolean expressions that are used in decisions. The first two columns of the table list the test/step information for when the decision first evaluated to true and when it first evaluated to false. A value -/- indicates that the relevant situation has not yet been encountered. The third column lists the conditions that make up the decision, while the forth and fifth columns give test/step information for when each condition was evaluated to true and the false.

MC/DC Coverage requires that each condition independently affect the outcome of the decision in which it resides. When a condition has met the MC/DC criterion in a set of tests, the sixth and seventh columns of the table explain how. Each element of these two columns has the form bb:test/step, where each b reports the outcome of evaluating one of the conditions in the decision during the test and step specified. Each b is either T to indicate the condition evaluated to true, F to indicate the condition evaluated to false, or x to mean the condition was not evaluated due to short circuiting.

It should be noted that the previous scenario relied on randomly generated input data, and replaying the steps outlined above may yield different coverage information than that depicted in Figure 3.6

An alternative way to query coverage information is to invoke the Coverage-Report Browser by selecting Coverage -> Show Report. This is a tool for viewing or exporting coverage information that explains which model elements have been covered along with the test and step where they were first exercised.

A simulation run, and associated coverage statistics, may be reset by clicking the (reset) button in the tool bar. Note that in the Coverage Summary window, not all percentages will be zero, since some items are covered in the model’s initial configuration.

3.4.3 Reading Inputs from Tests

Simulation inputs may also be drawn from tests in a Reactis test suite. Such a test suite may be generated automatically by Reactis Tester, constructed manually in Reactis Simulator, or imported from a file storing test-data in a comma-separated-value format. By convention files storing Reactis test suites have a .rst file-name extension. A Reactis test suite may be loaded into Simulator as follows.

§11 Click the    button in the tool bar to the right of the Inputs Source dialog and use the file-selection dialog to select cruise.rst in the examples folder of the Reactis distribution.

This causes cruise.rst, the name of a test suite file generated by Reactis Tester, to appear in the title bar and the contents of the Inputs Source dialog to change; it now contains a list of tests that have been loaded. To view this list:

§12 Click on the Inputs Source dialog (located to the left of    in the tool bar).

Each test in the suite has a row in the dialog that contains a test number, a sequence number, a name and the number of steps in the test. Clicking the “all” button in the lower left corner specifies that all tests in the suite should be executed one after another. To execute the last test in the suite:

§13 Do the following.
Select the last test in the test suite in the dialog.
Click the    (Run Fast Simulation) button.

If you look at the bottom-right corner of the window, you can see that the test is being executed, although the results of each execution step are not displayed graphically. When the test execution completes, the exercised parts of the model are drawn in black. If the Run Simulation button (    ) is clicked instead, then the results of each simulation step are rendered graphically, with the consequence that simulation proceeds more slowly.

You may specify that a subset of tests should be run by holding down the control key and clicking on each test to be run with the left mouse button. The tests will be run in the order they are selected. As tests are selected the sequence number column is updated to indicate the execution order of the tests.

You may also use the Inputs Source dialog to change the name of a test. To do so, select the test by single clicking on it, then click on the name and, when the cursor appears, type in a new name and press return.

3.4.4 Tracking Values of Data Items

When Simulator is paused¹, you may view the current value of a given data item (Simulink block or signal line, or Stateflow variable) by hovering over the item with your mouse cursor. You may also select data items whose values you wish to track during simulation using the watched-variable and scope facilities of Simulator.

§14 In the model hierarchy panel on the left of the Simulator window, select the top-level of the model (“cruise”) for display. Then:
Right-click on the outport “active” and select Add to Watched from the resulting pop-up menu.
Hover over outport “active” with the mouse; a pop-up displays its current value.

The bottom of the Simulator window now changes to that indicated in Figure 3.7.

Figure 3.7: The watched-variable panel in Simulator displays the values of data items, as does hovering over a data item with the mouse.

The watched-variable panel shows the values of watched data items in the current simulation step, as does hovering over a data item with the mouse. Variables may be added to, and deleted from, the watched-variable panel by selecting them and right-clicking to obtain a menu. You may also toggle whether the watched-variable list is displayed or not by selecting the View -> Show Watched Variables menu item.

Scopes display the values a given data item has assumed since the beginning of the current simulation run. To open a scope:

§15 Perform the following.
In the model hierarchy panel, select CruiseMain/CruiseMdl.
Right-click on inport “speed” and select Open Scope from the resulting pop-up menu. A new window like the one in Figure 3.8 appears and plots the speed of the car during the simulation run.
Right-click on the “dSpeed” signal that exits the “DesiredSpeed” subsystem and select Add to Scope -> cruise.CruiseMain.CruiseMDL.CruiseMDL|speed. This causes the desired speed to be plotted against the actual speed on the previously opened scope.

Figure 3.8: A scope window plotting desired speed (green) and actual speed (yellow). Note that the plots you see will be different than that shown above. This is because a different sequence of inputs brought the simulation to the displayed state.

§16 Close the watched-variable panel by selecting the View -> Show Watched Variables menu item.

Figure 3.9: The Next Input Values dialog enables you to hand-select input data.

3.4.5 Querying the User for Inputs

The third way for Simulator to obtain values for inports is for you to provide them. To enter this mode of operation:

§17 Select User Guided Simulation from the Inputs Source dialog.

Upon selecting this input mode, a Next Input Values dialog appears, as shown in Figure 3.9, that allows you to specify the input values for the next simulation step. Each top-level inport of the model has a row in the dialog containing five columns; these determine the next input value for the corresponding inport as follows.

The inport number and name.
This pull-down menu has three entries that determine how the next value for the port is specified:
Random
Randomly select the next value for the inport from the type given for the inport in the .rsi file.
Entry
Specify the next value with the text-entry box in column three of the panel.
Panel
Open a sub-panel to specify the next value. This input mode is primarily used when the port reads vector values.
If the pull-down menu in column two is set to “Entry”, then the next input value is taken from this text-entry box.
If the pull-down menu in column two is set to “Entry”, then clicking the history button (labeled H) displays recent values the inport has assumed. Selecting a value from the list causes it to be placed in the text-entry box of column three.
The arrow buttons in this column enable you to scroll through the possible values for the port. The arrows are not available for ports of type double or single or ranges with a base type of double or single.

When Run Simulation ( ) or Run Fast Simulation ( ) is selected, the inport values specified are used for each subsequent simulation step until the simulation is paused.

3.4.6 Other Features

Simulator has several other noteworthy features. You may step both forwards and backwards through a simulation using toolbar buttons:

The button executes a single execution step.
The button executes the next “mini-step” (a single execution step consists in general of several mini-steps).
The button, which causes the simulation to go back (undo) a single step.
The button causes the simulation to go back multiple steps.

You may specify the number of steps taken when , , or are pressed by adjusting the number in the text-entry box to the right of . When a simulation is paused at the end of a simulation step (as opposed to in the middle of a simulation step), the current simulation run may be added to the current test suite by selecting the menu item Test Suite -> Add/Extend Test. After the test is added it appears in the Inputs Source dialog. After saving the test suite with Test Suite -> Save, the steps in the new test may be viewed by selecting Test Suite -> Browse. A model (or portion thereof, including coverage information) may be printed by selecting File -> Print....

Breakpoints may be set by either:

right clicking on a subsystem or state in the hierarchy panel and selecting Toggle Breakpoint; or
right clicking on a Simulink block, Stateflow state, or Stateflow transition in the main panel and selecting Toggle Breakpoint. Additionally, if you are using the Reactis for C Plugin, then a breakpoint may be set on any line of a C file that contains a C statement by right-clicking just to the right of the line number and selecting Toggle Breakpoint.

The symbol is drawn on a model item when a break point is set. When breakpoints are set on subsystems or Stateflow states the symbol also appears in the hierarchy panel. During a simulation run, whenever a breakpoint is hit Simulator pauses immediately. When paused at a breakpoint, you may proceed either by mini-stepping by clicking or completing the current simulation step by clicking . In either case after reaching the end of the current simulation step all other navigation buttons in the toolbar become enabled.

3.5 Tester

Tester may be used to generate a test suite (a set of tests) automatically from a Simulink / Stateflow model. The tool attempts to maximize coverage criteria you specify. To start Tester:

§18 Select the Test Suite -> Create menu item.

This causes the window shown in Figure 3.10 to appear. Tester employs a three-phase algorithm to generate test suites. In the Preload Phase, a set of previously computed test suites may be loaded; Tester then attempts to extend the preloaded suite(s). In the Random Phase, Tester uses a fast random search strategy to generate test cases. In the Targeted Phase, the tool uses sophisticated algorithms to build tests that exercise previously uncovered parts of the model.

Figure 3.10: The Reactis Tester launch dialog.

By default, the Preload Phase is disabled, and the other two are enabled. Checking boxes to the left of the phase names in the Tester dialog allows you to enable or disable each of the phases. Each phase also has parameters that the you may adjust to tailor the performance of the tool. The only parameter for the Preload Phase is a list of files containing previously generated test suites. The Random phase has two parameters: one for the number of tests to be built and the other for the maximum number of steps in each test for this phase. It should be noted that, upon completion of the random phase, redundant steps are pruned from the tests, so the lengths of the final tests are usually shorter than this parameter. The Targeted Phase has one parameter: the total number of execution steps to take during this phase.

The Tester panel also contains a Coverage Objectives section consisting of check boxes that enable you to specify the criteria for guiding test generation. The currently supported targets include Simulink branches and conditionally executed subsystems; Stateflow states, condition actions, and transition actions; conditions, decisions and modified condition / decision coverage (MC/DC), all of which apply both to Simulink and Stateflow; boundary values of top-level inports, including lower and upper bounds in range-constrained inports, all values in enumeration-constrained inports, and boundary values of Relational Operator blocks; the intervals defined by a 1-d or 2-d Lookup Table block; and Validator objectives (assertions and user-defined targets). See Chapter 6 for details. If you are using the Reactis for C Plugin and your model includes C code, then you will also see a checkbox for C Statements.

To generate a test suite in the guided tour, retain the default settings and:

§19 Click the Create Suite button.

Figure 3.11: The Reactis Tester progress dialog.

The Tester progress dialog, shown in Figure 3.11, is displayed during test-suite generation. When Tester terminates, a results dialog is shown, and a file cruise.rst containing the suite is produced. The results dialog includes buttons for loading the test suite into the Test-Suite Browser (see below), Reactis Simulator, or a coverage viewer.

3.6 The Test-Suite Browser

The Test-Suite Browser is used to view the test suites created by Reactis. It may be invoked from either the Tester results dialog or the Reactis top-level window.

Figure 3.12: The Reactis Tester Test-Suite Browser.

§20 Select the Test Suite -> Browse menu item and then cruise.rst from the file selection dialog that pops up.

A Test-Suite Browser window like the one shown in Figure 3.12 is then displayed. The the Test Data tab of the browser displays the test selected in the button/dialog located on the right side of the browser’s tool bar. The main panel in the browser window shows the indicated test as a matrix, in which the first column gives the input and output ports of the model and each subsequent column lists the values for each port for the corresponding simulation step. The simulation time is displayed in the output row labeled “___t___”. The buttons on the tool bar may be used to scroll forward and backward in the test. The Test History and Suite History tabs display history information recorded by Reactis for the test and the suite as a whole.

The Test-Suite Browser may also be used to display the entire set of values passing over a port during a single test or set of tests.

§21 Perform the following in the Test-Suite Browser window.
Left click on the row for inport drag.
Right click on the row and select Show Distribution Scope (current test).

A dialog similar to that shown in Figure 3.13 appears. In the figure, each value assumed by the inport drag is represented by a yellow dot.

Figure 3.13: Values passing over inport drag during a test.

3.7 Validator

Reactis Validator is used for checking whether models behave correctly. It enables the early detection of design errors and inconsistencies and reduces the effort required for design reviews. The tool gives you two major capabilities.

Assertion checking.: You can instrument your models with assertions, which monitor model behavior for erroneous scenarios. The instrumentation is maintained by Reactis; you need not alter your .mdl files. If Validator detects an assertion violation, it returns a test highlighting the problem. This test may be executed in Reactis Simulator to uncover the source of the error.
Customized test scenarios.: You can also instrument your models with user-defined targets, which may be used to define specific test scenarios to be considered in the analyses performed by Tester and Validator. Like assertions, user-defined targets also monitor model behavior; however, their purpose is to determine when a desired test case has been constructed, so that the test may be included in a test suite.

Conceptually, assertions may be seen as checking system behavior for potential errors, while user-defined targets monitor system behavior in order to check for the presence of certain desirable executions (tests). Syntactically, Validator assertions and user-defined targets have the same form and are collectively referred to as Validator objectives.

Both assertions and user-defined targets play key roles in checking a model against requirements given for its behavior. A typical requirements specification consists of a list of mandatory properties. For example, a requirements document for an automotive cruise control might stipulate that, among other things, whenever the brake pedal is depressed, the cruise control should disengage. Checking whether or not such a requirement holds of a model would require a method for monitoring system behavior to check this property, together with a collection of tests that would, among other things, engage the cruise control and then apply the brake. In Validator, the behavior monitor would be implemented as an assertion, while the test scenario involving engaging the cruise control and then stepping on the brake would be captured as a user-defined target.

3.7.1 Manipulating Validator Objectives

This section gives more information about Validator objectives.

§22 Do the following.
Disable Simulator by clicking the button in the top-level tool bar. (Validator objectives may only be modified or inserted when Simulator is disabled.)
In the model hierarchy panel select the top-level of the model cruise for display in the main window.

After performing these operations, you now see a window like the one depicted in Figure 3.14. The two kinds of objectives are represented by different icons; assertions are denoted by a lightning bolt while targets are marked by a cross-hair symbol .

Figure 3.14: The top-level Reactis window, with Validator objectives.

Objectives in Validator may take one of two forms.

Expressions.: Validator supports a simple language of boolean expressions for defining both assertions and user-defined targets.
Simulink / Stateflow diagrams.: Simulink / Stateflow diagrams may also be used to define objectives. Such a Simulink subsystem defines a set of objectives, one for each outport of the subsystem. For assertion diagrams, a violation is flagged by a value of zero on an outport. For user-defined targets, coverage is indicated by the presence of a non-zero value on an outport.

To see an example expression objective, do the following.

§23 Right click on the Brake assertion and select Edit Properties. When through with this step, click Cancel to dismiss the dialog.

Figure 3.15: The dialog for adding or modifying a Validator expression objective.

A dialog like that shown in Figure 3.15 now appears. This dialog shows an expression intended to capture the following requirement for a the cruise control: “Activating the brake shall immediately cause the cruise control to become inactive.” Note that the dialog consists of four parts:

Name. This name labels the assertion in the model diagram.
Expression. This is a C-like boolean expression. The interpretation of such an assertion is that it should always remain “true”. If it becomes false, then an error has occurred and should be flagged. In this case, the expression evaluates to “true” provided that at least one of brake and active is false (i.e. the conjunction of the two is false). Section 9.2.1 contains more detail on the expression notation.
# steps to hold For assertions, this entry is an integer value that specifies the number of simulation steps that the expression must remain false before flagging an error. For user targets, the entry specifies the number of steps that the expression must remain true before the target is considered covered.
Wiring. The entry boxes in the right column of this section list the variables used to construct the expression. These can be viewed as virtual input ports to the expression objective. The pull-down menus to the left of the section specify which data items from the model feed into the virtual inputs.

To see an example diagram objective:

§24 Perform the following.
Using the model hierarchy panel, open the CruiseMDL subsystem located within the CruiseMain subsystem.
In the main panel, right-click on the assertion SpdCheck and select Edit Properties.

Figure 3.16: The Properties dialog for Validator requirement SpdCheck.

A dialog like the one in Figure 3.16 now appears. This dialog contains five sections.

Name. The name of the objective.
Library. The Simulink library containing the diagram for the objective. In the case of SpdCheck, the target resides in cruise_validator.mdl.
System. The system in the library that is to be used as the objective. In this case, the system to be used is SpeedMaintenance.
Parameters. If the subsystem selected for use as an objective is a masked subsystem, in Simulink terms, then this panel is used to enter the relevant parameters. In the case of SpdCheck, no parameters are required because the indicated subsystem is not masked.
Wiring. The wiring panel is used to indicate which data items in the model should be connected to the inputs of the objective. In this case, SpdCheck has three inputs: speed, dSpeed, and active. The wiring information indicates that the first input should be connected to the speed inport of the current level of the model; the second should be connected to the dSpeed output of subsystem DesiredSpeed; and the third should be connected to (the output of) Relational Operator1. In general, this panel contains pull-downs describing all valid data items in the current scope that inputs of the objective may be connected to; you perform the wiring by selecting elements from these pull-downs.

Wiring information may be viewed by hovering over a diagram objective in the main Reactis model-viewer panel.

Diagram-based objectives may be viewed as monitors that read values from the model being observed and raise flags by setting their outport values appropriately (zero for false, non-zero for true). A diagram-based assertion in essence defines one “check” for each of its outports, with such an outport check being violated if it ever assumes the value zero. Similarly, a diagram-based target objective in essence defines one “target” for each outport; such a target is deemed covered if it becomes non-zero.

To view the diagram associated with SpdCheck:

§25 Perform the following.
Close the Properties dialog for SpdChk by clicking the Cancel button at the bottom of dialog box.
Double-click on the SpdChk icon.

These operations open the Stateflow diagram shown in Figure 3.17. This diagram encodes the following requirement: “While it is engaged, the cruise control shall not allow the desired and actual speeds to differ by more than 1 mile per hour for more than three time units.”

Figure 3.17: A Validator diagram assertion encoding a requirement that the cruise control properly maintain the speed of the car when engaged.

To understand how this diagram captures this requirement, note that the SpdCheck diagram has two top-level states, one corresponding to when the cruise control is active and one when it is inactive. The active state has three child states:

OkDiff: Control resides here when the difference between actual and desired speed is within the accepted tolerance.
BigDiff: Control resides here when the difference between actual and desired speed is greater than the accepted tolerance, but three time units have not yet elapsed.
Error: Control resides here when the difference between actual and desired speed has been greater than the accepted tolerance for more than three consecutive time units.

Note that the transition action executed as state Error is entered sets the outport ok to 0. This is how an assertion violation is flagged.

Diagram objectives give you the full power of Simulink / Stateflow to formulate assertions and targets. The objectives may use any Simulink blocks supported by Reactis, including full Stateflow. The diagrams are created using Simulink and Stateflow in the same way standard models are built; they are stored in a separate .mdl file from the model under validation.

Diagram wiring is managed by Reactis, so the model under validation need not be modified at all. As this information is stored in the .rsi file associated with the model, it also persists from one Reactis session to the next. After adding a diagram objective to a model, the diagram is included in the model’s hierarchy tree, just as library links are in a model. See Chapter 9 for more details on using Reactis Validator.

3.7.2 Launching Validator

To use Validator to check for assertion violations:

§26 Select the Validate -> Check Assertions... menu entry.

Figure 3.18: Launching Validator brings up this screen.

A dialog like the one in Figure 3.18 now appears. The dialog is similar to the Tester launch screen in Figure 3.10 because the algorithms underlying the two tools are very similar. Conceptually, Validator works by generating thorough test suites from the instrumented model using the Tester test-generation algorithm and then applying these tests to the instrumented model to see if any violations occur. Note that when a model is instrumented with Validator objectives, the test-generation algorithm uses the objectives to direct the test construction process. In other words Reactis actively attempts to find tests that violate assertions and cover user-defined targets. Validator stores the test suite it creates in the file specified in this dialog. The tests may then be used to diagnose any assertion violations that arise.

1: A simulation is paused if it Simulator is not actively computing simulation step(s).