标签: 车载通信

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

1、服务概述 汽车工业的很多领域都有严格的国际标准，其中针对车载诊断的ISO14229规定了车载诊断服务的通用需求(UDS)，UDS主要应用于OSI模型的应用层，UDS协议根据功能的不同定义了26种诊断服务。 为了应对网联汽车日益增加的安全风险，在ISO14229-1的2020版本增加了29服务。29服务英文名称为Authentication Service，译为认证服务。通过名称可以看出29服务的目的是为客户提供一种身份认证的方法。当客户想获取一些有访问限制的数据时来验证客户的身份，这些限制可能是由于安全或排放相关的原因。本文将详细介绍29服务。 29服务一般在如下场景中使用： 1. 需要读取特定内存地址的数据； 2. 上传或下载控制器数据； 3. 关于车身安全或者会影响车身控制器属性。 传统的27服务不能满足这些需求，因此新版本的ISO14229协议增加了29服务，来实现基于以太网的身份认证。 2、背景知识介绍 对称加密：加密和解密使用相同密钥的加密算法。 非对称加密：一对加密密钥和解密密钥，用户加密后所得的信息，只能用该用户的解密密钥才能解开。如果知道了其中一个，不能计算出另一个。公开的加密密钥为公钥，不公开的解密密钥为私钥。 PKI：PKI的全称是Public Key Infrastructure，译为公钥基础设施。PKI是包括硬件、软件、人员、策略和规程的集合，用来实现基于公钥密码体制的密钥和证书的产生、管理、存储、分发和撤销等功能。用来建立不同实体间的“信任”关系。 3、服务介绍 29服务支持两种认证方式，如下图所示： APCE: 采用非对称加密的基于PKI证书交换程序的认证 ACR: 采用对称或非对称加密的基于挑战确认（Challenge-Response）流程的认证 。 图1-29服务支持的两种认证方式 3.1 APCE认证流程 图2-APCE的认证流程图 上图是APCE的认证流程图，包括单向认证和双向认证。 3.1.1单向认证 Client通过V erifyCertificateUnidirectiona l(2) 向Server发送带有Client公钥的证书。 Server收到证书后会验证证书的有效性(3)，如果Client不合法，则停止流程，验证失败，返回否定响应，如果合法则继续之后的流程。 Server创建Challenge(4)，并向Client发送针对证书的Challenge消息(7)，请求Client对所发证书的所有权证明，消息中包含认证所需的随机数。 Client收到Challenge后使用私钥计算所有权证明客户端(10)，并且通过SubFunction ProofOfOwnership(11)发送所有权证明客户端。 Server使用来自Client的公钥验证所有权客户端(12)，与Challenge消息比较，如果验证成功，则根据访问权限(14)，授予对诊断对象的访问权限。并向Client发送相应的响应,表示认证成功。 3.1.2双向认证 Client创建Challenge客户端(1)，并通过SubFuntion Vertify Certificate Bidire- ntional向Server发送Challenge客户端和含有公钥的证书客户端。 Server验证证书是否有效(3)，如果无效，则验证失败，返回否定响应。如果有效，则进行后续的流程。 Server创建Challenge服务端，并且通过客户端发来的Challenge和自己的私钥计算出所有权证明(6)，并向Client发送Challenge服务端、服务端证书、服务端的所有权证明以及临时公钥(7)。 Client根据所得的临时公钥验证服务器证书和所有权证明是否有效(8)，有效之后根据服务端发来的Challenge和客户端私钥计算客户端所有权证明(10)，并通过ProofOfOwnership向Server发送客户端所有权证明(11)。 Server收到所有权证明后进行验证是否通过(12)，通过后发送访问权限(14)以及相应的响应(15)，认证成功。 图中(5)，(9)跟安全诊断通信有关，(16)，(17)，(18)跟创建会话密钥有关。 3.2ACR认证流程 图3-ACR的认证流程图 3.2.1ACR认证前提条件 非对称加密：具有客户端密钥对：客户端存在客户端私钥，服务器中存在客户端公钥。如果是双向认证的话，还需要在服务器端加个密钥对：客户端存在服务器公钥，服务器端存在服务器私钥。 对称加密：和27服务的流程相似，在客户端和服务端同时存在对称密钥。 3.2.2单向认证 Client通过RequestChallengeForAuthentication请求验证(1)。 Server创建Challenge数据(2)并发送Challenge数据(3)。 Client计算所有权证明(5)。 Client通过VerifyProofOfOwnershipUnidirectional发送所有权证明(7)。 Server验证所有权证明(8)，如果验证成功发送访问权限。 其中(14)，(15)，(16)是关于建立会话密钥使用的。 3.2.3双向认证 Client 通过SubFunction R equestChallengeForAuthentication请求验证 (1) 。 Server 创建Challenge数据(2)，并且发送Challenge数据(3)。 Client 创建Challenge数据(4)，并且计算 Client 所有权证明，并通过VerifyProofOfOwnershipBidirectional发送给服务器端(7)。 Server 验证所有权证明(8)。 如果验证成功， Server 计算所有权证明(9)，并且发送访问权限(11)。 Client 验证服务器的所有权证明(13)，如果验证成功，访问成功。 3.3子功能介绍（部分） 表1-29服务部分子功能 4、CANdelaStudio中配置29服务 在CANdelaStudio中打开CDDT文件，选择Protocol Service,在这里可以对29服务的请求和响应的格式进行编辑。 图4-29服务编辑 打开CDD文件，在Base Variant下选择Authentication，就可以对29服务的参数进行编辑。 图5-29服务参数编辑 在States下Dependencies可以配置每个服务在各个状态下的支持情况。 图6-服务状态编辑 5、CANoe中29服务的实现 以CANoe中29服务的Demo工程为例，来介绍29服务的认证过程。 图7-29服务Demo工程 在诊断控制台中可以看到关于29服务的一些子功能。每个子功能都有不同的作用，每个认证方法的区别在于发送的子功能不同。可以根据上面的流程来决定使用哪些子功能，例如要用APCE单向认证方法的话，发送29 01和29 03服务，APCE双向认证的话发送29 02和29 03服务。用哪一个认证方法是OEM自定义的。 图8-29服务子功能 Security Open Security Manager，在这里就可以导入关于29服务的文件（X.509）。 图9-29服务配置 在设置好29服务文件后，在Security Configuration就会显示刚才创建的文件，将证书和通道匹配好后就可以发送29服务。 图10-29服务证书和通道匹配 在Panel面板中，可以发送29服务，选择单向认证或者双向认证。发送之后在Trace中可以查看认证的过程。 图11-29服务Panel面板 6、总结 29服务和27服务的功能比较相似，都是为了防止ECU的数据和软件安全受到威胁，但是27服务提供的安全机制已经不能满足现在车辆诊断功能面临的新的安全威胁，29服务就是为了弥补这些缺陷而产生的。 由于27 服务 的安全访问控制手段缺乏灵活性，29 服务 引入了PKI和证书认证体系，可以灵活地给诊断的参与者分配权限 ,29服务还适用于多客户端，在车辆网联化共享化的趋势下很好的应对了这些新的安全威胁。 北汇信息专注于其汽车电子网络通信、诊断刷写、逻辑功能测试开发服务，期待进一步沟通交流、共享合作的机会。 参考文献：ISO14229-1(2020) 注：图片部分来源于ISO14229-1(2020)、CANoe16、CANdelaStudio18

现如今，随着汽车电子的发展，串行通信在ECU上也被广泛应用，我们常见的串行通信有：RS485、RS232、PSI5、SPI等，每一种串行通信都有其自身的特点。本文主要就基于VT2710实现SPI仿真进行相关的介绍。 V T2710 介绍 VT2710是Vector 旗下的一款串行通信板卡。VT2710 提供一套测试ECU或传感器串行通信通道所需的接口。该模块可用于模拟总线通道上传感器和ECU的行为。此外，还可以监控串行总线上的通信。VT2710可用于控制试验台上的外围设备。 如下图所示，VT2710模块可以同时处理两组串行接口，包括汽车传感器相关的PSI5和SENT接口。以及支持通用型数字接口，SPI，I2C，UART，RS232，RS422，RS485或LVDS等诸多通信协议。下面，将就基于VT2710实现SPI仿真的方式展开讲解。 图 1- VT2710 串行通信卡 SPI SPI，是串行外设接口“Serial Peripheral Interface”的简写，这是一种全双工同步串行的通信协议。 图 2-SPI 多从机模式 SPI通信原理其实很简单，要需要至少4根线，它们是MISO（主设备数据输入）、MOSI（主设备数据输出）、SCLK（时钟）和CS/SS（片选）。 MISO（ Master Input Slave Output）：主设备数据输入，从设备数据输出； MOSI（Master Output Slave Input）：主设备数据输出，从设备数据输入； SCLK（Serial Clock）：时钟信号，由主设备产生； CS/SS（Chip Select/Slave Select）：片选线，用于多从机时主设备与从设备进行选择。当主设备要和某个从设备进行通信时，主设备需要先向对应从设备的片选线上发送使能信号，（大多数是将电平拉低），表示选中该从设，主芯片对此从芯片的操作才有效。 图 3- 通信过程 其通信过程也很容易理解。首先，主设备发起片选信号，将CS/SS拉低（一般情况），启动通信。然后，主设备通过发送时钟信号，来告诉从设备进行发数据或者读数据的操作。值得关注的是，通信过程中有四种数据采样的模式，由极性（CPOL）和相位（CPHA）来决定，CPOL为“0”则代表时钟信号空闲时为低电平，为“1”则空闲时为高电平，相位的“0”、“1”则分别代表在第一个跳变沿传输数据和在第二个跳变沿传输数据。以上极性和相位排列组合为以下四种模式： C POL=0,CPHA=0 ：空闲时低电平，第一个跳变沿发数据 C POL=0,CPHA=1 ：空闲时低电平，第二个跳变沿发数据 C POL=1,CPHA=0 ：空闲时高电平，第一个跳变沿发数据 C POL=1,CPHA=1 ：空闲时高电平，第二个跳变沿发数据 图 4- 四种工作模式 主设备发送片选信号选中从设备，并且发送时钟信号后。紧接着主机（Master）将要发送的数据经MOSI信号线发送给从机（Slave），从机也将数据经MISO信号线返回给主机。SPI通信协议还具有高速传输、简单灵活、支持和多从设备的连接，具有较高的灵活性、双向通信、低功耗的特点。 以上就是SPI的基本通信原理，下面介绍一下上位机软件配置。 在上位机软件—CANoe中，有一个SPI Basic的示例工程。在File→Sample Configurations下的SPI Basic工程中，可以实现SPI基础的传输接收等基本通信。下面简单介绍一下该工程的使用和配置。工程位置如下图所示。 图5 -SPI B asic工程 首先，将Master和Slave的MISO、MOSI、CS、SCLK对应连接。打开示例工程，确认通道是否匹配好。启动工程，在对应的输入窗口下输入数据即可完成收发。 图 6-SPI B asic工程实例 关于SPI的配置都在Hardware窗口下的Protocol Configuration Sensors模块下。 图 7-SPI 配置 icon Master配置： 1）Clock polarity when idle:指空闲时的SCLK极性 2）Clock frequency:指时钟频率 3) Wait after CS active : 主机通过CS选中从机后的等待时间 4）Wait before CS inactive : CS片选在待命状态下的等待时间 图 8-M aster配置窗口 Slave配置： 1）General Setting:此模式选择项包含Low Active和High Active，Low Active用于一般复杂度的通信需求，High Active用于高复杂度的通信需求。 2）Clock Setting：极性和相位选项，CPOL为极性，CPHA是相位。 图 9-S lave配置窗口 至此，就是我们在上位机软件中的示例工程以及对Master和Slave的一个基本的配置。 S PI 多从机模式的配置： 保证主机、从机连接没有问题，在上位机软件CANoe的Hardware窗口下的Protocol Configuration Sensors模块下，右击Master→Add Slave，具体参数的配置参照上文即可。值得关注的是，每块VT2710可以提供2个独立通道的四线SPI通讯，最多支持5路片选，两个通道至多可支持10个从机。 图1 0-S lave添加 图1 1-S lave 菊花链 在一个主机和多个从机的SPI 系统中，通常采用专门的片选信号来寻址从机。随着从机数量不断增加，片选线也随之增多。 这种情况将给电路板带来很大的挑战。这时候，使用菊花链的连接方式是更好的选择。 菊花链，顾名思义，这种连接方式就像是花环，进行通信的过程中，在设备信号以串行的方式从一个设备依次传到下一个设备，不断循环直到数据到达目标设备的方式被称为菊花链。在菊花链的SPI系统中，只采用一个SS (或者CS) 信号，所有从机接收同一个时钟信号。只有链上的第一个从机(SLAVE 1) 从微控制器直接接收命令。其他所有从机都从链上前一个从机的输出引脚获得其数据。要保证菊花链正常工作，每一个从机就必须能在给定的命令周期读入命令，而在下一个命令周期从数据输出引脚输出同样的命令。 图10为菊花链连接方式。在菊花链模式下，各个从机一个接一个地连接起来。主机通过所有连接的从机传输数据。为此，主机的MOSI输出连接到第一个从机的MOSI输入，下一个从机的 M ISO 再连接到下一个从机的MISO，以此类推。最后一个从机的MISO输出再次连接回主机。所有从机的芯片选择信号在这里相互连接。采用菊花链的连接方式，优点在于节约空间，释放总线压力。缺点就是因为是信号串行传输，所以一旦数据链路中的某设备发生故障的时候，它下面优先级较低的设备就不可能得到服务了。 图1 2- 菊花链的连接方式 B MS 系统中菊花链实例 目前，国内的BMS设备主要分为两种。第一种是以分布式架构为主，BMS分为主板和从板，主从板上都有微型的控制器，用作收集从板采集到的电池电压和温度数据 ，通过CAN总线传给主板。第二种是采用菊花链技术的BMS集中式架构。这种架构只在BMS主板上保留微控制器，原本的从板改成单纯围绕AFE芯片功能的小板，AFE采集的信息通过差分隔离信号的方式直接传送给主板。主板完成BMS主要的保护和电池管理功能。 图1 3- 传统方式到菊花链的演变 BMS的主板上的微控制器连接SPI串行通信接口，通过通信转换芯片将信号转换为差分信号。主板以差分信号的形式与第一个从板进行通信，差分信号从第一个从板出来后，依次进入后序的从板，这样主板最终得以与所有从板通信。菊花链在BMS系统中就是作为这样一个主、从板之间的桥梁而存在。菊花链的仿真可以基于 VT的 FPGA板卡实现， 通过Simulink构建菊花链仿真模型并运行在FPGA板卡中，从而实现用菊花链的方式完成主板从、板之间通信的功能。 总结 VT2710是一款为ECU和N个数字传感器提供硬件接口的功能型板卡。希望通过本文的介绍，大家对VT2710串行通信板卡和SPI通信协议有了更深入的了解。如果您对VT2710板卡亦或是SPI通信协议或者想要了解更多相关内容，欢迎咨询北汇信息，感谢观看！ 北汇信息作为Vector中国的合作伙伴，始终专注于汽车电子领域的新技术和新产品，为整车厂和零部件企业提供完整的研发、测试解决方案，为工程师在汽车领域提供“趁手装备”！我们不仅提供相应的工具和技术支持服务及培训，还针对不同的应用提供相应的解决方案，助力中国客户的研发效率提升。欢迎联系北汇信息，我们将根据不同需求为您提供针对性的高效、灵活、稳定的解决方案！

概述 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 等，其他平台需要特殊定制开发。