车辆数据存储方法、车辆及可读存储介质与流程

1.本发明涉及车辆领域，尤其涉及一种车辆数据存储方法、车辆及可读存储介质。


背景技术：

2.目前，为了满足车辆项目研发阶段技术人员对车辆数据分析需求，比如通过数据评估三电系统质量、性能的好与坏，评估供应商实力以及为车辆销售售后维修提供支持，通过查询车辆数据，分析事故发生时、发生前后驾驶员的操作意图及相关零部件的工作状态，需要车载终端采集车辆数据信号并上报给远程数据监控服务器，但采集的车辆数据信号除规定的国标数据项外还包括上千项自定义can数据信号项，因此给远程数据监控服务器的整个明细数据存储和集群带来了很大的成本压力。


技术实现要素：

3.本发明提出的一种车辆数据存储方法、车辆及可读存储介质，旨在解决远程数据监控服务器因大量的明细数据存储和集群而导致成本过高的技术问题。
4.为实现上述目的，本发明提供一种车辆数据存储方法，包括以下步骤：
5.接收车载终端上传的车辆原始数据；
6.全量解析所述车辆原始数据以生成全量明细数据；
7.根据待执行频率规则裁剪所述全量明细数据，以生成必要明细数据；
8.存储所述必要明细数据。
9.可选地，所述根据待执行频率规则裁剪所述全量明细数据，以生成必要明细数据的步骤之前包括：
10.接收输入的频率规则；
11.经过预设时间对所述频率规则进行缓存，以生成缓存频率规则；
12.判断所述缓存频率规则与所述全量明细数据是否匹配；
13.若是，则将所述缓存频率规则作为待执行频率规则。
14.可选地，所述根据待执行频率规则裁剪所述全量明细数据，以生成必要明细数据的步骤包括：
15.读取待执行频率规则，以触发与所述待执行频率规则所对应的跳帧存储指令；
16.根据所述跳帧存储指令，对所述全量明细数据进行跳帧读取，以生成必要明细数据。
17.可选地，所述根据所述跳帧存储的指令，对所述全量明细数据进行跳帧读取，以生成必要明细数据的步骤包括：
18.根据所述跳帧存储的指令，对所述实时数据进行跳帧读取，以生成实时必要明细数据；
19.根据所述跳帧存储的指令，对所述补发数据进行跳帧读取，以生成补发必要明细数据；
20.其中，所述全量明细数据包括实时数据和补发数据中的至少一种，必要明细数据包括所述实时必要明细数据和/或所述补发必要明细数据。
21.可选地，所述存储所述必要明细数据的步骤之后包括：
22.接收输入的重新解析指令；
23.根据所述重新解析指令，全量解析所述车辆原始数据中与所述重新解析指令对应的所需原始数据，以生成所需全量明细数据；
24.输出所述所需全量明细数据。
25.可选地，所述重新解析指令包括车辆标识码和起止时间，所述根据所述重新解析指令，全量解析所述车辆原始数据中与所述重新解析指令对应的所需原始数据，以生成所需全量明细数据的步骤包括：
26.根据所述重新解析指令，获取与所述车辆标识码对应的所述车辆原始数据；
27.获取所述车辆原始数据中与所述起止时间对应的所需原始数据；
28.全量解析所述所需原始数据，以生成所需全量明细数据。
29.可选地，所述全量解析所述车辆原始数据以生成全量明细数据的步骤之后，还包括：
30.根据预设提取规则，实时提取所述全量明细数据中与预设提取规则所对应的最新数据，以生成实时状态快照信息；
31.存储所述实时状态快照信息。
32.可选地，所述存储所述实时状态快照信息的步骤之后包括：
33.将所述实时状态快照信息划分为用户所需信息和技术人员所需信息；
34.分别输出所述用户所需信息和所述技术人员所需信息。
35.此外，为实现上述目的，本发明还提供一种车辆，所述车辆包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的车辆数据存储程序，其中：所述车辆数据存储程序被所述处理器执行时实现如上所述的车辆数据存储方法的步骤。
36.此外，为实现上述目的，本发明还提供一种可读存储介质，所述可读存储介质上存储有车辆数据存储程序，所述车辆数据存储程序被处理器执行时实现如上所述的车辆数据存储方法的步骤。
37.本发明中的车辆数据存储方法先通过接收车载终端上传的车辆原始数据，再全量解析所述原始数据以生成全量明细数据，再根据待执行频率规则裁剪所述全量明细数据，以生成必要明细数据，最后存储所述必要明细数据。可以使得在不影响技术人员对车辆数据分析的情况下大幅降低远程数据监控服务器对车辆数据的存储和集群压力，降低了成本，同时裁剪后生成的必要明细数据便于技术人员的分析和处理，也降低了人力成本和节省了技术人员的时间。
附图说明
38.图1为本发明实施例方案涉及的车辆的硬件运行环境的终端结构示意图；
39.图2为本发明车辆数据存储方法第一实施例的流程示意图；
40.图3为本发明车辆数据存储方法第二实施例的流程示意图；
41.图4为本发明车辆数据存储方法第四实施例的部分流程示意图；
42.图5为本发明车辆数据存储方法第五实施例的流程示意图；
43.图6为本发明车辆数据存储方法所涉及的结构设计图。
具体实施方式
44.应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
45.如图1所示，图1是本发明实施例方案涉及的车辆的硬件运行环境的终端结构示意图。
46.如图1所示，该终端可以包括：处理器1001，例如cpu，网络接口1004，用户接口1003，存储器1005，通信总线1002。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示器(display)、输入单元比如控制面板，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如5g接口)。存储器1005可以是高速ram存储器，也可以是稳定的存储器(non
‑
volatile memory)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。作为一种计算机存储介质的存储器1005中可以包括车辆数据存储程序。
47.可选地，终端还可以包括麦克风、扬声器、rf(radio frequency，射频)电路，传感器、音频电路、无线模块等等。其中，传感器比如雷达传感器、红外传感器以及其他传感器，在此不再赘述。
48.本领域技术人员可以理解，图1中示出的终端结构并不构成对终端的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。
49.如图2所示，图2是本发明车辆数据存储方法第一实施例的流程示意图，在本实施例中，所述方法包括：
50.步骤s10，接收车载终端上传的车辆原始数据；
51.本实施例中，车载终端根据国家规定通过can(controller area network，控制器局域网络)总线按照1s/帧的频率获取国标数据项和自定义车辆can数据项，比如有关车辆的曲轴转速，节气门开度信号，车速，档位开关，水温，刹车信号，防盗系统等模块或部件的原始数据项，这些数据项可以以sae
‑
j1939协议的形式制成，sae j1939协议是美国汽车工程协会的推荐标准，用于为中重型道路车辆上电子部件间的通讯提供标准的体系结构。数据项为十六进制的字符，例如，一串报文1818d0f3 ce 0d 00 7d 00 6d 1100。将这些原始数据项按照2s/帧的频率上传到远程数据监控服务器作为车辆原始数据，远程数据监控服务器对接收到的这些车辆原始数据全部进行存储，方便技术人员根据实际情况需要这些原始数据的时候能够从远程数据监控服务器获取和解析。
52.步骤s20，全量解析所述原始数据以生成全量明细数据；
53.由于原始数据是一串串十六进制字符，杂乱无章，需要将原始数据全部进行解析和整理，从而生成具体的便于技术人员分析的全量明细数据，全量明细数据可以以excel表格的形式进行呈现，例如，解析原始的十六进制数据后，将各项电子控制单元放在第一列，后面各列是对应各电子控制单元的解析出来的各种运行工况，例如表格中第1列第三行是电池组健康状态，与电池组健康状态对应的第三行第2，10列：电池电量100％、电池组电压值360v，电池电量99％、电池组电压值370v。
54.步骤s30，根据待执行频率规则裁剪所述全量明细数据，以生成必要明细数据；
55.缓存的频率规则可由技术人员根据实际情况进行创建，可以创建规则如禁止明细数据存储、全量明细数据存储、10s一帧数据存储、16s一帧数据存储、30s一帧数据存储及60s一帧数据存储等规则。例如：原始数据是按照2s/帧的频率进行接收和存储的，解析后生成的全量明细数据也是2s/帧的数据，如果缓存的频率规则为30s一帧数据存储，那么根据该频率规则，生成的必要明细数据就是30s/帧的数据。简单来说，必要明细数据就是按照待执行频率规则从全量明细书中抽取出来的部分数据，和全量明细数据的表现形式是一样的。其中，全量明细数据可由kafka开源流处理平台来处理，包括原始数据生成全量明细数据和根据缓存的的频率规则裁剪全量明细数据以生成必要明细数据的过程。
56.步骤s40，存储所述必要明细数据。
57.必要明细数据存储在第一数据库，第一数据库可以是hbase、cassandra、riak等开源分布式nosql(非关系型数据库)数据库。
58.本发明中的车辆数据存储方法先通过接收车载终端上传的车辆原始数据并进行全量存储，再全量解析所述原始数据以生成全量明细数据，再根据缓存的的频率规则裁剪所述全量明细数据以生成必要明细数据，最后将所述必要明细数据存储至第一数据库。可以使得在不影响技术人员对车辆数据分析的情况下大幅降低远程数据监控服务器对车辆数据的存储和集群压力，降低了成本，同时裁剪后生成的必要明细数据便于技术人员的分析和处理，也降低了人力成本和节省了技术人员的时间。
59.如图3所示，图3为本发明车辆数据存储方法第二实施例的流程示意图，并参照图6，图6为本发明车辆数据存储方法所涉及的结构设计图，进一步地，基于本发明车辆数据存储方法的第一实施例提出本发明车辆数据存储方法的第二实施例，在本实施例中，步骤s30之前包括：
60.步骤s31，接收输入的频率规则；
61.频率规则往往是由技术人员输入到远程数据监控服务器，技术人员可以根据每台车辆、每种型号、车辆不同生产批次等标准设定不同的频率规则并将频率规则关联对应的车辆，例如，对于同一型号的车辆设定5s一帧数据存储的频率规则，那么这一型号的车辆都关联了这一规则，远程数据监控平台对这一型号的车辆都按照相同的频率规则存储其必要明细数据；再例如，对于某台经常发生故障的车辆，技术人员就可以为这台车单独设置频率规则以专门对其发生故障的原因进行分析，频率规则可以设定为全量明细数据存储，即按照原来的2s一帧的频率进行必要明细数据存储；另外技术人员将不同的频率规则发送至远程数据监控服务器，远程数据监控服务器将这些频率规则存储至第二数据库，第二数据库可以为mysql(关系型数据库管理系统)数据库。
62.步骤s32，经过预设时间对所述频率规则进行缓存，以生成缓存频率规则；
63.存储在数据库中的频率规则不会立即对原始数据解析后的全量明细数据按照频率规则进行裁剪存储，而是在频率规则存储在数据库之后经过预设时间，比如10min，将频率规则发送至规则缓存器进行缓存。
64.步骤s33，判断所述缓存频率规则与所述全量明细数据是否匹配；
65.缓存的频率规则都有与之相关联的车辆，如果全量明细数据是来自前述相关联的车辆的原始数据解析生成的，那么就判定缓存的频率规则与全量明细数据匹配。
66.若是，则执行步骤s34：将所述缓存频率规则作为待执行频率规则。
67.进一步地，基于本发明车辆数据存储方法的第一实施例提出本发明车辆数据存储方法的第三实施例，在本实施例中，步骤s30包括：
68.步骤a，读取待执行频率规则，以触发与所述待执行频率规则所对应的跳帧存储指令；
69.步骤b，根据所述跳帧存储指令，对所述全量明细数据进行跳帧读取，以生成必要明细数据。
70.在本实施例中，例如：假如频率规则是60s一帧数据存储，由于车载终端上传原始数据至远程数据监控服务器按照2s/帧的频率上传，所以原始数据解析生成的全量数据也是2s一帧的数据，那么按照60s一帧数据存储的频率规则就会生成每隔30帧读取一次全量明细数据中所对应的数据的指令，按照该指令，读取对应的数据生成必要明细数据。
71.另一实施例中，所述全量明细数据包括实时数据和补发数据中的至少一种；所述根据所述跳帧存储的指令，将所述全量明细数据进行跳帧读取以生成所述必要明细数据的步骤包括：
72.步骤c，根据所述跳帧存储的指令，对所述实时数据进行跳帧读取，以生成实时必要明细数据；
73.步骤d，根据所述跳帧存储的指令，对所述补发数据进行跳帧读取，以生成补发必要明细数据；
74.步骤e，其中，所述全量明细数据包括实时数据和补发数据中的至少一种，必要明细数据包括所述实时必要明细数据和/或所述补发必要明细数据。
75.在这一实施例中，由于车载终端通信模块故障或者远程数据监控服务器故障等其他故障导致车辆原始数据不能实时上传到远程数据监控服务器，那么就需要对车辆原始数据进行补发上传，为了防止由于补发的数据时间错乱导致裁剪全量明细数据不准确，需要将实时数据和补发数据隔离分别跳帧读取以生成实时必要明细数据和补发必要明细数据。
76.如图4所示，图4为本发明车辆数据存储方法第四实施例的部分流程示意图，进一步地，基于本发明车辆数据存储方法的第一实施例提出本发明车辆数据存储方法的第四实施例，在本实施例中，步骤s40之后包括：
77.s41，接收输入的重新解析指令；
78.s42，根据所述重新解析指令，全量解析所述车辆原始数据中与所述重新解析指令对应的所需原始数据，以生成所需全量明细数据；
79.s43，输出所述所需全量明细数据。
80.在本实施例中，当一辆车出现故障，但是该车辆在发生故障当天关联的频率规则不能满足技术人员对故障的分析，比如30s一帧数据存储或60s一帧数据存储或禁止明细数据存储，技术人员可以发送重新解析的指令至远程数据监控服务器的原始数据解析模块，从而使得远程数据监控服务器的原始数据解析模块对车辆原始数据进行全量解析以生成技术人员所需的全量明细数据，该所需的全量明细数据也是2s一帧的明细数据。另外，该所需的全量明细数据可以发送给技术人员开发端以供技术人员进行数据分析，也可以同时保存在远程数据监控服务器的数据库中。
81.在一实施例中，所述重新解析指令包括车辆标识码和起止时间，步骤s42包括：
82.步骤f，根据所述重新解析指令，获取与所述车辆标识码对应的所述车辆原始数
据；
83.步骤g，获取所述车辆原始数据中与所述起止时间对应的所需原始数据；
84.步骤h，全量解析所述所需原始数据，以生成所需全量明细数据。
85.在这一实施例中，当某辆车发生故障，在远程数据监控服务器又没有所需要的全量明细数据的情况下，技术人员需要从远程数据监控服务器搜索获取到该车辆的原始数据，那么就需要对该车辆的原始数据进行一个定位，首先是通过车辆的标识码，即vin码(vehicle identification number)定位到远程数据监控服务器中属于该车辆全部原始数据，根据实际情况再确定所需原始数据的起止时间，比如车辆的故障发生在2021年6月21日上午，那么就可以将起止时间设置为202106210000
‑
202106211200，即起止时间是从2021年6月21日的零点零分到中午的十二点零分，从而根据该起止时间获取到2021年6月21日的零点零分到中午的十二点零分这一时间段对应的该车辆的原始数据，最后全量解析所需的原始数据就生成了技术人员所需要进行分析的全量明细数据。
86.如图5所示，图5为本发明车辆数据存储方法第五实施例的流程示意图，进一步地，基于本发明车辆数据存储方法的第一实施例提出本发明车辆数据存储方法的第五实施例，在本实施例中，步骤s20之后，还包括:
87.步骤s21，根据预设提取规则，实时提取所述全量明细数据中与预设提取规则所对应的最新数据，以生成实时状态快照信息；
88.步骤s22，存储所述实时状态快照信息。
89.实时根据全量明细数据生成车辆的状态信息并保存在第三数据库，第三数据库可以是redis(remote dictionary server，远程字典服务)数据库，上述的第一数据库、第二数据库、第三数据库都互不相同。因为原始数据又是按照2s/帧的频率上传到远程数据监控服务器，所以实时状态快照信息也是每2s进行一次更新，当后2s的实时状态快照信息存储至第三数据库，会替换掉前2s的实时状态快照信息。
90.在一实施例中，参照图5，步骤s22之后包括：
91.步骤s23，将所述实时状态快照信息划分为用户所需信息和技术人员所需信息；
92.步骤s24，分别输出所述用户所需信息和所述技术人员所需信息。
93.在本实施例中，例如，可以将车辆的定位、行驶里程、行车轨迹、故障诊断等信息划分为用户所需信息并将这些信息发送给车载终端或者用户移动端；将车辆的发动机转速、节气门开度、怠速时间长短、电瓶电压、车载空调工况、变速箱档位等技术人员需要信息发送至技术人员能够分析的操作端。
94.此外，本发明还提出一种车辆，所述车辆包括存储器、处理器及存储在存储器上并可在处理器上运行的车辆数据存储程序，所述处理器执行所述车辆数据存储程序时实现如以上实施例所述的车辆数据存储方法的步骤。
95.本发明车辆具体实施方式与上述车辆数据存储方法各实施例基本相同，在此不再赘述。
96.此外，本发明还提出一种计算机可读存储介质，其特征在于，所述计算机可读存储介质包括车辆数据存储程序，所述车辆数据存储程序被处理器执行时实现如以上实施例所述的车辆数据存储方法的步骤。
97.本发明计算机可读存储介质具体实施方式与上述车辆数据存储方法各实施例基
本相同，在此不再赘述。
98.上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。
99.通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在如上所述的一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是电视机，手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。
100.在本发明中，术语“第一”“第二”“第三”“第四”“第五”仅用于描述的目的，而不能理解为指示或暗示相对重要性，对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本发明中的具体含义。
101.在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
102.尽管上面已经示出和描述了本发明的实施例，本发明保护的范围并不局限于此，可以理解的是，上述实施例是示例性的，不能理解为对本发明的限制，本领域的普通技术人员在本发明的范围内可以对上述实施例进行变化、修改和替换，这些变化、修改和替换都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。