Modèles et Protocoles de coordination pour la reconfiguration dynamique des architectures logicielles embarquées

Modèles et Protocoles de coordination pour la reconfiguration dynamique des architectures logicielles embarquées

Définition des concepts 

Architecture logicielle embarquée 

L’architecture logicielle embarquée est la partie centrale et incontournable d’un système embarqué. En effet, l’architecture logicielle embarquée d’un système comprend un ensemble d’éléments structurés pour le bon fonctionnement. Elle [Fat13B] comprend : • Les composants : représentent les briques de base de l’architecture • Les interfaces : sont associées à un composant et permettent d’accéder aux propriétés de celui-ci • Les connecteurs : permettent de spécifier les liaisons entre les composants et les interfaces • La configuration : représente un assemblage de composants, reliés aux interfaces par des connecteurs • Le style architectural : représente toutes les contraintes imposées aux configurations • L’ADL (Architecture Description Language) : est un langage qui définit les différents éléments décrits dernièrement Figure 1: Représentation graphique d’une architecture logicielle embarquée 

Configuration

 La configuration d’un système embarqué représente l’architecture de ses composants afin d’accomplir une tâche. En effet, un composant est tout élément intervenant dans l’exécution d’une fonctionnalité du système. Chaque composant peut être divisé en sous composants. Cette Modèles et protocoles de coordination pour la reconfiguration dynamique des architectures logicielles embarquées Page 25 décomposition peut s’opérer jusqu’à l’obtention de composant indivisible c’est-à-dire atomique. Une configuration est bien définie pendant l’étape d’analyse et de conception du système. Cette étape est élaborée par les concepteurs du système grâce aux théories basées sur les modèles (MDA, MDE, …) 

 Reconfiguration 

De nos jours, les systèmes embarqués font partie de notre quotidien. Afin de satisfaire les besoins de l’homme grandissants et exigeants, le système embarqué est obligé de s’adapter, de contourner les obstacles de fonctionnement, de donner les résultats escomptés dans un respect de délai malgré les aléas de l’environnement d’exécution. Ainsi, ce système intelligible qui assure son bon fonctionnement dans les meilleures conditions possibles de sécurité, d’intégrité, de fiabilité, de rapidité est appelé système reconfigurable. En effet, une reconfiguration [Guo08] est l’ensemble des modes d’adaptation d’un système en fonction des exigences des utilisateurs, des environnements d’exécution sans entraver à la qualité des résultats escomptés dans le respect des échéances fixés. Ainsi, nous proposons les différents types de changements et d’adaptation qui peuvent se dérouler dans les systèmes embarqués à temps réel 

 Les Types de changement dans un système 

Afin d’assurer une bonne exécution, les systèmes doivent effectuer certains changements à divers niveaux : structure, déploiement, interface, implémentation.

 Les changements de structure

 Les changements de structure modifient la configuration structurelle du système. Les changements structuraux de base sont : l’ajout, la suppression de composants ou la modification d’interconnexions entre composants. Dans la figure ci-dessous, le changement de structure s’est effectué au niveau de la modification de la connexion Con1. Ainsi, les requêtes qui quittent C3 sont dirigées vers C5. Modèles et protocoles de coordination pour la reconfiguration dynamique des architectures logicielles embarquées Page 26 Figure 2: Exemple de changement de structure : Redirection de la connexion Con1 vers le composant C5 [Mou12] 

 Les changements de déploiement 

Les changements de déploiement déplacent un composant dans un autre nœud d’exécution mais ne modifient jamais la structure initiale des connexions. Dans la figure 2 ci-dessous, le composant C6 se retrouve dans un nouveau nœud Noeud3. Cependant, les interconnexions restent inchangées. Figure 3: Exemple de changement de déploiement : Déplacement du composant C6 du Nœud2 vers le Noeud3 [Mou12]

Les changements d’interface 

Les changements d’interface consistent à la modification de la signature des services fournis (figure 3 – A) par un paramètre (c) ou celle de l’ensemble des services fournis (figure 3 – B). En effet la signature d’un service comprend son nom, ses paramètres, leur type. Modèles et protocoles de coordination pour la reconfiguration dynamique des architectures logicielles embarquées Page 27 Figure 4: Exemples de changement d’interface [Mou12] 

 Les changements d’implémentation 

Les changements d’implémentation modifient le code des composants et restructure leurs données sans entraver à leurs interfaces. Cependant, ils n’altèrent pas les placements, ni les connexions des composants. 

 Les catégories d’adaptation

Une étape importante d’un système reconfigurable est le plan de reconfiguration. Il détermine les changements (énoncés dans la section 1.3) à effectuer sur le système en fonction des paramètres temporels, environnementaux et aux exigences de son utilisateur. Ainsi, nous rencontrons ces différents plans de reconfiguration du système :

 Le plan constructible 

Le plan constructible permet au concepteur de définir la configuration initiale à l’aide d’un langage de description et son plan de reconfiguration avec un langage de modification. En effet, ce langage de modification devra supporter l’activation, la désactivation et le déplacement des composants et des interconnexions. Dans ce contexte, le programmeur implémente des configurations alternatives. Ainsi, le gestionnaire de reconfiguration choisit la configuration adéquate. (Cf. figure 4- A) 

Le plan prédéfini 

Le concepteur élabore plusieurs configurations alternatives, prédéfinies du système. Ces configurations sont bien conçues, vérifiées et validées. A l’exécution, le système Modèles et protocoles de coordination pour la reconfiguration dynamique des architectures logicielles embarquées Page 28 choisit la configuration la mieux adaptée à son contexte en s’appuyant sur une fonction d’aptitude connue. Ainsi, une maitrise de chaque configuration et des plans de reconfigurations vers les autres configurations sont obligatoires (Cf. figure 4 – B) 

Le plan intelligent

 Contrairement au plan précédent, le plan intelligent propose une série illimitée de configurations possibles. Le gestionnaire de reconfiguration choisit une configuration en fonction des modèles de performance. En effet, ce plan de reconfiguration n’est pas utilisé dans les systèmes à temps réel strict à cause de l’analyse effectué durant leur exécution. (Cf. figure 4 – C) Figure 5: Les différentes catégories d’adaptation : Plan constructible (Figure 4 – A), Plan prédéfini (Figure 4 – B), Plan intelligent (Figure 4 – C) [Mou12] Dans la section suivante 1.5, nous allons nous intéresser à une nouvelle science novatrice nommée Intelligence Artificielle. Cette science introduit les techniques d’adaptation des systèmes embarqués sous forme d’algorithmes bien structurés. 

L’intelligence artificielle 

Ce point est dédié à une science innovante qui porte le nom d’intelligence artificielle abrégé I.A (A.I en Anglais Artificial Intelligence). Jadis, le mathématicien américain Norbert Wiener [Web01] introduisit une nouvelle science appelé Cybernétique [Web02]. En effet, la cybernétique [Nor14] [Cél04] fut défini comme l’ensemble des règles régissant les domaines naissants tels que l’automatique, l’électronique, les théories mathématiques appliquées à l’informatique. A partir de cette science naquirent certains domaines tels que les sciences cognitives, l’IA. L’origine de l’IA est probablement liée à l’article Imitation Game [Tur50] [Web03] du génie informaticien Alan Turing [Web04] en 1936. Ce test rebaptisé test de turing [Web05] en 1950 consistait à mettre en évidence l’intelligence avec laquelle une machine Modèles et protocoles de coordination pour la reconfiguration dynamique des architectures logicielles embarquées Page 29 arrive à soutenir une conversation avec l’homme. Ce dernier ne sent pas le caractère automate de la machine. Cette machine a su adopter le comportement humain. A partir de ce test naquit le concept de « machine consciente ». Ce concept fut introduit et défendu par Turing dans plusieurs conférences internationales : • La conférence « L’intelligence de la machine, une idée hérétique », • Dans la conférence qu’il donne à la BBC 3e programme le 15 mai 1951 « Les calculateurs numériques peuvent-ils penser ? » • La discussion avec M.H.A. Newman, Sir Geoffrey Jefferson et R.B. Braithwaite les 14 et 23 janvier 1952 sur le thème « Les ordinateurs peuvent-ils penser? » Cette science a été développée par l’imminent chercheur John McCarthy [Web06] de l’université Stanford avec son collègue et cofondateur Marvin Lee Minsky [Web07] du MIT. En effet, l’IA est une science dédiée aux robots (nanordinateurs) et aux logiciels afin de les rendre intelligibles via des algorithmes implémentés en eux. Ces algorithmes dictent l’exécution des tâches accomplies par ces robots et logiciels de cette nouvelle ère. Jadis, ces tâches n’étaient accomplies que par les êtres humains dues à leur complexité. Leur exécution sollicite un certain niveau d’intelligence, de perception (sensibilité auditive, visuelle, tactile ou d’autres capteurs) et de raisonnement critique. Ainsi, l’IA est à la suite d’une évolution de plusieurs domaines de recherche qui sont : • Recherches opérationnelles [Web08] dans les années 60, • Supervision [Web09] dans les années 70, • Aide à la décision [Web10] dans les années 80, • Data mining [Web11] dans les années 90. 

Différence entre l’intelligence artificielle forte et l’intelligence artificielle faible 

Le concept d’IA faible cherche à créer des machines de plus en plus autonomes afin de réduire les couts de supervisions. En effet, ces supervisions des machines sont effectuées par des hommes. Les chercheurs de l’IA faible conçoivent des algorithmes capables de résoudre des problèmes d’une classe bien déterminée. Ainsi, ces machines dotées d’IA faible simulent l’intelligence. En effet, ELIZA[Web12] [Web13] est un programme d’IA faible créée par Joseph Weizenbaum [Web14]. ELIZA simule le comportement (jeux de questions, réponses) d’un psychothérapeute rogérien avec son patient. Dans son ouvrage « Computer Power and Human Reason », Joseph Weizenbaum affirme que ces programmes informatiques simulent leurs intelligences. En effet, son ELIZA répond souvent par « Je comprends ». Cependant, le programme en réalité ne comprend pas son interlocuteur. Modèles et protocoles de coordination pour la reconfiguration dynamique des architectures logicielles embarquées Page 30 Le concept d’IA forte définit une machine capable non seulement d’effectuer des tâches de façon intelligente, d’éprouver une réelle conscience de soi, de vrais sentiments et de comprendre chacune de ses actions. De nos jours, les chercheurs défendent l’hypothèse de créer une intelligence consciente sur un support matériel. Selon les scientifiques, l’obstacle à créer une machine aussi consciente et intelligente que l’être humain ne réside pas sur l’aspect matériel mais plutôt sur la capacité de créer des algorithmes performants. 

 Méthodes implémentés par l’IA

 En effet, l’IA développe des méthodes mathématiques permettant de rendre le système intelligent grâce à leur étape d’apprentissage par les expériences. Les méthodes les plus utilisées sont : • Les arbres de décision [Qui86] [Bre84], • Les réseaux de neurones, • La régression multiple [Fat13], • La logique floue [Bou07]. En effet, les méthodes qui sont les arbres de décision, les réseaux de neurones et la logique floue feront l’objet de recherche approfondie dans la suite. a) Les arbres de décision L’arbre de décision est un outil d’aide à la décision qui connait un énorme succès. Il intervient dans des domaines variés (datamining ou fouille de données, sécurité, médecine, …). L’arbre de décision est une représentation lisible mettant en évidence les variations d’une variable à prédire (variable cible, variable de sortie) qui est la racine en fonction des variables descriptives (variables d’entrée, variables explicatives). Ces variables constituent les différentes branches à partir desquelles sortent les feuilles qui sont les résultats escomptés. Son succès est dû à: 1. Sa lisibilité de représentation : En effet, l’arbre de décision met en évidence la variable cible (nœud initial), ses relations entre les autres variables (nœuds fils) et ses différentes valeurs ou classes possibles (feuilles). 2. Sa capacité de sélection rapide des critères discriminants de la variable à prédire malgré l’importance de la base à explorer (la base échantillon). La figure ci-dessous met en évidence l’architecture d’arbres de décision.  

Table des matières

 Dédicaces
Remerciements
Résumé
Abstract
Liste des figures
Liste des tableaux
Liste des formules
Liste des abréviations
Introduction générale
Contexte de la thèse
Problématiques et Objectifs de la thèse
Plan de la thèse
Première partie: Etat de l’art
Chapitre 1 : Rappels sur les concepts
1.1 Introduction
1.2 Définition des concepts
1.2.1 Architecture logicielle embarquée
1.2.2 Configuration
1.2.3 Reconfiguration
1.3 Les Types de changement dans un système
1.3.1 Les changements de structure
1.3.2 Les changements de déploiement
1.3.3 Les changements d’interface
1.3.4 Les changements d’implémentation
1.4 Les catégories d’adaptation
1.4.1 Le plan constructible
1.4.2 Le plan prédéfini
1.4.3 Le plan intelligent
1.5 L’intelligence artificielle
1.5.1 Différence entre l’intelligence artificielle forte et l’intelligence artificielle faible
1.5.2 Méthodes implémentés par l’IA
1.5.3 Langages de programmation de l’IA 4
1.5.4 Domaines d’application dynamique des architectures logicielles embarquées
1.6 Conclusion
Chapitre 2 : Analyse et conception de système embarqué à temps réel
2.1 Introduction
2.2 L’ingénierie dirigée par les modèles
2.2.1 Le langage de modélisation UML (Unified Modeling Language)
2.2.2 UML profil MARTE
2.2.3 AADL
2.2.4 Spécification PEARL et le profil UML-RT
2.3 Les algorithmes d’ordonnancement
2.3.1 Ordonnancement par priorité statique
2.3.2 Ordonnancement par priorité dynamique
2.4 Frameworks de vérification
2.4.1 Cheddar
2.4.2 TASM Toolset
2.4.3 ModSyn
2.4.4 VERTAF
2.5 Intergiciels dédiés aux systèmes embarqués
2.5.1 DynamicTAO
2.5.2 CIAO
2.5.3 SwapCIAO
2.5.4 FLARe
2.5.5 PolyORB_HI
2.6 Processus et frameworks de développement 6
2.6.1 ModES
2.6.2 Framework dirigé par les modèles
2.6.3 CoSMIC
2.6.4 Ocarina
2.6.5 TimeAdapt
2.7 Conclusion
Deuxième partie: contributions
Chapitre 3: Processus de développement des systèmes embarqués dynamiquement reconfigurables
3.1 Introduction
3.2 Description de notre Processus de développement
3.3 Concepts de modélisation
3.3.1 MetaMode, MetaTransition, Mode, Transition 69
3.3.2 Illustration des concepts : Une machine à laver Hi-Tech
3.3.3 M4DRES (Modeling For Dynamically Reconfigurable Embedded Systems)
3.4 Vérification des contraintes non fonctionnelles
3.4.1 Introduction
3.4.2 Les propriétés non fonctionnelles
3.4.3 La consommation du CPU et le respect des échéances des tâches
3.4.4 La consommation de la mémoire et de la bande passante
3.4.5 L’absence de l’interblocage et de la famine
3.5 Conclusion
Chapitre 4 : Intergiciel dédié aux Systèmes embarqués à temps réel dynamiquement reconfigurables
Et Evaluation de nos contributions
4.1 Introduction
4.2 La plateforme d’exécution PolyORB_HI
4.2.1 Services canoniques de PolyORB_HI
4.2.2 Familles des services canoniques
4.2.3 Support des constructions de systèmes embarqués dynamiquement reconfigurables
4.2.4 Faible empreinte mémoire
4.3 Description de notre intergiciel dédié pour les systèmes embarqués dynamiquement reconfigurables
4.3.1 Fonctionnalités attendues
4.3.2 Modèle de notre intergiciel
4.4 L’évaluation de nos contributions
4.5 Conclusion
Chapitre 5 : Outillage du processus de développement
5.1 Introduction
5.2 L’architecture de la suite d’outils
5.3 Les outils de modélisation
5.3.1 L’environnement Eclipse Papyrus
5.3.2 Le profil M4DRES dans Eclipse Papyrus
5.4 Les outils de vérification
5.5 Les outils de génération
5.6 Conclusion
Chapitre 6 : Etude de cas -Ecran Publicitaire Intelligent
6.1 Introduction
6.2 Description du système
6.3 Modélisation du système EPI avec M4DRES
6.3.1 Architecture logicielle du système
6.3.2 Architecture matérielle du système
6.3.3 Allocation
6.4 Vérification des propriétés non fonctionnelles du système
6.5 Construction automatique d’une partie de notre système EPI
6.6 Conclusion
Chapitre 7 : Evaluation de performances
7.1 Introduction
7.2 Méthodes d’évaluation de performance des systèmes
7.2.1 Réseaux de file d’attente
7.2.2 Réseaux de pétri (RdP)
7.2.3 Réseaux de pétri stochastiques (SPN)
7.2.4 Réseaux de pétri stochastiques Bien Formés (SWN)
7.3 Modèle SWN et calculs de performance du système EPI
7.4 Conclusion
Conclusion générale et Perspectives
Rappel de problématique
Contributions
Perspectives
Bibliographie
Webographie
Annexe
Liste des publications

projet fin d'etudeTélécharger le document complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *