第3章 OTA系统需求分析

3、OTA系统需求分析：功能需求、非功能需求、安全需求

好，咱们进入第三章。说实话，需求分析这步，很多团队容易跳过去，或者草草了事。我见过不止一个项目，代码写了大半才发现「哎呀，这个场景没考虑到」。OTA升级涉及整车网络，牵一发动全身，需求分析必须做扎实。

我个人习惯把OTA需求拆成三块来看：功能需求——车主要什么；非功能需求——系统跑得稳不稳；安全需求——会不会被黑。咱们一个一个聊。

功能需求，说白了就是「用户能拿它干什么」。我参与过的项目里，最基础的功能需求有这几条：

升级包下载：支持通过蜂窝网络、Wi-Fi或USB离线方式获取升级包。嗯，这里要注意，下载过程要支持断点续传。我在项目里遇到过车主把车开进地库，信号断了，结果下载到一半的包全废了——后来加了断点续传才解决。
版本管理：系统要能识别当前ECU的软件版本，并与服务器端的目标版本做比对。你想想看，如果版本号都搞不清楚，升级岂不是乱套？
升级策略选择：支持静默升级（后台下载，下次启动时安装）和立即升级（用户确认后马上执行）。我个人建议，涉及安全相关的ECU（比如制动、转向）必须用静默升级，避免用户误操作。
回滚能力：升级失败后，能自动恢复到上一个可用版本。我曾经有个血泪教训——第一次做OTA时没做回滚，结果某个ECU刷死了，最后只能进4S店用诊断仪救回来。从那以后，回滚成了我的必选项。
升级状态上报：ECU要把升级进度、成功/失败状态实时上报给中央网关，再同步到云端。这样车主在手机上就能看到「您的车辆正在升级，已完成60%」。

核心要点：功能需求要覆盖「下载-校验-安装-回滚-上报」全链路，缺一环都可能出大问题。

非功能需求，很多人觉得是「锦上添花」。其实不然，它决定了系统能不能真正落地。我总结了几条关键项：

需求类别	具体指标	我的经验值
可靠性	升级成功率 ≥ 99.9%	实际项目中，受网络波动、ECU供电不稳影响，能做到99.5%已经很不错了。别盲目追求理论值。
实时性	下载速度 ≥ 2MB/s（4G环境）	我建议用差分升级，只传输变化的部分，能把包体缩小70%以上，速度自然就上去了。
资源占用	升级过程中RAM占用 ≤ 当前ECU可用内存的30%	有些老ECU只有256KB RAM，升级代理占太多内存会导致其他任务饿死。嗯，这里要精打细算。
兼容性	支持AUTOSAR 4.2及以上版本	不同OEM对AUTOSAR版本要求不一样，我建议在需求阶段就明确好基线版本，不然后期适配会疯掉。
可扩展性	支持未来新增ECU的接入	你想想看，如果架构设计死了，后面加个域控制器就得重新搞OTA，那成本就高了。

避坑指南：我曾经在某个项目里，非功能需求只写了「稳定可靠」四个字，结果验收时客户问「多稳定？多可靠？」——完全答不上来。所以，指标一定要量化，比如「升级失败后自动重试3次，每次间隔30秒」。

安全需求，这是OTA的命门。说实话，没有安全的OTA就是给黑客开后门。我参与过安全审计，被问得最多的就是这几个点：

加密传输：升级包在传输过程中必须使用TLS 1.2+加密。我记得有一次测试，用明文传输升级包，抓包工具直接看到了二进制内容——这要是被中间人攻击，后果不堪设想。
双向认证：云端要验证车辆身份，车辆也要验证云端身份。说白了，就是防止伪基站下发恶意包。

安全存储：私钥、证书等敏感信息要存放在HSM（硬件安全模块）或安全元件中。我见过有些方案把私钥写在Flash里，用调试器一读就出来了——这等于把家门钥匙挂在门外。
完整性校验：升级包下载到本地后，要用SHA-256计算哈希值，与云端下发的签名做比对。任何一位不匹配，直接丢弃。

权限控制：只有经过授权的诊断会话才能触发升级。我在AUTOSAR里通常用DCM模块的SecurityAccess机制来实现。
防回滚攻击：要防止黑客刷回一个有漏洞的旧版本。做法是在Bootloader里维护一个「最小允许版本号」，低于这个值的包一律拒绝。
看门狗保护：升级过程中如果ECU死机，看门狗要能复位系统，并进入安全模式。嗯，这个我在实际项目中踩过坑——有一次升级到一半，ECU卡死了，没有看门狗，最后只能断电重启。

特别提醒：安全需求不是「加上加密就完事了」。我建议做一次威胁建模（TARA），把每个ECU的资产、威胁、风险都列出来，再针对性地设计安全措施。否则，你防住了A面，B面可能还是敞开的。

好，需求分析这块就聊到这儿。总结一句话：功能需求让OTA能用，非功能需求让OTA好用，安全需求让OTA敢用。下一章咱们开始聊架构设计，到时候我会把AUTOSAR里那些模块怎么配合OTA讲清楚。