Fundamentals of Protection Relays

8/9/2019 Fundamentals of Protection Relays

1/17

1

Fundamentals of Protective Relays Object Modeling

Alexander Apostolov

ALSTOM T&D, Protection & ControlLos Angeles, CA

Introduction

Microprocessor relays are the standard for all new substations and arecontinuously replacing electromechanical or solid state relays in existing substations. Theyoffer the significant advantages of their sophisticated functionality that allows thereplacement of multiple devices used for protection, metering, control, event and faultrecording by a single Intelligent Electronic Device (IED). The integration of this

functionality in a single device leads to reduced space, wiring, commissioning,maintenance and overall cost.

One of the main characteristics that makes microprocessor based relays intelligentis their ability to communicate - to communicate with their peer (other IED's), substationcomputers, SCADA systems, etc. This ability makes obvious the next step in theintegration process - integrated substation protection and control systems.

The biggest obstacle in this integration process is the fact that Intelligent ElectronicDevices (IEDs) from different manufacturers or even from the same vendor use differentcommunication protocols and different user interfaces for real time data acquisition, data

archiving, substation control and fault records extraction. This to a great extent reducesthe benefits of integration because of the need for additional hardware, such as protocol

converters, data concentrators, software (multiple user interface programs) and increasedengineering and training costs. The industry is currently in the process of developing auniversal platform that will allow a “plug-and-play” technology to replace today’sproprietary devices.

This requires a significant joint effort by experts, who until recently came fromcompletely different fields such as power system protection, metering, information

systems, communications, energy control systems, etc.

The only solution to this problem is the object-oriented approach to the client-server and peer-to-peer communications between IEDs in the substation and the powersystem.

This is not an easy task and requires understanding of the existing and developing

technology for substation and power system integration and automation.

At the same time this new technology changes significantly the required level of expertise of protection engineers and technicians. Knowledge of protection is not sufficientanymore - understanding of different aspects of IED communications becomes essential.

This paper discusses some fundamental concepts and definitions implemented inthe modeling of multifunctional advanced protective relays based on the principles and


2/17

2

basic relay object models developed as part of the Utilities Communications Architecture(UCA) and the Utility Initiative.

Typical Digital Protection and Control System

A simplified diagram of a typical UCA substation Digital Protection and ControlSystem is shown on Figure 1.

It consists of a series of devices interconnected through one or more Ethernetnetworks. Such a system has a hierarchical structure with distributed intelligence and high

level of complexity:

At the bottom of the integrated system are the multifunctional protective IntelligentElectronic Devices(IED). Their primary function is to protect different substation and power

system elements such as transformers, buses, capacitor banks, transmission anddistribution lines.

Figure 1. Typical UCA substation integration system topology

The protective IEDs however perform this basic function only when there is a fault,which is an event with very low probability. At the same time they are devices with

• • •

• • •

• • • • •

• • •

FRAD

FRAD

FRAD

SCADA

Master

SYMMETRY

WAN

ETHERNETHUB B

ETHERNETHUB A

(ALTERNATE)

R C C

L C C

Printer

IED

A1 A2 A3 An

IED

B1 B2 B3 Bn

MAINTENANCE

(OPTIONAL)

HMIMMS CLIENT

Local Control Computer

ROUTER


3/17

3

significant processing power and intelligence. This allows their use as the lower level of the hierarchical data acquisition, control, monitoring and fault recording system.

At the next level are the Bay Controller IED's that provide additional digital and

analog interface with the substation environment and at the same provide protection andcontrol functionality at the bay level in the substation.

In the case of an Ethernet based substation integration architecture both theindividual substation equipment IED’s and the Bay Controller IED’a are connected to thesame physical LAN. The hierarchy in this case is functional, not physical.

At the top of the multilevel integrated protection and control system in thesubstation is the substation computer, which provides the Human Machine Interface withthe different IEDs in the substation. It also supports alarm and event reporting, dataarchiving, analysis, monitoring, etc. functions.

The advantages of such architecture include reduced wiring, improved reliability,better overall protection and control functionality.

In the above described architecture the Ethernet network is shown with therequired hubs and an optional router. There are many types of hubs, that can bedescribed as two main groups: active and passive. Passive hubs can be considered as a

junction box, while active hubs are used as repeaters that regenerate the signals goingfrom one network device to another.

Routers on the other hand are used to separate different parts of the network inorder to reduce the traffic on each network and improve the performance of the

integrated protection and control system. They examine the address information in thedata packets and send them along a predefined path to their destination.

The interface between the Local Area Network (LAN) in the substation and the

Wide Area Network (WAN) is shown through a FRAD (Frame Relay Access Device).Frame Relay is a packet-oriented communication method for connecting computersystems over public or private networks. It uses permanent virtual circuits (PVC) as apredefined path to connect two end points (the substation LAN with a SCADA master)through the Frame Relay network.

Communications interoperability over this substation network is the key to

successful integration of microprocessor based relays in substation automation systems.

Interoperability can be defined as the capacity to communicate, execute programs ortransfer data amongst the various elements of a system or network without requiringextensive knowledge of the equipment and processes involved.

The International Organization for Standardization (ISO) is responsible for the

development and maintenance of the Open Systems Interconnection (OSI) referencemodel. They promote an open networking environment that allows multi-vendorcomputer based devices to communicate using protocols accepted by ISO members. Themodel is built around the concept of a multi-layered architecture that specifies differentfunctions and services at different levels of the “protocol stack”. Hardware componentsare based on specifications defined in the lower layers of the stack, while layers above


4/17


5/17

5

creation of an object from its class. The class defines the information and behavior of theinstance, while the current state of the instance is defined by the operations performed on

the instance. Each instance has a unique identity. For example, Overcurrent Relay could

be defined as a Class with Phase and Ground as instances (Object instantiations) of theclass.

Objects represent information and behavior. Thus they have properties (orcomponents, attributes), and services (or methods, and events). Properties are data thatdescribe an object. Methods are things you can tell the object to do, while events are

things the object does.

The above described objects are used for communications between different IED’son a network. A client IED or application is a network entity that issues service requeststo a server. In an electric utility a client can be the substation network master polling forreal time currents and voltages or a protection engineer making setting changes from his

computer on the corporate Wide Area Network.

A server IED is a network entity that responds to the requests of a client. In thecase of substation integration it can be the relay responding to the polling request of thesubstation master or to the setting change command from the protection engineer. It canalso be the substation master responding to a request from a planning engineer toprovide the load profile for a transformer in the substation.

The same real or virtual device can perform either as a client or as a server. Forexample, a bay controller IED will be a Client to the protective IED’s of the lines andtransformers, while at the same time is a Server to the substation computer. One should

keep in mind that the virtual device model defines the network visible behavior of serversonly.

The IED’s can also work in a peer-to-peer network where each entity has thesame status on the network, i.e. there are no masters and no slaves.

The modeling of a real device leads to the creation of the virtual device associatedwith it. There is a distinction between a real device (an IED) and the real objectscontained in it and the virtual device and objects defined by the model. Real devices andobjects have features associated with them that are unique to each brand of device or

application. Virtual devices and objects conform to the model and are independent of brand, language or operating system. The Virtual Device model only specifies thenetwork visible aspects of communications. Each server device or server applicationdeveloper is responsible for “hiding” the details of their real devices and objects. Sinceclients always interact with the virtual device and objects defined by the model, their

applications are isolated from the specifics of the real devices and objects. A properlydesigned client application can communicate with many different brands and types of devices in the same manner. That is why protective relay modeling is critical to achievinginteroperability between clients and servers in the electric utility.

This method allows the integration system designer to develop an object model,which to a great extent will provide similar information to the client, regardless of the fact

that it represents a virtual protective device with real communication capabilities or a real


6/17

6

electromechanical relay with virtual communication capabilities. All of this is possiblewhen the server to the corporate client is the substation master and the relay is a server to

the substation computer (Fig. 2).

Figure 2 Client - Server relationships in Virtual Device modeling

The concept of a utility distributed data base should also be considered in theobject model development process. The assumption is that the information is stored as

close as possible to the real object and is available to the client through the servicesprovided by the model. Most of the data in a microprocessor IED is stored in its’ ROM orRAM and is accessible either directly or through the Substation Master.

For electromechanical or solid state relays, breakers, transformers and other realdevices with no communication and data storage capabilities, the data is stored in thesubstation computer data base or is available from the real time data base of the IEDsassociated with the Virtual Devices.

This information is accessible only through the services of the Substation Master,that responds as a server to the requests of a corporate client.

The development of simple and complex object models is based on the objecthierarchy shown on Fig. 3.

The naming conventions used are compliant with the Manufacturing Message

Specification (MMS), because MMS/Ethernet was selected for the Utility Initiative. TheUtilities Communications Architecture (UCA) defines a Power System Object Model(PSOM). The UCA substation and feeder elements of the PSOM are used to model therepresentation of substation field equipment for the identification and development of communication and performance requirements, and the generic services required forcommunicating with substation field equipment. It does not describe the mapping of the

Server

Substation

Master

Client

Server

Substation

Data Base VD

Client

Substation

Master

Server

IED

Data Base


7/17

7

objects onto the application layer: this is the function of another UCA document, knownas UCA 2.0 Common Application Services Model and Mapping to MMS (CASM).

CASM by definition is independent of MMS, thus the naming conventions apply to

CASM and it is desirable that they facilitate MMS mapping as well as mapping to otherapplication layers.

Logical Device Object Models

Basic Building Bricks

Functional Components

Common Data Classes

Common Components

Standard Data Types

Figure 3 Object model hierarchy

The Generic Object Models for Substation and Feeder Equipment (GOMSFE)apply the concept of Basic Building Bricks that are standardized reusable groupings of associated data objects that address a focused function or use. Object Models are thendefined as specialized groupings of associated Bricks that model devices, functions orapplications of a specific function or application in the problem domain, i.e., protection,

control and data acquisition.

Standard Data Type defines how the component values of all possible class-objects are represented. The Standard Data Type determines the format, the number of bits to communicate the value, and the range of possible values. (e.g. an unsigned eight

bit integer is defined as INT8U.)Common Components represent the elementary components used in the class-

object definitions. The names for Common Components are constructed from commonabbreviations. Definition of these Common Components allows them to be defined onlyonce and then listed under the Common Class definitions. An example of a commoncomponent is “b”, which represents a binary value with a data type of BOOL.

Common Data Classes are groups or structures of components which are the

attributes of the object.. The components are named variables associated with datarepresented by the Common Data Classes. The components are specified according to

Object Hierarchy


8/17

8

the Standard Data Types. Common Data Classes represent the commonly used class-objects. AI is an example of a common data class used to define an Analog Input.

Bricks are standardized reusable groupings of associated data objects that

address a focused function or use.

Logical Device Object Models are specialized groupings of associated Bricks thatrepresent devices, functions or applications of a specific function in the problem domain,i.e., protection, control and data acquisition.

When all Data Objects have been defined based on the hierarchy in Fig. 3, they

are assembled into Functional Component groupings to present the finished DeviceModel. Each IED functioning as a Server within a network can represent multiple logicaldevices, each of which implements one or more Device Models.

A multifunctional protection device object model is built using the basic building

“bricks”. In GOMSFE they are defined as standard collections of data objects andstructures that logical device models are assembled from. These bricks are combined toform logical device models that represent real world devices.

The communications visible protection functions in microprocessor protectiondevices are modeled in an object hierarchy (Fig. 6) based on a set of pre-defined objectmodels, predominantly multiple instances of a Protection Basic Relay Object (buildingblock PBRO).

MONITORED INPUTS

UT

1 0

PBRO

BASIC RELAY OBJECT

SETPOINT

CONTROL

(ENA, DIS)

(PU)

AUXIN

(Bool[16])

AUXOUT

TARGET

Fig. 4 Basic Relay Object (PBRO)

The Basic Relay Object (PBRO) provides a basic building block containingfunctionality common to many relays. It has a control, that allows it to be enabled ordisabled, a set point, a target and other typical functions. Not all attributes must be usedwhen instantiating the PBRO - only the ones available and visible to the communications

interface.

This block is then used either by itself, or in combination with other basic buildingblocks and other object components for building more complex relay objects (Fig. 6). By

just changing the monitored input it can be used to model an under or overcurrent phase


9/17

9

and ground relay (PIOC model), negative or positive sequence overcurrent relay, etc. It isused for instantaneous or definite time delayed protection functions and has a pick-up,

time delay on pickup and/or time delay on drop-out settings. It can be combined with a

directional element PDIR in order to model a directional overcurrent relay. The table below shows as an example the properties of the PBRO as a grouping of

associated data objects that address a model of a simple single function protectiondevice. It can be compared to a single phase overcurrent electromechanical relay andcan be used to model device functions that receive control commands (binary and

analog), setting changes (binary and analog), and indication data (binary and analog)from other objects. The object model maintains relevant data, such as configurationparameters, settings (binary and analog) and indication data (binary and analog). Theobject model outputs control commands (binary and analog) and indication data (binaryand analog).

Table 1 Protective Basic Relay Object PBRO

FC Object Name Class rw m/o Description

S Operation

Out BOOL r o Present output status of the element

Tar PhsTar r o Targets since last reset

FctDS SIT r o Function is enabled/disabled

AuxIn BSTR16 r o Block of 16 auxiliary inputs

PuGrp INT8U r o Settings PuGroup selected for use

SG Relay Settings

Pu PUG rw o When the measurements exceed (or drop below, in the

case of a dropout function) this value, the protection

control operation is initiated.

PuDelTim INT32U rw o Pickup Time Delay

DODelTim INT32U rw o Drop Out Time Delay

CO EnaDisFct DCO w o Enable/Disable relay function

RsTar BO w o Reset ALL Targets

RsLat BO w o Reset ALL Latched Outputs

EnaLatRs BO w o Enable/Disable resetting latch inputs

AuxOut BOOL[16] w o Block of 16 individually addressable auxiliary outputs

CF All PBRO.SP ACF rw o Configuration for all included PBRO.SP

All PBRO.CO CCF rw o Configuration for all included PBRO.CODC All PBRO.ST d rw o Description of all included PBRO.ST

All PBRO.SP d rw o Description of all included PBRO.SP

All PBRO.CO d rw o Description of all included PBRO.CO

AS All Related IEDs TBD rw m Associations with all related functions and IEDs.

All object parameters can be mandatory (m) or optional (o).

Configuration Parameters (CF) are values that determine the setup of the deviceand are not expected to change often. Configuration Parameters are usually changed

when the operating environment of the device has changed, the monitored system has


10/17

10

changed, or the device has been relocated to another part of the system. ConfigurationParameters can be read (r) and written (w) to, but can only be changed by authorized

users or other devices

Settings (SP) contain set points relating to the pick up and time delay of theprotection function modeled.

Modern relays have multiple setting groups. If the set points can be differentdepending on the setting group selection, (SG from Setting Group) gives the values thatdetermine the operation of the device and can change often. Settings are usually

changed when operating conditions change. Settings can be read and written to, but canonly be changed by authorized users or other devices.

Operation represents the actual output decisions or commands of the model toperform its functions. These may be binary or analog (setpoint) outputs.

Status (ST from Status) represents the indications or values directly concerned withthe function of the device. Status values are usually (but not always) on-off, set-not set, ortrue-false types of indication analogous to mechanical or LED indications on devices.Boolean Status values may be grouped into Bitstring. Status values are only necessary forinteraction with other objects and devices in the problem domain. These parameters aregenerated by the device, but are not values internal to the algorithms or processes of thedevice that are considered proprietary by the manufacturer.

Each relay object that instantiates the PBRO can have controls (CO) that determineits mode of operation.

Description (DC) contains additional descriptive information of the different dataobjects included in the model, such as status, set points, controls, etc…

Associated Parameters (AS) are values that are associated with the function of the

model. These parameters are only necessary for interaction with other objects anddevices in the problem domain, i.e., values and indication for other objects and devices.

These parameters may be calculated within the device, or obtained from other objects insome form, but are not values internal to the algorithms or processes of the device thatare considered proprietary by the manufacturer. Associated Parameters can also be

referred to as “pseudo-points”.

Example : Multifunctional Distribution Protection Object Model

As described above, the multifunctional distribution protection device object model

is built using basic building “bricks”. It is selected as an example, because it includes alltypical objects model, while it is not very complicated since most of the protectionfunctions can be modeled as instances of the PBRO.

The description, vendor, owner and nameplate information of the distributionprotection IED is defined by the Device Identity (DI) (see Fig. 5).


11/17

11

Fdr1/GLOBE.DC.DI.d D3PH+DEF RELAY

Fdr1/GLOBE.DC.DI.Loc S/S CB REFFdr1/GLOBE.DC.VndID.Mdl KCEG142?????MED

Fdr1/GLOBE.DC.VndID.HwRev 17KCEG14201XMEFdr1/GLOBE.DC.VndID.SwRev 18 KCEG100 XXE I

Fdr1/GLOBE.DC.VndID.SerNum 146G570Fdr1/GLOBE.DC.EqRtg.Hz 60HzFdr1/GLOBE.ST.ActSG 1 (Active Setting Grp)Fdr 1 / G LO BE.CF.FctLn k 0000000011010110

Fig. 5 Example of mapping to a GLOBE object

DataObjects

phsPIOC0.SG.Pu.Phsi I>>

phsPIOC0.SG.TimDelPu.Phsi t>>

FunctionalComponentphsPIOC0.SG

DeviceModel

phsPIOC0

rapper

phs

LogicalDevice

Fdr1/

Server@

Fig. 6 Distribution relay object hierarchy

If we consider the distribution protection relay as a server, at the Logical Devicelevel it has a set of global attributes defined in a GLOBE object model [1].

It includes data objects that are used to control the access and use of data objectsincluded in the “Settings Group” Functional Component. It is used to copy, save oractivate relay setting groups, determine the relay mode of operation, etc.

GLOBE contains data sets for retrieval by a Client. Numerous Data Sets may bedefined for the distribution protection object model. An example of the data sets providedby it’s GLOBE are the sum of all of the measurements: phase and sequence currents andvoltages, frequency, power factor, etc., depending on the metering functions of the relaybeing modeled. Another example can be the sum of all monitored status points, such as

breakers, etc.


12/17

12

The PBRO is used for the definite time delayed phase overcurrent protectionfunction phsPIOC0 (Fig. 6).

The Basic Time Curve Object (PBTC) provides a basic building block containing

Time Curve functionality common to many relays. This block is used in combination withother basic building blocks and objects for building more complex relay objects. Again bychanging the monitored input it can be used to model the inverse-time curve of phase orground overcurrent element in a multifunctional distribution protection IED. Its’ settingsinclude curve type, time dial, etc.[1]. The inverse time overcurrent element (PTOC model)

uses a combination of PBRO and PBTC object models.

Data mapping of inverse and definite time phase overcurrent elements intoGOMSFE relay object models are shown in Fig. 7.

phsPTOC0.SG.CrvTyp.Phsi Curve

phsPTOC0.SG.Pu.Phsi I>phsPTOC0.SG.TimDial.Phsi t>/TMSphsPTOC0.SG.TimDelPu.Phsi t>/DTphsPTOC0.SG. TimDelDO.Phsi Curve

phsPIOC0.SG.Pu.Phsi I>>phsPIOC0.SG.TimDelPu.Phsi t>>phsPIOC1.SG.Pu.Phsi I>>>phsPIOC1.SG.TimDelPu.Phsi t>>>phsPDOC0.SG.MaxTorqAng.Phsi Char Angle

phsPUCP0.SG. Pu.Phsi I<

phsRATO0.CF.ARatio.PhsA CT Ratio

Fig. 7 Example of mapping to Overcurrent Objects

Instrumentation metering (not for revenue purposes), is a function that exists intypical distribution protection devices.

"MMXU0","{(A), Ia, Ib, Ic, Io

(V), Va, Vb, Vc, Vo (PhsPhsV), Vab, Vbc, Vca

(Hz), F (TotW), 3W

(TotVAr), 3VAr (TotVA), 3VA (MaxPkA), Imax (TotPF) PowerFactor (VAr), VARa, VARb, VARc

Fig. 8 Example of mapping to Metering Objects


13/17

13

It is modeled as a part of the IED and implements the Measurement Unit (MU)model. In the case of a multifunctional distribution protection relay, it includes multiple

measurements based on the three phase current and voltage data available.

Some of the values are direct current and voltage measurements, other arecalculated - such as active and reactive power or power factor. Distribution protectionrelays also provide demand metering measurements and breaker performance data.Examples of Metering data objects are shown in Fig. 8.

High Speed Peer-to-Peer Communications

The peer-to-peer communications are based on what is defined as a GOOSE [1]. This is a Generic Object Oriented Substation Event (GOOSE) and it is based upon theasynchronous reporting of an IED’s digital outputs status to other peer devices enrolled to

receive it during the configuration stages of the substation integration process (Fig. 9). Itis used to replace the hard wired control signal exchange between IED’s for interlockingand protection purposes and, consequently, is mission sensitive, time critical and must behighly reliable.

l

l

l

RECEIVINGIED(c)

SENDINGIED

(a)

RECEIVINGIED

(b)

RECEIVINGIED

(n)

SubstationLAN

GOOSE

Figure 9 GOOSE message for protection functions

The associated IEDs receiving the message use the contained information todetermine what the appropriate protection response is for the given state. The decision of the appropriate action to GOOSE messages and the action to take should a messagetime out due to a communication failure is determined by local intelligence in the IED

receiving the GOOSE message. It can be used for Breaker Failure Protection to trip the


14/17

14

adjacent breakers or to provide distribution or sub-transmission bus protection based onGOOSE messages from the feeder protection IEDs.

The table below includes the common components used to facilitate the GOOSE

Class Object.

Table 2 GOOSE structure

Considering the importance of the functions performed using GOOSE messages,UCA defines very strict performance requirements. The idea is that the implementation of high speed peer-to-peer communications should be equal to or better than what isachievable by existing technology. Thus the total peer-to-peer time should not exceed 4

ms.

Another important requirement for the GOOSE messages is very high reliability.Since the messages are not confirmed, but multicasted, and considering the importanceof a message such as Initiate Breaker Failure Protection, there has to be a mechanism toensure that the receiving IED’s will receive the message and operate as expected. To

achieve a high level of reliability, messages will be repeated as long as the state persists. To maximize dependability and security, a message will have a time to live which will beknown as “hold time”. After the hold time expires the message (status) will expire unlessthe same status message is repeated or a new message is received prior to theexpiration of the hold time.

The repeat time for the initial GOOSE message will be short and subsequent

messages have an increase in repeat and hold times until a maximum is reached. TheGOOSE message contains information (Table 2) that will allow the receiving IED to knowthat a message has been missed, a status has changed and the time since the last statuschange.

Common Components Required for GOOSE

Name Description Data Type

SendingIED

Sending IED IDENT IDENT

t GOOSE Timestamp BTIME6

SqNum Message Sequence

Number

INT16U

StNum Event Sequence Number INT16U

HoldTim Time to Wait before RS INT16U

BackTim Time since Event INT16U

PhsID Identifies Faulted Phases INT16U

DNA Protection DNA BSTR64

UserSt User defined Bitstring,used in bit pairs

BSTR256


15/17

15

In order to achieve high speed performance and at the same time reduce thenetwork traffic during severe fault conditions, the GOOSE message has been designed

based on the idea to have a single message that conveys all required protection scheme

information regarding an individual protection IED. It represents a state machine thatreports the status of the devices in the IED to it’s peers. Table 3 below defines the use of the standardized DNA for protection messages:

Table 3 GOOSE DNA

To allow further customization of the GOOSE messages, individual applicationscan map other status points to the User Defined bit pairs UserSt.

Bit Order 00 01 10 11

Bit # Bit Value 0 1 2 3

Pair Definition State State State State

0, 1 1 OperDev Normal Trip Close Invalid

2, 3 2 Lock Out Invalid Normal LO Invalid4, 5 3 Initiate Reclosing Normal Cancel Auto Reclosing Invalid

6, 7 4 Block Reclosing Normal Cancel Block Invalid

8, 9 5 Breaker Failure Initiate Normal Cancel Initiate Invalid

10, 11 6 Send Transfer Trip Normal Cancel Set Invalid

12, 13 7 Receive Transfer Trip Normal Cancel Set Invalid

14, 15 8 Send Perm Normal Cancel Send Perm Invalid

16, 17 9 Receive Perm Normal Cancel Receive Perm Invalid

18, 19 10 Stop Perm Normal Cancel Stop Perm Invalid

20, 21 11 Send Block Normal Cancel Send Block Invalid

22, 23 12 Receive Block Normal Cancel Receive Block Invalid

24, 25 13 Stop Block Normal Cancel Stop Block Invalid

26, 27 14 BkrDS Between Open Closed Invalid28, 29 15 BkrPhsADS Between Open Closed Invalid

30, 31 16 BkrPhsBDS Between Open Closed Invalid

32, 33 17 BkrPhsCDS Between Open Closed Invalid

34, 35 18 DiscSwDS Between Open Closed Invalid

36, 37 19 Interlock DS Invalid Non Interlock Interlock Invalid

38, 39 20 LineEndOpen Between Open Closed Invalid

40, 41 21 Mode Test Offline Available Unhealthy

42, 43 22 Event Invalid Normal Event Invalid

44, 45 23 Fault Present Invalid Clear Present Invalid

46, 47 24 Sustained Arc Invalid Normal Present Invalid

48, 49 25 Downed Conductor Invalid Normal Downed Invalid

50, 51 26 Sync Closing Normal Cancel Initiate Invalid

52, 53 27 Reserved

54, 55 28 Reserved

56, 57 29 Reserved

58, 59 30 Reserved

60, 61 31 Reserved

62, 63 32 Reserved


16/17

16

An example for the use of GOOSE messages in distribution protection is shown inFig. 10. For a fault on any distribution feeder (F2 to F5) it will send a blocking GOOSE

message to the relay at the low side of the transformer. If the fault is on the bus (F1),

none of the distribution relays will operate and the transformer relay will not receive anyblocking signal. It will determine that this is a distribution bus fault and will send aGOOSE message to trip the transformer breaker and clear the fault.

Fig. 10 Use of GOOSE messages for distribution bus protection

Another example can be a sub-transmission bus protection scheme based on theexchange of directional signals between the individual protective IED’s and the sub-transmission bus bay controller IED. If all protection IED’s see a fault in the reversedirection, the bay controller makes a decision that there is a bus fault and will send aGOOSE message to all IED’s connected to the faulted bus to trip their associatedbreakers.

ConclusionsSubstation Integration and Automation are becoming one of the tools that can

help a utility to achieve reduced installation, maintenance and operations costs. This ispossible because of the integration of microprocessor based devices, particularly

protective relays, into Substation or even Power System Integration Systems.

Interoperability between protective relays from different manufacturers in thesubstation becomes a necessity in order to achieve substation level interlocking,protection and control functions and improve the efficiency of microprocessor basedrelays applications.


17/17

17

This can be achieved by the joint efforts of utility and manufacturer experts in thefields of power system protection, control and communications. The primary goal of

object modeling of protective relays is to specify a standard communications mechanism

for such devices and their integration into computer applications that would achieve ahigh level of interoperability in a client/server and peer-to-peer relationship. The UCA2.0 project and the Utility Initiative defined the fundamentals of the basic object modelspresented in the paper.

The object model for multifunctional protection IED’s are developed based on the

assumption that such devices are composite complex objects. The functionality of suchdevice is modeled using GOMSFE object models.

GOOSE messages are implemented for protection related functions and wereintroduced with examples as well.

For further reading :

1. Generic Object Models for Substation and Feeder Equipment (GOMSFE),Version 0.9

2. Substation Integrated Protection, Control and Data Acquisition, Phase 1, Task2, Requirements Specification, Preliminary Report, Version 1.0

3. Object Models: Strategies, Patterns & Applications by Peter Coad, David Northand Mark Mayfield, Prentice Hall, 1993;

4. Overview and Introduction to the Manufacturing Message Specification (MMS),

Rev. 2, SISCO, Inc. 1995

Documents

Fundamentals of Protection Relays