REPUBLIQUE DU BENIN
¤¤¤¤¤¤¤¤¤¤
U N I V E R S I T E D ’ A B O M E Y - C A L A V I ( U A C )
¤¤¤¤¤¤¤¤¤¤
ECOLE POL Y TECHNIQUE D’ ABOME Y -CALA VI (EPAC)
¤¤¤¤¤¤¤¤¤¤¤¤¤
DEPARTEMENT DE GENIE INFORMATIQUE ET TELECOMMUNICATION (GIT)
Option : Réseaux Informatiques et Internet (RII)
MEMOIRE DE FIN DE FORMATION
POUR L’OBTENTION DU
DIPLOME D’INGENIEUR DE CONCEPTION
THEME :
Réalisé par:
Eric Christophe Kouassivi DEGBOE
Superviseur:
Dr. Médésu SOGBOHOSSOU
Maître de mémoire, Enseignant-chercheur à l’EPAC
Année Académique : 2013 - 2014
7ème Promotion
INTEGRATION SOUS UML-STATECHARTS D'UNE IMPLEMENTATION PAR FREERTOS DES APPLICATIONS
TEMPS REEL
SOMMAIRE . . . . i
DEDICACES . . . . i
REMERCIEMENTS . . . . ii
LISTE DES SIGLES ET ABREVIATIONS . . . iv
LISTE DES TABLEAUX . . . . v
LISTE DES FIGURES . . . vii
RESUME . . . ix
ABSTRACT . . . . x
INTRODUCTION GENERALE . . . . 1
I SYNTHESE BIBLIOGRAPHIQUE 5
1 Généralités sur les UML Statecharts . . . . 62 Fonctionnement de FreeRTOS . . . 18
Sommaire
3 La génération de code dans les SETR . . . 25
II MATERIELS ET METHODES 34
4 Approches d’étude et outils . . . 355 Implémentation et principe de fonctionnement . . . 40
6 Test et simulation . . . 48
III RESULTATS ET DISCUSSION 54
7 Résultats obtenus . . . 558 Discussion . . . 61
CONCLUSION ET PERSPECTIVES . . . 63
Bibliographie . . . 65
ANNEXES 69
A Utilisation de QEP . . . 69B Caractéristiques des éléments de FreeRTOS . . . 70
C Utilisation de notre générateur de code . . . 72
D Template Acceleo de génération de code des machines à état . . . 74
ENGLISH VERSION 77
Tables des matières . . . 92A
Mon père Patrick DEGBOE Ma mère Jeanne MEHINTO
Je dédie ce travail pour le rôle que chacun d’entre vous a joué dans mon éducation.
Eric Christophe Kouassivi DEGBOE
REMERCIEMENTS
En préambule à ce mémoire, je souhaite témoigner toute ma recon- naissance à Toi Dieu, le Père Tout-Puissant, Qui m’a permis d’aller jus- qu’au bout, malgré les nombreuses épreuves rencontrées. Que Ta Lumière me guide au quotidien.
J’adresse aussi mes sincères remerciements à toutes les personnes qui, de près ou de loin, ont contribué à l’élaboration de ce mémoire. Je pense particulièrement :
– au Pr. Félicien AVLESSI, Directeur de l’École Polytechnique d’Abomey- Calavi (EPAC) et à tout le personnel administratif ;
– au Prof. Marc Kokou ASSOGBA, Chef du Département du Gé- nie Informatique et Télécommunication (GIT) à l’EPAC, pour son attention envers les étudiants dudit département ;
– au Dr. Médésu SOGBOHOSSOU, maître de ce mémoire, qui a accepté encadrer mes travaux. Ses enseignements de qualité, son oreille attentive, sa patience et ses conseils judicieux m’ont été d’une aide précieuse ;
– à l’enseignant Feu Dr. Sèmiyou A. ADEDJOUMA pour la qualité de ses cours ;
– à tous les professeurs de l’EPAC, et en particulier à ceux qui ont participé à ma formation, pour la richesse de leurs enseignements ; – à mon frère Yannick DEGBOE, mes sœurs Anne DEGBOE et Mi-
chele DEGBOE pour leur soutien sans pareil sur tous les plans ; – à tous mes promotionnaires et amis pour les bons moments passés
ensemble.
LISTE DES SIGLES ET ABREVIATIONS
AADL Architecture Analysis and Design Language ABS Annex Behavior Specification
API Application Programming Interface EMF Eclipse Modeling Framework
FIFO First In First Out
GRAFCET GRAphe Fonctionnel de Commande Etape Transition HRM Hardware Ressource Modeling
IDE Integerated Development Environment
ISAE International Society of Automotive Engineers ISR Interrupt Service Routine
MARTE Modeling and Analysis of Real-Time and Embedded Systems MDA Model Driven Architecture
MDT Modeling Tools
MOFM2T Model to Text Transformation Language MUTEX MUTual EXclusion
NSC Nested Switch Cases
OCL Object Constraint Langage OMG Object Managment Group
PSiCC Practical Statecharts in C/C++
QEP Quantum Event Processor QF Quantum Framework
QM Quantum Modeling
QP Quantum Platform RTC Run To Completion
RTOS Real Time Operating System
SERP Software Eng. Research and Practice SETR Systèmes Embarqués Temps Réel SP State Pattern
SPT Schedulability, Performance and Time SRM Software Ressource Modeling
STT State Transition Table
TURTLE Timed-UML RT-Lotos Environment UML Unified Modeling Language
XMI XML Metadata Interchange XML Extensible Modeling Language
Liste des tableaux
5.1 Liste des stéréotypes SRM choisis . . . 44
A.1 Liste de quelques fonctions de QEP . . . 69
B.1 Liste des paramètres de création d’une tâche . . . 70
B.2 Liste des paramètres d’une queue . . . 71
1 SRM stereotypes selected list . . . 82
1.1 Exemple de représentation d’un état simple . . . 11
1.2 Exemple de représentation d’un état composé . . . 11
1.3 Exemple de représentation d’un état final . . . 11
1.4 Exemple de représentation d’une transition . . . 12
1.5 Exemple de représentation de l’orthogonalité . . . 14
1.6 Exemple de représentation du l’état initial . . . 14
1.7 Exemple de représentation du deepHistory . . . 14
1.8 Exemple de représentation du shallowHistory . . . 15
1.9 Exemple de représentation du join . . . 15
1.10 Exemple de représentation du fork . . . 16
1.11 Exemple de représentation de la jonction . . . 16
1.12 Exemple de représentation du choice . . . 16
2.1 La machine à état complète d’une tâche [2] . . . 20
2.2 Scénario d’exécution d’une interruption . . . 22
3.1 Représentation d’une capture d’écran du générateur de code [3] . . . 28
3.2 Définition de FreeRTOS avec les stéréotypes SRM [3] . . . 29
3.3 Les diagrammes UML utilisés dans l’implémentation de Lennis et Aedo [6] . . . 30
3.4 Aperçu du logiciel QM . . . 31
3.5 Diagramme de paquetage illustrant l’interaction entre le framework temps réel, le RTOS et l’application [21] . . . . 32
5.1 Exemple de représentation d’une ressource concurrente . . 44
5.2 Exemple de représentation d’une ressource d’interruption . 45 5.3 Exemple de représentation d’une ressource partagée . . . . 45
Table des figures
5.4 Exemple de représentation d’une queue . . . 46
6.1 Machine à état du mode montre . . . 51
6.2 Machine à état du mode alarme . . . 51
6.3 Diagramme de classe du système . . . 52
7.1 Circuit de la montre pour la simulation . . . 56
1 State machine mode watch . . . 83
2 State machine alarm mode . . . 84
3 Class diagram of the system . . . 84
4 Circuit of the application . . . 85
Le travail réalisé durant ce mémoire exploite les fonctionnalités du système d’exploitation temps réel FreeRTOS et les machines à état UML (Unified Modeling Language) pour le développement des applications temps réel. Notre proposition a permis de pouvoir obtenir une métho- dologie permettant de modéliser les applications temps réel dans l’envi- ronnement Eclipse avec l’outil Papyrus. Cela a permis donc de pouvoir spécifier en plus des machines à état, les diverses tâches, les ressources partagées, les interruptions et les mécanismes de communication du sys- tème. Nous avons ensuite, grâce à l’outil Acceleo d’Eclipse, créé un tem- plate permettant la génération automatique du code source du modèle construit. Une horloge a été modélisée comme étude de cas pour montrer tout le procédé.
Mots clés : UML Statecharts, FreeRTOS, modélisation de sys- tèmes, génération de code, Eclipse
ABSTRACT
The work realized in this master thesis exploits the features of the real time operating system FreeRTOS and the UML Statecharts for the development of real-time applications. Our proposal has permitted to obtain a methodology for modeling real-time embedded systems in the Eclipse environment with the plugin Papyrus. This has allowed to specify on top of state machines, the various tasks, shared resources, interrup- tions and communication mechanisms of the system. Then, through the Acceleo Eclipse tool, we have created a template for the automatic ge- neration of source code of the model built. A watch has been designed as study case to illustrate the process.
Keywords : UML Statecharts, FreeRTOS, system modeling, code generation, Eclipse
Les systèmes embarqués sont des systèmes électroniques intégrant du logiciel et du matériel, inclus dans des objets ou des systèmes qui ne sont pas perçus comme des ordinateurs par leurs utilisateurs [4]. Les appli- cations les plus connues des SETR (Systèmes Embarqués Temps Réel) sont les systèmes de transport (voiture, avion, train) et les systèmes mo- biles autonomes (robot, fusée, satellite). De même, les systèmes liés à la gestion d’un périphérique (imprimante, souris sans fil), à la mesure (acquisition en temps réel) et les systèmes domotiques (électroménager) sont des systèmes embarqués pouvant posséder des contraintes temps réel liées aux capteurs ou actionneurs utilisés. Enfin, la notion d’embar- qué peut être étendue aux objets portables grand public (cartes à puce, assistants personnel, téléphones mobiles, lecteurs vidéo, consoles de jeu).
Devant assurer de plus en plus de fonctionnalités, ceux-ci sont de- venus de plus en plus complexes. En addition à cette complexité, vient s’ajouter une contrainte liée à la dynamique toute particulière du marché des systèmes embarqués. Cette contrainte oblige les industries à fournir des produits toujours plus novateurs à moindre prix tout en optimisant leurs temps de mise sur le marché (time to market) [23].
Ainsi, plusieurs approches et outils ont été développés pour la concep- tion des SETR. Nous avons les langages de description graphique et tex- tuelle des systèmes (UML Statecharts, ADL, SDL, GRAFCET, Sync- charts, etc), les systèmes d’exploitation temps réel (PREEMPT-RT,
INTRODUCTION GENERALE
Xenomai, RTEMS, FreeRTOS, etc), les outils de génération de code (RHAPSODY, VISUALState, STATEFLOW, Acceleo).
L’association de ces outils permettrait d’améliorer efficacement le dé- veloppement des SETR. Par exemple, les Statecharts présentent un outil très adéquat pour la modélisation de la dynamique des systèmes réac- tifs avec leurs concepts d’abstraction hiérarchique, de synchronisation, de concurrence, etc. [7]. D’un autre côté, les RTOS (Real Time Opera- ting System) permettent de gérer les contraintes liées au temps réel, à l’ordonnancement, à la synchronisation, au partage des ressources, af- franchissant le développeur d’un travail d’adaptation au matériel pour les interfaces de base (PCI, USB, Ethernet...). Et enfin une génération automatique de code à partir des modèles permettrait un gain incroyable de temps de développement. Autrement dit, pouvoir générer le code d’un SETR pour une implémentation sur un RTOS à partir d’un modèle des- criptif du système va améliorer le développement des SETR.
Contexte, justification et problématique
La complexité croissante des systèmes informatiques entraîne des dif- ficultés d’ingénierie pour les systèmes à base de composants, en particu- lier liées à l’optimisation, la validation et à l’analyse des performances et des exigences concernant la sûreté de fonctionnement. Des approches d’ingénierie guidées par des modèles sont de plus en plus utilisées dans l’industrie dans l’objectif de maîtriser cette complexité au niveau de la conception. Ces approches encouragent la réutilisation et l’automatisa- tion du cycle de développement. Elles doivent être accompagnées de lan- gages et outils capables d’assurer la conformité du système implémenté aux spécifications [4]. Ainsi, l’implémentation sur diverses plateformes peut se faire par la génération de codes à partir des mêmes modèles.
Pour gérer cette complexité croissante et augmenter la productivité des développeurs, l’Architecture Dirigée par les Modèles (Le Model Driven Architecture, MDA) [4], un processus de développement proposée par l’OMG (Object Managment Group), offre un cadre méthodologique ou-
tillé aux développeurs des systèmes embarqués, qui se concentrent désor- mais sur l’élaboration de modèles abstraits, plutôt que sur des concepts liés à l’algorithmique et la programmation.
Néanmoins, une utilisation effective du MDA est seulement possible avec des outils et méthodes permettant la transformation des modèles en code source. Parmi les divers diagrammes UML, le plus indiqué pour la modélisation des SETR sont les diagrammes UML statecharts. Le formalisme des statecharts a été introduit par D. Harel et son équipe en 1984 [12]. C’est une extension des MEF (Machine à Etats Finis) et des hypergraphes. Des outils commerciaux permettant la modélisation et la génération de codes tels que Rhapsody et Artisan Studio existent mais n’étant pas Open Source, ils sont indisponibles dans le cadre de recherche à cause de leur cherté. Au-delà du gain de temps de production du code, la génération automatique de celui-ci contribue également à la diminution du temps de correction des programmes écrits à la main tout en permettant la génération de code lisible, maintenable et consistant avec les modèles [23].
Cependant, l’autre aspect de la génération de codes est celui du sup- port qui pour le respect des contraintes d’un SETR doit être un RTOS.
De nombreux RTOS sont disponibles gratuitement, libre comme payant à savoir VxWorks, PREEMPT-RT, Xenomai, RTEMS, FreeRTOS etc.
Du fait du besoin de l’utilisation d’outils open source et gratuits, FreeR- TOS qui est un micronoyau, écrit en langage C et portable sur plusieurs plateformes a été choisi.
Pour avoir une solution complète, il serait utile d’obtenir un sys- tème global dans un seul environnement permettant la modélisation et la génération de code. Eclipse qui est un IDE (Integerated Development Environment) libre, est équipé d’outils de modélisation des diagrammes UML statecharts et d’outils de générations de code.
INTRODUCTION GENERALE
Objectifs
L’objectif principal qui nous amène à l’exploration de notre sujet est la mise au point d’un système permettant de générer le code source à implémenter sous FreeRTOS à base des diagrammes UML statecharts décrivant un système embarqué temps réel dans l’environnement Eclipse.
Plus précisément, il s’agira :
– d’étudier les caractéristiques et les composants des statecharts, ainsi que les propriétés de FreeRTOS ;
– d’étudier les diverses méthodes et outils de transformations des modèles ;
– de relever les insuffisances de ces outils et algorithmes ;
– de trouver des solutions permettant d’améliorer la génération de code ;
– d’implémenter ces solutions dans l’environnement Eclipse.
Le présent mémoire fait le point de nos travaux et comprend trois grandes parties.
Dans la première partie, nous présentons une synthèse bibliogra- phique sur les UML statecharts, FreeRTOS et un état de l’art sur les méthodes de génération de code à partir des modèles UML.
Dans la deuxième partie, nous présentons notre solution aux insuf- fisances de ces outils de génération de code. Cette partie présente donc la méthodologie d’étude adoptée ainsi que les différents choix techniques opérés.
Dans la troisième partie, nous faisons une présentation et une analyse critique des résultats obtenus suite à nos simulations.
Enfin nous conclurons en faisant le point de nos travaux et en pro- posant des perspectives.
Première partie
SYNTHESE
BIBLIOGRAPHIQUE
CHAPITRE 1
Généralités sur les UML Statecharts
Les demandes de plus en plus performantes des SETR ont conduit à une approche différente dans leur conception. Celle-ci passe par la représentation de ces systèmes par des modèles afin de pouvoir décrire le fonctionnement de ces derniers pour une plus grande optimisation et performance.
1.1 Les outils de modélisation de système
L’approche MDA peut être instanciée en utilisant différents langages.
C’est pourquoi un certain nombre de langages formels graphiques de modélisation pour les systèmes temps réel embarqués permettant cette description sont apparus et offrent à ce jour un certain nombre de fonc- tionnalités. Nous allons décrire quelques-uns des plus populaires de ces derniers.
Le langage d’analyse et de description d’architectures (Architecture Analysis and Design Language, AADL) a fait l’objet d’un intérêt crois- sant dans l’industrie des systèmes embarqués critiques (comme Honey- well, Rockwell Collins, l’Agence Spatiale Européenne, Astrium, Airbus) [4]. AADL a été standardisé par la ISAE (International Society of Au- tomotive Engineers) en 2004, pour faciliter la conception et l’analyse
de systèmes complexes, critiques, temps réel dans des domaines comme l’avionique, l’automobile et le spatial. AADL fournit une notation tex- tuelle et graphique standardisée pour décrire des architectures maté- rielles et logicielles. Le succès d’AADL dans l’industrie est justifié par son support avancé à la fois pour la modélisation d’architectures recon- figurables et pour la conduite d’analyses. En particulier, le langage a été conçu pour être extensible afin de permettre des analyses qui ne sont pas réalisables avec le langage de base. Dans cette optique, une annexe au standard AADL a été définie. Il s’agit de ABS (Annex Behavior Speci- fication), utilisée pour compléter les descriptions d’architecture avec du comportement.
Le GRAFCET (GRAphe Fonctionnel de Commande Etape Transi- tion) est né en 1977 des travaux de l’AFCET (Association Française pour la Cybernétique Economique et Technique), en tant que synthèse théo- rique des différents outils existant à cette époque (organigramme, dia- gramme de Girard, réseaux de Petri, etc.). Ce modèle, largement utilisé pour les automatismes logiques représente très clairement les séquences exécutées en parallèle. De plus ce modèle est synchrone ; plusieurs tran- sitions peuvent être franchies simultanément. Des extensions du modèle permettent des descriptions hiérarchisées (grafcets partiels) et si on uti- lise la notion de forçage, il permet de prendre en compte certaines formes de préemptions. Toutefois, la sémantique du GRAFCET n’est pas tota- lement compatible avec celle des langages synchrones.
Le formalisme UML statecharts est une variante des machines à états de Harel basée sur les objets (Norme UML). Les statecharts permettent de modéliser les systèmes réactifs complexes. D’après D. Harel [12] :
Statecharts = diagrammes d’état + hiérarchie + parallélisme + dif- fusion.
Il permet d’exprimer les éléments nécessaires pour la modélisation d’un SETR. Une autre variante des statecharts sont les SyncCharts qui intègrent les concepts de haut niveau des langages synchrones dans un formalisme graphique expressif. Il permet de faire connaitre et d’utiliser le paradigme synchrone dans les milieux industriels. L’un des apports
Chapitre 1. Généralités sur les UML Statecharts
majeurs de la programmation synchrone est justement d’avoir conçu l’aspect séquentiel, le parallélisme et la préemption comme des concepts orthogonaux, c’est-à-dire qu’ils peuvent s’appliquer à tout niveau sans restriction . Il nécessite l’utilisation d’un langage synchrone comme ES- TEREL, capable de donner une sémantique très claire aux programmes mêlant parallélisme et préemption.
1.2 Les diagrammes UML
L’UML est un langage pour documenter et spécifier graphiquement tous les aspects d’un système à logiciel prépondérant [11]. En tant que standard de l’OMG, UML jouit d’une popularité sans précèdant à la fois dans le monde industriel et académique. UML offre une représentation indépendante de tout langage de programmation et de toute méthode de développement.
UML a été accepté comme standard par l’OMG en 1997 à partir de sa version 1.1. La version 1.3 d’UML est sortie en 1999 et la version 1.4 à la fin des années 2000. Cette version comporte neuf (9) types de diagrammes à savoir : Diagramme de classe, Diagramme d’objets, Dia- gramme de composants, Diagramme de déploiement, Diagramme des cas d’utilisation, Diagramme de séquence, Diagramme d’activité, Dia- gramme de Collaboration, Diagramme d’état-transition. Mais, UML 1.4 manque de sémantique formelle. Il manque également des concepts pour les contraintes et propriétés temps réel. Ensuite dans les années 2003, la version 2.0 d’UML est standardisée et apporte les solutions aux in- suffisances de la version précédente. Nous avons ainsi l’apparition des nouveaux diagrammes qui sont : diagramme de structure composite, dia- gramme de paquetages, diagramme de vue d’ensemble des interactions, diagramme de timing, ainsi que l’apparition des diagrammes de machines à état suite à la modification des diagrammes d’état-transition.
1.3 Les profils UML pour le temps réel
Un profil UML est un mécanisme d’extension permettant d’effectuer des extensions courantes sans avoir à modifier le langage de modélisation.
Ainsi, nous avons la possibilité de réaliser des extensions limitées d’UML pour l’adapter à un domaine, une technologie ou une implémentation spécifique. Un profil se compose de différents mécanismes d’extensibilité à savoir :
– des stéréotypes : nouveaux types d’éléments de modèle fondés sur des types de modèles existants ;
– des valeurs étiquetées : éléments d’information désignés, attachés à un élément de modèle. Ils permettent d’ajouter des informations aux classes. Ils peuvent être considérés comme des méta-attributs de la classe ;
– des contraintes : instructions textuelles de la relation sémantique.
Elles permettent d’exprimer les relations entre les stéréotypes et les valeurs étiquetées.
Des profils ont été créés et dédiés à la modélisation des systèmes em- barqués temps réel. Au nombre de ceux-ci, nous avons SPT (Schedulabi- lity, Performance and Time) qui permet d’analyser l’ordonnancement et les performances du système. Le profil TURTLE (Timed-UML RT-Lotos Environment) qui est conçu dans un objectif de validation des systèmes temps réel. Ce profil se caractérise ainsi : premièrement, une sémantique formelle est donnée aux associations entre classes ; deuxièmement, des opérateurs temporels avec délai non déterministe et offre limitée dans le temps sont introduits dans les descriptions de comportement ; troisième- ment, les classes et leurs descriptions comportementales sont traduites en une description formelle en RT-LOTOS, algèbre de processus temporisé supporté par un outil de validation.
Nous avons également un dernier profil très puissant dénommé MARTE (Modeling and Analysis of Real-Time and Embedded Systems) adopté en 2007, pour la modélisation des systèmes embarqués temps réels. Son succès vient du fait qu’il est constitué de plusieurs sous-profils qui traite
Chapitre 1. Généralités sur les UML Statecharts
en détails des aspects des SETR. Parmi ceux-ci, nous avons le sous profil SRM (Software Ressource Modeling) qui permet de créer des APIs afin de pouvoir avoir une sémantique correcte dans nos diagrammes corres- pondant aux particularités du RTOS que nous voulons utiliser. De plus, un sous profil HRM (Hardware Ressource Modeling) s’occupe de la des- cription fonctionnelle du système, ainsi que des équipements physique ; par exemple la vibration, les capteurs, la température, etc.
1.4 Composants des UML Statecharts
Afin de pouvoir modéliser les systèmes, les statecharts sont constitués de plusieurs composants qui permettent de définir chaque aspect de celui- ci.
1.4.1 Les états et les transitions
Les états et les transitions sont les composants les plus utilisés pour représenter les machines à états, car ce sont eux qui décrivent le processus du système
1.4.1.1 Les états
Les états dans un diagramme UML statecharts permettent de savoir à quel niveau se trouve le système, c’est-à-dire le comportement actuel de ce dernier. Ils représentent les composants indispensables dans la mo- délisation d’un système. Un état est représenté par un rectangle à bord arrondi qui est composé d’une partie supérieure contenant le nom de l’état et de la partie inférieure contenant le processus de ce dernier, c’est- à-dire les fonctions qui lui sont associées comme les fonctions d’entrées et de sortie. Nous distinguons les états simples et les états composés. Un état composé est un état qui est composé de plusieurs états simples ou d’états composés appelés sous-états. La figure 1.1 ci-dessous montre la représentation d’un état simple et la figure 1.2 celle d’un état composé.
Figure 1.1 – Exemple de représentation d’un état simple
Figure 1.2 – Exemple de représentation d’un état composé
Afin de représenter la fin de l’exécution du système ou d’un état com- posé d’un type spécial d’état existe est appelé ”état final” (FinalState) représenté à la figure 1.3.
Figure 1.3 – Exemple de représentation d’un état final
1.4.1.2 Les transitions
Les transitions (Figure 1.4) quant à elles permettent de marquer le lien qui fait passer le système d’un état à un autre. Les transitions sont représentées par une flèche reliant les deux états. Une transition peut se mettre sous la forme suivante : A [condition1] /action1. Ce qui se
Chapitre 1. Généralités sur les UML Statecharts
traduit par : Lorsque l’événement A survient, la condition1 est testée.
Si elle est vérifiée alors la transition est franchie et l’action1 associée est effectuée. L’action entraîne généralement la production d’un événement.
Les transitions peuvent être internes, externes ou locales. Une transition interne représente le fait qu’un événement se produisant dans un état, ne produit pas un changement d’état de système mais reste dans cet état lorsque les actions liées à ce dernier sont effectuées. Les transitions locales et externes sont utilisées pour passer d’un super-état à un de ses sous-états. En utilisant les transitions locales, le système reste dans le super-état et passe au sous-état ; mais en utilisant une transition externe, il quitte le super-état avant de repasser au sous-état.
Figure 1.4 – Exemple de représentation d’une transition
1.4.2 Les événements, les conditions de garde et les actions
Ces trois composants, constituent les éléments qui marquent les tran- sitions. Ainsi, ce sont eux qui paramètrent le passage d’un état à un autre.
1.4.2.1 Les événements
Les événements représentent le composant qui déclenche une transi- tion. Nous pouvons avoir plusieurs évènements sur une même transition.
Et il ne faut pas confondre un évènement et son occurrence. Pour expli- quer cela, prenons l’exemple d’une calculatrice : l’appui sur une touche représente un évènement, mais l’appui sur la touche ”1” n’est qu’une occurrence de cet évènement. La norme UML définit également quatre types d’évènement à savoir :
– CallEvent : représente la réception d’une requête de synchronisa- tion pour invoquer une opération spécifique ;
– ChangeEvent : représente un évènement qui survient lorsqu’une expression booléenne devient vraie suite au changement de l’un des attributs ou associations qui la composent ;
– SignalEvent : il représente la réception d’un signal particulier ; – TimeEvent : utilisé pour modéliser l’expiration d’un délai, l’occur-
rence de ce dernier est reçue par la machine à état au même moment que celui-ci est atteint. L’expression définissant le délai peut être relative ou absolue. L’instance de l’évènement n’est générée que si la machine à état se trouve dans l’état en question lorsque le délai est atteint.
1.4.2.2 Les conditions de garde
Les conditions de garde sont des expressions booléennes qui sont rat- tachées aux transitions afin d’y ajouter un contrôle après que celles-ci ont été déclenchées. Lorsque la condition est évaluée, si elle est vraie alors la transition est permise et dans le cas contraire, elle ne l’est pas.
1.4.2.3 Les actions
Lorsqu’un évènement survient dans la machine à état et que la condi- tion de garde si elle est définie a été évaluée à vrai, alors des actions peuvent être effectuées. Ces actions peuvent être le changement de la valeur d’une variable, l’appel d’une fonction, la génération d’un autre évènement, le changement d’état du système etc. Chaque état dispose de deux actions optionnelles à savoir entry et exit qui sont respective- ment exécutées à l’entrée et à la sortie du système de cet état.
1.4.3 L’orthogonalité
Un état composé d’une machine à état peut contenir plusieurs ma- chines à états finis évoluant en parallèle. Le macro-état est dit orthogo- nal : tous les états lui appartenant sont actifs en même temps. La figure
Chapitre 1. Généralités sur les UML Statecharts
1.5 nous montre un exemple d’état orthogonal. Le macro-état est un état de type ET. L’orthogonalité est symbolisée par une ligne pointillée divisant le macro-état.
Figure 1.5 – Exemple de représentation de l’orthogonalité
1.4.4 Les pseudos états
Un pseudo-état est une abstraction qui inclut différents éléments éphémères dans une machine à état (OMG, 1999). Les différents pseudos état d’après la norme UML sont :
– l’état initial (initial) (Figure 1.6) : il représente la source d’une transition simple pour l’état par défaut d’un état composé ;
Figure 1.6 – Exemple de représentation du l’état initial
– l’entrée historique profonde (deepHistory) (Figure 1.7) : elle per- met de garder la configuration d’un état composé qui la contient directement lors de la dernière fois qu’il a été quitté ;
Figure 1.7 – Exemple de représentation du deepHistory
– l’entrée historique peu profonde (shallowHistory) (Figure 1.8) : elle permet de garder le plus récent sous-état actif du super état qui le contient ;
Figure 1.8 – Exemple de représentation du shallowHistory
– la jointure (join) (Figure 1.9) : elle permet de regrouper plusieurs transitions provenant de plusieurs régions orthogonales, toutes les transitions sont déclenchées à la fois ;
Figure 1.9 – Exemple de représentation du join
– la bifurcation (fork) (Figure 1.10) : elle permet de séparer une tran- sition en plusieurs transitions vers des cibles différents, dans ce cas aussi toutes les transitions sont déclenchées à la fois ;
– la jonction (junction) (Figure 1.11) : elle permet de regrouper plu- sieurs transitions, ou de séparer une seule transition en plusieurs autres avec des conditions de garde différentes. Un seul des choix possible est déclenché et une seule fois ;
– le choix (choice) (Figure 1.12) : il permet de paramétrer vers quel état le système doit aller après l’évaluation d’une condition de garde.
Chapitre 1. Généralités sur les UML Statecharts
Figure 1.10 – Exemple de représentation du fork
Figure 1.11 – Exemple de représentation de la jonction
Figure 1.12 – Exemple de représentation du choice
Conclusion partielle
Ce chapitre nous a permis de décrire les diverses méthodes de modé- lisation des SETR et le rôle de la modélisation dans le processus de dé- veloppement. Nous avons également exposé les diagrammes UML, leurs caractéristiques et les profils UML pour le temps réel, particulièrement
le profil MARTE et son sous-profil SRM. Enfin nous avons mené une étude détaillée sur les composants des UML Statecharts. Dans le cha- pitre suivant, nous parlerons des systèmes d’exploitation temps réel et particulièrement de FreeRTOS.
CHAPITRE 2
Fonctionnement de FreeRTOS
Les RTOS permettent de développer de façon plus performante. Ils permettent de pouvoir s’adapter plus aisément aux exigences des sys- tèmes face à leur complexité. En effet, en les utilisant nous ne dévelop- pons plus toutes les pièces de notre application mais utilisons celles qui sont déjà disponibles dans notre RTOS.
2.1 Généralité sur les RTOS
Il existe plusieurs excellentes méthodes établies pour coder des ap- plications embarquées sans l’utilisation d’un système d’exploitation et si le développement du système est simple, alors ces méthodes peuvent apporter la solution la plus adéquate. Dans les cas plus complexes, il est vraisemblable que l’utilisation d’un noyau serait préférable, mais là où les points d’aboutissement seront toujours subjectifs [2].
En effet, un RTOS peut apporter beaucoup d’éléments bénéfiques pour le développement d’une application. Le premier que nous pouvons remarquer est la priorisation des tâches qui permet de pouvoir respecter les deadlines des tâches. Le noyau se charge de la coordination de l’exécu- tion des tâches et fournit des API (Application Programming Interface) à l’application. Cela permet à la structure du code source d’être simple.
Le RTOS permet aussi d’avoir un code source maintenable et modulaire car l’application est scindée en plusieurs tâches ayant chacune un but précis. Cette modularité permet le développement en équipe. Il facilite les tests, et la réutilisabilité du code car les tâches peuvent être testées séparément, et leur code peut être utilisé dans une autre application si nous avons besoin de la même fonction. En utilisant un RTOS, on amé- liore l’utilisation du processeur car les applications sont complètement développées avec le paradigme orienté évènement. Les contraintes de dé- veloppement liées aux exécutions périodiques ou continu, le temps réel dur ou souple et la gestion des périphériques sont efficacement traités par les systèmes d’exploitation temps réel.
2.2 L’utilisation de FreeRTOS
FreeRTOS est un micronoyau écrit en langage C. Il est de petite taille (à peu près 328ko) et peut être utilisé sur divers équipements à savoir les ATMega, les PIC32, les ARM etc. Ce ne sont pas seulement ses performances qui font sa renommée dans la famille des RTOS mais aussi le fait qu’il soit libre et gratuit. Il peut fonctionner en mode préemptif, coopératif ou hybride.
2.2.1 La gestion des tâches
Les tâches sont représentées comme des fonctions C. Si l’équipement sur lequel tourne le programme est monoprocesseur alors une seule tâche peut s’exécuter à la fois. La figure 2.1 ci-dessous, décrit la machine à état complète d’une tâche.
Une tâche peut être dans l’un des deux états : en exécution (Run- ning) ou non (Not Running). Lorsqu’une tâche est dans l’état d’exécu- tion (Running) le processeur exécute son code. Quand il est dans l’état de non-exécution (Not Running), il est inactif et son statut est sauve- gardé pour la prochaine fois qu’il sera exécuté. Ainsi lorsqu’une tâche reprend son exécution, il le fait depuis l’instruction sur laquelle il était
Chapitre 2. Fonctionnement de FreeRTOS
Figure 2.1 – La machine à état complète d’une tâche [2]
avant d’être arrêté. Dans cet état il peut être dans l’un des sous-états suivants :
– bloqué(Blocked) : si elle attend un événement temporel ou de syn- chronisation ;
– suspendu(Suspend) : dans un sous-état la tâche n’est pas disponible pour l’ordonnanceur ;
– prêt(Ready) : lorsque la tâche est prête à être exécuter mais n’est pas encore dans son état d’exécution.
L’ordonnanceur de FreeRTOS est la seule entité qui peut faire passer une tâche d’un état à un autre. Une tâche peut être créée dans la fonction principale de l’application ou dans une autre tâche. La priorité définie pour une tâche lors de sa création peut être changée en cours d’exécution du programme de façon dynamique ou statique. L’application fonctionne
donc en exécutant les différentes tâches qui la composent selon la poli- tique d’ordonnancement définie.
2.2.2 La gestion des files de message
Les applications utilisant FreeRTOS sont composées de diverses tâches indépendantes. Il est vraisemblable que si ces tâches autonomes arrivent à communiquer entre elles collectivement alors elles pourront fournir le fonctionnement utile du système [2]. Le mécanisme de file de message constitue la primitive sous-jacente sur laquelle repose tous les autres mécanismes de synchronisation et de communication.
Une file de message peut contenir un nombre fini de donnée de taille fixée. Normalement, elles sont utilisées en tant que mémoire FIFO (First In First Out) c’est à dire que les données sont écrites à la queue et lu à la tête. Mais elles peuvent être également écrites à la tête de la file. Plu- sieurs tâches peuvent écrire dans une même file et plusieurs peuvent lire dans une même file. Lorsqu’une tâche essaie de lire une donnée dans une file, il est possible de spécifier un temps de blocage. La tâche bloquée est automatiquement passée à l’état prêt lorsqu’une autre tâche ou une in- terruption écrit la donnée qu’elle attendait dans la file. Lorsque plusieurs tâches attendent la même donnée, alors c’est la tâche la plus prioritaire qui y a accès lorsque celle-ci devient disponible. Si plusieurs tâche de priorités supérieures égales attendent la ressource alors c’est celle qui l’attend depuis le plus longtemps qui y à accès d’après le principe de FIFO.
2.2.3 La gestion des interruptions
Les SETR doivent prendre des actions en réponse aux évènements dont les origines sont l’environnement. FreeRTOS n’impose aucune stra- tégie de traitement des évènements au développeur de l’application mais fournit le dispositif qui permet l’implémentation de la stratégie choisie de façon simple et maintenable [2]. Seules les fonctions API (et macros) dont le nom se termine par ”FromISR” ou ”FROM_ISR” sont utilisables
Chapitre 2. Fonctionnement de FreeRTOS
dans les ISR.
Un sémaphore binaire peut être utilisé pour débloquer une tâche à chaque occurrence d’une interruption. Le traitement interrompu est dit déféré vers une tâche de traitement (Handler task). Si le traitement interrompu est particulièrement dans un instant critique, alors la priorité de la tâche de traitement peut être définie pour s’assurer qu’elle puisse préempter toutes les autres tâches. Ainsi, l’ISR retourne directement dans la tâche à manier lorsqu’elle finit son exécution. Pour ce faire, un sémaphore binaire est utilisé entre la tâche de traitement et l’ISR. Ce comportement du système est représenté par l’exemple de la figue 2.2.
Figure 2.2 – Scénario d’exécution d’une interruption
Si une autre interruption survient avant que la tâche de traitement n’est terminée son traitement par la première interruption, alors tout autre évènement survenant sera perdu. Cela peut être évité en utilisant les sémaphores à compte.
2.2.4 La gestion des ressources
Dans un système multitâche, il existe un potentiel conflit si une tâche commence à accéder à une ressource mais ne termine pas l’utilisation de cette dernière avant d’être passé à l’état de non-exécution. Si la tâche
laisse la ressource dans un état inapproprié alors l’accès à cette même ressource par une autre tâche ou interruption peut conduire à une cor- ruption de donnée ou un autre type d’erreur similaire [2]. Pour ce faire FreeRTOS fournit des mécanismes de gestion de ressources afin d’éviter ces genres d’erreurs.
L’accès à une ressource qui est partagée entre plusieurs tâches doit être géré en utilisant une technique d’accès en exclusion mutuelle. FreeR- TOS fournit plusieurs dispositifs permettant l’implémentation de la tech- nique de l’accès en exclusion mutuelle. Pour cela, nous avons les MUTEX qui sont un type spécial de sémaphore binaire. Ils sont très similaires, à la seule différence que les MUTEX incluent un mécanisme basic d’inversion de priorité.
Et pour prévenir les risques d’inter-blocage et d’inversion de priorités FreeRTOS met à disposition les tâches de garde (Gatekeeper tasks). Elles sont des tâches qui sont les seules propriétaires d’une ressource. Elle est la seule autorisée à accéder à la ressource directement et toute autre tâche voulant accéder à cette ressource peut le faire de façon indirecte à travers les services que met à disposition cette tâche de garde.
2.2.5 La gestion de la mémoire
Le système d’exploitation doit allouer dynamiquement de l’espace mémoire à chaque fois qu’une tâche, une file ou un sémaphore est créé.
Divers systèmes embarqués ont des principes d’allocation de RAM et des exigences temporelles variées. Ainsi un algorithme unique d’alloca- tion de mémoire RAM sera seulement approprié pour un sous-ensemble d’application. FreeRTOS permet donc à chaque développeur de fournir son propre principe d’allocation de RAM pour chaque application.
Conclusion partielle
Les RTOS sont comme des boîtes à outils, ils sont composés de plu- sieurs méthodes prédéfinies que nous appelons pour effectuer des tâches spécifiques dans nos applications. Nous avons choisi FreeRTOS car il est
Chapitre 2. Fonctionnement de FreeRTOS
libre, écrit en langage C et très léger. Il nous reste donc à pouvoir l’utiliser efficacement dans le développement de nos applications et l’intégration avec les machines à état. Dans le chapitre suivant, nous discuterons des méthodes de génération de code à partir des machines à état.
CHAPITRE 3
La génération de code dans les SETR
L’un des plus grandes utilités de la modélisation est de pouvoir géné- rer le code à partir des modèles. Cela permet au développeur de système de gagner du temps. De plus, la génération de code conduit à un code plus optimisé et dispense de la routine habituelle de correction d’erreur que l’on rencontre souvent en programmant.
3.1 Généralité sur la génération de code à partir des machines à état
Il existe plusieurs méthodes de génération de code à partir des ma- chines à états UML. Le choix d’une méthode dépend du langage de programmation que nous voulons utiliser dans notre application, ainsi que des performances que nous désirons. Outre les concepts utilisés pour l’implémentation des éléments d’une machine à états (les états, les évè- nements, les transitions, etc.), les patterns de génération de code se dif- férencient essentiellement par la manière avec laquelle ils implémentent le comportement du système vis-à-vis de l’évènement reçu [23]. Les trois patterns les plus utilisés pour l’implémentation des machines à état sont : le NSC (Nested Switch Cases), le STT (State Transition Table) et le SP (State Pattern).
Chapitre 3. La génération de code dans les SETR
Le NSC est le pattern de génération de code le plus simple des ma- chines à état. Les composants de la machine à état à savoir les états et les transitions sont généralement représentés par des énumérations. L’im- plémentation consiste à l’utilisation de deux Switch/Cases imbriqués, le premier Switch/Cases détecte la valeur de l’état courant parmi la liste des états de la machine à état, le deuxième Switch/Cases détecte l’évène- ment reçu. Ainsi, à chaque combinaison d’un état et d’un événement, la transition sortante de l’état courant, déclenchée par l’évènement reçu est exécutée, l’état courant change ainsi de valeur. Nous remarquons donc que la génération de code à partir de ce pattern est relativement simple.
Mais, il ne promeut pas la réutilisabilité du code car chaque élément d’une machine à état doit être codé spécialement pour chaque problème, le code devient très peu lisible dès que le nombre d’états atteint quelques dizaines, et le code n’est pas facilement maintenable.
Le but des deux Switch/Cases imbriquées du pattern NSC est de chercher la transition à franchir selon l’évènement reçu et l’état courant du système. Une manière évidente de faire correspondre à un couple de valeurs (état/évènement) une troisième valeur (la transition à franchir) consiste à créer un tableau à deux dimensions. C’est le principe adopté par le pattern STT. Le code produit par ce pattern est donc plus com- pact et il suffit d’une simple lecture dans le tableau liant les états aux évènements pour trouver la transition à franchir. Mais, le tableau peut s’avérer être une perte de mémoire si la machine à état possède peu de transition par état. L’implémentation des machines à état avec des conditions de garde sur les transitions est rendues également très difficile car une simple lecture ne suffit plus mais également un test sur toute les conditions de gardes.
L’approche orienté objet pour implémenter les machines à état est le SP. Il permet à un objet de modifier son comportement quand son état interne change. L’idée principale de ce pattern est d’introduire une classe concrète Contexte et une classe abstraite State à partir de laquelle dé- rivent des classes concrètes implémentant les états de la machine à états UML. La réception des évènements et le changement de l’état courant est
géré par la classe Contexte. Quand l’instance Contexte reçoit un évène- ment, elle le délègue à l’état concret courant via la classe abstraite State.
L’état courant exécute le comportement et appelle la méthode changeS- tate() de la classe Contexte. Le code généré par cette implémentation est bien structuré et lisible mais a un poids plus lourd dû au fait que les états sont représentés par des classe au lieu de simple énumération. De plus, il ne peut être implémenté que par les langages orienté objet ce qui exclut déjà le langage C qui est quand même l’un des plus utilisé dans le domaine des systèmes embarqués.
3.2 Les générateurs de code à partir des machines à état
Des travaux auparavant se sont déjà penchés sur la génération de code à partir des machines à état. Plusieurs directives ont été choisies par ces derniers et des solutions diverses ont été développées. Parmi celles-ci, nous allons énumérer certaines qui ont attiré notre attention.
Van Hon BUI [3] a développé un générateur de code qui traduit les machines à état en code source JAVA. L’interface de son application est représentée par la figure 3.1. Son générateur comprend un scanner, un analyseur syntaxique et le générateur de code. Le scanner est un simple lecteur qui lit le code source pour produire une structure de données plus proche du code source. L’analyseur syntaxique utilise les données fournies par le scanner et les réorganise en une structure intermédiaire plus logique et facile à utiliser. Le générateur, appelé aussi générateur de code cible, récupère les données fournies par l’analyseur et produit le code cible. Son générateur de code utilise l’approche orientée objet SP pour l’implémentation des machines à état. Son générateur prend en entrée un fichier contenant la définition de la machine à état. XMI (XML Metadata Interchange), est un standard créé par l’OMG pour l’échange d’informations de métadonnées UML basées sur XML.
Il permet de décrire des objets sous forme XML. Il est utilisé comme standard d’échange entre différents outils de modélisation [3].Les princi-
Chapitre 3. La génération de code dans les SETR
Figure 3.1 – Représentation d’une capture d’écran du générateur de code [3]
paux éléments des machines à état sont traités par son système. Certains détails restent non traités comme la gestion du temps par exemple. Ainsi, son système a quelques limites. De plus, utiliser le SP pour l’implémen- tation nous empêche d’utiliser les langages non orientés objets comme le C.
L. Lennis et J. Aedo [6] ont développé un générateur de code C pour FreeRTOS basé sur le profil UML MARTE. Ce qui leur a valu une pré- sentation en 2013 lors de la conférence internationale SERP (Software Eng. Research and Practice). Dans leurs travaux, ils ont utilisé les outils intégrés à l’environnement Eclipse soit Papyrus pour la modélisation des diagrammes UML et Acceleo pour le template de génération de code.
Afin de générer le code C pour FreeRTOS, ils se sont basés sur le sous- profil SRM de MARTE. SRM permet de décrire la plateforme logicielle sur lequel le système doit s’exécuter ; dans ce cas il s’agit de FreeRTOS.
Ainsi, en sélectionnant les quatre (4) stéréotypes suivant ”swSche- dulableResource”, ”messageComResource”, ”interruptResource” et ”En- tryPoint”, Ils permettent respectivement d’indiquer la concurrence, la communication, les interruptions et la routine d’exécution pour les res- sources concurrentes. L’utilisation de ces stéréotypes est décrite dans la figure 3.2.
Leur méthode consiste à utiliser les diagrammes de classe pour définir
Figure 3.2 – Définition de FreeRTOS avec les stéréotypes SRM [3]
les attributs et les opérations des entités structurelles de l’application, les diagrammes d’activité pour spécifier l’aspect dynamique du modèle ainsi que le corps des méthodes pendant que les machines à état sont utilisées pour modéliser le comportement des classes réactives (Figure 3.3).
Mais, les machines à état UML ne sont pas totalement prises en compte car par exemple les transitions ne sont déclenchées que par l’oc- currence d’un événement.
Il existe également des outils et logiciel permettant la modélisation et la génération de code à partir des machines à état. A part les outils propriétaires tels que Rhapsody, Artisan Studio et VisualState dont les sources sont fermées et sont trop couteuses pour l’acquisition dans notre travail actuel. Ils utilisent le plus souvent la méthode NSC ou STT.
Le code généré est compact mais difficile à la compréhension. Ils sont adaptés pour générer des objets ayant un comportement simple [3].
Il y aussi QP (Quantum Platform) qui est un framework open source et disposant de nombreux avantages et permettant d’accroitre la rapi- dité et l’efficacité dans le domaine des SETR grâce à son logiciel de modélisation et de génération de code QM (Quantum Modeling).
Chapitre 3. La génération de code dans les SETR
Figure 3.3 – Les diagrammes UML utilisés dans l’implémentation de Lennis et Aedo [6]
3.3 Présentation de QP
«Pendant plusieurs années, j’avais cherché à voir un livre ou un ma- gazine d’article qui décrirait une véritable méthodologie pratique pour coder les machines à état moderne (UML Statecharts) dans un langage de programmation courant comme le C ou le C++. Je n’ai jamais trouvé une telle technique» cite le Dr. Miro Samek dans son livre PSiCC (Prac- tical Statecharts in C/C++ : Quantum Programming for Embedded Systems). C’est en 2002 le Dr. Miro SAMEK a écrit le livre PSiCC qui était le premier livre à fournir ce qui manquait dans le domaine. C’est- à-dire une implémentation efficace des UML statecharts en C et C++.
PSiCC est également le premier livre à offrir le code source C et C++
d’un framework générique pour les applications temps réelle basées sur
les machines à état. La deuxième version du livre sort en 2008 et le fra- mework a été amélioré ainsi que son organisation, et est dénommé QP.
QP est une plateforme utilisée dans le développement des applications embarquées temps réel à partir des machines à état. Il est pour ce fait composer d’un processeur d’évènement dénommé QEP (Quantum Event Processor) et d’un framework gérant les aspects temps réel des systèmes dénommé QF (Quantum Framework). Un logiciel de modélisation et de génération de code dénommé QM accompagne également tout cet en- semble tout un aperçu est présenter au niveau de la figure 3.4. Mais, l’outil de modélisation des machines à état ne comporte pas tous les élé- ments des UML statecharts. En effet, les seuls éléments disponibles avec son outil de modélisation sont, les états, les transitions et les pseudos état de choix, d’entré historique et l’état initial.
Figure 3.4 – Aperçu du logiciel QM
QEP est un processeur d’événements hiérarchique générique, efficace et hautement portable qu’on peut utiliser dans n’importe quel environ- nement orienté événement, tels que les systèmes ayant une interface gra- phique, des jeux informatiques, ou les systèmes embarqués temps réel.
QEP met tout en œuvre pour être conforme à la spécification UML,
Chapitre 3. La génération de code dans les SETR
mais il ne peut pas vraiment mettre en œuvre l’ensemble des éléments du paquetage UML des machines état. Au lieu de cela, la stratégie de conception de QEP est de fournir juste assez d’éléments vraiment es- sentiels pour permettre directement la construction de machine à état de base et soutenir les concepts UML haut niveau à travers les modèles de conception. Ce processeur d’événement a été construit en tirant la meilleure partie des trois méthodes d’implémentation des machines à état à savoir : le NSC, le STT et le SP. Ce qui fait donc de lui une im- plémentation des machines à état plus puissante que l’utilisation de ces méthodes séparément.
De plus, QEP a un très faible encombrement RAM / ROM. Un objet de la machine à état ne nécessite qu’un seul pointeur de fonction dans la mémoire vive. Ce qui est très bénéfique car nous savons à quel point les mémoires vive et de stockage sont petites dans le domaine des systèmes embarqués. Ainsi, QEP permet de représenter l’implémentation d’une machine à état d’une façon très efficace, lisible et maintenable.
D’un autre côté, QF se charge de gérer l’exécution concurrente des machines à état. QF peut garantir que votre application est libre des
Figure 3.5 – Diagramme de paquetage illustrant l’interaction entre le framework temps réel, le RTOS et l’application [21]
risques traditionnels de préemption dans les systèmes multitâches tels
que l’inter-blocage, l’inversion de priorité, la famine, et le non détermi- nisme. Particulièrement, vous n’aurez jamais besoin d’utiliser les MU- TEX, les sémaphores, les moniteurs ou autre pénible mécanisme au ni- veau de votre application [21]. L’utilisation du framework temps réel se fait en se basant sur un RTOS de notre choix. La figure 3.5 montre les relations entre l’application le framework et le RTOS.
Conclusion partielle
Dans le processus de génération de code à partir des machines à état, plusieurs méthodes existent. Dans ce chapitre nous avons exposé les trois diverses méthodes les plus utilisées. Notre attention s’est le plus portée sur QEP qui a combiné et amélioré ses diverses méthodes.
Deuxième partie
MATERIELS ET
METHODES
CHAPITRE 4
Approches d’étude et outils
L’implémentation des UML statecharts nous pose d’abord le pro- blème de l’environnement dans lequel nous installerons l’outil de modé- lisation à utiliser puis de l’outil de génération de code. Notre méthode consiste à utiliser l’outil de modélisation Papyrus pour représenter nos diagrammes UML et l’outil de génération de code Acceleo qui sont tous deux des plugins intégrés à l’environnement Eclipse. Le code à générer se basera sur FreeRTOS. Dans ce chapitre, nous présentons la méthodologie d’étude ainsi que les différents choix techniques opérés dans l’implémen- tation de notre solution.
4.1 Eclipse, les outils de modélisation et de génération de code
Eclipse est un IDE open source, très connu et utilisé dans la com- munauté informatique. Il existe plusieurs versions et modèles d’Eclipse.
Pour nos travaux, nous allons utiliser la dernière version qui est baptisée LUNA, plus précisément l’Eclipse MDT (Modeling Tools) qui regroupe les divers plugins dont nous avons besoin pour travailler avec les mo- dèles UML. Il dispose en son sein de plusieurs outils de modélisation et de génération de code.
Chapitre 4. Approches d’étude et outils
4.1.1 Les outils de modélisation
Dans le but de pouvoir représenter les modèles UML, plusieurs ou- tils de modélisation ont été développés. Parmi ceux qui sont intégrés à la plateforme Eclipse, nous pouvons citer Papyrus et Topcased. Pa- pyrus s’appuie sur l’implantation EMF (Eclipse Modeling Framework) du méta-modèle UML2 considéré comme étant l’implantation de réfé- rence en termes de gestionnaire de modèles UML2. L’objectif du projet Papyrus open-source est double : premièrement, Papyrus vise à offrir une implantation complète, efficace, robuste et méthodologiquement du standard UML2, ainsi que de ses deux extensions majeures, SysML et MARTE ; deuxièmement, Papyrus est un outil ouvert et flexible pour la définition et l’utilisation de langages de modélisation de domaines spé- cifiques, grâce à une mise en œuvre très avancée du concept de profils UML.
Topcased développé par un consortium avec entre autre Airbus France, CNES, et Thalès, est un environnement de modélisation complet, qui possède un éditeur UML (GEF UML Editor), et de nombreux outils liés à l’ingénierie dirigée par les modèles comme la simulation d’exécution, la validation, la traçabilité des exigences, etc... [24]. Cependant, ces deux outils autrefois concurrents ont fusionné pour obtenir Papyrus MDT, qui en est à sa version 1.0 lors de la réalisation de nos travaux. Ainsi, les fonctions de ses deux puissants outils sont combinées en un seul projet.
Ce qui fait de lui un outil très complet pour la modélisation de nos dia- grammes UML et qui justifie son choix pour la modélisation des UML Statecharts dans nos travaux. Il permet la validation des modèles, leur simulation avec l’outil MOKA qui lui est intégré. La validation se base sur les contraintes OCL (Object Constraint Langage) qui est le langage sémantique utilisé par UML, la simulation se base sur Alf et fUML. Mais en travaillant avec les machines à état UML pour la génération automa- tique de code, les contraintes et les corps des fonctions sont souvent directement écrits dans le langage cible ce qui ne permet pas avec l’état actuel des travaux autour de papyrus MDT de faire les simulations de
nos machines à états.
Il existe encore beaucoup d’autres modeleurs UML, comme ArgoUML, starUML, etc. Ces outils, bien qu’ils puissent être de très bonne qualité, sont généralement moins complets et moins aboutis que ceux cités ci- dessus [24].
4.1.2 Les outils de génération de code
La génération de code consiste en une transformation du modèle source en un autre modèle cible. Une transformation est une généra- tion automatique d’un modèle cible à partir d’un modèle source selon une définition de transformation. Une définition de transformation est un ensemble des règles de transformation qui décrit comment un modèle source peut être transformé en un modèle cible [15].
Les modèles UML représentés par les outils de modélisation sont sto- ckés dans un format de fichier standard dénommé XMI pour pouvoir être interchangeables entre les divers outils de modélisation. Deux principales approches sont identifiées dans les littératures pour la génération de code dans le contexte des conceptions basées sur les modèles : l’approche à base de visiteur, et la génération de code basée sur les templates [6].
L’approche à base de visiteur consiste à utiliser un langage de program- mation comme le langage Java pour parcourir le fichier XMI du modèle afin de générer le code correspondant à chaque élément rencontré dans le fichier. D’autre part, les templates sont des fragments de code compo- sés de texte statique et de texte paramétré. Les textes paramétrés sont remplacés dans le processus de génération par le code adéquat dans le langage cible qui a été défini. La technique basée sur les templates est plus avantageuse que celle basée sur les visiteurs car les templates sont très semblables au code à générer et ils sont compréhensibles et facile à construire.
Les outils de génération de code intégré à la plateforme Eclipse basés sur les templates sont Acceleo, JET et Xpand. Nous choisirons Acceleo car il est basé sur la norme MOFM2T (Model to Text Transformation Language) et les modèles UML 2.X construis avec divers outils de mo-
Chapitre 4. Approches d’étude et outils
délisation sont compatibles avec lui. Nous l’utiliserons dans sa version 3.3.
Acceleo est un outil de transformation modèle vers texte (son déve- loppement a commencé en 2006) ; son objectif principal est de mettre en œuvre des générateurs de codes. Un programme Acceleo nécessite un méta-modèle et un modèle conforme avec le méta-modèle à partir duquel il génère le code source. Acceleo est sous la forme d’un plugin Eclipse convivial, donc facile à installer, et dispose d’outils de coloration syntaxique, d’auto complétion, etc. Le méta-modèle et le modèle sont définis en utilisant EMF, ce qui rend Acceleo compatible avec d’autres outils basés sur EMF [10]. Une caractéristique principale d’Acceleo est que le texte généré est mélangé avec la syntaxe Acceleo. La syntaxe d’Acceleo propose des structures de contrôle, les boucles, la définition des variables, mais avec une portée limitée. Il dispose des requêtes qui permettent à l’utilisateur de définir des opérations qui pourraient être répétées plusieurs fois. Mais Acceleo ne dispose pas de syntaxe pour dé- finir ni les variables globales, ni les structures de données tels que les tableaux, les listes etc. Pour pallier ces insuffisances, il est possible de définir des services Java que l’on invoque pour opérer des traitements qui ne pouvaient être réalisés en se limitant aux syntaxes d’Acceleo.
4.2 L’implémentation des machines à état
Nous avons choisi notre outil de modélisation ainsi que notre outil de génération de code mais, il nous faut à présent choisir la méthode que nous allons utiliser pour transformer nos machines à état en code source. Notre choix c’est porté sur la méthodologie proposée par le Dr.
Samek avec son processeur d’événement QEP. Les différentes méthodes du processeur d’évènement QEP sont listées dans l’annexe A. Rappelons- le, QEP est construit en mettant en commun tous les points positifs des trois méthodes principales d’implémentation des machines à état. Alors donc, nous devons écrire l’algorithme permettant de générer le code des machines à état en suivant les principes de QEP, et ensuite traduire cet
algorithme en un template Acceleo.
4.3 L’intégration de FreeRTOS
Un système temps réel est composé de plusieurs tâches s’exécutant en parallèle. Ainsi, le comportement réactif de chaque tâche peut être modélisé par une machine à état. Notre application devient donc un ensemble de machine à état s’exécutant de façon concourante. De ce faite, les mécanismes de communication et de synchronisation entre les tâches doivent pouvoir être représenté lors de la modélisation. En plus de cela, tous les éléments propres à FreeRTOS à savoir les interruptions, la gestion des ressources etc. Pour cela, nous allons utiliser le sous-profil SRM du profil UML MARTE pour la modélisation des systèmes temps réel afin de pouvoir représenter ces éléments dans nos diagrammes. Cela nous implique donc d’intégrer l’utilisation des diagrammes de classe dans notre modélisation afin d’utiliser les stéréotypes de SRM.
Conclusion partielle
Dans ce chapitre, nous avons présenté les choix des outils pour la modélisation et la génération de code à partir des machines à état, ainsi que l’implémentation des machines à état et leur intégration sous FreeR- TOS par l’utilisation du sous-profil SRM de MARTE. Dans le prochain chapitre nous présenterons notre solution à travers son implémentation et son principe de fonctionnement.
CHAPITRE 5
Implémentation et principe de fonctionnement
5.1 La méthodologie proposée
Afin d’aboutir à une génération de code complète, il est indispensable que l’étape de modélisation apporte toutes les informations nécessaires au fonctionnement du système. Pour ce faire, deux types de diagrammes UML seront utilisés dans la modélisation, les diagrammes de classe et les machines à état. Les machines à état permettent de modéliser les com- posants réactifs du système. Les diagrammes de classe permettent de définir les attributs et méthodes des classes, d’appliquer les stéréotypes du sous profil SRM. Les stéréotypes permettront de définir les tâches, les interruptions, les fils de message et les ressources partagées. Chaque machine à état de notre système est considérée comme un objet actif.
La spécification UML définit un objet actif comme un objet ayant son propre thread de contrôle qui traite les événements d’une manière RTC (Run To Completion) et qui communique avec les autres objets actifs en échangeant les événements de façon asynchrones. Le principe de RTC sous-tend qu’une machine à état ne traite un événement que lorsqu’il finit d’en traiter un autre, il ne peut interrompre le traitement d’un évé- nement pour en traiter un autre. La plus part des outils de génération de code pour les SETR utilise ce principe et l’encapsule dans un fra-
mework. Comme exemple nous pouvons citer les outils de génération de code Rhapsody et VisualSTATE. L’outil de génération de code Rhap- sody l’appelle ”Object Execution Framework” et VisualSTATE l’appelle
”VisualSTATE engine”. Dans notre implémentation, nous allons utiliser un fil de message associé à chaque machine à état dans lequel les événe- ments concernant chaque machine à état seront stockés. Ils seront traités par ordre d’arrivée (FIFO) par la machine à état. Un objet actif repré- sente donc dans notre implémentation la somme d’une tâche, d’un fil de message et d’une machine à état.
5.2 La modélisation avec Papyrus
Afin de pouvoir utiliser notre générateur de code, nous nous devons de spécifier les règles et principe de modélisation des classes et des machines à états.
5.2.1 La modélisation des machines à état
Nous allons exposer dans cette section l’utilisation des éléments des machines à état dans la modélisation.
5.2.1.1 Les états et les transitions
Les états sont les éléments de base des machines à état. Pour cela donc, ils sont totalement supportés par notre système en ce sens que, les fonctions d’entrée et de sortie des états peuvent être définies et récupé- rées par notre générateur de code. Les états composés ainsi que l’état final sont également pris en compte.
Les transitions entre les états peuvent être de tous les types : locale, interne ou externe. Elles sont donc différenciées et rendues différemment par le générateur de code. Les transitions n’ont pas toutes la même sémantique, si une transition est du type interne par exemple alors les fonctions d’entrées ne sont plus appelées. Sur les transitions peuvent être placée les événements, les actions et les conditions de garde.
