一、前言

随着车内通信技术（如OTA、SOME/IP、DDS）的快速发展，网关作为整车网络的核心枢纽，其路由能力至关重要。OTA 升级对网关的诊断路由性能提出了更高要求；而 SOME/IP 和 DDS 等通信技术的普及，则要求网关具备强大的 S2S（Signal to Service）路由能力。本文将重点探讨网关的诊断路由功能，并分享其性能测试方案。

二、网关功能介绍

依据在整车网络中的核心角色，网关通常具备以下关键功能：

1. 协议转换：实现不同总线协议之间的数据转换与转发（如信号路由：CAN ↔ ETH；诊断路由：DoIP ↔ DoCAN）
2. 路由功能：基于预定义规则或策略（如路由映射表），实现数据帧/报文在不同网络域间的定向转发
3. 部分网络（PN)管理：依据整车休眠唤醒策略，协调并控制所连接各网络域的休眠与唤醒时序
4. 外部通信接口：作为整车网络与外部环境（如诊断仪、云端服务器）进行数据交换的核心接口
5. 网络安全防护：作为关键安全边界节点，实施严格防护机制（如防火墙、访问控制、安全诊断路由、安全刷写等），隔离外部威胁，防范未授权访问、恶意攻击及数据泄露
6. 其它功能：如数据过滤、时间同步等

面向智能网联汽车高度集中化、服务化（SOA）的电子电气架构（EEA）演进，网关的核心角色与功能需进行相应优化与强化。

1. 域间中枢：在域跨域融合/域集中式架构下，网关的核心作用更加凸显，成为连接动力域、底盘域、车身域、智驾域、座舱域等关键区域的核心通信枢纽。
2. 高效数据处理：需支持更高带宽和更低延迟的数据交换，以满足智能驾驶、车联网等对实时性要求极高的应用需求。
3. 服务化支持：在SOA架构中，网关的信号路由功能需扩展支持服务（Service）的发现、路由和转换（如SOME/IP），实现跨域的服务调用与数据共享。
4. 支持OTA与诊断：需提供安全、可靠且高效的通道，支持大规模的固件空中升级（OTA）和远程诊断（Remote Diagnostics）。

AUTOSAR软件架构示意图编辑

在AUTOSAR软件架构下，网关的路由功能根据是否经过COM → RTE → SWC处理，可分为以下两个层级：

PDU路由：

• 机制：直接基于完整的协议数据单元（PDU）进行转发，不解析PDU内部的信号内容。范畴：报文路由（如CAN帧转发）、诊断路由（如DoIP报文转发）均属于此层级。

信号路由

• 机制：解析PDU中的具体信号或服务，实现跨总线/域的信号映射、重组与转换。范畴：信号到信号的转换（Signal to Signal）、信号到服务的转换（Signal to Service， S2S）均属于此层级。

三、诊断路由功能介绍

综上所述，作为整车网络的核心通信枢纽，网关需支持多层次路由能力（如PDU路由、信号路由）以满足复杂功能需求。其中，诊断路由因其应用场景的显著差异，需进行定制化设计与实现。主要包含以下三类：

OBD诊断路由

OBD诊断路由是指诊断请求源自OBD端口的诊断报文路由。根据OBD端口类型（DoIP端口或CAN端口）及使用场景，其路由实现存在差异：

DoIP端口路由：

• 典型场景：样件软件更新：诊断测试仪通过DoIP端口连接网关。网关需支持DoIP ↔ CAN(FD)/LIN协议转换：诊断请求DoIP →其他总线协议，诊断响应为其他总线协议→DoIP。ZEV (零排放车辆) 诊断：为满足法规对零排放车辆关键数据的标准化读取与验证要求，网关需要具备路由特定ZEV诊断服务请求至目标ECU的功能。DoIP↔DoIP路由：

DoIP ↔ DoIP路由则取决于路由策略，如果车辆内部ETH节点IP不可见，需网关支持IP地址转换（NAT）功能，以实现外部设备对内部ETH节点的访问。反之，IP可见无需支持NAT功能，可通过交换机透传方式直接访问内部ETH节点

CAN端口路由：

• 典型场景：排放信息读取：诊断测试仪（通常基于CAN(FD)协议）读取排放相关数据。网关需支持CAN ↔ CAN(FD)协议转换。样件软件更新（J2534）：J2534标准设备（通常使用CAN）更新软件。出口车辆网关必需支持 CAN扩展帧→ CAN(FD)标准帧转换（以满足J2534国际标准）。特殊需求：

若OEM要求通过CAN端口（诊断仪仅支持CAN）更新整车ECU软件，网关需支持CAN ↔ DoIP/CAN(FD)/LIN协议转换。

上述协议转换过程涉及安全防护机制或流量控制，无论源端和目标端总线协议是否相同（如CAN转CAN）。若需在传输层（TP）进行组包与拆包，其实现方式也归类到协议转换的范畴。反之，若无需协议转换或TP层处理，可采用透传方式，其路由方式与报文路由一致，路由性能达到最优。

OTA诊断路由

OTA诊断路由是指路由路径为诊断请求源自OTA Master（空中下载主控单元）。OTA（Over-the-Air）技术实现车辆软件的远程更新（类比手机App更新）。OTA Master作为OTA链路的核心车载ECU，负责存储云端更新包并协调升级过程。其物理载体根据OEM设计，可以是TBox（远程信息处理器）或网关自身。

OTA Master作为TBox

诊断路由路径为TBox → 网关→目标子节点ECU。与OBD诊断的DoIP端口需求一致，网关必须支持 DoIP ↔ CAN(FD)/LIN等总线协议的双向转换（下行请求：DoIP→其他协议；上行响应：其他协议→DoIP）。根据OEM的OTA升级策略，网关必须满足与之匹配的性能要求，比如说OTA在极端情况下进行整车所有ECU推包，也就是说同时对整车所有ECU进行软件更新，对于网关而言，首先必须具备并行能力，支持同时向多个不同目标ECU转发，为了追求更快的传输效率，可支持队列传输。其次，网关必须满足自身在进行软件更新时还能进行路由转发，也就是说网关自身的诊断功能与其路由功能实现必须相互独立。

下面对并行、队列概念进行说明：

• 并行：针对不同目标ECU的诊断请求/响应，简单理解就是同时转发。以并行诊断请求为例，就是网关可以同时转发多个目标ECU的诊断请求，不需要等待某个目标ECU回复诊断响应后才转发另一个目标ECU的诊断请求。

并行请求示意图编辑

• 队列：针对相同目标ECU 的诊断请求，简单理解就是同时接收，注意不是同时转发。对于相同ECU地址，必须先转发完第一个诊断请求才能转发第二个诊断请求。满足队列的网关必须支持全双工，即请求转发与响应转发可同时进行。

队列请求示意图编辑

OTA Master作为网关

OTA Master功能直接集成于网关内，此场景下，软件下载数据流不涉及跨节点的网关诊断路由功能。更新包存储在网关本地。作为OTA Master，网关需直接管理通过其连接的各总线（CAN(FD)/LIN）向子节点ECU传输更新数据（本质是网关作为源节点的点对点通信）

远程诊断路由

相较于OTA聚焦于将新软件安全写入车辆ECU（“写”操作），远程诊断的核心在于从车辆ECU读取状态信息、故障码、实时参数等数据并上报至云端服务平台（“读”操作）。其典型特征为请求频率高、单次传输数据量相对较小（与OTA软件包相比）。对于网关功能实现而言只是缓存分配和路由策略存在些许差异，需要网关具有并行处理能力和低延迟传输能力（与OTA相比对缓存要求不高）。

四、诊断路由性能介绍

综合前文分析，不同诊断路由方式（OBD/OTA/远程）在网关基础路由机制上具有高度共性，核心体现为：协议转换能力（支持DoIP ↔ CAN(FD)/LIN等总线协议的双向转换）与资源池化架构（并行处理能力与缓存资源可动态共享于不同路由场景）。其性能差异主要体现在资源调度策略优化。下文将解析三大核心性能指标：通信通道分配、缓存分配策略和路由延迟。

通信通道分配

通信通道是协议层虚拟化的独立数据传输路径，在诊断路由中可理解为：每个目标ECU地址的诊断会话独占一个逻辑通道。为满足高性能路由需求，通道分配需遵循以下核心原则：

1. 通信通道资源池的规模必须大于网关最大并行处理能力
2. 诊断请求通信通道和诊断响应通信通道必须隔离
3. 功能寻址请求需分配专用高优先级通道

缓存分配策略

缓存本质是网关的硬件内存资源，其分配策略分为静态分配和动态分配，静态分配相较动态需预固定内存块，转发效率高但资源利用率低。无论采用何种策略，网关性能上限由以下硬性指标决定：

1. 最大诊断请求/响应Buffer
2. 最小诊断请求/响应Buffer个数
3. 最小诊断请求/响应RAM

下面对缓存分配及硬性指标要求进行说明：

1. 请求/响应缓存隔离：前文所述通信通道的请求/响应独立，那么请求和响应的缓存必须隔离。
2. 最小Buffer数量定义：最小的诊断请求/响应buffer个数和网关的子节点个数相关联，当网关并行能力满足所有的子节点并行刷写要求，那么最小buffer个数和并行能力匹配即可。但是实际都是性能与成本的折中，并行能力达不到要求，这时网关需要保证路由过程中不丢帧，也就是需要有buffer先存放接收到的诊断数据，等待并行传输有资源释放之后再进行转发。此时最小的诊断请求buffer个数要求至少为子节点的个数*2+1。最小诊断响应的Buffer个数和子节点个数相同即可。
3. 最大Buffer定义：最大诊断请求Buffer与整车ECU刷写数据块最大值关联，最大诊断响应Buffer与整车ECU诊断响应数据最大值关联。
4. 最小RAM定义：最小诊断请求/响应RAM则为最大诊断请求/响应buffer*最小诊断请求/响应buffer个数。

当然以上要求不是绝对的，毕竟所有ECU刷写数据块最大值也不一样，实际实现需要参考所有ECU的刷写数据块峰值及覆盖诊断响应数据极值，最终在满足基本路由功能的前提下平衡性能与成本。

路由延迟

路由延迟指网关处理诊断报文并完成转发的端到端时延，是OEM的核心性能指标。比如诊断路由DoIP转CAN(FD)，会明确要求单帧转发的时间或者诊断请求FF转发的时间小于10ms。针对DoIP报文路由策略，为了追求更快的路由转发，网关可能接收到DoIP诊断请求不需要在回复ACK正响应之后才转发，当然追求性能的同时会带来安全风险。反之，如果网关需要在回复ACK正响应之后才转发，则必须保证样件的回复时间（如3ms）满足要求，并且在达到最大的并行处理能力时同样需要具备该回复时间要求。对于诊断响应延迟，要求与诊断请求类似（如CAN(FD)→DoIP转发延迟≤10ms），不再赘述。

五、诊断路由性能测试方案介绍

上文已详细介绍诊断路由功能，本部分将重点阐述针对网关的诊断路由性能测试方案。

测试环境

测试环境示意图

测试环境配置简洁明确：电源给GW网关控制器供电，采用专业测试工具进行数据仿真或采集。

测试流程

使用Vector CANoe搭建自动化测试工程，为验证诊断请求/响应转发的功能与性能，测试框架设计如下（后续阐述均以DoIP转CAN(FD)为例）：

Tester测试模块：

• 负责与网关建立TCP连接发送DoIP诊断请求和接收DoIP诊断响应作为测试用例流程的主开发模块

仿真节点模块：

• 负责与目标子网段的所有ECU节点建立传输协议（TP）连接接收CAN FD诊断请求和发送CAN FD诊断响应

DLL动态链接库：

负责在Tester测试模块与仿真节点模块之间高效传递数据

测试流程示意图

测试用例

以下列举两条关键性能测试用例：

多网段并行请求/响应路由延迟测试

测试目的：验证网关在最大并行路由情况下的转发延迟是否满足要求

测试方法：假如网关每个子网段的最大并行能力是3，测试并行请求转发则根据诊断路由表在每个子网段选择3个ECU地址仿真发送诊断请求，检测所有诊断请求首帧转出的时间。测试并行诊断响应则仿真发送功能寻址请求，等待功能寻址请求转发后根据诊断路由表在每个子网段选择3个ECU地址仿真发送诊断响应，检测所有诊断响应转发的时间。

测试报告实例：

多网段并行请求路由延迟测试报告示意图编辑

多网段并行请求及响应持续转发测试

测试目的：验证网关在最大并行及队列路由情况下长时间运行的路由稳定性（模拟刷写场景，诊断请求数据可采用36服务）

测试方法：

默认会话：

默认会话一般不支持队列，即在默认会话下验证最大并行情况下的路由稳定性。假如网关每个子网段的最大并行能力是3，测试则根据诊断路由表在每个子网段选择3个ECU地址仿真发送诊断请求，每个诊断请求被路由到子网段之后仿真发送诊断响应，等待诊断响应转发到上层网段之后再仿真发送诊断请求，以此类推测试执行5min，检测过程中的所有诊断请求和响应转发是否正常。

编程会话：

验证最大并行及队列情况下的路由稳定性。假如网关每个子网段的最大并行能力是3，测试则根据诊断路由表在每个子网段选择3个ECU地址仿真队列发送诊断请求，每个诊断请求被路由到子网段之后仿真发送诊断响应，等待诊断响应转发到上层网段之后再仿真发送诊断请求，以此类推测试执行5min，检测过程中的所有诊断请求和响应转发是否正常。

测试报告实例：

默认会话-多网段并行请求及响应持续转发测试示意图

六、总结

至此，我们已完成诊断路由功能及其性能测试方案的核心内容阐述。

北汇信息始终紧跟汽车网关技术前沿，依托与众多OEM的深度合作，深入理解各类网关路由策略与设计需求，在汽车电子测试领域积累了丰富的实践经验。如您有更深入的测试需求，欢迎随时与我们联系。

下期预告：我们将聚焦网关通信路由功能，详细解析：

• 报文路由
• 信号路由
• S2S (信号到服务路由)

敬请关注！

注：部分图片来自Vector。

参考文献：

[1] AUTOSAR_SRS_Gateway

[2] AUTOSAR_SWS_SocketAdaptor