标签: TSN

在传统网络中，一旦某个节点“罢工”，数据只能靠重传来恢复连接。但这对实时性要求极高的业务（如自动驾驶、工业控制）来说，简直是“致命伤”——延迟几毫秒，就可能引发严重后果。如何让数据传输既可靠又准时？TSN网络中的IEEE 802.1CB协议应运而生，它像一位聪明的“快递员”，通过“双包裹策略”确保数据必达。今天，我们将通过实际测试，揭开这项技术的神秘面纱！ 一、IEEE 802.1CB的核心：FRER机制 想象一下，你寄出一份重要文件，快递员为了确保万无一失，同时将文件复制了两份并派出两辆快递车走不同路线。即使一条路堵车，另一条也能准时送达——这就是CB协议中帧复制与删除（FRER）的精髓。 帧复制 ：数据包被复制成多份，通过不同路径传输，形成“成员流”。 帧删除 ：接收端根据编号识别重复包，只保留最早到达的“正版”，避免数据冗余。 无缝切换 ：即使某条路径故障，其他路径仍能保证业务不中断，真正实现“零感知切换”。 图1 FRER帧复制与删除原理示意图 如图1所示：FRER机制像双车道，冗余传输保障可靠性。 二、IEEE 802.1CB协议FRER机制测试的重要性 在工业自动化、智能车联网等高实时性业务场景中，数据传输的可靠性与低延迟是核心诉求。传统网络依赖重传机制保障可靠性，但重传引入的延迟波动难以满足毫秒级实时控制需求。IEEE 802.1CB协议提出的帧复制与删除（FRER）机制，通过冗余传输与智能去重技术，为关键业务构建了“双保险”架构。测试FRER机制的必要性主要体现在以下方面： 1、验证冗余传输的鲁棒性。 通过复制数据包并经由独立路径传输，FRER可规避单点故障风险。测试需验证设备能否精准实现帧复制与路径分发，确保在部分链路中断时，冗余路径仍能无缝接管流量，实现零感知切换。 2、确保去重机制的准确性。 接收端需基于唯一序列号（R-TAG）快速识别并剔除重复帧，避免冗余数据占用带宽或引发逻辑冲突。测试需严格验证序列恢复与解码功能，确保输出流量无冗余且时序一致，满足业务对数据完整性与确定性的严苛要求。 3、检验故障隔离能力。 当部分成员流出现异常（如序列重复或路径拥塞）时，系统需具备独立恢复能力，及时隔离问题流并维持正常数据传输。测试需模拟异常场景，验证设备能否动态调整转发策略，保障复合流的纯净性与可用性。 4、兼容性与扩展性验证。 工业网络环境复杂，需支持多流识别模式（如MAC、VLAN、IP）及多级冗余中继。通过测试验证设备在不同拓扑下的“接力”复制与恢复能力，确保技术适配多样化部署需求。 三、测试实战：四大功能验证 为了验证设备的FRER能力，我们搭建了专业的测试环境，使用信而泰BigTao220 测试仪与TSN交换机，模拟真实网络场景。以下是核心测试环节： 1. 序列生成与拆分：数据的“分身术” 图2 CB协议序列生成、编码和拆分功能测试拓扑示意图 如图2所示，本测试旨在验证设备基于IEEE 802.1CB协议的FRER机制能否实现数据流的冗余复制与唯一标识功能。测试通过模拟正常业务流量（Non-FRER）输入，激活交换机的FRER功能后，检测其是否具备以下核心能力： 流量复制： 将原始数据流动态拆分为两条独立成员流，确保每条流携带全局唯一的R-TAG标签（含序列号、路径标识等元数据），并通过不同物理端口输出，形成冗余传输路径； 标签生成： 在帧头中准确插入R-TAG标签，为接收端提供去重与路径识别依据，同时避免破坏原始数据载荷的完整性； 路径独立性： 确保两条成员流严格遵循预设的异构传输路径，规避单路径故障对业务连续性的影响。 在测试仪Renix软件中查看CB Stream Statistic统计，可以看到Port1端口发送了100个数据包至Port2和Port3，由于DUT FRER配置开启，Port2和Port3分别接收到了100个冗余数据包，即有R-TAG标签的数据包。 查看Port2和Port3端口的捕获报文情况，数据包均被打上R-TAG标签。 2. 序列恢复与解码：数据的“去重大师” 图3 CB协议序列恢复和解码功能测试拓扑示意图 如图3所示，本测试基于冗余消除机制原理，采用对比分析法验证网络设备的流合并与数据去重功能。通过构建双流并行传输模型，由测试仪同步发送两条R-TAG标识相同的成员流至被测交换机，模拟真实网络中的多路径传输场景。测试过程中重点验证设备对重复数据包的识别算法、标签剥离处理机制及复合流重构能力。通过接收端流量统计与数据校验双重验证，证实交换机在完成标签剥离后输出流量规模精准缩减50%且数据完整性达标，有效验证了设备基于流量特征识别的智能去重机制和业务流还原能力，符合链路聚合场景下消除冗余传输的技术规范要求。 在测试仪Renix软件中查看CB Stream Statistic统计，可以看到Port1和Port2端口分别向Port3端口发送了65536个数据包，即，共计131072个数据包，由于有R-TAG标签的存在，因此有65536个数据包是重复的。两条成员流经过DUT时，通过CB协议进行序列恢复和解码，由于DUT上使能了Terminate参数，其会将R-TAG头剥离后在发送给目的端口，所以将Port3最终共计收到65536个非冗余数据包。 查看Port3端口的捕获报文情况，数据包均未被打上R-TAG标签 3. FRER序列复制：网络的“接力赛” 本测试基于数据包多路径分发原理，采用压力测试与流量复制模型相结合的方法，验证网络设备在复杂组网环境下的流复制与中继转发能力。通过构建单流输入多端口输出模型，由测试仪构造携带R-TAG标签的成员流注入交换机，模拟网络节点间数据帧拆分重组的关键场景。测试重点验证设备的标签解析逻辑、流量复制算法及多端口同步转发机制，通过预设配置触发交换机的智能复制功能，实现数据帧的精准拆分与重组转发。最终通过多端口流量统计、数据完整性校验及传输时序分析三重验证，确认所有目标端口均获得完整有序的数据序列，且无丢包或乱序现象，证明设备具备符合网络架构要求的智能流量中继能力，满足复杂网络拓扑中数据高效分发的技术标准。 场景一： 图4 CB协议FRER序列拆分功能测试拓扑示意图 如图4所示，携带R-TAG标签数据包被拆分后正常转发。 在测试仪Renix软件中查看CB Stream Statistic统计，可以看到Port1端口发送了65536个数据包至Port2和Port3，由于DUT FRER配置开启，Port2和Port3分别接收到了65536个冗余数据包，即所有Sequence_number的FRER成员流均可被复制转发。 查看Port2和Port3端口的捕获报文情况，两个端口均可收到Sequence_number从0至65535的复制报文。 场景二： 图5 CB协议FRER序列恢复功能测试拓扑示意图 如图5所示，携带R-TAG标签的两条FRER成员流数据包被精准去重后正常转发。 在测试仪Renix软件中查看CB Stream Statistic统计，可以看到Port1和Port2端口分别向Port3端口发送了65536个数据包，即，共计131072个数据包，由于有R-TAG标签的存在，因此有65536个数据包是重复的。两条成员流经过DUT时，通过CB协议进行FRER序列恢复，由于DUT上未使能Terminate参数，其会携带R-TAG标签做数据转发，所以此时Port3最终共计收到65536个冗余数据包。 查看Port3端口的捕获报文情况，数据包均被打上R-TAG标签，且Sequence_number是唯一的。 4. 独立恢复功能：故障的“紧急隔离” 图6 CB协议成员流单独恢复功能测试拓扑示意图 如图6所示，本测试基于流冗余消除（FRER）机制的原理，通过模拟数据链路层异常场景验证交换机的故障隔离能力。采用主动注入式验证策略，通过测试仪在特定成员流中构造携带R-TAG标签的重复序列报文，模拟传输层异常；继而通过DUT的FRER检测引擎对接收报文进行序列号比对分析，验证其是否具备实时识别重复序列的算法能力；最终评估设备对异常流的处置逻辑是否符合IEEE 802.1CB标准要求，包括异常包的精准识别、选择性丢弃以及正常数据流的无损转发等关键指标。 在测试仪Renix软件中查看CB Stream Statistic统计，可以看到Port1向Port2端口发送了65536个数据包，由于该成员流会重复发送2次，因此会有32768个数据包，R-TAG标签中的Sequence number是重复的。该成员流经过DUT时，由于DUT使能了Individual独立恢复功能，所以此时Port2最终共计收到32768个冗余数据包。 查看Port2端口的捕获报文情况，数据包均被打上R-TAG标签，且Sequence_number是唯一的。 四、测试意义：为工业、车载等网络戴上“安全帽” 通过上述测试，我们验证了设备在冗余传输、快速去重、故障隔离等场景下的可靠性。对于工业自动化、智能电网、智能车联网等场景，这意味着： 零丢包： 关键数据永不丢失，保障产线稳定运行。 低延迟： 无需重传，实时控制指令直达设备。 高兼容性： 支持多种流识别模式（如MAC、VLAN、IP），适配复杂网络环境。 IEEE 802.1CB协议如同为网络装上“双引擎”，既提升了可靠性，又兼顾了效率。随着TSN（时间敏感网络）技术的普及，这项“双保险”机制将成为工业4.0、车联网的基石。下次当你看到无人车间流畅运作时，别忘了背后有一群“隐形快递员”，正在用FRER默默守护每个数据包的安全！ 时间敏感网络 (TSN)具备大带宽、通用以太协议及精准网络KPI控制的技术优势，可满足工业网络日益数字化、智能化的技术需求。TSN作为下一代工业网络技术演进方向已经在业内形成共识。而任何一种技术的成熟和广泛采用，一个强大而专业的测试工具必不可少。 信而泰BigTao220便携式机框是公司推出的新一代研发类测试机框。它采用模块化设计，提供2个插槽，支持从10M到800G多种速率的测试模块（含TSN测试模块）任意组合，其可以针对汽车以太网和工业以太网等提供TSN协议测试解决方案。

01 概述 随着嵌入式系统日益复杂，高效可靠的设计工具变得愈发重要。RTaW公司的仿真工具RTaW-Pegase最新发布的4.6版本，为用户带来了一系列重要更新和功能增强。本文将详细介绍RTaW-Pegase v4.6版本的主要更新内容，涵盖了DDS、SOME/IP、Ethernet、CAN以及SDV等多个关键领域的改进。无论您是汽车电子、航空航天还是工业自动化领域的专业人士，相信这些更新都将为您的工作带来显著的效率提升和设计优化。 02 v4.6版本更新内容 2.1.DDS 1)建模DDS实体、LatencyBudget和DeadLine QoS策略 2)域参与者与网络节点之间的Mapping 3)DDS消息和Ethernet帧（TCP/UDP）的Mapping 4)自动生成Topic到帧映射（多播或多个单播） 5)仿真和WCTT分析 甘特图展示DDS网络传输行为 6)服务方法请求和响应之间的细化延迟建模 2.2.SOME/IP 1)在ServiceSet窗口的“Properties”页面中添加了“Data Rate”列 2)支持SOME/IP TP 2.3.Ethernet 1)拓扑窗口的“Load”页面中添加了“Link Load Details”链路负载详细信息子页面 2)ARXML导入程序的改进 3)YANG-XML导出已更新 4)添加了通过NETCONF导出配置的选项 5)在AS帧生成过程中，交换机中的分配节点会自动生成 2.4.CAN 1)FrameFlows页面和CAN总线窗口中添加“Show Transported PDU”菜单 2)CAN总线窗口的数据帧表中添加“Cumulated”负载列 3)dbc导入器配置的各种改进：保存并加载配置文件、创建延迟约束的参数、忽略TxMode的选项和更多默认值 4)事件和混合到达模型中添加事件以重复周期发送的形式 2.5.SDV 1）对可执行程序的执行和时序链延迟的仿真轨迹进行各种校正和改进 2）支持对OSTasks和计划的可执行程序添加时延约束 03 联系我们 如果您想体验RTaW-Pegase最新版本带来的便利，欢迎联系我们申请试用，marketing@polelink.com。 北汇信息⼀直致⼒于TSN设计与验证的实践⼯作，近六年积累了丰富的TSN项⽬经验。参与多个国内TSN项⽬，拥有完整的TSN设计、仿真、原型构建的开发经验，同时为客户提供⻬备的TSN测试⼯具链与验证⽅法。

欢迎关注虹科，为您提供最新资讯！ #TSN #时间敏感网络 #虹科PCIe网卡 导读 在当今快速发展的工业自动化和智能制造领域，时间敏感网络（TSN）正成为连接各个智能设备的核心技术。虹科TSN-PCIe网卡，作为市场上首个即用型TSN解决方案，为构建高效、可靠的工业通信网络提供了强大的支持。 虹科RELY-TSN-PCIe网卡 想象一下，如果通信网络能够像时钟一样精准，每条信息都能在预定的时间内准时到达，那将会怎样改变我们的通信世界？虹科RELY-TSN-PCIe网卡，正是这一构想的实现者。在本篇QA指南中，我们将深入探讨这款革命性产品的核心特性，解答您可能遇到的疑问。 01 虹科TSN端点的结构是怎样的？ 虹科PCIe网卡在端到端的传输当中，充当数据调度和调节收发的作用。虹科PCIe设备本身，通过PCIe接口与用户的主机（CPU端）相连，面对各种复杂多样的算法，往往数据的计算都是由主机CPU来进行计算和操作。而端到端之间的数据传输是用户主机（CPU）将计算的控制命令通过PCIe接口向设备的Port1/2进行发送出去，同理对于接收到的控制命令也是通过Port0/1向PCIe端口转发给用户主机（CPU）。 面对复杂多样的各种类数据，用户主机（CPU）需要对不同种类的数据进行规划编程，或者分类（VLAN），规划为TSN当中的8种不同类别的数据流量。或者可以由虹科PCIe网卡本身将用户主机的流量以一种TSN类别发送出去。 在操作上，虹科TSN网卡可以做到 赋予数据流量的时间敏感的调度 。但网络数据的负载，还是需要用户在用户主机（CPU）定义应用程序，将设备当成一个普通网卡，先保证数据能相互传输，再利用虹科PCIe设备内部的Web进行协议的设置，使得数据传输遵循TSN传输。 02 如何部署和使用虹科TSN-PCIe卡？ 具体是要根据TSN需求，以及所需要的 时隙配置 。端到端的情况下，比如在不采用TSN调度情况下，网络在多流量传输下， 遵循优先转发原则 ，可能会导致部分流量丢失，以及延迟和抖动情况大多在ms级别的发生，因为无法按照用户确定性时延的去转发。 当采用TSN门控机制下，保证网络特性情况下（即对应的帧率需要保证门控带宽能够无丢包），设置us级别的门控，比如第一个门控100us内，此门控传输控制类别1，3，4三种，第2个门控150us传输控制类别2，6，那么对于这三种流量的传输结果，以一个周期转发为例，延迟和抖动都是在用户可确定的范围内，延迟和抖动都是在门控范围以内（通常实际只有几us的抖动，并且速率也高，情况越是良好），这就是TSN的确定性网络的由来。 03 TSN端点具备哪些独特优势？ 虹科TSN-PCIe网卡 可用作 PCIe TSN 端点和 TSN 桥 ，提供 2 个多媒体千兆以太网端口和 2 个内部端口。作为端点，它提供了 在托管设备中引入 TSN 技术的可能性 ，以便将其集成到确定性网络中。PCI Express（PCIe）是扩展性最强的高速串行计算机扩展总线，它是 PC 计算机中扩展板的实际标准，并且正在获得工业PC 甚至SCADA系统的认可。 在探索时间敏感网络（TSN）的实现方案时，结合I210网卡和Linux系统的TSN补丁是一个切实可行的方法。尽管I210网卡本身可能并不具备丰富的TSN功能，但通过在搭载这些网卡的设备上应用开源的Linux TSN补丁，可以扩展其功能，尽管这可能需要相当的工作量。 虹科的TSN网卡在这方面展现出了其独特的优势。它不仅 支持市面上广泛使用的多种协议，而且采用了基于PCIe板卡的创新结构——ARM-CPU与FPGA的结合 。在ARM侧，我们实现了一个经过优化的Linux TSN补丁包，与FPGA中的TSN协议交换结构相互配合，共同确保了TSN协议的高效数据调度。通过PCIe接口上的I210网卡，这些网卡能够与搭载设备（如工控机）进行通信，无论搭载的是Windows、Linux还是VxWorks操作系统，用户只需配置相应的网卡驱动，即可实现即插即用的便利性，轻松部署确定性以太网网络，同时将技术复杂性从用户设备和应用程序中抽象出来。 更进一步，虹科的TSN解决方案在协议配置上也进行了创新。它不再依赖于传统的命令行方式，而是提供了一个直观的Web GUI页面，使用户能够通过图形界面进行配置，这大大简化了TSN协议的设置和管理过程，提高了用户体验。 04 TSN端点的二次开发潜力如何？ 对于TSN IP的端点方案而言，虹科除了提供FPGA 代码形式TSN方案，还包括ARM侧的Linux软件组件包，便于客户集成TSN 端点方案。同时保持 行业内协议数量和性能的领先特性， 从开发层面来说，一站式的TSN解决方案帮助客户克服了很多时间和开发难题；从产品最终形态而言，产品带来的用户体验感好，协议性能上具备一定的市场优势。 我们的TSN协议是用FPGA实现的，以IP封装的形式存在，在赛灵思的MPSOC上做的系统集成，硬件设备都是集成好的标准品，如果想改协议确实只能走IP这条路径。 如果是应用层面的话，硬件设备是非常支持用户对协议参数的可调整，比如QBV本身的时隙大小可设置，周期性传输中队列的可调整，出入帧的优先级设置等等，但对于协议本身来说，它自身的实现的方式是固定好的，所以说协议本身的算法机制是无法从现有标准品对其进行改变，从而实现二次开发的目标。 结语 欢迎访问https://www.intelnect.com/category/technical-article/了解更多虹科技术文章！

简介 作为全球专业的TSN网络分析及测量解决方案提供商，TSN Systems公司的主打产品TSN CoreSolution是专为时间关键型网络设计的全面解决方案，提供了一个完整的生态系统，旨在满足区域架构开发和验证的需求与挑战。它结合了硬件（如TSN Box）和软件（如TSN Tools）组件，为全球OEM厂商和一级供应商提供了应对未来系统和网络挑战所需的全面支持。 随着TSN技术获得越来越多的关注和广泛应用，TSN Systems公司推出了一款入门级的解决方案 TSNBasicSolution，通过简化的方式为用户提供关键功能，基于硬件与软件的无缝集成，帮助您提升生产力，更快实现目标并且有效应对复杂的任务和分析需求。 TSN CoreSolution包含了完整的TSN工具集（如TSN Tools、TSN API、TSN Scripts）以及硬件支持（如TSN Box），为用户提供了全方位的时间关键型网络支持。而TSN Basic Solution则是一个简化版，专注于提供基本功能，结合了除TSN Box之外的其他硬件和TSN Tools Basic，适合需要核心功能但不需要全部高级功能的用户。 TSNBasicSolution TSNBasicSolution提供六种硬件选择，您可以根据需要选择其中一种，并与TSN Tools Basic软件结合使用。TSN Tools Basic是TSN Tools的基础版本，通过TSN Tools核心的数据分析功能，帮助您在工作中更加高效，快速达成目标。 TSN Switch 10G 10G汽车交换机专为TSN以太网设计，提供超高速数据传输和强大的网络稳定性。无论是在实验室还是在实际应用中，该交换机都能帮助您实现卓越的连接性能。 TSN Switch 1G TSN Systems Q50 2.0 1G是一款非常灵活的AVB/TSN交换机，适用于实验室、车辆或硬件在环（HiL）测试。它配备了多个端口，能够应对各种网络配置需求，确保在不同应用场景中提供最佳性能。 TSNAP TSNAP是一款集成数据记录和网络接入功能的设备，适用于测试台、车辆或硬件在环应用。它设计简洁、操作便捷，能够在各种环境中灵活使用，满足多样化的数据记录需求。 TSN SMC 10G TSN SMC 10G是一款高性能的智能媒体转换器，专为实验室、车辆和硬件在环（HiL）测试环境而设计。它支持多种高速网络连接，包括2500/5000/10000BASE-T和2500/5000/10000BASE-T1接口，能够实现数据的透明传输，不会丢失或过滤任何数据包。因此，TSN SMC 10G非常适合使用gPTP或TSN协议的时间敏感应用。所有设置都可以直接在设备上手动调整，无需使用PC，操作直观简便。 TSN SMC 1G TSN SMC 1G是一款紧凑、灵活的媒体转换器， 适用于多种测试环境。它不仅能够无缝转换1000BASE-T和1000BASE-T1网络连接，还支持100Mbps的传输速率。TSN SMC 1G非常灵活，所有设置都可以直接在设备上手动调整，无需额外的PC配置。这使得它在各种时间敏感型应用中都是理想的选择，确保数据传输的可靠性和准确性。 TSN Timepiece TSN Timepiece是一款精确的时间同步设备，可以接收全球导航卫星系统（GNSS）信号，并将其时间信息转换为IEEE 802.1AS-2011标准，确保以太网网络的同步性。 TSN Tools Basic TSN Tools Basic包含了TSN Tools的核心功能，能够为您提供多种数据分析和可视化工具，帮助您在时间敏感网络设计中轻松应对各种需求。 TSN CoreSolution 和 TSN BasicSolution 功能对比表 结论 本文对TSNBasicSolution解决方案进行了简介，您可以根据实际情况选择不同硬件与软件组合来应对网络通信中的复杂需求，实现卓越的系统性能，在提升工作效率的同时，为保证系统正确可靠的运行提供保障。 北汇信息在车载网络通信领域拥有多年的丰富经验，已为众多整车厂和供应商提供了TSN技术的咨询与测试服务。我们凭借成熟的解决方案和专业的技术团队，能够满足您在网络通信架构集成与测试验证方面的各种需求。期待与各位读者进一步交流，共同推动智能汽车技术的发展。

软件定义汽车对网络通信技术的影响 图 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 等技术的咨询和测试服务，拥有成熟的解决方案和专业的技术团队，能够满足客户在软件定义汽车网络通信架构集成和测试验证等方面的各种需求，期待各位读者与我们进一步交流。