CN109895712A - 通过串口读取obd设备的汽车信息并进行展示的方法 - Google Patents

Abstract

本发明提供一种通过串口读取OBD设备的汽车信息并进行展示的方法，应用于包括OBD设备、车机系统、安装于车机系统的车机系统应用程序、后台服务器和安装于客户端的客户端小程序的系统中；客户端小程序根据用户输入的指令，向后台服务器发送与用户唯一标识UUID对应的指定汽车信息获取请求；客户端小程序将接收到的指定汽车信息进行界面展示。优点为：(1)能够确保实时采集OBD的信息，对于采集到的OBD设备信息，除了传给后台服务器进行过滤，校验，解析，存储外，还会进行二次数据加工，得到更多的的信息。(2)采用客户端小程序的方式展示数据，只要用户安装客户端，随时可通过客户端小程序查看车辆状况信息，方便用户使用。

Description

通过串口读取OBD设备的汽车信息并进行展示的方法

技术领域

本发明属于汽车信息获取及展示技术领域，具体涉及一种通过串口读取OBD设备的汽车信息并进行展示的方法。

背景技术

现在越来越多的汽车车机厂商采用Android系统来设计车机系统，使用Android系统不仅仅因为它是个开放的系统，成本很低，还在于现在Android系统在手机设备上非常普及，使它在开发各种应用程序时非常的方便，快捷，而且稳定性，操作性都非常的好，车机系统可以很方便给用户展示各种信息。而汽车本身自带的仪表，仪器展示给用户的信息量却很少，这样车机系统就可以弥补这一部分的缺陷。比如，汽车缺油了，可以通过仪表展示给用户。但是如果汽车出现其它问题呢？比如水箱缺水等，因为它有上百个故障码，这些故障一旦发生，目前的车机系统由于缺少一个合适的展示平台，也很难及时通知给用户。再比如，目前的车机系统仅能向用户展示原始运行数据，如果用户需要了解每次行程的公里数，油耗，平均速度，刹车次数等等信息，用户只能根据原始运行数据自行计算才可以得到这些信息，对于用户来说非常不方便。还有，如果用户需要知道当前汽车存在的隐含故障信息，以便及时做些保养和维修，目前的车机系统也无法满足此种需求。

因此，开发一种装置或方法，能够获取到汽车的各种状态信息，并且通过有效的手段及时通知给用户，将会显得很智能，也会使用户更喜欢购买带有这种设备的汽车。公开号为CN106027605A，名称为“车辆状态数据处理装置”的发明申请中，公开了一种车辆状态数据收集和显示车辆状态的方法，内容如下“本发明实施例公开一种车辆状态数据处理装置，数据接入模块通过TCP传输协议接收OBD设备上报的车辆数据消息，对车辆数据进行节流缓存；按照协议规则确定车辆数据消息长度，根据车辆数据消息长度截取缓存的车辆数据消息中数据包；将截取后的数据包进行协议适配，确定匹配的接入协议；对数据包中数据进行解析，将数据由字节流转换为协议数据实体，得到解析后的数据，根据接入协议，将解析后的数据转换为原始数据，将原始数据携带于原始数据消息队列中传输至所述传输控制模块；传输控制模块接收原始数据，应用业务算法对原始数据处理后，发送到数据展示模块；数据展示模块根据原始数据确定车辆状态，并显示车辆状态。”本专利申请主要可以概括为：通过TCP传输协议接收OBD设备上报的车辆数据，按照协议进行解析，最后将解析后的原始数据，通过传输模块传递给数据展示模块，最终展示模块显示车辆状态。

上述专利申请记载的内容主要存在以下三个缺点：一是数据接入模块必须通过TCP协议才能和OBD设备相连接，但是基于TCP/IP协议的传输方式需要进行较为复杂的握手过程，并且需要耗费用户较多的通信流量，传输过程较为复杂，如果信号不好，很难实时采集到OBD的信息；二是数据接入模块和传输控制模块虽然有对数据进行解析的过程，但并没有进行一些二次加工处理，这样有些有用的信息无法获取到。比如，如果需要获得上次行程信息，包括行程里程，刹车次数，行程开始，结束时间等，只通过读取解析OBD数据是无法获取到的；三是采用订阅通知的方式展示给用户，用户很可能无法方便的获取到。因为展示应用的程序往往安装在车机系统上，用户如果没有在汽车里，就无法获取到这些信息。

通过读取OBD设备信息，然后将其存储到服务器端，在使用的时候通过移动终端展示给用户也是一种不错的方式。公开号为CN103095799A，名称为“车载诊断数据通信系统”的发明申请中，公开了一种将OBD设备，服务器和移动终端结合使用的方式，内容如下：“本发明提供一种车载诊断数据通信系统，包括车载诊断OBD设备、服务器、及移动终端，其中OBD设备通过车辆提供的OBD，端口与车载电脑ECU连接，用于通过OBD端口读取车辆状态数据并通过第一移动通信网络发送至服务器；服务器用于接收OBD设备发送的车辆状态数据并转换成预定格式信息以通过第二移动通信网络发送至移动终端；移动终端用于接收服务器发送的预定格式信息并根据该预定格式信息获知车辆的状态。本发明提供的车载诊断数据通信系统可以不受距离的限制而实现即时通信，并且读取的车辆状态信息将更为准确、种类更多，相应也能实现更多的应用功能。”主要可以概括为：通过车辆提供的OBD设备读取车辆状态，然后发送给服务器，服务器接收数据后，将其转换成预定义格式信息，再发送给移动端，移动端最后再将信息展示给用户。

上述专利申请记载的内容主要存在以下三个缺点：一是本发明通过OBD端口读取车辆状态数据，并未指出采用具体的何种方式或协议来读取数据；二是服务器接收OBD设备发送的车辆状态数据后，只是转换成预定格式信息，并没有进行二次加工，这样一些深层次的数据信息无法得到，比如，上次行程信息，制动次数，每次行程的油耗信息等等，这些仅仅读取OBD数据是无法获取到的；三是用移动终端进行信息展示，但未提到详细的展示方式，并且这种展示方式也仅限于车机系统的应用程序，不能在脱离汽车车机系统的情况下继续查询汽车的状态信息，即使是一个可以脱离车机系统应用程序，但用户不一定很容易获取到，或者愿意在自己的手机上安装这样的应用程序。

发明内容

针对现有技术存在的缺陷，本发明提供一种通过串口读取OBD设备的汽车信息并进行展示的方法，可有效解决上述问题。

本发明采用的技术方案如下：

本发明提供一种通过串口读取OBD设备的汽车信息并进行展示的方法，应用于包括OBD设备、车机系统、安装于车机系统的车机系统应用程序、后台服务器和安装于客户端的客户端小程序的系统中；

通过串口读取OBD设备的汽车信息并进行展示的方法包括以下步骤：

步骤1，当汽车发动机启动时，同步触发启动所述车机系统和所述OBD设备；所述OBD设备获取并实时存储汽车信息；其中，所述汽车信息包括汽车故障码信息和汽车运行基本信息；

当所述车机系统启动时，根据预设定的OBD设备的串口名称和串口读写波特率，通过对应的串口与所述OBD设备相连接；

步骤2，所述车机系统启动运行于所述车机系统的车机系统应用程序；所述车机系统应用程序按照所述串口读写波特率，持续通过所述串口向所述OBD设备发送读取指定汽车信息的请求指令；并持续接收所述OBD设备返回的指定汽车信息的响应指令；

步骤3，所述车机系统应用程序对持续接收到的所述OBD设备返回的指定汽车信息的响应指令进行校验和解析，确定该响应指令所对应的请求指令，然后根据所述OBD设备对应的指令协议类型，过滤掉无用的信息，筛选出有效响应指令，再从所述有效响应指令中解析到有效汽车信息；

步骤4，所述车机系统应用程序调用后台服务器提供的服务接口，通过所述服务接口，接收所述后台服务器传递的用于区分不同车机系统的用户唯一标识UUID；

然后，所述车机系统应用程序将携带所述用户唯一标识UUID的有效汽车信息上报给所述后台服务器；

步骤5，所述后台服务器接收到携带所述用户唯一标识UUID的有效汽车信息后，解析出所述用户唯一标识UUID以及所述有效汽车信息，并根据所述用户唯一标识UUID，将属于同一个用户唯一标识UUID的所有有效汽车信息写入到数据库；

步骤6，对于每个已注册的客户端小程序，均通过所述后台服务器的接口获得对应的用户唯一标识UUID；然后，利用所述用户唯一标识UUID生成与指定车机系统对应的二维码图片，并将所述二维码图片传输给对应的车机系统的车机系统应用程序；所述车机系统应用程序本地保存对应的所述二维码图片；并通过界面展示所述二维码图片；

所述客户端扫描所述二维码图片，在扫描过程中，向所述后台服务器发送访问二维码图片的请求；所述后台服务器接收到所述访问二维码图片的请求后，对所述访问二维码图片的请求进行解析，得到对应的用户唯一标识UUID，然后，触发所述客户端运行与所述用户唯一标识UUID对应的所述客户端小程序；

步骤7，所述客户端小程序根据用户输入的指令，向所述后台服务器发送与所述用户唯一标识UUID对应的指定汽车信息获取请求；

所述后台服务器接收到所述指定汽车信息获取请求后，判断是否可直接通过查找所述数据库获取，如果可以，则直接从所述数据库读取到对应的指定汽车信息，并返回给所述客户端小程序；

如果不可以，则所述后台服务器启动服务器端实时计算模块，通过所述服务器端实时计算模块，对所述数据库中的相关信息进行二次加工计算，得到指定汽车信息，并返回给所述客户端小程序；

步骤8，所述客户端小程序将接收到的所述指定汽车信息进行界面展示。

优选的，步骤1中，所述OBD设备获取并实时存储的汽车信息，包括汽车故障码信息以及汽车运行状态信息。

优选的，步骤2具体为：

步骤2.1，在所述车机系统应用程序中首先创建一个Service服务进程；在启动运行于所述车机系统的车机系统应用程序时，启动所述Service服务进程；其中，所述Service服务进程和所述车机系统应用程序运行于同一进程，或者，所述Service服务进程为一个独立的进程；

步骤2.2，当所述Service服务进程被启动时，所述Service服务进程根据预设定的OBD设备的串口名称和串口读写波特率，打开OBD设备对应的串口，为读写OBD设备做准备；

所述Service服务进程判断OBD设备对应的串口是否被成功打开，如果串口打开失败，则向所述车机系统返回串口打开失败的提示信息，然后通过重启服务的方式，重新打开串口；如果串口打开成功，执行步骤2.3；

步骤2.3，所述Service服务进程启动后，在后台一直保持运行状态；当所述串口打开成功后，所述Service服务进程同时启动一个无限循环的写串口的指令线程和一个无限循环的读取串口返回指令的线程；

对于所述无限循环的写串口的指令线程，通过以下步骤2.3.1-步骤2.3.5实现持续向OBD设备的串口写入读取指定汽车信息的指令：

步骤2.3.1，写串口的指令线程根据需求设定与获取指定汽车信息对应的指令内容以及指令发送频率；

步骤2.3.2，写串口的指令线程检测当前线程是否被打断，如果被打断，则执行步骤2.3.3；如果没有被打断，则执行步骤2.3.4；

步骤2.3.3，重新启动所述Service服务进程，当所述Service服务进程被重新启动时，重新启动所述写串口的指令线程，再返回执行步骤2.3.1；

步骤2.3.4，写串口的指令线程保持运行状态，根据对应的所述指令发送频率，持续向所述OBD设备的串口写入读取指定汽车信息的指令；其中，在每次向所述OBD设备的串口写入读取指定汽车信息的指令时，监控写入过程是否发生异常；如果发生异常，则返回步骤2.3.3；如果没有发生异常，则执行步骤2.3.5；

步骤2.3.5，在进行一次写入循环后，使所述写串口的指令线程暂停50毫秒，然后再返回步骤2.3.1；

对于所述无限循环的读取串口返回指令的线程通过以下步骤2-3-1-步骤2-3-4实现持续接收OBD设备的串口上报的指定汽车信息；

步骤2-3-1，OBD设备的串口检测读取串口返回指令的线程是否被打断，如果被打断，则执行步骤2-3-2；如果没有被打断，则执行步骤2-3-3；

步骤2-3-2，OBD设备的串口暂停向所述串口返回指令的线程上报指定汽车信息；并重新启动所述Service服务进程，当所述Service服务进程被重新启动时，重新启动所述读取串口返回指令的线程，再返回执行步骤2-3-1；

步骤2-3-3，OBD设备的串口持续向串口返回指令的线程上报指定汽车信息；

步骤2-3-4，串口返回指令的线程持续接收所述OBD设备通过串口上报的指定汽车信息。

本发明提供的通过串口读取OBD设备的汽车信息并进行展示的方法具有以下优点：

(1)采用本发明的方案，不会存在耗费用户较多的通信流量的情况，能够确保实时采集OBD的信息，。对于采集到的OBD设备信息，除了传给后台服务器进行过滤，校验，解析，存储外，还会进行二次数据加工，得到更多的用户想了解的信息。

(2)采用客户端小程序的方式展示数据，可以做到只要用户安装了对应客户端，随时都可以通过客户端小程序查看车辆的状况信息，方便用户使用。

附图说明

图1为本发明提供的通过串口读取OBD设备的汽车信息并进行展示的方法的整体流程示意图；

图2为本发明提供的服务器后台处理子流程的运行过程示意图；

图3为本发明提供的微信小程序展示子流程展示数据给用户的运行过程示意图。

具体实施方式

为了使本发明所解决的技术问题、技术方案及有益效果更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

本发明涉及到的缩略语和关键术语解释：

Android：中文名称为安卓，是一种基于Linux的自由及开放源代码的操作系统，主要用于移动设备，如智能手机和平板电脑，由Google公司和开放手机联盟领导及开发。

车机系统:车机指的是安装在汽车里面的车载信息娱乐产品的简称，车机在功能上要能够实现人与车，车与外界(车与车)的信息通讯。车机大多安装在中控台里面，有的车机主机和屏幕在一起，有的车机主机和屏幕分离。车机系统就是用来控制车机的操作系统，可以是linux，Android，目前最为流行的是Android系统。

OBD设备：OBD是英文On-Board Diagnostic的缩写，中文翻译为“车载诊断系统”。这个系统随时监控发动机的运行状况和尾气后处理系统的工作状态，一旦发现有可能引起排放超标的情况，会马上发出警示。当系统出现故障时，故障灯(MIL)或检查发动机(CheckEngine)警告灯亮，同时OBD系统会将故障信息存入存储器，通过标准的诊断仪器和诊断接口可以以故障码的形式读取相关信息。根据故障码的提示，维修人员能迅速准确地确定故障的性质和部位。

串口：串行接口简称串口，也称串行通信接口或串行通讯接口(通常指COM接口)，是采用串行通信方式的扩展接口。串行接口(Serial Interface)是指数据一位一位地顺序传送，其特点是通信线路简单，只要一对传输线就可以实现双向通信(可以直接利用电话线作为传输线)，从而大大降低了成本，特别适用于远距离通信，但传送速度较慢。

现有技术中，通过TCP协议和OBD设备相连接读取数据，需要进行较为复杂的握手过程，并且耗费用户较多的通信流量，传输过程较为复杂，如果信号不好，很难实时采集到OBD信息，而采用其它协议也或多或少存在同样的问题；对于读取到的OBD信息，可以直接展示给用户看的信息量还是比较少，如果仅仅是读取，然后上传服务器，再解析，从服务器读取，最后再展示，给用户带来的价值并不是很大；另外，如果用车机自带的应用程序展示给用户结果，会有很多方面的限制，比如，只能在车机系统上查看车辆状态信息，很难获取到查看状态的应用，用户可能不乐意安装这样的应用，车辆状态信息不能及时获取等等问题。而本发明的目的就在于解决上述问题。采用本发明的方案，不会存在耗费用户较多的通信流量的情况，能够确保实时采集OBD的信息，因为此方案直接通过串口读取OBD设备中信息。对于采集到的OBD设备信息，除了传给后台服务器进行过滤，校验，解析，存储外，还会进行二次数据加工，这样可以得到更多的用户想了解的信息，比如，上次行程的相关信息，包括里程，起始时间，结束时间，油耗，刹车次数，急刹次数，慢刹车次数等信息。另外，采用客户端小程序的方式展示数据，可以做到只要用户安装了对应客户端，随时都可以通过客户端小程序查看车辆的状况信息，哪怕是别人在使用自己的汽车，都可以监控到汽车的使用情况。本发明中，客户端小程序包括但不限于微信小程序。

本发明设计和实现了一种通过串口读取OBD设备的汽车信息，然后利用客户端小程序展示汽车状况的方法。主要设计思路为：

OBD设备用于存储汽车信息，包括汽车故障码信息和汽车常用信息，其通过串口连接的方式连接到车机系统上。发明人首先开发一个运行于Android版的车机系统上的车机系统应用程序，车机系统应用程序可简称为app应用程序，然后，车机系统应用程序通过读串口数据的方式得到OBD中存储的汽车信息，接着，在车机系统应用程序端，根据OBD使用的协议对读取到的汽车信息分别进行处理，如，OBD使用CAN 500K协议或KWP2000协议，不同的协议使用不同的解析方法。

在本发明的车机系统应用程序中，首先会启动一个Service服务进程，然后在Service服务进程启动的时候将打开OBD设备对应的串口。在打开串口时，需要知道串口的名称和波特率，如串口名称为/dev/tty4，波特率为115200。如果打开串口失败，需要给用户一个合理的提示，然后可以重启服务，重新打开串口；如果打开串口成功，则可以启动一个无限循环的子线程Thread，包括一个无限循环的写串口的指令线程和一个无限循环的读取串口返回指令的线程，对于无限循环的写串口的指令线程，只要线程不被打断，就可以一直发送读取OBD数据的指令。而指令发送时间间隔、指令发送内容都可以按照需求进行设置。比如，对于读取汽车的故障码指令，设置指令发送时间间隔较长。原因为：因为汽车不可能在发生故障生成故障码后，短期内又发生了新的故障，所以没有必要非常频繁的读取故障码，可以设置成分钟级别的间隔时间，如，1分钟，3分钟或5分钟等等都可以。而有一些指令是用于记录数据实时变化情况的，因此，指令发送时间间隔非常短，如，每秒去读取一次OBD设备，比如，实时统计汽车的瞬时速度，那么就需要每秒种上报一次当前汽车的速度，这样才能及时准确的获取到汽车的瞬时速度。

在无限循环的写串口的指令线程发送读取OBD设备的指令时，需要将发送指令编码成协议要求的格式才能使OBD设备准确的接收到请求，一般指令都是以十六进制数字数组的方式来传递指令，如，CAN 500k协议中读取数据流的指令如下所示：

AA 55 00 0E FF E1 02 00 00 17 00 01 00 13 02 1B，

其中前两个字节AA 55是协议的特定写法，表示数据包标志；紧接着后面两个字节00 0E是数据包的长度，长度包括从第3个字节开始到校验和(倒数第2个字节)为止的所有字节数量；然后后面两个字节FF E1是上两个字节的取反操作得到的值；接下来一个字节02表示数据包ID值，ID值是一个指令执行顺序的表示值,比如第一条指令ID为1，第二条指令ID就应该是2，依次类推；下一个字节00是一个保留字节，暂时没有作用；下两个字节00 17表示一个读取数据流的命令字；00 01表示需读取的数据流个数，由数值为01可知只读取1个数据流；后面两个字节00 13表示数据流的类型，通过查询协议，得到十六进制13表示的是瞬时车速的一个数据流；最后两个字节02 1B表示校验和，表示从数据包长度(即第3个字节)开始至全部数据内容结束止的所有字节产生的累加之和。

以上就是一个发送读取汽车瞬时速度的指令，我们需要在车机系统应用程序中通过程序的方式将其构造出来，然后通过写串口指令，将其写入OBD设备对应的串口中，这样就完成了一次指令发送。而其它指令也是采用相同的方法进行构建和发送。

在将此指令发送给OBD设备后，OBD设备会返回类似以下格式的指令，如，返回读取瞬时车速结果的指令为，

AA 55 00 21 FF DE 30 00 00 17 00 01 31 32 2E 32 00 06 7A

它的解析方式和生成指令的解析方式类似，不同的字节代表着不同的含义，有用的信息就包含在这些字节中。Service服务将通过以上介绍的相同方法将该指令包含的信息解析出来。

在Service服务中，对收到的OBD设备返回的指令经过解析后，过滤出有用的数据，然后将其转换成UTF-8格式的字符串数据，接着使用后台服务器提供的http接口将数据上报给后台服务器。在上报数据时，会在连接前通过接口，首先获取到后台服务器传递过来的一个用户唯一标识UUID，它用来区不同的车机系统，进而区分不同的汽车，每次上报的数据需要携带这个UUID信息。服务器收到车机系统应用程序上报的数据后，会根据不同的UUID来区分不同的汽车，从而保证每台汽车都有自己独有的数据。

后台服务器会对收集到的数据进行实时计算，然后将计算结果及时返回给用户。比如，如果用户想知道上次行程的车程距离，则通过客户端小程序的方式给用户展示信息。客户端小程序会使用后台服务器提供的接口来请求数据，后台服务器收到请求后，将到数据库中查询最近一次发动机熄灭时和最近一次发送机启动时的信息，当然发动机熄灭的时间必须大于启动的时间，启动和熄灭之间将表示一次完整的行程，这个时间段内的数据就是一次行程的数据。由发动机熄灭时的总里程数S1和启动时的总里程S2，通过S1减去S2就可以得到这次行程的距离为S1-S2。再比如，如果想计算上次行程中的刹车次数，通过上次行程中每秒统计上来的瞬时速度就可以得到，比如第一秒的速度为V1，第三秒的速度为V2，如果V1-V2大于10KM/H，就表示一次紧急刹车。因为刹车是这样定义的，上次车速和本次车速速度差为10KM/H，并且持续为2秒以上就可以看做一次紧急刹车。通过以上类似的方法，由后台服务器对数据进行二次加工处理后，将数据升级为对用户来说更有用的数据，然后再传递给客户端小程序，客户端小程序通过界面展示给用户，使用户可以及时获取到更多更有价值的信息，而不仅仅是从OBD设备上读取到的表面的故障码信息。

本发明通过客户端小程序展示给用户汽车信息，为方便理解和说明，下面以客户端小程序为微信小程序为例，介绍微信小程序关联到某个汽车的方法。通过以下方式保证某个用户安装的微信小程序从后台服务器获取的汽车信息，就是该用户汽车的汽车信息，而不是其他人的汽车信息：

这要从之前车机系统应用程序向后台服务器上报数据时使用的UUID说起，这个UUID关联到具体的某个汽车，在后台开发微信小程序时，需要用户到微信公众平台上进行注册，注册成功后，可以通过后台服务器提供的接口获取到一个用户唯一标识UUID，然后由微信公众平台提供的接口，利用这个UUID生成一个针对这台汽车的一个二维码图片，拿到这个二维码图片后，将其提供给车机系统应用程序。

车机系统应用程序通过后台接口可以获取到这个二维码图片，然后利用界面展示给用户，用户再通过微信二维码扫描程序，扫描此二维码图片，就可以打开对应的微信小程序。此时这个二维码图片包含的信息中就有用于区分汽车身份的UUID，这样用户就能通过微信小程序获得当前汽车的状态信息。

具体的，本发明提供一种通过串口读取OBD设备的汽车信息并进行展示的方法，应用于包括OBD设备、车机系统、安装于车机系统的车机系统应用程序、后台服务器和安装于客户端的客户端小程序的系统中；

通过串口读取OBD设备的汽车信息并进行展示的方法包括以下步骤：

步骤1，当汽车发动机启动时，同步触发启动所述车机系统和所述OBD设备；所述OBD设备获取并实时存储汽车信息；其中，所述汽车信息包括汽车故障码信息和汽车运行基本信息；所述OBD设备获取并实时存储的汽车信息，包括汽车故障码信息以及汽车运行状态信息。

当所述车机系统启动时，根据预设定的OBD设备的串口名称和串口读写波特率，通过对应的串口与所述OBD设备相连接；

步骤2，所述车机系统启动运行于所述车机系统的车机系统应用程序；所述车机系统应用程序按照所述串口读写波特率，持续通过所述串口向所述OBD设备发送读取指定汽车信息的请求指令；并持续接收所述OBD设备返回的指定汽车信息的响应指令；

步骤2具体为：

步骤2.1，在所述车机系统应用程序中首先创建一个Service服务进程；在启动运行于所述车机系统的车机系统应用程序时，启动所述Service服务进程；其中，所述Service服务进程和所述车机系统应用程序运行于同一进程，或者，所述Service服务进程为一个独立的进程；

步骤2.2，当所述Service服务进程被启动时，所述Service服务进程根据预设定的OBD设备的串口名称和串口读写波特率，打开OBD设备对应的串口，为读写OBD设备做准备；

所述Service服务进程判断OBD设备对应的串口是否被成功打开，如果串口打开失败，则向所述车机系统返回串口打开失败的提示信息，然后通过重启服务的方式，重新打开串口；如果串口打开成功，执行步骤2.3；

步骤2.3，所述Service服务进程启动后，在后台一直保持运行状态；当所述串口打开成功后，所述Service服务进程同时启动一个无限循环的写串口的指令线程和一个无限循环的读取串口返回指令的线程；

对于所述无限循环的写串口的指令线程，通过以下步骤2.3.1-步骤2.3.5实现持续向OBD设备的串口写入读取指定汽车信息的指令：

步骤2.3.1，写串口的指令线程根据需求设定与获取指定汽车信息对应的指令内容以及指令发送频率；

步骤2.3.2，写串口的指令线程检测当前线程是否被打断，如果被打断，则执行步骤2.3.3；如果没有被打断，则执行步骤2.3.4；

步骤2.3.3，重新启动所述Service服务进程，当所述Service服务进程被重新启动时，重新启动所述写串口的指令线程，再返回执行步骤2.3.1；

步骤2.3.4，写串口的指令线程保持运行状态，根据对应的所述指令发送频率，持续向所述OBD设备的串口写入读取指定汽车信息的指令；其中，在每次向所述OBD设备的串口写入读取指定汽车信息的指令时，监控写入过程是否发生异常；如果发生异常，则返回步骤2.3.3；如果没有发生异常，则执行步骤2.3.5；

步骤2.3.5，在进行一次写入循环后，使所述写串口的指令线程暂停50毫秒，然后再返回步骤2.3.1；

对于所述无限循环的读取串口返回指令的线程通过以下步骤2-3-1-步骤2-3-4实现持续接收OBD设备的串口上报的指定汽车信息；

步骤2-3-1，OBD设备的串口检测读取串口返回指令的线程是否被打断，如果被打断，则执行步骤2-3-2；如果没有被打断，则执行步骤2-3-3；

步骤2-3-2，OBD设备的串口暂停向所述串口返回指令的线程上报指定汽车信息；并重新启动所述Service服务进程，当所述Service服务进程被重新启动时，重新启动所述读取串口返回指令的线程，再返回执行步骤2-3-1；

步骤2-3-3，OBD设备的串口持续向串口返回指令的线程上报指定汽车信息；

步骤2-3-4，串口返回指令的线程持续接收所述OBD设备通过串口上报的指定汽车信息。

步骤3，所述车机系统应用程序对持续接收到的所述OBD设备返回的指定汽车信息的响应指令进行校验和解析，确定该响应指令所对应的请求指令，然后根据所述OBD设备对应的指令协议类型，过滤掉无用的信息，筛选出有效响应指令，再从所述有效响应指令中解析到有效汽车信息；

步骤4，所述车机系统应用程序调用后台服务器提供的服务接口，通过所述服务接口，接收所述后台服务器传递的用于区分不同车机系统的用户唯一标识UUID；

然后，所述车机系统应用程序将携带所述用户唯一标识UUID的有效汽车信息上报给所述后台服务器；

步骤5，所述后台服务器接收到携带所述用户唯一标识UUID的有效汽车信息后，解析出所述用户唯一标识UUID以及所述有效汽车信息，并根据所述用户唯一标识UUID，将属于同一个用户唯一标识UUID的所有有效汽车信息写入到数据库；

步骤6，对于每个已注册的客户端小程序，均通过所述后台服务器的接口获得对应的用户唯一标识UUID；然后，利用所述用户唯一标识UUID生成与指定车机系统对应的二维码图片，并将所述二维码图片传输给对应的车机系统的车机系统应用程序；所述车机系统应用程序本地保存对应的所述二维码图片；并通过界面展示所述二维码图片；

所述客户端扫描所述二维码图片，在扫描过程中，向所述后台服务器发送访问二维码图片的请求；所述后台服务器接收到所述访问二维码图片的请求后，对所述访问二维码图片的请求进行解析，得到对应的用户唯一标识UUID，然后，触发所述客户端运行与所述用户唯一标识UUID对应的所述客户端小程序；

步骤7，所述客户端小程序根据用户输入的指令，向所述后台服务器发送与所述用户唯一标识UUID对应的指定汽车信息获取请求；

所述后台服务器接收到所述指定汽车信息获取请求后，判断是否可直接通过查找所述数据库获取，如果可以，则直接从所述数据库读取到对应的指定汽车信息，并返回给所述客户端小程序；

如果不可以，则所述后台服务器启动服务器端实时计算模块，通过所述服务器端实时计算模块，对所述数据库中的相关信息进行二次加工计算，得到指定汽车信息，并返回给所述客户端小程序；

步骤8，所述客户端小程序将接收到的所述指定汽车信息进行界面展示。

下面以客户端小程序为微信小程序、安装于车机系统的车机系统应用程序简称为app应用程序为例，介绍一个具体实施例：

本实施例提供了详细的通过串口读取OBD设备的汽车信息，然后利用微信小程序展示汽车状况的方法，如示例图1，其实现的步骤如下：

S101、开始：

本发明将涉及到若干个设备或者系统，包括：布置于汽车的OBD设备，汽车的车机系统，以及安装在车机系统的app应用程序，后台服务器，微信小程序等几个部分。首先从汽车发动机启动开始，车机系统开始工作，然后由车机系统的app应用程序开始收集OBD设备存储的汽车状况信息。

S102、车机系统启动：

汽车启动会导致车机系统启动。车机系统是非常重要的一个环节，用来连接OBD设备，并且是app应用程序的载体。车机系统和OBD设备通过串口相连接，在出厂时规定这个串口名称以及读写的波特率。本发明假设此串口为/dev/tty4，波特率为115200，那么在读写串口时，需要指定串口的名称为/dev/tty4，访问的数据的波特率必须为115200，否则就会读写失败。

S103、启动一个Android的app应用程序，在app应用程序中创建一个Service服务进程：

本发明涉及的车机系统必须为Android系统，在此车机系统上需要预先开发一个app应用程序，这个车机负责读取OBD设备信息，并且上报给后台服务器，同时用于展示提供给微信要扫描的二维码图片。在app应用程序中会首先创建一个Service服务进程，用它来读写OBD设备的信息，并由它来完成信息的上报。

Service是Android四大组件之一，运行在后台，一些非界面操作的工作都可以放到Service中执行，一旦启动它会一直在后台运行。它可以和app应用程序运行于同一进程，也可以是一个独立的进程，此发明中把它放到一个独立进程中，只需要在app应用程序的AndroidManifest.xml配置文件中设置一下android:process的值即可。如，android:process＝"com.demo.test.service",设置此Service为独立进程，并且进程名称为com.demo.test.service。

S104、在Service服务进程创建时打开OBD设备对应的串口：

Service作为独立进程启动后，就会一直运行，可以在其创建时同时打开OBD设备对应的串口，为读写OBD设备做准备。

S105、Service服务进程在后台一直保持运行，同时启动一个写串口的指令线程和一个读取串口返回指令的线程：

Service进程启动后，会在后台一直保持运行状态。它先后启动了一个写串口的指令线程和一个读取串口返回指令的线程。

获取OBD设备的汽车状态信息的过程是这样的：写串口的指令线程首先发送给OBD设备一个请求指令，也就是往OBD中写入一个指令，比如，读取故障码，写入成功后，OBD会返回一个响应指令，这个指令会返回到串口对应的输出文件句柄中，app应用程序需要从这个文件句柄中将返回值读取出来，才能得到请求的故障码信息。所以写串口的指令线程是不断给OBD发请求，而读取串口的线程是不断从串口中得到对应的响应结果。

S106、写串口的指令线程保持无限循环运行状态：

在写串口的线程thread中，通过运行语句while(！thread.isInterrupted))，只要收不到线程被打断的命令，即thread.isInterrupted一直为false，就可以使写串口的指令线程保持无限循环运行状态，这样就可以一直和OBD设备保持通信。

S107、读串口的指令线程保持无限循环运行状态：

在写串口的线程thread中，通过运行语句while(！thread.isInterrupted))，只要收不到线程被打断的命令，即thread.isInterrupted一直为false，就可以是使读串口的指令线程保持无限循环运行状态，可以持续去读取OBD设备返回的指令。

S108、写串口线程是否被打断：

在不断写串口的过程中每次循环都要检测一下当前线程是否有被打断，即判断thread.isInterrupted的值为true还是false。

S109、线程被打断，需要重启服务，再将线程启动起来：

如果线程被打断，thread.isInterrupted变为true，说明当前有异常或错误发生，导致正常的线程中断，要恢复写和读的正常运行状态，需要重新启动Service进程，然后再重新启动写串口线程和读串口线程，使程序重新步入正轨。

S1010、保持运行状态，持续往串口中写入指令：

如果写串口线程一直未打断，即thread.isInterrupted始终为false，则持续往串口中写入指令。

S1011、写入指令的过程就是发送读取串口的命令，不同的需求对应不同的指令以及发送频率：

在步骤S105已介绍，写入指令的过程就是发送读取串口的请求命令给OBD设备，但是需要注意，不同的需求对应着不同的请求指令以及发送频率。例如，统计汽车的瞬时速度，那就需要实时的，每秒去读取OBD设备的汽车对应的速度信息；如果是统计汽车的故障信息，就没有必要那么频繁了，可以1分钟，3分钟或5分钟，像这样以分钟级别的间隔来读取就可以了。

S1012、写入过程中是否有异常发生：

在写入串口指令的过程中，包括构建指令，获取文件句柄，写文件句柄等很多步骤，在这些过程中都需要进行监控，是否有异常发生。

S1013、将所有请求指令写入串口后，让当前线程暂停50毫秒，然后继续循环执行：

如果未发生异常，则在将所有请求指令写入串口后，通过调用语句Thread.sleep(50)，让当前线程暂停50毫秒执行，然后再继续循环执行。这样做目的是使当前线程让出CPU，使其它线程能够有机会得到执行。

S1014、捕获发生的异常，准备做重启处理：

如果期间发生了异常情况，需要保存当前的一些状态信息，为重启Service进行做一些准备工作。

S1015、读串口线程是否被打断：

在不断读串口的过程中每次循环都要检测一下当前线程是否有被打断，即判断thread.isInterrupted的值为true还是false。

S1016、保持运行状态，OBD设备持续将数据上报给读取串口的程序：

如果读取线程没有遇到外界的打断，OBD设备会持续将数据上报给读取串口的程序。

S1017、获取串口信息，Service进程对读取到的指令进行校验和解析：

在读取到响应指令后，需要对读到的指令进行校验，确定其对应的是哪条请求指令。然后通过OBD对应的指令协议类型，筛选出有效指令，然后过滤掉无用的信息，再将有效的信息解析出来。

例如之前介绍过的一个读取汽车瞬时速度指令的返回信息为，AA 55 00 21 FFDE 30 00 00 17 00 01 31 32 2E 32 00 06 7A，它的解析方式和生成指令的解析方式类似，不同的字节代表着不同的含义，有价值的信息就包含在这些字节中。如上指令，前8个字节可以对照之前的介绍进行了解，第9,10个字节00 17表示读数据流数值；接着的两个字节00 01表示读取数值的数据流数量，可知只读取1个数据流；后面几个字节，只到06 7A之前，这5个字节31 32 2E 32 00表示数据流数据值，它是一个字符串类型的值，经过查询它表示“12.2”这样的一个字符串，因为我们读取的是瞬时速度，所以12.2表示的是当前车速为12.2km/h。通过解析以上十六进制字符数组，就可以得到当前的速度为12.2km/h。

S1018、以上过程是否有异常发生：

以上解析过程是一个非常复杂的过程，需要实时监测过程中的状态，判断是否有异常情况发生。

S1019、调用后台服务器提供的接口，准备将解析过的数据上报给后台服务器：

如果未发生异常情况，说明读取和解析过程没有发生问题。这时可以调用后台服务器提供的接口，准备将解析好的数据上报给后台服务器。

S1020、继续监听读取串口返回的数据：

除了上报后台服务器外，需要继续监听读取串口返回的数据，然后解析，重复以上步骤。

S1021、服务器后台处理子流程：

将数据上报给后台服务器，此时进入到服务器后台处理子流程，具体可以参考图2以及详解。

S1022、微信小程序展示子流程：

数据在后台服务器端处理后，会使用微信小程序展示子流程展示数据给用户，可以参考下面的图3以及详解。

S1023、结束：

完成以上步骤后，整个流程结束。

以上就是通过串口读取OBD设备的汽车信息，然后利用微信小程序展示汽车状况的整体流程图，下面分别介绍服务器后台处理子流程和微信小程序展示子流程。

以下图2是服务器后台处理子流程：

其实现的步骤如下：

S201、开始：开始服务器后台处理子流程。

S202、服务器提供给车机系统一个获取UUID的接口以及若干个数据上报的接口：

在车机系统进行数据上报时需要一个区分不同汽车的标识，这个标识就用UUID来代替。而UUID需要服务器端提供，这样便于服务器端进行统计，所以服务器会预先提供给车机系统一个获取UUID的接口以及若干个数据上报的接口。

S203、车机系统的app应用程序通过UUID接口获取UUID，并保存到本地：

app应用程序通过服务端提供的UUID接口获取到UUID，然后将其保存到本地，用于后续的继续进行数据上报的参数字段。

S204、app应用程序将采集到的数据经过解析，验证等处理后，通过上报接口传递给后台服务器：

由图1介绍的步骤知道，app应用程序通过读取OBD设备中的汽车状态信息，然后对得到的信息经过校验，解析等处理后得到初始信息，然后通过上报接口传递给后台服务器。例如，可以通过如下方式上报故障码，

HashMap<String,String>args＝new HashMap<>()；

args.put(UmsAgentUtils.OBD_FAULT_VALUE_ONE,json.toString())；

UmsAgent.postEvent(MainApplication.application,UmsAgentUtils.MACHINTE_OBD_FAULT_ONE_STATUS,UmsAgentUtils.MACHINTE_OBD_DATE,null,args)；

HashMap<String,String>args＝new HashMap<>()；表示定义一个HashMap变量，然后将构建的有用信息json.toString()通过语句args.put存放到args这个结构体中，最后调用UmsAgent.postEvent方法将其发送给后台服务器。其中参数MainApplication.application表示上下文句柄，UmsAgentUtils.MACHINTE_OBD_FAULT_ONE_STATUS表示上报的是故障码类型的信息，args表示上报具体信息。通过以上方式就可以依次将所有需要上报的信息上报给后台服务器。

S205、上报过程是否有异常发生：

以上上报过程需要构造json格式的数据，并通过Http协议进行上报，因此可能会出现异常情况，所以需要判断上报过程是否有异常发生。

S206、捕获异常，准备重新上报此条记录：

如果异常发生，需要捕获此异常，防止其引起程序的崩溃。并且由于异常发生，上报失败，需要重新上报，所以要重新准备上报此条记录。

S207、服务器将接收到的数据写入到数据库：

如果没有异常发生，则会在服务器端收到此条记录，使用服务器端的数据库将其保存下来。

S208、微信小程序子流程请求数据进行展示：

接着就是使用微信小程序来展示数据。首先是请求到数据，然后准备展示数据给客户查看。

S209、服务器端实时计算模块对一些数据进行二次加工处理，并将结果写入数据库：

服务器收到微信小程序请求后，启动服务器端实时计算模块对一些数据进行二次加工处理。比如，用户想知道上次行程的车程距离，则通过微信小程序的方式给用户展示信息。微信小程序会使用服务器提供的接口来请求数据，服务器收到请求后，将到数据库中查询最近一次发动机熄灭时和最近一次发送机启动时的信息，当然发动机熄灭的时间必须大于启动的时间，启动和熄灭之间将表示一次完整的行程，这个时间段内的数据就是一次行程的数据。由发动机熄灭时的总里程数S1，和启动时的总里程S2，通过S1减去S2就可以得到这次行程的距离为S1-S2。再比如，想计算上次行程中的刹车次数，通过上次行程中每秒统计上来的瞬时速度就可以得到，比如第一秒的速度为V1，第三秒的速度为V2，如果V1-V2大于10KM/H，就表示一次紧急刹车。因为刹车是这样定义的：上次车速和本次车速速度差为10KM/H，并且持续为2秒以上就可以看作是一次紧急刹车。

通过以上类似的方法，由服务器端对数据进行二次加工处理后，将数据升级为对用户来说更有用的数据，并最终将结果写入数据库。

S2010、加工过程是否存在异常或者错误：

以上加工的过程情况很复杂，难免会出现错误或异常情况，所以需要对异常情况进行监控。

S2011、对异常和错误进行处理，准备重新写入：

如果有异常发生，则需要对其进行处理，并重新对出现异常的二次计算进行重新计算。

S2012、服务器根据微信小程序请求的指令，分别返回故障信息，汽车基本信息和二次加工的信息给小程序：

微信小程序请求的指令包括很多种类型，包括有故障信息，汽车基本信息和二次加工的信息，服务器需要根据不同的请求给出不同的数据响应。

S2013、微信小程序获取到数据后进行展示：

微信小程序获取到服务器端响应的数据后进行界面展示，用户通过小程序从而了解到汽车当前有哪些故障，汽车的基本信息，如汽车型号，车系，油耗，行驶里程等。还有二次加工的信息，如上次的里程，油耗，刹车次数等各种更有价值的信息。

S2014、结束：

结束服务器后台处理子流程。

以上是服务器后台处理子流程的介绍，它和总流程和微信小程序展示子流程都有关系，接下来介绍微信小程序展示子流程。

如图3所示，其实现的步骤如下：

S301、开始：

开始微信小程序展示子流程。

S302、用户使用微信小程序查看汽车状况：

用户要用微信小程序查看汽车的状况信息，需要通过微信才能打开微信小程序，而现在的微信几乎已经是手机应用中的标配应用了，所以可以肯定，只要用户使用智能手机，基本都会安装微信这个应用程序。

S303、微信之前打开过小程序，保存有此记录：

用户打开微信后，在程序主界面，向下滑动列表可以看到之前打开的微信小程序，如果之前运行过此微信小程序，就会在此显示。会首先判断微信之前是否打开过微信小程序。

S304、直接在微信历史记录中打开微信小程序：

如果之前通过微信打开过此微信小程序，并且用户在微信主列表界面通过点击的方式重新启动此微信小程序，这样可以避免扫码的方式登录，更加快捷。

S305、之前未打开过或者打开过但未使用历史记录打开：

如果之前微信并没有打开过此微信小程序，或者打开过，但用户并不想通过点击历史记录图标的方式启动微信小程序。

S306、通过应用程序提供的二维码打开微信小程序：

那么用户只能通过微信扫描app应用程序提供的二维码的方式来打开微信小程序。

S307、应用程序之前通过服务器接口获取过二维码图片：

需要判断一下客户单的应用程序之前通过服务器接口是否获取过二维码图片，因为之前获取过就不用重新再获取了，使用保存的记录就可以了。

S308、获取本地保存过的二维码图片，展示给用户：

如果之前获取过，则使用本地保存的二维码图片展示给用户。

S309、通过服务器提供的接口获取二维码图片并保存到本地：

如果之前未获取过，那么需要首先通过服务器提供的接口方位服务器获取此二维码图片，然后将其保存到本地，供以后再次扫描时使用。

S3010、服务器收到请求，利用微信公众平台提供的接口生成二维码图片，并传递给应用程序：

服务器收到访问二维码的请求，它会调用微信公众平台提供的接口生成二维码图片，然后在服务器端做好备份，再将图片通过客户端访问的接口传递给应用程序。

S3011、应用程序将二维码图片展示给用户：

应用程序拿到二维码图片后，利用应用程序的界面控件将此图片展示给用户，并附上指导文字，使用户进行正确的扫描。

S3012、用户利用微信扫一扫功能扫描二维码图片，打开微信小程序：

用户利用微信扫一扫功能扫描二维码图片，通过此扫描打开微信小程序，此二维码图片含有汽车的唯一标识UUID，微信小程序在请求服务器端保存的汽车状况信息时，就是通过这个UUID获取到只和自己相关的信息。

S3013、登录微信小程序，按产品需求展示汽车状况信息：

通过微信扫描二维码成功后，将登陆到微信小程序。然后按照产品需求进行汽车状况的信息展示。

S3014、通过服务器提供的接口，显示各种状况信息(故障信息，基本信息，二次加工信息等)：

通过访问服务器提供的接口，获取要显示各种状况信息，然后通过不同的界面进行展示。比如第一页可展示汽车名称，车系，汽车发动机唯一标识VIN码这些汽车的基本信息，还可以展示行驶总里程，百公里油耗，上次行程的报告等等二次加工的信息。第二页可以用来展示汽车故障信息，如水箱缺水等。可以分类将不同信息展示给用户。此种展示方式只是一个示例，其实还有很多信息可以通过此种方式展示，此发明包括但不限于类似这些信息。

S3015、服务器器实时计算模块会随时根据用户的请求更新数据给微信小程序：

一些信息会随时发生变化，所以需要服务器器实时计算模块能够随时根据用户的请求更新数据给微信小程序，比如，当前汽车的瞬时速度，需要服务器端实时计算统计后，显示给用户。

S3016、微信小程序实时刷新数据，及时展示给用户：

微信小程序会实时刷新数据，及时将变动的数据展示给用户，使用户及时的了解到自己爱车的最新状况信息。

S3017、结束：

结束微信小程序展示子流程。

综上，以上就是整个发明的详细实现主流程和相关的子流程。

因此，针对很多汽车用户不仅想及时的了解自己汽车的故障信息，还想更深入的了解一些深层次信息的需求，本发明设计和实现了一种解决方法，具有以下设计特点。

(1)首先，以微信小程序的方式展示汽车故障码信息，常用信息和深层次汽车使用信息，可以做到方便，快捷和及时。

因为只要用户的手机上安装了微信，无论在何时何地都可以调用出微信小程序，从而通过微信小程序就能及时了解到这些信息了；

(2)其次，本发明对汽车的基本信息进行了加工处理，对用户展示的不仅仅是故障码对应的故障信息，基本的行驶总里程，剩余油耗等基本信息，它还包括，例如每次行程的详细信息，油耗，行驶时长，平均油耗，制动次数等等深层次的信息，这些信息都是用户更想了解的有价值的信息；

(3)最后，通过获取到汽车状况信息，使车主可以及时了解汽车的当前状况，例如，故障类型和故障数量，是否需要维修和保养等，为用户起到一个安全提醒的功能，将使汽车的使用寿命更长，汽车在使用的时候也更加的安全。

需要强调的是，本实施例使用微信小程序的方式展示汽车状况，其实还可以使用应用程序app的方式来展示，但是需要用户另外下载安装这个app到手机上才可以使用。

本发明中提到的服务器会进行二次数据加工处理，其中有些处理过程可以放到应用程序上传基本数据前进行处理，也就是在上报数据前可以预先处理一下数据再进行上报，这样的好处是可以减轻些服务器的负担。

本发明有以下两个关键点：

1、使用车机系统上的app应用程序，通过读取OBD设备对应串口的方式得到汽车的基本信息，然后传递给后台服务器，后台服务器对基本数据进行二次加工，获得更有意义的数据，并提供一个二维码图片给app应用程序进行展示；

2、用户通过微信扫一扫功能扫描app应用程序的二维码，此二维码关联了此台汽车的信息，通过扫描可以启动对应的微信小程序，在微信小程序中展示服务器二次加工过的有用数据给用户，从而使用户获得更多更有意义的汽车使用状况信息。

本发明提供的通过串口读取OBD设备的汽车信息并进行展示的方法，具有以下优点：

(1)采用本发明的方案，不会存在耗费用户较多的通信流量的情况，能够确保实时采集OBD的信息，。对于采集到的OBD设备信息，除了传给后台服务器进行过滤，校验，解析，存储外，还会进行二次数据加工，得到更多的用户想了解的信息。

(2)采用客户端小程序的方式展示数据，可以做到只要用户安装了对应客户端，随时都可以通过客户端小程序查看车辆的状况信息，方便用户使用。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视本发明的保护范围。

Claims (3)

1.一种通过串口读取OBD设备的汽车信息并进行展示的方法，其特征在于，应用于包括OBD设备、车机系统、安装于车机系统的车机系统应用程序、后台服务器和安装于客户端的客户端小程序的系统中；

通过串口读取OBD设备的汽车信息并进行展示的方法包括以下步骤：

步骤1，当汽车发动机启动时，同步触发启动所述车机系统和所述OBD设备；所述OBD设备获取并实时存储汽车信息；其中，所述汽车信息包括汽车故障码信息和汽车运行基本信息；

当所述车机系统启动时，根据预设定的OBD设备的串口名称和串口读写波特率，通过对应的串口与所述OBD设备相连接；

步骤2，所述车机系统启动运行于所述车机系统的车机系统应用程序；所述车机系统应用程序按照所述串口读写波特率，持续通过所述串口向所述OBD设备发送读取指定汽车信息的请求指令；并持续接收所述OBD设备返回的指定汽车信息的响应指令；

步骤3，所述车机系统应用程序对持续接收到的所述OBD设备返回的指定汽车信息的响应指令进行校验和解析，确定该响应指令所对应的请求指令，然后根据所述OBD设备对应的指令协议类型，过滤掉无用的信息，筛选出有效响应指令，再从所述有效响应指令中解析到有效汽车信息；

步骤4，所述车机系统应用程序调用后台服务器提供的服务接口，通过所述服务接口，接收所述后台服务器传递的用于区分不同车机系统的用户唯一标识UUID；

然后，所述车机系统应用程序将携带所述用户唯一标识UUID的有效汽车信息上报给所述后台服务器；

步骤5，所述后台服务器接收到携带所述用户唯一标识UUID的有效汽车信息后，解析出所述用户唯一标识UUID以及所述有效汽车信息，并根据所述用户唯一标识UUID，将属于同一个用户唯一标识UUID的所有有效汽车信息写入到数据库；

步骤6，对于每个已注册的客户端小程序，均通过所述后台服务器的接口获得对应的用户唯一标识UUID；然后，利用所述用户唯一标识UUID生成与指定车机系统对应的二维码图片，并将所述二维码图片传输给对应的车机系统的车机系统应用程序；所述车机系统应用程序本地保存对应的所述二维码图片；并通过界面展示所述二维码图片；

所述客户端扫描所述二维码图片，在扫描过程中，向所述后台服务器发送访问二维码图片的请求；所述后台服务器接收到所述访问二维码图片的请求后，对所述访问二维码图片的请求进行解析，得到对应的用户唯一标识UUID，然后，触发所述客户端运行与所述用户唯一标识UUID对应的所述客户端小程序；

步骤7，所述客户端小程序根据用户输入的指令，向所述后台服务器发送与所述用户唯一标识UUID对应的指定汽车信息获取请求；

所述后台服务器接收到所述指定汽车信息获取请求后，判断是否可直接通过查找所述数据库获取，如果可以，则直接从所述数据库读取到对应的指定汽车信息，并返回给所述客户端小程序；

如果不可以，则所述后台服务器启动服务器端实时计算模块，通过所述服务器端实时计算模块，对所述数据库中的相关信息进行二次加工计算，得到指定汽车信息，并返回给所述客户端小程序；

步骤8，所述客户端小程序将接收到的所述指定汽车信息进行界面展示。

2.根据权利要求1所述的通过串口读取OBD设备的汽车信息并进行展示的方法，其特征在于，步骤1中，所述OBD设备获取并实时存储的汽车信息，包括汽车故障码信息以及汽车运行状态信息。

3.根据权利要求1所述的通过串口读取OBD设备的汽车信息并进行展示的方法，其特征在于，步骤2具体为：

步骤2.1，在所述车机系统应用程序中首先创建一个Service服务进程；在启动运行于所述车机系统的车机系统应用程序时，启动所述Service服务进程；其中，所述Service服务进程和所述车机系统应用程序运行于同一进程，或者，所述Service服务进程为一个独立的进程；

步骤2.2，当所述Service服务进程被启动时，所述Service服务进程根据预设定的OBD设备的串口名称和串口读写波特率，打开OBD设备对应的串口，为读写OBD设备做准备；

所述Service服务进程判断OBD设备对应的串口是否被成功打开，如果串口打开失败，则向所述车机系统返回串口打开失败的提示信息，然后通过重启服务的方式，重新打开串口；如果串口打开成功，执行步骤2.3；

步骤2.3，所述Service服务进程启动后，在后台一直保持运行状态；当所述串口打开成功后，所述Service服务进程同时启动一个无限循环的写串口的指令线程和一个无限循环的读取串口返回指令的线程；

对于所述无限循环的写串口的指令线程，通过以下步骤2.3.1-步骤2.3.5实现持续向OBD设备的串口写入读取指定汽车信息的指令：

步骤2.3.1，写串口的指令线程根据需求设定与获取指定汽车信息对应的指令内容以及指令发送频率；

步骤2.3.2，写串口的指令线程检测当前线程是否被打断，如果被打断，则执行步骤2.3.3；如果没有被打断，则执行步骤2.3.4；

步骤2.3.3，重新启动所述Service服务进程，当所述Service服务进程被重新启动时，重新启动所述写串口的指令线程，再返回执行步骤2.3.1；

步骤2.3.4，写串口的指令线程保持运行状态，根据对应的所述指令发送频率，持续向所述OBD设备的串口写入读取指定汽车信息的指令；其中，在每次向所述OBD设备的串口写入读取指定汽车信息的指令时，监控写入过程是否发生异常；如果发生异常，则返回步骤2.3.3；如果没有发生异常，则执行步骤2.3.5；

步骤2.3.5，在进行一次写入循环后，使所述写串口的指令线程暂停50毫秒，然后再返回步骤2.3.1；

对于所述无限循环的读取串口返回指令的线程通过以下步骤2-3-1-步骤2-3-4实现持续接收OBD设备的串口上报的指定汽车信息；

步骤2-3-1，OBD设备的串口检测读取串口返回指令的线程是否被打断，如果被打断，则执行步骤2-3-2；如果没有被打断，则执行步骤2-3-3；

步骤2-3-2，OBD设备的串口暂停向所述串口返回指令的线程上报指定汽车信息；并重新启动所述Service服务进程，当所述Service服务进程被重新启动时，重新启动所述读取串口返回指令的线程，再返回执行步骤2-3-1；

步骤2-3-3，OBD设备的串口持续向串口返回指令的线程上报指定汽车信息；

步骤2-3-4，串口返回指令的线程持续接收所述OBD设备通过串口上报的指定汽车信息。