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

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

Hier klicken, um zum Whitepaper zu gelangen.

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

Ich wünsche allen Beteiligten viel Erfolg!!

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

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

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

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

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

Interoperability Assessment of IEC 61850 Devices in a Multivendor Digital Substation

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

Interoperability Assessment of IEC 61850 Devices in a Multivendor Digital Substation

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

Click HERE for more information ...

Whitepaper: OCPP and IEC 61850 - A Winning Team

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

Excerpt:

"EXECUTIVE SUMMARY

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

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

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

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

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

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

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

Congratulation!

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

Some Hints On Static And Dynamic Reporting According To IEC 61850

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

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

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

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

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

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

A nice summary can be found here:

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

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

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

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

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

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

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

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

Do you want have a problem - no problem!

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

What is an IED (Intelligent Electronic Device)?

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

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

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

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

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

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

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

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

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

A Physical IED can host any combination of IED Roles.

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

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

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

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

Let me know what you think.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Please let me know your opinion ...

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

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

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

Click HERE to access the video.

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

I look forward to your feedback.

Enjoy.

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

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

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

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

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

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

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

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

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

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

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

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

I still like it.

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

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

Good luck!

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

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

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

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

Click HERE to access the video.

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

I look forward to your feedback.

Enjoy.

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

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

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

and:

Thanks to the IEC Central Office.

Cyber Security: Power Outages Caused by Animals

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

https://www.cybersquirrel1.com/

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

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

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

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!

The IEC 61850 Tissue Database reached 1900 Tissues

The IEC 61850 Tissue Database is a very useful tool to help improving the quality of the standard series. The first Tissue (#1) was posted almost 19 years ago. On December 12, 2023 the Tissue #1900 was posted. In average two Tissues per week have been posted. The Tissue process is accepted all over.

The other day I received a question on the definition of power factor (MMXU.PF). The definition is contained in the Logical Node class MMXU of part IEC 61850-7-4:

When I read the definition I was wondering that there was no definition of the sign of the PF. I thought that somebody must have found this long before me ... I checked the Tissue Database to find the corresponding Tissue ... which is #1721 (Power factor related data objects in LN MMXU) dated September 22, 2020.

The following figure depicts the corrected definition.

Recommendation: In case you belief you found an error in the standard series, check first the tissue database and search ... you may find the correct answer ...

Is National, Regional, and International Standardization Work Important?

The editor-in-chief of the well known German monthly technical magazine "atp - Automatisierungs-technische Praxis" publishes the "atp weekly" discussing this and that. This week he discussed if the various user groups and other interest groups in the process industry (NAMUR, IGR, and VCI) are important for the national, regional, and international standardization. The resume is: Yes it is!

The weekly lists several examples. In the third example he reports that the review and comments of the three above mentioned organizations on a single German draft standard has the potential of savings of 80 Million Euro!! 

Click HERE for the weekly archive (in German only) ... accessible for 6 months.

Not to be involved in the standardization is more expensive than spending time and money to participate and discuss what is needed and what should not be specified in a standard. Less is sometime MORE!

Default Passwords May Cause Some Issues - Change Them As Soon As Possible

 A friend of mine reported the following in a SCADA and cyber-security related group:

"The recent cyber-attack on that small water facility outside of Pittsburg is getting increased attention (certainly on this list) . The model and manufacturer of the device in question are known.  The manufacturer's web site has some  documentation on the device, but I do not think they provide the  device's default password.

No need to look hard, it is listed in plain site on CISA's bulletin (below)."

Exploitation of Unitronics PLCs used in Water and Wastewater Systems Release Date November 28, 2023 

Oops.