Approche avec automates temporisés et model checking

Les automates temporisés ont été introduits par Alur et Dill [8, 7] pour décrire le comportement de systèmes en prenant en compte leur aspect temporel. La vérification de modèles, décrits dans ce formalisme, est possible grâce à l’association de techniques de vérification tels que le model checking [38, 22].

Automates temporisés

Un automate temporisé est un automate fini, étendu avec un ensemble d’horloges et des règles sup- plémentaires sur les transitions. Les horloges sont des variables positives réelles qui évoluent à la même vitesse dans le temps. Les transitions d’un tel automate peuvent être étiquetées par :

– une garde portant sur les valeurs des horloges, c’est-à-dire une condition sur les horloges indiquant si la transition peut être franchie,

– une action effectuée lors du tir de la transition,

– des remises à zéro d’horloges effectuées lors du tir de la transition.

Formellement, un automate temporisé _{A est un 6-uplet (L, l}0, X, Σ,_{!, Inv) avec :} 1. L un ensemble fini de localités,

2. l0 la localité initiale,

3. X un ensemble fini d’horloges, dont les valeurs sont dans_R+_, 4. Σ un ensemble fini d’actions,

5. _{! L C(X)} Σ 2X _{L un ensemble fini de transitions. Une transition e =}

hl, γ, σ, R, l0_{i 2!} correspond à une transition entre la localitél et la localité l0_{, gardée par la contrainte d’horlogeγ,} étiquetée par l’actionσ et qui remet les horloges de R X à zéro,

6. Inv: L! C(X) est une fonction qui associe des invariants aux localités. Les invariants d’une localité sont des contraintes sur les horloges de la forme Inv(l) =V x p où x est une horloge et p2 N. La sémantique d’un automate est donnée par un système de transitions dans lequel un état consiste en la localité courante et une valuation des horloges. Nous ne détaillons pas cette sémantique mais il y a deux types de transition entre états :

– l’automate peut laisser passer le temps dans une localité tant que son invariant est satisfait, – l’automate peut tirer une transition si la garde de la transition est satisfaite et que l’invariant de la

localité atteinte l’est également.

Cette sémantique implique que les transitions de l’automate sont instantanées et le temps ne peut s’écouler que dans les localités.

Exemple 1 (Un automate temporisé). Nous illustrons la notion d’automate temporisé avec un exemple tiré de [21] et représenté sur la figure 2.5.

end y <= 20 loop y <= 50 start y<=20 x==1 work x:=0 10 <=y y:=0 40 <= y leave y:=0 10 <= y enter x:=0, y:=0

Figure 2.5 – Exemple d’automate temporisé

Cet automate comporte trois localités ( start qui est la localité initiale, loop et end) et son compor- tement temporel est contrôlé par deux horloges x et y. Un invariant est défini pour chaque localité. Par exemple l’invariant y 20 est associé à la localité start, ce qui signifie que l’automate peut être dans cette localité uniquement si l’horloge y vaut moins que 20. Trois actions sont définies ( enter, work et leave) sur les transitions. Aucune action n’est associée à la transition entre end et start. L’horloge x est utilisée pour contrôler la boucle sur la localité loop. Cette transition ne peut être tirée que si x= 1 et cette horloge est remise à zéro quand cette transition est tirée. Ceci permet de limiter les répétitions de l’action work. L’horloge y contrôle l’exécution de l’automate complet. L’automate peut quitter la localité start à n’importe quel instant quand y est dans l’intervalle entre 10 et 20 (l’invariant de la localité start oblige l’automate à quitter cette localité au plus tard à 20). Il peut aller de loop vers end quand y_{2 [40, 50], et} finalement il peut aller de end vers start quand y _{2 [10, 20].}

Véri cation par model checking

Les automates temporisés permettent la définition formelle du comportement d’un système. Un tel modèle peut alors être exploité pour la vérification d’exigences, en particulier à l’aide d’outils de model checking [38, 22]. L’idée du model checking est de parcourir l’ensemble des états atteignables d’un modèle pour vérifier qu’une exigence est satisfaite. Avec les automates temporisés, ceci pose deux problèmes. En premier lieu, l’ensemble des états du système n’est pas fini car les horloges ne sont pas nécessai- rement bornées et car le temps est dense. Pour dépasser ce problème, des techniques basées sur des relations d’équivalence ont été mises au point dans [25]. L’idée est de définir des régions à l’intérieur des- quelles toute valuation des horloges conduit nécessairement à un même état du système. Ces équivalences permettent de définir une représentation finie des états d’un automate temporisé. La seconde difficulté concerne l’explosion combinatoire du model checking. Du fait du parcours exhaustif des états du modèle, la complexité de la méthode est exponentielle : bien que le nombre de régions d’un automate soit fini, ce nombre croît de manière exponentielle avec le nombre d’horloges du modèle.

L’expression d’une exigence peut se faire de deux manières. La première consiste à l’encoder dans le langage d’une logique. Le choix de cette logique se fait en rapport avec l’exigence à modéliser. Par exemple, la logique CTL (pour Computational Tree Logic) permet d’exprimer une propriété du type « l’événement a se produira toujours après l’événement b » tandis qu’en logique TCTL (pour Timed Computational Tree Logic) il est possible de quantifier temporellement une propriété, par exemple « l’événement a se produira toujours 5 unités de temps après l’événement b ». Pour vérifier les propriétés exprimées à l’aide de ces logiques, il existe différents outils parmi lesquels KRONOS [111], Uppaal [67, 20]. . . Le rapport [23] propose une comparaison des outils courants de model checking. Une deuxième approche consiste à exprimer l’exigence à l’aide d’un automate de test. Comme présenté dans [33, 1, 22], un automate de test implémente un état dit unhappy qui est atteint si l’exigence n’est pas satisfaite. Ainsi, la vérification devient un problème d’atteignabilité : si l’état unhappy est atteignable alors l’exigence n’est pas satisfaite. Par rapport à l’expression d’exigences avec une logique dédiée, cette approche offre de meilleures performances, mais au prix d’une expressivité plus limitée.

Modélisation de l'étude de cas

Nous avons proposé une modélisation d’un système IMA à l’aide d’automates temporisés dans l’ar- ticle [72]. Mais la modélisation détaillée du réseau limite la vérification d’exigence à des systèmes de taille réduite. Une solution pour dépasser cette limitation est de considérer le réseau comme un ensemble de canaux temporisés [34, 35]. Chaque canal représente alors un lien entre un unique émetteur et un unique récepteur, et ce lien impose un délai à chaque message échangé entre l’émetteur et le récepteur. Pour chaque message, le délai est choisi de façon non-déterministe dans un intervalle, borné par les meilleur et pire temps de traversée du réseau. Ces bornes sont calculables à l’aide de techniques telles que le Network Calculus ou l’approche par trajectoire que nous décrivons ultérieurement (c.f. section 2.3 page 34).

Dans la suite, nous suivons l’idée de cet article pour modéliser une partie de l’étude de cas et ainsi évaluer l’efficacité de cette approche. Nous utilisons les extensions des automates temporisés qui sont définies dans le model checker Uppaal. En particulier, il est possible de définir des variables (de type entier par exemple). La mise à jour d’une variable s’effectue lors du tir d’une transition : une règle d’affectation de valeurs (u = v + 1 par exemple) ou une fonction encodée dans le langage C est alors associée à une transition.

Un des intérêts des automates temporisés est qu’un système peut être modélisé comme un réseau d’automates, c’est-à-dire la composition d’un ensemble d’automates élémentaires. La composition d’au- tomates est définie par le produit synchronisé. La synchronisation de deux automates s’effectue à l’aide d’une action commune a. Cette action est suffixée par ! dans un des automates et par ? dans l’autre : l’action a! exécutée par un premier automate correspond à une action a? exécutée en parallèle dans un second automate. Autrement dit, une transition qui exécute l’actiona! ne peut être tirée que si la transi- tion exécutanta? peut l’être également. Dans la syntaxe dUppaal, une telle action est appelée un canal (channel ).

Le système est donc modélisé comme un réseau d’automates temporisés étendus. La figure 2.6 présente ce réseau.

Nous utilisons un automate pour :

– le moduleM1(sur lequel s’exécutent les fonctions KCCU et MFD ), – le moduleM2(avec la fonction FM ),

keyboard display M1 C1 C2 M2 obs wpId_C1 wpInfo_FM req_obs wpInfo_C2 req_key disp_MFD disp_display wpId_KU mardi 25 octobre 11

Figure 2.6 – Réseau d’automates temporisés du système FMS

– l’écran (display ),

– le canal temporisé reliant KCCU à FM (notéC1), – le canal temporisé reliant FM à MFD (notéC2), – l’observateur encodant l’exigence à vérifier

Les flèches entre les automates représentent les variables utilisées. Une flèche en trait plein précise qu’il existe en plus un canal de synchronisation entre deux automates.

Le rôle de l’observateur est d’initier une requête et de mesurer le temps écoulé jusqu’à l’affichage sur l’écran d’une page dépendant de cette requête. L’observateur contrôle que cette latence ne dépasse pas un certain seuil. L’automate correspondant est représenté sur la figure 2.7. L’observateur ne peut atteindre l’état unhappy que si il s’est écoulé un temps supérieur à maxLatency depuis son démarrage et qu’aucun affichage dépendant de sa requête n’a été produit (ce qui est testé par disp_display == 0).

unhappy waitDisplay

start

h > maxLatency && disp_display == 0

h = 0, req_obs = 1

Figure 2.7 – Automate temporisé de l’observateur

Pour identifier qu’un affichage dépend bien de la requête initiée par l’observateur, nous utilisons des variables globales. Une variable indique si la requête de l’observateur a déjà été traitée par un élément du système. Initialement, toutes ces variables valent 0. Par exemple, la variable req_obs modélise l’envoi d’une requête par l’observateur : elle passe à 1 lorsque l’observateur démarre. Cette variable est utilisée dans l’automate modélisant le clavier, représenté sur la figure 2.8.

sampling h <= T waitStart h <= T h == T h = 0, Key() void Key ( ) { i f ( req_obs == 1 ) { req_key = 1 ; } }

Figure 2.8 – Automate temporisé du clavier

Après son démarrage, l’automate du clavier boucle sur la localité sampling, dont la transition est tirée périodiquement (avec une période T). Le franchissement de cette transition modélise l’échantillonnage de l’entrée du clavier. A chaque transition, la fonction Key() est appelée. Elle permet de propager la valeur de req_obs vers req_key. Si req_key vaut 1, cela signifie qu’une requête dépendant de la requête de l’observateur est disponible en sortie du clavier. Cette valeur est exploitée dans l’automate décrit sur la figure 2.9 qui modélise le moduleM1 sur lequel s’exécute les fonctions KCCU et MFD.

En accord avec le standard ARINC 653, les partitions d’un module sont ordonnancées au sein d’une trame temporelle périodique appelée la MAF (pour MAjor time Frame). L’automate modélise cet or- donnancement et on y retrouve les paramètres utilisés dans le modèle AADL, présenté précédemment. La durée de la MAF est modélisée par la contrainte h <= HP, HP correspond donc au paramètre AADL ARINC653::Module_Major_Frame et est égale à 50 ms. Les paramètres oKU et oMFD correspondent aux décalages (o pour o set ) des démarrages des partitions KCCU et MFD par rapport au démarrage de la

startM1 h < HP waitNextMAF h<= HP execMFD h <= oMFD + cMFD endKU h<= oMFD execKU h <= oKU + cKU startKU h <= oKU h:=0 h== HP h:=0 MFD() h == oMFD emitWpId! KCCU() h == oKU void KCCU( ) { i f ( req_key == 1 ) { wpId_KCCU = 1 ; } } void MFD( ) { i f ( wpInfo_C2 == 1 ) { wpInfo_MFD = 1 ; } }

Figure 2.9 – Automate temporisé modélisant la MAF du module M1

MAF. Les slots de temps de la MAF sont définis par ARINC653::Partition_Slots => (25ms, 25ms) et KCCU est alloué au premier slot et MFD au second. On a alors oKU = 0 et oMFD = 25. Les paramètres cKU et cMFD sont les durées des partitions et donc des slots, ils valent donc 25 ms. La mise à jour de la sortie de KCCU (et donc la propagation de req_key vers wpId_KCCU) est modélisée par la fonction KCCU(). Cet automate est synchronisé avec l’automate du canal temporisé entre M1 et M2(C1) avec le canal emitWpId. Cette synchronisation permet de modéliser le délai subi par un message émis par KCCU dans le canal (l’horloge chronométrant ce délai est remise à zéro lors de la synchronisation). La figure 2.10 représente l’automate du canal temporiséC1.

delay h <= b start h >= a TC_wpId() emitWpId? h = 0 void TC_wpId ( ) { i f (wpId_KCCU == 1 ) { wpId_C1 = 1 ; } }

Figure 2.10 – Automate temporisé modélisant un canal temporisé

Les paramètres de cet automate sont les temps minimala et maximal b de traversée du canal. Ils sont définis dans le virtual bus VL.1 du modèle AADL avec la propriété Latency => 120 us .. 2 ms.

Les autres éléments de l’exemple sont modélisés de façon similaire. Nous utilisons ce modèle pour évaluer les capacités du model checker. Une particularité du système étudié est le rapport de temps entre les paramètres des fonctions qui sont définies en milli-secondes et les paramètres du réseau qui sont en micro-secondes. Par exemple, la période de KCCU vaut 50 ms et la valeur maximale de la latence acceptable est 700 ms. Mais le temps d’émission d’une trame réseau de taille maximale est 120µs. Ceci pose un problème au model checker. En effet, cette disparité des horloges (certaines peuvent être remises à jour beaucoup plus fréquemment que d’autres), fait que le graphe des régions utilisé pour construire une représentation finie des états d’un modèle « explose ».

Pour vérifier que la latence de cet exemple ne dépasse pas la borne maxLatency, nous demandons au model checker de vérifier que le modèle n’atteint jamais l’état unhappy de l’observateur. L’outil Uppaal produit une réponse positive : l’état n’est jamais atteint et donc la propriété est satisfaite. Cette vérification requiert un peu plus de 42 minutes1_{, ce qui correspond à l’exploration de 2263053} états.

Conclusion

A la suite de ces expérimentations, nous avons noté plusieurs freins à l’utilisation de ces méthodes. En premier lieu, la modélisation d’un système IMA, asynchrone par nature, nécessite l’utilisation de nombreuses horloges. Or, la complexité de la résolution du problème augmente de façon exponentielle avec le nombre d’horloges. En outre, le système fonctionne avec plusieurs échelles de temps (période d’une fonction enms, temps d’émission d’une trame en µs) ce qui limite l’efficacité des techniques de réduction de l’espace d’états du système.

Pour ne pas compliquer la présentation de l’exemple, nous n’avons pas modélisé les lisseurs de trafic ni les files d’attente du réseau. Nous proposons une modélisation détaillée de ces éléments dans [72]. Inclure ces éléments dans le modèle augmente significativement la complexité. L’analyse d’un réseau modélisé avec des automates temporisés est limitée à des réseaux ne comportant qu’une vingtaine de flux pour le moment [4, 2, 3], mais des travaux sont en cours afin d’améliorer la méthode pour en considérer une cinquantaine.

Bien que ces techniques ne soient utilisables que sur des exemples restreints, elles ne manquent pas d’intérêt : certaines améliorations proposées sur l’approche par trajectoire [16] ont été permises grâce aux observations faites sur les modèles à automates temporisés, car ces modèles permettent d’exhiber le comportement pire cas du système. En revanche, pour le moment, il n’est pas envisageable d’utiliser ces techniques sur des systèmes IMA de tailles industrielles.