Aujourd’hui, les objets connectés exploitent une multitude de protocoles de communication, propriétaires ou non, pour transmettre leurs données à travers des réseaux IoT.
La gestion de ces sources de données hétérogènes est laborieuse car les backends ont besoin d’un connecteur adapté pour supporter la multitude de protocoles exigeant chacun la prise en charge de son propre format de données. Les utilisateurs se retrouvent souvent contraints par des systèmes de gestion des données incapables d’interagir correctement avec leurs capteurs dans leur diversité et ce parfois même pour des capteurs du même équipementier.
Le CETIC propose son middleware DMWay qui permet l’exploitation de sources de données liées à des capteurs communicants selon des protocoles différents, et ce de manière décorrélée de leur spécificité hardware (marque, version, interface physique, etc.) .
Dans cet article, nous nous intéressons particulièrement à une famille assez répandu de capteurs : ceux qui utilisent les communications sérielles comme UART [1], SPI [2] ou I2C [3] ou encore 1-Wire [4]. Pour illustrer l’approche d’’intégration et d’exploitation de leur données en capitalisant sur les capacités de modélisation de data dans le middleware DMWay, nous avons choisi de mettre en oeuvre des capteurs de qualité d’air Sensirion avec une personnalisation du modèle de données pour le cas d’usage envisagé.
DMWay propose ses modèles de données IoT intrinsèques comme LWM2M [5] ou OCF [6] mais permet aussi aux utilisateurs d’encoder leurs propres modèles de données selon leurs besoins.
Dans notre cas, il s’agit de configurer un modèle de données qui prend en compte les données de qualité d’air envoyées par les capteurs Sensirion.
les deux capteurs SEN55 et SPS30 permettent tous les deux de mesurer la concentration des particules PM1.0, PM2.5, PM4 et PM10. SEN55 permet de mesurer en plus le taux de COV(Composés Organiques Volatiles), NOX (oxydes d’azote) ainsi que la température et l’humidité qui serviront aussi aux algorithmes internes du capteur pour faire la correction automatique des mesures réalisées.
La première étape consiste a construire le modèle de données qui prendra en charge toutes ces mesures. Les figures ci-dessous montrent le configurateur DMWay permettant d’encoder les paramètres nécessaires.
La figure suivante montre le mapper qui est le module du middleware qui connecte la source de données au modèle d’information ou infomodel. Ce dernier représente en effet un concept central du middleware DMWay. L’infomodel consiste en une structure hiérarchique d’objets. Ces objects peuvent être des valeurs, des actions, des évènements ou des objets composites (i.e. objets contenant d’autres objets).
Dans DMWay, les concepts de Datamodel (signification des données manipulées) et Infomodel (organisation des données) sont fortement liés. L’explication détaillée est en dehors du cadre de cet article. Ce qu’il faut retenir est que DMWay offre intrinsèquement le moyen de spécifier et personnaliser la représentation des données grâce à ces deux concepts.
Comme DMWay est compatible avec une multitude de protocoles IoT, ceci offre à l’utilisateur une très grande liberté pour choisir ses capteurs sans se préoccuper de gérer explicitement et de bout en bout, le type ou de la technologie de communication utilisée par le capteur.
Dans notre cas, le Sensirion SPS30 est connecté à DMWay par une connexion série et les données du SEN55 sont transmises à DMWay en passant par une passerelle programmable (un module ESP32 configuré pour encapsuler les mesures sérielles à travers un lien Wifi). Le firmware développé pour l’ESP32 interroge le capteur SEN55 à travers la liaison I2C et envoie les données à DMWay en MQTT comme c’est montré dans la figure suivante.
La Figure ci-dessous représente les dashboards réalisés dans la plateforme Thingsboard en se basant en grande partie sur les capteurs de qualité d’air Sensirion.
Ce PoC illustre la grande flexibilité de DMWay lui permettant de spécifier et gérer des modèles de données personnalisés qui satisfont un besoin bien spécifique pour l’utilisateur tout en permettant leur exploitation par des plateformes de données IoT comme Thingsboard ou autres logiciels en backend.
Intéressé(e) d’en savoir plus sur les capacités du middleware DMWay ou de le voir en oeuvre sur un démonstrateur réel ?
N’hésitez pas :
à nous contacter sur info@cetic.be
à visiter la page de l’outil : https://asset.cetic.be/fr/dmway/
ou à nous rendre visite dans notre espace de démonstration à notre adresse [Avenue Jean Mermoz 28, 6041 Charleroi (Belgium)]
—
[1] UART : Universal Asynchronous Receiver / Transmitter
[2] SPI : Serial Peripheral Interface
[3] I2C : Inter-Integrated Circuit
[4] 1-Wireou OneWire
[5] LWM2M : Light Weight Machine to Machine
[6] OCF : Open Connectivity Foundation