Simulation of Cyber Physical Systems with FMI 2.0

Cyber Physical Models combine event driven and clock driven elements, critical parts and non critical parts. For that purpose PragmaDev Studio V5.3 supports Functionnal Mockup Interface FMI V2.0. The tool imports a Functionnal Mockup Unit (FMU) and analyzes its inputs and outputs. A mapping between the SDL model and the FMU is then defined through a specific interface. Both co-simulation and model exchange modes are supported. PragmaDev Studio acts as a "master" / "importing" tool.

As a typical example one can now combine a PragmaDev model with a Scade model and simulate them together. To illustrate this kind of situation two FMI integration examples come with PragmaDev Studio:

• A basic OpenModelica water tank.
• A more advanced one with Ansys Scade cruise control.

Live FMI presentation during the V5.3 webinar:

Raspberry Pi

An integration example with the Raspberry Pi 3 Model B+ is available to easily start modeling with this very successful and cheap board. The Raspberry Pi is an ARM based board running Raspbian, a dedicated Debian Linux distribution. It comes with extension boards such as the Sense Hat that has an 8×8 LED matrix, a joystick and includes a set of sensors.

As a prerequisite, the example requires:

• The Raspberry GCC cross compiler,
• PuTTy utilities.

The example is an application running on the Raspberry Pi that interacts with the Sense Hat peripherals. The model is designed using SDL-RT. The architecture of the system is made of a process for each peripheral and one orchestrator. Each process is a finite state machine with an implicit message queue. They all run in parallel. There is a finite state machine to handle the LED matrix, one for the gyroscope, the joystick and the pressure. A central controller gathers all of the information. The interesting aspect of this example is that it demonstrates how to deal with a continuous device such as the gyroscope as well as an event base device such as the joystick all together in an event based model.

• The joystick process uses the input event interface from Linux with a blocking call. When nothing happens the state machine hangs on the poll call. When the joystick is moved it unblocks the call, the action is read, and the information is sent to the controller. It then loops back to the blocking poll call.
• For the gyroscope it is a bit different because the gyroscope is not natively an event based peripheral. The model reads the angle values ten times per second and if any of the angles has changed, the new information is sent to the controller. If the angles did not change, no information is sent to the controller making it much more efficient. The same principle applies to the temperature sensor.
• The last state machine is the LED matrix handler. It can switch on or off a 2 by 2 square (with PragmaDev corporate colors for each LED), or it can display a number between 0 and 99.

The code generation is based on the posix integration, the GCC ARM cross compiler, pscp to copy the generated executable on the target, and plink to start it in gdb environment.