# Running Tests in Simulink#

## How do I execute Reactis-generated tests in Simulink?#

You can export tests from Reactis to a Simulink-suitable format, then use a utility distributed with Reactis to execute the tests. For details, see Executing Tests. 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 API folder is in your path. If you installed Reactis in the default location, you can add the Reactis API folder to your MATLAB path with:

```
>> addpath('c:\Program Files\Reactis V2024\lib\api\MATLAB\reactis')
```

At the MATLAB prompt, type

`rsRunTests`

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

## Why are the simulation times in exported .m files different from those in .rst files?#

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, a 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.

## Why do I need to turn interpolation off for top-level inports when running test suites generated by Reactis in Simulink?#

See the answer to Question above.

## Why are the output values produced by Reactis different from those produced by Simulink?#

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.