MARTE : le futur standard OMG pour le développement dirigé

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
SAE1 a normalisé un langage de
description d’architecture (ADL) temps
réel : AADL (Architecture Analysis and
Design Language) [1]. De même l’OMG2 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
ProMarte3.
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)
NFP
Time
« import »
« import »
Causality
« import »
« import »
Resources
« import »
« import »
RTEA (Real-Time and Embedded Analysis)
RTEM (Real-Time and Embedded Design)
RT/E Features
Generic Quantitative Analysis
« import »
Schedulability
« import »
Performance
Allocation
« import »
« import »
HW
Resources
« import »
SW
Resources
« import »
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=1 E-3}
«unit» us {baseUnit=s, convFactor=1E-6}
« NFP_Type »
Duration
value: Real
unit: DurationUnitKind
« import »
« profile »
SchedulabilityAnalysisModel
« metaclass »
UML::InstanceSpecification
« stereotype »
ExecutionEngine
«nfp» tickerPeriod: Duration
«nfp» contextSwitch: Duration = (unit= us)
« 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.
« import »
CarWithSpeedRegulator
CarSpeedRegulator
CarWithSpeedRegulator_Instance
isAtomic = true
direction = out
spm:Speedometer
[1]
«flowPort »
outSpeed : Integer [1]
isAtomic = true
direction = in
« flowPort »
inSpeed : Integer [1]
« msgPort »
rp: RegInterface [1]
« msgPort »
regOn: Start [1]
mySpeedRegulator : CarSpeedRegulator
spm=mySpm
rgm=myRgm
rgm:Regulator [1]
myRgm : Regulator
«msgPort »
engineCmd: ECInterface [1]
isAtomic = true
direction = out
« allocate »
mySpm : Speedometer
« allocate »
ARINC_Platform
Concurrency
Concurrency_Instance
partition
1
« MemoryPartition »
Partition
processes
0..*
« import »
<<schedulableResource >>
Process
« allocate »
P1 : Partition
t1 : Process
t2 : Process
« allocate »
HW_Platform
« HW_Processor »
cpu1 : CPU
frequency = 200Mhz
« 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 = 512 kB
« HW_Bus »
fsb : FSB
« HW_Chip »
« HW_RAM»
sdram : SDRAM
frequency = 66Mhz
memorySize = 64MB
adressSize = 22bit
organization = (4096 ; 256; 4; 16bit)
area = 224mm²
nbPins = 54
isSynchronous = true
wordWidth = 64bit
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/0501-02, 2005.
[4] OMG, UML Profile for Modeling Quality
of
Service
and
Fault
Tolerance
characteristics & Mechanisms, ptc/04-0901, 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.