40 Years Ago I Started Contributing To The MAP/MMS Standardization In Detroit (MI)

I have contributed to the MAP/MMS Standardization (Manufacturing Automation Protocols/Manufacturing Message Specification) from the very beginning. I was working for Siemens in the group dealing with communication solutions for process control and factory automation. In February 1985 I attended the first time a meeting of the MAP project at the GM TechCenter in Warren (Michigan, USA). As you can see, the first day was a very cold day (1985-02-14) with a lot of fresh snow:

I looked still young (40 years younger than today) ... 32 years old and father of four children.

The approach of MAP/MMS was very new ... even today a lot of people have difficulties with MMS ... especially because of using ASN.1 BER as the encoding notation for all messages exchanged according to IEC 61850 - Client/Server and Publisher/Subscriber messages!!

In 1993 I got also involved in the new IEC TC 57 project TASE.2 (Telecontrol Application Service Element 2) based on MMS ... called ICCP (Intercontrol Center Communication Protocol):

I attended the following meeting in Loveland (Colorado, USA):

30 years ago (March 1995) the IEC TC 57 decided to start a new project: IEC 61850 based on the EPRI UCA 2.0 Specification ... also using MMS/ASN.1/BER ... I got involved in UCA and IEC 61850 starting with the second IEC TC 57 WG 10 meeting end of 1995.

Many people in the electrical power world have complained since then that MMS/ASN.1/BER is toooo ... too much of ... and as a result many have departed from the approach.

I have suggested many times to use web services ... JSON encoding instead of ASN.1/BER and XML ... most people ignored the use of web services ... I guess it will come in the near future.

In many of the following standardization groups I have supported modern communication approaches ... in some cases it took some time ... or still is awaiting for a push:

Object Modeling in the late 1980s - Too Early!

One of the crucial aspects of the standard series IEC 61850 is about object modeling ... first versions have been published in the year 2004 ... guess you agree!

Did you know that object modeling for process automation was already defined to some degree in the late 1980s for the standard ISO/IEC 9506-6 (MMS Companion Standard for Process Control) - published in the year 1994? Maybe you are surprised ... you may even have been born after that time ... 

The other day I have documented the following example of supervision of rate change of a process measurement:

On the bottom the MMS Named Variable C_PVRCPAP is shown. The semantic (setting for a specific event) is equivalent to the "Temperature rate alarm trigger level setting" of the LN class STMP in IEC 61850-7-4 Ed2.1. The definition in MMS part 6 is generic and applies to any measurement.

I would say that the MMS companion standard ISO/IEC 9506-6 was some 30 years too early published ... mainly due to the fact that many engineers did not understand abstract object modeling. 

History repeats itself, which is good because most people don't pay attention the first time anyway.

And today? Hope you have a better understanding! In case you need help ... let me know.

The semantic of the huge amount of signals in IEC 61850 or the few in the old ISO/IEC 9506-6 make the difference compared to most protocols like IEC 60870-5-104 and ... 

IEC 61850-7-410 ED3 CDC - Hydroelectric Power Plants Available for Public Commenting

Please note that last Friday IEC TC 57 has published the following Committee Draft for Vote (CDV) (57/2750/CDV) for comments by National Committees AND for public commenting by anybody before April 04, 2025:

IEC 61850-7-410 ED3: Communication networks and systems for power utility automation - Part 7-410: Basic communication structure - Hydroelectric power plants - Communication for monitoring and control 

To comment on the CDV please click HERE. If you have not yet an account you can register ... if you have an account, go on. (IEC reports: Please use Google Chrome or Microsoft Edge).

IEC Public Commenting is a chance to let your voice be heard before the final vote.

This draft is a major step forward to get an international standard for hydroelectric power plants, steam and gas turbines.

Is AI Solving the Future Challenges in Physics, Technologies, Automation ...?

There are a lot of expectations regarding AI (Artificial Intelligence) ... what are experienced engineers telling us ...

I came about a very interesting post on LinkedIn from David Ingram. The post is worth reading!!

Click HERE for the post.

The comment from Chris Turner on the post writes: 

"AI fails in poorly understood domains. It relies on websites that may be right, wrong or a mixture of both. e.g. I asked AI "Q: What In-Circuit Test measurements (including powered tests), are most likely to provide a Gaussian bell shaped curve?

A: .... "

Chris resumes: "The AI answer is wrong."

I am not surprised ... 

„Lumpensammler“ in der Stationsautomatisierung mit IEC 61850 - Störmelder

EES (Backnang) bietet eine "super-einfache" Lösung zur Alarmierung von Störungen in IEC 61850 basierten Systemen:

"Neben den Informationen von Feld- und Schutzgeräten, fallen in Schaltanlagen zusätzliche Meldungen an, die an die Leittechnik übermittelt werden sollen. Diese Informationen sollen über die vorhandene Infrastruktur mit dem Protokoll IEC 61850 übertragen werden. ... 

1. Einbindung von Einzelmeldungen in die Stationsautomatisierung über IEC 61850
2. Integrierte Relaisausgänge zur Befehlsausgabe
3. Einfache Parametrierung über integrierten Web-Server
4. Zuverlässiger Betrieb durch störfestes Design und angepasste Signalverarbeitung
5. Hohe Funktionalität und Skalierbarkeit von 8 bis zu 192 Meldungen ..."

HIER kommen Sie zu weiteren Informationen.

Dieses Beispiel zeigt, dass IEC 61850 auch für einfache Aufgaben angewendet werden kann!

„Rag-man“ in Substations Applying IEC 61850 - Fault Annunciators

EES (Backnang, Germany) offers a nice solution for simple and easy alarming in IEC 61850 based systems:

"In addition to the information provided by the field and protection devices over IEC 61850, different single alarms incurr in switchgear stations, e.g. from the station supply switchboard section or general alarms like temperature monitoring or door contacts. ... 

1. Simple integration of fault annunciators into IEC 61850 structures – through copper or optical fibre connection
2. Integrated relay outputs for issue of commands
3. Easy parameterisation through integrated web-server
4. Reliable operation through immune design and adapted signal processing
5. High functionality and scalability from 8 up to 192 alarms ..."

Click HERE for additional information.

This product shows that IEC 61850 is applicable for simple and easy to use applications.

Are LTE And 5G Cell Phone Systems Secure?

Are you expecting that every communication system has one or the other issue with security? You are right! What's about LTE and 5G? Here is what researchers have found:

Check out the following:

RANsacked: Over 100 Security Flaws Found in LTE and 5G Network Implementations
By Ravie Lakshmanan

Excerpt: "A group of academics has disclosed details of over 100 security vulnerabilities impacting LTE and 5G implementations that could be exploited by an attacker to disrupt access to service and even gain a foothold into the cellular core network. ..."

Click HERE and HERE for additional information.

LTE and 5G are used for power systems all over ... just google for iec 61850 lte 3g ... you will be surprised ;-)

Click HERE to follow some discussion on remote monitoring and control ... if ever possible minimize the use of communication ... 

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)."