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