A data format conversion method, device, equipment and medium

Abstract

The application relates to the field of embedded communication technology and discloses a data format conversion method, device, equipment and medium, the method comprising the following steps: receiving a data conversion source file and a data conversion header file, the data conversion source file and the data conversion header file being generated through a predefined data model, the data conversion header file being used for declaring the data types of various data variables in the data conversion source file, and the data model being used for recording data variables and data types involved in a protobuf protocol and a DDS protocol; obtaining protobuf protocol source data or DDS protocol source data; and performing conversion processing on the protobuf protocol source data or the DDS protocol source data through the data conversion source file to obtain converted DDS protocol target data or protobuf protocol target data. The application solves the problems that manual configuration of data conversion codes is prone to errors and has a high labor cost.

Description

Technical Field

[0001] This invention relates to the field of embedded communication, and more specifically to a data format conversion method, apparatus, device, and medium. Background Technology

[0002] With the development of intelligent driving technology, vehicles typically contain many different types of domain controllers. Generally, the communication protocols between different domain controllers differ, requiring format conversion for vehicle-wide domain controller data exchange. Typically, the driving domain uses the protobuf protocol for intra-domain communication, while external domains use the DDS protocol. The driving domain refers to the hardware running intelligent driving applications, while the external domain is a general term for non-driving hardware. During vehicle operation, situations may arise where the driving domain controller needs data from the external domain (e.g., gear position status), or vice versa (e.g., the vehicle's infotainment system needs to display parking status). This leads to communication barriers and high manual adaptation costs, necessitating a conversion method. Current technologies often involve manually adding conversion code to the domain controllers. However, with the addition, replacement, and upgrade of domain controllers, manual adaptation is prone to errors and incurs significant labor costs. Summary of the Invention

[0003] In view of this, embodiments of the present invention provide a data format conversion method, apparatus, device, and medium to solve the problems of error-prone manual configuration of data conversion code and high labor costs.

[0004] In a first aspect, embodiments of the present invention provide a data format conversion method, characterized in that it includes: receiving a data conversion source file and a data conversion header file, wherein the data conversion source file and the data conversion header file are generated through a predefined data model, the data conversion header file is used to declare the data types of each data variable in the data conversion source file, and the data model is used to record the data variables and data types involved in the protobuf protocol and the DDS protocol; obtaining protobuf protocol source data or DDS protocol source data; and performing conversion processing on the protobuf protocol source data or DDS protocol source data through the data conversion source file to obtain the converted DDS protocol destination data or protobuf protocol destination data.

[0005] Based on the aforementioned technical means, users only need to describe the data variables and data types involved in communication between the protobuf and DDS protocols in the data model beforehand. Then, a command tool can be invoked to automatically generate a data conversion source file and a data conversion header file from the data model. When converting DDS protocol data to protobuf protocol data, the data conversion header file and data conversion source file are simply placed on the communication end. The communication end can then understand the data types and function meanings of each data variable in the data conversion source file through the data conversion header file, thereby compiling and executing the data conversion source file to convert the acquired protobuf protocol source data or DDS protocol source data into DDS protocol destination data or protobuf protocol destination data. This invention provides a solution for automatically generating data conversion code by simply describing the data, eliminating the need to manually write data conversion code on the communication end, thus solving the problems of error-prone code and high manual costs.

[0006] In one optional implementation, the step of generating a data model includes: obtaining a protobuf file from the driving domain controller; extracting the definition information of data variables from the protobuf file; and generating a data model based on the definition information, wherein each data variable in the data model has a unique name.

[0007] Based on the aforementioned technical methods, developers in the driving domain currently commonly use custom proto files to store data variables and data types from the protobuf protocol. To ensure data model consistency across the two protocols, this embodiment employs compatible proto data types and variables, thereby importing existing protobuf files into the data model and reducing the complexity of manually creating new data variables and data types within the data model. Furthermore, the unique naming of each data variable in the data model ensures that data variables declared in both the DDS and protobuf protocols in the subsequently generated conversion header file have identical names for the same type of data, facilitating accurate data matching and correspondence.

[0008] In an optional implementation, the steps of generating data conversion source files and data conversion header files through a data model include: creating a basic data type mapping table representing the data type correspondence between protobuf protocol data and DDS protocol data; using the basic data type mapping table and the data model to generate converter source files and converter header files for mapping and converting data variables with the same name to each other; using the basic data type mapping table and the data model to generate a communication protocol header file for identifying data types, and generating a communication protocol source file for serialization and deserialization; wherein, the converter source file and the communication protocol source file are data conversion source files, and the converter header file and the communication protocol header file are data conversion header files.

[0009] Based on the aforementioned technical methods, a one-to-one correspondence is established between different data types in the DDS and protobuf protocols through a maintained basic data type mapping table, ensuring that the same data can be matched across different data types in the two protocols. Even when using an imported protobuf file as the data model, the basic data type mapping table can optimize and match the data types in the imported data model. Furthermore, by uniformly defining data names in both the protobuf and DDS protocols through the data model, ambiguous naming conventions can prevent misunderstandings in the generated conversion code. Finally, each data name is used to generate DDS and protobuf protocol data description files according to the data types of both protocols. This allows the header and source files generated by the DDS and protobuf protocol data description files to be parsed and executed by the communication terminals of their respective protocols, enabling serialization or deserialization operations on the acquired data and ensuring the complete execution of both data conversion and data transmission processes.

[0010] In one optional implementation, a communication protocol header file for identifying data types is generated using a basic data type mapping table and a data model, and a communication protocol source file for serialization and deserialization is generated. This includes: importing data variables from the data model into a DDS protocol data description file and a protobuf protocol data description file, respectively, according to the data type mapping table for the two protocols; executing the `idlc` instruction to convert the DDS protocol data description file into a DDS communication protocol source file and a DDS communication protocol header file; and executing the `protoc` instruction to convert the protobuf protocol data description file into a protobuf communication protocol source file and a protobuf communication protocol header file. The DDS communication protocol header file and the protobuf communication protocol header file are communication protocol header files, used by the DDS application and the protobuf application respectively to identify the corresponding data types according to their own communication protocols. The DDS communication protocol source file and the protobuf communication protocol source file are communication protocol source files, used for data serialization and deserialization.

[0011] Based on the above technical means, the embodiments of the present invention use template file technology to write the data types and data variables that need to be declared into the DDS protocol data description file and the protobuf protocol data description file respectively. Then, the corresponding communication protocol source file and communication protocol header file are generated directly by using the idlc and protoc commands in the shell command tool. This reduces the time for users to customize the description file and improves the efficiency and accuracy of creating communication protocol source files and communication protocol header files.

[0012] In one optional implementation, the data variables in the data model are imported into the DDS protocol data description file according to the basic data type mapping table and the data types defined by the DDS protocol. This includes: marking the target data variables in the data model; filling the marked target data variables into the IDL template file; extracting the target data type corresponding to the target data variable from the basic data type mapping table; filling the target data type into the IDL template file and establishing an association relationship with the target data variable; and using the filled IDL template file as the DDS protocol data description file.

[0013] Based on the above technical means, by marking specific members in the data model, it can be clearly identified which data is needed during transmission and which is not. When generating the DDS protocol data description file, only the data type of the target member is generated, avoiding the waste of resources caused by having to convert all data. For resource-sensitive domain controllers, this reduces the resource consumption of the domain controller.

[0014] In one optional implementation, the DDS protocol source data is converted using a data conversion source file to obtain the converted DDS protocol destination data. This includes: acquiring serialized DDS protocol source data; deserializing the DDS protocol source data using a DDS communication protocol source file to obtain a first object; assigning the values ​​in the first object to a second object according to the data type of the protobuf protocol data using a converter source file; and serializing the second object using a protobuf communication protocol source file to obtain the serialized protobuf protocol destination data.

[0015] In one optional implementation, the protobuf protocol source data is converted using a data conversion source file to obtain the converted protobuf protocol destination data. This includes: obtaining serialized protobuf protocol source data; deserializing the protobuf protocol source data using a protobuf communication protocol source file to obtain a third object; assigning the values ​​in the third object to a fourth object according to the data type of the DDS protocol data using a converter source file; and serializing the fourth object using a DDS communication protocol source file to obtain the serialized DDS protocol destination data.

[0016] Secondly, embodiments of the present invention provide a data format conversion apparatus, comprising: a conversion file installation module, used to receive a data conversion source file and a data conversion header file, wherein the data conversion source file and the data conversion header file are generated through a predefined data model, the data conversion header file is used to declare the data types of each data variable in the data conversion source file, and the data model is used to record the data variables involved in the protobuf protocol and the DDS protocol; a source data acquisition module, used to acquire protobuf protocol data or DDS protocol data; and a data conversion module, used to convert the protobuf protocol data or DDS protocol data through the data conversion source file to obtain converted DDS protocol data or protobuf protocol data.

[0017] Thirdly, embodiments of the present invention provide a computer device, including: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to perform the data format conversion method described in the first aspect or any corresponding embodiment thereof.

[0018] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing computer instructions, which are used to cause a computer to perform the data format conversion method described in the first aspect or any corresponding embodiment.

[0019] The beneficial effects of this invention are:

[0020] (1) The solution of automatically generating data conversion code by simply describing the data eliminates the need to manually write data conversion code on the communication end, thus solving the problems of error-prone code and high labor costs.

[0021] (2) By using existing proto data types and variables, existing protobuf files can be imported into the data model, reducing the complexity of manually creating new data variables and data types in the data model. Furthermore, the unique naming of each data variable in the data model ensures that data variables declared in both the DDS and protobuf protocols in the subsequently generated conversion header file have the same name for the same type of data, facilitating accurate data matching and correspondence.

[0022] (3) A one-to-one correspondence is established between different data types in the DDS and protobuf protocols through a maintained basic data type mapping table, ensuring that the same data can be matched across different data types in the two protocols. Even when using an imported protobuf file as the data model, the data types in the imported data model can be optimized and matched through the basic data type mapping table. Furthermore, by uniformly defining the data names in both the protobuf and DDS protocols through the data model, ambiguous naming conventions can prevent ambiguity in the generated conversion code's understanding of the data. Finally, using template file technology, each data name is filled into the corresponding template according to the data types of the two protocols, generating DDS and protobuf protocol data description files. This allows the header and source files generated by the DDS and protobuf protocol data description files to be parsed and executed by the communication terminals of their respective protocols, enabling serialization or deserialization of the acquired data, ensuring the complete execution of both data conversion and data transmission processes.

[0023] (4) By marking specific members in the data model, it can be clearly identified which data is needed during transmission and which is not needed. When generating the DDS protocol data description file, only the data type of the target member is generated, avoiding the waste of resources caused by having to convert all data. For resource-sensitive domain controllers, this reduces the resource consumption of the domain controller. Attached Figure Description

[0024] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0025] Figure 1 This is a flowchart illustrating a data format conversion method according to some embodiments of the present invention;

[0026] Figure 2 This is another schematic flowchart of a data format conversion method according to some embodiments of the present invention;

[0027] Figure 3 This is yet another flowchart illustrating a data format conversion method according to some embodiments of the present invention;

[0028] Figure 4 This is yet another flowchart illustrating a data format conversion method according to some embodiments of the present invention;

[0029] Figure 5 This is a schematic diagram of the structure of a data format conversion device according to some embodiments of the present invention;

[0030] Figure 6 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. Detailed Implementation

[0031] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

[0032] According to an embodiment of the present invention, a data format conversion method embodiment is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0033] This embodiment provides a data format conversion method, which can be used in the aforementioned computer equipment. Figure 1 This is a flowchart of a data format conversion method according to an embodiment of the present invention, the process including the following steps:

[0034] Step S101: Receive the data conversion source file and the data conversion header file. The data conversion source file and the data conversion header file are generated through a predefined data model. The data conversion header file is used to declare the data types of each data variable in the data conversion source file. The data model is used to record the data variables and data types involved in the protobuf protocol and the DDS protocol.

[0035] Specifically, the data format conversion method provided in this embodiment is applied to the current communication terminal, which can be a communication terminal executing the DDS protocol or the protobuf protocol, and communicating with another communication terminal using the DDS protocol or the protobuf protocol. Furthermore, a device can also include two or more communication software applications. For example, in a device, two different applications use different protocols for internal communication, one application using the DDS protocol and the other using the protobuf protocol. Therefore, the current communication terminal is not limited to a hardware device, but can also be one of the communication applications. This embodiment of the invention is merely an example and is not intended to be limiting.

[0036] To address the issues of error-prone manual code conversion and high labor costs, this invention provides a solution for automatically generating data conversion code, which is then executed by the communication end to convert between protobuf protocol data and DDS protocol data.

[0037] Before automatically generating code, this embodiment of the invention first defines a data model using text to record the data variables and data types involved in the protobuf and DDS protocols. Specifically, a data variable refers to the name of the variable that transmits data values; for example, a data variable transmitting name data can be named "name," and a data variable transmitting age data can be named "age." The data type refers to the format type of the data, such as integer (int) or floating-point (float).

[0038] This embodiment parses and identifies a text-based data model to create a data conversion source file and a data conversion header file. The header file declares the data types of various variables in the source file and includes a function library for necessary functions. The data types declared in the header file originate from the user-defined data model and are directly combined according to C++ declaration syntax and the data types recorded in the data model to automatically generate code. The data conversion header file is a .h file in C++, and it is a necessary environment for the data conversion source file (.c file) to run. The source file defines specific conversion functions, such as functions that assign data from a variable in the DDS protocol to another variable in the protobuf protocol and switch data types. In this embodiment, the assignment syntax in C++ can be used as the blanks to fill in the blanks, and the data variables and data types in the data model are used to fill in the blanks, thereby automatically generating the corresponding code instructions. Through the above steps, the code for data conversion can be automatically created and generated, and the data conversion source file can be directly compiled and run by the communication end.

[0039] Step S102: Obtain protobuf protocol source data or DDS protocol source data.

[0040] Step S103: Convert the protobuf protocol source data or DDS protocol source data using the data conversion source file to obtain the converted DDS protocol destination data or protobuf protocol destination data.

[0041] Specifically, the data variables and data types involved in communication between the protobuf and DDS protocols are described in advance in the data model. This allows command-line tools to automatically generate data conversion source files and header files from the data model. When converting between DDS and protobuf protocol data, only the header and source files need to be placed on the communication end. The communication end can then understand the data types and function meanings of each data variable in the source file through the header file, compile and execute the source file, and convert the acquired protobuf or DDS protocol source data into DDS or protobuf protocol destination data. This invention provides a solution for automatically generating data conversion code by simply describing data in text, eliminating the need to manually write data conversion code on the communication end and solving the problems of error-prone code and high manual costs.

[0042] In some alternative implementations, the steps for generating the above data model include:

[0043] Step a1: Obtain the protobuf file from the driving domain controller;

[0044] Step a2: Extract the definition information of data variables from the protobuf file and generate a data model based on the definition information. Each data variable in the data model has a unique name.

[0045] Specifically, the data model provided in this embodiment of the invention can be obtained through user-defined text, that is, users create their own data model containing data variables. However, considering that developers in the driving domain currently commonly use custom proto files to store data variables and data types in the protobuf protocol, in order to ensure the data model is consistent across the two protocols and improve the efficiency of data model generation, this embodiment adopts a method compatible with existing proto data types and data variables, thereby importing existing protobuf files into the data model and reducing the complexity of manually creating data variables and data types in the data model. Furthermore, in real-world scenarios, different data names in DDS protocol data and protobuf protocol data may actually represent the same information. While this can be controlled manually for handwritten conversion code, it requires accurate description for automatically generated code. For example, the X coordinate is represented as XPosition in proto, but as XPos or xPosi in DDS; these uncertain naming conventions bring considerable trouble to the generation of conversion code. To address this issue, the data model provided in this invention provides a unique name for each data variable. For example, a data variable in the DDS protocol is called "name," and the same data variable in protobuf is also called "name." Both protocols use this data model to create corresponding header and source files, ensuring that the data variables declared in both the DDS and protobuf protocols in the subsequently generated conversion header files have the same name for the same type of data, facilitating accurate data matching and correspondence.

[0046] In one optional implementation, the steps of generating data transformation source files and data transformation header files through the data model include:

[0047] Step b1: Create a basic data type mapping table that represents the data type correspondence between protobuf protocol data and DDS protocol data;

[0048] Step b2: Use the basic data type mapping table and data model to generate converter source files and converter header files to map and convert data variables with the same name to each other.

[0049] Step b3: Use the basic data type mapping table and data model to generate a communication protocol header file for identifying data types, and generate a communication protocol source file for serialization and deserialization;

[0050] Among them, the converter source file and the communication protocol source file belong to the data conversion source files, and the converter header file and the communication protocol header file belong to the data conversion header files.

[0051] Specifically, achieving full data conversion between the protobuf and DDS protocols involves three key points: first, data types must match; second, data quantities must correspond; and third, data names must have a mapping relationship. Typically, the data model generated from imported protobuf files only includes protobuf protocol data types. Data types for the DDS protocol still need to be added and defined by the user. Therefore, to ensure accurate data type matching and reduce manual definition, this embodiment of the invention maintains a basic data type mapping table between the protobuf and DDS protocols on the configuration side, as shown in the table below.

[0052] Table 1. Correspondence between protobuf data types and DDS data types

[0053] protobuf data type DDS data type bool bool int32 int8 int32 int16 int32 int32 uint32 uint8 uint32 uint16 uint32 uint32 uint32 enum float float double double string char* repeated uint8 array <uint8> < / uint8>

[0054] For example, in the DDS protocol, the array type of the uint8 element is array. <uint8>In the protobuf protocol, it is repeated uint8.

[0055] Based on this, this embodiment uses data variables in the data model to fill in preset assignment statements, thereby automatically generating assignment instructions between data variables and automatically creating code. Simultaneously, it distinguishes which data variables in the instructions belong to the DDS protocol and which belong to the protobuf protocol based on the data type completion instructions recorded in the basic data type mapping table. Furthermore, all data type declarations are written into the created header file, such as... Figure 2 As shown, the converter source file converter.c and the converter header file converter.h are generated by using the basic data type mapping table and data model to map data variables with the same name to each other and convert their data types.

[0056] In addition, the communication end of DDS or the communication end of the protobuf protocol often involves data compression and transmission during communication. In order to meet this function, this embodiment also creates a communication protocol source file for serialization and deserialization based on the data model and the basic data type mapping table, and at the same time creates a communication protocol header file to provide a runtime environment for the communication protocol source file.

[0057] Creating communication protocol source files and communication protocol header files requires data descriptors. Therefore, in this embodiment, the data names used in protobuf protocol data and DDS protocol data are uniformly defined in the data descriptor file through the data model provided in the aforementioned embodiments. This ensures that the names of data variables with the same information in protobuf protocol data and DDS protocol data are the same, avoiding ambiguity in the generated conversion code due to uncertain naming methods. At the same time, it solves the second key point (the number of data items can correspond) and the third key point (the data names have a mapping relationship).

[0058] Finally, the various data names are used to generate a DDS protocol data description file user.idl and a protobuf protocol data description file user.proto according to the data types of the two protocols. This enables the header and source files generated by the DDS and protobuf protocol data description files to be parsed and executed by the communication terminals of their respective protocols. This allows the communication terminals to use the corresponding data types normally according to their own communication protocols. For example, the DDS communication terminal uses the header file user.h, and the protobuf communication terminal uses the header file user.pb.h. It also enables the communication terminals to perform serialization or deserialization operations on the acquired data, so that the data conversion and data transmission processes can be completed completely.

[0059] In one alternative implementation, step b3 includes:

[0060] Step c1: Import the data variables in the data model into the DDS protocol data description file and the protobuf protocol data description file respectively, according to the basic data type mapping table for the data types defined by the two protocols.

[0061] Step c2: Execute the idlc command to convert the DDS protocol data description file into a DDS communication protocol source file and a DDS communication protocol header file;

[0062] Step c3: Execute the protoc command to convert the protobuf protocol data description file into a protobuf communication protocol source file and a protobuf communication protocol header file;

[0063] Among them, the DDS communication protocol header file and the protobuf communication protocol header file are communication protocol header files, which are used by DDS applications and protobuf applications respectively to identify the corresponding data types according to their own communication protocols. The DDS communication protocol source file and the protobuf communication protocol source file are communication protocol source files, which are used for data serialization and deserialization.

[0064] Specifically, FreeMarker is a template engine, a general-purpose tool for generating text output based on templates, written in pure Java. FreeMarker is commonly used to generate HTML web pages, especially for applications based on the MVC pattern. This embodiment of the invention utilizes this engine to first create .idl and .proto templates in a Java environment. Using an online website implemented in Java, and combining FreeMarker template file technology, the data variables that need to be declared in the data model are written into the two templates respectively, and the data types corresponding to the basic data type mapping table are filled into the two templates, thus obtaining the DDS protocol data description file and the protobuf protocol data description file. Afterwards, Java can call a shell script, which directly generates the communication protocol source file and communication protocol header file in the C++ environment by executing the corresponding command-line tools using the idlc and protoc commands. The pseudo-instructions for generating .idl files are idlc*.idl, and for proto files are protoc*.proto. Figure 2 As shown, the source file for the DDS communication protocol is user.c, the header file for the DDS communication protocol is user.h, the source file for the protobuf communication protocol is user.cc, and the header file for the protobuf communication protocol is user.bp.h.

[0065] This approach enables the automatic creation of description files based on data models and basic data type mapping tables, thereby achieving an automatic generation scheme for communication protocol source files and communication protocol header files. This reduces the time users spend manually customizing description files and significantly improves the efficiency and accuracy of creating communication protocol source files and communication protocol header files.

[0066] In some alternative implementations, step c1 above includes:

[0067] Step d1: Label the target data variables in the data model.

[0068] Step d2: Fill the tagged target data variables into the IDL template file.

[0069] Step d3: Extract the target data type corresponding to the target data variable from the basic data type mapping table.

[0070] Step d4: Fill the target data type into the IDL template file and establish a relationship with the target data variable.

[0071] Step d5: Use the filled IDL template file as the DDS protocol data description file.

[0072] Specifically, in practical applications, asymmetric data conversion may be involved. For example, the internal driving data (protobuf protocol) might require 50 data entries, but the external domain (DDS protocol) only needs 10. In this case, converting all data would be wasteful, which is unacceptable for resource-sensitive domain controllers. To achieve asymmetric data conversion, the key is to maintain the mapping relationship of the converted data. This embodiment of the invention marks specific target data variables in the data model. These marked target data variables are those that need to be transmitted, thus clarifying which data is needed during transmission and which is not. Simultaneously, the target data type corresponding to the target data variable is extracted from the basic data type mapping table. When generating the DDS protocol data description file subsequently, only the data type of the target data variable is generated. To maintain compatibility with existing code, the protobuf data is still generated in its entirety without selection. During data conversion, only the data of the target data variable is converted for the DDS application, thus avoiding the resource waste caused by having to convert all data. For resource-sensitive domain controllers, this reduces resource consumption. For example... Figure 3 As shown, the full set of data variables includes name, age, sex, school, and class. In one embodiment, name, school, and class are tagged, so the generated DDS protocol data description file, converter source file, and converter header file only include the three data variables name, school, and class and their corresponding data types. In another embodiment, name, age, and sex are tagged, so the generated DDS protocol data description file, converter source file, and converter header file only include the three data variables name, age, and sex and their corresponding data types, so that the data conversion on the DDS end is only performed on the tagged data variables.

[0073] In some alternative implementations, step S103 includes:

[0074] Step e1: Obtain the serialized DDS protocol source data;

[0075] Step e2: Deserialize the DDS protocol source data using the DDS communication protocol source file to obtain the first object;

[0076] Step e3: Using the converter source file, the values ​​in the first object are assigned to the second object according to the data type of the protobuf protocol data;

[0077] Step e4: Serialize the second object using the protobuf communication protocol source file to obtain the serialized protobuf protocol destination data.

[0078] Step f1: Obtain the serialized protobuf protocol source data;

[0079] Step f2: Deserialize the protobuf protocol source data using the protobuf communication protocol source file to obtain the third object;

[0080] Step f3: Using the converter source file, assign the values ​​in the third object to the fourth object according to the data type of the DDS protocol data;

[0081] Step f4: Serialize the fourth object using the DDS communication protocol source file to obtain the serialized DDS protocol destination data.

[0082] Specifically, the solution provided in this embodiment of the invention automatically generates protobuf and DDS communication protocol source files for serialization, as well as converter source files for data conversion. Assuming there are two communication ends, a DDS end and a protobuf end, the protobuf communication protocol source file, protobuf communication protocol header file, DDS communication protocol source file, and DDS communication protocol header file are provided to the corresponding communicating parties. The header file enables the communicating parties to use the corresponding data types normally according to their own communication protocols; for example, the DDS end uses user.h, and the protobuf end uses user.pb.h. The source files enable the communicating parties to serialize and deserialize data, thereby compressing and decompressing the data for easier transmission. The converter source file and converter header file for mutual conversion are used by one of the communicating parties. The converter source file converter.c can assign data variables in proto to corresponding data variables in idl, and vice versa. Assuming that `user.proto` has a member named `name`, and `user.idl` has a field with the same name named `name`, you can assign proto data to idl data using an assignment statement like `User.name = UserProto.name()`. Conversely, to assign idl data to proto data, you can use a statement like `UserProto.set_name(User.name)`. Executing `converter.c` iterates through all members of each data type and assigns values, thus completing the data type conversion between proto and idl. For example... Figure 4 As shown, the specific data conversion operations are completed within the mutual conversion code logic after the converter source file is compiled. For example, if the converter source file is on the proto side, the input protobuf data will be processed by the conversion code, which will sequentially assign the member data of protobuf to the data in DDS. Finally, the converted DDS data will be sent out through the DDS interface on the protobuf side. After receiving the data, the DDS side will serialize the data using the communication protocol source file and continue data transmission. After receiving the DDS response data from the DDS side, the proto side will decompose and reassemble the data into protobuf data in the same way through the code logic of the converter source file and return it to the protobuf application. Thus, the data conversion code automatically generated by this embodiment of the invention realizes a communication scheme for seamless protocol switching between protobuf and DDS.

[0083] This embodiment also provides a data format conversion device for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0084] This embodiment provides a data format conversion device, such as... Figure 5 As shown, it includes:

[0085] The conversion file installation module 501 is used to receive the data conversion source file and the data conversion header file. The data conversion source file and the data conversion header file are generated through a predefined data model. The data conversion header file is used to declare the data types of each data variable in the data conversion source file, and the data model is used to record the data variables involved in the protobuf protocol and the DDS protocol.

[0086] The source data acquisition module 502 is used to acquire protobuf protocol data or DDS protocol data.

[0087] The data conversion module 503 is used to convert protobuf protocol data or DDS protocol data through the data conversion source file to obtain converted DDS protocol data or protobuf protocol data.

[0088] In this embodiment, the data format conversion device is presented in the form of a functional unit. Here, a unit refers to an ASIC circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0089] Further functional descriptions of the above modules are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0090] This invention also provides a computer device having the above-described features. Figure 5 The data format conversion device shown.

[0091] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of a computer device provided in an optional embodiment of the present invention, such as... Figure 6 As shown, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). Figure 6 Take a processor 10 as an example.

[0092] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0093] The memory 20 stores instructions executable by at least one processor 10 to cause at least one processor 10 to perform the method shown in the above embodiments.

[0094] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0095] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0096] The computer device also includes a communication interface 30 for communicating with other devices or communication networks.

[0097] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0098] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A data format conversion method, characterized in that, include: The system receives a data conversion source file and a data conversion header file, which are generated through a predefined data model. The data conversion header file is used to declare the data types of each data variable in the data conversion source file, and the data model is used to record the data variables and data types involved in the protobuf protocol and the DDS protocol. The steps of generating the data conversion source file and the data conversion header file using the data model include: creating a basic data type mapping table representing the data type correspondence between protobuf protocol data and DDS protocol data; using the basic data type mapping table and the data model to generate a converter source file and a converter header file for mapping and converting data variables with the same name; using the basic data type mapping table and the data model to generate a communication protocol header file for identifying data types, and generating a communication protocol source file for serialization and deserialization; wherein, the converter source file and the communication protocol source file belong to the data conversion source file, and the converter header file and the communication protocol header file belong to the data conversion header file; Obtain protobuf protocol source data or DDS protocol source data; The protobuf protocol source data or DDS protocol source data is converted using the data conversion source file to obtain the converted DDS protocol destination data or protobuf protocol destination data.

2. The data format conversion method according to claim 1, characterized in that, The steps for generating the data model include: Obtain the protobuf file from the driving domain controller; Extract the definition information of data variables from the protobuf file, and generate the data model based on the definition information. Each data variable in the data model has a unique name.

3. The data format conversion method according to claim 2, characterized in that, The step of generating a communication protocol header file for identifying data types using the basic data type mapping table and the data model, and generating a communication protocol source file for serialization and deserialization, includes: The data variables in the data model are imported into the DDS protocol data description file and the protobuf protocol data description file respectively, according to the basic data type mapping table for the two protocol-defined data types. The idlc command is executed to convert the DDS protocol data description file into a DDS communication protocol source file and a DDS communication protocol header file; The protoc command is executed to convert the protobuf protocol data description file into a protobuf communication protocol source file and a protobuf communication protocol header file; The DDS communication protocol header file and the protobuf communication protocol header file are part of the communication protocol header files, and are used by the DDS application and the protobuf application to identify the corresponding data types according to their own communication protocols, respectively. The DDS communication protocol source file and the protobuf communication protocol source file are part of the communication protocol source files, and are used for data serialization and deserialization.

4. The data format conversion method according to claim 3, characterized in that, Importing the data variables in the data model into the DDS protocol data description file according to the basic data type mapping table, including: Label the target data variables in the data model; Fill the labeled target data variables into the IDL template file; Extract the target data type corresponding to the target data variable from the basic data type mapping table; Fill the target data type into the IDL template file and establish an association relationship with the target data variable; The filled-in IDL template file is used as the DDS protocol data description file.

5. The data format conversion method according to claim 3 or 4, characterized in that, The DDS protocol source data is converted using the aforementioned data conversion source file to obtain the converted DDS protocol destination data, including: Obtain the serialized DDS protocol source data; The first object is obtained by deserializing the DDS protocol source data using the DDS communication protocol source file; The converter source file is used to assign the values ​​in the first object to the second object according to the data type of the protobuf protocol data; The second object is serialized by the protobuf communication protocol source file to obtain the serialized protobuf protocol destination data.

6. The data format conversion method according to claim 3 or 4, characterized in that, The protobuf protocol source data is converted using the data conversion source file to obtain the converted protobuf protocol destination data, including: Obtain the serialized protobuf protocol source data; The protobuf protocol source data is deserialized from the protobuf communication protocol source file to obtain a third object; The converter source file is used to assign the values ​​in the third object to the fourth object according to the data type of the DDS protocol data; The fourth object is serialized by the DDS communication protocol source file to obtain the serialized DDS protocol destination data.

7. A data format conversion device, characterized in that, include: The conversion file installation module is used to receive a data conversion source file and a data conversion header file. The data conversion source file and the data conversion header file are generated through a predefined data model. The data conversion header file is used to declare the data types of each data variable in the data conversion source file. The data model is used to record the data variables involved in the protobuf protocol and the DDS protocol. The steps of generating the data conversion source file and the data conversion header file using the data model include: creating a basic data type mapping table representing the data type correspondence between protobuf protocol data and DDS protocol data; using the basic data type mapping table and the data model to generate a converter source file and a converter header file for mapping and converting data variables with the same name; using the basic data type mapping table and the data model to generate a communication protocol header file for identifying data types, and generating a communication protocol source file for serialization and deserialization; wherein, the converter source file and the communication protocol source file belong to the data conversion source file, and the converter header file and the communication protocol header file belong to the data conversion header file; The source data acquisition module is used to acquire protobuf protocol data or DDS protocol data; The data conversion module is used to convert the protobuf protocol data or DDS protocol data using the data conversion source file to obtain the converted DDS protocol data or protobuf protocol data.

8. A computer device, characterized in that, include: A memory and a processor are communicatively connected, the memory stores computer instructions, and the processor executes the computer instructions to perform the data format conversion method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing a computer to perform the data format conversion method according to any one of claims 1 to 6.

Images