des simplifications influe énormément sur la taille de l’espace d’états. Il faut cepen- dant que ces abstractions soit faites tout en garantissant la justesse de la vérification des propriétés (les modèles complets et simplifiés doivent avoir un comportement équivalent au regard de la vérification). Pour cela, et pour être efficace, il est indis- pensable d’être expert dans la sémantique du langage de modélisation comme dans la technique de vérification sous-jacente.
2.5.3.3 En limitant l’espace d’états exploré
Vérification on-the-fly : La technique de vérification à la volée (on-the-fly)
permet d’analyser le système sans construire tout l’espace d’états ce qui permet de réduire le nombre d’états explorés, et par conséquent réduire le temps de vérification et la mémoire utilisée. Cette réduction n’est cependant effective que pour certaines propriétés, qui ne nécessite pas, par définition, de parcourir l’ensemble du graphe (typiquement l’accessibilité). Cependant, la vérification à la volée est également utile pour les autres propriétés (les invariants par exemple), lorsque la propriété est violée : le premier état qui ne satisfait pas la propriété arrête le processus de vérification, ce qui raccourcit le processus de détection d’erreur lorsqu’il y en a une.
Il y a principalement deux familles d’algorithmes qui permettent d’analyser des systèmes temporisés à la volée. La première, appelée analyse en arrière, consiste à calculer itérativement les prédécesseurs des états que l’on cherche à atteindre et à tester si un état initial se trouve dans l’ensemble calculé. La seconde, appelée analyse en avant, consiste à calculer itérativement les successeurs des états initiaux et à tester si l’état que l’on cherche à atteindre a déjà été calculé.
Vérification en largeur ou profondeur d’abord : Même dans le cas où la
méthode de vérification ne nécessite de parcourir qu’une partie de l’espace d’état, le choix de la stratégie de parcours (et de construction) du graphe d’états du sys- tème décrit à la sous-sous-section 2.5.1.2 peut également avoir une influence sur les performances globales de la vérification.
Nous allons maintenant voir quelques outils de MC.
2.6 Outils de model-checking
Dans cette section, nous donnons un aperçu sur quelques outils de model-checking. Ensuite, nous présentons l’outil UppAal choisi pour le travail de recherche présenté dans ce mémoire.
2.6.1 Aperçu des outils de model-checking
Il existe de nombreux outils de model-checking. Une liste étendue des logiciels de vérification est disponible via l’url présentée en pieds de page2. Le lecteur in-
téressé par des descriptions plus détaillées des outils peut se reporter aux articles [21, 60, 94]. D’un point de vue pratique, nous pouvons classer les outils de vérifica- tion en 4 catégories d’usage : ceux dédiés à l’analyse de code (BLAST, CPAchecker), ceux voués au MC ordinaire (SPIN, TAPAs, TLA+, NuSMV), ceux permettant le MC probabiliste (CADP, MRMC, PAT, PRISM), et enfin les outils pour le MC temporisé (DREAM3, LTSmin4, mCRL25, TAPAAL6, UppAal7, ROMEO8, HY-
TEC9, TINA10, Kronos11). Nous nous intéressons à ces derniers puisque certains
des problèmes d’agriculture de précision auxquels nous nous intéressons sont des problèmes temporisés.
TAPAAL, TINA et ROMEO sont utilisés pour la validation et la vérification des systèmes temps réel modélisés en réseaux de Petri temporel (RPT). Hytech permet d’analyser des systèmes décrits comme des Automates Hybrides Linéaires (AHL) [31]. LTSmin et mCRL2 sont utilisés pour la vérification des systèmes modé- lisés en algèbre de processus. Les algèbres de processus sont une famille de langages formels permettant de modéliser les systèmes (informatiques) concurrents ou distri- bués. Kronos a été beaucoup utilisé par la communauté scientifique avant l’année 2009 mais depuis sa maintenance n’est plus assurée par son équipe de développe- ment. Un avantage spécifique de Kronos est qu’il peut fournir (option de vérification) toutes les traces qui vérifient une propriété donnée. L’outil DREAM a été très peu utilisé et il n’a pas une interface graphique utilisateur conviviale.
UppAal est, aujourd’hui, l’outil d’analyse de systèmes temporisés le plus abouti : il est régulièrement mis à jour et une interface graphique conviviale assure une prise en main aisée du logiciel. Il est également énormément utilisé par la communauté scientifiques [57, 67, 110, 93]. Les modèles manipulés par l’outil sont exprimés dans une variante équivalente du formalisme des automates temporisés, qui sont étendus avec des variables entières [12].
Nous avons estimé que UppAal était bien adapté au travail de recherche présenté dans ce mémoire, et en particulier qu’il permettrait de démontrer l’intérêt de faire appel aux techniques de model-checking pour vérifier des systèmes avec une com-
2. https ://cps-vo.org/group/verification_tools/wiki 3. http ://dre.sourceforge.net/ 4. http ://ltsmin.utwente.nl/ 5. https ://www.mcrl2.org/web/user_manual/index.html 6. http ://www.tapaal.net/ 7. http ://www.UppAal.org/ 8. http ://romeo.rts-software.org/ 9. https ://ptolemy.berkeley.edu/projects/embedded/research/hytech/ 10. http ://www.laas.fr/tina/ 11. http ://www-verimag.imag.fr/DIST-TOOLS/TEMPO/kronos/
2.6. OUTILS DE MODEL-CHECKING 55
posante spatiale, dans le cadre de l’agriculture de précision. En effet, l’utilisation de variables entières facilite en pratique la modélisation. La représentation en ré- seaux d’automates temporisés synchronisés par évènements permet une modularité de modélisation qui est adaptée à la représentation conjuguée des systèmes biolo- giques et techniques impliqués par l’agriculture de précision. Par exemple, le modèle développé au chapitre 5 représente d’une part l’état des rangs de végétation, avec un automate par rang, et d’autre part le comportement de la machine de récolte.
Par ailleurs, l’outil UppAal, mature au plan technique, est encore largement utilisé par la communauté scientifique, avec un soutien aux utilisateurs. C’est un atout pratique important pour cette recherche.
Table 2.2 – Classification des outils de vérification
Outil de MC Classe du MC Lang. de modélisation Lang. de propriété GUI
BLAST analyse du code C Monitor automata Non
CPAchecker analyse du code C Monitor automata Oui
CADP probabiliste - - Oui
MRMC probabiliste - - Non
PAT probabiliste - - Oui
PRISM probabiliste - - Oui
SPIN ordinaire - - Oui
TAPAs ordinaire - - Oui
TLA+ ordinaire - - Oui
NuSMV ordinaire - - Non
DREAM temps réel AT Monitor automata Non
LTSmin temps réel Algèbre de processus µ − calculus, LTL, CTL Non
HYTEC temps réel AHL - -
Kronos temps réel AT TCTL -
TAPAAL temps réel RPT TCTL Oui
TINA temps réel RPT - Oui
ROMEO temps réel RPT TCTL Oui
mCRL2 temps réel Algèbre de processus µ − calculus Oui
UppAal temps réel AT TCTL Oui
De plus, une comparaison d’outils de vérification a été faite pour une appli- cation sur les systèmes de contrôle des trains dans [94]. Cette étude compare les performances de dix environnements de vérification formels différents (UMC, SPIN, NuSMV/nuXmv, mCRL2, CPN Tools, FDR4, CADP, TLA+, UppAal et ProB) en répondant à une propriété de sûreté. Cette étude démontre l’efficacité et la supério- rité d’UppAal ce qui nous a conforté dans notre choix. Il faut assumer que LTSmin et
DREAM permettent de vérifier des modèles conçus avec l’outil UppAal. Idéalement, il aurait été intéressant de comparer les performances entre les trois outils UppAal, LTSmin et DREAM, pour les cas étudiés dans ce mémoire, ce que faute de temps, nous n’avons pu faire, nous avons cependant choisi UppAal sans cette comparaison. D’autant plus que les automates temporisés et UppAal ont déjà été utilisés dans les domaines de l’agriculture et de la gestion des écosystèmes (par exemple, dans [70], [86], [57]), ce qui nous conforte encore dans ce choix.
Maintenant, nous allons présenter en détails l’outil UppAal.
2.6.2 UppAal
L’outil UppAal a été développé en 1995, conjointement par l’université d’Uppsala (Upp) en Suède et l’université d’Aalborg (Aal) au Danemark, d’où son nom [88]. C’est un environnement intégré d’outils pour la modélisation, la validation et la vérification de systèmes en temps réel modélisés comme des réseaux d’automates temporisés. Les automates temporisés d’UppAal sont une variante des automates temporisés d’Alur et Dill, étendus avec des variables entières, des types de données structurés, des fonctions définies par l’utilisateur et la synchronisation des canaux. Notons qu’il y a deux types de canaux dans UppAal :
• Les canaux binaires : un émetteur envoie le signal m ! et un unique récepteur se synchronise avec lui par le signal complémentaire m ?. Les transitions de ces deux automates étiquetées par m ! et m ? sont tirées en même temps. Si, à partir d’une configuration, plusieurs couples de transitions peuvent être syn- chronisées, un choix est fait de façon non déterministe. La synchronisation par canaux binaires peut conduire à des blocages si un automate envoie un signal m ! mais qu’aucun autre automate ne peut le recevoir (par exemple si la garde de la transition étiquetée par m ? est fausse).
• Les canaux multiples (broadcast) : les transitions étiquetées par m ? et m ! sont synchronisées, mais cette fois avec un émetteur et un nombre quelconque de récepteurs, qui peut être égal à zéro. Ainsi, une synchronisation par canaux multiples ne conduit jamais à un blocage du modèle.
Les états des automates temporisés d’UppAal peuvent être étiquetés de 2 façons : • L’étiquette U pour Urgent : un tel état est équivalent au fait de remettre à zéro une horloge x avant d’arriver dans cet état et d’ajouter la garde x ≤ 0 sur les transitions d’action sortant de cet état. L’automate doit donc le quitter en un temps nul. Les délais dans les états urgents sont toujours égaux à zéro. Dans la figure 2.12 l’automate P est équivalent à l’automate
Q. Cette portion de modèle correspond par exemple au fonctionnement d’un
système de communication qui reçoit des paquets sur le canal a et les envoie immédiatement sur le canal b.
2.6. OUTILS DE MODEL-CHECKING 57
Figure 2.12 – Exemple pour l’étiquette urgent
• L’étiquette C pour Committed : cette notion est plus restrictive que la notion d’état urgent. L’automate doit quitter un état marqué par C immédiatement après son arrivée en empruntant une des transitions sortantes (s’il y en a plu- sieurs). Cette étiquette permet de diminuer les cas d’entrelacement à examiner par le model checkeur. En effet, un réseau d’automates peut présenter plusieurs transitions tirables à un même moment, même pendant un intervalle de temps de durée nulle. Lorsque l’état courant dans un des automates du réseau est
Committed, une de ses transitions sera tirée avant toute autre transition dans
un autre automate, y compris celle sortant d’un état marqué Urgent. Cela permet de représenter un niveau de priorité dans le tir des transitions.
Les propriétés supportées par UppAal sont principalement des propriétés d’at- teignabilité, de vivacité ou d’états bloquants [12]. Le connecteur temporel G est représenté par [] et le connecteur temporel F est représenté par <>. La logique utilisée par UppAal est uniquement un fragment de TCTL qui ne permet pas de vérifier l’ensemble des formules TCTL. Les connecteurs ne pouvant pas être tous imbriqués, seules les propriétés suivantes sont vérifiées par UppAal : A[]p, A<>p, E<>p, E[]p, p –> q et A[] not deadlock [12]. Il faut noter que si UppAal accepte TCTL alors il est possible de vérifier des formules CTL.
UppAal implémente la technique de vérification à la volée (on-the-fly).
Il propose un ensemble d’options pour contrôler le comportement du MC au mo- ment de l’exploration de l’espace d’état (largeur ou profondeur d’abord, génération de traces,..). Ces options influent sur l’ordre dans lequel l’espace d’états est exploré, le nombre d’états explorés, la quantité de mémoire allouée au processus de vérifica- tion et le temps de vérification. A la différence de l’outil Kronos, UppAal ne fournit
qu’une seule trace, il ne possède pas une option qui permet de donner toutes les traces. D’autre part, il ne fournit pas malheureusement le graphe d’états généré au moment de la vérification.
Le site internet d’UppAal12 et notamment l’onglet Web Help permet d’accéder
à un manuel d’utilisation qui contient toutes les informations nécessaires avec des explication détaillées, ce qui facilite la découverte et la maîtrise de l’outil.
Dans plusieurs des cas étudiés dans ce mémoire, nous souhaitions pouvoir accéder à la trace d’un chemin d’exécution optimal selon un critère de coût. Avec UppAal, il serait possible de modéliser explicitement le coût par une variable entière et ensuite de chercher par dichotomie la valeur optimale du coût. Ce serait cependant une méthode peu efficace. La recherche par dichotomie oblige à relancer plusieurs fois la vérification. D’autre part, il n’existe aucune méthode dans UppAal qui permette de spécifier une variable comme monotone. La définition d’un coût comme une variable ordinaire conduit donc a priori à augmenter l’espace d’états. Il existe heureusement une variante d’UppAal qui répond à notre attente et que nous détaillons dans la section suivante.