Thursday, September 17, 2020

Boeing's 737 MAX - A True But Unbelievable Story Told In A New Report

The final 245 page committee report (September 2020) on the problems with the Boeing 737 MAX tells stories that we (as engineers) could not believe! Or?

There are are many very crucial details that have been reported. You have to read the report on your own ...

Click HERE for the report.

Here are two excerpts that made me very sad:

"The story of the Boeing 737 MAX was never expected to be associated with catastrophe. It was supposed to be a story of American ingenuity and technological success—a modern, more fuelefficient airplane that had already become the manufacturing giant’s best-selling jet in its storied history prior to the first MAX crash ..." ... Obviously it was too easy to cheat ... in order to make more sales ... to earn more money, to get richer ... to ... what ever.

"... FAA delegated some certification activities to Boeing that it should have retained. In the case of the 737 MAX, in 2013, the FAA originally delegated 28 of 87 tasks to Boeing. However, this number rose to 79 of 91 activities by November 2016, four months prior to final certification of the 737 MAX aircraft."

Be aware that is very common in the industry to allow self-certification ... so, the results may be similar as with the 737 MAX ... non-conformity of a protection relay may lead to severe blackouts and ...  

One obvious reason for these behavior of humans these days could be found in 

"And for this cause God sendeth them a working of error, that they should believe a lie: that they all might be judged who believed not the truth, but had pleasure in unrighteousness."
Bible 2. Thessalonians 2:11-12 

Saturday, August 15, 2020

IEC TC 57 Just Published Additional Code Components for IEC 61850

IEC TC 57 has published five additional code components document as listed in the figure:

These documents are very helpful ... they provide the main parts of the corresponding information models.

Click HERE to see the full list of the 18 published code components.

Friday, August 7, 2020

IEC 61850 Global 2020 - Virtual Conference - 26-30 October 2020

IEC 61850 is one of the most crucial standard series for automation - in power systems and beyond. There are still just a few experts that really understand what it is all about.

If you want to learn a bit more, you may attend the VIRTUAL Conference 26-30 October 2020 ... You don't need to travel ... don't need to stay at a hotel ... stay at home with your family ...

Get a discount by registering before 28 August 2020.

Click HERE for the details.

Friday, July 31, 2020

Ten Years After Stuxnet Went Public - And Now?

One of the senior experts in cyber security wrote today:

"Recently many of us noted the 10th Anniversary of when Stuxnet went public. Some commentators think it was for cyberspace a “Hiroshima” type of event. Some have been saying that there have been no other events like it since and this puzzled me. So I wrote my thoughts down to share."

Another senior expert is wondering why there is little information disclosed and lack of guidance about control system cyber security incidents that can affect multiple facilities in multiple industries:

Both are worth to read!

Tuesday, July 28, 2020

IEDScout 5.00 Available - One of the Most Crucial Test Tools for IEC 61850

IEDScout is a well known test tool for most of the needed support in the communication with IEC 61850 compliant devices.
Omicron has released the version 5.00 ... providing crucial extensions compared to version 4.2:

IEDScout is a versatile software tool for working with IEC 61850 devices. With Version 5.0, IEDScout offers a new level of cyber security and powerful simulation utilizing the new MBX1/RBX1 hardware.
Additional improvements are:

  • IEDScout now supports function-related naming for logical devices
  • The icon set has been updated to provide a smooth user experience when used together with StationScout/StationGuard.
  • When writing data to an IED, IEDScout will now automatically update the “t” attribute of the data object.
  • Improved screen scaling for better readability on high resolution screens.
  • License information is now available in the configuration dialog.
  • OMICRON’s IEC 61850 library has been updated to include the latest developments in standardization and improve interoperability.
  • The usability of IEDScout is continuously improved based on expert reviews and customer feedback.
  • Several smaller tweaks and bug fixes improve overall performance and stability.

Click HERE for more information on IEDScout 5.0

Monday, July 20, 2020

PhD Student Working On Cyber Security In Critical Infrastructures

Fredrik Heiding (PhD Student) wrote the other day:

Fredrik Heiding, PhD StudentNetwork and Systems Engineering
KTH, Royal Institute of Technology

I am doing a PhD on cyber security in critical infrastructure. Currently I study the security trends for critical infrastructures in Europe, analyzing where it is heading and how it is developing. To strengthen the study I have identified seven general questions, they are general in nature so they can be answered by people in critical positions without revealing sensitive information.
Here are the Questions from Fredrik and Answers from a very senior expert:
Cybersecurity consulting
See also:
Vytautas Butrimas wrote in the introduction to his answers:
This a particularly interesting time in CIP. I come from and IT background and have focused mostly on the cybersecurity of industrial control systems in the past 10 years. This has been a long learning curve for I found that my IT knowledge did not provide enough to understand the engineering and laws of physics that are dominant in the monitor and control of physical processes found in the pumps and compressors on fuel pipelines, treatment of drinking water, routing of trains, and the generation and distribution of electricity. One needs to know the implications and peculiarities between working IT office time and real time to work in this field.
I looked at your questions and will give brief answers.  If you wish to further discuss them with me then we can do so offline.
Question 1:
What concerns for the future do you have regarding cyber security in critical infrastructure?

Answer 1:
How the introduction of increased complexity of systems (systems of systems, adding more sensors, increased connectivity) will be managed without taking away from safety, reliability and performance.

Question 2:
Over the past decade, digital attacks have become more central to the security of critical infrastructure. Do you think the trend will continue to increase or culminate?

Answer 2:
There are some signs that things will get better but at the same time they will get more complicated.  Security practitioners need to realize that much more attention is needed where the physical process is taking place and the devices closest to it that are monitoring and controlling it, not where they are being monitored by humans in a remote location or control room.  ** One more thing we should not just be focused  on „ATTACKS“.  We also have to consider unintended actions or accidents. As the complexity of systems and connectivity of devices increases so will the unintended or „why did that happen?“ incidents.***

Question 3:
What relevant research or technological advances do you find most interesting for the future?

Answer 3:
Have to think about this one.  It feels we are all trying to keep afloat in a tsunami of technological advances.  The ones that worry me the most are the new features which also come with vulnerabilities that need to be addressed before a malicious group decides to exploit them.

Question 4:
Do you see IIoT (Industrial Internet of Things) as an opportunity or a concern, if both, which part is greatest (positive or negative)?

Answer 4:
I see it mostly as a concern (see my earlier answers). I suggest watching a video available on youtube called "Brave New Internet 4.0 " by one of your famous countrymen, Ralph Langner.  The questions and concerns he raised in that lecture IMHO have not been addressed.

Question 5:
Do you have plans to, or do you think that you will expand the cyber security department in the coming years?

Answer 5:
I am currently working my out of "mandatory retirement" and am not in position in expand anything (perhaps later this year I will change my answer).  If I was in a position of influence at an operator of CI (energy sector for example) I would do my best to set up some support for the senior engineer of the plant.  When he sees something unusual going in the operation he should be able assign this problem to an security operation center. Could be at least one person or a small team that understands cyber threats and how they could be applied to the engineering side of the operation.  The senior plant engineer has to keep things running and does not have time to stop and investigate something.  He needs someone to help him and a ICS SOC could be a good solution is management is willing to spend the money for the positions and training.

Question 6:
Can you share anything about past attacks/intrusion attempts, both successful and unsuccessful attempts are interesting?

Answer 6:
Look at the freely available information on line. Look up Ralph Langer to learn about STUXNET. It happened 10 years ago and this is probably the most analyzed and documented incident we have today that is publicaly  available.  Much can still be learned for the methods continued to be applied today. In 2014 in Germany your government (BSI) published its yearly report on cyber incidents.  There is a section devoted to a cyber attack on a steel mill that had an uncontrolled shutdown and resulted in damage. Look at Triton/Trisis/Hatman incident of 2017 where the safety systems of a petrochemical plant tripped not one but twice. Look for video lectures on this from Dale Pedersons S4 conferences in 2018/2019 (see lecture by Julian Gustmanis and by Schneider Electric)

Question 7:
Has the attitude towards cyber security changed in the last 5 years, why and in which way/

Answer 7:
The attitude is changing and for the better. Much better in the engineering community who have  understood how threats from cyberspace can get into their operations. On the other hand as far as government policy makers go they still have a long way to go. Much technical expertise has left government for the private sector leaving some governments blind to some issues. The 3 Little Pigs problem is evident where one thinks one has taken the appropriate measures and build a house of straw or of sticks to protect from the wind and the rain but the possibility of their being a wolf is somehow missed.  You would be surprise at how many government policy makers do not know what scada is and yet think they are doing a great job at protecting critical infrastructure.

Improve the Quality of Your Standard With A Tissue Database

What is a Tissue Database? Tissue stands for Technical Issues - short Tissues.

One of the crucial challenges of maintaining and improving standard series like IEC 61850, IEC 62351, IEC 61400-25, ... is that usually standardization processes of the Standard Setting Organizations use text files (Word, pdf, ...) for publishing drafts and final documents. When it comes to manage and document errors and other problems, then quite often Excel Sheets are used ... or even just a text file.

This was the case in the IEC TC 57 regarding IEC 61850 after the first parts had been published. We often had a discussion like: Who has the latest Word Document with the Tissue Lists? When was it updated ... grrrr.

NettedAutomation GmbH developed the first version of the so-called IEC 61850 Database in 2004. 16 years later IEC uses a license of the improved tissue database (Tissue DB v.

Click HERE for the parts overview.

For the current Edition 2.1 of part 7-2 there are eight tissues listed:

Click HERE for 7-2 Ed 2.1.

The IEC 61850 tissue database is a very helpful tool to improve the quality of the standard series IEC 61850, IEC 61400-25, and IEC 62351.

Contact NettedAutomation GmbH for an offer of a license of the NettedAutomation tissue database for your project.

Click HERE to contact NettedAutomation for a quote.

IEC Just Published IEC 61850-80-5 Guideline for Mapping Information Between IEC 61850 and IEC 61158-6 (Modbus)

IEC TC 57 Just Published IEC 61850-80 -5 Guideline for Mapping Information Between IEC 61850 and IEC 61158-6 (Modbus)

(57/2250/CD, 166 pages) - closing date for comments: 2020-09-11

Excerpt from the introduction:

"This technical specification provides a guideline to exchanging information between IEC 61850 and IEC 61185-6 (Modbus TCP). Nowadays, industrial field such as distributed energy resource (wind and solar energy, etc.) and condition monitoring, has been exchanging the information from Modbus to IEC 61850 for an effective operation. Although many manufacturers already implemented the Modbus to IEC 61850 conversion device or system, these devices do not guarantee interoperability. Therefore, it requires the consistent and unified information exchange scheme between IEC 61850 and IEC 61158-6 (Modbus).
Modbus over serial line (Modbus RTU) is not part of IEC 61185-6, but is also considered in this technical specification."

IEC Just Published IEC TR 61850-7-5 ED1 - Modelling Concepts

IEC TC 57 just Published Draft IEC TR 61850-7-5 ED1 - IEC 61850 Modelling Concepts

(57/2253/DTR - 33 pages) - voting closes 2020-09-11

Excerpt from the introduction:

"The standard IEC 61850 provides a very broad range of data models covering as much as possible all application functions in the range of power utility automation. The modelling both in the domains and between the domains show differences which may impact the interoperability. Therefore, some informative guideline is helpful to reach a common approach in application function modelling. A lot of basic functionality is based on the concept of IEC 61850 and, therefore, the same for all application domains. As result, a basic cross-domain part as Technical Report is useful. Domain specific issues are addressed in the Technical Reports 7-5xx (e.g. IEC TR 61850-7-500 for substation automation)."

Wednesday, July 15, 2020

Repository of Ransomware Incidents Against Critical Infrastructures

Aunshul Rege, Ph.D., Associate Professor Trusted CI Open Science Cybersecurity Fellow 2019 Department of Criminal Justice | Temple University

wrote today:

"I'd like to share a potentially useful FREE resource that my team and I have created. In September 2019, we started a repository of ransomware incidents against critical infrastructures. These are based on publicly disclosed incidents in the media or security reports. This repository now has 642 records assembled from publicly disclosed incidents between 2013 and June 2020. So far, we have had download requests from industry, researchers, faculty, undergraduate and graduate students, so we hope that this repository might be of use to this community.

Please visit to request a download. Funded by my NSF CAREER Award #1453040. "

The Version 9 of the repository (I received today) lists the following numbers of ransomware incidents:

2 for 2013
6 for 2014
9 for 2015
82 for 2016
99 for 2017
68 for 2018
202 for 2019
173 for 2010 (until 20 June)

The total amount paid is unbelievable high! Even most amounts are undisclosed!

It is unbelievable!

Friday, July 10, 2020

Fusion: Fundamentals and SystemCORP

Excerpt from the press release:

Fundamentals and SystemCORP Energy have each built businesses on a combination of know-how, innovation, engineering, products and services, in particular but overlapping areas of expertise. But coming together now as a single Fundamentals entity will create a fusion reaction, generating more energy for innovation than our two separate elements.

On a more immediate and practical level, SystemCORP and its employees in Perth are being incorporated into Fundamentals Australia Pty Ltd., adding to Fundamentals’ existing bases in Sydney, together with our headquarters in Swindon, UK,  and facilities in Bristol and Oldham. This will greatly enhance the mutual support we can provide for customers in both countries – and increasingly worldwide, as we continue to grow.

Click HERE for the complete press release.

Tuesday, June 30, 2020

SCADA Security Matters Should Matter

The SCADA Security and Cybersecurity of critical infrastructure challenges are growing very fast. In order to follow a great source of information provided by a gray hair senior expert please visit the following pages:

Learn what the expert Mr. Vytautas (Vytas) Butrimas has to say.

Wish us all power systems that are hardened to withstand any attack from inside and outside!

Stay safe!

Wednesday, May 20, 2020

Sampled Values and IEC 61850-9-2 LE: What is it?

The other day I received the following email:

Dear Mr. Karlheinz Schwarz,
I am sorry to disturb you. My name is XXX and I am a researcher from YYY. I would like to ask some questions to you regarding the standard IEC 61850-9-2LE.

1) May I know the status of IEC 61850-9-2LE? Is the standard will be obsolete or remain as it this?

2) Can I get some explanations from you about the differences between IEC 61850-9-2, IEC 61850-9-2LE and IEC 61869-9?

I really appreciate your kindness and time to answer my questions above.
Thank you & best regards,
I have a very good friend that I asked to answer for me. Her is his answer:
Dear Karlheinz, 
Sure I can do my best for that.
Thanks for this opportunity.
Dear XXX, please see my attempt to answer.
Your questions are our everyday’s questions, and my answers need to be taken with “common sense”, reasonability and not as law, where somebody is right and somebody is wrong.
This is the best I can say.
The IEC 61850-9-2 Light Edition (LE)  is NOT a standard.  It is an UCA profile; a sort of gentlemen agreement (followed by everybody so far), where in principle the dataset carried by the SV Message (Sampled Values message) is fixed to 4 voltages and 4 currents.
The sampling frequency is 80 samples per period (4000 Hz for 50 Hz systems and 4800 Hz for 60 Hz systems).
The length of the SV message is fixed (in terms of bytes)
The quality string has one “extra bit” (the 14th bit, for derived or measured of the analog quantity) compared with a “normal quality string” of IEC 61850 and also IEC 61869 series, of 13 bits.
The time synchronization is 1-PPS
There is formally no support for PTP time synch (typical of “Edition 2” of IEC 61850 standard. LE is “edition 1”)
There is formally no support for “SIMULATION” mechanism (typical od “Edition 2 “ of IEC 61850 standard; LE is “edition 1”)
And many others.
It is commonly understood (and you have to make sure it is commonly understood also by the people working in your projects: suppliers, consultants, utility engineers etc) that:
- 9-2 LE supports Simulation mechanisms
- 9-2 LE supports PTP as time synch (be careful that PTP is actually IEC 61850-9-3: 2016 )
Even if formally this is not strictly in line with the UCA specification for “LE”.
So, IEC 61850-9-2LE (written by UCA working group) is a profile of IEC 61850-9-2 (written by the IEC committee TC 57)
And today it is the only “standard” that is implemented and in service for process bus applications.

IEC 61869-9 (and also -6 and also soon the -13) are parts of the IEC 61869 series, written by the IEC committee TC 38 (Instrument Transformer). 
So they have to do with the Merging Units, they are also profiles somehow, and also many other requirements, that you need to fulfill if you want to have a Merging Unit according to IEC standards.
To my opinion, no matter what IEC 61850 says in general, if you do a Merging Unit and follow IEC, you should follow IEC 61869 series.
In principle, the IEC 6185069-9 standards are often associated to:
  • “Dynamic” dataset. This means that not only 4 U and 4 I will be transmitted. I can transmit just  one voltage, or 25 currents, or 6 voltages and 3 currents.. This is done from SCL.
  • Sampling frequency of 4800 Hz, no matter the power system frequency (50 Hz or 60 Hz).
  • PTP time synchronization (for MU)
  • 2 samples per SV message (so called ASDU). “LE” has only one sample per message (one ASDU per message)
But it is of course much more than that.
What about protection relays/protection functions?
TC 95 is responsible for protection functions in IEC.
In principle it  is TC 95 / MT 4 (Maintenance Team 4) that takes care of functional standards for protection functions (IEC 60255-121:2014 for distance protection for example). Other maintenance teams take care of protection related standards like EMC etc.
Recently TC 95 has started a new working group (WG 2) that considers IEC 61850 for protection applications. A Technical Report is on its way and parts of that technical report will be implemented in the so called IEC 60255-1xx series, for protection relays.
But this is not ready yet and all of this needs to be considered with extreme care and communication among all the involved parts in a project.
I work as well as consultant for IEC 61850 applications in relay protection. Mainly for TSOs, since many years. Please have a look at this paper, written by many of us active in TC 95 / WG2. I think it will help you to better understand.
If you are interested in what TC 95 / WG2 does, you are more than welcome to contact me and I’ll help you in joining “our” activities.
For your understanding, there is a high dialog between TC 95, TC 38 and TC 17 (circuit breakers) for making the use of IEC 61850 more interoperable not only at “data level” but also at “functional level”, at least for protection applications.
For metering or power quality applications, for example, I don’t know what to say.
I hope this helps you.
Karlheinz, your extra comments are always welcome.
My best regards
Andrea Bonetti
Just passed

 Fachtagung Schutz- und Leittechnik 2020 , Berlin, 18-19 February 2020

Mr. Andrea Bonetti MSEE
Senior Application Specialist Relay Protection and IEC 61850
Active member of IEC TC 95 / MT 4 ”Measuring relays and protection equipment” since 2006.
Megger Sweden AB
Rinkebyvägen 19, SE-182 36 Danderyd (Stockholm)

Tuesday, May 12, 2020

New GOOSE and Sampled Values Performance Test Platform

GridClone developed a new GOOSE and Sampled Values Performance Test Platform:

SIMFLEX IEC 61850 PT Platform

It is a solution for testing GOOSE and Sample Values time performance, functional behavior and conformance to the standard.

  • Inspect GOOSE/SV behavior on microsecond level
  • Simulate multiple GOOSE and SV Streams
  • Execute (pre)conformance, detail and functional testing
  • One solution for GOOSE/SV and MMS testing
  • Demystify process bus complex behavior
  • Ready to integrate fully automated platform
  • Building trust in Digital Substation by testing it
  • Resolve GOOSE/SV issues in system design phase
  • Maximize level of details and minimize testing time
Click HERE for more information.

Wednesday, March 18, 2020

Tissues For IEC 61869-9 Could Be Posted

Please note that a new part has been added to the IEC 61850 Tissue Database:

Part 9-2 (related to IEC 61869-9; 2016)

IEC 61869-9 defines: Instrument transformers -
Part 9: Digital interface for instrument transformers

IEC 61869-9:2016 is a product family standard applicable to instrument transformers with digital output. The product standard is composed of IEC 61869-1 and IEC 61869-6, in addition to this standard and the relevant product specific standards in the IEC 61869 series (Part 7, Part 8, Part 12, Part 13, Part 14, and Part 15). This standard defines requirements for digital communications of instrument transformer measurements. It is based on the IEC 61850 series, UCA international users group document Implementation guideline for digital interface to instrument transformers using IEC 61850-9-2, and the relevant parts of IEC 60044-8 that are replaced by this standard. It includes additional improvements including the IEC 61588 network based time synchronization. This first edition replaces the corresponding specific requirements previously contained in IEC 60044-8, published in 2002. This International Standard contains specific requirements for electronic low power instrument transformers (LPIT) having a digital output. However, the reader is encouraged to use its most recent edition. This publication contains an attached file in the form of a .xml file. This file is intended to be used as a complement and does not form an integral part of the publication.

Click HERE for more information.

Saturday, March 7, 2020

IEC 61850 Is Very Crucial For Semantic Models And Interoperability

IEC 61850 provides a huge number of generic and specific semantic models ... Logical Nodes, Data Objects, Common Data Classes, Instance-Information, Topology Information, Information Exchange, Communication, Protocols, ...

Can you please show me an easy to understand example! Here you are!

The following figure shows how (meta) model information is added to a simple voltage measurement (right upper corner). The value is wrapped with a data object model comprising with many attributes like instCVal.mag.i or units ...
The logical device and and logical node instance information is added next. Finally the semantic of the information exchange (report model) is applied to the value - sure, there is a data set involved as well (not shown here).
All this information (general and specific (instance) semantic) could be described in an SCL document (using an XML based SCL schema). Note that some configuration information, e.g., engineering unit (kV), may be contained in the SCL document only. The device needs to process implicitly the voltage in kV. A device may allow to use the SCL document to configure the device to expose the voltage in V ... or mV ... A client (SCADA or ...) may read out the model at runtime (including the engineering unit, if that is implemented as a model attribute) or may just read locally the SCL document and get the engineering unit from the file. Note: the SCL document is the main document for the models and configuration ... keep it safe!! And check the online read model against the SCL file from time to time to compare the two in order to figure out any change!

Further in our example we have a simple bay topology with electrical equipment like generator, switch gears, voltage and current sensors. This topology could be engineered and documented with the SCL (System Configuration Language) - an XML schema for a whole system. The equipment is assigned to specific information models (MMXU.PhV.phsA. ...).
The system engineering could be managed, e.g., with the Helinks STS Tool. An easy to use tool.
The generic Information Model, e.g., MMXU (defined in IEC 61850-7-4) is concatenated with the application designation (MyGenSets/Gen11).

The various levels of semantics of the Message elements are:
  1. Model Instance: Hierarchical Identification of the specific Model of Semantics (in SCL) 
  2. Message Elements: Service Type, Identification, Value, Quality, and Timestamp (ACSI - Abstract Services)
  3. Message Instance: Service Type, Instance of Identification, of Value, of Quality, and of Timestamp (Report)
  4. Message semantic (ACSI mapped to MMS)
The modeling approach of IEC 61850 could be applied in most automation domains ... especially when electric power is applied.

Let me know please if there is a similar standard model defined for automation systems that may compete with IEC 61850 and IEC 61400-25. 

Why Do You Need a Pocket Lamp for a Smart Meter?

The other day I was really surprised reading a letter to the editor of our local newspaper here in Karlsruhe. The Writer reported that he had to use a pocket lamp and morse code for a PIN to activate the screen of a smart meter. The DSO had told him the benefits of this ... nobody else can see the metered values ;-) ... and the meter is protected from outside ... because it is not connected to any communication medium ... OK. He summarized in stating that the meter is not smart - but it is a Smart Business Case for somebody.

I searched for "smart meter taschenlampe" and got several hits. Here is one ... in German language ... but you will understand it. Enjoy!

Click HERE for a nice video demonstrating how to use a pocket lamp to communicate with the Human Machine Interface of a modern smart electric meter.

What do you think? How much would you pay for this Smart Meter? ... 20 Euro/year!

Friday, March 6, 2020

Do You Know ISO/IEC 9506-6 - The MMS Process Control Companion Standard?

Long time ago (may be when you still went to Kindergarten) there was an international standardization project defining a set of standards that offered comprehensive sets of services and models for Industrial Automation Systems:

ISO/IEC 9506 Manufacturing Message Specification (MMS)
- Part 1 (Services) and Part 2 (Protocol)

MMS was developed in the 80s and published in 1990. The standardization in ISO TC 184/SC5/WG2 took place in the context of the GM led MAP project.

Part 1 and Part 2 comprise the basic definitions for any application domain.
Click HERE for useful hints and explanations what MMS is and how it is used for IEC 61850.

The Companion Standards have been developed for specific applications:

Part 3 Companion Standard for robotics ISO/IEC 9506-3
Part 4 Companion Standard for numerical control ISO/IEC 9506-4
Part 5 Companion Standard for Programmable controllers ISO/IEC 9506-5
Part 6 Companion Standard for Process control ISO/IEC 9506-6

Part 6 seems to be a simple forerunner model of IEC 61850 for communication services models and applications models.

Cover page:

Excerpt of the application model related to a process variable (Data Model in IEC 61850):

Excerpt of the reporting model related to the report control block model in IEC 61850:

Unfortunately all MMS parts have (more or less) been ignored by the industrial automation domain. As one of the experts deeply involved since 1985 I know a bit what happened ... the most crucial reason was: many experts that did not (WANT to) understand the benefits of MMS have led to the situation today: No comprehensive unique standard for information models, services, protocols, ... has been offered for the industrial automation ... even in Industry 4.0 there is not yet one in preparation - as I see it. Even OPC UA is still looking for domain specific models ... may "copy" IEC 61850 models!?

Sure: IEC 61850 is much more than MMS !!! But MMS could be understood as a kind of forerunner for IEC 60870-6 (TASE.2/ICCP), IEC 61850 and IEC 61400-25 (Wind).