车况数据包解析方法、装置、车联网平台以及车辆

技术领域

本申请涉及车辆领域，并且更具体地，涉及车辆领域中的一种车况数据包解析方法、装置、车联网平台以及车辆。

背景技术

随着汽车工业的发展，如何提高汽车使用的安全性和便捷性是汽车智能化发展的方向。比如，为车主提供远程的车况数据实时查看功能，以使得车主可以及时了解到车辆当前状态。

车况数据的分享过程一般为：车辆按照预设周期向云端平台上报车况数据包，云端平台在接收到车况数据包后，对车况数据包进行解析，以便将车况数据包中的信号数值，解析转换为具体的状态信息，反馈给车主所持有的终端，以便车主查看和了解车辆当前状态。

而由于车辆使用过程中，存在车况数据包变更的情况，若仍然使用原有解析方案，可能会导致车况数据包解析失败。

发明内容

本申请提供了一种车况数据包解析方法、装置、车联网平台以及车辆，该方法可以提高车况数据包的解析成功率。

第一方面，提供了一种车况数据包解析方法，该方法由车联网平台执行，该方法包括：

接收车辆发送的车况数据包；

确定车况数据包对应解析方案的匹配方式；

在匹配方式为第一匹配方式的情况下，基于车况数据包中的解析方案标识，确定车况数据包对应的目标解析方案，解析方案标识是车辆进行软件升级后添加在车况数据包中的；

在匹配方式为第二匹配方式的情况下，基于车辆发送的车型标识，确定车况数据包对应的目标解析方案；

基于目标解析方案对车况数据包进行解析，得到车辆的目标车况信息。

上述技术方案中，提供了一种车况数据包的解析方式：车联网平台在接收到车辆上传的车况数据包后，首先确定车况数据包对应解析方案的匹配方式，若匹配方式为第一匹配方式，可以基于车况数据包中的解析方案标识匹配对应的解析方案，保障完成软件升级的车辆对应车况数据包的成功解析；若匹配方式为第二匹配方式，根据车型标识匹配解析方案，保障了未完成软件升级的车辆对应车况数据包的成功解析；且由于对完成软件升级的车辆的车况数据包进行解析时，是采用区别于未升级车辆的解析方案的匹配方式，使得对于使用环境中同时存在已升级车辆和未升级车辆的情况，通过采用不同的匹配方式，均可以准确匹配到合适的解析方案，可以兼顾多种情况下车况数据包的解析，进而提高了车况数据包的解析成功率。

结合第一方面，在某些可能的实现方式中，确定车况数据包对应解析方案的匹配方式，包括：识别车况数据包中是否包括升级标识符，升级标识符是车辆进行软件升级后添加在车况数据包中的；在识别到升级标识符的情况下，确定车况数据包对应解析方案的匹配方式为第一匹配方式；在未识别到升级标识符的情况下，确定车况数据包对应解析方案的匹配方式为第二匹配方式。

结合第一方面和上述实现方式，在某些可能的实现方式中，识别车况数据包中是否包括升级标识符，包括：解析车况数据包中时间戳的目标相邻字符；在目标相邻字符为升级标识符的情况下，确定识别到车况数据包中的升级标识符；在目标相邻字符为信号个数的情况下，确定车况数据包中不包括升级标识符，信号个数指示车况数据包中包括的车况状态信号的个数。

上述技术方案中，通过在车况数据包中时间戳的目标相邻字符添加升级标识符，以使得车联网平台可以通过识别时间戳的目标相邻字符是否为升级标识符，判断车况数据包对应解析方案的匹配方式。区别于原有车况数据包中时间戳的目标相邻字符为信号个数，通过不同的车况数据包结构，使得车联网平台可以识别不同的匹配方式，提高匹配方式的确定准确性，进而提高车况数据包的解析准确性和成功率。

第二方面，提供了一种车况数据包解析方法，该方法由车辆执行，该方法包括：

在车辆完成软件升级的情况下，获取软件升级后车况数据包的解析方案标识，不同解析方案标识对应车况数据包的不同解析方案；

在车辆存在车况数据上报需求的情况下，基于车辆当前的车况状态信号和解析方案标识，生成车辆对应的车况数据包；

向车联网平台发送车况数据包，车联网平台用于在识别到车况数据包对应解析方案的匹配方式是第一匹配方式的情况下，基于解析方案标识，确定车况数据包对应的目标解析方案，并使用目标解析方案对车况数据包进行解析，得到车辆的目标车况信息。

上述技术方案中，提供了一种车况数据包的解析方式：在车辆完成软件升级后，可以获取车况数据包的解析方案标识，并基于解析方案标识和车况状态信号生成车况数据包，使得车联网平台可以基于车况数据包中的解析方案标识匹配对应的解析方案，保障完成软件升级的车辆对应车况数据包的成功解析；而且，对完成软件升级的车辆的车况数据包进行解析时，是采用区别于未升级车辆的解析方案匹配方式，对于未进行软件升级的车辆，仍然可以保留根据车型标识匹配解析方案，使得可以兼顾已升级车辆和未升级车辆的解析成功率；此外，对于已经升级的车辆，仅从解析方案标识维度进行解析方案的维护，而不考虑车型维度，也可以支持后续软件升级的灵活性和多样性。

结合第二方面，在某些可能的实现方式中，基于车辆当前的车况状态信号和解析方案标识，生成车辆对应的车况数据包，包括：获取车辆的升级标识符，升级标识符用于指示车辆完成软件升级；基于车辆当前的车况状态信号、升级标识符和解析方案标识，生成车辆对应的车况数据包，车联网平台用于基于升级标识符确定车况数据包对应解析方案的匹配方式。

结合第二方面和上述实现方式，在某些可能的实现方式中，基于车辆当前的车况状态信号、升级标识符和解析方案标识，生成车辆对应的车况数据包，包括：获取车况状态信号的时间戳和信号个数；在时间戳和信号个数之间添加升级标识符和解析方案标识，以及在信号个数之后添加车况状态信号，生成车辆对应的车况数据包，升级标识符与时间戳相邻，且时间戳与信号个数相邻。

上述技术方案中，为了使得车联网平台可以区分原有车况数据包以及软件升级后的车况数据包，本申请还提出了在原有车况数据包结构的基础上，在时间戳和信号个数之间增加升级标识符和解析方案标识，且时间戳后的相邻字符为升级标识符。以使得车联网平台均可以在识别到时间戳后，识别时间戳后的相邻字符是否为升级标识符，来判断车况数据包对应解析方案的匹配方式，提高车联网平台确定匹配方式的准确性，进而提高车况数据包的解析成功率。

结合第二方面和上述实现方式，在某些可能的实现方式中，在车辆完成软件升级的情况下，获取软件升级后车况数据包的解析方案标识，包括：

在车辆完成软件升级的情况下，确定软件升级是否更改车况数据包的数据包长度；在车况数据包的数据包长度更改的情况下，获取软件升级后的车况数据包的解析方案标识；该方法还包括：在车况数据包的数据包长度未更改，且车辆存在车况数据上报需求的情况下，基于车辆当前的车况状态信号、信号个数和时间戳，生成车辆对应的车况数据包；向车联网平台发送车况数据包和车型标识，车联网平台用于在识别到车况数据包对应解析方案的匹配方式是第二匹配方式的情况下，基于车型标识，确定车况数据包对应的目标解析方案，并使用目标解析方案对车况数据包进行解析，得到车辆的目标车况信息。

上述技术方案中，考虑到软件升级也可能存在不对车况数据包更改的情况，本申请还提出了在车辆完成软件升级后，首先判断软件升级是否会更改车况数据包，若更改再获取对应的解析方案标识，并在车况数据包中添加该解析方案标识；若未更改，则会在上传车况数据包的同时上传车型标识，以使得车联网平台可以基于车型标识匹配对应的解析方案；使得车联网平台对于已升级但是车况数据包未更改的情况，仍然可以准确匹配对应的解析方案，进一步提高车况数据包的解析成功率。

第三方面，提供了一种车况数据包解析装置，该装置包括：

接收模块，用于接收车辆发送的车况数据包；

第一确定模块，用于确定车况数据包对应解析方案的匹配方式；

第二确定模块，用于在匹配方式为第一匹配方式的情况下，基于车况数据包中的解析方案标识，确定车况数据包对应的目标解析方案，解析方案标识是车辆进行软件升级后添加在车况数据包中的；

第三确定模块，用于在匹配方式为第二匹配方式的情况下，基于车辆发送的车型标识，确定车况数据包对应的目标解析方案；

解析模块，用于基于目标解析方案对车况数据包进行解析，得到车辆的目标车况信息。

结合第三方面，在某些可能的实现方式中，该第一确定模块，还用于：识别车况数据包中是否包括升级标识符，升级标识符是车辆进行软件升级后添加在车况数据包中的；在识别到升级标识符的情况下，确定车况数据包对应解析方案的匹配方式为第一匹配方式；在未识别到升级标识符的情况下，确定车况数据包对应解析方案的匹配方式为第二匹配方式。

结合第三方面和上述实现方式，在某些可能的实现方式中，该第一确定模块，还用于：解析车况数据包中时间戳的目标相邻字符；在目标相邻字符为升级标识符的情况下，确定识别到车况数据包中的升级标识符；在目标相邻字符为信号个数的情况下，确定车况数据包中不包括升级标识符，信号个数指示车况数据包中包括的车况状态信号的个数。

第四方面，提供了一种车况数据包解析装置，该装置包括：

获取模块，用于在车辆完成软件升级的情况下，获取软件升级后车况数据包的解析方案标识，不同解析方案标识对应车况数据包的不同解析方案；

第一生成模块，用于在车辆存在车况数据上报需求的情况下，基于车辆当前的车况状态信号和解析方案标识，生成车辆对应的车况数据包；

第一发送模块，用于向车联网平台发送车况数据包，车联网平台用于在识别到车况数据包对应解析方案的匹配方式是第一匹配方式的情况下，基于解析方案标识，确定车况数据包对应的目标解析方案，并使用目标解析方案对车况数据包进行解析，得到车辆的目标车况信息。

结合第三方面，在某些可能的实现方式中，该第一生成模块，还用于：获取车辆的升级标识符，升级标识符用于指示车辆完成软件升级；基于车辆当前的车况状态信号、升级标识符和解析方案标识，生成车辆对应的车况数据包，车联网平台用于基于升级标识符确定车况数据包对应解析方案的匹配方式。

结合第四方面和上述实现方式，在某些可能的实现方式中，该第一生成模块，还用于：获取车况状态信号的时间戳和信号个数；在时间戳和信号个数之间添加升级标识符和解析方案标识，以及在信号个数之后添加车况状态信号，生成车辆对应的车况数据包，升级标识符与时间戳相邻，且时间戳与信号个数相邻。

结合第二方面和上述实现方式，在某些可能的实现方式中，该获取模块，还用于：在车辆完成软件升级的情况下，确定软件升级是否更改车况数据包的数据包长度；在车况数据包的数据包长度更改的情况下，获取软件升级后的车况数据包的解析方案标识；该装置还包括：第二生成模块，用于在车况数据包的数据包长度未更改，且车辆存在车况数据上报需求的情况下，基于车辆当前的车况状态信号、信号个数和时间戳，生成车辆对应的车况数据包；第二发送模块，用于向车联网平台发送车况数据包和车型标识，车联网平台用于在识别到车况数据包对应解析方案的匹配方式是第二匹配方式的情况下，基于车型标识，确定车况数据包对应的目标解析方案，并使用目标解析方案对车况数据包进行解析，得到车辆的目标车况信息。

第五方面，提供了一种车联网平台，包括存储器和处理器。该存储器用于存储可执行程序代码，该处理器用于从存储器中调用并运行该可执行程序代码，使得该车联网平台执行上述第一方面或第一方面任意一种可能的实现方式中的车况数据包解析方法。

第六方面，提供了一种车辆，包括存储器和处理器。该存储器用于存储可执行程序代码，该处理器用于从存储器中调用并运行该可执行程序代码，使得该车辆执行上述第二方面或第二方面任意一种可能的实现方式中的车况数据包解析方法。

第七方面，提供了一种计算机程序产品，该计算机程序产品包括：计算机程序代码，当该计算机程序代码在计算机上运行时，使得该计算机执行上述方面所述的车况数据包解析方法。

第五方面，提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序代码，当该计算机程序代码在计算机上运行时，使得该计算机执行上述方面所述的车况数据包解析方法。

附图说明

图1是本申请实施例提供的实施环境示意图；

图2是车况数据包的上传时机示意图；

图3是本申请实施例提供的一种车况数据包解析方法的示意性流程图；

图4是本申请实施例提供的另一种车况数据包解析方法的示意性流程图；

图5是本申请实施例提供的一种车况数据包的解析过程示意图；

图6是本申请实施例提供的另一种车况数据包解析方法的示意性流程图；

图7是本申请实施例提供的另一种车况数据包解析方法的示意性流程图；

图8是本申请实施例提供的一种车况数据包的结构示意图；

图9是本申请实施例提供的一种车况数据包解析装置的结构示意图；

图10是本申请实施例提供的另一种车况数据包解析装置的结构示意图；

图11是本申请实施例提供的一种车联网平台的结构示意图；

图12是本申请实施例提供的一种车辆的结构示意图。

具体实施方式

下面将结合附图，对本申请中的技术方案进行清楚、详尽地描述。其中，在本申请实施例的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B：文本中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况，另外，在本申请实施例的描述中，“多个”是指两个或多于两个。

以下，术语“第一”、“第二”仅用于描述目的，而不能理解为暗示或暗示相对重要性或隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者多个该特征。

为了使得车主可以实时通过移动终端查看车况(车辆状态)，通常提供有对应的车辆APP，通过车辆-车联网平台-车辆APP三者交互，实现实时车况反馈和查看功能。图1是本申请实施例提供的实施环境示意图。如图1所示，该实施环境中至少包括车辆110、车联网平台120和移动终端130。

其中，移动终端130中安装或运行有车辆110所关联的车辆APP，移动终端是车辆APP的车主所持有的终端；车联网平台120可以是车辆APP的后台服务器，或者是车辆的后台服务器；三者可以通过无线网络或者有线网络进行通信。可选地，移动终端也可以是对车辆110具备驾驶权限的其他驾驶对象(非车主)所持有的终端，只要驾驶对象所持有的终端中安装或运行有车辆110对应的车辆APP，该驾驶对象即可以通过车辆APP查看车辆110的车况。

在车况数据上报过程中，车辆110按照预设周期，每隔预设时间段向车联网平台120上报车况数据包，或者，在按照预设周期间隙，若检测到车况数据发生变更，也可以向车联网平台120上报变更后的车况数据包；对应的车联网平台120接收到车辆110上报的车况数据包后，对车况数据包进行解析，并将解析得到的车况信息反馈给移动终端130，使得用户可以通过移动终端130中的车辆APP，实时查看车辆110的车况。

图2是车况数据包的上传时机示意图。如图2所示，车辆按照车况数据包的上传周期，向车联网平台上报周期数据包T、周期数据包T+10以及周期数据包T+20；而且，若强感知信号发生数值变化，车辆也会立即将变化后的车况变更数据T+x、车况变更数据T+10+y上报给车联网平台。

由于车辆上传的车况数据包中包含的是车况状态信号，也可以称为强感知信号，无法直接对应具体的车况信息，比如，车况状态信号可以是：001，对应的车况信息可能是车门开启；对应车联网平台在接收到车况数据包后，需要按照预先设置的解析方案，将车况数据包中的车况状态信号解析为用户可理解的车况信息。

在解析车况信息时，考虑到不同车型需要上报的车况状态信号不同，对应车况数据包的数据包长度可变，而不同长度的车况数据包所对应的解析方案不同。一般在车联网平台上维护有车型标识与解析方案的关联关系，以使得车联网平台可以在接收到车况数据包后，根据车型标识，选取对应的解析方案，对车况数据包进行解析。

而在车辆销售之后，车辆可能会进行定期的软件更新(FOTA)，软件更新可能会带来车况状态信号的增加或删减，从而影响车况数据包的数据包长度，若此时仍然使用车型标识进行解析，显然会导致车况数据包解析错误。若直接在车联网平台更新车型标识对应的解析方案，虽然会使得软件更新后车辆上传的车况数据包解析成功，而对于未完成软件更新的车辆，车况数据包的数据包长度仍然是原有长度，使用车型标识匹配到的解析方案是更新后的解析方案，显然会导致未进行软件更新的车辆的车况数据包解析错误。

针对上述存在的车况数据包解析错误的问题，本申请提出了一种新的车况数据解析方案，可以满足软件更新后的车辆的车况数据包解析需求，同时不对原有解析方案造成影响。图3是本申请实施例提供的一种车况数据包解析方法的示意性流程图。应理解，该方法可以应用于图1所示的车联网平台120中。

示例性的，如图3所示，该方法300包括：

步骤301，接收车辆发送的车况数据包。

在车辆具备车况数据上报需求时，车辆会生成车况数据包，并向车联网平台发送该车况数据包，对应车联网平台接收到车辆发送的车况数据包，并由车联网平台根据预设的解析方案对其进行解析，以得到具体的车况信息，反馈给车主所持有的终端。

步骤302，确定车况数据包对应解析方案的匹配方式。

在车辆完成软件升级的情况下，考虑到软件升级可能会导致车况数据包的数据包长度发生改变，对应车况数据包的解析方案发生变更。而考虑到软件升级与否是车主的自主行为，导致环境中存在已经完成软件升级的车辆，车况数据包发生变更，还存在未完成软件升级的车主，车况数据包还是原有格式，而对于同一车型，已完成软件升级和未进行软件升级的车辆上报的车况数据包存在差异，解析方案也存在差异则为了兼顾未完成软件升级和已完成软件升级的车辆的车况数据包的解析，对于已经完成软件升级的车辆，提供一种新的车况数据包的解析方式：为车况数据包分配解析方案标识(也可以称为方案号)，并将解析方案标识与对应车况数据包的解析方案关联，使得对于完成软件升级的车辆的车况数据包，可以按照不同解析方案标识匹配对应的解析方案，而并非按照车型维度去匹配车况数据包的解析方案，避免解析错误；而对于未进行软件升级的车辆，仍然可以按照原有根据车型维度匹配解析方案。

对应一种可能的实施方式中，在车联网平台接收到车辆上传的车况数据包后，首先需要确定该车况数据包对应解析方案的匹配方式，比如，是按照车型维度去匹配，还是按照方案号去匹配，进而按照对应的匹配方式，确定车况数据包对应的解析方案。

步骤303，在匹配方式为第一匹配方式的情况下，基于车况数据包中的解析方案标识，确定车况数据包对应的目标解析方案，解析方案标识是车辆进行软件升级后添加在车况数据包中的。

对于未进行软件升级的，仍然按照车型维度去匹配，对于进行过软件升级的，则可以按照方案号去匹配；对应分别设置有第一匹配方式和第二匹配方式，第一匹配方式对应按照方案号去匹配，第二匹配方式对应按照车型维度去匹配。

对于第一匹配方式，为了使得车联网平台可以根据方案号进行解析方案的匹配，车辆在进行软件升级后，会在车况数据包中添加有解析方案的解析方案标识(也即方案号)。对应在车联网平台确定车况数据包对应解析方案的匹配方式为第一匹配方式的情况下，车联网平台可以从车况数据包中获取解析方案标识，进而根据解析方案标识，匹配车况数据包的目标解析方案。

可选地，在软件升级后，对于不同车型，若车况数据包的数据包长度相同(数据包长度相同具体指车况数据包中所包含的车况状态信号的信号类型和个数相同)，则为其分配相同的解析方案标识，也只需要维护一个解析方案，无需再区分车型进行解析方案的维护。

可选地，车辆在使用过程中可能会进行多次软件升级，若每次软件升级均会改变车辆的车辆数据包，则每次软件升级后，车况会获取最新的解析方案标识。

步骤304，在匹配方式为第二匹配方式的情况下，基于车辆发送的车型标识，确定车况数据包对应的目标解析方案。

对于第二匹配方式，为了使得车联网平台可以根据车型维度进行解析方案的匹配，车辆会在上传车况数据包的同时上传车型标识。对应在车联网平台确定车况数据包对应解析方案的匹配方式为第二匹配方式的情况下，车联网平台可以基于车辆发送的车型标识，匹配车况数据包的目标解析方案。

可选地，若软件升级与未升级之前相比，未改变车辆的车况数据包的数据包长度，即是车辆完成软件升级，也仍然上传车型标识和车况数据包，使得车联网平台基于车型标识进行解析方案的匹配。也就是说，若软件升级未改变车辆的车况数据包的数据包长度(与未升级之前一致)，则车辆发送的车况数据包中不包括解析方案标识。

步骤305，基于目标解析方案对车况数据包进行解析，得到车辆的目标车况信息。

进一步地，在车联网平台确定出车况数据包对应的目标解析方案后，可以基于目标解析方案对车况数据包进行解析，以分析得到车况数据包中每个车况状态信号所指示的车况信息，得到车辆的目标车况信息；进而将目标车况信息反馈给车主所持有的终端，使得用户可以在终端上实时查看车况。

示例性的，若从车况数据包中获取到车况状态信号为“000×01”，根据目标解析方案(信号与具体状态的映射关系)，可以解析得到对应的车况信息为：车窗开启状态。

综上所述，本申请实施例提供了一种车况数据包的解析方式：车联网平台在接收到车辆上传的车况数据包后，首先确定车况数据包对应解析方案的匹配方式，若匹配方式为第一匹配方式，可以基于车况数据包中的解析方案标识匹配对应的解析方案，保障完成软件升级的车辆对应车况数据包的成功解析；若匹配方式为第二匹配方式，根据车型标识匹配解析方案，保障了未完成软件升级的车辆对应车况数据包的成功解析；且由于对完成软件升级的车辆的车况数据包进行解析时，是采用区别于未升级车辆的解析方案的匹配方式，使得对于使用环境中同时存在已升级车辆和未升级车辆的情况，通过采用不同的匹配方式，均可以准确匹配到合适的解析方案，可以兼顾多种情况下车况数据包的解析，进而提高了车况数据包的解析成功率。

为了使得车联网平台可以区分未升级和已升级车辆，从而选取对应的匹配方式，车辆在生成车况数据包时，还在车况数据包中添加有升级标识符，以使得车联网平台可以根据是否识别到升级标识符，确定车况数据包对应解析方案的匹配方式。

图4是本申请实施例提供的另一种车况数据包解析方法的示意性流程图。应理解，该方法可以应用于图1所示的车联网平台120中。

示例性的，如图4所示，该方法400包括：

步骤401，接收车辆发送的车况数据包。

步骤401的实施方式可以参考步骤301，本实施例在此不做赘述。

步骤402，识别车况数据包中是否包括升级标识符，升级标识符是车辆进行软件升级后添加在车况数据包中的。

其中，升级标识符也可以称为固定标识符，是用于表征车况数据包中包含解析方案标识的一个符号；一般车辆进行软件升级后若车辆的车况数据包的数据包长度变更后，对应该升级标识符也可以表征车辆进行软件升级后，且软件升级导致数据包长度变更，需要根据解析方案标识进行方案匹配。

示例性的，升级标识符可以是“AAAA”，或者其他任意符号。本申请实施例不对升级标识符的具体样式进行限定。

由于升级标识符是可以指示车况数据包中包含解析方案标识，对应匹配方式应该为第一匹配方式，若没有升级标识符，对应匹配方式应该为第二匹配方式。则车联网平台可以通过识别车况数据包中是否包括升级标识符，来确定车况数据包对应解析方案的匹配方式。

原有车况数据包的数据包结构为：时间戳+信号个数+若干车况状态信号；车联网平台在解析车况数据包时，往往由前往后依次进行，若需要使得车联网平台在读取到车况状态信号之前，就可以获取到车况状态信息的具体解析方案，需要在时间戳和信号个数之间添加升级标识符和解析方案标识；为了使得车联网平台可以兼容旧车况数据包和新的车况数据包的读取和解析，设置车联网平台在读取到时间戳后，判断时间戳后相邻的两个字符，以识别解析相邻两个字符，来确定车况数据包的解析方式。

也就是说，在识别车况数据包中是否包含升级标识符时，主要解析车况数据包中时间戳的目标相邻字符(具体为相邻两个字符)，若解析到目标相邻字符是升级标识符的情况下，可以确定识别到车况数据包中的升级标识符，使得车联网平台可以进一步获取解析方案标识。反之，若解析到目标相邻字符是信号个数的情况下，确定车况数据包中不包括升级标识符，为原有车况数据包，根据车型维度进行解析方案的匹配。

示例性的，信号个数是车况状态信号的个数，比如，车辆中需要上报的强感知信号(车况状态信号)为20个，则信号个数为20。

步骤403，在识别到升级标识符的情况下，确定车况数据包对应解析方案的匹配方式为第一匹配方式。

在车联网平台识别到车况数据包中包括升级标识符的情况下，表示车况数据包中也包括有解析方案标识，需要根据解析方案标识匹配解析方案，对应确定车况数据包对应解析方案的匹配方式为第一匹配方式。

步骤404，在未识别到升级标识符的情况下，确定车况数据包对应解析方案的匹配方式为第二匹配方式。

在车联网平台识别到车况数据包中未包括升级标识符的情况下，标识车况数据包中未包括解析方案标识，需要根据车型标识匹配解析方案，对应确定车况数据包对应解析方案的匹配方式为第二匹配方式。

步骤405，在匹配方式为第一匹配方式的情况下，基于车况数据包中的解析方案标识，确定车况数据包对应的目标解析方案，解析方案标识是车辆进行软件升级后添加在车况数据包中的。

步骤406，在匹配方式为第二匹配方式的情况下，基于车辆发送的车型标识，确定车况数据包对应的目标解析方案。

步骤407，基于目标解析方案对车况数据包进行解析，得到车辆的目标车况信息。

图5是本申请实施例提供的一种车况数据包的解析过程示意图。如图5所示，不同车型需要上报的强感知信号(强感知信号也即车况状态信号)的个数存在差异，则不同车型的车况数据包所需采取的解析方案也存在差异。比如，针对未进行软件升级的车型A和车型B，车型A中的TBOX需要上报30个强感知信号，车况数据包长度为17byte；TSP接收到车况数据包后，根据车型选择解析方案，且TSP的数据库中预先维护有车型A对应的解析方案A1；车型B中的TBOX需要上报28个强感知信号，车况数据包长度为15byte；TSP接收到车况数据包后，根据车型选择解析方案，且TSP的数据库中预先维护有车型B对应的解析方案B1。可选地，对于车型A来说，进行软件升级会更改车况数据包中所包括强感知信号的信号个数，对应解析方案存在变更；比如，在车型A进行1次升级后，TBOX需要上报32个强感知信号，车况数据包长度为19byte，同时上报标识符(升级标识符)和方案号M(解析方案标识)；TSP接收到车况数据包后，根据方案号M选择解析方案，且TSP的数据库中预先维护有方案号M对应的解析方案；在车型A进行2次升级后，TBOX需要上报40个强感知信号，车况数据包长度为35byte，同时上报标识符(升级标识符)和方案号N(解析方案标识)；TSP接收到车况数据包后，根据方案号N选择解析方案，且TSP的数据库中预先维护有方案号N对应的解析方案；使得车辆进行软件升级后，TSP中维护更新后的解析方案时，仅根据方案号维护，无需再关联到车型A。

步骤405和步骤407的实施方式可以参考步骤303～步骤305，本实施例在此不做赘述。

本实施例中，通过在车况数据包中时间戳的目标相邻字符添加升级标识符，以使得车联网平台可以通过识别时间戳的目标相邻字符是否为升级标识符，判断车况数据包对应解析方案的匹配方式。区别于原有车况数据包中时间戳的目标相邻字符为信号个数，通过不同的车况数据包结构，使得车联网平台可以识别不同的匹配方式，提高匹配方式的确定准确性，进而提高车况数据包的解析准确性和成功率。

上文实施例从车联网平台一侧描述了车况数据包的解析过程，为了实现上述车况数据包的解析方式，车辆一侧在软件升级后，也需要改变车况数据包的生成方式，以为车联网平台提供解析所需的解析方案标识。

图6是本申请实施例提供的另一种车况数据包解析方法的示意性流程图。应理解，该方法可以应用于图1所示的车辆110中。

示例性的，如图6所示，该方法600包括：

步骤601，在车辆完成软件升级的情况下，获取软件升级后车况数据包的解析方案标识，不同解析方案标识对应车况数据包的不同解析方案。

在车辆完成软件升级的情况下，考虑到软件升级可能会导致车况数据包的数据包长度发生改变，对应车况数据包的解析方案发生变更。而考虑到软件升级与否是车主的自主行为，导致存在已经完成软件升级的车辆，车况数据包发生变更，还存在未完成软件升级的车主，车况数据包还是原有格式，则为了兼顾未完成软件升级和已完成软件升级的车辆的车况数据包的解析，对于已经完成软件升级的车辆，提供一种新的车况数据包的解析方式：为不同的车况数据包分配解析方案标识(也可以称为方案号)，并将解析方案标识与对应车况数据包的解析方案关联，使得对于完成软件升级的车辆的车况数据包，可以按照不同解析方案标识匹配对应的解析方案，而并非按照车型维度去解析车况数据包，避免解析错误。

在车辆销售后，一般在车辆软件升级后可能会出现车况数据包变更的情况，对应在车辆完成软件升级的情况下，可以进一步获取软件升级后车况数据包的解析方案标识，以便为后续车况数据包的解析提供解析方案确定依据。

可选地，在车辆销售后，若车辆未进行软件升级，则车况数据包一般不会发生变更，也即无须获取解析方案标识，通过上报车型标识，使得车联网平台匹配车型标识对应的解析方案。

可选地，解析方案标识可以随软件更新包一起发送给车端；或者，在车辆完成软件升级后，向后台服务器请求解析方案标识，或者更新后的解析方案标识。

可选地，在车辆销售后，车辆可能会进行多次软件更新，若每次软件更新均涉及到车况数据包的变更，对应每次软件更新后，车辆需要获取新的解析方案标识。

步骤602，在车辆存在车况数据上报需求的情况下，基于车辆当前的车况状态信号和解析方案标识，生成车辆对应的车况数据包。

为了使得车联网平台可以顺利解析软件升级后车辆上报的车况数据包，车况数据包中应该至少携带有方案解析标识，以使得车联网平台可以基于方案解析标识进行解析方案的匹配。对应在车辆存在车况数据上报需求的情况下，可以获取车辆当前的车况状态信号，以及解析方案标识，并基于车况状态信号和解析方案标识，生成车辆对应的车况数据包。

可选地，车况数据包中还可以包括车况数据包的生成时间戳、以及车况数据包中所包含车况状态信号的信号个数。

示例性的，车况状态信号也可以称为强感知信号，强感知信号是指车辆的车窗(四窗)、车门(四门)、发动机状态、天窗、后备门、空调开关、座椅加热等状态类型的信号。车况状态信号不包括车辆里程、车速等数值类型的信号。需要说明的是，车况状态信号主要为了便于车主可以远程实时查看到车辆的车辆状态，因此不包括车辆里程、车速等在车主驾驶车辆时明确感知到的信号。

针对确定车辆存在车况数据上报需求的方式：达到车辆的车况数据周期性上报的上报时间；或者，在检测到车辆的车况状态信号发生变更时，需要上报车况数据包；或者，接收到车主的远程车况数据查看请求时，上报车况数据包。

步骤603，向车联网平台发送车况数据包，车联网平台用于在识别到车况数据包对应解析方案的匹配方式是第一匹配方式的情况下，基于解析方案标识，确定车况数据包对应的目标解析方案，并使用目标解析方案对车况数据包进行解析，得到车辆的目标车况数据。

在车辆生成车况数据包后，向车联网平台发送该车况数据包。对应车联网平台接收到车况数据包，首先识别车况数据包对应解析方案的匹配方式，若识别到匹配方式是第一匹配方式，则从车况数据包中获取解析方案标识，并根据解析方案标识查找车况数据包对应的目标解析方案，以及根据目标解析方案对车况数据包进行解析，得到车辆的目标车况数据。

进一步的，车联网平台可以将解析得到的目标车况数据反馈给车主所持有的移动终端，使得车主可以通过移动终端远程查看车辆的实时车况信息。

可选地，对于完成软件升级的车辆，提供根据解析方案标识匹配解析方案，对车况数据包进行解析的方式。而对于未进行软件升级的车辆，仍然可以保留根据车型标识匹配解析方案。

综上所述，本申请实施例提供了一种车况数据包的解析方式：在车辆完成软件升级后，可以获取车况数据包的解析方案标识，并基于解析方案标识和车况状态信号生成车况数据包，使得车联网平台可以基于车况数据包中的解析方案标识匹配对应的解析方案，保障完成软件升级的车辆对应车况数据包的成功解析；而且，对完成软件升级的车辆的车况数据包进行解析时，是采用区别于未升级车辆的解析方案匹配方式，对于未进行软件升级的车辆，仍然可以保留根据车型标识匹配解析方案，使得可以兼顾已升级车辆和未升级车辆的解析成功率；此外，对于已经升级的车辆，仅从解析方案标识维度进行解析方案的维护，而不考虑车型维度，也可以支持后续软件升级的灵活性和多样性。

为了使得车联网平台可以明确车况数据包中包括解析方案标识，还需要在车况数据包中的特定位置中添加升级标识符，以使得车联网平台可以在识别到升级标识符的情况下，获取解析方案标识。

图7是本申请实施例提供的另一种车况数据包解析方法的示意性流程图。应理解，该方法可以应用于图1所示的车辆110中。

示例性的，如图7所示，该方法700包括：

步骤701，在车辆完成软件升级的情况下，确定软件升级是否更改车况数据包的数据包长度。

考虑到有的软件升级与未升级相比，并未对车辆需要上报的车况状态信号造成影响，也即车辆上报的车况状态信号在升级前和升级后相同，此时也无需获取解析方案标识或者新的解析方案标识。因此，在车辆完成软件升级后，首先需要判断软件升级是否会更改车况数据包的数据包长度，这里具体指的是车况数据包中车况状态信号，进而确定是否需要获取软件升级后的车况数据包的解析方案标识。

可选地，若软件升级会导致车况数据包发生改变，车辆的业务人员会对应针对更改后的车况数据包匹配对应的解析方案，并设置新的解析方案标识，并通过后台服务器将该解析方案标识反馈给车辆；或者，该解析方案标识可以携带在软件升级包中，以反馈给车辆，使得车辆解析软件升级包后，升级的同时，也会从中获取到解析方案标识。

步骤702，在车况数据包的数据包长度更改的情况下，获取软件升级后的车况数据包的解析方案标识。

在车况数据包的数据包长度更改的情况下，车辆需要获取软件升级后的车况数据包的解析方案标识。

示例性的，若车辆进行首次软件升级，且软件升级会影响到车况数据包，则车辆可以获取到解析方案标识为“方案号N”；若车辆第二次软件升级，且本次软件升级也会影响到车况数据包，则车辆可以获取到新的解析方案标识为“方案号M”。

步骤703，在车辆存在车况数据上报需求的情况下，获取车辆的升级标识符，升级标识符用于指示车辆完成软件升级。

为了使得车联网平台可以知晓车况数据包中包括解析方案标识，还需要在车况数据包中的特殊位置添加升级标识符。对应在车辆存在车况数据上报需求的情况下，可以获取车辆的升级标识符。

步骤704，基于车辆当前的车况状态信号、升级标识符和解析方案标识，生成车辆对应的车况数据包，车联网平台用于基于升级标识符确定车况数据包对应解析方案的匹配方式。

对应车辆在生成车况数据包时，基于车辆当前的车况状态信号、升级标识符和解析方案标识，共同生成车况数据包，以使得车联网平台可以在识别到升级标识符后，确定解析方案的匹配方式为第一匹配方式，进而从车况数据包中获取解析方案标识，以根据解析方案标识，匹配对应的解析方案。

考虑到车联网平台需要兼顾原有数据包和更新后数据包二者之间的解析，则在生成车况数据包时，对车况数据包的结构存在要求，也即如何在原有车况数据包中添加升级标识符和解析方案标识，以实现车联网平台对升级标识符和解析方案标识的识别。

在一个示例性的例子中，步骤704可以包括步骤704A和步骤704B。

步骤704A，获取车况状态信号的时间戳和信号个数。

步骤704B，在时间戳和信号个数之间添加升级标识符和解析方案标识，以及在信号个数之后添加车况状态信号，生成车辆对应的车况数据包，升级标识符与时间戳相邻，且时间戳与信号个数相邻。

其中，软件更新后的车况数据包中除了包括有车况状态信号、升级标识符和解析方案标识之外，还至少包括时间戳和车况状态信号的信号个数。而原有车况数据包仅包括时间戳、信号个数以及车况状态信号。为了兼顾车联网平台对两种数据包结构的解析，设置在时间戳和信号个数之间添加升级标识符和解析方案标识，以及在信号个数之后添加车况状态信号，使得升级标识符和时间戳相邻，且时间戳与信号个数相邻。使得车联网平台在识别到车况数据包后，无论是原有车况数据包还是更新后的车况数据包，均可以先解析到时间戳，再解析时间戳后的目标相邻字符(两个字符)，若目标相邻字符是升级标识符，则确认解析方案的匹配方式是第一匹配方式，以获取解析方案标识；若目标相邻字符是信号个数，则确认解析方案的匹配方式是第二匹配方式，以获取车辆标识匹配解析方案。

图8是本申请实施例提供的一种车况数据包的结构示意图。软件升级后新的车况数据包主要由数据包时间戳、标识符AAA(升级标识符)、方案号(解析方案标识)、信号个数以及若干车况状态信号构成(比如，信号1～信号32)；其中，标识符AAA和方案号位于数据包时间戳和信号个数之间，且标识符AAA与数据包时间戳相邻，方案号与信号个数相邻。

步骤705，向车联网平台发送车况数据包。

步骤705的实施方式可以参考上文实施例，本实施例在此不做赘述。

步骤706，在车况数据包的数据包长度未更改，且车辆存在车况数据上报需求的情况下，基于车辆当前的车况状态信号、信号个数和时间戳，生成车辆对应的车况数据包。

在车况数据包的数据包长度未更改的情况下，车况数据包仍然采用原有数据包结构，即包括车况状态信号、信号个数和时间戳；对应在车辆存在车况数据上报需求的情况下，可以基于车辆当前的车况状态信号、信号个数和时间戳，生成车辆对应的车况数据包。

如图8所示，对于未进行软件升级的，或者软件升级不改变车况数据包的，其对应的原有车况数据包由数据包时间戳、信号个数和若干车况状态信号构成(比如，信号1～信号30)。

步骤707，向车联网平台发送车况数据包和车型标识，车联网平台用于在识别到车况数据包对应解析方案的匹配方式是第二匹配方式的情况下，基于车型标识，确定车况数据包对应的目标解析方案，并使用目标解析方案对车况数据包进行解析，得到车辆的目标车况信息。

对于未发生数据包长度变更的车况数据包，数据包结构也未发生改变，车联网平台需要根据车型标识匹配对应的解析方案。对应车辆在向车联网平台发送车况数据包时，还会携带车辆的车型标识，以使得车联网平台用于在识别到车况数据包对应解析方案的匹配方式是第二匹配方式的情况下，可以基于车型标识，确定车况数据包对应的目标解析方案，并使用目标解析方案对车况数据包进行解析，得到车辆的目标车况信息。

本实施例中，为了使得车联网平台可以区分原有车况数据包以及软件升级后的车况数据包，本申请还提出了在原有车况数据包结构的基础上，在时间戳和信号个数之间增加升级标识符和解析方案标识，且时间戳后的相邻字符为升级标识符。以使得车联网平台均可以在识别到时间戳后，识别时间戳后的相邻字符是否为升级标识符，来判断车况数据包对应解析方案的匹配方式，提高车联网平台确定匹配方式的准确性，进而提高车况数据包的解析成功率。

此外，考虑到软件升级也可能存在不对车况数据包更改的情况，本申请还提出了在车辆完成软件升级后，首先判断软件升级是否会更改车况数据包，若更改再获取对应的解析方案标识，并在车况数据包中添加该解析方案标识；若未更改，则会在上传车况数据包的同时上传车型标识，以使得车联网平台可以基于车型标识匹配对应的解析方案；使得车联网平台对于已升级但是车况数据包未更改的情况，仍然可以准确匹配对应的解析方案，进一步提高车况数据包的解析成功率。

图9是本申请实施例提供的一种车况数据包解析装置的结构示意图，该装置应用于车联网平台中。

示例性的，如图9所示，该装置900包括：

接收模块901，用于接收车辆发送的车况数据包；

第一确定模块902，用于确定车况数据包对应解析方案的匹配方式；

第二确定模块903，用于在匹配方式为第一匹配方式的情况下，基于车况数据包中的解析方案标识，确定车况数据包对应的目标解析方案，解析方案标识是车辆进行软件升级后添加在车况数据包中的；

第三确定模块904，用于在匹配方式为第二匹配方式的情况下，基于车辆发送的车型标识，确定车况数据包对应的目标解析方案；

解析模块905，用于基于目标解析方案对车况数据包进行解析，得到车辆的目标车况信息。

一种可能的实现方式中，该第一确定模块902，还用于：识别车况数据包中是否包括升级标识符，升级标识符是车辆进行软件升级后添加在车况数据包中的；在识别到升级标识符的情况下，确定车况数据包对应解析方案的匹配方式为第一匹配方式；在未识别到升级标识符的情况下，确定车况数据包对应解析方案的匹配方式为第二匹配方式。

一种可能的实现方式中，该第一确定模块902，还用于：解析车况数据包中时间戳的目标相邻字符；在目标相邻字符为升级标识符的情况下，确定识别到车况数据包中的升级标识符；在目标相邻字符为信号个数的情况下，确定车况数据包中不包括升级标识符，信号个数指示车况数据包中包括的车况状态信号的个数。

图10是本申请实施例提供的另一种车况数据包解析装置的结构示意图，该装置应用于车辆中。

示例性的，如图10所示，该装置1000包括：

获取模块1001，用于在车辆完成软件升级的情况下，获取软件升级后车况数据包的解析方案标识，不同解析方案标识对应车况数据包的不同解析方案；

第一生成模块1002，用于在车辆存在车况数据上报需求的情况下，基于车辆当前的车况状态信号和解析方案标识，生成车辆对应的车况数据包；

第一发送模块1003，用于向车联网平台发送车况数据包，车联网平台用于在识别到车况数据包对应解析方案的匹配方式是第一匹配方式的情况下，基于解析方案标识，确定车况数据包对应的目标解析方案，并使用目标解析方案对车况数据包进行解析，得到车辆的目标车况信息。

一种可能的实现方式中，该第一生成模块1002，还用于：获取车辆的升级标识符，升级标识符用于指示车辆完成软件升级；基于车辆当前的车况状态信号、升级标识符和解析方案标识，生成车辆对应的车况数据包，车联网平台用于基于升级标识符确定车况数据包对应解析方案的匹配方式。

一种可能的实现方式中，该第一生成模块1002，还用于：获取车况状态信号的时间戳和信号个数；在时间戳和信号个数之间添加升级标识符和解析方案标识，以及在信号个数之后添加车况状态信号，生成车辆对应的车况数据包，升级标识符与时间戳相邻，且时间戳与信号个数相邻。

一种可能的实现方式中，该获取模块1001，还用于：在车辆完成软件升级的情况下，确定软件升级是否更改车况数据包的数据包长度；在车况数据包的数据包长度更改的情况下，获取软件升级后的车况数据包的解析方案标识；该装置还包括：第二生成模块，用于在车况数据包的数据包长度未更改，且车辆存在车况数据上报需求的情况下，基于车辆当前的车况状态信号、信号个数和时间戳，生成车辆对应的车况数据包；第二发送模块，用于向车联网平台发送车况数据包和车型标识，车联网平台用于在识别到车况数据包对应解析方案的匹配方式是第二匹配方式的情况下，基于车型标识，确定车况数据包对应的目标解析方案，并使用目标解析方案对车况数据包进行解析，得到车辆的目标车况信息。

图11是本申请实施例提供的一种车联网平台的结构示意图。

示例性的，如图11所示，该车联网平台1100包括：存储器1101和处理器1102，其中，存储器1101中存储有可执行程序代码1103，处理器1102用于调用并执行该可执行程序代码1103执行上文实施例中由车联网平台执行的车况数据包解析方法。

图12是本申请实施例提供的一种车辆的结构示意图。

示例性的，如图12所示，该车联网平台1200包括：存储器1201和处理器1202，其中，存储器1201中存储有可执行程序代码1203，处理器1202用于调用并执行该可执行程序代码1203执行上文实施例中由车辆执行的车况数据包解析方法。

此外，本申请实施例还保护一种装置，该装置可以包括存储器和处理器，其中，存储器中存储有可执行程序代码，处理器用于调用并执行该可执行程序代码执行本申请实施例提供的一种车况数据包解析方法。

本实施例可以根据上述方法示例对该装置进行功能模块的划分，例如，可以对应各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中，上述集成的模块可以采用硬件的形式实现。需要说明的是，本实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

在采用对应各个功能划分各个功能模块的情况下，该装置还可以包括接收模块、第一确定模块、第二确定模块、第三确定模块、解析模块等。需要说明的是，上述方法实施例涉及的各个步骤的所有相关内容的可以援引到对应功能模块的功能描述，在此不再赘述。

应理解，本实施例提供的装置用于执行上述一种车况数据包解析方法，因此可以达到与上述实现方法相同的效果。

另外，本申请的实施例提供的装置具体可以是芯片、组件或模块，该芯片可包括相连的处理器和存储器；其中，存储器用于存储指令，当处理器调用并执行指令时，可以使芯片执行上述实施例提供的一种车况数据包解析方法。

本实施例还提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序代码，当该计算机程序代码在计算机上运行时，使得计算机执行上述相关方法步骤实现上述实施例提供的一种车况数据包解析方法。

本实施例还提供了一种计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述相关步骤，以实现上述实施例提供的一种车况数据包解析方法。

其中，本实施例提供的装置、计算机可读存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

通过以上实施方式的描述，所属领域的技术人员可以了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。

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

以上内容，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。