IEC 61850 in Cyber Secure Environments - New Comprehensive Seminar

Due to my family situation (nursing my beloved wife from 2017 to 2022) I had to slow down my training activities. This year I was asked by several senior experts if it would be possible to resume the training.

As a result of discussions with friends of mine, we updated our previous course program and offer a brand new 5-day comprehensive public seminar for Automation, Protection, Monitoring, Engineering, Configuration (SCL), SCADA, Smart Grids, RTU, Gateways, … cyber physical security in electrical systems of any industrial plant … it is available for you and your people.

The reason for the update: We want to do more than teaching the theory of IEC 6850 and demonstrate single IEDs … we want to let our practice talk for your practice. The new training will start in March 2026. Taking the experience with many crucial applications of IEC 61850 into account we offer a new program for a 5-day course conducted by four (4) real experts.

09.-13. March 2026, Karlsruhe (Germany)
21.-25. September 2026, Karlsruhe (Germany)

Click HERE for more details on dates, location, and registration information.

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

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!

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

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

IEC CDV files available for Public Commenting - circulation date 2023-08-11

 Dear Friends of IEC standards, I just remember you that IEC lets you comment on published CDVs (Committe Draft for Vote) ... 

Click HERE for general rules, :

IEC Public Commenting

Help shape international standards if you have the requisite technical expertise. Public commenting on draft IEC Standards is open for a two month period

Currently the following IEC 61850 document is open for comments ... you have to login with your IEC account or register for an account:

57/2602/CDV 

IEC 61850-6/AMD2 ED2: Amendment 2 -
Communication networks and systems for power utility automation -
Part 6: Configuration description language for communication in electrical substations related to IEDs 

CLOSING DATE FOR VOTING: 2023-11-03

Please take your time to review the document ... You may agree with me that part 6 (SCL) is a crucial part of the series IEC 61850!

3-Day Training for Electrical Engineers New to IEC 61850

3-Day Training for Electrical Engineers New to IEC 61850

17-19 March 2020 | London, UK

Day One: Tuesday 17 March
Core Concepts
Overview of IEC 61850 and introduction to the core concepts, including the hierarchical data model, communication services and the range of applications possible.

Day Two: Wednesday 18 March
Engineering and Configuration
Deep-dive into the IEC 61850 engineering process, learning how to use Substation Configuration Language and engineering tools for IEC 61850 specification, system design and IED configuration.

Day Three: Thursday 19 March
Testing
Learn how to thoroughly test IEC 61850 systems, including functional and system testing as well as gaining an overview of cybersecurity considerations for IEC 61850 systems.

Click HERE to learn more.

IEC TC 57 Just Published the IEC 61850-90-11 on Logics

IEC TC 57 Just Published the 90 pages of the Draft Technical Report IEC 61850-90-11 (57/2129/DTR)

Communication networks and systems for power utility automation –
Part 90-11: Methodologies for modelling of logics for IEC 61850 based applications

Voting closes 2019-10-04

"This Technical Report of IEC 61850 describes the methodologies for the modelling of logics for IEC 61850 based applications. ... the technical report

• Defines different application uses cases where all aspects to be considered are clearly identified.
• Describes the functional requirements and the intended engineering process
• Proposes a suitable solution in the context of IEC 61850 based on an investigation of the different possibilities to model the logic.
• Describes the impact on various parts of IEC 61850"

If, when and how this Technical Report will impact implementations of tools and IEDs is quite open. I remember that we had heated debates on the question how to deal with (internal) logics already some 10 years ago.

If you are planning to apply IEC 61850 - please DO NOT wait until this part 90-11 offers stable definitions ... IEC 61850 (as it is defined today) has enough to get started! ;-)

OPC-UA@TSN, Profinet@TSN or CC-Link@TSN - and IEC 61850

Automation and industrial communication are buzzwords for decades. They mean something quite different when you look at the 80s, 90s, 00s, 10s, today ... Where are we today? Not really far away from the 80s.

In February 1985 I attended the first time the GM MAP Team in Detroit (MI) - it was a cold week:



This was my first trip to the USA. At that time I did not expect to come back to the US for more than 130 times ... almost all trips related to standardization: MAP, MMS, UCA, IEC, IEEE, ...
The MAP (Manufacturing Application Protocol) project and especially the MMS (Manufacturing Message Specification) standard where the first combined attempt to define a single set of  international standards for manufacturing automation systems. As you may know: they failed - because they were far too early.
MMS (ISO 9506) defines many services that have been smiled at. But if you read today (2019-02-23) what experts in the OPC/UA World are looking at - then you wonder how it was possible in the 80s to define most of the basic services the industry is looking for TODAY:

• Client/Server
• Selfdescription
• Read/Write/Report
• Two-Way-DataExchange (like RPC)
• Standard Configuration
• Semaphore
• Event Management
• Journaling (Logging)
• ...

It really took 30+ years before the industry understood what is really needed besides the myriad of Fieldbusses!!

Since the MAP days we have learned some crucial lessons:

• In addition to Client/Server we need Publisher/Subscriber (as defined some 15 years after the MAP project in IEC 61850; GOOSE and Sampled Values)
• In addition to ISO/OSI Transport we need TCP/IP ... done in IEC 61850.
• We need many semantic models ... as the many Hundred Logical Nodes in IEC 61850, e.g., for electrical measurements MMXU or Temperature Supervision STMP, ...
• Standardized system configuration is key for any future automation system ... as defined in SCL (IEC 61850-6) for energy systems.

Fieldbusses are understood today as the "maximum credible accident". Heinrich Munz (Lead Architect Industry 4.0 at KUKA) says in the just published special issue ot the magazine "tsn & opc ua 2019" (www.computer-automation.de) on page 12: "Jeder Gerätehersteller muss die Anschaltung und das Engineering jedes seiner Produkte an mehr als zehn unterschiedliche Feldbusse entwickeln und pflegen - ein betriebs- und volkswirtschaftlicher Super-GAU." [Each vendor has to develop and maintain hardware and engineering tools for each of his products to be compliant with more than 10 different fieldbusses - economically a maximum credible accident.]
My personal resume after reading through the special magazine is this:

• The third fieldbus war started some years ago and is expected to go on for many years. 
• The standard series IEC 61850, IEC 62351, IEC 61968/70 (CIM), IEC 61400-25, ... provide most of what OPC-UA and TSN are looking for.
• It is likely that the providers of traditional and Ethernet-based Fieldbusses will migrate during the next years to OPC UA and TSN.
• OPC UA and TSN will be implemented and used - why not?
• In the meantime the energy domain is already using and extending the semantic models, applying the needed services and feeling happy with the standardized configuration language.
• What else do you need?

The French novelist Andre Gide nailed it when he wrote, "Everything that can be said has been said, but we have to say it again because no one was listening."

According to my 50 years of experience as a technician, the most crucial challenge in automation is this: People of different application domains (control center, RTU, protection, PLC programming, robot controlling, communication, security, engineering, maintenance, ... telecomms, internet, web, ...) DO NOT LISTEN TO EACH OTHER!!! If one expert of a specific domain talks - no one from the other domains is listening!
Talk together and have a look at what people have said and done even decades ago! It may be better than what you were told. It may save you hours and days and weeks ... of struggling.

IEC 61850 Applications in Germany - DKE Documents Online for Free Download

The German National Committee of IEC TC 57 (DKE K 952) has many members of various Working Groups (in the national as well as in the international groups) that discussed the IEC 61850 standard series in general and particularly how the standards could be applied to substation automation and protection. One of the key issues is the modelling and configuration using SCL.

Several documents in German and in English are available:



Click HERE for the link to the above page.

Enjoy the documents.

FMTP, NettedAutomation and other Experts Offer New Training Courses for Power System Automation, Protection, Smart Grid, and Security

FMTP Power AB (Uppsala, Sweden), KTH (Royal Institute of Technology Stockholm), Håvard Storås (Security expert), and NettedAutomation GmbH (Karlsruhe, Germany) have each long-term experience in the application of standards for protection and control as well in secure communication and SCADA applications.
FMTP and NettedAutomation in coopration with other senior experts offer the most comprehensive and vendor-independent education and practical training courses – they combine their knowledge and practical experience in the following areas:

1. Substation control and protection, system design, engineering, and testing
   (Mr Andrea Bonetti who worked for ABB, Megger, and STRI),
2. Smart Grid (Mr Lars Nordström, Director and Professor at KTH – Royal Institute of Technology Stockholm), 
3. IT, OT & Cyber Security
   (Expert Mr Håvard Storås) and 
4. Communication technology and SCADA ... market penetration and solutions(Mr Karlheinz Schwarz who worked for Siemens in the 80s and 90s):

We offer the following comprehensive training options:

Stockholm/Sweden
(English: Andrea Bonetti, Prof. Lars Nordström, Håvard Storås, and Karlheinz Schwarz): 

12-16 March 2018 (book 3, 4 or 5 days)

Click HERE for details

Karlsruhe/Germany
(English: Andrea Bonetti, Håvard Storås, and Karlheinz Schwarz):

23-27 April 2018 (book 3, 4 or 5 days)

Click HERE for details

Karlsruhe
(Deutsch: Karlheinz Schwarz):

14-17 Mai 2018
04-07 Dezember 2018

HIER für Details in Deutsch klicken.

IEC TC 88 Started Work on SCL for Wind Power Plants

WOW! IEC TC 88 has published a new work item proposal (88/621/NP) for the specification of extending the SCL (System Configuration Language):

Wind energy generation systems –
Part 25-7: Communications for monitoring and control of wind power plants –
Configuration description language for communication in wind automation systems
related to IEDs

The objective of the NWIP is to describe the adoption of the System Configuration description Language (SCL) defined in IEC 61850-6 to the wind domain

"This part would extend the IEC 61400-25 series with a file format for describing communication-related IED (Intelligent Electronic Device) configurations of a wind turbine, wind power plant controller, metrological mast etc. The extension of SCL to wind domain would simplify integration of wind power plant equipment as well as their integration to the electrical system. The adoption of SCL allows formalised tool based exchange of IED parameters, communication system configurations, switch yard (function) structures, as well as description of the relations between them.
The purpose of this format is to formally and efficiently exchange wind turbine and wind power plant IED capability descriptions, and system descriptions between IED engineering tools and the system
engineering tool(s) of different manufacturers in a compatible way. The file format is also intended for providing report configuration and alarms as well as HMI interface information from a wind power plant. This information can be used to engineer overlying SCADA systems for the site, for connected DSO, TSO or fleet operators maintenance and surveillance systems. Finally, the SCL is intended as a documentation of the configuration and topology of the delivered system."

WOW! Why a WOW? During the fist years of standardization of the series IEC 61400-25 the proposal of applying and extending the SCL (IEC 61850-6) did not find enough support to start working on the issue! Time is passing and more and more experts understand the advantage of SCL!

Good luck.

Dubai (UAE): NEW IEC 61850 Seminar for Protection, Control, and Generation

You are invited to register for one of the world leading IEC 61850 Seminars for Protection, Control, and Generation to be conducted by

FMTP, Al-Ojaimi, and NettedAutomation 
in Dubai (UAE) at the Sheraton Dubai Mall of the Emirates
11-13 July 2017

With the focus on protection and control in HV/MV substations, power generation (PV, Wind, DER, Hydro), distribution systems using Client/Server, GOOSE, SV, SCADA and SCL Language covering:

• IEC 61850 / IEC 61400-25 Introduction (Edition 1, 2, and 2.1) and experience after more than 10 years in operation. Where are we today?
• Return of experience, applications and practical demonstrations:
• Protection and Control in Substation Automation
• Engineering and Configuration
• Maintenance
• Monitoring and SCADA system
• Specification of the IEC 61850 protection and control system.
• Through the practical demonstrations, you will learn:
• To handle IEC 61850 relay protections from different vendors and their software tools; to be able to efficiently manage flexibility in engineering and interoperability.
• To use the state of the art IEC 61850 testing tools and equipment to efficiently detect the technical problems and work-out their solutions.
• To understand SCL files, setup clients and servers for MMS communication to SCADA and RTU Systems
• All the presentations are supported by practical examples or demonstrations.

Who should attend?

• Protection and Electrical Engineers (protection, control, engineering, SCADA, asset managers)
• System integrators
• Product managers of vendors
• R&D engineers
• Maintenance personnel
• Experts responsible for network infrastructure

Click HERE for program and registration information.
Click HERE for other training opportunities.

Case Study - IEC 61850 Application for a Transmission Substation in Ghana

A lot of discussions about the benefits of using IEC 61850 have happened in the past and are still going on ... and will go on also in 2017 and beyond.

A nice paper has been presented some three years ago:

Case Study: IEC 61850 Application for a Transmission Substation in Ghana

"One of the benefits of implementing IEC 61850 is minimizing or even eliminating the copper field wiring used to exchange protection and control data between intelligent electronic devices (IEDs) across a substation. Conversely, implementing IEC 61850 has introduced commissioning, testing, and maintenance complexity that can be alleviated with proper training, documentation, and testing plans. The design and implementation of the Kintampo, Ghana, transmission substation required redundant protection and control functions distributed among the IEDs and a robust communications network to implement IEC 61850 protocols. ...
As the acceptance of IEC 61850 communications by utilities grows, this type of large-scale project will grow as well. ...
A system solution that is repeatable, pre-engineered, pretested, and designed to specifications is extremely important because it provides the user with a standardized solution that can be implemented across the system, minimizing different designs."

Click HERE for the 10 page paper [pdf]

How to get Interoperability and Interchangeability with IEC 61850?

The standardization process in the context of IEC 61850 is picking up quite fast. As you have learned in the posts of today and older ones, there are several new topics on the list of items to work on for future new parts of IEC 61850.
One of the crucial objectives is the interoperability and INTERCHANGEABILITY of devices from different vendors in a multi-vendor system.
To reach this goal, we need standards! Sure. But what is absolutely required is the EDUCATION of experts from Vendors, Utilities and System integrators.
We offer the right courses for you: With focus on protection, automation and SCADA.In English and German.
Due to the request from power engineers FMTP and NettedAutomation have scheduled several dates for public training courses in 2017:
The next courses are:

19-23 September 2016 in Stockholm, Sweden [EN]
10-13 Oktober 2016 in Karlsruhe, Germany [EN]
07-09 Dezember 2016 in Karlsruhe, Germany [DE]

Click HERE for more details.

Hurry to reserve your seat!

You would get more than in any other course - because two of most experienced experts (Andrea Bonetti and Karlheinz Schwarz) will guide you through the most crucial aspects of IEC 61850. The combined experience of the two is unparalleled.

ENTSO-E proposes some Extensions of IEC 61850

IEC TC 57 distributed a proposal from ENTSO-E to add some features to IEC 61850 (57/1771/DC):

Proposed new work items by ENTSO-E to introduce additional specification features of IEC 61850 based systems within SCL

Edition 2 of IEC 61850-4 was published in 2011. Edition 2 of IEC 61850-6 was published in 2009. Ultimately, the proposal by the ENTSO-E statement and example of engineering process, aims to serve the market in order to reach the multi-vendor interoperability of systems in an efficient way.

Crucial Topics are:

1. Input and data flow modelling / Virtual IED - Introduction of additional specification features of IEC 61850 based systems within SCL.
2. System engineering efficiency - Introduction of additional specification and configuration features of IEC 61850 based systems within SCL.
3. Communication Network Description - Introduction of additional specification and configuration features of IEC 61850 based systems within SCL.

Please note that big utilities (in Europe ...) have already used SCL to specify the details they want vendors to implement. The time where vendors could model the automation system the way they like it most seems to be over soon. Utilities start to understand that even interchangeability is the ultimate goal!!

It all depends on the willingness to cooperate!

Teamwork makes the dream work!

How to Exchange a Voltage Measurement with IEC 61850?

As discussed before you will find a reasonable example to learn the benefits of applying IEC 61850.
Let's look at a voltage measurement:



According to IEC Electropedia we find many names for the same semantic: voltage, Spannung, spenning, ... Ok. These help humans to understand what we are talking about. But what about machines (controllers, SCADA systems, ..)?
They have to use a data type (int16, int32, float32, ...) and a reference (address ...) for a specific protocol like Modbus. Each vendor will likely use different types and addresses.
What's about the scale in applications that use integer? Is the scale known when you read the value of a voltage? Do you know the offset or the multiplier (V, kV, mV, ...)?
How do you know where the measurement is taken in the electrical system (location in the single line diagram)?
Answers to these questions may be found in a set of documents sitting on a shelf or on someones computer - hard to find out if the owner is on vacation.
With IEC 61850 we have a model that could be implemented so that all these details are always accessible online from each device that is a source of measurements:



Phase A voltage has a standard name "MMXU.PhV.phsA" with the value, quality, timestamp, units, and scale. These names are used all over in any IEC 61850 device.

IEC 61850 services allow to retrieve the MMXU model and read the values:



The device has all information to interpret the voltage value for phase A.

Finally we need to know where the value is measured in the single line diagram. IEC 61850-6 (SCL) provides the solution specified as an SCL file (simplified SSD - Substation Specification Description):


The above voltage could be designated as follows:
MySub_400kV_3A63_BayFunction_ABC/ACMMXU1.PhV.phsA

The value is located in the device "BayController". The device is communication wise identified by an IP Address.

This information really exposes all information needed to interpret a measurement. 

Note that this name needs not to be communicated when the value is reported cyclically or issued by a limit change.The report message could only carry the value, quality and timestamp.

The SCL file has all information to configure the whole system and the devices.

Any question?

Hope you have learned this: IEC 61850 goes very far beyond a protocol! We only need the protocol when we retrieve the selfdescription or read out or report the values.

And: the nice thing is that any device that implements the standard uses the same model, configuration, and services. What else do we need?

If we would apply just a protocol like Modbus then most of the information exposed (directly from the device) through the standard IEC 61850 would have to be stored in paper docs or excel sheets ... 

Once Again: Is IEC 61850 another Protocol?

IEC 61850 and related standards like IEC 61400-25 offer very complex definitions that are intended to ease the life-cycle of the whole system: design, engineering, configuration, operation, maintenance, system extension, documentation, error diagnosis, ...
In my experience with protocols since 1982 (when I started working for Siemens) I have seen (too) many protocols coming and going. I guess I could list several hundred protocols including IEC 60870-5-10x, DNP3, Profibus FMS, Profibus DP, ...

Many experts (especially in the higher management and HR) have years of experience with one or several protocols - working with 600 baud or even 100 Mbit/s Ethernet based links. It happens quite often that those experts are promoted for higher management functions. Many of them have no experience with the approach of IEC 61850. But they often have to decide if, how and when the new technology will be used.

Because of the complexity, they may decide not to use it at all and even not trying to understand what it really could offer their engineers - at least as long as they are the persons in charge.

The real issue is (as Dee Hock, Founder of Visa put it): "The problem is never how to get new, innovative thoughts [IEC 61850] into someones mind, but how to get old ones out." One of these "old ones" is the opinion that IEC 61850 is something like DNP4 or IEC 60870-5-105 -- just another but more complex protocol (MMS, ISO 9506). This (old, too old, wrong) opinion has also a big impact on decisions, e.g., to get a green-light for attending an IEC 61850 training course. Managers and HR often have the opinion: Why do we need this comprehensive training (of 2, 3, 4, or 5 days) for just another protocol? Often the light stays at RED!
We could put it in future in a different way:

1. IEC 61850 Protocol Training -> 1/2 day
2. IEC 61850 Services (Client/Server, Publisher/Subscriber, Reporting, Control, Setting Groups, ...) -> 1 day
3. IEC 61850 Modeling and Models -> 1 day
4. IEC 61850 Engineering and Configuration -> 3 days 
5. How to use it for protection, SCADA, monitoring, power generation applications -> x days (depending on what application you have in mind).

If you don't understand what Models and SCL provide ... either take a course or stop discussing it.

IEC 61850 is not intended to replace any other protocol with MMS! In order to harvest the fruits of the application of IEC 61850, you have to look at any other topic than protocols.

But you have to be open to take a closer look at the issues listed under bullets 2 to 5.

You will not get an answer by just reading the standards ... take a course to get a reasonable understanding.

Be an ENGINEER - not just a boss or a leader.
Click HERE for a nice illustration at LinkedIn (or optionally HERE) to see the difference between old approaches and the engineers solution. IEC 61850 is a very big vehicle to carry a lot of loads - to make life easier.

I will post some example to show you the real benefits.

IEC 61850: THE crucial standard for Power Delivery System at EDF

PennWell Corporation reported earlier this year:
French utility giant EDF uses IEC 61850 for more than the standard's usual communication applications. Working with Schneider Electric, EDF has embraced a new approach for application modeling with IEC 61850 at its core.

For designing wind farms and photovoltaic (PV) systems, EDF employs this approach as early as the requirements-gathering level. The approach echoes one encouraged by Schneider Electric for using IEC 61850, an ambition the company translated into software engineering tools.

With its new approach to engineering smart substation automation systems, EDF places information flow at the center of project engineering. …

Any person or machine at EDF can read and understand that common language. The language enables information exchange among devices, people, departments, organizations, generations of stakeholders and the components and people involved in projects and systems.

… EDF's approach, based completely on the IEC 61850 standard, allows the capture of unambiguous requirements in a formal way.

Click HERE to read the full article.

More to come.