软件定义汽车时代，OTA不再只是车机升级的小功能，而是整车生命周期软件迭代、缺陷远程修复、功能付费升级的核心载体。

本文分层拆解OTA基础概念、行业发展、云-车端完整架构、全链路安全设计、法规要求，同时汇总各大车企量产真实故障与落地解决方案，电控、OTA、售后工程师可直接收藏复用。

一、OTA基础概念与行业发展史

1.1 OTA两大分类

• SOTA ：软件在线升级，侧重应用APP、地图、多媒体类软件更新
• FOTA ：固件在线升级，覆盖VCU、BMS等软件，整车核心升级场景

最早OTA应用于电脑、手机；汽车因ECU繁多、功能安全要求高，普及速度缓慢。

特斯拉率先打通整车全域FOTA，实现底盘调校、智驾、电池策略远程迭代；后续蔚来、小鹏、理想、比亚迪、大众等车企跟进布局全域升级。

1.2 软件定义汽车底层支撑四大支柱

1. 新一代集中式电子电气架构（域控、中央计算）
2. 整车数据平台（整车采集、预测分析）
3. 整车网络安全体系（Efuse信任根、SecOC、固件验签）
4. OTA远程升级系统（整车软件迭代核心通道）

OTA给车企带来两大核心价值：

✅生命通道：远程修复软件缺陷，减少线下召回、4S店返工，大幅降低售后成本

✅商业黄金通道：新车上市后持续推送付费功能，挖掘车辆全生命周期收益

二、OTA法规强制要求（国内+国际）

2.1 国内监管政策（市监总局2020年通知）

1. 车企所有OTA服务必须向总局提前备案
2. 若通过OTA消除车辆缺陷，等同于线上召回，需完整提交召回计划
3. 若车辆被远程入侵、控制等安全事故，车企必须第一时间上报
4. 严禁利用OTA隐瞒车辆缺陷、规避线下召回，违规将严肃处罚

2.2. 国际WP29 SUMS法规

2021年正式生效，全球车辆统一软件升级管理体系认证要求：

1. 所有支持OTA的乘用车、商用车需取得 SUMS证书 （3年有效期）
2. 强制要求升级验签、失败回滚、充足电量检测等机制
3. 每台车辆标注唯一软件识别码RXSWIN，所有升级全程可追溯
4. 升级前评估是否影响车辆型式认证、功能安全参数

三、OTA完整系统架构：云端平台+车辆端

整车 OTA 采用云- 管- 车三层全域协同架构，完整链路分为：云端 OTA 管理平台、传输通道、车载端升级执行系统，同时配套独立安全加密体系、对接整车上下游业务系统（TSP/KMS/CDN/售后MES），实现软件包制作、版本管控、分批次推送、车端下载、校验刷写、结果回传全闭环。

TSP：OEM的云端统一管理平台

KMS：密钥管理系统

CDN：软件包下载位置

MES：OEM的生产管理系统，包括订单、物料、生产计划、调度等

3.1 云端OTA管理平台核心模块

云端平台为车企后台运营、测试、发布统一操作入口，拆分8大核心业务模块，各模块独立解耦、支持接口对外对接。

3.1.1. 车型 & 车辆管理模块

• 维护全车型ECU硬件BOM清单，绑定每台车辆 VIN 与整车软件版本

• 区分改装车、换件车辆，自动识别软硬件不匹配异常车辆并预警

• 支持批量筛选车辆（区域、年款、配置等），精准定向推送升级

3.1. 2. 软件包管理模块

• 存储整车全量包、 差分包 、标定文件、座舱应用、地图数据包

• 支持整包/差分两种打包模式，自动生成差分包减少下载流量

• 绑定软硬件版本依赖关系，禁止不兼容版本推送

• 软件包上传后自动对接KMS完成加密、数字签名存储

3.1. 3. 策略 & 任务管理模块（核心运营模块）

• 可自定义升级规则，支持多类推送模式：

• 静默升级 ：后台无感知升级（非市场车辆）

• 用户预约升级 ：弹窗提醒，车主自选时间安装

• 强制安全升级 ：涉及制动、三电等缺陷修复（无法取消升级）

• 白名单测试 ：先内部工程车、种子用户小批量验证，再全量发布

• 可配置限制条件 ：仅 WiFi下载、车速为 0、电量阈值、升级时段等

3.1. 4. CDN 分发对接模块

• 升级包体积可达几百MB~数GB，原生服务器带宽不足以支撑百万车辆并发下载；

• 对接CDN内容分发网络，就近节点分发，降低下载时延、避免服务器拥堵。

3.1. 5. KMS 密钥安全对接模块

• 密钥管理系统 ：负责对称加密密钥、非对称公私钥、整车设备证书全生命周期管理

• 云端打包完成后加密签名，车端下载后通过证书验签，杜绝升级包篡改、伪造。

3.1. 6. 日志 & 数据统计模块

• 全链路日志留存 ：软件打包记录、任务发布记录、车辆下载记录、刷写成功/失败日志

• 多维度报表 ：升级成功率、失败原因分类、各车型版本渗透率，用于研发迭代、售后故障排查

3.1. 7. 系统对外对接接口 平台预留标准化 API，打通车企内部多系统：

• TSP车联网平台 ：下发升级弹窗、APP推送通知给车主手机

• 故障诊断平台 ：OTA升级后同步车辆软件状态，联动远程诊断

• MES生产系统 ：车辆出厂时同步初始软件版本

• 售后系统 ：升级失败车辆自动流转至售后工单

3.1. 8. 账号权限管理 分级角色：研发测试、运营发布、运维、管理员；不同角色隔离操作权限（如测试账号无法发布正式任务），操作全程留痕审计。

3.2 传输通道（车云中间链路）

3.2. 1. 通讯协议标准

• 车辆TBOX与云端采用HTTPS双向加密通讯，全程密文不可抓取

• 每台车辆分配唯一设备证书，双向身份校验，防止伪车辆接入平台

3.2. 2. 两种传输网络

• 4G/5G蜂窝网络 ：通用全场景下载

• WiFi局域网 ：大体积座舱包、智驾算法包优先WiFi下载，节省流量

3.2. 3. 传输保障机制

• 支持断点续传、分片下载，网络中断恢复后无需从头下载

• 传输数据包附带CRC校验，分片损坏自动重传对应片段

3.3 车端OTA执行系统（整车刷写执行层）

车端以UC升级主控为核心，部署在 TBOX/中央网关，对接全车所有ECU，分为 5 个子模块，配套硬件安全机制。

3.3. 1. UC 升级主控单元（核心控制）

整车 OTA 调度大脑：

• 定时主动连接云端，查询是否存在适配新版本

• 接收下载任务，调度网络分片下载升级包

• 调用KMS本地证书完成包完整性、合法性验签

• 校验整车升级前置条件（P档、电量、无高压故障、静止）

• 按预设ECU顺序依次分发升级包至各控制器

• 全程记录刷写日志，完成/失败状态回传云端

• 升级异常触发自动回滚机制

3.3. 2. UP适配传输层

负责 UC与车内各 ECU间数据转发，适配车内不同总线：

• CAN/CAN FD ：车身、底盘小体积标定包

• 以太网DoIP ：智驾、座舱大固件差分包高速传输

3.3. 3. UA升级引擎（ECU本地刷写单元）

部署在可升级ECU内部，核心硬件保障：

• A/B双分区存储：分区A正常运行车辆程序，分区B后台刷写新版本；刷写失败直接切回A分区，彻底防止变砖

• 断电保护、硬件看门狗

• 差分解压、本地校验，刷写完成自动校验固件CRC

3.3. 4.人机交互模块

• 仪表全流程弹窗提示 ：新版本简介、升级时长预估、下载进度、刷写进度、故障提醒

• 支持预约升级、一键取消非强制更新

3.3. 5. 整车供电协同模块

联动 BCM（低压）、 BMS （高压）判断 12V 低压电瓶电量：

• 电量不足禁止启动大版本升级，防止中途亏电抛锚

• 禁止用户随意下 电中断流程（不支持A/B分区升级的情况）

• 区分高压ECU与低压ECU刷写逻辑，高压部件升级强制下高压

3.4 全链路配套安全架构（贯穿云端 - 传输 - 车端）

• 云端侧：软件包私钥签名、密钥隔离存储、平台操作日志审计

• 传输侧：TLS双向证书加密、分片CRC校验

• 车端侧：硬件安全芯片HSE/TPM、Efuse信任根、固件验签、A/B分区回滚

• 业务安全：WP29 SUMS法规合规，所有升级行为可追溯，安全类升级强制备案

3.5 标准OTA完整业务流程

1. 云端制作加密升级包、配置推送策略
2. TSP下发升级通知至车辆TBOX
3. 用户确认/静默后台下载（支持WiFi限流）
4. 下载完成校验完整性、合法性
5. 检测整车前置条件
6. 依次对各ECU执行刷写，实时上报进度云端
7. 升级成功/失败结果回传平台，失败自动触发回滚

四、整车电子电气EE架构如何影响OTA

1. 传统分布式架构：ECU分散、总线速率低，只能小范围座舱升级，全域FOTA无法落地
2. 域控架构：动力/底盘/座舱分区，支持分域OTA，但跨域升级协调复杂
3. 中央计算架构：以太网高速通讯，全域统一升级，差分包效率大幅提升

关键硬件设计要点：所有ECU必须支持A/B分区；CAN总线仅适合小标定包，大固件必须以太网传输

五、OTA全链路信息安全防护（云端-传输-车端）

5.1 云端安全

平台账号分级权限、升级包加密存储、定期漏洞渗透测试、操作日志留痕

5.2 传输安全

整车与云端采用HTTPS双向SSL证书认证，一车一密钥；升级包全程加密传输，防止劫持篡改

5.3 车端硬件安全

ECU内置HSE硬件安全引擎、Efuse一次性信任根，固件验签；禁止未授权第三方刷写

5.4 典型安全事故警示

Jeep、宝马、特斯拉早年均曝出OTA漏洞，黑客可远程入侵控制制动、转向，车企投入巨额召回成本；完善加密验签、证书体系可规避同类风险。

六、量产高频OTA故障与落地解决方案

6.1 存储容量问题

痛点 ：TBOX预留OTA空间不足，大包升级失败 方案 ：扩容至5.1G以上，座舱包走车机本地存储，采用差分包传输

6.2 低压电瓶供电风险

痛点 ：整车升级耗时1小时以上，仅12V小电瓶供电易亏电、车辆抛锚 方案 ：区分高低压ECU：低压件可上高压刷写；高压件低压刷写

6.3 BCM车身控制器升级bug

痛点 ： BCM刷写完成整车下电，车机黑屏无法展示升级结果，用户误以为故障 方案 ： BCM放在升级序列最后，刷完后延迟下电，HMI留存升级记录

6.4 BMS刷写后无法挂档

痛点 ： TBOX下发复位指令与VCU通讯时序冲突，触发故障码 方案 ：调整TBOX报文发送延时，匹配BMS通讯超时阈值

6.5 升级中途开门、下电导致卡死

OTA专属电源模式，升级期间锁车不中断流程，支持断点恢复

6.6 版本基线混乱

建立整车软件BOM，VIN锁定ECU版本基线

七、远程诊断DOTA：OTA配套售后核心能力

7.1 远程诊断两大核心价值

• 故障自动上报 ：车辆产生DTC实时上传云端，售后主动联系车主，被动维保变主动服务

• 远程下发诊断脚本 ：无需到店即可读取数据流、清除故障、简易标定，节省用户时间

7.2 远程诊断系统架构

• 云端诊断平台+TBOX诊断代理+整车CAN/以太网诊断通道，支持UDS全协议

• 配套云诊断知识库，自动匹配故障现象、维修方案，赋能4S售后

7.3 业务场景

路试车辆远程监控、批量新车故障筛查、OTA升级后健康检测、营运车辆实时车况监控

八、文末总结

1. OTA是软件定义汽车的基础设施，FOTA全域升级是新车标配，同时受国家法规严格监管
2. 一套合格OTA系统需要兼顾功能安全、信息安全、整车电气匹配、低压供电、存储多维度设计
3. 远程诊断与OTA相辅相成，实现车辆全生命周期数字化运维，大幅降低车企售后成本
4. 新一代中央计算架构、硬件安全芯片、A/B分区是落地全域FOTA的三大必备硬件基础