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

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

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

诊断功能是车辆控制器自属的功能，通过诊断功能可以快速获取车辆

控制器状态信息（数据信息、DTC故障信息）、SoftwareUpdate

等，它的模型如下：

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

随着HPC（高性能计算机）的引入，以及未来车辆中越来越多的车载

系统以软件为基础，诊断必不可免面临着新的挑战。具有异构操作系

统和大量并行进程的强大计算系统需要新的诊断功能（驱动力）。

与软件和汽车诊断相关的变更的频率显著提高（这也是敏捷开发逐渐

成为车载软件开发必不可少的一种模型的原因），需要采用新的数据

管理方法。

在这种情况下，面向服务的车载诊断（SOVD）项目于2019年在

ASAM启动，旨在创建简单的新一代诊断接口，同时访问传统ECU

和以软件为基础的新系统，实现远程、近端和车载诊断场景的统一访

问。

“

车载诊断数据库ODX最初也是ASAM先

提出并进行内容定义的，后续ISO组织纳入了

ISO协议簇中（ISO22901）

”

由于HPC（大算力、实时性）的引入，以及汽车中越来越多的车载系

统以软件为基础，诊断在以往的模型中逐渐不适应新的模式。

对HPC和应用程序进行诊断所需的数据很难与ODX（开放诊断交换

格式）和UDS（统一诊断服务）的静态结构结合起来。本机应用程序

还使用其他接口或数据格式，这些接口或格式很难映射到基于UDS的

字节序列中。因为新的数据内容需要在诊断需求规范中先定义出来，

并体现在诊断数据库中，作为代码配置工具的输入数据内容。

基于UDS的诊断需要为通信提供离线的静态描述，通常采用ODX格

式。然而，越来越多的基于软件的架构的主要目标是将新的软件和功

能快速灵活地“上车”。实际上，为软件的每个版本都提供适当的诊

断描述几乎是不可能的。

在UDS中，诊断寻址基于静态标识符，不够灵活。通信矩阵在车辆项

目前期已经定义完毕，中途的更改很复杂，因此很少进行更改。这与

快速将新的软件组件引入汽车的需求形成对比。

即使在汽车中引入中央计算机系统后，仍有相当数量的传统ECU构成

基于软件的功能的基石。出于需求和资源的考虑，传统ECU目前基于

熟悉的软件平台（如AUTOSARClassic），未来将继续如此。传统

ECU采用基于UDS的诊断。因此，必须将这些诊断无缝集成到

SOVD中。

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

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

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

-使用场景：近端（通过有线/短距离无线通信连接到汽车），车载

（随车行驶）和远程（离汽车很远）

-自我描述API允许在没有外部描述文件的情况下进行诊断。然而，

未来仍需要一些外部描述，例如能够创建交叉变量测试序列

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

汽车中各种各样的软件组件和（带有处理器/控制器的）设备不仅有助

于功能，也有助于诊断。在每个案例中，诊断和软件更新请求都会转

发给相应的进程代理。

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

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

-读取事件和故障存储

-更改参数

-启动特殊诊断功能

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

此外，请求可以检索具体资源（硬件或软件部分）的自我描述（“能

力描述”）。可以请求的诊断范围可能取决于请求者的角色或授权。

自我描述包括当前角色可以请求的所有诊断范围。

如果请求被定向到支持UDS诊断的ECU，则必须将SOVD请求转换

为UDS诊断，响应同样需要转换。将SOVD转换为UDS（反之亦

然）称为“传统诊断适配器”。

对于请求者