【经纬恒润】让DDS运转起来——DDS系统设计（上）

文章来源：https://blog.csdn.net/Hirain1234/article/details/137451298

▎什么是DDS

DDS（Data Distribution Service，数据分发服务）是由OMG（Object Management Group，对象管理组织）进行标准化的通信中间件，采用以数据为中心的发布订阅模式。该标准在工业物联网、航空航天等领域广泛应用。

随着汽车电子电气架构的发展及车辆功能的增加，控制器间交互的数据量也逐渐增多，对于通讯过程中的各种服务质量问题也越来越受到各主机厂商的重视。作为提供了多样化QoS特性的DDS协议便很好的满足了这一需求，DDS在车载领域的优势逐渐凸显，本文主要介绍将DDS协议应用至车载领域时，要开展的DDS系统设计。

▎什么是DDS系统设计？

DDS系统设计的目的是让DDS服务于车辆功能。需要依赖前期已经完成的UC（Use Case）描述、功能规范、车辆拓扑等作为输入，利用DDS协议机制及特点，满足相关功能需求，最终设计产物主要有：

• DDS通信矩阵
• DDS数据库文件

开发工程师需要根据通信系统设计产物，完成后续DDS相关功能的软件开发和适配，测试工程师也需要以设计输出入为基础，开展DDS相关协议测试验证工作。

▎什么是DDS系统设计？

DDS系统设计围绕DDS相关的核心概念开展，目的是明确如何利用DDS协议及其机制，满足整车功能和安全需求。具体来讲，DDS系统设计主要涉及以下几方面：

• Topic的设计：明确系统中DDS Topic的定义及数量
• Datatype的设计：为每个Topic指定数据类型
• QoS的设计：为所有通信实体配置QoS策略
• 通信实体的设计：明确所有通信实体的部署及关联
• 通信参数的设计：明确影响系统通信行为的通信参数

设计Topic

Topic是DDS系统内各节点进行交互的桥梁，基于各节点间需要传输的数据描述，在进行Topic设计时应考虑以下因素：

• Topic颗粒度：从可复用性和资源消耗的角度合理控制Topic的颗粒度和数量
• Topic类型：根据通信需求选择合适的Topic类型
• Topic名称：需要结合实际情况考虑是否对Topic命名规则有限制（如遵循OMG DDS-RPC规范命名）

如下图所示，将整车“感知功能相关”的信号安装传感器类别进行分类，划分出了如下几个Topic：LidarPointCloudTopic表征激光雷达的点云数据、CameraFreeSpace表征摄像头的FreeSpace信息、MapInfoTopic表征高精地图信息，VisionObjectTopic则表征融合程序对各类传感器的融合结果。

设计Datatype

DDS Topic绑定唯一固定的数据类型，针对Topic数据类型的设计也是DDS系统设计要完成的一部分内容。

• Type：根据信号描述为每个信号明确数据类，需为DDS-XTypes规范定义支持的数据类型
• Type Description：数据类型描述，针对数据类型明确该类型的详细描述，如Enumeration数据类型的每个value及其对应的name
• Type Attributes：数据属性，如其Extensibility，Optional等

设计QoS

丰富的QoS特性是DDS保证通信服务质量的重要手段，因此需要根据实际功能需求设计DDS系统的参数配置。需要为DDS所有角色设计其QoS。

• 参数配置：充分梳理功能描述和相关规范，识别DDS的QoS机制是否可满足相关需求，同时明确其配置参数，从而进一步简化功能应用的处理逻辑，使其专注于处理业务流程。例如通过对LIFESPAN的设计满足对数据新鲜度的传输需求。
• 落地实现：在进行QoS设计时，还应充分考虑其落地可行性。需要调研当前系统采用的协议栈对需要配置的QoS的支持情况，同时需要明确控制器集成的软件平台（如AUTOSAR-CP、AUTOSAR-AP等）、硬件平台（如MCU、MPU等）和DDS
  QoS的适配及限制。

设计通信实体

针对车载环境的特殊性，需要对DDS系统中所有通信实体进行设计和管理。

• Domain设计：为整车系统划分DDS通信域；
• Domain Participant设计：明确每个DDS Domain内的参与者，同时指定相关参与者所部署的ECU控制器；
• Publisher/Subscriber设计：针对每个Domain
  Participant，根据其对数据的交互需求，为其指定Publisher和Subscriber；
• DataWriter/DataReader设计：为Publisher设计其相关的DataWriter，为Subscriber设计其相关的DataReader，同时分别为DataWriter和DataReader关联指定的Topic数据。

需要注意的是，DDS通信实体的数量、各类实体间的部署关系需要同时结合其对资源的消耗和系统可扩展性进行考虑。

通信参数设计

在车载有线网络环境下，DDS协议采用DDSI-RTPS协议进行交互，RTPS协议中定义了完整的DDS SD和数据交互过程。

• 各类ID设计：在符合规范要求的前提下，为各通信实体分配唯一ID；
• 时间参数：明确SPDP、SEDP及数据交互阶段各时间参数；
• Locator信息：需结合整车网络通信设计规则，明确各通信实体的位置信息（传输协议、IP地址和端口号等）。

▎结语

DDS系统设计明确了系统内各ECU基于DDS协议互相通信的具体方式，上述关键元素的设计结果在DDS通信矩阵中进行体现，ECU开发工程师会以通信矩阵为输入完成后续的软件开发和适配，那么这些信息具体是以什么形式进行传递的呢？敬请期待《DDS系统设计（下）》。了解更多：请致电 010-64840808转6115或发邮件至market_dept@hirain.com（联系时请说明来自CSDN平台）

▎参考文档

[Ref.1] https://www.omg.org/omg-dds-portal/
[Ref.2] https://www.omg.org/spec/DDSI-RTPS
[Ref.3] https://www.omg.org/spec/DDS-XTypes/1.3/