Graph-based accelerator natural language control method, device, equipment and medium

Abstract

The application discloses a kind of accelerator natural language control methods, device, equipment and medium based on atlas, it is related to particle accelerator control technical field, through the deep integration of natural language semantic scheduling module and accelerator field knowledge graph, it realizes the accurate conversion from unstructured natural language instruction to standardization equipment control command.The method comprises: receiving the first natural language text input by user, based on the natural language semantic scheduling module of pre-training, the first natural language text is parsed into control intent and parameter slot;Based on the pre-constructed accelerator field knowledge graph, the device topology structure and operation dependency relationship in the accelerator field knowledge graph are used to map the control intent and parameter slot to the accelerator device, and the control command sequence is generated by reasoning;Control command sequence is issued to target accelerator device, to control target accelerator device to execute corresponding operation.

Description

Technical Field

[0001] This application relates to the field of particle accelerator control technology, and in particular to a graph-based accelerator natural language control method, device, equipment and medium. Background Technology

[0002] Particle accelerators are large-scale scientific instruments with complex structures. Their control systems encompass a vast array of hardware, including magnets, vacuum pumps, radio frequency cavities, and beam measurement devices. Relying on a distributed control architecture, the operation of these devices generates massive amounts of time-series operational data. Although the underlying monitoring data is abundant, the recording and interaction of information during daily operation still heavily relies on manual intervention, resulting in a general problem of abundant data but insufficient effective information.

[0003] Regarding operational logs, existing particle accelerator operational logs mainly rely on manual recording by on-duty personnel through electronic log systems. Due to the lack of unified semantic standards, the logs are mostly unstructured free text, exhibiting serious semantic heterogeneity issues and making them difficult for computers to parse automatically. Furthermore, the log text lacks explicit correlation with process variables in the control system, forming information silos and resulting in low efficiency in fault debriefing.

[0004] In terms of alarm and fault diagnosis, existing alarm and diagnostic systems mainly use static thresholds to trigger alarms, lacking correlation analysis capabilities. This can easily lead to alarm storms during system-level failures, making it difficult for operators to pinpoint the root cause. Static thresholds cannot adapt to different operating modes, easily resulting in false alarms or missed alarms. Fault diagnosis relies heavily on expert experience, lacking a unified machine-readable knowledge base, making it difficult to effectively transfer experience.

[0005] In machine scheduling and human-computer interaction, there is a conversion barrier between the natural language control intentions of physicists and the structured instructions of the control system. Currently, this conversion relies entirely on manual operation, which is not only prone to input errors, but also lacks an automated safety verification mechanism, posing a safety hazard.

[0006] In summary, existing particle accelerators suffer from problems such as non-standard log recording, inability to automatically parse logs, unreasonable alarm mechanisms, and excessive reliance on manual fault diagnosis. This makes it difficult to translate natural language commands into control commands, hindering rapid fault location and safe and stable automated scheduling and operation. Summary of the Invention

[0007] In view of this, this application provides a graph-based accelerator natural language control method, device, equipment and medium, the main purpose of which is to solve the problem that existing particle accelerator natural language commands are difficult to convert into control commands, and cannot achieve rapid fault location and safe and stable automated scheduling operation.

[0008] In a first aspect, this application provides a graph-based accelerator natural language control method, which includes: The system receives first natural language text input by the user, and parses the first natural language text into control intent and parameter slots based on a pre-trained natural language semantic scheduling module. The natural language semantic scheduling module is configured to perform semantic vectorization representation of the natural language description and output intent classification results and slot sequence labeling results in parallel. Based on a pre-built accelerator domain knowledge graph, the control intent and parameter slots are mapped to accelerator devices using the device topology and operation dependencies in the accelerator domain knowledge graph, and control command sequences are inferred and generated. The accelerator domain knowledge graph is a multi-level semantic network data structure with accelerator devices as nodes and device topology connections and operation dependency logic as edges. The control command sequence is sent to the target accelerator device to control the target accelerator device to perform corresponding operations.

[0009] Secondly, this application provides a graph-based accelerator natural language control device, the device comprising: The parsing unit is used to receive the first natural language text input by the user, and parse the first natural language text into control intent and parameter slots based on the pre-trained natural language semantic scheduling module. The natural language semantic scheduling module is configured to perform semantic vectorization representation of natural language description and output intent classification results and slot sequence labeling results in parallel. The generation unit is used to map the control intent and parameter slots to accelerator devices based on a pre-built accelerator domain knowledge graph, utilizing the device topology and operation dependencies in the accelerator domain knowledge graph, and to infer and generate a sequence of control commands. The accelerator domain knowledge graph is a multi-level semantic network data structure with accelerator devices as nodes and device topology connections and operation dependency logic as edges. The control unit is used to send the control command sequence to the target accelerator device to control the target accelerator device to perform corresponding operations.

[0010] Thirdly, this application provides a computer device including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described method.

[0011] Fourthly, this application provides a computer storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.

[0012] By employing the above technical solutions, this application provides a graph-based accelerator natural language control method, apparatus, device, and medium. Compared with existing methods that rely on manual operation for accelerator natural language control, this application receives first natural language text input by the user, parses the first natural language text into control intentions and parameter slots based on a pre-trained natural language semantic scheduling module, which is configured to perform semantic vectorization representation of the natural language description and output intention classification results and slot sequence labeling results in parallel. Based on a pre-constructed accelerator domain knowledge graph, the control intentions and parameter slots are mapped to accelerator devices using the device topology and operation dependencies in the accelerator domain knowledge graph, and control command sequences are inferred and generated. The accelerator domain knowledge graph is a multi-level semantic network data structure with accelerator devices as nodes and device topology connections and operation dependency logic as edges. The control command sequences are then sent to the target accelerator device to control the target accelerator device to perform corresponding operations. The entire process achieves the following beneficial technical effects: By deeply integrating a natural language semantic scheduling module with a knowledge graph in the accelerator domain, precise conversion from unstructured natural language instructions to standardized equipment control commands is achieved. On one hand, utilizing semantic vectorization representation and parallel output mechanisms, user intent can be efficiently parsed and key parameters extracted, lowering the cognitive threshold for operators interacting with complex accelerator control systems and enabling an intuitive natural language interaction experience. On the other hand, leveraging the explicitly defined device topology and operational dependencies in the knowledge graph, abstract control intents are mapped to specific physical devices. The graph's reasoning capabilities automatically generate logically consistent control command sequences, effectively resolving instruction conflicts or misoperations caused by complex device coupling in traditional control methods. This significantly improves the intelligence level, operational safety, and accuracy of cross-device collaborative execution in accelerator control.

[0013] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0014] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a flowchart illustrating a graph-based accelerator natural language control method in one embodiment of this application. Figure 2 This is a schematic diagram of the construction process of an accelerator domain knowledge graph in one embodiment of this application; Figure 3 This is a schematic diagram of the process of constructing an accelerator process variable map that integrates a hierarchical classification system of process variables in one embodiment of this application; Figure 4 This is a flowchart illustrating the construction of an accelerator domain knowledge graph that integrates multiple types of sub-graphs in one embodiment of this application. Figure 5 This is a schematic diagram of the process for locating the root cause of a fault in one embodiment of this application; Figure 6 This is a schematic diagram of the risk identification and early warning process in one embodiment of this application; Figure 7 This is a fault location timing drift diagram in one embodiment of this application; Figure 8 This is a schematic diagram of the process of normalizing the text to be processed by log in one embodiment of this application; Figure 9 This is a flowchart illustrating the comprehensive static and dynamic verification process in a security verification sandbox environment according to one embodiment of this application. Figure 10 This is a flowchart illustrating the process of adding a security sandbox verification to the natural language semantic scheduling module in one embodiment of this application; Figure 11 This is a system architecture diagram of graph-based accelerator natural language control in one embodiment of this application; Figure 12 This is a schematic diagram of the structure of a graph-based accelerator natural language control device in one embodiment of this application; Figure 13 This is a schematic diagram of the device structure of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0015] The present application will be described in detail below with reference to the accompanying drawings and embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in the embodiments of the present application can be combined with each other.

[0016] In related technologies, particle accelerators suffer from problems such as non-standard log recording, inability to automatically parse logs, unreasonable alarm mechanisms, and excessive reliance on manual fault diagnosis. These issues make it difficult to convert natural language commands into control commands, hindering rapid fault location and safe and stable automated scheduling and operation.

[0017] To address this issue, this embodiment provides a graph-based natural language control method for accelerators, such as... Figure 1 As shown, the method includes the following steps: 101. Receive the first natural language text input by the user, and parse the first natural language text into control intentions and parameter slots based on the pre-trained natural language semantic scheduling module.

[0018] In this embodiment, the natural language semantic scheduling module is configured to perform semantic vectorization representation of natural language descriptions and output intent classification results and slot sequence labeling results in parallel. Specifically, the natural language semantic scheduling module is based on deep learning technology and first performs semantic vectorization representation on the input first natural language text. This process maps each word and sentence structure in the first natural language text to a high-dimensional vector space, enabling the computer to capture the deep semantic features and contextual relationships of the text. Through this vectorization representation, the user's true intent can be understood, going beyond mere surface-level text matching.

[0019] After semantic vectorization, the natural language semantic scheduling module employs a parallel processing architecture, outputting two results simultaneously. One is the intent classification result, used to determine the type of operation the user intends to perform, such as device control, status query, or parameter adjustment. The other is the slot sequence labeling result, used to accurately extract specific parameter information from the text, including key elements such as the target device name, operation value, and time parameters. This parallel output mechanism significantly improves the efficiency and accuracy of semantic parsing.

[0020] For example, in an accelerator control system, an operator inputs a natural language command: "Adjust the injector beam intensity to 10 mA." The control system performs semantic vectorization through a natural language semantic scheduling module, and outputs the intent classification result as parameter adjustment, while the slot sequence labeling result extracts the device as the injector, the parameter as beam intensity, and the value as 10 mA.

[0021] In particle accelerator control systems, operators need to frequently adjust various equipment parameters to ensure the accelerator's normal operation. Traditional methods require operators to use complex graphical interfaces or command lines, which are costly to learn and prone to errors. This embodiment achieves intelligent accelerator control through a natural language semantic scheduling module.

[0022] 102. Based on a pre-built accelerator domain knowledge graph, the control intent and parameter slots are mapped to accelerator devices using the device topology and operational dependencies in the accelerator domain knowledge graph, and a control command sequence is generated by reasoning.

[0023] In this embodiment, the accelerator domain knowledge graph is a multi-level semantic network data structure with accelerator devices as nodes and device topology connections and operational dependency logic as edges. In other words, the construction of the accelerator domain knowledge graph is based on a deep understanding of the accelerator system's domain knowledge. Each node in the accelerator domain knowledge graph represents a specific accelerator device, such as an injector, main accelerator, focusing magnet, deflecting magnet, etc. The edges between nodes represent the physical connections and operational dependency logic between devices; for example, a device can only operate after another device is started, or the adjustment of a certain parameter will affect the operating state of other devices.

[0024] After the natural language semantic scheduling module parses the control intent and parameter slots, the mapping process using the accelerator domain knowledge graph is to associate the abstract control intent and parameter information with specific accelerator devices. The reasoning process using the accelerator domain knowledge graph is to automatically generate a sequence of control commands that conforms to safety specifications and operational logic based on the operational dependencies between accelerator devices.

[0025] In practical applications, the accelerator system in the accelerator knowledge graph is decomposed into multiple subsystem nodes, including the power system, vacuum system, cooling system, injector, main accelerator, and beam transmission line. Edges between nodes represent startup sequence dependencies; for example, the power system must start first, the vacuum system needs to start after the power system stabilizes, and the injector can only operate after the vacuum system reaches the required level. Based on the topology and operational dependencies in the knowledge graph, a detailed sequence of control commands can be generated. First, the startup command for the power system is generated, including the power-on sequence and parameter settings for each sub-power supply. After the power system stabilizes, the startup command for the vacuum system is generated, including the startup sequence of the vacuum pumps and the target vacuum level. Next, the startup command for the cooling system is generated to ensure that all equipment operates at the appropriate temperature.

[0026] It should be noted that throughout the inference process, the system must adhere to the operational dependency logic defined in the accelerator domain knowledge graph. For example, before generating the main accelerator start command, the system checks whether the injector is functioning correctly; before generating the beam transfer command, the system verifies whether the parameters of all relevant magnet systems are correctly set. This knowledge graph-based inference mechanism ensures the security and reliability of the control command sequence.

[0027] 103. Send the control command sequence to the target accelerator device to control the target accelerator device to perform corresponding operations.

[0028] In this embodiment, the control command sequence distribution process can adopt a layered transmission architecture. First, the generated control command sequence is formatted and encapsulated, converting each command into a standard protocol format recognizable by the accelerator device. During encapsulation, a unique sequence identifier and timestamp are added to each command for subsequent execution tracking and status monitoring.

[0029] In the actual operation of a particle accelerator, it is assumed that the system has generated a sequence of ten control commands through the aforementioned semantic parsing and knowledge graph reasoning, used to initiate the accelerator's beam injection process. First, these ten control commands are formatted and encapsulated. Each control command is converted into a binary protocol format that the accelerator device controller can recognize. After encapsulation, the control command sequence is transmitted to each target accelerator device via Industrial Ethernet according to the execution order defined in the knowledge graph.

[0030] The first control command was sent to the power control system, requesting that the high-voltage power supply voltage of the main accelerator be set to a predetermined value. Upon receiving the command, the power control system immediately parsed and verified it. After confirming the completeness and validity of the command, it began executing the voltage adjustment operation. During execution, the power control system provided real-time feedback on the execution progress and current status to the main control system.

[0031] Once the power control system completes voltage adjustment and returns a success confirmation, the system immediately sends a second control command to the vacuum control system. Upon receiving the control command, the vacuum control system starts the vacuum pump unit and begins the vacuuming operation. The system continuously monitors changes in the vacuum level, and when the vacuum level reaches a preset threshold, the vacuum control system sends an execution completion signal to the main control system.

[0032] Subsequently, the system issues the remaining control commands sequentially according to a preset order. The third control command is sent to the cooling system to initiate water cooling circulation; the fourth control command is sent to the ion source system to begin generating the particle beam; and the fifth control command is sent to the pre-accelerator to prepare for receiving and accelerating the particle beam. The issuance of each command strictly follows the completion status of the preceding command, ensuring the safety and logical correctness of the operation.

[0033] It should be noted that the system implements multi-level safety monitoring during the execution of control commands. If a device malfunctions while executing a command, such as failing to achieve the required vacuum level or experiencing abnormal cooling system temperature, the system will immediately interrupt the issuance of subsequent control commands and activate the emergency plan. Simultaneously, the system will record detailed anomaly information to provide data support for subsequent fault diagnosis and system optimization.

[0034] The graph-based accelerator natural language control method provided in this application, compared with existing methods that rely on manual operation for accelerator natural language control, receives first natural language text input by the user. Based on a pre-trained natural language semantic scheduling module, the first natural language text is parsed into control intentions and parameter slots. The natural language semantic scheduling module is configured to perform semantic vectorization representation of the natural language description and output intention classification results and slot sequence labeling results in parallel. Based on a pre-constructed accelerator domain knowledge graph, the control intentions and parameter slots are mapped to accelerator devices using the device topology and operational dependencies in the accelerator domain knowledge graph, and control command sequences are inferred and generated. The accelerator domain knowledge graph is a multi-level semantic network data structure with accelerator devices as nodes and device topology connections and operational dependency logic as edges. The control command sequences are then sent to the target accelerator device to control the target accelerator device to perform corresponding operations. The entire process, through the deep integration of the natural language semantic scheduling module and the accelerator domain knowledge graph, achieves accurate conversion from unstructured natural language instructions to standardized device control commands. On the one hand, by utilizing semantic vectorization and parallel output mechanisms, user intent can be efficiently parsed and key parameters extracted, lowering the cognitive threshold for operators interacting with complex accelerator control systems and achieving a human-like natural language interaction experience. On the other hand, by leveraging the explicitly defined device topology and operational dependencies in the knowledge graph, abstract control intents are mapped to specific physical devices. The reasoning capabilities of the graph are used to automatically generate logically consistent control command sequences, effectively solving the problem of instruction conflicts or misoperations caused by complex device coupling in traditional control methods. This significantly improves the intelligence level, operational safety, and accuracy of cross-device collaborative execution in accelerator control.

[0035] In practical applications, accelerator systems, as complex large-scale scientific devices, contain numerous instruments and intricate operational logic, making traditional methods insufficient to meet the demands of modern intelligent control. By constructing a knowledge graph for the accelerator domain, tacit knowledge scattered throughout operational logs and design documents can be transformed into structured explicit knowledge. Furthermore, for example... Figure 2 As shown, the construction process of the accelerator domain knowledge graph includes the following steps: 201. Using semantic triple extraction technology, extract accelerator entities and their relationships from the accelerator's operation logs and design documents.

[0036] 202. Using the accelerator device graph as the basic level, the basic level is expanded and merged based on the accelerator entities and their relationships to construct a multi-level accelerator domain knowledge graph that includes device topology and operational dependencies.

[0037] In this embodiment, the construction of the accelerator domain knowledge graph adopts a bottom-up approach. First, a basic-level accelerator equipment graph is established. Then, semantic triple extraction technology is used to expand and integrate the basic level. Semantic triple extraction technology is the core technology for building a knowledge graph, capable of automatically identifying and extracting entities and their relationships from unstructured text data. Specifically, in the construction process, equipment operation records, fault information, and maintenance data are extracted from the accelerator's operation logs, while equipment specifications, connection relationships, and operating procedures are extracted from design documents. Through natural language processing technology, accelerator entities in the text, such as various magnets, power supplies, vacuum pumps, and other equipment, as well as the relationships between these entities, such as physical connections and operational dependencies, are automatically identified. The extracted accelerator entities and relationships are represented in the form of semantic triples, each containing three elements: subject, relation, and object. After quality verification and standardization, these triples are integrated into the knowledge graph with the accelerator equipment graph as the basic level. Through continuous expansion and integration, a multi-level accelerator domain knowledge graph containing device topology and operational dependencies is eventually formed.

[0038] The knowledge graph construction in the accelerator domain adopts a standardized ontology design, defining core classes including devices, signals, events, and locations, and core relationships including control, monitoring, feed, logical dependencies, and log entries. The graph construction process includes three stages: the static graph initialization stage parses experimental physics and industrial control system database files to establish control logic topology, and parses accelerator layout files to establish physical spatial relationships; the dynamic log fusion stage receives structured logs, extracts semantic triples, such as the association between devices and fault states, and inserts them into the graph database; the time-series index embedding stage stores the index keys and archive keys of signal nodes in the time-series database in the graph's signal node attributes, realizing multimodal fusion of graph and time series. This construction method organically combines static topology, dynamic operating status, and historical time-series data, providing comprehensive knowledge support for intelligent control of accelerators.

[0039] In the process of constructing a knowledge graph for a large-scale particle accelerator, a basic level of equipment graph is first established. This basic level includes the accelerator's main equipment nodes, such as ion sources, pre-accelerators, main accelerators, beam transport lines, and experimental terminals. Each equipment node is labeled with basic attribute information, such as equipment type, specifications, and installation location.

[0040] Next, semantic triples are extracted from the accelerator's operation logs. For example, from one operation log record, it is identified that the ion source device generated a particle beam of a specific intensity at a certain point in time; this information is extracted as a triple: ion source - generation - particle beam. From another log record, it is identified that the main accelerator performed an acceleration operation after receiving the particle beam, forming a triple: main accelerator - acceleration - particle beam.

[0041] Simultaneously, the topological connections between devices are extracted from the design documents. For example, the physical connection between the ion source and the pre-accelerator is identified from the system architecture diagram, forming a triple: ion source - connected to - pre-accelerator. The operational dependency that the pre-accelerator can only start after the ion source is functioning normally is identified from the operation manual, forming a triple: pre-accelerator - dependent on - ion source.

[0042] After extracting a large number of semantic triples, these triples are fused with the basic-level device graph. Through entity alignment and relation disambiguation techniques, the extracted entities are matched with nodes in the device graph, and the extracted relations are added as edges to the graph. For example, ion source device nodes are aligned with extracted ion source entities, and the resulting relations are used as edges connecting ion source nodes and particle beam nodes.

[0043] After multiple rounds of extraction and fusion, the final accelerator domain knowledge graph formed a multi-level semantic network structure. The first level is the device topology layer, which describes the physical connections between devices; the second level is the operation dependency layer, which describes the operational logic between devices; and the third level is the parameter association layer, which describes the mutual influence between device parameters.

[0044] Understandably, in accelerator operation and management, the number of process variables is enormous and their relationships are complex, making it difficult for traditional variable management methods to reflect the intrinsic connections between process variables and equipment. Establishing a hierarchical classification system for process variables and mapping it to a knowledge graph can achieve systematic management of process variables, integrating scattered process variable information into a unified knowledge framework, making the hierarchical relationships, classification attributes, and equipment associations of process variables readily apparent. Furthermore, such as... Figure 3 As shown, the construction process of the accelerator process variable map, which integrates a hierarchical classification system of process variables, includes the following steps: 301. Establish a hierarchical classification system for process variables. Based on the device topology in the accelerator domain knowledge graph, classify and categorize accelerator process variables hierarchically.

[0045] 302. Using the accelerator equipment map as anchor points, and based on the accelerator entities and their associations, the categorized and graded accelerator process variables are associated and mapped with the accelerator entities in the accelerator domain knowledge graph to generate an accelerator process variable map that integrates process variables.

[0046] In this embodiment, process variables are hierarchically divided and classified based on the device topology structure in the accelerator domain knowledge graph. The hierarchical division is determined by the importance and scope of influence of the process variables within the system, while the classification is based on dimensions such as the variables' functional attributes and physical characteristics. Then, using the accelerator device graph as anchor points, the classified and graded process variables are associated and mapped with accelerator entities in the knowledge graph. This association mapping process requires establishing correspondences between process variables and entities such as devices, signals, and events, ultimately generating an accelerator process variable graph that integrates the process variables. This process variable graph not only contains information about the process variables themselves but also fully preserves the association between the variables and the device topology.

[0047] During accelerator operation, the process variables are classified into four levels according to their impact on operational safety and availability. The first level is the machine protection and safety level. Process variables at this level are directly related to personal safety and critical equipment safety protection. For example, the vacuum valve status signal belongs to this level. When an anomaly occurs in the vacuum system, this signal immediately triggers the interlock protection mechanism, forcibly stopping the accelerator to prevent equipment damage or personnel injury. These process variables have the highest priority; the system will forcibly record their log information and write it to the database in real time to ensure that any anomaly can be fully tracked.

[0048] The second level is the critical operating parameter level. The process variables at this level are the core elements for maintaining the normal operation of the accelerator beam. Taking magnet current as an example, the current value of the magnet system directly determines the beam's transmission trajectory and focusing effect. Once the current fluctuates abnormally, the beam will deviate from its intended trajectory or even be lost. Therefore, when such parameters become abnormal, the system automatically records high-frequency sampling data within five minutes before and after the anomaly, providing complete timing information for fault analysis. Although these parameters do not directly trigger safety interlocks, they are crucial for the stable operation of the accelerator.

[0049] The third level is the beam quality parameter level. Process variables at this level are primarily used to evaluate and optimize beam performance indicators. Beam position monitor readings are a typical example; they reflect real-time beam position deviations during propagation. While they don't directly affect the accelerator's safe operation, they have a decisive impact on beam quality. These parameters are mainly used for long-term trend analysis and performance optimization, helping operators to promptly identify slow degradation trends in beam quality and thus make preventative adjustments.

[0050] The fourth level is the auxiliary monitoring level. Process variables at this level primarily provide information on the operating status of the environment and auxiliary equipment. Room temperature and humidity monitoring are typical examples of this level. While they do not directly participate in the core operation control of the accelerator, they reflect the suitability of the equipment's operating environment. When environmental parameters exceed normal ranges, although they will not immediately affect accelerator operation, long-term environmental anomalies may have a potential impact on equipment lifespan and stability. These parameters are typically recorded at a low sampling frequency and are mainly used for long-term monitoring and statistical analysis of environmental conditions.

[0051] During accelerator operation, log data generation is often accompanied by synchronous changes in multiple related process variables. Traditional logging methods focus only on anomalies in a single process variable, making it difficult to capture the relationships and contextual information between process variables. By introducing a context-aware correlation algorithm during manual log entry, a dynamic correlation between log events and related process variables is established, providing more comprehensive information support for fault diagnosis. This method not only improves the accuracy of anomaly detection but also reduces false alarm rates, avoiding misjudging normal fluctuations as faults.

[0052] The specific context-aware association algorithm first sets the association time window based on the log timestamp when the log is generated. For the first-level machine protection and security process variables, due to their extremely high response speed requirements, the association window can be set to ten milliseconds to ensure that instantaneous protection actions and rapid changes in related variables can be captured. For the second-level critical operating parameter process variables, the association window can be set to five minutes, which can cover the change trend over a longer period of time before and after the parameter anomaly occurs. The system performs a topology search based on the accelerator domain knowledge graph, starting from the device node corresponding to the log event and searching along the connection relationships and control logic relationships between devices to find all related process variable nodes. Then, it calculates the statistical values ​​of these process variables within the set time window, including mean, variance, maximum, and minimum values. The degree of change of each process variable is evaluated by calculating a standard score. The standard score can effectively measure the degree to which the variable deviates from the normal value, filtering out noisy data with small changes and retaining only abnormal process variables with significant abrupt changes for association.

[0053] As one specific implementation method, the construction process of an accelerator domain knowledge graph that integrates multiple sub-graphs can be found in [link to documentation]. Figure 4 As shown, Figure 4The entire processing flow is clearly presented in a three-part structure with left and right columns and a central convergence. The left area fully displays the log cleaning sub-process, starting from the log cleaning module. After extracting the description field, it enters the length judgment node. If the text length is less than eight characters, the system determines it as an invalid record and performs a deletion operation; otherwise, it enters the model input stage, where a pre-trained language model generates structured sentence-level records. Finally, after traversing all records, a complete cleaned file is output. The right area corresponds to the process variable data cleaning process. First, PV names are aligned and named in a standardized manner, then the validity of the PV is determined. If valid, the time-series data is retained; if invalid, it proceeds to the manual inspection stage. After manual confirmation, maintenance or deletion operations are determined based on the equipment status to ensure the accuracy and timeliness of the PV nodes in the graph. The dashed box in the middle contains the entity device normalization and alignment module. As a hub for the convergence of two streams, it receives the cleaning results from the left and right sides and performs multi-level entity mapping: first, it completes precise matching through a predefined thesaurus, then it uses a string similarity algorithm for fuzzy association, and finally combines semantic model and graph topology rules to complete the final verification and normalization, thereby uniformly mapping the device entities scattered in logs and PVs to standard graph nodes. Figure 4 The bottom clearly lists the components of the constructed accelerator domain knowledge graph, including multiple sub-graphs such as the device graph, entity attribute graph, device state graph, and PV time series graph, demonstrating the system's ability to support multi-level and multi-dimensional knowledge representation. This entire process not only achieves a comprehensive improvement in data quality but also fundamentally solves the information fragmentation problem caused by heterogeneous data sources.

[0054] In accelerator operation and management, the accuracy and efficiency of fault diagnosis directly affect the system's stability and operational efficiency. Traditional fault diagnosis methods mainly rely on human experience and rule bases, which are insufficient to address the fault propagation problem caused by multi-node coupling in the complex topology of accelerator equipment. Constructing a fault pattern library based on knowledge graphs and combining it with graph attention networks for intelligent matching can achieve rapid and accurate location of fault root causes, significantly improving the intelligence and accuracy of diagnosis. Furthermore, as... Figure 5 As shown, after establishing the hierarchical classification system for process variables in step 301, the method further includes the following steps: 401. Build a fault mode library.

[0055] 402. When an accelerator malfunction is detected, a real-time local subgraph containing contextual dependencies is extracted from the accelerator domain knowledge graph, using the current alarm node as the anchor point.

[0056] 403. Match the real-time local subgraph with the historical fault mode subgraphs in the fault mode library, and use a graph attention network to perform graph propagation calculation on the matching results. Evaluate the fault probability of each candidate root cause node in the real-time local subgraph based on the relational weights between nodes.

[0057] 404. Identify the candidate root cause node with the highest failure probability as the root cause device and obtain the failure type corresponding to the process variable associated with the root cause device.

[0058] In this embodiment, the fault mode library stores multiple historical fault mode subgraphs. Each historical fault mode subgraph is a subset of the device topology in the accelerator domain knowledge graph, meaning that each historical fault mode subgraph is a subset of the device topology in the accelerator domain knowledge graph, fully preserving the connection and dependency relationships between devices at the time of the fault. Simultaneously, each subgraph is labeled with a clear historical fault root cause tag, which has been verified by experts to ensure the accuracy of the fault mode. When the system detects an accelerator malfunction, it first extracts a real-time local subgraph centered on alarm process variables and related devices. This real-time local subgraph fully records the device status, parameter changes, and inter-device relationships at the time of the fault. Next, the system performs similarity calculations between the extracted real-time local subgraph and the historical fault mode subgraphs in the fault mode library, using a graph editing distance algorithm or graph neural network to assign different relationship weights to different nodes based on the control logic and historical fault propagation paths. By capturing deep dependencies between nodes through multi-layer graph propagation, the fault probability of each candidate root cause node in the real-time local subgraph is accurately assessed.

[0059] When the calculated similarity exceeds a preset threshold, the system automatically pushes corresponding diagnostic conclusions and handling suggestions, enabling rapid fault identification and response. For unknown faults where the similarity does not reach the threshold, the system initiates a reverse causal reasoning mechanism. This mechanism fully utilizes the logical dependencies between devices, starting from the fault phenomenon and tracing upwards along the dependency chain to gradually locate possible root causes of the fault. By analyzing the causal chains and state propagation paths between devices, the system can identify the root cause of the current anomaly, even if the fault pattern has not appeared in the historical database. This reasoning capability ensures the system's diagnostic coverage of novel faults, avoiding the limitations of traditional rule-based diagnostic methods.

[0060] Accordingly, the candidate root cause node with the highest failure probability is identified as the root cause device, and the failure type corresponding to the process variable associated with the root cause device is further obtained.

[0061] During accelerator operation, many failures do not occur suddenly, but rather follow a gradual process from abnormal parameters to equipment failure. Traditional monitoring methods often only issue alarms when parameters have exceeded limits, at which point a failure may have already occurred or is about to occur, making true preventative maintenance difficult. By combining equipment context information and deep learning time-series prediction models, the risk of parameter exceeding limits can be identified in advance, allowing preventative measures to be taken before failures occur, significantly improving the reliability and safety of accelerator operation. Furthermore, such as... Figure 6 As shown, after establishing the hierarchical classification system for process variables in step 301, the method further includes the following steps: 501. For key process variables in the accelerator control system, obtain the timing monitoring data of the key process variables in the current operating mode.

[0062] 502. Extract the device context information associated with the key process variables from the accelerator domain knowledge graph.

[0063] 503. Combining the device context information, the time series monitoring data is processed using a pre-trained deep learning time series prediction model to predict the future change trends of key process variables.

[0064] 504. Based on the comparison results between the future change trend and the preset safety threshold, identify the risk of parameter exceeding the limit in advance and generate an early warning signal, and obtain the risk level corresponding to the early warning signal.

[0065] In this embodiment, time-series monitoring data is first acquired for key process variables in the accelerator control system. These key process variables include parameters crucial to accelerator operation, such as magnet current, power supply voltage, and vacuum level. The system acquires real-time monitoring data for the corresponding process variables based on the current accelerator operating mode, such as injection mode, storage mode, or experimental mode. Then, device context information associated with these key process variables is extracted from the accelerator domain knowledge graph. This context information includes not only the topological connections of the devices to which the process variables belong but also physical coupling parameters between devices, such as electromagnetic coupling coefficients and thermal conductivity coefficients.

[0066] Next, the extracted device context information is combined with time-series monitoring data of key process variables and input into a pre-trained deep learning time-series prediction model for processing. This prediction model typically employs architectures such as Long Short-Term Memory networks or temporal convolutional networks, which can effectively capture long-term dependencies and periodic features in time-series data. During the training phase, the model learns the patterns of parameter changes in a large amount of historical operating data. Combined with device context information, it can more accurately predict the future trends of key process variables. The prediction results are then compared with preset safety thresholds. When the predicted value approaches or exceeds the safety threshold, the risk of parameter exceeding limits is identified in advance, and an early warning signal of the corresponding level is generated.

[0067] Specifically, predictive models combining long short-term memory networks and attention mechanisms can be deployed in accelerator systems, or transformer architectures using pure attention mechanisms can be employed. These deep learning models can effectively capture the time-series characteristics and long-term dependencies of process variables. In model design, the system fully utilizes the characteristics of attention mechanisms, enabling it to automatically focus on process variables closely related to the target device within the accelerator domain knowledge graph. By analyzing the topological connections and functional dependencies between devices, the system can identify the relevant variables that have the greatest impact on the operating state of the target device and assign them higher weights.

[0068] The predictive model continuously receives real-time process variable data streams and performs sequence modeling using a sliding time window approach. The model not only learns the historical variation patterns of individual variables but also comprehensively considers the collaborative variation trends of multiple related variables. During the prediction process, the model outputs the variation trajectory and confidence interval of key process variables over a future period, providing quantitative evidence for anomaly early warning.

[0069] The system employs a dynamic threshold mechanism for anomaly detection. This threshold is not a fixed value but rather adaptively adjusts based on equipment operating conditions, environmental conditions, and historical statistical characteristics. When the predicted result exceeds the dynamic threshold, the system automatically generates an alert log containing the anomaly type, scope of impact, and severity, and issues warnings to maintenance personnel through multiple channels.

[0070] During accelerator operation, the importance of process variables is not static. Certain variables may exhibit higher risk values ​​under specific operational phases or failure scenarios, and static classification systems cannot adapt to such dynamic changes. By dynamically adjusting the hierarchy of process variables based on failure type and risk level, the monitoring system can become more intelligent and adaptive, ensuring that high-risk variables receive higher priority attention and treatment.

[0071] Accordingly, based on the fault type and / or the risk level, the level of the corresponding process variable in the process variable classification system is adjusted; If the fault type indicates a serious fault, or the risk level exceeds a preset level, the process variable is elevated in the process variable classification system, so that it is treated as a high-priority variable in subsequent log parsing or anomaly monitoring.

[0072] Specifically, after the system completes fault diagnosis or risk warning, it automatically assesses the importance changes of relevant process variables based on the diagnostic results. If the fault type is determined to be a severe fault, such as equipment damage or system crash, which could cause significant losses, the system will automatically elevate the level of the associated process variable. Similarly, if the risk level of a risk warning signal exceeds a preset threshold, the system will also elevate the level of that process variable accordingly. Process variables with elevated levels will be treated as high-priority variables in subsequent log parsing and anomaly monitoring. This means the system will allocate more computing resources to these variables, adopt more refined monitoring strategies, and set stricter anomaly judgment criteria. Simultaneously, anomaly information for these high-priority variables will be highlighted in the logs, facilitating quick identification and handling by operations and maintenance personnel. This dynamic adjustment mechanism ensures that the monitoring system can continuously optimize based on actual operating conditions, concentrating limited resources on the variables requiring the most attention.

[0073] In the accelerator scenario, suppose the beam position monitor triggers an alarm. The system first extracts a local subgraph containing upstream and downstream power supply equipment, magnet equipment, and the control system, using this monitor as an anchor point. By matching with a fault mode library, this subgraph is found to be highly similar to historical power supply fault modes. Graph attention network calculations show that the power supply equipment has the highest failure probability, identifying it as the root cause device. Simultaneously, the system monitors a slow upward trend in the key process variable of magnet current. Combining this with the physical coupling relationship between the magnet and the power supply, the prediction model determines that the current will exceed the safety threshold within two hours, generating a medium-level warning signal.

[0074] Based on the results of fault diagnosis and risk warning, the system automatically adjusts the process variable classification system. If a fault is classified as a serious fault, or the warning risk level exceeds a preset threshold, the corresponding process variable's level is elevated. For example, the power supply voltage and magnet current are given higher priority in the system and will be treated as high-priority variables in subsequent log analysis and anomaly monitoring, ensuring that similar faults can be detected and addressed earlier. This dynamic adjustment mechanism enables the entire monitoring system to be continuously optimized and adapt to changes in the accelerator's operating status.

[0075] During the operation of the accelerator control system, the accuracy of fault diagnosis highly depends on the precise alignment of time-series data. However, in actual operation and maintenance scenarios, the time when manually recorded fault logs often lags behind the physical moment when the equipment fails. This time deviation causes the data window extracted during fault analysis to deviate from the actual fault point, seriously affecting the reliability of the diagnostic results. Maintenance personnel need time to discover anomalies, confirm fault phenomena, and record them in the logs, while the physical fault of the equipment may have occurred seconds or even minutes earlier. If data before and after the fault is extracted directly based on the log recording time, it will be impossible to capture the key signs before the fault occurred and the initial evolution of the fault, leading to biases in the root cause analysis. Therefore, it is necessary to establish a time-series drift calibration mechanism to precisely align manual logs with machine alarm signals, ensuring that fault analysis is based on the true physical timeline.

[0076] Specifically, the timing drift calibration mechanism can be implemented through fault location timing drift and associated window calibration. This process first receives log records of fault phenomena such as magnet tripping entered by maintenance personnel at specific times. Then, based on entity keywords extracted from the logs, the system automatically retrieves the corresponding device's main state process variable signal on the process variable timing axis. Within a preset search window range prior to the log entry time, the system intelligently locates the exact time when the process variable triggers the alarm and accurately calculates the time deviation between the two. This preset search window adopts an adaptive setting strategy; the search window length for first-level process variables is smaller than that for second-level process variables to accommodate the differences in response delay characteristics of events at different levels. The above implementation process can be referred to... Figure 7 As shown in the fault location timing drift diagram, this figure visually illustrates the timing deviation between the manual log recording time and the actual alarm trigger time of the device. The upper log timing axis represents the time point when maintenance personnel enter fault records, and the lower PV timing axis represents the physical moment when the corresponding process variable actually triggers the alarm signal. As can be seen in the figure, the fault record event occurs after the alarm trigger event, with a clear time interval between the two, marked by a triangle symbol T, representing the time deviation. This figure clearly reflects a common phenomenon in actual operation: due to the delay in manual response, the log recording time lags behind the physical time of the fault occurrence. The system corrects the log time reference by identifying the alarm trigger point and calculating the deviation based on this observable timing misalignment. Figure 7 The diagonal line connecting the alarm trigger point and the fault record point vividly illustrates the logical path by which the system establishes a mapping relationship between the two, providing a visual basis for subsequent window panning, feature extraction, and data association.

[0077] Based on the calculated time deviation, the system dynamically shifts and calibrates the data extraction window to accurately extract the real waveform data within a specific time period before and after the alarm time. The pre- and post-extraction durations of the extraction window can be flexibly configured according to the equipment type, process variable level, or current operating mode. When the system detects multiple candidate abnormal process variables, it prioritizes the calibration result corresponding to the higher-level process variable, or performs weighted fusion processing on multiple candidate times.

[0078] Finally, the system establishes a hash association between the calibrated time-series data snapshot and the original log entries to ensure the physical authenticity of the stored data. If the log description involves multiple device entities, the system associates the calibrated time-series snapshot with the corresponding device entities and records in detail the basis and confidence level of the deviation estimation used, providing complete data support for subsequent fault tracing and diagnostic interpretation.

[0079] In accelerator operation and management, the standardization and consistency of log recording are crucial for fault diagnosis and operational analysis. By introducing natural language processing technology to automatically convert unstructured text into standardized log records, log quality can be significantly improved, laying a solid data foundation for the intelligent operation and maintenance of accelerators. Furthermore, such as... Figure 8 As shown, the method also includes the following steps: 601. Receive the text to be processed at the log entry end.

[0080] 602. The pre-trained log semantic specification processing module identifies accelerator entities and action intentions in the text to be processed.

[0081] 603. Based on the accelerator entity and action intent, the text to be processed is automatically filled into a predefined semantic template to generate a standard log record that conforms to the predefined format.

[0082] In this embodiment, the text to be processed includes user-inputted second natural language text or log text written due to accelerator malfunctions. That is, whether it's the colloquial expression used by maintenance personnel to describe the fault phenomenon or the abnormal information automatically generated by the system, both will be collected uniformly at the log entry point. Then, the system calls a pre-trained log semantic standardization processing module, which transforms unstructured natural language text into structured data objects. This module uses a corpus-pretrained language model as its basic algorithm architecture, fully considering the strict real-time processing requirements of the control room workstation. It selects a pre-trained model based on an attention mechanism or its lightweight improved version, which can accurately identify accelerator entities in the text, such as device names, parameter names, and location information, while also understanding the user's action intent, such as fault reporting, parameter adjustment, and equipment maintenance.

[0083] In the standardized processing flow, when a user inputs natural language text, the system first performs word segmentation and entity information extraction. By establishing a fuzzy matching mechanism, the system can intelligently map non-standard expressions such as "correcting the ferroelectric power supply in sector two" to specific equipment entries in the system's equipment list. Finally, the system generates a standardized template containing tags for event type, involved equipment, fault symptoms, and handling suggestions, which is then stored in the log system after final user confirmation.

[0084] Based on the identified accelerator entities and action intentions, the text to be processed is automatically populated into predefined semantic templates. These semantic templates are pre-designed according to different log types and include standard fields such as timestamps, device identifiers, operation types, and parameter values. After population, standard log records conforming to a predefined format are generated. These records have a unified structure and clear semantics, facilitating subsequent storage, retrieval, and analysis. This process requires no manual intervention, achieving automation and standardization of log entry.

[0085] It's important to note that the importance and urgency of different process variables vary significantly during accelerator log processing. Treating all identified accelerator entities equally could lead to the overwhelming or misjudgment of critical information, impacting subsequent fault diagnosis and operational decisions. By using a process variable hierarchical classification system to constrain and filter identified entities, we can ensure that high-risk, high-priority process variables receive due attention in log processing. This approach achieves intelligent hierarchical logging, enabling the system to dynamically adjust processing strategies based on the actual importance of variables.

[0086] Correspondingly, after the pre-trained log semantic specification processing module identifies accelerator entities and action intentions in the text to be processed, it combines the process variable hierarchical classification system to perform constraint filtering on the identified accelerator entities, so as to assign higher weight priority to the accelerator entities corresponding to higher-level process variables; based on the constraint-filtered accelerator entities and action intentions, the text to be processed is automatically filled into the predefined semantic template.

[0087] Specifically, after the log semantic specification processing module identifies the accelerator entities and their action intentions, a process variable hierarchical classification system is introduced as a constraint filtering mechanism. First, the current process variable hierarchical classification system is obtained, which categorizes all process variables within the accelerator into different levels based on importance, risk level, and scope of impact. Then, the identified accelerator entities are matched and filtered to determine whether these entities correspond to higher-level variables in the process variable hierarchical classification system.

[0088] For accelerator entities corresponding to higher-level process variables, the system assigns them higher weight and priority. This means that in subsequent semantic template population, information about these entities will be processed and highlighted first. Simultaneously, the system adjusts the population strategy based on the entity's hierarchy; for example, it uses a more detailed description format for higher-level entities and a simplified description format for lower-level entities. This constraint filtering mechanism ensures that log records accurately reflect the severity and urgency of the actual situation.

[0089] Specifically, in the process of constraining and screening identified accelerator entities using a process variable hierarchical classification system, anchor entities are determined in the accelerator domain knowledge graph based on the identified accelerator entities. Anchor entities include anchor equipment, anchor components, or anchor systems. The retrieval priority, topology search radius, and association time window for different levels of process variables are determined according to the process variable hierarchical classification system. Starting from the anchor entities, a topology search is performed in the accelerator domain knowledge graph along equipment connection relationships, control dependencies, signal monitoring relationships, interlocking protection relationships, physical coupling relationships, and / or location proximity relationships to obtain a set of candidate process variables. An association reference time is determined based on log timestamps, event occurrence times, or alarm trigger times. Based on the association reference time and association time window, time-series data fragments of candidate process variables are extracted from the time-series database. The time-series data fragments are then processed... Feature calculations are performed to obtain the statistical and anomalous features of candidate process variables. Statistical features include one or more of the following: mean, extreme values, variance, standard deviation, and rate of change. Anomalous features include one or more of the following: limit exceedance points, state transition points, slope abrupt change points, alarm trigger points, and limit exceedance duration. Based on the process variable's level, the topological distance between the candidate process variable and the anchor entity, the semantic relevance between the candidate process variable and the action intent, and the anomalous features of the candidate process variable, the association score between the candidate process variable and the log event is calculated. The candidate process variables are then filtered and sorted according to the association score to generate an associated process variable dataset. Correspondingly, the associated process variable dataset is bound to the standard log record corresponding to the text to be processed to generate an enhanced standard log record containing log semantic information, device topology context information, and process variable temporal state information.

[0090] In the specific implementation process, the text to be processed is first segmented, entity recognized, intent recognized, and event type identified to extract equipment entities, component entities, system entities, location entities, fault phenomena, operation actions, and time information contained in the log text. Among them, equipment entities include magnets, power supplies, radio frequency cavities, vacuum pumps, beam diagnostic equipment, etc.; component entities include valves, coils, probes, controllers, etc.; action intents include alarms, trips, resets, parameter adjustments, checks, recovery, maintenance, etc.; event types include fault events, operation events, inspection events, maintenance events, and status record events.

[0091] After identifying log entities and action intents, the system maps the identified device, component, or system entities to standard entity nodes in the accelerator domain knowledge graph. For log texts containing non-standard names, abbreviations, or colloquial descriptions, the system performs entity normalization based on a device alias library, thesaurus, device numbering rules, and string similarity matching results, converting non-standard entity names in the logs into standard device or component nodes in the knowledge graph. If multiple device entities are identified in the log text, the system determines the primary anchor entity and secondary anchor entities based on their semantic roles in the text, action object relationships, and fault description locations. The primary anchor entity serves as the starting node for subsequent process variable association searches, while the secondary anchor entities are used to limit the search direction and filter candidate process variables.

[0092] After identifying the anchor point entities, a process variable association retrieval strategy is determined based on a process variable hierarchical classification system. This system categorizes accelerator process variables into at least four levels: safety interlock level, critical operation level, beam quality level, and auxiliary monitoring level. Different levels of process variables correspond to different retrieval priorities, time window lengths, topology search radii, and feature calculation methods. For example, safety interlock level process variables have the highest priority, prioritizing retrieval of process variables directly connected to or interlocked with the anchor point equipment; critical operation level process variables reflect equipment operating status, and the retrieval scope can be extended to equipment with control dependencies or upstream / downstream connections to the anchor point equipment; beam quality level process variables reflect beam transmission and quality changes, and the retrieval scope can be extended upstream and downstream along the beam path; auxiliary monitoring level process variables provide auxiliary status information such as environment, cooling, temperature, and humidity, and are associated when higher-level process variables fail to explain log events or require supplementary environmental context.

[0093] When specifically retrieving process variables, a topological search is performed along different types of edges in the accelerator domain knowledge graph, starting from the log anchor entity, to obtain a set of candidate process variables. Edges include equipment connection edges, control dependency edges, signal monitoring edges, interlocking protection edges, physical coupling edges, and location proximity edges. For safety interlocking level process variables, the search is prioritized along interlocking protection edges and signal monitoring edges; for critical operation level process variables, the search is prioritized along control dependency edges and equipment connection edges; for beam quality level process variables, the search is prioritized along beam transmission paths and equipment topological connection edges; and for auxiliary monitoring level process variables, the search is prioritized along location proximity edges and auxiliary system association edges. Through this hierarchical topological search, candidate process variables related to the current log event can be obtained from the knowledge graph, rather than simply relying on process variable name keyword matching.

[0094] Furthermore, the process variable association time window is determined based on the log timestamp, event description time, or system alarm time. If the text to be processed contains a clear event occurrence time, the event occurrence time is used as the association reference time; if the text to be processed does not contain a clear event occurrence time, the log entry time is used as the initial reference time; if the system can obtain the corresponding alarm trigger time from alarm records or equipment status change records, the alarm trigger time is used as the association reference time. The time window is set differently according to the process variable level. Among them, the association window of safety interlock level process variables is shorter and used to capture instantaneous events such as tripping, interlock triggering, and state change; the association window of critical operation level process variables is longer and used to capture the changing trends of operating parameters such as current, voltage, vacuum degree, and RF power before and after the event; the association window of beam quality level process variables is determined according to the beam adjustment cycle or operating mode and used to capture changes in parameters such as beam position, beam current intensity, and beam spot size; the association window of auxiliary monitoring level process variables can be set to a longer time range to analyze the potential impact of the environment or auxiliary systems on the event.

[0095] After determining the candidate process variable set and associated time window, the system extracts time-series data segments of the candidate process variables within the associated time window from the time-series database and preprocesses these data segments. Preprocessing includes timestamp alignment, missing value imputation, outlier removal, sampling frequency unification, and data normalization. For process variables with different sampling frequencies, the system selects a resampling strategy based on the process variable level and event type. For safety interlock-level process variables, high-frequency original sampling points or state transition points are retained. For critical operational-level process variables, continuous time-series trends before and after the event are calculated. For auxiliary monitoring-level process variables, low-frequency statistical values ​​or moving averages can be used to represent their state changes.

[0096] Subsequently, correlation features are calculated for the time-series data segments of each candidate process variable. These correlation features include, but are not limited to: mean, maximum, minimum, variance, standard deviation, rate of change, slope, peak value, trough value, number of limit violations, duration of limit violations, number of state transitions, alarm trigger point, difference before and after the event, and deviation from historical baseline values ​​within the event window. For state-type process variables, the system focuses on calculating state transition points, transition directions, and transition times; for analog process variables, the system focuses on calculating limit violation points, slope abrupt change points, fluctuation amplitude, and trend changes; for alarm-type process variables, the system focuses on calculating alarm trigger time, alarm duration, and alarm recovery time.

[0097] After calculating the correlation features, the correlation strength between candidate process variables and log events is evaluated based on multidimensional factors. These multidimensional factors include at least the level of the process variable, the topological distance between the process variable and the anchor entity, the semantic relevance between the process variable and the action intent, the significance of changes in the process variable's time-series data within the correlation time window, whether the process variable has exceeded limits or undergone a state jump, whether the device corresponding to the process variable is in the same subsystem or an adjacent topological region, and whether the process variable has historically been correlated with similar log events. The system can assign weights to the above factors, calculate a comprehensive correlation score for each candidate process variable, and rank the candidate process variables according to their comprehensive correlation scores.

[0098] For example, when the log text reads "Power supply to sector 2 calibration magnet tripped, beam position abnormal," the system first identifies "power supply to sector 2 calibration magnet" as a device entity, "tripped" as a fault event, and "abnormal beam position" as a fault phenomenon. It then maps this device entity to a standard power node in the knowledge graph and uses this power node as an anchor point to prioritize retrieving process variables that have interlocking, power supply, control dependencies, and beam path associations with it. The system can extract process variables such as the power supply's output current, output voltage, interlocking status, fault code, associated magnet current, adjacent beam position monitor readings, and upstream / downstream beam current intensity, and extract corresponding time segments within a set window before and after the log time. If the power supply interlocking status changes abruptly before the log time, the output current drops sharply, and the beam position process variable subsequently shifts significantly, the system determines that these process variables have a high correlation with the log event and writes them into the associated process variable dataset.

[0099] The aforementioned associated process variable dataset includes process variable identifier, process variable name, associated device, associated process variable level, topological path to the anchor entity, topological distance, association time window, time-series data segment, statistical characteristics, anomaly characteristics, association score, and association reason. The association reason explains the basis for associating the process variable with the log event, such as "there is a direct interlocking relationship with the anchor device," "a state transition occurs before or after the log time," "the safety threshold is exceeded within the association window," or "it is located downstream of the anchor device along the beam path and a synchronization anomaly occurs," etc.

[0100] Finally, the system binds the associated process variable dataset with standard log records, generating enhanced standard log records that include textual semantic information, device entity information, event intent information, process variable timing status information, and graph context information. Thus, the enhanced standard log records not only include the time, device, event type, and description content found in traditional logs, but also a list of process variables automatically associated with the log event, process variable timing segments, process variable anomaly characteristics, and associated explanatory information. Through this method, log records are no longer isolated text records, but rather establish explicit associations with the timing data of process variables in the control system, thereby providing a computable data foundation for subsequent timing drift calibration, root cause analysis, anomaly prediction, operational review, and semantic scheduling.

[0101] In the accelerator control system, the natural language semantic scheduling module realizes the intelligent conversion from user-inputted spoken commands to safety control commands. This module first performs deep semantic parsing of the user's input natural language commands, accurately identifying the user's operational intent and extracting key information elements, including the operation object, parameter names, and target values. Then, it intelligently maps this information to control commands in the accelerator control system. However, erroneous execution of control commands can lead to serious equipment damage or safety accidents. Traditional safety verification mechanisms often focus only on checking the range of a single parameter, making it difficult to detect complex interlocking conflicts and system-level risks. By constructing a safety verification sandbox environment, comprehensive static and dynamic verification can be performed before commands are issued, ensuring the safety and rationality of control commands. This method represents a leap from single-point verification to system-level verification, significantly improving the safety assurance capabilities of accelerator operation. Furthermore, as... Figure 9 As shown, prior to step 103, the method further includes the following steps: 701. Construct a secure verification sandbox environment.

[0102] 702. Map the control command sequence to logical predicates in the accelerator domain knowledge graph, and perform reasoning verification in the security verification sandbox environment by combining the local state subgraph and the interlocking logic rule set.

[0103] 703. If the verification fails, the conflicting nodes are traced back based on the topological relationship in the local state subgraph, and a rejection reason or correction suggestion is generated and fed back to the user; the control command sequence is sent to the target accelerator device only after the verification passes and a confirmation instruction is received.

[0104] Specifically, during the control command sequence generation stage, the system first generates candidate control command sequences and then sends these candidate control command sequences into the virtual control environment for safe simulation execution.

[0105] In this embodiment, the security verification sandbox environment is configured with static range verification rules and dynamic interlocking verification rules. The static range verification rules determine whether the target parameters in the control command sequence are within preset allowable upper and lower limits, such as the reasonable value range of parameters like current, voltage, and temperature. The dynamic interlocking verification rules are more complex. They retrieve the set of interlocking logic rules associated with the target accelerator device from the accelerator domain knowledge graph and obtain the corresponding local state subgraphs of the target accelerator device. These subgraphs contain the device's current operating state and its relationships with other devices.

[0106] In the security verification sandbox environment, the system maps control command sequences to logical predicates in the accelerator domain knowledge graph. These logical predicates accurately express the semantics and intent of the control commands. Then, the system performs reasoning verification by combining the local state subgraph and the interlocking logic rule set, checking whether the control commands conflict with the current system state and whether they violate interlocking logic between devices. If the verification fails, the system will trace the conflicting nodes backward based on the topological relationships in the local state subgraph to accurately locate the problem and generate detailed rejection reasons or correction suggestions to feed back to the user. Only after successful verification and receiving confirmation from the user will the system send the control command sequence to the target accelerator device.

[0107] In practical applications, the virtual environment fully replicates the operational logic of the real control system, enabling the verification of command feasibility without interfering with the actual equipment. The verification process includes a multi-layered protection mechanism. First, static limit checks are performed to ensure that set values ​​are strictly within the safe range allowed by the equipment. Second, dynamic interlock verification is executed, querying interlock rules in the system's knowledge graph in real time. For example, certain key parameters may be prohibited from being modified under specific operating modes. If a violation of interlock rules is detected, the system immediately intercepts the command and provides the user with detailed reasons for rejection and suggested modifications.

[0108] Specifically, a human-computer interaction security verification mechanism can be added to the natural language semantic scheduling module. This mechanism, through the deep integration of natural language understanding and knowledge graph interlocking rules, constructs a secure closed loop from user commands to device execution. The system first performs semantic parsing on the user's input natural language commands, accurately identifying the operational intent and extracting key entities and parameter information, laying the foundation for subsequent security verification. Then, it enters the core security sandbox verification stage. The system retrieves associated interlocking rule subgraphs from the knowledge graph, centered on the operation object, and performs multi-dimensional logical judgments based on real-time device operating status data. When a potential security risk is detected, the system immediately intercepts command execution and provides the user with detailed reasons for the blocking, including the triggered security rule identifier, the current status value of the conflicting parameters, a detailed explanation of why execution is not possible, and the feasible parameter adjustment range derived based on security constraints, guiding the user to correct the command. If the security verification passes, the parsed parameters are encapsulated into a standardized sequence of device control commands. Finally, the system enters a secondary human confirmation stage. The final operation can only be executed after the operator explicitly grants permissions, and the execution result is fed back in real time, ensuring the traceability and security of the entire control process.

[0109] For details on adding security sandbox verification to the natural language semantic scheduling module, please refer to [link / reference]. Figure 10 As shown, this diagram presents a clear decision tree structure, fully illustrating the entire processing flow from user command input to device execution feedback. The process begins at the user input command node, and after the command parsing module extracts the intent and parameters, it enters the core area of ​​the security sandbox verification. Figure 10 The left-hand branch illustrates the risk assessment path. When the system detects a security risk in an operation, the process transitions to a feedback and correction phase, providing the user with detailed blocking information and parameter adjustment suggestions. The right-hand branch corresponds to the safe passage path, where the system parses the verified parameters into a sequence of computer-executable control commands. A manual confirmation node is placed at the end of the process, emphasizing that all device operations require secondary authorization from the operator before execution, ultimately completing the execution feedback loop. The entire flowchart, through the organic combination of diamond-shaped judgment nodes and rectangular processing nodes, intuitively demonstrates how the system ensures device safety through a multi-layered security verification mechanism while maintaining operational convenience.

[0110] In practical applications, the aforementioned graph-based accelerator natural language control method deeply integrates knowledge graph technology with natural language understanding capabilities, achieving fully automated processing from user natural language commands to precise device control. See details... Figure 11As shown in the figure, this diagram illustrates a complete graph-based accelerator natural language control system architecture, exhibiting a hierarchical structure from bottom to top and from the outside in. The bottom layer represents the accelerator hardware equipment layer, listing typical subsystems such as the magnet system, power supply, and radio frequency cavity, with notes indicating that the actual equipment types are more diverse, reflecting the system's physical foundation and wide applicability. Hardware devices connect upwards via the EPICS control network, reporting device status information in real time and receiving control commands from the upper layers.

[0111] The EPICS control network, acting as an intermediate communication hub, not only handles command issuance and status feedback but also works in a two-way linkage with the fault location and anomaly prediction module. On one hand, it transmits detected anomaly signals to this module to trigger early warnings; on the other hand, it receives parameter tuning suggestions generated by the module, enabling dynamic optimization of operational strategies. This module automatically adjusts classification thresholds based on historical fault frequencies and current operational consequences, continuously improving prediction accuracy.

[0112] At the data processing level, the log semantic normalization input module is responsible for receiving log information entered by operations and maintenance personnel, standardizing it, writing it into the log database, and extracting the triple structure for building a knowledge graph. Another data stream comes from process variable time-series data, which is persistently managed through the data storage and interface module and synchronously linked to the knowledge graph construction stage.

[0113] The core of knowledge graph construction is undertaken by the semantic triple extraction and knowledge graph construction module. This module jointly extracts entities, relationships, and attributes from logs and process variables to form structured triples, and then maps them to entity devices to ultimately generate and store a complete knowledge graph. This knowledge graph further supports the PV hierarchical classification and association module, enabling the semantic classification and logical association of process variables, providing a basis for security verification.

[0114] The Natural Language Semantic Scheduling module, located at the system's top level, receives natural language commands from users, performs reasoning based on the constructed knowledge graph, and parses out the specific operational intent and parameter configuration. If the command poses a risk, it returns correction suggestions for the user to adjust; if the command is safe and feasible, it generates an executable assembly command and a simulation test plan, which, after user confirmation, are sent to the EPICS control network for execution. The entire process forms a closed-loop feedback mechanism, ensuring that the execution of every natural language command is based on sufficient knowledge support and security verification, achieving a human-machine collaborative, intelligent, and controllable accelerator operation mode.

[0115] Furthermore, as a specific implementation of the above method, embodiments of this application provide a graph-based accelerator natural language control device, such as... Figure 12 As shown, the device includes: The parsing unit 81 is used to receive the first natural language text input by the user, and parse the first natural language text into control intent and parameter slots based on the pre-trained natural language semantic scheduling module. The natural language semantic scheduling module is configured to perform semantic vectorization representation of natural language description and output intent classification results and slot sequence labeling results in parallel. The generation unit 82 is used to map the control intent and parameter slots to accelerator devices based on a pre-built accelerator domain knowledge graph, utilizing the device topology and operation dependency relationships in the accelerator domain knowledge graph, and to infer and generate a control command sequence. The accelerator domain knowledge graph is a multi-level semantic network data structure with accelerator devices as nodes and device topology connections and operation dependency logic as edges. Control unit 83 is used to send the control command sequence to the target accelerator device to control the target accelerator device to perform corresponding operations.

[0116] The graph-based accelerator natural language control device provided in this invention, compared with existing methods that rely on manual operation for accelerator natural language control, receives first natural language text input by the user. Based on a pre-trained natural language semantic scheduling module, the first natural language text is parsed into control intentions and parameter slots. The natural language semantic scheduling module is configured to perform semantic vectorization representation of the natural language description and output intention classification results and slot sequence labeling results in parallel. Based on a pre-constructed accelerator domain knowledge graph, the control intentions and parameter slots are mapped to accelerator devices using the device topology and operation dependencies in the accelerator domain knowledge graph, and control command sequences are inferred and generated. The accelerator domain knowledge graph is a multi-level semantic network data structure with accelerator devices as nodes and device topology connections and operation dependency logic as edges. The control command sequences are then sent to the target accelerator device to control the target accelerator device to perform corresponding operations. The entire process, through the deep integration of the natural language semantic scheduling module and the accelerator domain knowledge graph, achieves accurate conversion from unstructured natural language instructions to standardized device control commands. On the one hand, by utilizing semantic vectorization and parallel output mechanisms, user intent can be efficiently parsed and key parameters extracted, lowering the cognitive threshold for operators interacting with complex accelerator control systems and achieving a human-like natural language interaction experience. On the other hand, by leveraging the explicitly defined device topology and operational dependencies in the knowledge graph, abstract control intents are mapped to specific physical devices. The reasoning capabilities of the graph are used to automatically generate logically consistent control command sequences, effectively solving the problem of instruction conflicts or misoperations caused by complex device coupling in traditional control methods. This significantly improves the intelligence level, operational safety, and accuracy of cross-device collaborative execution in accelerator control.

[0117] In specific application scenarios, the device further includes: a map construction unit; The map construction unit is specifically used for: Using semantic triple extraction technology, accelerator entities and their relationships are extracted from the accelerator's operation logs and design documents. Using the accelerator device graph as the basic level, the basic level is expanded and fused based on the accelerator entities and their relationships to construct a multi-level accelerator domain knowledge graph that includes device topology and operational dependencies.

[0118] In specific application scenarios, the accelerator domain knowledge graph also includes an accelerator process variable graph mapped with process variables. The graph construction unit is further used for: A hierarchical classification system for process variables is established, and the process variables of the accelerator are hierarchically divided and classified based on the device topology in the knowledge graph of the accelerator domain. Using the accelerator equipment map as anchor points, the accelerator process variables after classification and grading are associated with the accelerator entities in the accelerator domain knowledge graph based on the accelerator entities and their associations, thereby generating an accelerator process variable map that integrates process variables.

[0119] In specific application scenarios, the device further includes: a fault determination unit; and / or a fault early warning unit; The fault determination unit is specifically used for: After establishing the hierarchical classification system for process variables, a fault mode library is constructed. The fault mode library stores multiple historical fault mode subgraphs, where each historical fault mode subgraph is a subset of the device topology in the accelerator domain knowledge graph and is labeled with historical fault root cause tags. When an accelerator malfunction is detected, a real-time local subgraph containing contextual dependencies is extracted from the accelerator domain knowledge graph, using the current alarm node as the anchor point. The real-time local subgraph is matched with the historical fault mode subgraphs in the fault mode library, and the graph attention network is used to perform graph propagation calculation on the matching results. The failure probability of each candidate root cause node in the real-time local subgraph is evaluated based on the relation weights between nodes. The candidate root cause node with the highest failure probability is identified as the root cause device, and the failure type corresponding to the process variable associated with the root cause device is obtained. The fault early warning unit is specifically used for: For key process variables in the accelerator control system, acquire time-series monitoring data of key process variables under the current operating mode; In the accelerator domain knowledge graph, device context information associated with the key process variable is extracted. The device context information includes the topological connection relationship and physical coupling parameters of the device to which the key process variable belongs. By combining the device context information, a pre-trained deep learning time series prediction model is used to process the time series monitoring data and predict the future change trends of key process variables. Based on the comparison between the future trend and the preset safety threshold, the risk of parameter exceeding the limit is identified in advance and an early warning signal is generated, and the risk level corresponding to the early warning signal is obtained. Accordingly, the map construction unit is further used for: Based on the fault type and / or the risk level, adjust the level of the corresponding process variable in the process variable classification system; If the fault type indicates a serious fault, or the risk level exceeds a preset level, the process variable is elevated in the process variable classification system, so that it is treated as a high-priority variable in subsequent log parsing or anomaly monitoring.

[0120] In specific application scenarios, the device further includes: a log processing unit; The log processing unit is specifically used for: The log entry terminal receives text to be processed, which includes second natural language text input by the user or log text written due to accelerator operation error. The pre-trained log semantic specification processing module identifies accelerator entities and action intentions in the text to be processed. Based on the accelerator entity and action intent, the text to be processed is automatically filled into a predefined semantic template to generate a standard log record that conforms to the predefined format.

[0121] In specific application scenarios, the log processing unit is further used for: After the pre-trained log semantic specification processing module identifies accelerator entities and action intentions in the text to be processed, it combines the process variable hierarchical classification system to perform constraint screening on the identified accelerator entities, so as to assign higher weight priority to the accelerator entities corresponding to higher-level process variables. Accordingly, based on the constrained accelerator entities and action intentions, the text to be processed is automatically filled into a predefined semantic template; The log processing unit is further configured to: Based on the identified accelerator entities, anchor entities are determined in the accelerator domain knowledge graph, and the anchor entities include anchor devices, anchor components, or anchor systems. Based on the process variable classification system, determine the retrieval priority, topological search radius, and association time window for process variables of different levels; Starting from the anchor point entity, a topological search is performed in the accelerator domain knowledge graph along device connection relationships, control dependency relationships, signal monitoring relationships, interlocking protection relationships, physical coupling relationships and / or location proximity relationships to obtain a set of candidate process variables; The associated baseline time is determined based on the log timestamp, event occurrence time, or alarm trigger time. Based on the associated baseline time and the associated time window, time series data fragments of candidate process variables are extracted from the time series database. The time series data segment is subjected to feature calculation to obtain the statistical features and abnormal features of the candidate process variables. The statistical features include one or more of the following: mean, extreme value, variance, standard deviation and rate of change. The abnormal features include one or more of the following: limit violation point, state jump point, slope change point, alarm trigger point and limit violation duration. Based on the level of the process variable, the topological distance between the candidate process variable and the anchor entity, the semantic relevance between the candidate process variable and the action intent, and the abnormal characteristics of the candidate process variable, the association score between the candidate process variable and the log event is calculated. Candidate process variables are filtered and sorted based on the association scores to generate an association process variable dataset; Accordingly, the associated process variable dataset is bound to the standard log record corresponding to the text to be processed to generate an enhanced standard log record containing log semantic information, device topology context information, and process variable timing status information.

[0122] In specific application scenarios, the device further includes: a sandbox verification unit; The sandbox verification unit is specifically used for: Before sending the control command sequence to the target accelerator device to control the target accelerator device to perform corresponding operations, a security verification sandbox environment is constructed. The security verification sandbox environment is configured with static range verification rules and dynamic interlock verification rules. The static range verification rules are used to determine whether the target parameters in the control command sequence are within the preset upper and lower limits. The dynamic interlock verification rules are used to retrieve the interlock logic rule set associated with the target accelerator device in the accelerator domain knowledge graph and obtain the local state subgraph corresponding to the target accelerator device. The control command sequence is mapped to logical predicates in the accelerator domain knowledge graph, and reasoning verification is performed in the security verification sandbox environment by combining the local state subgraph and the interlocking logic rule set. If the verification fails, the conflicting nodes are traced back based on the topological relationship in the local state subgraph, and a rejection reason or correction suggestion is generated and fed back to the user; the control command sequence is only sent to the target accelerator device after the verification passes and a confirmation instruction is received.

[0123] Based on the above-described graph-based accelerator natural language control method, this application also provides a computer storage medium storing a computer program that, when executed by a processor, implements the above-described graph-based accelerator natural language control method.

[0124] Based on this understanding, the technical solution of this application can be embodied in the form of a software product. The software product can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, or portable hard drive), and includes several instructions to cause a computer device (such as a personal computer, server, or network device) to execute the methods described in the various implementation scenarios of this application.

[0125] Based on the above-described graph-based accelerator natural language control method, in a virtual device embodiment, to achieve the above objectives, this application embodiment also provides a computer device, specifically a computer, smartphone, tablet computer, smartwatch, server, or network device, etc., the physical device including a storage medium and a processor; the storage medium is used to store computer programs; the processor is used to execute the computer programs to implement the above-described graph-based accelerator natural language control method.

[0126] Optionally, the physical device may also include a user interface, a network interface, a camera, radio frequency (RF) circuitry, sensors, audio circuitry, a Wi-Fi module, etc. The user interface may include a display screen, input units such as a keyboard, etc., and optional user interfaces may also include USB interfaces, card reader interfaces, etc. The network interface may optionally include standard wired interfaces, wireless interfaces (such as Wi-Fi interfaces), etc.

[0127] In an exemplary embodiment, see Figure 13 The aforementioned physical device includes a communication bus, a processor, a memory, and a communication interface. It may also include an input / output interface and a display device. The various functional units can communicate with each other via the bus. The memory stores a computer program, and the processor executes the program stored in the memory to perform the graph-based accelerator natural language control method described in the above embodiments.

[0128] Those skilled in the art will understand that the physical device structure for accelerator natural language control based on graphs provided in this embodiment does not constitute a limitation on the physical device, and may include more or fewer components, or combine certain components, or have different component arrangements.

[0129] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages the hardware and software resources of the aforementioned graph-based accelerator natural language control entity, supporting the operation of information processing programs and other software and / or programs. The network communication module is used to enable communication between the various components within the storage medium, as well as communication with other hardware and software in the information processing entity.

[0130] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented using software plus necessary general-purpose hardware platforms, or it can be implemented in hardware. By applying the technical solution of this application, compared with the existing methods, this application achieves accurate conversion from unstructured natural language instructions to standardized equipment control commands through the deep integration of a natural language semantic scheduling module and an accelerator domain knowledge graph. On the one hand, by utilizing semantic vectorization representation and parallel output mechanisms, user intentions can be efficiently parsed and key parameters extracted, reducing the cognitive threshold for operators to interact with complex accelerator control systems and achieving a human-like natural language interaction experience. On the other hand, by leveraging the explicitly defined device topology and operational dependencies in the knowledge graph, abstract control intentions are mapped to specific physical devices, and the reasoning ability of the graph is used to automatically generate logically consistent control command sequences, effectively solving the problem of instruction conflicts or misoperations caused by complex device coupling in traditional control methods, significantly improving the intelligence level, operational safety, and accuracy of cross-device collaborative execution of accelerator control.

[0131] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of a preferred embodiment, and the modules or processes shown in the drawings are not necessarily essential for implementing this application. Those skilled in the art will understand that the modules in the apparatus of the embodiment can be distributed within the apparatus of the embodiment as described, or can be modified to be located in one or more apparatuses different from this embodiment. The modules of the above-described embodiment can be combined into one module, or further divided into multiple sub-modules.

[0132] The serial numbers in this application are for descriptive purposes only and do not represent the superiority or inferiority of any particular implementation scenario. The above disclosures are merely a few specific implementation scenarios of this application; however, this application is not limited thereto, and any variations conceived by those skilled in the art should fall within the protection scope of this application.

Claims

1. A graph-based accelerator natural language control method, characterized in that, include: The system receives first natural language text input by the user, and parses the first natural language text into control intent and parameter slots based on a pre-trained natural language semantic scheduling module. The natural language semantic scheduling module is configured to perform semantic vectorization representation of the natural language description and output intent classification results and slot sequence labeling results in parallel. Based on a pre-built accelerator domain knowledge graph, the control intent and parameter slots are mapped to accelerator devices using the device topology and operation dependencies in the accelerator domain knowledge graph, and control command sequences are inferred and generated. The accelerator domain knowledge graph is a multi-level semantic network data structure with accelerator devices as nodes and device topology connections and operation dependency logic as edges. The control command sequence is sent to the target accelerator device to control the target accelerator device to perform corresponding operations.

2. The graph-based accelerator natural language control method according to claim 1, characterized in that, The construction process of the accelerator domain knowledge graph includes: Using semantic triple extraction technology, accelerator entities and their relationships are extracted from the accelerator's operation logs and design documents. Using the accelerator device graph as the basic level, the basic level is expanded and fused based on the accelerator entities and their relationships to construct a multi-level accelerator domain knowledge graph that includes device topology and operational dependencies.

3. The graph-based accelerator natural language control method according to claim 2, characterized in that, The accelerator domain knowledge graph also includes an accelerator process variable graph mapped to process variables, and the construction process of the accelerator domain knowledge graph further includes: A hierarchical classification system for process variables is established, and the process variables of the accelerator are hierarchically divided and classified based on the device topology in the knowledge graph of the accelerator domain. Using the accelerator equipment map as anchor points, the accelerator process variables after classification and grading are associated with the accelerator entities in the accelerator domain knowledge graph based on the accelerator entities and their associations, thereby generating an accelerator process variable map that integrates process variables.

4. The graph-based accelerator natural language control method according to claim 3, characterized in that, After establishing the hierarchical classification system for process variables, the method further includes: A fault mode library is constructed, which stores multiple historical fault mode subgraphs. Each historical fault mode subgraph is a subset of the device topology in the accelerator domain knowledge graph and is labeled with historical fault root cause tags. When an accelerator malfunction is detected, a real-time local subgraph containing contextual dependencies is extracted from the accelerator domain knowledge graph, using the current alarm node as the anchor point. The real-time local subgraph is matched with the historical fault mode subgraphs in the fault mode library, and the graph attention network is used to perform graph propagation calculation on the matching results. The failure probability of each candidate root cause node in the real-time local subgraph is evaluated based on the relation weights between nodes. The candidate root cause node with the highest failure probability is identified as the root cause device, and the failure type corresponding to the process variable associated with the root cause device is obtained. as well as, For key process variables in the accelerator control system, acquire time-series monitoring data of key process variables under the current operating mode; In the accelerator domain knowledge graph, device context information associated with the key process variable is extracted. The device context information includes the topological connection relationship and physical coupling parameters of the device to which the key process variable belongs. By combining the device context information, a pre-trained deep learning time series prediction model is used to process the time series monitoring data and predict the future change trends of key process variables. Based on the comparison between the future trend and the preset safety threshold, the risk of parameter exceeding the limit is identified in advance and an early warning signal is generated, and the risk level corresponding to the early warning signal is obtained. Correspondingly, if the fault type indicates a serious fault, or the risk level exceeds a preset level, the level of the process variable in the process variable classification system is raised, so that it is treated as a high-priority variable in subsequent log parsing or anomaly monitoring.

5. The graph-based accelerator natural language control method according to any one of claims 1-4, characterized in that, The method further includes: The log entry terminal receives text to be processed, which includes second natural language text input by the user or log text written due to accelerator operation error. The pre-trained log semantic specification processing module identifies accelerator entities and action intentions in the text to be processed. Based on the accelerator entity and action intent, the text to be processed is automatically filled into a predefined semantic template to generate a standard log record that conforms to the predefined format.

6. The graph-based accelerator natural language control method according to claim 5, characterized in that, After the pre-trained log semantic specification processing module identifies the accelerator entity and action intent in the text to be processed, the method further includes: By combining the process variable hierarchical classification system, the identified accelerator entities are constrained and screened to assign higher weight and priority to the accelerator entities corresponding to higher-level process variables. Accordingly, based on the constrained accelerator entities and action intentions, the text to be processed is automatically filled into a predefined semantic template; The combined process variable hierarchical classification system performs constraint screening on the identified accelerator entities to assign higher weight and priority to accelerator entities corresponding to higher-level process variables, including: Based on the identified accelerator entities, anchor entities are determined in the accelerator domain knowledge graph, and the anchor entities include anchor devices, anchor components, or anchor systems. Based on the process variable classification system, determine the retrieval priority, topological search radius, and association time window for process variables of different levels; Starting from the anchor point entity, a topological search is performed in the accelerator domain knowledge graph along device connection relationships, control dependency relationships, signal monitoring relationships, interlocking protection relationships, physical coupling relationships and / or location proximity relationships to obtain a set of candidate process variables; The associated baseline time is determined based on the log timestamp, event occurrence time, or alarm trigger time. Based on the associated baseline time and the associated time window, time series data fragments of candidate process variables are extracted from the time series database. The time series data segment is subjected to feature calculation to obtain the statistical features and abnormal features of the candidate process variables. The statistical features include one or more of the following: mean, extreme value, variance, standard deviation and rate of change. The abnormal features include one or more of the following: limit violation point, state jump point, slope change point, alarm trigger point and limit violation duration. Based on the level of the process variable, the topological distance between the candidate process variable and the anchor entity, the semantic relevance between the candidate process variable and the action intent, and the abnormal characteristics of the candidate process variable, the association score between the candidate process variable and the log event is calculated. Candidate process variables are filtered and sorted based on the association scores to generate an association process variable dataset; Accordingly, the associated process variable dataset is bound to the standard log record corresponding to the text to be processed to generate an enhanced standard log record containing log semantic information, device topology context information, and process variable timing status information.

7. The graph-based accelerator natural language control method according to any one of claims 1-4, characterized in that, Before sending the control command sequence to the target accelerator device to control the target accelerator device to perform corresponding operations, the method further includes: A security verification sandbox environment is constructed, which is configured with static range verification rules and dynamic interlock verification rules. The static range verification rules are used to determine whether the target parameters in the control command sequence are within the preset upper and lower limits. The dynamic interlock verification rules are used to retrieve the interlock logic rule set associated with the target accelerator device in the accelerator domain knowledge graph and obtain the local state subgraph corresponding to the target accelerator device. The control command sequence is mapped to logical predicates in the accelerator domain knowledge graph, and reasoning verification is performed in the security verification sandbox environment by combining the local state subgraph and the interlocking logic rule set. If the verification fails, the conflicting nodes are traced back based on the topological relationship in the local state subgraph, and a rejection reason or correction suggestion is generated and fed back to the user; the control command sequence is only sent to the target accelerator device after the verification passes and a confirmation instruction is received.

8. A graph-based accelerator natural language control device, characterized in that, The device includes: The parsing unit is used to receive the first natural language text input by the user, and parse the first natural language text into control intent and parameter slots based on the pre-trained natural language semantic scheduling module. The natural language semantic scheduling module is configured to perform semantic vectorization representation of natural language description and output intent classification results and slot sequence labeling results in parallel. The generation unit is used to map the control intent and parameter slots to accelerator devices based on a pre-built accelerator domain knowledge graph, utilizing the device topology and operation dependencies in the accelerator domain knowledge graph, and to infer and generate a sequence of control commands. The accelerator domain knowledge graph is a multi-level semantic network data structure with accelerator devices as nodes and device topology connections and operation dependency logic as edges. The control unit is used to send the control command sequence to the target accelerator device to control the target accelerator device to perform corresponding operations.

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

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

Images