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"

IEC 62541 (OPC Unified Architecture) - 3 Additional CDVs published for commenting

IEC TC 65E just published 3 additional Committee Drafts for Vote (CDV) for commenting and voting ... also for public comments!

CDVs for circulation on 2024-02-02 also available in Public Commenting application: (https://www.iec.ch/how-get-involved/public-commenting)

Here are the CDV documents published (official voting period closes April 26, 2024):

IEC 62541-3 ED4: OPC Unified Architecture - Part 3: Address Space Model

IEC 62541-5 ED4: OPC Unified Architecture - Part 5: Information Model

IEC 62541-6 ED4: OPC Unified Architecture - Part 6: Mappings

See also the other 21 CDVs out for comments.

Be aware that these documents are the basis to define domain specific information models like in IEC 61850: MMXU.PhV.phsA for voltage of phase A (L1) in a three phase AC power system or MMXU.Hz for representing the frequency ... 

I guess that a lot of the definitions published in the 24 CDVs will not be implemented in all devices and only a subset of the implemented definitions may be used.

After some 40 years involved in the IEC TC 65 (1982 - 2001), TC 57 (2002 - today), IEC TC 88 (2001 - today), and ISO TC 184 SC5 WG2 (MMS, 1984 - 2000) I am increasingly convinced that IEC 61850 has a lot of advantages compared to other standards ...

IEC 62541 (OPC Unified Architecture) - 21 CDVs published for commenting

Dear All,

IEC TC 65E just published 21 Committee Drafts for Vote (CDV) for commenting and voting ... also for public comments!

CDVs for circulation on 2024-01-26 also available in Public Commenting application: (https://www.iec.ch/how-get-involved/public-commenting)

Here are the CDV documents published (official voting period closes April 19, 2024):

62541-1 ED1: OPC Unified Architecture - Part 1: Overview and Concepts

62541-2 ED1: OPC Unified Architecture - Part 2: Security Model

62541-4 ED4: OPC Unified Architecture - Part 4: Services

62541-7 ED4: OPC Unified Architecture - Part 7: Profiles

62541-8 ED4: OPC Unified Architecture - Part 8: Data Access

62541-9 ED4: OPC Unified Architecture - Part 9: Alarms and Conditions

62541-10 ED4: OPC Unified Architecture - Part 10: Programs

62541-11 ED3: OPC Unified Architecture - Part 11: Historical Access

62541-12 ED2: OPC Unified Architecture - Part 12: Discovery and global services

62541-13 ED3: OPC Unified Architecture - Part 13: Aggregates

62541-14 ED2: OPC Unified Architecture - Part 14: PubSub

62541-16 ED1: OPC Unified Architecture - Part 16: State Machines

62541-17 ED1: OPC Unified Architecture - Part 17: Alias Names

62541-18 ED1: OPC Unified Architecture - Part 18: Role-Based Security

62541-19 ED1: OPC Unified Architecture - Part 19: Dictionary Reference

62541-20 ED1: OPC Unified Architecture - Part 20: File Transfer

62541-21 ED1: OPC Unified Architecture - Part 21: Device Onboarding

62541-22 ED1: OPC Unified Architecture - Part 22: Base Network Model

62541-23 ED1: OPC Unified Architecture - Part 23: Common ReferenceTypes

62541-24 ED1: OPC Unified Architecture - Part 24: Scheduler

62541-100 ED2: OPC Unified Architecture - Part 100: Device Interface

It is a huge list of documents ...

I have looked through the docs and did not find any application domain specific semantic models like in IEC 61850 ... 

Hope you find some time to comment on these documents.

Enjoy!