Intelligent management system and method capable of arranging flow and rule for complex equipment
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- XIAN AEROSPACE SAINENG AUTOMATION TECH CO LTD
- Filing Date
- 2025-12-25
- Publication Date
- 2026-05-26
Smart Images

Figure CN122086393A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to a process management system and method, specifically to an intelligent management system and method for programmable processes and rules for complex equipment. Background Technology
[0002] Process control and data simulation for complex equipment (such as automated equipment and complex aircraft involving process orchestration) is a typical high-complexity, high-reliability systems engineering project involving the parallel execution of multiple subsystems. Currently, the process control and data simulation systems commonly used in this field are mostly based on rigid, fixed design patterns, which have significant limitations in adaptability, maintenance efficiency, and reusability, mainly in the following aspects: 1) Rigid processes and insufficient flexibility: Existing systems typically embed test processes and data simulation logic into the program in a hard-coded form. Once test requirements change or processes need to be adjusted, the source code must be modified, resulting in low code reusability, heavy maintenance workload, and difficulty in adapting to rapidly iterating test scenarios.
[0003] 2) Overly high coupling between business rules and execution logic: In traditional systems, business rules such as data simulation and equipment control are tightly coupled with the underlying process execution logic. When business rules change, developers often need to delve into the code layer to make modifications, resulting in cumbersome system maintenance, long upgrade and iteration cycles, and difficulty in responding to flexible and ever-changing business needs.
[0004] 3) Lack of visual orchestration and management tools: Existing systems are mostly "black boxes" for users, who cannot intuitively perceive the full picture of the process, nor can they visually orchestrate, simulate, and optimize the process structure according to actual needs. The management, maintenance, and optimization of the process heavily rely on the development team, resulting in low efficiency for users to adjust and change the process.
[0005] 4) Poor system reusability: Most existing systems are custom-developed for specific equipment models, with process logic and business rules fixed in the code, making them difficult to port and reuse across different models or platforms. This results in a large amount of repetitive development work, high R&D costs, and hinders the accumulation and sharing of testing assets and professional knowledge.
[0006] In summary, existing technologies suffer from common problems such as rigid processes, high coupling, poor visibility, and difficulty in reuse. Therefore, there is an urgent need in this field for a technical solution that can decouple process control logic from data simulation rules from the code, supporting flexible, visual, dynamic orchestration, and centralized management to improve system adaptability, maintenance efficiency, and asset reuse capabilities. Summary of the Invention
[0007] The purpose of this invention is to solve the problems of rigid management systems, high maintenance costs, and poor reusability caused by the high coupling between process control and business rules, fixed coding, and lack of visual orchestration methods in existing management systems. In order to provide an intelligent management system and method for the orchestration of processes and rules for complex equipment.
[0008] To achieve the above objectives, the technical solution provided by this invention is: A programmable intelligent management system for processes and rules in complex equipment, characterized by: It includes core service components that connect to upper-layer systems and complex device clusters, database components that connect to the core service components, and service middleware for internal communication within the core service components; the complex device cluster includes several complex devices; The core service components include a process model library module, a process engine module connected to the process model library module, a rule engine module connected to the process engine module, and a rule model library module connected to the rule engine module. The process model library module provides a graphical process orchestration interface for users to create and edit process trees that represent task processes. The process tree is a tree structure, including several nodes, each of which is associated with at least one rule model and can be configured with breakpoint attributes. The rule model library module is used to provide a graphical rule orchestration interface for users to predefine rule models associated with the nodes of the process tree; The process engine module is connected to the upper-level system and is used to receive tasks issued by the upper-level system, load the process tree required to execute the task from the process model library module, drive the nodes of the process tree to execute in sequence, and provide breakpoint debugging means. The rule engine module is connected to the upper-layer system and the complex equipment cluster respectively. When the process engine module executes a node of the process tree, it generates corresponding simulation data or control instructions in real time according to the rule model associated with the corresponding node in the rule model library module and sends them to the complex equipment cluster. At the same time, it feeds back the data returned by the complex equipment cluster to the upper-layer system. The database component includes a relational database connected to the process model library module and the rule model library module, respectively, and an in-memory database connected to the process engine module and the rule engine module, respectively. The relational database is used to persistently store the process tree, rule model, the relationship between the process tree and the rule model, and general system configuration data. The in-memory database is used for high-speed access to real-time status information, context data, and breakpoint information during the execution process. The service middleware component is a shared message middleware. The process model library module and the process engine module, the process engine module and the rule engine module, and the rule engine module and the rule model library module are connected through the same message middleware. The message middleware is used for data communication between modules to achieve decoupling of the process model library module, the process engine module, the rule engine module, and the rule model library module.
[0009] Furthermore, the service middleware component also includes a stream processing middleware connected to the rules engine module; The rule engine module includes an instruction generation unit connected to the process engine module and the rule model library module respectively, and a data simulation service unit that communicates with a complex equipment cluster. The stream processing middleware is connected to the instruction generation unit and the data simulation service unit respectively. It is used to buffer, organize and sort the high-throughput data instruction stream generated by the instruction generation unit to form an ordered queue data, and transmit the ordered queue data to the data simulation service unit. The data simulation service unit is used to generate corresponding simulation data or control instructions based on the ordered queue data and send them to the complex device cluster, and feed back the data returned by the complex device cluster to the upper layer system.
[0010] Furthermore, the relational database is DM database, and the in-memory database is Redis database.
[0011] Furthermore, the stream processing middleware is Kafka middleware, and the message middleware is EMQX middleware.
[0012] Furthermore, the rule model includes at least one of the following: threshold simulation model, delay processing model, fixed parameter model, button control model, device control model, and data import model; The threshold simulation model is used to dynamically generate data within a preset minimum and maximum value range; The delay processing model is used to delay the execution of process nodes according to a preset duration; The fixed parameter model is used to output one or more preset fixed values; The button control model is used to pause execution at process nodes and wait for external interface operation instructions; The device control model is used to generate operation instructions that directly drive the complex device cluster. The data import model is used to push predefined batch data sequentially.
[0013] Meanwhile, this invention also provides a programmable intelligent management method for processes and rules of complex equipment. Its unique feature is that, based on the aforementioned programmable intelligent management system for processes and rules of complex equipment, it includes the following steps: Step 1: Create and edit the process tree representing the task flow, and predefine the rule models associated with the nodes of the process tree: Step 1.1: Use the graphical process orchestration interface provided by the process model library module to create and edit the process tree that represents the task process, and persist the process tree to a relational database. Step 1.2: Use the rule model library module to provide a graphical rule orchestration interface, predefine the rule models associated with the nodes of the process tree, and persistently store the rule models in a relational database; Step 1.3: Configure the association between the nodes in the process tree and the corresponding rule model to obtain the association relationship between the process tree and the rule model, and persist the association relationship to a relational database; Step 2: The upper-level system sends a task to the process engine module. The process engine module loads the process tree required to execute the task from the process model library module, drives the execution of the nodes of the process tree in sequence, and provides breakpoint debugging methods; at the same time, it synchronizes the real-time status to the in-memory database. Step 3: When the process engine module reaches a node associated with a rule model, it sends a trigger command to the rule engine module through a message middleware. The rule engine module reads the associated rule model from the rule model library module according to the trigger command, generates the corresponding simulation data or device control command, and synchronizes the real-time status to the memory database. Step 4: The rule engine module sends the generated simulation data or device control commands to the complex device cluster, and at the same time receives the feedback data returned by the complex device cluster and sends the feedback data back to the upper layer system.
[0014] Furthermore, in step 2, the breakpoint debugging specifically involves: S1. After the process engine module finishes executing the business of the current node, the process pointer automatically advances to the next node to be executed and verifies the breakpoint attribute of that node. S2. Determine if a breakpoint is configured for this node: If no breakpoint is configured for the node, the business logic of that node will be executed, and the process will return to step S1 to continue. If a breakpoint has been configured on the node, the process execution is paused, the current full process state is saved to the memory database, and the user is waited for manual input of debugging commands. S3. User inputs debugging commands: When the user inputs a command to continue execution, the system enters automatic execution mode, executes the business logic of the node currently pointed to by the pointer, and then returns to step S1. When the user enters the next instruction, the business logic of the node currently pointed to by the pointer is executed. Then the process is paused again and returns to step S2, where the user is waiting to manually enter debugging instructions. When the user enters the previous instruction, the process pointer shifts forward by one position, and then the process pauses again and returns to the step S2 where the user is waiting to manually enter debugging instructions. When the user inputs the instruction to skip this step, the process pointer shifts one position forward, and the business logic of the currently skipped node is not executed. The process then pauses again and returns to step S2, where the user is waiting for manual input of debugging instructions.
[0015] Compared with the prior art, the beneficial effects of the present invention are: 1. The intelligent management system for programmable processes and rules for complex equipment provided by this invention achieves a complete separation of business logic, process logic, and execution logic by constructing the process model library, process engine, rule model library, and rule engine as decoupled independent service modules and using a message middleware based on a publish / subscribe pattern for communication. This three-layer decoupled architecture of "process-rule-execution" ensures that modifications, upgrades, or extensions of any service do not affect other services, greatly improving the maintainability, scalability, and overall stability of the system, and effectively avoiding the drawbacks of traditional tightly coupled systems where "changing one part affects the whole".
[0016] 2. The intelligent management system for programmable processes and rules for complex equipment provided by this invention offers independent graphical process orchestration and rule orchestration interfaces, allowing users to freely design process trees and predefine diverse rule models through visual drag-and-drop functionality. This design transforms the development model of complex equipment testing and control processes from a "code development" model that relies on developers writing and modifying source code to a "business orchestration" model led by domain experts, significantly lowering the technical threshold, shortening the cycle of process construction and changes, and enabling agile response to business needs.
[0017] 3. The intelligent management system for programmable processes and rules for complex equipment provided by this invention has a process engine module with built-in complete process-level breakpoint debugging functions (including continue execution, next step, previous step, skip this step, etc.). This function allows users to pause at any node during process execution and finely control the execution steps of the business process as if debugging software code, realizing transparent and controllable observation and intervention of the entire process of testing complex equipment. This fundamentally solves the problems of difficult debugging and inability to intervene in real time in traditional black-box testing systems, and greatly improves the accuracy and efficiency of testing and verification.
[0018] 4. The intelligent management method for programmable processes and rules for complex equipment provided by this invention realizes full lifecycle digital management of testing tasks for complex equipment by linking process modeling, rule definition, association configuration, debuggable execution and intelligent simulation into an end-to-end closed loop process; this method precipitates volatile business knowledge into standardized process model and rule model assets, supports rapid reuse, reorganization and iteration of tasks, thereby reducing redundant development and lowering the full lifecycle cost of the project.
[0019] 5. The programmable intelligent management method for processes and rules of complex equipment provided by this invention replaces the traditional fixed data injection mode by introducing a rule engine to perform dynamic data simulation and equipment control based on standardized rule models (such as threshold simulation, delay processing, etc.). This method enables the testing process to more intelligently simulate the uncertainty and dynamism of the real world, significantly enhancing the coverage of test scenarios and the reliability of system verification, and providing core support for intelligent testing and decision-making of complex equipment. Attached Figure Description
[0020] Figure 1 This is a schematic diagram of an embodiment of the intelligent management system for programmable processes and rules for complex equipment according to the present invention. Figure 2 This is a detailed flowchart of step 2, interruption point debugging, in an embodiment of the intelligent management method for programmable processes and rules for complex equipment of the present invention. Figure 3 This is a detailed schematic diagram of the rule engine module in an embodiment of the intelligent management system for programmable processes and rules for complex devices according to the present invention. Detailed Implementation
[0021] The present invention will be further described below with reference to the accompanying drawings and specific embodiments.
[0022] A programmable intelligent management system for processes and rules in complex devices adopts a three-layer decoupled architecture of "process-rule-execution" based on microservices. (See also...) Figure 1 and Figure 3 It includes core service components that connect to the upper-layer system and complex device clusters, database components that connect to the core service components, and service middleware for internal communication within the core service components; the complex device cluster includes several complex devices; The core service components include a process model library module, a process engine module connected to the process model library module, a rules engine module connected to the process engine module, and a rules model library module connected to the rules engine module. The process model library module provides a graphical process orchestration interface for users to create and edit process trees that represent task processes. The process tree is a tree structure, including several nodes, each of which is associated with at least one rule model and can be configured with breakpoint attributes. The rule model library module provides a graphical rule orchestration interface for users to predefine rule models associated with nodes in the process tree; The process engine module connects to the upper-level system to receive tasks issued by the upper-level system, loads the process tree required to execute the task from the process model library module, drives the nodes of the process tree to execute in sequence, and provides breakpoint debugging methods. The rule engine module connects to both the upper-layer system and the complex equipment cluster. When the process engine module executes a node in the process tree, it generates corresponding simulation data or control commands in real time based on the rule models associated with the corresponding nodes in the rule model library module and sends them to the complex equipment cluster. At the same time, it feeds back the data returned by the complex equipment cluster to the upper-layer system. The rule engine module includes a command generation unit that connects to both the process engine module and the rule model library module, as well as a data simulation service unit that communicates with the complex equipment cluster. The database component includes a relational database connected to the process model library module and the rule model library module, respectively, and an in-memory database connected to the process engine module and the rule engine module, respectively. The relational database is used to persistently store the process tree, rule model, the relationship between the process tree and the rule model, and the general system configuration data. The in-memory database is used for high-speed access to real-time status information, context data, and breakpoint information during the execution process. The service middleware components include message middleware and stream processing middleware connected to the rule engine module. The process model library module and the process engine module are connected through message middleware; the process engine module and the rule engine module are connected through message middleware; the rule engine module and the rule model library module are connected through message middleware; the message middleware is used for data communication between modules, realizing the decoupling of the process model library module, the process engine module, the rule engine module, and the rule model library module.
[0023] The stream processing middleware is connected to the instruction generation unit and the data simulation service unit respectively. It is used to buffer, organize and sort the high-throughput data instruction stream generated by the instruction generation unit to form an ordered queue of data, and transmit the ordered queue of data to the data simulation service unit. The data simulation service unit is used to generate corresponding simulation data or control instructions based on the ordered queue of data and send them to the complex device cluster, and feed back the data returned by the complex device cluster to the upper layer system.
[0024] In this embodiment, the relational database is DM Database, and the in-memory database is Redis Database. The stream processing middleware is Kafka Middleware, and the message middleware is EMQX Middleware (based on the MQTT (Message Queuing Telemetry Transport) protocol). The advantage of this design is that when a user modifies the process tree through the process model library module, they only need to publish the updated model to a specific message topic. The process engine module subscribing to that topic can asynchronously obtain the latest version, while the rule engine module remains completely unaffected. Conversely, changes to business rules are limited to the rule model library module and the rule engine module. This decoupled design completely solves the "one change affects the whole" problem in the background technology, making system maintenance, upgrades, and horizontal scaling extremely flexible. A failure in a single service will not paralyze the entire system. The presence of the Kafka middleware allows the data simulation service unit to consume data from the Kafka queue at a controllable rate and distribute it to the device cluster. This design effectively smooths out peaks and valleys, preventing instantaneous data surges from overwhelming the system or blocking critical control command channels, ensuring system stability and real-time performance.
[0025] The rule model includes at least one of the following: threshold simulation model, delay processing model, fixed parameter model, button control model, device control model, and data import model. The threshold simulation model is used to dynamically generate data within a preset minimum and maximum value range. The delay processing model is used to delay the execution of process nodes according to a preset duration. The fixed parameter model is used to output one or more preset fixed values. The button control model is used to pause execution at process nodes and wait for external interface operation instructions. The device control model is used to generate operation instructions that directly drive complex device clusters. The data import model is used to push predefined batch data in sequence.
[0026] Furthermore, this embodiment also provides a programmable intelligent management method for complex equipment, which includes the following steps based on the aforementioned programmable intelligent management system for complex equipment. Step 1: Create and edit the process tree representing the task flow, and predefine the rule models associated with the nodes of the process tree: Step 1.1: Use the graphical process orchestration interface provided by the process model library module to create and edit the process tree that represents the task process, and persist the process tree to a relational database. Step 1.2: Use the rule model library module to provide a graphical rule orchestration interface, predefine the rule models associated with the nodes of the process tree, and persist the rule models to a relational database; Step 1.3: Configure the association between the nodes in the process tree and the corresponding rule model to obtain the association relationship between the process tree and the rule model, and persist the association relationship to a relational database; Step 2: The upper-level system sends a task to the process engine module. The process engine module loads the process tree required to execute the task from the process model library module, drives the execution of the nodes of the process tree in sequence, and provides breakpoint debugging methods; at the same time, it synchronizes the real-time status to the in-memory database. See Figure 2 Breakpoint debugging specifically involves: S1. After the process engine module finishes executing the business of the current node, the process pointer automatically advances to the next node to be executed and verifies the breakpoint attribute of that node. S2. Determine if a breakpoint is configured for this node: If no breakpoint is configured for the node, the business logic of that node will be executed, and the process will return to step S1 to continue. If a breakpoint has been configured on the node, the process execution is paused, the current full process state is saved to the memory database, and the user is waited for manual input of debugging commands. S3. User inputs debugging commands: When the user inputs a command to continue execution, the system enters automatic execution mode, executes the business logic of the node currently pointed to by the pointer, and then returns to step S1. When the user enters the next instruction, the business logic of the node currently pointed to by the pointer is executed. Then the process is paused again and returns to step S2, where the user is waiting to manually enter debugging instructions. When the user enters the previous instruction, the process pointer shifts forward by one position, and then the process pauses again and returns to the step S2 where the user is waiting to manually enter debugging instructions. When the user inputs the instruction to skip this step, the process pointer shifts one position forward, and the business logic of the currently skipped node is not executed. The process then pauses again and returns to step S2, where the user is waiting for manual input of debugging instructions.
[0027] The working principle of the "breakpoint debugging method" is explained in detail below: The workflow engine module internally maintains a workflow queue pointer to indicate the current execution position. Its execution process is a loop: execute the current node's business logic -> the pointer points to the next node to be executed -> check the breakpoint attribute of that node. The key to this design is that breakpoint determination occurs before, rather than after, the execution of a node.
[0028] If the breakpoint attribute is false, the engine will directly execute the rule associated with that node and continue the loop.
[0029] If the breakpoint attribute is true, the engine immediately interrupts the automatic loop, saving the current flow pointer position, all variable states, context data, and other complete state to an in-memory database (such as Redis) serving as a "real-time state board," and then enters a waiting state. Different debugging commands issued by the user in this waiting state will drive the engine to enter different execution modes: Continue execution: The engine enters automatic execution mode. After executing the current node, the pointer automatically advances and executes subsequent nodes. However, this "automatic" execution does not ignore breakpoints; its core logic is to restore the initial loop judgment process. Therefore, when the pointer encounters a node with a breakpoint attribute that is true again, it will trigger a pause again.
[0030] Next step / Previous step / Skip instruction: The engine enters single-step execution mode. Each time such an instruction is received, the engine performs only one atomic operation (execute one step, backtrack the pointer one step, or skip one step), and then forcibly returns to the waiting state, achieving precise control of the stepping. During this process, the current state is constantly synchronized in real-time with the in-memory database, ensuring state traceability and recovery.
[0031] This mechanism introduces advanced software debugging concepts into the field of physical process control, enabling testers to trace, inspect, and intervene in the testing process of complex equipment line by line, just like debugging code, greatly improving the efficiency of verification, troubleshooting, and optimization of complex systems.
[0032] The system's workflow forms a complete closed loop: users can orchestrate and associate processes and rules in the design phase through a visual interface, and persist the data; after a task is started, the system enters the running phase, where the process engine drives the process and can be precisely debugged and controlled by the user; the rule engine intelligently generates data or instructions on demand, interacts with the real device cluster, and provides real-time feedback on the results. Throughout this process, the decoupled architecture, the cooperation of the two databases, and the division of labor among middleware components jointly support the system's high flexibility, high reliability, and high intelligence.
Claims
1. A programmable intelligent management system for complex equipment, characterized in that: It includes core service components that connect to upper-layer systems and complex device clusters, database components that connect to the core service components, and service middleware for internal communication within the core service components; the complex device cluster includes several complex devices; The core service components include a process model library module, a process engine module connected to the process model library module, a rule engine module connected to the process engine module, and a rule model library module connected to the rule engine module. The process model library module provides a graphical process orchestration interface for users to create and edit process trees that represent task processes. The process tree is a tree structure, including several nodes, each of which is associated with at least one rule model and can be configured with breakpoint attributes. The rule model library module is used to provide a graphical rule orchestration interface for users to predefine rule models associated with the nodes of the process tree; The process engine module is connected to the upper-level system and is used to receive tasks issued by the upper-level system, load the process tree required to execute the task from the process model library module, drive the nodes of the process tree to execute in sequence, and provide breakpoint debugging means. The rule engine module is connected to the upper-layer system and the complex equipment cluster respectively. When the process engine module executes a node of the process tree, it generates corresponding simulation data or control instructions in real time according to the rule model associated with the corresponding node in the rule model library module and sends them to the complex equipment cluster. At the same time, it feeds back the data returned by the complex equipment cluster to the upper-layer system. The database component includes a relational database connected to the process model library module and the rule model library module, respectively, and an in-memory database connected to the process engine module and the rule engine module, respectively. The relational database is used to persistently store the process tree, rule model, the relationship between the process tree and the rule model, and general system configuration data. The in-memory database is used for high-speed access to real-time status information, context data, and breakpoint information during the execution process. The process model library module and the process engine module, the process engine module and the rule engine module, and the rule engine module and the rule model library module are connected through the same message middleware; the message middleware is used for data communication between modules to achieve decoupling of the process model library module, the process engine module, the rule engine module, and the rule model library module.
2. The intelligent management system for programmable processes and rules for complex equipment as described in claim 1, characterized in that: The service middleware component also includes a stream processing middleware connected to the rule engine module; The rule engine module includes an instruction generation unit connected to the process engine module and the rule model library module respectively, and a data simulation service unit that communicates with a complex equipment cluster. The stream processing middleware is connected to the instruction generation unit and the data simulation service unit respectively. It is used to buffer, organize and sort the high-throughput data instruction stream generated by the instruction generation unit to form an ordered queue data, and transmit the ordered queue data to the data simulation service unit. The data simulation service unit is used to generate corresponding simulation data or control instructions based on the ordered queue data and send them to the complex device cluster, and feed back the data returned by the complex device cluster to the upper layer system.
3. The intelligent management system for programmable processes and rules for complex equipment according to claim 2, characterized in that: The relational database is DM Database, and the in-memory database is Redis Database.
4. The intelligent management system for programmable processes and rules for complex equipment according to claim 3, characterized in that: The stream processing middleware is Kafka middleware, and the message middleware is EMQX middleware.
5. The intelligent management system for programmable processes and rules for complex equipment according to claim 4, characterized in that: The rule model includes at least one of the following: threshold simulation model, delay processing model, fixed parameter model, button control model, device control model, and data import model; The threshold simulation model is used to dynamically generate data within a preset minimum and maximum value range; The delay processing model is used to delay the execution of process nodes according to a preset duration; The fixed parameter model is used to output one or more preset fixed values; The button control model is used to pause execution at process nodes and wait for external interface operation instructions; The device control model is used to generate operation instructions that directly drive the complex device cluster. The data import model is used to push predefined batch data sequentially.
6. A method for intelligent management of processes and rules that can be programmed for complex equipment, characterized in that, The process and rule-programmable intelligent management system for complex devices, based on any one of claims 1 to 5, includes the following steps: Step 1: Create and edit the process tree representing the task flow, and predefine the rule models associated with the nodes of the process tree: Step 1.1: Use the graphical process orchestration interface provided by the process model library module to create and edit the process tree that represents the task process, and persist the process tree to a relational database. Step 1.2: Use the rule model library module to provide a graphical rule orchestration interface, predefine the rule models associated with the nodes of the process tree, and persistently store the rule models in a relational database; Step 1.3: Configure the association between the nodes in the process tree and the corresponding rule model to obtain the association relationship between the process tree and the rule model, and persist the association relationship to a relational database; Step 2: The upper-level system sends a task to the process engine module. The process engine module loads the process tree required to execute the task from the process model library module, drives the execution of the nodes of the process tree in sequence, and provides breakpoint debugging methods; at the same time, it synchronizes the real-time status to the in-memory database. Step 3: When the process engine module reaches a node associated with a rule model, it sends a trigger command to the rule engine module through a message middleware. The rule engine module reads the associated rule model from the rule model library module according to the trigger command, generates the corresponding simulation data or device control command, and synchronizes the real-time status to the memory database. Step 4: The rule engine module sends the generated simulation data or device control commands to the complex device cluster, and at the same time receives the feedback data returned by the complex device cluster and sends the feedback data back to the upper layer system.
7. The intelligent management method for programmable processes and rules for complex equipment according to claim 6, characterized in that: In step 2, the breakpoint debugging specifically involves: S1. After the process engine module finishes executing the business of the current node, the process pointer automatically advances to the next node to be executed and verifies the breakpoint attribute of that node. S2. Determine if a breakpoint is configured for this node: If no breakpoint is configured for the node, the business logic of that node will be executed, and the process will return to step S1 to continue. If a breakpoint has been configured on the node, the process execution is paused, the current full process state is saved to the memory database, and the user is waited for manual input of debugging commands. S3. User inputs debugging commands: When the user inputs a command to continue execution, the system enters automatic execution mode, executes the business logic of the node currently pointed to by the pointer, and then returns to step S1. When the user enters the next instruction, the business logic of the node currently pointed to by the pointer is executed. Then the process is paused again and returns to step S2, where the user is waiting to manually enter debugging instructions. When the user enters the previous instruction, the process pointer shifts forward by one position, and then the process pauses again and returns to the step S2 where the user is waiting to manually enter debugging instructions. When the user inputs the instruction to skip this step, the process pointer shifts one position forward, and the business logic of the currently skipped node is not executed. The process then pauses again and returns to step 2, where the user is waiting to manually input debugging instructions.