Worldlex Wiki DDS répond aux besoins d'échange de données en temps réel des applications dans les domaines de l'aérospatiale, de la défense, du contrôle du trafic aérien , des véhicules autonomes , des dispositifs médicaux, de la robotique, de la production d'énergie, de la simulation et des tests, de la gestion des réseaux intelligents , des systèmes de transport et d'autres applications.
middleware réseau qui simplifie la programmation réseau complexe . Il implémente un modèle de publication/abonnement pour l'envoi et la réception de données, d'événements et de commandes entre les nœuds . Les nœuds qui produisent des informations (les éditeurs) créent des « sujets » (par exemple, température, localisation, pression) et publient des « échantillons ». DDS distribue ces échantillons aux abonnés qui manifestent un intérêt pour le sujet concerné.DDS gère les tâches de transfert : adressage des messages, sérialisation et désérialisation des données (afin que les abonnés puissent se trouver sur des plateformes différentes de l’éditeur), livraison, contrôle de flux, nouvelles tentatives, etc. Tout nœud peut être un éditeur, un abonné ou les deux simultanément.
Le modèle de publication-abonnement DDS élimine pratiquement toute programmation réseau complexe pour les applications distribuées.de qualité de service (QoS) afin de configurer en amont les mécanismes de découverte et de comportement. En échangeant des messages de manière anonyme, DDS simplifie les applications distribuées et favorise la conception de programmes modulaires et bien structurés. DDS gère également le basculement automatique à chaud des éditeurs redondants en cas de défaillance de l'éditeur principal. Les abonnés reçoivent toujours l'échantillon prioritaire dont les données sont encore valides (c'est-à-dire dont la période de validité spécifiée par l'éditeur n'est pas expirée) . Le basculement vers l'éditeur principal est également automatique dès que celui-ci est rétabli .libres, sont disponibles. Celles-ci incluent des interfaces de programmation (API) et des bibliothèques d'implémentations en Ada , C , C++ , C# , Java , Python , Scala , Lua , Pharo , Ruby et Rust .
Les fournisseurs de DDS ont participé à des démonstrations d'interopérabilité lors des réunions techniques de printemps de l'OMG de 2009 à 2013.
Lors des démonstrations, chaque fournisseur publiait et s'abonnait aux sujets des autres à l'aide d'une suite de tests appelée « démo des formes ». Par exemple, un fournisseur publiait des informations sur une forme, et les autres fournisseurs pouvaient s'abonner au sujet et afficher les résultats sur leur propre interface. Chaque fournisseur publiait les informations à tour de rôle, tandis que les autres s'y abonnaient. Ces démonstrations ont été possibles grâce à deux éléments : le protocole DDS-I ou RTPS (Real-Time Publish-Subscribe) , et l'accord sur l'utilisation d'un modèle commun.
En mars 2009, trois fournisseurs ont démontré l'interopérabilité entre les produits individuels et indépendants qui implémentaient le protocole OMG Real-time Publish-Subscribe version 2.1 de janvier 2009. La démonstration comprenait la découverte des éditeurs et abonnés des uns et des autres sur différentes plateformes OS ( Microsoft Windows et Linux ) et prenait en charge les communications réseau multicast et unicast .
La démonstration d'interopérabilité DDS a utilisé des scénarios tels que :
- Connexion de base au réseau via le protocole Internet (IP)
- Découverte des éditeurs et des abonnés
- Compatibilité de la qualité de service (QoS) entre le demandeur et l'offrant
- Réseaux tolérants aux délais
- Sujets et exemples multiples
- Propriété exclusive des sujets
- Filtrage du contenu des données thématiques, incluant la période et la zone géographique.
Histoire
Le développement de la spécification DDS a commencé en 2001. En 2004, l' Object Management Group (OMG) a publié la version 1.0 de DDS. La version 1.1 a été publiée en décembre 2005, la version 1.2 en janvier 2007, et la version 1.4 en avril 2015. DDS est couvert par plusieurs brevets américains, entre autres.
La spécification DDS décrit deux niveaux d'interfaces :
- Un niveau de publication-abonnement centré sur les données (DCPS) inférieur, destiné à la diffusion efficace des informations appropriées aux destinataires appropriés.
- Une couche de reconstruction locale de données de niveau supérieur optionnelle (DLRL), qui permet une intégration simple de DDS dans la couche application .
D'autres normes connexes ont suivi le document de base initial. La spécification du protocole d'interopérabilité DDS (Real-time Publish-Subscribe Wire Protocol) garantit que les informations publiées sur un sujet à l'aide de l'implémentation DDS d'un fournisseur sont accessibles à un ou plusieurs abonnés utilisant les implémentations DDS du même fournisseur ou d'un fournisseur différent. Bien que cette spécification soit destinée à la communauté DDS, son utilisation n'est pas limitée à cette communauté. Les versions 2.0 et 2.1 ont été publiées respectivement en avril 2008, novembre 2010, septembre 2014 et mai 2019.
DDS pour Lightweight CCM (dds4ccm) propose un modèle architectural qui sépare la logique métier des propriétés non fonctionnelles. Une extension de 2012 a ajouté la prise en charge des flux. Un PSM (Platform Specific Model) Java 5 pour DDS définit une liaison de langage Java 5, appelée modèle spécifique à la plateforme (PSM) pour DDS. Il spécifie uniquement la partie « publication-abonnement centrée sur les données » (DCPS) de la spécification DDS ; il englobe également les API DDS introduites par DDS-XTypes et DDS-CCM. DDS-PSM-Cxx définit la liaison de langage PSM ISO/IEC C++ , appelée modèle spécifique à la plateforme (PSM) pour DDS. Il fournit une nouvelle API C++ pour la programmation DDS, plus intuitive pour un développeur C++. La spécification fournit des correspondances pour l' interface de programmation d'applications (API) spécifiée dans DDS-XTypes et permet d'accéder aux profils de qualité de service (QoS) spécifiés dans DDS-CCM.
Les types de sujets extensibles et dynamiques pour DDS (DDS-XTypes) ont permis de prendre en charge la communication de type publication/abonnement centrée sur les données, où les sujets sont définis par des structures de données spécifiques. Pour être extensibles , les sujets DDS utilisent des types de données définis avant la compilation et utilisés dans tout l'espace de données global DDS. Ce modèle est souhaitable lorsque la vérification statique des types est utile. Un profil UML ( Unified Modeling Language ) a spécifié les domaines et les sujets DDS à intégrer à la modélisation d'analyse et de conception. Cette spécification a également défini comment publier et s'abonner à des objets sans avoir à décrire au préalable les types dans un autre langage, tel que XML ou OMG IDL. Un langage de définition d'interface (IDL) a été spécifié en 2014, indépendamment du chapitre 3 de la spécification CORBA ( Common Object Request Broker Architecture ). Cet IDL 3.5 était compatible avec la spécification CORBA 3, mais a été extrait comme une spécification distincte, ce qui lui a permis d'évoluer indépendamment de CORBA.
Parmi les autres protocoles à mentionner, citons : DDS-XRCE (DDS pour environnements à ressources extrêmement limitées), qui permet la communication entre des dispositifs aux ressources limitées, comme un microcontrôleur par exemple, et un réseau DDS. Il rend possible la publication et l’abonnement à des sujets via un service intermédiaire dans un domaine DDS et DDS-RPC (RPC sur DDS), qui définit les appels de procédure à distance. Ces derniers assurent une communication bidirectionnelle requête/réponse et définissent les services distribués, détaillés par une interface de service. Ils prennent également en charge l’invocation de méthodes synchrones et asynchrones
À partir de la version 1.4 de DDS en 2015, la couche DLRL optionnelle a été déplacée vers une spécification distincte.