Chapter 5  The Reactis 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 in this chapter.

.rsi files can include directives to:

• constrain the values that the inports assume during simulation, test generation, and validation
• tag certain workspace data items as configuration variables
• manipulate model data items designated as test points
• specify tolerance for Simulator to use when comparing outport value computed by the model against that stored in a test suite
• specify the coverage criteria to be used when working with a model
• manipulate Validator objectives (assertions, user-defined targets, virtual sources)
• if using the Reactis for C Plugin, view a list of places in a model that reference C code (S-Functions and Stateflow custom code) and manipulate the settings for white-box analysis of each S-Function
• specify callbacks to be executed before and/or after a model is loaded
• specify a model-specific search path
• specify 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 .mdl file and .rsi file of a model share the same base name; for example, if the model file is named cruise.mdl, then the name of the associated .rsi file is assumed to be cruise.rsi. A .rsi file named differently may be associated with a model by loading the model in Reactis and selecting File -> Select Info File....

5.1  Contents of Reactis Info Files

This section describes the ten kinds of directives manipulated by the Reactis Info File Editor using the ten tabbed panels of the editor window.

5.1.1  Inport Types

Inport type specifications are used by Reactis to constrain the set of values fed into top-level 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 vector types. More precisely, allowed types are defined by the following grammar.

The variables in this grammar are defined as follows. min, max, step, and value are elements of the given base type, weight is an integer greater than zero and less than one thousand, and the base types mentioned in rsiType₁, …, rsiType_n must all be identical.

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

bits

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

slope

is a decimal specified in one of two ways

• as _SfpDecimal such that slope = fpDecimal
• as _FfpDecimal_EfpInt such that slope = fpDecimal×2^fpInt

bias

is a decimal specified as _BfpDecimal.

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

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

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{u₁, …, u_n}) the probability weights in the u_i 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{ v₁:w₁, v₂:w₂, ..., v_n:w_n}, then the probability of each value in the type being assigned to x is computed as follows. Let W = w₁ + w₂ + ... + w_n, where w_i denotes the probability weight assigned to v_i (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 v_i is w_i/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 v₁ then in the next simulation step the new value, v₂, of x must satisfy: v₁ + l <= v₂ <= v₁ + 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.1.2  Configuration Variables

If you tag a workspace 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 workspace variables can be used to initialize blocks, such as Constant blocks; these expressions are evaluated before simulation begins. When these expressions are workspace variables, they may be declared to be configuration variables. Note, that workspace variables appearing in larger expressions may not be declared configuration variables. For example, if MINTEMP is a workspace 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 which users may select from. The types associated with these configuration variables in .rsi files are the same as those that may be assigned to inports. 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.

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 ] { instance₁, ..., instance_n } where numElts is a positive integer and each instance_i has the form [ elt₁, ... , elt_numElts ].
• Two-Dimensional Arrays
  basetype array [ numRows,numCols ] { instance₁, ..., instance_n } where numRows and numCols are positive integers and each instance_i has the form [ row₁; ... ;row_numRows ] and each row_i has the form elt₁,..., elt_numCols.
• Structures
  { fieldName₁ : fieldType₁ , ... , fieldName_n : fieldType_n } { instance₁, ..., instance_m } where each instance_i has the form { fieldName₁ = value₁, ... , fieldName_n = value_n }.

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.1.3  Test Points

This tab displays a list of test points currently associated with the model. Test points are internal data items (Simulink blocks or signals or Stateflow variables) that Reactis treats as virtual outputs. Specifically, the tool records values for test points in test suites and Reactis Simulator flags any differences between the values computed by a model for a test point and those stored in a test suite.

Test points can be added by right-clicking on a data item in the Reactis main panel when Simulator is off and selecting Add To Test Points. When generating a test suite in Reactis Tester or modifying a test suite in Simulator, Reactis will store the data for the currently defined test points in the test suite.

Test points can be removed by going selecting Edit -> Remove (Simulator must be off) from the Info File Editor menu bar.

When running a test suite within Reactis Simulator, Reactis will compare the test point data in the test suite with the computed values at the test points and report differences. The comparison uses a tolerance exactly as described for outports in Section 5.1.4. The Tolerance column of this tab enables you to set a separate tolerance for each test point.

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.1.4  Outport Tolerances

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 tab lets you specify a relative tolerance for each outport to be used in these comparisons. Note, that this port-specific setting may override the global tolerance set within the Reactis Settings dialog. A difference is flagged for a step and outport if the difference between the computed value and test value exceeds the error tolerance for the outport. More precisely, for an outport p, let

then an error for outport p at step i of test j exceeds the specified tolerance if any of the following conditions are true:

Hence, a tolerance of zero will require that the model and test values always be the same, a tolerance of 0.1 will allow a difference of 10%, and a tolerance of 1 will allow the model value to be at most twice the test value. A negative value for an outport tolerance means that the tolerance is inherited from the global tolerance setting.

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.4.4)
• When executing a test suite generated by Reactis within Simulink using the runtests utility (see Section 12.2.1)

---

Figure 5.1: The relative tolerance used for output ports whose tolerance setting is set to “inherited” (i.e. a negative value) is specified in the Settings Dialog (invoked with File -> Settings...).

---

The tolerance works exactly as the tolerance for outports. For a precise description, see Section 5.1.4.

5.1.5  Coverage

The different coverage criteria supported by Reactis are defined in Chapter 6. The model-specific coverage tab lets you enable or disable each criterion. If a criterion is disabled:

• the criterion will not be targeted by Tester when generating tests, and
• Simulator will not include the targets from the criterion in the Coverage Summary dialog, the Coverage Report Browser, and the highlighting in the main panel.

The following dependencies among criteria exist:

• Enabling Condition coverage requires that Decision coverage be enabled
• Enabling MC/DC requires that Condition coverage be enabled

Additionally, the meaning of several of the criteria (CSEPT, MC/DC, 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.

Modified Condition/Decision Coverage (MC/DC)

Multi-block MC/DC

Switches between single-block MC/DC tracking and multi-block MC/DC tracking for Simulink logical operator blocks. For more details about this feature see Section 6.3.1.

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 criterion has the potential to introduce a large number of very hard to cover targets, some users might prefer to not track these targets. This checkbox 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 include, 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”.

When a new .rsi file is created, the settings in this tab are initialized with the values set in the Defaults dialog (invoked with File -> Defaults...).

5.1.6  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 tab 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 tab 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 tab 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.

5.1.7  C Code

When using the Reactis for C Plugin, this tab 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.1.8  Callbacks

The Callbacks tab 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.1.9  Search Path

This tab 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 tab of the Reactis Settings dialog. For a description of how the operations work, please see Section 4.8.4. Note, that the one difference between the two path tabs is that the Import button of the model-specific tab 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.1.10  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 ¹ If a .m file that a model depends on changes, the stored information needs to be re-computed. The dependency information given in this tab 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 .mdl files need not be listed here; the .mdl files on which a model depends are inferred automatically.

5.2  Labeled Window Items

---

Figure 5.2: The Reactis Info File Editor.

---

Figure 5.2 contains a screen shot of the Info File Editor. This section describes the labeled items in the figure.

1. Save any changes to the currently loaded .rsi file.
2. Equivalent to menu item Edit -> Add....
3. Equivalent to menu item Edit -> Edit....
4. Equivalent to menu item Edit -> Remove.
5. Cut the selected item and copy it to the clipboard. This button is only enabled for the Configuration Variables, Test Points, Validator Objectives, and Callbacks tabs.
6. Copy the selected item into the clipboard.
7. Paste the item in the clipboard into the selected row.
8. Undo last editing operation.
9. Redo last undone edit operation.
10. Get help.
11. Specify constraints for top-level input ports using this tabbed pane. Each row corresponds to a different inport and includes the port number, port name, and constraint for the port. Double clicking on a row opens the type editor dialog for the item in the row. See Section 5.4 for details regarding the usage of the type editor dialog and see Section 5.1.1 for more information on the Ports tab.
12. Specify constraints for configuration variables using this tabbed pane. The behavior of the pane is exactly as described above for top-level inports. See Subsection 5.1.2 for more discussion of configuration variables.
13. Manipulate the list of test points associated with the model using this tabbed pane. Double-clicking on a test point will highlight the test point in the Reactis main panel. A test point may be deleted by selecting it, then selecting Edit -> Remove. See Subsection 5.1.3 for further discussion of test points.
14. Specify the maximum acceptable difference between the value computed by the model for an outport and the value stored in a test suite. See Section 5.1.4 for details.
15. Specify the set of coverage criteria to be used with the model. See Section 5.1.5.
16. Manipulate Validator objectives (assertions, user-defined targets, virtual sources) using this pane. See Subsection 5.1.6.
17. If using the Reactis for C Plugin, view a list of places in a model that reference C code (S-Functions and Stateflow custom code) and manipulate the settings for white-box analysis of each S-Function. See Chapter 16 for details.
18. 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.
19. Specify a model-specific search path. See Section 5.1.9.
20. Each line in this tabbed pane lists a .m file on which the model depends. See Section 5.1.10.

5.3  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 tab 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 tab.

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 Variable tab 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 the variables defined in the .m file(s) attached with the Simulink or Reactis pre-load callback of the model.

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

When the File Dependencies tab 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 tabs 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.3 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 tabs 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.1. The entry is disabled when one of the other tabs is selected.

Remove

Remove the currently selected item.

Tools.

The availability and contents of this menu vary depending on the currently displayed tab. The tabs that offer a Tools menu are below along with the entries available with each tab.

• When the Inport Types tab is displayed the Tools menu has the following entries:

  Synchronize

  The current .rsi file is modified as follows. If the same top-level inport is included in both the currently loaded .mdl file and the old .rsi file, then the old entry in the .rsi file is retained. Inports deleted from the .mdl file will have their entry in the .rsi file removed; new ports in the .mdl file will have entries introduced in the .rsi file.

  Reset to Defaults

  Revert the type of each port to the type inferred for it in the .mdl file (i.e. drop any added constraints such as ranges, enumerated sets, probabilities, delta constraints, etc.).

• When the Test Points tab is displayed the Tools menu has the following entries:

  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.

• When the Outport Tolerances tab is displayed the Tools menu has the following entries:

  Synchronize

  The current .rsi file is modified as follows. If the same top-level outport is included in both the currently loaded .mdl file and the old .rsi file, then the old entry in the .rsi file is retained. Outports deleted from the .mdl file will have their entry in the .rsi file removed; new outports in the .mdl file will have entries introduced in the .rsi file.

  Reset to Defaults

  Revert each outport tolerance to Inherited (-1).

• When the Coverage tab is displayed the Tools menu has the following entries:

  Reset to Defaults

  Revert each coverage setting for the model to that specified in the Defaults dialog (invoked with File -> Defaults...).

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.

5.4  The Type Editor Dialog

The Type Editor Dialog, shown in Figure 5.3, helps users construct types for top-level inports and configuration variables. Recall that, as described in Sections 5.1.1 and 5.1.2, these types constrain the set of values Reactis will assign to inports and configuration variables during testing. In the following discussion, we use TUC to denote the type under construction, i.e. the type currently being defined with the dialog.

---

Figure 5.3: The dialog for specifying type information for inports or configuration variables. As shown here a type of double {0.0, 1.0} is specified for port “onOff”, meaning that during random simulation “onOff” will be assigned the values 0.0 and 1.0 with equal probability.

---

5.4.1  Invoking the Type Editor

The Type Editor may be invoked in several different ways:

• From the main panel of the Reactis window, by either:
  • double-clicking on a top-level inport, or
  • right-clicking on a top-level inport and selecting Edit Type, or
  • 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 Reactis Info File Editor, by either:
  • double clicking on an inport or configuration variable row, or
  • selecting an inport or configuration variable 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.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.3. Recall that TUC denotes type under construction, i.e. the type currently being defined with the dialog.

1. 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 3) and proceed to step 2.

   Only a subrange of the base type.

   Select the Subrange of base type radio button (window item 4) and specify a lower and upper bound for the range using window items 5 and 6 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 7) and enter a resolution value in the text box to the right (window item 8). 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 in window item 8. Proceed to step 2.

   A specific set of values in the base type.

   Select the Set of specific values radio button (window item 9) and use the Add, Edit, and Remove buttons (window items 12, 13, and 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.1 for a description of probability weights. Proceed to step 2.

2. 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 3.

   Yes.

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

3. When you are satisfied with the type you have constructed click the Ok button to update type and dismiss the Type Editor dialog.
4. Select File -> Save to save your changes to the .rsi file.

5.4.3  Labeled Window Items

This section describes the labeled items in Figure 5.3. Recall that TUC denotes type under construction, i.e. the type currently being defined with the dialog.

1. The textual version of the TUC (as described in Section 5.1) is displayed here. The string here may not be edited; it is read-only. It is modified by Reactis as you manipulate the other controls in the type editor dialog.
2. The radio buttons in this group (window items 3, 4, and 9) enable you to specify the values from the base type to be include in the TUC.
3. Selecting this radio button indicates that all values from the base type should be included in the TUC.
4. Selecting this radio button indicates that only a subrange of values from the base type should be included in the TUC.
5. When the Subrange of base type radio button is selected, this entry box enables the user to specify a lower bound for the subrange.
6. When the Subrange of base type radio button is selected, this entry box enables the user to specify an upper bound for the subrange.
7. When the Subrange of base type radio button and a base type of double or single are selected, then this check box may be checked in order to specify a resolution for the TUC.
8. 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.
9. Selecting this radio button indicates that only a specified set of values from the base type should be included in the TUC. Window items 10-14 are used to specify the set of values.
10. The entries in this column specify the values in the TUC.
11. The entries in this column associate a probability weight with each value in the TUC. See Section 5.1 for a description of probability weights.
12. Add one or more new values to the TUC using the dialog shown in Figure 5.4.

    ---

    

    Figure 5.4: 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.

    ---

13. Edit the probability weight for the currently selected value.
14. Remove the currently selected value.
15. The radio buttons in this group (window items 16 and 17) enable you to specify whether or not the type has a delta constraint. For an inport with the TUC, such a constraint limits the allowable changes in value from one simulation step to the next.
16. The TUC has no delta constraint.
17. The TUC has the delta constraint indicated by window items 18 and 19.
18. The value for an inport with the TUC may change by no less than the value specified here. If v₁ and v₂ are the values of the inport in consecutive simulation steps then v₂ − v₁ >= min .
19. The value for an inport with the TUC may change by no more than the value specified here. v₂ − v₁ <= max .
20. View help on the type editor dialog.
21. Update the TUC and dismiss the dialog. The revised TUC will appear in the appropriate row of the Info File Editor and “[modified]” will appear in the title bar. Selecting File -> Save will write the .rsi file to disk and cause the “[modified]” tag in the title bar to disappear.
22. Discard any changes to the TUC and dismiss the dialog.

5.4.4  Editing Vector Types

As shown in Figure 5.5, the top of the type editor dialog changes slightly when editing a inport with a vector type. The Signal Elements box 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 bottom portion of the dialog to specify a type in the same manner described above for scalar types. Multiple elements may be set to the same type as follows:

1. Select one element and configure it as desired.
2. Click the Copy button.
3. Select some number of other elements by one of the following methods:

   Consecutive elements

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

   Non-consecutive elements

   Hold down the control key and select any number of elements.

4. Click the Paste button.

---

Figure 5.5: When an inport has a vector type, the top portion of the type editor includes a matrix in which each element specifies the type for an element of the vector.

---

1

This caching feature may be disabled by selecting File -> Settings... on the top-level Reactis window and unchecking the check-box Create and use cache files. When this feature is disabled, dependency directives need not be given, although model-loading times will be adversely affected.