CN116489190A - Communication method, device, electronic device and storage medium for vehicle and cloud - Google Patents

Abstract

The present application provides a communication method, device, electronic equipment and storage medium for a vehicle and a cloud. The method includes: obtaining a digital certificate and a public-private key pair of the vehicle, and configuring the digital certificate and the public-private key pair of the vehicle on a predetermined analog communication tool; using the analog communication tool to perform two-way certificate authentication on the communication proxy service between the vehicle end and the cloud, so as to establish a symmetrical encryption channel between the vehicle end and the communication proxy service; determining the communication data sent by the vehicle end to the communication proxy service, performing a serialization operation on the communication data to obtain a byte array corresponding to the communication data; using a predetermined character array to convert the byte array into text in a target format, and reporting the text in the target format to the cloud through a symmetric encryption channel . This application is simple to operate, low in learning costs, and easy to understand, which improves the convenience of communication between the vehicle end and the cloud.

Description

Communication method, device, electronic device and storage medium for vehicle and cloud

technical field

The present application relates to the technical field of new energy vehicles, and in particular to a communication method, device, electronic equipment and storage medium for vehicles and the cloud.

Background technique

The wide application of new energy vehicles in the industry requires remote monitoring and upgrading of vehicles, for which efficient and secure communication between vehicle terminals and the cloud is required. The MQTT protocol and protobuf format are widely used in the field of new energy vehicles as effective communication technologies. However, how to implement certificate authentication between vehicles and clouds and simulate MQTT communication in protobuf format in the test environment to facilitate development and debugging has become a challenge.

The existing simulation methods mainly include two schemes: using communication tools and writing codes. Among them, the communication tool has many advantages, but the Payload format used by the communication tool does not support protobuf. In the program of writing code, such as using JAVA code to simulate the process of reporting information from the car to the cloud. However, when this method realizes two-way certificate authentication, the learning cost and time cost are too large, and it is not suitable for one-time verification in a special environment. At the same time, the Payload format of the communication tool in the existing method does not support protobuf. Therefore, the existing vehicle-cloud communication method has the problems of complicated operation, high learning cost, and inconvenient communication.

Contents of the invention

In view of this, the embodiment of the present application provides a communication method, device, electronic device and storage medium for a vehicle and the cloud, so as to solve the problems of complex operation, high learning cost and inconvenient communication in the vehicle-cloud communication method in the prior art.

The first aspect of the embodiment of the present application provides a method for communication between the vehicle and the cloud, including: obtaining the digital certificate and the public-private key pair of the vehicle, and configuring the digital certificate and the public-private key pair of the vehicle to a predetermined analog communication tool; using the analog communication tool to perform two-way certificate authentication on the communication proxy service between the vehicle end and the cloud, so as to establish a symmetric encryption channel between the vehicle end and the communication proxy service; determining the communication data sent by the vehicle end to the communication proxy service, performing serialization operations on the communication data to obtain a byte array corresponding to the communication data; using a predetermined character array to convert the byte array into a target format, and report the text in the target format to the cloud through a symmetric encrypted channel.

The second aspect of the embodiment of the present application provides a communication device for a vehicle and the cloud, including: a configuration module configured to obtain a digital certificate and a public-private key pair of the vehicle, and configure the digital certificate and the public-private key pair of the vehicle to a predetermined analog communication tool; an authentication module configured to use the analog communication tool to perform two-way certificate authentication on the communication agent service between the vehicle end and the cloud, so as to establish a symmetric encrypted channel between the vehicle end and the communication agent service; The byte array corresponding to the communication data is obtained; the conversion module is configured to use a predetermined character array to convert the byte array into a text in a target format, and report the text in the target format to the cloud through a symmetric encrypted channel.

A third aspect of the embodiments of the present application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and operable on the processor, and the processor implements the steps of the above method when executing the program.

A fourth aspect of the embodiments of the present application provides a computer-readable storage medium, where a computer program is stored in the computer-readable storage medium, and when the computer program is executed by a processor, the steps of the foregoing method are implemented.

The above at least one technical solution adopted in the embodiment of the present application can achieve the following beneficial effects:

By obtaining the vehicle’s digital certificate and public-private key pair, configure the vehicle’s digital certificate and public-private key pair on the predetermined analog communication tool; use the analog communication tool to perform two-way certificate authentication on the communication agent service between the vehicle end and the cloud, so as to establish a symmetric encrypted channel between the vehicle end and the communication agent service; determine the communication data sent by the vehicle end to the communication agent service, perform serialization operations on the communication data, and obtain the byte array corresponding to the communication data; use the predetermined character array to convert the byte array into text in the target format, and report the text in the target format to the cloud through the symmetric encrypted channel. This application can use analog communication tools to complete the two-way certificate authentication between the car and the cloud, and can convert the communication data into the required target format, and report the communication data in the target format to the cloud. Not only is the operation simple, the learning cost is low, and it is easy to understand.

Description of drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the accompanying drawings used in the embodiments or prior art descriptions. Obviously, the accompanying drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, other accompanying drawings can also be obtained based on these drawings without creative work.

FIG. 1 is a schematic flowchart of a method for communicating between a vehicle and a cloud provided by an embodiment of the present application;

Fig. 2 is a schematic flow diagram of the MQTT communication that realizes the authentication of the vehicle cloud certificate and simulates the protobuf format provided by the embodiment of the present application;

Fig. 3 is a schematic structural diagram of a communication device for a vehicle and a cloud provided by an embodiment of the present application;

FIG. 4 is a schematic structural diagram of an electronic device provided by an embodiment of the present application.

Detailed ways

In the following description, specific details such as specific system structures and technologies are presented for the purpose of illustration rather than limitation, so as to thoroughly understand the embodiments of the present application. It will be apparent, however, to one skilled in the art that the present application may be practiced in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.

On the one hand, MQTT is a lightweight message transmission protocol based on the publish/subscribe model. It is specially designed for IoT applications in low-bandwidth and unstable network environments. It can provide real-time and reliable message services for networked devices with very little code. MQTT has the following characteristics:

1. Lightweight and efficient, saving bandwidth: MQTT minimizes the additional consumption of the protocol itself, and the message header only needs to occupy a minimum of 2 bytes, which can run stably in a network environment with limited bandwidth. At the same time, the MQTT client only needs to occupy very small hardware resources and can run on various resource-constrained edge devices.

2. Reliable message delivery: The MQTT protocol provides 3 message quality of service levels (Quality of Service), which ensures the reliability of message delivery in different network environments (0-at most once, 1-at least once, 2-exactly once).

3. Mass connection support: The MQTT protocol has taken into account the growing mass of IoT devices since its inception. Thanks to its excellent design, MQTT-based IoT applications and services can easily have high concurrency, high throughput, and high scalability.

4. Secure two-way communication: Relying on the publish-subscribe model, MQTT allows two-way message communication between devices and the cloud. The advantage of the publish-subscribe model is that the publisher and the subscriber do not need to establish a direct connection, nor do they need to be online at the same time, but the message server is responsible for the routing and distribution of all messages.

5. Online status awareness: In order to deal with network instability, MQTT provides a heartbeat keep-alive (KeepAlive) mechanism. When there is no message interaction between the client and the server for a long time, Keep Alive keeps the connection from being disconnected. Once disconnected, the client can immediately perceive and reconnect immediately.

On the other hand, protobuf (protocol buffer) is a binary format developed by Google for serializing structured data. As an efficient and compact data exchange format, it is designed to enable data transfer and communication between different platforms and programming languages. protobuf has the following characteristics:

1. Language independent: protobuf supports multiple programming languages, such as C++, Java, Python, etc. Through the protobuf compiler (protoc), codes in different programming languages can be generated according to the corresponding data structure definition (.proto file).

2. Platform independent: Since protobuf is a binary format, it can efficiently exchange data between different platforms and operating systems.

3. High performance: Compared with traditional data exchange formats such as XML and JSON, protobuf has smaller data volume and faster parsing speed, thereby reducing the performance overhead of network transmission and parsing.

4. Scalability: Without affecting the compatibility of existing data, new fields can be added to the protobuf data structure to support the continuous development of the system.

Thanks to protobuf's efficient, compact and scalable features, protobuf is widely used in communication protocols, data storage, RPC (Remote Procedure Call) framework and other fields.

Based on the above advantages, in the selection of new energy vehicle communication technology, the MQTT communication protocol is usually used, and the protobuf communication content is used for serialization and deserialization. In the absence of a real vehicle and a TBOX platform, how to simulate the information reported by the vehicle during the cloud OTA upgrade system test (for example: the upgrade software package starts to download, the result of the download, the start of installation, the result of the installation, etc.) has become a big problem.

It should be noted that the cloud OTA upgrade system test is a remote online upgrade service for new energy vehicles. This service allows manufacturers to push software updates through wireless networks without requiring users to go to the service center to update. The cloud OTA upgrade system can realize the addition of new functions, repair of system defects, and performance optimization. In this process, the information reported by the vehicle end is crucial to the operation and upgrade results of the system.

In the absence of a real vehicle and a TBOX (vehicle communication module), it is indeed a big challenge to simulate new energy vehicles to report information. At present, there are usually two ways to solve this problem:

The first way is to use a simulator: a software simulator can be developed to simulate the communication process between the vehicle and TBOX, including various information reported by the vehicle. The advantage of this method is that the cost is low, and it is convenient and fast to verify the system function. However, the simulator may not be able to completely simulate various abnormal situations in the actual environment, so there may be certain limitations.

The second way is to write code simulation: by using JAVA code to simulate the process of reporting information from the vehicle to the cloud, by writing code, more flexible control and customization requirements can be achieved, and Payload in protobuf format can be supported. This approach may require more development and maintenance than using tools, but offers more flexibility to meet specific needs.

In the process of solving the above technical problems, new problems have emerged. In the formal production environment, in order to ensure the security of the communication between the car and the cloud, two-way certificate authentication (SSL) will be performed before the communication. The steps of certificate authentication can be realized through the code, but the learning cost and time cost of writing the code are too large, and it is not suitable for one-time verification in a special environment. According to the functional characteristics of the technical solution using the simulator, although the simulator supports CA, self-signed certificates, and single and two-way SSL authentication, the Payload format does not support protobuf.

In view of this, in order to solve the above problems, the embodiment of the present application provides a test method that realizes the authentication of the vehicle cloud certificate and simulates the MQTT communication in the protobuf format. This application obtains the certificate and public-private key pair from the vehicle and configures them on the simulated communication tool, and uses the simulated communication tool to complete the SSL two-way certificate authentication between the vehicle terminal and the cloud communication proxy service. And the original JAVA code is modified, the original protobuf format communication content is directly reported to the cloud, and the protobuf format communication content is converted into Hex format and output as text, and then the simulation communication tool is used to configure the certificate and key of the previous vehicle to establish an SSL channel with the cloud.

The content of the technical solution of the present application will be described in detail below in conjunction with the accompanying drawings and specific embodiments.

Fig. 1 is a schematic flowchart of a communication method between a vehicle and a cloud provided by an embodiment of the present application. The method for communicating between the vehicle and the cloud in FIG. 1 can be executed by an application program. As shown in Figure 1, the communication method for the vehicle and the cloud may specifically include:

S101. Obtain the digital certificate and the public-private key pair of the vehicle, and configure the digital certificate and the public-private key pair of the vehicle to a predetermined analog communication tool;

S102, using the analog communication tool to perform two-way certificate authentication on the communication agent service between the vehicle end and the cloud, so as to establish a symmetric encryption channel between the vehicle end and the communication agent service;

S103, determine the communication data sent by the vehicle end to the communication agent service, perform a serialization operation on the communication data, and obtain a byte array corresponding to the communication data;

S104. Convert the byte array into text in a target format by using a predetermined character array, and report the text in the target format to the cloud through a symmetric encryption channel.

In some embodiments, obtaining the digital certificate and the public-private key pair of the vehicle, and configuring the digital certificate and the public-private key pair of the vehicle on a predetermined analog communication tool includes:

Obtain the digital certificate and the public-private key pair corresponding to the actual vehicle, and configure the digital certificate and the public-private key pair of the vehicle to the analog communication tool, wherein the analog communication tool adopts the MQTTX tool, and the analog communication tool is used to complete the two-way certificate authentication and communication data transmission between the vehicle end and the communication proxy service of the cloud.

Specifically, in a formal production environment, in order to ensure the security of communication between the vehicle and the cloud, mutual certificate authentication (SSL) is required. In the embodiment of the present application, the certificate and the public-private key pair of the vehicle will be obtained from the real vehicle, and the certificate and the public-private key pair of the vehicle will be configured in the simulated communication tool, so that the simulated communication tool can be used to complete the SSL two-way certificate authentication between the vehicle terminal and the MQTT proxy service (ie, the communication proxy service), which can ensure the security in the communication process.

Further, two-way certificate authentication (SSL) means that in the Secure Socket Layer (Secure Socket Layer, SSL) protocol, both parties (client and server) need to provide digital certificates to verify each other's identities. The SSL protocol is an encryption protocol widely used in network communication, which can ensure the security and integrity of data in network connections. The SSL protocol has been replaced by the successor Transport Layer Security (TLS) protocol, but it is often referred to as SSL/TLS.

In the normal SSL/TLS communication process, usually only the server needs to provide a certificate, and the client confirms the identity of the server by verifying the server certificate. This situation is known as one-way certificate authentication. However, in some scenarios, a higher level of security is required, and two-way certificate authentication comes in handy. The basic process and principles of two-way certificate authentication (also known as client certificate authentication, two-way SSL/TLS authentication) are as follows:

The client establishes a connection with the server and requests a certificate from the server.

The server sends its digital certificate (usually containing a public key) to the client.

The client verifies the legitimacy of the server certificate. If the certificate is valid, the client will continue to communicate; otherwise, the communication will be terminated.

At this time, the server will also ask the client to provide its digital certificate. The client sends its digital certificate to the server.

The server verifies the legitimacy of the client certificate. If the certificate is valid, the server will continue to communicate; otherwise, the communication will be terminated.

The client and server establish an encrypted channel by using public key cryptography and key exchange algorithms.

It should be noted that, in the scenario of the embodiment of the present application, the client here can be regarded as the vehicle end, and the server end can be regarded as the cloud. Two-way certificate authentication is very important in scenarios that require high security, such as financial transactions and confidential communications. Through two-way certificate authentication, both the client and the server can confirm each other's identity, thus ensuring the security of communication.

In a specific example, the simulated communication tool can use the MQTTX tool, which is a cross-platform MQTT5.0 desktop client, open sourced by EMQ. By using MQTTX, users can easily create MQTT connections, subscribe topics (Topic) and publish messages. MQTTX has the characteristics of an elegant chat interface, cross-platform support, multi-language support, and conversion of multiple Payload formats.

However, since the tool does not support the Payload in protobuf format, this means that if you need to use protobuf format for communication data transmission, this method cannot meet the demand. Therefore, the embodiment of the present application transforms the Java code and converts the communication content in the protobuf format to the Hex format, so that the MQTTX tool can support the communication data transmission in the protobuf format, and solves the problem that the Payload format does not support protobuf.

The process of using the MQTTX tool for two-way certificate authentication and realizing the conversion of communication content in protobuf format in the embodiment of the present application will be described in detail below with reference to the accompanying drawings. As shown in Figure 2, Figure 2 is a schematic flow diagram of the MQTT communication that implements the vehicle cloud certificate authentication and simulates the protobuf format provided by the embodiment of the application.

In some embodiments, the two-way certificate authentication is performed on the communication agent service between the vehicle end and the cloud by using the communication tool, including:

Use the car end to send negotiation communication information to the communication proxy service in the cloud, and the negotiation communication information includes the SSL version and encryption suite supported by the car end;

The communication proxy service in the cloud will return the selected SSL version, encryption suite, digital certificate, public key and random number of the communication proxy service to the vehicle end;

The car end verifies the digital certificate of the communication proxy service, and when it is judged that the digital certificate of the communication proxy service is legal, the car end continues to communicate with the communication proxy service in the cloud;

The car end sends the digital certificate and public key to the communication agent service, so that the communication agent service can verify the digital certificate of the car end and obtain the public key of the car end;

Determine the symmetric encryption scheme between the vehicle end and the communication proxy service, and generate a random code as a symmetric encryption key;

The vehicle uses the public key of the communication proxy service to encrypt the symmetric encryption key and sends it to the communication proxy service;

The communication agent service uses the private key to decrypt the encrypted information received to obtain the symmetric encryption key, thereby completing the two-way certificate authentication between the vehicle terminal and the cloud communication agent service, so as to establish a secure symmetric encryption channel.

Specifically, in the two-way certificate authentication (SSL) process, the digital certificate, the public key and the private key all play an important role, and they jointly ensure the security of communication. The role played by the digital certificate, public key and private key in the two-way certificate authentication process will be introduced below in conjunction with specific embodiments, which may specifically include the following:

Certificate: A digital certificate is issued by a trusted certificate authority (Certificate Authority, or CA) to verify the identity of an entity (such as a server or client). A certificate includes a public key, identity information of the certificate holder, issuer information, and validity period. In the two-way certificate authentication process, the main function of the certificate is to confirm the identities of the two communicating parties and prevent man-in-the-middle attacks.

Public key: The public key is a key part of an encryption algorithm, and the other part that is paired with it is the private key. In two-way certificate authentication, the main role of the public key is to encrypt data and verify signatures. Both communicating parties can use the public key of the other party to encrypt the data, thus ensuring the confidentiality of the data during transmission. At the same time, the public key can also verify the digital signature generated by the private key to ensure the integrity of the data and the reliability of the source.

Private key: The private key is paired with the public key to decrypt data and generate digital signatures. In two-way certificate authentication, the main function of the private key is to decrypt data and sign. The private key must be kept strictly confidential and can only be used by the key owner. The two communicating parties use their own private keys to decrypt the data encrypted by the other party's public key to achieve secure information transmission. At the same time, the private key can also generate a digital signature to prove the source and integrity of the data.

To sum up, in the two-way certificate authentication (SSL) process, digital certificates are used to verify the identities of both communicating parties to ensure communication security; public keys are used to encrypt data and verify digital signatures to ensure data confidentiality, integrity and source reliability; private keys are used to decrypt data and generate digital signatures to achieve secure information transmission. These three together guarantee the security in the communication process.

The following describes the process of using a communication tool (i.e. MQTTX tool) to realize the SSL two-way certificate authentication between the vehicle end and the cloud communication proxy service in conjunction with the application scenario of the embodiment of the present application. The process may specifically include the following steps:

Step 1: The car end sends information such as the SSL version of the car end to the cloud;

Step 2: The cloud returns information such as the SSL version, random number, and server public key to the car;

Step 3: Check whether the cloud certificate is legal on the vehicle side, and continue legally, otherwise it will give an alarm;

Step 4: After passing the verification on the vehicle side, send your own certificate and public key to the cloud;

Step 5: Verify the car-side certificate, and obtain the car-side public key after the verification is completed;

Step 6: The car end sends the symmetric encryption scheme it can support to the cloud for its choice;

Step 7: The cloud selects an encryption method with a high degree of encryption;

Step 8: Encrypt the selected encryption scheme with the public key of the vehicle and send it to the vehicle;

Step 9: After receiving the encryption method, the car terminal uses the private key to decrypt, generates a random code as a symmetric encryption key, encrypts it with the cloud public key, and sends it to the cloud;

Step 10: The cloud uses the private key to decrypt the encrypted information, obtains the key for symmetric encryption, and performs symmetric encryption to ensure communication security.

In some embodiments, determining a symmetric encryption scheme between the vehicle end and the communication proxy service, and generating a random code as a symmetric encryption key includes:

The car end sends the list of supported symmetric encryption schemes to the communication agent service, so that the communication agent service selects a symmetric encryption scheme from the list of symmetric encryption schemes;

The communication agent service will encrypt the selected symmetric encryption scheme with the public key of the vehicle and send it to the vehicle;

The car end uses the private key to decrypt the encrypted symmetric encryption scheme, and generates a random code as the symmetric encryption key.

Specifically, the vehicle end sends the symmetric encryption scheme that it can support to the cloud server (that is, the MQTT proxy service), for the cloud server to choose. The cloud server selects an encryption method with higher encryption strength from the list of symmetric encryption schemes provided by the vehicle. The cloud server encrypts the selected encryption scheme with the public key of the car and sends it to the car. After receiving the encrypted encryption scheme, the car terminal uses its own private key to decrypt. Then, the car terminal generates a random code as a symmetric encryption key, encrypts it with the public key of the cloud server, and then sends it to the cloud server. The cloud server uses its own private key to decrypt the received encrypted information to obtain the symmetric encryption key. Since then, the two parties have started to communicate using symmetric encrypted channels to ensure data security during communication.

According to the technical solution provided by the embodiment of the present application, the vehicle terminal and the cloud server can perform identity verification and negotiation of secure communication parameters when establishing a connection. On the basis of two-way certificate authentication, a secure symmetric encrypted channel can be established between the communication parties to ensure the security of data transmission between the new energy vehicle and the cloud server. This method can also be applied to scenarios such as the Internet of Vehicles and intelligent transportation systems to improve the security and reliability of data transmission.

The above embodiments have described in detail the process of the SSL two-way certificate authentication between the vehicle end and the MQTT proxy service in the cloud. The method for transforming the Java code and converting the communication content in protobuf format to Hex format in the embodiment of the present application will be described in detail below in conjunction with specific embodiments.

The following is a general description of the conversion process and principle between protobuf format and Hex format. The specific method of converting the communication content of protobuf format into Hex format is summarized as follows:

First, understand the relationship between byte and Hex. In Java, byte occupies 8 bits in binary representation, and each character in Hex (hexadecimal) needs to be represented by 4 binary bits, so each byte can be converted into two corresponding hexadecimal characters, that is, convert the high 4 bits and low 4 bits of byte into corresponding hexadecimal characters H and L, and combine them to get the result of converting byte to hexadecimal string, namely: new String(H)+new String(L).

The assembled protobuf content is serialized to get a byte[] array, define a char[] array whose length is twice as long as the byte[] array, traverse the byte[] array one by one, take out the value of the high four digits of the byte, shift the high four digits to the right by four digits, and perform &0x0f operation (the binary value of 0x0f is 0000 1111, and at the same time, the 1& operation obtains the original number, and the 0& operation obtains 0) to obtain the high four digit value; take out the low four digit value, directly &0x0 The value of the lower four digits is obtained by the f operation; these values are stored in the char[] array in turn, and finally the char[] array is converted into String(), and String() is the content in the Hex format we expect.

In practical applications, before the communication content in protobuf format is converted into communication content in Hex format, the embodiment of the present application can also use JAVA to write the code for simulating vehicle end reporting, which may specifically include the following steps:

Step 1: Determine the proto file. The proto file is used to predefine the data structure of the message. The data packet needs to complete the encoding and decoding of the binary stream according to the structure defined by the proto file, so that the car terminal and the OTA background service can understand the information sent by each other. This file is generally designed and determined by the technical staff of the project team.

Step 2: Compile the proto file into JAVA language classes. First, download the protoc compiler of the specified protobuf version of the operating system—protoc.exe; then, open cmd in the path where the compiler is located, and execute the protoc --java_out=.

Step 3: Assemble the payload content. Use the java class generated in the second step to create a new object and assign values to the properties (the combination of these values is the Payload content to be sent by the car to the MQTT service).

Step 4: Serialize the Payload content, and serialize the newly created object in step 3 into a byte array.

Step 5: Convert the serialized byte array into Hex format.

In some embodiments, the serialization operation is performed on the communication data to obtain a byte array corresponding to the communication data, including:

Obtain the communication data reported by the vehicle end to the cloud during the test of the cloud OTA upgrade system. The communication data is in the protobuf format, and the communication data in the protobuf format is serialized to obtain a byte array.

Specifically, the embodiment of the present application is described by taking the process of simulating the format conversion of the data content reported by the vehicle terminal to the cloud during the test process of the cloud OTA upgrade system as an example. During the testing process of the cloud OTA upgrade system, the car end responds to the software update data pushed by the cloud, and generates data content reported to the cloud, such as the download of the upgrade software package, the result of the download, the start of installation, the result of the installation, etc. Before converting the communication content in the protobuf format into the Hex format, first serialize the communication content in the protobuf format to obtain a byte[] array (that is, a byte array).

In some embodiments, using a predetermined character array to convert the byte array into text in a target format includes:

Define a character array whose length is twice the length of the byte array, traverse the character array to take out the high four-digit value and the low four-digit value of each byte, store the high four-digit value and the low four-digit value in the character array in turn, convert the character array into a string type object, and obtain the communication content in the target format, where the target format is Hex format.

Specifically, after serializing the communication content in the protobuf format to obtain a byte[] array, the embodiment of the present application also defines a char[] array (that is, a character array) whose length is twice the byte[] array, and the char[] array is used to store the converted Hex characters. After that, the byte[] array is traversed one by one, and the high four-digit value and low four-digit value of each byte are taken out.

Further, the obtained values (that is, the high four-digit value and the low four-digit value) are sequentially stored in the char[] array after corresponding operations. Finally, convert the char[] array into a String object (that is, an object of type string). At this point, the String object is the communication content in Hex format that is expected to be obtained in the end.

In practical applications, char[] arrays can be represented as "character arrays". In programming languages, a char represents a character, usually occupying one or more bytes (depending on the encoding). A char array is a data structure composed of a series of characters, which can be used to represent a string or a piece of text information.

In Java, data of type char usually occupies two bytes (16 bits), using the Unicode character set to represent characters. Therefore, the char[] array can store various language characters, including Chinese. A char[] array can be traversed and processed to implement string operations, such as splitting, splicing, searching, and so on. In addition, char[] arrays can also be converted with other types of arrays (such as byte[] arrays) for data processing and transmission.

In some embodiments, the high four-digit value and the low four-digit value of each byte are obtained by traversing the character array, including:

When taking out the high four-digit value, shift each byte to the right by four bits, and perform a bitwise AND operation with the predetermined value to obtain the high four-digit value;

When fetching the lower four-digit value, directly perform a bitwise AND operation on each byte with a predetermined value to obtain the lower four-digit value.

Specifically, when traversing the byte[] array one by one to take out the high four-digit value and the low four-digit value of each byte, for the high four-digit value, by shifting each byte four bits to the right, and then performing a bitwise AND operation with 0x0f (that is, the predetermined value) to obtain the high four-digit value; for the low four-digit value, directly performing a bitwise AND operation with 0x0f (that is, the predetermined value) to obtain the low four-digit value. Among them, 0x0f represents the hexadecimal notation of the decimal value "15", that is, 0x0f represents the value "15".

The technical solution of the embodiment of the present application provides a method for converting communication content in protobuf format into Hex format in Java, so as to transmit and process communication data in different platforms and systems. In scenarios such as the Internet of Vehicles and the Internet of Things, this method can help achieve compatibility and interoperability between multiple data formats.

According to the technical solution provided by the embodiment of the application, the embodiment of the application configures the certificate and public-private key pair obtained on the real vehicle to the MQTTX tool, and uses the MQTTX tool to complete the SSL two-way certificate authentication between the MQTT proxy service from the vehicle end to the cloud. And by transforming the original JAVA code, the original protobuf format communication content is directly reported to the cloud and transformed into converting the protobuf format communication content into Hex format output, and then the converted Hex format text is reported to the cloud through the MQTTX tool to solve the problem that the Payload format does not support protobuf when using the MQTTX tool to simulate communication data transmission.

This application makes reasonable use of the respective advantages of the code and the tool, simply transforms the original code, and has low learning costs, and then uses the MQTTX tool to complete the process of two-way certificate authentication to achieve the purpose of testing this special environment. Low learning cost, easy to understand, easy to use. This application gives full play to the respective advantages of the code and the tool, cleverly uses the tool to complete the certificate authentication, and then uses the code to convert the protobuf format not supported by the tool into the Hex format supported by the tool to complete the test task.

The following are device embodiments of the present application, which can be used to implement the method embodiments of the present application. For details not disclosed in the device embodiments of the present application, please refer to the method embodiments of the present application.

Fig. 3 is a schematic structural diagram of a communication device for a vehicle and a cloud provided by an embodiment of the present application. As shown in Figure 3, the communication device for the vehicle and the cloud includes:

The configuration module 301 is configured to obtain the digital certificate and the public-private key pair of the vehicle, and configure the digital certificate and the public-private key pair of the vehicle to a predetermined analog communication tool;

The authentication module 302 is configured to use an analog communication tool to perform two-way certificate authentication on the communication agent service between the vehicle end and the cloud, so as to establish a symmetric encrypted channel between the vehicle end and the communication agent service;

The serialization module 303 is configured to determine the communication data sent by the vehicle end to the communication proxy service, perform a serialization operation on the communication data, and obtain a byte array corresponding to the communication data;

The conversion module 304 is configured to convert the byte array into a text in a target format by using a predetermined character array, and report the text in the target format to the cloud through a symmetric encrypted channel.

In some embodiments, the configuration module 301 in FIG. 3 acquires the digital certificate and the public-private key pair corresponding to the actual vehicle, and configures the digital certificate and the public-private key pair of the vehicle to the analog communication tool, wherein the analog communication tool adopts the MQTTX tool, and the analog communication tool is used to complete two-way certificate authentication and communication data transmission between the vehicle end and the communication proxy service of the cloud.

In some embodiments, the authentication module 302 in FIG. 3 uses the vehicle terminal to send negotiation communication information to the communication proxy service in the cloud, and the negotiation communication information includes the SSL version and encryption suite supported by the vehicle terminal; the communication proxy service in the cloud returns the selected SSL version, encryption suite, digital certificate, public key and random number of the communication proxy service to the vehicle terminal; the vehicle terminal verifies the digital certificate of the communication proxy service, and when it is judged that the digital certificate of the communication proxy service is legal, the vehicle terminal continues to communicate with the communication proxy service in the cloud; the vehicle terminal sends the digital certificate and public key to the communication proxy Service, so that the communication agent service can verify the digital certificate of the car end, and obtain the public key of the car end; determine the symmetric encryption scheme between the car end and the communication agent service, and generate a random code as a symmetric encryption key;

In some embodiments, the authentication module 302 of FIG. 3 sends the list of supported symmetric encryption schemes to the communication proxy service, so that the communication proxy service selects a symmetric encryption scheme from the list of symmetric encryption schemes; the communication proxy service encrypts the selected symmetric encryption scheme with the public key of the vehicle terminal and sends it to the vehicle terminal; the vehicle terminal uses the private key to decrypt the encrypted symmetric encryption scheme, and generates a random code as the symmetric encryption key.

In some embodiments, the serialization module 303 in FIG. 3 obtains the communication data reported by the vehicle end to the cloud during the test process of the cloud OTA upgrade system. The communication data adopts the protobuf format, and serializes the communication data in the protobuf format to obtain a byte array.

In some embodiments, the conversion module 304 in FIG. 3 defines a character array whose length is twice the length of the byte array, traverses the character array to extract the upper four-digit value and the lower four-digit value of each byte, stores the upper four-digit value and the lower four-digit value in the character array in turn, converts the character array into a character string type object, and obtains the communication content in the target format, wherein the target format is Hex format.

In some embodiments, the conversion module 304 in FIG. 3 shifts each byte to the right by four bits when taking out the upper four-digit value, and performs a bitwise AND operation with the predetermined value to obtain the upper four-digit value;

It should be understood that the sequence numbers of the steps in the above embodiments do not mean the order of execution, and the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation to the implementation process of the embodiment of the present application.

FIG. 4 is a schematic structural diagram of an electronic device 4 provided by an embodiment of the present application. As shown in FIG. 4 , the electronic device 4 of this embodiment includes: a processor 401 , a memory 402 , and a computer program 403 stored in the memory 402 and capable of running on the processor 401 . When the processor 401 executes the computer program 403, the steps in the foregoing method embodiments are implemented. Alternatively, when the processor 401 executes the computer program 403, the functions of the modules/units in the foregoing device embodiments are realized.

Exemplarily, the computer program 403 can be divided into one or more modules/units, and one or more modules/units are stored in the memory 402 and executed by the processor 401 to complete the present application. One or more modules/units may be a series of computer program instruction segments capable of accomplishing specific functions, and the instruction segments are used to describe the execution process of the computer program 403 in the electronic device 4 .

The electronic device 4 can be electronic devices such as desktop computers, notebooks, palmtop computers, and cloud servers. The electronic device 4 may include but not limited to a processor 401 and a memory 402 . Those skilled in the art can understand that FIG. 4 is only an example of the electronic device 4, and does not constitute a limitation to the electronic device 4. It may include more or fewer components than shown in the figure, or combine certain components, or different components. For example, the electronic device may also include input and output devices, network access devices, buses, etc.

The processor 401 may be a central processing unit (Central Processing Unit, CPU), or other general-purpose processors, a digital signal processor (Digital Signal Processor, DSP), an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), a field-programmable gate array (Field-Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, and the like. A general-purpose processor may be a microprocessor, or the processor may be any conventional processor, or the like.

The storage 402 may be an internal storage unit of the electronic device 4 , for example, a hard disk or a memory of the electronic device 4 . The memory 402 can also be an external storage device of the electronic device 4, for example, a plug-in hard disk equipped on the electronic device 4, a smart memory card (Smart Media Card, SMC), a secure digital (SecureDigital, SD) card, a flash memory card (Flash Card) and the like. Further, the memory 402 may also include both an internal storage unit of the electronic device 4 and an external storage device. The memory 402 is used to store computer programs and other programs and data required by the electronic device. The memory 402 can also be used to temporarily store data that has been output or will be output.

Those skilled in the art can clearly understand that for the convenience and conciseness of description, only the division of the above-mentioned functional units and modules is used as an example. In practical applications, the above-mentioned function allocation can be completed by different functional units and modules according to needs, that is, the internal structure of the device is divided into different functional units or modules, so as to complete all or part of the functions described above. Each functional unit and module in the embodiment may be integrated into one processing unit, or each unit may physically exist separately, or two or more units may be integrated into one unit, and the above-mentioned integrated units may be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the protection scope of the present application. For the specific working processes of the units and modules in the above system, reference may be made to the corresponding processes in the aforementioned method embodiments, and details will not be repeated here.

In the above-mentioned embodiments, the descriptions of each embodiment have their own emphases, and for parts that are not detailed or recorded in a certain embodiment, refer to the relevant descriptions of other embodiments.

Those skilled in the art can appreciate that the units and algorithm steps of the examples described in conjunction with the embodiments disclosed herein can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are executed by hardware or software depends on the specific application and design constraints of the technical solution. Skilled artisans may use different methods to implement the described functions for each specific application, but such implementation should not be regarded as exceeding the scope of the present application.

In the embodiments provided in this application, it should be understood that the disclosed apparatus/computer equipment and methods can be implemented in other ways. For example, the device/computer device embodiments described above are only illustrative. For example, the division of modules or units is only a division of logical functions. In actual implementation, there may be other division methods. Multiple units or components may be combined or integrated into another system, or some features may be ignored or not implemented. In another point, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be in electrical, mechanical or other forms.

A unit described as a separate component may or may not be physically separated, and a component displayed as a unit may or may not be a physical unit, that is, it may be located in one place, or may be distributed to multiple network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, each unit may exist separately physically, or two or more units may be integrated into one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units.

If an integrated module/unit is realized in the form of a software function unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application realizes all or part of the processes in the methods of the above embodiments, and can also be completed by instructing related hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, it can implement the steps of the above-mentioned method embodiments. A computer program may include computer program code, which may be in source code form, object code form, executable file, or some intermediate form or the like. The computer readable medium may include: any entity or device capable of carrying computer program code, recording medium, U disk, removable hard disk, magnetic disk, optical disk, computer memory, read-only memory (Read-Only Memory, ROM), random access memory (Random Access Memory, RAM), electrical carrier signal, telecommunication signal, and software distribution medium, etc. It should be noted that the content contained in computer readable media may be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, computer readable media do not include electrical carrier signals and telecommunication signals according to legislation and patent practice.

The above embodiments are only used to illustrate the technical solutions of the present application, but not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that: it can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements to some of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions depart from the spirit and scope of the technical solutions of the various embodiments of the application, and should be included within the scope of protection of the application.

Claims (10)

1. A communication method for a vehicle and a cloud, comprising: Obtain the digital certificate and the public-private key pair of the vehicle, and configure the digital certificate and the public-private key pair of the vehicle on a predetermined analog communication tool; Using the analog communication tool to perform two-way certificate authentication on the communication agent service between the vehicle end and the cloud, so as to establish a symmetric encryption channel between the vehicle end and the communication agent service; Determine the communication data sent by the vehicle to the communication proxy service, perform a serialization operation on the communication data, and obtain a byte array corresponding to the communication data; converting the byte array into text in a target format by using a predetermined character array, and reporting the text in the target format to the cloud through the symmetric encryption channel. 2. The method according to claim 1, wherein said obtaining the digital certificate and the public-private key pair of the vehicle, and configuring the digital certificate and the public-private key pair of the vehicle on a predetermined analog communication tool includes: Obtain the digital certificate and the public-private key pair corresponding to the actual vehicle, and configure the digital certificate and the public-private key pair of the vehicle to the analog communication tool, wherein the analog communication tool adopts the MQTTX tool, and the analog communication tool is used to complete the two-way certificate authentication and communication data transmission between the vehicle end and the communication proxy service of the cloud. 3. The method according to claim 1, wherein said utilizing said communication tool to carry out two-way certificate authentication to the communication proxy service between the vehicle end and the cloud, comprises: Utilize the vehicle end to send negotiation communication information to the communication agent service of the cloud, the negotiation communication information includes the SSL version and encryption suite supported by the vehicle end; The communication proxy service in the cloud returns the selected SSL version, encryption suite, digital certificate, public key and random number of the communication proxy service to the car end; The vehicle terminal verifies the digital certificate of the communication proxy service, and when it is judged that the digital certificate of the communication proxy service is legal, the vehicle terminal continues to communicate with the communication proxy service of the cloud; The vehicle terminal sends the digital certificate and the public key to the communication agency service, so that the communication agency service verifies the digital certificate of the vehicle terminal and obtains the public key of the vehicle terminal; Determine the symmetric encryption scheme between the vehicle end and the communication proxy service, and generate a random code as a symmetric encryption key; The vehicle uses the public key of the communication proxy service to encrypt the symmetric encryption key and sends it to the communication proxy service; The communication agent service uses the private key to decrypt the received encrypted information to obtain the symmetric encryption key, thereby completing the two-way certificate authentication between the vehicle end and the cloud communication agent service, so as to establish a secure symmetric encryption channel. 4. The method according to claim 3, wherein the determining the symmetric encryption scheme between the vehicle end and the communication proxy service, and generating a random code as a symmetric encryption key comprises: The vehicle end sends a list of supportable symmetric encryption schemes to the communication proxy service, so that the communication proxy service selects a symmetric encryption scheme from the list of symmetric encryption schemes; The communication proxy service encrypts the selected symmetric encryption scheme with the public key of the car end and sends it to the car end; The vehicle end uses the private key to decrypt the encrypted symmetric encryption scheme, and generates a random code as the symmetric encryption key. 5. The method according to claim 1, wherein the performing a serialization operation on the communication data to obtain a byte array corresponding to the communication data comprises: Obtain the communication data reported by the vehicle end to the cloud during the test process of the cloud OTA upgrade system. The communication data is in the protobuf format, and the communication data in the protobuf format is serialized to obtain the byte array. 6. The method according to claim 5, wherein said utilizing a predetermined character array to convert said byte array into text in a target format comprises: Define a character array whose length is twice the length of the byte array, traverse the character array to take out the high four-digit value and the low four-digit value of each byte, store the high four-digit value and the low four-digit value in the character array in turn, convert the character array into a character string type object, and obtain the communication content of the target format, wherein the target format is Hex format. 7. The method according to claim 6, wherein said traversing said character array takes out the high four-digit value and the low four-digit value of each byte respectively, comprising: When taking out the high four-digit value, shift each byte to the right by four bits, and perform a bitwise AND operation with a predetermined value to obtain the high four-digit value; When the value of the lower four bits is taken out, a bitwise AND operation is directly performed on each byte with a predetermined value to obtain a value of the lower four bits. 8. A communication device for a vehicle and a cloud, comprising: The configuration module is configured to obtain the digital certificate and the public-private key pair of the vehicle, and configure the digital certificate and the public-private key pair of the vehicle to a predetermined analog communication tool; The authentication module is configured to use the analog communication tool to perform two-way certificate authentication on the communication agent service between the vehicle end and the cloud, so as to establish a symmetric encryption channel between the vehicle end and the communication agent service; The serialization module is configured to determine the communication data sent by the vehicle to the communication agent service, perform a serialization operation on the communication data, and obtain a byte array corresponding to the communication data; The conversion module is configured to convert the byte array into a text in a target format by using a predetermined character array, and report the text in the target format to the cloud through the symmetric encryption channel. 9. An electronic device, comprising a memory, a processor, and a computer program stored in the memory and operable on the processor, when the processor executes the program, the method according to any one of claims 1 to 7 is implemented. 10. A computer-readable storage medium storing a computer program, wherein the computer program implements the method according to any one of claims 1 to 7 when executed by a processor.