随着无线毗连技术进入汽车市场，将会出现新的访问和利用车辆诊断的方法。从历史上看，车辆诊断一直专注于基于近距离的用例，即技术职员或工人位于车辆附近并毗连外部装备以实行诊断使命。Wi-Fi 和移动宽带网络接入 (4G、5G) 答应远程和 OTA 用例，例如远程诊断、配置和软件更新。随着 HPC 引入新的车辆架构，这也使得无需任何永世的外部毗连即可实行车载诊断使命。
SOVD 为车载、近距离和远程诊断用例提供解决方案。该标准旨在满足基于 UDS（ISO 14229 [1]）、D-PDU API（ISO 22900-2 [18]）、ODX（也称为ISO 22901-1 [9] 或ASAM MCD-2D）和ASAM MCD-3D（也称为ISO 22900-3 [29]）的当前诊断堆栈未涵盖的用例的要求。
对于远程用例，假设操作员不在车辆附近，而是通过（移动）宽带网络（无线）远程访问车辆。远程用例不肯定需要人类最终用户，但也可以包括基于云的服务，例如车队管理、数据网络和分析，这些服务仅间接向人类用户提供信息。远程用例大概依靠于车载用例，例如，在网络不可用的情况下缓冲数据。
远程诊断用例包括但不限于以下内容：
- 信息检索（例如，燃油液位、电池健康查抄）
- 查抄运行状态
- 配置
- 排放查抄
- 车间维修预备
- 远程故障清除
- 远程激活车辆功能
- 软件更新
- 固件更新
- 车队管理
- 软件配置
对于近距离利用案例，假设技术职员或工人靠近车辆，并拥有毗连到特定车辆的测试装备（通过有线或无线）。
近距离诊断用例包括但不限于以下内容：
- 故障清除
- 实行功能查抄的启动或刺激
- 定期技术查抄
- 排放查抄
- 查抄运行状态
- 软件更新
- 固件更新
- 软件配置
对于车载用例，假设这些用例可以在车辆内自主运行，而无需永世毗连到远程服务器或近距离测试器。但是，车载用例的结果也可以通过近距离或远程用例访问。
车载诊断用例包括但不限于以下内容：
• 车载监督器
• 防备性/预测性维护
• 车队监控场景（例如，定期网络车辆状态）
SOVD API 遵照 REST 原则 [16]。这意味着诊断内容以资源的形式提供。资源可通过其特定的资源路径访问。
在 SOVD 中，资源路径由单个实体的路径（拜见 4.2）以及为该实体提供的标准化资源和资源集合（拜见 4.3）组成。
单个诊断内容可用的操作利用 HTTP 方法表示。SOVD 利用以下 HTTP 方法：
Table 1 HTTP methods used by SOVD
HTTP method Purpose GET 从资源中读取内容 PUT 更新资源内容（例如，通过写入新值） POST 创建新的（暂时）资源 DELETE 删除已创建的资源，将内容重置为默认值 以下示例将简要分析 SOVD 利用的基于 REST 的方法。以下章节将详细先容如何构建资源结构。
该示例展示了车辆中的软件应用步伐，它提供了控制窗户的功能，例如，它提供了有关“RearWindows”位置的信息。
Figure 1 WindowControl example
在 SOVD 方面，这是通过提供包含叶资源“RearWindows”的 SOVD 实体“WindowControl”来实现的，可以利用 GET 操作读取。以下示例中资源路径的路径元素“apps”和“data”将在后面的 4.2 和 4.3 章中表明。
Example:
Request:
- GET {base_uri}/apps/WindowControl/data/RearWindows HTTP/1.1
SOVD API 定义了生存诊断内容的实体。要访问诊断内容，SOVD 客户端需要指定要与之交互的实体。本小节先容实体类型、层次结构以及如何在方法请求中引用实体。
SOVD 标准定义实体类型如图 2 所示。实体类型定义足够机动，可以支持各种拓扑和诊断策略。SOVD 实体将诊断内容作为资源生存。实体类型可用的资源集合在 4.3.1 中定义。
Figure 2 Entity types overview
EntityType EntityCollectionType Description SOVDServer / SOVDServer 代表 API 结构的入口点。该级别的资源仅与 SOVD 服务器自己相关，而不是从其他实体聚合而来。 Area areas 地区代表逻辑视图，可用于描述各种车辆拓扑，例如域架构（车身控制、信息娱乐、动力系统）、地区架构（前部、后部）或逻辑架构（软件定义车辆）。 Component components 组件是硬件或软件的代表。组件也可以代表两者的组合（例如，带有根本软件的 ECU）。代表硬件的组件的特点是具有 CPU 和实行软件。例如 HPC、ECU 和智能传感器。作为组件一部门的软件的特点是实行应用步伐所需的根本软件。根本软件的示例是操作系统或假造机管理步伐。只有软件组件或包含软件部门的组件才应链接到应用步伐。 App apps App 表示在组件上实行的应用步伐，例如 Advanced-Lane-Keeping 或 Window Control。 Function functions 功能代表功能视图，答应 OEM 定义对诊断信息的访问，这些信息大概分布在多个组件中，例如车辆识别。留意：本标准未定义功能处置惩罚的更多细节。 从 API 角度来看，硬件和软件组件之间没有区别。但是，OEM 可以选择这样做，并在组件层次结构中表示这一点。
本标准既不定义也不要求车辆内的特定架构。它旨在支持 OEM 定义的任何架构，包括单个车辆中的多个 SOVD 服务器。猛烈建议车辆中的每个实体都绑定到专用的 SOVD 服务器，并且只能通过该服务器举行访问（拜见 4.2.1）。
每个 SOVD 服务器都可以通过毗连措施（远程或近距离）从外部直接访问。OEM 有责任为远程 SOVD 客户端提供公共 SOVD 服务器的标识。对于近距离客户端，应利用 4.9 中描述的标识方法。
