ARTICLE · 1236434
一问到底|SOVD:统一了软件更新入口,底层刷写流程变了吗?
导语：
前阵子刚把ECU刷写系列写完（原理、实战、安全），我本来觉得，底层的34/36/37报文、27安全访问、还有Bootloader这套流程，自己算是摸得门儿清了。
但在公司的技术研讨会上，工程师在做SOVD分享时提到，SOVD出来以后，整车的“软件更新”也全归它管了。
我当时的第一反应就是：那我之前学的那套过时了？以后刷ECU，难道真发个HTTP请求就完事了？底层的Bootloader还要不要？27安全访问还有没有？
带着这个疑惑，我第一时间去翻了一大堆ASAM规范和AUTOSAR文档。结果，文档里全是控制面、执行面的概念，越看越晕。没办法，我只好去请教我们团队里刚从ASAM中国区域大会回来的工程师。
他听完我的困惑，没直接回答，而是反问了我一句：“你觉得SOVD里的‘更新’，和我们平时说的‘刷写’，是一回事吗？”
这篇文章，就是我顺着这句反问，把这个逻辑彻底捋顺的过程。如果你也刚了解SOVD，且对它和传统ECU刷写的关系有点犯迷糊，那这篇笔记应该能帮到你。
一、先搞清楚：“更新”和“刷写”不是一回事
带着这句反问，我仔细查阅了ASAM SOVD的基础标准（ASAM_SOVD_BS_V1-0）。在软件更新章节里，有一句非常明确的定调，原话是：“更新程序本身不受ASAM SOVD约束”。
顺着这个思路，我明白了工程师那句反问的意思：在SOVD架构下，刷写和更新，其实被拆分成了两个层面。
1.1 规范里的底层逻辑：控制面与执行面的解耦
标准里预设了这样一个前提：车辆内部已经存在一个“执行软件更新的核心组件”，而SOVD API的作用仅仅是触发这个中央组件。这就从根本上划清了界限：SOVD不干涉底层的Flash Driver、不干涉底层的安全访问握手，也不负责将字节流打碎成34/36/37报文。
刷写（Flashing）是执行面：它的本质是往Flash里写数据。擦除、传输、校验、复位——这些动作发生在ECU内部，由Bootloader执行，走的还是经典的UDS服务。
更新（Update）是控制面：它的本质是决定“装哪个包、什么时候装、装完了没有”。包括查版本、检查前置条件、触发安装、监控进度、失败回滚等管理动作。
（图注：ASAM 官方 SOVD 参考架构，直观体现 HPC 应用、传统 ECU、SOVD Client 之间的链路，SOVD (HTTPS) 和底层 UDS 协议相互独立，是控制面 / 执行面解耦的标准示意。）
1.2 UDS时代的局限：诊断仪把活全干了
回顾一下我们之前的刷写实战篇，诊断仪从头到尾要干这些事：
读ECU基本信息，确认版本匹配
发10 03进扩展会话、85关DTC、28停通信
发10 02进编程会话、27安全访问
发31擦除Flash
发34/36/37传数据
发31校验
发11复位、恢复通信
在单ECU、本地连接的场景下，这没问题。但到了HPC时代、OTA时代，问题来了：如果云端要同时给几百辆车更新，每辆车都要从头到尾盯着34/36/37吗？如果HPC上跑的是应用而不是ECU，应用更新哪来的Bootloader？
这就是SOVD要解决的：把“控制面”和“执行面”解耦，让更上层的系统去管更新，让底层的系统去干活。
二、SOVD的/updates到底管什么？
既然SOVD是控制面，那它具体管什么？工程师告诉我，SOVD规范里/updates资源的方法，它的核心功能围绕着“更新生命周期”展开。
2.1 它只管更新编排，不碰底层擦写
它不管的事： 直接擦写Flash、把数据拆成34/36/37底层报文、底层Bootloader的搬运逻辑、切B区、回滚。这些全部交给底层的更新系统去执行。
注：对于原生支持SOVD的HPC平台，SOVD规范确实定义了Bulk Data（批量数据）资源，能用来传输大文件或配置包。但它传输完后，依然是交给底层的更新管理器去处理，而不是SOVD自己去操作Flash扇区。
2.2 三种更新模式，覆盖不同工程场景
分步更新（Stepwise）：先调用PUT /prepare，系统将包下载到车端并进行完整性校验；确认无误后，再调用PUT /execute进行安装和激活。适合维修站作业，技师可以确认车辆状态绝对安全后，再手动触发执行。
自动更新（Automated）：调用PUT /automated，SOVD Server会将后续动作打包处理，全权交给后端的更新系统控制。适合远程OTA。
自主更新（Autonomous）：
GET /updates/autonomous返回服务器评估后推荐的更新包ID。适合紧急安全补丁，系统自动锁定最新补丁包推送。
三、谁在真正干活？——顺着架构往下摸
明白了SOVD只管“编排”，我又产生了第二个问题：那它到底是通过谁，去指挥底层的“执行面”呢？
工程师带我顺着AUTOSAR架构往下摸，发现这里面其实分成了几种不同的路线。
3.1 传统ECU：SOVD-to-UDS适配层做翻译
车上还有大量传统ECU，它们听不懂HTTP，只认34/36/37。SOVD-to-UDS适配层的作用，就是把SOVD的控制指令翻译成UDS的执行序列。
在AUTOSAR架构里，这个链路是这样的：当云端发来PUT /updates/{id}/prepare，请求先到SOVD Gateway（网关），网关路由给Diagnostic Manager（诊断管理器）。诊断管理器发现目标是一个传统ECU，于是调用SOVD-to-UDS Translation（适配器），在车内总线上发起以下动作：
向ECU发10 02进编程会话
发27过安全访问
发31擦除Flash
发34/36/37把包传进去
发31校验
返回SOVD响应：“prepare完成”
（图注： SOVD Gateway + SOVD2UDS Adapter 链路示意，展示 HTTP SOVD 请求，经适配层翻译转为 UDS 报文下发给传统 ECU。）
从SOVD客户端角度看，它只发了一个HTTP请求。从ECU角度看，它经历了一整套熟悉的UDS刷写流程。适配层在客户端视角屏蔽了底层的复杂性，但代价是，这个适配层在车内承担了极高的状态机管理、超时机制与NRC（否定响应码）翻译成本。
补充一点：如果是通过SOVD控制ECU的“准备状态”，SOVD还专门定义了modes资源。客户端可以通过PUT /components/{id}/modes/session 显式要求目标进入特定状态，再由适配层去转换为底层的UDS动作。
3.2 AUTOSAR的分化：HPC和应用怎么办？
传统ECU有适配层翻译，那HPC上的应用（App）呢？它们没有Bootloader，也不走34/36/37。翻看AUTOSAR AP的技术说明，我发现架构在这里做了分化：
整车更新（Vehicle Update）：SOVD网关将请求直接路由给OTA Client（比如eSync Client）。此时，OTA Client直接充当了SOVD Server的角色，与后端交互、下载包并驱动整车更新。这条路径完全不涉及诊断管理器（Diagnostic Manager）。
组件更新（Component Update）：诊断管理器作为原生SOVD Server，通过ara::diag接口与UCM（更新与配置管理） 交互。SOVD负责接收指令，UCM负责实际的软件包下载、传输到目标ECU、处理、激活及回滚。
这清晰地体现了“接口编排（SOVD）”与“执行管理（UCM/OTA Client）”的分离。
3.3 实战看协同：SOVD怎么指挥eSync干活
在ASAM与eSync联盟联合发布的白皮书里，展示了这种分工在实际业务中的三种典型落地场景，帮我理清了思路：
选择性更新（Elective）：某辆车OTA升级失败，eSync管道把错误码报给后台。后台通过SOVD API的faults和logs资源读取故障和日志，发现是签名校验失败。修复问题后，技术人员通过SOVD API再次触发eSync，仅仅对这台单一个体重新进行刷写。
加速更新（Accelerated）：SOVD系统在实时监测中，发现某辆车报出了雨刮校准故障（特定的DTC）。系统立即标记该车，通过SOVD指令绕过常规的OTA更新队列，直接让eSync管道优先推送修复该DTC的软件包。
纠正性更新（Corrective）：维修店给车换了一个旧版本的备件ECU。SOVD系统检测到版本不匹配，自动下发指令触发eSync管道，下载并刷写最新软件，让新ECU与整车配置对齐。
四、那刷写安全呢？SOVD的Token跟27/29什么关系？
梳理完底层的分工，我又想到之前写《刷写安全》时留下的一个疑问：SOVD里引入了OAuth Token，这跟我之前讲的27（种子-密钥）和29（证书）到底是什么关系？它们会打架吗？
我把这个问题抛给工程师，他告诉我：在SOVD架构下，安全通常分为三层，作用于不同阶段，是叠加的关系。
第一层：SOVD的OAuth Token（接口鉴权）证明“这个客户端有权限发起更新”。云端或诊断仪必须先登录授权服务器，拿到Token，才能调用PUT /updates/{id}/prepare。
第二层：底层的访问控制（执行鉴权）在SOVD的架构下，这一步并不总是割裂的。当适配层要把数据写进ECU时，ECU会要求进行27或29认证。但在现代架构中，SOVD Server可以将传递来的OAuth角色映射到底层权限（例如通过AUTOSAR DEXT配置），从而隐式地由车端代劳完成底层的鉴权握手。
第三层：固件数字签名（数据完整性）更新包本身会带签名，ECU在安装前会通过内置的公钥进行验签。证明“这份固件确实来自官方，且没有被篡改”。
这三层各司其职，缺一不可。
五、走一遍完整链路：从云端到Flash
为了验证我理解的这套逻辑，我拉着工程师，对着规范，把整个链路在纸上推演了一遍。
从SOVD客户端角度看，它只发了几个HTTP请求。从ECU角度看，它经历了一整套UDS刷写流程。从适配层角度看，它把两边的协议进行了严丝合缝的翻译与状态同步。这就是“控制面”与“执行面”解耦后的真实运作状态。
六、小彩蛋
【图注】： 工程师在ASAM中国区域大会外场拍到的工程测试车。这台吉利银河700是目前国内首个在实际项目中落地SOVD应用场景的车型。看到实车，我才真切感受到SOVD不再只是文档里的名词，这套控制面架构已经真真切切地装进车里跑起来了。
总结
回到开篇的问题：SOVD出来了，刷写流程变了吗？
没变。 Bootloader还是那个Bootloader，34/36/37还是那个34/36/37，27安全访问还是那个27。SOVD没有发明新的刷写协议，也没有取代UDS刷写服务。
但架构变了。 以前诊断仪要自己从头盯到尾，现在SOVD客户端只需要发几个HTTP请求。复杂的协议翻译交给了网关与适配层，大包传输交给了eSync/UCM，底层的状态机维护由诊断管理器完成，刷写执行还是ECU自己干。
用一句话概括：
SOVD不是“新刷写”，它是软件更新的“控制面（Control Plane）”。它把“选什么、什么时候装、装得怎么样”标准化了，但“怎么擦、怎么传、怎么校验”依然由底层的“执行面（Execution Plane）”完成。
搞懂了这个分层，你再看SOVD的/updates资源，就不会问“它怎么不擦Flash”了——因为Flash的物理驱动，本来就不属于上层更新管理的范畴。
栏目信息：
《一问到底》 是讯联技术推出的汽车电子测试专栏。我们不讲空话，只聊工程师遇到的真问题——总线、通信等等。每一期，我们从一个具体痛点出发，讲透原理，给出解法。
本系列文章均为原创，未经授权禁止搬运、洗稿、抄袭。如需转载，请先获得授权。
📢 小编碎碎念：
如果这篇文章帮你搞懂了SOVD的核心逻辑，欢迎点赞、转发、关注，你的支持是我们最大动力！
大家在实际测试中还遇到过哪些问题？欢迎在评论区留言讨论！
声明：本文基于ASAM、AUTOSAR及eSync Alliance公开技术文档整理，旨在以通俗视角解析SOVD与底层刷写架构的分工。实际工程落地中的具体参数、流程及OEM定制化实现，请以官方正式规范及项目需求为准。
参考资料：
ASAM e.V. ASAM SOVD Base Standard V1.0.0 (2022).
AUTOSAR. Explanation of Service-Oriented Vehicle Diagnostics (AP R25-11).
ASAM & eSync Alliance. Combining ASAM SOVD and eSync to enhance OTA update capabilities (Part 1 & 2).
ISO. ISO 17978-2:2026 Road vehicles — Service-oriented vehicle diagnostics (SOVD) — Part 2: Use case definitions.
