Data updating method, vehicle, computer equipment and program product

Abstract

The invention provides a data updating method, a vehicle, computer equipment and a program product, and the method comprises the steps: obtaining real-time vehicle data and a first reference data packet under various vehicle cloud protocol fields; the first reference data packet comprises historical vehicle data, which is locally stored in the vehicle end and is newly updated, under each vehicle cloud protocol field; the vehicle cloud protocol field is a data field set in a data transmission protocol between a vehicle end and a cloud end; if target data different from the historical vehicle data exists in the real-time vehicle data, generating a differencing data packet according to the target data by adopting a variable length coding mode; sending the differencing data packet to a cloud; the cloud is used for updating a second reference data packet of the cloud according to the differencing data packet; the second reference data packet comprises historical vehicle data under each vehicle cloud protocol field which is remotely stored in the cloud and updated latest.

Description

Technical Field

[0001] The present disclosure relates to the field of communication technology, and in particular to a data updating method, a vehicle, a computer device and a program product. Background Art

[0002] With the rapid development of Internet of Vehicles technology, vehicles need to frequently report their own data to the cloud, so that the cloud can provide intelligent and networked services to the vehicle based on the reported vehicle data, thereby improving vehicle performance and safety. In the traditional vehicle data transmission method, all kinds of vehicle data need to be packaged and transmitted to the cloud each time data is transmitted, which will cause the data packet to have too much data or data redundancy, which not only wastes network bandwidth, but also affects data transmission efficiency. Summary of the invention

[0003] The embodiments of the present disclosure at least provide a data updating method, a vehicle, a computer device, and a program product.

[0004] In a first aspect, an embodiment of the present disclosure provides a data updating method, which is applied to a vehicle side, and includes:

[0005] Acquire real-time vehicle data and a first reference data packet under various vehicle-to-cloud protocol fields; the first reference data packet includes the latest updated historical vehicle data under each of the vehicle-to-cloud protocol fields stored locally on the vehicle end; the vehicle-to-cloud protocol field is a data field set in the data transmission protocol between the vehicle end and the cloud end;

[0006] If there is target data different from the historical vehicle data in the real-time vehicle data, a variable-length coding method is used to generate a differential quantization data packet according to the target data;

[0007] The differential data packet is sent to the cloud; the cloud is used to update a second reference data packet in the cloud according to the differential data packet; the second reference data packet includes the latest updated historical vehicle data under each of the vehicle-cloud protocol fields remotely stored in the cloud.

[0008] In this implementation, by comparing the real-time vehicle data under various vehicle-cloud protocol fields with the various historical vehicle data in the first reference data packet stored locally, the target data that has changed recently can be determined in time. Then, by packaging and transmitting each target data to the cloud, the timely storage of the changed data in the cloud can be achieved, and the timely synchronization of the data between the vehicle and the cloud can be completed. By transmitting only a small amount of changed data during the data transmission process, it is not necessary to transmit all the vehicle data under various vehicle-cloud protocol fields, which effectively reduces the data volume of the differential quantization data packet and reduces the waste of network bandwidth. Especially in the vehicle-cloud data transmission scenario, since there is a small amount of frequently changing data on the vehicle side, it is necessary to frequently interact with the vehicle cloud. Compared with the prior art, each interaction requires that the data under various fields be packaged and sent to the cloud. The present disclosure can effectively reduce the data volume of the differential quantization data packet during the vehicle-cloud interaction by determining the differential quantization target data for transmission, thereby reducing the waste of network bandwidth and improving data transmission efficiency. In addition, by encoding the target data in a variable-length coding manner, compact coding can be achieved according to the attribute value corresponding to the target data, further reducing the data volume of the differential quantization data packet.

[0009] In a possible implementation manner, the step of using a variable length coding method to generate a differential quantization data packet according to the target data includes:

[0010] Determine the data transmission protocol version of the vehicle end and the data packet type of the differential data packet; different data transmission protocol versions correspond to different vehicle-to-cloud protocol fields;

[0011] According to the first identifier of the first reference data packet, determine the second identifier of the differential quantization data packet, and use a variable-length coding method to encode the first identifier, the second identifier, the field attribute of the vehicle-cloud protocol field to which each of the target data belongs, the data value of each of the target data, and the number of target data to obtain encoded data;

[0012] The differential quantization data packet is generated according to the encoded data, the data transmission protocol version, the data packet type and the current timestamp information.

[0013] This implementation method can effectively reduce the amount of information required to be reported corresponding to each target data by performing variable-length encoding on various identifiers, field attributes of the vehicle-cloud protocol fields to which each target data belongs, and data values, thereby effectively reducing the data volume of the differential data packet.

[0014] In a possible implementation manner, after sending the differential quantization data packet to the cloud, the method further includes:

[0015] receiving a first confirmation character packet fed back by the cloud; the first confirmation character packet is generated and sent by the cloud after the second reference data packet is updated;

[0016] When the state of the first confirmation character packet indicates that the update is successful, obtaining from the first confirmation character packet a third identifier of the updated second reference data packet and a fourth identifier of the updated second reference data packet;

[0017] When the third identifier is consistent with the first identifier of the first reference data packet, the first reference data packet is updated using the target data in the differential quantization data packet having the fourth identifier to obtain the latest updated first reference data packet.

[0018] In this implementation, by comparing the third identifier with the first identifier, it can be determined whether the reference data packets used by the cloud and the vehicle are consistent. If they are consistent, it means that the cloud has successfully stored the target data that has changed on the vehicle. The vehicle then uses the target data to update the first reference data packet, which can achieve further synchronization of the reference data packets between the vehicle and the cloud.

[0019] In a possible implementation, the method further includes:

[0020] When the third identifier is inconsistent with the first identifier of the first reference data packet, generating a first full data packet according to the real-time vehicle data under various vehicle-to-cloud protocol fields;

[0021] Sending the first full data packet to the cloud; the cloud is used to use the first full data packet as the latest updated second reference data packet, and feed back a second confirmation character packet to the vehicle end;

[0022] In response to receiving the second confirmation character packet, when the status of the second confirmation character packet indicates that the update is successful, the first full data packet is used as the first reference data packet that is most recently updated.

[0023] In this implementation, when the third identifier is inconsistent with the first identifier, it can be determined that the reference data packets used by the cloud and the vehicle are out of order. Therefore, the vehicle can quickly synchronize the reference data packets between the vehicle and the cloud by sending the first full data packet, providing a guarantee for the subsequent successful transmission of differential data.

[0024] In a possible implementation manner, after transmitting the differential quantization data packet to the cloud, the method further includes:

[0025] In response to reaching the data reporting cycle, a second full data packet is generated based on the real-time vehicle data under various vehicle-cloud protocol fields, and the second full data packet is sent to the cloud.

[0026] This implementation method can eliminate the accumulated errors that may exist between the vehicle side and the cloud side by periodically reporting the second full data packet, thereby providing a guarantee for the subsequent successful transmission of differential data.

[0027] In a possible implementation, the method further includes:

[0028] In response to the vehicle side establishing a connection with the cloud for the first time or re-establishing a connection with the cloud, a third full data packet is generated according to the real-time vehicle data under various vehicle-cloud protocol fields, and the third full data packet is sent to the cloud.

[0029] In this implementation mode, after the connection between the vehicle side and the cloud is established, by reporting the third full data packet, the vehicle data under each vehicle-cloud protocol field stored between the vehicle side and the cloud side can be timely unified.

[0030] In a possible implementation, the method further includes:

[0031] If the first confirmation character packet is not received within the target time length, return to the step of obtaining the real-time vehicle data and the first reference data packet under various vehicle-cloud protocol fields to generate and send the latest differential data packet.

[0032] In this implementation, if the first confirmation character packet is not received within the target time length, it may be that the cloud has not received the differential data packet due to network problems or other problems. By returning to execute the steps of determining the differential data packet and uploading it, the target data that has changed recently can be collected and reported again, avoiding data loss problems.

[0033] In a second aspect, the present disclosure provides a data update method, which is applied in the cloud, and includes:

[0034] Receive a differential quantization data packet sent by the vehicle end; the differential quantization data packet is generated by the vehicle end according to the target data using a variable length coding method; the target data is data in the real-time vehicle data under various vehicle-cloud protocol fields that is different from the latest updated historical vehicle data in the latest first reference data packet stored in the vehicle end;

[0035] Using the differential quantization data packet, updating the local latest second reference data packet;

[0036] According to the update result, a first confirmation character packet is generated and fed back to the vehicle end.

[0037] This implementation method can achieve timely synchronization of target data changed on the vehicle side by acquiring the differential data packet sent by the vehicle side and using the differential data packet to update the latest local second reference data packet. Then, a first confirmation character packet is generated based on the update result and fed back to the vehicle side, so that the vehicle side can determine whether to update the first reference data packet stored on the vehicle side based on the first confirmation character packet, thereby achieving synchronization of reference data packets between the vehicle side and the cloud.

[0038] In a possible implementation manner, generating a first confirmation character packet according to the update result and feeding it back to the vehicle end includes:

[0039] In the case of a successful update, a first confirmation character packet indicating a successful update status is generated and fed back to the vehicle end based on the third identifier of the second reference data packet and the fourth identifier of the updated second reference data packet; or, in the case of a failed update, a first confirmation character packet indicating an failed update status is generated and fed back to the vehicle end.

[0040] In this implementation, by generating a first confirmation character packet with status information matching the update result, the vehicle side can use the status information of the first confirmation character packet to determine whether the cloud update is successful, and then accurately determine whether the locally stored first reference data packet needs to be updated.

[0041] In a possible implementation manner, the differential quantization data packet includes the data transmission protocol version of the vehicle end and the encoded data corresponding to the target data;

[0042] The method of updating the local latest second reference data packet by using the differential quantization data packet includes:

[0043] According to the data transmission protocol version, determining the second reference data packet from the latest third reference data packets corresponding to various data transmission protocol versions stored locally;

[0044] Deserialize the encoded data to obtain the field attribute of the vehicle-cloud protocol field corresponding to the target data, the data value of the target data, the first identifier of the first reference data packet, the second identifier of the differential data packet, and the quantity of the target data;

[0045] In a case where the quantity of the target data is consistent with the quantity of the data values, determining whether the differential quantization data packet meets the update requirement according to the first identifier and the third identifier;

[0046] If so, the second reference data packet is updated according to the field attribute and the data value.

[0047] In this implementation, by deserializing the encoded data, the pre-encoding information of the target data can be obtained, and the pre-encoding information can be used to accurately update the second reference data.

[0048] In a possible implementation, the method further includes:

[0049] receiving a first full data packet transmitted by the vehicle end, where the first full data packet is generated and sent by the vehicle end according to real-time vehicle data under various vehicle-to-cloud protocol fields when the third identifier is inconsistent with the first identifier of the first reference data packet;

[0050] The first full data packet is used as the latest second reference data packet, and a second confirmation character packet indicating a successful update status is generated and fed back to the vehicle end.

[0051] In this implementation, when the third identifier is inconsistent with the first identifier, it can be explained that the reference data packets used by the cloud and the vehicle are out of order. Therefore, the cloud can achieve rapid synchronization of the reference data packets between the cloud and the vehicle by receiving the first full data packet sent by the vehicle and using the first full data packet for data update, thus providing a guarantee for the subsequent successful transmission of differential data.

[0052] In a possible implementation, the method further includes:

[0053] receiving a second full data packet transmitted by the vehicle end; the second full data packet is generated and sent by the vehicle end according to the real-time vehicle data under various vehicle-to-cloud protocol fields when determining that a data reporting period has arrived;

[0054] The second full data packet is used as the latest second reference data packet, and a third confirmation character packet indicating a successful update status is generated and fed back to the vehicle end.

[0055] This implementation method, by using the second full data packet periodically reported by the vehicle side as the latest second reference data packet, can eliminate the cumulative errors that may exist between the vehicle side and the cloud side, and provide a guarantee for the subsequent successful transmission of differential data.

[0056] In a possible implementation, the method further includes:

[0057] receiving a third full data packet transmitted by the vehicle end; the third full data packet is generated and sent according to the real-time vehicle data under various vehicle-cloud protocol fields when the vehicle end establishes a connection with the cloud end for the first time or re-establishes a connection;

[0058] The third full data packet is used as the latest second reference data packet, and a fourth confirmation character packet indicating a successful update status is generated and fed back to the vehicle end.

[0059] In this implementation, after a connection is established between the vehicle side and the cloud side, the third full data packet reported by the vehicle side is obtained and used as the latest second reference data packet, so as to realize the timely unification of vehicle data under various vehicle-cloud protocol fields stored between the vehicle side and the cloud side.

[0060] In a third aspect, an embodiment of the present disclosure further provides a vehicle, including a controller, wherein the controller includes:

[0061] a memory for storing machine-readable instructions; and

[0062] A processor is used to call and execute the machine-readable instructions stored in the memory to implement the data update method in the first aspect above, or the steps in any possible implementation of the data update method in the first aspect above; or, to implement the data update method in the second aspect above, or the steps in any possible implementation of the data update method in the second aspect above.

[0063] In a fourth aspect, an optional implementation of the present disclosure further provides a computer device, a processor, and a memory, wherein the memory stores machine-readable instructions executable by the processor, and the processor is used to execute the machine-readable instructions stored in the memory, and when the machine-readable instructions are executed by the processor, the steps in the first aspect or any possible implementation of the first aspect are executed; or, when the machine-readable instructions are executed by the processor, the steps in the second aspect or any possible implementation of the second aspect are executed.

[0064] In a fifth aspect, an optional implementation of the present disclosure further provides a computer program product, which, when run, executes the steps of the above-mentioned first aspect, or any possible implementation of the first aspect; or, the computer program product, when run, executes the above-mentioned second aspect, or any possible implementation of the second aspect.

[0065] For a description of the effects of the above-mentioned vehicle, computer equipment, and computer program product, please refer to the description of the above-mentioned data updating method, which will not be repeated here.

[0066] In order to make the above-mentioned objectives, features and advantages of the present disclosure more obvious and easy to understand, preferred embodiments are specifically cited below and described in detail with reference to the attached drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0067] In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the following is a brief introduction to the drawings required for use in the embodiments. The drawings herein are incorporated into the specification and constitute a part of the specification. These drawings illustrate embodiments consistent with the present disclosure and are used together with the specification to illustrate the technical solutions of the present disclosure. It should be understood that the following drawings only illustrate certain embodiments of the present disclosure and should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can also be obtained based on these drawings without creative work.

[0068] Figure 1 A flow chart of a data updating method applied to a vehicle end provided by an embodiment of the present disclosure is shown;

[0069] Figure 2 A schematic diagram of the structure of a differential quantization data packet provided by an embodiment of the present disclosure is shown;

[0070] Figure 3 A schematic diagram of a reporting process of a differential quantization data packet provided by an embodiment of the present disclosure is shown;

[0071] Figure 4 A schematic diagram of a reporting process for sending a full data packet provided by an embodiment of the present disclosure is shown;

[0072] Figure 5 Another schematic diagram of a reporting process for sending a full data packet provided by an embodiment of the present disclosure is shown;

[0073] Figure 6 A flow chart of a data updating method applied to the cloud provided by an embodiment of the present disclosure is shown;

[0074] Figure 7 A schematic diagram of the structure of a computer device provided by an embodiment of the present disclosure is shown. DETAILED DESCRIPTION

[0075] In order to make the purpose, technical scheme and advantages of the embodiments of the present disclosure clearer, the technical scheme in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are only part of the embodiments of the present disclosure, rather than all of the embodiments. The components of the embodiments of the present disclosure generally described and shown here can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present disclosure is not intended to limit the scope of the present disclosure claimed for protection, but merely represents the selected embodiments of the present disclosure. Based on the embodiments of the present disclosure, all other embodiments obtained by those skilled in the art without making creative work belong to the scope of protection of the present disclosure.

[0076] In addition, the terms "first", "second", etc. in the description and claims of the embodiments of the present disclosure and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the terms used in this way can be interchangeable where appropriate, so that the embodiments described herein can be implemented in an order other than that illustrated or described herein.

[0077] The "multiple or several" mentioned in this article refers to two or more. "And / or" describes the association relationship of the associated objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the associated objects are in an "or" relationship.

[0078] Research has found that in the scenario of vehicle-cloud data transmission, whenever there is a data change on the vehicle side, the vehicle side needs to report the vehicle data to the cloud. Since some data on the vehicle side will change frequently, such as various control switches, dashboard information, etc., this causes the vehicle side to frequently report data to the cloud. However, in the traditional data reporting method, when any data changes, all vehicle data needs to be reported to the cloud. In other words, even if there are a small amount of data changes on the vehicle side, the full amount of data needs to be transmitted, which not only leads to the possibility that a large amount of unchanged data may be repeatedly sent to the cloud, but also causes problems such as excessive data packets and serious waste of network bandwidth, and it is impossible to effectively process vehicle data that changes frequently and slightly. Therefore, how to solve the problem of data transmission when a small amount of data changes frequently in the scenario of vehicle-cloud data transmission has become a technical issue worthy of attention.

[0079] Based on the above research, the present disclosure provides a data update method, a vehicle, a computer device and a program product. By comparing the real-time vehicle data under various vehicle-cloud protocol fields with the various historical vehicle data in the first reference data packet stored locally, the target data that has changed recently can be determined in time. Then, by packaging and transmitting each target data to the cloud, the timely storage of the changed data can be achieved in the cloud, and the timely synchronization of the data between the vehicle and the cloud can be completed. By transmitting only a small amount of changed data during the data transmission process, it is not necessary to transmit all the vehicle data under various vehicle-cloud protocol fields, which effectively reduces the data volume of the differential quantization data packet and reduces the waste of network bandwidth. In particular, in the vehicle-cloud data transmission scenario, since there is a small amount of frequently changing data on the vehicle side, it is necessary to frequently interact with the vehicle cloud. Compared with the prior art, each interaction requires that the data under various fields be packaged and sent to the cloud. The present disclosure determines the differential target data for transmission, which can effectively reduce the data volume of the differential quantization data packet during the vehicle-cloud interaction, thereby reducing the waste of network bandwidth and improving data transmission efficiency. In addition, by encoding the target data in a variable-length coding manner, compact coding can be achieved according to the attribute value corresponding to the target data, further reducing the data volume of the differential quantization data packet.

[0080] The defects existing in the above solutions are the results obtained by the inventor after practice and careful research. Therefore, the discovery process of the above problems and the solutions proposed by the present disclosure for the above problems below should be the contributions made by the inventor to the present disclosure during the disclosure process.

[0081] It should be noted that similar reference numerals and letters denote similar items in the following drawings, and therefore, once an item is defined in one drawing, further definition and explanation thereof is not required in subsequent drawings.

[0082] It is understandable that before using the technical solutions disclosed in the embodiments of the present disclosure, the types, scope of use, usage scenarios, etc. of the personal information involved in the present disclosure should be informed to the user and the user's authorization should be obtained in an appropriate manner in accordance with relevant laws and regulations.

[0083] It should be noted that the specific terms mentioned in the embodiments of the present disclosure include:

[0084] PB: Protocol Buffers, a data description language that can serialize structured data similar to XML and can be used for data storage, communication protocols, etc.

[0085] VDTP: Vehicle Delta Transmission Protocol, a PB-based optimization protocol proposed in this disclosure, used to transmit the changed data on the vehicle side to the cloud;

[0086] ACK: Acknowledgment, confirmation information;

[0087] Varint encoding: A data encoding technique that uses one or more bytes to serialize integers and encode integers into variable-length bytes to achieve data compression. The principle of Varint encoding is that for smaller values, it uses fewer bytes to encode, and for larger values, it uses more bytes;

[0088] MQTT: Message Queue Telemetry Transport is a message protocol based on the publish / subscribe paradigm under the ISO standard.

[0089] To facilitate understanding of this embodiment, a data update method disclosed in an embodiment of the present disclosure is first introduced in detail. The executor of the data update method provided in the embodiment of the present disclosure is generally a terminal device or other processing device with certain computing capabilities, wherein the terminal device may be a user equipment (UE), a mobile device, a user terminal, a terminal, a personal digital assistant (PDA), a handheld device, a vehicle device, a server, a computer device, etc.; in some possible implementations, the data update method may be implemented by a processor calling computer-readable instructions stored in a memory.

[0090] The data updating method provided by the embodiment of the present disclosure is described below by taking the vehicle end as an example of the execution subject.

[0091] like Figure 1 As shown, it is a flow chart of a data updating method applied to a vehicle end provided by an embodiment of the present disclosure, which may include the following steps:

[0092] S101: Acquire real-time vehicle data and a first reference data packet under various vehicle-cloud protocol fields; the first reference data packet includes historical vehicle data under various vehicle-cloud protocol fields that are locally stored on the vehicle side and are most recently updated; the vehicle-cloud protocol field is a data field set in the data transmission protocol between the vehicle side and the cloud side.

[0093] Here, the data transmission protocol may specifically be a VDTP protocol, which is used to transmit the changed vehicle data in the vehicle end to the cloud. The protocol is obtained by improving the PB protocol, and the focus is on combining the principle of compact coding of PB with the differential data update strategy. Among them, differential data can be understood as the changed vehicle data under any protocol field of the vehicle end. For the traditional PB protocol, all vehicle-cloud protocol fields must be filled with valid values ​​during the data reporting process, otherwise the data under the unfilled fields will be deserialized to the default value after being received in the cloud, resulting in the cloud data being overwritten by the default abnormal value. The VDTP protocol proposed in the embodiment of the present disclosure only needs to upload differential data, and the cloud will not deserialize the unchanged data that has not been uploaded to the default value after receiving the differential data, thereby realizing both the retention of unchanged data in the cloud and the timely storage of changed data. The reason why it is possible to achieve that the unreported data will not be set to the default value while uploading differential data is that when the VDTP protocol is written in combination with the differential update strategy and the PB protocol, the relevant code in the PB protocol is improved.

[0094] Under the data transmission protocol, the vehicle and the cloud can pre-negotiate the data fields of various vehicle data to be transmitted, and these data fields can be defined as vehicle-cloud protocol fields. For example, the vehicle-cloud protocol field includes data fields 1 to 10, so the data to be transmitted between the vehicle and the cloud includes the data corresponding to data fields 1 to 10.

[0095] Optionally, different fields between the car and the cloud have different interaction characteristics. For example, data under certain data fields need to be reported in real time, and data under certain data fields can be reported in batches, etc. Therefore, the disclosed embodiment can predefine at least one data field group, each data field group can include at least one car-cloud protocol field, and the division of different data field groups is related to the interaction characteristics of different data fields. The car-cloud protocol fields in each data field group are different. For example, data field group 1 includes data fields 1 to 10, data field group 2 includes data fields 11 to 16, and data field group 3 includes data fields 17 to 30.

[0096] Real-time vehicle data refers to the vehicle data of a certain vehicle-cloud protocol field at the current moment, and each vehicle-cloud protocol field has corresponding real-time vehicle data. The first reference data packet is a data packet stored locally on the vehicle side, which includes the latest updated historical vehicle data stored locally on the vehicle side for each vehicle-cloud protocol field. For example, for vehicle-cloud protocol fields 1 and 2, the historical vehicle data of vehicle-cloud protocol field 1 at time 1 is data 1, and the historical vehicle data of vehicle-cloud protocol field 2 at time 1 is data 2. At time 2, the latest first reference data packet includes data 1 corresponding to vehicle-cloud protocol field 1 and data 2 corresponding to vehicle-cloud protocol field 2. If at time 2, the vehicle data under vehicle-cloud protocol field 1 becomes data 3, and the vehicle data under vehicle-cloud protocol field 2 is still data 2, then at time 3, the latest first reference data packet includes data 3 corresponding to vehicle-cloud protocol field 1 and data 2 corresponding to vehicle-cloud protocol field 2.

[0097] In specific implementation, for each data field group pre-agreed between the vehicle and the cloud, the data acquisition cycle related to the interaction characteristics can be determined according to the interaction characteristics of the vehicle-cloud protocol field in the data field group. Then, the real-time vehicle data under each vehicle-cloud protocol field in the data field group and the latest updated first reference data packet stored locally at the current moment are acquired according to the data acquisition cycle.

[0098] Taking the data acquisition cycle of 5 seconds (s) as an example, vehicle data can be acquired every 5 seconds to obtain real-time vehicle data under various vehicle-cloud protocol fields and the most recently updated first benchmark data packet at that moment.

[0099] S102: If there is target data in the real-time vehicle data that is different from the historical vehicle data, a variable-length coding method is used to generate a differential quantization data packet according to the target data.

[0100] Here, the variable length encoding method can flexibly select a suitable byte length according to the data to be encoded, thereby realizing compact encoding of the data. Specifically, the variable length encoding method can be a varint encoding method.

[0101] The target data is the real-time vehicle data under any vehicle-to-cloud protocol field, which is different from the latest historical vehicle data under the vehicle-to-cloud protocol field. The target data can be specifically understood as the data that has changed. The differential quantization data packet includes the encoded data corresponding to each target data.

[0102] In specific implementation, for each data field group, the real-time vehicle data under each vehicle-cloud protocol field in the data field group can be compared for consistency with the historical vehicle data under the corresponding vehicle-cloud protocol field in the latest first reference data packet to determine whether the real-time vehicle data under a vehicle-cloud protocol field is different from the latest historical vehicle data. If so, the real-time vehicle data under the vehicle-cloud protocol field is used as the target data. If no real-time vehicle data under any vehicle-cloud protocol field is different from the latest historical vehicle data, then S101 can be returned according to the data acquisition cycle.

[0103] After filtering out each target data from the real-time vehicle data, the varint encoding method can be used to encode each target data, and the encoded data can be packaged into a differential quantization data packet.

[0104] S103: Send a differential data packet to the cloud; the cloud is used to update a second reference data packet in the cloud according to the differential data packet; the second reference data packet includes the historical vehicle data under each vehicle-cloud protocol field that is remotely stored in the cloud and is most recently updated.

[0105] Here, the second reference data packet is a data packet stored remotely in the cloud, which includes the latest updated historical vehicle data stored remotely in the cloud for each vehicle-cloud protocol field. When the communication between the vehicle and the cloud is normal, the historical vehicle data stored in the latest second reference data packet on the cloud should be consistent with the historical vehicle data stored in the latest first reference data packet on the vehicle side.

[0106] In specific implementation, after generating a differential data packet, the vehicle side can send the differential data packet to the cloud to achieve data synchronization between the vehicle and the cloud. After receiving the differential data packet, the cloud side can verify the integrity and security of the differential data packet. If the verification is passed, it is determined whether the first reference data packet corresponding to the differential data packet is consistent with the second reference data packet. If so, the data under the corresponding field in the first reference data can be updated using each target data corresponding to the differential data packet, and based on the update result, a first confirmation information packet is generated and fed back to the vehicle side to feedback information on whether the update is successful.

[0107] In this way, by comparing the real-time vehicle data under various vehicle-cloud protocol fields with the various historical vehicle data in the first reference data packet stored locally, the target data that have changed recently can be determined in time. Then, by packaging and transmitting each target data to the cloud, the timely storage of the changed data in the cloud can be achieved, and the timely synchronization of the data between the vehicle and the cloud can be completed. By transmitting only a small amount of changed data during the data transmission process, it is not necessary to transmit all the vehicle data under various vehicle-cloud protocol fields, which effectively reduces the data volume of the differential quantization data packet and reduces the waste of network bandwidth. Especially in the vehicle-cloud data transmission scenario, since there is a small amount of frequently changing data on the vehicle side, it is necessary to frequently interact with the vehicle cloud. Compared with the prior art, each interaction requires that the data under various fields be packaged and sent to the cloud. The present disclosure can effectively reduce the data volume of the differential quantization data packet during the vehicle-cloud interaction by determining the differential quantization target data for transmission, thereby reducing the waste of network bandwidth and improving data transmission efficiency. In addition, by encoding the target data in a variable-length coding manner, compact coding can be achieved according to the attribute value corresponding to the target data, further reducing the data volume of the differential quantization data packet.

[0108] In one embodiment, the step of generating a differential quantization data packet in S102 may be implemented according to the following steps:

[0109] S102-1: Determine the data transmission protocol version of the vehicle side and the data packet type of the differential data packet; different data transmission protocol versions correspond to different vehicle-cloud protocol fields.

[0110] Here, since the data transmission protocol version will be updated with the data transmission demand, and the version update status of different vehicle terminals is inconsistent, and the cloud will interact with a large number of vehicles, in order to ensure that the cloud can use the differential data packet transmitted by each vehicle terminal only for the update of the data stored in the cloud by the vehicle terminal, the data transmission protocol version of the vehicle terminal can be used when generating the differential data packet.

[0111] Different data transmission protocol versions correspond to different vehicle-to-cloud protocol fields. The data transmission protocol version may specifically be a VDTP protocol version number. The data transmission protocol version may be represented by 1 byte in a data packet.

[0112] The data packet type is used to distinguish the transmission types of different data packets, which can specifically include the reporting packet type and the confirmation packet type, where the confirmation packet type is the ACK type. The data packet type can also be represented by 1 byte. Different data packet types can use different setting data identifiers. For example, the reporting packet type can be represented by 0x00, and the ACK type can be represented by 0x01. For the vehicle side, the data packet type of any data packet sent to the cloud is the reporting packet type.

[0113] In specific implementation, after determining the target data, the vehicle end can simultaneously determine the data transmission protocol version currently in use, that is, can determine the VDTP protocol version number currently in use. At the same time, the reporting packet type can be used as the data packet type of the differential quantization data packet to be generated.

[0114] S102-2: Determine the second identifier of the differential data packet based on the first identifier of the first reference data packet, and use variable-length coding to encode the first identifier, the second identifier, the field attributes of the vehicle-cloud protocol field to which each target data belongs, the data value of each target data, and the number of target data to obtain the encoded data.

[0115] Here, each reference data packet and each differential quantization data packet have a corresponding identifier, which can be the number of the data packet. The first identifier is the identifier of the first reference data packet, and the first identifier is the identifier of the differential quantization data packet. The identifiers of the data packets can all be represented by greater than or equal to 1 byte.

[0116] The field attributes may specifically include the field number of the car-cloud protocol field and the data type corresponding to the field. Among them, the field attributes can be represented by 1 byte. In 1 byte, 5 bits (5 bits) are used to represent the field number, and 3 bits are used to represent the data type. The field number is used to uniquely identify the car-cloud protocol field. The data type is used to indicate the type of the field value (i.e., data value), such as integer type, string type, etc. The data value is used to represent the specific numerical value of the target data and can be stored according to the data type. For the encoding method of field attributes and data values, please refer to the definition method of the PB protocol. In varint encoding, 1 byte includes 8 bits, and 7 bits of 8 bits are used to encode the rule to identify a number. The high bit is used to identify whether there are subsequent bytes, and the low 7 bits identify part of the integer. The following is an example of a varint encoding process:

[0117] Uint64 (unsigned 64-bit integer) id = 123; / / Identifier is 123

[0118] Binary: 0111 1011

[0119] Varint: 0 1111011 / / High bit 0 indicates no subsequent bytes

[0120] Dec(decimal): 300

[0121] Binary: 0001 0010 1100

[0122] Varint: 1 0101100 0 0000010 / / The high bit of the first byte is 1, which means there are subsequent bytes, and the high bit of the second byte is 0, which means there are no subsequent bytes.

[0123] The number of target data is used to indicate the number of target data included in the differential data packet, and may also indicate the number of vehicle-cloud protocol fields included in the differential data packet. The number of target data may be represented by greater than or equal to 1 byte.

[0124] During specific implementation, the second identifier of the differential data packet that needs to be sent can be determined by using the self-increment method of the identifier based on the first identifier of the first reference data packet and the identifier of the differential data packet that has not received a reply from the cloud. Among them, the differential data packets that have not received a reply from the cloud are the differential data packets sent by the vehicle end to the cloud after the first reference data packet is generated and before the current differential data packet is sent. For example, the first identifier of the first reference data packet is 0x01. After determining the target data, the vehicle end will generate a differential data packet with a second identifier of 0x02 and send it to the cloud. If no reply is received from the cloud after sending it, when the next cycle is reached, the first identifier of the first reference data packet is still 0x01, and a differential data packet with a second identifier of 0x03 can be generated according to the new target data and sent to the cloud.

[0125] After obtaining the second identifier, the number of target data, the field attributes of the car-cloud protocol field to which each target data belongs, and the data value corresponding to each target data can be determined. Then, the varint encoding method is used to encode the first identifier, the second identifier, the field attributes corresponding to each target data, the data value of each target data, and the number of target data to obtain the encoded data.

[0126] Here, variable-length encoding is used for data encoding, which can effectively reduce the size of the encoded data, achieve compact encoding, and avoid bandwidth waste compared to json or xml format encoding in the prior art.

[0127] S102-3: Generate a differential quantization data packet according to the encoded data, the data transmission protocol version, the data packet type and the current timestamp information.

[0128] Here, the timestamp information is used to indicate the generation time of the differential quantization data packet, which can be represented by 8 bytes.

[0129] In specific implementation, the encoded data, the data transmission protocol version represented by 1 byte, the data packet type represented by 1 byte, and the timestamp information represented by 8 bytes can be combined into a differential quantization data packet.

[0130] like Figure 2 As shown, it is a schematic diagram of the structure of a differential quantization data packet provided in an embodiment of the present application, and the differential quantization data packet includes two parts, namely a header part and a data field part. Among them, the header part includes the protocol version number, the data packet type, the differential data packet number (that is, the identification of the differential quantization data packet), the reference data packet number (that is, the identification of the reference data packet), and timestamp information, and the data field part includes the number of changed data (that is, the number of target data), the field number and data type constituting the field attributes, and the field value (that is, the data value of the target data, wherein the field attributes and the field value constitute the target data). It can be understood that in a specific implementation, the structure of the differential quantization data packet is not limited to Figure 2 The arrangement structure shown can be flexibly set according to the requirements. Regarding the protocol version number, data packet type, and timestamp information, other encoding methods other than variable length encoding, such as fixed length encoding, can be used for encoding.

[0131] For example, assume that a VDTP data packet is currently generated, and the header part of the data packet is as follows:

[0132] Protocol version number: 0x01

[0133] Data packet type: 0x00 (report packet)

[0134] Packet number: 0x01 (varint encoding, indicating 1)

[0135] Base data packet number: 0x00 (varint code, representing 0, this code is used to indicate that the data packet is a full data packet)

[0136] Timestamp: 0x0000000000000001

[0137] Number of changed data: 0x02 (varint code, indicating 2)

[0138] The Data Field part is as follows:

[0139] Field attribute code: 0x10 (field number is 2, data type is integer)

[0140] Field value: 0x0001 (integer value is 1)

[0141] Field attribute code: 0x21 (field number is 4, data type is string)

[0142] Field value: 0x48656C6C6F (string value is "Hello")

[0143] In one embodiment, after the vehicle sends a differential data packet to the cloud, the vehicle also needs to update the local reference data packet according to the ACK packet fed back by the cloud. Specifically, the update can be performed according to the following steps:

[0144] Step 1: Receive a first confirmation character packet fed back by the cloud; the first confirmation character packet is generated and sent by the cloud after the second reference data packet is updated.

[0145] Step 2: when the status of the first confirmation character packet indicates that the update is successful, obtain the third identifier of the updated second reference data packet and the fourth identifier of the updated second reference data packet from the first confirmation character packet.

[0146] Here, the first confirmation character packet can be an ACK packet of a confirmation information packet type fed back by the cloud, which is generated and fed back after the cloud updates the latest second benchmark data packet according to the received differential quantization data packet. The ACK packet may include the data transmission protocol version (1byte) of the updated second benchmark data packet, the data packet type (where 0x01 represents the ACK packet type), the reference data packet number before the update (i.e., the updated second benchmark data packet, using Varint encoding), and the reference data packet number after the update (and the identifier of the updated second benchmark data packet, using Varint encoding). Among them, the first confirmation character packet is related to the update result of the second benchmark data packet. In the case where the second benchmark data packet is successfully updated, the first confirmation character packet may include a status indicating a successful update, a third identifier of the updated second benchmark data packet, a fourth identifier of the new second benchmark data packet obtained after the update, a fifth identifier of the differential quantization data packet used when the cloud updates the updated second benchmark data packet, a data transmission protocol version, and a data packet type. In the case where the second benchmark data packet fails to update, the first confirmation character packet may include a status indicating a failed update. In addition, the information that needs to be included may be set as needed, for example, the identifier of the latest second benchmark data packet in the cloud, the identifier of the differential quantization data packet used for updating, the data transmission protocol version, the data packet type, and other information.

[0147] Among them, under normal circumstances, when the data synchronization between the cloud and the vehicle is normal, the third identifier can be consistent with the first identifier.

[0148] During specific implementation, after the vehicle sends a differential data packet to the cloud, the cloud can determine whether the reference data packets on the vehicle and cloud are consistent based on the first identifier in the first reference data packet corresponding to the differential data packet and the identifier of the latest second reference data packet. If so, the cloud can use the differential data packet to update the data of the first reference data packet. Then, based on the update result, a first confirmation character packet is generated and fed back to the vehicle. If the reference data packets on the vehicle and cloud are inconsistent, it can be directly determined that the update has failed, and a first confirmation character packet indicating the update failure is generated and fed back to the vehicle. In addition, after receiving the differential data packet, the cloud can also determine whether it complies with the principle of increasing numbering based on the second identifier of the differential data packet and the identifier of the latest second reference data packet, and determine whether there is data packet loss and disorder based on the judgment result.

[0149] After receiving the first confirmation character packet fed back from the cloud, the vehicle can determine that the first confirmation character packet is an ACK packet based on the data packet type, and then, if the data transmission protocol version in the first confirmation character packet is consistent with the local data transmission protocol version on the vehicle, determine whether the status of the first confirmation character packet is a status indicating a successful update. If so, the third identifier of the updated second reference data packet in the first confirmation character packet and the fourth identifier of the new second reference data packet obtained after the update can be obtained.

[0150] When the status of the first confirmation character packet indicates that the update failed, the real-time vehicle data under various protocol fields can be immediately obtained, and a full data packet including these data can be generated, and the full data packet is sent to the cloud. When received by the cloud, the full data packet is used as the latest second reference data packet and the first confirmation character packet indicating the successful update is fed back to the vehicle side, so that the vehicle side uses the full data packet as the latest first reference data packet stored locally. Optionally, in order to avoid data packet number overflow, the number of the full data packet generated by the vehicle side can be 0x00, that is, each time a full data packet is uploaded, the data packet number is reset to 0. For each differential data packet, the number of the differential data packet can be incremented starting from the number of the latest full data packet.

[0151] Step three: when the third identifier is consistent with the first identifier of the first reference data packet, the first reference data packet is updated using the target data in the differential quantization data packet having the fourth identifier to obtain the latest updated first reference data packet.

[0152] Here, in the absence of data delay or disconnection of the vehicle-cloud connection, the fourth identifier should be consistent with the second identifier. If the above situation occurs, the difference between the number corresponding to the fourth identifier and the second identifier may be greater than 1.

[0153] During specific implementation, the vehicle end can determine whether the third identifier is consistent with the first identifier of the first reference data packet corresponding to the differential data packet. If they are consistent, the target data in the differential data packet with the fourth identifier can be used to update the first reference data packet corresponding to the differential data packet to obtain the latest updated first reference data packet. Among them, the number of the latest updated first reference data packet is obtained by incrementing the number of the first reference data packet corresponding to the differential data packet. In this way, the ACK-based reference data packet synchronization mechanism can ensure the consistency of vehicle-side and cloud-side data.

[0154] like Figure 3 As shown, it is a schematic diagram of the reporting process of a differential quantization data packet provided in an embodiment of the present application, wherein the vehicle end can determine the differential quantization data packet according to the latest target data and send it to the cloud. The number of the differential quantization data packet can be obtained by incrementing the number of the first benchmark data packet. After receiving the differential quantization data packet, the cloud can process the differential quantization data packet. That is, the cloud can update the latest second benchmark data packet according to the differential quantization data packet, and if the update is successful, generate an ACK packet with a status of 0x00 and feed it back to the vehicle end. After receiving the ACK packet, the vehicle end uses the differential quantization data packet to update the first benchmark data packet when the number of the benchmark data packet in the differential quantization data packet (i.e., the first identifier) ​​is consistent with the number of the benchmark data packet updated in the cloud (i.e., the third identifier) ​​to obtain a new first benchmark data packet.

[0155] When the third identifier is inconsistent with the first identifier of the first reference data packet, the vehicle side can immediately send a full data packet to the cloud side according to the following steps, thereby achieving data unification between the vehicle and the cloud side:

[0156] Step A: Generate a first full data packet based on real-time vehicle data under various vehicle-cloud protocol fields.

[0157] Here, the full data packet includes real-time vehicle data under various protocol fields, and the differential data packet only includes the changed target data.

[0158] In a specific implementation, when the vehicle receives the first confirmation character packet sent by the cloud, and the third identifier in the first confirmation character packet is inconsistent with the first identifier of the first reference data packet, real-time vehicle data including various protocol fields can be obtained, and based on these data, a first full data packet is generated using a variable-length encoding method. The data packet number of the first full data packet can be 0x00, that is, each time a full data packet is sent, the data packet number is reset to 0.

[0159] Step B: sending a first full data packet to the cloud; the cloud is used to use the first full data packet as the latest updated second reference data packet, and feed back a second confirmation character packet to the vehicle.

[0160] Here, the second confirmation character packet is also an ACK packet.

[0161] In specific implementation, the vehicle side can generate a first full data packet and send it to the cloud. After receiving the first full data packet, the cloud can directly use the first full data packet as the latest second reference data packet, or use the vehicle data in the first full data packet to update the most recently updated second reference data packet to obtain the latest updated second reference data packet. After the update is completed, the cloud can generate a second confirmation character packet to indicate that the update is successful and feed it back to the vehicle side.

[0162] Step C: in response to receiving the second confirmation character packet, when the status of the second confirmation character packet indicates that the update is successful, the first full data packet is used as the latest updated first reference data packet.

[0163] In specific implementation, the vehicle side can receive the second confirmation character packet sent by the cloud, and then when the status of the second confirmation character packet is 0x00, the first full data packet is used as the latest updated first benchmark data packet. At this time, the number of the latest updated first benchmark data packet will also be reset to 0.

[0164] Optionally, after receiving the differential quantization data packet in the cloud, before using the differential quantization data packet to update the second reference data packet, it is also possible to determine whether the first identifier of the first reference data packet in the differential quantization data packet is consistent with the identifier of the latest second reference data packet. If they are consistent, the update can continue, and a first confirmation character packet is generated based on the update result and fed back to the vehicle end. In the event that the cloud determines that the first identifier is inconsistent with the identifier of the latest second reference data packet, a first confirmation character packet with a status indicating that the update failed can be directly generated and fed back to the vehicle end, and the first confirmation character packet can include the identifier of the latest second reference data packet.

[0165] Optionally, when the vehicle sends a full data packet to the cloud, the baseline data packet may default to the full data packet.

[0166] like Figure 4As shown, a schematic diagram of a reporting process for sending a full data packet provided by an embodiment of the present application, wherein the vehicle end can determine the differential data packet according to the latest target data and send it to the cloud. After receiving the differential data packet, if the cloud finds that the number of the first reference data packet in the differential data packet is inconsistent with the number of the latest second reference data packet, or, in the case of failure to update the differential data packet, an ACK packet with a status of 0x01 can be generated and fed back to the vehicle end. After receiving the ACK packet, if the number of the reference data packet in the differential data packet (i.e., the first identifier) ​​and the number of the updated reference data packet in the cloud are inconsistent (i.e., the third identifier), the vehicle end will generate a full data packet numbered 0x00 according to the real-time vehicle data under various vehicle-cloud protocol fields and send it to the cloud. The cloud can receive the full data packet and use the full data packet to update the second reference data packet. After the update is completed, an ACK packet with a status of 0x00 can be generated and fed back to the vehicle end. After receiving the ACK packet, the vehicle end can update the local first reference data packet with the full data packet to obtain the latest first reference data packet. Among them, the data structure of the full data packet is consistent with that of the differential data packet. The difference is that the full data includes real-time vehicle data under all vehicle-cloud protocol fields, and the differential data packet only includes target data under the vehicle-cloud protocol fields that have changed.

[0167] In one embodiment, after the differential quantization data packet is transmitted to the cloud, the method further includes:

[0168] In response to reaching the data reporting cycle, a second full data packet is generated based on the real-time vehicle data under various vehicle-cloud protocol fields, and the second full data packet is sent to the cloud.

[0169] Here, the data reporting cycle is the upload cycle of the full data. While the differential data is uploaded periodically using the data acquisition cycle, in order to eliminate the data accumulation error that may exist between the vehicle and the cloud, the data reporting cycle can also be used to periodically upload the full data. For example, the data acquisition cycle can be 5s, and the data reporting cycle can be 15 minutes.

[0170] During specific implementation, it can be determined whether the current data reporting cycle has been reached based on the time of the last upload of full data and the duration corresponding to the data reporting cycle. If so, the real-time vehicle data under various vehicle-cloud protocol fields can be obtained, and based on these data, a new full data packet is generated by variable-length coding. Among them, the number of the full data packet is 0x00. The full data packet is used as the second full data packet and sent to the cloud. After receiving the second full data packet, the cloud can directly use the second full data packet as the latest second benchmark data packet, or use the vehicle data in the second full data packet to update the data of the most recently updated second benchmark data packet to obtain the latest updated second benchmark data packet. After the update is completed, the cloud can generate a third confirmation character packet for indicating the successful update status and feedback to the vehicle end (that is, the cloud can generate an ACK packet for indicating the successful update status and feedback to the vehicle end). Furthermore, after receiving the third confirmation character packet, the vehicle end can use the second full data packet to update the local first benchmark data packet, thereby realizing the unification of vehicle-cloud data.

[0171] In another embodiment, in response to the vehicle establishing a connection with the cloud for the first time or re-establishing a connection, a third full data packet can be generated based on real-time vehicle data under various vehicle-cloud protocol fields, and the third full data packet can be sent to the cloud.

[0172] Exemplarily, in order to ensure data consistency between the vehicle and the cloud, when the connection is reestablished or established for the first time between the vehicle and the cloud, real-time vehicle data under various vehicle-cloud protocol fields can also be immediately obtained, and based on these data, a new full data packet is generated by variable-length coding. Among them, the number of the full data packet is 0x00. The full data packet is used as the third full data packet and sent to the cloud. After receiving the third full data packet, the cloud can directly use the third full data packet as the latest second reference data packet, or use the vehicle data in the third full data packet to update the data of the most recently updated second reference data packet to obtain the latest updated second reference data packet. After the update is completed, the cloud can generate a fourth confirmation character packet for indicating the successful update status and feedback to the vehicle end (that is, the cloud can generate an ACK packet for indicating the successful update status and feedback to the vehicle end). Furthermore, after receiving the fourth confirmation character packet, the vehicle end can use the third full data packet to update the local first reference data packet, thereby realizing the unification of vehicle-cloud data.

[0173] like Figure 5As shown, it is a schematic diagram of another reporting process of sending a full data packet provided by an embodiment of the present application, wherein, when the connection between the vehicle and the cloud is first established, the connection is re-established, or when periodic reporting is adopted to prevent long-term cumulative errors, the vehicle end can generate a full data packet numbered 0x00 based on the real-time vehicle data under various vehicle-cloud protocol fields and send it to the cloud. The cloud end can receive and process the full data packet, obtain the latest second reference data packet numbered 0x00, and feedback an ACK packet with a status of 0x00 to the vehicle end. After receiving the ACK packet, the vehicle end can use the full data packet to update the latest first reference data packet numbered 0x00.

[0174] In one embodiment, after the vehicle sends a differential data packet to the cloud, the cloud may not receive the differential data packet due to network problems, data loss, etc., and the cloud cannot feedback an ACK packet to the vehicle. In this case, data synchronization between the vehicle and the cloud can also be achieved by following the following steps:

[0175] If the first confirmation character packet is not received within the target time length, return to the step of obtaining the real-time vehicle data and the first reference data packet under various vehicle-cloud protocol fields to send the latest differential data packet.

[0176] Here, the target duration may be a reply waiting time set based on experience.

[0177] Exemplarily, after the vehicle sends a differential data packet to the cloud, if the ACK packet fed back by the cloud is not received within the target time, the real-time vehicle data and the latest first reference data packet under various vehicle-cloud protocol fields can be re-acquired, and the target data can be determined. Then a new differential data packet is generated according to the target data, wherein the number of the differential data packet can be obtained by incrementing the number of the differential data packet to which a reply is not received. After the new differential data packet is generated, it can continue to be sent to the cloud.

[0178] That is, if the ACK packet fed back by the cloud is not received within the target time, the process may return to execute S101 to resend the differential quantization data.

[0179] Optionally, if the first confirmation character packet corresponding to the differential data packet is not received within the target time length, the vehicle end may also attempt to resend the differential data packet. After the number of attempts exceeds the preset target number, if the first confirmation character packet is not received, it may return to S101 to achieve the resending of the differential data packet.

[0180] Optionally, after receiving the differential data packet or the full data packet, the vehicle side can also use the encryption algorithm and integrity verification mechanism agreed with the cloud to encrypt and integrity-check the differential data packet or the full data packet, and send the processed differential data packet or the full data packet to the cloud. After receiving the data packet, the cloud side can first perform decryption processing and integrity verification, and if the verification is successful, use the decrypted data packet for data synchronization.

[0181] It is understandable that, during specific implementation, the transmission strategy of differential data packets and full data packets can be set according to the specific application scenario, and the disclosed embodiment does not limit the specific transmission strategy. For example, in the scenario of caring about old changed data, before reporting a new differential data packet or a full data packet, the previously unreissued data packet cannot be ignored. That is, for a data packet that has not received a reply from the cloud, the data packet needs to be reissued until a reply is received from the cloud. Of course, if the scenario is only concerned with new changed data, if a data packet does not receive a reply from the cloud, the differential data packet corresponding to the new changed data can be directly sent in the next data acquisition cycle, without reissuing the data packet to which a reply has not been received. In short, the VDTP protocol in this application can be used to adapt to the data transmission requirements of various application scenarios, and the transmission logic of the data packet can be set according to specific needs, with high flexibility.

[0182] Based on the above embodiments, it can be seen that in order to solve the problems of bandwidth waste, inability to effectively process frequently changing in-vehicle data with small amplitudes, and lack of optimization mechanism for vehicle-cloud interaction characteristics in the PB protocol in the vehicle-mounted scenario, the disclosed embodiment proposes a VDTP protocol based on the PB protocol and the differential update mechanism. This solution innovatively combines the efficient coding of PB with the differential update strategy, and only transmits field data that has changed compared to the baseline data packet, thereby greatly reducing the amount of data transmitted. At the same time, an intelligent baseline packet management based on ACK packets and a data processing mechanism for vehicle-cloud collaboration are designed to ensure the consistency of vehicle-side and cloud-side data, and optimize long-term data transmission efficiency.

[0183] At the same time, the disclosed embodiment also provides a data update method for the cloud, which realizes data synchronization between the vehicle and the cloud through the interaction between the cloud and the vehicle. Figure 6 As shown, it is a flow chart of a data update method applied to the cloud provided by an embodiment of the present disclosure, which may include the following steps:

[0184] S601: Receive the differential data packet sent by the vehicle end; the differential data packet is generated by the vehicle end according to the target data using a variable-length coding method; the target data is the real-time vehicle data under various vehicle-cloud protocol fields, which is different from the latest updated historical vehicle data in the latest first benchmark data packet stored by the vehicle end.

[0185] Here, the definitions of the above-mentioned differential data packet, target data, vehicle-cloud protocol field, first reference data packet, real-time vehicle data, and historical vehicle data can all be referred to the above-mentioned S101 and will not be repeated here.

[0186] For example, after the vehicle generates a differential data packet, the differential data packet may be sent to the cloud. If the cloud does not receive the differential data packet, any response may be generated. If the cloud receives the differential data packet, the differential data packet may be used for data synchronization.

[0187] S602: Use the differential quantization data packet to update the local latest second reference data packet.

[0188] For example, after receiving the differential data packet, the cloud can verify the integrity and security of the differential data packet. If the verification is passed, it is determined whether the first identifier of the first reference data packet corresponding to the differential data packet is consistent with the third identifier of the latest second reference data packet. If so, the data under the corresponding field in the first reference data can be updated using each target data corresponding to the differential data packet. If they are inconsistent, an ACK packet with a status of 0x01 can be directly generated and fed back to the vehicle end.

[0189] In addition, after receiving the differential data packet, the cloud can also determine whether there is a packet loss or disorder problem based on the second identifier of the differential data packet and the third identifier of the latest second reference data packet. If so, it can generate corresponding prompt information and feedback to the vehicle end.

[0190] S603: Generate a first confirmation character packet according to the update result and feed it back to the vehicle end.

[0191] Exemplarily, when the second reference data packet is updated successfully, the first confirmation character packet may include a status indicating a successful update, a third identifier of the updated second reference data packet, a fourth identifier of the new second reference data packet obtained after the update, and a fifth identifier of the differential quantization data packet used when the cloud updates the updated second reference data packet. When the second reference data packet fails to be updated, the first confirmation character packet may include a status indicating a failed update, and in addition, the information to be included may be set as needed, for example, the identifier of the latest second reference data packet in the cloud, the identifier of the differential quantization data packet used for updating, and other information.

[0192] For the specific implementation steps of S601 to S603, reference may be made to the above embodiments, which will not be described in detail here.

[0193] In this way, by obtaining the differential data packet sent by the vehicle end and using the differential data packet to update the latest local second reference data packet, timely synchronization of the target data changed on the vehicle end can be achieved. Then, a first confirmation character packet is generated based on the update result and fed back to the vehicle end, so that the vehicle end can determine whether to update the first reference data packet stored on the vehicle end based on the first confirmation character packet, thereby achieving synchronization of the reference data packets between the vehicle end and the cloud.

[0194] In one embodiment, the above S603 may be implemented according to the following steps:

[0195] In the case of a successful update, a first confirmation character packet indicating a successful update status is generated and fed back to the vehicle end based on the third identifier of the second reference data packet and the fourth identifier of the updated second reference data packet; or, in the case of a failed update, a first confirmation character packet indicating an failed update status is generated and fed back to the vehicle end.

[0196] Exemplarily, if the update is successful, an ACK packet with a status of 0x00 may be generated, and the packet includes the number of the second reference data packet before the update and the number of the second reference data packet after the update. If the update fails, an ACK packet with a status of 0x01 may be generated.

[0197] In one embodiment, the differential quantization data packet includes the data transmission protocol version of the vehicle side, the encoded data corresponding to the target data, the data packet type and the timestamp information. Among them, the timestamp information can be used for timing management of the data and the data time display requirements of the cloud platform. The types of data packets uploaded by the vehicle side can all be reporting packet types.

[0198] For S602, the following steps can be followed:

[0199] S602-1: Determine a second reference data packet according to the data transmission protocol version from the latest third reference data packets corresponding to various data transmission protocol versions stored locally.

[0200] The cloud stores the latest reference data packets corresponding to various data transmission protocol versions, which are referred to as third reference data packets here. Since the cloud can interact with multiple vehicle terminals and different vehicle terminals have different corresponding data transmission protocol versions, in order to accurately synchronize the data transmitted by each vehicle terminal, the cloud can use the data transmission protocol version in the differential data packet to find the latest second reference data packet that is consistent with the vehicle terminal version, so that the cloud and the vehicle terminal that sends the differential data packet use the same version.

[0201] In specific implementation, after receiving the data packet (which may be a differential data packet or a full data packet) from the vehicle, the cloud can parse the data packet to obtain the data packet type and data transmission protocol version information carried in the data packet, which may specifically be a version number. Then, in the case where the data packet type is a reporting packet type, the cloud can find a data packet that matches the version number from the third reference data packets corresponding to each stored version, and use the data packet as the second reference data packet.

[0202] In addition, after parsing the data packet, in addition to obtaining the data transmission protocol version, the encoded data and timestamp information corresponding to each target data can also be obtained.

[0203] S602-2: Deserialize the encoded data to obtain the field attributes of the vehicle-cloud protocol field corresponding to the target data, the data value of the target data, the first identifier of the first reference data packet, the second identifier of the differential data packet, and the number of target data.

[0204] It should be noted that when deserializing the encoded data, the data values ​​corresponding to each vehicle-cloud protocol field except the vehicle-cloud protocol field to which the target data belongs will be maintained as the most recently updated value and will not be serialized as the default value.

[0205] S602-3: When the number of target data is consistent with the number of data values, determine whether the differential quantization data packet meets the update requirement according to the first identifier and the third identifier.

[0206] Here, the update requirement is used to indicate whether the second reference data packet can be updated using the differential quantization data packet.

[0207] In specific implementation, when the number of target data is consistent with the number of data values, it can be explained that there is no lost target data, and then it can be determined whether the first identifier and the third identifier are consistent. If so, it can be determined that the differential data packet meets the update requirements. If they are inconsistent, it can be determined that it does not meet the update requirements, ignore the differential data packet, do not update the data, and generate an ACK packet with a status of 0x01 to feed back to the vehicle end.

[0208] Alternatively, when the third identifier is consistent with the first identifier, it is also possible to determine whether the second identifier is greater than the third identifier. If so, it can be determined that the differential data packet meets the update requirements; otherwise, it is determined that it does not meet the update requirements, and data update is not performed and an ACK packet with a status of 0x01 is generated and fed back to the vehicle end.

[0209] S602-4: If yes, update the data of the second reference data packet according to the field attributes and data values.

[0210] Exemplarily, when the third identifier is consistent with the first identifier, the corresponding historical vehicle data in the second benchmark data packet can be obtained according to the field attributes of each target data, and the historical vehicle data can be updated using the data value of the target data to obtain an updated second benchmark data packet.

[0211] It should be noted that the timestamp information in the differential data packet can be stored as the timestamp information of the target data when the target data is used to update the second benchmark data packet in the cloud, and can be used for data timing management and data time display requirements using the cloud platform.

[0212] In one embodiment, the cloud can also receive a full data packet sent by the vehicle end. Specifically, it can receive a first full data packet transmitted by the vehicle end. The first full data packet is generated and sent by the vehicle end according to real-time vehicle data under various vehicle-cloud protocol fields when the third identifier is inconsistent with the first identifier of the first reference data packet. The first full data packet is used as the latest second reference data packet, and a second confirmation character packet indicating the successful update status is generated and fed back to the vehicle end.

[0213] Optionally, the cloud can also receive a second full data packet transmitted by the vehicle; wherein the second full data packet is generated and sent by the vehicle according to the real-time vehicle data under various vehicle-cloud protocol fields when the vehicle determines that the data reporting period has arrived. The cloud can then use the second full data packet as the latest second reference data packet, and generate a third confirmation character packet indicating the update success status and feed it back to the vehicle.

[0214] Optionally, the cloud can also receive a third full data packet transmitted by the vehicle; wherein the third full data packet is generated and sent based on real-time vehicle data under various vehicle-cloud protocol fields when the vehicle and the cloud establish a connection for the first time or re-establish a connection. Then, the cloud can use the third full data packet as the latest second reference data packet, and generate a fourth confirmation character packet indicating the update success status and feed it back to the vehicle.

[0215] For the specific processing process of various full data packets, please refer to the relevant introduction on the vehicle side, which will not be repeated here.

[0216] To facilitate understanding of the data update method provided in the embodiment of the present disclosure, the vehicle-cloud data synchronization process in different situations is shown below. However, in specific implementation, the specific vehicle-cloud interaction method can be designed according to requirements and is not limited to the following examples:

[0217] The data acquisition cycle is 5 seconds based on demand, and the cloud only cares about the latest data and does not care about old data. The data reporting cycle is 15 minutes (min):

[0218] The reporting period of differential data is to report a differential data packet to the cloud every 5 seconds, and the period block is synchronized every 15 minutes, that is, a full data packet is reported to the cloud every 15 minutes.

[0219] The vehicle needs to report a full data packet to the cloud each time it wakes up from sleep mode. The reliability of the connection between the vehicle and the cloud is guaranteed by the MQTT protocol (ensuring message reliability in a weak network environment).

[0220] ①. Vehicle-to-cloud data transmission process under normal communication conditions:

[0221] The vehicle sends a data packet:

[0222] Send a full data packet, numbered 0x00; the reference data packet number is 0x00 (when sending a full data packet, the full data packet is used as the reference data packet by default, and the reference data packet number is 0x00 by default)

[0223] The cloud responds with an ACK data packet: Sequence number: the number of the baseline data packet before the update, the number of the second baseline data packet after the update is 0x00 (i.e. the updated second baseline data packet is a full data packet); ACK status: 0x00 success; The vehicle side updates the baseline data packet: the baseline data packet after the vehicle side is updated is a full data packet, numbered 0x00.

[0224] 5s later: the vehicle sends a differential data packet: 0x01, a reference data packet: 0x00; the cloud replies with an ACK packet: the reference data packet before update: 0x00, the reference data packet after update: 0x01; ACK status: 0x00 Success; the reference data packet on the vehicle side is updated: 0x01; 5s later: the vehicle sends a differential data packet: 0x02, a reference data packet: 0x01; the cloud replies with an ACK packet: the reference data packet before update: 0x01, the reference data packet after update: 0x02; ACK status: 0x00 Success; the reference data packet on the vehicle side is updated: 0x02

[0225] ②. The vehicle-to-cloud data transmission process in the case of disconnection, the baseline data packet of the vehicle end is 0x02:

[0226] After 5s (disconnection)

[0227] The vehicle sends a differential data packet: 0x03, a reference data packet: 0x02; the cloud: no response; the vehicle's reference data packet: not updated; the vehicle tries to resend: sending a differential data packet: 0x03, a reference data packet: 0x02;

[0228] After 5s (still disconnected)

[0229] The vehicle side no longer resends 0x03; the vehicle side sends the difference data packet: 0x04, the reference data packet: 0x02; the cloud: no reply; the vehicle side reference data packet: not updated; try to resend: send the difference data packet: 0x04, the reference data packet: 0x02

[0230] After 5s (restore connection)

[0231] The vehicle side no longer resends 0x04; the vehicle side sends a differential data packet: 0x05, a reference data packet: 0x02; the cloud side replies with an ACK packet: the reference data packet before update: 0x02, the reference data packet after update: 0x05; ACK status: 0x00 Success; Update the vehicle side reference data packet: 0x05

[0232] After 5 seconds

[0233] The vehicle sends a differential data packet: 0x06, the vehicle's reference data packet: 0x05; the cloud responds with an ACK packet: the reference data packet before update: 0x05, the reference data packet after update: 0x06; ACK status: 0x00 Success; Update the vehicle's reference data packet: 0x06

[0234] …

[0235] ③. Data delay leads to disordered scenarios

[0236] The vehicle sends a differential data packet: 0x14, and a vehicle-side reference data packet: 0x13; the cloud does not respond; the vehicle tries to resend data: The vehicle sends a differential data packet: 0x14, and a vehicle-side reference data packet: 0x13;

[0237] 5s later: the vehicle sends a differential data packet: 0x15, the vehicle sends a reference data packet: 0x13; the cloud sends an ACK packet: the reference data packet before update: 0x13, the reference data packet after update: 0x14 (the return packet of the previous data packet sent by the vehicle); ACK status: 0x00 success; the vehicle updates the reference data packet: 0x14

[0238] After 5s: the vehicle sends a differential data packet: 0x16, the vehicle sends a reference data packet: 0x14; the cloud sends an ACK packet: the reference data packet before update: 0x14, the reference data packet after update: 0x16; ACK status: 0x00 success; the vehicle updates the reference data packet: 0x16; the vehicle-cloud data transmission returns to normal working conditions

[0239] …

[0240] 5s later: the vehicle sends a differential data packet: 0xb4, the vehicle sends a reference data packet: 0xb3; the cloud sends an ACK packet: the reference data packet before update: 0xb3, the reference data packet after update: 0xb4; ACK status: 0x00 success; the vehicle updates the reference data packet: 0xb4;

[0241] …

[0242] After 15 minutes, cycle:

[0243] The vehicle sends a full data packet: 0x00, the vehicle's baseline data packet: 0x00; the cloud replies with an ACK packet: the baseline data packet before update: 0xb4, the baseline data packet after update: 0x00; ACK status: 0x00 success; the vehicle updates the baseline data packet: 0x00. After continuous cyclic reporting, data synchronization between the vehicle and the cloud is achieved.

[0244] Those skilled in the art will appreciate that, in the above method of specific implementation, the order in which the steps are written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of the steps should be determined by their functions and possible internal logic.

[0245] In addition, an embodiment of the present disclosure further provides a vehicle, wherein the vehicle includes a controller, wherein the controller includes:

[0246] a memory for storing machine-readable instructions; and

[0247] The processor is used to call and execute the machine-readable instructions stored in the memory to implement the steps of the data updating method as described in the above embodiments.

[0248] Based on the same technical concept, the embodiment of the present application also provides a computer device. Figure 7 FIG. 1 is a schematic diagram of a computer device provided in an embodiment of the present application, including:

[0249] Processor 701, memory 702 and bus 703. The memory 702 stores machine-readable instructions executable by the processor 701, and the processor 701 is used to execute the machine-readable instructions stored in the memory 702. When the machine-readable instructions are executed by the processor 701, the processor 701 performs the following steps: S101: Acquire real-time vehicle data and a first reference data packet under various vehicle-cloud protocol fields; the first reference data packet includes historical vehicle data under various vehicle-cloud protocol fields that are locally stored and updated on the vehicle side; the vehicle-cloud protocol field is a data field set in the data transmission protocol between the vehicle side and the cloud side; S102: If there is target data different from the historical vehicle data in the real-time vehicle data, a variable-length coding method is used to generate a differential quantization data packet according to the target data; and S103: Send the differential quantization data packet to the cloud; the cloud The end is used to update the second reference data packet in the cloud according to the differential data packet; the second reference data packet includes the historical vehicle data under each vehicle-cloud protocol field that is remotely stored in the cloud and is updated the most recently; or, when the machine-readable instruction is executed by the processor 701, the processor 701 performs the following steps: S601: receiving the differential data packet sent by the vehicle end; the differential data packet is generated by the vehicle end according to the target data using a variable-length coding method; the target data is the real-time vehicle data under various vehicle-cloud protocol fields, which is different from the historical vehicle data updated the most recently in the latest first reference data packet stored in the vehicle end; S602: using the differential data packet, the latest local second reference data packet is updated; and S603: based on the update result, a first confirmation character packet is generated and fed back to the vehicle end.

[0250] The above-mentioned memory 702 includes a memory 7021 and an external memory 7022; the memory 7021 here is also called an internal memory, which is used to temporarily store the calculation data in the processor 701, as well as the data exchanged with the external memory 7022 such as a hard disk. The processor 701 exchanges data with the external memory 7022 through the memory 7021. When the computer device is running, the processor 701 communicates with the memory 702 through the bus 703, so that the processor 701 executes the execution instructions mentioned in the above method embodiment.

[0251] The present disclosure also provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the data updating method described in the above method embodiment are executed. The storage medium can be a volatile or non-volatile computer-readable storage medium.

[0252] The computer program product of the data updating method provided in the embodiment of the present disclosure includes a computer-readable storage medium storing program code, and the instructions included in the program code can be used to execute the steps of the data updating method described in the above method embodiment. For details, please refer to the above method embodiment, which will not be repeated here.

[0253] The computer program product may be implemented in hardware, software or a combination thereof. In one optional embodiment, the computer program product is embodied as a computer storage medium, and in another optional embodiment, the computer program product is embodied as a software product, such as a software development kit (SDK) and the like.

[0254] Those skilled in the art can clearly understand that, for the convenience and simplicity of description, the specific working process of the system and device described above can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here. In the several embodiments provided in the present disclosure, it should be understood that the disclosed system, device and method can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some communication interfaces, and the indirect coupling or communication connection of the device or unit can be electrical, mechanical or other forms.

[0255] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0256] In addition, each functional unit in each embodiment of the present disclosure may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0257] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a non-volatile computer-readable storage medium that is executable by a processor. Based on this understanding, the technical solution of the present disclosure, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present disclosure. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0258] If the technical solution of this application involves personal information, the product using the technical solution of this application has clearly informed the personal information processing rules and obtained the individual's voluntary consent before processing the personal information. If the technical solution of this application involves sensitive personal information, the product using the technical solution of this application has obtained the individual's separate consent before processing the sensitive personal information, and at the same time meets the "explicit consent" requirement. For example, on personal information collection devices such as cameras, clear and prominent signs are set to inform that the personal information collection scope has been entered and personal information will be collected. If the individual voluntarily enters the collection scope, it is deemed that he or she agrees to the collection of his or her personal information; or on the device that processes personal information, the personal information processing rules are notified by obvious signs / information, and the individual's authorization is obtained through pop-up information or by asking the individual to upload his or her personal information; among them, the personal information processing rules may include information such as the personal information processor, the purpose of personal information processing, the processing method, and the type of personal information processed.

[0259] Finally, it should be noted that the above-described embodiments are only specific implementation methods of the present disclosure, which are used to illustrate the technical solutions of the present disclosure, rather than to limit them. The protection scope of the present disclosure is not limited thereto. Although the present disclosure is described in detail with reference to the above-described embodiments, ordinary technicians in the field should understand that any technician familiar with the technical field can still modify the technical solutions recorded in the above-described embodiments within the technical scope disclosed in the present disclosure, or can easily think of changes, or make equivalent replacements for some of the technical features therein; and these modifications, changes or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present disclosure, and should be included in the protection scope of the present disclosure. Therefore, the protection scope of the present disclosure should be based on the protection scope of the claims.

Claims

1. A data updating method, characterized in that: Applied to the vehicle side, including: Acquire real-time vehicle data and a first reference data packet under various vehicle-to-cloud protocol fields; the first reference data packet includes the latest updated historical vehicle data under each of the vehicle-to-cloud protocol fields stored locally on the vehicle end; the vehicle-to-cloud protocol field is a data field set in the data transmission protocol between the vehicle end and the cloud end; If there is target data different from the historical vehicle data in the real-time vehicle data, a variable-length coding method is used to generate a differential quantization data packet according to the target data; The differential data packet is sent to the cloud; the cloud is used to update a second reference data packet in the cloud according to the differential data packet; the second reference data packet includes the latest updated historical vehicle data under each of the vehicle-cloud protocol fields remotely stored in the cloud.

2. The method according to claim 1, characterized in that The method of using variable length coding to generate a differential quantization data packet according to the target data includes: Determine the data transmission protocol version of the vehicle end and the data packet type of the differential data packet; different data transmission protocol versions correspond to different vehicle-to-cloud protocol fields; According to the first identifier of the first reference data packet, determine the second identifier of the differential quantization data packet, and use a variable-length coding method to encode the first identifier, the second identifier, the field attribute of the vehicle-cloud protocol field to which each of the target data belongs, the data value of each of the target data, and the number of target data to obtain encoded data; The differential quantization data packet is generated according to the encoded data, the data transmission protocol version, the data packet type and the current timestamp information.

3. The method according to claim 1, characterized in that After sending the differential data packet to the cloud, the method further includes: receiving a first confirmation character packet fed back by the cloud; the first confirmation character packet is generated and sent by the cloud after the second reference data packet is updated; When the state of the first confirmation character packet indicates that the update is successful, obtaining from the first confirmation character packet a third identifier of the updated second reference data packet and a fourth identifier of the updated second reference data packet; When the third identifier is consistent with the first identifier of the first reference data packet, the first reference data packet is updated using the target data in the differential quantization data packet having the fourth identifier to obtain the latest updated first reference data packet.

4. The method according to claim 3, characterized in that The method further comprises: When the third identifier is inconsistent with the first identifier of the first reference data packet, generating a first full data packet according to the real-time vehicle data under various vehicle-to-cloud protocol fields; Sending the first full data packet to the cloud; the cloud is used to use the first full data packet as the latest updated second reference data packet, and feed back a second confirmation character packet to the vehicle end; In response to receiving the second confirmation character packet, when the status of the second confirmation character packet indicates that the update is successful, the first full data packet is used as the first reference data packet that is most recently updated.

5. The method according to claim 1, characterized in that After transmitting the differential quantization data packet to the cloud, the method further includes: In response to reaching the data reporting cycle, a second full data packet is generated based on the real-time vehicle data under various vehicle-cloud protocol fields, and the second full data packet is sent to the cloud.

6. The method according to claim 1, characterized in that The method further comprises: In response to the vehicle side establishing a connection with the cloud for the first time or re-establishing a connection with the cloud, a third full data packet is generated according to the real-time vehicle data under various vehicle-cloud protocol fields, and the third full data packet is sent to the cloud.

7. The method according to claim 3, characterized in that The method further comprises: If the first confirmation character packet is not received within the target time length, return to the step of obtaining the real-time vehicle data and the first reference data packet under various vehicle-cloud protocol fields to generate and send the latest differential data packet.

8. A data updating method, characterized in that: Applied in the cloud, including: Receive a differential quantization data packet sent by the vehicle end; the differential quantization data packet is generated by the vehicle end according to the target data using a variable length coding method; the target data is data in the real-time vehicle data under various vehicle-cloud protocol fields that is different from the latest updated historical vehicle data in the latest first reference data packet stored in the vehicle end; Using the differential quantization data packet, updating the local latest second reference data packet; According to the update result, a first confirmation character packet is generated and fed back to the vehicle end.

9. The method according to claim 8, characterized in that The step of generating a first confirmation character packet according to the update result and feeding it back to the vehicle end includes: In the case of a successful update, a first confirmation character packet indicating a successful update status is generated and fed back to the vehicle end based on the third identifier of the second reference data packet and the fourth identifier of the updated second reference data packet; or, in the case of a failed update, a first confirmation character packet indicating an failed update status is generated and fed back to the vehicle end.

10. The method according to claim 8, characterized in that The differential quantization data packet includes the data transmission protocol version of the vehicle end and the encoded data corresponding to the target data; The method of updating the local latest second reference data packet by using the differential quantization data packet includes: According to the data transmission protocol version, determining the second reference data packet from the latest third reference data packets corresponding to various data transmission protocol versions stored locally; Deserialize the encoded data to obtain the field attribute of the vehicle-cloud protocol field corresponding to the target data, the data value of the target data, the first identifier of the first reference data packet, the second identifier of the differential data packet, and the quantity of the target data; In a case where the quantity of the target data is consistent with the quantity of the data values, determining whether the differential quantization data packet meets the update requirement according to the first identifier and the third identifier; If so, the second reference data packet is updated according to the field attribute and the data value.

11. The method according to claim 9, characterized in that The method further comprises: receiving a first full data packet transmitted by the vehicle end, where the first full data packet is generated and sent by the vehicle end according to real-time vehicle data under various vehicle-to-cloud protocol fields when the third identifier is inconsistent with the first identifier of the first reference data packet; The first full data packet is used as the latest second reference data packet, and a second confirmation character packet indicating a successful update status is generated and fed back to the vehicle end.

12. The method according to claim 8, characterized in that The method further comprises: receiving a second full data packet transmitted by the vehicle end; the second full data packet is generated and sent by the vehicle end according to the real-time vehicle data under various vehicle-to-cloud protocol fields when determining that a data reporting period has arrived; The second full data packet is used as the latest second reference data packet, and a third confirmation character packet indicating a successful update status is generated and fed back to the vehicle end.

13. The method according to claim 8, characterized in that The method further comprises: receiving a third full data packet transmitted by the vehicle end; the third full data packet is generated and sent according to the real-time vehicle data under various vehicle-cloud protocol fields when the vehicle end establishes a connection with the cloud end for the first time or re-establishes a connection; The third full data packet is used as the latest second reference data packet, and a fourth confirmation character packet indicating a successful update status is generated and fed back to the vehicle end.

14. A vehicle, characterized in that: A controller is included, the controller comprising: a memory for storing machine-readable instructions; and A processor, configured to call and execute the machine-readable instructions stored in the memory to implement the steps of the data updating method according to any one of claims 1 to 13.

15. A computer device, characterized in that: include: A processor and a memory, wherein the memory stores machine-readable instructions executable by the processor, and the processor is used to execute the machine-readable instructions stored in the memory. When the machine-readable instructions are executed by the processor, the processor executes the steps of the data updating method according to any one of claims 1 to 13.

16. A computer program product, which, when executed by a computer device, executes the steps of the data updating method according to any one of claims 1 to 13.

Images