10.4 Mise en œuvre des activités d’analyse de modèles
10.4.5 Model-checking avec des PUSMs
Cette section illustre la spécification de PUSMs pour le modèle d’interface du régulateur de vitesse et leur utilisation en model-checking avec OBP2 et EMI-UML. Pour cette expérimenta-tion, deux questions de recherche ont été prises en compte :
RQ#6 Les propriétés formelles peuvent-elles facilement être spécifiées avec des PUSMs ? RQ#7 Les résultats de model-checking obtenus avec des PUSMs sont-ils comparables à
ceux obtenus par model-checking des propriétés LTL équivalentes ?
10.4.5.1 Spécification de PUSMs
Avant de pouvoir effectuer la vérification formelle, les exigences de l’interface du régulateur de vitesse doivent être exprimées sous forme de PUSMs. Les propriétés de vivacité (corres-pondant aux exigencesE1IRV,E2IRV,E3IRV) ont été encodées sous forme d’automates de Büchi et les propriétés de sûreté (correspondant aux exigencesE4IRV,E5IRV,E6IRV) ont été exprimées sous forme d’automates observateurs. Les gardes de ces automates sont exprimées dans le langage d’observation d’EMI-UML. Les expressions de ces propositions atomiques sont don-nées dans la section E.2.
La Figure 10.8 présente les machines à états des PUSMs représentant des automates de Büchi pourE1IRV,E2IRV etE3IRV. Le model-checker ne pouvant utiliser qu’un seul automate de Büchi à la fois, les trois PUSMs de la Figure 10.8 peuvent être combinés en un seul afin de vérifier les trois propriétés simultanément (cf. section 9.2.2). L’automate résultant est illustré sur la Figure 10.9.
Pour les automates observateurs, les machines à états des PUSMs correspondant aux exigencesE4IRV,E5IRVetE6IRVsont illustrées sur la Figure 10.10. Les automates Observateur4, Observateur5 et Observateur6 sont des automates observateurs déterministes qui peuvent être utilisés en monitoring. L’automate ObservateurND est un exemple d’automate observateur non-déterministe combinant la vérification des exigencesE5IRVetE6IRV. Cet automate est non-déterministe car les états Engaged et Disengaged ont deux transitions sortantes qui peuvent être tirables au même instant puisque leurs gardes peuvent être vraies en même temps.
10.4. Mise en œuvre des activités d’analyse de modèles
(a) Büchi1 pour E1IRV (b) Büchi2 pour E2IRV (c) Büchi3 pour E3IRV
FIGURE10.8 – Machines à états des PUSMs (représentant des automates de Büchi) pour le modèle d’IRV.
FIGURE 10.9 – Combinaison de plusieurs PUSMs en un pour vérifierE1IRV, E2IRV et E3IRV si-multanément.
(a) Observateur4 pour E4IRV (b) Observateur5 pour E5IRV
(c) ObservateurND pour E5IRVet E6IRV (d) Observateur6 pour E6IRV FIGURE10.10 – Machines à états des PUSMs (représentant des automates observateurs) pour le modèle d’IRV.
Tous ces PUSMs peuvent maintenant être utilisés en vérification formelle pour analyser le comportement de l’interface du régulateur de vitesse.
10.4.5.2 Model-checking du comportement du système
Le model-checking à l’aide des PUSMs a été mis en œuvre avec l’architecture de la Fi-gure 9.4.
Pour les propriétés de vivacité, la vérification a été réalisée en utilisant l’algorithme “nested DFS” [GS09] pour la détection de boucles d’acceptation et l’interpréteur EMI-UML pour exécu-ter le modèle du système et les PUSMs. Chaque automate de Büchi a été utilisé séparément pour vérifier le comportement du système et aucune défaillance n’a été détectée par OBP2. Le PUSM de la Figure 10.9 résultant de la combinaison des trois PUSMs pourE1IRV,E2IRVetE3IRV confirme également ce résultat en model-checking.
Pour les propriétés de sûreté, la vérification réalisée avec un algorithme d’atteignabilité montre que les exigencesE4IRV etE5IRV sont satisfaites et que l’exigenceE6IRV est violée. En conséquence, la propriété encodée par l’ObservateurND qui est une combinaison de E5IRV et
E6IRV est aussi violée.
Pour vérifier la validité de notre approche, ces résultats ont été comparés aux résultats obtenus par model-checking des propriétés LTL équivalentes. Ainsi, toutes les exigences de
10.4. Mise en œuvre des activités d’analyse de modèles
l’interface du régulateur de vitesse ont été spécifiées en LTL avec des propositions atomiques exprimées à l’aide du langage d’observation d’EMI-UML.
P1IRV "[] (|evStop| -> (<> |ccsDisengaged|))"
P2IRV "[] ((|ccDisengaged| && |evSet|) -> (<> |ccEngaged|))" P3IRV "[] ((|canResume| && |evThrottleReleased|) ->
(|evThrottleReleased| U |evResume|))" P4IRV "(!|evUpdateSetPoint| W |evOn|) &&
([] (|evOff| -> (!|evUpdateSetPoint| W |evOn|)))" P5IRV "[] (|intervalCS| or |unknownCS|)"
P6IRV "[] (|ccsEngaged| -> !|unknownCS|)"
En comparaison avec les PUSMs, certaines de ces propriétés LTL ont des expressions plutôt complexes car elles requièrent la connaissance des opérateurs LTL et notamment des opérateurs temporels (p. ex. globally, weak until) (cf. RQ#6). En particulier, la propriétéP4IRVa demandé un travail de réflexion important pour pouvoir être exprimée en LTL alors que l’auto-mate observateur correspondant (Figure 10.10a) a été trivial à concevoir en UML.
Réponse à RQ#6 (Expression des propriétés) Les ingénieurs peuvent facilement spéci-fiées des propriétés formelles sous forme de PUSMs s’ils maîtrisent les concepts du langage UML.
Le model-checking de ces propriétés LTL montre que toutes les propriétés sont vérifiées excepté la propriété P6IRV. Ces résultats basés sur les propriétés LTL sont donc identiques à ceux obtenus avec les PUSMs (cf. RQ#7). Pour comprendre pourquoi l’exigence E6IRV n’est pas satisfaite, il faut analyser le contre-exemple retourné par OBP2. Ce contre-exemple montre que lorsque l’objet controller de l’IRV va de l’état Engaged à l’état Off, les évènements disen-gage et resetCS sont tous les deux envoyés en même temps (cf. Figure 10.11a). Cependant, l’ordonnanceur du système peut choisir de traiter l’évènement resetCS en premier ce qui met
(a) Version initiale. (b) Version corrigée.
la vitesse de croisière à une valeur indéfinie (c.-à-d. -1) alors que le système est toujours en-gagé. La Figure 10.11b montre comment corriger le problème. Un état intermédiaire, appelé ici WaitDisengaged, doit être ajouté pour envoyer l’évènement disengage en premier, attendre son acquittement et enfin envoyer l’évènement resetCS. Le problème était donc dû à une erreur subtile d’entrelacement d’évènements. Avec les PUSMs, la trace de l’automate de Büchi est directement exprimée avec des concepts UML ce qui simplifie encore un peu plus l’analyse du contre-exemple en comparaison au model-checking LTL (cf. RQ#2). Le fait d’utiliser l’ordonnan-ceur dans la boucle de vérification, avec une politique d’ordonnancement qui rend le traitement de l’évènement disengage plus prioritaire que resetCS, aurait également pu permettre d’éviter ce problème.
Une nouvelle itération du processus de vérification montre que toutes les propriétés sont maintenant vérifiées avec les PUSMs et avec le model-checking LTL. La version corrigée de ce modèle possède un espace d’état contenant 17 134 122 configurations et 29 088 210 tran-sitions. Une comparaison entre les performances du model-checking basé sur les PUSMs et le model-checking basé sur LTL a également été menée à la fois sur le temps et la mémoire prise par le model-checker pour effectuer la vérification. En moyenne pour ce modèle de l’IRV, la vérification avec les PUSMs est plus efficace que la vérification LTL de 6,7% en mémoire et de 7,4% en temps. Ces résultats s’expliquent notamment par le fait que la composition synchrone est implémentée en langage C plutôt qu’en Java.
Réponse à RQ#7 (Comparaison des résultats LTL vs PUSMs) Sur le modèle d’IRV considéré, les résultats de model-checking obtenus avec des PUSMs sont identiques à ceux obtenus par model-checking des propriétés LTL équivalentes.