A vehicle end data recording method and device, electronic equipment and computer readable storage medium

Abstract

The application provides a vehicle end data recording method and device, electronic equipment and a computer readable storage medium, wherein the method comprises: performing data type format processing on target data to obtain a prototype file; instantiating and serializing the prototype file to obtain a target string; determining a subject data type file corresponding to the target data according to the prototype file and the target string; constructing a subject file according to the prototype file and the subject data type file; and sending the subject file to a data distribution service bus, so that a data receiver subscribing to the subject file receives the subject file through the data distribution service bus. Through the method, the generality of a data recording program can be improved, and data recording and a business application program can be decoupled.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of vehicle communication, in particular to a vehicle-end data recording method and device, an electronic device and a computer readable storage medium. BACKGROUND

[0002] Data Distribution Service (DDS) is a middleware protocol and application program interface (API) standard, which provides a low-latency, high-reliability, scalable communication architecture standard for distributed systems, and is widely used in industries, medical care, energy and national defense. With the rise of "software-defined cars", it is gradually applied in the automotive industry. Cyclone DDS is an implementation of the DDS standard.

[0003] In the automotive field, for some functionally safe modules such as automatic driving modules and remote control modules, data recording of data communicated between various software modules is performed to facilitate analysis when problems occur. Currently, DDS is used for communication data recording, but the application module itself needs to save the data to be recorded by calling the data recording service interface, which couples the application's business logic with the data recording business. Changes in the data recording interface will result in changes to all application modules.

[0004] Furthermore, different data is transmitted between various software modules, and the data types are different. When using DDS for data transmission, the data type of the transmitted data in the topic needs to be defined accordingly when sending / receiving. Each type of transmitted data needs corresponding data type definition information to be correctly sent / received, which causes the data recording program to be unstable. Whenever new data needs to be recorded, the data recording program needs to be modified to add corresponding data type definition information to receive the new data. SUMMARY

[0005] In view of the above-mentioned shortcomings of the prior art, the present application provides a vehicle-end data recording method to solve the above-mentioned technical problems.

[0006] The vehicle-end data recording method provided by the present application is applied to a data sender and includes the following steps.

[0007] The target data is subjected to data type format processing to obtain a prototype file;

[0008] The prototype file is instantiated and serialized to obtain a target string;

[0009] The topic data type file corresponding to the target data is determined according to the prototype file and the target string;

[0010] constructing a theme file according to the prototype file and the theme data type file;

[0011] sending the theme file to a data distribution service bus, so that a data receiver subscribing to the theme file receives the theme file through the data distribution service bus.

[0012] In an embodiment of the present application, at least one field in the target data is obtained; each of the at least one field is processed according to a data type, a field name and a number tag value to obtain an intermediate file; the intermediate file is converted into a preset language to obtain a first code file; the first code file is compiled to obtain a first compiled file.

[0013] In an embodiment of the present application, the data type in the first compiled file is instantiated and assigned to obtain an instantiated data file; at least one field in the first compiled file is serialized to obtain a serialized interface; the instantiated file is instantiated into binary data through the serialized interface; the binary data is preset encoded to obtain a target string.

[0014] In an embodiment of the present application, the theme data type file includes a second code file and a second compiled file.

[0015] In an embodiment of the present application, an interactive data language file is determined according to the name of the prototype file and the target string; the interactive data language file is converted into a preset language to obtain the second code file; the second code file is compiled to obtain the second compiled file.

[0016] In an embodiment of the present application, the data type of the second compiled file is instantiated and assigned to obtain a data object; the data object is taken as the theme file.

[0017] In a second aspect, an embodiment of the present application provides a vehicle-end data recording method applied to a data receiver and including:

[0018] receiving the theme file through a data distribution service bus;

[0019] performing reverse processing on the theme file to obtain target data;

[0020] recording the target data through a preset configuration file, the preset configuration file including a data recording program.

[0021] In an embodiment of the present application, the theme file includes a target string and a first compiled file.

[0022] In an embodiment of the present application, the target string is pre-decoded to obtain binary data; the binary data is deserialized into target data through a deserialization interface in the first compiled file, and the deserialization interface is obtained according to the first compiled file.

[0023] In a third aspect, the embodiments of the present application provide a vehicle-end data recording device, applied to a data sender, the device comprising:

[0024] a processing unit configured to perform data type format processing on the target data to obtain a prototype file;

[0025] the processing unit is further configured to instantiate and serialize the prototype file to obtain a target string;

[0026] the processing unit is further configured to determine a subject data type file corresponding to the target data according to the prototype file and the target string;

[0027] the processing unit is further configured to construct a subject file according to the prototype file and the subject data type file;

[0028] a transceiving unit configured to send the subject file to a data distribution service bus, so that a data receiver subscribing to the subject file receives the subject file through the data distribution service bus.

[0029] In a fourth aspect, the present application provides an electronic device comprising:

[0030] one or more processors;

[0031] a storage device configured to store one or more programs, when the one or more programs are executed by the one or more processors, the electronic device implements the vehicle-end data recording method described in the first aspect and the second aspect.

[0032] In a fifth aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, when the computer program is executed by a processor of a computer, the computer executes the vehicle-end data recording method described in the first aspect and the second aspect.

[0033] The present application has the beneficial effect of improving the universality of the data recording program, and is beneficial to decoupling the data recording and the business application program.

[0034] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the present application. BRIEF DESCRIPTION OF DRAWINGS

[0035] The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate embodiments consistent with the present application and, together with the description, further serve to explain the principles of the application. It is to be understood that the drawings are designed solely for purposes of illustration to be used in conjunction with the description in

[0036] Figure 1 is a schematic diagram of a DDS topic-based data publishing / subscription system according to an example embodiment of the present application;

[0037] Figure 2 is a flowchart of a vehicle-side data recording method according to an example embodiment of the present application;

[0038] Figure 3 is a flowchart of a vehicle-side data recording method according to another example embodiment of the present application;

[0039] Figure 4 is a block diagram of a vehicle-side data recording apparatus according to an example embodiment of the present application;

[0040] Figure 5 shows a structural schematic diagram of a computer system of an electronic device suitable for implementing embodiments of the present application. DETAILED DESCRIPTION

[0041] The present application will be described with reference to the attached drawings and preferred embodiments, which are given by way of example and are not meant to limit the present application in any way. The present application can be implemented in other ways and applied to other embodiments without departing from the spirit of the present application. The details of the application can be modified in various ways based on different views and applications, and various modifications or changes can be made without departing from the spirit of the present application. It should be understood that the preferred embodiments are only for illustrating the present application, and are not intended to limit the scope of protection of the present application.

[0042] It should be noted that the diagrams provided in the following embodiments only schematically illustrate the basic concepts of the present application, and only show the components related to the present application in the diagrams, rather than being drawn according to the number, shape and size of the components in actual implementation. The shapes, number and proportions of the components in actual implementation can be arbitrarily changed, and the layout pattern of the components can be more complex.

[0043] In the following description, a large number of details are discussed to provide a more thorough explanation of embodiments of the present application, however, it is obvious to those skilled in the art that the embodiments of the present application can be implemented without these specific details, and in other embodiments, well-known structures and devices are shown in the form of block diagrams rather than in the form of details, to avoid making the embodiments of the present application difficult to understand.

[0044] First of all, it should be pointed out that the serialization technology is implemented using protobuf, also known as protocol buffer, which is a data exchange format, independent of language and platform, with good performance, high efficiency, code generation, support for multiple programming languages, etc. It usually uses ".proto" file to describe the definition of a data message, and the message is composed of at least one field, similar to a structure in C language, and each field is defined in the format of "data type field name = unique number tag value;".

[0045] DDS (Data Distribution Service) is a new generation of distributed real-time communication middleware protocol, which adopts a publish / subscribe architecture, emphasizes data-centric, provides rich QoS (Quality-of-Service) policies to ensure real-time, efficient and flexible data distribution, and can meet various distributed real-time communication application requirements. The DDS in the embodiment of the present application can be Cyclone DDS. DDS defines the data transmitted in the distributed network as Topic, and defines the data generation and receiving objects as Publisher and Subscriber respectively, thereby forming a data publish / subscribe transmission model. Each node has no master-slave relationship in logic, and the point-to-point relationship is equal, and the communication mode can be point-to-point, point-to-multiple, multiple-to-multiple, etc. The connection is established under the control of QoS (Quality-of-Service), and the network parameters are automatically discovered and configured.

[0046] Among them, Topic: is an abstract concept of data, identified by TopicName, associated with the corresponding data type (DataType), if all the Topics involved in the vehicle are collected together, a virtual global data space (Global Data Space) is formed, further weakening the concept of node, so the domain participant is not a concept of node.

[0047] DataWriter: similar to a cache, writes the topic data to be published from the application layer to the DataWriter;

[0048] DataReader: also can be understood as a kind of cache, gets the topic data from the subscriber and then transmits it to the application layer;

[0049] Publisher: publishes topic data, at least associated with one DataWriter, and sends data by calling the relevant functions of DataWriter;

[0050] Subscriber: subscribe to topic data, at least associated with 1 DataReader. When data arrives, the application can be busy performing other operations or the application is simply waiting for the message, so there are two cases, synchronous access and asynchronous notification.

[0051] Figure 1 is a schematic diagram of a DDS topic-based data publishing / subscription system according to an example embodiment of the present application. The system includes a data sender and a data receiver, wherein a data recording program can be configured on the data receiver. The data sender acts as a publisher, and the data receiver can act as a subscriber, subscribing to data from the data sender. The data sender can publish a topic through a DDS bus, and the data receiver can receive the topic through the DDS bus, thereby realizing data interaction.

[0052] The embodiments of the present application can be applied in a vehicle, which can support wireless communication methods such as 3G (third generation mobile information technology), 4G (fourth generation mobile information technology), 5G (fifth generation mobile information technology), without limitation.

[0053] Please refer to Figure 2 , Figure 2 is a flowchart of a vehicle-end data recording method according to an example embodiment of the present application. The method can be applied to the implementation environment shown in Figure 1 , and implemented by the data sender in the implementation environment. It should be understood that the method can also be applicable to other example implementation environments, and specifically implemented by devices in other implementation environments. The present embodiment does not limit the implementation environment to which the method is applicable.

[0054] For example, the intelligent terminal to which the vehicle-end data recording method disclosed in the present embodiment is applicable can be installed with an SDK (Software Development Kit, software development kit, a collection of development tools for building application software for a specific software package, software framework, operating system, etc.), and the method disclosed in the present embodiment is specifically implemented as one or more functions provided by the SDK.

[0055] As shown in Figure 2 , in an example embodiment, the vehicle-end data recording method includes at least steps S210 to S250, which are described in detail as follows:

[0056] Step S210, performing data type format processing on target data to obtain a prototype file.

[0057] The prototype file can include a first code file and a first compiled file.

[0058] Specifically, the data sender can obtain at least one field from the target data and process each field according to the format of data type, field name, and numbered label value to obtain an intermediate file. This format can be expressed as "data type field name = numbered label value," where the numbered label value corresponding to each field can be different, i.e., unique. This intermediate file can be a proto file; for example, if the target data is GPS data, the intermediate file can be a GPS.proto file.

[0059] The format of GPS.proto can be:

[0060]

[0061] Further, the intermediate file is converted into a preset language to obtain the first code file. The protoc compiler can be used to generate the corresponding program code file, i.e., the first code file, from the intermediate file, and then compiled to obtain the first compiled file. The preset language can be C++, and the specific command can be `protoc --cpp_out=$DST_DIRXXX.proto`, where "XXX" is the name of the intermediate file, and `$DST_DIR` is the storage path for the compiled C++ code. The first code file can be `XXX.pb.cc`. For example, if the target data is GPS data, the command to convert the `GPS.proto` file to C++ can be `protoc --cpp_out=$DST_DIRGPS.proto`, and the first code file will be `GPS.pb.cc`. `$DST_DIR` is the storage path for the compiled C++ code, and `GPS.pb.cc` and `GPS.pb.h` files will be generated in this path.

[0062] Step S220: Instantiate and serialize the prototype file to obtain the target string.

[0063] Specifically, the data types in the first compiled file are instantiated and assigned values ​​to obtain an instantiated data file. For example, when the target data is GPS data, the instantiated data file can be represented as: GPS gps_data={"23.45833","109.45833"}.

[0064] Furthermore, at least one field in the first compiled file can be serialized to obtain a serialization interface; the instantiated file is instantiated into binary data through the serialization interface; and the binary data is subjected to a preset encoding to obtain the target string. This preset encoding can be Base64 encoding.

[0065] Because transmitting different data types within a DDS topic would require modifications to the data logging program, all data types transmitted across topics must be designed with a unified format. In DDS, data types are generally defined using IDL (Interactive Data Language), whose data structure contains two fields: data type name (data_type_name) and data content (data_content). Both data_type_name and content are of string type. data_content is the target string, and data_type_name is the filename of the prototype file. For example, if the target data is GPS data, then its corresponding data_type_name would be GPS.

[0066] In one embodiment of this application, the Cyclone DDS implementation provides an idlc program, which can compile idl files into C++ code. The specific command is: idlc Data.idl. After successful execution, Data.cpp and Data.h code files will be generated in the current directory.

[0067] Step S230: Determine the subject data type file corresponding to the target data based on the prototype file and the target string.

[0068] The data type file for this topic includes a second code file and a second compiled file.

[0069] Specifically, the data sender can determine the interactive data language (IDL) file based on the name of the prototype file and the target string;

[0070] The contents of the IDL file can be:

[0071]

[0072] Furthermore, the IDL file is converted into a preset language to obtain a second code file, which is then compiled to obtain a second compiled file. This second code file can be a C++ code file, generated using a corresponding compilation tool. In this application, Cyclone DDS uses the idlc tool to convert the DIL file into a second code file. The specific command for converting to C++ code is: `idlc Data.idl`. Successful execution will generate `Data.cpp` and `Data.h` code files in the current directory.

[0073] Step S240: Construct a theme file based on the prototype file and the theme data type file.

[0074] Specifically, the data sender can instantiate and assign values ​​to the data types in the second compiled file (Data.h) to obtain a data object; this data object is then used as a topic file. Data.h includes `data_content` as the target string and `data_type_name` as the filename of the prototype file. For example, if the target data is GPS data, its corresponding `data_type_name` will be named GPS. The topic file can be named `XXX_topic`. When the target data is GPS data, the topic file will be named `GPS_topic`.

[0075] Step S250: Send the topic file to the data distribution service bus so that the data receivers subscribing to the topic file can receive the topic file through the data distribution service bus.

[0076] Specifically, the data sender can send the topic file to the DDS bus, which includes the target string.

[0077] This application decouples data recording from business applications, eliminating the need for business applications to concern themselves with the data recording logic. Modifications to the data recording program's logic have no impact on the business applications. The data recording program is highly versatile; when new data needs to be recorded, there is no need to modify the source code, compile, or republish, thus improving the stability and scalability of the software module.

[0078] Please see Figure 3 , Figure 3 This is a flowchart illustrating a vehicle-side data recording method, as shown in another exemplary embodiment of this application. This method can be applied to... Figure 1 The implementation environment shown is the data receiving environment within that implementation environment. It should be understood that this method can also be applied to other exemplary implementation environments and specifically executed by devices in other implementation environments. This embodiment does not limit the implementation environment to which the method is applicable.

[0079] like Figure 3 As shown, in an exemplary embodiment, the vehicle-side data recording method includes at least steps S310 to S330, which are described in detail below:

[0080] Step S310: Receive the topic file through the data distribution service bus.

[0081] The topic file can be sent to the DDS bus by the data sender, and the data receiver can receive the topic file in the DDS bus. The data receiver may have subscribed to the topic file in advance from the data sender.

[0082] Step S320: Perform reverse processing on the subject file to obtain the target data.

[0083] The topic file includes the target string and the first compiled file.

[0084] The target string is decoded using a preset method to obtain binary data;

[0085] Specifically, the data receiver can deserialize the binary number into target data through the deserialization interface in the first compiled file. The deserialization interface is obtained based on the first compiled file, for example, it can be obtained by deserializing at least one field in the first compiled file.

[0086] Step S330: Record the target data using a preset configuration file, which includes a data recording program.

[0087] DDS's inherent features ensure that when a topic has multiple subscribers, each subscriber receives the same data. Therefore, the data logging program only needs to subscribe to the corresponding topic to achieve the data logging function, without requiring special modifications to the application. Furthermore, since the data format transmitted by all topics is standardized, the data logging program can implement data logging through a unified processing logic and a preset configuration file. When adding corresponding data records, only the preset configuration file needs to be modified, without having to modify the program itself again.

[0088] The default configuration file can be defined using JSON, and its content format is as follows:

[0089] {

[0090] "topic":["topic_A","topic_B",...]

[0091] }

[0092] To add a new record to a specific topic, simply add the topic name to this file.

[0093] After receiving data, the data logging program records it to a text file in the format of "receive time, data type name (data_type_name), data content (data_content)", with each data entry recorded on a separate line. When data playback is needed later, the corresponding proto file can be located by reading the data type name, and the data content can then be deserialized into the actual business data.

[0094] The data logging program reads the topic names configured in the configuration file and subscribes to the data transmitted in each topic in a loop. To add or stop recording data in a topic, simply add or delete the corresponding topic name in this file. In this example, when the target data is GPS data, the configuration file content is as follows:

[0095] {

[0096] "topic":["gps_topic"]

[0097] }

[0098] After subscribing to the `gps_topic`, the data logging program receives the data sent by the data sender. The program records the received data to a text file with the format "receive time, data type name (data_type_name), data content (data_content)", one line per data item. For subsequent data playback, the corresponding proto file can be located by reading the data type name, and the data content can be deserialized into actual business data. In this example, the content format is:

[0099] 2022-01-2710:01:01.359,GPS,XXXXXX

[0100] Here, GPS represents the value of the received data_type_name, and XXXXXX represents the value of the received data_content. When data playback is needed later, the contents of this file are read, and the corresponding proto file is found through GPS to achieve data deserialization, thereby obtaining the real business data.

[0101] This method decouples data recording from business applications, so that business applications do not need to care about the logic related to data recording, and modifications to the logic related to data recording have no impact on business applications.

[0102] Figure 4 This is a block diagram illustrating a vehicle-mounted data recording device according to an exemplary embodiment of this application. The device can be applied to… Figure 1 The implementation environment shown is specifically configured in the data sender and data receiver. This device can also be applied to other exemplary implementation environments and specifically configured in other devices. This embodiment does not limit the implementation environment to which the device is applicable.

[0103] like Figure 4 As shown, when this exemplary vehicle-mounted data recording device is applied to a data sender, it includes:

[0104] Processing unit 410 is used to process the target data in terms of data type format to obtain a prototype file;

[0105] The processing unit 410 is also used to instantiate and serialize the prototype file to obtain the target string;

[0106] Processing unit 410 is also used to determine the subject data type file corresponding to the target data based on the prototype file and the target string;

[0107] Processing unit 410 is also used to construct a theme file based on the prototype file and the theme data type file;

[0108] The transceiver unit 420 is used to send a topic file to the data distribution service bus so that the data receivers subscribing to the topic file can receive the topic file through the data distribution service bus.

[0109] In one embodiment of this application, the acquisition unit 430 is used to acquire at least one field in the target data; the processing unit 410 is further used to process each field in the at least one field according to the format of data type, field name and number label value to obtain an intermediate file; convert the intermediate file into a preset language to obtain a first code file; and compile the first code file to obtain a first compiled file.

[0110] In one embodiment of this application, the processing unit 410 is further configured to instantiate and assign values ​​to the data types in the first compiled file to obtain an instantiated data file; serialize at least one field in the first compiled file to obtain a serialization interface; instantiate the instantiated file into binary data through the serialization interface; and perform preset encoding on the binary data to obtain a target string.

[0111] In one embodiment of this application, the subject data type file includes a second code file and a second compiled file;

[0112] In one embodiment of this application, the processing unit 410 is further configured to determine an interactive data language file based on the name of the prototype file and the target string; convert the interactive data language file into a preset language to obtain a second code file; and compile the second code file to obtain a second compiled file.

[0113] In one embodiment of this application, the data type of the second compiled file is instantiated and assigned a value to obtain a data object; the data object is then used as the subject file.

[0114] When this exemplary vehicle-mounted data recording device is used on a data receiver, it includes:

[0115] Transceiver unit 420 is used to receive topic files via the data distribution service bus;

[0116] Processing unit 410 is used to perform reverse processing on the subject file to obtain target data;

[0117] The processing unit 410 is also used to record target data through a preset configuration file, which includes a data recording program.

[0118] In one embodiment of this application, the subject file includes a target string and a first compiled file;

[0119] In one embodiment of this application, the processing unit 410 is further configured to perform preset decoding on the target string to obtain binary data; and to deserialize the binary data into target data through the deserialization interface in the first compilation file, wherein the deserialization interface is obtained based on the first compilation file.

[0120] It should be noted that the vehicle-side data recording device and the vehicle-side data recording method provided in the above embodiments belong to the same concept. The specific operation methods of each module and unit have been described in detail in the method embodiments and will not be repeated here. In practical applications, the vehicle-side data recording device provided in the above embodiments can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. This is not a limitation here.

[0121] Embodiments of this application also provide an electronic device, including: one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, cause the electronic device to implement the vehicle-side data recording method provided in the above embodiments.

[0122] Figure 5 A schematic diagram of a computer system suitable for implementing the embodiments of this application is shown. It should be noted that... Figure 5 The computer system 500 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0123] like Figure 5As shown, the computer system 500 includes a Central Processing Unit (CPU) 501, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 502 or programs loaded from storage portion 508 into Random Access Memory (RAM) 503, such as performing the methods described in the above embodiments. The RAM 503 also stores various programs and data required for system operation. The CPU 501, ROM 502, and RAM 503 are interconnected via a bus 504. An Input / Output (I / O) interface 505 is also connected to the bus 504.

[0124] The following components are connected to I / O interface 505: an input section 506 including a keyboard, mouse, etc.; an output section 507 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to I / O interface 505 as needed. Removable media 511, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 510 as needed so that computer programs read from them can be installed into storage section 508 as needed.

[0125] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 509, and / or installed from removable medium 511. When the computer program is executed by central processing unit (CPU) 501, it performs various functions defined in the system of this application.

[0126] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0127] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0128] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0129] Another aspect of this application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a computer's processor, causes the computer to perform the vehicle-end data recording method as described above. This computer-readable storage medium may be included in the electronic device described in the above embodiments, or it may exist independently and not assembled into the electronic device.

[0130] Another aspect of this application provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the vehicle-side data recording method provided in the various embodiments described above.

[0131] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A method for recording vehicle-side data, characterized in that, Applied to the data sender, the method includes: The target data is processed to obtain a prototype file; The prototype file is instantiated and serialized to obtain the target string; The subject data type file corresponding to the target data is determined based on the prototype file and the target string; the subject data type file includes a second code file and a second compiled file; specifically, it includes: determining an interactive data language file based on the name of the prototype file and the target string; converting the interactive data language file into a preset language to obtain the second code file; and compiling the second code file to obtain the second compiled file; Constructing a theme file based on the prototype file and the theme data type file; specifically including: instantiating the data type of the second compiled file and assigning values ​​to obtain a data object; and using the data object as the theme file; The topic file is sent to the data distribution service bus so that data recipients subscribing to the topic file can receive the topic file through the data distribution service bus.

2. The method according to claim 1, characterized in that, The prototype file includes a first code file and a first compiled file; The process of processing the target data to obtain a prototype file includes: Obtain at least one field from the target data; Each of the at least one field is processed according to the format of data type, field name, and number label value to obtain an intermediate file; The intermediate file is converted into a preset language to obtain the first code file; The first code file is compiled to obtain the first compiled file.

3. The method according to claim 2, characterized in that, The instantiation and serialization of the prototype file to obtain the target string includes: Instantiate the data types in the first compiled file and assign values ​​to them to obtain an instantiated data file; Serialize at least one field in the first compiled file to obtain a serialization interface; The instantiated file is instantiated into binary data through the serialization interface; The binary data is pre-encoded to obtain the target string.

4. A method for recording vehicle-side data, characterized in that, Applied to the data receiver, the method includes: Receive topic files via the data distribution service bus; The topic file is reverse-processed to obtain target data; the topic file includes a target string and a first compiled file; specifically, it includes: performing a preset decoding on the target string to obtain binary data; and deserializing the binary data into the target data through a deserialization interface in the first compiled file, wherein the deserialization interface is obtained based on the first compiled file; The target data is recorded using a preset configuration file, which includes a data recording program.

5. A vehicle-end data recording device, characterized in that, Applied to the data sender, the device includes: The processing unit is used to process the target data in terms of data type and format to obtain a prototype file. The processing unit is also used to instantiate and serialize the prototype file to obtain the target string; The processing unit is further configured to determine the theme data type file corresponding to the target data based on the prototype file and the target string; the theme data type file includes a second code file and a second compiled file; specifically, it includes: determining an interactive data language file based on the name of the prototype file and the target string; converting the interactive data language file into a preset language to obtain the second code file; and compiling the second code file to obtain the second compiled file; The processing unit is further configured to construct a theme file based on the prototype file and the theme data type file; specifically, this includes: instantiating the data type of the second compiled file and assigning a value to obtain a data object; and using the data object as the theme file. The transceiver unit is used to send the topic file to the data distribution service bus so that the data receivers subscribing to the topic file can receive the topic file through the data distribution service bus.

6. An electronic device, characterized in that, The electronic device includes: One or more processors; A storage device for storing one or more programs, which, when executed by the one or more processors, cause the electronic device to implement the vehicle-end data recording method as described in any one of claims 1 to 4.

7. A computer-readable storage medium, characterized in that, It stores a computer program, which, when executed by the computer's processor, causes the computer to perform the vehicle-end data recording method according to any one of claims 1 to 4.

Images