A system and method for parsing PLC intermediate code based on compilation technology and automatically generating data bridge description

Abstract

The application provides a system and method for parsing PLC intermediate code based on compilation technology and automatically generating data bridge description. The system comprises: a preprocessing module for normalizing the C intermediate code generated by matIEC; a lexical analysis module for converting the code into a Token stream; a syntax analysis module for constructing an abstract syntax tree; an abstract syntax tree processing module for traversing the AST to extract type definitions, fields and memory layouts, and converting them into an internal data model; a code generation module for serializing the data model into a standardized JSON file, including data item name, type, size, offset, memory type and nested sub-items; a version management module for automatically updating the compiler version number and embedding the JSON based on CMake during building. The application realizes full-automatic extraction and standardized output of PLC data structure, eliminates manual parsing, ensures accurate memory layout, supports cross-platform integration and version consistency verification.

Description

Technical Field

[0001] This invention relates to the fields of industrial automation control technology, computer compilation technology, and data integration technology, specifically a system and method for parsing PLC intermediate code and automatically generating data bridging descriptions based on compilation technology. Background Technology

[0002] In industrial control systems, programmable logic controllers (PLCs) serve as the core control devices, and their programming typically follows the IEC 61131-3 standard. This standard specifies various programming languages, including ladder diagrams (LD), function block diagrams (FBD), sequential function charts (SFC), instruction lists (IL), and structured text (ST). Among these, structured text (ST) is often used as an intermediate representation language due to its expression capabilities similar to high-level languages ​​(such as Pascal or C) and its structured programming characteristics. In actual development processes, integrated development environments (IDEs) such as OpenPLCEditor can uniformly convert the graphical languages ​​such as ladder diagrams and function block diagrams written by engineers into ST language. Furthermore, open-source compilers such as matIEC can compile the ST language into portable C language code, which can then run in embedded environments or real-time operating systems.

[0003] However, while this multi-level compilation and conversion process enables cross-platform execution of PLC programs, it introduces a serious technical problem: data structure information is lost at each level of the compilation process. This manifests in the following ways: First, the original semantics are lost. While high-level data structures such as data blocks, global variables, arrays, and structures defined by engineers in ladder diagrams or function block diagrams retain some structured information when converted to ST language, this information is "flattened" into ordinary C structures, pointers, arrays, and complex offset calculations after ST language is further compiled into C code. The original logical grouping intent, the meaning of data type aliases, memory layout design, and other high-level semantics become difficult to discern.

[0004] Secondly, manual data parsing is extremely costly. When external systems (such as SCADA monitoring systems, MES manufacturing execution systems, data visualization platforms, digital twin systems, etc.) need to interact with the PLC, developers must manually read the massive C language code files generated by matIEC (usually containing thousands or even tens of thousands of lines of code), meticulously extracting information such as the name, data type, structure, memory offset within the structure, and array dimensions of each variable. This process is not only incredibly time-consuming but also highly error-prone. An incorrect offset calculation or data type mismatch in any field can lead to the external system reading incorrect data values, or even cause system crashes. Even more seriously, when the PLC program version is updated (e.g., adding a new field or modifying the array length), all of the above manual work must be redone, resulting in extremely high maintenance costs.

[0005] Third, memory layout information is not visible. In the C code generated by matIEC, the memory offsets of structure members are automatically calculated by the C compiler according to the alignment rules of the target platform. For example, the actual memory layout of a structure containing int16_t and uint8_t members may not be completely consistent with the declaration order in the source code due to alignment padding. External systems cannot directly obtain this offset information, but data interaction requires precise offset addresses. Whether it is direct mapping based on shared memory or register address mapping based on the Modbus protocol, it all depends on accurate offset calculation.

[0006] Fourth, there is a lack of standardized bridging interfaces. Existing technical solutions typically require developers to write a hard-coded data parsing module for each PLC program. For example, a dedicated C++ structure definition might be written for a conveyor belt control program, and another dedicated Python class definition for a robotic arm control program. This approach has extremely poor reusability; a new set of code needs to be developed for each new PLC program. Currently, there is no automated, universal method in the industry that can directly extract data structure information from the C code generated by matIEC and output a standardized description file that can be directly used by external data bridging modules.

[0007] Therefore, the industrial automation field urgently needs a parsing tool specifically designed for the end of the compilation chain: "IEC language → ST language → C language". This tool should be able to automatically extract data structure definitions and memory layout information from the final C code and output standardized description files that can be directly used by external data bridging modules, thereby opening up an automated channel for data interaction between PLC programs and external systems. Summary of the Invention

[0008] This invention aims to address the following technical problems existing in the prior art: In the C language intermediate code generated by the matIEC compiler from various programming languages ​​according to IEC61131-3, data structures are difficult to extract automatically, memory layout information is invisible, and standardized bridging descriptions are lacking. This leads to difficulties in data interaction between external systems and PLCs, low development efficiency, and high maintenance costs. Therefore, this invention provides an automated parsing, mapping, and description generation method and system, achieving fully automated extraction and standardized output of PLC data structures.

[0009] To address the aforementioned technical problems, embodiments of the present invention provide the following technical solution: a system for parsing PLC intermediate code and automatically generating data bridging descriptions based on compiler technology, comprising: The preprocessing module is used to normalize the intermediate C code generated by the matIEC compiler; The lexical analysis module, generated by the Flex tool according to the C99 standard lexical rules, is used to convert the normalized code text output by the preprocessing module into a token stream; The syntax analysis module, generated by the Bison tool according to the C99 context-free grammar rules, is used to receive the token stream output by the lexical analysis module and perform syntax deduction, constructing an abstract syntax tree during the deduction process; The abstract syntax tree processing module is used to traverse the AST constructed by the syntax analysis module, extract type definitions, field lists and memory layout information, and convert them into an internal unified data model. The code generation module is used to serialize the internal data model constructed by the abstract syntax tree processing module into a standardized JSON format file. The JSON file contains data item names, type names, type sizes, memory offsets, memory type identifiers, and a list of sub-items of nested structures. The version management module, implemented based on the CMake build system, is used to automatically update the compiler version number each time the stCompiler executable is built, and embed the version number into the generated JSON description file for the data bridging module to perform consistency verification.

[0010] Furthermore, in the second stage of the preprocessing module, the filtering algorithm based on curly brace depth scanning is specifically as follows: read the preprocessing output line by line, detect the line starting with struct, typedefstruct or typedef to mark the start of the structure definition, maintain a curly brace depth counter, increment the depth by one whenever "{" is encountered, decrement the depth by one whenever "}" is encountered, and save the complete structure definition code block when the depth reaches zero.

[0011] Furthermore, the memory type intelligent inference unit of the abstract syntax tree processing module determines the type based on the syntax pattern of the field name: if the field name string contains " If the field name contains the characters "[" and "]", the number within the square brackets is used as the array size, and the field is determined to be an array type. If neither of these matches, the field is determined to be a normal value type. For multidimensional arrays, the intelligent inference unit recursively parses the size of each dimension and calculates the total number of elements.

[0012] Furthermore, the offset automatic calculation unit of the abstract syntax tree processing module simulates the memory layout behavior of a C compiler: Starting from offset 0 at the beginning of the structure, the number of bytes occupied by each field is accumulated sequentially according to the order of field declaration; For basic types, simply use their fixed size; For pointer types, use the pointer size of the target platform; For array types, use the element size multiplied by the array length; For nested structure fields, recursively calculate the total size of the substructures and then place them as a whole at the current offset.

[0013] Furthermore, the compiler version number update strategy of the version management module is as follows: each time CMake build is executed, a script is triggered by a custom target to read the current version header file to extract the current value of the COMPILER macro, generate a random integer between [1,9] as the increment, calculate the new value equal to the current value plus the random increment, and then write it back to the file.

[0014] This invention also proposes a method for parsing PLC intermediate code and automatically generating data bridging descriptions based on compilation technology, comprising the following steps: Step S1: Receive the path to the intermediate C code file generated by the matIEC compiler, the path to the output JSON file, and the PLC program module name, which are entered by the user via the command line; Step S2: The preprocessing module performs two-stage preprocessing on the input C language intermediate code. In the first stage, GCC preprocessing commands are called to expand macros, merge header files and remove comments. In the second stage, the curly brace depth scanning algorithm is used to filter out all complete data type definitions and generate standardized C code snippets. Step S3: The lexical analysis module converts the normalized C code snippet generated in step S2 into a token stream, and the syntax analysis module performs syntax deduction on the token stream according to the C99 grammar rules and constructs an abstract syntax tree; Step S4: The abstract syntax tree processing module traverses the abstract syntax tree constructed in step S3, extracts type definition and field list information, intelligently infers the storage type of each field through memory type, calculates the memory offset of each field through the offset automatic calculation module to simulate the compiler's memory layout, and converts C language type names into internal enumeration values ​​through the type mapping module to build an internal unified data model. Step S5: The code generation module serializes the internal data model constructed in step S4 into a standardized JSON format file. The JSON file contains the program module name, version number, timestamp, data item list, and total size of the data area. Step S6: Output a JSON description file for the PLC data bridging module to read, enabling data interaction between the external system and the PLC.

[0015] Furthermore, in step S4, the specific logic for the intelligent inference of the memory type is as follows: check the name string of each field; if it contains " The character "" indicates a pointer type. If it contains "[" and "]", the array dimension is parsed and marked as an array type. If neither matches, it is marked as a normal value type. For array types, the array length information is further extracted and recorded.

[0016] Furthermore, in step S4, the automatic offset calculation module processes nested structures as follows: when encountering a nested structure field, it first recursively calculates the total size of the substructure and the relative offset of each field within it, and then places the substructure as a whole at the current offset position of the current structure. The absolute offset of each field within the substructure is equal to the starting offset of the nested field in the parent structure plus the relative offset within the substructure.

[0017] Furthermore, in step S5, the code generation module uses a recursive serialization strategy to process nested structures: when a data item in the internal data model contains a non-empty list of sub-items, its value is a JSON object or array generated by recursively calling the same serialization function; a depth limit is set during the recursion process, and an error is output and the process terminates when the preset number of levels is exceeded.

[0018] Furthermore, in the first stage of step S2, the input C language intermediate code is subjected to macro expansion, header file recursive merging, conditional compilation processing, and comment removal operations by calling the C language preprocessor, and normalized C code text without preprocessing directive interference is output. The preprocessor is configured to conform to the C99 standard and mask specific parameter macros in the matIEC generated code.

[0019] The beneficial effects of the above-mentioned technical solution of the present invention are as follows: 1. This invention fills the gap in fully automated data bridging from IEC language. In existing technologies, the transition from high-level languages ​​such as ladder diagrams and function block diagrams to the final data interaction with external systems (such as SCADA and MES) requires multiple manual conversions and coding. This invention directly operates on the C language intermediate code generated by matIEC, breaking through the final automation barrier and achieving a complete closed loop of "IEC program → executable bridging description," eliminating the need for engineers to manually read or parse any intermediate code.

[0020] 2. This invention simulates the memory layout behavior of a C compiler, automatically calculating the memory offset, size, and array dimension of each data member, and accurately distinguishing between pointers, arrays, and value types through an intelligent inference mechanism. The data bridging module does not need to guess or hardcode any offsets; it can directly generate correct memory access code based on the content of the JSON file, fundamentally avoiding data misalignment problems caused by human calculation errors.

[0021] 3. The JSON description file output by this invention adopts an open and standard data format, which can be parsed by any mainstream programming language such as Python, C++, C#, Java, and Go. This greatly enhances cross-platform integration capabilities, enabling external systems based on different technology stacks to seamlessly access PLC data.

[0022] 4. The version management module built into this invention automatically generates a unique compiler version number during each build and embeds it into the JSON description file. The data bridging module compares the version number in the JSON with the version information embedded in the PLC firmware at runtime. If they do not match, the connection is rejected and an alarm is triggered, fundamentally avoiding data parsing errors caused by the description file not being synchronized due to PLC program version updates.

[0023] 5. This invention is built upon the Flex / Bison industrial-grade compiler construction tool, boasting high accuracy in lexical and syntax analysis, and capable of handling various complex C language data type definitions. It employs the RapidJSON high-performance JSON library for output, ensuring processing times in milliseconds to seconds even for large PLC projects containing thousands of data items, meeting the real-time requirements of industrial environments. Attached Figure Description

[0024] Figure 1 This is a schematic diagram of the complete workflow provided for this invention.

[0025] Figure 2 This is a flowchart of the internal architecture of the stCompiler system.

[0026] Figure 3 This is a schematic diagram of the secondary filtering algorithm in the preprocessing module.

[0027] Figure 4 This is an example of token recognition rules for a lexical analyzer.

[0028] Figure 5 This is a logic diagram for intelligent memory type inference in the abstract syntax tree processing module.

[0029] Figure 6 This is a diagram illustrating the structure of the JSON output file.

[0030] Figure 7 Example diagram for calculating offsets of nested structures.

[0031] Figure 8 This diagram illustrates the use of the command-line tool and its interaction with the data bridging module. Detailed Implementation

[0032] To make the technical problems, technical solutions and advantages of the present invention clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0033] This invention provides a system (hereinafter referred to as stCompiler system) that parses PLC intermediate code and automatically generates data bridging descriptions based on compilation technology. This system exists as a command-line tool and can be integrated into the PLC program development process or continuous integration pipeline.

[0034] The complete workflow of the system described in this invention is as follows: IEC61131-3 program (written in any one or more languages ​​among LD / FBD / SFC / IL / ST) → converted to ST language → matIEC compiles to generate C language program → stCompiler system parses → generates JSON description file → PLC data bridge module reads JSON file → external applications (SCADA / MES / digital twin, etc.) realize data interaction with PLC.

[0035] The stCompiler system, as the core of this invention, is responsible for parsing the C language program generated by matIEC and outputting a standardized JSON description file. The PLC data bridging module (which can be a third-party module or a subsequent processing stage) reads the JSON file, dynamically constructs a memory mapping, and realizes efficient data interaction with the PLC.

[0036] stCompiler System Architecture The stCompiler system draws inspiration from classic compilers and comprises six core modules: preprocessing, lexical analysis, syntax analysis, abstract syntax tree processing, code generation, and version control. Each module is described in detail below.

[0037] (a) Preprocessing module The preprocessing module is the first step in the stCompiler parsing process. It is responsible for normalizing the intermediate C code generated by matIEC, providing clean and predictable input for subsequent lexical and syntactic analysis. This module employs a two-stage preprocessing strategy to handle complex situations commonly encountered in industrial code, such as macro definitions, conditional compilation, and multi-file organization.

[0038] Phase 1: Implementation based on GCC preprocessing commands. This phase calls GCC preprocessing commands, with the following command format: gcc-EP-std=c99-DDISABLE_EN_ENO_PARAMETERS=1-I. / lib / C; The command's functions are as follows: the -E option causes GCC to perform only preprocessing without compilation; the -P option suppresses line marker output to avoid generating extra line number information that could interfere with subsequent parsing; -std=c99 ensures that preprocessing conforms to the C99 standard and is compatible with matIEC's output; -DDISABLE_EN_ENO_PARAMETERS=1 masks specific parameter macros in the matIEC-generated code to prevent preprocessing errors; and -I. / lib / C appends the header file search path, ensuring that the preprocessing stage can correctly find dependent header files. Through this command, the preprocessing module fully processes preprocessing directives such as #include, #define, #if / #ifdef, expanding macros to their original definitions, recursively merging included header files into the main file, removing all comments and blank lines, and finally outputting a complete C code text free from preprocessing directive interference.

[0039] The second stage: Structure definition filtering. Since the preprocessing results from the first stage contain function definitions, global variable declarations, and a large amount of non-data type code (such as function implementations), directly feeding this content into the lexical analyzer would reduce parsing efficiency and potentially introduce syntactic noise. Therefore, the preprocessing module implements a filtering algorithm based on brace depth scanning. The specific steps of this algorithm are as follows: Read the preprocessing output from the first stage line by line, detecting lines starting with `struct`, `typedefstruct`, or `typedef` (but excluding `typedefenum`), marking these lines as the beginning of a structure definition; then maintain a brace depth counter, incrementing the counter by one whenever a left brace `{` is encountered, and decrementing it by one whenever a right brace `}` is encountered; when the depth counter reaches zero, it indicates that a complete structure definition has ended, and the code block is saved to the buffer. This algorithm only retains data type definitions (including structures, unions, enumerations, and `typedef` aliases), discarding all function implementations, global variable declarations, and other executable code, thus significantly narrowing the scope of subsequent processing. Furthermore, the preprocessing module supports saving the filtered intermediate results to a file specified by the user via the `-p` parameter, facilitating debugging and manual review.

[0040] (II) Lexical Analysis Module The lexical analysis module is automatically generated by the Flex tool based on the lexC99.l rule file. Its core responsibility is to convert the character sequence (i.e., normalized C code text) output by the preprocessing module into a token stream that the parser can recognize. This module strictly follows the C99 standard lexical specification and is specifically adapted to common naming conventions in industrial control code (such as identifiers starting with an underscore, __val).

[0041] The token categories identified by the module include: C99 keywords: struct, union, enum, int, char, void, typedef, const, volatile, etc. User-defined identifiers: follow the C language identifier naming rules (composed of letters, numbers, and underscores, and do not start with a number); Constants: decimal integers, hexadecimal integers (starting with 0x or 0X), floating-point numbers, string literals, and character constants; Operators: Arithmetic operators (+, -, ...) Relational operators (>, <, ==, !=), logical operators (&&, ||), bitwise operators (&, |, ^), assignment operators (=, +=, etc.), and pointer operators ( / ). 、&); Punctuation marks: curly braces ({,}), semicolons (;), commas (,), parentheses ((, )), square brackets ([, ]), etc.

[0042] Each token is generated along with its line and column number from the source file, providing precise information for locating subsequent syntax errors. The lexical rules are implemented using regular expressions to match various patterns: for example, matching identifiers like [a-zA-Z_][a-zA-Z0-9_]. Integer constants match 0[xX][0-9a-fA-F]+|[0-9]+, and string literals match \"(\\.|[^\"\\])\ \" For comments ( / / single-line comments and / (Multi-line comments) are skipped entirely by the lexical analyzer, generating no tokens and ensuring that the parser only processes valid code. The module also includes a built-in lexical error detection mechanism: when an illegal character that cannot match any rule is encountered, an error message containing the character's position and ASCII code is output, and the scanning of subsequent input continues, preventing a single point of error from interrupting the entire parsing process. Because the generated lexical analyzer is pure C code and does not depend on any external runtime libraries, it has excellent cross-platform compatibility and can run stably on embedded Linux, Windows, and various real-time operating systems.

[0043] (III) Syntax Analysis Module The syntax analysis module is generated by the Bison tool based on the parserC99.y rule file. Its function is to receive the token stream output by the lexical analyzer, perform syntax deduction according to the C99 context-free grammar rules, and construct an abstract syntax tree (AST) during the deduction process. This module is the "skeleton" of the entire parsing system, determining which code structures are considered valid data type definitions.

[0044] The syntax rules cover all productions related to data type definitions in the C99 standard, including: Complete definitions and incomplete declarations of structures (struct) and unions; Enumeration definition; Basic type specifiers (int, char, float, double and their combinations with short, long, unsigned, and signed); Type qualifiers (const, volatile); Pointer declarator; Array declarator (supports multidimensional arrays); typedef alias definition.

[0045] In particular, this module supports empty field lists (i.e., definitions like struct{};) to be compatible with the output styles of some code generation tools.

[0046] During syntax analysis, for each complete syntactic structure identified (such as a structure definition or a typedef alias definition), the module calls the corresponding AST node constructor to attach child nodes (such as field lists, type names, etc.) to the current node, forming a hierarchical tree structure. AST node types include: structure nodes, field nodes, basic type nodes, pointer type nodes, array type nodes, etc. Each node stores the syntactic structure's location information in the source code (line number, column number), name, list of child nodes, and other attributes. When encountering syntax errors (such as missing semicolons, mismatched curly braces, or incorrect type specifier order), the module employs an error recovery strategy—skipping the current token until a synchronization point is encountered (such as a semicolon or closing curly brace), then reporting a message containing the error location and expected symbol, and continuing to parse the remaining input to ensure that as many valid definitions as possible are extracted. The parser also generates pure C code, seamlessly linking with the lexical analyzer, and the entire parsing process is initiated through the yyparse() function.

[0047] (iv) Abstract Syntax Tree Processing Module The Abstract Syntax Tree (AST) processing module is the core computing engine of the stCompiler system. It is responsible for traversing the AST output by the parser, extracting type definitions, field lists, and memory layout information, and converting them into an internally unified data model. This module implements three key technical features: intelligent memory type inference, automatic offset calculation, and type mapping.

[0048] Intelligent memory type inference: This feature determines the type based on the syntax pattern of the field names. For each field, its name string is checked: If included Characters (e.g., char) If the name is a pointer type (internal enumeration value emPointer), then this field stores the address of other data, and its size is determined by the address width of the target platform (usually 4 bytes or 8 bytes). If it contains [ and] characters (e.g., int coordinates[4]), the number inside the square brackets is extracted as the array size and determined to be an array type (internal enumeration value emArray). This field occupies a continuous block of memory with a length of "element type size × array length". If neither matches, it is determined to be a normal value type (internal enumeration value emValue), and the data itself is stored directly.

[0049] For multidimensional arrays (such as intmatrix[3][4]), the module recursively parses the size of each dimension and calculates the total number of elements (e.g., 3×4=12 elements).

[0050] Automatic offset calculation: This module simulates the memory layout behavior of a C compiler. The calculation rules are as follows: Starting from offset 0 of the structure, the number of bytes occupied by each field is accumulated sequentially according to the order of field declaration. For basic types (such as int, char, float, etc.), their fixed size is used directly (e.g., int is 4 bytes, char is 1 byte); for pointer types, the pointer size of the target platform is used (obtained through compile-time configuration); for array types, "element size × array length" is used; for nested structure fields, the total size of the substructure is recursively calculated first, and then it is placed as a whole at the current offset position. The offset of each field in the substructure is relative to the starting address of the nested structure. The alignment strategy adopts compact alignment (i.e., no padding bytes are inserted), because the code generated by matIEC usually already ensures natural alignment by explicitly padding fields, requiring no additional processing. The offset calculation result is directly written to the m_offset__ member variable of the internal data model.

[0051] Type Mapping: This module converts C language type names (such as int16_t, uint32_t, structPoint) into a set of internal enumeration values ​​(eDataType), while also recording the type size. For user-defined types (defined via typedef), the module maintains a symbol table that maps aliases to the original types, ensuring correct expansion during nested parsing. For example, typedef int16_t SPEED_TYPE; will be recorded as SPEED_TYPE mapped to uint16_t. Subsequently, when encountering fields of type SPEED_TYPE, the module can correctly identify its underlying type as an unsigned 16-bit integer.

[0052] (v) Code generation module The code generation module is responsible for serializing the internal data model built by the abstract syntax tree processing module into a standardized JSON file, which serves as the direct input to the data bridging module. The module uses the RapidJSON library for high-performance writing, which provides both DOM and SAX parsing methods. In the generation scenario, it uses a Writer for streaming output, avoiding the construction of a complete DOM tree, thereby reducing memory overhead and improving processing speed.

[0053] The generation process is driven by the user-specified program module name (passed via the -n parameter). The module first searches its internal data model for a top-level structure matching that name (usually corresponding to the data area of ​​the PLC program). If found, the module and all its nested substructures are output; otherwise, the entire data structure is output. The output JSON file contains the following top-level fields: progName: Program module name, with the suffix _data__ to conform to the matIEC naming convention; version: JSON format version number, currently "1.0"; comment: An automatically generated comment indicating that the file was created automatically by the tool and should not be manually modified. date: The generation timestamp in ISO format (e.g., "2026-04-09 16:00:00"); items: A list of data items, each of which is a JSON object containing name (field name), type_name (raw type name), type_size (size in bytes), offset (memory offset), mem_type (one of "pointer", "array", or "value"), and optional array_size (array length) and subItem (a list of sub-items of a nested structure, recursively). size: The total number of bytes in the entire data area.

[0054] For nested structs, the module employs a recursive serialization strategy: when a non-empty field `m_sub_items__` is encountered, a `subItem` key is added to the JSON, whose value is a complete JSON object or array, and the same serialization function is recursively called. To prevent excessive recursion from causing stack overflow, the module sets a depth limit (default 10 levels); exceeding this limit results in an error and termination. The generated JSON file is UTF-8 encoded, with spaces used for indentation to improve readability, and a compact mode is supported for production environments. The file is finally written to disk using the `save()` method; an error code is returned if the write operation fails.

[0055] (vi) Version Management Module The version management module is implemented based on the CMake build system. It automatically updates the version number each time stCompiler is compiled, ensuring that each build artifact carries a unique identifier, which facilitates consistency verification by the data bridging module. Version information is stored in the include / version.hpp header file and includes four integer macros: MAJOR (major version number), MINOR (minor version number), PATCH (patch version number), and COMPILER` (compiler version number).

[0056] The core innovation of this module lies in the compiler version number update strategy: each time a CMake build is executed, a script is triggered via a custom target `UpdateVersion`. The script first reads the current `version.hpp` file and extracts the current value of the `COMPILER` macro using regular expressions; then it generates a random integer between 0 and 9 (using CMake's `string(RANDOM...)` command); next, it calculates the new value as the current value plus a random increment; finally, it uses `file(WRITE)` to write the replaced content back to the file. This "monotonically increasing + random step size" strategy ensures that the version number strictly increments with each build (facilitating comparison between old and new versions) while avoiding the risk of external guessing from simple +1 increments. Simultaneously, because the increment range is controlled within 0-9, the version number does not grow too rapidly, adapting to the long-term maintenance needs of industrial products.

[0057] The major, minor, and patch version numbers are manually maintained by developers and incremented during major feature changes or fixes. The module prints version update information in the build output, such as "Updated COMPILER version from 125 to 131 (added 6)," facilitating pipeline integration and tracing. During runtime, the data bridging module reads the compiler version number embedded in the PLC firmware and compares it with the `compiler_version` field in the JSON file. If they do not match, it determines that the PLC program has been updated but the description file is not synchronized, rejects the connection, and triggers an alarm, fundamentally avoiding data parsing errors caused by version mismatches. Furthermore, the version management module supports querying the current version via command-line parameters (`-v` or `--version`), allowing users to easily confirm the toolchain status.

[0058] The system described in this invention covers the entire processing chain from user input of matIEC-generated C language intermediate code to output of a standardized JSON data bridging description file. The entire process is based on the pipeline architecture of a classic compiler, sequentially going through stages such as command-line parsing, preprocessing, lexical analysis, syntax analysis, abstract syntax tree processing, data model construction, and JSON generation. The following section elaborates on each step using a typical execution scenario.

[0059] Step 1: Command line argument parsing Users launch the tool by invoking the stCompiler executable in the terminal or integrated build script, along with the necessary command-line arguments. The command-line format is: . / stCompiler -i<input file> -o<output file> -n<program module name> [-p<preprocessing output file>]; The `-i` parameter specifies the path to the C language header or source file generated by matIEC (usually in .h or .c format). This file contains the structure definitions, type aliases, and variable declarations for the PLC program data area. The `-o` parameter specifies the path to the output JSON description file. The `-n` parameter identifies the name of the PLC program module (e.g., "ConveyorSystem"), which will be used as the value of the `progName` field in the JSON root object for the data bridging module to locate the corresponding top-level data structure. The `-p` parameter is optional and is used to save the preprocessed intermediate file for debugging. Additionally, the `-h` or `--help` parameter displays help information, and the `-v` or `--version` parameter outputs the stCompiler's own version number (maintained by the version management module). The main program first parses these parameters, performs validity checks (such as whether the input file exists and whether the output directory is writable), and outputs an error message and exits if any parameter is missing or invalid.

[0060] Step 2: Preprocessing The main program passes the input file path to the preprocessing module. This module first performs the first stage of preprocessing: it calls the GCC preprocessing command, with the format `gcc-EP-std=c99-DDISABLE_EN_ENO_PARAMETERS=1<input file>-I. / lib / C`. This command expands all macros such as `#include` and `#define`, recursively merges header files, and removes comments and line markers. The preprocessing result is returned as a string stream. In the second stage, the preprocessing module uses a deep brace scanning algorithm to filter out all complete data type definitions (including aliases of `struct`, `typedefstruct`, and `typedef` definitions) from the above results, removing function definitions, global variable declarations, and executable code. The filtered pure data type definitions are stored in a `std::vector`. <char>The contents of the buffer are also written to a specified file if the user specifies the -p parameter. The final output of the preprocessing module is a normalized C code snippet containing only the definitions of structures, unions, enumerations, and type aliases, providing clean and compact input for subsequent parsing.

[0061] Step 3: Lexical and Syntactic Analysis The preprocessed code text is fed into the lexical analyzer. Generated by Flex according to the lexC99.l rules, the lexical analyzer divides the input character stream into a token stream. Each token carries its type (e.g., keyword struct, identifier Point, left curly brace {, etc.) and source code location information. The lexical analyzer automatically skips whitespace characters and comments and reports illegal characters. The token stream is then passed to the parser. Generated by Bison according to the parserC99.y rules, the parser consumes tokens progressively according to C99 syntax rules and performs syntax deduction. When the parser recognizes a complete data type definition (e.g., a struct definition), it calls the corresponding AST node constructor, dynamically creates node objects, and attaches child nodes (e.g., field lists, type specifiers) to the current node. Throughout the parsing process, the parser continuously builds one or more abstract syntax trees, with the root nodes of these trees corresponding to each top-level data type definition in the input code. If a syntax error occurs (e.g., missing semicolons, mismatched brackets), the parser attempts error recovery and outputs error information including line numbers, column numbers, and expected symbols. After parsing, all AST nodes are encapsulated in a list for traversal in the next stage.

[0062] Step 4: Abstract Syntax Tree Processing and Data Model Construction The Abstract Syntax Tree (AST) processing module receives the list of AST nodes generated in step 3. The core task of this module is to traverse each AST, extract the data structure information of interest to the user, and convert it into an internally unified data model (i.e., the hierarchical organization of the `stDataItem` structure). The traversal process uses a depth-first recursive algorithm: for each structure node, the module first creates an `stDataItem` object to represent the structure itself; then it traverses its field child nodes, creating a corresponding `stDataItem` object for each field and filling in the following key attributes: `m_name__` (field name, extracted from the identifier of the AST node), `m_type_name__` (field type name, such as `int`, `structPoint`, or pointer type `char`). `m_type_size__` (the number of bytes occupied by this type on the target platform, obtained by querying the built-in type table or recursively calculating), and `m_offset__` (the memory offset of the current field in its associated structure, calculated by summing the sizes of preceding fields and considering alignment rules). Specifically, the module identifies the memory type of a field through an intelligent inference mechanism: if the field name contains... If it contains [ and ], the array size is parsed and marked as an array; otherwise, it is marked as a normal value. For nested structure fields, the module recursively calls itself to process the substructures and attaches the stDataItem list of the sub-items to the m_sub_items__ of the parent field, while correctly calculating the offset inside the nested structure (relative to the starting address of the substructure). After processing, all top-level data items (usually the main structure corresponding to the PLC program and its dependent types) are organized into a data_t container (i.e., std::vector). <stdataitem>), waiting for the code generator to use.

[0063] Step 5: JSON Generation and Output The code generation module receives the `data_t` data model generated in step 4 and the user-specified program module name. The module first searches for a matching top-level data item in `data_t` based on the module name (usually, the name of this data item corresponds to the module name, such as `ConveyorSystem_data__`). If found, it performs JSON serialization with this item as the root; otherwise, it serializes the entire `data_t` (at which point the JSON will contain all parsed data types). The serialization process uses the `Writer` streaming output interface of the `RapidJSON` library: it creates `rapidjson::StringBuffer` and `rapidjson::Writer` objects and calls the `gen_json__()` recursive function to traverse the data model. This function first writes the start marker of the JSON object, and then outputs `progName`, `version` (fixed to "1.0"), `comment` (automatically generated timestamp and tool identifier), and `date` (current system time, in the format YYYY-MM-DDHH:MM:SS). Next, the function writes to the `items` array, iterating through all `stDataItem`s at the current level: for each data item, it writes a JSON object containing fields such as `name`, `type_name`, `type_size`, `offset`, and `mem_type`; if the data item contains sub-items (where `m_sub_items__` is not empty), it recursively calls itself to serialize the sub-items into nested JSON objects or arrays. A depth counter is set during recursion; an error is reported and the function exits if the recursion exceeds 10 levels to prevent stack overflow. After all data items have been processed, the `size` field is written, representing the total number of bytes in the entire data area. The generated JSON string is saved to the module's internal buffer and finally written to the user-specified output file using the `save()` method. Upon successful writing, the main program outputs a success message similar to "JSON description file generated: conveyor_bridge.json" to the console; if an error occurs at any stage (such as a file that cannot be opened or parsing failure), detailed error information is output and a non-zero exit code is returned.

[0064] Step 6: Version Update (triggered during build) It's important to note that version updates are not part of the runtime workflow, but rather occur during the stCompiler's own build process. Whenever stCompiler is built using CMake, the UpdateVersion custom target of the version management module is automatically executed. This reads include / version.hpp, extracts the current COMPILER macro value, generates a random increment of 0-9, calculates the new value, and writes it back to the file. Thus, each generated stCompiler executable carries a unique compiler version number. This version number is represented as the compiler_version field in the JSON file generated in step 5 (this can be added in future extensions) for the data bridging module to perform consistency checks.

[0065] Through the above six steps, stCompiler automatically transforms obscure, machine-generated C language data structure definitions into standardized JSON description files that are human-readable and machine-parsable. The entire process requires no manual intervention, and a single execution typically takes between milliseconds and seconds (depending on the input file size), significantly improving the development efficiency and reliability of data bridging from PLC programs to external systems.

[0066] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings and a complete industrial example.

[0067] like Figure 1 As shown, the complete workflow provided by this invention begins with an IEC61131-3 multilingual program (Ladder Diagram LD, Function Block Diagram FBD, Sequential Function Chart SFC, Instruction List IL, and Structured Text ST). After being represented in ST language, it is compiled by matIEC to generate C language intermediate code. Subsequently, the stCompiler system of this invention parses the C code and outputs a JSON description file. Finally, the PLC data bridging module reads the JSON file to realize data interaction between external applications (such as OPCUA servers) and the PLC. The following steps will be elaborated around this workflow.

[0068] like Figure 2 As shown, the stCompiler system's internal architecture comprises an input layer, a processing layer, and an output layer. The input layer receives the C file generated by matIEC; the processing layer consists of a preprocessing module, a lexical analysis module, a syntax analysis module, an abstract syntax tree processing module, and a version management module; the output layer generates a JSON description file through a code generation module. The tool dependencies (GCC, Flex, Bison, RapidJSON, CMake) are also marked in the diagram. The following section, using a specific example of a conveyor belt control system, explains the role of each module in this embodiment of the invention.

[0069] Step 1: Write the IEC61131-3 program (ladder diagram) The engineer used ladder diagram language to design the conveyor control logic, in which a data block named ConveyorData was defined, which contains the following fields: Speed: Data type is INT (16-bit signed integer); Running: Data type is BOOL (Boolean value); ErrorCode: Data type is ARRAY[0..5]OFBYTE (an array of 6 bytes); Position: The data type is STRUCTOF(X:INT,Y:INT) (a structure containing two integers).

[0070] This data block corresponds to Figure 1 The input section of the "IEC61131-3 procedure".

[0071] Step 2: Generate C code using matIEC. The engineer imported the ladder diagram program into OpenPLCEditor, which automatically converted it to ST language and then used the matIEC compiler to compile the ST language into a C language header file. This header file defines a structure whose members include: a 16-bit signed integer velocity variable, an unsigned 8-bit integer running status variable, a 6-byte error code array variable, and a nested structure position variable consisting of two 16-bit signed integer coordinates. The actual generated code may include alignment padding and naming conventions, but its core data type definitions are consistent with the above description. This C file serves as... Figure 1 Input to the stCompiler system.

[0072] Step 3: Call stCompiler to parse The engineer executes the following command in the command line (e.g.) Figure 8 The command-line usage shown is as follows, where the -i parameter specifies the input C header file, the -o parameter specifies the output JSON file path, and the -n parameter specifies the PLC program module name: . / stCompiler-iconveyor_iec_c.h -oconveyor_bridge.json -nConveyorSystem; The system follows Figure 2 The internal architecture process execution is analyzed below. Figures 3 to 7 The specific operation of each module in this case study will be explained.

[0073] Preprocessing stage (see Figure 3 ):like Figure 3 As shown, the preprocessing module employs a secondary filtering algorithm based on brace depth. First, it calls GCC preprocessing commands to expand all macros and include files, removing comments. Then, the algorithm scans the preprocessed results line by line, detecting lines starting with `struct` or `typedefstruct`, and maintaining a brace depth counter. When the depth reaches zero, the complete structure definition is extracted. In this case, the algorithm successfully extracted the complete structure definition corresponding to the conveyor belt data block from the input C header file, discarding all function implementations and other executable code, providing clean and compact input for subsequent parsing.

[0074] Lexical analysis and grammatical analysis stages (see...) Figure 4 Lexical analyzer according to Figure 4 The token recognition rules shown convert the preprocessed code text into a token stream. For example, the keyword `struct` is recognized as the `STRUCT` keyword, the structure name is recognized as `IDENTIFIER`, the left curly brace is recognized as `LBRACE`, and basic types such as `int16_t` are recognized as `TYPE_NAME`. The lexical analyzer automatically skips comments and whitespace characters and appends line and column numbers to each token. Subsequently, the parser performs grammatical deduction on the token stream according to the C99 grammar rules and constructs an Abstract Syntax Tree (AST). For the structure definition in this case, the parser generates an AST node representing the top-level structure, which has four field child nodes: velocity field, running status field, error code array field, and position structure field. The position structure field node itself contains two subfields: X coordinate and Y coordinate.

[0075] AST processing and memory model construction phase (see...) Figure 5 and Figure 7 The Abstract Syntax Tree (AST) processing module traverses the AST, performing intelligent memory type inference, automatic offset calculation, and type mapping. For example... Figure 5 The memory type inference logic shown in the diagram checks the name of each field: Speed ​​field: If the name does not contain pointer or array markers, it is determined to be a value type.

[0076] Running status field: also determined to be a value type.

[0077] Error code array field: The name contains an array marker, the extracted array size is 6, and it is determined to be an array type.

[0078] Position structure field: If there are no special characters in the name, it is determined to be a value type, but if its sub-item list is not empty, it indicates a nested structure.

[0079] Automatic offset calculation Figure 7 The method for calculating the offset of nested structures is shown. Starting from the initial offset of 0 in the structure, the calculations are performed sequentially: Speed ​​field: The type size is 2 bytes, and the offset is 0.

[0080] Running status field: The type size is 1 byte, and the offset is 2 (accumulated from the previous 2 bytes).

[0081] Error code array field: element type size is 1 byte, array length is 6, total size is 6 bytes, offset is 3 (3 bytes including the preceding field).

[0082] Position structure fields: The internal fields are recursively calculated: X-coordinate offset 0 (relative to the start of the position structure), Y-coordinate offset 2 (accumulating the 2 bytes of the X-coordinate), the total size of the position structure itself is 4 bytes, and the offset is 9 (accumulating the preceding fields, a total of 3 + 6 = 9 bytes). Compact alignment is used, and no padding bytes are inserted. Figure 7 The example shown demonstrates the offset calculation of each field within the parent and child structures, which is completely consistent with the calculation logic in this case.

[0083] JSON generation stage (see) Figure 6 The code generation module serializes the above data model into a JSON file. For example... Figure 6 As shown, the JSON output file contains the program module name, format version number, automatically generated comments, ISO format timestamps, a list of data items, and the total size of the entire data area in bytes. Each data item in the list includes a field name, primitive type name, type size, memory offset, and memory type identifier; for array types, it also includes the array length; for nested structures, it includes a recursive list of sub-items. The JSON file generated in this example follows... Figure 6 The structure shown includes: the top-level object has the program module name "ConveyorSystem_data__", version number "1.0", and timestamp is the ISO time of generation; the data item list describes four data items in sequence: speed, running status, error code array, and position structure. The error code array is marked as having an array length of 6. The position structure contains two nested sub-data items (X coordinate and Y coordinate), each of which contains its own name, type, size, offset, and memory type; the total size of the entire data area is 13 bytes.

[0084] Version Management: When building the stCompiler executable, the version management module automatically updates the compiler version number based on CMake. During each build, the compiler version number increments using a monotonically increasing + random step strategy. This version number can be extended into the generated JSON with a compiler version field for subsequent consistency checks by the data bridging module.

[0085] Step 4: The PLC data bridging module reads the JSON and enables interaction (see...) Figure 8 ) like Figure 8 As shown, the JSON description file generated by stCompiler is read by the PLC data bridging module. The data bridging module (implemented in Python in this embodiment) first opens and parses the JSON file to obtain a list of data items. Then, based on the memory type identifier, type size, array length, and nesting information in each data item, the module dynamically constructs a data structure that perfectly corresponds to the PLC memory layout. Specifically, for fields marked as "value type," the module selects the corresponding signed or unsigned integer type based on its type size; for fields marked as "array type," the module constructs an array type of a specified length; for fields marked as "pointer type," the module constructs a pointer type; and for nested structure fields containing sub-items, the module recursively constructs nested data structures. After completing the data structure definition, the bridging module directly maps the PLC shared memory area (or a memory buffer obtained through other communication protocols) to this dynamic data structure. Afterward, external OPCUA servers or other external applications can directly read and write data such as speed, running status, error code array elements, and position coordinates using variable names through this bridging module, without any manual offset calculations or hard coding. Figure 8 The document demonstrates the use of command-line tools and the complete workflow of JSON files being consumed by the data bridging module.

[0086] Step 5: Version Management Ensures Consistency When the conveyor belt PLC program is upgraded (e.g., by adding an acceleration field), engineers modify the ladder diagram program and rerun matIEC and stCompiler. The new version of stCompiler (whose compiler version number is automatically incremented) generates a new JSON file where the total size field and the offset values ​​of each field change. The data bridging module reads the compiler version field from the JSON file upon startup and compares it with the version information embedded in the PLC firmware. If they do not match, the bridging module refuses the connection and outputs an alarm, indicating that the PLC firmware version and the data description file version do not match, and stCompiler needs to be rerun. This fundamentally avoids data parsing errors caused by version mismatches.

[0087] Through the above steps, and with the help of Figures 1 to 8 The workflow, system architecture, algorithm flow, token rules, intelligent inference logic, JSON structure, offset calculation example, and command-line interaction shown in the diagram allow engineers to achieve efficient and reliable data bridging between the PLC and the external OPCUA server without having to manually read any C code or write hard-coded data parsing logic.

[0088] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.< / stdataitem> < / char>

Claims

1. A system for parsing PLC intermediate code and automatically generating data bridging descriptions based on compiler technology, characterized in that, include: The preprocessing module is used to normalize the intermediate C code generated by the matIEC compiler; The lexical analysis module, generated by the Flex tool according to the C99 standard lexical rules, is used to convert the normalized code text output by the preprocessing module into a token stream; The syntax analysis module, generated by the Bison tool according to the C99 context-free grammar rules, is used to receive the token stream output by the lexical analysis module and perform syntax deduction, constructing an abstract syntax tree during the deduction process; The abstract syntax tree processing module is used to traverse the AST constructed by the syntax analysis module, extract type definitions, field lists and memory layout information, and convert them into an internal unified data model. The code generation module is used to serialize the internal data model constructed by the abstract syntax tree processing module into a standardized JSON format file. The standardized JSON format file contains data item names, type names, type sizes, memory offsets, memory type identifiers, and a list of sub-items of nested structures. The version management module, implemented based on the CMake build system, is used to automatically update the compiler version number each time the stCompiler executable is built, and embed the version number into the generated JSON description file for the data bridging module to perform consistency verification.

2. The system according to claim 1, characterized in that, The memory type intelligent inference unit of the abstract syntax tree processing module determines the type based on the syntax pattern of the field name: if the field name string contains " If the field name contains the characters "[" and "]", the number within the square brackets is used as the array size, and the field is determined to be an array type. If neither of these matches, the field is determined to be a normal value type. For multidimensional arrays, the intelligent inference unit recursively parses the size of each dimension and calculates the total number of elements.

3. The system according to claim 1, characterized in that, The automatic offset calculation unit of the abstract syntax tree processing module simulates the memory layout behavior of a C compiler: Starting from offset 0 at the beginning of the structure, the number of bytes occupied by each field is accumulated sequentially according to the order of field declaration; For basic types, simply use their fixed size; For pointer types, use the pointer size of the target platform; For array types, use the element size multiplied by the array length; For nested structure fields, recursively calculate the total size of the substructures and then place them as a whole at the current offset.

4. The system according to claim 1, characterized in that, The compiler version number update strategy of the version management module is as follows: each time CMake build is executed, a script is triggered by a custom target to read the current version header file to extract the current value of the COMPILER macro, generate a random integer between [1,9] as the increment, calculate the new value equal to the current value plus the random increment, and then write it back to the file.

5. A method for parsing PLC intermediate code and automatically generating data bridging descriptions based on compiler technology, characterized in that, Includes the following steps: Step S1: Receive the path to the intermediate C code file generated by the matIEC compiler, the path to the output JSON file, and the PLC program module name, which are entered by the user via the command line; Step S2: The preprocessing module performs two-stage preprocessing on the input C language intermediate code. In the first stage, GCC preprocessing commands are called to expand macros, merge header files and remove comments. In the second stage, the curly brace depth scanning algorithm is used to filter out all complete data type definitions and generate standardized C code snippets. Step S3: The lexical analysis module converts the normalized C code snippet generated in step S2 into a token stream, and the syntax analysis module performs syntax deduction on the token stream according to the C99 grammar rules and constructs an abstract syntax tree; Step S4: The abstract syntax tree processing module traverses the abstract syntax tree constructed in step S3, extracts type definition and field list information, intelligently infers the storage type of each field through memory type, calculates the memory offset of each field through the offset automatic calculation module to simulate the compiler's memory layout, and converts C language type names into internal enumeration values ​​through the type mapping module to build an internal unified data model. Step S5: The code generation module serializes the internal data model constructed in step S4 into a standardized JSON format file. The JSON file contains the program module name, version number, timestamp, data item list, and total size of the data area. Step S6: Output a JSON description file for the PLC data bridging module to read, enabling data interaction between the external system and the PLC.

6. The method according to claim 5, characterized in that, In step S4, the specific logic for intelligent memory type inference is as follows: check the name string of each field; if it contains " The character "" indicates a pointer type. If it contains "[" and "]", the array dimension is parsed and marked as an array type. If neither matches, it is marked as a normal value type. For array types, the array length information is further extracted and recorded.

7. The method according to claim 5, characterized in that, In step S4, the automatic offset calculation module processes nested structures as follows: when encountering a nested structure field, it first recursively calculates the total size of the nested structure and the relative offset of each field inside it, and then places the nested structure as a whole at the current offset position of the current structure. The absolute offset of each field in the nested structure is equal to the starting offset of each field in the nested structure in the parent structure plus the relative offset of the corresponding field.

8. The method according to claim 5, characterized in that, In step S5, the code generation module uses a recursive serialization strategy to process nested structures: when a data item in the internal data model contains a non-empty list of sub-items, its value is a JSON object or array generated by recursively calling the same serialization function; a depth limit is set during the recursion process, and an error is output and the process terminates when the preset number of levels is exceeded.

9. The method according to claim 5, characterized in that, In the first stage of step S2, the input C language intermediate code is subjected to macro expansion, header file recursive merging, conditional compilation processing, and comment removal operations by calling the C language preprocessor, and normalized C code text without preprocessing directive interference is output. The preprocessor is configured to comply with the C99 standard and to mask specific parameter macros in the matIEC generated code.

Images