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

欢迎关注虹科，为您提供最新资讯！ #时间敏感网络 #TSN #时间感知整形器 导读 本文旨在验证时间敏感网络（TSN）中时间感知整形器（TAS）的性能，通过实施IEEE 802.1Qbv和IEEE 802.1AS-2020标准测试用例，确保其在网络中的准确性。我们选用了虹科RELY-TSN12和虹科RELY-10TSN12设备作为待测对象，并利用Calnex公司的Paragon-X与Keysight公司的Novus ONE PLUS测试台进行全面评估。文章将详细介绍测试流程、配置、设置以及关键的测试结果，展示TAS在控制抖动和防止窗口违规方面的实际表现，为您提供深入了解TSN技术应用的窗口。 图1 测试设置 在某些应用和行业中，确保高优先级数据帧在预定时隙内准时传输至关重要。时间感知整形器（IEEE 802.1Qbv）保障了控制数据在规定时隙内的准时传输，同时维持了可接受的抖动和延迟。本文旨在 验证时间感知整形器的性能 ，通过分析结果来监测窗口违规并评估抖动，确保网络通信的准确性和可靠性。 01 时间敏感网络的最新发展 以太网在航空航天和国防领域的通信应用日益增多，其中 时间敏感网络（TSN） 作为确保通信准确性的关键技术，正迅速成为主流。TSN通过时间感知整形器（TAS），基于IEEE 802.1Qbv标准，实现了 网络流量的周期性分配 ，并通过设置优先级窗口来控制数据包的传输顺序。 为了实现网络节点间的精确时间同步，IEEE 802.1AS-2020同步协议被引入，保障了 纳秒级别的时间一致性 。尽管TSN技术尚属新兴，但行业组织如Avnu以及技术公司虹科SoC-e、Keysight（Novus ONE PLUS）和Calnex（Paragon-X）正在积极开发必要的测试计划和工具，旨在验证TSN设备的性能、标准合规性以及不同设备间的互操作性，从而推动这一技术的发展和应用。 02 被测设备平台 虹科TSN交换机架构如图2所示，其核心功能包括Rx接口端口接收的帧从电信号到数字信号的转换，以及交换矩阵引擎基于MAC地址表和VLAN配置进行帧路由。出口数据包处理模块依据IEEE 802.1Qbv标准对输出缓冲区的帧进行排序，确保它们在预定时间窗口内正确转发。该模块与1588计时器（IEEE 802.1AS-2020）同步，保障了Tx端口的精确时隙转发。 图2 虹科IP Core架构 虹科SoC-e平台采用 AMD Xilinx Ultrascale＋MPSoC系统 ，其中处理系统（PS）负责软件处理，而可编程逻辑（PL）基于FPGA实现交换和TSN功能。 PS通过虹科SoC-e的定制Linux发行版进行配置，该系统内嵌了设置交换和TSN功能所需的命令，并通过内部端口与PL系统通信，实现PL寄存器的配置。图3展示了完整的虹科RELY-TSN-BRIDGE＋10TSN12 TSN交换机架构。 图3 虹科RELY-TSN12 本次测试选用了两款设备：基于MTSN IP核的虹科RELY-TSN12（1Gbps）和基于TSN TGES IP核的虹科RELY-10TSN12（10Gbps），以评估不同速度下的TSN性能。 03 测试设备配置 交换机配置可通过CLI、Netconf或Web界面进行， 本测试选择Netconf来设置IEEE 802.1Qbv和VLAN ，而IEEE 802.1AS-2020同步协议则通过Web界面配置。 IEEE 802.1AS-2020配置 本测试的主要目的是精确评估IEEE 802.1Qbv的性能， 重点检查窗口违规情况和测量帧的抖动 。为此，必须确保待测设备（DUT）与测试站之间达到纳秒级的同步。 我们将使用Paragon-X测试设备来精确计算DUT的接收（Rx）和发送（Tx）延迟，并通过迭代调整，最小化PPS（脉冲每秒）差异，确保与测试站的同步。完成这些校准步骤后，DUT将连接到Novus ONE PLUS测试站，并配置IEEE 802.1AS-2020协议。在此配置中，DUT的第一个端口将作为主端口，第二个端口作为从端口，同时配置发送优先级为7的数据包，验证同步协议的准确性。 IEEE 802.1Qbv与VLAN配置 我们将使用Netconf协议对DUT进行IEEE 802.1Qbv和VLAN配置，确保测试的精确性。 测试将覆盖100M、1G和10G三种速度 ，其中虹科RELY-TSN12设备将用于100M和1G测试，而虹科RELY-10TSN12设备将用于所有三种速度的测试。 统一的VLAN配置将应用于所有测试速度，确保PORT1和PORT2均属于VLAN2，以此隔离测试流量，避免网络干扰。DUT的端口将设置为PVID1、PCP0、DEI0，允许所有入站帧（无论是否带标记）以指定的出站标记进行中继。 此外，将为VID2创建专门的VLAN表项，将PORT1和PORT2纳入其中，并从VLAN1中移除，以进一步精细化流量管理，为测试提供清晰的网络环境。 IEEE 802.1Qbv标准专门用于管理前向出口流量，本测试案例中将针对端口2进行配置。配置过程需根据网络速度进行差异化设置。以下是针对1Gbps速度下端口2的IEEE 802.1Qbv配置细节： 图4 IEEE 802.1-Qbv配置 配置确保每个队列在每个周期内仅在其分配的时间段内传输流量，同时设置了缓冲间隔以防止流量超出预定时间窗口，确保在此间隔期间不会转发流量。 对于 100M，配置有以下差异： Cycle time: 10000000ns Base time: 0s and 0ns Time intervals changes from 100000ns to 1000000ns and from 25000ns to 250000ns 对于 10G，配置有以下差异： Cycle time: 100000ns Base time: 0s and 0ns Time intervals changes from 100000ns to 10000ns and from 25000ns to 2500ns 图5 1G 的 IEEE 802.1Qbv 配置 Novus ONE PLUS测试站配置 为确保测试结果的准确性，Novus ONE PLUS测试站需经过精心配置。 本测试涉及构建两个具备以太网和精确时间协议（PTP，IEEE 802.1AS-2020）功能的拓扑结构 ，其中拓扑1充当主设备，拓扑2作为从设备。关键配置参数包括点对点（P2P）延迟机制、多播设置、域编号0、优先级设置为128，以及时钟类别6。 完成IEEE 802.1AS-2020的同步配置后，接下来将定义八个具有不同优先级的流量流，以模拟和测试网络在不同服务等级下的表现。 图6 Novus ONE PLUS 流量配置 测试连接设置 为确保测试的准确性，本测试需完成两个关键设置：首先，DUT需与Paragon-X设备相连，通过端口1对端口1的直接连接和PPS同步，精确计算传输延迟。 图7 Paragon-X测试设置 图8 IEEE 802.1Qbv Novus ONE PLUS 测试设置 04 测试结果分析 预期结果 本测试的核心在于验证IEEE 802.1Qbv的抖动控制和窗口合规性。为确保精确测量，测试站(Novus ONE PLUS)与待测设备(DUT)之间的同步偏移需控制在特定范围内：1G速度下不超过100纳秒，10G速度下不超过50纳秒，100M速度下不超过500纳秒。Novus ONE PLUS将记录统计数据以检查并确认这一偏移量。 取得成果 测试首先确认了DUT与测试台（Novus ONE PLUS和Calnex）之间的同步精度。利用Calnex设备，我们计算并记录了同步误差，确保了在不同速度下的测量均在可接受范围内。进一步地，Novus ONE PLUS用于检查持续同步的一致性，并确认了DUT能够正确识别测试站为主站（GM）。 接下来，通过开发的Python脚本，我们检查了IEEE 802.1Qbv的窗口合规性。脚本利用Novus ONE PLUS记录的时间戳，确保每个帧都严格在其分配的时隙内到达。结果显示， 所有帧均未出现窗口违规，表明IEEE 802.1Qbv配置正确，抖动控制稳定 。 图9 IEEE 802.1Qbv结果 图10 延迟结果 图9和图10分别展示了不同速度和优先级下的抖动结果和存储转发延迟结果。数据显示， 在所有测试条件下，系统均表现出良好的性能，抖动和延迟均符合预期 。 图11 AS基准下队列门控窗口 图12 不良AS同步 最后，为了凸显IEEE 802.1AS-2020同步协议的重要性，我们还进行了100%帧速率的测试，人为制造同步失败的情况。结果如图12所示， 缺乏同步导致帧在错误时隙到达，引发窗口违规，从而证明了精确同步的必要性 。 结语 本次测试成功验证了虹科RELY-TSN12和虹科RELY-10TSN12设备的TSN功能，以及正确配置TSN的重要性。 测试结果证实了IEEE 802.1AS-2020和IEEE 802.1Qbv在控制抖动和防止窗口违规方面的有效性 。此外，测试还突出了同步在TSN网络中的核心作用。 作为更大TSN测试计划的一部分，本次测试为进一步的IEEE 802.1AS-2020和IEEE 802.1Qbv测试奠定了基础。未来的工作将继续深化对这些标准的理解，并探索它们在更广泛场景中的应用。 虹科是一家在通讯领域，尤其是汽车电子和智能自动化领域拥有超过15年经验的高科技公司，致力于为客户提供CAN/CAN FD、LIN、车载以太网、TSN等全方位的一站式智能互联解决方案。