IEC TC 57 Just Published Draft IEC TS 618540-1-2 - Extending IEC 61850

IEC TC 57 just published the 43 page draft 57/2084/DTS:

Communication networks and systems for power utility automation IEC 61850-1-2 -
Guideline on extending IEC 61850

CLOSING DATE FOR VOTING: 2019-06-07

Excerpt of the draft:
------------
1 Scope
This document is intended for any users but primarily for standardization bodies that are considering using IEC 61850 as a base standard within the scope of their work and are willing to extend it as allowed by the IEC 61850 standards. The document identifies the required steps and high-level requirements in achieving such extensions of IEC 61850 and provides guidelines for the individual steps. Within that scope, the document addresses the following cases:

• The management of product-level standards for products that have an interface based on IEC 61850
• The management of domain-level standards based on IEC 61850
• The management of transitional standards based on IEC 61850
• The management of private namespaces based on IEC 61850
• The development of standards offering the mapping of IEC 61850 data model at CDC level
• The development and management of IEC 61850 profiles for domains (underlying the role of IEC 62361-103 and IEC 61850-7-6)

The document includes both technical and process aspects :
On the technical side, the document:

• Reminds the main basic requirements (mostly referring to the appropriate parts of the series which host the requirements or recommendations)
• Lists all possible flexibilities offered by the standards
• Defines which flexibilities are allowed/possible per type of extension cases

On the process side, the document covers:

• The initial analysis of how the existing IEC 61850 object models and/or communication services may be applied and what allowed extensions may be required for utilizing them in new or specific domains (including private ones). The results of that step are expected to be documented
• The extension of the IEC 61850 object models for new domains. The typical associated work is to identify existing logical nodes which can be reused “as is”, to determine if existing logical nodes can be extended, or to define new logical nodes
• The purpose and process to use transitional namespaces, which are expected to be merged eventually into an existing standard namespace
• The management of standard namespaces
• The development of private namespaces

---------------

It is highly recommended to have a closer look at this document and review the content in detail. Because in the end it will be used as a very crucial "cook-book" for those that need to extend the standard series IEC 61850 and IEC 61400-25.

IEC TC 57 Publishes Draft for Basic Application Profiles (BAPs)

IEC TC 57 just published Draft for Basic Application Profiles (BAPs):

Development of IEC TR 61850-7-6 (57/1946/DC):
Communication networks and systems for power utility automation
Part 7-6: Guideline for definition of Basic Application Profiles (BAPs) using IEC 61850

Different types are possible:

1. User profile –defined subset that is valid for a specific user / community of users (e.g. utility)
2. Domain profile - defined subset for a specific domain and relevant use cases (e.g. asset management)
3. Basic Application Profile (BAP) – standardized subset defining an atomic application function (e.g. reverse blocking)
4. Application profile - profile covering a specific application mostly based by aggregating BAPs e.g. busbar protection)
5. Device profile – profile covering a typical IED functionality e.g. Merging Unit, IEC 61869-9)
6. Product profile – implemented subset in a specific vendor product

Comments on this draft are due by 2018-01-19.

ENTSO-E Just Published a New Update on Activities Related to IEC 61850

ENTSO-E is actively supporting the application of IEC 61850.

They believe that "The IEC 61850 Standard for the design of electrical substation automation addresses many crucial aspects of TSO communications, data modeling and engineering in order to reach seamless interoperability of different vendors’ subsystems within the TSO system management architecture."

ENTSO-E published an Update on their activities related to IEC 61850 in July 2017.

ENTSO-E Ad Hoc Group IEC 61850 continued to intensively work on the improvement of the IEC 61850 standard interoperability on two main domains:

1. At information level (data semantic), the development of the ENTSO-E profile through the Interoperability Specification Tool (ISTool)
2. At engineering level, by consolidating ENTSO-E requirements that have been formalized into a DC (Document for Comment), approved through the IEC National Committees (NC) voting process, and now encapsulated in the action plan of several task forces of the IEC TC 57 WG10

Click HERE for reading the complete the report.

Guideline for definition of Basic Application Profiles (BAPs) using IEC 61850

IEC TC 57 has published a document for comments (57/1813/DC, 27 pages) on application profiles::

Draft IEC TR 61850-7-6, Communication networks and systems for power utility automation –
Part 7-6: Guideline for definition of Basic Application Profiles (BAPs) using IEC 61850

Comments are expected by 2017-02-03

This guideline is focused on building Application / function profiles and specifies a methodology to define Basic Application profiles (BAPs). These Basic Application profiles shall provide a framework for interoperable interaction within or between typical substation automation functions. BAPs are intended to define a subset of mandatory features of IEC 61850 in order to increase interoperability in practical applications.

In the context of standards the term “profile” is commonly used to describe a subset of an entity (e.g. standard, model, rules).
Accordingly an IEC 61850 standard profile contain a selection of data models (mandatory elements), communication services applicable and relevant engineering conventions (based on the Substation Configuration Language SCL defined in IEC 61850-6) for an application function of a specific use case in the domain of power utility automation.
Depending on the scope and objective different profile types can be distinguished:

• User profile – defined subset that is valid for a specific user / organization (e.g. utility)
• Product / Device profile – implemented subset in a specific vendor product /device
• Domain profile – defined subset for a specific domain and relevant use cases (e.g. monitoring of substation)
• Application / function profile

A nice example is contained in Annex A:
Example for BAP of distributed automation function “reverse blocking” using BAP template

Basic Application Profiles (BAPs) using IEC 61850

IEC TC 57 has proposed to develop a new Technical Report (TR):

IEC TR 61850-7-6: Communication networks and systems for power utility automation –
Part 7-6: Guideline for definition of Basic Application Profiles (BAPs) using IEC 61850
(57/1782/DC)

The proposed work will:

• describe the methodology of profiling in the context of IEC 61850
• give a common understanding about the modular profiling concept of basic application profiles (BAP)
• define the contents of a standardized basic application profile (BAP template)
• give guidance for the use of that BAP template
• and also show an example of a BAP.

Just published: Draft Technical Report IEC 61850-90-17 (Using IEC 61850 to transmit power quality data)

IEC TC 57 just publsihed the Draft Technical report (57/1676/DTR):
IEC 61850-90-17 TR: Communication networks and systems for power utility automation –
Part 90-17: Using IEC 61850 to transmit power quality data
Voting terminates on 2016-04-08

This document provides
• Guidelines for using of IEC 61850 in the power quality application domain,
• Name space extensions required for power quality function assessment,
• Profile for using IEC 61850 in the specific context of IEC 61000-4-30.
Specific Power Quality requirements that are not 100 % covered by existing Logical
Nodes (LN) or Common Data Classes (CDC) (e.g. LN for continuous power quality recorders,
LN for RVC…) are defined here.
The document defines a lot of configuration values for specific applications. This document helps to increase the interoperability to a high degree.

This document will serve as a very helpful Guideline in the Power Quality Domain.
Power Quality devices produce huge amounts of values .. these must be communicated with a variety of services: Read, Report, Log, or Files like COMTRADE, PQDIF, or COMFEDE. This TR discusses these for the various applications.

Deutsche Gasversorgung nutzt Profil für IEC 60870-6 TASE.2

20 Jahre nach der Veröffentlichung der Normenreihe IEC 60870-6 TASE.2 (ICCP) ist das Thema TASE.2 bei der deutschen Gasversorgung immer noch hochaktuell! Das wird sicher auch für die nächsten 20 und mehr Jahre so sein!

IEC 60870-6 TASE.2 basiert auf derselben Basistechnologie wie IEC 61850 und IEC 61400-25: MMS (Manufacturing Message Specification, ISO 9506). MMS ist aus dem MAP-Projekt Mitte der 80er Jahre hervorgegangen.

Der DVGW-Arbeitskreis „Standardisierung des Informationsaustausches zwischen Dispatchingzentralen“ empfiehlt für den Austausch von Prozessdaten den Einsatz des „Telecontrol Application Service Element Two“ (kurz TASE.2).

Die Spezifikation des TASE.2-Standards zum Einsatz zum Prozessdatenaustausch zwischen Leitzentralen der Gaswirtschaft sowie einen Leitfaden zur Anwendung finden Sie in der DVGW Gas-Information Nr. 18 "Prozessdatenaustausch zwischen Leitzentralen der Gaswirtschaft auf Basis von TASE.2" , Ausgabe Februar 2012.

Der Leitfaden gibt einen Überblick über die wichtigsten Merkmale und Funktionalitäten von TASE.2 und die konkrete Anwendung von TASE.2 im Extranet der Gaswirtschaft. Der Leitfaden kann auch als Profil verstanden werden. Von der Vielzahl der Möglichkeiten der TASE.2 werden die Definitionen ausgewählt, die für den Anwendungsbereich zu verwenden sind – um einen hohen Grad an Interoperabilität zu erreichen.

Hier klicken, um die DVGW Gas-Information Nr 18 herunterzuladen [pdf, nur lesbar]. Eine druckbare Pdf-Version kann erworben werden.

Vor 15 Jahren haben die an der Normung beteiligten Experten den folgenden Report veröffentlicht:

etz-Report 32
Open communication plattforms for telecontrol applications:
benefits from the new standard IEC 60870-6 TASE.2 (ICCP)

Einige Exemplare des etz-Reports 32 stehen noch zur Verfügung und werden kostenlos abgegeben.

Die hier beschriebene Profil-Bildung sollte auch für IEC 61850 in anderen Anwendungsbereichen zum Vorbild dienen! Dafür werde ich mich verstärkt einsetzen.

A REFRESHER ON THE “STANDARDS CONTINUUM”

Erich Gunther, Aaron Snyder and Grant Gilchrist, EnerNex have published an interesting article in the SGIP Newsletter, Volume 6, June 2014 Issue:

A REFRESHER ON THE “STANDARDS CONTINUUM”

Their Conclusion is right:

“Often misapplied, the term “standard” is truly only applicable in certain situations. The author of this piece advocates reserving the use of “standard” for de jure standards, especially when employed without the "de jure" modifier. There may appear to be little harm in referring to de facto "standards" simply as “standards,” but this actually dilutes and confuses the definition in the manner that the term "engineer" is often misapplied to functions requiring no engineering education or certification. For example, in these cases, it is preferable to use the applicable term of "specification," "requirements" and "requirements specification" instead of "standard."”

Click HERE for the full article.

So far so good. There are other languages that differentiate between “Standard” and “Norm”, like in German. German “DIN Standards” are specifications that are reflecting a document that has been published with lower hurdles than a “Norm”. The “DIN Norm” compares to the de-jure Standard.

The reality is more complex than just to differentiate between de-jure Standards and other documents. The (de-jure) Standards have to be extended in many cases by non-de-jure Standards: e.g., Implementation agreements that can be written by a Two-party (two vendors, one vendor and one user, one vendor and one testlab, …), an Alliance, Users Group, or standardization bodies.

The future power delivery systems will need many combinations of de-jure (Base) Standards and non-de-jure Documents (Implementation agreements, Profiles, … and even Green-Tissues-List as in case of IEC 61850, IEC 61400-25 – these are documents that are refer to de-jure Standards).

In the end of the day, we want to get interoperable devices to build multi-vendor automation systems for the future power delivery system! Or?

In case of IEC 61850 I see a lot of pressure to come up with more “official” Implementation agreements or Profiles that are agreed by more than two parties, two companies, or two experts.

One good example is the VHPReady Industrieforum.
Click HERE for the current Specification 3.0 in English.

This is a good starting point – it’s not yet the final result … to expected early 2015.

IEC 61850 Profiles and associated Interoperability Tests for Hydro Power Plants

Hydro Power Plants require very complex information models and information exchange services. IEDs are usually acting as client and server in order to receive and send comprehensive reports. The suite of hydro power standards in the series IEC 61850 (IEC 61850-7-510, IEC 61850-10-210, …) define therefore many application specific naming elements like logical device names, prefixes and suffixes of logical nodes and complete data sets (additional means, e.g., in addition to IEC 61850-7-4).

These additional definitions reduce the number of options to a good extent! It helps to reach a high level of interoperability.

IEC 61850-10-210 TS:
Communication networks and systems for power utility automation - Part 10-210: IEC 61850 Interoperability tests – Hydro profile

See document 57/1468/CD 
Commenting closes 2014-08-08

The hydro experts in IEC 61850 have understood that Profiles are an absolute MUST if we want to reach interoperability! A simple (but good) example is the Implementation Guideline “9-2LE” of the UCA Usersgroup.

Another good example of profiles can be found at the VHPReady Website:

http://www.vattenfall.de/de/file/VHP-READY-3.0-englisch.pdf_30408907.pdf

This specification contains two profiles:

1. IEC 60870-5-104 (with all signals specified)
2. IEC 61850 (with all signals specified)

Vendors can not just rely on IEC 61850 and define their own instance models of the needed logical nodes. The logical device names, prefixes and suffixes of logical nodes and complete data sets are already defined – to prevent use of options!!

What are the Benefits of IEC 61850?

The question “What are the benefits of IEC 61850” has different flavors and multiple answers – it depends on what are you looking for. If you are looking just at the communication protocol, there are answers like:

1. The client/server protocol (MMS) is a unified solution standardized some 25 years ago. It is a stable standard – unlikely to change in the future and accepted all over for many years.
2. The GOOSE messaging is very unique and provides real-time information exchange in the msec range – accepted all over
3. The Sampled Values messaging provides a unique solution for exchanging samples of currents, voltages, vibration measurements accepted all over.

If you are looking at the information models, there are really many crucial models defined and in use. No other standard (I am aware of) has such a rich set of information models that expose process information in a standardized way – all over accepted.

There is – of course – the crucial issue on the configuration language. In this post we will discuss the benefit of a unified model that allows to hide the different vendor-specific signal lists for Modbus communication in two different power quality meters. In the end, the unification of specific information profiles (or subsets) for, e.g., the electrical measurements makes IEC 61850 different compared to any other solution I know.

The power quality monitors used are: Janitza UMG 604 and Acuvim II. Both meters provide many measurements of the electrical system. The signals can be communicated by Modbus. Usually each vendor has a different approach to define the lists of signals – and especially the indexes used for the vary same signal is quite different and have to be mapped manually to any application – again and again. There is no way to agree on a single unified Modbus signal list that can be applied all over. The next figure shows the two devices, their signal “phase voltage” with different identifiers and indexes.

The unification of the information model is implemented in a simple gateway (com.tom BASIC 5.1). The gateway is based on a WEB-PLC that maps the incoming Modbus signals to IEC 61850 models. The IEC 61850 model uses the same logical node class and type. The type MMXU_0 is the subset of the MMXU class used in this application (of four data objects – as can be seen in the icd file). The instance MMXU1 can easily be “copied” to build a second instance: for the Acuvim II meter. Both instances use a unique MMXU logical node type (contained in the icd file). The model can be used to configure the IEC 61850 server device and an IEC 61850 client (in this case the IEDScout) as shown in the next figure.

The gateway solution is reasonable in case just a limited number of applications need the information communicated by IEC 61850.  The next step could be to integrate the “gateway” into the meter housing, as shown in the next figure:

The “heart” of the gateway (we use) is the Beck IPC@CHIP controller that could be applied as a subsystem in the meter. It manages the complete IEC 61850, IEC 61400-25, IEC 60870-5-104 or DNP3 communication.

The IEC 61850 models are the same as before in the case of using a separate gateway box. From a client point of view there is only one difference: there are two IP addresses and two IED names to take into account.

The configuration of the client could benefit from the unified information model contained in a standardized machine readable format (.icd). When you google for power meters with a Modbus interface (or any other fieldbus-like) interface you will get as many different signal list as solutions. In our case we can easily unify the information that comes from many different meters.

By the way, the unified model can be fed not only by a Modbus communication interface. Any other signal list communicated by the myriad of solutions could easily be unified! It does not matter how many different protocols you have to take into account – the very same IEC 61850 profile could serve them all. Define it once and use it for ever and all over.

The WEB-PLC based solution explained here is available – I have tested the concept with several devices: meters, monitoring devices, control devices. This approach could be applied right away – and you pay while you go. To get started with a extra box is in the range of some hundred Euro plus some time to understand the approach and learn how to get started with the product. The IPC@CHIP including IEC 61850 client and server (GOOSE and SMV), IEC 60870-5-104 server, and Modbus client costs less than 100 Euro – too cheap to ignore.

Let people define new protocols and … IEC 61850 can unify them all! The next days I will post a report on a hierarchical system with a Janitza UMG 604 and fan heater as the process, a com.tom device to monitor and control the process (with an IEC 61850 server), an a com.tom on top that could be used as a (proxy) gateway to the underlying com.tom (providing an IEC 61850 client, IEC 60870-5-104 server and an IEC 61850 server). The gateway interoperates in a plug&play manner with the underlying IEC 61850 IEDs.

I don’t fear the following situation:

nor this …

It is a change for IEC 61850 to unify the proliferation!

More to come shortly – stay tuned to this blog.

I had to wait almost 30 years to have a real simple and easy to use “MAP” solution running on my desk:

The MAP/TOP Demonstration in 1986 was too early! Definitely!

New VHPReady Industrieforum to push IEC 60870-5-104 and IEC 61850

The specification “Virtual Heat and Power” (VHPReady) has been developed by Vattenfall and published as Version 3. The specification is a profile for a specific application. It has gained crucial industry support. The specification is the major input for the newly established “Industrieforum VHPReady”  this week Wednesday during the E-World conference in Essen.

The Virtual Power Plant combines block-type combined heat and power (BCHP) plants and heat pumps to create an interconnected, flexible system with centralized control. It is the first power plant which is capable of generating power during heat generation using the connected BCHP plants while making good use of excess wind and solar electricity by way of heat pumps.

The two communication options are: IEC 60870-5-104 and IEC 61850.

Founding members of the Industrieforum are well known organizations and companies:
- Fraunhofer FOKUS
- 2G Energy AG
- 50Hertz Transmission GmbH
- Beck IPC GmbH
- Bosch Software Innovations GmbH
- Energy2market GmbH
- E.ON Connecting Energies GmbH
- IT&I GmbH
- LichtBlick SE
- Optimax Energy GmbH
- PHOENIX CONTACT Electronics GmbH
- SSV Software Systems GmbH
- Vattenfall Europe Wärme AG
- WAGO Kontakttechnik GmbH & Co. KG
- Younicos AG

Download the VHPReady 3.0 specification in English [PDF, 650 KB] and in German [PDF, 650 KB].

Some discussions can be found here:

• English Version of Vattenfall’s “VHP READY – Virtual
  Heat & Power Ready” available
• Is IEC 61850 still there?
• IEC 61850 ready for VHP-Ready (Virtual Heat and
  Power Ready)

Security and IEC 61850: Is it about Bug Fixes or Systematic Issues?

These days experts discuss the future of more secure IEDs and systems in the world of Industrial Control Systems (ICS). Note: ICS is also used in power systems – no question.

There are people that focus on single bugs and how to solve them by patching et cetera. Other experts are more looking at the systematic security problems in control systems.

Eric Byres, CTO and vice president of Tofino Security, a division of Belden, says “It will take major players like Exxon, Duke Energy, for instance, and other corporations with the ICS purchasing power, he says, to force vendors to step up and fix the systemic security issues."

Read a comprehensive discussion about the two positions – quite crucial and interesting.

What do you think about translating this statement into the issues we have with IEC 61850 Interoperability?

It will take major players like AEP, SCE, E.ON, EDF, RWE, Duke Energy, for instance, and other corporations with the ICS purchasing power, to force vendors to step up and fix the systemic interoperability issues with regard to IEC 61850."

This would help to prevent a lot of frustrations during factory and site acceptance tests.

Why do we see just a few major players from the utility domain using their force to improve interoperability? There are several reasons I see:

• Wall Street, Frankfurter Börse, …
• Ignorance of issues
• Not enough experts
• Attitude: just fix what brakes
• …

Recommendation from my side: Vendors and users should cooperate more in Teamwork and agree on writing documents like “How to profile IEC 61850, IEC 60870-5, …” to get specific profile specifications for a specific application that have (hopefully) not left options to ignore or to chose from.

A good example is the Vattenfall VHP Ready specification (Virtual Heat an Power). This spec defines the IOA for signals according to IEC 60870-5-104 and the Logical Device, Logical Node and Data Object Names.

Example 104:

Example IEC 61850:

If utilities do not specify what they want, they may experience a big surprise when they get the system delivered and installed. They may get much less or much more than what they expected.

And note this: When we get more standard conformant and interoperable IEDs installed, they are definitely linked to the Security issues discussed at the beginning!

What we are looking for is: Interoperable and Secure IEDs and Systems. We should not separate these two requirements! They are highly interrelated.