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

DDS协议解读及测试开发实践  在去年??SOME/IP概述及TC8-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能够周期更新，可以设置DEADLIN