Databus vs Database : 6 questions clés que tout développeur IIoT doit considérer

L'Internet Industriel des Objets (IIoT) introduit de nombreux nouveaux concepts, s'appuyant souvent sur des principes informatiques familiers mais remodelant la façon dont les systèmes opèrent. Parmi ceux-ci, le « databus » se distingue comme un élément fondamental.

La prochaine architecture de référence IIC v2 introduit un nouveau motif appelé « layered databus ». Bien que les détails soient encore en revue, le processus de documentation a clarifié les définitions clés et meilleures pratiques.

Définition : Un databus est une technologie de partage d'information centrée sur les données qui implémente un espace de données virtuel et global. Les applications logicielles lisent et mettent à jour les entrées dans cet espace, et les mises à jour sont propagées via un mécanisme de publication-souscription.

Caractéristiques clés :

1. Les applications interagissent directement avec les données, sans wrappers intermédiaires.
2. L'infrastructure comprend les données, permettant le filtrage sélectif et l'outillage avancé.
3. L'infrastructure applique des garanties Quality-of-Service (QoS) telles que le débit, la fiabilité et la sécurité.

Ces propriétés mènent à une série de questions qui surgissent lors de l'introduction des concepts de databus dans un environnement IIoT. Les six sections suivantes adressent les interrogations les plus courantes.

Question 1 : En quoi un databus diffère-t-il d'une base de données ?

Réponse courte : Une base de données stocke des données historiques pour récupération ultérieure, tandis qu'un databus gère des données vivantes et entrantes, les filtrant par les propriétés de la nouvelle information.

Réponse longue : La centricité données s'exprime à travers trois dimensions :

• Interface : Les données elles-mêmes sont l'interface primaire ; il n'y a pas de wrappers artificiels comme messages ou fichiers.
• Compréhension : L'infrastructure peut interpréter les données, permettant filtrage, recherche et intégration d'outils.
• Gouvernance : Le système applique des règles d'échange de données, établissant une source unique de vérité et gérant les durées de vie, schémas et sémantiques CRUD.

Une base de données relationnelle, par exemple, fournit une couche de stockage structurée qui applique la cohérence et offre une recherche globale. Elle définit la « vérité » du système car les données stockées ne peuvent être corrompues ou perdues. Un databus, en revanche, fournit un espace de données virtuel global qui permet aux applications d'écrire et lire des flux de données, tandis que le middleware applique les règles QoS et ne livre que l'information correspondant aux critères du consommateur.

Question 2 : Un databus agit-il comme une base de données accédée via une interface pub-sub ?

Réponse courte : Non. Une base de données implique un stockage persistant ; un databus offre un espace de données purement virtuel et global qui peut ou non persister les données.

Réponse longue : Considérez un contrôleur d'intersection souscrivant aux positions de véhicules dans un rayon de 200 m. Le contrôleur reçoit des mises à jour satisfaisant ses contraintes QoS (ex: < 0.01 s latence, 100 mises à jour/s). Le databus peut livrer les données directement sans les stocker, bien qu'une mise en cache temporaire puisse survenir pour satisfaire les exigences de fiabilité.

Question 3 : Que signifie que les participants interfaçent directement avec les données ?

Dans le middleware centré messages, les applications doivent connaître les détails du pair, comme le schéma et les taux de mise à jour attendus, ce qui ajoute du couplage et entrave la réutilisation. Un databus abstrait ces détails ; les applications lisent ou écrivent dans l'espace de données via une interface CRUD, spécifiant seulement les données et QoS nécessaires. L'infrastructure gère la découverte de source, le filtrage, le transport et les garanties.

Question 4 : Comment le filtrage sélectif fonctionne-t-il dans un databus vs pub-sub traditionnel ?

Le pub-sub traditionnel se contente de transférer les messages aux souscripteurs, souvent sans inspecter les payloads. Même le pub-sub avec filtre de contenu repose sur des sélecteurs simples qui ne peuvent exprimer de QoS complexes. Un databus, par contraste, permet à un souscripteur de spécifier des critères détaillés (ex: véhicule dans 200 m, se déplaçant > 10 m/s vers l'intersection, mises à jour 200 Hz). Le middleware applique ces contraintes à la source, throttlant, droppant ou bufferisant les données pour respecter le contrat, et garantissant la vivacité.

Comme le filtrage se produit au producteur, le souscripteur ne reçoit que les échantillons pertinents (ex: 600 mises à jour par seconde), réduisant drastiquement la bande passante et la surcharge de traitement tout en assurant la fiabilité.

Question 5 : En quoi un databus diffère-t-il d'un moteur CEP ?

Réponse courte : Un databus est un middleware distribué qui transfère les données basées sur des filtres simples, tandis qu'un moteur CEP est un service centralisé qui évalue des motifs d'événements complexes.

Réponse longue : Les moteurs CEP analysent les flux pour détecter des motifs définis par l'utilisateur et peuvent déclencher des actions, mais ils nécessitent que toutes les données soient routées vers un nœud unique. Un databus effectue un filtrage local à chaque source de données, ne livrant que les échantillons correspondants aux consommateurs intéressés, scalant ainsi à des milliers de nœuds sans goulots d'étranglement centraux.

Question 6 : Qu'est-ce qui a motivé la création du standard DDS et des concepts de databus ?

Les premiers adopteurs en robotique, défense et systèmes de coordination à grande échelle exigeaient fiabilité, faible latence et découverte sélective face aux défaillances de composants. Ces exigences ont mené au standard DDS, qui trouve aujourd'hui application dans la santé, le transport, les smart cities et le secteur énergétique.

Pour en savoir plus sur les logiciels intelligents façonnant l'IIoT, téléchargez notre livre blanc, The Secret Sauce of Autonomous Cars.