Outils de Model Checking

Nous nous concentrons dans cette section sur les outils ayant un pouvoir d’ana-lyse qui permet de vérifier à la fois des propriétés temporelles et probabilistes (par exemple, “Avec une probabilité d’au moins 99%, la latence maximale d’un paquet est toujours en dessous de 5 secondes”) sur des PTA. Nous avons référencé trois outils qui possèdent ces caractéristiques : Fortuna [Berendsen et al., 2010], PRISM [Kwiatkowska et al., 2011] et UPPAAL [Gerd Behrmann and Larsen, 2004].

7.3.1 Fortuna

Fortuna est un model checker pour les PPTA (Priced PTA), qui sont des PTA étendus avec des coûts sur les transitions (le passage d’une transition a un coût) et des coûts par unité de temps dans les états du PTA. Les auteurs de [Berendsen et al., 2009] montrent que le Model Checking sur les PPTA n’est pas décidable dans le cas général. Cependant, il existe un semi-algorithme (algorithme dont la terminaison n’est pas garantie pour toutes les entrées) qui permet de calculer la probabilité maximale d’accéder à une configuration sous contrainte de coût et de temps. On peut noter que même si l’objectif de ce document est de valider des pro-tocoles temps-réel avant tout, l’ajout de coût permet de modéliser la consommation énergétique qui est un paramètre essentiel dans les RCsF. On peut alors imaginer vérifier des propriétés du type : “Avec une probabilité de 99% un paquet arrive au puits en moins de 5 secondes et en dépensant moins de 10 unités d’énergie”.

Fortuna est entièrement écrit en C++. Les modèles PPTA doivent aussi être encodés en C++. Malgré une étude [Berendsen et al., 2010] qui montre que les per-formances de Fortuna sont meilleures que celles de PRISM (pour les deux cas d’études évalués), Fortuna reste pour l’instant peu utilisé et pas documenté. Ce manque de maturité est un point bloquant, car le manque de retour d’expérience des utilisateurs ne nous permet pas de nous faire une idée sur la fiabilité de l’outil. De plus, l’absence,

†. Il s’agit ici d’un outil prenant en compte tous les aspects cités

à notre connaissance, de documentation rend toute tentative d’implémentation de modèle très délicate.

7.3.2 PRISM

PRISM est un model checker probabiliste qui permet de travailler avec des chaînes de Markov (temps discret et continu), des MDP et des PTA. PRISM propose deux algorithmes pour la vérification des PTA : le premier basé sur la discrétisa-tion des horloges [Kwiatkowska et al., 2006] et le second sur les jeux stochastiques [Kwiatkowska et al., 2009]. Les deux techniques souffrent cependant de limitations. Dans le premier cas, les principales restrictions sont l’impossibilité d’utiliser des comparaisons strictes dans les contraintes d’horloges et l’interdiction d’utiliser des comparaisons diagonales (comparaisons entre deux horloges). Ces restrictions ne sont pas en soit bloquantes pour la modélisation des RCsF, mais sont contraignantes lors de la modélisation. En revanche, même si les expérimentations menées dans [Norman et al., 2012] montrent que cette technique a de bonnes performances en pratique (temps d’exécution et occupation mémoire), les auteurs indiquent que les performances se dégradent fortement lorsque la contrainte maximale sur les horloges dans le modèle augmente. C’est un problème dans le cas des protocoles RCsF, car certains des comportements des protocoles sont à courte échéance (acquittement d’un paquet par exemple de l’ordre de la milliseconde) et d’autres à longue échéance (à cause du cycle d’endormissement, de l’ordre de la seconde). La différence d’échelle oblige à avoir de grandes valeurs de contraintes d’horloge pour modéliser les événe-ments longs car les contraintes sont des entiers naturels (les grandes valeurs sont donc des multiples de la plus petite valeur). Dans le cas de la méthode des jeux stochastiques [Kwiatkowska et al., 2009], ce problème n’apparaît pas. En revanche, il est dans ce cas interdit d’utiliser des variables globales. Cela pose problème pour modéliser les protocoles, car la modélisation des échanges de données induites par les communications entre nœuds se fait à l’aide de variables globales.

En plus de ces contraintes induites par les méthodes de vérifications, il existe des restrictions sur le langage de modélisation de PRISM. D’abord, PRISM n’implémente pas de tableaux de variables, c’est un problème pour modéliser la topologie du réseau par exemple. En effet, dans la littérature [Fehnker et al., 2007] [Wibling et al., 2004] [Tschirner et al., 2008] la topologie est représentée par une matrice de connectivité (aussi appelée matrice d’adjacence) : une matrice carrée où chaque ligne et chaque co-lonne correspondent à un nœud, une valeur cij de la matrice à 1 indique une connexion entre les nœuds i et j (la valeur à zéro indique qu’il n’y à pas de connexion). Dans PRISM, il faut décrire spécifiquement le voisinage de chaque nœud (il n’est pas pos-sible d’avoir une définition générale d’un nœud puis de l’instancier plusieurs fois), cela oblige à redéfinir chaque nœud puisqu’ils ont un voisinage propre (ou à écrire un outil qui permet de générer le modèle PRISM [Fruth, 2011] mais on verra dans la section 7.4 que cette méthode a aussi des limitations). Il n’est pas non plus possible de réaliser de synchronisation avec passage de valeur, ce qui est utile pour représenter les transmissions de paquets de données. Le traitement des données sur les transi-tions est limité à des opératransi-tions arithmétiques basiques. Pour les opératransi-tions plus

complexes (qui nécessitent des traitements conditionnels sur les données ou bien avec des boucles) il faut générer les résultats à l’avance et encoder les différents cas dans différentes transitions.

Toutes ces restrictions rendent la modélisation et vérification de protocoles temps-réel pour RCsF avec PRISM contraignante. En revanche, PRISM est largement utilisé (principalement pour la vérification de chaînes de Markov et MDP), il existe de nom-breux articles sur les algorithmes de vérifications ainsi que sur des cas d’étude. On peut aussi noter qu’une des caractéristiques qui fait la puissance de PRISM (mais qui limite aussi le passage à l’échelle) est sa capacité à quantifier automatiquement la probabilité du pire cas, et pas seulement de vérifier si une probabilité donnée en entrée est respectée.

7.3.3 UPPAAL

L’outil de Model Checking UPPAAL [Gerd Behrmann and Larsen, 2004] permet de vérifier des TA. Son extension, UPPAAL-PRO [Engdahl and Haugstad, 2008], per-met la spécification et vérification de PTA. UPPAAL offre la possibilité d’implémenter le modèle en langage graphique en plaçant directement les états et les transitions et en leur assignant des invariants, des gardes et des mises à jour (cf. Figure 7.2, dont le fonctionnement est détaillé plus loin dans ce paragraphe). UPPAAL permet de déclarer des variables et tableaux de variables qui sont notamment utiles pour im-plémenter une représentation de la topologie (matrice de connectivité) du réseau ou bien la file d’attente d’un nœud du réseau par exemple, les données peuvent être locales à un nœud ou bien globales. Il est possible d’écrire des mises à jour sur les données (exécutées lors du passage des transitions) sous forme de fonctions en un langage dérivé du C (il n’y a donc pas besoin d’encoder les différents comportements à l’aide de multiples transitions comme c’est le cas dans PRISM, cf. section 7.3.2). UPPAAL ajoute aussi la notion d’urgence [Gerd Behrmann and Larsen, 2004] aux états : un état urgent est un état dans lequel le temps ne peut pas s’écouler, une transition doit être prise immédiatement (si aucune transition n’est active le système est bloqué). Il est aussi possible de définir des états dits ”engagés“ (committed) qui en plus d’être urgents sont prioritaires, c’est-à-dire que si plusieurs transitions sont actives au même instant, une transition qui sort d’un état ”engagé“ doit être prise en premier. Les synchronisations entre TA sont réalisées sur des variables appelées canaux : sur une transition, un nœud peut émettre un signal de synchronisation sur une variable canal, un autre nœud dont une transition active possède cette variable canal prend la transition au même instant que le nœud émetteur. Par exemple, sur la Figure 7.2, le nœud émetteur (Figure 7.2(a)) attend entre 2 et 3 secondes (grâce à la garde x > 2 et l’invariant x < 3) dans l’état initial représenté par un double cercle et émet un signal de synchronisation sur le canal c (noté c!), il remet ensuite immédiatement (l’état est urgent, il est marqué avec la lettre ”u“) son horloge x à zéro en retournant dans son état initial. Le récepteur (Figure 7.2(b)) attend un signal sur le canal c (noté c?) sur réception du signal il incrémente la variable nb en retour-nant dans son état initial. Les deux TA passent la transition depuis l’état initial à l’état urgent au même instant (décidé par l’émetteur). UPPAAL permet de modéliser

deux types de synchronisations : les synchronisations un à un comme l’exemple de la Figure 7.2 et les synchronisations broadcast qui consistent à synchroniser plusieurs TA sur une transition. Les synchronisations un à un sont bloquantes, c’est-à-dire que l’émission d’un signal doit correspondre à la réception du signal par un autre TA sinon la transition ne peut pas être prise. Ce n’est pas le cas des synchronisations

broadcast pour lesquels la transition d’émission peut être prise même si aucun TA

ne prend la transition qui correspond à la réception du signal. Les synchronisations

broadcast sont très utiles pour modéliser les transmissions broadcast dans les réseaux

sans fil comme nous le verrons dans le chapitre suivant.

(a) Emetteur (b) Récepteur

Figure 7.2 – Exemple de NTA UPPAAL : émetteur-récepteur

[Engdahl and Haugstad, 2007] et [Engdahl and Haugstad, 2008] présentent un al-gorithme de vérification des PTA pour UPPAAL. Il est basé sur l’alal-gorithme de [Kwiatkowska et al., 2002a] mais avec une représentation encore plus concise des états qui permet un meilleur passage à l’échelle. A notre connaissance cet algorithme n’im-pose pas de restrictions sur la modélisation du système. En revanche, il est seulement possible de vérifier des probabilités maximales d’accessibilité (probabilité maximale d’arriver dans un état). On peut noter que dans de nombreux cas on peut expri-mer une propriété par rapport à la probabilité maximale ou minimale indifféremment [Berendsen et al., 2010] : la probabilité maximale d’arriver dans un “mauvais” état et probabilité minimale d’être toujours dans un “bon” état sont complémentaires.

Le langage utilisé par UPPAAL est le plus adapté pour modéliser les protocoles temps-réel pour RCsF. De plus UPPAAL est capable de réaliser le Model Checking sur les PTA. Nous nous sommes donc tournés vers cet outil pour modéliser et vé-rifier RTXP. Cependant, l’arrêt de la distribution d’UPPAAL-PRO ainsi que l’ab-sence de documentation de la partie probabiliste sont des points très négatifs sur son utilisation. La partie de vérification temporelle reste quant à elle bien documentée, régulièrement maintenue et dispose d’une large communauté d’utilisateur.

7.3.4 Conclusion sur les outils

Au niveau des outils, UPPAAL semble le plus à même de nous permettre de modéliser correctement les RCsF. Cependant il existe un vrai manque au niveau de la vérification des propriétés probabilistes (absence de documentation). PRISM en revanche a des lacunes à cause des restrictions dues aux techniques de vérification et

au langage de modélisation. Nous concluons qu’aucun des outils n’est complètement satisfaisant pour la vérification des PTA. En revanche, UPPAAL permet de vérifier des propriétés temporelles sur des TA donc des modèles de RCsF sans la prise en compte du lien radio non-fiable. Dans le chapitre suivant, pour palier à ce manque, nous proposons une technique qui permet de modéliser le lien radio non-fiable et qui est indépendante de l’outil de vérification utilisé.