A method, system, equipment, and medium for coordinated operation of a hierarchical control system

Abstract

This invention discloses a method, system, device, and medium for the coordinated operation of a hierarchical control system, relating to the field of industrial control technology. The method decomposes the control tasks of an intermediate controller into sub-tasks and constructs control modules with independent interfaces, which communicate with each other via an event bus. A master control state machine is maintained within the intermediate controller, receiving instructions from the upper layer and sending asynchronous start events. Upon receiving an asynchronous start event, the control module detaches from synchronous dependencies and executes its logic driven by internal events, generating key node state events to drive module collaboration. The master control state machine aggregates key node state events into a macroscopic state and reports it to the upper layer. This invention simplifies the state space, addresses granularity mismatch issues, constructs a decoupled modular architecture, and improves the system's maintainability, robustness, and debugging efficiency.

Description

Technical Field

[0001] This invention relates to the field of industrial control technology, specifically to a method, system, device, and medium for the coordinated operation of a hierarchical control system. Background Technology

[0002] In the control of subsystems of large and complex engineering systems, such as the International Thermonuclear Experimental Reactor (ITER), a hierarchical state machine architecture is commonly used in the industry to achieve coordinated operation of the system. The upper-level state machine (such as the central control system) is responsible for switching macroscopic operating modes, while the lower-level subsystem state machines are responsible for receiving instructions and controlling specific equipment to execute complex internal processes.

[0003] The design logic of the state machine of the lower-level subsystem is usually based on defining the states according to the "complete workflow" it needs to complete. Designers need to enumerate all possible stable configurations of the system as states and specify the transition conditions between states. However, in systems with a large number of devices and high process complexity, this design approach has the following drawbacks:

[0004] 1. The problems of state explosion and logical coupling are prominent: the number of system states increases exponentially with the number of devices and process complexity, resulting in an extremely complex state transition diagram. All device control and process logic are deeply coupled in a single state machine. Any local modification requires re-examining and verifying the entire state machine, resulting in extremely high maintenance and expansion costs.

[0005] 2. Rigid instruction response and prone to process interruption: The upper-level state machine only issues coarse-grained instructions representing macroscopic stage transitions (such as "start experiment"). After responding to such instructions, traditional state machines can usually only execute the operation steps directly corresponding to the instruction. Subsequent continuous fine-grained internal operations without the support of upper-level instructions cannot proceed automatically, leading to control interruption. To solve this problem, waiting loops or sub-state machines are added to the state machine, which further exacerbates state explosion and logical chaos.

[0006] 3. Mismatch in granularity of status reporting: When lower-level subsystems report their status to the upper level, either the reporting of all statuses leads to excessively frequent communication and includes a large number of irrelevant intermediate statuses, or the lack of summarization logic results in insufficient reported information. Neither of these issues can accurately reflect the macro-level stage of the subsystem, directly affecting upper-level coordination and decision-making.

[0007] Currently, there is a lack of a hierarchical control system design method that can naturally connect coarse-grained instructions with fine-grained processes, fundamentally simplify the state space, and achieve clear modularity. Summary of the Invention

[0008] This invention provides a method, system, device, and medium for the coordinated operation of a hierarchical control system. It aims to solve the technical problems of state space explosion, mismatch between upper and lower layer instruction / state granularity, and high system tight coupling caused by the use of a single state machine design based on a complete process in the lower layer of existing hierarchical control systems. It enables the lower-level subsystem to autonomously and continuously execute complex internal processes while synchronizing with the instructions of the upper layer, while reducing the number of core control logic states and decoupling functional modules.

[0009] This invention is achieved through the following technical solution:

[0010] A first aspect of the present invention provides a method for coordinated operation of a hierarchical control system, applied to an industrial control system, the industrial control system including a top-level controller, at least one intermediate controller, and an execution device controlled by the intermediate controller; the method includes:

[0011] The control task of the intermediate controller is decomposed into multiple sub-tasks, and a control module is built for each sub-task. Each control module includes an independent start-up interface, execution logic based on internal event-driven processes, and a key node status reporting interface. Multiple control modules communicate with each other through an event bus.

[0012] A master control state machine is maintained inside the intermediate controller. The master control state machine is configured to receive state transition instructions from the upper controller, update its own state according to the state transition instructions, and synchronously send asynchronous start events to one or more of the control modules according to the updated state.

[0013] After receiving the asynchronous start event, the control module breaks away from the synchronous dependency of the master control state machine and drives the execution logic based on internal events to control the execution device to complete the sub-task. When a critical node is reached, a critical node status event is generated and transmitted to other control modules through the event bus to drive other control modules to collaboratively complete the control task.

[0014] The master control state machine continuously monitors the key node state events, synthesizes the key node state events into a macro state according to predefined aggregation rules, and reports the macro state to the upper-layer controller.

[0015] Furthermore, the state set of the master control state machine corresponds to the state transition instruction set issued by the upper-level controller, so that the master control state machine retains only the minimum state set required for synchronization with the upper-level controller.

[0016] Furthermore, the internal events that drive the execution logic of the control module include internal timer timeout events, physical sensor feedback events, and key node status events from other control modules.

[0017] Furthermore, the predefined aggregation rules include: when multiple key node state events from different control modules simultaneously meet preset conditions, the master control state machine aggregates them into a macro state; when the multiple key node state events have logical conflicts, the master control state machine generates an abnormal state or alarm information.

[0018] Furthermore, the event bus provides an asynchronous communication channel for each control module, and the key node status events are transmitted between control modules through the event bus to form a cross-module event-driven chain.

[0019] Furthermore, a cross-module event-driven chain is pre-configured. This cross-module event-driven chain is defined and modified through a configuration file and is independent of the logic of the master control state machine.

[0020] Furthermore, after the control module is no longer dependent on the synchronization of the master control state machine, the execution logic of the module does not depend on the instructions of the master control state machine or the upper-level controller.

[0021] After generating critical node state events, the control module restores its synchronization dependency on the master control state machine.

[0022] A second aspect of the present invention provides a hierarchical control system, comprising:

[0023] The upper-level controller is used to issue state transition instructions;

[0024] At least one intermediate controller includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the coordinated operation method of the hierarchical control system according to any one of the first aspects of the present invention;

[0025] Multiple execution devices, controlled by the intermediate controller, are used to perform physical operations in response to control commands from the intermediate controller.

[0026] A third aspect of the present invention provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor, when executing the computer program, implements a coordinated operation method of a hierarchical control system as described in any one of the first aspects of the present invention.

[0027] A fourth aspect of the present invention provides 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 coordinated operation method of the hierarchical control system described in any one of the first aspects of the present invention.

[0028] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0029] This invention decomposes the complex control tasks of the intermediate controller into independent sub-tasks and constructs autonomous control modules. It separates the fine process logic that was originally coupled in a single state machine into each control module. The master control state machine only undertakes the core responsibilities of instruction reception, event triggering and state aggregation. It does not need to enumerate the states of all devices and processes, which greatly reduces the number of states and significantly reduces the difficulty of designing, verifying and maintaining the control logic.

[0030] For coarse-grained instructions from the upper layer, the main control state machine converts them into asynchronous start events that trigger the module to run. Without the upper layer issuing subsequent fine instructions, the control module can autonomously complete continuous sub-tasks and achieve coordination through events, thus realizing the efficient driving of fine processes by coarse-grained instructions.

[0031] Regarding status reporting, the master control state machine aggregates the status events of key nodes in each module to generate a macro-level status. This avoids frequent reporting of a large number of intermediate states and accurately reflects the overall operating stage of the subsystem, providing the upper-level controller with effective decision-making basis and achieving efficient matching of upper and lower-level status communication.

[0032] Each control module has an independent interface and execution logic, and asynchronous communication is achieved through an event bus. It has only a loose association with the master control state machine. Modification, replacement or addition of modules does not require modification of the master control state machine and other modules. Adding a new control task only requires building a new module and configuring the event communication relationship, which allows the system to quickly adapt to changes in business processes and greatly reduces the system's expansion and maintenance costs.

[0033] After receiving the start event, the control module breaks free from synchronous dependencies and completes subtasks by executing logic driven by internal events. It also drives other modules to run collaboratively through key node status events. The entire control process does not require continuous intervention from the master control state machine or upper layers, realizing automated progress from instruction triggering to process completion. This effectively solves the problem of easy process interruption in traditional control and improves the operating efficiency and autonomy of the hierarchical control system. Attached Figure Description

[0034] To more clearly illustrate the technical solutions of the exemplary embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of the present invention and should not be considered as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort. In the drawings:

[0035] Figure 1 This is a block diagram of the hierarchical control system architecture of the present invention;

[0036] Figure 2 This is a flowchart illustrating the coordinated operation of a hierarchical control system according to the present invention.

[0037] Figure 3 This is a design diagram of the master control state machine of a NAS system applying the method of this invention;

[0038] Figure 4 This is a flowchart illustrating a self-driven capsule transport module using the method of this invention. Detailed Implementation

[0039] To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the embodiments and accompanying drawings. The illustrative embodiments and descriptions of the present invention are only used to explain the present invention and are not intended to limit the present invention.

[0040] It should be noted that the terms "comprising" and "having" and any variations thereof in the specification, claims, and accompanying drawings of this invention are intended to cover non-exclusive inclusion, for example, a process, method, system, product, or device that includes a series of steps or units is not necessarily limited to other steps or units inherent in the device.

[0041] The terminology used in the various embodiments of the invention is for the purpose of describing particular embodiments only and is not intended to limit the various embodiments of the invention. As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. Unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which the various embodiments of the invention pertain. The terms (such as those defined in commonly used dictionaries) are to be interpreted as having the same meaning as in the context of the relevant technical field and are not to be interpreted as having an idealized or overly formal meaning, unless clearly defined in the various embodiments of the invention.

[0042] This invention proposes a method for the coordinated operation of a hierarchical control system, applicable to hierarchical control systems of large scientific facilities (such as fusion reactors and particle accelerators) or complex industrial systems. Specifically, this invention addresses how to efficiently, decouple, and reliably coordinate the upper-level coarse-grained operational mode commands with the lower-level subsystems containing numerous devices and having continuous and complex internal processes, proposing an innovative asynchronous event triggering and state aggregation mechanism.

[0043] In a typical industrial control scenario, the control system usually adopts a hierarchical architecture. A hierarchical control system includes a top-level controller, at least one intermediate controller, and one or more execution devices controlled by the intermediate controller. The top-level controller is responsible for global macro-level decisions, such as issuing coarse-grained commands like "start operation," "pause," and "enter maintenance mode" based on experimental progress or production plans. The intermediate controller is the core control device in the lower-level subsystem, directly interacting with specific execution devices such as valves, motors, and sensors. It is responsible for translating these macro-level commands into fine-grained control of the equipment. Together with the top-level controller and the execution devices, it constitutes a three-layer control architecture. The coordinated operation method in this embodiment is implemented at the intermediate controller level, aiming to optimize its internal control logic organization.

[0044] like Figure 1 The diagram shows the improved hierarchical control system of this invention, whose coordinated operation depends on the following two aspects.

[0045] (a) Decouple the control tasks of each intermediate controller.

[0046] Specifically, the overall control task of the intermediate controller is decomposed into multiple relatively independent sub-tasks, and a corresponding control module (sub-module A, sub-module B, sub-module C) is built for each sub-task.

[0047] Traditional design approaches construct the entire control task as a massive state machine, with the control logic and process sequence of all devices coupled together. This embodiment, however, decomposes the overall control task into multiple relatively independent sub-tasks based on the natural boundaries of the physical process and control independence. For example, in a system including material transfer, pressure control, and temperature regulation, separate material transfer control, pressure maintenance, and temperature regulation control modules can be constructed. Each control module is designed as an autonomous functional unit, and each module has three core interfaces:

[0048] (1) Independent startup interface: used to receive enable signals and start the workflow;

[0049] (2) Execution logic based on internal event-driven processes: This execution logic can proceed autonomously without relying on external continuous instructions;

[0050] (3) Critical Node Status Reporting Interface: Used to generate status events when the execution logic reaches a predefined critical milestone.

[0051] The control module independently receives the signal that enables it to start working through its startup interface. After startup, it controls the corresponding execution device to work based on its internal event-driven execution logic. When the module reaches a predefined key node such as "task completed", "ready" or "fault", it can generate the corresponding status event and report it to the main control state machine through the key node status report interface.

[0052] In addition, multiple control modules in each intermediate controller establish communication connections through an event bus, allowing modules to exchange event signals and achieve collaboration.

[0053] S2 builds and maintains a simplified master state machine within the intermediate controller.

[0054] The master state machine differs from traditional state machines, undertaking two core responsibilities: First, it receives state transition instructions from the upper-level controller / upper-level state machine. These instructions are typically coarse-grained macro-level instructions, such as "enter the ready state" or "start running." The master state machine updates its own state based on the received instructions and synchronously sends asynchronous start events to one or more control modules corresponding to the instructions. Second, it continuously monitors key node state events from various control modules and, according to predefined aggregation rules, combines these events into a macro-level state that characterizes the current macro-level stage of the intermediate controller. This macro-level state is then reported to the upper-level controller.

[0055] The master control state machine only sends enable signals to each control module, without waiting for or being aware of the specific execution process after the control module is triggered. Therefore, the state set of the master control state machine only needs to correspond to the set of instructions that can be issued by the upper-level controller and require macro-level synchronization by the lower-level subsystems.

[0056] The instruction interaction between the master state machine and the upper-level controller follows a preset mapping relationship. Specifically, the master state machine maintains an instruction-state mapping table, which defines the correspondence between each state transition instruction issued by the upper-level controller and the master state machine's own state, as well as which control module startup events should be triggered by that state. For example, when the master state machine receives a "start running" instruction, it updates its own state to "running" according to the mapping table and simultaneously sends asynchronous startup events to the control modules associated with that state. This ensures that a coarse-grained instruction from the upper level can be accurately decomposed into multiple parallel, independent module startup signals without including any specific execution step details in the instruction.

[0057] Aggregation rules are the basis for the master control state machine to combine key node state events reported by multiple control modules into a single macro-state. These rules can be logical combinations (such as AND, OR, NOT), timing conditions (such as the order in which events occur), or numerical thresholds (such as the progress percentage of multiple modules reaching a specific value). In actual systems, aggregation rules are usually stored in the intermediate controller in the form of configuration files, which can be flexibly adjusted by engineers according to process requirements. For example, for an automated production line, the aggregation rule might be defined as: when the "feeding module" reports "complete" and the "processing module" reports "idle," the aggregation state is "pending processing." Configurable aggregation rules enable the upper-level controller to grasp the macro-state of the lower-level subsystems in the simplest way, serving as the basis for upper-level decision-making.

[0058] The aggregated state is reported to the upper-level state machine periodically or based on events. Event-driven reporting means that when the aggregated state changes, the master state machine immediately reports the new state to the upper-level controller. This mode is suitable for scenarios requiring rapid response to state changes, such as safety-critical systems. Periodic reporting means that the master state machine reports the current aggregated state at fixed time intervals (e.g., every 100 milliseconds), regardless of whether the state has changed. This mode is suitable for scenarios where the upper-level controller needs to continuously monitor the system's health status. In a preferred implementation, both modes can coexist: critical state changes are reported immediately using event-driven reporting, while non-critical states or periodic heartbeat information are reported according to a preset period, thereby achieving a balance between real-time performance and communication load.

[0059] In practical applications, aggregation rules can be flexibly defined according to actual control requirements.

[0060] In a preferred embodiment, when multiple key node status events from different control modules simultaneously meet preset conditions, the master control state machine aggregates them into a single macro-level status report. For example, when the pressure maintenance module reports "pressure stable" and the capsule transfer module reports "transmission idle," the master control state machine can aggregate these two events into a "system ready" state and report it to the upper-level controller. Conversely, when multiple key node status events are logically conflicting, such as simultaneously receiving contradictory events like "complete" and "fault," the master control state machine can generate an abnormal state or alarm information and trigger safety interlock logic so that the upper-level controller can promptly be aware of and handle system anomalies.

[0061] Please combine Figure 2 As shown, the coordinated operation process of the hierarchical control system is as follows:

[0062] S101, Upper-level instruction issuance: The upper-level controller sends a state transition instruction, such as "start experiment", to the master state machine of the lower-level intermediate controller according to the experiment or production plan.

[0063] S102, Instruction parsing and status update: After receiving the instruction, the master control state machine updates its own status to "running" according to the internal mapping table, and synchronously sends asynchronous start events to one or more control modules associated with this status.

[0064] S103, Autonomous Operation of Control Module: After receiving the start event, the triggered control module immediately breaks away from the synchronization dependency of the master control state machine and enters the autonomous operation mode.

[0065] S104, Cross-module Event-Driven Chain: When a control module generates a critical node status event, the event is broadcast via the event bus or transmitted point-to-point to other relevant modules. In this way, a chain of events automatically drives the entire process forward, achieving a synergistic effect of "one event affecting the whole system".

[0066] S105, State Aggregation and Reporting: Throughout the entire process, the master control state machine continuously monitors the key node state events reported by all control modules. When certain event combinations are detected to meet predefined aggregation rules, the master control state machine dynamically synthesizes a new macro-state and reports it to the upper-level controller either through event-driven methods or periodically.

[0067] During this process, the upper-level controller does not need to concern itself with the specific operations of the lower-level controller; it only needs to make decisions for the next stage based on the reported macroscopic status.

[0068] The control module starts upon receiving an asynchronous start event via the start interface, entering autonomous operation mode. In this mode, the control module is completely independent of the master control state machine's synchronization dependency; its internal processes are driven by internal events. These internal events can be preset execution sequences, timeout events generated by internal timers, feedback events from physical sensors of the execution devices, or key node status events received from other control modules via the event bus. Internal timer timeout events handle scenarios requiring a fixed waiting time. Physical sensor feedback events respond to changes in the physical world, such as material arrival detection or pressure compliance detection. Key node status events from other control modules enable inter-module collaboration; for example, the completion of one control module serves as a driving signal for the autonomous operation of the next. These three event types essentially cover common process-driven scenarios in industrial control, enabling the control module to flexibly respond to various complex control requirements.

[0069] Through this event-driven mechanism, a control module can autonomously complete a series of sub-processes that may contain multiple steps. When a control module reaches a predefined critical node, it generates a critical node status event. For example, when it completes all its assigned tasks, it generates a "complete" event and broadcasts it via the event bus. These critical node status events are then passed to other control modules via the event bus, serving as internal events that drive their execution logic. This enables collaborative work among multiple control modules to jointly complete the entire control task.

[0070] Through the chaining of the aforementioned events, each control module can autonomously complete a continuous subprocess that may contain multiple steps without relying on any further instructions from the upper-level or master control state machine. During the operation of the entire control system, the upper-level controller only needs to issue macro-level instructions and receive macro-level states. The master control state machine is responsible for converting macro-level instructions into start events for each control module, monitoring the status of each control module, aggregating the data, and reporting it upwards. Each control module then collaborates with each other through the event bus, autonomously completing its own sub-tasks and driving the process automatically forward. The advancement of its internal process is entirely driven by preset sequential logic and internal events. This process fundamentally separates the complex process control logic from the master control state machine and distributes it to various functionally autonomous control modules, thereby achieving essential simplification of the state space and modular decoupling of the system.

[0071] Furthermore, after the control module detaches from its synchronous dependency on the master state machine, its execution logic operates entirely autonomously, without relying on further instructions from the master state machine or upper-level controllers. However, when the control module generates a critical node state event, it resumes its synchronous dependency on the master state machine. This critical node state event then becomes the input for the master state machine to perform state aggregation and decision-making. The control module follows a trigger-autonomy-report lifecycle: it is triggered when it receives a start event from the master state machine; after triggering, it enters autonomous operation; when it completes a subtask or encounters a fault, it generates a critical node state event, enabling the master state machine to perceive its state and use it for subsequent aggregation and decision-making.

[0072] The internal execution logic of the control module is designed as a finite state machine based on internal events, where state transitions are entirely triggered by internal events. These internal events include:

[0073] Preset sequence steps: The module will automatically proceed to the first step after startup, and automatically proceed to the next step after completion;

[0074] Timer timeout event: The module starts a timer, which automatically triggers the next step after the timeout.

[0075] Sensor feedback event: When the sensor detects that the value meets the standard, the next step is automatically triggered;

[0076] Events from other modules: Events received via the event bus can be directly used as start or step signals for this module.

[0077] Since each control module is an independent unit with clearly defined input and output interfaces, it only needs to receive an enable signal once at startup. After that, it autonomously advances based on internal logic and external events until it completes the entire sub-process and generates a final completion event. Therefore, the master control state machine only needs to send a start signal once to automatically run to the end without any intervention.

[0078] Furthermore, to achieve automatic connection of complete processes within the lower-level subsystems, a cross-module event-driven chain is pre-established between functionally autonomous control modules. A module's "complete" or "release" event can directly serve as an internal event source to trigger the next module to start or execute its next operation. Each control module exchanges key node status events based on the pre-established cross-module event-driven chain, continuing to drive the execution of subsequent sub-processes and ultimately collaboratively completing the control task.

[0079] The event bus provides an asynchronous communication channel for each control module. Critical node status events can be broadcast via the event bus, ensuring all monitoring control modules receive them. Point-to-point transmission is also possible, allowing events to be directed to specific control modules, supporting complex inter-module collaboration logic. By supporting both modes, the event bus can flexibly adapt to various inter-module communication needs.

[0080] Cross-module event-driven chains enable complex end-to-end processes to proceed automatically like dominoes, while the master state machine is only triggered once by upper-level instructions at the beginning of the process, and thereafter it no longer interferes with the internal operation of the process, but is only responsible for state aggregation and monitoring.

[0081] Cross-module event-driven chains can operate independently of the main control state machine's logic. In practical applications, cross-module event-driven chains can be defined and modified through configuration files, such as adding an event response relationship or adjusting the event propagation path, without altering the core code of the main control state machine. This decouples the execution logic from upper-level instructions, improving the system's scalability and maintainability.

[0082] In a preferred embodiment, to ensure the simplicity of the master state machine, the set of states in the master state machine is designed to correspond to the set of state transition instructions issued by the upper-level controller. That is, the master state machine retains only the minimum set of states necessary for macroscopic synchronization with the upper-level controller, without adding any additional intermediate states, thereby maximizing its simplicity. This allows the number of states in the master state machine to be significantly less than the number of states in a traditional state machine built based on a complete workflow.

[0083] For example, if the upper-level controller might issue three commands: "Stop," "Standby," and "Run," then the master control state machine will only set the three states corresponding to "Stop," "Standby," and "Run." When the master control state machine receives a state transition command from the upper-level controller, it first updates its own state according to the command, and then, based on the updated state, synchronously sends asynchronous start events to one or more control modules.

[0084] The following example, using the neutron activation system (NAS) in the ITER helium-cooled ceramic breeding blanket system (TBS), illustrates the specific application of the method of this invention. This example is for illustrative purposes only and does not constitute a limitation on the scope of protection.

[0085] The NAS system is a typical complex industrial control system, containing 42 devices. It needs to respond to four macro commands from the TBS layer and automatically complete the entire process of capsule loading, irradiation, cooling, measurement and disposal.

[0086] When applying the method of this invention, the control tasks of the NAS system are first functionally decoupled, decomposing them into four autonomous control modules: a pressure maintenance module, a capsule loading module, a capsule transfer module, and a measurement control module. Each module is responsible for a relatively independent sub-process and has an independent startup interface, internal event-driven execution logic, and a key node status reporting interface. The four modules are interconnected through an internal event bus.

[0087] Next, construct a simplified master state machine, such as... Figure 3 As shown, the master control state machine has only four states: Go To Stop, Go To Start, Go To Ready, and Go To Plasmastart, which correspond exactly to the four commands that the TBS layer may issue. The workflow of the master control state machine is as follows: When it receives the "Start" command from the TBS layer, it transitions to the "Ready" state and simultaneously sends an asynchronous start event to the pressure maintenance module; when it receives the "Go To Ready" command, it transitions to the "Go To Ready" state and sends an asynchronous start event to the capsule loading module; when it receives the "Plasma Discharge Start" command, it transitions to the "Go To Start" state and sends an asynchronous start event to the capsule transfer module, initiating the first capsule transfer to the irradiation station.

[0088] Simultaneously, state aggregation rules for the master control state machine are defined. For example, when the pressure maintenance module reports "pressure stable" and the capsule transfer module reports "system idle," the master control state machine aggregates these two events into a "ready" state and reports it to the TBS layer.

[0089] See Figure 4The self-driven process of the capsule transfer module shown. After receiving the start event sent by the main control state machine, the capsule transfer module immediately enters the autonomous operation mode. It first executes the transfer task from the loading station to the irradiation station. After placing at the irradiation station, an irradiation timer is started inside the module. When the irradiation timer times out, this internal event automatically triggers the module to execute the next task: transfer from the irradiation station to the cooling station. After arriving at the cooling station, a cooling timer is started. After the cooling timer times out, it automatically triggers the transfer from the cooling station to the measurement station. At the same time, the measurement control module is configured to listen for the cross-module event of "capsule arriving at the measurement station". Once this event is monitored, the measurement process is automatically started. And so on in a cycle until the capsule finally enters the waste station and the whole process ends.

[0090] During the whole process, except for the initial trigger and continuous state aggregation, the main control state machine no longer issues any control instructions. The complex linkage process of 42 devices is completely automatically completed by four autonomous modules through internal event driving and cross-module event chains. After applying the present invention, the core coordination logic of the NAS system is clearly expressed with only 4 states, perfectly docking with 4 upper-layer instructions, while the complex internal process is automatically advanced through module autonomy and event chains, greatly reducing the complexity of system design, debugging and maintenance.

[0091] In a preferred embodiment, to solve the problem that in a highly concurrent complex system, when multiple function autonomous control modules generate events simultaneously or there are circular dependencies in the event chain, resulting in overloading of the target module or state chaos, a further refined control mechanism is introduced into the event bus and the main control state machine.

[0092] In a high-concurrency scenario, when multiple control modules generate events simultaneously or there are circular dependencies in the event chain, some potential problems may be caused. For example, multiple modules broadcasting events simultaneously may lead to overloading of the target module or state chaos. Another example is that module A waits for the event of module B, module B waits for the event of module C, and module C waits for the event of module A, forming a circular wait, that is, deadlock. Another example is that when the main control state machine performs state aggregation, it may generate an incorrect aggregated state due to receiving conflicting events. To address these problems, in this embodiment, a process token mechanism is introduced into the cross-module event-driven chain to achieve conflict avoidance and deadlock prevention.

[0093] The specific method is as follows: When the master control state machine issues an asynchronous start event, it simultaneously generates a unique process token and attaches it to the event for transmission. This token is passed between control modules along the event chain. Only when a control module holds the token for the current process can it send control commands to the execution device. When a module completes its subprocess and generates a critical node state event, it passes the token along with that critical node state event to the next control module. If the token is not passed within a predetermined time, for example, if a module malfunctions and causes the process to be interrupted, the master control state machine will trigger a timeout protection mechanism, reclaim the token, and reset the relevant module.

[0094] This mechanism fundamentally eliminates the problem of multiple modules vying for control of the device simultaneously, and through the token timeout mechanism, it can quickly locate the node where the process is interrupted, thus enhancing the robustness and debuggability of the system.

[0095] Furthermore, a conflict resolution engine is added to the macroscopic state aggregation step of the master control state machine. First, a mutual exclusion state table is defined in the system to clearly identify which states cannot coexist. For example, in a nuclear fusion experiment scenario, "irradiation in progress" and "maintenance door open" are mutually exclusive. When the master control state machine detects critical node state events from different modules, the conflict resolution engine compares these events with the mutual exclusion state table. If it finds that the reported event combination violates predefined safety rules, the master control state machine does not perform the usual aggregation and reporting, but directly generates an alarm state and prioritizes the execution of safety interlock logic, forcibly suspending all related modules. This mechanism solves the problem that simple state aggregation may mask underlying conflicts, elevating safety monitoring to the logical level, rather than just data aggregation.

[0096] Compared with the prior art, the present invention has the following significant technical advancements:

[0097] 1. Achieved essential simplification of the state space: By stripping complex sequential logic from the state machine to autonomous modules, the master state machine retains only the minimum set of states necessary for synchronization with the upper layer (usually 3-10), fundamentally eliminating the state explosion problem and making the top-level design of the system extremely clear.

[0098] 2. Creatively solved the coordination problem of instruction / state granularity mismatch: On the instruction side, the master control state machine acts as a trigger, transforming a single coarse-grained upper-level instruction into an "ignition" signal for a long and fine process, achieving the effect of one action affecting the whole system;

[0099] On the state side, by dynamically aggregating key state events of each module, an aggregated state that accurately reflects the macro-level progress of the subsystem is generated and reported to the upper layer. This avoids the problem of reporting a large number of irrelevant intermediate states or insufficient information, and achieves efficient and semantically matched communication between the upper and lower layers.

[0100] 3. A truly modular and decoupled architecture has been established: functionally autonomous control modules communicate asynchronously through an internal event bus, with only a loose "enable" and "event reporting" relationship with the master state machine. Modifications, optimizations, or replacements of the internal logic of a module do not affect the master state machine or other modules at all. Adding new business processes only requires adding or reorganizing modules and configuring new event response relationships on the event bus, resulting in a revolutionary improvement in system scalability and maintainability.

[0101] 4. Enhanced system robustness and debuggability: Clear control logic hierarchy: The main control state machine is responsible for when to start which process, and the control module is responsible for how to execute specific tasks. This separation makes the system easier to perform unit testing, integration testing and fault location. Faults in individual modules can usually be isolated without affecting other parts of the entire system.

[0102] 5. Solves the problem of overload or state chaos in highly concurrent systems: By ensuring the exclusivity of the token, it ensures that only one module has the right to control the execution device at any given time, fundamentally eliminating the state chaos caused by multiple modules competing for control of the device at the same time; the token is passed sequentially in the event chain, forming a unidirectional flow, and there will be no circular waiting, so the system is naturally immune to deadlock.

[0103] 6. Improved system security: If the token is not passed within the predetermined time, the master control state machine can immediately locate the faulty module and trigger timeout protection (such as reclaiming the token or resetting the module), thereby quickly restoring the system or entering a safe state; the token is passed sequentially in the event chain, and when a module fails, other modules cannot misoperate the device, ensuring the security of the system.

[0104] Embodiments of the present invention also provide a hierarchical control system, which includes: an upper-level controller, at least one intermediate controller, and multiple execution devices;

[0105] The upper-level controller is used to issue state transition instructions;

[0106] At least one intermediate controller includes a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, it implements the coordinated operation method of the hierarchical control system described in any of the foregoing claims of the present invention.

[0107] Each intermediate controller controls one or more execution devices, which perform corresponding physical operations in response to the control commands of the intermediate controller.

[0108] The intermediate controller comprises multiple autonomous control modules, each responsible for a subtask, and internally maintains a master control state machine. The master control state machine receives state transition instructions from the upper-level controller, updates its own state accordingly, and synchronously sends asynchronous start events to one or more control modules based on the updated state. Upon receiving an asynchronous start event, a control module detaches from its synchronous dependency on the master control state machine and, based on its internal event-driven execution logic, controls the execution device to complete the subtask. Upon reaching a critical node, it generates a critical node state event and transmits it to other control modules via an event bus, driving them to collaboratively complete the control task. The master control state machine also monitors the critical node state events of each control module, synthesizes these events into a macroscopic state according to predefined aggregation rules, and reports it to the upper-level controller.

[0109] Embodiments of the present invention also provide an electronic device including a processor and a memory, wherein the number of processors may be one or more. The memory, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and modules. The processor executes various functional applications and data processing of the electronic device by running the software programs, instructions, and modules stored in the memory, thereby realizing the coordinated operation method of the hierarchical control system of any of the above embodiments of the present invention.

[0110] The memory may primarily comprise a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a given function; the data storage area may store data created based on terminal usage. Furthermore, the memory may include high-speed random access memory (RAM) and non-volatile memory, such as at least one disk storage device, flash memory, or other non-volatile solid-state storage device. In some instances, the memory may further include memory remotely located relative to the processor, which can be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks (LANs), mobile communication networks, and combinations thereof.

[0111] Embodiments of the present invention also provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the coordinated operation method of the hierarchical control system of any embodiment of the present invention.

[0112] The computer storage medium of this invention can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0113] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0114] Embodiments of the present invention also provide a computer program product that, when run on a computer, causes the computer to execute the coordinated operation method of the hierarchical control system of any of the above embodiments of the present invention.

[0115] The above embodiments are merely preferred embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the appended claims.

Claims

1. A method for coordinated operation of a hierarchical control system, characterized in that, The hierarchical control system includes a top-level controller, at least one intermediate controller, and an execution device controlled by the intermediate controller; the method includes: The control task of the intermediate controller is decomposed into multiple sub-tasks, and a control module is built for each sub-task. Each control module includes an independent start-up interface, execution logic based on internal event-driven processes, and a key node status reporting interface. Multiple control modules communicate with each other through an event bus. A master control state machine is maintained inside the intermediate controller. The master control state machine is configured to receive state transition instructions from the upper controller, update its own state according to the state transition instructions, and synchronously send asynchronous start events to one or more of the control modules according to the updated state. After receiving the asynchronous start event, the control module breaks away from the synchronous dependency of the master control state machine and drives the execution logic based on internal events to control the execution device to complete the sub-task. When a critical node is reached, a critical node status event is generated and transmitted to other control modules through the event bus to drive other control modules to collaboratively complete the control task. The master control state machine continuously monitors the key node state events, synthesizes the key node state events into a macro state according to predefined aggregation rules, and reports the macro state to the upper-layer controller.

2. The coordinated operation method of the hierarchical control system according to claim 1, characterized in that, The state set of the master control state machine corresponds to the state transition instruction set issued by the upper-level controller, so that the master control state machine retains only the minimum state set required for synchronization with the upper-level controller.

3. The coordinated operation method of the hierarchical control system according to claim 1, characterized in that, The internal events that drive the execution logic of the control module include internal timer timeout events, physical sensor feedback events, and key node status events from other control modules.

4. The coordinated operation method of the hierarchical control system according to claim 1, characterized in that, The predefined aggregation rules include: when multiple key node state events from different control modules simultaneously meet preset conditions, the master control state machine aggregates them into a macro state; when the multiple key node state events have logical conflicts, the master control state machine generates an abnormal state or alarm information.

5. The coordinated operation method of the hierarchical control system according to claim 1, characterized in that, The event bus provides an asynchronous communication channel for each control module. The key node status events are transmitted between control modules through the event bus, forming a cross-module event-driven chain.

6. The coordinated operation method of the hierarchical control system according to claim 5, characterized in that, A cross-module event-driven chain is pre-configured. The cross-module event-driven chain is defined and modified through a configuration file and is independent of the logic of the master control state machine.

7. The coordinated operation method of the hierarchical control system according to claim 1, characterized in that, After the control module is no longer dependent on the synchronization of the master control state machine, the execution logic of the module does not depend on the instructions of the master control state machine or the upper-level controller. After generating critical node state events, the control module restores its synchronization dependency on the master control state machine.

8. A hierarchical control system, characterized in that, include: The upper-level controller is used to issue state transition instructions; At least one intermediate controller, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the coordinated operation method of the hierarchical control system according to any one of claims 1-7; Multiple execution devices, controlled by the intermediate controller, are used to perform physical operations in response to control commands from the intermediate controller.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the coordinated operation method of the hierarchical control system as described in any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the coordinated operation method of the hierarchical control system as described in any one of claims 1-7.

Images