Les projets d’objets connectés commencent souvent par valider le cas d’usage métier avec quelques dizaines d’objets prototypes. Les objets sont alors paramétrés à la main et suivis individuellement dans une feuille excel… Le cycle de vie de l’objet est “artisanal”. Mais lorsque l’entreprise veut passer à l’échelle industrielle, elle s'aperçoit que le nombre d’objets et de leurs variations matérielles et logicielles font du cycle de vie un casse-tête. La nécessité d’organiser la vie des objets et de disposer d’applications d'administration pour assurer la qualité de service attendue devient impérieuse. Chez OCTO, nous considérons que l’administration des objets est le deuxième sujet le plus prioritaire après la validation du cas d’usage métier.
Cependant, le sujet est ardu, technologiquement immature et risqué. Il existe de multiples schémas techniques et d'organisation pour réaliser le cycle de vie des objets connectés. Cette première partie d’article a pour objectif de faire une introduction d'une part aux besoins fonctionnels de la gestion des objets, et d'autre part de faire le point sur les standards et technologies pouvant être mis en œuvre. On s'attardera sur les “protocoles de device management’, car ils embrassent bon nombre de fonctions essentielles. Dans une deuxième partie de cet article, nous montrerons un cas concret d'administration d’objets mobiles, des scooters électriques mis en location. Nous y verrons des outils permettant de réaliser les fonctions de gestion des objets.
Pour exploiter des objets connectés, il faut assurer sept fonctions essentielles :
Bien souvent le cas d'usage métier ne prend pas en compte le cycle de vie des objets qu'il utilise pour de multiples raisons, notamment :
Cette dissociation complète de la fonction métier et de l’administration des objets est porteuse de problèmes :
Afin d'illustrer ces concepts, nous introduisons un exemple simple du domaine de la ville intelligente. Il s’agit d’une entreprise de location de scooter électrique en milieu urbain. Cet exemple s'inspire de http://www.cityscoot.eu, service nouvellement créé. Chaque scooter est équipé d'un module comprenant un GPS, d’un qmètre mesurant la charge de la batterie, d'un émetteur/récepteur 3G/4G, de divers capteurs de température (moteur et environnement) et d'un contacteur télécommandé permettant de (dé)verrouiller le scooter à distance.
Le cas d'usage métier est très simple : il s'agit de faire payer la location du scooter au temps passé.
On voit donc le cas d'usage “métier” en deux étapes :
Cela suppose que le scooter disponible à la location (mis en circulation) soit connu du système d'information. Il existe donc deux activités liées qui se déroulent en parallèle :
Ces deux activités se rencontrent au moment où le scooter est en circulation, c'est-à-dire disponible à la location.
Les données de configuration d'un scooter sont représentées sur la figure suivante :
Notons, que les données manipulées en device management ne sont pas des données "métier", mais des données "techniques" utiles au bon fonctionnent du système. On peut les voir comme des méta données des équipements techniques.
Nous analyserons dans le détail cet exemple et les technologies à mettre en œuvre dans la deuxième partie de cet article.
Ce type de problématique est très courant et les spécialistes de l’administration des objets ont imaginé des patrons de réalisation de ces fonctions essentielles. Ils viennent principalement du monde des télécommunications (gestion des équipements réseau, des « box »). D’autres sources d’inspiration viennent du monde de l’industrie (LWM2M) et de l’administration des serveurs/postes informatiques (SaltStack, Chef, Puppet, Ansible…). Les opérateurs PaaS d’Internet des objets (plates-formes IoT) proposent également des solutions plus ou moins propriétaires.
Reste que les fabricants d'objets connectés et de systèmes y vont le plus souvent de leur solution propre sans se soucier de l'interopérabilité avec les autres objets ou systèmes de gestion d'objets. Les spécialistes s'accordent ainsi sur le fait que ce domaine est un capharnaüm sans nom ! L’expérience montre cependant, qu’en fonction des industries on retrouve des systèmes et produits historiques, qui utilisent les standards cités ici, et que l’on ne peut pas ignorer. Ainsi les plateformes IoT les plus ouvertes offrent souvent les systèmes “historiques” d’administration des objets.
Nous allons passer en revue quelques-unes de ces différentes solutions, souvent présentées comme des “protocoles” d’administration des objets.
Ce protocole porté par le Broadband Forum vise à administrer à distance les équipements d’un LAN (routeur, box, téléphone IP,...), en dépassant les limites de SNMP. Il est agnostique à la couche de liaison physique, il requiert par contre IP et est conforme à la norme SOAP. En termes de structure de données, il prend pour modèle la MIB de SNMP, c’est-à-dire un arbre de données représentant l’objet. Il existe un arbre de base (root data model), et les fabricants d’objets peuvent ajouter des arbres représentant des propriétés spécifiques à leur objet (service data models).
Il couvre des fonctionnalités relevant des catégories suivantes :
La sécurité informatique est par contre confiée à TLS qui est recommandé dans la spécification de TR-069, et rien n’est prévu concernant l’interopérabilité des objets. TR-069 apparaît toutefois comme vieillissant et lié fortement à des infrastructures adaptées (au DHCP notamment). Très peu de nouveaux systèmes d’Internet des objets utilisent TR-069.
Il s’agit d’un protocole spécifié par l’Open Mobile Alliance et qui vise à administrer les objets du monde des télécom. Il s’appuie principalement sur HTTP+JSON/XML et est binaire pour un seul type de message. Son paradigme est celui de commandes envoyées par le serveur d’administration aux objets, lesquels peuvent de leur côté envoyer des alertes au serveur.
Son fonctionnement est un peu déroutant. Par exemple, les commandes envoyées par le serveur à l’objet doivent être implémentées comme des réponses HTTP aux messages tels que les acquittements qui lui sont envoyés par l’objet sous forme de requêtes HTTP. Fonctionnellement, c’est l’inverse de la SOA, en quelque sorte ! Le but est peut-être de s’appuyer sur des serveurs d’application pour implémenter le protocole du côté du serveur d’administration, lesquels sont conçus pour traiter des requêtes HTTP.
Un problème potentiel est que si un traitement synchrone est lancé sur l’objet et que celui-ci plante, il y a un risque que le serveur ne puisse plus envoyer de commande à l’objet, puisqu’il ne peut que répondre aux requêtes HTTP de l’objet.
De manière plus classique, les alertes sont des requêtes HTTP initiées par l’objet.
Il couvre des fonctionnalités relevant des catégories suivantes :
Rien n’est par contre prévu concernant l'interopérabilité des objets. La complexité du protocole et sa lourdeur de mise en oeuvre ont dissuadé les opérateurs d’Internet des objets de s’engager vers OMA-DM. Il y a peu de chance que ce protocole perce en IoT.
Issu également de l’Open Mobile Alliance, il est plus récent qu’OMA-DM et prétend répondre aux problématiques M2M, même si la version actuelle a un fonctionnement centralisé. Il s’appuie sur CoAP et est significativement plus léger que TR-069 et OMA-DM. Il couvre des fonctionnalités relevant des catégories suivantes :
Un modèle de description des ressources est présent dans la norme ce qui permet de réaliser des modèles partagés et structurés de ressources pour les objets. L’interopérabilité (sémantique) n’est toutefois pas abordée.
Différents efforts “privés” sont menés pour désolidariser l’API d’usage LWM2M de CoAP, car CoAP fait des hypothèses très fortes d’accessibilité réseau des objets à partir du serveur. Ainsi, différentes initiatives de portage sur MQTT sont en cours (nous contacter sur ce sujet) afin de rendre LWM2M plus proche des connectivités effectivement disponibles aujourd’hui. Nous pensons chez OCTO que LWM2M est le meilleur candidat de normalisation, car il constitue un premier palier vers l’interopérabilité, ce qui est le seul véritable objectif à terme.
Différents opérateurs privés proposent des solutions d’administration d’objets tels que Proximetry (http://proximetry.com/technology/) . Il en va de même avec les opérateurs PaaS de plateformes IoT qui offrent des services d’administration d’objets. Leurs offres évoluent rapidement, que ce soit chez Amazon IoT, Microsoft Azure ou IBM Watson IoT. Néanmoins leur positionnement reste assez “propriétaire”, mais cela peut évoluer sous la pression du marché.
Malgré de nombreuses initiatives propriétaires et cette situation compliquée, nous pensons que se rapprocher des standards reste la bonne stratégie. Le tableau suivant présente l’analyse de leur couverture fonctionnelle.
| TR-069 | OMA-DM | LWM2M | |
| Provisioning,configuration | ✓ | ✓ | ✓ |
| M.à.j. firmware | ✓ | ✓ | ✓ |
| Inventaire | ✓ | ✓ | ✓ |
| Diagnostic, alarmes | ✓ | ✓ | ✓ |
| Interopérabilité | ✘ | ✘ | Modèle normalisé de ressources |
| Sécurité | ✘ | ✓ | ✓ |
Finalement, les protocoles de device management ne se départagent pas tellement en termes de couverture fonctionnelle. Ils ont notamment en commun de faire de l’interopérabilité le parent pauvre du device management avec une exception pour LWM2M qui introduit des descriptions élémentaires de ressources dont la sémantique est normalisée. L’adaptation aux technologies logicielles actuelles distingue également ces protocoles. Dans ce registre, LWM2M présente aussi le meilleur potentiel d’adoption et d’implémentation. Son écosystème se développe rapidement et nous allons l’illustrer dans la deuxième partie de cet article.