从UDS到SOVD：汽车诊断技术的演进与突破

随着汽车行业的快速发展，车辆电子系统的复杂性和数据量急剧增加。传统的诊断协议（如UDS）在过去几十年中发挥了重要作用，但在面对现代车辆的需求时，逐渐显露出其局限性。2022年，ASAM发布了全新的面向服务的车辆诊断（SOVD，Service-Oriented Vehicle Diagnostics）标准。该标准通过现代化的技术（如HTTPS、RESTful API）重构车辆诊断体系，支持远程、近端和车内诊断场景，并兼容现有的UDS协议。

本文将深入探讨SOVD协议的背景、动机、技术特性及其在AUTOSAR自适应平台中的实现。通过对SOVD协议的详细分析，我们将揭示其在现代汽车诊断中的重要性，并展望其未来的应用前景。

#01

为什么需要SOVD？

SOVD旨在解决传统诊断协议（如UDS）在车联网时代面临的挑战。UDS协议虽然高效，但其依赖于ODX文件进行数据解析，导致客户端技术栈复杂且与诊断实现存在强耦合。SOVD通过以下特性解决了这些问题：

1.1 现代通信技术

现代汽车产生的数据量呈指数级增长，涵盖了从车辆状态到驾驶习惯的各个方面。这些数据不仅用于实时监控车辆性能，还为预测性维护和智能驾驶提供了基础。传统的诊断协议在处理如此庞大的数据量时，往往显得力不从心。SOVD协议通过采用基于HTTPS等现代通信技术，支持高带宽传输和远程诊断。

1.2 多场景支持

随着车联网技术的普及，远程诊断和服务的需求日益增加。SOVD协议支持远程、近端和车内诊断三种场景，使得技术人员可以在不需要直接接触车辆的情况下，通过移动宽带网络远程访问车辆数据和控制系统。这种能力不仅提高了诊断的便捷性，还降低了维护成本。

1.3 灵活性和动态性

SOVD协议的另一个显著特点是其灵活性和动态性。与传统的静态API描述不同，SOVD允许在运行时动态地定义和调用服务。这种设计使得系统能够根据不同的车辆和场景需求，灵活地调整诊断策略和服务，从而提高了系统的适应性和可扩展性。

1.4 标准化和互操作性

SOVD协议提供了一个标准化的诊断框架和统一的诊断接口，使得不同OEM（原始设备制造商）和供应商的系统可以互操作。这种标准化减少了专有协议带来的兼容性问题，促进了行业内的协作和创新。

1.5 UDS的兼容性

SOVD协议将UDS作为子集，支持传统微控制器的诊断。它兼容不同的硬件和软件平台，确保各种设备和系统之间的无缝通信。这种跨平台兼容性使得SOVD能够广泛应用于各种车辆和系统中，进一步推动了其在行业内的普及。

1.6 自解释协议

SOVD协议无需依赖外部ODX文件，数据解析可以由协议自身完成，简化了诊断流程并提高了效率。

#02

SOVD——面向服务的诊断

Adaptive AUTOSAR的SOVD（Service-Oriented Vehicle Diagnostics）是基于SOA（面向服务架构）的诊断框架，强调服务的动态发现和按需使用。这意味着SOVD不再依赖于传统的基于信号的通信，而是通过服务接口来提供诊断功能，更加灵活，适合现代车辆中复杂的软件架构和动态需求。

2.1 服务独立性

在SOVD协议中，诊断功能被分解成独立的服务模块。例如，发动机诊断服务、制动系统诊断服务和电池管理诊断服务都是独立的。这些服务各自运行，不相互依赖，确保系统的灵活性和稳定性。

2.2 松耦合设计

SOVD基于SOA架构，服务之间通过标准化接口进行通信，而不是直接调用。这意味着一个服务的变化不会直接影响其他服务。这种设计使得系统更易于维护和扩展，同时也提高了系统的可靠性。

2.3 服务重用

SOVD协议支持服务重用，某个诊断服务可以在不同的车辆和系统中重复使用。例如，标准化的发动机诊断服务可以应用于多种车型，而无需为每个车型单独开发。这种重用性提高了开发效率，降低了成本。

2.4 服务发现机制

SOVD协议引入了服务发现机制，诊断服务可以在需要时动态发现，而不是预先绑定到特定的服务实现。这意味着车辆系统可以在运行时根据当前需求发现和调用最合适的诊断服务，从而提高了系统的灵活性和资源利用率。

2.5 按需服务调用

SOVD协议支持按需调用诊断服务，而不是在系统启动时加载所有可能的服务。这种按需调用确保了系统资源的高效利用和服务的灵活性。当车辆某个部件需要诊断时，系统会发出请求，调用相关的诊断服务。诊断完成后，服务可以释放资源，等待下次调用。

2.6 实时响应和数据处理

动态诊断要求系统能够实时响应诊断请求，并处理和传输诊断数据。这种实时性对于确保车辆安全和性能至关重要。SOVD协议通过高效的通信协议（如HTTP、MQTT）和优化的服务实现，确保诊断请求能够快速响应，并实时传输诊断结果。

2.7 自适应能力

SOVD协议的动态诊断特性使得系统可以根据实际情况调整诊断策略和服务。例如，在不同的驾驶条件下或车辆状态下，系统可以自适应地选择合适的诊断服务和策略。这种自适应能力进一步提高了系统的灵活性和可靠性。

#03

SOVD协议的应用场景

3.1 远程诊断

SOVD协议支持远程诊断，允许技术人员或服务系统在不需要直接接触车辆的情况下，通过移动宽带网络远程访问车辆数据和控制系统。这种能力不仅提高了诊断的便捷性，还降低了维护成本。

3.2 近端诊断

当技术人员在车辆附近时，可以通过有线或无线方式连接到车辆的SOVD服务器，进行诊断操作。这种近端诊断方式结合了远程诊断的便捷性和传统诊断的精确性，进一步提高了诊断效率。

3.3 车辆内部诊断

SOVD协议还支持车辆内部的诊断任务，这些任务可以独立于外部服务器或近场测试器运行。例如，车辆健康监测、预测性维护等任务可以通过SOVD协议在车辆内部完成，从而提高了系统的自主性和可靠性。

#04

SOVD协议的技术架构

为了在分布式系统中提供中央SOVD边缘节点，需要引入一些基础设施组件。以下是SOVD技术架构的核心组件：

4.1 SOVD Gateway

4.2 SOVD到UDS的转换（SOVD to UDS Translation）

4.3 诊断管理器（AUTOSAR AP）

4.4后端连接

SOVD旨在支持近端、远程和车内诊断。SOVD通过引入mDNS对接近和车内访问进行了相对精确的标准化。标准化远程访问相对困难，因为它与后端基础设施存在许多依赖关系。AUTOSAR保持了这一自由度。尽管如此，通过某个后端连接功能模块将后端连接抽象化，从而将SOVD请求路由到SOVD网关是一个相对简单的解决方案。后端连接功能模块可以通过使用mDNS发现SOVD网关，而路由可以通过HTTP转发实现。

#05

SOVD用例实现

5.1 SOVD与UDS的通用用例

大部分SOVD用例可以直接映射到现有的UDS用例中，具体的映射过程在SWS Diagnostics文档中进行了详细描述。

对于与UDS（ISO 14229-1）相对应的用例，一个主要原则：重用与相应UDS服务相同的端口实例。这一设计原则为应用程序的开发带来了便利，因为无需集成具有冗余功能的额外端口。同时，这种实现方式也适用于与UDS相关的重入性和并行执行的相同规则。

然而，SOVD对某些用例的处理可能与其UDS对应项存在显著差异，因此需要采用不同的要求和机制。从方法论的角度来看，SOVD的方法通过使用DEXT配置机制来实现，仅在某些必要的地方进行扩展。具体的匹配方式如下：

DiagnosticDataIdentifier（简称DID）。DID是用于唯一标识ECU（电子控制单元）中的某个特定数据块或参数。在AUTOSAR自适应架构中，为了建立诊断服务配置参数（DiagnosticSovdConfigurationParameter）与具体诊断数据标识符（DiagnosticDataIdentifier）之间的关联，我们引入了诊断服务配置数据映射（DiagnosticSovdConfigurationDataIdentifierMapping）。这一映射机制明确了：

通过这样的映射关系，自适应AUTOSAR平台能够灵活地配置和管理诊断服务，确保诊断数据能够准确无误地被识别和处理。

DiagnosticDataIdentifier让我们在配置阶段就完全指定与诊断数据相关的有效载荷（payload）。

DID在车辆诊断系统中扮演着至关重要的角色，它用于唯一标识车辆控制单元（ECU）中可用于诊断的数据项。

DID的主要属性包括：

1. ‌dataElement（数据元素）‌：这是一个聚合属性，与DID相关联的诊断参数。它表示      DID所代表的具体数据项。该属性具有多个可能的值，并且可以被分割（由atpSplitable立体类型指示）和变化（由atpVariation立体类型指示）。分割键包括数据元素的位偏移量、数据元素标识符的短名称以及数据元素变化点的短标签。

2. ‌didSize（DID大小）‌：这是一个可选属性，表示DID的大小（以字节为单位）。它提供了关于DID所占用空间的信息。

3. ‌representsVin（表示VIN）‌：这也是一个可选属性，用于指示特定的DID是否代表车辆识别号（VIN）。如果为真，则意味着该DID与车辆的唯一识别信息相关联。

4. ‌supportInfoByte（支持信息字节）‌：这是一个可选的聚合属性，表示与DID相关联的支持信息。它提供了关于DID的额外信息，如诊断服务可能需要的特定配置或能力。

DiagnosticDataIdentifier是AUTOSAR自适应和经典架构中用于定义和管理诊断数据标识符的关键元类。它允许开发者在配置阶段就明确指定诊断数据的相关属性，从而确保诊断服务的准确性和可靠性。通过合理使用DID，可以大大提高车辆诊断系统的效率和准确性。

含义‌：指在服务导向车辆诊断系统中进行的配置设置，这些配置同样基于        DiagnosticDataIdentifier。配置信息可能包括DID的映射关系、诊断服         务的参数设置等。

作 用‌：SOVD配置使得诊断系统能够根据不同的车辆和诊断需求进行灵活        调整，确保诊断过程的准确性和有效性。

含义‌：指在服务导向车辆诊断系统中检测到的故障，这些故障通常源自            DiagnosticTroubleCodeUDS（简称DTC）。DTC是汽车电子诊断中用于       标识特定故障的代码，每个DTC都对应着一种特定的故障情况。

 诊断‌：SOVD故障通过诊断服务进行识别和报告，维修人员可以根据DTC         快速定位并解决车辆故障。

5.2 SOVD特定用例

SOVD还引入了一些特定用例，例如授权、接近挑战和软件更新。除了可配置的方法之外，还引入了两个标准化模式，以匹配现有的ISO 14229-1服务：0x28 CommunicationControl和0x85 ControlDTCSettings。实现这些映射所需的静态元数据源自在语义上对应的DEXT和清单属性。

对于从应用程序传递到诊断管理器的动态数据，诊断管理器需要进行解释。这一点与UDS（ISO 14229-1）解决方案有显著不同，因为在UDS中，诊断管理器可以直接将数据转发给测试仪，后者负责参数化处理。动态数据在DEXT中通过DiagnosticDataElements表示。

在数据解释的过程中，使用DiagnosticDataElement的SwDataDefProps中的compuMethod。诊断管理器必须根据这些compuMethod，将来自应用程序的字节流转换为有效的SOVD JSON格式，以供SOVD客户端使用，反之亦然。

5.2.1 访问权限

授权机制：在SOVD中，采用OAuth令牌进行授权，诊断管理器通过SovdAuthorization接口请求应用程序中的授权角色。

SOVD的授权过程依赖于OAuth令牌，这些令牌作为请求头的一部分。当诊断管理器接收到含有OAuth令牌的请求时，它将调用SovdAuthorization接口，以确定应用程序中编码的授权角色。凭借这个授权角色，诊断管理器能够判断SOVD客户端是否有权限执行特定的SOVD操作。

在此过程中，现有的DEXT模型相关于ISO 14229-1的服务0x29，被用来指定基础角色，包括DiagnosticAuthRoles以及DiagnosticAccessPermission与各个SOVD方法之间的关系。这种映射基于诊断管理器SOVD部分中描述的现有服务，确保DiagnosticAccessPermission与相应的SOVD方法之间的正确关联，从而保障系统的安全性和有效性。

5.2.2 软件更新

软件更新功能主要通过AUTOSAR更新和配置管理（UCM）框架以及诊断管理器实现。软件更新用例分为两类：“车辆更新”和“组件更新”。

1. 车辆级更新：由SOVD网关直接路由到OTA客户端，无需诊断管理器参与。

2.组件级更新：诊断管理器通过ara::diag接口与ara::ucm::PackageManagement集成，控制更新请求的转发。

在车辆更新的场景中，SOVD网关会将由任何SOVD客户端发起的请求路由到OTA客户端的SOVD接口，该接口能够独立处理更新，无需通过诊断管理器。但在组件更新的情况下，诊断管理器则发挥了关键作用。它提供了一个标准化接口ara::diag，该接口映射到ara::ucm::PackageManagement API。诊断管理器负责控制与软件更新相关的请求消息的转发，允许对更新服务进行分别的注册和注销。

ara::diag与ara::ucm之间的集成确保了在AUTOSAR自适应平台中，组件更新能够无缝处理。这种结构化的设计使得软件更新过程更加高效和可靠。

5.2.3 日志记录

系统中的日志记录功能未由ara::log标准化，因此日志文件的检索和管理细节以平台供应商特定的方式处理。这意味着ara::diag与ara::log之间的连接，特别是在读取日志文件方面，是基于平台供应商的指导和要求实现的。

5.2.4 大数据处理

通过ara::diag接口，诊断管理器负责管理大数据操作的各个方面。这些操作由自适应应用程序促进，自适应应用程序可以利用持久性机制和加密功能，例如签名生成和哈希验证。通过利用这些功能，自适应应用程序可以安全、受控地处理大数据的存储、检索和删除。

5.2.5 配置管理

ASAM理解的配置处理涉及两种方法：作为参数读取和写入配置，以及作为大数据读取和写入配置。通过引入一个名为ara::diag::GenericConfiguration的新接口，支持作为大数据的配置处理。该接口涵盖了ASAM SOVD标准中定义的所有方法。ara::diag::GenericConfiguration接口使诊断管理器能够根据授予的访问控制执行多个操作。这些操作可以通过自适应应用程序使用持久性和加密操作来完成。通过利用ara::diag::GenericConfiguration接口，作为大数据的配置处理得以简化，符合ASAM SOVD标准，并为汽车系统中的配置管理提供灵活性。

#06

小 结

SOVD通过面向服务的设计和现代化技术栈，为车辆诊断提供了高灵活性、高安全性的解决方案。其与AUTOSAR自适应平台的深度集成，支持从传统ECU到HPC的混合架构，满足未来车辆的远程诊断、动态更新与大数据处理需求。随着标准化进程的推进，SOVD将成为智能网联汽车诊断系统的核心支撑技术，推动汽车行业向智能化、网联化迈进。

相关文档与标准