Construction method of power system digital target range based on knowledge graph

Abstract

The application discloses a kind of based on knowledge graph's electric power system digital target range construction method, comprising: receiving target range construction instruction data, target range construction instruction data includes the topological structure and component type information of target electric power system described in declarative manner;Based on preset target range construction knowledge graph, target range construction instruction data is parsed and converted, generates target range construction list, and preset target range construction knowledge graph is the domain model for mapping electric power component entity into simulation resource entity;According to target range construction list, resource in simulation environment is dispatched and configured, and electric power system digital target range is constructed.Through based on preset target range construction knowledge graph, declarative description target range construction instruction data is parsed and resource mapping automatically, generates target range construction list, improves the construction efficiency and scene fidelity of electric power system digital target range, solves the problem that traditional construction method is highly dependent on artificial, inefficient and difficult to ensure the accuracy of electric power business logic.

Description

Technical Field

[0001] This invention relates to the field of power system simulation and network security testing technology, and in particular to a method for constructing a digital test range for power systems based on knowledge graphs. Background Technology

[0002] The power system is a critical infrastructure related to the national economy and people's livelihood, and its safe and stable operation is of paramount importance. As the power system becomes increasingly intelligent and networked, the cybersecurity threats targeting it are becoming more complex and covert. To effectively conduct cybersecurity defense capability verification, attack and defense drills, and fault and accident reproduction, building a highly realistic digital test range for the power system has become an urgent need for the industry.

[0003] Currently, the construction of such test ranges mainly relies on manual script writing, drag-and-drop graphical interfaces, or configuration based on fixed templates. While these methods can achieve basic functions, they have significant limitations in terms of construction efficiency, scenario realism, flexibility, and intelligence. On the one hand, manual methods heavily depend on expert experience, making the construction process cumbersome, time-consuming, and prone to errors, making it difficult to quickly respond to diverse exercise needs. On the other hand, existing methods mostly focus on topology simulation at the information network level, lacking in-depth modeling and automated mapping of the characteristics of power physical equipment, complex business logic, and information-physical coupling relationships. This results in test range environments that are "similar in form but not in essence" to real power systems, making it difficult to accurately simulate the complex consequences such as cascading failures caused by network attacks.

[0004] Furthermore, the scheduling and configuration of range resources (such as simulation software, hardware-in-the-loop devices, and computing nodes) are often accomplished through preset rules or simple matching, which cannot achieve globally optimized resource deployment while meeting numerous constraints specific to the power sector (such as security partitioning, communication protocol matching, and real-time requirements). Although knowledge graph technology has been applied in fields such as power equipment management and fault diagnosis, how to construct a domain knowledge model specifically for range construction, and use it as the core to drive the automated and intelligent transformation and optimization from high-level business requirements to the underlying simulation resource list, remains a technological gap that has not been systematically addressed by existing technologies. Summary of the Invention

[0005] The purpose of this invention is to provide a knowledge graph-based method for constructing a digital test range for power systems. By automatically parsing and mapping resources of test range construction instructions based on a pre-defined test range construction knowledge graph, a test range construction list is generated. This significantly improves the construction efficiency and scene fidelity of digital test ranges for power systems, and solves the technical problems of traditional construction methods that are highly dependent on manual labor, inefficient, and unable to guarantee the accuracy of power business logic.

[0006] To address the aforementioned technical problems, a first aspect of this invention provides a method for constructing a digital test range for power systems based on knowledge graphs, comprising the following steps: Receive range construction instruction data, which includes topology and component type information of the target power system described in a declarative manner; The target range construction instruction data is parsed and transformed based on the preset target range construction knowledge graph to generate a target range construction list. The preset target range construction knowledge graph is a domain model used to map power component entities to simulation resource entities. Based on the test range construction list, resources in the simulation environment are scheduled and configured to construct the digital test range of the power system.

[0007] Furthermore, the received range construction instruction data includes topology and component type information of the target power system described in a declarative manner, including: Obtain the range construction request data used to define the target power system functions and scale to be simulated; The target range construction request data is parsed and elements are extracted to obtain the power component entities contained in the target power system and the electrical topology connection relationships between the power component entities; The power component entities and the electrical topology connections are used to generate standardized, identifiable power system model data. According to the declarative description preset specification, the power system model data is converted into structured test range construction instruction data. The declarative description preset specification defines the description syntax and data format of the power system topology and component types.

[0008] Further, the step of parsing and extracting elements from the target range construction request data to obtain the power component entities included in the target power system and the electrical topology connections between the power component entities includes: The range construction request data is input into the power equipment attribute and topology rule base, which defines the standard attributes, naming conventions, and allowed topology connection rules for power component types. Based on the power equipment attributes and topology rule base, entity recognition and relationship extraction are performed on the target range construction request data. The types and quantities of power components involved in the request data are identified, and the preset connection relationship descriptions between the power component types are extracted. Based on the power equipment attributes and the topology connection rules in the topology rule base, the extracted connection relationship descriptions are logically verified to obtain the electrical topology connection relationships that conform to the electrical connection rules. By associating the types and quantities of the power components with the electrical topology connections, the power component entities included in the target power system and the electrical topology connections between the power component entities are obtained.

[0009] Furthermore, the step of converting the power system model data into structured test range construction instruction data according to the predefined declarative description specification includes: The target range instruction data pattern is obtained from the predefined declarative description specification. The target range instruction data pattern defines the data fields, data types, and hierarchical relationships required for the structured description of the target power system. Extract the type identifier and attribute parameters from the power component entity, and obtain the electrical topology connection relationship; Based on the target range command data pattern, the type identifier, the attribute parameters, and the electrical topology connection relationship are filled into the corresponding data fields to generate initial command data; Based on the syntax rules in the predefined declarative description specification, the field relationships and value ranges in the initial instruction data are validated for compliance. The verified initial instruction data is serialized and encapsulated according to the standard data exchange format defined by the predefined declarative description specification to generate the structured target range construction instruction data.

[0010] Furthermore, the compliance verification of field relationships and value ranges in the initial instruction data based on the syntax rules in the predefined declarative description specification includes: The set of semantic rules for the power domain is obtained from the predefined declarative description specification. The set of semantic rules for the power domain defines the logical constraints on the component types and topological connections within the target power system. Based on the semantic rule set of the power field, the field relationships in the initial instruction data are checked for topological logic to verify whether the electrical topology connection relationship conforms to the connection rules and hierarchical relationships defined in the power equipment attributes and topology rule base. The value range in the initial instruction data is checked for attribute compliance based on the set of semantic rules for the power field, and it is verified whether the value of the attribute parameter matches the range of electrical parameters and physical constraints defined by the type identifier. Based on the results of the topology logic verification and the attribute compliance verification, the field relationships or attribute parameters that fail the verification are marked or preset automatic correction logic is executed.

[0011] Furthermore, the step of parsing and transforming the target range construction instruction data based on the preset target range construction knowledge graph to generate a target range construction list includes: Semantic parsing is performed on the target range construction instruction data to identify the power component entities and their structural relationships contained in the target power system; A mapping layer for a knowledge graph is constructed based on the preset target range to match a corresponding simulation resource entity for each identified power component entity. The mapping layer stores the mapping relationship between power component entities and simulation resource entities. Based on the resource compatibility rules and deployment constraints defined in the resource layer and constraint layer of the knowledge graph constructed in the preset target range, the matching simulation resource entities and their dependencies are constrained and solved to generate a set of simulation resource instances and their configuration relationships that satisfy all the resource compatibility rules and deployment constraints. The set of simulation resource instances and their configuration relationships are arranged according to a preset list format to generate the target range construction list used to directly drive resource scheduling and configuration.

[0012] Further, the step of solving for constraints on the matched simulation resource entities and their dependencies to generate a set of simulation resource instances and their configuration relationships that satisfy all the resource compatibility rules and deployment constraints includes: Based on the resource compatibility rules and deployment constraints, a set of constraints is constructed to describe the deployment relationships between the matched simulated resource entities. The constraint set and the optional instantiation options of the matched simulation resource entities are input into a preset constraint solver for calculation. The constraint solver outputs the selected instantiation options corresponding to each simulation resource entity and the deployment configuration relationship between entities. Based on the selected instantiation options and deployment configuration relationships output by the constraint solver, the set of simulation resource instances and their configuration relationships that satisfy all the resource compatibility rules and deployment constraints are generated.

[0013] Furthermore, the step of constructing a set of constraints based on the resource compatibility rules and deployment constraints to describe the deployment relationships between the matched simulation resource entities includes: The resource compatibility rules and deployment constraints are parsed to identify hard constraints and soft constraints. An adjustable weight factor is assigned to the soft constraints. The hard constraints are deployment conditions that must be met, and the soft constraints are deployment conditions that are expected to be met through optimization. Based on the preset target range, a resource layer of knowledge graph is constructed, and the instantiation cost vector of each simulation resource entity is determined. The instantiation cost vector includes at least quantitative indicators of computing resource overhead, network communication overhead, and power simulation fidelity overhead. The soft constraints are transformed into penalty terms according to their weights, and the instantiation cost vector is determined as the primary objective term. The penalty terms and the primary objective term are weighted and summed to form a comprehensive optimization objective function. The set of constraints includes the hard constraints that must be satisfied and the comprehensive optimization objective function used to drive the process.

[0014] Further, the step of inputting the set of constraints and the optional instantiation options of the matched simulation resource entities into a preset constraint solver for calculation includes: The matched simulation resource entities, their optional instantiation options, and the set of constraints are organized into standard input data for a multi-objective optimization problem that the constraint solver can process. The constraint solver is run to calculate the standard input data to obtain the Pareto optimal solution set; Based on the business preference strategy defined in the constraint layer of the knowledge graph constructed according to the preset target range, a final solution is selected from the Pareto optimal solution set. The final solution is subjected to deployment feasibility simulation verification. If the verification fails, the verification result is fed back as a new constraint and a re-solution is triggered until a feasible solution that passes the verification is obtained.

[0015] Furthermore, the step of scheduling and configuring resources in the simulation environment according to the test range construction list to construct the digital test range of the power system includes: The target range construction list is parsed to generate a specific deployment instruction sequence for the cloud resource manager, power simulation equipment controller, and network configuration interface; The deployment instruction sequence is issued to the cloud platform manager, simulator controller, and network device configuration interface, and the creation and configuration status of all simulation resource instances are monitored. According to the configuration relationships in the test range construction list, establish communication links and logical associations between all simulation resource instances to complete the construction process of the power system digital test range.

[0016] Accordingly, a second aspect of the present invention provides an electronic device, including: at least one processor; and a memory connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to cause the at least one processor to perform the above-described knowledge graph-based digital test range construction method for power systems.

[0017] Accordingly, a third aspect of the present invention provides a computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the above-described method for constructing a digital test range for a power system based on a knowledge graph.

[0018] The above-described technical solutions of the embodiments of the present invention have the following beneficial technical effects: 1. By receiving instruction data that declaratively describes the requirements of the test range, and using a pre-defined test range knowledge graph to automatically parse and transform it, a one-click generation from high-level business intent to low-level simulation resource list is achieved. This fundamentally transforms the test range construction mode from manual coding and configuration that heavily relies on expert experience to intelligent and standardized production driven by domain models, greatly improving construction efficiency, reducing technical barriers and human error rates, and ensuring that the constructed test range is highly consistent with the design intent at the topology and component levels. 2. Based on the structured mapping layer, resource layer, and constraint layer in the knowledge graph, simulation resources are automatically matched for power component entities. The complex resource compatibility rules and deployment constraints are formalized into solvable optimization problems. Through the constraint solver, Pareto optimal deployment schemes that meet multiple objectives are intelligently calculated. This not only achieves efficient and accurate matching of simulation resources, but also comprehensively considers multi-dimensional constraints such as cost, performance, and reliability at the global level, automatically generating the optimal or most reasonable resource scheduling and configuration scheme under given constraints, thereby significantly improving the overall efficiency and economy of range resource utilization. 3. By designing a complete technical closed loop from requirements analysis, intelligent matching, optimization solution to automated scheduling and deployment, and embedding quality assurance mechanisms such as semantic verification and feasibility simulation verification in key links, it is ensured that the final constructed digital power system test range is not a static, isolated set of resources, but a fully verified organic whole that can be directly started and operated. The closed-loop process ensures the high reliability and practical usability of the test range construction results, enabling it to stably and realistically support subsequent advanced application requirements such as network security attack and defense exercises, system testing, and fault reproduction. Attached Figure Description

[0019] Figure 1 This is a flowchart of a knowledge graph-based digital test range construction method for power systems provided in an embodiment of the present invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to specific embodiments and the accompanying drawings. It should be understood that these descriptions are merely exemplary and not intended to limit the scope of the invention. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concept of the invention.

[0021] Please refer to Figure 1 The first aspect of this invention provides a method for constructing a digital test range for a power system based on a knowledge graph, comprising the following steps: Step S100: Receive range construction instruction data, which includes the topology and component type information of the target power system described in a declarative manner.

[0022] First, the system receives test range construction instruction data submitted by users or upper-level systems. This instruction data is not a traditional procedural script or low-level configuration code, but rather uses a declarative description to define the state and structure that the target power system to be constructed should possess. For example, the instruction may include a description such as "construct a test network including two 220kV substations, four 110kV outgoing lines, and corresponding relay protection systems," and clearly specify the types of power components such as circuit breakers, transformers, and protection devices within the substations, as well as their electrical connections. This step receives such structured or semi-structured input data through a standard interface, providing accurate and easily parsed input specifications for subsequent automated processing.

[0023] The declarative description method described above only specifies the constraints and target states that the final system needs to meet, without specifying the specific operational steps or command sequences required to achieve those states. In the context of power system test range construction, the description focuses on defining the network topology (such as the connection methods of buses, lines, and transformers), component types (such as the model of protection devices and the rated parameters of circuit breakers), and their functional attributes (such as relay protection settings and communication protocols), thus clarifying "what" the system "is" and "what operating conditions it needs to achieve." Compared to traditional procedural scripts (i.e., writing detailed "how-to" instructions for each step), declarative descriptions transfer the complexity of system construction to the backend parsing and execution engine. It allows users or planners to express their intentions in a more natural form closer to business logic and engineering drawings, thereby freeing test range design from tedious and error-prone low-level coding work, improving the abstraction level, readability, and maintainability of the description, and providing clear and unambiguous structured input for subsequent automated resource mapping and optimization solutions based on knowledge graphs.

[0024] Step S200: Based on the preset target range construction knowledge graph, the target range construction instruction data is parsed and transformed to generate a target range construction list. The preset target range construction knowledge graph is a domain model used to map power component entities to simulation resource entities.

[0025] The system invokes and utilizes a pre-defined target range to construct a knowledge graph for deep analysis and intelligent transformation of received instruction data. The knowledge graph is a structured domain model that establishes a semantic mapping relationship from power component entities (such as specific models of line protection devices) to simulation resource entities (such as a virtual machine image or hardware-in-the-loop tester containing a specific simulation software version, vulnerability database, and communication protocol). The parsing process first performs semantic understanding of the instruction data, identifying the various power component entities mentioned and their topological relationships. Then, based on the mapping layer of the knowledge graph, the system queries and matches one or more candidate simulation resource entities for each identified entity. Further, based on the resource attributes, compatibility rules, and deployment constraints defined in the resource and constraint layers of the knowledge graph (e.g., requiring devices simulating the same protection panel to be deployed in the same low-latency network segment), the system comprehensively evaluates and optimizes all matching schemes, ultimately automatically generating a detailed target range construction list. This list precisely describes the set of simulation resources to be instantiated, the specific configuration parameters of each resource, and the interconnection relationships between resources.

[0026] In one specific embodiment of the present invention, the knowledge graph constructed in the preset target range adopts a hierarchical structure to organize domain knowledge. The mapping layer stores core mapping relationships in triples of the form "<subject, relation, object>", for example, it may contain records such as "<220kV intelligent substation monitoring host, isSimulatedBy, virtual machine image: SCADA_Center_v3.2>", associating power components with specific simulation resource templates. The resource layer describes the static capabilities and consumption of each simulation resource entity in the form of attribute tables, for example, defining the attribute set "{cpu_cores: 4, memory_gb: 16, preinstalled_software: ['IEC 61850 Stack v2.1']}" for the aforementioned image. The constraint layer uses production rules or logical expressions to define deployment constraints, such as the rule "IF resource_type == 'RTDS_Simulator' AND requirement == 'μs-level real-time performance' THEN deployment_location == 'High-PerformanceComputing Cluster A'", which ensures that domain knowledge can be computed and reasoned in resource matching and deployment planning.

[0027] Step S300: Based on the test range construction list, schedule and configure resources in the simulation environment to construct a digital test range for the power system.

[0028] Based on the test range construction list generated in step S200, the underlying simulation environment resource pool is driven to complete the physical construction of the test range. The system parses the list content and converts it into a series of executable operation instructions, such as requesting the creation of virtual machines of specified specifications from the cloud management platform, issuing specific model loading commands to the simulator control nodes, or configuring specified VLANs and routing policies through the network controller. The system schedules and monitors the execution of these instructions to ensure that all simulation resource instances successfully start and complete interconnection configuration as required by the list. After all resources are ready, the system coordinates the various components for unified initialization, ultimately delivering a fully commissioned and ready-to-use digital power system test range instance.

[0029] This invention employs declarative descriptions to define construction requirements, utilizes structured domain knowledge graphs to automate and intelligently map and optimize business concepts to simulation resources, and ultimately completes automated resource configuration and range construction through integrated scheduling, forming a complete and efficient digital range construction process. This process effectively reduces reliance on manual operations during construction, improves construction efficiency and standardization, and ensures the accuracy and rationality of the constructed range in terms of business logic and resource configuration.

[0030] Compared to the traditional construction methods mentioned in the background, which rely on manual scripts, fixed templates, or simple rule matching, this invention achieves significant progress through the synergistic effect of a complete technology chain: "declarative requirement input - knowledge graph-driven parsing - automated multi-objective constraint solving - closed-loop verification execution." Specifically, the combination of declarative description and knowledge graph solves the problems of low efficiency and difficulty in ensuring the accuracy of domain logic in manual coding; automated solving based on multi-objective constraints overcomes the limitations of poor flexibility of fixed templates and the inability of simple rules to be globally optimized; and the closed-loop process, which includes semantic verification and simulation verification, eliminates the risk of errors being exposed only during the deployment stage in traditional open-loop construction, achieving a comprehensive improvement in construction efficiency, solution quality (including compliance and resource optimization), and final test range reliability, thus meeting the agile, intelligent, and high-fidelity construction requirements of modern power system digital test ranges.

[0031] Further, in step S100, the range construction instruction data is received. This range construction instruction data includes topology and component type information of the target power system, described declaratively, including: Step S110: Obtain range construction request data for defining the target power system functions and scale to be simulated.

[0032] The system receives initial target range construction request data through interactive channels such as graphical user interfaces, application programming interfaces (APIs), or file uploads. This request data defines the functional scope and physical scale of the target power system to be simulated. It can be expressed in natural language paragraphs, semi-structured forms filled with key parameters, or simplified graphical topology sketches. For example, users can submit a preliminary requirement through interface selection or text input: "Simulate a 220kV substation with a double busbar connection, configured with line differential protection and automatic reclosing functions, and connected to the opposite substation via two tie lines." This process allows the system to obtain the user's high-level, possibly not fully standardized, construction intentions and use them as raw input for subsequent automated processing, thus establishing a data bridge from user operation to system processing.

[0033] Step S120: parse and extract elements from the target range construction request data to obtain the power component entities included in the target power system and the electrical topology connection relationships between the power component entities.

[0034] The received range construction request data undergoes automated parsing and structured element extraction, relying on pre-defined knowledge sources in areas such as power equipment attributes and topology rule bases. Using natural language processing, keyword matching, or template parsing techniques, the system identifies the specific types of power equipment mentioned (e.g., "220kV circuit breaker," "main transformer"), their key attributes (e.g., rated current, turns ratio), and descriptive connection relationships (e.g., "connected to," "connected to busbar") from the request data. Subsequently, based on the equipment logical relationships and topology connection rules defined in the domain knowledge base (e.g., circuit breakers must be connected in series at both ends of the line), the extracted preliminary connection descriptions undergo logical verification, ambiguity elimination, and relationship completion. Finally, a clear set of system model elements is output, consisting of standardized power component entities and their electrical-compliant topological connections.

[0035] Step S130: Generate standardized, identifiable power system model data from the power component entities and electrical topology connections.

[0036] The power component entities and electrical topology connections extracted in step S120, which are still in the element list state, are transformed and integrated into a standardized, globally uniquely identifiable power system model data. A unique identifier is assigned to each identified component entity, and a complete set of attribute parameters is filled or completed according to a standard template. Simultaneously, the electrical topology connections are transformed into formalized connection pairs or adjacency matrices based on these unique identifiers. This standardized model data constitutes an intermediate representation layer, stripping away the potential diversity of representations in the original request, and fully representing the static structure and component composition of the target power system in an internally unified, machine-processable, and standardized data format.

[0037] Step S140: Based on the declarative description preset specification, the power system model data is converted into structured test range construction instruction data. The declarative description preset specification defines the description syntax and data format of the power system topology and component types.

[0038] Based on a pre-defined, strictly declarative description specification, standardized power system model data is transformed into final structured test range construction instruction data. This specification explicitly defines the syntax, data fields, type constraints, and serialization format (e.g., using a specific JSON or YAML-based schema) required to describe the power system topology and components. Following this specification, component identifiers, attribute sets, and topological connections in the model data are accurately mapped and populated into the corresponding data fields and nested structures defined in the specification. This transformation generates a test range construction instruction data set that is strictly formatted, fully structured, and conforms to the pre-defined syntax standards. This instruction data adopts a completely declarative paradigm, describing only the final state of the target system and containing no specific execution commands.

[0039] The above process, through parsing and extraction, standardized modeling and formatting transformation, ultimately generates a highly structured, machine-understandable and processable declarative range construction instruction. This effectively achieves the goal of transforming human professional intent into a precise computer-executable description, laying a solid and reliable data foundation for subsequent fully automated range resource mapping and construction.

[0040] Further, step S120 involves parsing and extracting features from the target range construction request data to obtain the power component entities included in the target power system and the electrical topology connections between these power component entities, including: Step S121: Input the range construction request data into the power equipment attribute and topology rule base. The power equipment attribute and topology rule base defines the standard attributes, naming conventions and allowed topology connection rules for power component types.

[0041] The received range construction request data is used as input and loaded into a pre-defined power equipment attribute and topology rule base for processing. This rule base is a structured domain knowledge base that formally defines the standard technical attributes, unified naming conventions, and permissible physical and logical connection rules between various components in the power system (such as transformers, circuit breakers, disconnectors, and protection devices). For example, the library explicitly defines a set of standard attribute fields (such as rated voltage, rated current, and tripping time) for a "220kV SF6 circuit breaker" and stipulates that its legal connection object is usually a "bus" or "transmission line," and not directly connected to another "circuit breaker."

[0042] Step S122: Based on the power equipment attributes and topology rule base, perform entity identification and relationship extraction on the target range construction request data, identify the types and quantities of power components involved in the request data, and extract the preset connection relationship descriptions between the power component types.

[0043] Based on a loaded rule base, the system performs automated parsing of construction request data. By integrating keyword matching, pattern recognition, or lightweight semantic analysis techniques, the system scans request text or structured data to identify the types of power components explicitly mentioned or implicitly referred to, as well as the number of their instances. For example, from the description "requires two main transformers and four outgoing lines," the system can identify the component type "main transformer" with a quantity of 2 and the number of "outgoing lines" (i.e., lines) with a quantity of 4. Simultaneously, phrases or structures expressing connection relationships, such as "connected to" and "from," are extracted from the description to form an initial set of connection relationship descriptions. This achieves the transformation from unstructured or semi-structured text to preliminary structured elements, completing the first machine-readable extraction of the system's constituent elements.

[0044] Step S123: Based on the power equipment attributes and the topology connection rules in the topology rule base, perform logical verification on the extracted connection relationship descriptions to obtain electrical topology connection relationships that conform to the electrical connection rules.

[0045] The original connection descriptions extracted in step S122 undergo logical verification and normalization based on electrical rules. According to the topology connection rules defined in the rule base, each extracted connection is checked for electrical logic compliance and completeness. For example, if the request describes "circuit breaker A connected to bus B," this relationship conforms to the rules and will be directly adopted. If the description is ambiguous or incomplete (e.g., only stating "line L connected" without specifying the connection point), it can be marked as needing completion according to the rule that "lines must be connected to two buses or substations." If the description violates basic rules (e.g., "voltage transformers are directly connected in series in the line"), it will be identified as a logical error. Through this verification, ambiguities can be corrected, implicit relationships can be completed, and illegal connections can be eliminated, ultimately outputting a set of self-consistent, normalized electrical topology connection relationships that conform to the basic principles of power network construction.

[0046] Step S124: Associate the types and quantities of power components with the electrical topology connection relationships to obtain the power component entities included in the target power system and the electrical topology connection relationships between the power component entities.

[0047] The information fusion operation integrates the identified and verified discrete elements into a complete, internally interconnected system model. Specifically, for each type and quantity of power component identified in step S122, a corresponding number of uniquely identified power component entities are instantiated. Subsequently, the standardized electrical topology connection relationships generated in step S123 are precisely associated and bound to the instantiated, corresponding specific power component entities, using their defined specific connection objects (such as "bus B1" and "circuit breaker QF1") as links. By generating a network model composed of specific entity objects and clearly defined connection relationships between entities, the model accurately reflects the composition and topology of the target power system.

[0048] Further, step S140, which converts the power system model data into structured range construction instruction data according to the predefined specifications of the declarative description, includes: Step S141: Obtain the range instruction data pattern from the declarative description preset specification. The range instruction data pattern defines the data fields, data types, and hierarchical relationships required for the structured description of the target power system.

[0049] By accessing and loading a predefined declarative description specification, the target range instruction data pattern is obtained. This data pattern is a structured schema definition that precisely specifies all the data fields required to fully describe a target power system, the allowed data types for each field (such as strings, integers, floating-point numbers, booleans, or nested objects), the hierarchy and subordination relationships between fields, and the necessary constraints. For example, the schema might define a top-level Substation object, which contains a voltageLevel field and an array field named CircuitBreakers. Each element in the array is an object that must contain subfields such as id (identifier) ​​and ratedCurrent (rated current). This provides a blueprint and data architecture that must be strictly followed for subsequent data assembly, ensuring that all generated instruction data is structurally consistent and standardized.

[0050] Step S142: Extract the type identifier and attribute parameters from the power component entity, and obtain the electrical topology connection relationship.

[0051] From the standardized power system model data generated in the preceding steps, the core information required for the conversion is read and extracted. This includes extracting the standardized type identifier (e.g., "220kV_SF6_CircuitBreaker") and a complete set of attribute parameters (e.g., {"ratedVoltage": 220, "breakingCapacity": 50}) from each power component entity, and simultaneously acquiring a validated set of electrical topology connection relationships representing the connections between entities (e.g., [{"from": "BusBar_A", "to": "CB_01"}, …]). This information constitutes the main body of the final instruction data, completing the accurate acquisition of the modeled information.

[0052] Step S143: Based on the target range command data pattern, fill the type identifier, attribute parameters and electrical topology connection relationship into the corresponding data fields to generate initial command data.

[0053] Based on the target range command data pattern obtained in step S141, and using it as a template, the type identifier, attribute parameters, and topology connection relationships extracted in step S142 are systematically and one-to-one filled into the data fields specified by the pattern. For example, the type identifier "ThreeWinding_Transformer" of a "main transformer" entity is filled into the "equipmentType" field in the pattern, its capacity, short-circuit impedance, and other parameters are filled into the corresponding subfields under the parameters object, and its connection relationship with the bus is reflected in the "connections" list. Through this mapping and filling process, scattered information is systematically organized to generate an initial command data draft that fully conforms to the preset pattern requirements in terms of data structure. This draft has completely contained all the structural information of the target system in terms of content.

[0054] Step S144: Based on the syntax rules in the predefined specification of the declarative description, perform compliance verification on the field relationships and value ranges in the initial instruction data.

[0055] Based on the syntax and business rules defined in the declarative description pre-defined specifications that go beyond basic data types, a deep compliance check is performed on the initial draft instruction data. This check not only examines basic data types (such as ensuring that the rated current value is a number), but also focuses on verifying whether the logical relationships between fields and the data value range conform to the business semantics of the power industry. For example, the check may include: checking whether a "Bay" object contains at least one "CircuitBreaker" object; verifying that the entered protection settings are within the allowable setting range of the protection device model; and confirming that all device identifiers referenced in the topology connection relationship are explicitly defined in the instruction data.

[0056] Step S145: The verified initial instruction data is serialized and encapsulated according to the standard data exchange format defined by the predefined declarative description specification to generate structured target range construction instruction data.

[0057] After passing all compliance checks, the initial instruction data, which is structurally correct and valid in content, is serialized and encapsulated according to the standard data exchange format (such as JSON, YAML, or XML) specified by the declarative description predefined specification. This process converts (i.e., serializes) the structured data object in memory into a continuous string or byte stream that conforms to a standard format. For example, the final result is a well-formatted ".json" document that conforms to the predetermined JSON Schema. This document is the final structured range construction instruction data, which encapsulates all the constituent information of the target power system, described declaratively, in a standardized, platform-independent form that is easy to transmit and parse over a network, completely, accurately, and unambiguously.

[0058] Furthermore, step S144, based on the syntax rules in the predefined specification of the declarative description, performs compliance checks on the field relationships and value ranges in the initial instruction data, including: Step S1441: Obtain the set of semantic rules for the power domain from the predefined specification of the declarative description. The set of semantic rules for the power domain defines the logical constraints on the component types and topological connections within the target power system.

[0059] From the pre-loaded declarative description specifications, a specially defined set of semantic rules for the power industry is parsed and obtained. This set of rules goes beyond the basic data format definition, encoding a series of professional logical constraints and business rules in the field of power engineering. These rules exist as formalized conditional statements or constraint expressions, explicitly specifying the allowed or prohibited topological connections between different component types within the target power system, as well as the physical laws or engineering specifications that the attribute parameters of each component must satisfy. For example, the rule set may contain specific rules such as "voltage transformers must not be directly connected in series in the main circuit, but must be connected in parallel", "differential protection must act simultaneously on both sides of the circuit breaker of the protected line", and "the rated insulation voltage of all equipment on the same voltage level bus must be consistent", transforming the implicit knowledge of domain experts into a set of explicit rules that can be executed and queried by machines.

[0060] Step S1442: Perform topological logic verification on the field relationships in the initial instruction data according to the semantic rule set of the power field to verify whether the electrical topology connection relationship conforms to the connection rules and hierarchical relationship defined in the power equipment attributes and topology rule base.

[0061] The system uses the semantic rule set obtained from the application to perform topological logic-level compliance checks on the electrical topology connections described in the initial draft instruction data. This process iterates through all connections defined in the instruction data, and for each pair of connected entities, queries the rule set regarding the constraints on their respective component types to verify whether the connection is permitted and whether the connection method conforms to the hierarchical relationship. For example, the system checks whether a "line disconnecting switch" is correctly connected between a "bus" and a "line circuit breaker," rather than directly connecting two "buses"; or it checks whether the output of a "protection trip signal" is associated with the tripping coil of a "circuit breaker," rather than incorrectly associated with a "transformer" winding. This verification ensures that the described network topology is not only physically connected but also logically correct, complete, and compliant with safe operating procedures in the power system control and protection logic.

[0062] Step S1443: Perform attribute compliance verification on the value range in the initial instruction data according to the semantic rule set of the power field, and verify whether the value of the attribute parameter matches the range of electrical parameters and physical constraints defined by the type identifier.

[0063] Based on the same semantic rule set, attribute compliance verification is performed on the attribute parameter values ​​configured for each power component entity in the initial instruction data. This verification focuses on whether the parameter values ​​match the electrical characteristics and physical constraints implied by their type identifier. According to the component's type identifier (e.g., "Microcomputer Line Protection Device_Model A"), the rule set is used to find the parameter value range, unit system, and associated constraints with other parameters defined for that type. For example, the verification might check whether the "short-circuit impedance percentage" configured for a "220kV, 120MVA main transformer" falls within the typical design range (e.g., 10%-15%) for that type of transformer; whether the "resistance per unit length" configured for a "steel-cored aluminum stranded wire" conforms to its "cross-sectional area" and "material" parameters; or whether the "operating current setting" of an "overcurrent protection" is greater than the "maximum load current" of its "feeder," ensuring that the configuration of each component parameter has engineering rationality and physical feasibility.

[0064] Step S1444: Based on the results of topology logic verification and attribute compliance verification, mark or execute preset automatic correction logic for field relationships or attribute parameters that fail verification.

[0065] By combining the results of topology logic verification and attribute compliance verification, predefined processing strategies are executed for any non-compliant items found. For field relationships or attribute parameters that fail verification, they are explicitly marked, and the error type, location, and specific rule violated are recorded, generating a detailed verification report for user review and correction. Furthermore, for specific types of errors for which explicit automatic correction logic is defined in the rule set, automatic correction is triggered. For example, when a protection setting is found to slightly exceed the maximum allowable setting range of the device hardware, it is automatically adjusted to the maximum value within the allowable range; when a device model is detected to be incompatible with the connected voltage level, a compatible alternative model can be recommended based on the rules, and a replacement suggestion can be issued. This achieves a closed loop from verification results to processing actions, ensuring data quality while also improving automation capabilities and user experience to a certain extent.

[0066] Specifically, in step S200, the target range construction instruction data is parsed and transformed based on the preset target range construction knowledge graph to generate a target range construction list, including: Step S210: Semantic parsing is performed on the target range construction instruction data to identify the power component entities and their structural relationships contained in the target power system.

[0067] Deep semantic analysis is performed on the structured target range construction instruction data generated in step S100. Based on the ontology and data model of the power system domain, the precise semantics carried by the structured fields in the instruction data are understood. All explicitly declared power component entities, such as specific transformers, circuit breakers, and protection devices, are identified and extracted, and the defined electrical connections, hierarchical relationships, or functional associations between these entities are parsed. For example, from the instruction data, an entity identified as "Protection_Device_01" is identified, its type is "line differential protection device," and the protection object of this device is parsed to be associated with the two line entities "Transmission_Line_A" and "Transmission_Line_B." The above process yields a fully structured, machine-processable list of system components and their internal relationship network.

[0068] Step S220: Construct a mapping layer of the knowledge graph based on the preset target range, and match the corresponding simulation resource entity for each identified power component entity. The mapping layer stores the mapping relationship from power component entities to simulation resource entities.

[0069] Based on a pre-defined target range, a mapping layer is constructed within the knowledge graph to automatically search for and match one or more candidate simulation resource entities for each power component entity identified in step S210. The mapping layer stores specific mapping relationships from power domain concepts to simulation domain resources in the form of triples or rules. For example, a mapping rule might specify that "a line differential protection device of model PCS-931" can be mapped to "a PCS-931 simulation software Docker container template running on a specific Linux image," or to "a hardware-in-the-loop tester slot with a specific FPGA configuration." The matching process, based on precise matching or similarity calculation of component type and attribute characteristics, initially associates abstract power system design elements with specific, deployable simulation environment resource options, achieving the first crucial transformation from the business design layer to the simulation implementation layer.

[0070] Step S230: Based on the resource compatibility rules and deployment constraints defined in the resource layer and constraint layer of the knowledge graph constructed in the preset target range, the matching simulation resource entities and their dependencies are constrained and solved to generate a set of simulation resource instances and their configuration relationships that satisfy all resource compatibility rules and deployment constraints.

[0071] Based on the detailed rules defined in the resource and constraint layers of the knowledge graph constructed in the test range, the system performs global constraint satisfaction and optimization on all candidate sets of simulation resource entities and their interdependencies obtained in step S220. The resource layer describes the static attributes of the simulation resource entities themselves, such as computational resource consumption, supported protocols, and software license types. The constraint layer defines dynamic deployment rules, such as different simulation devices must be deployed in the same real-time network domain, specific software version conflicts, physical server resource capacity limits, and security partition isolation requirements. The system integrates the matching results, dependencies, and these multi-level rules, formalizing them into an optimization problem model containing a large number of variables and constraints, and calls the constraint solver for automatic calculation. The solver aims to find a feasible resource allocation and configuration scheme that selects a specific simulation resource instance for each power component from all candidate entities and determines its deployment parameters (such as IP address and host). This ensures that the scheme simultaneously satisfies all hard compatibility constraints and, where possible, optimizes soft objectives such as total cost, network latency, and load balancing.

[0072] To illustrate how domain knowledge can be transformed into a form that constraint solvers can process, let's take the business constraint "ensuring that the communication delay between the relay protection device and the corresponding merging unit simulation instance is less than 2 milliseconds" as an example. During modeling, this constraint is formalized as an inequality constraint involving deployment location variables. The system defines a Boolean variable "colocated[X, Y]" for the relevant simulation instances, indicating whether instances X and Y are deployed on the same physical host or tightly coupled computing nodes. The aforementioned delay constraint is transformed into "colocated[Protection_Device_P, Merging_Unit_M] ​​== TRUE", or into a constraint on the network latency variable "latency[P, M]" of "latency[P, M] < 2ms". Simultaneously, the "power simulation fidelity overhead" can be quantified as follows: choosing a high-fidelity electromagnetic transient model relative to a quasi-steady-state model adds a quantified cost increment ΔC to the objective function. This increment reflects the additional occupancy of dedicated computing hardware (such as FPGA resources).

[0073] Step S240: Arrange the set of simulation resource instances and their configuration relationships according to a preset list format to generate a target range construction list for directly driving resource scheduling and configuration.

[0074] The set of simulation resource instances and their configuration relationships generated after optimization in step S230 are standardized and arranged according to a predefined manifest format that can be directly read and executed by the downstream range scheduling and management system. This manifest format is a standardized data exchange format that clearly specifies how to organize the descriptions, configuration parameters, and network topology information of resource instances. Information about each resource instance in the solution result (such as the selected image ID, CPU / memory specifications, and allocated IP address) and its configuration relationships (such as VLAN ID and peer connection information) are populated into the corresponding fields and structures of the manifest file. The final generated range construction manifest is a complete, low-level, infrastructure-as-code deployment blueprint that describes every underlying resource object and its relationships required to build the target range.

[0075] Further, in step S230, constraint solving is performed on the matched simulation resource entities and their dependencies to generate a set of simulation resource instances and their configuration relationships that satisfy all resource compatibility rules and deployment constraints, including: Step S231: Based on resource compatibility rules and deployment constraints, construct a set of constraints to describe the deployment relationships between the matched simulation resource entities.

[0076] Based on the set of simulation resource entities and their inherent dependencies obtained from the previous steps, and combined with resource compatibility rules and deployment constraints extracted from the knowledge graph constraint layer, a formalized set of constraints is automatically constructed. This process first parses and classifies the rules and constraints, identifying hard constraints that must be unconditionally satisfied and soft constraints that can serve as optimization objectives. For example, hard constraints include "real-time simulation unit A and unit B must be deployed on the same physical server to ensure microsecond-level synchronization" and "simulation equipment involving the production control area must not share the physical network with equipment in the information management area"; soft constraints may include "distributing computationally intensive services across different hosts as much as possible to achieve load balancing" and "prioritizing images pre-installed with specific software versions to reduce deployment time." These rules, described in natural language or business logic, are transformed into mathematical inequalities, equations, or logical expressions that the constraint solver can understand. Simultaneously, the system obtains optional instantiation options (such as different virtual machine specifications and different deployment locations) and their related cost and performance attributes for each simulation resource entity from the knowledge graph resource layer, providing variables and objectives for subsequent optimization. This step abstracts and models the complex, multi-domain deployment planning problem into a well-defined constraint satisfaction problem or optimization problem model that includes variables, value ranges, constraints, and optimization objectives.

[0077] Step S232: Input the set of constraints and the optional instantiation options of the matched simulation resource entities into the preset constraint solver for calculation. The constraint solver outputs the selected instantiation options corresponding to each simulation resource entity and the deployment configuration relationship between entities.

[0078] The set of constraints constructed in step S231, along with the set of optional instantiation options for each simulation resource entity, are submitted as standardized input data to a pre-defined general or specific constraint solver for computation. Upon receiving this input, the solver (such as a solver engine based on mixed-integer programming, constraint programming, or heuristic algorithms) searches for one or more feasible solutions within its solution space. A feasible solution requires specifying a particular choice from the optional instantiation options for each simulation resource entity variable, determining specific parameters for the interconnections, locations, and other relationships between all entities, and ensuring that the choice fully satisfies all hard constraints. In the presence of soft constraints or optimization objectives, the solver strives to find the solution that best achieves the objective function value (e.g., lowest total cost, lowest average delay) among all solutions that satisfy all hard constraints; this is the optimal solution or Pareto optimal solution set. After the solution is completed, the solver outputs the results, which clearly indicate the specific instantiation option finally selected for each simulation resource entity (e.g., explicitly selecting "4-core, 8GB memory, virtual machine located in rack 3 of computer room A" as the host entity of a certain SCADA server), and the specific deployment configuration relationships between all entities derived therefrom (e.g., assigning the IP address "192.168.1.10" to the above SCADA server and specifying that it communicates with the two specified RTU simulators through VLAN 100).

[0079] Step S233: Based on the selected instantiation options and deployment configuration relationships output by the constraint solver, combine and generate a set of simulation resource instances and their configuration relationships that satisfy all resource compatibility rules and deployment constraints.

[0080] The system receives and parses the output of the constraint solver, instantiates and combines the abstract "selected options" and "configuration relationships" descriptions to generate a complete set of simulation resource instances and their configuration relationships that can directly guide deployment. Specifically, based on the selected instantiation options of each simulation resource entity, a concrete resource instance object with all runtime parameters is created or associated. For example, a selected "RTDS simulation node template" is transformed into a specific instance that requires the allocation of specific FPGA board resources and the loading of a specific power grid model file. At the same time, the deployment configuration relationships (network connections, dependency startup order, shared storage mount points, etc.) output by the solver are applied to these resource instances to form a complete inter-instance relationship network. The final generated set is a detailed blueprint of the test range's underlying resources that fully resolves all resource conflicts, satisfies all deployment rules, and achieves the optimization goals as much as possible. It not only lists which resources are needed but also clarifies the specific specifications, configuration parameters, and all interaction details with other resources for each resource.

[0081] Further, in step S231, based on resource compatibility rules and deployment constraints, a set of constraints is constructed to describe the deployment relationships between the matched simulation resource entities, including: Step S2311: Parse the resource compatibility rules and deployment constraints, identify the hard constraints and soft constraints, and assign adjustable weight factors to the soft constraints. Hard constraints are deployment conditions that must be met, and soft constraints are deployment conditions that are expected to be met through optimization.

[0082] The resource compatibility rules and deployment constraints obtained from the knowledge graph constraint layer are structured and classified. The parsing process categorizes constraints into hard constraints (those that must be absolutely satisfied) and soft constraints (those that can be used as optimization objectives) based on their enforceability in the deployment plan. Hard constraints typically involve security principles, physical laws, or functional necessities, such as "devices requiring 1 millisecond simulation real-time performance must be deployed on an operating system with a real-time kernel" or "monitoring hosts in Security Zone I and gateways in Security Zone II must be connected via a unidirectional isolation device." Soft constraints typically involve performance, economic, or management-related goals, such as "minimizing cross-data center network traffic" or "prioritizing the use of existing base images." Each identified soft constraint is assigned a configurable weight factor, quantifying its importance in the overall optimization objective. For example, "load balancing" might be assigned a higher weight, while "using specific vendor resources" might be assigned a lower weight.

[0083] Step S2312: Construct a resource layer of the knowledge graph based on the preset target range, and determine the instantiation cost vector of each simulation resource entity. The instantiation cost vector shall at least include quantitative indicators of computing resource overhead, network communication overhead and power simulation fidelity overhead.

[0084] The process queries and utilizes detailed information stored in the resource layer of the knowledge graph built from the preset target range to construct a quantified instantiation cost vector for each simulation resource entity matched in step S220. This vector is a multi-dimensional evaluation metric designed to comprehensively measure the various overheads involved in selecting a specific instantiation option for that entity. Specifically, computational resource overhead quantifies the cost of required cloud computing resources such as CPU, memory, and storage; network communication overhead assesses network latency, bandwidth consumption, or cross-domain communication costs due to the instance's deployment location. Furthermore, the vector includes a quantified metric specifically for the power simulation field: power simulation fidelity overhead. This metric measures the additional resource costs necessary to achieve specific simulation accuracy, real-time requirements, or physical effect realism; for example, the rental cost of a high-performance real-time simulation computer required to achieve microsecond-level electromagnetic transient simulation accuracy, or the cost of a dedicated commercial software license required to run a high-precision generator model. This process unifies resource consumption and performance requirements of different natures and units into a comparable and computable numerical vector, providing a unified quantitative input for global optimization.

[0085] Step S2313: Soft constraints are transformed into penalty terms according to their weights, and the instantiated cost vector is determined as the primary objective term. The penalty terms and the primary objective term are weighted and summed to form the comprehensive optimization objective function. The constraint set includes hard constraints that must be satisfied and the comprehensive optimization objective function used for driving the process.

[0086] First, the weighted soft constraints from step S2311 are transformed into penalty terms in the optimization problem according to their weights. When the final solution violates a soft constraint, its corresponding penalty term will generate a "cost" in the objective function that is proportional to the degree of violation and its weight. Second, the instantiation cost vectors generated for all simulation resource entities in step S2312 are aggregated (e.g., summed) to form the main objective term, which typically represents the total cost or expense to be minimized. Then, the main objective term is combined with the penalty terms corresponding to all soft constraints through weighted summation to form a single comprehensive optimization objective function. The value of this function comprehensively reflects the total cost of the deployment scheme and the degree to which the expectations of each soft constraint are met. Finally, the complete input model constructed for the constraint solver includes: a set of simulation resource entity instantiation options as decision variables, a set of hard constraints as boundary conditions that must be satisfied, and a comprehensive optimization objective function used to guide the search for the optimal solution. The above process expresses the business problem of "finding a deployment scheme that satisfies all mandatory rules and is overall optimal" as a standard mathematical optimization problem.

[0087] Further, in step S232, the optional instantiation options of the constraint set and the matched simulation resource entity are input into a preset constraint solver for calculation, including: Step S2321: The matched simulation resource entities, their optional instantiation options, and the set of constraints are organized into standard input data for a multi-objective optimization problem that the constraint solver can handle.

[0088] The matching results and constraint model obtained in the previous steps are converted into a standardized data structure required by the constraint solver. This process defines each "simulation resource entity" as a decision variable and its "optional instantiation options" set as the range of values ​​for that variable. Simultaneously, all hard constraints in the "constraint set" are transformed into mandatory restrictions on variable values, and the "comprehensive optimization objective function" is established as the target to be optimized. These elements are then arranged according to a specific data exchange format (e.g., using OPL language, MiniZinc model, or a specific JSON schema) to generate a complete, self-describing model file. This file, serving as standard input data, encapsulates all the mathematical definitions of the optimization problem to be solved and can be directly read and parsed by downstream constraint solvers or mathematical programming solvers.

[0089] Step S2322: Run the constraint solver to calculate the standard input data and obtain the Pareto optimal solution set.

[0090] The pre-defined constraint solver is invoked and run, loading the standard input data generated in step S2321 into the solver. The solver performs calculations within its vast combinatorial search space based on the model definition. Using its internal algorithms (such as scalar-based weighted sums, ε-constraints, or multi-objective evolutionary algorithms), the solver explores and computes a set of Pareto optimal solutions. Each solution in this set represents a feasible deployment scheme that satisfies all hard constraints, and there is no absolute superiority or inferiority among these schemes: no single scheme can further improve a particular objective without worsening at least one other objective (e.g., reducing total cost without increasing network latency or reducing simulation fidelity). The solver outputs this Pareto optimal solution set, describing the optimal trade-off boundary achievable among multiple competing objectives.

[0091] Step S2323: Based on the business preference strategy defined in the constraint layer of the knowledge graph constructed in the preset target range, a final solution is selected from the Pareto optimal solution set.

[0092] Based on a formally defined business preference strategy read from the constraint layer of the knowledge graph constructed from a pre-defined target range, a decision-making process is performed to select the Pareto optimal solution set. This strategy clarifies the core optimization orientation under different business scenarios. For example, the strategy might stipulate that "in cost-sensitive training scenarios, the solution with the lowest total economic cost is prioritized"; "in scientific research scenarios with extremely high simulation accuracy requirements, the solution with the highest power simulation fidelity is prioritized"; or "in scenarios that ensure system reliability, the solution with the highest resource redundancy is prioritized". According to the priority rules or trade-off weights specified by the strategy, all solutions in the Pareto solution set are evaluated and ranked, and the solution that best matches the current business preference is automatically selected as the final solution.

[0093] The business preference strategy is implemented in the system as a configurable weight vector or priority rule set for automated decision-making within the Pareto optimal solution set. For example, a strategy named "Cost Priority - R&D Testing" can be predefined in the strategy library. This strategy sets the weight of the "economic cost" dimension in the comprehensive optimization objective function to 0.7, the weight of "simulation accuracy" to 0.2, and the weight of "deployment speed" to 0.1. When this strategy is applied, all solutions in the Pareto solution set are sorted according to this weighted score, and the solution with the highest total score is automatically selected as the final solution. Another strategy, "Accuracy Priority - Incident Inversion," may assign higher weights to "simulation accuracy" and "time synchronization accuracy." This mechanism allows the same set of Pareto optimal solutions to adaptively derive the deployment plan that best suits the current business orientation based on different exercise objectives.

[0094] Step S2324: Perform deployment feasibility simulation verification on the final solution. If the verification fails, the verification result will be fed back as a new constraint and trigger a re-solution until a feasible solution that passes the verification is obtained.

[0095] The final solution selected in step S2323 undergoes a pre-deployment feasibility simulation verification. This verification is performed in an independent sandbox environment or through lightweight simulation, simulating potential problems encountered during actual deployment, startup, and basic integration testing in the target simulation environment, based on the resource configuration and relationships described by the solution. Verification may include checking port conflicts, evaluating startup dependency cycles, testing network connectivity, or verifying the reachability of specific real-time conditions. If the simulation verification is successful, the solution is confirmed to be feasible. If the verification fails, the specific reason for the failure (e.g., "Node A and Node B cannot complete the synchronization handshake within the required 1ms") is analyzed and transformed into a new, specific hard constraint (e.g., "Add constraint: Node A and Node B must be deployed in the same real-time computing domain"). The system feeds this new constraint back into the constraint set of step S231 and re-triggers the complete process from modeling to solving until a feasible solution that passes both theoretical constraint verification and deployment simulation verification is obtained.

[0096] Specifically, step S300, which involves scheduling and configuring resources in the simulation environment based on the target range construction list to construct a digital power system target range, includes: Step S310: Parse the target range construction list and generate a specific deployment instruction sequence for the cloud resource manager, power simulation equipment controller, and network configuration interface.

[0097] By parsing the target range build manifest generated in step S240, the abstract, declarative resource and configuration targets described therein are transformed into a series of specific, executable deployment operation instructions. This parsing process, based on the resource types, specifications, and configuration relationships defined in the manifest, and for the management domain to which different resources belong, calls the corresponding driver adaptation modules to generate an instruction sequence that conforms to the target management system's application programming interface specification. For cloud computing resources (such as virtual machines and containers) described in the manifest, creation and configuration instructions for cloud platform managers (such as OpenStack Nova API calls or Kubernetes YAML manifests) are generated; for power simulation-specific equipment (such as real-time digital simulators, power amplifiers, and protection testers), model loading, board configuration, and startup commands for specific simulator controllers are generated; for network devices (such as virtual switches, routers, and firewalls), VLAN partitioning, routing policies, and access control list configuration scripts for network configuration interfaces (such as via the NETCONF protocol or SDN controller REST API) are generated; thus realizing the transformation from a unified deployment blueprint to heterogeneous, specific execution commands.

[0098] Step S320: Issue a sequence of deployment instructions to the cloud platform manager, emulator controller, and network device configuration interface, and monitor the creation and configuration status of all simulation resource instances.

[0099] Through pre-defined communication channels and interfaces, the specific deployment instruction sequence generated in step S310 is distributed to the corresponding cloud platform manager, emulator controller, and network device configuration interface. Instructions can be distributed in parallel or executed in the order defined by dependencies. The system initiates comprehensive status monitoring of the instruction execution process, tracking the creation progress of each simulation resource instance (e.g., virtual machine status changing from "building" to "running"), the completion status of configuration tasks, and potential errors in real time by polling the status interfaces of each management system or receiving asynchronous event notifications. The monitoring process ensures that the instantiation process of all underlying resources conforms to the manifest requirements and triggers predefined error handling procedures, such as retrying, rolling back created resources, or issuing alarm notifications, in the event of a failure (e.g., resource request failure, configuration timeout).

[0100] Step S330: According to the configuration relationship in the test range construction list, establish the communication links and logical associations between all simulation resource instances to complete the construction process of the power system digital test range.

[0101] After all simulation instance resources have been successfully created and basic configurations completed according to the list, the system performs final integration and commissioning operations to establish organic connections between resource instances and complete the overall construction of the test range. This process executes a series of refined post-configuration steps based on the configuration relationships explicitly defined in the test range construction list. For example, it configures specified IP addresses for allocated virtual network cards and adds them to the correct VLANs; it sets up communication peering relationships and data exchange channels between simulation nodes in the simulator controller; and it writes access endpoint information for their dependent services into software components. Through these operations, discrete and independent simulation resource instances are systematically interconnected to form a complete system with specific network topology, data flow, and functional dependencies. Once all communication links and logical associations are established and basic connectivity tests are passed, the power system digital test range instance is considered to have been completed at the infrastructure level and is ready for subsequent loading of specific power grid models, initiation of simulation processes, or testing exercises.

[0102] Accordingly, a second aspect of the present invention provides an electronic device, including: at least one processor; and a memory connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to cause the at least one processor to perform the above-described knowledge graph-based digital test range construction method for power systems.

[0103] Accordingly, a third aspect of the present invention provides a computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the above-described method for constructing a digital test range for a power system based on a knowledge graph.

[0104] The embodiments of this invention aim to protect a method for constructing a digital test range for power systems based on knowledge graphs, which has the following effects: 1. By receiving instruction data that declaratively describes the requirements of the test range, and using a pre-defined test range knowledge graph to automatically parse and transform it, a one-click generation from high-level business intent to low-level simulation resource list is achieved. This fundamentally transforms the test range construction mode from manual coding and configuration that heavily relies on expert experience to intelligent and standardized production driven by domain models, greatly improving construction efficiency, reducing technical barriers and human error rates, and ensuring that the constructed test range is highly consistent with the design intent at the topology and component levels. 2. Based on the structured mapping layer, resource layer, and constraint layer in the knowledge graph, simulation resources are automatically matched for power component entities. The complex resource compatibility rules and deployment constraints are formalized into solvable optimization problems. Through the constraint solver, Pareto optimal deployment schemes that meet multiple objectives are intelligently calculated. This not only achieves efficient and accurate matching of simulation resources, but also comprehensively considers multi-dimensional constraints such as cost, performance, and reliability at the global level, automatically generating the optimal or most reasonable resource scheduling and configuration scheme under given constraints, thereby significantly improving the overall efficiency and economy of range resource utilization. 3. By designing a complete technical closed loop from requirements analysis, intelligent matching, optimization solution to automated scheduling and deployment, and embedding quality assurance mechanisms such as semantic verification and feasibility simulation verification in key links, it is ensured that the final constructed digital power system test range is not a static, isolated set of resources, but a fully verified organic whole that can be directly started and operated. The closed-loop process ensures the high reliability and practical usability of the test range construction results, enabling it to stably and realistically support subsequent advanced application requirements such as network security attack and defense exercises, system testing, and fault reproduction.

[0105] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0106] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0107] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0108] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0109] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A method for constructing a digital test range for power systems based on knowledge graphs, characterized in that, Includes the following steps: Receive range construction instruction data, which includes topology and component type information of the target power system described in a declarative manner; The target range construction instruction data is parsed and transformed based on the preset target range construction knowledge graph to generate a target range construction list. The preset target range construction knowledge graph is a domain model used to map power component entities to simulation resource entities. Based on the test range construction list, resources in the simulation environment are scheduled and configured to construct the digital test range of the power system.

2. The method for constructing a digital test range for power systems based on knowledge graphs according to claim 1, characterized in that, The received range construction instruction data includes topology and component type information of the target power system described in a declarative manner, including: Obtain the range construction request data used to define the target power system functions and scale to be simulated; The target range construction request data is parsed and elements are extracted to obtain the power component entities contained in the target power system and the electrical topology connection relationships between the power component entities; The power component entities and the electrical topology connections are used to generate standardized, identifiable power system model data. According to the declarative description preset specification, the power system model data is converted into structured test range construction instruction data. The declarative description preset specification defines the description syntax and data format of the power system topology and component types.

3. The method for constructing a digital test range for power systems based on knowledge graphs according to claim 2, characterized in that, The step of parsing and extracting elements from the target range construction request data to obtain the power component entities included in the target power system and the electrical topology connections between the power component entities includes: The range construction request data is input into the power equipment attribute and topology rule base, which defines the standard attributes, naming conventions, and allowed topology connection rules for power component types. Based on the power equipment attributes and topology rule base, entity recognition and relationship extraction are performed on the target range construction request data. The types and quantities of power components involved in the request data are identified, and the preset connection relationship descriptions between the power component types are extracted. Based on the power equipment attributes and the topology connection rules in the topology rule base, the extracted connection relationship descriptions are logically verified to obtain the electrical topology connection relationships that conform to the electrical connection rules. By associating the types and quantities of the power components with the electrical topology connections, the power component entities included in the target power system and the electrical topology connections between the power component entities are obtained.

4. The method for constructing a digital test range for power systems based on knowledge graphs according to claim 3, characterized in that, The process of converting the power system model data into structured range construction instruction data according to the predefined declarative description specification includes: The target range instruction data pattern is obtained from the predefined declarative description specification. The target range instruction data pattern defines the data fields, data types, and hierarchical relationships required for the structured description of the target power system. Extract the type identifier and attribute parameters from the power component entity, and obtain the electrical topology connection relationship; Based on the target range command data pattern, the type identifier, the attribute parameters, and the electrical topology connection relationship are filled into the corresponding data fields to generate initial command data; Based on the syntax rules in the predefined declarative description specification, the field relationships and value ranges in the initial instruction data are validated for compliance. The verified initial instruction data is serialized and encapsulated according to the standard data exchange format defined by the predefined declarative description specification to generate the structured target range construction instruction data.

5. The method for constructing a digital test range for power systems based on knowledge graphs according to claim 4, characterized in that, The compliance verification of field relationships and value ranges in the initial instruction data based on the syntax rules in the predefined declarative description specification includes: The set of semantic rules for the power domain is obtained from the predefined declarative description specification. The set of semantic rules for the power domain defines the logical constraints on the component types and topological connections within the target power system. Based on the semantic rule set of the power field, the field relationships in the initial instruction data are checked for topological logic to verify whether the electrical topology connection relationship conforms to the connection rules and hierarchical relationships defined in the power equipment attributes and topology rule base. The value range in the initial instruction data is checked for attribute compliance based on the set of semantic rules for the power field, and it is verified whether the value of the attribute parameter matches the range of electrical parameters and physical constraints defined by the type identifier. Based on the results of the topology logic verification and the attribute compliance verification, the field relationships or attribute parameters that fail the verification are marked or preset automatic correction logic is executed.

6. The method for constructing a digital test range for power systems based on knowledge graphs according to claim 1, characterized in that, The process of parsing and transforming the target range construction instruction data based on a pre-defined target range knowledge graph to generate a target range construction list includes: Semantic parsing is performed on the target range construction instruction data to identify the power component entities and their structural relationships contained in the target power system; A mapping layer for a knowledge graph is constructed based on the preset target range to match a corresponding simulation resource entity for each identified power component entity. The mapping layer stores the mapping relationship between power component entities and simulation resource entities. Based on the resource compatibility rules and deployment constraints defined in the resource layer and constraint layer of the knowledge graph constructed in the preset target range, the matching simulation resource entities and their dependencies are constrained and solved to generate a set of simulation resource instances and their configuration relationships that satisfy all the resource compatibility rules and deployment constraints. The set of simulation resource instances and their configuration relationships are arranged according to a preset list format to generate the target range construction list used to directly drive resource scheduling and configuration.

7. The method for constructing a digital test range for power systems based on knowledge graphs according to claim 6, characterized in that, The process of solving for constraints on the matched simulation resource entities and their dependencies to generate a set of simulation resource instances and their configuration relationships that satisfy all the resource compatibility rules and deployment constraints includes: Based on the resource compatibility rules and deployment constraints, a set of constraints is constructed to describe the deployment relationships between the matched simulated resource entities. The constraint set and the optional instantiation options of the matched simulation resource entities are input into a preset constraint solver for calculation. The constraint solver outputs the selected instantiation options corresponding to each simulation resource entity and the deployment configuration relationship between entities. Based on the selected instantiation options and deployment configuration relationships output by the constraint solver, the set of simulation resource instances and their configuration relationships that satisfy all the resource compatibility rules and deployment constraints are generated.

8. The method for constructing a digital test range for power systems based on knowledge graphs according to claim 7, characterized in that, The set of constraints, constructed based on the resource compatibility rules and deployment constraints, to describe the deployment relationships between the matched simulation resource entities includes: The resource compatibility rules and deployment constraints are parsed to identify hard constraints and soft constraints. An adjustable weight factor is assigned to the soft constraints. The hard constraints are deployment conditions that must be met, and the soft constraints are deployment conditions that are expected to be met through optimization. Based on the preset target range, a resource layer of knowledge graph is constructed, and the instantiation cost vector of each simulation resource entity is determined. The instantiation cost vector includes at least quantitative indicators of computing resource overhead, network communication overhead, and power simulation fidelity overhead. The soft constraints are transformed into penalty terms according to their weights, and the instantiation cost vector is determined as the primary objective term. The penalty terms and the primary objective term are weighted and summed to form a comprehensive optimization objective function. The set of constraints includes the hard constraints that must be satisfied and the comprehensive optimization objective function used to drive the process.

9. The method for constructing a digital test range for power systems based on knowledge graphs according to claim 7, characterized in that, The step of inputting the optional instantiation options of the constraint set and the matched simulation resource entity into a preset constraint solver for calculation includes: The matched simulation resource entities, their optional instantiation options, and the set of constraints are organized into standard input data for a multi-objective optimization problem that the constraint solver can process. The constraint solver is run to calculate the standard input data to obtain the Pareto optimal solution set; Based on the business preference strategy defined in the constraint layer of the knowledge graph constructed according to the preset target range, a final solution is selected from the Pareto optimal solution set. The final solution is subjected to deployment feasibility simulation verification. If the verification fails, the verification result is fed back as a new constraint and a re-solution is triggered until a feasible solution that passes the verification is obtained.

10. The method for constructing a digital test range for power systems based on knowledge graphs according to any one of claims 1-9, characterized in that, The step of constructing the digital power system test range by scheduling and configuring resources in the simulation environment according to the test range construction list includes: The target range construction list is parsed to generate a specific deployment instruction sequence for the cloud resource manager, power simulation equipment controller, and network configuration interface; The deployment instruction sequence is issued to the cloud platform manager, simulator controller, and network device configuration interface, and the creation and configuration status of all simulation resource instances are monitored. According to the configuration relationships in the test range construction list, establish communication links and logical associations between all simulation resource instances to complete the construction process of the power system digital test range.

Images