DDS的目标是在正确的时间（right time）在正确的位置（right place）共享正确的数据（right data）。2024年3月14日，在2024第五届软件定义汽车论坛暨AUTOSAR中国日上，北京经纬恒润科技股份有限公司研发经理于洪斌介绍，DDS标准可分为以下四个部分——核心标准、 扩展标准、 网关标准、 API标准。同时，他对DDS的发展历程以及AUTOSAR DDS 在HPC上的开发实践进行了讲解。针对HPC项目的开发实践，于洪斌以经纬恒润DDS开发工具链为例进行了分享。
的发展历程及概述DDS，即Data Distribution Service，是由OMG组织提出的新一代分布式实时数据通信中间件协议。DDS的目标是在正确的时间、正确的位置共享正确的数据，具有以下四个特点。
第一，DDS采用以数据为中心的发布订阅机制。数据的发送端需要有相应的publisher来关联对应的datawriter实现数据的发送，而数据的接收端需要有相应的订阅者来关联对应的数据读取者实现数据的接收。只要数据的发送方和接收方的主题和服务质量相匹配，就能够实现数据的交互。
其次，DDS具有丰富的服务质量策略。OMG组织已经提出了22种标准的QoS策略，但在实际应用中，可以根据实际场景进行定制化开发，因此并不局限于这22种策略。第三，DDS具有大规模的可扩展性。DDS中间件可以支持多种编程语言，如C语言、Java等，并且能够兼容多种操作系统，包括Linux系统、安卓系统以及RTOS系统等。因此，它的应用范围从小型单元扩展到大型云端设备，应用范围非常广泛。
DDS还支持动态发现机制。在DDS网络中，当我们向网络添加新节点时，其他节点可以通过动态发现机制自动构建相应的通信关系，因此可以实现真正的即插即用功能。第三点是安全性。像DDS这样的协议已经公布了相应的规范标准，在这些标准中包括身份认证、数据加密以及数据完整性等方面的规范要求。通过遵循这些规范要求，我们可以实现数据的可靠性和安全性传输。
DDS标准主要分为以下四个部分。第一部分是核心标准，包括DDS协议、RTBS协议、Cecired协议以及X-TYPE协议等。第二部分是扩展标准，其中定义了像XML协议、RPZ协议等。第三部分是网关协议标准，主要定义了DDS协议与其他协议之间转换的标准和规范要求。例如，DDS外部协议定义了DDS协议与外部协议之间的协议转换标准规范要求。第四部分是API标准，针对不同的编程语言如C、C++、Java等，规定了实现相应DDS通信中间件功能所需遵循的API接口规范要求。
DDS协议最初由OMG组织于2004年推出1.0版本的协议规范，随着时间的推移，OMG组织不断迭代协议标准，并增加其他协议的规范要求。例如，AUTOSAR联盟组织在2018年基于AP的R18-03协议标准增加了对DDS网络绑定相关的支持。经纬恒润于2023年推出了经纬恒润的AUTOSARDDS的协议站组件。
AUTOSAR的应用领域非常广泛，涉及到航空航天、智能电网、医疗器械等多个领域。在汽车行业中，自动驾驶方向是最为广泛应用的领域之一。这是因为自动驾驶涉及大量数据的传输，包括MCU内部的并行通信、SOC内部的核间通信以及跨芯片的通信。传输内容从简单的信号到流媒体数据，再到二维、三维的感知数据，因此对通信效率和大量数据分发有很高的要求。DDS协议是基于数据的通信方式，同时支持各种QoS策略，因此与自动驾驶方向高度契合，可以通过DDS协议实现相关的数据通信功能。
DDS在HPC上的开发实践AUTOSARDDS在HPC上的开发实践基于L4的项目，主要包括车云交互系统、软驾系统、感知系统和底盘系统等几大系统。正在开发的HPC属于软驾系统，主要实现自动驾驶功能。
目前，HPC是基于TDA4芯片进行开发的，其中包括两个主要的，即HPC1和HPC2。HPC1主要实现激光识别和智驾融合功能，而HPC2则负责视觉识别相关功能。另外，TBOX模块主要用于与云端进行数据交互，并将路径信息下发至相关设备。对于TC397芯片，主要实现智驾控制功能。在早期开发阶段，我们采用了SOMEIP通讯方式进行功能开发，而对于DDS内部通讯则采用了核间通讯方式。在新一代平台上，我们将所有MCU之间的通讯以及MCU内部通讯都切换到了DDS通讯方式。
要实现这种转换，需要进行大量的开发工作，具体包括以下三个部分：首先是DDS系统设计，包括DDS需求规范开发、DDS通信矩阵开发以及DDS XML通信矩阵模板开发。其次是ECU软件的开发，因为早期HPC采用了AUTOSAR标准的CP和AP软件，所以需要对AP和CP软件进行升级，以支持相应的DDS模块。同时，相关的工具链也需要进行迭代，以支持对DDS通信矩阵的解析。最后，完成所有基础软件搭建后，需要与原有的HPC相关应用软件进行整体系统联调，包括数据融合相关软件，这是第二个阶段，也是ECU软件开发的一部分。
DDS的系统设计是针对实际项目需求开发的，其中通信矩阵的设计工作是其中的重要部分。在通信矩阵的设计过程中，主要涉及三个部分，针对DDS常用的属性进行设计开发工作。
首先，我们需要将基于SOA架构开发的服务列表转换成DDS所需的通信矩阵。将服务列表分成两类：一类是基于RPC类型的服务，另一类是非RPC类型的服务。
第二部分是进行与数据相关的设计。在这方面，设计内容相对简单，主要是针对数据类型进行设计，类似于SOMEIP的设计。然而，在DDS相关的XTypes协议标准中，实际上增加了一些数据属性的要求。因此，在通信矩阵的设计中，我们单独增加了一些列表，针对属性进行配置。这些属性包括数据可选性、可扩展性以及可便性的配置。用户可以基于我们的模板，针对相关的数据类型进行单独的属性配置。
第三步是对于Entity设计。这部分的设计内容主要包括DataReader、DataWriter、Publisher、Domain等。所有这些设计完成后，就形成了HPC通信矩阵模板。通信矩阵设计完成后，还需要形成相应的DDS通信矩阵，这样做的目的是为了给下游的软件提供集中开发的基础。我们选用的通信矩阵模板是XML文件格式，可以包含相应的ECU信息，还可以包含AP、CP所使用的所有服务相关的属性信息，包含的信息更加全面。
所有系统设计完成后，接下来就是相关的软件开发工作。软件开发工作主要涉及对相关的CP和AP的供应链进行升级，包括软件模块的开发工作。目前AP和CP的DDS软件模块已经实现了对AP和CP的供应链兼容，并且支持相应通信矩阵的导入配置。这些软件模块能够与AP、CP供应链的其他软件模块进行整体集成、开发和迭代，实现了相应的RTPS协议、DDS协议和X-Types协议相关的内容，并且能够兼容不同操作系统以及相关的硬件平台。
针对软件测试部分，实际上，无论是OMG还是AUTOSAR官方，都没有对一致性测试规范进行一致的定义要求。考虑到整车厂在进行相关DDS网络设计时，不同的Tier1供应商可能使用不同的DDS软件解决方案，可能会使用开源的DDS，也可能会使用商用的RTI的DDS，甚至可能使用我们恒润的DDS。在这种情况下，如何保证相关DDS的兼容性就会涉及到一致性测试的问题。因此，我们基于OMG组织的相关规范要求，开发了相应的一致性测试工具，并将其集成到AETP测试软件中，以进行相关的DDS一致性测试功能。
在HPC的开发设计过程中，我们得出了一些总结和思考，主要有以下三点。首先，DDS协议在实现过程中代码量非常大，其中许多功能在实际应用中可能并不需要。因此，我们认为可以对DDS的协议站进行适当的裁减，去除不必要的功能，以提高效率和性能。
其次，每家DDS协议站都支持多种QoS服务，但实际项目中可能并不会使用所有这些服务。因此，我们认为可以对无效的QoS服务进行适当的裁减，并根据整车厂的规范要求进行DDS定制化开发，以满足实际项目需求。
最后，工具链的兼容性也是关键。大部分都基于AUTOSAR的软件架构进行开发，因此对于DDS的软件模块，如何实现与已有工具链的兼容性是关键。我们采取了将DDS模块直接嵌入到自己的AUTOSAR的DDS软件平台中的解决方案，从而实现了对全套AUTOSAR解决方案的兼容性。
DDS解决方案在设计过程中，我们认为在DDS的开发主要遵循以下三个原则。第一，规范性。要遵循OMG组织提出的标准规范，保证整个设计流程的规范化和设计产物的规范化。第二，兼容性。要考虑到不同平台实现的DDS兼容性，还有DDS软件模块跟已有的AUTOSAR工具链的兼容性。第三，可行性。要关注实际落地效果的性能，并且不断优化设计原则。
AUTOSARDDS的全套解决方案包括以下几个方面：第一，通信矩阵设计：设计了相应的DDS通信矩阵模板，支持通信矩阵到xml文件的转换，为系统设计提供了基础。第二，通信矩阵转换网络设计工具：提供了支持通信矩阵到xml文件的转换工具，方便用户进行通信矩阵的设计和转换。第三，软件层面解决方案：提供了针对AP和CP的解决方案，支持对DDSxml文件的解析，使得软件开发和集成更加顺畅。第四，测试阶段：提供了一致性测试的AETPDDS套件，支持对DDS通信矩阵的测试，确保系统的稳定性和可靠性。第五，总线监控设备：提供相关的总线监控设备，可以进行实车的监测，并支持DDS通信矩阵的解析，帮助用户进行系统调试和故障排除。
（以上内容来自北京经纬恒润科技股份有限公司研发经理于洪斌于2024年3月12-14日在2024第五届软件定义汽车论坛暨AUTOSAR中国日发表的《AUTOSAR DDS在HPC上的开发实践》主题演讲。）
上一篇：蔚来ET9新系统+硬件能带来10个以上新功能？ 下一篇：深蓝汽车6月交付16万辆1-6月销量猛增96%
