IEC 61850 Has Come A Long Way Since February 1995 - 30 Years

The development of an IEC Standard on "Substation Control and Protection Interfaces" (which is now IEC 61850) was discussed during the IEC TC 57 meeting in Sydney (November 1993). The Ad-hoc group „Substation Control and Protection Interfaces“ (led by Dr. Reiner Speh, Germany) was tasked to come up with a proposal. The result was published as:

IEC 57/214/INF Report of the Ad-Hoc Working Group on Substation Control and Protection Interfaces, February 1995

This report covers the work of the Ad-Hoc Working Group from March 1994 to April 1995. The group was formed in November 1993 and consisted of 24 members from 12 countries. Four meetings where held in the time period and the results of the work provided the bases for forming Working groups 10, 11, and 12. 

Sources: TR 61850-1 (2003) and etz-Report 34  (Offene Kommunikation nach IEC 61850)

Three new work proposals (NP) have been proposed in February 1995 (57/210, 57/211, and 57/212). The acceptance of these NPs led to the new TC 57 working groups WG 10, WG 11, and WG 12 ...

The IEC 61850 standardization started 30 years ago - congratulation! I am involved since the very beginning in 1995!

What happend in the global market? A lot of discussions, complaints, ideas, benefits, success stories, ... ignorance, ... misinterpretations, disconnects, ... until today.

BUT wait: I guess the series IEC 61850 is accepted, planned and decided to be used, or already in use in many applications globally. It is interesting to check this blog what I have reported many years ago:

Wednesday, August 27, 2008 / Siemens sold more than 1000 plants with IEC 61850
Wednesday, November 5, 2014 / IEC 61850 Devices installed worldwide by Siemens: 300.000 (the incorporated links to Siemens websites are not working anymore)

There is no need in the year 2025 to count the number of IEDs or systems that implement IEC 61850 ... I just came about an interesting video published by CONDIS Group (Webinar on IEC 61850 Standardisation) the other day. Additional information ... on how many substations at Tennet (TSO in the Netherlands) will be refurbished with IEC 61850 ...

One reason why this all happens is here: my personal involvement ... and training all over ... as you may know: I am one of the great grandfathers of the standard series IEC 61850 and IEC 61400-25. 

By the way, I am a great grandfather in the real life as well! ... and a gray hair engineer ...

Any question?

Why Do We Need IEC 61850 (SCL) Based System Configuration Descriptions?

IEC 61850 has been developed in the late 1990's mainly by protocol experts and protection engineers - results are well done and applied all-over. Later IEC 61850-6 (SCL - Substation System Configuration Language) was in the focus. Now, 30 years later the industry has learned that the System Configuration Description goes far beyond information models and communication networks and services - AND PROTOCOLS. The crucial aspect is about a COMPLETE description of the WHOLE system ... from device independent descriptions of Functions and Function Models applying a Top-Down-Modeling-Approach. Work towards this approach is going on in several projects, e.g., IEC 61850-90-30 (IEC 61850 90-30 – IEC 61850 Function Modeling in SCL). A nice description from Jörg Reuter (Helinks) can be found HERE from the pacworld magazine. IEC 61850 based aspects is - of course - just one (crucial) aspect of a system. There are more aspects ... like Hardware, Software, Cybersecurity, Operation, ...

In addition to getting a complete system specification based on SCL to get a running IEC 61850 based system that does the job you want to have ... there is another crucial aspect: Engineers may be happy to use a complete SCD file to configure everything and then forget the SCD file ... don't forget it BUT keep it up-to-date and NEVER EVER make any change in the system without updating the SCL based System Description! 

You may need the complete and updated SCD file to help you "protecting" yourself in case there is a damage or an accident ... when "a fleet of well dressed lawyers who will use the lack of that document to make you all look guilty after ..." may arrive immediately after ... as Jake Brodsky (a well known engineer) just published in an article about "Industrial Cybersecurity “Gatekeeping”" ... worth to read.

Here is one excerpt from his article: "Take the time to find out where the important documents are such as the Standard Operating Procedures, the chemical Safety Data Sheets, and especially the Control System Narrative documents are located. If you can’t find the control system narrative documents, stop. Get someone to agree to write them with you. This is effectively your contract with the engineers, technicians, and operators that indicates in plain language what is supposed to happen normally and in most upset conditions. If you’re operating without that living document you will all be fodder for a fleet of well dressed lawyers who will use the lack of that document to make you all look guilty after an accident."

What could be done to get and maintain such complete descriptions of various aspects of a system? Do we need more lawyers, politicians, engineers, ... ? 

I am kidding (just a bit): "Hire a lawyer to escort you when you have an interview for a new position as a responsible engineer in a utility or ... in order to figure out (by the right questions of the lawyer) that the company applies with what Jake Brodsky recommends!"

What we really need is more engineers ... gray-hair experts that know a lot about the systems ... that could write down what the systems do and how they work ... and that could train the young people ... BUT: it isn't easy to convince the management to let the engineers learn from the experienced, gray-hair experts ... gray-hair engineers could lead the horses to the water - but they cannot make to drink it. 

What do you think? Let me know!

KTH Royal Institute of Technology (Stockholm/Sweden) has some interesting things to say about IEC 61850

Andrea Bonetti (Megger) ... one of my best friends posted some interesting information at LinkedIn ... 

Here is a direct YouTube link to an informative interview mentioned in Andreas post: Welcome to episode 2, where Niclas Wetterstrand, Global Industry Director for Protection in Megger, talks with Lars Nordström, (PH.D, MSC.EE) professor in information systems for power system control at the KTH Royal Institute of Technology in Sweden about IEC61850 in the academic world.

The importance of the knowledge, the experience in this field, and the connections to the industry are some of the topics discussed in this interview.

In addition you can follow a discussion on LinkedIn about the many parts of the IEC 61850 series that are currently under development ...

Click HERE to find a list of the published parts of IEC 61850 with links to the preview of the 46 officially available parts ... with a total of 7,361 pages.

Tissue Database for IEC 60870-5 is now online

The industry asked for another tissue database for IEC standards. The other day the new tissue database for IEC 60870-5 went online:

https://iec60870-5.tissue-db.com/default.mspx

IEC 60870-5: "Telecontrol equipment and systems" ... a well known standard used in many applications globally.

Some discussion can be found here (60870-5, comparison with other solutions): 

https://blog.nettedautomation.com/search?q=60870-5

https://blog.nettedautomation.com/search?q=comparison

IEC 60870-5-1:1990
IEC 60870-5-2:1992
IEC 60870-5-3:1992
IEC 60870-5-4:1993
IEC 60870-5-5:1995
IEC 60870-5-6:2006
IEC TS 60870-5-7:2013
IEC 60870-5-101:2003+AMD1:2015 CSV
IEC 60870-5-102:1996
IEC 60870-5-103:1997
IEC 60870-5-104:2006+AMD1:2016 CSV
IEC TS 60870-5-601:2015
IEC TS 60870-5-604:2016 RLV

Do you know the PAC World Magazine? You should!

The PAC World Magazine - "Protection, Automation & Control World" - is a great global forum for the corresponding community:

https://www.pacw.org/

There you will find great discussions and use-cases on IEC 61850 ... and hints you don't find in the standards! 

Another source of background information is buried in the IEC 61850 Tissue Database:

https://iec61850.tissue-db.com/default.mspx

Enjoy!

Aktuell: Version 3.0 des Whitepapers "Anforderungen an sichere Steuerungs- und Telekommunikationssysteme"

"Der BDEW (Bundesverband der Energie- und Wasserwirtschaft) und seine österreichischen und schweizer Schwesterverbände (OE Oesterreichs Energie und VSE Verband Schweizerischer Elektrizitätsunternehmen) haben am 30.09.2024 eine vollständig überarbeitete Version 3.0 des Whitepapers "Anforderungen an sichere Steuerungs- und Telekommunikationssysteme" veröffentlicht. Das BDEW/OE/VSE-Whitepaper definiert grundlegende Sicherheitsanforderungen an Leit- und Automatisierungstechniksysteme der Energieversorgung und die zugehörige Nachrichten- und Telekommunikationstechnik."

Hier klicken, um zum Whitepaper zu gelangen.

Das Whitepaper ist ein gelungenes Anforderungspapier, das unbedingt beachtet werden sollte! Allerdings ist der Erfüllungsaufwand sehr hoch ... aber auch lohnend zu spendieren. 

Ich wünsche allen Beteiligten viel Erfolg!!

IEC 61850 Tissue Database Has Been Used to Publish The Second Set Of Tissues in Force

The IEC 61850 Tissue Database is an excellent tool helping to support a high level of quality. Tissues that affect interoperability will be put in force as batches, before an amendment of the standard can be done. They will then as well be required to be implemented for conformance testing.

70 Tissues related to 13 parts are listed in the second batch! Only 18 tissues are real interoperability tissues ... 57 are editorial tissues that improve the understanding of the various parts.

Click HERE to find the link to the first and second batch.

It is highly recommended to study the tissues in some detail ... many tissues (even those that have no impact on the interoperability) contain valuable discussions ... why is this and that done ... or not ... e.g., https://iec61850.tissue-db.com/tissues/1731 

Interoperability Assessment of IEC 61850 Devices in a Multivendor Digital Substation

 Researchers at the Karlsruhe Institute of Technology (KIT) presented a great paper at the IEEE GPECOM, June 2024, in Budapest:

Interoperability Assessment of IEC 61850 Devices in a Multivendor Digital Substation

"The present paper investigates interoperability challenges in multivendor digital substations, focusing on vertical data exchange reliability and Precision Time Protocol synchronization amidst various implementations of the IEC 61850 standard. The state of the art is examined through an Interoperability Testing Framework that assesses communication issues and data exchange across different equipment. Utilizing a two-phase bottom-up and top-down approach within this framework yields an efficient system deployment, focusing on synchronization, data exchange reliability, and addressing variations in IEC 61850 implementations, alongside a systematic literature survey. Results indicate that the proposed top-down engineering process can mitigate interoperability issues, promising streamlined future deployments."

Click HERE for more information ...

Whitepaper: OCPP and IEC 61850 - A Winning Team

DNV published a nice whitepaper on the use of IEC 61850 in conjunction with OCPP (Open Charge Point Protocol):

Excerpt:

"EXECUTIVE SUMMARY

In the coming years, utilities will see more and more electric vehicles connecting to their electricity grid. Cars, busses, vans, trucks, ships and airplanes will charge their batteries drawing energy from the grid. In some cases, these vehicles will also discharge their batteries and feed energy back into the grid, effectively becoming a Distributed Energy Resource (DER). It means that utilities will work together with new customers, systems and use cases. To integrate DERs safely into the grid, information exchange and control is needed. The IEC 61850 protocol for electricity grid control and OCPP for charging infrastructure control combine to ensure that the charging and discharging of vehicles takes place whilst ensuring grid stability and meeting the customers' needs and expectations.

Even though both protocols were developed by different industry groups in different periods of time, the combination of these two protocols can fulfil all requirements that utilities might have to control electric vehicles acting as DERs. The paper list use cases that a utility might use to control a DER, and shows for each use case which IEC 61850 settings to use and how these settings will be transferred to the charging station via OCPP.

This paper aims to help the industry better understand both protocols and help with the implementation of the combination of IEC 61850 and OCPP in charging station management systems."

Click HERE for the whitepaper (59 pages, PDF, 1.7 MB)

My Friend Andrea Bonetti Has Been Appointed As New Chair of IEC TC 95 (Protection ...)

Please note that my friend Andrea Bonetti (currently working for Megger, Sweden) has been appointed as the new chair of IEC TC 95 (Measuring relays and protection equipment).

Andrea and I have conducted many training courses on IEC 61850 ... and cooperated in consulting services related to protection, communication, IEC 61850, ...

Congratulation!

I wish Andrea the best for his future ... managing the process of how power systems are protected. It is a huge task!!

Some Hints On Static And Dynamic Reporting According To IEC 61850

Let me briefly help to understand the term dynamic and static regarding reporting:

Every report control block must be “created” in an SCL file – no way to create a report control block with a service.

Several report control block attributes can be configured in an SCL file or set (overwritten) by a (MMS) service.

A data set can be “created” in an SCL file or by the optional service CreateDataSet.

The term “dynamic” could apply to the setting/overwriting of report control block attributes, and the creation of data sets.

In one case with a Gateway from a well known vendor (as a client) I have seen that the client always defines the data sets dynamically!! And links a given report control block to that created data set. If a server does not support the service CreateDataSet, then you get into trouble …

A nice summary can be found here:

https://wiki.lfenergy.org/pages/viewpage.action?pageId=56380504

For operational functions (protection, control, …) the only dynamical services that should be allowed are to enable or disable the report control blocks. This should be configured in the corresponding SCL file for an IED by setting the attributes to “Conf”:

<ReportSettings cbName="Conf" datSet="Conf" rptID="Conf" optFields="Conf" bufTime="Conf" trgOps="Conf" intgPd="Conf" resvTms="true" owner="true" />

Example of a device from a well known vendor I received the other day:

<ReportSettings cbName="Conf" datSet="Dyn" rptID="Dyn" optFields="Dyn" bufTime="Dyn" trgOps="Dyn" intgPd="Dyn" resvTms="true" owner="true" />

Dynamic setting or overwriting of control block attributes or creation of a data set by a service could cause a lot of troubles!! Client and server should not allow it!  A well known RTU (client) overwrites dynamically a report control block attribute (in the server) immediately after it has connected to the server … that should not be accepted.

It could have a big impact on testing, e.g., you expect that a report (or GOOSE, SMV) message has a structure defined by a data set “X with 5 members” (according to the SCL file) … but you receive a message with 3 members (from data set Y) only … because somebody has overwritten the attribute “DatSet” of the report (GOOSE, SMV) control block. 

IEC 61850 is very flexible … to cause trouble … if you want to trust, that the device is 100% as shown in the SCL file, then NO dynamic modifications should be allowed!

Do you want have a problem - no problem!

By the way, Andrea Bonetti wrote the other day: "It is a good practice followed by the majority of the TSOs that do write their own IEC 61850 specification (sort of “dynamic reports are not allowed unless for testing/debugging”). It is also mentioned in IEC TS 63266:2023 (Representation of communication in power utility automation)."

What is an IED (Intelligent Electronic Device)?

IEC 61850 deals a lot with IEDs. But: What is an IED?

First you can check with two documents of the series IEC 61850:

IEC 61850-1 - Intelligent Electronic Device (IED)
any device incorporating one or more processors with the capability of receiving or sending data/control from or to an external source (for example, electronic multifunktional meters, digital relays, controllers)

IEC 61850-1 - Physical Device (PD)
equivalent to an IED as used in the context of this standard

IEC 61850-5 - Intelligent electronic device (IED)
device incorporating one or more processors with the capability to execute application 
functions, store data locally in a memory and exchange data with other IEDs (sources or sinks) over a digital link

Many years after these definitions have been published, we have different views on the term IED:

Physical IED (in the context of IEC 61850 and IEC 61400-25) - any physical device incorporating one or more processors with the capability of exchanging information (derived from IEC 61850 information models and exchanged with IEC 61850 services for client/server and publisher/subscriber) with other physical device(s). The semantic, the coding and decoding of the exchanged information (messages) follows the standard series.

IED Configuration (in the context of IEC 61850 and IEC 61400-25) - formal description (section in the SCL according to part 6) of the IEC 61850 information models linked to the IEC 61850 information exchange roles client, server, publisher, or subscriber, and the signal flow between physical IEDs.

IED Role (in the context of IEC 61850 and IEC 61400-25) - implementation of the IED Configuration: implementation of the IEC 61850 information model plus implementation of any combination of the following information exchange roles: client, server, publisher, or subscriber.

A Physical IED can host any combination of IED Roles.

Note: A gateway may host a server role to an up-link (first SCL file plus a client role and a subscriber role (both configured in a second SCL file) to the underlying Physical IEDs.

Please note that in SCL a Server configuration comprises the models including the DataSets, Report Control Blocks, GOOSE Control Blocks, SV Control Blocks, and Log Control Blocks:

From a communication point of view GOOSE and SV publisher and subscriber are NOT part of the client/server communication ... 

I hope this definition will help to reduce the disconnects in the communication of the experts.

Let me know what you think.

Mapping of IEC 61850 Models and Information Exchange Services to JSON, HTTP, and MQTT

After I published two sketch videos on IEC 61850 information exchange services and the mapping to MMS, I discuss simple interface options for the last meters between a device that implements the role of IEC 61850 server, GOOSE publisher, and GOOSE subscriber, and the underlying huge world of a myriad of other controllers.

The standard series IEC 61850 and IEC 61400-25 (Wind Power Plants) provide a comprehensive set of standardized information or device models (Logical Nodes, Data Objects, Data Attributes, ...) for a wide range of use cases in the electric power domain (protection, automation, supervision, monitoring, control, ...) and for general applications beyond the electrical world. By the way, tell me where electricity is not a crucial resource in factories, buildings, petrochemical plants, homes, ... it is all over ... required 24/7. These series also comprise information exchange mechanisms like Reporting, Logging, Control, GOOSE, Sampled Values, ... mapped mainly to MMS in IEC 61850-8-1 ... other mappings like mappings to XML and XMPP in IEC 61850-8-2 or MMS, Web Services, IEC 60870-5-104, DNP3, OPC XML DA, ... in IEC 61400-25-4. The most crucial part of IEC 61850 and IEC 61400-25 is the System Configuration Language (SCL, IEC 61850-6).

Many applications use only a very small set of models (a few measurements, control signals, and status signals), a small set of information exchange services, and a simple subset of SCL. Critic comes from experts of various domains: Why do I need to have a complex and comprehensive IEC 61850 stack to implement a simple subset of these standard series? Is there another solution? The wind power plant people developing and maintaining IEC 61400-25 believing that five (5) mappings would help in this regard - really? So, the discussion is still going on. 

A very simple solution has been implemented in various projects: Notation of a subset of the information models and the payload of the messages in JSON. The exchange services could be mapped to various transport mechanisms like MQTT or HTTP ...

This approach would KEEP the models as they are - NO mapping required, just another notation (JSON instead of MMS named Variables etc.). Even SCL could be used.

Whenever there is a need to communicate from a device that plays the role of an IEC 61850 server, GOOSE publisher, GOOSE subscriber, to an underlying (likely simple) device (for the last meters) the decision usually is to use some other communication stacks from a set of 100+ solutions like CAN, Modbus, many fieldbusses, EEBUS, Sunspec, ... and private digital solutions, or even wires only ...

Any of these need to MAP from one standard to another standard, e.g., map MyIED/myMMXU1.Hz.mag.f (measurement of frequency) to register 2246 in one application and to 9817 in another ... hm, that is feasible BUT means a lot of configuration and documentation ... outside the definitions and tools provided by IEC 61850. 

A more reasonable approach would be to use JSON, e.g., to define a DataSet (semantically equivalent to IEC 61850 and MMS) and the report message payload as shown in the figure below:

Please check a couple of blog posts published a few years ago for more details and discussions:

https://blog.nettedautomation.com/2019/07/iec-61850-8-2-versus-iec-61850-8-1.html

https://blog.nettedautomation.com/search?q=mqtt

https://blog.nettedautomation.com/2019/10/iec-61850-for-monitoring-data-private.html

Unfortunately the Beck IPC com.tom Web PLCs with support of IEC 61850, ... disappeared ...

Please let me know your opinion ...

Second Sketch (Video) on Some Basics: The Mapping of IEC 61850 to MMS

IEC 61850 is well accepted globally in the power utility domain. One key issue has always been discussed and criticized: The mapping of the information models (Logical Devices, Logical Nodes, Data Objects ... ) and information exchange services to MMS (Manufacturing Message Specification defined in the standards ISO 9506-1 and ISO 9506-2, developed in the 1980s).

This video (58 minutes) explains the concepts of the mapping to MMS ... ASN.1, ASN.1 BER ... MMS for GOOSE and Sampled Values !?

Click HERE to access the video.

I will continue to produce more sketches (videos) and make them available through Screencast.

I look forward to your feedback.

Enjoy.

Global Push for IEC 61850 - The vPAC Alliance for Virtual Protection Automation and Control

IEC 61850 is one of the crucial core components of the architecture of the Virtual Protection Automation and Control (vPAC) Alliance: "Driving standards-based, open, interoperable, and secure software-defined architecture to host protection, automation, and control solutions for power system substations." 

As of the membership list I accessed today 23 well known companies are involved in the alliance: ABB, Advantec, AEP, Black&Veatch, Crystal, Dell Technologies, ... SCE, ... Intel, ... Omicron, Phoenix Contact, Schneider Electric, Siemens Energy, ... 

This kind of alliances will make a chance in how to protect, automate, control, and supervise power systems ... and other system where power is a crucial factor ... like in factories, buildings, ... airports, ...

"A key plays the "virtual protection relay (VPR) concept [pdf document] – an architecture where software defined and virtualized platforms are deployed to host the critical circuit protection functions for an advanced and agile grid. ... 

Standard models of various protection functions were devised for possible interoperability between protection IEDs from any vendor. Standards were prepared for data exchange between devices (station bus) and current/voltage information from field (process bus). Acceptance of the IEC 61850 standards worldwide have resulted in station level and process level communication networks for exchange of digitized raw values (using Sampled Values, or SV, protocol) and processed values/information across the substation devices and beyond the substation to centralized monitoring systems. ..."

It is interesting that it took some 40 years from the definition of Virtual Manufacturing Devices (VMD) in ISO 9506 (MMS, Manufacturing Message Specification) until such a big alliance has the term "virtual" in its name! I have demonstrated on and on since the 80s that this is the future ... 

MMS defines Virtual Manufacturing Devices in clause 6 of part ISO 9506-1 as follows:

I have found in the automation domain that only a few engineers understand abstraction and virtualization. The following wise saying may help ... try it:

If it's there and you can see it It's REAL
If it's there and you can't see it It's TRANSPARENT
If it's not there and you can see it It's VIRTUAL
If it's not there and you can't see it It's GONE
Roy Wills

IEC 61850, IEC 61400-25 (Windpower), and IEC 60870-6 (TASE.2/ICCP) use MMS and the concepts of abstraction and virtualization ... I had a chance to describe these crucial basic concepts as editor of the first edition of IEC 61850-7-1 (Basic communication structure – Principles and models) ... here is what I have written ... some 20 years ago ... still in the current edition:

" ... The IEC 61850 series defines the information and information exchange in a way that it is independent of a concrete implementation (i.e., it uses abstract models). The standard also uses the concept of virtualisation. Virtualisation provides a view of those aspects of a real device that are of interest for the information exchange with other devices. Only those details that are required to provide interoperability of devices are defined in the IEC 61850 series. ..." 

I still like it.

It is great to see that this concept (defined in the 80s) is in the core of future protection, automation, and SCADA ... 

Let me know what you thing ... you find me on LinkedIn as well.

Good luck!

A New Sketch (Video) on the Introduction of Some Basics of IEC 61850 has been Published

In order to give support in learning what IEC 61850 is about, I have produced a 32 minute video (182 MB) for free access. 

This video is one of the easiest ways to understand some basics of IEC 61850 ... you will agree once you finished it ...

I have trained some 4,500 attendees all over the world ... this video takes into account my experience in training these people ...

Click HERE to access the video.

I will continue to produce more sketches (videos) and make them available through Screencast.

I look forward to your feedback.

Enjoy.

IEC Opens the Glossaries and Other Contents of Published Standards and Specifications

IEC has opened their databases with the myriad of abbreviations and terms used in the published material. If you want to know what an IED is, just search for IED on the landing page ... 

Here are two examples for the search in the Glossaries and in the publications:

and:

Thanks to the IEC Central Office.

Cyber Security: Power Outages Caused by Animals

I just came about the following website that reports many serious "attacks" on the electric power grids:

https://www.cybersquirrel1.com/

It seems that animals are more serious "attackers" of the power grid than hackers ...

Fortunately researchers are "looking" beyond animals ... to humans ... 

Click HERE for information about a crucial R&D project at KIT (Karlsruhe Institute of Technology): "Weak point analysis in energy system protocols"