A method for implementing a multi-terminal industrial automation unified programming configuration platform compatible with a standard industrial control kernel

Abstract

This invention relates to the field of industrial automation control technology, specifically to a method for implementing a multi-terminal unified programming configuration platform for industrial automation that is compatible with standard industrial control kernels. The method includes the following steps: unified engineering parsing and intermediate representation construction; target terminal configuration and consistency verification; generation of multi-terminal runtime packages and symbol files; terminal deployment and loading and standard service operation; and runtime data feedback and online operation and maintenance management. By generating a target-independent intermediate representation through unified lexical and syntactic parsing and semantic normalization, the problems of repeated compilation and variable inconsistency across multiple terminals are solved, achieving global reuse through a single parsing. By constructing a cross-terminal constraint graph containing variable production-consumption edges and temporal constraints and projecting it to generate deployment slices, the problems of missing global constraint modeling and coarse resource allocation are solved. By persisting the constraint graph as an operation and maintenance index and locating anomalies based on association relationships and comparing versions to determine the scope of changes, the problem of lacking a global index for operation and maintenance is solved.

Description

Technical Field

[0001] This invention relates to the field of industrial automation control technology, and more specifically, to a method for implementing a multi-terminal unified programming configuration platform for industrial automation that is compatible with standard industrial control kernels. Background Technology

[0002] In industrial automation and intelligent manufacturing scenarios, a complete industrial control system typically needs to be deployed simultaneously across multiple heterogeneous terminals such as PLCs, HMIs, and SCADA systems. These terminals differ significantly in hardware architecture, operating systems, and runtime environments. Currently, the industry generally adopts an independent development model for each type of terminal. The compilation and parsing processes for each terminal are independent, and the project configurations are stored in a dispersed manner. This makes it difficult to achieve unified adaptation of global variable management, task scheduling rules, runtime communication, and debugging services. Integrated compilation, standardized deployment, and global collaborative operation across multiple terminals have become long-standing technical challenges for the industry.

[0003] Specifically, the existing development system requires configuring dedicated compilation and parsing modules and target code generation rules for each PLC, HMI, and SCADA terminal. For the same set of engineering data, lexical and syntactic analysis, variable validation, and resource allocation must be repeatedly performed. This not only results in low reusability in the compilation process and long development cycles, but also, because each terminal maintains its own local variable table, it is highly susceptible to data consistency defects such as inconsistent variable definitions, mismatched input / output mappings, and task execution timing conflicts. Regarding cross-terminal data interaction, the lack of a globally unified variable semantic identification and association mechanism means that interaction relationships rely on hardware physical address binding. Once the variable configuration or task parameters within the project are adjusted, each terminal's program and configuration file must be manually modified, resulting in a large workload for maintenance and a high risk of cross-terminal data interaction failures and operational anomalies.

[0004] Meanwhile, the existing compilation architecture lacks a unified intermediate representation decoupled from terminal hardware architecture and operating system type. During the compilation phase, it cannot perform unified constraint modeling of global variables, tasks, hardware resources, and interactive reference relationships, and can only perform local resource verification at the single-terminal level. Faced with the differentiated hardware resource boundaries and real-time operation requirements of multiple terminals, there is a lack of a unified constraint strategy to accurately decompose the global project according to the terminal dimension. It is difficult to divide the global project into suitable program subsets, resource access permissions, and task scheduling priorities for each terminal. Developers can only manually divide project segments, which easily leads to operational problems such as terminal memory resource overflow, real-time task preemption conflicts, and interface acquisition task lag. The independently configured scheduling strategies and resource access rules for each terminal cannot achieve multi-terminal collaborative task scheduling, safe variable access, and standardized communication services based on a common set of global constraints.

[0005] Furthermore, existing compilation process data only serves temporary code generation and does not persistently save the variables, tasks, and resource relationships of the global project. The development side lacks a global index carrier for online operation and maintenance. When the running status, diagnostic data, and alarm information of each terminal are returned, only local fault diagnosis can be performed on a single terminal. It is impossible to rely on the global project relationships to achieve cross-terminal anomaly tracing and online monitoring of global variables. In scenarios of program hot updates and version rollbacks, updates can only be deployed individually on a single terminal. It is impossible to globally determine the scope of terminals affected by configuration changes, related variables, and business tasks, resulting in low efficiency for online debugging and version control.

[0006] In summary, the pressing technical challenge lies in how to generate runnable target packages for various terminals, operating systems, and hardware architectures based on a unified engineering and standardized industrial control program model, and how to achieve consistent task scheduling, variable access, communication services, and online debugging on the standard industrial control kernel through a runtime adaptation layer. Existing traditional compilation and deployment architectures cannot achieve unified parsing of the global project, unified management of cross-terminal constraints, standardized runtime adaptation, and end-to-end operation and maintenance traceability, making it difficult to meet the practical needs of efficient development, stable collaborative operation, and convenient operation and maintenance debugging of industrial control engineering in multi-terminal heterogeneous scenarios. Summary of the Invention

[0007] This invention addresses the technical problems in existing technologies, such as fragmented compilation and deployment of multi-terminal industrial control engineering, lack of globally unified constraint modeling, and lack of a global index carrier for online operation and maintenance. It provides a method for implementing a unified programming configuration platform for multi-terminal industrial automation that is compatible with a standard industrial control kernel. This method constructs a target-independent intermediate representation set decoupled from the target runtime environment through unified engineering parsing, generates a cross-terminal variable-task-resource consistency constraint graph, and projects it as a deployment constraint slice for each terminal. Based on this, it generates runtime execution packages adapted to different terminals and unified symbol tag files carrying cross-terminal semantic identifiers. Based on the standard industrial control kernel service interface, it realizes integrated deployment, consistent task scheduling, and global collaborative operation and maintenance of multiple terminals.

[0008] To solve the above-mentioned technical problems, this invention provides a method for implementing a multi-terminal unified programming configuration platform for industrial automation that is compatible with standard industrial control kernels, comprising the following steps: S1. Unified Engineering Parsing and Intermediate Representation Construction: Reads integrated engineering data containing PLC control program, HMI configuration configuration, and SCADA monitoring configuration, and processes it through the compilation front-end parsing to extract variable definitions, task configurations, input / output mapping relationships, screen binding relationships, and monitoring object reference relationships, generating a target-independent intermediate representation set that is decoupled from the target operating environment; S2. Target Terminal Configuration and Consistency Verification: Generate target configuration description files based on the hardware architecture, system platform, running role, and resource boundaries of multiple target terminals, and perform cross-terminal engineering data consistency verification based on unified variable semantic rules; S3. Generation of Multi-Terminal Runtime Packages and Symbol Files: Based on the target-independent intermediate representation set and the target configuration description file, a cross-terminal variable-task-resource consistency constraint graph is constructed; based on the cross-terminal variable-task-resource consistency constraint graph, deployment constraint slices containing variable roles, resource boundaries, and real-time priorities are generated by projecting the graph onto each target terminal; runtime execution packages adapted to PLC terminals, HMI terminals, and SCADA terminals are generated based on the deployment constraint slices, and unified symbol tag files carrying cross-terminal semantic identifiers are generated simultaneously; and the cross-terminal variable-task-resource consistency constraint graph is saved as an online operation and maintenance index on the development side. S4. Terminal Deployment Loading and Standard Service Execution: Various runtime execution packages, corresponding deployment constraint slices, and unified symbol tag files are distributed to the corresponding target terminals. The terminal runtime adaptation layer completes resource loading, variable registration, and scheduling configuration based on the deployment constraint slices, completes cross-terminal variable semantic registration based on the unified symbol tag file, and executes corresponding business tasks based on the standard industrial control kernel service interface, dynamically scheduling system resources according to real-time priority. S5. Operational Data Feedback and Online Operation and Maintenance Management: During operation, each terminal will send its running status, diagnostic data, and alarm information back to the development end. Based on the saved cross-terminal variable-task-resource consistency constraint diagram, the terminal will complete the diagnosis of operational anomalies, online variable monitoring, determination of program hot update range, and version rollback operation.

[0009] As a further improvement to this technical solution, step S1, unifying engineering parsing and intermediate representation construction, includes the following steps: S1.1 Perform syntax parsing processing on the integrated engineering data. The lexical analysis unit and syntax analysis unit of the compilation front end complete the legality verification of the engineering file and construct the original syntax tree set of the corresponding PLC control program, HMI configuration configuration and SCADA monitoring configuration. S1.2 Traverse the original syntax tree set of the project, extract five core project elements according to object type: variable definition, task configuration, input / output mapping relationship, screen binding relationship and monitoring object reference relationship, and generate a standardized set of element items; S1.3 Perform global semantic normalization on the standardized element item set to unify the global variable namespace, data type definition, object reference rules and address identification rules; S1.4 Based on the normalized core engineering elements, construct abstract semantic nodes that are decoupled from the target hardware architecture, target system platform, and target operating environment, and attach the attribute parameters and association identifiers of the corresponding elements to each abstract semantic node; S1.5. All abstract semantic nodes are structurally integrated according to variable dimension, task dimension, interaction dimension, and communication dimension, and assembled into a target-independent intermediate representation set.

[0010] As a further improvement to this technical solution, step S2, the target terminal configuration and consistency verification, includes the following steps: S2.1 Collect hardware architecture, system platform, running role and resource boundary parameters of multiple types of target terminals, and summarize them to form a set of terminal attribute parameters; S2.2 Based on the set of terminal attribute parameters, generate target configuration description files for each target terminal according to a standardized structure; S2.3 Read the target-independent intermediate representation set and extract the semantic definitions, relationships, and mapping configuration information of all variables; S2.4. Based on the unified variable semantic rules and the target configuration description files of each target terminal, perform cross-terminal engineering data consistency verification. S2.5 Record the consistency verification results, mark the engineering data items that do not conform to the rules, and generate a verification result list.

[0011] As a further improvement to this technical solution, the generation of multi-terminal runtime packages and symbol files in step S3 includes the following steps: S3.1 Based on the engineering semantic elements in the target-independent intermediate representation set and the terminal constraint parameters in the target configuration description file, construct a cross-terminal variable-task-resource consistency constraint graph; S3.2 Based on the cross-terminal variable-task-resource consistency constraint graph, projection processing is performed with each target terminal as an independent projection dimension to generate a deployment constraint slice containing variable roles, resource boundaries and real-time priority; S3.3. Based on the deployment constraint slices of each target terminal, generate runtime execution packages adapted to PLC terminals, HMI terminals, and SCADA terminals respectively, and simultaneously generate unified symbol tag files carrying cross-terminal semantic identifiers. S3.4 Bind the cross-terminal variable-task-resource consistency constraint graph with the corresponding project version identifier and save it as an online operation and maintenance index on the development side.

[0012] As a further improvement to this technical solution, step S3.1 involves constructing a cross-terminal variable-task-resource consistency constraint graph, which includes the following steps: S3.11 Extract the engineering element data corresponding to variable definitions, task configurations, input-output mapping relationships, screen binding relationships, and monitoring object reference relationships from the target-independent intermediate representation set; S3.12 Extract the terminal parameter data corresponding to the hardware architecture, system platform, running role and resource boundary of each target terminal from the target configuration description file; S3.13. Based on the extracted engineering element data and terminal parameter data, generate variable nodes, task nodes, terminal nodes, screen binding relationship nodes, monitoring object reference nodes, and resource nodes respectively; S3.14. Incorporate all nodes into the graph structure to complete the node construction of the cross-terminal variable-task-resource consistency constraint graph.

[0013] As a further improvement to this technical solution, after completing the node construction of the cross-terminal variable-task-resource consistency constraint graph in step S3.1, the following steps are also included: S3.15. Based on the relationships between nodes, generate variable production edges, variable consumption edges, node ownership edges, resource binding edges, and time-series constraint edges; use variable production edges, variable consumption edges, node ownership edges, resource binding edges, and time-series constraint edges as constraint edges. S3.16 Attach corresponding attribute parameters to each node, and attach corresponding variable roles, refresh time limits, resource boundaries and real-time priority attributes to each constraint edge; S3.17. Based on all nodes and attributed constraint edges, a complete cross-terminal variable-task-resource consistency constraint graph is formed.

[0014] As a further improvement to this technical solution, step S3.2, generating a deployment constraint slice that includes variable roles, resource boundaries, and real-time priority, includes the following steps: S3.21. Select the terminal node corresponding to a single target terminal as the projection start node; S3.22. Starting from the projection start node, perform an associative traversal along each constraint edge and mark all associated nodes and edges. S3.23. Extract all marked nodes and edges to form a subgraph structure corresponding to the target terminal; S3.24. Generate deployment constraint slices containing variable roles, refresh time limits, resource boundaries, and real-time priority based on the subgraph structure.

[0015] As a further improvement to this technical solution, step S3.3, generating the runtime execution package and unified symbol tag file, includes the following steps: S3.31. Read the deployment constraint slice of the corresponding target terminal, generate memory layout information and communication resource binding information according to the resource boundaries in the deployment constraint slice, generate task scheduling parameter configuration information according to the real-time priority in the deployment constraint slice, and generate the runtime execution package of the corresponding target terminal. S3.32. Based on the global variable definition of the cross-terminal variable-task-resource consistency constraint graph, generate a corresponding cross-terminal semantic identifier for each variable; S3.33. Combine the variable roles, resource boundaries, and real-time priority information in each deployment constraint slice to generate a unified symbol tag file that carries cross-terminal semantic identifiers and the corresponding relationship of deployment constraint slices.

[0016] As a further improvement to this technical solution, in step S4, the terminal deployment, loading, and standard service operation include the following steps: S4.1 Establish communication links between the development end and each target terminal, and send the runtime execution package, corresponding deployment constraint slice and unified symbol tag file adapted to PLC terminal, HMI terminal and SCADA terminal to the corresponding target terminal one by one; S4.2 The terminal runtime adaptation layer of each target terminal reads the corresponding deployment constraint slice, completes resource loading according to the resource boundaries in the deployment constraint slice, completes variable registration according to the variable roles in the deployment constraint slice, and completes scheduling configuration according to the real-time priority in the deployment constraint slice. S4.3 The terminal runtime adaptation layer of each target terminal reads the corresponding unified symbol tag file, and completes the cross-terminal variable semantic registration based on the cross-terminal semantic identifier and deployment constraint slice correspondence in the unified symbol tag file. S4.4 The terminal runtime adaptation layer of each target terminal is based on the standard industrial control kernel service interface and executes the corresponding business tasks. S4.5 The terminal runtime adaptation layer of each target terminal dynamically schedules the terminal's computing resources, storage resources, and communication resources based on the real-time priority and resource boundaries in the deployment constraint slice.

[0017] As a further improvement to this technical solution, S5, the operation data feedback and online operation and maintenance management, includes the following steps: S5.1 When each target terminal is running, it collects running status, diagnostic data and alarm information according to the variable roles and refresh time limits in the corresponding deployment constraint slice, and sends the collected data back to the development end. S5.2 The development end receives the returned data and, based on the project version identifier corresponding to the data, retrieves the saved cross-terminal variable-task-resource consistency constraint diagram for the corresponding project version. S5.3 Based on the constraint edge association relationship in the cross-terminal variable-task-resource consistency constraint graph, locate the node and link corresponding to the operation anomaly, perform operation anomaly diagnosis, and perform online variable monitoring in combination with the returned data; S5.4. Based on the version difference comparison of the cross-terminal variable-task-resource consistency constraint graph, determine the terminal range and variable range affected by the program hot update, retrieve the deployment constraint slice of the corresponding version, and perform a version rollback operation.

[0018] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. This invention constructs a compilation front-end to perform unified lexical and syntactic parsing on integrated PLC, HMI, and SCADA engineering data, extracts five core elements such as variable definitions, task configurations, and input / output mappings, and performs global semantic normalization. It assembles these elements into a target-independent intermediate representation set that is decoupled from the target hardware architecture and operating system. This solves the problem of having to configure compilation modules separately and repeatedly execute parsing and verification in a multi-terminal independent development mode, achieving the effect of global reuse of multi-terminal engineering data after one-time parsing and eliminating inconsistent variable definitions and mismatched mapping relationships from the source. 2. By extracting engineering elements such as variables, tasks, and mapping relationships from the target-independent intermediate representation, and combining parameters such as the hardware architecture and resource boundaries of each terminal, a cross-terminal consistency constraint graph is constructed, which includes variable nodes, task nodes, terminal nodes, variable production edges, consumption edges, and timing constraint edges. The graph is then projected along the constraint edges to each target terminal to generate deployment constraint slices containing variable roles, resource boundaries, and real-time priorities. This solves the problem that the existing compilation architecture lacks a unified intermediate representation carrier and cannot perform unified constraint modeling of global variables, tasks, and hardware resources. It achieves the effect that program subsets, resource permissions, and task scheduling priorities of each terminal can be accurately divided and uniformly allocated under global constraints. 3. This invention persistently saves the cross-terminal consistency constraint graph as an online operation and maintenance index on the development side after binding it with the project version identifier. After each terminal returns the running status and alarm information, it locates anomalies based on the association relationships such as variable production and consumption edges and node ownership edges in the constraint graph. It determines the terminals and variable range affected by hot updates and version rollbacks based on the version difference comparison of the constraint graph. This solves the problems of non-persistent data in the compilation process and lack of a global index carrier for online operation and maintenance, and achieves the effect of cross-terminal anomaly traceability and global determination of the impact of program changes. Attached Figure Description

[0019] Figure 1 This is a schematic diagram of the overall method steps of the present invention. Detailed Implementation

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

[0021] like Figure 1 As shown, this embodiment provides a method for implementing a unified programming configuration platform for multi-terminal industrial automation that is compatible with standard industrial control kernels. This method integrates PLC control logic, HMI human-machine interface configuration, and SCADA monitoring configuration into unified engineering data. Through unified parsing and intermediate representation construction, semantic conflicts and platform dependencies between multiple data sources are eliminated. The method includes the following steps: S1. Unified Project Parsing and Intermediate Representation Construction: This step reads the integrated project data containing PLC control programs, HMI configuration settings, and SCADA monitoring configurations. After parsing and processing by the compilation front-end, it extracts variable definitions, task configurations, input / output mapping relationships, screen binding relationships, and monitoring object reference relationships, generating a target-independent intermediate representation set decoupled from the target operating environment. Specifically, this step reads the integrated project data containing PLC control programs, HMI configuration settings, and SCADA monitoring configurations. After parsing and processing by the compilation front-end, it generates a target-independent intermediate representation set decoupled from the target operating environment. The integrated project data file uses a structured format, organizing content under the same project root node according to the three configuration fields: PLC, HMI, and SCADA. After receiving the compilation command, the compilation front-end executes the following sub-steps sequentially: S1.1 Perform syntax parsing processing on the integrated engineering data. The lexical analysis unit and syntax analysis unit of the compilation front end complete the legality verification of the engineering file and construct the original syntax tree set of the corresponding PLC control program, HMI configuration configuration and SCADA monitoring configuration. Specifically, the lexical analysis unit of the compiler frontend reads the project file and segments the character stream into a sequence of tokens according to predetermined lexical rules. Token types include keywords, identifiers, numeric literals, string literals, and delimiters. The syntax analysis unit takes the token sequence as input and performs shift-reduce analysis based on the context-free grammar corresponding to the project data format, simultaneously verifying the validity of the project file. For token combinations that do not conform to the grammar definition, the syntax analysis unit outputs error codes and row and column position information from the source file for engineers to locate and correct.

[0022] After successful verification, the syntax analysis unit constructs the original syntax tree for each of the three domains: PLC control program, HMI configuration configuration, and SCADA monitoring configuration. The root node of each syntax tree is labeled with the corresponding configuration domain type, and the child nodes expand layer by layer according to the structure of program organization unit, task configuration section, variable declaration section, screen object tree, and acquisition point list. The nodes also retain the source file location information and the original identifier name.

[0023] S1.2 Traverse the original syntax tree set of the project, extract five core project elements according to object type: variable definition, task configuration, input / output mapping relationship, screen binding relationship and monitoring object reference relationship, and generate a standardized set of element items; Specifically, the compiler frontend traverses each syntax tree according to predefined node matching rules, extracting five categories of core project elements. These include: Extract variable definition elements from the variable declaration section, and record the variable name, data type, initial value, address mapping, and read / write attributes; Extract task configuration elements from the task configuration section and record the task name, priority, cycle time or triggering condition, and list of associated program organization units. Extract the input / output mapping relationship from the hardware configuration section and record the physical channel logical address, associated variable name and refresh direction; Extract screen binding relationships from the HMI screen control tree and record control identifiers, bound variable names, and refresh cycles; Extract the reference relationships of monitored objects from the SCADA acquisition point definition, and record the monitoring object identifier, reference variable name, alarm threshold and storage policy.

[0024] The extracted feature entries are standardized by unifying field names and filling missing field default values ​​to form a set of standardized feature entries. Each entry is appended with a source domain tag and a syntax tree path index.

[0025] S1.3 Perform global semantic normalization on the standardized element item set to unify the global variable namespace, data type definition, object reference rules and address identification rules; Specifically, this step is used to eliminate naming conflicts, type definition ambiguities, and address inconsistencies caused by independent configurations across multiple domains. First, a global symbol table is established to merge variable names from the three domains: variables with the same name and matching type are considered the same variable and merged; variables with the same name but conflicting types generate warning messages and retain original copies. Data types are uniformly mapped according to a preset basic type system, which includes Boolean, 8 / 16 / 32 / 64-bit signed and unsigned integers, 32 / 64-bit IEEE 754 floating-point numbers, fixed-length strings, time types, and user-defined arrays, structures, and enumerations. Precision differences are handled with upward compatibility based on security principles, and conversion rules are recorded.

[0026] Object reference rules are unified into hierarchical reference paths based on a global symbol table, eliminating ambiguity in relative paths and aliases. Address identification rules unify the address representation of different fieldbuses into a logical address model that includes fields such as bus type identifier, slave address, slot number, and channel offset, and maintain a mapping table between logical addresses and physical addresses.

[0027] S1.4 Based on the normalized core engineering elements, construct abstract semantic nodes that are decoupled from the target hardware architecture, target system platform, and target operating environment, and attach the attribute parameters and association identifiers of the corresponding elements to each abstract semantic node; Specifically, this step takes the normalized engineering elements as input and constructs a corresponding abstract semantic node for each element. The design goal of the abstract semantic node is to completely strip away the specific details related to the target hardware architecture, operating system, and runtime environment, retaining only the semantic information at the engineering logic level.

[0028] The specific construction rules are as follows: Each variable definition element generates a variable node, which records the variable's globally unique identifier, normalized data type, initial value, whether it needs to be retained after power failure, and normalized logical address binding information; Each task configuration element generates a task node, which records the task name, scheduling priority, loop period or triggering condition, list of associated program organization units, and worst-case execution time; Each screen binding relationship element generates an interaction node, which records the control type, control identifier, bound variable reference path, refresh strategy, and operation permissions; Each monitored object reference element generates a monitoring node, which records the reference variable path, alarm threshold set, dead zone width, and storage strategy.

[0029] In addition to generating the four types of nodes mentioned above, the compilation frontend also extracts communication relationships from I / O mapping elements and cross-domain variable references to generate communication nodes. A communication node describes the basic attributes of a data exchange link, including the logical identifiers of the nodes at both ends of the link, the type of communication protocol used, logical address information, data length, and refresh cycle.

[0030] In addition to attaching basic attribute parameters, each abstract semantic node also attaches association identifiers. For example, variable nodes are associated with each other through a "producer-consumer" relationship identifier, task nodes are associated with the variable nodes they access through "read" and "write" relationship identifiers, interaction nodes and monitoring nodes are associated with their corresponding variable nodes through a "binding" relationship identifier, and communication nodes are associated with their data source variables and destination variables through a "connection" relationship identifier. These associations are recorded in the form of references, and the global identifiers of the associated nodes are stored in the node data structure.

[0031] The resulting set of abstract semantic nodes constitutes an engineering logic relationship diagram that does not contain any platform-related information, providing complete input for subsequent cross-terminal consistency verification and runtime package generation.

[0032] S1.5. All abstract semantic nodes are structurally integrated according to variable dimension, task dimension, interaction dimension, and communication dimension, and assembled into a target-independent intermediate representation set.

[0033] Specifically, the implementation process for structured integration is as follows: At the variable level, all variable nodes are organized into a variable definition table. Each entry in the table uses a globally unique internal variable identifier as its index key and includes fields such as the variable's global path, data type structure description, initial value, persistence flag, and logical address binding. This table serves as the unified entry point for all subsequent compilation steps to query variable definition information.

[0034] At the task level, a task-variable association structure is established with task nodes at its core. This structure describes the read-write relationship of each task to the variables it accesses through directed edges. The edge attributes indicate the access type, data refresh cycle, and the priority weight of the variable in that task. Simultaneously, the priority partial order relationship between tasks is recorded, providing a basis for subsequent scheduling parameter configuration.

[0035] In terms of interaction, interaction nodes and monitoring nodes are uniformly incorporated into the front-end interaction model. For HMI interaction nodes, a tree structure is established according to the screen hierarchy, with leaf nodes representing specific controls and branch nodes representing screen containers. For SCADA monitoring nodes, a group-monitoring point inclusion relationship is established according to monitoring groups. Each interaction node and monitoring node points to the corresponding entry in the variable dimension table through a binding reference edge.

[0036] In terms of communication, all communication nodes and their associated source and destination variables are integrated into a data exchange description block. Each description block contains the communication protocol type, logical address field assembly rules, triggering method (periodic triggering or change triggering), and default action in case of communication failure.

[0037] The data blocks of the above four dimensions, along with the cross-reference indexes between nodes, together constitute a target-independent intermediate representation set. This set is stored in a unified internal data format and serves as the sole input source for the target terminal configuration and consistency verification steps in subsequent S2. Since all platform dependencies have been eliminated during the construction process, this intermediate representation set can serve the parallel generation of runtime packages for different types of target terminals without modifying its content.

[0038] S2. Target Terminal Configuration and Consistency Verification: Based on the hardware architecture, system platform, running roles, and resource boundaries of various target terminals, a target configuration description file is generated. Cross-terminal engineering data consistency verification is then performed based on unified variable semantic rules. Specifically, after constructing a unified engineering parsing and target-independent intermediate representation set, the target terminal configuration and consistency verification phase begins. The main purpose of this step is to generate standardized terminal configuration description files based on the hardware and software characteristics of the various target terminals actually selected in the project. Using these files as a reference, cross-terminal consistency checks are performed on the engineering data in the intermediate representation set to ensure that variable definitions, type mappings, and reference relationships are consistent across multiple terminals, avoiding semantic conflicts from being introduced into subsequent runtime package generation and on-site deployment. The specific implementation includes the following sub-steps: S2.1 Collect hardware architecture, system platform, running role and resource boundary parameters of multiple types of target terminals, and summarize them to form a set of terminal attribute parameters; Specifically, in actual engineering projects, the target terminals may be PLC controllers, HMI human-machine interface devices, and SCADA monitoring servers from different manufacturers and of different models, or they may be virtualized soft PLCs or edge computing nodes. In order to automatically generate deployment constraints and runtime packages that match each terminal, it is first necessary to obtain the attribute parameters of these terminals.

[0039] The collected information includes four aspects: First, the hardware architecture, such as CPU model, word length, available memory capacity, non-volatile storage capacity, whether it has a floating-point unit, and whether it has a hardware encryption module; second, the system platform, such as the type and version of the real-time operating system, the type and version of the runtime kernel, and the type of task scheduling strategy supported; third, the running role, that is, the functional role assigned to the terminal in this project, marked as a PLC execution terminal, HMI display terminal, or SCADA data acquisition terminal, and some terminals may assume a composite role; fourth, resource boundaries, including the maximum number of configurable tasks, the maximum number of registerable variables, the upper limit of single task stack space, the number of communication ports and the maximum message length supported by each port, and the minimum configurable granularity of the I / O refresh cycle.

[0040] These parameters come partly from specifications stored in a pre-configured terminal model database on the development side, and partly from parameters manually selected and entered by engineers in the project configuration interface. The system aggregates these collected parameters by terminal instance, forming a set of terminal attribute parameters. Each record in the set corresponds to a specific terminal instance, and the record contains the unique identifier of the terminal instance, the terminal type, the model, and the complete fields of the four types of attributes mentioned above.

[0041] S2.2 Based on the set of terminal attribute parameters, generate target configuration description files for each target terminal according to a standardized structure; Specifically, based on the set of terminal attribute parameters, the system generates a corresponding target configuration description file for each target terminal instance according to a predefined standardized structure.

[0042] The standardized structure uses a segmented description method, generally including the following sections: Terminal Identifier Section, recording the terminal instance identifier, terminal type and model; Hardware Resource Section, describing CPU processing power, memory boundaries, non-volatile memory boundaries, floating-point operation support status and I / O channel specifications; System Platform Section, describing the operating system type and version, kernel type and version, supported task scheduling policies and timer resolution; Running Role Section, describing the role type undertaken by the terminal and the corresponding list of functional constraints; Communication Resource Section, describing the number of available communication interfaces, the protocol stack versions supported by each interface, the maximum data length per frame and port buffer capacity; Variable Bearing Boundary Section, giving the maximum number of variables allowed to be registered by the terminal, the maximum allowed type nesting depth, and the upper limit of string length.

[0043] The target configuration description file is stored using the same serialization format as the intermediate representation set, ensuring that it can be directly parsed and referenced by the compilation backend in subsequent steps. Through this standardized structure, the differences between different terminal models are uniformly abstracted into a set of quantifiable and comparable constraint parameters, establishing a consistent parameter benchmark for subsequent consistency checks and slice generation.

[0044] S2.3 Read the target-independent intermediate representation set and extract the semantic definitions, relationships, and mapping configuration information of all variables; Specifically, after obtaining the target configuration description files for each target terminal, the consistency verification still needs to read the required information from the constructed target-independent intermediate representation set. S2.3 is mainly responsible for extracting the semantic definitions, relationships, and mapping configuration information of all variables.

[0045] The specific operation involves traversing all variable nodes in the variable definition table representing the intermediate set, reading each variable's internal identifier, global path, data type structure, initial value, persistence flag, and logical address binding field one by one. Simultaneously, it extracts information from the task-variable association graph about which tasks access the variables and how, from the human-computer interaction and monitoring front-end model about which interaction nodes and monitoring nodes the variables are bound to, and from the data exchange description block set about which cross-terminal communication links the variables participate in. It also synchronously extracts parameters such as the communication protocol type, single-frame effective data length, refresh cycle, and triggering method for the corresponding links.

[0046] The extracted information is organized into a summary table of variable semantic information. The primary key of the table is the global path of the variable, and the remaining columns include the variable's role label on each terminal, the data type mapping on each terminal, the source domain and reference method of the variable in all its occurrences in the project. The summary table fully reflects the semantic picture of each variable in the entire project and serves as input data for the next step of verification.

[0047] S2.4. Based on the unified variable semantic rules and the target configuration description files of each target terminal, perform cross-terminal engineering data consistency verification. Specifically, the unified variable semantic rules cover the following aspects: The first rule is the type compatibility rule. This rule also covers the type conflicts of the same variable across multiple domains marked in the S1.3 semantic normalization stage. It requires that the data type mapping results of the same variable on different terminals and different configuration domains be compatible within the basic type system, and fundamental conflicts such as one terminal interpreting it as Boolean while another terminal interprets it as integer are not allowed. Among them, fundamental type conflicts marked in the S1 stage are uniformly judged as error level, while precision difference conflicts are retained as warning level. If a variable is mapped as a 16-bit unsigned integer on the PLC terminal and as a 32-bit unsigned integer on the HMI terminal, it is considered acceptable upward precision compatibility, and the verification passes. However, the precision difference is recorded for subsequent code generation to determine whether a range check needs to be inserted. The second is the address space rule, which requires that for the terminal that plays the role of PLC, the number of I / O variables and the range of logical addresses bound to it shall not exceed the I / O channel specifications given in the target configuration description file. If they exceed the limit, it shall be judged as address space overflow. The third is the variable capacity rule, which requires that the total number of variables actually registered on each terminal does not exceed the maximum number of variables registered declared in the variable carrying boundary segment of that terminal, and the number of variables associated with the task node does not exceed the indirect constraints of the task stack space, that is, the total memory occupied by local variables required for the task to run does not exceed the upper limit of the single task stack space. Fourth is the referential integrity rule, which requires that the variables bound to the interaction node and the monitoring node must exist in the variable definition table visible to the corresponding terminal, and references to empty variables or out-of-bounds references are not allowed. The fifth is the real-time constraint rule. For variables marked with high real-time priority, check whether their refresh cycle is within the minimum configurable granularity of the target terminal. If the terminal cannot meet the refresh cycle, it is judged as a violation of the real-time constraint. The sixth is the communication resource matching rule. For all cross-terminal communication links, three items are verified: first, whether the communication protocol type used by the link is supported by the communication interfaces of both ends of the terminal; second, whether the effective data length of a single frame does not exceed the maximum single frame length limit of the ports of both ends of the terminal; and third, whether the bandwidth requirement for periodic refresh does not exceed the available bandwidth limit of the corresponding port. Failure to meet protocol support or exceeding the single frame length limit is judged as an error level, and exceeding the bandwidth limit is judged as a warning level.

[0048] Furthermore, the verification process proceeds instance-by-instance. For each terminal instance, its target configuration description file is read in, and a subset of variables visible to that terminal is selected from the variable semantic information summary table. The aforementioned rules are then applied to each variable for verification. Cross-terminal verification follows the communication link, performing type compatibility and address alignment checks on the source and destination variables associated with the communication nodes.

[0049] S2.5 Record the consistency verification results, mark the engineering data items that do not conform to the rules, and generate a verification result list.

[0050] Specifically, the output of the verification process is a structured list of verification results. For each verification item, the list records the verification time, the terminal identifier involved, the variable or element identifier involved, the rule number applied, the verification result (pass / warning / error), and detailed diagnostic description information.

[0051] For situations deemed warnings, such as type precision backward compatibility or using default values ​​for bindings without a specified refresh period, the system marks these items as warnings, indicating that the project can continue compiling, but engineers are advised to check and confirm. For situations deemed errors, such as type incompatibility conflicts, variable capacity overflow, or referencing null variables, the system marks these items as errors. In this case, the compilation process is suspended in stage S2, and the error list is displayed to the development interface. Engineers must correct the project data before restarting compilation.

[0052] Furthermore, the verification result list is simultaneously displayed in readable text format in the development output window and stored in the project compilation record as structured data, associated with the project version identifier, serving as the data foundation for tracing the compilation process during subsequent operation and maintenance phases. Only when there are no error-level items in the verification result list will the compilation process continue to the S3 multi-terminal runtime package and symbol file generation stage.

[0053] S3. Generation of Multi-Terminal Runtime Packages and Symbol Files: Based on the target-independent intermediate representation set and the target configuration description file, a cross-terminal variable-task-resource consistency constraint graph is constructed; based on the cross-terminal variable-task-resource consistency constraint graph, deployment constraint slices containing variable roles, resource boundaries, and real-time priorities are generated by projecting the cross-terminal variable-task-resource consistency constraint graph onto each target terminal; runtime execution packages adapted to PLC terminals, HMI terminals, and SCADA terminals are generated based on the deployment constraint slices, and unified symbol tag files carrying cross-terminal semantic identifiers are generated simultaneously; and the cross-terminal variable-task-resource consistency constraint graph is saved as an online operation and maintenance index on the development end; specifically, after completing the target terminal configuration and cross-terminal consistency verification, and confirming that there are no error-level items in the verification result list, the compilation process enters the multi-terminal runtime package and symbol file generation stage. This step is the core of the unified programming configuration platform's compilation backend. Its basic logic is as follows: Using the target-independent intermediate representation set and the target configuration description files for each terminal as input, a global graph model is constructed that covers the constraints between all terminals, all variables, and all tasks. Then, using this graph model as a blueprint, projections are made onto each target terminal, and deployment constraint slices relevant only to that terminal are extracted. Finally, runtime execution packages adapted to different terminal types are generated based on each slice, and a set of unified symbol tag files carrying cross-terminal semantic identifiers is simultaneously produced. The specific implementation methods for each sub-step are explained below: S3.1. Based on the project semantic elements in the target-independent intermediate representation set and the terminal constraint parameters in the target configuration description file, a cross-terminal variable-task-resource consistency constraint graph is constructed. Specifically, the cross-terminal variable-task-resource consistency constraint graph is the basic data structure of the entire compilation backend. It models the variable definitions, task configurations, I / O mappings (input / output mappings), screen bindings, monitoring references, and hardware and software constraints of each target terminal in a unified manner in the form of a graph, providing a single source of fact for subsequent slice projection and code generation. The entire construction process includes six steps in sequence: project element extraction, terminal parameter extraction, node generation and initialization, constraint edge generation, attribute mounting, and final graph model formation. These are described in detail below: S3.11 Extract the engineering element data corresponding to variable definitions, task configurations, input-output mapping relationships, screen binding relationships, and monitoring object reference relationships from the target-independent intermediate representation set; In this step, before constructing the constraint diagram, the compilation backend first reads the target-independent intermediate representation set and extracts all the engineering element data required to construct the constraint diagram. Specifically: Extract the internal identifier, global path, data type structure, initial value, persistence flag, and logical address binding information for each variable from the variable definition table; Extract the task name, scheduling priority, period or triggering condition, list of associated program organization units, and read / write relationships between the task and each variable from the task-variable association graph for each task node. Extract the source variable identifier, destination variable identifier, logical address information, data length, and refresh cycle for each cross-terminal data exchange relationship from the data exchange description block set. Extract the interaction node corresponding to each screen binding relationship from the front-end interaction model, and record its control identifier, control type, bound variable identifier and refresh cycle; Extract each monitoring object reference node from the monitoring group structure and record its monitoring object identifier, reference variable identifier, alarm threshold set, and storage mode.

[0054] Before entering the graph construction process, all the extracted engineering element data are converted into structured records indexed by globally unique identifiers to ensure that elements from different sources can be accurately matched through identifiers when incorporated into the graph model.

[0055] S3.12 Extract the terminal parameter data corresponding to the hardware architecture, system platform, running role and resource boundary of each target terminal from the target configuration description file; In this step, the extraction of terminal parameter data occurs simultaneously with the extraction of engineering elements. The compilation backend reads all target configuration description files generated in S2 and extracts the terminal parameter data for each target terminal. The fields to be extracted from the configuration description file of each terminal instance include: Terminal instance identifier, terminal type, running role flag; Hardware architecture parameters include CPU word length, maximum available memory capacity, maximum non-volatile storage capacity, and whether it has a floating-point arithmetic unit; The system platform parameters include the operating system type and version, runtime kernel type, list of supported task scheduling policies, minimum timer resolution, real-time response level threshold table, and system fixed overhead parameters. The real-time response level threshold table defines several level numbers and their corresponding maximum allowable response time limits. The system fixed overhead parameters give the fixed amount of memory occupied by the terminal's runtime system code segment, runtime kernel stack, and communication buffer. The communication resource parameters include the number of available communication ports, the protocol types supported by each port, and the maximum data length per frame. In addition, the maximum number of registered variables, the maximum type nesting depth, and the upper limit of string length within the variable carrying boundary.

[0056] Finally, the extracted terminal parameter data is organized into a set of terminal parameter records according to the terminal instance identifier, and each record will then correspond to a terminal node in the constraint diagram.

[0057] S3.13. Based on the extracted engineering element data and terminal parameter data, generate variable nodes, task nodes, terminal nodes, screen binding relationship nodes, monitoring object reference nodes, and resource nodes respectively; In this step, after extracting the engineering element data and terminal parameter data, the compilation backend enters the node generation stage. Based on the above two types of data, the compilation backend generates the following six types of nodes and registers them all into the graph data structure, completing the initialization of the node set of the constraint graph. Each node is assigned a unique node identifier within the graph.

[0058] The first type is variable nodes. Each variable defined in the target-independent intermediate representation set generates a variable node. The core attributes of the node include the variable's internal identifier, global path, data type description structure, and logical address binding.

[0059] The second category is task nodes. Each task defined in the project generates a task node. The core attributes of the node include the task name, scheduling priority, execution cycle or trigger condition type, and a list of associated program organization unit identifiers. If the engineer explicitly declares the timing offset requirements between the task and another task in the task configuration, the offset value is also recorded in the task node attributes.

[0060] The third category is terminal nodes. Each target terminal instance configured in the project generates a terminal node. The core attributes of the node include terminal instance identifier, terminal type, hardware architecture parameter summary, system platform parameter summary, running role identifier, communication resource boundary, and variable carrying boundary.

[0061] The fourth category is screen binding relationship nodes. Each screen control binding defined in the HMI configuration generates a screen binding relationship node, which records the control identifier, control type, bound variable identifier, and refresh cycle.

[0062] The fifth category is the monitoring object reference node. Each monitoring point defined in the SCADA monitoring configuration generates a monitoring object reference node, which records the monitoring object identifier, the referenced variable identifier, the alarm threshold set, and the storage mode.

[0063] The sixth category is resource nodes. Based on the hardware and system parameters of each terminal, several sub-level resource nodes are created for each terminal node, specifically including memory resource nodes, storage resource nodes, communication resource nodes, and computing resource nodes. Resource nodes establish a hierarchical relationship with their respective terminal nodes.

[0064] S3.14. Incorporate all nodes into the graph structure to complete the node construction of the cross-terminal variable-task-resource consistency constraint graph.

[0065] In this step, after the six types of nodes have been generated, all nodes are formally registered into the graph data structure. Specifically, the compilation backend creates an empty graph data structure instance and sequentially adds variable nodes, task nodes, terminal nodes, screen binding relationship nodes, monitoring object reference nodes, and resource nodes to the vertex set of this graph. Each node uses its unique identifier within the graph as its index key. During the addition process, the compilation backend simultaneously establishes a fast lookup index from node identifiers to node objects, so that nodes can be efficiently located using identifiers when generating constraint edges later. At this point, all nodes in the cross-terminal variable-task-resource consistency constraint graph have been incorporated into the graph structure, and the node construction phase is complete.

[0066] S3.15. Based on the relationships between nodes, generate variable production edges, variable consumption edges, node ownership edges, resource binding edges, and time-series constraint edges; use variable production edges, variable consumption edges, node ownership edges, resource binding edges, and time-series constraint edges as constraint edges. In this step, after the node set is initialized, the compilation backend begins to establish the relationships between nodes in the graph structure, i.e., generate constraint edges. Based on the logical relationships and physical affiliations between nodes, the following five types of constraint edges are generated.

[0067] Firstly, variable production edges are used to connect variable nodes to the task nodes that generate the data for that variable. When a task node's program organization unit contains a write operation on a certain variable, a variable production edge is established between that task node and the variable node, with the direction pointing from the task node to the variable node. If a variable has multiple write operations by different tasks, multiple variable production edges are established, connecting each production task node to the variable node.

[0068] Secondly, variable consumption edges are used to connect variable nodes with task nodes, interaction nodes, or monitoring nodes that consume the variable's data. When a task reads the value of a variable, a screen binding relationship node binds to a variable, or a monitoring object references a variable, a variable consumption edge is established between the corresponding consumer node and the variable node, with the direction from the variable node to the consumer node.

[0069] Third, the node affiliation edge is used to connect node pairs with clearly defined affiliations. Specifically, this includes: connecting task nodes to the terminal node they run on; connecting screen-bound nodes to their corresponding HMI terminal nodes; connecting monitored object reference nodes to their corresponding SCADA terminal nodes; and connecting resource nodes to their respective terminal nodes. The direction of the affiliation edge is uniformly from the child node to the parent terminal node or resource node.

[0070] Fourth, resource binding edges are used to connect variable nodes, task nodes, and the terminal resources they consume. Specifically, this includes connecting variable nodes to the resource nodes of the terminal where their physical mapping is located; and connecting task nodes to the memory resource nodes and computing resource nodes of the terminal where they run.

[0071] Fifth, temporal constraint edges are used to connect task node pairs that have temporal dependencies. When there is a data transfer relationship between two tasks, and the execution cycles or trigger times of the two tasks have a definite sequential constraint, a temporal constraint edge is established between them, with the direction from the task node that executes first to the task node that executes later.

[0072] Finally, after the five types of edges are generated, the compilation backend integrates them into the graph structure as a unified set of constraint edges. At this point, each constraint edge has only established topological connections and has not yet been loaded with quantitative attributes related to refresh time limits, resource consumption, etc. These attributes will be loaded in S3.16.

[0073] S3.16 Attach corresponding attribute parameters to each node, and attach corresponding variable roles, refresh time limits, resource boundaries and real-time priority attributes to each constraint edge; In this step, after the graph topology is established, the nodes and edges only express the relationships between engineering elements and do not yet possess the information density required for quantitative analysis. Therefore, the compilation backend further loads attributes onto all nodes and constraint edges, filling the various parameters extracted earlier and the derived constraint values ​​into the corresponding graph elements.

[0074] For each type of node, the attribute attachments are as follows: The attribute parameters attached to the variable node include the variable's data type structure, initial value, persistence flag, logical address binding information, and production-consumption statistics of the variable across multiple terminals; The attribute parameters attached to the task node include the scheduling priority value, the execution cycle or trigger condition structure, the list of associated program organization unit identifiers, and the estimated worst-case execution time. The attribute parameters mounted on the terminal node include hardware architecture parameters, system platform parameters, running role markers, communication port attribute list, and variable carrying boundary values ​​extracted from the target configuration description file; The screen binding relationship node is configured with the control identifier, control type, bound variable reference identifier, refresh cycle, and operation permission level. The monitoring object reference node is attached with the monitoring object identifier, reference variable identifier, alarm threshold structure and storage mode; the resource node is attached with the total resource limit and the current occupied amount.

[0075] For constrained edges, different quantization attributes are attached according to their type, which are explained in detail below.

[0076] For the variable production edge, the compilation backend attaches a variable role attribute to it, marking the variable as a producer in this link, and also attaches a refresh timeout attribute, which is determined by the update cycle of the production task for this variable. Let's say the task node that produces this variable... The execution cycle is (Unit: microseconds), then the refresh time limit of the production edge. Take as: ; in Indicates production task The execution cycle. It should be noted that if the production task is event-triggered, then... The values ​​are selected in the following priority order: First, the maximum event interval declared by the engineer in the task configuration is used; if the engineer has not declared it, the worst-case response interval for that event obtained by the system through static analysis is used; if neither can be obtained, then... The default upper limit is set to 10 to 100 times the minimum resolution of the terminal timer where the task is located (this can be configured as needed in the target configuration description file). This priority rule ensures that the refresh timeout of event-triggered tasks can always be assigned a reasonable and calculable engineering value.

[0077] For the variable consuming edge, the compilation backend attaches a variable role attribute to it, marking it as a consumer role, and also attaches a refresh time limit attribute. Let the required refresh cycle of the task node, interaction node, or monitoring node consuming this variable be... (Unit: microseconds), then the refresh time limit of the consumption edge. for: ; in This indicates the refresh cycle required by the consumer node. For consumer nodes that do not explicitly declare a refresh cycle, Retrieve the default refresh cycle value corresponding to the terminal type where the node is located.

[0078] After attaching the refresh time limits for all consumer edges, the compilation backend further calculates the comprehensive refresh time limit constraint for each variable node. It is attached as an additional attribute of the variable node.

[0079] Set variable nodes exist Each production edge has a corresponding production refresh time limit of [number]. The actual achievable refresh timeout is defined as the minimum refresh timeout of all production edges, representing the fastest data update capability of this variable: ; Set variable nodes exist Each consumption edge has a corresponding consumption refresh time limit. The most stringent refresh requirement is defined as the minimum refresh time limit of all consumer edges, representing the system's minimum refresh requirement for this variable: ; when When the production capacity of the variable is deemed insufficient to meet the refresh requirements of the consumer end, a real-time violation warning is triggered; the overall refresh time limit of the variable... Take the actual achievable refresh time limit, that is: .

[0080] in Represents variable nodes The number of production edges. Represents variable nodes The number of consumption sides, Indicates the first The refresh time limit for each production edge. Indicates the first The refresh time limit for each consumption edge. It represents the upper limit of the supply-side capacity for updating variable data, that is, the fastest data refresh interval that the variable can reach in all production task refresh cycles, representing the highest data update frequency that the system can actually output; This represents the lower limit of the demand-side constraint for variable data refresh, which is the highest required refresh interval among all tasks, screens, and monitoring points that consume this variable. It represents the system's minimum requirement for the freshness of the variable data.

[0081] For node affiliation edges, the compilation backend attaches an affiliation type attribute to indicate whether the affiliation relationship belongs to task affiliation, screen affiliation, monitoring affiliation, or resource affiliation.

[0082] For resource-bound edges, the compilation backend mounts resource requirement quantification attributes, specifically including the estimation of the target resource's usage by variable nodes or task nodes. Variable nodes Corresponding memory usage (Unit: bytes) The size is calculated using the SizeOf function based on the data type structure. For basic data types, the size is determined by the predefined values ​​of the underlying type system; for array types, let the element type size be... The number of elements is ,but For struct types, members are arranged sequentially according to their own alignment requirements, with padding bytes inserted between members as needed. The total size is rounded up based on the alignment value of the largest basic member of the struct. (Task Node) Corresponding stack space usage (Unit: bytes) Based on the conventional constraints of non-recursive calls in industrial control programming, the estimation formula is determined by the worst-case nested call stack depth of all program organizational units called by the task and the size of local variables in each stack frame. ; in This represents the basic stack overhead reserved by the kernel during task runtime; its value is given in the target configuration description file. This represents the maximum call depth obtained through static analysis. Indicates the first call in the call chain The set of program organizational units that a layer may invoke; This indicates the stack frame size required for local and temporary variables within the corresponding program organization unit.

[0083] Furthermore, for resource-bound edges involving communication, the compilation backend also needs to load the communication bandwidth usage. Let the variable node... The variable is periodically transmitted via a certain communication link, and the effective data payload length mapped during transmission is [length missing]. (Unit: bytes), communication refresh cycle is (Unit: microseconds) indicates the average communication bandwidth occupied by this variable on this link. (Unit: bits per second, bps) Calculated using the following formula: ; in This indicates the length of the effective data payload. The overhead of the corresponding protocol stack frame header, address field, check field, etc., will be calculated separately in the subsequent communication stack configuration stage and will not be included here.

[0084] For timing-constrained edges, the compiler backend attaches a maximum allowed delay attribute. Let the production task node period connected by this timing-constrained edge be... The consumption task node cycle is The timing offset between the two tasks declared by the engineer in the task configuration is... (Unit: microseconds; positive values ​​indicate relaxed timing constraints, negative values ​​indicate tightened timing constraints; if not declared) If the maximum allowable delay of the edge is 1 / 3, then the maximum allowable delay of the edge is 1 / 3. Defined as: (must meet) Boundary constraints ensure that there is at least one valid data update within each consumption task cycle; where... Indicates the execution cycle of a production task. This indicates the execution cycle of the consumption task. This indicates the timing bias declared by the engineer. As an additional attribute attached to the temporal constraint edge, it is used to determine whether the temporal dependency between task pairs can be satisfied during subsequent real-time verification.

[0085] At this point, the attribute mounting work for all nodes and constraint edges is complete, and the graph model has been expanded from a simple structural topology to a constraint network carrying complete quantitative information.

[0086] S3.17. Based on all nodes and attributed constraint edges, a complete cross-terminal variable-task-resource consistency constraint graph is formed.

[0087] In this step, through four stages—node generation, node integration into the graph structure, constraint edge generation, and attribute mounting—a complete cross-terminal variable-task-resource consistency constraint graph is ultimately formed. This constraint graph is a directed attribute graph containing multiple node types and multiple edge types. Variable nodes and task nodes constitute the logical skeleton of control and data flow, terminal nodes and resource nodes provide the constraint boundaries for physical deployment, screen binding relationship nodes and monitoring object reference nodes connect human-computer interaction and monitoring needs, and the five types of constraint edges precisely describe the complete constraint topology from production to consumption, from logic to physical, and from time to space.

[0088] The constraint graph is stored in the compilation backend memory using an adjacency list combined with an attribute table. Its serialized copy will then be used in two ways: first, as input to the projection engine to generate deployment constraint slices for each terminal; second, bound to the current project version identifier and saved as an online operation and maintenance index file for the development side, for subsequent online debugging, diagnosis, and version rollback phases.

[0089] S3.2. Based on the cross-terminal variable-task-resource consistency constraint graph, projection processing is performed with each target terminal as an independent projection dimension to generate deployment constraint slices containing variable roles, resource boundaries, and real-time priorities. Specifically, after the cross-terminal variable-task-resource consistency constraint graph is constructed, the compilation backend enters the projection stage. The basic idea of ​​projection is to take each target terminal as the viewpoint center, cut out a subgraph from the global constraint graph that is only related to that terminal, and organize the information in the subgraph into a deployment constraint slice for that terminal. The entire projection process unfolds in sequence according to four sub-steps: starting node selection, association traversal, subgraph extraction, and slice generation. S3.21. Select the terminal node corresponding to a single target terminal as the projection start node; In this step, the first step of projection is to determine the starting node. The compilation backend traverses all terminal nodes in the constraint graph, selecting one unprocessed terminal node as the starting node for this projection at a time. The projection operation is executed at the terminal instance level, and the projection processes between terminals do not interfere with each other. It can be processed serially or in parallel when resources permit. After selecting the starting node, the projection engine creates an empty set of marked nodes and a set of marked edges for that terminal, ready to begin traversal.

[0090] S3.22. Starting from the projection start node, perform an associative traversal along each constraint edge and mark all associated nodes and edges. In this step, the selected projection starting node is used. Starting from this point, the projection engine executes the following traversal rules to progressively mark all nodes and edges that fall within the scope of the terminal's interest.

[0091] The first step is to initialize the traversal state. This involves setting the starting terminal node. Add to the set of marked nodes Initialize the set of marked edges Empty, and will Used as the initial element for traversing the queue at the current level.

[0092] The second step is to traverse in reverse along the edges that belong to the node. Starting from the node in the current level of the queue, search for all direct child nodes in the reverse direction along the edges that belong to the node. For each child node found, if the child node is not yet in the queue... In the middle, then add it. And add the corresponding belonging edge. At the same time, the child node is added to the next level of the traversal queue. Through this step, all task nodes, screen binding relationship nodes, monitoring object reference nodes, and resource nodes belonging to this terminal are marked one by one.

[0093] The third step is to traverse along the resource-binding edges. Starting from the marked resource nodes and task nodes, search bidirectionally along the resource-binding edges. For each resource-binding edge, if the variable node connected to the edge is not yet in... In the middle, the variable node is added. And add the resource to the bound edge. Simultaneously, the newly marked variable nodes are added to the next level of the traversal queue. Through this step, variables directly accessed by the terminal task and variables physically mapped by the terminal are included in the marking scope.

[0094] The fourth step is to traverse along the production and consumption edges. Starting from the marked variable nodes, perform a bidirectional search along the variable production and consumption edges. For each production or consumption edge, if the task node, interaction node, or monitoring node connected to the edge is not yet in... Then, it is further determined whether the node belongs to the current terminal node through the node belonging edge. If so, mark the node and add it. Add the corresponding production edge or consumption edge. The newly marked node is then added to the next level of the traversal queue. If the node belongs to another terminal, only the current variable node is marked as a cross-terminal communication variable and the remote terminal identifier is recorded; the remote terminal node is not added to the queue. The corresponding production edge or consumption edge is not included in the formal edge set of the subgraph. Only the cross-terminal communication attribute is attached to the current variable node, and the reference identifier of the remote terminal and communication link is retained.

[0095] Step 5: Traverse along the temporal constraint edges. Starting from the marked task node, perform a bidirectional search along the temporal constraint edges. For each temporal constraint edge, if the other task node it connects to is already... In the middle, the time-series constraint edge is added. This step ensures that the temporal dependencies between tasks within the same terminal are fully preserved.

[0096] Step 6, Iteration and Termination. Repeat steps 2 through 5, treating the next level of the traversal queue as the new current level queue, until no new nodes are marked after a certain round of traversal. To handle potential circular dependencies in the graph, check if a node already exists before attempting to mark it. In this process, already marked nodes are not processed again, ensuring that the traversal process will terminate within a finite number of steps.

[0097] S3.23. Extract all marked nodes and edges to form a subgraph structure corresponding to the target terminal; In this step, after the traversal terminates, the projection engine will... All nodes in All edges are extracted from the graph to form a subgraph structure corresponding to the target terminal. All constraint edge endpoints in this subgraph belong to the subgraph node set. Remote association information related to cross-terminal communication is attached to local variable nodes as attributes. This subgraph has the terminal node as its root node and contains several task nodes, variable nodes, interaction nodes, or monitoring nodes, as well as the terminal's resource nodes and all associated constraint edges. For variables marked as cross-terminal communication, the subgraph retains the variable node itself and its corresponding consumer or producer edge, while also attaching a cross-terminal marker and a remote terminal identifier to the variable node attributes for reference in subsequent communication configuration segments. This subgraph is a dedicated view tailored for this terminal from the global constraint graph, containing all variables, tasks, and resource constraint information that the terminal needs to consider during runtime.

[0098] S3.24. Generate deployment constraint slices containing variable roles, refresh time limits, resource boundaries, and real-time priority based on the subgraph structure.

[0099] In this step, after obtaining the subgraph structure, the projection engine organizes the information contained in the subgraph into a structured deployment constraint slice. Each deployment constraint slice contains a variable list segment, a task list segment, a resource boundary segment, a real-time priority segment, and a communication configuration segment. The content of each segment is extracted and organized from the subgraph.

[0100] The variable list section lists information about all variable nodes involved in the terminal. Each variable entry includes a variable identifier, data type structure, initial value, persistence flag, variable role label (local producer, local consumer, cross-terminal producer, or cross-terminal consumer), refresh time limit requirement for the variable within the terminal, and logical address binding information associated with the variable. For variables labeled as cross-terminal, the entry also includes a remote terminal identifier and a reference to the corresponding communication node.

[0101] The task list section lists information about all task nodes running on the terminal. Each task entry includes a task identifier, scheduling priority, execution cycle or triggering condition, a list of associated program organization units, and a list of variable identifiers accessed by the task and their access types.

[0102] The resource boundary segment extracts hard constraint values ​​such as the terminal's available memory limit, storage limit, maximum number of tasks, maximum number of variables, communication port configuration, and I / O channel capacity from the resource nodes of the subgraph, and organizes them into a resource boundary table.

[0103] The generation of real-time priority segments is based on the comprehensive refresh time limit of variable nodes. The compilation backend reads the real-time response level threshold table from the target configuration description file corresponding to the target terminal. This table defines the... Each real-time level, Associate a maximum allowed response time limit (Unit: microsecond), and satisfies Let the set of all variable nodes involved in this terminal be . First, eliminate For infinitely large non-real-time variables, where non-real-time variables refer to variables that have no periodic production tasks and are only triggered by events or manually assigned values, the remaining variables are divided into... The variables are sorted in ascending order and then assigned to different real-time levels based on the upper limit of the response time for each level. Subset of variables of a layer satisfy ,in The value is 0. Each level is marked with its maximum allowable response latency. The compiler backend generates a list of associated variables and task identifiers for each level, which is then used by the code generation phase to generate corresponding task scheduling priority suggestions.

[0104] The communication configuration section extracts the corresponding communication protocol type, logical address framing information, data length, refresh cycle, and timeout handling strategy from the data exchange description block for variables involving cross-terminal communication, and organizes them into a communication configuration table for the terminal.

[0105] Finally, the compilation backend repeats the projection process from S3.21 to S3.24 for each target terminal node to generate a complete set of deployment constraint slices, with one slice corresponding to one terminal instance.

[0106] S3.3. Based on the deployment constraint slices of each target terminal, generate runtime execution packages adapted to PLC terminals, HMI terminals, and SCADA terminals respectively, and simultaneously generate unified symbol tag files carrying cross-terminal semantic identifiers. Specifically, after all deployment constraint slice sets are generated, the compilation backend immediately enters the code generation and symbol file generation stage. This stage uses the deployment constraint slice of each terminal as input and sequentially completes three tasks: runtime execution package generation, cross-terminal semantic identifier generation, and unified symbol tag file generation. This step is further detailed into the following sub-steps: S3.31. Read the deployment constraint slice of the corresponding target terminal, generate memory layout information and communication resource binding information according to the resource boundaries in the deployment constraint slice, generate task scheduling parameter configuration information according to the real-time priority in the deployment constraint slice, and generate the runtime execution package of the corresponding target terminal. In this step, for each target terminal, the compilation backend reads its corresponding deployment constraint slice and assigns the task to the corresponding code generator, namely the PLC code generator, HMI code generator, or SCADA code generator, based on the terminal type field in the slice.

[0107] Taking a PLC code generator as an example, this section explains the specific process of generating runtime execution packages. The generation work of the PLC code generator mainly includes four stages: memory layout, task scheduling parameter generation, communication resource binding, and execution package serialization.

[0108] First, there's the memory layout. The generator reads the variable list segment and assigns an offset address in the PLC's memory space for each variable. Let the set of variables for this PLC terminal be... The number of bytes of memory corresponding to each variable is PLC memory address alignment granularity Byte alignment, Obtained from the target configuration description file. Variables are assigned offset addresses in the order they appear in the variable list, starting at [address missing]. Set to 0, for The recursive formula for the offset address is: ; in Indicates the first The starting offset address of each variable; Indicates the first The number of bytes of memory for each variable; In order to make the first The number of padding bytes inserted to ensure the starting address of each variable meets the alignment requirements. The rule for determining the value is: if It is already If it is an integer multiple of , then ;otherwise .

[0109] all After all variables are allocated, the memory usage of the variable region for: ; in The padding bytes following the last variable are calculated in the same way as described above. The rules are the same. The compilation backend will... Add the system fixed overhead parameters read from the target configuration description file The total runtime memory requirement of the PLC terminal is obtained. and compare it with the available memory limit in the resource boundary segment. Compare. If If this occurs, a memory overflow error will be reported and code generation for that terminal will be aborted.

[0110] The second step is task scheduling parameter generation. The generator reads the task list segment and the real-time priority segment, and maps each task to task control block parameters that can be recognized by the PLC real-time kernel. Specifically, these parameters include the task priority value, the execution cycle in milliseconds or microseconds, the entry address of the associated program organization unit, and the task scheduling strategy configured according to the real-time priority hierarchy.

[0111] Next is communication resource binding. The generator reads the communication configuration segment, and for each communication link, it substitutes its effective data payload length and refresh cycle into the bandwidth calculation formula to obtain the required bandwidth for that link. The total required bandwidth for all communication links of this PLC terminal is then calculated. The generator will Available bandwidth of communication ports in resource boundary segments Perform a verification. If... If the error occurs, a bandwidth limit warning will be issued; if the verification passes, communication stack initialization parameters will be generated, including bus interface selection, slave address configuration, and PDO mapping table filling.

[0112] Finally, the execution package is serialized. The compilation backend serializes the variable offset address allocation results, task scheduling parameters, and communication stack initialization parameters together to generate a runtime execution package that can be directly loaded by the PLC terminal. The variable offset address allocation results are embedded in the execution package in the form of a variable address mapping table. This mapping table uses the variable's internal identifier as the key and the offset address as the value, allowing the runtime adaptation layer to establish the correspondence between variables and physical addresses when the terminal loads the package.

[0113] Similarly, the HMI code generator reads the deployment constraint slices of the HMI terminal, generates a variable subscription table based on the variable list segment, records the refresh cycle and data type conversion rules for each variable, generates a screen control tree configuration file based on the interaction node information, and generates interface refresh scheduling parameters based on the real-time priority segment. The compilation results of all the above parts are packaged into an HMI runtime executable package.

[0114] The SCADA code generator reads the deployment constraint slices of the SCADA terminal, generates a data acquisition point configuration table based on the node information referenced by the monitored object, generates a data acquisition communication link configuration based on the communication configuration segment, and generates historical data archiving parameter configuration based on the storage limit in the resource boundary segment. The compilation results of all the above parts are packaged into a SCADA runtime executable package.

[0115] S3.32. Based on the global variable definition of the cross-terminal variable-task-resource consistency constraint graph, generate a corresponding cross-terminal semantic identifier for each variable; In this step, while generating runtime packages for each terminal, the compilation backend also undertakes the task of generating global symbol identifiers. Based on the global variable definition of the cross-terminal variable-task-resource consistency constraint graph, the compilation backend generates a cross-terminal semantic identifier for each variable in the project. The generation rule for this identifier is: based on the variable's global path string, concatenate the data type digest and the project version number to form a self-descriptive unique identifier string. This identifier remains unique and unchanged across multiple terminals. Regardless of which physical address the variable is assigned to within the PLC terminal or which internal tag it is mapped to in the HMI terminal, its cross-terminal semantic identifier remains unchanged, serving as a unified identity credential for subsequent cross-terminal variable tracking and online debugging.

[0116] S3.33. Combine the variable roles, resource boundaries, and real-time priority information in each deployment constraint slice to generate a unified symbol tag file that carries cross-terminal semantic identifiers and the corresponding relationship of deployment constraint slices.

[0117] In this step, after obtaining the cross-terminal semantic identifiers for all variables, the compilation backend enters the symbol file generation stage. The compilation backend associates and integrates the cross-terminal semantic identifiers generated in S3.32 with the variable roles, resource boundaries, and real-time priority information in each deployment constraint slice, generating a unified symbol tag file that carries the cross-terminal semantic identifiers and the correspondence between deployment constraint slices.

[0118] This unified symbol tag file adopts a structured, hierarchical record format. The top level is divided into sections based on terminal instance identifiers. Each terminal section contains the following subsections: Basic terminal information, recording the terminal type, model, and runtime version compatibility identifier; Variable symbol table, where each line records the internal identifier, cross-terminal semantic identifier, variable role, data type structure, address or internal tag assigned within the terminal, refresh time limit, and real-time priority of a variable on that terminal; Task symbol table, recording the identifier, scheduling priority, and execution cycle of each task; and Communication link symbol table, recording the communication protocol and peer terminal identifier corresponding to each cross-terminal communication variable.

[0119] A global variable index section is appended to the end of the file. This section lists all terminal instance identifiers of the variable appearing in the project, along with its role and address information on each terminal, using the variable's cross-terminal semantic identifier as the key. This enables one-click indexing from variable semantic identifiers to multi-terminal physical deployment. The unified symbol tag file is saved and distributed along with the runtime packages for each terminal after the project is compiled. Online monitoring tools, debuggers, and diagnostic modules on the development side all use this file as the basis for terminal addressing and variable location.

[0120] S3.4 Bind the cross-terminal variable-task-resource consistency constraint graph with the corresponding project version identifier and save it as an online operation and maintenance index on the development side.

[0121] In this step, after all runtime packages and unified symbol tag files have been generated, the cross-terminal variable-task-resource consistency constraint graph generated during the build process is bound to the version identifier of the current project, and serialized and saved to the project compilation cache or project database on the development side. This binding record serves as the online operation and maintenance index on the development side.

[0122] The online operation and maintenance index stores a complete topological snapshot of the project semantics at compile time, including all nodes, all constraint edges, and their attribute parameters. When the project enters the online operation and maintenance phase, the development team can retrieve the corresponding constraint graph through the project version identifier, mapping the runtime status data returned from the terminal to the nodes and edges in the graph. This allows for locating abnormal nodes, tracing fault paths, determining the impact range of program hot updates, and assisting in version rollback decisions. The saving of this index signifies the completion of the compilation and generation work in this step, and the compilation process then enters the S4 terminal deployment and loading phase.

[0123] S4. Terminal Deployment Loading and Standard Service Execution: Various runtime execution packages, corresponding deployment constraint slices, and unified symbol tag files are distributed to the corresponding target terminals. The terminal runtime adaptation layer completes resource loading, variable registration, and scheduling configuration based on the deployment constraint slices, completes cross-terminal variable semantic registration based on the unified symbol tag files, and executes corresponding business tasks based on the standard industrial control kernel service interface, dynamically scheduling system resources according to real-time priority. Specifically, after the development side completes the generation of all runtime execution packages and unified symbol tag files, the compilation process enters the terminal deployment loading and standard service execution stage. The goal of this step is to reliably distribute the compiled output to each target terminal, where the terminal-side runtime adaptation layer parses and loads it, ultimately initiating the execution of business tasks with the support of the standard industrial control kernel. The specific implementation method is described below in five sub-steps: S4.1 Establish communication links between the development end and each target terminal, and send the runtime execution package, corresponding deployment constraint slice and unified symbol tag file adapted to PLC terminal, HMI terminal and SCADA terminal to the corresponding target terminal one by one; Specifically, the first step in the deployment process is to establish communication connections between the development team and each target terminal. The development team obtains the IP address, port number, and device identifier of each target terminal through network scanning or a pre-configured terminal list, and initiates connection requests for each terminal one by one based on TCP / IP or industrial Ethernet protocols. Upon receiving the request, the pre-configured deployment agent service on the terminal side completes identity verification and responds, and both parties establish an encrypted transmission channel.

[0124] After the communication link is established, the development team matches the runtime execution package, deployment constraint slice, and unified symbol tag file generated in S3 according to the terminal identifier and distributes them one by one. Specifically, the development team maintains a deployment list, which records the identifier, terminal type, corresponding runtime execution package file name, deployment constraint slice file name, and unified symbol tag file version information for each terminal instance. During distribution, the development team pushes the files item by item according to the list. After the deployment agent on the terminal side receives the files, it returns a file integrity verification value. The development team confirms that the terminal distribution is successful after verifying that the verification value matches. For distribution failures or verification failures, the development team automatically retryes a specified number of times (e.g., 3 times, which can be adjusted according to the on-site network environment). If the retry still fails, the terminal is marked as a deployment anomaly, and an engineer is prompted to intervene.

[0125] S4.2 The terminal runtime adaptation layer of each target terminal reads the corresponding deployment constraint slice, completes resource loading according to the resource boundaries in the deployment constraint slice, completes variable registration according to the variable roles in the deployment constraint slice, and completes scheduling configuration according to the real-time priority in the deployment constraint slice. Specifically, after receiving the complete three types of files, the runtime adaptation layer takes over the subsequent loading work at each target terminal. The runtime adaptation layer is a middleware module pre-installed on the terminal, responsible for establishing a bridge between the standard industrial control kernel and specific business logic.

[0126] The runtime adaptation layer first reads the deployment constraint slice and parses the resource boundary segment, variable list segment, task list segment, and real-time priority segment from it.

[0127] During the resource loading phase, the adaptation layer allocates contiguous memory blocks in the terminal's physical memory for the variable area, task stack area, and communication buffer, based on the available memory limits given in the resource boundary segments. The start and end addresses of each area are recorded in an internal resource allocation table. After allocation, the adaptation layer checks whether the actual allocated amount exceeds the limits declared in the resource boundary segments. If it does, a resource overflow alarm is generated, and loading is refused to continue.

[0128] During the variable registration phase, the adaptation layer iterates through each variable entry in the variable list segment and creates a corresponding variable record in the terminal's internal variable registry based on the variable identifier, data type structure, and offset address information. The variable registry uses the variable's internal identifier as the primary key and records the variable's physical address in local memory, data type size, and persistence flag. For variables marked as persistent, the adaptation layer also maps the corresponding memory region to a non-volatile storage area to ensure data is not lost after power failure.

[0129] During the scheduling configuration phase, the adaptation layer reads the task list segment and the real-time priority segment, mapping each task to a task control block structure of the standard industrial control kernel. For each task, its scheduling priority value, execution cycle, associated program entry address, and task stack pointer are configured. The real-time priority hierarchy result is converted into the kernel's task priority grouping strategy, assigning higher preemption priority to tasks with higher real-time priority and lower priority to tasks with lower real-time priority, ensuring that variable-related tasks with strict data refresh time limits receive priority scheduling.

[0130] S4.3 The terminal runtime adaptation layer of each target terminal reads the corresponding unified symbol tag file, and completes the cross-terminal variable semantic registration based on the cross-terminal semantic identifier and deployment constraint slice correspondence in the unified symbol tag file. Specifically, after resource loading, variable registration, and scheduling configuration are completed, the adaptation layer enters the cross-terminal semantic registration phase. The adaptation layer reads the section corresponding to its own terminal from the unified symbol tag file and extracts the variable symbol table for that terminal. For each record in the variable symbol table, the adaptation layer establishes a mapping relationship from cross-terminal semantic identifiers to local internal identifiers and registers this mapping relationship in the cross-terminal variable index table within the terminal.

[0131] Furthermore, the cross-terminal variable index table uses cross-terminal semantic identifiers as keys to record the corresponding local internal identifiers, variable roles, data type structures, and local physical addresses. For variables marked as cross-terminal communication, the index table also records the identifier of the remote terminal and communication link information. This index table is continuously maintained at runtime. When the development end issues a cross-terminal variable query request, the terminal can quickly respond through this index table, returning the current value and status information of the variable.

[0132] S4.4 The terminal runtime adaptation layer of each target terminal is based on the standard industrial control kernel service interface and executes the corresponding business tasks. Specifically, after all the loading and registration work is completed, the runtime adaptation layer calls the task startup interface of the standard industrial control kernel to submit the task control blocks configured in S4.2 to the kernel scheduler in sequence. The standard industrial control kernel then begins to schedule the execution of each task according to the set priority and scheduling policy.

[0133] For PLC terminals, the kernel schedules the execution of each program organization unit according to a cycle or trigger condition, sequentially completing three stages within each scan cycle: input refresh, program logic execution, and output refresh. During program logic execution, tasks directly read and write variable data through the physical addresses in the variable registry.

[0134] For HMI terminals, the kernel periodically triggers the variable subscription refresh of screen controls according to the interface refresh scheduling parameters, and obtains the latest value of the bound variables from the local variable registry or through the cross-terminal communication link. When the terminals interact with cross-terminal variable data, the communication data frame carries the cross-terminal semantic identifier of the variable. When the receiving end runs, the adaptation layer completes the identifier matching and address mapping based on the local cross-terminal variable index table, and drives the screen rendering engine to update the control display.

[0135] For SCADA terminals, the kernel periodically reads the monitoring variable values ​​of each PLC terminal through the communication link according to the data acquisition point configuration table. During the communication process, variable identity alignment is completed based on cross-terminal semantic identifiers. After the values ​​are read, they are compared with alarm thresholds and the data is written to the historical archive according to the storage mode.

[0136] S4.5 The terminal runtime adaptation layer of each target terminal dynamically schedules the terminal's computing resources, storage resources, and communication resources based on the real-time priority and resource boundaries in the deployment constraint slice.

[0137] Specifically, during the operation of business tasks, the runtime adaptation layer continuously monitors the usage status of terminal resources and performs dynamic scheduling based on real-time priority and resource boundaries.

[0138] Regarding computational resource scheduling, the adaptation layer monitors the actual execution time of each task. When it detects that the actual execution time of a high-priority task exceeds 120%~150% of its estimated worst-case execution time (which can be configured as needed in the target configuration description file), the adaptation layer requests the kernel to temporarily increase the scheduling priority of that task. After the high-priority task completes its execution, the priority is restored to its original value. If it detects that a low-priority task has not received an execution opportunity for a long time, the adaptation layer records a starvation alarm.

[0139] Regarding storage resource scheduling, the adaptation layer monitors the usage rate of variable memory areas and communication buffers. When it detects that the occupancy rate of a communication buffer exceeds a preset threshold of 80% (configurable on demand), the adaptation layer temporarily increases the capacity of the buffer or accelerates its consumption rate to prevent data loss. For historical data archiving of SCADA terminals, when the archived files reach the maximum capacity limit set in the resource boundary segment, the adaptation layer deletes the oldest historical data segment according to a cyclic overwrite strategy to release storage space.

[0140] In terms of communication resource scheduling, the adaptation layer dynamically adjusts the polling order and transmission cycle of communication ports based on the variable refresh time limit requirements marked in the real-time priority segment. Cross-terminal communication variables with stricter refresh time limit requirements receive higher communication scheduling priority and shorter polling intervals, ensuring that the end-to-end latency of critical variable data meets engineering requirements.

[0141] After the above steps are completed in sequence, each target terminal enters a stable online operating state. The development end can query the operating status, diagnostic data and alarm information of each terminal at any time through the communication link, and enter the operation data feedback and online operation and maintenance management stage described in S5.

[0142] S5. Operational Data Feedback and Online Operation and Maintenance Management: During operation, each terminal sends its running status, diagnostic data, and alarm information back to the development end. Based on the saved cross-terminal variable-task-resource consistency constraint graph, the system performs operational anomaly diagnosis, online variable monitoring, program hot update range determination, and version rollback operations. Specifically, after all target terminals have completed deployment and entered a stable operating state, the system enters the online operation and maintenance management phase. The core mechanism of this step is that each terminal periodically or event-driven sends operational data back to the development end. The development end uses the cross-terminal variable-task-resource consistency constraint graph saved during the compilation phase as an index graph to perform correlation analysis on the returned data, thereby realizing operational anomaly diagnosis, online variable monitoring, program hot update range determination, and version rollback operations. The specific implementation method is described below in four sub-steps: S5.1 When each target terminal is running, it collects running status, diagnostic data and alarm information according to the variable roles and refresh time limits in the corresponding deployment constraint slice, and sends the collected data back to the development end. Specifically, the collected data is divided into three categories. The first category is operational status data, including the cycle execution count, actual execution time, task stack usage, and CPU utilization for each task. For PLC terminals, this also includes the input refresh time, program execution time, and output refresh time for each scan cycle. The second category is diagnostic data, including the number of retransmissions in the communication link, the count of check errors, the number of buffer overflows, and the memory utilization rate. The third category is alarm information. When the runtime adaptation layer detects a task execution timeout, communication link interruption, memory usage exceeding the threshold, or variable value exceeding the alarm threshold, it immediately generates an alarm record, which includes the alarm timestamp, alarm type, involved terminal identifier, and variable identifier.

[0143] Data feedback employs the following mechanism: For real-time variable-related states with short refresh timeouts, the adaptation layer periodically feeds back data at the refresh cycle specified in the deployment constraint slice. This feedback cycle is determined by the combined refresh timeout of the corresponding variable. To maintain consistency, diagnostic data and alarm information are transmitted in real-time using an event-driven approach. Transmitted data messages use a structured format, with a header containing a terminal identifier, project version identifier, and timestamp, and the body organizing three types of data in key-value pairs. The development-side communication service parses the received messages and stores them in a real-time database.

[0144] S5.2 The development end receives the returned data and, based on the project version identifier corresponding to the data, retrieves the saved cross-terminal variable-task-resource consistency constraint diagram for the corresponding project version. Specifically, the development-side communication service extracts the project version identifier from the return message header and searches the compilation cache or project database for the cross-terminal variable-task-resource consistency constraint graph bound to that version identifier. This constraint graph is an online operation and maintenance index serialized and saved in S3.4, containing a complete topology snapshot of the project semantics at the compile time.

[0145] If the project has undergone online updates during operation, the development team maintains a multi-version mapping table between version identifiers and constraint diagrams. When retrieving constraint diagrams, the development team precisely matches the corresponding version of the constraint diagram based on the version identifier in the message, ensuring that the analysis basis is strictly consistent with the currently running program version on the terminal. If the match fails, the development team displays a version inconsistency warning to the front-end interface and guides engineers to check the terminal's running status.

[0146] S5.3 Based on the constraint edge association relationship in the cross-terminal variable-task-resource consistency constraint graph, locate the node and link corresponding to the operation anomaly, perform operation anomaly diagnosis, and perform online variable monitoring in combination with the returned data; Specifically, after the constraint diagram is successfully retrieved, the development team loads it into the diagnostic analysis engine in memory and performs two core operation and maintenance operations in conjunction with the returned data, as follows: The first step is runtime anomaly diagnosis. When the returned data contains alarm information, the diagnostic engine uses the variable identifier or task identifier carried in the alarm information as a starting point to locate the corresponding variable node or task node in the constraint graph. Then, it expands and traverses outward layer by layer along the variable consumption edge, variable production edge, resource binding edge, and timing constraint edge of that node, marking all nodes and edges that are directly or indirectly related to that node, and generating an anomaly impact subgraph.

[0147] By analyzing the topology of the subgraph affected by the anomaly and the attribute parameters of each edge, the diagnostic engine can trace the root cause of the anomaly. For example, when a task node reports an execution timeout alarm, the diagnostic engine finds its terminal node and computing resource node along the resource binding edge of the task node, checks whether the CPU utilization of the terminal is saturated (typically, the threshold is a continuous utilization exceeding 90%); it finds the variables consumed by the task along the variable consumption edge, traces to the variable production task along the production edge, and checks whether the production task has an execution delay (typically, the threshold is that the actual execution time exceeds 1.5 times the estimated worst execution time); it checks whether the time sequence dependency of upstream and downstream tasks is broken along the time sequence constraint edge (typically, the actual end-to-end delay exceeds the maximum allowable delay). The diagnostic engine organizes the analysis results into a diagnostic report that includes fault nodes, fault types, scope of impact, and root cause suggestions, and pushes it to the front-end interface of the development side.

[0148] The second feature is online variable monitoring. Engineers select variables of interest on the development interface. The development team uses a unified symbol tag file to find the cross-terminal semantic identifier for this variable, and then uses a constraint graph to locate the variable node and all its production and consumption edges, determining the variable's role and deployment location on each terminal. Subsequently, the development team sends a variable monitoring subscription request to the corresponding terminal. The runtime adaptation layer on the terminal side looks up the local address in the cross-terminal variable index table based on the cross-terminal semantic identifier, reads the variable value at a specified sampling period, and sends it back. The development team organizes the returned values ​​by time series and displays them on the interface as a trend chart or numerical table. If the variable is a cross-terminal communication variable, the development team simultaneously initiates monitoring subscriptions to both the production and consumption terminals, displaying the source and destination variable values ​​and end-to-end transmission delays side-by-side on the interface.

[0149] S5.4. Based on the version difference comparison of the cross-terminal variable-task-resource consistency constraint graph, determine the terminal range and variable range affected by the program hot update, retrieve the deployment constraint slice of the corresponding version, and perform a version rollback operation.

[0150] Specifically, when an engineer submits modified project data and initiates a hot update compilation, the development team compares the cross-terminal variable-task-resource consistency constraint graphs of the two versions before and after the modification. This comparison is conducted across three dimensions: At the node level, the addition, deletion, and attribute changes of variable nodes, task nodes, terminal nodes, screen binding relationship nodes, and monitoring object reference nodes were compared between the two versions. In terms of constraint edges, compare the addition, deletion, and attribute changes of variable production edges, variable consumption edges, resource binding edges, and temporal constraint edges; At the terminal level, the change nodes and change edges involved in the two versions for each terminal are summarized. The difference comparison results generate a hot update impact scope report, which clearly lists the list of affected terminal identifiers, the list of affected variable identifiers, and the list of task pairs that may have timing conflicts due to changes in timing constraint edges; Based on the report, engineers determine whether hot updates are safe and whether synchronized updates are needed for associated terminals. Furthermore, after confirming the safety of hot updates, the development team, following the version rollback execution process, distributes the new version runtime package, deployment constraint slices, and unified symbol tag files to the affected terminals. The terminal runtime adaptation layer then completes the update loading. Terminals supporting non-disruptive updates can complete incremental updates of variables and tasks without interrupting business operations.

[0151] Furthermore, when a running system experiences a serious failure and needs to be rolled back to a previous version, the engineer specifies the target rollback version identifier on the development side. The development side retrieves the cross-terminal variable-task-resource consistency constraint diagram, the complete set of deployment constraint slices, and the unified symbol tag file for that version from the version management repository. Then, it compares these files item by item with the corresponding files of the currently running version to generate a rollback operation list, which lists the terminal identifiers and runtime execution packages that need to be redeployed.

[0152] During rollback execution, the development team uses the communication link established in S4.1 to send the rollback version of the runtime execution package, corresponding deployment constraint slices, and unified symbol tag files to each target terminal in the list. After receiving the rollback files, each terminal's runtime adaptation layer pauses the execution of the current business task and re-completes resource loading, variable registration, scheduling configuration, and cross-terminal semantic registration according to the process from S4.2 to S4.4, before resuming the execution of the business task. After the rollback is complete, each terminal restarts transmitting runtime data according to the mechanism in S5.1. After the development team confirms that the running status of each terminal in the transmitted data is normal, it records the rollback result in the operation and maintenance log, and the rollback operation is complete.

[0153] Those skilled in the art will understand that the process of implementing all or part of the steps of the above embodiments can be carried out by hardware or by a program instructing the relevant hardware.

[0154] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely preferred examples and are not intended to limit the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the claimed invention.

Claims

1. A method for implementing a multi-terminal unified programming configuration platform for industrial automation compatible with standard industrial control kernels, characterized in that, Includes the following steps: S1. Unified Engineering Parsing and Intermediate Representation Construction: Reads integrated engineering data containing PLC control program, HMI configuration configuration, and SCADA monitoring configuration, and processes it through the compilation front-end parsing to extract variable definitions, task configurations, input / output mapping relationships, screen binding relationships, and monitoring object reference relationships, generating a target-independent intermediate representation set that is decoupled from the target operating environment; S2. Target Terminal Configuration and Consistency Verification: Generate target configuration description files based on the hardware architecture, system platform, running role, and resource boundaries of multiple target terminals, and perform cross-terminal engineering data consistency verification based on unified variable semantic rules; S3. Generation of Multi-Terminal Runtime Packages and Symbol Files: Based on the target-independent intermediate representation set and the target configuration description file, a cross-terminal variable-task-resource consistency constraint graph is constructed; based on the cross-terminal variable-task-resource consistency constraint graph, deployment constraint slices containing variable roles, resource boundaries, and real-time priorities are generated by projecting the graph onto each target terminal; runtime execution packages adapted to PLC terminals, HMI terminals, and SCADA terminals are generated based on the deployment constraint slices, and unified symbol tag files carrying cross-terminal semantic identifiers are generated simultaneously. The cross-terminal variable-task-resource consistency constraint graph is saved as an online operation and maintenance index on the development side. S4. Terminal Deployment Loading and Standard Service Execution: Various runtime execution packages, corresponding deployment constraint slices, and unified symbol tag files are distributed to the corresponding target terminals. The terminal runtime adaptation layer completes resource loading, variable registration, and scheduling configuration based on the deployment constraint slices, completes cross-terminal variable semantic registration based on the unified symbol tag file, and executes corresponding business tasks based on the standard industrial control kernel service interface, dynamically scheduling system resources according to real-time priority. S5. Operational Data Feedback and Online Operation and Maintenance Management: During operation, each terminal will send its running status, diagnostic data, and alarm information back to the development end. Based on the saved cross-terminal variable-task-resource consistency constraint diagram, the terminal will complete the diagnosis of operational anomalies, online variable monitoring, determination of program hot update range, and version rollback operation.

2. The method for implementing a multi-terminal unified programming configuration platform for industrial automation compatible with standard industrial control kernels as described in claim 1, characterized in that, In S1, the unified engineering parsing and intermediate representation construction includes the following steps: S1.1 Perform syntax parsing processing on the integrated engineering data. The lexical analysis unit and syntax analysis unit of the compilation front end complete the legality verification of the engineering file and construct the original syntax tree set of the corresponding PLC control program, HMI configuration configuration and SCADA monitoring configuration. S1.2 Traverse the original syntax tree set of the project, extract five core project elements according to object type: variable definition, task configuration, input / output mapping relationship, screen binding relationship and monitoring object reference relationship, and generate a standardized set of element items; S1.3 Perform global semantic normalization on the standardized element item set to unify the global variable namespace, data type definition, object reference rules and address identification rules; S1.4 Based on the normalized core engineering elements, construct abstract semantic nodes that are decoupled from the target hardware architecture, target system platform, and target operating environment, and attach the attribute parameters and association identifiers of the corresponding elements to each abstract semantic node; S1.

5. All abstract semantic nodes are structurally integrated according to variable dimension, task dimension, interaction dimension, and communication dimension, and assembled into a target-independent intermediate representation set.

3. The method for implementing a multi-terminal unified programming configuration platform for industrial automation compatible with standard industrial control kernels as described in claim 1, characterized in that, In step S2, the target terminal configuration and consistency verification includes the following steps: S2.1 Collect hardware architecture, system platform, running role and resource boundary parameters of multiple types of target terminals, and summarize them to form a set of terminal attribute parameters; S2.2 Based on the set of terminal attribute parameters, generate target configuration description files for each target terminal according to a standardized structure; S2.3 Read the target-independent intermediate representation set and extract the semantic definitions, relationships, and mapping configuration information of all variables; S2.

4. Based on the unified variable semantic rules and the target configuration description files of each target terminal, perform cross-terminal engineering data consistency verification. S2.5 Record the consistency verification results, mark the engineering data items that do not conform to the rules, and generate a verification result list.

4. The method for implementing a multi-terminal unified programming configuration platform for industrial automation compatible with standard industrial control kernels as described in claim 1, characterized in that, In step S3, the generation of multi-terminal runtime packages and symbol files includes the following steps: S3.1 Based on the engineering semantic elements in the target-independent intermediate representation set and the terminal constraint parameters in the target configuration description file, construct a cross-terminal variable-task-resource consistency constraint graph; S3.2 Based on the cross-terminal variable-task-resource consistency constraint graph, projection processing is performed with each target terminal as an independent projection dimension to generate a deployment constraint slice containing variable roles, resource boundaries and real-time priority; S3.

3. Based on the deployment constraint slices of each target terminal, generate runtime execution packages adapted to PLC terminals, HMI terminals, and SCADA terminals respectively, and simultaneously generate unified symbol tag files carrying cross-terminal semantic identifiers. S3.4 Bind the cross-terminal variable-task-resource consistency constraint graph with the corresponding project version identifier and save it as an online operation and maintenance index on the development side.

5. The method for implementing a multi-terminal unified programming configuration platform for industrial automation compatible with standard industrial control kernels as described in claim 4, characterized in that, In step S3.1, constructing a cross-terminal variable-task-resource consistency constraint graph includes the following steps: S3.11 Extract the engineering element data corresponding to variable definitions, task configurations, input-output mapping relationships, screen binding relationships, and monitoring object reference relationships from the target-independent intermediate representation set; S3.12 Extract the terminal parameter data corresponding to the hardware architecture, system platform, running role and resource boundary of each target terminal from the target configuration description file; S3.

13. Based on the extracted engineering element data and terminal parameter data, generate variable nodes, task nodes, terminal nodes, screen binding relationship nodes, monitoring object reference nodes, and resource nodes respectively; S3.

14. Incorporate all nodes into the graph structure to complete the node construction of the cross-terminal variable-task-resource consistency constraint graph.

6. The method for implementing a multi-terminal unified programming configuration platform for industrial automation compatible with standard industrial control kernels as described in claim 5, characterized in that, In step S3.1, after completing the node construction of the cross-terminal variable-task-resource consistency constraint graph, the following steps are also included: S3.

15. Based on the relationships between nodes, generate variable production edges, variable consumption edges, node ownership edges, resource binding edges, and time-series constraint edges; use variable production edges, variable consumption edges, node ownership edges, resource binding edges, and time-series constraint edges as constraint edges. S3.16 Attach corresponding attribute parameters to each node, and attach corresponding variable roles, refresh time limits, resource boundaries and real-time priority attributes to each constraint edge; S3.

17. Based on all nodes and attributed constraint edges, a complete cross-terminal variable-task-resource consistency constraint graph is formed.

7. The method for implementing a multi-terminal unified programming configuration platform for industrial automation compatible with standard industrial control kernels as described in claim 6, characterized in that, In step S3.2, generating a deployment constraint slice that includes variable roles, resource boundaries, and real-time priorities includes the following steps: S3.

21. Select the terminal node corresponding to a single target terminal as the projection start node; S3.

22. Starting from the projection start node, perform an associative traversal along each constraint edge and mark all associated nodes and edges. S3.

23. Extract all marked nodes and edges to form a subgraph structure corresponding to the target terminal; S3.

24. Generate deployment constraint slices containing variable roles, refresh time limits, resource boundaries, and real-time priority based on the subgraph structure.

8. The method for implementing a multi-terminal unified programming configuration platform for industrial automation compatible with standard industrial control kernels as described in claim 7, characterized in that, In step S3.3, generating the runtime execution package and the unified symbol tag file includes the following steps: S3.

31. Read the deployment constraint slice of the corresponding target terminal, generate memory layout information and communication resource binding information according to the resource boundaries in the deployment constraint slice, generate task scheduling parameter configuration information according to the real-time priority in the deployment constraint slice, and generate the runtime execution package of the corresponding target terminal. S3.

32. Based on the global variable definition of the cross-terminal variable-task-resource consistency constraint graph, generate a corresponding cross-terminal semantic identifier for each variable; S3.

33. Combine the variable roles, resource boundaries, and real-time priority information in each deployment constraint slice to generate a unified symbol tag file that carries cross-terminal semantic identifiers and the corresponding relationship of deployment constraint slices.

9. The method for implementing a multi-terminal unified programming configuration platform for industrial automation compatible with standard industrial control kernels as described in claim 1, characterized in that, In step S4, the terminal deployment, loading, and standard service operation include the following steps: S4.1 Establish communication links between the development end and each target terminal, and send the runtime execution package, corresponding deployment constraint slice and unified symbol tag file adapted to PLC terminal, HMI terminal and SCADA terminal to the corresponding target terminal one by one; S4.2 The terminal runtime adaptation layer of each target terminal reads the corresponding deployment constraint slice, completes resource loading according to the resource boundaries in the deployment constraint slice, completes variable registration according to the variable roles in the deployment constraint slice, and completes scheduling configuration according to the real-time priority in the deployment constraint slice. S4.3 The terminal runtime adaptation layer of each target terminal reads the corresponding unified symbol tag file, and completes the cross-terminal variable semantic registration based on the cross-terminal semantic identifier and deployment constraint slice correspondence in the unified symbol tag file. S4.4 The terminal runtime adaptation layer of each target terminal is based on the standard industrial control kernel service interface and executes the corresponding business tasks. S4.5 The terminal runtime adaptation layer of each target terminal dynamically schedules the terminal's computing resources, storage resources, and communication resources based on the real-time priority and resource boundaries in the deployment constraint slice.

10. The method for implementing a multi-terminal unified programming configuration platform for industrial automation compatible with standard industrial control kernels according to claim 1, characterized in that, In S5, the data feedback and online operation and maintenance management include the following steps: S5.1 When each target terminal is running, it collects running status, diagnostic data and alarm information according to the variable roles and refresh time limits in the corresponding deployment constraint slice, and sends the collected data back to the development end. S5.2 The development end receives the returned data and, based on the project version identifier corresponding to the data, retrieves the saved cross-terminal variable-task-resource consistency constraint diagram for the corresponding project version. S5.3 Based on the constraint edge association relationship in the cross-terminal variable-task-resource consistency constraint graph, locate the node and link corresponding to the operation anomaly, perform operation anomaly diagnosis, and perform online variable monitoring in combination with the returned data; S5.

4. Based on the version difference comparison of the cross-terminal variable-task-resource consistency constraint graph, determine the terminal range and variable range affected by the program hot update, retrieve the deployment constraint slice of the corresponding version, and perform a version rollback operation.

Images