DDS协议解读及测试开发实践

DDS概述

DDS是OMG在2004年发布的中间件协议和应用程序接口（API）标准，它为分布式系统提供了低延迟、高可靠性、可扩展的通信架构标准。DDS目前在工业、医疗、交通、能源、国防领域都有广泛的应用。OMG（Object Management Group）成立于1989年，是一个开放性的非营利性的计算机行业标准联盟。OMG多年来致力于为工业分布式系统提供可互操作的，可移植的，可复用的软件标准。它的成员包括IT行业的设备供应商，终端用户，政府部门，以及学术组织等。很多我们熟知的标准都来自OMG，比如UML（Unified Modeling Language），CORBA（Common Object Request Broker Architecture）等。

在去年关于SOME/IP的文章中我们曾简单解释过中间件的概念，即在分布式系统中，中间件是位于操作系统和用户应用程序之间的软件层，它将操作系统提供的资源进行抽象和封装，为应用程序提供各种各样的高级的服务和功能，比如通信或数据共享。中间件的存在简化了应用程序开发者的工作，这使他们能够将注意力放在应用程序本身上，而不必在不同应用程序之间或不同系统之间的数据传输上花太多精力。

DDS最重要的特性是以数据为中心，这是与其他很多通信中间件不同的地方。DDS的数据共享以Topic为单元，应用程序能够通过Topic判断其所包含的数据类型，而不必依赖其他的上下文信息。同时，DDS能够按照用户定义的方式自动地进行存储、发布或订阅数据，使应用程序能够像访问本地数据一样去写入或者读取数据。

DDS实现的数据共享可以理解成一个抽象的“全局数据空间”，任何应用程序，不论开发语言，或者运行的操作系统类型，都可以通过相同的方式访问这个“全局数据空间”，就好像访问本地的存储空间一样。当然“全局数据空间”仅仅是一个抽象的概念，在实现时仍然是分别存储在每个应用程序的本地空间当中。在系统运行时，数据是按需传输或存储的，数据的发布者仅仅发送对方需要的数据，而订阅者仅接收并存储本地应用程序当前需要的数据。

DDS还提供了非常灵活的QoS（Quality of Service）策略，以满足用户对数据共享方式的不同需求，比如可靠性，故障处理等等。针对数据安全性要求比较高的系统，DDS还提供了细颗粒度的数据安全控制，包括应用程序身份认证，权限控制，数据加密等等。

类似于SOME/IP-SD，DDS提供了对数据发布者和订阅者的动态发现机制，这意味着用户不必去配置通信节点的地址或其他属性信息，因为他们在运行的过程中会自动发现对方，并自动完成相关配置，即实现了“即插即用“。

DCPS模型

DCPS（Data-Centric Publish-Subscribe）是DDS标准中定义的以数据为中心的订阅-发布模型。在这个模型中，向“全局数据空间“写入数据的一方称为Publishers和DataWriter，同样地，在”全局数据空间“中读取数据的一方称为Subscriber和DataReader，下图中展示了它们之间的逻辑关系。除了DCPS模型，DDS标准中还定义了一套完整的应用程序接口（API），该接口标准是与平台无关的，这意味着不论应用程序使用什么开发语言，或运行在什么平台之上，只要DDS中间件的实现符合DDS标准，那么相关的应用程序即可实现不同平台间的移植。

Figure 1 DCPS模型

数据的发送过程，简单来说就是应用程序调用DataWriter对象提供的write方法，把数据传递给Publisher对象，而Publisher负责将数据在网络上发送出去。

数据的接收过程，简单来说就是Subscriber负责从网络上接收数据，并把它存储在对应的DataReader中。应用程序可以为对应的DataReader注册一个回调函数，或者使用DataReader提供的read和take方法来轮询DataReader中的数据。

具体来说，DataWriter在逻辑上从属于Publisher，并受Publisher管理。一个DataWriter只能从属一个Publisher，而Publisher可以拥有多个DataWriter。每一个DataWriter都绑定一个Topic，所以同一个应用程序中可能存在多个DataWriter和Topic，此外还可以为同一个Topic绑定多个DataWriter。

同理，DataReader在逻辑上从属于Subscriber，并受Subscriber管理。一个DataReader只能从属一个Subscriber，而Subscriber可以拥有多个DataReader。每一个DataReader都绑定一个Topic，所以同一个应用程序中可能存在多个DataReader和Topic，此外还可以为同一个Topic绑定多个DataWriter。

这个DSCP模型的工作过程实际上很像日常生活中报纸的发行过程。我们以《人民日报》为例，其中Topic就是“人民日报“，数据即报纸中的文字或者图片，DDS中间件负责报纸发行的所有中间环节和渠道，包括报纸的印刷，存储，运输等等。

QoS策略

用户可以通过设置QoS策略来控制数据在应用程序之间共享的方式，每个DCPS实体，包括Topic，DataWriter，Publisher，DataReader，Subscriber等，都能够独立配置相应的QoS策略。

下面是几种常用的QoS策略：

DEADLINE

如果希望某个Topic能够周期更新，可以设置DEADLINE属性。在数据的发布方设置DEADLINE，这意味着应用程序必须以小于DEADLINE的周期去更新Topic；而在数据的订阅方设置DEADLINE，这意味着数据的发布方必须以小于DEADLINE的周期去发布Topic。

LIFESPAN

通过设置LIFESPAN，可以使DataWriter写入的每个数据样本都有一个关联的“到期时间”，超过该时间后，该数据样本不再传送给任何应用程序，并且这些数据将从DataReader缓存中清除。

HISTORY

设置HISTORY属性可以让DataWriter保存并发送旧的采样数据，新的DDS节点如果订阅了相关的Topic，它不仅能够接收到数据的当前值，也能收到一部分历史值，从而了解数据近期的变化趋势

RELIABILITY

为DataWriter设置RELIABILITY属性，可以使数据实现“可靠”的传输，当出现通信错误导致数据采样没有被接收到时，DataWriter会持续重传，直到所有数据被正确接收。

RTPS协议

DDS的标准中并不包含传输层协议，所以不同的DDS实现可能使用不同的消息交互方式，甚至使用不同的传输协议，这就可能导致来自不同厂家的DDS实现是不能互操作的。而随着DDS在大型分布式系统中的应用越来越广泛，制定统一传输层标准的需求越来越强烈。

RTPS（Real-Time Publish Subscribe）就是在此背景下诞生，它主要为了满足工业自动化领域大规模分布式系统的需求，也能够很好的契合DDS协议特点。规范中定义了消息格式，各种使用场景下的消息交互方式等。它的主要特点包括：

• 提供容错机制，避免单点故障
• 高扩展性，支持“即插即用”
• 模块化设计，针对计算能力较弱的平台，可只实现RTPS的一个子集功能，并且不会出现兼容性问题

Figure 2 RTPS 示例

RTPS基于多播、无连接的传输模型，这个模型可以映射到不同的传输协议上，如UDP/IP（这也是目前RTPS标准中唯一被标准化的传输协议）。除此之外，基于TCP的传输，以及基于TSN（Time-Sensitive Networks）的传输的相关标准也在制定中。很多DDS的实现支持除UDP/IP之外的多种传输协议，但并没有遵循统一的标准，因此不同供应商的DDS实现之间可能存在互操作问题。

DDS与SOME/IP

DDS与SOME/IP存在诸多不同，但是需要强调的是，二者的设计需求不同，目标应用场景不同，所以我们不能简单的判定孰优孰劣。在选取技术方案时，应考虑具体的应用场景，结合各个方案的功能，性能，成本等多个维度，才能做出合理的选择。我们可以从以下几个方面进行对比，为读者提供参考。

通信模式

SOME/IP是面向服务的通信，服务端将方法和数据以服务的形式暴露给其他节点。而DDS最大的特点是以数据为中心，侧重数据的分发，这种模式其实很像传统的面向信号的通信，只不过DDS更灵活，功能更强大。

应用程序接口

SOME/IP协议标准中没有定义标准API，所以基于不同SOME/IP实现的应用程序一般是不能互相移植的。DDS制定了多种编程语言的标准API，因此DDS应用程序理论上能够在不同的DDS实现上进行移植。

传输协议

SOME/IP支持UDP和TCP，此外，从AUTOSAR 4.3开始支持对大于1400字节的UDP数据进行分段传输，即SOME/IP-TP。DDS则使用前面提到的RTPS协议，至少支持UDP/IP，而很多DDS实现还支持其他传输协议，如TCP。 RTPS实现了与传输无关的可靠性和分段协议，理论上可在任何传输形式之上运行。

安全性

SOME/IP本身并不提供数据安全的控制，所以它的安全性依赖于传输协议，比如基于IPsec或TLS上运行。DDS当然也可以在IPsec或TLS上运行，但这并不是首选的方式。DDS提供多种插件，实现了对安全性的更细粒度的控制，比如数据的加密传输，读写权限控制，应用程序身份认证等，并且DDS安全机制与传输协议无关，因此使用任何传输协议都不影响安全机制的实现。

QoS支持

DDS提供多种QoS策略，而SOME/IP本身不提供QoS的支持，因此只能在传输协议或者应用程序中实现。

资源需求

DDS在诸多方面提供了更丰富的特性，这自然就导致了在资源需求上，比如内存占用，比SOME/IP要大得多。

AUTOSAR平台支持

AUTOSAR Adaptive平台从2018年起开始支持对DDS的绑定，Classic平台目前还并没有支持DDS绑定的规划。而SOME/IP是针对汽车应用定制的，可以无缝部署在AUTOSAR Adaptive和Classic平台中。

DDS测试

OMG组织并不提供DDS软件实现，各厂商可以根据该标准实现自己的DDS。我们可以在DDS官网（https://www.omg.org/dds-directory/）查询DDS的供应商列表，用户可以按照自己的具体需求进行选择。这种由第三方供应商提供的预构建软件，一般称为商业现货软件（COTS）。对于COTS软件，我们在测试策略的选择上与自行开发的软件是不同的。一般来说，COTS软件往往是经过市场和时间验证的产品，其核心部分是比较稳定的，并且已由供应商进行了单元和功能测试。因此我们可以减少对COTS软件本身功能的重新测试，应该更侧重在系统集成测试或性能测试等测试类型上。

下面为大家展示了一个简单的DDS硬件在环（HiL）测试环境。

Figure 3 DDS 测试环境示例

为了保证ECU的正常运行环境，并监测或触发ECU的某些行为，我们需要仿真ECU的外围IO信号或者总线信号，这时我们可以借助Vector提供的丰富的IO激励和测量板卡，如VT系统，以及总线接口卡，如VN系列硬件等工具。在测试环境中，我们还需要仿真DDS Writer或者Reader，来发布或订阅ECU的DDS数据，以此来验证被测节点的变量范围，非法值的错误处理机制等。由于CANoe暂不支持DDS节点的仿真功能，我们可以使用开源或者DDS厂商提供的库，如pydds，RTI Connector等，来快速搭建DDS应用程序，并在CANoe中编写接口来控制仿真节点。

Figure 4 使用vTESTstudio进行测试用例的设计和管理

测试用例方面，可使用vTESTstudio进行测试用例的设计和管理。vTESTstudio不但提供了图形化和图表化的测试用例设计方式，而且提供多种基于测试参数自动生成测试用例的功能，并支持模糊测试，能够极大的提高测试用例的开发效率和测试覆盖度。

Figure 5 测试报告展示

总结

自从汽车在十九世纪末被发明以来，技术的创新就从未停止过。汽车作为一种消费产品，已经从最初的交通工具变成了一种生活方式，正如今天的智能手机不再仅仅是一个打电话的工具而已。通过持续的技术创新和融合，汽车变得更安全，更人性化，更智能，更互联。DDS的引入，无疑是在汽车和互联世界之间打开的另一扇大门。至于DDS能否在汽车行业内得到更广泛的应用，还需要更全面和更细致的评估，但我们期待DDS以其丰富的特性和功能，能够为汽车应用领域带来更多可能性，帮助应对汽车智能化和互联化道路上的更多挑战。

北汇信息专注汽车电子测试，拥有多年的项目实践经验，提供一站式的测试解决方案。本篇文章简单介绍了DDS中间件技术以及测试方案，但由于篇幅有限，未能将更多内容展现给大家，期待感兴趣的读者能联系到我们，进行更进一步的交流。

参考文献：
[1] Data Distribution Service (DDS) Version 1.4
[2] DDS Security Version 1.1
[3] The Real-time Publish-Subscribe Protocol DDS Interoperability Wire Protocol (DDSI-RTPSTM) Specification Version 2.3