Complexité grandissante des développements de systèmes d’information

Télécharger le fichier original (Mémoire de fin d’études)

Contexte

La contribution de cette thèse vise à résoudre deux problèmes majeurs pour le déve-loppement logiciel de systèmes adaptatifs : l’hétérogénéité des plates-formes d’exécution et l’utilisation des ressources de calcul distribuées. Ces besoins sont particulièrement important dans les systèmes d’information de terrains dont une illustration est donnée avec le projet DAUM détaillé en section Le reste du chapitre détaille les définitions des grandes approches et modèles de développement communément exploités pour ré-pondre aux deux problèmes identifiés : développement hétérogène 2.2 et distribué 2.3. Ces définitions seront par la suite exploitées dans le chapitre 3 dressant l’état de l’art du domaine.

Cas d’étude : projet DAUM

Depuis 2009, des réflexions ont été engagées avec les pompiers du Service Départe-mental d’Incendie et de Secours d’Ile-et-Vilaine (SDIS35) pour l’élaboration d’un sys-tème tactique de terrain informatisé pour les opérations d’urgence. Sur bien des aspects ce type de système rentre dans la catégorie de systèmes visée par la contribution de cette thèse. Le projet Dynamic Adaptation Using Models (DAUM) qui résulte de ces réflexions a joué un double rôle. D’un coté c’est un cas d’étude qui permet d’extraire et d’illustrer les besoins d’un système adaptatif distribué, de l’autre c’est une étude de validation puisque le prototype du projet a été réalisé avec les travaux de cette thèse.

Un besoin d’information sur le terrain

Sur le terrain et lors d’une intervention, les pompiers ont besoin d’échanger des in-formations en temps réel sur la situation des moyens, des personnels engagés et sur les actions en cours et à venir. Les données tactiques des actions et moyens sont synthétisées via une notation graphique nommée Tactical Reasoning Method (TRM). Actuellement, ces données collectées sont échangées via des canaux de communication radio et re-produits sur des tableaux blancs dans des centres de commandement pour illustrer la situation courante et tracer l’historique des positions des moyens mis en oeuvre. Sur le terrain les groupes de personnels sont organisés sous la forme d’une arborescence hiérarchique. Un chef est donc désigné, ayant sous ses ordres un groupe d’hommes et des sous-groupes sur lesquels il a la visibilité des informations tactiques.
L’adaptation est inhérente au fonctionnement des pompiers, en eﬀet les missions montent en puissance en fonction des besoins, ajoutant ainsi sur place du personnel, et des véhicules. Ces changements impactent du même coup l’organisation hiérarchique, géographique et donc la topologie des échanges radio associés.

Des noeuds de calcul et un réseau maillé de terrain

La solution envisagée par le projet DAUM consiste à informatiser l’ensemble de la chaîne de collecte et diﬀusion des informations tactiques mais également de les enrichir avec des informations biométriques sur les personnels. Pour cela, chaque responsable d’un secteur et chaque oﬃcier impliqué dans la chaîne de commandement doit disposer sur le terrain d’une tablette tactile ou d’un tableau tactile pour présenter et éditer la situation tactique. Ces tablettes doivent s’organiser en topologie réseaux pairs-à-pairs pour déployer sur le terrain un réseau maillé permettant de résister à la perte de noeud. En eﬀet tout matériel utilisé en intervention a de grande chance d’être endommagé ou d’être simplement hors connexion aboutissant à une topologie réseau très dynamique.
A cela s’ajoute un équipement embarqué dans les vêtements de sécurité des per-sonnels. Reliés à des capteurs biomédicaux (rythme cardiaque, analyse de température corporelle, de stress), de positionnement géographique (GPS, triangulation réseau) et d’analyse des températures environnantes (température du sol et plafond) ces dispositifs sauvegardent l’ensemble des informations récoltées par un porteur. Ils peuvent égale-ment s’adapter suivant les diﬀérentes interventions (risque chimique, feu, etc) et avertir le porteur d’évènements urgents.
Enfin des ordinateurs de soutien permettent de stocker et redistribuer les données récoltées des informations tactiques et des données des capteurs de terrain. Ces noeuds sont embarqués dans les véhicules et participent aux échanges de données dans un réseau maillé de terrain entre les noeuds de capteurs, les tablettes et les ordinateurs de soutien. La sauvegarde et la traçabilité historique des données est un besoin légal vis à vis de la législation française, ces noeuds sont synchronisés pour la même raison avec les centres de commandement régionaux (CODIS). La figure 2.1 illustre le réseau de terrain global envisagé pour les interventions

Challenge de modélisation de la solution

Ce type d’architecture met particulièrement en lumière les besoins de gestion d’adap-tation dans les plates-formes hétérogènes. En eﬀet les tablettes de commandement ex-ploitaient des architectures à basse/moyenne consommation sur des processeurs de type ARM, tandis que les noeuds de soutien, alimentés par plus d’énergie peuvent être plus puissants. A l’opposé, les noeuds capteurs dans les vêtements sont des architectures à très basse consommation de type micro-contrôleur. La distribution du logiciel sur des noeuds hétérogènes est donc inhérente au cas d’usage qui doit faire collaborer ces noeuds dans un réseau commun. L’adaptation est inhérente au métier même des pompiers, en eﬀet tous les noeuds doivent faire face à des reconfigurations dynamiques. En eﬀet, les noeuds tablettes doivent changer leur mode de communication suivant le rôle du porteur tandis que les noeuds capteurs changent le type et la fréquence de mesure suivant le type de sinistre ainsi que le type de communication (radio longue ou courte portée) de façon opportuniste. Tous les noeuds doivent également faire face à des changements de topologie qu’ils soient dus à l’arrivée de renfort ou à la perte d’un noeud en défaillance, ce qui dans ce contexte hostile est plus qu’envisageable.
Pour conclure cette architecture nécessite réellement une conception qui lui permet de se surveiller afin de parer aux aléas de fonctionnement et d’assurer en cas d’urgence un service minimum, ce qui est typiquement le but d’un système DDAS tel qu’envisagé dans cette thèse. Ainsi l’objectif de cette thèse est de fournir une abstraction support pour le développement de logiciels répondant à ce type de problèmes, pour permettre par exemple de déplacer des composants logiciels d’une tablette à une autre, ou encore afin de les faire collaborer pour faire de l’agrégation des informations de terrain.

Développement pour plate-forme hétérogène

Les problèmes de développement pour des plates-formes diﬀérentes est un problème récurrent qui tire ses racines depuis la standardisation des premières architectures maté-rielles. En eﬀet depuis l’opposition entre les architectures PowerPC et x86 les subtilités d’exécution telles que les environnements de mémoire big et little endian poussent les langages de développement à fournir des solutions pour s’en abstraire.
Les mécanismes permettant de s’abstraire des spécificités matérielles sont multiples et possèdent chacun leurs atouts. Les approches par langages interprétés ou par machine virtuelle, interprètent tardivement une représentation abstraite commune, tandis que les approches par frameworks et par méthodes génératives issues du monde MDA visent à encadrer les primitives données aux développeurs pour éviter d’exploiter du code spécifique.
Cette section passe en revue ces mécanismes couramment utilisés afin de pouvoir expliquer les choix de solution pour gérer l’hétérogénéité dans l’étude de l’état de l’art mais également dans l’abstraction et la méthodologie proposée.

Abstraction et framework

Une première approche afin de lisser et masquer les diﬀérences d’exécution des plates-formes est d’exploiter un framework qui définit un sous-ensemble commun de ce qui est manipulable (API) et fournit ensuite une implantation ou interprétation de ce sous-ensemble pour un certain nombre de plates-formes. Cette approche a deux avantages, elle est extensible : par nature on peut fournir de nouvelles implantations pour de nouvelles plates-formes. Mais surtout elle découple le code métier des implantations en forçant le développement au travers de l’API, ceci permettant après coup de choisir de déployer avec telle ou telle plate-forme. La limitation qui en découle est que l’API borne les possibilitées des utilisateurs qui ne peuvent alors plus exploiter les spécificités des plates-formes par exemple pour faire des optimisations. Néanmoins cette approche est largement exploitée depuis les premiers langages assembleurs .

Table des matières

0 Résumé de thèse
0.1 Contexte : vers des systèmes distribués dynamiquement adaptables
0.2 Contribution
I Contexte, pré-requis et état de l’art
1 Introduction
1.1 Complexité grandissante des développements de systèmes d’information
1.2 Systèmes éternels et adaptation continue, du cycle en V vers le déploiement
continu
1.3 Mode@Runtime : couche de réflexion de système DAS
1.4 Vers des systèmes hybrides distribués, hétérogènes, adaptatifs
1.5 Challenges et points de contribution
1.6 Organisation du document
1.7 Liste des publications liées à cette thèse
2 Contexte
2.1 Cas d’étude : projet DAUM
2.1.1 Un besoin d’information sur le terrain
2.1.2 Des noeuds de calcul et un réseau maillé de terrain
2.1.3 Challenge de modélisation de la solution
2.2 Développement pour plate-forme hétérogène
2.2.1 Abstraction et framework
2.2.2 Langage interprété
2.2.3 Machine virtuel et Just-In-Time compiler
2.2.4 Approche générative et IDM
2.2.4.1 Générateur au design
2.2.4.2 Principes et généralités de l’IDM
2.2.4.3 IDM pour les approches génératives
2.2.4.4 Approche mixte API et génératif
2.3 Développement pour environnement distribué
2.3.1 Processus et échange synchrone et asynchrone
2.3.2 Modèle de programmation évènementiel
2.3.3 Socket et port réseau
2.3.4 Remote Procedure Call et Service
2.3.5 Bus de messages
2.3.6 Gestion de processus concurrents locaux et distants
2.3.7 Patron et style d’architecture
2.3.8 Algorithmes de consensus
2.3.9 Algorithmes épidémiques
2.3.10 Cohérence à terme
3 Etat de l’art
3.1 Système autonomique et boucle d’adaptation
3.1.1 Akka : Exploiter les erreurs dans le design (Fault as first class
entity)
3.1.2 Du design au runtime : chargement à chaud et déploiement
3.2 Critères d’évaluation
3.3 Approches permettant l’Introspection et l’Intercession
3.3.1 Approches basées sur la notion de composant
3.3.1.1 Une classification difficile et multiple
3.3.1.2 Fractal
3.3.1.3 Standard SCA / Projet FraSCAti
3.3.1.4 ArchJAVA
3.3.1.5 OSGi / DOSGi
3.3.1.6 iPOJO
3.3.1.7 Projet SAM / Modèle iPOJO
3.3.1.8 SOFA 2.0
3.3.1.9 Rainbow
3.3.1.10 Darwin
3.3.1.11 Modèle DIF et plateforme Prism-MW
3.3.2 Agent et Acteurs
3.3.2.1 Jade
3.3.2.2 S4
3.3.3 Model@Runtime
3.3.3.1 Genie
3.3.3.2 SmartAdapters / Modèle ART
3.4 Dissémination et distribution des adaptations
3.4.1 Disséminiation incrémentale de modèle d’adaptation
3.4.2 Algorithmes de dissémination dans des réseaux complexes
3.5 Synthèse et enjeux
II Thèse et Application
4 Concepts généraux de la contribution
4.1 Idée générale
4.1.1 Un modèle commun pour les étapes du cycle de vie logiciel
4.1.2 Mise à jour de DDAS par propagation de modèle
4.1.3 La divergence pour la performance et la résilience
4.1.4 L’hétérogénité des algorithmes de convergence
4.1.5 L’hétérogénéité des types d’adaptation
4.2 Propriétés attendues de la solution
4.2.1 Séparation des préoccupations pour maximiser la réutilisation
4.2.2 Modèle extensible et versatile pour l’hétérogénéité des capacités
de synchronisation et d’adaptation
4.2.3 Divergence de modèle pour la résilience aux fautes des noeuds
5 Modèle de composant étendu
5.1 Ensemble minimaliste des modèles CBSE
5.2 Type définition, type, Instance
5.3 Cycle de vie
5.4 Composants
5.4.1 ServicePortType
5.4.2 MessagePortType
5.4.3 Modèle de concurrence des ports
5.5 Canaux de communication : channels
5.5.1 Des connecteurs aux middlewares : motivation pour une modélisation
d’architecture de la communication
5.5.2 Définition des channels
5.5.3 Pourquoi une nouvelle entité et non des composants dédiés ?
5.5.4 Modèle de concurrence
6 Model@Runtime distribué
6.1 Modèle de déploiement
6.1.1 Modèle de DeployUnit
6.1.1.1 Relation de similarité des unités de déploiement
6.1.1.2 Graphe de dépendance
6.1.1.3 Hétérogénéité des binaires
6.1.2 Résolution et sélection de binaire
6.1.2.1 Relation de conformité par plate-forme
6.1.2.2 Sélection de dépendance nécessaire par plate-forme
6.2 Modèle de Noeud : conteneur d’instances et sémantique d’adaptation
6.2.1 Noeud Kevoree : pilote d’adaptation de plate-forme pour un processus
Model@Runtime
6.2.2 Méta-modèle d’adaptation
6.2.3 Responsabilités et fonctionnalités d’un noeud type
6.2.4 Extensibilité des NodeType : héritage
6.2.5 Modèle d’adaptation et comparaison de modèle
6.2.5.1 Extension de l’opérateur d’intersection
6.2.5.2 Planification
6.2.5.3 Détail du processus Kompare
6.2.6 Mapping vers plates-formes concrètes
6.2.6.1 Classification des niveaux d’adaptation
6.2.7 Modèle de topologie
6.2.7.1 Lier les informations topologiques au modèle structurel
6.3 Model@Runtime Core
6.3.1 Définition
6.3.2 Exécution de modèle d’adaptation et reprise sur erreur
6.3.3 Extensibilité et interruptilibilité du processus Core
6.3.3.1 Difficulté de la notion d’ordre et de composition des ModelListeners
6.3.4 Model@Runtime service : Api Mape
6.3.4.1 Accès concurrent local au service Model@Runtime
6.4 Groupes de synchronisation
6.4.1 Encapsulation des sémantiques de synchronisation
6.4.2 Fragmentation des groupes
6.4.3 Problème du Hara-Kiri
6.4.4 Consensus du DDAS sur un modèle : groupe Paxos
6.4.5 Consensus de migration ou consensus de mise à jour
6.4.6 Groupe exclusif ou lock-free
6.4.7 Groupe pour les réseaux P2P : association de Gossip et VectorClock118
6.4.7.1 Objectifs et spécificité d’une dissémination P2P
6.4.7.2 Une architecture moyenne calculée comme une agrégation
épidémique gossip
6.4.7.3 Principe de combinaison des horloges vectorielles ainsi
qu’une propagation gossip
6.4.7.4 Protocole gossip pour dissémination de Model@Runtime
6.4.8 Propriétés attendues
6.4.8.1 Propriétés de convergence
6.4.8.2 Complexité temporelle
6.4.8.3 Propriétés de résilience à l’intermittence des connexions
6.4.8.4 Complexité en nombre de messages
6.4.9 Slicing de modèle à l’image du peer sampling
6.5 Discussion sur l’impact du modèle Kevoree sur la construction du DDAS
III Validation
7 Axes d’évaluation
7.1 Une couche d’abstraction pour faire face à la complexité des DDAS
7.2 Des outils du design au runtime, à quel coût ?
7.3 Evaluation aux cas limites
7.4 Evaluation de la généricité de l’approche
8 Evaluation quantitative aux limites : gestion des environnements
contraints
8.1 Connecter les DDAS à leur contexte physique
8.1.1 Convergence de l’Internet des Objets et des Cyber Physical Systems138
8.1.2 Des DDAS aux CPS
8.2 Besoins spécifiques des systèmes adaptatifs contraints
8.3 Capacité des micro-contrôleurs vis-à-vis des niveaux d’adaptation Kevoree
8.4 Implantation d’un noeud Arduino Kevoree
8.5 Validation expérimentale sur micro-contrôleur
8.5.1 Axes d’évaluation
8.5.2 Protocole expérimental général
8.6 Downtime : combien de temps les adaptations bloquent-elles la logique
métier ?
8.6.1 Configuration expérimentale
8.6.2 Limites de validité expérimentale
8.6.2.1 Interne
8.6.2.2 Externe
8.6.3 Resultats et analyse expérimentale
8.6.4 Extension expérimentale pour connaitre l’impact du type de mémoire.
8.7 Utilisation de la mémoire volatile : combien d’instance déployable ?
8.7.1 Protocole expérimental
8.7.2 Limites de validité expérimentale
8.7.2.1 Interne
8.7.2.2 Externe
8.7.3 Résultats expérimentaux et analyse
8.8 Utilisation de la mémoire persistante : combien de reconfigurations successives
peuvent être déployées ?
8.8.1 Limites de validité expérimentale
8.8.1.1 Interne
8.8.1.2 Externe
8.8.2 Résultats et analyse
8.9 Délai de redémarrage : combien de temps pour la récupération d’état ?
8.9.1 Limites de validité expérimentale
8.9.1.1 Interne
8.9.1.2 Externe
8.9.2 Résultats expérimentaux et analyse
8.10 Comparatif vis-à-vis d’un micro-logiciel non généré
8.11 Conclusion vis-à-vis des axes d’évaluation
9 Évaluation quantitative aux limites : adaptation de DDAS en environnement
mobile
9.1 Validation expérimentale sur cluster de simulation
9.2 Protocole expérimental commun
9.2.1 Modèle de topologie initiale
9.2.2 Horloge de temps absolu pour la collecte des traces d’exécution
9.2.3 Mode de communication
9.3 Études expérimentales
9.3.1 Délai de propagation vis-à-vis de l’usage du réseau de communication
9.3.1.1 Protocole expérimental
9.3.1.2 Limites de validité expérimentale
9.3.1.3 Analyse des résultats expérimentaux
9.3.2 Impact des erreurs de communication sur les délais de propagation
9.3.2.1 Protocole expérimental
9.3.2.2 Limites de validité expérimentale
9.3.2.3 Analyse des résultats expérimentaux
9.3.3 Réconciliation de modèle et reconfiguration concurrente
9.3.3.1 Protocole expérimental
9.3.3.2 Limites de validité expérimentale
9.3.3.3 Analyse des résultats expérimentaux
9.4 Conclusion sur l’usage des groupes pour la convergence
10 Ecosystème Kevoree et validation par les projets liés
10.1 Concrétisation du modèle et éléments validant l’utilisabilité de Kevoree
10.1.1 Implantation sous la forme d’un projet open source
10.1.2 Implantation d’outils et langages dédiés pour la construction de
composants et manipulation de modèles d’architectures
10.1.2.1 Notation graphique d’architecture
10.1.2.2 KevScript : DSL de manipulation de modèle d’architecture170
10.1.2.3 Model2Code et Code2Model
10.1.2.4 Kevoree IDE, environnement de modélisation d’architecture
10.1.3 Passage de l’abstraction à l’implantation : adaptation des outils
de modélisation pour une exploitation à l’exécution
10.1.3.1 Kevoree Modeling Framework
10.1.3.2 Implantation des noeuds
10.1.3.3 Maturité du projet
10.1.4 Évaluation de prise en main par un panel de chercheurs et d’étudiants
10.2 Validation de la versatilité par la généralisation via des collaborations
10.2.1 Projet Entimid
10.2.2 Projet DAUM
10.2.3 Kevoree pour le cloud
10.2.3.1 Considérer les clouds comme un DDAS hiérarchique
10.2.3.2 Du cloud au sky computing dirigé par les modèles
10.2.3.3 Gérer les clouds comme des DDAS, une validation de la distribution large échelle et hétérogène
11 Conclusion de validation
IV Conclusion et perspectives
12 Conclusion
12.1 Une convergence des systèmes distribués par nature hétérogènes
12.2 L’abstraction en réponse à la complexité de conception
12.3 La divergence : outil pour la distribution
12.4 Utiliser le Model@Runtime comme couche de réflexion de DDAS
12.5 Kevoree : une approche générique, expressive et performante du Model@
Runtime distribué
12.6 Une modélisation générique des systèmes adaptatifs qui s’inscrit dans une
convergence CPS et Cloud
13 Perspectives
13.1 Génération continue d’architecture
13.1.1 Approche génétique pour la résolution multi-axiale
13.1.1.1 Cas d’étude : optimisation de réseaux de capteurs
13.1.1.2 Évaluation du domaine d’exploration
13.1.1.3 Approche : définition de mutation au niveau modèle
13.1.1.4 Résultats préliminaires
13.1.2 Fragment / Aspect / Patron d’architecture
13.1.3 Utilisation continu de modèle de contexte
13.2 Modéliser la dynamicité des protocoles eux-mêmes
13.3 Apprentissage d’erreur opportuniste
13.4 Kevoree pour le cloud computing
13.5 Adaptation d’interface : exploiter Kevoree dans un naviguateur Web
13.6 Couplage modèle comportemental et modèle d’architecture
13.7 Chargement de code à chaud et sécurité des plates-formes Java et Dalvik
Bibliography
Acronyms
Table of figures
V Annexe
Sommaire