CN110989555A

CN110989555A - 车辆诊断报警的方法、装置及系统

Info

Publication number: CN110989555A
Application number: CN201911246710.1A
Authority: CN
Inventors: 刘均; 樊球
Original assignee: Shenzhen Launch Technology Co Ltd
Current assignee: Shenzhen Launch Technology Co Ltd
Priority date: 2019-12-06
Filing date: 2019-12-06
Publication date: 2020-04-10

Abstract

本申请实施例提供了一种车辆诊断报警方法、装置及系统，该方法包括：诊断设备接收服务器发送的目标诊断数据ODX文件，该目标ODX文件包含第一标准范围，该第一标准范围用于描述所述第一车辆中目标模块的参数值的安全范围；所述诊断设备获取所述第一车辆运行过程中产生的第一参数值，该第一参数值用于描述所述第一车辆的所述目标模块的运行状态；若所述第一参数值未落入所述第一标准范围，则所述诊断设备输出预警信息，该预警信息表征所述第一车辆的所述目标模块的运行状态异常。采用本申请实施例，能够提高车型预警的准确性和时效性，便于用户及时发现车辆运行异常、解决车辆故障。

Description

车辆诊断报警的方法、装置及系统

技术领域

本申请涉及车辆电子技术领域，尤其涉及一种车辆诊断报警的方法、装置及系统。

背景技术

随着车辆电子技术的发展，车辆的结构越来越复杂，一辆车辆可以包含的电子控制单元(Electronic Control Unit，ECU)随之增多，如发动机管理系统(EngineManagement System，EMS)、网关(GateWay，GW)和自动变速箱控制单元(TransmissionControl Unit，TCU)等。由于ECU管理的传感器和执行器数量不断增长，使得车辆交互数据不断增多，使得车辆的运行状况越来越复杂，无形中提升了排查车辆故障的工作难度。

对于日渐复杂的车辆数据，可以采用监测车辆的传感器参数值的方法了解车辆的运行状况，例如，诊断设备将实时采集到的参数值与设置的范围值进行比较来判断车辆的运行状况是否正常。其中使用的范围值是由诊断设备中预先设置的范围值，或者通过样本采集得到的范围值，使得预警结果不精确，不能精确地预警车辆的运行异常。

发明内容

本申请实施例公开了一种车辆诊断报警的方法、装置及系统，能够提高车辆诊断报警结果的准确性和时效性，便于用户及时发现车辆运行异常、解决车辆故障。

第一方面，本申请实施例提供了一种车辆诊断报警方法，包括：

诊断设备接收服务器发送的目标诊断数据ODX文件，该目标ODX文件包含第一标准范围，该第一标准范围用于描述第一车辆中目标模块的参数值的安全范围；

诊断设备获取第一车辆运行过程中产生的第一参数值，该第一参数值用于描述第一车辆的目标模块的运行状态；

若第一参数值未落入第一标准范围，则诊断设备输出预警信息，该预警信息表征第一车辆的目标模块的运行状态异常。

车辆中的参数值可以反应车辆传感器和执行器的运行状态，对参数值进行检测，可以及时预警车辆的运行异常。当前的诊断设备在预警过程中，预先设置的范围值，或者通过样本采集得到的范围值进行预警，影响预警结果的准确性。本申请实施例中，服务器向诊断设备发送带有标准参数范围的ODX文件，诊断设备使用标准参数范围值对车辆参数值进行监测，在参数值异常时输出预警信息，提高了车辆诊断报警结果的准确性和时效性，便于用户及时发现车辆运行异常、解决车辆故障。并且通过服务器获取标准范围的方式，使得在车辆生产商更新标准范围值后，诊断设备的获取的范围值也会相应更新，提高了车辆诊断报警结果的稳定性。

在第一方面的一种可能的实施方式中，上述诊断设备接收服务器发送的目标诊断数据ODX文件之前，还包括：

诊断设备向服务器发送第一车辆的车型信息；其中，服务器上存储有多个车型信息与多个ODX文件的对应关系，目标ODX文件为第一车辆的车型信息对应的ODX文件。

服务器中存储有多个车型信息与多个ODX文件之间的对应关系，因此诊断设备可以向服务器发送车型信息，服务器车型信息后，可以查找到该车型信息对应的ODX文件，发送给诊断设备。可以看出，通过该诊断设备，即可预警多个车型的车辆的参数值，节省了购买专用设备的成本。

在第一方面的又一种可能的实施方式中，在诊断设备根据第一车辆的车型信息获取第一车辆的标准文件之前，还包括：

诊断设备接收第一操作，该第一操作指示向第一车辆发送多个第一命令，上述多个第一命令分别支持不同的通信协议，上述多个第一命令中每个第一命令均用于请求读取第一车辆的车辆识别号码VIN码；

诊断设备向第一车辆发送多个第一命令；

诊断设备接收第一车辆发送的VIN码；

诊断设备根据VIN码得到第一车辆的车型信息。

在上述方法中，诊断设备内预先存储支持多种通信协议的命令，通过向车辆发送多个请求读取车辆识别号码的命令来获取车辆的车辆识别号码，上述多个读取车辆识别号码的命令分别支撑不同的通讯协议。因此，不管车辆采用何种通讯协议，都可以接收到请求读取车辆识别号码的指令，并向诊断设备发送的身份标志。

在第一方面的又一种可能的实施方式中，该ODX文件还包含第一解析算法；上述诊断设备获取第一车辆运行过程中产生的第一参数值，包括：

诊断设备向第一车辆发送请求读取第一参数值的命令；

诊断设备接收第一车辆发送的第二命令，上述第二命令中编译有第一参数值；

诊断设备根据第一解析算法解析第二命令，得到第一参数值。

可以看出，ODX文件中还可以包括车辆的标准解析算法，通过标准解析算法可以快速的定位解析车辆发送的命令应当使用何种算法解析，而不用重新查找解析算法，提高了解析车辆回复命令的效率。

在第一方面的又一种可能的实施方式中，诊断设备获取第一车辆运行过程中产生的第一参数值，还包括：

诊断设备接收输入的第二操作，第二操作用于指示向第一车辆发送请求读取第一参数值的命令。

可以看出，上述读取车辆参数的命令可以由用户的操作来进行控制，提升了诊断设备的交互性。

在第一方面的一种可能的实施方式中，诊断设备获取第一车辆运行过程中产生的第一参数值之后，还包括：

诊断设备记录第一参数值的获取时间，该获取时间为诊断设备获取第一参数值的时间；

诊断设备向服务器发送第一参数值和获取时间，该第一参数值和获取时间用于服务器输出第一车辆的数据报表。

可以看出，诊断设备获取车辆的参数值后，可以将参数值和获取时间发送给服务器。相应的，服务器可以收集参数值和获取时间，并输出数据报表，在需要对车辆的历史运行状况进行查看时，用户可以通过服务器查看数据报表，了解车辆之前的运行状况和预警车辆，便于用户针对性的查找车辆可能出现的问题。

在第一方面的一种可能的实施方式中，该第一标准范围包括最大值和最小值；若第一参数值未落入第一标准范围，则诊断设备输出预警信息，包括：

若第一参数值与最大值或最小值的差值小于预设第一阈值，则诊断设备输出第一预警信息；

若第一参数值与最大值或最小值的差值等于或大于预设第一阈值，则诊断设备输出第二预警信息。

当前设备在进行预警时，对于超出范围值的参数值的预测信息没有做出等级区分，使得严重影响驾驶的参数值不能及时被发现。在本申请实施例中，对于超出范围的不同程度的参数值分为不同的预警等级，在检测到超过不同预设阈值的参数值时，能产生不同的预警消息，便于用户及时发现严重影响安全的参数值，及时解决车辆安全隐患，提高车辆安全性。

第二方面，本申请实施例提供了一种车辆诊断报警方法，该方法包括：

服务器接收诊断设备发送的第一车辆的车型信息；

服务器确定第一车辆的车型信息对应的目标诊断数据ODX文件，其中，该服务器中存储有多个车型信息与多个ODX文件的对应关系，该目标ODX文件中包含第一标准范围，该第一标准范围用于描述第一车辆中目标模块的参数值的安全范围；

服务器向诊断设备发送目标ODX文件，该目标ODX文件用于诊断设备输出预警信息，该预警信息表征第一车辆的目标模块的运行状态异常。

在第二方面的一种可能的实现方式中，该服务器向诊断设备发送目标ODX文件之后，还包括：

服务器接收诊断设备发送的第一参数值和获取时间；第一参数值用于描述第一车辆的目标模块的运行状态，该获取时间为诊断设备获取第一参数值的时间；

服务器输出第一车辆数据报表，该数据报表中包含第一参数值和获取时间。

第三方面，本申请实施例提供了一种车辆诊断报警装置，该装置包括：

接收单元，用于接收服务器发送的目标诊断数据ODX文件，该目标ODX文件包含第一标准范围，该第一标准范围用于描述第一车辆中目标模块的参数值的安全范围；

获取单元，用于获取第一车辆运行过程中产生的第一参数值，该第一参数值用于描述第一车辆的目标模块的运行状态；

输出单元，用于若第一参数值未落入第一标准范围，则诊断设备输出预警信息，该预警信息表征第一车辆的目标模块的运行状态异常。

在第三方面的一种可能的实施方式中，该装置还包括：

发送单元，用于向服务器发送第一车辆的车型信息；其中，该服务器上存储有多个车型信息与多个ODX文件的对应关系，该目标ODX文件为第一车辆的车型信息对应的ODX文件。

在第三方面的又一种可能的实施方式中，该装置还包括：

输入单元，用于接收输入的第一操作，该第一操作指示向第一车辆发送多个第一命令，该多个第一命令分别支持不同的通信协议，该多个第一命令中每个第一命令均用于请求读取第一车辆的车辆识别号码VIN码；

发送单元，用于向第一车辆发送多个第一命令；

该接收单元，用于接收第一车辆发送的VIN码；

识别单元，用于根据VIN码得到第一车辆的车型信息。

在第三方面的又一种可能的实施方式中，该ODX文件还包含第一解析算法；获取单元，用于获取第一车辆运行过程中产生的第一参数值，具体为：

向第一车辆发送请求读取第一参数值的命令；

接收第一车辆发送的第二命令，该第二命令中编译有第一参数值；

根据第一解析算法解析第二命令，得到第一参数值。

在第三方面的又一种可能的实施方式中，该装置还包括：

输入单元，用于接收输入的第二操作，该第二操作用于指示向第一车辆发送请求读取第一参数值的命令。

在第三方面的又一种可能的实施方式中，该获取单元，还用于记录第一参数值的获取时间，该获取时间为诊断设备获取第一参数值的时间；

上述装置还包括：

发送单元，用于向服务器发送第一参数值和获取时间，该第一参数值和获取时间用于服务器输出第一车辆的数据报表。

在第三方面的又一种可能的实施方式中，该第一标准范围包括最大值和最小值；输出单元，用于若第一参数值未落入第一标准范围，则诊断设备输出预警信息，具体为：

若第一参数值与最大值或最小值的差值小于预设第一阈值，则输出第一预警信息；

若第一参数值与最大值或最小值的差值等于或大于预设第一阈值，则输出第二预警信息。

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

接收单元，用于接收诊断设备发送的第一车辆的车型信息；

确定单元，用于确定第一车辆的车型信息对应的目标诊断数据ODX文件，其中，该服务器中存储有多个车型信息与多个ODX文件的对应关系，该目标ODX文件中包含第一标准范围，该第一标准范围用于描述第一车辆中目标模块的参数值的安全范围；

发送单元，用于向诊断设备发送目标ODX文件，该目标ODX文件用于诊断设备输出预警信息，该预警信息表征第一车辆的目标模块的运行状态异常。

在第四方面的一种可能的实施方式中，该接收单元，还用于接收诊断设备发送的第一参数值和获取时间；第一参数值用于描述第一车辆的目标模块的运行状态，该获取时间为诊断设备获取第一参数值的时间；

上述服务器还包括输出单元，用于输出第一车辆数据报表，该数据报表中包含第一参数值和获取时间。

第五方面，本申请实施例提供一种车辆诊断报警装置，包括：处理器、存储器以及通信接口；该处理器与存储器、通信接口相连，该存储器中存储有计算机程序，该处理器用于调用该计算机程序，以执行本申请实施例第一方面或第一方面的任意一种实现方式提供的方法。

第六方面，本申请实施例提供一种服务器，包括：处理器、存储器以及通信接口；该处理器与存储器、通信接口相连，该存储器中存储有计算机程序，该处理器用于调用该计算机程序，以执行本申请实施例第二方面或第二方面的任意一种实现方式提供的方法。

第七方面，本申请实施例提供一种车辆诊断报警系统，该系统包括诊断设备和服务器，其中：上述诊断设备为第一方面，或者第一方面的任意一种可能的实施方式所描述的服务器；上述服务器为第二方面或者第二方面的任意一种可能的实施方式所描述的服务器。

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

第九方面，本申请实施例提供了一种计算机程序产品，该计算机程序产品包括：计算机可读存储介质，其随之包含计算机可读程序代码，该计算机可读程序代码在由一个或多个处理器运行，用于执行本申请实施例第一方面或第一方面的任意一种实现方式提供的方法。

可以理解地，上述提供的第三方面提供的车辆诊断报警装置、第五方面提供的车辆诊断报警装置、第七方面的提供的车辆诊断报警系统、第八方面提供的计算机可读存储介质，以及第九方面提供的计算机程序产品均用于执行第一方面所提供的车辆诊断报警方法，因此，其所能达到的有益效果可参考第一方面所提供的车辆诊断报警方法中的有益效果。上述第四方面提供的服务器，第六方面提供的服务器均用于执行第二方面提供的车辆诊断报警方法，因此，其所能达到的有益效果可参考第二方面所提供的车辆诊断报警方法中的有益效果。此处不再赘述。

附图说明

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

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

图2是本申请实施例提供的一种车辆的接口的结构示意图；

图3是本申请实施例提供的一种车辆诊断报警方法的流程图；

图4是本申请实施例提供的一种ODX文件的应用场景图；

图5是本申请实施例提供的一种请求ODX文件的场景示意图；

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

图7是本申请实施例提供的一种获取第一参数值的方法的示意图；

图8是本申请实施例提供的一种获取车辆的车型信息的方法的示意图；

图9是本申请实施例提供的一种输出预警信息的方法的示意图；

图10是本申请实施例提供的一种车辆诊断报警装置的结构示意图；

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

图12是本申请实施例提供的一种诊断设备的结构示意图；

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

具体实施方式

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

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

如图1所示，车辆诊断报警系统可以包括车辆101、车载装置102、诊断设备103和服务器104。诊断设备103可以通过车载装置102与车辆101建立数据连接关系，从而获取车辆101的车型信息和参数值。并且，诊断设备103可以和服务器104建立数据连接关系，将车辆101的车辆信息和参数值发送给服务器104。

车辆101可以包括车辆总线以及通过车辆总线相连的接口105和节点106的集群。具体实施过程中，车辆可以是货车、公交车、面包车、电动车辆等不同型号的车辆。车辆总线是将接口105和节点106的集群连接起来的传输介质，车辆总线可以是局域互联网络(localinterconnect network，LIN)总线、控制器局域网络(controller area network，CAN)总线、SAE-J1850总线、ISO9141-2总线或ISO14230-4总线。

车辆的接口105可以是车载诊断接口(on-Board diagnostics，ODB)、通用串行总线(universal serial bus，USB)等。其中OBD接口可以理解成为车辆故障诊断而延伸出来的一种检测接口，OBD经过发展包括OBD和比OBD更为先进的Ⅱ型车载诊断系统(on BoardDiagnosticsⅡ，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号引脚表示电源正极。

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

作为一种可能的实施例，在CAN总线系统中，多个ECU同时控制多个工作装置或系统，各个ECU的共用信息通过CAN总线互相传递。例如但不限于，CAN总线上各个ECU的通信可以通过组标准CANBUS协议的数据帧实现。为了方便说明，本申请实施例以接口为OBD接口，节点集群中的任意一个节点为ECU来进行说明。

车载装置102也可以称为诊断接头。例如但不限于，Ross-Tech公司的HEX-NET无线诊断接头和HEX-V2第二代诊断接头、博世公司的BOSCHEDC7UC31诊断接头和元征公司的DBSCar5诊断接头。预警装置102可以插到车辆101的OBD接口上。车载装置102通过接口连接车辆101的CAN总线，并和CAN总线相连的任意一个ECU建立数据连接关系。

作为一种可选的实施方式，车辆101可以通过图2所示的OBDⅡ接口的第16号引脚为车载装置102供电，并将第6号引脚和第14号引脚作为通讯管脚。

诊断设备103可以是手机、平板电脑、笔记本电脑、掌上电脑等具有显示面板的设备。诊断设备103可以通过有线(例如但不限于，同轴电缆、光纤和数字用户线等)或无线(例如但不限于，蓝牙、无限局域网和移动设备网络等)方式连接车载装置102或服务器104。

服务器104中配置有基于诊断的数据交互方案(open diagnostic dataexchange，ODX)的多种诊断数据。ODX是一种开放式的数据交互方案，具有开源和标准化的属性，因此ODX格式的数据常用于整车生命周期中诊断数据的交互，通过ODX格式进行开发的诊断数据文档可以成为ODX文档。本申请实施例中提到的ODX文件即基于ODX开发的文档。ODX作为一种新型技术，用于制作车辆诊断所需的诊断数据文件，已经得到越来越多的应用，主机厂开发人员根据车型诊断需求开发诊断数据文件，客户端通过网络下载升级，解析ODX文件，进行车辆诊断。在实际使用中，ODX文件往往被包裹在数据交互索引文件(productdata exchange，PDX)文件中进行下载，PDX文件是由Adobe公司推出一种索引文件，用于创建和查看文档。PDX文件中包含文档内容和目录索引，类似于一个压缩包，为了方便描述，本申请中将涉及的PDX文件称为PDX文件包。PDX文件包可以包括ODX文件和其他一些附属的文件(如日志文件、密钥文件等)，客户端可通过解析PDX文件包获取车辆诊断所需要的ODX文件。

作为一种可选的实施方式，诊断设备103可以通过无线方式(如蓝牙)连接车载装置102。用户对诊断设备103进行操作时，诊断设备103可以发送按照厂家自定义或遵循D-PDU标准的请求命令给车载装置102。车载装置102将诊断设备103发送的请求命令转发给车辆101中的ECU。相应的，车辆101的ECU接收到请求命令后，根据请求内容返回相应的响应命令给车载装置102，车载装置102转发送给诊断设备103，从而完成了一次诊断设备103和ECU的数据交互，诊断设备103将收到的响应数据进行解析，得到ECU所管理的传感器或者执行器的状态值，对超出标准范围的参数值进行预警。

可选的，在发送请求命令时，可以通过转码模块将命令转换为车辆总线所支持的协议的数据帧，例如将请求命令转换未CAN协议的数据帧(如组标准CANBUS协议的数据帧)，并把转换后的CAN协议的数据帧发送给车辆101，相应的，上述转码模块也可以将数据帧转为返回命令。上述转码模块可以集成在诊断设备中，也可以集成在车载装置中，用于进行命令和数据帧的转码。

可选的，车载装置102与车辆进行连接的功能也可以诊断设备103来实现。例如，车载装置102可以集成在诊断设备102中，成为一个用于车辆诊断报警的设备。为了方便说明，本申请实施例的后文中，将图1中的诊断设备103和车载装置102统称为诊断设备来进行后续的说明。其中，诊断设备103可以通过有线(例如但不限于同轴电缆、光纤和数字用户线DSL等)或无线(例如但不限于，蓝牙、WIFI和移动设备网络等)方式和车辆101建立数据连接关系。

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

S301：服务器向诊断设备发送目标ODX文件。

具体的，服务器中预先存储有多个ODX文件，可以通过有线(例如同轴电缆、光纤和数字用户线DSL等)或无线(例如蓝牙、WIFI和移动设备网络等)方式向诊断设备发送。

ODX是一种可扩展标记语言(extensible markup language，XML)数据格式，用以描述车辆诊断相关数据，主要用于车辆厂商(即主机厂)、车辆原始设备生产商(originalequipment manufacturer，OEM)及其供应商之间交换诊断数据。现在有越来越多的主机厂和车辆OEM趋向于建立以ODX格式为核心的规范化诊断流程。在过去，许多主机厂或车辆OEM都开发了私有的诊断数据解决方案，使得不同车型、不同ECU，只能使用专门为其定制开发的测试设备进行诊断测试，甚至在同一个公司中，不同部门，诊断数据描述格式也不统一。2002年开始，ASAM(Association for Standardization of Automation and MeasuringSystems)组织的ODX工作组开始制定描述诊断数据的标准，以便能够简单地交换诊断数据，甚至跨越工具边界。2008年，ISO组织正式释放ISOODX标准——ISO22901。使用ODX格式编辑的诊断数据称为ODX文件，在实际使用中，ODX文件可以被包含在以.PDX为后缀的文件包中，方便存储。

参见图4，图4是本申请实施例提供的一种ODX文件的应用场景图，包括主机厂开发部门401、服务器402和诊断设备403。主机厂开发人员确定某一车型对应的诊断数据，按照ODX格式编辑数据，形成ODX文件，将ODX使用PDX文件格式打包，上传至服务器402，服务器不仅存储ODX文件，还预先存储有车型文件与ODX文件的对应关系。服务器可以通过有限、无限、存储介质传输等方式，将ODX文件传送给诊断设备。相应的，诊断设备403可以通过接收ODX文件，获取车辆的诊断数据。诊断数据中可以包括车辆的参数值的标准范围，还可以包括车辆的标准解析算法，其中，范围值可以使用可选值来表示，也可以是使用最大值和/或最小值来表示。服务器402中存储有一个或多个PDX文件包，PDX文件包中除了包括ODX文件，还可以包括附属的文件(如日志文件、密钥文件等)。服务器中存储了多个ODX文件，包括车辆当前使用的ODX文件，如区域404中的ODX文件，还包括历史版本的ODX文件，如区域405中的文件，可选的，主机厂中不仅存储ODX文件，还存储了车型信息与ODX文件地对应关系，便于发送对应车型地ODX文件。其中区域402为ODX文件的标识信息，区域407为ODX文件的版本号信息。可选的，服务器可以设置编辑、上传ODX文件的权限，只有符合权限要求的用户才可以编辑、上传ODX文件，以保证数据的真实性与准确性。

服务器可以在以下可选情况下向诊断设备发送ODX文件：

情况一，诊断设备向服务器发送请求，请求获取ODX文件。参见图5，图5是本申请提供的一种请求ODX文件的场景示意图，包括诊断设备501和车型信息选择控件502。诊断设备为用户提供多种车辆型号的信息，可以使用选择、输入、搜索等方式为用户呈现车型信息。接收到用户针对第一车型的车型信息的输入后，向服务器发送获取第一车型的ODX文件的请求。服务器接收到诊断设备的请求后，向诊断设备发送ODX文件。可选的，诊断设备也可以通过发送其他信息请求获取ODX文件，例如，ODX文件请求获取某一厂商生产的所有车型的ODX文件等，此处对诊断设备发送的请求信息的具体内容不做限定。可选的，在实际使用中，只有加入ODX文件共享协议或者购买了ODX文件的用户才可以下载ODX文件。

情况二，主机厂更新某一车型的ODX文件，服务器向诊断设备发送该ODX文件。在实际使用过程中，由于车辆系统升级、环境变化等情况，主机厂可以更新ODX文件并重新上传至服务器。服务器接收到更新的ODX文件后，向诊断设备发送更新后的ODX文件，保证诊断设备的预警结果的准确性。

情况三，服务器与诊断设备进行数据共享，向诊断设备发送ODX文件。例如，车辆主机厂商、诊断设备提供商可以签署相关约定，在诊断设备制造后，诊断设备为主机厂提供车辆监测服务，主机厂为诊断设备提供ODX文件，服务器为诊断设备提供预先约定的ODX文件，提升了车联网、无人驾驶等技术的数据交互性。

S302：诊断设备接收ODX文件，该ODX文件中包含标准解析算法和标准范围。具体的，标准解析算法用于解析命令，标准范围用于表征车辆中目标模块的参数值的安全范围。可选的，ODX文件可以包含在PDX文件包中，诊断设备接收到PDX文件包后，通过解析PDX文件包得到ODX文件。参见图6，图6是本申请实施例提供的一种ODX文件的示意图，包括标准解析算法数据601和标准范围数据602，其中，该ODX文件用于指示“刷写次数“的标准解析算法和标准范围，在标准解析算法数据601中，被”<SHORT-NAME>”与“</SHORT-NAME>”两个标签包裹的是标准算法的名称，即“DID0200__Progr ammingCounter_Hex__8_Bits”算法。在标准范围数据602中，”<LOWER-LIMIT>“标签包裹的数据即标准范围的最小值99，在”<UPPER-LIMIT>“标签包裹的数据即标准范围的最大值250。

步骤S303：诊断设备获取车辆的第一参数值。具体地，第一参数值是车辆在运行过程中产生的参数值，可以表示描述车辆中功能模块的运行状态。例如，参数值可以为实时油耗、发动机水温、发动机转速、车辆行驶里程、电瓶压力、进气压力、冷却液温度、氧传感器电压发动机负载、节气门开度和空气流量等等，可以描述车辆中对应功能模块的运行状态，例如，实时油耗可以表明车辆发动机的油耗状态。

诊断设备获取第一参数值至少可通过如下方式实现：

方式一，诊断设备通过其他中间设备或存储介质，获取第一参数值。例如，车辆中的数据收集设备用于收集车辆参数值，通过有线连接方式或者无线连接方式向诊断设备发送车辆参数值。诊断设备接收数据收集设备发送的车辆参数值，车辆参数值中包括第一参数。

方式二，诊断设备向第一车辆发送请求读取第一参数值的命令，接收第一车辆发送的返回命令，解析返回命令得到第一参数值。针对这种方式，该诊断设备第一车辆之间预先要建立通信连接，可以为有线连接，也可以为无线连接(例如，WI-FI连接、蜂窝网络连接等)，当诊断设备向第一车辆发送请求读取第一参数的命令，根据第一参数回复的命令解析得到第一参数值。可选的，诊断设备向第一车辆发送请求读取第一参数值的命令，可以由用户输入的操作来指示。

参见图7，图7是本申请实施例提供的一种可能的获取第一参数值的方法的示意图，包括诊断设备701、第一车辆702、请求命令703和返回命令704。例如，以第一参数为“刷写次数”为例，第一车辆请求读取刷鞋次数的命令为Req08 F2 60 03 22 02 00 00 00 0000。其中，Req表示这是设备发送给车辆地请求命令，仅作标识。该条数据用16进制标识，每一位代表4个bit位，每两位代表一个字节。第1-2位(即“08”)代表有效数据的长度为8个字节，意思是本条命令有效数据长度为8个字节，多余8个字节的数位为填充位。第3-6位(即“F2 60”)代表控制器局域网标识(controllerarea networkidentification，CAN ID)，CAN总线上的每个节点设备可以接收和发送多条不同CAN ID的数据帧，因此CAN ID可以标识接收本条命令或者发送本条命令的对象，而F2 60具体代表向存储了“刷写次数”的节点发送读取数据的请求。第7-8位(即“03”)代表有效数据的长度，因为前面字节均标识了发送对象等，真正请求发送的数据长度为3个字节(从当前位算起，即第7-12位)条数据的有效字节为3位，22表示算法标识数据，0200表示数据标识(data identifier，DID)，由于发送请求是没有数据，因此0200后面的数据为均为0。

第一车辆接收到诊断设备发送的请求命令702后，向诊断设备返回其所请求读取的数据值，该数据值编译在回复命令中，为了方便描述，将第一车辆返回的命令称为第二命令。可选的，诊断设备接收到命令后，可以使用解析算法解析命令，该解析算法由诊断设备接收到的ODX文件中指示，参见图6可以知晓车型的标准解析算法，便于快速解析车辆返回的命令。例如，第一车辆接收请求读取“刷次次数”的命令后，向诊断设备返回00608 F2 6004 62 02 00 FF 00 00 00，其中，006表示回复命令的序号。诊断设备接收命令后，使用标准解析算法对回复命令进行解析。例如，定位有效数据长度为08(8个字节)，定位DID为0200，0200数据后面的数据(即FF)为真正返回的数据。解析算法将16进制的FF转为十进制，即255，因此诊断设备使用标准解析算法解析的到刷写次数这一参数值为255。

可选的，在诊断设备向车辆发送给请求读取第一参数的命令之前，需要建立通信连接，因此需要先获取车辆的车型信息，便于确定通信协议。参见图8，图8是本申请实施例提供的一种获取车辆的车型信息的方法的示意图，该方法可以包括以下步骤：

步骤S811：诊断设备向第一车辆发送第一命令。

具体的，诊断设备向需要进行预警的车辆发送请求读取车辆标识(vehicleidentification number，VIN)的命令，为了方便描述，将需要进行预警的车辆称为第一车辆，将请求读取VIN码的命令称为第一命令。

诊断设备中预先存储有支持不同通信协议的第一命令，该多种通信协议可以包括关键字协议2000(keyword protocol 2000，KWP2000)、控制器局域网络(controller areanetwork，CAN)、脉冲宽度调制(pulse width modulation，PWM)、可变脉宽调制(variablepulse width modulated，VPW)中的一项或者多项，当然，该多种车辆协议除了包括这里例举的协议之外，还可能包括其他通信协议。该诊断设备可以基于上述通信协议与车辆进行通讯。

由于诊断设备开始时无法确定第一车辆使用的通讯协议，所以将基于不同的通讯协议的第一命令都向第一车辆发送一次，直到接收到车辆返回的VIN码。例如，车辆V1是采用CAN协议通信的车辆，诊断设备车辆V1的VIN码时，将支持CAN，KWP，PWM，VPW等协议的请求读VIN码第一命令给车辆V1。

步骤S812：第一车辆接收第一命令。

具体的，第一车辆接收诊断设备发送给请求读取VIN码的第一命令。例如，车辆V1车辆接收到通过CAN协议格式发送的第一命令，即请求读取VIN码命令，则将VIN码发送给诊断设备。

步骤S813：第一车辆向诊断设备发送车辆身份标识VIN码。

具体的，第一车辆通过有线连接或者无线连接(例如，WI-FI连接、蜂窝网络连接等)向诊断设备发送VIN码。

步骤S814：诊断设备接收第一车辆发送的VIN码。

步骤S815：诊断设备根据VIN码得到第一车辆的车型信息。

具体的，诊断设备在接收第一车辆发送的VIN码后，可以得到第一车辆的车型信息。例如，车辆V1向诊断设备返回自身的身份标识信息VIN码WDD2210222a253260，诊断设备根据接收到VIN码确定第一车辆的车型信息。VIN码的1至3位可以表征车辆的产地、品牌与车系，第4-8位可以表征车辆特征，如种类，系列，车身类型等，第9位可以表征校验位通过一定的算法防止输入错误，第10位可以表征表示车型年份，第11位可以表征组装工厂的代码，该VIN码的第12-17位可以表征生产序列号。诊断设备解析身份标识信息WDD2210222a253260，根据VIN码第1-3位可以确定车辆产地为德国，车辆的品牌为奔驰BENZ，车系为W221，根据VIN码的4-8位可以确定车型是S 320。由此可以得到车辆V1的型号为BENZ-S350。因此诊断设备可以根据车辆V1的型号，得到车辆所使用的通讯协议，与车辆建立通信连接。

可选的，诊断设备使用图8所述的方法获取的第一车辆的型号信息，可以在上述情况一所述的实施例中，将第一车辆的型号信息发送给服务器，使得服务器向诊断设备发送第一车辆的型号信息对应的ODX文件。

步骤S304：若第一参数值未落入所述标准范围，则诊断设备输出预警信息。

具体的，获取了标准范围和第一参数值后，若第一参数值未落入所述标准范围，则诊断设备输出预警信息，用于表示当前车辆的某一模块运行状态异常，例如，由图6所示的ODX文件得到第一车辆的“刷写次数”的范围为99至250，由图7所示的获取第一车辆的“刷写次数”值为255，因此，参数值没有落入标准范围，则诊断设备输出预警信息，提醒用户“刷写次数”异常，便于用于及时处理刷写次数的故障。上述输出预警信息的方案可以有以下几种可选方案：

方案一，诊断设备生成警戒色标记。参见图9，图9是本申请实施例提供的一种输出预警信息的方法的示意图，包括诊断设备913、参数菜单911、参数报表913，其中，诊断设备将超出标准范围的参数值用警戒色标志，方便用户查看状态异常的参数。例如，刷写次数这一参数的值为255，超出了标准范围99-255，因此，参数菜单中，刷写参数这一栏使用红色、蓝色等亮眼的颜色进行预警，方便用户及时查看刷写次数异常的问题。可选的，可以实时获取车辆的参数，将车辆参数形成变化图，便于用户生动形象地认识到车辆的运行状况。

方案二，诊断设备输出预警文字信息。具体的，上述文字信息可以包括短信、邮件、提示信息等。例如，诊断设备可以预先添加联系人邮箱或者电话号码，当信息出现异常，向预先添加的联系人发送邮件或者短信，便于在车辆运行异常时，及时联系预先添加的联系人，便于远程监测车辆的运行状况。

方案三，诊断设备输出预警语音信息。具体的，诊断设备可以通过声音输出设备(如扬声器、喇叭、耳机)等，播放语音信息提醒运行异常。参见图3，诊断设备901还包括扬声器模块913，因此在“刷写次数“这一参数值异常时，输出语音提醒，便于提醒不再诊断设备前的用户及时了解运行异常。

可选的，对于超出标准范围不同程度的参数值，可以输出不同等级的预警信息。例如，诊断设备中预先设置有第一阈值，若第一参数值超过标准范围中的最大值，但是第一参数值与标准范围中的最大值的差值小于第一阈值，则诊断设备输出第一预警信息，该第一预警信息可以是将该参数值使用第一警戒色标记(例如橙色)。若第一参数值超过标准范围中的最大值且第一参数值与标准范围中的最大值的差值大于或等于第一阈值，则输出第二预警信息，该第二预警信息可以是指示将该参数值使用第二警戒色标记(例如红色)。所述预警信息可以由诊断设备预先设置，或者接收用户输出的信息进行设置。

因此，由上可见对于超出范围的不同程度的参数值分为不同的预警等级，在检测到超过不同预设阈值的参数值时，能产生不同的预警消息，便于用户及时发现严重影响安全的参数值，及时解决车辆安全隐患，提高车辆安全性。

可选的，本申请实施例还可以包括步骤S305—S307或305及之后的步骤，步骤S305—S307具体如下：

步骤S304：诊断设备向服务器发送第一参数值和获取时间。

具体的，诊断设备在获取第一参数值时，记录获取第一参数值的时间作为获取时间。诊断设备向服务器发送第一参数值和获取时间，便于服务器进行数据收集与共享。例如，对于一些复杂的参数值，如汽油颗粒过滤器(gasoline particle filter，GPF)传感器自学习值等，用户在处理时不能针对该参数及时处理运行异常，则可以将参数值发送给服务器，主机厂可以通过服务器获取该参数信息，向用户提供解决方案。可选的，若第一车辆中记录了第一参数值的生成时间，诊断设备可以将第一参数的生成时间作为获取时间。

步骤S306：诊断设备向服务器发送第一参数值和获取时间。

具体的，诊断设备发送了第一参数值和获取时间，相应的，服务器接收第一参数和获取时间。服务器与诊断设备间可以通过有线(例如但不限于，同轴电缆、光纤和数字用户线等)或无线(例如但不限于，蓝牙、无限局域网和移动设备网络等)方式进行数据收发。

步骤S307：服务器输出数据报表，所述数据报表中包括第一参数值和获取时间。

具体的，服务器获取诊断设备发送的第一参数和获取时间后，可以基于获取时间和参数值建立数据报表，在需要对车辆的历史运行状况进行查看时，用户可以通过服务器查看数据报表，了解车辆之前的运行状况和预警车辆，便于用户针对性的查找车辆可能出现的问题。进一步的，将车辆的参数值和获取时间上传至服务器后，用于协助主机厂售后技术人员排查车辆问题，通过报告可以清楚的看到哪些数据流经常出现预警，是否是模块出现问题，方便消除车辆的安全隐患，保证形成安全。

在图3所描述的方法中，服务器向诊断设备发送带有标准参数范围的ODX文件，诊断设备使用标准参数范围值对车辆参数值进行监测，在参数值异常时输出预警信息，提高了车辆诊断报警结果的准确性和时效性，便于用户及时发现车辆运行异常、解决车辆故障。

请参见图10，图10是本申请实施例提供的一种车辆诊断报警装置100的结构示意图。该装置100可以包括接收单元1001、获取单元1002和输出单元1003，其中，各个单元的详细描述如下：

接收单元1001，用于接收服务器发送的目标诊断数据ODX文件，该目标ODX文件包含第一标准范围，该第一标准范围用于描述所述第一车辆中目标模块的参数值的安全范围；

获取单元1002，用于获取所述第一车辆运行过程中产生的第一参数值，该第一参数值用于描述所述第一车辆的所述目标模块的运行状态；

输出单元1003，用于若所述第一参数值未落入所述第一标准范围，则所述诊断设备输出预警信息，该预警信息表征所述第一车辆的所述目标模块的运行状态异常。

本申请实施例中，服务器向诊断设备发送带有标准参数范围的ODX文件，诊断设备使用标准参数范围值对车辆参数值进行监测，在参数值异常时输出预警信息，提高了车辆诊断报警结果的准确性和时效性，便于用户及时发现车辆运行异常、解决车辆故障。并且通过服务器获取标准范围的方式，使得在车辆生产商更新标准范围值后，诊断设备的获取的范围值也会相应更新，提高了车辆诊断报警结果的稳定性。

在一种可能的实施方式中，该装置还可以包括：

发送单元1004，用于向所述服务器发送第一车辆的车型信息；其中，该服务器上存储有多个车型信息与多个ODX文件的对应关系，该目标ODX文件为所述第一车辆的车型信息对应的ODX文件。

在又一种可能的实施方式中，该装置还可以包括：

输入单元1005，用于接收输入的第一操作，该第一操作指示向所述第一车辆发送多个第一命令，该多个第一命令分别支持不同的通信协议，该多个第一命令中每个第一命令均用于请求读取所述第一车辆的车辆识别号码VIN码；

发送单元1004，用于向所述第一车辆发送所述多个第一命令；

所述接收单元1001，用于接收所述第一车辆发送的VIN码；

识别单元1006，用于根据所述VIN码得到第一车辆的车型信息。

可以看出，诊断设备内预先存储支持多种通信协议的命令，通过向车辆发送多个请求读取车辆识别号码的命令来获取车辆的车辆识别号码，该多个读取车辆识别号码的命令分别支撑不同的通讯协议。因此，不管车辆采用何种通讯协议，都可以接收到请求读取车辆识别号码的指令，并向诊断设备发送的身份标志。

在又一种可能的实施方式中，该ODX文件还包含第一解析算法；获取单元1002，用于获取所述第一车辆运行过程中产生的第一参数值，具体为：

向所述第一车辆发送请求读取第一参数值的命令；

接收所述第一车辆发送的第二命令，该第二命令中编译有所述第一参数值；

根据所述第一解析算法解析所述第二命令，得到所述第一参数值。

可以看出，ODX文件中还可以包括车辆的标准解析算法，通过所述标准解析算法可以快速的定位解析车辆发送的命令应当使用何种算法解析，而不用重新查找解析算法，提高了解析车辆回复命令的效率。

在又一种可能的实施方式中，该装置还可以包括：

输入单元1005，用于接收输入的第二操作，该第二操作用于指示向所述第一车辆发送请求读取所述第一参数值的命令。

在又一种可能的实施方式中，该获取单元1002，还用于记录所述第一参数值的获取时间，该获取时间为所述诊断设备获取第一参数值的时间；

装置100还可以包括：发送单元1004，用于向服务器发送所述第一参数值和所述获取时间，该第一参数值和所述获取时间用于所述服务器输出第一车辆的数据报表。

在第三方面的又一种可能的实施方式中，该第一标准范围包括最大值和最小值；所述输出单元1005，用于若所述第一参数值未落入所述第一标准范围，则所述诊断设备输出预警信息，具体为：

若所述第一参数值与所述最大值或所述最小值的差值小于预设第一阈值，则输出第一预警信息；

若所述第一参数值与所述最大值或所述最小值的差值等于或大于所述预设第一阈值，则输出第二预警信息。

需要说明的是，各个操作的实现还可以对应参照图3所示的方法实施例的相应描述。该车辆诊断报警装置100为图3所示方法实施例中的诊断设备。

请参见图11，图11是本申请实施例提供的一种服务器110的结构示意图。该服务器110可以包括接收单元1101、确定单元1102和发送单元1103，其中，各个单元的详细描述如下：

接收单元1101，用于接收所述诊断设备发送的第一车辆的车型信息；

确定单元1102，用于确定第一车辆的车型信息对应的ODX文件，其中，该服务器中存储有多个车型信息与多个ODX文件的对应关系，该目标ODX文件中包含第一标准范围，该第一标准范围用于描述所述第一车辆中目标模块的参数值的安全范围；

发送单元1103，用于向所述诊断设备发送所述目标ODX文件，该目标ODX文件用于所述诊断设备输出预警信息，该预警信息表征所述第一车辆的所述目标模块的运行状态异常。

在一种可能的实施方式中，该接收单元1102，还用于接收所述诊断设备发送的第一参数值和获取时间；所述第一参数值用于描述所述第一车辆的所述目标模块的运行状态，该获取时间为所述诊断设备获取第一参数值的时间；

所述服务器还可以包括输出单元1103，用于输出第一车辆数据报表，该数据报表中包含所述第一参数值和所述获取时间。

需要说明的是，各个操作的实现还可以对应参照图3所示的方法实施例的相应描述。该服务器110为图3所示方法实施例中的服务器。

请参见图12，图12是本申请实施例提供的一种诊断设备120的结构示意图，该诊断设备可以包括存储器1201、处理器1202和通信接口1203，还可以包括用户接口1205，其中，存储器1201、处理器1202、通信接口1203和用户接口1205可通过总线1204或其他方式连接，本申请实施例以通过总线连接为例，各个单元的详细描述如下。

其中，存储器1201(Memory)是诊断设备中的存储设备，用于存放程序和数据。可以理解的是，此处的存储器1201既可以包括诊断设备的内置存储器，当然也可以包括诊断设备所支持的扩展存储器。存储器1201提供存储空间，该存储空间存储了诊断设备的操作系统及其他数据，可包括但不限于：Android系统、iOS系统、Windows Phone系统等等，本申请对此并不作限定。

处理器1202(或称中央处理器(Central Processing Unit，CPU))是诊断设备的计算核心以及控制核心，其可以解析诊断设备内的各类指令以及处理诊断设备的各类数据，例如：CPU可以在诊断设备内部结构之间传输各类交互数据，等等。

通信接口1203用于接收和发送数据。通信接口1203可以连接获取器、发射器、射频器或其他通信模块，其他通信模块可以包括WiFi模块、蓝牙模块等。

用户接口1203可以是与用户进行交互操作的输入设备的接口，例如用于录制音频的设备，如麦克风或者音频记录模块，或者输入设备可以是键盘、鼠标、或者可触摸显示屏等数据采集的模块，在这里不限制。

所述存储器中可以存储有计算机程序，处理器1202可以用于调用存储器1201中存储的计算机程序，可以执行如图3所示实施例提供的方法。

需要说明的是，诊断设备120执行的具体操作还可以对应参照图3所示的方法实施例的相应描述。该诊断设备120为图3所示方法实施例中的诊断设备。

请参见图13，图13是本申请实施例提供的又一种服务器130的结构示意图，该服务器可以包括存储器1201、处理器1202和通信接口1203，其中，存储器1201、处理器1202和通信接口1203可通过总线1204或其他方式连接，本申请实施例以通过总线连接为例，各个单元的详细描述如下。

其中，存储器1301(Memory)是服务器中的存储设备，用于存放程序和数据。可以理解的是，此处的存储器1301既可以包括服务器内置存储器，当然也可以包括服务器所支持的扩展存储器。存储器1301提供存储空间，该存储空间存储了服务器的操作系统及其他数据，可包括但不限于：Android系统、iOS系统、Windows Phone系统等等，本申请对此并不作限定。

处理器1302(或称中央处理器(Central Processing Unit，CPU))是服务器的计算核心以及控制核心，其可以解析服务器内的各类指令以及处理服务器的各类数据，例如：CPU可以在服务器内部结构之间传输各类交互数据，等等。

通信接口1303用于接收和发送数据。通信接口1203可以连接获取器、发射器、射频器或其他通信模块，其他通信模块可以包括但不限于WiFi模块、蓝牙模块等。

用户接口1303可以是与用户进行交互操作的输入设备的接口，例如用于录制音频的设备，如麦克风或者音频记录模块，或者输入设备可以是键盘、鼠标、或者可触摸显示屏等数据采集的模块，在这里不限制。

所述存储器中可以存储有计算机程序，处理器1302可以用于调用存储器1301中存储的计算机程序，可以执行如图3所示实施例提供的方法。

需要说明的是，服务器130所执行的具体操作还可以对应参照图3所示的方法实施例的相应描述。该服务器130为图3所示方法实施例中的服务器。

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

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

Claims

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

诊断设备接收服务器发送的目标诊断数据ODX文件，所述目标ODX文件包含第一标准范围，所述第一标准范围用于描述所述第一车辆中目标模块的参数值的安全范围；

所述诊断设备获取所述第一车辆运行过程中产生的第一参数值，所述第一参数值用于描述所述第一车辆的所述目标模块的运行状态；

若所述第一参数值未落入所述第一标准范围，则所述诊断设备输出预警信息，所述预警信息表征所述第一车辆的所述目标模块的运行状态异常。

2.根据权利要求1所述的方法，其特征在于，所述诊断设备接收服务器发送的目标诊断数据ODX文件之前，还包括：

所述诊断设备向所述服务器发送第一车辆的车型信息；其中，所述服务器上存储有多个车型信息与多个ODX文件的对应关系，所述目标ODX文件为所述第一车辆的车型信息对应的ODX文件。

3.根据权利要求1或2所述的方法，其特征在于，在所述诊断设备接收服务器发送的目标诊断数据ODX文件之前，还包括：

所述诊断设备接收第一操作，所述第一操作指示向所述第一车辆发送多个第一命令，所述多个第一命令分别支持不同的通信协议，所述多个第一命令中每个第一命令均用于请求读取所述第一车辆的车辆识别号码VIN码；

所述诊断设备向所述第一车辆发送所述多个第一命令；

所述诊断设备接收所述第一车辆发送的VIN码；

所述诊断设备根据所述VIN码得到第一车辆的车型信息。

4.根据权利要求1中所述的方法，其特征在于，所述ODX文件还包含第一解析算法；在所述诊断设备获取所述第一车辆运行过程中产生的第一参数值之前，还包括：

所述诊断设备接收输入的第二操作，所述第二操作用于指示向所述第一车辆发送请求读取所述第一参数值的命令；

所述诊断设备获取所述第一车辆运行过程中产生的第一参数值，包括：

所述诊断设备向所述第一车辆发送请求读取第一参数值的命令；

所述诊断设备接收所述第一车辆发送的第二命令，所述第二命令中编译有所述第一参数值；

所述诊断设备根据所述第一解析算法解析所述第二命令，得到所述第一参数值。

5.根据权利要求1或2中所述的方法，其特征在于，所述诊断设备获取所述第一车辆运行过程中产生的第一参数值之后，还包括：

所述诊断设备记录所述第一参数值的获取时间，所述获取时间为所述诊断设备获取第一参数值的时间；

所述诊断设备向服务器发送所述第一参数值和所述获取时间，所述第一参数值和所述获取时间用于所述服务器输出第一车辆的数据报表。

6.根据权利要求1或2中所述的方法，其特征在于，所述第一标准范围包括最大值和最小值；所述若所述第一参数值未落入所述第一标准范围，则所述诊断设备输出预警信息，包括：

若所述第一参数值与所述最大值或所述最小值的差值小于预设第一阈值，则所述诊断设备输出第一预警信息；

若所述第一参数值与所述最大值或所述最小值的差值等于或大于所述预设第一阈值，则所述诊断设备输出第二预警信息。

7.一种车辆诊断报警方法，其特征在于，包括：

服务器接收所述诊断设备发送的第一车辆的车型信息；

所述服务器确定第一车辆的车型信息对应的目标诊断数据ODX文件，其中，所述服务器中存储有多个车型信息与多个ODX文件的对应关系，所述目标ODX文件中包含第一标准范围，所述第一标准范围用于描述所述第一车辆中目标模块的参数值的安全范围；

所述服务器向所述诊断设备发送所述目标ODX文件，所述目标ODX文件用于所述诊断设备输出预警信息，所述预警信息表征所述第一车辆的所述目标模块的运行状态异常。

8.一种车辆诊断报警装置，其特征在于，包括：

接收单元，用于接收服务器发送的目标诊断数据ODX文件，所述目标ODX文件包含第一标准范围，所述第一标准范围用于描述所述第一车辆中目标模块的参数值的安全范围；

获取单元，用于获取所述第一车辆运行过程中产生的第一参数值，所述第一参数值用于描述所述第一车辆的所述目标模块的运行状态；

输出单元，用于若所述第一参数值未落入所述第一标准范围，则所述诊断设备输出预警信息，所述预警信息表征所述第一车辆的所述目标模块的运行状态异常。

9.一种服务器，其特征在于，包括：

接收单元，用于接收所述诊断设备发送的第一车辆的车型信息；

确定单元，用于确定所述第一车辆的车型信息对应的目标诊断数据ODX文件，其中，所述服务器中存储有多个车型信息与多个ODX文件的对应关系，所述目标ODX文件中包含第一标准范围，所述第一标准范围用于描述所述第一车辆中目标模块的参数值的安全范围；

发送单元，用于向所述诊断设备发送所述目标ODX文件，所述目标ODX文件用于所述诊断设备输出预警信息，所述预警信息表征所述第一车辆的所述目标模块的运行状态异常。

10.一种电子设备，其特征在于，包括：处理器、存储器和通信接口；所述处理器与所述存储器、所述通信接口相连，所述存储器中存储有计算机程序，所述处理器用于调用所述计算机程序，以执行权利要求1-7中任一项所述的方法。