CN114070898A

CN114070898A - 车型和车辆状态的信号推送方法、装置及计算机可读介质

Info

Publication number: CN114070898A
Application number: CN202111335396.1A
Authority: CN
Inventors: 钟小敏; 张亮; 程登; 黎飞; 苏国传
Original assignee: SAIC GM Wuling Automobile Co Ltd
Current assignee: SAIC GM Wuling Automobile Co Ltd
Priority date: 2021-11-11
Filing date: 2021-11-11
Publication date: 2022-02-18
Anticipated expiration: 2041-11-11
Also published as: CN114070898B

Abstract

本发明公开了一种车型和车辆状态的信号推送方法、装置及计算机可读存储介质，该方法包括：接收用于定义原协议架构的相关指令信息，基于所述相关指令信息，在所述原协议架构上创建推送模块，以构建新协议架构，基于所述推送模块，将所述原协议架构之外的预置车型状态和预置车辆状态的新增信号项增加到新协议架构上，基于所述原协议架构上的控制消息可变头和控制消息固定头扩展所述新协议架构字节，在所述新协议架构增加所述新增信号项的基础上预留空信号项的备用位置。实现了减少资源的浪费和开发新的协议和接口的项目的流程，提高了远程控制开发的效率，达到了降本增效的目的。

Description

车型和车辆状态的信号推送方法、装置及计算机可读介质

技术领域

本发明涉及车联网驾驶领域，尤其一种车型和车辆状态的信号推送方法、装置及计算机可读介质。

背景技术

随着汽车市场逐渐朝着智能化发展，汽车的远程控制功能也越来越完善了，用户对车辆的控制无需在车辆内部进行，只需在用户终端进行相关指令的下发即可远程控制车辆的各种常用功能和查看车辆当前的状况。而从目前发展的现状来看，现有技术中的车辆车况信号上传比较固定，对于不常用或者新的远程控制对应的车型状态和车辆状态增加时，需重新开发或升级协议和接口。

因此现有技术中至少存在如下问题，对于不常用或者新增的远控指令所对应的信号推送，以及新车型开发中新增的车辆信号，传统的车辆车况状态推送的设计满足不了更新迭代的需求，只能重新开发或升级协议和接口，影响了用户用车体验感，增加了云端和智能车机的开发工作量及发开发费用，并且通过车辆FOTA(Firmware Over-The-Air，移动终端的空中下载软件升级)平台进行升级会所产生额外的人力和物力的费用。

另外，每增加一个信号推送或者车辆信号，云端、智能车机和用户终端均需重新开发或升级接口和协议，容易造成多方资源的浪费。

发明内容

本发明的主要目的在于提供一种车型和车辆状态的信号推送方法、装置及计算机可读介质，旨在解决现有的车型状态和车辆状态上传比较固定，对于不常用或者新的远程控制对应的车型状态和车辆状态增加时，需重新开发或升级协议和接口的技术问题。

为实现上述目的，本发明提供一种车型和车辆状态的信号推送方法，所述车型和车辆状态的信号推送方法包括以下步骤：

接收用于定义原协议架构的相关指令信息；

基于所述相关指令信息，在所述原协议架构上创建推送模块，以构建新协议架构；

基于所述推送模块，将所述原协议架构之外的预置车型状态和预置车辆状态的新增信号项增加到新协议架构上；

基于所述原协议架构上的控制消息可变头和控制消息固定头扩展所述新协议架构字节，在所述新协议架构增加所述新增信号项的基础上预留空信号项的备用位置。

可选地，所述接收用于定义原协议架构的相关指令信息的步骤之前，还包括：

基于所述原协议架构的后台执行qmake命令，生成用于构建模块的Makefile文件，得到构建模块的相关指令信息。

可选地，所述基于所述相关指令信息，在所述原协议架构上创建推送模块的步骤包括：

将所述相关指令信息安装到Qt的安装目录中，生成推送模块的文档；

运行推送模块的文档，在所述原协议架构上创建推送模块。

可选地，所述基于所述推送模块，将所述原协议架构之外的预置车型状态和预置车辆状态的新增信号项增加到所述新协议架构上的步骤之前，还包括：

接收所述原协议架构中未存在的车型和车辆状态的信号推送的新增信号项；

将所述新增信号项发送到所述新协议架构上。

可选地，所述基于所述原协议架构上的控制消息可变头和控制消息固定头扩展所述新协议架构字节的步骤包括：

基于所述控制消息可变头为计算控制消息可变头中TopicName的多余字节，并将多余字节转化为TopicID，所述TopicID用于扩展字节；

基于所述控制消息固定头为基于PINGREQ和PINGRESP进行扩展，确定剩余字节用于扩展字节。

可选地，所述在所述新协议架构增加所述新增信号项的基础上预留空信号项的备用位置的步骤包括：

根据扩展新协议架构字节的长度计算所述新协议架构的容量；

基于所述容量计算可预留空信号项的备用位置数量，并增加相应数量的备用位置。

可选地，所述基于所述原协议架构上的控制消息可变头和控制消息固定头扩展新协议架构字节，在所述协议架构增加所述新增信号项的基础上预留空信号项的位置的步骤之后，还包括：

接收用户终端上传的当前车型信号和当前车辆信号；

判断所述当前车型信号和当前车辆信号对应的当前信号项是否存在于所述新协议架构上；

若所述新协议架构上存在所述当前信号项，则直接调用新协议架构上所述当前信号项用于展示当前车型状态和当前车辆状态；

若所述新协议架构上不存在所述当前信号项，则调用预留的空信号项的备用位置用于展示当前车型状态和当前车辆状态。

可选地，所述判断所述当前车型信号和当前车辆信号对应的当前信号项是否存在于所述新协议架构上的步骤包括：

对所述用户终端上传的当前车型信号和当前车辆信号对应的当前信号项进行解码，得到与所述当前信号项对应的协议和接口；

将所述对应的协议和接口与所述新协议架构上的协议和接口进行对比分析，判断所述对应的协议和接口是否存在于所述新协议架构上，进而得出当前信号项是否存在于新协议架构上。

此外，为实现上述目的，本发明还提供一种车型和车辆状态的信号推送装置，包括存储器、处理器及存储在存储器上并可在处理器上运行的车型和车辆状态的信号推送装置处理程序，所述处理器执行所述车型和车辆状态的信号推送装置处理程序时实现上述车型和车辆状态的信号推送方法的步骤。

此外，为实现上述目的，本发明还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有车型和车辆状态的信号推送程序，其特征在于，所述车型和车辆状态的信号推送程序被处理器执行时实现上述车型和车辆状态的信号推送方法的步骤。

本发明通过重新定义协议架构，对原协议架构的规则进行优化，提高了用户终端和云端之间的信息传递效率和信息容量，通过增加推送模块，将协议架构中所能推送的车型状态和车辆状态的信号项最大化，满足了更多用户的远程控制需求，通过扩展字节，实现了新增车型状态和车辆状态的信号项直接添加使用的需求，避免了开发新的协议和接口所造成的多方资源的浪费，提升了用户的用车体验度。

附图说明

图1是本发明实施例方案涉及的硬件运行环境的终端结构示意图；

图2为本发明车型和车辆状态的信号推送方法一实施例的流程示意图；

图3为图2中步骤S40的步骤的细化流程示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本发明实施例的主要解决方案是：通过重新定义新协议架构，在新协议架构上增加原协议架构之外的预置车型状态和预置车辆状态的信号项，并在新协议架构上预留多个空信号项的位置。

由于现有技术中原协议架构的限制，使得传统的车辆车况状态推送的设计满足不了更新迭代的需求，只能重新开发新的协议和接口，或者通过车辆FOTA平台升级，影响了用户的用车体验感，容易造成多方资源的浪费。

本发明提供一种车型和车辆状态的信号推送方法，能够使新的车型信号和新的车辆信号不需要开发新的协议和接口，也不需要通过FOTA平台升级就能直接使用，解决了重新开发造成的资源浪费的问题，提升了用户的用车体验感。

如图1所示，图1是本发明实施例方案涉及的硬件运行环境的终端结构示意图。

本发明实施例车型和车辆状态的信号推送装置可以是PC，也可以是智能手机、平板电脑、便携计算机等具有显示功能的可移动式终端设备。

如图1所示，该终端可以包括：处理器1001，例如CPU，网络接口1004，用户接口1003，存储器1005，通信总线1002。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display)、输入单元比如键盘(Keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1005可以是高速RAM存储器，也可以是稳定的存储器(non-volatile memory)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。

可选地，信号推送装置还可以包括摄像头、RF(Radio Frequency，射频)电路，传感器、音频电路、WiFi模块等等。其中，传感器比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示屏的亮度，接近传感器可在移动终端移动到耳边时，关闭显示屏和/或背光。作为运动传感器的一种，重力加速度传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别移动终端姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；当然，移动终端还可配置陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

本领域技术人员可以理解，图1中示出的信号推送装置结构并不构成对信号推送装置的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图1所示，作为一种计算机存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及车型和车辆状态的信号推送程序。

在图1所示的终端中，网络接口1004主要用于连接后台服务器，与后台服务器进行数据通信；用户接口1003主要用于连接客户端(用户端)，与客户端进行数据通信；而处理器1001可以用于调用存储器1005中存储的车型和车辆状态的信号推送程序，并执行以下操作：

接收用于定义原协议架构的相关指令信息；

进一步地，处理器1001可以调用存储器1005中存储的车型和车辆状态的信号推送程序，还执行以下操作：

运行推送模块的文档，在所述原协议架构上创建推送模块。

将所述新增信号项发送到所述新协议架构上。

接收用户终端上传的当前车型信号和当前车辆信号；

参照图2，本发明一实施例提供一种车型和车辆状态的信号推送方法，所述车型和车辆状态的信号推送方法包括：

步骤S10，接收用于定义原协议架构的相关指令信息；

需要说明的是，本发明的执行主体是定义后的MQTT(Message Queuing TelemetryTransport，消息队列遥测传输)协议架构，即新协议架构。原协议架构基于接收到的相关指令信息，确定与该指令匹配的模块的基本信息。

指令信息是指计算机硬件进行某种操作的命令，本实施例中的原协议架构就是根据指令指挥和控制计算机各部件协调动作，实现对指令信息的加工和处理。

相关指令信息是指与用来定义原协议架构相关的指令信息，例如推送模块的相关指令信息。

MQTT协议架构，具有轻量、简单、开发和易于实现的特点，这些特点使得MQTT协议架构的适用范围非常广泛。而在车联网驾驶领域中，智能车机需要基于MQTT协议架构与云端进行信息交互。

需要注意的是，本发明中的云端指车控中心。

可选地，步骤S10中接收用于定义原协议架构的相关指令信息的步骤之前，还包括：

步骤A，基于所述原协议架构的后台执行qmake命令，生成用于构建所述推送模块的Makefile文件，得到构建所述推送模块的相关指令信息。

在原协议架构的qtmqtt的源码库目录里执行qmake命令后，生成的Makefile文件用于构建推送模块。

qmake命令的作用主要是生成一个执行编译的Makefile文件。

可以将Makefile文件理解为一个编译规则，优点是可以自动化编译，只需将要链接的推送模块库文件放在Makefile文件中，并制定相应的规则和对应的链接顺序后，执行make命令，与推送模块对应的相关指令信息就会自动编译，省略了动手编译中的参数选择和命令，减少了编译所需耗费的时间。

推送模块主要是为了增加原协议架构之外的预置车型信号和预置车辆信号的信号项，原协议架构只推送常用的车型状态和车辆状态的信号项，而未考虑到不常用的车型状态和车辆状态的信号项需要推送的情况，虽然满足了原协议架构的容量需求，但后续需用到不常用的车型状态和车辆状态的信号项时，每增加一个原协议架构没有的信号项，云端都需开发新的协议和接口。而通过增加推送模块，在原协议架构的基础上增加目前现有的可以推送的车型状态和车辆状态的信号项，解决了不常用的车型状态和车辆状态的信号项不兼容协议和接口时，需要开发新的协议和接口或需要到车辆FOTA平台远程升级的问题，降低了人力和物力的资源浪费。

在生成的Makefile文件中输出构建推送模块的库文件和链接顺序后，得到构建推送模块的相关指令信息。

步骤S20，基于所述相关指令信息，在所述原协议架构上创建推送模块，以构建新协议架构；

相关的指令信息里包含了指明该指令要完成的操作的类型或性质，例如本发明里的指令信息为输出推送模块的数据，和指明操作对象的内容或所在的存储单元地址，例如本发明的操作对象为原协议架构的服务器地址。

可选地，步骤S20中基于所述相关指令信息，在所述原协议架构上创建推送模块的步骤包括：

步骤B1，将所述相关指令信息安装到Qt的安装目录中，生成推送模块的文档；

步骤B2，运行推送模块的文档，在所述原协议架构上创建推送模块。

将输出推送模块的数据和原协议架构的服务器地址打包成相关指令信息，并安装到Qt的安装目录中，进而生成安装推送模块的文档，最后在原协议架构上成功运行生成的推送模块的文档，将原协议架构转变为新协议架构后，才算推送模块创建成功。

不同版本的Qt的安装目录大同小异，本发明Qt的安装目录的版本为Qt5.9.0，里面包含了Qt类库和源代码、帮助文档、示例代码、开发工具集、VC运行库和Qt安装管理工具。

步骤S30，基于所述推送模块，将所述原协议架构之外的预置车型状态和预置车辆状态的新增信号项增加到新协议架构上；

推送模块创建成功后，对原协议架构的规则进行了优化，相对于原协议架构MQTT上固定的常用的车型状态和车辆状态的推送，新协议架构增加了不常用的车型状态和车辆状态的信号项，满足了小部分用户的远程控制需求，例如使用原协议架构，用户在用户终端上只能进行空调、车锁的远程操控，而在使用新协议架构后，用户除了能在用户终端上对空调和车锁进行远程操控，还能远程在用户终端上直接查看发动机的状态，省去了用户需到4S店查看发动机状态的时间和精力，节约了重新开发车型状态和车辆状态对应的协议和接口所需的时间，减少了开发的工作量和开发的费用。

信号项是指上传的车型状态和车辆状态对应的协议和接口。

车型状态是指车企开发的具体车型的标识码。

车辆状态是指用户终端发出的具体指令，例如远程启动车辆、远程预约空调和远程打开车窗或关闭车窗等。

可选地，步骤S30中基于所述推送模块，将所述原协议架构之外的预置车型状态和预置车辆状态的新增信号项增加到所述新协议架构上的步骤之前，还包括：

步骤C1，接收所述原协议架构中未存在的车型和车辆状态的信号推送的新增信号项；

云端获取现有可能推送的所有车型状态和车辆状态的信号项，将获取的所有车型状态和车辆状态的信号项，与原协议架构中固定的信号项进行对比分析后，得到的与原协议架构不匹配的信号项为新增信号项，即原协议架构之外的预置的新增信号项，并将原协议架构之外的预置的新增信号项发送至新协议架构中。

步骤C2，将所述新增信号项发送到所述新协议架构上。

接收云端发送的原协议架构之外的预置的新增信号项，并将其全部添加至新协议架构上，最大化新协议架构上车型状态和车辆状态的信号项，充分考虑到了不常用的信号项需要推送到用户终端的情况，满足了用户的需求，减少了开发信号项对应的协议和接口所需浪费的时间。

步骤S40，基于所述原协议架构上的控制消息可变头和控制消息固定头扩展所述新协议架构字节，在所述新协议架构增加所述新增信号项的基础上预留空信号项的备用位置。

在原协议架构的数据结构中，包括固定头、可变头和消息体，而在本发明中，主要是控制消息可变头和控制消息固定头。

扩展新协议架构字节所占用的字节在原协议架构的应用中并没有起到作用，因此不会对新协议架构产生影响。

需要说明的是，本发明中车联网驾驶领域是基于原协议架构实现的，原协议架构采用发布或订阅的方式进行消息的交互，原协议架构中的TopicName占据至少3个字节，但在通常情况下，TopicName占据的字节远远大于3个字节，容易造成容量资源的浪费。另外在原协议架构中，某些字节的字节值永远为0，例如PINGREQ和PINGRESP扩展后的剩余字节和控制消息的类型为0和15的保留值。

因此可以对TopicName、PINGREQ和PINGRESP、保留值为0和15的字节进行扩展，从而达到扩大新协议架构的信息容量的目的，为预留空信号项的位置提供基础。

可选地，步骤S40中基于所述原协议架构上的控制消息可变头和控制消息固定头扩展所述新协议架构字节的步骤包括：

步骤D1，基于所述控制消息可变头为计算控制消息可变头中TopicName的多余字节，并将多余字节转化为TopicID，所述TopicID用于扩展字节；

原协议架构在进行数据收发时，通常采用SUBSCRIBE/PUBLISH命令，该命令的格式要求必须有TopicName，并且该TopicName必须是字符串，因此至少占用3个字节，其中，该字符串前2个字节表示其长度，因此TopicName至少需要1个字节。当传输的数据类型较多时，TopicName会占用多个的字节数以区分数据类型，但占用的字节多为不用的字节。

为了将TopicName多占用的不用的字节用于扩展字节，将TopicName多占用的字节替换为TopicID，避免因数据类型较多导致TopicName所占用字节增多的问题出现，进而可得到用于扩展字节的TopicID。

步骤D2，基于所述控制消息固定头为基于PINGREQ和PINGRESP进行扩展，确定剩余字节用于扩展字节。

将PINGREQ和PINGRESP进行扩展，确定剩余字节作为扩展字节，并根据控制消息的类型，确定控制消息的类型为0和15的保留值的字节用于扩展字节。

因为控制消息的类型为0和15的保留值是被保留未使用的，因此可以启用保留值为0和15的字节用于扩展字节。

充分利用了原协议架构中多余和空闲的字节，将其用于优化原协议架构MQTT的规则，使协议架构有更多的信息容量去预留多个空信号项的位置，例如在使用原协议架构时，车企每开发出一款新车型，都需针对新车型状态对应的协议和接口进行开发后，才能在用户终端上进行展示，而在使用新协议架构时，无需另外进行协议和接口的开发，就能在用户终端上直接进行展示，从而节省开发新的协议和接口所需的时间和费用，达到降本增效的目的。

可选地，步骤S40中在所述新协议架构增加所述新增信号项的基础上预留空信号项的备用位置的步骤包括：

步骤E1，根据扩展新协议架构字节的长度计算所述新协议架构的容量；

新协议架构的容量是基于现有技术和新协议架构扩展字节后的长度得到的。

步骤E2，基于所述容量计算可预留空信号项的备用位置数量，并增加相应数量的备用位置。

基于计算结构可得出新协议架构的容量可预留30-50个空信号项的位置，用于满足不同车型状态和车辆状态的信号项的需求。

在本实施例中，通过重新定义协议架构，对原协议架构的规则进行优化，提高了用户终端和云端之间的信息传递效率和信息容量，通过增加推送模块，将原协议架构中推送的车型状态和车辆状态的信号项最大化，避免了开发新的协议和接口所造成的多方资源的浪费，通过扩展字节，满足了车型状态和车辆状态更新迭代的需求，提升了用户的用车体验感。

进一步的，参照图3，本发明一实施例提供一种车型和车辆状态的信号推送方法，步骤S40中基于所述原协议架构上的控制消息可变头和控制消息固定头扩展所述新协议架构字节，在所述新协议架构增加所述新增信号项的基础上预留空信号项的备用位置的步骤之后，还包括：

步骤S41，接收用户终端上传的当前车型信号和当前车辆信号；

云端接收用户终端上传的当前车型状态和当前车辆状态的信当前号项，并将接收到的当前车型状态和当前车辆状态的当前信号项发送至MQTT协议架构上，利于判断所接收的当前信号项是否已存在于MQTT协议架构上。

步骤S42，判断所述当前车型信号和当前车辆信号对应的当前信号项是否存在于所述新协议架构上；

通过判断接收的当前车型状态和当前车辆状态的当前信号项是否存在于新协议架构上是为了确认是否要调用预留的空信号项的位置，利于云端作出符合当前需求的判断。

可选地，步骤S42中述判断所述当前车型信号和当前车辆信号对应的当前信号项是否存在于所述新协议架构上的步骤包括：

步骤F1，对所述用户终端上传的当前车型信号和当前车辆信号对应的当前信号项进行解码，得到与所述当前信号项对应的协议和接口。

步骤F2，将所述对应的协议和接口与所述新协议架构上的协议和接口进行对比分析，判断所述对应的协议和接口是否存在于所述新协议架构上，进而得出当前信号项是否存在于新协议架构上。

云端通过对上传的当前车型状态和当前车辆状态的当前信号项进行解码，可直接得到上传的当前信号项对应的协议和接口，将得到的协议和接口与新协议架构上的协议和接口进行对比，可知上传的当前信号项对应的协议和接口是否存在于新协议架构上，进而可以判断上传的当前信号项是否存在于新协议架构上，即上传的当前信号项对应的协议和接口存在于新协议架构上，判定上传的当前信号项存在于新协议架构上，上传的当前信号项对应的协议和接口不存在于新协议架构上，判定上传的当前信号项不存在于新协议架构上，从而加快了云端对用户终端上传的远程控制指令的反馈速度，提升了用户的用车体验度。

步骤S43，若所述新协议架构上存在所述当前信号项，则直接调用新协议架构上所述当前信号项用于展示当前车型状态和当前车辆状态；

若解码后的协议和接口存在于新协议架构上，说明该信号项是现有的，可直接调用对应的信号项，直接向用户展示当前的车型和车辆状态，不需要调用预留的空信号项的位置，避免造成资源的浪费。

步骤S44，若所述新协议架构上不存在所述当前信号项，则调用预留的空信号项的备用位置用于展示当前车型状态和当前车辆状态。

若解码后的协议和接口不存在于新协议架构上，说明该信号项需要调用预留的空信号项的位置，通过预留的空信号项，可以在不改变云端、智能车机和用户终端设计的情况下，直接进行车辆的远程控制，加快了远程控制项目的进程，节省了通过车辆FOTA平台进行升级所产生的人力和物力的费用。

在本实施例中，通过基于用户终端上传的车型状态和车辆状态，从而判断其对应的信号项的协议和接口是否是已存在于新协议架构上的，方便了云端进行快速对比，从而提取出不同信号项，通过将存在于新协议架构上的信号项直接调用对应的信号项节约了重新开发车型状态和车辆状态对应的协议和接口所需的时间，减少了开发的工作量和开发的费用，通过将不存在于新协议架构上的信号项调用预留的空信号项的位置，减少新车型信号和新车辆信号接入开发的工作量，提高了远程控制的开发效率，并使用户终端能准确展示用户车辆的状态。

此外，本发明实施例还提出一种车型和车辆状态的信号推送装置，所述车型和车辆状态的信号推送装置包括存储器、处理器及存储在存储器上并可在处理器上运行的车型和车辆状态的信号推送处理程序，所述处理器执行所述车型和车辆状态的信号推送处理程序时实现上述车型和车辆状态的信号推送方法的步骤。

此外，本发明还提出一种计算机可读存储介质，所述计算机可读存储介质上存储有车型和车辆状态的信号推送程序，所述车型和车辆状态的信号推送程序被处理器执行时实现上述车型和车辆状态的信号推送方法的步骤。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。

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

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在如上所述的一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims

1.一种车型和车辆状态的信号推送方法，其特征在于，车型和车辆状态的信号推送方法应用于协议架构，所述方法包括以下步骤：

接收用于定义原协议架构的相关指令信息；

2.如权利要求1所述的车型和车辆状态的信号推送方法，其特征在于，所述接收用于定义原协议架构的相关指令信息的步骤之前，还包括：

3.如权利要求2所述的车型和车辆状态的信号推送方法，其特征在于，所述基于所述相关指令信息，在所述原协议架构上创建推送模块的步骤包括：

运行推送模块的文档，在所述原协议架构上创建推送模块。

4.如权利要求3所述的车型和车辆状态的信号推送方法，其特征在于，所述基于所述推送模块，将所述原协议架构之外的预置车型状态和预置车辆状态的新增信号项增加到所述新协议架构上的步骤之前，还包括：

将所述新增信号项发送到所述新协议架构上。

5.如权利要求4所述的车型和车辆状态的信号推送方法，其特征在于，所述基于所述原协议架构上的控制消息可变头和控制消息固定头扩展所述新协议架构字节的步骤包括：

6.如权利要求5所述的车型和车辆状态的信号推送方法，其特征在于，所述在所述新协议架构增加所述新增信号项的基础上预留空信号项的备用位置的步骤包括：

7.如权利要求6所述的车型和车辆状态的信号推送方法，其特征在于，所述基于所述原协议架构上的控制消息可变头和控制消息固定头扩展新协议架构字节，在所述协议架构增加所述新增信号项的基础上预留空信号项的位置的步骤之后，还包括：

接收用户终端上传的当前车型信号和当前车辆信号；

8.如权利要求7所述的车型和车辆状态的信号推送方法，其特征在于，所述判断所述当前车型信号和当前车辆信号对应的当前信号项是否存在于所述新协议架构上的步骤包括：

9.一种车型和车辆状态的信号推送装置，其特征在于，包括存储器、处理器及存储在存储器上并可在处理器上运行的车型和车辆状态的信号推送处理程序，所述处理器执行所述车型和车辆状态的信号推送处理程序是实现权利要求1-8中任一项所述的车型和车辆状态的信号推送方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有车型和车辆状态的信号推送程序，其特征在于，车型和车辆状态的信号推送程序被处理器执行时实现权利要求1-8中任一项所述的车型和车辆状态的信号推送方法的步骤。