# 034、AutoSAR OTA软件更新设计与实现：从深夜告警到量产落地

凌晨两点，产线测试组的电话又来了：“ECU刷废了三十台，Bootloader报0x31错误，现在产线停了。” 揉着太阳穴打开远程桌面，看到日志里那一行“NVM_WriteBlock()返回E_NOT_OK”，心里已经明白了七八分——又是OTA升级包和NVM分区对齐惹的祸。这种场景在车载OTA项目中太典型了，今天我们就聊聊AutoSAR OTA那些实战中必须趟过的坑。

OTA在AutoSAR CP中的真实定位

很多人以为OTA就是简单的“下载-写入-重启”，但在AutoSAR CP架构里，这是个涉及十几个BSW模块的协同工程。MemIf、Fee、NvM这一套存储管理层是基础，CryptoStack负责验签解密，ComM、Dcm、DoIP要处理通信会话，最要命的是ECU状态管理——车辆行驶中突然来个升级请求，你敢处理吗？

我们项目里吃过亏：诊断会话没管控好，升级过程中CAN报文把刷写流程冲乱了。后来在Dcm模块里加了状态锁，非安全状态直接拒绝非诊断报文。AutoSAR的优雅就在于这些机制都有现成的配置项，但你不实际踩坑根本不知道它们多重要。

双Bank设计不是选择题

“单Bank加回滚”听起来很美好，直到你遇到256KB的Flash而固件有300KB。双Bank切换是量产车的标配，这里有个细节：Bank0和Bank1的起始地址必须严格对齐到Flash Sector边界。我见过有人图省事用0x80040000和0x80080000，结果硬件寻址错位，上电后程序跑飞。