车载网关测试入门2【路由功能】补充1-CAN诊断路由

1 背景

我们知道车内ECU是通过CAN/LIN/Flexray/ETH等网络进行信息交互的，各类网络必须遵循各自的通信协议。如果整车某ECU需要进行故障诊断和软件升级是如何进行的？必须遵循相应协议，如ISO14229、ISO15765。
上文对CAN-CAN报文/信号路由有相关介绍；路径如下：
车载网关测试入门1-【路由功能】

1.1问题

大家带着以下问题进行本文的阅读，希望有所帮助。

1. 如何对车内ECU进行故障诊断和软件更新？
2. 不带协议转与带协议转换的诊断路由的区别？
3. 不带协议转换与带协议转换的诊断路由的测试？

2 诊断过程

汽车ECU的诊断和软件升级一般通过OBD（车载诊断系统）或者OTA连接网关实现的。
下图以OBD为例简述其过程：

外部诊断仪-连接OBD 网关 BCM 我想获取BCM的当前和历史故障信息：0x721 03 19 02 09 你当前和历史故障是啥？0x721 03 19 02 09 好的，我发你，0x729 ** 59 02 （故障信息） BCM的当前和历史故障信息为：0x729 ** 59 02 （故障信息） 外部诊断仪-连接OBD 网关 BCM

这样工程师就可以通过专有诊断设备连接OBD接口（OBD接口与网关相连）对整车所有ECU进行诊断，软件更新原理类似。因此，网关充当的是对外的接口，也是通信的核心枢纽。

备注：
图示的0x721和0x729分别为BCM的诊断请求ID和诊断响应ID；整车上支持诊断的所有ECU都会存在一对诊断请求和响应ID，这样就能通过不同的诊断ID来明确应该对哪一个ECU进行诊断或者软件升级。图示的19和59为ISO14229定义的诊断服务，此例是为了完成获取故障信息，所有用到了19服务。感兴趣的可以去查询标准，此处不做详细介绍，后续有需要可开专题详细介绍。

3 诊断路由

TP路由又称诊断路由，一共分为两类：不带协议转换的诊断路由、带协议转换的诊断路由。
什么叫协议转换，也就是发送数据和接收数据的ECU支持的通信协议不一致。比如：CAN-CANFD、CAN-LIN、CAN-ETH等。
不带协议转换的诊断路由仅转发原始报文（需总线协议一致），而带协议转换的诊断路由需适配不同总线的传输层协议。两者核心区别在于是否修改报文格式以匹配目标总线要求。

类型	不带协议转换的诊断路由	带协议转换的诊断路由
核心功能	网关直接转发原始报文，不修改协议格式。	网关解析并转换协议格式，适配目标总线要求。
适用场景	源总线和目标总线协议完全相同（如CAN到CAN）。	源总线和目标总线协议不同（如CAN到CAN FD、CAN到以太网）。
TP层处理	保留源报文TP层封装，无需修改。	需解析源TP层，按目标总线协议重新封装（如CAN TP转DoIP）。
兼容性要求	两端总线需支持相同协议版本及参数（如波特率）。	目标总线协议可独立于源总线，网关负责协议适配。

---

本文主要介绍CAN-CANFD的类型，其他类型后续专题补充。

3.1 不带协议转换的诊断路由

• 实现逻辑：
  • 网关作为“透明代理”，仅根据路由表转发原始报文（包括TP层封装），所以又称为报文透传。
  • 示例：CAN-A发送02 10 01（单帧会话控制），网关直接转发至CAN-B，格式不变。
• 优点：
  • 低延迟：无需解析和封装，转发效率高。
  • 开发简单：无需实现协议转换逻辑。
• 缺点：
  • 协议一致性要求高：两端总线必须完全兼容（如相同的TP层参数、波特率）。
  • 灵活性差：无法跨不同协议或参数的总线路由。
• 典型应用：
  • 同一车型内相同CAN子网间的诊断报文转发（如动力总成CAN到底盘CAN）。

3.2 带协议转换的诊断路由

• 实现逻辑：
  • 网关解析源总线协议（如CAN TP层），提取应用层数据，按目标总线协议重新封装。
  • 示例：
    • CAN到CAN FD：将CAN的22 ReadDataByIdentifier（读取DID-整车VIN码等）多帧请求，转换为CAN FD单帧传输（若数据允许）。
    • CAN到以太网：将ISO 15765-2报文转换为DoIP协议格式（如封装为UDP/IP报文）。
• 优点：
  • 跨协议兼容：支持异构网络（如传统CAN与车载以太网共存）。
  • 参数适配灵活：可动态调整目标总线的TP层参数（如Block Size、STmin）。
• 缺点：
  • 复杂度高：需实现多协议解析与封装，开发及测试成本高。
  • 潜在性能损耗：协议转换可能增加延迟（尤其在大数据量时）。
• 典型应用：
  • 混合架构车辆（如CAN与以太网混合网络）的诊断路由。
  • 跨代ECU通信（如传统CAN ECU与支持CAN FD的新ECU交互）。

---

3.2.1 协议转换的核心步骤（以CAN到CANFD为例）

1. 解析源协议：
   • 网关接收CAN报文，提取TP层信息（帧类型、数据长度、流控参数）。
   • 示例：解析CAN多帧请求的首帧（FF）和连续帧（CF）。
2. 提取应用层数据：
   • 将TP层分片重组为完整的应用层报文（如UDS请求22 F1 90）。
3. 适配目标协议：
   • 根据CAN FD的传输能力（最大64字节），将应用层数据重新分片：
     • 若数据长度≤64字节，封装为CAN FD单帧（SF）。
     • 若超过64字节，按CAN FD的TP层规则分片（需支持ISO 15765-2扩展）。
4. 发送至目标总线：
   • 按CAN FD的波特率和帧格式发送报文。

备注：
SF：单帧、FF：首帧、CF：连续帧、FC：流控帧；其他参数可以参考ISO15765-2；

---

4 诊断路由测试

4.1 不带协议转换

• 测试重点：测试网关转发延迟和带宽限制。
• 测试点：

• 转发值测试
  测试目的：验证是否按照客户路由表进行路由；
• 路由延时测试
  测试目的：验证是否满足客户路由延时需求；一般需求为2ms，具体以实际需求为准；
• 模拟ECU刷写测试
  测试目的：模拟刷写工况，验证是否出现丢帧；
  注意：对报文格式无强行要求；

4.2 带协议转换

• 测试重点：验证协议映射准确性（如CAN TP到DoIP的报文完整性）及极端场景（如最大数据长度传输）。
• 测试点：

• 转发值测试1
  按照ISO15765报文格式定义进行测试
  测试目的：验证是否按照客户路由表进行路由；预期：应该转发
• 转发值测试2
  不按照ISO15765报文格式定义进行测试
  测试目的：验证是否按照客户路由表进行路由；预期：不转发
• 路由延时测试
  按照ISO15765报文格式定义进行测试
  测试目的：验证是否满足客户路由延时需求；一般需求为2ms，具体以实际需求为准；
• 模拟ECU刷写测试
  按照ISO15765报文格式定义进行测试
  测试目的：模拟刷写工况，验证是否出现丢帧；

4.3测试用例

• 带协议转换的转发值测试1-测试用例示例如下：
  初始条件：

1.系统电压=12V
2.KL15=ON
3.CANoe按照通信矩阵定义模拟发送所有周期报文（模拟实车环境-对应打开CANoe节点同步）

测试步骤：

1.CANoe按照诊断路由表定义的路由关系遍历模拟发送诊断测试报文且数据场为0x02 0x10 0x01 0x00 0x00 0x00 0x00 0x00（某一测试报文如：源网段：DCAN、报文ID：0x721、DLC：8、源报文周期：100ms；目标网段：BCAN、报文ID：0x721、DLC：8、目标报文周期：100ms）；
2.持续监控10S，观察目标网段报文转发情况

预期结果：

1.监控到目标网段的网段、报文ID、DLC符合诊断路由表定义且数据场为0x02 0x10 0x01 0x00 0x00 0x00 0x00 0x00；（如：目标网段BCAN是否正常监控到0x721报文且DLC为8以及周期为100ms）；

• 带协议转换的转发值测试2-测试用例示例如下：
  初始条件：

1.系统电压=12V
2.KL15=ON
3.CANoe按照通信矩阵定义模拟发送所有周期报文（模拟实车环境-对应打开CANoe节点同步）

测试步骤：

1.CANoe按照诊断路由表定义的路由关系遍历模拟发送诊断测试报文且数据场为0x00（某一测试报文如：源网段：DCAN、报文ID：0x721、DLC：8、源报文周期：100ms；目标网段：BCAN、报文ID：0x721、DLC：8、目标报文周期：100ms）；
2.持续监控10S，观察目标网段报文转发情况

预期结果：

1.监控BCAN网段无0x721报文
其他用例就不一一展示了，如果有需要可联系我交流，如果后续大家有此类需求，我会继续新增专题进行介绍。

总结

上面就是对CAN诊断路由相关概念、原理以及测试用例的介绍，后续专题会对诊断路由测试自动化脚本实现进行介绍。如果存在描述问题，欢迎各位大佬给我留言，一起讨论、学习、成长！