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