# OTA 升级包/刷写脚本 交互流程
📚 本文目标：系统梳理车联网 OTA 升级的完整技术流程，便于面试准备和技术参考
# 📋 目录
# 一、基础概念
# 1.1 什么是 OTA？
OTA（Over-The-Air） 空中下载技术，指通过无线网络远程升级设备固件/软件的技术。
| 对比项 | 传统升级方式 | OTA 升级 |
|---|---|---|
| 升级方式 | 4S 店专用设备连接 | 远程无线推送 |
| 成本 | 高（人工+设备） | 低（自动化） |
| 用户体验 | 不便（需到店） | 便捷（自动进行） |
| 响应速度 | 慢 | 快（即时修复 bug） |
# 1.2 OTA 升级类型
| 类型 | 说明 | 优势 | 适用场景 |
|---|---|---|---|
| 全量升级 | 传输完整的固件包 | 实现简单，兼容性好 | 小版本更新、跨大版本 |
| 差分升级 | 只传输新旧版本差异 | 数据量小，节省流量和时间 | 补丁修复、小版本迭代 |
| 压缩升级 | 固件包经过压缩 | 进一步减少传输量 | 空间受限场景 |
# 1.3 相关术语
| 术语 | 说明 |
|---|---|
| T-Box | Telematics Box，车联网通信盒，负责云端通信 |
| ECU | Electronic Control Unit，电子控制单元 |
| UDS | Unified Diagnostic Services，统一诊断服务（ISO 14229） |
| Bootloader | 引导加载程序，负责固件加载和升级 |
| CAN | Controller Area Network，控制器局域网 |
| DoIP | Diagnostics over IP，基于以太网的诊断 |
| DTC | Diagnostic Trouble Code，诊断故障码 |
# 二、整体架构：云-管-端
# 2.1 架构图
┌─────────────────────────────────────────────────────────────────┐
│ 【云端平台】 │
│ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
│ │ 升级包 │ │ 版本管理 │ │ 任务调度 │ │ 监控告警 │ │
│ │ 生成服务 │ │ 服务 │ │ 服务 │ │ 服务 │ │
│ └───────────┘ └───────────┘ └───────────┘ └───────────┘ │
└─────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────┐
│ 4G/5G 网络 │
│ HTTP/HTTPS/MQTT │
└─────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ 【车机/T-Box】 │
│ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
│ │ 下载管理 │ │ 升级策略 │ │ 诊断会话 │ │ 状态上报 │ │
│ │ 模块 │ │ 模块 │ │ 管理 │ │ 模块 │ │
│ └───────────┘ └───────────┘ └───────────┘ └───────────┘ │
└─────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────┐
│ CAN/Ethernet │
│ 车内总线 │
└─────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ 【目标 ECU】 │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Bootloader │ ←──────────→ │ Application │ │
│ │ 引导分区 │ │ 应用分区 │ │
│ └─────────────────┘ └─────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
# 2.2 各层职责
| 层级 | 组件 | 主要职责 |
|---|---|---|
| 云端 | OTA 平台 | 升级包生成、版本管理、任务分发、升级监控 |
| 车端 | T-Box/网关 | 下载升级包、解析升级策略、UDS 诊断通信、状态上报 |
| ECU | 目标控制器 | 接收固件、刷写写入、完整性校验、回滚机制 |
# 三、核心交互流程（八步法）
# 流程总览
【云端平台】 【车端T-Box】 【目标ECU】
│ │ │
│ ① 下发升级任务 │ │
│ ────────────────────────────────────→ │ │
│ │ │
│ │ ② 下载升级包 │
│ │ ←───────────────────────────────── │
│ │ (HTTPS + 断点续传) │
│ │ │
│ │ ③ 诊断会话准备 │
│ │ ──────────────────────────────────→ │
│ │ (10/27/85/3E) │
│ │ │
│ │ ④ 擦除Flash/准备写入 │
│ │ ──────────────────────────────────→ │
│ │ (31/2E) │
│ │ │
│ │ ⑤ 数据传输 (34/36/37) │
│ │ ←────────────────────────────────→ │
│ │ │
│ │ ⑥ 完整性校验 (31) │
│ │ ──────────────────────────────────→ │
│ │ │
│ │ ⑦ 重启生效 (11) │
│ │ ──────────────────────────────────→ │
│ │ │
│ ←───────────────────────────────── │ ⑧ 上报升级结果 │
│ 上报升级状态 │ │
# 步骤 ①：云端下发升级任务
云端操作：
A[版本管理] --> B[生成升级包] --> C[创建升级任务] --> D[车辆分组] --> E[下发任务]
| 任务属性 | 说明 |
|---|---|
| 目标车辆 | 按 VIN、车型、区域等分组 |
| 升级包 | 全量包或差分包 |
| 升级策略 | 立即升级/预约升级/条件升级 |
| 优先级 | 高（安全补丁）/中（功能优化）/低（体验改进） |
| 超时时间 | 下载超时、升级超时 |
# 步骤 ②：车端下载升级包
下载流程：
1. T-Box 接收升级任务
↓
2. 检查升级条件（电量、网络、车辆状态）
↓
3. 从云端下载升级包（HTTPS）
├── 支持断点续传
├── 分片下载（大文件）
└── 实时进度上报
↓
4. 完整性校验
├── MD5/SHA256 校验
├── 数字签名验证
└── 包格式解析
关键技术点：
| 技术 | 作用 |
|---|---|
| 断点续传 | 网络中断后可继续下载，避免重新开始 |
| 分片下载 | 大文件分包下载，支持并发和重试 |
| 加密传输 | HTTPS + TLS，防止中间人攻击 |
| 签名校验 | RSA/ECDSA 签名，确保升级包未被篡改 |
# 步骤 ③：诊断会话准备（预编程）
下载完成后，车端需要与 ECU 建立诊断会话，确保 ECU 处于可刷写状态。
预编程流程：
| 序号 | 指令 | 含义 | 作用 |
|---|---|---|---|
| ① | 10 03 | 切换到扩展会话 | 允许执行诊断操作 |
| ② | 3E 00 | 测试器保持 | 周期性发送，防止会话超时 |
| ③ | 27 01/02 | 安全访问 | 种子+密钥验证，解锁刷写权限 |
| ④ | 85 02 | 关闭 DTC 存储 | 防止刷写过程中产生误报故障码 |
| ⑤ | 28 00 01 | 关闭通信报文 | 降低总线负载，提高刷写稳定性 |
安全访问流程（种子-密钥机制）：
【车端】 【ECU】
│ │
│ ──── 27 01 ─────────→ │ 请求种子
│ │
│ ←──── 67 01 [种子] ── │ 返回随机种子
│ │
│ ──── 27 02 [密钥] ──→ │ 发送计算后的密钥
│ │ 验证密钥
│ ←──── 67 02 ──────── │ 验证成功，解锁
# 步骤 ④：刷写准备（编程会话）
进入编程模式：
| 指令 | 作用 | 说明 |
|---|---|---|
10 02 | 切换到编程会话 | ECU 进入可刷写状态，暂停应用 |
2E F1 99 | 写入指纹信息 | 记录刷写时间、操作者等信息 |
31 01 FF 00 | 擦除 Flash | 擦除目标区域的旧固件 |
Flash 擦除过程：
【车端】 【ECU】
│ │
│ ──── 31 01 FF 00 ───→ │ 请求擦除
│ │
│ ←──── 71 01 ──────── │ 擦除中...
│ │
│ ←──── 71 01 ──────── │ 擦除中...
│ │
│ ←──── 71 02 ──────── │ 擦除完成
⚠️ 注意：擦除操作不可逆，必须确保升级包完整且正确！
# 步骤 ⑤：数据传输（核心）
这是 OTA 升级的核心流程，基于 UDS 协议的 34/36/37 服务。
完整数据传输时序：
【车端】 【ECU】
│ │
│ ──── 34 [块大小] [地址] [长度] ─────────────→ │ 请求下载
│ │
│ ←──── 74 [块大小] ───────────────────────── │ 同意传输，返回最大块大小
│ │
│ ──── 36 [块序号=1] [数据...] ──────────────→ │ 传输第1块数据
│ ←──── 76 [块序号=1] ─────────────────────── │ 接收成功
│ │
│ ──── 36 [块序号=2] [数据...] ──────────────→ │ 传输第2块数据
│ ←──── 76 [块序号=2] ─────────────────────── │ 接收成功
│ │
│ │ ... 继续传输 ... │
│ │
│ ──── 36 [块序号=N] [数据...] ──────────────→ │ 传输最后一块
│ ←──── 76 [块序号=N] ─────────────────────── │ 接收成功
│ │
│ ──── 37 ──────────────────────────────────→ │ 请求退出传输
│ ←──── 77 ───────────────────────────────── │ 传输完成
服务详解：
| 服务 ID | 名称 | 方向 | 数据格式 | 说明 |
|---|---|---|---|---|
0x34 | Request Download | 车端 →ECU | 34 [数据格式] [地址大小] [内存地址] [数据长度] | 请求开始下载，指定写入地址 |
0x74 | Response Download | ECU→ 车端 | 74 [最大块大小] | ECU 确认可接收，返回单次最大长度 |
0x36 | Transfer Data | 车端 →ECU | 36 [块序号] [数据内容...] | 传输固件数据块 |
0x76 | Response Transfer | ECU→ 车端 | 76 [块序号] | 确认接收成功 |
0x37 | Request Transfer Exit | 车端 →ECU | 37 | 请求结束传输 |
0x77 | Response Transfer Exit | ECU→ 车端 | 77 | 确认传输结束 |
关键技术点：
| 要点 | 说明 |
|---|---|
| 块大小协商 | 车端请求期望块大小，ECU 返回实际支持的最大值 |
| 序号机制 | 每个数据块带有序号，防止乱序或丢失 |
| 流控机制 | ECU 可通过 NRC（Negative Response Code）请求暂停 |
| 超时处理 | 传输超时需重试，连续失败则中止升 ��� |
# 步骤 ⑥：完整性校验
数据传输完成后，必须进行完整性校验，确保固件写入正确。
校验流程：
【车端】 【ECU】
│ │
│ ──── 31 01 02 02 ──────────────────────────→ │ 请求执行校验例程
│ │
│ ←──── 71 01 ─────────────────────────────── │ 校验中...
│ │ 执行 CRC/Checksum 校验
│ ←──── 71 01 ─────────────────────────────── │ 校验中...
│ │
│ ←──── 71 02 [校验结果] ───────────────────── │ 校验完成
│ │
│ ──── 31 01 01 04 ──────────────────────────→ │ 请求校验结果
│ ←──── 71 02 [结果] ─────────────────────── │ 返回结果
校验类型：
| 校验类型 | 说明 | 作用 |
|---|---|---|
| Checksum | 简单累加和校验 | 快速验证数据完整性 |
| CRC16/CRC32 | 循环冗余校验 | 更可靠的错误检测 |
| 数字签名验证 | RSA/ECDSA 签名 | 确保固件来源可信 |
校验结果处理：
| 结果 | 处理方式 |
|---|---|
| 成功 (0x00) | 继续后续流程，准备重启 |
| 失败 | 触发回滚机制，恢复旧版本 |
# 步骤 ⑦：重启生效
校验通过后，ECU 重启使新固件生效。
重启方式：
| 方式 | 指令 | 说明 |
|---|---|---|
| 软重启 | 11 01 | ECU 复位，保持供电 |
| 硬重启 | 断电重启 | 完全断电后重新上电 |
| 应用重启 | 11 03 | 重启应用分区 |
Bootloader 启动流程：
【ECU 上电/复位】
↓
【Bootloader 启动】
↓
┌───────┴────────┐
│ 检测升级标志 │
└───────┬────────┘
↓
┌────┴────┐
│ 有新固件? │
└────┬────┘
│
┌───┴───┐
│ YES │ NO
↓ ↓
【新固件校验】 【跳转旧固件】
↓
CRC/签名验证
↓
┌───┴────────┐
│ 验证通过? │
└───┬────────┘
│
┌───┴────┐
│ YES │ NO → 回滚机制
↓
【搬移固件】
Flash A/B 分区切换
↓
【跳转新固件】
A/B 分区机制（双备份）：
┌─────────────────────────────────────┐
│ Flash 存储布局 │
├─────────────────────────────────────┤
│ Bootloader (固定区域) │
├──────────────┬──────────────────────┤
│ Partition A │ Partition B │
│ (当前版本) │ (备份/新版本) │
└──────────────┴──────────────────────┘
优势：
• 升级失败可立即回滚
• 无需连接外部设备
• 提高升级可靠性
# 步骤 ⑧：结果上报
升级完成后，车端向云端上报升级结果。
上报内容：
| 字段 | 说明 |
|---|---|
| VIN | 车辆识别码 |
| ECU ID | 目标 ECU 标识 |
| 旧版本 | 升级前的版本号 |
| 新版本 | 升级后的版本号 |
| 升级状态 | 成功/失败/回滚 |
| 失败原因 | NRC 码/错误描述 |
| 升级耗时 | 下载时间+刷写时间 |
云端处理：
【接收升级结果】
↓
【更新车辆状态】
↓
【生成升级报告】
↓
【触发后续操作】
• 成功：更新版本记录
• 失败：创建工单/告警
• 回滚：分析原因
# 四、UDS 诊断协议详解
# 4.1 UDS 协议概述
UDS（Unified Diagnostic Services） 是 ISO 14229 定义的统一诊断服务标准，广泛应用于汽车诊断领域。
| 特性 | 说明 |
|---|---|
| 标准号 | ISO 14229-1 (应用层)、ISO 15765-2 (传输层) |
| 通信方式 | 基于 CAN、以太网等总线 |
| 请求/响应 | 主从模式，诊断仪主动请求，ECU 被动响应 |
| 服务分类 | 诊断会话、数据传输、安全访问、例程控制等 |
# 4.2 UDS 报文结构
请求报文格式：
┌──────────┬──────────┬─────────────────────────┐
│ SID │ 子功能 │ 数据参数 │
│ (服务ID) │ 参数 │ (可选) │
│ 1 byte │ 1 byte │ N bytes │
└──────────┴──────────┴─────────────────────────┘
响应报文格式：
┌──────────┬──────────┬─────────────────────────┐
│ SID+0x40 │ 子功能 │ 数据参数 │
│ (肯定响应)│ 参数 │ (可选) │
│ 1 byte │ 1 byte │ N bytes │
└──────────┴──────────┴─────────────────────────┘
┌──────────┬──────────┬─────────────────────────┐
│ 7F │ SID │ NRC │
│ (否定响应)│ (服务ID) │ (负响应代码) │
│ 1 byte │ 1 byte │ 1 byte │
└──────────┴──────────┴─────────────────────────┘
# 4.3 OTA 升级常用 UDS 服务
| 服务 ID | 名称 | 请求 | 响应 | 用途 |
|---|---|---|---|---|
0x10 | Diagnostic Session Control | 10 [会话类型] | 50 [会话类型] | 切换诊断会话模式 |
0x11 | ECU Reset | 11 [复位类型] | 51 [复位类型] | ECU 复位重启 |
0x22 | Read Data By Identifier | 22 [DID...] | 62 [DID...] [数据] | 读取数据标识符 |
0x27 | Security Access | 27 [级别/子功能] [密钥] | 67 [级别] | 安全访问验证 |
0x28 | Communication Control | 28 [控制类型] [通信类型] | 68 | 控制通信报文 |
0x2E | Write Data By Identifier | 2E [DID] [数据] | 6E [DID] | 写入数据标识符 |
0x31 | Routine Control | 31 [控制类型] [RID] [参数] | 71 [RID] [结果] | 例程控制（擦除/校验） |
0x34 | Request Download | 34 [格式] [地址] [大小] | 74 [块大小] | 请求下载数据 |
0x35 | Request Upload | 35 [格式] [地址] [大小] | 75 [块大小] | 请求上传数据 |
0x36 | Transfer Data | 36 [序号] [数据] | 76 [序号] | 传输数据块 |
0x37 | Request Transfer Exit | 37 | 77 | 退出数据传输 |
0x3E | Tester Present | 3E [子功能] | 7E [子功能] | 测试器保活 |
0x85 | Control DTC Setting | 85 [开关] | C5 [开关] | 控制 DTC 存储 |
# 4.4 诊断会话类型
| 会话类型 | 值 | 说明 | 权限 |
|---|---|---|---|
| Default Session | 0x01 | 默认会话，ECU 正常运行 | 最低 |
| Programming Session | 0x02 | 编程会话，允许刷写 | 高 |
| Extended Diagnostic Session | 0x03 | 扩展诊断会话 | 中 |
| Safety System Diagnostic Session | 0x04 | 安全系统诊断 | 中 |
# 4.5 安全访问机制
种子-密钥算法流程：
┌─────────────────────────────────────────────────────────┐
│ 安全访问验证流程 │
├─────────────────────────────────────────────────────────┤
│ │
│ 1. 诊断仪发送: 27 01 (请求种子) │
│ ↓ │
│ 2. ECU 返回: 67 01 [SEED] (返回随机种子) │
│ ↓ │
│ 3. 诊断仪计算: KEY = f(SEED) 使用预设算法 │
│ ↓ │
│ 4. 诊断仪发送: 27 02 [KEY] (发送密钥) │
│ ↓ │
│ 5. ECU 验证: 比较计算结果 │
│ ↓ │
│ 6. ECU 返回: 67 02 (验证成功) 或 7F 27 35 (验证失败) │
│ │
└─────────────────────────────────────────────────────────┘
常见 NRC（Negative Response Code）：
| NRC | 含义 | 可能原因 |
|---|---|---|
0x13 | 设备响应过长 | ECU 处理超时 |
0x22 | 条件不满足 | 未满足服务执行条件 |
0x31 | 请求超出范围 | 参数值超出允许范围 |
0x33 | 安全访问拒绝 | 种子-密钥验证失败 |
0x35 | 密钥验证失败 | 密钥计算错误或次数超限 |
0x37 | 请求序号错误 | 数据块序号不匹配 |
# 五、通信协议栈
# 5.1 车云通信协议
┌─────────────────────────────────────────────┐
│ 应用层: HTTP/HTTPS/MQTT │
│ 升级包下载、任务下发、状态上报 │
└─────────────────────────────────────────────┘
│
┌─────────────────────────────────────────────┐
│ 安全层: TLS 1.2+ │
│ 双向认证、加密传输 │
└─────────────────────────────────────────────┘
│
┌─────────────────────────────────────────────┐
│ 传输层: TCP/UDP │
│ 可靠传输(QoS保障) │
└─────────────────────────────────────────────┘
│
┌─────────────────────────────────────────────┐
│ 网络层: IP │
│ 4G/5G 蜂窝网络 │
└─────────────────────────────────────────────┘
# 5.2 车内诊断通信协议
| 协议 | 传输介质 | 特点 | 应用场景 |
|---|---|---|---|
| DoCAN | CAN 总线 | 带宽低、稳定可靠 | 传统车型、低速升级 |
| DoIP | 以太网 | 带宽高、支持大数据 | 新能源车型、高速升级 |
| FlexRay | FlexRay 总线 | 实时性高、容错性强 | 安全关键系统 |
# 5.3 DoCAN 与 DoIP 对比
| 对比项 | DoCAN | DoIP |
|---|---|---|
| 传输介质 | CAN 总线 | 以太网 |
| 最大带宽 | 500 Kbps ~ 1 Mbps | 100 Mbps ~ 1 Gbps |
| 传输层 | ISO-TP (ISO 15765-2) | TCP/UDP |
| 寻址方式 | CAN ID | IP 地址 + 端口 |
| 适用场景 | 传统 ECU 升级 | 智能座舱、ADAS ECU |
# 5.4 协议栈映射
【车端诊断应用】
│
├─── UDS 诊断服务 (ISO 14229)
│
【传输层适配】
│
├─── DoCAN (ISO 15765-2) ←─ CAN 总线
│
└─── DoIP (ISO 13400) ←─ 以太网
# 六、异常处理机制
# 6.1 升级过程中的异常场景
| 异常场景 | 触发条件 | 处理策略 |
|---|---|---|
| 网络中断 | 4G/5G 信号弱或丢失 | 断点续传、任务重试 |
| 电量不足 | 蓄电池电压低于阈值 | 暂停升级、等待充电 |
| 车辆行驶中 | 车速不为 0 | 延迟升级到停车状态 |
| ECU 通信失败 | 总线故障、ECU 无响应 | 重试机制、诊断故障码 |
| 校验失败 | CRC/签名验证错误 | 中止升级、触发回滚 |
| 刷写中断电 | 升级过程中断电 | Bootloader 自动回滚 |
# 6.2 回滚机制
A/B 分区回滚流程：
┌─────────────────────────────────────────────┐
│ 升级失败时的回滚处理 │
├─────────────────────────────────────────────┤
│ │
│ 1. 检测失败条件: │
│ • 校验失败 (CRC错误) │
│ • 签名验证失败 │
│ • 启动失败 (应用程序崩溃) │
│ • 超时 (Bootloader检测) │
│ │
│ 2. Bootloader 处理: │
│ • 标记新分区为无效 │
│ • 切换回旧分区 │
│ • 记录故障码 (DTC) │
│ │
│ 3. 车端处理: │
│ • 上报升级失败 │
│ • 记录失败原因 │
│ • 等待下次升级任务 │
│ │
└─────────────────────────────────────────────┘
# 6.3 重试机制
| 重试类型 | 重试次数 | 重试间隔 | 说明 |
|---|---|---|---|
| 下载重试 | 3-5 次 | 1-5 分钟 | 网络波动导致下载失败 |
| 刷写重试 | 2-3 次 | 立即 | 传输失败、NRC 错误 |
| 会话重试 | 3 次 | 10 秒 | 会话超时、3E 保活失败 |
# 6.4 状态机管理
升级状态转换：
┌──────────┐
│ 待机 │
└─────┬────┘
│ 接收任务
▼
┌──────────┐ 下载失败 ┌──────────┐
│ 下载中 │ ──────────────→ │ 下载失败 │
└─────┬────┘ └─────┬────┘
│ 下载完成 │ 重试
▼ │
┌──────────┐ ┌─────┴────┐
│ 预编程中 │ ◄─────────────── │ │
└─────┬────┘ 会话失败 │ │
│ │ │
│ 刷写中 │ │
▼ │ │
┌──────────┐ 校验失败 │ │
│ 刷写中 │ ──────────────→ │ │
└─────┬────┘ │ │
│ 重启中 │ │
▼ │ │
┌──────────┐ 启动失败 │ │
│ 重启中 │ ──────────────→ │ 回滚中 │
└─────┬────┘ └─────┬────┘
│ │
▼ ▼
┌──────────┐ ┌──────────┐
│ 升级成功 │ │ 升级失败 │
└──────────┘ └──────────┘
# 七、安全机制
# 7.1 安全威胁分析
| 威胁类型 | 风险描述 | 防护措施 |
|---|---|---|
| 中间人攻击 | 篡改升级包内容 | HTTPS + 双向认证 |
| 重放攻击 | 重复发送旧升级包 | 时间戳 + Nonce |
| 恶意固件 | 注入恶意代码 | 数字签名验证 |
| 拒绝服务 | 大量请求导致服务不可用 | 限流 + 黑名单 |
| 权限提升 | 未授权访问 ECU | 安全访问 (种子-密钥) |
# 7.2 安全防护体系
┌─────────────────────────────────────────────────┐
│ 应用层安全 │
│ • 权限控制 (RBAC) │
│ • 操作审计 (日志记录) │
└─────────────────────────────────────────────────┘
│
┌─────────────────────────────────────────────────┐
│ 数据层安全 │
│ • 升级包签名 (RSA/ECDSA) │
│ • 固件加密 (AES) │
│ • 完整性校验 (SHA256) │
└─────────────────────────────────────────────────┘
│
┌─────────────────────────────────────────────────┐
│ 传输层安全 │
│ • HTTPS/TLS 加密 │
│ • 双向认证 (mTLS) │
│ • 证书管理 (PKI) │
└─────────────────────────────────────────────────┘
│
┌─────────────────────────────────────────────────┐
│ 设备层安全 │
│ • 安全启动 (Secure Boot) │
│ • 种子-密钥验证 │
│ • A/B 分区保护 │
└─────────────────────────────────────────────────┘
# 7.3 升级包签名与验证
签名流程（云端）：
1. 生成升级包 (固件.bin)
↓
2. 计算哈希值: SHA256(固件)
↓
3. 私钥签名: Sign(哈希, 私钥)
↓
4. 附加签名: 固件 + 签名
↓
5. 上传到升级服务器
验证流程（车端）：
1. 下载升级包
↓
2. 分离固件和签名
↓
3. 计算固件哈希: SHA256(固件)
↓
4. 验证签名: Verify(哈希, 签名, 公钥)
↓
5. 验证通过 → 继续升级
验证失败 → 拒绝升级
# 7.4 国密算法应用
| 算法 | 用途 | 说明 |
|---|---|---|
| SM2 | 数字签名 | 替代 RSA/ECDSA |
| SM3 | 哈希算法 | 替代 SHA256 |
| SM4 | 对称加密 | 替代 AES |
# 八、面试问答
# 8.1 核心问题
# Q1：请描述一下 OTA 升级的完整流程？
参考回答（3 分钟版）：
"OTA 升级是一个跨系统的复杂流程，我主要从云端后台的角度来说：
第一阶段：任务下发 云端根据 VIN 和车型分组，创建升级任务并下发给目标车辆。
第二阶段：车端下载 T-Box 接收任务后，检查电量、网络等前置条件，然后通过 HTTPS 断点续传下载升级包。下载完成后进行 MD5 和签名验证。
第三阶段：诊断通信 车端通过 UDS 协议与目标 ECU 通信。先切换扩展会话、做安全访问验证、关闭 DTC 存储，确保 ECU 处于可刷写状态。
第四阶段：数据刷写 切换到编程会话后，使用 34/36/37 服务进行数据传输。这是核心流程，需要按照 ECU 支持的块大小分块传输固件。
第五阶段：校验与生效 传输完成后进行 CRC 校验，通过后重启 ECU，Bootloader 验证新固件并切换分区。
第六阶段：结果上报 车端将升级结果（成功/失败/回滚）上报云端。
关键点：我们在项目中重点处理了断电续传和回滚机制，确保异常情况下车辆不会变砖。"
# Q2：差分升级是如何实现的？
参考回答：
"差分升级的核心是只传输新旧版本的差异部分，主要步骤：
云端（生成差分包）：
- 使用差分算法（如 bsdiff、bspatch）对比新旧版本
- 生成差分包（通常只有原包的 10%-30% 大小）
- 对差分包进行签名和压缩
车端（还原固件）：
- 下载差分包并验证
- 使用旧版本固件 + 差分包还原出新固件
- 还原方式有两种：
- 上位机还原：T-Box 还原后再刷写
- 下位机还原：ECU 自己支持差分解压
优势：节省流量、缩短下载时间、降低服务器成本。 风险：差分算法选择不当可能导致还原失败，需要充分测试。"
# Q3：如果刷写过程中断电怎么办？
参考回答：
"这是 OTA 升级必须考虑的关键场景，我们有多层保护机制：
ECU 层面：
- A/B 双分区设计：一个分区运行，另一个分区升级
- Bootloader 保护：上电时检测升级标志，验证失败自动回滚
- 原子写入：擦除后确保完整写入，避免半新半旧状态
车端层面：
- 电量检测：电压低于阈值（如 12V）拒绝升级
- 状态记录：记录当前刷写进度和阶段
- 重试机制：恢复后可从断点继续
云端层面：
- 任务监控：实时监控升级状态
- 失败告警：升级失败立即通知
- 版本锁定：失败车辆暂停新任务推送
实际项目中我们专门测试过各种断电场景（擦除中、传输中、校验中等），确保任何时点断电都不会导致车辆变砖。"
# Q4：如何保证 OTA 升级的安全性？
参考回答：
"OTA 安全涉及多个层面：
传输安全：
- HTTPS + TLS 1.2+ 加密传输
- 双向认证（mTLS）防止伪造设备
包安全：
- RSA/ECDSA 数字签名，防篡改
- SHA256 完整性校验
- 必要时对固件进行 AES 加密
访问控制：
- 安全访问机制（种子-密钥）
- 诊断会话权限控制
- VIN 精确匹配，防止误刷
设备安全：
- Secure Boot 安全启动
- A/B 分区防回滚保护
审计监控：
- 全流程日志记录
- 异常行为告警
在我们的项目中，还采用了国密算法（SM2/SM3/SM4）满足国内合规要求。"
# Q5：UDS 协议中的 34/36/37 服务是什么作用？
参考回答：
"这三个服务是 UDS 协议中用于数据传输的核心服务：
0x34 - Request Download（请求下载）：
- 由诊断仪发起
- 告诉 ECU 要下载的数据信息：地址、大小、数据格式
- ECU 返回它能接受的最大块大小
0x36 - Transfer Data（传输数据）：
- 真正传输固件内容的服务
- 每个数据块带有序号，防止乱序
- 支持 4095 字节数据（单帧）或更多（多帧）
- ECU 每接收一块返回 0x76 应答
0x37 - Request Transfer Exit（退出传输）：
- 传输完成后发送
- ECU 确认传输结束
完整流程：34 → 74 → 36 → 76 → ... → 37 → 77
在云端后台设计升级包时，我们需要根据 ECU 返回的块大小来合理分包，确保 36 服务能顺利传输。"
# Q6：你遇到过哪些 OTA 相关的技术难题？如何解决的？
参考回答（举例）：
"在奇瑞项目中，我们遇到了一个棘手问题：
问题：某 ECU 在 36 服务传输数据时，间歇性返回 NRC 0x13（响应过长）。
排查过程：
- 排查网络：CAN 总线负载正常
- 排查时序：调整 3E 保活间隔，无效
- 排查数据：发现该 ECU 在处理特定数据模式时性能下降
解决方案：
- 减小单次传输块大小（从 4095 → 2048）
- 增加块间延迟（10ms → 20ms）
- 优化升级包数据布局
结果：传输成功率从 85% 提升到 99.8%。
总结：OTA 调试需要软硬件协同，有些问题只有通过大量测试和日志分析才能定位。"
# 8.2 常见追问
| 追问问题 | 关键点 |
|---|---|
| 如何验证升级包是否正确？ | MD5/SHA256 + 数字签名验证 |
| 为什么需要 3E 保活？ | 防止诊断会话超时，ECU 自动退出编程模式 |
| 什么是 NRC？ | Negative Response Code，负响应代码 |
| CAN 和以太网诊断有什么区别？ | DoCAN vs DoIP，带宽、传输层不同 |
| 如何支持批量车辆升级？ | 灰度发布、分组推送、并发控制 |
# 附录
# A. 常用 NRC 代码速查表
| NRC | 含义 | 常见原因 |
|---|---|---|
0x10 | 拒绝访问 | 安全级别不足 |
0x11 | 服务不支持 | ECU 不支持该服务 |
0x12 | 子功能不支持 | 不支持该参数 |
0x13 | 设备响应过长 | 处理超时或数据过大 |
0x21 | 忙碌 | ECU 正在处理其他任务 |
0x22 | 条件不满足 | 未满足服务执行条件 |
0x31 | 请求超出范围 | 参数值超出允许范围 |
0x33 | 安全访问拒绝 | 种子-密钥验证失败 |
0x35 | 密钥验证失败 | 密钥错误或尝试次数过多 |
0x37 | 请求序号错误 | 数据块序号不匹配 |
# B. OTA 升级时间估算参考
| ECU 类型 | 固件大小 | 传输方式 | 预估耗时 |
|---|---|---|---|
| BCM | 1-2 MB | DoCAN | 5-10 分钟 |
| 娱乐主机 (IVI) | 500 MB - 2 GB | DoIP | 15-60 分钟 |
| ADAS 控制器 | 50-200 MB | DoIP | 10-30 分钟 |
| 网关 | 500 KB - 1 MB | DoCAN | 3-5 分钟 |
# C. 参考资料
| 标准/规范 | 说明 |
|---|---|
| ISO 14229-1 | UDS 应用层协议 |
| ISO 15765-2 | DoCAN 传输层协议 |
| ISO 13400 | DoIP 诊断协议 |
| ISO 26262 | 功能安全标准 |
| AUTOSAR | 汽车开放系统架构 |
📝 最后提醒：
- 理解整体流程，不需要死记硬背每条指令
- 重点掌握：34/36/37 数据传输、种子-密钥机制、A/B 分区回滚
- 结合项目经验，能讲清楚遇到的问题和解决方案
- 对安全机制有基本认识，知道有哪些防护措施
- 了解 CAN 和以太网的差异，能说明 DoCAN 和 DoIP 的区别
祝你面试顺利！🚀