Elektor Electronics 2018 01 02 469

l’EEBUS arrive
fin de la tour de Babel pour l’Internet des Objets ?
Tam Hanna
Les maisons connectées sont généralement
un salmigondis d’appareils de différents
fabricants. Si ces appareils veulent
communiquer entre eux, la maîtrise de
la variété babylonienne de protocoles
et de langages est un travail de Sisyphe.
L’Initiative EEBUS fondée en Allemagne est un
organe de normalisation qui souhaite apporter une
solution à ce problème.
Commençons nos considérations par un aperçu du marché. À
part Samsung, LG et Haier, peu d’entreprises peuvent offrir
à leurs clients une solution globale allant du sèche-linge à
l’ordiphone en passant par le réfrigérateur.
Des entreprises plus petites, spécialisées sur un secteur
particulier, sont à la traîne face à leurs concurrents mieux
capitalisés. Cela crée un déséquilibre sur le marché et enlève
aux utilisateurs différentes possibilités lors de la composition
de leur « parc d’appareils ». La solution à ces problèmes est la
raison d’être de l’Initiative EEBUS e.V., instance de normalisation
domiciliée à Cologne (voir l’encadré « Qui est l’EEBus ? »).
Architecture
L’EEBUS a connu un développement similaire au Bluetooth LE
par ex. : il fallait créer une architecture de communication qui
soit aussi générique que possible et qui couvre tous les cas
d’application (y compris futurs). Une telle norme a également la
responsabilité de rassembler « à la même table » des appareils
de plusieurs fabricants.
Les bases de données KV (KV = key/value ou clé/valeur) sont
une approche possible. D’une part, elles sont suffisamment
simples techniquement, ce qui signifie qu’elles ne constituent
pas un obstacle pour le développeur. D’autre part, la
standardisation des clés et/ou des contenus des clés permet
de créer une norme assez stricte.
Lorsqu’on parle d’EEBUS, cela on pense immédiatement à
SPINE - l’acronyme de Smart Premises Interoperable Neutralmessage
Exchange. Cette norme est fortement orientée vers
l’application : le développeur prend en compte les exigences de
communication interdispositifs dans l’application en question et
décide ensuite de la présentation des messages correspondants.
Observons l’architecture représentée sur la figure 1. Au
niveau hiérarchique supérieur se trouve l’appareil physique,
par exemple une machine à laver, un ordiphone ou une lampe.
Dans le domaine de l’électroménager de cuisine, les appareils
effectuent plusieurs tâches dans une même « boîte » – comme
ces boîtiers sont en général blancs, on parle de « produits
blancs ». SPINE a créé pour ces appareils le concept d’entité
(entity). Une entité décrit une fonction de l’appareil. Dans le cas
d’un refroidisseur à vin avec distributeur de glaçons intégré, il
s’agit d’une part du refroidisseur lui-même et d’autre part du
distributeur de glaçons.
Les différentes caractéristiques qui décrivent chaque fonction
d’un appareil se trouvent au niveau le plus bas.
Une question de format de données
Le Bluetooth LE se différencie du modèle SPINE, dans la mesure
où la norme de radio spécifie le format de communication aussi
bien physique que logique. SPINE se limite lui au septième
niveau du modèle de couches OSI : le processus par lequel
les données se déplacent d’un hôte à un autre est du ressort
exclusif du développeur. L’EEBUS propose uniquement comme
option d’utiliser SHIP, c’est-à-dire Smart Home IP, un protocole
maison qui s’appuie sur TCP/IP.
L’EEBUS est bien plus strict en ce qui concerne le choix du
codage des messages – les données sont au format texte, la
syntaxe XML a été retenue (voir encadré « XML »). Cela simplifie
le travail d’implémentation, car chaque langage comporte un
ou même plusieurs analyseurs XML. Comme la puissance de
calcul disponible dans les composants embarqués est toujours
plus grande, le surcoût (overhead) évidemment énorme, dû à
l’utilisation du XML, va fortement diminuer.
24 janvier/février 2018 www.elektormagazine.fr
vu sur www.frboard.com