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

Présentation au sujet: "profil UML pour les systèmes embarqués de l’automobile"— Transcription de la présentation:

1 profil UML pour les systèmes embarqués de l’automobile
Sébastien Gérard 00 33 (0) Directeur de Thèse : François Terrier profil UML pour les systèmes embarqués de l’automobile … « Au cours de cette exposé, je vais vous présenter une extension, une spécialisation, de UML pour le développement de systèmes embarquées dans une automobile » …

2 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 Le profil ACCORD/UML

3 Contexte de travail avec PSA
Fournisseurs Donneur d’ordre Le système que nous voulons construire doit …. Spécification ? Produit Automobile : Électricité et électronique 1993 : 12% : 25%

4 Quelques fonctions pilotées
Mobilité Sécurité Confort Traction Tenue de route Direction Passive Active Commandes Communication Intrusions Environnement Contrôle moteur Transmission Suspension Contrôle de stabilité Direction assistée Système d'airbags Prétensionneurs Freinage Anticollision Condamnations Equipements Véhicule Instruments Audio, Téléphone Aide à la navigation Climatisation Bruit

5 Complexité des systèmes
ECM BVA SUSP ABS/CDS BSI Capteurs -Partage d'informations -Interactions -Concurrence... Passerelle Développement des systèmes pilotés Nombre des fonctions Complexité et intégration des fonctions Architectures Nombre des calculateurs Réseaux automobiles (VAN et CAN) Interdépendance des fonctions Développement des systèmes pilotés: Architectures: Diversité: Nombre d’architectures électroniques/véhicule

6 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 Diminuer les erreurs (ou oublis) Évaluer les coûts de réalisation Évaluer les coûts de modification

7 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 Définition des extensions de UML Organisation de ces extensions Le profil ACCORD/UML L’approche OO semble pouvoir apporter des solutions aux besoins précédemment définis. UML apparaissant comme un standard incontournable en la matière de modélisation OO, PSA se tournent naturellement vers cette solution. Cependant, au départ, UML est un langage de modélisation objet généraliste. Il vise le développement de systèmes logiciels en tout genre, de la base de donnée, aux applications Internet en passant par les systèmes temps-réel embarqués. Cependant pour être utiliser au mieux dans un domaine d’application précis, UML doit être quelque peu adapté. (Transparent suivant) …

8 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 Introduction: Or cela est possible car UML contient des mécanismes internes permettant de construire des spécialisation de UML pour ses besoins : les stéréotypes, les valeurs marquées (tagged values) et les contraintes. Exemples de mécanismes d’extension de UML: Classifier « thread » : un processus léger, au sens UNIX, est associé au classifieur (thread) « process » : un processus, lourd au sens UNIX, est associé au classifieur Element {documentation = “ … ” } : spécifie un commentaire, une description ou une explication de l’élément spécifié Instance {destroyed} : l’instance spécifiée est détruite pendant l’exécution {new} : l’instance spécifiée est crée pendant l’exécution {transient} : l’instance spécifiée est crée et détruite pendant l’exécution Contraintes (Constraint) Ajout ou modification de « Well-Formedness Rules » {destroyed}, {new} ou {transient} sur Instance

9 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) Ajout ou modification de « Well-Formedness Rules » {destroyed}, {new} ou {transient} sur Instance Besoin de structuration  notion de profil dans UML 1.3 Introduction: Or cela est possible car UML contient des mécanismes internes permettant de construire des spécialisation de UML pour ses besoins : les stéréotypes, les valeurs marquées (tagged values) et les contraintes. Exemples de mécanismes d’extension de UML: Classifier « thread » : un processus léger, au sens UNIX, est associé au classifieur (thread) « process » : un processus, lourd au sens UNIX, est associé au classifieur Element {documentation = “ … ” } : spécifie un commentaire, une description ou une explication de l’élément spécifié Instance {destroyed} : l’instance spécifiée est détruite pendant l’exécution {new} : l’instance spécifiée est crée pendant l’exécution {transient} : l’instance spécifiée est crée et détruite pendant l’exécution

10 Définition d’un profil UML
Objectif Un profil peut contenir… les éléments sélectionnés du méta modèle référence, des mécanismes d’extension (ajouts ou spécialisations), des descriptions sémantiques du profil, des notations supplémentaires, des règles de transformation, de validation ou de présentation. Spécialiser un méta modèle standard (comme UML) servant de référence en un méta modèle spécifique dédié à un domaine d’application particulier. Méta classes fondamentales sur lesquelles repose le profil Stéréotypes, tagged values et contraintes introduits dans le profil « Semantics Variation Points » et ambiguïtés sémantiques de UML e.g.: Mr Dupont « conducteur » Système Train Control Circuit ? e.g.: Éléments sélectionnés du méta modèle référence: Sélection et description des méta classes les plus intéressantes pour le profil. Des mécanismes d’extensions: Description des stéréotypes, des tagged values et des contraintes introduits dans le profil Des descriptions sémantiques du profil: Il est possible de décrire en langage naturel la sémantique de certains éléments ajouté, des interactions éventuelles entre le profil décrit et d’autres profils déjà existants ou des « Semantics Variation Points » (e.g. pour les machines à états-transitions). Des notations supplémentaires: Les notations déjà définies dans UML (guide des notations UML) peuvent être spécialisées, voire enrichies, pour répondre à des besoins d’expression liés au domaine d’application visé par le profil. Attention, ajouter des possibilités de notation, ce n’est pas ajouter des concepts supplémentaires à UML, c’est en donner une représentation différente pour mettre en valeur une caractéristique précise. Des règles de transformation, de validation ou de présentation: transformation -> spécifier comment passer d’un modèle de niveau n de détail à un modèle de niveau n+1. validation -> vérifier qu’un modèle satisfait certaines propriétés, que des modèles d’un même niveau de détail sont consistants les uns par rapport aux autres, qu’un modèle de niveau n+1 est consistant avec le modèle dont il est issu au niveau n. présentation -> spécifier des filtres de présentation pour les diagrammes utilisé en fonction des phases du développement.

11 Un modèle à quatre couches
instanceDe Méta Méta Modèle (M3) Modèle (M1) Objets (M0) Méta Modèle (M2) MOF UML Autres standards . . . Méta Méta Modèle (M3) Modèle (M1) Objets (M0) Méta Modèle (M2) MOF UML Autres standards . . . instanceDe Entité instanceDe Classe instanceDe EDOC : Entreprise Distributed Object Computing CWM : DataWareHouse Chaque standard de méta modèle couvre un large spectre d ’application. UML, par exemple, s’applique essentiellement au modèle logiciel depuis les SGBDs, les SEs, les applications internet, … Chacun de ces sous-domaines a le besoin de préciser certains concepts de UML ou n ’en utilise qu ’une partie et d ’une façon bien précise. Exple, les deux RFP: Temps-réel et EDOC. L ’objectif des profils est de proposer une présentation et une organisation de ces spécialisation. Voiture instanceDe une106

12 Organisation de UML MOF UML SPE ActionLanguage Real Time ACCORD/UML
Méta Méta Modèle (M3) MOF UML SPE . . . Méta Modèle (M2) ActionLanguage Real Time . . . Profils standard (M2) Profils spécifiques utilisateur (M2) ACCORD/UML La définition de UML repose sur une architecture à quatre couches : M0, M1, M2 et M3. La couche M2 contient la définition du méta-modèle de UML. Cette couche est redécoupée en trois sous-couches. La première sous-couche contient entre autre le méta-modèle de UML. La sous-couche 2 contient des profils standards comme le profil pour le temps réel ou celui contenant la définition du langage d’action de UML. La sous-couche 3 contient les profils spécifiques à un domaine de développement donné, comme celui de WOODDES destiné à l’automobile. Problèmes possibles: Nombre important de profil qui risque d’émerger (trop de standard nuit à la notion même de standard) Liens entre les profils (importations, héritage, utilisation …) Modèle (M1) Objets (M0)

13 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), …)} Le concept de Signal 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

14 Processus de développement de ACCORD/UML
Système Besoins Dictionnaire Train Control Circuit Statecharts Diagrammes de séquence Diagrammes de classe Cas d’utilisation Prototype Analyse détaillée Analyse préliminaire Modèle de pré analyse: diagramme de cas d’utilisation = description des fonctions principales et interactions syst./env. diagramme de séquence = description de la séquence d’interaction syst./env. effectuée pour réaliser un cas d’utilisation diagramme de collaboration = échange de flux entre le syst. (boite noire) et son environnement dictionnaire = description des mots clé du cahier des charges => support de découverte des concepts OO et peut servir pour analyse de traçabilité. Modèle d’analyse et prototype = union de trois modèles: modèle d’interaction -> diagramme de séquence modèle structurel -> diagramme de classes modèle de comportement -> diagramme états-transitions Le modèle de prototype est un modèle issu du modèle d’analyse contenant des détails de conception et d’implantation nécessaire pour construire un prototype du produit attendu de cette spécification. Un tel prototype peut servir de base pour : la validation du modèle d’analyse, des pré études de performance, la communication au sein des équipes de développement (automaticiens, motoristes, …), la communication entre un client (PSA) et ses fournisseurs (équipementiers auto.).

15 La notion d’objet actif de UML
anActiveObject ? ? ? ? ? Messages methode_1 Code Méthode Attributs Messages « mono threadé »: Comportement ? : L’association message entrant et comportement de l’objet est un pb. On ne sait pas clairement ce qu’il se passe. Si on choisi de definir le comportement d’un objet actif via un statechart, il faut encore faire des choix par rapport aux variation semantics points contenus dans la sémantique des machines à états-transitions, et définir clairement le lien entre message et réaction de l’objet. E.g., un message de type appel d’opération va-t-il être perçu comme un événement qui déclenchera éventuellement une transition du statechart ou alors va –t-il déclencher l’exécution de l’opération associé à la méthode appelé??? Caractéristiques principales de l’objet actif de UML « mono thread » comportement  ?

16 « Real-Time objects » Différences majeures avec l’objet actif de UML
aRealTimeObject m e t h o de_2 de_1 . Interface externe Message processing & attribute access control Messages Attributs Code Méthode methode_1 methode_2 « multi threadé » et « temps-réel »: Il peut allouer des ressources de calcul (thread) à ses propres traitements. Il peut donc gérer la concurrence entre ses ressources de traitement. De plus, il est dit temps réel, car il sait gérer des contraintes de temps attachés aux messages qu’il reçoit. Comportement clairement et complètement définit: L’association message entrant et comportement de l’objet est formellement définie => WFRs en OCL. La sémantique du comportement d’un OTR est formellement définie => Semantics Variation Points + WFRs. Différences majeures avec l’objet actif de UML « multi threadé » et « temps-réel » comportement clairement et complètement défini

17 Le concept de message de UML
Définition Un message = une action + un événement Appel d’opération (CallAction + CallEvent)  Communication synchrone ou asynchrone de type point à point Un signal (SendAction + SignalEvent)  Communication asynchrone, … Un message définit une communication particulière entre deux instances participant à la réalisation d’une tâche précise. Dire au sujet du point d’interrogation: D’un point de vue sémantique, ce type de communication possède deux types de problèmes, des points de variation sémantique à compléter (méta attribut target de la méta classe Action) et manque de précision en ce qui concerne le passage des paramètres d’un signal. En effet, un signal en UML peut transporter des informations. Il faut donc formellement décrire un lien entre les arguments de l’action générant un signal, les attributs de la classe du signal qui définit ses paramètres et les paramètres de l’événement engendré par la réception du signal. ?

18 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 à l’émission è TV {RTF} sur l’action générant le signal à la réception è TV {RTF} sur un événement Par rapport aux signaux de UML, on précise d’une part les cibles d’un message par signal. En effet, ceci fait l’objet d’un « Semantics Variation Point » dans la sémantique de UML via l’attribut target de la méta classe SendAction. D’autre part, dans la sémantique des statecharts de UML, un événement de type signal peut déclencher le tirage d’une transition qui entraîne l’exécution d’une séquence d’actions élémentaires. Dans ACCORD/UML, la réception d’un signal déclenche une transition qui déclenche l’exécution d’une méthode de l’objet récepteur. Et le comportement de la méthode est lui même décrit dans un statechart parallèle à celui du comportement global de l’objet. Un signal en ACCORD/UML présente les avantages suivants : Moyen de modéliser les comportements réactifs d'un système, Moyen de faire communiquer des parties du système sans connaissance de l’existence des uns et des autres => pas de lien structurel nécessaire entre les classes des objets qui communiquent par signal d’où un gain en modularité de l’application. Real Time Feature: {RTF = (dl(xxx, ms), rd(xxx, ms), p(xxx, ms), nbPeriod(xxx), endOfPeriod, outOfTime)} 22 25 22

19 Ajout de « Well-Formedness Rules »
? SignalEvent [1]    Un événement signal ne possède que des paramètres en entrée. self.parameter  forAll ( p | p.kind = # in) [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

20 Spécialisation de la notation pour les signaux
OffCar CarStarter Regulator OffCar :CarStarter OffCar {RTC=(dl(100, ms)} :Regulator OffCar /sendOffCar() {RTC=(dl(100, ms)} Etat2 Etat1

21 Plan de la présentation
Contexte et besoins Présentation de la notion de profil UML Le profil ACCORD/UML Aspects liés à la modélisation Transformation automatique de modèle Génération automatique de code L’approche OO semble pouvoir apporter des solutions aux besoins précédemment définis. UML apparaissant comme un standard incontournable en la matière de modélisation OO, PSA se tournent naturellement vers cette solution. Cependant, au départ, UML est un langage de modélisation objet généraliste. Il vise le développement de systèmes logiciels en tout genre, de la base de donnée, aux applications Internet en passant par les systèmes temps-réel embarqués. Cependant pour être utiliser au mieux dans un domaine d’application précis, UML doit être quelque peu adapté. (Transparent suivant) …

22 Transformation de modèle, pattern des signaux
_OffCar « derive » <<signal>> OffCar <<signal>> OffCar + _Signal() + addToListOfTarget () + removeFromListOfTarget () + broadcast() Target OffCar CarStarter {isAbstarct = true} listOfTargets + handleSignals() «use» «use» 0..* Regulator OffCar Regulator + Recepteur () + ~Recepteur () + handleSignals() - sendSignal() CarStarter

23 Dynamique du pattern des signaux
create() :Regulator _OffCar addToListOfTargets(this) delete() removeFromListOfTargets(this) :Regulator sendOffCar() create() delete() :Target handleSignals(sig) i=1..listOfTargets.size :_OffCar

24 Passage du modèle à sa mise en œuvre multitâche
Regulateur calculer acquérir loiDeReg Vitesse Modèles Génération automatique du code Temps-Réel Deux point de vue: - le point de vue, modélisation : L'application est un ensemble d'objets communicants par envois de message. - le point de vue, exécution : L'exécution de l'application est un esemble de tâche supportant l'exécution des appels de méthode. Ces tâches sont activées, syncroniser et ordonnancer par le noyau ACCORD selon les caractéristiques de modélisation, specification des CTR et du parallélisme. acquerir calculer Exécution

25 Un même modèle pour plusieurs implantations TR
Real-Time Objects Multitasking Loop Regulateur maintenir Compteur acquerir InterfaceBoutonMA emettreAppuiBoutonMA «RTO» «thread» Task create start Lock create take release Regulateur maintenir tacheMaintenir InterfaceBoutonMA emettreAppuiBoutonMA tacheEmettreAppuiBoutonMA Compteur acquerir tacheAcquerir Main Regulateur maintenir InterfaceBoutonMA gererAppuiBoutonMA Compteur acquerir MailBox ReplyBox Signal Specific Code Generation ACCORD Kernel ACCORD Virtual Machine

26 Description du modèle utilisateur
«RealTimeObjects» PanneauAffichage Class PanneauAffichage { public : PortPA *portPA; void InitAffichage(EI infoEI) { //### code user for InitAffichage ### majInfoInitVitesse(infoEI.vit) ; majInfoInitSyst(infoEI.syst); //############# end ############# } }; «PublicWriter» InitAffichage(<infoEI) 1-1 portPA PortPA allocateThread resume un thread qui poursuivra l’exécution de la méthode. Des que le thread est alloué, allocate thread rend la main à l’appelant qui s’exécute alors en parallèle. Control fait les verif de concurrence et rend la main quand les attib de l’objet sont dispo. (création de section critique) Decrire le code standard OnOff / InitAffichage(dl=50ms) horsLigne enLigne 49 49 56

27 Génération automatique du code temps-réel 1/2
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);} «RealTimeObjects» PanneauAffichage «PublicWriter» intiAffichage(<pos) 51 58

28 Génération automatique du code temps-réel 2/2
void handleSignal (OnOff &ev) { if (state == horsLigne) { RTC c (50); InitAffichage( c, ev.infoEI);} } }; horsLigne OnOff / InitAffichage(dl=50ms) … série de branchements qui permet de déterminer le traitement à effectuer et sa contrainte de temps associée en fonction de l’état de l’objet récepteur…. enLigne 57 50

29 Intérêt de cette démarche par profil UML
Guider Contrôler le développement des modèles Automatiser Amélioration de la maîtrise de développement d’un produit Gain en qualité, sûreté et en fiabilité des produits issus d’un tel développement

30 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 Génération automatique de tests

31  Modèle ACCORD/UML Modèle Statemate reformulation Environnement
Train Control Circuit Modèle ACCORD/UML reformulation Modèle Statemate Environnement ACCORD/UML Produit Agatha  J1 = (Vit=120, dist=150) J2 = (Reg=true, Vit=55) …  (Vit < 100 )  ( dist < 200) (Reg = true)  (Vit  50) … Tests