Distributed double-layer safety interlocking system for PECVD equipment

Abstract

This invention relates to the field of safety interlocking control technology, specifically to a distributed two-layer safety interlocking system for PECVD equipment. The system includes an interlocking cause-effect graph configuration component, a rule compilation component, multiple lower-level interlocking nodes, an upper-level interlocking coordination component, and a version consistency verification component. By using chamber pressure, process gas enable, radio frequency enable, vacuum status, purging status, maintenance status, and process stage into a common-source interlocking cause-effect graph, and generating a lower-level real-time assertion table and an upper-level state coordination automaton, the system ensures consistency arbitration between the lower-level interlocking sub-states, trigger cause codes, and upper-level interlocking shadow states. This invention reduces the problems of false interlocking, missed interlocking, and premature release of permissions caused by different sources of distributed interlocking rules, ensuring consistency between local rapid blocking and cross-process stage safety coordination.

Description

Technical Field

[0001] This invention relates to the field of safety interlocking control technology, specifically to a distributed dual-layer safety interlocking system for PECVD equipment. Background Technology

[0002] Plasma-enhanced chemical vapor deposition (PECVD) equipment is typically used in thin film deposition processes. The operation of this equipment involves a series of stages, including chamber vacuuming, process gas introduction, RF ignition, plasma maintenance, deposition completion, purging, vacuum breaking, and maintenance release. To prevent process hazards caused by abnormal chamber pressure, accidental process gas activation, accidental RF enable, incomplete purging, or accidental maintenance release, existing equipment generally incorporates safety interlock logic. The conventional implementation involves connecting signals such as chamber pressure switch status, gas enable status, RF power permission, vacuum status, and door / maintenance status to a controller. The controller then determines whether to allow the corresponding action based on preset logic. For controlled objects with high response requirements, existing solutions also configure fixed assertion rules in the local control node to directly prohibit gas valve, RF permission, or vacuum-related actions when local conditions are not met, thus shortening the response chain for local safety actions.

[0003] In distributed control architectures, existing plasma-enhanced chemical vapor deposition (PECVD) equipment typically assigns different subsystems to different control nodes. For example, the vacuum control node is responsible for vacuuming and pressure status, the gas path control node is responsible for enabling process gases, the RF control node is responsible for RF authorization and feedback status, and the upper-level coordination program is responsible for recipe progression and interlock status aggregation. The lower-level control nodes determine whether local inputs meet authorization conditions based on local rules, while the upper-level coordination program decides whether to proceed to the next process step based on the recipe stage and the status uploaded by each node. To balance response speed and global control, some solutions employ a two-layer safety interlocking method: the lower-level nodes handle immediate blocking, while the upper-level program handles cross-node authorization and alarm recording. In such solutions, the lower-level and upper-level rules are often configured manually, and the triggering reasons for lower-level interlocks are often reported in the form of status codes or alarm codes. The upper-level program then interprets and handles these triggering methods based on the recipe stage.

[0004] The main technical problem with the aforementioned conventional approach is that the underlying real-time interlocking rules and the upper-level cross-node coordination rules lack a common causal source. When there is a time lag between process stage switching, rule changes, or node status reporting, inconsistencies easily arise between local interlocking judgments and upper-level process interpretations. In plasma-enhanced chemical vapor deposition (PECVD), the same signal has different safety implications at different stages. A pressure rise might be expected during the purging stage but constitute a prohibitive condition during the RF ignition stage; the judgment boundaries for gas flow rate changes also differ between the pre-charge and deposition stages. If the underlying layer acts solely based on local, fixed rules, the upper layer struggles to promptly determine whether the triggering cause conforms to the current process causal chain. If the upper layer unilaterally decides on cross-node permission, the underlying layer might prematurely release the action due to inconsistencies in rule versions or stage signatures. This results in the inability of the two-layer interlocking to form a stable rule loop, making it difficult to simultaneously meet the requirements of rapid local blocking and cross-process stage consistency arbitration. Summary of the Invention

[0005] The purpose of this invention is to provide a distributed dual-layer safety interlocking system for PECVD equipment, which can solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows: A distributed two-layer safety interlocking system for PECVD equipment includes an interlocking causal graph configuration component, a rule compilation component, multiple lower-level interlocking nodes, an upper-level interlocking coordination component, and a version consistency verification component. The interlocking causal graph configuration component uses chamber pressure, process gas enable, radio frequency enable, plasma state, vacuum state, purging state, maintenance state, and process stage into a directed causal graph. The rule compilation component generates a lower-level real-time assertion table and an upper-level state coordination automaton based on the same interlocking causal graph. The lower-level interlocking nodes output interlocking sub-states and trigger cause codes according to the lower-level real-time assertion table. The upper-level interlocking coordination component constructs interlocking shadow states based on the upper-level state coordination automaton and performs consistency arbitration with the interlocking sub-states. The version consistency verification component verifies the correspondence between the rule versions of the lower-level real-time assertion table and the upper-level state coordination automaton.

[0007] Preferably, the interlocking causality graph configuration component sets up a process stage layer, an interlocking signal layer, a control permission layer, and a hazardous state layer in the interlocking causality graph. The process stage layer includes at least the stages of vacuuming, ventilation, RF ignition, deposition, RF shutdown, purging, vacuum breaking, and maintenance. The interlocking signal layer and the control permission layer are configured with edge semantics of allow, prohibit, mutual exclusion, pre-acknowledgment, delay release, and irreversible blocking, and each edge semantic is bound to the effective interval, pre-state, and release state of the corresponding process stage.

[0008] Preferably, the rule compilation component performs bidirectional compilation processing on the interlocking causal graph, compiling the edge semantics, process stage effective intervals, and control permission conditions related to a single underlying interlocking node into a lower-level real-time assertion table, and compiling the mutual exclusion relationships, pre-acknowledgment relationships, and delay release relationships spanning two or more underlying interlocking nodes into an upper-level state coordination automaton, and writing the same causal graph version identifier, stage signature, rule hash, and compilation batch identifier for the lower-level real-time assertion table and the upper-level state coordination automaton.

[0009] Preferably, when each underlying interlocking node executes the underlying real-time assertion table, it encapsulates the local interlocking input, process stage identifier, control permission status, interlocking sub-state, trigger reason code, sampling timestamp, and rule version identifier into an event token; the upper-layer interlocking coordination component sorts the event tokens from multiple underlying interlocking nodes according to the sampling timestamp and the process stage identifier, and generates an interlocking shadow state according to the upper-layer state coordination automaton, and establishes a mapping record between the interlocking shadow state and the interlocking sub-state in the corresponding event token.

[0010] Preferably, the interlocking causal graph configuration component establishes a permission prerequisite set and a permission exclusion set for each control permission. The permission prerequisite set consists of edge semantics corresponding to the chamber pressure, vacuum state, purging state, and maintenance state that must be satisfied before entering the current process stage. The permission exclusion set consists of edge semantics corresponding to the prohibition of process gas enable, radio frequency enable, and vacuum breaking permission that are simultaneously satisfied with the current control permission. The permission prerequisite set and the permission exclusion set are used as graph constraint segments that can be recognized by the rule compilation component.

[0011] Preferably, when the rule compilation component changes the rules of the interlocking causal graph, it forms an incremental compilation fragment for the semantics of the changed edge and its adjacent process stage nodes, interlocking signal nodes, and control permission nodes, and synchronously converts the incremental compilation fragment into a low-level assertion increment and an upper-level automaton increment; the version consistency verification component generates a run activation flag after the low-level assertion increment and the upper-level automaton increment have the same rule hash, stage signature, and compilation batch identifier, and the run activation flag is written to the relevant low-level interlocking node and the upper-level interlocking coordination component.

[0012] Preferably, the upper-layer interlocking coordination component performs causal chain matching processing on the event token, associates the local interlocking input corresponding to the trigger cause code with the expected dangerous state node of the same process stage in the interlocking shadow state, and generates a cross-node arbitration record when the association result shows that the process stage is inconsistent, the control permission is mutually exclusive, the pre-confirmation is missing, or the delayed release is not completed. The cross-node arbitration record includes conflict edge semantics, conflict control permission, the identifier of the underlying interlocking node involved, and the sampling timestamp.

[0013] Preferably, the upper-level interlocking coordination component generates a permission lock table based on the cross-node arbitration record. The permission lock table marks conflict control permissions in RF enable, process gas enable, vacuum breaking permission, purging permission, and maintenance release as prohibited permission, maintained permission, or conditional permission. The permission lock table is bound to the interlocking sub-state of the corresponding lower-level interlocking node. The lower-level interlocking node maintains prohibited output when the local interlocking input satisfies the lower-level real-time assertion table and prohibited permission exists. When conditional permission exists, it reads the pre-acknowledgment items included in the conditional permission.

[0014] Preferably, before receiving the license locking table, the version consistency verification component performs joint verification on the rule version identifier, cause-effect graph version identifier, stage signature, rule hash, and compilation batch identifier of the underlying interlocking nodes involved; when any identifier is inconsistent with the run activation flag, the corresponding control license is written into the version isolation area, and the version isolation area is merged with the prohibited license in the license locking table; when all identifiers are consistent and there is no incomplete conflict edge semantics in the cross-node arbitration record, the pre-confirmation item in the conditional license is retained.

[0015] Preferably, before releasing the control permissions in the version isolation zone or permission locking table, the upper-level interlocking coordination component generates an unlocking sequence according to the reverse dependency relationship in the interlocking causal graph. The unlocking sequence sequentially includes rule version review, interlocking sub-state refresh, permission pre-set confirmation, permission exclusion set clearing, and interlocking shadow state synchronization. Each lower-level interlocking node returns the event token of the corresponding unlocking step to the upper-level interlocking coordination component. The upper-level interlocking coordination component deletes the corresponding prohibited permission or conditional permission when the event token timestamps of adjacent unlocking steps are consecutive and the stage signatures are consistent.

[0016] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. This invention unifies chamber pressure, process gas enable, radio frequency enable, plasma state, vacuum state, purging state, maintenance state, and process stage into an interlocking causality graph. A bottom-level real-time assertion table and an upper-level state coordination automaton are generated from the same interlocking causality graph, ensuring that the bottom-level nodes and upper-level coordination logic share the same rule source. Bottom-level interlocking nodes output interlocking sub-states and trigger cause codes according to the bottom-level real-time assertion table. The upper-level interlocking coordination component constructs interlocking shadow states according to the upper-level state coordination automaton and arbitrates the consistency between the interlocking shadow states and interlocking sub-states. Through this two-layer, homogeneous rule structure, local controlled objects can directly enter a prohibited output state when pressure, gas, radio frequency, purging, or maintenance conditions are not met. The upper level can also interpret the bottom-level trigger cause based on the current process stage and cross-node causal relationships, preventing the same signal from being incorrectly deactivated or incorrectly released due to different stage meanings. The version consistency verification component verifies the correspondence between the rule versions of the underlying real-time assertion table and the upper-layer state coordination automaton, ensuring that the underlying rules, stage signatures, rule hashes, and upper-layer automata remain consistent after rule changes, reducing the possibility of distributed nodes operating in a state of rule asynchrony. These technical features work together to enable the distributed two-layer security interlocking to maintain local response speed while forming a closed-loop interlocking judgment across process stages and control nodes, directly improving upon the rule inconsistency problem in the background technology.

[0017] 2. This invention also enables permission, prohibition, mutual exclusion, pre-confirmation, delay release, and irreversible blocking relationships to be compiled into executable graph constraint fragments through edge semantic configuration between the process stage layer, interlocking signal layer, control permission layer, and hazardous state layer. The permission pre-set set and permission exclusion set in the interlocking causal graph are used to define the dependencies between control permissions such as RF enable, process gas enable, vacuum breaking permission, purging permission, and maintenance release. When rules change, the rule compilation component forms incremental compilation fragments for the changed edge semantics and adjacent nodes, and synchronously converts them into lower-level assertion increments and upper-level automaton increments, reducing the gap between local rule updates and upper-level rule updates. The upper-level interlocking coordination component performs causal chain matching on the trigger cause code, sampling timestamp, process stage identifier, and rule version identifier in the event token. When process stage inconsistencies, control permission mutual exclusions, missing pre-confirmation, or incomplete delay release occur, a cross-node arbitration record is generated, and a permission locking table is formed accordingly. Version isolation zones and unlock sequences further define the license recovery process, ensuring that rule version verification, interlock sub-state refresh, license pre-set confirmation, license exclusion set clearing, and interlock shadow state synchronization are executed according to reverse dependencies. Thus, interlock triggering, license locking, rule isolation, and license recovery are all constrained by the same causal relationship, reducing secondary interlock conflicts caused by incorrect recovery order or cross-node state asynchrony. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating the overall operation of the distributed dual-layer safety interlock system for PECVD equipment according to the present invention. Figure 2 This is a flowchart of the interlocking cause-effect graph hierarchical configuration and bidirectional rule compilation process of the present invention; Figure 3 This is a flowchart illustrating the event token construction, interlocking shadow state matching, and permission locking process of the present invention. Figure 4 This is a flowchart illustrating the version consistency verification, version isolation, and reverse unlocking process of the present invention. Detailed Implementation

[0019] refer to Figure 1In one embodiment, a distributed two-layer safety interlocking system for PECVD equipment is provided, including an interlocking causal graph configuration component, a rule compilation component, multiple lower-level interlocking nodes, an upper-level interlocking coordination component, and a version consistency verification component. The interlocking causal graph configuration component uses chamber pressure, process gas enable, radio frequency enable, plasma state, vacuum state, purging state, maintenance state, and process stage into an interlocking causal graph with directed causal relationships. The rule compilation component generates a lower-level real-time assertion table and an upper-level state coordination automaton based on the same interlocking causal graph. The lower-level interlocking nodes output interlocking sub-states according to the lower-level real-time assertion table. The upper-level interlocking coordination component constructs an interlocking shadow state based on the upper-level state coordination automaton and performs consistency arbitration with the interlocking sub-state. The version consistency verification component verifies the correspondence between the rule versions of the underlying real-time assertion table and the upper-level state coordination automaton. Specifically, the interlocking cause-effect graph configuration component uses the process stage as the semantic context, and uses chamber pressure, process gas enable, radio frequency enable, plasma state, vacuum state, purging state, and maintenance state as interlocking inputs or intermediate states. It uses radio frequency permission, gas permission, vacuum break permission, purging permission, and maintenance release as control permissions, and uses pressure anomalies as associated with... Radio frequency enable, incomplete purging accompanied by vacuum breaking permission, and unconfirmed maintenance status accompanied by automatic operation permission are considered as dangerous states. The causal dependency between these states and permissions is defined by directed edges, allowing the same interlocking signal to have different executable meanings at different process stages. After reading the interlocking causal graph, the rule compilation component expands the edge semantics related to a single bottom-level interlocking node into directly executable local Boolean assertions, stage assertions, and release assertions. It expands the pre-confirmation, mutual exclusion, and delayed release relationships across bottom-level interlocking nodes into state transition conditions in the upper-level state coordination automaton. The bottom-level interlocking node does not wait for the upper-level automaton after acquiring the local interlocking input. The interlocking coordination component confirms the completion of local assertion matching and encapsulates the matching result into an interlocking sub-state and a trigger cause code. The upper-level interlocking coordination component reconstructs the interlocking shadow states of multiple lower-level interlocking nodes according to the process stage and performs consistency arbitration on the interlocking sub-states and interlocking shadow states. The version consistency verification component verifies the source relationship between the lower-level real-time assertion table and the upper-level state coordination automaton during rule loading, rule change, operation activation, and license recovery. This embodiment, through the closed-loop configuration of same-source rules, lower-level blocking, upper-level arbitration, and version verification, ensures that local rapid safety actions and cross-process stage consistency judgments are under the same causal rule constraints.

[0020] In this embodiment, the interlocking cause-effect graph is stored in the form of a directed attribute graph. Graph nodes include at least stage nodes, signal nodes, permitted nodes, and dangerous nodes. Graph edges include at least dependent edges, prohibited edges, mutually exclusive edges, pre-acknowledgment edges, release edges, and irreversible blocking edges. Each graph edge carries a start stage, an end stage, an input state value, a permitted state value, a release condition reference, and a compilation target tag. The start stage and end stage are used to define the range of process stages to which the edge semantics apply. The input state value is used to express the acceptable state of chamber pressure, process gas enable, RF enable, plasma state, vacuum state, purging state, and maintenance state at the current stage. The permitted state value is used to express whether the corresponding control permission allows output. The release condition reference is used for... The expression of the prerequisite relationships that must be satisfied before the prohibition and permission are lifted is used to distinguish whether the graph edges are written into the lower-level real-time assertion table, the upper-level state coordination automaton, or both. The lower-level real-time assertion table uses process stage identifier, input signal identifier, edge semantic identifier, permission identifier, and reason code identifier as indexes. The upper-level state coordination automaton uses process stage, interlock shadow state, event token, and permission state as state transition inputs. During runtime, the lower-level interlock nodes first form interlock sub-states based on the local assertion table, and then the upper-level interlock coordination component identifies cross-node causal relationships based on the automaton state. The operating mechanism of this embodiment is to transform the originally separately maintained lower-level rules and upper-level rules into two execution projections of the same graph structure, reducing the rule fragmentation caused by manual separate configuration.

[0021]

[0022] in, This represents the rule version consistency judgment value. A value of 1 indicates that the rule is allowed to enter the running and active state, while a value of 0 indicates that the rule is to enter version isolation processing. This represents the rule hash carried by the underlying real-time assertion table. This represents the rule hash carried by the upper-level state coordination automaton. This indicates the stage signature carried by the underlying real-time assertion table. This represents the stage signature carried by the upper-level state coordination automaton. This indicates the version identifier of the causal graph carried by the underlying real-time assertion table. This indicates the version identifier of the causal graph carried by the upper-level state coordination automaton. This indicates the compilation batch identifier carried by the underlying real-time assertion table. This indicates the compilation batch identifier carried by the upper-level state coordination automaton. These are indicator operators; they take a value of 1 if the condition within the parentheses is true and 0 if it is false. In the example, all four indicator operators take a value of 1 when the rule hash, stage signature, cause-effect graph version identifier, and compilation batch identifier are all consistent. Set the value to 1; if the stage signatures are inconsistent, set the corresponding indicator operator to 0. Setting it to 0 physically means whether the same interlocking rule maintains the same source on the underlying real-time execution side and the upper-level coordination and interpretation side.

[0023] refer to Figure 2 In a preferred embodiment, based on the aforementioned distributed dual-layer safety interlocking system for PECVD equipment, the interlocking causality graph configuration component sets up a process stage layer, an interlocking signal layer, a control permission layer, and a hazardous state layer in the interlocking causality graph. The process stage layer includes at least the stages of vacuuming, venting, RF ignition, deposition, RF shutdown, purging, vacuum breaking, and maintenance. The interlocking signal layer and the control permission layer are configured with edge semantics of allow, prohibit, mutual exclusion, pre-acknowledgment, delayed release, and irreversible blocking, and each edge semantic is bound to the effective range, pre-state, and release state of the corresponding process stage. Specifically, the process stage layer is used to define the semantic boundary of the same interlocking signal, the interlocking signal layer is used to carry chamber pressure, process gas enable, RF enable, plasma state, vacuuming state, purging state, and maintenance state, and the control permission layer... The layer is used to carry RF enable permission, process gas enable permission, vacuum breaking permission, purging permission, and maintenance release. The hazardous state layer is used to carry hazardous state nodes formed by the combination of signals and permissions. The allow edge indicates that a certain interlock signal meets the permission release condition in the current process stage. The prohibit edge indicates that a certain interlock signal directly forms the permission prohibition condition in the current process stage. The mutual exclusion edge indicates that two control permissions cannot be established at the same time. The pre-confirmation edge indicates that a specific interlock signal or state confirmation must exist before the permission is released. The delayed release edge indicates that after the interlock is triggered, it must be released after the release state is continuously met. The irreversible blocking edge indicates that after being triggered in the current process stage, automatic recovery is not allowed. This embodiment solidifies the relationship between stages, signals, permissions, and hazardous states into compileable graph semantics through a layered modeling method, so that the real-time judgment of the bottom layer and the state interpretation of the upper layer can be traced back to the same graph edge.

[0024] Table 1. Example of Interlocking Cause-Effect Graph Configuration Process Stages Vacuum pumping, ventilation, RF ignition, deposition, RF shutdown, RF purging, vacuum breaking, and maintenance. Recording phase, entering condition phase, exiting condition phase, mutual exclusion relationship Upper-level state coordination automaton Interlocking signal layer Chamber pressure, process gas enable, radio frequency enable, plasma state, vacuum state, purging state, maintenance state Record signal source, signal lifetime, and signal stage. Low-level real-time assertion table and high-level state coordination automaton Control Licensing Layer RF enable process gas enable vacuum breaking allow purging allow maintenance release Record the pre-license set, license exclusion set, license revocation conditions Underlying real-time assertion table and permission locking table Dangerous State Layer Pressure not met, accompanied by unconfirmed RF clearance purging, accompanied by unconfirmed vacuum clearance maintenance, accompanied by unconfirmed automatic operation clearance. Record dangerous combination trigger cause code arbitration record field Upper-level interlocking shadow state Pre-confirmation edge Confirmation relationship before control license release Binding phase effective interval preceding state release state Low-level real-time assertion table and high-level state coordination automaton Mutual Exclusive Edges Simultaneous licensing relationships are not allowed. Binding conflict control permission conflict underlying interlocking node Upper-level state coordination automaton and permission lock table

[0025] In a preferred embodiment, based on the aforementioned system comprising a process stage layer, an interlocking signal layer, a control permission layer, and a hazardous state layer, the rule compilation component performs bidirectional compilation processing on the interlocking causal graph. It compiles the edge semantics, effective intervals of the process stage, and control permission conditions related to a single bottom-level interlocking node into a bottom-level real-time assertion table. It compiles the mutual exclusion relationships, pre-acknowledgment relationships, and delayed release relationships spanning two or more bottom-level interlocking nodes into an upper-level state coordination automaton. Furthermore, it writes the same causal graph version identifier, stage signature, rule hash, and compilation batch identifier into the bottom-level real-time assertion table and the upper-level state coordination automaton. Specifically, after reading the interlocking causal graph, the rule compilation component assigns ownership to the graph edges. If the start and end points of an edge both belong to the same bottom-level interlocking node's directly observable or directly controllable range, it compiles them into a local assertion in the bottom-level real-time assertion table. The assertions include stage conditions, input conditions, permitted output conditions, prohibited output conditions, and trigger reason codes. If a graph edge involves two or more lower-level interlocking nodes or involves the upper-level recipe stage state, it is compiled into the transition conditions in the upper-level state coordination automaton. The transition conditions include the source node, target node, stage transition condition, mutual exclusion permission condition, and release confirmation condition. The rule hash is generated by normalizing and sorting the graph node identifier, graph edge identifier, edge semantics, stage valid interval, and release state. The stage signature is generated by the process stage sequence and the allowed transition relationship between stages. The causal graph version identifier is generated by the graph version when the rule is published. The compilation batch identifier is generated by the same compilation task. This embodiment maps the same interlocking causal graph to lower-level execution rules and upper-level coordination rules through bidirectional compilation, so that the distributed interlocking nodes and upper-level coordination programs no longer rely on manually maintained rule texts.

[0026] In a preferred embodiment, based on the aforementioned bidirectional compilation process, the rule compilation component forms an independent rule view for each underlying interlocking node when generating the underlying real-time assertion table. The independent rule view only retains graph edges related to the input, output, and permissions of the node, while retaining summary constraints from cross-node graph edges. The summary constraints do not directly require the underlying interlocking node to access the real-time signals of other nodes, but rather enter the underlying real-time assertion table in the form of permission lock status, conditional permission flag, or prohibition permission flag. When generating the upper-level state coordination automaton, the rule compilation component represents cross-node mutual exclusion relationships as concurrent permission conflict migration, pre-acknowledgment relationships as necessary states before permission release, delayed release relationships as release waiting states, and irreversible blocking relationships as non-reversible states within a phase. The independent rule view of the underlying interlocking node is mainly based on local reactions, while the upper-level state coordination automaton is mainly based on cross-node interpretation. The interface between the two consists of event tokens, permission lock tables, and version consistency verification results. This embodiment, without requiring the underlying interlocking node to retain complete global rules, allows the underlying rules to still retain constraint summaries from the global causal graph, reducing the possibility of losing cross-node constraints after the underlying rules are simplified.

[0027]

[0028] in, This represents the set of affected nodes that need to be recompiled after the rule change. Let V represent the set of edges whose semantics have changed, and let V represent the set of nodes in the interlocking causal graph. Indicates the semantics of the changed edge. This represents the graph distance from node x to the changed edge semantic e. A distance less than or equal to 1 indicates that the node and the changed edge are directly adjacent. This indicates that there is a directed path from node y to the control permission p. This represents the set of control permissions affected by the changed edge. In the example, when the pre-acknowledgment edge of the RF enable permission changes, the RF enable permission node, chamber pressure node, vacuum status node, corresponding process stage node, and purge status node that can affect the RF enable permission through a directed path enter the control set. The physical meaning is that when a rule changes, it should be included in the minimum causal range of the underlying assertion increment and the upper automaton increment simultaneously.

[0029] refer to Figure 3In a preferred embodiment, based on the aforementioned system that writes the same causal graph version identifier, stage signature, rule hash, and compilation batch identifier, each underlying interlocking node, when executing the underlying real-time assertion table, encapsulates the local interlocking input, process stage identifier, control permission state, interlocking sub-state, trigger cause code, sampling timestamp, and rule version identifier into an event token. The upper-layer interlocking coordination component sorts the event tokens from multiple underlying interlocking nodes according to the sampling timestamp and the process stage identifier, and generates interlocking shadow states based on the upper-layer state coordination automaton, establishing a mapping record between the interlocking shadow states and the corresponding interlocking sub-states in the event tokens. Specifically, the local interlocking input in the event token is used to record the signal state observed by the underlying interlocking node during assertion execution, and the process stage identifier is used to bind the local signal state to the recipe stage. Semantics, control permission states are used to record the permission states output or received by the underlying interlocking nodes, interlocking sub-states are used to express local assertion results, trigger reason codes are used to point to the semantics of trigger edges in the interlocking causal graph, sampling timestamps are used to reconstruct the timing of cross-node events, and rule version identifiers are used to participate in version consistency verification. The upper-layer interlocking coordination component first divides event tokens according to the process stage identifier, then establishes an event sequence according to the sampling timestamp within the same process stage, and inputs the event sequence into the upper-layer state coordination automaton. The interlocking shadow state output by the automaton forms a mapping record with the interlocking sub-states in the event tokens. The mapping record includes at least the underlying interlocking node identifier, trigger reason code, shadow state identifier, mapping time, and version identifier. In this embodiment, event tokens enable the underlying immediate assertion results to be interpreted by the upper layer with the same stage semantics, avoiding the lack of causal context when only alarm codes are reported.

[0030] Table 2 Event Token Fields and Processing Rules Local interlocking input Sampling results of the underlying interlocking nodes Match with input conditions in the underlying real-time assertion table Interlocking signal layer node Process stage identification Mirroring the upper-level formulation stage or the lower-level stage Used to determine the stage to which an event token belongs. Process stage node Control license status Low-level output or upper-level distribution of licenses Cross-validation with the permission lock table Control Permission Layer Node Interlocking sub-state Execution result of the underlying real-time assertion table Establish a mapping record with the interlocking shadow state Dangerous state layer nodes Trigger reason code assertion terms or edge semantic identifiers Used for causal chain matching and arbitration record generation Interlocking causal graph edge semantics Sampling timestamp Underlying Interlocking Node Event Time Stamp Used for cross-node sorting and unlocking continuity judgment. Event Sequence Rule version identifier Underlying real-time assertion table version Used for version consistency verification and version isolation Run activation mark

[0031] In a preferred embodiment, based on the aforementioned event token sorting and mapping records, the interlocking causal graph configuration component establishes a permission precondition set and a permission exclusion set for each control permission. The permission precondition set consists of edge semantics corresponding to chamber pressure, vacuum state, purging state, and maintenance state that must be satisfied before entering the current process stage. The permission exclusion set consists of edge semantics corresponding to prohibiting process gas enable, radio frequency enable, and vacuum breaking permission from being simultaneously satisfied with the current control permission. The permission precondition set and the permission exclusion set are used as graph constraint segments that can be recognized by the rule compilation component. Specifically, the permission precondition set for radio frequency enable permission can be composed of edge edges for chamber pressure permission, vacuum state confirmation, process gas state permission, and maintenance state prohibition in the current process stage, and the permission exclusion set... The set of permissions can be composed of mutually exclusive edges for vacuum breaking, mutually exclusive edges for maintenance release, and mutually exclusive edges for incomplete purging. The set of permissions prior to enabling process gas can be composed of vacuum state, chamber pressure state, and current formulation stage. The set of permissions for exclusion can be composed of maintenance state, vacuum breaking permission, and incomplete RF shutdown state. When the rule compilation component reads the set of permissions prior to enabling, it writes the semantics of edges that can be judged by a single underlying interlocking node into the underlying real-time assertion table and writes the cross-node confirmation relationship into the upper-level state coordination automaton. When reading the set of permissions for exclusion, it writes the local mutual exclusion relationship into the local prohibition assertion and writes the cross-node mutual exclusion relationship into the upper-level state coordination automaton and permission locking table to generate rules. In this embodiment, by decomposing control permissions into a set of permissions prior to enabling and a set of permissions for exclusion, both permission release and permission prohibition have traceable graph constraint sources.

[0032] In this embodiment, the permission pre-set set and permission exclusion set are organized around the control permission. Each control permission corresponds to a pre-set set and an exclusion set. The elements of the sets are all edge semantic references in the interlocking causal graph, rather than ordinary text conditions. When the lower-level interlocking node executes the lower-level real-time assertion table, the locally observable pre-set set elements are directly calculated as permission release conditions, and the locally observable exclusion set elements are directly calculated as permission prohibition conditions. The cross-node set elements are calculated by the upper-level interlocking coordination component based on the event token and the interlocking shadow state and written into the permission locking table. If the local pre-set set of the RF enable permission is satisfied but the upper-level permission locking table still contains a prohibition permission from the vacuum break allow mutual exclusion edge, the lower-level interlocking node outputs the prohibition state after taking the intersection of the local permission result and the prohibition permission. If the local exclusion set of the gas enable permission is not triggered but the upper-level condition permission contains a purge state pre-confirmation item, the lower-level interlocking node does not release the gas enable permission before reading the purge state confirmation. This embodiment uses set-based permission control to merge local assertions and upper-level arbitration on the same permission object, avoiding bypassing cross-node mutual exclusion constraints when the local permission is established alone.

[0033]

[0034] in, Indicates event token The causal chain matching value between the interlocked shadow state z and the interlocked shadow state z. Indicates the sampling timestamp of the event token. This indicates the stage time window corresponding to the interlocking shadow state. This indicates the process stage identifier carried by the event token. This indicates the process stage identifier corresponding to the interlock shadow state. This indicates the semantics of the edge pointed to by the trigger reason code carried by the event token. This represents the set of edge semantics that are allowed to be matched in the interlocking shadow state. This indicates the control permission status carried by the event token. This indicates the expected control permission state corresponding to the interlocking shadow state. , , , To match weights that sum to 1, in this example, all four weights are set to 1 / 4. If the event time falls within the stage time window, the process stage is consistent, the trigger reason code belongs to the allowed matching edge semantic set, and the control permission state is consistent, then... If the process stages and control permission statuses are inconsistent, then... Taking 1 / 2, the physical meaning is whether the underlying interlock sub-state can be interpreted by the current interlock shadow state of the upper layer.

[0035] In a preferred embodiment, based on the aforementioned permission pre-set and permission exclusion set, when the interlocking causal graph undergoes a rule change, the rule compilation component forms incremental compilation fragments for the changed edge semantics and its adjacent process stage nodes, interlocking signal nodes, and control permission nodes, and synchronously converts the incremental compilation fragments into lower-level assertion increments and upper-level automaton increments; the version consistency verification component generates a run activation flag after the lower-level assertion increment and the upper-level automaton increment have the same rule hash, stage signature, and compilation batch identifier, and the run activation flag is written to the relevant lower-level interlocking nodes and upper-level interlocking coordination components; specifically, the rule change can manifest as an adjustment of the effective range of a certain process stage, or a change in the semantics of a certain edge from allowed to allowed. When a change is made to require prior confirmation, a new mutual exclusion relationship is added to a control permission, or a certain release state is adjusted, the rule compilation component does not recompile the entire interlocking causal graph. Instead, it extracts incremental compilation fragments based on the set of affected nodes. The underlying assertion increments include new assertion items, invalid assertion items, and modified assertion items, while the upper-level automaton increments include new state transitions, invalid state transitions, and modified state transitions. The version consistency verification component performs joint verification on the rule hashes, stage signatures, and compilation batch identifiers of the two types of increments, and generates a runtime activation flag after the verification is consistent. This embodiment enables rule changes to enter the runtime while maintaining the same source between the underlying and upper layers through incremental compilation and unified activation flags, without producing a state where the underlying layer has been updated but the upper layer still interprets it according to the old rules.

[0036] In this embodiment, the run activation marker may include an activation identifier, a cause-effect graph version identifier, a stage signature, a rule hash, a compilation batch identifier, an applicable set of underlying interlocking nodes, and an applicable set of control permissions. After receiving the run activation marker, the relevant underlying interlocking nodes only write the underlying assertion increment that matches their own node identifier into the run rule area and move the original assertion items into the historical rule area. After receiving the run activation marker, the upper-level interlocking coordination component writes the upper-level automaton increment into the current state coordination automaton and establishes a migration relationship between the historical automaton state and the current automaton state. If a certain underlying interlocking node does not return activation confirmation, the version consistency verification component does not mark the control permission involving that node as runnable, but instead places the relevant control permission into the version isolation area. If all involved nodes return activation confirmation, the upper-level interlocking coordination component constructs the interlocking shadow state according to the current state coordination automaton. This embodiment avoids the mixed execution of old and new rules during the rule switching process by separating the run rule area, the historical rule area, and the version isolation area.

[0037] In a preferred embodiment, based on the aforementioned operation activation flag, the upper-layer interlocking coordination component performs causal chain matching processing on the event token, associating the local interlocking input corresponding to the trigger cause code with the expected hazardous state node of the same process stage in the interlocking shadow state. When the association result shows inconsistencies in process stages, mutually exclusive control permissions, missing pre-confirmation, or incomplete delayed release, a cross-node arbitration record is generated. The cross-node arbitration record includes conflict edge semantics, conflict control permissions, the identifiers of the underlying interlocking nodes involved, and a sampling timestamp. Specifically, the upper-layer interlocking coordination component first selects the corresponding interlocking shadow state based on the process stage identifier in the event token, and then queries the interlocking causal graph based on the trigger cause code. For the corresponding edge semantics, if the queried edge semantics points to the expected dangerous state node in the dangerous state layer, the event token is marked as interpretable trigger. If the edge semantics corresponding to the trigger reason code is only valid in other process stages, a cross-node arbitration record for inconsistent process stages is generated. If the control permission state in the event token and the mutually exclusive permission in the permission exclusion set are both established, a cross-node arbitration record for mutually exclusive control permissions is generated. If the edge semantics in the permission precondition set do not have corresponding event token confirmation, a cross-node arbitration record for missing precondition confirmation is generated. If the delay release edge is still in a waiting state, a cross-node arbitration record for incomplete delay release is generated. In this embodiment, the underlying reason code is transformed into a graph relationship that can be verified by the upper-layer automaton through causal chain matching.

[0038] In this embodiment, the cross-node arbitration record is not a regular alarm record, but rather the basis for subsequently generating the license lock table and version isolation zone. The conflict edge semantics in the cross-node arbitration record are used to locate the graph edges that cause conflicts in the interlocking causal graph. The conflict control license is used to limit the licensed objects that need to be prohibited, maintained, or conditionally released. The underlying interlocking node identifiers involved are used to determine the scope of the lock command issuance. The sampling timestamp is used to determine whether the conflict belongs to a concurrent conflict within the same process stage. When multiple cross-node arbitration records point to the same control license, the upper-level interlocking coordination component merges the records in the order of irreversible blocking edge, mutual exclusion edge, pre-confirmation edge, and delayed release edge. If an irreversible blocking edge exists, the control license is used for non-automatic release within the stage. If a mutual exclusion edge exists, the control license is used for prohibition license. If only the pre-confirmation edge is missing, the control license is used for conditional license. If only the delayed release edge is incomplete, the control license is used for maintenance license. This embodiment, through the structured merging of arbitration records, ensures that subsequent license locks have a definite causal source and processing order.

[0039] In a preferred embodiment, based on the aforementioned cross-node arbitration record, the upper-layer interlocking coordination component generates a permission locking table according to the cross-node arbitration record. The permission locking table marks conflict control permissions in RF enable, process gas enable, vacuum breaking permission, purging permission, and maintenance release as prohibited permission, hold permission, or conditional permission. The permission locking table is then bound to the interlocking sub-state of the corresponding lower-level interlocking node. The lower-level interlocking node maintains prohibited output when its local interlocking input satisfies the lower-level real-time assertion table and a prohibited permission exists; when a conditional permission exists, it reads the pre-acknowledgment items included in the conditional permission. Specifically, the permission locking table uses the control permission as the primary key and includes the lower-level interlocking node identifier, permission type, associated conflict edge semantics, associated interlocking sub-state, conditional pre-acknowledgment items, hold reason, and version number. This identifier is a field. "Prohibit Permission" indicates that the current permission cannot be released; "Maintain Permission" indicates that the current permission maintains its previous safe state; and "Conditional Permission" indicates that even after the local assertion is satisfied, a pre-confirmation item still needs to be read. After receiving the permission lock table, the underlying interlocking node uses the local assertion result and the permission lock state together as input and output conditions. If the local assertion result is "allow" and the permission lock state is "prohibit permission," the underlying interlocking node outputs a "prohibit" state. If the local assertion result is "allow" and the permission lock state is "conditional permission," the underlying interlocking node reads the condition pre-confirmation item and waits for confirmation from the upper-level interlocking coordination component or a locally observable signal. If the local assertion result is "prohibit," there is no need to read the conditional permission, and the "prohibit" state is output directly. This embodiment uses the permission lock table to enable the upper-level cross-node arbitration result to enter the underlying real-time execution logic.

[0040] In this embodiment, the binding between the permission locking table and the interlocking sub-state adopts a double-key structure. The double-key structure consists of a control permission identifier and a lower-level interlocking node identifier. The binding content includes the trigger reason code, the interlocking sub-state, the conflict edge semantics, and the stage signature. When the interlocking sub-state of the lower-level interlocking node is refreshed, the lower-level interlocking node returns the refreshed event token to the upper-level interlocking coordination component. The upper-level interlocking coordination component updates the permission locking table according to the control permission state in the event token. If the mutual exclusion edge corresponding to the prohibition permission still exists, the prohibition permission is maintained. If the pre-acknowledgment item corresponding to the condition permission has been satisfied and there is no mutual exclusion edge, the condition permission is changed to the pending unlocking state. If the delayed release edge corresponding to the hold permission is still in the waiting state, the current permission state is maintained. The update of the permission locking table does not directly delete the original arbitration record, but marks the arbitration record as processed, held, or pending unlocking, so that the change of permission state can correspond to the event token sequence. This embodiment forms a continuous data closed loop between the lower-level interlocking sub-state and the upper-level permission control through double-key binding and state tracking.

[0041] refer to Figure 4In a preferred embodiment, based on the aforementioned license lock table, before receiving the license lock table, the version consistency verification component performs joint verification on the rule version identifier, causal graph version identifier, stage signature, rule hash, and compilation batch identifier of the underlying interlocking nodes involved; when any identifier is inconsistent with the runtime activation flag, the corresponding control permission is written into the version isolation area, and the version isolation area is merged with the prohibited permissions in the license lock table; when all identifiers are consistent and there is no incomplete conflict edge semantics in the cross-node arbitration record, the pre-confirmation item in the conditional permission is retained; specifically, the version consistency verification component verifies the event token, the runtime rule area of ​​the underlying interlocking nodes, and the upper-level state... Version elements are extracted from the state coordination automaton, and the extraction results are compared with the running activation flag item by item. If the rule version identifier is consistent but the stage signature is inconsistent, it means that the interpretation of the stage boundary is different between the underlying assertion table and the upper automaton. If the rule hash is inconsistent, it means that there is at least a difference in the graph node, graph edge, or edge semantics. If the compilation batch identifier is inconsistent, it means that the underlying assertion increment and the upper automaton increment are not the same compilation result. When any inconsistency occurs, the relevant control permission enters the version isolation zone and is merged with the prohibition permission in the permission locking table and then issued to the corresponding underlying interlocking node. In this embodiment, the version isolation zone ensures that the control permission when the rule source is inconsistent does not participate in the release of ordinary conditional permissions.

[0042] In this embodiment, the version isolation zone uses control permissions as the primary index and version inconsistency sources as secondary indexes. These inconsistencies include underlying rule version inconsistencies, upper-layer automaton version inconsistencies, stage signature inconsistencies, rule hash inconsistencies, and compilation batch identifier inconsistencies. When the version isolation zone is merged with prohibited permissions in the permission locking table, if the same control permission simultaneously has version isolation and mutual exclusion edge conflicts, the version isolation state is used as the primary cause of the prohibited permission, and the mutual exclusion edge conflict as the secondary cause. The underlying interlocking nodes only receive the merged prohibited permission and do not need to handle multiple conflict sources separately. When all identifiers are consistent and there are no incomplete conflict edge semantics in the cross-node arbitration record, the version consistency verification component does not delete the pre-confirmation items in the conditional permission. Instead, it retains the conditional permission and requires the underlying interlocking nodes to continue reading the pre-confirmation items, avoiding the direct release of control permissions that have not yet met pre-confirmation requirements after version consistency. This embodiment separates version isolation from conditional permissions, allowing version consistency verification and interlocking causal confirmation to assume different control boundaries.

[0043]

[0044] in, This represents the permission release judgment value for the k-th unlocking step. A value of 1 indicates that the next unlocking step is allowed, while a value of 0 indicates that the current permission lock state is maintained. This represents the confirmation value of the prerequisite set corresponding to the k-th unlocking step. A value of 1 indicates that the prerequisite set has been confirmed. This represents the set of uncleared permission exclusions corresponding to the k-th unlocking step. To represent an empty set, This represents the sampling timestamp of the event token for the k-th unlocking step. This indicates the sampling timestamp of the event token from the adjacent preceding unlocking step. This represents the allowed continuous time window for the k-th unlocking step. In the example, it means that the rule versions are consistent, the preceding set is confirmed, the exclusion set is empty, and the time difference between adjacent event tokens is within the continuous window. If the exclusivity set still contains a vacuum-breaking allowed mutual exclusion edge, then... Take 0, Setting it to 0 physically means whether the control permission can proceed to the next recovery stage according to the reverse dependency relationship.

[0045] In a preferred embodiment, based on the aforementioned version isolation zone and license locking table, before releasing the control license in the version isolation zone or license locking table, the upper-layer interlocking coordination component generates an unlocking sequence according to the reverse dependency relationship in the interlocking causal graph. The unlocking sequence sequentially includes rule version verification, interlocking sub-state refresh, license pre-set confirmation, license exclusion set clearing, and interlocking shadow state synchronization. Each lower-level interlocking node returns the event token of the corresponding unlocking step to the upper-layer interlocking coordination component. The upper-layer interlocking coordination component deletes the corresponding prohibited license or conditional license when the event token timestamps of adjacent unlocking steps are consecutive and the stage signatures are consistent. Specifically, the reverse dependency relationship extends from the locked control license to its pre-set. The process involves a backtracking of the combination, exclusion sets, interlock signals, and process stages. If the control permission is RF enabled, the unlocking sequence first verifies the rule version, then refreshes the RF-related interlock sub-states, then confirms the chamber pressure, vacuum status, maintenance status, and process stage status, then clears the mutual exclusion relationships of vacuum breaking permission, incomplete purging, and maintenance release, and then synchronizes the upper-level interlock shadow state. After each unlocking step is completed, the lower-level interlock node returns an event token containing the local interlock input, interlock sub-state, trigger reason code, sampling timestamp, and rule version identifier. The upper-level interlock coordination component determines whether to proceed to the next unlocking step based on time continuity and stage signature consistency. This embodiment avoids the interlock release sequence deviating from the causal graph constraint by using reverse dependency unlocking.

[0046] In this embodiment, the unlocking sequence is not a fixed process, but is generated at runtime by the reverse dependencies in the interlocking causal graph. Different control permissions result in different sets of interlocking signals for the backtracking path and unlocking steps. For process gas enable permission, the unlocking sequence backtracks to the vacuum state, chamber pressure state, maintenance state, and the mutual exclusion relationship with RF enable. For vacuum breaking permission, the unlocking sequence backtracks to RF stop, process gas shutdown, purging state confirmation, and maintenance state confirmation. For maintenance release, the unlocking sequence backtracks to automatic operation permission, chamber safety state, and irreversible blocking edge. When generating the unlocking sequence, the upper-level interlocking coordination component converts each backtracking node into a pending confirmation item. The lower-level interlocking nodes only confirm locally observable pending confirmation items. The upper-level interlocking coordination component is responsible for merging pending confirmation items across nodes. If any pending confirmation item lacks an event token or the event token stage signature is inconsistent, the corresponding prohibition permission or conditional permission is retained. This embodiment uses runtime backtracking to ensure that permission recovery corresponds to the actual locking reason, reducing the problem of insufficient adaptability of fixed release processes to different interlocking scenarios.

[0047] In this embodiment, the bottom-level interlocking nodes can correspond to the vacuum control domain, gas path control domain, radio frequency control domain, purging control domain, and maintenance control domain, respectively. The control domain only represents the logical ownership of interlocking data and control permissions, and does not limit the addition of new hardware structures. The bottom-level interlocking nodes in the vacuum control domain execute the bottom-level real-time assertion table based on the chamber pressure and vacuum status. The bottom-level interlocking nodes in the gas path control domain execute the bottom-level real-time assertion table based on the process gas enable and purging status. The bottom-level interlocking nodes in the radio frequency control domain execute the bottom-level real-time assertion table based on the radio frequency enable and plasma status. The bottom-level interlocking nodes in the maintenance control domain execute the bottom-level real-time assertion table based on the maintenance status and maintenance release permission. After receiving the event tokens from each control domain, the upper-level interlocking coordination component does not directly replace the local prohibition output of the bottom-level interlocking nodes. Instead, it generates the interlocking shadow status, cross-node arbitration record, and permission lock table according to the upper-level state coordination automaton, and then feeds back the permission lock status to the relevant bottom-level interlocking nodes. This embodiment uses logical control domain division to enable each bottom-level interlocking node to maintain its local independent blocking capability, while making cross-domain control permissions subject to the upper-level interlocking causal graph.

[0048] In a preferred embodiment, the interlocking causal graph configuration component supports normalization verification of edge semantics. Normalization verification includes whether there are bidirectional references between mutually exclusive edges within the same process stage, whether the same control permission simultaneously has an allowable edge and an irreversible blocking edge, whether the same pre-confirmation edge is configured with a release state, and whether the same delay release edge is bound to the valid interval of the process stage. If the normalization verification finds that the RF enable permission within the same stage is simultaneously pointed to by an allowable edge and a prohibitive edge, the interlocking causal graph configuration component marks the conflicting edge semantics as unpublished, and the rule compilation component does not compile the edge semantics of the unpublished state into the underlying real-time assertion table or the upper-level state coordination automaton. If the normalization verification finds that the mutually exclusive edge only has a one-way reference, the interlocking causal graph configuration component supplements the reverse reference relationship and marks it as edge semantics to be reviewed. Before the review is completed, the edge semantics to be reviewed are only allowed to generate the hold state in the upper-level state coordination automaton, and are not allowed to generate the underlying permission release assertion. This embodiment reduces the possibility of erroneous edge semantics entering the running rule area through graph semantic verification before publication.

[0049] In a preferred embodiment, when the upper-level interlocking coordination component establishes the interlocking shadow state, it maps each process stage to a state set. The state set includes states such as stage entered, stage pending confirmation, permission pending release, permission locked, permission pending unlock, and stage pending exit. After the event token enters the upper-level state coordination automaton, the automaton selects the state set according to the process stage identifier in the event token, selects the edge semantics according to the trigger cause code, and selects the state transition direction according to the control permission state. If the event token shows that the lower-level interlocking sub-state is prohibited and the corresponding edge semantics in the interlocking causal graph is an irreversible blocking edge in the current stage, the interlocking shadow state transitions to the state that cannot be automatically released within the stage. If the event token shows that the lower-level interlocking sub-state is permitted but there are uncleared mutual exclusion edges in the permission exclusion set, the interlocking shadow state transitions to the permission locked state. If the event token shows that the local pre-confirmation has been completed and there are no incomplete arbitration records, the interlocking shadow state transitions to the permission pending unlock state. This embodiment discloses the generation path of the interlocking shadow state through the state set method, so that the upper-level arbitration result has a definite state transition source.

[0050] In a preferred embodiment, the assertion entries of the underlying real-time assertion table include a stage matching entry, an input matching entry, a permission output entry, a reason code entry, and a lock merging entry. The stage matching entry is used to determine whether the current process stage is within the valid range of edge semantics. The input matching entry is used to determine whether the local interlocking input meets the edge semantic requirements. The permission output entry is used to generate a local permission result that is allowed or prohibited based on the stage matching entry and the input matching entry. The reason code entry is used to write the triggered edge semantic identifier into the event token. The lock merging entry is used to merge the prohibition permission, hold permission, or conditional permission issued by the upper layer into the local permission result. When the stage matching entry is not true, the corresponding assertion entry does not participate in the permission output. When the input matching entry is not true and the edge semantics are a prohibited edge or an irreversible blocking edge, the permission output entry generates a prohibited state. When the lock merging entry reads a prohibited permission, even if the permission output entry generates an allowed state, the underlying interlocking node still outputs a prohibited state. This embodiment exposes the execution method of the underlying real-time assertion table through the assertion entry field, enabling the underlying fast blocking and the upper-layer permission locking to be merged at the same permission output.

[0051] In a preferred embodiment, the event token, cross-node arbitration record, permission lock table, and unlock sequence are associated using a unified identifier chain. This identifier chain consists of a cause-effect graph version identifier, a stage signature, an underlying interlocking node identifier, a control permission identifier, and a trigger reason code. The identifier chain is written when the event token is generated, referenced when the cross-node arbitration record is generated, referenced when the permission lock table is generated, and referenced when the unlock sequence is generated. If a control permission is written to the version isolation area, the version isolation area also stores the same identifier chain and passes it to the unlock sequence after version verification. This identifier chain enables the upper-level interlocking coordination component to trace back from the release action to the edge semantics corresponding to the trigger reason code, and further trace from the edge semantics to the stage node, signal node, and permission node in the interlocking cause-effect graph. This embodiment maintains the same data association relationship between interlocking triggering, arbitration, locking, isolation, and recovery through a unified identifier chain, reducing the possibility of data inconsistencies between multiple tables.

[0052] In a preferred embodiment, in cases of communication delays or abnormal arrival order of event tokens, the upper-layer interlocking coordination component does not directly construct the interlocking shadow state according to the receiving order. Instead, it establishes an intra-stage buffer sequence based on the sampling timestamp and process stage identifier carried by the event token. Within the same process stage, if the sampling timestamps of two event tokens are sequential, the upper-layer interlocking coordination component sorts them according to the sampling timestamps and inputs them into the upper-layer state coordination automaton. If the two event tokens belong to different process stages, the upper-layer interlocking coordination component first checks whether there is an allowed migration relationship in the stage signature, and then decides whether to treat the later-arriving event token of the previous stage as a delayed event. Event tokens marked as delayed events still participate in causal chain matching, but do not directly overwrite the current interlocking shadow state. Instead, they are used to generate historical arbitration records or supplement the evidence chain of the current arbitration record. This embodiment, through intra-stage sorting and cross-stage migration verification, ensures that the interpretation of the upper-layer state is not directly affected by the normal arrival order.

[0053] In a preferred embodiment, for scenarios involving manual maintenance or recovery after a process pause, the maintenance state is treated as a signal node in the interlocking signal layer, and maintenance release is treated as a control permission in the control permission layer. The interlocking causal graph configuration component establishes a permission pre-set set and a permission exclusion set for maintenance release. The permission pre-set set includes maintenance state confirmation, the current process stage being in a recoverable stage, interlocking sub-state refresh completion, and version consistency verification passing. The permission exclusion set includes RF enable not stopped, process gas enable not turned off, vacuum breaking permission mutual exclusion not cleared, and irreversible blocking edge not released. The rule compilation component writes the locally observable conditions for maintenance release into the underlying real-time assertion table of the corresponding underlying interlocking node and writes the cross-node mutual exclusion conditions into the upper-level state coordination automaton. Before maintenance release, the upper-level interlocking coordination component generates an unlocking sequence, and the underlying interlocking node returns event tokens item by item. This embodiment avoids the maintenance release logic from forming an independent judgment chain by incorporating the maintenance state into the same interlocking causal graph.

[0054] In a preferred embodiment, for the interlocking control related to purging and vacuum breaking, the purging state is used for the interlocking signal layer node, and vacuum breaking permission is used for the control permission layer node. The interlocking cause-effect graph configuration component configures a pre-acknowledgment edge between the purging state and vacuum breaking permission, a mutual exclusion edge between RF enable and vacuum breaking permission, and a mutual exclusion edge between process gas enable and vacuum breaking permission. The rule compilation component writes the locally decidable edge semantics between the purging state and vacuum breaking permission into the underlying real-time assertion table, and writes the cross-node mutual exclusion edges between RF enable, process gas enable, and vacuum breaking permission into the upper-level state coordination automaton. When the local pre-condition for vacuum breaking permission is met but the upper-level interlocking coordination component still identifies that RF enable has not been completely deactivated or process gas enable has not been completely shut down, the permission locking table marks vacuum breaking permission as prohibited permission, and the underlying interlocking node maintains prohibited output based on the locking merge item. This embodiment combines the pre-condition and mutual exclusion edges under the same control permission to enable purging confirmation and cross-node mutual exclusion to jointly limit vacuum breaking permission.

[0055] In a preferred embodiment, for the interlocking control related to the RF ignition and deposition stages, RF enable is used to control the permission layer node, while chamber pressure, process gas enable, vacuum state, plasma state, and maintenance state are used to interlock the signal layer node. The interlocking causal graph configuration component configures allow and prohibit edges between chamber pressure and RF enable, pre-confirmation edges between vacuum state and RF enable, prohibition edges between maintenance state and RF enable, and mutually exclusive edges between vacuum breaking permission and RF enable. The rule compilation component writes the edge semantics that can be directly judged in the RF control domain into the underlying real-time assertion table of the corresponding RF bottom-level interlocking node, and writes the pre-confirmation relationships involving the vacuum control domain, gas path control domain, and maintenance control domain into the upper-level state coordination automaton. The upper-level interlocking coordination component uses event tokens to determine whether the chamber pressure state, vacuum state, and maintenance state can all be interpreted as the permission pre-confirmation set for the current RF ignition stage. If any pre-confirmation is missing, a conditional permission or prohibition permission is generated. This embodiment, through a staged RF permission causal chain, ensures that RF enable is no longer determined solely by a single local state.

[0056] In a preferred embodiment, the rule compilation component performs a consistency lookup on the underlying real-time assertion table and the upper-level state coordination automaton. The lookup process starts with each control permission, querying whether there are local assertion entries in the underlying real-time assertion table corresponding to the permission precondition set and permission exclusion set, and then querying whether there are state transition conditions in the upper-level state coordination automaton corresponding to cross-node edge semantics. If a precondition edge is neither within the underlying observable range nor appears in the upper-level state coordination automaton, the rule compilation component marks the precondition edge as a compilation omission and prevents the generation of a runtime activation marker. If a mutually exclusive edge is simultaneously compiled into two unrelated underlying permissible assertions, the rule compilation component marks the corresponding control permission as a conflicting compilation result and requires the regeneration of the underlying assertion increment and the upper-level automaton increment. This embodiment discloses the integrity verification method after rule homology through post-compilation lookup, avoiding the loss of graph constraints when projected as execution rules.

[0057] In this embodiment, the data storage method can adopt a logical division of the running rules area, event area, arbitration area, locking area, isolation area, and recovery area. The running rules area stores the underlying real-time assertion table, the upper-level state coordination automaton, running activation flags, and historical rule indexes. The event area stores the event tokens reported by the underlying interlocking nodes. The arbitration area stores cross-node arbitration records. The locking area stores the permission locking table. The isolation area stores the version isolation record. The recovery area stores the unlocking sequence and the event tokens returned by each unlocking step. The logical areas are associated with each other through a unified identifier chain. The underlying interlocking nodes only need to access the node rule view in the running rules area and the permission locking items related to themselves in the locking area. The upper-level interlocking coordination component is responsible for accessing the event area, arbitration area, locking area, isolation area, and recovery area and generating interlocking shadow states. This embodiment uses logical data area division to isolate the running rules, event evidence, arbitration results, and recovery process while maintaining reference relationships, which facilitates the public disclosure of the internal data processing path of the system.

[0058] In a preferred embodiment, if the underlying interlocking node detects an inconsistency between the rule version identifier and the running activation flag after sampling the local interlocking input, the underlying interlocking node does not execute the permission release assertion corresponding to the new sampled value. Instead, it generates a prohibited or maintained interlocking sub-state based on the activated underlying real-time assertion table in the current running rule area and writes the version inconsistency reason code into the event token. After receiving the event token, the upper-layer interlocking coordination component matches the trigger reason code with the interlocking shadow state. If the matching result shows that the version inconsistency originates from the underlying node rule not being activated, the version consistency verification component writes the relevant control permission into the version isolation area. If the matching result shows that the upper-layer state coordination automaton is not activated, the upper-layer interlocking coordination component maintains the prohibited permission in the permission locking table. This embodiment treats version inconsistency as a coded event, enabling rule version anomalies to enter the same arbitration and unlocking process.

[0059] In a preferred embodiment, when the system switches between recipe stages, the upper-level interlocking coordination component generates a stage switching token. The stage switching token includes an old process stage identifier, a new process stage identifier, a stage signature, allowed migration edge semantics, and a running activation flag. After receiving the stage switching token, the lower-level interlocking node only updates the stage matching item in its lower-level real-time assertion table, without changing the input matching item and reason code item of the assertion item. If a lower-level interlocking node does not acknowledge the stage switching token, the upper-level interlocking coordination component retains the old stage image in the interlocking shadow state and sets the control permission across the old stage and the new stage to conditional permission or prohibition permission. When all relevant lower-level interlocking nodes return event tokens with consistent stage signatures, the upper-level interlocking coordination component then migrates the interlocking shadow state to the new process stage. This embodiment uses the stage switching token to synchronize the process stage boundaries into the lower-level assertions and the upper-level automata, reducing the situation where the same signal is interpreted as different meanings by different layers at the moment of stage switching.

[0060] In a preferred embodiment, when an irreversible blocking edge in the interlocking causal graph is triggered, the lower-level interlocking node writes an irreversible blocking cause code into the event token. The upper-level interlocking coordination component, based on the trigger cause code, migrates the corresponding interlocking shadow state to a state that cannot be automatically released within the phase. The permission locking table marks the corresponding control permission as a prohibited permission and attaches a non-automatically released mark. The non-automatically released mark is not removed by clearing ordinary pre-confirmation items, but can only be converted to a state awaiting manual confirmation or awaiting controlled recovery after the rule version review, interlocking sub-state refresh, permission pre-set confirmation, permission exclusion set clearing, and interlocking shadow state synchronization are completed in the unlocking sequence. If the phase signature of any event token in the unlocking sequence is inconsistent, the non-automatically released mark is retained, and the lower-level interlocking node maintains a prohibited output. This embodiment, through the cooperation of the irreversible blocking edge and the unlocking sequence, ensures that the control permission will not be directly released due to the short-term recovery of the local state after a high-risk interlock is triggered.

[0061] In a preferred embodiment, for delayed release edges in the interlocking causal graph, the rule compilation component compiles the release state of the delayed release edge into a waiting state in the upper-level state coordination automaton, and compiles the observable release state at the lower level into a release assertion entry in the lower-level real-time assertion table. After the lower-level interlocking node satisfies the local release assertion entry, it does not directly delete the interlocking sub-state, but returns the event token that satisfies the release assertion entry to the upper-level interlocking coordination component. The upper-level interlocking coordination component determines whether the corresponding interlocking shadow state is already in a waiting state. If the waiting state is consistent with the event token process stage identifier and there are no uncleared items in the permission exclusion set, the permission will be maintained and converted to a conditional permission or pending unlocking state. If the waiting state is inconsistent with the event token process stage identifier, a cross-node arbitration record with inconsistent process stages will be generated. This embodiment projects the delayed release edge onto the lower-level release assertion and the upper-level waiting state respectively, so that the interlocking release is not determined instantaneously by a single local state.

[0062] In a preferred embodiment, the system's operational data can be compiled into replayable records according to recipe batches and process stages. These replayable records include interlocking causal graph versions, underlying real-time assertion table versions, upper-level state coordination automata versions, event token sequences, interlocking shadow state sequences, cross-node arbitration records, permission lock table change records, version isolation zone change records, and unlock sequence execution records. During replay, the upper-level interlocking coordination component does not read real-time control permissions but instead re-inputs the event token sequences into the upper-level state coordination automata corresponding to the then-current running activation flag according to the sampling timestamp order, and reproduces the interlocking shadow state migration, arbitration record generation, and permission lock table changes. If the replay result is inconsistent with the saved arbitration record, it indicates that the event token, version identifier, or automata version was missing, and the corresponding record needs to be marked as an incomplete chain of evidence. This embodiment enables the causal process of interlocking triggering and permission recovery to be verified by engineering through replayable records.

[0063] In this embodiment, the aforementioned implementation methods collectively form a distributed two-layer security interlocking implementation method, which uses an interlocking causal graph as the rule source, a low-level real-time assertion table as the local execution rule, an upper-level state coordination automaton as the cross-node interpretation rule, an event token as the runtime evidence, a permission lock table and a version isolation zone as the permission control boundary, and an unlock sequence as the recovery path. During device operation, the low-level interlocking nodes form interlocking sub-states using local interlocking inputs and the low-level real-time assertion table, the upper-level interlocking coordination component forms interlocking shadow states using event tokens and the upper-level state coordination automaton, the version consistency verification component confirms the rule homology using rule hashes, stage signatures, causal graph version identifiers, and compilation batch identifiers, and the rule compilation component generates synchronized low-level assertion increments and upper-level automaton increments when rules change. In this embodiment, the same causal rule runs through interlocking configuration, rule compilation, runtime arbitration, permission locking, version isolation, and permission recovery, enabling the plasma-enhanced chemical vapor deposition equipment to maintain consistency between local blocking and cross-stage arbitration under the distributed two-layer interlocking architecture.

Claims

1. A distributed dual-layer safety interlock system for PECVD equipment, characterized in that, This includes an interlocking cause-effect graph configuration component, a rule compilation component, multiple underlying interlocking nodes, an upper-level interlocking coordination component, and a version consistency verification component; The interlocking causal graph configuration component uses chamber pressure, process gas enable, radio frequency enable, plasma state, vacuum state, purging state, maintenance state, and process stage for an interlocking causal graph with directed causal relationships. The rule compilation component generates a low-level real-time assertion table and an upper-level state coordination automaton based on the same interlocking causal graph. The underlying interlocking node outputs the interlocking sub-state and trigger reason code according to the underlying real-time assertion table. The upper-level interlocking coordination component constructs the interlocking shadow state according to the upper-level state coordination automaton and performs consistency arbitration with the interlocking sub-state. The version consistency verification component verifies the correspondence between the rule versions of the underlying real-time assertion table and the upper-level state coordination automaton.

2. The distributed dual-layer safety interlocking system for PECVD equipment according to claim 1, characterized in that, The interlocking cause-effect graph configuration component sets up a process stage layer, an interlocking signal layer, a control permission layer, and a hazardous state layer in the interlocking cause-effect graph. The process stage layer includes at least the stages of vacuuming, ventilation, RF ignition, deposition, RF shutdown, purging, vacuum breaking, and maintenance. The interlocking signal layer and the control permission layer are configured with edge semantics of allow, prohibit, mutual exclusion, pre-acknowledgment, delay release, and irreversible blocking, and each edge semantic is bound to the effective range, pre-state, and release state of the corresponding process stage.

3. A distributed dual-layer safety interlocking system for PECVD equipment according to claim 2, characterized in that, The rule compilation component performs bidirectional compilation processing on the interlocking causal graph, compiling the edge semantics, process stage effective intervals, and control permission conditions related to a single underlying interlocking node into a lower-level real-time assertion table, and compiling the mutual exclusion relationships, pre-acknowledgment relationships, and delay release relationships spanning two or more underlying interlocking nodes into an upper-level state coordination automaton. The component also writes the same causal graph version identifier, stage signature, rule hash, and compilation batch identifier into the lower-level real-time assertion table and the upper-level state coordination automaton.

4. A distributed dual-layer safety interlocking system for PECVD equipment according to claim 3, characterized in that, When each underlying interlocking node executes the underlying real-time assertion table, it encapsulates the local interlocking input, process stage identifier, control permission status, interlocking sub-state, trigger reason code, sampling timestamp, and rule version identifier into an event token. The upper-level interlocking coordination component sorts the event tokens from multiple lower-level interlocking nodes according to the sampling timestamp and the process stage identifier, generates interlocking shadow states based on the upper-level state coordination automaton, and establishes a mapping record between the interlocking shadow states and the interlocking sub-states in the corresponding event tokens.

5. A distributed dual-layer safety interlocking system for PECVD equipment according to claim 4, characterized in that, The interlocking causal graph configuration component establishes a permission prerequisite set and a permission exclusion set for each control permission. The permission prerequisite set consists of edge semantics corresponding to the chamber pressure, vacuum state, purging state, and maintenance state that must be satisfied before entering the current process stage. The permission exclusion set consists of edge semantics corresponding to the prohibition of process gas enable, radio frequency enable, and vacuum breaking permission that are simultaneously satisfied with the current control permission. The permission prerequisite set and the permission exclusion set are used as graph constraint segments that can be recognized by the rule compilation component.

6. A distributed dual-layer safety interlocking system for PECVD equipment according to claim 5, characterized in that, When the rule compilation component changes the rules of the interlocking causal graph, it forms incremental compilation fragments for the semantics of the changed edge and its adjacent process stage nodes, interlocking signal nodes and control permission nodes, and synchronously converts the incremental compilation fragments into low-level assertion increments and high-level automaton increments. The version consistency verification component generates a runtime activation flag after the underlying assertion increment and the upper-layer automaton increment have the same rule hash, stage signature and compilation batch identifier. The runtime activation flag is written to the relevant underlying interlocking node and upper-layer interlocking coordination component.

7. A distributed dual-layer safety interlocking system for PECVD equipment according to claim 6, characterized in that, The upper-layer interlocking coordination component performs causal chain matching processing on the event token, associates the local interlocking input corresponding to the trigger cause code with the expected dangerous state node of the same process stage in the interlocking shadow state, and generates a cross-node arbitration record when the association result shows that the process stage is inconsistent, the control permission is mutually exclusive, the pre-confirmation is missing, or the delayed release is not completed. The cross-node arbitration record includes conflict edge semantics, conflict control permission, the identifier of the underlying interlocking node involved, and the sampling timestamp.

8. A distributed dual-layer safety interlocking system for PECVD equipment according to claim 7, characterized in that, The upper-level interlocking coordination component generates a permission lock table based on the cross-node arbitration record. The permission lock table marks conflict control permissions in RF enable, process gas enable, vacuum breaking permission, purging permission, and maintenance release as prohibited permission, maintained permission, or conditional permission. The permission lock table is bound to the interlocking sub-state of the corresponding lower-level interlocking node. The lower-level interlocking node maintains prohibited output when the local interlocking input satisfies the lower-level real-time assertion table and prohibited permission exists. When conditional permission exists, it reads the pre-acknowledgment items contained in the conditional permission.

9. A distributed dual-layer safety interlocking system for PECVD equipment according to claim 8, characterized in that, Before receiving the license locking table, the version consistency verification component performs joint verification on the rule version identifier, cause-effect graph version identifier, stage signature, rule hash, and compilation batch identifier of the underlying interlocking nodes involved. When any identifier is inconsistent with the run activation flag, the corresponding control permission is written to the version isolation zone, and the version isolation zone is merged with the prohibited permissions in the permission lock table; When all identifiers are consistent and there are no incomplete conflict edge semantics in the cross-node arbitration record, the pre-acknowledgment item in the conditional permission is retained.

10. A distributed dual-layer safety interlocking system for PECVD equipment according to claim 9, characterized in that, Before releasing the control permissions in the version isolation zone or permission locking table, the upper-layer interlocking coordination component generates an unlocking sequence according to the reverse dependency relationship in the interlocking causal graph. The unlocking sequence includes rule version review, interlocking sub-state refresh, permission pre-set confirmation, permission exclusion set clearing, and interlocking shadow state synchronization in sequence. Each underlying interlocking node returns the event token for the corresponding unlocking step to the upper-level interlocking coordination component. The upper-level interlocking coordination component deletes the corresponding prohibited permission or conditional permission when the timestamps of the event tokens for adjacent unlocking steps are consecutive and the stage signatures are consistent.

Images