📚 课程目录第4章 OTA系统总体架构设计

4. OTA系统总体架构设计

任务目标

设计一套完整的汽车OTA系统总体架构，明确云端、车端、移动端三大域的组件构成及其交互关系，并输出架构图。本案例聚焦架构设计本身，不涉及具体协议报文或刷写细节。

架构组件与职责

OTA系统按部署位置划分为三个域，各域内部组件及跨域接口定义如下：

云端：负责升级包管理、策略控制与任务下发。
- 升级包管理服务：存储固件/软件包，生成校验元数据（版本号、SHA256、文件大小）
- 车辆管理服务：维护车辆唯一标识（VIN）、当前版本状态、目标版本策略
- 任务调度服务：创建升级任务，记录任务状态机（待执行→执行中→成功/失败）
- 证书管理服务：签发车端验签所需根证书与设备证书
车端：负责接收指令、下载包、安全校验与执行升级。
- OTA Client：与云端通信，上报状态，接收任务指令
- 下载管理器：断点续传下载升级包到本地存储分区
- 验签与校验模块：验证云端签名及包完整性（SHA256）
- 升级执行器：调用底层刷写接口（UDS/诊断会话），管理备份与回滚
- 状态上报模块：将升级进度与结果上报云端
移动端：面向用户的操作入口。
- 用户App：展示升级通知、用户确认触发、查看升级结果
- 消息推送通道：接收云端下发的升级提醒（通过APNs/FCM或车企自建通道）

交互流程定义

云端任务调度服务创建升级任务后，通过消息队列通知车端OTA Client（或车端轮询拉取）。
OTA Client向云端请求升级包下载地址（带短期有效令牌），下载管理器拉取升级包。
下载完成后，验签模块校验签名与哈希；校验通过后由升级执行器触发刷写。
升级执行器完成刷写后，状态上报模块将结果（成功/失败/回滚）上报云端，云端更新车辆版本记录。
移动端App通过云端API查询升级状态，并在用户确认后触发云端下发指令（可选流程，不阻塞车端自动升级）。

架构图

关键接口定义

接口方向	协议/方式	核心数据
云端→车端（任务下发）	MQTT over TLS	任务ID、升级包版本、下载URL（短期令牌）
车端→云端（状态上报）	HTTPS	VIN、任务ID、状态（下载中/校验中/刷写中/成功/失败）、进度百分比
云端→移动端（通知）	APNs/FCM	升级标题、VIN、任务ID
移动端→云端（确认）	HTTPS API	用户、VIN、任务ID、确认动作

```plantuml
@startuml
!include <C4/C4_Container>
!include <C4/C4_Context>

Person(user, "车主", "通过手机App操作OTA升级")
System_Boundary(cloud, "云端") {
    Container(ota_cloud, "OTA云平台", "Java/Spring Cloud", "升级包管理、任务下发、车辆管理、日志分析")
    Container(cdn, "CDN", "静态资源服务", "存储和分发升级包")
    Container(business, "业务系统", "TSP/CRM", "车辆档案、用户鉴权、订单")
}

System_Boundary(car, "车端") {
    Container(ota_client, "OTA Client", "C++/AUTOSAR", "升级包下载、校验、安装调度")
    Container(update_agent, "Update Agent", "Linux进程", "执行刷写、回滚、状态上报")
    Container(ecu, "ECU群", "MCU/SOC", "Bootloader、应用分区")
}

System_Boundary(mobile, "移动端") {
    Container(app, "手机App", "iOS/Android", "用户操作、进度查看、车辆绑定")
}

Rel(user, app, "操作升级")
Rel(app, ota_cloud, "HTTPS/API", "发起升级、查询状态")
Rel(ota_cloud, business, "内部API", "鉴权/车辆信息")
Rel(ota_cloud, cdn, "生成下载链接", "预签名URL")
Rel(cdn, ota_client, "HTTPS下载", "升级包")
Rel(ota_cloud, ota_client, "MQTT/HTTPS", "下发任务/上报状态")
Rel(ota_client, update_agent, "IPC/DBus", "指令与状态")
Rel(update_agent, ecu, "UDS/DoIP", "刷写")
@enduml
```

架构设计验证

本架构满足以下判定条件即视为设计通过：

三个域（云端/车端/移动端）的组件划分清晰，每个组件有明确且唯一的职责，无功能重叠。
所有跨域交互均有对应的接口定义（协议或方式），且交互方向与数据内容在架构图中可追溯。
升级主链路（任务创建→下发→下载→校验→执行→上报）在架构图中完整闭合，无缺失环节。
安全机制（证书管理、验签、短期令牌）在架构中有明确归属组件，不依赖未定义的第三方模块。

如需进一步验证架构可落地性，可基于上述接口定义编写Mock服务模拟一次完整升级流程，但本案例仅要求架构设计层面闭环。