Une fois le code exécutable de l’interpréteur EMI produit, celui-ci peut être déployé soit sur une cible embarquée soit sur un PC de développement. Le déploiement peut être fait de deux façons :
— En bare-metal (c.-à-d. sans OS) : l’interpréteur interagit directement avec le hardware de la cible embarquée (valable uniquement pour le déploiement sur une cible embarquée) ;
8.7. Synthèse
— Sur un OS (p. ex. Linux) : l’interpréteur utilise les services de l’OS et la couche d’abs-traction matérielle qu’il fournit (valable pour le déploiement sur une cible embarquée ou un PC de développement).
Pour interagir avec l’environnement réel, une API de haut niveau permet de communiquer avec les périphériques d’entrées/sorties de la plateforme d’exécution. Cette API permet de ré-cupérer les informations fournies par les capteurs mais aussi de piloter les actionneurs. Elle est indépendante des spécificités du matériel ce qui permet à un modèle donné d’être facilement déployable sur de multiples cibles embarquées. Pour chaque type de carte, une implémen-tation de cette API doit alors être fournie pour s’adapter au firmware de chaque plateforme d’exécution.
Application à UML. Dans le contexte d’UML, nous avons mis en place une solution pour le déploiement de modèles dans notre contribution en [Bes+20]. La modélisation du système à l’étude est réalisée dans plusieurs fichiers représentant le système, les interfaces et signaux échangés, et l’environnement. Un dernier fichier décrit la structure composite principale, appe-lée Main, permettant de connecter ensemble le système et son environnement (réel ou abs-trait). Chaque fichier peut faire des références externes vers d’autres fichiers grâce au concept d’ElementImport d’UML et à des identifiants (IDs) XMI “stables”. Le nom qualifié des objets est utilisé comme XMI IDs à la place des XMI IDs usuels qui ne sont pas lisibles par l’homme. Ces XMI IDs sont dits “stables” car ils peuvent être partagés par plusieurs fichiers.
Cette technique permet ainsi de concevoir des modèles UML modulaires dans lesquels le modèle d’environnement est interchangeable. En effet, une abstraction de l’environnement réel, utilisée en vérification formelle, peut facilement être remplacée par un modèle d’environ-nement décrivant les liens avec les périphériques de la plateforme d’exécution. Ainsi, exacte-ment la même modélisation du système est utilisée pour toutes les activités d’analyse et pour l’exécution sur une cible embarquée.
8.7 Synthèse
Dans ce chapitre, une méthodologie de conception permettant de construire un interpréteur EMI pour un langage de modélisation donné a été proposée. Avec cette méthodologie, un interpréteur EMI satisfait aux exigences identifiées dans les chapitres précédents. L’interpréteur de modèles peut être déployé sur une cible embarquée et la sémantique opérationnelle qu’il implémente est pilotable et déterministe ce qui permet de l’utiliser à la fois pour l’exécution réelle et les activités d’analyse.
Avec l’architecture d’analyse et l’implémentation de l’interface STR (cf. chapitre 7), l’exé-cutable produit peut être utilisé pour mettre en œuvre toutes les techniques d’analyse du chapitre 5 (c.-à-d. simulation interactive, débogage multivers, détection de deadlocks,
model-checking et monitoring) et les opérateurs du chapitre 6 pour ordonnancer l’exécution du mo-dèle. Pour illustrer ces propos, des détails supplémentaires ont été donnés pour appliquer cette méthodologie au langage UML. Ce même langage va maintenant servir d’exemple pour mon-trer comment les techniques de vérification formelle peuvent être mises en œuvre de façon plus spécifique sur UML à l’aide d’un interpréteur EMI.
CHAPITRE9
U
NIFICATION DU MODEL
-
CHECKING ET
DU MONITORING DE SPÉCIFICATIONS
UML
EXÉCUTABLES
Sommaire
9.1 Introduction . . . 141 9.2 Expression de propriétés dans le langage de modélisation . . . 142 9.2.1 Modélisation de propriétés en UML . . . 142 9.2.2 Modélisation des automates de Büchi en UML . . . 143 9.2.3 Modélisation des automates observateurs en UML . . . 145 9.2.4 Conversion des propriétés LTL en PUSMs . . . 146 9.3 Composition synchrone . . . 148 9.3.1 Mise en œuvre de la composition synchrone . . . 148 9.3.2 Ajout de transitions implicites . . . 148 9.3.3 Composition synchrone avec un automate de Büchi . . . 150 9.3.4 Composition synchrone avec un automate observateur . . . 150 9.4 Model-checking et monitoring avec des machines à états UML . . . 150 9.4.1 Architecture de model-checking avec des PUSMs . . . 151 9.4.2 Architecture de monitoring avec des PUSMs . . . 152 9.5 Synthèse . . . . 154
Ce chapitre est partiellement adapté de notre contribution en [Bes+19d].
9.1 Introduction
Pour vérifier et monitorer l’exécution de modèles, les ingénieurs se heurtent à deux pro-blèmes principaux. (i) D’une part, les langages utilisés pour spécifier des propriétés formelles sont généralement différents des langages utilisés pour modéliser des systèmes. L’expression de propriétés dans un langage formel est donc une tâche complexe pour les ingénieurs sans
expertise dans ce domaine. (ii) D’autre part, les automates des propriétés utilisés en model-checking ne peuvent pas être réutilisés tels quels pour monitorer l’exécution du système. Des techniques de transformation de modèles et d’instrumentation de code doivent généralement être utilisées pour déployer ces automates sur la plateforme d’exécution réelle.
Pour apporter une solution à ces problèmes dans le cadre d’UML, la section 9.2 présente le concept de Property UML State Machines (PUSMs) pour exprimer des propriétés formelles directement en UML. Chaque PUSM est interprété avec la même sémantique d’UML que le modèle du système. La section 9.3 décrit les spécificités de la composition synchrone d’un PUSM avec l’exécution du système. Enfin, la section 9.4 présente l’architecture logicielle per-mettant d’utiliser les PUSMs en phase de model-checking ou de déployer ces mêmes PUSMs sur la cible embarquée pour continuer la vérification à l’exécution (via monitoring).