N ordre : 2007-ISAL-0060

Institut National des Sciences Appliquees de Lyon

Ecole Doctorale Informatique et Informations pour la Societe

SAIA : un style architectural pourassurer l’independance vis-a-vis

d’entrees / sorties soumises a descontraintes temporelles

THESE

presentee et soutenue publiquement le 12 octobre 2007

pour l’obtention du

Doctorat de l’Institut National des Sciences Appliquees de Lyon

(specialite informatique)

par

Julien DeAntoni

Composition du jury

Rapporteurs : Jean-Marc Jezequel Professeur a l’universite de Rennes - IRISALionel Seinturier Professeur a l’universite de Lille 1 - LIFL

Examinateurs : Jean-Philippe Babau Maıtre de conference a l’INSA-Lyon - CITI (directeur de these)Sebastien Gerard Chercheur au CEA-Saclay - LETIYvon Trinquet Professeur a l’ecole centrale de Nantes - IRCCyNStephane Ubeda Professeur a l’INSA-Lyon - CITIFrancois Vernadat Professeur a l’INSA-Toulouse - LAAS

Laboratoire CITI : Centre d’Innovations en Telecommunications et Integration de services

-

Remer iementsUne thèse, trois ans de travail et en�n la réda tion de e manus rit. Il est lair que etaboutissement doit énormément au soutien des gens qui nous ont entourés et ompris, dans le adre professionnel aussi bien que dans le adre personnel. Je tiens don à les remer ier au traversde ette page.Je tiens d'abord à remer ier Jean-Philippe Babau, dire teur et en adrant de ette thèse, pourles trois années passées à ses �tés. Il a su m'orienter dans e petit monde qu'est la re her heet faire preuve de patien e dans les moments di� iles. Je le remer ie pour ses onseils, sa om-préhension et l'autonomie qu'il m'a laissé dans mon travail. Il est pour beau oup dans la réussitede ette thèse.Je tiens également à remer ier ha un des membres du jury pour avoir a epté de jouer er�le et en parti ulier, Jean-Mar Jézéquel et Lionel Seinturier pour les onseils avisés qu'ils m'ontpro urés en tant que rapporteurs de ette thèse.En�n, pour ne pas utiliser un style trop répétitif et a�n d'apporter la tou he d'originalitésouvent re her hée dans les remer iements, la suite de mes remer iements est présentée, pagesuivante, sous forme de mots roisés.

i

Horizontal Verti al4 Amis : aussi appelé monsieur dépoireaux, on a passé pas malde temps à parler de tout et surtout de rien. 1 Amies++ : son soutien journalier et ses rele tures ne sontqu'une in�me partie du bon temps passé à ses �tés.5 Amis/ ollègues : une ren ontre originale pour quelqu'un d'o-riginal ave qui il fait bon dis uter. 2 Famille : sans elle je ne serais rien, au sens propre omme�guré ! Je lui dois énormément.6 Autres : là où se mettre au vert prend tout son sens, 'estégalement un endroit peuplé d'amis. 3 Amis/ ollègues : Pas fa ile d'être thésard après lui, malgré ela e fut un bonheur de le onnaître et de dis uter ave lui.9 Collègues : Menés par Stéphane Ubéda qui m'a a ueillidans le laboratoire CITI et à qui j'exprime ma gratitude,ils m'ont tous donné les moyens d'e�e tuer ette thèse dansles meilleurs onditions. 7 Famille : que de bon temps passé ave lui à dis uter et àbosser omme des vrais hefs ed' hantier.12 Autres : utilisés au quotidien, je pense qu'ils apportent beau- oup et en parti ulier au monde a adémique. 8 Collègues : Sylvain, Pierri k, Pitou, Aurélien, Adrien,Samarth, e fut un plaisir de les en adrer ou simplementde les a ueillir au bureau.14 Famille : elle m'a soutenu depuis le début de mes études, aumoins une heure par semaine au téléphone ;-) Mer i ! ! ! 10 Amis/ ollègues : après 4 ans de vie ommune au bureau, jepeux lui dire un grand Chokran.15 Autres : wikipedia, wordreferen e, radioblog lub, s holar-google en font parti. 11 Autres : Noir Désir, Léo Ferré, Les béruriers noirs, Tra yChapmann, Alain Sou hon ne sont que des exemples.16 Amis/ ollègues : aussi fort en info qu'aux jeux de artes, sonfoie doit me haïr... 13 Autres : Université dans laquelle j'ai eu le bonheur d'êtremoniteur et ainsi, d'e�e tuer mes premières armes en tantqu'enseignant.Mer i à tous ! ! !ii

Table des matièresChapitre 1Introdu tionChapitre 2État de l'art2.1 Domaine d'étude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.1 Introdu tion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.2 Aspe ts temporels des systèmes de ontr�le de pro essus . . . . . . . . . . 82.1.3 Développement des systèmes de ontr�le de pro essus . . . . . . . . . . . 92.1.4 Con lusion du domaine d'étude . . . . . . . . . . . . . . . . . . . . . . . . 102.2 Ar hite ture et génie logi iel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.1 Dé�nitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.2 Béné� es attendus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.3 Dé rire une ar hite ture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.3.1 Les omposants . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.3.2 Les interfa es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2.3.3 Les onne teurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2.3.4 La on�guration et son niveau de des ription . . . . . . . . . . . 192.2.3.5 Le style ar hite tural . . . . . . . . . . . . . . . . . . . . . . . . 202.2.3.6 Le langage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.2.3.6.1 Con lusion sur le langage . . . . . . . . . . . . . . . . . 232.2.4 Analyse d'une on�guration . . . . . . . . . . . . . . . . . . . . . . . . . . 242.2.5 Mise en ÷uvre d'une ar hite ture logi ielle . . . . . . . . . . . . . . . . . . 262.2.6 Con lusion sur les ar hite tures . . . . . . . . . . . . . . . . . . . . . . . . 282.3 Les prin ipes de l'indépendan e . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.3.1 Introdu tion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.3.2 Notion de plateforme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.3.3 Indépendan e, les appro hes existantes . . . . . . . . . . . . . . . . . . . . 322.3.3.1 L'indépendan e vis-à-vis de l'ar hite ture matérielle . . . . . . . 322.3.3.2 L'indépendan e dans les réseaux . . . . . . . . . . . . . . . . . . 342.3.3.3 L'indépendan e vis-à-vis des Interfa es Homme Ma hine (IHM) . 362.3.3.4 L'indépendan e vis-à-vis des périphériques . . . . . . . . . . . . 392.3.3.5 Con lusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.4 Con lusion sur l'état de l'art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Chapitre 3SAIA3.1 Le style ar hite tural SAIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47iii

TABLE DES MATIÈRES3.1.1 La stru turation en ou hes . . . . . . . . . . . . . . . . . . . . . . . . . . 473.1.2 Le onne teur omplexe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.1.3 QoS et qualité de ontr�le . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.1.4 Le ontrat de QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.1.5 Niveau de des ription ar hite turale . . . . . . . . . . . . . . . . . . . . . 503.1.6 SAIA et le langage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.2 Les (méta-)modèles dans SAIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.2.1 Le modèle à omposant . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.2.2 Le modèle SAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.2.2.1 Les pilotes d'a quisition de données . . . . . . . . . . . . . . . . 553.2.2.2 Les pilotes d'a quisition d'événements . . . . . . . . . . . . . . . 563.2.2.3 Les pilotes de réalisation de ommandes . . . . . . . . . . . . . . 573.2.2.4 Les pilotes de réalisation de ommandes événementielles . . . . . 573.2.2.5 Le SAM et la qualité de servi e . . . . . . . . . . . . . . . . . . . 573.2.2.6 Con lusion sur le SAM . . . . . . . . . . . . . . . . . . . . . . . 583.2.3 Le modèle SAIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.2.3.1 Les entrées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.2.3.1.1 Les données . . . . . . . . . . . . . . . . . . . . . . . . . 603.2.3.1.2 Les événements . . . . . . . . . . . . . . . . . . . . . . . 613.2.3.2 Les sorties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.2.3.2.1 Les ommandes . . . . . . . . . . . . . . . . . . . . . . . 623.2.3.2.2 Les ommandes événementielles . . . . . . . . . . . . . 623.2.3.3 Le SAIM et la QoS . . . . . . . . . . . . . . . . . . . . . . . . . 623.2.3.4 Con lusion sur le SAIM . . . . . . . . . . . . . . . . . . . . . . . 633.2.4 Le onne teur omplexe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643.2.4.1 Les types de omposants de l'ALM . . . . . . . . . . . . . . . . . 643.2.4.1.1 Les omposants d'adaptation d'entrées . . . . . . . . . . 653.2.4.1.2 Les omposants d'adaptation de sorties . . . . . . . . . 653.2.4.1.3 Les interfa es de on�guration . . . . . . . . . . . . . . 673.2.4.1.4 Contraintes stru turelles . . . . . . . . . . . . . . . . . . 673.2.4.2 Spé i� ation de la �glue� . . . . . . . . . . . . . . . . . . . . . . 693.2.4.2.1 Adaptation de types / unités . . . . . . . . . . . . . . . 693.2.4.2.2 Adaptation sémantique . . . . . . . . . . . . . . . . . . 703.2.4.2.3 Adaptation de QoS . . . . . . . . . . . . . . . . . . . . 713.2.4.3 Con lusion sur l'ALM . . . . . . . . . . . . . . . . . . . . . . . . 723.3 SAIA et la QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723.3.1 Introdu tion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723.3.2 Dé�nition de la QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733.3.2.1 Dé�nition des o urren es de QoS . . . . . . . . . . . . . . . . . 733.3.2.2 Dé�nition des ara téristiques de QoS . . . . . . . . . . . . . . . 753.3.3 Analyse du onne teur omplexe . . . . . . . . . . . . . . . . . . . . . . . 763.3.3.1 Prin ipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763.3.3.2 Méthode d'analyse . . . . . . . . . . . . . . . . . . . . . . . . . . 773.3.4 Établissement du ontrat de QoS . . . . . . . . . . . . . . . . . . . . . . . 793.3.4.1 Résumé des étapes d'établissement d'un ontrat de QoS dans SAIA 813.4 Con lusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83iv

TABLE DES MATIÈRESChapitre 4Évaluation de l'appro he4.1 Outil de modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 874.2 Pro essus de modélisation in rémentaux dans SAIA . . . . . . . . . . . . . . . . . 894.2.1 Développement du SAIM . . . . . . . . . . . . . . . . . . . . . . . . . . . 894.2.2 Développement du SAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904.2.3 Développement de l'ALM . . . . . . . . . . . . . . . . . . . . . . . . . . . 914.2.4 Evaluation et ontrat de QoS . . . . . . . . . . . . . . . . . . . . . . . . . 924.3 Illustration de la méthode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934.3.1 Réalisation du SAIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934.3.1.1 Étape 1 : extra tion des entrées / sorties . . . . . . . . . . . . . 934.3.1.2 Étape 2 : Réalisation de l'appli ation de ontr�le . . . . . . . . . 944.3.1.3 Étape 3 : Extra tion de la qualité de ontr�le à respe ter . . . . 954.3.1.4 Étape 4 : Dérivation de la qualité de ontr�le en QoS . . . . . . 954.3.1.5 Étape 5 : Finalisation du SAIM . . . . . . . . . . . . . . . . . . 964.3.2 Réalisation du SAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974.3.3 Réalisation de l'ALM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 994.3.3.1 Étape 1 : stru ture des sous onne teurs . . . . . . . . . . . . . . 994.3.3.2 Étape 2 : stru ture de la �glue� des sous onne teurs . . . . . . . 1004.3.3.3 Étape 3 : spé i� ation des omposants de la �glue� . . . . . . . . 1014.3.4 Réalisation de l'évaluation de la QoS . . . . . . . . . . . . . . . . . . . . . 1014.3.5 Réalisation de l'établissement du ontrat de QoS . . . . . . . . . . . . . . 1014.3.6 Con lusion sur l'illustration de la méthode . . . . . . . . . . . . . . . . . . 1024.4 SAIA pour la mise au point de systèmes . . . . . . . . . . . . . . . . . . . . . . . 1024.5 Con ours no 1 : The maRTian Task . . . . . . . . . . . . . . . . . . . . . . . . . . 1054.5.1 Le simulateur asso ié à maRTian Task . . . . . . . . . . . . . . . . . . . . 1064.5.2 Déployer l'appli ation de ontr�le sur une ible réelle . . . . . . . . . . . . 1074.5.3 SAIA et le développement basé sur un simulateur . . . . . . . . . . . . . . 1084.5.4 La mise en ÷uvre des modèles . . . . . . . . . . . . . . . . . . . . . . . . 1084.6 Con ours no 2 : The CiberMouse Proje t . . . . . . . . . . . . . . . . . . . . . . . 1104.6.1 CiberMouse versus maRTian Task . . . . . . . . . . . . . . . . . . . . . . 1104.6.2 Les modi� ations dans le SAIM . . . . . . . . . . . . . . . . . . . . . . . . 1124.6.3 Le onne teur omplexe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1124.6.3.1 L'a quisition de la position du robot . . . . . . . . . . . . . . . . 1124.6.3.2 Le pilotage du SAIM . . . . . . . . . . . . . . . . . . . . . . . . 1134.6.3.3 Con lusion de CiberMouse . . . . . . . . . . . . . . . . . . . . . 1144.7 Con lusion sur l'évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Chapitre 5Con lusion et Perspe tivesBibliographie 123v

TABLE DES MATIÈRES

vi

1Introdu tionLes ordinateurs personnels sont la manifestation la plus visible de l'arrivée massive des or-dinateurs dans notre quotidien. Pour autant la quasi-totalité des pro esseurs que nous utilisonssont intégrés dans des objets de notre quotidien. Depuis les ma hines à laver, en passant par les limatisations ou en ore par les moyens de lo omotions, l'informatique prend une pla e de plusen plus enfouie dans notre vie de tous les jours. Ces systèmes informatiques appelés systèmesembarqués sont di�érents des ordinateurs personnels (PC, Ma ) pour plusieurs raisons.La première di�éren e on erne leur utilisation. Un ordinateur personnel permet de réaliserplusieurs a tivités aussi diverses et variées que la programmation de logi iels, des al uls om-plexes, la le ture de � hiers multimédia ou en ore la réda tion de do uments de bureautique.Contrairement à ela, si un système tel qu'un four intègre un système informatique, elui- i nefournit que les fon tionnalités en rapport ave le four ; soit le ontr�le de la uisson des aliments.On parle alors de système dédié, 'est-à-dire un système dont les fon tionnalités logi ielles sontintimement liées aux fon tionnalités de l'objet sur lequel elles s'exé utent.Une autre di�éren e entre les systèmes embarqués et les ordinateurs personnels est qu'ils nedisposent pas d'é rans lassiques, de laviers ou de souris. La ommuni ation entre l'homme etde tels systèmes, lorsqu'elle est possible, est plus limitée qu'ave un ordinateur personnel. Onparle alors de systèmes enfouis, 'est-à-dire invisible à l'utilisateur. De e fait, la maintenan e enest plus omplexe ar le système peut ne pas posséder de tou he �redémarrer� ou �reset�. Cessystèmes sont don soumis à des véri� ations plus poussées que les ordinateurs personnels a�nd'éviter un arrêt inopiné, les rendant potentiellement dangereux ou inutilisables. Si dans le asdu four, la uisson risque simplement d'être mauvaise, dans le as du système de freinage d'unevoiture, les onséquen es peuvent être graves et mettre des vies en danger ; on parle alors desystèmes ritiques.Une autre di�éren e notable est qu'un système embarqué ommunique ave un pro essus1

Chapitre 1. Introdu tionphysique dont il doit assurer le ontr�le. Par exemple l'ABS (Anti Blo age System) d'une voiturene ommunique pas dire tement ave l'utilisateur de la voiture mais ommunique de manièrepermanente ave l'environnement physique ; 'est-à-dire ave la roue et le frein de la voiture.On parle alors de système de ontr�le de pro essus. Un système de ontr�le de pro essus esten harge de réguler de manière �able un pro essus de l'environnement physique. Pour ela ilré upère les informations en provenan e de l'environnement à l'aide de apteurs et il agit surl'environnement physique à l'aide d'a tionneurs.Le fait qu'un système embarqué soit lié à un pro essus et don à la dynamique de e pro essusen fait un système temps réel ; 'est-à-dire un système dont la validité dépend non seulement del'a tion entreprise mais aussi du temps dans lequel l'a tion est entreprise. À titre d'illustration,la ommande de freinage d'un véhi ule est dite orre te si elle ralentit le véhi ule mais aussi sielle est e�e tuée dans un temps borné après l'appui sur la pédale de frein.Dans le adre de ette thèse, nous nous intéressons au développement des systèmes embarqués,dédiés au ontr�le de pro essus. Plus pré isément, nous nous intéressons à la partie logi ielle de es systèmes en assurant leur orre tion.Les ara téristiques énon ées pré édemment impliquent des di�éren es entre le développe-ment des systèmes de ontr�le de pro essus temps réel et le développement d'un système lassiquesur deux points prin ipaux. D'une part la riti ité des systèmes et leurs ontraintes temporellesimposent une véri� ation formelle. D'autre part, l'aspe t dédié des hoix te hnologiques (en termede système d'exploitation, de moyens d'intera tion ave l'environnement, de pro esseur, de apa -ité mémoire, de médium de ommuni ation, ...) est spé i�que à haque domaine, voire à haquesystème. On peut noter qu'un des aspe ts spé i�ques essentiel dans l'ar hite ture matérielle dessystèmes de ontr�le de pro essus temps réel porte sur les moyens d'intera tion de l'appli ationave son environnement via les apteurs et les a tionneurs. Ces hoix impa tent lourdement le omportement temporel des systèmes et doivent don faire l'objet d'une attention parti ulière.A�n de maîtriser �nement les paramètres temporels lors du développement et aboutir à unsystème orre t, les méthodes utilisées sont souvent entrées sur l'implémentation. Toutes esspé i� ités font des systèmes de ontr�le de pro essus temps réel des systèmes di� iles à réu-tiliser ou à faire évoluer. Pour autant, a�n d'être réa tif aux besoins du mar hé, es systèmesdoivent aujourd'hui pouvoir évoluer rapidement, que e soit au niveau de la partie matérielle oude la partie logi ielle qui y est implantée. Devant la multipli ation et la omplexité roissante de es systèmes, assurer une réutilisation sûre de ertaines fon tionnalités logi ielles de es systèmesdoit aider à améliorer le développement. En parti ulier, omme dans les systèmes lassiques,un besoin de plus en plus exprimé par les industriels est de pouvoir développer une appli ationlogi ielle en s'a�ran hissant de la ible matérielle et en parti ulier en s'a�ran hissant des ap-teurs et des a tionneurs. Ce i est d'autant plus vrai que les premières phases du développementdes appli ations logi ielles ne sont pas e�e tuées sur une ible matérielle réelle mais sur la iblematérielle simulée. Permettre de s'a�ran hir de la ible matérielle lors du développement o�redeux avantages ertains :� une appli ation développée et validée sur une ible matérielle simulée peut être déployéesur une ible réelle sans modi� ation ;� une appli ation peut être déployée sur des ibles matérielles di�érentes.Cependant, puisque la qualité de l'intera tion entre l'appli ation et le pro essus impa tefortement la validité du système, il est né essaire de pouvoir quali�er la qualité d'intera tionné essaire à une appli ation pour être réutilisée orre tement. Ces di�érentes préo upations2

amènent à se poser une série de questions :� Comment développer une appli ation de ontr�le de pro essus indépendamment d'unete hnologie spé i�que de apteurs et d'a tionneurs ?� Comment spé i�er et valider la qualité d'intera tion né essaire à l'appli ation pour assurerun ontr�le orre t ?� Et en�n, omment s'assurer qu'une te hnologie de apteurs et d'a tionneurs réels respe tela qualité d'intera tion spé i�ée par l'appli ation ?Considérer es questions in�ue sur le pro essus de développement. Le développement d'unsystème passe par un en haînement d'étapes ayant ha une un obje tif di�érent dans la on ep-tion du système. Dé�nir es di�érentes étapes, leurs en haînements et obje tifs revient à gérer ledéveloppement d'un système informatique. On regroupe les études liées à e domaine à un vastedomaine visant à améliorer la qualité logi iel et nommé génie logi iel. De nombreux prin ipesde génie logi iel ont été proposés dans la littérature pour améliorer le développement de sys-tèmes omplexes et en parti ulier pour aider la réutilisation orre te des appli ations. Parmi estravaux on retrouve les études autour de la stru turation de logi iel (software ar hite ture) et lesappro hes dirigées par les modèles. La stru turation de logi iel permet de raisonner sur une vuede haut niveau d'un système logi iel et ainsi o�re un support pour la prise en onsidération del'évolutivité et de la réutilisation des systèmes logi iels. Les appro hes dirigées par les modèles,quand à elles, permettent de dé�nir les on epts d'un domaine à partir d'un ou plusieurs modèlespla és au entre de l'a tivité de développement. Ces appro hes ont déjà montré leurs béné� espour la réutilisation, lors du développement, de systèmes non dédiés et non temps réel. Certainstravaux a tuels on ernent l'appli ation de es prin ipes dans le adre des systèmes dédiés tempsréels. Cependant, dans les systèmes visés par notre étude, les moyens spé i�ques d'intera tionave l'environnement sont rarement traités.Le but de ette thèse est de traiter les questions énon ées pré édemment en utilisant lesprin ipes de génie logi iel liés à la stru turation de logi iel et aux appro hes dirigées par lesmodèles. Plus parti ulièrement, l'étude s'atta he à fournir, d'une part des prin ipes de stru tura-tion permettant de développer une appli ation de ontr�le de pro essus indépendamment d'unete hnologie de apteurs et d'a tionneurs ; et d'autre part à assurer, par une analyse formelle, la orre tion de l'appli ation lors de son utilisation ave une te hnologie de apteurs et d'a tionneursspé i�ques. Ces deux préo upations ont été traitées en fournissant :� un style ar hite tural dé�nissant des règles de stru turation du logi iel via di�érents typesde omposants et des ontraintes sur leur asso iation permettant d'obtenir une stru tureanalysable ;� une formalisation des ontraintes temporelles on ernant : la ommuni ation d'une appli- ation de ontr�le ave le monde extérieur et la ommuni ation de l'appli ation de ontr�leave une plateforme spé i�que de ommuni ation ave le monde extérieur ;� une formalisation de l'établissement d'un ontrat de qualité de servi e (QoS : Quality ofServi e) lors du déploiement de l'appli ation de ontr�le sur une plateforme de ommuni- ation ave le monde extérieur,� une proposition de méthode et d'outil pour fa iliter la mise en ÷uvre du style ar hite turalet des analyses formelles.Cette thèse s'arti ule autour de inq hapitres. Le deuxième hapitre ommen e par uneprésentation du ontexte d'étude dans lequel s'ins rit ette thèse. Il permet de présenter lesspé i� ités des systèmes visés ainsi que de dé�nir les termes employés tout au long de ettethèse. Une fois le ontexte présenté, un état de l'art omposé de deux parties est proposé. Lapremière partie de et état de l'art propose un panel des on epts a tuellement proposés pour3

Chapitre 1. Introdu tionla modélisation d'une ar hite ture logi ielle, en parti ulier dans le domaine de l'embarqué. Cettepartie est issue d'une synthèse des di�érentes appro hes existantes aussi bien dans le domaine dugénie logi iel à base de omposants (CBSE : Component Based Software Engineering) que dans ledomaine des ar hite tures logi ielles (Software Ar hite ture) proprement dit. La troisième partiede e hapitre présente les stru turations lassiquement adoptées en informatique pour permettrela réutilisation orre te d'une même appli ation sur plusieurs ibles.Après une analyse ritique de l'état de l'art, le quatrième hapitre dé rit la propositione�e tuée dans ette thèse, appelée SAIA pour Sensors / A tuators Independent Ar hite ture.A�n de fa iliter la le ture, e hapitre ommen e par une synthèse permettant d'introduire les on epts de SAIA. Ces on epts sont dé rits au travers des prin ipes de stru turation ainsi quedes prin ipes de gestion de la QoS. Ensuite, le modèle à omposant utilisé est présenté avant dedé rire en détail les di�érents types de omposants dé�nis ainsi que les servi es qui leurs sontasso iés. Une fois les types de omposants présentés, une vision détaillée de la formalisation etde la gestion des ontraintes temporelles pour l'établissement d'un ontrat de QoS est fournie.En�n, une on lusion rappelle les points lefs de l'appro he.Le inquième hapitre propose ensuite une évaluation de l'appro he proposée. Pour ela il ommen e par présenter l'outil de modélisation permettant de onstruire des appli ations on-formes à SAIA. Ensuite, deux méthodes pour l'utilisation de SAIA sont présentées et illustrées autravers d'un exemple. La première méthode dé�nit des pro essus in rémentaux de modélisationalors que la deuxième est fo alisée sur la mise au point des paramètres temporels système. Pour�nir e hapitre, la mise en ÷uvre de SAIA est présentée au travers des modèles et des implémen-tations réalisés dans le adre de deux on ours internationaux de programmation temps réel. Lepremier on ours a permis de s'assurer de la faisabilité de l'implémentation de l'ar hite ture mod-élisée. Le deuxième on ours a permis d'évaluer la propension de réutilisation des modèles SAIAen réutilisant les modèles du premier on ours sur une plateforme de ommuni ation di�érente.En�n, le sixième et dernier hapitre donne les on lusions, ainsi que des perspe tives pourles travaux menés durant ette thèse.

4

2État de l'artSommaire2.1 Domaine d'étude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.1 Introdu tion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.2 Aspe ts temporels des systèmes de ontr�le de pro essus . . . . . . . . 82.1.3 Développement des systèmes de ontr�le de pro essus . . . . . . . . . 92.1.4 Con lusion du domaine d'étude . . . . . . . . . . . . . . . . . . . . . . 102.2 Ar hite ture et génie logi iel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.1 Dé�nitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.2 Béné� es attendus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.3 Dé rire une ar hite ture . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.3.1 Les omposants . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.3.2 Les interfa es . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2.3.3 Les onne teurs . . . . . . . . . . . . . . . . . . . . . . . . . 182.2.3.4 La on�guration et son niveau de des ription . . . . . . . . . 192.2.3.5 Le style ar hite tural . . . . . . . . . . . . . . . . . . . . . . 202.2.3.6 Le langage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.2.3.6.1 Con lusion sur le langage . . . . . . . . . . . . . . 232.2.4 Analyse d'une on�guration . . . . . . . . . . . . . . . . . . . . . . . . 242.2.5 Mise en ÷uvre d'une ar hite ture logi ielle . . . . . . . . . . . . . . . . 262.2.6 Con lusion sur les ar hite tures . . . . . . . . . . . . . . . . . . . . . . 282.3 Les prin ipes de l'indépendan e . . . . . . . . . . . . . . . . . . . . . . . . . . 302.3.1 Introdu tion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.3.2 Notion de plateforme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.3.3 Indépendan e, les appro hes existantes . . . . . . . . . . . . . . . . . . 322.3.3.1 L'indépendan e vis-à-vis de l'ar hite ture matérielle . . . . . 322.3.3.2 L'indépendan e dans les réseaux . . . . . . . . . . . . . . . . 342.3.3.3 L'indépendan e vis-à-vis des Interfa es HommeMa hine (IHM) 365

Chapitre 2. État de l'art2.3.3.4 L'indépendan e vis-à-vis des périphériques . . . . . . . . . . 392.3.3.5 Con lusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.4 Con lusion sur l'état de l'art . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6

2.1. Domaine d'étude2.1 Domaine d'étude2.1.1 Introdu tionL'étude menée dans ette thèse s'intéresse aux systèmes de ontr�le de pro essus. Un systèmede ontr�le de pro essus est un système informatique dont le fon tionnement est assujetti àl'évolution dynamique de l'état de l'environnement qui lui est onne té et dont il doit ontr�lerle omportement.Dans de tels systèmes, on distingue quatre entités prin ipales ( f. �gure 2.1) :le système de ontr�le : 'est l'entité qui omprend l'appli ation de ontr�le ainsi que le sup-port lui permettant de s'exé uter. C'est l'asso iation support et logi iel qui permet d'obtenirles informations sur le pro essus via des apteurs et d'agir sur elui- i à l'aide d'a tionneurs.le pro essus : 'est l'entité à ontr�ler. Son état peut être mesuré par un ou plusieurs apteursde même qu'il peut être modi�é par un ou plusieurs a tionneurs. Le pro essus évolue au ÷ur de son environnement.l'environnement physique du pro essus : 'est l'ensemble des phénomènes physiques quin'appartiennent pas au pro essus mais dont l'évolution impa te le omportement du pro- essus.l'opérateur : 'est une personne ou un système extérieur fournissant des dire tives que le sys-tème doit réaliser sur le pro essus. Il peut être informé sur l'état du pro essus ainsi que surl'état du ontr�le.Dans la suite du do ument, l'ensemble environnement physique, pro essus et opérateur estdésigné par l'expression �monde extérieur�.On distingue plusieurs types d'informations é hangées entre le monde extérieur et le système.Les informations dites �en entrée� sont onsommées par le système et elles dites �en sortie� sontproduites par le système. En entrée, on distingue les Mesures e�e tuées sur le pro essus ou surl'environnement, et les Consignes fournies par l'opérateur.Une Mesure re�ète l'état du pro essus ou de l'environnement. Une mesure est un �ot in�nid'o urren es notées f représentatif d'une grandeur physique appartenant au monde extérieur etnotée ϕ. Chaque o urren e du �ot est notée fi et orrespond à une o urren e de ϕ notée ϕi où ireprésente le numéro de l'o urren e entre 1 et l'∞. Elles sont lassiquement dé linées en donnéeset en événements. L'o urren e d'une donnée est ara térisée par une date d'a quisition notée@fi et une valeur notée V (fi) alors que l'o urren e d'un évènement est ara térisée seulementpar sa date d'arrivée dans le système. On parle alors de �ot de données ou de �ot d'événements.Toujours en entrée, une Consigne est un �ot de données ou d'événements servant de dire tiveou d'obje tif pour le ontr�le de pro essus. Dans notre étude, toute information en entrée esta quise par l'intermédiaire d'entités appelées apteurs ( f. �gure 2.1).Les informations ir ulant en sortie du système sont appelées Commandes. Les Commandessont un �ot de données ou d'événements. Ces �ots d'informations servent à ommander les a -tionneurs ( f. �gure 2.1) qui transforment haque o urren e en une a tion physique et modi�ent7

Chapitre 2. État de l'artainsi l'état du pro essus.À titre d'exemple, prenons le as du ontr�le d'une voiture. Le système est représenté par : les apteurs fournissant les Mesures (vitesse, température moteur, et .), les apteurs fournissant lesConsignes (position de la pédale d'a élération, de freins, et .), un système de ontr�le qui al uleles Commandes et les a tionneurs qui réalisent les Commandes (niveau d'admission éle tronique,pression de la mâ hoire de frein, puissan e d'un moteur de ventilateur, et .).Dans e as, le pro essus est la voiture en elle-même, 'est-à-dire sa arrosserie, ses roule-ments, ses roues, la boîte de vitesse, et . L'environnement de la voiture est onstitué de la route,sa signalétique, des autres voitures, et . L'opérateur est i i le ondu teur (réel mais pourquoipas automatique) qui a tionne les pédales de freins, d'a élération et autres a�n de fournir lesConsignes au système.

Fig. 2.1 � Représentation d'un système de ontr�le de pro essusIl est à noter que pour ertaines Consignes, lorsqu'elles sont di tées par un utilisateur, le apteur orrespondant peut faire partie d'une interfa e homme ma hine (IHM). Les appro hesréalisées autour des IHMs sont nombreuses et font l'objet d'études parti ulières. Dans e do -ument les informations en provenan e ou à destination d'IHMs sont onsidérées omme desinformations en provenan e de apteurs ou à destination d'a tionneurs.2.1.2 Aspe ts temporels des systèmes de ontr�le de pro essusLes systèmes de ontr�le de pro essus sont des systèmes temps réel dans le sens où leurdynamique est di tée par la dynamique du pro essus qu'ils ontr�lent. A�n d'assurer un ontr�le orre t du pro essus, la qualité des informations é hangées entre l'appli ation de ontr�le et lemonde extérieur est essentielle. Ces informations sont don sujettes à une des ription de leurqualité ; des ription essentiellement temporelle. [105, 64℄ mettent l'a ent sur deux propriétéstemporelles importantes : La loi d'arrivée et la loi de retard. Lorsqu'une fusion d'informationsintervient en un point, il est également important de onnaître la loi de orrélation temporelleentre les informations fusionnées. La dé�nition informelle de es propriétés temporelles est donnéedans la suite de e hapitre.8

2.1. Domaine d'étudeSur lesMesures, les Commandes et les Consignes, la loi d'arrivée est la loi exprimant le tempsé oulé entre deux o urren es su essives d'une Mesure, d'une Commande ou d'une Consignedans son �ot.Pour les Mesures et les Consignes, la loi de retard exprime la loi sur les temps é oulésentre la date à laquelle une information est présente dans l'environnement et la date à laquellel'o urren e orrespondante est onsidérée dans le système.Pour les Commandes, la loi de retard est la loi représentant le temps é oulé entre la dateoù le système produit la Commande et la date à laquelle la Commande ou l'a tion physique orrespondante est onsidérée.Pour toutes les informations dans le système, la loi de orrélation temporelle est la di�éren ed'âge entre les informations fusionnées, au moment de la fusion.D'autres propriétés peuvent aussi être onsidérées pour es systèmes, telles que la pré isionsur les données ou en ore les é héan es de bout en bout, qui spé i�e le temps a eptables entrel'a quisition d'une information en entrée et la réalisation de l'a tion physique orrespondante ensortie du système. Dans notre étude, nous nous on entrons sur la loi d'arrivée, la loi de retardet la loi de orrélation temporelle. Ce hoix s'appuie sur le onstat de [129, 105, 64, 104, 77℄,qui montre que si les lois temporelles ara térisant les �ots d'informations en provenan e ou àdestination des apteurs et des a tionneurs ne sont pas prises en ompte lors du développement,elles peuvent rendre le système à l'exé ution instable. Plus pré isément, les lois temporellesin�uent sur la qualité de ontr�le du système. C'est-à-dire sur la pré ision du ontr�le sur lepro essus par rapport à une Consigne donnée.Nous venons de présenter les spé i� ités des systèmes de ontr�le de pro essus. Ces spé i� itésin�uent sur le pro essus de développement dont la démar he lassique ainsi que les tendan esa tuelles sont présentées dans la se tion suivante.2.1.3 Développement des systèmes de ontr�le de pro essusLors du développement d'un système de ontr�le de pro essus, il est primordial de s'as-surer que la qualité de ontr�le du système est respe tée. Nous avons vu que ela revient, entreautres, à maîtriser les ontraintes temporelles du système. Pour e faire, les appro hes dédiées audéveloppement des systèmes de ontr�le de pro essus sont di�érentes des appro hes de développe-ment des systèmes informatiques lassiques tels que les systèmes d'informations. En e�et, a�nde permettre une maîtrise �ne des propriétés temporelles, les parties logi ielle(s), matérielle(s)et physique(s) des systèmes de ontr�le de pro essus sont fortement ouplées dès les premièresétapes du développement.Classiquement, les appro hes de développement ommen ent par la modélisation du pro essusphysique à ontr�ler ainsi que des di�érents apteurs et a tionneurs permettant la ommuni ationave le pro essus. Cette modélisation est basée sur des outils tels que Matlab/Simulink [80, 82℄,ASCET-SE [42℄ ou en ore Dspa e [39℄, permettant la modélisation de systèmes physiques. Il estalors possible de développer l'appli ation de ontr�le d'après les spé i� ations du système. Ce9

Chapitre 2. État de l'artdéveloppement passe essentiellement par l'utilisation de modèles ayant des fondements mathé-matiques forts tels que les modèles réalisables dans Simulink/State�ow. Ces modèles peuventalors être mis au point et validés vis-à-vis de leurs fon tionnalités et de la qualité de ontr�lere her hées. Cette étape est réalisée par une phase de simulation in luant le modèle physique dupro essus à ontr�ler, le modèle des apteurs et des a tionneurs ainsi que le modèle de l'appli a-tion de ontr�le. Une fois le modèle de l'appli ation de ontr�le mis au point, la dernière étapedu développement onsiste à implanter e modèle ; 'est-à-dire à réer le ode binaire permettantde réaliser les fon tionnalités dé rites dans le modèle de l'appli ation de ontr�le. Depuis unedizaine d'années, des logi iels tels que SCADE [41℄ ou en ore Matlab real time workshop [81℄permettent de générer automatiquement le ode. De plus, es logi iels permettent de spé i�er lemodèle de tâ hes sous-ja ent et de véri�er sa onformité par rapport aux ontraintes temporelles.Ces étapes dé oulent alors sur un système développé et mis au point pour un ontexte matérielet physique donné. Il est alors très di� ile de réutiliser la partie logi ielle de tels systèmes dansun ontexte matériel di�érent [6℄.Partant de e onstat, des initiatives de standardisation ommen ent à apparaître. Par ex-emple, dans le domaine de l'automobile, on peut iter le standard Autosar [7℄ qui, par l'ajoutd'une ou he logi ielle, permet d'homogénéiser l'a ès au matériel bas niveau tels que les unitésde al ul ou le réseau. Très ré emment, la élèbre multinationale améri aine de solutions infor-matiques Mi rosoft s'attaque au manque de �exibilité dans le développement des appli ationsrobotiques au travers de l'initiative Mi rosoft Roboti Studio [85℄. Leur but est alors de réerune haîne omplète de développement fa ilitant le développement de systèmes robotiques.2.1.4 Con lusion du domaine d'étudeLes modèles a tuellement utilisés pour la modélisation d'un système de ontr�le permettentde s'assurer de la orre tion du système. Cependant, a�n de permettre la réutilisation de ertainesparties logi ielles, il est né essaire de raisonner sur la stru ture de es modèles. La stru turationne doit pas remettre pas en question l'utilisation de modèles tels que eux manipulés dans Mat-lab/Simulink ou SCADE ; elle doit apporter de la qualité au sens du génie logi iel (réutilisation, apa ité d'analyses, et ). Elle ne doit également pas remettre en question la validation de essystèmes ainsi que la génération de leur ode.Ainsi, nous nous intéressons dans un premier temps aux te hniques de stru turation deslogi iels dé oulant de ertains prin ipes de génie logi iel. Une fois les on epts de es te hniquesabordés, nous détaillons les appro hes permettant de dé oupler les fon tionnalités d'un logi ieldes servi es d'a ès au matériel sur lequel elles s'exé utent.2.2 Ar hite ture et génie logi ielLe on ept de génie logi iel a émergé il y a maintenant un peu plus de trois dé ennies,lorsque le Comité S ienti�que de l'OTAN a organisé su essivement deux onféren es tenuesrespe tivement à Garmis h-Partenkir hen en o tobre 1968 et à Rome en o tobre 1969 [20, 91℄.10

2.2. Ar hite ture et génie logi ielLes textes des exposés et des omptes rendus de dis ussions �gurant dans les a tes de es deux onféren es sont souvent référen és pour leur étonnante a tualité. Les grands sujets débattus àl'heure a tuelle y sont tous présents, notamment les omposants et la réutilisation du logi iel, lanotion de y le de vie, la mise en pla e de pro essus de validation et de véri� ation, les te hniquesformelles, la onduite de projet ou l'estimation des oûts et des délais.Cette thèse s'interroge sur la manière de développer les systèmes de ontr�le de pro essusa�n de fa iliter la réutilisation d'une même appli ation de ontr�le sur di�érentes plateformesen termes de apteurs et d'a tionneurs. Cette séparation doit permettre de garantir la orre -tion d'une appli ation de ontr�le avant son déploiement sur un support réel. Parmi toutes lesproblématiques adressées par le génie logi iel, la stru turation de logi iel et les analyses que elaautorise semble essentielle à l'atteinte de es obje tifs. Cette problématique, toujours d'a tual-ités, a été étudiée dès la �n des années 60 par Dijkstra. Celui- i expose ertains prin ipes destru turation [38℄ omme l'organisation en ou he hiérar hique et l'abstra tion permettant defa iliter le développement et la validation de systèmes informatiques. En parti ulier, il souligneque ette organisation parti ulière permet de réaliser des tests sans explosion des états. Toutefois, e n'est que dix ans plus tard que la omplexité des systèmes logi iels a fait émerger l'idée de on- eption ar hite turale [36℄. Cette dernière idée distingue la notion de on eption ar hite turale(Programming-in-the-large) de la notion de on eption détaillée (Programming-in-the-small). En-�n, 'est dans les années 90 que la notion d'ar hite ture logi ielle en tant que "perspe tive hautniveau d'un système logi iel" devient une dis ipline à part entière [57℄.2.2.1 Dé�nitionsIl existe à l'heure a tuelle de nombreuses dé�nitions se rapportant au on ept d'ar hite turelogi ielle (software ar hite ture). Cha une des dé�nitions parmi la entaine re ensée 1, est oloréepar le domaine duquel elle dé oule. Nous retenons, dans le adre de ette thèse, deux dé�nitionsnous apparaissant su�samment générales et pertinentes.Dans le standard 1471 [56℄ datant de 2001, l'IEEE dé�nit une ar hite ture logi ielle omme :dé�nition 1 �The fundamental organization of a system embodied in its omponents, their re-lationships to ea h other, and the environment, and the prin iples guiding its design andevolution�Une ar hite ture logi ielle est don dé�nie par l'IEEE omme l'organisation prin ipale d'unsystème à l'aide de omposants, de la manière de onne ter les omposants entre eux ainsi quepar les prin ipes qui en guident la on eption et l'évolution.De son �té, le SEI (Software Engineering Institute) propose dans [53℄ une dé�nition qui seveut être une synthèse de nombreuses dé�nitions antérieures :dé�nition 2 �[...℄ While there are numerous de�nition of software ar hite ture, at the ore ofthem is the notion that the ar hite ture of a system des ribes its gross stru ture. This1http ://www.sei. mu.edu/ar hite ture/de�nitions.html 11

Chapitre 2. État de l'artstru ture illuminates the top level design de isions, in luding things su h as how the systemis omposed of intera ting parts, where are the main pathways of intera tion, and what arethe key properties of the parts. Additionally, an ar hite tural des ription in ludes su� ientinformation to allow high level analysis and riti al appraisal�Cette dé�nition onsidère une ar hite ture omme la des ription de la stru ture d'un système.Cette stru ture est le re�et des dé isions prises lors de la modélisation de haut niveau ; 'est-à-direqu'elle pré ise quelles sont les di�érentes parties d'un système, quelles sont les intera tions entre es parties ainsi que les propriétés essentielles de ha une de es parties. De plus, ette dé�nitionmet l'a ent sur le fait qu'une ar hite ture doit pouvoir permettre d'e�e tuer des analyses sur lesystème, ainsi qu'une évaluation des points ritiques.De manière plus générale, toutes les appro hes onsidèrent une ar hite ture omme une stru -ture �gros grains� d'un système. Cette stru ture permet de dé�nir, à l'aide d'un assemblage de omposants, les dé isions relatives à la on eption d'un système. Elle peut être ra�née et analyséea�n de guider la mise en ÷uvre du système. Ainsi, une ar hite ture logi ielle peut être onsidérée omme un point pivot entre les exigen es des spé i� ations, la on eption et la mise en ÷uvre.Puisque la des ription ar hite turale onditionne les hoix relatifs à la on eption d'un sys-tème, il est essentiel que elle i soit validée pour assurer la ohéren e des hoix par rapport auxobje tifs temporels, é onomiques, ou autres du système.2.2.2 Béné� es attendusDe nombreux béné� es sont attendus du fait de la maîtrise des ar hite tures logi ielles.Puisqu'une ar hite ture re�ète la stru ture �gros grains� d'un système, elle permet à l'ar hite tede se on entrer en premier lieu sur l'organisation du système en di�érents blo s interagissant.Cette préo upation e�a e les sou is te hniques inhérents à ha un des blo s et fait ainsi ap-paraître une dé omposition naturelle du problème en sous problèmes. On assiste ainsi à uneséparation des préo upations importante pour la maîtrise de la omplexité [10, 53℄.Cette séparation des préo upations fournit une première on eption du système où ertainsdétails sont masqués. Elle permet ensuite de se on entrer sur les détails d'un omposant sansavoir à se sou ier des autres omposants. Cela permet de fa iliter la ommuni ation entre lesdi�érents intervenants d'un système en leur fournissant un niveau de détails adapté à leur tâ he[36, 57, 10, 53℄.De plus, la possibilité de ontraindre l'organisation de la stru ture et de ses omposantspermet une mise en ÷uvre de prin ipes de génie logi iel [59℄. L'ensemble de es ontraintes,appelé un style ar hite tural, permet d'obtenir ertaines propriétés de qualité au sens du génielogi iel, omme la réutilisation, la apa ité d'analyse, l'interopérabilité, et . [89℄.En�n, asso iée à des te hniques formelles de al uls, l'utilisation d'une ar hite ture logi iellepermet d'e�e tuer des analyses sur les diverses parties du système et sur leur omposition [54, 53,59℄. Ces analyses �au plus t�t� de ertaines propriétés doivent permettre les premières validationsdu système. En déte tant le non-respe t de ertaines propriétés, il est plus fa ile de revenir sur les12

2.2. Ar hite ture et génie logi iel hoix ar hite turaux défaillants. Ces analyses doivent être faites à plusieurs stades du ra�nementde l'ar hite ture [5, 23℄.On peut résumer les prin ipaux béné� es attendus lors de l'utilisation d'une ar hite turelogi ielle suivant quatre points. L'utilisation d'une ar hite ture doit fournir :� un adre pour maîtriser la omplexité d'un système (niveau d'abstra tion puis ra�ne-ment) ;� un support pour la prise en ompte de prin ipes de génie logi iel (utilisation destyles ar hite turaux) ;� une base de raisonnement à des �ns d'analyse et de validation (à tous les niveauxde ra�nement et d'abstra tion) ;� une do umentation du système fa ilitant sa mise en ÷uvre ainsi que sa ommuni ation.Maintenant que nous avons vu les béné� es attendus d'un raisonnement au niveau ar hite -tural, nous donnons les éléments né essaires à l'établissement d'une ar hite ture.2.2.3 Dé rire une ar hite tureAux vues des études existantes et en se basant sur la synthèse e�e tuée dans [84℄, une ar hi-te ture est ara térisée par les éléments suivants ( f. �gure 2.2) :les omposants qui sont les briques de base d'une ar hite ture ;les interfa es qui sont asso iées à un omposant et permettent d'a éder aux propriétés ou omportement(s) de elui- i ;les onne teurs qui permettent de spé i�er les ommuni ations entre les interfa es ;la on�guration qui est un assemblage de omposants, reliés au travers d'interfa es par des onne teurs ;le style ar hite tural qui est un ensemble de ontraintes sur les on�gurations possibles oua eptables ;l'ADL Ar hite ture Des ription Language qui est un langage permettant la des ription deséléments pré édents.Dans la suite de e hapitre, nous présentons plus pré isément ha un des on epts né essairesà l'établissement d'une ar hite ture logi ielle, en parti ulier dans le domaine de l'embarqué etdu temps réel. Les on epts sont organisés selon la liste pré édente et s'appuient sur un étatde l'art du domaine. Nous dis utons ensuite des possibilités d'analyse et de mise en ÷uvre desar hite tures logi ielles avant de on lure.2.2.3.1 Les omposantsUn omposant est une unité de traitement ou de sto kage de données. Il représente, ave les onne teurs, la brique de base utilisée pour dé rire un système. À un omposant est asso iéun omportement omposé d'un ensemble de servi es (au sens de fon tions ou de méthodes).On distingue dans la majorité des appro hes deux manières de dé rire le omportement d'un omposant : 13

Chapitre 2. État de l'art

Fig. 2.2 � Exemple de représentation graphique d'une ar hite ture logi ielle� les omposants dit primaires possèdent un omportement dé rit dans un langage spé i�que(langage de programmation, langage formel, langage ma hine) ;� les omposants omposites, lorsqu'ils sont pris en harge par l'appro he, possèdent un omportement dé rit à l'aide d'une on�guration ( 'est-à-dire d'un ensemble de omposantsinter onne tés).L'utilisation de omposants omposites permet de réer une hiérar hie de omposants. Un omposant omposite est don d'un niveau d'abstra tion supérieur aux omposants qui le on-stituent.Le omportement d'un omposant primaire peut être spé i�é de di�érentes manières. Lalittérature met en avant trois atégories non ex lusives :1. Spé i� ation du omportement par un (ou plusieurs) exé utable(s) binaire(s) ou sous formede byte ode (osgi [98℄, .Net [87℄, EJB [88℄, EAST-EEA [101℄, PACC [128℄). Dans e ason parle de omposants en boîte noire ar le omportement peut être utilisé mais son odesour e, puisque (pré) ompilé, reste a hé. Le omposant se doit alors d'in lure ha un des odes binaires orrespondant aux ibles pour lequel il a été prévu.2. Spé i� ation du omportement à l'aide d'un (ou plusieurs) ode(s) sour e(s) exprimé(s)dans un langage de programmation � lassique� (koala [124℄, PBO [113℄, rubus [63℄, PECOS[58℄, Think [45℄, MetaH [125℄, EAST-EEA [101℄, VEST [112℄, giotto [61℄, AADL [99℄). Dansle ontexte des systèmes embarqués, le langage C est un hoix ré urrent pour la des riptiondu omportement. Dans e as on parle de omposants en boîte blan he ar le ode sour edu omposant est fourni et visible. Une phase de ompilation est alors né essaire pourpermettre l'exé ution d'un omposant sur une ible donnée.3. Spé i� ation du omportement à l'aide d'un langage formel. Cette appro he permet deréaliser diverses analyses sur le omposant ou sur un assemblage de omposants. On trouvedans la littérature les appro hes basées sur le langage CSP (Wright [2℄) ou sur les auto-mates à états �nis (CLARA [40℄, MetaH [125℄, AADL [99℄, PECOS [58℄, COTRE [43℄,14

2.2. Ar hite ture et génie logi ielC2 [37℄, PACC [128℄). Toujours à des �ns d'analyses, le omportement d'un omposantpeut être abstrait selon divers points de vue. Typiquement, d'un point de vue temporel,un omportement peut être abstrait par son pire (ou son meilleur) temps d'exé ution a�nd'e�e tuer des analyses d'ordonnançabilité (CLARA [40℄, MetaH [125℄, EAST-EEA [101℄,VEST [112℄, giotto [61℄). Cette appro he de des ription du omportement fournit un om-posant en boîte grise ; 'est-à-dire un omposant ne fournissant pas le ode sour e maisles propriétés né essaires à son utilisation orre te ou à l'analyse de son omportementvis-à-vis d'une propriété donnée.Puisque les trois atégories pré édentes ne sont pas ex lusives, beau oup d'appro hes asso- ient di�érentes des riptions possibles d'un omportement. En parti ulier, pour réaliser des anal-yses de on eption, le omportement est dé rit à l'aide d'un ode binaire et/ou d'un ode sour eet est ara térisé par des propriétés abstraites né essaires à l'analyse (MetaH [125℄, EAST-EEA[101℄, VEST [112℄, giotto [61℄, PACC [128℄, koala [124℄, PECOS [58℄) ou né essaire au déploiement(osgi [98℄, .Net [87℄).Con lusion sur les omposants Cha une des manières de dé rire le omportement d'un omposant possède des intérêts di�érents. La solution à retenir dépend don des besoins expriméspar le domaine d'appli ation, soit lassiquement : l'exé ution, le déploiement ou l'analyse.Exé ution :Pour assurer l'installation et/ou le rempla ement de omposants lors de l'exé ution, l'utili-sation de ode binaire permet d'éviter la phase de ompilation. Par ontre, son déploiement estlimité aux ibles sur lesquelles le ode binaire est exé utable. Il faut toutefois remarquer que ertains odes sont exé utables sur plusieurs ibles (le byte ode Java [115℄ par exemple). Il fautégalement remarquer que la des ription d'un omportement sous forme de ode binaire évitede dévoiler le ode sour e d'un omposant. C'est souvent un avantage mis en avant dans lesdomaines où la propriété intelle tuelle est importante.Si l'on souhaite exé uter un système sur des ibles hétérogènes et don limiter les hypothèses on ernant les futures ibles d'exé ution du système, un langage de programmation lassiqueest préférable. Par ontre, une phase de ompilation doit être réalisée a�n de pouvoir utiliser le omposant. L'installation ou le rempla ement de omposants pendant l'exé ution est alors plusdi� ile.Déploiement :Le déploiement orre t d'un omposant né essite plusieurs informations supplémentaires. Celles- i peuvent être générales, omme le nom de l'auteur ou le numéro de version ; être utiles àl'installation, omme l'arbores en e des � hiers ou en ore les librairies requises. Elles peuventégalement être omposées des besoins extra-fon tionnels né essaires au déploiement, omme lebesoin de persistan e ou de sé urité, par exemple. 15

Chapitre 2. État de l'artAnalyse :Les deux premiers points se fo alisent sur la problématique d'exé ution d'un omposant. Cepen-dant, si l'on désire e�e tuer des analyses pour s'assurer de la orre tion d'un omposant primaireou omposite, les deux te hniques pré édentes ne sont pas adaptées. Il est alors né essaire defournir les renseignements sur le omportement de omposants a�n de permettre d'e�e tuer desanalyses. Ces renseignements sont utilisés soit sur un omposant, soit sur un assemblage de omposants, soit lors de la onnexion d'un omposant à un autre omposant ( hargements àl'exé ution), soit lors de son déploiement ou en ore lors de son exé ution ( ontr�les). Un despoints importants et non trivial est bien sûr de s'assurer que le omportement ainsi dé rit demanière abstraite re�ète l'exé ution du omposant.L'énon é des propriétés, aboutissant à un omportement en boîte grise, peuvent être diverseset variées selon le ontexte. On trouve, par exemple, les propriétés temporelles, les types de iblespour lesquelles le omposant est prévu, le nom de l'algorithme implémenté, le numéro de version,le y le de vie, et . Il faut noter que la plupart de es propriétés sont liées au omportement du omposant à l'exé ution. À l'image de la pire ou de la meilleure durée d'exé ution (respe tivement�Worst/Best Case Exe ution Time� ou WCET/BCET), les propriétés peuvent être une ontrainteportant sur l'implémentation du omposant auquel as on parle de budgets temporels (CLARA[40℄, EAST-EEA [101℄) ou le résultat de l'analyse de son exé ution (MetaH [125℄, VEST [112℄).Nous avons vu les di�érentes façons de dé rire le omportement d'un omposant. Nous allonsmaintenant voir les di�érentes te hniques utilisées pour a éder à e omportement.2.2.3.2 Les interfa esUne interfa e est un point d'intera tion d'un omposant ave son environnement. Dans laplupart des appro hes, es points d'intera tions sont orientés. On trouve des interfa es en entréeou en sortie (PBO [113℄, rubus [63℄, giotto [61℄) ou des interfa es fournies ou requises (EAST-EEA [101℄, koala [124℄, Think [45℄, UML2.0 [97℄). Classiquement les interfa es en entrée ou ensortie sont utilisées lorsque la ommuni ation est de type �ot de données ou événementielle alorsque les interfa es fournies ou requises servent aux ommuni ations de type lient/serveur.Les interfa es peuvent être lassées suivant le type d'intera tion qu'elles implémentent. Ense basant sur les appro hes existantes, on dis erne trois prin ipaux types d'interfa es :1. Les interfa es fon tionnelles qui permettent d'a éder à un servi e parti ulier d'un om-posant ;2. les interfa es de on�guration qui permettent d'ajuster ertains paramètres relatifs au om-portement d'un omposant ( hoix de l'algorithme, et .) ;3. les interfa es de syn hronisation qui permettent de dé len her ou de suspendre l'exé utiond'un omposant.Puisque les interfa es sont les seuls points de ommuni ation d'un omposant ave son envi-ronnement, elles représentent la spé i� ation du omposant. Cette spé i� ation doit idéalement16

2.2. Ar hite ture et génie logi ielpermettre d'utiliser le omposant en boîte noire. A�n d'atteindre et obje tif, [16℄ propose dedé rire les spé i� ations d'une interfa e selon quatre niveaux de ontrats distin ts :Contrat de niveau 1 il spé i�e la signature des servi es o�erts ou requis par un omposant.Ce niveau de ontrat peut être établi en mettant en orrespondan e un ou plusieurs hampstextuel(s) dé rivant la signature d'un servi e.Contrat de niveau 2 il spé i�e les ontraintes sur l'utilisation d'un servi e. Ces ontraintessont essentiellement réalisées à l'aide d'assertions booléennes (pré et post onditions, in-variants). Ces ontraintes peuvent être dé rites en OCL [96℄ mais également être spé i�ées àl'aide d'un algèbre de pro essus [2℄ ou de manière plus omplexe à l'aide d'un méta-modèledu r�le exer é par le servi e spé i�é [69℄.Contrat de niveau 3 il spé i�e le proto ole de syn hronisation entre les appels aux di�érentsservi es omposant le omportement d'un omposant. Cette syn hronisation peut être ex-primée par des hamps textuels omme une séquen e ou �aléatoire� ou de manière plus omplexe par des automates spé i�ques de type �proto ol state hart� [75℄.Contrat de niveau 4 il spé i�e les ara téristiques extra-fon tionnelles que l'ondésire observer sur le servi e asso ié. Il exprime le niveau de QoS (Quality of Servi e) requisou o�ert pour/par une interfa e omme dans [123, 65℄. À e titre le ontrat de niveau 4 estaussi appelé ontrat de QoS. Globalement, dans le domaine de l'embarqué, rares sont lesappro hes qui intègrent e niveau de ontrat.Con lusion sur les interfa es Les interfa es sont les seuls points de ommuni ation entreun omposant et son environnement. Elles permettent de spé i�er omment interagir ave un omposant, tant au niveau fon tionnel qu'extra-fon tionnel.Si un omposant doit être utilisé par un tiers dans un environnement a priori non onnu,alors la des ription de l'interfa e devra être assez pré ise pour éviter une mauvaise utilisation du omposant. Ce dernier peut alors être vu omme une entité de réutilisation auto- ohérente (self onsistent), utilisable en boîte noire ( f. dé�nition d'un omposant par Szyperski [117℄).A ontrario, si l'utilisation d'un omposant est on�née à un type de on�guration onnue et apriori �xe, la des ription d'une interfa e peut être réduite. La réutilisation du omposant né essitealors une onnaissan e minimale de son omportement. A�n d'assurer un fon tionnement orre t,l'utilisation (ou � omposabilité�) du omposant est d'une part liée à une utilisation orre te deson interfa e et d'autre part à l'analyse de son assemblage au sein de la on�guration.De nombreuses appro hes permettent de véri�er la onformité sémantique et syntaxique ( on-trats de niveau 1 et 2) des interfa es lors de leur onnexion. Quelques appro hes s'intéressentaux ontrats de niveau 3. Cependant, les ontrats de QoS (de niveau 4) sont souvent mis de �té.Lorsqu'ils sont adressés, les appro hes proposent généralement un langage permettant la des rip-tion de ontrat de QoS et/ou propose une ar hite ture permettant la négo iation de ontrat àl'exé ution. La sémantique de satisfa tion permettant l`établissement des ontrats de niveau QoSest alors simplement basée sur un opérateur de omparaison de quantité de ressour e utilisée.Ces préo upations sont pourtant né essaires à l'établissement d'une ar hite ture possédant des ontrats de QoS. 17

Chapitre 2. État de l'artNous venons de présenter le r�le d'une interfa e ainsi que la notion de ontrat, nous présentonsmaintenant la manière dont es interfa es peuvent être inter onne tées.2.2.3.3 Les onne teursUn onne teur est en harge des intera tions entre les omposants d'une ar hite ture. Ilspé i�e les règles qui régissent la relation entre deux ou plusieurs omposants via leurs interfa es.Il réalise don l'établissement de ha un des ontrats dé rits dans le paragraphe 2.2.3.2.Certaines appro hes onsidèrent les onne teurs omme de simples liens logiques (MetaH[125℄, giotto [61℄, PECOS [58℄, PBO [113℄, rubus [63℄, koala [124℄). Ces appro hes permettentalors de n'établir des ontrats qu'entre des interfa es homogènes.Dans d'autres appro hes, le onne teur peut posséder un omportement appelé �glue� (Wright[2℄, uni on [108℄, Think [45℄, VEST [112℄, BIP [11℄). Il a pour obje tif l'adaptation des interfa esa�n de permettre l'établissement de ontrats entre des interfa es hétérogènes.Un onne teur spé i�e également le type de ommuni ation entre omposants. Par exemple,un onne teur peut spé i�er si les é hanges de données se font par tunnels (pipe) ou par mémoirepartagée (PECOS [58℄, PBO [113℄, rubus [63℄). D'autres propositions permettent de les utiliserpour spé i�er le type de syn hronisation lors de la mise à jour d'une donnée (rendez-vous, se tion ritique, et .) (CLARA [40℄, Wright [2℄, BIP [11℄).Lorsque le onne teur possède un omportement, la �glue� peut soit être dé rite de la mêmemanière que le omportement d'un omposant (primaire ou omposite) omme dans Wright [2℄,uni on [108℄, Think [45℄, VEST [112℄, Wright [2℄, soit de manière spé i�que omme dans BIP [11℄ou [21℄. La �glue� peut également être hoisie parmi une liste �nie de omportements (CLARA[40℄).La des ription de la �glue� peut être plus ou moins éloignée des détails de son implémentation.En parti ulier, [21℄ propose l'utilisation de modèles (diagramme de ollaboration, ontraintesOCL, et ) pour dé rire la �glue� d'un onne teur. Cette des ription est ensuite ra�née et peutaboutir à di�érentes implémentations selon les ritères hoisis (performan es, sé urité, et ).Con lusion sur les onne teurs Les utilisations des onne teurs énon és pré édemment nesont que des exemples. Les onne teurs sont très hétérogènes suivant les appro hes. On trouveainsi di�érents types de onne teurs allant du onne teur logique (assimilable à un �l) jusqu'au onne teur omplexe dé rit par une on�guration (un assemblage de omposants).La omplexité d'un onne teur est en ore une fois liée au domaine d'appli ation. Les on-ne teurs simples sont, de préféren e, réservés aux systèmes ayant des besoins d'installations et/oude rempla ements de omposants pendant l'exé ution. Ils peuvent également être utilisés pour�ger la sémantique de ommuni ation entre les omposants, fa ilitant, de fait, la réalisation d'-analyse. Cependant, les onne teurs logiques ne peuvent être utilisés que lorsque les omposants18

2.2. Ar hite ture et génie logi ielde la on�guration forment un ensemble homogène sur les quatre niveaux de ontrat des inter-fa es.A ontrario, les onne teurs omplexes sont utilisés dans les systèmes où les besoins de spé i�- ation en termes de ommuni ation/syn hronisation sont plus forts. En parti ulier, ils permettentde faire ommuniquer des omposants hétérogènes en termes de signature ( ontrat de niveau 1),de omportement ( ontrat de niveau 2) et de proto ole de syn hronisation ( ontrat de niveau 3).À notre onnaissan e, au une appro he ne propose de onne teurs permettant l'établissementde ontrats de QoS lors de la omposition d'interfa es.Grâ e aux onne teurs, nous avons vu omment relier les interfa es des omposants. Lerésultat d'un assemblage est appelé on�guration. La se tion suivante introduit ette notion.2.2.3.4 La on�guration et son niveau de des riptionUne on�guration est un graphe bipartite de omposants et de onne teurs. C'est le résultatd'une des ription ar hite turale pour un système donné. À e titre, une on�guration est aussi ommunément appelée �ar hite ture� dans la littérature.Plusieurs types de on�guration existent suivant la pla e qu'elle o upe dans le y le de viedu système. La littérature identi�e prin ipalement trois lasses de on�guration dont les nomspeuvent varier. Nous prenons dans ette thèse la terminologie suivante :Con�guration ou ar hite ture logique : C'est une vue ar hite turale des aspe ts fon tion-nels d'un système sans prise en ompte de la plateforme de déploiement. Le niveau d'ab-stra tion de ette on�guration peut aller d'une des ription des relations entre les di�érentesentités omposant le système jusqu'à la spé i� ation du omportement, voire la mise en÷uvre des algorithmes utilisés. Les aspe ts extra-fon tionnels d'un système sont souventliés au matériel sur lequel le système s'exé ute. Il est don di� ile de les in orporer àla des ription d'une ar hite ture logique. Toutefois, pour les aspe ts temporels, CLARA[40℄ et EAST-EEA [101℄ proposent l'utilisation de budget temporel. Un budget temporelest l'estimation d'un temps (WCET, temps de blo age, et .) servant de ontrainte lors dura�nement de l'ar hite ture logique ou lors de son déploiement.Con�guration ou ar hite ture te hnique/support : C'est une vue ar hite turale de la pla-teforme de déploiement. Cette spé i� ation peut être réalisée à des niveaux di�érents. Ellepeut être une des ription du matériel sur lequel s'exé ute le logi iel (pro esseurs, bus, mé-moire, et .) aussi bien qu'une des ription des servi es o�erts par le système d'exploitationde la plateforme (servi e d'a ès aux tâ hes, aux media de ommuni ation, et .). À eniveau, ertaines informations extra-fon tionnelles sur la plateforme telles que la vitesse dupro esseur ou la taille de la mémoire peuvent être renseignées (VEST [112℄, EAST-EEA[101℄).Con�guration ou ar hite ture opérationnelle : C'est une vue ar hite turale résultantdu déploiement de l'ar hite ture logique sur l'ar hite ture te hnique. Elle dé rit don le19

Chapitre 2. État de l'artsystème omplet, ave les tâ hes, les proto oles de ommuni ation, la politique d'ordon-nan ement, et . Il est alors possible de donner une des ription réelle des aspe ts extra-fon tionnels du système. En parti ulier, les informations sur le omportement temporel, omme par exemple le temps de réponse, sont des valeurs mesurées une fois le déploiementréalisé.Con lusion sur les on�gurations Pour les systèmes embarqués temps réel, la majoritédes ADLs se on entrent sur la des ription d'une on�guration opérationnelle ou onfondentla on�guration logique et la on�guration opérationnelle (MetaH [125℄, giotto [61℄, COTRE[15℄, PECOS [58℄, PACC [128℄, PBO [113℄, rubus [63℄, AADL [99℄). Cette vue ar hite turalepermet alors de s'assurer du respe t des ontraintes fon tionnelles et extra-fon tionnelles. Pourles systèmes visés, travailler sur la on�guration opérationnelle permet de réaliser, entre autres,les analyses lassiques du domaine visé omme l'analyse d'ordonnan ement temps réel (MetaH[125℄, giotto [61℄, COTRE [43℄, rubus [63℄), l'évaluation des temps de réponse (MetaH [125℄,COTRE [43℄) ou le al ul de l'empreinte mémoire (Koala [124℄).On trouve ependant quelques appro hes qui identi�ent lairement la on�guration logique(CLARA [40℄, EAST-EEA [101℄, VEST [112℄, koala [124℄). Cette vue ar hite turale permet laréalisation de premières analyses destinées à valider une on�guration logique andidate et ainsis'assurer de la ohéren e de ses des riptions extra-fon tionnelles. Une fois la des ription de l'ar- hite ture te hnique réalisée, des analyses doivent permettre de s'assurer que les résultats obtenuslors des analyses de la on�guration logique sont préservés lors du déploiement (CLARA REACT[46℄, EAST-EEA [101℄).Il semble intéressant de séparer la on�guration logique de la on�guration opérationnellea�n de séparer les préo upations au niveau fon tionnel mais également extra-fon tionnel. Ene�et, les analyses réalisées sur une on�guration logique permettent de déte ter les in ohéren esextra-fon tionnelles pouvant exister et assurer une dérivation orre te des ontraintes extra fon -tionnelles. On sépare ainsi la faisabilité d'une des ription ar hite turale de sa réalisation sur une on�guration te hnique parti ulière.Cha un des niveaux de on�guration spé i�e di�érents points de vue sur la stru turation dusystème. L'étude des ar hite tures logi ielles montre que ertaines stru turations sont ré urrenteset utilisées pour résoudre une lasse spé i�que de problèmes.2.2.3.5 Le style ar hite turalLes ontraintes permettant d'obtenir es stru turations parti ulières ont été identi�ées et lassées omme �styles ar hite turaux� (ar hite tural style). Parmi les dé�nitions existantes au-tour de ette notion, nous onsidérons elle- i :�An ar hite tural style is a oordinated set of ar hite tural onstraints that restri ts the role /features of ar hite tural elements and the allowed relationships among those element within anyar hite ture that onforms to that style� [49℄.20

2.2. Ar hite ture et génie logi ielCette dé�nition datant de 2000 signi�e qu'un style ar hite tural est un ensemble de ontrain-tes permettant de limiter le r�le, le omportement ainsi que la manière d'assembler les éléments( omposants et onne teurs) des on�gurations appliquant e style. D'après [55℄, les ontraintesdé�nies par un style ar hite tural permettent de :� dé�nir un vo abulaire �ni de type de omposants et de onne teurs ;� dé�nir des ontraintes sur les asso iations entre es entités ;� dé�nir une interprétation sémantique pour ha un des éléments utilisés dans la réalisationd'une on�guration ;� dé�nir les analyses pouvant être réalisées sur les on�gurations appliquant e style.Classiquement, on identi�e en génie logi iel les styles ar hite turaux suivant : �Pipe and�lter �, �Bla kboard�, �Obje t-oriented� and �Layered systems� [109℄. Il en existe bien sûr d'autreset ha un de es styles possède des variantes. De plus ertains styles sont le résultat d'un mélangede plusieurs styles.L'utilisation ou la dé�nition d'un style ar hite tural, en parti ulier l'énon iation de ontrain-tes, est souvent motivée par l'appli ation d'un prin ipe de génie logi iel [59℄. En e�et, [70, 71℄mettent en avant le fait que es di�érentes ontraintes entraînent un ensemble de propriétés dequalité, au sens du génie logi iel, sur la on�guration qui les applique.On distingue prin ipalement deux types de propriétés extra-fon tionnelles : les propriétés hi�rables et les propriétés non hi�rables. Les propriétés non hi�rables sont par exemple :l'e� a ité, la fa ilité d'évolution et de réutilisation. Elles sont souvent désignées par le terme�attributs de qualité� (quality attribute) [10℄. De nombreuses études, parmi lesquelles [121, 68, 67℄,se fo alisent sur leur évaluation.Selon les propriétés extra-fon tionnelles re her hées, un style ar hite tural est plus ou moinse� a e. Le tableau suivant, en partie extrait de [31℄ donne un aperçu du omportement de haquestyle vis-à-vis de inq propriétés extra-fon tionnelles non hi�rables. Il est possible de modérerar hite tural style Performan e Maintainability Reliability Safety Se urityPipes & �lters +- +- - - +Bla kboard - + +- - +-Obje t-Oriented +- +- +- + +-Layered - + +- ? ? ? ?+- : non pertinent, + : e�et positif, - : e�et négatif, ? ? : non déterminé.Tab. 2.1 � Comparaison des styles ar hite turaux lassiques vis-à-vis de propriétés extra-fon tionnelles non hi�rables.l'impa t d'un style sur un attribut de qualité en réalisant une variante d'un style parti ulier ouen utilisant un style hétérogène. Un style hétérogène possède les propriétés de ha un des stylesqu'il emploie. Les styles employés peuvent être ombinés de plusieurs manières. On peut, parexemple, les ombiner de manière hiérar hique. Ainsi une ar hite ture en ou he (Layered) peut,à l'intérieur de ha une des ou hes utiliser un style Pipe and �lter. Chaque omposant du stylePipe and �lter peut être dé rit grâ e à un style Objet oriented [109℄.Pour leur part, les propriétés extra-fon tionnelles hi�rables peuvent être liées aux aspe tstemporels et de performan e. Certains styles ar hite turaux, en imposant un langage formel et21

Chapitre 2. État de l'artune stru ture parti ulière fa ilite l'évaluation de es propriétés [55℄. Un style ar hite tural adaptédoit don dé�nir des types de omposants et de onne teurs dont le omportement permet l'anal-yse de la propriété re her hée. Il peut également dé�nir ertaines ontraintes sur les assemblagesde omposants et de onne teurs a�n d'assurer que la on�guration est analysable vis-à-vis dela propriété re her hée. Par exemple, dans l'embarqué, pour assurer la possibilité de faire uneanalyse du temps de réponse, un style ar hite tural adéquat doit imposer la spé i� ation deséléments né essaires à ette analyse (par exemple, des tâ hes périodique pour faire une analyseRMA [72℄). Il faut don noter qu'un style ar hite tural impose la spé i� ation des éléments né es-saires pour e�e tuer une analyse mais ne peut ni spé i�er la manière de réaliser ette analyse, niassurer du résultat de l'analyse.Con lusion sur le style ar hite tural La littérature portant sur les ar hite tures logi iellesa mis en avant l'importan e du style ar hite tural puisque son appli ation permet non seulementd'imposer ertains prin ipes de génie logi iel, mais aussi d'imposer une stru ture analysable.Pour autant, omme le souligne [49℄, il n'existe pas de style ar hite tural �mira le� (�silver-bullet�). Chaque style possède ses avantages et ses in onvénients. C'est alors à l'ar hite te defaire ou d'appliquer le style favorable à son problème.Il faut faire une di�éren e fran he entre l'évaluation de propriétés extra-fon tionnelles liéesà un style ar hite tural et la propension qu'apporte un style ar hite tural à l'évaluation depropriétés extra-fon tionnelles.D'un �té l'appli ation d'un style ar hite tural peut fournir des propriétés extra-fon tionnel-les non hi�rables. On peut par exemple dire qu'un style ar hite tural � X � permet d'obtenirune bonne réutilisabilité sur les on�gurations qui l'appliquent.D'un autre �té on ne peut pas assurer des propriétés extra-fon tionnelles hi�rables ; 'est-à-dire qu'il n'est pas possible de dire que le style ar hite tural � X � permet d'obtenir un tempsde réponse de � a �. En revan he, on peut dire que la propriété est évaluable.En�n, il est intéressant de remarquer que les styles ar hite turaux, puisqu'ils spé i�ent des onditions d'utilisation sur des éléments du langage de des ription ( omposants, onne teurs,et .) sont intimement liés à e langage. Tout langage impose don de manière impli ite un stylear hite tural. De la même manière, un modèle à omposant, ave des ontraintes de ompositionfortes, peut dé�nir impli itement un style ar hite tural [32, 127℄.Une fois les types de omposants, de onne teurs et les ontraintes sur leurs assemblagesidenti�és, il est né essaire de les exprimer dans un langage parti ulier.2.2.3.6 Le langageIl existe de nombreux langages permettant de dé rire une on�guration. On trouve notam-ment deux grandes familles de langages : les langages de des ription d'ar hite ture (ADLs)(MetaH [125℄, giotto [61℄, COTRE [15℄ , AADL [99℄, CLARA [40℄, EAST-EEA [101℄, VEST22

2.2. Ar hite ture et génie logi iel[112℄, uni on [108℄, Wright [2℄) et les modèles à omposants (notés CMs pour Component Model)(PECOS [58℄, PACC [128℄, PBO [113℄, rubus [63℄, koala [124℄, Think [45℄, osgi [98℄ , .Net [87℄,EJB [88℄).La multipli ation des langages provenant de es deux familles a introduit de nombreux formal-ismes et notations (textuelles, graphiques ou mixtes). Aujourd'hui, du fait d'UML, les langagesont tendan e à s'uni�er. En parti ulier, UML2 [97℄ permet de prendre en harge la des ription de omposants, d'interfa es et de onne teurs, soit les éléments né essaires pour dé rire des ar hi-te tures. De plus, UML2 permet de modéliser le système sous développement à plusieurs niveaux.Par exemple, les omposants UML2 possèdent une vue boîte noire de par la spé i� ation d'in-terfa es requises et fournies mais également une vue boîte blan he qui est, quant à elle, a hée àl'utilisateur du omposant. Cette vue s'appuie sur un ensemble de realizations implémentant le omportement du omposant. Une fois une on�guration spé i�ée, UML2 permet également despé i�er la phase de déploiement. Durant ette phase, un omposant UML2 est représenté parun ou plusieurs artifa ts. Un artifa t UML2 permet de modéliser e que l'on veut produire àpartir d'un modèle, de manière indépendante des modèles. Ainsi, un même modèle peut produire ertains artifa ts pour les tests lo aux, d'autres pour l'intégration, et d'autres pour un portagesur d'autres environnements. .Puisque les entités dé rites dans UML2 sont génériques, des points de variations sémantiquessont introduits [106℄. Pour pallier à es �trous� sémantiques, ertains langages de des riptiond'ar hite ture omme AADL [99℄ proposent une spé ialisation des entités d'UML2 pour dé�nirleur langage. Ainsi AADL ajoute des entités spé i�ques à elles dé rites dans UML2. AADL sefo alise alors sur la des ription d'entités de bas niveau fortement liées à l'implémentation. Undes points intéressant d'AADL réside dans le fait qu'il est l'un des premiers langages à permettrel'ajout de QoS dans la spé i� ation des interfa es d'un omposant.En�n, il faut noter qu'un style ar hite tural peut être dé�ni par la formulation d'un langagespé i�que (DSSA : Domain-Spe i� Software Ar hite ture) ou par la spé ialisation d'un langageexistant. Aesop [55℄ est un langage de des ription d'ar hite ture spé i�que permettant la dé�ni-tion d'un style ar hite tural. De sont �té, UML permet l'expression d'un style ar hite tural autravers de deux mé anismes :� il permet d'être étendu pour la réation de types de omposants parti uliers (notion despé ialisation, pro�ls, et .) ;� il peut être ontraint de di�érentes manières omme par l'utilisation de OCL (Obje t Con-straint Language) [96℄ ou par la dé�nition d'un méta-modèle [51℄.Dé�nir un langage spé i�que, et don un style ar hite tural, à l'aide d'un méta-modèle permetde dé�nir l'ensemble des on epts utilisés. Ces on epts peuvent alors être utilisés pour dé�nir unenvironnement de modélisation asso ié aux on epts du style ar hite tural. Ce sont les prin ipesutilisés par les outils EMF [19℄, MetaEdit+ [122℄, GME [62℄ et très ré emment dans TopCased[44℄. Ceux- i permettent d'obtenir rapidement un environnement de développement à partir dela des ription des on epts utilisés.2.2.3.6.1 Con lusion sur le langage De très nombreux formalismes et notations ont vule jour es vingt dernières années. Cela entraîne une di� ulté de ompréhension des notations,grammaires et des avantages/in onvénients liés à ha un des langages. On distingue deux grandes23

Chapitre 2. État de l'artfamilles parmi es langages : les ADLs et les CMs. Les ADLs, sont historiquement des langagesqui permettent de spé i�er une abstra tion du omportement désiré d'une on�guration pendantl'exé ution. Contrairement à ela, les CMs dé rivent des langages qui permettent d'en apsulerproprement le ode d'un omposant a�n de pouvoir les développer indépendamment les un desautres.Au niveau des formalismes, on voit de plus en plus d'ADL basés sur UML (AADL [99℄,EAST-EEA [101℄, VEST [112℄) ; UML ayant l'avantage de fournir une notation de plus en plusuniverselle et des outils existants. Cependant, au-delà des notations, l'essentiel des e�orts portentaujourd'hui sur les on epts manipulés. Dans e ontexte l'ingénierie dirigée par les modèleso�re des outils de manipulation des on epts au travers de l'utilisation de méta-modèles et detransformations de modèles.De manière plus générale, l'ingénierie dirigée par les modèles o�re un adre méthodologique ette hnologique qui permet d'uni�er di�érentes façons de faire dans un pro essus homogène. Il estainsi possible d'utiliser la te hnologie la mieux adaptée à ha une des étapes du développement,tout en ayant un pro essus global de développement qui est uni�é dans un paradigme unique[66℄. Ainsi, il nous parait lair que l'utilisation de modèles pour la des ription d'une ar hite tureest, aujourd'hui, l'appro he la plus appropriée.Il faut être ons ient que l'utilisation d'un langage parti ulier impose souvent l'utilisationdu style ar hite tural sous ja ent. Le style est alors utilisé de manière impli ite. Seuls ertainslangages omme C2 [83℄ fournissent expli itement le style ar hite tural qu'ils utilisent.Pour assurer la orre tion des on�gurations dé rites, le langage utilisé se doit de posséderune sémantique opérationnelle formelle et adaptée. Le langage utilisé doit don fournir unesémantique opérationnelle en adéquation ave les analyses à réaliser. Ces analyses sont le sujetdu paragraphe suivant.2.2.4 Analyse d'une on�gurationLes analyses basées sur les ar hite tures logi ielles permettent de s'assurer de la orre tiond'une on�guration vis-à-vis d'une propriété donnée.Certaines on�gurations, pouvant être modi�ées dynamiquement lors de l'exé ution, per-mettent de véri�er des propriétés pendant l'exé ution du système (Qinna [123℄, osgi [98℄, .Net[87℄, EJB [88℄). Ces on�gurations ont alors besoin de pouvoir identi�er les omposants pendantl'exé ution du système. À l'inverse, les systèmes visés par l'étude ont des besoins de validation apriori, e hapitre se on entre don sur les analyses réalisées lors du développement du système.Comme pré isé dans le hapitre 2.2.3.5, il existe deux grandes atégories de propriétés véri-�ables. La première on erne les propriétés qualitatives (non hi�rables) omme le niveau deréutilisabilité de l'ar hite ture ou sa fa ilité de maintenan e. Les études de es propriétés, parmilesquelles [121, 68, 67℄, sont basées sur des te hniques non formelles et non automatisables ( f.analyse de [126℄).24

2.2. Ar hite ture et génie logi ielLa deuxième atégorie on erne les propriétés quantitatives ( hi�rables) omme les propriétéstemporelles, de performan es, et . Ces propriétés sont essentielles à la validation des systèmestemps réel.Les travaux dé rits dans [30℄ proposent une lassi� ation des propriétés extra-fon tionnellesliées aux omposants et à leur on�guration. Cette lassi� ation fait émerger deux lasses depropriétés lairement di�éren iables :Les propriétés dire tement omposables (dire tly omposables properties) : e terme dési-gne les propriétés d'une on�guration qui sont fon tion d'un et un seul type de propriétésde haque omposant appartenant à la on�guration. La propriété de l'assemblage est alorsdu même type que la propriété de haque omposant.Les propriétés dérivées (derived properties) : également appelées propriétés émergentes ; eterme désigne les propriétés d'une on�guration qui dépendent de plusieurs propriétés des omposants appartenant à la on�guration. Ces propriétés peuvent ou non être réi�ées auniveau du omposant.Parmi les propriétés dérivées dans le domaine des systèmes temps réel, on trouve notammentles analyses des propriétés temporelles suivantes :viva ité : quelque hose de bien arrivera un jour, COTRE [43℄, CLARA [46℄, EAST-EEA [101℄,MetaH [125℄ ;sûreté : quelque hose de mauvais n'arrive jamais, MetaH [125℄, COTRE [43℄ ;respe t des é héan es : le temps é oulé entre deux événements dans le système est inférieurou égal à un temps donné, COTRE [43℄, CLARA [46℄, EAST-EEA [101℄, MetaH [125℄.Ces analyses, ainsi que elles réalisées dans [78, 126℄, se basent sur une des ription formelleet abstraite du omportement d'un omposant à l'aide d'automates temporisés (MetaH [125℄,COTRE [43℄, CLARA [40℄). L'évaluation est alors réalisée par des outils basés sur les te hniquesformelles tels que UPPAAL [76℄, Kronos [130℄ ou CADP [47℄.On trouve également, parmi les propriétés dérivées, les analyses d'ordonnançabilité (MetaH[125℄, giotto [61℄, PACC [128℄, COTRE [43℄, rubus [63℄, VEST [112℄, Uni on [108℄). Ces analysesné essitent la onnaissan e du WCET de haque omposant, leur période d'a tivation, le modèlede tâ hes sous-ja ent, la politique d'ordonnan ement ainsi que les di�érentes syn hronisationsentre les omposants.Sous ertaines onditions, il est possible d'analyser ertaines propriétés dérivées sur des sousparties d'une on�guration. Par exemple, l'analyse d'ordonnançabilité d'un système distribué surplusieurs unités de al uls peut être analysée unité par unité pour haque on�guration partielleregroupant les omposants et les onne teurs s'exé utant sur l'unité de al ul onsidérée.On trouve également dans la littérature la véri� ation de propriétés dire tement omposables omme l'empreinte mémoire réalisée par Koala [124℄. Ces propriétés peuvent être véri�ées lorsde haque onnexion d'un omposant ave le système. Ces analyses peuvent être réalisées au furet à mesure de la onstru tion d'une on�guration et servent ainsi d'aide à la onstru tion dusystème.On trouve en�n des appro hes pour la véri� ation de la onformité à un style ar hite turalparti ulier. Ces analyses permettent de dé eler rapidement les erreurs stru turelles pouvant avoir25

Chapitre 2. État de l'artun impa t sur la on�guration globale (utilisation d'un type de omposant non analysable, et .).Les ontraintes sont alors exprimées à l'aide d'un langage de ontraintes tel que OCL [96℄, d'unméta-modèle [51℄ ou d'un artefa t spé i�que à l'ADL omme dans [55, 2℄.Con lusion sur les analysesPuisque les analyses de propriétés qualitatives ne donnent pas de résultats hi�rables, ellespeuvent uniquement servir de base de omparaison entre di�érentes on�gurations andidates.Elles sont indépendantes d'un ADL parti ulier et permettent de omparer des on�gurationsdé rites à l'aide de divers ADLs. Ces méthodes d'analyses sont étroitement liées à l'analysedes impa ts d'un style ar hite tural parti ulier [70℄. Elles ne donnent pas d'informations surl'exa titude de la on�guration réalisée mais sur des propriétés de qualité au sens du génielogi iel (maintenabilité, réutilisabilité, et .).Parmi les analyses quantitatives omme elles des propriétés temporelles on peut di�éren ierdeux grandes familles : les propriétés dire tement omposables et les propriétés dérivées (ou émer-gentes). Les informations permettant d'évaluer ha une de es propriétés peuvent être en apsuléesdans des interfa es. L'établissement d'un ontrat de QoS lors de la onnexion de deux interfa esest possible uniquement pour des propriétés dire tement omposables. Les propriétés émergentesne peuvent pas dire tement donner lieu à l'établissement d'un ontrat de QoS puisqu'elles né es-sitent l'analyse d'un assemblage de omposants. Cependant, une fois la on�guration analysée,le résultat de l'analyse peut être utilisé pour établir le ontrat.En�n, pour pouvoir faire des analyses de propriétés extra-fon tionnelles et hi�rables, unesémantique opérationnelle doit être fournie pour ha un des éléments ar hite turaux mais aussipour ha une des propriétés impliquées dans l'analyse. Dans le domaine des systèmes temps réel,les automates temporisés et les outils asso iés sont souvent utilisés pour abstraire le omporte-ment et fournir une sémantique opérationnelle temporisée.2.2.5 Mise en ÷uvre d'une ar hite ture logi ielleUne fois la on�guration d'un système réalisée et validée, la phase �nale est sa mise en ÷uvre.On distingue prin ipalement deux stratégies :1. La proje tion du ode exé utable de haque omposant et de haque onne teur dire tementsur une infrastru ture permettant son exé ution ( f. �gure 2.3) ;2. La ompilation de la on�guration vers un ode exé utable et monolithique de la on�gu-ration entière ( f. �gure 2.4).Dans le premier as, l'exé ution devra être gérée par un intergi iel spé i�que permettantl'installation et l'exé ution du ode exé utable de haque entité ar hite turale. Les omposantsrestent alors identi�ables à l'exé ution. Dans e as, on trouve deux appro hes pour gérer la ommuni ation entre les omposants. Si les onne teurs ne sont qu'une vue logique ( f. 2.2.3.3)ou qu'ils ne peuvent être hoisis que parmi une librairie de onne teurs prédé�nis, la ommuni- ation entre les omposants est réalisée par l'intergi iel ( f. �gure 2.3 B). Lorsqu'au ontraire les onne teurs sont des entités pouvant être dé rites de manière plus omplexe, le ode exé utable26

2.2. Ar hite ture et génie logi ielde la �glue� du onne teur est exé uté par l'intergi iel, omme pour un omposant ( f. �gure 2.3A).

Fig. 2.3 � Deux mises en ÷uvre d'une on�guration basée sur un intergi ielDans la deuxième appro he, la on�guration est ompilée dans un langage intermédiaire ompilable/exé utable sur la ible de déploiement ( on�guration te hnique). Les omposants nesont plus réi�ables ; le dé oupage en omposants de la vue ar hite turale a disparu à l'exé ution.

Fig. 2.4 � l'implémentation d'une ar hite ture logi ielle ompiléeCon lusion sur la mise en ÷uvre d'une on�gurationEn règle générale, le hoix d'une de es stratégies est lié à la stratégie hoisie lors de la de-s ription du omportement des omposants. Si le omportement est dé rit sous forme binaire oude byte ode, son exé ution est réalisée par un intergi iel. Dans le as d'une des ription du om-portement sous forme de ode sour e (formel ou non) le hoix reste libre, même si généralement la on�guration est ompilée. Ce hoix est important et intervient très t�t dans le développement.27

Chapitre 2. État de l'artL'utilisation d'un intergi iel permet de onserver la séparation en omposants pendant l'exé- ution. Elle permet ainsi de ontr�ler l'exé ution, l'arrêt, le rempla ement, la suppression etla re on�guration de ha un des omposants. Cependant, le modèle d'allo ation des ressour esd'exé ution (tâ hes) sous-ja ent est souvent préétabli et non optimisé (par exemple une tâ hepar omposant).La ompilation d'une on�guration permet d'obtenir un ode plus e� a e en termes d'em-preinte mémoire et plus performant pour l'allo ation des ressour es. La on�guration logiquepeut même être orthogonale au modèle de tâ he hoisi et don à la on�guration opérationnelle.Des études omparatives montrent alors l'impa t de tels hoix vis-à-vis de ritères omme lerespe t des é héan es ou l'utilisation des ressour es [60, 52℄. C'est don , pour es raisons que la ompilation d'une on�guration est la solution la plus fréquemment retenue dans le domaine dessystèmes embarqués temps réel.2.2.6 Con lusion sur les ar hite turesDans e hapitre, nous avons présenté les di�érents éléments né essaires à la des riptiond'une ar hite ture logi ielle. Une ar hite ture logi ielle est dé�nie par une on�guration ; 'est-à-dire par un ensemble de omposants inter onne tés. Chaque omposant est dé�ni par un omportement dé rit de manière plus ou moins abstraite par rapport à l'implémentation. Ce omportement n'est a essible qu'au travers d'interfa es. En�n les interfa es des omposantssont inter onne tées à l'aide de onne teurs. Un ADL est un langage permettant d'exprimer ha un de es éléments.Nous avons vu qu'il existe de nombreuses possibilités pour dé rire les éléments d'une ar hi-te ture logi ielle. En parti ulier, il existe de nombreux langages de des ription ar hite turale.Cependant, l'utilisation de modèles (et de méta-modèles), en se on entrant sur la manipulationdes on epts, nous apparaît omme fédérateur. Cette appro he permet en e�et de dé�nir les on- epts d'un domaine plut�t que leur syntaxe. Travailler au niveau des on epts permet égalementd'e�e tuer des transformations de es on epts vers d'autres on epts, par exemple dans un butde ra�nement. Au niveau de la mise en ÷uvre des modèles, UML s'impose omme un standardde fait et propose de nombreux outils.Pour e qui est de la dé�nition du omportement exé utable et de son exé ution, les ar- hite tures logi ielles pour les systèmes embarqués utilisent en ore largement le langage C. Lades ription ar hite turale est alors ompilée et s'exé ute généralement dire tement sur un sys-tème d'exploitation temps réel. Cependant, l'introdu tion d'une sur ou he logi ielle au systèmetemps réel permet la mise en ÷uvre de ertains mé anismes ré urrents omme, par exemple, la ommuni ation entre les omposants. Elle permet également de s'abstraire d'une ible parti -ulière. Bien sûr, l'utilisation d'un intergi iel se fait au détriment de l'utilisation des ressour es,qui s'en trouve augmentée.Nous avons vu que les servi es proposés par un omposant sont a essibles via des interfa esen entrées/sorties ou o�ertes/requises. Ces interfa es permettent de donner une spé i� ationdu omposant auquel elles sont asso iées via quatre niveaux de ontrats. Ces ontrats permet-tent de s'assurer de l'utilisation orre te d'un omposant vis-à-vis de sa spé i� ation fon tion-28

2.2. Ar hite ture et génie logi ielnelle et extra-fon tionnelle. En parti ulier, l'établissement de ontrats de qualité de servi es estné essaire à l'utilisation de omposants dans le domaine d'appli ation visé où les ontraintesextra-fon tionnelles sont fortes.Une attention parti ulière est apportée aux hoix permettant de réaliser l'analyse de tels sys-tèmes. Ces analyses on ernent prin ipalement l'utilisation des ressour es (empreinte mémoire,ordonnan ement, et .) et les ontraintes temporelles (é héan e de bout en bout, et .). L'utilisa-tion des ressour es et les ontraintes temporelles peuvent être véri�ées lors de l'exé ution d'unsystème ou durant sa spé i� ation. Puisque les systèmes de ontr�le de pro essus peuvent pos-séder un omportement ritique en as de dysfon tionnement, il est préférable de réaliser lesanalyses pendant la spé i� ation du système.On distingue deux types d'analyses di�érentes :1. Les analyses réalisées sur une on�guration : une vue boîte grise du omportement des omposants et des onne teurs est alors né essaire. Cette vue boîte grise doit permettred'évaluer l'impa t de la on�guration sur ses propriétés extra-fon tionnelles. En�n, il fautremarquer que si le omportement est abstrait dans un langage parti ulier, permettant laréalisation d'analyse, la sémantique opérationnelle de la future mise en ÷uvre doit êtreéquivalente à elle du langage utilisé lors de l'analyse. L'utilisation de e type d'analyse estsouvent réservée à l'analyse des propriétés émergentes d'un système.2. L'établissement d'un ontrat de QoS lors de la onnexion entre deux interfa es : le on-ne teur doit permettre d'assurer l'établissement de e ontrat. Cela permet de s'assurerd'une omposition orre te vis-à-vis des ontraintes extra-fon tionnelles dire tement om-posables. Pour réaliser e i, la spé i� ation des propriétés requises et fournies dé rites parles interfa es doit être homogène et non ambigüe. De plus, la relation qui spé i�e les on-ditions sous lesquelles le ontrat peut être établi doit être spé i�ée.Les appro hes dé rites dans la littérature sont souvent homogènes au niveau du type d'analyseprésenté pré édemment : soit elles réalisent toutes les analyses sur la on�guration �nale, soit ellesréalisent les analyses par l'établissement de ontrats entre les interfa es de haque omposant.Au niveau des onne teurs, on remarque également deux appro hes di�érentes. La première onsiste à utiliser des onne teurs logiques, dans e as les interfa es ainsi onne tées doiventêtre homogènes. À l'inverse, dans le as où les interfa es sont hétérogènes en un ou plusieurspoints, un onne teur possédant une �glue� est né essaire a�n d'e�e tuer la onnexion.Dans tous les as, omme souligné dans [54℄, a�n d'être apable de réaliser des analyses surune ar hite ture logi ielle, une sémantique formelle doit être utilisée pour ha un des élémentsde l'ar hite ture. Puisqu'un style ar hite tural permet de dé�nir des types de omposants, de onne teurs et d'interfa es spé i�ques, ils peuvent être utilisés pour for er l'utilisation d'unesémantique parti ulière. Il est don important d'avoir une spé i� ation expli ite du style ar hi-te tural utilisé. L'intérêt d'un style ar hite tural est alors double :1. il permet d'imposer, d'une part une sémantique formelle à ha un des éléments de l'ar hi-te ture, et d'autre part un ensemble de ontraintes de onnexion permettant de garder une on�guration analysable. 29

Chapitre 2. État de l'art2. il permet également, de part les ontraintes de onnexion qu'il exprime, permettre l'appli- ation de prin ipes de génie logi iel a�n de posséder des qualités (au sens du génie logi iel)telles que la réutilisabilité.On voit ainsi émerger plusieurs point important a�n de permettre le développement d'unsystème embarqué et temps réel en s'appuyant sur une ar hite ture logi ielle. Premièrement l'u-tilisation de modèles paraît primordiale a�n de se on entrer sur les on epts plut�t que surle langage. Deuxièmement, la des ription et la gestion des propriétés extra-fon tionnelles doitêtre adaptée aux ontraintes à analyser : il est intéressant d'utiliser l'établissement de ontratsde QoS a�n de réer des omposants réutilisables dans plusieurs on�gurations ; ependant,l'analyse d'une on�guration peut être né essaire à l'établissement d'un ontrat pour les pro-priétés émergentes. A�n de réaliser es analyses, haque élément de l'ar hite ture doit posséderune sémantique opérationnelle formelle. En�n, un style ar hite tural, en donnant des types de omposants et de ontraintes stru turelles permet d'obtenir un système analysable, mais aussi ertaines propriétés de génie logi iel telles que la réutilisabilité.Maintenant que les prin ipes pour la mise en pla e d'une ar hite ture logi ielle ont été étudiés,la partie suivante présente les prin ipes de stru turation et les styles ar hite turaux qui ont permisle développement de systèmes informatiques indépendamment de leur ible de déploiement.2.3 Les prin ipes de l'indépendan e2.3.1 Introdu tionLa réutilisation de logi iel est un obje tif re her hé depuis le début de la programmation.Cette préo upation a fait l'objet de beau oup de propositions es vingt dernières années :librairies réutilisables, méthodes et outils d'ingénierie spé i�ques au domaine, réutilisation demotifs, ar hite tures logi ielles, programmation orientée omposant, et . [50℄. À titre d'exemples,Unix a lairement été pensé dans un but de réutilisation ; le langage C fournit des on eptsminimaux pouvant être étendus par des librairies réutilisables ; le langage C++ a également étépensé dans le but d'améliorer la réutilisation [114℄.Une des tendan es a tuelles visant à plus de réutilisation est la séparation, lors du développe-ment, des aspe ts indépendants de la plateforme de eux dépendants de la plateforme. L'indépen-dan e vis-à-vis de la plateforme est une qualité d'un modèle qui identi�e le degré d'abstra tionde e modèle par rapport aux ara téristiques d'une plateforme te hnologique parti ulière [3℄.Comme sous-entendu dans ette dé�nition et souligné dans [66℄, un modèle ne peut don jamaisêtre totalement indépendant de la plateforme sous-ja ente. En e�et tout modèle est, au mini-mum, dépendant de son méta-modèle qui onstitue alors une plateforme te hnologique plus oumoins abstraite.Cette tendan e a été renfor ée par la proposition MDA (Model Driven Ar hite ture) [95℄, ini-tiée par l'OMG (Obje t Management Group) [94℄ en 2001. MDA est une philosophie de développe-ment d'ar hite tures basée sur l'utilisation de modèles.La notion d'indépendan e étant générale, e hapitre se propose d'étudier omment les notions30

2.3. Les prin ipes de l'indépendan ede réutilisation et d'indépendan e vis-à-vis de la plateforme on été onsidérées dans plusieursdomaines de l'informatique.Avant de présenter es travaux, la notion de plateforme est dis utée.2.3.2 Notion de plateformeLa notion de plateforme ne onnait pas de dé�nition pré ise et ommunément admise. MDA[95℄ propose la dé�nition suivante :A platform is a set of subsystems and te hnologies that provide a oherent set of fun tionalitythrough interfa es and spe i�ed usage patterns, whi h any appli ation supported by that platform an use without on ern for the details of how the fun tionality provided by the platform isimplemented.Cette dé�nition explique qu'une plateforme est un ensemble de sous systèmes et de te hnolo-gies fournissant un ensemble ohérent de fon tionnalités au travers d'interfa es et de modèlesd'utilisations spé i�és. Ainsi, toutes les appli ations supportées par ette plateforme peuventutiliser es servi es sans se sou ier des détails on ernant leur implémentation.Cette dé�nition reste très générale. Une plateforme est perçue di�éremment suivant l'util-isation qui en est faite. Ainsi, pour un développeur d'appli ations largement distribuées, unintergi iel est une plateforme. Contrairement à ela, pour un développeur d'intergi iels 'est lesystème d'exploitation qui est la plateforme. En�n, si on développe un système d'exploitation ouun système dédié, le matériel, en termes de pro esseur, de mémoire, et ., est onsidéré ommeétant la plateforme. La notion de plateforme est don fortement in�uen ée par le domaine. Ellepeut être à rappro her de la notion de sémantique opérationnelle d'un langage de modélisation.La sémantique opérationnelle d'un langage dé rit omment un programme valide est interprétépour être exé uté. De la même manière, ha un des servi es d'une plateforme pouvant être utilisépar un programme valide permet de dé rire omment les appels de e programme aux servi esde la plateforme vont être exé utés.On onserve de ette dis ussion la né essité de dé�nir une plateforme omme un ensemblede omposants en boîtes noires (ou grises) qui, une fois onne tés à une appli ation permetde �ger sa sémantique opérationnelle. On remarque que la notion de plateforme et la notionde on�guration te hnique sont pro hes. Dans la suite de e do ument, nous utilisons le termeplateforme plut�t que elui de on�guration te hnique.La se tion suivante présente omment, au ours du temps et selon les domaines, l'informatiques'est déta hée d'un type de plateforme parti ulier. 31

Chapitre 2. État de l'art2.3.3 Les appro hes existantes pour l'indépendan e vis-à-vis d'une plate-forme2.3.3.1 L'indépendan e vis-à-vis de l'ar hite ture matérielleLe langage de base ompréhensible par une ma hine, appelé langage ma hine, est om-posé d'une suite de nombres binaires. A�n de fa iliter l'utilisation des ordinateurs pour lesdéveloppeurs, le langage assembleur a été proposé. Un tel langage est ompréhensible par unhumain mais reste pro he du langage ma hine et dépend don étroitement du type de pro esseurutilisé. Chaque pro esseur possède son propre langage ma hine. Ainsi, un programme développépour une ma hine ne peut pas être exé uté sur une autre ma hine. A�n de ontourner e prob-lème, des langages indépendants des instru tions d'un pro esseur parti ulier ont vu le jour.Si es langages permettent de ibler de la même manière plusieurs pro esseurs, l'a ès auxdivers périphériques, omme par exemple un port parallèle ou un disque dur, reste toujoursdépendant de la plateforme sous ja ente. Cet a ès requiert une onnaissan e exa te du disqueet une maîtrise �ne de la programmation. De plus il demande une gestion des a ès on urrentsentre les di�érentes appli ations qui utilisent e périphérique. A�n d'aider le développeur, lesar hite tures matérielles des ordinateurs se sont alors vues dotées d'un système d'exploitation.Les systèmes d'exploitation ont deux buts prin ipaux : gérer les a ès on urrents auxressour es et fournir une abstra tion du matériel présent sur l' on�guration te hnique sous ja- ente [119℄. Pour ela ils fournissent une API (Appli ation Programming Interfa e) ommuneà une lasse de matériels pouvant réaliser ette API. Ainsi, deux disques durs di�érents peu-vent être utilisés de manière transparente malgré une di�éren e de apa ité ou de te hnologie ar ils supportent tous les mêmes servi es d'a ès (primitives open(), read(), write, lose(), ...).Les adaptations né essaires entre les primitives de l'API du système d'exploitation et elles dumatériel sont alors à la harge du pilote de périphériques (driver). Le pilote doit don avoirune onnaissan e de l'API désiré a�n de réaliser l'adaptation né essaire, dépendante d'un pé-riphérique parti ulier [120℄. Sur un système d'exploitation moderne, l'ensemble de es APIs estappelé HAL (Hardware Abstra tion Layer). Les systèmes d'exploitation permettent ainsi de iblerindi�éremment les di�érents matériels lassiques d'un ordinateur personnel. Cette ar hite tureest alors une ar hite ture en ou he où ha une des ou hes abstrait une partie des détailsmatériels par une API ( f. �gure 2.5).La multipli ation des systèmes d'exploitation a fait émerger deux problèmes :1. L'impossibilité d'exé uter simultanément plusieurs systèmes d'exploitation sur la même on�guration te hnique. Ce i est dû à la né essité d'avoir une gestion entralisée des a ès on urrents à un périphérique.2. L'impossibilité d'exé uter la même appli ation sur plusieurs systèmes d'exploitation. Ce iest dû à l'hétérogénéité des APIs des systèmes d'exploitation.La notion de ma hine virtuelle permet de ontourner es problèmes. Une ma hine virtuelleest une ou he supplémentaire pouvant se pla er à di�érents endroits et permettant de fournirdi�érents types de servi es suivant le but re her hé [103℄.Une ma hine virtuelle peut fournir des servi es semblables à eux d'une on�guration te h-32

2.3. Les prin ipes de l'indépendan e

Fig. 2.5 � Les di�érentes ou hes d'un système d'exploitationnique a�n de permettre l'exé ution de systèmes d'exploitation de manière on urrente ( f. �gure2.6 B). Pour ela, la ma hine virtuelle, basée sur un système d'exploitation h�te, propose uneAPI semblable à elle d'une on�guration te hnique. Ainsi, les systèmes d'exploitation ommu-niquent ave le matériel virtualisé par l'API de la ma hine virtuelle plut�t qu'ave le matérielréel ; et e i de manière transparente.Une ma hine virtuelle peut également se pla er au dessus d'un système d'exploitation a�nd'homogénéiser les APIs de di�érents systèmes d'exploitation et ainsi permettre à une appli ationde s'exé uter indi�éremment sur l'un ou l'autre des systèmes d'exploitation possédant ettema hine virtuelle ( f. �gure 2.6 A).Con lusion sur l'indépendan e vis-à-vis de l'ar hite ture matérielle Depuis la réa-tion des langages adressant plusieurs pro esseurs jusqu'à l'utilisation d'une ma hine virtuelle enpassant par l'ajout d'une ou he HAL, l'envie de donner une interfa e ommune (virtuelle ounon) à tous les matériels est omniprésente. Ainsi, plut�t que de développer un système dédiéà un matériel spé i�que, l'utilisateur développe un système dédié à une interfa e donnée, etteinterfa e étant par la suite reliée à des matériels spé i�ques.Les appro hes suivies s'appuient sur une ar hite ture en ou he : haque ou he du systèmefournit à la ou he supérieure une abstra tion des servi es fournis par la ou he inférieure. Ledéveloppeur base don le développement de son appli ation sur l'API d'un matériel abstrait. Lesservi es de e matériel abstrait sont adaptés au fur et à mesure des ou hes pour orrespondrein �ne à un matériel réel.Ce style ar hite tural en ou he (Layered) a également été adopté dans les réseaux de om-muni ation. Le paragraphe suivant détaille e point. 33

Chapitre 2. État de l'art

Fig. 2.6 � Les di�érentes utilisations d'une ma hine virtuelle2.3.3.2 L'indépendan e dans les réseauxDans les années 60, les grands onstru teurs (Bull, DEC, IBM, ...) ommen ent à dévelop-per de nombreux proto oles. Malheureusement eux- i n'étaient pas ompatibles entre eux. Lebesoin d'inter onne ter tous es réseaux s'est alors fait de plus en plus pressant, obligeant les onstru teurs à se on erter. Parallèlement, la ommuni ation entre deux ma hines sur un réseaua exigé un ensemble d'opérations de plus en plus omplexes. De toutes es ontraintes est né lebesoin de simpli�er la ommuni ation en divisant les tâ hes à e�e tuer en sous-tâ hes, ha uneimplémentée séparément.C'est en 1982 que ommen e un e�ort de standardisation dans le monde des réseaux ave lemodèle d'ar hite ture OSI (Open System Inter onne tion [131℄). Cet e�ort fut initié par l'ISO(International Standard Organization). Le modèle ISO/OSI est basé sur une stru turation en ou he. Ce modèle, largement utilisé, est en quelques sortes un modèle général de réseau in-formatique ( f. �gure 2.7). Il répartit les questions relatives au domaine des ommuni ationsinformatiques selon sept ou hes lassées par ordre d'abstra tion roissant. Son obje tif est d'as-surer que les proto oles spé i�ques utilisés dans ha une des ou hes oopèrent pour assurerune ommuni ation e� a e entre des réseaux et des proto oles hétérogènes. Cependant, ettestru turation en ou he est outeuse et de e fait la distan e entre l'utilisation on rète (l'im-plémentation) et le modèle est parfois importante. En e�et, peu de programmes peuvent utiliserl'ensemble des 7 ou hes du modèle : les ou hes session et présentation sont fort peu utilisées età l'inverse les ou hes liaison de données et réseau sont très souvent dé oupées en sous- ou hestant elles sont omplexes [116℄. De même, pour des raisons de performan es, ertaines appro hestelles que [9℄ ourt- ir uitent l'en apsulation en ou hes.Quoi qu'il en soit, les appli ations développées sur le modèle OSI utilisent des primitivesde ommuni ations abstraites pour pouvoir transmettre des informations. Ces primitives sontlargement plus simples à utiliser que les ou hes de bas niveau du modèle qui demande une on-naissan e pointue du réseau physique. L'adaptation entre les primitives o�ertes aux appli ations34

2.3. Les prin ipes de l'indépendan e

Fig. 2.7 � Les sept ou hes du modèles OSIet elles qui ontr�lent le réseau physique s'e�e tue au fur et à mesure du passage d'une ou heà une autre.Cependant, ave l'arrivée des systèmes largement distribués, l'utilisation de primitives perme-ttant de masquer les ommuni ations distantes entre di�érents objets s'est fait ressentir. L'utili-sation d'un intergi iel (middleware) propose alors des primitives semblables pour ommuniquerentre deux objets distants et deux objets lo aux. Il y a de nombreuses dé�nitions di�érentes duterme intergi iel dans la littérature. Cependant, la dé�nition généralement admise est la suivante :�Middleware is the software that assists an appli ation to intera t or ommuni ate with otherappli ations, networks, hardware, and/or operating systems� [17℄Cette dé�nition dé�nit un intergi iel omme un logi iel qui assiste une appli ation pour ommuniquer ave d'autres appli ations, réseaux, matériels, et/ou systèmes d'exploitation.Parallèlement, dans le domaine des réseaux de terrains (FIP [93℄, Pro�bus [92℄, CAN [111℄,TTP [73℄), 'est-à-dire des réseaux dédiés aux ommuni ations au sein d'un même système( ommuni ation des équipements dans une haîne d'usine), des besoins di�érents de eux desréseaux lassiques apparaissent. Du fait du domaine, es réseaux ont prin ipalement des besoinsde prédi tibilité et de robustesse. Ils doivent également diminuer les délais de ommuni ation desé hanges d'informations. Pour e faire, les réseaux de terrains ont une ar hite ture de ommu-ni ation ne reprenant généralement que trois des sept ou hes du modèle OSI standard ( ou he0, 1 et 7 ; f. �gure 2.7) [100℄. Ils laissent ainsi l'adaptation des ou hes 2 à 6 aux soins dudéveloppeur.Con lusion sur l'indépendan e vis-à-vis des réseaux En ore une fois le style ar hite -tural en ou he permet de s'abstraire des détails matériels. La séparation en sept ou hes dumodèle OSI entraîne des traitements qui peuvent s'avérer oûteux. Pour palier e oût, ertainsauteurs omme [24℄ proposent de ourt- ir uiter ette stru ture en ou hes ; réduisant de fait samodularité. La même préo upation de performan e apparait dans les réseaux de terrains quilimitent le modèle OSI à trois ou hes fondamentales.Au ontraire, a�n de permettre une plus grande transparen e dans le développement d'ap-35

Chapitre 2. État de l'artpli ations distribuées, l'arrivée des intergi iels peut être vue omme l'ajout d'une ou he sup-plémentaire au modèle OSI. Un ompromis doit don être fait entre l'utilisation de nombreuses ou hes d'abstra tion et les besoins de performan e.Si la division en ou hes des réseaux est normalisée, elle des interfa es homme ma hine nel'est pas aussi lairement.2.3.3.3 L'indépendan e vis-à-vis des Interfa es Homme Ma hine (IHM)Les premières interfa es hommes ma hines réalisées étaient spé i�ées ave le même langageque le reste du programme. Les interfa es graphiques utilisaient don les primitives fourniespar le système d'exploitation. Alors que les langages informatiques évoluaient et permettaientd'être ompilés et/ou interprétés sur di�érents systèmes d'exploitation, l'utilisation de primitivesgraphiques ou d'entrée/sortie spé i�ques à un système d'exploitation parti ulier obligeait lesappli ations à être redéveloppées pour haque nouveau système d'exploitation. L'importan ed'une on eption ar hite turale émerge alors et plusieurs styles ar hite turaux sont proposés.Le style ar hite tural MVC (Model-View-Controler) [74℄ a été un des premiers à proposerun style ar hite tural réalisant une séparation fran he entre la partie présentation et la partie omportement des appli ations. Il distingue trois omposants logiques :� le Modèle réunit l'ensemble des fon tions relatives au noyau fon tionnel de l'appli ation ;� la Vue se harge de la présentation des informations à destination de l'utilisateur ;� le Contr�leur interprète les données en provenan e de l'utilisateur.Ainsi lors d'un hangement de plateforme, le Modèle peut, en théorie, être réutilisé. Cepen-dant, les ommuni ations et les adaptations entre le Modèle et les deux autres omposantslogiques n'est pas expli ite et limite don la réutilisation.Le style ar hite tural Seeheim [27℄ distingue également trois omposants logiques dans lebut de séparer le domaine de l'appli ation de sa présentation à l'utilisateur ( f. �gure 2.8).Toutefois ontrairement à MVC qui distingue les interfa es d'entrées et elles de sorties, Seeheimles regroupe dans le même omposant Présentation.Ce omposant lit les données en provenan e des dispositifs physiques d'entrée et les traduiten une forme abstraite ompatible ave le monde informatique interne. Il reçoit également desinformations abstraites qu'il interprète dans les termes du lexique des dispositifs de sorties. C'estle seul omposant du système à manipuler les dispositifs physiques d'entrées/sorties.Seeheim distingue également le omposant Interfa e ave l'appli ation. Ce dernier dé�nitles fon tions exportées ainsi que les ontraintes d'utilisation de es fon tions. En�n, le om-posant Contr�leur de dialogue joue le r�le de médiateur et de �ltre entre les deux omposantspré édemment dé rits.[28℄ s'a orde ave les nombreux auteurs qui mettent en éviden e les avantages de la dé- omposition en niveaux d'abstra tions, depuis les on epts du domaine jusqu'aux �ns détails del'intera tion.36

2.3. Les prin ipes de l'indépendan e

Fig. 2.8 � Le style ar hite tural Seeheim (�gure adaptée de [28℄)Un autre style ar hite tural dit �entrée/sortie� modélise un é hange ave l'utilisateur ommeune suite d'opérations d'entrées/sorties et de traitements ( f. �gure 2.9). Cette suite de trans-formations est assurée par une hiérar hie de ma hines abstraites [25, 26℄. La ma hine de plusbas niveau interagit ave les dispositifs matériels servant à ommuniquer ave l'utilisateur. Lesinformations en provenan e de ette ma hine sont progressivement transformées en données ab-straites ompréhensibles par l'appli ation. Dans le sens inverse, les on epts de l'appli ation sonttraduits su essivement pour être ompréhensibles par la ma hine de plus bas niveau.Sur la �gure 2.9, les �è hes verti ales symbolisent les appels dire ts d'un programme lientaux fon tions d'une ma hine. Sur la gau he de la �gure les on epts manipulés dans haqueniveau. En ara tère gras, on retrouve les lasses de servi es rendus et entre parenthèses, lesnoms usuels des ma hines.

Fig. 2.9 � Le style ar hite tural dit �entrée/sortie� (�gure extraite de [28℄)Cette dé omposition imite le modèle OSI ( f. 2.3.3.2), à la di�éren e près que ha une des ou hes d'abstra tion o�re une interfa e a essible par l'appli ation. Bien que réduisant grande-ment la modularité, e i permet de gagner en performan e en limitant les oûts de transfert entreles ou hes logi ielles. 37

Chapitre 2. État de l'artLes styles ar hite turaux �Seeheim� et �entrée/sortie� donnent des prin ipes généraux destru turation et font ressortir l'envie de séparation entre la partie appli ation et la partie présen-tation. Toutefois, le lien entre es deux vues est peu détaillé. Le style ar hite tural PAC [29℄pour Présentation Abstra tion Contr�le omble e vide. PAC identi�e l'interfa e ave uneappli ation dans le omposant Abstra tion et la ommuni ation ave le matériel dans la vuePresentation. La vue Contr�le est alors en harge de l'intera tion entre les deux omposantspré édents. L'intera tion est dé rite sous forme d'agents [110℄. Ce style ne fournit pas de lim-itation sur l'abstra tion idéale entre les omposants abstra tion et presentation puisque le omposant ontr�le peut être dé omposé ré ursivement sous la forme d'un système PAC.

Fig. 2.10 � Le style ar hite tural PAC (�gure adaptée de [29℄)Le r�le du omposant Contr�le est identi�é. Il est double et omprend les fon tions d'ar-bitrage et de tradu tion ( f. �gure 2.10). L'arbitrage on erne, par exemple, les syn hronisa-tions entre les di�érents événements en provenan e / à destination des omposants Abstra tionet Présentation. La fon tion de tradu tion sert, elle, d'intermédiaire entre le formalisme dereprésentation abstrait de l'appli ation (Abstra tion) et le formalisme de représentation pourl'utilisateur (Présentation).Con lusion sur l'indépendan e vis-à-vis des IHMs Dans le domaine des IHMs, il est ourant de onstater qu'à une sémantique donnée orrespondent plusieurs formes syntaxiques.Autrement dit, l'utilisateur peut dé len her la même fon tionnalité d'une appli ation de dif-férentes manières. Il en est de même pour l'appli ation qui peut ommuniquer la même infor-mation à l'utilisateur de di�érentes manières. Ce i à amené à proposer des styles ar hite turauxséparant la partie sémantique et la partie syntaxique. Pour e faire, on trouve la stratégie destru turation en ou he du style �entrée/sortie� et la stratégie de stru turation en trois partiesde MVC, Seeheim et PAC.La dé omposition en niveaux d'abstra tion fournit une base saine à la dé�nition d'ar hi-te tures modulaires. Cependant, elle introduit des oûts de ommuni ation entre ha une des ou hes qui en limitent les performan es. Les styles ar hite turaux basés sur le modèle Seeheimont été largement utilisés dans le domaine de l'IHM. PAC ra�ne et spé i�e plus pré isément lestyle Seeheim a�n de le rendre plus exploitable. Il est don important de dé rire pré isément ler�le de ha un des éléments d'un style ar hite tural ainsi que les prin ipes de réalisation de esr�les.38

2.3. Les prin ipes de l'indépendan eLes IHMs sont une famille d'interfa es de ommuni ation parti ulières puisqu'elles utilisentlargement l'é ran omme moyen d'intera tion ave leur environnement (dans e as l'utilisa-teur). Une IHM peut alors évoluer dynamiquement lors de l'intera tion (ouverture de nouvellesboîtes de dialogue, fenêtres, et .). Dans le domaine qui nous intéresse, les ommuni ations ave l'environnement se font par l'intermédiaire de périphériques physiques ( apteurs et a tionneurs).2.3.3.4 L'indépendan e vis-à-vis des périphériquesSur un ordinateur lassique de type PC, les entrées physiques orrespondent essentiellementau lavier et à la souris. De la même manière que la ou he d'abstra tion logi ielle (HAL)d'un système d'exploitation fournit une API indépendante d'un matériel parti ulier, une APIindépendante d'un type pré is de lavier ou de souris peut être réalisée. Dans Windows, etteAPI regroupe les a tions possibles d'une souris ou d'un lavier dans un périphérique virtuel [86℄.Les appli ations interagissent ainsi ave une souris virtuelle plut�t qu'ave la souris physique.Ce i permet de lier l'appli ation ave tous les types de souris mais également d'autres typesde périphériques rendant les mêmes servi es qu'une souris (i.e. un tou hpad ou une palettegraphique). Les pilotes des périphériques réels doivent réaliser l'adaptation entre les servi es dupériphérique réel et eux du périphérique virtuel.Les problèmes introduits par la ommuni ation ave les périphériques d'entrées / sorties d'unsystème sont rarement traités ( f. analyse de [120℄). Cependant, [1℄ propose une appro he à based'intergi iel pour adresser le problème de l'indépendan e d'une appli ation temps réel par rapportà ses apteurs et ses a tionneurs [1℄. Cette appro he a pour but de permettre le développementd'une appli ation indépendamment des types et des unités des données véhi ulées par les apteursou vers les a tionneurs ( f. �gure 2.11).Pour e faire, le style ar hite tural proposé sépare les données utiles à une appli ation de ellesvéhi ulées au travers des apteurs / a tionneurs par une ou he de transformation (Input / OutputTransforms �gure 2.11). Puisque les auteurs s'intéressent au développement d'appli ation tempsréel, l'étude introduit dans la spé i� ation des données né essaires à l'appli ation une des riptionqui omprend, pour ha une des données en entrée ou en sortie : l'unité, le type, l'intervalle devaleurs possibles, la validité, la fraî heur, le taux de rafraî hissement, la pré ision et la �abilité.La ou he transformation est au ÷ur de la séparation entre les apteurs / a tionneurset les entrées / sorties né essaires à l'appli ation. Elle est en harge des onversions de type(par exemple short integer vers integer, et .) et d'unité (par exemple km/s vers m/s, et .).Cette ou he est également en harge de la gestion de la redondan e. Ainsi, elle peut re evoirles informations de plusieurs apteurs redondants et hoisir à l'aide de voters l'information quisemble la plus orre te. Dans le sens inverse, elle peut re evoir les informations de plusieursappli ations s'exé utant sur des pro esseurs di�érents et dé ider quelle information envoyer versles a tionneurs du système. L'utilisation de voters prend en harge ertains aspe ts de toléran esaux fautes. Le développement de l'appli ation basé sur les entrées / sortie est don indépendantdes aspe ts de toléran es aux fautes.Malgré la spé i� ation de ontraintes temporelles sur les données, au une information n'estfournie quand à leur utilisation pour la validation du système. Les auteurs ne pré isent pas39

Chapitre 2. État de l'art

Fig. 2.11 � Un style ar hite tural pour l'indépendan e vis-à-vis des apteurs / a tionneurs (�gureextraite de [1℄) omment sont traitées les propriétés extra-fon tionnelles. De même il n'est pas pré isé s'il estpossible de onstruire une entrée à partir de plusieurs informations apteurs di�érentes.Con lusion sur l'indépendan e vis-à-vis des périphériques Le fait de virtualiser un omposant existant pour baser les appli ations sur le omposant virtuel plut�t que le omposantréel rejoint l'idée développée dans [1℄. Cependant, en hoisissant ette stratégie, les servi es utilesdu périphérique réel sont limités à eux du périphérique virtuel. Ainsi, on ne peut pas pro�terde tous les servi es du périphérique réel s'ils ne sont pas pris en harge par le périphériquevirtuel. Malgré et in onvénient fort, utiliser un périphérique virtuel permet d'o�rir une interfa estandard entre un ensemble d'appli ations et un ensemble de périphériques, favorisant ainsi laréutilisation de l'un ou de l'autre.Dans la même idée que PAC ( f. hapitre 2.3.3.3) pour les IHMs, l'idée dé rite dans [1℄ estintéressante ar elle onsiste à développer une appli ation en se basant sur une des ription desentrées et des sorties né essaires à l'appli ation plut�t que sur une des ription des données enprovenan e et à destination des apteurs et des a tionneurs d'une plateforme parti ulière. Celapermet l'a eptation de hangement matériel sur les apteurs / a tionneurs sans pour autanta�e ter l'appli ation. Il est toutefois impératif de spé i�er de manière pré ise les entrées / sortiesné essaires à l'appli ation ; d'un point de vue fon tionnel et extra-fon tionnel. Une ou he de liai-son est alors inévitable à la liaison entre les entrées / sorties et les apteurs / a tionneurs. En�n,il faut s'assurer de la orre tion fon tionnelle et extra-fon tionnelle des apteurs / a tionneursvis-à-vis de la des ription des entrées / sorties. Ce point n'est pas abordé dans [1℄.40

2.3. Les prin ipes de l'indépendan e2.3.3.5 Con lusionLes styles ar hite turaux étudiés dans le adre de ette thèse montrent indubitablement quele style ar hite tural en ou he est le plus adapté pour mettre en ÷uvre la séparation entre lesaspe ts dépendants et indépendants d'une plateforme.On distingue deux appro hes de stru turation en ou he. La première est elle qui onsiste, omme dans la se tion traitant de l'indépendan e vis-à-vis de l'ar hite ture matérielle (se tion2.3.3.1), à ajouter su essivement des ou hes a�n d'atteindre petit à petit les obje tifs d'indépen-dan e désirés. Dans ette appro he le nombre de ou hes peut varier au ours du temps selon lesbesoins.L'autre stratégie onsiste à élaborer un dé oupage en ou he a priori qui sert de base pour lesappli ations dans un domaine parti ulier ( f. les ou hes du modèle OSI se tion 2.3.3.2). Dans e as, plus le nombre de ou hes est élevé, plus les niveaux d'abstra tions sont nombreux. Lesaspe ts dépendant de la plateforme peuvent ainsi s'appuyer sur le niveau d'abstra tion qui leur orrespond le mieux et éviter la ré-implémentation des ou hes supérieures pour atteindre la ou he la plus haute (la plus abstraite). Le nombre de ou hes d'abstra tions est proportionnelau gain en modularité. Il est ependant inversement proportionnel aux performan es. Il est don né essaire de réaliser un ompromis entre la modularité et les performan es.Pour s'abstraire des périphériques, la virtualisation d'un périphérique existant permet defournir une interfa e ommune à toutes les appli ations utilisant ette famille de périphériques.Cette appro he n'admet, ependant, que de faibles variabilités entre les fon tionnalités des pé-riphériques réels.Les IHMs, de leur �té, ont des préo upations de performan es a�n d'assurer une intera tione� a e ave l'utilisateur. De plus, une IHM, ontrairement à un réseau, est réalisée pour inter-fa er une appli ation parti ulière. Le nombre de ou hes minimal permettant l'indépendan e estalors re her hé. Dans e ontexte, la littérature identi�e trois ou hes : l'interfa e ave l'appli- ation, l'interfa e ave l'environnement et la ou he de liaison entre les deux pré édentes. La ou he de liaison permet de onne ter les deux autres ou hes en réalisant diverses adaptationssuivant les appro hes. Cette appro he est également elle utilisée dans [1℄ pour obtenir une formed'indépendan e vis-à-vis des apteurs et des a tionneurs d'un système.Cependant, pour les systèmes temps réel, au une gestion des propriétés extra-fon tionnellesn'est proposée lors de la onnexion entre les ou hes appli ations et la plateforme sous forme de apteurs et d'a tionneurs.L'apport de MDA Les styles ar hite turaux dé rits pré édemment présentent les di�érentesentités qui s'exé utent dans le système. MDA propose une modélisation de es entités au traversde trois familles de modèles :PIM Platform Independent Model. Ce modèle permet de spé i�er les entités intervenant dans lesfon tionnalités d'un système indépendamment de la façon dont es fon tionnalités serontréalisées par une plateforme. 41

Chapitre 2. État de l'artPM Platform Model. Ce modèle permet de spé i�er les di�érentes entités et servi es fournis parune plate forme parti ulière.PSM Platform Spe i� Model. Ce modèle exhibe la façon dont les fon tionnalités des entitésdé rites dans le PIM sont réalisées par un PM parti ulier.Le passage d'un PIM à un PSM se fait par une transformation appelée mapping ( f. �gure2.12). Ce mapping peut être omplexe et ainsi fusionner les deux modèles PIM et PM ave unobje tif spé i�que, par exemple l'optimisation des performan es. Ce i permet ainsi de spé i�erune stru turation en ou he au niveau modèle sans pâtir du oût introduit par une stru turationen ou he lors de l'exé ution.

Fig. 2.12 � Les prin ipaux modèles MDA et leurs relations[3℄ met en avant le manque de dire tives dans MDA pour le hoix d'abstra tion dans le PIM.Il pré onise alors l'utilisation d'une plateforme abstraite. Une plateforme abstraite dé�nit unensemble de plateformes qui sont pertinentes pour l'appli ation. Plus pré isément, une plate-forme abstraite dé�nit un ensemble de servi es dont a besoin l'appli ation. La des ription de esservi es peut être plus ou moins pré ise suivant le degré d'indépendan e souhaité. Ce i permetde dé�nir lairement le degré d'indépendan e des modèles PIM en réduisant la taille de l'espa ede modélisation à explorer pour la réalisation des PSMs.[3℄ identi�e alors deux appro hes pour la réalisation des PSMs. Dans la première ( f. (1) �gure2.13), la plateforme réelle est adaptée pour orrespondre dire tement à la plateforme abstraite.Le modèle PIM n'est don pas modi�é. Dans la deuxième appro he ( f. (2) �gure 2.13), le PSMest une adaptation, en respe t de la spé i� ation réalisée dans le PIM, permettant de le omposerave la plateforme réelle.Dans le domaine des IHMs, on peut iter l'appro he SEFAGI [22℄. Ce travail permet de dé rireune plateforme abstraite ainsi que les adaptations prédé�nies pour un ensemble de plateformesréelles. Ce i permet de hanger les adaptations de la plateforme abstraite selon la plateformeréelle à l'exé ution. Ainsi l'appli ation s'adapte dynamiquement à la plateforme. Il faut ependantréaliser a priori les adaptations né essaires et don dé�nir un ensemble �ni de plateformes réellesa eptables.42

2.4. Con lusion sur l'état de l'art

Fig. 2.13 � Deux appro hes pour la réalisation d'un PSM (�gure extraite de [3℄).Dé rire expli itement une plateforme abstraite permet de mieux omprendre les ara téris-tiques présumées des plateformes utilisables et permet ainsi une réutilisation plus aisée d'un PIMsur di�érentes plateformes. De plus, dans le adre des systèmes embarqués temps réel, ela per-met de donner les ara téristiques extra-fon tionnelles devant être respe tées par la plateformeréelle.2.4 Con lusion sur l'état de l'artLe domaine des ar hite tures logi ielles a donné lieu à de nombreuses appro hes, souventdestinées à une utilisation parti ulière. Ainsi, ertaines appro hes sont destinées à permettrel'installation ou le rempla ement d'éléments de l'ar hite ture ( omposants) lors de l'exé ution ;d'autres permettent de générer un ode exé utable à partir d'une des ription ar hite turale ; en�nd'autres en ore s'atta hent à fournir des des riptions ar hite turales permettant la réalisationd'analyses de performan es.Nonobstant ette diversité entre les appro hes, des similarités apparaissent selon le domaineadressé. Ainsi, lassiquement dans le domaine des systèmes embarqués temps réel, le omporte-ment d'un omposant logi iel est réalisé en langage C, puis ompilé et exé uté sur un systèmed'exploitation temps réel. Dans la quasi totalité des appro hes destinées aux appli ations tempsréel, la des ription ar hite turale résulte en une on�guration opérationnelle. Travailler au niveaude la on�guration opérationnelle permet d'analyser de manière pré ise un système dédié à uneplateforme parti ulière. Cependant, a�n de dé rire une ar hite ture de manière indépendanted'une plateforme d'exé ution parti ulière, il est possible de dé rire une ar hite ture logique etd'abstraire la plateforme d'exé ution en spé i�ant des budgets temporels.Pour les systèmes embarqués temps réel, les appro hes se sont prin ipalement atta hées à43

Chapitre 2. État de l'artpermettre la des ription et l'analyse de propriétés lassiques dans le domaine (ordonnan ement, ontraintes de bout en bout, viva ité, et .). Peu de styles ar hite turaux ont été proposés a�n depermettre l'appli ation de prin ipes de génie logi iel. En parti ulier, la séparation des préo upa-tions entre la on�guration logique et la plateforme n'est que peu abordée. Lorsque e point estabordé, il dé rit la on�guration te hnique en termes de support d'exé ution et ne se préo upepas ou peu des interfa es de ommuni ation entre le système et le monde extérieur. Ce pointnous parait pourtant ru ial pour permettre l'utilisation d'une même on�guration logique surplusieurs plateformes.Lors de la onnexion des interfa es, on trouve parmi les appro hes existantes l'établissementde ontrats de niveau 1, 2 et 3 mais les ontrats de QoS n'en sont qu'à leur début. La prin ipalepréo upation des appro hes existantes est alors de spé i�er des ontrats plut�t que de les établir.Ces appro hes proposent généralement de négo ier les ontrats de QoS lors de l'exé ution. Dansles systèmes visés par l'étude, les aspe ts ritiques imposent l'établissement des ontrats avantl'exé ution. De plus, a�n de prendre en ompte les propriétés émergentes, il peut être né essairede oupler l'établissement d'un ontrat de QoS ave la réalisation préalable d'analyses sur une on�guration.En�n, pour permettre la mise en appli ation de prin ipes de génie logi iel et aussi permettrel'établissement de ontrats de QoS de manière formelle, un style ar hite tural adéquat doitêtre dé�ni. Le style ar hite tural doit d'une part dé�nir des prin ipes de stru turation et des ontraintes pour utiliser les résultats issus du génie logi iel et d'autre part dé�nir des typesde omposants et de onne teurs permettant la des ription et l'évaluation de propriétés extra-fon tionnelles ainsi que l'établissement des ontrats asso iés.Ainsi, omme le montre la littérature, a�n d'augmenter la réutilisabilité d'une plateformea une autre, un style ar hite tural en ou he est pré onisé. De plus, e style doit permettre ladé�nition d'une plateforme abstraite permettant de spé i�er de manière expli ite les besoins del'appli ation. En�n le style ar hite tural doit également permettre la dé�nition d'une plateformeréelle et de la liaison omplexe qui lie la plateforme abstraite à la plateforme réelle. Ces des rip-tions devront permettre la réalisation des analyses et la mise en pla e des ontrats né essairespour assurer la orre tion du système.En partant de e onstat, l'étude proposée a pour but de fournir les on epts dé�nissant unstyle ar hite tural pour assurer l'indépendan e d'un système de ontr�le de pro essus vis-à-vis deses besoins de ommuni ation ave le monde extérieur. De plus, les on epts du style ar hite turalproposé doivent permettre de valider la orre tion de l'appli ation de ontr�le en fon tion des ontraintes temporelles de ses ommuni ations ave le monde extérieur. La présentation de es on epts est réalisée dans le hapitre suivant.44

3SAIASommaire3.1 Le style ar hite tural SAIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.1.1 La stru turation en ou hes . . . . . . . . . . . . . . . . . . . . . . . . 473.1.2 Le onne teur omplexe . . . . . . . . . . . . . . . . . . . . . . . . . . 483.1.3 QoS et qualité de ontr�le . . . . . . . . . . . . . . . . . . . . . . . . . 493.1.4 Le ontrat de QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.1.5 Niveau de des ription ar hite turale . . . . . . . . . . . . . . . . . . . 503.1.6 SAIA et le langage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.2 Les (méta-)modèles dans SAIA . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.2.1 Le modèle à omposant . . . . . . . . . . . . . . . . . . . . . . . . . . 523.2.2 Le modèle SAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.2.2.1 Les pilotes d'a quisition de données . . . . . . . . . . . . . . 553.2.2.2 Les pilotes d'a quisition d'événements . . . . . . . . . . . . . 563.2.2.3 Les pilotes de réalisation de ommandes . . . . . . . . . . . 573.2.2.4 Les pilotes de réalisation de ommandes événementielles . . 573.2.2.5 Le SAM et la qualité de servi e . . . . . . . . . . . . . . . . 573.2.2.6 Con lusion sur le SAM . . . . . . . . . . . . . . . . . . . . . 583.2.3 Le modèle SAIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.2.3.1 Les entrées . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.2.3.1.1 Les données . . . . . . . . . . . . . . . . . . . . . . 603.2.3.1.2 Les événements . . . . . . . . . . . . . . . . . . . . 613.2.3.2 Les sorties . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.2.3.2.1 Les ommandes . . . . . . . . . . . . . . . . . . . . 623.2.3.2.2 Les ommandes événementielles . . . . . . . . . . . 623.2.3.3 Le SAIM et la QoS . . . . . . . . . . . . . . . . . . . . . . . 623.2.3.4 Con lusion sur le SAIM . . . . . . . . . . . . . . . . . . . . . 633.2.4 Le onne teur omplexe . . . . . . . . . . . . . . . . . . . . . . . . . . 6445

Chapitre 3. SAIA 3.2.4.1 Les types de omposants de l'ALM . . . . . . . . . . . . . . 643.2.4.1.1 Les omposants d'adaptation d'entrées . . . . . . . 653.2.4.1.2 Les omposants d'adaptation de sorties . . . . . . 653.2.4.1.3 Les interfa es de on�guration . . . . . . . . . . . 673.2.4.1.4 Contraintes stru turelles . . . . . . . . . . . . . . . 673.2.4.2 Spé i� ation de la �glue� . . . . . . . . . . . . . . . . . . . . 693.2.4.2.1 Adaptation de types / unités . . . . . . . . . . . . 693.2.4.2.2 Adaptation sémantique . . . . . . . . . . . . . . . 703.2.4.2.3 Adaptation de QoS . . . . . . . . . . . . . . . . . . 713.2.4.3 Con lusion sur l'ALM . . . . . . . . . . . . . . . . . . . . . . 723.3 SAIA et la QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723.3.1 Introdu tion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723.3.2 Dé�nition de la QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733.3.2.1 Dé�nition des o urren es de QoS . . . . . . . . . . . . . . . 733.3.2.2 Dé�nition des ara téristiques de QoS . . . . . . . . . . . . . 753.3.3 Analyse du onne teur omplexe . . . . . . . . . . . . . . . . . . . . . 763.3.3.1 Prin ipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763.3.3.2 Méthode d'analyse . . . . . . . . . . . . . . . . . . . . . . . 773.3.4 Établissement du ontrat de QoS . . . . . . . . . . . . . . . . . . . . . 793.3.4.1 Résumé des étapes d'établissement d'un ontrat de QoS dansSAIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813.4 Con lusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

46

3.1. Le style ar hite tural SAIACe hapitre présente le style ar hite tural proposé dans le adre de ette thèse. Appelé SAIApour Sensors / A tuators Independent Ar hite ture, il orrespond à un ensemble :� de types de omposants,� de ontraintes sur les intera tions possibles entre es omposants,� de modèles formels pour la des ription des ara téristiques de QoS, asso iés à des règlesd'évaluation de la QoS,� de règles d'établissement d'un ontrat de QoS.Les types de omposants, leur QoS ainsi que les ontraintes sur leurs asso iations sont ex-primées à l'aide de di�érents modèles. Une première partie de e hapitre permet d'introduireles prin ipes généraux de stru turation des omposants selon le style ar hite tural SAIA. Unedeuxième partie permet de dé rire plus pré isément les types de omposants, de onne teurs etde ontraintes induits par le style SAIA. En�n, une troisième partie se fo alise sur les aspe tsextra-fon tionnels, i i temporels.3.1 Le style ar hite tural SAIALe style ar hite tural SAIA permet le développement d'un système de ontr�le de pro essusde manière indépendante des apteurs et des a tionneurs présents sur une plateforme spé i�que.La se tion 2.3 montre que la stru turation en ou he est une façon lassique de stru turer unsystème lorsque l'on désire être indépendant d'une plateforme ; 'est don la stratégie adoptéedans SAIA.3.1.1 La stru turation en ou hesEn se basant sur les idées développées par les modèles de stru turation dédiés aux IHMs(notamment PAC et Seeheim) et sur le modèle de stru turation pour les apteurs et les a tion-neurs présenté pré édemment, SAIA spé i�e le système selon trois ou hes distin tes. On trouvedans une première ou he l'appli ation de ontr�le et ses interfa es puis, dans une autre ou he,la te hnologie de ommuni ation entre le système et le monde extérieur. En�n, entre es deux ou hes, une troisième ou he assure la liaison au travers d'adaptations et de ontr�les.1) La première ou he dé�nit l'appli ation et ses interfa es en termes d'entrées et de sorties.Les entrées représentent les données et les phénomènes physiques pertinents pour l'appli ation.Les sorties, quant à elles, représentent les a tions physiques utiles pour le ontr�le du pro essus.Les entrées ainsi que les sorties sont spé i�ées sans fournir de renseignements on ernant late hnologie grâ e à laquelle elles sont a quises ou réalisées. L'ensemble omposé des entrées etdes sorties est une spé i� ation de la plateforme abstraite. Elle fournit un ensemble de servi esd'é ritures et de le tures utilisables en boîte noire ou grise et permettant de réaliser les ommu-ni ations de l'appli ation ave le monde extérieur via des interfa es d'entrées et de sorties. Ce ipermet de spé i�er l'appli ation en se basant sur les servi es de la plateforme abstraite et don indépendamment des servi es fournis par les pilotes des apteurs et des a tionneurs. Par analogie47

Chapitre 3. SAIAau PIM (Platform Independent Model) dé rit dans MDA, es informations sont ontenues dansle modèle appelé SAIM (Sensors / A tuators Independent Model).2) La deuxième ou he dé�nit les servi es de ommuni ation entre le système et le mondeextérieur. Cette ommuni ation est réalisée par des éléments de la plateforme matérielle : les apteurs et les a tionneurs. Les apteurs fournissent une vue du monde extérieur et les a tionneursréalisent des a tions sur le pro essus. Plus pré isément, ette ou he dé�nit les servi es des pilotesde apteurs et des pilotes d'a tionneurs, a essibles au travers d'interfa es d'entrées et de sorties.Il s'agit don de la spé i� ation de la plateforme réelle en termes de apteurs et d'a tionneurs.En rapport ave la terminologie MDA qui identi�e un modèle de la plateforme (PM : PlatformModel), SAIA identi�e le modèle des apteurs et des a tionneurs : le SAM (Sensors A tuatorsModel).

Fig. 3.1 � Les di�érents modèles dans SAIA3) La troisième ou he identi�ée permet aux deux modèles présentés pré édemment de spé- i�er un système omplet. Pour e faire, les opérations d'adaptation, de �ltrage et d'arbitrageidenti�ées dans les omposants � ontr�le� et � ontr�leur de dialogue� de PAC et de Seeheimfont partie des opérations né essaires. Ces opérations sont dé�nies par l'ALM (Adaptation LayerModel). D'un point de vue MDA, L'ALM peut être vu omme la spé i� ation du mapping quipermet de lier le PIM et le PM. Plus pré isément, 'est une adaptation de la plateforme réelledé�nie par le SAM a�n qu'elle orresponde dire tement à la plateforme abstraite dé�nie par lesentrées et les sorties du SAIM.3.1.2 Le onne teur omplexeL'ALM est la spé i� ation d'un onne teur omplexe qui réalise la liaison entre les interfa esdes omposants du SAM et elles des omposants du SAIM. Les entrées et les sorties du SAIMsont dé rites de manière abstraite alors que les pilotes des apteurs et des a tionneurs o�rent desservi es liés aux te hnologies, les �ots d'informations et les interfa es spé i�és par les uns et lesautres sont don , a priori, hétérogènes. Le but du onne teur omplexe est de spé i�er la �glue�permettant d'homogénéiser les �ots d'information entre le SAM et le SAIM.Le onne teur omplexe est omposé de sous onne teurs pouvant ommuniquer les uns ave les autres. Chaque sous onne teur est spé i�é par un omposant omposite dont le type est48

3.1. Le style ar hite tural SAIAspé i�que au type d'entrée ou de sortie auquel il est asso ié. Puisqu'un sous onne teur est un omposant omposite, sa �glue� est spé i�ée par un assemblage de omposants ( on�gurationinterne).SAIA identi�e trois types d'hétérogénéités entre les �ots d'informations spé i�és dans le SAIMet eux spé i�és dans le SAM.La première hétérogénéité on erne les valeurs spé i�ées par les �ots de données. Celles- ipeuvent être exprimées dans une autre unité, un autre repère, et . E�e tuer les onversionsné essaires à l'homogénéité des valeurs onstitue l'étape de formatage.La deuxième hétérogénéité est due à la di�éren e de niveau d'abstra tion des omposantsdu SAM et de eux du SAIM. Par exemple, le SAIM peut spé i�er l'entrée onsigne_Vitessedans la plateforme abstraite. Les valeurs du �ot de données spé i�ées par l'entrée sont don desvitesses. A�n de réaliser ette entrée sur une plateforme réelle, il est possible d'utiliser un joysti k.Les valeurs du �ot de données en sortie du pilote du joysti k sont des oordonnées. Passer d'une oordonnée à une vitesse (et éventuellement une rotation) onstitue une étape d'interprétationné essaire, programmable, mais non automatisable a priori.La troisième hétérogénéité on erne la QoS de ha un des �ots d'informations. Les tenantset aboutissants de ette sour e d'hétérogénéité sont dé rits plus en détails dans la suite de e hapitre.3.1.3 QoS et qualité de ontr�leLa séparation en trois modèles distin ts permet de réaliser une séparation fran he entre d'unepart l'appli ation et d'autre part les pilotes des apteurs et des a tionneurs d'une plateforme.Cependant, une appli ation de ontr�le de pro essus est sensible à plusieurs paramètres quiin�uen ent la qualité du ontr�le. La qualité de ontr�le est un ensemble de ontraintes expriméessur le pro essus en termes de stabilité ou de marges d'erreurs.Par exemple, pour un robot devant suivre une ligne sur le sol, une des ontraintes sur laqualité de ontr�le peut être que le robot ne doit pas dévier de la traje toire désirée de plus de1 m.La qualité de ontr�le d'une appli ation est fortement in�uen ée par les ara téristiquestemporelles on ernant l'a quisition des informations en provenan e du monde extérieur ainsi quesur la réalisation des a tions physiques sur le pro essus. SAIA propose de dériver les ontraintesde qualité de ontr�le en ontraintes temporelles sur les �ots d'informations en provenan e età destination de l'appli ation. Dans le SAIM, ela se traduit par une spé i� ation de la QoSsur la plateforme abstraite qui, lorsqu'elle est satisfaite, assure d'atteindre la qualité de ontr�lere her hée par l'appli ation.Une fois le SAIM et sa QoS spé i�és, il faut être apable de onne ter la plateforme abstraiteà une plateforme réelle en s'assurant que la QoS est satisfaite. Pour e faire, il est né essaire quela plateforme réelle réalise une des ription de la QoS. La QoS du SAM dé oule d'une évaluation49

Chapitre 3. SAIAde performan es des pilotes existants. La QoS dépend de l'ar hite ture des pilotes et du matériel( apteur, a tionneur) asso iés aux pilotes [13, 102℄. Les analyses ainsi e�e tuées permettentd'obtenir une des ription la QoS pour ha un des pilotes du SAM. Le but de ette étude étantde permettre l'établissement d'un ontrat de QoS entre le SAM et le SAIM, les travaux développésdans le adre de ette thèse présument que la des ription de la QoS du SAIM et du SAM estdisponible.3.1.4 Le ontrat de QoSLors de la onnexion du SAIM et du SAM, il est né essaire d'établir un ontrat de QoS( ontrat de niveau 4) pour garantir la orre tion de l'appli ation vis-à-vis de sa qualité de ontr�le.Ce i se traduit par l'établissement d'un ontrat de QoS entre ha une des entrées et des sortiesspé i�ées dans le SAIM et ha un des pilotes spé i�és dans le SAM. Ce ontrat doit exprimer sila relation de satisfa tion entre QoS requise et QoS fournie est véri�ée.L'établissement d'un ontrat de QoS est à la harge du onne teur omplexe. Cependant,nous avons vu que le onne teur omplexe est omposé de sous onne teurs possédant ha un une�glue� a�n de rendre homogènes les �ots d'informations entre le SAM et le SAIM. En modi�antles �ots d'informations, la �glue� modi�e également leur QoS, spé i�ée dans le SAM et dans leSAIM. Avant de pouvoir établir le ontrat de QoS, l'impa t de la �glue� sur la QoS est évaluépar la réalisation d'analyses temporelles.Pour assurer la faisabilité de es analyses, les omposants doivent posséder une sémantiqueopérationnelle formelle ainsi qu'une spé i� ation des informations temporelles pertinentes. Cesinformations temporelles re�ètent les durées d'exé ution des traitements réalisés ainsi que lestemps de blo ages induits par l'ordonnan ement des a tions.La des ription de la sémantique opérationnelle et des di�érents temps de traitements permetd'e�e tuer les analyses temporelles et don d'évaluer la QoS des �ots d'informations modi�és parla �glue� des sous onne teurs. Il est alors possible de véri�er si la onnexion entre le SAM et leSAIM donne lieu à l'établissement d'un ontrat ou non ( f. �gure 3.2).3.1.5 Niveau de des ription ar hite turaleIl est important de noter que l'utilisation du style ar hite tural SAIA amène à la onstru tiond'une ar hite ture logique. En e�et, une fois le système dé rit ave SAIA, seule la plateformede ommuni ation est dé�nie. La plateforme d'exé ution a été abstraite par des informationstemporelles sur les durées d'exé ution de ses traitements ainsi que par les temps de blo ages pos-siblement induits par l'ordonnan ement. Ces informations temporelles sont don des ontraintesdevant être respe tées lors de la mise en ÷uvre de l'ar hite ture : on parle de budgets temporels.Dé rire une ar hite ture logique permet d'e�e tuer une première analyse du système avantson implémentation et son déploiement sur une plateforme d'exé ution parti ulière. Ce i permetd'e�e tuer une première validation d'un système de ontr�le lors de la onnexion de la plateforme50

3.1. Le style ar hite tural SAIA

Fig. 3.2 � Gestion de la QoS dans SAIAabstraite ave la plateforme réelle. Cette première validation intervient avant le hoix d'uneplateforme d'exé ution. Elle est né essaire pour éviter d'obtenir, sur une plateforme spé i�que,une stru turation logique fournissant des omportements temporels non ohérents ave la QoS.On évite ainsi les allers-retours oûteux entre la stru turation logique et son implémentation.Raisonner sur une ar hite ture logique est intéressant ependant, lorsque la plateforme d'exé- ution est onnue, les di�érentes informations temporelles mesurées, telles que les durées d'exé- ution ou les temps de blo age, peuvent être renseignées dans SAIA sans remettre en ause lespossibilités d'analyses temporelles. Toutefois, il faut noter que SAIA ne spé i�e ni les types de omposants né essaires à la des ription de la plateforme d'exé ution, ni les éléments né essairesà la spé i� ation d'un modèle de tâ hes.3.1.6 SAIA et le langageL'expression d'un style ar hite tural né essite de faire le hoix d'un langage de des ription.Les avantages liés à l'utilisation de (méta-)modèles a�n de manipuler des on epts nous per-mettent de nous a�ran hir d'un langage de programmation parti ulier. Ainsi, SAIA dé rit lestyle ar hite tural au travers de di�érents méta-modèles. Pour des fa ilités d'outillages les méta-modèles sont exprimés dans une extension d'UML fournie par l'outil GME [62℄ ; et de ontraintesexprimées en OCL [96℄.Sur es bases, SAIA dé rit des types de omposants asso iés à di�érents modèles. Après51

Chapitre 3. SAIAavoir présenté le modèle à omposant utilisé, les di�érents types de omposants et les ontraintessur leurs asso iations sont détaillés dans les parties suivantes. Après la des ription des types de omposants, une des ription de la QoS, de son évaluation dans le onne teur omplexe et del'établissement du ontrat de QoS sont fournies.3.2 Les (méta-)modèles dans SAIA3.2.1 Le modèle à omposantAu delà d'un style ar hite tural et des prin ipes de stru turation qu'il propose, il est né essairede hoisir un modèle à omposant sur lequel appliquer le style. Le modèle à omposant retenu nedoit ni omporter de règles de stru turation impli ite ni posséder une sémantique opérationnellenon désirée. De plus, il est né essaire de posséder un modèle à omposant omprenant les on eptsde bases minimaux que l'on retrouve dans la majorité des modèles à omposant pour les systèmesvisés par l'étude :� des omposants primaires,� des omposants omposites,� des interfa es,� des onne teurs logiques.Pour es raisons nous avons basé le style ar hite tural sur un modèle ad-ho , basé sur UML etréalisé spé ialement pour SAIA.Dans le domaine visé, le modèle à omposant doit de plus posséder une sémantique opéra-tionnelle temporisée formelle. Un omposant dans SAIA possède un ou plusieurs servi e(s) dé ritspar un automate temporisé IF (Intermediate Format : [18℄). En e�et, parmi les langages existants,IF o�re l'avantage d'être formel, de permettre la programmation on urrente, d'être temporisé etégalement d'être outillé. De plus, l'exé ution d'un automate IF permet de réaliser une simulationexhaustive du omportement de l'automate dont le résultat est a essible sous forme de LTS (la-beled Transition System). Dans le modèle à omposant de SAIA, haque automate IF peut faireappel à une fon tion dont l'exé ution est ara térisée temporellement par un budget temporel.Ce budget temporel est lui-même ara térisé par un intervalle pré isant le temps minimum et letemps maximum imparti pour l'exé ution de la fon tion.Puisque la ommuni ation entre l'appli ation de ontr�le et le monde extérieur est ara -térisée par des �ots d'informations, haque omposant omporte des interfa es d'entrées et/oudes interfa es de sorties. Les interfa es d'entrées onsomment un �ot d'informations alors qu'uneinterfa e de sortie le produit. Plus pré isément, les interfa es d'entrées permettent à un �ot d'in-formations d'entrer dans un omposant pour y être traité. Ce i se traduit par l'appel à un servi efourni par le omposant en question. L'appel au servi e est don fait à haque nouvelle o urren edans le �ot d'entrée. À l'inverse, les interfa es de sortie permettent à un �ot d'informations desortir d'un omposant. Ce i se fait via l'appel à un servi e requis, dé�ni par un autre omposant.En ore une fois, l'appel se fait à haque nouvelle o urren e du �ot de sortie.A�n de ara tériser les o urren es, SAIA dé�nit deux types abstraits d'o urren es : T_ev-enttype, qui ara térise une o urren e d'un �ot d'événements, et T_datatype, qui ara térise52

3.2. Les (méta-)modèles dans SAIAune o urren e d'un �ot de données. Ils ontiennent respe tivement deux et trois hamps :� timestamp, qui représente la date du système à laquelle l'o urren e est réée.� initial_delay, qui représente le retard de l'o urren e lors de sa réation. Si l'o urren eest réée par le système, le retard initial est de 0. A ontrario, si l'o urren e est issue d'unpilote d'a quisition, e retard est le re�et du temps passé entre la le ture de l'informationpar le apteur physique et la réation de l'o urren e orrespondante par le pilote.Puisque T_datatype ontient des données, il ontient également la valeur de l'o urren e,notée o _value.Dans le modèle à omposant réalisé, à une interfa e orrespond un et un seul servi e. Ainsi,la liaison entre une interfa e de sortie et une interfa e d'entrée est possible uniquement lorsquele servi e requis par l'interfa e de sortie orrespond au servi e fourni par l'interfa e d'entrée.De plus, puisqu'à une interfa e ne orrespond qu'un et un seul servi e, alors à une interfa e ne orrespond qu'un et un seul �ot d'informations. Ce i permet de lier la des ription de la QoS d'un�ot à une interfa e.La sémantique opérationnelle des servi es, des onne teurs et des interfa es dans SAIA estfournie par la sémantique opérationnelle du langage IF. Ainsi, pour les servi es d'un omposant,l'exé ution des automates possède la sémantique opérationnelle des automates IF et l'exé utiondes fon tions possède la sémantique d'un temps d'attente dont la durée est spé i�ée par le budgettemporel asso ié à la fon tion. La ommuni ation entre deux omposants dont les interfa es sontreliées par un onne teur logique orrespond à une transmission d'o urren e et possède don lamême sémantique que l'envoi d'un message entre deux automates IF. La ommuni ation dansSAIA est don de type asyn hrone (émission sans attente).La ommuni ation d'une o urren e est à l'initiative du omposant produ teur via l'appel àun servi e du omposant onsommateur. La ommuni ation dans SAIA est don de type Push. Ce hoix est lassique lorsque l'on traite des �ots d'informations. De plus, il fa ilite la modélisationd'un système SAIA en IF. Cependant passer à une ommuni ation de type Pull, 'est-à-dire oùle traitement d'une o urren e d'un �ot est à l'initiative du omposant réalisant le traitementreste envisageable et ne remet pas en ause les possibilités d'analyses et/ou d'établissement de ontrat de QoS exprimés par la suite.En�n, lors d'un envoi de message en IF, elui- i est déposé dans une boîte aux lettres detype FIFO (First In First Out) en attendant d'être onsommé. Les interfa es de SAIA possèdentdon la sémantique d'une boîte aux lettres de type FIFO, ependant, nous �xons la taille de laFIFO à 1. Lorsqu'une information est déposée dans une boîte aux lettres non vide, l'informationpré édente est é rasée par la nouvelle information arrivée. Ce hoix permet de s'a�ran hir desproblèmes d'explosion des boîtes aux lettres dans le système. De plus, puisque l'on onsidèredes �ots d'informations à destination et en provenan e du monde extérieur pour ontr�ler unpro essus physique, ne onsidérer que la dernière o urren e d'une information semble logiquepour être réa tif plut�t que sto ker es informations dans une FIFO pour un traitement ultérieur.Toutefois, il omplique la modélisation d'un système SAIA en IF ar la taille de la boîte auxlettres d'un système IF ne peut pas, dans les outils existants, être hoisie. On s'assure don queles boîtes aux lettres peuvent être lues dans tous les états du système a�n de mettre à jour unevariable interne, représentative de l'information reçue. 53

Chapitre 3. SAIALe modèle à omposant utilisé dans SAIA est basé sur le paradigme de méta modélisation del'outil GME. Ce paradigme dé�nit les entités de bases dé rites pré édemment : les omposantsprimaires (appelés Atom dans l'outil), les omposants omposites (Model), les interfa es (Port) etles onne teurs logiques (Conne tion). De plus, au une sémantique opérationnelle n'est asso iée à es entités dans GME. Ce i nous a permis de dé�nir un modèle à omposant simple et ad-ho dontles on epts et la sémantique opérationnelle ont été dé�nis spé i�quement dans SAIA. Cependant,tous les modèles à omposant qui peuvent orrespondre aux ritères énon és pré édemmentpeuvent, de fait, appliquer le style ar hite tural dé rit dans ette thèse.Maintenant que les éléments prin ipaux du modèle à omposants sont présentés et que leursémantique opérationnelle est pré isée, les parties suivantes s'atta hent à la des ription des dif-férents types de omposants et de ontraintes dé�nis par le style ar hite tural proprement dit.3.2.2 Le modèle SAMLes types de omposants du SAM représentent les di�érents types de pilotes des apteurs et depilotes des a tionneurs. Ils dé rivent la vue d'une plateforme réelle en termes de ommuni ationave le monde extérieur.Nous appelons �pilote d'a quisition� un omposant qui produit un �ot d'informations à des-tination de l'appli ation en fon tion des �u tuations d'un ou de plusieurs apteur(s) via l'appelà une fon tion spé i�que du pilote. Parallèlement, nous appelons �pilote de réalisation� un om-posant qui reçoit un �ot d'informations en provenan e de l'appli ation pour faire �u tuer lesa tionneurs en onséquen e (toujours via l'appel à une fon tion spé i�que du pilote). Les pilotesne possèdent qu'une et une seule interfa e : les pilotes d'a quisition une interfa e de sortie, etles pilotes de réalisation une interfa e d'entrée. Dans ette étude, nous ne nous intéressons qu'aufon tionnement nominal des pilotes en supposant leur initialisation orre te. Nous di�éren ionségalement un omposant selon si le �ot d'informations qu'il manipule est un �ot de données ouun �ot d'événements.On distingue don au �nal quatre types de omposants dans le SAM, ha un de es types de omposants est dédié à l'a quisition ou à la réalisation d'un �ot de données ou d'événements :� les pilotes d'a quisition de données (driver_data),� les pilotes d'a quisition d'événements (driver_event),� les pilotes de réalisation de ommandes (driver_ md),� les pilotes de réalisation de ommande événementielles (driver_ md_event).En�n, ha une des interfa es des omposants du SAM est asso iée à une des ription de la QoS quilui est propre. Ces informations sont représentées d'une manière simpli�ée sur le méta modèlede la �gure 3.3. Sur ette �gure, et sur les suivantes, ≪ Model ≫ représente un omposant omposite. Au ontraire ≪ Atom ≫ représente un omposant primaire, pouvant ontenir desattributs mais ne pouvant pas être omposé d'autres omposants. ≪ Connection ≫ représenteun type de onne teur logique. Cha une de es entités peut être dé rite plus en détail dans unautre modèle. Elle est alors référen ée et estampillée ≪ xxxProxy ≫ où xxx représente le typed'entité référen ée. En�n, les attributs des omposants peuvent être de type field, auquel as ela représente un type abstrait quel onque, et de type enum, auquel as l'attribut peut prendreune des valeurs prédé�nies dans le métamodèle.54

3.2. Les (méta-)modèles dans SAIA

Fig. 3.3 � Métamodèle simpli�é représentant les di�érents types de pilotes3.2.2.1 Les pilotes d'a quisition de donnéesNotés driver_data, les pilotes d'a quisition de données fournissent une vue de l'évolutiond'une donnée physique au ours du temps. Pour ela, ils transforment les informations en prove-nan e d'un ou plusieurs apteur(s) en un �ot de données à destination de l'appli ation. Le pilote a he les détails d'a ès bas niveau au matériel (registre, bro hage, et .). Le �ot de données générépar le pilote d'a quisition de données peut indi�éremment être représentatif d'une Mesure enprovenan e de l'environnement ou du pro essus, où être représentatif d'une Consigne en prove-nan e d'un opérateur. Un pilote d'a quisition de données est ara térisé par le �ot de donnéesqu'il génère, lui même ara térisé par :� son nom, représenté par une haîne informelle de ara tères,� son unité, 'est-à-dire la grandeur hoisie omme référen e pour mesurer la valeur deso urren es (data_unity),� son type, 'est-à-dire la représentation informatique de ha une des o urren es (integer,�oat, stru t, et .) (type_representation),� ses valeurs minimum et maximum, 'est-à-dire les valeurs bornant ha une des o urren es(min_value max_value),� sa valeur initiale, 'est-à-dire la valeur de la première o urren e dans le �ot (initial_value),� sa QoS, la QoS est présentée en détail dans le hapitre 3.3. 55

Chapitre 3. SAIALe pilote est également omposé d'une entité T_datatype permettant de sto ker l'o ur-ren e ourante du �ot de données. Cette o urren e est véhi ulée au travers d'une interfa eo_NewDriverData. Cette interfa e est spé i�ée temporellement par une entité de type QoS_dataqui lui est asso iée via un onne teur logique de type spe i�es.A�n de permettre au �ot de données généré d'être onsommé, les omposants de e typerequièrent le servi e :� NewDriverData(T_datatype) //mise à jour d'une donnée en provenan e d'un piloteÀ titre d'illustration, le métamodèle simpli�é d'un pilote d'a quisition de données est donné�gure 3.4. Les métamodèles des autres pilotes sont onstruits de la même manière que elui- iet, de e fait, ne sont pas présentés.

Fig. 3.4 � Métamodèle simpli�é d'un pilote d'a quisition de données3.2.2.2 Les pilotes d'a quisition d'événementsNotés driver_event, les pilotes d'a quisition d'événements sont semblables aux pilotes d'a -quisition de données au détail près qu'ils fournissent une vue de l'évolution du hangement d'unétat physique au ours du temps plut�t que d'une valeur physique. De e fait, au une valeurn'est dé�nie sur le �ot d'événements qui est uniquement ara térisé par :� son nom, représenté par une haîne de ara tères informelle,� sa QoS, la QoS est présentée en détail dans le hapitre 3.3.A�n de permettre au �ot d'événement généré d'être onsommé, les omposants de e typerequièrent le servi e :56

3.2. Les (méta-)modèles dans SAIA� NewDriverEvent(T_eventtype) //arrivée d'un nouvel événement en provenan e d'un pilote3.2.2.3 Les pilotes de réalisation de ommandesNotés driver_ md, les pilotes de réalisation de ommandes réalisent des a tions pouvant êtreparamétrées par une valeur dans le but de ontr�ler le pro essus. Pour ela, ils onsommentun �ot de données dont haque o urren e est une Commande en provenan e du système. Ilstransforment alors e �ot de données en a tion sur le pro essus. En ore une fois le pilote estutilisé pour a her les détails d'a ès bas niveau au matériel (registre, bro hage, et .).Le �ot de données, représentatif des Commandes du système sur le pro essus est ara tériséde la même manière que le �ot de donnée d'un pilote d'a quisition de données. Contrairement auxpilotes d'a quisition qui possèdent une interfa e de sortie, les pilotes de réalisation de ommandespossèdent une interfa e d'entrée. À ette interfa e d'entrée est liée une des ription de la QoS du�ot onsommé. Chaque o urren e de e �ot est onsommée via l'appel au servi e fourni :� NewDriverCmd(T_datatype) // mise à jour d'une ommande dans la plateforme réelle.3.2.2.4 Les pilotes de réalisation de ommandes événementiellesNotés (driver_ md_event), les pilotes de réalisation de ommandes événementielles réalisentune a tion mé anique non paramétrable dans le but de ontr�ler le pro essus. Ils possèdent don les mêmes ara téristiques que les pilotes de réalisation de ommandes mis à part qu'ils on-somment un �ot d'événements dont haque o urren e est une Commande événementielle enprovenan e du système. De e fait, le �ot d'événements représentant les Commandes événemen-tielles est ara térisé de la même manière que les �ots d'évènements des pilotes d'a quisitionsd'événements.Pour onsommer le �ot d'événements, les omposants de e type fournissent le servi e :� NewDriverCmdEvent(T_eventtype) // arrivée d'un nouvelle ommande événementielle dans laplateforme réelle.3.2.2.5 Le SAM et la qualité de servi eNous avons vu dans le hapitre ontexte ( hapitre 2.1) que la QoS desMesures, des Consigneset des Commandes in�ue sur la stabilité et la qualité de ontr�le du système. Ainsi haque typede omposant du SAM doit dé rire la QoS qui ara térise son �ot d'informations en termes deloi d'arrivée et de loi de retard sur l'a quisition ou la réalisation des o urren es du �ot.Cha une des ara téristiques de QoS spé i�ées par un omposant peut être soit du typerequise, soit du type fournie. Ce paragraphe dis ute du type des ara téristiques de QoS dans leSAM. 57

Chapitre 3. SAIALes pilotes d'a quisition produisent un �ot d'informations, ils génèrent don les o urren esdu �ot. De e fait, ils sont responsables de la loi d'arrivée du �ot qu'ils produisent : la loid'arrivée est don une ara téristique de QoS fournie. De même, le temps é oulé entre le momentoù l'information est vraie dans le monde extérieur et le moment de sa présen e en sortie despilotes d'a quisition est fon tion du apteur et de l'ar hite ture des pilotes. La loi de retard estdon également une ara téristique de QoS fournie par les pilotes d'a quisition.Les pilotes de réalisation onsomment un �ot d'informations pour réaliser des a tions surle pro essus. Un pilote de réalisation possède des restri tions sur le �ot qu'il onsomme. La loid'arrivée fait partie de es restri tions ar le pilote de réalisation possède un temps minimumné essaire à la réalisation d'une a tion. Il est parfois né essaire de ne pas envoyer une nouvelle ommande avant la �n de la réalisation de la pré édente a�n de ne pas détériorer l'a tionneur. Unpilote de réalisation doit don spé i�er la loi d'arrivée requise pour un fon tionnement orre t.Parallèlement à ela, le temps dans lequel l'a tion va être réalisée par le pilote de réalisa-tion est une information ara térisant le pilote de réalisation. Cette information, puisqu'elle estdépendante du pilote, est une spé i� ation de la loi de retard fournie par le pilote de réalisation.À part la loi d'arrivée des pilotes de réalisation qui est une ara téristique de QoS requise, les ara téristiques de QoS des types de omposants du SAM sont de la QoS fournie. La des riptionformelle de la QoS et de es ara téristiques est donnée plus en détails dans le hapitre 3.3.3.2.2.6 Con lusion sur le SAMLe SAM est un modèle de la plateforme réelle. À e titre il modélise les servi es de la plate-forme a essibles en boîte grise via ses interfa es. Il est ainsi possible d'utiliser les servi es despilotes sans onnaissan e des mé anismes internes de eux- i.Puisque les servi es de la plateforme sont utilisés sans onnaissan e de la manière dont ilssont réalisés, la plateforme peut être réelle ou au ontraire peut représenter les servi es de om-muni ation fournis par un simulateur. De ette manière, une ible réelle et une ible simulée sontmodélisées à l'identique et sont a essibles via les mêmes servi es.Quelque soit la ible représentée, une des ription de la QoS fournie et requise par les types de omposants du SAM est né essaire pour l'établissement d'un ontrat de QoS entre la plateformeréelle du SAM et la plateforme abstraite ontenue dans le SAIM dont la des ription est l'objetde la se tion suivante.3.2.3 Le modèle SAIMLe modèle SAIM est omposé de types de omposants représentants d'un �té l'appli ationde ontr�le et de l'autre la plateforme abstraite ara térisant les besoins de ommuni ation entrel'appli ation de ontr�le et le monde extérieur.58

3.2. Les (méta-)modèles dans SAIAL'appli ation de ontr�le représente le noyau métier du système. C'est elle qui est en hargedu al ul des Commandes né essaires pour ontr�ler le pro essus en fon tion des Mesures et desConsignes qu'elle reçoit. Au une attention parti ulière n'est portée sur l'appli ation de ontr�ledans ette thèse. Elle est simplement représentée par un omposant a édant à la plateformeabstraite par l'intermédiaire des servi es suivants :Servi es fournis par l'appli ation de ontr�le� SetSoftData(T_datatype) //mise à jour d'une donnée dans l'appli ation� NewSoftEvent(T_eventtype) //arrivée d'un nouvel événement dans l'appli ationServi es requis par l'appli ation de ontr�le� SetCmd(T_datatype) //mise à jour d'une ommande par l'appli ation� NewEventCmd(T_eventtype) //produ tion d'une nouvelle ommande événementielle par l'ap-pli ation.En e�et, le but étant de séparer les besoins de ommuni ation de l'appli ation (la plateformeabstraite) ave les moyens réels de ommuni ation ave le monde extérieur fourni par une plate-forme réelle (spé i�és par les pilotes), on se on entre, dans le SAIM, sur la dé�nition de laplateforme abstraite.La plateforme abstraite est dé�nie par un ensemble d'entrées et de sorties. Les entrées spé i-�ent l'ensemble des Mesures et des Consignes utiles à l'appli ation pour e�e tuer le ontr�le. Lessorties, quant à elles, spé i�ent les Commandes générées par l'appli ation a�n de modi�er l'étatdu pro essus. Cha une des entrées et des sorties est également di�éren iée selon qu'elle spé i�eun �ot de données ou d'événements. On distingue don quatre types de omposant di�érentsdans la plateforme abstraite : les données (data), les événements (event), les ommandes ( md)et les ommandes événementielles (event_ md). Ces quatre types de omposant sont représentéssur le métamodèle simpli�é de la �gure 3.5.Les deux parties suivantes dé rivent la plateforme abstraite et les types de omposants in-tervenant dans sa spé i� ation. Pour e faire, nous ommençons par la des riptions des entréesavant de poursuivre ave les sorties.3.2.3.1 Les entréesUne entrée est une vue abstraite du monde extérieur. Le mot �abstrait� re�ète le fait que laspé i� ation d'une entrée revient à spé i�er dire tement l'élément physique qui est d'intérêt pourl'appli ation. Par exemple, une appli ation de ontr�le d'un robot explorateur a de fortes han esde posséder l'entrée 'Position'. 'Position' est une valeur physique du pro essus. Elle représenteun besoin de l'appli ation quant à sa vue du monde extérieur. Cependant, elle ne spé i�e pasla te hnologie qui est utilisée pour l'a quisition de la valeur physique (GPS, en odeur de roue,et .).Il est important de ne spé i�er au un aspe t te hnologique lors de la des ription des entréesa�n de ne pas rendre la plateforme abstraite dépendante d'une te hnologie parti ulière.Pour ara tériser les entrées, omme pour les pilotes du SAM, on di�éren ie les élémentsphysiques ara térisés par un �ot de données de eux ara térisés par un �ot d'événements. Ils59

Chapitre 3. SAIA

Fig. 3.5 � Métamodèle simpli�é représentant les di�érents types de omposant de la plateformeabstraitesont respe tivement nommés 'donnée' et 'événement '. Chaque entrée est en harge d'un et d'unseul �ot d'informations. Une entrée ne possède don qu'une interfa e d'entrée et qu'une interfa ede sortie.On réalise également une autre distin tion entre les entrées vis-à-vis de leur r�le (data_role etevent_role, �gure 3.5). Une entrée, qu'elle soit du type donnée ou événement peut être soit uneMesure, soit une Consigne. Cette distin tion permet de di�éren ier les Mesures qui représententl'état a tuel de l'environnement ou du pro essus, et les Consignes qui représentent l'état dupro essus désiré par l'opérateur. Cette distin tion est faite uniquement dans le SAIM ar ellere�ète une di�éren e appli ative. Cette di�éren e n'intervient pas dans le SAM ar les Consigneset les Mesures peuvent provenir du même type de apteurs.3.2.3.1.1 Les données Une donnée est la spé i� ation de l'évolution d'une valeur physiqueau ours du temps. Pour ela une donnée spé i�e un �ot de données en entrée de l'appli ation.Le �ot de données représenté par une donnée est ara térisé de la même manière que les �ots dedonnées des pilotes d'a quisition à laquelle on ajoute :� son r�le, 'est-à-dire Mesure ou Consigne (data_role).Le type de omposant représentant les données dans SAIA est noté data. Son métamodèleest présenté �gure 3.6. Une donnée possède une interfa e d'entrée i_SetData dont la spé i� a-tion temporelle du �ot qu'elle onsomme est fournie par une entité de type QoS_data. Chaque60

3.2. Les (méta-)modèles dans SAIAo urren e est onsommée via l'appel au servi e fourni :� SetData(T_datatype) //mise à jour de la donnée dans la plateforme abstraiteL'appel à e servi e permet de mettre à jour les informations sur l'o urren e, ontenue dansl'entité T_datatype. En�n, les omposants de types donnée requièrent le servi e :� SetSoftData(T_datatype) //mise à jour de la donnée dans l'appli ationa�n de permettre au �ot de données d'être onsommé par l'appli ation de ontr�le.

Fig. 3.6 � Métamodèle d'une donnée3.2.3.1.2 Les événements Un événement, noté Event dans SAIA, est la spé i� ation del'évolution du hangement d'un état physique. Pour ela un événement spé i�e un �ot d'événe-ments en entrée de l'appli ation.Un événement fournit le servi e :� NewEvent(T_eventtype) //arrivé d'un nouvel événement dans la plateforme abstraiteet requiert le servi e :� NewSoftEvent(T_eventtype) //arrivé d'un nouvel événement dans l'appli ationLe hangement de l'état physique spé i�é par un événement est fon tionnellement ara tériséde la même manière qu'un pilote d'a quisition d'événements à laquelle on ajoute :� son r�le, 'est-à-dire Mesure ou Consigne (event_role).3.2.3.2 Les sortiesUne sortie est une a tion abstraite sur le pro essus. Spé i�er une sortie abstraite revient àspé i�er dire tement la �nalité de l'a tion que l'appli ation doit entreprendre sur le pro essus.Il est important que ette a tion soit spé i�ée de manière à re�éter la �nalité sur le pro essusplut�t que l'a tion en elle même pour éviter la spé i� ation d'aspe ts liés à une te hnologiedonnée. Par exemple, pour une appli ation de ontr�le d'un robot explorateur, il est tentant despé i�er une sortie du type �freiner�. Cette a tion suggère la présen e de frein, pourtant la�nalité pour l'appli ation est soit de ralentir le pro essus, soit de l'arrêter. On spé i�e alors lessorties �ralentir� et/ou �stopper� plut�t que �freiner�. 61

Chapitre 3. SAIAComme pour les entrées, il est important de ne pas spé i�er d'aspe ts te hnologiques lorsde la spé i� ation des sorties a�n de pouvoir ajuster les sorties de la plateforme abstraite surun maximum de pilotes de réalisation di�érents et don un maximum de plateformes réellesdi�érentes.Il existe deux types de sortie di�érents, elles spé i�ant un �ot de données et elles spé i�antun �ot d'événements. Elles sont respe tivement nommées ommande et ommande événemen-tielle. Chaque sortie est en harge d'un et un seul �ot d'informations. Une sortie possède don une seule interfa e d'entrée et une seule interfa e de sortie.3.2.3.2.1 Les ommandes Une ommande, notée md dans SAIA, est la spé i� ation d'unea tion sur le pro essus pouvant être paramétrée par une valeur. De e fait une ommande spé i�eun �ot de données en sortie de l'appli ation.Une ommande fournit le servi e :� SetCmd(T_datatype) //mise à jour d'une ommande par l'appli ationet requiert le servi e :� NewSoftCmd(T_datatype) //mise à jour d'une ommande dans le onne teur omplexePuisque les ommandes représente un �ot de données en sortie de l'appli ation et à destinationdu pro essus, leur �ot est ara térisé de la même manière que elui d'un pilote de réalisation de ommandes.3.2.3.2.2 Les ommandes événementielles Une ommande événementielle est la spé i�- ation d'une a tion non paramétrable sur le pro essus. De e fait une ommande événementiellespé i�e un �ot d'événements en sortie de l'appli ation.Une ommande événementielle fournit le servi e :� NewEventCmd(T_eventtype) //produ tion d'une nouvelle ommande événementielle par l'ap-pli ation .et requiert le servi e :� NewSoftEventCmd(T_eventtype) //arrivée d'une ommande événementielle dans le onne teur omplexeLe type de omposants représentant les ommandes événementielles dans SAIA est notéevent_ md.3.2.3.3 Le SAIM et la QoSA�n de développer une appli ation de ontr�le de pro essus en se basant sur la des riptiond'une plateforme abstraite, il est né essaire de ara tériser la QoS des �ots d'informations sur lesentrées et les sorties garantissant la stabilité du système et/ou la qualité de ontr�le re her hée.Comme pour le SAM, haque ara téristique de QoS peut être requise ou fournie.Les entrées spé i�ent un �ot d'informations à destination du système. Ce �ot est don on-sommé par l'appli ation. Chaque entrée doit fournir une ara térisation du �ot d'informations62

3.2. Les (méta-)modèles dans SAIAreprésentant la vue souhaitée du monde extérieur en termes de loi d'arrivée et de loi de retardsur l'a quisition des informations. Cette spé i� ation est une exigen e de l'appli ation et dé�nitdon la QoS requise sur les entrées pour garantir la stabilité du système.Les sorties produisent un �ot d'informations. Ce �ot est produit par l'appli ation. La loid'arrivée est don fon tion de l'appli ation. De e fait, une sortie doit spé i�er la loi d'arrivée entant que QoS fournie.Toujours pour les sorties, la loi de retard est la loi représentant les temps é oulés entre lemoment où l'o urren e d'une Commande est générée et le moment où l'a tion orrespondante surle pro essus est onsidérée omme réalisée. Lorsque l'o urren e d'une Commande est générée,son retard est don égal à 0. Le retard est prin ipalement fon tion de l'a tionneur réalisantl'a tion ainsi que du pro essus re evant l'a tion. Ce temps n'est pas fon tion de la manière dontest généré le �ot d'informations des sorties. C'est une exigen e de la plateforme abstraite àrespe ter par la plateforme réelle. La loi de retard sur les sorties est don spé i�ée en tant queQoS requise.On voit don que pour ha une des ara téristiques de QoS fournie dans le SAIM, on trouve la ara téristique de QoS requise orrespondante dans le SAM et inversement. Ainsi, il est possiblede gérer la satisfa tion entre la QoS requise et la QoS fournie. La satisfa tion fait l'objet del'établissement d'un ontrat de QoS réalisé par le onne teur omplexe.A�n de permettre de onne ter la plateforme abstraite à un maximum de plateforme réelle,la QoS doit garantir la orre tion du système mais en dé rivant la QoS de la manière la pluspermissive possible.3.2.3.4 Con lusion sur le SAIMLe SAIM omprend des omposants de types appli ation, entrées et sorties. Les omposantsde types entrées et sorties servent d'interfa es de ommuni ation entre l'appli ation et le mondeextérieur. Ils fournissent et requièrent un ensemble de servi es qui spé i�ent une plateforme demanière abstraite. La mise en pla e de l'appli ation de ontr�le se base alors sur ette plateformeabstraite plut�t que sur une plateforme réelle. Ainsi, l'appli ation de ontr�le n'est pas dépen-dante des moyens te hnologiques grâ e auxquels la ommuni ation ave le monde extérieur este�e tivement réalisée.A�n d'obtenir une spé i� ation omplète de la plateforme abstraite, une spé i� ation dela QoS requise et fournie par ette plateforme abstraite est né essaire. Sans ette spé i� ationextra-fon tionnelle, la onnexion de la plateforme abstraite et de la plateforme réelle ne peutpas garantir la orre tion de l'appli ation de ontr�le en termes de stabilité et/ou de qualité de ontr�le.Les entrées et les sorties ne peuvent pas être dire tement liées aux pilotes du SAM. D'unepart les servi es ne sont pas identiques et d'autre part il est rare de pouvoir a quérir dire tementun élément physique parti ulier à l'aide d'un pilote d'a quisition ou de pouvoir réaliser la �nalitéd'une a tion physique parti ulière de manière dire te par un pilote de réalisation ; plusieurs63

Chapitre 3. SAIAopérations d'adaptation sont alors né essaires. Ces adaptations sont réalisées par la �glue� du onne teur omplexe dé rit dans la se tion suivante.3.2.4 Le onne teur omplexeLe onne teur omplexe est formé d'un ensemble de sous onne teurs. Cha un d'eux est un omposant omposite, en harge des adaptations et mettant en relation soit des entrées ave despilotes d'a quisition ; soit des sorties ave des pilotes de réalisation. De plus, les sous onne teurspeuvent ommuniquer entre eux si né essaire a�n de béné� ier des adaptations réalisées par lesautres.A�n de rester homogène ave la des ription de la plateforme abstraite et réelle, les omposantsd'adaptation sont di�éren iés selon qu'ils produisent un �ot de données ou un �ot d'événements.A�n de garder la di�éren e entre données et événements, un omposant d'adaptation est dédié àla produ tion d'un type de �ot parti ulier en sortie. Il peut ependant onsommer indi�éremmentun �ot de données ou d'événements en entrée. Le r�le d'un sous onne teur est :� soit de prendre un ou plusieurs �ots d'informations en provenan e des pilotes d'a quisitionet/ou d'autres sous onne teurs pour onstruire un ou plusieurs �ots d'informations àdestination des entrées ;� soit de prendre un ou plusieurs �ots d'information en provenan e des sorties et/ou d'autressous onne teurs pour onstruire un ou plusieurs �ots d'informations à destination despilotes de réalisation.Pour e faire, haque onne teur possède une �glue� spé i�ée par une on�guration de om-posants. L'ensemble des onne teurs et de leur �glue� est spé i�é par l'ALM (Adaptation LayerModel).Les pro haine partie présente les di�érents types de sous onne teurs orrespondant aux diverstypes d'entrées et de sorties. Ensuite, la partie suivante dé rit les ontraintes sur la stru turationdes sous onne teurs. En�n, les types de omposants spé i�ant la �glue� de ha un des sous onne teurs sont présentés.3.2.4.1 Les types de omposants de l'ALMSAIA distingue quatre types prin ipaux de omposants pour dé�nir la plateforme abstraitedans le SAIM : les données, les événements, les ommandes et les ommandes événementielles.Cha un de es types de omposants possède un type parti ulier de omposant dans l'ALM. Ces omposants sont appelés omposants d'adaptation (AE : Adaptation Element). On di�éren iedon quatre types de omposants d'adaptations :Les omposants d'adaptation d'entrées� les omposants d'adaptation de données (DAE : Data Adaptation Element),� les omposants d'adaptation d'événements (EAE : Event Adaptation Element),Les omposants d'adaptation de sorties� les omposants d'adaptation de ommandes (CAE : Command Adaptation Element),64

3.2. Les (méta-)modèles dans SAIA� les omposants d'adaptation de ommandes événementielles (ECAE : Event CommandAdaptation Element),3.2.4.1.1 Les omposants d'adaptation d'entrées Ils possèdent au minimum une inter-fa e d'entrée. Cette interfa e peut onsommer un �ot d'événements ou de données en provenan ed'un pilote d'a quisition ou d'un autre omposant d'adaptation. Ils onsomment les �ots d'in-formations en provenan e des pilotes d'a quisition en fournissant les servi es suivants :� NewDriverData(T_datatype) //mise à jour d'une donnée en provenan e d'un pilote� NewDriverEvent(T_eventtype) //arrivée d'un nouvel événement en provenan e d'un piloteParallèlement, ils onsomment les �ots en provenan e des autres omposants d'adaptation enfournissant les servi es suivants :� NewAEData(T_datatype) //mise à jour d'une donnée en provenan e d'un sous onne teur d'en-trée� NewAEEvent(T_eventtype) //arrivée d'un nouvel événement en provenan e d'un sous on-ne teur d'entrée� NewAECmd(T_datatype) //mise à jour d'une donnée en provenan e d'un sous onne teur desortie� NewAECmdEvent(T_eventtype) //arrivée d'un nouvel événement en provenan e d'un sous on-ne teur de sortieCha un des omposants d'adaptation d'entrée peut être en harge de l'a quisition d'une ouplusieurs entrées, il peut dont posséder une ou plusieurs interfa es de sorties. Les omposantsd'adaptation de données requièrent don le servi e suivant :� SetData(T_datatype) //mise à jour de la donnée dans la plateforme abstraiteet les omposants d'adaptation d'événements requièrent le servi e suivant :� NewEvent(T_eventtype) //arrivée d'un nouvel événement dans la plateforme abstraiteToujours à propos des servi es requis, il faut noter que seuls les omposants d'adaptationd'événements (EAE) peuvent produire des événements. Ainsi seuls les EAE requièrent le ser-vi e NewAEEvent. De la même façon, seuls les omposants d'adaptation de données (DAE) re-quièrent le servi e NewAEData. Ils fournissent ependant tous deux les servi es NewDriverData,NewDriverEvent, NewAEData, NewAEEvent, NewAECmd et NewAECmdEvent ar un EAE peut on-struire un �ot d'événements à partir d'un ou plusieurs �ot(s) de données et inversement pour unDAE.3.2.4.1.2 Les omposants d'adaptation de sorties Ils possèdent les même ara téris-tiques que les omposants d'adaptation d'entrées à la di�éren e prêt qu'ils onsomment les �otsd'informations en provenan e des omposants de type sortie du SAIM. Pour ela ils peuventfournir les servi es suivants :� NewSoftCmd(T_datatype) //mise à jour d'une ommande dans le onne teur omplexe� NewSoftEventCmd(T_eventtype) //arrivée d'une ommande événementielle dans le onne teur omplexeIls peuvent également onsommer les �ots d'informations en provenan e des autres om-posants d'adaptation de sortie en fournissant les servi es :� NewAECmd(T_datatype) //mise à jour d'une donnée en provenan e d'un sous onne teur desortie 65

Chapitre 3. SAIA� NewAECmdEvent(T_eventtype) //arrivée d'un nouvel événement en provenan e d'un sous on-ne teur de sortieLes omposants d'adaptation de sorties peuvent posséder une ou plusieurs interfa es de sortievia lesquelles, après adaptation, ils fournissent des �ots d'informations à destination des pilotesde réalisation. Les omposants d'adaptation de ommande requièrent don le servi e :� NewDriverCmd(T_datatype) // mise à jour d'une ommande dans la plateforme réelle.et les omposants d'adaptation de ommande événementielle requièrent le servi e :� NewDriverCmdEvent(T_eventtype) //arrivée d'un nouvelle ommande événementielle dans laplateforme réelle.Comme pour les omposants d'adaptation d'entrées, seuls les CAE peuvent produire des ommandes pour les drivers de réalisation et don seuls les CAE requièrent le servi e NewAECmd.De la même manière, seuls les ECAE requièrent le servi e NewAECmdEvent.Remarque : Les omposants du SAM et du SAIM possèdent un nombre d'interfa es imposé :une interfa e de sortie pour un pilote d'a quisition, une d'entrée et une de sortie pour les Entréeset les Sorties du SAIM, et . Ces ontraintes sont imposées par la spé i� ation des arités entrele type de omposant et ses interfa es. De plus, le type de ha une des interfa es est égalementimposé. Au ontraire, les sous onne teurs peuvent posséder plusieurs interfa es d'entrée, deplusieurs types. Il est pourtant né essaire de spé i�er que haque sous onne teur possède auminimum une interfa e d'entrée. Cette ontrainte ne peut pas être imposée par la spé i� ationdes arités puisque haque interfa e, prise à part peut intervenir zéro fois ou plus. Pour e type de ontrainte, l'ajout d'une ontrainte OCL est alors né essaire. La �gure 3.7 illustre ette ontrainte,pla ée dans le métamodèle sur les omposants d'adaptation d'entrée.

Fig. 3.7 � Une ontrainte OCL pour assurer que les omposants d'adaptation d'entrée possèdentau minimum une interfa e d'entrée.66

3.2. Les (méta-)modèles dans SAIA3.2.4.1.3 Les interfa es de on�guration Les omposants d'adaptation peuvent né es-siter la des ription d'une ou de plusieurs onstante(s) de on�guration. On peut iter, par exem-ple, la réalisation de patron de on eption �observer �. Un �observer � surveille un �ot de donnéeset produit un événement sur une ondition parti ulière des o urren es du �ot omme, par exem-ple, lorsqu'une donnée dépasse un seuil prédé�ni. Ce seuil, s'il n'est pas variable, est expli itementspé i�é dans SAIA par une information de type onstante. Ce i permet de rendre expli ite er-taines onstantes de on�guration qui introduisent un point de variabilité dans le omportementd'un sous onne teur. A�n d'être onsultée par les sous onne teurs, eux- i peuvent posséderune ou plusieurs interfa es d'entrée de type :� AE_ onfig3.2.4.1.4 Contraintes stru turelles Les ontraintes de stru turation permettent d'imposer ertaines règles sans lesquelles la des ription de la on�guration est erronée. Dans SAIA, es ontraintes ont trois obje tifs prin ipaux :1. réaliser les ontrats de niveau 1 ;2. imposer la fusion expli ite des �ots d'informations ;3. interdire de � ourt- ir uiter� le SAIM.Cha un de es obje tifs et les ontraintes asso iées sont expliquées par la suite.1) Le premier type de ontraintes de stru turation permet de réaliser les ontrats de niveau1. Pour ela, elles doivent interdire la liaison entre des interfa es dont les servi es sont di�érents.Étant donné le nombre limité de servi es identi�és dans SAIA, on rée un type d'interfa ed'entrée et un type d'interfa e de sortie par servi e. Ainsi, dans le métamodèle, on ne permet laliaison qu'entre les interfa es d'entrée et de sortie se référant au même servi e. On obtient ainsile métamodèle de la �gure 3.8 auquel nous avons superposé un s héma des omposants a�n demontrer la stru ture adoptée.2) De plus, sur le métamodèle de la �gure 3.8, on exprime les arités a eptables entre ha une des interfa es fournies et ha une de elles requises. Ainsi, une interfa e d'entrée ne peutêtre onne tée qu'à une et une seule interfa e de sortie. La onnexion d'une interfa e d'entrée àplusieurs interfa es de sorties reviendrait à fusionner impli itement plusieurs �ots d'informations.Dans SAIA, la fusion de di�érents �ots d'informations doit être expli ite et réalisée par la �glue�des omposants d'adaptation ar réaliser des fusions impli ites ne permet pas d'établir les règlesde fusion permettant de maîtriser la QoS ara térisant le �ot résultant de la fusion ( f. se tion3.3.3). De plus, pour les pilotes de réalisation, n'a epter qu'un seul �ot en entrée permet despé i�er, au sein des omposants d'adaptation de sortie (CAE et ECAE), les a ès on urrentsaux pilotes de réalisation et don aux a tionneurs.Les ontraintes imposant la fusion expli ite de �ots sont illustrées sur la �gure 3.9 en prenantle as des �ots d'informations en entrée du système.Malgré la ontrainte pré édente, les onnexions point à point ne sont pas les seules a eptablesdans SAIA. Comme les montre les arités de la �gure 3.8, une interfa e de sortie peut être67

Chapitre 3. SAIA

Fig. 3.8 � Métamodèle établissant la stru turation et les arités entre les interfa es dans SAIAreliée à une ou plusieurs interfa es d'entrée. Ce omportement orrespond à un broad ast du �otd'informations depuis une interfa e de sortie vers toutes les interfa es d'entrées auxquelles elleest onne tée. Comme nous avons vu que la ommuni ation d'un �ot d'informations se fait parl'appel au servi e du omposant onsommateur du �ot, le broad ast est don e�e tué par une suitede n appels aux servi es des n omposants asso iés. De e fait, un ordre de pré éden e apparaîtet il est don né essaire de pré iser dans quel ordre les �ots d'informations sont ommuniqués.

Fig. 3.9 � Exemple de stru turations orre tes et erronées dans SAIA3) La dernière ontrainte de stru turation interdit aux omposants d'adaptation de sortiede posséder les interfa es d'entrées et les servi es leurs permettant de re evoir les �ots d'in-formations des omposants d'adaptation d'entrée. Pourtant il est possible pour les omposants68

3.2. Les (méta-)modèles dans SAIAd'adaptation d'entrée de posséder les interfa es et les servi es leurs permettant de re evoir les�ots d'informations des omposants de sortie. Il est en e�et possible d'e�e tuer une bou le ou-verte des omposants d'adaptation de sortie vers les omposants d'adaptation d'entrées a�nd'estimer une entrée d'après les Commandes envoyées au pro essus. Cependant, l'inverse re-vient à ourt- ir uiter l'appli ation de ontr�le. En e�et, envoyer les �ots d'informations des omposants d'adaptation d'entrée vers les omposants d'adaptation de sortie implique que esderniers possèdent une partie appli ative spé i�ant quelles sont les Commandes à envoyer aupro essus en fon tion des informations en provenan e du monde extérieur. Cette partie appli a-tive doit impérativement être réalisée dans l'appli ation de ontr�le a�n de ne pas être omiselors de la réutilisation du SAIM.Cha un des types de omposant d'adaptation est un omposant omposite possédant une�glue� a�n de réaliser l'adaptation. Cette �glue� est réalisée par une on�guration omprenanttrois types de omposants primaires détaillés dans la partie suivante.3.2.4.2 Spé i� ation de la �glue�La �glue� des onne teurs d'adaptation permet de onne ter les interfa es des pilotes du SAMave les interfa es des entrées et des sorties du SAIM malgré leurs aspe ts hétérogènes. DansSAIA, on distingue trois prin ipales sour es d'hétérogénéité, adressées ha une par un type de omposant parti ulier. Ces types de omposants parti uliers sont ensuite onne tés entre euxa�n d'obtenir la �glue� désirée.Les paragraphes suivants détaillent les sour es d'hétérogénéité ainsi que les types de om-posants asso iés :� Format : en harge de l'hétérogénéité de types / d'unités� Interpret : en harge de l'hétérogénéité sémantique� QoS_adapt : en harge de l'hétérogénéité de qualité de servi e.3.2.4.2.1 Adaptation de types / unitésLa première sour e d'hétérogénéité on erne les unités et/ou les types de représentationinformatique d'une o urren e dans un �ot. Puisque les unités et les types ne sont pas dé�nisdans un �ot d'événements, ette hétérogénéité ne on erne que les �ots de données. Ce typed'hétérogénéité peut intervenir dans deux as :� lorsque les unités et/ou les types des o urren es d'un �ot de données en entrée d'un onne teur sont di�érents de la spé i� ation des o urren es du �ot de données en sortiedu onne teur.� lorsque l'on désire fusionner deux ou plusieurs �ots de données dont les unités et/ou lestypes des o urren es des �ots sont di�érents.Les hangements d'unité ou de type né essaires à une manipulation ohérente des o urren esde données sont à la harge du type de omposant Format et onstituent l'étape de formatage.Ce omposant est toujours onsommateur d'un et un seul �ot de données et ne produit qu'unet un seul �ot de données. De plus pour une o urren e du �ot de données en entrée, il existe69

Chapitre 3. SAIAtoujours une et une seule o urren e du �ot de donnée en sortie. Autrement dit, il n'y a ni �ltrageni dupli ation des o urren es dans e omposant. Le formatage est modélisé du point de vuetemporel par un omposant omprenant une fon tion ara térisée par son pire et son meilleurtemps d'exé ution notés respe tivement WCET et BCET (Worst/Best Case Exe ution Time).Parmi les as types, nous trouvons bien sûr le hangement d'unité. Ce hangement peuts'e�e tuer entre deux unités di�érentes d'une même grandeur, omme par exemple de degréCelsius vers degré Kelvin. Il peut également s'e�e tuer au sein de même unité omme par ex-emple lors du passage de mètre vers kilomètre. Les omposants de type Format sont égalementutilisés lors d'un hangement de repère. En ore une fois le hangement peut s'e�e tuer de deuxmanières di�érentes : entre deux repères du même plan, ou entre des repères exprimés di�érem-ment (représentation artésienne vers représentation polaire). En�n, es types de omposantssont également utiles lors d'un hangement de type, semblable à la notion de � ast� dans leslangages de programmation.3.2.4.2.2 Adaptation sémantiqueNous avons vu que les entrées du SAIM spé i�ent une vue abstraite d'une valeur physiquené essaire au ontr�le et que les sorties spé i�ent une a tion abstraite sur le pro essus. Contraire-ment à ela, les pilotes d'a quisition fournissent une vue réelle du monde extérieur et les pilotesde réalisation réalisent une a tion réelle sur le pro essus. On peut don avoir une hétérogénéitésémantique entre la spé i� ation réalisée par les entrées et les sorties et la spé i� ation despilotes. Cette adaptation peut amener à fusionner ou s inder des �ots d'informations.Cette adaptation onstitue la phase d'interprétation. Elle est réalisée par le type de om-posant Interpret. Puisque l'on peut fusionner ou s inder des �ots d'informations, le omposantInterpret peut posséder 1 à n �ots d'informations en entrée et 1 à n �ots d'informations ensortie. De plus, à une o urren e d'un �ot d'entrée peut orrespondre zéro, une ou plusieurso urren es en sortie. Autrement dit, les omposants de type Interpret peuvent �ltrer ou du-pliquer ertaines o urren es en leur sein. Pour dé rire le omportement des omposants de typeInterpret, on utilise un automate temporisé ommuni ant et une fon tion. L'automate tempo-risé ommuni ant permet de spé i�er la partie réa tive de l'interprétation ; 'est-à-dire le lienentre la façon de onsommer le(s) �ot(s) en entrée du omposant et la façon de produire le(s)�ot(s) en sortie du omposant. Parallèlement, la fon tion spé i�e les traitements à e�e tuer surla ou les o urren es d'entrées a�n de produire la ou les o urren es en sortie.Nous donnons maintenant deux exemples permettant d'illustrer deux as type de omporte-ment d'un omposant de type Interpret. Considérons dans le SAIM un omposant de typeentrée, modélisant Vitesse_robot qui spé i�e la vitesse d'un robot. Considérons dans le SAM lepilote d'a quisition d'événements Ti k_roues, générant un événement à haque tour de roue. Ilest possible de al uler l'entrée Vitesse_robot du robot en al ulant la di�éren e de temps entredeux o urren es su essives du �ot d'événements en provenan e de Ti k_roues. Il faut epen-dant réaliser une interprétation sémantique qui spé i�e omment les événements de Ti k_rouessont interprétés pour fournir l'entrée Vitesse. Dans e as l'automate peut, par exemple, spé i-�er si le al ul de la vitesse est réalisé à haque nouvelle mesure de temps entre deux événements70

3.2. Les (méta-)modèles dans SAIAou est réalisé en faisant la moyenne de 2,3 ou n mesure(s) de temps entre deux événements.Parallèlement à ela, la fon tion spé i�e omment la moyenne est al ulée à partir d'une ou deplusieurs mesure(s) de temps.Un autre as type, on erne la fusion de �ot d'informations. Considérons maintenant, dansle ontexte de l'exemple pré édent, que le SAM possède deux pilotes d'a quisition d'événementsTi k_roue_droite et Ti k_roue_gau he, générant ha un un événement à haque tour de laroue dont il est en harge. L'automate spé i�e alors la manière de onsommer et de produire les�ots d'informations pour réaliser la fusion. Par exemple, il spé i�e si l'entrée Vitesse_robot est al ulée pour haque o urren e de ha un des pilotes d'a quisition ou uniquement lorsque l'ona une nouvelle o urren e du pilote de Ti k_roue_gau he. Ce ne sont bien sûr que des exempleset on peut réaliser de nombreuses autres spé i� ations de la partie réa tive de l'interprétationlors d'une fusion de �ots d'informations.3.2.4.2.3 Adaptation de QoSNous avons vu que le SAM et le SAIM spé i�ent des ara téristiques de QoS requises etfournies. Des hétérogénéités peuvent apparaître au niveau de la QoS entre le SAM et le SAIM.Ces hétérogénéités peuvent apparaître au niveau de la loi d'arrivée et/ou de elle de retard.L'adaptation permettant de pallier ette hétérogénéité est réalisée par les omposants detype QoS_adapt. Le omposant QoS_adapt est toujours onsommateur d'un et un seul �ot d'in-formations et ne produit qu'un et un seul �ot d'informations du même type que elui d'entrée.Cependant, ontrairement au omposant Format, pour une o urren e du �ot d'informations enentrée, il peut exister zéro, une ou plusieurs o urren e(s) en sortie. Les omposants de typeQoS_adapt peuvent don �ltrer ou dupliquer des o urren es de leur �ot d'entrée. Comme pourle omposant Interpret, QoS_adapt est dé�ni par un automate temporisé ommuni ant et unefon tion.Un des as types est le �ltrage. Par exemple, une entrée peut spé i�er qu'elle requiert un �otd'informations ayant une loi d'arrivée périodique de 20ms. De l'autre �té, après formatage etinterprétation, le �ot d'informations originellement en provenan e d'un pilote peut posséder uneloi d'arrivée de 5ms. Dans et exemple l'automate doit réaliser le �ltrage des informations d'en-trées en ne réémettant qu'une o urren e du �ot d'entrée sur quatre. Parallèlement, la fon tionpeut spé i�er que l'on émet la valeur maximum / minimum / moyenne des o urren es reçuesentre deux réémissions.Un autre as type onsiste à émettre périodiquement un �ot d'informations non périodique.Si la période de réémission est inférieure à la loi d'arrivée du �ot d'informations en entrée, lafon tion du omposant de type QoS_adapt peut alors réaliser une interpolation. En�n, un autre as type intéressant onsiste à réer un retard onstant sur les o urren es en sortie. Ce retardest, bien sûr, au minimum égal au retard maximum des o urren es du �ot d'entrée, ependant,dans ertains as il est préférable d'avoir un retard plus important et onstant que moindre etvariable. 71

Chapitre 3. SAIA3.2.4.3 Con lusion sur l'ALML'ALM est le modèle d'une ou he d'adaptation entre le SAM et le SAIM. Il dé�nit un onne teur omplexe omposé de sous onne teurs pouvant ommuniquer entre eux. Cha unedes entrées et des sorties du SAIM possède un type de sous onne teur spé i�que dé�ni par un omposant omposite. La on�guration interne des sous onne teurs spé i�e la �glue� né essairepour pallier à l'hétérogénéité entre d'un �té les interfa es des entrées et des sorties et de l'autreles interfa es des pilotes.La �glue� est une on�guration de trois types de omposants : Format, Interpret et QoS_a-dapt. Format est seulement dé�ni par une fon tion alors que Interpret et QoS_adapt sont dé�nispar une fon tion et par un automate temporisé ommuni ant. Il n'existe pas de ontraintesparti ulières sur la stru ture de ette on�guration.Le onne teur omplexe est une adaptation de la plateforme réelle dé�nie par les pilotes duSAM a�n qu'elle orresponde dire tement à la plateforme abstraite dé�nie par les entrées / sortiesdu SAIM. Puisque le respe t de la QoS spé i�ée dans le SAIM est né essaire au fon tionnement orre t du système, le onne teur omplexe est en harge de l'établissement d'un ontrat de QoSentre le SAM et le SAIM. La se tion suivante détaille le mé anisme impliqué dans la mise en÷uvre de e ontrat, en ommençant par une dé�nition formelle de la QoS onsidérée dans erapport.3.3 SAIA et la QoS3.3.1 Introdu tionNous avons vu que la QoS on ernant la ommuni ation des appli ations de ontr�le depro essus ave le monde extérieur in�uen e la stabilité et la qualité de ontr�le du système. Lalittérature met en avant la loi d'arrivée et la loi de retard des informations. De plus, puisque lafusion entre des �ots d'informations est possible dans le onne teur omplexe, nous onsidéronségalement, dans le adre de ette thèse, la loi de orrélation temporelle.Nous avons également vu qu'une des ription de la QoS fournie et requise par les omposantsdu SAM et du SAIM est réalisée dans SAIA a�n de permettre l'établissement d'un ontrat deQoS par le onne teur omplexe.A�n de pouvoir réaliser la des ription et la gestion de la QoS sous forme de ontrat, plusieursétapes sont né essaires. Ces étapes sont dé rites dans e hapitre selon le plan suivant : Lapremière partie dé rit formellement les ara téristiques de QoS que sont la loi d'arrivée, la loide retard et la loi de orrélation temporelle. La se onde partie explique l'impa t du onne teur omplexe et l'analyse qu'il né essite. En�n, la troisième partie explique la mise en pla e du ontrat de QoS entre la plateforme abstraite et la plateforme réelle ( f. �gure 3.2 hapitre 3.1).72

3.3. SAIA et la QoS3.3.2 Dé�nition de la QoSLes �ots d'informations ir ulant dans le système sont en provenan e ou à destination dumonde extérieur. Nous faisons référen e au monde extérieur omme à un ensemble d'informationset d'a tions physiques. Un �ot d'informations est alors la onséquen e ou la ause d'une informa-tion ou d'une a tion physique. Un �ot d'information est une suite in�nie d'o urren e numérotéeentre un et l'in�ni. Pour haque o urren e d'un �ot d'information on onsidère l'existen e d'uneinformation ou d'une a tion orrespondante dans le monde extérieur. Une ara téristique de QoSest alors un modèle orienté QoS d'un �ot d'informations. De e fait haque ara téristique deQoS est ara térisée par une suite in�nie d'o urren es de QoS numérotées entre un et l'in�ni.Cha une des o urren es de QoS est liée à une o urren e dans le �ot d'informations qu'elle ara térise. Dans la partie suivante, nous ommençons par dé�nir ha une des o urren es deQoS de manière informelle avant de présenter leur dé�nition formelle.3.3.2.1 Dé�nition des o urren es de QoSTrois ara téristiques de QoS sont onsidérées dans ette thèse : la loi d'arrivée, la loi de orrélation temporelle et la loi de retard. Avant de donner la dé�nition formelle de ha une de es o urren es, nous ommençons par en donner une des ription informelle.Informellement, une o urren e de la loi d'arrivée représente le temps é oulé entre l'arrivéede deux informations onsé utives d'un même �ot.Une o urren e de la loi de orrélation temporelle représente la di�éren e d'âge entre deuxo urren es au moment de leur fusion. Cette loi n'existe don que lorsqu'une fusion est réaliséedans le onne teur omplexe.Pour la loi de retard, on di�éren ie la dé�nition de la loi de retard d'une information entrante,notée IDelay, de elle d'une information sortante, notée ODelay. Une o urren e de la loi deretard IDelay représente le temps é oulé entre le moment où l'information est présente dansl'environnement et le moment où l'o urren e est onsidérée dans le système. En sortie, uneo urren e de la loi de retard ODelay est informellement dé�nie par le temps é oulé entrele moment où l'o urren e est générée dans le système et le moment où ette o urren e est onsidérée dans le système ou dans le monde extérieur. En automatique, lorsque le moment oùl'o urren e est onsidérée orrespond au moment où l'a tion orrespondante sur le pro essus estréalisée, on appelle ette o urren e un temps de réponse. Comme lassiquement en automatique,nous onsidérons une Commande omme réalisée lorsque l'a tion physique orrespondante estréalisée à plus de 95%. Cette information est uniquement disponible dans le as d'un systèmelinéaire, ou d'un système non linéaire, linéarisé autour d'un point �xe [107℄.Dans les dé�nitions suivantes, nous donnons maintenant l'expression formelle de ha une deso urren es de QoS. Par la suite, un �ot d'information f est une suite in�nie d'o urren e fioù i ∈ [1;∞]. À un �ot f dans le système orrespond un �ot ϕ dans le monde extérieur. Nous onsidérons don que ∀ (fi ∈ f) ∃ (ϕi ∈ ϕ) tel que fi représente ϕi. Une ara téristique deQoS, notée QoSchar, est une suite in�nie d'o urren es QoSocci où i ∈ [1;∞] ; ∀ (QoSocci ∈73

Chapitre 3. SAIAQoSchar) ∃ (fi ∈ f) tel que QoSocci = QoS(fi).De plus, dans les dé�nitions suivantes, @fi représente la date de réation d'une o urren efi. De même, @ϕi représente la date de réation d'une o urren e ϕi. On note fi.init_delay,le retard initial de l'o urren e fi. La dé�nition formelle de fi.init_delay est donnée par lasuite. Puisque le retard d'une o urren e est dépendant du moment où on le onsidère, nousnotons Tfi la date à laquelle le retard de l'o urren e fi est onsidéré. Lors d'une fusion de N�ots d'informations, l'ensemble des �ots fusionnés est noté F . Il omprend N �ots notés fn oùn ∈ [1;N ]. (kp) représente le numéro de l'o urren e d'un �ot fn ou d'un �ot ϕn au moment dela keme fusion. L'o urren e orrespondante est don notée fnkp. En�n, nous notons :

arrivali est la QoSocci asso iée à la loi d'arrivée de fi ;IDelay

Tfi

i est la QoSocci asso iée à IDelay de fi au moment Tfi ;ODelay

Tfi

i est la QoSocci asso iée à ODelay de fi au moment Tfi ;∆k est la QoSocci asso iée à la loi de orrélation temporelle des o urren es

fnkp ∀ n ∈ [1;N ].Dé�nition préalable : fi.init_delay = @fi − @ϕi ∀i ≥ 1Les o urren es de QoS sont dé�nies omme e i ( f. �gure 3.10) :arrivali = @fi − @fi−1 ∀i ≥ 1

IDelayTfi

i = Tfi − @ϕi ∀i ≥ 1

ODelayTfi

i = Tfi − @fi ∀i ≥ 1

∆k = Max1≤n,m≤N

(|@fnkp − fnkp.init_delay − @fmkp + fmkp.init_delay|)

∀n > 0; m > 0; k > 0 fn, fm ∈ F= Max1≤n,m≤N

(|@ϕnkp − @ϕmkp|)

∀n > 0; m > 0; k > 0 @ϕnkp = QoS(fnkp),@ϕmkp = QoS(fmkp)Il est à noter que les o urren es de retard IDelayTfi

i sont exprimées par rapport au temps Tfiet sont don variable selon Tfi. Il en est de même pour les o urren es de retard ODelayTfi

i . Dansla suite de e rapport, les temps Tfi orrespondent à des instants pré is. Pour la ara téristiqueIDelay, Tfi orrespond au moment où l'o urren e est mise à jour dans l'entité où IDelayest exprimée. Pour la ara téristique ODelay, Tfi orrespond au moment où l'a tion physique orrespondante est onsidérée omme réalisée.En�n, la orrélation temporelle ne fait pas l'objet d'une spé i� ation dans le SAIM ou leSAM. En e�et, les valeurs a eptables pour la orrélation temporelle dépendent des types de74

3.3. SAIA et la QoS

Fig. 3.10 � Représentation des o urren es de QoS�ots fusionnés et de leur dynamique. La présen e d'une fusion ou non et des �ots impliqués dans ette fusion n'est onnue qu'au moment de la spé i� ation du onne teur omplexe. Cependant, ette ara téristique est importante pour assurer une ertaine qualité de ontr�le. La spé i� ationdes valeurs a eptables pour la orrélation temporelle s'e�e tue don au moment où l'on réaliseune fusion de �ot d'informations dans le onne teur omplexe. Cette ara téristique de QoS estdon spé i�ée dans le omposant primaire réalisant la fusion : Interpret.Maintenant que les o urren es de QoS ont été dé�nies, la se tion suivante dé�nit les ara -téristiques de QoS.3.3.2.2 Dé�nition des ara téristiques de QoSUne ara téristique de QoS est la spé i� ation d'une suite in�nie de QoSocc d'un même typepermettant de ara tériser un �ot f . Il existe plusieurs façons d'exprimer une suite in�nie deQoSocc. La manière la plus simple est l'expression d'une onstante, notée cste. Dans e as laspé i� ation signi�e que toutes les QoSocc doivent avoir la même valeur au ours du temps :

(QoS = cste) ⇐⇒ (∀i QoSocci = cste)Pour une expressivité plus ri he, une ara téristique de QoS peut être spé i�ée par un inter-valle. Dans e as, la spé i� ation signi�e que haque QoSocc appartenant à la ara téristiquepeut appartenir au domaine de valeurs dé�ni par l'intervalle. 75

Chapitre 3. SAIA(min < MAX ∧ QoS = [min ; MAX]) ⇐⇒ (∀i QoSocci ∈ [min ; MAX])Dans e as, l'intervalle [1 ; 5℄ peut spé i�er la suite {1, 5, 4, 3, 1, 4, 2, ...} mais aussi{1, 1, 1, 1, 1, ...} ou en ore {1, 5, 1, 5, 1, 5, ...} et .Certaines appli ations de ontr�le de pro essus peuvent né essiter une spé i� ation plus pré- ise qu'un intervalle. Par exemple on peut souhaiter que haque QoSocc appartienne à l'intervalle[1 ; 5℄ mais omme une suite de valeur unique ; 'est-à-dire {1, 1, 1, 1, ...} ou {2, 2, 2, 2, ...}.Dans e as, les intervalles ne sont pas assez expressifs. On propose alors d'utiliser des ω-expressions régulières a�n de spé i�er pré isément une ara téristique de QoS. Une expressionrégulière permet de spé i�er la grammaire d'un ensemble de mots. Dans e as les o urren esdes ara téristiques de QoS ne peuvent prendre leur valeur que pour former un des mots possiblesdans la grammaire spé i�ée.

QoS = regular expression ⇐⇒ ∀i > 1 {QoSocci−1, QoSocci} ∈ regular expressionPuisque les �ots d'informations ara térisés par la QoS sont in�nis, ou plus exa tement ont ladurée de vie du système, l'expression régulière ne doit dé�nir que des mots in�nis. Nous utilisonsdon les ω-expressions régulières. Ainsi, en plus des symboles de quanti� ation lassiques desexpressions régulières, nous utilisons le symbole de quanti� ation ω qui spé i�e qu'il existe unein�nité de répétitions de l'expression pré édent le symbole. Ainsi, dans l'exemple pré édent, lasuite de valeur unique appartenant ha une à [1 ; 5℄ devient [1ω | 2ω | 3ω | 4ω | 5ω]. Contrairementà ela, la spé i� ation d'un intervalle lassique devient [1 | 2 | 3 | 4 | 5]ω ou en ore [1 − 5]ω.Nous avons vu omment spé i�er les ara téristiques de QoS. Il est à noter que la spé i� ationest la même que la ara téristique soit requise ou fournie. Avant de voir omment établir le ontratde QoS, la partie suivante explique l'impa t du onne teur omplexe et l'analyse qui en résulte.3.3.3 Analyse du onne teur omplexe3.3.3.1 Prin ipesLa se tion 3.2.4 dé�nit le onne teur omplexe omme un ensemble de sous onne teursspé i�és par des omposants omposites ommuni ants. Cha un de es omposants ompos-ites omprend une �glue� qui est spé i�é par la on�guration émanant de l'inter onnexion des omposants primaires suivants : Format, Interpret et QoS_adapt. Ces omposants primaires ontiennent des fon tions représentées temporellement par leur WCET et leur BCET ainsi qu'unautomate temporisé ommuni ant pour Interpret et QoS_adapt. De plus, a�n de prendre en ompte les e�ets de l'implémentation, des budgets temporels représentant les temps de blo agesdus à l'ordonnan ement sont exprimés pour haque sous onne teur.76

3.3. SAIA et la QoSLa �glue� des sous onne teurs modi�e le(s) �ot(s) d'informations entre le SAM et le SAIM.Il est don lair que la QoS des �ots d'informations en entrée d'un sous onne teur est égalementmodi�ée par le omportement de e sous onne teur. Autrement dit, haque sous onne teur agit omme un modi� ateur de QoS. Un sous onne teur ne requiert au une QoS parti ulière sur esentrées. Cependant, une fois ses entrées onne tées, il fournit une ertaine QoS en sortie. Ainsi ilest impossible de spé i�er la QoS fournie par le sous onne teur sans onnaître la QoS de es �otsd'entrée. De plus, étant donné le omportement omplexe de la �glue� au sein de haque sous onne teur (automate, fon tion), la QoS n'est pas modi�ée de façon triviale. Il est don né essaired'évaluer la QoS résultante en sortie de haque sous onne teur une fois la on�guration internespé i�ant la �glue� réalisée et les interfa es d'entrée du sous onne teur onne tées.Ce onstat nous amène à on lure qu'au sein d'un omposant omposite spé i�ant un sous onne teur, la QoS onsidérée dans ette thèse est une propriété non dire tement omposable( f. hapitre 2.2.4). L'évaluation des ara téristiques de QoS passe don par l'analyse de la on�guration de ha un des sous onne teurs.Pour e�e tuer l'analyse, on s'appuie sur la sémantique opérationnelle des sous onne teursfournie par le langage d'automates temporisés IF. Cependant, ertains hoix restent en ore àfaire lorsque à une même ara téristique de QoS requise orrespondent plusieurs ara téristiquesde QoS fournie. Par exemple lors de la fusion de �ots d'informations au sein d'un omposantprimaire Interpret. Ce hoix on erne la sémantique de al ul de la QoS.En e�et, dans e as il existe plusieurs façons de al uler la QoS résultante en sortie du onne teur. Par exemple, onsidérant un automate qui réalise la fusion de deux �ots de donnéeset qui produit une nouvelle o urren e de donnée uniquement lorsqu'une nouvelle o urren e de haque �ot de données en entrée a été reçue. Dans SAIA, le retard de la donnée fusionnée peut,au hoix, être le retard maximum des o urren es au moment de la fusion ( f. �gure 3.11 A), leretard minimum des o urren es au moment de la fusion ( f. �gure 3.11 B), une moyenne desretards des o urren es au moment de la fusion ( f. �gure 3.11 C).Ce hoix est souvent fon tion de la dynamique des �ots d'informations fusionnés et est don laissé à la harge de l'utilisateur. Cependant, il est né essaire que e hoix soit renseigné ex-pli itement a�n de permettre l'évaluation de la QoS résultante en sortie du onne teur. Une fois e hoix renseigné, l'évaluation proprement dite peut ommen er.3.3.3.2 Méthode d'analyseL'analyse permettant l'évaluation de la QoS est e�e tuée sous onne teur par sous onne teur.La première étape onsiste à isoler les omposants dont le �ot d'informations entre dans le sous onne teur. Pour ha un de es omposants, il existe une des ription de la QoS. La deuxièmeétape onsiste à traduire la QoS exprimée sous forme d'expressions régulières en automate IF.L'automate IF doit reproduire un �ot d'informations onforme aux spé i� ations réalisées par ha une des ara téristiques de QoS. La deuxième étape ommen e don par une onversionde l'expression régulière sous forme d'un LTS déterministe [14℄. Un LTS est un graphe d'étatet de transition et où haque transition ontient une étiquette. Une fois le LTS réalisé, il faut onstruire un automate IF ontenant autant d'état que le LTS. Cha une des étiquettes sur les77

Chapitre 3. SAIA

Fig. 3.11 � Exemple de sémantique de la loi de retard lors de la fusion de deux informationstransitions sortantes d'un état du LTS orrespond alors à une garde temporelle dans l'automateIF. Cet automate est un simulateur du omportement temporel d'un des omposants dont le �otd'informations entre dans le sous onne teur. Puisque nous nous intéressons uniquement à despropriétés temporelles, les valeurs asso iées à un �ot (dans le as d'un �ot de données) ne sontpas utiles, seul le omportement temporel du �ot est important.Une fois les automates IF représentatif des expressions régulières réalisés, la partie représen-tant le sous onne teur et es entrées onstitue un système IF exé utable par les outils asso iés aulangage. L'exé ution d'un système IF réalise une simulation exhaustive du système aboutissantà la réation d'un LTS.Le LTS IF ontient la ombinatoire de tous les hemins d'exé ution possibles du système(i i du sous onne teur). A�n de onnaître la ara térisation du ou des �ot(s) d'informations ensortie du système IF, l'exé ution doit être observée. Dans notre as, la mesure des o urren esde QoS QoSocci orrespond à une propriété de viva ité bornée. En e�et, une o urren e de laloi d'arrivée met en relation deux o urren es onsé utives dans un �ot in�ni. Puisque le �ot estsupposé in�ni, pour haque o urren e 'i', il existe une o urren e 'i+1'. La mesure de arrivaliest don une propriété de viva ité bornée. En e qui on erne une o urren e delayi, son al ulmet en relation des informations ϕi du monde extérieur ave des informations fi dans le systèmeou inversement. Pré édemment, nous avons fait la supposition que pour haque fi dans le systèmeil existe un ϕi dans le monde extérieur et don un QoSocci. Il s'agit don en ore d'une propriétéde viva ité bornée. Pour e type de propriétés, il est don possible de réaliser ette mesure grâ eà des observateurs IF, un artefa t du langage noté observer.78

3.3. SAIA et la QoSUn observer, non intrusif dans notre étude, peut dé len her des a tions prioritaires surl'envoi ou la ré eption d'événements dans le système. On propose de les utiliser pour mesurerles o urren es de QoS QoSocc. Lorsqu'une QoSo est mesurée par l'observer, il génère unmessage. Ce message est alors traduit par une transition dans le LTS résultant de l'exé ution dusystème. L'étiquette asso iée à la transition orrespond alors à la valeur de l'o urren e de QoSmesurée.Le LTS résultant de l'observation du système par les observer ontient la ombinatoire detoutes les exé utions possibles du système ainsi que toutes les valeurs possibles des o urren esde QoS orrespondantes. Deux étapes sont alors né essaires à l'extra tion de l'ensemble deso urren es de QoS représentant la ara téristique de QoS mesurée. Premièrement, a�n de nepas a her de omportement non désirable du système, le LTS résultant de l'exé ution du systèmedoit être y lique et ne posséder au un état bloquant (deadlo k free).Une fois es propriétés véri�ées, il est possible de a her les transitions non générée par lesobserver a�n de ne garder que les QoSocc. Il en résulte un LTS ontenant les QoSocc et desǫ-transitions [4℄. Il est alors possible de réduire le LTS obtenus selon la relation d'équivalen efaible de tra e [118℄ a�n de ne garder que les QoSocc. Le LTS résultant de es deux opérationsne ontient alors que l'en haînement des QoSocc représentatif de l'expression régulière de la ara téristique de QoS mesurée.Ces étapes permettent de mesurer la QoS en sortie d'un sous onne teur malgré sa modi�- ation non triviale par la �glue�. Ces étapes doivent être réalisées pour haque sous onne teur.Ensuite, l'étape suivante onsiste à véri�er que la plateforme réelle, adaptée, peut être liée àla plateforme abstraite tout en satisfaisant la QoS exprimée pour la orre tion du système.Autrement dit, la pro haine étape onsiste à véri�er si le ontrat de QoS entre la plateformeréelle et la plateforme abstraite peut être établit.3.3.4 Établissement du ontrat de QoSÉtablir un ontrat de QoS doit don assurer que la onnexion du SAM ave le SAIM réaliseun système dont la qualité de ontr�le est elle re her hée. Ce i revient à s'assurer que ha unedes ara téristiques de QoS fournie satisfait la ara téristique de QoS orrespondante lors de la onnexion du SAM et du SAIM.Plus pré isément, un ontrat est établi pour haque ara téristique de QoS de haque entréeset de haque sorties. L'ensemble de es ontrats, s'ils sont tous établis orre tement, permetl'établissement d'un ontrat global. Pour la suite, on introduit l'opérateur satisfies qui véri�eque la satisfa tion de la QoS est atteinte pour une ara téristique de QoS d'une entrée ou d'unesortie donnée. Cet opérateur est booléen : la QoS est satisfaite ou non. L'établissement d'un ontrat de QoS onsiste don à véri�er :

QoSfournie “satisfies′′ QoSrequise 79

Chapitre 3. SAIALa QoS est exprimée par deux ara téristiques, ha une d'elles étant exprimée omme un�ot in�ni d'o urren es de QoS notées QoSocci. Le but de l'opérateur satisfies est don devéri�er que pour tout i, ha une des QoSocci spé i�ée par la QoS fournie est spé i�ée ommea eptable par la QoS requise.La façon de réaliser l'opérateur satisfies est di�érente suivant la méthode hoisie pourspé i�er les ara téristiques de QoS. Si les ara téristiques sont spé i�ées sous forme d'une on-stante, l'opérateur satisfies doit s'assurer que la onstante représentant la QoS fournie estégale à elle représentant la QoS requise :QoSfournie = QoSrequiseSi les ara téristiques de QoS sont spé i�ées par un intervalle, alors la relation qui permet devéri�er que la QoS fournie est omposée ex lusivement de QoSo spé i�ées omme a eptablespar la QoS requise est la relation d'in lusion : ⊆. Ainsi, ha une des valeurs possibles pour les

QoSocc de la QoS fournie appartient aux valeurs a eptables spé i�ées par la QoS requise, larelation est don la suivante :QoSfournie ⊆ QoSrequiseEn�n, si les ara téristiques de QoS sont spé i�ées par des expressions régulières, haque ara téristique forme un langage. La QoS requise dé rit un langage dont les mots in�nis spé i�ésdé rivent les suites de valeurs a eptables. Parallèlement, la QoS fournie dé rit les suites de motsin�nis possibles, en sortie de la plateforme.Si la QoS fournie est un sous langage de la QoS requise alors tous les mots de la QoS fourniefont partie du langage de la QoS requise. L'opérateur satisfies doit don véri�er la relationde sous langage entre la QoS fournie et la QoS requise. La relation de sous langage est véri�éesur les LTS. En e�et, l'évaluation de la QoS en sortie de haque sous onne teur est déjà sousforme de LTS, de plus, La tradu tion d'une expression régulière vers un LTS se fait de manièreassez naturelle. Il faut ependant s'assurer que le LTS représente la totalité des mots dé ritspar l'expression régulière. Pour les expressions régulières omplexes, il est intéressant de réaliserun automate IF a�n qu'il génère le LTS lui même. Une fois ha une la ara téristiques de QoSfournie et la ara téristique de QoS fournie orrespondante toutes deux obtenues sous forme deLTS, la relation de sous langage peut être véri�ée.La relation de sous langage doit véri�er que tous les mots possible dans la des ription duLTS d'une ara téristique de QoS fournie existent dans le LTS de la ara téristique de QoSrequise orrespondante. Plus pré isément, la suite de transitions, et don d'étiquettes du LTSd'une ara téristique de QoS fournie doit exister dans le LTS de la ara téristique de QoS requise orrespondante. Cette relation est appelée �équivalen e de tra e� [118℄.Ainsi l'opérateur �satis�es� doit, dans e as véri�er l'équivalen e de tra e entre la QoS fournieet la QoS requise. Nous notons et opérateur sublanguage_of. La relation devient :80

3.3. SAIA et la QoSQoSfournie “sublanguage_of ′′ QoSrequiseL'équivalen e de tra e est une relation implémentée dans l'outil aldébaran [48℄ et peut don être véri�ée automatiquement. Il faut remarquer qu'une valeur onstante C est un as parti ulierd'un intervalle [C1 ; C2℄ où C1 est égal à C2. De même, un intervalle [C1 ; C2℄ est un as parti ulierd'un langage dé rit par l'expression régulière [C1 | C1+1 | C1+2 | ... | C2]ω3.3.4.1 Résumé des étapes d'établissement d'un ontrat de QoS dans SAIALes se tions pré édentes dé rivent en détail la QoS en termes de des riptions formelles, d'anal-yses et de relations de satisfa tion. Plusieurs étapes sont né essaires pour permettre l'établisse-ment d'un ontrat de QoS dans SAIA. Ces étapes sont résumées dans e hapitre. La des riptiondes ara téristiques de QoS requises et fournies n'est pas symétrique entre les entrées et lessorties ( f. se tion 3.2.3.3). Les étapes né essaires à l'établissement d'un ontrat de QoS sontdon légèrement di�érentes, nous les présentons dans la même se tion mais au travers de deuxillustrations di�érentes.A�n d'établir un ontrat de QoS, il est né essaire de posséder une des ription, sous formede LTS des ara téristiques de QoS requises et des ara téristiques de QoS fournies, modi�éespar le sous onne teur en harge de l'établissement du ontrat de QoS. L'obtention des LTSreprésentants les ara téristiques de QoS requises et les ara téristiques de QoS fournies peut sefaire de manière parallèle. Nous ommençons arbitrairement par l'obtention des ara téristiquesde QoS fournie, modi�ées par le sous onne teur.La première étape, notée 1 sur les �gures 3.12 et 3.13, onsiste à traduire la QoS fournie de ha un des omposants liés au sous onne teur à analyser en un automate IF. Chaque automatedoit produire un �ot d'informations dont le omportement temporel est onforme à elui dé ritdans les ω-expressions régulières de la QoS. Une fois ette étape réalisée, il onvient d'extraireles automates IF de ha un des omposants de la �glue� du sous onne teur onsidéré (étapenotée 2 sur les �gures 3.12 et 3.13). Il faut ensuite ajouter les observers de QoS ; si pour unemême ara téristique de QoS requise orrespondent plusieurs ara téristique de QoS fournie, ilfaut hoisir l'observer onforme à la sémantique de al ul de la QoS. Cette étape est notée 3 surla �gure 3.12 et sur la �gure 3.13. On réalise ensuite l'exé ution de l'ensemble des automates IF(étape 4 de les �gures 3.12 et 3.13) a�n d'obtenir le LTS ontenant la ombinatoire de tous les hemins d'exé ution possibles pour le omportement du sous onne teur, auquel est ajouté lamesure des o urren es de QoS e�e tuée par l'observer. La dernière étape pour l'obtention duLTS de la QoS fournie, modi�ée par le sous onne teur est notée 5 sur la �gure 3.12 et sur la�gure 3.13. Elle onsiste à e�e tuer les rédu tions dé rites dans la se tion pré édente a�n de negarder, dans le LTS de départ, que la des ription du langage de la QoS, sous forme de LTS.A�n d'établir un ontrat de QoS est également né essaire de posséder le langage de la QoSrequise sous forme de LTS. Pour e faire trois étapes sont né essaires. La première, notée I surles �gures 3.12 et 3.13, onsiste à traduire la QoS requise par l'entrée en un automate IF. Cetautomate doit produire l'ensemble mots de QoS onforme à l'ensemble des mots dé rits dans les81

Chapitre 3. SAIA

Fig. 3.12 � Étapes pour l'établissement d'un ontrat de QoS d'une entrée

Fig. 3.13 � Étapes pour l'établissement d'un ontrat de QoS d'une sortie82

3.4. Con lusionω-expressions régulières de haque ara téristique de QoS requise. L'étape suivante (notée II surles �gures 3.12 et 3.13) onsiste à faire la simulation exhaustive du ou des automate(s) obtenu(s)à l'étape pré édente. En�n, l'étape notée III sur les �gures 3.12 et 3.13 permet de réduire leLTS obtenu à l'étape pré édente a�n de ne onserver que le langage de la QoS requise, exprimésous forme de LTS.Une fois es étapes réalisées, il est possible de véri�er la relation de sous langage en appliquantla relation d'équivalen e de tra e entre le LTS de la QoS fournie et elui de la QoS requise. Cetterelation, notée 6.IV sur les �gures 3.12 et 3.13, renvoie un résultat booléen. Si e résultat estvrai, le ontrat peut être établi. S'il est faux, l'outil aldébaran utilisé pour véri�er la relationd'équivalen e fourni un diagnosti qui pré ise le mot de QoS jusqu'à la première o urren e deQoS fautive.3.4 Con lusionCe hapitre a présenté les prin ipes du style ar hite tural SAIA, 'est à dire une séparationdes préo upations entre le �té appli atif d'un système de ontr�le de pro essus et la partieplateforme de ommuni ation ave le monde extérieur.Pour ela, l'appli ation de ontr�le est basée sur la des ription d'une plateforme abstraitedé rite en termes d'entrées et de sorties. Le ontr�le du pro édé est assujetti à une qualité de ontr�le, exprimant la pré ision et/ou la stabilité requise pour le système. Dans SAIA, la qualitéde ontr�le est dérivée en QoS sur la plateforme abstraite.A�n de réaliser le système, une plateforme réelle doit être hoisie et analysée a�n d'en on-naître la QoS. Elle est ensuite onne tée à la plateforme abstraite par un onne teur omplexe.Ce onne teur omplexe est omposé de sous onne teurs pouvant ommuniquer les uns ave lesautres. Ils sont en harge de l'adaptation de la plateforme réelle a�n qu'elle orresponde dire te-ment à la plateforme abstraite. Pour ela une �glue� est spé i�ée pour haque sous onne teursous la forme d'une on�guration de omposants.La stru turation d'une ar hite ture onforme à SAIA est soumise à des ontraintes sur lesasso iations entre les types de omposants. Les ontraintes sont prin ipalement dues à la né essitéde réaliser des analyses. Par exemple, le fait qu'une interfa e ne puisse être liée qu'à une et une seulinterfa e de sortie a été introduit pour éviter les fusions impli ites de �ots d'informations. Cettefusion impli ite n'est gênante que par le fait qu'elle ne permet pas de onnaître la sémantiqued'agrégation des �ots d'informations et don ne permet pas la réalisation d'analyses de QoS.Les agrégations ont don été isolées dans un omposant parti ulier et dé�nies sous la formed'un automate temporisé ommuni ant. En e sens, les restri tions sont pla ées de manière àpermettre à une on�guration d'être analysable.Toujours dans l'idée de réaliser des analyses sur la QoS des �ots d'informations ir ulantentre l'environnement et le système, une séparation est faite entre les �ots de données et les�ots d'événements. Pourtant, au regard des analyses réalisées, au une d'elles n'exploite ette83

Chapitre 3. SAIAdi�éren e. Il nous semble tout de même important de faire la di�éren e entre les �ots d'événe-ments et les �ots de données a�n de permettre des extensions futures de SAIA telles que l'ajoutd'analyses supplémentaires. En parti ulier, sur la pré ision des données et l'impa t des retards,des agrégations ou autres adaptations telles que les interpolations sur ette pré ision.Les analyses proposées permettent d'évaluer l'impa t du onne teur omplexe et ainsi de véri-�er la orre tion du système à l'aide d'établissements de ontrats de QoS. L'établissement d'un ontrat re�ète la satisfa tion d'une ara téristique de QoS requise par la ara téristique de QoSfournie orrespondante. Lorsqu'elle on erne les servi es d'un omposant, la notion de requis etde fourni est relativement intuitive. Cependant pour e qui est de la QoS, elle est moins évidente.Par exemple, la loi d'arrivée d'un pilote d'a quisition est dé�nie dans SAIA omme une ara -téristique fournie par eque le pilote génère le �ot d'informations ainsi ara térisé. Cependant, àl'image du débit entre un lient et un serveur, on pourrait admettre que la loi d'arrivée d'un piloted'a quisition est une loi requise a�n que le onsommateur du �ot puisse onsommer ha une deso urren es du �ot. Dans SAIA, deux règles ont permis d'établir si les ara téristiques étaientfournies ou requise. D'abord, puisque le but premier est de ara tériser la QoS permettant à l'ap-pli ation d'atteindre la qualité de ontr�le désirée, le point de vue de l'appli ation est un prin ipedire teur. Ainsi la loi d'arrivée d'une entrée est une ara téristique requise pour la stabilité. Ladeuxième règle est venue d'un besoin de ohéren e dans la relation de satisfa tion permettantl'établissement d'un ontrat. Ainsi, non seulement pour haque ara téristique de QoS fournie ilexiste une ara téristique de QoS requise mais également la relation de satisfa tion doit toujoursexprimer la notion de sous langage (lorsque la ara téristique est exprimée par une expressionrégulière).En�n, avant de on lure e hapitre, il me semble intéressant de se pen her sur les budgetstemporels introduits dans SAIA. SAIA ne fournit pas d'éléments permettant la des ription dela plateforme d'exé ution réelle. La plateforme d'exé ution est abstraite par la spé i� ation desdi�érents budgets temporels au sein de ha un des omposants. Un budget temporel est uneabstra tion temporelle des servi es d'exé ution. Cette abstra tion est né essaire (et su�sante)à la réalisation des analyses présentées. Cependant, puisque SAIA ne fournit pas de moyen dedé rire la plateforme d'exé ution réelle, elle ne spé i�e pas non plus omment onstruire le lienentre ette abstra tion et sa réalité. De e fait, SAIA reste une ar hite ture logique.Nous avons vu dans e hapitre les prin ipes de SAIA. Le hapitre suivant se propose d'évaluerla pertinen e et le adre d'utilisation de la proposition. À et e�et il présente les di�érentesutilisations et mises en ÷uvre de SAIA.

84

4Évaluation de l'appro heSommaire4.1 Outil de modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 874.2 Pro essus de modélisation in rémentaux dans SAIA . . . . . . . . . . . . . . . 894.2.1 Développement du SAIM . . . . . . . . . . . . . . . . . . . . . . . . . 894.2.2 Développement du SAM . . . . . . . . . . . . . . . . . . . . . . . . . . 904.2.3 Développement de l'ALM . . . . . . . . . . . . . . . . . . . . . . . . . 914.2.4 Evaluation et ontrat de QoS . . . . . . . . . . . . . . . . . . . . . . . 924.3 Illustration de la méthode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934.3.1 Réalisation du SAIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934.3.1.1 Étape 1 : extra tion des entrées / sorties . . . . . . . . . . . 934.3.1.2 Étape 2 : Réalisation de l'appli ation de ontr�le . . . . . . 944.3.1.3 Étape 3 : Extra tion de la qualité de ontr�le à respe ter . . 954.3.1.4 Étape 4 : Dérivation de la qualité de ontr�le en QoS . . . . 954.3.1.5 Étape 5 : Finalisation du SAIM . . . . . . . . . . . . . . . . 964.3.2 Réalisation du SAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974.3.3 Réalisation de l'ALM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 994.3.3.1 Étape 1 : stru ture des sous onne teurs . . . . . . . . . . . 994.3.3.2 Étape 2 : stru ture de la �glue� des sous onne teurs . . . . 1004.3.3.3 Étape 3 : spé i� ation des omposants de la �glue� . . . . . 1014.3.4 Réalisation de l'évaluation de la QoS . . . . . . . . . . . . . . . . . . . 1014.3.5 Réalisation de l'établissement du ontrat de QoS . . . . . . . . . . . . 1014.3.6 Con lusion sur l'illustration de la méthode . . . . . . . . . . . . . . . . 1024.4 SAIA pour la mise au point de systèmes . . . . . . . . . . . . . . . . . . . . . 1024.5 Con ours no 1 : The maRTian Task . . . . . . . . . . . . . . . . . . . . . . . . 1054.5.1 Le simulateur asso ié à maRTian Task . . . . . . . . . . . . . . . . . . 1064.5.2 Déployer l'appli ation de ontr�le sur une ible réelle . . . . . . . . . . 1074.5.3 SAIA et le développement basé sur un simulateur . . . . . . . . . . . . 10885

Chapitre 4. Évaluation de l'appro he4.5.4 La mise en ÷uvre des modèles . . . . . . . . . . . . . . . . . . . . . . . 1084.6 Con ours no 2 : The CiberMouse Proje t . . . . . . . . . . . . . . . . . . . . . 1104.6.1 CiberMouse versus maRTian Task . . . . . . . . . . . . . . . . . . . . 1104.6.2 Les modi� ations dans le SAIM . . . . . . . . . . . . . . . . . . . . . . 1124.6.3 Le onne teur omplexe . . . . . . . . . . . . . . . . . . . . . . . . . . 1124.6.3.1 L'a quisition de la position du robot . . . . . . . . . . . . . 1124.6.3.2 Le pilotage du SAIM . . . . . . . . . . . . . . . . . . . . . . 1134.6.3.3 Con lusion de CiberMouse . . . . . . . . . . . . . . . . . . . 1144.7 Con lusion sur l'évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

86

4.1. Outil de modélisationCe hapitre a pour but d'évaluer le adre d'utilisation de SAIA. Pour e faire, le hapitre ommen e par la des ription de l'outil de modélisation réalisé pour supporter SAIA. Ensuite,une méthode est proposée pour l'utilisation de SAIA. Cette méthode est illustrée par un exemplesimple mettant en éviden e les intérêts de l'appro he, en parti ulier pour la gestion de la QoS.Une deuxième utilisation de l'appro he est alors illustrée, également à l'aide d'un exemple simple.Ensuite, l'utilisation est présentée pour la modélisation et pour l'implémentation d'un robotexplorateur. En�n, autre exemple de robot explorateur présente la réutilisation du modèle SAIMdu robot pré édent dans un autre ontexte. Chaque partie de e hapitre propose une ritiquede l'appro he.4.1 Outil de modélisationRespe ter un style ar hite tural demande une grande onnaissan e du style en question.Cha un des types ainsi que ha une des ontraintes doivent préalablement être onnus. De plus,il faut une grande attention a�n de ne pas transgresser involontairement une des ontraintesénon ées par le style. La réalisation d'un outil de modélisation spé i�que au style ar hite turalpermet alors de s'assurer du respe t des types de omposants ainsi que des ontraintes sur leurasso iation. Pour SAIA, un outil basé sur GME [62℄ a été développé. GME est un outil pourla réation d'environnement de développement spé i�que. À ette �n, il propose de modéliserle langage ible sous forme d'un métamodèle basé sur une extension d'UML. Le but de l'outilréalisé est de fournir un éditeur de modèles onformes à SAIA. Il permet de modéliser ha un destypes de omposants et de modèles présentés dans ette thèse. Il implémente également ha unedes ontraintes stru turelles présentées.La des ription des métamodèles de SAIA a don été né essaire. Cette étape permet de poser lairement les on epts employés. Une fois les métamodèles de SAIA représentés dans l'outil, desinformations de présentation doivent être ajoutées aux métamodèles a�n de générer l'outil demodélisation de SAIA. Les informations de présentation permettent la des ription de plusieursvues où les types de omposants sont utilisables et/ou visualisables ou non. Pour SAIA, ha undes modèles (SAIM, SAM ou ALM) est réalisé dans l'outil par une vue di�érente. Ce i permetde ne proposer que l'utilisation des types de omposants relatifs au modèle en ours de réalisa-tion. Les informations de présentation permettent également de dé�nir di�érentes vues selon laprofondeur où l'on se trouve dans le modèle (La profondeur étant, i i, liée à l'arbores en e dansles omposants omposites). Ainsi, lors de la modélisation du omportement d'un omposantd'adaptation (xAE), seul les omposants spé i�ques à la �glue� sont utilisables. Ce i permet deséparer les préo upations relatives à ha un des modèles mais aussi elles relatives à la pro-fondeur où l'on se trouve dans le modèle. De plus, a�n de séparer les aspe ts fon tionnels etextra-fon tionnels, la des ription de la QoS est réalisée dans une vue di�érente de la des riptiondu omportement de ha un des types de omposant.Une boîte à outils proposant des omposants prédé�nis est proposée dans l'outil réalisé. Cetteboîte à outils permet d'utiliser dire tement un omportement parti ulier, omme par exempleun type d'agrégation spé i�que. Ce i permet de gagner du temps pour la réutilisation d'un omportement fréquemment ren ontré. Cela permet aussi d'appréhender dire tement le ode IFexé utable lié à e omportement. 87

Chapitre 4. Évaluation de l'appro heLa �gure 4.1 est une apture d'é ran de l'outil permettant la réalisation de modèles SAIA.L'onglet séle tionné est elui du SAIM, Les types de omposants utilisables ne sont don que eux appartenant au SAIM. Les attributs des omposants sont a essibles dans la fenêtre en basà droite. Pour les omposants omposites, il est possible de dé rire leur on�guration interne en�rentrant� dans le omposant omposite ; une nouvelle page d'édition de modèles s'ouvre alors.En�n, tous les omposants et les modèles sont a essibles via l'explorateur se trouvant à la droitede la zone de modélisation.

Fig. 4.1 � Capture d'é ran de l'outil réaliséUne fois la modélisation d'un système réalisé dans l'outil, il faut débuter le pro essus d'étab-lissement des ontrats de QoS. Nous avons vu se tion 3.3.3 qu'il est né essaire pour ela deréaliser des analyses. Ces analyses sont implémentées par les outils de manipulation de LTS as-so ié à IF [18℄. A�n de permettre l'utilisation des outils IF existant, un parser a été réalisé pourextraire un modèle IF d'une représentation SAIA. Le parser exploite les fa ilités de GME quipermet de onvertir automatiquement les modèles SAIA en XML. Une fois les informations du� hier XML ré upérées, elles sont ompilées de manière à obtenir un modèle IF exé utable.L'outil de modélisation développé ne apture pas tous les on epts manipulés par le langageIF (le but n'étant pas i i de fournir un éditeur IF). A�n de générer un modèle IF exé utable, ilest don né essaire d'utiliser les omportements prédé�nis asso iés à la boîte à outils. De plus,le parser permettant la tradu tion du modèle SAIA vers le modèle IF n'a été réalisé que pourmontrer la faisabilité de l'automatisation. Dans la version a tuelle, il ne permet d'e�e tuer unetradu tion que lorsque le modèle ontient un seul omposant d'adaptation. En�n, la réalisa-tion de transformation de modèle est une préo upation importante ré emment adressée par lestravaux autour de l'ingénierie dirigée par les modèles ; ainsi de nombreux langages et appro hesde transformation de modèles apparaissent [33℄. La transformation réalisée i i pour passer d'unedes ription du modèle en XML à sa des ription en IF ne manipule pas dire tement les on eptspermettant de passer d'un modèle à un autre mais est odée �en dur� dans du ode java.88

4.2. Pro essus de modélisation in rémentaux dans SAIALa mise en pla e de l'outil nous a permis de s'assurer de la ohéren e entre les modèles. Deplus, e i nous a fourni un point d'entrée vers l'ingénierie dirigée par les modèles. On peut don imaginer lier l'appro he ave des appro hes pour les transformations de modèles et ainsi réerun pont vers d'autres langages pour la véri� ation, l'exé ution, et .La se tion suivante présente la méthode proposée pour la réalisation de système de ontr�lede pro essus ave SAIA.4.2 Pro essus de modélisation in rémentaux dans SAIAA�n d'utiliser e� a ement les di�érents modèles proposés par le style ar hite tural (quipeuvent s'avérer omplexes), une méthode est proposée. Cette méthode n'est pas la seule pouvantêtre utilisée mais permet de montrer un en hainement possible pour la dé�nition des di�érentsmodèles. La méthode dé�nit des pro essus de modélisation in rémentaux (au sens de [79℄). Ellepermet don de dé omposer l'a tivité de modélisation en étapes et ainsi d'aider l'utilisateur à se on entrer sur un seul aspe t de la mise en pla e de son modèle.Nous avons vu que dans SAIA, l'appli ation de ontr�le, basée sur la plateforme abstraiteest indépendante de la plateforme réelle. Pour ne pas être in�uen ée par une plateforme réellespé i�que, la méthode proposée ommen e par la modélisation de l'appli ation de ontr�le et de saplateforme abstraite. Ensuite, la modélisation de la plateforme réelle puis du onne teur omplexesont présentées. En�n, une méthode permettant l'établissement des ontrats est proposée.4.2.1 Développement du SAIMAvant la première étape de modélisation, il est né essaire de posséder les spé i� ations dusystème à réaliser. La première étape de la modélisation du SAIM onsiste à extraire des spé i-� ations les di�érentes entrées et sorties né essaires à l'appli ation pour atteindre ses obje tifsde ontr�le (noté I.1 sur la �gure 4.2). Comme spé i�é dans la se tion 3.2.3 traitant du SAIM,il est né essaire que la spé i� ation des entrées et des sorties soit indépendante de la façon deles a quérir ou de les réaliser. La des ription des entrées et des sorties n'est pour l'instant quepurement fon tionnelle. En e�et, la des ription de la QoS est, à et instant, impossible puisquefortement liée à l'appli ation de ontr�le.La se onde étape est don la modélisation de l'appli ation de ontr�le. Le ontr�le est basé surla des ription de la plateforme abstraite. La modélisation du ontr�le en lui même est extrait desspé i� ations (noté I.2 sur la �gure 4.2). Comme expliqué dans la se tion 3.2.3, la modélisationde l'appli ation de ontr�le n'est pas détaillée dans SAIA.La troisième étape de modélisation onsiste à extraire des spé i� ations les besoins en qualitéde ontr�le (noté I.3 sur la �gure 4.2). La qualité de ontr�le est souvent exprimée à l'aide de ontraintes de haut niveau dans les spé i� ations. On trouve par exemple la spé i� ation d'uneé héan e de bout en bout, d'une onsommation éle trique ou, de ontraintes plus spé i�ques à89

Chapitre 4. Évaluation de l'appro he

Fig. 4.2 � Les pro essus de modélisation in rémentaux pour la modélisation du SAIMun ontr�le parti ulier, omme par exemple une ontrainte de déviation maximale lors d'un suivide traje toire.Pour appliquer SAIA, il onvient alors de dériver la qualité de ontr�le de l'appli ation a�nd'obtenir la QoS orrespondante sur haque entrée et de haque sortie. La qualité de ontr�len'est pas uniquement fon tion de la qualité de servi e sur les entrées et les sorties. Elle est, entreautre fon tion de la période d'a tivation de la loi de ontr�le [12℄. Cependant, dans SAIA la QoSest dérivée sur les entrées et les sorties après avoir �xé les autres paramètres in�uents. Cetteétape, notée I.4 sur la �gure 4.2, fournie la des ription de la QoS pour ha une des entrées et ha une des sorties.La dernière étape (notée I.5 sur la �gure 4.2) e�e tue la liaison entre la des ription fon tion-nelle des entrées et des sorties, la des ription de la QoS et la modélisation du ontr�le. Cetteétape aboutit à un modèle SAIM omplet.4.2.2 Développement du SAMLe développement du SAM onsiste à spé i�er la plateforme réelle. Il faut don spé i�er lesdi�érents �ots d'informations ir ulant en entrée et en sortie de ette plateforme. Puisqu'il s'agitd'une plateforme réelle, ette étape est issue de l'analyse d'un système existant. Le SAIM peutêtre un ensemble omposé de apteurs, d'a tionneurs et de leur pilote ou bien un ensemble de90

4.2. Pro essus de modélisation in rémentaux dans SAIAservi es d'un simulateur. Dans les deux as, une des ription de la QoS doit être renseignée pour ha un des �ots d'informations spé i�és.Une fois le SAM modélisé, il est né essaire de modéliser le onne teur omplexe qui onne tele SAM et le SAIM, soit la des ription de l'ALM.4.2.3 Développement de l'ALMNous proposons au travers de ette méthode la modélisation du onne teur omplexe selontrois étapes. La première (notée II.1 sur le �gure 4.3) spé i�e la stru ture gros grains expli itant omment les pilotes sont impliqués dans l'a quisition ou la réalisation des entrées et des sorties.Autrement dit, des onnexions logiques sont réées entre d'une part les interfa es des pilotes et elles des omposants d'adaptation asso iés et d'autres part entre les interfa es des entrées etdes sorties et elles des omposants d'adaptation asso iés. Cette opération (notée III.1 sur la�gure 4.4) né essite la onnaissan e d'élément du SAM et du SAIM.Les étapes suivantes spé i�ent la �glue� de ha un des sous onne teurs. La première enspé i�e la on�guration interne, 'est-à-dire quels sont les omposants intervenants dans la �glue�et la manière dont ils sont onne tés (notée II.2 sur la �gure 4.3). Par exemple : Est- e qu'un omposant de type Format est né essaire ; avant ou après un omposant de type Interpret ? Unefois la on�guration de la �glue� réalisée, il faut spé i�er l'automate temporisé et/ou la fon tionasso iés à ha un des omposants de la �glue� (noté II.3 sur la �gure 4.3). Durant ette étape ilfaut également spé i�er la sémantique d'agrégation de la QoS s'il y a lieu.

Fig. 4.3 � Les pro essus de modélisation in rémentaux pour la modélisation de l'ALMMaintenant que l'ALM est spé i�é, les trois modèles sont inter onne tés (transformation notéIII.2 sur la �gure 4.4). En analogie au PSM (Platform Spe i� Model) dé�ni dans MDA, nousappelons le modèle résultant de ette asso iation le SASM (Sensors A tuators Spe i� Model).Ce modèle est fon tionnellement omplet ependant nous avons vu dans la se tion 3.3.3 qu'ilest né essaire de réaliser une évaluation de la QoS et d'établir un ontrat global de QoS pours'assurer de la orre tion du système. C'est don l'objet de la partie suivante. 91

Chapitre 4. Évaluation de l'appro he4.2.4 Evaluation et ontrat de QoSL'étape d'évaluation de la QoS est réalisée en IF telle que ela est spé i�é dans la se tion3.3.3. Les informations né essaires à la réalisation de l'évaluation sont issues du SASM. Puisqueles évaluations sont e�e tuées sous onne teur par sous onne teur, un outil doit idéalement onvertir le SASM en un ensemble de systèmes IF exé utables a�n d'analyser la QoS modi�ée ensortie de haque sous onne teur (transformation notée III.3 sur la �gure 4.4). La QoS modi�éeainsi obtenue peut être ajoutée au modèle SASM (transformation notée III.4 sur la �gure 4.4).

Fig. 4.4 � Les pro essus de modélisation in rémentaux pour la validation d'un systèmeDésormais, la QoS modi�ée est onnue en sortie de haque sous onne teur, il reste à réaliserl'établissement des ontrats a�n de pouvoir établir le ontrat de QoS global. L'établissement du ontrat dépend de la te hnique utilisée pour dé rire la QoS ( onstante, intervalle ou expressionrégulière). La relation de satisfa tion est don pré isée dans le modèle noté Rules sur la �gure4.4. Lors du test d'admission (noté III.5 sur la �gure 4.4), soit la QoS requise est satisfaite parla QoS fournie, un ontrat est établi et on peut ontinuer l'établissement des ontrats jusqu'àl'établissement du ontrat global (III.6.2 sur la �gure 4.4) ; soit un des ontrats ne peut pas êtreétabli, auquel as un rapport d'erreur doit être généré et doit pré iser quelle est la ara téristiquede QoS qui ne peut pas être satisfaite. Il est alors possible d'adapter la QoS modi�ée par le onne teur orrespondant en ajoutant, par exemple, un omposant QoS_adapt ou en modi�ant92

4.3. Illustration de la méthodel'adaptation réalisée. Dans e as un nouveau pro essus de validation doit redémarrer à l'étapeIII.2 de la �gure 4.4.La partie suivante illustre ette méthode au travers d'un exemple simple.4.3 Illustration de la méthodeLes on epts de SAIA ont été présentés dans les hapitres pré édents. La mise en ÷uvre deSAIA ainsi que de la méthode proposée est illustrée dans ette partie par la réalisation partielled'un robot explorateur dont la spé i� ation sommaire est la suivante :Le robot se dépla e dans son environnement selon la onsigne en traje toire donnée par unopérateur. L'opérateur émet la traje toire sous la forme d'un �ot de données ontenant une suitede positions absolues à atteindre. Le robot ne doit pas s'éloigner à plus de 0.08 m de la traje toiredésirée. L'environnement du robot a une super� ie arrée de 400 m2 la plus simple possible : ellene ontient pas d'obsta le, pas de trou, est plane et ne possède pas de pentes. Le robot peut alorsse dépla er sur l'axe des X et des Y sans glissements. En�n, à l'origine, le robot se trouve à laposition à 100 m du bord gau he de la surfa e et à 10 m du bord inférieur.4.3.1 Réalisation du SAIM4.3.1.1 Étape 1 : extra tion des entrées / sortiesLa première étape onsiste à extraire les entrées et les sorties des spé i� ations sommaires quipré èdent. Dans un premier temps l'obje tif est de suivre une traje toire. Celle- i est expriméepar une donnée ayant le r�le Consigne. Elle est représentée par un ouple [X ; Y℄ de nombresréels :Consigne : Position_a_atteindretype : [�oat ; �oat℄,valeur minimum : [0 ; 0℄,valeur maximum : [200 ; 200℄,valeur initiale : [100 ;10℄,unité : [ m ; m℄.On pourrait exprimer la onsigne traje toire en deux entrées distin tes : une pour X, l'autrepour Y. Dans e as la mise en pla e d'une syn hronisation est né essaire pour éviter que l'ap-pli ation puisse lire une position erronée lorsqu'une seule des données est mise à jour. SAIA nedonne au une onsigne sur e niveau de modélisation.Plusieurs mesures sont né essaires pour e�e tuer le ontr�le du robot. Le robot doit savoiroù il est dans l'environnement a�n d'atteindre la pro haine Consigne. De plus, le robot doit onnaître son orientation a�n de pouvoir s'orienter vers la pro haine position à atteindre. Ainsi93

Chapitre 4. Évaluation de l'appro heon distingue deux données possédant le r�le Mesure. La position a tuelle [X ; Y℄ et l'orientationdu robot par rapport au nord magnétique ; toutes deux représentées par des nombres réels :Mesure : Position_a tuelletype : [�oat ; �oat℄,valeur minimum : [0 ; 0℄,valeur maximum : [200 ; 200℄,valeur initiale : [100 ;10℄,unité : [ m ; m℄.Mesure : Orientation_a tuelletype : �oat,valeur minimum : -π,valeur maximum : π,valeur initiale : 0,unité : radian.En�n, pour agir sur le pro essus robot, deux sorties de type md sont utilisées : une om-mande en vitesse notée avan er_a et une ommande en rotation, notée pivoter_de, toutes deuxreprésentées par des nombres réels :Commande : pivoter_de(param)type : �oat,valeur minimum : -π,valeur maximum : π,valeur initiale : 0,unité : radian.Commande : avan er_a(param)type : �oat,valeur minimum : 0,valeur maximum : 0.2,valeur initiale : 0,unité : m/s.Cet ensemble d'entrées et de sorties spé i�e la plateforme abstraite né essaire à la réalisationde l'appli ation de ontr�le du robot. En ore une fois, des di�éren es peuvent apparaître dansla dé�nition de la plateforme abstraite pour une même appli ation de ontr�le ; ependant laplateforme se doit de pré iser l'ensemble des �ots d'informations entre le monde extérieur etle système de manière indépendante d'une te hnologie spé i�que. La modélisation fon tionnelleobtenue dans l'outil est présentée �gure 4.5.4.3.1.2 Étape 2 : Réalisation de l'appli ation de ontr�leL'appli ation de ontr�le pour et exemple a été réalisée grâ e à l'outil Matlab/Simulink [82℄.Nous avons vu que l'appli ation de ontr�le est basée sur la plateforme abstraite. En omplément94

4.3. Illustration de la méthode

Fig. 4.5 � Modèle SAIM d'un robot explorateur simple dans l'outil SAIAde la modélisation du monde extérieur, la plateforme abstraite est la première hose à modéliserdans Simulink. Ensuite, une appli ation de ontr�le simple a été réalisée : la position et l'orienta-tion a tuelle sont prises en ompte périodiquement, le robot s'oriente vers la position à atteindreet avan e. La vitesse, quand à elle est proportionnelle à la distan e à par ourir entre la positiona tuelle et elle à atteindre au moment de la prise en ompte de la onsigne. Plus de détails surla modélisation Simulink de et exemple sont fournis dans [34℄.4.3.1.3 Étape 3 : Extra tion de la qualité de ontr�le à respe terLa qualité de ontr�le est, dans et exemple, à la fois simple et expli itement pré isée : �Lerobot ne doit pas s'éloigner à plus de 0.08 m de la traje toire désirée�. La qualité de ontr�le est,dans ertains as, exprimée de manière moins dire te. Par exemple, dans le as du robot, ellepourrait être exprimée par le fait que la traje toire à suivre par le robot peut, dans le pire des as, passer à 0,1 m d'un trou. Elle doit ependant toujours être exprimée.4.3.1.4 Étape 4 : Dérivation de la qualité de ontr�le en QoSPlusieurs paramètres in�uent sur la qualité de ontr�le du système. Nous �xons don dans unpremier temps tous les paramètres non relatifs à la plateforme abstraite. Dans notre as, ela serésume à la période d'a tivation de l'appli ation de ontr�le, �xé à 110ms. Pour un système plus omplexe, es paramètres sont déterminés par des appro hes métiers, souvent issues du domainede l'automatique.A�n de présenter lairement l'impa t de la QoS de la plateforme abstraite, nous �xonstous les paramètres de QoS de la plateforme abstraite sauf un : la loi de retard de l'entréeOrientation_a tuelle. Ainsi, ha une des lois d'arrivée des autres entrées sont �gées à 20mset leur loi de retard à 0s. Pour les sorties, le retard est �gé à 432ms.De nombreuses simulations sont né essaires pour déterminer la loi de retard sur l'Orienta-tion_a tuelle du robot a�n que la qualité de ontr�le soit respe tée. La première simulation95

Chapitre 4. Évaluation de l'appro he onsidère un retard nul sur l'entrée Orientation_a tuelle. Dans e as, la �gure 4.6 montrel'erreur entre la traje toire servant de Consigne et la traje toire e�e tuée par le robot. Cetteerreur est de 0.0713 m. L'erreur malgré la loi de retard nulle est due à la période d'a tivation del'appli ation de ontr�le, à la loi d'arrivée des di�érentes entrées et à la loi de retard des sorties.Fig. 4.6 � Erreur de traje toire pour une loi de retard nulleUn ensemble de simulations pour di�érentes valeurs de la loi de retard sur l'Orientation_a -tuelle du robot sont alors lan ées dans le but de déterminer le langage le plus permissif possibleassurant la orre tion du système. Dans le as du robot, après une inquantaine de simulation,nous avons abouti au langage suivant :Loi de retard requise surOrientation_a tuelle [[0ω − 0.049ω ] | [0 − 0.01] {3, } . [0.01 − 0.09] {, 4}]ωLes valeurs de l'expression sont exprimées en se onde.Cette expression exprime que, si le retard est onstant il ne doit pas dépasser 49ms sans quoi,non seulement la qualité de ontr�le n'est pas respe tée mais, en plus, le robot n'arrive pas àsuivre la traje toire désirée (le système devient instable). Lorsque le retard est variable, le retardpeut être ompris entre 0 et 10ms et il peut dépasser es valeurs un maximum de 4 fois tous les3 retards entre 0 et 10ms. La valeur de l'ex ès doit alors être inférieure à 90ms. Ce langage n'estpas le plus permissif, il permet uniquement de montrer qu'une spé i� ation de la QoS sous laforme d'une expression régulière plut�t que d'un intervalle permet d'obtenir plus de souplesselors du déploiement sur une plateforme réelle tout en gardant une même qualité de ontr�le.Ainsi, pour illustration sur la �gure 4.7, le retard sur l'entrée Orientation_a tuelle du robotforme un mot ompris dans le langage de la loi de retard requise ; le système respe te la qualitéde ontr�le.A ontrario, sur la �gure 4.8, la simulation a été e�e tuée ave un mot du retard de l'orien-tation a tuelle légèrement di�érent de eux dé�nis omme a eptable par l'expression régulièrede la QoS requise. En e�et, au lieu d'avoir un retard ompris entre 0 et 10ms lorsque l'on n'apas d'ex ès, le début du mot onsidéré (�gure 4.8) a un retard ompris entre 0 et 30ms. On voitalors que l'erreur sur la traje toire dépasse la qualité de ontr�le désirée, représentée par uneligne pointillée.4.3.1.5 Étape 5 : Finalisation du SAIMCette étape onsiste uniquement à inje ter dans l'outil de modélisation développé pour SAIAla QoS de la plateforme abstraite obtenue à l'aide des simulations présentées dans la se tion96

4.3. Illustration de la méthode

Fig. 4.7 � Erreur de traje toire pour une loi de retard respe tant le langage de retard requis

Fig. 4.8 � Erreur de traje toire pour une loi de retard ne respe tant pas le langage de retardrequispré édente.4.3.2 Réalisation du SAMComme souvent, plusieurs SAM sont envisageables a�n d'a quérir ou de réaliser les en-trées/sorties spé i�ées dans le SAIM. Par exemple, l'entrée Position_a tuelle peut être fourniepar un GPS (Global Positioning System) aussi bien que par des points de repère dans l'environ-nement. De la même façon, l'entrée Position_a_atteindre peut être fournie par la manipulationd'un joysti k, par le suivi d'une ligne sur le sol, et .Il n'est pas rare que la plateforme réelle en termes de pilotes d'a quisition et de réalisation soitliée à une infrastru ture physique parti ulière. Dans l'exemple hoisi, l'infrastru ture physiquedu robot est omposée de deux roues motri es indépendantes de diamètre d et diamétralementopposées par un axe de longueur d sur lesquelles vient se gre�er le � orps� du robot ( f. �gure4.9). 97

Chapitre 4. Évaluation de l'appro he

Fig. 4.9 � Infrastru ture physique simpli�ée liée à la plateforme réelleLa plateforme réelle est omposée de quatre pilotes d'a quisition de données : la vitesse rouedroite, la vitesse roue gau he, un GPS fournissant la position en oordonnées artésienne et unpilote qui génère la position à atteindre en oordonnées polaires.� vitesse_roue_droite / vitesse_roue_gau hetype : �oat,valeur minimum : -30,valeur maximum : 30,valeur initiale : 0,unité : tour/s.� GPS type : [�oat ; �oat℄,valeur minimum : [-100 ; -100℄,valeur maximum : [100 ; 100℄,valeur initiale : [100 ; 10℄,unité : [ m ; m℄.� générateur_positiontype : (�oat ; �oat),valeur minimum : (0 ; -π),valeur maximum : (0.1 ; π),valeur initiale : (100 ; 10),unité : [ m ; radian℄.La plateforme réelle omporte également deux pilotes de réalisation de ommandes : un pilotedu moteur lié à la roue droite et un moteur lié à la roue gau he du robot.� roue_droite_avan er(param) / roue_gau he_avan er(param)type : �oat,valeur minimum : 0,valeur maximum : 0.2,valeur initiale : 0,unité : m/s.La modélisation fon tionnelle réalisée dans l'outil SAIA est présentée sur la �gure 4.10L'étape d'analyse de la QoS de ha un des pilotes n'est pas détaillée i i. Cependant, l'anal-yse des deux apteurs d'a quisition de données vitesse_roue_droite et vitesse_roue_gau hedonne une loi de retard onforme à l'expression régulière suivante :98

4.3. Illustration de la méthode

Fig. 4.10 � Modèle SAM d'un robot explorateur simple dans l'outil SAIA[[0.005] {5, } . [0.01 − 0.06] {, 1}]ωLes valeurs de l'expression sont exprimées en se onde.Textuellement, ha un des pilotes fournit des o urren es ave un retard de 0.005 se ondemais pour une o urren e sur 6, le retard peut être ompris entre 0.01 et 0.06 se onde.

4.3.3 Réalisation de l'ALM4.3.3.1 Étape 1 : stru ture des sous onne teursCette étape permet de spé i�er les pilotes qui entrent dans l'a quisition ou la réalisation de haque entrées et de haque sorties. La stru ture du système est donnée sur la �gure 4.11.On voit que le pilote du GPS permet l'a quisition de l'entrée Position_a tuelle, les pilotesvitesse_roue_droite et vitesse_roue_gau he fournissent l'entrée Orientation_a tuelle. Lavitesse fournie par les pilotes d'a quisition est exprimée en tour par se onde. A�n de pouvoir al uler l'orientation du robot, il est né essaire de onnaître d'une part le diamètre des roues durobot (pour al uler la vitesse sur la roue droite et sur la roue gau he en entimètre par se onde)et d'autre part de onnaître la taille de l'axe entre les deux roues (pour en déduire la rotation durobot et de fait, son orientation). Ces deux informations ne varient pas lors de l'exé ution et sontdon renseignées à l'aide de deux onstantes notées d pour le diamètre des roues et e pour l'é artentre les deux roues. L'entrée Position_a_atteindre, ayant le r�le de Consigne est a quise parle pilote générateur_position. En�n les deux sorties avan er_a et pivoter_de sont réaliséestoutes deux par les pilotes roue_droite_avan er et roue_gau he_avan er. 99

Chapitre 4. Évaluation de l'appro he

Fig. 4.11 � Modèle SASM d'un robot explorateur simple dans l'outil SAIA4.3.3.2 Étape 2 : stru ture de la �glue� des sous onne teursCette étape et la suivante ne sont détaillées que pour le sous onne teur en harge de l'adap-tation entre les pilotes vitesse_roue_droite et vitesse_roue_gau he a�n qu'ils fournissentl'entrée Orientation_a tuelle. Ce sous onne teur utilise les deux onstantes dé rites dansla se tion pré édente. En e�et, les pilotes de vitesse des roues fournissent un �ot de donnéesexprimées en tour/s, le diamètre d est utilisé par les deux omposants de type Format a�n detraduire ette vitesse en m/s. De plus, l'é art e est utilisé par le omposant de type Interpreta�n de al uler la rotation du robot et en déduire son orientation. On remarque que le omposantde type Interpret est également en harge de la fusion des deux �ots de données en provenan edes omposants de type Format ( f. �gure 4.12).

Fig. 4.12 � Stru ture de la �glue� du sous onne teur réalisant l'a quisition deOrientation_a tuelle100

4.3. Illustration de la méthode4.3.3.3 Étape 3 : spé i� ation des omposants de la �glue�Durant ette étape, ha un des trois omposants spé i�ant la �glue� présentée pré édemmentest spé i�é. Pour les omposants de type Format, il est né essaire de spé i�er la fon tion asso iée.Cette fon tion est abstraite par sa durée d'exé ution dont le budget temporel est �xé à 10ms.Pour la spé i� ation du omposant de type Interpret, deux hoix di�érents peuvent être faits.Soit, on hoisit un automate prédé�ni dans la boîte à outils fournie par l'outil SAIA, soit on onstruit un automate parti ulier. Un automate prédé�ni a été hoisi, il génère une o urren eà haque fois qu'il reçoit une o urren e de ha un de ses �ots d'entrée. Une fois l'automate hoisi, il reste à spé i�er la fon tion en harge de la fusion des deux o urren es olle tées. Cettefon tion est également abstraite par ses informations extra-fon tionnelles. Ainsi, deux budgetstemporels sont dé�nis : le BCET, égal à 30 ms et le WCET, égal à 40ms.Une fois les étapes 2 et 3 réalisées ( f. se tion 4.2.3) pour ha un des sous onne teurs,on obtient un système omplet du point de vue fon tionnel. La QoS en sortie de haque sous onne teur doit maintenant être évaluée a�n de permettre l'établissement des ontrats de QoS.4.3.4 Réalisation de l'évaluation de la QoSComme pour les deux étapes pré édentes, e hapitre ne détaille que l'ensemble omprenantles deux pilotes de vitesse des roues ainsi que le sous onne teur et l'entrée asso iés. Nous possé-dons tous les éléments permettant de onnaître la QoS modi�ée en sortie de e sous onne teur :� l'expression régulière exprimant la QoS requise par l'entrée sur la loi de retard ;� l'expression régulière exprimant le retard fourni par ha un des pilotes ;� le omportement du sous onne teur.Malgré la simpli ité apparente de l'exemple, il est di� ile de prédire si le ontrat peut êtreétabli ou non. Cette partie du système sous étude est exé utée par la suite d'outils IF. Suiteà l'exé ution, après avoir véri�é que le LTS obtenu est un graphe y lique sans état bloquant,après avoir a hé ses transitions non pertinentes et après avoir e�e tué les rédu tions, on obtientle LTS exprimant la QoS modi�ée en sortie du sous onne teur ( f. se tion 3.3.3).La pro haine étape onsiste alors à véri�er si le ontrat peut, ou ne peut pas, être établi.4.3.5 Réalisation de l'établissement du ontrat de QoSUn ontrat peut être établi si l'équivalen e de sous langage entre la QoS fournie et la QoSrequise est véri�ée. Ce i est réalisé grâ e à l'outil �bisimulator� de la suite CADP [47℄. A�nde véri�er si la relation de sous langage existe, nous utilisons la relation d'équivalen e de tra eimplémentée dans CADP. Pour le sous onne teur présenté pré édemment, l'équivalen e de tra eest véri�ée. La relation QoS_requise �satis�es� QoS_fournie est don vrai et le ontrat peutêtre établi. Cependant, il faut remarquer que si l'on hange le budget temporel du WCET de lafon tion omprise dans le omposant de type Interpret du sous onne teur de 40ms à 50ms, larelation de sous langage n'est plus satisfaite. Dans e as l'outil bisimulator donne le diagnosti suivant : 101

Chapitre 4. Évaluation de l'appro hedoes providedQoS.aut tra e_equivalent_to requiredQoS.aut ?b g_open : using �/usr/lo al/ adp/bin.iX86/bisimulator.a�b g_open : running �bisimulator -smaller -diag -tra e requiredQoS.b g� for �./providedQoS.b g�FALSE** diagnosti sequen e found at depth 5<start state>�DLo = p1=11 ��DLo = p1=11 ��DLo = p1=11 ��DLo = p1=11 ��Absent in requiredQoS.b g : DLo = p1=11 �<goal state>Ce diagnosti indique qu'une violation est déte tée sur QoSocc5. En e�et, l'expression réguli-ère dé rivant les mots de la QoS requise ( f. se tion 4.3.1.4) spé i�e que le nombre d'o urren ede retard peut ex éder 10ms jusqu'à hauteur de 90ms mais seulement un maximum de 4 fois onsé utives toutes les 7 o urren es. Ainsi l'outil diagnostique qu'une suite de 5 o urren es onsé utives dépassant 10ms (dans e as égale à 11ms) ne fait pas parti du langage de la QoSrequise. Le ontrat ne peut don pas être établi4.3.6 Con lusion sur l'illustration de la méthodeL'exemple présenté i-avant permet de montrer l'en haînement des étapes de la méthodeproposée. Il permet également de montrer l'intérêt d'une spé i� ation pré ise de la QoS surles entrées et les sorties a�n d'atteindre une ertaine qualité de ontr�le par l'appli ation. Cedo ument ne traite pas la manière de dériver les ontraintes de la qualité de fon tionnement en ontrainte de QoS sur les entrées et les sorties.Une fois la QoS sur la plateforme abstraite (les entrées et les sorties) spé i�ée et la QoSmodi�ée par un sous onne teur évaluée, la relation de sous langage doit être véri�ée pourétablir un ontrat. Dans le as où la relation de sous langage n'est pas respe tée, l'outil véri�antla relation permet d'indiquer la première des o urren es de QoS fautive. Il est à noter que pourla onnaissan e de l'o urren e de QoS fautive n'est pas su�sante pour indiquer la modi� ationà réaliser dans la �glue� pour pouvoir établir le ontrat de QoS.Nous montrons maintenant une utilisation alternative de SAIA pour la mise au point tem-porelle du système.4.4 SAIA pour la mise au point de systèmesNous avons vu que l'utilisation de l'ar hite ture et des outils IF asso iés permet d'évaluer laQoS résultant d'une on�guration de omposants SAIA. Cette évaluation peut être fournie demanière pré ise à l'aide d'expressions régulières mais aussi de manière bornée à l'aide d'intervalles.Il est don possible d'évaluer, par exemple, le retard maximum de la donnée en sortie d'un onne teur pour une on�guration donnée. Les outils d'évaluation peuvent alors servir d'aide102

4.4. SAIA pour la mise au point de systèmesà la mise au point d'un système. Il est par exemple possible d'e�e tuer une série d'évaluationen faisant varier un ou plusieurs paramètre(s) temporel(s) d'un système a�n de hoisir une on�guration respe tant la propriété re her hée.

Fig. 4.13 � Exemple de variation de deux paramètres temporels dans une on�gurationPour illustrer ette utilisation de SAIA, nous onsidérons un système représentant un ban detest moteur, né essitant la onnaissan e de la masse volumique de l'air entrant dans le moteur.La masse volumique d'un gaz est al ulée en fon tion de sa température et de sa pression. A�nd'obtenir une bonne estimation de la masse volumique du gaz il est né essaire de posséder desvaleurs de la température et de la pression ayant une orrélation temporelle faible. Dans esystème nous onsidérons la onstru tion de l'entrée Masse volumique. Pour e faire, un premierpilote d'a quisition noté Capteur 1 fournit un �ot de données représentatif de l'évolution dela pression de manière périodique toutes les 100ms. Lorsque le pilote d'a quisition fournit uneo urren e, elle- i possède un retard initial de 9ms. Un deuxième pilote d'a quisition (notéCapteur 2) fournit un �ot de données représentant l'évolution de la température. Le �ot dedonnée est périodique et sa période peut être ajustée entre 10 et 30ms. Quelque soit la périodedu pilote d'a quisition, le retard initial de ses o urren es est de 1ms. Avant d'être fusionnées,les �ots de données subissent une étape de formatage. Le temps d'exé ution de la fon tion deformatage du �ot fournissant la pression peut être ajustée entre 1 et 19ms alors que la fon tionde formatage du �ot de température est de 1ms. Sa hant que la fon tion de fusion a un tempsd'exé ution de 1ms, on désire hoisir une on�guration garantissant une orrélation temporelleinférieure ou égale à 15ms en ajustant les paramètres du système (la période de Capteur 2 et letemps d'exé ution de Format 1).A�n de répondre à e problème, il est possible de lan er une série d'évaluation de la QoSpour haque valeur de la loi d'arrivée de Capteur 2 et pour haque temps d'exé ution de Format1. Pour lan er la série d'évaluation il est né essaire de ontraindre les hypothèses on ernant lasyn hronisation entre les pilotes d'a quisition. Typiquement, lors d'une analyse de type RMA,au une hypothèse n'est faite sur la syn hronisation des pilotes d'a quisition du système. Cetteanalyse donne alors une borne maximale souvent pessimiste. La représentation IF du modèlepermet d'a�ner e paramètre en fournissant des bornes de minimales et maximales de syn hro-nisation. 103

Chapitre 4. Évaluation de l'appro heUne fois les ontraintes de syn hronisation spé i�ées, il est possible de lan er la série d'é-valuation de la QoS et ainsi de dé�nir l'ensemble des ouples de la loi d'arrivée et du tempsd'exé ution permettant d'obtenir une orrélation temporelle maximum inférieure à 15ms. A�nd'illustrer graphiquement les résultats de ette appro he, nous avons réalisé deux séries d'éval-uation. La première fait l'hypothèse que les pilotes sont syn hronisés. On voit alors l'évolutionde la orrélation temporelle maximale (axe Z) selon la loi d'arrivée de Capteur 2 et de Format1. Sur les �gures 4.14 et 4.15, les on�gurations permettant d'obtenir une orrélation temporelleinférieure ou égale à 15 sont olorées en orange. Sur la �gure 4.14, on remarque une évolutionnon intuitive de la orrélation temporelle. On remarque également les points de syn hronisationintéressants du système (période de Capteur 2 égale à 20 ou 25ms). La deuxième série d'évalu-ation fait l'hypothèse que les pilotes d'a quisition sont, dans le pire des as, déphasés de 30ms.Puisque l'on regarde l'évolution de la orrélation temporelle maximale, on remarque, sur la �gure4.15, que ertains phénomènes de syn hronisation sont atténués. Les phénomènes de syn hroni-sation intervenant pour une période de Capteur 2 égale à 20 ou 25ms sont ependant toujoursprésents.Sur les deux représentations graphiques, on remarque qu'il est possible de hoisir un ouplea eptable possédant un temps d'exé ution de Format 1 et une période de Capteur 2 élevés.Ce i permet, entre autre de ne pas sur harger le système en ne onsidérant que les as les pluspessimistes.

0

5

10

15

20

25

30

10 15

20 25

30

0

5

10

15

20

0

5

10

15

20

25

30

periode de Capteur 2

temps d’execution de Format 1

Fig. 4.14 � Corrélation temporelle maximale de la donnée agrégée lorsque les pilotes des apteurssont syn hronisésL'exemple utilisé i i utilise des spé i� ations de la QoS sous forme d'intervalle. De plus lavaleur extraite de l'évaluation est une borne maximale de la orrélation temporelle. En�n, nousne faisons varier que deux paramètres dans le système. Ce i a pour de but de pouvoir représentergraphiquement les résultats. Cependant, il est également possible d'utiliser ette appro he ave 104

4.5. Con ours no 1 : The maRTian Task

0

5

10

15

20

25

30

10 15

20 25

30

0

5

10

15

20

0

5

10

15

20

25

30

periode de Capteur 2

temps d’execution de Format 1

Fig. 4.15 � Corrélation temporelle maximale de la donnée agrégée lorsque les pilotes des apteurssont désyn hronisés au maximum de 30msdes expressions régulières et ha une des relations de satisfa tion présentées dans la se tion 3.3.4.Il est également possible de faire varier plus de deux paramètres.Maintenant que les utilisations possibles de SAIA ont été dé rites et illustrées, les se tionssuivantes présentent la mise en ÷uvre de SAIA, réalisée pour la modélisation de deux as d'étudeplus onséquent : maRTian Task2 et CiberMouse 3. Ce sont tous deux des robots explorateurproposés lors de on ours internationaux.4.5 Con ours no 1 : The maRTian TaskLe on ours �maRTian Task� a été proposé en temps d'évènement satellite de la onféren eReal Time System Symposium en dé embre 2005. Le but est le développement du ontr�le d'unrobot explorateur devant aller de leur position d'origine à un point B dans un environnementa priori in onnu. Le robot a une vue limitée du monde et doit impérativement éviter les trousa�n de rester en vie. Ce on ours a donné lieu à une ompétition durant laquelle le but étaitd'arriver le premier au point B. La plateforme d'exé ution du robot n'était pas imposée mais saplateforme de ommuni ation ave l'environnement est basée sur un simulateur fourni par lesorganisateurs du on ours. L'appro he SAIA a don été employée d'une part pour réaliser unemise en ÷uvre réelle de l'appro he et d'autre part pour montrer l'intérêt d'une telle appro he2http ://www.ertos.ni ta. om.au/events/05/rtss_ ompetition.pml3http ://www.ieeta.pt/∼lau/web_ iberRTSS/info.htm 105

Chapitre 4. Évaluation de l'appro helors d'un développement basé sur un simulateur.Après une présentation du simulateur fourni pour le on ours, ette se tion aborde su - in tement les problèmes qui apparaissent lorsqu'une appli ation de ontr�le est développée surun simulateur avant d'être déployée sur une plateforme réelle. Ensuite, quelques solutions liées àl'utilisation de SAIA sont proposées pour répondre à es problèmes. En�n, les modèles ainsi queleur mise en ÷uvre sont rapidement présentés.4.5.1 Le simulateur asso ié à maRTian TaskLe simulateur a été développé par the Institute for Real-Time Computer Systems de Muni het modi�é à l'o asion du on ours par l'équipe Embedded and Real-time Operating Systemsde l'université de Sydney (National ICT Australia Ltd.). Il fournit des �ots de données surl'environnement et onsomme des �ots de ommandes et de ommandes événementielles pour ontr�ler le pro édé. Plus pré isément, le simulateur possède 4 pilotes d'a quisition de donnéespermettant de onnaître l'état du monde extérieur :� pilote fournissant l'état des bumpers du robot ( ollision),� pilote fournissant l'état des sonars du robot (présen e d'un trou),� pilote fournissant l'état du robot (en mar he, mort, et ),� pilote fournissant la position et l'orientation du robot.

Fig. 4.16 � Présentation de l'infrastru ture physique virtuelle de maRTian TaskLe simulateur omprend également trois pilotes de réalisations permettant de ontr�ler lepro édé, les deux premiers sont des pilotes de réalisation de ommandes et le dernier un pilotede réalisation de ommandes événementielles :� pilote réalisant la rotation du robot,� pilote réalisant le dépla ement du robot,� pilote réalisant l'arrêt du robot.Cha un des pilotes est fourni ave une spé i� ation de sa QoS en termes de loi d'arrivéeminimale et maximale. De plus le simulateur introduit des erreurs de le ture des apteurs sousla forme de probabilité. Ainsi, des faux négatifs et des faux positifs peuvent apparaître. Unereprésentation simpli�ée de l'infrastru ture virtuelle du robot est donnée �gure 4.16.106

4.5. Con ours no 1 : The maRTian TaskDe ette des ription du simulateur, fournie pour le on ours, dé oule le modèle SAM. Lemodèle SAIM n'est pas détaillé i i. On remarque ependant sur le �gure 4.17 que les entrées etles sorties identi�ées dans la plateforme abstraite ne font pas de suspi ions sur le SAM sous-ja ent. De plus, la plateforme abstraite ontient uniquement les entrées et les sorties né essairesà la réalisation de la mission dé rite pour le on ours.

Fig. 4.17 � Présentation du modèle SASM obtenu pour maRTian Task4.5.2 Déployer l'appli ation de ontr�le sur une ible réelleL'utilisation d'un simulateur pour le développement d'une appli ation de ontr�le est une aidepré ieuse. Cependant des problèmes dus au manque de réalisme des simulateurs interviennentlors du déploiement de l'appli ation de ontr�le sur une ible réelle. Le manque de réalisme peutintervenir au niveau fon tionnel omme au niveau extra fon tionnel. Si es dévian es par rapportà une ible réelle ne sont pas maîtrisées, elles peuvent modi�er, lors du déploiement, la stru tureet la qualité de ontr�le du système (sa pré ision, voire sa stabilité).Au niveau fon tionnel, les servi es fournis par le simulateur et une plateforme réelle peuventêtre di�érents : il peut, par exemple, exister un pilote par sonar, un pilote pour la positiondi�érent de elui pour l'orientation, la position peut être donnée de manière relative par rapportau point de départ, et . De la même façon, au niveau extra fon tionnel, des di�éren es entrele simulateur et une ible réelle apparaissent. Par exemple, dans maRTian Task, la le ture dessonars est perturbée de manière probabiliste par l'apparition de faux positifs et de faux négatifs.Le manque de réalisme à e niveau vient du fait que lorsqu'un faux négatif (ou un faux positif)apparaît, des le tures su essives du même apteur donnent le même faux négatif (ou fauxpositif) tant que le robot n'a pas bougé (tourné, avan é ou re ulé). Ce type de omportement estdon lairement di�érent de elui d'un apteur réel et peut impa ter la validité de l'appli ationde ontr�le. Un autre manque de réalisme du simulateur est le fait que l'envoi d'une ommande107

Chapitre 4. Évaluation de l'appro hed'arrêt au pilote de réalisation arrête le robot instantanément. Un vrai robot ne peut pas s'arrêterinstantanément, il possède un minimum d'inertie, e qui implique un retard avant l'arrêt durobot. En�n, les retards des o urren es en provenan e des apteurs sont nuls. En ore une fois es valeurs manquent de réalisme.4.5.3 SAIA et le développement basé sur un simulateurComme nous venons de le voir au travers du simulateur proposé pour le on ours, il est di� iled'obtenir un simulateur réaliste. Il est alors di� ile de tester (voire de valider) une appli ationde ontr�le sur un simulateur en espérant préserver e omportement lors du déploiement surune plateforme réelle. A�n de ontourner e problème, il est possible de modi�er, au sein du onne teur omplexe, la QoS fournie/requise par la le simulateur et ainsi s'appro her d'uneQoS réaliste. Ce i peut par exemple se faire par l'ajout de retard, par un �ltrage de ertaineso urren es, et . En parti ulier dans notre as, il est intéressant d'augmenter le retard sur l'arrivéedes o urren es de sonars et sur l'arrêt du robot a�n de trouver, a priori, les lois de retardpermettant au robot de ne pas tomber dans les trous une fois le déploiement e�e tué. Il peutégalement être intéressant de �ltrer ertaines o urren es du �ot de données en provenan e duGPS a�n de trouver, en ore une fois, les limites permettant au robot d'e�e tuer sa mission.Ainsi, de la même façon qu'il est possible de dériver les ontraintes de qualité de fon tion-nement en QoS sur la plateforme abstraite à l'aide d'un simulateur de la plateforme abstraitesous Matlab, il est possible i i, de dériver les ontraintes à l'aide d'un simulateur de la plateformeréelle et d'une modi� ation de sa QoS par le onne teur omplexe.Maintenant que le simulateur et l'utilisation de SAIA pour le développement sur simulateura été présenté, la se tion suivante présente les hoix réalisés pour l'implémentation des di�érentsmodèles.4.5.4 La mise en ÷uvre des modèlesLa modélisation du système en a ord ave les spé i� ations fournies par maRTian Task apermis d'aboutir au modèle SASM dé rit par la �gure 4.17Une fois le système modélisé, il est né essaire de l'implémenter dans un langage spé i�queet d'établir un modèle de tâ hes [8℄. Il existe di�érentes stratégies de mise en ÷uvre d'une on�guration ( f. se tion 2.2.5). Notre premier hoix fut d'ex lure l'utilisation d'un intergi ielmais plut�t de ompiler la on�guration pour obtenir un ode monolithique. Ce i est entre autresmotivé, aux vues du on ours, par l'inutilité de réi�er les omposants à l'exé ution et la re her hed'un omportement temporel optimisé. Nous avons don hoisi de réaliser l'implémentation enC++. À un omposant nous faisons orrespondre une lasse et un objet. Dans le but de serappro her de la sémantique opérationnelle de IF, la ommuni ation entre les objets passe parune zone de mémoire partagée permettant de représenter une �le d'attente de type FIFO et detaille 1.108

4.5. Con ours no 1 : The maRTian TaskPour atteindre les obje tifs temps réel, il est né essaire de fournir une gestion de la on urren eentre les objets. On trouve deux appro hes prin ipales pour gérer ette on urren e : �event-based� and �obje t-based� [90℄. Résumée rapidement, la stratégie obje t-based rée une tâ hepar objet alors que l'appro he �event-based� rée une tâ he par �l d'événement temps réel. Lastratégie �obje t-based� est plus simple à mettre en ÷uvre mais augmente les se tions ritiquesainsi que l'utilisation du CPU. A ontrario, la stratégie �event-based� permet de réduire les tempsde blo ages mais demande la mise en pla e expli ite d'un modèle de tâ hes orthogonal aux objets ; e fut la stratégie hoisie. Le modèle de tâ hes est orthogonal à elui des objets puisque lié auxévénements temps réel. Chaque a tion dé len hée par l'événement temps réel est exé utée dansune tâ he spé i�que. DansmaRTian Task, le seul événement dé len hant une tâ he temps réel estla demande d'arrêt d'urgen e (urgent_stop), dé len hé sur la déte tion d'un trou par le piloted'a quisition des sonars. Une tâ he événementielle est don réée et liée à l'élément dé len heur(l'a tivation d'un sonar). Les opérations des objets permettant d'exé uter l'arrêt du robot sontalors exé utées dans ette tâ he. L'événement dé len hant potentiellement la tâ he est issu de lale ture d'une déte tion d'un sonar dans le �ot de données a quis par le pilote asso ié. Les pilotesd'a quisition ont tous la même loi d'arrivée périodique, les envois des o urren es qu'ils génèrentsont don regroupés au sein d'une même tâ he, dé len hée périodiquement. En�n, le reste desa tivités (re her he de hemin, politique d'évitement) sont regroupé au sein d'une autre tâ he,également dé len hée périodiquement. On distingue ainsi trois tâ hes :� la tâ he périodique réalisant la le ture des apteurs (en orange �gure 4.18),� la tâ he sporadique réalisant l'a tivité urgente (en bleu �gure 4.18),� la tâ he périodique regroupant les a tivités non urgentes (en jaune �gure 4.18).Le modèle de tâ hes est présenté sur la �gure 4.18. On remarque la présen e d'objets partagésentre les tâ hes (en vert �gure 4.18). Ces objets sont protégés par un a ès en ex lusion mutuelle.

Fig. 4.18 � Présentation du modèle des tâ hes hoisi pour maRTian TaskCette mise en ÷uvre n'a pour but ni de hoisir une implémentation pour SAIA ni de formaliserla mise en ÷uvre des modèles dans SAIA mais plut�t de s'assurer de la faisabilité des modèles à109

Chapitre 4. Évaluation de l'appro hel'exé ution. De plus, ela nous a permis de nous rendre ompte que la stru turation gros grainset la séparation des aspe ts dépendant et indépendant de la plateforme fa ilite l'implémentationdu système. En e�et, une fois les modèles réalisés, ha un des omposants peut être développéde manière indépendante des autres omposants.Si l'on désire s'assurer de la onformité de l'implémentation par rapport aux modèles présen-tés, des analyses supplémentaires doivent être réalisées a�n de s'assurer que la sémantique opéra-tionnelle de l'implémentation est onforme à elle des modèles ( .a.d. à elle de IF).L'implémentation des modèles, né essaires pour répondre aux exigen es de e on ours, nousa permis de produire un ode qui a rapporté une deuxième pla e lors de la ompétition. Ce iillustre que génie logi iel et performan es ne sont pas obligatoirement ontradi toires. Maintenantque maRTian Task a été présenté, la réutilisation de son modèle SAIM dans le adre du on ours�The CiberMouse Proje t� est présentée dans la partie suivante.4.6 Con ours no 2 : The CiberMouse Proje tLe but de e on ours était, omme pour le on ours numéro 1, le développement, basé surun simulateur, du ontr�le d'un robot explorateur. Le but du ontr�le est quelque peu di�érentde elui de l'année pré édente et le simulateur est, lui, omplètement di�érent. A�n de remporterle on ours, il est prin ipalement demandé que le robot e�e tue sa mission plus rapidement queses adversaires. Cependant, notre parti ipation avait pour but d'évaluer la propension de SAIAà réutiliser un modèle SAIM sur des plateformes di�érentes.Après une des ription de CiberMouse, les points ommuns et les di�éren es entre les missionset les simulateurs des deux on ours sont présentés. Ensuite, une deuxième puis une troisièmepartie présente respe tivement les hangements apportés au SAIM et la modélisation du on-ne teur omplexe. En�n, une dernière partie on lue sur une ritique de l'appro he.4.6.1 CiberMouse versus maRTian TaskDurant le premier on ours, le but de haque robot est d'aller de leur position d'origine à unpoint B, tous deux onnus a priori, sans tomber dans un trou. Dans le deuxième on ours, latâ he des robots est d'aller de leur position d'origine à une surfa e ible signalée par un émetteurde lumière infrarouge et de retourner à leur position d'origine. Le s ore est d'autant meilleur quele robot e�e tue sa tâ he rapidement et sans ollision ontre les murs ou les autres robots en jeu.La position d'origine, la surfa e ible, les murs et les autres robots sont in onnus du robot à ontr�ler.Dans les spé i� ations de CiberMouse, des similarités et des di�éren es apparaissent ave lesspé i� ations de maRTian Task. Parmi les similarités, on observe que dans les deux on ours :� il est né essaire de se dépla er d'un point A à un point B dans un environnement non onnu a priori,110

4.6. Con ours no 2 : The CiberMouse Proje t� il est né essaire d'avoir une politique d'évitement des obsta les.On observe ependant des di�éren es entre les missions :� un robot CiberMouse doit retourner à sa position initiale une fois la ible atteinte,� un robot CiberMouse ne onnait ni sa position initiale ni la position de la ible.� un robot CiberMouse doit informer le simulateur de l'état dans lequel il se trouve.Malgré es di�éren es, nous dé idons de réutiliser le SAIM de maRTian Task ontenant, dansl'appli ation de ontr�le, l'algorithme de re her he de hemin et l'algorithme d'évitement d'ob-sta les. Pourtant, CiberMouse demande également d'autres fon tionnalités telles que la re her hede la ible ou en ore la ommuni ation de son état au simulateur.Au niveau de la plateforme réelle (i i le simulateur), le orps virtuel du robot est de forme ylindrique et équipé de apteurs et d'a tionneurs ( f. �gure 4.19). Plus pré isément, il est équipéde quatre apteurs d'obsta les, d'un apteur de lumière infrarouge donnant l'angle relatif dedéte tion de la lumière, d'une boussole et d'un apteur de ollision. Le robot omprend égalementdeux moteurs diamétralement opposés permettant le ontr�le de deux roues indépendantes demanière di�érentielle. Pour ommuniquer ave le simulateur et les utilisateurs, le robot omprendtrois diodes éle trolumines entes permettant de onnaître son état. Les spé i� ations omplètesdu on ours sont données dans [35℄. Il faut remarquer que ontrairement au on ours pré édent,le simulateur ne fournit ni la position du robot, ni son orientation. De plus, le nombre et ladisposition des apteurs d'obsta les (bumper + sonars) sont di�érents. En�n, la gestion desdépla ements est également di�érente.

Fig. 4.19 � Infrastru ture physique virtuelle du robot utilisé pour le on ours CiberMouseLa se tion suivante présente et dis ute les modi� ations mineures apportées au SAIM. En-suite, puisque le SAM est imposé par le simulateur, les hangements apparaissent dans le on-ne teur omplexe dont la réalisation est détaillée. En�n, une troisième partie donne les béné� eset limites mis en avant dans et exer i e de réutilisation. 111

Chapitre 4. Évaluation de l'appro he4.6.2 Les modi� ations dans le SAIMLe SAIM de maRTian Task a été modi�é ; plus pré isément, il a été étendu. En e�et, en regar-dant les sorties identi�és dans le SAIM de maRTian Task, on se rend ompte qu'au une d'entreelles ne permet de ommuniquer les informations sur l'état du robot à l'environnement. De efait nous ajoutons une sortie : Mission_info qui permet de renseigner sur l'état de la mission durobot (re her he de la ible, sur la ible, sur le hemin du retour, arrivé à destination). La deux-ième extension qui fut né essaire on erne la manière de manipuler ette nouvelle sortie. Pour e faire, nous avons ajouté les états présentés pré édemment à l'entrée existante robot_state.Malgré es extensions, les fon tionnalités prin ipales du SAIM telles que la re her he de heminou l'évitement d'obsta les n'ont pas été modi�ées. Les autres fon tionnalités né essaires pourréaliser les spé i� ations de CiberMouse ont don été réalisées dans le onne teur omplexe.4.6.3 Le onne teur omplexeLe onne teur omplexe, en harge de la liaison du SAIM et du SAM, a dans e as pré isdeux fon tions prin ipales. Premièrement, il doit utiliser les servi es du SAM pour a quérir lesentrées, et réaliser les sorties du SAIM. Deuxièmement, il doit �piloter� le SAIM a�n de réaliserles fon tionnalités non dire tement liées à la re her he de hemin ou à l'évitement d'obsta les.Cha une de es deux fon tions sont présentées au travers de :1. la manière d'a quérir la position et l'orientation du robot,2. la manière de piloter le SAIM par l'a quisition de l'entrée goal_position.4.6.3.1 L'a quisition de la position du robotLa position absolue et l'orientation du robot (entrée notée a tual_position) sont né essairesà l'appli ation. Malheureusement, le simulateur fourni pour le on ours CiberMouse n'o�re au unpilote d'a quisition pouvant produire es entrées. De e fait, a�n d'évaluer la position du robot,on rée un al ul en bou le ouverte ( f. �gure 4.20). L'idée de la bou le ouverte est d'évaluer

Fig. 4.20 � A quisition de l'entrée a tual_position en bou le ouverte112

4.6. Con ours no 2 : The CiberMouse Proje tla position et l'orientation du robot d'après les Commandes en dépla ement que l'on envoieau SAM. Pour ela, les trois sorties nommées Run, Stop et Turn_of_X sont, dans un premiertemps, traduites par le sous onne teur 2 en Commandes de bas niveau pour les pilotes deréalisation Right_motor_speed et Left_motor_speed. Ces Commandes, notées RMS et LMS(Right/Left Motor Speed) sont également envoyées au sous onne teur 1, en harge de l'a quisitionde l'entrée a tual_position. Ainsi, dans le sous onne teur 1, les deux Commandes de basniveau RMS et LMS sont agrégées par un omposant de type Interpret. Ce omposant, à l'aidede la position pré édente, de la dynamique des moteurs et de la inétique du robot (i i fourniespar le simulateur), est apable de al uler la position résultante du robot. A�n de posséder unmaximum de pré ision et éviter les dérives, les o urren es de la position sont al ulées à la même aden e que le simulateur, 'est-à-dire à ha un de es y les. Cependant, a�n d'éviter les oûtsde ommuni ation de la position à haque y le, elle i est �ltrée par un omposant de typeQoS_adapt et n'est mise à jour dans a tual_position qu'un y le sur trois. Si le oût induit parun al ul de l'o urren e de position à haque y le est trop élevé, l'automate du omposant detype Interpret devra être modi�é a�n de ne pas al uler l'o urren e à haque y le. Il devratout de même onnaître le temps é oulé entre deux al uls ainsi que les o urren es de RMS etLMS orrespondantes a�n de al uler l'évolution orrespondante de A tual_position.Pour e al ul, nous devons également onsidérer les ontraintes physiques parmi lesquellesle fait que le robot ne peut plus avan er lorsqu'il entre en ollision ave un obsta le. Le �otd'informations en provenan e du pilote d'a quisition des ollisions (nommé Bumper sur la �gure4.20) renseigne sur les ollisions ; 'est don un �ot d'informations devant être onsommé par lesous onne teur 1.Cette se tion a permis de détailler une partie du sous onne teur omplexe permettantd'adapter le SAM proposé dans le adre du on ours CiberMouse aux entrées et aux sortiesdé�nies lors du on ours maRTian Task. La se tion suivante détaille le pilotage du SAIM par le onne teur omplexe a�n de l'adapter aux besoins du on ours CiberMouse.4.6.3.2 Le pilotage du SAIMContrairement au on ours maRTian Task, la position à atteindre dans l'environnement n'estpas onnue a priori. La surfa e où se dépla e le robot ontient une sour e de lumière infrarougeen provenan e de la position à atteindre mais ne pouvant pas être déte tée aux travers des mursplus haut qu'elle. La première étape pour le robot onsiste don à re her her la position de ettesour e lumineuse à l'aide du pilote d'a quisition du déte teur infrarouge. Ensuite, omme dansmaRTian Task, le robot doit atteindre ette position. Une fois atteinte, le robot doit retournerà sa position initiale. On identi�e don trois phases su essives :1. Re her her la ible.2. Atteindre la ible.3. Revenir à la position initialeCha une de es trois phases peut être pilotée en modi�ant le �ot de données onsommé parl'entrée goal_position du SAIM. C'est don un seul onne teur, elui en harge de l'a quisitionde l'entrée goal_position, qui va permettre de piloter le SAIM de maRTian Task. 113

Chapitre 4. Évaluation de l'appro heLors de la première phase, le sous onne teur en harge de l'a quisition de goal_positiongénère un �ot de positions de manière à explorer la arte et ainsi espérer voir l'émission in-frarouge de la ible au moins une fois. Pour e faire, le sous onne teur doit onsommer les �otsd'informations suivant :� le �ot de données en provenan e du pilote d'a quisition de déte tion de la ible,� le �ot de donnée en provenan e du sous onne teur en harge de l'a quisition de la positionet de l'orientation du robot.Le sous onne teur doit également posséder une politique d'exploration de l'environnement luipermettant de générer une position à atteindre d'après les informations de es �ots.Le passage à la phase deux s'e�e tue lorsque la ible a été déte tée au minimum une fois. Lesous onne teur doit don générer des positions qui vont permettre d'atteindre la ible. Lors de ladéte tion de la ible, la donnée fournie est l'orientation relative de la ible, sans renseignement sursa distan e. Le sous onne teur doit onserver l'historique des positions dans lesquelles la ible aété vue et l'orientation asso iée a�n de réaliser une triangularisation et ainsi fournir une positionà atteindre de plus en plus pré ise. En plus des informations pré édentes, e sous onne teur doit onsommer le �ot de données représentant l'état du robot a�n de savoir si la ible est atteinte ounon. Lorsque elle- i est atteinte, la troisième phase ommen e. La position à atteindre est don mise à jour par la position initiale du robot, préalablement sauvegardée par le sous onne teur.4.6.3.3 Con lusion de CiberMouseCe travail a permis de montrer omment réutiliser un modèle SAIM sur un SAM di�érent enmodi�ant le onne teur omplexe. En plus des di�éren es au niveau de la plateforme réelle (i ile simulateur), des di�éren es au niveau des spé i� ations de la mission à réaliser ont été géréesdans le onne teur omplexe. Ce hangement de plateforme et de spé i� ation ont né essité unemodi� ation du SAIM en ajoutant une sortie permettant de ommuniquer l'état de la mission durobot. Le modèle SAIM de maRTian Task ne possède e�e tivement pas de sortie permettant de ommuniquer son état. L'ajout de ette sortie est don une amélioration du SAIM de maRTianTask. De plus, a�n d'améliorer les futurs réutilisations, la sortie ne doit pas seulement ommu-niquer les états de la mission important dans le ontexte de CiberMouse mais tous les états dela mission et du robot. Ainsi, on remarque que la réutilisation d'un SAIM permet égalementd'améliorer elui- i en le ra�nant en in orporant l'expérien e a quise au fur des réutilisations.L'obje tif �nal serait de faire de es omposants des omposants �métiers�.Il a été possible de piloter le SAIM de maRTian Task a�n de l'adapter aux spé i� ations deCiberMouse en utilisant le sous onne teur en harge de l'a quisition de la position à atteindre.Cependant, on remarque que la omplexité de l'ALM a, de e fait, augmenté. En parti ulier, lesous onne teur dé rit pré édemment ontient un y le de vie pour gérer trois phases de fon tion-nement di�érentes, un algorithme d'exploration de arte et un algorithme de triangularisation.On voit don que la réutilisation d'un SAIM pour une utilisation di�érente de elle prévu a un oût qu'il est né essaire d'évaluer pour tirer béné� e de la réutilisation.Le sous onne teur en harge de l'a quisition de la position à atteindre possède trois phasesdurant lesquelles sa politique de génération du �ot de données est di�érente. On a don un QoSdi�érente pour ha un de es �ots. En généralisant e i, on se rend ompte que la QoS des entrées114

4.7. Con lusion sur l'évaluationet des sorties peut, dans ertains as être liée au y le de vie du système. Il pourrait don êtreintéressant de dé rire plusieurs QoS pour une même entrée ou sortie, ha une orrespondant àun y le de vie di�érent du système.Dans un autre registre, l'intérêt do umentaire des modèles a été mis en avant lors de laréutilisation, une année après leur réalisation, des spé i� ations et de l'implémentation de maR-Tian Task. La vue gros grains des modèles, dé rivant ha un un aspe t di�érent du système(SAM, ALM, SAIM), permet une ompréhension fa ilité du r�le de ha un des omposants. Lamodi� ation dans le ode sour e asso ié est don plus fa ile à lo aliser et à e�e tuer.En�n, la modélisation réalisée pour le ontr�le du robot dans le adre du on ours CiberMousenous a valu une pla e honorable de quatrième lors de la ompétition.4.7 Con lusion sur l'évaluationCe hapitre a présenté le adre d'utilisation de SAIA au travers de plusieurs points. Le premierd'entre eux est elui de l'outil. La réalisation d'un outil a dans un premier temps permis de réaliserdes modèles qui ne peuvent qu'être onformes au style ar hite tural SAIA. Il a également permisde s'assurer de la ohéren e entre les modèles SAM, ALM et SAIM pour la réalisation d'unmodèle omplet. Le point le plus important de la réalisation de l'outil est qu'il permet de lier ette appro he aux appro hes de transformations de modèles et o�re ainsi un pont vers d'autresappro hes et formalismes.Le deuxième et le troisième points abordés présentent des méthodes qui permettent d'exploiterle style ar hite tural. La première appro he présente une suite de pro essus de modélisationpermettant de onstruire ha un des modèles du style ar hite tural proposé. Cette méthodemontre omment développer puis déployer de manière sûre une appli ation de ontr�le. Pour efaire, l'hypothèse est que la qualité de ontr�le est fon tion de l'appli ation et de la QoS surles entrées et les sorties Cette méthode est illustrée par un exemple qui permet de se �gurerl'utilisation de SAIA pour réaliser la on�guration logique d'un système. De plus l'exemplepermet de montrer que lors de la dérivation de la qualité de ontr�le en QoS sur la plateformeabstraite, il est intéressant d'utiliser une spé i� ation pré ise de la QoS pour ne pas restreindreles déploiements ou pour ne pas sur harger le système en spé i�ant une QoS trop restri tive.La deuxième méthode est d'avantage fo alisée sur la mise au point des paramètres temporelsd'un système. Elle montre que SAIA, et en parti ulier la simulation exhaustive ainsi que laréalisation de ontrat de QoS, permet de dé�nir un ensemble de valeurs des paramètres pourlesquelles un ontrat peut être établi.Pour �nir e hapitre, deux mises en ÷uvre plus onséquentes ont été présentées. La première on erne le développement de l'appli ation de ontr�le de maRTian Task. Cette première miseen ÷uvre a permis de s'assurer de la faisabilité des modèles à l'exé ution. SAIA permet lades ription d'une ar hite ture logique, ainsi, lors de l'implémentation des modèles, la mise enpla e d'un modèle de tâ hes a don été né essaire. Elle nous a également permis de nous rendre ompte de l'impa t positif de la stru ture �gros grains� lors de l'implémentation puisque ha un115

Chapitre 4. Évaluation de l'appro hedes omposants peut être développé indépendamment des autres.En�n, la deuxième mise en ÷uvre a permis de présenter omment réutiliser un même SAIMsur deux SAM di�érents. Pour ela le SAIM de maRTian Task a été utilisé pour réaliser Ciber-Mouse. Ainsi, nous avons véri�é qu'il est possible de onne ter la plateforme abstraite à plusieursplateformes réelles. Nous avons également pu appré ier l'intérêt de la séparation des préo upa-tions de part la fa ilité de reprise en main de la mise en ÷uvre réalisée l'année pré édente.L'ensemble des points abordés montre l'intérêt de baser une appli ation de ontr�le sur uneplateforme abstraite plut�t que sur une plateforme réelle. Une plateforme abstraite dé�nit unensemble de plateformes réelles. Cet ensemble est restreint par une dé�nition de la QoS perme-ttant à l'appli ation de ontr�le d'atteindre ses obje tifs de qualité de ontr�le. La réalisationd'un ontrat de QoS est alors né essaire pour assurer un déploiement orre t. La séparation despréo upations ainsi réalisée et la stru turation du système en omposants permet de égalementde maîtriser la omplexité du développement. De plus, les modèles réalisés agissent omme unedo umentation du système, fa ilitant ainsi les futures réutilisations.

116

5Con lusion et Perspe tivesCette thèse propose un style ar hite tural pour le développement d'une ar hite ture logi ielledédiée aux systèmes de ontr�le de pro essus. Les prin ipaux obje tifs de l'appro he proposée sontde permettre le développement d'une appli ation de ontr�le indépendamment d'une plateformede ommuni ation et de s'assurer ensuite de la orre tion du déploiement de ette appli ation de ontr�le sur une plateforme de ommuni ation spé i�que. Par plateforme de ommuni ation on onsidère les apteurs, les a tionneurs et les pilotes asso iés.L'étude des ar hite tures logi ielles a permis d'identi�er ertains prin ipes lés devant êtremis en ÷uvre. Ces études ont mis en avant la né essité de dé�nir des styles ar hite turaux perme-ttant d'une part d'appliquer ertains prin ipes de génie logi iel et d'autre part de restreindre les on�gurations réalisées a�n qu'elles restent analysables. On remarque également aux vues de esétudes que la des ription de la QoS requise et fournie par un omposant permet d'utiliser elui- ien respe t de ses exigen es extra-fon tionnelles. Ainsi, lors de la liaison entre deux omposants,un ontrat de QoS est établi si les deux omposants peuvent être onne tés tout en respe tantles ontraintes de QoS. Cependant, les ontrats de QoS traités dans la littérature se fo alisentsur les propriétés dire tement omposables, dé rites à l'aide de valeurs dis rètes, ontraignantainsi l'expressivité. De plus, lors de la onnexion entre deux interfa es, on utilise un onne teurpossédant une �glue� pour pallier l'hétérogénéité entre les interfa es. Du onstat de ette étudenous notons un point important, il est né essaire de quanti�er l'impa t du onne teur sur la QoSlors de l'établissement du ontrat, e point n'est pas traité dès lors que la �glue� n'est pas un hoix réalisé parmi une liste �nie de omportements.Puisque l'obje tif est de permettre le développement d'une appli ation de ontr�le indépen-damment d'une plateforme de ommuni ation spé i�que, une étude à été réalisée sur les di�érentsstyles ar hite turaux permettant de s'abstraire d'une plateforme, au sens large du terme. Ceux- i mettent lairement en avant l'utilisation de di�érentes ou hes logi ielles re�étant di�érentsniveaux d'abstra tion vis-à-vis de la plateforme. On note aussi qu'il est possible de dé rire une117

Chapitre 5. Con lusion et Perspe tivesplateforme abstraite a�n de spé i�er les besoins d'une appli ation et ainsi dé�nir un ensemblede plateformes potentiellement utilisables. Ces stru turations sont rarement utilisées dans le do-maine des systèmes visés ar la orre tion de l'appli ation est fortement liée aux performan esde la plateforme.Le style ar hite tural proposé dans ette thèse propose d'utiliser une stru turation en trois ou hes distinguant :1. une appli ation de ontr�le et sa plateforme abstraite ;2. une plateforme réelle ;3. le onne teur omplexe permettant de lier la plateforme abstraite et la plateforme réelle.Puisque la orre tion de l'appli ation est dépendante des performan es de la plateforme, ilfaut restreindre l'ensemble des plateformes réelles utilisables par une des ription de la QoS surla plateforme abstraite. On dé�nit ainsi un ensemble de plateformes réelles qui, sous réserve desatisfaire la QoS et les servi es dé rits dans la plateforme abstraite, peuvent être utilisées parl'appli ation de ontr�le on ernée. On obtient ainsi une appli ation non dépendante d'une plate-forme réelle spé i�que, ependant on est tout de même dépendant d'un ensemble de plateformesréelles, pas for ément onnu a priori. Plus et ensemble est grand, plus le niveau d'indépendan eest élevé.A�n d'obtenir un niveau d'indépendan e élevé, il est important que la plateforme abstraitedé rive les besoins de l'appli ation de manière indépendante d'une te hnologie existante. Il estégalement important que la QoS ne restreigne pas drastiquement et ensemble. Elle doit don êtreexprimée d'une manière ri he. Plut�t que de se baser sur des valeurs onstantes ou des intervalles,nous dé rivons un langage de la QoS dé rit à l'aide d' ω-expression régulière. En�n, dans le but devéri�er qu'une plateforme réelle appartient à l'ensemble des plateformes utilisables, des ontratsde QoS sont établis entre haque omposant de la plateforme abstraite et de la plateforme réelle.Les ontrats sont établis si la QoS fournie satisfait la QoS fournie, une relation de satisfa tiondoit don être dé�nie pour savoir si l'établissement d'un ontrat peut avoir lieu ou non.A�n de pouvoir réaliser les di�érentes étapes dé rites pré édemment, le style ar hite turalSAIA dé rit des omposants types pour spé i�er ha une des trois ou hes identi�ées et desrègles de stru turation permettant de s'assurer d'obtenir un onne teur omplexe analysable,permettant ainsi l'établissement de ontrats de QoS.L'évaluation de SAIA a été réalisée au travers de divers aspe ts : l'outillage, les méthodeset plusieurs mises en ÷uvre. Elle a permis de ara tériser les apports et les limites du stylear hite tural proposé. Au travers de es diverses mises en ÷uvre il a été possible d'extraireplusieurs bonnes propriétés de SAIA.Au niveau fon tionnel, il a été possible de réutiliser le même SAIM sur plusieurs plateformesréelles grâ e à la spé i� ation de la plateforme abstraite. De plus, lors d'une modi� ation dans laplateforme réelle ou dans la plateforme réelle, les hangements interviennent lo alement au seindu ou des sous onne teur(s) on erné(s). Le fait de on entrer les modi� ations à réaliser dans un omposant est une aide pré ieuse pour le développeur. La séparation du onne teur omplexe ensous onne teurs permet également au développeur de se on entrer sur un omposant spé i�quedu système. Puisque la plateforme abstraite agit omme une interfa e entre la plateforme réelle etl'appli ation, il est également possible de réaliser des hangements dans l'appli ation de ontr�le118

sans pour autant que eux- i soient propagés dans tout le système. Il est également possible dedévelopper l'appli ation de ontr�le et la onnexion à une plateforme réelle en parallèle.Au niveau extra-fon tionnel, l'utilisation d'un langage de QoS permet d'être plus expressif, ependant, il est di� ile de savoir intuitivement si un ontrat peut être établi ou non. SAIA o�redon une haîne d'outil permettant d'automatiser l'établissement de ontrat de QoS. De plus, les ontrats sont établis sous onne teur par sous onne teur. Ainsi, il est possible de se fo aliser surle paramétrage d'un sous onne teur jusque l'établissement d'un ontrat de QoS. Ce paramétrageest fa ilité par la possibilité de réaliser un ensemble d'analyses de manière automatique.Perspe tivesLes résultats obtenus lors de e travail de thèse permettent d'entrevoir de nombreuses per-spe tives de re her he que nous exposons i i selon trois grands axes :Extension des modèles� SAIA est basé sur un modèle à omposants ad-ho a�n de s'a�ran hir des ontraintesimpli ites inhérentes aux modèles à omposants existant. De plus, e i nous permettaitde hoisir une sémantique opérationnelle formelle. Il serait intéressant d'étudier dansquelle mesure SAIA peut être utilisée sur un modèle à omposant existant. La premièreétape serait alors de rendre expli ite le style ar hite tural sous-ja ent au modèle à om-posant séle tionné. La se onde étape serait d'évaluer la propension du style ar hite turalainsi rendu expli ite à a ueillir la sémantique opérationnelle formelle de IF. En�n, ilserait né essaire d'augmenter le modèle à omposant par les types de omposants et les ontraintes stru turelles dé�nis dans SAIA.� Les di�érentes analyses, basées sur IF dans SAIA, ont été e�e tuées en se basant surun temps dis ret. Il est don né essaire de réaliser une des ription de la QoS omme unensemble de valeurs dis rètes. A�n d'étendre le pouvoir d'expression de la QoS, il seraitintéressant d'évaluer l'impa t d'une des ription du langage de la QoS omprenant desintervalles ontinus. Il faudrait alors réaliser les analyses en temps ontinu (IF en temps ontinu ou UPPAAL) et véri�er si les relations de satisfa tion proposées sont toujoursvalides, en parti ulier l'équivalen e de tra e.� Les ara téristiques de QoS prises en ompte dans SAIA ont été hoisies pour leur impa tsur la qualité de ontr�le et la stabilité des systèmes de ontr�le de pro essus. Cepen-dant, d'autres ara téristiques ayant un impa t sur la qualité de ontr�le peuvent êtreenvisagées. On peut iter deux types de ara téristiques di�érentes : les ara téristiquestemporelles telles que la gigue et les ara téristiques non temporelles telles que la pré- ision des données. La première étape de ette extension onsisterait don à hoisir unete hnique de spé i� ation pour haque ara téristique de QoS. Ensuite, une relation desatisfa tion entre la QoS fournie et la QoS requise doit être formalisée. En�n, il faudraitévaluer l'impa t de l'in orporation de ha une des ara téristiques sur l'analyse. En par-ti ulier, les ara téristiques non temporelles telles que la pré ision des données pourraientdemander la réation d'un modèle re�étant l'évolution de l'environnement. 119

Chapitre 5. Con lusion et Perspe tives� Dans SAIA la spé i� ation de la QoS dans la plateforme abstraite est réalisée pour haqueentrée et pour haque sortie. Cependant, ette des ription est statique quelque soit lemode de fon tionnement (normal, dégradé, et .) de l'appli ation de ontr�le. Certainesentrées et/ou sorties devraient pouvoir spé i�er une qualité de servi e di�érente enfon tion du y le de vie de l'appli ation de ontr�le. Il serait alors né essaire de dé rirele y le de vie de l'appli ation de ontr�le ainsi que les liens qui lient e y le de vie àla QoS de la plateforme abstraite. En�n, il faudrait investiguer l'impa t du y le de viesur le onne teur omplexe et sur l'établissement des ontrats de QoS.Mise en ÷uvre� SAIA permet de dé rire une ar hite ture logique. On peut ainsi réaliser des analyses avantde traiter les détails de l'implémentation. La plateforme d'exé ution et l'e�et de l'ordon-nan ement sont abstraits par les budgets temporels. A�n de réaliser l'implémentationexé utable d'un modèle SAIA, il est né essaire de pré iser le langage de programmation,l'utilisation ou non d'un intergi iel ou en ore le modèle de tâ hes. Il serait alors intéres-sant d'investiguer le ra�nement de SAIA a�n de produire une ar hite ture opérationnelleen partant de l'ar hite ture logique. Dans la même idée que A ord [75℄, une solutionserait de ara tériser une plateforme d'exé ution multitâ hes réelle (du type d'un sys-tème d'exploitation temps réel) et une ma hine virtuelle d'exé ution multitâ he. Alors,dans la même idée que SAIA, la ma hine virtuelle serait vue omme une plateformed'exé ution abstraite. Ensuite le travail onsisterai à : formaliser les ara téristiques deQoS pertinentes, formaliser la des ription de la QoS requise et fournie et formaliser larelation de satisfa tion pour haque ara téristique de QoS. Ainsi, on devrait pouvoir ara tériser la onnexion entre la plateforme réelle et la plateforme abstraite et, si né es-saire, expli iter les ontraintes et méthodes permettant d'envisager l'établissement d'un ontrat de QoS.Extensions du domaine� Au un des types de omposants dé�nis dans SAIA ne permet de modéliser les e�etsde réseaux de terrains au sein d'un système de ontr�le. Cependant, de plus en plusde systèmes de ontr�le de pro essus, à l'image des systèmes automobiles, utilisent unréseau de ommuni ation. L'utilisation de es réseaux peut s'e�e tuer entre les apteurs,les a tionneurs et l'appli ation de ontr�le ou entre di�érentes appli ations de ontr�le.A�n de permettre la modélisation de tels systèmes, il serait intéressant, dans la mêmeidée que [77℄, d'étudier l'impa t des di�érents réseaux de terrains (CAN, TTA, ...) surles ara téristiques de QoS dé rites dans SAIA. Ce i devrait permettre de ara tériser demanière abstraite l'e�et des ommuni ations dans le but de réaliser les analyses dé ritesdans SAIA, dans le adre des systèmes distribués.� Dans SAIA, les interprétations né essaires entre les informations de la plateforme ab-straite et elles de la plateforme réelle sont réalisées statiquement pendant la phase demodélisation. Dans les systèmes où les ontraintes temporelles sont moindres et les sys-tèmes ouverts (PDA, téléphones, ...) l'arrivée et le déploiement d'une appli ation devraitse faire de manière transparente sur plusieurs plateformes. L'utilisation d'une plateformeabstraite semble être une bonne solution pour la spé i� ation des besoins sans pourautant spé i�er une te hnologie parti ulière. Dans le but de onne ter la plateforme ab-120

straite à la plateforme réelle, il serait alors né essaire de dé�nir une base ontologiqueregroupant la sémantique de la plateforme abstraite et de la plateforme réelle ainsi quedes interprétations préétablies permettant de onne ter les deux plateformes. Il seraitalors né essaire d'utiliser un intergi iel spé i�que permettant de gérer, à l'exé ution, lades ription ontologique des plateformes ainsi que le hoix de l'interprétation pour l'étab-lissement de la onnexion entre les plateformes.

121

Chapitre 5. Con lusion et Perspe tives

122

Bibliographie[1℄ M. Agrawal, S. Cooper, L. Graba, and V. Thomas. An open software ar hite ture forhigh-integrity and high-availability avioni s. Digital Avioni s Systems Conferen e, 2004.DASC 04. The 23rd, 2, 2004.[2℄ Robert Allen. A Formal Approa h to Software Ar hite ture. PhD thesis, Carnegie Mellon,S hool of Computer S ien e, January 1997. Issued as CMU Te hni al Report CMU-CS-97-144.[3℄ JP Almeida, R. Dijkman, M. van Sinderen, and LF Pires. On the notion of abstra tplatform in MDA development. Enterprise Distributed Obje t Computing Conferen e, 2004.EDOC 2004. Pro eedings. Eighth IEEE International, pages 253�263, 2004.[4℄ R. Alur and DL Dill. Automata for modeling real-time systems. Pro eedings of the seven-teenth international olloquium on Automata, languages and programming table of ontents,pages 322�335, 1990.[5℄ ARTIST. Adaptive real-time systems for quality of servi e management. Draft IST-2001-34820, 2003.[6℄ ARTIST 2. Sele ted topi s in Embedded System Design : Roadmaps for resear h, pages22�37. Draft IST-2001-34820, 2004.[7℄ G.R. AUTOSAR. AUTOSAR website. http ://www.autosar.org.[8℄ Jean-Philippe Babau and Sebastien Gerard. Model-Driven S hedulability Analysis, hap-ter 9. Hermes S ien e publishing, London, 2005.[9℄ Rajesh Krishna Balan, Lee Boon Peng, K. Renjish Kumar, Lillykutty Ja ob, WinstonK. G. Seah, and A. L. Ananda. TCP HACK : TCP header he ksum option to improveperforman e over lossy links. In INFOCOM 2001, April 2001.[10℄ Len Bass, Paul Clements, and Ri k Kazman. Software Ar hite ture in Pra ti e, Se ondEdition. Addison-Wesley Professional, Boston, April 2003.[11℄ Ananda Basu, Marius Bozga, and Joseph Sifakis. Modeling heterogeneous real-time om-ponents in bip. In SEFM '06 : Pro eedings of the Fourth IEEE International Conferen eon Software Engineering and Formal Methods, pages 3�12, Washington, DC, USA, 2006.IEEE Computer So iety.[12℄ I. Bate, P. Nightingale, and A. Cervin. Establishing timing requirements and ontrolattributes for ontrol loops in real-time systems. Real-Time Systems, 2003. Pro eedings.15th Euromi ro Conferen e on, pages 121�128, 2003.[13℄ Belga em Ben-Hedia, Fabri e Jumel, and Jean-Philippe Babau. Formal evaluation of qual-ity of servi e for data a quisition systems. Forum on spe i� ation and Design Language,2005. 123

Bibliographie[14℄ G. Berry and R. Sethi. From regular expressions to deterministi automata. Theoreti alComputer S ien e, 48(1) :117�126, 1986.[15℄ B. Berthomieu, P-O. Ribet, and F. Vernadat. Towards the veri� ation of real-time systemsin avioni s : The otre approa h. 8th international workshop on formal method for industrial riti al systems (FMICS), 2003.[16℄ Antoine Beugnard, Jean-Mar Jézéquel, N�÷l Plouzeau, and Damien Watkins. Making omponent ontra t aware. IEEE omputer, 32(7), pages 38�45, 1999.[17℄ Toni A. Bishop and Ramesh K. Karne. A survey of middleware. In Narayan C. Debnath,editor, Computers and Their Appli ations, pages 254�258. ISCA, 2003.[18℄ Marius Bozga, Suzanne Graf, and L. Mounier. If-2.0 : A validation environment for omponent-based real time systems. In ed. Brinksma, K.G. Larsen (Eds) Pro eedingsof CAV'02, 2002.[19℄ F. Budinsky. E lipse Modeling Framework. Addison-Wesley Professional, Boston, 2003.[20℄ J.N. Buxton and B. Randell. Software engineering te hniques : Report on a onferen esponsored by the nato s ien e ommittee rome italy the 27-31th o t. 1969, 1970.[21℄ E. Cariou, A. Beugnard, and JM Jezequel. An ar hite ture and a pro ess for implementingdistributed ollaborations. Enterprise Distributed Obje t Computing Conferen e, 2002.EDOC'02. Pro eedings. Sixth International, pages 132�143, 2002.[22℄ Tarak Chaari and Frédérique Laforest. Sefagi : Simple environment for adaptable graphi alinterfa es - generating user interfa es for di�erent kinds of terminals. In Chin-Sheng Chen,Joaquim Filipe, Isabel Seru a, and José Cordeiro, editors, ICEIS (1), pages 232�237, 2005.[23℄ Kenneth Chan. Formal proofs for qos-oriented transformations. edo w, 0 :41, 2006.[24℄ D. D. Clark and D. L. Tennenhouse. Ar hite tural onsiderations for a new generation ofproto ols. SIGCOMM Comput. Commun. Rev., 20(4) :200�208, 1990.[25℄ J. Coutaz. Abstra tions for user interfa e design. Computer, 18(9) :21�34, 1985.[26℄ J. Coutaz. Abstra tions for user interfa e toolkits. Foundation for Human-ComputerCommuni ation, Elsevier S ien e, North-Holland, 1986.[27℄ J. Coutaz. Interfa es homme-ordinateur : on eption et réalisation, pages 139�145. Dunod,Paris, 1990.[28℄ J. Coutaz. Interfa es homme-ordinateur : on eption et réalisation. Dunod, Paris, 1990.[29℄ J. Coutaz. Interfa es homme-ordinateur : on eption et réalisation, pages 161�186. Dunod,Paris, 1990.[30℄ I. Crnkovi , M. Larsson, and O. Preiss. Con erning Predi tability in DependableComponent-Based Systems : Classi� ation of Quality Attributes. le ture notes in om-puter s ien e, 3549 :257, 2005.[31℄ Ivi a Crnkovi . Building Reliable Component-Based Software Systems. Arte h House, In .,Norwood, MA, USA, 2002.[32℄ Ivi a Crnkovi . Building reliable omponent-based software systems. pages 189�190, 2002.[33℄ K. Czarne ki and S. Helsen. Feature-based survey of model transformation approa hes.IBM Systems Journal, 45(3) :621�645, 2006.[34℄ Julien DeAntoni, Fabri e Jumel, and Jean-Philippe Babau. te h-report-20070130 :A simple simulink exploration robot simulator. Te hni al report, janvier 2007.http ://www.deantoni.fr.st/simulink_robot/te h-report-20070130.pdf.124

[35℄ Tele omuni a ões e Informáti a Universidade de Aveiro Departamento deEle tróni a. Ciber-mouse rules and te hni al spe i� ations, july 2006.http ://www.ieeta.pt/ lau/web_ iberRTSS/do s/ iberRTSSrules.pdf.[36℄ Frank DeRemer and Hans Kron. Programming-in-the large versus programming-in-the-small. In Pro eedings of the international onferen e on Reliable software, pages 114�121,New York, NY, USA, 1975. ACM Press.[37℄ Mar io S. Dias and Marlon E. R. Vieira. Software ar hite ture analysis based on state hartsemanti s. In IWSSD '00 : Pro eedings of the 10th International Workshop on SoftwareSpe i� ation and Design, page 133, Washington, DC, USA, 2000. IEEE Computer So iety.[38℄ Edsger W. Dijkstra. The stru ture of the THE-multiprogramming system. Commun. ACM,11(5) :341�346, 1968.[39℄ Dspa e. Produits logi iels intuitifs pour le pro essus de développement de al ulateur.http ://www.dspa e.fr/ww/fr/fra/home/produ ts/sw. fm, 2007.[40℄ E. Durand. Des ription et véri� ation d'ar hite ture temps réel : Clara et les réseaux depetri temporisés. Thèse de do torat, é ole Centrale de Nantes Fran e, 2004.[41℄ Esterel-Te hnologies. S ade suite(tm). http ://esterel-te hnologies. om/produ ts/s ade-suite/, 2007.[42℄ Groupe ETAS. As et-se (génie logi iel). http ://www.etas. om/fr/produ ts/986.php, 2006.[43℄ P. Farail and P. Gau�llet. The otre proje t : How to model and verify real time ar hite -ture ? 2nd European Congress on Embedded Real Time Software (ERTS'2004), 2004.[44℄ P. Farail, P. Gau�llet, A. Canals, C. Le Camus, D. S iamma, P. Mi hel, X. Crégut, andM. Pantel. TOPCASED : An Open Sour e Development Environment for EmbeddedSystems. Chapter 11, From MDD Con epts to Experiments and Illustrations, ISTE Editor,pages 195�207, 2006.[45℄ Jean-Philippe Fassino, Jean-Bernard Stefani, Julia L. Lawall, and Gilles Muller. Think :A software framework for omponent-based operating system kernels. In USENIX AnnualTe hni al Conferen e, General Tra k, pages 73�86, 2002.[46℄ Sébastien Fau ou, Anne-Marie Déplan he, and Yvon Trinquet. An ADL entri approa hfor the formal design of real time systems. In Ar hite ture des ription language, IFIP,pages 67�82, 2004.[47℄ J.C. Fernandez, H. Garavel, A. Kerbrat, L. Mounier, R. Matees u, and M. Sighireanu.CADP-A Proto ol Validation and Veri� ation Toolbox. Pro eedings of the 8th InternationalConferen e on Computer Aided Veri� ation, pages 437�440, 1996.[48℄ Jean-Claude Fernandez. Aldébaran : a tool for veri� ation of ommuni ating pro esses.te hni al report SPECTRE 14, LGI-IMAG, 1989.[49℄ Roy Thomas Fielding. Ar hite tural styles and the design of network-based software ar hi-te tures. PhD thesis, University of California, Irvine, 2000. Chair-Ri hard N. Taylor.[50℄ William B. Frakes and Kyo Kang. Software reuse resear h : Status and future. IEEETrans. Softw. Eng., 31(7) :529�536, 2005.[51℄ Robert B. Fran e, Dae-Kyoo Kim, Sudipto Ghosh, and Eunjee Song. A UML-based patternspe i� ation te hnique. IEEE Transa tions on Software Engineering, 30(3) :193�206, 2004.[52℄ J. Fredriksson, K. Sandstrom, and M. Akerholm. Optimizing resour e usage in omponent-based real-time systems. Pro . ACM International Symposium on Component-Based Soft-ware Engineering (CBSE), pages 49�65, 2005. 125

Bibliographie[53℄ David Garlan. Software ar hite ture : a roadmap. In A. Finkelstein, editor, The Future ofSoftware Engineering. ACM Press, 2000.[54℄ David Garlan. Formal modeling and analysis of software ar hite ture : Components, on-ne tors, and events. In SFM, pages 1�24, 2003.[55℄ David Garlan, Robert Allen, and John O kerbloom. Exploiting style in ar hite tural designenvironments. In SIGSOFT '94 : Pro eedings of the 2nd ACM SIGSOFT symposium onFoundations of software engineering, pages 175�188, New York, NY, USA, 1994. ACMPress.[56℄ David Garlan and D. Shaw. IEEE re ommanded pra ti e for ar hite tural des ription ofsoftware-intensive systems. ANSI/IEEE Standard 1471, 2001.[57℄ David Garlan and Mary Shaw. An introdu tion to software ar hite ture. Te hni al report,Pittsburgh, PA, USA, 1994.[58℄ Thomas Genssler, Alexander Christoph, Benedikt S hulz, Mi hael Winter, Chris M. Sti h,Christian Zeidler, Peter Müller, Andreas Stelter, Os ar Nierstrasz, Stéphane Du asse,Gabriela Arévalo, Roel Wuyts, Peng Liang, Bastiaan S hönhage, and Reinier van denBorn. Pe os in a nutshell. The Pe os Consortium� 2002.[59℄ Carlo Ghezzi, Mehdi Jazayeri, and Dino Mandrioli. Fundamentals of software engineering.Prenti e-Hall, In ., Upper Saddle River, NJ, USA, 1991.[60℄ Z. Gu and Z. He. Real-time s heduling te hniques for implementation synthesis from omponent-based software models. Pro . ACM SIGSOFT International Symposium onComponent-Based Software Engineering (CBSE), 2005.[61℄ T.A. Henzinger, B. Horowitz, and C.M. Kirs h. Giotto : a time-triggered language forembedded programming. Pro eedings of the IEEE, 91(1) :84�99, 2003.[62℄ ISIS. The Generi Modeling Environment (GME). http ://www.isis.vander-bilt.edu/Proje ts/gme/, 2005. ISIS : Institute for Software Integrated Systems. VanderbiltUniversity.[63℄ D. Isovi and C. Norstrm. Components in real-time systems. The 8th Interational Con-féren e On Real-Time Computing Systems and Appli ations (RTCSA'2002, 2002.[64℄ Fabri e Jumel. Dé�nition et gestion d'une qualité de servi e pour les appli ations tempsréel. PhD thesis, LORIA, Nan y, 2003.[65℄ Jean-Mar Jézéquel, Olivier Defour, and Noël Plouzeau. An MDA Approa h to TameComponent Based Software Development. Formal Methods for Components and Obje ts,Se ond International Symposium, FMCO 2003, Leiden, The Netherlands, November 4-7,2003, Revised Le tures, 3188.[66℄ Jean-Mar Jézéquel, Sébastien Gérard, and Benoit Baudry. L'ingénierie dirigée par lesmodèles, hapter Le génie logi iel et l'IDM : une appro he uni� atri e par les modèles.Lavoisier, Hermes-s ien e, 2006.[67℄ Ri k Kazman, Gregory Abowd, Len Bass, and Paul Clements. S enario-based analysis ofsoftware ar hite ture. IEEE Software, 13(6) :47�55, November 1996.[68℄ Ri k Kazman, Leonard J. Bass, Mike Webb, and Gregory D. Abowd. SAAM : A method foranalyzing the properties of software ar hite tures. In International Conferen e on SoftwareEngineering, pages 81�90, 1994.[69℄ Dae-Kyoo Kim, Robert Fran e, Sudipto Ghosh, and Eunjee Song. Using role-based mod-eling language (rbml) to hara terize model families. In ICECCS '02 : Pro eedings of the126

Eighth International Conferen e on Engineering of Complex Computer Systems, page 107,Washington, DC, USA, 2002. IEEE Computer So iety.[70℄ M. Klein and R. Kazman. Attribute based ar hite tural styles. Te hni al report, 1999.[71℄ M. Klein, R. Kazman, L. Bass, J. Carriere, M. Barba i, and H. Lipson. Attribute basedar hite ture styles. In Software Ar hite ture, Pro eedings of the First Working IFIP Con-feren e on Software Ar hite ture (WICSA1), pages 225�243. Kluwer A ademi Publishers,Hingham, 1999.[72℄ M.H. Klein. A Pra titioner's Handbook for Real-Time Analysis : Guide to Rate Monotoni Analysis for Real-time Series. Kluwer A ademi Publishers, Hingham, 1993.[73℄ H. Kopetz, A. Damm, C. Koza, M. Mulazzani, W. S hwabl, C. Senft, and R. Zainlinger.Distributed fault-tolerant real-time systems : the Mars approa h. Mi ro, IEEE, 9(1) :25�40,1989.[74℄ Glenn E. Krasner and Stephen T. Pope. A ookbook for using the model-view ontrolleruser interfa e paradigm in smalltalk-80. J. Obje t Oriented Program., 1(3) :26�49, 1988.[75℄ Agnès Lanusse, Sébastien Gérard, and François Terrier. Real-time modeling with UML :The ACCORD approa h. volume 1618, pages 319�335. Springer-Verlag, London, 1999.[76℄ Kim G. Larsen, Paul Pettersson, and Wang Yi. Uppaal in a Nutshell. Int. Journal onSoftware Tools for Te hnology Transfer, 1(1�2) :134�152, O tober 1997.[77℄ Feng-Li Lian. Analysis, design, modeling, and ontrol of networked ontrol systems. Ph.D.Dissertation, The University of Mi higan, 2001.[78℄ Gabor Madl, Sherif Abdelwahed, and Douglas S hmidt. Verifying distributed real timeproperties of embedded systems via graph transformation and model he king. Real-TimeSystems : The international journal of Time- riti al Computing systems, Volume 33, 2006.[79℄ Raphaël Marvie and Mirabelle Nebut. Pro essus de modélisation in rémentaux. IngénierieDirigée par les modèles (IDM'06), 2006.[80℄ Mathworks In . MATLAB. http ://www.mathworks. om/produ ts/matlab/, 2005.[81℄ Mathworks In . real time workshop. http ://www.mathworks. om/produ ts/rtw/, 2005.[82℄ Mathworks In . SIMULINK. http ://www.mathworks. om/produ ts/simulink/, 2005.[83℄ Nenad Medvidovi , Peyman Oreizy, Jason E. Robbins, and Ri hard N. Taylor. Usingobje t-oriented typing to support ar hite tural design in the C2 style. In SIGSOFT '96 :Pro eedings of the 4th ACM SIGSOFT symposium on Foundations of software engineering,pages 24�32, New York, NY, USA, 1996. ACM Press.[84℄ Nenad Medvidovi and Ri hard N. Taylor. A lassi� ation and omparison framework forsoftware ar hite ture des ription languages. Software Engineering, 26(1) :70�93, 2000.[85℄ Mi rosoft. Mi rosoft roboti s studio. http ://msdn.mi rosoft. om/roboti s/.[86℄ Mi rosoft. Review of windows 3.1 ar hite ture. http ://www.mi rosoft. om/te hnet/ar h-ive/wfw/1_ h2.mspx, 2005.[87℄ Mi rosoft. .NET. http ://www.mi rosoft. om/net, 2006.[88℄ Sun mi rosystems. JSR 153 : Enterprise JavaBeans 2.1. Te hni al Report, Java CommunityPro ess, 2003.[89℄ RT Monroe, A. Kompanek, R. Melton, and D. Garlan. Ar hite tural styles, design patterns,and obje ts. Software, IEEE, 14(1) :43�52, 1997. 127

Bibliographie[90℄ A. Muth, T. Kollo h, T. Maier-Komor, and G. Farber. An evaluation of ode generationstrategies targeting hardware forthe rapid prototyping of SDL spe i� ations. Rapid SystemPrototyping, 2000. RSP 2000. Pro eedings. 11th International Workshop on, pages 134�139,2000.[91℄ P. Naur and B. Randell. Software engineering te hniques : Report on a onferen e sponsoredby the nato s ien e ommittees garmis h germany 7-11 o t. 1968, 1969.[92℄ D.I. Norm and G. Berlin. Pro�bus Standard : DIN 19245, 1995. Two volumes.[93℄ FIP Normes. NF C46-601 to NF C46-607. Union Te hnique de l'éle tri ité, AFNOR, 1990.[94℄ OMG. Obje t management group. http ://www.omg.org, 2003.[95℄ OMG-MDA. Model driven ar hite ture guide v1.0.1. http ://www.omg.org/mda, 2003.[96℄ OMG-OCL. UML 2.0 OCL spe i� ation. http ://www.omg.org/ gi-bin/do ?pt /2005-06-06, 2005.[97℄ OMG-UML. Final FTF report MOF 2.0 ore and UML 2.0 infrastru ture �nalization taskfor e. http ://www.omg.org, 2004.[98℄ The Open Servi e Gateway initiative. OSGI release platform 4. Te hni al Report, 2006.[99℄ P.H.Feiler, B. Lewis, and Steve Vestal. the SAE avioni ar hite ture des ription language(AADL) standard : A basis for model-based ar hite ture driven embedded systems engi-neering. RTAS Workshop on Model-Driven Embedded Systems, 2003.[100℄ P. Pleinevaux, J.D. De otignie, and L. EPFL. Time riti al ommuni ation networks : �eldbuses. Network, IEEE, 2(3) :55�63, 1988.[101℄ proje t EAST-EEA. De�nition of language for automotive embedded ele troni ar hite -ture. Version 1.02, 2004.[102℄ E. Robles and J. Held. A omparison of windows driver model laten y performan e onwindows nt and windows 98. Pro . OSDI third symposium, 1999.[103℄ Mendel Rosenblum. The rein arnation of virtual ma hines. ACM queue :�Virtual Ma- hine� ; number 5 ; volume 2, 2004.[104℄ M. Sanfridson. Timing Problems in Distributed Real-Time Computer Control Systems.Me hatroni s Lab, Dept. of Ma hine Design, Royal Inst. of Te hnology, Sto kholm, 2000.[105℄ M. Sanfridson, M. Törngren, and J. Wikander. The E�e t of Randomly Time-VaryingSampling and Computational Delay. In Pro eedings of the IFAC world ongress, Prague,2005.[106℄ B. Seli . On the Semanti Foundations of Standard UML 2.0. Le ture Notes in ComputerS ien e, 3185 :181�199, 2004.[107℄ G.R. Sell. Smooth Linearization Near a Fixed Point. Ameri an Journal of Mathemati s,107(5) :1035�1091, 1985.[108℄ Mary Shaw, Robert DeLine, Daniel V. Klein, Theodore L. Ross, David M. Young, and Gre-gory Zelesnik. Abstra tions for software ar hite ture and tools to support them. SoftwareEngineering, 21(4) :314�335, 1995.[109℄ Mary Shaw and David Garlan. Software Ar hite ture : Perspe tives on an Emerging Dis- ipline. Prenti e-Hall, 1996.[110℄ Y. Shoham et al. Agent-Oriented Programming. Arti� ial Intelligen e, 60(1) :51�92, 1993.128

[111℄ ISO Standard. 11898 : Road Vehi les - Inter hange of Digital Information - Controller AreaNetwork (CAN) for High-Speed Communi ation. International Standards Organization,Switzerland, November, 1993.[112℄ J.A. Stankovi . VEST-A Toolset for Constru ting and Analyzing Component Based Em-bedded Systems. Pro eedings of the First International Workshop on Embedded Software,pages 390�402, 2001.[113℄ David B. Stewart, Ri hard A. Volpe, and Pradeep K. Khosla. Design of dynami ally re on-�gurable real-time software using port-based obje ts. Software Engineering, 23(12) :759�776, 1997.[114℄ B. Stroustrup. Language-te hni al aspe ts of reuse. In ICSR '96 : Pro eedings of the 4thInternational Conferen e on Software Reuse, page 11, Washington, DC, USA, 1996. IEEEComputer So iety.[115℄ sun. Java 2 platform standard edition development kit 5.0. http ://www.java.sun. om.[116℄ Sylvain and FrameIP. Le modèle osi. http ://www.frameip. om/osi/#4.2_-_Ce_nie, 2006.[117℄ Clemens Szyperski. Component Software : Beyond Obje t-Oriented Programming. Addison-Wesley Professional, Boston, De ember 1997.[118℄ Q. Tan, A. Petrenko, and G. Bo hmann. Testing tra e equivalen e for labeled transitionsystems. Te hni al Report 976, Dept.of I.R.O., University of Montreal, 1995., 1995.[119℄ A.S. Tanenbaum. Modern operating systems. Prenti e-Hall, In . Upper Saddle River, NJ,USA, 1992.[120℄ A.S. Tanenbaum. Modern operating systems � Input Output hapter, pages 205�239.Prenti e-Hall, In . Upper Saddle River, NJ, USA, 1992.[121℄ Bedir Tekinerdogan. Asaam : Aspe tual software ar hite ture analysis method. WorkingIEEE/IFIP Conferen e on Software Ar hite ture (wi sa), 00 :5, 2004.[122℄ J.P. Tolvanen and M. Rossi. MetaEdit+ : de�ning and using domain-spe i� modelinglanguages and ode generators. Conferen e on Obje t Oriented Programming Systems Lan-guages and Appli ations, pages 92�93, 2003.[123℄ Jean-Charles Tournier. Qinna : une ar hite ture � base de omposants pour la gestion dela qualité de servi e dans les systèmes embarqués mobiles. PhD thesis, Institut Nationaldes S ien es Appliquées de Lyon, July 2005.[124℄ Rob van Ommering, Frank van der Linden, Je� Kramer, and Je� Magee. The koala omponent model for onsumer ele troni s software. Computer, 33(3) :78�85, 2000.[125℄ Steve Vestal. Metah user's manual - version 1.27, 1998.[126℄ Anders Wall. A formal approa h to analysis of software ar hite tures for real-time systems.Te hni al report, September 2000.[127℄ Kurt Wallnau, Judith Sta�ord, S ott Hissam, and Mark Klein. On the relationship of soft-ware ar hite ture to software omponent te hnology. Pro . 6th Workshop on Component-Oriented Programming, 2001.[128℄ Kurt C. Wallnau. Volume III : A te hnology for predi table assembly from erti�able omponents (pa ). Te hni al Report CMU/SEI-2003-TR-009, Carnegie Mellon University,Pittsburgh, OH, USA, April 2003.[129℄ B. Wittenmark, J. Nilsson, and M. Torngren. Timing problems in real-time ontrol systems.Ameri an Control Conferen e, 1995. Pro eedings of the, 3, 1995. 129

[130℄ Sergio Yovine. Kronos : A veri� ation tool for real-time systems. (kronos user's manualrelease 2.2).[131℄ H. ZIMMERMANN. OS1 Referen e Model-The IS0 Model of Ar hite ture for Open Sys-tems Inter onne tion. IEEE TRANSACTIONS. ON COMMUNICATIONS, 28(4) :425,1980.Table des �gures2.1 Représentation d'un système de ontr�le de pro essus . . . . . . . . . . . . . . . . 82.2 Exemple de représentation graphique d'une ar hite ture logi ielle . . . . . . . . . 142.3 Deux mises en ÷uvre d'une on�guration basée sur un intergi iel . . . . . . . . . 272.4 l'implémentation d'une ar hite ture logi ielle ompilée . . . . . . . . . . . . . . . 272.5 Les di�érentes ou hes d'un système d'exploitation . . . . . . . . . . . . . . . . . 332.6 Les di�érentes utilisations d'une ma hine virtuelle . . . . . . . . . . . . . . . . . . 342.7 Les sept ou hes du modèles OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.8 Le style ar hite tural Seeheim (�gure adaptée de [28℄) . . . . . . . . . . . . . . . 372.9 Le style ar hite tural dit �entrée/sortie� (�gure extraite de [28℄) . . . . . . . . . . 372.10 Le style ar hite tural PAC (�gure adaptée de [29℄) . . . . . . . . . . . . . . . . . 382.11 Un style ar hite tural pour l'indépendan e vis-à-vis des apteurs / a tionneurs(�gure extraite de [1℄) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.12 Les prin ipaux modèles MDA et leurs relations . . . . . . . . . . . . . . . . . . . 422.13 Deux appro hes pour la réalisation d'un PSM (�gure extraite de [3℄). . . . . . . . 433.1 Les di�érents modèles dans SAIA . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.2 Gestion de la QoS dans SAIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.3 Métamodèle simpli�é représentant les di�érents types de pilotes . . . . . . . . . . 553.4 Métamodèle simpli�é d'un pilote d'a quisition de données . . . . . . . . . . . . . 563.5 Métamodèle simpli�é représentant les di�érents types de omposant de la plate-forme abstraite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.6 Métamodèle d'une donnée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.7 Une ontrainte OCL pour assurer que les omposants d'adaptation d'entrée pos-sèdent au minimum une interfa e d'entrée. . . . . . . . . . . . . . . . . . . . . . . 663.8 Métamodèle établissant la stru turation et les arités entre les interfa es dans SAIA 683.9 Exemple de stru turations orre tes et erronées dans SAIA . . . . . . . . . . . . 683.10 Représentation des o urren es de QoS . . . . . . . . . . . . . . . . . . . . . . . . 753.11 Exemple de sémantique de la loi de retard lors de la fusion de deux informations 783.12 Étapes pour l'établissement d'un ontrat de QoS d'une entrée . . . . . . . . . . . 823.13 Étapes pour l'établissement d'un ontrat de QoS d'une sortie . . . . . . . . . . . 824.1 Capture d'é ran de l'outil réalisé . . . . . . . . . . . . . . . . . . . . . . . . . . . 884.2 Les pro essus de modélisation in rémentaux pour la modélisation du SAIM . . . 904.3 Les pro essus de modélisation in rémentaux pour la modélisation de l'ALM . . . 914.4 Les pro essus de modélisation in rémentaux pour la validation d'un système . . . 92130

4.5 Modèle SAIM d'un robot explorateur simple dans l'outil SAIA . . . . . . . . . . 954.6 Erreur de traje toire pour une loi de retard nulle . . . . . . . . . . . . . . . . . . 964.7 Erreur de traje toire pour une loi de retard respe tant le langage de retard requis 974.8 Erreur de traje toire pour une loi de retard ne respe tant pas le langage de retardrequis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974.9 Infrastru ture physique simpli�ée liée à la plateforme réelle . . . . . . . . . . . . 984.10 Modèle SAM d'un robot explorateur simple dans l'outil SAIA . . . . . . . . . . . 994.11 Modèle SASM d'un robot explorateur simple dans l'outil SAIA . . . . . . . . . . 1004.12 Stru ture de la �glue� du sous onne teur réalisant l'a quisition de Orientation_a tuelle1004.13 Exemple de variation de deux paramètres temporels dans une on�guration . . . 1034.14 Corrélation temporelle maximale de la donnée agrégée lorsque les pilotes des ap-teurs sont syn hronisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1044.15 Corrélation temporelle maximale de la donnée agrégée lorsque les pilotes des ap-teurs sont désyn hronisés au maximum de 30ms . . . . . . . . . . . . . . . . . . . 1054.16 Présentation de l'infrastru ture physique virtuelle de maRTian Task . . . . . . . 1064.17 Présentation du modèle SASM obtenu pour maRTian Task . . . . . . . . . . . . 1074.18 Présentation du modèle des tâ hes hoisi pour maRTian Task . . . . . . . . . . . 1094.19 Infrastru ture physique virtuelle du robot utilisé pour le on ours CiberMouse . . 1114.20 A quisition de l'entrée a tual_position en bou le ouverte . . . . . . . . . . . . 112Liste des tableaux2.1 Comparaison des styles ar hite turaux lassiques vis-à-vis de propriétés extra-fon tionnelles non hi�rables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

131

RésuméDu fait de leur omplexité roissante, le développement des systèmes embarqués et temps réel né essitent on-jointement l'appli ation de prin ipes de génie logi iel et l'appli ation de te hniques formelles. Le travail développépendant ette thèse propose une appro he et des outils basés sur les modèles. Ces modèles, basés sur UML (Uni�edModeling Language), permettent de dé�nir un style ar hite tural appelé SAIA4 dont l'obje tif est le développe-ment et la mise au point de systèmes temps réel en intégrant l'évolution et la variabilité des plateformes. On entendi i par plateforme les servi es de ommuni ation entre le système et son environnement physique, 'est-à-dire desopérations de le ture et d'é riture via les apteurs et les a tionneurs.Pour répondre à et obje tif, l'idée de SAIA est de séparer lairement le modèle de plateforme du modèlede l'appli ation. À ette �n, SAIA propose l'introdu tion d'une plateforme de ommuni ation abstraite ave lepro essus. Cette plateforme abstraite est omposée d'entrées et de sorties utiles pour e�e tuer le ontr�le, maisindépendantes d'une te hnologie de apteurs/a tionneurs parti ulière. L'appli ation est développée en se basantsur les servi es fournis par la plateforme abstraite.La stabilité d'une appli ation de ontr�le et sa qualité de ontr�lesont, entre autres, dépendantes des ara téristiques temporelles de la plateforme abstraite. Cette dernière est don omposée d'un ensemble de servi es ainsi que d'une des ription de ses ara téristiques temporelles (notées QoSpour Quality of Servi e). La des ription de la QoS de la plateforme abstraite re�ète le omportement temporel,sous forme de ω-expression régulière de la plateforme abstraite pour laquelle l'appli ation a le omportementsouhaité. Ainsi, nous avons d'un �té un modèle de la plateforme abstraite et de la QoS permettant la orre tionde l'appli ation et de l'autre un modèle de la plateforme réelle dont la QoS a été analysée. A�n de onne ter laplateforme abstraite à la plateforme réelle, SAIA s'appuie sur un onne teur omplexe. Ce onne teur omplexeest un assemblage de omposants, dé rit formellement par des automates temporisés réalisant des servi es deformatage, d'interprétation, de fusion de données et en�n d'adaptation de la QoS. Le onne teur omplexe possèdeun omportement et modi�e don la QoS de la plateforme réelle. A�n d'évaluer l'impa t du onne teur omplexesur la QoS de la plateforme réelle, une analyse formelle basée sur la simulation exhaustive du onne teur omplexeest réalisée. Il est alors né essaire de s'assurer que ette QoS nouvellement évaluée satisfait la QoS de la plateformeabstraite et permet ainsi la réalisation d'un système orre t. La véri� ation de ette satisfa tion est basée surl'établissement d'un ontrat de QoS. Dans SAIA, l'établissement d'un ontrat de QoS est basé sur une relationde satisfa tion (équivalen e de tra e) entre systèmes à transitions étiquetés. En�n, SAIA a été mis en ÷uvre àplusieurs reprises dont, lors de deux on ours d'implémentation de robots d'exploration terrestre dans le adre deworkshop satellites de RTSS (Real Time System Symposium).Abstra tDue to their growing omplexity, real time and embedded systems development requires to apply both soft-ware engineering and formal methods. In order to improve reuse, applying software engineering allows separationof on erns to be applied between the appli ation part ( ontrol) and its ommuni ation with the physi al en-vironment. This separation allows the ontrol to be deployed through di�erent on rete platforms in terms ofsensors and a tuators. SAIA4 implements these on epts by de�ning an ar hite tural style where the ontrol isbased on an abstra t platform. Then, to realize the system, the abstra t platform is linked to a on rete platformthrough a omplex onne tor. This software engineering method is promising, however an important real time andembedded systems aspe t is that their orre tness depends on the ommuni ation with the physi al environmenttemporal behaviors. A minor hange in a measure a quisition by a sensor an lead to unpredi table rea tion ofthe system. To allow separation of on erns to be orre tly realized, SAIA proposes formal models and te hniquesbased on timed automata and exhaustive simulation. In a �rst step, formal QoS (Quality of Servi es) require-ments are expressed in both the abstra t and the on rete platform. Then, the se ond step ensures the onne tion orre tness between the on rete and the abstra t platform. This is done when the omplex onne tor establishesa QoS ontra t. In SAIA, a QoS ontra t de�nes a formal onformity relation to ensure the QoS satisfa tion and,so, to ensure a safe deployment during the onne tion. At the end, a show ase demonstrates the use and thisapproa h interest.4Sensors A tuators Independent Ar hite ture