Synchroniser les payloads appareils avec Eclipse Vorto : guide pratique

Alexander Edelmann

你好 (Bonjour en chinois), je suis Alexander Edelmann, basé à Singapour et ingénieur logiciel chez Robert Bosch depuis 2006. Je suis passionné par l'IoT et milite pour des standards ouverts permettant l'interopérabilité fluide des appareils across plateformes. Je contribue activement au projet Eclipse IoT Vorto, qui fournit des outils cloud pour la description uniforme des appareils et leur intégration across écosystèmes IoT divers. Hors ingénierie, j'apprécie la cuisine asiatique, perfectionner mes compétences aux baguettes, et le tennis.

Dans un environnement dépourvu de standard global, fabricants d'appareils IoT, intégrateurs et fournisseurs de plateformes luttent contre la variété immense de formats de payload, APIs et protocoles propriétaires.

Eclipse Vorto relève ce défi en offrant des éditeurs cloud qui abstraient les payloads vendor‑spécifiques en blocs de fonction Vorto réutilisables. Ces blocs sont assemblés en un Modèle d'Information Vorto qui définit le jumeau numérique d'un appareil. Modèles d'Information et Blocs de Fonction sont écrits en vortolang, une grammaire concise spécifiant l'interface entre un appareil physique et son jumeau numérique. Les solutions IoT communiquent exclusivement via ces blocs de fonction abstraits et leurs schémas de données associés, se découplant ainsi des formats de données appareil disparates. La conversion des données brutes appareil en ces interfaces abstraites s'effectue via les Spécifications de Mapping Vorto, qui encodent les instructions nécessaires pour harmoniser les payloads appareil‑spécifiques.

Normalisation de payload en général

La normalisation des données peut être effectuée à divers niveaux de la stack IoT, permettant aux parties prenantes de garder le contrôle sur l'endroit où les données propriétaires sont transformées en forme standardisée.

1. Sur le nœud appareil — Un appareil intelligent, tel qu'un four connecté Bosch, traite les données capteur localement, les normalise, et peut exposer des analytiques agrégeables dans un data lake cloud.
2. Sur le nœud passerelle — Une passerelle qui agrège multiples capteurs ou appareils via divers drivers de protocole (BLE, GPIO, etc.) normalise les données entrantes pour fournir analytiques niveau passerelle ou autres fonctions métier.
3. Sur un nœud plateforme IoT — Similaire à une passerelle, une plateforme IoT cloud normalise la télémétrie reçue via adaptateurs de protocole (MQTT, CoAP, etc.) pour alimenter services de gestion d'appareils ou analytiques.
4. Sur un nœud application — Une application normalise les données pour rester agnostique des appareils spécifiques, se concentrant sur la logique métier plutôt que sur les décodeurs appareil‑spécifiques.

Quand un appareil ne peut pas effectuer le mapping de payload — peut‑être par puissance de calcul ou bande passante limitée — un moteur de mapping séparé doit exécuter cette étape sur un nœud intermédiaire, passerelle, plateforme ou application.

La normalisation des données peut être gérée soit sur un nœud appareil (1), sur un nœud passerelle (2), sur un nœud plateforme IoT (3) ou sur un nœud application (4).

Tim Grossmann

En tant qu'étudiant allemand en informatique, j'ai réalisé des projets dans trois départements Bosch différents sur l'an dernier et demi. Mes intérêts portent sur l'Open Source et les technologies EduTech. Je crois que l'IoT et l'automatisation ont un potentiel immense pour transformer le quotidien. Je suis un apprenant et développeur dédié, et je maintiens le plus grand bot d'automatisation Instagram open‑source gratuit au monde. Dans mon temps libre, j'aime l'escalade et les voyages à l'étranger.

Comment Eclipse Vorto adresse la normalisation

Eclipse Vorto fournit une bibliothèque runtime qui, configurée avec un Modèle d'Information Vorto, applique la spécification de mapping pour transformer les payloads bruts appareil en leur forme normalisée. La spécification de mapping est versionnée et stockée aux côtés du Modèle d'Information de l'appareil dans le Référentiel Vorto, permettant sa réutilisation across différents nœuds de déploiement — appareil, passerelle, plateforme ou application. La bibliothèque est actuellement disponible pour Java et Node.js. En savoir plus sur la bibliothèque Vorto Payload Mapping.

Exemple : Normaliser des données industrielles avec Eclipse Vorto

Pour illustrer ces concepts, considérons un scénario où de la télémétrie CSV d'un moteur synchrone à aimants permanents (PMSM) est transmise à un connecteur MQTT Eclipse Hono.

Le middleware Vorto Payload Normalization consomme ces données depuis Hono, les route à travers le Vorto Payload Mapping Engine, et publie les données harmonisées comme topic AMQP. Tout abonné AMQP 1.0 peut alors consommer les données standardisées indépendamment de l'appareil d'origine, en tirant parti d'une plateforme de jumeau numérique comme Bosch IoT Things.

Dans cet exemple, nous employons Eclipse Ditto, un service de jumeau numérique open‑source, pour ingérer et stocker les données normalisées. Le Vorto Dashboard interroge ensuite l'API Ditto et présente l'information via des widgets UI pré‑définis conformes Vorto.

L'architecture conceptuelle complète de notre pipeline de mapping de payload appareil.

Si vous souhaitez observer l'ensemble du pipeline de mapping en action, visitez la démo Vorto Dashboard.

Cet article fournit un aperçu bref des Payload Mappings. Pour un guide complet, étape par étape, de configuration de votre propre pipeline, consultez notre tutoriel détaillé.