Post on 04-Aug-2020
transcript
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