Modèle Analytique du Middleware et Application au Monitoring pour gestion locale de la QoS

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

INTRODUCTION

Le chapitre 3 a porté sur la partie structurelle de l’architecture du système IoT-Q. Dans ce chapitre, nous approfondissons la partie comportementale de cette architecture au travers du composant de planification du gestionnaire autonomique local (AMS) à chaque entité. En général, les approches envisagées pour la planification vont de l’utilisation de règles simples (de type “SI <X> est correct, ALORS faire <Y>”) jusqu’à des règles plus complexes basées sur des modèles descriptifs ou de décision [hol89]. Dans une approche orientée modèle, l’architecture du système géré, de ses entités constituantes, leurs relations ainsi que les transformations possibles doivent être modélisées. Trois types de modèles peuvent être utilisés dans cette approche. Les modèles prédictifs analysent les événements passés afin d’estimer le futur de manière probabiliste. Alors que les modèles descriptifs permettent de quantifier les relations entre les événements et de les classer en groupes. A l’opposé des modèles prédictifs, les modèles descriptifs identifient plusieurs relations entre les événements. Enfin, les modèles de décision ou de prise de décision qui élaborent les relations entre tous les éléments d’une décision (les événements connus, la décision et les résultats attendus de la décision) afin de prédire les résultats de ces décisions.
Les architectures logicielles peuvent être décrites via des modèles semi formels tel que UML 2.0. Cependant, dans un contexte tel que l’IoT susceptible d’engendrer des transformations structurelles de façon dynamique, c’est-à-dire durant le temps d’exécution du système, ce type de description gagne à être remplacé par des modèles plus adéquats [eic15]. Pour modéliser l’évolution dynamique d’une architecture, il existe des modèles, représentations et approches formelles de description basés notamment sur la théorie des graphes et sur des règles de réécriture associées [eic15]. Les graphes permettent alors de représenter les différentes configurations du système géré, les règles de réécriture formalisant leurs transformations.
La contribution générale décrite dans ce chapitre réside dans l’utilisation de techniques basées sur les graphes pour guider le comportement du système IoT-Q dans sa phase de planification. Ces techniques sont appliquées pour la planification des mécanismes orientés ressources (décrits dans le chapitre 2 ), dans le cadre d’un cas d’étude correspondant à une activité de supervision d’une zone à risques (en l’occurrence un métro doté de multiples capteurs et actionneurs) et d’intervention en cas de problème (incident ou danger).
Dans cette optique, ce chapitre présente deux contributions principales. Nous proposons tout d’abord une modélisation à base de graphe du cas d’étude considéré. Nous distinguons deux niveaux d’abstraction. Le premier niveau, dit métier, modélise les rôles et les interactions d’entités de haut niveau impliquées dans chacune des phases du cas d’étude. Le second niveau, dit opératoire, fait apparaître les applications logicielles impliquées ainsi que les entités Middleware nécessaires à leurs interactions avec les objets connectés. Pour chacun des niveaux, nous donnons la description du style architectural sous forme de productions de grammaires afin de modéliser les entités et les interactions.
La deuxième contribution s’inscrit dans la phase de planification des actions de gestion de la QoS dans les deux phases du cas d’étude. Nous proposons ainsi des règles de planification suivant une approche multi-modèles, couplant des techniques d’appariement et de transformation de graphes avec le modèle analytique de la plateforme Middleware décrit au chapitre 3. L’approche proposée permet tout d’abord de valider l’applicabilité des mécanismes orientés ressources envisagés. Elle permet ensuite de modéliser les modifications d’attributs ou de structure du graphe correspondant aux actions d’adaptation réalisées. À des fins d’illustration, un exemple simple de protocole de planification de la mise en œuvre de ces règles est également fourni. Dans la suite de ce chapitre, la section 5.2 détaille notre approche d’adaptation dynamique guidée par les modèles. Les différents niveaux d’abstraction ainsi que la gestion multi-modèles proposée sont présentés. La section 5.3 présente le cas d’étude de gestion d’une foule dans un réseau de lignes de métro ; un scénario en 2 phases (supervision et intervention) est exposé. Les niveaux d’abstraction considérés (métier et opératoire) sont finalement détaillés. Les sections 5.4 et 5.5 fournissent l’ensemble des propriétés architecturales ainsi que la description des styles architecturaux pour les niveaux métier et opératoire. Enfin, la section 5.6 présente les règles de reconfiguration structurelle, pour la gestion dynamique de l’architecture, issues de la composition du modèle analytique et des règles de réécriture de graphes. Nous terminons le chapitre par une Le contexte IoT est dynamique à la fois par les équipements, les ressources, les profils et les besoins en QoS des applications, qui sont susceptibles d’évoluer durant l’exécution du système dans son ensemble. Dans notre cas de gestion de la QoS exprimée par les applications IoT, les adaptations doivent se faire donc par le composant de planification de manière dynamique (c’est-à-dire sans interruption des services fournis aux applications). Pour ce faire, il existe des approches formelles issues de la théorie des graphes et de la transformation de graphes. Plusieurs approches pour la description des transformations de graphes ont été proposées, telles que par exemple DPO, SPO et edNCE [eng89].
Notre approche d’adaptation, guidée par des modèles multiples, couple ces techniques de description avec le modèle analytique proposé dans le chapitre 3. Le but est double μ il est d’une part de déterminer le paramétrage des mécanismes (par exemple, le nombre de cœurs à activer) a priori retenus par le composant de planification, et de valider l’applicabilité de ces mécanismes ; il est d’autre part de maintenir à tout moment un modèle du système résultant des actions d’adaptation réalisé, cohérent vis-à-vis du système réel.
Dans cette section, nous définissons tout d’abord ce que sont les architectures dynamiques. Nous présentons ensuite les approches de base pour la description de ces architectures. Enfin, nous détaillons notre approche d’adaptation guidée par les modèles en la positionnant vis-à-vis d’autres approches d’adaptation basées graphes.

Architecture dynamique et graphes de description

Les architectures peuvent être divisées en deux types selon leur capacité ou non à évoluer lors de l’exécution du système [mor07]. Nous distinguons ainsi les architectures statiques et dynamiques. Une architecture statique est une architecture dont la topologie (entités et liens d’interaction) n’évolue pas. Au contraire, la description d’une architecture dynamique ne peut, par essence, se limiter à une unique topologie. Elle se doit de caractériser l’ensemble des topologies possibles du système, c’est-à-dire l’ensemble des configurations que le système peut adopter. Cet ensemble est spécifié par un style architectural caractérisant les contraintes et les caractéristiques communes des configurations acceptables. Dans le contexte des architectures dynamiques, il est également nécessaire de caractériser les règles guidant le passage d’une configuration à une autre, dans le but d’assurer la validité des transformations. La description d’architectures dynamiques comporte donc trois grandes notions μ configurations, style architectural et transformations. Par essence, l’architecture du système que nous considérons est dynamique. Deux types d’adaptation sont considérés μ (1) une adaptation dite corrective guidée par des défaillances du système ou des contraintes de QoS non respectées durant une phase d’activité ; et (2) une adaptation dite évolutive suite à l’évolution de l’activité d’une phase vers une autre, induisant des changements dans les interactions et/ou dans les exigences de QoS.
La description des architectures dynamiques diffère de celle des architectures statiques. Ces dernières peuvent adopter, par définition, une unique topologie. Une description de celle-ci précisant ses différents composants et leurs interconnexions est donc suffisante pour décrire le système. Pour des architectures dynamiques, dont les composants et connexions peuvent être ajoutés, modifiés ou supprimés durant l’exécution du système, cette approche peut être transposée en énumérant l’ensemble des topologies acceptables du système. Ceci peut néanmoins s’avérer très largement inefficace, produire une telle énumération pouvant être une tâche ardue, voire totalement inapproprié s’il existe une infinité de topologies acceptables.
Les graphes constituent un puissant modèle de description des architectures dynamiques [luk13]. De manière basique, un graphe G peut être défini par un ensemble de nœuds N et un ensemble d’arêtes A, une arête reliant 2 nœuds (arrête de cardinalité 2). Par exemple, dans le cas d’architectures orientées composants, les nœuds correspondent aux composants logiciels et les arcs à leurs relations qui peuvent être des canaux de communication [gue06]. Des représentations plus riches sont basées sur des graphes orientés, des nœuds incluant des labels et des arêtes dotées d’étiquettes. Pour modéliser une architecture dynamique à partir des graphes, nous utilisons ici trois méta-modèles :
– des graphes pour représenter les configurations du système ;
– des règles de réécriture de graphe [eng97, ehr90] pour la spécification de transformations. Une règle de réécriture décrit à la fois les conditions d’application d’une transformation et ses effets. Elle précise un ensemble d’ajout/suppression d’arcs et de nœuds au sein d’un sous-graphe, caractérisant ainsi le passage de graphes modélisant le système dans des états donnés à de nouveaux graphes et états ;
– des grammaires de graphes pour la spécification générative de styles architecturaux.
Une grammaire de graphes est constituée entre autres d’un ensemble de règles de réécriture appelées productions de la grammaire. L’application d’une séquence quelconque de ces productions permet d’aboutir à une instance de déploiement de l’architecture compatible avec le style caractérisé par la grammaire.
Plusieurs approches de réécriture peuvent être utilisées pour la spécification des productions de grammaires et des règles de transformation. Les règles de réécriture les plus simples sont basées sur une paire (L; R) où L et R désignent des graphes appelés respectivement graphes mère et fille. Ce type de règle est applicable sur un graphe hôte G s’il existe une occurrence du graphe mère L dans G. Son application a pour conséquence la suppression de cette occurrence2 de L du graphe G et son remplacement par une copie (isomorphe) du graphe fille R. Le graphe issu de ces opérations est appelé graphe résultant G’. L’application de cette approche basique peut faire apparaître des arcs dits suspendus qui ne relient pas deux nœuds. Pour pallier à ce problème, deux approches principales existent [ekl90], l’approche SPO (Single PushOut) et l’approche DPO (Double PushOut).
L’apport de l’approche SPO est que des parties (nœuds et arcs) du graphe L seront préservées après l’application de la règle. Ces parties sont spécifiées en les faisant apparaître dans les deux graphes L et R. L’application de la règle implique la suppression du graphe correspondant à Del = (L\(L∩R)) et le rajout du graphe correspondant à Add = (R\(L∩R)). Selon l’approche

Table des matières

Introduction générale
Contexte et Problématique
Contributions
Structure du manuscrit
Chapitre 1 – Etat de l’art, problématique, positionnement et approche générale
1.1. INTRODUCTION
1.2. PARADIGME DE L’INTERNET DES OBJETS
1.2.1. Applications métier de l’IoT
1.2.2. Visions architecturales et challenges de l’IoT
1.3. APPLICATION MÉTIER DANS L’IOT ET BESOINS EN QoS
1.3.1. Types de données générées par les entités IoT
1.3.2. Types d’interactions entre les entités IoT
1.3.3. Besoins en QoS des applications IoT
1.4. SOLUTIONS AU NIVEAU MIDDLEWARE ET GESTION DE LA QOS
1.4.1. Styles architecturaux pour le Middleware
1.4.2. Propositions de niveau Middleware dans l’IoT
1.4.3. Gestion de la QoS au niveau Middleware
1.5. POSITIONNEMENT ET APPROCHE GENERALE DE GESTION DE LA QOS
1.5.1. Contexte spécifique
1.5.2. Problématique considérée
1.5.3. Approche générale de solution
1.5.4. Contributions de cette thèse
1.6. CONCLUSION
Chapitre 2 – Mécanismes de gestion de la QoS au niveau Middleware
2.1. INTRODUCTION
2.2. ENTITÉS MIDDLEWARE ET SOURCES DE TRAFIC
2.2.1. Entités Middleware
2.2.2. Sources de trafic
2.3. MÉCANISMES DE GESTION ORIENTÉS TRAFIC
2.3.1. Classification et Marquage du trafic
2.3.2. Proxy orienté priorités
2.3.3. Scénarios de validation des mécanismes orientés trafic
2.4. MÉCANISMES ORIENTÉS RESSOURCES
2.4.1. Approche de gestion verticale
2.4.2. Approche de gestion horizontale
2.4.3. Scénarios de validation des mécanismes orientés ressources
2.5. CONCLUSION
Chapitre 3 – Architecture de gestion autonomique et hiérarchique de la QoS
3.1. INTRODUCTION
3.2. APPROCHE D’ÉLABORATION
3.2.1. Paradigme de l’Autonomic Computing
3.2.2. Approche de gestion autonomique et hiérarchique du système IoT
3.3. SYSTÈME DE GESTION AUTONOMIQUE ET HIÉRARCHIQUE
3.3.1. Approches d’élaboration et exigences du système
3.3.2. Spécification et Conception du Système IoT-Q
3.4. CONCLUSION
Chapitre 4 – Modèle Analytique du Middleware et Application au Monitoring pour gestion locale de la QoS
4.1. INTRODUCTION
4.2. MODELE ANALYTIQUE DU MIDDLEWARE OM2M
4.2.1. Etude du Middleware OM2M
4.2.2. Modélisation Analytique
4.2.3. Paramètres du modèle pour le cas d’une Gateway
4.3. COMPOSANT DE MONITORING POUR L’AMS
4.3.1. Capteurs logiques de supervision
4.3.2. Architecture fonctionnelle du composant de Monitoring
4.3.3. Approches de Monitoring réactif et proactif
4.4. CONCLUSION
Chapitre 5 – Planification guidée par les modèles
5.1. INTRODUCTION
5.2. ADAPTATION DYNAMIQUE GUIDÉE PAR LES MODÈLES
5.2.1. Architecture dynamique et graphes de description
5.2.2. Positionnement de notre approche d’adaptation guidée par les modèles
5.3. ACTIVITÉ DE GESTION DE LA FOULE
5.3.1. Description du cas d’étude
5.3.2. Phases d’exécution
5.3.3. Niveaux d’abstraction
5.4. ARCHITECTURE AU NIVEAU MÉTIER
5.4.1. Style architectural correspondant à la phase de supervision
5.4.2. Style architectural correspondant à la phase d’intervention
5.5. ARCHITECTURE AU NIVEAU OPÉRATOIRE.
5.5.1. Style architectural correspondant à la phase de supervision
5.5.2. Style architectural correspondant à la phase d’intervention
5.6. ACTIONS DE RECONFIGURATION GUIDÉES PAR LES MODÈLES
5.6.1. Modèle analytique pour guider la planification
5.6.2. Gestion de la défaillance de la machine primaire
5.6.3. Gestion des exigences métier en QoS au niveau opératoire
5.6.4. Règles de reconfiguration dans le processus de planification
5.7. CONCLUSION
Conclusion générale et perspectives
SYNTHÈSE DES CONTRIBUTIONS
PERSPECTIVES
Publications de l’auteur
Liste des acronymes
Références