MARTE : le futur standard OMG pour le développement dirigé par les modèles des systèmes embarqués temps réel Frédéric Thomas, Huascar Espinoza, Safouan Taha, Sébastien Gérard CEA LIST Boîte 94 Gif sur Yvette 91191 {prenom.nom}@cea.fr Résumé Depuis l adoption du standard UML, notamment sous sa deuxième version, ce langage de modélisation a été très largement testé industriellement pour le développement de systèmes embarqués temps-réel (SETR). Fort de cette expérience, UML apparait aujourd hui comme un langage de modélisation très utile, couvrant de multiples besoins mais ne permettant pas de répondre à toutes les spécificités métiers liées au développement de tel système. Le manque d artéfacts pour la quantification du temps, pour la modélisation des ressources d exécution (tâches, sémaphores ) et enfin pour la description rigoureuse d une sémantique d exécution empêchaient jusqu à maintenant sa plus large utilisation dans ces domaines. Ceux-çi nécessitent des langages couvrant aussi bien les besoins liés à la conception que les besoins liés à l analyse des systèmes. Pour répondre à ces besoins, le consortium OMG a d ors et déjà normalisé des extensions à son langage de modélisation universel UML : l extension SPT (Schedulability, Performance and Time) et l extension QoS&FlT (Modeling Quality of Service and Fault Tolerance Characteristics & Mechanisms). Ces extensions ne couvrant pas tous les besoins d un développement dirigé par les modèles, l OMG a récemment émis un nouvel appel à soumission pour une extension nommée MARTE (UML PROFILE FOR MODELING AND ANALYSIS OF REAL-TIME AND EMBEDDED SYSTEMS). Le consortium ProMarte a répondu à cet appel. Bien que cette proposition soit en cours de construction, il est d ors et déjà possible de décrire les principaux concepts qu elle fournit. Il est aussi possible de faire une première comparaison avec d autres langages utilisés dans l embarqué temps-réel tel que le langage de description d architecture : AADL (Architecture Analysis and Design Language).
1. Introduction De part la complexité et l hétérogénéité des systèmes embarqués temps réel (TR/E), leur modélisation reste aujourd hui un exercice difficile qui nécessite des langages de modélisation appropriés. Il est ainsi courant de vouloir modéliser à des niveaux d abstraction différents : la concurrence (ou parallélisme), les contraintes temporelles (i.e. échéance, périodicité, etc.), les contraintes d embarquabilité (i.e. taille mémoire, consommation électrique, etc.), les supports d exécution qu ils soient logiciels (i.e. système d exploitation, intergiciel) et/ou matériels. Récemment, plusieurs consortiums ont normalisés des langages ou des extensions de langages dédiés au domaine de TR/E. Ainsi, le consortium SAE 1 a normalisé un langage de description d architecture (ADL) temps réel : AADL (Architecture Analysis and Design Language) [1]. De même l OMG 2 a d ors et déjà normalisé deux extensions à son langage de modélisation unifié (UML [2]): l extension SPT (Schedulability, Performance and Time) [3] et l extension QoS&FlT (Modeling Quality of Service and Fault Tolerance Characteristics & Mechanisms) [4]. Ces premières extensions ne couvrant pas tous les besoins, l OMG a récemment émis un nouvel appel à proposition (Request For Proposal (RFP)) intitulé MARTE (UML PROFILE FOR MODELING AND ANALYSIS OF REAL-TIME AND EMBEDDED SYSTEMS) [5]. Cet article vise donc dans un premier temps à décrire succinctement les extensions à UML dédiées au temps réel. Dans une deuxième partie il s attachera à présenter la RFP MARTE et une réponse en cours de construction du consortium 1 SAE : Society of Automotive Engineers, http://www.sae.org 2 OMG : Object Management Group : http://www.omg.org ProMarte 3. Cette proposition sera comparée à celles du langage AADL. 2. Les extensions UML pour le temps réel Un profile UML est un mécanisme d extension qui spécialise le langage qu il étend pour un domaine particulier tout en préservant l intégrité des concepts de modélisation originels. Concrètement, un profil UML est donc un paquetage contenant des extensions aux métaclasses UML. Ces extensions sont appelées des stéréotypes. Un stéréotype possède des propriétés (attributs, relations, etc.), nommées définitions d étiquette (tag definition). Dès lors que le stéréotype est appliqué sur une classe du modèle, les valeurs de ces propriétés sont renseignées. Enfin, un profile définit un ensemble de contraintes qui, associées à un stéréotype, clarifient la sémantique d un concept ou précisent des règles d utilisation d une construction du métamodèle. Les cas d utilisation d un profil sont divers : nouvelle terminologie, clarification sémantique, nouvelle syntaxe, règles méthodologiques, annotation des éléments par des propriétés non-fonctionnelles. Pour répondre aux problèmes très spécifiques de domaine TR/E, deux profils UML ont alors été normalisés : SPT et QoS&FlT. SPT vise à définir un ensemble minimal de concepts nécessaires à l analyse des aspects temps-réel d un système. Ces concepts doivent aboutir à la description de modèles à partir desquels l ingénieur doit être capable, soit de produire une implantation, soit d analyser le comportement temps-réel d une application en termes d ordonnançabilité et de performance. Pour ce faire, le profil SPT est constitué de deux sous-profils principaux. Le premier sous-profil concerne la modélisation des ressources générales fournissant une base pour la 3 ProMarte : www.promarte.org
définition de contraintes temps-réel qualitatives (par exemple: échéance, débit, temps d exécution maximale, etc). Le second concerne les analyses d ordonnançabilité classiques (RMA, EDF, etc. [6]), l analyse de performance et l analyse d ordonnançabilité dans le contexte de RTCorba. Le second profil, «QoS et Tolérance aux fautes», fournit un ensemble de concepts pour la prise en compte de la modélisation des aspects de qualité de service et de tolérance aux fautes, en particulier dans le contexte des systèmes temps-réel. En ce qui concerne la qualité de service, ce nouveau profil définit un ensemble de concepts concrets, décrivant un canevas général pout définir la qualité de service dans le profil SPT. Les extensions proposées par ces profils ne sont pas entièrement satisfaisantes principalement pour deux raisons. Premièrement, le niveau d abstraction proposé est insuffisant et inadéquate pour envisager la conception d une application TR/E. En effet, les concepts proposés sont principalement issus des problématiques liées à l analyse. Quelque soit la technique d analyse visée, elle requière généralement des informations quantitative et qualitative supplémentaires à celles disponibles dans un modèle de spécifcaton/conception classique. Ces informations sont donc annotées sur les éléments du modèle pour faciliter la transformation du modèle d une application vers le formalisme d entrée des techniques d analyse. Par exemple, une analyse d ordonnançabilité requiert un modèle de tâche dans lequel l échéance ou le temps d exécution au pire cas est nécessaire. Ces artéfacts de modélisation ne sont pourtant pas toujours adéquates pour des modélisations visant à automatiser le développement des SETR (i.e déploiement de l application sur des supports d exécutions logiciels et matériels hétérogènes, génération de code). La seconde raison est l absence de concept lié au domaine embarqué. Par exemple, il n est pas possible de modéliser facilement des espaces mémoires séparés, une consommation énergétique ou une occupation mémoire d un système. Pour combler ces lacunes, l OMG a donc émis l appel à proposition MARTE. Celleci vise à adresser les deux branches du cycle en V, c.-à-d. celle de la conception ainsi que celle de la vérification & validation. Elle a donc pour objectif de faciliter les échanges entre les intervenants d un projet et entre les outils de développement. Pour cela, les moyens de modélisation proposés doivent aussi bien couvrir les étapes de spécification, de conception, d implémentation, que celles liées à l analyse. Ils doivent assurer la modélisation conjointe des artéfacts matériels et logiciels. Le consortium ProMarte a proposé, en novembre 2005, une réponse initiale. La version définitive est prévue pour mars 2007. Le contenu de cette proposition n est donc pas encore figé aujourd hui. Des disparités pourront donc exister entre ce qui va être présenté par la suite et le standard final. 3. UML-MARTE : la proposition ProMarte La structure de l extension proposée par le consortium ProMarte est illustrée en Figure -1. Un premier paquetage, nommé TCRM, définit de manière générique des artéfacts de modélisation pour la représentation du temps, pour la représentation des propriétés non-fonctionnelles, pour la représentation de la concurrence et pour la représentation des ressources d exécution. Un second paquetage (RTEA) complète le profile SPT pour la description des concepts nécessaires aux analyses d ordonnancement et de performance. Enfin le troisième paquetage (RTEM) définit les concepts utiles à la conception des SETR : modélisation de l application et modélisation des supports d exécution logiciels et matériels.
TCRM (Time, Concurrency and Resources) Causality RTEA (Real-Time and Embedded Analysis) Generic Quantitative Analysis Schedulability NFP Performance Resources Time Allocation RTEM (Real-Time and Embedded Design) HW Resources RT/E Features SW Resources Application Figure -1 Structure de la proposition ProMarte Il serait illusoire de vouloir décrire tous les concepts de cette extension dans cet article. Nous nous concentrons donc par la suite sur la modélisation du temps, la modélisation des propriétés nonfonctionnelles, et la description des supports d exécution. Nous nous efforcerons pour chacune de ces descriptions de faire le lien avec le langage AADL. La modélisation du temps La proposition du consortium ProMarte permet l expression de modèles de temps causaux (i.e. s intéressant à la précédence et aux dépendances entre les instants), de modèles de temps synchrones (i.e. divisant l échelle de temps en une suite discrète d événement où la notion de simultanéité est possible) et des modèles de temps physique (i.e. permettant de définir de manière précise des durées de temps). Ainsi il permet d exprimer des valeurs de temps, des événements dans le temps, des stimuli liés au temps et enfin des mécanismes liés au temps (i.e. des horloges, des réveils ). Il n y a pas à notre connaissance d équivalent dans le langage AADL puisque ce langage vise à décrire l architecture du système TR/E. La modélisation des propriétés nonfonctionnelles Les propriétés d une application sont regroupées traditionnellement en deux catégories : celles propres aux fonctionnalités que doit remplir l application (i.e ce qui est fait à l exécution) et celles liées à la qualification des fonctionnalités attendues (i.e. comment est-ce fait ou comment ce doit être fait). Les premières sont dites fonctionnelles (FP), les secondes non-fonctionnelles (NFP). Les NFPs fournissent des informations sur différentes caractéristiques telles que les délais d exécution, l utilisation de la mémoire, les surcharges d exécution, etc. La Figure -2 illustre la modélisation de ces propriétés avec le paquetage NFP de la proposition ProMarte. Celui-ci s intéresse à formaliser un ensemble d artéfacts de modélisation permettant la description précise et complète des informations nonfonctionnelles. Ce paquetage vise donc à qualifier et à typer de manière standard les propriétés non-fonctionnelles. Pour cela il étend les types de données d UML par les principaux types manipulés dans le TR/E (par exemple : la fréquence, le débit, la consommation). Ces types standards sont fournis sous une forme de librairie que l utilisateur peut importer (i.e le paquetage Basic_NFP_Types de la Figure -2). Par ailleurs, il permet au travers du langage VSL de définir une syntaxe concrète associée à chacun de ces types. VSL permet de décrire des constantes, des variables, des expressions complexes, et des expressions de temps. La notation «contextswitch = (value=8, unit=ms) est un exemple d utilisation de VSL. Elle exprime que pour l instance «uc», le temps de changement de contexte est de 8 us. L utilisateur pourra donc définir ses propres types tout en utilisant une notation standard, ce qui n existait pas auparavant dans UML. «modellibrary» Basic_NFP_Types «enumeration» DurationUnitKind «unit» s «unit» ms {baseunit=s, convfactor=1e-3} «unit» us {baseunit=s, convfactor=1e-6} «profile» SchedulabilityAnalysisModel «metaclass» UML::InstanceSpecification «stereotype» ExecutionEngine «nfp»tickerperiod: Duration «nfp»contextswitch: Duration= (unit= us) «NFP_Type» Duration value: Real unit: DurationUnitKind «apply» UserModel «executionengine» tickerperiod= (value= 1.0) contextswitch= (value=8, unit =us) «executionengine» uc: Controller Figure -2 Un exemple d'utilisation du sousprofile NFP et du langage VSL
Les chapitre concernant l analyse, utilise ces types pour décrire les propriétés nonfonctionnelles les plus utilisés dans le TR/E et ainsi faciliter le lien avec les outils d analyse. Par l intermédiaire des concepts de «properties», AADL permet lui aussi de renseigner des caractéristiques valuées. Tout comme UML, certains types sont déjà définis par le noyau du langage (aadlboolean, aadlinteger, aadlstring ). De nouveaux types de données peuvent également être définis par l utilisateur selon ses besoins. Une syntaxe concrète ainsi que les principales propriétés nonfonctionnelles sont aussi décrites dans la norme. La description de l application La proposition ProMArte propose des artéfacts de modélisation aussi bien pour permettre la modélisation de l application que pour la modélisation des ressources et services offerts à l application par les supports d exécution. Ainsi, il propose des concepts pour la description de l application à un haut niveau d abstraction. Tout comme AADL, il propose un modèle générique de composant (i.e. composant, instance de composant, port de donnée, port d événement, connecteur) permettant de modéliser aussi bien les architectures logicielles et matérielles ce qui n est pas le cas dans UML2 (i.e le concept de composant est lié exclusivement au logiciel). Plus particulièrement il propose des éléments pour modéliser le modèle d exécution de l application et ceci indépendamment des concepts implémentés sur les supports d exécution. Contrairement à AADL, ces modèles d application peuvent être décrits à différents niveaux d abstraction. Ainsi AADL contraints l utilisation des concepts de tâche (thread) et d espace mémoire séparé (Process) pour la description de l application. La proposition de ProMarte laisse beaucoup plus de liberté à l utilisateur qui peut utiliser des niveaux d abstraction comparable à ceux des objets actif d UML ou des objets dits temps réel, par exemple ceux de la méthodologie ACCORD UML [7] (i.e. une tâche par opération de l objet, une boite aux lettres comme mécanisme de communication avec cet objet). Des artéfacts de modélisation sont aussi proposés pour modéliser concrètement les supports logiciels et matériels d exécution. Ainsi, la partie logicielle permet de représenter les ressources d exécution offerte à l utilisateur par les systèmes d exploitation temps-réel embarqué. Ces principales ressources sont celles d exécution concurrentes (i.e. tâches, interruption ), celles d interaction entre les ressources d exécution (i.e. exclusion mutuelle, communication par message, synchronisation) et enfin celles permettant de gérer les ressources matérielles et logicielles (i.e. ordonnanceur, driver ). La Figure -3 représente un exemple d un régulateur de vitesse. L application est décrite puis allouée sur des «Partitions» et des «Process» de la plate-forme d exécution logicielle ARINC-653. Les concepts proposés pour la modélisation de ces ressources logicielles ne sont pas liés à des technologies spécifiques (exemple : semaphore posix, buffer Arinc) mais permettent de décrire ces technologies de manière standard. Même si SAE et ProMarte propose des notions identiques en ce qui concerne le logiciel (des files d exécution («thread»), des espaces mémoire séparés («process») ), ils ne peuvent pas être utilisés facilement de la même manière. Pour exemple le concept de fil d exécution dans le contexte de modélisation de la plate-forme permet de décrire que le support d exécution logiciel fournit des entités qui implémente cette sémantique d exécution. Il ne permet pas, comme le fait un «thread» AADL, de décrire que l application est conçu en différente tâches (i.e. fil d exécution). Pour cela il faut utiliser les concepts proposés dans le sous-profile «Application» décrit précédemment. De cette manière, une application peut être décrite à un niveau
d abstraction plus haut avant d être allouée en tâche par exemple sur la plate-forme d exécution logicielle. Un stéréotype spécifique permet de décrire cette allocation. Ce mécanisme est semblable au «binding» d AADL. La partie matérielle est, quant à elle, séparée en deux vues : une logique qui classifie les ressources matérielles suivant leur propriétés fonctionnelles (i.e. ressource mémoire (RAM, ROM), ressource de calcul (CPU, FPGA), ressource de communication (DMA, BUS)) et une physique qui se concentre sur les propriétés physiques du composant (i.e. : nombre de pattes, boitier ). Tout comme la proposition ProMarte, AADL propose des concepts pour représenter le support matériel. Notons cependant qu ils sont beaucoup moins détaillés du côté d AADL. Par exemple, il n existe pas de représentation physique du support d exécution. CarWithSpeedRegulator isatomic = true direction = out spm:speedometer [1] «msgport» regon: Start [1] isatomic = true direction = out «MemoryPartition» Partition CarSpeedRegulator «flowport» outspeed : Integer [1] Concurrency «HW_Processor» cpu1 : CPU frequency = 200Mhz HW_Platform «flowport» inspeed : Integer [1] «msgport» rp: RegInterface [1] ARINC_Platform <<schedulableresource >> Process isatomic = true direction = in rgm:regulator [1] «msgport» enginecmd: ECInterface [1] Concurrency_Instance partition processes 1 0..* P1 : Partition «HW_Unit» «HW_Cache» level = 2 type = unified memorysize = 512kB «HW_Processor» cpu2 : CPU frequency = 200Mhz «HW_Unit» «HW_Cache» level = 2 type = unified memorysize = 512kB «HW_Bus» issynchronous = true fsb : FSB wordwidth = 64bit «allocate» «allocate» CarWithSpeedRegulator_Instance myspeedregulator : CarSpeedRegulator spm=myspm rgm=myrgm myrgm : Regulator «allocate» t1 : Process t2 : Process «HW_Chip» «HW_RAM» sdram : SDRAM frequency = 66Mhz memorysize = 64MB adresssize = 22bit organization = (4096; 256; 4; 16bit) area = 224mm² nbpins = 54 myspm : Speedometer «allocate» Figure -3 Un exemple d'allocation d'une application sur une plate-forme logicielle puis sur une plate-forme matérielle. 4. Conclusion Dans cet article, notre intention a été d introduire simplement et sans ambition d exhaustivité, certaines parties de la proposition du consortium ProMarte répondant à l appel à soumission MARTE de l OMG. MARTE est une nouvelle extension à UML dédiée au domaine du TR/E. Ainsi après avoir discuté des lacunes des extensions d ors et déjà normalisée par l OMG (SPT, QoS&FlT), nous avons détaillé la modélisation du temps, la modélisation des propriétés nonfonctionnelle et la conception de l application en prenant compte les supports d exécution logiciels et matériels. Cette proposition est toujours en construction et sera soumise au vote en mars 2007. Nous avons proposé un premier rapprochement avec le langage AADL. Etant donné que la proposition ProMarte est en construction, cette comparaison ne se veut ni formelle, ni complète. Elle permet une première approximation de la complémentarité des deux langages et de l effort nécessaire pour exprimer une ou des passerelles de l une à l autre. Cette passerelle n était peut être pas évidente vers UML. Elle devrait être plus aisée à décrire vers UML-MARTE. 5. Références [1] SAE Society of Automotive Engineer, AS5506 Architecture Analysis and Design Language (AADL), 2004 [2] OMG, "UML2.0 Superstructure Specification", 2004. [3] OMG, UML Profile for Schedulability, Performance, and Time, v1.1, formal/05-01-02, 2005. [4] OMG, UML Profile for Modeling Quality of Service and Fault Tolerance characteristics & Mechanisms, ptc/04-09- 01, 2004. [5] OMG, "UML Profile for Modeling and Analysis of Real-Time and Embedded systems RFP", realtime/05-02-06, 2005. [6] A. BURNS, «Scheduling hard real-time systems: a review,» Software Engineering Journal, mai 1991. [7] S. Gérard, C. Mraidha, F. Terrier, and B. Baudry, "A UML-based concept for high concurrency: the Real-Time Object", presented at The 7th IEEE International Symposium on Object-oriented Real-time distributed Computing (ISORC'2004), T. A. a. I. L. J. Gustafsson, IEEE Computer Society, ISBN 0-7695-2124-X, pp 64-67, Vienna, Austria, 12-14 May 2004 2004.