DDS（Data Distribution Service）是一套通信协议和 API 标准；它提供了以数据为中心的连接服务，基于发布者-订阅者模型。本文记录相关内容。
OMG DDS (Data Distribution Service) 是一个中间件协议和API标准，它提供低延迟、高可靠的以数据为中心的连接，对系统组件进行集成，为业务和关键任务物联网 (IoT)应用程序提供所需的可扩展架构。
DDS最早应用在美国海军系统，用于解决军舰系统复杂网络环境中大量软件升级的兼容性问题。在汽车领域，2018年Adaptive AUTOSAR引用了DDS，作为可选择的通信方式之一。目前国内已有主机厂开始研究，主要针对自动驾驶相关需求，工具方面，在汽车电子领域常用的工具厂商也在开发这部分内容。不仅是汽车领域引入DDS，在机器人开发领域，最新升级的ROS2也引入了DDS中间件来传递信息。
在分布式系统中，中间件是位于操作系统和应用程序之间的软件层。它使系统的各个组件能够更轻松地通信和共享数据。它通过屏蔽应用程序和系统之间传递信息的机制，让软件开发人员专注于应用程序设计，从而简化分布式系统软件开发。
DDS 中间件是一个软件层，它将应用程序从操作系统、网络传输和底层数据格式的细节中抽象出来。DDS中间件为不同的编程语言提供相同的概念和API，允许应用程序跨操作系统、编程语言和处理器架构交换信息。
数据格式、应用程序的互相发现、数据连接、可靠性、协议、传输方式选择、QoS、安全性等底层细节由中间件管理。
DDS是一个以数据为中心的开放式国际互联标准，是一个经过验证的工业物联网数据连接标准。DDS标准主要有以下优点：
通信中间件采用的模型一共经历过四代演变：
点对点模型：常见的服务器/客户端(Client/Server)模式。通信时，服务器和客户端直接连接，导致服务器和客户端的耦合程度过高，且服务器的异常会直接影响到客户端。
Broker模型：由Broker集中统一处理所有请求，解决了通信双方的耦合问题，当服务器地址发生变化时，客户端不受影响。但是一旦Broker出现异常，会影响整个系统，且当请求规模达到一定程度，会因为Broker处理速度慢而影响整体的性能，可靠性很低。
广播模型：通信双方不用单独连接，而是借助于一种总线——广播信道。只需借助广播信道发送和接收信号。由于所有的通信实体都可以从广播信道接收所有的信号，而无论该实体是否需要这个信号，这样会浪费传输带宽。
以数据为中心的模型：与广播模型类似，所有通信实体都可以往“总线”发布和订阅消息，但是这个“总线”根据数据不同划分了很多数据空间，每个通信实体在数据空间内只收到和自己关联的信号。
DDS 提供基于QoS控制的数据共享。应用程序通过发布和订阅由其主题名称标识的主题进行通信。应用程序订阅时可以指定时间和内容过滤器，以获取在该主题上发布的数据的子集。不同的DDS数据域彼此完全独立，DDS数据域之间无法完成数据共享。
现实中有许多通信中间件的标准和产品，DDS以数据为中心的特性使其非常适合工业物联网。大多数中间件通过在应用程序和系统之间发送信息来工作。以数据为中心的特性确保所有通过DDS发送的消息都包含应用程序能够完全理解其接收数据所需的上下文信息。
以数据为中心的本质是 DDS 知道它存储了什么数据并控制如何共享这些数据。使用传统的以消息为中心的中间件的程序员必须编写发送消息的代码。使用以数据为中心的中间件的程序员编写代码仅需指定如何以及何时共享数据。DDS 不是在应用程序代码中管理所有这些复杂性，而是直接为应用程序实现受控、托管、安全的数据共享。
从概念上讲，DDS将本地数据存储区称为“全局数据空间”。对应用程序来说，全局数据空间就像通过API访问的本地内存。应用程序发送数据看起来像写入本地存储。实际上，DDS会发送消息来更新远程节点上的存储。远程节点上的接收方程序看起来像从本地存储取得数据。
在 DDS域内，信息共享单元是主题内的数据对象。主题由其名称标识，数据对象由一些“键值”属性标识，类似于使用关键属性来标识数据库中的记录。DDS应用程序之间为点对点通信，不需要通过服务器或云来转发数据。
总的来说，本地存储给应用程序一种可以访问整个全局数据空间的错觉。这只是一种错觉，没有一个公共的地方可以存放所有数据。每个应用程序只在本地存储它需要的内容，并且只在它需要的时间窗口内存储。全局数据空间是一个虚拟概念，实际上只是本地存储的集合。使用任意语言开发并在任意系统上运行的应用程序，都以最恰当的方式访问本地内存。 全局数据空间使得应用程序可以跨多种传输方式在嵌入式、移动和云之间共享数据并且具有极低的延迟。
数据可以通过灵活的服务质量 (QoS) 规范实现共享，包括可靠性、系统健康程度（活跃度）以及安全性。真实系统中并非所有其他应用程序都需要本地存储中的每条数据。DDS可以智能地发送其他应用程序需要的数据。如果数据无法100%到达其预定接收方，DDS中间件提供可靠性QoS解决这一问题。
当系统发生变化时，DDS中间件动态地确定将哪些数据发送到哪里，并将变化通知参与者。如果总数据量很大，DDS会自动过滤数据并且只发送每个应用程序真正需要的数据。当需要快速更新数据时，DDS会发送多播消息，在发送一次数据情况下，远程应用程序都能接收到数据。随着数据格式的发展，DDS中间件会获取系统各个应用程序使用的DDS版本并自动进行数据转换。对于安全关键型应用程序，DDS中间件提供控制访问、强制执行指定数据流路径传输以及即时加密数据等功能确保其安全性。
在一个非常动态、苛刻和不可预测的环境中，当应用程序同时使用这些QoS时，DDS 的强大功能便体现出来，并且以极快的速度完成高效可靠的数据传输。
DDS 提供发布者和订阅者的动态发现。动态发现使DDS 应用程序可扩展。意味着应用程序不必知道或配置用于通信的端点，因为它们会被 DDS 自动发现。这可以在程序运行时完成，而不必在设计或编译时完成。这一特点为 DDS 应用程序实现真正的“即插即用”。
DDS的动态发现比应用程序的发现更进一步，DDS会发现应用程序是在发布数据、订阅数据还是既发布也订阅数据，同时DDS也将发现应用程序正在发布或订阅的数据类型。它还将发现发布者提供的通信特性和订阅者请求的通信特性。在DDS参与者的动态发现和匹配过程中，所有这些属性都会被考虑在内。
DDS参与者可以在同一台机器上也可以通过网络连接。应用程序使用相同的DDS API 进行通信。由于无需了解或配置 IP 地址，也无需考虑机器架构的差异，因此在任何操作系统或硬件平台上添加额外的通信参与者都变得非常简单。
DDS 包括为信息分发提供身份验证、访问控制、机密性和完整性的安全机制。DDS Security 使用分散的对等架构，可在不牺牲实时性能的情况下提供安全性。
DDS的通信模型DCPS
| 概念 | 含义 | 备注 |
|---|---|---|
| Domain | 代表一个通信平面，由Domain ID唯一标识，只有在同一个域内的通信实体才可以通信；可以只划分1个Domain，也可以按照交互规则或其他规则，定义多个Domain； | |
| Domain Participant | 代表域内通信的应用程序的本地成员身份，简单来说，就是说明同一数据域内的通信成员； | |
| Topic | 是数据的抽象概念，由TopicName标识，关联相应数据的数据类型(DataType)，把所涉及的所有Topic集合在一起，这样就形成一个虚拟的全局数据空间“Global Data Space”，这里弱化了节点的概念； | |
| DataWriter | 数据写入者，类似缓存，把需要发布的Topic数据从应用层写入到DataWriter中； | |
| DataReader | 数据读取者，同样可以理解为一种缓存，从订阅者得到Topic数据，随之传给应用层； | |
| Publisher | 发布者，发布主题数据，至少与1个DataWriter关联，通过调用DataWriter的相关函数将数据发出去； | |
| Subscriber | 订阅者，订阅主题数据，至少与1个DataReader关联。当数据到达时，应用程序可能忙于执行其他操作或应用程序只是等待该消息时，这样就会存在两种情况，同步访问和异步通知。 | |
| QoS | 服务质量(Quality of Service)，这是DDS的亮点，通过定义灵活的QoS规则，包括可靠性、系统健康(活跃度)甚至安全性，也可以共享数据。DDS在发送它所需要的信息方面很聪明。如果消息不能总是到达它们预期的目的地，那么中间件将在需要的地方实现可靠性。当系统发生变化时，中间件动态地计算出向何处发送哪些数据，并智能地通知参与者这些变化。如果总数据量很大，DDS会智能地过滤并只发送每个端点真正需要的数据。当更新需要快速时，DDS发送多播消息来一次更新许多远程应用程序。随着数据格式的发展，DDS跟踪系统各个部分使用的版本，并自动转换。对于安全性至关重要的应用程序，DDS控制访问、强制数据流路径并实时加密数据。 |
根据前面介绍，我们清楚了DDS是一个以数据为中心的中间件协议和API标准，意为用户只关心自己想要的数据，数据通过Topic进行标识，这样发布者根据主题发布数据，订阅者根据自己感兴趣的主题订阅数据。这便是DDS的核心，以数据为中心的发布-订阅模型DCPS（Data-Centric Publish-Subscribe）
如果是熟悉的以服务为中心的SOME/IP中间件，我们需要做的是把数据打包成服务，之后服务的消费方向服务提供方通过SD订阅服务中的事件组，当数据发生变化后，相应的事件报文便会发到总线上。相比之下，DDS确实很直接，直接与数据沟通。
传统分布式系统采用点对点的方案，会面临通道数量爆炸式增长问题：
而采用 DDS，拥有统一的 DDS DataBus，随着新节点的加入，不会增加拓扑的复杂度；
采用基于 DDS 的上层应用，能极大简化复杂度
OMG DDS标准主要包括以下规范：
DDS v1.4：DDS 规范描述了以数据为中心的发布-订阅 (DCPS) 模型，该模型用于分布式应用程序通信和集成。
DDSI-RTPS v2.3：RTPS规范定义了实时发布-订阅协议 (RTPS)，此协议为DDS标准中互操作有线协议。
DDS-XTypes v1.3：此规范定义DDS数据类型系统以及DDS数据的序列化表示方法。
DDS-Security v1.1：此规范为DDS实现定义了安全模型和服务插件接口 (SPI) 架构。
IDL4 v4.2(即ISO标准ISO/IEC 19516:2020)：接口定义语言（Interface Definition Language）规范定义了IDL，一种用于以独立于编程语言的方式定义数据类型和接口的语言。IDL规范不是 DDS 标准，但 DDS 依赖于它。
IDL4-JAVA：此规范定义了 IDL4 类型到 Java 语言的映射。
IDL4-C#：此规范定义了 IDL4 类型到 C# 语言的映射。
DDS C++ API**（对应ISO/IEC C++ 2003）**：此规范为DDS规范中以数据为中心的发布-订阅 (DCPS) 部分定义了C++ API。
DDS Java API**（对应Java 5）**：此规范为DDS规范中以数据为中心的发布-订阅 (DCPS) 部分定义了Java API。
DDS-RPC v1.0：此规范定义了一个分布式服务框架，该框架提供了独立于语言的服务定义以及使用DDS进行通信的服务/远程过程调用。此规范支持自动发现，同步和异步调用并可使用多种QoS。
DDS-XML v1.0：此规范定义了用于表示DDS相关资源的XML语法，为DDS服务质量 (QoS)、DDS 数据类型和DDS 实体（DomainParticipants、Topics、Publishers、Subscriber、DataWriters和DataReaders）提供XSD模式文件。
DDS-JSON v1.0：此规范定义了用于表示 DDS 相关资源的JSON语法，为 DDS 服务质量 (QoS)、DDS数据类型、DDS数据和 DDS 实体（DomainParticipants、Topics、Publishers、Subscriber、DataWriters和DataReaders）提供JSON模式文件。
DDS-WEB v1.0：此规范定义了一个独立于平台的抽象交互模型，用于说明Web客户端应该如何访问DDS系统以及一组DDS到特定 Web 平台的映射，这些特定 Web 平台在标准Web技术和协议方面实现了平台无关模型 (PIM)。
DDS-OPCUA v1.0**](https://www.omg.org/spec/DDS-OPCUA/1.0/PDF)：此规范定义了一个标准的、可配置的网关，它支持使用DDS的系统和使用OPCUA的系统之间的互操作和信息交换。
DDS-XRCE v1.0](https://www.omg.org/spec/DDS-XRCE/1.0/PDF)**：此规范定义了资源受限的低功耗设备向DDS域发布和订阅数据的协议。XRCE协议将XRCE客户端（Client）与DDS 代理（Agent）连接，该DDS代理充当连接至DDS域的网关。
DDS-TSN：此规范定义了一组机制，这些机制可以将DDS部署到时间敏感网络 (TSN) 上，并利用TSN特性实现特定功能。此规范定义了DDSI-RTPS 协议到 TSN 传输方式的映射。
DDSI-RTPS TCP/IP PSM：此规范定义了DDSI-RTPS 协议到TCP/IP传输方式的映射。
DDS C# API：此规范为DDS规范中以数据为中心的发布-订阅 (DCPS) 部分定义了C# API。
DDS规范描述了以数据为中心的**发布****-**订阅(DCPS)模型，该模型用于分布式应用程序通信和集成。该规范定义了应用程序接口 (API) 和通信语义（行为和服务质量QoS），它们能够有效地将信息从信息生产者传递到匹配的信息消费者。DDS规范的目的可以概括为：在正确的时间将正确的信息高效、可靠地传送到正确的地点。
DDS规范总共有四个正式版本，如下表所示：
| 版本编号 | 发布时间 | 获取链接 |
|---|---|---|
| V1.4 | 2015年3月 | https://www.omg.org/spec/DDS/1.4/ |
| V1.2 | 2006年12月 | https://www.omg.org/spec/DDS/1.2/ |
| V1.1 | 2005年12月 | https://www.omg.org/spec/DDS/1.1/ |
| V1.0 | 2004年12月 | https://www.omg.org/spec/DDS/1.0/ |
其中1.4版本相较于1.2版本最大的变化是将1.2版本中的可选部分（第八章 数据本地重建层）去除。
规范中关于DDS内部数据类型的定义可通过DDS 20140501 dds_dcps.idl及DDS 20140501 dds_dlrl.idl获取。
规范中文版可参考规范中文版链接。
RTPS规范定义了DDS的互操作有线协议。它的目的和范围是为了确保基于不同供应商DDS实现的应用程序可以互操作。
RTPS规范总共有四个正式版本，如下表所示：
| 版本编号 | 发布时间 | 获取链接 |
|---|---|---|
| V2.3 | 2019年5月 | https://www.omg.org/spec/DDSI-RTPS/2.3/ |
| V2.2 | 2014年9月 | https://www.omg.org/spec/DDSI-RTPS/2.2/ |
| V2.1 | 2010年11月 | https://www.omg.org/spec/DDSI-RTPS/2.1/ |
| V2.0 | 2008年4月 | https://www.omg.org/spec/DDSI-RTPS/2.0/ |
其中2.3版本相较于2.2版本主要修改了以下部分：
8.2.1中Participant类与Endpoint类关系由2.2版本中的无关系变为组合关系；Participant类增加guidPrefix成员变量，Endpoint类增加endpoint成员变量；
8.2.3 RTPS CacheChange类增加inlineQoS成员变量；
8.2.4 RTPS Entity类增加了同一参与者内部端点组的GUID信息，主要是指Publisher和Subscriber的GUID；同时Endpoint类也继承Entity类；
8.2.5 RTPS Participant类与Endpoint类之间增加了一个Group类；
8.3.2关于数据类型定义添加了GroupDigest_t类型；
8.3.3 RTPS消息组成结构部分去除NoKeyData以及NoKeyDataFrag类型；
8.3.4 RTPS消息接收器（RTPS Message Receiver）增加对HeaderExtension的依赖；
8.3.5 RTPS子消息元素（RTPS SubmessageElements）增加了KeyHashPrefix、KeyHashSuffix以及GroupDigest数据类型的支持；将2.2版本的Flags数据类型改为StatusInfo类型；将SerializedPayload以及SerializedPayloadFragment类型合并为SerializedData类型；
8.3.7.2 Data报文类型添加NonStandardPayloadFlag字段；
8.3.7.3 DataFrag报文类型添加NonStandardPayloadFlag及KeyFlag字段；
8.3.7.4 Gap报文类型添加GroupInfoFlag、gapStartGSN以及gapEndGSN字段；
8.3.7.5 Heartbeat报文类型添加GroupInfoFlag、currentGSN、firstGSN、lastGSN、writerSet以及secureWriterSet字段；
8.4.7.1 RTPS Writer类增加dataMaxSizeSerialized成员变量；RTPS Writer类的new_change方法增加inlineQos参数。
8.4.7.2 RTPS StatelessWriter类去除resendDataPeriod数据成员；
8.4.7.5 RTPS ReaderProxy类增加remoteGroupEntityId成员；
8.4.10.4 RTPS WriterProxy类增加dataMaxSizeSerialized和remoteGroupEntityId成员；
8.4.12.1 Best-Effort StatefulReader 行为变换图改变；
8.4.13.4 Participant Message Data数据组成添加kind字段；
8.4.15.7 在HeartbeatFrag和NackFrag报文中增加count；
8.5.3.2 SPDPdiscoveredParticipantData数据类型增加domainId、domainTag 和builtinEndpointQos字段；
8.7.5 添加Group Ordered Access实现；
9.3.1.2 EntityId_t添加Writer Group和Reader Group实体ID类型；
9.6.3 In-line QoS增加PID_GROUP_COHERENT_SET、PID_GROUP_SEQ_NUM、PID_WRITER_GROUP_INFO以及PID_SECURE_WRITER_GROUP_INFO等字段支持；
10 数据串化封装增加CDR2_BE、CDR2_LE、PL_CDR2_BE、PL_CDR2_LE、D_CDR_BE、D_CDR_LE和XML 等版本字段。
RTPS 2.3版本UML模型XML文件见DDSI-RTPS 2.3 UML Model XMI file-18-08-18.xml。
规范中文版可参考规范中文版链接。
DDS-XTYPES规范定义了可用于DDS主题的数据类型模型。数据类型系统是使用 UML 正式定义的。该数据类型系统在规范的7.2节及其子条款中定义。
DDS-XTYPES规范总共有四个正式版本，如下表所示：
| 版本编号 | 发布时间 | 获取链接 |
|---|---|---|
| V1.3 | 2020年2月 | https://www.omg.org/spec/DDS-XTypes/1.3/ |
| V1.2 | 2017年9月 | https://www.omg.org/spec/DDS-XTypes/1.2/ |
| V1.1 | 2014年10月 | https://www.omg.org/spec/DDS-XTypes/1.1/ |
| V1.0 | 2012年10月 | https://www.omg.org/spec/DDS-XTypes/1.0/ |
DDS-XTYPES规范规范性的辅助文档主要包含以下五个文档：
DDS-SECURITY规范定义了符合 DDS 实现的安全模型和服务插件接口 (SPI) 架构。DDS 安全模型通过 DDS 实现调用这些SPI来强制执行。本规范还定义了一组这些SPI的内置实现。
DDS-SECURITY规范总共有两个正式版本，如下表所示：
| 版本编号 | 发布时间 | 获取链接 |
|---|---|---|
| V1.1 | 2018年7月 | https://www.omg.org/spec/DDS-SECURITY/1.1/ |
| V1.0 | 2016年8月 | https://www.omg.org/spec/DDS-SECURITY/1.0/ |
DDS-SECURITY规范规范性的辅助文档主要包含以下四个文档：
文章链接：
https://www.zywvvd.com/notes/protocol/communication/dds-protocol/dds-protocol/
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。