车辆检测方法、装置、电子设备及存储介质与流程

1.本技术属于车辆技术领域，尤其涉及一种车辆检测方法、装置、电子设备及存储介质。


背景技术：

2.随着社会的持续快速发展，汽车已成为人们出行的重要交通工具，当汽车出行故障时，可通过车辆诊断设备进行故障检测。
3.目前在进行故障检测时，通常是按照固定的顺序对汽车的多个电子控制单元((electronic control unit，ecu)进行检测，比如固定顺序为发动机ecu
‑
轮胎ecu
‑
防抱死制动系统(anti
‑
lock braking system，abs)ecu
‑
仪表ecu等，车辆检测智能性低。


技术实现要素：

4.本技术实施例提供了一种车辆检测方法、装置、电子设备及存储介质，旨在解决现有车辆检测智能性低的问题。
5.第一方面，本技术实施例提供了一种车辆检测方法，包括：
6.获取目标车辆的检测场景类别；
7.根据所述检测场景类别获取对应的车辆信息；
8.根据所述检测场景类别以及对应的车辆信息，确定待检测电子控制单元的检测顺序；
9.根据所述检测顺序，对所述待检测电子控制单元进行检测。
10.在一个实施例中，所述根据所述检测场景类别获取对应的车辆信息，包括：
11.在确定所述检测场景类别为保养检测场景类别时，获取所述目标车辆的行驶信息及车型信息。
12.在一个实施例中，所述行驶信息包括里程信息；所述根据所述检测场景类别以及对应的车辆信息，确定待检测电子控制单元的检测顺序，包括：
13.从预设数据库获取与目标车辆同车型且同里程的车辆的各个系统的故障概率；
14.根据各个系统的故障概率的高低确定目标车辆的待检测电子控制单元的检测顺序。
15.所述行驶信息包括里程信息；所述根据所述检测场景类别以及对应的车辆信息，确定待检测电子控制单元的检测顺序，包括：
16.从预设数据库获取与目标车辆同车型且同里程的车辆的各个系统的保养频率；
17.根据各个系统的保养频率的高低确定目标车辆的待检测电子控制单元的检测顺序。
18.在一个实施例中，所述根据所述检测场景类别获取对应的车辆信息，包括：
19.在确定所述检测场景类别为故障检测场景类别时，获取所述目标车辆的故障信息及车型信息。
20.在一个实施例中，所述根据所述检测场景类别以及对应的车辆信息，确定待检测电子控制单元的检测顺序，包括：
21.从预设数据库获取与目标车辆同车型的车辆的维修记录；
22.根据所述维修记录查询所述故障信息对应的故障系统名单；
23.根据所述故障系统名单确定目标车辆的待检测电子控制单元的检测顺序。
24.在一个实施例中，所述根据所述维修记录查询所述故障信息对应的故障系统名单之后，还包括：
25.获取所述故障系统名单中各个系统对应所述故障信息的故障概率；
26.对应地，所述根据所述故障系统名单确定目标车辆的待检测电子控制单元的检测顺序，包括：
27.根据所述故障系统名单中各个系统对应所述故障信息的故障概率，确定目标车辆的待检测电子控制单元的检测顺序。
28.第二方面，本技术实施例提供了一种车辆检测装置，包括：
29.场景获取模块，用于获取目标车辆的检测场景类别；
30.车辆信息获取模块，用于根据所述检测场景类别获取对应的车辆信息；
31.检测顺序确定模块，用于根据所述检测场景类别以及对应的车辆信息，确定待检测电子控制单元的检测顺序；
32.检测模块，用于根据所述检测顺序，对所述待检测电子控制单元进行检测。
33.在一个实施例中，车辆信息获取模块包括：
34.第一车辆信息获取单元，用于在确定所述检测场景类别为保养检测场景类别时，获取所述目标车辆的行驶信息及车型信息。
35.在一个实施例中，所述行驶信息包括里程信息；所述检测顺序确定模块包括：
36.第一获取单元，用于从预设数据库获取与目标车辆同车型且同里程的车辆的各个系统的故障概率；
37.第一检测顺序确定单元，用于根据各个系统的故障概率的高低确定目标车辆的待检测电子控制单元的检测顺序。
38.在一个实施例中，所述行驶信息包括里程信息；所述检测顺序确定模块包括：
39.第二获取单元，用于从预设数据库获取与目标车辆同车型且同里程的车辆的各个系统的保养频率；
40.第二检测顺序确定单元，用于根据各个系统的保养频率的高低确定目标车辆的待检测电子控制单元的检测顺序。
41.在一个实施例中，车辆信息获取模块还包括：
42.第二车辆信息获取单元，用于在确定所述检测场景类别为故障检测场景类别时，获取所述目标车辆的故障信息及车型信息。
43.在一个实施例中，所述检测顺序确定模块包括：
44.第三获取单元，用于从预设数据库获取与目标车辆同车型的车辆的维修记录；
45.查询单元，用于根据所述维修记录查询所述故障信息对应的故障系统名单；
46.第三检测顺序确定单元，用于根据所述故障系统名单确定目标车辆的待检测电子控制单元的检测顺序。
47.在一个实施例中，检测顺序确定模块还包括：
48.第四获取单元，用于获取所述故障系统名单中各个系统对应所述故障信息的故障概率；
49.对应地，所述第三检测顺序确定单元具体用于：根据所述故障系统名单中各个系统对应所述故障信息的故障概率，确定目标车辆的待检测电子控制单元的检测顺序。
50.第三方面，本技术实施例提供了一种电子设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述车辆检测方法的步骤。
51.第四方面，本技术实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，上述计算机程序被处理器执行时实现上述车辆检测方法的步骤。
52.第五方面，本技术实施例提供了一种计算机程序产品，当计算机程序产品在电子设备上运行时，使得电子设备执行上述车辆检测方法的步骤。
53.本技术实施例与现有技术相比存在的有益效果是：本技术实施例可获取目标车辆的检测场景类别；根据所述检测场景类别获取对应的车辆信息；根据所述检测场景类别以及对应的车辆信息，确定待检测电子控制单元的检测顺序；根据所述检测顺序，对所述待检测电子控制单元进行检测。由于可基于检测场景获取对应的车辆信息，再根据检测场景和车辆信息确定待检测电子控制单元的检测顺序，并根据检测顺序对待检测电子控制单元进行检测，可提高对车辆检测的智能性。
附图说明
54.为了更清楚地说明本技术实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
55.图1是本技术实施例一提供的车辆检测方法的流程示意图；
56.图2是本技术实施例二提供的车辆检测方法的流程示意图；
57.图3是本技术实施例三提供的车辆检测方法的流程示意图；
58.图4是本技术实施例四提供的车辆检测方法的流程示意图；
59.图5是本技术实施例五提供的车辆检测装置的结构示意图；
60.图6是本技术实施例六提供的电子设备的结构示意图。
具体实施方式
61.以下描述中，为了说明而不是为了限定，提出了诸如特定系统模块结构、技术之类的具体细节，以便透彻理解本技术实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本技术。在其它情况中，省略对众所周知的系统模块、装置、电路以及方法的详细说明，以免不必要的细节妨碍本技术的描述。
62.本技术实施例提供的车辆检测方法，可以应用于电子设备，所述电子设备可以是车载设备、诊断仪、诊断设备、故障检测设备、手机、平板电脑、笔记本电脑、上网本、个人数字助理(personal digital assistant，pda)等电子设备，所述电子设备与目标车辆进行通
信连接，所述目标车辆为需要进行车辆检测的车辆，本技术实施例对电子设备的具体类型不作任何限制。
63.为了说明本技术所述的技术方案，下面通过具体实施例进行说明。
64.实施例一
65.请参阅图1，示出了本技术实施例提供的车辆检测方法的示意性流程图，所述方法包括：
66.步骤s101，获取目标车辆的检测场景类别。
67.具体地，可预先设置多种检测场景，如多种检测场景包括但不限于保养检测场景类别、故障检测场景类别等。用户可基于预先设置的多种检测场景选择需要检测的检测场景类别，根据用户选择的检测场景类别获取目标车辆当前的检测场景类别，所述目标车辆为需要进行检测的车辆。
68.在一种应用中，如可预先设定每种检测场景类别需要发送的车辆检测请求指令，用户可发送对应车辆检测请求指令，接收到用户发送的车辆检测请求指令时，确定出与用户发送的车辆检测请求指令对应的检测场景类别。
69.步骤s102，根据所述检测场景类别获取对应的车辆信息。
70.具体地，可预先设置不同的检测场景类别需要获取的车辆信息，不同检测场景类别需要获取的车辆信息不同。
71.在一个实施例中，如保养检测场景类别下，预先设置获取的车辆信息为行驶信息及车型信息。所述根据所述检测场景类别获取对应的车辆信息，包括：在确定所述检测场景类别为保养检测场景类别时，获取所述目标车辆的行驶信息及车型信息。
72.在一个实施例中，如故障检测场景类别下，预先设置获取的车辆信息为故障信息及车型信息。所述根据所述检测场景类别获取对应的车辆信息，包括：在确定所述检测场景类别为故障检测场景类别时，获取所述目标车辆的故障信息及车型信息。
73.步骤s103，根据所述检测场景类别以及对应的车辆信息，确定待检测电子控制单元的检测顺序。
74.具体地，预先设置不同检测场景类别下不同特征的车辆信息分别对应需要检测的ecu系统和检测顺序。根据预先设置不同检测场景类别下不同特征的车辆信息分别对应需要检测的ecu系统和检测顺序，确定与当前检测场景类别和当前车辆信息的特征匹配的待检测ecu，以及待检测ecu的检测顺序。由于汽车功能、配置越多后，汽车需要检测的ecu就越多，所花费的时间就越多，导致检测效率低。确定与当前检测场景类别和当前车辆信息的特征匹配的待检测ecu，以及待检测ecu的检测顺序。可根据实际应用需求确定出每种检测场景类别下对应的待检测电子控制单元，只对与当前检测场景类别对应的待检测电子控制单元进行检测，可提高车辆的检测效率。
75.如检测场景类别是保养检测场景类别，获取车辆信息为行驶信息及车型信息。在保养检测场景类别下，预设设置各种车型在不同行驶范围下对应需要检测的ecu以及该需要检测的ecu的检测顺序，可根据保养检测场景类别下对应的行驶信息及车型信息，确定出需要检测的ecu(即待检测电子控制单元)，以及需要检测的ecu的检测顺序。
76.如检测场景类别是故障检测场景类别，获取车辆信息为目标车辆的故障信息及车型信息。在故障检测场景类别下，预先设置各种车型在不同故障信息下对应需要检测的ecu
以及该需要检测的ecu的检测顺序，可根据故障检测场景类别下对应的故障信息及车型信息，确定出需要检测的ecu(即待检测电子控制单元)，以及需要检测的ecu的检测顺序。
77.步骤s104，根据所述检测顺序，对所述待检测电子控制单元进行检测。
78.具体地，根据确定出的待检测ecu的检测顺序，按顺序对待检测ecu进行检测，可在当前检测场景下有需要优先进行检测的ecu优先进行检测，可提高车辆检测的智能性，使得用户体验性高。
79.本技术实施例可基于检测场景获取对应的车辆信息，再根据检测场景和车辆信息确定待检测电子控制单元的检测顺序，并根据检测顺序对待检测电子控制单元进行检测，可提高对车辆检测的智能性。
80.实施例二
81.本实施例是对实施例一的进一步说明，与实施例一相同或相似的地方，具体可参见实施例一的相关描述，此处不再赘述。如图2所示，本实施例中的检测场景类别为保养检测场景类别，步骤s202可作为上述步骤s102的一种实现方式，步骤s203至步骤s204可作为上述步骤s103的一种实现方式，车辆检测方法包括：
82.步骤s201，获取目标车辆的检测场景类别。
83.具体地，如用户基于预先设置的多种检测场景选择保养检测场景类别，获取目标车辆当前的检测场景类别为保养场景类别，所述目标车辆为需要进行检测的车辆。
84.步骤s202，在确定所述检测场景类别为保养检测场景类别时，获取所述目标车辆的行驶信息及车型信息。
85.具体地，所述行驶信息包括里程信息。在确定所述检测场景类别为保养检测场景类别时，获从目标车辆中读取车辆的行驶信息，如可以是从目标车辆中读取车辆的总的里程数据。获取目标车辆对应的车辆识别码，根据车辆识别码确定目标车辆的车型信息。车辆识别码简称vin(vehicleldentificationnumber)，是汽车唯一的身份识别信息，也可以叫做"汽车身份证"，包含如国家、生产厂家、发动机型号、车型、时间年限等汽车的重要信息。如车辆识别码可以是17个字节的车辆识别，根据车辆识别码可确定出车辆的车型。
86.步骤s203，从预设数据库获取与目标车辆同车型且同里程的车辆的各个系统的故障概率。
87.具体地，在确定所述检测场景类别为保养检测场景类别时，获取目标车辆的行驶信息，该行驶信息包括里程信息，在预设数据库中存储不同车型处于不同里程时各个ecu系统的故障概率。根据目标车辆的车型和里程，从数据库中查找与该车型相同，并目标车辆的里程相同里程对应车辆的各个ecu的故障概率。
88.如预先采集多辆车型为2015款宝马，里程数2万公里的车辆，统计该多辆车型每辆车型中各个ecu发生过故障情况，根据多个车辆中各个ecu发生故障情况，确定各个ecu发生故障的概率，将该概率与车型为2015款宝马，里程数2万公里的车辆信息关联存储在数据库中，当目标车辆为2015款宝马，里程数2万公里的车辆，可直接确定目标车辆对应车辆的各个系统的故障概率。
89.在一个实施例中，为了节省空间，无需每个里程都存储，可以是在预设数据库中存储不同车型下处于不同里程范围时各个ecu系统的故障概率。根据目标车辆的车型和里程，从数据库中查找与该车型相同，并目标车辆的里程相同里程对应车辆的各个ecu的故障概
率。此处与目标车辆的里程相同里程的车辆可以是目标车辆里程在对应的里程范围内的车辆。
90.如预先收集多辆车型为2015款宝马，里程数为1.8到2万公里这个范围的车辆，统计该多个车辆每辆车型中各个ecu发生过故障情况，根据多个车辆中各个ecu发生故障情况，确定各个ecu发生故障的概率，将该概率与车型为2015款宝马，里程数为1.8到2万公里这个范围的车辆关联存储在数据库中，当目标车辆为2015款宝马，里程数1.9万公里的车辆，1.9万公里在1.8到2万公里这个范围内，从预设数据库获取与目标车辆同车型且同里程的车辆的各个系统的故障概率可以是：获取车型为宝马，里程数为1.8到2万公里这个范围的车辆对应的ecu系统的故障概率。
91.在一个实施例中，可在车辆平时保养过程中采集不同车型的处于不同里程时各个ecu系统的故障情况，根据新采集的数据定期更新不同车型下处于不同里程范围时各个ecu系统的故障概率。
92.步骤s204，根据各个系统的故障概率的高低确定目标车辆的待检测电子控制单元的检测顺序。
93.具体地，根据各个系统的故障概率的高低确定需要检测的euc的检测顺序，若出现多个ecu故障概率相同的情况，则按照默认的顺序进行检测。比如，轮胎euc系统及车灯ecu系统异常的故障概率相同，则轮胎异常及车灯异常的检测顺序按照默认的轮胎系统
‑
电控系统进行检测。
94.具体地，预先可存储各个车型中不同行驶信息下需要检测的ecu的检测顺序数据。当检测场景类别为保养检测场景类别，根据当前车辆的车型信息以及行驶信息确定对应当前需要检测ecu的检测顺序数据，当前需要检测的ecu即为待检测电子控制单元。
95.步骤s205，根据所述检测顺序，对所述待检测电子控制单元进行检测。
96.具体地，根据确定出的待检测ecu的检测顺序，按顺序对待检测ecu进行检测，可将在保养检测场景类别下，根据目标车辆的行驶信息及车型信息，确定需要优先进行检测的ecu优先进行检测，可提高车辆检测的智能性。
97.在一种应用场景中，车辆a行驶到2万公里，例行进行保养，维修师在汽车故障检测设备选择汽车保养场景，此时获取汽车的车辆信息，该车辆信息包括汽车的当前里程数信息2万公里，根据当前的车型信息2015款宝马、里程数信息2万公里在数据库中查找对应待检测电子控制单元的检测顺序，待检测电子控制单元的检测顺序可基于当前里程数的众多同款汽车类型保养的数据得到。如车型为2015款宝马，里程数2万公里的轮胎故障率最高或轮胎故障次数最多，则轮胎系统为待检测电子控制单元的第一个待检测的系统，根据待检测电子控制单元的检测顺序，对车辆进行检测保养。如未获取到对应待检测电子控制单元的检测顺序，则根据预设默认的待检测电子控制单元的检测顺序进行检测。
98.在保养检测场景类别下，可根据各个系统的故障概率的高低确定目标车辆的待检测电子控制单元的检测顺序，将故障概率高的ecu系统优先进行检测，可提高车辆检测的智能性。
99.实施例三
100.本实施例是对实施例一的进一步说明，与实施例一相同或相似的地方，具体可参见实施例一的相关描述，此处不再赘述。如图3所示，本实施例中的检测场景类别为保养检
测场景类别，步骤s302可作为上述步骤s102的一种实现方式，步骤s303至步骤s304可作为上述步骤s103的一种实现方式，车辆检测方法包括：
101.步骤s301，获取目标车辆的检测场景类别。
102.具体地，如用户基于预先设置的多种检测场景选择保养检测场景类别，获取目标车辆当前的检测场景类别为保养场景类别，所述目标车辆为需要进行检测的车辆。
103.步骤s302，在确定所述检测场景类别为保养检测场景类别时，获取所述目标车辆的行驶信息及车型信息。
104.具体地，所述行驶信息包括里程信息。在确定所述检测场景类别为保养检测场景类别时，获从目标车辆中读取车辆的行驶信息，如可以是从目标车辆中读取车辆的总的里程数据。获取目标车辆对应的车辆识别码，根据车辆识别码确定目标车辆的车型信息。vin码是汽车唯一的身份识别信息，也可以叫做"汽车身份证"，包含如国家、生产厂家、发动机型号、车型、时间年限等汽车的重要信息。如车辆识别码可以是17个字节的车辆识别，根据车辆识别码可确定出车辆的车型。
105.步骤s303，从预设数据库获取与目标车辆同车型且同里程的车辆的各个系统的保养频率。
106.具体地，在确定所述检测场景类别为保养检测场景类别时，获取目标车辆的行驶信息，该行驶信息包括里程信息，在预设数据库中存储不同车型处于不同里程时各个ecu系统的保养概率。根据目标车辆的车型和里程，从数据库中查找与该车型相同，并与目标车辆同里程对应车辆的各个ecu的保养概率。
107.如预先收集多辆车型为2015款宝马，里程数2万公里的车辆，统计该多个车型每辆车型中各个ecu保养情况，根据多2015款车辆中各个ecu保养情况，确定各个ecu平均保养频率，即平均多久保养一次，将该保养频率与车型为2015款宝马，里程数2万公里的车辆信息关联存储在数据库中，当目标车辆为2015款宝马，里程数2万公里的车辆，可直接确定目标车辆对应车辆的各个系统的保养频率。
108.在一个实施例中，为了节省空间，无需每个里程都存储，可以是在预设数据库中存储不同车型下处于不同里程范围时各个ecu系统的保养频率。根据目标车辆的车型和里程，从数据库中查找与该车型相同，并目标车辆同里程对应车辆的各个ecu的保养频率。此处与目标车辆同里程的车辆可以是目标车辆里程在对应的里程范围内的车辆。
109.如预先收集多辆车型为宝马，里程数为1.8到2万公里这个范围的车辆，统计该多个车辆每辆车中各个ecu系统发生过保养情况，根据多个车辆中各个ecu系统发生保养情况确定，确定各个ecu系统平均保养频率，即多久保养一次，将该保养频率与车型为2015款宝马，里程数为1.8到2万公里这个范围的车辆关联存储在数据库中，当目标车辆为2015款宝马，里程数1.9万公里的车辆，1.9万公里在1.8到2万公里这个范围内，从预设数据库获取与目标车辆同车型且同里程的车辆的各个系统的保养频率可以是：获取车型为2015款宝马，里程数为1.8到2万公里这个范围的车辆对应的ecu的保养频率。
110.在一个实施例中，可在车辆平时保养过程中采集不同车型的处于不同里程时各个ecu系统的保养数据，根据新采集的数据定期更新不同车型下处于不同里程范围时各个ecu系统的保养频率。
111.步骤s304，根据各个系统的保养频率的高低确定目标车辆的待检测电子控制单元
的检测顺序。
112.具体地，根据各个ecu系统的保养频率的高低确定需要检测的euc的检测顺序，若出现多个ecu保养频率相同的情况，则按照默认的顺序进行检测。比如，轮胎euc系统及车灯ecu系统的保养频率相同，则轮胎异常及车灯异常的检测顺序按照默认的轮胎系统
‑
电控系统进行检测。
113.步骤s305，根据所述检测顺序，对所述待检测电子控制单元进行检测。
114.具体地，根据确定出的待检测ecu的检测顺序，按顺序对待检测ecu进行检测，可将在保养检测场景类别下，根据目标车辆的行驶信息及车型信息，确定需要优先检测的ecu优先进行检测，可提高车辆检测的智能性。
115.在一种应用场景中，车辆a行驶到2万公里，例行进行保养，维修师在汽车故障检测设备选择汽车保养场景，此时获取汽车的车辆信息，该车辆信息包括汽车的当前里程数信息2万公里，根据当前的车型信息2015款宝马、里程数信息2万公里在数据库中查找对应待检测电子控制单元的检测顺序，待检测电子控制单元的检测顺序可基于当前里程数的众多同款汽车类型保养的数据得到。如车型为2015款宝马，里程数2万公里的轮胎保养率最高或轮胎保养次数最多，则轮胎系统为待检测电子控制单元的第一个待检测的系统，根据待检测电子控制单元的检测顺序，对车辆进行检测保养。如未获取到对应待检测电子控制单元的检测顺序，则根据预设默认的待检测电子控制单元的检测顺序进行检测。
116.在保养检测场景类别下，可根据各个系统的保养频率的高低确定目标车辆的待检测电子控制单元的检测顺序，将保养频率高的优先进行检测的ecu优先进行检测，可提高车辆检测的智能性。
117.实施例四
118.本实施例是对实施例一的进一步说明，与实施例一相同或相似的地方，具体可参见实施例一的相关描述，此处不再赘述。如图4所示，本实施例中的检测场景类别为故障检测场景类别，步骤s402可作为上述步骤s102的一种实现方式，步骤s403至步骤s405可作为上述步骤s103的一种实现方式，车辆检测方法包括：
119.步骤s401，获取目标车辆的检测场景类别。
120.具体地，如用户基于预先设置的多种检测场景选择故障检测场景类别，获取目标车辆当前的检测场景类别为故障检测场景类别，所述目标车辆为需要进行检测的车辆。
121.步骤s402，在确定所述检测场景类别为故障检测场景类别时，获取所述目标车辆的故障信息及车型信息。
122.具体地，在确定所述检测场景类别为故障检测场景类别时，则对目标车辆进行故障检测从而获取故障信息。获取目标车辆对应的车辆识别码，根据车辆识别码确定目标车辆的车型信息。vin码是汽车唯一的身份识别信息，也可以叫做"汽车身份证"，包含如国家、生产厂家、发动机型号、车型、时间年限等汽车的重要信息。如车辆识别码可以是17个字节的车辆识别，根据车辆识别码可确定出车辆的车型。
123.步骤s403，从预设数据库获取与目标车辆同车型的车辆的维修记录。
124.具体地，在确定所述检测场景类别为故障检测场景类别时，获取目标车辆当前的故障信息，如故障信息可以是仪表异常，轮胎异常等故障信息，在预设数据库中存储不同车型下处于不同故障信息时各个ecu系统的维修记录。根据目标车辆的车型和故障信息，从数
据库中查找与目标车辆车型相同，并与目标车辆的故障信息相同故障对应车辆的各个ecu的维修记录。
125.步骤s404，根据所述维修记录查询所述故障信息对应的故障系统名单。
126.具体地，从数据库中查找与目标车辆车型相同，并与目标车辆的故障信息相同故障对应车辆的各个ecu的维修记录，根据所述维修记录查询所述故障信息对应的故障系统名单。
127.步骤s405，根据所述故障系统名单确定目标车辆的待检测电子控制单元的检测顺序。
128.具体地，根据所述故障系统名单确定需要检测的ecu，并根据各个故障系统的故障次数或故障概率确定需要检测ecu的检测顺序。
129.如目标车辆的故障信息是启动异常，与目标车辆车型相同的多个车辆中的维修记录检测到启动异常对应的故障系统名单包括发动机ecu系统、点火ecu系统，查询多个维修记录中发动机ecu系统和点火ecu系统维修次数。从而可根据所述故障系统名单确定需要检测的ecu为发动机ecu系统和点火ecu系统，并根据各个故障系统的故障次数或故障概率确定发动机ecu系统和点火ecu系统的检测顺序，此处仅是便于理解进行举例说明，并不作为对本技术的限定。
130.在一个实施例中，所述根据所述维修记录查询所述故障信息对应的故障系统名单之后，还包括：获取所述故障系统名单中各个系统对应所述故障信息的故障概率；对应地，所述根据所述故障系统名单确定目标车辆的待检测电子控制单元的检测顺序，包括：根据所述故障系统名单中各个系统对应所述故障信息的故障概率，确定目标车辆的待检测电子控制单元的检测顺序。
131.具体地，可获取故障系统名单中由于各个系统产生对应故障信息的故障概率，如故障信息是启动异常，发动机ecu系统产生该启动异常的故障概率，或者点火ecu系统产生该启动异常的故障概率。根据各个系统的故障概率的高低确定待检测euc的检测顺序，若出现多个ecu故障概率相同的情况，则按照默认的顺序进行检测。
132.步骤s406，根据所述检测顺序，对所述待检测电子控制单元进行检测。
133.具体地，根据确定出的待检测ecu的检测顺序，按顺序对待检测ecu进行检测，可将在故障检测场景类别下，根据目标车辆的行驶信息及车型信息，确定需要优先进行检测的ecu优先进行检测，可提高车辆检测的智能性。
134.在一种应用场景中，车辆b进行故障检测，维修师在汽车故障检测设备选择故障检测场景，此时获取汽车的故障信息，如该故障信息包括汽车仪表显示的异常信息，如轮胎标识亮起(此时说明是轮胎有故障)，根据当前车型信息2015年款宝马及异常标识信息在预设数据库中查找众多同款车型轮胎灯异常车辆的维修记录中查找对应的系统故障，比如100款2015款宝马车轮胎灯异常，其中60台车都指向的轮胎系统异常问题，则轮胎系统为待检测电子控制单元的第一个待检测的系统，根据待检测电子控制单元的检测顺序，对车辆进行故障检测。
135.在故障检测场景类别下，可从预设数据库获取与目标车辆同车型的车辆的维修记录；根据所述维修记录查询所述故障信息对应的故障系统名单；根据所述故障系统名单确定目标车辆的待检测电子控制单元的检测顺序，根据故障系统名单确定进行检测，可更符
合用户实际需求，从而提高车辆检测的智能性。
136.实施例五
137.对应于上文实施例所述的车辆检测方法，图5示出了本技术实施例提供的车辆检测装置的结构框图，为了便于说明，仅示出了与本技术实施例相关的部分。所述车辆检测装置应用于电子设备，所述电子设备与目标车辆进行通信连接，所述车辆检测装置500包括：
138.场景获取模块501，用于获取目标车辆的检测场景类别；
139.车辆信息获取模块502，用于根据所述检测场景类别获取对应的车辆信息；
140.检测顺序确定模块503，用于根据所述检测场景类别以及对应的车辆信息，确定待检测电子控制单元的检测顺序；
141.检测模块504，用于根据所述检测顺序，对所述待检测电子控制单元进行检测。
142.在一个实施例中，车辆信息获取模块包括：
143.第一车辆信息获取单元，用于在确定所述检测场景类别为保养检测场景类别时，获取所述目标车辆的行驶信息及车型信息。
144.在一个实施例中，所述行驶信息包括里程信息；所述检测顺序确定模块包括：
145.第一获取单元，用于从预设数据库获取与目标车辆同车型且同里程的车辆的各个系统的故障概率；
146.第一检测顺序确定单元，用于根据各个系统的故障概率的高低确定目标车辆的待检测电子控制单元的检测顺序。
147.在一个实施例中，所述行驶信息包括里程信息；所述检测顺序确定模块包括：
148.第二获取单元，用于从预设数据库获取与目标车辆同车型且同里程的车辆的各个系统的保养频率；
149.第二检测顺序确定单元，用于根据各个系统的保养频率的高低确定目标车辆的待检测电子控制单元的检测顺序。
150.在一个实施例中，车辆信息获取模块还包括：
151.第二车辆信息获取单元，用于在确定所述检测场景类别为故障检测场景类别时，获取所述目标车辆的故障信息及车型信息。
152.在一个实施例中，所述检测顺序确定模块包括：
153.第三获取单元，用于从预设数据库获取与目标车辆同车型的车辆的维修记录；
154.查询单元，用于根据所述维修记录查询所述故障信息对应的故障系统名单；
155.第三检测顺序确定单元，用于根据所述故障系统名单确定目标车辆的待检测电子控制单元的检测顺序。
156.在一个实施例中，检测顺序确定模块还包括：
157.第四获取单元，用于获取所述故障系统名单中各个系统对应所述故障信息的故障概率；
158.对应地，所述第三检测顺序确定单元具体用于：根据所述故障系统名单中各个系统对应所述故障信息的故障概率，确定目标车辆的待检测电子控制单元的检测顺序。
159.本技术实施例由于可基于检测场景获取对应的车辆信息，再根据检测场景和车辆信息确定待检测电子控制单元的检测顺序，并根据检测顺序对待检测电子控制单元进行检测，可提高对车辆检测的智能性。
160.实施例五
161.如图6所示，是本技术实施例提供的电子设备的结构示意图。所述电子设备600包括：处理器601、存储器602以及存储在上述存储器602中并可在上述处理器601上运行的计算机程序603。上述处理器601执行上述计算机程序603时实现上述车辆检测方法实施例中的步骤。
162.示例性的，上述计算机程序603可以被分割成一个或多个单元/模块，上述一个或者多个单元/模块被存储在上述存储器602中，并由上述处理器601执行，以完成本技术。上述一个或多个单元/模块可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述上述计算机程序603在上述电子设备600中的执行过程。例如，上述计算机程序603可以被分割成场景获取模块、车辆信息获取模块、检测顺序确定模块和检测模块等，各模块具体功能在上述实施例中已有描述，此处不再赘述。
163.上述电子设备600可包括，但不仅限于，处理器601、存储器602。本领域技术人员可以理解，图6仅仅是电子设备600的示例，并不构成对电子设备600的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如上述电子设备600还可以包括输入输出设备、网络接入设备、总线等。
164.所称处理器601可以是中央处理单元(central processing unit，cpu)，还可以是其它通用处理器、数字信号处理器(digital signal processor，dsp)、专用集成电路(application specific integrated circuit，asic)、现成可编程门阵列(field
‑
programmable gate array，fpga)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
165.上述存储器602可以是电子设备600的内部存储单元，例如电子设备600的硬盘或内存。上述存储器602还可以既包括上述电子设备600的内部存储单元也包括外部存储设备。上述存储器602用于存储上述计算机程序以及上述电子设备600所需的其它程序和数据。上述存储器602还可以用于暂时地存储已经输出或者将要输出的数据。
166.所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将上述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本技术的保护范围。上述维修案例生成设备中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
167.在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。
168.本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员
可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本技术的范围。
169.在本技术所提供的实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，上述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统模块，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装置或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。
170.上述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本技术实施例方案的目的。
171.另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
172.上述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，上述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，上述计算机程序包括计算机程序代码，上述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。上述计算机可读介质可以包括：能够携带上述计算机程序代码的任何实体或装置、记录介质、u盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(rom，read
‑
only memory)、随机存取存储器(ram，random access memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，上述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括是电载波信号和电信信号。以上所述实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本技术各实施例技术方案的精神和范围，均应包含在本技术的保护范围之内。