车载通信架构 —— DDS协议介绍

车载通信架构 —— DDS协议介绍

我是穿拖鞋的汉子，魔都中坚持长期主义的汽车电子工程师。

老规矩，分享一段喜欢的文字，避免自己成为高知识低文化的工程师：

屏蔽力是信息过载时代一个人的特殊竞争力，任何消耗你的人和事，多看一眼都是你的不对。非必要不费力证明自己，无利益不试图说服别人，是精神上的节能减排。

本文主要

-> 1、标准及发展简介

-> 2、概念介绍

-> 3、应用场景及价值意义

一、标准及发展简介

DDS 的全称为 Data Distribution Service（数据分发服务 )，是由OMG联盟在2004年发布的中间件协议和应用程序接口标准。采用发布 / 订阅模型，提供丰富的 QoS（Quality of Service）服务质量策略，可满足各种分布式系统实时通信的低延迟、高可靠性、可扩展性的需求。DDS 被广泛应用在航空航天、船舶、军事、工业、医疗、交通、能源等领域中。

在分布式系统中，DDS 中间件是处于操作系统和用户应用程序之间的软件层，如图 4.5-12 所示。它将应用程序从操作系统，网络传输和低级数据格式的详细信息中抽象出来，以接口定义语言模式提供了支持多种编程语言 API，从而使应用在不同的操作系统、编程语言和处理器体系架构之间交换信息。DDS中间件管理了数据格式、发现、连接、可靠性、协议、传输选择、QoS、安全性等底层细节。

随着SOA在汽车领域的发展和运用，面向服务的通信中间件SOME/IP标准协议被引入到基础软件架构标准中。随着基础软件软硬解耦、软软解耦的发展，应用和服务之间除了服务能力的提供，还出现数据共享的需求。DDS正是以数据为中心的通信中间件，用Topic为单元实现数据的共享，按照用户定义的方式存储、发布和订阅数据，支持运行在不同系统上，不同开发语言的应用可以分布式的互相收发数据。

二、概念介绍

DDS 在软件框架中的模型如下图所示。DDS 通信的要素包括：

->（Domain）代表一个通信平面，由Domain ID唯一标识，只有在同一个域内的通信实体才可以通信；如果考虑车内通信，可以只划分1个Domain，也可以按照交互规则或其他规则，定义多个Domain；

-> 域参与者（Domain Participant）代表域内通信的应用程序的本地成员身份，简单来说，就是说明同一数据域内的通信成员;

-> 主题（Topic）是数据的抽象概念，由TopicName标识，关联相应数据的数据类型(DataType)，如果把车内所涉及的所有Topic集合在一起，这样就形成一个虚拟的全局数据空间“Global Data Space”，进一步弱化了节点的概念，所以域参与者已经不是节点的概念了;

-> 发布者（Publisher）发布者，发布主题数据，至少与1个DataWriter关联，通过调用DataWriter的相关函数将数据发出去;

-> 订阅者（Subscriber）订阅者，订阅主题数据，至少与1个DataReader关联。当数据到达时，应用程序可能忙于执行其他操作或应用程序只是等待该消息时，这样就会存在两种情况，同步访问和异步通知;

-> 数据写入者（Data Writer）数据写入者，类似缓存，把需要发布的主题数据从应用层写入到DataWriter中；;

-> 数据读取者（Data Reader）数据读取者，同样可以理解为一种缓存，从订阅者得到主题数据，随之传给应用层。

详细内容可参见如下示意图：

DDS软件框架模型

DDS软件框架模型

DCPS（Data-Centric Publish-Subscribe ）模型中的4个基础的概念：

-> 1、Publisher：它是负责创建和配置其实现的 DataWriters 的 DCPS 实体。 DataWriter 是负责实际发布消息的实体。每个 DataWriter 都有一个分配的 Topic，在该 Topic 下发布消息。

-> 2、Subscriber：它负责接收在其订阅的 Topic 下发布的数据。它为一个或多个 DataReader 对象提供服务，这些对象负责将新数据的可用性传达给应用程序。

-> 3、Topic：它是绑定发布和订阅的实体，在 DDS 域中是唯一的。通过 TopicDescription，它允许发布和订阅数据类型的统一。

-> 4、Domain：它用于链接所有发布者和订阅者，属于一个或多个应用程序，它们在不同主题下交换数据。这些参与域的单个应用程序称为 DomainParticipant，DDS域由Domain ID 标识。DomainParticipant通过定义Domain ID 以指定它所属的DDS域。具有不同Domain ID 的两个 DomainParticipants不知道彼此在网络中的存在。因此，可以创建多个通信通道。这适用于涉及多个DDS应用程序的场景，它们各自的 DomainParticipants相互通信，但这些应用程序不得干扰。DomainParticipant 充当其他 DCPS 实体的容器，充当发布者、订阅者和主题实体的工厂，并在域中提供管理服务。

三、应用场景及价值意义

作为AP中中间件协议的常用协议，DDS还广泛应用于如下地方：

-> 军事&航空航天

NASA Launch Control System，NASA 发射控制系统，DDS用于超过40万个控制点 , 能够智能地分发来自数千个传感器的数据，并允许在控制室进行数据的存储和查看。

另外，Next Generation Navy System基于DDS标准的、高性能的中间件促进系统更好地实现互操作性，并作为未来架构设计的基础。

-> 智能能源

Large Scale Fusion Reactor System,该系统是DDS用于聚变能源中心的远程控制系统的数据监控和采集。SIEMENS WIND POWER也使用DDS可用于控制多个分布式的风力涡轮机，通过数据的交互和采集提高发电效率。

-> 医疗设备&健康卫生系统

用于集成医院的医药诊断系统。DDS将设备、服务连接在一起，以支持实时的显示。DDS 可用于支持需要高效控制大规模数据流传输的系统，如CT成像系统等。

-> 仿真&测试系统

飞行员训练模拟器。CAE用DDS进行高效的数据分发，并作为下一代飞行模拟器的架构.

-> 汽车领域(敲重点)

用于 Hardware-in-the-loop（HIL）仿真，Audi使用DDS中间件实现测试系统中数百个设备的数据的实时交互。

DDS用于大众智能车的驾驶辅助及综合安全系统，用于结合来自雷达、激光测距仪和视频的数据，来协助安全操作，比如能够检测驾驶员的睡意，还能够检测车道偏离等。

Baidu Apollo系统中集成了DDS。

AUTOSAR 的AP平台在 R18-03 版本开始支持DDS，CP平台也已经开始规划支持DDS。

部分自动驾驶的SoC芯片预留了DDS接口，ROS2、Cyber RT 等操作系统也集成了开源DDS。

而对于面向服务的通信协议，DDS与SOME/IP各自的优劣？DDS能否替换SOME/IP等问题不在本文讨论。

搁笔分享完毕！

愿你我相信时间的力量

做一个长期主义者！