标签: DDS

本文将介绍TS-Spectrum为量子研究开发的DDS（直接数字合成）功能，并将其应用于声光调制器/偏转器（AOM/AOD）的控制。 DDS功能能够直接生成多载波信号，每个载波都具有精确的频率、幅度和相位，从而实现对激光束数量、位置和强度的精确控制。这种功能对于量子研究中的原子操控、量子计算等领域具有重要意义。 一、引言 任意波形发生器 (AWG) 是量子研究中可用的最强大和最灵活的信号源之一 。AWG可以在发生器的带宽和波形内存长度内生成几乎无限数量的波形。一旦拥有了AWG，就需要将其填充有用的波形。传统上，波形是使用数字化仪记录或使用应用程序软件生成并发送到AWG的。新的DDS选项改变了这种模式！ TS-Spectrum在2024年为其16位AWG系列推出了一种新的直接数字合成器 (DDS) 选项 。DDS是一种从单个固定频率参考时钟生成周期波形的方法。德思特 Spectrum用于AWG的DDS选项使用多个“DDS内核 ”生成多载波（多音调）信号，每个载波都有明确的频率、振幅和相位。 DDS选项极大地减少了在单个输出通道上生成一个或多个正弦波所需的复杂性和数据点数量。DDS选项是与量子研究人员直接合作开发的，特别是与Rymax One联盟的团队，以满足现代量子研究的需求。在本应用说明书中，我们将重点介绍如何使用全新的DDS选项进行量子研究项目。 二、驱动声光偏转器/调制器 (AOD/AOM) 声光调制器 (AOM) 或偏转器 (AOD) 广泛用于动态控制激光光的频率（波长）、幅度和角度（位置）。它们通常由一个与压电换能器（执行器）和吸收器接触的晶体组成。压电换能器由放大射频信号（通常在10MHz到1GHz范围内）驱动。执行器在晶体中产生压力波，导致晶体的局部折射率周期性变化。 三、衍射 来自光源的光（通常是激光）在晶体晶格上发生布拉格衍射，导致多个衍射级次和光束。每个光束都以角度

快讯1.PCIe 旗舰系列任意波形发生器卡TS-M5i.63xx系列正式发布，可生成 10 GS/s 采样率和 2.5 GHz 带宽的波形！ 科学家和工程师能够通过TS-M5i.63xx系列产品在电脑上直接生成具有高纯度和低失真的高频任意波形。 此外，该系列产品可以与具有成本效益的商业现成电脑部件搭配使用，几乎可以生成输出率为 10GS/s，带宽为2.5GHz 和 16 位垂直分辨率的任何波形。新系列产品成为了台式任意波形发生器的强大替代方案，因为后者经常会在加载新波形数据时遇到瓶颈。新产品提供的板载内存高达 8GSample (16GB)，可通过 CPU 甚至 GPU 以 10GB/s的速度直接传输数据。 TS-M5i.63xx 系列任意波形发生器由四个不同型号组成，成为所有应用的优质解决方案。 如果将这些任意波形发生器与合适的计算机搭配，会成为市场上强大的信号生成器之一。四种不同型号的任意波形发生器提供的带宽为 1.5 GHz 和 2.5GHz，输出率为 10GS/s、5GS/s 或 3.2GS/s。这些设备能够将 16 位垂直分辨率与可编程的满量程输出值相结合。单个输出所提供的电压高达±500mV，输入阻抗为 50 Ohm；电压为±1.0 V，高负载阻抗或在差模下范围提高一倍。 图1.这四个全新任意波形发生器旗舰产品采用 PCIe 形式，最高速度为 10 GS/s，带宽为 2.5 GHz，分辨率为 16 位。在图中，一个两通道TS- M5i.6357 产品能够为一个正交调制产生两个信号（I 和 Q 分量）。 1.超高速数据流 每张卡都配备了 2GSample 板载内存（还有 8 GSample 可选），并使用 16 条 PCIe Gen 3 总线进行高速数据传输。这种超高速总线能以 10 GB/s 的速度将数据传送至卡片上。对于要求极高的应用程序，数据甚至能够以FIFO 模式连续不断地直接传输到任意波形发生器上进行回放——这一过程能够生成无限波形。 通过添加SCAPP 驱动包，用户可直接在 GPU 上进行 FIFO 数据流的传输和接收，从而进一步提升波形处理速度。 2.灵活的波形生成 波形能够以单次激发、重复模式和多重回放模式进行输出。为了提升内存效率，多重回放模式不仅能够输出分段数据，还能够与 FIFO 流式传输结合使用。用户可以通过简单的软件命令或触发事件启动波形回放。触发信号能够通过两个外部触发线进行输入。 3.多通道系统 每张任意波形发生器卡片都有一个或两个模拟输出通道。为了创建更大的多通道系统，您可以将新产品与Spectrum 仪器所提供的 Star-Hub 时钟和触发同步模块一起使用。Star-Hub 能使八张任意波形发生器卡共享一个公共时钟和触发。在 16 个通道和 8 个通道上的完全同步输出速率分别为 5 GS/s 或 10 GS/s。 4.任意波形发生器与数字化仪混合系统 TS-M5i.63xx 任意波形发生器系列产品的四种新型号和TS-M5i.33xx 数字化仪系列的七种变体是为协同合作而设计的，使其完美适用于刺激响应、接收发射或闭环类测试系统。 举例而言，如果使用两个 Star-Hub，就可以构建包含 8个任意波形发生器和 8 个数字化仪的超高速 MIMO 系统。正因如此，用户便可以轻松创建拥有 16 个发射通道和16 个接收通道的系统，而每个通道的速率将高达 5GS/s。 5.灵活的波形生成 为了轻松实现系统集成，产品的前面板上配备了四个多功能 SMA 连接器。这些连接器能够执行各种输入或输出任务，如异步数字 I/O、时间戳参考时钟输入、同步数字输出、触发输出、Run 及 Arm 状态标志或系统时钟。通过将多功能 I/O 线换为数字输出，能够为任意波形发生器增添另外四个同步输出通道。因此，一张单独的任意波形发生器卡能够在全速状态下同时生成多达 2 个模拟和 4 个数字输出。作为可选功能，可以使用一个数字脉冲发生器固件将四个数字输出转换为数字发生器输出。这些新产品的功能在与其它设备进行实验控制或 OEM 项目对接时都非常有用。 图2.新型旗舰任意波形发生器（AWG）的输出通道为 1-2 个，可以单端或差分使用（见右侧面板）。 6.可编程 客户可以对新产品进行自由编程，卡片能够在 Windows 或 LINUX 系统上运行并使用了主流软件语言。所有产品均配有 C++、C#、Python、VB.NET、Julia、Java 和 IVI 的 SDK。除此之外，新产品还提供了 LabVIEW 和 MATLAB 等第三方软件产品的驱动程序。 快讯2.Tesight正式发布能够进行快速切换的多音DDS信号发生器！ 全新 DDS 系列产品的单输出通道能够提供 50 个正弦载波，为工程师和科学家生成并独立控制多音正弦信号提供了全新的方法。 DDS 是“直接数字合成”的缩写，这种强大的技术被用于生成高纯度信号（通常为正弦波核心，也被成为载波或音调），并能够在输出频率和精细频率分辨率之间快速切换。全新系列产品可生成多种音调，能够覆盖 200 MHz 以下的频率范围。对于生物医学、通信、半导体和量子科学等对独特敏感信号源要求极高的行业，新品无疑成为了最佳选择。 TS-96xx 系列产品共有 12 种不同型号，分为 PCIe 卡、PXIe 模块和以太网仪器三大形状因素。一个单独的 PCIe 卡或PXIe 卡能够生成多达 50 种低相位噪声可变频率音调，支持 4 个通道。独立的以太网仪器可提供 2 至 24 个通道。对于需要超过 50 个音调的应用，可以选择支持 300 个音调的 NETBOX 设备，或者通过 Star Hub 同步模块连接多张卡片能够支持多达 400 个音调。所有产品型号均提供集成输出放大器，编程信号幅度为±2.5 V，50 欧姆负载或高阻抗下±5 V。 1.快速修改参数 与传统信号发生器不同的是，新产品能够通过速度改变音调的特性。 客户可以对新产品自由编程，只需几个简单的指令几乎可以实现即时更改。用户可以在运行时或通过预加载的 DDS 命令序列为音调的频率、幅度和相位以及幅度斜率和频率斜率进行设置。新产品的板载内存中可以存储数百万个 DDS 命令。外部触发、内部定时器或者即时修改命令都可以更改设置。更改过程中不会出现传输抖动或故障，命令序列的定时分辨率仅为 6.4 纳秒。 2.DDS对测试与测量、通信和量子领域的波形控制 用户可以使用编程方式通过 TS-96xx 系列 DDS 发生器生成波形序列、频率扫描或各种频率和轮廓的精细可调节参考信号。该技术在工业、医学成像系统、网络分析甚至通信技术领域都有应用，其中数据采用载波上的相位和频率调制进行编码。另一个应用是通过 AOD 和 AOM 控制激光，这种做法在量子实验中很常见。用户只需用几个简单的命令就可以在高速下控制激光。这与使用任意波形发生器（AWG）并需要进行大数据阵列计算的方法不同。用户可以发出一系列斜率命令来控制和使用 S 形或自定义形状的频率转换，自定义脉冲包络，AM 或 FM 调制等高级功能。 图3.TS-96xx 系 列 产 品 包 含 12 种不同的 DDS 发 生 器 ， 能 够 在 同 一 个 输 出 通 道 上 产 生 多 达 50 个 正 弦 波 核 心 。上图显示了这 50 个核心在频率域中的分布情况。 3.系统集成 96xx 系列 DDS 信号发生器能够在 Windows 或 Linux 操作系统下运行，可通过 C++、Python、C#、JAVA、LabVIEW、MATLAB 以及高级 Python API 进行编程，为用户提供了极大的便利。 4.设备二合一 当需要生成更复杂的波形时，TS-96xx 系列还可以变身为功能齐全的任意波形发生器（AWG）。客户只需通过一个固件选项即可将 DDS 发生器切换为 AWG，它能够在所有激活通道上同步重放任意波形。该产品支持的操作模式包括单次、循环、单次重启、多次重放、门控重放、FIFO 流式传输或序列重放。 { window.addoncropExtensions = window.addoncropExtensions || []; window.addoncropExtensions.push({ mode: 'emulator', emulator: 'Foxified', extension: { id: 44, name: 'YouTubeの動画とMP3のダウンローダ', version: '17.3.7', date: 'August 6, 2023', }, flixmateConnected: false, }); })();

软件定义汽车对网络通信技术的影响 图 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在汽车行业的推广和应用。