SciTech-EECS-Autosar(自动驾驶)-DDS(数据分发服务): 中国智能网联汽车DDS测试标准颁布 → 助力车载设备规范化部署

2025-01-16 18:51:
前些日，中国智能网联汽车行业迎来了一项重要进展。中国汽车工程学会正式发布了编号为T/CSAE 371-2024的《智能网联汽车用数据分发服务（DDS）测试方法》团体标准，
此举标志着国内在车用DDS测试领域填补了空白，为智能网联汽车的未来发展奠定了坚实基础。

DDS(数据分发服务)，作为一种 "分布式实时通信"的"中间件技术规范"，
近年来在智能汽车领域受到了广泛关注。
因为车辆智能化和网联化需求的不断提升，众多车企及供应商纷纷采用DDS作为车载控制器软件的Middleware。
然而，由于DDS协议的复杂性，对采用该技术的车载设备和系统进行验收与评价成为了一项极具挑战性的任务。

为了应对这一挑战，由中国信息通信研究院（简称“中国信通院”）牵头，
联合了包括长城、一汽、吉利、长安、北汽、奇瑞等在内的16家单位，
共同编制完成了这一标准。
该标准旨在规范车用DDS的协议一致性、功能（含QoS）以及安全功能等方面的测试，
以确保有关设备和系统的性能和安全性。

具体而言，该标准依据国际上OMG联盟的DDS系列技术要求，
制定了对应的车用DDS测试方法。
标准内容涵盖了协议一致性测试、协议功能测试以及安全功能测试等多个方面，
为有关测试工作提供了明确的指导和依据。

这一标准的发布，对于采用DDS技术的车载设备和系统的研发、验证和评价，有重要意义。
它不仅解决了DDS协议复杂性带来的测试难题，还为有关测试工作提供了重要依据，
推动了智能网联汽车在该领域的标准化建设。
同时，该标准的实施也将加速车载设备及系统对DDS的规范化部署，
进一步提升智能网联汽车的性能和安全性。

未来，随着该标准的广泛应用，相信将进一步推动智能网联汽车行业的快速发展，
为消费者带来更加安全、智能、便捷的出行体验。

全面解读DDS和TSN融合技术及其测试方案

https://www.cnblogs.com/polelink/p/18350511

十多年来，汽车电子电气架构架构由不断升级的需求的推动而快速演进。
从智能网联、自动驾驶、智能座舱，到软件定义汽车、OTA 升级等新兴应用日新月异，
上层应用的创新，必将催生电子电气架构的变革，后者是前者实现的重要基础。

追溯十多年前，当时的典型架构就是中央网关加上若干 CAN 节点的拓扑结构。
后来随着域控制器、主干网络、集中式架构等概念的引入，
区域控制器和高性能计算单元开始有计划的上位。

在这股变革浪潮，值得重点关注的是一个趋势——功能上移。
早期的分布式架构，整车功能分散布局成十余个 ECU 。
然而，这种分散布局在快速迭代和频繁升级的大潮下，日益无法很好适应需求。
过于分散不利于 ECU 间耦合协同，任何局部变动都可能引发整车级连锁反应，影响迭代升级效率。
因此，引入了域控制器概念，按域整合分散的 ECU 功能，实现集中管理和高效升级。
更进一步，功能继续上移，集中至中央高性能计算平台，
由根本上解决了分散布局导致的迭代低效问题，高效地支持软件快速迭代升级的需求。

图 2: 标准化的基础软件和硬件平台

精简地表达，这可以称为“软硬分离”，或“应用软件与基础软件/硬件平台分离”。
功能上移的本质，是应用软件聚焦层上移，因为底层基础软件和硬件平台则可标准化，实现长周期维护。

软件快速迭代升级是大趋势，应用软件对基础软硬件平台提出了新的需求。

• 首先，是动态性需求。
  为实现快速开发新车型，有必要赋予基础平台一定的动态灵活性，
  这也是过去十年 SOA 架构飞速发展的原因之一。
  动态化的平台，类似搭乐高积木，可让 OEM 厂商快速为系统增加新的功能。
• 其次，更为重要的是实时性需求。
  这是汽车与消费电子的根本不同所在。
  作为交通工具，汽车的首要任务是确保驾驶员、乘客和行人的安全。
  要实现这一点，基础软硬件必须具备足够的实时响应能力、可靠性和确定性，
  才能有力承载关键应用。
• 那么，DDS 如何满足上述各方面需求呢？

DDS 的关键特性

首先，通信模式的角度。
很多人习惯将 DDS 与 SOME/IP 进行对比，但实际上两者遵循的是完全不同的通信模式，有不同的应用场景。

• Pub-Sub(发布-订阅)通信模型，DDS 是一典型，一种面向信号的通信方式。
  大家熟知的 CAN 总线实际上也是发布订阅模型，只是 DDS 版的发布订阅要更加灵活。
  • DDS 的通信模式
    
  • SOME/IP 的通信模式
    
• SOA 模型(Client-Server客户端服务器模型)，则是在Pub-Sub模型上的进一步抽象。
  在Pub-Sub模型, Publisher和Subscriber交互的是独立的Message。
  在SOA 模型，Client和Server交互的数据则赋予了新的语义，如Request/Response/Event等分类的Message等。
  SOA 模型只是表面上看似更高级，但实际上两种模式并无高下之分，只是各有适用的场景。
• 对比 Pub-Sub模型 与 SOA模型
  • Pub-Sub模型更适合实时高性能的定制的数据分发场景，
    如传感器数据、车辆状态数据的分发。
    此外，发布端和订阅端也是高解耦度的，双方无需关注对方的位置状态，
    作者稍后将详解 DDS 在这方面的优势。
  • SOA 模型(Client-Server客户端服务器模型)的限制则更多。
    • 首先，要求数据流向明确，
      要有一Server(中心服务器)节点，其他Clients节点只与该节点通信，
      Clients节点之间无直接交互。
    • 其次，通信模式是Request-Response(请求-响应)式的，
      如数据库查询、文件服务等。
    • 另外，数据和计算资源均集中在Server端。
    • SOA 的典型发展过程图解
      图片来源于AEC 2024《Is SOME/IP the right solution for the next 10 years of vehicles》
      
  • 因此，SOA 通信模型的适用场景是比较有限的。
    使用 SOA 必须要数据流符合该模型，不然会增加设计和开发的成本。
    事实上，这些年，一些 OEM 在第一代车载Ethernet(以太网)量产后，
    大幅追求整车 SOA 化，但开发效率不仅未能显著提升，还增加了不少成本。
    任何科技都有长短，选择与决策适当。

DDS 的以数据为中心

DDS 的一个重要特性是“以数据为中心”。
DDS 世界只有“Data(数据)”这一核心要素。然而 DDS 同是能够实现高度解耦。
过去在介绍 SOA 时，人们常说其一大特点是高度解耦。但解耦并非 SOA 的专利，
而DDS与 SOA 的Service(服务)、Request(请求)、Response(响应) 等复杂概念却不同，
也是能够实现高度解耦。
DDS受益于Pub-Sub通信模型:
应用程序可以类比访问数据库，自由收发数据，而不必关注数据来源去向。
Publisher只需把数据“广播”给DDS，不必care接收者情况；
Subscriber则直接从 DDS “收取”所需数据，不问数据发布方。
这种“充分解耦”的模式，甚至超越了 SOA。

• DDS与SOA的中心Server的区别
  大家可能会问，DDS 是否也要存在一个中央节点，和 SOA 架构类似?
  逻辑上，确实要有一个虚拟的“全局数据空间”，但并非 SOA 的“服务器”概念，两者指向不同层次。

  • DDS 的“Service”, 仅指Distribution服务，负责数据发现、存储、发布等，不涉业务逻辑；
  • SOA 的“Service”, 则指Application的业务服务，如空调、音乐等, 深度参与业务逻辑。

  这是须明确区分的两个概念。
  另外，尽管 DDS 逻辑上有“全局数据空间”，但在物理实现上它仍是分布式的，
  并不存在真实的服务器节点，因此不存在单点故障和性能瓶颈隐患。

• DDS 的以数据为中心的概念以及解耦
  

  上图可以很好地解释 DDS 的 Pub-Sub通信模型的解耦关系。
  ①一开始整个系统处于空闲状态
  ②Publisher开始发布数据,第一个“唤醒”。此时网络上尚无接收者，发布端只管把数据“发给”DDS 即可，随后休眠。
  ③Subscriber收取数据: 等到有Subscriber上线，直接从 DDS“收取”所需Channels的数据即可，无需在意数据源头。
  这种“充分解耦”模式，靠 DDS 的自带的 QoS(服务质量)实现，
  这能够使 DDS 的耦合程度比 SOA 更低。
  因为在 SOA 的 Request-Response通信，Clients和Server必须同时在线，
  而 DDS 并不一定要求如此。

DDS 的Platforms(OS/Protocols)无关

DDS 的另一大特性是平台无关性。这的“平台”泛指操作系统、传输协议等依赖。
DDS 实现Platforms无关的方式是，尽量不依赖于Platforms的独有复杂功能，
而将这些功能需求自主实现，然后通过统一的标准化 API(接口) 对外提供服务。

图 7: DDS 的平台无关

因此，DDS 的可移植性非常好，甚至只要有基本的UDP 通信支持，就可以运行。
事实上，DDS 与 UDP 被认为是最佳拍档，因为 UDP 最为精简，几乎没有 QoS 保证。
DDS 则希望底层协议尽可能精简，因为诸如 QoS 等复杂功能需求，DDS 自身已实现并对应用开放。

但是，DDS 的“自力更生”做法使得有一部分人认为 DDS 过“重”、复杂、资源开销较大。
然而，作者发现，这是一种"局部集中最优化"的设计选择：
DDS 集中地提供了平台无关的、丰富特性、标准统一的API接口，可以达到"局部最优的设计目标"。
作为代价，有一定的资源开销和软件复杂度。这一种权衡，最适合"Autosar的新分封制管理(王侯将相主政一方/域)"。

基于 DDS 实现的 SOA 架构

SOA在现代车载分布式系统上扮演着至关重要的角色。
SOA 提供了一种灵活、可扩展的方法来设计和实现复杂的分布式系统，
使得不同的服务能够独立开发、部署和维护，同时又能无缝地协同工作。

通过在 DDS 之上实现 SOA，
我们可以结合 DDS 的数据化中心特性，和 SOA 的服务化中心特性，
既能够利用DDS的适用于大量实时数据分发的特性，又具备了SOA的灵活、可扩展，便于管理的优势。

前文提到 DDS 并非 SOA 架构，与 SOME/IP 等技术有所不同。
但通过一定手段，DDS 确实可以支持类 SOA 的通信模式。

图 8: DDS-RPC（图片来自 https://www.omg.org/spec/DDS-RPC ）

OMG 发布了 DDS-RPC 标准规范，并且给出了一个参考实现。
在 DDS Topic 的基础上又封装一层，对于Req.报文，添加包含Client GUID(全局唯一 ID) 和 SeqID(序列号)的 Msg. Header，以让Server识别Source(来源)和追踪SeqID.(序列号)。
Server在Reply时，将Server的 ID、SeqID及原Header(请求头)复制到Response报文头上，
使Clients能将 Request-Response 通过 Server/Clients ID 及 SeqID 进行一一对应。

图 9: 基于 DDS 实现 SOA 时存在的问题

虽然基于 DDS 也可以大致模拟 SOA，但仍有些特性缺失，比如真正意义上的Service Discovering(服务发现)功能。
DDS 虽然也有 SPDP/SEDP(发现机制)，但仅提供 "通信端点层面的发现"，无法发现应用层业务服务。
但是，DDS 本身提供了良好的可扩展性，DDS-RPC 框架使用者可自主开发所需的服务发现功能。

另一个限制是，一旦将 DDS 用于请求-响应模式的 RPC 通信，很多 QoS 特性将不再适用。

综合考虑，
将 DDS 用作 SOA 通信框架或 SOME/IP 的替代方案时，我们需要全面权衡其优势与挑战。
DDS 与 SOA 的结合无疑能带来诸多优点，如高性能的实时数据分发与灵活的服务架构的融合。
然而，这种整合也伴随着显著的成本和潜在短处：

• 技术实现方面，我们可能需要自主解决一系列额外的技术问题。
• 功能应用方面，这种使用方式可能会限制 DDS 原有的一些独特优势。
• 资源成本方面，DDS 较高的系统资源占用可能成为一个必须重视的点。

因此，在做出技术路线的选择之前，我们必须审慎评估其带来的收益，
是否足以超过其成本和潜在风险。

通过 TSN 改善 DDS 的传输延迟和优先级

另一需要关注的是传输延迟和优先级问题，这也是 TSN 所重点关注的。

在 DDS 上，有对应的 QoS 策略:
注意: DDS 作为应用层Middleware，本身虽然无法直接控制传输层的 Latency或Priority，但能给出上层的“期望”。

• LATENCY_BUDGET - 允许应用程序向传输层指定"延迟时间的上层需求"。
• TRANSPORT_PRIORITY - 同理，应用层可以指定不同数据流的传输优先级，

需要注意的是，这些延迟和优先级的设置，实际上更多是应用层对传输层的一种“建议”或“要求”。
如何基于这些要求，动态调度网络资源、规划路径、设置队列等，
要由深层的传输层的有关机制来决策及实现，DDS 本身无法约束。

图 13: TSN 中间件

一种可行方案是:
在 DDS 下层部署一个 TSN Middleware，专门负责动态处理这些延迟和优先级需求。
但这种机制也存在新的不确定性风险。
当资源有限时，必定会有部分延迟、优先级需求无法满足，这将导致无法接受的实时性下降。
因此，在决定是否采用这种机制时，我们需要全面评估其在车载场景下的适用性和合理性，
谨慎权衡收益和潜在风险。

OMG DDS-TSN

说到 DDS 与 TSN 的融合，就不得不提接 OMG 发布的 DDS-TSN 规范，
该规范定义了 DDS 与 TSN 的集成插件。
目前该规范已经发布了 Beta 版本，有需要的读者可以在 OMG 官网免费下载。

DDS-TSN 规范的目的是建立一个统一标准，
使不同供应商在实现 DDS 与 TSN 集成时能够遵循相同规范，
进一步实现整个行业内产品和工具链的互操作性，有利于提高开发效率，降低成本。

OMG DDS-TSN 规范约束了两个主要方面的内容:
第一，是标准化了 DDS-TSN 系统的部署和配置流程。
第二，是提出了两种具体的技术实现方案:

• RTPS → UDP/IP → TSN Ethernet 方案: 实现成本低 + 实时性低
  RTPS 消息映射到 UDP/IP 上 ，再通过 TSN 传输 UDP 数据包。
  • 长处是容易实现: 这是一种比对容易实现的方式，
    因为只要将原有传统以太网改为 TSN 以太网，对系统修改较小。
  • 缺短处是对实时性有影响: 要有额外时间开销:
    数据要经 UDP/IP 协议栈，后到 TSN 网络，实时性会受操作系统内核调度影响。
• RTPS → TSN Ethernet 方案: 实时性高+实现成本高。
  将 RTPS 直接映射到 TSN 网络的以太网帧上，绕过 UDP/IP协议栈的影响。
  这种方式可有效提高实时性，但需对 DDS 实现做大量修改，研发工作量较大。

两种方案各有长短，应根据具体场景的实时性需求和开发投入进行权衡选择。

针对 DDS -TSN 的系统级测试

图 14: “应用到应用”的 DDS-TSN 系统级接口测试框架

在Middleware测试领域，一个核心问题是:
如何有效地对Middleware产生激励或触发测试。
这一挑战源于Middleware接口的特殊性。

黑盒测试通常需要仿真被测对象的输入并测量其输出。
然而，Middleware的接口多以软件形式存在，这与传统的 ECU 硬件在 HIL(环)测试有显著不同。
Middleware测试面临的主要问题，在于少有可直接进行激励或测量的物理外部Interface。

为应对这一挑战，业界普遍采用的方法, 是在 ECU 内部嵌入专门的测试应用程序。
例如，TC 8 中的 Upper Tester 或 ETS 就是此类应用。
这些程序的作用是将Middleware的软件接口，以标准化的服务接口形式通过网络发布出来，
使外部测试系统能够访问Middleware接口。

在 DDS-TSN 系统测试上，可沿用这一思路，在系统内置入测试应用程序。
需要注意的是，车载分布式系统通常具有较高的复杂性，可能包含多种网络节点配置：

• 独立网络节点
• 复杂节点，内部包含多个通过板载交换机通信的子系统

支持多进程的高级操作系统节点，进程间通信采用基于共享内存的 DDS
尽管系统结构复杂多样，但是仍能采用统一的方式植入测试程序。
这得益于 DDS 接口的一致性，使我们无需过多关注底层实现细节。

在测试系统层面，可通过私有协议对这些 DDS 测试程序进行控制和编排，以实现各种测试用例。
这种架构实现了真正的“应用到应用”测试，能够全面反映整个系统的行为表现。

除了全系统测试，还有必要开展多种专项测试，
聚焦于特定环节，如物理层到物理层（Phy-to-Phy）测试。
但需要注意的是，这类局部测试结果可能无法准确反映整个系统的时间特性。

不仅要提供标准测试用例集，还药支持用户根据系统的特殊场景，定制开发新的测试用例。
例如，用户可以设计一对多通信、多对一通信等模拟真实应用场景的测试。

图 15: 监测 DDS-TSN 的时钟同步状态

此外，时间特性测试（如延迟测试）依赖于全局同步时钟，以确保收发双方具有共同的时间基准。
这一点在设计和执行测试时需要特别关注。

为了实时监控时钟同步系统的运行状态，可采用 TSN CoreSolution，
能够对网络上的每一节点的 1 PPS(Pulse Per Second每秒脉冲) 信号进行实时监测。
通过这种方式，我们可以准确判断时钟同步系统是否正常工作，以及其Error值是否满足系统要求。

TSN系统分析: TSN Box(硬件) + TSN Tools(上位机软件)

在硬件方面，使用的核心工具是 TSN Box。
这是一个专门设计用于 TSN 系统仿真和分析的硬件系统。
TSN Box 具备丰富的接口支持，尤其是能够采集 1 PPS 信号，这使得它成为时钟同步监测的理想设备。
与 TSN Box 配套的是上位机软件 TSN Tools。这款软件提供了强大的数据分析和可视化功能。
通过 TSN Tools，我们能够：

• 实时处理从 TSN Box 采集的数据
• 进行深入的时钟同步性能分析
• 提供直观的可视化界面，便于工程师快速识别和解决同步问题

这套软硬件组合（TSN Box 硬件 + TSN Tools 软件）为我们提供了一个全面的 TSN 系统分析平台。
它不仅能够监测时钟同步，还能对整个 TSN 网络的性能进行全方位的评估和优化。

图 16: 监测 DDS-TSN 的网络消息的格式和行为

时钟同步监测之外，TSN Box 还有捕获以太网原始数据的能力，
这为深入分析 DDS-TSN 系统的行为提供了重要支持。
值得注意的是，所有捕获的数据都以 gPTP 为基准时钟，确保了数据的时间一致性。

在实际应用上，测试过程所产生的各类数据都可以被放置在同一时间基准上进行分析，
如 DDS 接口测试日志、以太网数据帧的时间戳等数据。
这种统一的时间视角就能够全面、准确地评估系统性能。

通过对这些统一基准的数据进行分析，
我们可以轻松地识别并量化系统在每个环节的具体延迟。
这种精细化的延迟分析对于优化系统性能、满足严格的实时要求至关重要。

总结

本文全面介绍了软件定义汽车对网络通信技术的新需求，
并阐述了如何通过 DDS 与 TSN 的融合来提升系统的动态灵活性和实时性能力，
最后介绍了针对 DDS 与 TSN 融合系统的测试解决方案。

针对复杂的 DDS-TSN 系统，本文提出了一套完整的“应用到应用”的系统级测试方法，
通过植入测试程序、监控时钟同步、捕获网络数据包、进行统一时间基准的分析，
可以全面评估和验证系统的实时性能指标，
为软件定义汽车的软硬件架构集成提供有力支持。

在车载网络通信和Middleware Testing领域拥有多年经验，
已为众多整车厂和供应商提供过 DDS、TSN 等技术的咨询和测试服务，
拥有成熟的解决方案和专业的技术团队。
能够满足客户在软件定义汽车网络通信架构集成和测试验证等方面的各种需求，
期待各位读者与我们进一步交流。

本文来自博客园，作者：{北汇信息}，转载请注明原文链接：{https://www.cnblogs.com/polelink/}