Le prototype déployé du système autonomique

Dans le contexte de la maquette de système IoT présenté ci-dessus, une instance du système de gestion autonome a été implémentée et déployée.

4.2.3.1 Diagramme de déploiement global et architecture (intégration avec oneM2M)

Le système de gestion autonomique implémenté en Java est déployé et intégré dans le système comme présenté dans la Figure 4.6.

Le système va être connecté à l’intergiciel OM2M via l’interface applicative (mca). L’intérêt du déploiement oneM2M est également de pouvoir réaliser des découvertes d’objets connectés au système mais aussi de s’abonner à ces derniers afin d’observer leurs changements d’état notamment, l’arrivée de nouveaux objets, etc.

Le gestionnaire autonome implémenté va se structure suivant différents compo-sants présentés en Figure 4.8.

4.2. Preuve de concept : prototype et déploiement 105

Figure 4.8 – Diagramme de composants haut-niveau du prototype de système autonomique implémenté

4.2.3.2 Les différents composants mis en œuvre

On peut ainsi voir comment les différents éléments de la boucle MAPE-K ainsi que les modèles sont instanciés. Le composant Model comporte le modèle qui inclue l’ontologie avec les différents individus et les règles SWRL, ainsi que le modèle de grammaire de graphes.

Le Moniteur est connecté au système via des souscriptions (Subscription avec un client REST oneM2M) afin d’être notifié lors des changements d’états des capteurs considérés (nouvelles valeurs disponibles, nouvel objet connecté, objet déconnecté, etc.). Par exemple, lorsque le capteur RFID va lire une nouvelle valeur, cet évè-nement sera détecté de même lorsqu’un capteur va produire un nouveau contenu (nouvelle valeur de température par exemple, un changement d’état au niveau du bâtiment connecté, etc.) et une notification sera reçue (HTTP). En fonction des dif-férents évènements qui occurrent sur le système supervisé, le moniteur va mettre à jour la base de connaissance sémantique avec de nouvelles méta-données actualisées ou non via le Contrôleur. Enfin, en fonction de ces évènements il va pouvoir générer des symptômes (un lot d’exemples est fourni en Annexe B dans la Table B.1). Ces symptômes peuvent amener l’analyseur à déclencher certaines actions comme l’infé-rence sémantique. Dans le cas où un symptôme est levé qui nécessite une infél’infé-rence, l’analyseur va travailler sur un instantané (snapshot) de l’ontologie à cet instant à l’aide de la OWL API et réaliser une inférence sémantique à l’aide d’un raisonneur. Une fois cette inférence réalisée, suivant les résultats obtenus un graphe de RFC sera généré à partir des informations connues dans la base de connaissance.

Le planificateur va recevoir ces graphes RFC par le biais d’un buffer permettant de stocker les graphes à traiter dans le cas où il y aurait plusieurs graphes générés rapidement. Ces graphes vont être transformés et ensuite transmis à l’exécuteur (via un buffer également).

L’exécuteur va lire les plans produits par le planificateur et récupérer les méta-données nécessaire à l’exécution (via la base de connaissance) à l’aide de la OWL API avant de l’exécuter littéralement. Ce dernier sera formé ici de services REST avec le protocole défini par oneM2M (en HTTP), et d’opérateurs permettant

d’arti-culer l’exécution. Les services utilisés ici sont ceux fournis via la plateforme OM2M et permettant à la fois de récupérer les données fournies par les objets (capteurs, etc.) mais aussi d’envoyer des contenus comme par exemple le contenu à afficher sur le terminal du bus. De fait l’interopérabilité syntaxique s’en trouve grandement fa-cilitée. Cependant, il également possible de faire appel à d’autres types de services, il est juste nécessaire de disposer d’un client (REST, SOAP, etc.) implémenté dans l’exécuteur pour l’appel de ces services dont les méta-données sont disponibles dans la base de connaissance.

4.2.3.3 Configuration du système autonomique et du prototype

Zone 1 2 3 4

Nom Init Industrial City Centre Museum

Contenu Temperature Temp. Particules Gaz Temp. Particules Temp. État du musée

Table 4.2 – Configuration du système de démonstration

Le système simulé est configuré tel que présenté dans la Table 4.2 avec diffé-rentes zones géographiques possible dans la ville intelligente et différents services fournissant des contenus (capteurs ou autres) afin de mettre en œuvre le scénario de diffusion autonome de contenu dynamique.

Les différents contenus fournis sont liés à différents sujets :

• informations générales, pour des données générales comme la température, des informations globales sur la ville, etc.

• la qualité de l’air, pour les données en rapport avec les particules présentes dans l’air, les mesures de gaz polluants, pollens, etc.

• musées, afin de regrouper des informations en rapport avec des institutions comme des musées (qui représentera ici le bâtiment connecté disponible) Dans le prototype, deux personnes sont considérées : P₁ et P₂.

• P₁ est intéressée par les informations générales et la qualité de l’air • P₂ est intéressée également par les informations générales et les musées De ce fait, lorsque de nouveaux contenus sont disponibles, le système va auto-matiquement décider comment faire parvenir les contenus aux entités concernées. 4.2.3.4 Résultats en fonctionnement

Des résultats ont été obtenus en jouant le scénario sur le système déployé pour montrer son bon fonctionnement. Ces résultats sont présentés dans la Table 4.3 ci-dessous. Le contenu affiché est obtenu quand le système va exécuter le plan d’exé-cution de services en récupérant les données à partir des services producteurs de contenu et envoyé les résultats agrégés (ou non suivant les cas) au service d’affichage du bus si nécessaire.

4.2. Preuve de concept : prototype et déploiement 107

Zone 1 1 2 3 3 4

Passagers ∅ P₁ P₁, P₂ P₁, P₂ P₂ P₂

Affichage bus ∅ ^Temp.,

Lum. Temp., Lum., Gaz, Particules Temp., Lum., Particules Temp., Lum. Temp., Lum., Musée Affichage P₁ ^Temp., Lum. ∅ ∅ ∅ ^Temp., Lum. Temp., Lum. Affichage P₂ ^Temp., Lum. Temp., Lum. ∅ ∅ ∅ ∅

Table 4.3 – Contenu affiché sur l’écran connecté du bus et sur les terminaux des personnes en fonction des passagers dans le bus et de sa position

Ainsi on peut voir que lorsque le bus se trouve dans la zone 1, aucun contenu ne s’affiche car il n’y a pas de passagers dans le bus. Lorsque le passager P₁ monte dans le bus, le système décide alors d’envoyer les informations générales accessibles (température, luminosité) de la zone concernée à l’écran du bus directement. De fait, les informations générales diffusées auparavant sur le terminal privé de l’utilisateur car il n’avait accès à aucun autre terminal sont désormais diffusées sur le terminal collectif du bus.

Lorsque le passager P₂ monte dans le bus dans la zone 2, le système envoie désor-mais les nouvelles informations de température, de gaz et de particules sur l’écran car il s’agit d’informations d’ordre collectif et qu’il y a des personnes intéressées dans le bus. Lorsque le bus passe dans la zone 3, il n’y a plus d’informations liées au capteur de gaz d’affichées car il n’y a pas de capteur de gaz déployé dans cette zone. Enfin, quand le passager P₁ descend du bus en zone 3, les données liées à la

qualité de l’air ne sont plus affichées car cela n’intéresse pas P₂ qui est alors le seul passager restant. De manière similaire, dans la zone 4 les informations concernant le musée à proximité sont affichées sur le terminal du bus car P₂ est toujours dans le bus et est intéressé par ce genre de contenu.