Analyse model checking

Nous devons d’abord exprimer les propriétés à vérifier dans la syntaxe de la logique temporelle linéaire par des formules LTL. Nous spécifions ensuite ces formules dans le module  MODEL-CHECK-AADL-PROP (figure 6.11) qui importe le module prédéfini TIMED-MODEL-CHECKER et le module AADL-SPEC pour être analysé. Dans ce module, la spécification des formules LTL, exprimant les propriétés à vérifier définies dans la section 6.3.3, se fait par la déclaration des propositions de sort Prop. Cette spécification est faite, en considérant les spécifications RT-Maude des configurations architecturales du module AADL-SPEC, par les propositions atomiques suivantes: CompleteStateTGPS (P1), CompleteStateTSCREEN (P1) et RunningState (P3).

Figure 6.11- Spécifications RT-Maude des formules LTL

La vérification de la propriété (P1) par le LTL model-checker de RT-Maude est lancée par cette commande :

(mc initState1 |=t (<> CompleteStateTGPS)/\ (<> CompleteStateTSCREEN) in time <= 70 .)  

L’exécution de cette commande a donné le résultat de la figure 6.12 précisant que la propriété est non vérifiée. Un contre-exemple est alors retourné donnant une trace d'exécution, indiquant que le thread exhibe un comportement Zénon, signifiant qu’un nombre infini de transitions discrètes se produit dans un intervalle de temps fini.

En effet, la propriété (P1) n'est pas satisfaite parce que le thread est indéfiniment préempté (il y a une infinité de transitions d'état à travers le cycle : resume, preempt et block-on Release-Resource) pendant une période de temps limitée sans pouvoir finir son exécution. Par conséquence, le sous état (Substate = Complete) du thread ne peut jamais être atteint.

(tomod MODEL‐CHECK‐AADL‐PROP is  including TIMED‐MODEL‐CHECKER .   protecting AADL‐SPEC .  var REST : Configuration .   vars Imp : Oid .   vars R R' R'' : Time .   ops RunningState  CompleteStateTGPS         CompleteStateTSCREEN : ‐> Prop [ctor].  eq {REST  < TGPS :  ThreadImpl | Substate : Complete   >}           |=   CompleteStateTGPS = true .   eq {REST  < TSCREEN : ThreadImpl | Substate :  Complete >}       |=  CompleteStateTSCREEN = true .   eq {REST < Imp : ThreadImpl| TState : compute, Substate :        Running   >} |= RunningState = true.   endtom)

Figure 6.12 Vérification formelle des propriétés d’exécution AADL: “Comportement Zénon”

Cette première tentative de vérification de la propriété (P1) montre bien le comportement Zénon de l’automate du standard. Pour surmonter ce comportement incorrect, nous avons essayé d’adopter, dans un premier temps, une stratégie naïve. Celle-ci consiste à associer un intervalle de temps limité aux transitions resume, preempt et block-on-Release-Resource, en limitant le nombre de transitions durant l'exécution du thread (pas plus de deux).

Le résultat obtenu reste incorrect où d’autres comportements inattendus apparaissent. Cela est dû au fait que l’exécution des règles de réécriture du module temporisé AADL-SPEC se fait de façon aléatoire, il fallait donc guider le système de réécriture. La deuxième stratégie adoptée est donc d'ajouter des priorités à l'exécution de certaines règles.

Figure 6.13 : Vérification formelle des propriétés d’exécution AADL

L’image d’écran de la figure 6.13 montre qu’après avoir adopté la deuxième stratégie, le problème du comportement Zénon est résolu et la propriété (P1) est évaluée à vrai. La vérification de cette propriété (Substate = complete est accessible dans le temps) pour les threads TGPS et TSCREEN implique que ces threads finissent par s’exécuter correctement et de façon concurrente. Nous pouvons considérer également que les propriétés d’exécution temporelles (Period et Compute-Execution-Time) sont vérifiées. Etant donné que le problème du comportement Zénon est résolu donc l’exécution d’un thread n’est pas préemptée indéfiniment et/ou en attente d'une ressource indéfiniment. Par conséquent la propriété (P2) est également vérifiée.

Pour vérifier la propriété de vivacité (P3) et justifier que le thread a fini par s’exécuter, nous appliquons la commande de recherche temporisée (tsearch) pour savoir si le sous état (Substate = running) est accessible à partir de l’état initial initState (instancié dans la figure 6.6) dans une durée de temps donnée.

< TGPS : ThreadImpl | Substate : running > } in time <= 50 .)

Figure 6.14 -Trace d’une recherche temporisée (tsearch)

Le résultat obtenu implique que l’exécution de chaque thread, dans la configuration de l’état initial, passe par le sous état (Substate = running). La recherche de cet état est matché à n'importe quel état qui contient ( Substate =

running). La trace de la recherche temporisée (figure 6.14) montre que l'ensemble des états accessibles de l'état initial est fini.

6.4 Conclusion

L’annexe comportementale ABAReL offre une solution générique à base de théories orientées objet temps réel. Le prototypage de son modèle mathématique sous RT-Maude, propose un outil pour ABAReL permettant de spécifier formellement une architecture logicielle d’un système embarqué respectant la syntaxe du langage AADL, analyser son comportement et vérifier ses propriétés.

Etant donné que tous les outils d’analyse et de vérification supportant le langage AADL n’ont pas été conçus pour la spécification formelle et la vérification des propriétés sans passer par plusieurs transformations, nous avons présenté, dans une première partie de ce chapitre, une autre alternative qui consiste à implémenter le modèle sémantique ABAReL, proposé dans les chapitres précédents sous le système RT-Maude. Cette implémentation d’ABAReL permet d’autre part la vérification formelle des propriétés comportementales d’une architecture AADL composée d’un ensemble de composants de types threads en tirant profit des outils d’analyse et de vérification du système RT-Maude.

Nous avons illustré l’utilisation de l’outil issu d’ABAReL par une étude de cas reposant sur le modèle architectural AADL d’un système de contrôle de navigation. Nous avons exploité les procédures d’analyse et de simulation du comportement de RT-Maude pour montrer les différentes étapes de simulation du comportement de plusieurs exemples de configuration. Nous nous sommes particulièrement concentrées sur l’utilisation du model-checker LTL de RT-Maude pour la vérification des propriétés comportementales. Les premières tentatives de vérification ont échoué à cause du problème de comportement Zénon de l’automate du standard. Nous avons pu résoudre ce problème par une stratégie qui guide le système de réécriture de notre outil. Ainsi les propriétés comportementales exprimées dans la syntaxe de la logique temporelle linéaire LTL ont été vérifiées.