Introduction

Dans la première partie de cet article nous avons présenté les besoins principaux couverts par le concept de « plate-forme IoT ». Dans cette partie nous allons aborder l’architecture fonctionnelle et applicative d’une plate-forme générique d’IoT. Le but est de donner un guide de lecture structuré des offres de plates-formes.

Cet article aspire à être le point de départ d’un projet d’IoT, basé sur une analyse des besoins « métier » faite sur la trame de la première partie de l’article.

Dans la troisième partie de cet article, nous montrerons l'usage de ce modèle d'architecture pour décrypter les services rendus par les plates-formes IoT du marché.

Architecture des plates-formes IoT

Diagramme de contexte

Il est important de considérer l’intégralité du système pour assurer la totale interopérabilité des différents composants. Les offres commerciales de plates-formes IoT ont souvent un périmètre plus réduit et proposent la compatibilité avec des standards d’interopérabilité (d’objets et/ou de protocoles de communication).

La figure suivante montre notre périmètre d’étude (en vert pâle) :

Les objets sont connectés à une passerelle via un protocole de communication (local ou longue distance). La passerelle communique avec un système central qui est accédé par des utilisateurs, des administrateurs et d’autres machines qui portent des applicatifs consommant ou fournissant des données aux objets. Les administrateurs veillent sur le système central, les réseaux de communication et les passerelles.

Dans cet article, on appelle « Plate-forme IoT » l’association du Système central, les passerelles (Gateway) et les protocoles de communication de l’objet jusqu’au système central. Les objets ne font pas partie du contexte de notre analyse de la « Plate-forme IoT ». Par contre, on s'attend à des propriétés d’interopérabilité des objets avec le reste de la plate-forme. En effet, en général les objets sont fournis par des constructeurs différents de ceux qui font et exploitent les plateformes IoT.

Ce modèle générique prend des formes concrètes très différentes. Le tableau ci-dessous en illustre quelques unes :

Les utilisateurs sont de natures différentes :

• Les utilisateurs d’objets (qui sont en contact ou en interaction avec les objets)
• Les utilisateurs « métier » qui s’intéressent à l’usage des objets où aux mesures issues des objets
• Des utilisateurs « machines » consommateur ou producteur des données du système central.

Les administrateurs peuvent veiller à des parties différentes du système et apporter du support aux utilisateurs sur les aspects :

• réseaux et passerelles
• d’architecture technique du système central
• fonctionnels et applicatifs au niveau central

Architecture applicative

Un sujet récurrent de l'IoT est la distribution des fonctions sur les différents composants. Plusieurs courants s'affrontent en ce moment, dont les deux extrêmes sont :

• Les architectures où les objets sont de simples capteurs et actionneurs, portant une intelligence réduite et communiquant avec le système central qui porte toute l'intelligence fonctionnelle. Ce sont les architectures type NEST, AWS IoT, ThingSpeak... Elles ont deux énormes avantages : la simplicité de l'architecture et de son exploitation, la collecte de l'intégralité des données utiles aux analyses. Les inconvénients sont la faible robustesse aux pertes du réseau et la nécessité de la haute disponibilité du central.
• Les architectures où les objets sont autonomes, se découvrent et communiquent entre eux, savent collaborer pour créer de la valeur fonctionnelle. Ils remontent certaines données en central.

Dans les architectures intermédiaires entre ces deux patterns, la passerelle joue un rôle fonctionnel local et assure la continuité de service en cas de perte du central ou du WAN. Mais ces architectures sont plus chères et plus compliquées à déployer.

Ainsi les fonctions offertes par une plate-forme IoT peuvent se localiser sur différents composants, voire être redondantes pour assurer la continuité du service.

Une plate-forme IoT est un PaaS

Une plate-forme IoT est un socle middleware sur lequel on déploie des applications IoT. Ce socle offre des services qui sont appelés par le code d’application que l’on déploie dessus. C’est donc un procédé analogue à ce que l’on fait sur les serveurs d’application.

Cependant, les plateformes IoT ne sont pas normalisées (comme l’est JEE) et chaque fournisseur essaie de se différentier par les services fournis. Les services offerts sont également très variés et relèvent de technologies différentes. Pour finir, les middlewares bien que majoritairement présents en central, sont également présents dans les gateways.

Quels services pour quels besoins ?

Dans la première partie de cet article, nous avons vu que l’IoT a des besoins tels qu’exprimés sur la figure ci-dessous. En face de chaque besoin apparaissent les patterns/solutions/technologies qui les adressent parfaitement :

Les solutions « reines » face à ces besoins sont constituées de réseaux, de middlewares de communication bidirectionnelle, et de 4 grandes technologies qui se démarquent dans les plates-formes IoT : Le Complex Event Processing, le Big data, le machine learning et la BI temps réel. Nous allons voir comment elles s’agencent dans une plate-forme IoT.

Services exposés par la plate-forme IoT idéale

Cartographie des services offerts

La figure suivante présente les grands blocs fonctionnels d’une plate-forme IoT "idéale" (en ce qui concerne sa complétude). Nous allons les passer en revue.

Aucune (à ma connaissance) plate-forme IoT propose tous les services présentés ici. Toutes exposent un sous-ensemble de ces services, parfois dans l’objectif de se « teinter » sur un usage. Par exemple, Kaa est très orienté sur la passerelle télécom et le stockage des données mais n’offre pas beaucoup plus. Resin.io est spécialisée dans le management des objets, mais ne fait pas de CEP. A contrario, ThingWorks se présente comme une plate-forme extrêmement complète. ThingSpeak se concentre sur un cœur de services couvrant 60 % des besoins de base et les algorithmes. De cela on peut conclure :

Pour réaliser une application IoT, il faut très souvent ajouter les services manquants à la plate-forme choisie, voire assembler différentes plates-formes

On peut d'ailleurs se poser la question de la pertinence commerciale de la plate-forme idéale...

Nous proposons également la construction "sur mesure" :

C'est une option très crédible que les architectes IoT OCTO pratiquent couramment

Les patterns

Les plates-formes respectent toutes certains patterns et il est extrêmement utile de bien déterminer ceux dont le projet que l’on mène à besoin :

• CQRS : La plate-forme sépare les canaux d’entrée des événements IoT des requêtes d’information (voir partie 1 de cet article).
• Event driven – Temps réel - Asynchrone : La plate-forme reçoit des événements des objets et fait évoluer sont état. Elle offre des facilités de traitements événementiels temps réel (calcul de durées, cumuls temps réel…). Les traitements sont asynchrones. Les protocoles de l’IoT supportent en général bien ce pattern.
• Multi-protocoles : La réception et l’envoi d’événements, leurs formats doivent se faire suivant des protocoles variés. La plate-forme offre une abstraction des services de communication, notamment sur les couches présentation et application.
• Hautement disponible : En général les services métier délivrés au client sont affectés gravement par la perte de messages et le fait de ne pas pouvoir interroger les données. Les patterns de haute disponibilité à appliquer se concentrent sur ces deux points.
• Élastique : Certaines applications IoT ont des caractéristiques de saisonnalité qui nécessitent des capacités variables. Les plates-formes doivent s’adapter à la demande de capacité.
• Multi-tenants : Les plates- doivent assurer l’étanchéité entre locataires, car elles sont souvent mutualisées (PaaS public ou multi-filiales dans les grands groupes).
• Interopérable : Les plates-formes offrent des représentations des objets et des états pouvant s’échanger en assurant la continuité sémantique (Voir Openinterconnect par exemple).

Ces patterns nous font clairement apparaître une architecture réactive au sens du « Réactive Manifesto ».

Les services d’administration des objets

Il s’agit de :

• Contrôler le cycle de vie des objets (installation, appairage entre l’objet physique et l’objet logique, changement d’affectation des objets…). Ce cycle est orchestré par la plate-forme.
• Configurer les objets sur les plans techniques et fonctionnels et sur des critères de profil (série de fabrication, version de logiciel, service souscrit par le client...)
• Maintenir en temps réel une base des objets et de leur configuration.
• Surveiller et télé-maintenir les objets (surveillance des piles, mise à jour des firmwares ) à distance (On The Air)…

Ces services sont de première importance car ils aident à soulager la logistique des objets et réduisent les coûts de fonctionnement. Certaines plates-formes sont même dédiées exclusivement à ces services.

Les services de passerelle télécom

DDS…) et les délivre aux traitements dans un protocole pivot. Ce dernier est en général un protocole publish and suscribe permettant aux traitements de recevoir les messages qui les concernent. Certaines plates-formes sont spécialisées sur ce service.

En général trois aspects principaux sont à traiter :

• Le protocole de transport, très souvent TCP mais pas seulement (UDP, protocoles propriétaires également), supportant des flux d'événements.
• Le protocole de présentation : on y retrouve les éléments d'encodage des données, la gestion des schéma et la cryptographie.
• Le protocole d'application coté objet (CoAP par exemple) et la traduction événementielle interne à la plate-forme.

Les services de calculs et de traitement des événements

Le cœur des traitements temps réel se situe dans ce service. Il s’agit de fonctions de Complex Event Processing (voir la partie 1 de cet article), mais également de l’intégration d’un Business Process Manager dont l’état évolue avec l’occurrence d’événements reçus ou engendrées par le CEP. Le type d’usage étant, par exemple, de déclencher un processus de maintenance sur un équipement qui a envoyé un message de défaillance. Voire de constater différents faits successifs et d’en déduire une défaillance imminente, et de la signaler.

Le service de publication de canaux offre la possibilité de restituer un flux d’information engendré vers des consommateurs externes (envoi de message ou flux de données (syndication et API)).

Les services de stockage des données

On distingue généralement trois types de stockages de données :

• Le stockage de données chaudes : c’est un mécanisme de cache qui permet de traiter les événements dans un horizon temporel rapproché (par exemple, le stockage d’un premier événement technique en attente d’un autre visant à créer un événement fonctionnel).
• Le stockage tiède : c’est un mécanisme qui stocke les informations susceptibles d’être mutées. Par exemple, dans un service de logistique, il s’agit de l’objet transporté durant sa période de transport. Son état changeant de « embarqué », « en voyage », « débarqué », « livré »…
• Le stockage froid : c’est un mécanisme qui stocke les informations (devenues) immuables. Par exemple, les données de l’objet transporté quand il a été livré, facturé et payé.

Les technologies de stockage disposant de capacité élevée d'ingestion de données et de gestion du multi-schéma sont généralement utilisées dans les plates-formes à haute performance.

Les services de data science et de Business Intelligence

On distingue deux types de services (voir partie 1 se l'article) :

• La BI big data.
• Le machine learning.

Du coté de la BI, les services peuvent adresser toutes les données, quelles soient chaudes, tièdes ou froides. Les requêtes effectuées sont de nature statistique (plutôt dans le froid) ou opérationnelles (conduite d’une flotte d’objets ou de leur environnement en temps réel ou légèrement différé). Il apparaît cependant de plus en plus d’usage où il est pertinent de mélanger froid, tiède et chaud pour obtenir des décisions de meilleure qualité. Les Lambda architectures sont souvent présentes dans les plates-formes IoT. Elles présentent une caractéristique extrêmement structurante des stockages et de leur interrogation.

Sur le pan du machine learning, les plates-formes se contentent de fournir des hooks vers du code spécialisé à construire en marge de la plate-forme. L'exemple emblématique de cette approche est celle de AWS IoT avec les services Lambda.

Les services d’API

Les données présentes dans la plate-forme ne sont pas accédées en direct sur les stockages mais uniquement par des services d’exposition. De même, de l’extérieur, les utilisateurs peuvent injecter des messages dans la plate-forme via les API. Ces services, embarquent des fonctions (requêtes/injection de messages) préparées et exposent des bindings variés : REST, email, message… La sécurité est un point important que les plates-formes IoT se doivent de soigner sur les API exposées sur Internet.

Les services de sécurité et de gestion d’identité

La protection des donnés IoT est souvent encadrée par le droit. Ce sujet devient particulièrement important avec, par exemple, la volonté actuelle du législateur de transformer les données issues du quantified-self en données médicales. Mais pas seulement, la concentration de larges volumes de données « métier » expose l’entreprise à toutes sortes d’indiscrétions et d’attaques. Les plates-formes IoT sont donc particulièrement sensibles en termes de sécurité. Conscients de ce besoin, les concepteurs de plates-formes adressent principalement :

• La traçabilité des événements (fonctionnels et d’administration) et des traitements.
• L’authentification des objets émetteurs / récepteurs d’événements, souvent par certificat (AWS IoT par exemple).
• Le chiffrement des canaux de communication ou des payloads (supportés par certains protocoles).
• Le chiffrement des données stockées (au niveau métier ou infrastructure).
• Le durcissement des accès aux API de requêtes (authentification forte, surveillance, audit).

Étant donné que l’IoT est un système ouvert sur Internet, deux patterns majeurs soutiennent la sécurité de l’IoT :

• La fédération d’identité (nécessité d’apprécier son ouverture et ses risques).
• La PKI.

Ces services peuvent être fournis par la plate-forme.

Les services d’administration

Les plates-formes tentent d’intégrer dans un même outil les fonctions d’administration de tous ces services. La tâche est particulièrement ardue car d’une part les objets techniques manipulés sont très variés (stockage, moteur de règles, CEP, passerelle télécom, API…) et ces objets étant intégrés s’influencent tous les un les autres (fonctionnellement mais également au niveau opérationnel). La fourniture d’une interface d’administration globale qui assure l’intégrité technique et fonctionnelle de la plate-forme est de très grande valeur, mais est très compliquée à concevoir et réaliser. Malheureusement, les offres sont encore assez embryonnaires sur ce plan.

L'exploitation (OPS) des plates-formes est complexe et nécessite un fort savoir faire pour les plates-formes haute performance. L'emploi d'un PaaS est à considérer pour un projet où l'aspect exploitation ne veut pas être trop prenant.

L’architecture applicative

Il existe de nombreuses architectures applicatives pouvant offrir les services décrits. Un scénario possible est présenté sur la figure suivante :

On remarque une correspondance quasi directe entre les services fournis dans des blocs applicatifs implémentés par des middlewares. Chez OCTO, nous avons déjà réalisé des plates-formes basées sur une telle architecture applicative.

Conclusion

Dans la première partie de cet article, nous avons présenté les besoins de l’IoT et les services attendus pour les adresser. Dans le présent article, nous avons affiné le concept de « Plate-forme IoT » à travers des vues d’architecture fonctionnelle et applicative. Ces vues nous permettent à la fois de construire une plate-forme IoT et aussi d’analyser les offres existantes. Nous allons traiter ce dernier point dans la 3^e et dernière partie de cet article.