L’IOT industriel : nuages, brouillards et un p’tit café pour la route

Je discutais cet été avec un ami de longue date, très impliqué dans l’usine du futur (il se reconnaîtra probablement) et la conversation portait sur l’avenir de l’objet connecté industriel.

Il m’expliquait que l’architecture où l’objet se connecte dans les nuages, où l’information est traitée puis redescendue des nuages vers d’autres objets connectés demandait trop de bande passante à l’échelle d’une installation significative.

Une architecture où des ensembles d’objets communiquent directement entre eux pour produire une fonction commune et ne remontent vers les nuages que les données pertinentes et nécessaires était bien préférable. Autrement dit, on s’orienterait aujourd’hui plus vers une architecture en brouillard, avant la remontée vers les nuages.

Il y a un parallèle intéressant avec la démarche qu’a eue il y a une trentaine d’années le monde de la GTB qui a abandonné à cette époque les architectures centralisées copiées sur les SNCC des installations industrielles pour des architectures à « intelligence répartie » basées sur des contrôleurs de terrain de plus en plus autonomes et communicants.

A l’époque, cette évolution était guidée par le coût des liaisons à « haut débit » et, admettons-le, leur fiabilité toute relative. On séparait alors deux flux de données : le flux à destination de l’IHM au sens large (écrans locaux, superviseurs, gestionnaires d’alarmes, serveurs d’historiques …) et le flux process (capteur / action réflexe / actionneur) qui restait dans le meilleur des cas à l’intérieur d’un des modules de terrain ou de plusieurs de ces modules coordonnés entre eux par des communications à réduire au minimum pour ménager la (faible) bande passante du réseau de terrain qui les reliait.

On peut aujourd’hui aller bien plus loin dans la gestion des flux avec les protocoles nés de l’IOT qui s’articulent autour de clients abonnés à des flux de données mis à leur disposition par un ou des « médiateurs » (brokers, pour ceux qui préfèrent parler volapük). C’est par exemple le cas de MQTT ou de STOMP, qui doivent regrouper à eux deux pas loin des trois quarts des compatibilités de nos objets connectés du quotidien.

Mais le monde de l’IOT industriel n’échappera pas à ce que j’appelle le problème de l’expresso : Quelle est la taille de la mouture des grains pour que le café soit le meilleur possible ? Autrement dit : quelle taille pour les objets qui vont composer le banc de brouillard, et quel niveau de traitement et de tri des données dans chacun d’entre eux pour optimiser le flux de données, sans perdre en pertinence, et en gardant un process performant. Et, au fait, quelle taille donner aux bancs de brouillard tant qu’on y est ?

Et je vous donne déjà la réponse : biiiinn … çà dépend de ce qu’on veut en faire.

Des objets petits permettront par exemple une alimentation par la lumière ou les vibrations ambiantes. Ils transmettront un flux de données faible mais issu de sources multiples (le BLE est un support fait pour çà), donc il faudra un médiateur avant de les remonter plus haut dans le brouillard. Des objets plus gros permettront un flux de données plus synthétique, qui gagnera donc en pertinence. Mais ils rendront probablement l’ensemble du nuage moins souple à la modification. Alors, vous êtes plutôt mesure ou process ?

Et pour finir, il va falloir créer l’architecture des objets au sein du brouillard. Répartir leurs fonctions, et définir les flux de données nécessaires et suffisants entre eux. Et enfin organiser l’action conjointe des bancs de brouillard.

Et si on reprenait un petit café ? Comment çà, filtre ?