DDSI-RTPS V2.3版本规范中文翻译 part1

1 范围

本规范定义了DDS的互操作性线协议。其目的和范围是确保基于不同供应商DDS实现的应用程序能够互操作。

2 合规性

实施本规范的实体必须遵守本规范第8.4.2节列出的合规性声明。

3 规范性引用

以下规范性文件包含规定，通过在本文中引用，构成本规范的规定。对于有日期的引用，任何这些出版物的后续修订或修改均不适用。

  [1] DDS规范v1.4（OMG文档正式/15-04-10）

  [2] 接口定义语言（IDL）v4.2（https://www.omg.org/spec/IDL）

  [3] DDS的可扩展和动态主题类型v1.2（https://www.omg.org/spec/DDS-XTypes）

  [4] 网络时间协议（版本3）（IETF RFC 1305，https://www.ietf.org/rfc/rfc1305.txt）

  [5] MD5消息摘要算法（IETF RFC 1321，https://www.ietf.org/rfc/rfc1321.txt）

4 术语和定义

就本规范而言，适用规范性引用中给出的术语和定义。

5 符号

  CDR 通用数据表示

  DDS 数据分发服务

  EDP 端点发现协议

  GUID 全局唯一标识符

  PDP 参与者发现协议

  PIM 平台独立模型

  PSM 平台特定模型

  RTPS 实时发布-订阅

  SEDP 简单端点发现协议

6 附加信息

6.1 对采纳的OMG规范的更改

本规范不更改任何已采纳的OMG规范。它是OMG DDS规范的补充（参见https://www.omg.org/spec/DDS/1.4/）。

6.2 如何阅读本规范

本规范定义了DDS互操作性协议。不熟悉DDS的DataReader首先阅读DDS规范将会有所帮助。

要了解RTPS（实时发布-订阅）的非常高层次概述和本文档结构的简要描述，请参阅引言。后续条款将更详细地涵盖RTPS。

虽然提供了PIM（平台独立模型）和PSM（平台特定模型）增加了本文档的篇幅，但这种方法也使得选择性阅读的DataReader能够轻松挑选出感兴趣的子条款：

初次接触RTPS的DataReader可以从阅读PIM的结构和消息模块开始。这些模块提供了RTPS协议参与者的概述，它们与DDS实体的关系，RTPS消息的存在以及它们的结构。

想要探索RTPS消息交换协议的DataReader可以阅读行为模块的第一部分。RTPS是一个相当灵活的协议，允许实现根据它们希望在远程端点上保持多少“状态”来定制它们的行为。行为模块的第一部分列出了任何符合RTPS的实现必须满足的通用要求，以保持与其他实现的互操作性。

行为模块的第二部分定义了两个参考实现。一个参考实现在远程端点上维护完整状态，另一个则不维护。对于想要更详细了解RTPS消息交换协议的读者来说，这个子条款可能会有兴趣，但初次阅读的读者可以轻松跳过。

对于有兴趣了解RTPS如何处理远程端点的动态发现的读者，可以参考独立的发现模块。

对于计划实施RTPS或定义新的PSM的读者，PSM条款包含了关于如何将RTPS PIM映射到UDP/IP PSM的详细讨论。

最后，关于数据表示的条款定义了与RTPS一起使用的各种数据表示机制。

6.3 致谢

以下公司提交和/或支持了本规范的部分内容：

•   Real-Time Innovations, Inc
•   THALES
•   PrismTech

6.4 概念验证声明

本提案中规定的协议已证明其在数据分发系统中的性能和适用性。该协议是实时创新公司实施DDS的使用协议，在本规范最初采纳之前的5年中已在全球数百个应用中部署。

本文档中的协议还是IEC实时工业以太网套件IEC-PAS-62030 IEC标准的一部分，展示了其适用于要求严格的实时和资源受限的工业控制环境。

7 概述

7.1 引言

最近采纳的数据分发服务规范定义了一个应用程序级接口和数据分发服务（DDS）的行为，该服务支持实时系统中的以数据为中心的发布-订阅（DCPS）。DDS规范使用了模型驱动架构（MDA）方法来精确描述特定的以数据为中心的通信模型：

• 应用程序如何建模其希望发送和接收的数据。
• 应用程序如何与DCPS中间件交互，指定其希望发送和接收的数据以及服务质量（QoS）要求。
• 数据如何发送和接收（相对于QoS要求）。
• 应用程序如何访问数据。
• 应用程序从中间件状态获取的反馈类型。

DDS规范还包括了对IDL的平台特定映射，因此使用DDS的应用程序只需重新编译即可在不同的DDS实现之间切换。因此，DDS解决了“应用程序可移植性”的问题。

DDS规范没有涉及实现使用的协议来通过像TCP/UDP/IP这样的传输交换消息，所以不同的DDS实现之间将无法互操作，除非提供特定于供应商的“桥接”。因此，情况与JMS等其他消息API标准类似。

随着DDS在大型分布式系统中的日益采用，定义一个标准的“线协议”来允许来自多个供应商的DDS实现互操作是可取的。理想的“DDS线协议”应能够利用DDS可配置的QoS设置，优化其对底层传输能力的使用。特别是，理想的线协议必须能够利用许多DDS QoS设置的组播、尽力而为和无连接的特性。

7.2 对DDS线协议的要求

在网络通信和许多其他工程领域中，一个事实是“一种尺寸并不适合所有”。工程设计是关于做出正确的权衡集合，这些权衡必须平衡相互冲突的要求，如通用性、易用性、功能丰富性、性能、内存大小和使用、可伸缩性、确定性和鲁棒性。这些权衡必须考虑到信息流的类型（例如，周期性与突发性、基于状态与基于事件、一对多与请求-回复、尽力而为与可靠性、小数据值与大文件等），以及应用程序和执行平台施加的限制。

因此，诸如HTTP、SOAP、FTP、DHCP、DCE、RTP、DCOM和CORBA等许多成功的协议应运而生。这些协议中的每一个都填补了一个利基，为特定目的或应用领域提供了良好调整的功能。

DDS的基本通信模型是单向数据交换，其中发布数据的应用程序将相关的数据更新“推送”到多位订阅者的本地缓存中。这种信息流由DataWriters和DataReaders之间隐含建立的QoS合同来调节。DataWriter在宣布其发布数据的意图时指定其QoS合同，DataReader在宣布其订阅数据的意图时也是如此。通信模式通常包括多对多风格的配置。部署DDS技术的应用程序的主要关注点是以最小的开销以高效的方式分发信息。另一个重要要求是需要以鲁棒的容错方式扩展到数百或数千个订阅者。

DDS规范规定了一个内置的发现服务，允许发布者动态地发现订阅者的存在，反之亦然，并且在不需要联系任何名称服务器的情况下持续执行这项任务。

DDS规范还规定，实现不应引入任何单点故障。因此，协议不能依赖于集中式名称服务器或集中式信息代理。部署DDS的应用程序的大规模、松散耦合、动态性质，以及适应新兴传输的需求，要求在数据定义和协议方面具有一定的灵活性，以便每个方面都能在保持与已部署系统的向后兼容性的同时进行发展。

7.3 RTPS线协议

实时发布订阅（RTPS）协议起源于工业自动化，并且实际上被IEC批准为实时工业以太网套件IEC-PAS-62030的一部分。它是一种经过实地验证的技术，目前在全球数千个工业设备中部署。

RTPS专门开发用于支持数据分发系统的独特要求。作为DDS目标应用领域之一，工业自动化社区为标准发布-订阅线协议定义了要求，这些要求与DDS的要求非常吻合。因此，DDS与RTPS线协议之间存在着紧密的协同关系，无论是在潜在的行为架构上还是在RTPS的特性上。

RTPS协议旨在能够在像UDP/IP这样的组播和无连接尽力而为传输上运行。RTPS协议的主要特性包括：

• 性能和服务质量属性，以支持通过标准IP网络实现实时应用程序的尽力而为和可靠发布-订阅通信。
• 容错能力，以创建没有单点故障的网络。
• 可扩展性，以允许协议通过添加新服务进行扩展和增强，而不破坏向后兼容性和互操作性。
• 即插即用连接性，使新应用程序和服务能够自动被发现，应用程序可以随时加入和离开网络，无需重新配置。
• 可配置性，以平衡每次数据传递的可靠性和及时性要求。
• 模块性，以允许简单设备实现协议的一部分子集，并仍然参与网络。
• 可扩展性，以实现系统潜在地扩展到非常大的网络。
• 类型安全性，以防止应用程序编程错误危及远程节点的操作。

以上特性使RTPS成为DDS线协议的绝佳匹配。鉴于其发布-订阅的根源，这并非巧合，因为RTPS专门设计用于满足DDS应用领域提出的类型要求。

本规范定义了RTPS协议使用的消息格式、解释和使用场景。

7.4 RTPS平台独立模型（PIM）

RTPS协议用平台独立模型（PIM）和一组PSM来描述。

RTPS PIM包含四个模块：结构、消息、行为和发现。结构模块定义了通信端点。消息模块定义了这些端点可以交换的消息集。行为模块定义了合法交互（消息交换）的集合以及它们如何影响通信端点的状态。换句话说，结构模块定义了协议的“参与者”，消息模块定义了“语法符号”的集合，行为模块定义了不同对话的合法语法和语义。发现模块定义了实体是如何被自动发现和配置的。

在PIM中，消息是根据它们的语义内容定义的。然后可以将这个PIM映射到各种平台特定模型（PSM），例如普通UDP或CORBA事件。

7.4.1 结构模块

鉴于其发布-订阅的根源，RTPS自然地映射到许多DDS概念上。本规范使用许多DDS规范中相同的核心实体。如图7.2所示，所有RTPS实体都与RTPS域相关联，RTPS域代表了一个包含一组参与者的单独通信平面。参与者包含包含本地端点的组。端点有两种类型：DataReader和DataWriter。DataReader和DataWriter是通过发送RTPS消息来通信信息的参与者。DataWriter通知域上的存在并发送本地可用数据给DataReader，DataReader可以请求并确认这些数据。

RTPS协议中的参与者与引起通信发生的DDS实体之间有一对一的对应关系。这在图7.3中有所展示。

结构模块在8.2中描述。

7.4.2 消息模块

消息模块定义了RTPSDataWriter和读者之间原子信息交换的内容。消息由一个头部和若干子消息组成，如图7.4所示。每个子消息由一系列子消息元素构建。选择这种结构是为了允许子消息的词汇和每个子消息的组成能够在保持向后兼容性的同时被扩展。

消息模块详细讨论位于第8.3节。

7.4.3 行为模块

行为模块描述了RTPS DataWriter和DataReader之间可以交换的消息序列，以及每条消息对DataWriter和DataReader状态的时序和变化。

为了互操作性，所需的行为以一组实现必须遵循的最低规则来描述，以保证互操作性。实际的实现可能会展示出超出这些最低要求的不同行为，这取决于它们希望如何在可伸缩性、内存要求和带宽使用之间进行权衡。

为了阐释这一概念，行为模块定义了两个参考实现。一个参考实现基于状态化DataWriter（StatefulWriters）和状态化DataReader（StatefulReaders），另一个基于无状态DataWriter（StatelessWriters）和无状态DataReader（StatelessReaders），如图7.2 - RTPS结构模块所示。两个参考实现都满足互操作性的最低要求，因此是互操作的，但由于它们在匹配的远程实体上存储的信息不同，表现出略有不同的行为。实际实现RTPS协议的行为可能与参考实现完全匹配或是它们的组合。

7.4.4 发现模块

发现模块描述了一种协议，使参与者能够获取有关域中所有其他参与者和端点的存在和属性的信息。这种元流量使得每个参与者能够获得域中所有参与者、DataReader和DataWriter的完整情况，并配置本地DataWriter与远程读者通信，以及本地读者与远程DataWriter通信。

发现是一个独立的模块。发现的独特需求，即透明的即插即用传播所有匹配DataWriter和DataReader关联所需的信息，使得不太可能有单一架构或协议能满足DDS将被部署的各种异构网络极其变化的可伸缩性、性能和可嵌入性需求。因此，引入从简单高效（但不是很可伸缩）到更复杂的分层（但更可伸缩）机制的多种发现机制是有意义的。

发现模块在8.5中进行了描述。

7.5 RTPS平台特定模型（PSM）

平台特定模型将RTPS PIM映射到特定的底层平台。它定义了所有RTPS类型和消息以及与平台相关的任何其他信息的精确位和字节表示。

可能支持多个PSM，但所有DDS实现至少必须在UDP/IP之上实现PSM，这在第9条中提出。

7.6 RTPS传输模型

RTPS支持广泛的传输和传输QoS。该协议设计为能够在组播和尽力而为传输上运行，例如UDP/IP，并且只需要从传输中获得非常简单的服务。实际上，传输提供一种能够尽力而为发送数据包的无连接服务就足够了。也就是说，传输不需要保证每个数据包都能到达目的地，或者数据包按顺序传送。在需要时，RTPS在传输接口之上实现数据和状态的可靠传输。这并不妨碍在可靠传输之上实现RTPS。它只是使得支持更广泛的传输成为可能。

如果可用，RTPS还可以利用传输机制的组播能力，其中来自发送者的一条消息可以到达多个接收者。RTPS旨在促进底层通信机制的确定性。协议在确定性和可靠性之间提供了一个开放的权衡。

RTPS对底层传输提出的一般要求可以总结如下：

• 传输具有单播地址的一般化概念（应该在16字节内）。
• 传输具有端口的一般化概念（应该在4字节内），例如，可能是UDP端口、共享内存段中的偏移量等。
• 传输可以向特定地址/端口发送数据报（未解释的八位字节序列）。
• 传输可以在特定地址/端口接收数据报。
• 如果传输过程中数据报不完整或损坏，传输将丢弃消息（即，RTPS假设消息是完整且未损坏的）。
• 传输提供了推断接收消息大小的方法。