• Aucun résultat trouvé

1.6 Les projets STM & S2C2

1.6.5 Contraintes et problématiques liées à ce contexte

Dans ce contexte différents éléments de problématique sont levés.

Tout d’abord il semble difficile d’avoir une approche centralisée dans ce scénario. En effet, il est très difficile de pouvoir centraliser le traitement de ce genre de systèmes vastes (ville intelligente) : dans le cas d’un bâtiment connecté, parfois des milliers d’objets sont en jeu. De fait, sur une ville entière il sera difficile de centraliser la gestion et surtout le traitement.

La gestion de ce type de systèmes IoT en intégrant l’aspect services s’avère complexe ne serait-ce que de par le côté dynamique lié au type de système. La mo-bilité est un élément important, que ce soit au niveau des utilisateurs ou des objets connectés (comme le bus). De plus il serait intéressant d’être capable de travailler à une gestion de ce type de systèmes en intégrant des paramètres non fonctionnels (QoS) afin de permettre de réaliser des optimisations suivant les scénarios. Dans le cas du scénario de diffusion d’information dynamique une contrainte peut être le temps de diffusion d’une information, notamment dans le cas d’une information urgente par exemple, ou bien le nombre de services utilisés. Des problématiques d’énergie peuvent également se poser par le coût d’exécution de certains ordres sui-vant les objets utilisés dans ce contexte car certains objets peuvent fonctionner sur batterie et posséder une autonomie limitée en cas de trop forte sollicitation. Enfin, la généricité et l’adaptabilité du ou des modèle·s en jeu doit être forte afin de limi-ter le coût d’adaptation du système à l’arrivée de nouveaux services, de nouveaux objets, à la déconnexion de certains objets, etc.

La vision orientée service amène également à la possibilité de combiner de ma-nière automatique différents services entre eux (objets connectés avec services logi-ciels ou accessibles sur internet comme un service de prévision de trafic par exemple ou météo).

Un moyen intéressant est de pouvoir composer différents services disponibles pour réaliser certaines actions, i.e. être capable de combiner différents services entre eux qui sont disponibles séparément. La combinaison avec des services de gestion d’objets apporte également une richesse supplémentaire et ouvre à de nouvelles

applications. Par exemple il est possible d’utiliser des services afin de récupérer l’état de batterie connu de différents objets afin de prendre une décision en fonction. Enfin, pouvoir mutualiser certains services apporte des améliorations. En effet, dans le cas de diffusion de contenu dynamique la mutualisation de services de diffusion de contenu représente une optimisation d’intérêt notamment dans le cas d’informations globales à diffuser à un lot d’utilisateurs. De manière plus générale, la capacité d’avoir recours à des services communs en mutualisant les appels à ces services pour minimiser le nombre d’appels et utiliser les ressources de manière plus optimisée, représente également un avantage.

1.6. Les projets STM & S2C2 35

Conclusion

En considérant différents éléments de contexte, différents axes ont été étudiés pour y répondre : les standards et protocoles de l’IoT, les problématiques de composition de services, les systèmes autonomiques ainsi que des modèles capables d’aider à cette gestion de systèmes IoT orientés services. Tout d’abord l’utilisation de plateformes standard (oneM2M notamment) et de protocoles comme LWM2M est particulièrement intéressante. En effet, l’utilisation de ce type de pla-teformes horizontales est un tremplin pour une plus grande interopérabilité et l’in-tégration d’applications IoT plus ambitieuses et complexes et engendre une vision plus haut-niveau, orientée services. L’interopérabilité permet également de rassem-bler des technologies hétérogènes au niveau des objets et de connecter différentes plateformes entre elles (ce qui apporte une valeur ajoutée dans le contexte des pro-jets) mais aussi de donner des éléments pour faciliter l’interopérabilité sémantique. Afin de répondre aux différentes problématiques qui se posent dans le contexte du scénario de ville intelligente et de diffusion de contenus dynamiques notamment mais pas que, différentes pistes ont été explorées. La richesse de la littérature sur la composition de services amène de nombreux moyens d’aider à cela, dans un contexte de vision orientée services. Les architectures autonomiques peuvent répondre aux problématiques de dynamicité et d’autonomie demandée en permet-tant de configurer des systèmes avec des politiques comportementales haut-niveau et que le système fasse preuve de capacités d’auto-gestion.

Enfin, les technologies du Web sémantique et notamment les ontologies sont plus démocratisées de nos jours et rendent possible la définition de vocabulaires par-tageables et compréhensibles pour les machines afin d’amener des informations de contextualisation et d’analyse de la connaissance sur un système donné via des mé-canismes de raisonnement et d’inférence de connaissance automatique Différentes ontologies reconnues ont été présentées et IoT-O se dégage comme un modèle de référence particulièrement intéressant dans notre contexte de travail. Les gram-maires de graphes sont des solutions permettant à la fois de modéliser des élé-ments sous formes de graphes typés mais aussi de transformer automatiquement des graphes en plans d’exécution à la volée et ne pas comporter des exécutions de plans figés préétablis en fonction de certains symptômes particuliers.

Dans le chapitre suivant, l’architecture centrale des contributions de cette thèse est abordée ainsi que l’approche multi-modèles mise en œuvre de manière théorique pour répondre aux problématiques d’analyse et de génération de plans d’exécution dynamique. Enfin, des instances des modèles dans le contexte de notre cas d’utili-sation sont proposées et détaillées.

Chapitre 2

Vers un système autonome de

gestion des services d’une

architecture IoT ouverte

Sommaire

2.1 Architecture haut-niveau du système proposé . . . . 38

2.1.1 Les composants du système . . . . 38