4. Bootloader需求分析与功能定义
Bootloader的需求分析不是把“能刷写”当作唯一目标，而是要把整车刷写系统在真实诊断链路中的行为边界定义清楚。它至少要回答五个问题：刷写数据通过什么协议传输、由哪些诊断服务承载、如何确认访问者具备权限、在什么会话状态下允许擦写、以及擦写后如何证明内存内容正确。这五个问题彼此耦合，任何一项定义模糊，都会在产线或售后阶段表现为刷写失败、超时、校验不通过甚至变砖。
刷写协议：从物理链路到传输层
在RH850平台上，Bootloader通常运行在CAN或CAN FD、以太网DoIP等链路上。需求定义时首先要明确协议栈边界：物理层与数据链路层由硬件和驱动保证，Bootloader需要关注的是传输层与诊断应用层。以CAN FD为例，若采用ISO 15765-2传输层，单帧最大有效数据为64字节，长数据需要分包与流控。需求中应写明：功能寻址与物理寻址分别用于什么场景、流控帧的BS与STmin取值、连续帧超时N_Cr、以及多帧传输的最大长度。例如教学示例中可定义：物理寻址用于刷写，功能寻址仅用于会话切换与故障读取；BS=0表示接收方不限制连续帧数量，STmin=5ms表示发送方连续帧最小间隔。这些参数不是随意填写，而是要与ECU接收缓冲能力和总线负载匹配。
若采用DoIP，则需定义TCP连接建立、路由激活、诊断消息的源地址与目标地址、以及UDP发现报文的使用条件。需求中应明确：刷写期间是否允许其他诊断请求插入、连接断开后的重连策略、以及传输层保活机制。协议选择直接决定后续诊断服务的封装方式，因此必须在需求阶段冻结。
诊断服务：UDS服务集与执行顺序
Bootloader的诊断服务需求应以UDS（ISO 14229）为基线，明确支持哪些SID、哪些子功能、以及每个服务的肯定响应与否定响应码。刷写场景中最小服务集通常包括：0x10会话控制、0x27安全访问、0x34请求下载、0x36传输数据、0x37请求传输退出、0x31例程控制、0x11ECU复位、0x22/0x2E读写数据、0x14清除诊断信息、0x19读取DTC。需求中要写清每个服务的调用前置条件，例如0x34必须在编程会话且安全解锁后执行，0x36必须在0x34成功响应后按块序号递增发送。
否定响应码的定义同样关键。常见需要覆盖的NRC包括：0x13报文长度或格式错误、0x22条件不满足、0x24请求序列错误、0x31请求超出范围、0x33安全访问被拒、0x72编程失败、0x78响应挂起。其中0x78用于擦除或校验等长耗时操作，Bootloader应在P2Server时间内返回0x78，并在P2*Server超时前给出最终响应。需求中应给出P2Server=50ms、P2*Server=5000ms这类示例参数，并说明这些值需与诊断仪配置一致。
安全访问：种子密钥与权限分级
安全访问服务0x27用于防止未授权刷写。需求中应定义安全等级：例如Level 1用于读取扩展信息，Level 2用于擦写与编程。种子长度、密钥算法、错误尝试次数与锁定时间都必须明确。教学示例中可采用：种子为4字节随机数，密钥算法为种子按字节异或固定掩码后再做一次循环左移，错误尝试3次后锁定10分钟。需要强调的是，算法本身不是安全强度的全部，种子必须由真随机数或高质量伪随机数生成，且每次请求种子后旧种子立即失效。
安全访问的时序要求也应写入需求：0x27请求种子后，诊断仪必须在规定时间内发送密钥，否则Bootloader应清除本次种子并返回0x24或0x37。解锁状态在会话切换或ECU复位后应自动清除，避免权限残留。
编程会话与内存擦写：状态迁移与地址边界
编程会话是刷写流程的状态容器。需求中应定义会话迁移路径：默认会话→扩展会话→编程会话，以及编程会话下允许的服务集合。进入编程会话通常需要先执行0x10 0x03，再执行0x27安全解锁，然后才能执行0x34。Bootloader应拒绝在默认会话下直接执行下载服务，并返回0x22或0x7F。
内存擦写需求要落到具体地址与粒度。RH850的Code Flash通常按块擦除，Data Flash按扇区擦除。需求中应写明：应用程序区起始地址与结束地址、Bootloader区保护范围、标定区与DTC存储区是否允许擦除、擦除最小单位与对齐要求。例如教学示例中可定义：App区为0x00010000～0x0007FFFF，擦除粒度为8KB，刷写数据按2KB块传输。擦除前应校验地址范围是否落在允许区内，越界请求返回0x31。擦除过程中若发生掉电，Bootloader应能通过标志位识别未完成刷写，并在下次上电时停留在Bootloader模式等待重新刷写。
校验需求：从传输校验到整区完整性
校验分为三个层次：传输层校验、块级校验和整区校验。传输层由ISO-TP或TCP保证数据完整性；块级校验可在0x36传输数据时由Bootloader对每块计算CRC16或累加和，发现错误立即返回0x72并终止本次下载；整区校验在0x37之后通过0x31例程触发，对App区计算CRC32，并与诊断仪下发的期望值比较。需求中应明确CRC多项式、初值、异或值和字节序。例如采用CRC32/MPEG-2，多项式0x04C11DB7，初值0xFFFFFFFF，结果不取反，按大端序比较。
校验通过后，Bootloader应置位刷写成功标志并等待0x11复位；校验失败则保持编程会话，允许重新下载，同时记录失败原因到非易失存储。需求中还应定义校验超时时间，例如整区CRC计算应在500ms内完成，超时返回0x78后继续等待或最终返回0x72。
需求闭环与可验证性
上述五类需求最终要落到可验证的条目上。每一条需求都应能对应一个测试用例：协议参数可通过总线记录仪抓取流控帧验证；诊断服务可通过诊断仪逐条发送并检查响应码；安全访问可通过错误密钥尝试验证锁定逻辑；编程会话可通过会话切换后调用下载服务验证拒绝行为；擦写与校验可通过注入错误数据验证NRC 0x72和重刷恢复。需求文档中应避免“支持刷写”“保证安全”这类不可验证的表述，而应写成“在编程会话且安全等级2解锁后，0x34服务应在50ms内返回肯定响应，否则返回0x22”。
最后需要强调，Bootloader需求不是孤立的功能清单，而是与整车诊断规范、产线刷写节拍、售后诊断仪能力共同约束的结果。协议参数、超时时间、擦除粒度和校验算法一旦冻结，后续变更成本很高，因此在需求阶段就应通过台架验证关键时序和边界条件，确保定义既完整又可执行。