A heterogeneous device attestation evidence normalization trigger admission method and system

Abstract

The application relates to the technical field of multi-device trigger access control, and provides a heterogeneous device confirmation evidence normalization trigger access method and system, which comprises the following steps: obtaining confirmation evidence and a security weight returned by a heterogeneous device for a preparation command; mapping the confirmation evidence to a confirmation level based on evidence depth and generating a confirmation result; when there is explicit failure evidence, the result is determined as failure; when there is no explicit failure evidence and the highest confirmation level does not reach a preset minimum confirmation level or missing resolvable confirmation evidence, the result is determined as unconfirmed; inputting the confirmation result and the security weight into an access decision mapping output trigger access state, wherein the security weight is used for determining the trigger access state without changing the confirmation result; and outputting a trigger instruction or a trigger enable signal based on the trigger access state through a trigger control interface. The application realizes unified normalization of confirmation evidence of heterogeneous devices and differential accurate trigger access control based on the security weight.

Description

Technical Field

[0001] This application relates to the field of multi-device trigger access control technology, and in particular to a method and system for triggering access by normalizing heterogeneous device confirmation evidence. Background Technology

[0002] In complex experimental systems such as neutral beam injection devices, a single trigger typically requires the coordinated operation of multiple heterogeneous devices, including a central control system, power supply equipment, trigger controller, data acquisition equipment, and safety interlocking devices. These devices often interact using PLC Modbus TCP, serial Modbus RTU, dedicated trigger protocols, or other communication protocols. The feedback depth provided by devices using different protocols varies significantly. Some devices can only report successful communication writes, some can return echo frames or acknowledgment frames, while others can provide multi-dimensional information such as parameter readback, status bits, fault bits, and interlock bits. Although existing experimental control systems can perform basic triggering, data acquisition, and clock synchronization functions, the access determination stage before the trigger command is issued usually relies on a relatively simple communication result judgment mechanism.

[0003] In actual single-gun triggering preparation, due to the asymmetry of feedback capabilities of heterogeneous devices, the control system easily equates successful writes at the communication layer, serial port byte transmission, or incomplete confirmation frames directly with the completion of physical preparation of the device. Especially in critical scenarios involving high-voltage power supplies, arc power supplies, and safety interlocks, if only successful communication is used as the triggering admission criterion, the system may still misjudge the device as ready and issue a trigger command when the device's internal parameters have not been actually updated, the status bit is not ready, or the interlocking conditions are not met but the communication link is normal. This approach of confusing communication layer responses with the physical execution status of the device leads to the inability to verify the pre-trigger preparation status, difficulty in anomaly localization, and the inability to implement differentiated admission control based on the different degrees of impact of the device on personal safety, equipment protection, and experimental effectiveness. This results in technical problems such as safety-critical equipment being mistakenly released when there is insufficient evidence, or non-critical equipment being excessively blocked due to minor anomalies. Summary of the Invention

[0004] To address the problems of existing technologies that misjudge successful communication write as successful device physical preparation and lack differentiated access control based on security weights, this application proposes a method and system for triggering access control by normalizing heterogeneous device confirmation evidence. This method achieves unified normalization processing of heterogeneous device confirmation evidence and precise triggering access control based on security weights.

[0005] To achieve the above objectives, this application adopts the following technical solution: Firstly, a method for triggering admission by normalizing confirmation evidence for heterogeneous devices includes: acquiring confirmation evidence returned by heterogeneous devices in response to a preparatory command, and security weights of the heterogeneous devices that write responses; mapping the write response confirmation evidence to a confirmation level based on evidence depth, and generating a confirmation result; determining the write response confirmation result as a failure when there is explicit failure evidence indicating device confirmation failure; defining the write response confirmation result as unconfirmed when there is no explicit failure evidence for the write response and the highest write response confirmation level does not reach the preset minimum confirmation level, or when resolvable confirmation evidence is missing; mapping the write response confirmation result and the write response security weight into an admission decision, and outputting a trigger admission state; the write response security weight is used to determine the write response trigger admission state without changing the write response confirmation result; and controlling the output of a trigger command or trigger enable signal through a trigger control interface based on the write response trigger admission state.

[0006] The above scheme achieves precise control over triggering access by mapping confirmed evidence to a confirmation level, independently defining the unconfirmed state, and combining security weights for access decisions.

[0007] In conjunction with the first aspect mentioned above, in one possible implementation, the process of mapping write response confirmation evidence to confirmation levels based on evidence depth specifically includes: write response confirmation levels include a first confirmation level, a second confirmation level, a third confirmation level, and a fourth confirmation level; the first confirmation level of the write response corresponds to successful communication write or a write response; the second confirmation level of the write response corresponds to write echo or confirmation frame matching; the third confirmation level of the write response corresponds to parameter readback results meeting a preset tolerance; the fourth confirmation level of the write response corresponds to status bits, fault bits, or interlock bits meeting preset security conditions; explicit failure evidence of the write response includes at least one of communication write failure, verification failure, parameter readback exceeding the preset tolerance of the write response, status bits not ready, fault bits valid, or interlock blocking; when explicit failure evidence of the write response exists, the write response confirmation result is determined to be a failure, and explicit failure evidence of the write response takes precedence over any successful write or echo matching evidence.

[0008] In conjunction with the first aspect mentioned above, in one possible implementation, the write response security weight is used to determine the write response trigger admission state without changing the write response confirmation result. Specifically, this includes: determining the security criticality level of the heterogeneous write response device based on the write response security weight; the write response security criticality level does not change the write response confirmation result, but is only used to determine the output of the write response trigger admission state; the write response admission decision mapping takes the write response security criticality level as the first dimension and the confirmation result and the type of non-confirmation reason as the second dimension; the write response trigger admission state includes an allowed trigger state, a blocked trigger state, a manual review state, or an allowed state with warning. When the write response security criticality level reaches the preset high level and the write response confirmation result is failure or unconfirmed, the write response admission decision mapping outputs a write response prevention trigger status; when the write response security criticality level is the preset low level and the write response confirmation result is unconfirmed, the write response admission decision mapping outputs a write response warning-enabled status or a write response manual review status, depending on the type of unconfirmed write response reason; when the write response security criticality level is the preset intermediate level and the write response confirmation result is unconfirmed, the write response admission decision mapping outputs a write response manual review status or a write response prevention trigger status, depending on the type of unconfirmed write response reason.

[0009] In conjunction with the first aspect mentioned above, in one possible implementation, the process of obtaining confirmation evidence returned by heterogeneous devices for a preparatory command in the write response specifically includes: performing frame filtering on the write response confirmation evidence, whereby the write response frame filtering includes matching and verifying the source address, command identifier, reception time window, and protocol integrity; performing deduplication processing on the confirmation evidence that passes the write response frame filtering based on a deduplication key composed of device identifier, command identifier, task identifier, channel number, and command sequence number; performing retry or waiting under confirmation timeout conditions, whereby the write response confirmation timeout conditions are determined based on polling period, link latency, historical response statistics, and safety margin; and defining the write response confirmation result as unconfirmed when the write response confirmation timeout conditions are exceeded and there is no explicit evidence of write response failure.

[0010] In conjunction with the first aspect above, in one possible implementation, when the write response trigger admission status is the write response manual review status, it further includes: responding to the write response admission decision mapping outputting the write response manual review status, keeping the write response trigger control interface prohibited from outputting write response trigger commands or write response trigger enable signals; receiving the review results submitted by an authorized operator, writing the write response review results as supplementary basis into the confirmation record, and triggering the write response admission decision mapping to re-determine; wherein, the write response review results do not directly replace the write response confirmation level, and when the write response review results are review rejection or review timeout, the write response blocking trigger status is output.

[0011] In conjunction with the first aspect mentioned above, in one possible implementation, the process of receiving the review result submitted by an authorized operator in the write response includes: determining the required permission level and review timeout limit based on the security critical level of the write response; verifying the identity and permissions of the write response operator; and when the verification fails or no valid response is received within the write response review timeout limit, the write response review result is not considered a valid basis, and a write response blocking trigger status is output.

[0012] In conjunction with the first aspect mentioned above, in one possible implementation, before obtaining the confirmation evidence returned by the heterogeneous device in response to the preparatory command, the write response further includes: freezing the configuration snapshot when the triggering task enters the configuration frozen state; the write response configuration snapshot includes the trigger configuration, confirmation protocol, version of the write response admission decision mapping, device security criticality level, device dependencies, and protocol configuration; after the write response configuration snapshot is frozen, in response to receiving a configuration modification request, a new configuration snapshot with a parent snapshot identifier and modification reason is generated; wherein, the original configuration snapshot and its associated collected confirmation records are retained as historical audit records, and the collected confirmation records of the write response are not migrated as valid trigger admission basis under the new configuration snapshot of the write response.

[0013] In conjunction with the first aspect mentioned above, in one possible implementation, the process of obtaining confirmation evidence returned by heterogeneous devices in response to a preparatory command includes: obtaining the device dependencies between heterogeneous devices in the write response and constructing a directed dependency graph; based on the directed dependency graph of the write response, collecting write response confirmation evidence in parallel for heterogeneous devices that do not have write response device dependencies, and collecting write response confirmation evidence in groups according to topological order for heterogeneous devices that have write response device dependencies; when the write response confirmation result of the preceding device is a failure and the write response security weight of the preceding device reaches a preset blocking level, skipping the subsequent trigger preparation steps that depend on the preceding device, and outputting the write response trigger admission state as a blocked trigger state.

[0014] Secondly, this application also provides a heterogeneous device confirmation evidence normalization trigger access system, which specifically includes: a central control computer configured to execute a heterogeneous device confirmation evidence normalization trigger access method as described above for writing responses, used to generate unified device confirmation records and output trigger access status; a device communication interface configured to communicate with heterogeneous devices to obtain confirmation evidence; and a trigger control interface configured to control the output of trigger commands or trigger enable signals based on the write response trigger access status.

[0015] The aforementioned system integrates the normalization of confirmation evidence, the calculation of access decision mapping, and the physical output of trigger commands or trigger enable signals into a unified system architecture through the coordinated operation of the central control computer, equipment communication interface, and trigger control interface. This achieves a complete closed loop from evidence collection to access decision and then to physical control, ensuring that the triggered access state can be directly converted into physical control actions, effectively preventing false triggering when the equipment is not actually ready.

[0016] In conjunction with the second aspect above, in one possible implementation, the write response system is deployed in an environment that includes a low-voltage control area and a high-voltage test area, and the low-voltage control area and the high-voltage test area are connected by an isolation link; the write response isolation link includes at least one of an optical fiber trigger link, a high-speed network optical fiber link, or an electrical isolation link; the constraint parameters of the write response isolation link are used to determine the reception time window, dynamic timeout value, or failure evidence determination rules of the write response device communication interface.

[0017] The above implementation deploys the system in an environment isolated from the low-voltage control area and the high-voltage test area. It utilizes fiber optic trigger links, high-speed network fiber optic links, or electrical isolation links to achieve physical isolation between the control side and the test side, ensuring the safety of operation in the low-voltage control area and the anti-interference capability of signal transmission. At the same time, the constraint parameters of the isolation link are directly mapped to the basis for determining the receiving time window, dynamic timeout value, or failure evidence judgment rules of the device communication interface. This allows the collection and judgment of confirmation evidence to adapt to the transmission characteristics of different isolation links, improving the accuracy and timeliness of confirmation evidence collection while ensuring safety.

[0018] This application provides a method and system for triggering admission by normalizing confirmation evidence for heterogeneous devices. It can obtain the confirmation evidence and security weight returned by heterogeneous devices in response to preparatory commands, and map the confirmation evidence from multiple heterogeneous sources to a standardized confirmation level by utilizing the evidence depth. When there is clear failure evidence, it is preferentially judged as failure. When there is no failure evidence but the evidence depth is insufficient or missing, it is independently defined as an unconfirmed state. Thus, at the data level, the successful writing of the communication layer and the actual preparation state of the device physical layer are strictly decoupled, avoiding the risk of misjudging the device as ready based solely on successful communication. Furthermore, by inputting the confirmation result and security weight into the access decision mapping, the security weight serves only as a dimension for determining the trigger access status without altering the objective confirmation result. This ensures both the objectivity and consistency of equipment status determination and enables differentiated handling based on the equipment's safety criticality. It ensures that safety-critical equipment is automatically blocked from triggering when evidence is insufficient or fails, while non-critical equipment can enter the review or warning-enabled process in a controllable unconfirmed state. Finally, the trigger control interface directly controls the output of trigger commands or enable signals, forming a complete closed loop from evidence normalization to differentiated access and then to physical control. This effectively solves the technical problems of inaccurate trigger access determination and one-size-fits-all security strategies in complex heterogeneous environments. Attached Figure Description

[0019] Figure 1 A flowchart illustrating a method for triggering admission by normalizing evidence for heterogeneous device verification, provided in an embodiment of this application; Figure 2 This is a schematic diagram of the confirmation level mapping and failure priority determination rules in a heterogeneous device confirmation evidence normalization trigger admission method provided in an embodiment of this application; Figure 3 This is a schematic diagram of a security weight differential admission decision matrix in a heterogeneous device confirmation evidence normalization trigger admission method provided in an embodiment of this application; Figure 4 This is a schematic diagram of the confirmation evidence collection and preprocessing process in a heterogeneous device confirmation evidence normalization trigger admission method provided in an embodiment of this application; Figure 5 This is a schematic diagram of the manual review status processing flow in a heterogeneous device verification evidence normalization trigger admission method provided in an embodiment of this application; Figure 6 This application provides a schematic diagram illustrating the configuration snapshot freezing and version management process for a heterogeneous device confirmation evidence normalization trigger admission method. Figure 7 A schematic diagram of the dependency-based directed graph grouping acquisition process in a heterogeneous device verification evidence normalization trigger admission method provided in an embodiment of this application; Figure 8A schematic diagram illustrating the system composition and confirmation evidence flow of a heterogeneous device confirmation evidence normalization trigger access system provided in this application embodiment; Figure 9 This is a schematic diagram of the deployment environment and isolated link constraint mapping of a heterogeneous device confirmation evidence normalization trigger admission system provided in an embodiment of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein in the specification of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0022] Example 1: like Figure 1 As shown, this embodiment provides a method for triggering access by normalizing evidence for heterogeneous devices. This method serves as the foundational process of the technical solution in this application and aims to solve the problem of misjudgment of trigger access caused by differences in the feedback capabilities of devices in complex experimental setups. The method in this embodiment mainly includes four core stages: evidence acquisition, normalization processing, access decision-making, and trigger control. By establishing a ternary state boundary and safety weight decoupling mechanism, it achieves accurate determination and differentiated control of the preparation state of heterogeneous devices. Step S100: Obtain the confirmation evidence returned by the heterogeneous device in response to the preparatory command, as well as the security weight of the heterogeneous device.

[0023] Among them, confirmation evidence refers to the set of multi-dimensional information that heterogeneous devices provide in response to preparatory commands before triggering, which can characterize their actual preparation status. It includes not only the write success response at the communication layer, but also deep physical feedback such as write echo, confirmation frame matching, parameter readback value, status bit, fault bit and interlock bit.

[0024] Safety weight is a technical parameter used to quantify the impact of the heterogeneous device on personal safety, equipment protection, experimental effectiveness, and triggering link integrity in a specific triggering task. Its value or level is statically given by the preset configuration or dynamically loaded according to the experimental mode.

[0025] In some implementations, the central control computer issues preliminary commands to each heterogeneous device through the confirmation protocol generation module, and collects the raw feedback data returned by each device in real time as confirmation evidence through various device communication interfaces such as PLC communication interface, serial communication interface, safety interlock input interface and acquisition device communication interface.

[0026] For example, for PLC power supply equipment, confirmation evidence may include Modbus TCP write responses, target current parameter readback values, and ready status bits; For RTU arc power supplies, confirmatory evidence may include serial port write echo frames and device status frames; For safety interlocking equipment, the confirmation evidence is the interlock permission signal or the emergency stop status.

[0027] Meanwhile, the system reads the security weights corresponding to each device from the configuration snapshot. These weights have been solidified during the configuration freeze phase to ensure the consistency of the judgment benchmark within this triggered task.

[0028] It should be noted that this step expands the definition of confirmation evidence from a single successful communication to multi-dimensional information including physical state, and obtains security weight as an independent input parameter. This lays a data foundation for distinguishing between successful communication and physical readiness and implementing differentiated access, thus avoiding the technical problem of blindly determining device readiness based solely on communication layer response.

[0029] Step S200: Map the confirmation evidence to a confirmation level based on the evidence depth and generate a confirmation result; when there is clear failure evidence indicating that the device has failed to confirm, the confirmation result is determined to be a failure; when there is no clear failure evidence and the highest confirmation level has not reached the preset minimum confirmation level, or when there is no resolvable confirmation evidence, the confirmation result is defined as unconfirmed.

[0030] Among them, the depth of evidence refers to the level of probative value of evidence in confirming the actual physical readiness of the equipment, which is usually increased in order from the communication layer to the physical layer.

[0031] Confirmation levels are standardized hierarchical identifiers based on the depth of evidence.

[0032] Unconfirmed is a final state independent of success and failure. It specifically refers to a state in which the equipment cannot be confirmed as ready due to insufficient or missing evidence in the absence of clear evidence of failure, rather than a temporary transitional state between success and failure.

[0033] In some implementations, the confirmation evidence normalization module first verifies and classifies the collected confirmation evidence to construct a set of valid evidence and a set of failed evidence.

[0034] If the set of failure evidence is not empty (such as clear failure evidence such as detected communication write failure, parameter out of bounds, fault bit validity, or interlock blocking), the confirmation result is directly judged as failure, and this failure judgment takes precedence over any write success or echo matching evidence.

[0035] If the set of failed evidence is empty, then the confirmation level with the highest evidence depth is extracted from the set of valid evidence as the actual confirmation level, and it is compared with the minimum confirmation level preset in the confirmation protocol: If the actual confirmation level reaches or exceeds the minimum confirmation level, the confirmation result is successful; If the actual confirmation level is lower than the minimum confirmation level, or if no resolvable confirmation evidence is obtained at all (such as not receiving a receipt within the time limit), the confirmation result will be defined as unconfirmed.

[0036] For example, if a device only returns a write response (corresponding to the first level of acknowledgment), but the acknowledgment protocol requires that the parameters be consistent upon readback (corresponding to the third level of acknowledgment), then even if the write response is successful, the acknowledgment result is still defined as unacknowledgment, rather than success.

[0037] It should be noted that this step, by establishing unconfirmed status as an independent third type of technical state, resolves the binary opposition in existing technologies where insufficient evidence is misjudged as success (leading to risk triggering) or misjudged as failure (leading to excessive blocking). This ternary state boundary design enables the system to accurately distinguish between two fundamentally different operating conditions: a definite equipment failure and an unclear equipment status, providing accurate logical input for subsequent differentiated handling based on safety weights.

[0038] Step S300: Map the confirmation result and security weight into the admission decision and output the trigger admission state; the security weight is used to determine the trigger admission state without changing the confirmation result.

[0039] The access decision mapping is a differentiated decision model with the safety criticality level (determined by safety weight) as the first dimension and the confirmation result and the type of non-confirmation reason as the second dimension. Its output includes four trigger access states: allow triggering, prevent triggering, manual review, or allow with warning.

[0040] The security weights only apply to this mapping process to determine the final handling strategy, without reverse-correcting or overwriting the objective confirmation results generated in step S200. This is the principle of decoupling security weights from confirmation results.

[0041] In some implementations, the safety criticality admission matrix receives unified device confirmation records (including confirmation results, actual confirmation levels, reasons for non-confirmation, etc.) and device safety weights from the confirmation evidence normalization module. In this case, the system first determines the device's safety criticality level (e.g., first to fourth safety criticality levels) based on the safety weights, then locates the corresponding row (safety level) and column (confirmation status combination) in the admission decision mapping matrix, and reads the pre-configured trigger admission status value within the cell.

[0042] For example, for the fourth safety critical level (safety critical equipment), if the confirmation result is failure or unconfirmed, the matrix directly outputs a prevent triggering status; while for the first safety critical level (non-safety critical equipment), if the confirmation result is unconfirmed and the reason is the lack of non-critical evidence, the matrix may output a warning-enabled permitted status.

[0043] Throughout the process, regardless of how the security weights are configured, the unacknowledged or failed result generated in step S200 remains unchanged; only the system's response to the result changes.

[0044] It should be noted that this step, through decoupling design, ensures both the objectivity and consistency of equipment status determination (avoiding contradictory factual determinations for the same physical phenomenon due to differences in equipment importance) and the flexible adaptation of safety strategies (allowing for a lenient approach to minor anomalies in non-critical equipment, while adopting a zero-tolerance approach to any uncertainty in critical equipment). This mechanism effectively avoids the dilemma of traditional solutions that either indiscriminately block all anomalies to ensure safety or ignore critical risks to ensure efficiency.

[0045] Step S400: Based on the trigger admission state, control the output of the trigger command or trigger enable signal through the trigger control interface.

[0046] Among them, the trigger control interface is the physical signal channel connecting the central control computer and the high-voltage test area trigger controller. Its output state is directly controlled by the trigger access state output by the access decision mapping, rather than being determined solely by the logical flag bits at the software level.

[0047] The trigger command or trigger enable signal is the hardware-level control signal that actually starts the high-voltage pulse or energy output.

[0048] In some implementations, when the admission decision mapping output allows triggering or is in a warning-enabled state, the trigger control interface releases the signal block, allowing the trigger command issued by the master control / HMI to be passed through to the trigger controller, or allows the system to proceed after attaching an unacknowledged flag log when the system is in a warning-enabled state.

[0049] When the output prevents the trigger state, the trigger control interface forcibly cuts off the trigger signal path or keeps the enable signal invalid at the hardware level, regardless of whether the host computer software issues a trigger request. When the manual review status is output, the trigger control interface remains in a prohibited output state until a valid review pass result is received and the matrix re-determines the status to be allowed, at which point the output can be unlocked.

[0050] It should be understood that although this embodiment shows that the trigger control interface is located inside the central control computer, in other implementations, the interface can also be an independent safety relay module or FPGA logic gate circuit, as long as it can perform physical-level signal on / off control according to the admission state.

[0051] It should be noted that this step transforms the abstract access decision into concrete physical control actions, forming a complete security closed loop from evidence collection, state normalization, differentiated decision-making to hardware execution. This hard-connection control mechanism ensures that even in the event of a software crash or logical error on the host computer, the trigger control interface can still maintain the security barrier based on the last valid access state, eliminating the risk of accidental triggering due to software misjudgment.

[0052] Based on the above technical solution, this embodiment establishes a three-dimensional state boundary of success, failure, and unconfirmed by constructing a multi-dimensional acquisition and deep mapping mechanism for confirmation evidence. In particular, defining unconfirmed as an independent final state eliminates the cognitive misconception of equating successful communication with physical readiness. Simultaneously, through the decoupling design of security weights and confirmation results, the access decision mapping can implement differentiated trigger control strategies based on the safety criticality of the equipment without altering objective facts. This structural design not only solves the misjudgment problem caused by the asymmetry of feedback capabilities of heterogeneous devices but also improves the experimental fault tolerance rate of non-critical equipment while ensuring a safety baseline. Furthermore, the physical-level execution of the trigger control interface ensures the enforceability and reliability of the access decision.

[0053] Example 2: like Figure 2 As shown, this embodiment, based on embodiment 1, further specifies the process of mapping confirmation evidence to confirmation level based on evidence depth. By constructing a four-level progressive confirmation level system and clarifying the priority rule for failed evidence, it solves the problem of misjudgment of status caused by differences in the feedback capabilities of heterogeneous devices.

[0054] Step S201: The confirmation levels include a first confirmation level, a second confirmation level, a third confirmation level, and a fourth confirmation level, which are progressively higher. The first confirmation level corresponds to a successful communication write or a write response. The second confirmation level corresponds to a write echo or a matching confirmation frame. The third confirmation level corresponds to a parameter readback result that meets the preset tolerance. The fourth confirmation level corresponds to a status bit, fault bit, or interlock bit that meets the preset safety conditions.

[0055] In this context, the depth of evidence refers to the level of probative value of evidence confirming the actual physical readiness of the equipment. The classification is not based on the amount of data or the complexity of the communication protocol, but rather on whether the evidence can directly represent that the equipment is in a physically ready state that can be safely triggered. Furthermore, the first to fourth levels of confirmation constitute a ladder of evidentiary strength that penetrates progressively from the communication level to the physical level; the higher the level, the more accurate the system's grasp of the equipment's true state.

[0056] In some implementations, the confirmation evidence normalization module, upon receiving the original confirmation evidence, first identifies the evidence type and maps it to the corresponding confirmation level. Specifically, if only a Modbus TCP write response message is received from the PLC power supply device, indicating that the instruction has been delivered to the device's network card or protocol stack, but the internal execution status of the device is unknown, it is marked as the first confirmation level. If a write echo frame is received from the RTU arc power supply, or an acknowledgment frame returned by the trigger controller that matches the sequence number of the issued command, it indicates that the device firmware has parsed and received the instruction, and it is then marked as the second acknowledgment level. If the target current, pulse width and other parameters of the device are read back and the value falls within the absolute or relative tolerance range preset by the confirmation protocol, it indicates that the internal settings of the device have been updated correctly, and it is marked as the third confirmation level. If the device's ready position, fault position reset, and emergency stop signal are detected as invalid, but the safety interlock permission signal is valid, it indicates that the device has fully met the triggering conditions at the physical level, and it is then marked as the fourth confirmation level.

[0057] When generating a unified device confirmation record, if the same device returns multiple types of valid evidence for the same preparatory command, the system automatically selects the level with the highest evidence depth as the actual confirmation level. For example, if there is a write response (level 1), consistent parameter readback (level 3), and normal status bit (level 4) at the same time, the actual confirmation level is determined to be the fourth confirmation level.

[0058] It should be noted that this hierarchical mapping mechanism transforms the previously chaotic and protocol-independent feedback from heterogeneous devices into a unified, standardized metric, enabling subsequent admission decisions to be based on consistent evidence quality rather than device model. In particular, explicitly defining successful communication write as the lowest first confirmation level technically negates the traditional practice of equating it with device readiness, providing a precise logical benchmark for distinguishing between command sent and device ready.

[0059] Step S202: Clarify the evidence of failure, including at least one of the following: communication write failure, verification failure, parameter readback exceeding the preset tolerance, status bit not ready, fault bit valid, or interlocking blockage.

[0060] Clear evidence of failure refers to negative feedback that can directly and unambiguously indicate that the equipment is in an untriggerable state or that there is a safety hazard. The essential difference between clear evidence of failure and unconfirmed state is that unconfirmed state only means that it is unknown whether it is ready, while clear evidence of failure means that it is certain that it is not ready or that there is a risk. Therefore, its judgment is absolute and exclusive.

[0061] In some implementations, the system performs a negative feature scan on all received confirmation evidence during the frame filtering and validity verification phase. Specifically, when communication write failures or verification failures are detected, such as a timeout error code returned by the communication link, a CRC check failure, or a function code anomaly, failure evidence is generated directly.

[0062] When the parameter readback value exceeds the absolute tolerance, relative tolerance, or discrete allowable set configured in the confirmation protocol, evidence of parameter out-of-bounds failure is generated. Evidence of physical status failure is generated when the polled status register displays an unprepared, busy, or error flag, or when a fault bit or emergency stop bit is set, or when a safety interlock device returns a blocking signal.

[0063] Once these failure evidences are identified, they are stored in the failure evidence set and recorded in detail in the failure reason field of the unified device confirmation record, including the specific error code, abnormal parameter value and occurrence timestamp.

[0064] It should be noted that by uniformly defining the above-mentioned abnormal situations from multiple dimensions as explicit evidence of failure, this embodiment constructs a comprehensive security monitoring network covering the communication layer, protocol layer, parameter layer, and physical layer. This definition method avoids the limitations of relying solely on a single indicator (such as only looking at communication connectivity) to judge device health, ensuring that any substantial fault at any level can be captured by the system and used as the basis for preventing triggering.

[0065] Step S203: When there is clear evidence of failure, the result is confirmed as a failure, and clear evidence of failure takes precedence over any successful write or echo matching evidence.

[0066] The failure priority rule means that in the evidence normalization judgment logic, the failure evidence set has a higher priority than the valid evidence set. That is, as long as the failure evidence set is not empty, the system immediately terminates the extraction and merging process of the highest confirmation level in the valid evidence set and directly locks the confirmation result as failure, regardless of whether there is any one or more valid evidence of the first to fourth confirmation levels at the same time.

[0067] In some implementations, the confirmation evidence normalization module follows a logic of first checking for failures and then determining the level when performing normalization judgment. Specifically, the system first checks whether the set of failed evidence corresponding to the current preparatory command is empty; if the set of failed evidence is not empty, the confirmation result is directly set to failure, and the evidence in the set of failed evidence is written into the record as the actual confirmation basis. At this time, even if the set of valid evidence contains evidence of consistent parameter readback (third confirmation level) or even evidence of normal status bit (fourth confirmation level), it will be ignored by the system or only stored as auxiliary information, and will not participate in the generation of the confirmation result.

[0068] For example, during a trigger preparation, the RTU arc power supply returns a write echo frame that perfectly matches the preparation command (corresponding to the second confirmation level), but the subsequent status frame feedback includes an "over-temperature protection" error code (corresponding to explicit failure evidence). According to the failure priority rule of this step, the system will ignore the positive evidence of echo frame matching and directly determine the confirmation result of the device as a failure, rather than misjudging it as success or unconfirmed due to echo matching.

[0069] For example, if the PLC power supply returns a successful write response (first level of confirmation) and the parameter readback value is within the tolerance (third level of confirmation), but the status bit shows "main contactor not engaged" (clear evidence of failure), the system will still determine the result as a failure based on the failure priority rule.

[0070] It should be noted that this design prevents the communication layer from successfully misleading the physical layer into being ready, thus mitigating the security risks in existing technologies caused by partial success evidence (such as write responses and echoes) masking underlying faults (such as abnormal states or protection actions). Technically, this is equivalent to setting a hardware-level emergency stop logic gate in the evidence merging algorithm; if any security-related signal is false, the output is false. This establishes a security defense depth in complex heterogeneous device collaborative environments, ensuring the conservatism and reliability of the trigger access decision.

[0071] Based on the above technical solution, this embodiment constructs a four-level progressive confirmation level system to transform the multi-dimensional feedback from heterogeneous devices into a standardized measure of evidence depth. Combined with a failure-priority rule, it establishes the dominant role of negative evidence in the normalization process. This design not only refines the specific execution logic of evidence mapping in Embodiment 1 but also eliminates cognitive blind spots caused by incomplete or partially successful device feedback information through algorithmic constraints. It effectively prevents normal responses at the communication level from masking substantial physical faults, providing a solid data credibility guarantee for the trigger access control of high-risk experimental devices.

[0072] Example 3: like Figure 3 As shown, this embodiment, based on Embodiments 1 and 2, further specifies the process of using security weights to determine the trigger access status without changing the confirmation result. By constructing a differentiated access decision mapping based on the security criticality level, it achieves refined control over the trigger access of heterogeneous devices.

[0073] Step S301: Determine the safety criticality level of heterogeneous devices based on safety weights. The safety criticality level does not change the confirmation result, but is only used to determine the output that triggers the access status.

[0074] Among them, the safety criticality level is a discrete classification of the degree of safety risk of heterogeneous devices in a specific triggering task. Its value or category is completely derived from the safety weight, but it is logically independent of the confirmation results (success, failure, unconfirmed) generated in Example 2.

[0075] Safety weights typically encompass multiple dimensions, including impact on personal safety, impact on equipment damage, impact on experimental effectiveness, and impact on triggering links. The system can map continuous or multidimensional safety weights into a finite number of discrete safety critical levels through one or more combinations of the highest risk dimension rule, weight score range rule, or equipment type lookup table rule.

[0076] In some implementations, after receiving the unified equipment confirmation record, the safety criticality admission matrix first reads the safety weight parameters that are fixed in the current configuration snapshot of the equipment. For example, for safety interlocking equipment involving high-voltage output or emergency stop circuits, if both the personal safety impact and equipment damage impact dimensions are at their highest values, the system determines it as the fourth safety critical level (safety critical equipment) based on the highest risk dimension rule.

[0077] For auxiliary display devices that only affect the integrity of data records, the impact in all dimensions is relatively low, and they are identified as the first safety critical level (non-safety critical devices).

[0078] Acquisition equipment that affects the quality of experimental data but does not directly pose a danger may be classified as Level 2 safety criticality (equipment related to experimental effectiveness).

[0079] For scenarios such as power parameter adjustment equipment that may cause equipment damage but have personal protective equipment, they may be identified as the third safety critical level (quasi-safety critical equipment).

[0080] It should be understood that the process of determining the safety criticality level is an independent step performed after the evidence normalization is completed and before the access decision. Regardless of the level of the equipment, the confirmation results such as unconfirmed or failed generated in Example 2 will not change. The only change is the row index located during subsequent matrix queries.

[0081] It should be noted that this step, by transforming multi-dimensional safety weights into standardized safety criticality levels, provides a unified addressing benchmark for subsequent differentiated decision-making. This design transforms safety evaluation standards from subjective experience-based judgments into configurable and traceable technical parameters. It ensures the uniqueness of the safety level determination for the same device under the same task scenario, while also allowing for dynamic adjustment of the device's safety classification by loading different weight configurations in different experimental modes, thus adapting to the varied operational needs of complex experimental devices.

[0082] Step S302: The access decision mapping takes the safety criticality level as the first dimension and the confirmation result and the type of non-confirmation reason as the second dimension.

[0083] In this embodiment, the access decision mapping is specifically represented as a two-dimensional configuration matrix. Its row dimension corresponds to the security criticality level determined in step S301 (such as levels one to four), and its column dimension corresponds to the confirmation result and its subdivided state combinations, including but not limited to success and reaching the minimum confirmation level, valid evidence existing but not reaching the minimum confirmation level, unconfirmed due to lack of parseable confirmation evidence, and failure. Furthermore, the value of each cell in the matrix represents a preset trigger access state. This value is a pre-configured technical parameter frozen with the configuration snapshot, rather than a subjective instruction temporarily entered by the operator at runtime.

[0084] In some implementations, when a task is triggered to enter a configuration-frozen state, the system writes the complete admission decision mapping matrix to a configuration snapshot. Specifically, the column dimension design of the matrix fully considers the heterogeneity of unconfirmed states, subdividing them into two scenarios: those with evidence but insufficient depth and those without evidence, in order to implement precise handling for different causes.

[0085] For example, in the configuration interface or configuration file, the administrator can configure the column for "Valid evidence exists for second-level security criticality devices but has not reached the minimum confirmation level" to be manually reviewed. This means that although the evidence is incomplete, there has been some feedback, which is worth human intervention for confirmation.

[0086] For unconfirmed columns at the same level that have no resolvable confirmation evidence, they may be configured to be in a warning-enabled state, meaning that the loss may be due to temporary communication jitter, which is tolerable on non-critical devices.

[0087] When the confirmation evidence normalization module outputs a unified device confirmation record containing the confirmation result = not confirmed and the reason for not confirming = no receipt received after timeout, the safety criticality admission matrix locates the row according to the safety criticality level in the record, locates the column according to the confirmation result and reason type, and directly reads the cell value at the intersection as the output.

[0088] It should be noted that by solidifying the access decision logic into a matrix structure and freezing it with configuration snapshots, the drift of security standards caused by human intervention or temporary rule modifications during the trigger preparation process is eliminated. At the same time, the matrix cell values ​​clearly indicate that states such as "allowed with warning" are based on automatic judgment results according to preset rules, rather than arbitrary operator approval. This ensures both safety and compliance while providing verifiable evidence for the deterministic behavior of the automated system.

[0089] Step S303: Triggering access status includes allowed triggering status, prevented triggering status, manual review status, or allowed with warning status; when the safety criticality level reaches the preset high level and the confirmation result is failure or unconfirmed, the access decision mapping outputs prevented triggering status; when the safety criticality level is the preset low level and the confirmation result is unconfirmed, the access decision mapping outputs allowed with warning status or manual review status according to the type of unconfirmed reason; when the safety criticality level is the preset intermediate level and the confirmation result is unconfirmed, the access decision mapping outputs manual review status or prevented triggering status according to the type of unconfirmed reason.

[0090] Among them, the differentiated handling logic refers to the access decision mapping outputting completely different trigger access states for the same confirmation result (especially unconfirmed and failed) based on the level of safety criticality, which reflects the safety control principle that the higher the risk, the lower the tolerance.

[0091] The "Allow with Warning" status is a special access status that indicates the system allows the triggering of command output, but will forcibly write a non-safety-critical unconfirmed flag, matrix version, and specific reason into the unified device confirmation record for post-event auditing or real-time monitoring prompts.

[0092] In some implementations, the safety criticality admission matrix exhibits significant gradient characteristics when executing queries. Specifically, for devices at the fourth safety criticality level (preset high level), the matrix unconditionally outputs a prevent triggering status as long as the confirmation result is a failure or any form of unconfirmation, ensuring that the safety critical link remains absolutely locked in the face of any uncertainty.

[0093] For equipment at the first safety critical level (preset low level), when the confirmation result is unconfirmed, if the reason is that valid evidence exists but does not meet the standards, the matrix may output a manual review status for quick confirmation. If the reason is that there is no evidence and historical statistics show that the communication of this type of equipment is unstable, the matrix may output a warning-enabled permission status to avoid interrupting the entire high-voltage test process due to occasional communication problems of auxiliary equipment.

[0094] For devices at the second or third safety criticality level (preset intermediate level), the matrix adopts a compromise strategy. For example, it manually reviews unconfirmed outputs or decides whether to block them based on the specific reason for the unconfirmation, neither completely ignoring the issue nor being overly sensitive. For instance, during a single-shot trigger preparation, if a non-critical diagnostic camera (level 1) fails to confirm due to network jitter timeout, the matrix outputs a warning allowing the experiment to proceed as normal, but an anomaly is marked in the log. At the same time, if the main trigger controller (level 4) also fails to confirm for the same reason, the matrix directly outputs a prevent trigger, forcibly terminating the experimental process.

[0095] It is worth noting that this step, through a matrix-based gradient handling mechanism, successfully resolves the binary conflict between safety and efficiency in traditional control systems. While ensuring zero tolerance for safety-critical equipment, it grants appropriate fault tolerance to non-critical equipment, enabling the system to maintain both safety standards and maximum experimental continuity in complex, heterogeneous equipment collaborative environments. This automated, differentiated decision-making based on technical parameters, compared to real-time judgment relying on human experience, not only offers faster response and more consistent judgment criteria but also achieves full traceability of the decision-making logic through configuration snapshots, providing precise data support for subsequent accident analysis and system optimization.

[0096] Based on the above technical solution, this embodiment transforms safety weights into discrete safety criticality levels and constructs a configurable access decision mapping matrix with the combination of safety level and confirmation status as the dimension, thereby achieving refined and deterministic trigger access control. This mechanism ensures that safety weights are only used as parameters for decision routing and do not tamper with objective confirmation results, maintaining the purity of status determination. At the same time, through the detailed handling of unconfirmed states and the gradient response of high- and low-level equipment, a dynamic balance between rigid safety constraints and flexible experimental requirements is achieved, effectively avoiding excessive blocking or risk out of control due to a single safety strategy, and improving the intelligence level and operational efficiency of the trigger access system for complex experimental devices.

[0097] Example 4: like Figure 4 As shown, this embodiment, based on embodiments 1 to 3, further specifies the process of obtaining confirmation evidence returned by heterogeneous devices in response to the preparatory command. By constructing a multi-dimensional frame filtering mechanism, a deduplication strategy based on five tuples, and an adaptive dynamic timeout retry logic, it provides underlying technical support for the accuracy of confirmation evidence and the reliable definition of the unconfirmed state.

[0098] Step S401: Perform frame filtering on the confirmation evidence. Frame filtering includes matching and verifying the source address, command identifier, reception time window, and protocol integrity.

[0099] Frame filtering refers to the preprocessing process of filtering out valid data packets belonging to the current triggering task, the current device, and the current preparatory command from the original communication data stream, and removing noise, expired frames, misaligned frames, and damaged frames. Its purpose is to ensure that the confirmation evidence entering the subsequent normalization process has resolvability and attribution certainty, and it is the first line of defense in distinguishing between no evidence and invalid evidence.

[0100] In some implementations, the evidence normalization module performs a five-fold verification logic on each received frame of data: The first layer is source address verification, which precisely matches the source IP, MAC address or Modbus slave address in the frame header with the device identifier registered in the configuration snapshot, and discards frames from unknown sources to prevent cross-device interference.

[0101] The second layer is command identifier verification, which checks whether the function code, command word, and command sequence number are completely consistent with the currently issued preparatory command, and discards response frames of irrelevant commands.

[0102] The third layer is the receive time window check, which determines whether the frame receive timestamp falls within a valid window that starts at the command sending time and ends at the dynamic timeout value. Frames that are earlier than the window (possibly remnants from the previous round) or later than the window (have timed out) are discarded.

[0103] The fourth layer is protocol integrity verification, which verifies whether the frame length, CRC checksum or checksum conforms to the protocol specification. For frames belonging to the current command but failing the verification, they are not discarded as valid evidence, but instead, explicit failure evidence is generated directly.

[0104] The fifth layer is parameter tolerance verification, which checks the range of parameter readback values ​​carried in the frame. If the values ​​fall within the tolerance range, they are marked as valid evidence; if they exceed the tolerance, clear failure evidence is generated.

[0105] For example, when collecting the status of PLC power supply equipment, if a Modbus TCP response frame with a CRC check error is received, the system will not regard it as no response received, but will determine it as clear evidence of communication link failure according to the fourth check rule.

[0106] It should be noted that this progressive filtering mechanism subdivides the originally ambiguous communication anomalies into different types of technical events such as irrelevant noise, data corruption, and parameter out-of-bounds errors, enabling subsequent normalization judgments to be based on clean and semantically clear data inputs.

[0107] Step S402: For the confirmation evidence that has passed frame filtering, perform deduplication processing based on the deduplication key composed of device identifier, command identifier, task identifier, channel number and command sequence number.

[0108] The deduplication key is a unique index identifier composed of five dimensions, used to accurately identify the same instance of the same preparatory command in concurrent communication or multi-frame response scenarios.

[0109] Deduplication aims to resolve multi-frame conflicts caused by network retransmissions, repeated device responses, or bus echoes, and to prevent duplicate evidence from interfering with the merging and determination of the confirmation level.

[0110] In some implementations, the confirmation evidence normalization module calculates a deduplication key for each piece of confirmation evidence that has passed frame filtering. ; In the formula, To remove duplicate keys; It serves as a device identifier, used to uniquely distinguish different heterogeneous devices (such as PLC power supplies, arc power supplies, trigger controllers, etc.) participating in the triggering task. This is a command identifier used to identify the type of pre-issued command (such as write parameters, read status, enable, etc.). The task identifier is a globally unique number associated with the current single triggered task, ensuring evidence isolation between different tasks; the ChannelID is the channel number, used to distinguish multiple physical or logical channels under the same device (such as multiple acquisition channels, multiple trigger output channels). This is the command sequence number, used to distinguish multiple transmission instances of the same command from the same device (such as different sequence numbers when retrying or re-issuing).

[0111] When the system receives new confirmation evidence, it first checks if a matching one exists in the memory cache. If the evidence does not exist, it is stored in the valid evidence set and the duplication counter is initialized to 1. If the evidence already exists, the timestamps and confirmation levels of the new and old evidence are compared: generally, the frame with the updated timestamp is retained, or if the timestamps are close, the frame with the higher confirmation level is retained (e.g., parameter readback frames are preferred over write response frames), and the duplication counter is incremented. .

[0112] For example, if the RTU arc power supply returns two identical write echo frames due to serial bus reflection, the system identifies them as belonging to the same command instance using a 5-tuple deduplication key, retains only the first valid frame for level mapping, and then... Record it as 2 and write it into the audit field of the unified device confirmation record.

[0113] It should be noted that introducing the quintuple deduplication key not only solves the data redundancy problem, but more importantly, provides a traceable diagnostic basis for the special condition of multi-frame collisions. When Furthermore, when the content of each frame is inconsistent (e.g., one frame displays successfully while another fails), the system can prioritize failures or trigger manual review, without losing crucial anomaly information due to simple overwrite logic. This design enhances the system's robustness in complex electromagnetic environments or poor-quality links while ensuring data processing efficiency.

[0114] Step S403: If a timeout is confirmed, perform a retry or wait. The timeout confirmation is determined based on the polling period, link latency, historical response statistics, and safety margin.

[0115] Among them, the confirmation timeout condition is a dynamically calculated adaptive time threshold used to define the maximum patience limit of the system in waiting for the device response. Unlike the traditional fixed timeout, this condition takes into account the device's own response characteristics, the real-time status of the communication link, and historical operating experience, aiming to balance the contradiction between quickly determining unconfirmed cases and avoiding false timeouts.

[0116] In some implementations, the system uses the following formula to calculate the dynamic timeout value. :

[0117] in, The base timeout value is determined by the device type; The current status polling cycle for the device; This is the estimated propagation delay of the link (a fixed value is used for fiber optic links, and a moving average is used for network links). This is the 95th percentile of the device's response time in the past N triggered tasks, reflecting its actual performance baseline; To provide a safety margin for absorbing momentary jitter; and These are preset minimum and maximum timeout boundaries to prevent frequent false alarms due to excessively small calculated values ​​or blockages due to excessively large calculated values.

[0118] During the waiting process, for idempotent operations such as reading status and reading parameters, the system can... Retry is initiated at preset intervals before exhaustion; however, for non-idempotent preparatory commands such as write and enable, only acknowledgment frames or polling status are repeatedly received, and the command itself is never repeatedly sent.

[0119] For example, the historical response time of a certain data acquisition device is usually around 200ms, but due to network congestion caused by a large amount of data pre-transmission before this experiment, Significant increase, the system will automatically The default 500ms was adjusted to 800ms to avoid the device being mistakenly judged as offline due to temporary congestion.

[0120] It's important to note that the dynamic timeout mechanism transforms the timeout from a static configuration parameter into an intelligent variable that is aware of the environment. It maintains a tight decision-making rhythm when device performance is stable, while automatically relaxing tolerances when link degradation occurs or device load increases, reducing the false unacknowledged rate caused by environmental fluctuations. Simultaneously, by limiting retry times for non-idempotent commands, it eliminates the security risk of unexpected device state reversals caused by timeout retries.

[0121] Step S404: When the confirmation timeout condition is exceeded and there is no clear evidence of failure, the confirmation result is defined as unconfirmed.

[0122] This step establishes a closed-loop timing logic for generating the unacknowledged state. That is, the system will mark the acknowledgment result as unacknowledged only after exhausting all waiting and retry methods and no clear evidence of failure is captured within the entire timeout window. If evidence of failure (such as a check error, a valid fault bit, etc.) is detected at any time during the timeout process, the waiting will be terminated immediately and the result will be locked as failure, and the unacknowledged decision branch will not be entered again.

[0123] In some implementations, the evidence normalization module internally maintains a high-precision timer and a failure flag. When the preparatory command is issued, the timer starts and begins counting; during this period, each received data frame undergoes steps S401 and S402. If failed evidence is generated, the failure flag is set and the failure result is immediately output; if the timer reaches its limit... If the failure flag is still false when the threshold is reached, and the set of valid evidence is empty or the minimum confirmation level has not been reached, then an unconfirmed result will be output.

[0124] For example, when verifying a safety interlock device, if no response frame is received within the 300ms dynamic timeout window and the link layer does not report a transmission error, the system defines it as unverified at the timeout deadline; conversely, if an interlock blocking signal is received at 200ms, the system immediately determines it as a failure at 200ms, and the remaining 100ms waiting time is canceled.

[0125] This dual-track decision logic, which includes immediate interruption upon failure and fallback for unconfirmed timeouts, ensures the timeliness and accuracy of status output.

[0126] It should be noted that this step, through strict timing and logical constraints, defines unconfirmed as a fully verified state of ignorance, rather than a simple wait for completion. Together with the failure evidence generation mechanism in step S401 and the dynamic timeout mechanism in step S403, it forms a robust evidence collection loop. This ensures that the ternary state definition of the response written in Example 1 has a solid data foundation and process credibility, eliminating the risk of various state confusions caused by improper timeout settings or oversights in exception handling.

[0127] Based on the above technical solutions, this embodiment constructs a three-in-one evidence preprocessing system integrating five-fold frame filtering, five-tuple deduplication, and dynamic timeout retry. This system effectively purifies the signal-to-noise ratio of heterogeneous device feedback data at the source, solving technical challenges commonly encountered in complex industrial environments, such as message crosstalk, duplicate responses, and network jitter. In particular, the introduction of dynamic timeout conditions enables the system to adaptively adjust its judgment rhythm according to real-time operating conditions, minimizing false alarm rates while ensuring a safety baseline. Furthermore, the strict unconfirmed generation loop provides the upper-level access decision with a true, reliable, and unambiguous state input, ensuring stable operation and accurate judgment of the entire trigger access control system in harsh electromagnetic environments and scenarios involving intertwined heterogeneous protocols.

[0128] Example 5: like Figure 5 As shown, this embodiment, based on embodiments 1 to 4, further specifies the processing flow when the trigger access state is manual review. By constructing a complete manual review mechanism that includes mandatory prohibition, supplementary evidence writing, permission verification, and timeout fallback, it solves the problem of decoupling manual intervention and technical security boundaries in the heterogeneous device confirmation evidence normalization trigger access method.

[0129] Step S501: In response to the manual review status output by the admission decision mapping, keep the trigger control interface from outputting trigger commands or trigger enable signals.

[0130] Specifically, keeping the trigger control interface disabled from output means that throughout the entire lifecycle of the system entering the manual review process, the trigger control interface maintains a physical-level signal blocking state. This state is independent of the operating state of the host computer software and is not released by the operator switching interfaces on the main control / HMI or by unauthorized operations. This is a hardware-level or low-level driver-level safety interlock mechanism designed to ensure that no trigger command or trigger enable signal can reach the trigger controller in the high-voltage test area before manual confirmation is completed.

[0131] In some implementations, when the trigger access status output by the safety criticality access matrix is ​​manual review, the central control computer immediately sends a lockout command to the trigger control interface.

[0132] The logic gate circuit or safety relay inside the trigger control interface then disconnects the trigger signal path and sets the verification flag in the hardware register.

[0133] During this period, even if the master control / HMI interface displays "ready" or other misleading information, or if the operator accidentally clicks the trigger button, the trigger control interface will refuse to respond based on the hardware interlock logic. The interlock state will only be released after subsequent steps S502 to S504 are completed and the access decision mapping is re-determined to allow triggering or allow with a warning.

[0134] For example, when verifying a power supply device of the third safety critical level, the matrix output is manually reviewed due to missing parameter readback. At this time, the trigger control interface automatically cuts off the enable signal. After the operator checks the equipment panel on site and confirms that it is normal, he submits the review in the system and it is approved. The matrix is ​​then re-judged as allowed to trigger, and the trigger control interface reconnects the signal path.

[0135] It should be noted that this step, by solidifying the prohibited actions during manual review into mandatory actions at the interface layer, physically eliminates the possibility of accidental triggering due to human error or software logic vulnerabilities. It clarifies that manual review is a controlled pause state, not a pending trigger state, eliminating the blind spot of risk caused by temporary failure of safety interlocks due to operator intervention in traditional systems, and ensuring a safety line during human-computer interaction.

[0136] Step S502: Receive the review result submitted by the authorized operator, write the review result as supplementary basis into the confirmation record, and trigger the access decision mapping to re-determine; wherein, the review result does not directly replace the confirmation level.

[0137] Supplementary evidence refers to an independent piece of human verification data added to the unified equipment confirmation record without modifying, overwriting, or deleting the original confirmation evidence and its generated confirmation level.

[0138] The fact that the review result does not directly replace the confirmation level means that even if the operator submits a review approval, the system will not forcibly change the original unconfirmed or failed device status to successful or upgrade its confirmation level. The original objective technical facts remain unchanged, and only the query input conditions of the access decision mapping are changed.

[0139] In some implementations, when an operator submits a review result (such as review passed or review rejected) on the review interface of the central control / HMI, the system first encapsulates the result along with information such as the reviewer ID, review timestamp, and review basis description into a "review evidence record" and associates it with the corresponding unified device confirmation record.

[0140] Subsequently, the system uses "original confirmation result + review result" as the new key combination to query the security criticality admission matrix again.

[0141] For example, if a data acquisition device is judged as unconfirmed (actual confirmation level 0) due to a communication timeout, and the operator verifies it on-site and submits a review that is approved, the system will not change the device's confirmation level to level 4 or the confirmation result to success. Instead, it will keep the unconfirmed record unchanged, and use "unconfirmed + approved" as the column index in the matrix query. If the cell in the matrix is ​​configured to allow triggering, the system will output an allow signal; if it is configured to prevent triggering, it will not be triggered even if the review is approved. Conversely, if the operator submits a review rejection, the matrix query will usually directly point to the cell that prevents triggering, regardless of the original status.

[0142] It should be noted that this supplementary rather than substitutive data processing mechanism achieves strict separation and traceable integration of objective machine evidence and subjective human judgment. It preserves the authenticity of the equipment's original state (facilitating post-fault analysis and liability determination) while also giving the system the flexibility to accept human verification under specific rules. Compared to the traditional practice of human confirmation directly overriding machine alarms, this application avoids the risk of concealing true equipment hazards due to human negligence or violations, making each human intervention an independently auditable technical link in the audit chain.

[0143] Step S503: Based on the security criticality level, determine the required permission level and review timeout limit for the review; verify the operator's identity and permissions.

[0144] The required access level for review is an access control threshold that is positively correlated with the security criticality level of the equipment. This is used to ensure that only personnel with the corresponding technical qualifications and management authorization can make decisions on the abnormal status of high-risk equipment.

[0145] The review timeout limit is the maximum allowable duration set for the manual review process. Its value can be dynamically configured according to the safety criticality level to prevent the review process from being suspended indefinitely, which would affect the experimental rhythm or cause environmental conditions to drift.

[0146] In some implementations, when generating a manual review request, the system automatically looks up the corresponding permission requirements and time limits based on the current safety criticality level of the device. Specifically, for devices at the fourth safety criticality level, the permission level required for review is set to the highest level (such as "Safety Supervisor" or "Chief Engineer"), and the review timeout is set to a shorter value (such as 30 to 60 seconds) to ensure that critical risks are addressed in a timely manner.

[0147] For devices at the first or second security critical level, the access level can be relaxed to that of ordinary operators, and the time limit can also be appropriately extended (e.g., 3 to 5 minutes). When an operator attempts to submit the review result, the system will first read their login credentials or biometric information to verify whether their identity matches the required access level; at the same time, the system continuously monitors the review timer, and if the current time exceeds the review deadline, the review window will be automatically closed.

[0148] For example, during a single-shot trigger preparation, if a non-critical diagnostic camera (Level 1) is not confirmed, the system prompts any duty officer to review it within 5 minutes; at the same time, if the main trigger controller (Level 4) is not confirmed, the system only allows the security officer holding the advanced key to review it within 30 seconds, and the ordinary operator account is grayed out and unavailable on this interface.

[0149] It should be noted that this step transforms manual review from a management process into a system function with clearly defined technical parameters. By binding permissions and time limits, the system ensures the seriousness of safety-critical operations while reserving necessary efficiency margins for non-critical operations. This differentiated review strategy effectively prevents low-authority personnel from misjudging and allowing high-risk operations, and also avoids the expiration of experimental windows due to review delays.

[0150] Step S504: When the verification fails or no valid response is received within the review timeout period, the review result is not considered a valid basis, and a trigger prevention status is output.

[0151] The statement that the review result is not used as a valid basis means that the system will discard any submissions that fail the permission verification or any inputs that have timed out as invalid data, and will not write them into the unified device confirmation record, nor will it trigger the re-judgment process of the access decision mapping.

[0152] The output blocking trigger state is the system's default safety fallback strategy when reviewing abnormal termination. That is, in the absence of legitimate and timely human confirmation, it automatically reverts to the most conservative control mode.

[0153] In some implementations, the system maintains a review state machine, which includes state nodes such as waiting for review, verification in progress, review completed, verification failed, and review timeout.

[0154] When in the waiting-for-review state, if the timer overflows, the state machine automatically jumps to the review timeout node and immediately sends a timeout signal to the safety criticality admission matrix, which then outputs an error to prevent triggering.

[0155] If an operator submits a review but the permission verification fails, the state machine jumps to the verification failure node, which also triggers the prevention output and reports the specific reason for the failure to the HMI (such as insufficient permissions or expired token).

[0156] Throughout the process, the trigger control interface remains locked until the next new trigger task is started or the configuration is reset.

[0157] For example, after a certain quasi-safety-critical equipment enters the manual review stage, the operator submits the review approval 5 seconds before the time limit expires. However, due to network latency, the system receives the request 1 second after the time limit has expired. The system strictly executes the timeout fallback logic, determines that the review is invalid, and outputs a prevent triggering error. Although the operator subjectively believes that the confirmation has been completed, the system still uses the objective time sequence to ensure the safety boundary.

[0158] It is important to note that this step establishes a fail-safe closed loop for the manual review mechanism. This ensures that in any situation where human error is absent, authority is exceeded, or there is a delay, the system can automatically revert to a defined safe state, rather than remaining in an uncertain intermediate state or mistakenly allowing access. This rigid fallback design eliminates the possibility of introducing new security risks due to imperfections in the review process itself, making manual review a true complement to the technical security system rather than a potential vulnerability.

[0159] Based on the above technical solution, this embodiment achieves seamless integration and strict decoupling of manual intervention and automated security control by constructing a manual review mechanism that includes mandatory physical prohibition, supplementary evidence without substitution for write operations, hierarchical permission time limit constraints, and automatic fallback upon timeout. This mechanism ensures that the experimental process can be restored through compliant manual verification when the device status is unclear, while also preventing the risk of manual operation bypassing security boundaries, concealing real faults, or causing accidental triggering due to uncontrolled permissions. In particular, the design of review not replacing confirmation level and blocking upon timeout establishes the principles of prioritizing objective evidence and ensuring that the security bottom line cannot be crossed, making manual review a quantifiable, traceable, and verifiable technical security component, thereby improving the overall reliability and compliance of the access control system for complex heterogeneous devices.

[0160] Example 6: like Figure 6As shown, this embodiment, based on embodiments 1 to 5, further specifies the configuration management process before obtaining confirmation evidence returned by heterogeneous devices in response to the preparatory command. By constructing configuration snapshot freezing, change inheritance, and audit isolation mechanisms, it solves the problems of consistency and traceability of the trigger access determination criteria. Step S601: When the triggering task enters the configuration frozen state, freeze the configuration snapshot. The configuration snapshot includes the triggering configuration, confirmation protocol, version of the admission decision mapping, device security critical level, device dependency relationship and protocol configuration.

[0161] The "configuration frozen" state is a controlled intermediate state in the lifecycle of a triggered task, between "created" and "confirmed." It signifies that the judgment criterion for this triggered task has been transformed from editable configuration data into an immutable execution basis. The "configuration snapshot" is the collection of all parameters that affect the trigger admission judgment result in this state. Its function is equivalent to solidifying the judgment standard for this single-shot trigger task, ensuring that subsequent evidence collection, normalization, and admission decisions are all executed based on the same set of static parameters, rather than relying on dynamic global configurations that may be modified at any time.

[0162] In some implementations, when the central control / HMI receives a task start command or automatic flow signal confirmed by the operator, the system will trigger the task state machine to switch from created to configuration frozen, and immediately trigger the snapshot generation process.

[0163] The process extracts and serializes the following core fields from the current runtime environment: trigger configuration (such as trigger mode, channel, timing, pulse width, polarity, etc.), acknowledgment specifications (such as minimum acknowledgment level for each device, timeout retry policy, frame filtering rules, etc.), version number and complete matrix content of the admission decision mapping, security criticality level and its grading factors for each heterogeneous device, directed dependency graph topology data between devices, and underlying communication protocol configuration (such as IP address, port, baud rate, register mapping, etc.). The generated configuration snapshot is assigned a globally unique snapshot ID and version number, and a hash digest is calculated to prevent tampering. It is then persistently stored in a local database or file system.

[0164] For example, during the preparation for a neutral beam injection experiment, the system froze a configuration snapshot A at 10:00 AM, which included "target voltage of high voltage power supply 80kV", "safety interlock level 4" and "access matrix v2.3". Even if the operator changed the global power parameters to 90kV at 10:05 AM due to other tasks, the triggered task still strictly performed parameter readback tolerance verification based on 80kV in snapshot A, and was not affected by external changes.

[0165] It should be noted that in traditional systems, if an operator mistakenly changes a threshold or matrix configuration during evidence collection, it may lead to the first half of the evidence being judged according to the old rules and the second half according to the new rules, causing logical confusion or even security incidents. The configuration snapshot mechanism decouples configuration time from execution time. By encapsulating discrete and volatile configuration parameters into atomic, immutable objects, it eliminates the risk of rule drift during the judgment process, ensuring absolute consistency of the judgment benchmark within a single triggered task. It also provides a basis for on-site reconstruction for post-event review, allowing any triggered admission result to be traced back to the exact parameter environment at the time of its generation.

[0166] Step S602: After the configuration snapshot is frozen, in response to receiving a configuration modification request, a new configuration snapshot with the parent snapshot identifier and the reason for modification is generated.

[0167] The parent snapshot identifier is a unique index pointing to the direct predecessor version of the currently effective configuration snapshot, used to build a clear configuration evolution lineage in the version management system.

[0168] The reason for the modification is to require operators to fill in a structured or textual description when submitting changes, in order to record the business motivation and technical background of the changes.

[0169] The new configuration snapshot is not an overwrite update of the original snapshot, but a completely new independent entity that inherits most of the attributes of the original snapshot but includes specific changes to ensure that the integrity of the historical version is not compromised.

[0170] In some implementations, when the system is in a configuration-frozen state, if the central control / HMI detects that an operator is attempting to modify critical configurations such as trigger channels, power parameters, security levels, or access matrices, the system will not directly reject the request, nor will it directly modify the currently used snapshot. Instead, a change confirmation interface will pop up, requiring the operator to enter the reason for the modification (such as "replace the backup acquisition channel", "adjust the interlocking threshold to adapt to the new target material", etc.).

[0171] After confirmation and submission, the system uses the current snapshot as the parent node, copies all its fields as the basis, updates only the fields modified by the user with the new values, automatically generates a new snapshot identifier, increments the version number, records the current time as the freeze time, and writes the original snapshot ID into the "parent snapshot identifier" field of the new snapshot.

[0172] For example, in the task using snapshot A mentioned above, if the operator discovers that acquisition channel 3 is malfunctioning and needs to switch to channel 4, the system will generate snapshot B. Its parent snapshot identifier points to A, and the reason for the change is recorded as "Hardware failure of channel 3, switching to backup." Only the channel mapping field changes in snapshot B; other settings such as trigger configuration and security level are inherited from A. At this point, if the task has not yet started acquisition, the system can update the snapshot pointer associated with the current task to B; if the task is already acquiring data, the system will decide whether to allow hot switching or prompt for a task restart based on a preset policy.

[0173] It's worth noting that this parent pointer-based version inheritance mechanism elevates configuration management from simple file overwriting to lineage tracing. It not only preserves the complete context of each change, allowing auditors to trace the parameter adjustments throughout the entire experiment preparation process along the parent snapshot identifier, but also enhances system interpretability by forcibly recording the reasons for modifications, linking what were originally purely technical operations with business intent. More importantly, because the old and new snapshots are independent entities, even if an error in the new configuration causes the task to fail, the system can instantly roll back to any historical snapshot state without relying on complex undo operations or backup recovery, improving operational efficiency and fault tolerance in complex experimental environments.

[0174] Step S603: The original configuration snapshot and its associated collected confirmation records are retained as historical audit records. The collected confirmation records are not migrated as valid trigger access basis under the new configuration snapshot.

[0175] Among them, "not migrating the collected confirmation records" means that after the configuration is changed and a new snapshot is generated, the system logically cuts off the validity association between the unified device confirmation records generated under the old snapshot and the new snapshot, and prohibits the direct reuse of these evidences collected based on old parameters and old rules as access judgment inputs under the new configuration.

[0176] Historical audit records refer to data stripped of its current validity but not deleted. Instead, it is marked as read-only archived and used only for post-event queries, comparative analysis, or troubleshooting. It no longer participates in real-time trigger control decisions.

[0177] In some implementations, when the system completes the generation of a new configuration snapshot and decides to apply it to the currently triggered task, it automatically executes an evidence isolation procedure. Specifically, the system first checks whether the current task already has associated unified device confirmation records; if so, it sets the validity flag of these records to false, or moves them to the historical audit partition in the database, while clearing the current access status display on the interface and prompting that the configuration has changed and evidence needs to be collected again. Subsequently, the system forcibly triggers a new round of confirmation evidence collection process, and all devices must respond to the preparatory command again based on the parameters in the new configuration snapshot, generating a completely new unified device confirmation record.

[0178] For example, in a task using snapshot A, if the PLC power supply has been confirmed and a "success" record has been generated, and the operator then changes the target voltage from 80kV to 90kV and generates snapshot B, even though the PLC is functioning normally at 80kV, this "success" record is based on the 80kV tolerance. For the new target of 90kV, this evidence is not only invalid but also misleading (because normal operation at 80kV does not guarantee normal operation at 90kV). Therefore, the system automatically discards the old record and forces the PLC to reread the parameters and undergo verification under the 90kV setting. Only the newly generated record can be used as the admission basis for snapshot B.

[0179] It should be noted that this step establishes the principle of strong binding between evidence and configuration. Through mandatory evidence isolation and re-collection mechanisms, misjudgments caused by configuration changes can be prevented, ensuring that every access decision is based on the latest and most accurate configuration benchmark, thus eliminating the risk of historical data contaminating real-time decisions.

[0180] Based on the above technical solution, this embodiment achieves spatiotemporal consistency and full traceability of the trigger access judgment benchmark by constructing a three-in-one configuration management system of configuration snapshot freezing, version inheritance, and evidence isolation. This mechanism solidifies dynamically changing configuration parameters into static execution criteria, eliminating the risk of rule drift during the judgment process. Simultaneously, a complete configuration evolution genealogy is established through a chained record of parent snapshot identifiers and modification reasons, supporting refined auditing and rollback. In particular, the mandatory isolation rule of not migrating collected confirmation records ensures that each piece of confirmation evidence strictly matches its corresponding configuration version, preventing the misuse of historical evidence due to parameter changes, and providing a solid data governance foundation and security compliance guarantee for the trigger access system for complex heterogeneous devices.

[0181] Example 7: like Figure 7 As shown, this embodiment, based on embodiments 1 to 6, further specifies the process of obtaining confirmation evidence returned by heterogeneous devices in response to the preparatory command. By constructing directed dependencies between devices and implementing a topology-based group acquisition and pre-blocking strategy, it solves the timing conflicts and security cascading control problems in the collaborative preparation process of complex heterogeneous devices. Step S701: Obtain the device dependencies between heterogeneous devices and construct a directed dependency graph.

[0182] Among them, equipment dependency refers to the sequential constraints of physical power supply, signal synchronization, logical interlocking or data supply among heterogeneous devices during the trigger preparation process. This relationship determines the legal timing of evidence collection.

[0183] A directed dependency graph abstracts discrete dependencies into a topological data structure composed of nodes and directed edges. In the graph, nodes represent heterogeneous devices that participate in triggering tasks, and directed edges represent the dependency direction from the front-end device to the back-end device. That is, only when the starting device of the edge completes the confirmation can the ending device of the edge have the physical or logical premise to start the confirmation.

[0184] In some implementations, during the task configuration phase, the central control computer reads a predefined list of device dependencies or a dependency matrix from the configuration snapshot and constructs a directed dependency graph in the form of an adjacency list or adjacency matrix in memory. Specifically, for typical scenarios such as neutral beam injection devices, safety interlocking devices are usually used as global root nodes, with their outgoing edges pointing to all other devices, indicating that confirmation of any device must be based on interlock permission.

[0185] The PLC power supply device acts as an energy source, with its output pointing to the RTU arc power supply and trigger controller, indicating that power readiness is a necessary condition for subsequent equipment to power on or standby.

[0186] If there is no direct connection between the acquisition device and the diagnostic device, it will be represented in the graph as an unconnected independent subgraph or parallel nodes.

[0187] In another implementation, after the system is built, it will also execute a loop detection algorithm (such as depth-first search, DFS). If a loop is found in the graph, an error will be reported immediately and the system will be prohibited from entering the configuration freeze state to prevent the confirmation process from being suspended due to deadlock.

[0188] It should be understood that although this embodiment uses static configuration as an example, in other embodiments, the dependency graph can also be dynamically generated according to the device's activation status or experimental mode, as long as it can accurately reflect the real physical constraints under the current task.

[0189] It should be noted that this step transforms implicit engineering experience into an explicit graph theory model, providing a precise mathematical foundation for subsequent automated scheduling. Compared to traditional systems that rely on manually arranging fixed scripts or hard-coding delays to avoid timing conflicts, directed dependency graphs enable the system to adaptively identify the inherent logical order between devices. This avoids dangerous operations such as turning on the device before turning it off due to human error, and also provides a structured basis for maximizing the use of parallel processing capabilities, which is a prerequisite for realizing intelligent trigger access control.

[0190] Step S702: Based on the directed dependency graph, collect confirmation evidence in parallel for heterogeneous devices that do not have device dependencies, and collect confirmation evidence in groups according to topological order for heterogeneous devices that have device dependencies.

[0191] Among them, topological order grouping acquisition refers to dividing all devices into several ordered levels or groups based on the topological sorting results of the directed dependency graph. Devices in the same group are independent of each other or depend only on devices in the previous group that have been completed. Therefore, the evidence acquisition process of writing the response in Example 4 can be executed concurrently within the group, while the process between groups strictly follows the sequential order.

[0192] In some implementations, before initiating data acquisition, the confirmation evidence normalization module performs a topological sorting algorithm (such as Kahn's algorithm) on the directed dependency graph to calculate the in-degree and level depth of each node. Nodes with an in-degree of 0 (such as safety interlocking devices) are assigned to the first group, and the system immediately initiates a confirmation request for them. Once all devices in the first group have reached the final state (success, failure, or unconfirmed), the system removes these nodes and their outgoing edges, updates the in-degree of the remaining nodes, assigns newly generated nodes with an in-degree of 0 to the second group (such as PLC power supply devices), and starts parallel data acquisition for that group. This process iterates until all nodes have been processed.

[0193] For multiple devices in the same group, the system uses multi-threading or asynchronous I / O mechanisms to simultaneously issue preparatory commands and listen for responses. The timeout timers of each device run independently and do not block each other.

[0194] For example, during a single-shot trigger preparation, after the safety interlock confirmation is completed, the system identifies that the high-voltage power supply, cooling water pump, and vacuum gauge are all dependent on the interlock and are independent of each other. Therefore, the confirmation process for these three devices is initiated concurrently at the same time. After all three have completed their confirmation, the next-level trigger controller is then initiated for confirmation. If one device in a group fails prematurely, it does not affect the continued data acquisition of other devices in the same group, but only affects the scheduling of subsequent nodes that depend on that device.

[0195] It should be noted that this step, through graph-driven dynamic grouping scheduling, successfully resolves the contradiction between the excessive time consumption of the traditional serial acknowledgment mode and the security risks of the disordered parallel mode. While ensuring that subsequent devices do not start until the preceding ones are ready, it fully leverages the parallel potential among heterogeneous devices, reducing the total preparation time. Especially in experimental setups with numerous devices and complex dependencies, this topology-based intelligent scheduling, compared to fixed-sequence execution, can shorten preparation time and improve the operational efficiency and response speed of the experimental setup.

[0196] Step S703: When the confirmation result of the front-end device is failure and the security weight of the front-end device reaches the preset blocking level, skip the subsequent trigger preparation steps that depend on the front-end device and output the trigger admission status as the trigger blocking status.

[0197] The preset blocking level is a safety threshold used to screen whether to trigger cascading blocking. It is usually set to the third safety critical level (quasi-safety critical) or the fourth safety critical level (safety critical) to distinguish between general failures and systemic risks.

[0198] Skipping subsequent trigger preparation steps means that after detecting a qualified pre-failure, the system no longer sends any preparatory commands to any downstream devices that directly or indirectly depend on the pre-failure device, nor does it start timeout timers for them. Instead, it directly marks the status of these downstream devices in the unified device acknowledgment record as blocked due to pre-failure, and immediately summarizes and generates the final blocking trigger status.

[0199] In some implementations, during the group acquisition process in step S702, whenever a device completes confirmation and generates a confirmation result, the system immediately checks whether the result is a failure and whether the security criticality level corresponding to its security weight is greater than or equal to the preset blocking level. If the conditions are met, the system traverses all successor subtrees of the node in the directed dependency graph, adds all downstream nodes that have not yet started to the skip list, and removes them from the scheduling queue. For non-dependent devices in the same group that are already executing, they are allowed to complete naturally, but their results are no longer used as a basis for allowing passage.

[0200] For example, if a PLC power supply device, classified as a fourth safety criticality level device, is deemed to have failed during verification (e.g., parameter readout exceeding limits), because the power supply is the physical upstream of the trigger controller and RTU arc power supply and has an extremely high safety level, the system immediately cancels the verification request for the trigger controller and arc power supply, directly locking the trigger access status of the entire task to prevent triggering, and recording the source of the blockage as PLC power supply failure in the audit log. Conversely, if only an auxiliary display device of the first safety criticality level fails verification, because its safety weight is lower than the blocking level, the system only records the failure status of that device itself and will not block the subsequent verification process of the main trigger link.

[0201] It should be noted that this step, by introducing safety weights as trigger thresholds for cascading interruptions, achieves refined and differentiated fault propagation control. This avoids the efficiency loss caused by occasional failures of non-critical auxiliary equipment leading to a shutdown of the entire high-voltage experimental system, while also ensuring that substantial faults on the critical path can be immediately cut off, preventing ineffective confirmation processes from wasting experimental windows or continuing preparations while equipment is faulty. This strategy of rapid circuit breaking for critical faults and local isolation for non-critical faults maintains the operational continuity of complex systems to the maximum extent possible while ensuring an absolute safety baseline.

[0202] Based on the above technical solution, this embodiment constructs a directed dependency graph and implements topology grouping scheduling and weighted pre-blocking mechanism to transform the physical and logical constraints between heterogeneous devices into a computable automated execution strategy. This mechanism not only eliminates the risk of equipment damage or safety accidents caused by timing errors, but also shortens the trigger preparation cycle through parallel processing. In particular, the selective cascading blocking design based on safety weights enables the system to make rational decisions that conform to the risk level when facing local faults, which avoids experimental interruptions caused by overreaction and eliminates potential hidden dangers of operating at risk.

[0203] Example 8: like Figure 8 As shown, this embodiment provides a heterogeneous device verification evidence normalization trigger access system. This system serves as the hardware carrier for the methods in the aforementioned embodiments, realizing the functions of evidence collection, processing, and trigger control through specific physical modules and connections. Specifically, the system includes a central control computer, device communication interfaces, and trigger control interfaces. The components interact and coordinate control through an internal bus or dedicated signal link.

[0204] The central control computer is configured to execute the heterogeneous device confirmation evidence normalization trigger admission method for writing responses as described in any of the foregoing embodiments, for generating unified device confirmation records and outputting the trigger admission status.

[0205] Among them, the central control computer is an embedded computing platform or industrial control computer that integrates dedicated logic units such as the confirmation protocol generation module, the confirmation evidence normalization module, and the safety criticality admission matrix. Its internal memory contains program instructions and configuration parameters for implementing the aforementioned method steps, and it is the core computing entity for the system to perform evidence normalization and admission decision.

[0206] In some implementations, the central control computer connects to the communication interfaces of each device via an internal high-speed bus, receiving raw feedback data from heterogeneous devices in real time, and running evidence normalization algorithms and admission matrix query logic in memory. Specifically, the confirmation protocol generation module generates acquisition rules for each device based on the current task configuration; the confirmation evidence normalization module filters, deduplicates, and maps levels to the acquired multi-source heterogeneous data, generating a unified device confirmation record containing confirmation results and reasons for non-confirmation; the safety criticality admission matrix then calculates the final trigger admission status (such as allow, block, review, or allow with warning) based on this record and the device's safety weight.

[0207] The device communication interface is configured to communicate with heterogeneous devices to obtain confirmation evidence.

[0208] Among them, the device communication interface is a collection of physical ports and protocol conversion circuits that are compatible with various industrial communication protocols. Its function is to shield the differences in electrical characteristics, data formats and transmission timing of the underlying heterogeneous devices, and to convert the raw signals from PLC power supply equipment, RTU arc power supply, safety interlock equipment and acquisition equipment into a standard digital evidence stream that can be recognized by the central control computer.

[0209] In some implementations, the device communication interface includes various types such as PLC communication interface, serial communication interface, safety interlock input interface, and data acquisition device communication interface.

[0210] PLC communication interfaces typically use the Ethernet physical layer and support protocols such as Modbus TCP to interact with PLC power supplies to obtain write responses, parameter readbacks, and status bits.

[0211] The serial communication interface supports electrical standards such as RS485 / RS232 and the Modbus RTU protocol, and is used to connect to the RTU arc power supply and obtain write echo and status frames.

[0212] Safety interlock input interfaces are typically optocoupler-isolated digital input channels used to directly acquire hard-wired interlock permission or emergency stop signals from safety interlock devices.

[0213] The communication interface of the acquisition device may use high-speed fiber optic or Ethernet to obtain the preparation status or configuration confirmation information of the acquisition device.

[0214] Each interface module has an independent protocol parsing chip or driver circuit, which can perform preliminary frame verification and timestamp marking at the hardware level, reducing the processing burden on the central control computer.

[0215] It should be noted that by constructing a diverse cluster of device communication interfaces, the compatibility problem of heterogeneous device access is solved at the physical level. This hardware-level protocol adaptation mechanism enables the system to simultaneously manage devices with different feedback depths and communication characteristics, providing a data source for the upper-layer normalization algorithm and avoiding evidence blind spots caused by missing interfaces or protocol mismatches.

[0216] The trigger control interface is configured to control the output of trigger commands or trigger enable signals based on the trigger admission state.

[0217] The trigger control interface is the physical signal execution mechanism connecting the central control computer and the high-voltage test zone trigger controller. Essentially, it is a safety gate directly driven by the access status, rather than a logical flag that merely exists in software memory. This interface determines whether to transmit the trigger command or trigger enable signal to the downstream high-voltage equipment through the on / off actions of the hardware circuitry, thereby forcibly enforcing the access decision at the physical level.

[0218] In some implementations, the trigger control interface can be constructed from safety relays, solid-state switches, or hard logic gates within an FPGA. Its control terminal is directly connected to the access status output pin of the central control computer or the result register of the safety criticality access matrix. When the access status is "trigger allowed" or "warning allowed," the switch inside the trigger control interface closes or the logic gate turns on, allowing the trigger command signal to be transmitted to the trigger controller via a fiber optic trigger link or an electrically isolated link.

[0219] When the access status is set to prevent triggering or manual verification, the interface will forcibly disconnect the signal path or keep the enable signal invalid in hardware. At this time, even if the software of the central control computer issues a trigger request due to a fault or misoperation, it will not be able to penetrate the physical barrier to reach the high-voltage side.

[0220] In addition, the trigger control interface can also be designed as an intelligent interface with self-monitoring function, which can provide real-time feedback of its on / off status for the central control computer to read back and verify, forming a control closed loop.

[0221] Based on the above technical solution, this embodiment constructs a system architecture that includes a central control computer, communication interfaces for multiple types of devices, and a physical-level trigger control interface. This architecture not only utilizes a dedicated computing platform to ensure the real-time execution of the normalization algorithm and access decisions, but also solves the data access problem for heterogeneous devices through diverse communication interfaces. More importantly, it establishes a mandatory enforcement mechanism for security decisions through the physical-level trigger control interface. This system design, which binds structure and function together, ensures that trigger access control no longer depends on a volatile software environment, but is built on a robust hardware foundation. This, in turn, enhances the security and reliability of trigger control while maintaining system flexibility.

[0222] Example 9: like Figure 8 and 9 As shown, based on Examples 1 to 8, this embodiment further applies the heterogeneous device confirmation evidence normalization trigger admission method and system to the specific experimental environment of the neutral beam injection device. By clarifying the physical isolation architecture and its link constraint parameters between the low-voltage control area and the high-voltage experimental area, the reverse determination effect on the confirmation protocol is demonstrated, showcasing the specific implementation form of the technical solution in high-voltage, strong electromagnetic interference and cross-isolation area communication scenarios.

[0223] Step S901: The system is deployed in an environment that includes a low-voltage control area and a high-voltage test area, which are connected by an isolation link.

[0224] The low-voltage control area refers to the area that houses the core logic processing units such as the central control computer, central control / HMI, confirmation protocol generation module, confirmation evidence normalization module, and safety criticality access matrix. This area is usually located at ground potential or in a low-voltage environment, where personnel can operate and maintain it relatively safely.

[0225] The high-voltage test area refers to the area that houses field equipment that directly participates in the generation, acceleration, diagnosis, or energy output of high-energy particle beams, such as PLC power supply equipment, RTU arc power supply, trigger controller, non-receiving serial port equipment, acquisition equipment / temporary storage instruments, and safety interlocks. During the experiment, this area may be at a high potential of tens to hundreds of kilovolts or have dangerous environmental factors such as strong radiation and strong magnetic fields.

[0226] An isolation link is a set of physical channels that connect the two areas mentioned above and achieve signal transmission and electrical safety isolation. It not only undertakes the function of data interaction, but also constitutes a physical barrier to prevent high voltage from entering the low voltage side and endangering personal and equipment safety.

[0227] In some implementations, the central control computer in the low-voltage control area establishes communication connections with various heterogeneous devices in the high-voltage test area through multiple types of isolation links. Specifically, the trigger controller is connected to the trigger control interface on the low-voltage side via a fiber optic trigger link to transmit high-precision trigger commands and synchronization signals.

[0228] The acquisition equipment / temporary storage instrument is connected to the confirmation evidence normalization module on the low-voltage side via a high-speed network fiber optic link, which is used to transmit back the preparation status, configuration confirmation information and experimental data.

[0229] PLC power supplies, RTU arc power supplies, and safety interlocks are connected to the corresponding low-voltage side equipment communication interfaces via electrical isolation links (such as optocoupler-isolated digital input / output channels or isolated serial buses).

[0230] Step S902: The isolation link includes at least one of the following: fiber optic trigger link, high-speed network fiber optic link, or electrical isolation link.

[0231] Among them, the fiber optic trigger link refers to a point-to-point fiber optic channel dedicated to transmitting trigger pulses, synchronization clocks or enable signals. Its characteristics are extremely high requirements for timing accuracy, small data volume but strong real-time performance, and it usually adopts dedicated protocols or hardware-level coding.

[0232] High-speed network fiber optic links refer to fiber optic communication channels based on Ethernet or other high-speed serial protocols, used to transmit device status, configuration parameters, diagnostic data, or large-capacity acquired data. They are characterized by large bandwidth, complex protocol stacks, and queuing and retransmission mechanisms.

[0233] Electrically isolated links refer to communication channels that achieve electrical disconnection but signal conduction through devices such as optocouplers, magnetic couplers, or capacitor isolators. They are commonly used for cross-potential transmission of low-speed control signals, switching status, or traditional serial buses (such as RS485 / Modbus RTU).

[0234] The three link types mentioned above cover the full spectrum of communication needs in neutral beam injection devices, from nanosecond-level triggering to megabit-level data transmission.

[0235] In some implementations, the system assigns appropriate isolation link types to each heterogeneous device based on its functional attributes and security level.

[0236] For example, for the trigger controller that undertakes the core timing control of single-gun triggering, an optical fiber triggering link is used to ensure microsecond or even nanosecond level synchronization accuracy and anti-electromagnetic interference capability.

[0237] For acquisition devices / temporary storage instruments that need to transmit large amounts of waveform data or high-frequency sampling status, high-speed network fiber optic links are used to meet throughput requirements.

[0238] For safety interlocks that only require feedback on ready / fault switch status or for RTU arc power supplies that only require simple parameter settings, an electrical isolation link can be used.

[0239] In addition, in some high-reliability designs, critical equipment may have two or more redundant links (such as primary fiber triggering + backup electrical isolation). In this case, the system can configure link priority and switching logic in the confirmation protocol, and automatically degrade to the backup link for evidence collection when the primary link fails.

[0240] Step S903: The constraint parameters of the isolated link are used to determine the receiving time window, dynamic timeout value, or failure evidence judgment rules of the device communication interface.

[0241] Among them, the constraint parameters of the isolated link refer to a set of quantitative indicators that characterize the physical transmission performance and security and stability boundary of the link, including but not limited to propagation delay, jitter limit, bandwidth, maximum round-trip time, packet loss threshold, synchronization error constraint, link health status, etc.

[0242] The reception time window refers to the time interval during which the system determines whether a certain frame of confirmation evidence belongs to the current preparatory command. Its start and end times are determined by the link propagation characteristics.

[0243] The dynamic timeout value refers to the maximum time the system is willing to wait before the device confirms its decision. Its value needs to be adapted to the real-time load and transmission capacity of the link.

[0244] The failure evidence determination rule refers to the logical criteria that directly transform link-level anomalies (such as link interruption, synchronization loss, and excessive bit error rate) into evidence for device confirmation of failure.

[0245] In some implementations, when generating the confirmation protocol, the confirmation evidence normalization module actively queries the constraint parameters of the isolated link currently connected to the device and calculates or adjusts the key thresholds for evidence collection accordingly. Specifically, for trigger controllers connected via fiber optic trigger links, the system reads the nominal propagation delay of the link (e.g., 5μs / m × length + fixed photoelectric conversion delay) and the measured jitter upper limit (e.g., ±50ns), and sets "command transmission time + minimum propagation delay - jitter margin" as the starting point of the reception time window, and "command transmission time + maximum propagation delay + jitter margin + processing time" as the ending point.

[0246] Any acknowledgment frames that fall outside this window, regardless of whether their content is correct, are discarded by the frame filtering mechanism as invalid noise or remnants from the previous round, thereby preventing timing confusion caused by long-distance fiber optic transmission.

[0247] For data acquisition devices connected via high-speed fiber optic links, the system monitors the link's round-trip time (RTT) and bandwidth utilization in real time. When a significant increase in RTT due to large data pre-transmission is detected, the dynamic timeout value is automatically increased. In This helps prevent devices from being mistakenly identified as offline due to temporary network congestion.

[0248] Meanwhile, if the link health status field reports an excessive CRC error rate or low optical power, the system can directly generate link abnormal failure evidence based on the failure evidence judgment rules without waiting for the device to respond to the timeout, thus triggering the blocking strategy of the admission matrix.

[0249] For electrically isolated links, if a drop in the secondary power supply voltage of the isolation device or a signal distortion exceeding the threshold is detected, it can also be directly determined as a link-level failure.

[0250] It is important to note that this step establishes a complete causal chain from physical link constraints and software confirmation protocols to admission decision results. This means that link constraint parameters can be explicitly incorporated into the generation logic of the confirmation protocol, allowing the system to adaptively perceive and compensate for timing deviations and transmission uncertainties caused by different isolated links. This avoids misjudging legitimate responses as timeouts due to ignoring physical delays, and also prevents the misinterpretation of reflected noise or crosstalk as valid evidence due to excessive tolerance. This parameter adaptation mechanism based on physical evidence improves the robustness and accuracy of the trigger admission system under extreme conditions such as high voltage and strong interference, ensuring that every trigger decision is based on a real and reliable physical foundation.

[0251] The above-described response is merely a specific implementation of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for triggering admission by normalizing evidence to confirm heterogeneous devices, characterized in that, include: Obtain the confirmation evidence returned by the heterogeneous device in response to the preparatory command, as well as the security weight of the heterogeneous device; The confirmation evidence is mapped to a confirmation level based on the evidence depth, and a confirmation result is generated. When there is clear failure evidence indicating that the device has failed to confirm, the confirmation result is determined to be a failure. When there is no clear failure evidence and the highest confirmation level has not reached the preset minimum confirmation level, or when there is no resolvable confirmation evidence, the confirmation result is defined as unconfirmed. The confirmation result is mapped to the security weight input admission decision, and the trigger admission state is output; the security weight is used to determine the trigger admission state without changing the confirmation result. Based on the trigger admission state, the output of trigger commands or trigger enable signals is controlled through the trigger control interface.

2. The method for triggering admission by normalizing evidence for heterogeneous device verification according to claim 1, characterized in that, The process of mapping the confirmed evidence to a level of confirmation based on evidence depth specifically includes: The confirmation levels include a first confirmation level, a second confirmation level, a third confirmation level, and a fourth confirmation level, which are progressively higher. The first confirmation level corresponds to successful communication write or write response; the second confirmation level corresponds to write echo or confirmation frame matching; the third confirmation level corresponds to parameter readback results meeting preset tolerance; and the fourth confirmation level corresponds to status bit, fault bit, or interlock bit meeting preset safety conditions. The explicit failure evidence includes at least one of the following: communication write failure, verification failure, parameter readback exceeding the preset tolerance, status bit not ready, fault bit valid, or interlocking blockage. When the explicit evidence of failure exists, the confirmation result is determined to be a failure, and the explicit evidence of failure takes precedence over any successful write or echo matching evidence.

3. The method for triggering admission by normalizing evidence for heterogeneous device verification according to claim 1, characterized in that, The security weight is used to determine the process of triggering the admission state without changing the confirmation result, specifically including: The safety criticality level of the heterogeneous device is determined based on the safety weight. The safety criticality level does not change the confirmation result, but is only used to determine the output of the trigger access state. The access decision mapping takes the safety criticality level as the first dimension and the confirmation result and the type of non-confirmation reason as the second dimension. The trigger access status includes trigger allowed status, trigger blocked status, manual review status, or allow with warning status. When the security criticality level reaches a preset high level and the confirmation result is failure or unconfirmation, the access decision mapping outputs the blocking trigger state; When the safety criticality level is a preset low level and the confirmation result is unconfirmed, the access decision mapping outputs the warning-enabled permission status or the manual review status according to the type of unconfirmed reason; when the safety criticality level is a preset intermediate level and the confirmation result is unconfirmed, the access decision mapping outputs the manual review status or the prevention trigger status according to the type of unconfirmed reason.

4. The method for triggering admission by normalizing evidence for heterogeneous device verification according to claim 2, characterized in that, The process of obtaining confirmation evidence returned by heterogeneous devices in response to the preparatory command specifically includes: Frame filtering is performed on the confirmation evidence, and the frame filtering includes matching and verifying the source address, command identifier, reception time window, and protocol integrity. The confirmation evidence filtered through the frame is deduplicated based on a deduplication key consisting of device identifier, command identifier, task identifier, channel number, and command sequence number. If a timeout is confirmed, a retry or waiting will be performed. The timeout confirmation is determined based on the polling cycle, link latency, historical response statistics, and safety margin. When the confirmation timeout condition is exceeded and there is no clear evidence of failure, the confirmation result is defined as unconfirmed.

5. The method for triggering admission by normalizing evidence for heterogeneous device verification according to claim 3, characterized in that, When the trigger admission state is the manual review state, it also includes: In response to the manual review status being output by the admission decision mapping, the trigger control interface is kept from outputting the trigger command or the trigger enable signal; Receive the review results submitted by an authorized operator, write the review results as supplementary evidence into the confirmation record, and trigger the re-determination of the access decision mapping; The review result does not directly replace the confirmation level. When the review result is a review rejection or a review timeout, the blocking trigger status is output.

6. The method for triggering admission by normalizing evidence for heterogeneous device verification according to claim 5, characterized in that, The process of receiving the review results submitted by an authorized operator includes: Based on the aforementioned security criticality level, determine the required access level and review timeout limit for the review; Verify the identity and permissions of the operator; If the verification fails or no valid response is received within the verification timeout period, the verification result will not be used as a valid basis, and the trigger prevention status will be output.

7. The method for triggering admission by normalizing evidence for heterogeneous device verification according to claim 1, characterized in that, Before obtaining the confirmation evidence returned by the heterogeneous device in response to the preparatory command, the process also includes: When a task is triggered to enter a configuration-frozen state, the configuration snapshot is frozen. The configuration snapshot includes the trigger configuration, confirmation protocol, version of the admission decision mapping, device security criticality level, device dependencies, and protocol configuration. After the configuration snapshot is frozen, in response to receiving a configuration modification request, a new configuration snapshot with the parent snapshot identifier and the reason for modification is generated; The original configuration snapshot and its associated collected confirmation records are retained as historical audit records, and the collected confirmation records are not migrated as valid trigger access criteria under the new configuration snapshot.

8. The method for triggering admission by normalizing evidence for heterogeneous device verification according to claim 1, characterized in that, The process of obtaining confirmation evidence returned by heterogeneous devices in response to the preparatory command includes: Obtain the device dependencies between the heterogeneous devices and construct a directed dependency graph; Based on the directed dependency graph, the confirmation evidence is collected in parallel for heterogeneous devices that do not have the device dependency relationship, and the confirmation evidence is collected in groups according to the topological order for heterogeneous devices that have the device dependency relationship. If the confirmation result of the front-end device is a failure, and the security weight of the front-end device reaches the preset blocking level, skip the subsequent trigger preparation steps that depend on the front-end device, and output the trigger admission state as a blocked trigger state.

9. A heterogeneous device verification evidence normalization trigger access system, characterized in that, The system specifically includes: The central control computer is configured to execute a heterogeneous device confirmation evidence normalization trigger admission method as described in any one of claims 1 to 8, for generating a unified device confirmation record and outputting the trigger admission status; The device communication interface is configured to communicate with heterogeneous devices to obtain confirmation evidence. The trigger control interface is configured to control the output of trigger commands or trigger enable signals based on the trigger admission state.

10. A heterogeneous device verification evidence normalization trigger access system according to claim 9, characterized in that, The system is deployed in an environment that includes a low-voltage control area and a high-voltage test area, which are connected by an isolation link. The isolation link includes at least one of a fiber optic trigger link, a high-speed network fiber optic link, or an electrical isolation link; The constraint parameters of the isolated link are used to determine the receiving time window, dynamic timeout value, or failure evidence determination rules of the device communication interface.

Images