面向服务的车辆诊断协议SOVD协议介绍

前言

在汽车诊断领域，UDS（Unified Diagnostic Services，统一诊断服务）长期以来一直是满足大多数诊断需求的核心协议。然而，随着 HPC（High-Performance Computing，高性能计算）在新型电子电气架构中的广泛应用，传统诊断方法逐渐暴露出局限性，例如难以高效访问复杂的软件数据以及灵活适配动态诊断场景。为应对这些挑战，SOVD（Service-Oriented Vehicle Diagnostics，面向服务的车辆诊断）标准应运而生，旨在提供更灵活、高效的诊断解决方案。

什么是SOVD协议

SOVD 是由 ASAM（Association for Standardization of Automation and Measuring Systems,自动化与测量系统标准化协会）制定的一种面向服务的诊断标准。该标准将诊断功能和数据抽象为独立的服务资源，利用实体与资源集合进行关联和管理。同时，它提供了一套标准化接口，允许客户端通过标准 HTTP 方法访问这些资源，从而实现相应的诊断功能。

SOVD的使用场景

SOVD协议的应用场景包括：

远程诊断：通过4G/5G等网络技术，将车辆与远程的SOVD Client进行连接，以此获取车辆的诊断数据。

近场/本地诊断：通过无线或有线（如OBD）的方式进行诊断，诊断仪作为SOVD Client去访问车内的整车数据。

车载诊断：在车内部署SOVD Client，无需与远程服务器或近场诊断仪永久连接。车载使用场景的结果也可能被近场或远程使用场景访问。

通过以上的场景介绍可以发现，SOVD协议有效实现了诊断技术路径的统一化，可在远程、近场及车载诊断等不同场景中应用。同时在系统架构层面，SOVD不仅支持部署多个可直接访问的SOVD Server，还能够借助SOVD-UDS网关实现传统ECU的协议转换与数据访问，构建了兼具开放性与兼容性的车载诊断体系。这种架构设计显著提升了各类诊断设备的开发一致性与互操作性。

SOVD的特点

遵从RESTful原则

SOVD API 基于 HTTP RESTful 架构设计，提供了 GET、PUT、POST、DELETE 四种方法，使用URI标识资源，通过JSON格式进行数据交换。基于此，我们可以轻松地获取、更新、创建和删除汽车诊断数据。

方法	用途
GET	用于检索特定资源的信息，例如组件的状态、配置或数据
POST	用于向系统中添加新的资源，如应用、配置或数据集。
PUT	用于对现有资源进行修改，例如更新配置参数、功能设置或数据内容。
DELETE	用于移除不再需要的资源，如应用、配置或数据集。

结构化数据管理

SOVD将车辆数据组织成不同的实体，例如 SOVD Server、Area、Component、App 和 Function。通过实体将不同类型的数据分门别类地存放，部分实体间也可以相互关联，方便快速找到所需的信息。

这些实体中存放着我们需要访问的资源，资源代表着具体的车辆数据。SOVD API 提供了丰富的资源集合，包括 configurations、bulk-data、data、faults 等等，涵盖了汽车数据的方方面面。

基于上面的知识，就可以尝试进行数据访问了。例如，若需获取车辆后窗的状态，可以发送以下GET请求：

GET {base_uri}/apps/WindowControl/data/RearWindows HTTP/1.1

SOVD API

当诊断对象为HPC控制器时，我们能够通过SOVD协议中定义的标准API直接访问相关数据。这些API不仅规范了对不同类型资源的访问方式，还将复杂的车辆数据和操作进行了标准化处理，为开发者和使用者提供了一套高效且完整的解决方案。

以下是一些场景下的SOVD API的使用示例：

当需要检查某个电子控制单元（ECU）的状态时，SOVD API可以通过GET /{entity-path}/data/{data-id}直接获取相关数据；

如果要清除故障码，只需调用DELETE /{entity-path}/faults/{fault-code}即可完成操作；

当车辆需要软件更新时，API提供了从准备（PUT /updates/{update-package-id}/prepare）到执行（PUT /updates/{update-package-id}/execute）的支持，以保障系统持续处于更新后的状态。

此外，SOVD API还支持批量数据处理（如日志文件管理）、锁定机制避免资源冲突，以及灵活的配置和模式切换功能等等。无论是读取车速信息、控制车窗操作，还是清除故障码，都可以通过这些标准API以更加直观的方式实现。

SOVD与UDS

当诊断对象为传统ECU时，我们需要一个网关进行SOVD-UDS的路由转换。在SOVD规范中，已经对常见的 UDS 服务与SOVD 映射关系进行了描述：

UDS 服务	描述	SOVD资源路径
0x10	诊断会话控制	/modes/session
0x11	ECU 复位	/operations/ecureset
0x27, 0x29	安全访问	/modes/security
0x28	通信控制	/modes/commctrl
0x3E	测试仪在线保持	由经典诊断适配器处理
0x85	DTC 设置	/modes/dtcsetting
0x22, 0x2E	数据读取与写入	/data/或 /configurations/
0x14, 0x19	故障码清除与读取	/faults/
0x2F	输入输出控制	/operations/
0x31	例程控制	/operations/

这种UDS-SOVD的适配方案，将传统的UDS诊断协议与现代SOVD架构相结合，为车辆诊断带来了更高的灵活性和可扩展性。通过RESTful接口，诊断工具能够以更直观、更标准化的方式访问和操作车辆数据，同时完整保留了UDS的核心功能。这种设计体现了SOVD的良好适应性，同时也降低了使用SOVD作为诊断协议的门槛。

SOVD的发展与应用

尽管ASAM提出的SOVD协议为汽车诊断带来了更灵活、更高效的解决方案，但其在实际应用中仍面临一定挑战，例如技术细节的实现等。然而，SOVD的标准化进程的也在稳步推进，ISO/AWI 17978-1（ISO定义的SOVD协议的第一部分）预计将在今年发布，这无疑将为SOVD的广泛应用奠定更坚实的基础。

作为国内SOVD技术的早期探索者，经纬恒润已成功助力多家OEM完成SOVD协议的开发与测试工作。公司构建了完整的SOVD系统架构设计方法论，涵盖需求规范制定、服务数据库构建以及技术培训体系，为客户提供全方位的技术支持。同时，经纬恒润具备SOVD协议栈开发能力，可支持协议的开发与集成，并建立了完善的SOVD测试规范体系，提供配套的自动化测试脚本和专业化实施服务。通过一致性检查、性能测试及安全检测等多维度验证，可确保SOVD系统在复杂车载环境中的可靠性与稳定性。

随着SOVD技术的不断演进，经纬恒润将持续发挥自身优势，深入挖掘协议的潜在价值，助力客户在汽车生产与应用中进一步释放SOVD协议的潜力。我们期待，SOVD协议将为汽车行业注入更多创新动力与可能性，推动汽车诊断技术实现新的突破与发展。