第二章 OTA系统架构：云端架构、车端架构与通信链路
大家好，我是老赵。在汽车电子测试这行摸爬滚打了十几年，OTA升级这块算是看着它从「能用就行」发展到现在的「必须万无一失」。今天咱们聊聊OTA的系统架构，说白了就是搞清楚升级这件事，从云端到车端到底是怎么串起来的。
你想想看，一个OTA升级指令发出去，背后要经过多少环节？我习惯把整个架构拆成三块来看：云端、车端、还有连接它们的通信链路。每一块都有各自的坑，咱们一个一个说。
2.1 云端架构：升级包管理与策略下发
云端是整个OTA的大脑。它不负责具体干活，但所有决策都在这里。
2.1.1 升级包管理
升级包管理，说白了就是怎么存、怎么管、怎么分发这些固件文件。我在项目中遇到过最头疼的事——一个升级包在云端存了三个版本，结果测试时发现版本号写错了，导致车端死活不认。嗯，从那以后我对版本命名规范就特别敏感。
云端升级包管理通常包含这几个核心模块：
- 版本仓库：存储所有历史版本和当前版本。我建议用语义化版本号，比如v2.1.3，别搞什么「最终版」「最终版2」这种命名。
- 差分算法引擎：生成差分包（增量包）的地方。常见的算法有bsdiff、xdelta。这里要注意，差分算法对内存和CPU消耗很大，云端生成时没问题，但车端解压时如果算力不够，升级时间会很长。
- 完整性校验模块：生成MD5、SHA256等校验值。我个人习惯在生成包的同时就把校验值算好，存到数据库里，避免后续再算一遍。
- 签名服务：用私钥对升级包签名。车端验签时用公钥。这个环节一旦出问题，整个升级流程就废了。
重要提醒：升级包管理最容易被忽视的是「回滚包」的管理。很多团队只关注新版本，忘了旧版本也要保留。一旦新版本出问题，你得能快速回退到上一个稳定版本。
2.1.2 策略下发
策略下发，就是决定「什么时候给谁升级」。这不是简单的广播，而是精细化的控制。
常见的策略包括：
- 灰度发布策略：先给5%的车推送，观察没问题再逐步扩大到100%。我记得有一次灰度比例设错了，结果直接推给了所有车，还好及时发现没出大问题。
- 时间窗口策略：只在凌晨2点到5点之间允许升级。为什么？因为这时候用户大概率在睡觉，不会影响用车。
- 条件触发策略：比如车辆必须处于P档、电量大于50%、网络信号良好等条件满足时才能升级。
- 区域策略：不同国家、不同地区的法规不同，升级策略也要区分。比如欧盟对网络安全有特殊要求，升级包必须经过额外认证。
我的小技巧：策略下发时，一定要在云端保留完整的下发日志。哪天用户投诉说「我没收到升级通知」，你翻日志一看，哦，原来是策略条件没满足。这能省去很多扯皮的时间。
2.2 车端架构：T-Box、网关、ECU
车端是执行升级的地方。这里涉及三个关键硬件：T-Box、网关、ECU。它们各司其职，缺一不可。
2.2.1 T-Box（远程通信终端）
T-Box是车和云端的「联络员」。它负责接收云端下发的升级包，然后转发给车内网络。
T-Box的核心功能：
- 网络连接：通过4G/5G连接云端。我建议T-Box要支持双SIM卡，一张主卡一张备用卡，防止某家运营商信号不好时断连。
- 数据缓存：升级包下载到T-Box后，先存到本地存储里。存储空间要够大，至少能放下两个完整升级包（一个当前版本，一个新版本）。
- 断点续传：下载过程中如果网络断了，T-Box要能记住下载到哪里了，下次接着下。这个功能在信号不好的地下车库特别重要。
- 安全存储：T-Box里要存公钥证书，用于验签。私钥绝对不能出现在T-Box里，这是安全红线。
注意：T-Box的存储芯片有擦写寿命限制。频繁写入升级包会缩短芯片寿命。我见过一个项目，因为测试时反复下载同一个包，结果T-Box的Flash提前报废了。所以测试时要注意控制写入次数。
2.2.2 网关
网关是车内网络的「交通警察」。它负责把T-Box传来的升级包，路由到正确的ECU上。
网关的关键职责：
- 协议转换：T-Box通常走以太网，而ECU可能走CAN、LIN、FlexRay。网关要把以太网数据包转换成ECU能识别的格式。
- 防火墙：防止非法数据进入车内网络。网关会检查每个数据包的来源和目的地，不符合规则的直接丢弃。
- 升级状态管理：网关要记录每个ECU的升级状态（待升级、升级中、升级成功、升级失败）。这样云端问起来，网关能快速汇报。
- 看门狗功能：如果升级过程中某个ECU卡死了，网关要能强制复位它，或者触发回滚流程。
这里有个容易踩的坑——网关的转发速度。如果升级包很大，网关转发太慢，整个升级时间会变得不可接受。我建议网关的以太网到CAN的转发延迟不要超过10ms。
2.2.3 ECU（电子控制单元）
ECU是最终被升级的对象。每个ECU都有自己的Bootloader和应用程序区。
ECU升级的核心流程：
- 进入Bootloader模式：ECU收到升级指令后，从应用程序模式切换到Bootloader模式。
- 擦除旧程序：擦除应用程序区的Flash。
- 写入新程序：接收升级数据，写入Flash。
- 校验：写入完成后，计算校验值，和云端下发的校验值对比。
- 跳转执行：校验通过后，跳转到新程序执行。
关键点：ECU的Bootloader必须支持「双备份」机制。也就是保留一个最小可启动的备份程序。万一新程序写坏了，还能从备份启动，不至于让ECU变砖。我见过一个项目没做双备份，结果一次升级失败，整个ECU报废了，只能换硬件。
2.3 通信链路：4G/5G、Wi-Fi、CAN、以太网
通信链路是连接云端和车端的「血管」。不同的链路有不同的特点，适用于不同的场景。
2.3.1 4G/5G（蜂窝网络）
蜂窝网络是OTA升级的主力。它覆盖范围广，但速度和稳定性受信号影响大。
| 特性 | 4G LTE | 5G NR |
|---|---|---|
| 理论峰值速率 | 100 Mbps | 1-10 Gbps |
| 典型延迟 | 30-50 ms | 1-10 ms |
| 覆盖范围 | 广 | 中等（仍在建设中） |
| 适用场景 | 小包升级、策略下发 | 大包升级、高清地图更新 |
我个人建议，对于超过500MB的升级包，优先用5G或者Wi-Fi。4G下载一个2GB的包，信号不好的时候可能要下几个小时，用户体验很差。
2.3.2 Wi-Fi
Wi-Fi适合在家庭或停车场场景下使用。速度快、流量免费，但需要用户主动连接。
Wi-Fi升级的典型流程：
- 车辆检测到可用Wi-Fi网络（比如用户家里的路由器）
- 自动连接（需要预先保存密码）
- 在后台静默下载升级包
- 下载完成后，提示用户下次启动时安装
经验之谈：Wi-Fi连接有个坑——车辆在移动中会频繁切换热点，导致下载中断。我建议在Wi-Fi升级策略里加一个条件：只有车辆处于P档且Wi-Fi信号强度大于-70 dBm时，才允许下载。
2.3.3 CAN（控制器局域网）
CAN是车内ECU之间通信的老牌协议。它可靠、实时性好，但带宽很低（经典CAN只有500 kbps，CAN FD最高8 Mbps）。
CAN在OTA中的角色：
- 传输升级指令：比如「开始升级」「暂停升级」「查询状态」这类小数据包。
- 传输小升级包：对于只有几十KB的ECU固件（比如车窗控制器），CAN完全够用。
- 传输诊断数据：升级过程中的错误码、状态信息等。
但要注意，CAN不适合传输大文件。一个2MB的升级包用CAN传，要传30多秒，而且会占用总线带宽，影响其他ECU的正常通信。
2.3.4 以太网
以太网是车内高速通信的未来。100BASE-T1（100 Mbps）和1000BASE-T1（1 Gbps）正在逐步普及。
以太网的优势：
- 高带宽：传输大升级包很快，一个1GB的包用千兆以太网传，不到10秒。
- 支持DoIP：基于IP的诊断协议，可以同时给多个ECU并行升级。
- 标准化：和云端通信的协议栈可以复用，减少开发工作量。
但以太网也有缺点——成本高、功耗大。目前主要用在域控制器和网关之间，普通ECU还是以CAN为主。
重要提醒：在混合使用CAN和以太网的网络中，一定要注意网关的协议转换能力。我遇到过一个问题：以太网传过来的升级包太大，网关的缓冲区不够，导致数据丢失。后来我们把网关的接收缓冲区从64KB扩到了512KB，问题才解决。
小结
好了，这一章的内容就这些。总结一下：
- 云端负责「管」和「策」——管好升级包，定好下发策略。
- 车端负责「接」和「执」——T-Box接包，网关路由，ECU执行。
- 通信链路负责「传」——4G/5G远程传，Wi-Fi本地传，CAN和以太网车内传。
下一章咱们聊聊升级流程的详细设计，包括预检查、下载、安装、回滚这些环节。到时候我会分享一些实际测试中遇到的奇葩问题，保证让你少走弯路。
公众号:蓝海资料掘金营，微信deep3321