Un préalable pour tendre vers plus d’intelligence dans la maison plus facilement est de normaliser pour faire en sorte que tout le monde (y compris et surtout les objets communicants) se comprennent. Cet article d’une série de trois approfondit la notion d’interopérabilité pour les objets communicants évoquée dans le premier article de la « Maison communicante à la maison Intelligente ».
Des langages communs et standards
La question centrale est ici de faciliter le déploiement d’un nouveau service dans un domicile ou d’enrôler dans la « maison intelligente » un nouvel objet communiquant nouvellement introduit dans le domicile. La mise à disposition d’une infrastructure logicielle permettant à un nouveau service d’utiliser les capteurs et les actionneurs déjà installés dans la maison ou, à un service déjà déployé d’enrôler un nouveau dispositif, est la clef pour accroître la valeur de la « maison intelligente » pour ses occupants.
Qu’est ce qui est si compliqué dans le fait d’allumer par exemple une lampe avec un bouton poussoir communicant ?
Comparons la situation de l’Internet des Objets à la situation du web. Lorsque vous êtes chez vous et que vous voulez consulter un site Internet, vous ne vous posez pas la question du tuyau (au sens protocolaire). Internet, c’est le protocole IP (Internet Protocol) : un tuyau qui permet d’acheminer le contenu. Ce qui intéresse le client, ce n’est pas de savoir comment ça marche mais de visualiser la page Internet qu’il demande, de voir ses mails, de transférer des fichiers, etc…
Dans le monde de l’IoT, outre le fait que les technologies radios dominent, il existe x technologies et donc y tuyaux protocolaires. Ils ne se valent pas tous. Le premier usage qui a popularisé Internet est la facilité pour consulter des pages contenant les liens hypertexte et cela grâce au langage HTML. Ce langage de description de page est devenu le langage commun supporté par tous les navigateurs. C’est la dernière pièce d’un édifice complexe mais sans cette dernière, l’édifice ne serait pas achevé.
Ce qui fait défaut aujourd’hui dans le monde l’IoT, c’est une sorte de « HTML » de l’Internet de Objets : un langage commun qui ferait que les objets (indépendamment de tout le reste) seraient en mesure de se comprendre. Car aujourd’hui, s’ils peuvent se parler, ils ne peuvent se comprendre. Presque chaque technologie a son propre langage. Un langage dit applicatif plus ou moins réussi.
Si l’on peut assez facilement passer d’un tuyau à l’autre dans la vie courante (un mobile peut être mise en relation avec un téléphone fixe), on ne résout pas le problème du langage applicatif (un peu comme si vous parliez Français et que votre interlocuteur au bout du fil parlait Russe). Impossible de se comprendre même si on s’entend.
L’objectif qui est toujours en cours est de créer un langage commun (une sémantique commune) et extensible à toutes ces technologies. Ce langage commun adopté par tous les fabricants est une prérequis à l’explosion des usages.
Le nombre d’acteurs dans le domaine et de communautés ne facilite pas l’émergence de ce langage. Un « standard » en chasse un autre et au final, il n’y a pas de standard. Pour ce qui concerne le langage applicatif et de la modélisation sur laquelle il s’appuie, on retrouve des similitudes de concept pour la majorité de ces technologies.
Nous avons un problème à résoudre avec de l’informatique, comment fait-on ?
Voyons sur un exemple concret : une multiprise communicante (figure ci-dessous).
La figure ci-dessous se permet quelques raccourcis et simplifications mais on voit par exemple que le nœud physique, vis-à-vis de l’aspect réseau est le chip de communication (ZigBee, ZWave, EnOcean…) comme l’est une carte réseau dans un ordinateur.
Cet simple multiprise suffit donc à elle seul pour expliquer la principale raison qui rend nécessaire la notion de nœuds logiques. Les 4 nœuds logiques (objet ou device logique) correspondent aux 4 prises de cette multiprise mais ce pourrait être des nœuds logiques n’ayant rien à voir fonctionnellement entre eux. Par exemple un Switch On/off, un capteur de température et un capteur d’humidité dans le même objet physique (même nœud de communication) comme l’illustre la figure ci dessous. Ma préférence est de parler de nœud plutôt que d’objet ou de device physique ou logique car de façon sous-jacente on est dans le domaine des réseaux.
Ces nœuds logiques partagent un même chip de communication comme des applications dans votre PC partagent la même carte réseau. Vous l’aurez compris un objet physique représenté/modélisé dans un HAB (Home Automation Box) est continué de plusieurs proxys informatiques à différents étages de la modélisation.
De façon plus théorique la figure ci-dessous montre les principales entités de la modélisation. Les notions d’objet physique, d’objet logique, de fonctionnalité/service, etc… se retrouvent dans presque toutes les technologies ou standards mais beaucoup sont désignées de façon différentes.
Cela ne favorise pas les échanges entre tous ces acteurs qui souvent ne connaissent que les entités de leur technologie et n’ont pas une vision d’ensemble sur la problématique. Le tableau ci-dessous, vis-à-vis des entités ci-dessus (excepté Network : en Français réseau), illustre (dans l’ordre) l’hétérogénéité des appellations dans différentes technologies, consortiums ou organismes de normalisation.
Cependant depuis 2010, des organismes de normalisation ou des consortiums travaillent sur ce problème. Si longtemps on a eu l’impression que chacun y allait de son standard, on note de plus en plus une convergence d’approche et au-delà, une prise de conscience pour ceux (industriels) qui étaient persuadés d’y arriver seul. La création de OneM2M, un consortium mondial qui regroupe les organismes de standardisation Européen, Chinois, Américain… devrait permettre l’unification à moyen terme. Le chemin reste difficile vu le nombre de participants et les lobbyings.
Remerciements à Sébastien Bolle, Jacques Pulou pour leur corrections
En savoir plus :
Avant d’arriver à une adoption native de la standardisation OneM2M (ou autre peut être), les différences vont perdurer et la « proxyfication » des objets (physiques, logiques, etc…), c’est-à-dire la représentation de ces entités informatiques dans un modèle informatique orienté technologiquement, est une étape intermédiaire. A chaque technologie de réseau (ZigBee, ZWave, EnOcean,…), sa modélisation que l’on aimerait coiffer d’un modèle dit d’abstraction technologique standardisé afin que du point de vue applicatif (donc usage), la vision soit unifiée et les développements simplifiés. Imaginez que les développeurs d’applications de service soient obligés, pour une même finalité, de faire différemment en fonction des technologies… C’est pourtant ce qui se passerait aujourd’hui dans une box multi-technologies sans modèle d’abstraction (et sémantique).
L’architecture générale simplifiée d’une HAB (Home Automation Box) logicielle (et/ou matérielle) est illustrée ci-dessous. Il pourrait y avoir une répartition plus fine des différents éléments d’architecture de la Box entre une Box physiquement chez le client et une Box virtualisée dans le Cloud.
Architecture simplifiée HAB
Au cœur de l’architecture, les représentants (proxy) des machines (objets communicants), comme l’illustre la figure ci-dessous et de façon transversale, la logique applicative.
Architecture simplifiée HAB
Notez qu’on ne présume pas de la manière technique d’offrir le service et que cette manière n’est pas forcément ce que l’on imagine de prime abord : un programme classique.
Enfin, au delà de ces deux indispensables premières couches qui sont une réalité aujourd’hui, sans rentrer dans trop de détails, il pourrait y avoir une couche dite d’agrégation et une couche de réification métier au-dessus des deux premières.
Le modèle d’abstraction peut être vu comme un wrapper ou un container de technologies propriétaires vers un modèle standardisé. Cependant, l’accès aux modèles et aux langages propriétaires doit rester possible (tant qu’ils existent) afin par exemple d’accéder à des fonctionnalités spécifiques. Ce dernier point doit rester l’exception car alors, on se lie à une technologie. Pour atteindre l’objectif, il convient de modéliser les technologies telles quelles en couvrant 100% des fonctionnalités sans se préoccuper du reste, puis de les mapper/lier/cacher grâce au modèle d’abstraction (et sémantique associée).
La figure ci-dessous tente d’illustrer le processus de composition de la couche d’abstraction. On crée un méta modèle de descriptions issu d’une spécification papier (1) qui permet de définir un ensemble d’objets (2) (device logique) faisant éventuellement partie d’un domaine ou profil. Ces définitions donnent lieu à la définition d’un méta modèle de classes de proxification (3) permettant une fois instanciées, de constituer le modèle de représentation des objets communicants de votre maison au travers de proxy (4). Il ne faut cependant pas oublier des entités non communicantes telles une pièce, un étage (mais non considéré ci-dessous).
