标签: DDS

软件定义汽车对网络通信技术的影响 图 1: 汽车电子电气架构演进趋势 十多年来，汽车电子电气架构架构在不断升级的应用需求的推动下快速演进。从智能网联、自动驾驶、智能座舱，到软件定义汽车、OTA 升级等新兴应用层出不穷，上层应用的创新必将催生电子电气架构的相应变革，后者是前者实现的重要基础。 回溯十多年前，当时典型的架构就是中央网关加上若干 CAN 节点的拓扑结构。后来随着域控制器、主干网络、集中式架构等概念的引入，区域控制器和高性能计算单元开始崭露头角。 在这股变革浪潮中，值得重点关注的是一个趋势——功能上移。早期的分布式架构中，整车功能分散布局在十余个 ECU 之中。然而，这种分散布局在快速迭代和频繁升级的大潮下，显然无法很好适应需求。过于分散加剧了 ECU 间耦合，任何局部变动都可能引发整车级连锁反应，迭代升级效率大打折扣。 为解决这一困境，后来引入了域控制器概念，将分散的 ECU 功能进行整合，实现集中管理和高效升级。更进一步，功能继续上移集中至中央高性能计算平台，从根本上解决了分散布局导致的迭代低效问题，有力支持软件快速迭代升级的需求。 图 2: 标准化的基础软件和硬件平台 功能上移的本质，是应用软件向上移动，而底层基础软件和硬件平台则可标准化，实现长周期维护。简单来说，这可以称为“软硬分离”，或“应用软件与基础软件/硬件平台分离”。 在这种软件快速迭代升级的大趋势下，应用软件对基础软硬件平台提出了新的需求。 首先是动态性需求。为实现快速开发新车型，有必要赋予基础平台一定的动态灵活性，这也是过去十年 SOA 架构飞速发展的原因之一。动态化的平台，就像搭乐高积木一样，可让 OEM 厂商快速为系统增加新的功能。 其次，更为重要的是实时性需求。这是汽车与消费电子的根本差别所在。作为交通工具，汽车的首要任务是确保驾驶员、乘客和行人的安全。要实现这一点，基础软硬件必须具备足够的实时响应能力、可靠性和确定性，才能有力承载关键应用。 那么DDS 如何满足上述各方面需求呢？ DDS 的关键特性 首先从通信模式的角度来看。很多人习惯将 DDS 与 SOME/IP 进行对比，但实际上两者遵循的是完全不同的通信模式，有不同的应用场景。 图 3: DDS 通信模式 DDS 是典型的发布订阅 （Pub-Sub） 通信模型，更像一种面向信号的通信方式。大家熟知的 CAN 总线实际上也是发布订阅模型，只不过 DDS 版的发布订阅要更加灵活。 图 4: SOME/IP 的通信模式 而客户端服务器模型 （Client-Server），又称 SOA 模型，则是在发布订阅模型基础上的进一步抽象。 在发布订阅模型中，发布者和订阅者交互的是独立的消息 （Message）。但在 SOA 模型里，客户端和服务端交互的数据则赋予了新的语义，如请求消息、响应消息、事件消息等。 表面上 SOA 模型看似更高级，但实际上两种模式并无优劣之分，只是各有适用的场景。 发布订阅模型更适合大量简单的实时数据分发场景，如传感器数据、车辆状态数据的分发。此外，发布端和订阅端也是相对解耦的，双方无需关注对方的位置状态，笔者稍后将详解 DDS 在这方面的优势。 而客户端服务器模型的限制则更多。首先要求数据流向明确，需有一中央节点，其他节点 （客户端） 只与该节点通信，客户端节点之间无直接交互。其次，通信模式是请求-响应式的，如数据库查询、文件服务等。再者，数据和计算资源均集中在服务端。 图 5: SOA 的典型发展过程（图片来源于AEC 2024《Is SOME/IP the right solution for the next 10 years of vehicles》） 因此，SOA 通信模型的适用场景是比较有限的。如果数据流不符合该模型，使用 SOA 反而会增加设计和开发的负担。事实上，近年一些 OEM 在第一代车载以太网量产后便急于追求整车 SOA 化，但开发效率未能显著提升，反而增加了不少成本。 DDS 的以数据为中心 DDS 的一个重要特性是“以数据为中心”。 过去在介绍 SOA 时，人们常说其一大特点是解耦。但解耦并非 SOA 的专利，DDS 同样能够实现解耦。 与 SOA 中的服务、请求、响应等复杂概念不同，DDS 世界中只有“数据”这一核心要素。应用程序可以像访问数据库一样，自由收发数据，而无需关注数据来源去向。发布端只需把数据“丢给”DDS，不必理会接收者情况；订阅端则直接从 DDS “拿走 ”所需数据，不问数据发布方。这种“充分解耦”的模式，甚至超越了 SOA。 大家可能会问，DDS 中是否也存在一个中央节点，和 SOA 架构类似? 从逻辑上讲，确实存在一个虚拟的“全局数据空间”。但这并非 SOA 中的“服务器”概念，两者指向不同层次。DDS 中的“服务”，仅指数据分发服务，属底层功能，负责数据发现、存储、发布等，不涉及业务逻辑；而 SOA 中的“服务”则指应用层的业务服务，如空调、音乐等。这是须明确区分的两个概念。另外，尽管 DDS 逻辑上有“全局数据空间”，但在物理实现上它仍是分布式的，并不存在真实的服务器节点，因此不存在单点故障和性能瓶颈隐患。 图 6: DDS 的以数据为中心的概念以及解耦 上图可以很好地解释 DDS 发布订阅双方的解耦关系。一开始整个系统处于空闲状态，发布端第一个“唤醒”，开始发布数据。此时网络中尚无接收者，但没关系，发布端只管把数据“丢给”DDS 即可，随后自己进入休眠。等到有订阅端上线需要数据时，直接从 DDS“拿走”所需数据即可，根本无需在意数据源头。这种 “充分解耦”模式靠 DDS 的内置 QoS （服务质量）实现，这能够使 DDS 的耦合程度比 SOA 更低。因为在 SOA 的请求-响应通信中，客户端和服务端必须同时在线，而 DDS 并不一定要求如此。 DDS 的平台无关 DDS 的另一大特性是平台无关性。这里的“平台”泛指操作系统、传输协议等底层依赖。DDS 实现平台无关的方式是，尽量不依赖于平台的独有复杂功能，而将这些功能需求自己实现，然后通过统一的标准化接口对外提供服务。 图 7: DDS 的平台无关 因此，DDS 的可移植性非常良好，只要有基本的 UDP 通信支持，就可以运行 DDS。事实上，DDS 与 UDP 被认为是最佳拍档，因为 UDP 最为简单，几乎没有 QoS 保证。而 DDS 则希望底层协议尽可能简单，因为诸如 QoS 等复杂功能需求，DDS 自身已实现并对应用开放。 不过，DDS 这种“自力更生”的做法，也带来了一个印象 —— 在很多人眼里，DDS 显得过于“重”、过于复杂，资源开销较大。笔者认为这是一种取舍：DDS 一边提供了丰富特性、标准统一接口和平台无关性，作为代价，另一边就是较高的资源开销和软件复杂度。这是一种权衡，没有绝对的对错。 基于 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 的基础上再封装一层，对于请求报文，添加包含客户端 GUID （全局唯一 ID） 和序列号的报文头，以让服务端识别来源和追踪序列。服务端回复时，将服务端 ID、序列号及原请求头复制到响应报文头中，使客户端能对应到之前的请求。 图 9: 基于 DDS 实现 SOA 时存在的问题 虽然 DDS 可以大致模拟 SOA，但仍有些特性缺失，比如真正意义上的服务发现功能。DDS 虽然也有发现机制 （SPDP/SEDP），但仅提供通信端点层面的发现，无法发现应用层业务服务。不过，DDS 本身提供了良好扩展性，DDS-RPC 框架使用者可自行开发所需的服务发现功能。 另一个限制是，一旦将 DDS 用于请求-响应模式的 RPC 通信，很多 QoS 特性将不再适用。 综合考虑，将 DDS 用作 SOA 通信框架或 SOME/IP 的替代方案时，我们需要全面权衡其优势与挑战。DDS 与 SOA 的结合无疑能带来诸多优点，如高性能的实时数据分发与灵活的服务架构的融合。然而，这种整合也伴随着显著的成本和潜在缺陷： 技术实现方面，我们可能需要自行解决一系列额外的技术问题。 功能应用方面，这种使用方式可能会限制 DDS 原有的一些独特优势。 资源消耗方面，DDS 较高的系统资源占用可能成为一个不容忽视的负担。 因此，在做出技术路线的选择之前，我们必须审慎评估其带来的收益是否足以抵消相应的成本和潜在风险。 DDS 与 TSN 的融合 实时性是系统性问题 首先需要明确，实时性是一个系统性挑战，原因在于汽车电子电气系统本身就是一个错综复杂的大系统。尤其是在车载以太网进入汽车领域后，Linux、Android、QNX 等复杂操作系统也开始大量应用，这使得确保整体实时性变得更加困难。 图 10: 分布式系统的实时性问题 其中的根源在于，从应用程序、中间件、操作系统到硬件、网络，每个环节都存在一定的不确定性因素，而这些不确定性会沿着系统层层累积，越靠近应用层级别，不确定性就越高；而越接近硬件层级，不确定性就越低，最终各环节不确定性的累积导致整个系统的不确定性和实时性下降。 因此，解决分布式系统实时性问题是一个复杂的系统工程，我们不能寄希望于某一单一技术的应用就能全面解决。单靠某种中间件、操作系统或网络技术是远远不够的，需要从系统层面综合施策，通过架构、平台、中间件、操作系统等多维协同，才能够满足严格的实时性需求。 首先需要明确的一点是，TSN （时间敏感网络）只能解决网络层面的实时性问题，且主要针对二层或二层以下。汽车领域常见的 TSN 协议见下表。 除了网络层面，大部分不确定性实际上来自于终端节点内部，而这部分无法依赖 TSN 来解决。由于终端内部的复杂性，很难有一个标准化的简单方案来全面解决内部实时性问题。 那么针对 DDS，我们可以采取以下措施来提高实时性和确定性: 内存申请固化：减少不可预测的动态内存申请 通信关系固化：降低正常使用场景下通信关系的动态变化，减少节点动态进出 交互过程固化：减少 DDS 协议维护数据可靠性而产生的额外数据交换 数据长度限制：避免单次发送/接收时间超出预期 总之，我们可以在一定程度上限制 DDS 的动态性特征，以换取更好的可预期性和实时性。这是一种权衡，需要根据具体场景需求来平衡动态性和实时性。 通过 TSN 改善 DDS 时间控制 前面我们从全局角度分析了实时性问题，下面针对一些具体点做进一步探讨。 DDS 的工作依赖于两种时钟： 内部时钟 - 用于中间件内部的各种定时操作，如周期性发送 SPDP 消息、Heartbeat 消息、Deadline 控制等。 外部时钟 - 主要用于为发送消息打上时间戳。 图 12: DDS 的时钟系统 应用时间同步（例如通过 IEEE 802.1 AS 同步）后，可实现更精确的时间控制，如 Deadline 等 QoS 策略。如果时间未同步，不同节点之间会存在时间偏差。例如发送端 1 秒周期发送数据，接收端实际周期或许是 1.2 秒。这时如果配置 1 秒的 Deadline QoS，接收端就可能误判为超时。 因此，缺少时钟同步系统时，我们只能放宽 Deadline 容忍度，比如正负 500 ms 视为正常。而通过时钟同步技术，我们可以实现更精准的 Deadline 控制，例如 1 ms 或更低。 另一需注意的是时钟跳跃问题。当 DDS 时钟配置为同步时钟源时，启动或其他情况下时钟可能会发生较大跳跃。无论是内部时钟还是外部时钟的跳跃，都可能导致 DDS 工作异常。所以在正常运行期间，时钟跳跃是应当尽量避免的。 时钟同步对实现精确的实时性控制非常重要，但也需规避时钟跳跃风险。在部署时钟同步方案时，务必权衡两者，审慎评估并制定相应的容错措施。 通过 TSN 改善 DDS 的传输延迟和优先级 另一需要关注的是传输延迟和优先级问题，这也是 TSN 所重点关注的。 在 DDS 中，有对应的 QoS 策略: LATENCY_BUDGET - 允许应用程序向底层传输层指定一个延迟时间要求。但 DDS 作为应用层中间件，本身无法对底层传输进行控制，只能给出这样的“期望”。 TRANSPORT_PRIORITY - 同理，应用层可以指定不同数据流的传输优先级，但无法直接对底层传输层进行优先级调度。 需要注意的是，这些延迟和优先级的设置，实际上更多是应用层对底层传输的一种“建议”或“要求”。如何基于这些要求来动态调度网络资源、规划路径、设置队列等，需要在底层传输层有相应的机制来支持，DDS 本身无法约束。 图 13: TSN 中间件 一种可行方案是在 DDS 下层部署一个 TSN 中间件，专门负责动态处理这些延迟和优先级需求。但这种机制也存在新的不确定性风险。当资源有限时，必定会有部分延迟、优先级需求无法满足，这将导致无法接受的实时性下降。因此，在决定是否采用这种机制时，我们需要全面评估其在车载场景下的适用性和合理性，谨慎权衡收益和潜在风险。 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 传输 UDP 数据包。这是一种相对容易实现的方式，因为只需将原有传统以太网改为 TSN 以太网，对系统修改较小。但缺点是数据需经 UDP/IP 协议栈再到 TSN 网络，实时性会受操作系统内核调度影响。 将 RTPS 直接映射到 TSN 网络的以太网帧上，绕过 UDP/IP 协议栈的影响。这种方式可有效提高实时性，但需对 DDS 实现做大量修改，研发工作量较大。 两种方案各有利弊，应根据具体场景的实时性需求和开发投入进行权衡选择。 针对 DDS -TSN 的系统级测试 图 14: “应用到应用”的 DDS-TSN 系统级接口测试框架 在中间件测试领域，一个核心问题是如何有效地对中间件产生激励或触发测试。这一挑战源于中间件接口的特殊性。 黑盒测试通常需要仿真被测对象的输入并测量其输出。然而，中间件的接口多以软件形式存在，这与传统的 ECU 硬件在环 （HIL） 测试有显著差异。中间件测试面临的主要困难在于缺乏可直接进行激励或测量的物理外部接口。 为应对这一挑战，业界普遍采用的方法是在 ECU 内部嵌入专门的测试应用程序。例如，TC 8 中的 Upper Tester 或 ETS 就属于此类应用。这些程序的作用是将中间件的软件接口以标准化的服务接口形式通过网络暴露出来，使外部测试系统能够访问中间件接口。 在 DDS-TSN 系统测试中，北汇信息沿用了这一思路，在系统内置入测试应用程序。需要注意的是，车载分布式系统通常具有较高的复杂性，可能包含多种网络节点配置： 简单的独立网络节点 复杂节点，内部包含多个通过板载交换机通信的子系统 支持多进程的高级操作系统节点，进程间通信采用基于共享内存的 DDS 尽管系统结构复杂多样，北汇信息仍能采用统一的方式植入测试程序。这得益于 DDS 接口的一致性，使我们无需过多关注底层实现细节。 在测试系统层面，北汇信息通过私有协议对这些 DDS 测试程序进行控制和编排，以实现各种测试用例。这种架构实现了真正的“应用到应用”测试，能够全面反映整个系统的行为表现。 除了全系统测试，北汇信息还开展了多种专项测试，聚焦于特定环节，如物理层到物理层（Phy-to-Phy）测试。但需要注意的是，这类局部测试结果可能无法准确反映整个系统的时间特性。 北汇信息不仅提供标准测试用例集，还支持用户根据系统的特殊场景定制开发新的测试用例。例如，用户可以设计一对多通信、多对一通信等模拟真实应用场景的测试。 图 15: 监测 DDS-TSN 的时钟同步状态 此外，时间特性测试（如延迟测试）依赖于全局同步时钟，以确保收发双方具有共同的时间基准。这一点在设计和执行测试时需要特别关注。 为了实时监控时钟同步系统的运行状态，北汇信息采用了 TSN CoreSolution 工具，能够对网络中每个节点的 1 PPS（每秒脉冲）信号进行实时监测。通过这种方式，我们可以准确判断时钟同步系统是否正常工作，以及其误差是否满足系统要求。 在硬件方面，使用的核心工具是 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 系统，文中提出了一套完整的“应用到应用”的系统级测试方法，通过植入测试程序、监控时钟同步、捕获网络数据包并进行统一时间基准的分析，可以全面评估和验证系统的实时性能指标，为软件定义汽车的软硬件架构集成提供有力支持。 北汇信息在车载网络通信和中间件测试领域拥有多年经验，已为众多整车厂和供应商提供过 DDS、TSN 等技术的咨询和测试服务，拥有成熟的解决方案和专业的技术团队，能够满足客户在软件定义汽车网络通信架构集成和测试验证等方面的各种需求，期待各位读者与我们进一步交流。

凯泽斯劳滕理工大学（Technische Universität Kaiserslautern），位于德国莱茵兰-普法尔茨州，是一所国立理工科大学。该大学成立于1970年7月13日，最初是特里尔/凯泽斯劳滕兄弟大学的一部分。1975年，凯泽斯劳滕理工大学从特里尔与凯泽斯劳滕兄弟大学中分离出来，独立成为今天的凯泽斯劳滕理工大学。2003年，该大学被正式命名为Technische Universität Kaiserslautern，是一所具有强烈研究导向和国际声誉的理工科大学，提供了丰富的学习计划和科研机会。 创建量子计算机（QC）的方法有很多，凯泽斯劳滕理工大学在Rymax One合作中采用的方法就是创建一个由单个原子组成的阵列，并将这些原子作为量子位使用。然而， 其挑战在于每个原子的定位必须十分精准 。因此，凯泽斯劳滕理工大学使用了激光，并将每个原子都有效地锁定在激光束中心，如同光镊阵列一样。然而，对每个激光束的移动进行逐点编程需要大量的编程和数据。 Rymax One QC： 由凯泽斯劳滕理工大学（Technische Universität Kaiserslautern）参与的一个量子计算机开发项目，采用光学镊子将单个镱原子悬浮在真空中，使其处于里德伯态。Rymax合作专注于量子优化问题，例如最大独立集问题，以及诸如QAOA或量子退火等算法来寻找解决方案。这使他们能够为“模拟”量子计算创建优化的硬件。该设计的一个关键点是动态控制紫外激光的光，这需要对不同的射频信号进行完全控制。 光镊阵列Optical Tweezer Array： 光镊阵列是一种基于光镊技术的先进装置，用于同时对多个微粒进行三维操纵。光镊技术自1986年由Ashkin等人发明以来，已经得到了迅速的发展。最初的光镊只能控制单个微粒，而阵列光镊的出现使得同时操纵多个微粒成为可能。该技术在生物医学、物理、化学等多个研究领域中有着广泛的应用，例如在细胞操纵、微粒组装、光学测量等领域。由于其高精度和灵活性，光镊阵列被视为一种非常有价值的工具，尤其在微纳尺度的研究中。 为此， TS Spectrum全新的直接数字频率合成（DDS）固件选项，通过几个简单的命令就能控制激光的位置 。这些命令定义了开始和终止时的参数，因此避免了大量耗时的数据计算。 物理学博士 Jonas Witzenrath 表示：“该产品对推动我们的研究进展产生了巨大的影响。 全新的DDS选项不仅使我们取得了快速的进展，还能简化系统的复杂性，使我们能够更加专注于研究 。接下来，我们将通过DDS固件的动态特性对静态二维阵列中的原子进行重新排序。”此外，Jonas将使用任意波形发生器(AWG)来生成理想的紫外激光脉冲，以精确控制量子位之间的交互。” 物理学博士Jonas Witzenrath在位于德国凯泽斯劳滕理工大学的量子实验装置前 "DDS已经成为我们项目中的重要工具。此外， 我们还发现DDS灵活的特性使它还适用于实验室的其他功能，所以这也节省了我们购买脉冲激光和调制生成器等其它设备的费用 。为了开发DDS更多的功能，我们与TS Spectrum展开了密切的合作。目前，我们也正在努力扩大DDS功能在实验室研究中的其他用途，使其发挥最大潜力。” 他补充到：“ TS Spectrum的AWG卡模拟性能卓越、内存大且传输速度非常快，因此成为了量子研究的首选解决方案 。传输速度对于实验而言非常重要，因为在计算重新排列的波形并将其传输到卡上这段时间实验必须暂停。TS Spectrum的AWG卡凭借卓越的传输速度，使其在同类产品中脱颖而出，这也是该产品在AMO/QC社群中被广泛使用的主要原因。此外，AWG卡的操作速度也尤为重要。快速AWG存在数十毫秒的固有延迟或较大的抖动问题，这会导致系统在校正和重新校正时不准确或需要更长的处理时间。DDS固件使Spectrum的AWG能够在20微秒内生成命令，得益于固有的定时，这些命令实际上是无抖动的。” 声光偏转器（红色箭头所示）将一个激光束分成多个可控的单束激光，用于捕获和持有原子 DDS是通过单个固定频率参考时钟生成任意周期正弦波的方法。该技术被广泛使用于信号生成类应用中。用户能够通过德思特Spectrum提供的DDS选项，定义每张AWG卡上的23个DDS核心。这些核心随后会被发送至硬件输出通道。用户可以对每个DDS核心（正弦波）的频率、幅度、相位、频率斜率和幅度斜率进行编程。DDS输出能够与外部触发事件或与分辨率为6.4ns的可编程定时器同步。 在DDS模式下，AWG可作为多音DDS信号的发生器。该设备内置4GB内存和快速DMA传输模式，使DDS命令的传输速度高达每秒1000万条。这种独特的能力让用户能够通过简单易用的DDS命令灵活地执行用户自定义斜率（例如S形）以及各种调制类型（例如FM和AM）。 在一个实验示例中，TS SpectrumM4i.6631-x8 AWG卡被用于驱动一个声光偏转器（AOD）以产生一个光镊来捕获原子。AOD是通过一个约为82MHz的射频信号驱动。在当前设置中，射频信号每改变1MHz，就会使镊子沿S形频率斜坡在100μs内移动8μm以最小化加热效应。在此期间，信号的幅度将线性地改变以补偿光强度的变化。 广泛应用于量子研究：M4i.6631-x8任意波形发生器，采样速度为1.25 GS/s，分辨率为16位，双通道

在上一篇文章中，我们对 DDS 协议测试的策略、方法和工具进行了详细的介绍。本文旨在进一步探讨如何利用这些方法和工具搭建实际的测试环境，并执行测试，进而揭示可能遇到的各类问题。 被测协议栈简介 在本次测试中，被测协议栈选择了一个在汽车行业内广泛使用的开源 DDS 产品。 近年来随着开源软件社区的不断发展和成熟，越来越多的整车厂在选择 DDS 协议栈实现时，开始青睐开源产品。相比商业化的 DDS 协议栈，开源产品具有显著的成本优势。此外，使用开源产品还可以让整车厂获得更大的自主可控性，以便根据自身需求对协议栈进行定制和优化。 然而天下没有免费的午餐，选择开源 DDS 协议栈也意味着使用者必须承担起产品质量的责任。与商业化产品不同，开源产品通常没有专门的团队负责质量保证。因此，开源 DDS 协议栈的使用者必须投入额外的精力和资源，甚至组建专门的软件团队，来全面评估、测试和维护所选择的开源产品，以确保其功能和性能满足汽车行业的严苛要求。 在本篇文章中我们试图准确地识别出可能存在的问题，希望为汽车行业用户在选择开源 DDS 协议栈时提供实用的参考。 测试环境搭建 被测的 DDS 协议栈部署在一台运行 Ubuntu 操作系统的 x 86 服务器上。这种部署方式能够为 DDS 协议栈提供一个简单、稳定，且一致的运行环境，避免资源或网络配置错误等原因导致的测试结果不可信。 同时，为了全面评估 DDS 协议栈的功能和性能，我们在 DDS 之上部署了两个专门设计的测试应用程序。这两个应用程序的主要目的是模拟真实场景下的应用程序对 DDS 接口的调用，以验证 DDS 能够正确地处理各种请求并返回预期的结果。通过这种方式, 可以全面检验 DDS 的接口是否符合 OMG DDS 标准，以及是否能够满足汽车行业的特定需求。 为了实现对测试过程的自动化控制和管理，我们在上位机中开发了一套专门的测试脚本。这些脚本负责向 DDS 测试应用程序发送各种测试指令，根据预定的逻辑对测试应用程序的行为进行编排和调度。测试过程全自动化，无需任何人工干预，能够确保测试过程的一致性和可重复性。 此外，为了方便工程师对测试用例进行管理和监控，上位机软件还提供了一个直观的图形化界面。通过这个界面，测试人员可以轻松地创建、编辑和组织测试用例，并实时监控测试的执行状态和结果。 图1: DDS测试环境搭建 需要强调的是，测试环境可以根据用户的具体需求进行灵活地配置。比如将 DDS 测试程序部署在一个或多个真实的 ECU 中，以帮助我们发现系统性的网络配置问题、兼容性问题或性能问题等，包括防火墙、IP 地址、端口号、TSN 约束、时间同步、网络拓扑结构问题，DDS 中间件与不同硬件和软件平台之间的兼容性问题，也包括吞吐量、延迟、资源占用等指标。从而全面评估 DDS 分布式系统在实际应用场景下的可靠性、兼容性和性能表现，为系统的开发和优化提供重要的依据。 测试用例介绍 测试用例覆盖了 OMG DDS 规范中定义的所有软件接口，共 406 条测试用例，内容如下： 接口行为测试，包括正常调用时的行为测试，以及错误调用的故障行为测试，共计 353 条用例 QoS 测试，即 OMG DDS 中定义的各项 QoS 的功能测试，共计 53 条用例 关于性能测试，由于 DDS 的性能很大程度上取决于硬件平台的性能和资源情况，以及操作系统的调度和管理机制，故在测试服务器中得到的性能测试结果与实际系统的性能表现可能相差很大，故本次测试不包含性能测试。 测试结果分析 概览 本次测试共计执行 406 个测试用例，通过194个，失败 212 个，通过率为 47.78%。如下为各模块的通过情况。 图2: 测试结果概览 问题示例 1. 功能缺失 如下表格列出了部分当前版本 DDS 缺失的接口。这些缺失的接口对于 DDS 分布式系统的功能和性能具有直接或间接的影响。重要的是，开发者文档可能并未明确指出这些接口功能的缺失，这种情况可能会对系统的稳定性和可靠性带来潜在风险。因此，用户在使用 DDS 时需要对这些潜在的缺陷保持警觉，并采取相应的预防措施。此外，用户应当积极参与开源社区讨论，关注产品的更新日志，以便及时了解和补充这些关键接口的功能，从而降低系统运行中的不确定性和风险。 表 1: 功能缺失问题示例 图3: 功能缺失问题的测试报告示例 2. 行为错误 当开发者根据官方文档调用特定 API 时，软件表现出的行为与文档描述不一致。这种不一致性可能表现为返回错误的结果、触发未预期的副作用或完全无响应。这种情况下，开发者不得不投入大量的时间去排查和定位问题。 表 2：API 行为错误示例 图4: 行为错误测试报告示例 3. 异常终止 此类问题指的是当应用程序在某些场景下调用特定接口时，DDS 中间件出现异常终止。这类问题的严重性在于其难以被发现、排查和修复。问题的隐蔽性在于异常通常只在特定的条件下触发，这些条件可能包括特定的数据模式、并发级别或资源使用情况，使得在常规测试中难以触发和识别。同时，即使问题被成功识别，修复工作也同样困难重重，这需要精确修改复杂的代码逻辑，还需要确保不会对 DDS 的其他功能造成负面影响。 由于 DDS 中间件作为系统的基础软件，其稳定性对整个系统的运行至关重要。同时，基础软件的不稳定性会对上层应用和最终用户产生连锁反应，极大地影响整个系统的质量和用户体验。因此，解决 DDS 中间件的异常终止问题，不仅是提升软件质量的技术挑战，也是确保系统整体稳定性和可靠性的重要一环。 表 3: DDS 软件异常终止问题示例 总结 经过本篇文章的介绍，相信读者已经对DDS的协议测试以及可能存在的问题有了大概的了解。 在敏捷开发模式下，软件需求不断增加，软件系统的规模和复杂度也在不断增长。然而，许多关键问题（尤其是性能问题）只有在软件达到一定规模和复杂度后才会暴露出来。一旦发现这些问题，修复的成本往往非常高昂，因为任何基础软件的改动可能会影响到整个系统，牵一发而动全身。 相比之下，如果在项目早期就能够模拟实际的应用场景，并对 DDS 进行全面的功能和性能测试，开发团队可以深入了解 DDS 的行为特点，甚至软件缺陷，识别性能瓶颈，从而及时调整设计，优化实现。这种“前置”的测试方法不仅能够显著降低后期的修复成本，能够提高整个系统的质量和可靠性，帮助系统应对未来的挑战。 本文介绍了南京臻融科技有限公司（以下简称“臻融科技”）开发的DDS协议测试工具。臻融科技在过去十年里，一直致力于DDS产品及其相关工具链的自主研发，并且在国内关键行业领域取得了最高的市场份额。这款DDS协议测试工具在DDS研发过程中已经历了近十年的不断迭代，证明了其产品的成熟性和可靠性。臻融科技与北汇信息的合作，旨在将这套工具引入汽车行业，以协助客户建立DDS测试能力，提供高品质的测试服务和相关培训，进而加快DDS在汽车行业的推广和应用。

概述 OMG DDS（Data-Distribution Service）协议测试套件是北汇信息与臻融科技合作研发的针对 DDS 中间件软件的测试套件。该套件用于验证 DDS（Data-Centric Publish-Subscribe, DCPS）软件的核心功能与 OMG DDS 相关标准规范的一致性，包括 API (Application Programming Interface) 接口及行为，QoS (Quality of Service) 功能等，也可用于评估 DDS 软件的性能，如吞吐量，时延等。测试套件中包括： 测试用例管理和执行监控平台软件 DDS Tester 软件（一款特殊的 DDS 应用程序，用于实现对 DDS 中间件的激励或监测） 测试用例 自动化测试脚本 测试用例和测试脚本简介 依据 OMG DDS 规范开发共计 400 余条测试用例以及自动化测试脚本，能够覆盖： DDS 接口功能测试，如 DomainParticipantFactory DomainParticipant Topic TypeSupport Publisher & DataWriter Subscriber & DataReader QoS 功能测试 性能测试 优势 能够在系统级环境下验证 DDS 软件的功能和性能，不仅能够检验 DDS 中间件本身的质量问题，还能够检验 DDS 软件与操作系统、硬件平台、网络配置的兼容性等系统问题 提供界面友好的上位机软件，操作简便 不依赖底层传输技术，UDP、TCP、共享内存等均适用 100% 国产自主知识产权 应用领域 针对 ECU (Electronic Control Unit) 的 DDS 协议测试 DDS 软件在特定的 ECU 计算平台下运行，在工控机中搭建仿真节点，与被测 ECU 建立通信 适用于研发早期阶段，可以脱离特定硬件环境和特定网络配置，在比较纯净的环境下验证 DDS 软件的核心功能，以及 DDS 软件与特定 ECU 操作系统和硬件平台的兼容性 针对完整 DDS 分布式系统或子系统的测试或性能评估 DDS 软件在特定的 ECU 计算平台下运行 适用于集成测试阶段，验证不同计算平台之间的兼容性，DDS 与下层网络配置的兼容性，如 VLAN、防火墙、TSN 约束、5G 等，以及性能测试 支持的平台 DDS Tester 目前支持 POSIX 兼容的操作系统，如 Linux、Android、QNX 等，其他平台需要特殊定制开发。

聚焦中国车载以太网市场发展的最新热点与痛点分析，AES 2023第四届中国国际汽车以太网峰会于2023年6月8日-9日在上海盛大举行。北汇信息应邀发表专题演讲，与各位参会的专家和嘉宾共同探讨DDS协议测试策略和分享实践成果。 DDS是OMG在2004年发布的中间件协议和应用程序接口（API）标准，它为分布式系统提供了低延迟、高可靠性、可扩展的通信架构标准。DDS目前在工业、医疗、交通、能源、国防领域都有广泛的应用，随着SOA在汽车行业的应用，以DDS及SOME/IP为代表的中间件技术得到日益关注和逐步应用。 北汇信息的测试专家王昊天发表了主题演讲《DDS协议测试策略探讨和实践》。基于北汇信息多年来对ECU测试策略的研究和实践，以及DDS的长期跟踪研究，我们认为对DDS中间件进行功能和性能测试是有必要的。因此，北汇信息与南京臻融软件科技合作开发了DDS协议测试套件，该产品能够在特定系统环境下验证DDS中间件的功能和性能，以及不同的DDS产品之间的互操作性。 实践出真知，不论是开源DDS还是商用的DDS，在汽车上应用时，都有缺陷或者不支持的特性存在，可能会影响整个分布式系统。此次AES峰会上，王昊天还重点探讨了DDS实践中的各种实际问题，与会专家进行了热烈探讨。 除本次分享的DDS协议测试，北汇信息已经落地实践了若干DDS相关的测试开发项目，包括基于OEM定制需求的DDS通信测试、S2S测试、DDS应用类测试，欢迎垂询探讨！