1. 课程导入
智能网联汽车正在从“分布式ECU”向“中央计算+区域控制”演进，车载网关不再只是CAN/LIN报文的转发器，而是整车诊断、刷写、安全与数据交换的核心枢纽。诊断路由与OTA工程，正是围绕网关这一枢纽展开的两项关键能力：前者解决“诊断请求如何跨网段、跨协议、跨ECU准确送达并回传响应”，后者解决“软件包如何安全、可靠、可回滚地分发到整车各节点”。本课程以工程落地为目标，把协议、路由、刷写、安全、测试与排障串成一条完整链路。
一、核心概念：先建立一张“术语地图”
在进入具体技术之前，需要先厘清几个高频概念。诊断通常基于UDS（ISO 14229）服务，物理层与数据链路层可能跑在CAN、CAN FD、DoIP（ISO 13400）或LIN上；网关负责在不同网段之间做协议转换与报文路由。OTA则分为FOTA（固件升级）与SOTA（软件升级），其核心是“包—传输—校验—激活—回滚”的完整状态机。安全方面涉及SecOC、签名验签、安全启动与访问权限控制。把这些概念放在同一张图上，才能理解它们之间的依赖关系。
二、方法流程：从需求到验证的工程闭环
诊断路由与OTA工程不是孤立的功能开发，而是一条端到端的工程链。典型流程如下：
- 需求与规范输入：明确诊断范围、目标ECU、支持的协议栈、OTA升级对象与安全等级。
- 诊断数据库设计：基于ODX/CDD定义服务、DID、例程与故障码，并确定寻址方式（物理寻址/功能寻址）。
- 路由表设计：定义源网段、目标网段、请求ID、响应ID、超时与优先级，形成可配置的路由规则。
- OTA流程设计：确定包格式、传输协议、校验方式、激活条件与回滚策略。
- 安全策略集成：接入SecOC、签名验签、安全访问与刷写前置条件。
- 台架验证：用CANoe/Vehicle Spy等工具模拟节点，验证路由正确性与刷写成功率。
- 实车联调与排障：采集总线日志，分析超时、丢包、路由错误与激活失败。
三、案例/场景：一次跨网段诊断请求的完整旅程
假设诊断仪通过DoIP接入中央网关，需要读取某个区域控制器（ZCU）的软件版本。请求路径如下：诊断仪发送UDS 0x22服务，目标为ZCU的DID；网关收到DoIP报文后，解析目标地址，查路由表，将请求转换为CAN FD报文转发到对应区域网段；ZCU响应后，网关再将响应封装回DoIP返回诊断仪。若中间出现超时，网关需要按策略返回NRC 0x78（响应挂起）或0x10（一般拒绝）。
诊断仪 → DoIP → 中央网关 → 路由表匹配 → CAN FD → ZCU
ZCU → CAN FD → 中央网关 → DoIP封装 → 诊断仪
关键参数：
请求ID: 0x7A0 响应ID: 0x7A8
超时: P2=50ms P2* = 5000ms
路由优先级: 高这个场景说明：诊断路由的核心不是“转发”，而是“带状态、带超时、带安全校验的受控转发”。任何一环缺失，都会导致诊断失败或误判。
四、误区与复盘：初学者最容易踩的坑
- 把网关当透明桥：忽略协议转换、寻址映射与超时管理，导致跨网段诊断失败。
- 混淆物理寻址与功能寻址：功能寻址用于广播，响应可能来自多个ECU，路由策略必须区分处理。
- OTA只关注下载：忽略激活条件、回滚策略与版本一致性，导致升级后车辆无法启动。
- 安全后置：刷写权限、签名验签与安全启动未在早期设计，后期返工成本极高。
- 缺少日志与追踪：排障时无法还原请求路径，只能靠猜，效率极低。
| 能力维度 | 关键对象 | 典型工具/方法 | 验收标准 |
|---|---|---|---|
| 诊断路由 | 路由表、寻址、超时 | CANoe、ODX、路由仿真 | 跨网段请求成功率≥99% |
| OTA刷写 | 包、传输、激活、回滚 | 差分工具、刷写脚本、状态机 | 刷写成功率≥99.5%，可回滚 |
| 信息安全 | SecOC、签名、权限 | HSM、密钥管理、安全启动 | 未授权刷写拦截率100% |
| 测试与排障 | 日志、追踪、故障码 | 总线分析仪、日志平台 | 问题定位时间≤30分钟 |
接下来的学习将围绕这条主线展开：先理解诊断协议与网关路由机制，再进入OTA包管理与刷写流程，随后叠加安全与测试，最终形成可落地的工程能力。掌握这套框架后，面对不同车型、不同网关架构，都能快速迁移与适配。