Gestion autonomique de la QoS au niveau middleware dans l’IoT

Les prémices de l’Internet datent des années 1λ60 [kle61]. Basiquement, il permet d’interconnecter des réseaux de machines (ordinateurs et autres) à des fins de communication dans le cadre de logiciels distribués entre ces machines. De par l’évolution de ses différents piliers (infrastructure, protocoles, applications, usages, etc.), l’Internet constitue l’une des révolutions technologiques majeures de ces dernières décennies. Différentes voies d’évolution de l’Internet sont aujourd’hui considérées. La plus récente est relative à son expansion au monde physique à travers tous les types possibles d’équipements connectés, c’est-à-dire dotés de moyens de communication informatique. Plusieurs paradigmes ont ainsi vu le jour en fonction des périmètres couverts, des parties prenantes et des scénarios métiers considérés. Actuellement, le paradigme de l’Internet des objets (IoT – Internet of Things) en constitue l’un des plus importants.

Ce paradigme, qui étend le concept de M2M (Machine-to-Machine), permet d’interconnecter toute sorte d’équipements de la vie quotidienne, pour permettre la capture à distance d’événements (température, humidité, présence, etc.) via des capteurs, mais également le contrôle de l’environnement via des actionneurs. Ce paradigme ouvre la voie à de nouveaux usages tels que la domotique, la télésurveillance des biens et des patients, ou encore le suivi des états des machines au travers du concept d’usine du futur. L’utilisation de l’IoT dans ces contextes est amenée à apporter une véritable valeur ajoutée tant du point de vue du consommateur que du producteur de service.

Plusieurs visions architecturales sont proposées pour la structuration de l’IoT. Celle que nous retenons pour notre contexte est constituée de quatre niveaux. Le premier est le niveau Équipements qui est constitué de l’ensemble des équipements IoT (capteurs, actionneurs, tags, etc.). Il est suivi du niveau Réseau qui comporte l’ensemble des technologies réseaux d’interconnexion, nécessaires aux différentes interactions. Le niveau Intergiciel (Middleware en anglais) qui offre aux applications une couche d’abstraction pour, notamment, faciliter leur interaction avec les niveaux sous-jacents. Enfin, le niveau Application qui consiste en l’ensemble des applications logicielles concourant, via leurs interactions avec les objets connectés, à la réalisation d’une activité métier. Plusieurs approches permettent d’implémenter le Middleware. Nous retrouvons par exemple des approches telles que RPC (Remote Procedure Call), SOA (Service Oriented Architecture) ou plus récemment ROA (Resource Oriented Architecture), cette dernière approche étant déclinée au travers des standards SmartM2M [ets690] et oneM2M [one15], dont plusieurs implémentations open source existent, notamment la plateforme OM2M [ben14]. Dans la suite, nous utiliserons le terme entité Middleware pour désigner toute instance logicielle de niveau Middleware.

Les spécificités de l’IoT conduisent à la reconsidération de nombreuses problématiques déjà abordées dans d’autres contextes plus traditionnels. Dans cette thèse, nous nous intéressons à la qualité de service (QoS – Quality of Service). Dans le domaine des télécommunications, l’ITU-T définit la QoS [itu08] comme l’ensemble des caractéristiques d’un service de télécommunication conduisant à sa capacité à satisfaire les besoins indiqués et implicites de l’utilisateur du service. Dans le contexte de l’IoT, elle se réfère à la capacité du système IoT et ses différentes couches à garantir les besoins non fonctionnels correspondants aux exigences des applications métiers.

Etat de l’art, problématique, positionnement et approche générale

De par la largeur de son spectre et les attendus qu’il suscite, l’IoT fait actuellement l’objet de nombreuses études de recherche, relevant tant de ses applications que de la reconsidération de problématiques initialement abordées dans l’Internet “classique”. Dans ce cadre, l’objectif final de ce chapitre est de présenter la problématique de nos travaux et d’y positionner notre approche générale de solution. Pour cela, nous exposons tout d’abord le contexte de nos travaux, à savoir l’IoT, ses applications et leurs besoins en QoS, ainsi que les limites actuelles de l’IoT à y faire face. Nous dressons ensuite un état de l’art des solutions envisagées au niveau Middleware pour l’IoT. Nous fournissons en particulier une analyse des capacités et des limites de ces Middlewares face aux besoins en QoS. Nous introduisons également les propositions de gestion de la QoS faites au travers de Middleware dédiés à d’autres domaines que l’IoT. Enfin, nous précisons le contexte et la problématique spécifiques de nos travaux et nous y positionnons notre approche pour une gestion de la QoS de bout en bout au niveau Middleware de l’IoT.

PARADIGME DE L’INTERNET DES OBJETS

Le qualificatif d’Internet des Objets (IoT) est apparu pour la première fois en 1999 [ash09]. Ce paradigme est considéré comme étant la prochaine génération de l’Internet [atz10, alf15]. Plusieurs définitions ont été données à l’IoT. Gartner [gar17] le définit comme étant “le réseau d’objets physiques qui contiennent des technologies intégrées pour communiquer et détecter ou interagir avec leurs états internes ou l’environnement externe”. L’IETF considère l’IoT comme étant une extension des technologies de l’actuel Internet et affirme qu’un véritable IoT exige que les objets doivent être capables d’utiliser les protocoles de l’Internet [ish13]. Une définition plus détaillée a été donnée par l’IERC (European Research Cluster on the Internet of Things) [ierc14] dans laquelle l’IoT est “une infrastructure de réseau globale dynamique avec des capacités d’auto-configuration, où les objets physiques et virtuels ont des identités, des attributs physiques et des personnalités virtuelles, et utilisent des interfaces intelligentes pour se connecter entre elles et au réseau de données”. Ce paradigme permet de couvrir un large éventail d’applications dans plusieurs domaines tels que la santé, la domotique, les services publics, les transports, ou encore les usines du futur.

Applications métier de l’IoT

Une application métier dédiée à l’IoT (application IoT) se caractérise par l’autonomie ajoutée à une activité métier, telle que la surveillance de patients à distance et l’intervention en cas d’urgence, à travers l’utilisation d’équipements de toutes sortes accessibles via l’Internet. L’autonomie qu’offre ces applications est destinée à permettre, par exemple, des économies de temps ou à réduire les risques d’erreurs, en minimisant autant que possible l’intervention humaine. Ces applications sont basées sur un ensemble d’échanges réalisés de manière essentiellement autonome entre les équipements, les entités intermédiaires et au final les humains via des moyens de communication, de nouvelles capacités de traitement de données offertes par le cloud computing, et des outils de gestion et d’analyse de ces données. Les applications IoT couvrent un large éventail de domaines. Elles sont qualifiées d’intelligentes (smart en anglais) par l’autonomie du service qu’elles fournissent aux utilisateurs finaux. Nous parlons à présent de Smart City, Smart Home, eHealth, Smart Energy, etc. Dans cette section, nous étudions trois catégories d’applications IoT, relevant respectivement du Smart Metering, du eHealth et du Smart Factory, dans le but de montrer la valeur ajoutée de l’utilisation de l’IoT du point de vue du consommateur et du fournisseur de services.

Smart Metering
L’économie d’énergie est une priorité mondiale pour la préservation de notre planète. Le contrôle de la consommation énergétique permet d’aller vers cet objectif. L’une des applications clés du Smart Grid est la mesure intelligente. Elle est basée sur des compteurs dits intelligents offrant une gamme de services tels que la mesure et l’enregistrement de la consommation (électricité, gaz, eau, etc.), le relevé de la consommation locale ou distant, la fixation du seuil de consommation maximale et l’extinction à distance de l’électricité par le consommateur, ainsi que l’échange d’informations sur la consommation avec les services publics.

Les compteurs intelligents sont considérés comme les successeurs des compteurs d’électricité mécaniques classiques dits muets. La différence est que, pour les compteurs intelligents, il n’y a pas besoin d’intervention humaine (Figure 1.1). Toutes les fonctionnalités se font automatiquement et à distance. D’ici fin 2020, le ministère de l’énergie et du changement climatique du gouvernement britannique prévoit d’équiper chaque maison du royaume avec des compteurs intelligents [uk17].

Au regard des avantages qu’offre une telle application, le consommateur et le fournisseur de services sont bénéficiaires. Le consommateur de service (le client final) a l’opportunité de réaliser des économies d’argent en ayant différentes vues de sa consommation, par exemple, la consommation en temps réel et son équivalent en euro, l’historique de la consommation et la visualisation des graphiques connexes, le coût quotidien, mensuel ou annuel, ainsi que sa capacité à contrôler à distance l’utilisation de ses ressources. Du point de vue du fournisseur de services (l’opérateur électrique), les coûts d’acquisition de données sont minimisés. Les agents, dont le rôle était auparavant dédié au déplacement pour l’acquisition manuelle de la consommation, peuvent maintenant être affectés à d’autres tâches. En outre, le fournisseur de services peut déterminer le comportement des utilisateurs liés à leur consommation énergétique pour une meilleure gestion des ressources.

eHealth
Le monde de la médecine (ou en général la santé) est en constante progression. Il commence à intégrer les méthodes et les ressources des technologies de l’information et de la communication. L’avènement des technologies de l’IoT permet d’envisager un saut substantiel. L’eHealth est l’un des sous-domaines les plus prometteurs de la télémédecine basée sur l’IoT. La Commission européenne [ehe17] le définit comme l’utilisation de technologies d’information et de communication modernes pour répondre aux besoins des citoyens, des patients, des professionnels de la santé, des fournisseurs de soins de santé, ainsi que des décideurs. Les applications IoT pour l’eHealth permettent [ets102] la surveillance à distance des informations sur la santé et la condition physique des patients, le déclenchement d’alarmes dans des conditions critiques et, dans certains cas, la maîtrise à distance de certains traitements ou paramètres médicaux.

Dans le passé, il n’y avait pas de surveillance à distance. Le patient devait être présent à l’hôpital, et dépendait des médecins et des équipements hospitaliers pour suivre et enregistrer les informations sur sa santé. Maintenant, les soins aux patients sont améliorés avec la surveillance à distance (Figure 1.2). La personne surveillée utilise des capteurs physiologiques portables formant un réseau BAN (Body Area Network). Ces capteurs recueillent et enregistrent différents signes vitaux tels que la fréquence cardiaque, la température corporelle, la pression artérielle, le taux respiratoire, les chutes et d’autres informations sur le patient. Les données collectées sont envoyées à un agrégateur (par exemple, le téléphone cellulaire du patient) qui est responsable de la transmission d’informations au centre de contrôle [wu11]. Grâce à ce système, les agents de santé peuvent exécuter des plans prédéfinis et intervenir lorsque des conditions critiques sont détectées en fonction des alarmes déclenchées.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela chatpfe.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

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 la 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
Conclusion générale

Lire le rapport complet

Télécharger aussi :

Laisser un commentaire

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