一种快速定位OBD设备故障的故障检测方法及系统与流程

本发明涉及一种obd设备的故障检测方法及系统，特别是公开一种快速定位obd设备故障的故障检测方法及系统。

背景技术：

obd（on-boarddiagnostics，车载诊断系统）可以实时监测车辆的发动机、催化转化器、颗粒捕集器、氧传感器、排放控制系统、燃油系统、egr等系统和部件，随时监控车辆发动机的运行状况和尾气后处理系统的工作状态，一旦发现有可能引起排放超标的情况，会马上发出警示。当车辆的系统和部件出现故障时，故障灯(mil)或检查发动机(checkengine)警告灯亮，同时obd会将故障信息存入存储器，通过标准的诊断仪器和诊断接口可以以故障码的形式读取相关信息，根据故障码的提示，维修人员能迅速准确地确定故障的性质和部位。

由于obd设备使用地点分散，且使用量较大，一旦obd设备在现场使用，难免会出现一些故障，这就给车辆故障分析带了很大的不便。通常的解决方案为：obd设备跟服务器端约定好数据格式，定期向服务器上报设备运行状态：

假设obd设备每隔一分钟向服务器上报一次数据，在每个数据包中携带设备故障码，例如约定：

bit0：gps故障

bit1：can通讯模块故障

bit2：4g通讯模块故障

...：其他故障

当bit为0时表示正常，为1时表示故障。服务器收到数据包后解析这个bit，然后可以看出obd设备是否有故障。在实际使用过程中，obd设备故障率很低的情况下，上传这个数据是浪费网络资源的。更重要的是，在数据包中携带故障码只能看出预期的故障，如果程序的逻辑上出现bug，工程师很难排查出具体原因。因此，查看故障的最好方式是抓取obd设备的log。

当服务器发现obd设备数据上报异常，在一系列分析后不能找到原因时，就需要派工程师到现场排查，抓取obd设备的log，然后分析原因，如果obd设备处于危险环境下，则很难处理。

上述方案在obd设备正常运行时会导致流量浪费，同时会带来巨大的人力资源成本，浪费人力资源，有不经济的缺点。

技术实现要素：

本发明的目的在于解决现有技术的缺陷，提供一种快速定位obd设备故障的故障检测方法及系统，在obd设备使用期间遇到故障时，能够快速准确的定位故障点，无需工程师到现场排查情况，大大降低了经济成本，节约了流量及人力资源。

本发明是这样实现的：一种快速定位obd设备故障的故障检测方法，其特征在于：所述故障检测方法包括下述步骤：

（1）接收服务器的故障检测指令，解析故障检测指令；

（2）根据解析结果判断是否打开gps模块、can通讯模块和/或4g通讯模块的log开关，保存打开了log开关的模块的log，log保存时长通过定时器控制；

（3）压缩保存的log文件，把压缩的log文件发送给服务器；

（4）服务器解压缩接收到的log文件，并根据log文件结合源代码定位obd设备故障位置。

所述步骤（1）中解析故障检测指令的具体步骤包括：根据obd设备与服务器约定的通讯的数据格式来解析故障检测指令，数据格式包括标识符、预留、长度、帧头、终端id、操作响应、报文内容和校验码，在收到服务器下发的数据包后，首先判断标识符、长度、帧头及校验码，如果数据包没问题，就开始解析报文内容，报文内容包括流水号、命令及参数，根据报文内容中的命令及参数部分判断是哪类命令及命令参数，如果数据包有问题，就丢掉此数据包。

所述步骤（2）中的gps模块、can通讯模块和4g通讯模块分别使用自己的打印函数，在打印函数中分别用一个全局变量控制是否打印到文件，打印时间通过定时器控制，在收到打开gps模块、can通讯模块和/或4g通讯模块的log开关的指令后，把对应模块中对应的打印函数中的变量置位，当下一次该模块调用到这个打印函数时，就会把log内容写到指定的文件，can通讯模块的log写到/log/canlog.txt，4g通讯模块的log写到/log/mdmlog.txt，gps模块的log写到/log/gpslog.txt。

所述步骤（2）中的log保存时长默认为5分钟。

所述步骤（4）中的根据log文件结合源代码定位obd设备故障位置的具体步骤包括：服务器把log文件的打印信息与源代码进行比对，log文件的打印信息与源代码逻辑不一致的部分为obd设备故障位置。

一种快速定位obd设备故障的故障检测系统，其特征在于：所述故障检测系统包括服务器、gps模块、can通讯模块和4g通讯模块，所述4g通讯模块集成有处理器和存储器，所述处理器和存储器相连，所述4g通讯模块分别连接gps模块、can通讯模块和watchdog，所述4g通讯模块与服务器通讯连接，所述can通讯模块还与obd接口连接，所述gps模块、can通讯模块、4g通讯模块和watchdog分别设置在obd设备的壳体内，所述gps模块用于获取当前的位置数据，所述4g通讯模块用于读取gps模块数据，4g通讯模块通过can通讯模块向车辆发送数据及读取数据，所述4g通讯模块还用于解析服务器发来的故障检测指令，并根据解析结果判断是否打开gps模块、can通讯模块和/或4g通讯模块的log开关，保存打开了log开关的模块的log，log保存时长通过定时器控制，压缩保存的log文件，把压缩的log文件发送给服务器，所述服务器用于发送故障检测指令，以及解压缩接收到的log文件，并根据log文件结合源代码定位obd设备故障位置，所述watchdog用于重置4g通讯模块。

所述位置数据包括gps信号强度、gps是否定位、经纬度、高度、速度。所述4g通讯模块和can通讯模块之间的通讯方式是串口。

本发明的有益效果是：本发明在obd设备使用期间遇到故障时，服务器可以根据实际需要远程控制obd设备，进而获取obd设备的gps模块、can通讯模块和/或4g通讯模块的log，然后根据log文件分析故障的原因，能够快速准确的定位obd设备的故障点，操作方便、省时，无需工程师到现场排查情况，当obd设备处于高危环境中时也可以获取log，本发明达到的效果与工程师到现场排查情况达到的效果一致，从而节省了大量的人力成本，且能很快定位obd设备的故障点，大大降低了经济成本，节约了流量及人力资源。

附图说明

图1是本发明的故障检测方法的流程示意图。

图2是obd设备的结构方框示意图。

具体实施方式

下面结合附图对本发明作进一步详细说明。

根据附图1和附图2，本发明为一种快速定位obd设备故障的故障检测方法，包括下述步骤：

（1）接收服务器的故障检测指令，解析故障检测指令；

（2）根据解析结果判断是否打开gps模块、can通讯模块和/或4g通讯模块的log开关，保存打开了log开关的模块的log，log保存时长通过定时器控制；

（3）压缩保存的log文件，把压缩的log文件发送给服务器；

（4）服务器解压缩接收到的log文件，并根据log文件结合源代码定位obd设备故障位置。

所述步骤（1）中解析故障检测指令的具体步骤包括：根据obd设备与服务器约定的通讯的数据格式来解析故障检测指令，数据格式包括标识符、预留、长度、帧头、终端id、操作响应、报文内容和校验码，在收到服务器下发的数据包后，首先判断标识符、长度、帧头及校验码，如果数据包没问题，就开始解析报文内容，报文内容包括流水号、命令及参数，根据报文内容中的命令及参数部分判断是哪类命令及命令参数，如果数据包有问题，就丢掉此数据包。

所述步骤（2）中的gps模块、can通讯模块和4g通讯模块分别使用自己的打印函数，在打印函数中分别用一个全局变量控制是否打印到文件，打印时间通过定时器控制，在收到打开gps模块、can通讯模块和/或4g通讯模块的log开关的指令后，把对应模块中对应的打印函数中的变量置位，当下一次该模块调用到这个打印函数时，就会把log内容写到指定的文件，can通讯模块的log写到/log/canlog.txt，4g通讯模块的log写到/log/mdmlog.txt，gps模块的log写到/log/gpslog.txt。

所述步骤（2）中的log保存时长默认为5分钟。

所述步骤（4）中的根据log文件结合源代码定位obd设备故障位置的具体步骤包括：服务器把log文件的打印信息与源代码进行比对，log文件的打印信息与源代码逻辑不一致的部分为obd设备故障位置。

一种应用快速定位obd设备故障的故障检测方法的故障检测系统，包括服务器、gps模块、can通讯模块和4g通讯模块，所述4g通讯模块集成有处理器和存储器，所述处理器和存储器相连，所述4g通讯模块分别连接gps模块、can通讯模块和watchdog，所述4g通讯模块与服务器通讯连接，所述can通讯模块还与obd接口连接，所述gps模块、can通讯模块、4g通讯模块和watchdog分别设置在obd设备的壳体内。

所述gps模块用于获取当前的位置数据，例如gps信号强度、gps是否定位、经纬度、高度、速度等。所述gps模块选用u-blox公司生产的ubx-g7020模块。

所述can通讯模块是4g通讯模块和车辆沟通的媒介，4g通讯模块可以通过can通讯模块向车辆发送数据和读取数据，4g通讯模块和can通讯模块之间的通讯方式是串口。所述can通讯模块选用意法半导体(中国)投资有限公司生产的stm32f103cbt6tr模块。

所述4g通讯模块可以通过iic总线读取gps模块数据。所述4g通讯模块还用于解析服务器发来的故障检测指令，并根据解析结果判断是否打开gps模块、can通讯模块和/或4g通讯模块的log开关，保存打开了log开关的模块的log，log保存时长通过定时器控制，压缩保存的log文件，把压缩的log文件发送给服务器。所述4g通讯模块选用德明通讯（上海）有限责任公司生产的lm61-31模块。

所述服务器用于发送故障检测指令，以及解压缩接收到的log文件，并根据log文件结合源代码定位obd设备故障位置。

所述watchdog用于重置4g通讯模块，即4g通讯模块5分钟以内需要喂一次watchdog(即拉高再拉低约定的管脚)，否则会被重置（被重新上电）。所述watchdog选用意法半导体(中国)投资有限公司生产的stm8s003f3p6tr模块。

所述4g通讯模块正常运行时不保存任何log，4g通讯模块在接收到服务器的故障检测指令后，解析服务器发来的故障检测指令，并根据解析结果判断是否打开gps模块、can通讯模块和/或4g通讯模块的log开关，各个模块的log开关可以单独控制，然后保存打开了log开关的模块的log，log保存时长默认为5分钟，时间可调，log保存时长通过定时器控制，所述定时器为软件定时器，由于4g通讯模块采用linux操作系统，可采用其定时器接口，然后压缩保存的log文件，把压缩的log文件发送给服务器，服务器解压缩接收到的log文件，并根据log文件结合源代码定位obd设备故障位置。

gps模块故障包括：gps信号弱故障，即在露天环境，gps搜星数量少于4个，从经验判断，大概率是gps天线损坏导致的。

can通讯模块故障包括：1、4g通讯模块向can通讯模块发心跳包，can通讯模块不反馈；

2、4g通讯模块向can通讯模块发心跳包，can通讯模块反馈，但是can通讯模块无法收到车辆can总线的数据。

4g通讯模块故障包括：1、无法联网，可能是物联网卡松动或者欠费导致；

2、能联网，但无法连接到服务器，可能是服务器维护或者未把设备添加到服务器的白名单导致的；以上两种情况，设备会保存无法联网时产生的log，等下一次能联网时再进行上报，但在此之前，仅能用灯光指示设备联网故障；

3、设备无法通过文件保存数据，通常是因为nandflash存储空间用尽导致的。

下面结合实施例对本发明作进一步详细说明。

实施例1：

手动把车辆的左前门关闭，而服务器显示左前门为打开状态。从逻辑上分析，左前门的状态来自车内的obd数据，服务器显示的数据来自obd设备，如果状态不一致，要么是obd设备从车内obd获取的数据有误，要么是obd设备上报服务器的数据有误。此时，obd设备的log就可以起作用了。

本实施例的快速定位obd设备故障的故障检测方法包括下述步骤：

（1）接收服务器的故障检测指令，解析故障检测指令；

（2）根据解析结果判断是否打开gps模块、can通讯模块和/或4g通讯模块的log开关，保存打开了log开关的模块的log，log保存时长通过定时器控制；

（3）压缩保存的log文件，把压缩的log文件发送给服务器；

（4）服务器解压缩接收到的log文件，并根据log文件结合源代码定位obd设备故障位置。

表1为obd设备与服务器约定的通讯的数据格式表：

所述步骤（1）中解析故障检测指令的具体步骤包括：根据obd设备与服务器约定的通讯的数据格式来解析故障检测指令，数据格式包括标识符、预留、长度、帧头、终端id、操作响应、报文内容和校验码，4g通讯模块在收到服务器下发的数据包后，首先判断标识符、长度、帧头及校验码，如果数据包没问题，就开始解析报文内容，报文内容包括流水号、命令及参数，根据报文内容中的命令及参数部分判断是哪类命令及命令参数；如果数据包有问题，就丢掉此数据包。

例如，约定报文内容中的命令及参数：

命令为0xfffe时，参数的值为1，打开gps模块的log，参数的值为0，则关闭gps模块的log；

命令为0xfffd时，参数的值为1，打开can通讯模块的log，参数的值为0，则关闭can通讯模块的log；

命令为0xfffc时，参数的值为1，打开4g通讯模块的log，参数的值为0，则关闭4g通讯模块的log；

根据报文内容中的命令及参数解析出的故障检测指令为：打开4g通讯模块和can通讯模块的log开关。

所述步骤（2）中的gps模块、can通讯模块和4g通讯模块分别使用自己的打印函数，在打印函数中分别用一个全局变量控制是否打印到文件，打印时间通过定时器控制。4g通讯模块收到打开can通讯模块的log开关的指令后，把can通讯模块中对应的打印函数中的变量(canlogopen)置位(true)，当下一次can通讯模块调用到这个打印函数时，就会把log内容写到/log/canlog.txt。

boolcanlogopen=false;

intcnt=60；

can_printf(char*buf)

{

if(canlogopen&&cnt)

{

file*fd=fopen("/log/canlog.txt","a+");

stdout=fd;

printf("%s",buf);

fclose(fd);

}

}

其中cnt是用来控制打印时间的，在定时器回调函数中，cnt每秒递减1。当收到服务器的指令后，初始化cnt=60，并启动定时器，在定时器回调函数中执行cnt--；直至cnt为0，定时器结束。

然后进行步骤（3）打包log文件：

dosystem(“tar-cvf/log/terminal.tar/log/canlog.txt”);

然后通过socket把/log/terminal.tar文件发送至服务器。

4g通讯模块收到打开4g通讯模块与gps模块的log开关的指令后的执行模式同can通讯模块，4g通讯模块的log写到/log/mdmlog.txt，gps模块的log写到/log/gpslog.txt。

所述步骤（4）中的根据log文件结合源代码定位obd设备故障位置的具体步骤包括：服务器接收到log文件：mdmlog.txt和canlog.txt。

canlog.txt：

2019-7-1815:20:39:uartluart_recv_thread(1438)thereisok

2019-7-1815:20:39:bcm_general_status：

00000000000000ff

mdmlog.txt：

2019-7-1815：20：49：terminalsocketsenddatatoserver：

7e000000011e262616318281011030000009570a81000d00007d2e0d1631828101100100000957000000000000000000ffffffffffffff

表2为obd数据协议表：

通过与表2的16bit对照，此时can通讯模块收到的数据显示左前门状态为打开，4g通讯模块向服务器发送的数据显示左前门也是打开状态，即can通讯模块从车内obd获取的数据有误，can通讯模块故障。

实施例2：

通过蓝牙钥匙打开近光灯，而服务器显示近光灯为关闭状态。从逻辑上分析，近光灯的开关状态来自车内的obd数据，服务器显示的数据来自obd设备，如果状态不一致，要么是obd设备从车内obd获取的数据有误，要么是obd设备上报服务器的数据有误。可以通过远程抓log的方式定位问题的原因。

本实施例的快速定位obd设备故障的故障检测方法的步骤同实施例1。

服务器接收到log文件：mdmlog.txt和canlog.txt，通过与表2的8bit对照，can通讯模块收到的数据显示近光灯状态为关闭，4g通讯模块向服务器发送的数据显示近光灯也是关闭状态，即can通讯模块从车内obd获取的数据有误，can通讯模块故障。

实施例3：

当服务器发现某个obd设备长期未定位时，可以给该obd设备下发打开gps模块的log开关的命令，obd设备收到命令后，收集数据并上报给服务器，服务器接收到后就可以通过log判断是不是因为gps信号太弱还是其他原因导致无法定位了。

本实施例的快速定位obd设备故障的故障检测方法包括下述步骤：

（1）接收服务器的故障检测指令，解析故障检测指令；

（2）根据解析结果判断是否打开gps模块、can通讯模块和/或4g通讯模块的log开关，保存打开了log开关的模块的log，log保存时长通过定时器控制；

（3）压缩保存的log文件，把压缩的log文件发送给服务器；

（4）服务器解压缩接收到的log文件，并根据log文件结合源代码定位obd设备故障位置。

所述步骤（1）中解析故障检测指令的具体步骤包括：根据obd设备与服务器约定的通讯的数据格式来解析故障检测指令，数据格式包括标识符、预留、长度、帧头、终端id、操作响应、报文内容和校验码，4g通讯模块在收到服务器下发的数据包后，首先判断标识符、长度、帧头及校验码，如果数据包没问题，就开始解析报文内容，报文内容包括流水号、命令及参数，根据报文内容中的命令及参数部分判断是哪类命令及命令参数；如果数据包有问题，就丢掉此数据包。

例如，约定报文内容中的命令及参数：

命令为0xfffe时，参数的值为1，打开gps模块的log，参数的值为0，则关闭gps模块的log；

命令为0xfffd时，参数的值为1，打开can通讯模块的log，参数的值为0，则关闭can通讯模块的log；

命令为0xfffc时，参数的值为1，打开4g通讯模块的log，参数的值为0，则关闭4g通讯模块的log；

根据报文内容中的命令及参数解析出的故障检测指令为：打开gps模块的log开关。

所述步骤（2）中的gps模块、can通讯模块和4g通讯模块分别使用自己的打印函数，在打印函数中分别用一个全局变量控制是否打印到文件，打印时间通过定时器控制。4g通讯模块收到打开gps模块的log开关的指令后，把gps模块中对应的打印函数中的变量(gpslogopen)置位(true)，当下一次gps模块调用到这个打印函数时，就会把log内容写到/log/gpslog.txt。

boolgpslogopen=false;

intcnt=60；

gps_printf(char*buf)

{

if(gpslogopen&&cnt)

{

file*fd=fopen("/log/gpslog.txt","a+");

stdout=fd;

printf("%s",buf);

fclose(fd);

}

}

其中cnt是用来控制打印时间的，在定时器回调函数中，cnt每秒递减1。当收到服务器的指令后，初始化cnt=60，并启动定时器，在定时器回调函数中执行cnt--；直至cnt为0，定时器结束。

然后进行步骤（3）打包log文件：

dosystem(“tar-cvf/log/terminal.tar/log/gpslog.txt”);

然后通过socket把/log/terminal.tar文件发送至服务器。

步骤（4）中的根据log文件结合源代码定位obd设备故障位置的具体步骤包括：服务器接收到log文件：gpslog.txt。

gpslog.txt：

2019-7-1815:22:19:gps_uart_nmeaparsefun

$gpgsv,3,1,2,18,84,067,23,09,67,067,27,22,49,312,28,15,47,231,30*70

gpsnmea解析规则：

$gpgsv,<1>,<2>,<3>,<4>,<5>,<6>,<7>,…<4>,<5>,<6>,<7>,<8>

<1>gsv语句的总数；

<2>本句gsv的编号；

<3>可见卫星的总数，0至12；

<4>卫星编号，1至32；

<5>卫星仰角，0至90度；

<6>卫星方位角，0至359度；

<7>讯号噪声比（c/no）；

<8>checksum.

通过gpslog.txt可以看出，当前看见卫星总数为2，因为卫星定位至少需要4个可见卫星，可以因此判断出此时不满足定位条件，即认为gps信号太弱。

实施例4：

当服务器发现某个obd设备上报的报文偶尔漏包时，可以给该obd设备下发打开4g通讯模块的log开关的命令，obd设备收到命令后，收集数据并上报给服务器，服务器接收到后就可以通过log判断是漏包还是因为信号不好把数据包保存到本地了。

本实施例的快速定位obd设备故障的故障检测方法包括下述步骤：

（1）接收服务器的故障检测指令，解析故障检测指令；

（2）根据解析结果判断是否打开gps模块、can通讯模块和/或4g通讯模块的log开关，保存打开了log开关的模块的log，log保存时长通过定时器控制；

（3）压缩保存的log文件，把压缩的log文件发送给服务器；

（4）服务器解压缩接收到的log文件，并根据log文件结合源代码定位obd设备故障位置。

所述步骤（1）中解析故障检测指令的具体步骤包括：根据obd设备与服务器约定的通讯的数据格式来解析故障检测指令，数据格式包括标识符、预留、长度、帧头、终端id、操作响应、报文内容和校验码，4g通讯模块在收到服务器下发的数据包后，首先判断标识符、长度、帧头及校验码，如果数据包没问题，就开始解析报文内容，报文内容包括流水号、命令及参数，根据报文内容中的命令及参数部分判断是哪类命令及命令参数；如果数据包有问题，就丢掉此数据包。

例如，约定报文内容中的命令及参数：

命令为0xfffe时，参数的值为1，打开gps模块的log，参数的值为0，则关闭gps模块的log；

命令为0xfffd时，参数的值为1，打开can通讯模块的log，参数的值为0，则关闭can通讯模块的log；

命令为0xfffc时，参数的值为1，打开4g通讯模块的log，参数的值为0，则关闭4g通讯模块的log；

根据报文内容中的命令及参数解析出的故障检测指令为：打开4g通讯模块的log开关。

所述步骤（2）中的gps模块、can通讯模块和4g通讯模块分别使用自己的打印函数，在打印函数中分别用一个全局变量控制是否打印到文件，打印时间通过定时器控制。4g通讯模块收到打开4g通讯模块的log开关的指令后，把4g通讯模块中对应的打印函数中的变量(mdmlogopen)置位(true)，当下一次4g通讯模块调用到这个打印函数时，就会把log内容写到/log/mdmlog.txt。

boolmdmlogopen=false;

intcnt=60；

mdm_printf(char*buf)

{

if(mdmlogopen&&cnt)

{

file*fd=fopen("/log/mdmlog.txt","a+");

stdout=fd;

printf("%s",buf);

fclose(fd);

}

}

其中cnt是用来控制打印时间的，在定时器回调函数中，cnt每秒递减1。当收到服务器的指令后，初始化cnt=60，并启动定时器，在定时器回调函数中执行cnt--；直至cnt为0，定时器结束。

然后进行步骤（3）打包log文件：

dosystem(“tar-cvf/log/terminal.tar/log/mdmlog.txt”);

然后通过socket把/log/terminal.tar文件发送至服务器。

步骤（4）中的根据log文件结合源代码定位obd设备故障位置的具体步骤包括：服务器接收到log文件：mdmlog.txt。

mdmlog.txt：

2019-7-1815:22:19:wait_count:10is_data_packet:1

根据代码逻辑，当执行完发送数据函数后，每秒对变量wait_count加一，如果收到服务器的确认包，则把变量wait_count清零，否则当wait_count大于等于10时，则保存发送数据到本地，通过mdmlog.txt可以看出，故障原因是未收到服务器确认包，此时认为服务器未收到数据。

上述实施例仅用于说明本发明而不用于限制本发明的范围，应理解，在阅读了本发明阐述的内容之后，本领域技术人员可以对本发明作不同形式但效果相同的各种改动或修改，这些等同形式修改同样落于本申请权利要求书所限定保护的范围之内。