Caract´eristiques hybrides des programmes embarqu´es

Comme nous l’avons dit en introduction, les programmes critiques embarqu´es interagissent avec l’environnement physique dans lequel ils sont ex´ecut´es. Leur ex´ecution est purement discr`ete, alors que l’´evolution de l’environnement ext´erieur est continue : un programme embarqu´e doit donc ˆetre vu comme une composante d’un syst`eme hybride. Cependant, certaines caract´eristiques intrins`eques de ces programmes rendent les mod`eles que nous avons pr´esent´es au chapitre 4 peu adapt´es pour repr´esenter et analyser ce type de syst`emes hybrides. Cette section vise `a expliquer ce constat.

D’un point de vue tr`es g´en´eral, un syst`eme hybride consiste en deux processus de natures diff´erentes s’ex´ecutant en parall`ele : la partie discr`ete et la partie continue. Ces deux processus communiquent `a travers des interfaces : les capteurs pour la communication du processus continu vers le processus discret, les actionneurs pour la communication en sens inverse (voir la figure 1.4). Selon les mod`eles utilis´es pour repr´esenter chaque processus et le choix du type de communica- tion pour mod´eliser les capteurs et les actionneurs (communication synchrone ou asynchrone, communication par envoi de messages ou via une m´emoire partag´ee), on obtient des mod`eles hy- brides ayant des comportements tr`es diff´erents. La principale difficult´e dans la mod´elisation d’un syst`eme hybride vient de la pr´esence d’actionneurs : ces derniers cr´eent une d´ependance cyclique entre l’´evolution discr`ete et l’´evolution continue ce qui rend la dynamique du syst`eme hybride complexe `a d´efinir. Une contribution de cette th`ese est de prendre en compte ces actionneurs et donc la r´etroaction entre le programme et son environnement. Remarquons que contrairement `a

de nombreux mod`eles hybrides, nous n’autoriserons pas un actionneur `a modifier directement la valeur d’une variable continue ; il ne pourra que modifier sa dynamique. Ceci n’est pas le cas dans la th´eorie des automates hybrides par exemple, o`u un changement d’´etat discret peut s’accompa- gner d’un changement discontinu des valeurs des variables continues. Cette possibilit´e nous semble trop peu r´ealiste (un moteur ne peut pas changer instantan´ement la position de la voiture, mais uniquement son acc´el´eration) et nous l’avons donc exclue de notre mod`ele.

La mod´elisation de la partie continue d’un syst`eme hybride est souvent donn´ee par les lois de la physique sous forme d’´equations diff´erentielles ou d’´equations aux d´eriv´ees partielles. Ce cadre tr`es g´en´eral permet d’appr´ehender de nombreux comportements continus, mais sa trop grande expressivit´e et les r´esultats d’ind´ecidabilit´e qui en d´ecoulent (th´eor`emes 4.3 et 4.4) ont pouss´e la plupart des outils de mod´elisation et d’analyse `a limiter le type d’´equations diff´erentielles permises ou `a choisir d’autres mod´elisations comme les fonctions affines par morceaux (Piecewise Affine Systems ou PWA). Les choix effectu´es pour mod´eliser la partie continue ont en fait assez peu d’incidence sur le comportement global du syst`eme, ils ont plus une fonction limitative quand `a l’expressivit´e du mod`ele. Remarquons que quelle que soit la mod´elisation choisie, un mod`ele pour la partie continue est toujours compos´e d’un ensemble de mod`eles simples repr´esentant chacun un “mode continu”, ce qui permet `a la partie discr`ete d’influer sur l’´evolution continue en en choisissant un. C’est g´en´eralement ainsi que sont mod´elis´es les actionneurs. Dans l’exemple 4.3 du thermostat, la partie continue poss`ede deux modes : un correspondant `a l’´etat o`u le radiateur est allum´e et un correspondant `a l’´etat o`u le radiateur est ´eteint.

La th´eorie des automates hybrides mod´elise la partie discr`ete du syst`eme hybride par un automate fini et associe `a chaque ´etat de l’automate un mode continu. Le syst`eme hybride est donc construit comme le produit cart´esien d’un automate fini et de l’ensemble des modes continus. Les actionneurs sont alors repr´esent´es par des changements d’´etat discret : si on reprend l’exemple du thermostat, la transition de ON `a OF F repr´esente l’action d’´eteindre le radiateur. Les capteurs ne sont pas explicitement pr´esents dans le mod`ele : la communication entre le milieu continu et le partie discr`ete repose sur une m´emoire partag´ee. En effet, le mod`ele suppose qu’`a tout instant, un ´etat discret connaˆıt l’ensemble du milieu ext´erieur, c’est-`a-dire la valeur de chaque variable continue. On peut donc supposer que la partie continue et la partie discr`ete poss`ede une zone de m´emoire partag´ee sur laquelle l’environnement continu ´ecrit et que les ´etats discrets lisent. Cette zone m´emoire repr´esente un capteur parfait (c’est-`a-dire n’introduisant pas de bruit) fonctionnant en continu. Le paradigme de communication sous sous-jacent est une communication synchrone ´ev´enementielle : lorsque l’automate entre dans un nouvel ´etat discret, il se met en attente d’un ´ev`enement lui permettant d’en sortir (soit que le pr´edicat de garde d’une transition est activ´ee, soit que l’invariant de l’´etat est contredit). De mani`ere tr`es sch´ematique, l’ex´ecution d’un automate hybride fonctionne donc ainsi :

d´ebut Initialise;

tant que vrai faire

Attendre l’´ev`enement E; si E est une transition alors

Ex´ecute la transition; sinon

echoue ; /* l’invariant de l’´etat est invalid´e, aucune transition n’est activ´ee */

finsi fintantque fin

L’ex´ecution de l’automate est donc bloqu´ee dans un ´etat discret jusqu’`a ce qu’une des transitions partant de cet ´etat soit activ´ee. C’est donc l’´evolution de l’environnement continu qui d´ecide des instants auxquels sont ex´ecut´ees les transitions discr`etes. Une des cons´equences majeures de ce choix est le non-d´eterminisme du mod`ele : si deux transitions sont activ´ees au mˆeme moment, il n’est pas pr´ecis´e laquelle doit ˆetre ex´ecut´ee.

5.1. DU PROGRAMME DISCRET AU PROGRAMME HYBRIDE 77

sont dans la tr`es grande majorit´e des cas g´en´er´es automatiquement `a partir d’un langage de sp´ecification de haut niveau qui repose sur le mod`ele synchrone (par exemple SCADE). La commu- nication entre le programme et son environnement ext´erieur se fait alors via des variables volatiles de mani`ere p´eriodique. Le sch´ema d’ex´ecution d’un programme critique embarqu´e est de la forme :

d´ebut Initialise;

tant que vrai faire Lire entr´ees;

Calculer ´etat suivant; ´

Ecrire sorties; fintantque fin

Dans la boucle de r´etroaction (Lire-Calculer-´Ecrire), la lecture correspond `a la communication entre le milieu continu et le programme discret, alors que l’´ecriture correspond `a l’action des actionneurs. Cette boucle est cadenc´ee avec pr´ecision, de sorte que les donn´ees ne sont lues que p´eriodiquement et non pas continˆument. ´Eventuellement, une analyse de pire temps d’ex´ecution (WCET, [FHL+_{01]) peut permettre d’estimer pr´ecis´ement la dur´ee d’une it´eration de}

la boucle. La communication entre le milieu continu et le programme s’apparente donc plus `a une communication par passage de messages qu’`a une communication `a m´emoire partag´ee : `a certains instants d´etermin´es par le programme discret, le programme et l’environnement continu vont se synchroniser pour ´echanger des donn´ees. Remarquons que la communication entre le milieu continu et le programme discret s’effectue via un capteur qui introduit une discr´etisation des valeurs : la valeur des variables continues r´eelles est discr´etis´ee en un nombre `a virgule flottante qui sera trait´e par le programme. Notre mod´elisation des capteurs prendra en compte cette double discr´etisation temporelle (les capteurs ne fournissent une valeur qu’`a certains instants pr´ed´etermin´es) et spatiale (les valeurs fournies sont des approximations flottantes des valeurs r´eelles). Enfin, par rapport aux automates hybrides, l’ex´ecution d’un programme embarqu´e est d´eterministe (car ´ecrit dans un langage d´eterministe) et l’ex´ecution du syst`eme est contrˆol´ee d’avantage par la partie discr`ete que par l’environnement continu.

On voit donc que les programmes embarqu´es, s’il peuvent ˆetre encod´es dans le formalisme des automates hybrides, reposent en fait sur un ´echantillonage pr´ecis du temps et des valeurs d’entr´ee alors que les mod`eles classiques de syst`emes hybrides consid`erent l’´evolution temporelle de mani`ere plus ´ev´enementielle. Cette deuxi`eme vision, si elle permet une mod´elisation plus rapide des syst`emes hybrides, rend ´egalement leur validation plus compliqu´ee : les changements d’´etats (c’est-`a-dire les changements de mode continu) sont d´etermin´es par des crit`eres purement spatiaux (la valeur des variables continues), ce qui rend la d´etection des instants de changement d’´etats dif- ficile : il faut calculer l’intersection du r´esultat de l’op´erateur d’avancement dans le tempsր avec les pr´edicats de garde (voir section 4.4.2). Les outils d’analyse limitent donc la dynamique continue pour pouvoir d´etecter ces changements d’´etats. Dans les programmes embarqu´es, les changements d’´etats se font `a travers l’´ecriture dans une variable volatile, `a la fin du cycle Lire-Calculer-´Ecrire, et donc `a des p´eriodes connues. La d´etection de changements d’´etats est donc bien plus simple, et l’on pourra s’autoriser des dynamiques non-lin´eaires lors de l’analyse (voir chapitre 7). Deux autres consid´erations font que le mod`ele des automates hybrides est moins adapt´e `a la mod´elisation et l’analyse des programmes critiques embarqu´es. D’une part, pour des raisons de sˆuret´e, il sera toujours n´ecessaire d’analyser le code source et non pas le mod`ele qui l’a g´en´er´e. On pourrait naturellement reconstruire, `a partir du code et d’une description de l’environnement continu, un automate ´equivalent, mais cette solution devient rapidement impossible pour des codes de grandes tailles ´evoluant dans des milieux physiques complexes (typiquement, les programmes utilis´es dans l’industrie a´eronautique font plusieurs centaines de milliers de lignes de code et l’environnement ext´erieur est compos´e, au moins, d’une dizaine de variables continues). Par ailleurs, dans le forma- lisme des automates hybrides, les ´etats discrets et les modes continus sont tr`es li´es (en fait, ce sont les mˆemes) et il n’y a donc pas de s´eparation r´eelle entre le continu et le discret. Pour des projets industriels, la mod´elisation de l’environnement physique et du programme discret demandent des expertises tr`es diff´erentes et sont souvent effectu´ees par des ´equipes s´epar´ees. Il nous semble donc

pr´ef´erable de disposer d’un mod`ele o`u la distinction entre le continu et le discret est nette, et tel que la communication entre les deux mondes se fassent via des interfaces d´efinies `a l’avance.