- How do I execute Reactis-generated tests in Simulink?
- Why are the simulation times in exported .m files different from those in .rst files?
- Why do I need to turn interpolation off for top-level inports when running test suites generated by Reactis in Simulink?
- Why are the output values produced by Reactis different from those produced by Simulink?

You can export the tests from Reactis to a Simulink-suitable format, then use the utility distributed with Reactis to execute the tests. For details, see Chapter Executing Tests of the Reactis User's Guide. In brief, do the following:

- Load your model in Reactis.
- Start Simulator.
- Load the test suite to be exported.
- Select menu item
`Test Suite`,`Export...`, and export the tests in either .m or .mat format. - In MATLAB, make sure the Reactis bin folder is in your path.
- At the MATLAB prompt, type
`runtests`, to invoke a utility for executing Reactis-generated tests. - Click the
`Load Model`button and specify the model on which you want to run the tests. - Click the
`Load Test File`button and specify the exported .m or .mat file containing the tests you want to run. - Click the
`Run Test button`to run the tests. Any differences in the responses of the model with those stored in the tests will be flagged.

This difference is a safety measure to prevent rounding errors in the time-step computation from leading to incorrect inputs to the model when running a test suite in Simulink.

To understand the problem, assume we have a model with a single sample of
0.1. The decimal value 0.1 does not have a finite floating-point representation
and therefore cannot be represented exactly on a computer; instead, an finite
binary approximation to 0.1 must be used. This means that when repeatedly adding
a sample time of 0.1, there will be some (small) *rounding errors* that
result. This occurs in Simulink/MATLAB as well as in Reactis. Unfortunately
there is no guarantee that Simulink and Reactis will produce the *same*
rounding errors; floating-point packages, even those ostensibly in compliance
with relevant IEEE standards, have subtle differences.

Now assume that for this model Reactis produces the following sequence of sample times and inputs:

Time | Value |
---|---|

0 | 0 |

0.1 | 1 |

0.2 | 0 |

0.2999999 | 1 |

When feeding these values into Simulink, Simulink first computes the
simulation time for the next step, then looks at the table of
time/value pairs given for each of the input ports. If there is an
exact match in the time column, then the corresponding value is used.
If there is no exact match, then Simulink consults the *Interpolate data*
parameter given for the input port:

- If
*Interpolate data*is*on*then Simulink will compute the new value by interpolation using the other values in the table. - If
*Interpolate data*is*off*, then Simulink will take the value of the most recent time/value pair whose time is smaller than the current simulation time.

Now assume that Simulink, during its execution of our example model, produces the following simulation time sequence: 0, 0.1, 0.19999999, 0.3, 0.4, ...

If *Interpolate data* for the input port is *on*, then at t=0.1999999
Simulink (through interpolation) will compute an input value slightly
different from 0. Having this only slightly different input value
should not pose a problem unless this value is
interpreted by the model to be (for example) a boolean value which is
tested to be either zero or non-zero. In that case, the model would
see a non-zero (i.e. {\em true}) value where a zero (i.e. {\em false}) value
should have been.

If *Interpolate data* for the input port is *off*, then at t=0.1999999
Simulink will still see the value of the previous time-step (0.1)
which of course is also not correct.

To get around this problem, Reactis changes input values
*between* time steps rather than exactly at each time step.
In our example, when the test suite is
exported, Reactis produces a .m file with
following time/value table for the input port:

Time | Value |
---|---|

0 | 0 |

0.05 | 1 |

0.15 | 0 |

0.25 | 1 |

0.35 | 1 |

Now with *Interpolate data* set to *off* for top-level input ports
(as Reactis requires), Simulink at time 0.1999999 will feed the correct
value (0) into the input port.

See the answer to Question above.

The most probable cause of differences in output values is that you forgot to turn off interpolation for top-level inports as described above. Slight differences can also result because of rounding errors due to platform-dependent floating-point discrepancies. If significantly larger differences occur when interpolation is disabled for all inports, please notify Reactive Systems of the problem.

Another possible explanation for the problem is related to the answer to
Question regarding S-Functions. If your model
contains an S-function that does not adhere to the Reactis guidelines, then
outputs obtained during test generation can differ from those obtained during
simulation runs.