CN115589353A - 车辆的报文处理方法、车辆的报文处理系统及车辆 - Google Patents

Abstract

本发明公开了一种车辆的报文处理方法、车辆的报文处理系统及车辆。其中，该方法包括：获取车辆中报文处理模块输出的实时报文，其中，实时报文用于表征车辆与车载设备之间的连接状态；判断实时报文与缓存模块中的预设报文是否一致，其中，缓存模块包括历史缓存的多个报文，预设报文为多个报文中最后缓存至缓存模块的报文；响应于实时报文与预设报文不一致，将实时报文上报至车辆的应用程序，其中，应用程序通过解析实时报文确定车辆与车载设备之间的连接状态。本发明解决了相关技术中车载设备故障后不再发送报文，用户无法即时了解车载设备的状态的技术问题。

Description

车辆的报文处理方法、车辆的报文处理系统及车辆

技术领域

本发明涉及车载设备领域，具体而言，涉及一种车辆的报文处理方法、车辆的报文处理系统及车辆。

背景技术

近几年来，随着社会的进步与发展，人们对生活质量的要求越来越高，车载设备的种类也越来越丰富。目前的相关技术主要是利用应用程序每隔一段时间获取车载设备输出的报文来确定该设备的状态，虽然在车机系统底层会一直缓存获取到的报文，但是如果车载设备发送报文之后出现了故障，则车载设备不再发送报文，上层的应用程序无法获取到报文，导致用户无法即时了解该设备出现故障，为用户的出行带来不便。

针对上述的问题，目前尚未提出有效的解决方案。

发明内容

本发明实施例提供了一种车辆的报文处理方法、车辆的报文处理系统及车辆，以至少解决相关技术中车载设备故障后不再发送报文，用户无法即时了解车载设备的状态的技术问题。

根据本发明实施例的一个方面，提供了一种车辆的报文处理方法，包括：获取车辆中报文处理模块输出的实时报文，其中，实时报文用于表征所述车辆与车载设备之间的连接状态；判断实时报文与缓存模块中的预设报文是否一致，其中，缓存模块包括历史缓存的多个报文，预设报文为多个报文中最后缓存至缓存模块的报文；响应于实时报文与预设报文不一致，将实时报文上报至车辆的应用程序，其中，应用程序通过解析实时报文确定车辆与车载设备之间的连接状态。

可选地，上述实时报文包括：车载设备实时上传至报文处理模块的正常报文或者控制报文处理模块生成的故障报文。

可选地，上述方法还包括：响应于报文处理模块在预设时长内未接收到车载设备上传的正常报文，控制报文处理模块生成故障报文。

可选地，响应于实时报文与预设报文不一致，将实时报文上报至车辆的应用程序之后，上述方法还包括：将实时报文缓存至缓存模块。

可选地，上述方法还包括：响应于实时报文与预设报文一致，将实时报文缓存至缓存模块。

可选地，控制报文处理模块生成故障报文，包括：控制报文处理模块获取缓存模块的预设报文；基于预设规则对预设报文进行更改，得到故障报文。

可选地，在实时报文为正常报文的情况下，应用程序通过解析实时报文确定车辆与车载设备之间的连接状态处于正常状态；或，在实时报文为故障报文的情况下，应用程序通过解析实时报文确定车辆与车载设备之间的连接状态处于故障状态。

可选地，应用程序间隔预设时长从缓存模块中获取预设报文，并通过解析预设报文确定车辆与车载设备之间的连接状态。

根据本发明实施例的另一方面，还提供了一种车辆的报文处理系统，包括：报文处理模块，用于输出实时报文，其中，实时报文用于表征车辆与车载设备之间的连接状态；控制器，用于判断实时报文与缓存模块中的预设报文是否一致，其中，缓存模块包括历史缓存的多个报文；预设报文为多个报文中最后缓存至缓存模块的报文；响应于实时报文与预设报文不一致，将实时报文上报至车辆的应用程序；应用程序，用于通过解析实时报文确定车辆与车载设备之间的连接状态。

根据本发明实施例的另一方面，还提供了一种车辆，包括：一个或多个处理器；存储装置，用于存储一个或多个程序；当一个或多个程序被一个或多个处理器执行，使得一个或多个处理器执行上述任意一项的车辆的报文处理方法。

根据本发明实施例的另一方面，还提供了一种计算机可读存储介质，计算机可读存储介质包括存储的程序，其中，在程序运行时控制计算机可读存储介质所在设备执行上述信息推送方法。

根据本发明实施例的另一方面，还提供了一种处理器，处理器用于运行程序，其中，程序运行时执行上述信息推送方法。

在本发明实施例中，采用获取车辆中报文处理模块输出的实时报文的方式，判断实时报文与缓存模块中的预设报文是否一致，若实时报文与预设报文不一致，则说明该实时报文为故障报文，车机系统底层可以将该实时报文上报至车辆的应用程序，从而实现车机系统底层及时上报车载设备出现故障的报文给应用程序，无需应用程序定期从车机系统底层获取，确保应用程序可以及时获取到车载设备出现故障的报文，实现了即时获取车载设备的状态的技术效果，进而解决了相关技术中车载设备故障后不再发送报文，用户无法即时了解车载设备的状态的技术问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的一种车辆的报文处理的方法的流程图；

图2是根据本发明实施例的一种车机系统的结构示意图；

图3是根据本发明实施例的一种车辆的报文处理装置的结构框图；

图4是根据本发明实施例的一种车辆的报文处理系统的示意图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

首先，针对本发明实施例中出现的技术名词进行解释如下：

车载单元(On Board Unit，简称为OBU)：OBU是指采用专用短程通信(DedicatedShort Range Communication，简称为DSRC)技术，与路侧单元(Road Side Unit，简称为RSU)进行通讯的微波装置。在电子不停车收费(Electronic Toll Collection,简称为ETC)E系统中，OBU放在车上，路边架设路侧单元相互之间通过微波进行通讯。车辆高速通过RSU的时候，OBU和RSU之间用微波通讯，识别真假，获得车型，计算费率，扣除通行费，就像非接触卡一样，只不过相比之下距离更远，频率更高。

在ETC系统中，OBU采用DSRC技术，建立与RSU之间微波通讯链路，使车辆在行驶过程中，不需要停车就可以实现车辆身份识别以及电子扣费，实现了不停车、免取卡，建立了无人值守车辆通道。

微控制单元(Microcontroller Unit,简称为MCU):又称为单片微型计算机(Single Chip Microcomputer)或者单片机，是把中央处理器(Central Process Unit,简称为CPU)的频率与规格做适当缩减，并将内存(memory)、计数器(Timer)、通用串行总线(Universal Serial Bus，简称为USB)、A/D转换、等周边接口，甚至液晶显示器(LiquidCrystal Display，简称为LCD)驱动电路都整合在单一芯片上，形成芯片级的计算机，为不同的应用场合做不同组合控制。诸如手机、遥控器，甚至汽车电子、工业上的步进马达、机器手臂的控制等，都可见到MCU的身影。

控制器局域网络(Controller Area Network，简称为CAN)总线：CAN是由研发和生产汽车电子产品著称的德国BOSCH公司开发的，并最终成为国际标准，是国际上应用最广泛的现场总线之一。在北美和西欧，CAN总线协议已经成为汽车计算机控制系统和嵌入式工业控制局域网的标准总线，并且拥有以CAN为底层协议专为大型货车和重工机械车辆设计的J1939协议。近年来，其所具有的高可靠性和良好的错误检测能力受到重视，被广泛应用于汽车计算机控制系统和环境温度恶劣、电磁辐射强和振动大的工业环境。

CAN总线系统具有以下优点：比传统的布线方式的数据传输速度更高；比传统的布线方式要更节省线束，降低了车身重量，同时优化了车身的布线方式；以CAN总线方式连接的控制单元中有一个发生故障，其他控制单元仍可以发送各自的数据，互不影响；CAN数据总线为双线制，如果有一条发生故障，CAN系统会转为单线运行模式，提高了整车的稳定性；CAN系统的双线在实际中是像“麻花”一样缠绕在一起的，这样可以有效地防止电磁波的干扰和向外辐射；基于CAN总线系统可以实现更丰富的车身功能。

报文：报文是指网络中交换与传输的数据单元，即站点一次性要发送的数据块。报文包含了将要发送的完整的数据信息，期长短不一致，长度不限且可变。报文的认证方式有传统加密方式的认证、使用密钥的报文认证码方式、使用单向散列函数的认证和数字签名认证方式。报文也是网络传输的单位，传输过程中会不断地封装成分组、包、帧来传输，封装的方式就是添加一些信息段，那些就是报文头以一定格式组织起来的数据，完全与系统定义，或自定义的数据结构同义。

ZLGCANTest软件：ZLGCANTest通用测试软件是一款集CAN接口卡测试和周立功CAN卡驱动为一体的软件，可以解决CAN接口卡和电脑不能正常连接的问题，如果不能连接会进行快速的测试，并给出测试报告。ZLGCANTest软件是SBCAN-I/II智能CAN接口卡配套驱动程序，还配备有错误检测能力，灵活性十分的强。ZLGCANTest软件支持接收、发送、查看、分析和记录CAN报文等功能，能够帮助用户增强CAN报文的稳定性。ZLGCANTest软件具有接收滤波设置、普通发送模式、文件发送、DBC等功能，其中，DBC功能是针对汽车电子用户设计的，非常便于汽车数据解析破解以及车辆状态的检测，是ZLGCANTest软件的核心功能。

实施例1

根据本发明实施例，提供了一种车辆的报文处理的方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

图1是根据本发明实施例的一种车辆的报文处理的方法的流程图，如图1所示，该方法包括如下步骤：

步骤S102，获取车辆中报文处理模块输出的实时报文。

获取车辆中报文处理模块输出的实时报文，其中，报文处理模块主要负责实现对报文“预处理”的功能，提取可以被工具包进行数据格式转换的业务信息，并以标准格式显示，同时又增加了完善报文标准的功能，具体包括报文标准管理和单证管理两个子模块。实时报文用于表征车辆与车载设备之间的连接状态，获取实时报文可以使用户实时了解到车辆与车载设备之间的连接状态。

在一种可选的实施例中，可以通过车机获取车辆中报文处理模块输出的实时报文。OBU设备会每隔100ms向CAN总线发送一帧报文，这些报文里面就包含了OBU设备的状态信息；我们的车机也是连接在CAN总线上的，所以车机是可以接到OBU设备发送的报文的。CAN报文的格式是一串16进制的数字，例如：88 00 0C 00 BB 0C 00 00，每两个数字代表一个字节，一共是8个字节，每个字节转换成二进制数是8位，比如十六进制的“0C”转换成二进制应该是00001100，中间用空格分开，是为了比较好辨识字节的个数，实际是不分开的。

上述车载设备用于实现车辆与路侧设备之间的通讯功能，其中，路侧设备可以指路侧的收费设备、路侧的充电设备等路侧智能设施，路侧设备可以包括摄像头、毫米波雷达、少量激光雷达、环境感知设备、智能化标志标识等装置。

在一种可选的实施例中，车载设备可以指前装ETC设备(即OBU设备)、智能后视镜、车载空气净化器、车载冰箱、车载吸尘器、车载按摩器等，以OBU设备为例，该设备是连接在汽车CAN总线上的，可以用于在车辆的电源为OBU设备供电后，检测该OBU设备是否已被激活，若未被激活，则通过CAN总线反馈未激活通知。

在一种可选的实施例中，仍以OBU设备为例，在车辆的电源为OBU设备供电后，检查OBU设备是否被拆卸，得到防拆检查结果，若防拆检查结果表征了OBU设备已被拆卸，则通过CAN总线在显示设备反馈对应的防拆失效通知。

其中，防拆失效通知，可以以文本(例如文字、数字、字母等至少之一)和/或图像(例如图片、图案、图形等至少之一)的形式反馈，例如，防拆检查结果出来之后，在显示设备上显示“检查完成，设备未被拆卸”，或，“检查完成，设备已被拆卸”。检查OBU设备是否被拆卸的方式可以是多样的，例如，OBU设备可以通过某线路(该线路的通断关联于OBU设备是否被拆卸的状态)对外发送信号和/或接收信号，若该信号被成功发出(例如被车载终端接收到)和/或成功接收，则认定未被拆卸；可以基于OBU设备所接收到的供电的电学参数，判断是否被拆卸(例如供电的电压低于阈值，则判断被拆卸)。

上述显示设备可以为任意能够对信息进行显示的设备，例如可以为仪表屏、显示屏、中控屏、抬头显示器等。

在一种可选的实施例中，OBU设备还可以用于：在车辆的电源为OBU设备供电后，自检OBU设备是否发生故障，得到故障检查结果，若故障检查结果表征了OBU设备发生了故障，则通过CAN总线在显示设备反馈对应的故障通知。

其中，故障可以指OBU设备软件和/或硬件的任意故障，只要是能够基于自检而检查出来的故障，均可包括在内。其中显示设备反馈的故障通知，可以以文本(例如文字、数字、字母等至少之一)和/或图像(例如图片、图案、图形等至少之一)的形式反馈，例如，可以在显示设备上显示文本“设备无故障”，或，“XX设备出现故障”。

在一种可选的实施例中，在OBU设备已被激活的情况下，若OBU设备被收费入口的路侧设备成功扫描通过，则通过显示设备和/或车辆的声音反馈装置输出对应的正常通行通知；在OBU设备已被激活的情况下，若OBU设备未被收费入口的路侧设备成功扫描通过，则通过显示设备和/或车辆的声音反馈装置输出对应的异常通行通知。

其中，显示设备反馈的正常通行通知，可以以文本(例如文字、数字、字母等至少之一)和/或图像)例如图片、图案、图形等至少之一)的形式反馈。声音反馈装置可理解为能够实现声音反馈的任意装置，例如可以是蜂鸣器、喇叭，或其他装载喇叭的设备。声音反馈装置反馈的正常通行通知可以是蜂鸣器蜂鸣，也可以是一段特定的语音，例如，正常通行通知为“滴”一声，异常通行通知为“滴滴滴”三声。

在一种可选的实施例中，在OBU设备已被激活的情况下，若OBU设备被收费出口的路侧设备成功扫描，则通过CAN总线在车辆的屏幕反馈消费金额信息，可以以文本(例如文字、数字、字母等至少之一)和/或图像(例如图片、图案、图形等至少之一)的形式反馈，例如，消费成功后在车辆的屏幕上显示“消费金额：XX元”。在OBU设备已被激活的情况下，若OBU设备被收费出口的路侧设备成功扫描，则通过CAN总线在车辆的声音反馈装置反馈对应的消费通知，可以以蜂鸣器蜂鸣和/或一段特定的语音的形式反馈，例如，消费成功使用语音播报“消费金额：XX元”。

上述实时报文包括：车载设备实时上传至报文处理模块的正常报文或者控制报文处理模块生成的故障报文。

响应于报文处理模块在预设时长内未接收到车载设备上传的正常报文，则说明车载设备与CAN总线的连接出现故障，可以控制报文处理模块生成故障报文。

其中，预设时长是由开发者设定的一个具体的时间段，可以是3s，若在该时间段内未接收到车载设备上传的正常报文，则说明车载设备与CAN总线的连接出现故障。

在一种可选的实施例中，可以通过一种报文生成方法来控制报文处理模块生成故障报文，该方法包括如下步骤：将各个数据通信协议具体报文格式的各种报文域抽象分类划分为比特报文域、字节报文域、字符串报文域、长度报文域以及检验和报文域；将待生成的数据通信协议具体报文格式的各个报文域归类到比特报文域、字节报文域、字符串报文域、长度报文域以及检验和报文域；根据待生成的数据通信协议具体报文格式的各个报文域在其归属的比特报文域、字节报文域、字符串报文域、长度报文域以及检验和报文域的输入参数值，整理出该数据通信协议报文的完整字节流。

控制报文处理模块生成故障报文，其中包括：控制报文处理模块获取缓存模块的预设报文；基于预设规则对预设报文进行更改，得到故障报文。

在一种可选的实施例中，可以通过CAN卡连接整车CAN或者调试端口，通过使用ZLGCANTest软件交互界面获取CAN报文；可以通过一种报文缓存方法将报文缓存至缓存模块，该方法包括以下步骤：对接收到的报文进行解析，确定报文的优先级；若自身缓存队列的占用量大于或等于优先级对应的丢包阈值，则丢弃报文，其中，缓存队列是指由一串报文数据组成的队列，队列数据长度可以自行设置，当只需要保留最近的缓存数据，或因为容量问题需要限制数据长度时，可以使用缓存队列；若自身缓存队列的占用量小于优先级对应的丢包阈值，则将报文写入缓存队列；其中，相邻的优先级中，高优先级所对应的丢包阈值大于低优先级所对应的丢包阈值。通过上述方法，能够保证高优先级的协议报文的缓存和处理，提高网络设备的可靠性。

上述基于预设规则对预设报文进行更改，得到故障报文，是指当应用程序接收不到OBU设备发出的报文时，就认为OBU设备断开连接了，此时将缓存的报文改成一组特定的故障报文，例如“00 00 00 0000 00 00 00”。

OBU设备发送CAN报文的周期是100ms，相当于每秒10次，如果车机把每一帧数据都接受并解析的话，车机的工作量就会非常大，对车机的性能会有很大影响。基于这个原因，我们在车机系统底层做了优化，增加了缓存模块，优化之后，只有当CAN报文发生变化时才会返回给android上层应用来使用。对车机系统底层进行优化，极大地节省了车机的性能，但是也产生了一个问题：如果OBU设备突然发生物理断联(设备被拔掉，或者线路切断)，那么车机底层缓存的就是OBU设备发出来的最后一帧报文，这一帧报文可能会是表示设备正常的报文，就产生了很严重的问题：用户所了解到的设备状态为正常状态，但是设备却无法使用，车机上层应用和用户都不知道问题出在哪里。

OBU设备报文的上报是在车机系统底层进行优化的，也就是说车机系统底层理论上是能够接受到OBU设备的所有报文的，所以我们可以在底层做处理，如果车机底层长时间(假设为3s)接收不到OBU设备的报文，我们则认为OBU设备断开连接了，此时将缓存的报文改成一组特定的故障报文，假设是“00 00 00 00 00 00 00 00”全是零，这样，安卓上层应用在获取OBU设备的状态信息时，如果发现报文全是0，则认为OBU设备断开连接了。

通过上述方法，不仅对车机性能做了优化，也将OBU设备的所有故障场景全都考虑了进来，能够准确的给用户更友好的交互使用体验，便于实现人机交互。例如可在检测到OBU设备未激活时，通过CAN总线在显示设备上反馈未激活通知，可见，基于车辆的CAN总线，结合车辆中的设备而实现人机交互，避免了前装OBU不便于交互的情形。

步骤S104，判断实时报文与缓存模块中的预设报文是否一致。

上述判断实时报文与缓存模块中的预设报文是否一致，其中，缓存模块包括历史缓存的多个报文，预设报文为多个报文中最后缓存至缓存模块的报文。

在实时报文为正常报文的情况下，应用程序通过解析实时报文确定车辆与车载设备之间的连接状态处于正常状态；或，在实时报文为故障报文的情况下，应用程序通过解析实时报文确定车辆与车载设备之间的连接状态处于故障状态。

其中，正常报文是指与缓存模块中的预设报文一致的实时报文，通过解析该实时报文可以确定车辆与车载设备之间的连接状态处于正常状态；故障报文是指与缓存模块中的预设报文不一致的实时报文，通过解析该实时报文可以确定车辆与车载设备之间的连接状态处于故障状态。

应用程序在间隔一段预设时长后从缓存模块中获取预设报文，并通过解析预设报文确定车辆与车载设备之间的连接状态。

响应于实时报文与预设报文一致，将实时报文缓存至缓存模块。

在一种可选的实施例中，可以通过java代码来解析报文，从而确定车辆与车载设备之间的连接状态。OBU设备发出来的报文，其中从左往右数第六个字节，其中的从左往右数第4-6位是表示OBU的设备状态，通过java代码来表示这个4-6位的数值就是0x07&((obuState[5])>>2)；obuState是8字节的CAN报文，obuState[5]代表第六个字节，((obuState[5])>>2)是将这个字节进行向右移2位的操作，然后再与十六进制的7做“与”操作，即可得出想要的那个数值。这个数值代表的含义如表1所示，其中，“自检中”状态是一个瞬时状态，是指设备在自检，可以忽略；“未做防拆匹配”是指OBU设备没有进行防拆卸匹配，为了避免用户移动OBU设备而逃费或漏扣费，通常将防拆柱按下，使OBU设备固定在挡风玻璃上并激活，当OBU设备拆下时，防拆柱弹开，OBU设备触发防拆失效机制。

表1不同数值代表的含义

数值	1	2	3	4	5
						含义	自检中	已激活	未做防拆匹配	设备硬件故障	未激活

在一种可选的实施例中，检测是否已被激活的方式可以为任意的，例如可检测OBU设备中所存储的标识位(标识出是否被激活)的数值，若该数值表征已被激活，则确定已被激活，若该数值表征未被激活，则确定未被激活，再例如，OBU设备可检测是否接收并存储了ETC功能实现所需的卡片信息和/或电子标签信息，若未存储，则可确定未被激活，若已存储，则可确定已被激活。

图2是根据本发明实施例的一种车机系统的结构示意图，如图2所示，上层应用与OBU设备不直接通信，而是通过MCU，向下注册监听；OBU设备上报的报文是100ms一次，经由MCU做处理，处理逻辑如下：用获取到的报文与缓存做对比，如果一致，则将实时报文缓存至缓存模块，不再进行下一步；如果不一致，就会更新缓存，同时上报应用层；上层应用也可以主动获取一帧CAN报文，他的获取来源是MCU中的缓存；报文处理模块做了超时的机制，因为注册了监听，所以，如果一定时间内(暂定3s)接不到OBU设备发的报文，报文处理模块就会更新缓存，写入错误的报文，并且同时上报一帧报文。

其中，监听是一种可以实时捕获到OBU设备发出的报文的模式。

步骤S106，响应于实时报文与预设报文不一致，将实时报文上报至车辆的应用程序。

响应于实时报文与预设报文不一致，将实时报文上报至车辆的应用程序之后，上述方法还包括：将实时报文缓存至缓存模块，用于进行后续对比。

若实时报文与预设报文不一致，则说明该实时报文是有故障的报文，此时该实时报文可以通过CAN总线主动上传到应用程序，以便于应用程序能够尽快告知用户车载设备连接有故障，并将故障报文缓存到缓存模块中。若在故障上报之后该故障被修复好了，故障报文与正常报文不一致，也可以通过应用程序尽快告知用户车载设备连接有故障，修复后已经恢复正常。

通过以上步骤，采用获取车辆中报文处理模块输出的实时报文的方式，判断实时报文与缓存模块中的预设报文是否一致，若实时报文与预设报文不一致，则说明该实时报文为故障报文，车机系统底层可以将该实时报文上报至车辆的应用程序，从而实现车机系统底层及时上报车载设备出现故障的报文给应用程序，无需应用程序定期从车机系统底层获取，确保应用程序可以及时获取到车载设备出现故障的报文，实现了即时获取车载设备的状态的技术效果，进而解决了相关技术中车载设备故障后不再发送报文，用户无法即时了解车载设备的状态的技术问题。

实施例2

根据本发明实施例的另一方面，还提供了一种车辆的报文处理装置，该装置可以执行上述实施例中的信息推送方法，具体实现方案和应用场景与上述实施例相同，在此不做赘述。

图3是根据本发明实施例的一种车辆的报文处理装置的结构框图。如图3所示，该装置包括：获取模块302，用于获取车辆中报文处理模块输出的实时报文，其中，实时报文用于表征车辆与车载设备之间的连接状态，包括车载设备实时上传至报文处理模块的正常报文或者控制报文处理模块生成的故障报文；判断模块304，用于判断实时报文与缓存模块中的预设报文是否一致，其中，缓存模块包括历史缓存的多个报文，预设报文为多个报文中最后缓存至缓存模块的报文；上报模块306，用于响应于实时报文与预设报文不一致，将实时报文上报至车辆的应用程序，其中，应用程序通过解析实时报文确定车辆与车载设备之间的连接状态。

该装置还包括：控制模块，用于响应于报文处理模块在预设时长内未接收到车载设备上传的正常报文，控制报文处理模块生成故障报文。

该装置还包括：缓存模块，用于响应于实时报文与预设报文不一致，将实时报文上报至车辆的应用程序之后，将实时报文缓存至缓存模块。

缓存模块还用于响应于实时报文与预设报文一致，将实时报文缓存至缓存模块。

控制模块包括：控制单元，用于控制报文处理模块获取缓存模块的预设报文；更改单元，用于基于预设规则对预设报文进行更改，得到故障报文。

实施例3

根据本发明实施例的另一方面，还提供了一种车辆的报文处理系统，图4是根据本发明实施例的一种车辆的报文处理系统的示意图，如图4所示，其中包括：报文处理模块，用于输出实时报文，其中，实时报文用于表征车辆与车载设备之间的连接状态；控制器，用于判断实时报文与缓存模块中的预设报文是否一致，其中，缓存模块包括历史缓存的多个报文；预设报文为多个报文中最后缓存至缓存模块的报文；响应于实时报文与预设报文不一致，将实时报文上报至车辆的应用程序；应用程序，用于通过解析实时报文确定车辆与车载设备之间的连接状态。

实施例4

根据本发明实施例的另一方面，还提供了一种车辆，包括：一个或多个处理器；存储装置，用于存储一个或多个程序；当一个或多个程序被一个或多个处理器执行，使得一个或多个处理器执行上述任意一项的车辆的报文处理方法。

实施例5

根据本发明实施例的另一方面，还提供了一种计算机可读存储介质，计算机可读存储介质包括存储的程序，其中，在程序运行时控制计算机可读存储介质所在设备执行上述信息推送方法。

实施例6

根据本发明实施例的另一方面，还提供了一种处理器，处理器用于运行程序，其中，程序运行时执行上述信息推送方法。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

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

Claims (10)

1.一种车辆的报文处理方法，其特征在于，包括：

获取车辆中报文处理模块输出的实时报文，其中，所述实时报文用于表征所述车辆与车载设备之间的连接状态；

判断所述实时报文与缓存模块中的预设报文是否一致，其中，所述缓存模块包括历史缓存的多个报文，所述预设报文为所述多个报文中最后缓存至所述缓存模块的报文；

响应于所述实时报文与所述预设报文不一致，将所述实时报文上报至所述车辆的应用程序，其中，所述应用程序通过解析所述实时报文确定所述车辆与所述车载设备之间的连接状态。

2.根据权利要求1所述的方法，其特征在于，所述实时报文包括：所述车载设备实时上传至所述报文处理模块的正常报文或者控制所述报文处理模块生成的故障报文。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

响应于所述报文处理模块在预设时长内未接收到所述车载设备上传的所述正常报文，控制所述报文处理模块生成所述故障报文。

4.根据权利要求1所述的方法，其特征在于，响应于所述实时报文与所述预设报文不一致，将所述实时报文上报至所述车辆的应用程序之后，所述方法还包括：

将所述实时报文缓存至所述缓存模块。

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

响应于所述实时报文与所述预设报文一致，将所述实时报文缓存至所述缓存模块。

6.根据权利要求2所述的方法，其特征在于，控制所述报文处理模块生成所述故障报文，包括：

控制所述报文处理模块获取所述缓存模块的预设报文；

基于预设规则对所述预设报文进行更改，得到所述故障报文。

7.根据权利要求2所述的方法，其特征在于，在所述实时报文为所述正常报文的情况下，所述应用程序通过解析所述实时报文确定所述车辆与所述车载设备之间的连接状态处于正常状态；或，在所述实时报文为所述故障报文的情况下，所述应用程序通过解析所述实时报文确定所述车辆与所述车载设备之间的连接状态处于故障状态。

8.根据权利要求1所述的方法，其特征在于，所述应用程序间隔预设时长从所述缓存模块中获取所述预设报文，并通过解析所述预设报文确定所述车辆与所述车载设备之间的连接状态。

9.一种车辆的报文处理系统，其特征在于，包括：

报文处理模块，用于输出实时报文，其中，所述实时报文用于表征所述车辆与车载设备之间的连接状态；

控制器，用于判断所述实时报文与缓存模块中的预设报文是否一致，其中，所述缓存模块包括历史缓存的多个报文；所述预设报文为所述多个报文中最后缓存至所述缓存模块的报文；响应于所述实时报文与所述预设报文不一致，将所述实时报文上报至所述车辆的应用程序；

所述应用程序，用于通过解析所述实时报文确定所述车辆与所述车载设备之间的连接状态。

10.一种车辆，其特征在于，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器执行权利要求1至8中任意一项所述的车辆的报文处理方法。

Images