图1DCPS模型

数据传输过程只是应用程序调用DataWriter对象提供的Write方法,将数据转移到 Publisher对象,而 Publisher负责通过网络发送数据。

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

具体来说，DataWriter逻辑上属于出版商,它由出版商管理。一个DataWriter只能从属一个Publisher，而Publisher可以拥有多个DataWriter。每个DataWriter绑定一个主题,因此在同一应用程序中可能有多个数据编写器和主题,此外还可以为同一个Topic绑定多个DataWriter。

同理，DataReader在逻辑上从属于Subscriber，它由用户管理。一个DataReader只能从属一个Subscriber，而Subscriber可以拥有多个DataReader。每一个DataReader都绑定一个Topic，因此在同一应用程序中可能有多个数据阅读器和主题,此外还可以为同一个Topic绑定多个DataWriter。

DSCP模型的工作过程实际上非常类似于每日报纸的出版过程。比如《人民日报》。主题是《人民日报》。数据,即报纸上的文字或图片,DDS中介人负责所有中介人和报纸发行渠道,包括报纸的印刷，存储，运输等等。

QoS策略

用户可以通过设置QoS策略来控制数据共享的方式。每个DCPS实体，包括Topic，DataWriter，Publisher，DataReader，订阅者等。他们可以独立配置QoS策略。

以下是一些常见的 QoS策略:

l DEADLINE

如果您希望一个主题定期更新,您可以设置“死亡”属性。在数据出版商中设置“死亡线”,这意味着应用程序必须以小于DEADLINE的周期去更新Topic；而在数据的订阅方设置DEADLINE，这意味着数据的发布者必须在周期较短的 DEADLINE周期上发布主题。

l LIFESPAN

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

l HISTORY

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

l RELIABILITY

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

RTPS协议

DDS标准不包括层协议,所以不同的DDS实现可能使用不同的消息交互方法,甚至使用不同的传输协议,这可能导致不同制造商的DDS实现无法相互操作。由于DDS在大型分布式系统中日益广泛应用,统一的传输层标准的需求日益强烈.

RTPS(Real-Time Publish Subscribe)在这一背景下诞生,主要以满足工业自动化领域大规模分布式系统的需求,它也很好地符合DDS协议特性.消息格式在规范中定义,各种方式与场景下的讯息交互,等等。它的主要特点包括：

l提供一个容错机制以避免单点故障

l高可扩展性,支持即时插件

l为较弱的计算能力的平台设计的模块化设计,只可实现RTPS的子集函数,并无兼容问题

图2RTPS实例

RTPS基于多播、不连接的传输模式,这个模型可以映射到不同的传输协议中,例如,UDP/IP(目前的RTPS标准中唯一标准化的传输协议)。除此之外，基于TCP的传输，同时,正在制定基于TSN(Time-Sensitive Networks)的传输相关标准。许多DDS实现支持多个传输协议,除了UDP/IP,但他们不遵循统一的标准,因此,在不同供应商的DDS实现之间可能存在互操作性问题。

DDS和SOME/IP

DDS和SOME/IP存在诸多不同，但是需要强调的是，两者的设计要求都不同,目标应用场景不同，所以我们不能仅仅判断它是否好或坏。在选取技术方案时，应考虑具体应用方案,结合各方案的功能,性能，成本等多个维度，作出合理的选择。我们可以从下列方面进行比较:为读者提供参考。

l 通信模式

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

l 应用程序接口

SOME/IP协议标准中没有定义的标准API,因此,基于不同的SOME/IP实现的应用程序通常互不移植。DDS已经为许多编程语言开发了一个标准API,因此, DDS 应用程序可以从理论上移植到不同的 DDS 实现。

l 传输协议

SOME/IP支持UDP和TCP,此外，从 AutoSAR 4.3开始支持超过1400字节的UDP数据的次传输,SOME/IP-TP。DDS使用上述RTPS协议,至少支持UDP/IP,许多DDS实现也支持其他传输协议,如TCP。RTPS实现无关联的可靠性和分割协议,理论上,它可以在任何形式的传输上运行。

l 安全性

SOME/IP本身不提供数据安全控制,因此它的安全性取决于传输协议,例如,它运行在IPsec或TLS上。DDS当然可以在IPsec或TLS上运行,但这不是第一道。DDS提供多种插件,实现了更精细的安全性控制.例如,加密数据传输,读写权限控制，应用程序认证等。DDS的安全机制与传输协议无关,因此使用任何传输协议都不影响安全机制的实现。

l QoS支持

DDS提供了多个 QoS策略,而SOME/IP本身并不提供 QoS支持,因此它只能在传输协议或应用程序中实现。

l 资源需求

在很多方面,DDS提供了更丰富的特性,这自然导致资源需求,例如存储器的使用,比SOME/IP要大得多。

l AUTOSAR平台支持

AUTOSAR Adaptive平台自2018年起支持DDS绑定。Classic平台目前不支持DDS绑定。SOME/IP适用于汽车应用,可以无缝部署在AUTOSAR Adaptive和Classic平台中。

DDS测试

OMG不提供DDS软件实现,制造商可以根据这个标准实现自己的DDS.我们可以在DDS网站(https://ww.omg.org/dds-directory/)查询DDS供应商名单,用户可以根据自己的具体需要作出选择。这是第三方供应商提供的预建软件,它通常被称为商业销售软件(COTS)。对于COTS软件，我们对测试策略的选择与我们自己开发的软件不同。一般来说，COTS软件通常是一个已经上市并经过时间验证的产品,它的核心相对稳定,设备和功能也由供应商测试.这样我们可以减少COTS软件本身的重新测试,应更多地注意测试类型,例如系统集成测试或性能测试。

这里是一个简单的DDS硬件测试环境在循环(HIL)。

为了确保ECU的正常运行环境,监视或触发ECU的某些行为,我们需要模拟ECU的外部IO信号或总线信号,在此阶段,我们可以利用Vector提供的丰富的IO刺激和测量板卡,如VT系统，以及总线接口卡，工具如VN系列硬件。在测试环境中，我们还需要模拟DDS编剧或阅读器,发布或订阅ECU的DDS数据,为了验证测量节点的变量范围,非法价值误差处理机制等。由于CANoe不支持DDS节点的仿真函数,我们可以利用开放源代码或DDS供应商提供的图书馆,如pydds，RTI连接器等,快速建立DDS应用程序,在CANoe中, 接口编写为控制仿真节点.

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

测试用例方面，您可以使用vTESTstudio来设计和管理测试实例。vTESTstudio不仅提供图形和图形测试实例设计方法,它还为基于测试参数的自动生成测试实例提供了多种功能,并支持模糊测试，它可以大大提高测试实例的开发效率和测试覆盖率.

图5测试报告显示

总结

自19世纪末汽车发明以来,技术创新从未停止。作为消费品,汽车,从原来的交通工具转变为一种生活方式,正如今天的智能手机不再是电话工具。通过持续的技术创新和一体化,汽车变得更安全，更人性化，更智能，更互联。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