一、OTA升级概述
1.1 什么是OTA升级
OTA，全称是Over-The-Air，翻译过来就是「空中升级」。说白了，就是不插线、不拆机，通过网络把新固件推送到设备上。
我刚开始做嵌入式那会儿，升级固件还得拿着JTAG调试器，一台一台连电脑刷。后来做车载项目，客户说「你们这车机升级能不能像手机一样方便？」——嗯，从那以后，OTA就成了我的必修课。
OTA升级的本质，其实就三步：
- 打包：把新固件、签名、校验信息打包成一个升级包
- 传输：通过网络（Wi-Fi、4G/5G、以太网）把包发到设备上
- 执行：设备接收后，校验、解压、刷写到指定分区
你想想看，一个车上有七八块屏幕，每块屏幕都有自己的MCU或SoC。如果每块屏都要手动刷，那得累死人。OTA就是来解决这个问题的。
1.2 OTA升级的价值与挑战
价值：为什么非做不可？
我个人习惯把OTA的价值总结成三个字：快、省、稳。
| 维度 | 说明 | 我见过的真实案例 |
|---|---|---|
| 快 | 发现Bug后，几天内就能推送到所有设备 | 某车型仪表盘死机，传统方案要召回，OTA三天搞定 |
| 省 | 省去人工刷写、物流、召回成本 | 一次OTA推送，省了上百万的4S店人工费 |
| 稳 | 可以灰度发布，先推10%设备，没问题再全量 | 我们当时做车机升级，先推给内部测试车，再推给公测用户 |
挑战：没那么简单
做OTA升级，最怕什么？我遇到过最惨的一次——升级到一半，网络断了。设备变砖了。嗯，这里要注意，OTA最大的挑战就是「升级失败后的恢复能力」。
具体来说，有这几个坑：
- 断点续传：下载到99%断了，难道要重头下？
- 掉电保护：升级写到一半，车主把电瓶拔了怎么办？
- 版本兼容性：老版本直接跳到新版本，中间跳过了好几个中间版本，会不会出问题？
- 安全风险：升级包被篡改，植入恶意代码怎么办？
⚠️ 我曾经踩过的坑：
有一次做仪表盘OTA，升级包签名校验没做好，结果黑客伪造了一个升级包推送出去。虽然及时发现没造成大范围影响，但那次之后，我所有项目都强制要求「双签名+硬件安全芯片」。
1.3 多屏系统OTA的独特需求
单屏设备的OTA，说白了就是「一个设备、一个升级包、一次刷写」。但多屏系统完全不一样。
你想想看，一辆车里有：
- 仪表盘屏幕（Linux/QNX系统）
- 中控娱乐屏（Android系统）
- 副驾娱乐屏（Android系统）
- 后排头枕屏（Linux系统）
- HUD抬头显示（RTOS系统）
这些屏幕之间，有的通过以太网连接，有的走CAN总线，有的用LVDS传视频。升级的时候，不能各升各的，必须协调好。
多屏系统OTA的独特需求，我归纳为四点：
- 升级顺序依赖：有些屏必须先升，有些屏可以后升。比如仪表盘升级时，中控屏得保持工作，否则倒车影像没了。
- 版本一致性：所有屏幕的软件版本必须匹配。中控屏升了，仪表盘没升，可能通信协议对不上。
- 带宽分配：多块屏同时下载升级包，Wi-Fi带宽够不够？会不会抢了其他业务（比如在线音乐）的带宽？
- 回滚策略：如果某块屏升级失败，其他屏要不要一起回滚？
💡 我的经验：
做多屏OTA，一定要先定义好「升级域」。把有依赖关系的屏幕划到一个域里，域内统一升级、统一回滚。域之间可以独立升级。这样既保证了版本一致性，又不会因为一块屏失败导致全车瘫痪。
一个典型的多屏OTA架构
我习惯用这样的分层设计：
┌─────────────────────────────────┐
│ 云端OTA管理平台 │
│ (升级包管理、灰度策略、统计) │
└──────────────┬──────────────────┘
│ HTTPS/MQTT
┌──────────────▼──────────────────┐
│ 车机主控（OTA Master） │
│ (下载管理、版本协调、状态上报) │
└──────┬──────┬──────┬────────────┘
│ │ │
┌──────▼┐ ┌──▼───┐ ┌▼──────┐
│仪表盘 │ │中控屏│ │副驾屏 │
│(OTA从) │ │(OTA从)│ │(OTA从) │
└────────┘ └──────┘ └───────┘主控负责跟云端通信，下载升级包，然后分发给各块屏幕。各屏幕只负责接收、校验、刷写。这样分工明确，出了问题也好排查。
📌 小技巧：
我在项目中遇到过，主控下载升级包时，其他屏幕还在正常工作。等下载完了，主控再通知各屏幕「准备升级」。这样用户体验最好——车主不会感觉到升级过程的存在。
好了，这一章我们聊了OTA是什么、为什么做、以及多屏系统有什么特殊之处。下一章，我会详细讲讲多屏OTA的系统架构设计，包括主控怎么选、通信协议怎么定、升级包怎么分发。到时候我会分享一个我实际用过的架构方案，保证干货满满。