[EMBEDDED WORLD] Sous le nom d’Universal IoT Connector, le groupe de standardisation SGeT (Standardization Group for Embedded Technologies) dévoile à l’occasion d’Embedded World sa première spécification 100% logicielle pour systèmes embarqués. ...

Créé il y a tout juste six ans, le SGeT a publié pour l’heure uniquement des standards « matériels » pour cartes et modules processeurs tels que le Smarc 2.0, le Qseven 2.0 et l’eNUC. Avec la spécification Universal IoT Connector (UIC) qui a nécessité près de trois ans de travail, l’organisme souhaite standardiser la connexion entre un équipement embarqué connecté et le cloud, et ce des couches logicielles les plus proches du matériel jusqu’aux niveaux applicatifs les plus élevés.

De fait, estime le SGeT, les précédentes tentatives de standardisation se sont souvent limitées à la communication et à la protection des échanges et donc aux couches logicielles hautes. Or les données doivent d’abord atteindre le niveau où elles peuvent être récupérées, transportées et finalement traitées ou stockées. Bien qu’il soit possible d’accéder aux ressources matérielles comme les capteurs, actuateurs ou sous-systèmes embarqués (et de les contrôler) via l'interface Embedded API préalablement définie par le comité PICMG, le SGeT constate que tous les paramétrages des communications d’entrées/sorties au niveau matériel doivent être faits manuellement pour chacune des connexions, que ce soit en périphérie de réseau ou dans le cloud. Un changement de carte, une mise à jour, ou le choix d’un autre fournisseur impliquent alors des personnalisations de toutes les couches logicielles affectées, et ce jusqu’à l’application finale.

La spécification UIC, dont la version 1.0 est attendue en mars et qui sera open source, a justement vocation à mettre un terme à cet état de fait en définissant trois niveaux d’abstraction pour un partitionnement de nombreux aspects liés aux traitements IoT. A cet égard, le standard fait une distinction entre la configuration système (identification du matériel, mappage, etc.), la communication avec les capteurs et les actionneurs (pilotes matériels) et la communication système (transfert et traitement des données). Alors qu’il existe aujourd’hui plus de 450 services cloud et un nombre encore plus élevé de configurations matérielles possibles, ce choix constitue une approche pratique, efficiente et très ouverte pour les solutions IoT actuelles et futures, assure l’organisme de standardisation.

Dans le détail, l’architecture UIC consiste en trois descriptions d’interfaces (voir schéma ci-contre). L’interface EDM (Embedded Driver Module) contrôle les périphériques matériels connectés au travers de pilotes et prend en charge les capteurs, les actionneurs et les informations localisées. Le deuxième bloc fonctionnel, du nom de Project Configuration Interface, fournit un mécanisme de configuration pour les systèmes embarqués ; il régule la façon dont tel ou tel périphérique va être commandé, la manière dont des données brutes vont être ajoutées à un ensemble d’informations et le moment où les données vont pouvoir être transmises vers le serveur. Enfin la troisième interface et non la moindre, labellisée Communication Agent Interface, est responsable du transfert des informations à l’unité de communication puis au serveur (éventuellement dans le nuage), ce qui inclut l’émission et la réception d’un ensemble de données ou d’événements.

Selon le SGeT, la spécification UIC se distingue par son approche ouverte vis-à-vis de la connectivité serveur (cloud/fog/M2M) et de l’infrastructure associée, par son indépendance vis-à-vis des architectures matérielles sous-jacentes et des fournisseurs (dès lors que ceux-ci évidemment fournissent des modules logiciels EDM) et par son autonomie vis-à-vis du niveau de communication (voir schéma ci-dessous).

Dans l’absolu, en fonction de la configuration, il sera ainsi possible de se connecter, au travers d’un même middleware conforme UIC, aux services AWS (Amazon Web Services) en utilisant un module Qseven et le protocole MQTT, ou au cloud Microsoft Azure via un module COM Express et le middleware XRCE (eXtremely Resource-Constrained Environments) (*). En raison du niveau d’abstraction, le middleware ouvre la voie à une approche particulièrement flexible, assure le SGeT tout en unifiant l’accès à de multiples modules matériels fournis par des sociétés comme ADLink, Congatec, Kontron, Portwell ou Seco, qui soutiennent l’initiative UIC du SGeT. Ainsi que l'accès à un nombre toujours plus important de plates-formes dans le cloud prises en charge comme AWS, PST (People System Things) de M2MGO, SAP Hana ou Microsoft Azure, via des protocoles comme MQTT, XRCE, OPC UA, etc. Le middleware UIC a été conçu pour s’exécuter sur Windows Embedded et Embedded Linux, précise encore le SGeT.

(*) XRCE est un dérivé de la spécification DDS de l'Object Management Group