57-61850-90-1-DTR

– 2 – 61850-90-1/DTR © IEC(E)

CONTENTS

FOREWORD.........................................................................................................................5 INTRODUCTION...................................................................................................................7 1 Scope ............................................................................................................................8 2 Normative references .....................................................................................................8 3 Terms and definitions .....................................................................................................9 4 Abbreviated terms ..........................................................................................................9 5 Use cases ....................................................................................................................10

5.1 General ...............................................................................................................10 5.2 Distance line protection with permissive overreach tele-protection scheme ...........10 5.3 Distance line protection with blocking tele-protection scheme ...............................13 5.4 Directional comparison protection ........................................................................16 5.5 Transfer/Direct tripping ........................................................................................18 5.6 Interlocking .........................................................................................................20 5.7 Multi-phase auto-reclosing application for parallel line systems.............................23 5.8 Current differential line protection ........................................................................26 5.9 Phase comparison protection ...............................................................................29 5.10 Other applications ...............................................................................................32

5.10.1 General ...................................................................................................32 5.10.2 Fault locator system (2, 3 terminals) .........................................................32 5.10.3 System integrity protection schemes (SIPS)..............................................34 5.10.4 Real time predictive generator shedding ...................................................38 5.10.5 Out-of-step detection ...............................................................................42 5.10.6 Synchrophasors .......................................................................................44 5.10.7 Remedial action schemes (RAS) ..............................................................44

6 Communication requirements for substation-to-substation communication .....................45 6.1 General issues ....................................................................................................45

6.1.1 Introduction..............................................................................................45 6.1.2 Logical allocation of functions and interfaces (5.2 in IEC 61850-5) ............45 6.1.3 The role of interfaces ...............................................................................46 6.1.4 Response behaviour requirements ...........................................................46

6.2 Functions based on substation-substation communication ....................................47 6.2.1 Protection functions .................................................................................47 6.2.2 Control functions......................................................................................48

6.3 Message performance requirements.....................................................................48 6.3.1 Transfer time definition (13.4 in IEC 61850-5) ...........................................48

6.4 The introduction and use of message performance classes...................................50 6.4.1 General ...................................................................................................50 6.4.2 Control and protection..............................................................................51 6.4.3 Metering and power quality ......................................................................52

6.5 General requirements for data integrity ................................................................54 6.6 Requirements for teleprotection ...........................................................................55

6.6.1 Reliability (security and dependability)......................................................55 7 Considerations on security and dependability issues when using Ethernet networks.......56

7.1 General ...............................................................................................................56

61850-90-1/DTR © IEC(E) – 3 –

7.2 Security of traffic .................................................................................................56 7.3 Dependability of traffic .........................................................................................56 7.4 Avoiding GOOSE packets flooding the WAN.........................................................57 7.5 Summary on recommendations for using Ethernet for communication

between substations ............................................................................................57 7.5.1 General ...................................................................................................57 7.5.2 Example of packet delays.........................................................................58

7.6 Useful features of some Ethernet telecommunications networks ...........................58 8 Communication aspects ................................................................................................59

8.1 Services ..............................................................................................................59 8.2 Communication architecture.................................................................................59

8.2.1 Preliminary notes and definitions ..............................................................59 8.2.2 Tunnelling................................................................................................60 8.2.3 Gateway ..................................................................................................61

9 Modelling .....................................................................................................................63 9.1 General architecture ............................................................................................63 9.2 Communication interface RTPC ...........................................................................63 9.3 Communication-aided protection schemes and direct tripping ...............................65

9.3.1 Proposed model .......................................................................................65 9.3.2 LN PSCH .................................................................................................66

9.4 Differential protection schemes ............................................................................67 9.4.1 Proposed model .......................................................................................67 9.4.2 LN RMXU ................................................................................................69 9.4.3 SV format ................................................................................................70

10 Configuration aspects ...................................................................................................71 10.1 General ...............................................................................................................71 10.2 Direct communication link ....................................................................................71

10.2.1 General ...................................................................................................71 10.2.2 SCL enhancements ..................................................................................75 10.2.3 SCL example ...........................................................................................75

10.3 Tele-protection equipment between substations ...................................................81 11 Bibliography .................................................................................................................82 Figure 1 – Distance line protection with permissive overreach tele-protection scheme [1]..........................................................................................................................10 Figure 2 – Distance line protection with blocking tele-protection scheme [1] .........................13 Figure 3 – Directional comparison with permissive scheme [1] .............................................16 Figure 4 – Transfer/Direct Tripping ......................................................................................18 Figure 5 – Interlocking – Interoperation ...............................................................................20 Figure 6 – Auto-reclosing ....................................................................................................23 Figure 7 – Current differential line protection [1] ..................................................................26 Figure 8 – Phase comparison protection [1] .........................................................................29 Figure 9 – Principle to detect internal fault by phase comparison [1] ....................................29 Figure 10 – Fault locator system (2, 3 terminals) .................................................................32 Figure 11 – Example of a System Integrity Protection Scheme.............................................34 Figure 12 – Real time predictive type generator shedding system ........................................38 Figure 13 – Out-of-step detection ........................................................................................42

– 4 – 61850-90-1/DTR © IEC(E)

Figure 14 – Logical interfaces between substation A and substation B .................................45 Figure 15 – Transfer time for binary and other signals over a serial connection ....................48 Figure 16 – Transfer time for binary signal with conventional output and input relays ...........49 Figure 17 - Definition of transfer time t for binary signals in case of line protection ...............49 Figure 18 - Definition of transfer time t over serial link in case of line protection ...................50 Figure 19 – Basic SS to SS communication structure...........................................................59 Figure 20 – SS to SS communication via tunnel...................................................................60 Figure 21 – SS to SS Communication via Proxy gateway .....................................................62 Figure 22 – Allocation of the LN RTPC representing the communication channel and the LNs providing the data to be exchanged between substations ........................................63 Figure 23 – Protection application example for permissive underreach distance teleprotection scheme and appropriate logical node modelling .............................................65 Figure 24 – Communication system based on current system ..............................................67 Figure 25 – Communication system based on future system ................................................67 Figure 26 – Proposed 2-terminal current differential feeder protection relay model ...............68 Figure 27 – Proposed 3-terminal current differential feeder protection relay model ...............68 Figure 28 – SCD files and SED region for SS-to-SS communication .....................................71 Figure 29 – Enhanced engineering process .........................................................................72 Figure 30 – IED states when exchanging SED files ..............................................................74 Figure 31 – Proxy gateway method (AA1F3, AA2F3 are Proxy gateways) .............................82 Table 1– Grouping of protection and control interfaces ........................................................46 Table 2 – Protection functions using substation-substation communication...........................47 Table 3 – Control functions using substation-substation communication ...............................48 Table 4 – Change of transfer time and synchronisation method............................................53 Table 5 – Performance classes for time tagging of events....................................................54 Table 6 – Time performance classes for instrument transformer synchronisation ..................54 Table 7 – The bit error rate as indication for communication quality .....................................54 Table 8 – Logical node RTPC..............................................................................................64 Table 9 – Logical node PSCH .............................................................................................66 Table 10 - Logical node RMXU............................................................................................69 Table 11 - Sampled value (SV) format definition ..................................................................70 Table 12 – IED engineering control types ............................................................................73

61850-90-1/DTR © IEC(E) – 5 –

INTERNATIONAL ELECTROTECHNICAL COMMISSION

____________

USE OF IEC 61850 FOR THE COMMUNICATION

BETWEEN SUBSTATIONS

FOREWORD

1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising all national electrotechnical committees (IEC National Committees). The object of IEC is to promote international co-operation on all questions concerning standardization in the electrical and electronic fields. To this end and in addition to other activities, IEC publishes International Standards, Technical Specifications, Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested in the subject dealt with may participate in this preparatory work. International, governmental and non-governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely with the International Organization for Standardization (ISO) in accordance with conditions determined by agreement between the two organizations.

2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international consensus of opinion on the relevant subjects since each technical committee has representation from all interested IEC National Committees.

3) IEC Publications have the form of recommendations for international use and are accepted by IEC National Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any misinterpretation by any end user.

4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications transparently to the maximum extent possible in their national and regional publications. Any divergence between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in the latter.

5) IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any equipment declared to be in conformity with an IEC Publication.

6) All users should ensure that they have the latest edition of this publication.

7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and members of its technical committees and IEC National Committees for any personal injury, property damage or other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC Publications.

8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is indispensable for the correct application of this publication.

9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of patent rights. IEC shall not be held responsible for identifying any or all such patent rights.

The main task of IEC technical committees is to prepare International Standards. However, a technical committee may propose the publication of a technical report when it has collected data of a different kind from that which is normally published as an International Standard, for example "state of the art".

IEC 61850, which is a technical report, has been prepared by IEC technical committee 57: Power systems management and associated information exchange.

The text of this technical report is based on the following documents:

Enquiry draft Report on voting

57/XX/DTR 57/992/DTR

Full information on the voting for the approval of this technical report can be found in the report on voting indicated in the above table.

This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.

– 6 – 61850-90-1/DTR © IEC(E)

A list of all parts of the IEC 61850 series, under the general title: Communication networks and systems for power utility automation, can be found on the IEC website.

The scope of IEC 61850 is not limited anymore to substations. This is reflected in the changed title of the series. New domain specific parts have been added to the series. TC57, WG10 is currently preparing the second edition of the basic parts from IEC 61850.

The committee has decided that the contents of this publication will remain unchanged until the maintenance result date1) indicated on the IEC web site under "http://webstore.iec.ch" in the data related to the specific publication. At this date, the publication will be

• reconfirmed, • withdrawn, • replaced by a revised edition, or • amended.

——————— 1) The National Committees are requested to note that for this publication the maintenance result date is

November 2014

61850-90-1/DTR © IEC(E) – 7 –

INTRODUCTION

When IEC 61850 was prepared, it was intended for the use of information exchange between devices of a substation automation system. In the mean time, the concepts are as well used in other application domains of the power utility system. Therefore, IEC 61850 is on the way, to become the foundation for a globally standardized utility communication network.

With existing and new applications in the field of the power system operation and protection, the requirement to exchange standardized information directly between substations increases. IEC 61850 shall be the basis for this information exchange.

IEC 61850 provides the basic features to be used for that information exchange, however, some extensions to IEC 61850 may be required. This technical report provides a comprehensive overview on the different aspects that need to be considered while using IEC 61850 for information exchange between substations. Areas that require extension of specific parts of the existing IEC 61850 standard will later be incorporated in future editions of the affected part of IEC 61850.

A similar report discussing the use of IEC 61850 for communication between substations and control centres is under preparation as IEC 61850-90-2. Further, a similar report discussing the use of IEC 61850 for wide-area RAS (Remedial Action Schemes) is being contemplated; this will likely be IEC 61850-90-3.

– 8 – 61850-90-1/DTR © IEC(E)

USE OF IEC 61850 FOR THE COMMUNICATION BETWEEN SUBSTATIONS

1 Scope

This technical report provides a comprehensive overview on the different aspects that need to be considered while using IEC 61850 for information exchange between substations. In particular, this technical report:

• defines use cases that require an information exchange between substations;

• describes the communication requirements;

• gives guidelines for the communication services and communication architecture to be used;

• defines data as a prerequisite for interoperable applications;

• does not define implementations which guarantee interoperability between different IEDs;

• describes the usage and enhacements of the configuration language SCL.

2 Normative references

The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

IEC 60044, Instrument transformers

IEC 60834-1, Teleprotection equipment of power systems – Performance and testing – Part 1: Command systems, 1999-10-01

IEC 60870-4, Telecontrol equipment and systems; part 4: performance requirements, 1990-03-01

IEC 61850-2, Communication networks and systems for power utility automation – Part 2: Glossary

IEC 61850-5, Communication networks and systems for power utility automation – Part 5: Communication requirements for functions and devices models 3

IEC 61850-6, Communication networks and systems for power utility automation – Part 6: Configuration description language for communication in electrical substations related to IEDs

IEC 61850-7-2, Communication networks and systems for power utility automation – Part 7-2: Basic communication structure – Abstract communication service interface (ACSI)

IEC 61850-8-1, Communication networks and systems for power utility automation – Part 8-1: Specific Communication Service Mapping (SCSM) – Mappings to MMS (ISO 9506-1 and ISO 9506-2) and to ISO/IEC 8802-3

IEC 61850-9-2, Communication networks and systems in substations – Part 9-2: Specific Communication Service Mapping (SCSM) – Sampled values over ISO/IEC 8802-3

IEC 62053-22, Electricity metering equipment (a.c.) - Particular requirements - Part 22: Static meters for active energy (classes 0,2 S and 0,5 S), 2003-01-01

61850-90-1/DTR © IEC(E) – 9 –

IEC/TS 62351-6, Power systems management and associated information exchange - Data and communication security - Part 6: Security for IEC 61850, 2007-06-01

IEC 62439, High availability automation networks, 2008-11-01

ANSI/IEEE 1588, Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems / revision of ANSI/IEEE 1588-2002 / Approved 2008-09-10

3 Terms and definitions

For the purposes of this document, the terms and definitions given in IEC 61850-2 and IEC 61850-7-2 apply.

4 Abbreviated terms

BER Bit error ratio Bkr Circuit Breaker C/S Client / Server CE Central equipment DCB Directional comparison blocking DF Directional relay to detect forward faults EHV Extreme high voltage HV High voltage IF, I/F Interface I/F -R Interface to receive data I/F -S Interface to send data L2TP Layer 2 tunnelling protocol MV Medium voltage PDH Plesiochronous digital hierarchy PMU Phasor measurement units QA Circuit breaker QB Line disconnector QC Earthing switch QinQ 802.1Q in 802.1Q (VLAN stacking) RAS Remedial action schemes RO Overreaching distance zone RT Remote terminal Rx Receiver SDH Synchronous digital hierarchy SIPS System integrity protection scheme SONET Synchronous optical NETwork transport system SS Substation TPI Teleprotection interface Tx Transmitter VoIP Voice over IP (Internet protocol) VPN Virtual private network WAN Wide area network

NOTE Abbreviations used for the identification of the common data classes and as names of the attributes are specified in the specific clauses of this document and are not repeated here.

– 10 – 61850-90-1/DTR © IEC(E)

5 Use cases

5.1 General

For the purpose of communication between substations, the following functions are considered.

Conventional CTs and VTs are assumed for input to relays in the following use cases. However, they could be replaced by newer technology, such as digital input based on process bus, without any significant change in the descriptions.

5.2 Distance line protection with permissive overreach tele-protection scheme Summary:

When a distance relay detects a forward fault in the overreach zone, it sends a permissive signal to the remote end, see Figure 1. If that relay also receives a permissive signal (from the remote end), the relay sends a trip signal to the local CB.

Figure 1 – Distance line protection with permissive overreach tele-protection scheme [1]

Constraints / Assumptions / Design considerations:

The permissive signal needs a minimum of 1 bit. If it is a phase segregated signal it needs 3 bits. If it is a phase segregated, and phase-to-phase and phase-to-earth are independent, the signal needs 6 bits. Directional earth fault detection may need another 1 bit.

Data is sent only when a forward fault is detected For communication channel failure alternative actions must be considered For fast tripping the propagation delay shall be small (e.g.: less than 5ms) A high reliability is needed (e.g. BER less than 10-6, Alternative route, Duplicated)

61850-90-1/DTR © IEC(E) – 11 –

Use case diagram:

Actor(s):

Name Role description Measuring equipment Measures current and voltage from protected line Comm. I/F –S Receives data from the local relay and sends the

data to the remote end Comm. I/F -R Receives data from the remote end and gives the

data to the local relay CB Disconnects the protected line from other system

(Circuit Breaker) Use case(s):

Name Services or information provided Data sampling and filtering Samples current and voltage data from measuring

equipment and filters them Data sending Calculates a distance to the fault using filtered data.

When a distance protection detects a forward fault the distance protection sends the permissive signal to Comm. I/F –S (the remote end).

Data receiving Receives the permissive signal from Comm. I/F –R (the remote end).

Relay decision When the distance protection detects the forward faults and receives permissive signal from remote end, the distance protection issues a trip command to the CB

Basic flow: Data sampling and filtering

Use Case Step Description Step 1 Current and Voltage are given to Distance protection by

Measuring equipment Step 2 Distance Protection samples an analogue value and converts it

to digital data Step 3 Distance Protection removes any unwanted frequency

components from the sampled data using a digital filter

Comm. I/F -S

Trip

Data samplingand filtering

Comm. I/F -R

Measuring equipment

(CT/VT)

CB

Relay decision

Data sending

Data receiving

V、I Sending

Receiving

Distance line Protection with permissive tele-protection scheme

– 12 – 61850-90-1/DTR © IEC(E)

Data sending

Use Case Step Description Step 1 Distance Protection stores the filtered instantaneous data Step 2 Distance Protection calculates a distance to the fault using

filtered data. Step 3 When a distance protection detects a forward fault to a pre-

determined distance, a distance protection sends the permissive signal to Comm. I/F –S (in order to send the data to a remote end relay)

Step 4 Comm. I/F –S send the information to remote end Data receiving

Use Case Step Description Step 1 Comm. I/F –R receives the data from the remote end Step 2 Comm. I/F –R gives the received data to Distance Protection Step 3 Distance Protection receives the data

Relay Decision

Use Case Step Description Step 1 When the distance protection detects the forward faults in a

predetermined zone, and receives a permissive signal from the remote end, the distance protection issues a trip command to the CB

Exceptions / Alternate flow:

N.A.

Pre-conditions: N.A.

Post-conditions:

N.A. References:

[1] Protection Using Telecommunication

61850-90-1/DTR © IEC(E) – 13 –

5.3 Distance line protection with blocking tele-protection scheme Summary:

When a distance relay detects reverse faults, it sends a blocking signal to the remote end. If the relay detects a forward fault and does not receive the blocking signal the relay sends a trip signal to the local CB, see Figure 2. A variant is the Directional Comparison Blocking (DCB) may use a non-directional element to send a blocking signal for any fault (other wording: “starts the carrier”). The operation of the forward element removes the blocking signal (“stops the carrier”) and sends a trip signal to the local CB.

Figure 2 – Distance line protection with blocking tele-protection scheme [1]


The blocking signal is a minimum of 1 bit. If it is phase segregated signal it needs 3 bits. If it is phase segregated, and phase-to-phase and phase-to-earth are independent, the signal needs 6 bits. Directional earth fault detection may need another 1 bit.

Data is sent when a reverse fault is detected or as a variant, when any fault is detected. In that variant the blocking signal is removed when the fault direction is detected as forward.

For communication channel failure the blocking signal is typically removed For fast tripping the propagation delay shall be small (e.g.: less than 5ms) A high reliability is needed (e.g. BER less than 10-6, Alternative route, Duplicated)

– 14 – 61850-90-1/DTR © IEC(E)

Use case diagram:

Actor(s):

Name Role description Measuring equipment Measures current and voltage from the protected

line Comm. I/F -S Receives data from the local relay and sends the


data to the local relay CB Disconnects the protected line from the other

system (Circuit Breaker) Use case(s):

Name Services or information provided Data sampling and filtering Samples current and voltage data from the

Measuring equipment and filters them Data sending Calculates a distance to the fault using filtered data.

When a distance protection detects a reverse fault the distance protection sends the blocking signal to Comm. I/F –S (the remote end).

Data receiving Receives the blocking signal from Comm. I/F –R (the remote end).

Relay decision When the distance protection detects the forward faults, and does not receive a blocking signal from the remote end, the distance protection issues a trip command to the CB


Use Case Step Description Step 1 Current and Voltage are given to Distance protection by the

Measuring equipment Step 2 Distance Protection samples an Analogue value, and converts

it to digital data Step 3 Distance Protection removes the unwanted frequency

component from the sampled data using a digital filter

Comm. I/F -S

Trip


Comm. I/F -R

Measuring equipment

(CT/VT)

CB

Relay decision

Data sending

Data receiving

V、I Sending

Receiving

Distance line Protection with blocking tele-protection scheme

61850-90-1/DTR © IEC(E) – 15 –

Data sending Use Case Step Description Step 1 Distance Protection stores the filtered instantaneous data Step 2 Distance Protection calculates a distance to the fault using

filtered data. Step 3 When a distance protection detects a reverse fault in a pre-

determined distance, it sends a blocking signal to Comm. I/F –S (in order to send the data to a remote end relay)

Step 4 Comm. I/F –S sends the information to remote end Data receiving

Relay Decision

Use Case Step Description Step 1 When the distance protection detects a forward fault in a

predetermined zone, and does not receive a blocking signal from the remote end, the distance protection issues a trip command to the CB


N.A.


Post-conditions:

N.A. References:


– 16 – 61850-90-1/DTR © IEC(E)

5.4 Directional comparison protection Summary:

When a directional relay (typically a directional overcurrent relay) detects a forward fault, the relay sends a permissive signal to the remote end. If the relay also receives a permissive signal from the remote end, the relay sends a trip signal to the local CB.

Figure 3 – Directional comparison with permissive scheme [1]


The permissive signal is a minimum of 1 bit. If it is phase segregated the signal needs 3 bits. If it is phase segregated and phase-to-phase and phase-to-earth are independent, the signal needs 6 bits. Directional earth fault detection may need another 1 bit.

Data is sent only when a forward fault is detected For communication channel failure alternative actions must be considered For fast tripping the propagation delay shall be small (e.g.: less than 5ms) A high reliability is needed (e.g. BER less than 10-6, Alternative route, Duplicated)

Use case diagram:

Comm. I/F -S

Trip


Comm. I/F -R

Measuring equipment

(CT/VT)

CB

Relay decision

Data sending

Data receiving

V、I Sending

Receiving

Directional relay with permissivescheme

61850-90-1/DTR © IEC(E) – 17 –

Actor(s): Name Role description Measuring equipment Measures current and voltage from a protected line Comm. I/F -S Receives data from the local relay and sends the


data to the local relay CB Disconnects the protected line from another system



Measuring equipment, and filters them Data sending Calculates the direction of the fault. When a

directional relay detects a forward fault the relay sends a permissive signal to Comm. I/F –S (the remote end).

Data receiving Receives the permissive signal from Comm. I/F –R (the remote end).

Relay decision When the directional relay detects a forward fault and receives a permissive signal from remote end, the directional relay issues a trip command to the CB.


Use Case Step Description Step 1 Current and Voltage are given to directional relay by the

Measuring equipment Step 2 Directional relay samples an Analogue value and converts it to

digital data Step 3 Directional relay removes the unwanted frequency components

from the sampled data using a digital filter Data sending

Use Case Step Description Step 1 Directional relay stores the filtered instantaneous data Step 2 Directional relay calculates a direction of the fault using filtered

data. Step 3 When a directional relay detects a forward fault, the relay

sends the permissive signal to Comm. I/F –S (in order to send the data to the remote end relay)

Step 4 Comm. I/F –S sends the information to remote end Data receiving

Use Case Step Description Step 1 Comm. I/F –R receives the data from the remote end Step 2 Comm. I/F –R gives the received data to the directional relay Step 3 Directional relay receives the data

Relay Decision

Use Case Step Description Step 1 When the directional relay detects a forward fault and receives

a permissive signal from the remote end, the relay issues a trip command to the CB


N.A.

– 18 – 61850-90-1/DTR © IEC(E)

Pre-conditions:

N.A. Post-conditions:

N.A. References:


5.5 Transfer/Direct tripping Summary:

Local equipment sends a trip command to the remote equipment. This function is sometimes called inter-tripping as well.

T.T Initiation

T.TTrip signal

Trip T.T

T.TTrip signal

Trip signal

Figure 4 – Transfer/Direct Tripping


The trip signal is a minimum of 1 bit. If it is phase segregated signal it is 3 bits. If the quantity of remote equipments is more than one, more bits may be needed for the signal

Data is sent only if a trip command is issued For communication channel failure alternative actions must be considered For fast tripping the propagation delay shall be small (e.g.: less than 5ms) A high reliability is needed (e.g. BER less than 10-6, Alternative route, Duplicated)

Use case diagram:

Comm. I/F -S

Trip

Comm. I/F -R

Commander

CB

Tripping

Data sending

Data receiving

Trip initiation

Sending

Receiving

Transfer/Direct tripping

61850-90-1/DTR © IEC(E) – 19 –

Actor(s): Name Role description Commander Requests local equipment to send a trip command

to the remote equipment Comm. I/F -S Receives data from the local relay and sends the


data to the local relay CB Disconnects the line from the other system (Circuit

Breaker) Use case(s):

Name Services or information provided Trip command issuing Issues a trip command to the local equipment

Data sending Sends the trip command to Comm. I/F –S (the remote end).

Data receiving Receives the trip command from Comm. I/F –R.

Tripping Issues the trip command to the CB

Basic flow: Trip command issuing

Use Case Step Description Step 1 Issues the trip command to local equipment Step 2 Local equipment receives the trip command

Data sending

Use Case Step Description Step 1 Local equipment sends the trip command to Comm. I/F –S (in

order to send the data to the remote equipment) Step 2 Comm. I/F –S sends the information to the remote end

Data receiving

Use Case Step Description Step 1 Comm. I/F –R gives the received command to the remote

equipment Step 2 Remote equipment receives the data

Tripping

Use Case Step Description Step 1 Remote equipment issues a trip command to the CB


N.A.


Post-conditions:

N.A. References:

N.A.

– 20 – 61850-90-1/DTR © IEC(E)

5.6 Interlocking Summary: The interlocking of the line earth switch depends on whether there is voltage on the line or not. To be able to detect this, the states of the earthing switch, and the line disconnector switch of the other line side, should be transferred and used. The method of under-voltage measurement may still be considered as back-up functionality in case of losing the communication link.

Figure 5 – Interlocking – Interoperation


Timing requirements: <= 100 ms Frequency of use: each switch state change is sent. Sizing characteristics: two switch states (maximum: all switch states of the other

side, i.e. around 10 switch states). Communication channel failure can be considered as intermediate or failed switch

state

QB1 Itl QB1 Itl

QC8 Itl QC8 Itl

QC8 Pos QC8 Pos

QB1 Pos QB1 Pos

QB1

QC8

QB1

QC8

Pos: Switch Position Itl: Interlocking logic

61850-90-1/DTR © IEC(E) – 21 –

Use case diagram:

The use case diagram applying to Process Control System is shown as a figure. Actor(s): Name Role description Switch state acquisition Switch states from line, at least earth switch and line

disconnector Comm. I/F -S Receives data from the local acquisition, and sends the data to

the remote end Comm. I/F -R Receives data from the remote end and gives the data to the

local interlocking controller Interlocking controller Uses remote switch states for local interlocking logic

Use case(s): Name Services or information provided Switch state acquisition

Acquires switch states from the line, at least the earth switch and the line disconnector

Data sending Receives data from the local acquisition, and sends the data to the remote end

Data receiving Receives data from the remote end, and gives the data to the local interlocking controller

Interlocking calculation

Uses remote switch states for local interlocking logic

Comm. I/F -S

Release or block command

Data acquisition

Comm. I/F -R

Interlocking controller

Interlocking

Data sending

Data receiving

XSWI states

Sending switch states

Receiving switch statesa

Interlocking

Switch States

Switch state acquisition

– 22 – 61850-90-1/DTR © IEC(E)

Basic flow: Use Case Step

Description Step 1 Acquires switch states from the line, at least earth the switch and the line

disconnector Step 2 Receives data from the local acquisition and sends the data to the remote end Step 3 Receives data from the remote end and gives the data to the local interlocking

controller Step 4 Uses the remote switch states for local interlocking logic Exceptions / Alternate flow: N.A. Pre-conditions: None. Post-conditions: Correct interlocking – no line disconnector closes on earthed line, no earthing switch closes on active (disconnector closed) line. References: None

61850-90-1/DTR © IEC(E) – 23 –

5.7 Multi-phase auto-reclosing application for parallel line systems Summary:

Multi-phase auto-reclosing (1-phase, 2-phase, 3phase) is a scheme that is applied to the double line circuit. In multi-phase auto-reclosing applications the scheme decides its actions based on CB status of the remote end (not usually used for other auto-reclosing methods). This use case focuses on how to use or how to transmit CB status information for multi-phase auto-reclosing. Normal auto-reclosing processes (e.g. checking dead time etc.) are omitted in the explanation.

AR ARTrip CB status

CB status

AR AR

CB status

Figure 6 – Auto-reclosing

Constraints / Assumptions / Design considerations: The CB status needs 3 bits or 6 bits Small propagation delay is preferred for quick operation (e.g.: 10 ms) A high reliability is needed For communication channel failure alternative actions must be considered

Use case diagram:

Comm. I/F -S

Trip

Tripping by protection relay

Comm. I/F -R

CB

Relay decision

Data sending

Data receiving

Trip signal Sending

Receiving

Auto-reclosing

Status

Protection

– 24 – 61850-90-1/DTR © IEC(E)

Actor(s):

Name Role description Protection relay Gives the tripping information to the auto-reclosing

scheme Comm. I/F –S Receives data from the local relay and sends the

data to the remote end Comm. I/F –R Receives data from the remote end and gives the



Name Services or information provided Tripping by protection relay Protection relay trips faulted phase, and gives that

information to the auto-reclosing scheme Local CBs in protected line and in the parallel line give their status to the auto-reclosing scheme

Data sending Sends the local CB status to Comm. I/F-S

Data receiving Receives the remote CB status from Comm. I/F –R

Relay decision If the auto-reclosing scheme decides to trip other phases, it sends a trip signal to the local CB

Basic flow: Data sending

Use Case Step Description Step 1 Auto-reclosing scheme sends the local CB status to Comm. I/F

–S (in order to send the data to the remote end relay) Auto-reclosing scheme also passes the information to the auto-reclosing scheme of the parallel line to share the information.

Step 2 Comm. I/F –S sends the information to the remote end Data receiving

Use Case Step Description Step 1 Comm. I/F –R give the received data to auto-reclosing scheme Step 2 Auto-reclosing scheme receives the data from comm. I/F-R and

from the Auto-reclosing scheme of the parallel line. Tripping by protection relay

Use Case Step Description Step 1 If a fault occurs in the protected line, a protection relay trips

the faulted phase and gives the trigger to start the auto-reclosing scheme to the auto-reclosing scheme of the protected line and of the other line located in the local substation.

Step 2 Auto-reclosing scheme receives the data Relay Decision

Use Case Step Description Step 1 By using the CB status of both ends of both lines, the auto-

reclosing scheme checks which phases are alive. The auto-reclosing scheme decides whether other phases must be tripped, or if the relay just continues to count up dead time by comparing the auto-reclosing conditions with the information of alive phases (*1).

Step 2 If the auto-reclosing scheme decides to trip other phases, it sends a trip signal to the local CB

(*1) More details are explained in the reference [1].

61850-90-1/DTR © IEC(E) – 25 –


N.A.


Post-conditions:

N.A. References: [2] K.Kasuga, Y.Sonobe “Multi-phase Autoreclose Function Installed in Line Differential Relay”, 61st Annual Georgia Tech Protective Relaying Conference, May 2-4, 2007, Atlanta, Georgia

– 26 – 61850-90-1/DTR © IEC(E)

5.8 Current differential line protection Summary:

Current differential relays measure the current of the protected line at both ends. A local relay sends the current data (IA) to the remote end and receives the current data from the remote end (IB). Current differential relays detect faults in the protected line (internal faults) by comparing the current from the remote relay with the current of the local terminal. When current differential relays detect an internal fault, they send a trip signal to the local circuit breaker.

Figure 7 – Current differential line protection [1]


Representation of measured currents and any additional information Data must be synchronised between substations (Required accuracy of

synchronisation depends on design. Typically it is considerably less than 0.1 ms, if high fault current sensitivity is required even less than 0.01 ms.)

Periodic data exchange, the frequency of data exchange depends on design philosophy. One example is 12 times per power cycle (i.e. 600 times per second for 50 Hz systems), another design operates with 4 data exchange telegrams per power cycle.

Data can be instantaneous values (sampled values), phasors or other quantities that represent the measured values

Enough data bandwidth to transmit three phase current data, additional information and, if applied, residual current data (e.g. 64 kbps)

Communication channel failure typically blocks the current line differential protection For fast tripping the propagation delay shall be small (Typically 5 ms for EHV,

10 ms to 40 ms for HV, MV), The propagation delay is negligible when direct fibre communication is applied.

A high reliability is needed (e.g. BER less than 10-6, Alternative route, Duplicated) Several types of telecommunication media may be used (i.e. ‘Telecommunication

system’ in the figure above) such as direct fibre, SDH, PDH etc. Synchronisation can be established either by using an external signal such as GPS

signal or, in applications with nearly equal delays in send an receive direction, by evaluating and considering the propagation delay during the signal exchange between the relays

61850-90-1/DTR © IEC(E) – 27 –

Use case diagram:

Actor(s):

Name Role description Measuring equipment Measures current (and voltage) from protected line Comm. I/F –S Receives data from the local relay and sends the

data to the remote end Comm. I/F –R Receives data from the remote end and gives the

data to the local relay CB Disconnects the protected line from other system


Name Services or information provided Data sampling and filtering Samples the current (and voltage) data from the

measuring equipment and filters them Data sending Stores the filtered instantaneous data. Sends the

sampled data to Comm. I/F –S (the remote end). Data receiving Receives the sampled current data from Comm. I/F

–R (the remote end). Relay decision Calculates the differential current etc. If a fault in

the protected line is detected, a trip command is issued to the CB


Use Case Step Description Step 1 Current (and Voltage, when charging current compensation is

needed) are given to the Current differential protection by the measuring equipment

Step 2 Current Differential Protection samples an analogue value and converts it to digital data

Step 3 Current Differential Protection removes the unwanted frequency components from the sampled data using a digital filter

Trip


Comm. I/F -R

Measuring equipment

(CT/VT)

CB

Relay decision

Data sending

Data receiving

V、I Sending

Receiving

Current Differential Protection (Peer to peer)

– 28 – 61850-90-1/DTR © IEC(E)

Data sending Use Case Step Description Step 1 Current Differential Protection stores the filtered instantaneous

data Step 2 Current Differential Protection puts the filtered instantaneous

data to the sending data format with other information bits Step 3 Current Differential Protection gives the sending data to

Comm. I/F –S (in order to send the data to remote end relay) Step 4 Comm. I/F –S sends the information to remote end

Data receiving

Use Case Step Description Step 1 Comm. I/F –R receives the data from the remote end Step 2 Comm. I/F –R gives the received data to the Current

Differential Protection Step 3 Current Differential Protection stores the received

instantaneous data Relay Decision

Use Case Step Description Step 1 Current Differential Protection calculates the differential

current and the restraining current, using local data and remote end data which were sampled at the same time

Step 2 Current Differential Protection judges whether a fault exists in the protected line or not by comparing the calculated value with a threshold.

Step 3 When Current Differential Protection judges that a fault exists in the protected line, Current Differential Protection issues a trip command to the local CB


N.A.

Pre-conditions: Synchronisation of the data between current differential relays must be established.

Post-conditions:

N.A. References:


61850-90-1/DTR © IEC(E) – 29 –

5.9 Phase comparison protection Summary:

When a phase comparison relay detects a positive current, above a set threshold, the relay sends an “on” signal to the remote end. The relay compares the local data signal with that from the remote end. If the time that both signals are “on” is very short, the phases of the currents detected by both ends are opposite and the relay restrained. If the time is sufficiently long the relay recognises there is an internal fault and sends a trip signal to the local CB.

Figure 8 – Phase comparison protection [1]

Figure 9 – Principle to detect internal fault by phase comparison [1]

– 30 – 61850-90-1/DTR © IEC(E)

Constraints / Assumptions / Design considerations: The “on” signal is a minimum of 1 bit. If it is a phase segregated signal it needs 3

bits. If the residual current phase comparison is an independent signal, it may need another 1 bit.

The “on” signal is sent when the detected current is positive Communication channel failure typically results in an “on” signal being delivered to

the local phase comparison function For fast tripping the propagation delay shall be small (e.g. 5 ms) A high reliability is needed (e.g. BER less than 10-6, Alternative route, Duplicated)

Use case diagram:

Actor(s):

Name Role description Measuring equipment Measures current from the protected line Comm. I/F -S Receives data from the local relay and sends the




Name Services or information provided Data sampling and filtering Samples current from the Measuring equipment,

and filters them Data sending Checks whether the current is positive or negative.

When the current is positive the phase comparison relay sends the “on” signal to Comm. I/F –S (the remote end).

Data receiving Receives the signal from Comm. I/F –R (the remote end).

Relay decision The phase comparison relay compares the local signal with the signal from the remote end. If the time that both signals are on is not long enough, the relay issues a trip command to the CB

Comm. I/F -S

Trip


Comm. I/F -R

Measuring equipment

(CT)

CB

Relay decision

Data sending

Data receiving

V、I Sending

Receiving

Phase comparison relay

61850-90-1/DTR © IEC(E) – 31 –


Use Case Step Description Step 1 Current is given to the phase comparison relay by the

Measuring equipment Step 2 The relay samples the Analogue value and converts it to digital

data Step 3 The relay removes the unwanted frequency components from

the sampled data using a digital filter Data sending

Use Case Step Description Step 1 Phase comparison relay stores the filtered instantaneous data Step 2 The relay checks whether the current is positive or negative.. Step 3 When the relay detects that the current is positive it sends the

“on” signal to Comm. I/F –S (in order to send the data to the remote end relay) and to the local time delay compensation circuit.

Step 4 Comm. I/F –S sends the information to the remote end Step 5 A local time delay compensation circuit compensates the

propagation delay according to a predetermined setting, to adjust the local data to the data from the remote end. It passes the data to the decision circuit.

Data receiving

Use Case Step Description Step 1 Comm. I/F –R receives the data from the remote end Step 2 Comm. I/F –R gives the received data to the phase comparison

relay Step 3 The phase comparison relay receives the data

Relay Decision

Use Case Step Description Step 1 The phase comparison relay compares the local signal with the

signal from the remote end. If the time that both signals are on is long enough, the relay issues a trip command to the CB


N.A.


Post-conditions:

N. A. References:


– 32 – 61850-90-1/DTR © IEC(E)

5.10 Other applications

5.10.1 General

There are other applications of which the requirement for communication is almost the same as the requirement for current differential protection. Examples of the applications are as follows.

Fault locator system (typically 2 or 3 terminals) System Integrity Protection Schemes (SIPS) Real time predictive type generator shedding Out-of-step detection Remedial Action Schemes (RAS) Synchrophasors from Phasor Measurement Units (PMUs)

The typical requirements for these applications are:

Representation of measured currents and/or voltages and any additional information Data must be synchronised between substations (e.g. less than 0,1 ms) Enough data bandwidth to transmit three phase current and/or voltage data and

additional information (e.g. 64 kbps) For communication channel failure alternative actions must be considered Propagation delay depending on the application, mostly critical e.g. 5 ms High reliability is needed (e.g. BER less than 10-6, Alternative route, Duplicated)

Details of each application are explained in the following subclauses. 5.10.2 Fault locator system (2, 3 terminals) Summary:

By using all terminal information, precise estimation of the fault location is possible. The voltages and currents of all ends are necessary.

V I V I

FL FL

HMI HMI

Result

Figure 10 – Fault locator system (2, 3 terminals)


Representation of measured currents and voltages and any additional information The propagation delay is not critical for fault locator calculation Communication channel failure may result in the fault locator calculation with data

only from the local line end Other constraints see 5.10

61850-90-1/DTR © IEC(E) – 33 –

Use case diagram:

Actor(s):

Name Role description Measuring equipment Measures current and voltage from the line Comm. I/F -S Receives data from the local relay and sends the


data to the local relay Use case(s):


Measuring equipment, and filters them Data sending Sends the sampled data to Comm. I/F –S (to the

Central computer). Data receiving and fault location calculation

Receives the sampled data from Comm. I/F –R (from the Network computing terminal).


Use Case Step Description Step 1 Currents and Voltages are given to the local terminal by the

Measuring equipment Step 2 A network computing terminal samples the Analogue values

and converts them to digital data Data sending

Use Case Step Description Step 1 When a fault occurs, the local terminal freezes the sampled

data. Typically the frozen data is measured from a few cycles before the fault until about 10 cycles after the fault

Step 2 The local terminal sends the frozen data to Comm. I/F –S (in order to send the data to the remote end)

Step 3 Comm. I/F –S sends the information to the remote end Data receiving and fault locating

Use Case Step Description Step 1 Comm. I/F –R receives the data from the remote end Step 2 Comm. I/F –R gives the received data to the local terminal Step 3 The local terminal estimates the location the fault. It shows and

stores the result.

Comm. I/F -S


Comm. I/F -R

Measuring equipment

(CT/VT) Data sending Data receiving and Fault locating

V、I Sending

Receiving

Fault locator system (2,3 terminals)

Operator

– 34 – 61850-90-1/DTR © IEC(E)


N.A.

Pre-conditions: Synchronisation of the data between the relays must be established.

Post-conditions:

N.A. References:

N.A.

5.10.3 System integrity protection schemes (SIPS) Summary:

The described system integrity protection scheme comprises remote terminal units and central equipment. Remote terminal units are located at power stations and measure voltage. These remote terminal units periodically send measured data to the central equipment. The central equipment calculates the differences of the voltage angles between the western generators and the other generator groups (northern group, eastern group and south-eastern group), and also estimates the future angle differences. If the central equipment predicts that the generators will lose synchronisation, the central equipment sends a trip signal to the circuit breaker of the tie line.

Figure 11 – Example of a System Integrity Protection Scheme


Representation of measured currents and voltages and any additional information For fast tripping the propagation delay shall be small (e.g.: less than 5ms) Communication channel failure may block the SIPS Other constraints see 5.10

C D

EB

61850-90-1/DTR © IEC(E) – 35 –

Use case diagram:

Actor(s):

Name Role description Measuring equipment Measures current and voltage from the protected

line Comm. I/F –S-RT Receives sampled data from the Remote Terminal

and sends the data to the Central Equipment Comm. I/F –R-RT Receives trip command from Comm. I/F –S-CE (the

Central Equipment) and passes the command to the Remote Terminal

Comm. I/F –R-CE Receives sampled data from Comm. I/F –S-RT (the Remote Terminal) and passes the data to the Central Equipment

Comm. I/F –S-CE Receives a trip command from the Central Equipment and sends the command to the Remote Terminal

CB Disconnects the tie line, which is connected to the western generators, with other generator groups (Circuit Breaker)

Comm. I/F –S-

Trip


Comm. I/F –R-

Measuring equipment

(CT/VT)

CB

Tripping

Data sending-RT

Data receiving-CE

V、I Sending

Receiving

System integrity protection scheme

Comm. I/F –S-

Comm. I/F –R-

Data sending-CE

Data receiving-RT

Sending

Receiving

– 36 – 61850-90-1/DTR © IEC(E)

Use case(s):


Measuring equipment and filters them Data sending-RT Sends the sampled data and information bits to

Comm. I/F –S (to the Central Equipment). Data receiving-CE Receives the sampled data and information bits

from Comm. I/F –R (from the Remote Terminal). Data sending-CE Sends the trip information from Comm. I/F –R (to

the Remote Terminal). Data receiving-RT Receives the trip information from Comm. I/F –R

(from the Central Equipment). Tripping According to the trip information from the Central

Equipment, the Central Equipment and/or Remote Terminal issues a trip command to the CB


Use Case Step Description Step 1 Voltage is given to Remote Terminals by Measuring equipment

Current is given to Central Equipment by Measuring equipment Step 2 Remote terminal and Central Terminal samples an Analogue

value and converts it to digital data Step 3 Remote terminal and Central Equipment removes the

unwanted frequency components from the sampled data, using a digital filter

Data sending -RT

Use Case Step Description Step 1 Remote terminal put the sampled voltage data to sending data

format with other information bits Step 2 Remote terminal sends the data to Comm. I/F –S-RT (in order

to send the data to Central Equipment) Step 3 Comm. I/F –S-RT sends the information to the Central

Equipment Data receiving -CE

Use Case Step Description Step 1 Comm. I/F –R receives the data from the remote end Step 2 Comm. I/F –R-CE gives the received data to the Central

Equipment Step 3 Central Equipment receives the data

Data sending -CE

Use Case Step Description Step 1 Central Equipment executes a calculation for the angle

difference prediction between the western generator group and the other generator groups

Step 2 If the Central Equipment predicts that the generators will go to out-of-step, the Central Equipment sends a trip command to the Comm. I/F –S-CE and/or the local CB

Step 3 Comm. I/F –S-CE sends the information to the Remote Terminal

61850-90-1/DTR © IEC(E) – 37 –

Data receiving-RT

Use Case Step Description Step 1 Comm. I/F –R-RT gives a trip command to the Remote

Terminal Step 2 Remote Terminal receives the data

Tripping

Use Case Step Description Step 1 If the Remote terminal B receives the trip command, it issues a

trip command to the CB Exceptions / Alternate flow:

N.A.


Post-conditions:

N.A. References:

[3] Y.Ohura, M.Suzuki, K.Yanagihashi, M.Yamaura, K.Omata, T.Nakamura, S.Mitamura, H.Watanabe, “A Predictive Out-of-Step Protection System Based On Observation Of The Phase Difference Between Substations”, IEEE Trans. PWRD, Vol.5, No.4, November 1990

– 38 – 61850-90-1/DTR © IEC(E)

5.10.4 Real time predictive generator shedding Summary:

This wide area protection system comprises Remote Terminals and Central Equipment. Remote Terminal A and B measure the voltage and current at Power Station A and B. These Remote Terminals periodically send the active power, which is calculated from the voltage and current, to the Central Equipment. Remote Terminal C sends voltage data to the central equipment. When a fault occurs, if the central equipment predicts that the generators will loose synchronisation, the central equipment sends a trip signal to the generators.

Figure 12 – Real time predictive type generator shedding system


Representation of measured currents and voltages and any additional information For fast tripping the propagation delay shall be small (e.g.: less than 5ms) For communication channel failure alternative actions must be considered Other constraints see 5.10

A B

C

61850-90-1/DTR © IEC(E) – 39 –

Use case diagram:

Actor(s):

Name Role description Measuring equipment Measures current and voltage from a protected line Comm. I/F –S-RT Receives sampled data from the Remote Terminal

and send the data to the Central Equipment Comm. I/F –R-RT Receive a trip command from the Comm. I/F –S-CE

(the Central Equipment) and passes the command to the Remote Terminal

Comm. I/F –R-CE Receives sampled data from the Comm. I/F –S-RT (the Remote Terminal) and passes the data to the Central Equipment

Comm. I/F –S-CE Receives the trip command from the Central Equipment, and sends the command to the Remote Terminal

CB Disconnects the line which is connected to a generator from the power station (Circuit Breaker)

Use case(s):


Measuring equipment, and filters them Data sending-RT Sends the sampled data and information bits to

Comm. I/F –S (to the Central Equipment). Data receiving-CE Receives the sampled data and information bits

from Comm. I/F –R (from the Remote Terminal). Data sending-CE Sends the trip information to Comm. I/F –R (to the

Remote Terminal). Data receiving-RT Receives the trip information from Comm. I/F –R

(from the Central Equipment). Tripping According to the trip information from Central

Equipment, the Remote Terminal issues a trip command to the CB

Comm. I/F –S-

Trip


Comm. I/F –R-

Measuring equipment

(CT/VT)

CB

Tripping

Data sending-RT

Data receiving-CE

V、I Sending

Receiving

Real time predictive typegenerator shedding

Comm. I/F –S-

Comm. I/F –R-

Data sending-CE

Data receiving-RT

Sending

Receiving

– 40 – 61850-90-1/DTR © IEC(E)


Use Case Step Description Step 1 Current and Voltage are given to the Remote Terminals by the

Measuring equipment Step 2 Remote terminal samples an Analogue value, and converts it to

digital data Step 3 Remote terminal removes the unwanted frequency components

from the sampled data, using a digital filter Data sending -RT

Use Case Step Description Step 1 Remote terminals A and B calculate the Power, from the

filtered current and voltage data Step 2 Remote terminal puts the electrical data (Power for Terminal A

and B, Current and Voltage for Terminal C) to sending data format, with other information bits

Step 3 Remote terminal sends the data to Comm. I/F –S-RT (in order to send the data to Central Equipment)

Step 4 Comm. I/F –S-RT sends the information to the Central Equipment

Data receiving -CE

Use Case Step Description Step 1 Comm. I/F –R receives the data from the remote end Step 2 Comm. I/F –R-CE give the received data to Central Equipment Step 3 Central Equipment receives the data

Data sending -CE

Use Case Step Description Step 1 Central Equipment executes a calculation for the generator

angle prediction Step 2 If Central Equipment predicts the generator will go to the out-

of-step, it calculate the minimum number of generators which is necessary to be shed in order to stabilise the power system

Step 3 Central Equipment sends the trip information (the number of the generator to be shed) to Comm. I/F –S-CE

Step 4 Comm. I/F –S-CE sends the information to Remote Terminal Data receiving-RT

Use Case Step Description Step 1 Comm. I/F –R-RT gives the trip information to the Remote

Terminal Step 2 Remote Terminal receives the data

Tripping

Use Case Step Description Step 1 According to the tripping information from the Central

Equipment, the Remote Terminal issues a trip command to the CB

61850-90-1/DTR © IEC(E) – 41 –

Exceptions / Alternate flow: N.A.


Post-conditions:

N.A. References:

[4] K.Matsuzawa, K.Yanagihashi, J.Tsukita, M.Sato, T.Nakamura, A.Takeuchi, “Stabilizing Control System Preventing Loss Of Synchronism From Extension And Its Actual Operating Experience”, IEEE Trans. PWRS, Vol.10, No.3, August 1995

– 42 – 61850-90-1/DTR © IEC(E)

5.10.5 Out-of-step detection Summary:

By comparing the angle of voltage between the two ends, it can be detected whether the centre of the out-of-step is between the two ends or not as shown in Figure 13. When the two voltages are in the opposite direction, an out-of-step occurs and the centre of out-of-step is in between the two ends.

V V

OST OST

Trip

Figure 13 – Out-of-step detection


Representation of measured voltages and any additional information For out-of-step detection a medium propagation delay is required (e.g.: 10 ms to

50 ms) Communication channel failure may block this kind of out-of-step detection,

alternative actions must be considered Other constraints see 5.10

Use case diagram:

Comm. I/F -S

Trip


Comm. I/F -R

Measuring equipment

(CT/VT)

CB

Relay decision

Data sending

Data receiving

V、I Sending

Receiving

Out-of-step detection

61850-90-1/DTR © IEC(E) – 43 –

Actor(s):

Name Role description Measuring equipment Measures voltage from protected line Comm. I/F -S Receives data from the local relay and sends the




Name Services or information provided Data sampling and filtering Samples voltages from the Measuring equipment,

and filters them Data sending Out-of-step detection sends the sampled voltage

data to Comm. I/F –S (the remote end). Data receiving Receives the permissive signal from Comm. I/F –R

(the remote end). Tripping If required, out-of-step detection sends a trip signal

to the local CB Basic flow: Data sampling and filtering

Use Case Step Description Step 1 Voltage is given to Out-of-step detection by Measuring

equipment Step 2 Out-of-step detection samples an Analogue value and converts

it to digital data Step 3 Out-of-step detection removes the unwanted frequency

components from the sampled data, using a digital filter Data sending

Use Case Step Description Step 1 Out-of-step detection sends the sampled voltage data to

Comm. I/F –S (in order to send the data to remote end relay) Step 2 Comm. I/F –S sends the information to the remote end

Data receiving

Use Case Step Description Step 1 Comm. I/F –R gives the received data to Out-of-step detection Step 2 Out-of-step detection receives the data

Relay Decision

Use Case Step Description Step 1 Compares the local voltage with the remote voltage and checks

the angle difference between the two voltages Step 2 When the out-of-step is detected, and if required, Out-of-step

detection issues a trip command to the local CB Exceptions / Alternate flow:

N.A.


Post-conditions:

N.A.

– 44 – 61850-90-1/DTR © IEC(E)

References:

N.A.

5.10.6 Synchrophasors Summary:

Synchrophasors are measured via Phasor Measurement Units (PMUs). These units provide synchronised measured data for a certain purpose or multiple purposes. Hence the application can vary widely. System Integrity Protection Schemes (SIPS) as described in 5.10.3, are one typical application of synchrophasors. Therefore the detail of an application is not explained here again.

5.10.7 Remedial action schemes (RAS) Summary:

Remedial Action Schemes (RAS) are designed to monitor and protect electrical systems. They perform automatic switching operations in response to adverse network conditions to ensure the integrity of the electrical system and to avoid a collapse of the network. Typical automatic remedial actions include: • Generator tripping for reduction of energy input to the system • Tripping of load, insertion of braking resistors, series capacitors, opening of

interconnecting lines and system islanding The RAS action is generally performed by a central controller. The controller needs data collected by field units. The field units are capable of measuring currents and voltages and/or transducer quantities (W, VAr) and deliver these to the central equipment for evaluation and comparison with data from other locations in the power system. The field unit also acts as a remote controller, such as performing breaker operations via programmable logic and inputs/outputs when a command is received from the central equipment.

61850-90-1/DTR © IEC(E) – 45 –

6 Communication requirements for substation-to-substation communication

NOTE This Clause 6 collects the requirements according to part IEC 61850-5 but focussed on substation-substation communication

6.1 General issues

6.1.1 Introduction

The substation-substation communication refers to functions in substation automation systems (SAS) which are either distributed between two substations (e.g. A and B) or to functions in one substation which needs information from the other one. Examples are line protection, bay interlocking with position information from the line isolators and earthing switch from the other side of the line, and any kind of automatics including more than one substation. Supporting functions are e.g. the time synchronisation between IEDs on both sides of the substation-substation link.

6.1.2 Logical allocation of functions and interfaces (5.2 in IEC 61850-5) The functions of a substation automation system may be allocated logically on three different levels (station, bay/unit, or process). These levels are shown by the logical interpretation of Figure 14 together with the logical interfaces 1 to 11.

Figure 14 – Logical interfaces between substation A and substation B

The interfaces 1, 3 to 6, and 8 to 9 are connecting functions of the substation automation system inside the substation. Interface 10 represents as TCI (telecontrol interface) the communication of the SA system to the remote control centre, interface 7 represents as TMI (telemonitoring interface) the communication to remote engineering, monitoring and maintenance places. Interface 2 represents as TPI (teleprotection interface) the protection related function between substations, interface 11 represents the same for control related functions. There is some relation between the interfaces as shown in Table 1 below.

– 46 – 61850-90-1/DTR © IEC(E)

Table 1– Grouping of protection and control interfaces

Process interfaces Bay-station interfaces Substation-substation interfaces

Protection IF 4 IF 1 IF 2

Control IF 5 IF 6 IF 11

IF1: protection-data exchange between bay and station level

IF2: protection-data exchange between substations. This interface refers both to analog data e.g. for line differential protection and binary data e.g. for line distance protection

IF3: data exchange within bay level

IF4: CT and VT instantaneous data transport (especially samples) from the process to the bay level. This comprises in the reverse direction also the protection trip

IF5: control-data exchange between process and bay level

IF6: control-data exchange between bay and station level

IF7: data exchange between substation (level) and a remote engineer’s workplace

IF8: direct data exchange between the bays especially for fast functions like interlocking

IF9: data exchange within station level

IF10: control-data exchange between the substation and remote control center(s)

IF11: control-data exchange between substations. This interfaces refers to binary data e.g. for interlocking functions or inter-substation automatics

6.1.3 The role of interfaces

The interface 2 is dedicated to communication with a remote protection device in the adjacent substation and the interface 11 is dedicated in the same way to communication with the remote control device. It should be noted that interfaces 2 and 11 may be interfaces to a communication network not according to IEC 61850. These networks are accepted if they allow tunnelling IEC 61850 messages and provide the requested performance between the functions running in IEC 61850 based SA systems on both sides.

According to the function allocation, the message types of clause 6.3 based on communication performance requirements of the application functions are assigned to the different interfaces. The free allocation of functions means that such an assignment may not be common for all substation automation systems and substation-substation links.

6.1.4 Response behaviour requirements

Since interoperability is claimed for proper running of functions, the reaction of the application in the receiving node has to be considered.

a) The reaction of the receiving node has to fit into the overall requirement of the distributed function to be performed.

b) The basic behaviour of the functions in any degraded case, i.e. in case of erroneous messages, lost data by communication interrupts, resource limitations, out of range data,

61850-90-1/DTR © IEC(E) – 47 –

etc. has to be specified. This is important if the overall task cannot be finalized successfully, e.g. if the remote node does not respond or react in a proper way.

c) The external communication system has to fit into the overall requirements of the distributed function to be performed.

These requirements are function related local issues and, therefore, outside the scope of this communication standard. But the requirement left for this standard is the provision of quality attributes to be transferred with the data under consideration.

6.2 Functions based on substation-substation communication

The following functions need substation-substation communication. More detailed modelling including the communication interfaces is given in Clause 9.

6.2.1 Protection functions

Table 2 – Protection functions using substation-substation communication

Function 61850 IEEE Description or Comments

Distance protection PDIS, PSCH

21 Distance relay is a relay that functions when the circuit admittance, impedance, or reactance increases or decreases beyond a predetermined value

The change of the impedance seen by PDIS is caused by a fault. The impedance characteristic is a closed line set in the complex impedance plane. – The reach of the distance protection is normally split into different zones (e.g. 1…4 forward and 1 backward) represented by dedicated characteristics.

Differential protection PDIF, RMXU

87 Differential protective relay is a protective relay that functions on a percentage or phase angle or other quantitative difference of two currents or some other electrical quantities

Phase comparison protection PDIF, RMXU

87P See above (PDIF/87)

Differential line protection (1) PDIF, RMXU

87L See above (PDIF/87)

– 48 – 61850-90-1/DTR © IEC(E)

6.2.2 Control functions

Table 3 – Control functions using substation-substation communication

Function 61850 Description or Comments

Interlocking function at station and/or bay level

CILO Interlocking may be totally centralized or totally decentralized. Since the interlocking rules are basically the same on bay and station level and based on all related position indications the different interlocking LNs may be seen as instances of the same LN class Interlocking (IL).

1) Interlocking of switchgear at bay level

All interlocking rules referring to a bay are included in this LN. Releases or blockings of requested commands are issued. In case of status changes affecting interlocking blocking commands are issued.

2) Interlocking of switchgear at station level

All interlocking rules referring to the station are included in this LN. Releases or blockings of requested commands are issued. Information with the LN bay interlocking is exchanged

6.3 Message performance requirements

6.3.1 Transfer time definition (13.4 in IEC 61850-5) If not mentioned explicitly, the transfer time is specified from the user or application point of view. This means that the transfer time is the time from the sending application to the receiving one i.e. the complete transmission of a message including the necessary coding and decoding including the media access at both ends (Figure 15). In the physical device PD1, an Application Function 1 sends data to another Application Function 2 located in physical device PD2. The time counts from the moment the sender puts the data content on top of its transmission stack up to the moment the receiver extracts the data from its receiver stack. The overall transfer time t will however consist of the individual times for coding (ta) and decoding (tc) with or without dedicated communication processors and the pure network transfer time tb.

Figure 15 – Transfer time for binary and other signals over a serial connection

For binary signals conventional output and input relays replace the coding and decoding (Figure 16). These output and input relays have response times of around 10 ms.

61850-90-1/DTR © IEC(E) – 49 –

Figure 16 – Transfer time for binary signal with conventional output and input relays

If there is only one direct link the time tb is for distances in substations and in power systems negligible referring to the speed of light.

If there are active components in the communication path like routers, switches or other ones the processing times of these elements contribute reasonable to the network transfer time tb. If collisions or losses have to be compensated e.g. by repetitions also theses times contribute. Any testing and verification of the transfer time must be performed during the site acceptance testing, since the physical devices and network equipment might be supplied from different manufacturers.

Figure 17 - Definition of transfer time t for binary signals in case of line protection

Application Function 1

Physical device PD1

Transfer time t = ta + tb1 + ta1 + tb0 + tc2 + tb2 + tc

ta tb0 tc

ApplicationFunction 2

Physical device PD2

Gate-way

Cod Dec

Wide Area Comm. System

tb1 ta1 tb2tc2

Gate-way Output/Input

relays Output/Input

relays

Application Function 1

Physical device

PD1

Transfer time t = ta + tb + tc

ta tb tc

Physical link (wire circuit) ApplicationFunction 2

Physical device

PD2 Output relay Input relay or

optocoupler

http://dict.leo.org/ende?lp=ende&p=thMx..&search=negligible

– 50 – 61850-90-1/DTR © IEC(E)

This is valid also for links beyond the substation boundary where the time delay in the interconnecting network is also part of tb. In Figure 17 and Figure 18 some dedicated times contributing to tb are shown. Relay times (Figure 17) are replaced by coding and decoding times (Figure 18). In case of full serial communication (Figure 18) Coding and Decoding for the Wide Area Communication System (Gateway in Figure 17) are replaced by Recoding for the Local Area Communication.

Figure 18 - Definition of transfer time t over serial link in case of line protection

The teleprotection operating time tA in Figure 6 of IEC 60834-1 is defined in nearly the same way as the transfer time t in this document.

All requirements reflect the needs of the application function and, therefore, are valid in any case under normal conditions without disturbed communication links.

Disturbances may need a logical reconnection of the communication link, repetition of messages or other means delaying the transfer time. This behavior is a matter of the services defined in the part IEC 61850-7-2 and of the implementation within the IEDs. Any possible delay has to be defined and considered for the transfer time. If the resulting transfer times are acceptable is a project specific question.

6.4 The introduction and use of message performance classes

6.4.1 General To allow for different requirements of the functions in and between substations, the requirements for the message types may be divided in Performance Classes. There are two basic groups of performance classes, one for control and protection applications (main criterion is the transfer times) and another one for metering and power quality applications (main criterion is the accuracy requirement). Since the performance classes are defined according to the requirements of the functions to be performed, they are independent from the size of the substation and basically form the voltage level. Raw analogue data both for voltage and current are transmitted over serial links as samples, mostly as synchronized

61850-90-1/DTR © IEC(E) – 51 –

stream of samples. To not delay any dependant actions, like necessary protection trips for these messages, not only the accuracy and sample rate are important but also the transfer time. Not all communication links in and between substations need to support the same message performance classes. But because of the free allocation of functions there is not a given allocation of message performance classes. Nearly all links may have to support all such classes. Therefore, all supported classes or at least the most demanding class shall be part of the IED specification.

It is a matter of implementation if all messages are sent with basically according to the highest performance class requested at one link. To respond also in this case to different requirements the support of priorities is requested.

The typical use of the performance classes is indicated below but it may be overwritten by dedicated function requirements or customer specifications.

6.4.2 Control and protection

The requirements for the transfer time i.e. the communication performance are basically the same in one bay, between bays and also between substations. Therefore, the same classification scheme shall be used for all links compliant with IEC 61850.

Some classes may be not applicable for all application areas. The use of an intermediate WAN not compliant with IEC 61850 may result in higher transfer times.

As mentioned above the requirements for the transfer time are independent from the voltage level. The fault clearance time tC as specified e.g. in Figure 2 of IEC 60834-1 is the time between fault inception and fault clearance. If at distribution level longer fault clearance times are accepted than at transmission level, then these times are related both to slower algorithms and less powerful breakers. But these times are not based on less demanding transfer times.

6.4.2.1 Types of message performances classes

6.4.2.1.1 Type 1 – High speed messages

This type of message typically contains simple binary information like a short command or a simple message like "Trip", "Close", “Reclose order”, "Start", "Stop", "Block", "Unblock", “Trigger”, “Release”, “State change”, maybe also “State” for some functions. This message type is mission critical for the performance of the supported function. The receiving IED shall act immediately in some way by the related function on receipt of this type of message.

6.4.2.1.1.1 Type 1A “Trip”

The “trip” is the most important fast binary message in the substation. Between substations “block” and “release” may be same as important. Therefore, this message has more demanding requirements compared to all other fast messages. Same performance may be requested for interlocking, intertrips (direct trips) and logic discrimination between protection functions.

d) For “trips” within the substation and within one bay transfer times not exceeding 4 ms shall be supported.

e) For “trips” within the substation between bays transfer times not exceeding 10 ms shall be supported but also transfer times not exceeding 4 ms may be requested.

f) For “trips” to the neighboring substation (e.g. for line protection) a whole set of transfer times for the message performance classes shall be supported according to the transfer time requirements defined in line with IEC 60834-1 which shall not be exceeded depending on the functional requirements which have to be supported by the communication system applied:

– 52 – 61850-90-1/DTR © IEC(E)

TR1 ≤ 4 ms TR2 ≤ 10 ms TR3 ≤ 15 ms TR4 ≤ 20 ms TR5 > 20 ms NOTE In IEC 60834-1 only 10 ms are defined for digital networks

6.4.2.1.1.2 Type 1B “Automation”

All other fast messages are important for automation functions between IEDs and for the interaction of the IEDs with the process but have less demanding requirements compared to the type “Trip”.

a) For fast state based applications the transfer time shall not exceed 20 ms in line with TR4 above

b) For normal state based applications the transfer time shall not exceed 100 ms in line with TR5 (> 20 ms) above but having 100 ms as upper limit

Therefore, these types of messages performance classes are valid inside the substation and also for messages between substations.

6.4.2.1.2 Type 3 – Low speed messages

Based on the response time of an operator (> 1 s) only low speed message performance classes are needed for the communication from the process and bay level to the operator. These messages shall not exceed 500 ms. This type refers to more complex messages for commands and reports like station level data base update, update of the single line display at the screen, for the update of alarm and event lists, and also for all operator commands. Such a performance message class is not applicable for functions based on substation-substation communication.

The same is valid for file transfers which may exceed 1 000 ms depending on the size.

6.4.3 Metering and power quality

6.4.3.1 Types of message performances classes

The performance class M1 refers to revenue metering with accuracy class 0.5 (IEC 62053-22) and 0.2 (IEC 60044) and up to the 5th harmonic.

The performance class M2 refers to revenue metering with accuracy class 0.2 (IEC 62053-22) and 0.1 (IEC 60044) and up to the 13th harmonic.

The performance class M3 refers to quality metering (power quality) up to the 40th harmonic.

6.4.3.2 Raw data messages

6.4.3.2.1 General requirements for raw data

This message type includes the output data from digitizing transducers and digital instrument transformers independently from the transducer technology (magnetic, optic, etc.). The samples of current and voltage values need to be transferred from the transducer to the processing unit i.e. typically to the protection IED. The line differential protection needs this data also across the line i.e. from one side to the other side. To avoid any delay of protection caused by a delay of samples the transfer time has to be according to the classes for the high speed messages as stated in 6.4.2.1.1 above. The difference to the binary messages is that these data consist not only of singular messages but of a continuous stream of synchronized samples from the source (sending IED).

61850-90-1/DTR © IEC(E) – 53 –

Regarding phasors which are used by some functions alternatively to samples the performance requirements regarding transfer time are the same. The difference is that the amount of data or messages in the data stream is lower compared to samples since phasors use for the angle definition normally more than one sample. .

If the current and voltage values are transferred as analogue values over wires to the protection their transfer time is the same for all voltage levels. The protection shall not be delayed by the data communication. Different transfer times if applicable have to be classified according to the classes for the high speed messages as stated in 6.4.2.1.1 above.

Analogue data have besides the transfer time additional features as amplitude resolution and sampling rate. The required transfer time for protection and control is: 4.0 ms acc. to Type 1A “Trip”. For digital communication beyond the substation also transfer times ≤ 10 ms may be accepted according to the message performance class TR2. For other communication systems also the less demanding classes TR3, TR4, etc. may be specified as long as the application function is able to work with these higher transfer times. 6.4.3.2.2 Additional requirements for time synchronisation for line differential

protection For comparing samples or phasors acquired at different places in different IEDs requires a synchronisation of these samples in μs range. The related classes are given in 6.4.3.4. This might also be a problem inside one substation which today is used with a pulse per second (pps) and in future over the IEC 61850 connections with IEEE 1588.

Table 4 – Change of transfer time and synchronisation method

Class Acceptable change of transfer time (ΔTA) Applicable synchronisation method

TT1 0.2 ms External signal synchronisation or self synchronisation (self synchronisation is outside scope of IEC 61850 because this method is not standardised)

TT2 10 ms External signal synchronisation

TT3 20 ms External signal synchronisation

The asymmetry of the communication path concering transfer time between the IEDs on both sides of the line works similarly like the changes in transfer time and set some additional limits for self-synchronisation as specified as class TT1 in Table 4. If the asymmetry in the transfer times exceeds the acceptable change of class TT1 (0.2 ms) external synchronisation has to be applied. 6.4.3.3 Type 5 – File transfer functions

Not applicable for functions based on substation-substation communication

6.4.3.4 Type 6 – Time synchronisation messages

6.4.3.4.1 General Between substations the synchronisation takes place without dedicated time synchronisation messages as explained in 6.4.3.2.2. Nevertheless, the classes for time synchronisation according to part IEC 61850-5 may be used if applicable.

– 54 – 61850-90-1/DTR © IEC(E)

6.4.3.4.2 Standard IED synchronizing for control and protection events

Table 5 – Performance classes for time tagging of events

Time Perf. Class Accuracy [ms] Purpose

T1 ± 1 Time tagging of events

T2 ± 0,1 Time tagging of zero crossings and of data for the distributed synchrocheck. Time tags to support point on wave switching.

6.4.3.4.3 Standard IED synchronizing for instrument transformers

For instrument transfomers the time performance classes according to Table 6 are applicable.

Table 6 – Time performance classes for instrument transformer synchronisation

Time Perf. Class Accuracy [μs]

T3 ± 25

T4 ± 4

T5 ± 1

6.4.3.5 Type 7 – Command messages with access control

Not applicable for functions based on substation-substation communication

6.5 General requirements for data integrity

Integrity means that for given conditions of the communication link (e.g. signal to noise ratio for analogue links equivalent to the BER (Bit Error Rate) for digital links) the resulting errors are below a certain acceptable limit. In part IEC 61850-3, the three integrity classes according to IEC 60870-4 are referenced. Integrity was also introduced as PICOM attribute in clause 10.1.2 of IEC 61850-5, 1st edition 2003. All safety related messages like commands and trips with direct impact on the process shall have the highest integrity class, i.e class 3. All other messages may be transmitted with a lower data integrity but not lower then class 2.

According to the Cigre report Protection using Telecommunications [1] the accepted BER is as shown in the table below.

Table 7 – The bit error rate as indication for communication quality

Protection type – communicated data Condition Limit for accepted BER

Distance protection – binary data Normal 10-5

Distance protection – binary data Fault 10-4

Differential protection – analog data Normal 10-6

Differential protection – analog data Fault 10-5

Normally, the noise level is given and cannot be influenced. Nevertheless, to reach integrity three groups of known measures exist to limit its impact.

a) Proper design of devices and the communication system, e.g. protecting enclosures and the use of fibre optic links to minimize the impact of noise on the communication system

b) Apply an appropriate coding of telegrams to achieve the desired residual error rate c) Use of at least two step sequences like select-before-operate (SBO) for commands

61850-90-1/DTR © IEC(E) – 55 –

The measures are outside the scope of part 5 but the required data integrity should be considered in modelling the services (IEC 61850-7-2, e.g. SBO) and defining the mapping (IEC 61850-8-x, 61850-9-x, e.g. coding).

6.6 Requirements for teleprotection

6.6.1 Reliability (security and dependability)

6.6.1.1 General

For the various protection schemes, the Cigre report Protection using Telecommunications [1] addresses the requirements from protection on the teleprotection interfaces and the communication channels. The term “teleprotection” refers either to the line protection as such or to the equipment needed to interface the protection equipment to the telecommunication network. This subclause will focus on delivering protection traffic with the required Security and Dependability.

6.6.1.2 Security requirements for protection schemes according to Cigre and IEC

“Security” S means the security against “unwanted commands” i.e. unwanted trips of protection if these are not requested by the protection scheme in the actual situation. If the probability for unwanted commands is Puc then the security is defined as

S = 1 – Puc

The “Security” requirements for protection schemes with telecommunications are declared in Tables 6-1-1 and 6-1-2 of the Cigre report Protection using Telecommunications [1] as “medium” to “high” with a reference to IEC 60834-1. The IEC Figure 21 “Performance guidance figures for various teleprotection schemes” in 60834-1 shows that Puc should be less than 10-4 for blocking schemes down to 10-8 for inter-tripping schemes.

Therefore the complete communication path including the protection application in the tripping IED shall allow for Puc of lower than 10-8 to be usable for inter-tripping protection schemes. The split between the different contributing parts is a matter of modelling and functions allocation.

6.6.1.3 Dependability requirements for protection schemes according to Cigre and IEC

“Dependability” D means the dependability against “missing commands” i.e. for protection missing trips if these are requested from the protection scheme in the actual situation. If the probability for missing commands is Pmc then the dependability is defined as

D = 1 – Pmc

The “Dependability” requirements for protection schemes with telecommunications are declared in Tables 6-1-1 and 6-1-2 of the Cigre report Protection using Telecommunications [1] as “medium” to “high” with a reference to IEC 60834-1. The IEC 60834-1 Figure 21 shows that Pmc should be less than 10-2 for permissive under-reach schemes down to 10-4 for inter-tripping schemes. Figure 21 shows also that the “maximum actual transmission time” should be < 10ms for all the protection schemes (see also 6.4.2.1.1.1 and 6.4.3.2.2 above).

Therefore the complete communication path including the protection application in the tripping IED shall allow for >10 ms message-latency probability of lower than 10-4 to be usable for inter-tripping protection schemes. The split between the different contributing parts is a matter of modelling and functions allocation.

– 56 – 61850-90-1/DTR © IEC(E)

7 Considerations on security and dependability issues when using Ethernet networks

7.1 General

This clause highlights the specific issues of Ethernet networks, and provides solutions so substation networks can be engineered to guarantee the security and dependability required by applications for communication between substations.

7.2 Security of traffic

The 32-bit CRC field at the end of each Ethernet packet provides an “unwanted command” probability, from an error, of < 10-9 (meeting the IEC 60834-1 < 10-8).

Of more concern are attempts at sabotage through the injection of rogue Ethernet packets into the network. Breaking security from external needs some external access point to the communication system. The measures to be taken depend on the externally available access points to the communication system. If e.g. a power line carrier based WAN communication is used, access to the power line should be secure enough. If additionally the coupling into the substation communication level is physically secured, no externally available access points exist and no additional measures are needed. If however the coupling point between the WAN lines and the substation internal communication network is externally accessible, then security measures for authentication as described in IEC 62351-6 are needed. As long as any other traffic as GOOSE and SMV is disabled at the entry port, no other measures are needed.

Two technologies are considered to restrict the access to the network either completely or to trusted partners:

(a) VLANs The IEEE 802.1Q standard adds a 4-byte “tag” to the headers of Ethernet packets in order to provide a 12-bit VLAN-ID (“VID”) and a 3-bit priority level for each packet. Ethernet switches supporting VLANs can be configured for which VLANs it will accept on each port. So by assigning a VID used for protection only to those ports connected to the protection IEDs guarantees that not the whole substation network can be flooded with packets from this port.

(b) Authentication Security technologies are available that can “authenticate” the source of a received packet (ref. to IEC62351-6). This does not help against flooding, but assures that only messages from trusted partners are accepted and processed. Though the complex processing of the authentification is a challenge for time-critical messages, the main implementation issue is the “key management” required to maintain the expected security. As an example, a frequent security requirement is to be able to replace all the keys within a few hours of a security breach; a hierarchical approach to key management reduces truck rolls, but adds complexity.

Since VLANs provide other benefits (see later), their use for reducing the flooding problem is recommended in any case.

7.3 Dependability of traffic

As noted above, IEC 60834-1 specifies that the probability of a “command” not being received within 10 ms should be <10-4.

For an Ethernet network, the reasons for a packet not being received within 10 ms comprise:

(a) Congestion Whenever two or more Ethernet packets compete for a network path, such as to egress the port of a switch, one of them must wait in a “queue”.

61850-90-1/DTR © IEC(E) – 57 –

If for some duration the arriving packets exceed a port’s capacity, the queue depth increases, and eventually packets may be discarded. For networks transporting different classes of traffic with different degrees of priority, the use of switches with several priority-dependent queues at each egress port will improve the latencies of the higher-priority traffic (assuming the packets have IEEE 802.1Q/p “tags” with the correct priority values). Note that though these tags support 8 priority levels, most switches provide only 4 or 2 priority level queues.

(b) Fibre Failure During a fibre failure redundant networks like rings need to reconfigure. Typical recovery times are: SONET < 60 ms, SDH < 50 ms, Ethernet Spanning Tree about 1 minute, and Ethernet Rapid Spanning Tree tens of milliseconds to a few seconds. As long as this kind of event happens with lower probability than 10-4, it can be accepted, else other architectures can be used, like PRP from IEC 62439, or other solutions with faster recovery times.

7.4 Avoiding GOOSE packets flooding the WAN

GOOSE messages and sampled value messages are typically sent as multicast. These multicast messages are distributed by switches within the whole Ethernet segment, if their flow is not restricted. The most common means to configure flow restrictions is to configure VLANs (VIDs) between all IEDs which need a certain message or belong to a certain application working with this kind of messages. Another possibility is to use MAC level filtering, but this may be more difficult to set up in a WAN environment.

In the case that there is a direct Ethernet connection between substations, or the substation – substation messages are tunnelled between the substations, using different VIDs for substation internal traffic and substation – substation traffic is a common means to avoid this, even if this might mean that some data objects are sent in two different messages from the same IED.

7.5 Summary on recommendations for using Ethernet for communication between substations

7.5.1 General

This clause uses the telecom terms “drop” for the equipment ports connecting to the traffic sources (e.g. for VF, data, video etc.), and “line” for the equipment ports connecting the networks’ nodes (typically fibre connections).

The requirements for the Ethernet Telecommunications network are as follows:

a) If some of the Ethernet Telecommunications network equipment is outside the utility’s

“Security Perimeter” (e.g. when Ethernet circuits are leased from a service provider), the Ethernet links through such equipment should be secured through a technology such as “L2TP” (Layer 2 Tunnelling Protocol) to create a “VPN” (Virtual Private Network), and the security should be maintained through the implementation of the associated key-management requirements. Note that this technology provides authentication of each message’s source (encryption is not required for protection applications, and may significantly increase the messages latencies).

b) Unless dual-port IEC 61850 IEDs are used with physically separate paths, the Ethernet network should recover (restore traffic) from a fibre failure within 10ms.

c) All the network switches’ “drop” ports connected to IEC 61850 IEDs should be configured for memberships only in the VLANs supported by the connected IEDs.

d) Such connections should be monitored to detect momentary link loss events; this allows the detection of malicious attempts to use such ports to access other IEDs on the critical VLANs.

– 58 – 61850-90-1/DTR © IEC(E)

e) All the network switches’ “drop” ports connected to other services (e.g. Video, Corporate, VoIP, 3rd-party WANs) shall be configured to block ingressing traffic with VIDs for the critical VLANS, and to prevent ingressing traffic using the network’s priority queues handling the GOOSE protection traffic (e.g. by controlling the priority fields of the ingressing packets’ IEEE 802.1Q tags).

f) The probability of a GOOSE packet taking more than 10ms to traverse the network should be constrained to < 10-4; by limiting the number of switches on the longest path, and by limiting the traffic loading (see the next subclauses for some examples).

7.5.2 Example of packet delays

At each egress switch port, a high-priority packet may have to wait for a maximum-length lower-priority packet to egress; a 1518 byte packet takes 122 μs at 100 Mbit/s, 12 μs at 1 Gbit/s.

A potential 2 ms extra delay could therefore be incurred for a network path comprising 16 hops operating at 100 Mbit/s, 160 hops operating at 1 Gbit/s.

At each egress switch port, a high-priority packet may also have to wait for many other high-priority packets to egress; a 600 byte packet (typical for GOOSE) requires 48 μs at 100 Mbit/s, 4,8 μs at 1 Gbit/s.

A potential 2 ms extra delay could therefore be incurred for an event-triggered burst of 40 GOOSE packets when operating at 100 Mbit/s, 400 packets when operating at 1 Gbit/s.

7.6 Useful features of some Ethernet telecommunications networks

A utility may desire its wide-area network to be used for transporting 3rd-party Ethernet traffic, (e.g. to interconnect the LANs of different sites), raising a potential conflict with the VIDs chosen for the utility’s 61850’s IEDs.

For such applications, the “encapsulation” of such traffic in a second 802.1Q VLAN tag (sometimes known as “nested VLANS”, or “QinQ”) is a good solution; this also preserves the original traffic’s priority tags (without such nesting, the utility would need to be able to modify the original tags to ensure that such traffic is kept out of the network’s GOOSE queues).

Some Ethernet Telecommunication networks use SONET rather than Ethernet for their transport formats (for the fibre signals); this technology allows the provisioning of a plurality of Ethernet WANs, each with its own dedicated bandwidth and immunity to the traffic on the others WANs. Some Ethernet Telecommunication switches provide an extra set of queues on their line ports (e.g. 16 c.f. 8) so that for traffic at a particular priority level, the “through” traffic (line to line) has priority over the “add” traffic (drop to line). This mitigates the delay accumulations over multi-hop paths.

Some Ethernet Telecommunication networks monitor the latency of critical traffic paths, recording the peak values over time, so that the user can confirm that the expected performance is being realized.

61850-90-1/DTR © IEC(E) – 59 –

8 Communication aspects

8.1 Services

This clause provides an overview of the information that needs to be transmitted and the service from IEC 61850-7-2 that shall be used.

Status information: Status information is typically transmitted using the GOOSE service from IEC 61850-7-2. If status information must be synchronised with the samples, they can be transmitted in the same message as the samples.

Phasors: If phasors are acquired cyclically, the service for the transmission of sampled values shall be applied. Both the unicast as well as the multicast services can be used. If phasors are time stamped and not necessarily cyclic, the GOOSE service shall be used.

Sampled values: Where sampled values need to be transmitted, the services for unicast or multicast transmission of sampled values shall be used.

8.2 Communication architecture

8.2.1 Preliminary notes and definitions

To explain the basic communication mechanisms involved in SS-to-SS communications, a minimal model shall be used. It is reduced to the case, that function A2 in station A obtains data from function B2 in station B. Of course, the situation is much more complex in reality, there will be most likely also a dataflow in the opposite direction, or there will be also other functions exchanging data with each other. The example used below could be easily extended by applying the principles shown.

The situation is looked at from the viewpoint of function A2; thus station A is called "local", station B is called "remote".

Station B

Function B1

Function B2

Station A

Function A1

Function A2

SS to SS Communication

Mechanism

IEC 61850-90-1

Figure 19 – Basic SS to SS communication structure

The scope of this report is the communication between substations, effectively exchanging data between the station networks. Consequently, the "blue areas" containing "Station A" and "Station B" mean in fact the local communication networks (station networks). In the same

– 60 – 61850-90-1/DTR © IEC(E)

sense, any of the "Functions" could be associated to a logical node when applying IEC 61850. Thus, the terms "Station" or "Station Network" and "Function" or "Logical Node" are often used synonymously in the following.

Two communication mechanisms are considered in this report:

(1) Tunnelling

(2) The Gateway approach using specific teleprotection communication equipment.

8.2.2 Tunnelling

"Tunnelling" means a method to connect multiple substation networks that allows "direct access" to functions in remote stations, see Figure 20.

The tunnel is configured for a specific kind of traffic, e.g. based on a VLAN ID. The kinds of traffic are the only information needed for configuring the tunnel. For IEC 61850, the relevant kinds of traffic would be TCP/IP (for C/S communication) and multicast messages on Ethernet layer 2 (GOOSE and SV).

The tunnel accepts any message of a kind it is configured for and passes it through unchanged. The tunnel does not care about the actual information content of the messages. Consequently, the tunnel does not need to be reconfigured if the "communication" becomes reconfigured, e.g. when the information exchanged between functions changes or if additional functions exchange information.

The station network becomes extended to include the remote station.

For the C/S communication, devices (servers) in the remote station become addressable; technically speaking a route is provided for the IP addresses in the remote station.

For GOOSE/SV, the broadcast domain extends into the remote station.

Station B

Function B1

Function B2

Station A

Function A1

Function A2

Transparent Tunnel (typically high

bandwidth)

IEC 61850-90-1

Figure 20 – SS to SS communication via tunnel

Typically, a tunnel will be only applied if sufficient bandwidth is available. What "sufficient" means, depends on the application.

The exchange of non-time-critical status information for SCADA purposes may work well over a slower link.

61850-90-1/DTR © IEC(E) – 61 –

Exchanging GOOSE messages for remote interlocking may require higher bandwidth just to achieve low enough latency. Even if the data volume of the GOOSE traffic is low, higher bandwidth of a communication mechanism typically correlates with lower latency.

In practice, such tunnels will be established by means of network switches or routers. In a very strict sense, such communication devices could be also seen as a kind of "teleprotection equipment".

8.2.3 Gateway

8.2.3.1 General

Gateways connect multiple substation networks by establishing "indirect access" to functions in remote stations. Gateways can be used if the communication link between substations does not fully support Ethernet communications, e.g. with power line carrier, copper, radio or PDH.

A gateway configuration depends on a specific communication configuration. It is fully aware of the actual information content of the messages. Consequently, the gateway must be reconfigured if the "communication" becomes reconfigured, e.g. when the information exchanged between functions changes or if additional functions exchange information.

For the gateway approach, explicit teleprotection equipment is involved. The teleprotection equipment on the sending side filters and re-codes information for the special communication mechanism used to transfer the information. On the receiving side, the teleprotection equipment re-creates the information from the remote end to provide it in a form that is usable for the functions in the substation.

Gateways can deliver a wide range of functionality. For the further considerations, two kinds of gateways shall be distinguished:

8.2.3.2 GGIO gateway

A number of arbitrary I/O points are exchanged between the stations. In IEC 61850, this would be implemented by using GGIOs. A separate cross-reference list is necessary to interpret the actual meaning of the anonymous data points of the GGIOs. This approach provides no semantics and delivers very little value within the scope of IEC 61850 conformant engineering.

Therefore and because IEC61850-7-4 anyhow forbits the use of GGIOs for data with known semantics, the GGIO Gateway will not be further covered by this document.

8.2.3.3 Proxy gateway

The teleprotection equipment on the receiving side acts as a proxy for the function on the sending side, see Figure 21. This means it re-creates the interface and the behavior of the real function, at least for the scope that is involved in the communication between the functions.

For C/S communication, the data model of the remote function is re-created by the proxy to serve the transmitted information. For GOOSE (and eventually SV), the messages are published by the proxy with the same format as on the remote side.

Thus, the Proxy Gateway is re-iterating the functionality of the tunnelling approach.

– 62 – 61850-90-1/DTR © IEC(E)

Station B

Function B1

Function B2

Station A

Function A1

Function A2

? ? Proxy

B2

"Teleprotection Equipment" acting as Gateway

Special Communication Mechanism (typically low bandwidth)

IEC 61850-90-1

Figure 21 – SS to SS Communication via Proxy gateway

From A2’s perspective, Proxy B2 is providing the subset of information required for A2.The teleprotection equipment can provide other features to make efficient use of the communication mechanism. E.g. for GOOSE, only state changes might be actually transferred, while the retransmissions with constant state information may be filtered out at the sending side and the retransmission are locally re-created in the proxy. Missing retransmissions at the sending side must then be signalled via status information between the teleprotection equipment to the proxy.

61850-90-1/DTR © IEC(E) – 63 –

9 Modelling

9.1 General architecture

In Figure 22 the general diagram for the gateway approach is illustrated. The basic philosophy for gateway approach and tunneling approach is to separate the supervision from the function itself. This is illustrated in Figure 22 by the logical node RTPC for the channel supervision. Any communication failure is brought to the attention of the function by means of the data quality attribute.

The main difference between gateway approach and tunneling approach is for the second one that the proxy logical nodes do not exist (dashed proxys in Figure 22 do not exist with tunneling approach).

RTPC

PSCH

RBRF

LPHDLLN0

PSCH

RBRF

PTRC

PSCH

RBRF

Teleprotection Equipment Teleprotection Equipment

GOOSE

GOOSE

trip

Application

Proxy

Proxy

Application

PTRC

PSCH

RBRF

trip

LPHDLLN0

GOOSE RTPC

GOOSE WAN channel

Figure 22 – Allocation of the LN RTPC representing the communication channel and the LNs providing the data to be exchanged between substations

In clause 9 some use cases from clause 5 are modelled as example according to IEC 61850. Other use cases, not mentioned in clause 9, may be modelled accordingly. Other applications, not listed as use case in clause 5, can also be modelled as long as they use the same approach.

9.2 Communication interface RTPC

The LN RTPC comprises all information for communication channel setting and supervision. RTPC is not intended to generate direct process data. Thus, it does not contain the input and output data to be transmitted and it has no ‘operate’ data object.

NOTE EEHealth is used to indicate the state of the communication channel, whereas PhyHealth is used to indicate the state of the (physical) communication device.

If RTPC receives a GOOSE message with data object quality attribute "invalid" or "questionable" or no GOOSE message at all within Tmax, it shall generate appropriate alarm message(s). Other actions in the direction of telecommunication channel are a local issue (refer to Figure 22).

– 64 – 61850-90-1/DTR © IEC(E)

Table 8 – Logical node RTPC

RTPC class Attribute Name Attr. Type Explanation T M/O LNName Shall be inherited from Logical-Node Class (see IEC 61850-7-2) Data Common Logical Node Information LN shall inherit all Mandatory Data from Common Logical Node

Class M

Measured Values BerCh MV Bit Error Rate of the communication channel. Used in case of a

digital communication channel O

FerCh MV Frame Error Rate of the communication channel. Used in case of a digital communication channel. May be vendor specific

O

LoopTestTm MV Time measured at last loop test O CarrierLev MV Power of received signal in case of an analogue communication

channel O

SNR MV Signal to noise ratio in dB, used in case of analogue communication.

O

Status Information EEHealth INS Communication channel health M

GrdRxCmdRx SPS Alarm situation: Guard received together with the command, may indicate interference on the channel. Used in case of an analogue communication channel.

O

LosOfSig

SPS Alarm situation: No signal received, indicates a channel problem O

TxCmdCnt1 INS For diagnostics: Transmitted commands counters (for each command)

O

RxCmdCnt1 INS For diagnostics: Received commands counters (for each command)

O

LosOfSyn SPS Alarm situation: Loss of synchronism. Indicates that there is no synchronisation between the transmitter and the receiver, i.e., no communication is possible. Used in case of a digital communication channel.

O

Settings NumTxCmd ING Number of used binary transmit commands

O

NumRxCmd ING Number of used binary receive commands

O

TpcTxMod1 ING Teleprotection application mode in Transmit direction for each command (Unused, Blocking, Permissive, Direct, Unblocking, Status)

O

TpcRxMod1 ING Teleprotection application mode in Receive direction for each command (Unused, Blocking, Permissive, Direct, Unblocking, Status)

O

SecTmms ING Pickup security timer on loss of carrier guard signal: if a command is received within SecTmms after the guard has disappeared this command is considered valid, used in case of an analogue communication channel.

O

BoostRatdB ING Level of increased power during the transmission of a command in dB. Used in case of an analogue communication channel

O

TxPEPwrdBm ING Transmit power (peak envelope power) in dBm. Used in case of an analogue communication channel

O

TxCtrHz ING Transmit center frequency. Used in case of an analogue communication channel

O

RxCtrHz ING Receive center frequency. Used in case of an analogue communication channel

O

TxBwHz ING Transmit bandwidth. Used in case of an analogue communication channel

O

RxBwHz ING Receive bandwidth. Used in case of an analogue communication channel

O

61850-90-1/DTR © IEC(E) – 65 –

9.3 Communication-aided protection schemes and direct tripping

9.3.1 Proposed model

This model is applicable for the following use cases (acc. to Clause 5):

Distance line protection with permissive overreach tele-protection scheme

Distance line protection with blocking tele-protection scheme

Directional comparison protection

Transfer/Direct tripping

State comparison protection schemes and direct trip signals shall be modelled by use of the logical node PSCH. The protection scheme requires the transmission of at least one binary signal from the protection device from one line end to the remote line end.

As an example Figure 23 shows the relation between protection application and logical modelling according to IEC 61850.

Figure 23 – Protection application example for permissive underreach distance

teleprotection scheme and appropriate logical node modelling

– 66 – 61850-90-1/DTR © IEC(E)

9.3.2 LN PSCH

Table 9 – Logical node PSCH

PSCH class Attribute Name Attr. Type Explanation T M/O

LNName Shall be inherited from Logical-Node Class (see IEC 61850-7-2)

Data Common Logical Node Information

LN shall inherit all Mandatory Data from Common Logical Node Class M

OpCntRs INC Resetable operation counter O

Status Information

TxPrm ACT Permissive information to be transmitted to the other side (Teleprotection permissive signal)

T O

TxBlk ACT Blocking information to be transmitted to the other side (Teleprotection blocking signal)

T O

TxTr ACT Direct trip information to be transmitted to the other side T O

RxPrm1 ACT Activation information RxPrm1 received from the other side(s), for logging purposes (Teleprotection permissive signal received)

T O

RxBlk1 ACT Activation information RxBlk1 received from the other side(s), for logging purposes (Teleprotection blocking signal received)

T O

RxTr1 ACT Activation information RxTr1 received from the other side(s), for logging purposes (direct trip signal received)

O

Op ACT Operate T M

EchoWei SPS TxPrm is being sent as echo signal or in case of weak end infeed T O

EchoWeiOp SPS Additional indication that Op is the operate from the weak end infeed or echo function (typically with undervoltage control)

T O

Blk SPS Teleprotection in blocked state O

Configuration

RxSrc1 ORG Source for activation information RxPrm or RxBlk, must refer to data of type ACT

O

RxSrcTr1 ORG Source for activation information RxTr, must refer to data of type ACT O

Settings

OpDlTmms ING Operate Delay Time O

CrdTmms ING Co-ordination timer for blocking scheme O

DurTmms ING Minimum duration of TxPerm in case of operate of PSCH O

UnBlkMod ING Unblock function mode for scheme type O

UnBlkTmms ING Unblocking time O

WeiMod ING Mode of weak end infeed function O

WeiTmms ING Co-ordination time for weak end infeed function O

Depending on the trip mode requirements the data exchange can be implemented with one general send/receive signal (e.g. PSCH.TxPrm.general) or with three phase selective send/receive signals (e.g. PSCH.TxPrm.phsA, PSCH.TxPrm.phsB, PSCH.TxPrm.phsC).

61850-90-1/DTR © IEC(E) – 67 –

9.4 Differential protection schemes

9.4.1 Proposed model

This proposal is applied to the communication between substations. Practically it will be applied to the communication between protection relays and telecom equipment as shown Interface (A) in Figure 24 and Figure 25. Figure 24 is based on existing system. Figure 25 shows another system architecture approach.

Public or dedicated network (e.g. SDH)

Telecom equipment Protection

relay Protection relay

Communication between substations

Interface (A)

Telecom equipment

Interface (B)

Figure 24 – Communication system based on current system

Wide area network (e.g. Giga Ether, SDH)

Telecom equipment

Protection relay Protection relay

Interface (A)

Telecom equipment

Interface (B)MU MU

Figure 25 – Communication system based on future system

Basically interface (B) is out of this scope. However if Ethernet is applied to the communication network, interface (B) will be equivalent to the interface (A).

This model can be drawn as Figure 26 for a 2-terminal model and as Figure 27 for a 3-terminal model.

– 68 – 61850-90-1/DTR © IEC(E)

TCTR

PDIF

XCBR PTRC

PDIF

XCBR PTRC

CT

CB trip

sampled valuesor

phasors and

status data

Protection Relay (Local) Protection Relay (Remote)

RMXU RMXU

VT*

External Condition

External Condition

Current or voltage data flow Status Data Decision

Current or voltage data flow with status information

SV service

RTPC RTPC

TVTR

TCTR CT

VT* TVTR

* connection optional for charge current compensation

Figure 26 – Proposed 2-terminal current differential feeder protection relay model

PDIF

XCBR PTRC

PDIF

XCBR PTRC

CT

CB trip

sampled valuesor

phasors and

status data

Protection Relay (Local) Protection Relay (Remote)

RMXU RMXU

VT*

External Condition

External Condition

Status Data Decision

Current or voltage data flow with status information

PDIF

XCBR PTRC

CT

CB trip

Protection Relay (Remote 2)

RMXU

VT*

External Condition

SV service

SV service

RTPC1

RTPC1

RTPC2

RTPC2

RTPC1 RTPC2

TCTR

TVTR

TCTR

TVTR

TCTR

TVTR

CT

VT*

* connection optional for charge current compensation

Figure 27 – Proposed 3-terminal current differential feeder protection relay model

61850-90-1/DTR © IEC(E) – 69 –

9.4.2 LN RMXU

This technical report proposes the change of the logical node name from MDIF in IEC 61850, ed. 1 (2003) to RMXU in ed. 2. Compared to MDIF the logical node RMXU needs to be modified as follows.

LN: Differential measurements Name: RMXU This LN shall be used to provide locally calculated process values (phasors calculated out of samples or the samples itself) representing the local current values which are sent to the remote end and which are used for the local differential protection function (PDIF). Therefore, the LN RMXU together with LN PDIF models the core functionality of the differential protection function number 87 according to the IEEE designation (C37.2). In addition, the LNs RMXU on both sides of the line represent also the function to synchronize the samples. Therefore, also the samples sent from the local TCTR to the local PDIF are routed through the function represented by RMXU. The local RMXU is therefore the source of synchronized samples or phasors from the local current sensor which sends its information to the local PDIF and to all required remote PDIF nodes.

Table 10 - Logical node RMXU

RMXU class

Attribute Name Attr.

Type

Explanation T M/O

LNName …. Shall be inherited from Logical-Node Class (see IEC 61850-7-2)

Data

Common Logical Node Information

LN shall inherited all Mandatory Data from Common Logical

Node Class

M

Measured values

OpALoc WYE Operate Current (Phasor) of the local current measurement C

OpAmpLocA SAV Operate Current (Sampled value) of the local current

measurement (Phase L1)

C

OpAmpLocB SAV Operate Current (Sampled value) of the local current


C

OpAmpLocC SAV Operate Current (Sampled value) of the local current


C

OpAmpLocN SAV Operate Current (Sampled value) of the local current

measurement (Residual current)

O

Condition C: Either OpALoc or OpAmpLocA…OpAmpLocC shall be used

– 70 – 61850-90-1/DTR © IEC(E)

9.4.3 SV format

As explained in previous subclause, SV will be able to transmit any attribute of any CDC. Thus, it can send phasor data as well as sampled values and status data as follows.

Table 11 - Sampled value (SV) format definition Sampled value format

Parameter name Parameter type Value/value range/explanation MsvID or UsvID VISIBLE STRING65 Value from the MSVCB or USVCB

OptFlds A Optional fields to be included in the SV message

DatSet ObjectReference Value from the MSVCB or USVCB Sample [1..n]

Value (*) (*) the type respective structure of the value is determined by the definition of the data set, which is referenced by the MSV / USV control block.

SmpCnt INT16U Sample counter RefrTm TimeStamp OPTIONAL; time of refresh activity ConfRev INT32U Configuration revision number from the

instance of MSVCB or USVCB SmpSynch BOOLEAN OPTIONAL; samples are synchronized by

clock signals SmpRate INT16U OPTIONAL; sample rate from the instance of

MSVCB or USVCB The type and value of the parameter OptFlds shall be derived from the attribute of the respective USVCB or MSVCB

NOTE 1 Examples of possible status data which would belong to the same DataSet as the samples are as follows:

– CT saturation detection, e.g. as quality information

– Confirmation of local differential relay’s operation (each phase + residual current)

– Local testing, e.g. as quality information

– Inrush detection etc.

Only Data Objects that are sampled according to the same sample rate should be sent within the telegram. That means that Data Objects that are not sampled with that sample rate shall not belong to the DataSet. For those kinds of Data Objects, the GOOSE service shall be used, since its control block doesn't introduce a semantic dependency with some kind of acquisition.

NOTE 2 According to IEC 61850-7-2 each SV message contains one sample. Therefore the sample rate is identical to the message transmission rate. Observe that IEC 61850-9-2 introduces the concept of ‘Number of ASDUs’, which allows several samples in a single message, thus reducing the message transmission rate at the expense of longer messages. The requirements of a function implementation determine if such grouping is usable or not.

61850-90-1/DTR © IEC(E) – 71 –

10 Configuration aspects

10.1 General

The practical approach to system configuration depends on the kind of communication system architecture as well as the split of responsibility between the engineering in the concerned substations. The following two scenarios relate to the direct communication connection (Figure 20 – SS to SS communication via tunnel) with one method, and a dedicated tele-protection equipment hiding the communication between the two substations (Figure 21 – SS to SS Communication via Proxy gateway) as a second method.

10.2 Direct communication link

10.2.1 General

For high bandwidth wide area connections the IEC 61850 Ethernet frame can be directly mapped to a wide area Ethernet connection. This corresponds then to a switch in the Ethernet architecture, with possibly lower performance (throughput, delay) than a real switch. To reduce the load on this ‘switch’, the data sent between substations should belong to an own VLAN.

Switches are currently not modelled in SCL. However, the data flow from some IEC 61850 IED in one substation to some appropriate IED in the other substation has to be described. In a meshed power network with all lines needing SS – SS communication, this can end up in the situation that the whole power network with all substations and substation IEDs must appear within one SCL file. As normally for a certain engineering purpose the concerned IEDs only have to know a part of the other system(s), it seems to be appropriate to use ‘System interface Exchange Descriptions’ (SED), which contain only a part of the overall system to be engineered for a certain purpose. This SED file is then transferred from one substation project to the other project, to include the needed DATA into the data flow. The engineered data flow then is transferred back to the originating system / project by means of an enhanced SED file, so that both systems then have the same consistent state regarding the data to be exchanged between them across the connecting Ethernet link.

Figure 28 – SCD files and SED region for SS-to-SS communication

AA1FAA1F

61850 Bus, Subnet AA1WA1

AA2FAA2F

Substation AA1 Substation AA2

High bandwidth wide area connection ‘looks like switch’

SW1/ SW1/2

SCD1 SCD2SED

– 72 – 61850-90-1/DTR © IEC(E)

From the view of the concerned tools this means that several system configuration tools exist, each responsible to configure a certain part of the overall system, i.e. each ‘owner’ of a certain amount of IEDs. We call a set of IEDs, which is engineered and also configured by a system tool and its connection to the corresponding IED tools, a project. These projects (project system configuration tools) exchange engineering data, which describe the overlapping parts. These overlapping parts are for some projects a boundary part, which they are not allowed to change, or only to change in a limited way before re-export to the ‘owner’ of this part. Only the IED owner project is allowed to give an SCD file to the IED tool for IED configuration. See Figure 29 for this engineering process.

IEDConfigurator

IEDDB

Substation gateway

IED IED IED

File transferLocal

File transferremote

EngineeringWorkplaceEngineeringWorkplace

SystemConfigurator

SystemConfigurator

IED Capabilities(LN, DO, …)

Associations, relation to single line,preconfigured reports, ...

File transfer and Parametrization with IEC61850 services

Engineering environment

SA system

System specification(Single line, LNs, …)

.CID

.ICD

.SSD

.SCD

SystemConfiguratorPart system

.SED

.SCD

Other IEC61850 projectwith interfaces betweenprojects

SystemConfigurator

SystemConfiguratorPart system

.SED

.SCD

Other IEC61850 projectwith interfaces betweenprojects

Figure 29 – Enhanced engineering process

In Figure 28 the IEDs AA1F1 and AA1F2 are owned by the system tool handling the AA1 project (substation), while AA2F1 and AA2F2 are owned by the system tool handling the AA2 project. AA1F2 is a ‘boundary’ IED for the AA2 project, while AA2F1 is a boundary IED for the AA1 project.

Important for SED files is how they are handled at export and import of the system configuration tools. For this purpose, at export a system tool can decide which kind of engineering rights another system tool might have. The engineering rights as defined in IEC 61850-6 are shown in the following table.

It should be remembered, that the only tool which is allowed to change the IED data model, is the IED tool. So, changes of data model are only allowed by the IED tool, and the handling after system integration is described in IEC 61850-6.

61850-90-1/DTR © IEC(E) – 73 –

Table 12 – IED engineering control types

IED Engineering

right

Meaning / purpose

Export handling Import handling Remarks

fix Fix boundary IED, no change allowed by other tools; ownership stays at exporting project (system tool)

Only those parts of the data model (access points, LDevice, LNs) and data flow definitions (data sets, control blocks) are exported, which are already referenced by the dataflow IEDs in this SED. All version information shall be in the exported parts.

If the importing project is the owner, then the IED is ignored and only the internal state set to full again. Is imported, if it does not exist. If it exists as fix / dataflow IED with lower version info, the old IED has to be replaced. If it exists as dataflow IED with same version, state should be set to fix.

Changes allowed only at owner. Might be referenced as client in owned IEDs.

dataflow Boundary IED, additions in data flow definitions are allowed in the limits of the IED engineering capability (especially new client references); ownership stays at exporting project

Only those parts of the data model (access points, LDevice, LNs) and data flow definitions (data sets, control blocks) are exported, which are needed / allowed for further engineering. Note that if new clients can be added for report control blocks, then all existing clients must also be contained at least as fix IEDs, else the RCB instance allocation would be disturbed. Similar it is with input section references.

If the importing project is the owner, the part must be checked for added data sets, control blocks, data flow definitions (also in existing control blocks) and new Input sections, and these modified / imported; then state is set to full again. This might mean that previously all other IEDs of the SED have to be imported, which are referenced.

If the owner is some other project, it is imported. If it exists already, the versions of existing parts should be checked, and only newer parts imported, replacing existing parts.

Changes at owner are blocked after export; at importing projects:no change of data model allowed, no removal of already engineered parts, no change in existing data sets and control blocks (confRev unchanged). Only additions of DS and CBs are allowed. Engineering capabilities can be restricted at export by setting the capability options appropriately.

full Full engineering of data flow is allowed. This right can not be formally transferred

Not allowed to export in a SED file.

Should not appear within a SED file – stop import

When an IED is exported to a SED file, then the IED ownership is marked by means of the (new) owner attribute of the IED, which is set to the SCD header identification respective project identification, and an IED exported as dataflow is blocked for changes within the owning system tool, e.g. by setting it to fix.

If a dataflow IED with same owner id as the project id is re-imported, then the change block is taken away again. The owner attribute at IEDs with fix and dataflow engineering right marks to which project they belong, to block changes at the owner after dataflow export.

The different IED states within a project and the triggers from one to the other are shown in Figure 30. Observe that there are two automata. One is valid in case that a system configuration tool starts with full control, the other is for an IED imported with dataflow control.

– 74 – 61850-90-1/DTR © IEC(E)

FullSrc=own

fixSrc=own

Export dataFlowSrc=ownImport dataFlow

Src=ownInclude additions

Export fixSrc=own

Import fixSrc=ownCheck revisions!If different, mark for transfer back

IED owner states

Interface IED states

IED not known

dataflowSrc=other

Import partSrc=other

Data set /data flow changesMark for transfer to other

Import dataFlowSrc=otherCheck changes!

fixSrc=other

Export dataFlowSrc=other

Import fixSrc=otherReplace, keep references

Figure 30 – IED states when exchanging SED files

The definitions above only concern IED sections. IEDs can also be referenced by the Communication section, and by the Substation section. Therefore these must also be considered:

• Communication section: all parts belonging to exported IEDs respective IED parts must be contained. For part IEDs and fixed IEDs only those parts of access points and control block parameters shall appear, which are still contained in the exported IED part. Both is not allowed to be changed. If address coordination is an issue, all access points with addresses can be exported (and the IED as fix, just containing the access point).

• Substation section: All elements down to bay, which contain references to LNs on some of the exported IEDs, have also to be exported, inclusive the references to IEDs to be exported. For any concerned bay its topology as well as primary equipment has to be exported completely, only references to logical nodes not contained in the exported part are allowed to be removed. No links are allowed to be modified or added for exported IEDs, just for newly introduced own IEDs. Also new bays and new IEDs might be added, but it is not allowed to delete bays or primary equipment.

It might happen, that several SED files from the same system part are exported at different points in time. Each of them shall have an identification and a revision index with time of modification. This allows identifying the latest version of a certain SED file, which then also indicates a specific purpose respective an export to a specific project. It is the responsibility of the importing project engineer, to identify different SED files and their versions. In any case, any owned IED marked as fix should only be exported as fix, if needed at all.

It is the responsibility of the project engineer as well as the exporting system tool, that a SED file containing IEDs with dataflow right for a certain engineering purpose is only used for this purpose and not in parallel for another purpose in another (third) system tool / project. This also includes that an exporting system tool is only allowed to export dataflow IEDs once for a certain purpose, and not a second time in parallel as dataflow IED for another purpose, before the possibly modified IED has been again re-imported. Fixed IEDs can be exported as fix in parallel as often as needed, because they do not have to be re-imported. The owner attribute

61850-90-1/DTR © IEC(E) – 75 –

value at fix and dataflow IEDs supports the system tool to remember, that it is the ‘owner’ of the IED, so that it can reset the state to ‘full’ after a re-import of the IED.

10.2.2 SCL enhancements

For the purpose defined above, the following SCL enhancements are introduced (see IEC 61850-6).

a) Optional attribute engRight at the IED element with values fix, dataflow; the default value, if missing, is full, which is not allowed within a SED file.

b) Optional attribute owner of type string at the IED element with default value identical to the Header id. This id contains the SCL ID / project ID of the system configurator project, which has exported this IED to a SED file. The SED identification must be different from the owner values.

An example of a SED file for SS-SS communication is contained in the next clause.

10.2.3 SCL example

The example is based on the system configuration of Figure 28. The engineering process in this case works as follows.

a) Project AA2 exports a SED file for IED AA2F1, with AA2F1 as data flow IED, and all needed source IEDs as fix IEDs.

b) Project AA1 imports the SED file, and engineers the data flow between AA1F2 and AA2F1. c) Project AA1 now can configure AA1F2 with its IED tool; then it exports a SED file with

same identification as the imported SED, containing AA1F2 as fixed IED and AA2F1 as original data flow IED (plus all needed source IEDs as fix) with the added data flow definitions.

d) Project AA2 imports the SED file, and finalizes any engineering on AA2F1 based on its now complete system description; now AA2F1 can be configured by its IED tool.

Note that it is the responsibility of the project engineer, to communicate any project changes (e.g. in project AA1) which influence the boundary IEDs owned by other projects (e.g. AA2F1 in project AA2), to the appropriate project. If this is forgotten, a sudden failure in communication especially with GOOSE and SAV services between the concerned IEDs might happen due to mismatch of message confRev values.

An alternative engineering approach could have been to export AA2F1 in step1 as fix, but with already preconfigured data set and control block to be sent to AA2F1. In this case within step 2 only the data flow from AA1F2 to AA2F1 could be engineered, and within step 4 the still missing data flow from AA1F2 to AA2F1 has to be added. This simplifies the tasks of the tools, because they have only to handle import and export of fix IEDs, however might complicate the engineering, because the complete communication engineering between AA1F2 and AA2F1 has been split into several parts (steps 1, 2, 4) instead of one step (step 2). Especially, it can not be indicated in step 1, that AA1F2 is the GOOSE client of AA2F1.

The following shows the SED file example to be imported in engineering step 4. It also contains the modelling of the line connection between the two substations as ConductingEquipment of type LIN (overhead line), to make the primary system modelling complete and show, that the two bays in the substations are connected by a common line. Further, the protection IED AA1FP2, which in principle is the same IED type as AA2FP1, is exported as fix, and therefore only the relevant (interface) parts for AA1FP2 are contained in it. It might contain more, but this is not necessary.

– 76 – 61850-90-1/DTR © IEC(E)

<?xml version="1.0"?> <SCL xmlns:sxy="http://www.iec.ch/61850/2003/SCLcoordinates" xmlns="http://www.iec.ch/61850/2003/SCL"> <Header id="SS-SS AA1 – AA2" toolID="SSI-Tool" nameStructure="IEDName" /> <Substation name="AA1" desc="Substation"> <VoltageLevel name="D1" desc="Voltage Level"> <Bay name="Q1" desc="Bay" sxy:x="55" sxy:y="62" sxy:dir="vertical"> <LNode iedName="AA1FP1" ldInst="LD1" lnClass="PTOC" lnInst="1" /> <LNode iedName="AA1FP1" ldInst="LD1" lnClass="PTRC" lnInst="1" /> <LNode iedName="AA1FP1" ldInst="LD1" prefix="F21" lnClass="PSCH" lnInst="1" /> <LNode iedName="AA1FP1" ldInst="LD1" prefix="F21" lnClass="PDIS" lnInst="1" /> <ConductingEquipment name="BI1" desc="Current Transformer" type="CTR" sxy:x="8" sxy:y="15" sxy:dir="vertical"> <Terminal name="AA1D1Q1N2" connectivityNode="AA1/D1/Q1/N2" substationName="AA1" voltageLevelName="D1" bayName="Q1" cNodeName="N2" /> <Terminal name="AA1D1Q1N3" connectivityNode="AA1/D1/Q1/N3" substationName="AA1" voltageLevelName="D1" bayName="Q1" cNodeName="N3" /> </ConductingEquipment> <ConductingEquipment name="QC2" desc="Isolator" type="DIS" sxy:x="10" sxy:y="21" sxy:dir="vertical"> <Terminal name="AA1D1Q1N6" connectivityNode="AA1/D1/Q1/N6" substationName="AA1" voltageLevelName="D1" bayName="Q1" cNodeName="N6" /> <Terminal name="grounded" connectivityNode="AA1/D1/Q1/grounded" substationName="AA1" voltageLevelName="D1" bayName="Q1" cNodeName="grounded" /> </ConductingEquipment> <ConductingEquipment name="BU2" desc="Voltage Transformer 3Phase" type="VTR" sxy:x="12" sxy:y="14" sxy:dir="vertical"> <Terminal name="AA1D1Q1N3" connectivityNode="AA1/D1/Q1/N3" substationName="AA1" voltageLevelName="D1" bayName="Q1" cNodeName="N3" /> </ConductingEquipment> <ConductingEquipment name="QB2" desc="Isolator" type="DIS" sxy:x="12" sxy:y="4" sxy:dir="vertical"> <Terminal name="AA1D1QBBN4" connectivityNode="AA1/D1/QBB/N4" substationName="AA1" voltageLevelName="D1" bayName="QBB" cNodeName="N4" /> <Terminal name="AA1D1Q1N5" connectivityNode="AA1/D1/Q1/N5" substationName="AA1" voltageLevelName="D1" bayName="Q1" cNodeName="N5" /> </ConductingEquipment> <ConductingEquipment name="QC1" desc="Isolator" type="DIS" sxy:x="10" sxy:y="8" sxy:dir="vertical"> <Terminal name="AA1D1Q1N5" connectivityNode="AA1/D1/Q1/N5" substationName="AA1" voltageLevelName="D1" bayName="Q1" cNodeName="N5" /> <Terminal name="grounded" connectivityNode="AA1/D1/Q1/grounded" substationName="AA1" voltageLevelName="D1" bayName="Q1" cNodeName="grounded" /> </ConductingEquipment> <ConductingEquipment name="BI3" desc="Current Transformer" type="CTR" sxy:x="8" sxy:y="19" sxy:dir="vertical"> <Terminal name="AA1D1Q1N6" connectivityNode="AA1/D1/Q1/N6" substationName="AA1" voltageLevelName="D1" bayName="Q1" cNodeName="N6" /> <Terminal name="AA1D1Q1N4" connectivityNode="AA1/D1/Q1/N4" substationName="AA1" voltageLevelName="D1" bayName="Q1" cNodeName="N4" /> </ConductingEquipment> <ConductingEquipment name="QA1" desc="Circuit Breaker" type="CBR" sxy:x="8" sxy:y="11" sxy:dir="vertical"> <Terminal name="AA1D1Q1N3" connectivityNode="AA1/D1/Q1/N3" substationName="AA1" voltageLevelName="D1" bayName="Q1" cNodeName="N3" /> <Terminal name="AA1D1Q1N5" connectivityNode="AA1/D1/Q1/N5" substationName="AA1" voltageLevelName="D1" bayName="Q1" cNodeName="N5" /> </ConductingEquipment> <ConductingEquipment name="BI2" desc="Current Transformer" type="CTR" sxy:x="8" sxy:y="17" sxy:dir="vertical"> <Terminal name="AA1D1Q1N2" connectivityNode="AA1/D1/Q1/N2" substationName="AA1" voltageLevelName="D1" bayName="Q1" cNodeName="N2" /> <Terminal name="AA1D1Q1N4" connectivityNode="AA1/D1/Q1/N4" substationName="AA1" voltageLevelName="D1" bayName="Q1" cNodeName="N4" /> </ConductingEquipment> <ConductingEquipment name="QB1" desc="Isolator" type="DIS" sxy:x="6" sxy:y="4" sxy:dir="vertical"> <Terminal name="AA1D1Q1N5" connectivityNode="AA1/D1/Q1/N5" substationName="AA1" voltageLevelName="D1" bayName="Q1" cNodeName="N5" /> <Terminal name="AA1D1QBBN1" connectivityNode="AA1/D1/QBB/N1" substationName="AA1" voltageLevelName="D1" bayName="QBB" cNodeName="N1" /> </ConductingEquipment> <ConductingEquipment name="QB4" desc="Isolator" type="DIS" sxy:x="8" sxy:y="23" sxy:dir="vertical"> <Terminal name="AA1D1Q1N1" connectivityNode="AA1/D1/Q1/N1" substationName="AA1" voltageLevelName="D1" bayName="Q1" cNodeName="N1" /> <Terminal name="AA1D1Q1N6" connectivityNode="AA1/D1/Q1/N6" substationName="AA1" voltageLevelName="D1" bayName="Q1" cNodeName="N6" /> </ConductingEquipment> <ConductingEquipment name="QC3" desc="Isolator" type="DIS" sxy:x="10" sxy:y="35" sxy:dir="vertical">

61850-90-1/DTR © IEC(E) – 77 –

<Terminal name="AA1D1Q1N1" connectivityNode="AA1/D1/Q1/N1" substationName="AA1" voltageLevelName="D1" bayName="Q1" cNodeName="N1" /> <Terminal name="grounded" connectivityNode="AA1/D1/Q1/grounded" substationName="AA1" voltageLevelName="D1" bayName="Q1" cNodeName="grounded" /> </ConductingEquipment> <ConnectivityNode name="N1" pathName="AA1/D1/Q1/N1" sxy:x="8" sxy:y="31" /> <ConnectivityNode name="N2" pathName="AA1/D1/Q1/N2" sxy:x="8" sxy:y="16" /> <ConnectivityNode name="N3" pathName="AA1/D1/Q1/N3" sxy:x="9" sxy:y="13" /> <ConnectivityNode name="N6" pathName="AA1/D1/Q1/N6" sxy:x="8" sxy:y="21" /> <ConnectivityNode name="N5" pathName="AA1/D1/Q1/N5" sxy:x="9" sxy:y="6" /> <ConnectivityNode name="N4" pathName="AA1/D1/Q1/N4" sxy:x="8" sxy:y="18" /> </Bay> <Bay name="QBB" desc="Bay" sxy:x="63" sxy:y="36" sxy:dir="vertical"> <ConnectivityNode name="N3" pathName="AA1/D1/QBB/N3" sxy:x="48" sxy:y="12" /> <ConnectivityNode name="N2" pathName="AA1/D1/QBB/N2" sxy:x="47" sxy:y="17" /> <ConnectivityNode name="N4" pathName="AA1/D1/QBB/N4" sxy:x="25" sxy:y="18" /> <ConnectivityNode name="N1" pathName="AA1/D1/QBB/N1" sxy:x="22" sxy:y="20" /> </Bay> </VoltageLevel> </Substation> <Substation name="AA2" desc="Substation"> <VoltageLevel name="D1" desc="Voltage Level"> <Bay name="Q1" desc="Bay" sxy:x="55" sxy:y="62" sxy:dir="vertical"> <LNode iedName="AA2FP1" ldInst="LD1" lnClass="PTOC" lnInst="1" /> <LNode iedName="AA2FP1" ldInst="LD1" lnClass="PTRC" lnInst="1" /> <LNode iedName="AA2FP1" ldInst="LD1" prefix="F21" lnClass="PSCH" lnInst="1" /> <LNode iedName="AA2FP1" ldInst="LD1" prefix="F21" lnClass="PDIS" lnInst="1" /> <ConductingEquipment name="BI1" desc="Current Transformer" type="CTR" sxy:x="8" sxy:y="15" sxy:dir="vertical"> <Terminal name="AA2D1Q1N2" connectivityNode="AA2/D1/Q1/N2" substationName="AA2" voltageLevelName="D1" bayName="Q1" cNodeName="N2" /> <Terminal name="AA2D1Q1N3" connectivityNode="AA2/D1/Q1/N3" substationName="AA2" voltageLevelName="D1" bayName="Q1" cNodeName="N3" /> </ConductingEquipment> <ConductingEquipment name="QC2" desc="Isolator" type="DIS" sxy:x="10" sxy:y="21" sxy:dir="vertical"> <Terminal name="AA2D1Q1N6" connectivityNode="AA2/D1/Q1/N6" substationName="AA2" voltageLevelName="D1" bayName="Q1" cNodeName="N6" /> <Terminal name="grounded" connectivityNode="AA2/D1/Q1/grounded" substationName="AA2" voltageLevelName="D1" bayName="Q1" cNodeName="grounded" /> </ConductingEquipment> <ConductingEquipment name="BU2" desc="Voltage Transformer 3Phase" type="VTR" sxy:x="12" sxy:y="14" sxy:dir="vertical"> <Terminal name="AA2D1Q1N3" connectivityNode="AA1/D1/Q1/N3" substationName="AA1" voltageLevelName="D1" bayName="Q1" cNodeName="N3" /> </ConductingEquipment> <ConductingEquipment name="QB2" desc="Isolator" type="DIS" sxy:x="12" sxy:y="4" sxy:dir="vertical"> <Terminal name="AA2D1QBBN4" connectivityNode="AA2/D1/QBB/N4" substationName="AA2" voltageLevelName="D1" bayName="QBB" cNodeName="N4" /> <Terminal name="AA2D1Q1N5" connectivityNode="AA2/D1/Q1/N5" substationName="AA2" voltageLevelName="D1" bayName="Q1" cNodeName="N5" /> </ConductingEquipment> <ConductingEquipment name="QC1" desc="Isolator" type="DIS" sxy:x="10" sxy:y="8" sxy:dir="vertical"> <Terminal name="AA2D1Q1N5" connectivityNode="AA2/D1/Q1/N5" substationName="AA2" voltageLevelName="D1" bayName="Q1" cNodeName="N5" /> <Terminal name="grounded" connectivityNode="AA2/D1/Q1/grounded" substationName="AA2" voltageLevelName="D1" bayName="Q1" cNodeName="grounded" /> </ConductingEquipment> <ConductingEquipment name="BI3" desc="Current Transformer" type="CTR" sxy:x="8" sxy:y="19" sxy:dir="vertical"> <Terminal name="AA2D1Q1N6" connectivityNode="AA2/D1/Q1/N6" substationName="AA2" voltageLevelName="D1" bayName="Q1" cNodeName="N6" /> <Terminal name="AA2D1Q1N4" connectivityNode="AA2/D1/Q1/N4" substationName="AA2" voltageLevelName="D1" bayName="Q1" cNodeName="N4" /> </ConductingEquipment> <ConductingEquipment name="QA1" desc="Circuit Breaker" type="CBR" sxy:x="8" sxy:y="11" sxy:dir="vertical"> <Terminal name="AA2D1Q1N3" connectivityNode="AA2/D1/Q1/N3" substationName="AA2" voltageLevelName="D1" bayName="Q1" cNodeName="N3" /> <Terminal name="AA2D1Q1N5" connectivityNode="AA2/D1/Q1/N5" substationName="AA2" voltageLevelName="D1" bayName="Q1" cNodeName="N5" /> </ConductingEquipment> <ConductingEquipment name="BI2" desc="Current Transformer" type="CTR" sxy:x="8" sxy:y="17" sxy:dir="vertical"> <Terminal name="AA1D1Q1N2" connectivityNode="AA2/D1/Q1/N2" substationName="AA2" voltageLevelName="D1" bayName="Q1" cNodeName="N2" /> <Terminal name="AA1D1Q1N4" connectivityNode="AA2/D1/Q1/N4" substationName="AA2" voltageLevelName="D1" bayName="Q1" cNodeName="N4" /> </ConductingEquipment>

– 78 – 61850-90-1/DTR © IEC(E)

<ConductingEquipment name="QB1" desc="Isolator" type="DIS" sxy:x="6" sxy:y="4" sxy:dir="vertical"> <Terminal name="AA1D1Q1N5" connectivityNode="AA2/D1/Q1/N5" substationName="AA2" voltageLevelName="D1" bayName="Q1" cNodeName="N5" /> <Terminal name="AA1D1QBBN1" connectivityNode="AA2/D1/QBB/N1" substationName="AA2" voltageLevelName="D1" bayName="QBB" cNodeName="N1" /> </ConductingEquipment> <ConductingEquipment name="QB4" desc="Isolator" type="DIS" sxy:x="8" sxy:y="23" sxy:dir="vertical"> <Terminal name="AA1D1Q1N1" connectivityNode="AA2/D1/Q1/N1" substationName="AA2" voltageLevelName="D1" bayName="Q1" cNodeName="N1" /> <Terminal name="AA1D1Q1N6" connectivityNode="AA2/D1/Q1/N6" substationName="AA2" voltageLevelName="D1" bayName="Q1" cNodeName="N6" /> </ConductingEquipment> <ConductingEquipment name="QC3" desc="Isolator" type="DIS" sxy:x="10" sxy:y="35" sxy:dir="vertical"> <Terminal name="AA1D1Q1N1" connectivityNode="AA2/D1/Q1/N1" substationName="AA2" voltageLevelName="D1" bayName="Q1" cNodeName="N1" /> <Terminal name="grounded" connectivityNode="AA2/D1/Q1/grounded" substationName="AA2" voltageLevelName="D1" bayName="Q1" cNodeName="grounded" /> </ConductingEquipment> <ConnectivityNode name="N1" pathName="AA2/D1/Q1/N1" sxy:x="8" sxy:y="31" /> <ConnectivityNode name="N2" pathName="AA2/D1/Q1/N2" sxy:x="8" sxy:y="16" /> <ConnectivityNode name="N3" pathName="AA2/D1/Q1/N3" sxy:x="9" sxy:y="13" /> <ConnectivityNode name="N6" pathName="AA2/D1/Q1/N6" sxy:x="8" sxy:y="21" /> <ConnectivityNode name="N5" pathName="AA2/D1/Q1/N5" sxy:x="9" sxy:y="6" /> <ConnectivityNode name="N4" pathName="AA2/D1/Q1/N4" sxy:x="8" sxy:y="18" /> </Bay> <Bay name="QBB" desc="Bay" sxy:x="63" sxy:y="36" sxy:dir="vertical"> <ConnectivityNode name="N3" pathName="AA2/D1/QBB/N3" sxy:x="48" sxy:y="12" /> <ConnectivityNode name="N2" pathName="AA2/D1/QBB/N2" sxy:x="47" sxy:y="17" /> <ConnectivityNode name="N4" pathName="AA2/D1/QBB/N4" sxy:x="25" sxy:y="18" /> <ConnectivityNode name="N1" pathName="AA2/D1/QBB/N1" sxy:x="22" sxy:y="20" /> </Bay> </VoltageLevel> </Substation> <Substation name="AA12" desc="Line between AA1 and AA2"> <VoltageLevel name="D1" desc="Line Voltage Level"> <Bay name="W1" desc="Bay" sxy:x="55" sxy:y="62" sxy:dir="vertical"> <ConductingEquipment name="WA1" desc="Overhead line" type="LIN" sxy:x="2" sxy:y="12" > <Terminal name="AA1D1Q1N1" connectivityNode="AA1/D1/Q1/N1" substationName="AA1" voltageLevelName="D1" bayName="Q1" cNodeName="N1" /> <Terminal name="AA2D1Q1N1" connectivityNode="AA2/D1/Q1/N1" substationName="AA2" voltageLevelName="D1" bayName="Q1" cNodeName="N1" /> </ConductingEquipment> </Bay> </VoltageLevel> </Substation> <Communication> <SubNetwork name="AA1WA1" desc="IEC61850 through both stations" type="8-MMS"> <ConnectedAP iedName="AA2FP1" apName="S1"> <Address> 0 172.17.1.4 255.255.0.0 1,3,9999,23 23 0001 00000001 0001 </Address> <GSE ldInst="LD1" cbName="SSAA2dist"> <Address> 01-0C-CD-01-02 2001 </Address> <MinTime unit="s">2</MinTime> <MaxTime unit="s">1000</MaxTime> </GSE> </ConnectedAP> <ConnectedAP iedName="AA1FP1" apName="S1"> <Address> 0 172.16.1.3 255.255.0.0 1,3,9999,23 23 0001 00000001 0001

61850-90-1/DTR © IEC(E) – 79 –

</Address> <GSE ldInst="LD1" cbName="SSAA2dist"> <Address> 01-0C-CD-01-01 2001 </Address> <MinTime unit="s">2</MinTime> <MaxTime unit="s">1000</MaxTime> </GSE> </ConnectedAP> <ConnectedAP iedName="AA2OPC1" apName="S1"> <Address> 0 172.17.0.100 255.255.0.0 1,3,9999,23 23 0001 00000001 0001 </Address> </ConnectedAP> </SubNetwork> </Communication> <IED name="AA2OPC1" type="OPCServer" manufacturer="XYZ" configVersion="1.0" engRight="fix" owner="AA2" > <AccessPoint name="S1"> <LN inst="1" lnClass="IHMI" lnType="IHMI_OPCServer_IEC61850" /> </AccessPoint> </IED> <IED name="AA1FP1" type="REL316-4" manufacturer="ABC" configVersion="1.0" engRight="fix" owner="AA1" > <Services> <DynAssociation /> <SettingGroups> <SGEdit /> </SettingGroups> <GetDirectory /> <GetDataObjectDefinition /> <DataObjectDirectory /> <GetDataSetValue /> <ConfDataSet max="50" maxAttributes="240" /> <ReadWrite /> <ConfReportControl max="100" /> <GetCBValues /> <ReportSettings datSet="Conf" rptID="Dyn" optFields="Dyn" bufTime="Dyn" trgOps="Dyn" intgPd="Dyn" /> <GSESettings datSet="Conf" appID="Conf" /> <GOOSE max="20" /> </Services> <AccessPoint name="S1"> <Server> <Authentication none="true" /> <LDevice inst="LD1"> <LN0 inst="" lnClass="LLN0" lnType="LLN0_REL316-4_IEC61850"> <DataSet name="PSCHtoAA2"> <FCDA ldInst="LD1" prefix="F21" lnClass="PSCH" lnInst="1" doName="Op" daName="general" fc="ST" /> <FCDA ldInst="LD1" prefix="F21" lnClass="PSCH" lnInst="1" doName="Op" daName="phsA" fc="ST" /> <FCDA ldInst="LD1" prefix="F21" lnClass="PSCH" lnInst="1" doName="Op" daName="phsB" fc="ST" /> <FCDA ldInst="LD1" prefix="F21" lnClass="PSCH" lnInst="1" doName="Op" daName="phsC" fc="ST" /> <FCDA ldInst="LD1" prefix="F21" lnClass="PSCH" lnInst="1" doName="Op" daName="q" fc="ST" /> <FCDA ldInst="LD1" prefix="F21" lnClass="PSCH" lnInst="1" doName="ProRx" daName="stVal" fc="ST" /> <FCDA ldInst="LD1" prefix="F21" lnClass="PSCH" lnInst="1" doName="ProRx" daName="q" fc="ST" /> <FCDA ldInst="LD1" prefix="F21" lnClass="PSCH" lnInst="1" doName="WeiOp" daName="general" fc="ST" /> <FCDA ldInst="LD1" prefix="F21" lnClass="PSCH" lnInst="1" doName="WeiOp" daName="q" fc="ST" /> </DataSet> <GSEControl name="SSAA2dist" desc="to AA2" datSet="PSCHtoAA2" confRev="1" appID=""> <IEDName>AA2FP1</IEDName> </GSEControl> </LN0> <LN inst="1" lnClass="PSCH" lnType="F21_Distance Scheme_REL316-4_IEC61850" prefix="F21" /> <LN inst="1" lnClass="LPHD" lnType="Physical Device_REL316-4_IEC61850" /> </LDevice> </Server> </AccessPoint> </IED> <IED name="AA2FP1" type="REL316-4" manufacturer="ABC" configVersion="1.0" engRight="dataflow" owner="AA2" > <Services>

– 80 – 61850-90-1/DTR © IEC(E)

<DynAssociation /> <SettingGroups> <SGEdit /> </SettingGroups> <GetDirectory /> <GetDataObjectDefinition /> <DataObjectDirectory /> <GetDataSetValue /> <ConfDataSet max="50" maxAttributes="240" /> <ReadWrite /> <ConfReportControl max="100" /> <GetCBValues /> <ReportSettings datSet="Conf" rptID="Dyn" optFields="Dyn" bufTime="Dyn" trgOps="Dyn" intgPd="Dyn" /> <GSESettings datSet="Conf" appID="Conf" /> <GOOSE max="20" /> </Services> <AccessPoint name="S1"> <Server> <Authentication none="true" /> <LDevice inst="LD1"> <LN0 inst="" lnClass="LLN0" lnType="LLN0_REL316-4_IEC61850"> <DataSet name="PSCHtoAA1"> <FCDA ldInst="LD1" prefix="F21" lnClass="PSCH" lnInst="1" doName="Op" daName="general" fc="ST" /> <FCDA ldInst="LD1" prefix="F21" lnClass="PSCH" lnInst="1" doName="Op" daName="phsA" fc="ST" /> <FCDA ldInst="LD1" prefix="F21" lnClass="PSCH" lnInst="1" doName="Op" daName="phsB" fc="ST" /> <FCDA ldInst="LD1" prefix="F21" lnClass="PSCH" lnInst="1" doName="Op" daName="phsC" fc="ST" /> <FCDA ldInst="LD1" prefix="F21" lnClass="PSCH" lnInst="1" doName="Op" daName="q" fc="ST" /> <FCDA ldInst="LD1" prefix="F21" lnClass="PSCH" lnInst="1" doName="ProRx" daName="stVal" fc="ST" /> <FCDA ldInst="LD1" prefix="F21" lnClass="PSCH" lnInst="1" doName="ProRx" daName="q" fc="ST" /> <FCDA ldInst="LD1" prefix="F21" lnClass="PSCH" lnInst="1" doName="WeiOp" daName="general" fc="ST" /> <FCDA ldInst="LD1" prefix="F21" lnClass="PSCH" lnInst="1" doName="WeiOp" daName="q" fc="ST" /> </DataSet> <DataSet name="StatUrgentA" desc="Status Data used to update process pictures and to generate alarms."> <FCDA ldInst="LD1" prefix="" lnClass="LPHD" lnInst="1" doName="Alm1" fc="ST" /> <FCDA ldInst="LD1" prefix="" lnClass="PTRC" lnInst="1" doName="Op" fc="ST" /> <FCDA ldInst="LD1" prefix="" lnClass="TVTR" lnInst="1" doName="FuFail" fc="ST" /> </DataSet> <ReportControl name="rcb_A" rptID="" datSet="StatUrgentA" confRev="1" bufTime="100" buffered="true"> <TrgOps dchg="true" qchg="true" /> <OptFields /> <RptEnabled max="5"> <ClientLN iedName="AA2OPC1" ldInst="none" lnInst="1" lnClass="IHMI" /> </RptEnabled> </ReportControl> <GSEControl name="SSAA2dist" desc="to AA1" datSet="PSCHtoAA1" confRev="1" appID=""> <IEDName>AA1FP1</IEDName> </GSEControl> </LN0> <LN inst="1" lnClass="LPHD" lnType="Physical Device_REL316-4_IEC61850" /> <LN inst="1" lnClass="PSCH" lnType="F21_Distance Scheme_REL316-4_IEC61850" prefix="F21" /> <LN inst="1" lnClass="PTOC" lnType="NPS DT_REL316-4_IEC61850" /> <LN inst="1" lnClass="PTRC" lnType="System Protection_REL316-4_IEC61850" /> <LN inst="1" lnClass="TCTR" lnType="CT_REL316-4_IEC61850" /> <LN inst="1" lnClass="TVTR" lnType="VT_REL316-4_IEC61850" /> <LN inst="1" lnClass="PDIS" lnType="F21_Distance Z1_REL316-4_IEC61850" prefix="F21" /> </LDevice> </Server> </AccessPoint> </IED> <DataTypeTemplates> ……………… </DataTypeTemplates> </SCL>

61850-90-1/DTR © IEC(E) – 81 –

10.3 Tele-protection equipment between substations

This case (corresponding to Figure 21 – SS to SS Communication via Proxy gateway), where dedicated teleprotection equipment connects the substations offering a certain fixed amount of signals to be transferred between them, can from the engineering approach be used for high bandwidth as well as low bandwidth communications. From the engineering point of view, here the teleprotection equipment is introduced as a separate IEC 61850 IED in each system (project), needing its own IED tool.

The teleprotection equipment communicates with the IEC 61850 IEDs in the substation by means of IEC 61850, typically GOOSE or SAV type of service, i.e. it is an IEC 61850 IED within each of the substations. To retain the semantics of the communicated signals, here the proxy gateway approach is used, which works like this (see also Figure 28):

• Each end of the teleprotection is a client (ITCI logical node), which receives the DATA to be sent and used in the other substation(s).

• These DATA to be sent to the other substation are mapped onto a proxy gateway data model within the other substation; e.g. substation AA1 contains a proxy GW for substation AA2 and vice versa, if data flow is bidirectional.

• The data model of the proxy contains as image all those logical devices and logical nodes from IEDs at the other side, which contain data to be used in the receiving substation (e.g. all LDs from the IEDs, which would have been exported with dataflow right in the previous method). This could be defined by analysing the data to which the proxy subscriber has been configured as client in the source substation, or as a separate proxy engineering step, which then at the end generates this client data flow. Together with the logical devices also the part of the substation section to which the LNs to be used are bound, should be put into the proxy IID file.

• The proxy has an own LPHD logical node, which shows its state and by means of the (new) RTPC logical node also the state of the wide area communication link.

• The proxy defines a message (typically GOOSE or SAV, but also reports are possible) by gathering the data communicated for use in the receiving substation into a data set, allocated to a (GOOSE, SV or report) control block.

• Based on this message definition the client/subscriber at the sending substation, which could be a part of the corresponding proxy or a separate (client) IED, connects its client/subscriber input signals to the corresponding channels and message bits on the wide area connection. It is recommended to use the proxy data model’s sAddr attributes or the ITCI client’s intAddr attribute (or both) to identify the telecommunication signal used for transfer.

The proxy logical devices and their kept references to the substation section define the source meaning of the data for the destination SA system, and define which signals to receive, to transfer via the wide area connection, and to map to the possibly predefined (GOOSE or SAV) telegram at the source substation. This works even for simple proxies, which can only send a fix GOOSE data set, by assuring in the teleprotection IED tool, that only data from the LD with a matching data type is mapped to the appropriate preconfigured GOOSE signal.

Naturally, for high speed connections the proxy method has the disadvantage that it defines a further (proxy) IED, which might introduce delays. On the other hand it might be implemented replacing the switch coupling to the WAN connection in the high speed scenario, so that in reality the performance loss will be small or even zero.

– 82 – 61850-90-1/DTR © IEC(E)

Figure 31 – Proxy gateway method (AA1F3, AA2F3 are Proxy gateways)

Above figure assumes, that data has to be sent from substation AA1 to AA2, represented there in the proxy IED AA2F3, as well as the other way round, there represented locally in AA1 at the proxy IED AA1F3.

The subscriber IED can either be considered the (ITCI) client part of the Proxy IED, or can be considered to be an own IED, which then must have an own IED name to configure sending DATA to it.

As the proxy SCL files look from SCL point of view like any other proxy gateway files, there is no example given. After the IID SCL file for the proxy has been generated from the SCD file of the other substation, this can be included into the project like any other IED’s ICD or IID file, and configuring the subscriber is done with the Proxy’s IED tool. All in all this is a three step system engineering process for each substation, flowed by the proxy IED engineering step:

a) Engineer the system without proxy gateway. b) Generate the proxy GW IID file for substation AA1 from the SCD file from substation AA”

and vice versa. c) Include the generated IID files into the systems, and finalize the data flow engineering. d) Use the proxy GW IED tool to configure the teleprotection IED(s).

11 Bibliography

[1] Cigre report, Protection using Telecommunications, CE/SC 34 34/35.11, 2001, Ref. No. 192

____________

AA1F2 AA1F1


AA2F2 AA2F1


Substation AA1 Substation AA2

Wide area connection, hidden behind proxies

AA1F3

AA2F3Subscriber

Subscriber

Publisher

Publisher

Documents

57-61850-90-1-DTR