车载obd行车状态检测设备与系统后台的通信技术方案的制作方法

车载obd行车状态检测设备与系统后台的通信技术方案的制作方法
【技术领域】
[0001]本发明涉及到汽车电子领域的车载OBD诊断接口及其相关设备的设计与制造。
【背景技术】
[0002]随着人们生活水平的提高，车辆已经逐渐成为了广大城市、农村居民必不可少的出行交通工具。然而，车辆日常运行损耗累积到一定程度，可能会导致车辆高速行驶过程的故障，致使无法正常行驶、甚至造成重大的交通事故，给人们带来财产或生命的损失，严重影响当事人接下来的生活。因此，如何实时监测车辆运行状态数据，并根据历史数据对车辆状态进行综合评估，以便广大车主及时对进行车辆维修、日常保养，防患于未然，显得很有必要。当前极少数的高价位高档车辆在出厂时，虽然具有内置的车辆状态数据实时跟装置，但也仅于汽车厂家的售后服务功能，车辆状态实时获取功能较差，还无法满足车主对车身状况的及时把控。此外，其他广大车主仍在对车辆状态盲然不知的情况下驾车行驶，隐藏着巨大安全隐患。
[0003]目前，车辆0BD(0n Board Diagrams，0BD)诊断接口是获得车辆内置状态监测数据的唯一途径，该接口是汽车工业的行业标准，用于汽车维修过程的汽车故障检测。实际上，任何实现汽车OBD接口标准的设备均可通过OBD接口向车辆的行车电脑(ElectronicControl Unit，E⑶)查询其监测到的车辆状态数据。很显然，汽车OBD设备获得的大量数据，又需要持久性、不间断地保存到一个存储器上，以便车主查询历史的监测数据。随着大规模数据存储技术和服务器集群技术的发展，云存储成了数据持久性、不间断保存的技术方案。当前，基于手机通信技术和Wifi的移动网络技术，推动了移动互联网时代的到来，使得人们随时随地可对网络资源的获取和共享成了可能，也使得数据监测设备可以将其监测的数据实时地发送到系统后台，存储在云端数据服务器上，实现多种移动终端设备的数据共享和服务。在云储存计算背景下，移动互联网技术的成熟会对汽车监测数据的云端存储、分析、共享产生巨大推动作用。
[0004]因此，近年来，基于车载OBD接口的各种车辆状态检测设备大量的涌现，但其与系统后台之间缺乏统一的通信接口，导致不同OBD设备厂家之间的设备互不兼容，系统后台无法同时与多种OBD设备之间进行通信，额外增加了实际中的费用开销。当前云存储、移动互联时代下，本发明提出了系统后台与OBD汽车状态检测设备通信的技术方案，该方案综合考虑了系统后台与OBD设备检测设备之间的消息收发特点，实现简单高效，并具有统一的通信接口，便于不同厂家OBD设备与系统后台之间的兼容性。

【发明内容】

[0005]本发明提出了系统后台与OBD车辆状态检测设备通信的技术方案，采用了消息事件机制，实现OBD车辆状态检测设备与系统后台之间的统一接口。
[0006]本发明定义了设备与系统后台之间的数据交换格式，设备接收到的数据是一些设备配置数据以及其他的操作指令，其数据格式定义，如图1所示。
[0007]其中数据类型为8位二进制数据，其中最高位表示是否返回指令的执行结果，其余7位标识数据的类别。若数据类型的最高位是1，则数据部分的前I个字节为系统后台指令的标识码，该标识码是一个随机数，从而数据长度-1是系统后台指令执行结果的数据长度。
[0008]而设备向后台发送数据的格式如图2所示，其中数据类型为8位二进制数据，其中最高位表示是否系统后台指令的执行结果，其余7位标识数据的类别。若数据类型的最高位是1，则数据部分的前I个字节为系统后台指令的标识码，该标识码是一个随机数，从而数据长度-1是系统后台指令执行结果的数据长度。
[0009]本发明所述的系统后台与OBD设备之间的通讯方案，包括“注册设备”、“发送数据”、“接收数据”，“防吊保持”等部分，现在分述如下:
[0010]⑴注册设备
[0011]本发明所述车载OBD行车状态检测设备系统注册的处理流程如图3所示，按以下的三个步骤执行。
[0012]第一步:设备加电启动后，将主动连接系统后台的服务地址，并将设备标识发送到系统后台。
[0013]第二步:系统后台，对设备身份进行验证。若验证通过维持TCP连接，否则断开建立的TCP连接。
[0014]第三步:设备注册完成。
[0015]⑵接收数据
[0016]本发明所述车载OBD行车状态检测设备接收数据的处理流程如图4所示，即按以下的几个步骤执行。
[0017]第一步:当设备检测到通信模块产生的数据达到中断信号后，主控芯片执行相应的中断处理函数。
[0018]第二步:在主控芯片的中断处理函数中，调用数据接收函数，将通信模块接收到数据保存到接收数据缓冲区。
[0019]第三步:由接收数据缓冲区第二个字节的值，获得有效数据的长度。
[0020]第三步:判断接收数据缓冲第一个节字的最高位是否为I。若为1，则读取接收数据缓冲的第三个字节数据，将其保存成系统指令代码变量的值，以便将返回些次指令的执行结果，再从接收缓冲区中从第四个字节及其以后余下的字节中读取接收的数据。否则，直接从接收缓冲区中第三个字节及其以后余下的字节中读取接收的数据。
[0021]第四步:忽略接收数据缓冲第一个字节的最高位，判断接收数据的类型。
[0022]第五步:根据接收的数据类型及其数据，执行相应的操作。
[0023]第六步:接收数据完成。
[0024](3)发送数据
[0025]本发明所述设备向系统后台发送数据，其执行流程如图5，需经过以下几个步骤完成发送数据帧的封装和发送。
[0026]第一步:确定发送数据的类型，设置数据发送缓冲中第一个字节，即数据类型字节相应的值。
[0027]第二步:检查要发送的数据是否系统后台指令的返回数据。
[0028]第三步:若要发送的数据是系统后台指令的返回数据，则设置数据类型字节最高位的值为1，并将系统后台指令代码拷贝到发送数据缓冲的第三个节字，再将要发送的数据拷贝到余下的发送数据缓冲中。否则，将数据类型字节的最高位设置为0，并把要发送的数据直接拷贝到发送数据缓冲的第三个字节及其以后的字节中。
[0029]第四步:计算发送数据数据缓冲中数据位的长度，并将长度值保存到数据发送缓冲的第二个字节中，完成发送数据帧的封装。
[0030]第五步:调用数据发送函数，将封装好的发送数据帧发送到系统后台。
[0031]第六步:发送数据完成。
[0032](4)防吊保持
[0033]本发明所涉及的车载OBD行车状态检测设备，在正常工作中需要定时向系统后台发送防吊消息，来维持连接的活动状态。防吊数据的帧结构是设备发送数据帧的特殊形式，是一个仅包含数据类型字节的数据，其封装步骤如下:
[0034]第一步:设置一个字节大小的防吊数据发送缓冲区。
[0035]第二步:将防吊数 据类型的值拷贝到防吊数据的发送缓冲区。
[0036]第三步:调用数据发送函数，将防吊数据发送给系统后台。
[0037]第四步:计时定时器开始工作，在定时中断产生时，回到步骤一，重新发送新的防吊消息。
【附图说明】
[0038]图1设备接收数据的格式
[0039]图2设备发送数据的格式、
[0040]图3车载OBD行车状态检测设备的注册流程
[0041]图4车载OBD行车状态检测设备的接收数据流程
[0042]图5车载OBD行车状态检测设备的发送数据流程
[0043]图6本发明适用的汽车OBD状态检测设备
[0044]图7车载OBD行车状态检测设备与系统后台的通信固件模块
【具体实施方式】
[0045]本发明所涉及到系统后台适用于具有固定IP且处于公网中的服务器，而其适用的OBD车辆行车状态检测设备，如图6所示，主要将定位数据、加速度数据、汽车诊断数据及其他反馈给后台的数据，定期或实时地发送到系统后台。同时，设备还会接收系统后台发送的操作指令，完成特定操作，将相应的操作结果反馈到系统后台。
[0046]整个汽车OBD检测设备由以下几个部分组成，即:
[0047](I)定位模块
[0048]实际中，定位模块完成车辆当前地理位置信息的获取，OBD设备的主控模块主动获得实时的位置信息。这里，定位模块的具体实现细节没有限制，可以是使用广泛的GBlox芯片，也可是北斗卫星定位芯片。
[0049](2)无线通信模块
[0050]在车载环境中，无线通信模块多指基于3G、4G技术的移动通信技术，以及短距离的Wifi模块，但不包括基于蓝牙的通信芯片。OBD设备主控通过它可实现与系统后台基于IP协议的通信。
[0051](3)陀螺仪模块
[0052]作为车辆行车过程中的异常行驶状态检测部件，陀螺仪可获得驾驶员的驾驶习惯数据数据，实际中多采用6轴陀螺仪。
[0053](4) OBD协议解析模块
[0054]该模块用于汽车OBD接口的数据格式解析，可以是市面上专门的OBD协议解析芯片，也可是OBD设备主控中实现汽车OBD数据格式解析的程序模块。
[0055](5) OBD设备主控芯片
[0056]该芯片是整个OBD设备的数据采集和控制中心，负责与系统后台之间的交互，将采集到数据数据及时地发送到系统后台，并可车辆状态的异常变化推送到用户前端。
[0057]本发明所述的通讯技术方案，其本质上一个车载OBD行车状态检测设备与系统后台之间通讯的协议，实际中需将其实现成固件程序，烧写到嵌入式车载OBD行车检测设备的存储器中，是整个设备与系统后台数据交换的中枢。具体实施步骤为:
[0058]第一步:定义车载OBD行车状态检测设备需要发送的数据类型。设备需要发送的数据有“定位数据(001)”、“陀螺仪数据(002)”、“定期OBD检测的数据(003)”、“0BD检测指令的执行结果数据(004)”、“设备故障数据(005)”、“设备连接防吊数据(006)”等，其中括号内的三位数是相应数据类型的代码。
[0059]第二步:定义设备接收数据的类型，包括“配置信息(001)”、“0BD操作指令
(002)”、“主控操作指令(003) ”等等。
[0060]第三步:实现通信协议固件，其功能组成模块为，如图7所示。:
[0061]第四步:将步骤三中实现的协议田固件烧写到嵌入式主控芯片的存储器，设备开机将加载该通信协议固件，建立与系统后台之间的通信连接，实现设备与系统后台之间的交互。
[0062]第五步:本发明所述的通信方案实施完成。
[0063]通过上述实例说明了本发明所述的通信技术方案实施步骤，但不限于该实施案例，可视具体的设备功能及数据交换类型，自定义数据类型及其编码。凡在本发明所述的通信技术方案所实现的设备与系统后台的通信协议固件，均在本发明的保护范围之内。
【主权项】
1.一种用于车载OBD行车状态检测设备与系统后台的数据通信技术方案，包括接收数据帧的定义、发送数据帧的定义、设备注册、防吊维持连接、发送数据和接收数据的执行流程等，其中接收数据帧和发送数据帧的定义用于约定设备与系统后台的数据通信格式，是整个通信技术方案的基础。2.如权利I中所述的接收数据帧，其特征在于，接收数据帧有三部分组成，即I个字节的数据类型字段、I个字节的数据长度字段、长度可变的数据字段。3.如权利I中所述的发送数据帧，其特征在于，发送数据帧有三部分组成，即I个字节的数据类型字段、I个字节的数据长度字段、长度可变的数据字段。4.如权利2所述的数据类型字段，其特征在于，其最高位的值表示接收到系统后台指令是否需要返回数据。若为1，设备需要将系统后台指令的执行结果返回给系统后台，并且需要设备保存系统后台指令的标识码。5.如权利3所述的数据类型字段，其特征在于，其最高位的值表示发送数据是否系统后台指令的执行结果。若为1，设备需要将系统后台指令的标识码及其执行结果作为数据发送到系统后台。6.如权利I所述的设备注册流程，其特征在于，设备注册过程分三步骤完成，其中设备与系统后台建立通信连接后，设备需要把其序列号作为数据发送到系统后台，系统后台再将其设备序列的验证结果返回给设备。7.如权利I所述的接收数据流程，其特征在于，接收数据的解析过程依照权利2所述的接收数据帧的格式。8.如权利I所述的发送数据流程，其特征在于，发送数据帖的封装过程，依照权利3所述的发送数据帧的格式。9.如权利I所述的防吊维持连接，其特征在于，防吊数据的格式是权利3所述的发送数据帧格式的特殊情况，仅包含I个字节大小的数据类型字段。
【专利摘要】本发明针对当前不同厂家的车载OBD行车状态检测设备与系统后台接口不统一的情况，提出了一种车载OBD设备与系统后台之间的通信方案。该方案由设备的接收数据帧定义、发送数据帧定义、以及设备与系统后台之间的交互流程等组成，其中接收数据帧和发送数据帧具有一致的帧结构，包含1个字节的数据类型字段、1个字节的数据长度字段和长度可变的数据字段。接收数据帧和发送数据帧的主要区别在于它们的数据类型定义不同。基于定义的接收数据帧和发送数据帧，本发明设计了设备与系统后台交瓦的操作流程，如设备注册、发送数据、接收数据、设备维护连接的防吊维持等操作。在实际中，本发明所述的通信技术方案需要实现为通信协议栈固件程序，烧写到嵌入式车载OBD设备主控芯片的存储器中，是设备与系统后台通信的核心。
【IPC分类】G05B23/02
【公开号】CN104881021
【申请号】CN201510205010
【发明人】卢照敢, 冯吉春, 丁岩磊, 张兰坤
【申请人】河南艾伊赛特电子科技有限公司
【公开日】2015年9月2日
【申请日】2015年4月28日