Cross-process debugging method and device and electronic equipment

Abstract

The invention relates to a cross-process debugging method and device and electronic equipment, a first process of a first controller can send a registry corresponding to a message format of a communication message to be transmitted to a second process in a second controller by responding to a connection request initiated by the second process in the second controller; obtaining content information in a field in the communication message to be transmitted, and generating the communication message to be transmitted according to the obtained content information; and transmitting the communication message to be transmitted to a second process in the second controller, so that the second process of the second controller performs data analysis on the communication message to be transmitted according to the registry. According to the method, the flexibility of cross-process data analysis is improved.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a cross-process debugging method, device and electronic equipment. Background Art

[0002] Cross-process debugging is a common debugging method. In multi-process applications written in C / C++, traditional debugging methods rely on manually defining the structure parsing logic in communication messages, which results in a strong coupling relationship between the debugging process and the debugged process, making it difficult to adapt to frequent changes in structure definitions. Serialization tools such as Protocol Buffers increase flexibility at the expense of performance, and decouple the debugging process from the debugged process by serializing and deserializing communication messages. However, in areas with extremely high performance requirements such as autonomous driving, there is an urgent need for a cross-process data parsing method that can maintain high efficiency and flexibly respond to data structure changes in order to cope with increasingly complex and dynamically changing application scenarios. Summary of the invention

[0003] One of the purposes of the present invention is to provide a cross-process debugging method, device and electronic device to solve the problem of poor flexibility of cross-process data parsing in the prior art.

[0004] In order to achieve the above object, the technical solution adopted by the present invention is as follows:

[0005] In a first aspect, the present invention provides a cross-process data parsing method, which is applied to a first controller, in which a first process is deployed, and the first process is a process to be debugged; the method comprises:

[0006] In response to a connection request initiated by a second process in a second controller, a registration table corresponding to a message format of a communication message to be transmitted is sent to a second process in the second controller; wherein the second process is a process for debugging other processes, and the connection request represents that the second process requests to establish a connection with the first process; and the registration table is used to indicate field format information of a field in the communication message to be transmitted;

[0007] Acquire content information in a field in the communication message to be transmitted, and generate the communication message to be transmitted according to the acquired content information;

[0008] The communication message to be transmitted is transmitted to the second process in the second controller; wherein the communication message to be transmitted is used to perform data parsing based on the registration table acquired by the second process.

[0009] In a second aspect, the present invention provides a cross-process debugging method, which is applied to a second controller, in which a second process is deployed, and the second process is a process for debugging other processes. The method includes:

[0010] Sending a connection request to a first process in a first controller, and receiving a registration table returned by the first process in the first controller; wherein the first process is a process to be debugged, and the connection request represents that the second process requests to establish a connection with the first process; the registration table is used to indicate field format information of fields in a communication message to be transmitted;

[0011] receiving the communication message to be transmitted sent by the first process in the first controller; wherein the communication message to be transmitted is generated based on content information;

[0012] The communication message to be transmitted is parsed according to the registration table.

[0013] In a third aspect, the present invention provides a cross-process debugging method, which is applied to a third controller, wherein a first process and a second process are deployed in the controller, wherein the first process is a process to be debugged, and the second process is a process for debugging other processes; the method comprises:

[0014] The second process sends a connection request to the first process; wherein the connection request indicates that the second process requests to establish a connection with the first process;

[0015] The first process sends a registration table corresponding to a message format of a communication message to be transmitted to the second process; wherein the communication message to be transmitted is a message that the first process needs to transmit, and the registration table is used to indicate field format information of a field in the communication message to be transmitted;

[0016] The first process obtains content information in a field in the communication message to be transmitted, and generates the communication message to be transmitted according to the obtained content information;

[0017] The first process sends the communication message to be transmitted to the second process;

[0018] The second process performs data parsing on the communication message to be transmitted according to the registration table.

[0019] In a fourth aspect, the present invention provides a cross-process data parsing device, which is applied to a first controller, in which a first process is deployed, and the first process is a process to be debugged; the device comprises:

[0020] A transceiver module, configured to respond to a connection request initiated by a second process in a second controller, and to send a registration table corresponding to a message format of a communication message to be transmitted to a second process in the second controller; wherein the second process is a process for debugging other processes, and the connection request indicates that the second process requests to establish a connection with the first process; and the registration table is used to indicate field format information of fields in the communication message to be transmitted;

[0021] A processing module, used for acquiring content information in a field in the communication message to be transmitted, and generating the communication message to be transmitted according to the acquired content information;

[0022] The transceiver module is used to transmit the communication message to be transmitted to the second process in the second controller; wherein the communication message to be transmitted is used to perform data analysis based on the registration table obtained by the second process.

[0023] In a fifth aspect, the present invention provides a cross-process debugging device, which is applied to a second controller, in which a second process is deployed, and the second process is a process for debugging other processes, and the device includes:

[0024] A transceiver module, used to send a connection request to a first process in a first controller, and receive a registration table returned by the first process in the first controller; wherein the first process is a process to be debugged, and the connection request represents that the second process requests to establish a connection with the first process; the registration table is used to indicate field format information of a field in a communication message to be transmitted; receive the communication message to be transmitted sent by the first process in the first controller; wherein the communication message to be transmitted is generated based on content information;

[0025] A processing module is used to perform data analysis on the communication message to be transmitted according to the registration table.

[0026] In a sixth aspect, the present invention provides a cross-process debugging device, which is applied to a third controller, wherein a first process and a second process are deployed in the controller, wherein the first process is a process to be debugged, and the second process is a process for debugging other processes; the device comprises:

[0027] A transceiver module, configured to send a connection request to the first process based on the second process; wherein the connection request indicates that the second process requests to establish a connection with the first process; and to send a registration table corresponding to a message format of a communication message to be transmitted to the second process based on the first process; wherein the communication message to be transmitted is a message that the first process needs to transmit, and the registration table is used to indicate field format information of a field in the communication message to be transmitted;

[0028] A processing module, configured to obtain content information in a field in the communication message to be transmitted based on the first process, and generate the communication message to be transmitted according to the obtained content information;

[0029] a transceiver module, configured to send the communication message to be transmitted to the second process based on the first process;

[0030] A processing module is used to perform data analysis on the communication message to be transmitted according to the registration table based on the second process.

[0031] In a seventh aspect, the present invention provides a first controller, the device comprising: a memory, a processor;

[0032] The memory is used to store computer programs; the processor is used to implement the method in the first aspect and any possible design of the first aspect according to the computer program stored in the memory.

[0033] In an eighth aspect, the present invention provides a second controller, the device comprising: a memory, a processor;

[0034] The memory is used to store a computer program; the processor is used to implement the method in the second aspect and any possible design of the second aspect according to the computer program stored in the memory.

[0035] In a ninth aspect, the present invention provides a third controller, the device comprising: a memory, a processor;

[0036] The memory is used to store computer programs; the processor is used to implement the method in the third aspect and any possible design of the third aspect according to the computer program stored in the memory.

[0037] In a tenth aspect, the present invention provides a computer-readable storage medium, in which a computer program is stored. When at least one processor of an electronic device executes the computer program, the computer program is used to implement the first aspect and the method in any possible design of the first aspect when executed by the processor in a first controller; or, the computer program is used to implement the second aspect and the method in any possible design of the second aspect when executed by the processor in a second controller; or, the computer program is used to implement the third aspect and the method in any possible design of the third aspect when executed by the processor in a third controller.

[0038] In an eleventh aspect, the present invention provides a computer program product, comprising a computer program. When at least one processor of an electronic device executes the computer program, the computer program is used to implement the first aspect and the method in any possible design of the first aspect when executed by the processor in a first controller; or, the computer program is used to implement the second aspect and the method in any possible design of the second aspect when executed by the processor in a second controller; or, the computer program is used to implement the third aspect and the method in any possible design of the third aspect when executed by the processor in a third controller.

[0039] Beneficial effects of the present invention:

[0040] The cross-process debugging method can pre-generate a field description object of a communication message in the first process, and further generate a global structure registry. The second process can synchronize the field description object of the communication message by obtaining the registry of the first process. In the actual debugging process, when the first process generates a communication message to be transmitted and transmits the communication message to be transmitted to the second process, the second process searches for the field description object of the communication message from the registry, and dynamically parses the string message of the communication message according to the field description object of the communication message. The use of the registry not only avoids the complex serialization and deserialization process of the message during the communication transmission process, greatly improves the CPU overhead of the communication, and improves the communication efficiency; moreover, the synchronization of the registry completely decouples the first process and the second process, and the interface change of the second process will not affect the parsing of the communication message by the first process, thereby improving the flexibility of data transmission between the first process and the second process. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 A signaling interaction diagram of a cross-process data parsing method provided by an embodiment of the present invention;

[0042] Figure 2 A schematic diagram of a coding format provided by an embodiment of the present invention;

[0043] Figure 3 A flowchart of a cross-process data parsing method provided by an embodiment of the present invention;

[0044] Figure 4 A flowchart of a cross-process data parsing method provided by an embodiment of the present invention;

[0045] Figure 5 An interaction diagram between a debugged program and a debugging program provided by an embodiment of the present invention;

[0046] Figure 6A schematic diagram of the structure of a cross-process data parsing device provided by an embodiment of the present invention;

[0047] Figure 7 A schematic diagram of the structure of a cross-process data parsing device provided by an embodiment of the present invention;

[0048] Figure 8 A schematic diagram of the structure of a cross-process data parsing device provided by an embodiment of the present invention;

[0049] Fig. 9 A schematic diagram of the hardware structure of a first controller provided in one embodiment of the present invention;

[0050] Fig.10 A schematic diagram of the hardware structure of a second controller provided in one embodiment of the present invention;

[0051] Fig.11 A schematic diagram of the hardware structure of a third controller provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0052] The following will describe the embodiments of the present invention 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 contents disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways 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, not for limiting the scope of protection of the present invention.

[0053] Cross-process debugging is a common debugging method. The debugged process sends information containing internal structure data to the external debugging process through communication. After receiving the information, the external debugging process parses the corresponding actual field information and applies the actual field information to subsequent debugging analysis. When debugging based on c / c++ structures, it is usually chosen to load the same c / c++ structure information in the debugger and manually define the corresponding parsing method. This method creates a strong coupling relationship between the debugger and the debugged program. If the structure information defined by the application of the debugged process is added, modified, or deleted, the debugging process will not be able to parse normally. Usually, the debugging process needs to be manually re-adapted and debugged before it can be used, which is difficult to adapt to frequent changes in structure definitions.

[0054] In order to solve the strong coupling relationship between the debugging process and the debugged process, serialization tools such as ProtocolBuffers are currently used in cross-process debugging. Protobuf is an efficient and flexible serialization data format developed by Google for the transmission of structured data. Its advantages include cross-language support, flexibility and scalability, and efficient serialization and deserialization. Protobuf supports multiple programming languages ​​such as Java, Python, and C++. Protobuf allows the definition of optional fields and extension fields, and can maintain backward compatibility even if the message format changes. Compared with traditional XML and JSON formats, protobuf serialization and deserialization are faster and occupy less bandwidth. In cross-process debugging, protobuf makes the communication between the debugger and the debugged program more standardized and convenient by defining a unified message format. When the debugged program sends internal structure data, these data will be serialized into protobuf messages. After receiving these messages, the debugger can obtain the actual field information through the deserialization method provided by protobuf itself for debugging analysis. Due to the extensibility of protobuf, even if the structure information of the debugged program changes, the debugger can be updated through the corresponding *.proto file, avoiding strong dependencies and thus improving the flexibility and adaptability of the system.

[0055] However, although protobuf has the advantage of flexibility, it has additional complex serialization and deserialization operations, which sacrifices certain performance and has a large CPU overhead. In the field of autonomous driving and other fields with high real-time requirements, not only is the amount of communication data large and the communication frequency high, but the embedded controller on which it runs usually has weak CPU performance and is difficult to bear the additional load brought by protobuf. Therefore, in order to solve the above technical problems, an embodiment of the present invention proposes a cross-process debugging method based on c / c++ language.

[0056] The cross-process debugging method can pre-register the necessary information related to the structure and its fields in the debugged process, and further generate a global structure registry. The debugging process can synchronize the necessary information related to the structure and its fields by obtaining the registry of the debugged process. In the actual debugging process, when the debugged process generates a communication message to be transmitted, and transmits the communication message to be transmitted to the debugging process, the debugging process searches for the corresponding message description information and field description information from the global structure registry by the structure name or field name, and dynamically parses the structure or field information by the type, offset, size, number and other information in the field description information. In addition, since the data transmission between the debugging process and the debugged process needs to be implemented in binary, the prior art needs to parse the received binary information by a predefined serialization method or field parsing method. The present invention globally defines an export and import method in yaml format. The debugged process can export information as string information in yaml format, and the debugging process can parse it after importing the string in yaml format.

[0057] The implementation of this cross-process debugging method, on the one hand, avoids the complex serialization and deserialization process of messages during communication, greatly improves the CPU overhead of communication, and reduces communication delays. On the other hand, it completely decouples the debugger and the debugged program. The debugger is not affected by any interface changes of the debugged program, and no longer needs to manually adapt to the interface changes of the debugged program, which greatly improves the development and debugging efficiency of intelligent driving or other software systems. The advantages of this cross-process debugging method at the communication level mean that it can also be directly applied to performance-sensitive software systems as a key link in efficient communication.

[0058] Figure 1 FIG. 1 shows a signaling interaction diagram of a cross-process data parsing method provided by an embodiment of the present invention. Figure 1 As shown, the signaling interaction diagram realizes the interaction between the first controller and the second controller. The first controller is deployed with a first process, which is a process to be debugged; the second controller is deployed with a second process, which is a process used to debug other processes. With the first controller and the second controller as the execution subjects, the method of this embodiment may include the following steps:

[0059] S110: The second controller sends a connection request to the first process in the first controller, wherein the connection request indicates that the second process requests to establish a connection with the first process.

[0060] In this embodiment, when the second process in the second controller is started, the second process in the second controller can first initialize the network component and prepare to establish a connection with the server. At the same time, the second process in the second controller can create a TCP or UDP client and configure the IP address and port.

[0061] The second process in the second controller may send a connection request to the first process in the first controller when determining that the first process in the first controller needs to be debugged. The connection request is used to request to establish a connection with the first process. Optionally, the information may include a registration table sent by the first process of the first controller. Optionally, the information may also include a communication message sent by the first process of the first controller.

[0062] S120: In response to a connection request initiated by a second process in a second controller, the first controller sends a registration table corresponding to a message format of a communication message to be transmitted to a second process in the second controller, wherein the registration table is used to indicate field format information of a field in the communication message to be transmitted.

[0063] In this embodiment, when the first process of the first controller is started, the first process of the first controller can create a TCP or UDP server. The first process of the first controller can also bind according to the IP address and port of the second process of the second controller corresponding to the debugging process, and start the monitoring of the second process of the second controller. The monitoring is mainly used to monitor the connection request of the second process of the second controller.

[0064] The first process of the first controller can also use KMessageRegistry to complete the registration of interface information when it starts, registering all message types and field information that need to be debugged in the registry. And call KMessageRegistry::ExportToYAML function to export the information of the registry into a string in YAML format for subsequent transmission. The specific generation process of the registry can be as follows Figure 3 shown.

[0065] Optionally, the first process of the first controller may also send the registration table to the second process of the second controller when receiving a connection request initiated by the second process in the second controller.

[0066] S130: The second controller receives a registration table returned by the first process in the first controller. The registration table is used to indicate field format information of fields in the communication message to be transmitted.

[0067] In this embodiment, the registry returned by the first process of the first controller accepted by the second controller may be a string in YAML format. The registry may include field format information of the fields of the communication message of the first process of the first controller. After the second process of the second controller receives the YAML format string returned by the first process of the first controller, the KMessageRegistry::ImportFromYAML function is used to parse the string and update the local interface registration information, thereby ensuring that the second process of the second controller can maintain consistent interface information with the first process of the first controller, and ensuring the accuracy and consistency of the debugging process.

[0068] S140. The first controller obtains content information in a field in a communication message to be transmitted, and generates a communication message to be transmitted according to the obtained content information.

[0069] In this embodiment, the first process of the first controller can obtain content information required by the second process of the second controller during debugging during operation, and generate a communication message to be transmitted according to the obtained content information.

[0070] In one example, the first process of the first controller may obtain content information in a field in a communication message to be transmitted in response to a periodic event. Alternatively, the first process of the first controller may obtain content information in a field in a communication message to be transmitted in response to a specific event.

[0071] S150: The first controller transmits the communication message to be transmitted to the second process in the second controller, wherein the communication message to be transmitted is used to perform data analysis based on the registration table acquired by the second process.

[0072] In this embodiment, the first process of the first controller can also establish a data publishing terminal after establishing a connection with the second process of the second controller. The first process of the first controller can publish the communication message to be transmitted through the publishing terminal. The communication message can be a string in yaml format.

[0073] In one example, the first process of the first controller is further used to encode the communication message to be transmitted to obtain an encoded communication message. The encoded communication message includes the communication message to be transmitted and attribute information of the communication message to be transmitted. The attribute information includes the length of the communication message and the message type of the communication message. Optionally, an encoding format can be as follows: Figure 2As shown. The encoding format can be four parts. Among them, the first part can be one byte. The byte is used to indicate the length of the message name. Optionally, the length can be N. The length of the message name can be recorded as N-topic. The second part can be a string of length N. The string is the message name. Optionally, the message name is topic. Optionally, the first process of the first controller can include multiple communication messages. Each message name corresponds to a communication message. Different types of communication messages have different fields. And different types of communication messages can be parsed to obtain different debugging contents. The third part can be one byte. The byte is used to indicate the specific content of the communication message. For example, the length of the specific content of the communication message can be recorded as L. The fourth part can be the specific content of the communication message. The specific content of the communication message is a string of length L. Optionally, the string of length L can be a binary string. Optionally, the string of length L includes a registry. Or, the string of length L includes specific debugging information.

[0074] The first process of the first controller can transmit the encoded communication message to the second process in the second controller. Since it is agreed that the structure can only use the plain data type (PlainOldData, POD) defined in the C / C++ language, when copying the structure data into these L bytes, only one copy is required, avoiding the complex field-by-field serialization process of solutions such as protobuf, greatly improving the data encoding efficiency. The debugged program sends the encoded data to the debugging program through the network to ensure that the data can be transmitted in time.

[0075] S160: The second controller receives a communication message to be transmitted sent by the first process in the first controller, wherein the communication message to be transmitted is generated based on content information.

[0076] In this embodiment, the second process of the second controller can also establish a data subscription terminal after establishing a connection with the first process of the first controller, and start to monitor and receive data sent by the first process of the first controller. When the first process in the first controller publishes a communication message on the publishing terminal, the second process of the second controller can monitor the communication message. The second process of the second controller can obtain the communication message.

[0077] S170. The second controller performs data analysis on the communication message to be transmitted according to the registration table.

[0078] In this embodiment, the second process of the second controller may perform data analysis on the communication message after obtaining the communication message. Optionally, the data analysis process may be specifically divided into two stages. The first stage may be a decoding process of the encoded data. The second stage may be a process of analyzing the specific content of the communication message.

[0079] In one example, the second process of the second controller can decode the encoded communication message to be transmitted to obtain the decoded communication message to be transmitted. Among them, the encoded communication message includes the communication message to be transmitted and the attribute information of the communication message to be transmitted. The attribute information includes the length of the communication message and the message type of the communication message. Specifically, the second process of the second controller can first read the first byte to obtain the length N of the topic name, and then read the subsequent N bytes to obtain the topic. The topic is the message name. The second process of the second controller can continue to read the length L of the specific content of the communication message, and then read the subsequent L bytes to obtain the binary data data of the specific content of the communication message. Specifically, the second process of the second controller can call the KMessageRegistry::MessageDescriptor function, pass in topic_name, and obtain the description class KMessageDescriptor object of the field description object of the communication message. The second process of the second controller can obtain a readable description text string of the field description object by calling the DebugString method of the KMessageDescriptor object. The second process of the second controller can also combine all the character strings of the communication message to obtain a message string.

[0080] In one example, the second process of the second controller can decode the encoded communication message to obtain the message name and binary data data. The second process of the second controller can search in the registry according to the message name. The registry can contain a mapping relationship between the message name and the field description object. Optionally, the registry can contain a mapping relationship between the message name and the pointer to the field description object. The second process of the second controller can query at least one field description object from the registry according to the message name. Each field description is a structure composed of multiple attribute information of a field in the communication message to be transmitted. The field description object obtained by the query is the field description object of the communication message currently being transmitted.

[0081] In one example, the second process of the second controller may sequentially obtain character strings of fields corresponding to each field description object from the communication message by traversing the field description objects corresponding to the communication message to be transmitted.

[0082] Specifically, taking a character string of a field of a field description object as an example, the process of the second process of the second controller acquiring the character string of the field may include the following steps:

[0083] Step 1: The second process of the second controller obtains the field offset, field size, and field repetition count of the field from the field description object.

[0084] Step 2: The second process of the second controller determines whether the number of repetitions of the field is 1.

[0085] If the number of repetitions of the field is 1, the second process of the second controller can directly obtain the string of the field from the continuous memory of the communication message according to the field offset and the field size. In this process, the second process of the second controller can first determine the starting position of the field in the continuous memory of the communication message according to the field offset. Secondly, the second process of the second controller can determine the ending position of the field in the continuous memory of the communication message according to the sum of the field offset and the field size. Finally, the second process of the second controller can obtain the string of the field from the continuous memory of the communication message according to the starting position and the ending position.

[0086] If the number of field repetitions is greater than 1, the second process of the second controller may use the number of field repetitions as a counter to obtain a string of each repeated field. The second process of the second controller may also use a preset first connection symbol to connect the string of each repeated field using the first connection symbol to obtain a final string. The process of obtaining the string of each repeated field may include:

[0087] Step 21: Determine whether the number of field repetitions is greater than 0. If yes, proceed to step 22. If no, proceed to step 24.

[0088] Step 22: determine the starting position of the field in the continuous memory of the communication message according to the field offset; determine the ending position of the field in the continuous memory of the communication message according to the sum of the field offset and the field size; and obtain the repeated string from the continuous memory of the communication message according to the starting position and the ending position.

[0089] Step 23: Set the field offset to the sum of the field offset and the field size; reduce the number of field repetitions by 1. Return to step 21.

[0090] Step 24: Use a preset first connection symbol to connect the character strings of each repeated field using the first connection symbol to obtain a final character string. Optionally, the first connection symbol can be a semicolon, a colon, a comma, a space, or the like. Optionally, symbols such as parentheses, square brackets, and curly brackets can be added at the beginning and end of the character strings of the multiple repeated fields to distinguish them.

[0091] Optionally, fields with a field repetition count greater than 1 correspond to data in array format.

[0092] In one example, the second process of the second controller can connect the character string of the field corresponding to the field description object corresponding to the communication message using a second connection symbol to obtain a message character string. Optionally, the second connection symbol can be a semicolon, a colon, a comma, a space, or the like.

[0093] The cross-process data parsing method provided by the present invention can send a registration table corresponding to the message format of the communication message to be transmitted to the second process in the second controller in response to a connection request initiated by the second process in the second controller; obtain content information in a field in the communication message to be transmitted, and generate the communication message to be transmitted according to the obtained content information; transmit the communication message to be transmitted to the second process in the second controller, so that the second process of the second controller performs data parsing on the communication message to be transmitted according to the registration table. In the present invention, by synchronizing the registration table, the parsing of the communication message in the cross-process debugging process is realized, and the flexibility of the cross-process data parsing is improved.

[0094] In the above embodiment, the second process of the second controller can call the DebugString method to obtain a readable description text string of the field description object. The function of the DebugString method is to generate a string of the field of the field description object so that the second process of the second controller can view and analyze the content of the field during the debugging process. The function of the DebugString method can receive binary data, parse and format it into a readable string, and return it to the caller. The parameter of the function of the DebugString method is const char*data. The parameter points to a character array containing the field description object. The DebugString method can first create an output string. Specifically, the DebugString method can use std::ostringstreamostr to create a string. The string is used to store the debugging information contained in the communication message. The DebugString method can output the field name and output the field name to the string. Thereafter, the DebugString method can process the communication message of the field corresponding to the field name. The DebugString method can convert the string stream into std::string and return it. The string generated by the DebugString method contains the field name and its corresponding value, which is convenient for viewing during debugging. Through the function of the DebugString method, the data of the field corresponding to the field description object can be parsed and formatted into a readable string, helping developers to view and analyze the data content more intuitively during the debugging process.

[0095] The DebugString method can also check whether the number of repetitions of the field, num_, is 1. If so, the DebugString method can use a switch statement to select the appropriate parsing and formatting method based on the field type, and output the parsed value to the string stream. For basic types such as INT32 and DOUBLE, the DebugString method can use the macro GENERATE_DEBUG_STR_CASE to copy the data from the data pointer offset offset_ to the corresponding variable, and output the variable value to the string stream. If the number of repetitions of the field, num_, is greater than 1, the DebugString method can use a switch statement to select the appropriate parsing and formatting method based on the field type, and output the parsed value to the string stream. For basic types such as INT32 and DOUBLE, the DebugString method can use the macro GENERATE_DEBUG_STR_REPEATED_CASE to copy the data from the data pointer offset offset_ plus i*size_ to the corresponding variable, and output the variable value to the string stream, with field values ​​separated by commas.

[0096] Among them, the GENERATE_DEBUG_STR_CASE macro is used to handle the parsing and formatting of a single field. It receives two parameters: case_ represents the type enumeration value of the field, and type_ represents the actual data type of the field. After matching the corresponding type in the switch statement, the macro creates a variable value of type type_ and uses the memcpy function to copy the field data at the offset offset_ of the data pointer to value. Then value is output to the string stream ostr and the current case branch ends. The GENERATE_DEBUG_STR_REPEATED_CASE macro is used to handle the parsing and formatting of repeated fields. It receives two parameters: case_ represents the type enumeration value of the field, and type_ represents the actual data type of the field. After matching the corresponding type in the switch statement, the macro starts to generate a string representation containing multiple field values, first outputting a left square bracket [. Then, it traverses each repeated field value, creates a variable value of type type_ for each value, and uses the memcpy function to copy the field data at the offset offset_ of the data pointer plus i*size_ to value. Output value to the string stream ostr, inserting commas and spaces between each value as separators. Finally, output a right square bracket ] and end the current case branch.

[0097] In one example, the field description object includes at least one of the following attribute information: field name, field type name, field index, field type, field offset, field size, and field repetition count. The field name represents the name of the field. The field type name represents the data type of the field. The field type includes an enumeration table of the data type of the field. The field index represents the sequence number of the field in the communication message. The field offset represents the offset of the content information in the continuous memory storing the communication message. The field size represents the data length of the content information. The field repetition count represents the length of the array when the field type of the field is an array.

[0098] Among them, the field description object can inherit from the field description class KFieldDescriptor. The field description class KFieldDescriptor is used to describe the information of a single field. The field description class KFieldDescriptor contains 7 member variables, namely the name of the field name_, the type name of the field type_name_, the index of the field index_, the type of the field type_, the offset of the field in the message continuous memory offset_, the size of the field size_, and the number of repetitions of the field num_. Among them, the type of the field type_ can be defined using the FieldType enumeration. Among them, FieldType has the following types: 32-bit integer type INT32, 64-bit integer type INT64, 32-bit non-negative integer type UINT32, 64-bit non-negative integer type UINT64, double floating point type DOUBLE, single floating point type FLOAT, non-Boolean type BOOL, enumeration type ENUM, string type STRING, structure type MESSAGE.

[0099] The field description class KFieldDescriptor can also define its constructor. The constructor accepts the name, type name, index, field type, offset, size and number of repetitions of the field, and initializes the corresponding member variables. At the same time, the constructor can also define the access method of the corresponding member variables to obtain detailed information of the field. For example, Name() is used to return the name of the field; TypeName() is used to return the type name of the field; Index() is used to return the index of the field; Size() is used to return the size of the field; Offset() is used to return the offset of the field; RepeatedNumber() is used to return the number of repetitions of the field; Type() is used to return the type of the field.

[0100] In addition, for a field description object of type MESSAGE, the DebugString method can obtain the corresponding KMessageDescriptor descriptor and recursively call its DebugString function to generate debugging information for the sub-message. For a field description object of type CHAR, the DebugString method can copy the string at the data pointer offset offset_ to std::string and output the string to the string stream. For a field description object of type MESSAGE, the DebugString method can obtain the corresponding KMessageDescriptor descriptor and recursively call its DebugString function to generate debugging information for each sub-message and output the debugging information to the string stream.

[0101] Figure 3 A flow chart of a cross-process data parsing method provided by an embodiment of the present invention is shown. Figure 1 and Figure 2 Based on the embodiment shown, Figure 3 As shown, before step S110, the first process of the first controller may also obtain field format information of fields in the communication message to be transmitted, and generate a registration table according to the obtained field format information of the fields. With the first controller as the execution subject, the process of generating the registration table may include the following steps:

[0102] S210: Obtain field format information of fields in the communication message to be transmitted.

[0103] In this embodiment, the first process of the first controller can obtain field format information of fields in a communication message to be transmitted. Optionally, the communication message to be transmitted can be a debugging message in a debugging process. Optionally, the first process of the first controller can include multiple communication messages. Optionally, each communication message can include fixed fields and a fixed field format. Optionally, when the first process of the first controller needs to add a new communication message, the new communication message can include fixed fields and a fixed field format. Optionally, the fields of each communication message and the format of the field amount are different.

[0104] S220: Generate a field description object of the field according to the acquired field format information of the field. The field description object is a structure composed of multiple attribute information of the field.

[0105] In this embodiment, the first process of the first controller can obtain the field format information of the field of the communication message. The first process of the first controller can generate a field description object for each field according to the field format information of each field. The field description object can be a structure consisting of multiple attribute information of the field. Optionally, the field description object includes at least one attribute information of the field name, field type name, field index, field type, field offset, field size and field repetition number. Optionally, each attribute information can correspond to a key-value pair. Among them, the key is the field name, field type name, field index, field type, field offset, field size and field repetition number, and the value is a specific value. Among them, the field name, field type name field type, field size and field repetition number can be determined according to the information of the field itself. Among them, the field repetition number can be determined according to the length of the array corresponding to the field.

[0106] In one example, the field index and the field offset need to be determined based on the order of the fields in the communication message. The first process of the first controller can obtain the field index and field offset of the field description object of the previous field when writing the field description object. The first process of the first controller can write the value of the field index of the previous field incremented by 1 into the field index of the field description object of the current field. The first process of the first controller can calculate the product of the field size of the current field and the number of field repetitions of the current field and the field offset of the previous field, and write them into the field offset of the field description object of the current field. The first process of the first controller can generate the current field description object based on the field index and field offset.

[0107] In one example, the first process of the first controller may also add the field index and field description object of the current field to the index mapping table during the process of generating the field description object. The index mapping table represents the mapping relationship between the field index and the field description object. Specifically, the index mapping table may include a pointer to the field index and the field description object. And / or, the first process of the first controller may also add the field name and field description object of the current field to the field name mapping table. The field name mapping table represents the mapping relationship between the field name and the field description object. Specifically, the field name mapping table may include a pointer to the field name and the field description object. The index mapping table and the field name mapping table may be defined in the structure description class KMessageDescriptor.

[0108] In one example, the first process of the first controller may also send the index mapping table and the field name mapping table to the second process of the second controller. The second process of the second controller may also query the field description object corresponding to the field index through the index mapping table according to the field index. And / or, the second process of the second controller may also query the field description object corresponding to the field name through the field name mapping table according to the field name.

[0109] S230. Generate a registration table according to the field description object of the field in the communication message.

[0110] In this embodiment, the first process of the first controller may also write the field description objects of the fields in the communication message into the registration table after generating the field description objects. Optionally, the first process of the first controller may complete the generation of the registration table after writing all the field description objects of all the communication messages into the registration table.

[0111] In one example, the registration table generated by the first process of the first controller may include a mapping relationship between a message name and a field description object corresponding to a message format of a communication message. Optionally, the first process of the first controller may write a mapping relationship between a message name and a pointer to a field description object into the registration table.

[0112] Optionally, when a new communication message appears between the first process of the first controller and the second process of the second controller, the first process of the first controller may write a field description object of the new communication message into a registration table to obtain a new registration table.

[0113] The cross-process data parsing method provided by the present invention is that the first process of the first controller can obtain the field format information of the field in the communication message to be transmitted. The first process of the first controller can obtain the field format information of the field of the communication message. The first process of the first controller can generate a field description object for each field according to the field format information of each field. The first process of the first controller can also write the field description objects into a registry after generating the field description objects of the fields in the communication message. In the present invention, the registry is generated in the first process of the first controller to achieve flexible generation of the registry.

[0114] In the above process, a structure description class KMessageDescriptor can be defined in the first process of the first controller. The structure description class is used to describe the information of a single structure. Among them, the member variables of the defined class may include an index mapping table index_map for storing field description objects by field index, and a field name mapping table name_map for storing field description objects by field name. The index mapping table index_map and the field name mapping table name_map may be unordered_map in the C++ Standard Template Library (STL). The variables therein may include the current field index index_. The field index starts from 0. The current field offset offset_. The field offset starts from 0.

[0115] The structure description class KMessageDescriptor can define its constructor and destructor. Among them, the constructor KMessageDescriptor() is used to initialize the class. Among them, index_ is initialized to 0 and offset_ is initialized to 0. Among them, the destructor ~KMessageDescriptor() is used to release the memory of the field descriptor. The destructor can release the memory of all KFieldDescriptor objects after traversing index_map_.

[0116] The structure description class KMessageDescriptor can also define the batch adding field method AddFields. The AddFields method has two overloaded functions, one is the ordinary parameterless function AddFields(), which is implemented as empty and serves as the recursive termination condition. The other is the variable length template parameter function template<typename...Fields> void void AddFields(const std::string&name, const std::string&type_name, FieldType type, uint64_t size, uint64_t num, Fields...rest). The AddFields method uses the recursive template parameter pack expansion technology to implement the function of accepting multiple field information and processing them in sequence. The parameters of the AddFields method include the field name (name), field type name (type_name), field type (type), field size (size), field repetition count (num), and remaining field information (rest). In the AddFields method body, first use the new operator to create a KFieldDescriptor object (desptr), and the parameters of its constructor are the field name, field type name, current index (index_), field type, current offset (offset_), field size, and field repetition count. The created KFieldDescriptor object is used to describe the detailed information of a single field. Then, the created KFieldDescriptor object is stored in two unordered_maps. The first unordered_map can be an index mapping table (index_map_). The index_map uses the index of the field as the key and the pointer of the field description object as the value to form multiple key-value pairs. The second unordered_map can be a field name mapping table (name_map_). The name_map uses the name of the field as the key and the pointer of the field description object as the value to form multiple key-value pairs. These two unordered_map structures are used to quickly find field descriptors based on the field index and field name. AddFields can update the current field index and field offset after each field description object is added. The field index (index_) is incremented by 1, index_=index_+1. The field offset (offset_) is accumulated according to the size of the field and the number of repetitions, offset_=size*num. The update of the field index and field offset can ensure that the storage location of the next field is correct.The AddFields method can call the AddFields method itself to recursively process the remaining field information (rest). The parameter of the recursive call is the remaining field information. The termination condition of the recursion is that there is no remaining field information (rest). That is, the recursion ends when the parameter pack expansion is completed. At this time, call the empty AddFields() method to end the recursive process. Through the above steps, the AddFields method implements the batch addition of field description objects and ensures that the field information is stored correctly in index order. This method uses recursive template parameter pack expansion technology to make it possible to flexibly process any amount of field information, simplify code writing, and improve the scalability and maintainability of the program.

[0117] The structure description class KMessageDescriptor can also define a single AddField method for adding field description information. The parameters of the AddField method include field name (name), field type name (type_name), field index (index), field type (type), field offset (offset), field size (size), and field repetition count (num). In the AddField method, the new operator can be used to create a KFieldDescriptor object (desptr). The parameters of the constructor of the KFieldDescriptor object are field name, field type name, field index, field type, field offset, field size, and field repetition count. The created KFieldDescriptor object is used to describe the detailed information of a single field. Then, the created KFieldDescriptor object is stored in two unordered_maps. It can be an index mapping table (index_map_). The index_map uses the index of the field as the key and the pointer of the field description object as the value to form multiple key-value pairs. The second unordered_map can be a field name mapping table (name_map_). The name_map uses the name of the field as the key and the pointer of the field description object as the value to form multiple key-value pairs. The two unordered_map structures are used to quickly find field descriptors based on field index and field name. Through the above steps, the AddField method implements the addition of a single field descriptor and ensures that field information is correctly stored by index and name.

[0118] The structure description class KMessageDescriptor may also define a FieldNumber() method for returning the number of fields, an IndexMap() method for returning an unordered_map of field descriptors stored by index, and a NameMap() method for returning an unordered_map of field descriptors stored by name.

[0119] The structure description class KMessageDescriptor can also define the DebugString function that generates the debug information string of the message. Parse the binary data of the message into a readable string format for debugging and viewing. The function accepts a parameter, which is a pointer data pointing to the starting position of the binary data. The DebugString function first creates a string stream ostr of type ostringstream to store the generated debug information string. Then, the DebugString function inserts a left curly brace { into the string stream to start generating the output format. Next, the DebugString function initializes a counter i=0 and a total number of fields n=index_map_.size() to control the delimiter between fields. Next, the DebugString function traverses each field descriptor in the index_map_ container and calls the DebugString method of the field descriptor to generate the debug information string s of the field. If the generated string s is not empty, it is inserted into the string stream, and the decision on whether to insert a newline and a right curly brace is made based on the counter i and the total number n of the field. If i+1==n, a right curly brace is inserted to indicate the end, otherwise a newline symbol is inserted. Finally, the DebugString function converts the content generated in the string stream into std::string and returns it. The generated string contains all the fields of the message and their corresponding values, which is convenient for viewing the specific data content during debugging. The DebugString function can easily parse complex binary data structures into readable string formats, helping developers quickly locate and solve problems during debugging.

[0120] A global type registration class KMessageRegistry can also be defined in the first process of the first controller. The global type registration class KMessageRegistry is responsible for managing all registered type information. The global type registration class KMessageRegistry ensures a globally unique instance through a singleton pattern to ensure unified management and efficient access to type information. The global type registration class KMessageRegistry mainly provides functions such as type registration, type information acquisition, type descriptor acquisition, type information export and import. The KMessageRegistry class has a private member variable types_, which is of type unordered_map. types_ is used to store the mapping relationship between type names and pointers to KMessageDescriptor objects, with the key being the type name and the value being a pointer to the KMessageDescriptor object. This unordered_map structure allows the corresponding KMessageDescriptor object to be quickly found based on the type name. This unordered_map structure is the registry.

[0121] The KMessageRegistry class can also define a static method GetInstance. The GetInstance method is a static method used to obtain the only instance of the KMessageRegistry class. The method implements the singleton pattern by returning a reference to a static local variable instance. The variable is created and initialized when it is first called, and the same instance is returned for each subsequent call to ensure the global uniqueness of KMessageRegistry. The GetInstance method implements the singleton pattern by defining a static local variable instance and returning a reference to the variable. This approach ensures thread safety and only creates an instance when it is first called, and all subsequent calls return the same instance.

[0122] The KMessageRegistry class also defines the Register method for registering type information. The Register method is used to register type information. This method accepts two parameters: the type name (typeName) and the KMessageDescriptor pointer (fields). The method stores the type name and KMessageDescriptor pointer in types_ to ensure that each type name is unique. After successful registration, a message will be output to confirm the registration. The specific implementation steps include: checking whether the type name is unique. If it is unique, the type name and KMessageDescriptor pointer are stored in types_, and a message of successful registration is output. This process ensures that the information of the registered type can be quickly stored and retrieved.

[0123] The KMessageRegistry class also defines the GetTypes method. The GetTypes method is a constant method that returns a reference to a constant unordered_map. It contains all registered type information, allowing users to obtain the reference type of all registered classes and their corresponding KMessageDescriptor objects. This method provides a convenient way to access all registered type information. The GetTypes method can ensure that the caller cannot modify the internal storage structure by directly returning a constant reference to types_, while providing read-only access to registered type information.

[0124] The KMessageRegistry class also defines the MessageDescriptor method. The MessageDescriptor method is used to obtain the type descriptor of the specified name. This method accepts a type name (name) as a parameter and returns a pointer to the corresponding KMessageDescriptor object. This method allows users to obtain specific type description information based on the type name, which facilitates the operation and management of specific types. The MessageDescriptor method can search for the type descriptor of the specified name in types_, and if found, it returns the pointer. If not found, it returns a null pointer.

[0125] The KMessageRegistry class also defines the ExportToYAML method. The ExportToYAML method is used to export the registered message type and its field information into a YAML-formatted string for persistent storage or transmission. The ExportToYAML method has no parameters and returns a YAML-formatted string containing all type and field information. The ExportToYAML method first creates a YAML::Emitter object out to generate data in YAML format. Next, the ExportToYAML method starts generating a YAML mapping, marked with YAML::BeginMap. Then, the ExportToYAML method traverses each type in the types_ container (the key is the type name and the value is KMessageDescriptor*). For each type, the type name is added as a key to the YAML mapping and a new mapping is started. In the type mapping, a key "Fields" is added, whose value is a sequence, and sequence generation begins. Next, the ExportToYAML method traverses the fields of the type and obtains the field information through type.second->IndexMap(). For each field, the ExportToYAML method starts a new mapping, adding the field's name, type name, index, type, offset, size, and number of repetitions. After the field information is added, the ExportToYAML method ends the mapping of the field. After all fields are added, the ExportToYAML method ends the mapping of the "Fields" key sequence and type. After all types are added, the ExportToYAML method ends the generation of the YAML mapping. Finally, the ExportToYAML method returns the generated YAML string.

[0126] The KMessageRegistry class also defines the ImportFromYAML method. The ImportFromYAML method is used to import the message type and its field information from a YAML formatted string and update the content of the type registry. The parameter of the ImportFromYAML method is input of type std::string, which represents the YAML string to be imported. The ImportFromYAML method first uses the YAML::Load function to parse the YAML string into a YAML::Node object data. Then, it traverses each type node in data, obtains the type name, and starts processing the "Fields" node. The ImportFromYAML method creates a new KMessageDescriptor object des for each type. Next, the ImportFromYAML method traverses each field node in the "Fields" node, and the ImportFromYAML method calls the des->AddField function to add field information, passing in parameters such as the field name, type name, index, type, offset, size, and number of repetitions. After all fields are added, the ImportFromYAML method adds des to the types_ container, with the type name as the key and des as the value. In this way, the content of the entire type registry is successfully updated with the information contained in the YAML string.

[0127] The macro KMESSAGE_REGISTER is also defined in the KMessageRegistry class. The macro KMESSAGE_REGISTER is used to automatically register the message type and its field information to the global type register. The macro KMESSAGE_REGISTER implements the registration operation by defining an anonymous namespace and a structure, and ensures that the registrar is automatically executed when the program starts. The macro KMESSAGE_REGISTER first defines an anonymous namespace to ensure that the scope of the structure and static variables is limited to the current translation unit. Next, the macro KMESSAGE_REGISTER defines a structure named KRegistrator_##type, where type is the name of the message type passed in. The constructor of the structure is responsible for creating a new KMessageDescriptor object des. The macro KMESSAGE_REGISTER calls des->AddFields(__VA_ARGS__) to add field information. __VA_ARGS__ represents the variable parameter list passed in, that is, the field information of the message type. Then, the macro KMESSAGE_REGISTER calls KMessageRegistry::GetInstance().Register(#type, des) to register the type name and descriptor object in the global type register, and #type converts the message type name into a string. Finally, the macro KMESSAGE_REGISTER defines a static variable kReg_##type of the KRegistrator_##type type to ensure that the variable is constructed when the program starts, so that the constructor of the structure is automatically executed to realize the registration of the message type and field information. Through the definition of the macro KMESSAGE_REGISTER, the registration process of the message type can be simplified to avoid manually writing repeated registration code.

[0128] Figure 4 FIG. 1 is a flow chart showing a cross-process data parsing method provided by an embodiment of the present invention. Figure 4 As shown, the first process is the process to be debugged, and the second process is a process used to debug other processes. When the first process and the second process are both deployed on a controller, the controller is named the third controller, and the third controller is used as the execution subject. The method of this embodiment may include the following steps:

[0129] S310: The second process sends a connection request to the first process, wherein the connection request indicates that the second process requests to establish a connection with the first process.

[0130] S320: The first process sends a registration table corresponding to the message format of the communication message to be transmitted to the second process, wherein the communication message to be transmitted is a message that the first process needs to transmit, and the registration table is used to indicate field format information of fields in the communication message to be transmitted.

[0131] S330: The first process obtains content information in a field in the communication message to be transmitted, and generates a communication message to be transmitted according to the obtained content information.

[0132] S340: The first process sends the communication message to be transmitted to the second process.

[0133] S350: The second process performs data analysis on the communication message to be transmitted according to the registration table.

[0134] Optionally, in the third controller, the first process may obtain field format information of fields in the communication message to be transmitted, and generate a registration table according to the obtained field format information of the fields.

[0135] Optionally, in the third controller, the first process can generate a field description object of the field according to the acquired field format information of the field. The field description object is a structure composed of multiple attribute information of the field. The first process generates a registration table according to the field description object of the field in the communication message.

[0136] Optionally, in the third controller, the first process can obtain the field index and field offset of the field description object of the previous field; write the value of the field index of the previous field incremented by 1 into the field index of the field description object of the current field; calculate the sum of the product of the field size of the current field and the number of field repetitions of the current field and the field offset of the previous field, and write it into the field offset of the field description object of the current field.

[0137] Optionally, in the third controller, the first process may add the field index and field description object of the current field to an index mapping table. The index mapping table represents the mapping relationship between the field index and the field description object. And / or, the first process adds the field name and field description object of the current field to a field name mapping table. The field name mapping table represents the mapping relationship between the field name and the field description object.

[0138] Optionally, in the third controller, the first process may obtain a message name corresponding to a message format of the communication message to be transmitted; and write the message name and a field description object of the communication message to be transmitted into a registration table.

[0139] Optionally, in the third controller, the first process may obtain content information in a field in the communication message to be transmitted in response to a periodic event; or, in response to a specific event, obtain content information in a field in the communication message to be transmitted.

[0140] Optionally, the first process may encode the communication message to be transmitted to obtain an encoded communication message. The encoded communication message includes the communication message to be transmitted and attribute information of the communication message to be transmitted. The attribute information includes the length of the communication message and the message type of the communication message; the encoded communication message is transmitted to the second process. The second process may decode the encoded communication message to be transmitted to obtain a decoded communication message to be transmitted.

[0141] Optionally, the second process may traverse the field description objects corresponding to the communication message to be transmitted, and obtain the field character string from the communication message to be transmitted according to the field description object; and connect the field character strings corresponding to the communication message to be transmitted to obtain the message character string.

[0142] Optionally, the second process may obtain a message name corresponding to the message format of the communication message to be transmitted, and obtain a field description object corresponding to the communication message to be transmitted from a registry according to the message name. The field description object is a structure consisting of multiple attribute information of fields in the communication message to be transmitted.

[0143] Optionally, the second process may query the field description object corresponding to the field index through the index mapping table according to the field index. And / or, the second process may query the field description object corresponding to the field name through the field name mapping table according to the field name.

[0144] The implementation process of the cross-process data parsing method provided by the embodiment of the present invention is Figure 1 The specific implementation principle and technical effect of the embodiment shown are similar, and can be found in the above method embodiment, which will not be described in detail in this embodiment. Figure 1 The difference between the illustrated embodiments is that the first process and the second process in the present invention are arranged in one controller. This arrangement enables the debugging of the first process to be debugged in the vehicle through the second process during the life cycle of the vehicle.

[0145] Figure 5 FIG. 1 shows an interaction diagram between a debugged program and a debugger provided by an embodiment of the present invention. Figure 5As shown, the debugged program is the first process, which is the debugged process to be debugged. The debugged program can be used as a server. The debugging program is the second process, which is a debugging process used to debug other processes. The debugging program can be used as a client. The registry synchronization process and the communication message transmission process between the debugged program and the debugging program may include the following steps:

[0146] Step 1: According to the above method, complete the generation of the registry in the debugged program.

[0147] Step 2: The debugged program, as a server, uses KMessageRegistry to register the interface information when it starts. The interface information includes the message names of all communication messages of the debugged program and the field format information of the fields in the communication messages. The debugged program calls the KMessageRegistry::ExportToYAML function to export the registered information into a string in YAML format for subsequent transmission.

[0148] Step 3: When the debugger is started as a client, it first initializes the network components and prepares to establish a connection with the server. Create a TCP or UDP client and configure the IP address and port of the target server.

[0149] Step 4: The debugged program starts the server listening. Create a TCP or UDP server, bind to the specified IP address and port, and start listening for the connection request of the client corresponding to the debugged program.

[0150] Step 5: The debugger sends a connection request to obtain the registration information. After the debugger establishes a connection with the debugged program, it sends a connection request to the debugged program, indicating that it needs to obtain the interface registration information. Wait for the debugged program's response.

[0151] Step 6: The debugged program processes the connection request of the debugger. When the debugger connects to the debugged program, the debugged program receives the connection request of the debugger. According to the connection request content, the debugged program sends the previously exported YAML format string as response data to the debugger to ensure that the debugger can obtain the latest interface registration information.

[0152] Step 7: The debugger receives a YAML format string containing interface registration information.

[0153] Step 8. The debugger parses and updates the registration information. After receiving the YAML format string returned by the debugged program, the debugger uses the KMessageRegistry::ImportFromYAML function to parse the string and update the local interface registration information. In this way, the debugger can maintain consistent interface information with the server, ensuring the accuracy and consistency of the debugging process.

[0154] Step 9: Establish a publishing end in the debugged program according to the publish / subscribe communication mode. The debugged program will publish the structure data that needs to be debugged and analyzed outside the process according to the required periodicity or specific events, so that the debugger can receive the data for analysis and processing.

[0155] Step 10: When the debugging program starts, the network components are initialized first, a data subscription terminal is established, and a communication link is established with the debugged program to receive data.

[0156] Step 11. When sending data, the debugged program first encodes the communication message. The first byte in the code represents the length N of the topic name of the structure being sent, the subsequent N bytes represent the topic name of the structure being sent, the next byte represents the length L of the structure being sent, and the subsequent L bytes represent the actual binary data of the structure being sent. Since it is agreed that the structure can only use the POD type (Plain Old Data) defined in the C / C++ language, when copying the structure data into these L bytes, only one complete copy is required, avoiding the complex field-by-field serialization process of solutions such as protobuf, greatly improving data encoding efficiency. The debugged program sends the encoded data to the debugging program through the network to ensure that the data can be transmitted in a timely manner.

[0157] Step 12: After the debugger establishes a connection with the debugged program, it starts to monitor and receive data sent by the debugged program. The received data is sent according to the previously defined encoding format, and the debugger needs to perform corresponding decoding processing.

[0158] Step 13. After receiving the encoded data, the debugger first reads the first byte to obtain the length N of the topic name. Then reads the following N bytes to obtain the topic name topic_name. Then reads the next byte to obtain the length L of the structure data. Finally, reads the following L bytes to obtain the actual binary data data.

[0159] Step 14, the debugger calls the KMessageRegistry::MessageDescriptor function, passes in topic_name, and obtains the description class KMessageDescriptor object instance des of the structure.

[0160] Step 15: The debugger calls the DebugString method of des to obtain the readable description text string information of the structure.

[0161] Figure 6 FIG. 4 shows a schematic diagram of the structure of a cross-process data parsing device provided by an embodiment of the present invention. Figure 6 As shown, the cross-process data analysis device 400 of this embodiment is applied to a first controller, in which a first process is deployed, and the first process is a process to be debugged. The cross-process data analysis device 400 of this embodiment includes:

[0162] The transceiver module 410 is used to respond to the connection request initiated by the second process in the second controller and send a registration table corresponding to the message format of the communication message to be transmitted to the second process in the second controller. The second process is a process for debugging other processes, and the connection request represents that the second process requests to establish a connection with the first process. The registration table is used to indicate the field format information of the field in the communication message to be transmitted.

[0163] The processing module 420 is used to obtain content information in a field in the communication message to be transmitted, and generate the communication message to be transmitted according to the obtained content information. The communication message to be transmitted is transmitted to the second process in the second controller. The communication message to be transmitted is used to perform data parsing based on the registration table obtained by the second process.

[0164] Optionally, the processing module 420 is configured to:

[0165] In response to the periodic event, content information in a field in a communication message to be transmitted is obtained.

[0166] Alternatively, in response to a specific event, content information in a field in a communication message to be transmitted is obtained.

[0167] Optionally, the processing module 420 is configured to:

[0168] The communication message to be transmitted is encoded to obtain an encoded communication message, wherein the encoded communication message includes the communication message to be transmitted and attribute information of the communication message to be transmitted. The attribute information includes the length of the communication message and the message type of the communication message.

[0169] The encoded communication message is transmitted to the second process in the second controller.

[0170] Optionally, the processing module 420 is configured to:

[0171] The field format information of the field in the communication message to be transmitted is obtained, and a registration table is generated according to the obtained field format information of the field.

[0172] Optionally, the processing module 420 is configured to:

[0173] According to the acquired field format information of the field, a field description object of the field is generated. The field description object is a structure composed of multiple attribute information of the field.

[0174] A registration table is generated according to the field description object of the fields in the communication message.

[0175] Optionally, the field description object includes at least one of the following attribute information: field name, field type name, field index, field type, field offset, field size, and field repetition count. The field name represents the name of the field. The field type name represents the data type of the field. The field type includes an enumeration table of the data type of the field. The field index represents the sequence number of the field in the communication message. The field offset represents the offset of the content information in the continuous memory storing the communication message. The field size represents the data length of the content information. The field repetition count represents the length of the array when the field type of the field is an array.

[0176] Optionally, the processing module 420 is configured to:

[0177] Get the field index and field offset of the field description object of the previous field.

[0178] Write the value of the field index of the previous field, which is incremented by 1, into the field index of the field description object of the current field.

[0179] Calculate the sum of the product of the field size of the current field and the field repetition count of the current field and the field offset of the previous field, and write them to the field offset of the field description object of the current field.

[0180] Optionally, the processing module 420 is configured to:

[0181] Add the field index and field description object of the current field to the index mapping table. The index mapping table represents the mapping relationship between the field index and the field description object.

[0182] and / or,

[0183] Add the field name and field description object of the current field to the field name mapping table. The field name mapping table represents the mapping relationship between the field name and the field description object.

[0184] Optionally, the processing module 420 is configured to:

[0185] Get the message name corresponding to the message format of the communication message to be transmitted.

[0186] Write the message name and field description object of the communication message to be transmitted into the registry.

[0187] The cross-process data analysis device 400 provided in the embodiment of the present invention can execute the above method embodiment. Its specific implementation principle and technical effects can be found in the above method embodiment, which will not be repeated in this embodiment.

[0188] Figure 7 FIG. 4 shows a schematic diagram of the structure of a cross-process data parsing device provided by an embodiment of the present invention. Figure 7 As shown, the cross-process data analysis device 500 of this embodiment is applied to the second controller, and the second controller is deployed with a second process, which is a process for debugging other processes. The cross-process data analysis device 500 of this embodiment includes:

[0189] The transceiver module 510 is used to send a connection request to the first process in the first controller, and receive a registration table returned by the first process in the first controller. The first process is a process to be debugged, and the connection request indicates that the second process requests to establish a connection with the first process. The registration table is used to indicate the field format information of the field in the communication message to be transmitted. The communication message to be transmitted sent by the first process in the first controller is received. The communication message to be transmitted is generated based on the content information.

[0190] The processing module 520 is used to perform data analysis on the communication message to be transmitted according to the registration table.

[0191] Optionally, the processing module 520 is configured to:

[0192] The encoded communication message to be transmitted is decoded to obtain a decoded communication message to be transmitted. The encoded communication message includes the communication message to be transmitted and attribute information of the communication message to be transmitted. The attribute information includes the length of the communication message and the message type of the communication message.

[0193] Optionally, the processing module 520 is configured to:

[0194] Get the message name corresponding to the message format of the communication message to be transmitted.

[0195] The field description object corresponding to the communication message to be transmitted is obtained from the registry according to the message name. The field description object is a structure composed of multiple attribute information of the fields in the communication message to be transmitted.

[0196] Optionally, the processing module 520 is configured to:

[0197] The field description objects corresponding to the communication message to be transmitted are traversed, and the character string of the field is obtained from the communication message to be transmitted according to the field description object.

[0198] The character strings of the fields corresponding to the communication message to be transmitted are connected to obtain a message character string, where the message character string represents the content information of each field in the communication message.

[0199] Optionally, the processing module 520 is configured to:

[0200] Get the field offset, field size, and field repetition count of a field from a field description object.

[0201] When the field repetition count is 1, the starting position and the ending position of the field in the continuous memory of the communication message are determined according to the field offset and the field size, and the character string of the field is obtained from the continuous memory of the communication message according to the starting position and the ending position.

[0202] When the number of field repetitions is greater than 1, the starting and ending positions of each field repetition are determined according to the number of field repetitions, the field offset, and the field size, and the character string of each repeated field is obtained from the continuous memory of the communication message according to the starting and ending positions.

[0203] Optionally, the processing module 520 is configured to:

[0204] According to the field index, query the field description object corresponding to the field index through the index mapping table.

[0205] and / or,

[0206] According to the field name, query the field description object corresponding to the field name through the field name mapping table.

[0207] The cross-process data analysis device 500 provided in the embodiment of the present invention can execute the above method embodiment. Its specific implementation principle and technical effects can be found in the above method embodiment, which will not be repeated in this embodiment.

[0208] Figure 8 FIG. 4 shows a schematic diagram of the structure of a cross-process data parsing device provided by an embodiment of the present invention. Figure 8As shown, the cross-process data analysis device 600 of this embodiment is applied to a third controller, in which a first process and a second process are deployed, the first process is a process to be debugged, and the second process is a process for debugging other processes. The cross-process data analysis device 600 of this embodiment includes:

[0209] The transceiver module 610 is used to send a connection request to the first process based on the second process. The connection request indicates that the second process requests to establish a connection with the first process. A registration table corresponding to the message format of the communication message to be transmitted is sent to the second process based on the first process. The communication message to be transmitted is a message that the first process needs to transmit, and the registration table is used to indicate the field format information of the field in the communication message to be transmitted.

[0210] The processing module 620 is used to obtain content information in a field in the communication message to be transmitted based on the first process, and generate the communication message to be transmitted according to the obtained content information.

[0211] The transceiver module 610 is used to send the communication message to be transmitted to the second process based on the first process.

[0212] The processing module 620 is used to perform data analysis on the communication message to be transmitted according to the registration table based on the second process.

[0213] Optionally, the processing module 620 is configured to:

[0214] The first process responds to the periodic event and obtains content information in a field in a communication message to be transmitted.

[0215] or,

[0216] Based on the first process responding to the specific event, content information in a field in the communication message to be transmitted is obtained.

[0217] Optionally, the processing module 620 is configured to:

[0218] The communication message to be transmitted is encoded based on the first process to obtain an encoded communication message, wherein the encoded communication message includes the communication message to be transmitted and attribute information of the communication message to be transmitted. The attribute information includes the length of the communication message and the message type of the communication message.

[0219] The encoded communication message is transmitted to the second process based on the first process.

[0220] The encoded communication message to be transmitted is decoded based on the second process to obtain a decoded communication message to be transmitted.

[0221] Optionally, the processing module 620 is configured to:

[0222] The field format information of the field in the communication message to be transmitted is obtained based on the first process, and a registration table is generated according to the obtained field format information of the field.

[0223] Optionally, the processing module 620 is configured to:

[0224] Based on the first process, a field description object of the field is generated according to the acquired field format information of the field. The field description object is a structure composed of multiple attribute information of the field.

[0225] A registration table is generated based on a field description object of the first process according to the fields in the communication message.

[0226] Optionally, the processing module 620 is configured to:

[0227] Gets the field index and field offset of the field description object of the previous field based on the first process.

[0228] Based on the first process, the value of the field index of the previous field, which is incremented by 1, is written into the field index of the field description object of the current field.

[0229] Based on the first process, the sum of the product of the field size of the current field and the field repetition number of the current field and the field offset of the previous field is calculated, and written into the field offset of the field description object of the current field.

[0230] Optionally, the processing module 620 is configured to:

[0231] Based on the first process, the field index and field description object of the current field are added to the index mapping table. The index mapping table represents the mapping relationship between the field index and the field description object.

[0232] and / or,

[0233] Based on the first process, the field name and field description object of the current field are added to the field name mapping table. The field name mapping table represents the mapping relationship between the field name and the field description object.

[0234] Optionally, the processing module 620 is configured to:

[0235] Based on the field index, the second process queries the field description object corresponding to the field index through the index mapping table.

[0236] and / or,

[0237] Based on the second process, according to the field name, through the field name mapping table, the field description object corresponding to the field name is queried.

[0238] Optionally, the processing module 620 is configured to:

[0239] A message name corresponding to a message format of a communication message to be transmitted is obtained based on the first process.

[0240] The message name and field description object of the communication message to be transmitted are written into the registration table based on the first process.

[0241] Optionally, the processing module 620 is configured to:

[0242] The field description object corresponding to the communication message to be transmitted is traversed based on the second process, and the character string of the field is obtained from the communication message to be transmitted according to the field description object.

[0243] Based on the second process, character strings of fields corresponding to the communication message to be transmitted are connected to obtain a message character string, where the message character string represents content information of each field in the communication message.

[0244] Optionally, the processing module 620 is configured to:

[0245] A message name corresponding to a message format of the communication message to be transmitted is obtained based on the second process.

[0246] Based on the second process, a field description object corresponding to the communication message to be transmitted is obtained from the registry according to the message name. The field description object is a structure composed of multiple attribute information of the fields in the communication message to be transmitted.

[0247] The cross-process data analysis device 600 provided in the embodiment of the present invention can execute the above method embodiment. Its specific implementation principle and technical effects can be found in the above method embodiment, which will not be repeated in this embodiment.

[0248] Fig. 9 FIG. 1 shows a schematic diagram of the hardware structure of a first controller provided by an embodiment of the present invention. Fig. 9 As shown, the first controller 700 is used to implement the operations corresponding to the first controller in any of the above method embodiments. The first controller 700 of this embodiment may include: a memory 710, a processor 720 and a communication interface 740.

[0249] The memory 710 is used to store computer programs. The processor 720 is used to execute the computer programs stored in the memory to implement the methods in the above embodiments. Optionally, the memory 710 can be independent or integrated with the processor 720.

[0250] When the memory 710 is a device independent of the processor 720, the first controller 700 may further include a bus 730. The bus 730 is used to connect the memory 710 and the processor 720. For ease of representation, the bus in the drawings of the present invention is not limited to only one bus or one type of bus.

[0251] The communication interface 740 may be connected to the processor 710 via the bus 730. The processor 720 may control the communication interface 740 to implement communication with the second controller.

[0252] The first controller provided in this embodiment can be used to execute the above method, and its implementation method and technical effect are similar, which will not be described in detail in this embodiment.

[0253] Fig.10 FIG. 1 shows a schematic diagram of the hardware structure of a second controller provided by an embodiment of the present invention. Fig.10 As shown, the second controller 800 is used to implement the operations corresponding to the second controller in any of the above method embodiments. The second controller 800 of this embodiment may include: a memory 810, a processor 820 and a communication interface 840.

[0254] The memory 810 is used to store computer programs. The processor 820 is used to execute the computer programs stored in the memory to implement the methods in the above embodiments. Optionally, the memory 810 can be independent or integrated with the processor 820.

[0255] When the memory 810 is a device independent of the processor 820, the second controller 800 may further include a bus 830. The bus 830 is used to connect the memory 810 and the processor 820. For ease of representation, the bus in the drawings of the present invention is not limited to only one bus or one type of bus.

[0256] The communication interface 840 may be connected to the processor 810 via the bus 830. The processor 820 may control the communication interface 840 to implement communication with the second controller.

[0257] The second controller provided in this embodiment can be used to execute the above method, and its implementation method and technical effect are similar, which will not be described in detail in this embodiment.

[0258] Fig.11 FIG. 1 shows a schematic diagram of the hardware structure of a third controller provided by an embodiment of the present invention. Fig.11 As shown, the third controller 900 is used to implement the operations corresponding to the third controller in any of the above method embodiments. The third controller 900 of this embodiment may include: a memory 910, a processor 920 and a communication interface 940.

[0259] The memory 910 is used to store computer programs. The processor 920 is used to execute the computer programs stored in the memory to implement the methods in the above embodiments. Optionally, the memory 910 can be independent or integrated with the processor 920.

[0260] When the memory 910 is a device independent of the processor 920, the third controller 900 may further include a bus 930. The bus 930 is used to connect the memory 910 and the processor 920. For ease of representation, the bus in the drawings of the present invention is not limited to only one bus or one type of bus.

[0261] The communication interface 940 may be connected to the processor 910 via the bus 930. The processor 920 may control the communication interface 940 to implement communication with the second controller.

[0262] The third controller provided in this embodiment can be used to execute the above method. Its implementation method and technical effect are similar, and this embodiment will not be repeated here.

[0263] The present invention also provides a computer-readable storage medium, in which a computer program / instruction is stored. When the computer program / instruction is executed by a processor, it is used to implement the methods provided in the above-mentioned various embodiments.

[0264] Among them, the computer-readable storage medium can be a computer storage medium or a communication medium. The communication medium includes any medium that facilitates the transmission of a computer program from one place to another. The computer storage medium can be any available medium that can be accessed by a general-purpose or special-purpose computer. For example, a computer-readable storage medium is coupled to a processor so that the processor can read information from the computer-readable storage medium and write information to the computer-readable storage medium. Of course, the computer-readable storage medium can also be a component of the processor. The processor and the computer-readable storage medium can be located in an application-specific integrated circuit (ASIC). In addition, the ASIC can be located in a user device. Of course, the processor and the computer-readable storage medium can also exist in a communication device as discrete components.

[0265] Specifically, the computer-readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk. The storage medium can be any available medium that can be accessed by a general or special-purpose computer.

[0266] The present invention also provides a computer program product, which includes a computer program / instruction, and the computer program / instruction is stored in a computer-readable storage medium. At least one processor of a device can read the computer program / instruction from the computer-readable storage medium, and at least one processor executes the computer program / instruction so that the device implements the methods provided in the various embodiments described above.

[0267] In the several embodiments provided by the present invention, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic, for example, the division of modules is only a logical function division, and there may be other division methods in actual implementation, such as multiple modules can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or modules, which can be electrical, mechanical or other forms.

[0268] Among them, each module can be physically separated, for example, installed in different locations of a device, or installed on different devices, or distributed on multiple network units, or distributed on multiple processors. Each module can also be integrated together, for example, installed in the same device, or integrated in a set of codes. Each module can exist in the form of hardware, or can also exist in the form of software, or can also be implemented in the form of software plus hardware. The present invention can select some or all of the modules according to actual needs to achieve the purpose of the solution of this embodiment.

[0269] When each module is implemented as an integrated module in the form of a software function module, it can be stored in a computer-readable storage medium. The above-mentioned software function module is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to perform some steps of the methods of each embodiment of the present invention.

[0270] It should be understood that, although the various steps in the flowcharts in the above-described embodiments are sequentially displayed according to the indications of the arrows, these steps are not necessarily executed sequentially in the order indicated by the arrows. Unless there is a clear description in this article, the execution of these steps is not strictly limited in order, and they can be executed in other orders. Moreover, at least a portion of the steps in the figure may include a plurality of sub-steps or a plurality of stages, and these sub-steps or stages are not necessarily executed at the same time, but can be executed at different times, and their execution order is not necessarily to be carried out sequentially, but can be executed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps.

[0271] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit them. Although the present invention has been described in detail with reference to the above embodiments, a person skilled in the art should understand that the technical solutions described in the above embodiments can still be modified, or some or all of the technical features can be replaced by equivalents. However, these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A cross-process data parsing method, characterized in that: Applied to a first controller, a first process is deployed in the first controller, and the first process is a process to be debugged; the method includes: In response to a connection request initiated by a second process in a second controller, a registration table corresponding to a message format of a communication message to be transmitted is sent to a second process in the second controller; wherein the second process is a process for debugging other processes, and the connection request represents that the second process requests to establish a connection with the first process; and the registration table is used to indicate field format information of a field in the communication message to be transmitted; Acquire content information in a field in the communication message to be transmitted, and generate the communication message to be transmitted according to the acquired content information; The communication message to be transmitted is transmitted to the second process in the second controller; wherein the communication message to be transmitted is used to perform data parsing based on the registration table acquired by the second process.

2. The method according to claim 1, characterized in that Acquiring content information in a field in the communication message to be transmitted, including: In response to the periodic event, obtaining content information in a field in the communication message to be transmitted; Alternatively, in response to a specific event, content information in a field in the communication message to be transmitted is obtained.

3. The method according to claim 1, characterized in that Transmitting the communication message to be transmitted to the second process in the second controller includes: Encoding the communication message to be transmitted to obtain an encoded communication message; wherein the encoded communication message includes the communication message to be transmitted and attribute information of the communication message to be transmitted; the attribute information includes the length of the communication message and the message type of the communication message; The encoded communication message is transmitted to the second process in the second controller.

4. The method according to any one of claims 1 to 3, characterized in that The method further comprises: The field format information of the field in the communication message to be transmitted is obtained, and the registration table is generated according to the obtained field format information of the field.

5. The method according to claim 4, characterized in that Generating the registration table according to the acquired field format information of the field includes: Generate a field description object of the field according to the acquired field format information of the field; the field description object is a structure composed of multiple attribute information of the field; The registration table is generated according to the field description object of the field in the communication message.

6. The method according to claim 5, characterized in that The field description object includes at least one attribute information of the field name, field type name, field index, field type, field offset, field size and field repetition number; The field name represents the name of the field; the field type name represents the data type of the field; the field type includes an enumeration table of the data type of the field; The field index represents the sequence number of the field in the communication message; The field offset represents the offset of the content information in the continuous memory storing the communication message; The field size represents the data length of the content information; The field repetition count represents the length of the array when the field type of the field is an array.

7. The method according to claim 6, characterized in that Generating a field description object of the field according to the acquired field format information of the field, including: Get the field index and field offset of the field description object of the previous field; Write the value of the field index of the previous field, which is incremented by 1, into the field index of the field description object of the current field; The sum of the product of the field size of the current field and the field repetition count of the current field and the field offset of the previous field is calculated, and written into the field offset of the field description object of the current field.

8. The method according to claim 7, characterized in that The method further comprises: Adding the field index and the field description object of the current field to an index mapping table; the index mapping table represents the mapping relationship between the field index and the field description object; and / or, The field name and the field description object of the current field are added to a field name mapping table; the field name mapping table represents the mapping relationship between the field name and the field description object.

9. The method according to claim 5, characterized in that The step of generating the registration table according to the field description object of the field in the communication message comprises: Obtaining a message name corresponding to the message format of the communication message to be transmitted; The message name of the communication message to be transmitted and the field description object are written into the registration table.

10. A cross-process debugging method, characterized in that: Applied to a second controller, a second process is deployed in the second controller, and the second process is a process for debugging other processes. The method includes: Sending a connection request to a first process in a first controller, and receiving a registration table returned by the first process in the first controller; wherein the first process is a process to be debugged, and the connection request represents that the second process requests to establish a connection with the first process; the registration table is used to indicate field format information of fields in a communication message to be transmitted; receiving the communication message to be transmitted sent by the first process in the first controller; wherein the communication message to be transmitted is generated based on content information; The communication message to be transmitted is parsed according to the registration table.

11. The method according to claim 10, characterized in that The performing data parsing on the communication message to be transmitted according to the registration table includes: The encoded communication message to be transmitted is decoded to obtain the decoded communication message to be transmitted; wherein the encoded communication message includes the communication message to be transmitted and attribute information of the communication message to be transmitted; the attribute information includes the length of the communication message and the message type of the communication message.

12. The method according to claim 11, characterized in that The performing data parsing on the communication message to be transmitted according to the registration table includes: Obtaining a message name corresponding to the message format of the communication message to be transmitted; A field description object corresponding to the communication message to be transmitted is obtained from the registration table according to the message name; the field description object is a structure consisting of multiple attribute information of the field in the communication message to be transmitted.

13. The method according to claim 12, characterized in that The performing data parsing on the communication message to be transmitted according to the registration table includes: Traversing the field description objects corresponding to the communication message to be transmitted, and acquiring a character string of the field from the communication message to be transmitted according to the field description objects; The character strings of the fields corresponding to the communication message to be transmitted are connected to obtain a message character string, wherein the message character string represents content information of each field in the communication message.

14. The method according to claim 13, characterized in that The acquiring the character string of the field from the communication message to be transmitted according to the field description object includes: Obtaining the field offset, field size and field repetition count of the field from the field description object; When the number of repetitions of the field is 1, determining the starting position and the ending position of the field in the continuous memory of the communication message according to the field offset and the field size, and obtaining the character string of the field from the continuous memory of the communication message according to the starting position and the ending position; When the number of field repetitions is greater than 1, the starting position and the ending position of each repetition of the field are determined according to the number of field repetitions, the field offset and the field size, and the character string of each repetition of the field is obtained from the continuous memory of the communication message according to the starting position and the ending position.

15. The method according to any one of claims 10 to 14, characterized in that The method further comprises: According to the field index, query the field description object corresponding to the field index through the index mapping table; and / or, According to the field name, the field description object corresponding to the field name is queried through the field name mapping table.

16. A cross-process data analysis method, characterized in that: Applied to a third controller, the controller has a first process and a second process deployed therein, the first process is a process to be debugged, and the second process is a process for debugging other processes; the method comprises: The second process sends a connection request to the first process; wherein the connection request indicates that the second process requests to establish a connection with the first process; The first process sends a registration table corresponding to a message format of a communication message to be transmitted to the second process; wherein the communication message to be transmitted is a message that the first process needs to transmit, and the registration table is used to indicate field format information of a field in the communication message to be transmitted; The first process obtains content information in a field in the communication message to be transmitted, and generates the communication message to be transmitted according to the obtained content information; The first process sends the communication message to be transmitted to the second process; The second process performs data parsing on the communication message to be transmitted according to the registration table.

17. The method according to claim 16, characterized in that: Acquiring content information in a field in the communication message to be transmitted, including: In response to the periodic event, obtaining content information in a field in the communication message to be transmitted; Alternatively, in response to a specific event, content information in a field in the communication message to be transmitted is obtained.

18. The method according to claim 16, characterized in that: The first process sends the communication message to be transmitted to the second process, comprising: The first process encodes the communication message to be transmitted to obtain an encoded communication message; wherein the encoded communication message includes the communication message to be transmitted and attribute information of the communication message to be transmitted; the attribute information includes the length of the communication message and the message type of the communication message; The first process transmits the encoded communication message to the second process; The second process decodes the encoded communication message to be transmitted to obtain a decoded communication message to be transmitted.

19. The method according to any one of claims 16 to 18, characterized in that: The method further comprises: The first process obtains field format information of fields in the communication message to be transmitted, and generates the registration table according to the obtained field format information of the fields.

20. The method according to claim 19, characterized in that Generating the registration table according to the acquired field format information of the field includes: The first process generates a field description object of the field according to the acquired field format information of the field; the field description object is a structure composed of multiple attribute information of the field; The first process generates the registration table according to the field description object of the field in the communication message.

21. The method according to claim 20, characterized in that Generating a field description object of the field according to the acquired field format information of the field, including: The first process obtains the field index and field offset of the field description object of the previous field; The first process writes the value of the field index of the previous field, which is incremented by 1, into the field index of the field description object of the current field; The first process calculates the sum of the product of the field size of the current field and the field repetition count of the current field and the field offset of the previous field, and writes it into the field offset of the field description object of the current field.

22. The method according to claim 21, characterized in that The method further comprises: The first process adds the field index and the field description object of the current field to an index mapping table; the index mapping table represents a mapping relationship between the field index and the field description object; and / or, The first process adds the field name and the field description object of the current field to a field name mapping table; the field name mapping table represents a mapping relationship between the field name and the field description object.

23. The method according to claim 22, characterized in that The method further comprises: The second process queries the field description object corresponding to the field index through the index mapping table according to the field index; and / or, The second process searches the field description object corresponding to the field name through the field name mapping table according to the field name.

24. The method according to claim 20, characterized in that The step of generating the registration table according to the field description object of the field in the communication message comprises: The first process obtains a message name corresponding to a message format of the communication message to be transmitted; The first process writes the message name of the communication message to be transmitted and the field description object into the registration table.

25. The method according to claim 16, characterized in that The second process performs data parsing on the communication message to be transmitted according to the registration table, including: The second process traverses the field description object corresponding to the communication message to be transmitted, and obtains the character string of the field from the communication message to be transmitted according to the field description object; The second process connects the character strings of the fields corresponding to the communication message to be transmitted to obtain a message character string, where the message character string represents content information of each field in the communication message.

26. The method according to claim 16, characterized in that The performing data parsing on the communication message to be transmitted according to the registration table includes: The second process obtains a message name corresponding to the message format of the communication message to be transmitted; The second process obtains a field description object corresponding to the communication message to be transmitted from the registration table according to the message name; the field description object is a structure consisting of multiple attribute information of the field in the communication message to be transmitted.

27. A first controller, characterized in that: The first controller includes: a memory and a processor; The memory is used to store a computer program; the processor is used to implement the method according to any one of claims 1 to 9 according to the computer program stored in the memory.

28. A second controller, characterized in that: The second controller includes: a memory and a processor; The memory is used to store a computer program; and the processor is used to implement the method according to any one of claims 10 to 15 according to the computer program stored in the memory.

29. A third controller, characterized in that: The third controller includes: a memory and a processor; The memory is used to store a computer program; the processor is used to implement the method according to any one of claims 16 to 26 according to the computer program stored in the memory.

30. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, which, when executed by a processor in a first controller, is used to implement a method as described in any one of claims 1 to 9; or, when executed by a processor in a second controller, is used to implement a method as described in any one of claims 10 to 15; or, when executed by a processor in a third controller, is used to implement a method as described in any one of claims 16 to 26.

31. A computer program product, characterized in that The computer program product includes a computer program, which, when executed by a processor in a first controller, is used to implement the method as described in any one of claims 1 to 9; or, when executed by a processor in a second controller, is used to implement the method as described in any one of claims 10 to 15; or, when executed by a processor in a third controller, is used to implement the method as described in any one of claims 16 to 26.

Images