Soutenance mémoire
Les systèmes embarqués sont devenus essentiels dans la pluspart des secteurs industriels : énergie, transport, télécommunications, santé… L’omniprésence de l’informatique dans nos sociétés impose la nécessité de la fiabilité des logiciels : les conséquences économiques, juridiques ou même humaines d’une défaillance logicielle peuvent être catastrophiques pour leur concepteur et/ou distributeur, ce qui rend les procédés industriels de plus en plus complexes.
Afin de garantir leur bon fonctionnement, il est nécessaire de prendre en compte les aspects continus et événementiels de leur dynamique. D’une façon générale, les systèmes dynamiques faisant intervenir explicitement et simultanément des phénomènes ou des modèles de type dynamique continus et événementiels sont appelés systèmes dynamiques hybrides SDH. Ces systèmes sont classiquement constitués de processus continus interagissant avec des processus discrets. La modélisation cherche à formaliser des modèles précis pouvant décrire le comportement riche et complexe des SDH. Ces systèmes sont classiquement représentés par le formalisme des automates hybrides, définis par des ensembles d’états et de variables discrètes et continues.
La simulation de ces systèmes hybrides nécessite des données précises et une puissance de calcul pour détecter les changements des valeurs continues et les synchroniser avec les transitions discrètes. Mais, durant les premières phases de conception, les valeurs exactes de quelques paramètres ne sont pas encore connues, alors qu’il est nécessaire de vérifier les comportements possibles du système pour prendre des décisions de conception. Pour les variables continues des systèmes hybrides, les lois d’évolution sont souvent décrites par des équations différentielles. Les variables continues évoluent ainsi en suivant ces lois sur les états temporisés du système. Souvent ces équations sont complexes ou incomplètes. Dans ces conditions, la simulation qualitative peut être une alternative à la simulation numérique pour ce type de modèle. Son principe est la discrétisation des domaines de variation des variables continues et de leurs dérivées. Elle mène à une description qualitative de l’évolution des variables continues : positive, negative, null, increasing, decreasing, constant. . . De cette manière, on peut obtenir un arbre des comportements abstraits du système. Chaque nœud décrit l’évolution des variables du système pendant une phase du comportement. Combiné avec un modèle de la partie discrète du système, on obtient un modèle global discret du comportement du système à qui des techniques formelles peuvent être appliquées. Parfois les équations différentielles ne sont pas disponibles ou quelques paramètres ne sont pas encore connus. Dans cette situation, nous pouvons utiliser un modèle abstrait des lois d’évolution des variables continues pour effectuer une simulation qualitative. En effet, nous pouvons représenter les variations de vitesse des variables continues (dérivées premières non explicitées) et établir des liens de causalité entre elles. Par exemple, les valeurs précises et les équations différentielles ne sont pas nécessaires pour prédire qu’un objet laissé dans un champ gravitationnel touchera le sol. Ce type de modèle qualitatif peut être modélisé par un automate hybride. Pour assurer un haut niveau de fiabilité, il est essentiel d’effectuer dans les premières phases de conception, une analyse du comportement du système quand il intéragit avec son environnement. Cet environnement implique généralement diverses connaissances métiers (électronique, hydraulique, mécanique, automatique, informatique. . . ) décrites dans un formalisme approprié. Le langage SysML [2] tend à devenir un standard dans la modélisation de spécifications multi domaines. Il est utilisé pour spécifier le système, analyser sa structure et ses fonctionnalités. Il est aussi utilisé pour vérifier des propriétés du système avant sa réalisation. Ce langage graphique offre des possibilités d’extension par la définition de profils. Cette activité est facilitée par l’utilisation de plateformes évoluées de modélisation telle que Papyrus, développée au CEA LIST.
Ingénierie dirigée par les modèles
Motivation
De nos jours les technologies logicielles ne cessent d’évoluer sans fin. Tous les jours de nouveaux paradigmes et de nouvelles technologies apparaissent : technologies WEB (HTML, CSS) ; technologies Microsoft comme C♯, .Net. La question qui se pose, c’est quelle est la meilleure technologie. La réponse à cette question est celle à venir. Dans le but de profiter de la dernière technologie, il est nécessaire d’adapter une application déjà développée. Le coût d’adaptation est très élevé. En effet, il est obligatoire de réécrire presque entièrement l’application puisque dans cette dernière il y a un mélange du code métier et du code technique. Prenons comme exemple une application écrite en C qui fait des calculs scientifiques distribués sur un réseau de machines. Si nous voulons prendre cette application et passer du langage C vers Java, il est impossible de reprendre le code existant bien que les algorithmes de distribution des calculs et de répartition des charges sur les machines soient indépendants de la technologie mise en œuvre. Il est clairement nécessaire de découpler la logique métier et la mise en œuvre technologique [17]. C’est pour ces raisons que l’Ingénierie Dirigée par les Modèles (IDM ) a vu le jour fin 2000.
MDA
L’OMG (Object Management Group) avait rendu publique son initiative MDA Model Driven Architecture [4] qui visait à la définition d’un cadre normatif pour l’IDM. Le but principal de cette approche est de séparer les parties métier de leur mise en œuvre technologique et ainsi garantir l’interopérabilité des modèles fonctionnels pour différents choix d’implémentation [48]. Pour réaliser cette séparation, MDA se base sur des technologies et standards de l’OMG comme le langage de modélisation UML, le langage de contraintes OCL, le langage de transformation de modèles QVT etc. Le MDA propose trois principaux niveaux de modèles [48] :
— CIM, Computation Independent Model correspondant à la spécification du système de point de vue extérieur de l’utilisateur ;
— PIM, Platform Independent Model correspondant à la spécification de la partie métier d’une application indépendamment de la technologie de mise en œuvre ;
— PSM, Platform Specific Model correspondant à la spécification d’une application après projection sur une plate-forme technologique donnée.
Principes de l’IDM
L’Ingénierie Dirigée par les Modèles est une discipline récente du génie logiciel qui promeut les modèles en entités de première classe dans le développement logiciel [10]. C’est un paradigme rassemblant de nombreux principes autour de la notion centrale de modèle. L’IDM repose sur les principes suivants [48] :
— Capitalisation, les modèles doivent être réutilisables ;
— Abstraction, les modèles doivent être indépendants des technologies dans le but d’adapter une logique métier à un contexte et faire évoluer les applications vers de nouvelles technologies ;
— Modélisation, faite suivant une vision bien définie afin de pouvoir générer le code final du logiciel pour une plateforme donnée ;
— Séparation des préoccupations, l’IDM se base sur deux principales préoccupations, le métier (le cœur de l’application) et la plateforme de sa mise en œuvre.
Le but de l’IDM est de passer d’une vision plutôt contemplative des modèles qui vise la documentation, spécification et la communication, à une vision productive qui permet de générer le code final du logiciel pour une technologie de mise en œuvre donnée. Pour que les modèles soient productifs, il est nécessaire qu’ils soient bien définis. Ceci est assuré par la notion de méta-modèle. Par conséquent, les modèles productifs peuvent être manipulés et interprétés via des outils qui permettent [48] :
— la définition de méta-modèles, de langages DSL : Domain Specific Language, de transformations et leur exécution ;
— la génération de code ;
— la composition de modèles ;
— la génération d’environnements graphiques de modélisation, la vérification de conformité de modèles, la spécification de contraintes. . .
L’IDM est donc une forme d’ingénierie générative, par laquelle tout ou partie d’une application informatique est engendrée à partir de modèles. Dans cette nouvelle vision, les modèles occupent une place importante parmi les artefacts de développement des systèmes. Ils doivent en revanche être précis et riches afin de pouvoir être interprétés ou transformés par des machines. Le processus de développement des systèmes peut alors être vu comme une séquence de transformations de modèles, chaque transformation prend un ou des modèles en entrée et produit un ou des modèles en sortie, jusqu’à l’obtention d’artefacts exécutables [25].
|
Table des matières
1 Introduction
1.1 Contributions de la thèse
1.2 Structure de la thèse
2 Contexte scientifique
2.1 Ingénierie dirigée par les modèles
2.1.1 Motivation
2.1.2 MDA
2.1.3 Principes de l’IDM
2.1.4 SysML
2.2 Problématiques
2.3 Raisonnement qualitatif
2.3.1 Motivation du raisonnement qualitatif
2.3.2 Application du raisonnement qualitatif
2.3.3 Techniques du raisonnement qualitatif
2.3.3.1 Raisonnement causal
2.3.3.2 Théorie des processus qualitatifs
2.3.3.3 Envisionnement
2.4 Simulation qualitative
2.4.1 Principe général de la simulation qualitative
2.4.2 Extension pour les automates hybrides
2.4.3 Approches de la simulation qualitative
2.5 Systèmes hybrides
2.5.1 Définition
2.5.2 Modélisation des systèmes dynamiques hybrides
2.5.2.1 Automates hybrides
2.5.2.2 Les bond graphs à communications
2.6 Exécution symbolique
2.7 Conclusion
3 Etat de l’art
3.1 QSIM
3.1.1 Valeurs, états et comportements qualitatifs
3.1.2 Contraintes sur les valeurs qualitatives
3.1.2.1 Contraintes d’état
3.1.2.2 Contraintes de transition
3.1.2.3 Contraintes globales
3.1.3 Déroulement de QSIM
3.1.4 Discussion
3.2 Ordres de grandeurs absolus
3.2.1 Motivation
3.2.2 Construction du modèle formel
3.2.3 Discussion
3.3 Ordres de grandeurs relatifs
3.3.1 Motivation
3.3.2 Système FOG
3.3.3 Système O(M)
3.3.4 Les systèmes Rom(K) et Rom(R)
3.3.5 Discussion
3.4 Introduction de l’information temporelle dans la simulation qualitative
3.4.1 Motivation
3.4.2 Filtre temporel pour le calcul de la durée des états
3.4.3 Discussion
3.5 Les différents outils existants dédiés à la simulation qualitative
3.5.1 QSIM
3.5.2 PA
3.5.3 Garp3
3.5.4 Discussion
4 Modèles d’exécution pour la simulation qualitative
4.1 Préliminaire
4.1.1 Valeur qualitative
4.1.2 Variable d’état
4.1.3 Comportement qualitatif
4.2 Modèle d’exécution énuméré
4.2.1 Calcul du comportement qualitatif
4.2.2 Exemple illustratif : la balle rebondissante
4.2.3 Simulation qualitative du modèle hybride brut
4.2.4 Ajuster le Modèle d’exécution
4.2.5 Ajuster le modèle
4.2.6 Discussion sur le modèle d’exécution énuméré
4.3 Modèle d’exécution symbolique inspiré de la méthode d’Euler
4.3.1 Implémentation du modèle d’exécution symbolique dans Diversity
4.3.2 Calcul des comportements qualitatifs de second ordre
4.3.3 Exemple illustratif : la balle rebondissante
4.3.4 Exemple illustratif : Le circuit RC
4.3.4.1 Calcul des comportements qualitatifs de premier ordre
4.3.4.2 Machine à états du circuit RC
4.3.4.3 Comportement qualitatif calculé par Diversity
4.3.5 Discussion sur le modèle d’exécution symbolique inspiré de la méthode d’Euler
4.4 Modèle d’exécution symbolique avec contraintes qualitatives
4.4.1 CPROP
4.4.2 PROP
4.4.3 CIPROP
4.4.4 IPROP
4.4.5 Évolution qualitative d’une variable d’état
4.4.6 Mise en œuvre de la génération du terme correctif
4.4.7 Vérification des relations
4.4.8 Implémentation du modèle de contraintes qualitatives dans Diversity
4.4.9 Analyse des comportements qualitatifs
4.4.10 Exemple illustratif : Système de refroidissement
4.4.10.1 Principe général du système de refroidissement
4.4.10.2 Scénario du système de refroidissement de température
4.4.10.3 Régulation du système de refroidissement de température
4.4.10.4 Comportement qualitatif calculé par Diversity
4.4.11 Discussion sur le modèle d’exécution symbolique avec contraintes qualitatives
4.5 Discussion sur les trois modèles d’exécution
5 Conclusion
