profil UML pour les systèmes embarqués de l`automobile

Transcription

Sébastien Gérard
[email protected]
00 33 (0)1 69 08 90 57
Directeur de Thèse : François Terrier
03/02/2000 ©CEA 1997
profil UML pour les systèmes
embarqués de l’automobile
DEIN/SLA/GLSP et DSIN/EIEV/ISIE : Sébastien Gérard
1
Plan de la présentation
äContexte et besoins
¾ Contraintes imposées par le partenaire industriel
¾ Choix définissant le cadre de travail
ä Présentation de la notion de profil UML
03/02/2000 ©CEA 1997
ä Le profil ACCORD/UML
2
Contexte de travail avec PSA
Le système que nous
voulons construire doit ….
Spécification
Donneur d’ordre
Automobile : Électricité et électronique
1993 : 12% 2005 : 25%
03/02/2000 ©CEA 1997
Produit
Fournisseurs
3
Quelques fonctions pilotées
Sécurité
Confort
Traction
Passive
Commandes
Contrôle moteur
Transmission
Système d'airbags
Prétensionneurs
Equipements
Véhicule
Tenue de route
Active
Communication
Suspension
Contrôle de stabilité
Freinage
Anticollision
Instruments
Audio, Téléphone
Aide à la navigation
Direction
Intrusions
Environnement
Direction assistée
Condamnations
Climatisation
Bruit
03/02/2000 ©CEA 1997
Mobilité
4
Complexité des systèmes
Capteurs
ECM
BVA
-Partage d’informations
-Interactions
-Concurrence...
BSI
Passerelle
Capteurs
ABS/CDS
03/02/2000 ©CEA 1997
SUSP
5
Définition des besoins et objectifs
ä Exprimer des besoins non-ambigus
• Compréhension entre donneur d ’ordre et fournisseurs
ä Maîtriser toute la chaîne de développement
• Spécification du système
• Implémentation sur cibles embarquées
• Validation des modèles produits
03/02/2000 ©CEA 1997
Ð Diminuer les erreurs (ou oublis)
Ð Évaluer les coûts de réalisation
Ð Évaluer les coûts de modification
6
ä Contexte et besoins
¾ Contraintes imposées par le partenaire industriel
¾ Choix définissant le cadre de travail
¾ Définition des extensions de UML
¾ Organisation de ces extensions
03/02/2000 ©CEA 1997
7
Mécanismes d’extension de UML
ä Stéréotypes (Stereotype)
• Ajout indirect d’éléments au méta-modèle
• « thread » ou « process » sur Classifier
ä Valeurs marquées (Tagged value)
• Ajout de propriétés à une méta classe
• {documentation = “ … ” } sur Element
ä Contraintes (Constraint)
03/02/2000 ©CEA 1997
• Ajout ou modification de « Well-Formedness Rules »
• {destroyed}, {new} ou {transient} sur Instance
8
Mécanismes d’extension de UML
ä Stéréotypes (Stereotype)
•Ajout indirect d’éléments au méta-modèle
ä Valeurs marquées (Tagged value)
•« thread » ou « process » sur Classifier
•Ajout de propriétés à une méta classe
ä Contraintes (Constraint)
•{documentation = “ … ” } sur Element
•Ajout ou modification de « Well-Formedness Rules »
03/02/2000 ©CEA 1997
Besoin
de structuration
•{destroyed},
{new} ou {transient} sur Instance
χ notion de profil dans UML 1.3
9
Définition d’un profil UML
ä Objectif
Spécialiser un métaMéta
modèle
standard
(comme UML) servant de
classes
fondamentales
tagged
et
référence en un méta
modèleStéréotypes,
spécifique
dédié àvalues
un domaine
sur lesquelles
repose le profil
introduits
dans
le profil
d’application particulier. contraintes
« Semantics
Variation
Points
» et
ambiguïtés sémantiques de UML
e.g.:
ä Un profil peut contenir…
Système
Mr Dupont
Train
Circuit
• les éléments sélectionnés du méta «modèle
référence,
conducteur
»
e.g.:
?Mr Dupont
• des mécanismes d’extension (ajouts ou spécialisations),
Control
• des notations supplémentaires,
• des règles de transformation, de validation ou de présentation.
03/02/2000 ©CEA 1997
• des descriptions sémantiques du profil,
10
Un modèle à quatre couches
instanceDe
Méta Méta Modèle Méta
(M3) Méta Modèle (M3)
MOF
instanceDe
MOF
...
Entité
...
Méta Modèle (M2) Méta Modèle (M2)
UML
UML
Autres
standards
Autres standards
instanceDe
instanceDe
Classe
instanceDe
instanceDe
Modèle (M1)
Voiture
Modèle (M1)
Objets (M0)
Objets (M0)
une106
03/02/2000 ©CEA 1997
instanceDe
instanceDe
11
Organisation de UML
Méta Méta Modèle (M3)
MOF
...
Méta Modèle (M2)
UML
SPE
...
Real Time
ACCORD/UML
ActionLanguage
Profils standard (M2)
Profils spécifiques utilisateur (M2)
03/02/2000 ©CEA 1997
Modèle (M1)
Objets (M0)
12
Exemples issus du profil ACCORD/UML
ä Règles de présentation
• Choix des diagrammes utilisés dans le contexte du processus de
développement ACCORD/UML
ä Extensions introduites
• Le stéréotype « Real Time Object »
• La valeur marquée {RTC=(dl(x,ms), …)}
• Aspects sémantiques
• Notations spécifiques introduites
• Génération automatique d’un patron de conception
ä Génération automatique du code temps-réel
03/02/2000 ©CEA 1997
ä Le concept de Signal
13
Processus de développement de ACCORD/UML
Analyse préliminaire
Besoins
Cas d’utilisation
Dictionnaire
Système
Système
Système
Analyse détaillée
Train
Circuit
Control
Diagrammes de classe
Diagrammes de séquence
Statecharts
Prototype
Circuit
Control
Diagrammes de classe
Diagrammes de séquence
Statecharts
03/02/2000 ©CEA 1997
Train
14
La notion d’objet actif de UML
anActiveObject
?
???
Code
Méthode
?
methode_1
Messages
Attributs
Messages
• « mono thread »
• comportement Ð
?
03/02/2000 ©CEA 1997
ä Caractéristiques principales de l’objet actif de UML
15
« Real-Time objects »
aRealTimeObject
...
Code
Méthode
Attributs
methode_1
met hode_1
met hode_2
methode_2
Interface
externe
methode_1
Messages
Message processing &
attribute access control
Messages
• « multi threadé » et « temps-réel »
• comportement clairement et complètement défini
03/02/2000 ©CEA 1997
ä Différences majeures avec l’objet actif de UML
16
Le concept de message de UML
ä Définition
Un message définit une communication particulière entre deux
instances participant à la réalisation d’une tâche précise.
ä Un message = une action + un événement
• Appel d’opération (CallAction + CallEvent)
Ð Communication synchrone ou asynchrone de type point à point
Ð Communication asynchrone, …
?
03/02/2000 ©CEA 1997
• Un signal (SendAction + SignalEvent)
17
Les signaux dans ACCORD/UML
ä Communication de type diffusion
• diffusés à tous les objets déclarés sensibles
• envoi Ð destinataire inconnu
• réception Ð émetteur inconnu
ä La réaction à un signal = exécution d’une méthode
ä Peut posséder une contrainte de temps
Real Time Feature:
{RTF = (dl(xxx, ms), rd(xxx, ms), p(xxx, ms), nbPeriod(xxx), endOfPeriod, outOfTime)}
03/02/2000 ©CEA 1997
• à l’émission Ð TV {RTF} sur l’action générant le signal
• à la réception Ð TV {RTF} sur un événement
18
Ajout de « Well-Formedness Rules »
Signal
0..1 +owner
+signal
+raised
1
*
SignalEvent
?
* +feature
Attribute
0..1 +owner
* +parameter
Parameter
SignalEvent
[1] Un événement signal ne possède que des paramètres en entrée.
[2] Un événement de type signal possède autant de paramètre que le signal lui même
possède d’attributs.
self.parameter È size = self.signal.allAttributes È size
03/02/2000 ©CEA 1997
self.parameter È forAll ( p | p.kind = # in)
19
Spécialisation de la notation pour les signaux
OffCar
CarStarter
OffCar
:CarStarter
Regulator
OffCar
{RTC=(dl(100, ms)}
:Regulator
/sendOffCar() {RTC=(dl(100, ms)}
Etat2
03/02/2000 ©CEA 1997
OffCar
Etat1
20
ä Contexte et besoins
03/02/2000 ©CEA 1997
• Aspects liés à la modélisation
• Transformation automatique de modèle
• Génération automatique de code
21
Transformation de modèle, pattern des signaux
_OffCar
+ _Signal()
+ addToListOfTarget ()
+ removeFromListOfTarget ()
+ broadcast()
«use»
OffCar
Regulator
Target
{isAbstarct = true}
listOfTargets
CarStarter OffCar
<<signal>>
OffCar
+ handleSignals()
«use» 0..*
CarStarter
- sendSignal()
Regulator
+ Recepteur ()
+ ~Recepteur ()
+ handleSignals()
03/02/2000 ©CEA 1997
<<signal>>
OffCar
« derive »
22
Dynamique du pattern des signaux
create()
:Regulator
_OffCar
addToListOfTargets(this)
delete()
removeFromListOfTargets(this)
:Regulator
:Target
sendOffCar()
:_OffCar
handleSignals(sig)
delete()
i=1..listOfTargets.size
03/02/2000 ©CEA 1997
create()
23
Passage du modèle à sa mise en œuvre multitâche
Regulateur
calculer
acquérir
loiDeReg
Modèles
calculer
acquerir
Exécution
03/02/2000 ©CEA 1997
Vitesse
24
Un même modèle pour plusieurs implantations TR
Real-Time Objects
«RTO»
Regulateur
maintenir
«thread»
«RTO»
Compteur
acquerir
«thread»
Loop
Multitasking
Regulateur
Lock
Task
maintenir
tacheMaintenir
create
take
release
create
start
Main
Regulateur
maintenir
Compteur
Compteur
acquerir
tacheAcquerir
«RTO»
InterfaceBoutonMA
InterfaceBoutonMA
InterfaceBoutonMA
emettreAppuiBoutonMA
tacheEmettreAppuiBoutonMA
Signal
ACCORD Kernel
MailBox
gererAppuiBoutonMA
ReplyBox
ACCORD Virtual Machine
Specific Code
Generation
03/02/2000 ©CEA 1997
emettreAppuiBoutonMA
«thread»
acquerir
25
Description du modèle utilisateur
PanneauAffichage
«PublicWriter»
InitAffichage(<infoEI)
1-1 portPA
PortPA
OnOff / InitAffichage(dl=50ms)
horsLigne
Class PanneauAffichage
{ public :
PortPA *portPA;
void InitAffichage(EI infoEI)
{ //### code user for InitAffichage ###
majInfoInitVitesse(infoEI.vit) ;
majInfoInitSyst(infoEI.syst);
//############# end #############
}
};
enLigne
03/02/2000 ©CEA 1997
«RealTimeObjects»
26
«RealTimeObjects»
PanneauAffichage
«PublicWriter»
intiAffichage(<pos)
Class PanneauAffichage : public RTO
{ public :
void initAffichage(RTC c, EI infoEI)
{ Request r (iniTask_initAffichage, this, c);
r << pos;
allocateTask( r); }
void iniTask_initAffichage (Request *pr)
{ PanneauAffichage *this = pr->This;
control(pr);
int arg; (*pr) >> arg;
codeTask_InitAffichage(arg);}
void codeTask_initAffichage(EI infoEI)
{ majInfoInitTrain(infoEI.train) ;
majInfoInitSyst(infoEI.syst);}
03/02/2000 ©CEA 1997
Génération automatique du code temps-réel 1/2
27
Génération automatique du code temps-réel 2/2
horsLigne
void handleSignal (OnOff &ev)
{ if (state == horsLigne)
{ RTC c (50);
InitAffichage( c, ev.infoEI);}
}
OnOff / InitAffichage(dl=50ms)
};
03/02/2000 ©CEA 1997
enLigne
28
Intérêt de cette démarche par profil UML
ä Guider
Contrôler
le développement des modèles
Automatiser
ä Gain en qualité, sûreté et en fiabilité des produits issus
d’un tel développement
03/02/2000 ©CEA 1997
ä Amélioration de la maîtrise de développement d’un
produit
29
Travaux en cours…
ä Rédaction d’un profil UML pour le développement de
systèmes temps-réel embarqués dans le domaine automobile
• Thèse
• Projet européen WOODDES
– CEA, PSA, IntraCom, MECEL, I-Logix, Verilog, UPSALA et OFFIS
ä Travaux sur la validation des modèles issus de ce profil
03/02/2000 ©CEA 1997
• Génération automatique de tests
30
Train
Circuit
Control
reformulation
t
n
e L
m
e
M
n
U
n
/
o
D
r
i
R
v
n
O
E
C
C
A
Θ
Agatha
J1 = (Vit=120, dist=150)
J2 = (Reg=true, Vit=55)
…
¬ (Vit < 100 ) ∧ ( dist < 200)
(Reg = true) ∧ (Vit ≥ 50)
…
Tests
03/02/2000 ©CEA 1997
Produit
31

profil UML pour les systèmes embarqués de l`automobile

Transcription

Documents pareils

Direction Informatique : Quel avenir chez PSA

TD Modelisation Vente Par Correspondance

formulaire de don en l`honneur

CS Calcul intensif et grilles de calcul Site

Mohamed Ben Salem

Budget de la recherche le gouvernement Raffarin et la fabrication du

DSIN : CORAIL, un coup d`avance - CFE

UML-2-par-la-pratique-etude-de-cas-et-exercices

Marc François - Iramis