DDS(Date-Distribution Service)协议解读和测试解决方案

1.DDS运行背景以及概述

通信的本质

• 在正确额时间内把正确的数据送达正确的地点
  （1）数据在哪里？
  （2）数据发送端什么时候能提供数据？
  （3）数据接收端什么时候需要数据？
  （4）如果有新节点加入或者节点离开如何处理？
  （5）节点故障或者网络故障如何处理？
  （6）启动时间满足要求吗？
  （7）出现网络拥塞怎么办？

分布式系统通信模型

• 客户端-服务器模型（Client-Server）
  （1）服务器把算法和数据封装成标准接口，客户端通过请求-相应机制来调用接口RPC
  （2）适用于数据集中且数据流向明确的系统，比如文件服务器系统，右键系统
  

• 发布-订阅模型（Publish-SubScribe）
  （1）节点订阅他们感兴趣的数据，发布他们生产的数据
  （2）需支持动态发现机制
  （3）适用于大量的实时数据分发
  

DDS概念

• 是OMG在2004年发布的中间件协议和应用程序接口（API）标准，定义了一个基于发布-订阅模型的以数据为中心的互联框架，它为分布式系统提供了低延迟，高可靠性，高扩展的通信架构标准，目前在工业、医疗、交通、能源、国防领域都有广泛的应用
• 核心标准
  （1）DDS Specificsation：API标准-保证不同DDS实现的应用程序的可移植性
  （2）DDSI-RTPS Specification：协议标准-保证不用DDS实现的互操作性
  

Global Data Space（GDS）

• 全分布式结构，无注册机，不存在单点故障（Single point of failure）和性能瓶颈
• 由GDS动态发现系统中的Publisher，Subscriber，数据以及其类型
  

Domain & Domain Participant

• 在DDS应用程序中，GDS称为Domain
• Domain是一组DDS应用程序的逻辑分组，不同Domain只的实体互相独立，不能相互访问
• 通过Domain ID来识别一个唯一的Domain
• 应用程序通过指定Domain ID创建Domain Participant(DP)来获取相应Domain的访问权限
  Application B和Application C属于不同的Domain，不能直接进行通信，若要通信需要经过Application A；
  Application A既属于Domain 1，也属于Domain 2，所以Application A既可以与Application B通信，也可以与Application C 通信；
  

Topic

• DDS的数据发布的最小单位是Topic
• Topic三要素
  （1）数据类型
  仅支持OMG Interface Definition Launguage(IDL)定义的数据类型；
  支持基本数据结构(eg:short,long,float,string)，以及array,sequence,union,enumeration，支持结构体嵌套；
  与定义C结构体的语法基本相同；
  （2）Topic名称
  由用户自己定义，如果要建立通信，pub和sub需要相同的名字
  （3）一组QoS策略
  上述三者一样，pub和sub才可以建立通信
• 同一个Topic可以存在多个实例，通过Key来进行区分，eg：#pragma中的id
• Topic定义完成后，通过预处理器将IDL文件生成类型库，应用程序可以通过DDS API将这些类型实例化
  tutorial::TempSensorType由IDL工具自动生成
  

通信形式

• DCPS模型（Data-Centric Publish-Subscribe）
• DDS的数据共享以Topic为单元，应用程序能够通过Topic判断其所包含的数据类型，而不必依赖其他的上下文信息
• 同时，DDS能够按照用户定义的方式自动地进行存储、发布或订阅数据，使应用程序能够像访问本地数据一样去写入或者读取数据
  
• eg：
  
  
  

服务质量QoS

• 用户可以通过设置QoS策略来控制数据在应用程序之间共享地方式，如：可靠性、周期性等，以满足不同场景下应用程序对功能和性能需求
• QoS特性的支持使DDS非常适用于数据类型丰富，且功能&性能需求多样的场景
• QoS Policy
  T：Topic，DR：Data Reader，DW：Data Writer，P：Pub，S：Sub
  
  

QoS分类

• （1）Data availability数据可用性
  DDS提供以下QoS策略以实现数据可用性控制：

DURABILITY
VOLATILE：数据仅提供给现有的订阅者，后加入的Subscribe无法获得数据，这是DDS的默认行为
TRANSIENT_LOCAL: Publisher在本地保存数据，后加入的Subscribe能够获得数据
TRANSIENT： GDS保存数据，后加入的Subscribe能够获得数据
PERSISTENT：GDS永久保存数据，后加入的Subscribe能够获得数据，即使整个系统发送了重启

LIFESPAN：Data sample的有效时间，默认为永久

HISTORY：保存data sample历史记录的个数，可以选择仅保存最新的sample，或最近的N个sample或者全部sample

• （2）Date delivery数据交付
  DDS提供以下QoS策略来控制数据的交付方式

PRESENTATION
Coherent Access
在一组DDS data sample的更新都到达接收端后，应用程序才能访问这一组data sample，使用于不同数据实例之间存在关联关系的场景，eg：坐标数据

Ordered Access
保留Data sample之间的顺序

RELIABILITY可靠性
RELIABLE：可靠送达
BEST_EFFORT:尽力送达

PARTITION：允许在同一个Domain下创建逻辑分区，处于同一分区内的DataWriter和DataReader才可以建立通信

DESTINATION_ORDER
当系统中存在针对同一个数据实例的多个DataRead才可以建立通信

DESTINATION_ORDER
当系统中存在针对同一个数据实例的多分DataReaders时，接收端如何访问数据
BY_RECEPTIONS_TIMESTAMP:以接收端最后收到的数据为准
BY_SOURCE_TIMESTAMP:以发送端最后发送的数据为准

OWNERSHIP
当系统中存在针对同一个数据实例的多个DataWriter时，可以通过设置每个DataWriter的强度来控制DataWriter的写入权限
强度最高的DataWriter拥有写入权限

• （3）Date timeliness
  DDS提供以下的QoS策略来控制分布式数据的时效性

DEADLINE
用于约束数据的发送周期
对发送端来说，设置DEADLINE意味着应用程序必须在给定的时间周期内写入数据，对接收端来说，设置DEADLINE是对数据的时效性的最小要求

LATENCY_BUDGET
可设定该参数来约束数据的传输时间（从数据写入到数据送达接收端的缓存内的时间）
DDS传给传输层

TRANSPORT_PRIORITY
控制传输数据的优先级，由一个整数表示，值越大优先级越高
DDS传给传输层

• （4）Resources
  DDS定义了以下QoS策略来控制满足数据分发要求所必须的网络和计算资源

TIME_BASED_FILTER
设置该参数意味着在指定时间周期内，只期望收到一个date sample，过多的date sample将被DataReader丢弃
该参数有助于优化网络负载以及节点的计算资源

RESOURCE_LIMITS
用于限制DDS可以分配的系统内存

• （5）Configuration
  DDS支持通过以下QoS策略来定义和分发用户信息：
  由用户定义

USER_DATA
允许应用程序将一个字节序列于DomainParticipant、DataReader或者DataWriter进行关联，该字节序通过内建的Topic进行分发
常用于分发安全凭证，应用程序可通过此凭证验证数据的有效性

TOPIC_DATA
允许应用程序将一个字节序列于Topic相关联，该字节序列通过内建Topic进行分发
常用于为Topic添加附加信息

GROUP_DATA
允许应用程序将一个字节序列于Publisher或者Subscriber相互关联，该字节序列通过内建Topic进行分发

DDS于SOME/IP区别

• 以数据为中心就是发布订阅，以面向服务为中心就是client-server
• API标准化意味着可以移植
  

DDS over TSN

• OMG DDS-TSN仍处于早期阶段
• 如何将DDS QoS策略映射到TSN？
  

2.DDS实现方案

协议栈实现

• 第三方供应商提供，eg：RTI
• 自行开发

应用实现

• 系统供应商开发
• OEM自行开发
  

3.DDS测试范围

通信矩阵一致性测试

• 验证DDS应用实现于通信矩阵的一致性
• eg：Topic完整性，数据结构一致性，数据范围一致性，QoS配置一致性等
  DDS的数据库就是IDL

容错性及鲁棒性测试

• 故障处理或故障恢复测试
• eg：数据结构错误，数据元素值错误，QoS配置不兼容，通信链路故障，电源故障

DDS应用功能测试

• 基于用户的应用场景需求
• eg：系统端到端相应时间

小结

• 暂无针对DDS中间件本身的一致性测试的行业标准

4.DDS测试解决方案

测试环境

• 测试开发环境
  Vectro vTESTstudio + CANoe CAPL
  第三方编程语言

• 测试执行环境
  Vector CANoe option Ethernet

• 被测设备运行环境仿真
  Vector VN56xx 以太网通信接口硬件
  Vector VT系统的各个IO办卡
  电源
  

CANoe于DDS应用的交互：

• 方案1
  

• 方案2
  FDX是VECTOR基于TCP，UDP实现的，目前可以用于控制一个DDS node
  

• 方案3
  

• 参考：【北汇信息】汽车电子热题 | DDS协议解读及测试开发实践-CSDN直播回放，DDS协议解读及测试开发实践