Removing events from models to improve real-time performance

When running a model as part of Hardware in the Loop (HIL) testing it is important that the model simulates fast enough so that overruns do not occur. Unfortunately when events occur this can cause a model to run significantly slower for that simulation time. A workaround is to remove events from the model, this post looks at different ways this can be done.

What is Hardware in the Loop testing?

Hardware in the loop simulating is a way of testing hardware that makes use of a model as part of the system to create inputs to the hardware being tested (See ‘What is Hardware-in-the-Loop’ explained by NI for a more detailed description). These models need to be able to run in real-time.

What does it mean that “a model to be able to run in real-time”?

The model used needs to be able to run fast enough so that the inputs to the hardware are available in time. A common approach is to run the model with a fixed step solver, and ensure that the amount of time to solve the model equations at each simulation time is less than the time step used by the controller. An example where the amount of time to calculate the time step is more than the step time used is given in Figure 1.

Figure 1. Turn-around time for a simulation using a fixed step solver with a step size of 0.001[s]. Note that there are a number of overruns, times where the amount of time to calculate the solution of the model exceeds the step-size.

The model simulated in Figure 1 was using an inlined Euler solver with a time step of 0.001[s] this means that for the model to be able to run in real-time the model needs to be able to solve the model equations at each time step faster than 0.001[s]. In this case there are 4 times where the amount of time to solve the equations (i.e. the turn-around time) is longer than 0.001[s] which can be seen in Figure 1 where the blue line is above the red line.

Common causes of overruns in models

Here is a list of common causes of overruns in models with possible solutions:

Issue	Solution	Related blog post
The model is mostly overrunning	Make the model run faster * Use profiling * Use a Real-Time solver – use Simulation>Setup on the Realtime tab * Set the Dymola flags that improve performance – use Claytex.Functions.RealTime.run * Simplify the model – turn off unnecessary features such as animation – remove numerical Jacobians – reduce non-linear equations – improve initialisation – reduce the model stiffness so the solver step can be larger * Try different C compilers	Profiling Stability issues Setting flags Analytic Jacobians Example Using filters Fluid models General advice Initialisation Compilers
Occasional spikes	Determine the cause of the spikes using profiling * For event detection also use Simulation Analysis – remove events * Non-linear Jacobian is being updated – Use an explicit Euler solver	This blog post looks at ways to remove events

Table 1. Issues and possible solutions

Table 1 gives a list of issues and the possible solutions, with references blog posts that give further information about the different possible solutions.

Why do events cause the model to be slow?

An event occurs at a discrete change in a value, when Dymola detects that an event has occurred Dymola searches for the exact simulation time that the discrete change occurs (refer to A closer look at Dymola events for more details) and then tests the model consistency. This process can result in the model equations being solved multiple times apposed to being solved only once.

What Modelica code generates events?

Events can be generated by a number of different ways, for example the triggering of when conditions, an if condition changing, clocks triggering, some functions like sample, mod and other functions can generate events, Boolean and Integer values changing and possibly other ways as well.

Some ways to remove events from Modelica code

One way to remove events from Modelica code is to put the Modelica code into a function and ensure that the function is not inlined (see A closer look at Inline). This may not always be possible or easy to implement.

One other way to remove events is to make use of the noEvent inbuilt operator.

Using noEvent to remove events from if conditions

if statements typically generate events, this is because the conditional behaviour of the if statement can create a discrete change in any variables being assigned in the if statement (see Figure 2). However if the value being assigned is continuous then noEvent can be used around the if condition to avoid an event being generated (see the example on the left side of Figure 2, in this example it may be more efficient to use y = smooth(0,if x>0 then x else 0) see Modelica Specification for more information about noEvent and smooth). It is possible to put noEvent around conditions that result in discrete changes in a value, see the right hand example in Figure 2. See Section 13.5 of the Dymola Full User Manual for more information about noEvent.

Figure 2. Examples of noEvent being used on if conditions

Putting noEvent around if conditions that generate discrete changes is not safe and may result in the simulation failing. Also the simulation results will be less accurate, because the exact time that the event occurs is not detected so the solver will assume that the value that changes discretely is held until the next simulation time and it may even miss that the event occurred at all if the event toggles before the next time step (see Why the solver sometimes ignores u). Using a fixed step solver with a small time step reduces the inaccuracies caused by using noEvent.

Removing events from Boolean and Integer values changing

When Boolean and Integer values change, an event is generated; a method to get around this is to use real values instead of Boolean or Integer values. For example instead of using a Boolean value with false and true, use 0 and 1. This will mean having to rewrite the Modelica code to support real values as has been done in the Claytex.Blocks.Logical.Eventless and Claytex.Blocks.Logical.EventlessReals packages.

An example of using the Claytex.Blocks.Logical.Eventless blocks to remove events

The Claytex.Blocks.Logical.Eventless package contains logic blocks that implement the ideas above and other methods to remove events. An example of where these logical blocks have been used is in Figure 3.

Figure 3. Heating system example, one of two controllers can be used:
* the Original controller that generates events
* the Eventless controller that makes use of a Claytex.Blocks.Logical.Eventless class that does not generate events

This example in Figure 3 is based on the Modelica.Fluid.Examples.HeatingSystem model that has been modified by adding in a controller to maintain a temperature of around 300K.

The Orignal controller in Figure 3 makes use of the Modelica.Blocks.Logical.OnOffController and Modelica.Blocks.Math.BooleanToReal classes that generate events when the Boolean output of the controller changes. The Eventless controller makes use of the Claytex.Blocks.Logical.Eventless.OnOffXController that does not generate events. The turn-around times for a simulation of the HeatingSystem model with the eventless controller are in Figure 4.

Figure 4. Turn-around times for the simulation of the heating system (Figure 3) with an eventless controller and a solver step size of 0.001 [s]

In Figure 4. note that there are no large spikes that are generated by events such as can be seen in Figure 5.

Figure 5. Heating system with the original controller that generates events. The overrun near 42[s] is due to an event, some of the other higher spikes are also due to events.

Comparing Figure 4 with Figure 5 shows that using the eventless controller gets rid of the overrun. The HeatingSystem model is small and the amount of time to solve the model equations is low, on average less than 0.002[s]. For models that are on average slower the overruns caused by events gets larger, and so it becomes more important with larger slower models to remove events.

In Figure 6 the controlled temperature T_return is compared between using the original controller and the eventless controller.

Figure 6. Comparing T_return between original controller and eventless controller

In Figure 6. there is a difference between the results of the T_return temperatures of the simulations when different controllers are used. This is expected as the Original controller will find the exact time that the events occur at effectively updating the controller outputs earlier than the eventless controller which performs the update at the fixed time step. Note that even when a fixed step inline solver is being used, events are searched for and Dymola scales simulation times accordingly so that the results are accurate, for more details; see Options for implicit inline integration in Section 11.3.3 of the Dymola Full User Manual.

Conclusion

A number of different methods have been mentioned that can be used to remove events from models. This can reduce spikes in the turn-around time of a simulation.

A method to remove events by using the noEvent is given, which can reduce events at the cost of simulation accuracy and stability. Typically we have not seen stability issues related to this however it is something to keep in mind if stability issues occur.

Removing events can reduce the maximum turn-around time and reduce accuracy as described in the heating system example above.

Typically a fixed solver will be used when eventless logic is being used as this will limit inaccuracies. Unintuitively, overall simulation time can be faster with events being present in a model.

Written by: Garron Fish – Chief Engineer

Please get in touch if you have any questions or have got a topic in mind that you would like us to write about. You can submit your questions / topics via: Tech Blog Questions / Topic Suggestion