Multi-Vendor Interoperability

Julio E. DominguezSGTech Europe 2015, September 2015

Current issues and prospects

CONTENTS

1. Gas Natural Fenosa: a short introduction

2. Why multi-vendor SAS?

3. Why IEC 61850?

4. IEC 61850 Edition 2 – SAS management remains unsettled

5. Preventing SAS management issues: some guidelines

6. Sanxenxo substation

7. Recapitulation

Gas Natural Fenosa: a short introduction

3

Gas Natural Fenosa: a short introduction

4

• Presence in over 30 countries

• EBIDTA: 4,853 M€ ; assets: 50,328 M€

• Electric power generation + liquefied gas transport + gas distribution + electric power distribution

• Power distribution in Spain:

• Two geographical areas (central & northwest)

220 kV to 400 V400 primary (HV) substations40,000 secondary (MV to LV) substations

• SCADA system for power distribution:

87,000 digital signals4,200,000 analog signals

www.gasnaturalfenosa.com

Why multi-vendor SAS?

5

Why multi-vendor SAS?

6

Why would an utility like to supply itself from multiple vendors?

1) Keep them in competition with one another

2) Get from each one whatever it can do best

3) Allow for partial update to better technology

Why multi-vendor SAS?

7

Substation A SAS by vendor X

Substation A SAS by vendor X

The Multi-vendor Utility, Single-vendor SAS (MUSS) approach

Substation B SAS by vendor Y

Substation B SAS by vendor Y

Substation C SAS by vendor Z

Substation C SAS by vendor Z

1) Keep them in competition with one another - YES2) Get from each one whatever it can do best - NO3) Allow for partial update to better technology - NO

Control Centre

Why IEC 61850 ?

8

Why IEC 61850?

9

A survey among SAS managers: why are you going into IEC 61850?

1) Because it is cool, ballyhooed and fashionable technology

2) Because the market will sooner or later force me to do so

3) Because I have assessed overall SAS costs in the long termand found IEC 61850 advantageous

Which group would YOU like to be in?

Why IEC 61850?

10

IEC 61850 contains three standards:

1) A set of protocols for IED-to-IED communication:

i. Client/server servicesii. GOOSEiii. Sampled Values

1) A specialized data model

2) An XML-based configuration language: SCL

Why IEC 61850?

11

• Single-vendor substations do not require international standards for IED-to-IED communication.

• Multi-vendor substations do require such standards, but...

1) There are alternatives for client/server communications

2) GOOSE and Sampled Values have only one alternative, but it is a reliable and well-proven one!

IED-to-IED communication is unlikely to be the driver for IEC 61850

Why IEC 61850?

12

However...

... another IED (or the Control Center) is not the only thing an IED inter-operates with.

• What about SAS management ?

• It usually involves large amounts of the company’s most expensive assets: staff and knowledge

Control Centre

single-vendorSAS

multi-vendorSAS

management applications

13

• Engineering• IED configuration• Device supervision• Incident analysis• Firmware update• Virtual testing• Standalone testing

Examples of information exchange beyond IED-to-IED communication:

All these tasks:

• Are necessary• Reside above the substation level• Demand lots of staff hours• Are about as complex under the MUSS approach• Can only be largely automated if based on standards

Why IEC 61850?

System Configurator

14

Example 1: the System Configurator allows seamless, centralized engineering

IED from vendor X

IED from vendor Y

IED from vendor Z

1) From ICD and SSD files, SCD file is created. It contains the whole SAS configuration

2) SC exports SCD (or CID) file into IEDs

IEC 61850 standard data exchange

ICD files

CID file

• engineering becomes genuinely top-down and seamless

• maximum efficiency is achieved

• specific vendor tools no longer needed (for regular engineering tasks)

• allows virtual test of the SAS

• consistent documentation source

CID file CID

file

ASSUMPTIONS:

1) all config parameters (even those for non-interop functions) are IEC-61850-modelled, SCL-coded and understood by IED

2) all subscriptions are coded in CID file and understood by IED3) programmable logics are standard-coded in CID file and understood by IED

Why IEC 61850?

SSD file

SCD file

CIM description

of substation

15

Example 2: Incident Analysis Tool

Why IEC 61850?

Incident Analysis Tool

RDRS# Logs

IEC 61850 standard data exchange

Substation Gateway

bay IED

COMTRADE records

RADRLogsCOMTRADE

recordsRBDR

RDRE

PTOC

PDIS

PDIF

read/controlread/control

16

Example 3: Automatic Software Interlocking Tester

Why IEC 61850?

Software Interlocking

Tester

Bay_#/X_CILO1.EnaClsBay_#/X_CILO1.EnaOpn

IEC 61850 standard data exchange

Substation Gateway

(other bay-level IEDs)

Bay_#/X_CSWI1.Pos

(other)_CSWI1.Pos

(other)_CSWI1.Pos

X_CILO1.EnaClsX_CILO1.EnaOpn

bay-level IED at Bay #

X_CSWI1.Pos

(other)_CSWI1.Pos

17

Conclusions:

• Automation of many SAS management tasks is the next wave of SAS improvement.

• Utilities are expected to invest large sums in such added-value applications.

• These applications naturally reside above the substation level.

• ROI will be highly sensitive on the availability, across the whole utility, of standards encompassing much more than IED-to-IED communication.

• The MUSS approach provides no advantage.

• SAS management, not SAS operation, is the real driver for a migration schedule to IEC 61850.

Also look beyond and above the Control Centre and SAS management: the Common Information Model (CIM), etc.

Why IEC 61850?

18

IEC 61850 Edition 2 -SAS management remains unsettled

IEC 61850 Edition 2 – SAS management remains unsettled

19

Good:

• Protocol interoperability issues becoming less and less commonplace

• GOOSE reliability no longer a concern in well-designed LANs

• Acceptable backward compatibility in Edition 2 devices

• Light universal clients are highly usable and convenient

20

IEC 61850 Edition 2 – SAS management remains unsettled

Bad:

• GOOSE subscription: ‘implicit OR’ not supported

• Free parts of data model (LD name, LN prefix, RCB name, etc.) cannot be customized by user

• Too much GGIO/GAPC instead of semantically-specific names

• Special modes not available: blocked, test/blocked, test; no substitution model, no LOGs

• No standard definition (IEC 61131) for logics

• Many IED designs show reluctance towards open TCP/IP access

• Most protection IEDs still in Edition 1 (no InRef, ExtRef, etc.)

• Enhancement of Part 7-4 not undertaken (definition of more DOs e.g. a 3-position disconnector)

• Configuration parameters not modelled not exposed to the System Configurator

• Restricted use of SCL by IEDs/ IED tools

• Role of the System Configurator remains awkward: it cannot ‘figure out’ what it is (not) expected to do

Highly inefficient SAS management (including SAS engineering/configuration)21

IEC 61850 Edition 2 – SAS management remains unsettled

Semantic adherence to the data model:

• RSYN#.Rel for synchronism presence

• ATCC#.TapChg for tap changer position publishing/changing

• RREC#.Mod for enabling/disabling an auto-recloser

• RREC#.AutoRecSt for auto-recloser status

• RBRF#.OpEx for breaker failure trip-other-bays condition

• PTOC#.Op for timed overcurrent protection trip

• CSWI#.CmdBlk for an 86-relay-like software blocking

• LLN0.Loc for bay in local status

... too often neglected in favour of unspecific GGIO/GAPC

22

IEC 61850 Edition 2 – SAS management remains unsettled

Conclusions:

• Enough progress in the protocols

• Scarce progress in data model and SCL compliance

• No solid basis for SAS management applications (including centralized engineering)

• Utility is expected to buy all tools/applications from same vendor (???)

• Or use one tool for each vendor (???)

• Many vendors seem to be lagging behind. Why?

23

IEC 61850 Edition 2 – SAS management remains unsettled

24

Preventing SAS management issues:

some guidelines

Preventing SAS management issues: some guidelines

• Always keep in mind the whole picture.

• Keep your designs simple.

• Remember: cost-efficient management is as important as reliable operation.

• SAS-related tasks can be much more intensively automated than they are today.

• Do not restrict your data modelling to the bay level.

• Choose vendors with a strong, proven commitment to standards such as as IEC 61850 and CIM data models, SCL, IEC 61131, TCP/IP communications.

• Select IEDs having all their configuration data modelled, so that they can be entirely SCL-configured.

• Keep your staff skilled, keep your skilled staff.

• Be ambitious!

• E3 Group specifications: https://sites.google.com/site/e3groupiec61850

25

Sanxenxo substation

26

27

Sanxenxo substation

66 kV to 20 kV GIS distribution substation

28

Sanxenxo substation

local IHM SCU

P&C

21/87 protection

Micro-RTU

binary I/OV (0,5) I (5P20)

binary I/OV (3P) I (5P20)

Meter

V (0,5) I (5P20)binary I/O

GOOSE GOOSE

GOOSEOTHER BAYS

reporting

reportingreporting

reporting

command

command

conventional binary/analogIEC 61850-8-GOOSE

IEC 61850-8-MMSother protocols

DLMS

CONTROL CENTRE

ENERGY BUDGETTING

WANIEC 60870-5-104

29

Sanxenxo substation

substation 66 kV 20 kVbay-level 50/51/67N protection & control --- ZIV 7IRV ZIV 7IRV

micro-RTU for remote control --- ARTECHE BCU ARTECHE BCU

line 21 protection --- SCHNEIDER MiCOM P442 ---

transformer 87 protection --- ZIV 8IDV ---

SCU SCHNEIDER --- ---

SAS equipment

30

Substation Control Unit (an intelligent substation gateway)

Sanxenxo substation

1) Performs protocol conversion (when needed)• IEC 61850 to IEC 60870-5-101/104

2) Performs data model conversion (i.e. isolates non-data-model-compliant IEDs from the upper levels)

3) Reduces communication overhead for both clients and servers

4) Provides application-level security: • access authentication• command integrity and safety (interlocking)

5) Provides substation-level automation: • controls transformer OLTC (ATCC logical node)• under-frequency load shedding• event logging• basic protection? (future, based on sampled values)

6) Incorporates IEC 61131 programmable logics for further function development

31

But is the SCU not a client? How then can I model it?

EASY: just as if it were a server!

Advantages:

1) The SCU can be an IEC 61850 SCADA server (i.e. to Control Center or local HMI)

2) It can be managed by a client (e.g. a light universal client)

3) It can be fully configured by an SCL file

4) Implementing new applications on the SCU is straightforward, since you already have all data modelled

Sanxenxo substation

32

Data-model handling at the SCU:

Sanxenxo substation

Implicit mapping = no conversion needed = “the same maps to the same”

IEC 61850 data modelling

SCU

bay-level IED

Control Centrenon-IEC 61850 data modelling

PRI 220 204 SBA

PRIUCS1_PRI_220_204 /SBA_CSWI1.Pos.stVal

PRI_220_204_VENDOR_CTRL_PRI_220_204 /SBA_CSWI1.Pos.stVal

33

Data-model handling at the SCU:

Sanxenxo substation

Explicit mapping = mapping GGIOs to semantically-proper data objects

IEC 61850 data modelling

SCU

bay-level IED

Control Centrenon-IEC 61850 data modelling

PRI 220 204 SBA

PRIUCS1_PRI_220_204 /SBA_CSWI1.Pos.stVal

PRI_220_204_VENDOR_CTRL_PRI_220_204 /GGIO1.Ind#.stVal

<Inputs><ExtRef><RptEnabled><ClientLN>

34

Next steps:

Sanxenxo substation

1) Configure bay-level IEDs entirely from System Configurator

2) Use CIM-like SSD file + bay-type ICDs as only inputs to System Configurator (no more Excel sheets!)

3) Eliminate IEDs requiring proprietary configuration tools/methods

4) Build and commission new IEC 61850 substation at Urda

5) Develop new substation/bay template models based on Sanxenxo-Urda experience

6) Develop/enhance added-value applications based on IEC 61850 data model:

engineering/documentation incident analysis automated testing etc.

35

Recapitulation

Recapitulation

1) Multi-vendor is better than single-vendor, if SAS management issues are kept under control.

2) This requires simplicity and strong compliance with international standards.

3) Specify your requirements carefully

36

37

Muchas gracias

jdominguezc@gasnatural.com