Virtual relay protection SCD modeling and automatic generation method

Abstract

The invention discloses a virtual relay protection SCD modeling and automatic generation method, and relates to the field of power system automation. Comprising two parts of modeling and automatic generation: during modeling, a model is built by adopting Matlab / Simulink, input and output modules of a station level and a process level are divided according to communication levels, variables such as device parameters, protection events, GOOSE data sets and the like are distinguished by using type identifiers, and attribute parameters are preset; during automatic generation, the model file is analyzed, a communication node, a subnet containing a station control layer and a process layer, an intelligent electronic equipment node, a merging unit, an intelligent terminal, protection equipment and a data type template node are configured, and an SCD file and a corresponding CID file are automatically generated. According to the method, the problems of low SCD file generation efficiency and poor information matching in the prior art are solved, the modeling efficiency is improved, clear signal interaction is ensured, an actual system is adapted, and a virtual relay protection development link is simplified.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of power system automation, in particular to a virtual relay protection SCD modeling and automatic generation method. BACKGROUND

[0002] Under the promotion of energy transformation, new power systems have higher requirements for the protection principle and data interaction of relay protection devices, and virtual relay protection technology has become an important solution. The SCD file of virtual relay protection is the core of connecting protection logic, data interface and real-time operation, but the existing technology has significant limitations:

[0003] The SCD file is a complex tree structure (including Header, Communication, IED root nodes) in XML format, containing hundreds of thousands of lines of text, and manual editing is almost impossible. Currently, SCD file generation and virtual protection modeling mainly rely on two ways: one is to model first and then generate SCD through special software, which requires editing personnel to be familiar with virtual protection logic, software operation and SCD structure, which is difficult and prone to model and SCD information mismatch; the second is to model based on typical SCD files, which requires modeling personnel to be proficient in parsing SCD files and complete information mapping, which is time-consuming and inefficient.

[0004] In addition, the variable types of virtual protection models are diverse (such as device parameters, protection events, GOOSE signals, etc.), and the existing methods lack unified variable classification and attribute definition rules, resulting in chaotic description of process layer and station control layer signal interaction in SCD files, which restricts the real-time operation and application expansion of virtual protection. SUMMARY

[0005] The purpose of the present application is to avoid the shortcomings of the prior art and provide a virtual relay protection SCD modeling and automatic generation method.

[0006] The above-mentioned purpose of the present application is realized by the following technical means:

[0007] A virtual relay protection SCD modeling method, comprising the following steps:

[0008] A virtual relay protection model is built using Matlab / Simulink graphical tools;

[0009] The input and output variables in the model are configured in input and output modules divided according to communication levels, and the input and output modules include station control layer input modules, station control layer output modules, process layer input modules and process layer output modules;

[0010] The variables in each input and output module are distinguished by type identification information, wherein:

[0011] The variables in the station control layer input module include types for representing device parameters, protection setting values and protection soft panels;

[0012] The variables in the station control layer output module include types for representing protection events, alarm signals, protection telemetering, protection telecontrol, protection function states and protection function lockouts;

[0013] The variables in the process layer input module include types for representing GOOSE receiving data sets;

[0014] The variables in the process layer output module include types for representing GOOSE sending data sets;

[0015] Corresponding attribute parameters are preset for different types of variables, and the attribute parameters at least include a logic node class, description information, a data type, path information and a data attribute.

[0016] Further, the input and output variables in the model are collectively configured in four Subsystem blocks, namely, FromHMI for station control layer input, ToHMI for station control layer output, FromPKT for process layer input and ToPKT for process layer output;

[0017] The variables in the four Subsystem blocks are distinguished by type suffix keywords, wherein the variable types in the FromHMI block include RP for representing device parameters, RS for representing protection setting values and RE for representing protection soft panels;

[0018] The variable types in the ToHMI block include RT for representing protection events, RW for representing alarm signals, RA for representing protection telemetering, RD for representing protection telecontrol, RS for representing protection function states and RB for representing protection function lockouts;

[0019] The variable types in the FromPKT block include GI for representing GOOSE receiving data sets;

[0020] The variable types in the ToPKT block include GO for representing GOOSE sending data sets;

[0021] Corresponding attribute parameters are preset for different variable types, and the attribute parameters include lnClass for representing a logic node class, desc for representing a description, type for representing a data type, path for representing a path and DA for representing a data attribute.

[0022] Preferably, the corresponding relationship between different variable types and variable names is as follows:

[0023] Variable name

[0024] Corresponding to RP type with a "-RP" ending;

[0025] the corresponding RS type ending in "-RS";

[0026] the corresponding RE type ending in "-RE";

[0027] the corresponding RT type ending in "-RT";

[0028] the corresponding RW type ending in "-RW";

[0029] the corresponding RA type ending in "-RA";

[0030] the corresponding RD type ending in "-RD";

[0031] the corresponding GI type ending in "-GI";

[0032] the corresponding GO type ending in "-GO".

[0033] Preferably,

[0034] the attribute parameters of the RP type variable are: lnClass = TVTC, desc = device parameter, type = CN_ASG_SP, path = PROT / TVTCSPRtg + serial number, DA = setMag.f;

[0035] the attribute parameters of the RS type variable are: lnClass = PDIF, desc = protection fixed value, type = CN_ASG_SG, path = PROT / PDIFSGStrSG + serial number, DA = setMag.f;

[0036] the attribute parameters of the RE type variable are: lnClass = PDIF, desc = protection soft pad, type = CN_SPC, path = PROT / PDIF$ST$FuncEna + serial number, DA = stVal;

[0037] the attribute parameters of the RT type variable are: lnClass = PDIF, desc = protection event, type = CN_ACT_3P, path = PROT / PDIFSTOp + serial number, DA = general;

[0038] the attribute parameters of the RW type variable are: lnClass = GGIO, desc = alarm signal, type = CN_SPS, path = PROT / GGIOSTAlm + serial number, DA = stVal;

[0039] The attribute parameters of the RA type variable are: lnClass=MMXU, Desc=protect telemetry, Type=CN_MV, Path=PROT / MMXU$MX$Val+serial number, DA=mag.f.

[0040] The attribute parameters of the RD type variable are: lnClass=GGIO, desc=protect interlocking, type=CN_SPS, path=PROT / GGIO$ST$Ind+serial number, DA=stVal.

[0041] The attribute parameters of the GI type variable are: lnClass=GPKT, desc=GOOSE received data set, type=CN_SPS, path=PROT / GPKTSTGsIn+serial number, DA=stVal.

[0042] The attribute parameters of the GO type variable are: lnClass=GPKT, desc=GOOSE sent data set, type=CN_SPS, path=PROT / GPKTSTGsOut+serial number, DA=stVal.

[0043] The application further discloses a virtual relay protection SCD automatic generation method, and the virtual relay protection SCD modeling method based on the modeling method comprises the following steps:

[0044] The variable type, attribute parameter and device information in the model are extracted by analyzing the file generated by compiling the virtual relay protection model.

[0045] The root node of the SCD file is generated, wherein the Header node and the Substation node adopt a general simplified description.

[0046] The communication node is configured: the network address of the relay protection intelligent electronic device in the station control layer subnetwork is automatically generated according to a preset rule, and the remaining communication parameters adopt typical values; the process layer subnetwork comprises a merging unit, an intelligent terminal and GOOSE publishing information of the relay protection.

[0047] The intelligent electronic device node is configured: a preset number of merging units and intelligent terminals are automatically generated, and all adopt typical data sets; the protection device is generated according to the number of virtual protections in the model, and the data set and the logic node are generated according to the variable type and the attribute parameter.

[0048] The data type template node is configured: the typical data type structure is loaded in advance; the logic node type is generated according to the variable type in the model, and comprises physical device information, disturbance record, data set node, telemetry, virtual protection, mutual inductor parameter, state quantity and the like.

[0049] Integrate the node information above, generate SCD files named after the model name, and generate instance configuration files corresponding to each virtual protection, with the instance configuration files named after the virtual protection model name.

[0050] Further, in the step,

[0051] Configure the communication node Communication:

[0052] Include the station control layer subnet SubNetwork_Stationbus and the process layer subnet SubNetwork_Processbus.

[0053] In SubNetwork_Stationbus, the IP addresses of the relay protection IEDs are automatically generated in ascending order starting from 192.168.6.101, and the remaining communication parameters use typical values.

[0054] In SubNetwork_Processbus, include the merging unit, intelligent terminal, and GOOSE publishing information of the relay protection.

[0055] Configure the intelligent electronic device node IED:

[0056] Automatically generate 30 merging unit IEDs and 64 intelligent terminal IEDs, all using typical data sets; generate protection device IEDs according to the number of virtual protections in the model, and generate data sets and logic nodes according to variable types and attribute parameters.

[0057] Configure the data type template node DataTypeTemplates:

[0058] Load pre-stored typical DOType, DAType, and EnumType structure files.

[0059] Generate LNodeType according to the variable types in the model, including LPHD, RDRE, LLN0, MMXU, PDIF, TVTC, and GGIO types.

[0060] Preferably, the typical data set of the merging unit IED includes at least one of the DelayTRtg delay channel, the Ia1 / Ia2 protection three-phase current channel, and the Ua1 / Ua2 protection three-phase voltage channel.

[0061] The typical data set of the intelligent terminal IED includes at least one of the BrkA_stVal circuit breaker position channel, the Sw1_stVal switch position channel, and the BlkCH1_stVal reclosing lockout channel.

[0062] Preferably, the data set of the protection device IED includes dsParameter representing device parameters, dsSetting representing protection setting values, dsTripInfo representing protection event information, and dsWarning representing alarm signals; and the logical nodes include LLN0 representing data set nodes, LPHD representing physical device information, and PDIF representing virtual protection.

[0063] Preferably, the member information of the LNodeType type is determined according to the variable type in the model, and the PDIF type includes an inter-phase impedance setting value DO member and a grounding impedance setting value DO member, and the TVTC type includes a PT / CT rated value DO member.

[0064] Preferably, the CID file includes IED node information corresponding to the virtual protection, access point information in the Communication node, and related data type information in the DataTypeTemplates.

[0065] The technical scheme has the following beneficial effects:

[0066] 1. The modeling method described in the embodiment accurately divides input and output modules according to communication levels, clearly distinguishes variable categories by type identification, and presets standardized attribute parameters for different types of variables. Starting from the model itself, the variable structure of the virtual protection is clear and orderly, and the classification rules are uniform, which completely solves the problem of variable disorder and fuzzy attribute definition in traditional modeling; provides a structured and standardized data cornerstone for the subsequent automatic generation of SCD files, ensures that model information can be directly parsed and converted, and avoids information fault risks from the source; simplifies the development process of virtual relay protection, and through standardized configuration, the modeling result can be directly connected to the existing communication protocol and equipment of the substation, which significantly improves the adaptability of virtual protection to the actual system; fundamentally improves the pain points of low SCD file generation efficiency and poor model and file information matching degree in the prior art, and provides key support for efficient landing of virtual relay protection.

[0067] 2. By centrally configuring variables in four Subsystem blocks and distinguishing variable types by type suffix keywords, the standardization degree of modeling is further refined. This specific configuration makes the module boundary of the virtual protection model clearer, and the correspondence between the variables and the communication levels more intuitive; the preset attribute parameters provide a unified "language" for model parsing, reducing the risk of information ambiguity caused by fuzzy module division. At the same time, based on the graphical tool characteristics of Matlab / Simulink, technicians can directly reuse the module structure to quickly build similar models, significantly improving the operability and consistency of modeling.

[0068] 3). Through the rule of "suffix keyword corresponding to variable type", the "automatic identification" of variable type is realized. Compared with the traditional modeling method which relies on manual type labeling, this rule enables the parsing tool to directly determine the category and purpose of the variable through the variable name, completely eliminating the subjective error of type judgment; at the same time, the simplicity of the keyword reduces the complexity of variable naming, and technicians can complete variable definition without remembering complex rules, which not only improves the modeling efficiency, but also provides accurate basis for the automatic classification of data sets in subsequent SCD files, reducing type matching errors from the source.

[0069] 4). Fine attribute parameters are preset for different variable types to realize "precise binding" of variables and SCD file logical nodes. Compared with the framework definition of attribute parameters in embodiment 2, this specific parameter setting ensures that each variable has a unique logical node, data type and path in SCD, avoiding information gaps caused by parameter omission or format errors during manual configuration; at the same time, the parameter values are highly compatible with industry standards, ensuring that the virtual protection model can directly interface with the communication protocol of the actual substation, improving the interaction accuracy of the model and the physical system.

[0070] 5). Based on the above modeling method, the whole process of SCD file generation is realized, and the core value is to break the "modeling-parsing-file generation" closed loop. Compared with the traditional "modeling and manual SCD coding" or "reverse modeling based on typical SCD", this method automatically extracts variable types, attribute parameters and other information through parsing model files, without manual intervention to complete the configuration of root nodes, communication nodes and IED nodes; the generated SCD file naturally matches the model information, completely solving the pain point of "model and file information disconnection" in the prior art. At the same time, the instance configuration file (CID) is one-to-one corresponding to the virtual protection, which not only guarantees the integrity of global information (SCD), but also meets the flexibility of single device debugging (CID), providing double support for system-level application and local debugging of virtual protection.

[0071] 6). By specifying the subnet division of communication nodes, the number of IED devices and the loading rules of data type templates, the "execution standard" of automatic generation is further refined. This specific configuration makes the generation process more operable: the rule of incrementing IP address from 192.168.6.101 ensures the uniqueness of the station control layer communication parameters; the reuse of typical data sets reduces the workload of repeated definition; the fixed type of LNodeType provides a unified data specification for information interaction of different virtual protections, significantly reducing the parameter adaptation cost during multi-device joint debugging.

[0072] 7). By limiting the typical data set of merging unit and intelligent terminal to contain key channels, the "lightweight optimization" of the data set is realized. Compared with the traditional data set containing redundant channels, this configuration greatly reduces the size of the SCD file under the premise of ensuring the core function; at the same time, the key channel is completely matched with the core signal of the actual device, ensuring that the process layer data received by the virtual protection is consistent with the physical system, avoiding the data transmission delay or analysis burden caused by redundant information, and improving the real-time performance.

[0073] 8). By defining the core data set and logic node of the protection device IED, the "completeness" of the virtual protection function description is ensured. The one-to-one correspondence between the data set and the variable type enables the SCD file to record the input and output information of the virtual protection completely; the logic node covers the full-dimensional description from the device basic information to the protection logic, meeting the needs of station control layer for protection state monitoring and parameter configuration. Compared with the fragmented information record, this structure makes the SCD file become the "digital mirror image" of the virtual protection, facilitating information interaction with other secondary devices, and improving the convenience of system integration.

[0074] 9). By dynamically binding the member information of LNodeType with the model variable type, the "dynamic adaptation" of data type description is realized. Compared with the fixed LNodeType definition, this method enables the members of the logic node to automatically adjust with the model variable type, ensuring that the data type description in the SCD file is completely matched with the actual functional needs of the virtual protection; at the same time, the accuracy of the member information provides correct data specifications for the logic calculation of the virtual protection, avoiding simulation errors caused by data type mismatch, and significantly improving the accuracy of protection action simulation.

[0075] 10). By defining the core information contained in the CID file, the "modular management" of virtual protection configuration is realized. The CID file focuses on the local information of a single virtual protection, which is complementary to the global information of the SCD file: when a protection device needs to be debugged or replaced, technicians do not need to modify the huge SCD file, but only need to adjust the corresponding CID file, which greatly reduces the maintenance cost; at the same time, the access point information ensures that the virtual protection can be independently connected to the communication network, improving the flexibility and scalability of the system, and providing convenience for batch deployment and iterative upgrade of virtual protection. BRIEF DESCRIPTION OF DRAWINGS

[0076] Figure 1 is an RP data type schematic diagram;

[0077] Figure 2 is an RS data type schematic diagram;

[0078] Figure 3 is an RT data type schematic diagram;

[0079] Figure 4 is a Subsystem block schematic diagram;

[0080] Figure 5 is an input / output variable diagram in the Subsystem block;

[0081] Figure 6 is a variable diagram in the FromHMI;

[0082] Figure 7 is a variable diagram in the ToHMI;

[0083] Figure 8 is a variable diagram in the FromPKT;

[0084] Figure 9 is a variable diagram in the ToPKT;

[0085] Figure 10 is a virtual relay protection SCD modeling automatic generation flowchart;

[0086] Figure 11 is an SCD file root node schematic diagram;

[0087] Figure 12 is a busbar differential protection virtual protection element schematic diagram;

[0088] Figure 13 is a merging unit channel diagram;

[0089] Figure 14 is an intelligent terminal channel diagram;

[0090] Figure 15 is a merging unit data corresponding schematic diagram;

[0091] Figure 16 is a GOOSE data set corresponding diagram. DETAILED DESCRIPTION

[0092] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present application.

[0093] Term explanation:

[0094] Virtualized protection: The digitalization of protection device, whose function configuration, external characteristics, data interaction and other features are consistent with the actual protection device, to realize the virtualization of protection device. Virtualized protection can be connected with the actual protection device, and can be connected with primary equipment and simulation system to form a real-time closed-loop operating environment.

[0095] IED: Intelligent Electronic Device, which contains one or more processors, can receive data from external sources, or send data to the outside, or control device. Each protection device, merging unit, intelligent terminal and other secondary equipment is an IED.

[0096] CID: Configured IED Description, which is a complete description of IED, including communication parameters, data types, logical nodes, etc., stored in xml format.

[0097] SCD: Substation Configuration Description, which is used to describe the signal interaction information between protection device and primary equipment, and between other protection devices and secondary equipment, stored in xml format. SCD file contains the contents of all CID files in substation.

[0098] XML: Extensible Mark-up Language, a high-level language used to construct the structure of data ordinary text format of a particular application. This language creates data files for computer reading, and is easy for human to understand.

[0099] Embodiment 1. As Figures 1-9 A virtualized protection SCD modeling method is shown, comprising the following steps:

[0100] A virtualized protection model is built by using Matlab / Simulink graphical tool;

[0101] The input and output variables in the model are configured in input and output modules divided according to communication level, and the input and output modules include station control layer input module, station control layer output module, process layer input module and process layer output module;

[0102] The variables in each input and output module are distinguished by type identification information, wherein:

[0103] The variables in the station control layer input module include types for representing device parameters, protection setting values and protection software pads;

[0104] The variables in the station control layer output module include types for representing protection events, alarm signals, protection telemetry, protection remote signals, protection function states and protection function lockouts;

[0105] The variables in the process layer input module include types for representing GOOSE receiving data sets;

[0106] The variables in the process layer output module include types for representing GOOSE sending data sets;

[0107] Corresponding attribute parameters are preset for different types of variables, and the attribute parameters at least include a logic node class, description information, a data type, path information and data attributes.

[0108] Taking the establishment of a 110 kV bus differential virtual protection model as an example, a graphical modeling tool is selected: Matlab / Simulink is used as the graphical modeling tool.

[0109] Dividing input and output modules: the model input and output variables are centrally configured in four modules according to the communication level, and it should be noted that the module name can be defined by those skilled in the art, for example, the station control layer input module can be named “FromSCADA” or “station control layer data input”, as shown in Figure 4

[0110] The station control layer input module (named “FromHMI”): used for receiving parameters and control signals issued by the station control layer;

[0111] The station control layer output module (named “ToHMI”): used for uploading protection events and state signals to the station control layer;

[0112] The process layer input module (named “FromPKT”): used for receiving GOOSE / SV data of the process layer;

[0113] The process layer output module (named “ToPKT”): used for sending GOOSE control signals to the process layer.

[0114] Variable type identification and custom naming:

[0115] The variables in each module are distinguished by type identification, and it should be noted that the type identification form can be customized, such as a suffix, a prefix or a middle identifier, and the variable name can be named by those skilled in the art according to habit, for example, the device parameter variable can be named “PT_RatedValue” or “TVTR1_VRtg”:

[0116] The station control layer input module (FromHMI): as Figures 1-6 ​As shown, including device parameters (type identification "RP", such as "PT_RatedValue-RP", protection setpoint (type identification "RS", such as "PhaseImpedance-RS"), protection enable (type identification "RE", such as "ProtectionEnable-RE").

[0117] Station control layer output module (ToHMI): as shown, including protection events (type identification "RT", such as "TripEvent-RT"), alarm signals (type identification "RW", such as "OverVoltageAlarm-RW"), protection telemetry (type identification "RA", such as "LineCurrent-RA"), protection telesignalling (type identification "RD", such as "BreakerState-RD"), protection function status (type identification "RS", such as "ProtectionStatus-RS"), protection function lockout (type identification "RB", such as "Lockout-RB"). Figures 1-4 Figure 7 Station control layer output module (ToHMI): as shown, including protection events (type identification "RT", such as "TripEvent-RT"), alarm signals (type identification "RW", such as "OverVoltageAlarm-RW"), protection telemetry (type identification "RA", such as "LineCurrent-RA"), protection telesignalling (type identification "RD", such as "BreakerState-RD"), protection function status (type identification "RS", such as "ProtectionStatus-RS"), protection function lockout (type identification "RB", such as "Lockout-RB").

[0118] Process layer input module (FromPKT): as shown, including GOOSE received data sets (type identification "GI", such as "SwitchStatus_GI"); Figure 8

[0119] Process layer output module (ToPKT): as shown, including GOOSE sent data sets (type identification "GO", such as "TripCommand_GO"). Figure 9

[0120] Pre-set variable attribute parameters:

[0121] As shown in the table, the above variable pre-set attribute parameters follow industry specifications, and the specific values can be adjusted, including: Figures 4-7 Logical node class (lnClass): such as "TVTC" for device parameter variables and "PDIF" for protection event variables;

[0122] Description (desc): such as "PT primary rated value" and "Segment 1 protection trip";

[0123] Data type (type): such as "CN_ASG_SP" for device parameters and "CN_ACT_3P" for protection events;

[0124] Path (path): such as "PROT / TVTCSPRtg+serial number" and "PROT / PDIFSTOp+serial number";

[0125] Path (path): such as "PROT / TVTCSPRtg+serial number" and "PROT / PDIFSTOp+serial number";​​​

[0126] Data attribute (DA): "setMag.f" of device parameter, "general" of protection event.

[0127] The modeling method described in the embodiment realizes a triple progressive effect by accurately dividing the input and output modules according to the communication level, explicitly distinguishing the variable categories by type identification, and presetting standardized attribute parameters for different types of variables.

[0128] First, starting from the model itself, the variable structure of virtual protection is clear and the classification rules are unified, completely solving the problem of variable chaos and disorder and fuzzy attribute definition in traditional modeling;

[0129] Second, it provides a structured and standardized data cornerstone for the automatic generation of subsequent SCD files, ensuring that model information can be directly parsed and converted, and avoiding information fault risks from the source;

[0130] Third, it simplifies the development process of virtual relay protection, and through standardized configuration, the modeling results can be directly connected to the existing communication protocols and equipment of the substation, significantly improving the adaptability of virtual protection to the actual system;

[0131] Finally, it fundamentally improves the pain points of low efficiency of SCD file generation and poor matching degree of model and file information in the prior art, and provides key support for efficient landing of virtual relay protection.

[0132] Embodiment 2. This embodiment exemplarily shows how to set the module name and the variable name.

[0133] As shown in Figures 1-9 , the input and output variables in the model are concentrated in four Subsystem blocks, namely FromHMI for station control layer input, ToHMI for station control layer output, FromPKT for process layer input, and ToPKT for process layer output;

[0134] The variables in the four Subsystem blocks are distinguished by type suffix keywords, wherein:

[0135] The variables in the FromHMI block include RP representing device parameters, RS representing protection setting values, and RE representing protection soft panels;

[0136] The variables in the ToHMI block include RT representing protection events, RW representing alarm signals, RA representing protection telemetry, RD representing protection remote signaling, RS representing protection function status, and RB representing protection function locking;

[0137] The variables in the FromPKT block include GI representing a GOOSE received data set;

[0138] The variables in the ToPKT block include a GO type representing a GOOSE sending data set;

[0139] Corresponding attribute parameters are preset for different types of variables, and the attribute parameters include an lnClass representing a logical node class, a desc, a type of data type, a path, and a DA of data attribute.

[0140] A 110kV bus differential virtual protection model is built by using a Matlab / Simulink graphical tool as shown in Figure 5 As shown in Figure 4 The model input and output variables are concentrated in four Subsystem blocks: FromHMI (station control layer input), ToHMI (station control layer output), FromPKT (process layer input), and ToPKT (process layer output).

[0141] As shown in Figure 6 The FromHMI block contains RP type variables (such as “TVTR1_VRtg (001-PT primary rated value-RP)” and “TCTR1_ARtg (002-Branch 1 CT primary value-RP)”.

[0142] As shown in Figure 7 The ToHMI block contains RT type variables (such as “PTRC2_Tr (120-Section 1 protection trip-RT)”.

[0143] As shown in Figure 8 The FromPKT block contains GI type variables (GOOSE receiving), and the ToPKT block contains GO type variables (GOOSE sending).

[0144] The attribute parameters of the variables are preset as follows:

[0145] As shown in Figures 1-9 The attribute parameters of the above variables are preset, including:

[0146] Logical node class (lnClass): such as “TVTC” for device parameter variables and “PDIF” for protection event variables.

[0147] Description (desc): such as “PT primary rated value” and “Section 1 protection trip”.

[0148] Data type (type): such as “CN_ASG_SP” for device parameters and “CN_ACT_3P” for protection events.

[0149] Path: such as “PROT / TVTCSPRtg+serial number” and “PROT / PDIFSTOp+serial number”.

[0150] Data attribute (DA): "general" of the protection event, such as "setMag.f" of the device parameter.

[0151] The embodiment further refines the standardization degree of modeling by configuring variables in 4 Subsystem blocks (FromHMI / ToHMI / FromPKT / ToPKT) and distinguishing variable types by type suffix keywords (such as "-RP" and "-RT"). Compared with the overall framework of embodiment 1, this specific configuration makes the module boundary of the virtual protection model clearer, and the correspondence between variables and communication levels more intuitive. The preset attribute parameters (such as lnClass and path) provide a unified "language" for model analysis, reducing the risk of information ambiguity caused by fuzzy module division. At the same time, based on the graphical tool characteristics of Matlab / Simulink, technicians can directly reuse the module structure to quickly build similar models, significantly improving the operability and consistency of modeling.

[0152] Embodiment 3. The method of embodiment 1 or 2, wherein the virtual protection model comprises a plurality of Subsystem blocks, and each Subsystem block comprises a plurality of variables. Figures 1-3 The correspondence between different variable types and variable names is shown as follows:

[0153] Variable name

[0154] Corresponding to the RP type with the end "-RP";

[0155] Corresponding to the RS type with the end "-RS";

[0156] Corresponding to the RE type with the end "-RE";

[0157] Corresponding to the RT type with the end "-RT";

[0158] Corresponding to the RW type with the end "-RW";

[0159] Corresponding to the RA type with the end "-RA";

[0160] Corresponding to the RD type with the end "-RD";

[0161] Corresponding to the GI type with the end "-GI";

[0162] Corresponding to the GO type with the end "-GO".

[0163] In the 4 Subsystem blocks of the 110kV bus differential virtual protection model, the variable names form a corresponding relationship with the types through suffix keywords:

[0164] In the FromHMI block, "TVTR1_VRtg-RP" (001-PT primary rated value) ends with "-RP", corresponding to the device parameter type RP; "PhStr-RS" (phase-to-phase impedance constant) ends with "-RS", corresponding to the protection constant type RS; "Enable-RE" (protection soft pressure plate) ends with "-RE", corresponding to the protection soft pressure plate type RE.

[0165] In the ToHMI block, "PTRC2_Tr-RT" (120-section 1 protection trip) ends with "-RT", corresponding to the protection event type RT; "OverVoltage-RW" (overvoltage alarm) ends with "-RW", corresponding to the alarm signal type RW; "LineCurrent-RA" (line current telemetry) ends with "-RA", corresponding to the protection telemetry type RA; "BreakerState-RD" (circuit breaker status) ends with "-RD", corresponding to the protection telesignaling type RD.

[0166] In the FromPKT block, "SwitchStatus-GI" (switch position reception) ends with "-GI", which corresponds to the GOOSE receive data set type GI.

[0167] In the ToPKT block, "TripCommand-GO" (trip command sent) ends with "-GO", which corresponds to the GOOSE send data set type GO.

[0168] This embodiment achieves "automatic identification" of variable types through the rule of "one-to-one correspondence between suffix keywords and variable types" (such as "-RP" for device parameters and "-GO" for GOOSE transmission). Compared with the traditional modeling method that relies on manual type annotation, this rule enables parsing tools to directly determine the category and purpose of variables by their names, completely eliminating the subjective errors in type judgment. At the same time, the simplicity of keywords (only the suffix difference) reduces the complexity of variable naming. Technicians can complete variable definitions without memorizing complex rules, which not only improves modeling efficiency, but also provides an accurate basis for the automatic classification of data sets in subsequent SCD files, reducing type matching errors from the source.

[0169] Example 4. This example shows how to set attribute parameters for different variable types.

[0170] The attribute parameters of the RP type variable are: lnClass=TVTC, desc=device parameter, type=CN_ASG_SP, path=PROT / TVTCSPRtg+serial number, DA=setMag.f;

[0171] The attribute parameters of RS type variables are: lnClass=PDIF, desc=protection setting value, type=CN_ASG_SG, path=PROT / PDIFSGStrSG+serial number, DA=setMag.f;

[0172] The attribute parameters of the RE type variable are: lnClass = PDIF, desc = protection soft pressure plate, type = CN_SPC, path = PROT / PDIF$ST$FuncEna + sequence number, DA = stVal;

[0173] The attribute parameters of the RT type variable are: lnClass=PDIF, desc=protection event, type=CN_ACT_3P, path=PROT / PDIFSTOp+sequence number, DA=general;

[0174] The attribute parameters of the RW type variable are: lnClass=GGIO, desc=alarm signal, type=CN_SPS, path=PROT / GGIOSTAlm+sequence number, DA=stVal;

[0175] The attribute parameters of the RA type variable are: lnClass = MMXU, Desc = protection telemetry, Type = CN_MV, Path = PROT / MMXU$MX$Val + sequence number, DA = mag.f;

[0176] The attribute parameters of the RD type variable are: lnClass = GGIO, desc = protection remote signaling, type = CN_SPS, path = PROT / GGIO$ST$Ind + sequence number, DA = stVal;

[0177] The attribute parameters of the GI type variable are: lnClass=GPKT, desc=GOOSE received dataset, type=CN_SPS, path=PROT / GPKTSTGsIn+sequence number, DA=stVal;

[0178] The attribute parameters of the GO type variable are: lnClass=GPKT, desc=GOOSE sent data set, type=CN_SPS, path=PROT / GPKTSTGsOut+sequence number, DA=stVal.

[0179] RP type variable "TCTR1_ARtg-RP" (002-branch 1CT primary value): lnClass=TVTC, desc=device parameter, type=CN_ASG_SP, path=PROT / TVTCSPRtg+002, DA=setMag.f.

[0180] RS type variable "PhD1Tmms-RS" (phase-to-ground time measurement): lnClass = PDIF, desc = protection measurement, type = CN_ASG_SG, path = PROT / PDIFSGStrSG+001, DA = setMag.f.

[0181] RT type variable "PTRC3_Tr-RT" (121-segment 2 protection trip): lnClass = PDIF, desc = protection event, type = CN_ACT_3P, path = PROT / PDIFSTOp+121, DA = general.

[0182] RW type variable "PressureLow-RW" (pressure low alarm): lnClass = GGIO, desc = alarm signal, type = CN_SPS, path = PROT / GGIOSTAlm+001, DA = stVal.

[0183] GI type variable "Sw1State-GI" (switch 1 position received): lnClass = GPKT, desc = GOOSE received dataset, type = CN_SPS, path = PROT / GPKTSTGsIn+001, DA = stVal.

[0184] GO type variable "TripCmd-GO" (three-phase trip command): lnClass = GPKT, desc = GOOSE sent dataset, type = CN_SPS, path = PROT / GPKTSTGsOut+001, DA = stVal.

[0185] The embodiment pre-sets refined attribute parameters (such as lnClass = TVTC and path = PROT / TVTCSPRtg+serial number of the RP type) for different variable types (RP / RS / RT, etc.), and realizes "precise binding" of the variable and the logical node of the SCD file. Compared with the framework definition of the attribute parameters in embodiment 2, the specific parameter setting ensures that each variable has a unique logical node, data type and path in the SCD, avoids information gaps caused by parameter omission or format errors during manual configuration, and at the same time, the parameter value (such as DA = setMag.f) is highly compatible with the industry standard (such as IEC61850), which ensures that the virtual protection model can directly interface with the communication protocol of the actual substation, and improves the interaction accuracy of the model and the physical system.

[0186] Embodiment 5. The method of any one of embodiments 1-4, wherein the SCD file comprises a plurality of logical nodes, each logical node comprising a plurality of attributes, and each attribute comprising a data type and a value. Figures 1-16A virtual relay protection SCD automatic generation method is shown, based on the virtual relay protection SCD modeling method obtained by the modeling method, the following steps are performed:

[0187] The file generated by compiling the virtual relay protection model is parsed, and the variable type, attribute parameter and device information in the model are extracted;

[0188] The root node of the SCD file is generated, wherein the Header node and the Substation node adopt a general simplified description;

[0189] The communication node is configured: including the station control layer subnetwork and the process layer subnetwork, in the station control layer subnetwork, the network address of the relay protection intelligent electronic device is automatically generated according to a preset rule, and the remaining communication parameters adopt typical values; in the process layer subnetwork, the GOOSE publishing information of the merging unit, the intelligent terminal and the relay protection is included;

[0190] The intelligent electronic device node is configured: a preset number of merging units and intelligent terminals are automatically generated, and all adopt typical data sets; the protection device is generated according to the number of virtual protections in the model, and the data set and the logic node are generated according to the variable type and the attribute parameter;

[0191] The data type template node is configured: the pre-stored typical data type structure is loaded; the logic node type is generated according to the variable type in the model, including the physical device information, the disturbance record, the data set node, the telemetry, the virtual protection, the mutual inductor parameter, the state quantity and the like;

[0192] The above node information is integrated to generate an SCD file named by the model name, and an instance configuration file corresponding to each virtual protection is generated, and the instance configuration file is named by the virtual protection model name.

[0193] Automatic generation process:

[0194] Taking a 110kV bus differential virtual protection model as an example, as shown in Figure 10 , the SCD automatic generation is performed:

[0195] The model file is parsed: the Matlab / Simulink compiled file is parsed, and the variable type (such as RP, RT), the attribute parameter (such as lnClass=TVTC) and the device information (such as one set of bus differential protection) are extracted.

[0196] It should be noted that the format of the model compiled file is not limited to a specific type, and those skilled in the art can select a parsing method according to the tool characteristics, such as a C code file or a model description file.

[0197] The root node is generated: as Figure 11As shown, the Header node is simplified as "toolID=KETOP, version=VirPROT_1.0".

[0198] Configure the communication node:

[0199] The station control layer subnet: the network address of the relay protection intelligent electronic device (IED) is automatically generated according to a preset rule (such as incrementing from 192.168.1.101), and the subnet mask and other parameters adopt typical values.

[0200] It should be noted that the network address preset rule can be customized, for example, generated according to "interval number + starting IP", and is not limited to a fixed network segment.

[0201] The process layer subnet: contains the GOOSE publishing information of the merging unit and the intelligent terminal.

[0202] Configure the intelligent electronic device node:

[0203] As shown, a preset number (such as 17) of merging units and a preset number (such as 37) of intelligent terminals are automatically generated, and typical data sets are adopted. Figures 13-16

[0204] It should be noted that the preset number can be adjusted according to the scale of the substation, and is not limited to 17 or 37.

[0205] Generate a set of busbar differential protection equipment, generate data sets and logic nodes according to variable types.

[0206] Configure the data type template node:

[0207] Load the pre-stored typical DOType and DAType structure files.

[0208] Generate the logic node type.

[0209] Generate files: integrate node information, generate SCD files "110kV busbar differential protection.scd" and CID files "busbar differential protection 1.cid".

[0210] It should be noted that the file name can be customized, for example, named according to "voltage level + protection type + number", and the variable name can also be adjusted by the technical personnel according to the habit (such as "TVTR1_VRtg" to "PT_Rated_U"), and the type identifier form can be a prefix (such as "RP_TVTR1_VRtg") or a middle identifier (such as "TVTR1_RP_VRtg").

[0211] ​The embodiment based on the foregoing modeling method realizes the full-process automatic generation of the SCD file, and the core value lies in breaking the closed loop of "modeling-analysis-file generation". Compared with the traditional "modeling and then manually compiling SCD" or "reverse modeling based on typical SCD", the method automatically extracts variable types, attribute parameters and other information by analyzing the model file, and the configuration of the root node, the communication node and the IED node can be completed without manual intervention; the generated SCD file is naturally matched with the model information, and the pain point of "disconnection between model and file information" in the prior art is completely solved. At the same time, the instance configuration file (CID) is one-to-one corresponding to the virtual protection, which not only guarantees the integrity of the global information (SCD), but also meets the flexibility of the single device debugging (CID), and provides double support for the system-level application and local debugging of the virtual protection.

[0212] In embodiment 6, the nodes are configured in the following manner, for example. Figures 10-16 As shown in the steps,

[0213] Configure the communication node Communication:

[0214] The station control layer subnet SubNetwork_Stationbus and the process layer subnet SubNetwork_Processbus are included.

[0215] In the SubNetwork_Stationbus, the IP addresses of the relay protection IEDs are automatically generated in sequence starting from 192.168.6.101, and the remaining communication parameters adopt typical values.

[0216] In the SubNetwork_Processbus, the GOOSE publishing information of the merging unit, the intelligent terminal and the relay protection is included.

[0217] Configure the intelligent electronic device node IED:

[0218] Thirty merging unit IEDs and sixty-four intelligent terminal IEDs are automatically generated, and all of them adopt typical data sets; the protection device IED is generated according to the number of virtual protections in the model, and the data set and the logic node are generated according to the variable type and the attribute parameter.

[0219] Configure the data type template node DataTypeTemplates:

[0220] Load the pre-stored typical DOType, DAType and EnumType structure files.

[0221] Generate LNodeType according to the variable type in the model, including LPHD, RDRE, LLN0, MMXU, PDIF, TVTC and GGIO types.

[0222] Exemplarily, the node is configured in the following specific manner:

[0223] Communication node (Communication):

[0224] SubNetwork_Stationbus: IP address of the relay protection IED is incremented from 192.168.6.101, and the rest of the parameters are “IP-SUBNET=255.255.255.0”.

[0225] SubNetwork_Processbus: GOOSE publishing information of 30 merging units, 64 intelligent terminals and bus differential protection.

[0226] Intelligent electronic device node (IED):

[0227] The 30 merging unit IEDs and the 64 intelligent terminal IEDs all use typical data sets.

[0228] 1 bus differential protection IED “PBDF”: generates data sets such as dsParameter and dsTripInfo, and logic nodes such as LLN0 and PDIF.

[0229] Data type template node (DataTypeTemplates):

[0230] Load pre-stored DOType and DAType structure files.

[0231] Generate LNodeType.

[0232] This embodiment further refines the automatically generated “execution standard” by explicitly dividing the subnets of the communication node (station control layer SubNetwork_Stationbus / process layer SubNetwork_Processbus), the number of IED devices (30 merging units / 64 intelligent terminals) and the loading rules of the data type templates. Compared with the framework steps of embodiment 5, this specific configuration makes the generation process more operable: the rule of incrementing the IP address from 192.168.6.101 ensures the uniqueness of the communication parameters of the station control layer; the reuse of typical data sets reduces the workload of repeated definition; and the fixed type of LNodeType (such as LPHD and PDIF) provides a unified data specification for the information interaction of different virtual protections, significantly reducing the parameter adaptation cost during multi-device joint debugging.

[0233] Embodiment 7. As Figures 13-15 This embodiment shows that the typical data sets of the merging unit and the intelligent terminal contain key channels.

[0234] A typical data set of the merging unit IED includes at least one of the DelayTRtg delay channel, the Ia1 / Ia2 protection three-phase current channel, and the Ua1 / Ua2 protection three-phase voltage channel;

[0235] A typical data set of an intelligent terminal IED includes at least one of the following channels: BrkA_stVal circuit breaker position channel, Sw1_stVal switch position channel, and BlkCH1_stVal blocking reclosing channel.

[0236] For example, a typical data set of a merging unit and an intelligent terminal includes the following key channels:

[0237] Merging unit IED: Figure 13 As shown, the data set includes 17 channels, including "DelayTRtg" (delay channel), "Ia1 / Ia2" (protection three-phase current channel), "Ua1 / Ua2" (protection three-phase voltage channel), etc. For example, the merge unit No. 1 includes "Ia1" (phase A current 1 channel).

[0238] Intelligent terminal IED: Figure 14 As shown, the data set includes 37 channels such as "BrkA_stVal" (circuit breaker A phase position channel), "Sw1_stVal" (No. 1 knife switch position channel), "BlkCH1_stVal" (locking reclosing channel), etc. For example, the No. 1 intelligent terminal contains "BrkA_stVal".

[0239] This embodiment achieves "lightweight optimization" of the data set by limiting the typical data sets of the merging unit and the intelligent terminal to include key channels (such as the Ia1 current channel of the merging unit and the BrkA_stVal circuit breaker position channel of the intelligent terminal). Compared with traditional data sets that include redundant channels, this configuration significantly reduces the size of the SCD file while ensuring core functions (such as current sampling and switch status acquisition). At the same time, the key channels are fully matched with the core signals of the actual equipment (such as protection current and circuit breaker position), ensuring that the process-layer data received by the virtual protection is consistent with the physical system, avoiding data transmission delays or parsing burdens caused by redundant information, and improving real-time performance.

[0240] Example 8. Figures 10-16 Shows the data set and logical node configuration of the protection device IED.

[0241] The data set of the protection device IED includes dsParameter representing the device parameters, dsSetting of the protection setting, dsTripInfo of the protection event, and dsWarning of the alarm signal;

[0242] The logical node includes LLN0 representing the data set node, LPHD for physical device information, and PDIF for virtual protection.

[0243] The following is an example of data set and logical node configuration for protection device IED:

[0244] Data sets: dsParameter (device parameter, corresponding to RP type), dsSetting (protection setting, corresponding to RS type), dsTripInfo (protection event, corresponding to RT type), dsWarning (alarm signal, corresponding to RW type).

[0245] Logical nodes: LLN0 (data set node, manages all data sets), LPHD (physical device information, such as manufacturer "KETOP"), PDIF (virtual protection logic, including protection setting members).

[0246] This embodiment ensures the "integrity" of the virtual protection function description by defining the core data sets (dsParameter / dsTripInfo, etc.) and logical nodes (LLN0 / LPHD / PDIF) of the protection device IED. The one-to-one correspondence between the data set and the variable type (such as dsSetting corresponding to the protection constant RS type) enables the SCD file to fully record the input and output information of the virtual protection; the logical node covers the full-dimensional description from the basic device information (LPHD) to the protection logic (PDIF), meeting the station control layer's requirements for protection status monitoring and parameter configuration. Compared with fragmented information records, this structure makes the SCD file a "digital mirror" of the virtual protection, which facilitates information interaction with other secondary devices (such as monitoring systems) and improves the convenience of system integration.

[0247] Example 9. This example shows that the member information of LNodeType matches the model variable type.

[0248] The member information of the LNodeType type is determined by the variable type in the model. The PDIF type contains the phase-to-phase impedance constant value DO member and the ground impedance constant value DO member, and the TVTC type contains the PT / CT rated value DO member.

[0249] The member information of LNodeType matches the model variable type:

[0250] PDIF type (virtual protection): contains DO members such as "PhStr" (phase-to-phase impedance constant, corresponding to RS type variable) and "Gndstr" (ground impedance constant, corresponding to RS type).

[0251] TVTC type (instrument transformer parameter): contains DO members such as "TVTR1_VRtg" (PT primary rated value, corresponding to RP type), "TCTR1_ARtg" (CT primary rated value, corresponding to RP type), etc.

[0252] By dynamically binding the member information of LNodeType with the model variable type (e.g., the PDIF type contains the inter-phase impedance fixed value DO member, and the TVTC type contains the PT rated value DO member), the embodiment realizes the "dynamic adaptation" of the data type description. Compared with the fixed LNodeType definition, this method enables the members of the logical node to automatically adjust with the model variable type, ensuring that the description of the data type in the SCD file completely matches the actual functional requirements of the virtual protection (e.g., the bus differential protection needs to contain the differential current fixed value, and the line protection needs to contain the impedance fixed value); at the same time, the precision of the member information (e.g., the correspondence between the DO member and the variable parameter) provides correct data specifications for the logical calculation of the virtual protection, avoiding simulation errors caused by data type mismatch, and significantly improving the accuracy of protection action simulation.

[0253] Embodiment 10. The method of any one of embodiments 1-9, wherein the CID file comprises a Communication node and a DataTypeTemplates node. Figures 11-16 The embodiment shows a CID file.

[0254] The CID file contains IED node information corresponding to the virtual protection, access point information in the Communication node, and related data type information in the DataTypeTemplates.

[0255] For example, the CID file contains the following information:

[0256] IED node information: name "PBDF", manufacturer "KETOP", type "RTplus-VirPROT", description "110kV bus differential virtual protection".

[0257] Communication node access point information: station control layer access point "s1" (IP = 192.168.6.102), process layer GOOSE access point "G1".

[0258] DataTypeTemplates related information: local definition of LNodeType such as PDIF and TVTC.

[0259] The embodiment realizes the "modular management" of the virtual protection configuration by defining the core information (IED node / access point / data type) contained in the CID file. The CID file focuses on the local information of a single virtual protection, and is complementary to the global information of the SCD file: when a protection device needs to be debugged or replaced, the technician does not need to modify the huge SCD file, but only needs to adjust the corresponding CID file, thereby greatly reducing the maintenance cost; meanwhile, the access point information (such as the station control layer "s1" and the process layer "G1") ensures that the virtual protection can be independently accessed to the communication network, improves the flexibility and scalability of the system, and provides convenience for batch deployment and iterative upgrade of the virtual protection.

[0260] The above only discloses the preferred embodiments of the present application, of course, cannot limit the scope of the patent rights of the present application, therefore, the equivalent changes made in the patent application scope of the present application, still belongs to the scope covered by the present application.

Claims

1. A virtual relay protection SCD modeling method, characterized in that, The method comprises the following steps: A virtual relay protection model is built by using a graphical tool of Matlab / Simulink; Input and output variables in the model are centrally configured in input and output modules divided according to communication levels, the input and output modules including a station control layer input module, a station control layer output module, a process layer input module and a process layer output module; Variables in each input and output module are distinguished by type identification information, wherein: Variables in the station control layer input module include types for representing device parameters, protection setting values and protection soft panels; Variables in the station control layer output module include types for representing protection events, alarm signals, protection telemetering, protection telecontrol, protection function states and protection function locking; Variables in the process layer input module include types for representing GOOSE received data sets; Variables in the process layer output module include types for representing GOOSE sent data sets; Corresponding attribute parameters are preset for different types of variables, the attribute parameters including at least a logic node class, description information, a data type, path information and a data attribute.

2. The virtual relay protection SCD modeling method of claim 1, wherein Input and output variables in the model are centrally configured in four Subsystem blocks, the four Subsystem blocks being FromHMI for station control layer input, ToHMI for station control layer output, FromPKT for process layer input and ToPKT for process layer output; Variables in the four Subsystem blocks are distinguished by type suffix keywords, wherein: Variable types in the FromHMI block include RP for representing device parameters, RS for representing protection setting values and RE for representing protection soft panels; Variable types in the ToHMI block include RT for representing protection events, RW for representing alarm signals, RA for representing protection telemetering, RD for representing protection telecontrol, RS for representing protection function states and RB for representing protection function locking; Variable types in the FromPKT block include GI for representing GOOSE received data sets; Variable types in the ToPKT block include GO for representing GOOSE sent data sets; Corresponding attribute parameters are preset for different variable types, the attribute parameters including lnClass for representing a logic node class, desc for representing a description, type for representing a data type, path for representing a path and DA for representing a data attribute.

3. The virtual relay protection SCD modeling method of claim 2, wherein, Corresponding relationships between different variable types and variable names are as follows: Variable names Corresponding to the RP type with "-RP" at the end; Corresponding to the RS type with "-RS" at the end; Corresponding to the RE type with "-RE" at the end; Corresponding to the RT type with "-RT" at the end; Corresponding to the RW type with "-RW" at the end; Corresponding to the RA type with "-RA" at the end; Corresponding to the RD type with "-RD" at the end; Corresponding to the GI type with "-GI" at the end; Corresponding to the GO type with "-GO" at the end.

4. The virtual relay protection SCD modeling method of claim 2, wherein The attribute parameters of the RP type variable are: lnClass=TVTC, desc=Device parameter, type=CN_ASG_SP, path=PROT / TVTCSPRtg+serial number, DA=setMag.f; The attribute parameters of the RS type variable are: lnClass=PDIF, desc=Protection setting value, type=CN_ASG_SG, path=PROT / PDIFSGStrSG+serial number, DA=setMag.f; The attribute parameters of the RE type variable are: lnClass=PDIF, desc=Protection soft panel, type=CN_SPC, path=PROT / PDIF$ST$FuncEna+serial number, DA=stVal; The attribute parameters of the RT type variable are: lnClass=PDIF, desc=Protection event, type=CN_ACT_3P, path=PROT / PDIFSTOp+serial number, DA=general; The attribute parameters of the RW type variable are: lnClass=GGIO, desc=Alarm signal, type=CN_SPS, path=PROT / GGIOSTAlm+serial number, DA=stVal; The attribute parameters of the RA type variable are: lnClass=MMXU, Desc=Protection telemetry, Type=CN_MV, Path=PROT / MMXU$MX$Val+serial number, DA=mag.f; The attribute parameters of the RD type variable are: lnClass=GGIO, desc=Protection telesignaling, type=CN_SPS, path=PROT / GGIO$ST$Ind+serial number, DA=stVal; The attribute parameters of the GI type variable are: lnClass=GPKT, desc=GOOSE receiving dataset, type=CN_SPS, path=PROT / GPKTSTGsIn+serial number, DA=stVal; The attribute parameters of the GO type variable are: lnClass=GPKT, desc=GOOSE sending dataset, type=CN_SPS, path=PROT / GPKTSTGsOut+serial number, DA=stVal.

5. A method for virtual relay protection SCD automatic generation, characterized in that, The virtual relay protection SCD modeling method based on the modeling method of any one of claims 1-4, comprising the following steps: parsing the generated file of the virtual relay protection model to extract the variable type, attribute parameter and device information in the model; generating a root node of the SCD file, wherein the Header node and the Substation node adopt a general simplified description; configuring a communication node: including a station control layer subnetwork and a process layer subnetwork, in the station control layer subnetwork, the network address of the relay protection intelligent electronic device is automatically generated according to a preset rule, and the remaining communication parameters adopt typical values; in the process layer subnetwork, the GOOSE publishing information of the merging unit, the intelligent terminal and the relay protection is included; Configure IED nodes: automatically generate a preset number of merging units and intelligent terminals, all using typical data sets; generate protection devices according to the number of virtual protections in the model, and generate data sets and logic nodes according to variable types and attribute parameters; Configure data type template nodes: load pre-stored typical data type structures; generate logic node types according to variable types in the model, including physical device information, disturbance records, data set nodes, telemetry, virtual protections, mutual inductor parameters, state variables, etc. Integrate the above node information to generate an SCD file named after the model, and generate an instance configuration file corresponding to each virtual protection, which is named after the virtual protection model.

6. The virtual protective relay SCD automatic generation method of claim 5, wherein, In the steps, Configure communication nodes Communication: Include the station control layer subnetwork SubNetwork_Stationbus and the process layer subnetwork SubNetwork_Processbus; In SubNetwork_Stationbus, the IP addresses of the relay protection IEDs are automatically generated in ascending order starting from 192.168.6.101, and the remaining communication parameters use typical values; In SubNetwork_Processbus, it contains the GOOSE publishing information of merging units, intelligent terminals, and relay protection; Configure IED nodes IED: Automatically generate 30 merging unit IEDs and 64 intelligent terminal IEDs, all using typical data sets; generate protection device IEDs according to the number of virtual protections in the model, and generate data sets and logic nodes according to variable types and attribute parameters; Configure data type template nodes DataTypeTemplates: Load pre-stored typical DOType, DAType, and EnumType structure files; Generate LNodeType according to variable types in the model, including LPHD, RDRE, LLN0, MMXU, PDIF, TVTC, and GGIO types.

7. The virtual relay protection SCD automatic generation method of claim 6, wherein The typical data set of the merging unit IED includes at least one of the DelayTRtg delay channel, the Ia1 / Ia2 protection three-phase current channel, and the Ua1 / Ua2 protection three-phase voltage channel; The typical data set of the intelligent terminal IED includes at least one of the BrkA_stVal circuit breaker position channel, the Sw1_stVal switch position channel, and the BlkCH1_stVal blocking recloser channel.

8. The virtual relay protection SCD automatic generation method of claim 6, wherein The data set of the protection device IED includes dsParameter representing device parameters, dsSetting representing protection settings, dsTripInfo representing protection events, and dsWarning representing alarm signals; The logic nodes include LLN0 representing data set nodes, LPHD representing physical device information, and PDIF representing virtual protections.

9. The virtual protective relay SCD automatic generation method of claim 6, wherein, The member information of LNodeType type is determined according to the variable type in the model, wherein the PDIF type contains the DO member of the fixed value of the inter-phase impedance and the DO member of the fixed value of the grounding impedance, and the TVTC type contains the DO member of the rated value of the PT / CT.

10. The virtual protective relay SCD automatic generation method of claim 6, wherein, The CID file contains the IED node information corresponding to the virtual protection, the access point information in the Communication node, and the related data type information in the DataTypeTemplates.

Images