Architecture logicielle et méthodologie de conception embarquée sous contraintes temps réel pour la radio logicielle

Transcription

1 Architectre logicielle et méthodologie de conception embarqée sos contraintes temps réel por la radio logicielle Noël Tchidjo Moyo To cite this version: Noël Tchidjo Moyo. Architectre logicielle et méthodologie de conception embarqée sos contraintes temps réel por la radio logicielle. Sciences de l ingénier [physics]. Université Rennes 1, Français. <tel > HAL Id: tel Sbmitted on 27 Jn 2011 HAL is a mlti-disciplinary open access archive for the deposit and dissemination of scientific research docments, whether they are pblished or not. The docments may come from teaching and research instittions in France or abroad, or from pblic or private research centers. L archive overte plridisciplinaire HAL, est destinée a dépôt et à la diffsion de docments scientifiqes de nivea recherche, pbliés o non, émanant des établissements d enseignement et de recherche français o étrangers, des laboratoires pblics o privés.

2 N d ordre 4314 ANNEE 2011 THÈSE / UNIVERSITÉ DE RENNES 1 sos le scea de l Université Eropéenne de Bretagne por le grade de DOCTEUR DE L UNIVERSITÉ DE RENNES 1 Mention : Electroniqe Ecole doctorale Matisse présentée par Noël Bertrand TCHIDJO MOYO préparée à l nité de recherche : SUPELEC/IETR UMR 6164 Nom développé de l nité : Institt d Electroniqe et de Télécommnication de Rennes Composante niversitaire : S.P.M Architectre logicielle et méthodologie de conception embarqée sos contraintes temps réel por la radio logicielle Thèse sotene à Rennes le 20 avril 2011 devant le jry composé de : Maryline CHETTO Professer, IUT, IRCCYN, Nantes / rapporter Joël CHAMPEAU Maître de conférence, ENSTA, Bretagne / rapporter Isabelle PUAUT Professer, Université de Rennes 1, IRISA / examinater Christophe MOY Professer, SUPELEC / directer de thèse Frédéric LAFAYE Responsable indstriel, THALES / examinater Jean-Philippe DELAHAYE Ingénier de recherche, DGA / examinater

3 ii Remerciements Cette thèse est le frit de 3 années de travail effectées a sein d service SPM (Signal Processing Mltimedia) de THALES Commnications (Colombes) et d Laboratoire SCEE/IETR de SUPELEC (Camps de Rennes). Je remercie beacop Monsier Gilles BOURDE chef d service SPM et Monsier Jacqes PALICOT responsable d laboratoire SCEE por m avoir acceilli por cette thèse et por lers conseils tot a long de mes travax. Je tiens à remercier particlièrement mon directer de thèse Christophe MOY et mes encadrants indstriels Frédéric LAFAYE et Eric NICOLLET por ler disponibilité, ler encadrement et lers conseils qi ont été préciex dans les résltats obtens pendant ce travail. J adresse n grand remerciement ax rapporters : Maryline CHETTO, Joël CHAMPEAU ; et ax membres d jry : Isabelle PUAUT, Christophe MOY, Frédéric LAFAYE, Jean-Philippe DELAHAYE. Je remercie tos cex avec qi j ai e des discssions scientifiqes très frcteses pendant ma thèse, en particlier Marie-Anne LEFEBVRE, Nabil SADOU, Vincent SEIGNOLE, Frédéric BRUEL, Pierre-André LAURENT. Je tiens à exprimer ma reconnaissance et ma profonde amitié à Frédéric LAFAYE, por son accompagnement, sa formation, sa gentillesse, bref je li dois beacop. Mes remerciements vont assi à l ensemble de mes collèges chez THALES Commnications por les échanges à la pase café, à la cantine, et por les bons moments passés ensemble a challenge et à la section Basket. Enfin je remercie ma famille, ma maman chérie, mes proches et mes amis por ler présence, ler sotien et lers encoragements. Une pensée por terminer ces remerciements à mon père parti très tôt, je sais qe t arais été très fier de ton fils.

4 iii Résmé Cette étde répond a problème d ordonnancement temps réel de composants logiciels s exéctant sr n processer de traitement d signal dans n contexte de radio logicielle. Elle vise ainsi à compléter l offre en termes d otillage de conception radio logicielle. Dans la pratiqe actelle, l ordonnancement temps réel des applications de traitement d signal flexibles s exéctant sr n processer donné, est effecté de manière manelle, en tilisant des méthodes empiriqes, et en prenant des marges non négligeables. Etant donnée l agmentation pressentie d nombre de composants logiciels de la coche physiqe s exéctant simltanément sr n même processer dans les ftres radios logicielles, ces méthodes seront sjettes à errer, feront perdre beacop de temps et ne troveront pas nécessairement de soltions d ordonnancement valides même lorsq il en existera ne. Por cela, cette thèse définit n novea modèle de tâche représentant pls précisément le comportement des tâches dans certains contextes de radio logicielle : le modèle GMF (Generalized Mlti-Frame) non cycliqe. Por ce modèle, nos présentons ne formlation d calcl d temps de réponse des tâches, ainsi q n novea test de faisabilité sffisant por des tâches s exéctant sr n processer avec la politiqe d ordonnancement «Earliest Deadline First» (EDF). Nos fornissons assi por ce modèle de tâche n algorithme efficace, permettant la détermination exacte de la faisabilité temps réel. Nos présentons dans cette thèse n novea flot de conception IDM (Ingénierie Dirigée par les Modèles), permettant de spécifier les paramètres rendant possibles ne analyse d ordonnançabilité temps réel des composants logiciels s exéctant sr n processer dans ne radio logicielle. Cette thèse propose des méthodes por calcler les contraintes temporelles dans ne radio logicielle. Elle présente les éléments d standard MARTE à tiliser por renseigner les contraintes dans le modèle ainsi qe les règles de transformations de modèles qi permettent d obtenir n modèle exploitable par n otil d analyse d ordonnançabilité temps réel. Cette thèse présente ne approche, implantée sos forme d n otil de simlation, effectant l analyse d ordonnancement temps réel des tâches de traitement d signal flexibles s exéctant sr n processer sivant ne politiqe d ordonnancement hybride. Cet otil est intégré a flot IDM proposé.

5 iv Abstract This stdy addresses the problem of real-time schedling of software components execting in a digital signal processor in a software radio context. It aims at providing new tooling for software radio design. Real-time schedling analysis of flexible signal processing applications execting in a processor is crrently done manally, sing ad hoc methods, and taking significant margins. Given the foreseen increase of software components of the physical layer execting simltaneosly on a processor in ftre software radios, these methods for schedling analysis will be error-prone, time consming and will often fail to find a feasible schedle even when one exists. For that prpose, this thesis defines a new task model which represents more precisely the behavior of the tasks in certain software radio context: the non-cylic GMF (Generalized Mlti-Frame) model. For this model, we present a formla to compte response time of tasks, as well as a new sfficient feasibility test for tasks execting in a processor according to the Earliest Deadline First schedling policy. We also provide for this task model an efficient algorithm, for exact feasibility determination. We present in this thesis a new MDE (Model Driven Engineering) design methodology, to specify the parameters which make possible a real-time schedling analysis of software components execting in a processor. This thesis proposes methods to compte real-time constraints in a software radio. It presents the elements of the MARTE standard to be sed, to note the constraints in the model as well as model transformation rles to obtain a sitable model for real-time schedling analysis. This thesis presents an approach, implemented as a simlation tool, to realize real-time schedling analysis of tasks implementing flexible signal processing algorithms in a processor and schedled according to a hybrid schedling policy. This tool is integrated into the proposed MDE design methodology.

6 v Table des matières Remerciements... ii Résmé... iii Abstract... iv Table des matières... v Table des figres... viii Liste des tableax... x Introdction... 1 Chapitre 1 Etat de l art Introdction La radio logicielle L architectre logicielle SCA Cas d étde de la thèse Méthodologies de conception Concepts générax de conception Les langages Les modèles de calcls Les modèles de commnications L ingénierie dirigée par les modèles L approche MDA La conception de type PBD (Platform-Based Design) Otils de conception Systèmes temps réel et ordonnancement temps réel Introdction ax systèmes temps réel Caractérisation d ne application temps réel Concepts et propriétés Les techniqes d analyse Algorithmes d ordonnancement à priorité fixe Algorithmes d ordonnancement à priorité dynamiqes... 34

7 vi Ordonnancement des tâches dépendantes Analyse de l ordonnançabilité des tâches mlti-trames Analyse de l ordonnançabilité des tâches mlti-trames généralisées Otils de vérification d ordonnancement temps réel Conclsion et problématiqes Chapitre 2 Contribtions : Ordonnancement temps réel Introdction Rappel sr les notations Condition sffisante de faisabilité Calcl d temps de réponse Test basé sr la densité Analyse exacte de la faisabilité temps réel Approche naïve Approche efficace Conclsion Chapitre 3 Contribtions : Méthodologie de conception et otillage Introdction Travax connexes Notre méthodologie de conception Modélisation PIM Modélisation PDM Modélisation PSM Transformation de modèles Ordonnancement temps réel et otillage Conclsion Chapitre 4 Cas d étdes Introdction Strctre d projet dans l otil de modélisation Modélisation PIM Modélisation PDM... 88

8 vii 4.5 Modélisation PSM Transformation de modèles Vérification d ordonnancement temps réel Précision de nos résltats Conclsion Conclsion et perspectives Annexe A Bibliographie liée à l étde Bibliographie...125

9 viii Table des figres Figre 1.1 Architectre logicielle d n éqipement radio d après le SCA... 9 Figre 1.2 Architectre d profil UML MARTE Figre 1.3 Les étapes d ne démarche MDA...21 Figre 1.4 Système temps réel Figre Interblocage et inversion de priorité non bornée Figre 2.1 Comparaison entre ne tâche GMF et ne tâche GMF non cycliqe Figre 2.2 Un modem radio typiqe Figre 2.3 Exemple d interférence sbie par ne tâche Figre 2.4 Interférence générée par τ 1 dans l exemple Figre 2.5 Interférence maximale sbit par ne tâche Figre 2.6 Les différentes possibilités d exéction de la tâche τ 1 de l exemple Figre 2.7 Détermination de la faisabilité dans l exemple Figre 2.8 Algorithme de détermination de la faisabilité temps réel exacte Figre 2.9 Evoltion d nombre de qees dans l exemple Figre 2.10 Evoltion d nombre qees dans l exemple Figre 2.11 Evoltion d nombre de qees dans l exemple Figre 3.1 Notre flot de conception Figre 3.2 Différents niveax de décomposition PIM Figre 3.3 Illstration d ne coche physiqe génériqe Figre 3.4 Profil correspondant à notre flot de conception Figre 3.5 Exemple de modèle de plateforme Figre 3.6 Exemple de relation entre n modle PIM et son implantation PSM Figre 3.7 Exemple d allocation de modle Figre 3.8 Méthode de calcl des échéances temporelles Figre 3.9 Comportement de la tâche qi programme les fréqences porteses Figre 3.10 Processs de transformation de modèles Figre 3.11 Dates des trames dans l air et dates des reqêtes sr le processer Figre 3.12 Algorithme de détermination de la faisabilité temps réel... 79

10 ix Figre 3.13 Schéma de l otil de vérification de l ordonnançabilité Figre 4.1 Schéma fonctionnel de notre modlater OFDM Figre 4.2 Explorater de projet Figre 4.3 Modélisation PIM (nivea en coche) Figre 4.4 Modélisation PIM (nivea modle de base) Figre 4.5 Séqence d ne transmission Figre 4.6 Valer de la mémoire L2 SRAM dans le modèle Figre 4.7 Relation entre les modles PIM et les modles PSM Figre 4.8 Approche graphiqe d allocation de modles Figre 4.9 Otil de calcl des échéances temporelles Figre 4.10 Les échéances temporelles dans le modèle Figre 4.11 Métamodèle de notre l otil de simlation Figre 4.12 Règle de transformation en ATL Figre 4.13 Transformation de modèle avec l otil ATL Figre 4.14 Comparaison entre le fichier iss d modèle et le fichier généré Figre 4.15 Interface graphiqe de l otil d ordonnancement temps réel Figre 4.16 Résltats prédits par l otil et cex obtens sr cible

11 x Liste des tableax Tablea 1.1 Otils de modélisation UML por la conception de radio logicielle Tablea 1.2 Qelqes otils de transformation de langage Tablea 2.1 Système d exemple Tablea 2.2 Système d exemple Tablea 2.3 Système d exemple Tablea 2.4 Système d exemple Tablea 3.1 Table de correspondance entre l otillage et MARTE Tablea er exemple de tâches Tablea ème exemple de tâches Tablea ème exemple de tâches Tablea 4.4 Identifiants des tâches... 99

12 1 Introdction Télécommnications d hier à ajord hi Il est commnément reconn qe l homme existe socialement à travers la commnication, c est porqoi il a tojors e besoin de commniqer avec ses congénères. L élément essentiel sr leqel s est d abord appyé l homme por échanger est la voix et les gestes, mais por se comprendre il fat tiliser le même langage, tiliser le même protocole. A cors des âges, les moyens de commnications des hommes ont évolé en même temps qe l évoltion de lers mœrs et de lers besoins. Commniqant d abord a moyen de la voix, la portée de celle-ci a contraint les hommes à réfléchir à d atres moyens permettant de commniqer en s affranchissant de la distance. Les alternatives sont basées sr la mise en forme de l information sivant n protocole et sa transmission via n spport (n otil atre qe la parole). Ce ft le cas des peples d Afriqe qi dialogaient avec des tam-tams, des indiens d Amériqe par le biais des nages de fmées o des sémaphores des frères Chappe à la fin d 18 ème siècle en France. Ces moyens ne permettant pas d avoir de vraies discssions, la décoverte de l électricité a permis de mettre en place d atres protocoles et d expérimenter des moyens de commnications sr de pls longes distances. Ainsi la naissance d télégraphe en 1838 par Wheatstone associé a morse (1844) de Samel Morse ont permis d envoyer n message sr ne distance de 60km via le résea télégraphiqe. Ensite la compréhension de l onde radio a permis d envoyer des signax sans spport câblé. Par la site, se sont sccédés l apparition d téléphone (1876), d télégraphe sans fil (1899), de la radiophonie (1900), ainsi qe les protocoles tilisés par ces otils. Ces otils reposent sr des composants et des systèmes électroniqes, qi ex assi ont conn a fil d temps ne croissance rapide de lers capacités. La radio n a cessé de se développer a 20 ème siècle, por passer d applications militaires à ne mltitde d applications civiles dans lesqelles baigne notre vie qotidienne (GPS, TV, Radio, commandes d overtres à distance, réseax sans fil, etc.). Ajord hi, différents standards de commnications radio sont disponibles por le grand pblic : GSM, GPRS, EDGE, UMTS et bientôt LTE. Face à cette mltitde de standards radios, la mobilité accre des personnes, le besoin croissant d appareils ayant la capacité de s adapter atomatiqement à l environnement dans leqel ils se trovent, il est nécessaire de proposer des éqipements de transmission radio flexibles et adaptatifs. Une soltion sr laqelle les cherchers travaillent depis ne vingtaine d années est la radio logicielle. La Radio logicielle Le terme «Software Radio» (Radio logicielle) a été inventé en 1991 par le professer Joseph Mitola, qi a pblié n premier article sr le sjet en 1992 [90]. Bien qe le concept ait été proposé en 1991, la radio logicielle a ses origines dans les années 70 lorsqe l armée américaine s est intéressée à l interopérabilité entre divers systèmes

13 2 fonctionnant dans des bandes de commnications différentes (HF, VHF, UHF ), avec des chaînes de modlations différentes (AM et FM) et des formats de données différents. Une radio logicielle est ne radio dont les fonctions sont majoritairement implantées sos forme logicielle. Etant donné les contraintes technologiqes actelles, il y a tojors d matériel dédiés ax fréqences radio, mais l idée est d avoir, tant qe c est faisable, les traitements effectés sos forme logicielle le pls proche possible de l antenne. Les «entorses» a concept de la radio logicielle (idéale, tote en logiciel) ont fait apparaître n atre terme, la radio logicielle restreinte o «SDR» (Software Defined Radio), mais les dex appellations sont sovent considérées éqivalentes. La figre 1 présente n schéma simplifié d ne chaîne radio. antenne Sorce / Destinataire Coder / Décoder Modlater / Démodlater Fréqence Radio Fig. 1 Schéma simplifié d ne chaîne radio Une radio logicielle basiqe porrait consister en n processer de traitement d signal nmériqe, n convertisser nmériqe/analogiqe, ne carte RF/IF (conversion des fréqences intermédiaires en fréqence radio), et d ne antenne. Ainsi, ne qantité significative d traitement d signal est faite de manière logicielle sr le processer a lie d être implanté sr d matériel spécifiqe. Une telle conception permet à la radio de povoir spporter ne large variété de protocoles radios en se basant niqement sr des mises à jor logicielles [90]. Une radio logicielle est donc flexible. La formalisation de la radio logicielle s effecte a sein d n Form qi rassemble les acters majers d domaine. Il s agit d SDR Form (ajord hi Wireless Innovation Form), où les différents acters présentent les avancées dans le domaine. D aillers, les travax de cette thèse y ont été présentés. Por faciliter le développement de la radio logicielle les programmes américains de défense : JTRS (Joint Tactical Radio Systems) et le JPEO (Joint Program Exective Office) ont standardisé ne architectre por les éqipements radio. C est le SCA (Software Commnications Architectre) [91]. Le SCA spécifie les moyens de déploiement, de gestion, d interconnexion et d intercommnication des composants logiciels d ne radio. Le SCA est ne strctre architectrale qi a été créée por maximiser la portabilité, l interopérabilité, et la reconfigrabilité d logiciel tot en gardant la flexibilité por s adapter ax exigences et restrictions spécifiqes à n domaine. Les contraintes sr le développement d logiciel imposé par la strctre concernent les interfaces et la strctre d logiciel mais pas la mise en œvre des fonctionnalités qi sont exéctées.

14 3 Cependant, les applications de traitement d signal ont ne notion dale d exactitde : exactitde logiqe et exactitde temporelle. Il n est pas sffisant de jste prodire les données correctes (par exemple les données décodées sans errer de transmission). Les données correctes doivent être prodites dans n intervalle de temps borné, conn à l avance (par exemple les données décodées sans errer de transmission a bot de 2ms). Ces contraintes temporelles sont généralement imposées par le standard considéré. Ainsi, les évoltions de la conception radio entraînent des modifications dans le processs de conception, de vérification et de validation de l ordonnançabilité temps réel d ne radio logicielle. La vérification de l ordonnancement temps réel n est pas adressée dans le SCA. Contexte des travax de thèse Dans la pratiqe actelle, l ordonnancement temps réel d ne radio logicielle est fait de manière manelle, tilisant des méthodes empiriqes, basées sr l expérience des ingéniers. Cependant, considérons ne radio logicielle composée d ne part a nivea des applications, de 2 schémas de modlation OFDM (Orthogonal Freqency Division Mltiplexing), d n schéma de modlation CPM (Continos Phase Modlation), et d atre part a nivea de sa plate-forme matérielle d n processer génériqe, d n processer de traitement d signal nmériqe, de trois composants FPGA, de convertissers, d amplificaters et de trois antennes. Evidemment si nos avions ne approche matérielle, les algorithmes de traitement d signal émanant de ces 3 schémas de modlation s exécteraient en parallèle sr des circits intégrés séparés et dédiés. Dans cette approche, il n y arait pas de problème d ordonnancement temps réel car il sffirait de trover n ordre statiqe hors ligne entre les composants. Dans cette étde nos choisissons ne approche logicielle, compte ten de tos les avantages q elle apporte. Par conséqent si nos ramenons le problème de conception a cas d processer de traitement d signal nmériqe, étant donné la grande combinatoire de fonctions de traitement d signal povant s exécter simltanément sr ce processer, les méthodes manelles et empiriqes por l ordonnancement temps réel prendront beacop de temps, seront sjettes à errer, et ne réssiront pas à déterminer ne soltion faisable même lorsq il en existera ne. En effet contrairement à ne approche matérielle, les fonctions ne s exéctent pas en parallèle sr le processer, mais séqentiellement. Il fat par conséqent répartir l exéction des tâches a cors d temps sr le processer, ce qi crée des problèmes d ordonnancement temps réel. C est porqoi THALES Commnications S.A (Colombes) et SUPELEC (Camps de Rennes) ont proposé n sjet de recherche dans ce domaine. L objectif est de définir et mettre en place ne méthodologie de conception orientée MDA por la radio logicielle et intégrant des moyens de tests d ordonnançabilité temps réel. Ces travax s appient sr n projet d étde amont financé par THALES Commnications. Le projet consiste en ne implantation de la version mlti-tilisater d schéma de modlation OFDM avec évasion de fréqence (sat de fréqence) sr ne carte électroniqe composé d n PowerQicc, d n DSP et d n FPGA. Ainsi plsiers tilisaters partagent le même éqipement et l accès mltiple est atteint en assignant n sos-ensemble de sos-porteses à chaqe tilisater. Cet éqipement transmet des

15 4 signax radio en satant rapidement parmi plsiers fréqences porteses et en tilisant ne séqence psedo aléatoire conne par l émetter et le récepter. De pls étant donné, l émission et la réception en contin sr l antenne, certains traitements doivent être anticipés et exéctés simltanément par rapport à d atres. Par exemple la fonction qi programme les fréqences porteses sate en fréqence por la réception en cors d ne trame, pendant qe l on code la trame à émettre à la site de cette réception. Dans cette radio logicielle, plsiers fonctions devant être exéctées simltanément vont être implantées sos forme logicielle. Cet éqipement radio est programmable car tote la partie adressant le contrôle de la radio (.i.e. le séqencement et la programmation des fréqences porteses et de l amplificater de pissance) est effectée sos forme logicielle. Ainsi, on porra changer de bande de fréqence ainsi qe la liste des fréqences sr lesqelles on sate jste en faisant n changement des paramètres d logiciel. Nos allons montrer qe cette radio logicielle pose donc des noveax problèmes d ordonnancement temps réel dans le cas notamment d ne implantation monoprocesser. Les travax de cette thèse s intéressent à l ordonnancement temps réel des fonctions de traitement d signal qi ont été déployées sr le DSP. Dans ce docment, lorsqe nos parlons de radio logicielle cela intègre assi les radios logicielles compatibles SCA. Le SCA propose ne strctre permettant le déploiement de composants logiciels correspondants à n standard radio. Problématiqes abordées Le cadre de ce projet repose sr n cas d tilisation réel aqel doit répondre n éqipement, à savoir qe l éqipement radio spporte des trames de tailles différentes, car elles correspondent à des services différents (par exemple : trame adio petite taille, trame vidéo grande taille). Ainsi, les tâches logicielles implantant les algorithmes de traitement d signal de l éqipement radio ont des contraintes temporelles qi varient en fonction d type de trame en entrée. En effet les trames adio ont ne échéance temporelle pls corte qe celle des trames vidéo. De pls les trames vidéo nécessitent pls de temps de traitement qe les trames adio. Un atre point important est la modélisation de la tâche logicielle qi programme les fréqences porteses, car en fonction de la taille de la trame en entrée, le nombre d activations de la tâche varie assi. En otre, le concepter doit povoir disposer de méthodes li permettant de calcler les contraintes temporelles, d otillage, et d ne méthodologie de conception afin de déterminer la faisabilité temps réel des composants logiciels d ne radio. En résmé, le concepter de radio logicielle se pose la qestion sivante : Etant donné la spécification d ne radio logicielle, composée de tâches implantant des algorithmes de traitement d signal flexibles, i.e. avec des contraintes temporelles variables, comment pet-on déterminer en phase de conception, si l ensemble des tâches s exéctant simltanément sr n processer vont être ordonnancées de manière à ce qe chaqe tâche respecte ses échéances temporelles?

16 5 Contribtions Ce docment fornit les contribtions sivantes : (1) Un novea modèle de tâche (le modèle de tâche mlti-trames généralisées non cycliqes) et ne novelle formle por le calcl d temps de réponse des tâches s exéctant sr n processer en fonction de la politiqe d ordonnancement EDF (Earliest Deadline First). Ce modèle caractérise miex le comportement des tâches dans ne radio logicielle. A partir de cette formle, nos présentons n novea test de faisabilité sffisant. (2) Un algorithme efficace, por la détermination exacte de la faisabilité temps réel d n ensemble de tâches mlti-trames généralisés non cycliqes ordonnancées avec EDF. (3) Une méthodologie de conception permettant l analyse d ordonnancement temps réel dans ne radio logicielle. Nos présentons n ensemble de règles à sivre pendant les phases de modélisation PIM (Platform Independent Model), PDM (Platform Description Model) et PSM (Platform Specific Model), en considérant en particlier le profil MARTE [7] (ne spécialisation d UML por les systèmes temps réel embarqés). Une expérimentation est assi présentée afin de démontrer les avantages de nos méthodes. (4) Une approche por la vérification de l ordonnancement temps réel des tâches implantant des algorithmes de traitement d signal flexibles et s exéctant sr n processer en fonction d ne politiqe d ordonnancement hybride. Cette approche est implantée sos forme d n otil de simlation et nos démontrons qe nos obtenons ne bonne précision en comparant les résltats prédits par l otil avec cex obtens dans n cas réel d implantation sr cible matérielle. Plan d mémoire Ce docment s organise de la manière sivante. Le premier chapitre présente la strctre d ne radio logicielle ainsi qe les concepts de base en méthodologie de conception et en ordonnancement temps réel monoprocesser. Le dexième chapitre présente notre novea modèle de tâche, ne formle por le calcl d temps de réponse, n test de faisabilité sffisant, pis n algorithme efficace por l analyse exacte de l ordonnancement temps réel de notre novea modèle de tâche en considérant n ordonnancer EDF.

17 6 Le troisième chapitre montre la méthodologie de conception, et l otillage qe nos avons mis en place por déterminer la faisabilité temps réel des composants logiciels s exéctant simltanément sr n processer dans n éqipement radio. Le qatrième chapitre présente ne expérimentation de nos méthodes (s appyant sr n projet en cors de réalisation) qi démontre les avantages de notre méthodologie. Nos montrons assi dans ce chapitre qe notre otil de simlation a ne bonne précision en comparant les résltats prédits par l otil à cex obtens sr cible. Enfin la conclsion retrace nos travax effectés, présente qelqes améliorations qi porraient être apportées et ovre la voie sr ne porsite des travax.

18 Chapitre 1 Etat de l art 1.1 Introdction Les sccessions d innovations rapides de ces 25 dernières années dans le domaine de l électroniqe embarqée, sont notamment le résltat de l amélioration permanente de méthodologies de conception en adéqation avec les technologies des composants physiqes qi spportent ces applications. Une méthodologie de conception, dans le domaine de l électroniqe embarqée, est l ensemble des méthodes et otils, tilisés por mener à bien la conception de systèmes électroniqes. Ces systèmes électroniqes ont por la plpart la propriété d être «temps réel» car ils doivent répondre en des intervalles de temps bien précis, conns à l avance. Ce premier chapitre décrit d abord l architectre d ne radio logicielle telle q elle est envisagée dans cette étde, ensite il présente les différentes méthodes et langages dont le concepter dispose por décrire et concevoir n système. Il s attarde notamment sr le langage UML et sr la prise en compte de l aspect temps réel en phase de modélisation. Ce chapitre propose assi n état de l art de l ordonnancement temps réel sr ne architectre monoprocesser. A la fin de ce chapitre nos présentons les problématiqes d ordonnancement temps réel rencontrées drant la conception d ne radio logicielle. Il s agit d ne part des problématiqes liées à la prise en compte des contraintes temporelles drant la phase de modélisation et d atre part de problématiqes liées à la validation de l ordonnancement temps réel à partir de ces contraintes. 1.2 La radio logicielle Les activités hmaines tilisent de nombrex signax radio émanant des téléphones mobiles, de périphériqes de commnications «bletooth», de liaisons WIFI por l accès à internet, de signax destinés à des récepters AM/FM, des télévisers HD, des récepters GPS, de portes atomatiqes de garage (cette liste est loin d être exhastive). Par analogie avec le concept de l ordinater povant spporter différents types d applications, est appar le concept de radio logicielle (software radio) por exécter plsiers protocoles de commnications sr n même éqipement radio. Le terme «Software Radio», dont l objectif premier est d implanter ne majorité des fonctions d n éqipement radio de manière logicielle, a été proposé par Joseph Mitola [90]. Ainsi 7

19 Chapitre 1 Etat de l art 8 l éqipement radio est pls flexible par rapport à ne implantation où ne majorité des composants sont réalisés sos forme matérielle. Une radio logicielle est donc ne radio flexible où les fonctionnalités sont contrôlées avec le logiciel qi est capable d exécter plsiers formes d ondes sr le même éqipement radio en fonction des besoins opérationnels. Une forme d onde «waveform - [91]» correspond à la transformation entre ne entrée tilisater et ne sortie en fréqence radio et vice versa. Une forme d onde est définie grâce ax protocoles radio, qi sont conformes ax standards tel qe l UMTS, le GSM etc. o qi sont propriétaires et définis par les fabricants d éqipements radio. Par principe (approche logicielle de type PC), ne radio logicielle favorise la rétilisation, et la flexibilité car les évoltions de l éqipement pevent être facilement effectées avec des mises à jor logicielles a lie de remplacer le matériel. Les trois principax objectifs de la radio logicielle sont donc, la portabilité [93] des formes d ondes à travers les différentes plateformes radio, l interopérabilité entre les composants des formes d ondes, et la reconfigrabilité [94] de l éqipement afin de répondre à plsiers besoins opérationnels. L ajot dans ne radio logicielle d ne certaine intelligence, prodit ne radio cognitive o radio intelligente. Cette notion a été proposée par Joseph Mitola lors d n séminaire en 1998 pis pblié en 1999 dans [95]. Une radio intelligente est ne radio qi s adapte et optimise ses paramètres radio en fonction de l environnement por, par exemple, tiliser efficacement le spectre de fréqence et les ressorces disponibles. A-delà, tot ce qi permet ne meillere gestion des besoins des tilisaters, par ne adaptation en tempsréel des traitements relatifs a lien radio, est concerné par la radio intelligente. Qelqes méthodologies de conception ont été proposées dans le domaine de la radio intelligente [96] [19] [98] L architectre logicielle SCA L architectre logicielle SCA a por bt de faciliter le développement de radio logicielle en maximisant la portabilité, la rétilisation, et l interopérabilité d logiciel grâce à l tilisation des prodits et protocoles commerciax. L architectre a été développée en tilisant ne approche orientée objet avec les pratiqes corantes venant de l approche par composants et les «design patterns». Le SCA représente donc ne radio logicielle sos la forme d n ensemble de composants logiciels qi ont besoin de former n chemin de commnication et de s exécter sr n ensemble d éléments matériels. Il propose ne strctre commne afin de gérer les composants logiciels et matériels, ainsi q n je d interfaces por isoler l application logicielle d matériel. Il s agit d «core framework». Comme décrit dans la Figre 1.1, le «core framework» fait partie d n environnement d exéction (OE : Operating Environment). Grâce ax capacités de déploiement dynamiqe fornies par le «core framework», l OE pet reconfigrer n éqipement radio et permettre l exéction de plsiers formes d ondes en parallèle. En pls des services réalisés par le «core framework», l OE fornit le mécanisme de connectivité entre les composants (CORBA Common Object Reqest Broker Architectre), le service

20 1.2 La radio logicielle 9 de gestion d temps, n système d exploitation temps réel et ne interface compatible POSIX por l tilisation de ces services. La plateforme de la Figre 1.1 est composée de plsiers nités de calcls. En effet bien qe la radio logicielle idéale préconise qe totes les fonctions de traitement d signal soient réalisées de manière entièrement logicielle, certains traitements demandent ne très grande pissance de calcl et ont besoin d être mis en œvre sr des nités de calcls comme des FPGA. MAC MODEM Transceiver Waveform Application Application Environment Profile Corba APIs Core Framework interfaces POSIX specification ORB and Corba Services Core framework control, Services, devices and file access Operating Environment (OE) Operating System GPP DSP FPGA ADC DAC Hardware Platform Figre 1.1 Architectre logicielle d n éqipement radio d après le SCA Le SCA soffre d fait qe l architectre q il propose, engendre ne certaine latence dans le système et n est pas adapté por certains traitements fortement contraints en temps (notamment les traitements de la partie modem de l éqipement radio [102]). De pls cette architectre occpe ne empreinte mémoire non négligeable. Une novelle version d SCA (SCA NEXT) en cors de réalisation a por objectif de combler ces lacnes [103] Cas d étde de la thèse Le cas d étde aqel se rapporte cette thèse consiste à l implantation sr n éqipement radio de la version mlti-tilisater d schéma de modlation OFDM. Contrairement à la technologie actelle existante, la portée et la pissance de l éqipement radio considéré sont pls importantes. En effet l éqipement radio a ne pissance de 10 Wt por offrir n débit de 2 Mégabits/s sr ne distance de 5 km, alors la technologie WIFI b (tilisant elle assi ne modlation OFDM [100]) qe nos tilisons qotidiennement offre n débit de 2 Mégabits/s sr 400 m avec ne pissance de 10 mw. Cette portée pls importante est nécessaire dans n contexte militaire car les modems sont embarqés dans des véhicles avec lesqels les militaires se déplacent. Ce qi n est pas le cas d

21 Chapitre 1 Etat de l art 10 WIFI où les bornes sont fixes. Por atteindre ce débit à cette distance il fat implanter des algorithmes de traitement d signal pls robstes et par conséqent pls exigeants en termes de calcl. On va par exemple tiliser n trbo code por le codage et le décodage canal. Une implantation logicielle de cet algorithme (par rapport à son éqivalent matériel) ara n impact fort sr les contraintes temps réel. De pls l éqipement radio gère des trames de tailles différentes car elles correspondent à des services différents (vidéo grande trame, adio petite taille). Ceci impliqe des contraintes temporelles variables. Ce n est pas le cas dans le WIFI où la pile IP regrope généralement les données en paqets de même taille avant de les envoyer. Les trames de longers différentes sont assi rencontrées dans d atres systèmes à base d OFDM, comme le standard DVB-T por la diffsion de la TNT. En effet ce standard tilise le dispositif de compression vidéo MPEG [61] qi maniple trois types de trames conns sos le nom de trame I, trame P, trame B. Cependant ces trames de tailles différentes sont regropées en trame d ne longer de 288 octets en passant par ne coche transport MPEG2-TS [101]. Ainsi a nivea d modlater OFDM, les trames ont la même taille. Par conséqent contrairement à l éqipement radio considéré, le modlater OFDM d DVB-T traite donc des trames de même taille. En otre dans l éqipement radio considéré ici on sate en fréqence à l intérier de la trame car la trame est décopée en paliers émis et reçs à des fréqences porteses spécifiqes. Dans la technologie WIFI, il y a également n sat de fréqence, cependant la longer d sat est de 400 ms et les fréqences de sat sont fixes alors qe dans notre éqipement la longer d sat est infériere o égale à 1 ms et les fréqences de sat pevent changer pendant la commnication. Ainsi pendant 1 seconde d émission de données sr le WIFI on satera sr 2 fréqences fixes connes par l émetter et le récepter tandis qe dans notre éqipement on satera sr a moins 10 fréqences qi pevent changer pendant la commnication. Notre éqipement radio doit donc être pls réactif. La fonction de contrôle qi programme les fréqences porteses et l amplificater de pissance va également être implantée sos forme logicielle et s ajote ainsi ax fonctions d émission et de réception qe l on vet exécter sr le même processer, ce qi nécessite donc ne analyse temps réel approfondie. Cette capacité de configration dynamiqe de notre éqipement radio permet non selement d être pls robste face a mlti-trajet mais assi d adapter l éqipement à tot type de terrain (rral, rbain, montagnex, etc.). L n des problèmes rencontré pendant la conception d ne telle radio logicielle est donc de garantir l exéction simltanée, dans n intervalle de temps borné, des composants logiciels émanant de différentes chaînes (émission, réception, contrôle), sos des contraintes temporelles variables et non prévisibles (ordre d arrivée des trames arbitraire) sr n même processer. Por faire face à ce problème le concepter doit disposer d ne bonne méthodologie de conception.

22 1.3 Méthodologies de conception Méthodologies de conception Une méthodologie de conception correspond à n ensemble de méthodes qe doit sivre le concepter afin de réaliser son logiciel. Il existe dex grandes catégories de méthodologies de conception : les méthodologies de conception systématiqes et les méthodologies de conception formelles. Les méthodologies de conception formelles tilisent majoritairement des formles et notations mathématiqes afin de représenter le logiciel et vérifier sa consistance. Les méthodologies systématiqes tilisent moins de notations mathématiqes, et consistent en n ensemble de méthodes procédrales qi décrivent comment la strctre d logiciel doit être représentée. Depis les années 70, il y a e ne agmentation des méthodologies de conception. Différentes méthodologies ont été développées por résodre différents types de problèmes. En décrivant ces problèmes, il est sovent nécessaire de les regroper en problèmes ayant des caractéristiqes similaires. Un processs de conception typiqe consiste à la définition des exigences, la conception préliminaire, la conception détaillée, le codage, les tests nitaires, les tests d intégration et les tests de validation. Drant la conception les étapes préliminaires a développement sont formalisées dans le bt de rendre le développement fidèle ax besoins d client. La phase de conception définie donc de manière précise le fonctionnement d système. Très sovent, le concepter tilise n langage de modélisation por cela. Par conséqent la conception d n logiciel est généralement basée sr n je de modèles. Les modèles sont basés sr des langages et chaqe langage possède ne syntaxe et ne sémantiqe. Nos allons à présent présenter les concepts générax de conception Concepts générax de conception Les concepts générax rencontrés dans la conception de tot système logiciel sont : l abstraction, l encapslation, la modlarité et la hiérarchisation. Ils fornissent de bonnes pratiqes de conception. Ces concepts ont été présentés par Booch [2] dans le contexte de l approche orientée objet, mais sont assez génériqes por être appliqés dans tote approche de conception dans le domaine de l ingénierie. o L abstraction L abstraction correspond à la séparation entre les éléments pertinents d n système à n certain nivea de la conception, et cex moins pertinents à ce même nivea. L objectif est d agmenter la compréhension d système et diminer sa complexité [2] [3]. Une abstraction est formée en rédisant les informations contenes dans le système. Typiqement, seles les informations importantes à n nivea précis de conception sont retenes. Ainsi, le concepter pet se concentrer sr qelqes informations à chaqe étape de la conception. Un système pet avoir plsiers niveax d abstractions où sont exposés ne certaine qantité d informations à chaqe nivea. La simplification qe fornit ne bonne abstraction facilite la rétilisation en prodisant n concept qi pet être facilement appréhendé et ainsi tilisé dans d atres systèmes. Cependant pls n nivea d abstraction est élevé, pls l écart entre la spécification et sa mise en œvre est

23 Chapitre 1 Etat de l art 12 grand. Il est donc important de définir le bon je d abstractions depis la spécification jsq à la mise en œvre. Une abstraction identifie et regrope les informations commnes d ne entité. Un bon exemple d abstraction est le modèle OSI por les systèmes de commnications. Il est composé de 7 niveax d abstraction et chaqe nivea aborde différents besoins d système de commnications. o L encapslation Booch [2] définit l encapslation comme étant le processs consistant à compartimenter les éléments d ne abstraction qi constitent sa strctre et son comportement ; l encapslation sert à séparer l interface contractelle d ne abstraction de son implantation. Cette définition est considérée dans beacop de docments comme étant la référence por la définition d ne encapslation. L encapslation consiste donc à cacher la ve interne d ne abstraction afin de rédire sa complexité, agmenter sa robstesse et permettre a concepter de limiter l interdépendance entre les composants (logiciels dans le cas considéré). Ceci permet de protéger l intégrité d composant. Les tilisaters d composant ne pevent pas modifier les données propres a composant vers ne sitation invalide o inconsistante. o La modlarité La modlarité consiste à décomposer n système en n ensemble de composants appelés modles. Chaqe modle permet d accomplir ne fonctionnalité. Les modles permettent la séparation des préoccpations et agmentent la maintenabilité d système en imposant des bornes logiqes entre les modles. Les modles sont intégrés dans le système grâce à des interfaces et chaqe interface exprime les éléments qe fornissent le modle et les éléments q il nécessite. Un système modlaire est de loin pls rétilisable et pls facile à assembler q n système non modlaire. Ainsi, les éléments d ne éqipe n ont pas forcément besoin de connaître le système dans son intégralité por travailler sr différentes sos-parties d système. Ils pevent se concentrer jste sr la tâche qi ler a été assignée. Cependant n compromis doit être trové entre le nivea de granlarité d n modle et le nombre de modles. En effet lorsq il y a trop de modles, il y a trop d interfaces, ce qi est bien pls difficile à gérer q n système avec pe de modles. o La hiérarchisation La hiérarchisation consiste à établir n ordre à travers les différents niveax d abstractions [2]. Le système est décomposé en niveax d abstraction hiérarchiqes. A partir d n nivea spérier, on pet décliner n/plsiers nivea(x) inférier(s). Les informations et comportements spécifiés a nivea spérier sont hérités et tilisés a nivea inférier. La notion d héritage tilisée en programmation orientée objet (notamment en langage C++) est n bon exemple de hiérarchisation. En effet les classes filles sont dérivées des classes mères par héritage. Elles possèdent les attribts et méthodes définies dans les classes mères.

24 1.3 Méthodologies de conception Les langages Les langages de programmation et de modélisation ont été développés dans le bt d élever le nivea d abstraction aqel la conception des systèmes est effectée. Ils permettent de miex gérer la complexité croissante des systèmes embarqés et d accroître la prodctivité. En effet avec par exemple les langages de programmation, nos povons rédire le temps de développements et les coûts pisqe moins de lignes de code sont nécessaires por réaliser la même fonctionnalité (par exemple le passage de l assembler ax langages pls évolés comme le langage C). Par aillers les langages de modélisations facilitent la génération atomatiqe de sqelette de code et l exploration de différentes soltions, ce qi permet d agmenter considérablement la prodctivité. o Langages de modélisation Le langage UML Le langage UML (Unified Modelling Langage) est n langage de modélisation standardisé et mainten par l OMG (Object Management Grop) depis Ce langage, spporté de manière graphiqe, est défini par n métamodèle UML, li-même défini à partir d MOF (Meta Object Facility) [4]. Ce dernier décrit les informations tilisées par les métamodèles. Ces mêmes métamodèles décrivent la sémantiqe (définition et sens d tilisation) des éléments employés dans les modèles et lers relations. UML permet ax concepters de modéliser n système complexe sivant plsiers aspects tel qe lers caractéristiqes strctrelles et comportementales. UML spécifie 15 diagrammes divisés en dex principales catégories : modélisation strctrelle et modélisation comportementale. Nos n allons pas décrire tos ces types de diagrammes ici, néanmoins nos présentons ne description de qelqes ns [2] : Représentation statiqe o strctrelle Le diagramme de package décrit les dépendances entre les packages qi composent n modèle. Les diagrammes de package pevent être tilisés por illstrer les différentes fonctionnalités d n système o por représenter les différentes coches d n système. Le diagramme de composant décrit comment le système est sbdivisé en composants et montre les dépendances entre les composants. Les composants sont reliés entre ex en tilisant n connecter d assemblage afin de connecter ne interface reqise par n composant avec ne interface fornie par n atre composant. Le diagramme de déploiement décrit l architectre matérielle tilisée dans le système, l environnement d exéction ainsi qe les éléments déployés sr le matériel. Le diagramme de classe décrit la strctre d système en montrant les classes d système, lers attribts, lers opérations et les relations entre les classes. Le diagramme de classe est tilisé assi bien por la conception générale de

25 Chapitre 1 Etat de l art 14 l application qe por la conception détaillée en transformant les modèles en code sorces. Le diagramme de strctre composite montre la strctre interne d ne classe et les collaborations qe cette strctre rend possible. Une strctre composite est n ensemble d éléments qi collaborent à l exéction por atteindre n bt précis. Chaqe élément a n rôle défini dans la collaboration. Le diagramme d objets décrit ne ve partielle o complète d ne strctre d système modélisé à n instant précis. Représentation comportementale Le diagramme d activité fornit ne description étape par étape des flx d activités d n système. Il montre l intégralité d flx de contrôle. Le diagramme de séqence montre comment les processs interagissent entre ex et dans qel ordre. Il est composé de lignes de vie, d opérations et permet de spécifier n scénario d exéction simple. Le diagramme de cas d tilisation décrit les fonctionnalités fornies par le système en termes d acters, lers bts (représentés sr forme de cas d tilisations) et totes les dépendances entre les cas d tilisations. Le diagramme de machine à états exprime le comportement d système sos forme de machines à états finis. Le passage d n état à n atre est déclenché par des évènements. Le diagramme temporel montre les variations d ne donnée a cors d temps. Il s agit d ne forme spéciale des diagrammes de séqence où les axes sont inversés de manière à ce qe le temps s école de gache vers la droite. Les lignes de vies sont présentées dans des compartiments séparés, rangés de manière verticale. Le diagramme de commnication décrit les interactions entre les objets en termes de séqences de messages. Il représente la combinaison des informations prises dans des diagrammes de classes, de séqences et de cas d tilisations en décrivant la strctre statiqe et le comportement dynamiqe d n système. Chacn de ces diagrammes maniple des éléments particliers de la sémantiqe UML, ce sont des «Class», des instances de classe «Object», des «components» etc. Les différents domaines d activités qi tilisent UML, disposent des mêmes éléments UML (isss d métamodèle) por modéliser lers applications. Or les applications sont très variées, et les objets maniplés différents. UML offre donc n mécanisme de spécialisation des éléments liés ax classes d applications, qi ler confère ne sémantiqe adaptée à ler domaine. Cette spécialisation s effecte par le biais de profils UML qi apportent des extensions a langage. Adapter UML : Les profils Le profil définit la sémantiqe particlière qi spécialise UML por n domaine d activité. Il est composé d n certain nombre de stéréotypes qi permettent d attriber

26 1.3 Méthodologies de conception 15 des caractéristiqes particlières (paramètres) ax divers éléments d métamodèle. Plsiers profils ont été développés et standardisés por intégrer les aspects temps réel des systèmes électroniqes et permettre des vérifications et validations temporelles. C est le cas des profils (1) «UML Profile for Schedlability, Performance and Time» (SPT) [5] et (2) «UML Profile for Modelling QoS and Falt Tolerance Characteristics and Mechanisms» (QoS) [6]. Le premier (1) apporte la sémantiqe des contraintes temps réel tiles ax analyses d ordonnancement temps réel avec certaines caractéristiqes de qalité de services introdites en tant q attribt. Le second (2) profil décrit les caractéristiqes permettant d apporter des informations non fonctionnelles à n système en terme de qalité de service (QoS) (latence, sûreté, probabilité d errer, etc.), les restrictions qi lers sont imposées (bornes), et ceci en fonction de plsiers modes d exéction. Concernant les profils UML por la radio logicielle, le profil «UML Profile for SWRadio» [9] a été proposé afin de permettre la modélisation de radio logicielle. Il étend le langage UML 1.4 non selement por modéliser, mais assi por permettre la génération atomatiqe de fichiers de description (fichier XML) et de code (sqelette). Une atre tentative de profil por la radio logicielle ft le profil A3S (Adéqation Architectre Application Système) [10]. Il permettait d effecter des vérifications de cohérence sr des modèles de radio logicielle et était basé sr UML 1.4 or nos tilisons ajord hi UML 2. En otre ces profils ne sont pas sffisants por exprimer l intégralité des caractéristiqes d n système complet. De pls, les mécanismes d annotation et d tilisation des éléments ne sont pas simples et ils ne facilitent pas la constrction et la compréhension des modèles. A-delà d domaine de la radio logicielle n novea profil a été développé afin d offrir davantage de possibilités de développement, de flexibilité et faciliter la modélisation. C est le profil MARTE «UML profile for Modelling and Analysis of Real-time and Embedded Systems» [7]. Le profil UML MARTE Le profil UML MARTE remplace les profils SPT et QoS. Il est compatible avec d atres standards de l OMG tel qe SysML, SAE AADL (Society for Atomotive Engineer Architectre Analysis and Design Langage), ARINC 653 (Aeronatical Radio Incoporated). Le profil UML MARTE est composé de trois parties principales : la première partie définit les concepts de base tilisés dans les systèmes temps réel embarqés avec les notions de propriétés non fonctionnelles (NFP : Non-Fnctional Properties), de temps (Time), de ressorce (GRM : Generic Resorce Modelling), et d allocation (Alloc). La seconde partie est le modèle de conception temps réel embarqé (Real-time Embedded Design model). Elle permet la description de composants logiciels (SRM : Software Resorce Modelling) et plateformes matérielles (HRM : Hardware Resorce Modelling). La dernière partie est le modèle d analyse temps réel embarqé, qi spporte l analyse qantitative. La Figre 1.2 représente l architectre d profil MARTE.

27 Chapitre 1 Etat de l art 16 Figre 1.2 Architectre d profil UML MARTE o Langages de programmation Un langage de programmation est n langage artificiel conç por exprimer des calcls qe pevent effecter ne machine. Un langage de programmation pet être tilisé por contrôler le comportement d ne carte électroniqe, o por exprimer n algorithme de traitement d signal par exemple. C/C++ Le langage C est n langage de programmation impératif (procédral) développé par Dennis Ritchie entre 1969 et 1973 a Bell Labs por tiliser le système d exploitation UNIX. C est l n des langages les pls poplaires de tos les temps car il existe beacop d architectres matérielles por lesqelles n compilater C existe. Il permet d effecter des accès mémoire de bas nivea et nécessite n spport d exéction minimal. Cet n langage très proche des langages machines. Il a beacop inflencé le langage C++, qi a commencé comme étant ne extension d langage C. Le langage C++ a été développé par Bjarne Strostrp a Bell Labs. Il ajote a langage C les notions de classes, d héritage, de polymorphisme, de fonctions virtelles, de srcharge d operaters, de «templates» et de gestion des exceptions. C est n langage de nivea intermédiaire car il combine les caractéristiqes des langages de hat nivea et de bas nivea. Java Le langage Java est n langage de programmation développé à l origine par James Gosling à Sn Microsystems (qi fait parti ajord hi d Oracle). Le langage Java dérive la plpart de sa syntaxe d langage C et C++, mais possède n modèle d objet simple avec pe de possibilités de bas nivea. Les codes sorces java son compilés en «bytecode» et pevent être exéctés sr n importe qelle architectre matérielle possédant ne «Java Virtal Machine» (JVM).

28 1.3 Méthodologies de conception 17 o Langage HDL (Hardware Description Langage) Un langage HDL est n langage de description formelle et de conception des circits électroniqes. Il est composé d expressions textelles correspondant à la strctre spatiale et temporelle d n système électroniqe ainsi qe son comportement. Un langage HDL possède ne syntaxe et ne sémantiqe explicite por exprimer la concrrence. Contrairement a langage de programmation logiciel, il possède ne notion explicite d temps, qi est n attribt principal d matériel. Les langages HDL sont tilisés por écrire des spécifications exéctables de certaines parties matérielles. Por cela, le code HDL est synthétisé en n circit matériel grâce ax otils de synthèse. L otil de synthèse (l éqivalent d compilater en langage de programmation) transforme le code HDL en ne liste physiqe de portes (netlist). On appelle «netlist» les langages dont la sele caractéristiqe est de décrire les connexions entre les différents blocs d n circit. Une étape essentielle de la conception HDL est la capacité de simler les programmes HDL. En effet la simlation permet de vérifier si la conception effectée en langage HDL réalise bien la fonctionnalité vole. Elle permet assi ne exploration de l architectre car le concepter pet expérimenter plsiers choix de conception en écrivant plsiers variantes de la conception de base et en comparant le comportement en simlation. Les dex langages HDL les pls répands et tilisées en indstries sont : VHDL (VHSIC hardware description langage ; VHSIC : very-high-speed integrated circit) et Verilog Les modèles de calcls Le modèle de calcl (model of comptation) expliqe comment le comportement de l ensemble d système est le résltat d comportement de chacn de ses composants. Le modèle de calcl décrit la sémantiqe de commnication entre les composants. Il pet être tilisé por mesrer la complexité d n algorithme en temps d exéction et en mémoire. En considérant certains modèles de calcls, il est possible de calcler les ressorces nécessaires por exécter n algorithme o alors discter sr ces limites. Les modèles de calcls décrivent l évoltion d n calcl et sont sovent exprimés comme la description d ne forme d atomate. Plsiers modèles de calcls ont été identifiés dans la littératre. Synchronos Data Flow (SDF) Le flot de données est n paradigme natrel por décrire les applications de traitement d signal. Por les applications de traitement d signal, les programmes en flots de données sont des graphes directs où chaqe nœd représente ne fonction et chaqe arc n chemin d signal. Le flot de données synchrone est n cas spécial de flot de données dans leqel le nombre d échantillons de données prodit/consommé par chaqe nœd est conn a priori [11]. Les nœds pevent donc être ordonnancés de manière statiqe (à la compilation) dans n sel o plsiers processers en parallèle. Par conséqent les dépassements observés à l exéction des flots de donnés sont éliminés. Les tax d échantillons mltiples rencontrés dans n système sont assi facilement gérer. Le principe d n flot de données est qe chaqe nœd ne pet effecter son calcl qe si ses

29 Chapitre 1 Etat de l art 18 données en entrées sont disponibles sr son arc d entrée. Un nœd qi n a pas d arc d entrées pet effecter son calcl à n importe qel moment. Commnicating Seqential Processes (CSP) C est n langage formel por décrire les modèles d interaction dans les systèmes concrrents. Il est bien adapté à la modélisation et l analyse des systèmes qi comprennent des échanges de messages complexes [12]. Le CSP a été décrit en 1978 par C. A. Hoare mais a depis considérablement évolé. Il a été appliqé dans l indstrie comme n otil por la spécification et la vérification des aspects concrrents sr différents systèmes tels qe les systèmes sécrisés d e-commerce. Kahn Process Networks (KPN) C est n modèle de calcl distribé où n grope de processs séqentiels déterministes commniqent grâce à des canax FIFO non bornés. Le modèle a été initialement développé por la modélisation de systèmes distribés [13], mais a prové sa convenance por la modélisation des applications de traitement d signal. Réseax de pétri (petri nets) Un résea de pétri est n graphe orienté direct biparti, dans leqel les nœds représentent les transitions (c est à dire les événements qi pevent srvenir, signifié par des barres) et des liex (c est à dire les conditions signifiées par des cercles). Les arcs orientés indiqent qels liex sont des pré o post conditions ax transitions. Les réseax de pétri ont ne définition mathématiqe exacte de ler sémantiqe d exéction, avec ne théorie bien développée por l analyse des processs. Atomates à états finis (Finite State Machine) Il s agit d n modèle de comportement composé d n nombre fini d états, les transitions entre ces états, et les actions. Il est similaire à n graphe de flot dans leqel on pet inspecter la manière avec laqelle la logiqe s exécte lorsqe certaines conditions sont remplies. Le fonctionnement d n atomate à états finis commence à partir de l n de ses états (appelé état de départ), passe par des transitions en fonction des entrées ax différents états et se termine sr l n des états disponible. Cependant sel n certain nombre d états (états finax) marqent n bon dérolement de l opération. Des otils ont été développés por modéliser et simler les modèles de calcls, et étdier ler hétérogénéité. En gise d exemple, on pet citer : Ptolemy [14] Les modèles de commnications o Le modèle OSI Le modèle OSI (OSI Open System Interconnection) est n moyen de sbdiviser n système en sos parties (appelées coches) dans le domaine des commnications. Une

30 1.3 Méthodologies de conception 19 coche est ne collection de fonctions similaires sr le plan conceptel qi fornit des services à la coche a desss et reçoit des services de la coche en dessos. Le modèle OSI est composé de 7 coches. La coche physiqe La coche physiqe définit les spécifications électriqes et physiqes por le transfert d n flx de bits sr n média de commnication. Elle est responsable de l établissement et de la terminaison de la commnication sr le média de commnication. Elle effecte la modlation, pis la conversion entre les données nmériqes dans l éqipement de l tilisater et les signax transmis à travers le média de commnication. La coche liaison de données Elle est responsable des commnications entre les nœds adjacents d n résea. Elle est en otre responsable de la srveillance, la correction d flx de trames ainsi qe des errers qi se glissent dans la transmission de trames. Dans certains réseax, tels qe les réseax locax (LAN : Local Area network) la coche liaison de données se compose de dex sos-coches : la sos-coche de contrôle de liaison logiqe (LLC Logical Link Control), et la sos-coche de contrôle d accès a média (MAC Medim Access Control). Comme exemple de coche liaison de données, on pet citer l Ethernet por les réseax LAN, o le PPP (Point-to-Point Protocol). La coche résea La coche résea fornit les moyens de transférer des données de tailles variables d ne machine hôte sorce sr n résea vers ne machine destinataire sr n atre résea, tot en maintenant la qalité de service demandée par la coche transport. Elle effecte les fonctions de rotage, et porrait assi effecter la fragmentation, le réassemblage o fornir les errers de livraisons. C est à ce nivea qe travaillent les roters. La coche transport La coche transport fornit les services de commnications de bot en bot por les applications entre dex systèmes sr le résea. Elle est chargée de transmettre le message complet d n processs sr la machine hôte à n atre processs sr la machine destinataire. Elle divise le message en paqets nmérotés qi, après la transmission, sont rassemblés dans le bon ordre. La coche transport fornit des services tel qe la commnication en mode connecté (TCP/IP), la fiabilité, le contrôle de flot, le mltiplexage. La coche session La coche session fornit le mécanisme d overtre, de clôtre et la gestion d ne session entre les processs de l application finale, à savoir n dialoge semi permanent. Les sessions de commnications sont composées de reqêtes et de réponses qi se prodisent entre les applications.

31 Chapitre 1 Etat de l art 20 La coche présentation La coche présentation est responsable de la livraison et d formatage de l information à la coche application por n traitement ltérier o por l affichage. Il solage la coche application de la préoccpation concernant les différences de syntaxe dans la représentation des données d système de l tilisater final. La coche application La coche application d modèle OSI est la coche la pls proche de l tilisater final. Ce qi signifie qe la coche application et l tilisater interagissent directement avec l application logicielle. Les fonctions réalisées par la coche application comprennent : l identification des protagonistes de la commnication, la détermination des ressorces disponibles, la synchronisation de la commnication. Comme exemple de coche application, nos povons citer n lecter adio/vidéo tel qe VLC L ingénierie dirigée par les modèles L ingénierie dirigée par les modèles (MDE Model Driven Engineering) est ne méthodologie de développement logiciel/matériel qi se concentre sr la création de modèles, o des abstractions, pls proche de certains concepts d n domaine particlier pltôt qe des concepts informatiqes o algorithmiqes. Elle a vocation à accroître la prodctivité en maximisant la compatibilité entre les systèmes, ce qi simplifie le processs de conception, et de promovoir la commnication entre les ingéniers et les éqipes travaillant sr le système. Les modèles sont développés grâce à ne commnication étende entre les encadrants, les concepters, et les membres de l éqipe de développement. La meillere initiative MDE conne est l architectre dirigée par les modèles (MDA Model Driven Architectre), initiative de l OMG L approche MDA L approche MDA est ne démarche de développement proposée par l OMG, permettant de séparer dex visions extrêmes d même système : ses spécifications fonctionnelles d ne part, sa mise en œvre physiqe d atre part, inclant plsiers aspects de la vie d logiciel, à savoir ses tests, ses exigences qalité, la définition des itérations sccessives, etc. Por ce faire, l approche MDA propose de strctrer les besoins selon ne architectre indépendante d contexte techniqe, avant de se livrer à ne transformation de cette modélisation fonctionnelle en modélisation techniqe, tot en testant chaqe modèle prodit. La mise en œvre d processs MDA pet se décoper en 4 étapes : 1. La réalisation d n modèle indépendant de tote plate forme appelée PIM (Platform Independent Model), 2. L enrichissement de ce modèle par étapes sccessives, 3. En fonction des modèles de description de plate forme (PDM Platform Description Model), n choix d ne plate forme de mise en œvre est effecté

32 1.3 Méthodologies de conception 21 pis, s en sit la génération d modèle spécifiqe correspondant appelé PSM (Platform Specific Model), 4. Le raffinement de celi-ci jsq à l obtention d ne implantation exéctable. La Figre 1.3 décrit ces différentes étapes. 1 PIM 2 PDM 3 PSM 4 Figre 1.3 Les étapes d ne démarche MDA o Modèle indépendant de la plate-forme (PIM) La première étape d processs MDA consiste à réaliser n modèle indépendant de tote plate forme. Il existe plsiers niveax de PIM mais tos sont indépendants de n importe qelle plate-forme. Le PIM de base représente niqement les capacités fonctionnelles métiers et le comportement d système, sans «dégradations» par des considérations technologiqes. La clarté de ce modèle doit permettre à des experts d domaine de le comprendre bien miex q n modèle de mise en œvre. Ils pevent ainsi vérifier pls facilement qe le PIM est complet et correct. Un atre bénéfice de l indépendance techniqe de ce modèle est q il garde tot son intérêt a cors d temps et doit être modifié niqement si les connaissances o besoins métiers changent. Une fois le PIM sffisamment détaillé, il est projeté vers n modèle spécifiqe. o Modèle spécifiqe à la plate-forme (PSM) Por obtenir n modèle spécifiqe, il fat choisir la o les plates-formes d exéction (plsiers plates-formes pevent être tilisées por mettre en œvre n même modèle). Les caractéristiqes d exéction et les informations de configration qi ont été définies de façon génériqe sont converties por tenir compte des spécificités de la plate-forme. Comme por les PIM, il existe plsiers niveax de PSM. Le premier, est obten directement à partir d modèle PIM, les atres sont obtens par transformations sccessives jsq à l obtention d système exéctable. o Les bases techniqes A cœr d MDA, se trovent plsiers standards importants de l OMG : UML, le Meta Object Facility (MOF), le XML Metadata Interchange (XMI) et le Common

33 Chapitre 1 Etat de l art 22 Warehose Metamodel (CWM). Ces standards définissent l infrastrctre d MDA. Ils sont complétés par des règles de transformation de modèles. Meta Object Facility (MOF) Le langage MOF fornit le standard de métamodélisation et d échange de constrctions tilisées par MDA. Les atres modèles standards de l OMG, comme UML et CWM sont définis par des constrctions MOF, ce qi permet de les relier entre ex. C est également le mécanisme par leqel les modèles sont sérialisés en XMI. Le MOF est n exemple de métamétamodèle. Il définit les éléments essentiels, la syntaxe et la strctre des métamodèles tilisés por constrire des modèles. La spécification MOF fornit les points sivants : - Un modèle abstrait d objets MOF génériqes et lers associations. - Un ensemble de règles por exprimer n métamodèle MOF à l aide d interfaces IDL. - Un ensemble de règles sr le cycle de vie, la composition et la fermetre sémantiqe des éléments d n métamodèle MOF. - Une hiérarchie d interfaces réflexives permettant de décovrir et manipler des modèles basés sr des métamodèles MOF dont on ne connaît pas les interfaces. Un intérêt d MOF est q il permet de faire interopérer des métamodèles différents. Une application MOF pet manipler n modèle à l aide d opérations génériqes sans connaissance d domaine. XML Metadata Interchange (XMI) Le langage XMI permet de décrire ne instance d MOF sos forme textelle, grâce a langage extensible Markp Langage (XML) d W3C (World Wide Web consortim). XMI définit comment tiliser les balises XML por représenter n modèle MOF en XML. Les métamodèles MOF sont décrits par des DTDs (Docment Type Definition). Le XMI résot beacop de problèmes rencontrés lorsqe l on vet représenter des objets et les associations sos forme textelle. De pls, pisqe XMI est basé sr XML, les métamodèles (tags) et les instances (elements) sont regropés dans le même docment, ce qi permet à ne application de comprendre les instances grâce à lers métadonnées. Le XMI est le format d échange standard entre les différents otils MDA. Common Warehose Metamodel (CWM) Le CWM est le standard de l OMG por les techniqes liées ax entrepôts de données. Il covre le cycle de vie complet de modélisation, constrction et gestion des entrepôts de données. Le CWM définit n métamodèle qi représente les métadonnées assi bien métiers qe techniqes qi sont le pls sovent trovées dans les entrepôts de données. Il est tilisé à la base des échanges de métadonnées entre systèmes hétérogènes. Le CWM comprend actellement n certain nombre de métamodèles concernant les entrepôts de données (représentation des données, analyse, gestion). Les métamodèles de données permettent de modéliser des ressorces comme les bases de données relationnelles, les bases de données orientées objet. Une coche d analyse d CWM définit des métamodèles por les transformations de données, la visalisation, la

34 1.3 Méthodologies de conception 23 nomenclatre et le datamining. Une coche de gestion est constitée de métamodèles représentant les processs standards, la jornalisation et la planification des activités. Finalement, le métamodèle de base définit les services et éléments commns, comme les types de données, les projections vers les types de systèmes, les clés et index, les expressions et le déploiement de programmes à base de composants. Il est possible à l aide d otils CWM de générer ne instance d entrepôt de données à partir de son modèle. Transformations de modèles Les techniqes de transformation de modèles sont assi a cœr d MDA. La transformation de modèle consiste à convertir n modèle sorce M1 conforme à n métamodèle MM1 en n modèle M2 conforme à n métamodèle MM2 en tilisant des règles de «mapping». Une transformation de modèle convertit n modèle d n nivea d abstraction donnée vers n atre modèle d n atre nivea d abstraction tot en gardant les dex modèles synchronisés. Les règles de transformation sont rétilisables, elles pevent être appliqées à l ensemble des modèles sorces conformes a métamodèle por leqel les règles de «mapping» ont été définies. De pls les modèles pevent être accompagnés de contraintes en OCL (Object Constraint Langage) afin de vérifier ler validité tot a long d processs. La transformation atomatiqe de modèles rédit le temps de développement tot en agmentant la qalité d logiciel. L OMG a défini n standard por la transformation de modèle QVT (Qery/View/Transformation) [15]. La spécification QVT est organisée en ne partie déclarative et ne partie impérative. Certaines réalisations de QVT sont développées dans le sos projet «Model to Model Transformation (M2M)» d projet «Eclipse Modelling Project». ATL (Atlas Transformation Langage) est n langage de transformation de modèle et n otil développé par l INRIA et la société OBEO. ATL est n composant d sos projet M2M et est disponible sos eclipse. Il existe d atres otils de transformation de langage ayant les mêmes capacités qe cex définies dans QVT tel qe Kermeta workbench [89] et Tefkat [78] La conception de type PBD (Platform-Based Design) La conception de type PBD [16] consiste à «mapper» sccessivement le modèle d ne application et le modèle d ne plate-forme à travers plsiers niveax d abstractions jsq à l obtention d système électroniqe désiré. PDB est ne approche «middle-ot», où ne instance d ne application venant de la liste des applications, et ne instance de plate-forme venant de la liste des plates-formes, sont «mappés» ensemble et raffinées par étapes sccessives afin d explorer ne possibilité de conception. Ce type d approche à d abord été proposé par Gajski et Khn [18] (Y-chart model). Le modèle de l application est n modèle abstrait et formel, typiqement n algorithme. Alors qe le modèle de plate-forme correspond à ne mise en œvre spécifiqe.

35 Chapitre 1 Etat de l art 24 Le modèle de l application décrit des fonctionnalités à réaliser et les services reqis qi doivent être fornis par le modèle de plate-forme caractérisé par les contraintes de plateforme. Méthodologie de conception A3S La méthodologie A3S (tilisé lors de la conception avec le profil A3S) est basée sr la méthodologie de conception PBD [17] [97]. Cette méthodologie ne reqiert qe dex types de diagrammes UML : le diagramme d activité et le diagramme de déploiement. Elle considère qe les concepters disposent d ne bibliothèqe d IP (Intellectal Property) matérielles/logicielles et propose ne spécification en 4 étapes. - Modélisation de l architectre matérielle : le concepter pet indifféremment débter par la modélisation de son (ses) architectre(s) matérielle(s) o de son (ses) application(s). Une bibliothèqe de composants dit «matériels» li propose n ensemble de composants matériels q il pet tiliser por créer son architectre. - Modélisation de l application : sachant qe le concepter pet rétiliser des codes logiciels de traitements déjà développés dans d atres applications, sachant également qe les applications pevent être décomposées en tâches spécifiqes, ne seconde bibliothèqe de composants dit «logiciels», li propose n ensemble de composants logiciels représentant des fonctionnalités. Il pet donc modéliser sa (ses) application(s) de manière indépendante de tote cible architectrale par l assemblage de composants logiciels «génériqes» sos la forme d n graphe de tâches. - Déploiement : ne fois l application logicielle et l architectre matérielle modélisées, le concepter pet décider des choix d implantations. Il choisit alors manellement la réalisation en matériel o en logiciel de chacne des fonctions d graphe de tâches. - Vérifications et Analyse : A chacne des étapes précédentes, des vérifications sont effectées por valider les modèles réalisés. Méthodologie de conception MOPCOM La méthodologie MOPCOM [19] [99] est n raffinement de la méthodologie MDA «Y- chart». Les techniqes MDA coplées avec UML sont tilisées por effecter de la génération de code (VHDL, C/C++, SystemC). Il prend en entrée des exigences fonctionnelles, non fonctionnelles et en termes d allocation. La modélisation s effecte en 3 niveax d abstractions. - AML (Abstract Modelling Level) : il a por bt de fornir la description d nivea sohaité de concrrence et de pipeline à travers le «mapping» de bloc fonctionnels sr des plates-formes d exéction virtelles. - EML (Exection Modelling Level) : il a por bt de fornir la topologie d ne plateforme génériqe définie en terme d exéction, commnication o stockage de nœds afin d effecter ne analyse gros grain. - DML (Detailed Modelling Level) : il a por bt de fornir ne description détaillée de la plate-forme afin de procéder à ne analyse à grain fin. Il permet la génération de code por cible matérielle (VHDL) o logicielle (langage C).

36 1.3 Méthodologies de conception 25 Por chaqe nivea, la méthodologie définit les sos-ensembles de MARTE qi sont obligatoires ainsi qe les contraintes de modélisation à respecter Otils de conception Plsiers otils de conception d applications existent à ce jor, cet état de l art s intéresse niqement ax otils de modélisation UML, ax otils de transformation de langage et ax otils de vérification d ordonnancement temps réel pertinents por la conception radio logicielle. o Otils de modélisation UML Un otil de modélisation UML est ne application qi spporte certaines o totes les notations et sémantiqes d langage UML. La plpart des otils de modélisation UML permettent : La création et l édition de diagrammes UML. La génération de code à partir de modèles et la génération de modèles à partir d code L échange de modèles via les fichiers de format XMI. Le Tablea 1.1 présente qelqes otils de modélisation UML. Nom de l otil AgroUML BoUML Qelqes détails Sos licence BSD, écrit en java, disponible sr totes les plates-formes spportant java, génère d C++, C#, Java, Php, Python, Rby Intégré avec Qt3, génération de code java, C++, Php, Python, IDL. Sos licence GNU GPL. MagicDraw Intégré avec Eclipse, EMF, netbeans. Spporte UML 2.3, génération de code Java C++, C#, CORBA IDL, DDL, plgin MARTE disponible Objecteering Papyrs Rational software Architect Rational Rhapsody Basé sr Eclipse, génération de code Java, C++, C#, SQL DDL, CORBA IDL et Fortran. Otil open sorce spportant UML 2, basé sr eclipse sos licence EPL (Eclipse Pblic Licence) Basé sos eclipse, spporte UML 2, génération de code de UML vers Java, C#, C++, EJB, WSDL, XSD, CORBA, SQL. De Java vers UML, d C++ vers UML, plgin MARTE disponible Spporte UML 2 et SysML. Génération de code C, C++, Ada, Java. Tablea 1.1 Otils de modélisation UML por la conception de radio logicielle

37 Chapitre 1 Etat de l art 26 En particlier dans le contexte SCA, le plgin eclipse Zeligsoft CX et l otil Spectra permettent de modéliser ne application radio logicielle et générer le code des ports et des conteners de composants logiciels compatibles avec le standard SCA. o Otils de transformation de langage Le Tablea 1.2 présente qelqes otils de transformation de langage. Nom de l otil ATL Kermeta workbench Tefkat Qelqes détails Développé par OBEO et l INRIA sos licence EPL. Utilisé por la translation sémantiqe et syntaxiqe. En réponse a QVT «reqest for proposal» de L OMG. Emprnte les concepts de MOF, OCL et QVT, mais assi de BasicMTL. Développé par ne éqipe de L IRISA (niversité de Rennes 1), Open sorce, sos licence EPL. Basé sr F-logic et la théorie des programmes logiqes stratifiés. C est n plgin Eclipse por l Eclipse Modelling Framework. Tablea 1.2 Qelqes otils de transformation de langage 1.4 Systèmes temps réel et ordonnancement temps réel L électroniqe embarqée temps réel est largement tilisée et prend ne importance de pls en pls grande dans la vie qotidienne. Plsiers domaines d application sont concernés, notamment, l atomobile, l avioniqe, la téléphonie mobile, le mltimédia, l énergie etc Introdction ax systèmes temps réel Les systèmes temps réel concernent des applications ayant n rôle de sivi o de contrôle de procédés dans n environnement qi évole dynamiqement. L application est réactive, en effet, elle doit réagir a changement d état d n système somis à des contraintes temporelles précises. D où le bon fonctionnement d n système temps réel ne dépend pas selement de l exactitde des résltats d calcl mais assi des dates axqelles ces résltats sont prodits. Certains systèmes sont classés critiqes lorsqe le non respect des contraintes temporelles pet provoqer des conséqences catastrophiqes (perte de vie hmaine, destrction de matériel ). Les systèmes de contrôle de vol, les systèmes de contrôle de centrale ncléaire en sont des exemples.

38 1.4 Systèmes temps réel et ordonnancement temps réel 27 Généralement, n système temps réel est composé d n ensemble de tâches exéctées en concrrence por tiliser le (o les) processer(s) et certaines ressorces partagées. Le pls sovent les exigences temporelles sont reportées sr les échéances d exéction des tâches. Par conséqent, ne validation temporelle consiste à vérifier qe totes les tâches d n système terminent ler exéction avant lers échéances, drant tote la drée de vie d système, et cela en examinant le pire scénario d exéction de tâches. S il existe n moyen de garantir la validation temporelle, alors le système est dit ordonnançable. Le test d ordonnançabilité est dépendant d modèle de tâches qi définit l ensemble des restrictions axqelles doivent se conformer les tâches et de la politiqe d ordonnancement tilisée por déterminer l ordre dans leqel doit être exécté les tâches. Dans les systèmes temps réel, le système électroniqe doit réagir en permanence ax variations d procédé et agir en conséqence sr celi-ci afin d obtenir le comportement o l état sohaité, cette caractéristiqe définit la notion de réactivité d système vis-à-vis d procédé (environnement aqel il est connecté)[20]. Une définition des systèmes réactifs, décrivant le fonctionnement d n système temps réel est donnée dans [21] : Un système réactif est n système qi réagit continûment avec son environnement à n rythme imposé par cet environnement. Il reçoit, par l intermédiaire de capters, des entrées provenant de l environnement, appelées stimli, réagit à tos ces stimli en effectant n certain nombre d opérations et prodit, grâce à des actionners, des sorties tilisables par l environnement, appelées réactions o commandes. R é a c t i o n s ( c o m m a n d e s ) S y s t è m e in f o r m a t i q e ( s y s t è m e c o n t r ô l e r ) A c t i o n n e r s C a p t e r s P r o c é d é ( s y s t è m e c o n t r ô l é ) S t im l i Figre 1.4 Système temps réel De cette définition, n système temps réel est alors composé principalement de dex éléments distincts : ne o plsiers entités physiqes constitent le procédé (le système contrôlé) et n système de contrôle (contrôler) qi est chargé de srveiller de manière réglière l état d procédé en récpérant les valers en provenance des capters. En fonction de l algorithme de contrôle et des valers décrivant l état actel d procédé, le contrôler commande les changements d état, via des actionners. Dans le domaine des commnications radio, le procédé est la sortie attende sr l antenne radio, et le système

39 Chapitre 1 Etat de l art 28 contrôler, n schéma de modlation sr ne carte électroniqe. Notons q n système temps réel est dit embarqé lorsq il est sité à l intérier de l environnement q il doit contrôler, comme n calclater dans ne voitre o n avion. Dans les systèmes temps réel, les données ont ne validité définie à la fois par le domaine de valers admises et par la drée de validité (temporelle) de celles-ci, qi dépend natrellement de l échéance. Les données ont donc ne drée d existence limitée [22]. Les systèmes de contrôle doivent donc respecter dex exigences : fonctionnelles et temporelles en parallèle. Selon les contraintes temporelles, on distinge dex grandes catégories des systèmes temps réel : - Systèmes temps réel drs : Lorsqe totes les contraintes temporelles doivent être impérativement respectées. Le non respect des contraintes pet provoqer des conséqences catastrophiqes [23]. Les systèmes de contrôle de vol, les systèmes de contrôle de station ncléaire, systèmes de contrôle de vois ferrées en sont des exemples. - Système temps réel soples o mo : a contraire des systèmes temps réel drs, le non respect des contraintes temporelles est toléré (acceptable) par le système, et sans qe cela ait des conséqences catastrophiqes. Par exemple les applications mltimédia. D atre part, les systèmes temps réel sont considérablement inflencés par l architectre matérielle sr laqelle doit s exécter le système. Cette architectre matérielle désigne les ressorces physiqes nécessaires a pilotage d procédé : les processers, les cartes d entrées/sorties, les mémoires, les réseax, etc. En fonction d nombre de processers et de l tilisation éventelle d n résea, on distinge trois grandes catégories d architectres [24] : - Architectre monoprocesser : Dans ce type de systèmes, totes les tâches de l application sont exéctées par n niqe processer partagé. - Architectre mltiprocesser : Les fonctions de l application sont réparties sr n processers partageant ne mémoire centrale commne. - Architectre distribée : Les fonctions de l application sont réparties sr n processers, mais a contraire des architectres mltiprocessers, il n y a pas de mémoire centrale partagée. Les processers sont reliés les ns ax atres par l intermédiaire d n résea. Dans la site nos nos intéressons ax systèmes de contrôle temps réel drs implantés dans ne architectre monoprocesser Caractérisation d ne application temps réel La méthode la pls coramment tilisée por mener à bien le dimensionnement d n système temps réel respecte les étapes sivantes [25]: Identifier le modèle de chacne des tâches, Identifier le modèle de contrainte temporelle considéré, Identifier le modèle d ordonnancement, Identifier les scénarios d activations, Etablir les conditions de faisabilité et vérifier sr les scénarios d activations.

40 1.4 Systèmes temps réel et ordonnancement temps réel 29 o Modèle temporel de tâche Un système temps réel se modélise donc par n ensemble fini de tâches τ { τ τ,..., } = 1, 2 τ n. Cet ensemble de tâches décole directement de l objectif de l application, c est à dire de son cahier des charges. Soit τ i ne tâche qelconqe d système, τ i pet être : Périodiqe : lorsqe ses activations sont périodiqes et de période d activation T i. La période d ne tâche est la drée fixe entre dex activations des dex instances sccessives deτ i. On pet ainsi calcler facilement les dates d activation de travers le temps. τ i à Sporadiqe : lorsqe dex activations sccessives de cette tâche sont espacées d ne drée spériere o égale à T i. Apériodiqe : Lorsqe ses activations srviennent à des moments aléatoires. o Modèle de contrainte temporelle L échéance temporelle o encore délai critiqe notée D i, correspond a temps alloé à la tâche por terminer complètement son exéction. Chaqe instance de τ i doit terminer son exéction avant D i nités de temps après la date de son activation. Le dépassement de cette date limite por l exéction prodit ne fate temporelle. Définissons maintenant la drée d exéction a pire cas d ne tâche et son temps de réponse a pire cas. La drée d exéction a pire cas, o WCET (Worst case Exection Time), d ne tâche τ i est notée C i. Cette drée d exéction a pire cas correspond a pire temps d exéction de la tâche τ i sele, c est à dire sans acne préemption de à l ordonnancer o à tote atre tâche. De nombrex travax ont traité le problème d calcl de WCET de façon à ce q il ne soit pas trop srestimé. Notons qe certains systèmes temps réel mo considèrent n temps d exéction moyen o minimal. La problématiqe d estimation de la drée d exéction fait l objet de nombrex travax [26][27][28][29][30]. Le temps de réponse a pire cas R i d ne tâche τ i est la pls longe drée entre ne activation de τ i et la terminaison de l exéction associée. La tâche τ i povant être éventellement interrompe pendant son exéction, a profit de tâches pls prioritaires, son temps de réponse a pire cas dépend des caractéristiqes des atres tâches d système ainsi qe de la politiqe d ordonnancement. Dans tos les cas, nos arons Ri Ci. Une tâche est dite à échéance sr reqête si D i = Ti. Les tâches d n système sont à échéances contraintes lorsqe les échéances sont inférieres o égales ax périodes. Une tâche est bien formée si cette condition 0 p Ci Di Ti est vérifiée. Si la date de la première activation d ne tâche, notée O i, est conne, la tâche est dite concrète. Un je de tâches est dit synchrone si il existe n instant où totes ses tâches sont activées simltanément, nos parlons alors d instant critiqe. Atrement, il sera dit asynchrone.

41 Chapitre 1 Etat de l art 30 o Modèle d ordonnancement Le problème de l ordonnancement consiste à choisir, si tant est q elle existe, ne politiqe d attribtion d processer ax tâches telle q acne fate temporelle ne sera commise drant tote la drée de vie d système. Dex approches pevent être distingées : L ordonnancement en ligne : Un algorithme d ordonnancement est dans le système. Les décisions d ordonnancement sont alors prises pendant la drée de vie d système. L ordonnancement hors ligne : Une séqence valide, définissant l ordre dans leqel les tâches doivent être exéctées, est déterminée avant le déploiement d système. Une fois chargée dans ne table, cette séqence sera tilisée par n séqencer tot a long de la vie d système. Les temps de réponse a pire cas obtens dépendent fortement de la politiqe d ordonnancement. Afin de permettre à n ordonnancer en ligne de déterminer l ordre dans leqel les tâches doivent s exécter, ne soltion très classiqe consiste à attriber ne priorité à chacne d entre elles. Lorsq il est invoqé, l ordonnancer sélectionne alors, selon l algorithme HPF (Highest priority First), la tâche la pls prioritaire. Nos distingons dex types de priorités : Priorité fixe : La priorité de chaqe tâche est fixée lors de la conception d système et demere invariable tot a long de sa vie Priorité dynamiqe : Les priorités des tâches varient a cors de l exéction d système. Les algorithmes d ordonnancement dit dynamiqes attribent les priorités ax tâches en fonction des paramètres temporels dynamiqes comme l échéance la pls proche. L algorithme doit alors recalcler les priorités à chaqe instant de décision. Priorité fixe/priorité dynamiqe : Dans ce cas l ordonnancement est dit mixte, o encore hybride, et tilise les priorités fixe comme premier critère d ordonnancement pis priorité dynamiqe comme second critère. Nos distingons dex modes d exéction des tâches temps réel, en fonction des contraintes de ressorces et de précédence : Non préemptif : L ordonnancer ne pet interrompre l exéction d ne tâche (possédant le processer) en faver d ne atre tâche. Il doit attendre jsq à la terminaison de l exéction de la tâche en cors, avant de débter l exéction de tote atre tâche. Si ne tâche non préemptive est interrompe, son exéction doit être reprise de novea depis le débt. Préemptif : L exéction d ne tâche pet être interrompe par ne atre tâche pls prioritaire (la priorité d ne tâche est définie en fonction des algorithmes d ordonnancement sos-jacents qi seront présentés pls tard dans ce chapitre). Son exéction est reprise ltérierement. Lorsqe totes les tâches de l application sont préemptives, l ordonnancement est alors dit préemptif. Dans ce cas dès q ne tâche pls prioritaire qe la tâche en cors d exéction est activée, celle-ci se voit alors attriber le processer a détriment de la tâche moins prioritaire.

42 1.4 Systèmes temps réel et ordonnancement temps réel 31 Un algorithme d ordonnancement est dit optimal par rapport à ne classe de problème d ordonnancement s il trove tojors ne soltion à n problème de cette classe lorsq il en existe ne. Ainsi, si l algorithme d ordonnancement optimal por ne classe donnée ne trove pas de soltion à n problème de cette classe alors celi-ci ne pet être résol Concepts et propriétés Dans la site de cette analyse temps réel, le temps sera, le pls sovent, considéré comme discret : totes les dates ainsi qe les paramètres des tâches seront entiers et exprimés dans la même nité. L article [31] montre l intérêt de ce choix selon les faits sivants : La plpart des ordonnancers tilisent ne horloge comme référence temporelle. Si tos les paramètres temporels sont entiers et exprimés dans la même nité, alors il existe n ordonnancement valide en temps discret si, et selement si, il en existe n en temps contin. Nos donnons qelqes propriétés tilisées dans l analyse d ordonnançabilité des systèmes. Une séqence d ordonnancement des tâches d n système est valide si, et selement si, totes les échéances sont respectées. Un système de tâches S est ordonnançable si, et selement si, il existe ne séqence d ordonnancement valide. Soit A n algorithme, et S n système de tâches temps réel. S est correctement ordonnancé par A si, et selement si, la séqence prodite par A est valide. Un test d ordonnançabilité est n algorithme qi, por n système S et n algorithme d ordonnancement A donné, renvoie ne réponse négative si l algorithme A pet générer ne séqence non valide. Cette thèse traite le problème d analyse d ordonnançabilité. Etant donné n système de tâches S, et n algorithme d ordonnancement A (priorités fixes o dynamiqes). Un problème de décision est posé : L algorithme A ordonnance t-il correctement le système S? La réponse est sos la forme d n test a priori d ordonnançabilité. Cela nécessite ne connaissance complète des contraintes temporelles d système, pls l algorithme d attribtion des priorités choisi. La validation d n système temps réel revient à montrer qe chacne de ses tâches respectera totes ses échéances temporelles tot a long de la vie ddit système. La validation s effecte hors-ligne, soit par simlation d système de tâches drant ne drée sffisante, appelée drée de simlation [32], soit à l aide de conditions d ordonnançabilité analytiqes basées sr les critères temporels des tâches Les techniqes d analyse On distinge trois principales techniqes d analyse - L analyse de l tilisation d processer (Processor Utilization Analysis) :

43 Chapitre 1 Etat de l art 32 Le facter d tilisation est le porcentage de temps qe le processer passe à exécter l ensemble des tâches d système. Il se définit par = n Ci U. Dans certains i= 1Ti cas particliers le facter d tilisation d processer permet de conclre si ne configration de tâches est ordonnançable o non. L analyse de la demande processer (Processor Demand Analysis) : Cette techniqe repose sr le calcl de la demande cmlée des exéctions des tâches réveillées et terminées dans n intervalle de temps (Demand Bond Fnction). Cette approche générale permet de constrire des tests d ordonnançabilité en limitant l étde d ordonnançabilité à qelqes intervalles d ne période d activité d processer [33][34]. L analyse des temps de réponse (Response Time Analysis) : Cette techniqe consiste à calcler les pires temps de réponse des tâches et à les comparer avec lers délais critiqes. Une tâche est ordonnançable si, et selement si, son pire temps de réponse est inférier o égal à son délai critiqe. Notons qe les techniqes de l tilisation d processer et de l analyse d temps de réponse seront tilisées dans cette thèse. Nos présentons dans les paragraphes sivants qelqes résltats d analyse d ordonnançabilité basés sr l étde d facter d tilisation processer Algorithmes d ordonnancement à priorité fixe Por les algorithmes d ordonnancement à priorités fixes, la priorité des tâches est calclée en phase de conception d système et reste la même pendant tote la drée de vie d système. Dans le cadre de ces algorithmes, on trove plsiers conditions d ordonnançabilité basées sr l instant critiqe. Un instant critiqe d ne tâche correspond à ne date d activation de la tâche prodisant le pire temps de réponse de la tâche parmi totes les occrrences d activations de la tâche. Por des tâches à échéances sr reqêtes et indépendantes, Li et Layland [35] ont montré qe l instant critiqe por ne tâche a lie lorsq elle est activée en même temps qe totes les tâches pls prioritaires q elle. o Rate Monotonic (RM) L algorithme de Rate Monotonic [35] a été présenté par Li et Layland en A travers cet algorithme, chaqe tâche se verra attriber ne priorité inversement proportionnelle à sa période. Ainsi la tâche la pls prioritaire correspondra à la tâche qi ara la pls petite période. En cas d égalité de priorités por plsiers tâches, le choix de la tâche à exécter sera arbitraire. Théorème 1.1 [35] L algorithme RM est optimal, dans la classe des algorithmes à priorités fixes, por des systèmes de tâches indépendantes, synchrones, et périodiqes à échéances sr reqête.

44 1.4 Systèmes temps réel et ordonnancement temps réel 33 Théorème 1.2 [35] Un système S composé de n tâches périodiqes à échéance sr reqête et indépendantes est ordonnançable par RM si : 1 n Ci U = n(2 n 1) i= 1Ti Le dexième membre de l inégalité tend vers ln 2 (=0,69) lorsqe n tend vers l infini. o Deadline Monotonic (DM) L algorithme DM a été proposé par Leng et Whitehead [36] (appelé assi inverse de l échéance temporelle), elle attribe les priorités ax tâches inversement proportionnelle à lers délais critiqes. La tâche la pls prioritaire est celle possédant le délai critiqe le pls cort. En cas d égalité de priorités, le choix de la tâche à exécter est fait arbitrairement. Théorème 1.3 [36] L algorithme DM est optimal, dans la classe des algorithmes à priorités fixes por les systèmes de tâches indépendantes, synchrones et à échéances inférieres ax périodes ( Di Ti ). Lorsqe les tâches sont à échéances sr reqêtes ( D i = Ti ), on se ramène a même ordre de priorité prodit par l algorithme RM. Théorème 1.4 [36] Un système S composé de n tâches périodiqes à échéance sr reqête et indépendantes est ordonnançable par DM si : 1 n Ci U = n(2 n 1). i= 1Di o L algorithme d Adsley Acn des dex algorithmes présentés précédemment n est optimal en général parmi les algorithmes à priorités fixes. En effet, en contexte préemptif, l algorithme RM n est optimal qe por les ensembles de tâches synchrones à échéances sr reqête. De même, la condition Di Ti doit être vérifiée por qe l algorithme DM soit optimal. L algorithme proposé par N. C. Adsley [37] comble cette lacne et apporte tojors ne soltion valide d attribtion de priorité, si tant est q il en existe ne, sr n ensemble de tâches indépendantes et asynchrones. Le psedo code de l algorithme d Adsley est donné cidesss.

45 Chapitre 1 Etat de l art 34 Optimal priority Assignment Algorithm for each priority level i, lowest first fond = false for each nassigned task τ if τ is schedlable at priority I fond = tre assign τ to priority I break (contine oter loop) end if end for if not fond retrn nschedlable end for retrn schedlable Algorithmes d ordonnancement à priorité dynamiqes Ils déterminent la priorité des tâches pendant l exéction d système. o Earliest Deadline First (EDF) Parmi les algorithmes à priorités dynamiqes, EDF est vraisemblablement le pls poplaire. Cet algorithme repose sr le principe q à chacne de ses invocations l ordonnancer élit la tâche dont l échéance est la pls proche. Théorème 1.5 [38][39] L algorithme EDF est optimal por l ordonnancement des tâches périodiqes o sporadiqes en contexte préemptif ainsi q en contexte non préemptif non concret. Cette optimalité n est pls vraie en contexte non préemptif concret. Por les tâches synchrones à échéances sr reqête, l algorithme EDF présente l avantage de posséder ne condition nécessaire et sffisante d ordonnançabilité simple à mettre en œvre. Théorème 1.6 [35] Un système S composé de n tâches synchrones à échéances sr reqêtes est ordonnançable par EDF si, et selement si : n Ci U = 1 i= 1Ti

46 1.4 Systèmes temps réel et ordonnancement temps réel Ordonnancement des tâches dépendantes L étde de l ordonnancement qi a été présentée dans la section précédente sppose n système monoprocesser assez restrictif. Totes les tâches sont indépendantes (sans acne relation de précédence entre elles) et acn partage de ressorces n est considéré. Nos présentons brièvement dans les sos-sections qi sivent les extensions apportées à l étde d ordonnancement des modèles de tâche, en prenant en compte pls de contraintes. o Contraintes de précédence La majorité des systèmes temps réel nécessitent des commnications entre les tâches. Une tâche (réceptrice) en cors d exéction, à n point de commnication, est mise en attente d ne condition (message) jsq à la satisfaction de la condition (arrivée d message). Ainsi l exéction de la tâche réceptrice doit être précédée par l exéction de la tâche émettrice, ce qi introdit des contraintes de précédence entre les tâches. o Ressorces partagées Il est indispensable d intégrer le partage de ressorces ax algorithmes d ordonnancement car rares sont les applications temps réel qi n tilisent pas de ressorces critiqes. Chaqe ressorce possède ne capacité d entrée, cette capacité représente le nombre d accès simltané permis (accepté) par la ressorce. On dit q ne ressorce est critiqe lorsq elle n accepte q n sel accès à la fois. Une présentation détaillée des ressorces critiqes et des sémaphores est fornie dans [42]. Mok [41] a montré qe le problème de l ordonnancement en présence de ressorces est NP-difficile a sens fort. De pls, dex phénomènes pevent se prodire lors de l ordonnancement d n système de tâches avec partage de ressorce : - L interblocage Ce phénomène se prodit lorsqe dex o plsiers tâches sont bloqées car chacne a demandé l accès à ne ressorce en possession de l atre. Spposons par exemple dex tâches τ1et τ 2 en partage de dex ressorces en accès exclsif R1 et R2. Un interblocage srvient lorsqe τ 1 possède R1 et τ 2 possède R2 et qe τ1et τ 2 ont à ler tor besoin de R2 et R1 respectivement. - Inversion de priorité non borné Ce phénomène srvient lorsq ne tâche, pls prioritaire, est bloqée par l exéction des tâches moins prioritaires alors q elle ne partage pas de ressorce, avec certaines des tâches moins prioritaires. Une tâche τ 1 de priorité spériere, est bloqée en attente d ne ressorce en possession d ne tâche moins prioritaireτ 2, cette dernière ( τ 2 ) pet être préemptée par totes tâchesτ j, de priorité intermédiaire (entre celle de τ 1 etτ 2 ), et qi n est en conflit, ni avecτ 1, ni avecτ 2. Cette préemption de l exéction de τ 2 prodit n blocage non borné porτ 1. Ce phénomène d inversion de priorité doit être pris en considération lors de la conception afin de mener ne bonne analyse d ordonnançabilité. Les phénomènes d interblocage et d inversion de priorité sont représentés à la Figre 1.5.

47 Chapitre 1 Etat de l art 36 Exéction sans resorce τ 1 τ 2 Exéction avec resorce R 2 R 1 Demande de R2 R 2 (a): Interblocage Demande de R1 Demande de R τ 1 τ j τ 2 R Inversion de priorité non borné R R (b): Inversion de priorité non borné Figre Interblocage et inversion de priorité non bornée Dans le bt d empêcher o de borner l inversion de priorité, plsiers protocoles de gestion de ressorces ont été proposés dans la littératre. Protocole d héritage de priorité Le PPH (Priority Inheritance Protocol) [43] a été proposé por palier le problème d inversion de priorité non bornée. L idée simple consiste à interdire tote préemption, de la tâche possédant ne ressorce, demandée par les tâches pls prioritaires (tâches bloqées), par tote tâche de priorité intermédiaire. Por cela on affecte, à la tâche bloqante, la pls grande priorité parmi les priorités de totes les tâches q elle bloqe (on dit q elle hérite d ne priorité). Lorsqe la tâche bloqante libère ne ressorce, sa priorité est recalclée en fonction des ressorces qi sont tojors en sa possession. Elle reprend sa priorité initiale lorsq elle libère totes les ressorces. Notons qe l héritage de priorité est transitif, tel qe si ne tâche τ k bloqe ne tâche τ j qi elle même bloqe ne atre tâcheτ i, alors la tâche τ k hérite de la priorité de τ i par l intermédiaire deτ j. On parle dans ce cas de blocage transitif. Une tâche ne pet être bloqée à l entrée d ne section critiqe q ne fois par ressorce existante. Ainsi le temps de blocage est la somme des pls longes sections critiqes sr chaqe ressorce. Théorème 1.7 [43] En tilisant le protocole à priorités héritées, ne tâche τ i d n système S ne pet être bloqée qe pendant n temps égal à : max {drée d tilisation de R parτ j }. R, ressorce j i

48 1.4 Systèmes temps réel et ordonnancement temps réel 37 Avec cette méthode, le temps de blocage est élevé si plsiers tâches partagent ne même ressorce. Il ne pet être calclé qe si les tâches possèdent des priorités fixes. Ainsi, ce protocole n est tilisable q avec des algorithmes d ordonnancement à priorités fixes. Notons enfin qe l tilisation de PPH ne résot pas le problème d interblocage. Protocole de priorité de plafond Le PPP (Protocole de Priorité de Plafond) a été présenté, dans les travax de Sha et al [43], afin de résodre les limitations de PPH. Le principe consiste à affecter à chaqe ressorce ne priorité plafond (seil), qi est la pls forte des tâches qi y accèdent. Le mécanisme d protocole est le sivant : Lorsq ne tâche accède à la ressorce, la priorité de la tâche se voit agmentée à la priorité de plafond associée à la ressorce en qestion. La priorité de plafond étant spériere o égale à la priorité maximale relevée sr l ensemble des tâches tilisant la ressorce. Après modification de sa priorité la tâche corante ne pet en acn cas être préemptée par ne tâche demandant l accès à cette même ressorce qi se trove ainsi correctement protégée. Cependant certaines tâches qi n emploient pas la ressorce pevent avoir ne priorité strictement spériere à sa priorité de plafond et préempter la tâche corante. Lorsq ne tâche libère la ressorce, la priorité de la tâche corante est ramenée à sa valer antériere. Une fois le changement effecté ne tâche pet être éventellement éle. Notons qe ce protocole est destiné ax algorithmes d ordonnancement à priorités fixes. Cependant il a été étend dans [45] por l tiliser avec EDF. Le protocole résltant est nommé protocole à priorité de plafond dynamiqe. Le PPP permet d empêcher tot interblocage et garantit q ne tâche ne pisse être retardée qe par, a pls, ne tâche moins prioritaire. Le lecter pet se référer à l annexe A, por avoir des informations complémentaires. Le modèle de tâches étdié dans le cadre de cette thèse se rapporte à la catégorie des tâches mlti-trames c est porqoi nos nos y intéressons particlièrement dans cet état de l art Analyse de l ordonnançabilité des tâches mlti-trames Le modèle de tâches périodiqes proposé par Li et Layland [35] sppose la prise en compte niqement d pire temps d exéction de chaqe tâche. Cette sitation est acceptable dans la modélisation de nombreses applications temps réel. Cependant, lorsqe le temps d exéction moyen d ne tâche est très faible devant le pire temps d exéction, cette considération devient très pessimiste. En fait la prise en compte d pire temps d exéction condit à ne srestimation de la charge d processer, ce qi rédit le tax d acceptation (validation) des systèmes. Por calcler le tax d tilisation réel des ressorces d système, d atres modèles de tâches ont été proposés. C est le cas d modèle mlti-trames (mltiframe - MF) introdit par Mok et Chen [60]. Ce modèle prend en compte des temps d exéction d ne tâche variables d ne instance à l atre. Le modèle mlti-trames tilise alors la liste des temps d exéction por établir les conditions

49 Chapitre 1 Etat de l art 38 d ordonnançabilité. La liste des temps d exéction se répétant périodiqement sivant n motif d activation. Le type d applications concrètes dans lesqelles on retrove ce genre de tâches est la transmission de trames vidéo codées MPEG [61]. Dans le codage standard MPEG (Moving Pictre Experts Grop), il y a trois types de trames vidéo : les I-frame, les P- frames et les B-frames. Les I-frames tilisent n encodage intra-frame. Les P-frames et B- frames tilisent n encodage inter-frame. Les trames sont encodées en fonction de données précédentes, corantes o sivantes. Totes les transmissions de trames présentent alors n motif fixe comme celi-ci : «IBBPBBPBBIBBP..». Le motif de l envoi des trames est périodiqe et chaqe période débte par l envoi d ne trame I. Présentation d modèle Une tâche mlti-trames est définie par n cople ( Γ i, Ti ) où Γ i est n tablea de N i 0 2 N 1 ( N i 1) trames avec temps d exéction ( C,,..., i i Ci Ci ) et T i est le temps minimm de séparation entre dex trames sccessives. Chaqe trame doit terminer son exéction avant son délai critiqe D i = Ti. Analyse basée sr la densité por des tâches à priorités fixes Soit τ i ne tâche mlti-trame composée de Ni trames, avec des temps d exéction 0 2 N 1 ( C,,..., i i Ci Ci ) respectivement. On dit qe τ i est accmlativement monotoniqe m+ l j+ l k k (AM) si m ( 0 : Ni 1) tel qe l, j (0 : Ni 1), Ci Ci. On appelle la trame m, k= m k= j la trame de pointe deτ i. m Notons qe la trame de pointe m est la trame ayant la pls grande drée d exéction C i dans Γ i. Une tâche AM est ne tâche por laqelle la pls grande qantité de temps d exéction totale de n importe qelle séqence de l ( l 1) trames correspond à celle dans laqelle la première trame est la trame de pointe. Spposons qe totes les tâches soient AM. Un instant critiqe prodisant le pire scénario d exéction d ne tâche srvient lorsqe sa trame de pointe s active simltanément avec totes les trames de pointe de totes les tâches pls prioritaires. Une borne d tilisation meillere qe celle de Li et Layland a été fornie dans [60]. Por ne tâcheτ i, définissons m Ci r i = si N m+1 i 2, m est la trame de pointe. Ci r i = 1 si N i = 1 Por n système S de n tâches, définissons r = min ri 1 i n Théorème 1.8 [60] Por n système S de n tâches mlti-trames, S est ordonnançable si le facter j max C n i 1 0 j Ni 1 r + 1 d tilisation ( U = ) est inférier à r * n*(( ) n 1). i= 1 Ti r

50 1.4 Systèmes temps réel et ordonnancement temps réel 39 Analyse basée sr le temps de réponse por les tâches à priorités fixes Dans [62], Barah et al ont proposé n test sffisant d ordonnançabilité par analyse approchée d temps de réponse. L idée consiste à tiliser ne fonction qi détermine la demande d exéction cmlative d ne tâche por n importe qelle séqence de k instances sccessives. Por 0 k N i 1, nos avons : j+ Ni 1 = l mod n g( τ i, k) max Ci 0 j Ni 1 l= j Cette fonction fornit l interférence maximm de k exéctions sccessives d ne tâcheτ i. Afin de calcler l interférence en fonction de la longer de l intervalle de temps t, nos devons déterminer le nombre d instances povant être activées dans t. t G( τ i, t) = g( τ i, ) Ti Appelons la trame de pointe d ne tâche τ i la trame possédant la pls grande drée d exéction. Une tâche τ i respectera tojors son échéance si sa trame de pointe respecte son échéance (théorème 1 dans [62]) car les trames d ne tâche ont la même échéance temporelle et sont à échéance sr reqête. La tâche τ i est alors ordonnançable si le pire temps de réponse de la trame de pointe est inférier à son échéance temporelle. La borne d temps de réponse est obtene par la méthode d calcl de temps de réponse de Joseph et Pandya [48]. 0 Ri = g( τ i,1) k k 1 Ri = g( τ i,1) + G( τ i, Ri ) τ hp( τ ) i Un instant critiqe por ne tâche analysée τ i srvient lorsqe sa trame de pointe s active simltanément avec ne trame de chacne des tâches pls prioritaires [63]. Por ne analyse exacte d pire temps de réponse, on doit considérer tos les instants candidats à prodire le pire temps de réponse en combinant totes les trames des tâches pls prioritaires. La complexité de l algorithme est exponentielle. Une rédction d nombre d instants critiqes qi doivent être examinés est possible en détectant tot instant qi ne porra jamais prodire le pire temps de réponse de la tâche analysée. Ces instants critiqes coïncident avec l activation des trames qi dominent d atres trames [63][64]. Dans [64], les aters ont étend l analyse d pire temps de réponse en intégrant les giges, pis en considérant le cas où l échéance temporelle d ne tâche est spériere à sa période. Dans le modèle mlti-trames, chaqe tâche possède ne période et ne échéance niqe por totes ses trames. Ces restrictions vont être levées dans le modèle mlti-trame généralisé Analyse de l ordonnançabilité des tâches mlti-trames généralisées Le modèle mlti-trames généralisées (Generalized mltiframe - GMF) [65] est ne extension d modèle mlti-trames dans les directions sivantes : i

51 Chapitre 1 Etat de l art 40 L échéance d ne trame pet être différente de son temps de garde ; les trames différentes pevent avoir des échéances différentes, Les trames différentes pevent avoir des temps de gardes différents. Une tâche GMF τ i est composée de N i trames. Chaqe trame est caractérisée par n temps d exéction j j j C i, ne échéance Di et n temps de garde T i entre son arrivée et l arrivée de la trame sivante, por j tel qe 0 j Ni 1. Avant d aborder les différentes approches d analyse des tâches GMF (avec priorité fixe et priorité dynamiqe), nos citons qelqes propriétés qi ont été définies dans la littératre : ne tâche satisfait la propriété L-MAD (localized monotonic Absolte Deadline) si l échéance de chaqe trame srvient avant l échéance de la trame sivante [65], c est j j ( j +1) mod N à dire por tot j ( 0 j Ni 1) Di Ti + Di, ne tâche satisfait la propriété FS (Frame Separation) si l échéance de chaqe trame srvient avant le réveil de la trame sivante [66], c est à dire por tot j j j ( 0 j Ni 1) Di Ti. Il est évident qe tote tâche satisfaisant la propriété FS satisfait la propriété L-MAD. Analyse d temps de réponse des tâches GMF à priorités fixes Cette analyse est faite sos l hypothèse qe les tâches GMF satisfont la propriété FS. Soit W ik (t) la fonction qi détermine la charge totale casée par ne tâche τ i dans n eme intervalle de temps t lorsq elle débte par la k trame. k + j 1 h mod N k+ j 1 i h mod N i W ik ( t) = Ci où j = min j : T i t. h= k h= k Afin d étdier l ordonnançabilité d ne tâche GMF, il est nécessaire de tester l ordonnançabilité de totes ses trames, por tos les instants critiqes candidats. Un instant critiqe candidat por ne trame d ne tâche se prodit lorsqe la trame s active simltanément avec ne trame de tote tâche pls prioritaire. Comme por les transactions l analyse exacte (condition nécessaire et sffisante) d temps de réponse a ne complexité exponentielle car on doit examiner totes les combinaisons possibles entre les trames. Une analyse avec ne complexité psedo-polynomiale est possible mais elle fornit ne condition sffisante d ordonnançabilité en calclant n temps de réponse approché por chaqe trame. Cette analyse consiste à étdier l interférence maximm q ne tâche GMF pet imposer sr le temps de réponse d ne tâche moins prioritaire. La fonction d interférence (MIF) [66] représente l interférence maximm de l intervalle de temps t, en considérant qe chaqe trame débte l intervalle t : M i ( t) = max Wik ( t) 0 k N 1 La borne d temps de réponse d ne trame j d ne tâche τ i est donnée par : (0) j Rij = Ci i ( k) j ( k 1) Rij = Ci + Mi ( Rij ) i hp ( ) τ i τ i dans Cette analyse a été améliorée en remplaçant la fonction d interférence W ik (t), par ne ' novelle W ik ( t) [66], qi détermine l interférence imposée effectivement par chacne des

52 1.5 Conclsion et problématiqes 41 tâches pls prioritaires. Cette fonction est éqivalente à celle d interférence effective proposée por les transactions : k = + j k+ j 1 ' h mod Ni ( h+ j) mod Ni h mod Ni Wik ( t) Ci + min Ci, t Ti h= k h= k Analyse de la demande processer des tâches GMF à priorités dynamiqes Considérons qe totes les tâches GMF satisfont la propriété L-MAD et sont ordonnancées par l algorithme à priorités dynamiqes EDF. Un test por analyser la demande processer consiste à vérifier por tot intervalle de temps qe la charge d processer prodite est tojors infériere o égale à la longer de l intervalle. Ce test est limité par la pls longe période d activité [31] et pls précisément par les dates d échéances srvenant dans la pls longe période d activité. Soit dbf ( τ i, t) (Demand-Bond Fnction) la fonction déterminant le temps processer maximm reqis par les instances de la tâche τ i activées dans l intervalle [0,t) et dont les échéances sont elles assi dans cet intervalle. Barah et al [65] donnent n algorithme «Bild list» calclant la demande processer drant la première période (somme des temps de garde des N i trames) de chaqe tâche GMF d système S. Cet algorithme enregistre la demande processer sos forme de coples (date d échéance, demande processer). La liste des coples sera tilisée facilement por trover la demande processer maximm dans n importe qel intervalle de temps t (algorithme Comptedbf(t) [65] ). En exploitant la périodicité de la fonction de la demande maximm dbf ( τ i, t), ne transformation de système S à n ensemble de tâches sporadiqes (système S ) modélisant cette fonction est possible. Le système S est ordonnançable sr ne architectre monoprocesser, si et selement si, le système S des tâches sporadiqes correspondant est ordonnançable (théorème 2 dans [65]) Otils de vérification d ordonnancement temps réel Plsiers otils de vérification d ordonnancement temps réel ont été développés afin d atomatiser les différentes techniqes d analyse présentées dans la littératre. Nos povons citer : Cheddar [67] : développé à l niversité de Brest, MAST [68] : développé à l niversité de Cantabria, Rapid RMA [69]: développé par la société Tri pacific software. 1.5 Conclsion et problématiqes Dans ce premier chapitre nos avons présenté dans n premier temps la strctre hétérogène et distribée d ne radio logicielle, ainsi qe certaines recommandations d SCA.

53 Chapitre 1 Etat de l art 42 Dans n dexième temps, nos avons présenté les différentes méthodologies et langages dont dispose le concepter afin de spécifier son système. Dans le domaine de la radio logicielle, l tilisation de méthodologies de conception à hat-nivea d abstraction s avère ajord hi indispensable compte ten de la complexité grandissante d n modem radio. En effet le besoin de spporter plsiers standards radios sr n même poste, entraîne n grand nombre de composants logiciels de la coche physiqe à s exécter simltanément sr n même processer. Cependant ces composants logiciels qi correspondent ax traitements en bande de base ont ne notion dale d exactitde : exactitde logiqe et exactitde temporelle. Or les méthodologies présentées dans ce chapitre sont soit très génériqes, soit adaptées à ne conception de composants de traitements en bande de base por ne architectre matérielle de type FPGA. La qestion se pose alors de savoir qelle méthodologie de conception adopter por la vérification temps réel de composants logiciels de traitements d signal s exéctant simltanément sr n processer donné? Comment calcler pis exprimer les contraintes temporelles lors de la modélisation des applications de traitement d signal avec le novea profil por n système temps réel embarqé (MARTE), de manière à ce qe ces contraintes pissent être exploitées par n otil d analyse d ordonnançabilité temps réel? Dans n troisième temps, nos avons présenté dans ce chapitre les différents modèles de tâches ainsi qe les différentes techniqes d analyse permettant la validation de l ordonnançabilité temps réel de ces tâches. Le modèle de tâche mlti-trames généralisé se rapproche le pls d modèle de tâche rencontré dans les applications de traitement de signal réalisées à ce jor car il atorise le temps d exéction, l échéance temporelle et le temps de garde d ne tâche à varier d ne activation à l atre en fonction d n pattern d activation spécifiqe. Cependant por les applications logicielles de traitement d signal dans les postes radio, on ne pet pas considérer n pattern spécifiqe d activation car le système est dirigé par des évènements venant d tilisaters. Par exemple si ne tâche logicielle a dex temps d exéctions et dex échéances temporelles parce q elle traite dex types de trames différentes (représentant dex services différents), on ne pet pas prédire pendant la phase de conception n ordre d arrivée fixe des trames qi se répétera drant tote la drée de vie d système. Dans ce contexte, où il n y a pas de motif spécifiqe d activation, comment vérifier qe l ensemble de tâches logicielles s exéctant sr n processer donné respecteront lers échéances temporelles? Pis, se pose assi la qestion de savoir qelle politiqe d ordonnancement et qel otil de vérification temps réel seront adaptés por les composants logiciels mettant en œvre les traitements en bande de base d n schéma de modlation de type OFDM (Orthogonal Freqency Division Mltiplexing) par exemple? Nos répondrons à ces qestions dans les chapitres sivants.

54 Chapitre 2 Contribtions : Ordonnancement temps réel Résmé : Le modèle de tâche mlti-trame généralisé (GMF) a été proposé afin de modéliser ne tâche dont le temps d exéction, l échéance et le temps de garde changent en fonction d n motif spécifiqe d activation. Dans ce chapitre nos relâchons l hypothèse consistant à prendre en compte n motif spécifiqe d activation, ce qi nos condit a modèle de tâche GMF non cycliqe. Dans ce contexte, les techniqes d analyse d ordonnancement por le modèle de tâche GMF ne pevent pas être appliqées. Ce chapitre présente ne novelle formle por le calcl d temps de réponse d ne tâche GMF non cycliqe s exéctant sr n monoprocesser sivant la politiqe d ordonnancement EDF. Assi, n novea test d ordonnançabilité basé sr la densité est donné. En dernière partie, nos présentons ne novelle approche efficace, permettant la détermination exacte de la faisabilité temps réel d n ensemble de tâche GMF non cycliqe, par simlation. 2.1 Introdction La plpart des étdes sr les algorithmes de vérification d ordonnancement temps réel ont relâché les hypothèses d modèle de tâche classiqe de Li et Layland [35]. Mok et Chen [60] sont les premiers à introdire le concept de mlti-trames (mltiframe). Une tâche mlti-trames est ne tâche dont le temps d exéction change périodiqement en fonction d n motif spécifiqe. Par exemple ne tâche avec n temps d exéction de 5 ms et de 8 ms, est considérée comme ayant dex trames et ces dex temps d exéction changent à chaqe activation en fonction d n motif spécifiqe. Le modèle de tâche mltitrames généralisé (GMF) est ne extension d modèle mlti-trames dans les trois directions sivantes : (1) L échéance d ne trame pet être différente de sa période, (la période est désormais considérée comme n temps de garde) (2) les trames différentes pevent avoir des échéances différentes, (3) les trames différentes pevent avoir des temps de garde différents. Le temps de garde est défini comme étant le temps minimm qi doit s écoler entre dex activations sccessives d ne même tâche. Nos introdisons dans cette thèse n novea modèle de tâches aqel se rapporte notre contexte de radio logicielle : le modèle de tâche GMF non cycliqe. La principale 43

55 Chapitre 2 Contribtions : Ordonnancement temps réel 44 différence entre le modèle de tâche GMF et celi non cycliqe vient d fait q il n y a pas de motif spécifiqe d activation de la tâche. En d atres mots, dans le modèle GMF non cycliqe il est possible d activer n importe qelle trame à la fin d temps de garde de la trame précédente. Le terme «non cycliqe» est tilisé por mettre en évidence le fait qe le motif d activation qi crée le cycle n est pas spécifié. La Figre 2.1 représente ne séqence d exéction des dex modèles de tâches, por celi d en hat, il s agit d ne tâche GMF τ i ((1,4,4),(2,5,6),(3,6,7)) constité de 3 trames. Le temps d exéction de la 2 ème trame est 2, son échéance relative est 5, et son temps de garde est 6. Atrement dit, lorsqe la 2 ème trame est activée, la trame sivante, qi est nécessairement la trame avec por temps d exéction 3, est activée après a moins 6 nités de temps. Nos choisissons de représenter le motif d activation par n vecter composé de la site des temps d exéction des trames. De manière évidente nos observons qe la tâche GMF τ i, d hat de la Figre 2.1, a n motif égal à [1 ;2 ;3]. Et ce motif se répète dans n cycle de 17 nités de temps. En revanche, le scénario d en bas de la Figre 2.1 représente ne séqence d exéction possible de la même tâche sans considérer le motif d activation (tâche GMF non cycliqe). La différence est qe la site des trames ne sit pas n motif spécifiqe. En fait, chacne des trois trames pet être activée à la fin d temps de garde de la trame précédente. 1 P i 1 D i 2 P i 2 D i cycle 3 P i 3 D i GMF task i cycle 1 C i 2 C i 3 C i non-cyclic GMF task i (a possible seqence of frames arrival) 1 P i 1 D i 2 P i 2 D i 3 P i 3 D i 1 2 Ci C i C i Figre 2.1 Comparaison entre ne tâche GMF et ne tâche GMF non cycliqe Barah et al [65] ont défini la propriété L-MAD (définie formellement dans le chapitre précédent). Ils ont proposé n algorithme basé sr la densité déterminant l ordonnançabilité d n ensemble de tâches GMF ordonnancées avec la politiqe EDF. Cet algorithme a ne complexité polynomiale.

56 2.1 Introdction 45 La méthodologie consiste à déterminer la demande processer (dbf Demand Bond Fnction) por chaqe tâche et vérifier q il n existe pas n intervalle de temps t tel qe dbf (τ i, t) f t. i Pisq il n existe pas de motif d activation qi se répète, l algorithme proposé dans [65] por calcler la demande processer ne pet pas être appliqé. Dans l optiqe de prendre en compte la relation de décalage entre les tâches, les aters dans [71], ont proposé le modèle de tâches avec décalage (o transactions). L analyse par le calcl d temps de réponse por les transactions ordonnancées avec EDF a été proposée par Palencia et Harbor dans [72], sivi par Pellizzoni et Lipari dans [73]. Traoré et al [74] ont mentionné dans ler article qe le modèle mlti-trame est n cas particlier d modèle avec décalage, ainsi ils considèrent qe l analyse por les tâches avec décalages pet s appliqer a modèle mlti-trames. Pls récemment Rahni a montré dans [51], comment transformer ne tâche GMF en transaction. Sivant cette approche, la transformation d ne tâche GMF non cycliqe en ne transaction, donne ne transaction avec des périodes différentes. Ainsi la période de la transaction change d n événement à l atre sans qe nos ne sachions dans qel ordre, v q il n y a pas de motif qi se répète. Il est donc clair qe l analyse par le calcl d temps de réponse proposé por les transactions ordonnancées avec EDF ne pet pas être appliqée a modèle de tâche GMF non cycliqe. Un exemple de modèle de tâche GMF non cycliqe, réglièrement rencontré dans les modems radio indstriels, consiste en la version mlti-tilisater d n schéma de modlation OFDM (Orthogonal Freqency Division Mltiplexing). Le modem radio pet servir plsiers tilisaters à travers la gestion de trames de tailles différentes. Les trames vidéo nécessitent habitellement pls de temps de traitement qe les trames adio, et les trames adio ont ne latence pls faible qe celle des trames vidéo. Ceci impliqe por les tâches de l application, n temps d exéction, ne échéance temporelle et n temps de garde qi varient en fonction d type de trame en cors de traitement. Evidemment on ne pet pas préspposer n motif d arrivée des trames car le système est dirigé par des événements venant d tilisaters (l tilisater A effecte n appel adio pendant qe l tilisater B regarde ne vidéo en diffsion). La Figre 2.2 représente n modem radio typiqe. Il est composé de 3 processers, et nos nos intéressons à l ordonnancement temps réel sr n processer d intérêt qi exécte ne sos-partie des traitements d modem. L application contient ne chaîne de transmission, ne chaîne de réception et ne chaîne por contrôler la radio. Chaqe chaîne est constitée d algorithmes de traitement d signal. Les flèches entre les fonctions représentent le flx de données. Typiqement, G est n algorithme de démodlation por leqel le temps d exéction est proportionnel à la taille de la trame, alors qe I est n algorithme de décodage flexible por leqel les différents temps d exéction sont ds ax différents paramètres por les trames adio et vidéo. Sans perte de généralité, nos choisissons de «mapper» chaqe algorithme sr ne tâche, ce qi nos condit a modèle GMF non cycliqe.

57 Chapitre 2 Contribtions : Ordonnancement temps réel 46 Ce chapitre fornit les contribtions sivantes : La formle por le calcl d temps de réponse d ne tâche GMF non cycliqe ordonnancée avec EDF. Pis n test d ordonnançabilité sffisant basé sr la densité avec ne complexité polynomiale. Une approche efficace, por la détermination exacte de la faisabilité temps réel, en tilisant la simlation. Processor1 Processor of interest Processor2 User A User B sink I Data Receive J G H sorce User A User B User A sorce Data Transmit C D F sink User A User B E User B sorce Radio Control A B sink Figre 2.2 Un modem radio typiqe Le reste de ce chapitre est organisé comme sit. La section sivante rappelle nos notations. La section 2.3 expliqe comment nos trovons la formle por le temps de réponse et présente le test de faisabilité sffisant. Une approche efficace por la détermination exacte de la faisabilité temps réel est présentée à la section 2.4. Les conclsions sont fornies en section Rappel sr les notations L analyse dans ce chapitre considère n système composé de m tâches indépendantes GMF non cycliqes avec ne drée d activité qe nos appelons «non-stop-rntime». Le «non-stop-rntime» est l intervalle de temps pendant leqel le système reçoit ne rafale de trames. Après cet intervalle de temps, s école n très cort intervalle de temps où le système ne reçoit acne trame à émettre o à recevoir, pis revient de novea ne rafale de trame et ainsi de site. Typiqement, dans n modem radio, la réception d ne rafale de trames srvient lorsq il fat transmettre des données tiles sr la voie radio. L intervalle de temps drant leqel il n y a pas de trames correspond a moment de la synchronisation d horloge entre émetter et récepter. Pendant cet intervalle de temps,

58 2.3 Condition sffisante de faisabilité 47 on ne reçoit pas de données tiles. Une tâche GMF non cycliqe constitée de N i trames Ni 1 Ni 1 Ni 1 est caractérisée par ne séqence de triplets (( C i, Di, Pi ), ( C i, Di, Pi )) où j j j C i, D i, et P i représente le pire temps d exéction de la j-ième trame de la tâche τ i, l échéance relative de la trame, et le temps de garde entre la j-ième trame et la trame sivante, respectivement. Chaqe tâche effecte ne première activation à l instant O i. Nos considérons les tâches GMF non cycliqes qi satisfont la propriété «Frame Separation», ce qi signifie qe l échéance absole d ne trame n est pas pls tardive qe j j la date d arrivée de la trame sivante, où qe Di Pi est vraie qelqe soit j ( 0 j Ni 1) [66]. 2.3 Condition sffisante de faisabilité Dans l optiqe de déterminer n test de faisabilité sffisant, nos considérons d ne part ne activation initiale simltanée de totes les tâches à n instant t ( i [ 0, m 1], O i = t ) et d atre part qe lers trames sivantes arrivent le pls tôt j j possible ( i [ 0, m 1], j [0, Ni 1], D i = Pi ). Ceci crée ne demande de calcl maximale por le processer, prodisant ainsi le pire scénario por les tâches afin q elles respectent lers échéances temporelles. Nos nos attaqons d abord a problème qi consiste à trover ne formle por le calcl d temps de réponse des tâches GMF non cycliqes Calcl d temps de réponse Por l activation d ne tâche GMF non cycliqe τ i à n instant t, de à l arrivée de sa j-ième trame, le temps de réponse de la tâche est composé d temps d exéction de la trame correspondante, pls l interférence dont soffre la tâcheτ i, de ax activations d atres tâches d système avec des dates d activations et échéances absoles comprises entre [t,t+ D j i ]. Nos définissons l interférence comme étant l impact qe sbit ne tâche τ i en raison des activations d atres tâches d système avec des échéances pls proches qe celle de la tâche τ i. En effet comme nos considérons n ordonnancer EDF, les tâches activées avec ne échéance pls proche se verront tojors attriber le processer. La Figre 2.3 présente n exemple d interférence sbie par ne tâche τ 1 (avec ne échéance temporelle à D 1) après son activation simltanée à l instant 0 avec les tâches τ 2 et τ 3. Cette interférence est de à l exéction des tâches τ 2 et τ 3 qi ont lers échéances temporelles ( D2 et D 3 ) avant D 1.

59 Chapitre 2 Contribtions : Ordonnancement temps réel 48 Interférence sbie par τ 1 τ 3 D3 time τ 2 D 2 time τ 1 0 D 1 time Figre 2.3 Exemple d interférence sbie par ne tâche Soit R i, t, le temps de réponse de τ + i, nos avons j D i j R i, t+ D = Ci + Ii, t+ D où I j i, t + représente l interférence dont soffre la tâche τ i. Nos présentons à présent l analyse por le calcl de I j i, t +. D i Afin d illstrer comment nos trovons ne formle por le calcl de l interférence, nos considérons l exemple d système d Tablea 2.1. j i j i D i task O i j C i j j D i = Pi τ τ Tablea 2.1 Système d exemple 1 Le système est composé de dex tâches. La tâche τ 1 a 3 trames alors qe la tâche τ 2 a jste ne trame. Nos sommes intéressés par le respect de l échéance temporelle de la tâcheτ 2, en considérant ne activation initiale simltanée avec la tâcheτ 1. Por calcler l interférence de ax activations de τ 1, nos éliminons d abord la seconde trame de la tâche τ 1(la trame por laqelle l échéance temporelle est à 17), ceci parce qe l arrivée de cette trame ne pet pas retarder l exéction de la tâche τ 2, car cette échéance est pls grande qe celle de la tâche τ 2. La Figre 2.4 représente sos forme d n arbre les différentes séqences d activations de τ1qi pevent retarder l exéction de τ 2 jsq à l instant 16. Chaqe chemin dans l arbre représente ne séqence d exéction qi pet interférer, car les dates d arrivées et les échéances temporelles sont comprises dans l intervalle [0 ; 16]. Par exemple, le chemin 4 correspond à la séqence [2 ;1 ;1 ]. Le temps de réponse est calclé por chaqe séqence possible d activation de la tâche τ 1. Soit L n, représentant ne séqence d activation de la tâche τ 1. L 2,2,2,2, chemin 1, nos avons Por [ ] 1 =

60 2.3 Condition sffisante de faisabilité 49 R 2,16 = 3 + 2*4 = 11 16, l échéance temporelle est respectée L 2 = 2,2,1, chemin 2, nos avons R 2,16 = 3 + 2*2 + 1 = 8 16, l échéance temporelle est respectée L 3 = 2,1,2, chemin 3, nos avons R 2,16 = 3 + 2*2 + 1 = 8 16, l échéance temporelle est respectée L 4 = 2,1,1, chemin 4, nos avons R 2,16 = *1 = 7 16, l échéance temporelle est respectée L 5 = 1,1,1, chemin 5, nos avons R 2,16 = 3 + 3*1 = 6 16, l échéance temporelle est respectée L 6 = 1,1,2, chemin 6, nos avons R 2,16 = 3 + 2*1+ 2 = 7 16, l échéance temporelle est respectée L 7 = 1,2,1, chemin 7, nos avons R 2,16 = 3 + 2*1+ 2 = 7 16, l échéance temporelle est respectée L 8 = 1,2,2, chemin 8, nos avons R 2,16 = *2 = 8 16, l échéance temporelle est respectée Por [ ] Por [ ] Por [ ] Por [ ] Por [ ] Por [ ] Por [ ] time 1 τ Figre 2.4 Interférence générée par τ 1 dans l exemple 1 Soit S 1 représentant l ensemble des différentes séqences d activations de τ1qi pevent interférer sr l exéction de τ 2, nos avons : S 1 = {[2;2;2;2],[2;2;1],[2;1;2],[2;1;1],[1;1;1],[1;1;2],[1;2;1],[1;2;2] }. De manière formelle, por ne tâcheτ, l ensemble des séqences d activations qi pevent interférer avec l exéction d ne atre tâche τ i est donné par : l l l l ln ln S = [ C 1 ;...; C ],[ C ;...; C ],...,[ C ;...; C ] l L l L,..., l L tel qe pot tot ln Ln nos { } 1 1, 2 2 n n ln avons t + D t + l n j Di En général l interférence est calclée comme sit :

61 Chapitre 2 Contribtions : Ordonnancement temps réel 50 Soit = { i } i [ 0; m 1] τ n ensemble de tâches. Considérons ne tâche τ i activée à n instant t, por calcler le temps de réponse de τ i, nos éliminons d abord por chaqe j tâche dans { τ i }, les trames avec des échéances temporelles spérieres à D i. En effet l arrivée de ces trames ne pet pas retarder l exéction de τ i. Evidemment si totes les trames d ne tâche sont éliminées, alors la tâche est éliminée. Ainsi por les tâches et k j lers trames respectives restantes nos avons ( i), k [0, Ni 1], D Di. Nos * appelons ce novel ensemble i qi est défini de manière formelle par : * { } k j i = τ i / k, D D (Le caractère «/» correspond à l expression «tel qe») i L interférence dont soffre la tâche τ i est donc donnée par : I ln j, t+ D = ( C ) i i * l j τ l / t+ D n t+ D Dans la formle de l interférence, nos avons l expression ln C l j l / t+ D n t+ D n l n i i n qi correspond à la somme des temps d exéction des séqences correspondant ax j activations dont les échéances temporelles sont avant D i. Ainsi, por chacne des tâchesτ, nos combinons ne de ses séqences avec ne des séqences des atres tâches. Le temps de réponse est alors égal à : l n i Ri, t D j = Ci + ( l τ l / t+ D n t+ D j + i * i n l n j i ln C ) Nos proposons dans la section sivante, n test d ordonnançabilité basé sr la densité por n ensemble de tâches GMF non cycliqes Test basé sr la densité (1) La sitation la pls critiqe Le pire scénario por ne tâche τ i lors la réception de sa j-ième trame (.i.e. le scénario qi li génère n temps de réponse maximal por le traitement de cette trame) est atteint lorsqe l interférence q elle sbit por le traitement de cette trame est maximale (de part la définition d temps de réponse). Cette interférence maximale est obtene lorsqe totes les tâches d système sont activées simltanément, a même moment où la tâche τ i reçoit sa j-ième trame. A titre de preve, prenons l exemple de la Figre 2.5, où est représentée dex tâches ( τ i et τ i+ 1). Nos nos intéressons à l interférence sbie par la tâche τ i de ax activations de la tâche τ i+ 1. Considérons ne activation de la tâche τ i à l instant t1 et de la tâche τ i+ 1 à j l instant t2. Drant l intervalle [ t 1, t1 + D i ], la préemption de la tâche τ i par la tâche τ i+ 1 va caser n retard sr la fin de l exéction de τ i, à moins qe la tâche τ i ait fini son exéction à l instant t2. De pls, si l activation de la tâche τ i+ 1 a lie à ne date spériere à t2, l interférence sbie par la tâche τ i, sera soit inchangée, soit diminée. Par

62 2.3 Condition sffisante de faisabilité 51 conséqent, por maximiser l interférence qe sbie la tâche τ i, il fat ramener l activation de la tâche τ i+ 1 à t1 (activation simltanée des dex tâches). t 1 j t 1 + D i τ i time t 2 j t2 + D i + 1 τ i+1 time Figre 2.5 Interférence maximale sbit par ne tâche Nos proposons le théorème sivant : Théorème 2.1 Etant donné n ensemble de m tâches GMF non cycliqes traitant m 1 j C i max ( ) 1 = j (2) i j N i D i N i trames, si alors l ensemble des tâches est ordonnançable avec EDF sr ne architectre monoprocesser. Preve : En considérant ne activation simltanée de totes les tâches, la preve consiste à montrer qe, lorsqe la condition (2) est satisfaite, totes les tâches respectent lers échéances temporelles por ler 1 ère activation. En effet les activations sivantes seront : soient simltanées et nos retombons sr la même sitation qe celle de la 1 ère activation, soient non simltanées et nos avons ne sitation moins critiqe car l interférence dont soffre chaqe tâche n est pas maximale. Por des besoins de clarté, considérons la xi -ième trame por chaqe tâche τ i, où xi j Ci C m 1 i = max ( ), la condition (2) devient x i C i 1 xi 0 j N 1 j D i x. i i Di i = 0 D i Sans perte de généralité, considérons qe la 1 ère activation de la tâche τ i est initiée par sa j-ième trame. Por qe la tâche τ i respecte son échéance temporelle, il sffit qe le temps de réponse de sa 1 ère j activation soit inférier à D i, i.e. :

63 Chapitre 2 Contribtions : Ordonnancement temps réel 52 j i D D l l j i D C C j i l n l n n n + τ ) ( / (3) Nos montrons à présent qe l éqation (3) est vérifiée lorsqe la condition (2) est vraie. Nos avons l n ) * ( ) ( * * * * / / / / i i l n j i l n n n l n j i l n n n ln j i l n n n ln j i l n n n n n n n D D l x x l D D l l D D l x x l D D l l x x l l x x l l D C D C D C D C D C D C D C D C τ τ En tilisant cette inégalité nos avons finalement j i x x j i j i j i j i x x j i D D l l x x j i D D l x x l j i D D l l j i D D C D C D D D C C D D C C D C D C C C i i l n j i l n n n i i l n j i l n n n i ln j i l n n n ) ( * ) ( ) * ( * * * * * / / / τ τ τ τ τ car 1 * * + + i i i i x x x i x i x x j i j i D C D C D C D C τ τ (d après la condition (2)). Cette méthode pet être appliqée à chaqe tâche i τ, ce qi prove le Théorème 2.1. L analyse par le calcl d temps de réponse et le test de faisabilité présentés précédemment sont tos les dex sffisants et pas forcément nécessaires. Lorsqe les tâches pevent avoir des dates de premières activations arbitraires, ne activation simltanée de totes les tâches pet ne jamais se prodire drant tote la drée de vie d système. De pls on n a pas nécessairement j i j i P D = (les trames sivantes arrivent le pls tôt possible). Néanmoins l avantage d test de faisabilité sffisant est sa complexité polynomiale. Ainsi dans les modems radio reconfigrables somis ax contraintes de l embarqé (temps de réponse borné), ce test pet être fait en ligne. La section sivante présente ne approche efficace por ne analyse exacte.

64 2.4 Analyse exacte de la faisabilité temps réel Analyse exacte de la faisabilité temps réel Por illstrer le problème de l analyse exacte, n atre système d exemple avec dex tâches ( τ 1 et τ 2 ) est représenté dans le Tablea 2.2. La tâche τ1est ne tâche GMF non cycliqe avec 2 trames et ne date de 1 ère activation à l instant 3. La tâche τ 2 a jste ne trame avec ne date de 1 ère activation à l instant 0. Le système a n non-stop-rntime égale à L. tâche O i j C i j D i j P i τ τ Tablea 2.2 Système d exemple time τ Figre 2.6 Les différentes possibilités d exéction de la tâche τ 1 de l exemple 2 Les différentes possibilités d exéction de τ 1 sont représentées dans la Figre 2.6 sos la forme d n arbre. Chaqe chemin dans l arbre représente ne séqence d exéction possible. Par exemple le chemin 5, a la séqence [2 ;1 ;2 ;2] à l instant 25. Por la détermination de la faisabilité par simlation, nos proposons de mettre en œvre n simlater EDF avec ne qee contenant les tâches activées, prêtes à s exécter et

65 Chapitre 2 Contribtions : Ordonnancement temps réel 54 ne horloge représentant la progression d temps. Lorsq ne tâche est activée, elle est q q q mise dans la qee. Précisément n qadrplet ( X i, Yi, Zi, #i) est ajoté dans la qee q q q q, où X i est le temps d exéction de la tâche, Y i son échéance temporelle relative, Z i la date de la prochaine activation de la tâche, et #i est l identifiant de la tâche. La qee est triée en fonction des échéances temporelles croissantes. Lorsqe l horloge avance, le temps d exéction de la tâche en 1 ère position dans la qee est décrémenté. L échéance temporelle relative de chacne des tâches de la qee est assi décrémentée. Ainsi, lorsqe le temps d exéction d ne tâche devient pls grand qe son échéance temporelle relative ceci revient à dire qe cette échéance temporelle ne sera pas respectée. Lorsqe le q temps d exéction d ne tâche dans la qee devient égale à zéro, ces paramètres X i et q Y i ne sont pls modifiées jsq à la prochaine activation de la tâche. ki Soit Pa i la ki -ième séqence d exéction d ne tâche τ i drant n non-stop-rntime L. La propriété formelle à vérifier est la sivante : k0 1 «Existe t-il n vecter [ 0, k k Pa Pa1,..., Pam m 1 ] qi pet être exécté sr le simlater EDF sans atteindre la sitation où ne échéance temporelle n est pas respectée» Approche naïve Dans l approche naïve, nos ferions d abord ne liste de tos les vecters possibles k0 1 [ 0, k k Pa Pa1,..., Pam m 1 ], k 0, k 1,..., k m 1. Pis de cette liste, nos vérifions qe chaqe vecter ne condit pas vers ne sitation où ne échéance temporelle n est pas respectée. Cette approche nécessite la prise en compte de totes les combinaisons d exéctions possibles de totes les tâches et abotira rapidement à ne explosion combinatoire. La complexité s aggrave lorsqe le non-stoprntime est grand et q il y a beacop de tâches. La section sivante présente ne approche efficace, qi rédit le nombre de combinaisons nécessaires Approche efficace Dans notre approche, nos constrisons chaqe vecter de la gache vers la droite, ainsi à chaqe instant, nos simlons l exéction avec ne qee, et testons s il existe ne qee prodite par n atre vecter qi est identiqe, dans ce cas nos remplaçons immédiatement les dex qees par ne sele. Définition 2.1 Considérons Q 1 et Q 2, dex qees avec lesqelles nos avons constrit n ordonnancement partiel sivant la politiqe EDF à n instant t1. Si por tote tâche τ i, nos avons ( X i = X i et Y i = Y i et Z i = Z i ) o ( X i = X i = 0 et Z i = Z i ), alors les dex qees sont identiqes (d point de ve de l ordonnancement temps réel). En d atres termes, à partir de t1, elles constriront le même ordonnancement. Sccessivement, pendant la constrction des différentes séqences d exéctions possibles des tâches, nos appliqons cette techniqe ax qees et remplaçons les

66 2.4 Analyse exacte de la faisabilité temps réel 55 qees identiqes par ne sele, économisant ainsi l effort de constrction des vecters et le temps de simlation des qees identiqes. Ainsi, lors de l activation initiale de la 1 ère tâche, le nombre de qees correspondant ax séqences possibles d exéction sont créées. Lorsq ne novelle tâche est activée, ne rotine combine les séqences possibles d exéction de la novelle tâche avec celles précédemment activées. Ceci dpliqe le nombre de qees. A chaqe instant, chaqe qee constrit n ordonnancement tel qe décrit pls hat sivant la politiqe EDF et les qees identiqes sont remplacées par ne sele. Afin d illstrer comment notre approche marche, nos revenons a système pris en exemple dans le Tablea 2.2. Q1 0 [(2, 4, 8, #2)] 1 [(1, 3, 8, #2)] 2 [(0, 2, 8, #2)] 3 [(2, 3, 9, #1); (0, 2, 8, #2)] 4 [(1, 2, 9,#1); (0, 2, 8, #2)] 5 [(0, 1, 9, #1); (0, 2, 8, #2)] 6 [(0, 1, 9, #1); (0, 2, 8, #2)] 7 [(0, 1, 9, #1); (0, 2, 8, #2)] 8 [(2, 4, 16, #2); (0, 1, 9, #1)] 9 [(1, 3, 16, #2); (2, 3, 15, #1)] 10 [(0, 2, 16, #2); (2, 2, 15, #1)] 11 [(1, 1, 15, #1); (0, 2, 16, #2)] 12 [(0, 0, 15, #1); (0, 2, 16, #2)] Q2 3 [(1, 4, 7, #1); (0, 2, 8, #2)] 4 [(0, 3, 7, #1); (0, 2, 8, #2)] 5 [(0, 3, 7, #1); (0, 2, 8, #2)] 6 [(0, 3, 7, #1); (0, 2, 8, #2)] 7 [(1, 4, 11, #1); (0, 2, 8, #2)] 8 [(2, 4, 16, #2); (0, 3,11, #1)] 9 [(1, 3, 16, #2); (0, 3,11, #1)] 10 [(0, 2, 16, #2); (0, 3,11, #1)] 11 [(2, 3,17, #1); (0, 2, 16, #2)] 12 [(1, 2,17, #1); (0, 2, 16, #2)] 13.. Q3 7 [(2, 3, 13, #1); (0, 2, 8, #2)] 8 [(1, 2, 13, #1); (2, 4, 16, #2)] 9 [(0, 1, 13, #1); (2, 3, 16, #2)] 10 [(1, 2, 16, #2); (0, 1, 13, #1)] 11 [(0, 1, 16, #2);(0, 1, 13, #1)] Q4 9 [(1, 3, 16, #2); (1, 4, 13, #1)] 10 [(0, 2, 16, #2); (1, 3, 13, #1)] 11 [(0, 2, 13, #1);(0, 2, 16, #2)] 12 [(0, 2, 13, #1);(0, 2, 16, #2)] 13 Q5 11 [(1, 4, 15, #1);(0, 2, 16, #2)] 12 [(0, 3, 15, #1);(0, 2, 16, #2)] Figre 2.7 Détermination de la faisabilité dans l exemple 2 Comme montré dans la Figre 2.7 (la figre est le d hat vers le bas), à l instant 0, τ 2 est ajoté dans la 1 ère qee Q1. La qee simle la politiqe d ordonnancement EDF. Por simler l exéction de la tâche nos diminons son temps d exéction d ne nité de temps entre l instant 0 et l instant 1. En même temps nos diminons son échéance temporelle correspondante por simler l échéance qi se rapproche. A l activation initiale de la tâche τ 1(instant 3), le qadrplet (2, 3, 9, #1) est ajoté à Q1. Q1 va donc simler le cas où τ 1(à l instant 3) reçoit sa 1 ère trame. Simltanément, ne novelle qee Q2 est créée por le second cas possible de τ 1. Cette novelle qee contient le qadrplet qi se trovait déjà dans Q1 (0, 2, 8, #2), pls le qadrplet (1, 4, 7, #1). Q2 simle le cas où à l instant 3, τ 1 reçoit sa dexième trame.

67 Chapitre 2 Contribtions : Ordonnancement temps réel 56 Pis les dex qees (Q1 et Q2) constrisent n ordonnancement sivant la politiqe EDF. A l instant 7, qi correspond a moment de la prochaine activation de τ 1 dans Q2, Q3 est créée por simler le cas où à cet instant il reçoit sa 1 ère trame, et ainsi de site. En continant cette procédre, nos observons q à l instant 11, Q3 et Q4 sont identiqes car nos avons X 1 = X1 = 0 avec Z 1 = Z1 = 13 et X 2 = X 2 = 0 avec Z 2 = Z2 = 16. A partir de cet instant, il n est pls nécessaire de continer la procédre avec les dex qees, elles constriront le même ordonnancement, nos spprimons donc Q3. A l instant 12, Q1 et Q5 sont assi identiqes, nos spprimons Q5. Progressivement pendant la constrction des différentes possibilités d exéctions des tâches, les qees identiqes sont remplacées par ne sele. Dans la Figre 2.8, nos présentons le psedo code de l algorithme por cette approche. time = 0; while (time < NONSTOPRUNTIME) Feasibility Determination Algorithm if(all tasks have not been released at least once) for τ i in remaining tasks to initiate their first release if ( O i == time) if (the list is empty) for each frame of τ i endif endif endfor endif q = create new qee; addtple(q, τ i ); addqeetolist(list, q); endfor else adddifferentpossibilitieswithpreviostaskreleased(list, τ i ) time++; for each qee in list execteedfstrategy(q); if(deadlinemissed(q)) retrn nschedlable; for each tple in q if(exist i: q Z i endfor endfor eliminateidenticalqee(list); endwhile ==time) adddifferentcombination(list, τ i ); for each qee in list execteedfstrategyforremainingworkload(q); if(deadlinemissed(q)) retrn nschedlable; endfor retrn schedlable; Figre 2.8 Algorithme de détermination de la faisabilité temps réel exacte

68 2.4 Analyse exacte de la faisabilité temps réel 57 L algorithme se termine en exéctant la politiqe EDF por la charge processer restante après le non-stop-rntime. Cette charge doit être infériere a délai après le nonstop-rntime, fixé par le concepter, avant qe le système ne reçoive ne novelle rafale de trames. L algorithme a été développé et testé sr n ordinater en langage C++. L efficacité de cette approche est mesrée en fonction d nombre de qees gérées à chaqe instant, car chaqe combinaison dpliqe le nombre de qees en fonction d nombre de trames de chaqe tâche. Nos avons expérimenté cette approche avec l exemple d Tablea 2.2. La Figre 2.9 montre qe por n non-stop-rntime de 300 nités de temps l approche naïve devrait gérer 149 qees alors q avec la novelle approche nos n tilisons qe 4 qees. Ce qi correspond à n gain de 97,4%. Après 300 nités de temps, l ensemble de tâches est correctement ordonnancé (i.e. totes les échéances temporelles sont respectées por totes les tâches). La charge maximale restante parmi les 4 qees est de 1 nité de temps. Ainsi si ce délai après le non-stop-rntime, est acceptable par le concepter, le système pet être réalisé avec sccès. Cette approche a été expérimentée sr l exemple d système d Tablea 2.3. Il est composé de 3 tâches. Chaqe tâche possède 2 trames. Tel qe le montre la Figre 2.10, le gain est assi significatif. Après 300 nités de temps, totes les échéances temporelles sont respectées. Nos obtenons ne charge maximale restante de 13 nités de temps. Alors qe l approche naïve arait nécessité la gestion de qees, la novelle approche nécessite qees. Ce qi correspond à n gain de 83,85%. La Figre 2.10 montre clairement, comment la novelle approche est pls efficace (i.e. moins exponentielle) qe l approche naïve. Evoltion of managed qees in example nmber of qee tim e naive approach new approach Figre 2.9 Evoltion d nombre de qees dans l exemple 2

69 Chapitre 2 Contribtions : Ordonnancement temps réel 58 tâche O i j C i j D i j P i τ τ τ Tablea 2.3 Système d exemple 3 Evoltion of m a na ge d qe e s in e x a m ple nmber of qee tim e naive approac h new approac h Figre 2.10 Evoltion d nombre qees dans l exemple 3 Nos avons testé l approche avec l exemple d Tablea 2.4. Cet exemple est composé de 6 tâches où chaqe tâche possède 2 trames. tâche O i j C i j D i j P i τ τ τ τ

70 2.4 Analyse exacte de la faisabilité temps réel τ τ Tablea 2.4 Système d exemple 4 Por cet exemple, ne échéance temporelle n est pas respectée à l instant 105. Evoltion of managed qee in example nmber of qee time naive approach new approach Figre 2.11 Evoltion d nombre de qees dans l exemple 4 La Figre 2.11 montre qe l approche naïve tilise qees lorsqe la novelle approche tilise qees, n gain de 52,37%. Notons qe por chacne de ses expérimentations, la drée effective de la simlation est de qelqes mintes. Nos précisons assi qe le Théorème 2.1 n est pas vérifié por chacn ces exemples. Discssion Le modèle GMF non cycliqe proposé dans ce chapitre est moins restrictif qe le modèle GMF cycliqe proposé en 1999 dans [65]. En effet le modèle GMF cycliqe représente ne séqence d exéction possible parmi ne infinité de possibilité dans le modèle non cycliqe. Clairement, en considérant le modem radio de l exemple introdctif, les modèles de tâches précédents [60] [49] [65] [85] ne réssissent pas à modéliser ce type de système. Cependant en tilisant notre modèle, nos povons constrire n modèle por ce type de système.

71 Chapitre 2 Contribtions : Ordonnancement temps réel Conclsion Dans ce chapitre nos avons relâché l hypothèse qi consiste à considérer n motif d activation por le modèle de tâches GMF. Dans ce contexte, nos avons présenté la formle d temps de réponse, et n test d ordonnançabilité sffisant por n ensemble de tâches GMF non cycliqes s exéctant sivant la politiqe d ordonnancement EDF. Nos avons également présenté ne approche efficace por l analyse exacte de la faisabilité temps réel d n ensemble de tâches GMF non cycliqes. Cette analyse tilise la simlation sr ordinater por déterminer la faisabilité temps réel. En général, le modèle de tâche GMF non cycliqe est fréqemment rencontré dans les applications de traitement d signal car ces applications deviennent de pls en pls flexibles et adaptatives, ainsi les flots de données ne sivent pas de motif spécifiqe. Après pblication de nos travax dans ne conférence phare de la commnaté temps réel, ils ont été porsivis par le professer Sanjoy BARUAH dans [75] et [76]. Dans [75], il propose n test de faisabilité exact à complexité psedo polynomiale avec la condition qe le tax d tilisation d processer soit strictement inférier à 1. Notre analyse exacte est générale por les systèmes de tâches non cycliqes car elle ne présppose acne hypothèse. Pis dans [76], il propose n novea modèle de tâche pls général qe le modèle GMF non cycliqe qe nos avons introdit. Il présente n test de faisabilité exact por ce modèle tojors avec la condition qe le tax d tilisation d processer soit strictement inférier à 1. Nos prenons en compte ce novea modèle dans le chapitre sivant. Bien qe notre étde fût basée sr les architectres monoprocessers, nos précisons tot de même qe nos avons généralisé le Théorème 2.1 por les architectres mlti-processers. Cette généralisation a fait l objet d dépôt d n brevet d invention.

72 Chapitre 3 Contribtions : Méthodologie de conception et otillage Résmé : Dans la radio logicielle idéale, tos les algorithmes de traitement d signal doivent être implantés sos forme logicielle. Etant donné le grand nombre de composants logiciels à exécter simltanément sr n même processer por les ftrs éqipements radios hat débit, les concepters s interrogent sr les méthodologies de conception por l ordonnancement temps réel en adéqation avec ces évoltions. Dans ce chapitre nos proposons ne méthodologie de conception qi permet d effecter l analyse d ordonnancement temps réel des tâches dans ne radio logicielle. Assi, nos présentons dans ce chapitre ne approche efficace permettant de vérifier l ordonnancement temps réel des tâches implantant des algorithmes de traitement d signal flexibles et s exéctant sr n processer sivant ne politiqe d ordonnancement hybride (combinaison de la politiqe d ordonnancement à priorité fixe et de la politiqe d ordonnancement «Earliest Deadline First»). Ces méthodes permettent assi de miex repartir les composants à implanter sos forme logicielle et cex à implanter sos forme matérielle dans n éqipement radio. 3.1 Introdction Avec la mltiplication des réseax (et standards) mobiles et sans fil, la coche physiqe des systèmes de commnications (i.e. la partie d modem d système) doit être complètement flexible afin qe les éqipements pissent s adapter à plsiers modes de fonctionnement. La coche physiqe doit spporter ne large variété d algorithmes complexes qi dépendent de nombrex paramètres. Certains de ces algorithmes en otre ne sont pas encore finalisés o standardisés et pevent évoler o changer. Un grand nombre de modems radios actellement commercialisés ont des composants majoritairement mis en œvre sos forme matérielle (i.e. sr FPGA o sr ASICs). La partie logicielle de ces modems radio est restreinte à la réalisation de fonctions complémentaires telles qe la programmation des fréqences porteses o le sivi de la performance. Il est généralement considéré irréalisable d ajoter pls d algorithmes de traitement d signal sos forme logicielle à case de lers complexités en temps de calcl et des problèmes d ordonnancement temps réel qe cela indit. Cependant ne soltion 61

73 Chapitre 3 Contribtions : Méthodologie de conception et otillage 62 logicielle (telle qe vole dans l approche SDR) porrait apporter qelqes avantages par rapport à son éqivalent matériel en termes de : faible coût de développement, rédction d temps de mise sr le marché, grande portabilité des IP (Intellectal Property) de traitement d signal, mise à jor facile lors des évoltions. Dans les perspectives offertes par les ftrs éqipements radio hat débit, ne approche logicielle entrainera plsiers tâches implantant des algorithmes de traitement d signal (émanant de standard radio différent) à s exécter simltanément sr n même processer. Cependant, ces tâches doivent prodire des données dans n intervalle de temps borné. Elles sont somises à des contraintes temporelles strictes. Les méthodologies de conception proposées dans la littératre [11] [79], et les otils commerciax [80] [81] fornissent différentes aides afin de faciliter le processs de conception, allant d développement de modèles visels, en passant par l évalation des performances, jsq à la génération atomatiqe d code por le déploiement sr cible. Malheresement, acn de ces otils de conception ne fornit n spport por vérifier l ordonnancement temps réel des tâches implantant des algorithmes de traitement d signal flexibles dans ne radio logicielle. Pire encore, il n est pas possible d tiliser les otils libres o commerciax d analyse d ordonnancement temps réel disponible à ce jor car il existe n fossé entre le modèle d analyse des otils d ordonnancement temps réel et les modèles générés par les otils de conception. Une raison qi jstifie cela vient d fait qe les modèles de réalisations générés par les otils de conception sont basés sr des applications dirigées par des évènements. Dans ne telle application, chaqe tâche gère plsiers types d évènements, ce qi fait en sorte qe son temps d exéction, son échéance temporelle et son temps de garde varient d ne activation à ne atre en fonction d type d évènement qi est traité. Ceci est complètement différent d modèle de tâche considéré dans les otils d ordonnancement temps réel à ce jor, où les tâches gèrent en général n sel type d événement et sont somises à ne sele contrainte de bot en bot. Ce chapitre fornit les contribtions sivantes : Une méthodologie de conception qi permet l analyse d ordonnancement temps réel des tâches dans ne radio logicielle. Nos présentons n ensemble de règles à sivre pendant les phases de modélisation PIM (Platform Independent Model), PDM (Platform Description Model) et PSM (Platform Specific Model), en considérant en particlier le profil MARTE [7]. Une approche por la vérification de l ordonnancement temps réel des tâches implantant des algorithmes de traitement d signal flexibles et s exéctant sr n processer en fonction d ne politiqe d ordonnancement hybride. Le reste de ce chapitre est organisé comme sit. La section 3.2 rappelle les travax connexes. La section 3.3 décrit la novelle méthodologie de conception qe nos proposons. La section 3.4 présente notre algorithme por l analyse d ordonnancement

74 3.2 Travax connexes 63 temps réel des tâches réalisant des algorithmes de traitement d signal dans ne radio logicielle. Une conclsion est présentée en section Travax connexes Un grand nombre de travax de recherche ont été entrepris dans le domaine des méthodologies de conception por les applications de traitement d signal. Plsiers de ces tentatives sont des méthodologies basées sr HDL (Hardware Description Langage) [10] [19] [70] [79] [82], alors qe d atres [83] [84] sont des méthodologies por des réalisations entièrement logicielles. Dans [83], Saksena et al ont intégré les résltats d analyse d ordonnancement por le modèle de tâches avec transaction [49] [56], sr la conception objet en tilisant le profil «UML-RT». Bartolini et al présentent dans [84] n algorithme permettant de «mapper» n flot de données sr n ensemble de tâches temps réel. Assi, certaines approches génériqes [86] [87] [88] ont été proposées dans la littératre por la conception de systèmes temps réel embarqés. Notre méthodologie de conception est différente car : (1) nos considérons le novea modèle de tâche récrrente non cycliqe introdit dans [76] après la pblication de nos premiers travax, pisqe ce modèle représente encore miex le comportement des tâches dans ne radio logicielle, (2) nos tilisons le novea profil UML por les systèmes temps réel embarqés récemment standardisé à l OMG (MARTE). Par conséqent, les approches précédentes de conception ne pevent pas être appliqées. 3.3 Notre méthodologie de conception Notre méthodologie de conception de modems radio logiciels est basée sr l approche MDA (Model Driven Architectre). Por cette raison le processs de conception est divisé en trois étapes distinctes. Dans la première phase, les aspects fonctionnels d modem radio sont abordés. Il s agit des fonctionnalités métiers d modem radio (schéma de modlation, type de coder etc.) sans acn détail de la plateforme où ces fonctionnalités vont être implantées. Dans la dexième phase, la plateforme matérielle est spécifiée, en termes de processers de traitement d signal nmériqe (Les DSPs par exemple), de la qantité de mémoire disponible, d mécanisme de connectivité entre les tâches, d système d exploitation temps réel tilisé etc. Dans la dernière phase, la spécification fonctionnelle est «mappée» sr la plateforme matérielle, les différentes activités à effecter sr n processer sont assignées sos forme de tâches temps réel. Ensite les temps d exéctions et les échéances temporelles des tâches sont calclés pis renseignés dans le modèle. La taille de bffer de données nécessaire por chaqe tâche est assi renseignée. Après ces étapes, nos proposons de transformer les modèles venant de l otil de modélisation vers n modèle compréhensible par l otil d analyse d ordonnancement temps réel qe nos avons développé dans cette thèse. L otil d analyse d ordonnancement spporte le novea modèle de tâche récemment introdit par Barah [76] site à des échanges sr nos travax. Il effecte ne simlation d comportement

75 Chapitre 3 Contribtions : Méthodologie de conception et otillage 64 temporel des tâches en se basant sr des arrivées de trames distribées de manière aléatoire dans le temps. Nos présentons également les concepts de MARTE qi doivent être tilisés por exprimer des propriétés non fonctionnelles. La Figre 3.1 résme la démarche de notre flot de conception. Le concepter réalise d abord n «état de configration fonctionnel», il s agit de l état vers leqel le poste radio va se reconfigrer. Il est composé d n ensemble de formes d ondes. Pis le concepter réalise n «état de configration physiqe». Il s agit d «mapping» de «l état de configration fonctionnel» vers les différentes nités d exéctions. Cette projection est sivie d rajot des différentes caractéristiqes temporelles des tâches et des services logiciels déployés sr le processer d intérêt. Enfin des fichiers générés par l otil de modélisation sont transformés et tilisés por l analyse d ordonnancement temps réel. PIM Fnctional configration state WF1 WF1 WF3 A1 B1 C A2 B2 C xmi.xmi WF1 PIM WF2 PIM Waveform PIMs Constraints (end-to-end delay) Connections PSM.xmi Fnctional configration State descriptor Physical configration state.xmi Physical configration state descriptor Waveform components.xmi Waveform components Descriptor Tool(s) Façade.xmi Facade Descriptor Schedling analysis with Hybrid schedler - real-time simlation based on random frames arrivals Technical services Connectivity Schedling.xmi Technical services Descriptor Time management Reconfigration infrastrctre Exection time Memory occpation Ports assmptions Descriptor Deployment assmptions Tasks models (period, exection time, deadline, priority ) MARTE Profile Figre 3.1 Notre flot de conception Dans l approche MDA, la première phase consiste à réaliser n modèle indépendant de tote plateforme Modélisation PIM Le modèle PIM pet contenir plsiers chaînes de traitement radio (chacne correspondant à n standard). Por chaqe chaîne radio, nos représentons dex ves : ne ve architectrale d modem radio, et ne ve comportementale. L architectre de l application est décrite de manière «top-down» et nos proposons cinq niveax de décomposition (comme présenté dans la Figre 3.2) : le nivea capacité,

76 3.3 Notre méthodologie de conception 65 le nivea en coche, le nivea applicatif, le nivea de spport fonctionnel, et le nivea d modle de base. Nos proposons l tilisation des diagrammes de strctres composites d UML por décrire progressivement chacn de ces niveax. Ce type de diagramme est appar avec UML 2.0, il permet de décrire la strctre interne d ne classe. Ainsi, por la modélisation PIM, chaqe élément dans notre flot de conception est représenté sos forme d ne classe UML, et sa strctre interne est décrite avec n diagramme de strctre composite. PIM Levels Capability Layer Applicative Fnctional spport Base modle Figre 3.2 Différents niveax de décomposition PIM Le nivea capacité («capability») permet d exprimer les «exigences boîtes noires». Ce sont les interfaces externes (micro, socket, etc.), les entrées tilisaters, le canal de commnication, la topologie d résea, le débit etc. A ce nivea le concepter doit renseigner la latence de bot en bot por l analyse d ordonnancement temps réel. Le nivea en coche («Layer») est en conformité avec le modèle OSI, atrement dit, à ce nivea on retrove totes les différentes coches d modèle OSI. En fonction d délai de bot en bot, le concepter alloe ne latence globale por chaqe composant. De cette latence globale sera dérivée les échéances temporelles des blocs internes de chaqe composant. Une coche se décompose en dex sos systèmes : l applicatif («Applicative») et le spport fonctionnel («Fnctional Spport»). La raison de cette décomposition est q ils réalisent des fonctionnalités métiers différentes. Par exemple la coche physiqe d ne radio logicielle va se décomposer en n modem qi prodit le signal en bande de base et n transceiver qi réalise par exemple les conversions nmériqes/analogiqes, l amplification d signal etc. Ainsi, n spport fonctionnel pet être défini comme étant le traitement d domaine radio, dont l implantation nécessite d matériel et qelqes atres spécificités d domaine radio. La Figre 3.3 illstre cet exemple de décomposition avec n diagramme de strctre composite. Il s agit d ne coche physiqe génériqe d ne radio logicielle. La classe «PHY» représente la coche physiqe et à l intérier, nos retrovons ne classe por le composant «MODEM», ne

77 Chapitre 3 Contribtions : Méthodologie de conception et otillage 66 classe por le composant «Transceiver» et ne classe por l antenne. Les ports des composants sont reliés grâce à des connecters. En hat des connecters, nos avons le nom des interfaces réalisées et tilisées par les différents ports. Les interfaces «ReceiveDataPsh» et «TransmitDataPsh» permettent l envoi et la réception des données tiles. Les interfaces «ReceiveControl» et «TransmitControl» permettent la programmation des fréqences porteses. Ce sont les interfaces standardisées a SDR Form [92] por l échange d informations entre la partie modem d ne radio et son transceiver (convertisser nmériqe/analogiqe, carte RF/IF etc.). Les ports d entrée/sortie («inofdm», «otofdm», «inphy», et «otphy») permettent les échanges d information entre le modem de la coche physiqe et les atres parties d système. Le port «rfsignal» correspond a signal radio. Figre 3.3 Illstration d ne coche physiqe génériqe L applicatif se décompose en n ensemble de modles de base. Un modle de base est défini comme n modle élémentaire qi ne pet pas être divisé en sos parties dans le bt de distriber les sos parties dans des processers différents. La raison principale d ne telle sitation est qe, compte ten de l interaction récrrente entre les sos parties, n temps de transfert pls long entre sos parties distribées prodira ne implantation moins efficace. Nos avons défini n profil UML por les différents niveax de notre méthodologie. Ce profil s appelle «WFP» («Waveform Properties» en anglais) et est composé de stéréotypes correspondant chacn à n des niveax PIM définis dans cette section. Por povoir tiliser ce profil il fat l ajoter en tant qe profil disponible por le modèle qe nos sommes en train de réaliser. La Figre 3.4 présente notre profil. A gache nos povons voir la liste des stéréotypes et à droite nos avons n exemple d application d

78 3.3 Notre méthodologie de conception 67 stéréotype «Basemodle» correspondant a nivea d modle de base. A gache d nom d modle on pet également voir apparaître l icône qe nos avons réalisé por ce stéréotype. Figre 3.4 Profil correspondant à notre flot de conception Por la représentation comportementale, nos décrivons le comportement des composants à chaqe nivea PIM. On pet par exemple retrover n diagramme qi décrit les échanges de messages entre les modles de base. Nos proposons l tilisation des diagrammes de séqences por représenter le comportement des composants. Un exemple de représentation est présenté dans le chapitre sivant Modélisation PDM La dexième phase consiste à décrire la plateforme. Une plateforme matérielle devant acceillir ne radio logicielle est généralement composée de plsiers processers, mais nos nos intéressons à la conception sr n processer d intérêt. Por la modélisation PDM, nos proposons dans notre méthodologie, l tilisation des diagrammes de classes. Le stéréotype MARTE «GRM ::Schedler» est tilisé afin de caractériser l ordonnancer d système d exploitation temps réel. Typiqement, l attribt «ispreemptible» est tilisé por spécifier le fait qe les tâches gérées par cet ordonnancer sont préemptives o pas. L attribt «schedlingpolicy» est tilisé por définir la politiqe d ordonnancement. La Figre 3.5 présente sr n diagramme de classes, n exemple simple de modélisation PDM. Il est composé de dex classes : ne classe représentant n processer et ne atre représentant n système d exploitation temps réel.

79 Chapitre 3 Contribtions : Méthodologie de conception et otillage 68 Figre 3.5 Exemple de modèle de plateforme Après avoir appliqé le stéréotype MARTE, le nom d stéréotype apparaît a-desss d nom de l élément sr leqel nos avons appliqé le stéréotype. Par exemple sr la Figre 3.5, nos voyons le nom «schedler» apparaître a desss d nom «RTOS». Apparaît également à coté d nom de chaqe élément l icône correspondant a stéréotype. Assi, dans les propriétés de l élément, nos voyons apparaître le stéréotype et la liste de ses attribts. Comme illstré dans la Figre 3.5, nos proposons d tiliser ne relation de composition entre le processer et ses différents composants logiciels o matériels. Le stéréotype MARTE «HRM ::Hwmemory» permet de décrire la taille de la mémoire ram sr le processer d intérêt. Le stéréotype MARTE «GRM ::ResorceUsage» est tilisé por décrire les caractéristiqes temporelles d mécanisme de connectivité tilisé entre les tâches. L attribt «Exectime» permet d exprimer le temps de transfert d n bffer entre dex tâches. Dès qe la plateforme est sffisamment décrite, la dernière étape consiste à «mapper» le modèle PIM sr ne plateforme spécifiqe Modélisation PSM Pendant la modélisation PSM, différentes plateformes pevent être tilisées por évaler n même modèle. Por chaqe modle de base d PIM, n novea modle doit être créé correspondant à son implantation. Il y a ne relation de généralisation entre les dex modles dans le bt de spécifier qe le modle implanté hérite de tos les attribts, propriétés, fonctions et relations définis por ce même modle a nivea PIM. Nos

80 3.3 Notre méthodologie de conception 69 séparons le modle de base défini a nivea PIM et son implantation définie a nivea PSM car il pet y avoir plsiers implantations d n même modle. Par exemple ne implantation optimisée en vitesse d exéction mais qi occpe beacop de mémoire, et ne atre prenant pe de mémoire mais avec n grand temps d exéction. Figre 3.6 Exemple de relation entre n modle PIM et son implantation PSM Un exemple de relation entre le modle PIM et son implantation PSM est présenté dans la Figre 3.6. Nos tilisons les diagrammes de classes por représenter cette relation. Nos passons maintenant à la phase d allocation. L allocation Le stéréotype MARTE «Alloc ::ApplicationAllocationEnd» est appliqé sr les différents modles implantés. Ainsi l attribt «allocatedto» est tilisé por sélectionner le processer où sera implanté le modle. Le stéréotype MARTE «alloc ::allocated» est tilisé por spécifier de manière viselle la relation d allocation d modle implanté sr ne plateforme matérielle. Les modles implantés sont assignés en tant qe tâches logicielles temps réel avec le stéréotype MARTE «SRM ::SwschedlableResorce». La Figre 3.7 montre n exemple d allocation de modle. Nos povons également voir sr la figre le stéréotype «SRM ::SwschedlableResorce» appliqé a modle implanté. L allocation se fait également avec les diagrammes de classes. Le lien entre le modle implanté et le processer sr leqel il va être déployé, correspond à ne relation de dépendance. Bien qe la spécification de MARTE propose le package «SAM» por l analyse d ordonnançabilité ([7] page 311), nos n avons tilisé qe le stéréotype «SAM ::SaAnalysisContext» de ce package por spécifier le type d analyse. Ainsi nos n avons pas tilisé les atres stéréotypes proposés dans ce package («SAM ::Sastep», «SAM::Gascenario», «SAM::Endtoendflow», etc.) car ils permettent de spécifier des contraintes sr ne fonction o ne activité. Or nos volons assigner des contraintes sr des tâches, chacne des tâches réalisant ne o plsiers fonctions. En effet les systèmes d exploitation temps réel ordonnancent des tâches (o «threads» a sens POSIX), c est la raison por laqelle les contraintes temporelles sont généralement (y compris dans la

81 Chapitre 3 Contribtions : Méthodologie de conception et otillage 70 littératre) rapportées sr des tâches. Cependant le profil propose le package «SRM» ([7] page 197) por définir les ressorces logicielles dans n système mltitâches. En otre, le stéréotype «Swschedlableresorce» d package «SRM» ([7] page 227) est proposé por définir ne ressorce logicielle qi s exécte de manière concrrente à d atres ressorces. C est porqoi nos avons choisi ce stéréotype. Après l allocation nos povons réaliser ne caractérisation temps réel de chaqe tâche. Figre 3.7 Exemple d allocation de modle Calcl des contraintes temporelles Le temps d exéction de chaqe modle implanté est calclé en mesrant le temps qe prend le modle lorsq il s exécte tot sel sr le processer. Por calcler les échéances temporelles relatives de chaqe modle, nos calclons dans n premier temps la date d activation a pls tôt de chaqe modle. Por cela les algorithmes constitant la partie modem des traitements sont représentés sos forme de graphe direct acycliqe où chaqe modle implanté est représenté par n nœd. Un algorithme tilise la méthode de parcors de graphe en profonder où le graphe est parcor en profonder à partir d ne sorce avant d aller sr les atres nœds. Por chaqe nœd et arc rencontré dans le parcors, l algorithme somme les latences rencontrées et les dates d activations a pls tôt sont assignées à chaqe nœd. Dans n second temps, les échéances temporelles absoles sont calclées. Un algorithme de parcors en profonder identiqe à celi tilisé por le calcl des dates d activation a pls tôt, mais jste en direction inverse, permet de calcler les échéances temporelles absoles. Partant d pits d graphe, l échéance temporelle globale est diminée en fonction de la latence des nœds et des arcs rencontrés jsq à la sorce d graphe. Ainsi l échéance temporelle absole correspondante à chaqe nœd est assignée. Enfin l échéance temporelle relative de chaqe nœd correspond à la différence entre son échéance temporelle absole et sa date d activation a pls tôt.

82 3.3 Notre méthodologie de conception A B C D E F G time Figre 3.8 Méthode de calcl des échéances temporelles La Figre 3.8 montre comment nos dérolons cet algorithme sr n exemple. La figre représente ne chaine de traitement radio où A, B,, G représentent des algorithmes de traitement d signal. Nos considérons par exemple l arrivée d ne trame à l instant 1500 et ne échéance temporelle absole à l instant Les valers sont en millisecondes et chaqe algorithme nécessite 500 ms de temps d exéction. Le transfert des données entre les algorithmes nécessite 10 ms (valable por chaqe arc). Ainsi les valers en gris clair (en hat à droite) correspondent ax dates de démarrage a pls tôt tandis qe celles en gris foncé (en bas à droite) correspondent ax échéances temporelles absoles de chaqe nœd. Les valers en noir correspondent ax échéances temporelles relatives. Cependant lors d calcl des dates de démarrage a pls tôt, ne attention doit être portée por les modles déployés sr n même processer, ainsi si dans notre exemple B et C sont sr n même processer, la date de démarrage a pls tôt de E doit être la somme des chemins B et C, et non le maximm des dex chemins. Cet algorithme a été implanté en langage C++ sos forme d n otil afin d atomatiser le calcl en phase de conception. Nos verrons son tilisation dans le cas d étdes présenté dans le chapitre sivant. Notons qe ces calcls doivent être effectés por chaqe type de trame. Les attribts «deadlineselements», «identifierelements» et «messageresorce» d stéréotype «SRM ::Swschedlableresorce» permettent de renseigner respectivement les échéances temporelles, l identifiant, et la taille des bffers de donnés des tâches. L attribt «notificationsresorces» permet de spécifier les tâches sivantes activées à la fin de l exéction de la tâche corante. Nos tilisons l attribt «type» afin de spécifier le type de la tâche. Dans les modems radio logiciels, la plpart des tâches sont activées site

83 Chapitre 3 Contribtions : Méthodologie de conception et otillage 72 à l arrivée d événements (arrivée de trames). De cette première grande famille, nos distingons qatre sos-types de tâches dans la radio logicielle : Les tâches activées niqement pendant la phase de transmission (ne tâche réalisant ne fonction de codage par exemple), les tâches activées niqement pendant la phase de réception (ne tâche réalisant ne fonction de décodage par exemple), les tâches activées dans les dex phases (la tâche qi réceptionne les reqêtes venant de la coche spériere), pis les tâches qi sont périodiqes pendant n intervalle de temps, après la réception d n événement (la tâche qi programme les fréqences porteses). Ce dernier type de tâche est généralement rencontré dans les radios logicielles avec sats de fréqences. En effet les trames sont sbdivisées en paliers et chaqe palier est émis à ne fréqence portese spécifiqe. Afin d illstrer le comportement de ce dernier type de tâche, nos considérons dex trames (trame 1 et trame 2) où la trame 1 est sbdivisée en 3 paliers et la trame 2 est sbdivisée en 7 paliers. Frame change dration Frame 1 Frame 2 Dwell dration Signal in space f1 f2 f3 f1 f2 f3 f4 f5 f6 f7 P rogramming the carrier freqency f1 a dwell Task activation on board ti me Event:arrival of frame 1 Event:arrival of frame 2 Figre 3.9 Comportement de la tâche qi programme les fréqences porteses Tel qe le montre la Figre 3.9, site à l arrivée de la trame 1, la tâche est activée 3 fois. Les activations, qi sivent l activation déclenchée par la réception de la trame, sont séparées de 2 nités de temps (correspondant à la drée d palier). Pis, site à l arrivée de la trame 2, la tâche est activée 7 fois. Les activations qi sivent l activation déclenchée par la réception de la trame sont assi séparées de 2 nités de temps. Les trames pevent arriver dans n importe qel ordre. La tâche qi programme les fréqences porteses ne doit jamais rater ses échéances temporelles car ceci réslterait en ne perte d signal radio, ce qi est inacceptable por l tilisater. L attribt «timeslicelements» d stéréotype «SRM ::Swschedlableresorce» est tilisé por spécifier les temps d exéctions d ne tâche.

84 3.3 Notre méthodologie de conception 73 Ordonnancer hybride Nos proposons l tilisation d n ordonnancer hybride comme politiqe d ordonnancement por les tâches d ne radio logicielle. Un ordonnancer hybride correspond à la combinaison d n ordonnancer à priorité fixe (FP) et d n ordonnancer à priorité dynamiqe (EDF). La motivation por l tilisation d n ordonnancer hybride, est d exploiter les avantages des dex types d ordonnancers. L ordonnancer à priorité fixe por sa prévisibilité et EDF por son efficacité. Ainsi les tâches ayant ne criticité très forte o permettant de contrôler le modem, seront gérées avec l ordonnancer à priorité fixe, alors qe les atres tâches seront gérées avec EDF, conceptellement comme des tâches de basse priorité. L attribt «schedler» d stéréotype «SRM ::Swschedlableresorce» est tilisé por spécifier le type d ordonnancer qi gère la tâche. Ainsi, l attribt «priorityelements» est tilisé por renseigner la priorité des tâches gérées par l ordonnancer à priorité fixe. Nos tilisons l attribt «periodelements» por renseigner la psedo-période des tâches qi programment les fréqences porteses. Dès qe la caractérisation temps réel est terminée, nos proposons la transformation des modèles UML et des concepts MARTE vers n modèle compréhensible par notre otil d ordonnancement temps réel qe nos avons développé drant ces travax Transformation de modèles Une transformation de modèle est nécessaire afin qe les modèles réalisés avec les otils de modélisations pissent être interprétables par n otil d analyse d ordonnancement temps réel. Il existe plsiers otils de transformations de modèles, certains sont basés sr QVT (Qery/View/Transformation), n standard OMG por effecter la transformation de modèles. Les otils basés sr QVT fornissent des moyens de spécifier la manière dont est prodit n modèle cible à partir d n modèle sorce. Dans notre cas il fat fornir : Le métamodèle d UML et de MARTE Le métamodèle de l otil d analyse d ordonnancement temps réel Le modèle de l application sorce Le modèle de transformations composé de règles, qi «mappent» les concepts MARTE, typiqement les stéréotypes et attribts tilisés pendant la modélisation, vers les concepts de l otil d analyse d ordonnancement. Le Tablea 3.1 présente la correspondance entre les concepts de l otil et cex de MARTE. Concepts otil de simlation Concepts MARTE Nom DSPSIMU «SAM::SaAnalysiscontext» Description Une simlation avec n nombre de trames précis générées aléatoirement Contexte d analyse racine où sont collectées les informations spécifiqes à l analyse

85 Chapitre 3 Contribtions : Méthodologie de conception et otillage 74 Règles Vérification L élément avec le stéréotype SAM ::SaAnalysiscontext correspond à DSPSIMU Une errer est remontée si ce stéréotype n est appliqé à acn élément Nom Processor «HRM ::Hwprocessor» Description Processer por leqel on effecte l analyse temps réel Ressorce de calcl matérielle Règles Le nom de l élément avec le stéréotype «HRM ::Hwprocessor» correspond a nom d processer Vérification Un avertissement est remonté si ce stéréotype n est appliqé à acn élément Nom Schedler «GRM ::Schedler» Description Ordonnancer d système d exploitation temps réel Ordonnancer d système d exploitation temps réel Règles L attribt «Schedpolicy» d stéréotype correspond à la politiqe d ordonnancement appelé «Schedlingpolicy» dans l otil L attribt «ispreemptible»d stéréotype précise si l ordonnancer est préemptif (variable «preemptible» dans l otil) Vérification Une errer est remontée si acn élément n a ce stéréotype o si l attribt «Schedpolicy» n est pas renseigné Nom Task «SRM ::Swschedlableresorce» Description Tâche logicielle à ordonnancer Contexte de calcl logiqe où la compétition por le processer est déterminée par l ordonnancer. Ressorce qi s exécte de manière concrrente à d atres ressorces Règles Le nom de l élément correspond a nom de la tâche L attribt «deadlineselements» contient la liste d échéances temporelles (tablea alloé de manière dynamiqe portant le nom «Deadline» dans l otil ) L attribt «priorityelements» contient la priorité de la tâche si elle est gérée avec l ordonnancer FP (variable «Prio» dans l otil)

86 3.3 Notre méthodologie de conception 75 L attribt «identifierelements» contient l identifiant de la tâche si elle est gérée par l ordonnancer EDF (variable «Id» dans l otil) L attribt «timeslicelements» contient la liste des temps d exéction (tablea alloé de manière dynamiqe portant le nom «WCET» dans l otil ) L attribt «notificationsresorces» correspond à la liste des tâches sivantes (tablea alloé de manière dynamiqe portant le nom «Nexttask» dans l otil) L attribt «schedler» précise le type d ordonnancer qi gère la tâche (variable «Policy» dans l otil) L attribt «entrypoints» correspond à l intervalle de temps après leqel nos devons activer ne tâche site à l arrivée d n événement (tablea alloé de manière dynamiqe portant le nom «Offset» dans l otil) L attribt «type» précise le sos-type de tâche (variable «Type» dans l otil) L attribt «periodelements» correspond à la psedopériode de certaines tâches (tablea alloé de manière dynamiqe portant le nom «PsedoPeriod» dans l otil) L attribt «messageresorces» correspond à la taille d bffer donc a besoin la tâche por effecter son traitement (tablea alloé de manière dynamiqe portant le nom «BfferR» dans l otil) Vérification Une errer est remontée si l attribt «priorityelements» n est pas renseigné alors qe la tâche est gérée par n ordonnancer FP. Une errer est remontée si «identifierelements» n est pas renseigné alors qe la tâche est gérée par l ordonnancer EDF. Une errer est remontée si ne tâche n a pas a moins ne échéance temporelle, n temps d exéction et son sos-type ne sont pas renseignés. Tablea 3.1 Table de correspondance entre l otillage et MARTE Ces règles ont été implantées en langage ATL. La Figre 3.10 résme le processs de transformation de modèles. Le modèle sorce («Sorce Model») conforme a métamodèle d UML et de MARTE est transformé en n modèle cible («Target Model») conforme a métamodèle de notre otil de simlation. La transformation est définie par le modèle de transformation («Sorce2Target») qi li-même est conforme a métamodèle d modèle de transformation basé sr QVT («QVT-Based langage»). Ce dernier métamodèle avec le métamodèle d UML et de MARTE, pls le métamodèle de

87 Chapitre 3 Contribtions : Méthodologie de conception et otillage 76 notre otil de simlation doivent être conformes a métamétamodèle MOF (Meta-Object Facility). MOF (Meta-Object Facility) Conforms to Conforms to Conforms to UML + MAR TE metamodel QVT-based langage Real-time schedling tool metamodel Conforms to Conforms to Sorce2target Conforms to Sorce Model Transformation Target Model Figre 3.10 Processs de transformation de modèles 3.4 Ordonnancement temps réel et otillage Nos proposons por l analyse exacte des tâches dans ne radio logicielle, ne détermination de la faisabilité par simlation. En pls d modèle de tâche GMF non cycliqe (introdit dans le chapitre précédent), on retrove dans ne radio logicielle des tâches périodiqes pendant n intervalle de temps site à l arrivée d n événement (notamment les tâches qi programment les fréqences porteses). L intervalle de temps et donc le nombre d activations de la tâche pendant cet intervalle varient en fonction de la taille de la trame en entrée. En otre dans ne radio logicielle, les tâches sont somises à des contraintes de précédence. Cette contrainte n a pas été prise en compte dans le chapitre précédent. Le type de tâches rencontré dans ne radio logicielle se représente bien avec le modèle de tâches récrrentes non cycliqes [76] introdit à la site de la pblication de nos travax sr le modèle GMF non cycliqe après de la commnaté temps réel. Cependant, bien qe la techniqe d analyse d ordonnancement por les tâches récrrentes non cycliqes présentée dans [76] a ne complexité psedo-polynomial por les systèmes avec n tax d tilisation strictement inférier à 1, cette analyse ne pet pas être appliqée dans notre cas car, (1) nos considérons des tâches avec contraintes de précédences, (2) nos considérons n système avec ordonnancer hybride (l analyse dans [76] est por des tâches indépendantes dans n système avec ordonnancer EDF), (3) nos relâchons la condition qi consiste à avoir n tax d tilisation strictement inférier à 1 (atrement dit nos ne considérons pas cette hypothèse restrictive).

88 3.4 Ordonnancement temps réel et otillage 77 Por la détermination de la faisabilité par simlation, n ordonnancer hybride pet être représenté avec dex qees contenant les instances de tâches activées et ne horloge représentant la progression d temps. La première qee simle l ordonnancer FP alors la seconde simle l ordonnancer EDF. Lorsq ne tâche est activée, en raison de l arrivée d ne trame (arrivée externe d ne trame, o l arrivée des données venant d ne atre tâche), la tâche est ajotée dans la 1 ère qee si elle doit être ordonnancée par l ordonnancer FP, sinon elle est ajotée dans la 2 ème qee. Typiqement, n qintplet est ajoté dans la qee. Il est composé d temps d exéction de la tâche, son échéance temporelle relative, la taille de bffer de données q elle tilise, de son identifiant por les tâches EDF remplacé par la priorité por les tâches FP, et de la liste des tâches sivantes. Une tâche n active ne atre tâche q à la fin de son exéction. Les instances de tâches dans la 1 ère qee sont triées en fonction de la priorité de chacne d elles. Dans la 2 ème qee les tâches sont triées en fonction des échéances temporelles croissantes. Lorsqe l horloge avance, la stratégie FP consiste à décrémenter le temps d exéction de la tâche en tête de la 1 ère qee, ainsi qe l échéance temporelle de chacne des tâches présentes dans les dex qees. La stratégie EDF consiste à décrémenter le temps d exéction de la tâche en tête dans la 2 ème qee ainsi qe l échéance temporelle de chacne des tâches présentes dans cette qee. Dans les dex stratégies, la taille totale de bffer tilisée sr le processer est mise à jor. Elle correspond à la somme des bffers tilisés par chaqe tâche. Lorsqe le temps d exéction d ne tâche devient pls grand qe son échéance temporelle relative, ceci revient à dire q ne échéance temporelle va être ratée. Lorsqe le temps d exéction devient égal à zéro ceci signifie qe la tâche a fini son exéction. Ainsi, la tâche est retirée de la qee et s il existe des tâches sivantes, elles sont activées. La stratégie EDF n est exéctée qe lorsqe la 1 ère qee est vide. Les trames (telles q elles porraient se présenter dans l air signax radio émis/reçs par les tilisaters) sont générées aléatoirement et distribées dans le temps. Ensite n calcl est effecté por obtenir les dates d arrivées des trames sr le processer d intérêt. Logiqement les trames à émettre sont reçes sr le processer d intérêt avant la date à laqelle la trame doit être dans l air. Le concepter doit donc spécifier la bonne drée d anticipation en tenant compte de la latence globale d système. Il en va de même por ne trame à recevoir qi est reçe a nivea de processer pe de temps après la réception effective de la trame sr l antenne. La Figre 3.11 illstre ce calcl.

89 Chapitre 3 Contribtions : Méthodologie de conception et otillage 78 Signal to send & receive on the air 1 ms Tx 1 ms Rx 2 ms Tx 1 ms Tx data on the 1 ms Tx 2 ms Tx 1 ms Rx 1 ms Tx board ti me Figre 3.11 Dates des trames dans l air et dates des reqêtes sr le processer La Figre 3.12 représente le psedo-code de l algorithme por la détermination de la faisabilité. La fonction «activatetaskwaitingfortimer()» dans le psedo-code permet d activer certaines tâches à des dates précises. Ceci revient à dire qe l activation d ne tâche site à la fin de l exéction d atres tâches o site à l arrivée d ne trame, pet ne pas être immédiate. En effet cette activation pet être programmée à ne date précise. C est le cas de la tâche qi programme les fréqences porteses. Cet algorithme a été implanté en langage C++, intégré sos forme d otil et testé sr n ordinater. L otil est composé de trois parties. La 1 ère partie est n générater aléatoire de trames, qi génère aléatoirement les trames et calcle les dates correspondantes d arrivée des trames sr le processer d intérêt. Cette partie de l otil pet être remplacée par ne génération de trames sivant ne loi de Poisson, o ne loi normale. N ayant pas d information sr la loi d arrivée des trames nos avons considéré cette approche. La 2 ème partie de l otil correspond à l analyse d ordonnancement temps réel proprement dite. Il s agit principalement de la mise en œvre de l algorithme de la Figre Pendant la simlation, les états d processer et la taille totale de la mémoire de données tilisée sont inscrits séparément dans dex fichiers. Lorsq ne échéance temporelle est ratée la simlation s arrête et on pet obtenir la séqence de trames qi nos a entraînée dans cette sitation. La 3 ème partie de l otil est ne simple interface graphiqe, qe nos avons développée sos Visal C++ avec MFC (Microsoft Fondation Class). Le code implanté dans cette partie, lit les dex fichiers générés pendant la simlation et affiche tos les 512 nités de temps l état d processer et la taille totale de la mémoire de donnée occpée. Notons qe, la valer 512, pet être modifiée.

90 3.4 Ordonnancement temps réel et otillage 79 FEASIBILITY DETERMINATION ALGORITHM d = RandomFrameGeneration(); qee q1; // FP schedler qee q2; // EDF schedler time = 0; while(time<=lastframearrivaltime) endwhile time++; for all frame f in d endfor if(time==arrivaltime(d(f))) for each task τ i in task set endfor activatetaskwaitingforexternalevent(); if(time== releasetime( τ i )) activatetaskwaitingfortimer( τ i ); if(emptyqee(q1) and Emptyqee(q2)) endif processorstate = idle; else if (deadlinemissed(q1) or deadlinemissed(q2)) else endif if(emptyqee(q1)) else endif processorstate = deadlinemissed; processorstate = rnning; execteedfstrategy(q2); exectefpstrategy(q1, q2); for each task τ i in dependent task set Γ endfor if (completionoftaskpriorto( τ i )) activate( τ i ); Figre 3.12 Algorithme de détermination de la faisabilité temps réel La Figre 3.13 représente les différentes parties de l otil. Nos vos présentons l expérimentation de cet otil sr n cas d étdes dans le chapitre sivant.

91 Chapitre 3 Contribtions : Méthodologie de conception et otillage 80 Random frames generator Inpts Schedling Analysis otpts files Graphical ser interface Can be easily replaced with a poisson distribtion, or normal distribtion Figre 3.13 Schéma de l otil de vérification de l ordonnançabilité Ainsi, si la validation temporelle est satisfaisante, por n certain nombre de trames générées aléatoirement, le système pet être considéré comme ne bonne soltion. Atrement, les concepters doivent revenir sr l ne des phases PIM, PDM o PSM et changer certaines spécifications. Par exemple, le concepter porrait décider q n processer pls performant est nécessaire, o q il a besoin de pls de mémoire, o qe certaines activités doivent être implantées sos forme matérielle. Le concepter porrait également décider d tiliser n algorithme pls simple afin de rédire la complexité en temps de calcl. 3.5 Conclsion Ce chapitre a considéré et abordé plsiers problèmes rencontrés lors de la conception de radio logicielle. Nos avons présenté dans ce chapitre des méthodes efficaces por : modéliser ne radio logicielle en intégrant des moyens de test d ordonnancement temps réel. De pls nos prenons en compte le novea profil por systèmes temps réel embarqé (MARTE). déterminer la faisabilité temps réel, l occpation d processer, et l occpation de la mémoire, d n ensemble de tâches dans ne radio logicielle implantant des algorithmes de traitement d signal flexibles et s exéctant sr n processer en fonction d ne politiqe d ordonnancement hybride. Les méthodes présentées dans ce chapitre, fornissent ne soltion intéressante a problème qi consiste à développer n grand nombre d algorithmes de traitement d signal sos forme entièrement logicielle dans n éqipement radio logicielle. Les résltats décrits dans ce chapitre ont été présentés dans dex conférences phares de la commnaté radio logicielle et ont fait l objet de la somission d n article dans n

92 3.5 Conclsion 81 jornal. Dans le chapitre sivant nos présentons ne expérimentation de ces méthodes sr n cas d étdes, qi démontre les avantages de notre méthodologie. Nos montrons également le nivea de précision de nos résltats en les comparant ax vrais résltats obtens sr cible.

93 82

94 Chapitre 4 Cas d étdes Résmé : Dans ce chapitre nos effectons ne expérimentation des méthodes proposées dans le chapitre précédent sr n projet afin de démontrer les avantages de notre approche. Le projet consiste en ne implantation de la version mlti-tilisater de la techniqe de modlation OFDM sr ne carte électroniqe contenant a moins n DSP. Nos montrons également dans ce chapitre qe l otil de simlation, développé pendant nos travax, a n bon nivea de précision en comparant les résltats prédits par l otil avec cex réellement obtens sr cible. 4.1 Introdction Dans l optiqe d illstrer notre méthodologie de conception, nos nos sommes appyé sr n projet en cors de réalisation chez THALES Commnications. L objectif d projet est de réaliser ne radio logicielle dont la coche physiqe est basée sr la version mlti-tilisater de la techniqe de modlation OFDM avec évasion de fréqence (sat de fréqence). La techniqe de modlation OFDM est tilisée dans plsiers systèmes tel qe les commnications par corants porters, les systèmes de diffsion adio (DAB) et vidéo (TNT), les systèmes de réseax sans fil (WIFI) etc. Une des raisons qi jstifie cette tilisation est qe l OFDM tilise les sos porteses orthogonales por envoyer et recevoir plsiers symboles de données en parallèle. L n des avantages d sat de fréqence, notamment dans n contexte militaire, est qe le signal est pls difficile à intercepter. Lorsqe nos avons repris ce projet, l évalation de la faisabilité temps réel, avait été effectée de manière empiriqe, i.e. basée sr l expérience des ingéniers. En effet l évalation consistait à estimer sr n fichier «Excel» la charge d processer pendant la phase où certaines tâches effectent des traitements d émission alors qe d atres effectent des traitements de réception. Contrairement, à cette approche nos avons tilisé notre méthodologie présentée dans le chapitre précédent. Notre objectif est d évaler le nombre de modles de traitement d signal qi pevent être déployés sr n processer DSP tot en garantissant le respect de lers contraintes temporelles. Le résltat d ne telle évalation fornit non selement ne garantie sr la faisabilité temps réel des modles de traitement d signal, mais permet assi ne implantation de modles sos forme entièrement logicielle comme visé dans l approche radio logicielle. Por réaliser notre évalation, nos sommes partis des docments de conception déjà réalisés por ce projet. La coche physiqe traite dex types de trames : les trames d ne longer de 2,5 ms et les trames d ne longer de 10 ms. Chaqe trame est sbdivisée en palier. Chaqe palier est émis/reç à ne fréqence portese spécifiqe. Par conséqent 83

95 Chapitre 4 Cas d étdes 84 on sate sr plsiers fréqences à l intérier d ne trame. Par exemple por la trame de 2,5 ms à émettre, si on considère des paliers de 500µs, pendant la drée d émission de la trame (2,5 ms) on va sater totes les 500 µs sr ne fréqence portese parmi 5. L émission et la réception en contin sr l antenne font qe les traitements d modem doivent respecter des contraintes temporelles strictes. C est ne radio logicielle, car plsiers fonctions de traitement d signal sont implantées de manière logicielle. C est par exemple le cas de la fonction qi contrôle la partie modem de l éqipement radio (i.e. la programmation et le séqencement des fréqences porteses et de l amplificater de pissance). Ainsi l éqipement radio pet changer de bande de fréqence grâce à n changement activé par commande logicielle. L éqipement pet également passer en mode écote/srveillance des commnications radio tojors grâce à n changement logiciel. La Figre 4.1 présente les différents blocs fonctionnels mis en œvre dans le modlater et lers relations de dépendances. Les premiers blocs (la partie correspondant ax traitements à l échelle de la trame) sont exéctés ne sele fois par trame. Les derniers blocs (la partie correspondant ax traitements à l échelle d palier) sont exéctés plsiers fois par trame. En effet le nombre de fois où le bloc est exécté correspond a nombre de paliers dans la trame. Traitement à l échelle de la trame Traitement à l échelle d palier SRC CRC COD INT SPR IFFT Emission DST DCRC DECOD DINT DSPR FFT Réception Figre 4.1 Schéma fonctionnel de notre modlater OFDM En phase d émission, les données sont d abord complétées par n code de redondance cycliqe (CRC) qi pet varier de 0 à 24 bits. Ensite les données passent par l étape d codage canal (COD - effecté par n trbo code). Il s ensit n entrelacement (INT) qi a por effet de répartir aléatoirement les errers. L étalement de spectre (SPR) est effecté avec n code d embroillage aléatoire. Enfin la modlation OFDM est effectée grâce à l inverse d ne transformée de forrier rapide (IFFT) avant l envoi des échantillons a transceiver por les conversions nmériqes/analogiqes, l amplification d signal, etc. En phase de réception, nos retrovons les blocs inverses de cex de la phase d émission. Une fois la démodlation effectée avec ne transformée de forrier rapide (FFT), le

96 4.2 Strctre d projet dans l otil de modélisation 85 désembroillage des données est effecté grâce ax code d embroillage (DSPR). Les étapes inverses de l émission se porsivent par n désentrelacement (DINT), n décodage canal, pis ne séparation d code de redondance cycliqe, afin de récpérer les données transmises. Totes les phases de modélisation ont été effectées avec l otil «Rational Software Architectre» (version 7.5.4), en tilisant l implantation d profil MARTE disponible sos licence libre. 4.2 Strctre d projet dans l otil de modélisation Notre projet sr l otil de modélisation est composé de dex modèles : n modèle por la modélisation PIM appelé «Waveforms_PIM» et n modèle por la modélisation PSM appelé «Waveforms_PSM». Tel qe le montre la Figre 4.2, nos proposons n modèle PIM composé de trois packages représentant respectivement l architectre de l application, le comportement de l application, et les différents types des données pls les interfaces tilisées et réalisées par les ports. Dans le modèle PSM, nos avons définis 4 packages. Le package «Deployment» est composé des modles à implanter pls le diagramme qi montre sr qelle cible est implanté chaqe modle. Le package «PIM2PSM_Relation» est composé d n diagramme qi fait la relation entre les modles PIM et les modles à implanter. Le package «Platform» décrit la plateforme, et le package «RealTimeProperties» contient totes les contraintes temporelles. Figre 4.2 Explorater de projet Comme mentionné dans le chapitre précédent la première phase de conception démarre par ne modélisation PIM de l application.

97 Chapitre 4 Cas d étdes Modélisation PIM La Figre 4.3 montre la représentation PIM d nivea en coche. Elle est composée de trois composants : ne coche MAC, ne coche PHY, et n modle INFOSEC. Bien qe nos ayons choisi de le représenter à ce nivea, le modle INFOSEC n est pas n composant d modèle OSI. Il s agit d ne carte de chiffrement qi génère des clés permettant de sécriser la transmission. Les noms a-desss des liens entre les composants correspondent ax interfaces entre les différents composants. Por chaqe interface ne liste de fonctions est définie. La Figre 4.4 montre la représentation PIM d nivea modle de base. Elle est composée de 10 modles de base. Il s agit des algorithmes de codage et de décodage, des modles por l étalement d spectre, des modles por la modlation et la démodlation, d n modle de contrôle de la radio qi permet de contrôler, de programmer la chaîne radio et l amplificater de pissance. Ce modle permet également d obtenir la synchronisation entre les horloges de l émetter et d récepter. Le modle «Secrity» permet la demande des clés de chiffrement. Le modle «WFProcessingCtl» calcle les métriqes. Le modle «Seqencer» dispache les différents types de données (données tiles, fréqences porteses, clé de chiffrement). Figre 4.3 Modélisation PIM (nivea en coche) Un modle de base ne pet pas être raisonnablement divisé en sos modles, par exemple, le modle «Decoding» correspond à n trbo décoder qi li même est composé de dex décoders élémentaires interconnectés entre ex. Les itérations récrrentes entre les dex décoders empêchent ne séparation des décoders élémentaires dans dex nités d exéction différentes (ceci réslterait en ne implantation moins efficace).

98 4.3 Modélisation PIM 87 Figre 4.4 Modélisation PIM (nivea modle de base) Radio Control Secrity Transmitting chain Acknowledgment Figre 4.5 Séqence d ne transmission La Figre 4.5 présente n des diagrammes de séqence qe nos avons réalisés. Ce diagramme représente le comportement des modles de la partie modem de la radio impliqés lors de la phase de transmission. Nos avons ne première partie «Radio Control» qi effecte le séqencement et la programmation des fréqences porteses. La dexième partie «Secrity» permet de réaliser la demande de la clé de chiffrement, afin

99 Chapitre 4 Cas d étdes 88 de sécriser les données. La troisième partie «Transmitting chain» correspond à la chaîne de traitement des données tiles jsq à l envoi des échantillons a «transceiver». La qatrième partie «Acqittal» est n acqittement correspondant a débt de l envoi de la trame dans l air. 4.4 Modélisation PDM La plateforme d exéction de la forme d onde dans le cadre de ce projet est composée d n PowerQicc, d n DSP Texas et d n FPGA Altera. Comme nos nos intéressons à la faisabilité temps réel sr le DSP, nos avons effecté notre expérimentation sr ne carte d évalation DSP qi a les mêmes caractéristiqes qe le processer DSP d projet. Il s agit d ne carte DSP TMS320C6416 avec 1Ghz de fréqence, n cache L1 SRAM de 32Ko, ne RAM L2 SRAM de 1Mo. Nos avons tilisé MicroC/OS-II comme système d exploitation temps réel où nos avons développé (en langage C) a-desss de l ordonnancer natif à priorité fixe, n ordonnancer EDF. MicroC/OS-II permet de créer des tâches dont la priorité va de 1 à 61 (les priorités de 62 et 63 étant réservées por la tâche de fond et la tâche de statistiqe). Le principe est qe pls le nombre est faible pls la priorité est importante. Dans notre implantation, les tâches de priorité 1 à 10 sont gérées par l ordonnancer natif de MicroC/OS-II pendant qe les tâches de 11 à 61 sont gérées par notre ordonnancer EDF. Atrement dit lorsq ne de ces tâches doit être exéctée, les lignes de code qe nos avons rajotées, permettent qe la tâche qi a l échéance temporelle la pls proche soit exéctée. L ordonnancer EDF gère donc conceptellement les tâches de pls basses priorités. Notre modification de MicroC/OS-II coûte, dans le pire cas, 10 µs spplémentaire à chaqe activation d ne tâche EDF, por 51 tâches EDF actives. Por 20 tâches actives, notre modification ne coûte qe 4 µs spplémentaires. Nos précisons qe notre modification ne rajote pas de srcoût lors de l activation des tâches à priorité fixe. Le changement de contexte prend 1 µs. Plsiers de ces paramètres ont été renseignés dans le modèle de la plateforme tel qe spécifié dans la section A titre d exemple la Figre 4.6 illstre comment nos renseignons la valer de la mémoire L2 SRAM dans le modèle.

100 4.5 Modélisation PSM 89 Figre 4.6 Valer de la mémoire L2 SRAM dans le modèle 4.5 Modélisation PSM La Figre 4.7 présente les relations entre les modles PIM et les modles PSM. Figre 4.7 Relation entre les modles PIM et les modles PSM

101 Chapitre 4 Cas d étdes 90 Dans le cadre d projet, qatre modles ont été implantés sr DSP : «Seqencer_impl», «Radiocontrol_impl», «Secrity_impl», «WFProcessingCtl_impl». Por notre expérimentation nos avons considéré sr le DSP en pls de ces 4 modles, les modles «Coding» et «Decoding» qi correspondent respectivement à n trbo coder 1/3 et n trbo décoder. Dans le projet ces modles ont été implantés sr FPGA car a démarrage d projet il était considéré risqé de déployer ces modles sr le DSP à case des problèmes d ordonnancement temps réel. La Figre 4.8 présente notre allocation sr n diagramme de classe. Figre 4.8 Approche graphiqe d allocation de modles Les échéances temporelles des tâches ont été calclées sivant l algorithme décrit en section dans le chapitre précédent. Il fat rentrer dans l otil implanté, le graphe correspondant à la chaîne radio (émission et réception), pis les temps d exéction de chaqe modle, les dates d arrivées por chaqe type de trame et les échéances temporelles absoles correspondantes. On doit également spécifier le processer où chaqe modle est déployé car comme nos l avons mentionné en section 3.3.3, la date de démarrage a pls tôt dépend dans certains cas d déploiement. La Figre 4.9 est ne captre d écran des résltats de l otil de calcl des échéances temporelles por n exemple composé de dex chaînes (émission pls réception) gérant dex types de trames. Chaqe modle a donc dex échéances temporelles. Par exemple les échéances temporelles de «Seqencer» valent respectivement 726 et 452 tandis qe celles de «Secrity» valent 1322 et 1644.

102 4.5 Modélisation PSM 91 Le Tablea 4.1 présente les paramètres temporels des tâches qe nos avons renseignés dans le modèle. Totes les valers sont en microseconde. Les tâches «Seqencer_impl» et «RadioControl_impl» sont gérées avec l ordonnancer FP (nos avons considéré «Seqencer_impl» pls prioritaire qe «RadioControl_impl») alors qe les atres tâches sont gérées avec l ordonnancer EDF. Figre 4.9 Otil de calcl des échéances temporelles Tâche j C i j D i j η i Trame Tâches sivantes implantées sr DSP RadioControl_i mpl Seqencer_impl ControlRadio_impl, Secrity_impl, WFProcessing Secrity_impl Coding_impl Decoding_impl

103 Chapitre 4 Cas d étdes WFProcessing Coding_impl o Decoding_impl (déterminé à l exéction) Tablea er exemple de tâches j j Les paramètres C i et D i représentent respectivement le temps d exéction et j l échéance temporelle de la j-ième trame de la tâcheτ i. Le paramètre η i représente le nombre de fois qe la tâche est activée site à l arrivée de la j-ième trame. La psedopériode de la tâche «RadioControl_impl» vat 500µs. Le temps de garde entre dex j j arrivées sccessives de trames por ne tâche est égale à η i * Di. A titre d exemple, la Figre 4.10 illstre comment nos renseignons les échéances temporelles dans le modèle. Une fois totes les contraintes temporelles renseignées, nos effectons ne transformation de modèle en tilisant l otil de développement ATL IDE, permettant d implanter nos règles en langage ATL (Atlas Transformation Langage). Figre 4.10 Les échéances temporelles dans le modèle 4.6 Transformation de modèles Le langage ATL est basé sr QVT. L otil ATL IDE, permet de spécifier des règles de transformations en langage ATL et d obtenir (après exéction) n modèle conforme a métamodèle (à la sémantiqe) de notre otil d analyse d ordonnancement temps réel. Nos avons réalisé le métamodèle de notre otil avec le langage UML, qi est conforme à

104 4.6 Transformation de modèles 93 MOF et donc par transition notre métamodèle est conforme à MOF. La Figre 4.11 présente le métamodèle qe nos avons réalisé por notre otil. Figre 4.11 Métamodèle de notre l otil de simlation Dans la Figre 4.11, la description qe nos faisons de notre otil est q il est composé d n o plsiers processers, qe chaqe processer possède n et n sel ordonnancer, et qe l otil est composé d n ensemble de tâches. Chaqe tâche possède plsiers attribts. Il s agit de la liste des temps d exéction, la liste des échéances temporelles, la liste des tâches sivantes, le type de la tâche, la psedo-période (si elle en a) etc. Les règles de transformations consistent à «mapper» les concepts MARTE vers les concepts de notre otil d analyse. La Figre 4.12 représente ne captre d écran des règles de transformation d Tablea 3.1 (présenté a chapitre précédent) qe nos avons développées en langage ATL. Le fichier contenant les règles en langage ATL porte le nom «MODEL2DSPSIMU.atl» dans la Figre Les fichiers commençant par «MARTE» proviennent d métamodèle de MARTE et permettent d attriber ne sémantiqe ax éléments de MARTE dans le modèle. Les fichiers «Defalt.profile.ml», «Deployment.profile.ml» et «ProfileBase.profile.ml» proviennent de l otil de modélisation «Rational Software Architectre». Nos précisons qe le format «.ml» correspond a format texte d langage UML, il est basé sr le langage XMI. Le fichier «Waveforms_PIM.ml» correspond a modèle PIM de notre application radio logicielle, tandis qe le fichier «Waveforms_PSM.ml» correspond a modèle PSM. Le fichier «DspSim.ecore» est le métamodèle de notre otil de simlation a format «.ecore», alors qe le fichier «Ot4DspSim.ecore» est le fichier qe nos avons obten après la transformation. Ce

105 Chapitre 4 Cas d étdes 94 fichier est conforme a métamodèle de notre otil. Les fichiers de format «.ecore» sont conformes a métamodèle Ecore de l «Eclipse Modeling Framework» (EMF). Ce métamodèle permet de décrire de manière textelle les modèles et les spports d exéction por les modèles, tilisant le format XMI et ne API (Application Programming Interface) efficace por manipler les objets EMF. Figre 4.12 Règle de transformation en ATL La Figre 4.13 résme le processs de transformation dans l otil ATL IDE.

106 4.6 Transformation de modèles 95 MOF (Meta-Object Facility) Conforms to Conforms to Conforms to UML + MARTE metamodel ATL langage Ecore Conforms to Conforms to Dspsim.ecore Conforms to MODEL2DSPSIMU.atl Conforms to Waveforms_PIM.ml Waveforms_PSM.ml MARTE_Alloc.profile.ml. Transformation Ot4Dspsim.ecore Figre 4.13 Transformation de modèle avec l otil ATL La Figre 4.14 présente n extrait d fichier «Waveforms_PSM.ml» (à gache) et le fichier obten («Ot4Dspsim.ecore») après la transformation (à droite). Figre 4.14 Comparaison entre le fichier iss d modèle et le fichier généré

107 Chapitre 4 Cas d étdes Vérification d ordonnancement temps réel Après la transformation de modèles, nos tilisons l otil qe nos avons développé drant cette thèse afin de valider l ordonnancement temps réel des tâches sr le DSP. L otil lit le fichier généré par ATL (por obtenir les tâches et lers contraintes temporelles), génère aléatoirement trames tel q elles porraient se présenter dans l air, et calcle les dates d arrivées correspondantes des trames sr le processer. Evidemment le nombre de trames pet être modifié. Les trames générées correspondent à n mélange de trames de 2,5 ms et 10 ms (en émission et en réception). Une horloge avance, et les tâches sont activées site à l arrivée des trames, site à la fin de l exéction d atres tâches, o site à l expiration d n «timer». Drant la simlation l état d processer et la taille totale de la mémoire de donnée tilisée sont inscrits dans dex fichiers distincts. Les dex fichiers sont ensite ls et les informations q ils contiennent sont affichées sr ne interface graphiqe. La Figre 4.15 représente l interface graphiqe de l otil qe nos avons développé en langage C++ avec MFC drant ces travax. En hat à gache, nos avons la liste des tâches récpérés d fichier généré par ATL. En hat à droite, nos avons le résltat d test de faisabilité d chapitre 2. Il ne s appliqe dans ce cas car nos n avons pls le même modèle de tâche. En bas à gache, nos avons n graphiqe à barres qi représente l occpation d processer totes les 512 nités de temps. En bas à droite n graphiqe en lignes représente l occpation totale de la mémoire de donnée pendant les mêmes 512 nités de temps. Nos considérons 3 états d processer : l état zéro signifie qe le processer est libre, l état 1 signifie qe le processer est occpé, l état 2 signifie q ne échéance temporelle va être ratée. Figre 4.15 Interface graphiqe de l otil d ordonnancement temps réel