2026 年 3 月的 OTA 新规把两件事明确划成了红线：禁止静默强制升级、禁止以升级之名行"锁电降配"之实。往前追，整车信息安全、软件升级、自动驾驶数据记录三项强制性国家标准已于 2026 年 1 月 1 日实施；《智能网联汽车组合驾驶辅助系统安全要求》（GB 47955-2026）于 7 月获批发布、2027 年 1 月实施。监管逻辑很清楚：OTA 不再是"厂家的后台操作"，而是一次需要备案、需要告知、需要可回滚、需要留痕的准召回行为。对车企而言，真正的成本不在云端，而在车端的刷写架构——一次跨越 30 多个 ECU 的整车升级，工程复杂度接近重做一遍 EOL 流程。

一、先区分三类升级，它们的风险完全不同

行业里"OTA"这个词被用得太宽，实际上要分开算：

第一类，座舱与智驾应用层升级。 包体几百 MB 到 2GB，刷写对象是单个域控制器，不影响车辆行驶能力，风险最低，可以做后台静默下载、驻车时安装。

第二类，整车控制器固件升级。 涉及 VCU、BMS、MCU、ESP、EPS 等，包体 100MB—1GB，刷写后必须做完整的功能自检与路试标定验证。这类升级一旦失败，车辆可能无法上高压或无法转向助力，属于"必须告知、必须在场确认"的范畴。

第三类，参数与标定调整。 包体最小，风险却最高——把可用 SOC 窗口从 96% 收到 90%、把快充峰值功率从 250kW 降到 200kW，都只需要改几个标定表。这正是"锁电降配"的技术形态：不需要换硬件，一次参数下发就能改变用户已购产品的性能。

二、车端的六道工程关口

一次合规的整车 OTA，要顺序通过六道关，任何一道不成立，升级就不能下发：

第一关，包完整性与来源认证。 每个升级包都要签名，车端用预置公钥验签（国密 SM2 或 RSA-2048 以上），验签失败直接丢弃。这一步拦住的是"中间人投毒"——云端被攻破时，攻击者可以下发任意固件，签名是最后一道物理边界。

第二关，低压电源保障。 刷写期间 12V 电压必须维持在 11V 以上，否则 Flash 写入中断会变砖。工程做法是刷写前强制把 DC-DC 拉起、把小电瓶 SOC 校验到 60% 以上，或者在高压上电状态下刷写。这一步是 OTA 失败率最高的原因之一，尤其在冬季低温、小电瓶老化的车上。

第三关，A/B 双分区与 Bootloader。 主流方案是双 Bank 备份：新固件写入备用分区，校验通过后切换启动指针；失败则回滚到原分区。没有双分区的 ECU 只能"原地刷写"，一旦断电就是返厂。这就是为什么老平台做 OTA 的成本远高于新平台——不是软件问题，是 Flash 容量与 Bootloader 架构问题。

第四关，刷写顺序与依赖关系。 30 多个 ECU 之间存在严格的版本依赖：BMS 新版本可能要求 VCU 先升级到某个版本，否则报文解析错位。工程上用"升级拓扑图"约束顺序，任何一个节点失败，整个事务回滚。

第五关，刷写后的功能自检。 不是"刷完就完事"，要跑一遍 DTC 清码、传感器标定校验、执行器行程学习（如电子驻车、车窗防夹）。少一步，用户提车就会发现"车窗一键升降失效"。

第六关，留痕与可追溯。 升级时间、包版本、失败原因、用户确认记录都要落盘并可上传，满足软件升级强标与召回追溯要求。这部分数据在事故调查中的权重，往往高于车端日志本身。

三、"锁电降配"为什么必须被单独盯住

从工程角度看，锁电有它的正当理由：电芯批次一致性差、热失控风险边界收窄、或是为了延长质保期内的寿命，收紧 SOC 窗口是保守做法。问题在于这属于产品性能的实质变更，而不是"优化体验"。

判断标准其实可以量化：如果升级导致 CLTC 续航下降超过 5%、或峰值充电功率下降超过 10%、或 0—100km/h 加速时间延长超过 0.3 秒，就应当视为产品变更，需要提前告知并留出用户选择权。新规把"静默"和"强制"两条路都堵上，本质是要求车企把这类调整放回"产品变更"的框架里处理。

对供应链的含义是明确的：BMS 的 SOH 算法与云端电池管理平台，从"售后工具"变成了"合规证据链"。谁能把每一次 SOC 窗口调整的原因、依据、影响量化记录清楚，谁就能在纠纷中站得住。

OTA 的能力上限不是"能推多少功能"，而是"推错了能不能退回来"——双分区、签名、回滚、留痕这四件事做不实，功能越多，风险敞口越大。

数据说明：三项强标实施时间、GB 47955-2026 发布与实施时间、2026 年 3 月 OTA 监管要求取自公开政策报道；包体大小、刷写时长、电压阈值等为行业通用工程区间，不同电子电气架构差异较大。

×

微信分享

微信扫一扫，或复制链接发送给朋友

复制链接