As the name suggests, software-in-the-loop simulation sees a piece of software (known as an app) form part of the simulation loop. The app could be a representation of a real-life control module or component, or it could be a control algorithm, which often requires development and calibration with respect to a real human driver’s inputs in a real time (driver-in-the-loop) environment. Vehicle control systems are typically built using Simulink and, on the face of it, interfacing a Simulink model with a Dymola vehicle model sounds challenging; however it is in fact a relatively straight forward process. Rather than a step-by-step detailed guide on interfacing Dymola and Simulink apps in real time, this blog post will present the ease of the concept which enables this to be possible.
Typical real-time environment
One of the standard ways of conducting driver-in-the-loop simulation is to interface a Dymola vehicle model compiled as an app with the rFPro simulation environment, using a framework plug-in such as vTAG or PTWinSim, presented graphically in figure 1. Virtual slots within the vTAG/PTWinSim plug-ins enable different apps to be loaded into rFpro, in much the same way motherboards have slots for RAM or physical memory drives.
Figure 1: Real time architecture and interaction
What rFPro provides, in a nutshell, is the physical environment the vehicle model will interact with as well as the graphical interface/display the driver sees. This environment is formed from a laser-scan (LiDAR) point cloud map of a real location (such as a racing circuit or public road), overlaid with textures and graphical objects to recreate the physical location in detail. rFPro will provide the environment data to the vehicle model, such as ground position data to the vehicle tyre model in addition to handling crash/collision physics regarding body contact with barriers and other environmental furniture. The interface between rFpro and the vehicle model app is defined by auxiliary apps loaded into the framework plug-in alongside the compiled vehicle model app.
These framework plug-ins enable the Dymola vehicle model app to communicate with other apps, such as the Simulink controller model app we are using as an example, or the inputs/outputs conversion app mentioned above. But crucially they do not define the interaction that takes place, merely enabling it to occur. Intuitively therefore, the vehicle model must have a method with which to communicate with other apps.
Concept of communication
Communication between apps is governed by matching the string name of a variable in one app to the variable string name in another app. So, for instance, vehicle lateral acceleration data from the Dymola vehicle model which is to be fed into a Simulink controller would require the variable name in both the Dymola vehicle model and the Simulink controller to have precisely the same string name. The same principle applies with the data passed between rFpro and the interface apps converting the variable names to ones which match variables within the Dymola vehicle model.
When vTAG/PTWinSim cannot match a global variable found in one app with a corresponding global variable in another app, an error message is issued via the rFpro terminal /log pertaining to the variable unable to be matched. It is important to note however, this error message does not halt the simulation. The unconnected variable will be set to zero, which may cause the model to crash, however.
Which variables to match, and which to ignore?
Now, there can be thousands upon thousands of variables within a vehicle model and many variables within an example Simulink controller too, but this doesn’t mean each and every variable requires a unique name to govern which variables are to be matched and which are to be ignored. Only specifically designated variables from different apps are available for matching; different methods achieve this distinction in the Dymola vehicle model and Simulink controller. A variable from one app which is eligible to be matched in this way shall be considered global in the context of the vTAG/PTWinSim plug-in.
When the Dymola model is compiled as an app only specific types of variables are designated as global and matched to variables in other apps by the vTAG/PTWinSim plug-in. Top level inputs and outputs, parameters that are not evaluated and signals on public expandable buses in the Dymola model are designated as global by the vTAG/PTWinSim plug-in.
A good example is to look at the top level of a Dymola vehicle model which is ready to be compiled for usage in rFpro, such as the one in Figure 2; all of the input and output blocks declared at the top level become global variables when the model is compiled. This example, produced by Claytex, is from the DiL (Driver-in-the-Loop) library which provides templates as well as example vehicle models ready for export as apps to be used in rFpro. The BuildModel function found within the DiL library makes exporting the vehicle model a very simple exercise.
Figure 2 – Typical vehicle model ready to be compiled into a real time app.
Creating global variables to interface the Simulink app with other apps is a bit trickier. Auxiliary blockset libraries which plug into Simulink are available, which make the job simpler. One such example is the @Source blockset available from Podium Technologies. Blocks included in this blockset enable internal Simulink data channels to be written to a globally visible string variable when the app is compiled, thus enabling the outputting of data from the Simulink app to other apps. In addition, there are blocks capable of importing data into the Simulink model from global variables in other apps, using the string name as specified in the block, thus providing a way of supplying data channels to the Simulink app from other apps. Other features include the ability to expose parameter variables globally as well, if the user wishes.
The upshot of this is that creating a software-in-the-loop simulation comprising of a Dymola and a Simulink model is a relatively straightforward concept, and an efficient way of conducting software-in-the-loop simulation.
Written by: Theodor Ensbury – Project 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