Simulation des systèmes cyber-physiques avec l'interface FMI 2.0

Les modèles cyber-physiques combinent des éléments basés sur des évènements et d'autres basés sur des horloges, des parties critiques et d'autres non critiques. Pour cela PragmaDev Studio V5.3 introduit le support de l'interface de maquette fonctionnelle FMI V2.0. L'outil permet d'importer une unité de maquette fonctionnelle (FMU) et analyse ses entrées et ses sorties. Une interface spécifique permet de connecter le modèle SDL et le FMU. Les deux modes, co-simulation et échange de modèles, sont supportés. PragmaDev Studio se comporte en tant qu'outil maitre / importateur.

Un cas d'utilisation typique serait de simuler ensemble un modèle PragmaDev et un modèle Scade. Pour illustrer cette situation deux exmples d'intégration FMI sont livrés avec PragmaDev Studio.

• Un modèle OpenModelica simple de réservoir d'eau.
• Un modèle Ansys Scade plus avancé de régulation de vitesse.

Présentation du FMI lors du webinaire de la V5.3:

Raspberry Pi

Un exemple de modèle PragmaDev Studio intégré avec la Raspberry Pi 3 Model B+ est disponible afin de faciliter la prise en main de cette carte dont la popularité n'est plus à démontrer. La Raspberry Pi est une carte basée sur un processeur ARM avec Raspbian, une distribution Linux dérivée de debian. Des cartes d'extension sont disponibles comme la Sense Hat qui est équipée d'une matrice de LED 8x8, d'un joystick, et différents capteurs.

Comme pré-requis l'exemple nécessite:

• Le compilateur croisé Raspberry GCC,
• Les utilitaires PuTTy.

L'exemple est une application s'exécutant sur la Raspberry Pi et qui intéragit avec les différents périphériques Sense Hat. Le modèle est décrit en SDL-RT. L'architecture du système est composé d'un process par périhérique et d'un pour l'orchestrateur. Chaque process est une machine d'état avec une file de messages implicite. Ils s'exécutent tous en parallèle. Il y a une machine d'état pour la matrice de LED, une pour le gyrsocope, une pour le joystick et une pour le capteur de pression. Un controlleur central réunit toutes les informations. L'aspect intéressant de ce modèle vient du fait qu'il démontre comment gérer des périphériques continus comme le gyroscope aussi bien que les périphériques évènementiels comme le joystick, ensemble, dans un modèle évènementiel.

• Le process joystick utilise l'interface évènementielle de Linux avec un appel bloquant. Quand rien ne se passe la machine d'état est en attente sur l'appel de la fonction. Quand le joystick est actionné l'appel est débloqué, l'évènement est lu, et l'information est envoyé vers le controlleur. L'exécution boucle et retourne sur l'appel bloquant.
• L'approche est différentes pour le gyroscope car c'est un périphérique qui n'est pas nativement basé sur des évènements. Le modèle lit les angles 10 fois par secondes et l'information n'est envoyée au controlleur que si un angle a changé. Si les angles n'ont pas changé, aucune information n'est envoyé pour éviter des transfers d'information inutiles. Les mêmes principes sont utilisés pour le capteur de température.
• La dernière machine d'état gère la matrice de LED. Elle peut allumer ou éteindre un carré de 2 par 2 (constitué des couleurs PragmaDev), ou elle peut afficher un nombre entre 0 et 99.

La génération de code s'appuie sur l'intégration posix, le compilateur croisé GCC pour ARM pscp pour copier l'exécutable sur la cible, et plink pour le démarrer dans l'environnement gdb.