Soutenance mémoire
Systèmes embarqués
Les systèmes embarqués sont très souvent considérés à travers des sous-types particuliers tels que les systèmes temps réel, les systèmes critiques, etc. Différentes taxonomies des systèmes embarqués existent [Zur05, Tim07], mais il est difficile d’en trouver une définition générale. Nous appelons système embarqué, ou système enfoui, un système intégré dans un système plus large avec lequel il est interfacé et pour lequel il réalise une ou plusieurs fonctions particulières(par exemple : contrôle, surveillance, communication. . .). Un système embarqué comprend des logiciels et des matériels conjointement et spécifiquement conçus pour assurer ces fonctionnalités. De ce fait, les systèmes embarqués sont par essence hétérogènes [EJL+03]. Les systèmes embarqués sont également par nature des systèmes contraints [HS07]. Tout d’abord, ce sont des systèmes réactifs qui subissent une forte intégration avec leur environnement. De plus, du fait de leur insertion dans un système « embarquant », l’espace matériel qu’ils peuvent occuper est généralement limité (tendance à la miniaturisation) ainsi que, très souvent, les ressources énergétiques qu’ils peuvent utiliser. Ils doivent par ailleurs répondre à des spécifications exigeantes [Zur07], que ce soit en termes de performances, de robustesse, de fiabilité, de délai de mise sur le marché, d’évolutivité ou encore de coût. Du fait de ces contraintes et exigences, la conception des systèmes embarqués pose des difficultés particulières que nous étudierons dans la section 2.5.5. Nous proposons de distinguer ci-dessous les différents types de contraintes auxquelles ils peuvent être exposés et qui donnent lieu à différentes catégories de systèmes embarqués. Il est important de noter que cette classification n’est pas stricte car un système embarqué donné est souvent soumis à plusieurs contraintes et exigences de types différents en fonction de l’application à laquelle il est destiné. Nous identifions, entre autres : Les systèmes temps réel D’après [Sta88], dans un système temps réel, la correction dépend non seulement du résultat logique du calcul mais également du temps nécessaire pour que le résultat soit produit. La contrainte de temps est donc un élément déterminant du fonctionnement des systèmes temps réel. Un système temps réel peut être décrit comme un système destiné à observer et à agir sur son environnement extérieur avec un délai de réponse fini et spécifié [Liu00]. Tout délai de réponse supérieur au délai spécifié implique un déphasage du système et des erreurs de traitement aux conséquences plus ou moins graves. Par exemple, lors de l’atterrissage d’un avion, le système d’indication d’altitude doit fournir une valeur exacte à un instant précis de manière à ce que les réactions du pilote, qui dépendent de l’altitude, aient lieu au bon moment. Tout retard de réponse du système peut conduire dans ce cas à l’écrasement de l’avion. L’interaction d’un système temps réel avec son environnement fait intervenir des capteurs et des actionneurs. La réaction du système comporte trois étapes, et doit se faire en un temps déterminé : réception des données à travers les capteurs, réaction (traitement des données, calcul), réponse à travers les actionneurs. Les systèmes critiques Ce type de système est soumis à des contraintes de fiabilité extrêmement fortes [Sto96]. Toute erreur dans le fonctionnement d’un tel système a des conséquences catastrophiques telles que des pertes de vies humaines, des destructions matérielles importantes, un impact financier colossal, etc. Les systèmes critiques peuvent également être des systèmes temps réels, pour lesquels les contraintes de temps de réponse sont dite « strictes » : leur non respect cause une erreur de fonctionnement pouvant entraîner d’importants dégâts. Le contrôle de processus industriels sensibles, comme par exemple des centrales nucléaires, le contrôle de systèmes aéronautiques, la bourse ou encore la médecine assistée par ordinateur font partie des systèmes critiques. Les systèmes distribués et mobiles Dans le cadre des systèmes embarqués, nous désignons par le terme de systèmes distribués les systèmes embarqués répartis spatialement fonctionnant généralement en association les uns avec les autres via un réseau. Les systèmes de type « réseaux de capteurs », par exemple, sont des systèmes embarqués distribués composés d’unités autonomes dotées de modules de communication (souvent sans fil). Leurs applications sont très variées, depuis les systèmes de surveillance environnementale jusqu’aux systèmes d’armement militaire. Les systèmes embarqués mobiles, quant à eux, sont caractérisés par une position spatiale qui change au cours du temps. Les puces de nos téléphones portables sont de parfaits exemples de systèmes embarqués mobiles. Qu’ils soient distribués ou mobiles, ces systèmes ont souvent pour contrainte majeure l’autonomie. Fonctionnant généralement sans intervention humaine directe, ils sont soumis à de fortes restrictions sur leurs ressources énergétiques (fonctionnement sur batterie en particulier).
Les systèmes reconfigurables Appelés également systèmes adaptatifs, les systèmes reconfigurables [Tei07] sont des systèmes capables de s’adapter de manière dynamique aux changements de leur environnement en modifiant leur configuration : modification de la disposition relative des éléments, du nombre d’éléments, de la nature des éléments, du comportement des éléments, etc. De telles notions d’adaptabilité et de flexibilité sont plutôt récentes, concernent principalement le domaine des logiciels embarqués et posent encore des problèmes techniques importants. Les systèmes embarqués sont d’une importance stratégique pour l’économie car ils sont facteurs d’innovation, de différentiation et d’amélioration de la compétitivité : ils permettent d’offrir de nouvelles fonctionnalités et de nouveaux services, dans des produits existants ou dans de nouveaux produits. La source de la valeur ajoutée est principalement aujourd’hui dans les logiciels embarqués. Les composants embarqués sont intégrés massivement dans les systèmes communicants qui sont à la base de notre société de l’information : téléphones cellulaires, automobile, appareils médicaux, photo/vidéo/hifi, électroménager, avionique, spatial, jouets, etc.
Evolutions autour des modèles
Depuis Vitruve, l’ingénierie système a évolué autour de la notion de modèle. Des abstractions de puissance croissante ont été nécessaires pour représenter des systèmes d’une complexité croissante. De plus, avec l’avènement des outils informatiques, les modèles ont évolué depuis les formats papier ou les prototypes de taille réduite vers des modèles informatiques au format électronique. Des outils permettant de construire et d’exploiter ces modèles ont été développés. Les modèles informatiques ont progressivement pris un rôle prépondérant dans le cycle de développement des systèmes, à tel point que l’on peut dire aujourd’hui que l’ingénierie système est en fait « dirigée par les modèles » car ces modèles sont omniprésents depuis les phases d’expression des besoins jusqu’aux phases d’exploitation ou de maintenance. Et si le fait de travailler à partir de modèles n’est pas nouveau en ingénierie système, toutes les disciplines qui se sont développées autour des modèles informatiques dans l’objectif d’outiller et d’automatiser les différentes activités du cycle de développement des systèmes sont, elles, relativement récentes. Le terme d’Ingénierie Dirigée par les Modèles (IDM) [Ken02, FEBF06] recouvre l’ensemble de ces disciplines, dans lesquelles les modèles jouent un rôle de tout premier plan.
Activités liées à l’IDM
Les activités liées à la manipulation des modèles dans le cadre de l’IDM sont nombreuses et apportent chacune un ensemble de problématiques spécifiques. Nous présentons ici une liste non exhaustive de ces activités et donnons un aperçu des problématiques qui leur sont liées.
Réalisation de modèles La réalisation des modèles nécessite non seulement l’expertise technique pour comprendre ou concevoir la partie du système concerné mais également une bonne connaissance du langage de modélisation utilisé. Dans le cas de systèmes complexes, les modèles deviennent également complexes et surtout de taille importante. La qualité de l’outillage devient alors essentielle car ce sont les outils qui permettent de mieux visualiser le modèle, de s’affranchir de certains détails ou encore de vérifier automatiquement la syntaxe. Les problématiques liées à l’outillage sont variées : elles concernent la visualisation des modèles, les méthodes d’assistance, le support des langages de modélisation, etc.
Stockage de modèles L’informatisation des modèles pose le problème de la gestion de leur persistance puis de leur accès par les utilisateurs. Les problématiques liées à cette activité concernent, par exemple, les formats de stockage, l’organisation du stockage ainsi que la gestion des méta-données concernant les modèles.
Echange de modèle L’échange de modèles entre différents acteurs d’un projet est une vraie nécessité car elle conditionne la bonne communication entre ces acteurs. Des problèmes de compréhension de modèles entre différents acteurs peuvent avoir des conséquences catastrophiques sur le système implémenté. L’échange de modèles pose notamment des problèmes de format (sérialisation, transport, etc.), de traduction et d’interprétation de la sémantique pour l’intéropérabilité (notamment entre les outils de modélisation).
Interrogation de modèles L’interrogation de modèles est l’activité qui permet de rechercher et récupérer de l’information dans les modèles. Les problématiques de cette activité sont liées par exemple à l’identification d’éléments ou de motifs dans les modèles.
Exécution de modèles L’exécution de modèles comprend un éventail de tâches différentes allant de la simulation à l’exécution en temps réel en passant par l’exécution symbolique ou la génération de code. Dans ce domaine, les problèmes majeurs concernent l’exécutabilité de la sémantique des langages de modélisation utilisés. En effet, cette propriété d’exécutabilité conditionne la possibilité de pouvoir calculer, à partir du modèle, un comportement du système (simulation), ou même tous les comportements possibles de ce système (modelchecking). Vérification de modèles La vérification d’un modèle consiste à vérifier les propriétés propres de ce modèle par rapport à ce que l’on attend de lui (correction syntaxique, etc.). L’activité de vérification se distingue notamment de l’activité de validation. En effet, la validation consiste à vérifier, en utilisant un ou plusieurs modèles, les propriétés du système conçu par rapport à ce que l’on attend de ce système. Le terme de vérification de modèle recouvre différents aspects allant de la vérification de la syntaxe à la vérification de la sémantique. Les problématiques les plus complexes concernent bien sûr la vérification de la sémantique. Différentes techniques de vérification existent, avec leurs problématiques particulières : la preuve, le test ou encore le model-checking. Les techniques de preuve s’appuient sur l’utilisation de représentations formelles (à base de logique, d’automates, de contraintes par exemple) du système. Dans ce contexte, on cherche à prouver des propriétés comme la consistance ou la complétude d’un modèle. Dans le cas de systèmes complexes, ces tâches deviennent impossibles à réaliser sur un modèle préexistant et un axe important de recherche vise à obtenir ces propriétés par construction. Les techniques de model-checking visent à analyser le comportement spécifié par le modèle de manière à vérifier des propriétés comme la sûreté, l’atteignabilité ou la vivacité. Les problématiques dans ce contexte sont liées notamment à l’identification avec exhaustivité des états possibles du système (explosion des espaces d’état). Enfin, le test est utilisé en complément du model-checking, notamment dans le cas de systèmes pour lesquels le model-checking est particulièrement inefficace (lorsque les systèmes sont trop complexes par exemple). L’évaluation de la pertinence des tests est une des difficultés principales dans ce domaine, et elle conditionne la façon dont les tests sont sélectionnés. Les enjeux liés à la vérification des modèles comptent aujourd’hui parmi les enjeux les plus importants de l’IDM.
Validation La validation permet de vérifier que le système implémenté répond aux besoins initiaux qui ont amené à sa conception. Certaines techniques comme le test peuvent être utilisées à la fois pour la vérification et pour la validation. Dans ce cadre, les modèles permettent notamment de générer des scénarios et des vecteurs de test de façon automatique [BGM91]. Par ailleurs, afin de minimiser les risques d’erreur de conception le plus en amont possible, les modèles peuvent être validés les uns par rapport aux autres au cours du cycle de développement. Il s’agit alors, par exemple, de vérifier que certaines propriétés sont préservées d’un modèle à un autre. Un ensemble des problématiques de ce domaine est lié au mécanisme de raffinement de modèle, par lequel on obtient un modèle plus détaillé à partir d’un autre (nécessitant souvent un apport d’information).
Gestion de l’évolution des modèles Les modèles évoluent au cours du cycle de développement du système. Ils peuvent être modifiés dans le cadre de correction d’erreurs ou d’ajout de fonctionnalités par exemple. Les problématiques dans ce contexte concernent en particulier la répercussion automatique des modifications sur les différents modèles impliqués et sur la documentation, la traçabilité des modifications ainsi que la gestion des versions.
Domain Specific Languages (DSLs)
Les Domain Specific Languages (DSLs) [vDKV00], appelés également langages dédiés ou langages domaine-spécifiques, sont des langages conçus spécifiquement pour un domaine technique ou un domaine métier, comprenant généralement un petit nombre de concepts et utilisés par un nombre modeste d’utilisateurs spécialistes. Ces langages apportent une solution ciblée et efficace à un ensemble restreint et particulier de problèmes de modélisation ou de programmation. Il existe un très grand nombre de DSLs, avec des niveaux d’abstraction très différents. Différentes études, dont celle documentée dans [KMB+96], permettent de dire que ces langages très spécifiques permettent aux spécialistes de gagner en productivité et en efficacité dans le traitement des problèmes par rapport à l’utilisation de langages généralistes (aussi appelés General Purpose Languages). Dans un contexte où la complexité des systèmes augmente, ces langages ont donc des qualités indéniables. Cependant, comme ils sont utilisés par de petits nombres de spécialistes, il est économiquement difficile de développer et maintenir l’outillage correspondant (environnements intégrés de développement, outils de génération de code, etc.). Différentes initiatives ont vu le jour afin de permettre la génération automatique d’outils à partir de la définition du langage [AFR06]. Parmi les plus importantes, nous pouvons citer GME [Dav03], MetaEdit+ [Poh03], le Eclipse Modeling Project (incluant EMF, GEF et GMF) [Ecla], XMF-Mosaic (seule la partie XMF est maintenue à ce jour [CSW08]) ou encore l’initiative Microsoft [GSCK04] par exemple. Ces outils permettent de définir facilement des syntaxes concrètes graphiques ou textuelles et permettent même souvent de séparer syntaxe abstraite et syntaxe concrète. Aujourd’hui, l’utilisation des DSLs est activement soutenue par les communautés du domaine de la méta-modélisation (voir Paragraphe 2.4.1.5.c). Dans ce cadre, un nouveau domaine, connexe à l’IDM, est en train d’apparaître : l’Ingénierie des Langages Logiciels [DD06, Fon07]. L’influence des techniques développées dans ce domaine sur l’IDM est telle que certains auteurs parlent même de Language Driven Development (LDD) [CSW08].
Méta-modélisation et MOF (MetaObject Facility)
La méta-modélisation prend sa source dans le besoin de représenter les concepts manipulés lors de l’utilisation des formalismes de modélisation. Dans le cadre de l’approche MDA, ce besoin est né des difficultés rencontrées dans les processus de transformations de modèles d’un langage à un autre : il s’agissait de décrire, de manière abstraite et détachée de l’instance de modèle considérée, les constructions du langage source pouvant être transformées ainsi que leurs équivalents dans le langage cible. Dans le cadre de ses travaux concernant la méta-modélisation, l’OMG a d’une part défini la notion de méta-méta-modèle et d’autre part standardisé une architecture générale décrivant les liens entre modèles, méta-modèles et méta-méta-modèles. Cette architecture est classiquement hiérarchisée en « 3+1 » niveaux : Niveau M3 (MMM) Dans l’approche MDA, le niveau M3 (ou méta-méta modèle) est composé d’une unique entité qui s’appelle le MOF (MetaObject Facility [OMGf]). Le MOF permet de décrire la structure des méta-modèles, d’étendre ou de modifier les méta-modèles existants. Le MOF est réflexif, c’est-à-dire qu’il se décrit lui-même. Niveau M2 (MM) Le niveau M2 (ou méta-modèle) définit le langage de modélisation et la grammaire de représentation des modèles M1. Le méta-modèle UML, qui est décrit dans le standard UML, et qui définit la structure interne des modèles UML, fait partie de ce niveau. Les profils UML, qui étendent le méta-modèle UML, appartiennent aussi à ce niveau. Les concepts définis par un méta-modèle sont des instances des concepts du MOF. Niveau M1 (M) Le niveau M1 (ou modèle) est composé de modèles d’information. Il décrit les informations de M0. Les modèles UML, les PIM et les PSM appartiennent à ce niveau. Les éléments d’un modèle (M1) sont des instances des concepts décrits dans un méta-modèle (M2). Niveau M0 Le niveau M0 (ou instance) correspond au monde réel. Il ne s’agit pas à proprement parler d’un niveau de modélisation. Ce niveau contient les informations réelles de l’utilisateur, instances du modèle du niveau M1.
Model Integrated Computing – MIC
Apparue au milieu des années 90, l’approche Model-Integrated Computing (MIC) [SK97] promeut l’utilisation de modèles domaine-spécifiques à la base du développement logiciel. La motivation première de cette approche était d’apporter à l’ingénierie des systèmes logiciels complexes une méthodologie ainsi que des outils logiciels de support. La méthodologie proposée est décomposée en deux phases. La première phase consiste à analyser le domaine d’application. L’objectif de cette phase est de trouver des paradigmes de modélisation appropriés et définir avec précision le langage de modélisation qui sera utilisé. Un outil automatique peut alors utiliser ces informations pour générer un environnement de modélisation dédié au domaine. Cet environnement est utilisé directement dans la seconde phase, qui consiste à modéliser l’application désirée. La plate-forme GME (Generic Modeling Environment) [Dav03] est une implémentation de la méthodologie définie par l’approche MIC. Dans sa dernière version, GME est intégré à l’environnement Visual Studio .NET et propose un ensemble de langages et d’outils pour l’ingénierie des modèles et des langages. Cependant, il ne permet pas pour le moment de spécifier la sémantique des langages développés.
|
Table des matières
1 Introduction
1.1 Contexte
1.2 Contributions
1.3 Structure du mémoire
1.4 Le projet OpenDevFactory
I Conception des systèmes et hétérogénéité
2 Ingénierie système, modélisation et hétérogénéité
2.1 Introduction
2.2 Terminologie
2.2.1 Système
2.2.2 Systèmes embarqués
2.2.3 Ingénierie Système
2.2.4 Modèle, modélisation
2.3 Ingénierie dirigée par les modèles (IDM)
2.3.1 Evolutions autour des modèles
2.3.2 Modèles pour l’ingénierie système
2.3.3 Modèles pour le génie logiciel
2.3.4 Activités liées à l’IDM
2.4 Approches de l’ingénierie dirigée par les modèles
2.4.1 Model Driven Architecture – MDA
2.4.2 Autres approches centrées sur les modèles
2.5 IDM appliquée aux systèmes complexes : notre vision du problème de l’hétérogénéité des modèles
2.5.1 Exemple introductif
2.5.2 Objectifs de modélisation
2.5.3 Paradigme versus formalisme
2.5.4 Hétérogénéité des modèles et conséquences
2.5.5 Spécificités des systèmes embarqués
2.6 Conclusion
3 Modélisation multi-paradigme
3.1 Introduction
3.2 Modélisation multi-paradigme
3.2.1 Travaux connexes
3.2.2 Présentation
3.2.3 Axes de recherche
3.3 Etat de l’art des techniques pour la modélisation multi-paradigme
3.3.1 Approches spécifiques
3.3.2 Prérequis : spécification de la syntaxe et de la sémantique des langages de modélisation
3.3.3 Transformations de modèles et composition de méta-modèles
3.3.4 Composition de sémantiques
3.3.5 Approches à bases de composants
3.3.6 Autres approches
3.3.7 Particularités liées au traitement de vues multiples et de niveaux d’abstraction multiples
3.4 Proposition de classification des approches de modélisation multi-paradigme
3.4.1 Support ouvert pour de multiples paradigmes
3.4.2 Support pour de multiples activités du cycle de développement
3.4.3 Support pour le raisonnement formel
3.5 Conclusion
II Composition exécutable de modèles hétérogènes avec ModHel’X
4 ModHel’X : une approche de la composition de modèles hétérogènes
4.1 Introduction
4.2 Problématiques de la composition de modèles hétérogènes
4.3 Préambule : approche proposée et concepts sous-jacents
4.3.1 Encapsulation du comportement : boîtes noires
4.3.2 Observation de l’exécution : snapshots
4.3.3 Modèles d’Exécution (MoEs)
4.3.4 Aspects temporels et synchronisation
4.3.5 Architecture globale de l’approche ModHel’X
4.4 Représentation des modèles hétérogènes : syntaxe abstraite générique
4.4.1 Blocs, points d’interface, relations et jetons
4.4.2 Blocs atomiques et blocs composites
4.4.3 Modèles et modèles de calcul
4.4.4 Hiérarchie et hétérogénéité : blocs d’interface
4.4.5 Paramètres
4.4.6 Récapitulatif : meta-modèle complet
4.5 Spécification exécutable de MoCs : sémantique abstraite générique
4.5.1 Boucle de déclenchement des snapshots
4.5.2 Déterminisme du calcul d’un snapshot
4.5.3 Contexte de calcul d’un snapshot
4.5.4 Observations successives des blocs : ordonnancement et propagation
4.5.5 Entrelacement des opérations d’ordonnancement et de propagation
4.5.6 Arrêt de la boucle d’observation des blocs
4.5.7 Validation d’un snapshot
4.5.8 Délégation de l’exécution aux éléments du méta-modèle
4.5.9 Hiérarchie et hétérogénéité : mise à jour d’un bloc d’interface
4.5.10 Modélisation du temps
4.6 Méthode de description d’un modèle de calcul dans notre approche
4.6.1 Syntaxe spécifique : spécialisation de la syntaxe abstraite générique
4.6.2 Sémantique spécifique : concrétisation de la sémantique abstraite
4.6.3 Description de l’adaptation sémantique entre deux modèles de calcul
4.7 Positionnement et discussion
4.7.1 ModHel’X et Ptolemy
4.7.2 ModHel’X et la composition de « Semantic Units »
4.7.3 Coût d’utilisation de ModHel’X
4.7.4 Modèles de calcul supportés
4.7.5 Langage de description de modèles de calcul
4.7.6 Expression des mécanismes de combinaison de modèles de calcul
4.7.7 Transmission d’informations à travers plusieurs niveaux hiérarchiques
4.7.8 Composabilité
4.7.9 Conformité entre un modèle d’exécution et un modèle de calcul
4.8 Conclusion
5 Application et validation : le framework ModHel’X
5.1 Introduction
5.2 Implémentation de notre approche : le framework ModHel’X
5.2.1 Conception du framework
5.2.2 Réalisation du framework et difficultés rencontrées
5.2.3 Solution finale retenue
5.3 Cas d’étude : le modèle de la machine à café
5.3.1 Description générale de l’exemple et motivation
5.3.2 Modèle du système global : MoC Discrete Events (DE)
5.3.3 Modèle de la machine à café : MoC Finite State Machine (FSM)
5.3.4 Combinaison des modèles DE et FSM
5.3.5 Exécution du modèle
5.4 Conclusion
6 Conclusion
6.1 Problématique
6.2 Apports
6.3 Perspectives
III Annexes
A Modèles de calcul courants
A.1 Modèle de calcul « Finite State Machine (FSM) »
A.2 Modèle de calcul « Discrete Events (DE) »
A.3 Modèle de calcul « Synchronous/Reactive (SR) »
A.4 Modèles de calcul à base de processus
A.4.1 Modèle de calcul « Process Networks (PN) »
A.4.2 Modèle de calcul « Kahn Process Networks (KPN) »
A.4.3 Modèles de calcul « DataFlow Process Networks (DF) » et « Synchronous DataFlow (SDF) »
A.4.4 Modèle de calcul « Communicating Sequential Processes (CSP) »
B Extension impérative d’OCL pour la description de modèles d’exécution
B.1 Objectifs du langage
B.2 Syntaxe abstraite
B.2.1 Types
B.2.2 Opérations
B.2.3 Expressions du langage
B.2.4 Contexte (self)
B.3 Syntaxe concrète
B.4 Sémantique
C Détails d’implémentation du framework ModHel’X
C.1 Implémentation du modèle de calcul FSM
C.1.1 Méta-modèle spécifique pour FSM
C.1.2 Sémantique d’exécution spécifique pour FSM : code Java
C.2 Implémentation du modèle de calcul DE
C.2.1 Méta-modèle spécifique pour DE
C.2.2 Sémantique d’exécution spécifique pour DE : code Java
C.3 Bibliothèque de blocs
C.3.1 Bloc atomique DEUser
C.3.2 Bloc atomique FSMSimpleGuard
C.3.3 Bloc atomique FSMSimpleAction
C.3.4 Bloc d’interface CoffeeMachineDEFSM
Table des figures
Liste des tableaux
Table des listings
Nos Publications
Bibliographie
Télécharger le rapport complet
