汽车控制器底层软件BOOTLOADER开发经历

现在所谓智能汽车必备的OTA技术，在ECU控制器层面就是BOOT的开发，对应autosar体系里面的BSW基础软件。

同学刚开始接触汽车软件开发会有一种思想，要学就学听起来high level的autosar，但是到底autosar是个什么东西也搞不懂，殊不知TSL根本就不鸟autosar，甚至迪迪多数用的是手写的代码，不必太过于执着是否符合要求。

参与电动汽车BOOTLOADER开发近三年，从完全没有这方面的基础到参与国内外大小知名或不知名车企零部件的BOOTLOADER开发，也使用过heng润、vector、mentor等软件供应商的基于classical autosar开发的BSW软件，总结了以下一点学习心得。

在阅读以下文章内容前，笔者默认读者们已有一定的电子技术、现场总线通信、计算机网络分层等基础知识，了解接触过**汽车CAN通信总线、CAN收发器（TJA1043等）或SBC系统基础芯片的工作原理、车规级英飞凌TC系列**或瑞萨TI等品牌MCU等基础知识，没有了解过就边学边搜索，千里之行始于足下。

进行汽车软件开发先了解一些基本术语，当整车厂客户问到一些专有名词或同义词时候需要快速识别对方意图，这就体现了自身的专业性了。

诊断、诊断会话、诊断服务、安全等级、寻址方式、FBL、BM、APP、CAL、擦除、驱动、并行刷写，加密传输，压缩传输，软件签名，软件验签，哈希算法，对称非对称加密算法，时间同步技术，软件AB分区，软件备份回滚方案，数据写入字节对齐，数据填充，CANFD可变速率，采样点

汽车的BOOT开发基本围绕ISO14229（UDS on CAN 定义诊断服务）、ISO15765（定义会话层时间参数等）、ISO21434这几个国际标准展开，车企在国际通用标准基础上进行企标修改开发。所以国际标准协议一定要熟悉，在进行企标开发时候还可以针对差异和车企谈判。

对于UDS协议内的服务报文格式是一定要牢记的，刚开始接触的时候是有点陌生的，除了博闻强记的学霸外不建议照着标准内容死记硬背，最好的方法就是找一个BOOT烧录流程报文去熟悉每个服务，逐个分析请求和响应报文的格式，这样既能熟悉协议也能把协议内容与实际项目使用进行联系。

以下例子就是典型的BOOT下载三段流程，分为预编程阶段、编程阶段、编程后阶段。

其中功能寻址、物理寻址在不同阶段有不同的意义，例如在预编程以及编程后阶段的功能寻址是对CAN总线所有节点的广播，而编程阶段的物理寻址是对待升级节点的单播。

在整车上通常有多个待升级节点，整车OTA为了提高升级效率及成功率会对这些节点进行功能寻址广播让它们进入扩展会话关闭网络通信及DTC记录，然后再对单一节点进行物理寻址发送升级数据包，待升级完成后再进行功能寻址广播开启DTC记录及网络通信。

BOOT涉及两个重要的状态机，一个是诊断会话状态机，另一个是安全访问状态机。
诊断会话状态机就是扩展会话、编程会话和默认会话三种会话状态之间的切换。
因为ECU在有APP情况下，会在编程会话下切换到BOOT，所以当上位机/诊断仪/烧录器等发起扩展会话1003服务到编程会话1002服务时候，是由BOOT回复编程会话的正响应。
BOOT在编程会话下还会因接收到默认会话引起复位操作。

在汽车网络安全法规实施以前，常用的安全访问一般为种子密钥配上固定的安全算法掩码MASK计算的安全访问算法和规定错误次数触发的延时惩罚机制，通过多次攻击就可以破解。从2022年开始，出口欧洲的汽车都要求满足网络安全法规。

欧盟实施汽车网络安全法规之后，相应的要求就提高了，硬件上要求有芯片自带的硬件安全模块HSM，电路版图设计的无仿真JTAG口保护，芯片AB双分区FLASH存储、多核运行，软件上要求做增强型安全访问、安全刷写SecureFlashing、安全日志SecureLOG、安全通信SecureOC。
车规级芯片门槛越来越高了，国内目前几乎没有严格符合标准的芯片厂家，满足要求的是英飞凌、瑞萨、德仪、恩智浦等几家。