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

操千曲尔后晓声，观千剑尔后识器。——刘勰

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

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

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

控制器状态信息（数据信息、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允许在没有外部描述文件的情况下进行诊断。然而，

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