Flexible, Multi-Regional database usage of a new Computer-aided Relay Coordinator

: This paper represents detailed results of developing a huge applied software program of Overcurrent and Earth Fault relays coordination in high voltage substations. The paper introduces an effective structure which can be potentially used in power system study tools. It has been developed by using the programing language, Vb.net and connection to the database, Microsoft Access. According to the proposed structure, private databases are produced for different regions of grid while keeping accessibility to other regions. This will in turn help the boundary substations to be evaluated by system operators from different authorized study groups simultaneously. Data layer relations of the developed solver are discussed together with various block diagrams, representing connections between the entities. This relationship as well as managing coordination algorithm has been figured out by using a program of 22000 lines of code and the software program has been verified in practice on a large power system grid in a regional electric company for about 10 years.


Introduction
Applications of Artificial Intelligence Techniques (AITs) took place in many areas including medicine such as diagnosis, treatment of illness, patient pursuit, prediction of disease risk and etc. AITs allow designing systems that let you build intelligent models for both predicting patients' response in treatment process and determining prediction of illness risk. Since these fields have very high complexity and especially uncertainty, the use of AITs such as fuzzy logic, artificial neural networks, genetic algorithms, artificial immune systems and others have been developed by many researchers [1]. The competency abilities of AITs have been explored in most of medicine field. Artificial neural network was the most commonly used analytical tool whilst other artificial intelligent techniques such as fuzzy expert systems, evolutionary computation and hybrid intelligent systems have all been used in different clinical settings [2]. During the recent years some software programs have been developed to facilitate power system studies and coordination analysis in particular. They have their own methodologies to model grid and calculate coordination algorithms. In general, a coordination software program should manage a huge number of data, classes and objects belong to a grid and user primary given settings. There should be appropriate structural coding and decoding rules to help the solver to access data recorded in the corresponding databases. A substation within a grid includes exclusive characteristics. Those characteristics are really needed to distinguish that substation among many others. While working on coordination, for instance to study current relays coordination, any relay in any feeder of any substation should have specific identification (ID) and a computer-aided software program should keep and use them while involvement in the calculation. This paper focuses on data layers of a software program, a new applied relay coordinator. The program applies instructions mentioned in [1]- [7]. Since relay coordination field is a knowledge developed by science and experience, two of references, [4] and [5] which are internal reports and instructions, have been used meanwhile. They cover recommendations given in relay text books such as [1], [2] and [3]. In the software development, databases have vital importance and should be organized in such a way to be able to handle different user needs and cover technical requirements. On the other hand they should have suitable connectivity in order to make appropriate capabilities according to [8], [9] and [10]. The present paper is organized as follows: A brief description on how to arrange data layers for the program is given first. Then a symbolic structure of a substation is presented to make foundation for the discussions. Later on, some instructions to the way that protective components get coded and decoded are given. Based on the proposed structure of the database connections in this research, some block diagrams supports algorithms toward making databases backup and restore capabilities.

Managing database according to needs
To achieve the objectives already mentioned, two separate database units have been assigned as seen in Fig. 1, database for substation (Substation_DB) and database for relays (Relay_DB). The connection between two databases is used because while defining configuration for a substation relays with properties already defined in Relay_DB should be available. This is also to make more privacy for any group as well as possibility to generate new databases when a new region is born. This is discussed in more details in the next sections.

Regional-based data layers for grid
To extend capabilities, users of an applied relay coordinator should have possibility to define different regions and groups for a Grid under evaluation in a Regional Electric Company (REC). It means that a REC may need dividing the grid under study to several regions and several study groups meanwhile. Users of each group focus on the assigned portions, unless they want to have access to other pre-defined group/regions. Furthermore, a supervisor may need to check all calculations or data of the groups defined in different regions. The following Fig. 2 illustrates how different group/regions connect to each other. The simple block diagram includes two main program user interfaces (Substation Creator and Relay Creator) with connections to the databases (Substation database and relay database). There are also some output reports which will be discussed later on. In this figure a simplified block diagram has been assigned to represent how we separate different branches for different areas of a grid. According to our proposed method, each REC can include several sub-groups for example ZREC, TREC, GREC and KREC. For each Company name made by user (Such as ZREC) a folder is assigned under 'Companies'. Then another sub-folder is created for the specific Group like Group_1, Group_2, etc. For the sake of simplicity, the folder organization is represented briefly only for ZREC, including three sub-groups (Group_A1, Group_A2 and Group_A3). The other companies/regions like TREC can also have different groups which have not shown in this figure.

I. AUTHORITY OF ACCESS TO DIFFERENT DATABASES
The authority to access to data of other regions as well as interior study groups means who has access to what? Within each group a particular database for substations exists. Furthermore, there are a folder to keep backups, a folder assigned for calculation outputs and also a folder to keep single line diagrams belong to substations under study. They are created in the first try to create such groups and all the changes are applied to that specific substation database. Connection between the data to be extracted or generated in any cases is so important. A part of data should be copied as soon as a region is born especially for users of that area. Another part of data should be generated by users of that specific region. It is noted that the relay database is common for all authorized companies defined by the user. It means that all sub-groups or regions might edit relay database and use it in common. This is to aggregate data entered by different operators for a coordination software program.

Data entry and Main loop
As seen in Fig. 4 in the beneath, data is entered by a user while both Substation_DB and Relay_DB are involved.  The first time use of Substation_DB is for calculating primary key values needed in the coordination algorithms. This might be preparing per unit values or changing units for the next calculations. After this stage, program makes a structure for the calculation to proceed and run the main algorithms in a loop from the first feeder to the last. Starting coordination from downstream to upstream, there will be many interfaces between any pair of blocks. Furthermore some of protective positions including either of O/C or E/F relay might need to use settings already made for other relays. For example block assigned for an E/F relay in the HV-Side neutral of an autotransformer ('Case_9_EF') in a 230 kV substation uses current and time settings of HV-Side lines as well as 'Case_8_EF' and 'Case_4_EF' or 'Case_6_EF'. The first time using Relay_DB is to put rigid data of each relay in the defined structure to know which units are activated or deactivated or whether that specific relay is enabled. After this data gathering, program knows how to proceed with relays and whether it should call subroutines related to that relay or corresponding units. During calculation of settings for each relay in a position, connection to Relay_DB is configured to look for suitable range of settings in the database. The connection in different stages might be to different tables in the database. However the table name is not shown in the block diagram. After taking correct value, it should be normalized via other algorithms until the best result is achieved. Therefore, during the whole procedure, there will be several connections to this database (Case_X to Relay_DB).

Matrix based structure for modeling
A structure of protection for a substation is modeled to facilitate accessibility to different elements. We start from outgoing feeders (P1) to HV-Side neutral (P9). There will be a matrix with nine rows and several columns for many variables referring to a relay. For example for relay names which belongs to feeders we make a matrix with dimension 9×n that n refers to the number of feeders in a protective positions holding relay. Therefore, there will be two similar matrixes for O/C and E/F relay names. For example element number (3,1) in a matrix assigned for O/C relay name will show relay at incoming in the first transformer feeder. If it is (3,2), it will refer to the second incoming feeder accompany with second parallel transformer. There will be many matrixes like this to address other properties of a specific relay together with the location. According to instructions related to current relays' coordination [1]- [5],

to code an Overcurrent relay in a substation
Each relay should have exclusive number in a protective structure inside a substation. To highlight the code, its position should be exactly verified. To diagnose relay position, feeder position number (PX), feeder number and Feeder name in Substation_DB are needed all together. Two tables inside Substation_DB are needed to record properties of O/C and E/F relays. Another table is needed to recognize a substation among others. The second table includes some fixed data belong to the substation. The nature of these data differs from the data belong to feeders and includes general information about a substation. Table I represents how a component such as an O/C relay in specific feeder of a substation is coded. The standard that we use here to code a feeder follows protective positions according to Fig. 3. Now to find or revise a relay, program needs to know the following information:

1) Substation exclusive name 2) Feeder name 3) Feeder type (Outgoing feeder, bus-coupler, incoming, etc.).
The feeder identification number among the other feeders in the same protective position. This may change when a relay is removed and again added and might not be a sequential number. In the following example there are some hints to show how different feeder protective devices get coded. These are common for O/C relays as well as E/F relays where other properties for each relay may differ. For instance in an outgoing feeder, different type of either O/C relay or E/F relay may exist.

-Neutral _HV2
In the above coding procedure for the first row, the code 006301002 can be decoded starting from left side as: '0063' refers to Substation number. '01' refers to protective position number. '002' refers to feeder identification number. It is not '001' because that identification number has already been fired by the user (during feeder removal procedure).

To issue detailed and abstract reports
The software program offers both detailed calculation as well as abstract, separately for O/C and E/F relays. The detailed report is issued align with the main calculation. However to make a report for abstract results, it is needed to wait until all operation is done as represented in Fig. 6. The detailed reports are generated as soon as a block for example ('Case_1_OC') related to over current (O/C) relay calculation starts. After the procedure is done for all feeders and relays which is 'Case_9_E/F', generating abstract reports starts from 'Case_10_OC' to 'Case_90_EF'.
In the appendix, a detailed and abstract results are given only for one O/C relay activated in an outgoing feeder of a 230/63 kV substation in brief. to code an Overcurrent relay in relay database Relay database may be including several tables. Each table covers specific type of data related to relays in general. For example when talking about O/C and E/F relays, they have a couple of units such as start up, instantaneous, time or time multiply setting (TMS), etc. A relay has also some properties which are not numeric functions. For example brand of a relay, relay functionality, date of production etc. This kind of information can be recorded and managed in a specific table. Other data such as setting ranges may also be gathered in another table. In the following we focus on the last mentioned range-type settings and try to give exclusive identification for important items. In the following table II the way to code a relay's item is represented. There may be 9999 types of relay to be modeled in the Relay_DB. For each relay, 99 cases oftime-current characteristics (such as IDMT curves) can be defined. Each of which may include 99 items such as TMS, Instantaneous current value, etc. Also it is possible to have 99 of different ranges under the same item. To read or revise a relay item, program needs to know the following information:  Relay name which is exclusive.  Characteristic type or number (SI, EI, DT, …).


The item number among the other existing items (Is, TMS, T, Iinst, …).  An item may include several setting ranges. Therefore we need to give a number for each range. An integer number is assigned to each characteristic in which it can be diagnosed later. Following example represents a relay (Example) with two characteristics ('EI' and 'LT'). There are two repetitive ranges for the item 'Is'. In the above coding example, starting from left side for the first row, the code '104060101' can be decoded as:

10) EI
1040 refers to relay number. '60' refers to characteristic number 'EI'. The first two digits, '01' refers to item name 'Is'. The last two digits, '01' or 02 refer to the first and second ranges of 'Is' as represented by low set and high set comments.

Making backup and restore
While making backup, a copy of database should be kept in a default path inside the related region's folder. The backup file of Substation should be copied from Group_A1 to the subfolder named Backup under 'Substation backup' while common Relay_DB is copied from program folder to the specific Backup assigned for relay database. This is represented in Fig. 7, where only one company and one group are shown for the sake of simplicity. To restore databases with an already saved database, according to the region in use, backup databases can be restored and overwritten on the used database in that region (only for Substation_DB) and to common Relay_DB in the program folder.

Generating reports
Several users can work with their installed relay coordinator program either individually in different regions (different folders) or on a common/shared area (Common folder). In the first case shown in Fig. 8, they will make their own region and any report is copied for each user. Other users cannot see others' reports unless they have permission to do that. In the second case, users may want to work with the same data (same substation) and fields in a common database simultaneously. In this case, there will be two issues as follows: First of all, different users may try to give different values to variables already stored in the database at the same time. This is not a big issue since high level database managing systems normally handle such a frequent access request from different users. However, second issue may still arise when they run their own installed program, getting involved the same database, and they create the reports. Since their generated reports are copied to the same folder, there will be a confliction issue since a single text file cannot reflect different results. This can also be fixed giving different timing tag to any output as represented in Fig. 9. The timing label will be different for each user and therefore several output reports will be generated even at the same time with the users' desired input data entered. After running the coordinator program, users will see their own report automatically. Though they have another option to access and see reports from other operators in need.

Conclusion
Detailed and core information of implementing a software program, an Applied Relay Coordinator to attain main settings for over current and earth fault relays were given in this paper. Data layer as well as modelling structure of the program was described together with examples and block diagrams. The way to achieve flexibility to define many regions and groups were also proposed and required connections were configured.