新的车载诊断架构——面向服务的汽车诊断

诊断功能是车辆控制器自属的功能，通过诊断功能可以快速获取车辆控制器状态信息（数据信息、DTC故障信息）、Software Update等，它的模型如下：

作为应激式响应，ECU收到诊断请求后才会给与对应的响应。

随着HPC（高性能计算机）的引入，以及未来车辆中越来越多的车载系统以软件为基础，诊断必不可免面临着新的挑战。具有异构操作系统和大量并行进程的强大计算系统需要新的诊断功能（驱动力）。

与软件和汽车诊断相关的变更的频率显著提高（这也是敏捷开发逐渐成为车载软件开发必不可少的一种模型的原因），需要采用新的数据管理方法。

在这种情况下，面向服务的车载诊断（SOVD）项目于2019年在ASAM启动，旨在创建简单的新一代诊断接口，同时访问传统ECU和以软件为基础的新系统，实现远程、近端和车载诊断场景的统一访问。

“

车载诊断数据库ODX最初也是ASAM先提出并进行内容定义的，后续ISO组织纳入了ISO协议簇中（ISO22901）

”

由于HPC（大算力、实时性）的引入，以及汽车中越来越多的车载系统以软件为基础，诊断在以往的模型中逐渐不适应新的模式。

对HPC和应用程序进行诊断所需的数据很难与ODX（开放诊断交换格式）和UDS（统一诊断服务）的静态结构结合起来。本机应用程序还使用其他接口或数据格式，这些接口或格式很难映射到基于UDS的字节序列中。因为新的数据内容需要在诊断需求规范中先定义出来，并体现在诊断数据库中，作为代码配置工具的输入数据内容。

基于UDS的诊断需要为通信提供离线的静态描述，通常采用ODX格式。然而，越来越多的基于软件的架构的主要目标是将新的软件和功能快速灵活地“上车”。实际上，为软件的每个版本都提供适当的诊断描述几乎是不可能的。

在UDS中，诊断寻址基于静态标识符，不够灵活。通信矩阵在车辆项目前期已经定义完毕，中途的更改很复杂，因此很少进行更改。这与快速将新的软件组件引入汽车的需求形成对比。

即使在汽车中引入中央计算机系统后，仍有相当数量的传统ECU构成基于软件的功能的基石。出于需求和资源的考虑，传统ECU目前基于熟悉的软件平台（如AUTOSAR Classic），未来将继续如此。传统ECU采用基于UDS的诊断。因此，必须将这些诊断无缝集成到SOVD中。

在新的诊断框架中，主要目的如下：

-> 同时用于诊断和软件更新的统一API（应用程序编程接口）

-> 同时用于新系统和传统传感器/执行器系统的统一API

-> 使用场景：近端（通过有线/短距离无线通信连接到汽车），车载（随车行驶）和远程（离汽车很远）

-> 自我描述API允许在没有外部描述文件的情况下进行诊断。然而，未来仍需要一些外部描述，例如能够创建交叉变量测试序列

-> 应该选择并组合合适的现有技术，避免发明一种全新的技术

汽车中各种各样的软件组件和（带有处理器/控制器的）设备不仅有助于功能，也有助于诊断。在每个案例中，诊断和软件更新请求都会转发给相应的进程代理。

抽象而言，诊断请求是对特定资源的操作，例如：

-> 读取单个或一系列的测量值和系统参数

-> 读取事件和故障存储

-> 更改参数

-> 启动特殊诊断功能

-> 控制/访问执行器和传感器

此外，请求可以检索具体资源（硬件或软件部分）的自我描述（“能力描述”）。可以请求的诊断范围可能取决于请求者的角色或授权。自我描述包括当前角色可以请求的所有诊断范围。

如果请求被定向到支持UDS诊断的ECU，则必须将SOVD请求转换为UDS诊断，响应同样需要转换。将SOVD转换为UDS（反之亦然）称为“传统诊断适配器”。

对于请求者来说，请求是指向高性能计算机还是支持UDS的传统ECU应该没有区别。传统诊断适配器允许请求者使用SOVD API，并且只处理符号值和数据。

ASAM SOVD的目标是为新系统和传统传感器/执行器的诊断制定统一的API。

开发ASAM SOVD的一个重要前提是使用适当的技术，而不是发明（或重新发明）新技术。SOVD API基于http/REST方法。

ASAM SOVD API支持查询自我描述，以避免依赖外部数据规范。尽管如此，仍有离线文档和规范的相关机制，以支持开发、生产和售后过程。

ASAM SOVD关注接口（API）的定义。在汽车上实施SOVD不是ASAM项目的主题。然而，AUTOSAR已经开展如何实施SOVD的活动(2022版最新AUTOSAR规范中已经对SOVD做了规范定义)。

2022年6月底，ASAM SOVD 1.0.0版本正式发布。用于应对智能网联汽车时代井喷的软件诊断需求，SOVD如何应对呢？

ASAM SOVD (Service-Oriented Vehicle Diagnostics，面向服务的车辆诊断) 定义了一个与基于软件的车辆进行诊断和通信的接口API。SOVD是一个灵活的标准，提供了统一的访问HPC (High Performance Computing，高性能计算机) 及其相关应用的诊断内容，以及经典的ECU等。

随着自动驾驶技术的发展，车辆配置变得越来越复杂，车载软件也在迅速增长：基于高性能计算、多操作系统、不同应用程序及其依赖关系的新架构也给诊断工作带来了重大挑战。诊断的重点从识别硬件错误逐渐扩展到分析软件问题，因此带来了巨大的挑战。因为车辆的内容是动态变化的，同时当诊断通信被用于控制车辆复杂的更新过程时，诊断任务的范围也急剧增加。

目前的诊断以ECU为核心，严重依赖于UDS (Unified Diagnostic Services，统一诊断服务) 协议。UDS是一种静态的诊断方法，无法应用于动态的软件诊断任务。因此，为HPC诊断需求扩展的UDS协议将不够灵活，无法满足必要的软件分析需求。

这就是ASAM开发与制定SOVD的原因。该标准旨在为所有诊断任务以及软件更新（跨车辆、车型）提供一个API。SOVD是具有一致性的方法，可用于全新系统，也可用于传统的传感器/执行器系统，同时，ASAM SOVD可用于近程、远程和车载三种应用场景。SOVD是一个自描述API，还支持无需外部描述文件的诊断，有别于当前的主流技术。

ASAM SOVD的开发旨在保持现有的程序、技术和方法的前提下，满足车载软件诊断的相关需求和挑战。因此，ASAM SOVD既涵盖了传统的用例(数据访问、故障信息、内部软件功能控制等)，也涵盖了与HPC相关的诊断用例(车载软件更新、日志记录、跟踪、系统信息访问、内容动态发现等)。另一方面，SOVD并非为了取代广泛使用的技术，如UDS协议，而是与其共存，同时增强诊断通信功能，更好地支持新技术的发展与应用。

ASAM SOVD的主要内容与更新包括以下部分：

-> SOVD为诊断提供了新的接口API；

-> 适用于远程、近程和车载应用场景；

-> 支持最先进的IT技术(HTTP, REST, JSON, OAuth)；

-> 诊断可以独立于诊断数据描述文件；

-> 整个计算过程被封装，使无状态访问成为可能；

-> 客户端实现不需要汽车特定的堆栈。

ASAM SOVD总体特性包括：

-> 可覆盖传统诊断用例：

-> 数据访问（Data Access）；

-> 故障信息（Fault Information）；

-> 控制内部软件功能（Internal Software-functions）。

可覆盖高性能计算相关的诊断用例：

-> 车辆软件升级（Software update）；

-> 记录（Logging）；

-> 访问系统信息（Access to system information）；

-> 动态内容发现（Dynamic discovery of content）；

在能力检测方面，可进行相关实体与资源的检查与发现：

-> 发现包含的实体；

-> 查询实体的子实体；

-> 查询实体相关的其他实体；

-> 查询实体功能；

-> 代表实体区域的拓扑视图，能够代表面向领域和面向区域的体系结构

访问功能描述内容：

-> 查询在线能力描述；

-> 查询模式信息，用于内容处理