An adaptive loading method and system for communication protocols in lithium battery production equipment

Abstract

This invention discloses an adaptive loading method and system for communication protocols in lithium battery production equipment, relating to the field of data communication technology. The method includes: obtaining a protocol description packet generated by a visual PDL editor, the protocol description packet including a pre-compiled Abstract Syntax Tree (AST); traversing the AST, obtaining verification rules and translating them into native machine code, and containerizing and binding the native machine code to interfaces; when an unknown physical device connects, obtaining the first packet of raw data sent by it and performing multi-dimensional feature extraction, performing communication protocol matching and establishing a routing table based on the extracted multi-dimensional features; establishing communication with the unknown physical device based on the routing table, and real-time monitoring of the agent for anomaly diagnosis and repair. This invention can decouple the protocol description from the execution engine, eliminating hard-coded dependencies, and the hot-swappable loading of protocol files can ensure continuous production and reduce production losses.

Description

Technical Field

[0001] This invention relates to the field of data communication technology, and in particular to an adaptive loading method and system for communication protocols in lithium battery production equipment. Background Technology

[0002] With the rapid development of the new energy industry, lithium battery production lines are evolving towards intelligence and flexibility. These production lines often integrate equipment from various brands, such as coating machines, slitting machines, and formation machines, and involve multiple protocols, including S7, Fins, MC, OPCUA, and Modbus. The fragmentation of equipment communication protocols has become a core bottleneck restricting the flexibility of production lines.

[0003] Current technologies rely on traditional hard-coded protocol-driven approaches, resulting in long development and debugging cycles for new devices. Protocol changes necessitate re-verification and debugging, strong coupling between code and equipment, and maintenance costs that increase annually. General industrial protocol gateways use OPCUA for protocol conversion, which cannot adapt to proprietary protocols. Protocol expansion requires downtime debugging, leading to low real-time performance. Some SCADA systems provide protocol configuration interfaces but only support pre-built protocol templates, failing to dynamically load protocol version differences and lacking protocol self-learning capabilities, still requiring manual intervention for new devices.

[0004] To address the technical issues of long debugging cycles, high maintenance costs, and poor real-time performance, an adaptive loading method and system for the communication protocol of lithium battery production equipment is urgently needed. Summary of the Invention

[0005] The purpose of this invention is to overcome the shortcomings of the prior art and provide an adaptive loading method and system for the communication protocol of lithium battery production equipment. By decoupling the protocol description from the execution engine, hard-coded dependencies can be eliminated, and hot-swappable loading of protocol files can ensure continuous production and reduce production losses.

[0006] To achieve the above objectives, the present invention is implemented using the following technical solution:

[0007] In a first aspect, the present invention provides an adaptive loading method for a communication protocol of lithium battery production equipment, comprising:

[0008] A visual PDL editor is used to generate a protocol description package, which includes a pre-compiled abstract syntax tree (AST).

[0009] Traverse the abstract syntax tree (AST), obtain the verification rules and translate them into local machine code, and then containerize and bind the local machine code to the interface.

[0010] When an unknown physical device accesses the network, the system acquires the first packet of raw data it sends and performs multi-dimensional feature extraction. Based on the extracted multi-dimensional features, the system performs communication protocol matching and establishes a routing table.

[0011] Communication is established with the unknown physical device based on the routing table, and the agent is monitored in real time for anomaly diagnosis and repair.

[0012] The adaptive loading method provided by this invention "staticizes" protocol details using PDL language, "dynamicizes" the static description through translation, and "isolates" dynamic code through a container engine, thereby achieving complete decoupling between the main program and the specific protocol. Furthermore, monitoring and maintenance are performed after communication is established to ensure high-quality communication.

[0013] Optionally, the visual PDL editor generates a protocol description package including:

[0014] The visual PDL editor obtains the communication protocol configured by the user according to the preset protocol meta-model architecture and performs real-time syntax verification; the protocol meta-model architecture includes protocol header, data field, verification rules and embedded industrial features;

[0015] After passing syntax validation, it is converted into a binary structure and a validation header is added to generate a .protox format protocol description packet; the structure of the .protox format protocol description packet includes:

[0016] Header: Contains the start flag, version number, package length, and CRC checksum.

[0017] Metadata area: Stores description information of the communication protocol in JSON format;

[0018] Code section: Contains PDL source code and pre-compiled Abstract Syntax Tree (AST).

[0019] This invention does not directly write executable code, but instead uses an intermediate language (PDL) to describe protocol characteristics, thus providing standard input for the automated generation of subsequent steps. The pre-compiled Abstract Syntax Tree (AST) is the key link between "static definition" and "dynamic execution": at the end of "protocol abstract modeling," the editor not only saves the user-readable text (PDL source code) but also simultaneously generates a machine-readable structure (AST). This demonstrates the advantages of "structured definition." In the subsequent loading stage, the PDL interpreter no longer needs to parse strings from scratch but directly reads the AST. Subsequently, the intermediate code generator traverses this tree, directly converting nodes (such as CheckRange nodes) into LLVM IR instructions (such as ICMP instructions).

[0020] Optionally, traversing the Abstract Syntax Tree (AST) to obtain verification rules and translate them into native machine code includes:

[0021] The abstract syntax tree (AST) is obtained from the protocol description packet using a PDL interpreter;

[0022] The abstract syntax tree (AST) is traversed by an intermediate code generator to obtain verification rules and translate them into platform-independent LLVM IR intermediate code.

[0023] The LLVM IR intermediate code is compiled into native machine code using the LLVM JIT compiler.

[0024] This invention is based on a microkernel architecture and LLVM JIT technology to achieve protocol-driven millisecond-level (<200ms) hot loading and memory-level resource isolation.

[0025] Optionally, the containerization and interface binding of the native machine code includes:

[0026] Allocate independent memory pages and use cgroups v2 to create independent resource groups for the local machine code of each communication protocol;

[0027] Computational resources are allocated using cpu.weight, and memory usage is limited using memory.max, thus constructing an independent protocol container;

[0028] The local machine code is stored in the corresponding protocol container, NX protection is set, and standard function pointers are generated to point to each of the protocol containers.

[0029] This invention transforms the protocol description packet into executable machine code in computer memory and encapsulates it in an isolated container. This is a key step in achieving "decoupling"—the main program calls the container through a generic interface without needing to know how the container is generated internally.

[0030] Optionally, the multidimensional features include:

[0031] Physical layer characteristics, including vendor ID and MAC address OUI;

[0032] Network layer characteristics, including port numbers;

[0033] Application layer features, including frame structure;

[0034] The communication protocol matching based on the extracted multidimensional features includes:

[0035] Matching scores are calculated based on the extracted multidimensional features:

[0036] Score=n1* Vendor+n2* Port+n3* FrameStructure

[0037] In the formula, Score is the matching score, n1, n2, n3 are weight parameters, n1+n2+n3=1, Vendor, Port, FrameStructure are the vendor score obtained based on physical layer features, the port score obtained based on network layer features, and the frame structure score obtained based on application layer features, respectively.

[0038] If the matching score is greater than or equal to the score threshold, the matching with the corresponding communication protocol is successful, a routing table is established, and the connection of the unknown physical device is directly mapped to the protocol container corresponding to the corresponding communication protocol.

[0039] This invention integrates features from the physical layer, network layer, and application layer, and uses a weighted similarity algorithm to automatically identify unknown devices, thereby achieving communication protocol matching and correctly routing the traffic of unknown physical devices to the corresponding protocol container.

[0040] Optionally, if the matching score is less than the score threshold, the corresponding communication protocol is added to the candidate pool.

[0041] Parallel verification is performed on the communication protocol with the highest matching score in the candidate pool. If the verification passes, the matching is successful, a routing table is established, and the connection of the unknown physical device is directly mapped to the protocol container corresponding to the corresponding communication protocol. If the verification fails, it is reported for manual processing.

[0042] This invention performs candidate matching on communication protocols that are below a score threshold, avoiding the low matching success rate caused by a single matching method, improving fault tolerance, and ensuring that the entire process can operate efficiently.

[0043] Optionally, establishing communication with the unknown physical device based on the routing table includes:

[0044] Execute the local machine code in the corresponding protocol container, lock the frame boundary in the data stream through a sliding window based on the start flag, and perform CRC check;

[0045] The parsed data is converted into a unified JSON format and output through the MQTT / Kafka bus, thus decoupling the business layer from the protocol layer.

[0046] In this invention, the isolated protocol container only processes legitimate traffic that has been confirmed by routing, which ensures both processing efficiency and secure isolation through the container boundary.

[0047] Optionally, the real-time monitoring agent performs anomaly diagnosis and repair, including:

[0048] The system reads the operational metrics of the protocol container in real time. If a memory leak or continuous heartbeat loss exceeding a preset standard is detected in the protocol container, the circuit breaker mechanism is triggered to destroy the current protocol container and re-execute: traverse the abstract syntax tree (AST), obtain the verification rules and translate them into local machine code, and containerize and bind the local machine code to the interface.

[0049] This invention ensures the stability of the device communication process through abnormal fuse breaking and self-healing.

[0050] Optionally, if the protocol description packet generated by the visual PDL editor is updated or the network environment deteriorates, causing the latency to exceed the preset standard, a double-buffering switch will be performed. A new protocol container will be started, and the traffic will be gradually migrated from the old protocol container to the new protocol container using the double-buffering mechanism to ensure that no frame of data is lost during the switch.

[0051] This invention ensures low latency and accuracy in device communication through lossless hot-switching and version rollback.

[0052] Secondly, the present invention provides an adaptive loading system for a communication protocol of lithium battery production equipment, comprising:

[0053] The protocol description module is configured to obtain a protocol description package generated by a visual PDL editor, the protocol description package including a pre-compiled abstract syntax tree (AST);

[0054] The translation and encapsulation module is configured to traverse the abstract syntax tree (AST), obtain the verification rules and translate them into local machine code, and then containerize and encapsulate the local machine code and bind it to the interface.

[0055] The matching connection module is configured to, when an unknown physical device accesses the network, acquire the first packet of raw data sent by the device and perform multi-dimensional feature extraction, perform communication protocol matching based on the extracted multi-dimensional features and establish a routing table;

[0056] The closed-loop control module is configured to establish communication with the unknown physical device based on the routing table, and to monitor the agent in real time for anomaly diagnosis and repair.

[0057] Compared with the prior art, the beneficial effects achieved by the present invention are as follows:

[0058] This invention provides an adaptive loading method and system for communication protocols in lithium battery production equipment. It uses the PDL language to "staticize" protocol details, translates the static description to "dynamicate" it, and isolates the dynamic code using a container engine, thereby achieving complete decoupling between the main program and the specific protocol. Specifically, PDL abstracts protocol details into metadata, and combined with LLVM intermediate code generation technology, the main program only needs to call general function pointers to drive any protocol, improving protocol compatibility and shortening protocol development time. Simultaneously, monitoring and maintenance are performed after communication is established to ensure high-quality communication. The hot-loading mechanism and just-in-time compilation technology of the container engine, along with double-buffered traffic switching, eliminate system downtime issues. Furthermore, PDL's visual editing and real-time syntax verification reduce configuration complexity, while intelligent matching based on multi-dimensional features and cgroups resource isolation enhance system scalability and robustness. Attached Figure Description

[0059] Figure 1 This is a flowchart of an adaptive loading method for the communication protocol of lithium battery production equipment provided in an embodiment of the present invention. Detailed Implementation

[0060] The present invention will be further described below with reference to the accompanying drawings. The following embodiments are only used to more clearly illustrate the technical solution of the present invention, and should not be used to limit the scope of protection of the present invention.

[0061] Example 1

[0062] like Figure 1 As shown, this embodiment of the invention provides an adaptive loading method for the communication protocol of lithium battery production equipment, including the following steps:

[0063] Step S1: Obtain the protocol description package generated by the visual PDL editor. The protocol description package includes a pre-compiled abstract syntax tree (AST).

[0064] Step S1 does not directly write executable code, but describes the protocol features through an intermediate language (PDL), thereby providing standard input for the automated generation of subsequent steps. Specifically, it includes: (1.1) A visual PDL editor obtains the communication protocol configured by the user according to the preset protocol meta-model architecture and performs real-time syntax verification; the protocol meta-model architecture includes protocol header, data field, verification rules and embedded industrial features.

[0065] a. Protocol header: Supports defining fixed fields and variable fields.

[0066] Start flag: For example, define 2 bytes as 0xAA55.

[0067] Version control: Supports BCD encoded version numbers (high 4 digits major version, low 4 digits minor version).

[0068] Logical association: The start flag defined here will be directly reused in the feature extraction in step S3 and the frame synchronization in step S4.

[0069] b. Data domain:

[0070] Nested structure: Supports three levels of nesting of data groups, data items, and sub-items, adapting to complex structures.

[0071] Type system: It includes 15 basic types such as uint8-64, float32 / 64, and timestamp, as well as 4 composite types such as array, struct, and union.

[0072] Serialization: Supports big-endian / little-endian configuration, strings support ASCII / UTF-8 / UTF-16, and binary supports Base64.

[0073] c. Verification Rules: Built-in CRC8 / 16 / 32 (supports 10+ polynomials), MD5, SHA-1 and other algorithms. Supports specifying the verification range via the CheckRange attribute (e.g., "Header[0-5], Data[2-10]"). These rules will be converted into specific bitwise operation instructions in step S2.

[0074] d. Embedding industrial features:

[0075] Physical units: Based on the SI unit system, defining conversion factors and offsets (e.g., Celsius to Kelvin offset +273.15).

[0076] Range limitation: Supports numerical range [min, max], enumeration {0:"Off", 1:"On"} and mask 0x0F definition.

[0077] Multidimensional mapping: Supports mapping data to five dimensions: time, space, device, and business, generating a multidimensional index structure.

[0078] (1.2) After the syntax check passes, it is converted into a binary structure and a check header is added to generate a .protox format protocol description packet; the structure of the .protox format protocol description packet includes:

[0079] Header: Contains the start flag, version number, package length, and CRC checksum.

[0080] Metadata area: Stores description information of the communication protocol in JSON format;

[0081] Code section: Contains PDL source code and pre-compiled Abstract Syntax Tree (AST).

[0082] The Abstract Syntax Tree (AST) is the key link connecting "static definition" and "dynamic execution":

[0083] At the end of the "Protocol Abstraction Modeling" stage, the editor not only saves the user-readable text (PDL source code) but also simultaneously generates a machine-readable structure (AST). This demonstrates the advantages of "structured definition." In the loading phase of step S2, the PDL interpreter no longer needs to parse the string from scratch but directly reads the Abstract Syntax Tree (AST). Subsequently, the intermediate code generator traverses this tree, directly converting nodes (such as CheckRange nodes) into LLVM IR instructions (such as ICMP instructions).

[0084] In step S1, if only the text PDL is stored, the system needs to perform lexical analysis and parsing every time the protocol is loaded during runtime (step S2), which consumes CPU time. Pre-compilation means that the tree is built in step S1 (compilation phase) and exists in the protocol description packet in serialized form. When the system loads the protocol at runtime, it can directly deserialize to obtain the Abstract Syntax Tree (AST), skipping the time-consuming text parsing phase and directly entering the intermediate code generation stage, thereby achieving "millisecond-level hot loading".

[0085] The process of precompiling the Abstract Syntax Tree (AST) is actually a deep syntax check. If generating the AST fails, it indicates an error in the protocol definition. The tool will report an error directly, preventing the generation of erroneous protocol description packets and ensuring that all packets entering the production environment are syntactically valid.

[0086] Step S2: Traverse the Abstract Syntax Tree (AST), obtain the verification rules and translate them into local machine code, and then containerize and bind the local machine code to the interface.

[0087] Step S2 converts the protocol description packet generated in step S1 into executable machine code in computer memory and encapsulates it in an isolated container. This is a crucial step in achieving "decoupling"—the main program calls the container through a generic interface without needing to know how the container's internal structure was generated in step S1. Specifically, this includes:

[0088] (2.1) Traversing the Abstract Syntax Tree (AST), obtaining the verification rules, and translating them into native machine code includes:

[0089] The abstract syntax tree (AST) is obtained from the protocol description packet using the PDL interpreter;

[0090] The intermediate code generator traverses the abstract syntax tree (AST), obtains the validation rules, and translates them into platform-independent LLVM IR intermediate code.

[0091] The LLVM JIT compiler compiles the LLVM IR intermediate code into native machine code.

[0092] This invention is based on a microkernel architecture and LLVM JIT technology to achieve protocol-driven millisecond-level (<200ms) hot loading and memory-level resource isolation.

[0093] (2.2) Containerization and interface binding of native machine code includes:

[0094] Allocate independent memory pages and use cgroups v2 to create independent resource groups for the local machine code of each communication protocol;

[0095] Computational resources are allocated using cpu.weight, and memory usage is limited using memory.max, thus constructing an independent protocol container;

[0096] Store the local machine code into the corresponding protocol container, set NX protection, and generate standard function pointers to point to each protocol container.

[0097] The specific implementation logic of step S12 is as follows:

[0098] a. Physical form: allocating and locking memory space.

[0099] JIT compilation and writing: The system uses the LLVM JIT compiler (ExecutionEngine interface) to not generate files on the hard disk, but instead allocates a space in memory and writes the machine code compiled from the intermediate code into this memory.

[0100] Access control (security encapsulation): To prevent code from being tampered with or to prevent buffer overflow attacks, the system will implement segment protection settings for this memory area.

[0101] Code segment: Set to "Read-Only / Executable". This means that this memory can only be executed by the CPU and cannot be modified by any program.

[0102] Data segment: Set to "Read / Write" to store runtime variables, but execution is prohibited (NX protection).

[0103] Independent address space: Each container obtains its own virtual address space through the clone(CLONE_NEWUSER) call, ensuring that memory between different protocols is not visible to each other.

[0104] b. Logical Boundaries: Constructing resource walls.

[0105] Although the machine code is in memory, to prevent it from crashing (infinite loop) or consuming excessive resources, the system builds a "wall" around it:

[0106] Creating a control group: The system uses Linux's cgroups v2 mechanism to create an independent control group path for the execution context of this machine code, such as / sys / fs / cgroup / protocol-containers / <container ID>.

[0107] CPU limits: By setting `cpu.weight` (weight) and `cpu.max` (absolute upper limit), the maximum CPU time slice that this machine code can occupy is forcibly specified. If the code enters an infinite loop, the operating system will forcibly suspend it, without affecting the main program.

[0108] Memory limit: Set a hard limit (e.g., 100MB) using memory.max. Once the memory requested by this code exceeds the threshold, the system will trigger the OOM (Out of Memory) protection mechanism, directly shutting down the container instead of causing the entire system to crash.

[0109] c. Interaction Channel: Dynamic Interface Binding (“Window”)

[0110] The encapsulated machine code is like a black box; the main program needs a standard interface to call it.

[0111] Pointer mapping: The system generates function pointers that point to the entry address of the aforementioned "read-only executable memory block". These pointers are forcibly converted to a uniform interface signature (such as parse_frame, build_frame).

[0112] Blind function call: The main program only holds this generic function pointer. When data needs to be processed, the main program calls this pointer, the CPU instruction jumps to the isolated memory block for execution, and returns the result after execution. The main program does not need to know whether the code in memory is Modbus or S7, thus achieving decoupling.

[0113] Step S3: When an unknown physical device accesses the network, obtain the original data of the first packet it sends and perform multi-dimensional feature extraction. Based on the extracted multi-dimensional features, perform communication protocol matching and establish a routing table.

[0114] Step S3 addresses the problem of how to correctly route the traffic of an unknown physical device to the corresponding protocol container created in step S2 when the device connects.

[0115] (3.1) Multidimensional features include:

[0116] Physical layer characteristics, including vendor ID and MAC address OUI, are obtained by querying the local database;

[0117] Network layer characteristics, including port numbers, such as port 502, which strongly points to the Modbus protocol; port 102 points to the S7 protocol.

[0118] Application layer features, including frame structure, are backtracked by using the similarity between the defined data frame in step S1 and the "frame structure" defined in all loaded PDLs (such as whether it contains the 0xAA55 header defined in step 1, or by calculating the data field entropy value to distinguish between ASCII and binary).

[0119] Communication protocol matching based on extracted multidimensional features includes:

[0120] Matching score calculation based on extracted multidimensional features:

[0121] Score=n1* Vendor+n2* Port+n3* FrameStructure

[0122] In the formula, Score is the matching score, n1, n2, n3 are weight parameters, n1+n2+n3=1, Vendor, Port, FrameStructure are the vendor score obtained based on physical layer features, the port score obtained based on network layer features, and the frame structure score obtained based on application layer features, respectively.

[0123] If the matching score is greater than or equal to the score threshold, the matching with the corresponding communication protocol is successful, a routing table is established, and the connection of the unknown physical device is directly mapped to the protocol container corresponding to the corresponding communication protocol.

[0124] Regarding the Vendor score, the specific data is as follows: Vendor ID: A specific vendor identification code in the physical layer frame header (e.g., a 2-4 byte ID). MAC Address OUI: The first 3 bytes of the MAC address (organization-unique identifier), used to query the IEEE database. Physical signal characteristics: such as baud rate, signal level (3.3V / 5V), etc. Calculation logic (how to convert it into a score of 0~1): A lookup table method and Boolean matching are used: Database lookup: The system searches the local "vendor fingerprint database" for the extracted OUI or vendor ID. Calculation: If there is a perfect match (e.g., OUI corresponds to "Siemens"), then Vendor = 1. If there is a fuzzy match (e.g., the baud rate matches the vendor's common settings, but the ID is unknown), then Vendor = 0.6 (example value, based on fuzzy matching logic). If there is no matching record, then Vendor = 0.

[0125] Regarding the port score (Port), the specific data is as follows: Target port number: TCP or UDP port (e.g., 502, 102, 1883, etc.). Source port behavior: Whether it is fixed port communication. Calculation logic (how to convert to a score of 0-1): Boolean feature matching is used: the system has a pre-set "well-known port mapping table" (e.g., 502=Modbus, 102=S7, 9600=Fins). Calculation: If the currently captured port number matches the standard port of the candidate protocol: Port = 1. If not: Port = 0.

[0126] Regarding the FrameStructure score, specific data includes: Start / End Marker: Whether a specific frame header (e.g., 0xAA55) or frame tail is included. Data Entropy: Calculates the disorder of the data field byte distribution (binary protocol entropy ≈ 7.5, ASCII protocol ≈ 5.0). Timing Behavior: Request-Response Time Interval (RTT) distribution. Calculation Logic (How to convert to a score of 0~1): Uses numerical feature normalization: Formula: F_i = 1 - {|actual value - standard value|} / {standard value range}. Example (based on entropy): Assume the candidate protocol is Modbus RTU (standard entropy 7.5, allowable range ±1.0). If the actual captured frame entropy is 7.2. Calculation: FrameStructure = 1 - {|7.2 - 7.5|} / {1.0} = 1 - 0.3 = 0.7. Example (based on frame header string): Calculate the edit distance between the actual frame header and the standard frame header; the smaller the distance, the higher the score.

[0127] Example of comprehensive calculation: Assume an unknown device is connected and a frame of data is collected with the following characteristics: MAC OUI: Unknown (vendor unidentified). Port: 502. Data content: Binary format, the calculated entropy value is very close to the Modbus standard (match degree 0.9). The system performs a matching calculation with "Modbus protocol": Vendor score: 0 points because no record of this MAC address exists in the database. Port score: 1 point because 502 is a Modbus standard port. Frame structure score: 0.9 points because the entropy value highly matches the standard. The weight parameters n1, n2, n3 are 0.4, 0.3, and 0.3 respectively. The final score is: Score = (0.4×0) + (0.3×1) + (0.3×0.9) = 0 + 0.3 + 0.27 = 0.57.

[0128] This invention integrates features from the physical layer, network layer, and application layer, and uses a weighted similarity algorithm to automatically identify unknown devices, thereby achieving communication protocol matching and correctly routing the traffic of unknown physical devices to the corresponding protocol container.

[0129] (3.2) If the matching score is less than the score threshold, the corresponding communication protocol is added to the candidate pool;

[0130] Parallel verification is performed on the communication protocols with the highest matching score in the candidate pool (the top 3 can also be selected as needed). If the verification passes, the matching is successful, a routing table is established, and the connection of the unknown physical device is directly mapped to the protocol container corresponding to the corresponding communication protocol. If the verification fails, it is reported for manual processing.

[0131] Step S3 implements the route binding mechanism: Once the scoring system determines that a device belongs to a specific protocol (such as Modbus), the system will perform the following binding operation:

[0132] Container instantiation: Call or create a Modbus protocol container instance from the dynamic container engine and obtain the entry address pointer of the container in memory.

[0133] Routing table update: Create a mapping record in the system's global communication routing table. Use the network socket handle of the physical device as the "key" and the above container entry address pointer as the "value".

[0134] Traffic switching: Switch the device's subsequent data stream processing mode from "identification mode" to "pass-through mode". All subsequently received raw data frames will skip the feature extraction module and be directly injected into the corresponding isolated container for parsing via memory copying based on the routing table.

[0135] Technical effect: This mechanism achieves "one-time identification, permanent pass-through". The isolation container only processes legitimate traffic confirmed by the route, which ensures both processing efficiency and secure isolation through the container boundary.

[0136] In summary: the scoring is for selecting containers. After selecting a container, the physical device and the isolated container are "locked" together at the memory level by updating the routing table.

[0137] Step S4: Establish communication with unknown physical devices based on the routing table, and monitor the agent in real time for anomaly diagnosis and repair.

[0138] After establishing a connection and initiating communication in step S3, the system enters a long-term operation phase. This step is responsible for monitoring the operational status of the container in step S2 and performing self-repair using the capabilities of steps S1 and S2 in the event of anomalies or environmental changes. Specifically, this includes:

[0139] (4.1) Establishing communication with unknown physical devices based on routing tables includes:

[0140] Execute the local machine code in the corresponding protocol container, lock the frame boundary in the data stream through a sliding window based on the start flag, and perform CRC check;

[0141] The parsed data is converted into a unified JSON format and output through the MQTT / Kafka bus, thus decoupling the business layer from the protocol layer.

[0142] In this invention, the isolated protocol container only processes legitimate traffic that has been confirmed by routing, which ensures both processing efficiency and secure isolation through the container boundary.

[0143] (4.2) Real-time monitoring of the agent for anomaly diagnosis and repair includes:

[0144] The system reads the operational metrics of the protocol container in real time. If a memory leak or continuous heartbeat loss exceeds the preset standard (memory leak > 80%, continuous heartbeat loss > 3), the circuit breaker mechanism is triggered to destroy the current protocol container and re-execute: traverse the abstract syntax tree (AST), obtain the verification rules and translate them into local machine code, and then containerize and bind the local machine code to the interface.

[0145] This invention ensures the stability of the device communication process through abnormal fuse breaking and self-healing.

[0146] (4.3) If the protocol description packet generated by the visual PDL editor is updated or the network environment deteriorates, causing the latency to exceed the preset standard, a double buffering switch will be performed. A new protocol container will be started. The double buffering mechanism will be used to gradually migrate traffic from the old protocol container to the new protocol container to ensure that no frame of data is lost during the switch.

[0147] This invention ensures low latency and accuracy in device communication through lossless hot-switching and version rollback.

[0148] In summary, the adaptive loading method for communication protocols in lithium battery production equipment provided by this invention "staticizes" the protocol details using PDL language, "dynamicizes" the static description through translation, and "isolates" the dynamic code through a container engine, thereby achieving complete decoupling between the main program and the specific protocol. Furthermore, monitoring and maintenance are performed after communication is established to ensure high-quality communication.

[0149] Example 2

[0150] This invention provides an adaptive loading system for a communication protocol of lithium battery production equipment, comprising:

[0151] The protocol description module is configured to obtain a protocol description package generated by a visual PDL editor. The protocol description package includes a pre-compiled abstract syntax tree (AST).

[0152] The translation and encapsulation module is configured to traverse the abstract syntax tree (AST), obtain the verification rules and translate them into local machine code, and then containerize and encapsulate the local machine code and bind it to the interface.

[0153] The matching and connection module is configured to acquire the first packet of raw data sent by an unknown physical device when it accesses the network, perform multi-dimensional feature extraction, perform communication protocol matching based on the extracted multi-dimensional features, and establish a routing table.

[0154] The closed-loop control module is configured to establish communication with unknown physical devices based on the routing table and to monitor the agent in real time for anomaly diagnosis and repair.

[0155] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0156] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0157] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0158] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0159] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. An adaptive loading method for a communication protocol in lithium battery production equipment, characterized in that, include: A visual PDL editor is used to generate a protocol description package, which includes a pre-compiled abstract syntax tree (AST). Traverse the abstract syntax tree (AST), obtain the verification rules and translate them into local machine code, and then containerize and bind the local machine code to the interface. When an unknown physical device accesses the network, the system acquires the first packet of raw data it sends and performs multi-dimensional feature extraction. Based on the extracted multi-dimensional features, the system performs communication protocol matching and establishes a routing table. Communication is established with the unknown physical device based on the routing table, and the agent is monitored in real time for anomaly diagnosis and repair.

2. The adaptive loading method for the communication protocol of lithium battery production equipment according to claim 1, characterized in that, The visual PDL editor generates a protocol description package including: The visual PDL editor obtains the communication protocol configured by the user according to the preset protocol meta-model architecture and performs real-time syntax verification; the protocol meta-model architecture includes protocol header, data field, verification rules and embedded industrial features; After passing syntax validation, it is converted into a binary structure and a validation header is added to generate a .protox format protocol description packet; the structure of the .protox format protocol description packet includes: Header: Contains the start flag, version number, package length, and CRC checksum. Metadata area: Stores description information of the communication protocol in JSON format; Code section: Contains PDL source code and pre-compiled Abstract Syntax Tree (AST).

3. The adaptive loading method for the communication protocol of lithium battery production equipment according to claim 1, characterized in that, The process of traversing the Abstract Syntax Tree (AST), obtaining verification rules, and translating them into native machine code includes: The abstract syntax tree (AST) is obtained from the protocol description packet using a PDL interpreter; The abstract syntax tree (AST) is traversed by an intermediate code generator to obtain verification rules and translate them into platform-independent LLVM IR intermediate code. The LLVM IR intermediate code is compiled into native machine code using the LLVM JIT compiler.

4. The adaptive loading method for the communication protocol of lithium battery production equipment according to claim 1, characterized in that, The containerization and interface binding of the local machine code includes: Allocate independent memory pages and use cgroups v2 to create independent resource groups for the local machine code of each communication protocol; Computational resources are allocated using cpu.weight, and memory usage is limited using memory.max, thus constructing an independent protocol container; The local machine code is stored in the corresponding protocol container, NX protection is set, and standard function pointers are generated to point to each of the protocol containers.

5. The adaptive loading method for the communication protocol of lithium battery production equipment according to claim 1, characterized in that, The multidimensional features include: Physical layer characteristics, including vendor ID and MAC address OUI; Network layer characteristics, including port numbers; Application layer features, including frame structure; The communication protocol matching based on the extracted multidimensional features includes: Matching scores are calculated based on the extracted multidimensional features: Score=n1* Vendor+n2* Port+n3* FrameStructure In the formula, Score is the matching score, n1, n2, n3 are weight parameters, n1+n2+n3=1, Vendor, Port, FrameStructure are the vendor score obtained based on physical layer features, the port score obtained based on network layer features, and the frame structure score obtained based on application layer features, respectively. If the matching score is greater than or equal to the score threshold, the matching with the corresponding communication protocol is successful, a routing table is established, and the connection of the unknown physical device is directly mapped to the protocol container corresponding to the corresponding communication protocol.

6. The adaptive loading method for the communication protocol of lithium battery production equipment according to claim 5, characterized in that, If the matching score is less than the score threshold, the corresponding communication protocol will be added to the candidate pool. Parallel verification is performed on the communication protocol with the highest matching score in the candidate pool. If the verification passes, the matching is successful, a routing table is established, and the connection of the unknown physical device is directly mapped to the protocol container corresponding to the corresponding communication protocol. If the verification fails, it is reported for manual processing.

7. The adaptive loading method for the communication protocol of lithium battery production equipment according to claim 1, characterized in that, The step of establishing communication with the unknown physical device based on the routing table includes: Execute the local machine code in the corresponding protocol container, lock the frame boundary in the data stream through a sliding window based on the start flag, and perform CRC check; The parsed data is converted into a unified JSON format and output through the MQTT / Kafka bus, thus decoupling the business layer from the protocol layer.

8. The adaptive loading method for the communication protocol of lithium battery production equipment according to claim 1, characterized in that, The real-time monitoring agent performs anomaly diagnosis and repair, including: The system reads the operational metrics of the protocol container in real time. If a memory leak or continuous heartbeat loss exceeding a preset standard is detected in the protocol container, the circuit breaker mechanism is triggered to destroy the current protocol container and re-execute: traverse the abstract syntax tree (AST), obtain the verification rules and translate them into local machine code, and containerize and bind the local machine code to the interface.

9. The adaptive loading method for the communication protocol of lithium battery production equipment according to claim 1, characterized in that, If the protocol description packet generated by the visual PDL editor is updated or the network environment deteriorates, causing the latency to exceed the preset standard, a double buffering switch will be performed. A new protocol container will be started, and the traffic will be gradually migrated from the old protocol container to the new protocol container using the double buffering mechanism to ensure that no frame of data is lost during the switch.

10. An adaptive loading system for a communication protocol of lithium battery production equipment, characterized in that, include: The protocol description module is configured to obtain a protocol description package generated by a visual PDL editor, the protocol description package including a pre-compiled abstract syntax tree (AST); The translation and encapsulation module is configured to traverse the abstract syntax tree (AST), obtain the verification rules and translate them into local machine code, and then containerize and encapsulate the local machine code and bind it to the interface. The matching connection module is configured to, when an unknown physical device accesses the network, acquire the first packet of raw data sent by the device and perform multi-dimensional feature extraction, perform communication protocol matching based on the extracted multi-dimensional features and establish a routing table; The closed-loop control module is configured to establish communication with the unknown physical device based on the routing table, and to monitor the agent in real time for anomaly diagnosis and repair.

Images