2. AUTOSAR刷写与维护标准框架
在AUTOSAR体系中，刷写与维护并不是单一工具的功能，而是一组标准协议、软件模块与工程工具链的协同结果。理解这一框架的关键，是把“标准层”与“ETAS实现层”对应起来：标准层定义服务语义、会话状态与安全规则，ETAS层则把这些抽象规则落地为可配置的模块、可执行的工程和可观察的日志。本节围绕UDS、OBD、FBL、Flash Bootloader以及诊断会话与安全访问五组概念，梳理它们在ETAS体系中的映射关系。
一、UDS：刷写与维护的服务语义基础
UDS（Unified Diagnostic Services，ISO 14229）定义了诊断仪与ECU之间的请求/响应服务集合。刷写场景中最核心的服务包括：0x10 DiagnosticSessionControl（会话切换）、0x27 SecurityAccess（安全访问）、0x34 RequestDownload、0x36 TransferData、0x37 RequestTransferExit、0x31 RoutineControl（擦除、校验）、0x11 ECUReset。这些服务本身只规定报文格式与肯定/否定响应语义，不规定ECU内部如何实现。ETAS体系中，UDS服务由诊断栈（如基于AUTOSAR DCM的配置）承载，服务处理逻辑通过配置生成，而非手写解析代码。
例如一次典型的下载请求：诊断仪发送 34 00 44 00 00 10 00 00，其中 0x44 表示 compression/encryption 与 memoryAddress 长度组合，后随4字节地址与4字节长度。ECU若接受，返回 74 20 04 00，其中 0x20 为 maxNumberOfBlockLength 的高字节，表示后续每个 0x36 块最多可携带 0x2004 字节数据。这个参数直接决定刷写吞吐，是ETAS刷写工程中需要与Bootloader配置一致的关键点。
二、OBD：法规诊断与刷写维护的边界
OBD（On-Board Diagnostics）主要面向排放相关法规诊断，服务集合与UDS有交集但语义更窄，典型如 0x01 当前动力系统诊断数据、0x02 冻结帧、0x03 排放相关DTC、0x04 清除DTC、0x09 车辆信息。在ETAS体系中，OBD通常作为独立诊断层与UDS刷写层共存：OBD服务在应用运行态可访问，而刷写相关UDS服务在Bootloader或编程会话中才开放。二者共享物理CAN/CAN FD或DoIP链路，但通过会话与安全状态进行隔离，避免法规诊断接口被误用于刷写。
三、FBL与Flash Bootloader：刷写执行体
FBL（Flash Bootloader）是ECU内负责擦写Flash并跳转到应用的程序。在AUTOSAR语境下，Flash Bootloader通常指符合AUTOSAR Flash Bootloader规范的实现，它包含驱动层（Flash驱动、CAN/DoIP通信）、服务层（UDS服务处理）和跳转逻辑。ETAS体系中，FBL的生成与配置通过工具链完成：Flash驱动参数（扇区大小、擦除粒度、写入对齐）来自具体MCU，通信参数来自总线配置，UDS服务表来自诊断配置。三者必须一致，否则会出现“服务被接受但数据写错地址”的隐性故障。
一个常见的教学示例参数：某MCU Flash扇区为 8 KB，擦除粒度为扇区，写入对齐为 8 字节。若 0x34 请求的起始地址为 0x80010000，长度为 0x00008000，则Bootloader需擦除从 0x80010000 开始的4个扇区。若地址未按扇区对齐，FBL应返回否定响应 0x31（requestOutOfRange），而不是强行擦除相邻扇区。
四、诊断会话与安全访问：状态与权限的闸门
诊断会话（Session）与安全访问（SecurityAccess）共同构成刷写操作的“状态机闸门”。默认会话 0x01 下通常只允许读取类服务；编程会话 0x02 下才开放下载与擦除；扩展会话 0x03 用于常规维护。安全访问则通过种子-密钥（Seed-Key）机制解锁受保护服务，典型流程为：请求种子 27 01，ECU返回 67 01 + Seed，诊断仪计算Key后发送 27 02 + Key，ECU校验通过返回 67 02。ETAS体系中，种子-密钥算法通常以DLL或配置形式集成到诊断工程，算法本身不暴露在诊断仪脚本中。
需要特别注意的是会话与安全状态的组合约束：即使处于编程会话，若未通过安全访问，0x34 仍应被拒绝；反之，安全访问通过后若会话超时回到默认会话，下载服务也应重新被锁定。这种“双条件”判断是ETAS刷写工程中必须验证的边界场景。
五、映射关系中的工程要点
把上述标准与ETAS实现对应起来，有三点值得在工程中反复确认。第一，服务表与会话状态机必须一致：DCM配置中每个服务允许在哪些会话下执行，必须与Bootloader实际判断逻辑一致，否则会出现“诊断仪认为可执行、ECU却拒绝”的错位。第二，安全访问算法与种子长度必须匹配：若ECU返回4字节种子而诊断仪按2字节解析，Key计算必然失败，表现为 27 02 返回 7F 27 35（invalidKey）。第三，Flash驱动参数与下载地址必须对齐：擦除粒度、写入对齐、地址范围三者任一不匹配，都可能导致写入失败或数据损坏，且往往在 0x37 之后才通过校验暴露。
综上，UDS提供刷写的服务语言，OBD划出法规诊断的边界，FBL与Flash Bootloader承担实际擦写执行，诊断会话与安全访问则控制“何时能做、谁有权做”。ETAS体系的价值，在于把这四层标准语义收敛为可配置、可生成、可验证的工程对象，使刷写从协议条文变成可重复执行的工程流程。