Architecture de monitoring avec des PUSMs

Une fois que la vérification hors-ligne du modèle a été effectuée, le modèle UML peut être déployé sur une cible embarquée. Pour continuer la vérification des propriétés monitorables à l’exécution, il est possible d’embarquer tous les PUSMs représentant des automates obser-vateurs déterministes. Contrairement au model-checking qui vérifie le modèle hors-ligne avec un environnement abstrait, le monitoring permet la vérification du système en ligne dans un environnement réel.

corres-9.4. Model-checking et monitoring avec des machines à états UML

FIGURE9.5 – Architecture utilisée pour le monitoring avec des PUSMs.

pond à une application de l’architecture en section 5.4.5. Le composant d’Exécution synchrone de modèles utilisé en model-checking est réutilisé pour le monitoring avec les mêmes modèles pour le système (Modèle du système) et la propriété (Modèle de la propriété). Néanmoins, cette fois le composant d’Exécution synchrone est relié aux entrées/sorties réelles (I/O) de la cible embarquée et la Politique d’ordonnancement réelle du système est utilisée plutôt qu’une abstraction. À chaque pas d’exécution, l’ordonnanceur sélectionne une et une seule transition à tirer parmi la liste des transitions tirables du système. Pour le monitoring, le choix de la pro-chaine transition à tirer est fait avant d’appliquer la composition synchrone (cf. section 5.5.2) afin d’éliminer les risques d’interférence sur le monitoring du système et garder de bonnes per-formances d’exécution. Pour piloter le composant d’Exécution synchrone de modèles, la Boucle d’exécution principale de la plateforme d’exécution est utilisée comme contrôleur d’exécution. À chaque pas d’exécution, le contrôleur d’exécution délègue la vérification des propriétés for-melles au composant d’Assertion d’acceptation. Ce dernier vérifie si les automates observa-teurs ont atteint leurs états d’acceptation via l’interface Accet met à jour le Statut de monitoring indiquant si une défaillance est survenue.

obser-vateurs déterministes que ceux utilisés durant la phase de vérification formelle peuvent être déployés sur une cible embarquée. Ces automates peuvent ainsi être réutilisés sans effort (c.-à-d. sans transformation de modèles, sans réécriture et sans génération de code) pour faire du monitoring à l’exécution. Malgré les possibilités offertes par la vérification hors-ligne, il reste utile de surveiller l’exécution du système pour plusieurs raisons. Premièrement, si l’abstrac-tion de l’environnement utilisée pour le model-checking est incomplète ou mal définie, il est possible que tous les cas d’exécution réels n’aient pas été couverts et que la vérification soit passée à côté d’une erreur de conception. Deuxièmement, à cause des problèmes d’explo-sion de l’espace d’état, il n’est pas toujours possible de vérifier des propriétés monitorables par model-checking. Avec notre approche, la véracité de ces propriétés peut toujours être sur-veillée à l’exécution par monitoring sans avoir besoin de transformations de modèles. Un autre bénéfice est que le monitoring peut détecter des violations de propriétés causées par des com-posants hardware défectueux, ce qui n’est pas possible avec le model-checking. Lorsqu’une défaillance est détectée, les PUSMs peuvent simplement notifier le problème à l’utilisateur (p. ex. en affichant un message d’erreur) ou activer des mécanismes de sûreté de fonctionnement (p. ex. de recouvrement d’erreurs). Enfin, les traces des automates observateurs peuvent être utilisées en analyse post-mortem pour comprendre pourquoi une défaillance est apparue dans le système.

En ce qui concerne les limitations de notre approche, l’utilisation d’automates observateurs en monitoring induit un surcoût en termes d’empreinte mémoire et de performance d’exécution comme la plupart des activités de monitoring. Un compromis entre l’efficacité de la vérification et les performances d’exécution doit être trouvé pour chaque contexte. Un autre inconvénient est que le monitoring peut seulement détecter la présence d’erreurs mais ne peut pas prouver leur absence. Le monitoring, contrairement à la vérification formelle exhaustive, observe les pas d’exécution du système en interaction avec l’environnement réel. Par conséquent, son efficacité dépend de la couverture des défaillances fournie par les moniteurs embarqués avec le système.

9.5 Synthèse

La spécification de propriétés sous forme de PUSMs permet de faciliter l’expression de ces propriétés par les ingénieurs. En effet, le langage de modélisation du système est également utilisé pour modéliser les propriétés formelles tout en réutilisant le langage d’observation pour l’expression des propositions atomiques (ici les gardes des transitions des PUSMs). L’exécu-tion des PUSMs est pilotée à travers l’interface de contrôle d’exécuL’exécu-tion et est composée de façon synchrone avec l’exécution du système. Pour la vérification hors-ligne, l’espace d’état du produit synchrone est exploré avec un model-checker pour vérifier que les propriétés encodées

9.5. Synthèse

par les PUSMs ne sont pas violées. Pour le monitoring, tous les automates observateurs déter-ministes utilisés lors de la vérification hors-ligne peuvent être déployés sur une cible embarquée sans utiliser de transformations de modèles et d’instrumentation de code. Cette technique per-met ainsi d’unifier le model-checking et le monitoring de modèles UML en assurant que les propriétés utilisées pour le monitoring sont exactement celles utilisées pour le model-checking.

TROISIÈME PARTIE

EXPÉRIMENTATIONS

Sommaire

10.1 Introduction . . . 159 10.2 Présentation de l’outil EMI-UML . . . 159 10.3 Présentation des cas d’études . . . 161 10.3.1 Contrôleur de passage à niveau . . . 161 10.3.2 Interface d’un régulateur de vitesse . . . 162 10.4 Mise en œuvre des activités d’analyse de modèles . . . . 163 10.4.1 Simulation interactive . . . 164 10.4.2 Débogage multivers . . . 165 10.4.3 Model-checking LTL et détection de deadlocks . . . 166 10.4.4 Model-checking avec l’ordonnanceur . . . 169 10.4.5 Model-checking avec des PUSMs . . . 172 10.4.6 Model-checking des mécanismes de sûreté de fonctionnement . . . . 176 10.4.7 Exécution embarquée et monitoring . . . 177 10.4.8 Évaluation des performances d’exécution . . . 178 10.5 Expérimentations avec d’autres outils . . . 180 10.5.1 EMI-LOGO : un interpréteur de modèles LOGO . . . 180 10.5.2 AnimUML : un outil d’interprétation et d’animation de modèles UML . . 181 10.5.3 Intégration d’EMI-UML dans Gemoc Studio . . . 183 10.6 Synthèse des expérimentations . . . 184 10.7 Contributions scientifiques . . . 185

10.7.1 C#1 Contribution à l’unification de l’analyse et de l’exécution embar-quée de modèles . . . 185 10.7.2 C#2 Contribution à l’adoption des techniques de vérification formelle

par les ingénieurs . . . 187 10.8 Synthèse . . . . 188

10.1. Introduction

10.1 Introduction

Après avoir exploré les possibilités offertes par l’architecture candidate, il est temps de la mettre en pratique pour évaluer son applicabilité. À ce titre, trois questions de recherche ont été formulées pour évaluer et valider l’approche EMI à travers différentes expérimentations.

V#1 Quel est l’effort nécessaire pour concevoir un interpréteur pilotable et y connecter différents outils d’analyse ?

V#2 L’interface de contrôle d’exécution est-elle suffisamment générique pour répondre aux besoins des différentes activités d’analyse ?

V#3 L’approche EMI facilite-t-elle l’analyse de l’exécution des modèles ?

Pour répondre à ces questions, la section 10.2 présente l’interpréteur de modèles UML conçu pendant cette thèse comme preuve de concept principale de l’approche EMI. Cet interpréteur a notamment été mis en œuvre sur deux cas d’études de systèmes embarqués présentés en section 10.3 : un contrôleur de passage à niveau et l’interface utilisateur d’un régulateur de vitesse. Dans la section 10.4, diverses activités d’analyse sont menées sur ces deux cas d’études en utilisant notamment le model-checker OBP2 pour simuler, déboguer et vérifier formellement l’exécution de ces modèles.

Pour montrer la versatilité de l’approche EMI, la section 10.5 présente d’autres expérimen-tations avec différents interpréteurs de modèles conformes à l’approche EMI et différents outils d’analyse permettant d’éprouver l’architecture candidate et son interface de contrôle d’exécu-tion. Une synthèse de ces expérimentations est réalisée en section 10.6 pour répondre à V#1, V#2 et V#3. Enfin, la section 10.7 met en lumière les contributions revendiquées par cette thèse en s’appuyant sur les résultats de ces expérimentations.