标签: 网络通信

5G网络是第五代移动通信技术的简称，它相较于前一代通信技术，具有更高的数据传输速率、更低的时延、更大的连接密度和更好的用户体验。5G网络的主要技术特点包括大规模天线技术、网络切片技术、超密集网络等，这些技术使得5G网络能够满足未来物联网、智能制造、自动驾驶等领域对高速、低时延、高可靠性的通信需求。 5G网络通信有哪些技术痛点？ 5G网络通信经过多年的高速发展，仍有一些技术痛点未能解决，其技术痛点主要包括网络覆盖范围与信号质量、高频段通信与设备兼容性、关键技术不够成熟以及核心器件依赖进口等方面。 网络覆盖范围与信号质量：5G网络在高频段下的传输距离相对较短，覆盖范围有限，且在建筑物密集或地形复杂的区域，信号穿透能力差，导致信号质量不稳定。 高频段通信与设备兼容性：5G使用的高频段使得设备间的兼容性问题更加突出，不同厂商之间的技术标准差异可能导致设备互操作性差。 关键技术不够成熟：尽管5G技术已经取得了很大进展，但在某些关键技术方面仍不够成熟，如大规模天线技术、网络切片技术等，这些技术的稳定性和效率尚未得到充分验证。 核心器件依赖进口：我国在5G核心器件，如高频段射频器件、高端芯片等方面的研发和生产能力与国际先进水平相比仍有一定差距，导致在关键器件上依赖进口。 光耦技术在未来网络通信的创新应用 光耦技术在解决这些5G网络通信的技术痛点方面可以发挥的创新应用： 提高信号质量与稳定性： 光耦具有优秀的电气隔离性能，能够有效地隔离噪声和干扰，提高信号的传输质量和稳定性。在5G基站和终端设备中，光耦可以应用于信号传输路径上，减少信号衰减和失真，提升网络覆盖范围和信号质量。 促进设备兼容性： 光耦作为一种标准化的接口器件，可以实现不同厂商设备之间的互连互通。通过采用统一的光耦接口标准，可以降低设备间的技术壁垒，提高设备的兼容性和互操作性。 弥补关键技术不足： 光耦在高速数据传输和电气隔离方面具有独特优势，可以作为辅助技术手段来弥补当前5G关键技术的不成熟之处。例如，在网络切片技术中，光耦可以实现不同切片之间的隔离和传输，提高网络的安全性和可靠性。 推动核心器件国产化： 光耦作为一种国产化的器件，其研发和应用有助于推动我国5G核心器件的自主创新和产业发展。通过加大光耦等核心器件的研发力度，可以降低对进口器件的依赖，提高我国5G产业的自主可控能力。

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

一 . 引言 在当今快速发展的汽车行业中，车载以太网正逐步成为推动汽车智能化、网联化浪潮的核心技术之一。作为传统以太网技术在汽车领域的创新应用，车载以太网不仅继承了以太网的开放性、成熟性和互操作性，还针对车辆特有的环境和需求进行了优化与定制，为车载内部的复杂数据传输提供了高速、可靠、低延迟的通信平台。 在复杂的车载网络拓扑中，主机间通信最初只知道目标设备的IP地址，那如何获取目标设备的MAC地址呢，这就不得不提到一个关键协议——ARP协议。 二．ARP概念 ARP协议（Address Resolution Protocol，地址解析协议）在车载以太网中的作用与传统以太网中作用相同，是一种网络层协议，在网络世界中扮演着至关重要的角色，它就像是网络中的地址翻译官，负责将网络层的IP地址转换为数据链路层的MAC地址。 三．ARP工作原理 当主机A向主机B发送数据包时，会经过以下几步： ARP缓存查询：主机A首先会在自己的ARP缓存表中查找主机B 的IP地址对应的MAC地址，如在缓存表中存在映射关系，则将IP数据包封装成以太网帧并发送给主机B。 ARP请求广播：如果主机A在本地ARP表中查询不到主机B对应的MAC地址，主机A会以广播方式发送一条ARP请求报文，ARP报文中源IP地址和MAC 地址为主机A的IP地址和MAC地址，目标IP地址是主机B地址，目标MAC地址设置为00:00:00:00:00:00 。 ARP响应：因ARP报文以广播方式发送，网段上所有主机都会接收到ARP请求，当主机B收到ARP请求后会比较自己的IP地址和报文中的目标IP地址是否相同，如果相同则回复一条单播ARP响应报文给主机A，响应报文中包含了主机B的IP地址和MAC地址，同时将发送端的IP地址和MAC地址存入主机B的ARP缓存表中。 缓存更新：主机A收到ARP应答后，将主机B的IP地址和MAC地址的对应关系存入自己的ARP缓存表中。 数据传输：主机A知道了主机B的IP地址和MAC地址，将IP数据包封装到以太网帧中发送到主机B。 四．ARP数据格式 1.以太网帧头： 目的MAC地址：占6字节，表示目标主机的MAC地址，作为ARP请求帧，目标MAC地址应设置为FF:FF:FF:FF:FF:FF; 源MAC地址：占6字节，表示源主机的MAC地址； 帧类型：占2字节，表示后面报文类型，对于ARP报文来说该字段值为0x0806； 2.ARP报文格式(以常用ARP报文为例)： 硬件类型：占2字节，表示硬件地址的类型。它的值为 1即表示以太网地址； 协议类型：占2字节，表示要映射的协议地址类型，值等于0x0800时为IPv4协议； MAC地址长度：占1字节，表示MAC地址长度，值为6； IP地址长度：占1字节，表示IP地址长度，值为4； 操作类型：占2字节，表示ARP报文类型，值等于1时为APR请求报文，值等于2时为ARP应答报文； 源MAC地址：占6字节，表示源主机的MAC地址； 源IP地址：占4字节，表示源主机的IP地址； 目的MAC地址：占6字节，表示目标主机的MAC地址，在ARP请求报文中该字段值全为0 ； 目的IP地址：占4字节，表示目标主机的IP地址； 五．报文解析示例 ARP请求报文解析示例： ARP应答报文解析示例： 六．ARP表 ARP表是主机内部的一个高速缓存表，用于临时存储IP地址和MAC地址的映射关系，可分为静态ARP表和动态ARP表： 静态ARP表：通过手工配置和维护，不会被老化，不会被动态ARP表项覆盖。 动态ARP表：动态ARP表由ARP协议通过ARP报文自动生成和维护，可以被老化，可以被新的ARP报文更新，也可以被静态ARP表项覆盖。 七：常见ARP老化过程 ARP 老化是指 ARP 缓存表中的条目在一定时间内没有使用而被删除的过程： 1. 老化时间内：当一个缓存条目在老化时间内没有被使用（即没有通过该条目发生过通信），它就会被视为过时并从ARP表中删除。 2. 更新重置：在老化时间内有新的数据包需要通过此ARP条目转发，该条目的老化周期将被重置，即其老化计时器会被重新开始计算。 3. ARP探测报文：当达到老化时间后，系统会发送一定次数的ARP探测报文，以确认该条目是否仍然有效，若探测失败，则删除该缓存条目。 八．免费ARP 当主机发送ARP请求，但请求的目标IP地址是自己本身的IP地址。这种类型的ARP不是为了获取MAC地址，而是用于更新网络中的ARP缓存、检测IP地址冲突或宣告主机更换了新的IP地址。 因免费ARP这些特性使其在DHCP(动态主机配置协议)过程中扮演着重要角色，当DHCP客户端从服务器获得了一个新的IP地址后，会发送一个免费ARP广播包，其目的是检查网络中是否有其他设备在使用相同的IP地址，如果存在另一台设备使用相同IP地址，它将响应这个ARP请求，从而客户端可以意识到地址冲突并重新向DHCP服务器请求一个新的IP地址。在此过程中确保了新分配的IP地址的唯一性，并促进了网络中的设备能迅速识别出客户端的IP地址和MAC地址映射关系。 九．总结 ARP协议是网络通信的基石之一，它的实现也需要符合特定的标准和规范（如IEEE 802.3以太网标准）。作为车载以太网相关测试人员了解ARP协议概念及原理是重要的，在车载网络中可能包含来自不同制造商的主机，它们在实现ARP协议时可能存在差异，通过测试可以验证整个网络中所有主机都能遵循相同的规则进行地址解析。同时为了提高车载网络中不同主机间的兼容性，OPEN联盟发布了相应的测试规范，其中《OPEN Alliance Automotive Ethernet ECU Test Specification Layer 3-7》文档中定义了ARP协议相关测试内容，如字段检测、动态学习、老化机制等。 北汇信息是一家专注于汽车电子测试领域的企业，对车载以太网测试有着丰富经验，并可提供相关培训、咨询服务以及测试解决方案，帮助汽车制造商和零部件供应商确保其车载以太网系统的可靠性和安全性。如果需要具体的测试服务或了解更多信息，欢迎大家来联系我们。 参考文献： 【1】《TCP/IP详解 卷1：协议》 【2】《车载以太网权威指南》 【3】《RFC 826文档》

背景 介绍 提起“匮电”二字，做测试的老司机定会虎躯一震，而根据过往经验，“网络管理”常是引起匮电的“钉子户”，所以针对网络管理的验证是测试的重中之重。 国内网络管理应用已从早期OSEK NM过渡到AUTOSAR NM，部分OEM使用了AUTOSAR NM的PN特性，本文从NM概念用途、PN的实现方式、CANoe下实现PN网络管理测试思路几个方面展开介绍。 什么是网络管理 汽车上的ECU在工作的时候需要通过网络来与其它ECU进行数据交换，而在不工作的时候需要进入低功耗状态来尽可能减少电量消耗。比如： 当拉动门把手准备使用车辆时，需某ECU接收到这个信息后在短时间能够从低功耗状态进入工作状态，并且快速地唤醒其它ECU，然后经过诸如用户认证等功能来使车辆能够被正常使用 当锁车离开后，相关ECU也需要判断这个信息，然后决定车辆需要进入非工作状态，网络通信需要被关闭且ECU需要进入低功耗状态 上述的工作循环可以概括为： 图 1 工作循环示例 而这样的网络行为正是通过网络管理来实现的。 什么是P N 网络管理 PN （Partial Network）即“局部网络”，通过一些规则（通常按照功能类）将车辆网络进一步划分为不同的“局域网”（类同于GM Global A架构中Virtual Network），通过PN网络管理处理其各种状态。 为什么需要PN 传统网络管理采用的是简单明了的“同醒同睡”的方式，但在一些场景中，我们只需要网段中有限的ECU参与工作，而不是全部的ECU，这造成了多余的电量消耗。 在ECU数量较少时还可以接受，但随着ECU的数量的增加，这个“浪费”问题就显得更为突出（当然，也可以通过设计不同的电源回路/模式控制ECU的供电等方案，但难以达到理想状态且会增加其它问题）。 PN正是通过对于网络的再次细分，在不同的场景下使不同的ECU处于工作状态，而无关的ECU仍处于低功耗状态，以达到进一步减少电量消耗的目的。 图2 PN 网络示例 NM PDU ECU请求网络以及接收到其它ECU的网络请求是通过NM PDU （Network Management Protocol Data Unit）来实现的。 以CAN网络为例，简单来说，当ECU需要请求网络时需要发送NM PDU；不需要请求网络时停止发送NM PDU。其它ECU在接收到NM PDU时，认为网络被请求。PN信息的接收发送也是类似，只是它是通过信号的形式在NM PDU中更新。 在AUTOSAR中，通常使用8个字节的数据分配给NM PDU，包含Source Node ID，CBV （Control Bit Vector）和User Data，其中User Data为用户自定义的内容，使用PN的情况下将全部或者部分User Data用于定义一组PN。 图3 NM PDU 格式 CBV包含了NM模块的一些控制信息，使用PN时需要使用Partial Network Information Bit。 图4 CBV 内容 除了上述的用于CAN/CAN FD的NM PDU外，PN网络管理还可以支持FlexRay。在FlexRay的NM PDU中，需要分为NM-Vote PDU和NM-Data PDU。CAN和FlexRay来说NM PDU有一些差异，但是其对于PN信息的处理是一样的。 状态机 ECU通过接收和发送NM PDU来传递网络管理的信息，而这些信息也决定ECU所处的状态。 以CAN通信为例，NM模块包含NM的状态机，针对ECU的通信端口，表示端口所处的网络管理状态，简单来说为网络的请求和释放。 图 5 NM 状态机 而对于PN网络来说，还包含PN的状态机，针对ECU所关联的PN，表示PN的状态，简单来说为PN的请求和释放。 图 6 PNC 状态机 而上述两者需要反馈到通信的状态上，因此还存在通信的状态机，针对ECU的通信端口，表示通信的状态，简单来说为通信的开启和关闭。 图 7 ComM channel 状态机 这些状态机需要共同作用，使ECU能正常的休眠和唤醒。当然，这个过程还 关联有其它的状态机，在此就不赘述，有兴趣的可以参考AUTOSAR的规范。 PN 网络管理测试方案 通过上述的内容，可以看到，其实PN网络管理只是在传统网络管理的基础上将PN信息添加在NM PDU中供ECU识别（当然这个说法忽略了大量细节，但就测试方案来说还可以接受）。如果被测ECU只包含1个通信端口（如1个CAN端口），我们采用的测试思路可以是： 图 8 测试方案1 然而，当ECU的复杂性增加时，这种判断的方法就变得比较困难。比如某个ECU包含2个通信端口，触发某个事件后，其网络行为可能为： 图 9 网络行为示例 这个情况在使用PN时更加常见，尤其是当这个ECU作为中央网关或将来的域控制器，需要将PN从一个网段路由到另一个网段。当然，对于单个部件的环境来说，这种行为还处于可控、有序的状态，如果放在系统级、实车环境中，先前的测试思路就会变得“一团乱麻”。 图1 0 网络行为示例2 因此必须要有新的思路和方法，北汇在长期工程实践中积累了特有的方案，借助于Vector公司的CANoe所提供灵活而强大的函数库，实现了对上述问题的“解耦”，从而解决这个“老大难”。如下为使用新方法，在CANoe环境下开发测试工程并自动生成的针对部件和系统级的测试报告。 图1 1 C AN oe自动生成 节点级 P N 测试 报告 示例 图1 2 C AN oe自动化生成P N 系统级测试 报告 示例 总结 网络管理是车载网络中非常重要也是比较复杂的内容，一方面它与功能有强相关性，不同的功能需求就可以有不同的网络行为，从而影响网络管理的状态；另一方面，网络管理本身强调逻辑，需提供足够的信息，实现与硬件接口间的交互；更困难的点在于网络管理涉及时序的控制，这就不可避免地与ECU的各种中断程序、各种随机事件耦合，会出现很多疑难杂症。 尤其是在系统层面，常会出现类似：A影响B，B影响C，C影响A，小问题累积成大问题，产生各种异常行为的情况。这也对测试规范的开发提出了更高的要求，即要验证逻辑又要覆盖场景。 随着以太网将成为主干网，随之SoA及网络动态配置应用，网络管理也将会迎来新的变化和调整。 仅以此篇文章投石问路，共同面对新的挑战。做好当下，即（不）是（畏）未来！ 注：文中部分图片来源于AUTOSAR 参考文献 AUTOSAR_SWS_CANNetworkManagement AUTOSAR_SWS_FlexRayNetworkManagement AUTOSAR_SWS_COMManager

数据中心是新基建中一个重要的基础设施，保障数据处理，信息的传输等等重大功能。 而随着信息的爆炸，数据量的陡然上升，对于数据中心的良好运行提出了更高的要求，需要数据中心拥有更多的创新和输出。 从机房整体来看，在建设选址，包括湖泊、海洋、大河或者风电供应良好区域，高原区域等等，需要有更好的供电、节能、散热的效果，微软的海底机房，阿里巴巴千岛湖机房，百度的阳泉机房都是类似的考量。中国的互联网厂商、云计算厂商和运营商在这个领域其实可以有很多创新的空间，我们跟欧美的亚马逊，微软和谷歌，facebook一样，或者 可以更好的超越这些厂家。 从通信的角度来看，数据中心之间的传输和通信，数据中心机柜之间的传输和通信，机柜内部服务器和服务器之间的通信，服务器和交换机之间的通信，更注重数据和信息传输的速度，功耗和损耗等，此部分是对于通信技术，计算机协议等部分最大的挑战。在以太网通信中，最直接的就是提高线缆COB，光模块的容量来提高性能，同时传输的协议，从PCIE到NV-LINK,长远的涉及到主板级的设计变化，芯片封装，最远的就是涉及到光通信的材料的创新，硅光子。在传输和通信领域，华为的技术是国内唯一可以同欧美厂家去抗衡的，但是在长远的领域，比如COBO封装，硅光子材料，由于国内在芯片级和材料级的创新远远落后于海外，如果没有更多国内优质厂家进入协作，未来会拉大差距。 从基础设施的角度来看，服务器的创新、存储的创新和数据中心交换机的创新是最关键核心的，服务器创新除去性能高速提升的要求，还有就是降低功耗，节能，并从机器层面去散热，单体服务器性能的提升关键是CPU,GPU,FPGA等芯片级的创新，功耗的控制大部分源于芯片架构，指令集等等创新,异构计算，虚拟化，超融合等等；存储的创新主要是架构和协议的创新，从传统的RAID，到未来 的智能网卡，分布式存储乃至超融合架构都是创新的点；交换机的创新目前主要集中在白盒化，可编程交换机、SD-WAN,SDN等整体网络架构设计方面。 节能的创新还涉及到供电方式-直流电源供电的创新；散热的创新主要是水冷方式的创新方式。 从各种前沿的技术来看，传统的芯片厂商掌握着创新的方向和技术趋势的前沿，包括博通，Marvell,麦络斯。 在网络，连接和通信上的芯片技术，传输方式包括芯片封装，硅光子材料应用；计算芯片和异构计算被英特尔，英伟达，AMD几个厂商掌握着核心的芯片技术和迭代方式；存储所涉及的软件技术，分布式存储，最早也是美国的虚拟化厂家掌握，不过国内目前也有成熟方案，不过在智能网卡基本上是被美国和以色列的领先厂家掌握。 液冷等散热的创新，欧美厂家也是处于领先地位，大规模的散热应用比如AAVID等已经有成熟方案，国内的散热厂家要不规模太小，要不专利受限，当然在这个领域，其实要超越欧美，是有机会的，需要的是资本和下游客户的合作，广东合一的喷淋式散热也是比较成熟，只是没有规模的应用起来。 未来数据中心创新的点，创新的路还很长，国内厂商如果还是停留在出货量论英雄的阶段，未来整个计算机和通信产业会长期被 欧美压制，跟随者的脚步如果方向走错，只会差距越来越远。