Fundamentals of Protection Relays

Embed Size (px)

Citation preview

  • 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

  • 8/9/2019 Fundamentals of Protection Relays

    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

  • 8/9/2019 Fundamentals of Protection Relays

    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

  • 8/9/2019 Fundamentals of Protection Relays

    4/17

  • 8/9/2019 Fundamentals of Protection Relays

    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

  • 8/9/2019 Fundamentals of Protection Relays

    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

  • 8/9/2019 Fundamentals of Protection Relays

    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/9/2019 Fundamentals of Protection Relays

    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

  • 8/9/2019 Fundamentals of Protection Relays

    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

  • 8/9/2019 Fundamentals of Protection Relays

    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).

  • 8/9/2019 Fundamentals of Protection Relays

    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.

  • 8/9/2019 Fundamentals of Protection Relays

    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

  • 8/9/2019 Fundamentals of Protection Relays

    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

  • 8/9/2019 Fundamentals of Protection Relays

    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

  • 8/9/2019 Fundamentals of Protection Relays

    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

  • 8/9/2019 Fundamentals of Protection Relays

    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.

  • 8/9/2019 Fundamentals of Protection Relays

    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