Lien avec d’autres travaux

∗ ∗

Nous venons d’esquisser une d´emarche suivant laquelle des programmes Signal, sp´ecifi´es ind´ependamment d’un choix de mise en œuvre sont d´ecrits selon une architecture modulaire int´egr´ee. Les composants ARINC d´efinis sont utilis´es pour d´ecrire le mod`ele final. Cette d´emarche s’int`egre parfaitement `a la m´ethodologie g´en´erale dePolychronypour la conception d’applica-tions distribu´ees temps r´eel, pr´esent´ee au chapitre 5. Par ailleurs, il convient de mentionner que ce n’est pas l’unique voie de repr´esentation de programmesSignalsous forme d’architecture de type IMA. Dans l’optique d’une mod´elisation de plus bas niveau, on peut vouloir exprimer un calcul complexe provenant d’une lign´ee, avec du sur-´echantillonnage temporel (i.e., l’ex´ecution d’un bloc n’est plus instantan´ee comme c’est le cas ici). Dans ce cas, l’horloge la plus rapide d’un processus ARINC n’est plus n´ecessairement celle qui est d´efinie par lepartition-level OS, mais plutˆot celle qui permet de raffiner temporellement les ex´ecutions de blocs.

8.4.3 Lien avec d’autres travaux

Dans le chapitre 1, nous avons ´evoqu´e un certain nombre d’approches `a la conception d’ap-plications temps r´eel. Il s’agit `a pr´esent de voir en quoi la nˆotre se distingue de celles-ci.

Taxys. C’est une approche qui a ´et´e d´efinie pour la conception et la validation d’applica-tions temps r´eel enfouies [65]. Elle combine les langagesEstereletCpour d´ecrire respective-ment les parties contrˆole et calcul d’une application. Conceptuellement, une telle description est constitu´ee de trois composants exprim´es enEsterel: l’application elle-mˆeme, l’environnement d’interaction de celle-ci et un gestionnaire externe des ´ev´enements ´echang´es par l’application et son environnement (cela est n´ecessaire pour ´eviter des pertes durant les ´echanges). Le code

Esterelest ensuite annot´e avec des contraintes temporelles (dur´ees d’ex´ecution des calculs et dates d’´ech´eance). L’ensemble est transform´e sous forme d’automates temporis´es. L’outil Kro-nos[219] est alors utilis´e pour v´erifier que les contraintes temporelles sp´ecifi´ees dans l’applica-tion sont bien respect´ees. Le compilateurSaxo-Rt[215] g´en`ere le code C enfoui correspondant. Un point commun de l’approcheTaxysavec celle que nous avons propos´ee est qu’elles utilisent toutes les deux la technologie synchrone. Dans un cas, c’estEsterel qui sert `a la description et dans l’autre, c’est plutˆot Signal. Elles proposent ainsi une d´emarche bas´ee sur des outils formels. La principale diff´erence entre ces approches r´eside dans la fa¸con de repr´esenter les ap-plications. En effet, notre mod´elisation propose un niveau de d´etail plus fin d’une mise en œuvre d’application temps r´eel. Elle est donc de plus bas niveau que celle qui est offerte par Taxys. Ce qui permet d’aborder davantage d’aspects d’une description d’application.

Giotto. Cette approche a d´ej`a ´et´e introduite au chapitre 1. Elle repose sur le mod`ele temporis´e pour la conception de syst`emes de contrˆole enfouis, `a contraintes temps r´eel strictes [120].

Giotto est aussi une approche formelle. Une sp´ecificit´e de celle-ci est la s´emantique time-triggered dont l’avantage est la pr´edictibilit´e des comportements temporels du syst`eme d´ecrit. Un mod`ele Giotto d’une application est donn´e sous forme de tˆaches avec un ordonnanceur.

Il est donc proche de celui que nous avons d´efini. Cependant, les tˆaches sont essentiellement p´eriodiques alors que dans notre cas, cette restriction n’existe pas.

MetaH. Nous avons ´egalement pr´esent´e le formalisme MetaH [210] au chapitre 1. Une ap-proche bas´ee sur ce formalisme a ´et´e d´efinie pour la conception de syst`emes temps r´eel em-barqu´es. Celle-ci figure parmi les plus connues dans le domaine de l’avionique. MetaH consti-tue notamment la base du standard Aadl (Avionics Architecture Description Language) [86] d´edi´e exclusivement `a la description d’architectures de syst`emes avioniques. La description d’un syst`eme suivantMetaHressemble `a celle adopt´ee dansGiotto(un ensemble de processus avec un module charg´e d’ordonnancer ceux-ci). Cependant, dans la mod´elisationMetaH, il existe `a la fois des processus p´eriodiques et ap´eriodiques, comme c’est le cas aussi dans la nˆotre. Me-taHpose quelques restrictions au niveau des communications entre processus. Ces derniers ne peuvent ´echanger de messages qu’en d´ebut ou en fin d’ex´ecution. Si ce choix facilite l’analyse des comportements de l’application, il est restrictif. Dans le mod`ele propos´e ici pour les processus ARINC, les communications peuvent avoir lieu `a n’importe quel moment de l’ex´ecution.

SynDEx. Lors de la conception d’applications distribu´ees temps r´eel dans l’environnement

SynDEx, c’est l’outil qui se charge de produire un ex´ecutif d´edi´e [106], d´efini selon les besoins de l’application sans faire appel `a un ex´ecutif r´esident. Le noyau de cet ex´ecutif est g´en´erique et facile `a porter sur d’autres composants mat´eriels. Dans notre cas, l’ex´ecutif est r´esident et conforme `a un type sp´ecifique d’architecture qui est IMA. Cela est dˆu au standard APEX qui requiert l’utilisation des bus ARINC 629 [5] et ARINC 659 [6] (cf. chapitre 7). Pour permettre l’utilisation d’ex´ecutifs bas´es sur d’autres standards (par exemple, POSIX ou OSEK), il faut ´etendre la biblioth`eque avec des mod`eles respectant les sp´ecifications issues de ces standards comme nous l’avons fait pour la norme APEX. Nous d´evelopperons ce point dans les perspec-tives donn´ees dans la conclusion de cette th`ese. L’approcheSynDExet les techniques utilis´ees dans la m´ethodologie de conception d´evelopp´ee dans Polychronysont compl´ementaires.

D’une part, dans SynDEx, la distribution et l’ordonnancement d’une application sur une architecture mat´erielle multi-processeur tient compte des crit`eres de performance de l’architec-ture cible (temps de r´eponse d´etermin´e `a partir d’un graphe logiciel de l’application, valu´e par des temps d’ex´ecution des processus sur le type de processeur consid´er´e, et les dur´ees des com-munications). Ces crit`eres sont typiquement le genre d’informations qu’on peut calculer `a l’aide de la technique d’´evaluation de performances bas´ee sur le morphisme de programmes Signal.

D’autre part, le partitionnement des applications dans SynDEx garantit une “ad´equation algorithme achitecture” : c’est-`a-dire, la distribution et l’ordonnancement obtenus automati-quement permettent de respecter des contraintes temps r´eel et de minimiser les ressources mat´erielles. Cela peut donc orienter vers des choix de partitionnement int´eressants dans la m´ethodologie g´en´erale de conception dansPolychrony. ´Etant donn´ee les sp´ecifications d’une application et de son architecture d’implantation, l’outilSynDExfournit une r´epartition opti-mis´ee de l’application qui prend en compte les performances de la plate-forme de mise en œuvre. Ce partitionnement est alors utilisable pour instancier l’application `a l’aide des mod`eles ARINC (partition, processus et services APEX). Ensuite, la phase d’´evaluation de performances pr´evue dans la m´ethodologie de Polychrony interviendra pour la validation temporelle finale, mais ´egalement pour des analyses suivant d’autres m´etriques comme l’´energie.

∗ ∗ ∗

syst`emes globalement asynchrones, localement synchrones (GALS) bas´ee sur le mod`ele syn-chrone. En particulier dans [110], Halbwachs et Baghdadi ´etudient une mod´elisation synchrone de syst`emes partiellement asynchrones. Ils illustrent quelques mod`elesEsterelde m´ecanismes ´el´ementaires de communication et de synchronisation (m´emoire partag´ee et rendez-vous). Leur travail a pour but de “syst´ematiser et populariser” l’utilisation des langages synchrones pour la description de syst`emes asynchrones `a des fins de simulation et de validation. Notre approche s’inscrit ´egalement dans cette d´emarche. De plus, elle va plus loin en mod´elisant des m´ecanismes plus complexes que ceux qui sont consid´er´es dans [110]. Enfin, grˆace `a la d´efinition d’une bi-blioth`eque de mod`eles de m´ecanismes standards, notre travail r´epond `a l’une des perspectives relev´ees par les auteurs.

8.5 Conclusion

Nous avons pr´esent´e la mod´elisation d’un certain nombre de composants permettant de d´ecrire des applications distribu´ees temps r´eel. Il s’agit d’une part, de composants utilisables pour repr´esenter des concepts d’une architecture de type IMA (`a savoir, partitions et proces-sus) ; et d’autre part, d’un ensemble de primitives permettant de mod´eliser les fonctionnalit´es d’un ex´ecutif temps r´eel. La d´efinition de ces primitives repose pour la majeure partie sur les sp´ecifications de la norme ARINC 653. Ces composants permettent ainsi de disposer d’un mod`eleSignalde support d’ex´ecution (c’est-`a-dire, l’ensemble des protocoles et services requis par des applications temps r´eel pour r´ealiser leurs fonctionnalit´es).

Les mod`eles d´efinis ici offrent des descriptions auxquelles des outils et techniques formels peuvent ˆetre appliqu´es ; en particulier, ceux de l’environnement Polychrony. La v´erification de propri´et´es comportementales d’une application peut ˆetre effectu´ee en adoptant une d´emarche similaire `a celle qui a ´et´e illustr´ee au chapitre 6. En outre, puisque la simulation est possible dans

Polychrony, le fonctionnement d’une application est observable. La validation d’un mod`ele de syst`eme temps r´eel comporte toujours une analyse de ses propri´et´es non fonctionnelles. En particulier, il faut ˆetre en mesure de garantir le respect de ses contraintes temporelles. Dans cette optique, la technique d’´evaluation de performances mise en œuvre dansPolychronyest bien adapt´ee pour nos mod`eles. Enfin, `a toutes ces possibilit´es vient s’ajouter celle de g´en´erer automatiquement du code optimis´e.

Sur le plan m´ethodologique, la d´efinition de ces composants s’inscrit dans le cadre d’une approche de conception g´en´erale qui est d´evelopp´ee dans Polychrony. Elle concerne plus pr´ecis´ement les applications distribu´ees temps r´eel (cf. chapitre 5). L’id´ee fondamentale derri`ere l’approche consiste `a utiliser le mod`ele s´emantique du langage Signalcomme support de rai-sonnement formel, `a la fois pour des aspects logiciels (i.e., fonctionnalit´es d’une application) et mat´eriels (i.e., propri´et´es de la plate-forme d’implantation). Par exemple, un raffinement des descriptions obtenues suivant cette approche consistera en l’instanciation de certaines de leurs parties `a l’aide des composants mod´elis´es.

Enfin, l’utilisation de ces composants d´epasse le cadre initial pour lequel ils ont ´et´e d´evelopp´es (c’est-`a-dire, la mod´elisation d’applications avioniques suivant ARINC). Ainsi, ils ont servi de base dans la mise en œuvre d’un sch´ema de traduction de programmes ´ecrits en Real

-Time Java vers Signal. Cela consiste d’une part, `a d´ecrire le support d’ex´ecution de pro-grammes Java et d’autre part, `a repr´esenter l’architecture fonctionnelle d’une application ´egalement ´ecrite en Java. Cela est possible en raison de la similitude des services et concepts utilis´es en Real-Time Java avec ceux d´ecrits dans la norme ARINC. Nous reviendrons sur

cette ´etude dans le chapitre suivant, apr`es avoir pr´esent´e la mod´elisation d’une application `a l’aide des composants ARINC.

Chapitre 9

Cas d’´etude : conception d’une

application `a l’aide des mod`eles

ARINC

Ce chapitre a pour but d’illustrer comment les composants ARINC permettent de mod´eliser une application de taille r´ealiste. Une ´etude similaire portant sur un exemple tr`es simple a ´et´e abord´ee dans [95]. La d´emarche qui est pr´esent´ee ici s’applique donc `a n’importe quelle appli-cation distribu´ee temps r´eel `a mod´eliser selon une architecture d´efinie en termes de partitions. Le cas d’´etude auquel nous nous sommes naturellement int´eress´e consiste en une application avionique. Cependant pour des raisons de confidentialit´e, nous nous contenterons plutˆot dans ce chapitre d’une analogie avec les satellites. Leur fonctionnement comporte en effet quelques aspects communs avec l’avionique. L’utilisation de l’informatique embarqu´ee en est un. Par cons´equent, la maintenance `a bord des appareils est l’une des tˆaches sensibles. Par ailleurs, ce sont des appareils qui sont en contact permanent avec des centres de contrˆole au sol. Ce qui leur permet de solliciter divers types de services sans ˆetre n´ecessairement au sol : des informations sur leur position courante pour la navigation, des r´eparations m´ecaniques, des ravitaillements en carburant1, etc. Ainsi, la norme ARINC sert aussi pour la construction d’´equipements pour satellites.

L’exemple que nous consid´erons dans la suite est une application qui est charg´ee d’acqu´erir et de traiter des donn´ees de maintenance re¸cues `a partir d’un satellite en orbite. Nous illustrons dans la section 9.1 la d´emarche globale sur laquelle repose la mod´elisation de cette application. Nous montrons dans la mˆeme section comment on peut proc´eder pour ´evaluer ses performances dans Polychrony. Ensuite, dans la section 9.2, nous mentionnons bri`evement une ´etude en cours reposant sur une utilisation des composants. Celle-ci a pour objectif de r´ealiser une tra-duction de programmes ´ecrits en Real-Time Java vers le langage Signal [202]. Cela permet d’acc´eder aux outils et techniques formels de Polychronypour analyser ces programmes.

1. Par exemple, dans les satellites de typeM´et´eosat (qui sont des satellites m´et´eorologiques g´eostationnaires de l’organisation europ´eenne pour l’exploitation des satellites m´et´eorologiques - l’EUMETSA), six r´eacteurs propuls´es par le carburant hydrazine sont utilis´es pour le contrˆole de l’orbite et de l’altitude. Ces r´eacteurs permettent le maintien de l’orientation du satellite dans l’espace, pour effectuer des ajustements sur orbite et pour d´eplacer le satellite vers un nouvel emplacement. Les r´eservoirs d’hydrazine sont dimensionn´es pour contenir le carburant n´ecessaire `a six ans minimum de maintenance sur orbite dans des conditions op´erationnelles normales.

9.1 Mod´elisation d’une application temps r´eel

L’application que nous d´ecrivons dans cette section s’appelle SATMAINT. Les fonctionna-lit´es tr`es vari´ees de celle-ci ne permettent pas un traitement s´equentiel. Elle est donc d´ecompos´ee en plusieurs processus regroup´es au sein d’une partition unique (ce choix a ´et´e fix´e dans le cahier des charges). La partition SATMAINT fait partie d’un module qui contient d’autres partitions avec lesquelles elle coop`ere. Les ´echanges entre partitions sont effectu´es via des sampling et

queuing ports. Ce module est quant `a lui reli´e, via un bus Ethernet, `a un p´eriph´erique assurant l’interface homme / machine de l’application SATMAINT.

Acquisition et traitement de données de maintenance

Figure 9.1 – Rˆole de l’application SATMAINT.

Dans ce qui suit, nous nous concentrons principalement sur la partition SATMAINT pour illustrer l’utilisation de nos mod`eles. Avant de pr´esenter informellement les ´el´ements qui la composent, nous indiquons d’abord ses diff´erentes fonctionnalit´es (Fig. 9.1) :

– calcul et ´emission, par SATMAINT vers les autres partitions du module, de param`etres g´en´eraux et des informations correspondant `a la phase de maintenance (cela est fait de fa¸con cyclique) ;

– acquisition et traitement par SATMAINT de messages de maintenance transmis par les autres partitions lorsque le satellite est en orbite ;

– communication avec un p´eriph´erique Q afin de permettre `a un op´erateur de visualiser les donn´ees de maintenance stock´ees en m´emoire par l’application ;

– surveillance et ´emission p´eriodique d’un rapport de maintenance.

La description globale de l’architecture de l’application est donn´ee dans la section ci-apr`es. Elle pr´esente notamment les diff´erents composants qui constituent la partition correspondante : processus, m´ecanismes de communication et synchronisation et autres ressources partag´ees.