Databus vs. Database :les 6 questions que chaque développeur IIoT doit se poser

à partir de l'espace de données avec une interface CRUD. Bien sûr, vous pouvez avoir besoin d'une certaine QoS de cet espace de données, par ex. vous avez besoin que vos données soient mises à jour 100x par seconde. L'espace de données lui-même (le bus de données) vous garantira d'obtenir ces données (ou signalera une erreur). Vous n'avez pas besoin de savoir s'il n'y a qu'une ou 27 sources redondantes de ces données, ou si elles proviennent d'un réseau ou d'une mémoire partagée, ou s'il s'agit d'un programme C sous Linux ou d'un programme C# sous Windows. Toutes les interactions se font avec votre propre vue de l'espace de données. Il est également judicieux, par exemple, d'écrire des données dans un espace sans destinataire. Dans ce cas, le bus de données peut ne rien faire, ou il peut mettre en cache des informations pour une livraison ultérieure, en fonction de vos paramètres de QoS.

Notez que les technologies de base de données et de bus de données remplacent l'interaction application-application par l'interaction application-données-application. Cette abstraction est absolument critique. Il découple les applications et facilite grandement la mise à l'échelle, l'interopérabilité et l'intégration du système. La différence est vraiment l'une des anciennes données stockées dans une base de données (probablement centralisée), par rapport aux futures données envoyées directement aux applications à partir d'un espace de données distribué.

Question 4 :"L'infrastructure comprend, et peut donc filtrer sélectivement les données." N'est-ce pas le cas de tous les pub-sub, où vous pouvez vous inscrire à des "événements" qui vous intéressent ?

La plupart des pub-sub sont très primitifs. Une application "enregistre un intérêt", puis tout est simplement envoyé à cette application. Ainsi, par exemple, un algorithme de détection de collision d'intersection pourrait souscrire à des "positions de véhicules". L'infrastructure envoie alors des messages à partir de n'importe quel capteur capable de produire des positions, sans aucune connaissance des données à l'intérieur de ce message. Même le "filtrage de contenu" pub-sub n'offre que des spécifications très simples et nécessite que le système présélectionne ce qui est important pour tous. Il n'y a pas de réel contrôle du flux.

Un bus de données est beaucoup plus expressif. Cette intersection pourrait dire "Je ne suis intéressé que par les positions des véhicules à moins de 200 m, se déplaçant à 10 m/s vers moi. Si un véhicule correspond à mes spécifications, je dois être mis à jour 200 fois par seconde. Vous (le bus de données) devez me garantir que tous les capteurs alimentant cet algorithme promettent de fournir des données aussi rapidement ... ni plus lentement ni plus rapidement. Si un capteur se met à jour 1000 fois par seconde, alors ne m'envoyez que toutes les 5 mises à jour. J'ai également besoin de savoir que vous êtes actuellement en contact avec vous -capteurs en direct (que je définis comme produisant au cours des 0,01 dernières secondes) sur toutes les approches possibles de la route à tout moment.Chaque capteur doit être capable de stocker 600 anciens échantillons (valant 3 secondes) et de me mettre à jour avec ces anciennes données si j'en ai besoin ce." (Ce sont quelques-uns des 20+ paramètres QoS de la norme DDS.)

Notez qu'une application d'abonnement dans le cas primitif pub-sub est très dépendante des propriétés réelles de ses producteurs. Il doit en quelque sorte croire qu'ils sont vivants (!), qu'ils ont suffisamment de tampons pour sauvegarder les informations dont ils peuvent avoir besoin, qu'ils ne les inonderont pas d'informations ni ne les fourniront trop lentement. S'il y a 10 000 voitures détectées 1000x/sec, mais seulement 3 à moins de 200m, il devra recevoir 10 000*1000 =10m échantillons chaque seconde juste pour trouver les 3*200 =600 auxquels il doit prêter attention. Il devra envoyer un ping à chaque capteur 100x/seconde juste pour s'assurer qu'il est actif. S'il y a des capteurs redondants sur différents chemins, il doit tous les envoyer indépendamment et s'assurer d'une manière ou d'une autre que tous les chemins sont couverts. S'il existe de nombreuses applications, elles doivent toutes envoyer un ping à tous les capteurs de manière indépendante. Il doit aussi connaître le schéma des producteurs, etc.

L'application dans le second cas recevra en revanche exactement les 600 échantillons qui lui tiennent à cœur, sachant qu'au moins un capteur pour chaque voie est actif. Le débit est garanti. Une fiabilité suffisante est garantie. Le flux de données total est réduit de 99,994% (nous n'avons besoin que de 600/10m d'échantillons, et le middleware intelligent filtre à la source). Pour être complet, notez que l'algorithme de collision est complètement indépendant des capteurs eux-mêmes. Il peut être réutilisé sur n'importe quelle autre intersection et fonctionnera avec un capteur par chemin ou 17. Si pendant l'exécution, le réseau est trop chargé pour répondre aux spécifications des données (ou quelque chose échoue), l'application sera immédiatement notifiée.

Question 5 :En quoi un bus de données diffère-t-il d'un moteur CEP ?

Réponse courte :un bus de données est un concept fondamentalement distribué qui sélectionne et fournit des données de producteurs locaux qui correspondent à un cahier des charges simple. Un moteur CEP est un service exécutable centralisé qui est capable de spécifications beaucoup plus complexes, mais doit avoir tous les flux de données envoyés à un seul endroit.

Réponse longue :un moteur de traitement des événements complexes (CEP) examine un flux de données entrant, à la recherche de modèles que vous le programmez pour identifier. Lorsqu'il trouve l'un de ces modèles, vous pouvez le programmer pour qu'il agisse. Les modèles peuvent être des combinaisons complexes de données passées et futures entrantes. Cependant, il s'agit d'un service unique, s'exécutant sur un seul processeur quelque part. Il ne transmet aucune information.

Un bus de données recherche également des modèles de données. Cependant, les spécifications sont plus simples; il prend des décisions sur chaque élément de données au fur et à mesure qu'il est produit. Les actions sont également plus simples; la seule action qu'il peut entreprendre est d'envoyer ces données à un demandeur. La puissance d'un bus de données est qu'il est fondamentalement distribué. La recherche se produit localement sur des centaines, des milliers, voire des millions de nœuds. Ainsi, le bus de données est un moyen très puissant pour sélectionner les bonnes données à partir des bonnes sources et les envoyer aux bons endroits. Un bus de données est en quelque sorte comme un ensemble distribué de moteurs CEP, un pour chaque source d'informations possible, qui sont automatiquement programmés par les utilisateurs de ces informations. Bien sûr, le bus de données a de nombreuses autres propriétés au-delà de la correspondance de modèles, telles que la médiation de schéma, la gestion de la redondance, la prise en charge du transport, un protocole interopérable, etc.

Question 6 :Quelle application a piloté la norme DDS et les bus de données ?

Les premières applications concernaient les robots intelligents, la « supériorité de l'information » et les grands systèmes coordonnés comme la gestion des combats de la marine. Ces systèmes avaient besoin de fiabilité même en cas de défaillance des composants, de données suffisamment rapides pour contrôler les processus physiques, ainsi que d'une découverte sélective et d'une livraison à l'échelle. La centricité des données a vraiment simplifié le code d'application et les interfaces contrôlées, permettant aux équipes de programmeurs de travailler sur de grands systèmes logiciels au fil du temps. La norme DDS est une famille de normes active et croissante qui était à l'origine dirigée à la fois par les fournisseurs et les clients. Il est largement utilisé dans de nombreux secteurs, notamment la médecine, les transports, les villes intelligentes et l'énergie.

Si vous souhaitez en savoir plus sur la façon dont les logiciels intelligents balayent l'IIoT, assurez-vous de télécharger notre livre blanc sur l'avenir de l'industrie automobile, "La sauce secrète des voitures autonomes."