Organisation fonctionnelle

Le développement de l’IdO est marqué par la création de silos : les fournisseurs de service et d’objets connectés mettent en place des écosystèmes fermés en utilisant des technologies propriétaires incompatibles avec celles d’autres fournisseurs (Tsiatsis et al., 2019; Borgia,

2014). Ces silos réduisent l’interopérabilité entre les objets connectés, c’est-à-dire leur ca- pacité à pouvoir fonctionner ensemble (e.g. échange de données, coordination d’actions) ce qui limite le potentiel de développement des applications de l’IdO et impact l’expérience de l’utilisateur. Pour répondre à cette problématique, plusieurs organismes internationaux, des entreprises et des chercheurs, élaborent des modèles d’architectures pour normaliser le déve- loppement des objets connectés et des services sur lesquels ils sont basés. L’objectif est de favoriser la comptabilité entre les objets connectés, l’accessibilité des services, d’accélérer le développement de l’IdO et d’ouvrir la voie à de nouvelles fonctionnalités.

Architectures de l’IdO

À l’instar des définitions de l’IdO, plusieurs modèles d’architecture ont été proposés dont les différences dénotent de la variété des besoins (e.g. communication avec une plateforme dans le cloud, edge computing). La variété s’explique par les modèles informatiques mis en œuvre pour le traitement des données et par les domaines concernés : domotique, industrie, santé, prêt-à-porter, agriculture, etc. Cependant, il existe des caractéristiques communes à l’ensemble de ces modèles.

Le groupe de travail P2413 de l’IEEE a pour but de créer une architecture de référence applicable à tous les domaines, en se concentrant sur les éléments communs. Initié en 2014 par l’IEEE-SA (Standards Association), le groupe de travail doit modéliser les concepts, entités et relations propres à l’IdO puis décrire le fonctionnement de l’IdO. Le projet est toujours en cours de développement toutefois, la Figure3.7montre l’architecture envisagée initialement. 57. Source :https://iot.ieee.org/images/files/pdf/IEEE_IoT_Towards_Definition_Internet_of_Things_ Issue1_14MAY15.pdf. Consulté le 24 avril 2019.

Applications

Réseaux et Transmission de données

Capteurs

Figure 3.7 – Architecture de l’IdO selon l’IEEE P241357.

La première couche, Capteurs, correspond aux réseaux de capteurs et d’actionneurs, em- barqués ou non dans des objets connectés. La couche Réseaux et Transmission de données désigne les technologies de communication et les processus de transmission nécessaires pour faire circuler les données entre les objets connectés et avec des plateformes situées dans le cloud. La dernière couche, Applications, concerne les applications et services pour les utili- sateurs créés à partir des données collectées par l’objet connecté. Dans le cas d’un bracelet connecté, par exemple, au niveau de la première couche, il s’agit des capteurs de type : accéléromètre, gyromètre, cardiofréquencemètre et altimètre. La seconde couche correspond aux protocoles de communication pour transmettre les données depuis le bracelet jusqu’au smartphone et à une plateforme située dans le cloud. La dernière couche est le traitement des données et leur visualisation via une application dédiée.

L’architecture proposée par la branche télécommunications de l’UIT apporte un niveau de détail supplémentaire et intègre la notion de sécurité. La recommandation UIT-T Y.2060 définit les concepts importants et donne les caractéristiques générales de l’IdO et des objets connectés. L’UIT-T décrit également le modèle de référence élaboré par plusieurs groupes de travail dont le SG20 (Study Group 20) dédié à l’IdO et ses applications aux villes connectées et aux communautés.

Figure 3.8 – Architecture de l’IdO selon l’UIT-T. Architecture de référence proposée par l’UIT-T dans sa Recommandation UIT-T Y.2060

La figure3.8 présente le modèle décrit l’UIT-T. On peut distinguer quatre couches prin- cipales et deux couches transversales :

— La première couche est similaire à celle de l’IEEE, mais intègre, en plus des capteurs et actionneurs, les passerelles permettant la communication entre les objets/capteurs et avec les plateformes situées dans le cloud ;

— La seconde couche (proche aussi de celle de l’IEEE) englobe les fonctions de contrôles pour l’accès aux ressources, l’authentification des équipements, la compatibilité entre eux et finalement la transmission des données ;

— La troisième couche, pour la prise en charge des services, fait référence aux fonctions de stockage et de traitement des données, qui peuvent être génériques et spécifiques suivant le type de service visé ;

— La quatrième couche désigne les applications et services créés avec les objets connectés ; — Les capacités de management, l’une des couches transversales, désignent les fonctions pour gérer la flotte d’équipements (e.g. contrôle à distance, mise à jour, maintenance), du réseau et du trafic ;

— Les capacités de sécurité sont les fonctions au niveau de l’application (e.g. maintient de la confidentialité, antivirus) et au niveau du réseau (e.g. intégrité des données, authen- tification des équipements).

Outre le travail de l’UIT-T, on peut citer également celui de l’ISO/CEI qui a publié en 2018 la norme ISO/CEI 30141 définissant une architecture de référence pour l’IdO58_{. Cette norme} est issue du travail mené par le sous-comité 41 (SC41), « Internet des Objets et technologies connexes », dans le cadre du JTC 1 (Joint Technical Committee), un organe de normalisation de la collaboration ISO/CEI. L’objectif du SC41 est d’élaborer une architecture de référence pour améliorer l’interopérabilité des systèmes au sein de l’IdO et d’inclure les problématiques liées à la sécurité. La norme ISO/CEI 30141 propose un modèle conceptuel pour définir les concepts et leurs relations, un modèle de référence pour présenter le fonctionnement à un niveau abstrait et compréhensible par tous et une architecture de référence détaillant toutes les fonctions nécessaires pour créer un système d’Internet des Objets59_.

Ces architectures de référence présentent l’organisation de l’écosystème de technologies de l’IdO au niveau macro. D’autres architectures élaborées par des chercheurs portent, au niveau micro, sur l’organisation et le fonctionnement technique des applications et services basés sur des objets connectés.

Architectures des applications et services basés sur des objets connectés

En mars 2015, des chercheurs de l’Internet Architecture Board (IAB)60 _{publient le RFC} 7452, un guide sur la mise en réseau d’objets connectés destiné aux développeurs et concep- teurs de services et d’applications basés sur des objets connectés61_{. Les recommandations} indiquées dans le RFC 7452 s’attachent à améliorer l’interopérabilité entre les objets connec- tés et à réduire la fragmentation de l’IdO en silos. La Figure3.9 illustre les quatre modes de communication présentés par les auteurs :

58. Source :https://www.iso.org/obp/ui/fr/#iso:std:iso-iec:30141:ed-1:v1:en. Consulté le 24 avril 2019. 59. Source :https://www.iso.org/fr/news/ref2361.html. Consulté le 24 avril 2019.

60. L’IAB est le comité chargé par l’association internationale Internet Society de surveiller le développement d’internet.

— (a) la communication entre objets ;

— (b) la communication des objets vers une plateforme dans le cloud ; — (c) la communication d’un objet avec une passerelle ;

— (d) le partage de données avec des tiers. Enceinte connectée Smartphone Réseau sans-fil Montre connectée Thermostat connecté Plateforme Cloud Balance connectée Smartphone

(passerelle) Plateforme Cloud

Bracelet connectée Plateforme Cloud Fournisseur de service B Plateforme Cloud Fournisseur de

service A _{Plateforme Cloud} Fournisseur de service C (a) (b) (c) (d)

Figure 3.9 – Modes de communication entre les objets connectés.

Le mode (a) désigne deux objets de fournisseurs différents connectés via un réseau sans-fil, par exemple, une enceinte connectée et un smartphone reliés par Bluetooth. Afin d’assurer l’interopérabilité entre les objets – pour que l’utilisateur puisse interagir avec l’enceinte, quel que soit son modèle de smartphone – les concepteurs doivent s’interroger sur les points suivants :

— les contraintes de l’objet (e.g. puissance de calcul, batterie) ; — la compatibilité de la technologie de communication ;

— le mode d’identification de l’objet ; — le mécanisme de découverte de l’objet ; — le protocole pour transporter les données ; — le langage pour décrire les données ;

— le niveau de sécurité requis et les potentielles atteintes à la vie privée.

Le mode (b) concerne la communication entre des objets connectés et une plateforme située dans le cloud, par exemple, une montre connectée envoyant des données médicales à une plateforme pour l’analyse. Dans cette configuration, l’interopérabilité peut paraître négli- geable, car l’objet connecté et la plateforme appartiennent au même fournisseur, cependant l’exploitation de la plateforme par des objets d’autres fournisseurs peut donner lieu à de nouveaux services. D’autre part, à long terme le risque d’une cessation d’activité augmente ce qui peut rendre inutilisable un objet connecté ayant une faible interopérabilité.

Plus complexe que les précédents, le mode (c) correspond à une communication entre des objets connectés et une plateforme dans le cloud en passant par une passerelle. Cette

dernière est nécessaire lorsque les ressources de l’objet connecté (e.g. puissance de calcul, débit) ne permettent pas d’utiliser les protocoles standards d’internet (e.g. TCP/IP, HTTP). La passerelle est un intermédiaire qui va recevoir les données de l’objet connecté par le biais d’un protocole adapté puis elle retransmettra les données à la plateforme dans le cloud.

Enfin, le mode (d) est l’ouverture à des tiers des données générées par l’objet connecté et la plateforme dans le cloud. Face aux écosystèmes fermés – les silos – créés par les four- nisseurs, les auteurs du RFC 7452 recommandent la mise en place de service web REST et d’API (Application Programming Interface) pour que d’autres fournisseurs ou des utilisateurs puissent exploiter et combiner les données. Par exemple, les données générées par un bracelet connecté peuvent intéresser une entreprise spécialisée dans le coaching sportif et gagneraient à pouvoir exploiter ces données pour émettre des conseils sur-mesure.

Ces architectures ont été élaborées pour synthétiser l’organisation fonctionnelle de l’éco- système de l’IdO et chacune des parties de ces architectures mobilisent des technologies spécifiques.