Low-code implementation method and system

Abstract

The invention discloses a low-code implementation method and system, and relates to the field of industrial automation, and the method comprises the steps: responding to a user operation in a low-code project environment, and generating a graphical logic definition; generating a structure reconstruction suggestion for the graphical logic definition by quantitatively analyzing the topological structure connectivity density and module cohesion of the graphical logic definition; compiling the graphical logic definition integrated with the reconstruction suggestion to generate a target executable code, and deploying the target executable code to a target PLC to form a control logic instance in operation; an execution path report is obtained by backtracking a runtime execution path of the control logic instance and extracting and visualizing an event dependency relationship and a state transition sequence which cause a specific abnormal state; and performing modification and version management on the graphical logic definition based on the execution path report. According to the method, the development quality, the operation and maintenance efficiency and the full-life-cycle value of the industrial automation software are improved.

Description

Technical Field

[0001] This invention relates to the field of industrial automation, and in particular to a low-code implementation method and system. Background Technology

[0002] In the field of industrial automation, the traditional development of programmable logic controllers (PLCs) heavily relies on professional tools that comply with the IEC 61131-3 standard. To lower the technical threshold, low-code development mode has been introduced, and low-code platforms have emerged that allow logic to be generated by graphically dragging and dropping components. These platforms convert visual logic into PLC executable code and integrate industrial protocols such as Modbus and OPC UA, aiming to simplify the process from design to deployment and meet the needs of rapid iteration.

[0003] While existing low-code platforms improve usability, they lack a quantitative evaluation and optimization mechanism for the structural quality of user-generated graphical logic definitions. Their ability to diagnose anomalies during the operation and maintenance phase is insufficient. Users may create complex, highly coupled spiderweb-like logic, ensuring only functional correctness but failing to optimize maintainability and efficiency. When runtime anomalies occur, existing technologies can usually only display the abnormal results, but cannot automatically backtrack and clearly display the entire chain of event dependencies and state transition sequences that led to the anomaly. This makes problem localization difficult and lacks precise basis for modification and iteration. Summary of the Invention

[0004] In view of the aforementioned existing problems, the present invention is proposed.

[0005] Therefore, this invention provides a low-code implementation method to solve the core problems of poor program maintainability and low operation and maintenance iteration efficiency caused by the lack of quantitative evaluation of the structural quality of graphical logic definitions and deep anomaly diagnosis capabilities in existing technologies.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution: In a first aspect, the present invention provides a low-code implementation method, which includes generating a graphical logic definition in response to user operations in a low-code project environment; By quantitatively analyzing the topological connectivity density and module cohesion of the graphical logic definition, structural reconstruction suggestions are generated for the graphical logic definition. The graphical logic definition after integrating the refactoring suggestions is compiled to generate target executable code, and the target executable code is deployed to the target PLC to form a running control logic instance; By tracing back the runtime execution path of the control logic instance, the event dependencies and state transition sequences that lead to specific abnormal states are extracted and visualized to obtain an execution path report; Based on the execution path report, the graphical logic definition is modified and version managed.

[0007] As a preferred embodiment of the low-code implementation method of the present invention, the following steps are included in responding to user operations and generating a graphical logic definition: In a low-code project environment, respond to user drag-and-drop operations on components in the task management interface, generate a layout draft of the components and their initial positions, and configure the specific parameters of the input and output pins of each component. By connecting the output pins of the source component and the input pins of the target component, the data flow and control logic relationship between the components are defined; Integrate the set of components that define the data flow and control logic relationship, and add more complex logic units composed of functional blocks to complete the assembly of graphical logic definition; Save the assembled graphical logic definition in the task management interface to generate the graphical logic definition.

[0008] As a preferred embodiment of the low-code implementation method of the present invention, the following steps are included: generating structural reconstruction suggestions for the graphical logic definition by quantitatively analyzing the topological connectivity density and module cohesion of the graphical logic definition: Based on the graphical logic definition, by traversing each node and weighting the sum of the quality of the connecting edges, suppressing according to the node depth, and taking the average of the local connectivity of all nodes, the specific value of the topological connectivity density is obtained. The specific numerical expression for the connectivity density of the topology is: ; in, This represents the specific value of the topological connectivity density. The total number of nodes. For node indexing, For nodes A connected edge, For nodes The set of all connected edges. The cross-penalty weighting coefficient is... Modular penalty weight coefficients, For nodes Input-output modular penalty factor; By calculating the core ratio of the number of internal connections to the total number of connections in a functional block, and then applying a weighted correction based on the boundary penalty term of the external connection ratio, the evaluation value of module cohesion is obtained. The expression for evaluating module cohesion is: ; in, This is the module cohesion evaluation value. This represents the number of connection edges between components within a function block. This represents the total number of all connecting edges in the function block. This represents the number of connection edges between the function block and external components. This is the boundary penalty coefficient; By combining the specific numerical values ​​of topological connectivity density and the evaluation values ​​of module cohesion, quantitative analysis is conducted to identify specific regions in the graphical logic definition where the topological structure is complex or the module cohesion is insufficient. Based on the correlation analysis of topology and maintenance cost in historical PLC low-code projects, combined with graph theory clustering coefficient inflection point verification and simulation stress test, the connectivity density threshold is obtained. Based on the quantitative analysis of the modularization criteria for industrial automation software, and combined with the correlation data of module cohesion and maintenance efficiency in historical projects, the module cohesion threshold is obtained. When a local component cluster has a topology connectivity density value greater than the connectivity density threshold and a module cohesion evaluation value less than the module cohesion threshold, it is extracted and encapsulated into an independent functional block to obtain a structural reconstruction suggestion.

[0009] As a preferred embodiment of the low-code implementation method of the present invention, the following steps are included: compiling the graphical logic definition after integrating the refactoring suggestions to generate the target executable code: The graphical logic definition after integration and refactoring suggestions is parsed and converted into a custom domain-specific language string to describe the control logic, forming an intermediate representation; The intermediate representation is transformed and abstracted into an abstract syntax tree. Static analysis is performed on the abstract syntax tree using an LLVM-based optimization strategy to obtain the optimized abstract syntax tree. The optimized abstract syntax tree is compiled into target executable code that can run in the Java Virtual Machine.

[0010] As a preferred embodiment of the low-code implementation method of the present invention, the following steps are included: Deploying the target executable code to the target PLC to form a running control logic instance: A physical communication connection with the target PLC is established through the data integration layer; The target executable code is completely transmitted to the target PLC's memory storage area through the established communication connection; The target executable code transferred to the target PLC memory is configured before execution. A start command is sent to the target PLC, which then loads and executes the configured target executable code. The target PLC begins to execute the target executable code in a loop, forming a running control logic instance.

[0011] As a preferred embodiment of the low-code implementation method of the present invention, the following steps are included: by tracing back the runtime execution path of the control logic instance, extracting and visualizing the event dependencies and state transition sequences that lead to specific abnormal states, and obtaining an execution path report: Monitor the variable values ​​and logic branch execution of running control logic instances, and detect when a running control logic instance triggers a specific abnormal state; When a specific abnormal state occurs, the complete runtime execution path of the control logic instance in operation is traced back within a fixed interval intercepted from the current moment; Extract the event dependencies that lead to specific abnormal states from the runtime execution path obtained through backtracking; Extract the state transition sequence of relevant variables from the runtime execution path obtained from backtracking, which leads to the occurrence of a specific abnormal state; An execution path report is generated based on the extracted event dependencies and state transition sequences.

[0012] As a preferred embodiment of the low-code implementation method of the present invention, the modification and version management of the graphical logic definition based on the execution path report includes the following steps: Analyze the execution path report to locate the functional block in the graphical logic definition that causes the specific abnormal state; Based on the issues identified in the execution path report, adjust the components already located in the graphical logic definition; Save the adjusted graphical logic definition as a new version graphical logic definition, create a version record for the saved new version graphical logic definition, and associate the version record with the execution path report on which it is based; The version history marks the new version of the graphical logic definition as being based on modifications to the previous version of the graphical logic definition, thus completing the version management of the graphical logic definition.

[0013] Secondly, the present invention provides a low-code implementation system, including a graphical logic definition module, which generates graphical logic definitions in response to user operations in a low-code project environment; The optimization module generates structural reconstruction suggestions for the graphical logic definition by quantitatively analyzing the topological connectivity density and module cohesion of the graphical logic definition. The logic parsing module compiles the graphical logic definition after integrating the reconstruction suggestions into target executable code, and deploys the target executable code to the target PLC to form a running control logic instance; The debugging module extracts and visualizes the event dependencies and state transition sequences that lead to specific abnormal states by tracing back the runtime execution path of the control logic instance, and obtains an execution path report. The management module modifies and manages the version of the graphical logic definition based on the execution path report.

[0014] Thirdly, the present invention provides a computer device including a memory and a processor, wherein the memory stores a computer program, wherein the computer program, when executed by the processor, implements any step of the low-code implementation method as described in the first aspect of the present invention.

[0015] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein: when the computer program is executed by a processor, it implements any step of the low-code implementation method as described in the first aspect of the present invention.

[0016] The beneficial effects of this invention are as follows: In a low-code environment, graphical logic definitions are generated by dragging and dropping components and connecting lines. A specific weighted algorithm is used to quantitatively analyze the topological connectivity density and module cohesion of the definition. Based on thresholds verified by historical data, structural reconstruction suggestions are made to encapsulate high-complexity clusters into independent functional blocks. This optimizes the program architecture from the source before compilation, improving maintainability. After the optimized logic definition is compiled and deployed to the PLC, the runtime execution path is traced back to extract and visualize the event dependencies and state transition sequences that cause anomalies. An execution path report with precise root cause localization is generated, allowing for accurate modification and version management of the graphical logic definition. This upgrades the low-code platform from a simple code generation tool to an intelligent development and operation integrated platform with forward-looking structural optimization and deep fault diagnosis capabilities, improving the development quality, operation and maintenance efficiency, and full lifecycle value of industrial automation software. Attached Figure Description

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

[0018] Figure 1 A flowchart for the low-code implementation method.

[0019] Figure 2 A diagram illustrating a low-code implementation of the system. Detailed Implementation

[0020] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0021] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0022] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0023] Reference Figures 1-2 As one embodiment of the present invention, this embodiment provides a low-code implementation method, including the following steps: S1. In a low-code project environment, respond to user actions and generate graphical logic definitions.

[0024] S1.1 In a low-code project environment, respond to the user's drag-and-drop operation of components in the task management interface, form a layout draft of the components and their initial positions, and configure the specific parameters of the input and output pins of each component.

[0025] Furthermore, based on the component layout draft with initialized pin parameters, the user performs a connection operation in the task management interface, using directed line segments to connect the output pin of the source component to the input pin of the target component, defining a data transmission channel from the data producer to the consumer, thereby clarifying the control logic relationship between components. For example, connecting the pressed state output pin of the button component to the start input pin of the motor component defines a control logic that starts the motor when the button is pressed.

[0026] Specifically, the physical architecture and spatial relationships of logical elements are established by capturing the layout draft formed by the user dragging and dropping components. Before the connection operation begins, the specific parameters of the input and output pins of each component are configured independently. The interface contract and data interaction specifications of all functional units are clearly defined in advance. This ingenious idea of ​​defining the interface first and then establishing the connection avoids the problems of interface type mismatch and semantic ambiguity that may be caused by arbitrary and impromptu connections in traditional graphical programming.

[0027] S1.2. By connecting the output pins of the source component and the input pins of the target component, the data flow and control logic relationship between the components are defined.

[0028] Furthermore, users can perform connection operations within the task management interface. Users can use a mouse or touch gesture to press and drag a connection from the output pin of the source component to the input pin of the target component. This action triggers a series of background logic executions by the interface engine: verifying the data type compatibility between the source component's output pin and the target component's input pin (e.g., whether a Boolean output can be connected to a Boolean input); visually establishing a directed line segment with an arrow clearly pointing to the data flow target; and internally establishing a directed edge record between the source and target components, which not only associates the two pins but also carries the semantics of the data flow defined by this connection. This transforms an intuitive graphical drag-and-drop operation into a data flow contract with strict semantic constraints, outputting a set of components with clear data flow direction and control logic relationships. Specifically, when handling connection operations, the task management interface performs real-time verification based on the pre-configured parameters of the input and output pins. For example, when an integer output pin is attempted to be connected to a string input pin, the interface will immediately provide an error message and prevent the connection from being established. This real-time verification mechanism is a key detail, bringing the core concepts of type-safe and directional programming languages ​​forward and integrating them into the user interaction of graphical connections. This allows the discovery and correction of logical errors to be moved from the post-compilation stage to the build stage, improving development efficiency and reliability. Users do not need to wait for code generation or deployment; they can obtain real-time feedback during the drawing process, thus ensuring the correctness of the graphical logic definition at the build time.

[0029] It should be noted that after the connection is completed, the control logic relationship between components is defined through the topology of the connection. For example, connecting the output pins of two different source components to different input pins of the same target component may define a parallel processing logic; while connecting the output of one component to the enable input pin of another component defines a conditional control logic. By using the intuitiveness of graphical connections to carry complex program semantics, the process of constructing control logic becomes visual and easy for users to understand. The complexity of the control logic is encapsulated in the connection method, and users can indirectly and error-free construct the correct program logic by manipulating graphical elements.

[0030] S1.3 Integrate the set of components that define the data flow and control logic relationship, and add more complex logic units composed of functional blocks to complete the assembly of the graphical logic definition.

[0031] Furthermore, based on the component set of data flow and control logic relationships, pre-built complex logic units composed of more basic components are selected from the function block library, such as a complete PID controller function block or a communication protocol stack function block. Users drag and drop the function blocks to the task management interface and lay them out together with the existing basic component set. By connecting the input and output pins exposed by the function blocks, the function blocks are integrated with the original component set. For example, the output pin of a temperature sensor component is connected to the input pin of a PID controller function block, and then the output pin of the PID controller function block is connected to the input pin of a regulating valve component. This allows the assembly of graphical logic definitions to be elevated from atomic component connections to a modular functional integration level. By increasing the granularity of logical abstraction, developers are allowed to think about and build complex systems in terms of higher-level functional units, which greatly improves the efficiency and clarity of logical expression.

[0032] Specifically, in the process of integrating the basic component set and functional blocks, the task management interface maintains a unified topology that can accommodate connections between basic components, connections within functional blocks, and connections between functional blocks and external basic components. It supports hierarchical modeling with mixed granularity. The graphical logic definition is no longer a huge, flat network, but a modular structure containing multiple levels, each with appropriate complexity. This allows each part of the logic to be developed, tested, and reused independently, and then integrated through well-defined interfaces to complete the assembly of the graphical logic definition. S1.4 Save the assembled graphical logic definition in the task management interface to generate the graphical logic definition.

[0033] Furthermore, the assembled graphical logic definition, including all components, functional blocks, their attributes, locations, and all connections between them, is serialized into a structured data document in a specific format and persistently stored by the user triggering a save operation in the task management interface. This overcomes the limitation that the results of traditional prototyping tools cannot be directly converted into deployable code.

[0034] S2. By quantitatively analyzing the topological connectivity density and module cohesion of the graphical logic definition, structural reconstruction suggestions are generated for the graphical logic definition.

[0035] S2.1 Based on the graphical logic definition, by traversing each node and weighted summing of the quality of the connecting edges, suppressing based on the node depth, and taking the average of the local connectivity of all nodes, the specific value of the topological connectivity density is obtained.

[0036] Furthermore, the generated graphical logic definition is parsed to obtain its complete set of nodes and edges. Each node in the graphical logic definition is traversed. For the currently traversed node, all edges connected to it are identified to form an edge set. For each edge in this edge set, a weighted calculation is performed, taking into account the existence of the edge and incorporating factors for edge quality evaluation. For example, geometric operations are used to detect whether edges intersect, and the modularity is evaluated by analyzing whether the two nodes connected by the edge belong to the same functional block. The weighted results of each edge are summed to obtain the initial value of the local connectivity of the current node. The depth value of the current node in the nested hierarchy of the graphical logic definition is queried, and the depth value is used to suppress the initial value of local connectivity. For example, the contribution of deep nodes is appropriately reduced. After traversing all nodes, the local connectivity values ​​of each node after depth suppression are accumulated and divided by the total number of nodes to obtain the specific value of the topological connectivity density.

[0037] Specifically, in the process of calculating the quality of each connecting edge by weighted summation, the selection and fusion of weighting factors are crucial. The quality assessment of connecting edges is not a single dimension, but rather a comprehensive consideration of layout complexity and architectural rationality. A connecting edge that intersects with other edges multiple times has a high layout complexity. An edge connecting nodes belonging to different functional blocks is assigned a weight to each edge as a function of these quality assessment factors, rather than a fixed value. This transforms subjective, experience-based code smell identification into objective, quantitative indicators based on graph theory and geometric characteristics.

[0038] It should be noted that in the definition of graphical logic, nodes may be located at different levels of logical nesting. For example, a node in the top-level task flow and a node inside a deeply nested functional block may have different contributions to the overall complexity, even if they have the same number of local connections. The depth suppression mechanism is implemented through a decay function related to the depth value. The larger the node's depth value, the more its calculated local connectivity is suppressed when participating in the final average calculation. Recognizing the impact of logical depth on the perception of complexity, and that not all connections are equally important, encapsulates complexity in deep logic while maintaining the clarity of surface logic. This conforms to the best practices of layered design, making the specific numerical value of the calculated topological connectivity density more reflective of the developer's actual perception and psychological complexity when maintaining the code.

[0039] The specific numerical expression for the connectivity density of the topology is: ; in, This represents the specific value of the topological connectivity density. The total number of nodes. For node indexing, For nodes A connected edge, For nodes The set of all connected edges. The cross-penalty weighting coefficient is... Modular penalty weight coefficients, For nodes Input-output modular penalty factor.

[0040] S2.2. By calculating the core ratio of the number of internal connections to the total number of connections in the functional block, and performing a weighted correction based on the boundary penalty term of the external connection ratio, the evaluation value of module cohesion is obtained.

[0041] Furthermore, count the number of connection edges between all components within the function block, i.e. Simultaneously, count the number of connection edges between the function block and all external components, i.e., Ecross-boundary; the total number of all connection edges of the function block. for and The sum of these values ​​represents the core proportion of the number of connections within a function block to the total number of connections. This reflects the tightness of the connections between components within a functional block. It calculates the proportion of external connections to the total number of connections within the functional block. Based on this external connectivity ratio, a boundary penalty term is constructed; its form is as follows: ,in It is a preset boundary penalty coefficient used to adjust the negative impact of external connections on the overall evaluation value. The core proportion is added to the boundary penalty term to obtain the module cohesion evaluation value.

[0042] Specifically, the cohesion assessment is expanded from a single internal ratio to a composite index that includes external dependency penalties. It recognizes that the quality of a module depends not only on its internal tightness but also on its degree of coupling with the outside world. By introducing a boundary penalty term, the formula for high cohesion and low coupling design overcomes the defect that focusing only on the internal connection ratio may misjudge a module that is highly coupled with the outside world as high quality. This makes the assessment results more comprehensive and in line with software engineering best practices, and outputs a module cohesion assessment value that can comprehensively reflect the internal tightness and external independence of functional blocks.

[0043] The expression for evaluating module cohesion is: ; in, This is the module cohesion evaluation value. This represents the number of connection edges between components within a function block. This represents the total number of all connecting edges in the function block. This represents the number of connection edges between the function block and external components. This is the boundary penalty coefficient.

[0044] S2.3. Combining the specific numerical values ​​of the topological connectivity density and the evaluation values ​​of module cohesion, quantitative analysis is performed to identify specific regions in the graphical logic definition where the topological structure is complex or the module cohesion is insufficient.

[0045] Furthermore, the graphical logic is defined as multiple candidate local component clusters based on functional boundaries and connection density. For each cluster, the specific value of the topological connectivity density and the evaluation value of module cohesion are calculated independently. When calculating the specific value of the topological connectivity density, the cluster is treated as a subgraph, and the same weighted average logic as the global calculation is applied to evaluate the quality and complexity of internal connections. When calculating the evaluation value of module cohesion, the cluster is treated as an independent unit, and the influence of the proportion of internal connections and external connections is analyzed. The global quality evaluation is pushed down to the local area for independent diagnosis. Through partitioned evaluation, problem hotspots can be accurately located, avoiding the global average value from masking serious local problems.

[0046] Specifically, the numerical value of topological connectivity density, which reflects the overall connectivity complexity, is combined with the evaluation value of module cohesion, which reflects the modularity quality, to perform joint analysis on the graphical logic definition. This allows for the identification of specific component clusters or functional block regions that exhibit abnormally complex connectivity density and severely insufficient module cohesion. It avoids misjudgments that may arise from a single indicator and ensures that the identified regions are truly problem areas with structural defects through mutual verification of the two dimensions.

[0047] S2.4. Based on the correlation analysis of topology and maintenance cost in historical PLC low-code projects, combined with graph theory clustering coefficient inflection point verification and simulation stress test, the connectivity density threshold is obtained.

[0048] Furthermore, collect historical PLC low-code project data with complete operation and maintenance records. For each functional module or local logic area in each project, extract corresponding maintenance cost indicators from the operation and maintenance database, such as the number of defect repairs, average fault troubleshooting time, and the scope affected by code modifications. Using statistical analysis methods, draw scatter plots or perform regression analysis between the specific values ​​of topology connectivity density and maintenance costs to observe the trend of maintenance costs as connectivity density increases. Identify the inflection point on the maintenance cost curve, that is, when the specific value of topology connectivity density exceeds a certain critical value, the maintenance cost begins to show a non-linear growth range. The critical value is a candidate value of connectivity density threshold derived from historical data. For example, the analysis may find that when the connectivity density of a module is below a certain value, its annual modification frequency remains stable at a low level; once it exceeds this value, the modification frequency and difficulty increase sharply.

[0049] Specifically, the topological structure defined by graphical logic is abstracted into a network model in graph theory. The clustering coefficients of each subgraph (i.e., candidate local component clusters) in this network model are extracted to measure the density of node clusters. By increasing or decreasing the number of connecting edges constituting the subgraphs (simulating changes in connectivity density), the relationship curve between the clustering coefficient and connectivity density is observed. When the connectivity density increases from a low level, the clustering coefficient rises rapidly, indicating that the structure tends to be ordered. However, when the connectivity density exceeds a certain inflection point, the growth of the clustering coefficient will tend to level off or even decrease, the connections become disordered, and the structure shifts from ordered to disordered. The connectivity density value corresponding to this inflection point is a threshold candidate value verified from a graph theory perspective. For example, it corresponds to the critical point where the network structure degenerates from the characteristics of an ideal small-world network to a random mesh network.

[0050] It should be noted that a test environment containing the target PLC hardware or high-fidelity simulation is constructed. A set of graphical logic definitions with equivalent functions but different specific values ​​of topological connectivity density is designed, including multiple versions from low density to high density. Each version is deployed to the test environment and runs the same test case set containing boundary conditions and abnormal situations to simulate real workload and pressure. During the test, key performance indicators, such as the stability of the program scan cycle, memory usage, and response delay to sudden events, are collected. The relationship between performance indicators and the specific value of topological connectivity density is analyzed to locate the critical connectivity density value at which performance begins to deteriorate significantly (such as a sharp increase in response delay or timeout). The candidate threshold value confirmed from the perspective of runtime performance is used to test the functional correctness and non-functional attributes (performance, stability) of structures with different complexities in a near-realistic environment through experimental methods. This ensures that the set connectivity density threshold guides static structure design and guarantees the reliability of dynamic operation, giving the connectivity density threshold a solid practical foundation.

[0051] S2.5 Based on the quantitative analysis of the modularization criteria for industrial automation software, and combined with the correlation data of module cohesion and maintenance efficiency in historical projects, the module cohesion threshold is obtained.

[0052] Furthermore, the determination of the module cohesion threshold stems from the quantitative analysis of the modular design principles of industrial automation software. This involves analyzing the requirements for high cohesion and low coupling in industry standards such as IEC 61131-3, and translating these requirements into a specific range for cohesion evaluation values. By analyzing the correlation data between the module cohesion evaluation values ​​and maintenance efficiency (such as the scope of modification and unit test pass rate) in historical projects, the cohesion critical point at which maintenance efficiency begins to decline sharply is determined. This empirical data is then combined with theoretical principles for mutual verification, leading to the module cohesion threshold.

[0053] S2.6 When the specific value of the topological connectivity density is greater than the connectivity density threshold and the evaluation value of the module cohesion is less than the module cohesion threshold, the local component clusters are extracted and encapsulated into independent functional blocks to obtain structural reconstruction suggestions.

[0054] Furthermore, for each local component cluster, it is determined whether the specific value of the topology connectivity density is greater than the connectivity density threshold and whether the evaluation value of the module cohesion is less than the module cohesion threshold. Only when both conditions are met simultaneously, a reconstruction suggestion is triggered for the cluster. This cluster is extracted from the original graphical logic definition, and the internal components and connections are encapsulated into a new, independent functional block. Clear input and output interfaces are defined for this new functional block to replace the original complex external connections. A strict judgment logic that requires both conditions to be met simultaneously is used to trigger the reconstruction, and the output is a reconstruction suggestion that clearly points to a specific region.

[0055] S3. Compile the graphical logic definition after integrating the refactoring suggestions to generate the target executable code.

[0056] S3.1 Parse the graphical logic definition after the integration and refactoring suggestions, and convert it into a custom domain-specific language string used to describe the control logic to form an intermediate representation.

[0057] Furthermore, the graphical logic definition after the integrated refactoring suggestions is parsed, traversing all components, functional blocks, and edges connecting them. The parsing process identifies the type, attributes, and pin connections of each component, and converts each graphical element into a corresponding text instruction according to predefined syntax rules. For example, the event of clicking a button component labeled "motor start" can be converted into a similar domain-specific language string. All such strings are combined in execution order to form a complete script, forming an intermediate representation.

[0058] Specifically, the semantics of graphical logic are mapped losslessly to a structured text form. Domain-specific languages ​​act as a bridge between graphical and formal language domains. They retain the intuitiveness of graphical expression while possessing the precision of textual language that can be processed programmatically. This overcomes the fundamental obstacle that graphical definitions are difficult to process directly by traditional compiler toolchains, and outputs a custom domain-specific language string, i.e., an intermediate representation, used to describe the control logic.

[0059] S3.2. Transform and abstract the intermediate representation into an abstract syntax tree. Apply an LLVM-based optimization strategy to the abstract syntax tree and perform static analysis to obtain the optimized abstract syntax tree.

[0060] Furthermore, the domain-specific language string intermediate representation generated in the previous step is received and parsed into an abstract syntax tree (AST) by a parser. The nodes of the AST represent various structural elements in the language, such as expressions, statements, and function calls, and the hierarchical relationships between nodes reflect the logical structure of the code. Subsequently, LLVM-based optimization strategies are applied to the AST for static analysis, such as dead code elimination to remove code branches that will never be executed and constant propagation to simplify expression evaluation. These optimizations are performed directly at the AST level, generating a more concise and logically efficient optimized AST.

[0061] Specifically, by introducing the concept of multi-layered intermediate representation and optimization from modern compiler infrastructure into the field of graphical programming, graphical logic definitions can enjoy the same depth of code optimization as traditional text-based programming languages ​​in the early stages of compilation. This improves the quality of generated code from the source, rather than generating redundant and inefficient code. It overcomes the common pain points of low-quality code and low running efficiency of traditional graphical programming tools, and ensures the industrial-grade reliability of low-code development results.

[0062] S3.3 Compile the optimized abstract syntax tree to generate target executable code that can run in the Java Virtual Machine.

[0063] Furthermore, the code generator traverses each node of the abstract syntax tree and generates equivalent Java language code snippets based on the node type. For example, an abstract syntax tree node of a loop control structure is converted into a Java for or while loop statement block. All these code snippets are combined into a complete Java source file, which is then compiled into standard Java bytecode, i.e., target executable code, by the Java compiler, which can run in the Java Virtual Machine.

[0064] Specifically, the target runtime environment was identified as the Java Virtual Machine (JVM), and the final conversion from a hardware platform-independent abstract syntax tree to platform-specific executable code was completed. This fully leverages the advantages of the JVM, such as cross-platform compatibility, high performance, and a mature ecosystem, enabling the generated graphical logic to be seamlessly deployed to any hardware or server that supports the JVM. This greatly enhances the versatility and deployability of the low-code platform's results and achieves standardization and openness of the generated code.

[0065] S4. Deploy the target executable code to the target PLC to form a running control logic instance.

[0066] S4.1 Establish a physical communication connection with the target PLC through the data integration layer.

[0067] Furthermore, the data integration layer selects and initializes the corresponding industrial communication protocol driver based on the target PLC model and network configuration. For example, it configures the correct IP address and port number for PLCs that support Modbus TCP protocol, and establishes a secure session channel for PLCs that support OPC UA. The connection establishment process includes handshake, authentication and parameter negotiation to ensure the reliability and security of the communication link.

[0068] Specifically, by encapsulating the differences between different industrial communication protocols through a unified abstraction layer, a transparent and consistent device access interface is provided for upper-layer applications. This eliminates the need for subsequent code transmission and deployment actions to concern themselves with the specific implementation details of the underlying physical connection. It overcomes the problems of complex deployment tools, large adaptation workload, and difficulty in large-scale management caused by protocol fragmentation in traditional industrial automation, and outputs a stable and usable physical communication connection with the target PLC.

[0069] S4.2 Transmit the target executable code completely to the target PLC's memory storage area through the established communication connection.

[0070] Furthermore, the target executable code is treated as a complete data entity, and a cryptographic hash value is obtained for integrity verification. The data integration layer divides the target executable code into appropriately sized data blocks, attaches a sequence number and error detection code to each data block, and sends them sequentially to the target PLC through the established physical communication connection. The target PLC performs error detection on each data block at the receiving end. If an error is found, it requests retransmission of the specific data block to ensure the correct reception of each data block. After all data blocks are successfully received, they are reassembled in the target PLC memory in sequence to restore the complete target executable code. The hash value of the reassembled data is compared with the initial hash value at the sending end. Only if there is a complete match is it confirmed that the target executable code has been completely and accurately written into the target PLC's memory storage area. The ingenious design of this implementation lies in applying the core concept of network communication protocols for reliable large-scale data transmission to the program deployment process in an industrial environment, outputting the target executable code that has been completely and accurately stored in the target PLC's memory storage area.

[0071] Specifically, in terms of the refinement of block transmission and verification, the principles of reliable data transmission protocols (such as TCP) are borrowed and adapted to the application layer of industrial communication protocols. The target executable code is divided into multiple data blocks, each carrying a sequence number and a cyclic redundancy check code. The sender sends these data blocks in sequence, and the receiver (target PLC) verifies each arriving data block. If a data block fails to be verified or is lost, the receiver can request the sender to retransmit that specific data block instead of retransmitting the entire program. This transforms the one-time, high-risk transmission of large amounts of data into a series of independently verifiable and repairable low-risk, small-volume data transmissions, improving the success rate and efficiency of transmission in unreliable industrial network environments. Even if individual data packets are damaged or lost during transmission, only that small portion of data needs to be retransmitted, rather than the entire target executable code.

[0072] It's important to note that, in refining end-to-end integrity verification, a comprehensive check is added on top of block checksum verification. Before transmission begins, the cryptographic hash value (e.g., SHA-256) of the entire target executable code is used. After all data blocks are successfully received and reassembled at the target PLC, the hash value of the reassembled data is checked. Only if the two hash values ​​are completely identical is the transmission confirmed as successful, providing the highest level of data integrity guarantee. Block checksum verification ensures the correctness of each data block during transmission, while end-to-end hash checksum verification ensures that all data blocks are correctly reassembled and that the overall content is completely consistent with the source file, effectively preventing possible disorder or unforeseen damage to data blocks during reassembly.

[0073] S4.3. Configure the target executable code transferred to the target PLC memory before execution, and send a start command to the target PLC to load and execute the configured target executable code.

[0074] Furthermore, the target executable code, already transferred to the target PLC's memory, undergoes pre-run configuration. This configuration process includes setting the task cycle scan period, initializing program variables to safe default values, and binding the mapping relationship between input / output variables and specific PLC hardware channels. The configuration operation is completed by sending a series of parameter setting commands to the target PLC through the data integration layer. After configuration, a clear start command is sent to the target PLC through the same communication connection. The start command instructs the target PLC's operating system or runtime engine to load the configured target executable code from the storage area into the executable memory area, create a corresponding task context, and begin interpreting or executing the instruction logic. This process is clearly divided into two independent and orderly stages: parameter configuration and execution triggering. This decouples the program code from the runtime environment, allowing for calibration and safety checks of key parameters before final execution. The output is a stream of instructions that has been loaded by the target PLC and is ready for execution.

[0075] Specifically, regarding the detailed aspects of pre-run configuration, it recognizes that the same executable code needs to run under different hardware environments or process requirements. For example, a motor control logic may need to set different acceleration time parameters for motors with different power ratings. The pre-run configuration mechanism allows for adaptation to specific scenarios through external parameterization settings without modifying the code itself. This separates the static logic of the program from the dynamic parameters, greatly enhancing the flexibility and reusability of the code. The same compiled executable code can be applied to multiple occasions through different configurations, avoiding the tedious process of recompiling and deploying the entire program for minor differences.

[0076] S4.4 The target PLC begins to execute the target executable code in a loop, forming a running control logic instance.

[0077] Furthermore, the target PLC's runtime engine is activated by the start command, and the engine enters an infinite loop, namely the scan cycle. In each scan cycle, the engine reads the state of all input signals from the physical input module, such as sensor switch values ​​or analog values, and maps them to the input variable memory area of ​​the target executable code. The engine sequentially interprets and executes the instruction logic in the target executable code, corresponding to the component and connection relationships in the original graphical logic definition. During instruction execution, internal variables are calculated and updated. After execution, the engine writes the latest state of the output variable memory area to the physical output module, driving the actuator to act, such as lighting up an indicator light or starting a motor. The engine performs internal diagnostics and communication processing, and then begins the next scan cycle. This seamlessly embeds the graphical logic definition into the PLC's inherent and reliable execution model, making full use of the deterministic scanning mechanism designed by the PLC hardware and firmware specifically for industrial control. This ensures that the control logic generated by the low-code platform can achieve the same real-time performance and reliability as manually written code, forming a running control logic instance.

[0078] Specifically, the target PLC's runtime engine cyclically executes three basic phases at fixed time intervals: input sampling, program execution, and output refresh. This cyclical mechanism ensures that the control logic's response to the physical world is predictable and unaffected by other tasks. Input signals are read in batches at the beginning of the cycle, avoiding logical inconsistencies caused by signal changes during program execution. The program execution phase focuses on processing logical operations, and the output refresh phase applies the results uniformly to external devices, transforming asynchronous external events into synchronous internal processing. This enables potentially complex control logic generated based on graphical logic definitions to operate stably under strict time constraints, with its behavior being completely predictable.

[0079] It should be noted that each instruction in the target executable code directly corresponds to a functional element in the original graphical logic definition. A timer component in a graphical logic definition is represented in the target executable code as a sequence of operation instructions on the PLC's internal timer resources. The connection relationships between components are compiled into variable assignment and transfer instructions. When the instructions are executed cyclically within the scan cycle, the static control strategy described by the graphical logic definition is dynamically instantiated into an active entity that continuously monitors and adjusts the external physical process. This completes the seamless transformation from the abstract logic description in the development stage to the specific control behavior at runtime. The compilation process not only completes the syntax translation but also the semantic mapping, accurately translating high-level graphical intentions into primitive operations executable by the underlying hardware, thus realizing reliable interaction between the digital world and the physical world.

[0080] S5. By tracing back the runtime execution path of the control logic instance, extract and visualize the event dependencies and state transition sequences that lead to specific abnormal states, and obtain the execution path report.

[0081] S5.1 Monitor the variable values ​​and logic branch execution of the running control logic instance, and detect when the running control logic instance triggers a specific abnormal state.

[0082] Furthermore, a lightweight monitoring probe is embedded within the running control logic instance. This probe continuously reads key variable values ​​of the running control logic instance non-intrusively, such as temperature sensor readings, motor speed setpoints, and the current values ​​of internal counters or timers, through the debugging interface or memory mapping technology provided by the target PLC. It monitors the execution of logic branches and records the flow of conditional statements, such as whether a loop exits or an exception handling branch is activated. The monitoring process compares the collected real-time data with a predefined set of exception condition rules. These rules define specific exception states, such as variable values ​​exceeding safety thresholds, drastic changes in variable values ​​within a short period, or a key logic branch not being triggered for an extended period. Once the real-time data satisfies any Boolean expression for an exception condition, the running control logic instance is determined to have triggered a specific exception state, immediately triggering subsequent backtracking analysis. This transforms passive log recording into an active condition triggering mechanism, outputting specific exception state trigger events.

[0083] Specifically, regarding monitoring variable values ​​and logical branches, based on the concept of state observation in control theory, the set of variables of a running control logic instance constitutes the internal state space, while the execution path of the logical branch reflects the conditions and direction of state transitions. This is equivalent to observing the state evolution of a dynamic system in real time, enabling the detection of two types of anomalies: one is state anomaly, where the value of a variable itself is abnormal; the other is behavioral anomaly, where the execution flow of the control logic deviates from the expected path. For example, in a liquid level control logic instance, the monitoring probe may simultaneously monitor whether the liquid level sensor variable value exceeds the limit and whether the high liquid level alarm branch is activated. Multi-dimensional monitoring provides a more comprehensive perspective on anomaly detection. The program is observed as a dynamic system, not just static code execution, thus enabling the discovery of more hidden, process-related anomalies.

[0084] It should be noted that the abnormal condition rule base and real-time comparison, based on rule-based real-time pattern matching, encode domain knowledge (such as equipment safety operating procedures and process parameter limitations) into machine-understandable logical rules. Each rule is a Boolean expression, such as motor current > rated current safety factor or valve opening command and feedback value deviation exceeding the dead zone for three consecutive scan cycles. After each scan cycle or specific event, the monitoring process quickly compares the current variable values ​​and logical branch states with these rules, allowing the monitoring strategy to flexibly adapt to different control logics and application scenarios without modifying the monitoring program itself.

[0085] S5.2 When a specific abnormal state occurs, backtrack the complete runtime execution path of the control logic instance in operation within a fixed interval intercepted forward from the current moment.

[0086] Furthermore, the detection of a specific abnormal state directly triggers an event. Once triggered, a dedicated diagnostic service immediately issues an instruction to the running control logic instance to freeze a runtime data cache that operates as a circular buffer. During the monitoring phase, the cache continuously records key snapshot data for each scan cycle in a first-in-first-out manner, including but not limited to the values ​​of all monitored variables, program counter positions, active task identifiers, and important intermediate calculation results. The freeze operation ensures that the complete historical data at the time of the anomaly and the period prior to it is fully preserved and will not be overwritten by new runtime data. The diagnostic service extracts the complete data sequence from the frozen cache, tracing back from the current anomaly moment. This implements a continuous historical data recording and trigger-based freeze mechanism based on a circular buffer, balancing the resource overhead of continuous monitoring with the data integrity requirements of fault diagnosis. It retains key evidence only when an anomaly occurs, rather than endlessly recording all data, and outputs the complete runtime execution path data for the period prior to the occurrence of the specific abnormal state.

[0087] Specifically, the circular buffer caching mechanism draws inspiration from the working principle of flight data loggers, also known as black boxes. A fixed-size memory area is divided into consecutive frames, with each frame storing snapshot data for one scan cycle. The monitoring process continuously updates the buffer by writing data in a circular manner, with the latest data overwriting the oldest data. The innovation of this mechanism lies in its resource-efficient way of always maintaining the latest running state within a time window in memory, with minimal impact on running performance. At the same time, it ensures that the running context during the most critical period before the anomaly can be obtained immediately when any anomaly occurs, providing a stable and reliable data source for reliable fault reproduction.

[0088] S5.3 Extract the event dependencies that cause specific abnormal states from the runtime execution path obtained from the backtracking.

[0089] Furthermore, a time sequence analysis is performed on the runtime execution path obtained through backtracking. The runtime execution path is a data sequence that records a series of states and events, sorted by timestamps. The analysis process identifies key event nodes in the path that are directly related to specific abnormal states, such as an abnormal jump of a variable or the setting of an error flag. The algorithm traces back the preconditions of each key event node, that is, it looks for those previous events that occurred earlier in time and whose logical state changes may cause the event to be triggered.

[0090] Specifically, for example, before a motor overload alarm occurs under a specific abnormal state, there may be events such as the issuance of a start command, overload current exceeding the limit, and protection delay timer timeout. By analyzing the timing relationship and logical conditions between these events, a directed graph is constructed, where nodes represent events and edges represent triggering or dependency relationships. The complete event dependency chain from the initial triggering event to the eventual occurrence of the specific abnormal state is extracted from the directed graph, revealing why a series of events occur in sequence, that is, reconstructing the fault propagation path, and outputting a sequence of key events and dependencies that clearly describe the occurrence of the specific abnormal state.

[0091] S5.4 Extract the state transition sequence of relevant variables from the runtime execution path obtained from the backtracking process, which leads to the occurrence of a specific abnormal state.

[0092] Furthermore, data is extracted from the backtracked runtime execution path, focusing on the set of variables related to the occurrence of a specific abnormal state. This includes variables that directly trigger the specific abnormal state, as well as key intermediate variables identified in the event dependency chain. For each related variable, values ​​at a series of consecutive sampling points are extracted from the runtime execution path in chronological order to form a time series data. For example, for a specific abnormal state that causes a motor to overload and stop, the state transition sequence of related variables may include the change curve of the motor current value from start to peak, the rising trajectory of the winding temperature value, and the corresponding record of the cooling fan speed. The time-stamp-aligned numerical sequence together constitutes the state transition sequence of the related variables.

[0093] Specifically, by transforming discrete event logs into continuous state evolution trajectories, it is discovered that many anomalies do not occur instantaneously, but rather result from the gradual deterioration of internal states until they exceed a threshold. By capturing this process of quantitative change leading to qualitative change, the state transition sequence provides dynamic and visual evidence for understanding the failure mechanism. This design overcomes the limitation of simple event analysis, which can only see the result and not the process. It allows operations personnel to intuitively see how anomalies accumulate step by step and eventually erupt, just like observing a chart. The output is the state transition sequence of relevant variables in the process leading to a specific abnormal state.

[0094] S5.5. Based on the extracted event dependencies and state transition sequences, generate an execution path report.

[0095] Furthermore, information fusion and structured organization are performed on event dependencies and state transition sequences. Event dependencies are transformed into a sequence description with a clear causal orientation, which is summarized in text as event A occurring first, then triggering event B, and finally leading to event C (i.e., a specific abnormal state). The state transition sequence is transformed into a data table or trend chart with time-series markers, clearly showing the continuous numerical changes of key variables during the event chain, and is filled into a preset report template.

[0096] Specifically, the report template includes several core parts: a description of the specific abnormal state, a chronological chain of event dependencies, a visualization of the state transition sequence of key variables, and an automatically inferred summary of the root cause of the abnormality based on this information. This generates a highly readable execution path report document containing structured text, data, and chart elements. It integrates scattered, raw analytical data points into a complete and easily understood diagnostic story with a logical narrative. It not only lists the facts (events and data), but more importantly, it elucidates the causal relationships and dynamic processes between the facts, thereby answering the three core questions: what happened, why it happened, and how it evolved. The result is an execution path report that accurately pinpoints the root cause.

[0097] S6. Modify and version manage the graphical logic definition.

[0098] S6.1 Analyze the execution path report to locate the functional block in the graphical logic definition that causes the specific abnormal state.

[0099] Furthermore, the execution path report is parsed to extract key event dependency chains and state transition sequences. The execution path report details a series of events leading to specific abnormal states and the changes in related variables. The analysis process maps the events in the report to elements in the graphical logic definition. For example, the execution path report indicates that the motor overload alarm event is triggered by the current sampling value exceeding the limit event, which in turn is related to the start-up of a high-power load event. These event names match the output pin names or component labels of the functional blocks in the graphical logic definition. By traversing the hierarchical structure of the graphical logic definition, the specific functional blocks or components that generate these event signals are located, such as the functional block responsible for current sampling or the functional block that performs load start-stop control. The starting point, key nodes, and ending point of the causal chain revealed in the execution path report are mapped to specific functional blocks in the graphical logic definition, thereby completing the location of the root cause of the problem and outputting a clear identifier of one or more functional blocks in the graphical logic definition that lead to a specific abnormal state.

[0100] Specifically, regarding the refined mapping and matching of events and function blocks, based on naming conventions and signal flow tracing, each function block or component in the graphical logic definition has a unique identifier and clearly defined input / output pin names. These names are preserved or associated in the event descriptions of the execution path report. For example, the PID_Controller_1.Output event mentioned in the execution path report can be directly matched by name to the Output pin of the function block identified as PID_Controller_1 in the graphical logic definition. For more complex event chains, the mapping process traces the signal flow along the graphical logic definition. If the report indicates that event A causes event B, the mapping process first finds the function block that generated event A in the graphical logic definition, then follows the connection from the output pin of that function block to find the downstream function block and verifies whether the downstream function block generates event B.

[0101] S6.2. Based on the issues pointed out in the execution path report, adjust the components that have been located in the graphical logic definition.

[0102] Furthermore, the execution path report is interpreted in detail to accurately understand the essence and root cause of the problems identified. The execution path report may reveal various problem types, such as improper parameter settings, missing logical conditions, or signal flow design defects. Based on the report's conclusions, targeted adjustments are made to the components in the identified graphical logic definition. If the report points to parameter issues, such as an excessively high setpoint in a temperature control loop causing frequent over-temperature alarms, the adjustment operation includes modifying the parameter attributes of the corresponding function block to adjust the setpoint to a reasonable range. If the report reveals logical defects, such as a lack of interlock protection for abnormal states, the adjustment operation involves inserting new judgment components into the original logic flow, such as adding a condition judgment function block to prohibit the start command when the device is not ready. If the report shows that there are race conditions or timing errors in the signal flow, the adjustment operation may include adjusting the execution order of components, adding delay units, or optimizing signal paths. All adjustments are completed through visual operations such as dragging, connecting lines, and modifying attributes in the graphical logic definition editing interface.

[0103] Specifically, the execution path report is transformed from a descriptive diagnostic document into a work instruction that directly guides specific modification operations. This ensures that every modification directly targets the confirmed root cause, significantly improving the accuracy and efficiency of the repair process. The output is a graphical logical definition showing that targeted adjustments have been made based on the issues identified in the execution path report.

[0104] S6.3 Save the adjusted graphical logic definition as a new version graphical logic definition, create a version record for the saved new version graphical logic definition, and associate the version record with the execution path report on which it is based.

[0105] Furthermore, after completing all adjustments in the graphical logic definition editing interface, the user performs a save operation. The save operation triggers the version management process, serializing the current graphical logic definition state in memory, including all components, functional blocks, connections, and their attributes, into an independent data file. A unique new version identifier is assigned to this data file, which typically follows an incrementing version number rule. A new version record entry is created, containing key metadata: the new version identifier, timestamp, and modifier information. During the version record creation process, a bidirectional association is established between this entry and the execution path report it is based on. This association is achieved by embedding the unique identifier of the execution path report in the version record. At the same time, the metadata of the execution path report can also record which version references it. The new version of the graphical logic definition data file and the version record containing the association information are persistently stored in the database or version repository.

[0106] Specifically, the concept of version control is elevated from managing code differences to a higher dimension of managing change-cause relationships. Simply recording changes to the code itself is not enough; more importantly, it is necessary to record the decision-making basis and context behind each change. This overcomes the limitations of traditional version control systems, which only record who modified what and when, but cannot answer the crucial question of why the modification was made. It sets a new standard for the traceability and auditability of projects, outputting a graphical logical definition of the saved new version and a version record closely associated with it, containing the decision-making basis.

[0107] S6.4 Mark the new version of the graphical logic definition in the version record as being based on the modification of the previous version of the graphical logic definition, thus completing the version management of the graphical logic definition.

[0108] Furthermore, when creating a version record for a new version of the graphical logic definition, a crucial operation is performed: a unique identifier for the direct predecessor version is explicitly recorded in the version record, establishing a directed link from the new version to the old version. For example, when a new version of the graphical logic definition with version number V2.0 is saved, the corresponding version record will contain a version-based field, and the value of the field will be set to V1.0. This marking operation is automatically performed every time a version is saved, ensuring that each version (except the initial version) accurately points to the source version it modified. All version records are interconnected through this pointer, forming a complete version chain or a version evolution tree.

[0109] Specifically, discrete version snapshots are organized into a continuous history with a clear direction of evolution. By recording parent-child relationships, a series of independent modifications are linked into a meaningful project evolution story. This overcomes the chaotic situation of traditional file backup methods that only retain multiple copies but cannot automatically sort out their modification order and dependencies. It provides a structured foundation for version backtracking, difference comparison and release management. Version management with graphical logical definitions is considered complete.

[0110] This embodiment also provides a low-code implementation system, including: a graphical logic definition module, which generates graphical logic definitions in response to user operations in a low-code project environment; The optimization module generates structural reconstruction suggestions for the graphical logic definition by quantitatively analyzing the topological connectivity density and module cohesion of the graphical logic definition. The logic parsing module compiles the graphical logic definition after integrating the refactoring suggestions into target executable code, and deploys the target executable code to the target PLC to form a running control logic instance; The debugging module extracts and visualizes the event dependencies and state transition sequences that lead to specific abnormal states by tracing back the runtime execution path of the control logic instance, and obtains an execution path report. The management module, based on the execution path report, allows for modification and version management of the graphical logic definition.

[0111] This embodiment also provides a computer device suitable for low-code implementation of the method, including: a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement the low-code implementation method proposed in the above embodiment.

[0112] The computer device can be a terminal, comprising a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, carrier networks, NFC (Near Field Communication), or other technologies. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device's casing, or an external keyboard, touchpad, or mouse.

[0113] This embodiment also provides a storage medium storing a computer program, which, when executed by a processor, implements the low-code implementation method proposed in the above embodiments. The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Red-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0114] In summary, this invention generates graphical logic definitions in a low-code environment by dragging and dropping components and connections. It then uses a specific weighted algorithm to quantify and analyze the topological connectivity density and module cohesion of these definitions. Based on thresholds validated by historical data, it proposes structural refactoring suggestions to encapsulate highly complex clusters into independent functional blocks. This optimizes the program architecture from the source before compilation, improving maintainability. After the optimized logic definitions are compiled and deployed to the PLC, the execution path is traced back to extract and visualize the event dependencies and state transition sequences that cause anomalies. This generates an execution path report that accurately pinpoints the root cause, allowing for precise modification and version management of the graphical logic definitions. This upgrades the low-code platform from a simple code generation tool into an intelligent integrated development and maintenance platform with forward-looking structural optimization and deep fault diagnosis capabilities, improving the development quality, operational efficiency, and lifecycle value of industrial automation software.

[0115] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A low-code implementation method, characterized in that: This includes generating graphical logic definitions in response to user actions in a low-code project environment; By quantitatively analyzing the topological connectivity density and module cohesion of the graphical logic definition, structural reconstruction suggestions are generated for the graphical logic definition. The graphical logic definition after integrating the refactoring suggestions is compiled to generate target executable code, and the target executable code is deployed to the target PLC to form a running control logic instance; By tracing back the runtime execution path of the control logic instance, the event dependencies and state transition sequences that lead to specific abnormal states are extracted and visualized to obtain an execution path report; Based on the execution path report, the graphical logic definition is modified and version managed.

2. The low-code implementation method as described in claim 1, characterized in that: In a low-code project environment, responding to user actions and generating graphical logic definitions involves the following steps: In a low-code project environment, respond to user drag-and-drop operations on components in the task management interface, generate a layout draft of the components and their initial positions, and configure the specific parameters of the input and output pins of each component. By connecting the output pins of the source component and the input pins of the target component, the data flow and control logic relationship between the components are defined; Integrate the set of components that define the data flow and control logic relationship, and add more complex logic units composed of functional blocks to complete the assembly of graphical logic definition; Save the assembled graphical logic definition in the task management interface to generate the graphical logic definition.

3. The low-code implementation method as described in claim 2, characterized in that: By quantitatively analyzing the topological connectivity density and module cohesion of the graphical logic definition, structural reconstruction suggestions are generated for the graphical logic definition, including the following steps: Based on the graphical logic definition, by traversing each node and weighting the sum of the quality of the connecting edges, suppressing according to the node depth, and taking the average of the local connectivity of all nodes, the specific value of the topological connectivity density is obtained. The specific numerical expression for the connectivity density of the topology is: ； in, This represents the specific value of the topological connectivity density. The total number of nodes. For node indexing, For nodes A connected edge, For nodes The set of all connected edges. The cross-penalty weighting coefficient is... Modular penalty weight coefficients, For nodes Input-output modular penalty factor; By calculating the core ratio of the number of internal connections to the total number of connections in a functional block, and then applying a weighted correction based on the boundary penalty term of the external connection ratio, the evaluation value of module cohesion is obtained. The expression for evaluating module cohesion is: ； in, This is the module cohesion evaluation value. This represents the number of connection edges between components within a function block. This represents the total number of all connecting edges in the function block. This represents the number of connection edges between the function block and external components. This is the boundary penalty coefficient; By combining the specific numerical values ​​of topological connectivity density and the evaluation values ​​of module cohesion, quantitative analysis is conducted to identify specific regions in the graphical logic definition where the topological structure is complex or the module cohesion is insufficient. Based on the correlation analysis of topology and maintenance cost in historical PLC low-code projects, combined with graph theory clustering coefficient inflection point verification and simulation stress test, the connectivity density threshold is obtained. Based on the quantitative analysis of the modularization criteria for industrial automation software, and combined with the correlation data of module cohesion and maintenance efficiency in historical projects, the module cohesion threshold is obtained. When a local component cluster has a topology connectivity density value greater than the connectivity density threshold and a module cohesion evaluation value less than the module cohesion threshold, it is extracted and encapsulated into an independent functional block to obtain a structural reconstruction suggestion.

4. The low-code implementation method as described in claim 3, characterized in that: The graphical logic definition, after integrating the refactoring suggestions, is compiled into the target executable code, including the following steps: The graphical logic definition after integration and refactoring suggestions is parsed and converted into a custom domain-specific language string to describe the control logic, forming an intermediate representation; The intermediate representation is transformed and abstracted into an abstract syntax tree. Static analysis is performed on the abstract syntax tree using an LLVM-based optimization strategy to obtain the optimized abstract syntax tree. The optimized abstract syntax tree is compiled into target executable code that can run in the Java Virtual Machine.

5. The low-code implementation method as described in claim 4, characterized in that: Deploying the target executable code to the target PLC to form a running control logic instance includes the following steps: A physical communication connection with the target PLC is established through the data integration layer; The target executable code is completely transmitted to the target PLC's memory storage area through the established communication connection; The target executable code transferred to the target PLC memory is configured before execution. A start command is sent to the target PLC, which then loads and executes the configured target executable code. The target PLC begins to execute the target executable code in a loop, forming a running control logic instance.

6. The low-code implementation method as described in claim 5, characterized in that: By tracing back the runtime execution path of the control logic instance, the event dependencies and state transition sequences leading to specific abnormal states are extracted and visualized to obtain an execution path report, including the following steps: Monitor the variable values ​​and logic branch execution of running control logic instances, and detect when a running control logic instance triggers a specific abnormal state; When a specific abnormal state occurs, the complete runtime execution path of the control logic instance in operation is traced back within a fixed interval intercepted from the current moment; Extract the event dependencies that lead to specific abnormal states from the runtime execution path obtained through backtracking; Extract the state transition sequence of relevant variables from the runtime execution path obtained from backtracking, which leads to the occurrence of a specific abnormal state; An execution path report is generated based on the extracted event dependencies and state transition sequences.

7. The low-code implementation method as described in claim 6, characterized in that: Based on the execution path report, the graphical logic definition is modified and version managed, including the following steps: Analyze the execution path report to locate the functional block in the graphical logic definition that causes the specific abnormal state; Based on the issues identified in the execution path report, adjust the components already located in the graphical logic definition; Save the adjusted graphical logic definition as a new version graphical logic definition, create a version record for the saved new version graphical logic definition, and associate the version record with the execution path report on which it is based; The version history marks the new version of the graphical logic definition as being based on modifications to the previous version of the graphical logic definition, thus completing the version management of the graphical logic definition.

8. A low-code implementation system, based on the low-code implementation method according to any one of claims 1 to 7, characterized in that: This includes a graphical logic definition module, which generates graphical logic definitions in response to user actions in a low-code project environment; The optimization module generates structural reconstruction suggestions for the graphical logic definition by quantitatively analyzing the topological connectivity density and module cohesion of the graphical logic definition. The logic parsing module compiles the graphical logic definition after integrating the reconstruction suggestions into target executable code, and deploys the target executable code to the target PLC to form a running control logic instance; The debugging module extracts and visualizes the event dependencies and state transition sequences that lead to specific abnormal states by tracing back the runtime execution path of the control logic instance, and obtains an execution path report. The management module modifies and manages the version of the graphical logic definition based on the execution path report.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that: When the processor executes the computer program, it implements the steps of the low-code implementation method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, it implements the steps of the low-code implementation method according to any one of claims 1 to 7.

Images