2、基础知识：OTA升级的基本概念（FOTA/SOTA）、车载电子控制单元（ECU）架构、固件与软件的区别、常见车载操作系统与升级场景
在深入AB分区与固件升级的工程细节之前，必须先建立一套统一的基础认知框架。车载OTA（Over-The-Air）并非简单的“远程下载安装包”，而是一套涉及整车电子电气架构、嵌入式系统、通信协议、安全策略与售后体系的系统工程。本章将围绕四个核心维度展开：OTA的两种主要形态（FOTA与SOTA）、车载ECU的硬件与软件架构、固件与软件的本质区别，以及当前主流车载操作系统与典型升级场景。只有厘清这些概念，后续的AB分区设计、升级失败回滚、差分算法选型等高级话题才有讨论的基石。
2.1 OTA升级的基本概念：FOTA与SOTA
核心原理
OTA（Over-The-Air）指通过无线通信方式（4G/5G、Wi-Fi）将数据包从云端服务器传输至车载终端，并完成安装激活的过程。在汽车领域，OTA被严格区分为两个层次：FOTA（Firmware Over-The-Air）和SOTA（Software Over-The-Air）。FOTA针对的是ECU内部固化在非易失性存储器（如NOR Flash、NAND Flash）中的底层固件，包括Bootloader、实时操作系统（RTOS）内核、底层驱动以及标定数据。FOTA升级会改变ECU的二进制映像，因此必须考虑断电保护、分区切换、校验失败回滚等机制。SOTA则针对运行在操作系统之上的应用软件与数据资源，例如车载信息娱乐系统（IVI）中的导航地图、音乐App、语音助手界面等。SOTA升级通常不涉及底层硬件抽象层，风险相对较低，但仍需处理版本兼容性与数据一致性。
判断方法：如何区分FOTA与SOTA
| 维度 | FOTA（固件升级） | SOTA（软件升级） |
|---|---|---|
| 升级对象 | ECU固件、Bootloader、RTOS、标定数据 | 应用层APK、地图数据、配置文件、UI资源 |
| 存储位置 | Flash专用分区（如Boot Partition、App Partition） | 文件系统（如ext4、UBIFS）中的用户数据区 |
| 失败影响 | 可能导致ECU无法启动（变砖），需AB分区或外部恢复 | 应用崩溃或数据丢失，通常可重新安装 |
| 升级通道 | CAN/CAN-FD、以太网DoIP、UDS诊断服务 | HTTPS下载、本地包管理工具 |
| 典型场景 | 发动机ECU标定更新、BMS电池管理策略、ADAS摄像头固件 | 车载导航地图增量更新、娱乐系统UI换肤 |
案例拆解：某车型T-Box远程升级的FOTA/SOTA混合场景
某量产车型的T-Box（远程通信终端）需要同时升级两部分内容：一是底层通信模组的固件（修复4G网络掉线问题），二是T-Box上运行的远程控制App（增加蓝牙钥匙功能）。前者属于FOTA，后者属于SOTA。在实施过程中，工程师将固件包（约8MB）通过UDS服务0x34/0x36（请求下载/传输数据）刷写到模组的专用Flash分区，并采用AB分区机制确保升级失败可回滚；而App升级包（约20MB）则通过HTTPS下载到T-Box的/data/app目录，校验签名后由包管理服务完成安装。整个升级过程由车端OTA Manager统一调度，先执行FOTA（需要整车下电条件），再执行SOTA（无需下电）。该案例说明，一个物理设备可能同时涉及FOTA与SOTA，需要不同的升级策略与安全机制。
2.2 车载电子控制单元（ECU）架构
核心原理
现代车辆包含50~150个ECU，从传统的分布式架构（每个ECU负责单一功能）向域集中式架构（DCU）和中央计算平台演进。ECU的硬件核心通常包括：主控芯片（MCU或SoC）、存储单元（Flash与RAM）、通信接口（CAN/LIN/FlexRay/以太网）以及电源管理电路。在OTA视角下，ECU的存储布局尤为关键：一般划分为Bootloader区、应用程序区（App区）、标定数据区（Calibration区）以及配置信息区（如VIN码、序列号）。Bootloader负责启动引导和诊断刷写，App区存放主功能固件，标定区存放可调参数。AB分区方案正是针对App区设计的双备份机制，而Bootloader通常单独存放且不参与AB切换。
操作流程：ECU升级的通用诊断流程
- 会话切换：通过UDS服务0x10（DiagnosticSessionControl）切换到编程会话（Programming Session）。
- 安全解锁：使用0x27（SecurityAccess）进行种子与密钥交换，防止未授权刷写。
- 身份校验：通过0x22（ReadDataByIdentifier）读取ECU的软件版本号、硬件版本号、VIN码。
- 擦除与写入：使用0x31（RoutineControl）擦除目标Flash分区，再通过0x34/0x36写入固件数据。
- 完整性校验：写入完成后，使用0x31执行CRC32或SHA-256校验，或通过0x2E（WriteDataByIdentifier）写入校验值。
- 复位激活：通过0x11（ECUReset）执行软复位，使新固件生效。
常见误区与总结复盘
一个常见误区是认为所有ECU都支持AB分区。实际上，AB分区需要Flash容量翻倍，对于成本敏感的ECU（如车窗控制器、座椅控制器）往往只有单分区。此时FOTA升级必须依赖外部看门狗和Bootloader的恢复机制，或者采用“压缩+解压”的临时缓冲方案。另一个误区是忽略标定数据与固件的耦合关系。某些ECU的标定数据（如发动机点火提前角）与固件版本强相关，升级固件后必须同步更新标定数据，否则可能导致性能下降甚至损坏硬件。因此，在OTA包设计时，应将固件与标定数据打包为同一个“升级单元”，并校验版本匹配关系。
2.3 固件与软件的区别
核心原理
固件（Firmware）是“固化在硬件中的软件”，通常以二进制形式直接烧录在ROM或Flash中，与硬件紧密耦合。固件负责初始化硬件、调度任务、管理中断，是硬件与上层软件之间的桥梁。软件（Software）则指运行在操作系统之上的程序与数据，具有较高的可替换性和独立性。在车载环境中，固件升级往往需要满足ISO 26262功能安全要求（如ASIL-B或ASIL-D等级），而软件升级通常只需满足一般网络安全要求。固件的版本号通常由硬件版本+厂商代码+功能版本组成，例如“HW01_SW03.02.01”，而软件版本号则遵循语义化版本（如v2.1.0）。
对比分析：固件与软件的关键差异
| 属性 | 固件（Firmware） | 软件（Software） |
|---|---|---|
| 存储介质 | NOR Flash、NAND Flash、EEPROM | 硬盘、eMMC、SD卡中的文件系统 |
| 执行方式 | 直接寻址执行（XIP）或拷贝至RAM执行 | 由操作系统加载至内存，依赖动态链接 |
| 更新频率 | 低（每年1~3次） | 高（每月或每季度） |
| 失败后果 | ECU无法启动，需Bootloader恢复或返厂 | 应用崩溃，可重启或重装 |
| 开发语言 | C、汇编、Rust（嵌入式） | C++、Java、Kotlin、Python |
| 调试方式 | JTAG、Trace32、UDS诊断 | GDB、Logcat、远程日志 |
案例拆解：固件升级失败后的恢复流程
某ECU在FOTA升级过程中，因车辆蓄电池电压跌落至7V以下，导致Flash写入中断。此时AB分区机制发挥作用：Bootloader检测到B分区（新固件）的CRC校验失败，自动将启动标志回滚至A分区（旧固件），ECU恢复正常启动。但若该ECU为单分区设计，则需进入Bootloader的“恢复模式”，通过CAN总线重新下载固件。该案例说明，AB分区不仅是一种存储策略，更是功能安全（ISO 26262）中“安全状态”的重要实现手段。在系统设计时，应确保Bootloader本身具备独立的看门狗和电压监测功能，防止在低电压条件下执行擦写操作。
2.4 常见车载操作系统与升级场景
核心原理
当前车载操作系统呈现多元化格局：AUTOSAR Classic Platform（CP）用于动力域、底盘域等安全关键ECU，采用OSEK/VDX实时操作系统；AUTOSAR Adaptive Platform（AP）面向高性能计算，支持POSIX接口和动态部署；Linux（含AGL、Yocto定制版）用于IVI和域控制器；QNX常用于仪表盘和ADAS域，具有高可靠性与硬实时特性；Android Automotive则主导娱乐信息生态。不同操作系统的升级机制差异显著：AUTOSAR CP通常通过UDS诊断协议刷写，Linux/Android则支持基于包的OTA（如OSTree、AB OTA）。
升级场景与策略选择
| 操作系统 | 典型ECU/域 | 升级方式 | AB分区支持 |
|---|---|---|---|
| AUTOSAR CP | 发动机、BMS、ESP | UDS刷写（0x34/0x36） | 部分支持（需Flash翻倍） |
| AUTOSAR AP | 自动驾驶域控制器 | 基于文件系统的更新（如.ear包） | 支持（通过软件集群管理） |
| Linux（Yocto） | IVI、网关 | OSTree + 原子切换 | 支持（/boot分区双备份） |
| QNX | 数字仪表、ADAS | 镜像写入 + 完整性校验 | 支持（IFS分区） |
| Android Automotive | IVI、后排娱乐 | AB OTA（A/B无缝升级） | 强制支持（system/vendor分区） |
实战场景：Android Automotive的AB OTA升级
Android Automotive从Android 7.0开始强制使用AB OTA机制。系统将system、vendor、boot等分区划分为A/B两套槽位（Slot）。升级时，update_engine在后台将新系统写入B槽位，写入完成后通过update_verifier校验B槽位的完整性，然后设置boot_control HAL中的“成功启动标志”。下次重启时，Bootloader根据标志从B槽位引导。若B槽位启动失败（如内核panic），Bootloader自动回退至A槽位。这种机制实现了“无缝升级”，用户几乎感知不到重启过程。但在实际工程中，需要注意：AB OTA要求分区大小一致，且需要预留足够的存储空间（通常为系统分区的1.5倍）。对于存储受限的低配车型，可能需要采用“流式OTA”或“压缩镜像”方案。