CN111024405A

CN111024405A - 汽车诊断方法、相关装置及系统

Info

Publication number: CN111024405A
Application number: CN201911196451.6A
Authority: CN
Inventors: 刘均; 樊球
Original assignee: Shenzhen Launch Technology Co Ltd
Current assignee: Shenzhen Launch Technology Co Ltd
Priority date: 2019-11-28
Filing date: 2019-11-28
Publication date: 2020-04-17
Anticipated expiration: 2039-11-28
Also published as: CN111024405B

Abstract

本申请实施例提供了一种汽车诊断方法及相关装置。该方法包括：服务器接收诊断终端发送的第一文件；其中，第一文件包括至少一个第一用户操作各自对应的事件以及至少一个第一用户操作各自对应的响应数据，响应数据为诊断终端针对与该响应数据对应的第一用户操作输出的数据，第一用户操作用于选择针对目标汽车的诊断功能；根据第一文件确定至少一个诊断方案；诊断方案用于解决目标汽车的故障；发送至少一个诊断方案给诊断终端。采用本申请实施例，能够提供更为有效的汽车诊断数据，便于快速定位汽车故障原因和及时有效地解决汽车故障，提升用户体验感。

Description

汽车诊断方法、相关装置及系统

技术领域

本申请涉及汽车电子技术领域，尤其涉及一种汽车诊断方法、相关装置及系统。

背景技术

随着汽车电子技术的发展，汽车的结构越来越复杂，汽车可以包含的电子控制单元(Electronic Control Unit，ECU)的数目和种类也越来越多，汽车总线上传输的数据量也不断增多，汽车出现故障的原因也层出不穷。

对于一些不常见或复杂的汽车故障，汽修店的工作人员往往不能快速有效地解决问题，只能求助汽车生产厂商，由汽车生产厂商的技术人员远程进行汽车故障的排查。在远程排查的过程中，技术人员往往需要借助相关的汽车诊断数据来协助进行故障分析。但目前常用的汽车诊断数据为诊断终端的专业的开发日志或诊断终端的简单流程日志等。这样的汽车诊断数据会让远程排查的实行较为困难。从而导致故障不能及时得到解决，整个故障排查过程的效率低下，用户体验感差。

发明内容

本申请实施例公开了一种汽车诊断方法、相关装置及系统，能够提供更为有效的汽车诊断数据，便于快速定位汽车故障原因和及时有效地解决汽车故障，提升用户体验感。

第一方面，本申请实施例提供了一种汽车诊断方法，包括：服务器接收诊断终端发送的第一文件；其中，第一文件包括至少一个第一用户操作各自对应的事件以及至少一个第一用户操作各自对应的响应数据，响应数据为诊断终端针对与该响应数据对应的第一用户操作输出的数据，第一用户操作用于选择针对目标汽车的诊断功能；

根据第一文件确定至少一个诊断方案；诊断方案用于解决目标汽车的故障；

发送至少一个诊断方案给诊断终端。

在上述方法中，诊断终端发送的用于汽车诊断的第一文件包括至少一个用于选择针对目标汽车的诊断功能的第一用户操作各自对应的事件以及各自对应的响应数据。也就是说，第一文件包括使用诊断终端的现场人员在汽车诊断过程中执行的部分或所有的操作步骤，以及诊断终端针对执行的用户操作返回的数据结果。相比现有技术中通过专业的开发日志或简单流程日志进行故障排查，本申请实施例中的第一文件在进行汽车故障诊断时更为有效，可读性更强。通过分析第一文件包括的数据，能够便于复现现场人员使用诊断终端进行汽车诊断的故障场景，减少远程排查过程中了解故障情况的时间。对于一些由于错误的用户操作导致无法解决汽车故障的情况，能够快速定位故障原因，大大提升了故障处理效率。本申请实施例通过第一文件进行汽车故障的远程排查，便于及时有效地解决故障。从而提高整个故障排查过程的效率，提升用户体验感。

在第一方面的一种可选方案中，第一文件还包括至少一个第一用户操作各自选择的诊断功能对应的诊断指令；诊断指令包括诊断终端和目标汽车交互的请求指令和响应指令。

在上述方法中，诊断终端发送的用于汽车诊断的第一文件还包括至少一个第一用户操作各自选择的诊断功能对应的诊断指令。也就是说，第一文件还包括与使用诊断终端的现场人员在汽车诊断过程中执行的用户操作对应的诊断终端和目标汽车交互的指令。通过分析第一文件中包括的用户操作对应的事件、响应数据和诊断指令来进行汽车故障的诊断，能够基于更为全面有效的汽车诊断数据来定位故障原因和确定诊断方案。从而提高整个故障排查过程的效率，提升用户体验感。

在第一方面的又一种可选方案中，上述发送至少一个诊断方案给诊断终端之前，该方法还包括：接收诊断终端发送的第二文件；其中，第二文件包括目标汽车的汽车总线的数据，目标汽车的汽车总线的数据包括至少一个第一用户操作各自选择的诊断功能对应的汽车总线的数据。

上述根据第一文件确定至少一个诊断方案，包括：根据第一文件和第二文件确定至少一个诊断方案。

在上述方法中，除了第一文件外，用于汽车诊断的数据还包括第二文件。第二文件包括目标汽车的原始诊断数据，即汽车总线的数据(如汽车总线传输的数据帧、诊断故障代码、汽车电子控制单元的版本和型号等)。结合第一文件和第二文件确定诊断方案，能够基于更为全面有效的汽车诊断数据来定位故障原因和确定诊断方案。从而提高整个故障排查过程的效率，提升用户体验感。

在第一方面的又一种可选方案中，上述根据第一文件和第二文件确定至少一个诊断方案，包括：将第一文件包括的数据、第二文件包括的数据和故障问题库包括的多个故障信息进行对比；其中，故障问题库包括多个故障信息以及多个故障信息各自对应的第一解决方法，故障信息包括以下至少一项：诊断功能对应的事件、诊断功能对应的响应数据、诊断功能对应的诊断指令或诊断功能对应的汽车总线的数据。

确定与第一文件和第二文件匹配的至少一个目标故障信息；至少一个目标故障信息为上述多个故障信息中的一个或多个故障信息。

当故障问题库存在至少一个目标故障信息的情况下，确定至少一个目标故障信息各自对应的第一解决方法；诊断方案包括至少一个目标故障信息各自对应的第一解决方法。

当故障问题库不存在至少一个目标故障信息的情况下，对第一文件和第二文件进行分析处理，得到用于解决目标汽车的故障的第二解决方法；诊断方案包括第二解决方法。

在上述方法中，故障问题库包括多个已知的故障信息和每个故障信息对应的至少一个解决方法。通过对比第一文件包括的数据、第二文件包括的数据和故障问题库包括的故障信息，确定与第一文件和第二文件对应的目标汽车的故障是否为故障问题库中已知的故障。在目标汽车的故障不为已知故障的情况下，对第一文件和第二文件进行分析处理，获取诊断方案。在目标汽车的故障为已知故障的情况下，可以无需分析处理第一文件和第二文件，直接获取故障问题库中与该已知故障对应的解决方法。从而更为快速有效地确定诊断方案，提高整个故障排查过程的效率。

在第一方面的又一种可选方案中，第一文件和第二文件均包含目标汽车的身份标识；第一文件和第二文件均为经过加密的文件。

在上述方法中，用于汽车诊断的第一文件和第二文件均包含目标汽车的身份标识，便于区分目标汽车和其他汽车的诊断数据。用于汽车诊断的第一文件和第二文件均经过加密处理，从而防止诊断数据泄露，增强核心数据的安全性。

第二方面，本申请实施例提供了一种汽车诊断方法，包括：诊断终端记录至少一个第一用户操作各自对应的事件以及至少一个第一用户操作各自对应的响应数据；其中，响应数据为诊断终端针对与该响应数据对应的第一用户操作输出的数据，第一用户操作用于选择针对目标汽车的诊断功能；

根据至少一个第一用户操作各自对应的事件以及至少一个第一用户操作各自对应的响应数据生成第一文件；

发送第一文件给服务器，以使服务器根据第一文件确定至少一个诊断方案；诊断方案用于解决目标汽车的故障；

接收服务器发送的至少一个诊断方案；

接收诊断方案选择指令并执行。

在上述方法中，诊断终端生成的用于汽车诊断的第一文件包括至少一个用于选择针对目标汽车的诊断功能的第一用户操作各自对应的事件以及各自对应的响应数据。也就是说，第一文件包括使用诊断终端的现场人员在汽车诊断过程中执行的部分或所有的操作步骤，以及诊断终端针对执行的用户操作返回的数据结果。相比现有技术中通过专业的开发日志或简单流程日志进行故障排查，本申请实施例中的第一文件在进行汽车故障诊断时更为有效，可读性更强。通过分析第一文件包括的数据，能够便于复现现场人员使用诊断终端进行汽车诊断的故障场景，减少远程排查过程中了解故障情况的时间。对于一些由于错误的用户操作导致无法解决汽车故障的情况，能够快速定位故障原因，大大提升了故障处理效率。本申请实施例通过第一文件进行汽车故障的远程排查，便于及时有效地解决故障。从而提高整个故障排查过程的效率，提升用户体验感。

在第二方面的一种可选方案中，第一文件还包括至少一个第一用户操作各自选择的诊断功能对应的诊断指令；诊断指令包括诊断终端和目标汽车交互的请求指令和响应指令。

在上述方法中，诊断终端生成的用于汽车诊断的第一文件还包括至少一个第一用户操作各自选择的诊断功能对应的诊断指令。也就是说，第一文件还包括与使用诊断终端的现场人员在汽车诊断过程中执行的用户操作对应的诊断终端和目标汽车交互的指令。通过分析第一文件中包括的用户操作对应的事件、响应数据和诊断指令来进行汽车故障的诊断，能够基于更为全面有效的汽车诊断数据来定位故障原因和确定诊断方案。从而提高整个故障排查过程的效率，提升用户体验感。

在第二方面的又一种可选方案中，上述发送第一文件给服务器，以使服务器根据第一文件确定至少一个诊断方案之前，该方法还包括：获取目标汽车的汽车总线的数据；目标汽车的汽车总线的数据包括至少一个第一用户操作各自选择的诊断功能对应的汽车总线的数据；根据目标汽车的汽车总线的数据生成第二文件。

上述发送第一文件给服务器，以使服务器根据第一文件确定至少一个诊断方案，包括：发送第一文件和第二文件给服务器，以使服务器根据第一文件和第二文件确定至少一个诊断方案。

在第二方面的又一种可选方案中，上述诊断终端记录至少一个第一用户操作各自对应的事件以及至少一个第一用户操作各自对应的响应数据之前，该方法还包括：读取配置文件，确定第一开关为开启状态；其中，第一开关用于控制以下至少一项：上述诊断终端记录至少一个第一用户操作各自对应的事件以及至少一个第一用户操作各自对应的响应数据或者上述获取目标汽车的汽车总线的数据，配置文件包括第一开关的状态信息，状态信息为开启状态或关闭状态。

可能地，上述读取配置文件，确定第一开关为开启状态之前，该方法还包括：接收用于设置第一开关的状态信息的第二用户操作；根据第二用户操作，确定配置文件包括的第一开关的状态信息。

本申请实施例中，使用诊断终端的用户可以在诊断终端的界面设置第一开关的状态信息，从而控制诊断终端是否记录至少一个第一用户操作各自对应的事件以及至少一个第一用户操作各自对应的响应数据或者是否获取目标汽车的汽车总线的数据。在确定第一开关为开启状态的情况下才会记录诊断数据，并根据诊断数据生成第一文件和第二文件。从而更为有效地管控诊断终端记录的诊断数据的数据量，尽量避免诊断终端的存储空间占用过多的情况，减轻诊断终端的负担。

在第二方面的又一种可选方案中，上述诊断终端记录至少一个第一用户操作各自对应的事件以及至少一个第一用户操作各自对应的响应数据之前，该方法还包括：获取目标汽车的身份标识；第一文件和第二文件均包含目标汽车的身份标识；第一文件和第二文件均为经过加密的文件。

可能地，身份标识是车辆识别号码(vehicle identification number，VIN)；其中，每辆汽车均有唯一的VIN码，VIN码用于确定汽车的车型信息，车型信息包括以下至少一项：汽车的产地、品牌、车系、种类、系列、车身类型、车型年份或组装工厂的代码。

第三方面，本申请实施例提供了一种服务器，该服务器包括：

第一接收单元，用于接收诊断终端发送的第一文件；其中，第一文件包括至少一个第一用户操作各自对应的事件以及至少一个第一用户操作各自对应的响应数据，响应数据为诊断终端针对与该响应数据对应的第一用户操作输出的数据，第一用户操作用于选择针对目标汽车的诊断功能。

确定单元，用于根据第一文件确定至少一个诊断方案；诊断方案用于解决目标汽车的故障。

发送单元，用于发送至少一个诊断方案给诊断终端。

在第三方面的一种可选方案中，第一文件还包括至少一个第一用户操作各自选择的诊断功能对应的诊断指令；诊断指令包括诊断终端和目标汽车交互的请求指令和响应指令。

在第三方面的又一种可选方案中，该服务器还包括：第二接收单元，用于在上述发送单元发送至少一个诊断方案给诊断终端之前，接收诊断终端发送的第二文件；其中，第二文件包括目标汽车的汽车总线的数据，目标汽车的汽车总线的数据包括至少一个第一用户操作各自选择的诊断功能对应的汽车总线的数据。

上述确定单元，具体用于根据第一文件和第二文件确定至少一个诊断方案。

在第三方面的又一种可选方案中，上述确定单元包括：

对比子单元，用于将第一文件包括的数据、第二文件包括的数据和故障问题库包括的多个故障信息进行对比；其中，故障问题库包括多个故障信息以及多个故障信息各自对应的第一解决方法，故障信息包括以下至少一项：诊断功能对应的事件、诊断功能对应的响应数据、诊断功能对应的诊断指令或诊断功能对应的汽车总线的数据。

第一确定子单元，用于确定与第一文件和第二文件匹配的至少一个目标故障信息；至少一个目标故障信息为上述多个故障信息中的一个或多个故障信息。

第二确定子单元，用于当故障问题库存在至少一个目标故障信息的情况下，确定至少一个目标故障信息各自对应的第一解决方法；诊断方案包括至少一个目标故障信息各自对应的第一解决方法。

第三确定子单元，用于当故障问题库不存在至少一个目标故障信息的情况下，对第一文件和第二文件进行分析处理，得到用于解决目标汽车的故障的第二解决方法；诊断方案包括第二解决方法。

在第三方面的又一种可选方案中，第一文件和第二文件均包含目标汽车的身份标识；第一文件和第二文件均为经过加密的文件。

第四方面，本申请实施例提供了一种诊断终端，该诊断终端包括：

记录单元，用于记录至少一个第一用户操作各自对应的事件以及至少一个第一用户操作各自对应的响应数据；其中，响应数据为诊断终端针对与该响应数据对应的第一用户操作输出的数据，第一用户操作用于选择针对目标汽车的诊断功能。

第一生成单元，用于根据至少一个第一用户操作各自对应的事件以及至少一个第一用户操作各自对应的响应数据生成第一文件。

第一发送单元，用于发送第一文件给服务器，以使服务器根据第一文件确定至少一个诊断方案；诊断方案用于解决目标汽车的故障。

接收单元，用于接收服务器发送的至少一个诊断方案。

执行单元，用于接收诊断方案选择指令并执行。

在第四方面的一种可选方案中，第一文件还包括至少一个第一用户操作各自选择的诊断功能对应的诊断指令；诊断指令包括诊断终端和目标汽车交互的请求指令和响应指令。

在第四方面的又一种可选方案中，该诊断终端还包括：获取单元，用于在上述第一发送单元发送第一文件给服务器，以使服务器根据第一文件确定至少一个诊断方案之前，获取目标汽车的汽车总线的数据；第二生成单元，用于根据目标汽车的汽车总线的数据生成第二文件。

上述第一发送单元，具体用于发送第一文件和第二文件给服务器，以使服务器根据第一文件和第二文件确定至少一个诊断方案。

在第四方面的又一种可选方案中，该诊断终端还包括：

读取单元，用于在上述记录单元记录至少一个第一用户操作各自对应的事件以及至少一个第一用户操作各自对应的响应数据之前，读取配置文件，确定第一开关为开启状态；其中，第一开关用于控制以下至少一项：上述记录单元记录至少一个第一用户操作各自对应的事件以及至少一个第一用户操作各自对应的响应数据或者上述获取单元获取目标汽车的汽车总线的数据，配置文件包括第一开关的状态信息，状态信息为开启状态或关闭状态。

可能地，该诊断终端还包括：接收确定单元，用于在上述读取单元读取配置文件，确定第一开关为开启状态之前，接收用于设置第一开关的状态信息的第二用户操作；根据第二用户操作，确定配置文件包括的第一开关的状态信息。

在第四方面的又一种可选方案中，该诊断终端还包括：

获取标识单元，用于在上述记录单元记录至少一个第一用户操作各自对应的事件以及至少一个第一用户操作各自对应的响应数据之前，获取目标汽车的身份标识；第一文件和第二文件均包含目标汽车的身份标识；第一文件和第二文件均为经过加密的文件。

第五方面，本申请实施例提供了一种服务器，包括处理器、存储器以及通信接口；处理器与存储器、通信接口相连，其中通信接口用于连接诊断终端，存储器用于存储程序代码，处理器用于调用程序代码，以执行本申请实施例第一方面或第一方面的任意一种实现方式提供的汽车诊断方法。

第六方面，本申请实施例提供了一种诊断终端，包括处理器、存储器以及通信接口；处理器与存储器、通信接口相连，其中通信接口用于连接服务器，存储器用于存储程序代码，处理器用于调用程序代码，以执行本申请实施例第二方面或第二方面的任意一种实现方式提供的汽车诊断方法。

第七方面，本申请实施例提供了一种汽车诊断系统，包括目标汽车、诊断终端和服务器；其中，诊断终端通过有线或无线的方式和目标汽车及服务器建立数据连接关系；服务器为本申请实施例第三方面或第三方面的任意一种实现方式提供的服务器，诊断终端为本申请实施例第四方面或第四方面的任意一种实现方式提供的诊断终端。

第八方面，本申请实施例提供了一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序，当计算机程序在处理器上运行时，实现本申请实施例第一方面或第一方面的任意一种实现方式提供的汽车诊断方法。

第九方面，本申请实施例提供了一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序，当计算机程序在处理器上运行时，实现本申请实施例第二方面或第二方面的任意一种实现方式提供的汽车诊断方法。

第十方面，本申请实施例提供了一种计算机程序产品，当该计算机程序产品在服务器上运行时，使得该服务器执行本申请实施例第一方面或第一方面的任意一种实现方式提供的汽车诊断方法。

第十一方面，本申请实施例提供了一种计算机程序产品，当该计算机程序产品在诊断终端上运行时，使得该诊断终端执行本申请实施例第二方面或第二方面的任意一种实现方式提供的汽车诊断方法。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对本申请实施例或背景技术中所需要使用的附图作简单地介绍。

图1是本申请实施例提供的一种汽车诊断系统的架构示意图；

图2是一种车载诊断接口的结构示意图；

图3是本申请实施例提供的一种汽车诊断方法的流程示意图；

图4是本申请实施例提供的一种诊断终端界面实施例的示意图；

图5是本申请实施例提供的一种示例性的第一文件的示意图；

图6是本申请实施例提供的一种示例性的第二文件的示意图；

图7是本申请实施例提供的一种服务器的结构示意图；

图8是本申请实施例提供的一种诊断终端的结构示意图；

图9是本申请实施例提供的又一种服务器的结构示意图；

图10是本申请实施例提供的又一种诊断终端的结构示意图。

具体实施方式

下面将结合附图对本申请实施例中的技术方案进行描述。

请参见图1，图1是本申请实施例提供的一种汽车诊断系统的架构示意图。

如图1所示，汽车诊断系统可以包括汽车10、诊断终端20和服务器30。诊断终端20可以但不限于通过汽车的诊断接头(如车载诊断(on-board diagnostic，OBD)接头)和汽车10建立数据连接关系，从而获取汽车10的车辆信息和诊断数据。诊断终端20可以通过有线方式(例如但不限于，同轴电缆、光纤和数字用户线(digital subscriber Line，DSL)等)或无线方式(例如但不限于，蓝牙、无线上网(WIFI)和移动设备网络等)与服务器30建立数据连接关系。在需要获取用于解决汽车故障的诊断方案时，诊断终端20可以将诊断数据发送给服务器30。服务器30可以根据接收的诊断数据确定诊断方案，并将诊断方案发送给诊断终端20，以使使用诊断终端20的现场人员根据接收的诊断方案解决汽车10的故障。其中，汽车10的车辆信息包括但不限于车辆识别号码(vehicle identification number，VIN)、车辆型号、车辆的位置信息等。

汽车10可以包括汽车总线以及通过汽车总线相连的接口和节点集群。汽车总线可以但不限于是局域互联网络(local interconnect network，LIN)总线、控制器局域网络(controller area network，CAN)总线、SAE-J1850总线、ISO9141-2总线或ISO14230-4总线。

接口也可以称为OBD(车载诊断，on-board diagnostic)接口。OBD可以理解成为汽车故障诊断而延伸出来的一种检测系统，OBD经过发展包括OBD和比OBD更为先进的Ⅱ型车载诊断系统(on board diagnosticsⅡ，OBDⅡ)。在汽车诊断领域，OBDⅡ得到了越来越广泛的实施和应用。可参见图2，图2示例性示出了一种标准的16针的OBDⅡ接口的结构示意图。

如图2所示，OBDⅡ接口包括16个引脚。其中，第1号引脚、第3号引脚、第8号引脚、第11号引脚、第12号引脚和第13号引脚为汽车厂家自定义功能的引脚。第2号引脚表示SAE-J1850总线的正极，第10号引脚表示SAE-J1850总线的负极。第4号引脚表示车身接地极，第5号引脚表示信号接地极。第6号引脚表示CAN总线的显性电平，即CAN_H，第14号引脚表示CAN总线的隐形电平，即CAN_L。第7号引脚表示ISO9141-2总线或ISO14230-4总线的K线，第15号引脚表示ISO9141-2总线或ISO14230-4总线的L线。第16号引脚表示电源正极。

节点集群可以包括多个节点，具体包括节点1、节点2、···、节点n，节点集群中的任意一个节点均可以和汽车总线连接。节点集群中任意一个节点可以是电子控制单元(electronic control unit，ECU)。不同ECU可以用于管理不同的硬件装置和实现不同的功能。例如但不限于，节点1可以是发动机管理系统(engine management system，EMS)，节点2可以是网关(gateway，GW)，节点n可以是自动变速箱控制单元(transmission controlunit，TCU)。不限于上述列举的情况，ECU的种类繁多，还可以是辅助控制单元(auxiliarycontrol unit，ACU)、空调制冷(air conditioner，AC)和制动防抱死系统(antilock brakesystem，ABS)，本申请实施例对此不作限定。

ECU也可以称为行车电脑，是现代汽车电子的核心元件之一。ECU和其他电子控制元件一起组成了汽车的大脑神经中枢系统。汽车总线则是将ECU连接起来的介质。CAN是一种串行数据通信协议，由于其高性能、高可靠性和独特的设计，得到广泛的重视和应用。CAN总线系统中，多个ECU同时控制多个工作装置或系统，各个ECU的共用信息通过CAN总线互相传递。例如但不限于，CAN总线上各个ECU的通信可以通过组标准CANBUS协议的数据帧实现。

为了方便说明，本申请实施例以汽车总线为CAN总线，接口为OBD接口，节点集群中的任意一个节点为ECU，CAN总线上各个ECU通过组标准CANBUS协议的数据帧实现通信为例进行描述。

诊断终端20可以但不限于是手机、平板电脑、笔记本电脑、掌上电脑等具有显示面板的设备。

作为一种可选的实施方式，诊断终端20可以安装汽车诊断应用程序(Application，App)。该汽车诊断App可以包括多个诊断软件包，每个诊断软件包对应一种车型，使用诊断终端20的用户可以根据自身的汽车的车型购买相应的诊断软件包。

为了方便说明，本申请实施例以诊断终端20安装有汽车诊断App，汽车诊断App包括多个诊断软件包为例进行说明。

基于上述图1所示的汽车诊断系统，接下来介绍本申请实施例提供的汽车诊断方法。

请参见图3，图3是本申请实施例提供的一种汽车诊断方法的流程示意图，该方法可以基于图1所示的汽车诊断系统实现，该方法包括但不限于如下步骤：

步骤S310：诊断终端记录至少一个第一用户操作各自对应的事件以及至少一个第一用户操作各自对应的响应数据。

作为一种可选的实施方式，在步骤S310之前，该方法还可以包括：

步骤S301：诊断终端获取目标汽车的身份标识。

具体地，诊断终端获取目标汽车的身份标识，并根据该身份标识确定目标汽车的车型信息。

可能地，身份标识可以是车辆识别号码(vehicle identification number，VIN)。每辆汽车均有唯一的VIN码。VIN码的第1-3位可以表征车辆的产地、品牌与车系，第4-8位可以表征车辆特征，如种类，系列，车身类型等，第9位可以表征校验位通过一定的算法防止输入错误，第10位可以表征生产年份，第11位可以表征组装工厂的代码，第12-17位可以表征生产序列号。例如，诊断终端20获取的目标汽车的VIN码为LFPH4ACB411C02008，诊断终端20解析VIN码第1-3位可以得到目标汽车属于中国一汽轿车股份有限公司生产的红旗轿车系列，解析VIN码的第4-8位可以得到目标汽车属于红旗CA7180和CA7202系列，解析VIN码的第10位可以得到目标汽车的生产年份为2001年，后续以此类推，不予赘述。

步骤S302：诊断终端读取配置文件，确定第一开关为开启状态。

具体地，第一开关用于控制以下至少一项：步骤S310的记录至少一个第一用户操作各自对应的事件以及至少一个第一用户操作各自对应的响应数据，或者下述步骤S311的获取目标汽车的汽车总线的数据。

具体地，配置文件包括第一开关的状态信息，状态信息为开启状态或关闭状态。

具体地，第一开关可以称为诊断数据开关。在执行步骤S310和下述的步骤S311之前，诊断终端会先读取包括第一开关的状态信息的配置文件。在确定第一开关为开启状态的情况下才会执行步骤S310和步骤S311。从而更为有效地管控诊断终端记录的诊断数据的数据量，尽量避免诊断终端的存储空间占用过多的情况，减轻诊断终端的负担。

例如但不限于，配置文件中可以用Log的值表征第一开关的状态信息，Log＝0代表第一开关的状态为关闭状态，Log＝1代表第一开关的状态为开启状态。诊断终端读取配置文件中Log的值来确定第一开关的状态。

作为一种可选的实施方式，在步骤S302之前，该方法还可以包括：

接收用于设置第一开关的状态信息的第二用户操作；根据第二用户操作，确定配置文件包括的第一开关的状态信息。

可能地，用户可以在诊断终端的设置界面设置第一开关的状态为开启状态或关闭状态。第二用户操作可以但不限于是在诊断终端的设置界面点击或滑动第一开关对应的选项。

作为一种可选的实施方式，在步骤S310之前，该方法还可以包括：诊断终端接收第三用户操作。

具体地，诊断终端可以解析目标汽车的VIN码以得到目标汽车的车型信息，并在诊断终端的界面显示该车型信息。用户可以选择与目标汽车的车型对应的诊断软件包(即第三用户操作)，诊断终端可以接收第三用户操作，在该汽车诊断过程中执行步骤S310。

可能地，诊断终端的第一显示界面包括多个第一诊断选项，每个第一诊断选项对应一种车型。例如但不限于，图1所示的诊断终端20的显示界面为第一显示界面，该第一显示界面包括三个第一诊断选项和一个购买软件包选项。其中，三个第一诊断选项具体包括对应奥迪的诊断选项、对应路虎的诊断选项和对应本田的诊断选项。若目标汽车的车型不为奥迪、路虎和本田，可以点击第一显示界面所示的购买软件包选项，购买与目标汽车的车型对应的诊断软件包。

第三用户操作可以但不限于是用户针对第一显示界面中任意一个第一诊断选项的点击操作，通过执行第三用户操作对应的事件开始针对目标汽车的汽车诊断过程。第三用户操作用于选择与目标汽车的车型对应的第一诊断选项。

作为一种可选的实施方式，诊断终端的第二显示界面包括多个第二诊断选项，每个第二诊断选项对应一种诊断功能。其中，第二显示界面可以是诊断终端响应于第三用户操作后跳转的显示界面。诊断功能可以但不限于是读取故障码、读取数据流和执行器测试等等。第二显示界面具体的显示样式可参见下述图4示例性示出的诊断终端显示界面，此处暂不详述。

具体地，第一用户操作可以但不限于是用户针对第二显示界面中任意一个第二诊断选项的点击操作。第一用户操作对应的事件可以为诊断终端解析该第一用户操作得到的对应该第一用户操作这一行为的数据。例如但不限于，第一用户操作为用户针对第二显示界面中的读取故障码选项的点击操作，则第一用户操作对应的事件为读取故障码。第一用户操作对应的响应数据为诊断终端针对该第一用户操作输出的响应数据。例如但不限于，第一用户操作为用户针对第二显示界面中的读取故障码选项的点击操作，则第一用户操作的响应数据为诊断终端输出的故障码数据。第一用户操作对应的事件以及第一用户操作对应的响应数据在诊断终端中的存储形式可参见下述图5示例性示出的第一文件，此处暂不详述。

请参见图4，图4示例性示出了一种执行一个第一用户操作前后的诊断终端显示界面的对比图。其中，左图为执行第一用户操作前的诊断终端显示界面，右图为执行第一用户操作后的诊断终端显示界面。

如图4中的左图所示，诊断终端显示界面41可以包括目标汽车的ECU菜单410。ECU菜单410可以包括但不限于GW选项411、EMS选项412、ACU选项413、TCU选项414和ABS选项415。用户可以根据目标汽车的故障情况，在诊断终端显示界面41选择需诊断的ECU，例如图4所示的选择ACU选项413。

如图4中的右图所示，诊断终端显示界面42可以包括针对目标汽车的ACU的诊断功能菜单420。诊断功能菜单420可以包括但不限于版本信息选项421、读取故障码选项422、读取数据流选项423、执行器测试选项424和特殊功能选项425。用户可以在诊断终端显示界面42选择针对目标汽车的ACU的诊断功能。

如图4所示，诊断终端显示界面41和诊断终端显示界面42均包括上一步选项和取消选项。其中，上一步选项用于退回到诊断终端的当前显示界面的上一个显示界面。取消选项用于退出汽车诊断过程，即返回到诊断终端的第一显示界面(如图1所示的诊断终端20的显示界面)。

具体地，诊断终端响应于第三用户操作(如点击图1的诊断终端20的显示界面的奥迪选项)，开始针对目标汽车的汽车诊断过程。在该汽车诊断过程中，诊断终端接收至少一个第一用户操作(如点击图4的左图所示的ACU选项143)，记录至少一个第一用户操作各自对应的事件(如生成ACU的拓扑图)以及至少一个第一用户操作各自对应的响应数据(如图4的右图所示的针对ACU的诊断功能菜单422)。

作为一种可选的实施方式，步骤S310具体为：记录至少一个第一用户操作各自对应的事件、至少一个第一用户操作各自对应的响应数据以及至少一个第一用户操作各自选择的诊断功能对应的诊断指令。

具体地，诊断指令包括诊断终端和目标汽车交互的请求指令和响应指令。

可能地，诊断终端可以通过诊断接头和目标汽车建立数据连接关系，其中，诊断接头可以插在目标汽车的OBD接口上，如通过图2所示的OBDⅡ接口的第16号引脚为诊断接头供电，并将第6号引脚和第14号引脚作为通讯管脚。

诊断接头，例如但不限于，Ross-Tech公司的HEX-NET无线诊断接头和HEX-V2第二代诊断接头、博世公司的BOSCH EDC7UC31诊断接头和元征公司的DBSCar5诊断接头。

诊断终端可以通过有线方式(例如但不限于，同轴电缆、光纤和DSL等)或无线方式(例如但不限于，蓝牙、WIFI和移动设备网络等)连接诊断接头。诊断终端接收第一用户操作后，可以根据第一用户操作对应的事件(如读取数据流)，发送遵循厂家自定义标准或遵循D-PDU标准的请求命令给诊断接头。诊断接头将诊断终端发送的请求命令转换为CAN协议的数据帧(如组标准CANBUS协议的数据帧)，并把转换后的CAN协议的数据帧发送给ECU。ECU返回相应的响应数据帧给诊断接头，再由诊断接头将响应数据转换成遵循厂家自定义标准或遵循D-PDU标准的响应命令发送给诊断终端。从而完成了一次诊断终端和ECU的数据交互。

例如但不限于，第一用户操作为点击图4的右图所示的读取故障码选项422，第一用户操作对应的诊断功能为读取ACU的故障码(也是第一用户操作对应的事件)，第一用户操作对应的诊断指令可以包括诊断终端和诊断接头交互的遵循厂家自定义标准或遵循D-PDU标准的请求命令(该请求命令用于请求ACU的故障码)和响应命令(该响应命令可以包含ACU的故障码)。

作为一种可选的实施方式，在步骤S310之后，该方法还可以包括：

步骤S311：诊断终端获取目标汽车的汽车总线的数据。

可能地，步骤S311具体为诊断终端获取目标汽车的汽车总线的数据和ECU的数据。

具体地，汽车总线的数据可以但不限于是CAN数据帧和诊断故障代码(DiagnosticTrouble Code，DTC)。ECU的数据可以但不限于是ECU的版本和型号。汽车总线的数据和ECU的数据可以统称为汽车的原始诊断数据，原始诊断数据可以用于表征汽车的实时油耗、发动机水温、发动机转速、车辆行驶里程、电瓶压力、进气压力、冷却液温度、氧传感器电压发动机负载、节气门开度、点火正时和空气流量等等，不限于此。

在CANBUS组协议中，CAN总线上各个ECU之间是通过数据帧、要控帧、错误帧、过载帧和帧间隔这5种类型的帧进行数据交互的。其中，数据帧和要控帧是较为常见的帧。CAN系统不仅实现了ECU之间的通信，同时也为在线诊断提供了网络载体。诊断故障编码DTC基于统一诊断服务(unified diagnostic services，UDS)诊断规范，用于表征CAN总线上ECU之间记录的通信故障信息(例如通信丢失故障信息)。

ECU的数据可以包括但不限于ECU的版本和型号，例如博世BOSCH柴油高压共轨系统ECU的版本有EDC7_V24、EDC7_V47和EDC7_V72等。其中，EDC7_V24版本的ECU的型号有4E-30、4G-30、6A-30和6G-30等。

具体地，目标汽车的汽车总线的数据包括上述至少一个第一用户操作各自选择的诊断功能对应的汽车总线的数据。汽车总线的数据在诊断终端中的存储形式可参见下述图6示例性示出的第二文件，此处暂不详述。

例如但不限于，第一用户操作为点击图4的右图所示的读取故障码选项422，第一用户操作对应的诊断功能为读取ACU的故障码，第一用户操作对应的汽车总线的数据为诊断接头发送给ACU的请求数据和ACU回复给诊断接头的响应数据。其中，请求数据和响应数据为符合CANBUS组协议的数据帧，响应数据可以包括DTC、ACU的版本和型号等。

作为一种可选的实施方式，ECU发生故障时，ECU可以通过自诊断模块检测到系统部件故障，然后将故障信息以数字代码(如DTC)的形式存储在自诊断模块内部的存储介质中。诊断终端可以和ECU建立通信联系，ECU从自身的存储介质中读取数字代码并传输给诊断终端。诊断终端根据数字代码对应的故障信息来识别故障。

例如但不限于，当诊断终端需要获取TCU的故障信息时，诊断终端20可以发送读取故障信息请求给TCU，TCU进行回复。如表1和表2所示。表1和表2示例性示出了两种TCU回复的故障信息，其中，表1的故障信息表征TCU回复的DTC个数，表2的故障信息表征TCU回复的DTC内容。

表1 表征DTC个数的故障信息

时间戳	CAN ID	数据
			1572846840	7e1	03 19 01 FF 00 00 00 00
1572846900	7e9	06 59 01 FF 00 00 00 00

表2 表征DTC内容的故障信息

时间戳	CAN ID	数据
			1572846840	7e1	03 19 02 FF 00 00 00 00
1572846900	7e9	07 59 02 FF C1 21 20 DB

其中，时间戳是一串字符序列，能够唯一地标识某一刻的时间。CAN ID用于区分不同的数据帧，CAN总线上的每个节点设备可以接收和发送多条不同CAN ID的数据帧。例如，7e1的CAN ID为TCU诊断标识，7e9的CAN ID为TCU响应诊断标识。

表1和表2中的数据包括数据帧的具体信息，数据中每两个数字为1位。数据的第1位(例如表1和表2第一行的03)代表数据帧的长度。数据的第2和3位代表数据帧的服务类型，例如19代表数据帧的服务类型为读取故障码信息，19服务又包含01、02、04、06和OA等子服务。59代表读取故障码服务19的肯定响应服务。数据的第4-8位用于补充信息。例如，表1的第一行的数据帧的服务为19，子服务为01，对于该服务的数据帧而言，数据的第4位代表DTC状态掩码，即需要读取哪种状态的数据帧，如数据的第4位为表1所示的FF表示读取所有比特位置1的DTC。表2的第一行的数据帧的服务为19，子服务为02，对于该服务的数据帧而言，数据的第4-6位代表该DTC的内容，数据的第7-8位为填充字节。

不限于表1和表2所示的包含DTC的数据帧，在具体实现中，还有诊断终端20向TCU发送的建立诊断请求的数据帧，本申请实施例对此不作限定。

作为一种可选的实施方式，诊断终端接收的目标汽车的CAN数据帧可以为经过过滤的数据帧。在实际应用中，通常使用CAN ID来完成CAN数据帧的过滤。诊断终端可以设定接收的数据帧的CAN ID，以此仅接收符合设定条件的CAN数据帧，从而过滤掉不需要的信息，减轻诊断终端的处理负担。

不限于上述列举的情况，在具体实现中，用户操作对应的事件、响应数据和诊断指令，以及汽车总线的数据还可以是其他形式，本申请实施例对此不作限定。

步骤S320：诊断终端根据至少一个第一用户操作各自对应的事件以及至少一个第一用户操作各自对应的响应数据生成第一文件。

具体地，诊断终端可以根据步骤S310记录的至少一个第一用户操作各自对应的事件以及所述至少一个第一用户操作各自对应的响应数据生成第一文件。

作为一种可选的实施方式，在步骤S310为记录至少一个第一用户操作各自对应的事件、至少一个第一用户操作各自对应的响应数据以及至少一个第一用户操作各自选择的诊断功能对应的诊断指令时，步骤S320具体为：诊断终端根据至少一个第一用户操作各自对应的事件、至少一个第一用户操作各自对应的响应数据以及至少一个第一用户操作各自选择的诊断功能对应的诊断指令生成第一文件。

结合步骤S310、步骤S320和图4的描述，图5示例性示出了一种第一文件的内容格式实施例的示意图。

请参见图5，图5示例性示出了本申请实施例提供的一种第一文件的示意图。

如图5所示，第一文件可以包括基本信息51、多个第一用户操作各自对应的事件52、54、56、57和59、多个第一用户操作各自对应的响应数据53、55、58。

基本信息51可以包括第一文件对应的汽车诊断过程的诊断时间(date)、目标汽车的VIN码(vin)、诊断装置的产品序列号(boxSerial)、目标汽车的型号(vehicle)和是否上传(hasUploaded)。其中，hasUploaded的值用于表征该第一文件是否上传到服务器30，hasUploaded＝true表示第一文件已经上传到服务器30，hasUploaded＝false表示第一文件还未上传到服务器30。

第一文件中除基本信息51外的其他内容的顺序可以和汽车诊断过程中接收或响应第一用户操作的时间顺序一致。

可能地，对应于图5的52的用户操作可以但不限于是在诊断终端响应第三用户操作(如点击图1的诊断终端20的显示界面的奥迪选项)后的针对开始诊断选项的点击操作。诊断终端20接收该用户操作，并根据该用户操作向汽车发送获取汽车数据的请求，汽车将自身的汽车数据回复给诊断终端20。诊断终端存储并解析该数据，以此为之后的汽车诊断过程做准备。其中，汽车数据可以但不限于是基于诊断的数据交互方案(open diagnosticdata exchange，ODX)的数据。ODX是一种开放式的诊断数据格式，ODX格式的数据具有开源和标准化的属性，因此ODX格式的数据常用于整车生命周期中诊断数据的交互。

如图5的52所示，括号框包含operateRecords表示该括号框内的内容对应的用户操作为界面操作。type用于表征第一用户操作的类型，如type＝文本对话框表示诊断终端的显示界面上对应该第一用户操作的显示类型为文本对话框。Content的内容用于表征诊断终端的显示界面上对应该第一用户操作的详细显示内容，如正在解析文件，请等候。其中，这里的文件可以为上述的汽车数据(如ODX格式的数据)。input用于表征该第一用户操作对应的事件中对应用户输入的部分。time可以为诊断终端接收或响应该第一用户操作的时刻。例如但不限于，图5所示的52对应的第一用户操作为上述的点击开始诊断选项，诊断终端中该第一用户操作对应的事件为获取并解析汽车数据(如ODX格式的数据)。

如图5的53所示，括号框包含Topology表示该括号框内的内容为汽车的ECU列表。图5的53所示的内容为诊断终端针对图5的52对应的第一用户操作输出的响应数据。

图5的53、54和55可以对应上述图4所示的诊断终端显示界面41、诊断终端显示界面42和点击ACU选项413的第一用户操作。其中，图5的53所示的响应数据对应图4的左图所示的诊断终端显示界面41的ECU菜单410，图5的55所示的响应数据对应图4的右图所示的诊断终端显示界面42的诊断功能菜单420，图5的54所示的事件对应的第一用户操作为图4所示的点击ACU选项413。

图5的56所示的事件、57所示的事件和58所示的响应数据对应的第一用户操作相同，该第一用户操作可以是点击图4的右图所示的读取故障码选项422。

图5的59所示的事件对应的第一用户操作可以为点击上传诊断数据选项。该第一用户操作也可以称为第四用户操作，诊断终端响应于第四用户操作，生成如图5所示的第一文件。

不限于图5所示的第一文件，在具体实现中，第一文件还可以包括其他内容，本申请对此不作限定。

作为一种可选的实施方式，在该汽车诊断方法包括步骤S311的情况下，在步骤S320之后，该方法还可以包括：

步骤S321：诊断终端根据目标汽车的汽车总线的数据生成第二文件。

作为一种可选的实施方式，第一文件和第二文件可以为同一文件。即步骤S320可以为根据至少一个第一用户操作各自对应的事件、至少一个第一用户操作各自对应的响应数据、至少一个第一用户操作各自选择的诊断功能对应的诊断指令以及目标汽车的汽车总线的数据生成第一文件。

具体地，第二文件可以但不限于包括上述步骤S311描述的CAN数据帧、DTC、ECU的版本和型号等。

请参见图6，图6示例性示出了本申请实施例提供的一种第二文件的示意图。

如图6所示，该第二文件可以包括基本信息61和包含多个汽车总线的数据的数据列表62。基本信息61可以包括但不限于生成第二文件的时刻和简单说明。其中，基本信息61中的简单说明Open CAN bus log！表示数据列表62包含的多个汽车总线的数据为CAN总线的数据。

如图6所示，数据列表62仅示例了包含DTC的数据帧。结合上述的表1和表2，数据列表62中的数据帧包括时间戳621、CAN ID622和数据623。包含DTC的数据帧的描述可参见上述表1和表2的说明，此处不予赘述。

不限于上述图6列举的第二文件，在具体实现中，第二文件还可以包括CAN总线传输的数据帧、ECU的版本和型号。本申请实施例对此不作限定。

作为一种可选的实施方式，步骤S320和步骤S321之前，该方法还可以包括：诊断终端接收第四用户操作。

具体地，第四用户操作可以但不限于是针对上传诊断数据选项、结束诊断选项和获取诊断方案选项的点击操作。诊断终端响应于第四用户操作，执行步骤S320和步骤S321，结束诊断终端侧的汽车诊断过程。

作为一种可选的实施方式，第一文件和第二文件可以均为经过加密后的文件。

汽车诊断过程中诊断终端记录的诊断数据，以及根据诊断数据生成的第一文件和第二文件可以经过加密处理，从而防止数据泄露，增加核心数据的安全性。

作为一种可选的实施方式，第一文件和第二文件的文件名均可以包含以下至少一项：目标汽车的身份标识、上述诊断终端接收或响应第三用户操作的时刻或上述接收或响应第四用户操作的时刻。

目标汽车的身份标识可以是VIN码。上述诊断终端接收或响应第三用户操作的时刻也可以称为汽车诊断过程的开始时刻，上述接收或响应第四用户操作的时刻也可以称为汽车诊断过程的结束时刻。用于汽车诊断的第一文件和第二文件的文件名可以包括目标汽车的身份标识、汽车诊断过程的开始时刻或汽车诊断过程的结束时刻。从而能够区分目标汽车和其他汽车的诊断数据，区分用户在不同时刻对汽车进行故障诊断的诊断数据，更为方便快捷地管理和查询汽车的诊断数据文件。

例如但不限于，第一文件或第二文件的文件名可以包括目标汽车的VIN码和接收第三用户操作的时刻，即LFPH4ACB411C02008_2019-09-03-13-51log.txt。

不限于上述列举的情况，在具体实现中，诊断终端的显示界面、第一用户操作、第二用户操作、第三用户操作、第四用户操作还可以是其他形式，本申请实施例对此不作限定。

步骤S330：诊断终端发送第一文件给服务器。

作为一种可选的实施方式，在该汽车诊断方法包括步骤S311和步骤S321的情况下，该方法还可以包括：步骤S331：诊断终端发送第二文件给服务器。

步骤S340：服务器接收诊断终端发送的第一文件。

具体地，第一文件包括的数据的描述可参见上述步骤S310、步骤S320和图5的示例，此处不予赘述。

作为一种可选的实施方式，在该汽车诊断方法包括步骤S311、步骤S321和步骤S331的情况下，该方法还可以包括：步骤S341：服务器接收诊断终端发送的第二文件。

具体地，第二文件包括的数据的描述可参见上述步骤S311、步骤S321和图6的示例，此处不予赘述。

不限于上述列举的情况，在具体实现中，步骤S301和步骤S302的顺序可以交换，步骤S310和步骤S311的顺序可以交换，步骤S320和步骤S321的顺序可以交换，步骤S330和步骤S331的顺序可以交换，步骤S340和步骤S341的顺序可以交换，本申请实施例对此不对限定。

步骤S350：服务器根据第一文件确定至少一个诊断方案。

作为一种可选的实施方式，在该汽车诊断方法包括步骤S341的情况下，步骤S350为根据第一文件和第二文件确定至少一个诊断方案。

具体地，服务器可以通过包含多个已知故障情况的故障问题库来确定诊断方案。故障问题库可以包括多个故障信息以及多个故障信息各自对应的第一解决方法。其中，故障信息包括以下至少一项：诊断功能对应的事件、诊断功能对应的响应数据、诊断功能对应的诊断指令或诊断功能对应的汽车总线的数据。

服务器可以将第一文件包括的数据、第二文件包括的数据和故障问题库包括的多个故障信息进行对比。例如但不限于，将第一文件包括的第一用户操作对应的事件(如读取ECU的故障码)、第一用户操作对应的响应数据(如压力传感器的电压为5.8伏特，压力传感器的电压超过最大阈值4.883伏特，故障码为P0108)与故障问题库包括的多个故障信息(其中一个故障信息为故障码为P0108，压力传感器的电压超过4.883伏特)进行对比。

服务器确定与第一文件和第二文件匹配的至少一个目标故障信息。至少一个目标故障信息为故障问题库包括的多个故障信息中的一个或多个故障信息。

当故障问题库存在至少一个目标故障信息的情况下，确定至少一个目标故障信息各自对应的第一解决方法。例如但不限于，上述的故障码为P0108，压力传感器的电压超过4.883伏特为确定的目标故障信息。故障问题库中包含与该目标故障信息对应的第一解决方法，从而得到包含与该目标故障信息对应的第一解决方法的诊断方案。

当故障问题库不存在至少一个目标故障信息的情况下，对第一文件和第二文件进行分析处理，得到用于解决目标汽车的故障的第二解决方法。从而得到包含第二解决方法的诊断方案。

需要说明的是，第一解决方法和第二解决方法仅用于区分是否为故障问题库中已有的解决方法，第一解决方法包含的内容可以和第二解决方法包含的内容一致。

作为一种可选的实施方式，服务器将第一文件包括的数据、第二文件包括的数据和故障问题库包括的多个故障信息进行对比，并确定与第一文件和第二文件匹配的至少一个目标故障信息时，可以根据第一文件包括的数据、第二文件包括的数据和故障信息包括的数据，计算目标汽车的故障和故障问题库中已有的故障信息的匹配度。在故障信息对应的匹配度大于预设阈值(如80％)的情况下，确定该故障信息为目标故障信息。本申请实施例对于预设阈值的设置方法不作限制。

不限于上述列举的情况，在具体实现中，还可以通过算法分析等方式确定与第一文件和第二文件匹配的至少一个目标故障信息，本申请实施例对此不作限定。

作为一种可选的实施方式，当故障问题库不存在至少一个目标故障信息的情况下，服务器可以结合服务器内置或互联网上的推理规则对第一文件和第二文件进行分析处理，得到用于解决目标汽车的故障的第二解决方法。

不限于上述列举的情况，在具体实现中，还可以是原厂的汽修人员下载第一文件和第二文件，人工分析处理并生成诊断方案。本申请实施例对此不作限定。

作为一种可选的实施方式，可以通过服务器已经处理和分析的汽车故障、互联网上的已有案例或用户手动输入的案例等数据不断丰富故障问题库。

不限于上述列举的情况，故障问题库还可以包括其他和汽车诊断有关的数据，本申请实施例对此不做限定。

步骤S360：服务器发送至少一个诊断方案给诊断设备。

步骤S370：诊断终端接收服务器发送的至少一个诊断方案。

步骤S380：诊断终端接收诊断方案选择指令并执行。

具体地，诊断方案可以包括用于解决目标汽车的故障的诊断功能指令。诊断终端可以执行诊断方案提供的诊断功能等指令来对目标汽车进行诊断，从而解决目标汽车的故障。

不限于上述列举的情况，在具体实现中，还可以是使用诊断终端的现场人员根据诊断方案提供的解决方法解决目标汽车的故障。本发明实施例对此不做限制。

作为一种可选的实施方式，诊断方案可以但不限于包括第一文件中部分或全部的数据、第二文件中部分或全部的数据、故障问题库中的故障信息、第一解决方法和第二解决方法。从而使得诊断终端获取更为清晰全面的诊断方案，快速有效解决汽车故障。

例如但不限于，当目标汽车的节点1(如EMS)发生故障时，现场人员可以连接目标汽车和诊断终端。诊断终端可以接收并解析目标汽车发送的VIN码，确定目标汽车的车型为奥迪，并显示在诊断终端的界面上。现场人员可以根据诊断终端界面显示的车型结果，在诊断终端上选择与目标汽车的车型对应的诊断软件包(即第三用户操作)。例如但不限于，现场人员点击图1中诊断终端20的显示界面上的奥迪选项，开始针对车型为奥迪的目标汽车的汽车诊断过程。

在汽车诊断过程中，现场人员可以根据诊断终端的显示界面的提示，选择需要的诊断功能(即第一用户操作)。诊断终端可以记录汽车诊断过程中部分或全部的第一用户操作(用于选择需要的诊断功能)对应的事件、对应的响应数据及对应的诊断指令作为诊断数据。

最后，现场人员可以但不限于点击上传诊断数据或获取诊断方案的按钮，结束汽车诊断过程。其中，目标汽车可以在汽车诊断过程中或汽车诊断过程结束后将目标汽车的汽车总线的数据发送给诊断终端。诊断终端可以将根据自身记录的诊断数据生成的第一文件，以及根据目标汽车发送的汽车总线的数据生成的第二文件均发送给服务器。由服务器和原厂的汽修人员配合分析第一文件和第二文件，从而得到用于解决目标汽车的故障的诊断方案。服务器将得到的诊断方案发送给诊断终端，以使诊断终端执行诊断方案提供的指令解决目标汽车的故障。

可以理解地，现有技术中的用于汽车诊断的诊断数据只是记录了诊断终端执行的一些简单流程或诊断终端的专业的开发者日志。这样的诊断数据导致远程排查的过程效率低下，汽车故障难以得到及时有效地解决。在本申请实施例中，用于汽车诊断的第一文件包括使用诊断终端的现场人员在汽车诊断过程中执行的部分或所有的操作步骤、用户操作对应的诊断终端和目标汽车交互的诊断指令，以及诊断终端针对执行的用户操作返回的数据结果。通过分析第一文件包括的数据，能够便于复现现场人员使用诊断终端进行汽车诊断的故障场景，减少远程排查过程中了解故障情况的时间，便于及时有效地解决故障。本申请实施例中还包括用于汽车诊断的第二文件，第二文件包括目标汽车的汽车总线的数据(如汽车总线传输的数据帧、诊断故障代码、汽车电子控制单元的版本和型号等)。结合第一文件和第二文件确定诊断方案，能够基于更为全面有效的汽车诊断数据来定位故障原因和确定诊断方案。从而提高整个故障排查过程的效率，提升用户体验感。

上述详细阐述了本申请实施例的方法，为了便于更好地实施本申请实施例的上述方案，相应地，下面提供了本申请实施例的相关装置。

请参见图7，图7是本申请实施例提供的一种服务器的结构示意图。服务器70包括第一接收单元701、确定单元702和发送单元703，其中，各个单元的详细描述如下：

第一接收单元701，用于接收诊断终端发送的第一文件。

具体地，第一文件包括至少一个第一用户操作各自对应的事件以及至少一个第一用户操作各自对应的响应数据。响应数据为诊断终端针对与该响应数据对应的第一用户操作输出的数据。第一用户操作用于选择针对目标汽车的诊断功能。

确定单元702，用于根据第一文件确定至少一个诊断方案。其中，诊断方案用于解决目标汽车的故障。

发送单元703，用于发送至少一个诊断方案给诊断终端。

作为一种可选的实施方式，第一文件还包括至少一个第一用户操作各自选择的诊断功能对应的诊断指令。

作为一种可选的实施方式，服务器70还可以包括：

第二接收单元，用于在发送单元703发送至少一个诊断方案给诊断终端之前，接收诊断终端发送的第二文件。

具体地，第二文件包括目标汽车的汽车总线的数据。目标汽车的汽车总线的数据包括至少一个第一用户操作各自选择的诊断功能对应的汽车总线的数据。

确定单元702，具体用于根据第一文件和第二文件确定至少一个诊断方案。

作为一种可选的实施方式，确定单元702可以包括：

对比子单元，用于将第一文件包括的数据、第二文件包括的数据和故障问题库包括的多个故障信息进行对比。

具体地，故障问题库包括多个故障信息以及多个故障信息各自对应的第一解决方法。故障信息包括以下至少一项：诊断功能对应的事件、诊断功能对应的响应数据、诊断功能对应的诊断指令或诊断功能对应的汽车总线的数据。

第一确定子单元，用于确定与第一文件和第二文件匹配的至少一个目标故障信息。其中，至少一个目标故障信息为上述多个故障信息中的一个或多个故障信息。

第二确定子单元，用于当故障问题库存在至少一个目标故障信息的情况下，确定至少一个目标故障信息各自对应的第一解决方法。其中，诊断方案包括至少一个目标故障信息各自对应的第一解决方法。

第三确定子单元，用于当故障问题库不存在至少一个目标故障信息的情况下，对第一文件和第二文件进行分析处理，得到用于解决目标汽车的故障的第二解决方法。其中，诊断方案包括第二解决方法。

作为一种可选的实施方式，第一文件和第二文件均包含目标汽车的身份标识。第一文件和第二文件均为经过加密的文件。

需要说明的是，在本申请实施例中，各个单元的具体实现还可以对应参照图3所示的方法实施例中的步骤S340到步骤S360的相应描述。

请参见图8，图8是本申请实施例提供的一种诊断终端的结构示意图。诊断终端80可以包括记录单元801、第一生成单元802、第一发送单元803和接收单元804，其中，各个单元的详细描述如下：

记录单元801，用于记录至少一个第一用户操作各自对应的事件以及至少一个第一用户操作各自对应的响应数据。

具体地，响应数据为诊断终端针对与该响应数据对应的第一用户操作输出的数据。第一用户操作用于选择针对目标汽车的诊断功能。

第一生成单元802，用于根据至少一个第一用户操作各自对应的事件以及至少一个第一用户操作各自对应的响应数据生成第一文件。

第一发送单元803，用于发送第一文件给服务器，以使服务器根据第一文件确定至少一个诊断方案。其中，诊断方案用于解决目标汽车的故障。

接收单元804，用于接收服务器发送的至少一个诊断方案。

执行单元805，用于接收诊断方案选择指令并执行。

作为一种可选的实施方式，诊断终端80还可以包括：

获取单元，用于在第一发送单元803发送第一文件给服务器，以使服务器根据第一文件确定至少一个诊断方案之前，获取目标汽车的汽车总线的数据。

第二生成单元，用于根据目标汽车的汽车总线的数据生成第二文件。

第一发送单元803，具体用于发送第一文件和第二文件给服务器，以使服务器根据第一文件和第二文件确定至少一个诊断方案。

作为一种可选的实施方式，诊断终端80还可以包括：

读取单元，用于在记录单元801记录至少一个第一用户操作各自对应的事件以及至少一个第一用户操作各自对应的响应数据之前，读取配置文件，确定第一开关为开启状态。

具体地，第一开关用于控制以下至少一项：记录单元801记录至少一个第一用户操作各自对应的事件以及至少一个第一用户操作各自对应的响应数据或者上述获取单元获取目标汽车的汽车总线的数据。配置文件包括第一开关的状态信息，状态信息为开启状态或关闭状态。

可能地，诊断终端80还可以包括：

接收确定单元，用于在上述读取单元读取配置文件，确定第一开关为开启状态之前，接收用于设置第一开关的状态信息的第二用户操作；根据第二用户操作，确定配置文件包括的第一开关的状态信息。

作为一种可选的实施方式，诊断终端80还可以包括：

获取标识单元，用于在记录单元801记录至少一个第一用户操作各自对应的事件以及至少一个第一用户操作各自对应的响应数据之前，获取目标汽车的身份标识。

具体地，第一文件和第二文件均包含目标汽车的身份标识。第一文件和第二文件均为经过加密的文件。

可能地，身份标识是车辆识别号码(vehicle identification number，VIN)。其中，每辆汽车均有唯一的VIN码，VIN码用于确定汽车的车型信息。车型信息包括以下至少一项：汽车的产地、品牌、车系、种类、系列、车身类型、车型年份或组装工厂的代码。

需要说明的是，在本申请实施例中，各个单元的具体实现还可以对应参照图3所示的方法实施例中的步骤S301到步骤S331的相关描述和步骤S370的相应描述。

请参见图9，图9是本申请实施例提供的又一种服务器的结构示意图。服务器90可以包括：至少一个处理器901，例如中央处理器(central processing unit，CPU)，至少一个网络接口904，用户接口903，存储器905，至少一个通信总线902。其中，通信总线902用于实现这些组件之间的连接通信。用户接口903可以包括但不限于键盘、鼠标、摇杆等等。网络接口904可选的可以包括标准的有线接口、无线接口(如WIFI接口、蓝牙接口)，通过网络接口904可以与诊断终端建立通信连接。存储器805可以是高速的随机存取存储器(RandomAccess Memory，RAM)，也可以是非易失性存储器(non-volatile memory，NVM)，例如至少一个磁盘存储器。如图9所示，作为一种计算机存储介质的存储器905中可以包括操作系统、网络通信模块、用户接口模块以及程序指令。

需要说明的是，网络接口904可以连接获取器、发射器或其他通信模块，其他通信模块可以包括但不限于WiFi模块、蓝牙模块等，可以理解，本申请实施例中服务器90也可以包括获取器、发射器和其他通信模块等。

处理器901可以用于调用存储器905中存储的程序指令，以执行如图3所示方法中的步骤S340到步骤S360。

请参见图10，图10是本申请实施例提供的又一种诊断终端的结构示意图。诊断终端10可以包括：至少一个处理器101，例如CPU，至少一个网络接口104，用户接口103，存储器105，至少一个通信总线102。其中，通信总线102用于实现这些组件之间的连接通信。用户接口103可以包括但不限于键盘、鼠标、摇杆、触控面板等等。网络接口104可选的可以包括标准的有线接口、无线接口(如WIFI接口、蓝牙接口)，通过网络接口104可以与服务器建立通信连接，通过网络接口104也可以与汽车建立通信连接。存储器105可以是高速的RAM，也可以是NVM，例如至少一个磁盘存储器。如图10所示，作为一种计算机存储介质的存储器105中可以包括操作系统、网络通信模块、用户接口模块以及程序指令。

需要说明的是，网络接口104可以连接获取器、发射器或其他通信模块，其他通信模块可以包括但不限于WiFi模块、蓝牙模块等，可以理解，本申请实施例中诊断终端10也可以包括获取器、发射器和其他通信模块等。

处理器101可以用于调用存储器105中存储的程序指令，以执行如图3所示方法中的步骤S301到步骤S331，以及步骤S370。

本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算机或处理器上运行时，使得计算机或处理器执行上述图3所示的方法中一个或多个步骤。上述汽车诊断相关装置的各组成模块如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在所述计算机可读取存储介质中。

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

综上所述，目前用于协助远程汽车故障排查的诊断数据只记录了诊断终端执行的一些简单流程或诊断终端的开发者日志。这样的诊断数据导致故障排查的效率不高，问题解决时间长。本申请实施例中，用于汽车诊断的第一文件包括使用诊断终端的现场人员在汽车诊断过程中执行的部分或所有的操作步骤以及诊断终端针对执行的用户操作返回的数据结果。通过分析第一文件包括的数据，能够便于复现现场人员使用诊断终端进行汽车诊断的故障场景，减少远程排查过程中了解故障情况的时间，便于及时有效地解决故障。本申请实施例中还包括用于汽车诊断的第二文件，第二文件包括目标汽车的汽车总线的数据。结合第一文件和第二文件确定诊断方案，能够基于更为全面有效的汽车诊断数据来定位故障原因和确定诊断方案。从而提高整个故障排查过程的效率，提升用户体验感。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，该的程序可存储于计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。而前述的存储介质包括：只读存储器(read-only memory，ROM)、RAM、磁碟或者光盘等各种可存储程序代码的介质。

Claims

1.一种汽车诊断方法，其特征在于，包括：

服务器接收诊断终端发送的第一文件；其中，所述第一文件包括至少一个第一用户操作各自对应的事件以及所述至少一个第一用户操作各自对应的响应数据，所述响应数据为所述诊断终端针对与所述响应数据对应的第一用户操作输出的数据，所述第一用户操作用于选择针对目标汽车的诊断功能；

根据所述第一文件确定至少一个诊断方案；所述诊断方案用于解决所述目标汽车的故障；

发送所述至少一个诊断方案给所述诊断终端。

2.如权利要求1所述的方法，其特征在于，所述第一文件还包括所述至少一个第一用户操作各自选择的诊断功能对应的诊断指令；所述诊断指令包括所述诊断终端和所述目标汽车交互的请求指令和响应指令。

3.如权利要求2所述的方法，其特征在于，所述发送所述至少一个诊断方案给所述诊断终端之前，所述方法还包括：

接收所述诊断终端发送的第二文件；其中，所述第二文件包括所述目标汽车的汽车总线的数据，所述目标汽车的汽车总线的数据包括所述至少一个第一用户操作各自选择的诊断功能对应的汽车总线的数据；

所述根据所述第一文件确定至少一个诊断方案，包括：

根据所述第一文件和所述第二文件确定所述至少一个诊断方案。

4.如权利要求3所述的方法，其特征在于，所述根据所述第一文件和所述第二文件确定所述至少一个诊断方案，包括：

将所述第一文件包括的数据、所述第二文件包括的数据和故障问题库包括的多个故障信息进行对比；其中，所述故障问题库包括所述多个故障信息以及所述多个故障信息各自对应的第一解决方法，所述故障信息包括以下至少一项：诊断功能对应的事件、诊断功能对应的响应数据、诊断功能对应的诊断指令或诊断功能对应的汽车总线的数据；

确定与所述第一文件和所述第二文件匹配的至少一个目标故障信息；所述至少一个目标故障信息为所述多个故障信息中的一个或多个故障信息；

当所述故障问题库存在所述至少一个目标故障信息的情况下，确定所述至少一个目标故障信息各自对应的第一解决方法；所述诊断方案包括所述至少一个目标故障信息各自对应的第一解决方法；

当所述故障问题库不存在所述至少一个目标故障信息的情况下，对所述第一文件和所述第二文件进行分析处理，得到用于解决所述目标汽车的故障的第二解决方法；所述诊断方案包括所述第二解决方法。

5.一种汽车诊断方法，其特征在于，包括：

诊断终端记录至少一个第一用户操作各自对应的事件以及所述至少一个第一用户操作各自对应的响应数据；其中，所述响应数据为所述诊断终端针对与所述响应数据对应的第一用户操作输出的数据，所述第一用户操作用于选择针对目标汽车的诊断功能；

根据所述至少一个第一用户操作各自对应的事件以及所述至少一个第一用户操作各自对应的响应数据生成第一文件；

发送所述第一文件给服务器，以使所述服务器根据所述第一文件确定至少一个诊断方案；所述诊断方案用于解决所述目标汽车的故障；

接收所述服务器发送的所述至少一个诊断方案；

接收诊断方案选择指令并执行。

6.如权利要求5所述的方法，其特征在于，所述发送所述第一文件给服务器，以使所述服务器根据所述第一文件确定至少一个诊断方案之前，所述方法还包括：

获取所述目标汽车的汽车总线的数据；所述目标汽车的汽车总线的数据包括所述至少一个第一用户操作各自选择的诊断功能对应的汽车总线的数据；

根据所述目标汽车的汽车总线的数据生成第二文件；

所述发送所述第一文件给服务器，以使所述服务器根据所述第一文件确定至少一个诊断方案，包括：

发送所述第一文件和所述第二文件给所述服务器，以使所述服务器根据所述第一文件和所述第二文件确定所述至少一个诊断方案。

7.如权利要求6所述的方法，其特征在于，所述诊断终端记录至少一个第一用户操作各自对应的事件以及所述至少一个第一用户操作各自对应的响应数据之前，所述方法还包括：

读取配置文件，确定第一开关为开启状态；其中，所述第一开关用于控制以下至少一项：所述诊断终端记录至少一个第一用户操作各自对应的事件以及所述至少一个第一用户操作各自对应的响应数据或者所述获取所述目标汽车的汽车总线的数据，所述配置文件包括所述第一开关的状态信息，所述状态信息为所述开启状态或关闭状态。

8.如权利要求6或7所述的方法，其特征在于，所述诊断终端记录至少一个第一用户操作各自对应的事件以及所述至少一个第一用户操作各自对应的响应数据之前，所述方法还包括：

获取所述目标汽车的身份标识；

所述第一文件和所述第二文件均包含所述身份标识，所述第一文件和所述第二文件均为经过加密的文件。

9.一种服务器，其特征在于，包括处理器、存储器以及通信接口；

所述处理器与所述存储器、所述通信接口相连，其中所述通信接口用于连接诊断终端，所述存储器用于存储程序代码，所述处理器用于调用所述程序代码，以执行如权利要求1-4任一项所述的方法。

10.一种诊断终端，其特征在于，包括处理器、存储器以及通信接口；

所述处理器与所述存储器、所述通信接口相连，其中所述通信接口用于连接服务器，所述存储器用于存储程序代码，所述处理器用于调用所述程序代码，以执行如权利要求5-8任一项所述的方法。