Virtual protection modeling method based on bus data interaction mode and 500kV transformer substation virtual relay protection modeling
Through the virtual protection modeling method based on bus data interaction method, data sets that participate in and do not participate in the virtual protection logic are distinguished and automatically modeled, which solves the problems of slow and inflexible virtual protection modeling in the existing technology, and achieves efficient and accurate virtual protection modeling.
Patent Information
- Application Number
- CN202411962812.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-30
- Publication Date
- 2025-04-18
AI Technical Summary
In the prior art, in virtual protection modeling, there are many members of the data set, which leads to the way of manually adding data set members to affect the modeling speed and compilation efficiency, and is not flexible and prone to errors.
The virtual protection modeling method based on bus data interaction is adopted to distinguish data sets that participate in and do not participate in the virtual protection logic construction, and the data sets are divided according to the customized different interface types to form a description file for virtual protection modeling, and automatically modeled based on the MATLAB/Simulink tool.
The number of variables involved in modeling of virtual protection is reduced, the modeling speed and model compilation efficiency is improved, the error of manually adding data set members is avoided, and the flexibility and efficiency of modeling is improved.
Smart Images

Figure CN119849177A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of relay protection of electric power systems, and in particular to a virtual protection modeling method based on bus data interaction and 500kV substation virtual relay protection modeling. Background Art
[0002] Digitalization is the direction of future social and power grid development. The digital transformation in the field of relay protection has become a research hotspot in recent years. The related virtual relay protection technology plays an important role in system-level simulation testing of relay protection devices, development and verification of protection principles, and skill training of relevant technical personnel in the relay protection field.
[0003] There are many data sets in actual protection devices. Taking 500kV line protection as an example, it contains at least 28 data sets and at least 833 data set members. When modeling virtual relay protection, the interface of these data set members must be modeled first. The interface of virtual protection is the way for virtual protection to interact with external devices for signals, mainly including background input and output interface, analog input and output interface, switch input and output interface, and recording channel. The existing technology mainly uses manual method to add the data set members required for virtual protection one by one, and then uses the "From-Goto" method to realize the transmission of variable signals between different modules within the model, or uses the "S-Function" encapsulation mode and "Data Store Memory" transmission method to realize automatic modeling of virtual protection interface. These two methods mainly have the following technical problems to be solved:
[0004] 1) When modeling virtual protection, there are a large number of data set members. Manually adding data set members to the model not only affects the modeling speed and model compilation efficiency, but is also prone to errors. Therefore, it is only suitable for situations where there are fewer model variables and no variable reuse.
[0005] 2) The "S-Function" encapsulation mode has strict requirements on the order of virtual relay protection interfaces and variable naming, which is very inflexible when adding and deleting variable signals. In addition, the interface variable modeling work needs to be repeated outside and inside the "S-Function", which is labor-intensive and the model is not intuitive. Summary of the invention
[0006] The purpose of the present invention is to avoid the shortcomings of the prior art and provide a virtual protection modeling method based on bus data interaction and 500kV substation virtual relay protection modeling.
[0007] The above-mentioned purpose of the present invention is achieved by the following technical means:
[0008] A virtual protection modeling method based on bus data interaction distinguishes between data sets participating in and not participating in the construction of virtual protection logic, divides data sets according to different user-defined interface types, forms a description file for virtual protection modeling, and automatically models data sets participating in the construction of virtual protection logic based on MATLAB / Simulimk modeling tools and with the help of bus data interaction.
[0009] Furthermore, the custom interface types include four interface types: Outside, FromBus, ToBus, and ToREC; wherein,
[0010] The Outside interface type does not participate in the construction of virtual protection logic, and its data set is a number of model description files that do not participate in the construction of virtual protection logic;
[0011] The FromBus interface type participates in the construction of virtual protection logic, and its data set is several model description files of the input interface of virtual protection;
[0012] The ToBus interface type is involved in the construction of virtual protection logic, and its data set is several model description files of the output interface of the virtual protection;
[0013] The ToREC interface type participates in the construction of virtual protection logic and is a recording of virtual protection. Its data set is a custom data set member, including some data set members in the FromBus and ToBus interface types and intermediate variables generated in the virtual protection modeling process.
[0014] Preferably, the data set involved in the construction of the virtual protection logic generates bus variable data with the help of an automatic modeling program, and references the required variables from the bus data for modeling;
[0015] The data sets that do not participate in the construction of virtual protection logic are uploaded to the background software through several model description files to perform operation and editing of the variables in the data sets.
[0016] Optional,
[0017] The Outside interface type description file includes at least one of the following:
[0018] LD0 / LLN0.dsAin data set for internal state monitoring, LD0 / LLN0.dsRelayDin data set for protection remote signaling, LD0 / LLN0.dsAlarm data set for fault signal, LD0 / LLN0.dsWarning data set for alarm signal, LD0 / LLN0.dsCommState data set for communication working condition, LD0 / LLN0.dsDeviceState data set for device operation state, LD0 / LLN0.dsSetGrpNum data set for set value area code, LD0 / LLN0.dsAin1 data set for internal state monitoring 1, LD0 / LLN0.dsAin2 data set for internal state monitoring 2, LD0 / LLN0.dsFileState data set for file management, LD0 / LLN0.dsComParameter data set for communication parameters;
[0019] The FromBus interface type description file includes at least one of the following:
[0020] PROT / LLN0.dsSetting data set for protection settings, PROT / LLN0.dsParameter data set for device parameters, PROT / LLN0.dsRelayEna data set for protection pressure plates, and PIGO / LLN0.dsGOIN data set for GOOSE input signals;
[0021] The ToBus interface type description file includes at least one of the following:
[0022] PROT / LLN0.dsWarning dataset for alarm signals, PROT / LLN0.dsRelayDin dataset for protection telesignaling, PROT / LLN0.dsRelayFunEn dataset for protection function activation and deactivation, PROT / LLN0.dsRelayState dataset for protection function status, PROT / LLN0.dsRelayBlk dataset for protection function blocking, PROT / LLN0.dsTripInfo dataset for protection events, PROT / LLN0.dsRelayAin dataset for protection telemetry, PROT / LLN0.dsTripParaInfo dataset for fault magnitude, PIGO / LLN0.dsGOOSE dataset for GOOSE output signals;
[0023] The ToREC interface type description file includes at least the RCD / LLN0.dsRelayRec data set for protection recording.
[0024] Preferably, the data set is the same worksheet in an Excel spreadsheet, and the worksheet includes serial number, description, variable name type, initial value, variable name, and interface type information to form a set of description files for virtual protection modeling, and the description file is named after the IED name of the virtual protection.
[0025] Furthermore, when there are multiple sets of virtual protection modeling of the same type, the interface type and protection logic are exactly the same, only the variable values are inconsistent. At this time, you only need to create a new worksheet in the Excel table that also includes the serial number, description, variable name type, initial value, variable name, and interface type information; for multiple sets of virtual protection of different types, you need to create a new Excel table as the description file of the virtual protection.
[0026] Furthermore, for the description files of the Outside interface type that do not participate in the construction of the virtual protection logic, multiple CSV files named after the IED are imported through the background software. The Outside interface type data can be modified in this interface and acted on the MMS Server in real time. After importing multiple CSV files, the mapMMS.txt file will be automatically saved in the Config directory of the virtual protection model. When the virtual protection model is opened later, there is no need to import it repeatedly. The MMS Server program can automatically load the mapMMS.txt file for modeling.
[0027] For the description files of FromBus and ToBus interface types involved in the construction of virtual protection logic, programming methods are used to generate BUS variable signals that can be directly referenced in MATLAB / Simulimk.
[0028] Furthermore, the automatic modeling process is as follows:
[0029] Extract the file name of the virtual protection modeling description file as the model name IED_TYPE corresponding to the virtual protection;
[0030] Read each line of information in the virtual protection modeling description file in sequence, and generate IED_TYPE_FromBus and IED_TYPE_ToBus bus data according to the interface classification of FromBus and ToBus; among them,
[0031] The elements in the IED_TYPE_FromBus bus data are all variables of the FromBus interface type, and the elements in the IED_TYPE_ToBus bus data are all variables of the ToBus interface type;
[0032] Each variable in the bus data is arranged according to the combination format of "type_variable name" in the description file;
[0033] Convert the data types of IED_TYPE_FromBus and IED_TYPE_ToBus to become IED_TYPE_FromSig and IED_TYPE_ToSig variable signals that can be directly referenced;
[0034] When modeling, with the help of the Data Store Memory transfer method of the Simulink simulation module, the IED_TYPE_FromSig data is used as the input of the virtual protection, and the IED_TYPE_ToSig data is used as the output of the virtual protection. When building the specific virtual protection logic, the required variables can be selected from the IED_TYPE_FromSig and IED_TYPE_ToSig data respectively.
[0035] When multiple virtual protections of the same or different types are modeled, the IED_TYPE_FromBus bus data of all virtual protections at the same voltage level can be used to generate the top-level FromBus_Sub variable signal, and the IED_TYPE_ToBus bus data of all virtual protections can be used to generate the top-level ToBus_Sub variable signal.
[0036] Furthermore,
[0037] Using GBK encoding, all FromBus and ToBus interface type data sets are generated into a mapBUS.txt file and uploaded to the background software. The data in the FromBus interface type description file can be directly edited in the background software and acted on the MMS Server in real time. The virtual protection ToBus interface type data information can be viewed in real time on the receiving monitoring interface.
[0038] Preferably,
[0039] When multiple virtual protections of the same or different types are modeled, the IED_TYPE_FromBus bus data of all virtual protections at the same voltage level can be used to generate the top-level FromBus_Sub variable signal, and the IED_TYPE_ToBus bus data of all virtual protections can be used to generate the top-level ToBus_Sub variable signal.
[0040] The present invention also discloses a 500kV substation virtual relay protection modeling. When performing virtual relay protection modeling of single bus protection, autotransformer protection, reactor protection, and short lead protection in the 500kV substation, the virtual protection modeling method based on bus data interaction is adopted.
[0041] The beneficial effects of adopting the above technical solution are:
[0042] The advantages of the present invention mainly include:
[0043] 1). The present invention models the data set involved in building the virtual protection logic, reduces the number of variables involved in the virtual protection modeling, and improves the modeling speed and model compilation efficiency.
[0044] 2). The present invention, based on MATLAB / Simulimk modeling tools, can model the data sets involved in the construction of virtual protection logic by directly referencing the required variables from the bus data with the help of bus data interaction. The direct reference of bus data in this modeling method eliminates the complex variable naming rules and avoids the problem of repeated modeling of interfaces in the "S-Function" encapsulation mode in the prior art. The modeling method is clear and flexible when adding and deleting variable signals, and is efficient and not prone to errors. It is particularly suitable for modeling virtual protection with many model variables.
[0045] 3) In the present invention, different model description files correspond to various data sets of different interface types, and the model data is clear. Different interface types correspond to different model description files, which are uniformly recorded in the same worksheet of Excel to form basic data for virtual modeling. The basic data is standardized and unified, providing a convenient operation basis for subsequent virtual modeling.
[0046] 4). In the present invention, all data sets are in the same worksheet in an Excel spreadsheet. The worksheet includes serial number, description, variable name type, initial value, variable name, and interface type information to form a set of description files for virtual protection modeling. The description file is named after the IED name of the virtual protection, and the relay protection is digitized and managed in a tabular form. The interface variable description file actually reflects the variable signals of different interface types.
[0047] 5). In the present invention, when there are multiple sets of virtual protection modeling of the same type, the interface type and protection logic are completely consistent, and only the variable values are inconsistent. At this time, it is only necessary to create a new worksheet in the Excel table that also includes the serial number, description, variable name type, initial value, variable name, and interface type information; multiple sets of different types of virtual protection need to create a new Excel table as the description file of the virtual protection. Multiple sets of interface variable description files of the same type of virtual protection can be quickly generated, and the modification of parameters, fixed values and other data in the interface only needs to be edited in the initial value column of each worksheet, without the need to reassign values in the model, which is conducive to improving the modeling efficiency of multiple sets of virtual protection.
[0048] 6). The present invention, for the data set involved in the construction of virtual protection logic, generates BUS variable signals that can be directly referenced in MATLAB / Simulimk by programming for modeling, thereby reducing the number of variables involved in the modeling of virtual protection and improving the modeling speed and model compilation efficiency; for the description files of the Outside interface type that do not participate in the construction of virtual protection logic, multiple CSV files named after the IED name are imported through the background software, and the data in the Outside interface type description files can be modified in this interface and acted on the MMS Server in real time. After importing multiple CSV files, the mapMMS.txt file will be automatically saved in the Config directory of the virtual protection model. There is no need to repeatedly import when the virtual protection model is opened later, and the MMS Server program can automatically load the mapMMS.txt file for modeling.
[0049] 7). The present invention directly references bus data during modeling, and there is no need to name variables in a special format, thereby reducing the workload of modeling.
[0050] 8). The present invention adopts GBK encoding, generates a mapBUS.txt file for all FromBus and ToBus interface type data sets, uploads it to the background software, directly edits the attribute data of the FromBus interface type description file in the background software and acts on the MMS Server in real time. The attribute data information of the virtual protection ToBus interface type description file can be viewed in real time on the receiving monitoring interface to provide a decision-making basis for the protection equipment that needs to be managed.
[0051] 9). The present invention, when modeling the virtual relay protection of a 500kV substation, effectively distinguishes between data sets that participate in and do not participate in the construction of the virtual protection logic, wherein the data sets that participate in the construction of the virtual protection logic form a description file for virtual protection modeling. Based on the MATLAB / Simulimk modeling tool, with the help of the bus data interaction method, modeling can be performed by directly referencing the required variables from the bus data, thereby reducing the number of variables involved in the modeling of the virtual protection, improving the modeling speed and model compilation efficiency, and directly referencing the bus data, eliminating the complex variable naming rules, and avoiding the problem of repeated modeling of interfaces in the "S-Function" encapsulation mode in the prior art. The modeling method is clear and concise, and is very flexible when adding and deleting variable signals, with high efficiency and low error-proneness, and is particularly suitable for virtual protection with many model variables in a 500kV substation. BRIEF DESCRIPTION OF THE DRAWINGS
[0052] Figure 1 is a schematic diagram of modeling virtual protection input signal;
[0053] Figure 2It is a schematic diagram of modeling for selecting virtual protection input signal;
[0054] Figure 3 is a schematic diagram of modeling of virtual protection output signal;
[0055] Figure 4 It is a schematic diagram of modeling for selecting virtual protection output signals;
[0056] Figure 5 This is a schematic diagram of modeling the primary value signal of the CT on the high voltage side of virtual protection;
[0057] Figure 6 This is a schematic diagram of modeling selection of primary value signal of CT on high voltage side of virtual protection;
[0058] Figure 7 It is a schematic diagram of modeling the action signal of virtual protection longitudinal differential protection;
[0059] Figure 8 It is a schematic diagram of modeling selection of virtual protection longitudinal differential protection action signal;
[0060] Fig. 9 It is a set of description files for virtual protection modeling, using the same Excel spreadsheet as a modeling description file diagram;
[0061] Fig.10 This is a schematic diagram of the data window of the Outside interface type that does not participate in virtual protection imported by the background software;
[0062] Fig.11 This is a diagram of the real-time editing window of the background software for Outside interface type data;
[0063] Fig.12 This is a schematic diagram of the real-time editing window of the FromBus interface type data by the background software;
[0064] Fig.13 It is a schematic diagram of the real-time monitoring interface of the background software for ToBus interface type data. DETAILED DESCRIPTION
[0065] The following is a clear and complete description of the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.
[0066] Glossary:
[0067] Virtual protection: Corresponding to the actual protection device, it is the virtualization of the actual protection device in the digital space. Virtual protection has the same functions and external characteristics as the actual protection device.
[0068] S-Function: An S-Function (system-function) is a computer language description of a Simulink module written in MATLAB, C, C++, or Fortran. Use the mex utility to compile C, C++, and Fortran S-Functions into MEX files. Like other MEX files, S-Functions are dynamically linked subroutines that can be automatically loaded and executed by the MATLAB execution engine.
[0069] Data Store Memory: Used to describe the definition and initialization of a named shared data store, i.e., a memory region, in the Simulink environment. This memory region is used by Data Store Read and Data Store Write blocks that specify the same data store name. In this way, Data Store Memory blocks can share global data between multiple diagrams or models.
[0070] Example 1. Figure 1-13 A virtual protection modeling method based on bus data interaction is presented, which distinguishes between data sets participating in and not participating in the construction of virtual protection logic, divides data sets according to different customized interface types, forms a description file for virtual protection modeling, and automatically models data sets participating in the construction of virtual protection logic based on MATLAB / Simulimk modeling tools and with the help of bus data interaction.
[0071] The present invention models the data set involved in building the virtual protection logic, reduces the number of variables involved in the modeling of the virtual protection, and improves the modeling speed and model compilation efficiency.
[0072] The present invention, based on MATLAB / Simulimk modeling tools, can model the data set involved in the construction of virtual protection logic by directly referencing the required variables from the bus data with the help of bus data interaction. The direct reference of the bus data in the modeling method eliminates the complex variable naming rules and avoids the problem of repeated modeling of interfaces in the "S-Function" encapsulation mode in the prior art. The modeling method is clear and flexible when adding and deleting variable signals, and is highly efficient and error-prone. It is particularly suitable for modeling virtual protection with a large number of model variables.
[0073] Embodiment 2. This embodiment shows different interface types, as shown in Table 1, a table of virtual protection data set interface types, and Fig. 9 As shown, the custom interface types include Outside, FromBus, ToBus, and ToREC.
[0074] The Outside interface type does not participate in the construction of virtual protection logic, and its data set is a number of model description files that do not participate in the construction of virtual protection logic;
[0075] The FromBus interface type participates in the construction of virtual protection logic, and its data set is several model description files of the input interface of virtual protection;
[0076] The ToBus interface type is involved in the construction of virtual protection logic, and its data set is several model description files of the output interface of the virtual protection;
[0077] The ToREC interface type participates in the construction of virtual protection logic and is a recording of virtual protection. Its data set is a custom data set member, including some data set members in the FromBus and ToBus interface types and intermediate variables generated in the virtual protection modeling process.
[0078] Table 1 Classification of virtual protection data set interface types
[0079]
[0080]
[0081] The present invention uses different model description files to correspond to various data sets of different interface types, and the model data is clear.
[0082] Embodiment 3. This embodiment shows how to model data sets that participate in and do not participate in the construction of virtual protection logic.
[0083] like Figure 1-8 As shown, the data set involved in the construction of virtual protection logic generates bus variable data with the help of automatic modeling program, and references the required variables from the bus data for modeling;
[0084] like Figure 10-11 As shown, the data set that does not participate in the construction of the virtual protection logic is uploaded to the background software through several model description files to perform operation editing of the variables in the data set.
[0085] The present invention effectively distinguishes between data sets that participate in and do not participate in the construction of virtual protection logic, reduces the number of variables involved in modeling of virtual protection, and is beneficial to improving modeling speed and model compilation efficiency.
[0086] Embodiment 4. This embodiment shows description files of different interface types, as shown in the virtual protection data set interface type classification table in Table 1 of Embodiment 2.
[0087] The Outside interface type description file includes at least one of the following:
[0088] LD0 / LLN0.dsAin data set for internal state monitoring, LD0 / LLN0.dsRelayDin data set for protection remote signaling, LD0 / LLN0.dsAlarm data set for fault signal, LD0 / LLN0.dsWarning data set for alarm signal, LD0 / LLN0.dsCommState data set for communication working condition, LD0 / LLN0.dsDeviceState data set for device operation state, LD0 / LLN0.dsSetGrpNum data set for set value area code, LD0 / LLN0.dsAin1 data set for internal state monitoring 1, LD0 / LLN0.dsAin2 data set for internal state monitoring 2, LD0 / LLN0.dsFileState data set for file management, LD0 / LLN0.dsComParameter data set for communication parameters;
[0089] The FromBus interface type description file includes at least one of the following:
[0090] PROT / LLN0.dsSetting data set for protection settings, PROT / LLN0.dsParameter data set for device parameters, PROT / LLN0.dsRelayEna data set for protection pressure plates, and PIGO / LLN0.dsGOIN data set for GOOSE input signals;
[0091] The ToBus interface type description file includes at least one of the following:
[0092] PROT / LLN0.dsWarning dataset for alarm signals, PROT / LLN0.dsRelayDin dataset for protection telesignaling, PROT / LLN0.dsRelayFunEn dataset for protection function activation and deactivation, PROT / LLN0.dsRelayState dataset for protection function status, PROT / LLN0.dsRelayBlk dataset for protection function blocking, PROT / LLN0.dsTripInfo dataset for protection events, PROT / LLN0.dsRelayAin dataset for protection telemetry, PROT / LLN0.dsTripParaInfo dataset for fault magnitude, PIGO / LLN0.dsGOOSE dataset for GOOSE output signals;
[0093] The ToREC interface type description file includes at least the RCD / LLN0.dsRelayRec data set for protection recording.
[0094] In the present invention, different interface types correspond to their own different model description files, which are uniformly recorded in the same worksheet of an Excel table to form basic data for virtual modeling. The basic data is standardized and unified, providing a convenient operating basis for subsequent virtual modeling.
[0095] Example 5. This example shows a data set expressed in an Excel worksheet, such as Fig. 9 As shown, the data set is the same worksheet in an Excel spreadsheet, and the worksheet includes serial number, description, variable name type, initial value, variable name, and interface type information to form a set of description files for virtual protection modeling, and the description file is named after the IED name of the virtual protection.
[0096] Please combine Fig. 9 , Table 1 and Table 2, in order to avoid confusion between members with the same data set name in LD0 of the Outside interface type description file and PROT of the FromBus and ToBus interface type description files, it is stipulated that the variable name types in the description file corresponding to the LD0 data set are uniformly suffixed with "0" to distinguish them.
[0097] For example, as shown in Table 2, the Outside interface type description file includes variable name types dsRelayDin0 and dsAlarm0, dsRelayDin0 is associated with the LD0 / LLN0.dsRelayDin data set for the corresponding interface for protection remote signaling, and dsAlarm0 is associated with the LD0 / LLN0.dsAlarm data set for the corresponding interface for fault signaling.
[0098] Table 2
[0099]
[0100] For example, as shown in Table 3, the variable name types include dsSetting and dsParameter in the FromBus interface type description file. dsSetting is associated with the PROT / LLN0.dsSetting data set for the corresponding interface for protection settings, and dsParameter is associated with the PROT / LLN0.dsParameter data set for the corresponding interface for device parameters.
[0101] Table 3
[0102]
[0103]
[0104] For example, as shown in Table 4, the variable name types include dsRelayAinCp and dsGOOSE in the ToBus interface type description file, dsRelayAinCp is associated with the PROT / LLN0.dsRelayAin data set of the corresponding interface for protection telemetry, and dsGOOSE is associated with the PIGO / LLN0.dsGOOSE data set of the corresponding interface for GOOSE output signal.
[0105] Table 4
[0106]
[0107]
[0108] The present invention digitizes and tabulates the management of relay protection, and uses interface variable description files to actually reflect variable signals of different interface types.
[0109] Example 6. Fig. 9 Shows the newly created worksheet in the Excel spreadsheet used for multiple sets of virtual protection modeling.
[0110] When there are multiple sets of virtual protection modeling of the same type, the interface type and protection logic are exactly the same, only the variable values are inconsistent. At this time, you only need to create a new worksheet in the Excel table that also includes the serial number, description, variable name type, initial value, variable name, and interface type information; for multiple sets of virtual protection of different types, you need to create a new Excel table as the description file of the virtual protection.
[0111] When there are multiple sets of virtual protection models of the same type, such as: longitudinal current differential protection needs to be modeled on both the local side and the opposite side, and the interface and protection logic of the local side and the opposite side are completely consistent, only the variable values are inconsistent, then you only need to create a new worksheet in the Excel table that also includes the serial number, description, variable name type, initial value, variable name, and interface type information. Different types of virtual protection require a new Excel table as the description file of the virtual protection.
[0112] Taking 500kV autotransformer protection as an example, the A set protection part in the description file is as follows Fig. 9 As shown in the figure, if there is a set B protection, you only need to create an additional "PT5001B" worksheet behind the "PT5001A" worksheet. This mode can quickly generate multiple sets of interface variable description files for the same type of virtual protection, and the modification of parameters, fixed values and other data in the interface only needs to be edited in the initial value column of each worksheet, without reassigning values in the model, which is conducive to improving the modeling efficiency of multiple sets of virtual protection.
[0113] Embodiment 7. This embodiment shows modeling of various interface type data sets that participate in or do not participate in the construction of virtual protection logic.
[0114] like Figure 9-11 As shown in the figure, for the description files of the Outside interface type that do not participate in the construction of the virtual protection logic, multiple CSV files named after the IED are imported through the background software. In this interface, the Outside interface type data can be edited and acted on the MMS Server in real time. After importing multiple CSV files, the mapMMS.txt file will be automatically saved in the Config directory of the virtual protection model. When the virtual protection model is opened later, there is no need to import it repeatedly. The MMS Server program can automatically load the mapMMS.txt file for modeling.
[0115] like Figure 1-9 As shown, for the description files of the FromBus and ToBus interface types involved in building the virtual protection logic, a programming method is used to generate BUS variable signals that can be directly referenced in MATLAB / Simulimk.
[0116] The present invention generates a BUS variable signal that can be directly referenced in MATLAB / Simulimk by programming for a data set participating in the construction of a virtual protection logic, thereby reducing the number of variables participating in the modeling of the virtual protection and improving the modeling speed and the model compilation efficiency; for a description file of the Outside interface type that does not participate in the construction of the virtual protection logic, multiple CSV files named with the IED name are imported through the background software, and the Outside interface type data can be edited in the interface and acted on the MMS Server in real time. After the multiple CSV files are imported, the mapMMS.txt file is automatically saved in the Config directory of the virtual protection model. When the virtual protection model is subsequently opened, there is no need to import it repeatedly, and the MMS Server-side program can automatically load the mapMMS.txt file for modeling.
[0117] Example 8. Figure 1-9 The automatic modeling process is shown as follows:
[0118] Extract the file name of the virtual protection modeling description file as the model name IED_TYPE corresponding to the virtual protection;
[0119] Read each line of information in the virtual protection modeling description file in sequence, and generate IED_TYPE_FromBus and IED_TYPE_ToBus bus data according to the interface classification of FromBus and ToBus; among them,
[0120] The elements in the IED_TYPE_FromBus bus data are all variables of the FromBus interface type, and the elements in the IED_TYPE_ToBus bus data are all variables of the ToBus interface type;
[0121] Each variable in the bus data is arranged according to the combination format of "type_variable name" in the description file;
[0122] Convert the data types of IED_TYPE_FromBus and IED_TYPE_ToBus to become IED_TYPE_FromSig and IED_TYPE_ToSig variable signals that can be directly referenced;
[0123] When modeling, with the help of the Data Store Memory transfer method of the Simulink simulation module, the IED_TYPE_FromSig data is used as the input of the virtual protection, and the IED_TYPE_ToSig data is used as the output of the virtual protection. When building the specific virtual protection logic, the required variables can be selected from the IED_TYPE_FromSig and IED_TYPE_ToSig data respectively.
[0124] When there are multiple virtual protection models of the same or different types, the IED_TYPE_FromBus bus data of all virtual protections at the same voltage level generate the top-level FromBus_Sub variable signal, and the IED_TYPE_ToBus bus data of all virtual protections generate the top-level ToBus_Sub variable signal, and then the data types of FromBus_Sub and ToBus_Sub are converted to become FromSig_Sub and ToSig_Sub variable signals that can be directly referenced. When modeling, it is necessary to select the IED_TYPE_FromBus bus data corresponding to the required modeled virtual protection from the top-level FromSig_Sub signal as the input of the virtual protection, and select the IED_TYPE_ToBus bus data corresponding to the required modeled virtual protection from the top-level ToSig_Sub signal as the output of the virtual protection. When building the specific virtual protection logic, select the required variables from the IED_TYPE_FromBus and IED_TYPE_ToBus data respectively.
[0125] The present invention directly models the data set involved in the construction of virtual protection logic, reducing the number of variables in virtual protection modeling, which is beneficial to improving the modeling speed and model compilation efficiency; bus data is directly referenced during modeling, without the need to name the variables in a special format, and the modeling method is clear and concise, avoiding the problem of repeated interface modeling in the "S-Function" encapsulation mode.
[0126] Example 9. This example shows how to edit a data set of FromBus and ToBus interface types, such as Figure 12-13 As shown,
[0127] Using GBK encoding, all FromBus and ToBus interface type data sets are generated into a mapBUS.txt file and uploaded to the background software. The FromBus interface type data is directly edited in the background software and acts on the MMSServer in real time. The information of the virtual protection ToBus interface type data can be viewed in real time on the receiving monitoring interface, providing a decision-making basis for the protection equipment that needs to be managed.
[0128] Example 10. Figure 1-13 A 500kV substation virtual relay protection modeling is shown. When performing virtual relay protection modeling of single bus protection, autotransformer protection, reactor protection, and short lead protection in a 500kV substation, the virtual protection modeling method based on bus data interaction is adopted.
[0129] The present invention, when modeling a 500kV substation virtual relay protection, effectively distinguishes between data sets that participate in and do not participate in the construction of virtual protection logic, wherein the data sets that participate in the construction of virtual protection logic form a description file for virtual protection modeling, based on a MATLAB / Simulimk modeling tool, with the aid of a bus data interaction method, modeling can be performed by directly referencing required variables from bus data, thereby reducing the number of variables involved in the modeling of virtual protection, improving the modeling speed and model compilation efficiency, and directly referencing bus data, eliminating complex variable naming rules, and avoiding the problem of repeated modeling of interfaces in an "S-Function" encapsulation mode in the prior art. The modeling method is clear and concise, and is very flexible when adding and deleting variable signals, with high efficiency and low error-proneness, and is particularly suitable for virtual protection with a large number of model variables in a 500kV substation.
[0130] The above disclosure is only the preferred embodiment of the present invention, which certainly cannot be used to limit the scope of rights of the present invention. Therefore, equivalent changes made according to the scope of the patent application of the present invention are still within the scope covered by the present invention.
Claims
1. A virtual protection modeling method based on bus data interaction, characterized in that: Distinguish between data sets that participate in and do not participate in the construction of virtual protection logic, divide data sets according to different customized interface types, form a description file for virtual protection modeling, and automatically model the data sets that participate in the construction of virtual protection logic based on MATLAB / Simulimk modeling tools and with the help of bus data interaction.
2. The virtual protection modeling method based on bus data interaction mode according to claim 1, characterized in that: The custom interface types include Outside, FromBus, ToBus, and ToREC. The Outside interface type does not participate in the construction of virtual protection logic, and its data set is a number of model description files that do not participate in the construction of virtual protection logic; The FromBus interface type participates in the construction of virtual protection logic, and its data set is several model description files of the input interface of virtual protection; The ToBus interface type is involved in the construction of virtual protection logic, and its data set is several model description files of the output interface of the virtual protection; The ToREC interface type participates in the construction of virtual protection logic and is a recording of virtual protection. Its data set is a custom data set member, including some data set members in the FromBus and ToBus interface types and intermediate variables generated in the virtual protection modeling process.
3. The virtual protection modeling method based on bus data interaction mode according to claim 2 is characterized in that: The data set involved in the construction of virtual protection logic generates bus variable data with the help of automatic modeling program, and references the required variables from the bus data for modeling; The data sets that do not participate in the construction of virtual protection logic are uploaded to the background software through several model description files to perform operation and editing of the variables in the data sets.
4. The virtual protection modeling method based on bus data interaction mode according to claim 2 is characterized in that: The Outside interface type description file includes at least one of the following: LD0 / LLN0.dsAin data set for internal state monitoring, LD0 / LLN0.dsRelayDin data set for protection remote signaling, LD0 / LLN0.dsAlarm data set for fault signal, LD0 / LLN0.dsWarning data set for alarm signal, LD0 / LLN0.dsCommState data set for communication working condition, LD0 / LLN0.dsDeviceState data set for device operation state, LD0 / LLN0.dsSetGrpNum data set for set value area code, LD0 / LLN0.dsAin1 data set for internal state monitoring 1, LD0 / LLN0.dsAin2 data set for internal state monitoring 2, LD0 / LLN0.dsFileState data set for file management, LD0 / LLN0.dsComParameter data set for communication parameters; The FromBus interface type description file includes at least one of the following: PROT / LLN0.dsSetting data set for protection settings, PROT / LLN0.dsParameter data set for device parameters, PROT / LLN0.dsRelayEna data set for protection pressure plates, and PIGO / LLN0.dsGOIN data set for GOOSE input signals; The ToBus interface type description file includes at least one of the following: PROT / LLN0.dsWarning dataset for alarm signals, PROT / LLN0.dsRelayDin dataset for protection telesignaling, PROT / LLN0.dsRelayFunEn dataset for protection function activation and deactivation, PROT / LLN0.dsRelayState dataset for protection function status, PROT / LLN0.dsRelayBlk dataset for protection function blocking, PROT / LLN0.dsTripInfo dataset for protection events, PROT / LLN0.dsRelayAin dataset for protection telemetry, PROT / LLN0.dsTripParaInfo dataset for fault magnitude, PIGO / LLN0.dsGOOSE dataset for GOOSE output signals; The ToREC interface type description file includes at least the RCD / LLN0.dsRelayRec data set for protection recording.
5. The virtual protection modeling method based on bus data interaction mode according to claim 1, characterized in that: The data set is the same worksheet in an Excel spreadsheet, which includes serial number, description, variable name type, initial value, variable name, and interface type information to form a set of description files for virtual protection modeling. The description file is named after the IED name of the virtual protection.
6. The virtual protection modeling method based on bus data interaction mode according to claim 5, characterized in that: When there are multiple sets of virtual protection modeling of the same type, the interface type and protection logic are exactly the same, only the variable values are inconsistent. At this time, you only need to create a new worksheet in the Excel table that also includes the serial number, description, variable name type, initial value, variable name, and interface type information; for multiple sets of virtual protection of different types, you need to create a new Excel table as the description file of the virtual protection.
7. The virtual protection modeling method based on bus data interaction mode according to claim 3 is characterized in that: For the description files of the Outside interface type that do not participate in the construction of virtual protection logic, multiple CSV files named after IEDs are imported through the background software. The Outside interface type data can be modified in this interface and acted on the MMS Server in real time. After importing multiple CSV files, the mapMMS.txt file will be automatically saved in the Config directory of the virtual protection model. When the virtual protection model is opened later, there is no need to import it again. The MMS Server program can automatically load the mapMMS.txt file for modeling. For the description files of FromBus and ToBus interface types involved in the construction of virtual protection logic, programming methods are used to generate BUS variable signals that can be directly referenced in MATLAB / Simulimk.
8. The virtual protection modeling method based on bus data interaction mode according to claim 7 is characterized in that: The automatic modeling process is as follows: Extract the file name of the virtual protection modeling description file as the model name IED_TYPE corresponding to the virtual protection; Read each line of information in the virtual protection modeling description file in sequence, and generate IED_TYPE_FromBus and IED_TYPE_ToBus bus data according to the interface classification of FromBus and ToBus; among them, The elements in the IED_TYPE_FromBus bus data are all variables of the FromBus interface type, and the elements in the IED_TYPE_ToBus bus data are all variables of the ToBus interface type; Each variable in the bus data is arranged according to the combination format of "type_variable name" in the description file; Convert the data types of IED_TYPE_FromBus and IED_TYPE_ToBus to become IED_TYPE_FromSig and IED_TYPE_ToSig variable signals that can be directly referenced; When modeling, with the help of the Data Store Memory transfer method of the Simulink simulation module, IED_TYPE_FromSig data is used as the input of the virtual protection, and IED_TYPE_ToSig data is used as the output of the virtual protection. When building the specific virtual protection logic, the required variables can be selected from the IED_TYPE_FromSig and IED_TYPE_ToSig data respectively; When multiple virtual protections of the same or different types are modeled, the IED_TYPE_FromBus bus data of all virtual protections at the same voltage level can be used to generate the top-level FromBus_Sub variable signal, and the IED_TYPE_ToBus bus data of all virtual protections can be used to generate the top-level ToBus_Sub variable signal.
9. The virtual protection modeling method based on bus data interaction mode according to claim 8, characterized in that: Using GBK encoding, all FromBus and ToBus interface type data sets are generated into a mapBUS.txt file and uploaded to the background software. The FromBus interface type data is directly modified in the background software and acts on the MMS Server in real time. The virtual protection ToBus interface type data information can be viewed in real time on the receiving monitoring interface.
10. A 500kV substation virtual relay protection modeling, characterized in that: When performing virtual relay protection modeling of single busbar protection, autotransformer protection, reactor protection, and short-lead protection in a 500kV substation, the virtual protection modeling method based on bus data interaction described in any one of claims 1 to 9 is adopted.