4、刷写协议与标准：UDS（ISO 14229）、OBD-II、DoIP、CAN/CAN-FD、LIN、FlexRay等协议在刷写中的应用
ECU固件刷写的本质，是在受控条件下通过车载或外部诊断链路，将新的可执行代码与标定数据写入非易失性存储器（Flash/EEPROM）。这一过程高度依赖底层通信协议与上层诊断规范的协同。在整车电子电气架构中，CAN/CAN-FD是当前刷写的主干道，LIN承担低速子节点的升级任务，FlexRay在高端底盘与动力域仍有存量应用，而DoIP（基于以太网的诊断）正成为面向软件定义汽车（SDV）的刷写主通道。UDS（ISO 14229）作为应用层统一诊断服务，定义了刷写会话控制、安全解锁、内存擦写、校验等标准流程；OBD-II则从法规层面强制规定了排放相关ECU的诊断接口与数据格式，其物理层通常复用CAN或DoIP。理解这些协议在刷写场景中的角色、时序约束与错误处理机制，是系统集成工程师设计可靠刷写方案的前提。
上图展示了刷写协议栈的典型映射关系：诊断仪通过不同物理链路（CAN/CAN-FD、DoIP、LIN、FlexRay）与目标ECU建立连接，UDS服务运行于传输层之上，而OBD-II作为法规层面的强制要求，主要面向排放相关ECU的通用诊断与刷写兼容性。在实际整车集成中，刷写路径往往需要经过网关路由，例如通过DoIP连接至网关，再由网关将UDS请求转换为CAN-FD报文转发至域控制器。因此，系统集成工程师必须同时掌握协议本身的时序特性、报文封装格式以及网关路由策略。
4.1 核心协议原理与刷写适配
UDS（ISO 14229）是刷写流程的应用层骨架。它定义了统一的诊断服务标识符（SID），刷写过程中最常用的服务包括：0x10（诊断会话控制，切换至编程会话）、0x27（安全访问，解锁Flash驱动）、0x34（请求下载）、0x36（传输数据）、0x37（请求传输退出）、0x31（例程控制，用于擦除Flash或校验完整性）、0x2E（通过标识符写数据，用于写入VIN或标定信息）。UDS不关心底层是CAN还是以太网，它只定义服务原语与数据格式。例如，0x34服务中，dataFormatIdentifier指定了压缩与加密方式，addressAndLengthFormatIdentifier定义了内存地址和长度的字节数，这些参数直接决定了刷写工具如何解析目标地址。
CAN/CAN-FD是当前刷写的主要物理层。经典CAN（ISO 11898-1）最大传输速率为1Mbps，单帧数据场仅8字节，因此刷写一个2MB的固件需要传输约26万帧，加上传输层协议（ISO 15765-2）的序列号与流控开销，实际有效吞吐率约为500-700kbps。CAN-FD将数据场扩展至64字节，速率提升至2Mbps甚至5Mbps，有效吞吐率可提升4-8倍。在刷写场景中，CAN-FD的优势不仅在于速度，还在于其支持更大的单帧数据段，减少了传输层分包与重组次数，降低了因丢帧导致的中断概率。但CAN-FD的物理层信号边沿更陡峭，对线束拓扑、终端电阻和节点电容要求更高，在刷写过程中若总线质量不佳，容易出现位错误（Bit Error）导致重传。
DoIP（ISO 13400）将UDS封装在TCP/IP之上，使用端口13400。DoIP支持高达100Mbps/1Gbps的传输速率，且TCP的流控机制天然适配大文件传输。在刷写场景中，DoIP通常用于整车OBD-II接口或以太网骨干节点。DoIP的地址分配采用逻辑地址（Logical Address）机制，诊断仪需要先通过车辆识别请求（Vehicle Identification Request）获取车辆的VIN、EID（实体ID）和GID（组ID），再建立TCP连接。DoIP的时序要求严格，例如RoutingActivation必须在2秒内完成，否则连接超时。此外，DoIP支持并行刷写多个ECU，但需注意网关的带宽分配与TCP窗口大小。
LIN（ISO 17987）是低成本低速总线，速率通常为19.2kbps，用于车窗、座椅、雨刮等车身舒适ECU。LIN的刷写通常采用主机-从机模式，诊断仪作为主机节点发起刷写请求，从机节点响应。由于LIN带宽极低，刷写一个128KB的固件需要约60秒，因此LIN刷写一般仅用于小容量MCU或标定数据更新。LIN的刷写协议基于UDS的简化子集，通常只支持0x10、0x27、0x34、0x36、0x37等核心服务，且不支持并发传输。
FlexRay（ISO 17458）是确定性高带宽总线，速率可达10Mbps，采用双通道冗余设计，主要用于线控底盘（Brake-by-Wire）和主动悬架等安全关键系统。FlexRay的刷写复杂度较高，因为其通信周期（Communication Cycle）是静态调度的，刷写数据必须插入预定义的静态时隙（Static Slot）中。若刷写数据量超过静态时隙容量，需要动态段（Dynamic Segment）配合，但动态段的时序不确定性会影响刷写超时判断。FlexRay刷写通常需要专用的总线监控工具，且ECU必须支持在刷写过程中保持通信调度不中断。
| 协议 | 物理速率 | 单帧数据场 | 典型刷写吞吐率 | 适用ECU | 刷写特点 |
|---|---|---|---|---|---|
| CAN | 500kbps | 8字节 | ~50KB/s | 动力、车身、底盘 | 成熟稳定，需ISO 15765-2传输层 |
| CAN-FD | 2-5Mbps | 64字节 | ~400KB/s | 域控制器、ADAS | 高速，需注意信号完整性 |
| DoIP | 100Mbps | TCP分段 | ~8MB/s | 中央网关、OTA主节点 | 大文件传输，支持并行刷写 |
| LIN | 19.2kbps | 8字节 | ~1.5KB/s | 车窗、座椅、传感器 | 低速，仅适合小容量更新 |
| FlexRay | 10Mbps | 254字节 | ~500KB/s | 线控底盘、主动悬架 | 确定性调度，刷写时序复杂 |
4.2 刷写流程中的协议操作与判断方法
刷写流程的协议操作必须遵循“会话切换→安全解锁→擦除→写入→校验→复位”的标准链路。每一步都有对应的UDS服务与超时参数，任何一步失败都需要明确的错误码与重试策略。
- 会话切换（0x10）：诊断仪发送
0x10 02（编程会话），ECU响应0x50 02。若ECU当前处于默认会话且不允许直接切换，需先通过0x28（通信控制）关闭非诊断通信。判断依据：ECU应在500ms内响应，否则视为会话切换超时。 - 安全访问（0x27）：发送
0x27 01请求种子（Seed），ECU返回4字节种子；诊断仪计算密钥（Key）后发送0x27 02。密钥算法通常为私有加密或基于种子和VIN的散列函数。判断依据：若连续3次密钥错误，ECU将锁定安全访问功能，锁定时间通常为10秒至10分钟不等。 - 内存擦除（0x31 01 02）：通过例程控制启动擦除，例程ID通常为
FF00（擦除Flash）。擦除时间取决于Flash容量，例如1MB的Flash擦除约需2-5秒。判断依据：ECU在擦除期间不应响应其他请求，若超过预设擦除超时（如10秒）仍未返回响应，需检查电源电压或Flash驱动是否异常。 - 数据传输（0x34/0x36/0x37）：先发送
0x34请求下载，指定内存地址与大小；然后循环发送0x36传输数据块，每块大小由blockLength定义（CAN-FD通常为4KB，DoIP为16KB）；最后发送0x37请求传输退出。判断依据：ECU对每个0x36请求应在200ms内响应0x76，若超时则重发当前块，重发次数超过3次则终止刷写。 - 校验与复位（0x31 01 03 / 0x11）：刷写完成后，执行CRC或RSA校验例程，确认固件完整性；最后发送
0x11 01（硬复位）或0x11 03（软复位）使ECU重启进入应用模式。判断依据：复位后ECU应发送应用模式的上电报文（如0x01 40），若未收到，需检查应用软件是否有效。
实战场景：CAN-FD刷写中断与恢复
某域控制器通过CAN-FD刷写，速率设置为2Mbps，数据场64字节。刷写过程中，由于线束连接器接触不良，总线出现偶发位错误，导致连续3帧数据被ECU拒绝。诊断仪检测到0x36服务无响应，根据ISO 15765-2的传输层超时机制（N_As/N_Cr超时），判定为网络层超时。此时，刷写工具不应立即终止，而应执行以下恢复步骤：
- 发送
0x3E（待机保持）维持会话，防止ECU回退到默认会话。 - 重新发送
0x36请求，并携带上一次成功传输的块序号（通过blockSequenceCounter确认）。 - 若连续重试3次仍失败，则发送
0x31 01 02重新擦除Flash，并从头开始传输。
该案例中，关键参数是blockSequenceCounter的同步。若诊断仪与ECU的计数器不一致，会导致数据错位。因此，刷写工具必须记录每个成功传输的块序号，并在重传时使用相同的序号。此外，CAN-FD的位速率切换（BRS）在长线束下可能因信号反射导致采样点偏移，建议在刷写前使用CANscope检查眼图，确保位错误率低于10⁻⁶。
4.3 OBD-II与法规合规性在刷写中的约束
OBD-II（ISO 15031）主要面向排放相关ECU（如发动机、变速箱、后处理系统）的通用诊断。在刷写场景中，OBD-II的约束体现在两个方面：物理接口兼容性与排放相关数据保护。物理接口上，OBD-II规定DLC（数据链路连接器）的引脚定义，其中引脚6和14为CAN-High/CAN-Low，引脚12和13为DoIP的以太网对。刷写工具必须通过OBD-II接口访问车辆网络，但OBD-II的CAN速率通常固定为500kbps（ISO 15765-4），若目标ECU使用CAN-FD，则需通过网关进行速率转换。
法规层面，OBD-II要求排放相关ECU的刷写不得绕过排放诊断功能（如催化剂监测、氧传感器监测）。因此，刷写工具在写入新固件后，必须执行0x31例程中的“就绪状态重置”（I/M Readiness Reset），并验证排放相关DTC（诊断故障码）未被意外清除。此外，美国CARB和EPA法规要求，OBD-II ECU的刷写必须支持“重新编程计数”（Reprogramming Count）的递增，该计数存储在非易失性存储器中，供监管机构检查。若刷写工具未正确递增计数，车辆可能无法通过排放年检。
常见误区：许多工程师认为OBD-II只是物理接口，与刷写协议无关。实际上，OBD-II的PID（参数标识符）服务（如0x01 0x05）在刷写过程中可能被ECU用于监控冷却液温度或电压，若刷写过程中电压低于9V，ECU可能中止刷写并进入跛行模式。因此，刷写工具必须实时监控OBD-II的电压PID，并在电压低于阈值时暂停刷写。
4.4 多协议网关路由与刷写时序协调
在整车电子电气架构中，刷写请求往往需要跨网段传输。例如，诊断仪通过DoIP连接至中央网关，网关再将UDS请求转换为CAN-FD报文发送至动力域控制器。此时，网关的路由策略直接影响刷写时序。网关必须处理以下问题：
- 报文封装转换：DoIP的TCP段需要拆分为CAN-FD帧，并添加ISO 15765-2的传输层头（单帧/首帧/连续帧）。网关的CPU负载与缓冲区大小决定了转换延迟，通常每个DoIP数据包（4KB）转换为约64个CAN-FD帧，转换延迟应小于10ms。
- 流控机制：CAN-FD的流控帧（FC）由接收方ECU发送，网关必须正确转发FC帧给诊断仪，否则诊断仪会因等待流控而超时。若网关同时路由多个ECU的刷写流量，需采用优先级调度，确保高优先级ECU（如安全气囊）的刷写不被低优先级ECU阻塞。
- 超时参数调整：DoIP的P2_Server（服务器响应时间）通常为50ms，但经过网关路由后，CAN-FD链路的响应时间可能增加至200ms。因此，诊断仪必须支持可配置的P2*（增强响应时间）参数，否则会误判ECU无响应。
| 路由场景 | 源协议 | 目标协议 | 关键参数 | 典型延迟 |
|---|---|---|---|---|
| DoIP→CAN-FD | TCP/IP | ISO 15765-2 | TCP窗口大小、CAN-FD速率 | 5-15ms/帧 |
| CAN-FD→CAN | ISO 15765-2 | ISO 15765-2 | 速率转换、数据场截断 | 1-3ms/帧 |
| CAN→LIN | ISO 15765-2 | LIN诊断 | LIN调度表、帧间隙 | 10-50ms/帧 |
| FlexRay→CAN | FlexRay诊断 | ISO 15765-2 | 静态时隙分配、周期同步 | 5-20ms/帧 |
4.5 刷写协议选择的决策框架与常见误区
选择刷写协议时，应基于以下维度进行权衡：数据量（固件大小）、时间预算（产线节拍或OTA窗口）、ECU算力（Flash驱动复杂度）、网络拓扑（是否经过网关）以及法规要求（OBD-II合规）。决策流程如下：
- 若固件大于2MB且时间预算小于2分钟，优先选择DoIP或CAN-FD；若ECU仅支持CAN，则需评估是否接受10分钟以上的刷写时间。
- 若目标ECU为LIN从节点，且固件小于256KB，可接受60秒刷写时间，则使用LIN；否则需增加CAN或以太网接口。
- 若涉及安全关键ECU（如制动），必须使用FlexRay或CAN-FD，并确保刷写过程不影响实时控制报文的调度。
- 若车辆需满足OBD-II法规，刷写工具必须支持ISO 15765-4的CAN速率和PID监控。
经验提醒：在产线刷写场景中，建议使用CAN-FD+DoIP双通道冗余。当DoIP链路异常时，自动降级至CAN-FD，但需提前在ECU中固化两套传输层驱动。此外，所有刷写协议都应支持断点续传功能，记录已传输的块序号，避免因网络抖动导致从头开始。
常见误区总结：第一，忽视CAN-FD的位速率切换（BRS）与采样点配置，导致高速传输时误码率升高；第二，在LIN刷写中未考虑主机任务调度，导致从机响应超时；第三，在DoIP刷写中未设置TCP_NODELAY，导致小数据包延迟累积；第四，在FlexRay刷写中未预留静态时隙，导致数据插入失败。系统集成工程师应在刷写前进行协议一致性测试（如使用CANoe的LIN/FlexRay/以太网模板），并验证所有超时参数与错误处理路径。