Servicio de distribución de datos

El Servicio de Distribución de Datos ()DDS) para sistemas en tiempo real es un estándar Grupo de Gestión de Objetos (OMG) de máquina a máquina (a veces llamado marco de middleware o conectividad) que tiene como objetivo permitir intercambios de datos fiables, de alto rendimiento, interoperables, en tiempo real, escalables utilizando un patrón de subscripción de publicación.

DDS aborda las necesidades de intercambio de datos en tiempo real de las aplicaciones dentro de aeroespacial, defensa, control de tráfico aéreo, vehículos autónomos, dispositivos médicos, robótica, generación de energía, simulación y pruebas, gestión de redes inteligentes, sistemas de transporte y otras aplicaciones.

Arquitectura

Modelo

DDS es un middleware de red que simplifica la programación de red compleja. Implementa un patrón de publicación-suscripción para enviar y recibir datos, eventos y comandos entre los nodos. Los nodos que producen información (editores) crean "temas" (por ejemplo, temperatura, ubicación, presión) y publicar "muestras". DDS entrega las muestras a los suscriptores que declaran interés en ese tema.

DDS maneja las tareas de transferencia: direccionamiento de mensajes, clasificación y desclasificación de datos (para que los suscriptores puedan estar en plataformas diferentes a las del editor), entrega, control de flujo, reintentos, etc. Cualquier nodo puede ser un editor, un suscriptor o ambos. simultáneamente.

El modelo de publicación-suscripción de DDS prácticamente elimina la programación de red compleja para aplicaciones distribuidas.

DDS admite mecanismos que van más allá del modelo básico de publicación-suscripción. El beneficio clave es que las aplicaciones que utilizan DDS para sus comunicaciones están desacopladas. Se necesita dedicar poco tiempo de diseño a manejar sus interacciones mutuas. En particular, las aplicaciones nunca necesitan información sobre las otras aplicaciones participantes, incluida su existencia o ubicación. DDS maneja de forma transparente la entrega de mensajes sin requerir la intervención de las aplicaciones del usuario, incluyendo:

• determinar quién debe recibir los mensajes
• donde se encuentran los receptores
• lo que sucede si los mensajes no se pueden enviar

DDS permite al usuario especificar parámetros de calidad de servicio (QoS) para configurar mecanismos de descubrimiento y comportamiento por adelantado. Al intercambiar mensajes de forma anónima, DDS simplifica las aplicaciones distribuidas y fomenta programas modulares y bien estructurados. DDS también maneja automáticamente los editores redundantes de intercambio en caliente si el principal falla. Los suscriptores siempre obtienen la muestra con la mayor prioridad cuyos datos aún son válidos (es decir, cuyo período de validez especificado por el editor no ha expirado). También vuelve automáticamente al primario cuando se recupera.

Interoperabilidad

Se encuentran disponibles implementaciones de software de DDS tanto patentadas como de código abierto. Estos incluyen interfaces de programación de aplicaciones (API) y bibliotecas de implementaciones en Ada, C, C++, C#, Java, Python, Scala, Lua, Pharo, Ruby y Rust.

Los proveedores de DDS participaron en demostraciones de interoperabilidad en las reuniones técnicas de OMG Spring de 2009 a 2013.

Durante las demostraciones, cada proveedor publicó y se suscribió a los temas de los demás mediante un conjunto de pruebas llamado demostración de formas. Por ejemplo, un proveedor publica información sobre una forma y los otros proveedores pueden suscribirse al tema y mostrar los resultados en sus propias formas. Cada proveedor se turna para publicar la información y el otro se suscribe. Dos cosas hicieron posibles las demostraciones: el protocolo DDS-I o publicación-suscripción en tiempo real (RTPS) y el acuerdo para utilizar un modelo común.

En marzo de 2009, tres proveedores demostraron la interoperabilidad entre los productos individuales e independientes que implementaron la versión 2.1 del protocolo OMG de publicación-suscripción en tiempo real desde enero de 2009. La demostración incluyó el descubrimiento de los editores y suscriptores de cada uno en diferentes plataformas de sistema operativo (Microsoft Windows y Linux) y comunicaciones de red multidifusión y unidifusión compatibles.

La demostración de interoperabilidad de DDS utilizó escenarios como:

• conectividad básica a la red utilizando el Protocolo de Internet (IP)
• Descubrimiento de editores y suscriptores
• Calidad del servicio (QoS) Compatibilidad entre el solicitante y el ofertante
• Redes tolerantes al retraso
• Múltiples temas y casos de temas
• Propietarios exclusivos de temas
• Filtro de contenidos de datos tópicos incluyendo tiempo y geográfico

Historia

El desarrollo de la especificación DDS comenzó en 2001. Fue desarrollado por Real-Time Innovations (RTI), una empresa de software, y Thales Group, una empresa de defensa francesa. En 2004, el Object Management Group (OMG) publicó DDS versión 1.0. La versión 1.1 se publicó en diciembre de 2005, la 1.2 en enero de 2007 y la 1.4 en abril de 2015. DDS está cubierto por varias patentes estadounidenses, entre otras.

La especificación DDS describe dos niveles de interfaces:

• A lower data-centric publish-subscribe (DCPS) level that is targeted towards the efficient delivery of the proper information to the proper recipients.
• Una capa de reconstrucción local de datos superior opcional (DLRL), que permite una simple integración de DDS en la capa de aplicación.

Otros estándares relacionados siguieron al documento central inicial. La especificación del protocolo de interoperabilidad DDS del protocolo de conexión de publicación-suscripción en tiempo real garantizaba que la información publicada sobre un tema utilizando la implementación de DDS de un proveedor sea consumible por uno o más suscriptores que utilicen implementaciones de DDS del mismo proveedor o de diferentes. Aunque la especificación está dirigida a la comunidad DDS, su uso no está limitado. Las versiones 2.0 se publicaron en abril de 2008, la versión 2.1 en noviembre de 2010, la 2.2 en septiembre de 2014 y la 2.3 en mayo de 2019.

DDS para Lightweight CCM (dds4ccm) ofrece un patrón arquitectónico que separa la lógica empresarial de las propiedades no funcionales. Una extensión de 2012 agregó soporte para transmisiones. Un PSM del lenguaje Java 5 para DDS definía un enlace del lenguaje Java 5, denominado modelo específico de plataforma (PSM) para DDS. Especificó sólo la parte de publicación-suscripción centrada en datos (DCPS) de la especificación DDS; Además, abarca las API de DDS introducidas por DDS-XTypes y DDS-CCM. DDS-PSM-Cxx define el enlace del lenguaje ISO/IEC C++ PSM, denominado modelo específico de plataforma (PSM) para DDS. Proporciona una nueva API de C++ para programar DDS que es más natural para un programador de C++. La especificación proporciona asignaciones para la interfaz de programación de aplicaciones (API) especificada en DDS-XTypes y el acceso a perfiles de calidad de servicio (QoS) especificados en DDS-CCM.

Los tipos de temas dinámicos y extensibles para DDS (DDS-XTypes) brindaron soporte para la comunicación de publicación y suscripción centrada en datos donde los temas se definen con estructuras de datos específicas. Para ser extensible, los temas de DDS utilizan tipos de datos definidos antes del tiempo de compilación y utilizados en todo el espacio de datos global de DDS. Este modelo es deseable cuando la verificación de tipos estáticos es útil. Un perfil de Lenguaje de modelado unificado (UML) especificaba dominios y temas de DDS que formarían parte del modelado de análisis y diseño. Esta especificación también define cómo publicar y suscribir objetos sin describir primero los tipos en otro lenguaje, como XML u OMG IDL. En 2014 se especificó un lenguaje de definición de interfaz (IDL) independientemente del capítulo 3 de la especificación Common Object Request Broker Architecture (CORBA). Este IDL 3.5 era compatible con la especificación CORBA 3, pero se extrajo como su propia especificación, lo que le permitió evolucionar independientemente de CORBA. .

Otros protocolos a mencionar son: DDS-XRCE (DDS para entornos con recursos extremos), este protocolo de especificación permite la comunicación entre dispositivos de recursos limitados, como un microcontrolador por ejemplo y una red DDS. Hace posible la publicación y suscripción de temas a través de un servicio intermedio en un dominio DDS y DDS-RPC (RPC sobre DDS) que define llamadas a procedimientos remotos. Estos proporcionan una comunicación bidireccional de solicitud/respuesta y determinan servicios distribuidos, y se detallan mediante una interfaz de servicio. También admite la invocación de métodos tanto sincrónicos como asincrónicos.

A partir de la versión 1.4 de DDS en 2015, la capa DLRL opcional se trasladó a una especificación independiente.