4. 车载终端软件

车载终端软件不是“把手机 App 搬到车上”那么简单。它运行在资源受限、实时性要求高、生命周期长达 8～15 年的嵌入式环境中，必须同时满足功能、安全、可靠与可运维四重约束。理解车载终端软件，关键是看清它从下到上的分层结构，以及 OTA 与安全启动如何贯穿整个软件栈。

一、四层软件栈：从内核到应用

典型车载终端软件可分为四层，层与层之间通过标准接口解耦，便于独立升级与替换。

• 嵌入式操作系统层：负责进程调度、内存管理、设备驱动与电源管理。常见选择包括 Linux（含 Yocto/Buildroot 定制发行版）、Android Automotive、QNX、RTOS（如 FreeRTOS、AUTOSAR OS）。Linux 生态丰富、成本低，适合信息娱乐与网关；QNX 实时性与安全性强，常用于仪表与 ADAS；RTOS 则用于 MCU 侧的实时控制。
• 中间件层：屏蔽底层差异，提供通信、诊断、数据与安全服务。典型组件包括 SOME/IP、DDS、MQTT、CAN 网关、诊断栈（UDS/DoIP）、时间同步（gPTP）、密钥与证书管理。中间件是“车规适配”的核心，决定了终端能否与整车网络和云平台顺畅对话。
• 应用框架层：提供应用生命周期管理、权限控制、UI 框架与 API。Android Automotive 的 CarService、Linux 侧的 systemd 服务管理、容器化运行时（Docker/OCI）都属于这一层。它让业务应用不必关心底层硬件细节。
• 应用层：导航、语音、远程控制、数据上报、诊断代理等具体业务。应用应通过框架提供的受控接口访问硬件与网络，避免直接操作设备节点。

下面这张结构图展示了四层软件栈及其与 OTA、安全启动的关系：

二、OTA 升级机制：A/B 分区与回滚

OTA（Over-The-Air）是远程运维的核心能力。车载 OTA 与手机 OTA 的最大区别在于：升级失败可能导致车辆无法启动，因此必须设计回滚机制。主流方案是 A/B 双分区：系统保留两套完整镜像，当前运行 A 槽，升级包写入 B 槽，重启后由 Bootloader 切换到 B 槽。若 B 槽启动失败，Bootloader 自动回退到 A 槽。

一次完整的 OTA 流程通常包括：云端生成差分包或全量包 → 终端下载并校验签名 → 写入备用分区 → 标记启动槽 → 重启验证 → 上报升级结果。关键参数包括包大小、签名算法、分区布局和回滚阈值。

# 典型 A/B 分区布局（简化）
/dev/mmcblk0p1  boot_a      64MB
/dev/mmcblk0p2  boot_b      64MB
/dev/mmcblk0p3  system_a    2GB
/dev/mmcblk0p4  system_b    2GB
/dev/mmcblk0p5  userdata    8GB   # 不参与 A/B，升级时保留

# 升级包校验示例
openssl dgst -sha256 -verify pubkey.pem \
  -signature update.sig update.zip
# 输出 Verified OK 才允许写入备用分区

三、安全启动：从信任根到应用

安全启动（Secure Boot）解决的是“设备启动的每一级代码是否可信”。其核心思想是建立一条信任链：芯片出厂时在 OTP/eFuse 中固化信任根公钥，BootROM 用该公钥验证第一级引导程序（SPL）的签名；SPL 验证 Bootloader；Bootloader 验证内核与根文件系统；内核再验证关键应用或容器镜像。任何一级验签失败，启动流程即中止或进入恢复模式。

安全启动与 OTA 是互补关系：OTA 负责“把新软件安全地送进来”，安全启动负责“确保启动的软件确实是经过授权的”。两者结合，才能形成完整的终端软件可信闭环。

四、场景与复盘：一次远程升级失败的处理

某车队终端在执行 OTA 后出现部分设备无法联网。排查发现：升级包写入 B 槽成功，但 B 槽中的中间件配置未同步更新，导致 MQTT 连接参数错误。由于 A/B 分区只保证系统镜像回滚，不保证配置数据回滚，设备虽然能启动，但业务不可用。

复盘结论：

• OTA 升级范围要明确区分“系统镜像”和“配置数据”，配置应纳入版本管理或使用独立配置分区。
• 升级后必须执行健康检查（网络、关键进程、诊断服务），检查失败自动回滚并上报。
• 安全启动验证的是镜像完整性，不验证配置正确性，二者需要配合灰度发布与监控。

五、核心组件与职责清单

车载终端软件的分层设计、OTA 机制与安全启动，共同决定了终端能否在长生命周期内持续演进而不失控。理解这四层结构与两条贯穿机制，是后续学习远程诊断、数据上报和终端安全运维的基础。