什么是DDS？初识CP AUTOSAR平台下的DDS规范

什么是DDS

数据分发服务（DDS）[1]是一个来自对象管理组（OMG）的中间件协议和API标准。它将系统的组件集成在一起，提供低延迟的数据连接，极高的可靠性，和可扩展的架构。

DDS中间件是一个软件层，它将应用程序从操作系统，网络传输，和低级数据格式的细节中抽象出来。底层的细节，例如数据线格式，发现，连接，可靠性，协议，传输选择，QoS，安全等，都由中间件管理。

DDS提供了QoS控制的数据共享。应用程序通过发布和订阅主题（topic）来进行通信，主题由它们的主题名和类型来标识。订阅者可以通过时间和内容过滤器来获取主题上发布的数据的一个子集。不同的DDS域彼此完全独立。DDS域之间没有数据共享。

DDS以数据为中心，这个特点保证了所有的消息都包含了应用程序需要理解数据的上下文信息。DDS知道它存储了什么数据，并控制了如何共享这些数据。使用传统的基于消息的中间件的程序员必须编写发送消息的代码。使用数据中心化的中间件的程序员编写指定如何和何时共享数据的代码，然后直接共享数据值。而不是在应用程序（用户）代码中管理所有这些复杂性，DDS直接为用户实现了受控的，管理的，安全的数据共享。

全局数据空间

DDS依赖于一个与平台无关的数据模型。这个模型定义了全局数据空间，并指定了发布者和订阅者如何引用这个空间的一部分。数据模型可以简单到一组没有关联的数据结构，每个数据结构由一个主题和一个类型来标识。

主题提供了一个唯一标识全局数据空间中某些数据项的标识符。类型提供了结构信息，告诉中间件如何操作数据。使用类型化接口意味着需要一个生成工具，将类型描述转换为适当的接口和实现，填补类型化接口和通用中间件之间的差距。

以下定义可能有助于更好地理解DDS。

实体Entity：DDS的基本对象，几乎所有其他对象都是它的特化。

发布者Publisher：这个对象负责数据分发。它可以发布不同数据类型的数据。

数据写入DataWriter：应用程序必须使用数据写入器来向发布者通知给定类型的数据对象的存在和值。当数据对象的值通过适当的数据写入器传递给发布者时，发布者有责任执行分发（发布者将根据自己的QoS或附加到相应数据写入器的QoS来执行此操作）。

订阅者Subscriber：订阅者负责接收发布的数据，并根据订阅者的QoS使其可用于接收应用程序。它可以接收和分发不同指定类型的数据。

数据读取DataReader：订阅者使用数据读取器来向应用程序提供特定类型的接收数据。

域Domain：域是一个分布式的概念，它连接了所有能够相互通信的应用程序。它代表了一个通信平面：只有附加到同一域的发布者和订阅者才能相互作用。

服务质量（QoS）：QoS（服务质量）是一个通用的概念，用于指定一个实体的行为。QoS由单个QoS策略（QosPolicy类型的对象）组成。影响不同实体的一个或多个QoS策略的特定值可以分组在QoS配置文件中。

主题Topic：一个主题对应于一个单一的数据类型。主题对象在概念上位于发布和订阅之间。发布必须以一种订阅可以明确引用的方式被知晓。主题的目的就是满足这个需求：它将一个名字（在域中唯一）、一个数据类型和与数据本身相关的QoS关联起来。除了主题QoS之外，与该主题相关的数据写入器的QoS和与数据写入器相关的发布者的QoS控制了发布者端的行为，而相应的主题、数据读取器和订阅者QoS控制了订阅者端的行为。

DDS是一个以数据为中心的发布订阅协议，这个协议定义了应用程序发布和订阅数据对象的值的功能。它允许：

发布应用程序标识它们打算发布的数据对象，然后提供这些对象的值（它们使用一些在某些域参与者中定义的发布者/数据写入器）。

订阅应用程序标识它们感兴趣的数据对象，然后访问它们的数据值（它们使用一些在与它们想要接收数据的各个主题的发布者相同的域参与者中定义的订阅者/数据读取器）。

应用程序定义主题，将类型信息附加到主题，创建发布者和订阅者实体，将QoS策略附加到所有这些实体，总之，使所有这些实体运行。

CP中的DDS模块

DDS模块实现实体管理，QoS等接口逻辑，还有DDSI-RTPS标准层，它是一个具备以下功能的协议栈：

序列化

反序列化

数据过滤

数据记录

数据持久化

数据重传

信息安全

E2E保护

从传输路径的角度来看，DDS模块只提供了一个基于PDU的接口，用于传入（例如，上层PDU）和传出（例如，下层PDU）的PDU。

基本上，在发送端，Dds数据是在应用层创建的，并直接传递给RTE（作为未序列化的数据），然后转发给LdCom，PduR，然后作为一个PDU转发给Dds模块，没有经过任何修改或转换（在接收端也是如此）。RTE，LdCom和PduR（作为上层）只是简单地充当透传模块。序列化是在Dds BSW内部执行的，对AUTOSAR堆栈完全不透明。Dds BSW应该知道复制数据的确切数据类型。

需要注意的是，在RTE，即使对于复合数据类型，也不会进行任何转换或序列化：数据会从应用层复制到ISignal（在LdCom缓冲区中），然后PduR将信息路由到DDS模块，数据到达Dds时完全没有修改。Dds模块能够通过其映射到PDU的类型来处理数据。下层PDU包含了DDSI-RTPS协议包，准备好交付给传输层。

传输层提供了一组适合于启用Dds通信的连接。例如，让我们考虑一个使用一些发布者/数据写入器在一些域参与者下的简单发布SW-C。如果本地域参与者不支持动态发现，那么对于每个数据写入器，就有必要静态配置适当的远程数据读取器可达性信息。接收端也应该发生类似的情况：本地数据读取器应该知道与之相关的数据写入器的可达性信息。这些信息应该用于适当的配置底层传输协议。

QoS管理

Dds BSW可以支持一部分（甚至为空）的QoS策略。没有必须实现的QoS。哪些QoS策略实际上是支持的，这是由供应商决定的。

对于DDS的TRANSPORT_PRIORITY QoS，由SoAdSocketFramePriority实现，但具体Dds模块在运行时需要自己选择发送PDU送到哪个优先级的SoAd connection上。

数据安全机制

在AP和CP之间，甚至在CP和非AUTOSAR平台之间，建立通信路径可能会涉及安全风险，因此可能需要使用一些安全机制。Dds BSW模块通过使用DDS安全规范来[2]保证一些安全机制。使用这个规范是为了保证与其他DDS系统的互操作性，无论是与AP（其中已经使用了DDS数据安全）还是与非AUTOSAR系统。然而，实现这个规范可能会非常消耗资源，特别是在一个慢速的微控制器上使用，这些功能需要硬件加速。为了克服这个问题，选择了一个DDS数据安全功能的子集，它能保证最低的安全级别。

在这个阶段，实现DDS数据安全的目的是为了保证消息认证，数据完整性和组认证。安全机制可以在配置时启用或禁用。如果启用，所有的安全参数必须在预编译时静态配置。

如果配置了，整个RTPS消息的消息认证码（MAC）会被添加。AUTOSAR CSM用于密钥管理和MAC计算，要使用的算法是可配置的（从支持的算法中选择）。

用于哈希算法的密钥是对称密钥，它们在与域参与者相关的实体之间共享，所以认证是在域参与者级别进行的（不是单个发布者/订阅者，不是单个数据写入器/数据读取器）。要使用的对称密钥应该由CSM直接管理，它应该提供一个handler给DDS，以便使用它的服务。为了上述目的，使用了DDS加密插件，它提供了一个接口来保护整个RTPS消息。在应用安全后，结果RTPS消息如下图所示。

功能安全机制

根据ISO 26262，在执行不同软件分区或ECU中的发送器和接收器之间的通信链路上的一组故障需要被考虑。

端到端保护的概念假定在运行时应保护与安全相关的数据免受通信链路内部故障的影响。

DDS规范具有内在的安全机制（计数器、CRC、QoS策略），可用于支持安全论证。

以下是在追求功能安全时需要解决的可能故障列表，以及DDS提供的支持它们的机制：

重复、丢失、插入、不正确的顺序、仅由接收器子集接收到的来自发送方的信息以及阻塞对通信通道的访问：子消息64位序列号，如DDS Interoperability Wire Protocol, Version 2.2第8节3.5.4“SequenceNumber”中定义的，以及在第8.3.7“RTPS Submessages”中定义的额外的SequenceNumber类型字段。这些机制仅对在接收器端检测丢失有用；如果还需要在发送器端进行检测，则应结合使用DDS QoS。

信息延迟和阻塞对通信通道的访问：LATENCY_BUDGET、DEADLINE和LIFESPAN质量服务策略，分别在Data Distribution Service (DDS), Version 1.4的2.2.3.8“LATENCY_BUDGET”、2.2.3.7“DEADLINE”和2.2.3.16“LIFESPAN”中定义的部分。

信息伪装或错误寻址：DDS安全认证插件，如DDS Security, Version 1.1 第8.3“Authentication Plugin”节中定义的。在这个概念中，只能在DomainParticipant级别实现身份验证，因为属于同一DomainParticipant级别的所有实体共享相同的对称密钥。这可以防止属于DomainParticipant之外的实体访问DomainParticipant通信，但不能区分被授权在DomainParticipant内部通信的两个不同实体。

信息损坏、从发送方发送到多个接收器的不对称信息（仅对导致无效CRC的情况有效）：位于HeaderExtension子消息下的rtpsMessageChecksum（[RTPS 2.5或更高版本]）。在没有此功能的情况下，DDS Security, Version 1.1 还提供了内置于其消息认证协议中的消息完整性验证。对于CRC计算，使用AUTOSAR CRC库。

对这些故障条件错误的通知：在发生任何通信错误或故障（甚至是超时错误）时，Dds BSW应通知Det模块。

审核编辑：刘清