A configuration-driven data parsing method, device, equipment and medium

Abstract

The application discloses a configuration-driven data analysis method and device, equipment and medium, and relates to the technical field of data processing. The method comprises the following steps: extracting data packet identification information and field analysis information from an interface control file according to a pre-configured field mapping relationship, and generating a standardized protocol description file; constructing a protocol analysis model comprising at least one set of mutually associated data packet identification information and field analysis information based on the standardized protocol description file; receiving a data packet to be analyzed, and matching the data packet to be analyzed with the data packet identification information in the protocol analysis model to determine target field analysis information corresponding to the data packet to be analyzed; and extracting and converting field data according to a field position and a data type to obtain an analysis result. Through the technical scheme of the application, protocol definition and business code can be decoupled, and the access efficiency, analysis reliability and maintenance efficiency of heterogeneous protocols can be improved.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a configuration-driven data parsing method, apparatus, device, and medium. Background Technology

[0002] In data-intensive systems, such as avionics, satellite communications, autonomous vehicles, and industrial control systems, different subsystems exchange data via predefined Interface Control Documents (ICDs). ICDs detail the format of data packets, including complex rules such as field offsets, data types, endianness, scale (dimensions), and time-division multiplexing. Traditionally, parsing these protocols heavily relies on developers manually writing code—hard-coded parsing. However, with the expansion of system scale and the increase in the number of devices, ICD version iterations are frequent. Hard-coding means that each protocol change requires modifying the source code, recompiling, repackaging, and deploying the entire application, resulting in extremely high maintenance costs and a high risk of errors. To alleviate this problem, the industry has introduced various alternatives, such as using Interface Definition Language (IDL) middleware (e.g., CORBA, Apache Thrift, Protocol Buffers) to define protocols and automatically generate parsing code; using Enterprise Service Bus (ESB) for visual data mapping configuration; or embedding scripting languages ​​or rule engines to achieve a degree of dynamism. These solutions achieve a certain degree of separation between protocol definition and business logic, but each has its own limitations: CORBA and ESB architectures are cumbersome, Thrift / Protobuf still requires compile-time binding, and script-based solutions rely on manually writing parsing logic. Therefore, there is an urgent need for a general data parsing method that can completely decouple protocol definition from program code, support runtime hot reloading, and has a high degree of automation, in order to reduce development and maintenance costs and improve the fault tolerance and stability of the system. Summary of the Invention

[0003] In view of this, the purpose of this invention is to provide a configuration-driven data parsing method, apparatus, device, and medium, which can solve the problem of repeated code modifications required due to protocol changes in traditional data parsing. The specific solution is as follows: Firstly, this application discloses a configuration-driven data parsing method, including: An interface control file is obtained, and packet identification information and field parsing information are extracted from the interface control file according to a pre-configured field mapping relationship to generate a standardized protocol description file; wherein, the standardized protocol description file includes at least one set of interrelated packet identification information and field parsing information; the field mapping relationship is used to characterize the correspondence between the source field names in the interface control file and the packet identification information or the field parsing information; Based on the standardized protocol description file, a protocol parsing model is constructed that includes at least one set of interrelated packet identification information and field parsing information; Receive the data packet to be parsed and match it with the data packet identification information in the protocol parsing model to determine the target field parsing information corresponding to the data packet to be parsed; Based on the field position in the target field parsing information, field data is extracted from the data packet to be parsed, and the field data is converted according to the data type in the target field parsing information to obtain the parsing result of the data packet to be parsed.

[0004] Optionally, the step of obtaining the interface control file and extracting packet identification information and field parsing information from the interface control file according to the pre-configured field mapping relationship to generate a standardized protocol description file includes: Obtain the interface control file in tabular form and load the field mapping table stored in the structured configuration file; the field mapping table records the correspondence between preset field names and source field names in one or more tabular interface control files; The header of the interface control file is matched according to the field mapping table to extract the data packet identification information of each data packet and the field parsing information of each field from the matched columns. According to a preset unified format, the extracted data packet identification information and field parsing information are output as a standardized protocol description file that is independent of the source of the interface control file.

[0005] Optionally, the step of constructing a protocol parsing model based on the standardized protocol description file, including the at least one set of interrelated packet identification information and field parsing information, includes: During the main program initialization and startup phase, the standardized protocol description file is parsed, a data packet protocol node is created for each data packet, and a field parsing node associated with the data packet protocol node is created for each field in the data packet. The data packet protocol node and the field parsing node are connected in a unidirectional chain structure, and a retrieval entry point for the data packet protocol node is established based on the data packet identification information to obtain a protocol parsing model that can be traversed and retrieved.

[0006] Optionally, the data packet identification information includes one or more identification locations and preset identification values ​​corresponding to each identification location; correspondingly, a data packet to be parsed is received and matched with the data packet identification information in the protocol parsing model to determine the target field parsing information corresponding to the data packet to be parsed, including: Traverse each data packet protocol node in the protocol parsing model; For the current data packet protocol node, extract single-byte or multi-byte matching identification values ​​from the data packet to be parsed according to each identification position, and compare each matching identification value with the preset identification value corresponding to the identification position in sequence; When all the identification values ​​to be matched corresponding to the current data packet protocol node match the preset identification value, the current data packet protocol node is determined as the target data packet protocol node; The target field parsing node is determined based on the target data packet protocol node, and the target field parsing node is identified as the target field parsing information.

[0007] Optionally, the field parsing information includes field position, data type, byte order information, dimensional coefficient, and time-division multiplexing information; the time-division multiplexing information is used to characterize the different sub-protocols corresponding to the same field position under different time-division identification values; correspondingly, based on the field position in the target field parsing information, field data is extracted from the data packet to be parsed, and the field data is converted according to the data type in the target field parsing information to obtain the parsing result of the data packet to be parsed, including: Based on the field position in the target field parsing information, extract the field data from the data packet to be parsed, and determine the byte length of the field data according to the data type in the target field parsing information; Based on the byte order information in the target field parsing information, the bytes in the field data are arranged, and the arranged field data is converted into field values; The physical value is obtained by converting the numerical value of the target field using the dimensional coefficients in the parsed information, and the physical value is used as the parsing result of the data packet to be parsed.

[0008] Optionally, when the target field parsing information contains the time-division multiplexing information, the method further includes: Obtain the target time-division identification value from the data packet to be parsed, determine the corresponding target sub-protocol based on the target time-division identification value, and parse the corresponding fields in the data packet to be parsed according to the field parsing information defined in the target sub-protocol.

[0009] Optionally, after obtaining the parsing result of the data packet to be parsed, the method further includes: The data packet to be parsed is stored in the receive buffer corresponding to the target data packet protocol node, and the physical value is stored in a separate parsing value cache; Update the target data packet protocol node's receive timestamp, total number of data packets received, valid data packet count, and data validity flag; Update the validity flag of the parsing result based on whether the time difference between the current time and the received timestamp exceeds a preset valid time threshold; The receive buffer and the parsed value cache are updated through a mutual exclusion access mechanism or a lock-free queue, and after the update is completed, a data update notification is sent to the service modules that subscribe to the parsed results through a semaphore or an event.

[0010] Optionally, the configuration-driven data parsing method further includes: The actual length of the data packet to be parsed is compared with the data packet length specified in the standardized protocol description file. If the actual length is less than the specified data packet length, the data packet to be parsed is recorded as an invalid data packet, the invalid data packet count is incremented, and parsing of the data packet to be parsed is stopped. For the field to be extracted, determine whether the offset of the field to be extracted exceeds the actual length. If it exceeds the actual length, discard the data packet to be parsed and record the parsing error. When the standardized protocol description file includes packet-level byte order information indicating whether the entire data packet is big-endian, the packet-level byte order information is applied to each field in the data packet to be parsed that does not have separately configured field-level byte order information.

[0011] Optionally, the configuration-driven data parsing method further includes: The system receives a subscription request carrying a first data packet name and a first field name, searches for first field parsing information in the protocol parsing model based on the first data packet name and the first field name, obtains first field data from the receiving buffer based on the first field parsing information, converts the first field data into a physical value, and returns it to the subscriber. Receive a publishing request carrying a second data packet name, a second field name, and a value to be published; search for second field parsing information in the protocol parsing model according to the second data packet name and the second field name; convert the value to be published into second field data according to the second field parsing information; and write the second field data into the sending buffer to generate a data packet to be sent. The receive buffer and the send buffer are independent of each other.

[0012] Optionally, after writing the second field data into the transmission buffer to generate the data packet to be transmitted, the method further includes: Obtain the sending strategy configuration corresponding to the data packet to be sent, and construct a sending strategy model based on the sending strategy configuration; The sending strategy model determines the sending mode corresponding to the data packet to be sent, and the sending task of the data packet to be sent is executed according to the sending mode; the sending mode includes one of the following: event-triggered single sending mode, quantitative sending mode with specified number of sending times, periodic sending mode with custom sending time interval, and fast and slow packet segmented sending mode based on different refresh frequencies; Obtain the sending result of the sending task, and update the execution status of the sending mode based on the sending result; When the sending task is completed, the execution status of the sending mode is updated to the completed state. When the preset resending conditions are met, the execution status of the sending mode is updated from the completed state to the pending state to wait for the next sending task.

[0013] Secondly, this application discloses a configuration-driven data parsing device, comprising: A standard file generation module is used to obtain an interface control file and extract packet identification information and field parsing information from the interface control file according to a pre-configured field mapping relationship to generate a standardized protocol description file; wherein, the standardized protocol description file includes at least one set of interrelated packet identification information and field parsing information; the field mapping relationship is used to characterize the correspondence between the source field names in the interface control file and the packet identification information or the field parsing information; The protocol parsing model construction module is used to construct a protocol parsing model based on the standardized protocol description file, including at least one set of interrelated data packet identification information and field parsing information; The matching and identification module is used to receive the data packet to be parsed and match it with the data packet identification information in the protocol parsing model to determine the target field parsing information corresponding to the data packet to be parsed. The parsing module is used to extract field data from the data packet to be parsed according to the field position in the target field parsing information, and to convert the field data according to the data type in the target field parsing information to obtain the parsing result of the data packet to be parsed.

[0014] Thirdly, this application discloses an electronic device, which includes a processor and a memory; wherein the memory is used to store a computer program, which is loaded and executed by the processor to implement the aforementioned configuration-driven data parsing method.

[0015] Fourthly, this application discloses a computer-readable storage medium for storing a computer program; wherein the computer program, when executed by a processor, implements the aforementioned configuration-driven data parsing method.

[0016] The beneficial effects of this application are as follows: By acquiring different interface control files and converting them into a standardized protocol description file of a unified format according to pre-configured field mapping relationships, a unified conversion from arbitrary format input protocol definitions to standardized descriptions is achieved, thus reducing dependence on specific interface control file formats and field naming methods. Based on this, the generated standardized protocol description file is loaded as a protocol parsing model containing packet identification information and its corresponding field parsing information. Upon receiving the packet to be parsed, the applicable target field parsing information is first determined based on the packet identification information, and then field extraction and conversion are completed according to the field position and data type. Therefore, the packet identification and field parsing process can be driven by the standardized protocol description file without writing any specific protocol parsing code for different packets. Thus, when the packet format, field position, or data type changes, the interface control file, field mapping relationships, or standardized protocol description file can be adjusted to adapt to the corresponding changes, reducing the repetitive writing and modification of parsing code, lowering the probability of errors in field position processing and data type conversion, and improving the adaptability and maintenance efficiency of the data parsing method to different data protocols. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0018] Figure 1 This is a flowchart of a configuration-driven data parsing method disclosed in this application; Figure 2 This is a flowchart of a protocol conversion tool disclosed in this application; Figure 3 This is a data structure diagram of the field mapping table and the standardized protocol description file disclosed in this application; Figure 4 This is a schematic diagram of a memory core data structure disclosed in this application; Figure 5 This application discloses a flowchart of a protocol description file dynamic loading process. Figure 6This application discloses a flowchart of a real-time data packet matching and memory buffer update process based on frame identification codes. Figure 7 This is a core class structure diagram of a data packet matching and parsing method disclosed in this application; Figure 8 This application discloses a general data parsing and subscription / publishing interaction flowchart based on ICD conversion. Figure 9 This application discloses a data subscription and publishing interaction flowchart; Figure 10 This is an overall flowchart of a general data parsing method disclosed in this application; Figure 11 This is a flowchart comparing a traditional hard-coded transmission strategy and a configuration-driven strategy engine disclosed in this application. Figure 12 This is a state diagram of a data packet transmission mode disclosed in this application; Figure 13 This is a runtime interaction sequence diagram of a configuration-driven sending strategy engine disclosed in this application; Figure 14 This application discloses an overall data flow and architecture flowchart; Figure 15 This is a schematic diagram of the structure of a configuration-driven data parsing device disclosed in this application; Figure 16 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] Currently, data-intensive systems such as avionics and autonomous driving rely on ICD (Interface Design Code) files to standardize cross-subsystem data packet formats. Traditional hard-coding suffers from high maintenance costs, requires recompilation and deployment, and is prone to introducing errors when facing frequent ICD iterations. Existing alternatives, such as those based on IDL middleware, ESB (Enterprise Service Block), or script engines, can separate protocols from business logic, but still fall short of meeting the system's requirements for efficient and flexible data processing. Specifically: (1) Hard-coded parsing: Hard-coded parsing is the most basic method for parsing data protocols. Developers write byte-by-byte parsing logic directly for specific ICD formats when writing business code. For example, for binary data packets, the code reads a fixed length of data at a specified offset using pointers or array indices and converts it to integer, floating-point, or other data types. For JSON or XML protocols, the code directly accesses specific field names to retrieve values. All protocol details, such as field offsets, data types, units (LSB values), endianness, and bitmasks, are fixed in the source code as constants or hard-coded statements. When the system runs, whenever it receives a raw data stream, the program executes these pre-defined parsing instructions, extracting various signal values ​​for subsequent business logic. This approach is direct, does not rely on any third-party middleware, and allows for rapid deployment of small systems with simple protocols and minimal changes.

[0021] The most significant drawback of hard-coded parsing lies in the strong coupling between the protocol definition and the program code. Once the ICD (Interface Code) is modified—for example, by adding a new field, adjusting the offset of an existing field, or changing the unit of measurement—developers must locate the relevant code segment, manually modify the parsing logic, and then recompile, package, and deploy the entire application. This process is not only time-consuming but also prone to introducing bugs such as offset calculation errors and inconsistencies in endianness handling due to human error. In a continuously running system, each protocol change means downtime or version upgrades, reducing system availability and flexibility. Furthermore, hard-coded parsing cannot achieve code reuse; each new protocol requires writing a new set of parsing logic from scratch, significantly increasing development workload and maintenance costs.

[0022] (2) CORBA (Common Object Request Broker Architecture): CORBA is a distributed computing standard proposed by the Object Management Organization, using IDL (Independent Language Demonstration) to describe service interfaces and data structures. Developers need to define the structure of all data types (including field names, types, order, nesting relationships, etc.) in the IDL file, and then the IDL compiler automatically generates stubs and skeletons in the corresponding programming language. This generated code contains the data serialization and deserialization logic. When the client or server needs to parse data, it can directly call the generated code without manually writing the parsing details. CORBA achieves a certain degree of separation between protocol definition and business logic: protocol definitions are centralized in the IDL file, and the compiler is responsible for generating the parsing code.

[0023] CORBA's limitations lie in its extremely complex configuration process and cumbersome system. IDL syntax rules are strict, requiring adherence to complex modules and interfaces when defining data structures. Furthermore, the ORB (Object Request Broker) runtime environment includes multiple components such as naming services and object adapters, resulting in significant deployment and maintenance overhead. More importantly, any change to the IDL file necessitates rerunning the compiler to generate new stub / skeleton code, recompiling and linking this code into the application, and then redeploying the entire system. This entire process cannot achieve runtime hot updates, failing to meet the demands of rapid iteration. In addition, CORBA has high resource requirements, making it unsuitable for embedded or lightweight cloud-native environments, and it lacks sufficient support for industrial protocol details such as binary bit-level operations and time-division frames, requiring additional coding.

[0024] (3)Apache Thrift / Protocol Buffers (gRPC): Apache Thrift and Protocol Buffers (Protobuf) are widely used serialization frameworks in modern distributed systems. They describe data structures and service interfaces by writing structured schema files (.thrift or .proto). Developers define the field names, types, and numbers for each message in these files, and then use their respective code generation tools (thrift or protoc) to automatically generate data access classes, serialization, and deserialization code in the corresponding programming language. In the business logic, developers directly call these automatically generated classes and methods to pack and unpack data, without manually handling byte offsets. This approach extracts protocol definitions from business logic, improving code maintainability, and the generated code has good cross-language compatibility.

[0025] Although Thrift / Protobuf achieves separation of protocol definition and code generation, in traditional usage, they still bind the protocol description file to the application's compilation process. When any changes occur to the .proto or .thrift file (such as adding fields or modifying types), developers must rerun the code generator, integrate the newly generated source code into the project, and then recompile and deploy the entire service. This process cannot achieve hot updates with zero code changes, and each protocol iteration involves a complete build cycle, increasing version management complexity. Furthermore, these frameworks are primarily designed for structured serialization and do not natively support common industrial protocol processing needs such as byte-by-byte offset parsing, time-division frame judgment, and custom unit conversion. Therefore, when dealing with complex ICDs, additional adaptation code still needs to be written.

[0026] (4) Data mapping in traditional ESB (Enterprise Service Bus): Enterprise Service Bus (ESB) is a core integration middleware in traditional service-oriented architectures, such as Oracle OSB and IBM Integration Bus. In an ESB, administrators can define data mapping rules through a visual interface or XML-based configuration files, dragging and dropping or configuring fields from the source system (e.g., XML format in system A) to correspond to fields in the target system (e.g., JSON format in system B). The ESB runtime engine automatically performs data format conversion, routing, and filtering based on these mapping rules. This approach achieves physical separation between protocol conversion logic and specific business code—mapping rules exist as configuration, and modifications do not require changes to the business code. ESBs typically also provide additional features such as message queues and load balancing, making them suitable for enterprise-level system integration scenarios.

[0027] The main limitations of traditional ESB solutions lie in their low level of automation and cumbersome architecture. When a new protocol or ICD is added, administrators often need to manually create new mapping tasks in the ESB console, defining field mappings through tedious GUI (Graphical User Interface) operations or by manually writing XSLT (Extensible Stylesheet Language Transformations) scripts. For complex systems containing hundreds of data packets, manual mapping is time-consuming and prone to errors. As a standalone middleware system, ESB itself comprises multiple components, resulting in high deployment and maintenance costs and consuming significant computing resources, making it unsuitable for lightweight or edge computing scenarios. Furthermore, most traditional ESBs require a service restart after updating mapping rules to take effect, failing to achieve hot-swapping; they also lack flexibility when handling low-level parsing details such as binary bit-level operations and time-division frames, typically requiring custom code.

[0028] (5) Parsing based on scripts or rule engines: In systems with high dynamic requirements, developers embed scripting language interpreters (such as Lua and Python) or rule engines (such as Drools) to parse data packets. Specifically, for each protocol, a corresponding parsing script or rule file is written, and a calling interface is reserved in the main program. When the system receives raw data, the main program passes the data to the script interpreter or rule engine, which is responsible for extracting fields, performing type conversions, and making business judgments. The advantage of this approach is that the parsing logic is physically separated from the main program code. Modifying the script does not require recompiling the main program; simply replacing the script file takes effect immediately, improving flexibility.

[0029] While script-based or rule-engine-based solutions are more flexible than hard-coding, they essentially distribute the parsing work across numerous manually written script files. When a system interfaces with a large number of protocols (e.g., avionics systems may contain thousands of different data packets), each script requires manual writing, testing, and version management, drastically increasing maintenance costs. The quality of script writing depends on the individual developer's skill; inconsistent script styles can easily introduce logical errors. Scripting languages ​​are typically interpreted, resulting in lower performance than compiled code and limited support for binary bit-level operations. Rule engines themselves are designed for business rules and are not adept at handling low-level byte offsets and unit conversions. Therefore, in practice, a mix of scripts and hard-coding is often necessary, not completely eliminating the reliance on manual coding. Furthermore, script-based solutions have weak error handling capabilities; spelling errors or logical errors in a script often only surface at runtime, making them difficult to prevent through compile-time checks.

[0030] In summary, existing alternatives suffer from limitations such as bloated architecture, dependency on compile-time binding, or the need for manually written parsing logic. To address these limitations, this application provides a configuration-driven data parsing solution. This solution employs a "configuration-driven" design philosophy, completely decoupling protocol definitions from business logic to achieve highly dynamic and automated data parsing, subscription, and publishing. This solution can be widely applied in scenarios requiring efficient and dynamic parsing of complex binary or hybrid protocols, such as aerospace, automotive electronics, and industrial automation. It is particularly suitable for environments where interface control files are frequently iterated and systems need to quickly adapt to new protocols.

[0031] This invention discloses a data parsing method for configuration drivers, see [link to relevant documentation]. Figure 1 As shown, the method includes: Step S11: Obtain the interface control file, and extract packet identification information and field parsing information from the interface control file according to the pre-configured field mapping relationship to generate a standardized protocol description file; wherein, the standardized protocol description file includes at least one set of interrelated packet identification information and field parsing information; the field mapping relationship is used to characterize the correspondence between the source field name in the interface control file and the packet identification information or the field parsing information.

[0032] In this embodiment, the interface control file of the system to be accessed is first obtained. An interface control file (ICD) is a standardized document used in data-intensive systems to define the data exchange format between subsystems. In engineering practice, interface control files are often exported as heterogeneous spreadsheet documents (e.g., Excel format) by different specialized tools, and different tools, or even different versions of the same tool, may use different column names for fields with the same semantic meaning.

[0033] To eliminate the aforementioned heterogeneity, this invention introduces a pre-configured field mapping relationship. This mapping relationship characterizes the correspondence between source field names in the interface control file and the packet identification information or the field parsing information. Specifically, this field mapping relationship is a standardized configuration table that predefines the mapping correspondence between standard field names used internally by the system and source field names that may actually appear in one or more interface control file formats. Packet identification information and field parsing information, as two core elements defined in the protocol of this invention, each have a specific column position in the interface control file, identified by the corresponding source field name. Through the field mapping relationship, the system can identify the semantic meaning carried by different named source field names, uniformly map them to standard field names, and thus correctly locate and extract the packet identification information and field parsing information of each packet from the interface control file.

[0034] In this embodiment, packet identification information refers to protocol information that can distinguish one packet from other packets, and may include one or more identification locations, identification lengths, and preset identification values. Field parsing information refers to the information required to locate and convert fields from the packet, and may include field name, field position, data type, byte length, byte order information, dimensional coefficients, bit field parameters, and time-division multiplexing information, etc. After extraction, the above information is output as a standardized protocol description file according to the system's preset unified format. This file is a unified structure file independent of the interface control file source, and can be in JSON, XML, YAML, or other structured formats that can be parsed by the program.

[0035] This step converts original protocol definition files from any source and in any format into standardized protocol description files with a unified format, laying the foundation for dynamic loading and universal parsing of subsequent protocol definitions and realizing the transformation of heterogeneous protocol definitions into unified descriptions.

[0036] Step S12: Construct a protocol parsing model based on the standardized protocol description file, which includes at least one set of interrelated packet identification information and field parsing information.

[0037] After the standardized protocol description file is generated, the system reads this file during the startup phase or the loading phase during operation and constructs a protocol parsing model accordingly. This protocol parsing model is a protocol definition image stored in system memory as a searchable data structure. Specifically, the protocol parsing model records the protocol parsing rules for each data packet contained in the standardized protocol description file. It at least associates and stores the data packet identification information and its corresponding field parsing information for each data packet, enabling the system to quickly locate its complete parsing rules for any given data packet by retrieving the model. Once constructed, this model serves as the sole basis for all subsequent data parsing operations. The system's matching, parsing, and transformation of raw data all use this model as the data source, thus achieving a complete separation between protocol definition and program code.

[0038] Step S13: Receive the data packet to be parsed and match it with the data packet identification information in the protocol parsing model to determine the target field parsing information corresponding to the data packet to be parsed.

[0039] In a communication bus or data transmission link, the system continuously receives raw data streams from various sensors or subsystems. These data streams consist of several data packets, each potentially corresponding to a different protocol type. When the system receives a data packet to be parsed, it first needs to determine the protocol definition followed by that packet, i.e., which set of protocol parsing rules it belongs to, as recorded in the protocol parsing model constructed in step S12. To this end, this step matches the feature information in the data packet to be parsed with the data packet identification information of each data packet in the protocol parsing model.

[0040] The packet identification information defines the criteria for determining the packet type. For example, it may include a fixed feature value at a specified offset position. The system extracts features from the corresponding identification position of the packet to be parsed and compares them with its corresponding preset identification value to determine the protocol type of the packet. A successful match means that the system has located the target field parsing information corresponding to the packet to be parsed in the protocol parsing model, thus providing accurate rules for subsequent field extraction and data conversion. This matching process is entirely driven by the configuration data in the protocol parsing model and does not involve any hard-coded judgment logic specific to any particular protocol.

[0041] Step S14: Extract field data from the data packet to be parsed according to the field position in the target field parsing information, and convert the field data according to the data type in the target field parsing information to obtain the parsing result of the data packet to be parsed.

[0042] This step performs actual data extraction and transformation operations on the data packet to be parsed based on the parsing rules recorded in the target field parsing information. Specifically, the system first locates and extracts the corresponding field data from the binary data stream of the data packet to be parsed based on the field positions recorded in the target field parsing information; then, according to the data type (e.g., integer, floating-point, unsigned character, etc.) recorded in the target field parsing information, the extracted field data is converted into numerical values ​​of the corresponding type.

[0043] The conversion process may also include byte order adjustment (e.g., swapping bytes based on endianness) and dimensional conversion (e.g., multiplying the original integer value by a dimensional coefficient to obtain a physical value) to restore the original binary data into a standardized data object with practical engineering meaning. The parsed result obtained after the above extraction and conversion operations can be directly used by upper-layer business modules, which do not need to concern themselves with details such as field offsets, byte order, or dimensional coefficients in the underlying protocol. Through this step, the system completes the entire conversion process from the original binary data stream to a standardized data object.

[0044] The beneficial effects of this application are as follows: By acquiring different interface control files and converting them into a standardized protocol description file of a unified format according to pre-configured field mapping relationships, a unified conversion from arbitrary format input protocol definitions to standardized descriptions is achieved, thus reducing dependence on specific interface control file formats and field naming methods. Based on this, the generated standardized protocol description file is loaded as a protocol parsing model containing packet identification information and its corresponding field parsing information. Upon receiving the packet to be parsed, the applicable target field parsing information is first determined based on the packet identification information, and then field extraction and conversion are completed according to the field position and data type. Therefore, the packet identification and field parsing process can be driven by the standardized protocol description file without writing any specific protocol parsing code for different packets. Thus, when the packet format, field position, or data type changes, the interface control file, field mapping relationships, or standardized protocol description file can be adjusted to adapt to the corresponding changes, reducing the repetitive writing and modification of parsing code, lowering the probability of errors in field position processing and data type conversion, and improving the adaptability and maintenance efficiency of the data parsing method to different data protocols.

[0045] In data-intensive fields such as aerospace, industrial control, and the Internet of Things (IoT), data interaction between different systems typically relies on Interface Control Files (ICDs) to define data structures. In traditional workflows, ICDs are exported to Excel format using specialized tools, containing crucial information such as packet byte offsets, field types, units, and frame identifiers. However, existing ICD tools generate Excel spreadsheets with a serious problem of inconsistent header names: different tools, and even different versions of the same tool, may use different column names for fields with the same semantics (e.g., "field name" might be expressed as "Name," "Field Name," or "parameter name"). This forces downstream protocol parsing code to be hard-coded for each Excel format. Whenever a new ICD tool is introduced or an existing tool is upgraded, developers need to rewrite or modify the parsing logic, increasing repetitive work and making it highly susceptible to field mapping errors due to human error. Furthermore, the hard-coding approach tightly couples protocol definitions with business code; any change to a protocol field (such as offset adjustments or adding a field) requires code modification and system redeployment, resulting in extremely poor flexibility. This embodiment provides a protocol conversion tool that automatically parses heterogeneous Excel-formatted ICDs. It utilizes a configurable field mapping table to eliminate header differences, achieving unified parsing and standardized output of heterogeneous ICD Excel files. Subsequent parsing is entirely handled by a unified engine, requiring no manual intervention. The core idea of ​​this tool is to establish a mapping relationship between fields in Excel files exported from different ICD tools that have the same semantics but different names, thereby automatically converting Excel files of any format into a unified JSON protocol description file within the system. Specifically, the process of generating the standardized protocol description file includes the following steps: Step 1: Obtain the interface control file in tabular form and load the field mapping table stored in the structured configuration file; the field mapping table records the correspondence between preset field names and source field names in one or more tabular interface control files; Step 2: Match the header of the interface control file according to the field mapping table to extract the data packet identification information and field parsing information of each data packet from the matched columns; Step 3: According to the preset unified format, output the extracted data packet identification information and the field parsing information as a standardized protocol description file that is independent of the source of the interface control file.

[0046] In this embodiment, upon startup, the tool first loads a predefined field mapping table (usually another JSON or XML file) stored in a structured configuration file. This table defines the correspondence between standard preset field names and the column names actually used by each ICD tool. For example, the preset field "name_en" might correspond to "Field Name" or "English Name". Subsequently, the tool reads the target Excel file, intelligently matches the semantics of each column based on the mapping table, and extracts the packet identification information of each data packet and the field parsing information of each field (including packet name, frame identification code, variable offset, data type, unit, bit field information, etc.). This information is output as a JSON file in a unified format. The generated JSON file is completely independent of any specific ICD tool and can be directly loaded by subsequent general-purpose data parsing engines without modifying any core code. This configuration-driven design means that when integrating a new protocol, only the field mapping table needs to be updated or a small amount of configuration needs to be adjusted, greatly reducing system integration costs and maintenance difficulty. Figure 2 The demonstration showcased the entire process of the protocol conversion tool, from loading the mapping table, reading Excel, intelligently matching column semantics, extracting data, to generating a unified JSON file, reflecting a configuration-driven and automated conversion mechanism.

[0047] Table 1 shows an exemplary field mapping table provided in this embodiment. It should be noted that the source field names in the table are merely examples, and the same preset field may correspond to more source names.

[0048] Table 1 Field Mapping Table

[0049] Figure 3 This describes the mapping between standard fields and source field names in the mapping table, as well as the structure of Config and ProtocolField in the converted JSON protocol description file. The mapping table maps different Excel headers to unified standard fields, ultimately generating a JSON file containing a Config array.

[0050] In summary, the core innovation of this embodiment lies in completely separating the definition of the Interface Control File (ICD) from the program code through a mechanism of "protocol conversion tool + standardized protocol description file". When the new ICD only changes the header name, only the field mapping table needs to be updated; when the protocol content changes, the conversion tool can be rerun to generate a new standardized protocol description file. After being replaced in the specified directory, the general parsing engine will automatically take effect when the next frame of data arrives. This process does not require modification, restart, or compilation of any core service code, realizing hot-plugging and dynamic loading of the protocol. In contrast, traditional hard-coded parsing and serialization frameworks such as Thrift / Protobuf still require code to be regenerated during compilation, while CORBA and ESB require cumbersome IDL compilation or visual mapping configuration. The design of this invention reduces the average processing time for protocol changes from several hours (code modification + compilation + deployment) to minutes (only updating the configuration file), significantly improving the system's response speed and deployment flexibility. Taking an avionics system as an example, assuming there are 500 data packets, each with an average of 20 fields, the hard-coded method would require approximately 10,000 lines of parsing code. In contrast, this invention only requires maintaining one mapping table (approximately 50 lines of configuration) and a one-time general-purpose engine code. Maintenance costs are reduced by over 90%, and problems such as offset calculation errors and inconsistencies in endianness caused by human coding negligence are completely eliminated.

[0051] In traditional embedded systems or distributed data communication scenarios, the parsing logic of data protocols is typically hard-coded into the application's source code. Whenever the Interface Control File (ICD) changes—for example, by adding data fields, adjusting byte offsets, modifying data types, or changing units—developers need to manually modify the corresponding parsing code, then recompile, link, and deploy the entire program. This approach not only leads to high development and maintenance costs but also easily introduces logical errors due to human coding oversights, reducing system robustness. Furthermore, when the system needs to interface with multiple heterogeneous protocols simultaneously or frequently update protocols, the hard-coded approach cannot achieve hot-swapping and dynamic updates of protocols, severely restricting the system's scalability and flexibility. Therefore, a mechanism is needed to completely separate protocol definitions from program code, enabling the main program to dynamically load and parse protocol descriptions of any format at runtime, thereby adapting to new data protocols without modifying the core code. This embodiment provides a dynamic loading mechanism based on standardized protocol description files and a corresponding core memory data structure. Specifically, it describes the implementation method of constructing a protocol parsing model from standardized protocol description files, including the following steps: Step 1: During the main program initialization and startup phase, parse the standardized protocol description file, create a data packet protocol node for each data packet, and create a field parsing node associated with the data packet protocol node for each field in the data packet; Step 2: Connect the data packet protocol node and the field parsing node in a unidirectional chain structure, and establish the retrieval entry point of the data packet protocol node based on the data packet identification information to obtain a protocol parsing model that can be traversed and retrieved.

[0052] In this embodiment, during the initialization and startup phase, the main program automatically loads and parses the standardized protocol description file pre-processed and generated by the protocol conversion tool. This file fully defines the frame identification code, length, variable field offset, data type, endianness, unit, and time-division frame logic of each data packet. After parsing, the system maps the protocol definition information of each data packet to a data packet protocol node in memory. The data packet protocol node contains at least the data packet identification information of that data packet. Simultaneously, the field parsing information of each field in each data packet is mapped to field parsing nodes under that data packet protocol node, with field parsing nodes under the same data packet protocol node being sequentially associated. Finally, the data packet protocol nodes are organized into a traversable and searchable protocol parsing model according to a predetermined structure (e.g., a singly linked list structure).

[0053] Specifically, in one implementation of the present invention, each data packet protocol node corresponds to a `pack_proto_buf` structure. This structure records attributes such as the frame identifier (defined by one or more identification positions and preset identification values ​​corresponding to each identification position), the protocol name `proto_name`, source and destination node information, and the data packet length `pack_len`, and holds a pointer to a linked list of all field parsing nodes under that data packet. Further, each field parsing node corresponds to a `type_value_config` structure, which records the parsing rules for all fields within the data packet. This structure may include field name, field position, data type (e.g., unsigned character, integer, floating-point), byte order information `is_big`, dimensional coefficient `lsb`, and time-division multiplexing information `is_fenshizhen`. For fields involving time-division multiplexing, an additional `fenshizhen` structure is used for identification and extension.

[0054] This design completely decouples protocol description from business logic: the loading process requires no writing or generation of any protocol-specific parsing code, relying solely on a general parsing engine to extract fields from the binary data stream based on the configuration chain in memory. When the ICD is updated, simply replacing the JSON file and triggering a reload of the main program achieves hot updates with zero code modification. Furthermore, this data structure provides an efficient retrieval entry point for subsequent packet matching, subscription, and publishing. By quickly locating the corresponding protocol node through the frame identification code array and then traversing the `type_value_config` linked list by variable name to obtain the parsing parameters of the fields, a high-performance and highly flexible foundation is laid for the entire data parsing process.

[0055] Figure 4 This section illustrates the core structures used for protocol parsing in the main program's memory and their relationships. In an example implemented in C or C++, the protocol parsing model can consist of structures such as `pack_proto_buf`, `type_value_config`, `fenshizhen`, and `CCS_Bus_Pkt`. These names are used to describe a feasible implementation and do not restrict other programming languages ​​or data structures. `pack_proto_buf` represents complete packet protocol information, including frame identifier, packet length, endianness flags, etc., and holds a pointer to the `type_value_config` linked list. `type_value_config` describes the parsing rules for each variable, including offset, type, unit, and bit count; if the variable is a time-division multiplexing field, the `fenshizhen` structure further identifies the time-division frame identifier and the corresponding sub-protocol. `CCS_Bus_Pkt` encapsulates the received raw data packets and can include a bus identifier `id`, a byte array `buf`, and the actual length `buf_len`. These structures are linked together via a singly linked list `next` pointer to form a dynamically searchable protocol parsing model.

[0056] Figure 5 This describes the process by which the main program dynamically loads the standardized protocol description file during initialization. First, it reads the standardized JSON file generated by the protocol conversion tool, then parses the configuration information, creating a `pack_proto_buf` node for each data packet and a `type_value_config` node for each variable. If a variable involves time-sharing (`is_fenshizhen` is true), a corresponding `fenshizhen` structure is created and linked to `type_value_config`. All nodes are connected via a singly linked list, ultimately forming an efficiently searchable memory protocol mapping for subsequent data matching and parsing. The entire process requires no modification to the core code, achieving hot-plugging of the protocol.

[0057] In summary, compared to CORBA (requires a complete ORB environment, often exceeding 200MB of memory) or ESB (usually requires a dedicated server, with processing latency of several milliseconds), this embodiment only requires maintaining a JSON configuration file and a set of C / C++ linked list traversal logic in an embedded or ordinary server. Memory usage is typically no more than tens of KB (depending on protocol complexity), and single-frame parsing time is in the microsecond range. This lightweight design makes it very suitable for resource-constrained embedded systems (such as drone flight control, vehicle ECU) and cloud-native microservice environments requiring rapid iteration. This invention natively supports time-division frames, bit field parsing, multiple data types (int / float / unsigned char, etc.), custom unit conversion (lsb), and endianness switching. These features are common requirements in aerospace, industrial automation, and other fields, while serialization frameworks such as Thrift / Protobuf require additional adaptation scripts to handle them. Through configuration, all complex parsing rules are described in JSON, requiring no special programming.

[0058] In distributed real-time systems, multiple sensors or subsystems send different data packets via a shared bus (such as CAN, serial port, or custom protocol). Traditionally, the main program typically needs to write specific receive callback functions for each data packet type, or hard-code the sequential judgment of message header identifiers. This approach has the following problems: 1) The increase in data packet types leads to a rapid expansion of the receive logic branches, making maintenance difficult; 2) When the data packet protocol (frame identification code, length, field position) changes, the receive code must be modified and recompiled, making hot updates impossible; 3) In asynchronous receive scenarios, the lack of a unified mechanism to quickly match the raw binary stream to the corresponding protocol description structure results in low data parsing efficiency and a high risk of errors. Furthermore, the lack of data packet validity verification (such as timeout and identification code integrity checks) makes system stability difficult to guarantee. Therefore, a mechanism is needed that can dynamically and efficiently match the received raw data packets with the pre-loaded protocol description in memory and update the standard data buffer in real time. Based on the aforementioned embodiments, this embodiment proposes a real-time data packet matching and memory buffer update mechanism based on frame identification codes. A general-purpose data parsing engine is provided for parsing data packets to be parsed after the arrival of raw binary stream data, in conjunction with a protocol parsing model. Specifically, it receives the data packets to be parsed and matches them with the data packet identification information in the protocol parsing model to determine the target field parsing information corresponding to the data packets to be parsed, including the following steps: Step 1: Traverse each data packet protocol node in the protocol parsing model; Step 2: For the current data packet protocol node, extract single-byte or multi-byte matching identification values ​​from the data packet to be parsed according to each identification position, and compare each matching identification value with the preset identification value corresponding to the identification position in sequence; Step 3: When all the identification values ​​to be matched corresponding to the current data packet protocol node match the preset identification value, the current data packet protocol node is determined as the target data packet protocol node; Step 4: Determine the associated target field parsing node based on the target data packet protocol node, and identify the target field parsing node as the target field parsing information.

[0059] In this embodiment, since the packet identification information contained in the packet protocol node is used to uniquely identify a type of packet, each packet protocol node corresponds to one packet type. Because different packet types are typically distinguished by different frame identification codes in the original data stream, this invention defines the packet identification information as a set of offset-value pairs (offset array and value array). Each offset-value pair specifies that the value extracted from one or more specific identification positions of the packet should be equal to a preset identification value. For a packet protocol node, its identification information may contain one or more offset-value pairs; the specific number (i.e., ident_num) is determined by the actual protocol definition of the packet.

[0060] When the main program receives a raw data packet to be parsed from the underlying driver layer (encapsulated as a CCS_Bus_Pkt structure containing members such as id, buf, and buf_len), it triggers the data packet matching process. This process is executed by the packet matcher, and the specific steps are as follows: First, the matcher calls the packet matching function to traverse each packet protocol node (pack_proto_buf) in the protocol parsing model. The protocol parsing model is built in memory during system initialization based on the standardized protocol description file. Each packet protocol node is organized in the form of a linked list, and each node contains a complete protocol definition for that packet type, including packet identification information (a set of offset-value pairs) and corresponding field parsing information.

[0061] Secondly, for the current packet protocol node being traversed, the matcher extracts a single-byte or multi-byte identification value to be matched from the corresponding identification position of the packet to be parsed, according to each offset-value pair in the packet identification information of that node, and compares the extracted value with the preset identification value corresponding to that identification position. Specifically, for the current node, its ident_num (number of frame identification codes) is read; the matcher iteratively processes each identification code index i (i from 0 to ident_num-1): from the packet buf, according to the identification position in the i-th offset-value pair, one byte or the data type corresponding to value[i] is extracted (usually a byte, expandable to multi-byte); the extracted value is compared with the corresponding preset identification value. If the comparison result of a certain offset-value pair is not equal, the current packet protocol node is immediately determined to be mismatched, further judgment of that node is terminated, and the next protocol node is checked.

[0062] Finally, if all `ident_num` offset-value pairs in the current data packet protocol node match successfully, meaning the value of the data packet at each specified offset position matches the corresponding preset value, then the data packet is determined to belong to the data packet type corresponding to the current protocol node. At this point, the matcher records a successful match and stops traversing subsequent nodes (assuming protocol uniqueness or priority support). The field parsing node corresponding to this data packet protocol node is then identified as the target field parsing information for use in subsequent parsing steps. If no match is found after traversing all protocol nodes, an invalid packet count (`invalid_count`) is recorded, and the data packet may be discarded or sent to the default processing flow.

[0063] In summary, this embodiment achieves dynamic identification and rule localization of data packet types through the offset-value pair-based matching mechanism described above. This mechanism offers the following technical advantages: First, the matching logic is entirely driven by the configuration data in the protocol parsing model, without involving any hard-coded judgments specific to any particular protocol. When the protocol definition changes, only the protocol description file needs to be updated and the model reloaded; the matching logic itself requires no modification. Second, it supports combined matching of multiple offset-value pairs, adapting to the varying complexity requirements of frame identification codes for different protocols. Third, the matching process employs a fast-failure strategy, immediately terminating the judgment of the current node and proceeding to the next node upon matching failure, ensuring matching efficiency. Fourth, this mechanism works in conjunction with the linked list structure in the protocol parsing model, providing an efficient and flexible retrieval entry point for the entire data parsing process.

[0064] Furthermore, once the target data packet protocol node is matched, the main program enters the parsing process, which specifically includes the following steps: Step 5: Extract field data from the data packet to be parsed according to the field position in the target field parsing information, and determine the byte length of the field data according to the data type in the target field parsing information; Step 6: Arrange the bytes in the field data according to the byte order information in the target field parsing information, and convert the arranged field data into field values; Step 7: Use the dimensional coefficients in the target field parsing information to convert the field value to obtain the physical value, and use the physical value as the parsing result of the data packet to be parsed.

[0065] In this embodiment, the head pointer of the value_config linked list of the target data packet protocol node is first obtained; then, each type_value_config target field parsing node in the linked list is traversed. Specifically, based on the field position (offset) in the target field parsing information, the original byte sequence is extracted from the buf of the data packet to be parsed as the field data. The data type (len) in the target field parsing information determines the byte length (e.g., unsigned char is 1 byte, int is 4 bytes, etc.).

[0066] In a preferred embodiment, field data conversion includes two sub-steps: byte order conversion and dimension conversion. First, the extracted field data is converted to byte order according to the byte order information (i.e., the endianness flag `is_big`) in the field's parsing information. The byte order information indicates the byte arrangement of the field in the data packet: big-endian (most significant byte first) or little-endian (least significant byte first). The system rearranges the byte order of the multi-byte field based on this information and converts the rearranged field data into a field value using an appropriate method (or through union / pointer conversion). Then, the obtained field value is multiplied by the dimension coefficient (LSB value, i.e., the physical unit represented by the least significant bit) in the target field's parsing information to obtain the corresponding physical value of the field. Through the above byte order conversion and dimension conversion operations, the original binary data is restored to a standardized value with a clear physical meaning, which can be directly used by upper-layer business modules without the business modules needing to concern themselves with the details of the underlying byte arrangement and dimension coefficients.

[0067] As described above, field parsing information includes field position, data type, byte order information, and dimensional coefficients, as well as time-division multiplexing information. This time-division multiplexing information is a common data organization format in complex industrial protocols such as aerospace, used to characterize different sub-protocols corresponding to the same field position under different time-division identification values. Specifically, a field may represent one meaning in one situation and a completely different meaning in another, depending on the value of a time-division identification value preceding or within that field.

[0068] It should be noted that when the system detects time-division multiplexing information in the target field parsing information during the parsing process (is_fenshizhen is non-zero), it further matches the time-division frame logic (refer to the fenshizhen linked list). Specifically: the target time-division identification value is obtained from the data packet to be parsed. Based on the target time-division identification value, the corresponding time-division sub-protocol is matched in the sub-protocol mapping table recorded in the time-division frame structure. Each time-division sub-protocol independently defines the field parsing rules (including field offset, data type, and unit) corresponding to that time-division identification value. After a successful match, the corresponding target sub-protocol is determined, and the corresponding fields in the data packet to be parsed are parsed according to the field parsing information defined in the target sub-protocol. If the time-division identification value does not match any sub-protocol, it is processed according to the default parsing rules or an exception is recorded.

[0069] Through the above-mentioned time-division frame processing mechanism, the present invention can natively support time-division multiplexing scenarios in complex industrial protocols without writing additional condition judgment code for each time-division case. All time-division logic is defined in a configuration manner in the standardized protocol description file.

[0070] Furthermore, in one feasible implementation, after obtaining the parsing result of the data packet to be parsed, the following steps are also included: Step 8: Store the data packet to be parsed into the receive buffer corresponding to the target data packet protocol node, and store the physical value into a separate parsing value cache; Step 9: Update the target data packet protocol node's receive timestamp, total number of data packets received, valid data packet count, and data validity flag; Step 10: Update the validity flag of the parsing result based on whether the time difference between the current time and the received timestamp exceeds a preset valid time threshold; Step 11: Update the receiving buffer and the parsed value cache through a mutual exclusion access mechanism or a lock-free queue, and after the update is completed, send a data update notification to the service modules that subscribe to the parsed results through a semaphore or event.

[0071] In this embodiment, each pack_proto_buf node contains a CCS_Bus_Pktpkt_buf member, which is used to cache the original packet content of the most recently received packet to be parsed (the maximum buffer length is usually 1056 bytes). At the same time, the parsed physical values ​​can be stored in a separate parsed value cache (e.g., a double array, arranged in variable order) or managed through a global hash table.

[0072] After storing the final physical values ​​in a buffer corresponding to the variable names (for example, a memory table can be used to record the latest value for each packet-variable name), the system updates the target packet protocol node's receive timestamp: recv_time, as well as recv_ananasy_time (seconds) and recv_ananasy_time_mili (milliseconds) time information. It also increments the total number of received packets (count) and the valid packet count (valid_count), and sets the data validity flag (is_valid) to valid. Finally, the system checks the timeliness of the packets. It updates is_time_valid based on whether the difference between the current time and recv_time exceeds the preset valid time threshold (valid_time). If it exceeds the threshold, is_time_valid is set to invalid; otherwise, it is valid.

[0073] In this embodiment, to support asynchronous subscription and publication, the update operation requires locking (such as a mutex lock) or the use of a lock-free queue to ensure thread safety. After updating the buffer, the main program can notify subscribers of new data arrival via semaphores or events.

[0074] In summary, in this embodiment, the general parsing engine extracts and performs physical value conversions on the original data field by field based on the value_config linked list in the node (each field's offset, type, endianness, and unit are defined by the type_value_config structure), and updates the results to the node's built-in pkt_buf or the user-specified receive buffer. The entire process requires no hard-coded checks, is entirely driven by the configuration file, and supports timestamp recording and validity verification of data packets (such as valid_timeout checks). This mechanism allows secondary developers to adapt to new data packets simply by updating the protocol description file, achieving hot-plug reception with zero code modification.

[0075] Figure 6This demonstrates the complete process of the main program from receiving raw data frames to finally updating the memory buffer. First, it receives data frames, then traverses the pre-loaded protocol list, matching the frame identifier's offset-value pairs. Upon successful matching, it parses the raw data field by field according to the protocol's field definitions (offset, type, endianness, units, etc.), processes the time-division frame logic, converts physical values, updates the buffer, timestamp, and validity flag, checks the packet length and timeliness, and finally notifies subscribers. The entire process is driven by a configuration file and requires no hard-coding.

[0076] Figure 7 This illustrates the relationship between the core data structures for packet matching and parsing. `pack_proto_buf` is a protocol linked list node containing an array of frame identifiers, the protocol name, source and destination nodes, a variable configuration linked list head, raw packet buffers, and statistics. `type_value_config` defines the parsing rules for each variable (offset, type, endianness, unit, time-division frame pointer). `fenshizhen` describes the identifier of the time-division frame and its corresponding protocol content. `CCS_Bus_Pkt` encapsulates the raw bus message. These structures work together to implement configuration-driven dynamic parsing.

[0077] Figure 8 The demonstration showcases the complete interactive process, starting with the ICD file provided by the developer, generating unified JSON through a protocol conversion tool, dynamically loading and parsing the data in real time by the parsing engine, and finally sending it to the business module through the message bus. This embodies the design philosophy of zero code modification and configuration-driven approach.

[0078] In a preferred embodiment, the present invention further includes an exception handling process, specifically: (1) Compare the actual length (buf_len) of the data packet to be parsed with the data packet length (pack_len) specified in the standard protocol description file. If the actual length is less than the specified data packet length, record the data packet to be parsed as an invalid data packet, increment the invalid data packet count (invalid_count), and stop parsing the data packet to be parsed; (2) Determine whether the offset of a field to be extracted during the parsing process exceeds the actual length. If it exceeds the actual length range, discard the data packet to be parsed and record the parsing error. (3) When the standardized protocol description file includes packet-level byte order information to indicate whether the entire data packet is big-endian, the packet-level byte order information is applied to each field in the data packet to be parsed that does not have separately configured field-level byte order information. That is, the is_highbit flag in the protocol configuration is used to indicate whether the entire data packet is big-endian, affecting the byte order parsing of all fields.

[0079] As can be seen, this embodiment uses a unified, general-purpose parsing engine to replace the scattered, hard-coded parsing logic, avoiding differences in style, boundary handling, and error handling between parsing code written by different developers, thus reducing runtime bugs at the source. Simultaneously, the in-memory protocol linked list structure supports frame identification code verification, packet length checking, and timeout detection (valid_time). Any abnormal data frames that do not conform to the protocol definition are recorded (invalid_count) and discarded, preventing abnormal data from polluting the business layer. This design significantly improves the system's mean time between failures (MTBF), especially in multi-sensor, high-noise industrial bus environments, effectively ensuring reliability. Through the above implementation, the main program can efficiently and accurately match and parse various data packets from the raw data stream, updating the memory buffer in real time, providing a reliable data foundation for subsequent subscription and publishing.

[0080] In traditional data parsing systems, business modules directly access and assign values ​​to underlying binary data, resulting in tight coupling between code and the protocol. Whenever the Interface Control Document (ICD) is updated, all subscription and publish logic related to that protocol must be modified synchronously, increasing development and maintenance workload and introducing potential coding errors. Furthermore, the lack of a unified data access abstraction layer forces business developers to have in-depth knowledge of protocol details, reducing development efficiency and system scalability. In this model, each protocol change requires rewriting parsing and encapsulation code across multiple business modules, making rapid iteration and system decoupling difficult. This embodiment provides a set of standardized asynchronous subscription and publish interfaces: CCS_Bus_Get_Value_By_Proto_Name_Asyn; CCS_Bus_Set_Value_By_Proto_Name_Asyn.

[0081] These interfaces, by passing in packet names and variable names, automatically parse or encapsulate the underlying binary stream using a standardized protocol description file dynamically loaded in the protocol parsing model. The packet name uniquely identifies a type of data packet (e.g., a protocol frame), and the variable name uniquely identifies a specific field within that data packet (e.g., a semaphore or parameter). Specifically, the configuration-driven data parsing method of this invention further includes the following steps: Step 1: Receive a subscription request carrying a first data packet name and a first field name; search for the first field parsing information in the protocol parsing model according to the first data packet name and the first field name; obtain the first field data from the receiving buffer according to the first field parsing information; convert the first field data into a physical value and return it to the subscriber. Step 2: Receive a publishing request carrying a second data packet name, a second field name, and a value to be published. Based on the second data packet name and the second field name, search for the second field parsing information in the protocol parsing model. Based on the second field parsing information, convert the value to be published into second field data and write the second field data into the sending buffer to generate a data packet to be sent.

[0082] In this embodiment, when subscribing to data, the interface searches the protocol parsing model built during system initialization based on the name of the first data packet, and locates the data packet protocol node corresponding to the packet name. Then, based on the name of the first field, it searches for the corresponding first field parsing information in the field parsing rule chain associated with the data packet protocol node. Finally, based on the found first field parsing information, it extracts the first field data from the storage location corresponding to the data packet in the receiving buffer, converts it into a field value according to the data type and byte order flag, multiplies it by a dimensional coefficient to obtain the physical value, and returns it to the caller in a standardized data type (e.g., double-precision floating-point number).

[0083] When publishing data, the operation is reversed. Internally, the interface retrieves the corresponding second field parsing information in the protocol parsing model based on the name of the second data packet and the name of the second field. Then, the input value to be published (double value) is inversely converted according to the unit (i.e., divided by the unit) to obtain the original field value. Then, the original field value is converted into the corresponding second field data according to the data type and byte order flag. Finally, it is written into the storage location corresponding to the data packet in the sending buffer according to the field position in the field parsing information, thereby completing the data encapsulation.

[0084] The receive buffer and the send buffer are independent of each other.

[0085] In this embodiment, secondary developers can obtain or set standardized double-type values ​​using only the package name and field name through the two asynchronous interfaces, CCS_Bus_Get_Value_By_Proto_Name_Asyn and CCS_Bus_Set_Value_By_Proto_Name_Asyn, without needing to concern themselves with underlying offsets, byte order, units, or other details. This completely decouples business code from protocol definitions, achieving standardized, unified, and dynamic data access. Business developers can focus on logic implementation without worrying about the underlying binary layout, reducing the onboarding time for new personnel from weeks to hours. Simultaneously, the interfaces maintain isolated receive and send buffers internally, ensuring no interference and supporting high-concurrency scenarios.

[0086] Figure 9This demonstrates the interaction process of secondary developers subscribing to and publishing data via an API. During subscription, the main program looks up the corresponding parsing rule (offset, unit, endianness, etc.) in the in-memory protocol linked list based on the passed package name and variable name. Then, it extracts the raw binary data from the receive buffer, converts it into a physical value, and returns it. During publishing, the main program converts the passed double value according to the same rules and writes it to the send buffer. The receive and send buffers are independent of each other, ensuring concurrency safety. The entire process requires no modification to the core code; it can dynamically handle arbitrary data protocols solely based on the protocol description in memory.

[0087] Figure 10 The three main steps of the general data parsing method are demonstrated: First, the protocol conversion tool converts traditional ICDs (such as Excel) into standardized JSON protocol files; second, the general data parsing engine loads this JSON file upon startup and constructs a linked list of protocol description structures centered on pack_proto_buf in memory; finally, when the raw data stream is received, the parsing engine matches data packets according to frame identification codes, unpacks them, and distributes the standardized data to business modules through a publish / subscribe mechanism. Business modules interact with the protocol descriptions in memory through a provided asynchronous interface (based on package name and variable name) to achieve data subscription and publication.

[0088] Furthermore, in traditional data distribution systems, data packet sending strategies are typically hard-coded into the business logic, such as fixed sending cycles or single triggering methods. This design lacks sufficient flexibility when facing changing business scenarios and system configurations. When it is necessary to adjust the sending frequency, triggering conditions, or number of times a data packet is sent, developers must modify the core code, recompile, and deploy the entire service. This not only increases maintenance costs but also reduces the system's adaptability and scalability. Especially in distributed systems and real-time signal interaction environments, the data exchange needs between different devices vary greatly (such as the coexistence of high-frequency control commands and low-frequency status monitoring data). Rigid strategies cannot meet the fine-grained scheduling needs in heterogeneous scenarios, easily leading to network bandwidth waste or insufficient real-time performance. To solve the above problems, this embodiment proposes a configuration-driven data packet sending strategy engine. This engine completely separates the sending strategy from the core business logic, allowing users to independently define the sending rules for each data packet by modifying standardized configuration files. Specifically, after writing the second field data into the sending buffer to generate the data packet to be sent, the following steps are also included: Step 1: Obtain the sending strategy configuration corresponding to the data packet to be sent, and construct a sending strategy model based on the sending strategy configuration; Step 2: Determine the sending mode corresponding to the data packet to be sent according to the sending strategy model, and execute the sending task of the data packet to be sent according to the sending mode; the sending mode includes one of the following: event-triggered single sending mode, quantitative sending mode with specified number of sending times, periodic sending mode with custom sending time interval, and fast and slow packet segmented sending mode based on different refresh frequencies; Step 3: Obtain the sending result of the sending task, and update the execution status of the sending mode according to the sending result; Step 4: When the sending task is completed, update the execution status of the sending mode to the completed state, and when the preset resending conditions are met, update the execution status of the sending mode from the completed state to the pending state, so as to wait for the next sending task.

[0089] In this embodiment, the main program reads the sending strategy configuration file during initialization, dynamically constructs the sending strategy model, and has it parsed and executed in real time by the built-in intelligent scheduling engine at runtime. This mechanism enables data packets to support multiple sending modes: single-trigger sending (event-driven), quantitative sending with a specified number of times, periodic sending with customizable time intervals, and segmented sending of fast and slow packets based on refresh frequency differences. Through configuration, the system can flexibly adapt to different application scenarios and system configurations without modifying any code, significantly improving the customizability and runtime adaptability of the data distribution mechanism.

[0090] Figure 11 This paper compares traditional hard-coded sending strategies with the configuration-driven strategy engine of this solution. In the traditional approach, the sending strategy is hard-coded into the business logic; changes in requirements necessitate code modifications and recompilation, leading to high maintenance costs. This solution defines data packet sending rules independently through configuration files. The main program reads the configuration to build the strategy model during initialization, and the intelligent scheduling engine parses and executes it in real time. It supports various modes such as single-trigger, quantitative sending, periodic sending, and segmented sending of fast and slow packets, ultimately achieving flexible adaptation to different scenarios without code modification.

[0091] Figure 12This describes the state transitions for the four main sending modes supported by the packet sending strategy engine. The initial state is "Pending Send," and different sending modes can be entered based on configuration: single-trigger sending (completes directly after an event-driven event), quantitative sending (completes after sending a specified number of times), periodic sending (repeatedly sends at fixed intervals until stopped), and segmented fast and slow packet sending (sent separately as fast and slow packets based on refresh frequency). After a packet to be sent completes its current round of sending according to the corresponding sending mode, the intelligent scheduling engine updates the execution status of that sending mode to the completed state based on the sending result. To enable the same packet to continue responding to subsequent sending trigger events, resend commands, or the next sending cycle, when preset resend conditions are met, the execution status of that sending mode is updated from the completed state to the pending send state, thus waiting for the next round of sending tasks. It should be noted that the updated pending send state indicates that the current sending task has been reset and is ready to be sent again, but does not mean that the current round of sending has not yet been completed.

[0092] Figure 13 This demonstrates the runtime interaction process of the configuration-driven sending strategy engine. Users or developers edit configuration files, which the main program reads during initialization and passes to the intelligent scheduling engine. The scheduling engine parses and executes the strategy in real time, triggering the data packet sending module to send packets according to the configuration (supporting multiple modes such as single, fixed-quantity, periodic, fast / slow packet, etc.), and feeding the results back to the scheduling engine for status updates. The entire process requires no modification to the core code, enabling flexible customization of the sending strategy.

[0093] As can be seen, the sending module in this embodiment supports defining the sending mode of each data packet independently through a configuration file: single trigger, specified number of times, periodic sending with a custom period, and differentiated sending of fast and slow packets (e.g., control commands are sent at a 10ms period, and status information is sent at a 100ms period). All strategies require no modification to any core code; they can adapt to different system configurations (e.g., single-machine, dual-machine redundancy, multi-machine collaboration) simply by updating the JSON configuration. Such flexibility, in contrast, would require extensive conditional branching and global variable maintenance under traditional hard-coding methods, making it highly prone to errors.

[0094] Figure 14This demonstrates the complete data flow from external ICD input to final data consumption by business modules. The system consists of three main parts: a protocol conversion tool, a general data parsing engine, and a message subscription and publishing mechanism. The protocol conversion tool is responsible for automatically parsing and converting externally input interface control files (ICDs, usually in Excel format) into a general JSON protocol description file defined internally by the system, i.e., the aforementioned standardized protocol description file. This file adopts a standardized format and contains information such as the data frame identification code, field offset, data type, and unit, serving as the sole basis for all subsequent parsing operations. When the main program starts, it loads the JSON into memory to build a structured protocol mapping model (such as a multi-level linked list). When the raw binary or text data stream arrives, the general data parsing engine combines the model for parsing, quickly matching the frame identification code in the model and parsing byte by byte according to the field definitions, converting the raw data into standardized data objects. Finally, the standardized data objects are encapsulated into unified messages through a publish / subscribe (Pub / Sub) mechanism and distributed to various business modules through a message bus. Business modules only need to subscribe to standard topics to obtain the required data, without needing to concern themselves with the underlying protocol details.

[0095] The core advantage of this solution lies in its ability to hot-swap protocols. When adding or modifying an ICD, simply generating a new JSON file using a protocol conversion tool and placing it in a designated directory allows the parsing engine to automatically take effect upon the next data reception, eliminating the need for modification, compilation, or service restart. Simultaneously, the unified parsing engine replaces scattered hard-coded logic, significantly reducing maintenance costs and error probability, while improving system fault tolerance and stability. The entire architecture is lightweight and efficient, suitable for the rapid iteration needs of cloud-native environments.

[0096] Accordingly, embodiments of this application disclose a configuration-driven data parsing device, see [link to relevant documentation]. Figure 15 As shown, the device includes: The standard file generation module 11 is used to obtain an interface control file and extract packet identification information and field parsing information from the interface control file according to a pre-configured field mapping relationship to generate a standardized protocol description file; wherein, the standardized protocol description file includes at least one set of interrelated packet identification information and field parsing information; the field mapping relationship is used to characterize the correspondence between the source field name in the interface control file and the packet identification information or the field parsing information; Protocol parsing model construction module 12 is used to construct a protocol parsing model based on the standardized protocol description file, including at least one set of interrelated data packet identification information and field parsing information; The matching and identification module 13 is used to receive the data packet to be parsed and match it with the data packet identification information in the protocol parsing model to determine the target field parsing information corresponding to the data packet to be parsed. The parsing module 14 is used to extract field data from the data packet to be parsed according to the field position in the target field parsing information, and convert the field data according to the data type in the target field parsing information to obtain the parsing result of the data packet to be parsed.

[0097] For more detailed information on the working process of each of the above modules, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.

[0098] Furthermore, embodiments of this application disclose an electronic device, Figure 16 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of protection of this application. The electronic device 20 may specifically include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the configuration-driven data parsing method disclosed in any of the foregoing embodiments.

[0099] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0100] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk, or optical disk, etc. The resources stored on it can include an operating system 221, computer programs 222, and data 223, etc. The data 223 can include various types of data. The storage method can be temporary storage or permanent storage.

[0101] The operating system 221 is used to manage and control the various hardware devices on the electronic device 20 and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of performing the configuration-driven data parsing method executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include a computer program capable of performing other specific tasks.

[0102] Furthermore, this application also discloses a computer-readable storage medium, which includes random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disks, magnetic disks, optical disks, or any other form of storage medium known in the art. The computer program, when executed by a processor, implements the aforementioned configuration-driven data parsing method. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0103] Furthermore, embodiments of this application also provide a computer program product, including a computer program / instruction, which, when executed by a processor, implements any of the above-described configuration-driven data parsing methods.

[0104] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0105] The steps of the configuration-driven data parsing method or algorithm described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0106] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0107] The above provides a detailed description of the configuration-driven data parsing method, apparatus, device, and medium provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A configuration-driven data parsing method, characterized in that, include: An interface control file is obtained, and packet identification information and field parsing information are extracted from the interface control file according to a pre-configured field mapping relationship to generate a standardized protocol description file; wherein, the standardized protocol description file includes at least one set of interrelated packet identification information and field parsing information; the field mapping relationship is used to characterize the correspondence between the source field names in the interface control file and the packet identification information or the field parsing information; Based on the standardized protocol description file, a protocol parsing model is constructed that includes at least one set of interrelated packet identification information and field parsing information; Receive the data packet to be parsed and match it with the data packet identification information in the protocol parsing model to determine the target field parsing information corresponding to the data packet to be parsed; Based on the field position in the target field parsing information, the field data is extracted from the data packet to be parsed, and the field data is converted according to the data type in the target field parsing information to obtain the parsing result of the data packet to be parsed.

2. The configuration-driven data parsing method according to claim 1, characterized in that, The process of obtaining the interface control file and extracting packet identification information and field parsing information from the interface control file according to the pre-configured field mapping relationship to generate a standardized protocol description file includes: Obtain the interface control file in tabular form and load the field mapping table stored in the structured configuration file; the field mapping table records the correspondence between preset field names and source field names in one or more tabular interface control files; The header of the interface control file is matched according to the field mapping table to extract the data packet identification information of each data packet and the field parsing information of each field from the matched columns. According to a preset unified format, the extracted data packet identification information and field parsing information are output as a standardized protocol description file independent of the source of the interface control file.

3. The configuration-driven data parsing method according to claim 1, characterized in that, The construction of a protocol parsing model based on the standardized protocol description file, including at least one set of interrelated packet identification information and field parsing information, includes: During the main program initialization and startup phase, the standardized protocol description file is parsed, a data packet protocol node is created for each data packet, and a field parsing node associated with the data packet protocol node is created for each field in the data packet. The data packet protocol node and the field parsing node are connected in a unidirectional chain structure, and a retrieval entry point for the data packet protocol node is established based on the data packet identification information to obtain a protocol parsing model that can be traversed and retrieved.

4. The configuration-driven data parsing method according to claim 3, characterized in that, The data packet identification information includes one or more identification locations and preset identification values ​​corresponding to each identification location; correspondingly, a data packet to be parsed is received and matched with the data packet identification information in the protocol parsing model to determine the target field parsing information corresponding to the data packet to be parsed, including: Traverse each data packet protocol node in the protocol parsing model; For the current data packet protocol node, extract single-byte or multi-byte matching identification values ​​from the data packet to be parsed according to each identification position, and compare each matching identification value with the preset identification value corresponding to the identification position in sequence; When all the identification values ​​to be matched corresponding to the current data packet protocol node match the preset identification value, the current data packet protocol node is determined as the target data packet protocol node; The target field parsing node is determined based on the target data packet protocol node, and the target field parsing node is identified as the target field parsing information.

5. The configuration-driven data parsing method according to claim 4, characterized in that, The field parsing information includes field position, data type, byte order information, dimensional coefficient, and time-division multiplexing information. The time-division multiplexing information is used to characterize different sub-protocols corresponding to the same field position under different time-division identification values. Accordingly, based on the field position in the target field parsing information, field data is extracted from the data packet to be parsed, and the field data is converted according to the data type in the target field parsing information to obtain the parsing result of the data packet to be parsed, including: Based on the field position in the target field parsing information, extract the field data from the data packet to be parsed, and determine the byte length of the field data according to the data type in the target field parsing information; Based on the byte order information in the target field parsing information, the bytes in the field data are arranged, and the arranged field data is converted into field values; The physical value is obtained by converting the numerical value of the target field using the dimensional coefficients in the parsed information, and the physical value is used as the parsing result of the data packet to be parsed.

6. The configuration-driven data parsing method according to claim 5, characterized in that, When the target field parsing information contains the time-division multiplexing information, the method further includes: Obtain the target time-division identification value from the data packet to be parsed, determine the corresponding target sub-protocol based on the target time-division identification value, and parse the corresponding fields in the data packet to be parsed according to the field parsing information defined in the target sub-protocol.

7. The configuration-driven data parsing method according to claim 5, characterized in that, After obtaining the parsing result of the data packet to be parsed, the process further includes: The data packet to be parsed is stored in the receive buffer corresponding to the target data packet protocol node, and the physical value is stored in a separate parsing value cache; Update the target data packet protocol node's receive timestamp, total number of data packets received, valid data packet count, and data validity flag; Update the validity flag of the parsing result based on whether the time difference between the current time and the received timestamp exceeds a preset valid time threshold; The receive buffer and the parsed value cache are updated through a mutual exclusion access mechanism or a lock-free queue, and after the update is completed, a data update notification is sent to the service modules that subscribe to the parsed results through a semaphore or an event.

8. The configuration-driven data parsing method according to claim 5, characterized in that, Also includes: The actual length of the data packet to be parsed is compared with the data packet length specified in the standardized protocol description file. If the actual length is less than the specified data packet length, the data packet to be parsed is recorded as an invalid data packet, the invalid data packet count is incremented, and parsing of the data packet to be parsed is stopped. For the field to be extracted, determine whether the offset of the field to be extracted exceeds the actual length. If it exceeds the actual length, discard the data packet to be parsed and record the parsing error. When the standardized protocol description file includes packet-level byte order information indicating whether the entire data packet is big-endian, the packet-level byte order information is applied to each field in the data packet to be parsed that does not have separately configured field-level byte order information.

9. The configuration-driven data parsing method according to claim 7, characterized in that, Also includes: The system receives a subscription request carrying a first data packet name and a first field name, searches for first field parsing information in the protocol parsing model based on the first data packet name and the first field name, obtains first field data from the receiving buffer based on the first field parsing information, converts the first field data into a physical value, and returns it to the subscriber. Receive a publishing request carrying a second data packet name, a second field name, and a value to be published; search for second field parsing information in the protocol parsing model according to the second data packet name and the second field name; convert the value to be published into second field data according to the second field parsing information; and write the second field data into the sending buffer to generate a data packet to be sent. The receive buffer and the send buffer are independent of each other.

10. The configuration-driven data parsing method according to claim 9, characterized in that, After writing the second field data into the sending buffer to generate the data packet to be sent, the method further includes: Obtain the sending strategy configuration corresponding to the data packet to be sent, and construct a sending strategy model based on the sending strategy configuration; The sending strategy model determines the sending mode corresponding to the data packet to be sent, and the sending task of the data packet to be sent is executed according to the sending mode; the sending mode includes one of the following: event-triggered single sending mode, quantitative sending mode with specified number of sending times, periodic sending mode with custom sending time interval, and fast and slow packet segmented sending mode based on different refresh frequencies; Obtain the sending result of the sending task, and update the execution status of the sending mode based on the sending result; When the sending task is completed, the execution status of the sending mode is updated to the completed state. When the preset resending conditions are met, the execution status of the sending mode is updated from the completed state to the pending state to wait for the next sending task.

11. A configuration-driven data parsing device, characterized in that, include: A standard file generation module is used to obtain an interface control file and extract packet identification information and field parsing information from the interface control file according to a pre-configured field mapping relationship to generate a standardized protocol description file; wherein, the standardized protocol description file includes at least one set of interrelated packet identification information and field parsing information; the field mapping relationship is used to characterize the correspondence between the source field names in the interface control file and the packet identification information or the field parsing information; The protocol parsing model construction module is used to construct a protocol parsing model based on the standardized protocol description file, including at least one set of interrelated data packet identification information and field parsing information; The matching and identification module is used to receive the data packet to be parsed and match it with the data packet identification information in the protocol parsing model to determine the target field parsing information corresponding to the data packet to be parsed. The parsing module is used to extract field data from the data packet to be parsed according to the field position in the target field parsing information, and to convert the field data according to the data type in the target field parsing information to obtain the parsing result of the data packet to be parsed.

12. An electronic device, characterized in that, The electronic device includes a processor and a memory; wherein the memory is used to store a computer program, which is loaded and executed by the processor to implement the configuration-driven data parsing method as described in any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, Used to store computer programs; wherein the computer programs, when executed by a processor, implement the configuration-driven data parsing method as described in any one of claims 1 to 10.

Images