Vérification formelle de protocoles

Comme mentionné précédemment, les systèmes critiques temps-réel dur doivent fonctionner correctement et respecter des contraintes temporelles. Pour être sûr du respect de ces propriétés, elles devront être vérifiées de manière formelle [Clarke and Wing, 1996]. La vérification formelle d’un système consiste à modé-liser le système et ses interactions puis à prouver un ensemble de propriétés sur le modèle. Le modèle d’un système est une représentation mathématique du compor-tement dudit système. Une propriété est un énoncé qui exprime une spécification voulue pour le système, par exemple dans le cadre d’une application de détection d’événement (comme l’application de détection de feux de forêt précédemment citée) on veut vérifier que “Le délai de bout en bout d’une alarme incendie ne dépasse pas

10s”. Cette propriété est traduite en langage mathématique (on peut citer les logiques

temporelles CTL et LTL [Baier and Katoen, 2008]) pour être vérifiée. 7

Pour obtenir la vérification formelle d’un système, la preuve de théorème et le

Model Checking sont les deux approches les plus répandues [Clarke and Wing, 1996].

Pour vérifier des propriétés dans les réseaux, il existe également une autre approche : le Network calculus qui est un framework théorique pour évaluer les bornes supé-rieures des délais dans les réseaux. Dans le cas de la preuve, on modélise le système à l’aide d’une algèbre et on se sert des axiomes de cette algèbre pour établir des preuves de propriétés du système. Cela permet de prouver des propriétés très géné-rales, et de travailler sur des systèmes infinis (variables qui prennent des valeurs dans R). Cependant, ce type d’approche oblige souvent à faire des abstractions qui vont éloigner les résultats obtenus de la réalité : on obtient alors des bornes temporelles sur le délai de bout en bout très lâches, c’est-à-dire très éloignées du pire cas réel (mais qui le majorent tout de même). La seconde approche, le Model Checking, consiste à représenter le système étudié sous forme d’un système à états et transitions. Un algo-rithme explore tous les comportements possibles et vérifie que la propriété est vraie dans tout l’espace d’état. Cette approche permet de déceler le cas pire réel. Cepen-dant, si le système étudié est complexe, le nombre d’états à stocker et explorer peut être trop grand pour que l’algorithme donne une réponse en un temps raisonnable. Ce phénomène est appelé explosion (combinatoire) de l’espace d’état.

De nombreux formalismes [Baeten, 2005] permettent de représenter des systèmes et des propriétés. Le formalisme choisi devra avoir un pouvoir d’expression suffisant pour représenter tous les aspects du système (le temps car nous vérifions des propriétés temporelles, les probabilités car le lien est non-fiable, les données pour représenter les échanges de paquets, etc) et les outils qui utilisent ce formalisme doivent avoir un pouvoir d’analyse suffisant pour vérifier les propriétés désirées (incluant le temps, les probabilités).

Des vérifications formelles de systèmes distribuées ont été réalisées avec succès, notamment pour des protocoles pour réseaux filaires [Clarke and Wing, 1996]. Les caractéristiques des RCsF (large échelle, liens non-fiables) rendent l’application de ces méthodes difficile sur ce type de réseaux [Kwiatkowska et al., 2002b] [Fruth, 2006] [Fehnker et al., 2007]. D’abord, les RCsF sont des réseaux sans fil, cela implique que les communications sont de type broadcast, c’est-à-dire que seuls les nœuds à portée de l’émetteur reçoivent le paquet (les nœuds de la zone d’interférence le reçoivent, mais ne peuvent pas décoder). Ensuite, la topologie des RCsF est dynamique, les nœuds ne sont pas considérés comme mobiles, mais des nœuds disparaissent lorsque leur batterie s’épuise. La fluctuation des liens radio provoque aussi des changements dans la topologie du réseau. Enfin, les RCsF sont des réseaux larges échelles, ils peuvent être composés de plusieurs centaines de nœuds. Cela pose problème pour le passage à l’échelle des méthodes de vérification.

1.4 Contributions

Nos contributions sont de deux types : d’une part, nous proposons une solution pour l’acheminement de données en temps borné dans les RCsF ; d’autre part, nous

fournissons une méthodologie de vérification formelle des RCsF et l’appliquons à la solution d’acheminement temps-réel proposée.

Notre solution d’acheminement de données temps-réel est composée de trois élé-ments :

1. un système de coordonnées virtuelles, proposé dans le Chapitre 4, pour organiser le réseau et introduire du déterminisme : ce système permet de déterminer la distance logique (en nombre de sauts) entre un nœud et le puits et de discriminer les nœuds appartenant à un même domaine d’interférence. Ces informations sont utilisées dans les propositions suivantes.

2. un protocole de communications temps-réel pour RCsF, RTXP (Real-Time X-layer Protocol) pour la remontée d’alarmes vers le puits dans le cadre de la détection d’événements dans les RCsF. Il permet de répondre aux probléma-tiques abordées dans la section 1.3.1 :

• RTXP est cross-layer (X-layer), les couches MAC et routage sont conçues ensembles, ce qui permet de gérer les délais d’interactions ;

• le protocole s’appuie sur le système de coordonnées virtuelles, proposé dans le Chapitre 4, qui permet d’avoir des accès au canal bornés et un choix du nœud relayeur déterministe ;

• ces coordonnées permettent aussi de connaître le nombre de sauts qui séparent un nœud du puits et ainsi de le borner ;

• RTXP est localisé : les décisions MAC et routages sont prises sans connais-sance de la topologie globale du réseau, cela permet de passer l’échelle ; • RTXP s’adapte à la charge de trafic dans le réseau : les nœuds dorment s’il

n’y a pas d’alarmes à acheminer, cela permet d’économiser l’énergie ;

• le protocole utilise un routage opportuniste [Biswas and Morris, 2005] qui permet d’augmenter la fiabilité des communications de bout en bout comme nous le montrons dans le Chapitre 3.

RTXP est, à notre connaissance, le premier protocole temps-réel MAC et routage localisé pour RCsF, c’est-à-dire qu’il n’est pas nécessaire d’avoir une vision globale de la topologie du réseau pour garantir une borne sur le délai de bout en bout contrairement aux solutions qui allient MAC et routage dans la littérature [Ergen and Varaiya, 2006] [Doherty and Pister, 2008]. De plus, ce protocole tient compte de la consommation d’énergie ce qui n’est pas le cas d’autres propositions temps-réel de la littérature [Caccamo et al., 2002] [Watteyne et al., 2006a] [Roedig et al., 2006].

3. Nous proposons également, dans le Chapitre 6, un protocole d’agrégation qui permet d’atténuer l’effet de tempête d’alarmes qui survient lorsqu’un nombre important de nœuds détectent un phénomène physique et envoient des alarmes aux puits au même instant. Ces tempêtes d’alarmes induisent une surconsom-mation et une congestion du réseau non nécessaire car l’inforsurconsom-mation qui circule est redondante. Notre proposition permet d’atténuer ce problème en élisant, à l’aide du système de coordonnées virtuelles, un seul nœud pour envoyer l’alarme vers le puits, et ce en temps borné.

Dans un second temps, nous proposons une méthodologie de vérification formelle de protocoles de communication temps-réel pour RCsF. Cette méthodologie est dé-taillée dans le Chapitre 8 et prend en compte les aspects propres à ces réseaux, comme le lien radio et la taille des RCsF. Nous utilisons l’approche du Model Checking qui permet une vérification exhaustive des comportements du système et pour obtenir des bornes sur les délais de bout en bout tout en essayant de limiter l’explosion combinatoire. Dans cette seconde partie, nous proposons les contributions suivantes : 1. Une étude des différentes façons de modéliser la nature broadcast du lien ra-dio, qui sont utilisées dans la littérature, montre que certaines augmentent le problème d’explosion combinatoire et doivent donc être évitées.

2. Pour prendre en compte l’aspect probabiliste des communications radio, il faut utiliser un formalisme probabiliste. Les outils qui utilisent ce genre de forma-lismes ne permettent pas de modéliser les RCsF de manière satisfaisante (res-trictions venant du langage de modélisation et des méthodes de vérifications comme détaillé dans le Chapitre 7). Nous développons donc une méthode indé-pendante de l’outil de vérification pour introduire l’aspect probabiliste du lien radio dans la vérification formelle et pouvoir ainsi estimer le degré de fiabilité du système.

3. Dans la littérature, les vérifications de protocoles de RCsF ne vont pas au delà de quelques nœuds (4 ou 5 en général). Pour passer l’échelle, nous développons une méthode hybride qui mélange l’approche du Model Checking et le Network

Calculus. Le Model Checking servant à vérifier localement que chaque nœud

à un comportement correct quand il est soumis au comportement global du réseau représenté analytiquement sous forme de courbes de services facilement composables.

La composition de ces techniques constitue une méthodologie de vérification de protocoles temps-réel pour RCsF. Nous l’appliquons pour la vérification de RTXP dans le Chapitre 9.