从设计到落地：一套可量产的SOVD诊断系统构建指南

发布时间：

2025-11-12 11:43

引言

随着汽车电子电气架构持续向集中式与SDV（Software-Defined Vehicle）方向演进，传统的基于UDS（Unified Diagnostic Services）的诊断方式已难以满足日益复杂的整车诊断需求。SOVD（Service-Oriented Vehicle Diagnostics）依托面向服务的架构（SOA），为整车诊断提供了统一、灵活且高度可扩展的解决方案。SOVD支持HTTP/HTTPS、JSON、OAuth等现代IT技术，契合互联网化、云原生的开发与运维模式。因此，如何构建一套可落地、可量产的SOVD诊断系统，已成为主机厂、Tier 1供应商及工具链企业共同关注的核心课题。

本文聚焦SOVD诊断系统的设计方法论，将其拆解为以下三个关键环节：

· 方案设计：明确应用场景、定义SOVD诊断拓扑、规划服务发现机制等

· 需求规范开发：拆解国际标准，定义OEM SOVD基础需求与OpenAPI接口规范

· 诊断数据库开发：生成SOVD诊断数据库，实现UDS数据向SOVD数据的自动化转换

整车SOVD方案设计

SOVD方案设计需从应用场景、网络拓扑和实体职责等多个维度进行设计。

首先需要进行应用场景的定义，SOVD应支持多场景诊断访问。远程诊断通过互联网连接，通常借助Wi-Fi或蜂窝网络访问。近场诊断基于本地网络，借助有线以太网或本地Wi-Fi访问。车内诊断通过车内网络直接访问。

在明确应用场景后就可以进行SOVD系统拓扑的定义，这部分需明确系统中关键实体的角色与部署位置。SOVD Client定义不同应用场景下的客户端。SOVD Public Server面向外部网络，作为整车SOVD服务对外访问入口。SOVD Private Server部署于车内，负责处理SOVD请求。SOVD-UDS Adapter实现SOVD与UDS协议转换，如果HPC外接了传统UDS节点，则需要此模块。

完成SOVD系统拓扑后，就可以绘制不同应用场景下的SOVD交互流程图，包括远程诊断访问HPC节点、内部诊断通过SOVD访问传统UDS节点等。明确各实体在诊断会话中的职责与交互逻辑，为后续需求开发与系统实现提供依据。

整车SOVD需求规范开发

在SOVD系统方案设计完成后，需求规范的制定成为承上启下的关键节点。它需结合多项国际标准与行业实践，确保系统的规范性、兼容性和可扩展性。

首先需要对ASAM SOVD规范进行系统性拆解，定义成可落地的工程需求。后续可以对标正在制定中的ISO AWI 17978标准，旨在使SOVD方案与国际标准的发展演进保持同步。如果架构中使用了Autosar AP，则也需要考虑SOVD与AUTOSAR体系的兼容性。

紧接着要结合项目实际场景进行SOVD需求规范的开发。规范中需要包括SOVD涉及的各类实体，明确实体间的关联关系与资源类型的定义原则。同时规范HTTP方法（GET、POST、PUT、DELETE）的使用场景，并设计语义清晰、结构合理的服务器地址和访问方式。基于上述基础，完整定义各类SOVD API接口，涵盖URI、请求头、请求体、响应头、响应体以及携带的参数要求和示例，从而确保规范既符合国际标准要求，又能精准支撑实际项目落地。

另一方面，考虑到对传统UDS控制器的兼容问题，需明确SOVD与UDS协议之间的映射与路由机制，以实现协议层与接口层的衔接。具体工作可分为以下三部分：

· 设计URI路由转换逻辑：明确如何将SOVD的URI与UDS的DoIP或CAN地址进行映射，确保诊断请求能够精准、高效地路由至目标ECU。

· 建立UDS服务与SOVDAPI 的映射规则：明确系统支持的UDS服务（如 0x22、0x19等），并逐一定义其与SOVD接口的映射规则，确保二者可相互转换。

· 定义UDS与SOVD的诊断数据映射规则：将UDS中的数据元素（如 DID、DTC 等）和数据类型与SOVD资源进行关联，实现数据在SOVD架构中的标准化表达

通过上述机制的设计与实现，可让SOVD具备通过UDS协议诊断传统ECU能力。

表 1 UDS服务与SOVD资源映射关系

需求开发的最后一步是评估是否存在序列化诊断需求或整车级诊断场景，例如获取整车健康状态、采集各 ECU 的软件版本、运行状态等。这类需求往往涉及跨多个ECU的协同诊断操作，若仍沿用单点 API 调用方式，将导致客户端需发起多次请求，效率低且易出错。为此，需要在规范中定义SOVD Function实体，用于封装一组关联的诊断指令，将其聚合为一个Function功能接口。后续客户端仅需发起一次功能请求，SOVD Public Server 即可自动拆分执行诊断指令，待所有指令完成后再统一聚合响应返回。

SOVD诊断数据库开发

在完成SOVD需求规范的开发后，即可开始SOVD数据库的开发工作。该阶段目标是定义各实体实际使用的OpenAPI接口与内部参数，为此需区分哪些功能由UDS实现、哪些需封装为SOVD接口，为后续的数据库定义划清边界。

针对SOVD原生节点数据库的开发，需依据已定义的SOVD规范，设计符合规范要求的的OpenAPI数据结构，确保资源支持动态发现、版本演进与跨平台集成。在此基础上，通过标准化工具链（如恒润INTEWORK-DDC工具）自动生成符合规范的SOVD JSON数据库，内容涵盖URI路径、参数约束、请求/响应Schema等完整元数据，提供结构化、可执行的SOVD接口定义。

在传统诊断节点数据库转换环节，需先通过诊断问卷收集各ECU的UDS数据，形成ODX格式源数据；随后依据SOVD-UDS映射规则，将数据库转换为符合SOVD与UDS映射规则要求的OpenAPI接口。INTEWORK-DDC专业转换工具内置高效的UDS-SOVD语义映射引擎，可自动解析PDX/ODX内容并一键生成SOVD OpenAPI数据库。这一流程有效避免了手动映射可能产生的错误与不规范问题，保障了开发质量。

结语

经纬恒润在SOVD诊断系统设计领域拥有深厚的技术积累与丰富的项目实践经验，具备从需求分析、规范定义到数据库生成、系统验证的全流程闭环开发与工具链支持能力。无论客户项目处于概念阶段、开发阶段还是量产导入阶段，我们都能提供定制化、高可靠、易落地的SOVD诊断解决方案，助力您从容应对软件定义汽车时代的技术挑战。

无

软件定义汽车的背后：一场架构的“深层次革命”

无

软件定义汽车的背后：一场架构的“深层次革命”