Périmètre de l’administration des objets connectés

De la nécessité de l’administration des objets

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.

Les fonctions essentielles de l’administration des objets connectés

Pour exploiter des objets connectés, il faut assurer sept fonctions essentielles :

• la déclaration et la configuration des objets
• la mise à jour du firmware (i.e. le programme informatique qui s’exécute dans l’objet)
• l’inventaire (capacité à avoir une vue juste du parc d’objets et leur état)
• le diagnostic de l’état des objets
• le traitement des alarmes venant des objets
• l'interopérabilité des objets, avec des problématiques de modèles de données
• la sécurité informatique (protection des objets et respect des politiques de sécurité)

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 :

• la concentration des efforts sur la découverte et la description de l'usage nominal une fois les objets déployés et activés
• la méconnaissance de la problématique technique de la gestion des objets connectés
• la valeur ajoutée de la gestion des objets perçue comme faible.

Cette dissociation complète de la fonction métier et de l’administration des objets est porteuse de problèmes :

• itérations supplémentaires dans le projet pour insérer l’administration des objets
• réformes du cas d'usage métier pour prendre en compte les contraintes techniques de la gestion des objets...
• …parfois jusqu'à la modification des objets pour les adapter aux contraintes de leur administration.

Exemple

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 :

• inscription des clients : enregistrement sécurisé des informations d'identité, permis de conduire, carte de paiement… puis,
• au travers d'une application mobile, réservation et usage d'un scooter par un client enregistré.

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 :

• l’usage du scooter par le client (cas d’usage métier)
• la mise en circulation et la maintenance du scooter (administration de l’objet connecté “scooter”)
  • Inscription du scooter dans le système d’information
  • Mise à jour à distance du logiciel présent sur le scooter (sécurisée bien sûr !)
  • Inventorisation des scooters
  • Organisation et suivi des actions de maintenance (recharge batterie, réparation)
  • Collecte et réaction aux alarmes : de surchauffe moteur, détection de vol…
  • Lecture de l’état des capteurs moteur et divers en temps réel
  • Mise à jour des paramètres de sécurité (clefs cryptographiques…)
  • Retrait de la circulation en fin de vie.

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.

Les protocoles d’administration des objets

Une foire d’empoigne !

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.

Les protocoles du monde des télécommunications

TR-069 (ou CPE WAN Management Protocol)

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 :

• le provisioning et la configuration
• la mise à jour du firmware
• le diagnostic et les alarmes
• l’inventaire (dans la mesure où le numéro de série est exposé par l’objet, ce qui contribue à la fonction d’inventaire)

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.

OMA-DM

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 :

• le provisioning et la configuration
• la mise à jour du firmware (au travers de la spécification connexe Firmware Object Management Object)
• l’inventaire (dans la mesure où le numéro de série est exposé par l’objet, ce qui contribue à la fonction d’inventaire)
• le diagnostic et les alarmes (au travers de la spécification connexe Diagnostic and Monitoring Management Object)
• la sécurité informatique (gestion des droits d’accès et de la sécurité lors de la phase de bootstrap c.à.d. de conditionnement logiciel minimal initial pour rendre l’objet administrable; pour le reste, l’OMA s’en remet à TLS)

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.

Les protocoles du monde industriel

LWM2M

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 :

• le provisioning et la configuration
• la mise à jour du firmware (Device Firmware Update (DFU))
• l’inventaire (dans la mesure où le numéro de série est exposé par l’objet, ce qui contribue à la fonction d’inventaire)
• le diagnostic et les alarmes (observation d’événements)
• la sécurité informatique

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.

Les protocoles « privés »

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é.

Conclusion

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.

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.