CN110515366A - 一种故障诊断方法及装置 - Google Patents

Abstract

一种故障诊断方法及装置，以实现将诊断仪与车载诊断系统的开发过程解耦合，解决由于需要频繁更新DTC等信息导致的诊断出错的问题，提升诊断仪的通用性。该方法包括：接收来自诊断仪的故障诊断请求，故障诊断请求包括第一DTC和第一信息，第一DTC用于标识故障，第一信息用于指示请求故障的第一故障信息，根据故障诊断请求生成故障诊断响应，故障诊断响应中包括第一DTC、第一描述信息、第一故障信息以及第二描述信息，其中，第一描述信息用于解释第一DTC，第二描述信息用于解释第一故障信息，向诊断仪发送故障诊断响应。

Description

一种故障诊断方法及装置

技术领域

本申请涉及汽车故障诊断技术领域，尤其涉及一种故障诊断方法及装置。

背景技术

随着电子技术的发展，目前可在汽车中装载车载诊断系统，例如常见的车载诊断系统有电子控制单元(electronic control unit，ECU)，车载诊断系统可用于记录汽车使用过程中发生的故障，例如可记录诊断故障码(diagnostic trouble codes，DTC)以及故障信息。当汽车发生故障需要进行故障诊断时，可以将汽车的车载诊断系统与诊断仪相连，诊断仪可以通过读取车载诊断系统中的故障信息完成故障诊断。现有技术中，诊断仪实现故障诊断的过程如下：诊断仪从车载诊断系统获取DTC和故障信息，进而可根据部署的描述信息库中存储的描述信息解释DTC以及故障信息，可以理解为根据描述信息将获取到的DTC以及故障信息转换为用户可读的字符串，并在显示界面显示该字符串，以便用户查看本次故障原因。

采用现有技术的诊断方法，诊断仪需要维护描述信息库，且，需要从第三方(例如设备生产商或车载诊断系统的开发者)获取完整的描述信息，例如，需要获取DTC的描述信息和/或故障信息的描述信息等。当修改DTC和/或故障信息的描述信息，或新增DTC以及相应的故障信息时，诊断仪需要重新获取被修改或新增的描述信息。随着自动驾驶技术的发展，未来汽车会不断叠加新功能或将老功能修改为新功能，那么就需要频繁引入新的诊断功能、新DTC以及新故障信息，进而导致诊断仪需要频繁获取新信息并更新维护的描述信息库，鉴于诊断仪有限的处理能力，可能不能及时获取到新信息，这样便可能导致后续诊断出错。

针对现有技术中，为适应新业务场景，诊断仪需要频繁获取新DTC以及新故障信息等，导致后续诊断出错的问题，目前尚未提出有效的解决方案。

发明内容

本申请实施例提供一种故障诊断方法及装置，用以解决由于需要频繁更新DTC等信息导致的诊断出错的问题。

第一方面，本申请实施例提供了一种故障诊断方法，可应用于车载诊断系统，该方法包括：接收来自诊断仪的故障诊断请求，故障诊断请求中包括第一DTC和第一信息，第一DTC用于标识故障，第一信息用于指示请求故障的第一故障信息，根据故障诊断请求生成故障诊断响应，并向诊断仪发送故障诊断响应，其中，故障诊断响应中包括第一DTC、第一描述信息、第一故障信息以及第二描述信息，第一描述信息用于解释第一DTC，第二描述信息用于解释第一故障信息。

该方法可由第一装置执行，第一装置可以是车载诊断系统或能够支持车载诊断系统实现该方法所需的功能的装置，当然还可以是其他装置，例如芯片系统。这里以第一装置是车载诊断系统为例说明。

通过上述方法，诊断仪从车载诊断系统获取DTC所标识故障的故障信息时，同时可获取到该DTC的描述以及该故障信息的描述信息，这样，在诊断仪端不需要维护描述信息库便可获知DTC以及故障信息的含义，即使DTC和故障信息发生更新，诊断仪也无需再获取更新后的信息，进而可避免由于诊断仪需要频繁获取更新后的信息导致的诊断出错问题，且，由于各个诊断仪不再需要维护不同的描述信息库，故可提升诊断仪的通用性。

在一种可能的实施方式中，可采用如下方式生成故障诊断响应：根据第一DTC以及预先存储的第一对应关系，确定与第一DTC对应的第一描述信息，并根据故障诊断请求获取预先存储的第一故障信息，并根据第一故障信息以及预先存储的第二对应关系，确定与第一故障信息对应的第二描述信息，进而生成包含第一DTC、第一描述信息、第一故障信息以及第二描述信息的故障诊断响应。其中，第一对应关系包括多个DTC与多个描述信息的一一对应关系，多个DTC包括第一DTC，第二对应关系包括多个故障信息与多个描述信息的一一对应关系，多个故障信息包括第一故障信息。采用该方法，可使得诊断仪在获取故障信息的同时获取到DTC和故障信息的描述信息，实现DTC和故障信息的自解释。

在一种可能的实施方式中，故障诊断响应中还可以包括第二信息，第二信息用于指示故障诊断响应为包含描述信息的诊断响应，或者，第二信息用于指示故障诊断响应的类型为包含描述信息的响应类型。采用该方法，在本申请提供的方法与现有技术的方法共同使用的场景下，可将本申请的诊断响应类型与现有技术中的诊断响应类型区别开来。

在一种可能的实施方式中，第一故障信息包括但不限于故障的快照信息或故障的扩展信息，其中，故障的快照信息是指故障发生时刻记录的用于分析故障的原因信息，故障的扩展信息是指除故障的快照信息之外的用于分析故障的原因信息。可以理解，快照信息与扩展信息仅作为故障信息的两个举例，其它类似的故障信息也可适用本申请的方法。

第二方面，本申请实施例提供了一种故障诊断方法，可应用于诊断仪，该方法包括：向车载诊断系统发送故障诊断请求，故障诊断请求包括第一DTC和第一信息，第一DTC用于标识故障，第一信息用于指示请求故障的第一故障信息，接收来自车载诊断系统的故障诊断响应，解析故障诊断响应，并显示解析后的故障诊断响应中的第一描述信息和第二描述信息，其中，故障诊断响应中包括第一DTC、第一描述信息、第一故障信息以及第二描述信息，第一描述信息用于解释第一DTC，第二描述信息用于解释第一故障信息。

该方法可由第二装置执行，第二装置可以是诊断仪或能够支持诊断仪实现该方法所需的功能的装置，当然还可以是其他装置，例如芯片系统。这里以第二装置是诊断仪为例说明。

在一种可能的实施方式中，故障诊断响应中还可以包括第二信息，第二信息用于指示故障诊断响应为包含描述信息的诊断响应，或者，第二信息用于指示故障诊断响应的类型为包含描述信息的响应类型。采用该方法，可将本申请的诊断响应类型与现有技术中的诊断响应类型区别开来。基于该实施方式，解析故障诊断响应之后，还包括：删除故障诊断响应中包括的第二信息。由于第二信息仅用于区分接收到的故障诊断响应的类型，不属于故障原因分析的内容，故删除该信息后便于用户阅读最后的故障描述信息。

在一种可能的实施方式中，第一故障信息包括但不限于故障的快照信息或故障的扩展信息，其中，故障的快照信息是指故障发生时刻记录的用于分析故障的原因信息，故障的扩展信息是指除故障的快照信息之外的用于分析故障的原因信息。可以理解，快照信息与扩展信息仅作为故障信息的两个举例，其它类似的故障信息也可适用本申请的方法。

第三方面，本申请实施例提供了一种故障诊断装置，该装置具有实现上述任意方面或任意方面中的实现方法的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。

第四方面，本申请实施例提供了一种故障诊断装置，包括：处理器和存储器；该存储器用于存储计算机执行指令，当该装置运行时，该处理器执行该存储器存储的该计算机执行指令，以使该装置执行如上述任意方面或任意方面中的实现方法。

第五方面，本申请实施例提供了一种故障诊断装置，包括：包括用于执行以上任意方面各个步骤的单元或手段(means)。

第六方面，本申请实施例提供了一种故障诊断装置，包括处理器和接口电路，所述处理器用于通过接口电路与其它装置通信，并执行以上任意方面提供的任意方法。该处理器包括一个或多个。

第七方面，本申请实施例提供了一种故障诊断装置，包括处理器，用于与存储器相连，用于调用所述存储器中存储的程序，以执行上述任意方面的任意实现方式中的方法。该存储器可以位于该装置之内，也可以位于该装置之外。且该处理器包括一个或多个。

第八方面，本申请还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得处理器执行上述任意方面所述的方法。

第九方面，本申请还提供一种包括指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述任意方面所述的方法。

第十方面，本申请还提供一种芯片系统，包括：处理器，用于执行上述各方面所述的方法。

第十一方面，本申请还提供一种系统，包括用于执行上述第一方面或第一方面任一实现方法的车载诊断系统，以及用于执行上述第二方面或第二方面任一实现方法的诊断仪。

附图说明

图1a为本申请实施例提供的一种诊断请求格式示意图；

图1b为本申请实施例提供的另一种诊断请求格式示意图；

图1c为本申请实施例提供的一种诊断响应格式示意图；

图1d为本申请实施例提供的又一种诊断请求格式示意图；

图2a为本申请实施例提供的一种AUTOSAR经典平台架构示意图；

图2b为本申请实施例提供的一种AUTOSAR自适应平台架构示意图；

图3a为本申请实施例提供的一种诊断仪结构示意图；

图3b为本申请实施例提供的一种诊断仪工作过程示意图；

图4为本申请实施例提供的一种诊断仪的开发过程示意图；

图5为本申请实施例提供的一种ECU结构示意图；

图6为本申请实施例提供的一种ECU与诊断仪交互示意图；

图7a为本申请实施例提供的一种系统架构；

图7b为本申请实施例提供的另一种系统架构；

图7c为本申请实施例提供的又一种系统架构；

图8为本申请实施例提供的一种故障诊断方法；

图9a为本申请实施例提供的另一种故障诊断方法；

图9b为本申请实施例提供的又一种故障诊断方法；

图10为本申请实施例提供的一种故障诊断装置；

图11为本申请实施例提供的另一种故障诊断装置；

图12为本申请实施例提供的又一种故障诊断装置；

图13为本申请实施例提供的又一种故障诊断装置。

具体实施方式

下面结合说明书附图对本申请进行详细说明。

首先，对本申请中的部分用语进行解释说明，以便于本领域技术人员理解。

1)统一诊断服务(unified diagnostic service，UDS)协议，即国际标准化组织(international organization for standardization，ISO)-14229，是一种应用层协议，是诊断服务的规范化标准，对所有的诊断命令进行了标准化定义，例如定义了诊断请求(diagnostic request)和诊断响应(diagnostic response)的消息格式。UDS协议可以在多种协议之上实现，例如，14229-5定义了UDS协议可在网际协议(internet protocol，IP)协议上实现(diagnostic over internet protocol，DoIP)，又例如，14229-3定义了UDS协议在控制器局域网络(controller area network，CAN)总线上实现。下面对UDS协议定义的诊断请求和诊断响应的格式简单说明。

UDS为不同诊断功能的诊断请求和诊断响应定义了统一的格式。诊断请求的格式可以分为两类：一类格式包含子服务(sub-function)，另一类格式不包含sub-function，如图1a和图1b所示。本申请实施例中主要以包含sub-function的诊断请求为例说明。请参见图1c所示，为针对包含sub-function的诊断请求的诊断响应格式。UDS协议中规定服务标识与响应标识相差预设值，当响应节点在回复诊断请求时，可由服务标识推得响应标识。

下面以UDS协议中定义的服务标识为0x19的服务为例举例说明，0x19服务用于读取DTC的信息(read DTC information)，0x19服务包括多个子服务，例如子服务0x04用于请求指定DTC的快照信息，子服务0x06请求指定DTC的扩展信息(环境数据)，0x02用于读取符合特定条件的DTC列表等。请参见图1d所示，其为请求0x19服务的子服务0x06的诊断请求格式，该请求用于读取/请求所述格式中指定的DTC的扩展信息，此时参数(parameter)为4个字节(byte)，前三个byte用于标识指定的DTC，第四个byte用于标识要读取的扩展信息的范围，UDS协议中规定使用FF来表示读取全部的扩展信息，各厂家可以根据实际需要来定义其他的值，以代表要读取的扩展信息的范围。常见的扩展信息可包括DTC状态、优先级、发生次数、老化计数器、时间戳或里程等。

2)汽车开放系统架构(AUTOmotive open system architecture，AUTOSAR)，是由全球汽车制造商、部件供应商及电子软件系统公司联合建立，是一个开放的、标准化的软件架构，是对汽车技术开发一百多年来的经验总结。AUTOSAR主要具备以下特点：

a、AUTOSAR致力于解决硬件平台不同带来的软件开发的困难，使开发者能够专注于汽车软件功能上的创新；

b、AUTOSAR提供标准的软件接口定义，工程师可以根据实际需求将所需要的软件组件分配到汽车的ECU中，实现标准软件组件的可重用性；

c、AUTOSAR的应用层软件组件是独立于硬件的，应用开发者可以在应用软件中指定各个车辆功能的细节，而不用担心底层软件服务和硬件接口不兼容的问题。

AUTOSAR组织先后发布了AUTOSAR经典平台(classical platform，CP)架构以及AUTOSAR自适应平台(adaptive platform，AP)架构，分别如图2a和图2b所示。

如图2a所示，AUTOSAR经典平台架构包括应用软件层(application layer)、运行环境(runtime environment，RTE)层、服务层(services layer)、ECU抽象层(ECUabstraction layer)、微控制器抽象层(microcontroller abstraction layer)、复杂驱动(complex device drivers)以及微控制器。下面简单介绍各个层的作用。

应用软件层封装了部分或全部汽车电子的功能与行为，包括对具体模块功能的实现以及对应描述，对外界仅开放定义好的接口，而所有ECU内部组件之间的通信及获取其他ECU资源的动作需要通过接口来访问RTE完成。应用软件层内的通信关系如下：软件组件能和同一个ECU上其他软件组件通信，软件组件能和位于不同ECU上的其他软件组件通信，软件组件能和有端口并位于同一个ECU上的基础软件(basic software，BSW)进行通信。

基础软件层划分为服务层、ECU抽象层、微控制器抽象层以及复杂驱动。以下分别简单介绍。

其中，服务层又可分为如下3个部分：

1、通信服务(communication services)，对上层的应用软件层隐藏了协议以及报文属性，可提供统一的总线通信接口供应用软件层调用，并可提供统一的网络管理服务，并可提供统一的诊断通信接口；

2、存储服务(memory services)，将微控制器内外内存的访问进行统一封装，以统一的格式为上层的应用软件层传输非易失性数据，抽象了内存地址以及属性，为数据的保存、加载、校验保护、验证以及安全存储提供了统一的机制；

3、系统服务(system services)，可以提供包括中断管理、资源管理、任务管理、功能禁止管理、通信管理、ECU状态管理、看门狗管理、同步时钟管理或基本软件模式管理等服务。

其中，ECU抽象层又可分为以下4个部分：

1、I/O硬件抽象层(I/O hardware abstraction)，通过I/O硬件抽象中的信号接口来访问不同的I/O设备，对电流、电压、频率等I/O信号进行封装传输，对上层的应用软件层隐藏下层的ECU硬件；

2、通信硬件抽象层(communication hardware abstraction)，通信硬件抽象将微控制器及板上所有的通信信道都进行了封装，并对CAN、面向媒体的系统传输(mediaoriented systems transport，MOST)等通信方式进行了抽象的定义；

3、内存硬件抽象层(memory hardware abstraction)，将片内、板上的内存资源进行统一封装，如对片内带电可擦写可编程只读存储器(electrically erasableprogrammable read-only memory，EEPROM)和片外的EEPROM都提供了统一的访问机制；

4、车载设备抽象层(on-board hardware abstraction)，对ECU上特殊的一些外设进行封装，如看门狗(watchdog)以及时钟等。

其中，微控制器抽象层又可分为如下4个部分：

1、I/O驱动(I/O drivers)，用于驱动模拟及数字I/O信号；

2、通信驱动(communication drivers)，负责车辆各模块及整车通信等；

3、内存驱动(memory drivers)，控制设备芯片内存(如片内闪存、EEPROM)及外部映射设备(外置闪存)；

4、微处理器驱动(microcontroller drivers)，驱动如看门狗、时钟模块(clockunit)并负责随机存取存储器(random access memory，RAM)测试及对微控制器抽象层内部设备和映射的微控制器抽象层外部设备的内存访问等功能。

其中，复杂驱动可通过对复杂传感器评估，实现实时性高的传感器采样等功能。

自适应平台与经典平台各层的含义类似，本申请不再赘述。

3)汽车诊断仪，也可以称为诊断仪或上位机，是一款专门针对汽车检测的专业仪器，检测车辆的性能、车辆故障，是检测车辆必备的一种工具，其中，诊断仪可通过开发的诊断仪软件实现对汽车的诊断，以图形化界面的方式呈现各种诊断结果，因此，安装有诊断仪软件的设备均可以理解为诊断仪，一些诊断仪的举例，例如安装有诊断仪软件的个人计算机(personal computer，PC)、平板电脑或专用设备等。请参见图3a所示，是自动化及测量系统标准协会(association for standardization of automation and measuringsystems，ASAM)制定的一种标准架构诊断仪。如图3a所示，该诊断仪包括应用层、诊断服务接口(diagnostic server API，D-Server API)、模块化车辆通信接口(modular vehiclecommunication interface，MVCI)运行系统(MVCI runtime system)(MVCI-RTE)、诊断协议数据单元接口(diagnostic protocol data unit API，D-PDU API)、车辆通信接口(vehicle communication interface，VCI)、诊断信息库以及显示仪。其中，应用层实现诊断的上层功能，如实现诊断仪中读取故障功能、下线设备中钥匙匹配功能或测试设备中的测试用例等。D-Server API，是指应用层与MVCI-RTE之间的接口，由ISO标准化定义。MVCI-RTE，负责将应用层的功能转换成诊断请求，或者在收到诊断响应后，与诊断信息库(例如开放式诊断数据格式(open diagnostic data exchange，ODX)数据库)进行交互，将诊断响应解析为应用层格式的数据传给应用层。D-PDU API是指MVCI-RTE与VCI之间的接口，由ISO标准化定义。VCI是车载诊断系统(例如ECU)与车辆外接设备之前的硬件接口，实现不同信号载体之间数据的传输。显示仪通常可包括显示界面，可用于显示诊断结果。

需要说明的是，图3a所示的诊断仪仅作为一种实例，本申请以下提供的方法不仅可用于图3a所示的诊断仪，也可以应用于其它架构的诊断仪。

以下简单介绍一下诊断仪的工作过程。

请参见图3b，其为一种诊断仪工作过程示意图，如图3b所示，现有技术中诊断仪工作过程可包括如下步骤：

步骤0，启动诊断仪，并启动诊断任务。

步骤1，启动诊断任务后，诊断仪可通过诊断软件从车载诊断系统读取DTC以及对应的故障信息。DTC以及对应的故障信息本质是一些数值。

步骤2，诊断仪通过查询诊断信息库，获知DTC以及对应的故障信息的含义或描述信息，相当于，诊断仪通过查询诊断信息库，将一些数值转换为用户可识别的字符串。诊断信息库中可以存储DTC与DTC描述信息的对应关系，以及，DTC故障信息与DTC故障信息的描述信息的对应关系。例如，若诊断仪通过步骤1从车载诊断系统获取到的DTC为xxyyzzcc，则可通过查询诊断信息库，将“xxyyzzcc”转换为“引擎故障”等。其中，诊断信息库是一种数据库，可以部署在本地，也可以部署在远端(如云上)。

步骤3，诊断仪通过显示仪显示转换后的描述信息，使得用户可通过显示仪显示的内容确定汽车故障原因。

以下简单介绍一下诊断仪的开发过程。

请参见图4，其为本申请提供的一种诊断仪的开发过程示意图。对于诊断仪的开发，可涉及到三类角色：主机厂设计者、ECU开发者以及诊断仪开发者，三者之间的关系如下：

步骤1：主机厂设计者定义诊断需求、DTC、DTC的含义、DTC对应的故障信息以及所述故障信息的含义等。一些情况下，ECU开发者也可以参与到该过程，主机厂设计者可与ECU开发者共同确定诊断需求、DTC、DTC的含义、DTC对应的故障信息以及所述故障信息的含义等参数或信息。此处DTC可以理解为主机厂设计者，或主机厂设计者与ECU开发者，自定义的DTC，除自定义的DTC之外，还有一些DTC是UDS协议规定的。UDS协议规定的DTC只有不到2000条左右，而一个车型涉及的DTC一般在1万条左右，因此更多是主机厂(即车厂)自定义的DTC。其中，主机厂例如可以是各家汽车生产商，例如丰田、宝马、大众等汽车厂。

步骤2：主机厂设计者将步骤1定义的信息或参数，以特定的数据格式下发给ECU开发者以及诊断仪开发者。

步骤3a：ECU开发者按主机厂设计者下发的信息所要求的内容，写代码，使得该代码在汽车装载的ECU中运行时，产生并记录DTC，以及产生并记录DTC对应的故障信息，例如快照信息以及扩展信息等。

步骤3b：诊断仪开发者按主机厂设计者下发的信息所要求的内容，写代码，使得该代码在诊断仪中运行时，可使得诊断仪查询DTC以及对应的故障信息，并正确解析该信息。

需要说明的是，在研发阶段，主机厂设计者可以采用.doc或.rtf格式描述诊断需求等信息；在测试验证阶段，主机厂设计者可以采用.cdd的格式描述诊断需求等信息；在生产、ECU代码实现及售后阶段，诊断需求的描述格式也不相同。信息交换的双方，通常是按各自的既有习惯进行约定。

4)车载诊断系统(on-board diagnostic system，OBD)，安置于汽车中，可用于实时记录汽车在行驶过程中发生的故障，通常以DTC的形式记录，以及发生故障时汽车的快照信息、扩展信息(也可以描述为环境数据)等，其中，故障的快照信息是指故障发生时刻记录的用于分析故障原因的信息或数据，故障的扩展信息是指除故障的快照信息之外的用于分析故障原因的其它信息，扩展信息例如可包括发生该故障的次数、自恢复的次数、时间或温度等，具体数据可自定义。本申请下文中以车载诊断系统为ECU为例说明，ECU又可称为“行车电脑”或“车载电脑”或“下位机”。其中ECU的软件系统架构，主流是AUTOSAR，AUTOSAR平台对于ECU上的诊断功能，有一整套软件规范。请参见图5所示，其为一种基于AUTOSAR平台实现的ECU结构示意图，该ECU结构中，诊断事件管理(diagnostic event manager，DEM)模块和诊断通信管理(diagnostic communication manager，DCM)模块是诊断服务的核心模块，在汽车行驶过程中DEM模块可将产生的故障的DTC和故障信息实时存储到存储服务/存储单元/存储器中，在需要时将数据提供给DCM模块，DCM模块为诊断提供通信服务以及根据外部诊断工具的要求和DEM模块共同提供诊断服务，DCM模块可以将外部诊断工具所需要的信息从DEM模块中获取并传递。例如，该ECU可通过DCM模块接收诊断仪发送的诊断请求，DCM模块接收到诊断请求后可向DEM模块发送该诊断请求，DEM模块接收到该诊断请求后可解析该请求，并生成相应的诊断响应，再通过DCM模块将该诊断响应发送至诊断仪，以使诊断仪完成诊断。

以上3)和4)分别介绍了诊断仪和车载诊断系统，下面以诊断仪和车载诊断系统的交互来简单说明诊断仪如何借助汽车中的车载诊断系统实现故障诊断。

请参见图6，其为一种故障诊断示意图，图6中以车载诊断系统为ECU为例示意，该ECU可以但不限于为图5所示的结构。需要说明的是，图6中诊断仪的结构仅作为示意，实际中诊断仪可以是各种结构。如图6所示，从用户的角度看，在诊断仪与ECU通信的过程中，可由诊断仪发出诊断请求，由ECU给出诊断响应，诊断仪和ECU分别是计算机网络通信中的客户端(client)和服务端(server)的角色。其中，本申请实施例中以诊断请求和诊断响应为UDS协议定义的格式为例说明，图6所示的诊断请求中可包括服务标识，进一步还可以包括子服务(标识)以及参数等，诊断响应中可包括返回的数据/参数，所述参数例如可以是DTC以及与该DTC对应的故障信息。由图3a所示的诊断仪的工作过程可知，诊断仪接收到DTC以及与该DTC对应的故障信息后，需要从诊断信息库获取DTC以及故障信息的含义或描述信息，并在显示仪的显示界面显示该描述，以便用户查看本次故障原因。采用现有技术的诊断方法，诊断仪需要实时更新诊断信息库，且，需要从第三方(例如设备生产商或车载诊断系统的开发者)获取完整的描述信息。当修改DTC和/或故障信息的描述信息，或新增DTC以及相应的故障信息时，诊断仪需要重新获取被修改或新增的信息，随着自动驾驶技术的发展，未来汽车会不断叠加新功能或将老功能修改为新功能，那么就需要频繁引入新的诊断功能、新DTC以及新故障信息，进而导致诊断仪需要频繁获取新信息并更新维护的描述信息库，鉴于诊断仪有限的处理能力，可能不能及时获取到新信息，这样便可能导致后续诊断出错。

鉴于上述存在的问题，本申请提供一种故障诊断方法，在车载诊断系统端维护DTC以及故障信息的描述信息，在诊断仪请求DTC以及故障信息时，一并将DTC以及故障信息的描述发送至诊断仪，以使诊断仪无需查询诊断信息库，就可以获知DTC以及故障信息的含义，进而在显示仪显示诊断结果。由于通过本申请的方法，诊断仪不需要再维护诊断信息库，也无需再从主机厂或车载诊断系统开发端获取DTC以及故障信息的描述信息等信息，进而可解决由于诊断信息库需要频繁更新DTC等信息导致的诊断出错的问题。可以理解，随着自动驾驶技术的广泛落地，诊断仪以及车载诊断系统的一些软硬件发生巨大变化，例如，诊断仪与车载诊断系统之间的接入方式由CAN总线转向以太总线(带宽大幅提升)，车载诊断系统的处理器从单片机(MHz级别的主频，KB级存储空间)提升为服务器，计算能力、存储能力大幅提升等，基于这些变化，使得本申请提供的方法更容易实现。

请参见图7a，为本申请可适用的一种系统架构。图7a中的系统架构包括的ECU为基于AUTOSAR经典平台实现的，该ECU诊断相关的软件模块处于服务层中，主要包括DCM、DEM以及存储服务或存储模块或存储器(例如非易失性存储器)。在汽车行驶过程中DEM可将产生的故障的DTC和故障信息实时存储到存储服务/存储单元/存储器中，当通过诊断仪检测故障时，该ECU可通过DCM模块接收诊断仪发送的诊断请求，DCM模块接收到诊断请求后可向DEM模块发送该诊断请求，DEM模块接收到该诊断请求后可解析该请求，从存储服务中获取请求的数据，并生成相应的诊断响应，再通过DCM模块将该诊断响应发送至诊断仪，以使诊断仪完成诊断。

请参见图7b，为本申请可适用的另一种系统架构。图7b中的系统架构包括的ECU为基于AUTOSAR自适应平台实现的，该ECU诊断相关的软件模块也包括DCM、DEM以及数据存储模块。在汽车行驶过程中DEM可将产生的故障的DTC和故障信息实时存储到数据存储模块中，当通过诊断仪检测故障时，该ECU可通过DCM模块接收诊断仪发送的诊断请求，DCM模块接收到诊断请求后可向DEM模块发送该诊断请求，DEM模块接收到该诊断请求后可解析该请求，从数据存储模块中获取请求的数据，并生成相应的诊断响应，再通过DCM模块将该诊断响应发送至诊断仪，以使诊断仪完成诊断。

无论是图7a还是图7b所示的系统架构，在故障诊断的过程中，诊断原理是类似的，对比分析图7a和图7b所示的诊断服务，可以发现，二者在功能设置上存在承接关系，由于承接关系的存在，本文将按抽象后的通信服务系统，描述相关方案。请参见图7c，为由图7a和图7b所示的系统架构抽象后的系统架构，是本申请适用于的又一种系统架构。本申请对现有的诊断架构做出修改，在ECU端引入描述信息库，在描述信息库中存储有与DTC对应的描述信息，用于解释相应的DTC含义，还存储有DTC的故障信息的描述信息，用于解释DTC的故障信息的含义，相应的，删除诊断仪端的诊断信息库。与图3b所示的故障诊断过程相比，采用本申请的方法，诊断仪无需再执行步骤2，诊断仪启动诊断任务后，可从ECU获取到DTC以及对应的故障信息，以及与DTC和所述故障信息对应的描述信息，诊断仪对于DTC和故障信息的解释，不再依赖本地的诊断信息库，DTC和故障信息的含义，实现了自解释。

需要说明的是，本申请提供的方法可以但不限于应用于图7a-图7c所示的系统架构。下面以将本申请提供的方法应用于图7c所示的系统架构为例，对本申请提供的方法结合附图详细说明。

请参见图8所示，为本申请提供的一种故障诊断方法流程示意图。如图8所示，该方法包括：

步骤101：诊断仪向ECU发送故障诊断请求，相应的，ECU接收来自诊断仪的故障诊断请求，该故障诊断请求中包括第一DTC和第一信息，第一DTC用于标识故障，第一信息用于指示请求所述故障的第一故障信息。本申请实施例中，第一故障信息可包括故障的快照信息或故障的扩展信息，其中，故障的快照信息是指故障发生时刻记录的用于分析故障的原因信息，故障的扩展信息是指除故障的快照信息之外的用于分析故障的原因信息。扩展信息例如可包括发生该故障的次数、自恢复的次数、时间、温度、电压或电流等。其中，在ECU端每个故障信息可能涉及多个字段(field)，故，本申请实施例中第一故障信息可能包含多个字段(field)，可以理解为，第一故障信息可以由多个field_id标识。

一种可能的实现中，ECU可通过DCM模块接收来自诊断仪的诊断响应。

本申请实施例中，诊断仪在向ECU请求第一DTC所标识的故障的第一故障信息之前，可以先执行获取第一DTC的操作，诊断仪可以预先从主机厂和/或ECU处获取第一DTC，也可以从其它设备获取第一DTC，本申请不做限定。示例性地，以诊断仪从ECU获取第一DTC为例说明，根据UDS协议规定，诊断仪可以按照图1a所示的命令格式向ECU发送诊断命令：0x190x02 0xFF，该诊断命令中均为16进制数，19是指服务标识，19服务用于读取DTC的信息，02是指子服务标识，19服务的02子服务用于读取符合特定条件的DTC列表，具体的，所述特定条件由诊断命令中的“0xFF”决定，针对该诊断命令，“0xFF”用于与ECU端存储的DTC的状态(status)进行“与”运算，而ECU向诊断仪返回与“0xFF”进行“与”运算之后结果不为0的DTC的列表，也就是返回状态非零的DTC，ECU通过图1c所示的诊断响应的格式向诊断仪发送诊断响应：0x59 0x02 0xFF 0xC1 0x21 0x20 0xDB，其中，该诊断响应中均为16进制数，59是指响应标识，用于标识该诊断响应是与所述诊断请求对应的响应，UDS协议中规定诊断响应的标识可由诊断请求中服务标识推导，这样便可方便的标识一对请求和响应，02是诊断请求发上来的子服务标识，FF是诊断请求发上来的条件参数，0xC1 0x210x20 0xDB是指从ECU获取到的DTC，该举例中以获取到一个DTC为例示意，实际应用中，通过该诊断请求可从ECU获取到全部状态非零的DTC，其中，0xC1 0x21 0x20 0xDB中前三个字节C1 21 20为DTC本身的内容，分为高位字节C1，中位字节21，低位字节20，DB表示这个DTC的状态。

例如，继续上述举例，以第一DTC为0xC1 0x21 0x20、第一信息包括服务标识0x19和子服务标识0x06为例，诊断仪执行步骤101，向ECU发送故障诊断请求，按照UDS协议定义的格式，该故障诊断请求可以为：0x19 0x06 0xC1 0x21 0x20，其中，0xC1 0x21 0x20用于标识第一DTC，0x19 0x06用于指示请求所述第一DTC的扩展信息。

又例如，继续上述举例，以第一DTC为0xC1 0x21 0x20、第一信息包括服务标识0x19和子服务标识0x04为例，诊断仪执行步骤101，向ECU发送故障诊断请求，按照UDS协议定义的格式，该故障诊断请求可以为：0x19 0x04 0xC1 0x21 0x20 0x01，其中，0xC1 0x210x20用于标识第一DTC，0x19 0x06用于指示请求所述第一DTC的快照(snapshot)信息，“0x01”是指请求所述第一DTC的序号为0x01的快照信息。

步骤102：ECU根据故障诊断请求生成故障诊断响应，故障诊断响应中包括第一DTC、第一描述信息、第一故障信息以及第二描述信息，其中，第一描述信息用于解释第一DTC，第二描述信息用于解释第一故障信息。本申请实施例中，第一描述信息用于解释第一DTC，可以理解为第一描述信息为第一DTC的含义，第一DTC实质是数值，而第一描述信息是用户可以识别的字符串。类似的，第二描述信息用于解释第一故障信息，可以理解为第二描述信息为第一故障信息的含义，第一故障信息实质是数值，而第二描述信息是用户可以识别的字符串。一种可能的实现中，ECU可通过DEM模块生成故障诊断响应。

结合图7c所示的系统架构，本申请中第一对应关系以及第二对应关系可以存储在图7c所示的ECU包括的描述信息库中，本申请中以将这两类对应关系存储在同一个描述信息库示意，实际中这两类对应关系也可以存储在不同的信息库，本申请对此不做限定。本申请实施例中，第一对应关系包括多个DTC与多个描述信息的一一对应关系，可以理解为第一对应关系包括多个[DTC，DTC_desc]构成的键值(key-value)对，其中，DTC_desc即是指与DTC对应的描述信息。类似的，以故障信息包括多个字段(field)为例，第二对应关系包括多个故障信息与多个描述信息的一一对应关系，可以理解为第二对应关系包括多个[field_id，field_desc]构成的键值(key-value)对，其中，field_id用于标识字段(field)，多个字段(field)构成故障信息，field_desc即是指与故障信息对应的描述信息。

本申请实施例提供的诊断方法可以单独使用，也可以与现有技术中方法结合使用，当与现有的方法结合使用时，需要将本申请的故障诊断响应格式与现有的故障诊断响应格式区别开来。为将两种格式的故障诊断响应格式区分开来，本申请中故障诊断响应中还可以包括第二信息，第二信息用于指示故障诊断响应为包含描述信息的诊断响应。可选的，所述第二信息可以放在故障诊断响应的尾部，也可以放在故障诊断响应的头部，当然也可以放在故障诊断响应的中间任意部位，携带第二信息的位置可通过协议定义，也可以通过诊断仪与ECU协商，本申请不做限定。一个可能的实例中，若ECU端的描述信息库中不存在第一DTC以及第一故障信息的描述信息，则故障诊断响应中不包括第二信息，以退化为原格式，以便对历史版本的前向兼容。

一个可能的实例中，ECU接收到故障诊断请求，例如(0x19，0x06，DTC)后，获取第一故障信息对应的多个字段(field)数值，并获取各个field数值的描述信息，以及获取DTC的描述信息，进而生成故障诊断响应：[filed1数值+filed1_desc][filed2数值+filed2_desc][+]….[DTC+DTC_desc][第二信息]。可以理解，该故障诊断响应格式仅作为一种参考实现，不可理解为对本申请的限定。

本申请实施例中，ECU可采用但不限于如下方式根据故障诊断请求生成故障诊断响应：根据第一DTC以及预先存储的第一对应关系，确定与第一DTC对应的第一描述信息，第一对应关系包括多个DTC与多个描述信息的一一对应关系，多个DTC包括第一DTC，并根据故障诊断请求获取预先存储的第一故障信息，进而根据第一故障信息以及预先存储的第二对应关系，确定与第一故障信息对应的第二描述信息，第二对应关系包括多个故障信息与多个描述信息的一一对应关系，多个故障信息包括第一故障信息，最终生成包含第一DTC、第一描述信息、第一故障信息以及第二描述信息的故障诊断响应。

例如，继续上述举例，以故障诊断请求为：0x19 0x06 0xC1 0x21 0x20为例，ECU接收到该请求后，可解析该请求的含义，进而可获知诊断仪想要请求DTC：0xC1 0x21 0x20的扩展信息，ECU可从描述信息库获取到第一对应关系，进而可根据第一对应关系以及DTC：0xC10x21 0x20确定出该DTC对应的描述信息为：字符串“网络故障，即通信故障，与ABS通信丢失”，或，字符串“Communication failure,loss of communication with ABS”，具体是何种字符串取决于格式设置，并可根据该诊断请求获取到与DTC：0xC1 0x21 0x20对应的扩展信息，例如获取到0x14 0x0C 0x07 0x13 0x2D 0x3B，以及可从描述信息库获取到第二对应关系，进而可根据第二对应关系以及扩展信息：0x14 0x0C 0x07 0x13 0x2D 0x3B，确定出该扩展信息对应的描述信息为：字符串“发送该故障的次数为3、发生该故障时的温度为29度”，最终可生成包含0xC1 0x21 0x20、“网络故障，即通信故障，与ABS通信丢失”、0x140x0C 0x07 0x13 0x2D 0x3B以及“发送该故障的次数为3、发生该故障时的温度为29度”的故障诊断响应，当然故障诊断响应中还可以包括响应标识、子服务标识等。针对该举例，若采用现有的方法，故障诊断响应中可包括0xC1 0x21 0x20以及0x14 0x0C 0x07 0x13 0x2D0x3B，并不会包括描述信息，故采用现有的方法，诊断仪需要在本地对诊断响应解析以实现诊断，进而会导致本申请中背景技术中陈述的问题。

又例如，继续上述举例，以故障诊断请求为：0x19 0x04 0xC1 0x21 0x20 0x01为例，ECU接收到该请求后，可解析该请求的含义，进而可获知诊断仪想要请求DTC：0xC1 0x210x20的快照信息，ECU可从描述信息库获取到第一对应关系，进而可根据第一对应关系以及DTC：0xC1 0x21 0x20确定出该DTC对应的描述信息为：字符串“网络故障，即通信故障，与ABS通信丢失”，或，字符串“Communication failure,loss of communication with ABS”，具体是何种字符串取决于格式设置，并可根据该诊断请求获取到与DTC：0xC1 0x21 0x20对应的快照信息，例如获取到0x01 0x02 0x47 0x11 0x0C 0x47 0x12 0x00 0x64，以及可从描述信息库获取到第二对应关系，进而可根据第二对应关系以及快照信息，确定出该快照信息对应的描述信息为：字符串“快照条目为1条；快照中包含两个DID；第一个DID为电压值；电压值为12V；第二个DID为电流值；电流值为100mA”，最终可生成包含0xC1 0x21 0x20、“网络故障，即通信故障，与ABS通信丢失”、0x01 0x02 0x47 0x11 0x0C 0x47 0x12 0x000x64以及“快照条目为1条；快照中包含两个DID；第一个DID为电压值；电压值为12V；第二个DID为电流值；电流值为100mA”的故障诊断响应，当然故障诊断响应中还可以包括响应标识、子服务标识等。针对该举例，若采用现有的方法，故障诊断响应中可包括0xC1 0x210x20以及0x01 0x02 0x47 0x11 0x0C 0x47 0x12 0x00 0x64，并不会包括描述信息，故采用现有的方法，诊断仪需要在本地对诊断响应解析以实现诊断，进而会导致本申请中背景技术中陈述的问题。

此外，ECU接收到诊断仪发送的故障诊断请求后，在生成故障诊断响应之前，还可以执行一些其他操作，例如检验接收到的故障诊断请求是否是合法的请求等。这些操作与本申请的诊断方法不是密切相关，故本申请不再赘述。

步骤103：ECU向诊断仪发送故障诊断响应，相应的，诊断仪接收来自ECU的故障诊断响应。示例性地，ECU可通过DCM向诊断仪发送故障诊断响应。

步骤104：诊断仪解析故障诊断响应。示例性地，诊断仪可在MVCI-RTE解析故障诊断响应。

步骤105：诊断仪显示解析后的故障诊断响应中的第一描述信息和第二描述信息。示例性地，诊断仪可在显示仪的显示界面显示解析后的故障诊断响应中的第一描述信息和第二描述信息。一种可能的实现中，若所述故障诊断响应中包括第二信息，则执行步骤104之后，显示第一描述信息和第二描述信息之前，可以删除故障诊断响应中包括的第二信息。

例如，继续上述举例，以故障诊断响应为：(0xC1 0x21 0x20“网络故障，即通信故障，与ABS通信丢失”0x14 0x0C 0x07 0x13 0x2D 0x3B“发送该故障的次数为3、发生该故障时的温度为29度”)为例，诊断仪可在显示界面显示“网络故障，即通信故障，与ABS通信丢失”以及“发送该故障的次数为3、发生该故障时的温度为29度”)。

又例如，继续上述举例，以故障诊断响应为：(0xC1 0x21 0x20“网络故障，即通信故障，与ABS通信丢失”0x01 0x02 0x47 0x11 0x0C 0x47 0x12 0x00 0x64“快照条目为1条；快照中包含两个DID；第一个DID为电压值；电压值为12V；第二个DID为电流值；电流值为100mA”)为例，诊断仪可在显示界面显示网络故障，即通信故障，与ABS通信丢失”以及“快照条目为1条；快照中包含两个DID；第一个DID为电压值；电压值为12V；第二个DID为电流值；电流值为100mA”。

采用本申请提供的诊断方法，诊断仪无需再从车载诊断系统获取原始的DTC信息构建并维护诊断信息库，可在从车载诊断系统获取DTC信息的同时获取到描述信息，实现DTC信息的自解释，实现了诊断仪开发与车载诊断系统开发的解耦合，可减小诊断数据在长路径传递和交换过程发生问题的概率，提升诊断仪与车载诊断系统的开发效率，在遵循当前UDS应用协议的前提下，大幅度提升诊断仪的适应性，有助于构建通用诊断仪。

下面以一个完整的实例对本申请提供的诊断方法进行举例说明。

请参见图9a所示，以ECU端DEM和DCM执行本申请提供的诊断方法为例，该方法可包括如下步骤：

步骤201：ECU通过DCM接收来自诊断仪的故障诊断请求(0x19，0x06，DTC)，DCM接收到该故障诊断请求后向DEM发送该请求。

步骤202：DEM接收到故障诊断请求后进行必要的条件判断。例如验证该故障诊断请求的合法性等。

步骤203：DEM根据所述故障诊断请求从数据存储模块读取DTC的扩展信息，以扩展信息包括多个字段(field)为例，DEM可根据所述故障诊断请求从数据存储模块读取多个field的数值。

步骤204：DEM根据各个field的内部标识，从数据存储模块读取各field数值对应的描述信息filed_desc。

步骤205：判断数据存储模块中是否存储有与field数值对应的描述信息filed_desc。

步骤206a：若数据存储模块中存储有与field数值对应的描述信息filed_desc，依次拼接各个field数值与对应的filed_desc，并充填文本数据报告(ExtDataRecord)，可以理解为充填故障诊断响应。其中，充填的格式可参见上文中描述。该步骤执行本申请提供的方法。

步骤206b：若数据存储模块中没有与field数值对应的描述信息filed_desc，则直接使用field数值充填ExtDataRecord，可以理解为充填故障诊断响应。该步骤执行现有方法。

步骤207：DEM根据DTC从数据存储模块读取与DTC对应的描述信息DTC_desc。

步骤208：判断数据存储模块中是否存储有与DTC对应的描述信息DTC_desc。

步骤209a：若数据存储模块中存储有与DTC对应的描述信息DTC_desc，则拼接DTC的数值和DTC_desc，并充填ExtDataRecord，可以理解为充填故障诊断响应。其中，充填的格式可参见上文中描述。该步骤执行本申请提供的方法。

步骤209b：若数据存储模块中没有与DTC对应的描述信息DTC_desc，则直接使用DTC充填ExtDataRecord，可以理解为充填故障诊断响应。该步骤执行现有方法。

步骤210：在故障诊断响应中携带/增加第二信息，第二信息的含义详见上文描述。

步骤211：DEM将故障诊断响应发送至DCM，DCM向诊断仪返回DCM，诊断结束。

请参见图9b所示，为诊断仪端执行诊断方法的流程示意图，该方法可包括如下步骤：

步骤301：诊断仪接收到故障诊断响应。

步骤302：诊断仪接收到故障诊断响应后进行必要的条件判断。例如验证该故障诊断响应的合法性等。

步骤303：对于验证合法的故障诊断响应，判断该故障诊断响应是否是新版本，也就是判断该故障诊断响应是否携带第二信息。

步骤304a：若该故障诊断响应是新版本，也就是携带第二信息，则将该故障诊断响应中的第二信息去掉，将故障诊断响应中的描述信息发送至显示仪。该步骤执行本申请提供的方法。

步骤304b：若该故障诊断响应不是新版本，也就是不携带第二信息，则诊断仪从诊断信息库中获取DTC信息(例如DTC和/或DTC的故障信息)的描述信息，将描述信息发送至显示仪。该步骤执行现有方法。

步骤305：诊断仪通过显示界面显示诊断结果。

步骤306：诊断结束。

可以理解，本申请提供的各个实施例或实例中，压缩节点和/或解压缩节点可以执行本申请实施例中的部分或全部步骤，这些步骤或操作仅是示例，本申请实施例还可以执行其它操作或者各种操作的变形。此外，各个步骤可以按照本申请实施例呈现的不同的顺序来执行，并且有可能并非要执行本申请实施例中的全部操作。

在采用集成的模块的情况下，图10示出了本申请实施例中所涉及的一种装置的可能的示例性框图，该装置1000可以以软件的形式存在，也可以为车载诊断系统，还可以为车载诊断系统中的芯片。装置1000可以用于执行上述实施例中涉及车载诊断系统的任意方法和功能。装置1000包括：处理模块1002和通信模块1003，通信模块1003可以包括接收模块和发送模块。处理模块1002用于对装置1000的动作进行控制管理。通信模块1003用于支持装置1000与其他设备(例如诊断仪)的通信。装置1000还可以包括存储模块1001，用于存储装置1000的程序代码和数据。例如，处理模块1002可以支持装置1000执行上文中各方法示例中车载诊断系统的动作，例如支持装置1000执行图8中的步骤102。通信模块1003可以支持装置1000与诊断仪之间的通信，例如，通信模块1003可以支持装置1000执行图8中步骤101或步骤103。

一种可能的设计中，所述处理模块1002采用如下方式根据所述故障诊断请求生成故障诊断响应：根据所述第一DTC以及所述存储模块1001中存储的第一对应关系，确定与所述第一DTC对应的所述第一描述信息，所述第一对应关系包括多个DTC与多个描述信息的一一对应关系，所述多个DTC包括所述第一DTC；根据所述故障诊断请求获取所述存储模块1001中存储的所述第一故障信息；根据所述第一故障信息以及所述存储模块1001中存储的第二对应关系，确定与所述第一故障信息对应的所述第二描述信息，所述第二对应关系包括多个故障信息与多个描述信息的一一对应关系，所述多个故障信息包括所述第一故障信息；生成包含所述第一DTC、所述第一描述信息、所述第一故障信息以及所述第二描述信息的所述故障诊断响应。

一种可能的设计中，所述故障诊断响应中还包括第二信息，所述第二信息用于指示所述故障诊断响应为包含描述信息的诊断响应。

一种可能的设计中，所述第一故障信息包括所述故障的快照信息或所述故障的扩展信息，其中，所述故障的快照信息是指所述故障发生时刻记录的用于分析所述故障的原因信息，所述故障的扩展信息是指除所述故障的快照信息之外的用于分析所述故障的原因信息。

其中，处理模块1002可以是处理器或控制器，例如可以是CPU，通用处理器，DSP，ASIC，FPGA或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。所述处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等等。通信模块1003可以是通信接口、收发器或收发电路等，其中，该通信接口是统称，在具体实现中，该通信接口可以包括多个接口，例如可以包括：车载诊断系统和诊断仪之间的接口，和/或其他接口。存储模块1001可以是存储器。

当处理模块1002为处理器，通信模块1003为通信接口，存储模块1001为存储器时，本申请实施例所涉及的装置1000可以为图11所示的装置1100。

参阅图11所示，装置1100包括：一个或多个处理器1102、通信接口1103、存储器1101。可选的，装置1100还可以包括总线1104。其中，通信接口1103、处理器1102以及存储器1101可以通过总线1104相互连接；总线1104可以是外设部件互连标准(peripheralcomponent interconnect，PCI)总线或扩展工业标准结构(extended industry standardarchitecture，EISA)总线等。所述总线1104可以分为地址总线、数据总线、控制总线等。为便于表示，图11中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

在采用集成的模块的情况下，图12示出了本申请实施例中所涉及的一种装置的可能的示例性框图，该装置1200可以以软件的形式存在，也可以为诊断仪，还可以为诊断仪中的芯片。装置1200可以用于执行上述实施例中涉及诊断仪的任意方法和功能。装置1200包括：通信模块1201、解析模块1202和显示模块1203，通信模块1201可以包括接收模块和发送模块。通信模块1201用于支持装置1200与其他设备(例如车载诊断系统)的通信。例如通信模块1201可以支持装置1200执行上文中各方法示例中诊断仪的动作，例如支持装置1200执行图8中的步骤101或步骤103。解析模块1202例如可以支持装置1200执行图8中步骤104。显示模块1203例如可以支持装置1200执行图8中步骤105。

一种可能的设计中，所述故障诊断响应中还包括第二信息，所述第二信息用于指示所述故障诊断响应为包含描述信息的诊断响应。基于该种设计，所述解析模块1202，还用于解析所述故障诊断响应之后，删除所述故障诊断响应中包括的所述第二信息。

一种可能的设计中，所述第一故障信息包括所述故障的快照信息或所述故障的扩展信息，其中，所述故障的快照信息是指所述故障发生时刻记录的用于分析所述故障的原因信息，所述故障的扩展信息是指除所述故障的快照信息之外的用于分析所述故障的原因信息。

其中，通信模块1201可以是通信接口、收发器或收发电路等，其中，该通信接口是统称，在具体实现中，该通信接口可以包括多个接口，例如可以包括：车载诊断系统和诊断仪之间的接口，和/或其他接口。解析模块1202可以是处理器或控制器，例如可以是CPU，通用处理器，DSP，ASIC，FPGA或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。所述处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等等。显示模块1203可以为显示屏幕，显示屏幕可以采用液晶显示器(liquid crystal display，LCD)或有机发光二极管(organic light-emitting diode，OLED)等形式来配置。

当通信模块1201为通信接口，解析模块1202为处理器，显示模块1203为显示屏幕时，本申请实施例所涉及的装置1200可以为图13所示的装置1300。

参阅图13所示，装置1300包括：一个或多个处理器1302、通信接口1303、显示屏幕1301。可选的，装置1300还可以包括总线1304。其中，通信接口1303、处理器1302以及显示屏幕1301可以通过总线1304相互连接；总线1304可以是外设部件互连标准(peripheralcomponent interconnect，PCI)总线或扩展工业标准结构(extended industry standardarchitecture，EISA)总线等。所述总线1304可以分为地址总线、数据总线、控制总线等。为便于表示，图13中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

基于与上述方法实施例相同构思，本申请实施例还提供了一种计算机可读存储介质，其上存储有一些指令，这些指令被计算机调用执行时，可以使得计算机完成上述方法实施例、方法实施例的任意一种可能的设计中所涉及的方法。本申请实施例中，对计算机可读存储介质不做限定，例如，可以是随机存取存储器(random-access memory，RAM)、只读存储器(read-only memory，ROM)等。

基于与上述方法实施例相同构思，本申请还提供一种计算机程序产品，该计算机程序产品在被计算机调用执行时可以完成方法实施例以及上述方法实施例任意可能的设计中所涉及的方法。

基于与上述方法实施例相同构思，本申请还提供一种芯片，该芯片与收发器耦合，用于完成上述方法实施例、方法实施例的任意一种可能的实现方式中所涉及的方法，其中，“耦合”是指两个部件彼此直接或间接地结合，这种结合可以是固定的或可移动性的，这种结合可以允许流动液、电、电信号或其它类型信号在两个部件之间进行通信。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘(Solid State Disk，SSD))等。

本申请实施例中所描述的各种说明性的逻辑单元和电路可以通过通用处理器，数字信号处理器，专用集成电路(ASIC)，现场可编程门阵列(FPGA)或其它可编程逻辑装置，离散门或晶体管逻辑，离散硬件部件，或上述任何组合的设计来实现或操作所描述的功能。通用处理器可以为微处理器，可选地，该通用处理器也可以为任何传统的处理器、控制器、微控制器或状态机。处理器也可以通过计算装置的组合来实现，例如数字信号处理器和微处理器，多个微处理器，一个或多个微处理器联合一个数字信号处理器核，或任何其它类似的配置来实现。

本申请实施例中所描述的方法或算法的步骤可以直接嵌入硬件、处理器执行的软件单元、或者这两者的结合。软件单元可以存储于RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动磁盘、CD-ROM或本领域中其它任意形式的存储媒介中。示例性地，存储媒介可以与处理器连接，以使得处理器可以从存储媒介中读取信息，并可以向存储媒介存写信息。可选地，存储媒介还可以集成到处理器中。处理器和存储媒介可以设置于ASIC中，ASIC可以设置于终端设备中。可选地，处理器和存储媒介也可以设置于终端设备中的不同的部件中。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管结合具体特征及其实施例对本发明进行了描述，显而易见的，在不脱离本发明的精神和范围的情况下，可对其进行各种修改和组合。相应地，本说明书和附图仅仅是所附权利要求所界定的本发明的示例性说明，且视为已覆盖本发明范围内的任意和所有修改、变化、组合或等同物。显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (16)

1.一种故障诊断方法，应用于车载诊断系统，其特征在于，包括：

接收来自诊断仪的故障诊断请求，所述故障诊断请求包括第一诊断故障码DTC和第一信息，所述第一DTC用于标识故障，所述第一信息用于指示请求所述故障的第一故障信息；

根据所述故障诊断请求生成故障诊断响应，所述故障诊断响应中包括所述第一DTC、第一描述信息、所述第一故障信息以及第二描述信息，其中，所述第一描述信息用于解释所述第一DTC，所述第二描述信息用于解释所述第一故障信息；

向所述诊断仪发送所述故障诊断响应。

2.如权利要求1所述的方法，其特征在于，所述根据所述故障诊断请求生成故障诊断响应，包括：

根据所述第一DTC以及预先存储的第一对应关系，确定与所述第一DTC对应的所述第一描述信息，所述第一对应关系包括多个DTC与多个描述信息的一一对应关系，所述多个DTC包括所述第一DTC；

根据所述故障诊断请求获取预先存储的所述第一故障信息；

根据所述第一故障信息以及预先存储的第二对应关系，确定与所述第一故障信息对应的所述第二描述信息，所述第二对应关系包括多个故障信息与多个描述信息的一一对应关系，所述多个故障信息包括所述第一故障信息；

生成包含所述第一DTC、所述第一描述信息、所述第一故障信息以及所述第二描述信息的所述故障诊断响应。

3.如权利要求1或2所述的方法，其特征在于，所述故障诊断响应中还包括第二信息，所述第二信息用于指示所述故障诊断响应为包含描述信息的诊断响应。

4.如权利要求1至3任一项所述的方法，其特征在于，所述第一故障信息包括所述故障的快照信息或所述故障的扩展信息，其中，所述故障的快照信息是指所述故障发生时刻记录的用于分析所述故障的原因信息，所述故障的扩展信息是指除所述故障的快照信息之外的用于分析所述故障的原因信息。

5.一种故障诊断方法，应用于诊断仪，其特征在于，包括：

向车载诊断系统发送故障诊断请求，所述故障诊断请求包括第一诊断故障码DTC和第一信息，所述第一DTC用于标识故障，所述第一信息用于指示请求所述故障的第一故障信息；

接收来自所述车载诊断系统的故障诊断响应，所述故障诊断响应中包括所述第一DTC、第一描述信息、所述第一故障信息以及第二描述信息，其中，所述第一描述信息用于解释所述第一DTC，所述第二描述信息用于解释所述第一故障信息；

解析所述故障诊断响应，并显示所述第一描述信息和所述第二描述信息。

6.如权利要求5所述的方法，其特征在于，所述故障诊断响应中还包括第二信息，所述第二信息用于指示所述故障诊断响应为包含描述信息的诊断响应；

解析所述故障诊断响应之后，还包括：

删除所述故障诊断响应中包括的所述第二信息。

7.如权利要求5至6任一项所述的方法，其特征在于，所述第一故障信息包括所述故障的快照信息或所述故障的扩展信息，其中，所述故障的快照信息是指所述故障发生时刻记录的用于分析所述故障的原因信息，所述故障的扩展信息是指除所述故障的快照信息之外的用于分析所述故障的原因信息。

8.一种故障诊断装置，其特征在于，包括：通信模块和处理模块；

所述通信模块，用于接收来自诊断仪的故障诊断请求，所述故障诊断请求包括第一诊断故障码DTC和第一信息，所述第一DTC用于标识故障，所述第一信息用于指示请求所述故障的第一故障信息；

所述处理模块，用于根据所述故障诊断请求生成故障诊断响应，所述故障诊断响应中包括所述第一DTC、第一描述信息、所述第一故障信息以及第二描述信息，其中，所述第一描述信息用于解释所述第一DTC，所述第二描述信息用于解释所述第一故障信息；

所述通信模块，还用于向所述诊断仪发送所述故障诊断响应。

9.如权利要求8所述的装置，其特征在于，所述装置还包括存储模块；

所述处理模块采用如下方式根据所述故障诊断请求生成故障诊断响应：

根据所述第一DTC以及所述存储模块中存储的第一对应关系，确定与所述第一DTC对应的所述第一描述信息，所述第一对应关系包括多个DTC与多个描述信息的一一对应关系，所述多个DTC包括所述第一DTC；

根据所述故障诊断请求获取所述存储模块中存储的所述第一故障信息；

根据所述第一故障信息以及所述存储模块中存储的第二对应关系，确定与所述第一故障信息对应的所述第二描述信息，所述第二对应关系包括多个故障信息与多个描述信息的一一对应关系，所述多个故障信息包括所述第一故障信息；

生成包含所述第一DTC、所述第一描述信息、所述第一故障信息以及所述第二描述信息的所述故障诊断响应。

10.如权利要求8或9所述的装置，其特征在于，所述故障诊断响应中还包括第二信息，所述第二信息用于指示所述故障诊断响应为包含描述信息的诊断响应。

11.如权利要求8至10任一项所述的装置，其特征在于，所述第一故障信息包括所述故障的快照信息或所述故障的扩展信息，其中，所述故障的快照信息是指所述故障发生时刻记录的用于分析所述故障的原因信息，所述故障的扩展信息是指除所述故障的快照信息之外的用于分析所述故障的原因信息。

12.一种故障诊断装置，其特征在于，包括：通信模块、解析模块和显示模块；

所述通信模块，用于向车载诊断系统发送故障诊断请求，所述故障诊断请求包括第一诊断故障码DTC和第一信息，所述第一DTC用于标识故障，所述第一信息用于指示请求所述故障的第一故障信息；

所述通信模块，还用于接收来自所述车载诊断系统的故障诊断响应，所述故障诊断响应中包括所述第一DTC、第一描述信息、所述第一故障信息以及第二描述信息，其中，所述第一描述信息用于解释所述第一DTC，所述第二描述信息用于解释所述第一故障信息；

所述解析模块，用于解析所述故障诊断响应；

所述显示模块，用于显示解析后的所述故障诊断响应中的所述第一描述信息和所述第二描述信息。

13.如权利要求12所述的装置，其特征在于，所述故障诊断响应中还包括第二信息，所述第二信息用于指示所述故障诊断响应为包含描述信息的诊断响应；

所述解析模块，还用于解析所述故障诊断响应之后，删除所述故障诊断响应中包括的所述第二信息。

14.如权利要求12或13所述的装置，其特征在于，所述第一故障信息包括所述故障的快照信息或所述故障的扩展信息，其中，所述故障的快照信息是指所述故障发生时刻记录的用于分析所述故障的原因信息，所述故障的扩展信息是指除所述故障的快照信息之外的用于分析所述故障的原因信息。

15.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机指令，当所述指令在计算机上运行时，使得计算机执行如权利要求1～7任一所述的方法。

16.一种计算机程序产品，其特征在于，所述计算机程序产品在被计算机调用时，使得计算机执行如权利要求1～7任一所述的方法。