The Demo of the IEC 61850-8-3 (WebSocket) is now Ready for You to Explore

First: The IEC 61850-8-3 Committee Draft (57/2980/CD)

Specific Communication Service Mapping (SCSM) – Mapping to Direct Message Specification (DMS), JSON Encoding Rules, and WebSockets

was out for comments in September and October 2026. The comments are mainly editorial ... the comments show high support of the draft ... no critical comment!

The Demo of the IEC 61850-8-3 (WebSocket, as an alternative to MMS) solution provided in the context of the Netbeheer's RTI 2 (Real-Time Interface 2) PoC is now Ready for You to Explore!

Here is the announcement I received today:

Hi everyone,

An exciting milestone to share!

I'm happy to announce that the RTI demo has officially been merged into the main branch of the Netbeheer Nederland iec61850-websocket repository!

But that's not all! To make deploying and exploring the demo as easy as possible, we've also created a dedicated repository:

iec61850-websocket-demo

With this repository, you can set up a fully functional demo environment locally using only Docker — no development environment required!

This makes the RTI demo much more accessible, allowing everyone to explore and experiment with it independently.

What can you expect?

Once the demo is up and running, you'll see an environment featuring:

• One System Operator (SO) and two customers acting as Flexibility Service Providers (FSPs).
• Secure communication between the SO and FSPs using TLS 1.3. The secured connections are clearly indicated by the TLS icon in the interface.
• External system integration: Both the SO and FSP2 have an attached box representing an external system. These systems can interact with the demo through plugins, enabling IEC 61850 operations. In the current setup, this is demonstrated by switching LEDs on and off within the interface.

​​

Explore IEC 61850 operations yourself

Navigate to the Traffic menu to explore the IEC 61850 communication and operations in action.

Here, you can:

• Execute IEC 61850 operations manually and immediately observe the results.
• Run a playbook that automatically executes a predefined sequence of IEC 61850 operations.
• Follow the execution step by step, directly within the Traffic page.
• Observe logging between the components on different levels 

Currently, one playbook is included, providing an easy and interactive way to experience how the RTI demo works.

And this is just the beginning! The demo already includes many more features (like data-models, Oauth2-security) and capabilities than we can cover in this single email. I encourage everyone to explore the environment and discover what's possible.

What's next? Bringing the demo into the physical world!

Over the coming month, we'll be putting the finishing touches on the physical part of the demo, built around Raspberry Pis.

This will take us beyond a fully virtual demonstration, allowing IEC 61850 operations to interact with actual physical devices and making the results directly visible in the real world.

Curious about what such an integration might look like? Here's a sneak peek: dr-ssd1306 – Raspberry Pi Demand Response Demo

A big thank you to everyone involved!

A special thanks to everyone who contributed to making this milestone possible! Whether through development, testing, reviewing, sharing ideas, or providing valuable feedback, your efforts and collaboration have helped bring the RTI demo to where it is today.

Give it a try!

With this milestone, we've not only integrated the RTI demo into the main development branch but also significantly lowered the barrier to getting started.

Fire up Docker, explore the demo, and experience firsthand how secure IEC 61850 communication works between a System Operator and Customers as Flexibility Service Providers!

Enjoy exploring! Feedback, ideas, and suggestions for future improvements are, of course, very welcome.

Met vriendelijke groet,

Robert-Jan Peters
Energy system architect | System Operations

robert-jan.peters@alliander.com

Background information: 

https://blog.nettedautomation.com/2026/09/what-is-iec-61850-8-1-mms-compared-to.html 

https://blog.nettedautomation.com/2025/12/long-awaited-christmas-gift-for-smarter.html 

Deploying IEC 61850 Process Bus and vPAC at the UK’s Largest GridHub (Dorman Point 400 kV Substation)

UK’s largest electricity transmission substation is designed to handle up to 3.2 GW of throughput ... the planned 400 kV facility ... will be build on IEC 61850 instead relying on 200 km multi-core copper control cabling ... wow.

Bruno Silveras LinkedIn post ...

Bruno Silveira reported today many details in his LinkedIn document (November 02, 2026):

Deploying IEC 61850 Process Bus and vPAC at the UK’s Largest GridHub (Dorman Point 400 kV Substation)

Excerpt:

"National Grid Electricity Transmission (NGET) has secured 73.3 acres at Dorman Point within the Teesworks industrial zone in Redcar to develop what is projected to be the UK’s largest electricity transmission substation.Designed to handle up to 3.2 GW of throughput, the planned 400 kV facility will serve as the electrical backbone for hyperscale AI data centres, offshore wind landings, and industrial decarbonisation projects across Teesside.

Delivering transmission capacity of this scale under ambitious energisation targets (targeted for initial operations by late 2029) exposes the limits of legacy substation engineering. A traditional hardwired design across dozens of 400 kV feeder, transformer, and busbar bays would demand hundreds of kilometres of copper multi-core cabling, sprawling relay buildings, and months of point-to-point physical commissioning.

Applying a modern, software-defined architecture, combining an IEC61850 Station Bus, a redundant Process Bus, and Virtualised Protection, Automation, and Control (vPAC), fundamentally transforms the civil footprint, project timeline, and operational lifecycle of the Dorman Pointasset. ..."

Some 30 years after the start of the standardization project IEC 61850 we can see the change in applied technologies and standards for our electric power delivery systems ... more to come.

Ask AI Who I am ... regarding IEC 61850 education

A good friend of mine asked recently the following question to ChatGPT and somebody else asked Claude:

So, frankly speaking, who is the most competent trainer in the world about IEC 61850 standard today? What do you think?

Ok ... like it ... I have trained 4,400+ Experts from 1.000+ Companies from 90+ Countries in 250+ courses (2026-10).

More to come.

Let me know in case you need help!

Stromsysteme funktionieren nur zusammen, wenn deren Entwickler zusammenarbeiten

Wenn Fachleute nicht zusammenarbeiten, dann tun es Stromsysteme auch nicht

Unter diesem Titel hat die DKE ein unbedingt lesenswertes Interview mit Andrea Bonetti geführt. 

"Andrea Bonetti ist der neue Vorsitzende des Technischen Komitees IEC/TC 95, das Normen zu Schutzrelais für das Stromnetz erstellt. Schutzrelais erkennen elektrische Fehler im Netz und isolieren sie, um eine unterbrechungsfreie Stromversorgung zu gewährleisten.

Bonetti erklärt, wie die Anforderungen an intelligente Netze und der Klimawandel die Arbeit der Expert*innen verändern ...

Wir haben eine gemeinsame Gruppe unter der Leitung von TC 57 mit Fachleuten aus TC 95 und TC 38 gebildet. Die wesentliche Anforderung hierbei ist, Fachleute mit unterschiedlichen Perspektiven zu verstehen, zu sehen, woher sie kommen. Ich sage immer, niemand liegt richtig oder falsch. Falsch ist nur, wenn das Produkt nicht funktioniert. Zusammenarbeit ist wichtig – sie ist eine Grundvoraussetzung. Wenn Fachleute nicht zusammenarbeiten, dann tun es Stromnetze auch nicht."

Er hat absolut recht! Teamwork makes the Dream work.

Danke Andrea!

Andrea Bonetti verweist mehrfach auf die gute Zusammenarbeit mit dem IEC TC 57 hin ... dabei spielt die Normenreihe IEC 61850 eine besondere Rolle!

Hier geht es zum Beitrag (in Deutsch) ... Article in Englisch

OPC UA is About to Follow IEC 61850 in its Energy Initiative

The standard series IEC 61850 has already helped globally for more than 20 years to improve (with a broad approach) the power system engineering, system and device configuration, information modelling, and information sharing ... helping to reach a high level of reuse-ability and getting more resilient systems ... keeping the power flowing and the grass green.

Many years after it became obvious that IEC 61850 uses such a broad approach, the time has come that the OPC Foundation tries to benefit from the big success of IEC 61850!! Really!

According to the OPC Foundation Energy Initiative [7 page PDF] standardized "Semantic Information Models of Energy-related Systems ..." are planned to use IEC 61850! Wow!

Excerpt: 

"In 2024. OPC UA has started to look at the whole energy market to help simplify, standardize and improve the resilience of connection points. Not only among the five major energy components but also within. ... One important standard that is widely used in substations, wind farms, solar array and other large utility size installations is the IEC 61850. The OPC UA Wind and Solar PV Operations and Monitoring (SPOM) working group, together with the IEC 61850-20 working group has started mapping the 61850 models to OPC UA models ...

THE CHALLENGE: FRAGMENTED ENERGY DATA

Many factories lack a consistent way to collect and analyze energy data from machines, devices, and production systems. Different communication technologies and proprietary interfaces often prevent seamless integration of energy information. Without standardized data structures and semantics, companies struggle to gain a clear overview of their energy usage. This makes it difficult to identify optimization potential, implement coordinated energy-saving measures, ..."

For exactly these reasons, the electric power industry started in the year 1995 to develop the standard series IEC 61850! The struggle is reduced since IEC 61850 touched the road.

With IEC 61850-8-3 (web-based communication using WebSockets, JSON and DER encodings) a new and modern information sharing is underway - while preserving the rest of IEC 61850 (engineering, configuration, models, ...) unchanged.

It is also interesting to see how the wind industry that developed the standard series IEC 61400-25 (Wind Turbines) has understood that the deviation from IEC 61850 as it happened in the first two editions of IEC 61400-25-2 (models) was not a good idea. The third edition of IEC 61400-25-2 will be harmonized with IEC 61850 (The ORIGINAL).

Congratulation for using THE ORIGINAL! ... always use the original IEC 61850 ... if possible ...

CDV Just Published: IEC 61400-25-2 Edition 3 - Wind Power Plants - Information Models

Just published: the Committee Draft for Vote (CDV) of the 3rd edition of the Standard for Wind turbines - IEC 61400-25-2: Communications for monitoring and control of wind power plants - Information models 

IEC 61400-25-2 ED3, 88/1199/CDV for Public Commenting (157 pages) 

DATE OF CIRCULATION: 2026-10-16
CLOSING DATE FOR VOTING: 2027-01-08

Excerpt from the Foreword:

"This edition includes the following significant technical changes with respect to the previous edition: 

The harmonization of IEC 61400-25-2 with IEC 61850 in term of data modelling and document structure. The IEC 61400-25-2 Edition 3 is auto-generated from the reference UML model, following the process set-up in TC57 and described in IEC TS 61850-1-2. A benefit of this process is that this document is provided with Code Components, including the NSD.

Common data classes (CDC) specific to the wind power domain have been removed and replaced by existing CDCs from the IEC 61850-7-3:2011+AMD1:2020 to follow the rules set in IEC TS 61850-1-2. ..."

I highly appreciate that this 3rd edition compared to the first two editions is really harmonized with the original standard IEC 61850 - which was the base for the IEC 61400-25-2 ... BUT the group decided some 20+ years ago to be (for good reasons) "special" ... unfortunately I (and a few other experts) were not able to convince that the real benefit would be to just use the IEC 61850 as a base and just extend models for wind turbines. 

IEC awarded me with the IEC 1906 Award vor my involvement in IEC 61850 AND the adoption for wind turbines:

Congratulation for this step forward to reach a harmonious set of information models published by IEC 61850 AND IEC 61400-25-2 !!!

All other "tools" like SCL configuration language, services, protocols like IEC 61850-8-1 ad IEC 61850-8-3 (Websockets, JSON encoded messages; in preparation) ... can be used also for the wind turbines. The need for an extra comprehensive mapping of the models to OPC UA is ... !?

Next Step in CIM - IEC 61850 Harmonization: Public Commenting

IEC TC 57 just published the 57/2975/CDV for Public Commenting:

CLOSING DATE FOR VOTING: 2027-01-08

IEC 62361-102 ED1

Power systems management and associated information exchange - Interoperability in the long term -
Part 102: CIM - IEC 61850 harmonization 

Excerpt from the Scope:

"1.1 General

This part of IEC 62361 outlines a technical approach for achieving effective information exchange between power system installations governed by IEC 61850 and business systems integrated with IEC CIM standard data exchanges, based on a selected specific set of use cases, but also with the goal of creating a framework that will extend successfully to other use cases in the future. This document includes proposals to ‘harmonize’ the two standards by adapting or extending existing information models and/or defining new models, where such changes will enable more effective communication. Both current and future directions of models will be considered. The document aims to take into account existing standards for semantics, services, protocols, system configuration language, and architecture. ..."

Click HERE for the public commenting.

The Cyberattack on French Supermarket Refrigeration Should be a Wake-up

Here is a link to the research paper worth to read and take into account for your OT system:

When the Cold Chain Is the Target: The October 2026 Cyberattack on French Supermarket Refrigeration, a Trend in Temperature-Control OT, and a Comparison with Other Control-System Incidents

Publishing Editors: Bob Radvanovsky, infracritical®

Extract from the Abstract

"On the night of 11 October 2026 the refrigeration systems of hundreds of French supermarkets were made to defrost and warm on command, destroying stock and, in some stores, starting fires. This paper reads that event through the operational technology (OT) that holds food cold: the refrigeration system managers that stage compressors and condenser fans and schedule defrost, and the management interfaces through which maintenance firms reach them. It treats the event first as a cyber incident, an occurrence in which the behaviour of digital systems jeopardised the availability of a process, and settles the question of intent second, following the primary sources. It sets out what the public record establishes about the event and its scope [1–4], identifies the affected controller families and their support status [5–8], and places the event in a trend of cold-chain and refrigeration-control incidents running from 2022 to 2026 [5,9,10]. ..."

Click HERE for the report.

Stay safe!

German FNN Steuerbox (Control Box) Version 1.5 is now available as English Version, August 2026

The famous German VDE FNN Steuerbox (Control Box) Version 1.5 is now available as English Version (edition August 2026).

"The "Specification for Control Box: Functional and constructive properties" describes one option for implementing control via smart metering systems. With this new version, VDE FNN has made important corrections regarding the operation, application, and compliance of the Control Box. Among other things, the parameter set and certificate set were updated, and corrections were made to the [added by editor: IEC 61850] data model. These new adjustments thus improve the operation and flexibility of the FNN Control Box and make an important contribution to implementing control via the smart metering system."

This specification is worth to purchase and to read. The price for the eBook is 69,00 Euro.

Click HERE for a link to the order form ...

On the last page you will find a link to the ICD file for the device ... free of charge.

Neu: Branchenempfehlung für die Harmonisierung von Ortsnetzstationen

Die Verbände BDEW und ZVEI haben am 29. September 2026 eine 16-seitige und  beachtenswerte Branchenempfehlung für die Harmonisierung von Ortsnetzstationen veröffentlicht! 

In der Executive Summary lautet der vierte Satz: "Durch die Reduzierung der Variantenvielfalt können Ressourcen geschont, Planungs- und Beschaffungsprozesse vereinfacht und Realisierungszeiten verkürzt werden."

Weiter unten: "Die Unterstützer bekennen sich mit dieser Branchenempfehlung zu einer gemeinsamen Verantwortung von Netzbetreibern und Herstellern für die Umsetzung der Energiewende. Sie wollen mit diesem Dokument Potenziale aufzeigen, um die technische und organisatorische Komplexität im Ausbau der Stromnetze zu reduzieren, die Digitalisierung voranzutreiben und die Umsetzungsgeschwindigkeit zu erhöhen ..."

Auf den Seiten 11/12 ist zu lesen: "Zur Vereinfachung der Integration könnte der Einsatz eines einheitlichen Stationsbusses geprüft werden, um Messwerte und Steuerbefehle über standardisierte Schnittstellen übertragen zu können. Dies erleichtert zudem eine Vorfertigung sowie spätere Erweiterungen. Dabei könnten Steckverbinder die aufwendige Einzelverdrahtung ersetzen. Für die Kommunikation mit übergeordneten Systemen (z. B. Netzleitsystem, IoT) wird die Standardisierung auf wenige geeignete Protokolle und einheitliche Datenmodelle empfohlen."

Hier klicken, um die Empfehlung herunterzuladen [pdf, 2,1 MB].

Spätestens jetzt wird den meisten Lesern die Normenserie IEC 61850 in den Sinn kommen! Oder?

Mit dem neuen IEC61850-Protokoll nach IEC 61850-8-3 (aktuell in der CD-Kommentierung) ist die allgemeine Kommunikation (ohne GOOSE und Sampled Values) innerhalb und außerhalb der Ortsnetzstationen ein sehr gut geeignetes Protokoll, das die einheitlichen Datenmodelle, das Engineering und die Konfiguration der Normenreihe unverändert verwendet!

Ich bin gespannt, wie die Reaktionen ausfallen!

Erste Reaktionen (sehr positiv!) sind hier zu finden.

Update on Traffic Engineering with IEC 61850

The other day I have discussed Traffic Engineering with IEC 61850. In a second post today I showed how SCL can be used to validate incoming messages.

Now I will show you in the analogy of traffic control how limits on the street are signaled. Fotos by Karlheinz Schwarz. 

First example Maximum Load Limit on a bridge: 

Second example with three limits: one vehicle at a time, max gross weight, and max speed:

Third example: max Tunnel hight 4,00 Meter

I guess you understand that IEC 61850 SCL can be used to configure signals for limits ... 

Enjoy. 

Cyberattacks Targeting OT Systems and IEC 61850

According to Security Week, "Hackers targeted operational technology (OT) systems at two private water utilities in Colorado in late August, apparently attempting to cause disruptions.

Few technical details are available, but it seems the attackers targeted industrial control systems (ICS) at the water utilities, which serve fewer than 200 people. 

A spokesperson for Colorado Governor Jared Polis told The Denver Post [paywalled] that the attackers changed equipment settings, disabled remote access and alarms, and altered pumping cycles. However, the disruptions were brief and did not affect water services or public safety."

I highly recommend small and all electric power utilities to pay attention to this situation and improve the cyber-security of the power system devices like SCADA, control, protection, RTUs, ... changing equipment settings could cause dangerous situations like blackouts, ... 

IEC 61850 information models can play an important role when somebody wants to change settings of a process control signal. The other day I used the IEDScout from Omicron to limit the setting value of a CDC=APC (Analogue Setting) structured setting. I set the maxVal to 1,000 (in the server) and tried with a second instance of IEDScout as a client to set the process value to Oper.ctlVal > maxVal ... the server responds with an MMS Write-Error and a Report "Inconsistent-parameters". The server did not accept a value outside of the maxVal and minVal. The process value did not change at all!

This possibility is a standardized (kind of "security") function incorporated into the CDC=APC !!!

Sure, the maxVal and minVal should be blocked for online changes! That could be configured in the CSL file as well.

So, IEC 61850 and especially SCL provide more than just a communication configuration ... many function related definitions are defined for the various common data classes!!

Let me know in case you want to further discuss this.

P.S.: After I published the above post I came across the following LinkedIn post   

CVE-2025-6625 — Improper Input Validation
> Crafted FTP command can take the controller offline
> CVSS 7.5 — network reachable, no auth, availability hit
> Energy, water, manufacturing fleets still run these PACs

Input VALIDATION is a crucial issue ... YES!

P.S2.: I just read another post on LinkedIn regarding DNP3 message validation. Interesting.

P.S3: Update

What is IEC 61850-8-1 MMS Compared to IEC 61850-8-3 DMS?

The paper "The Standard Message Specification for Industrial Automation Systems ISO 9506 (MMS)" has been downloaded 6,691 times from the ResearchGate ... seems to be an interesting document. 

Now, since we are working on a new protocol standard for IEC 61850-7-2 Client/Server communication (IEC 61850-8-3, DMS, Direct Message Specification), the question is: What is the difference between MMS and DMS?

Here are some answers:

DMS will be an alternative protocol for MMS ... with WebSocket connectivity, ASN.1 message schema, ASN.1 JER JSON encoding, ... very simple ... a straight forward from IEC 61850-7-2 ACSI (abstract messages) to concrete messages ... 1:1 ... no tricks ...

There are a few crucial aspects: (1) MMS as a standard that needs outdated OSI upper layers, (2) MMS is very complex and does not easily fit for IEC 61850-7-2 ACSI ... needs a tricks mapping to MMS in IEC 61850-8-1, (3) DMS communicates over WebSockets (bidirectional), (4) DMS uses JSON for message encoding (or DER binary) many tools are available, (5) the message schema of DMS is far simpler than the MMS message schema ... even both are using ASN.1 as schema notation, (6) MMS is not a good friend of many experts, (7) the Proof of Concept for RTI2 (Netherlands DSOs) is the basis for IEC 61850-8-3 ... and available at GitHub ...

From an system point of view (engineering, SCL, Models, abstract services, ... application functions, ...) there is no difference between the two protocols. From a smart implementation point of view the "stacks" could have an API that is independent of the protocols. There needs to be a tiny layer that decides if, e.g., a Report (with the payload from the application models) is wrapped with MMS or DMS ... for DMS there are two options: JER (JSON) and DER (binary) ... from a DMS stack point of view there is one line of code (!!) that is needed to encode in JSON or binary ...

Of course, the MMS message syntax and encoding are not compatible with DMS message syntax and encoding. BUT: they both carry the same payload!! ... thanks to the huge list of standardized "Signals" (models).

Both solutions run on TCP/IP ... there may be multi-protocol IEDs available some time down the road ... as we see today that many IEDs are supporting multiple protocols ... 

People asked me: Why did you not have this solution developed earlier?!? I developed something with my granddaughter when she did her Bachelor at KIT ... check my blog with some historical discussions

IEC published the Committee Draft (57/2980/CD) on IEC 61850-8-3

The next step of the publication of IEC 61850-8-3 has been reached

Yesterday (2026-09-04) IEC published the Committee Draft (57/2980/CD) on

"Communication networks and systems for power utility automation –
Part 8-3: Specific Communication Service Mapping (SCSM) –
Mapping to Direct Message Specification (DMS), JSON Encoding Rules, and WebSockets"

The commenting period closes on 2026-10-30 ... very soon.

All experts that are members of the IEC TC 57 National Committees can access the document and provide comments online.

My experience with the editing processing tool (OSD - Online Standards Development) is very positive: After I finished the editing on Monday (2026-08-31) IEC could easily publish the CD ... the document follows automatically the format of IEC ... because it is an IEC (ISO) tool ... perfect.

The crucial definition is the ASN.1 message schema that is used to code and decode messages (see see below for a link to the ASN.1 schema used in the RTI2 open-source software):

The committee draft (57/2980/CD) is based on the Netherlands Netbeheers Proof of Concept for RTI2 (real-time interface). Netbeheer is supporting the implementation as open-source software under GitHub. The message syntax of the committee draft is the latest ASN.1 module. The ASN.1 version at GitHub is a pre-version of the official version:
General: https://github.com/Netbeheer-Nederland/iec61850-websocket

Direct Access to the ASN.1 Schema: https://github.com/Netbeheer-Nederland/iec61850-websocket/blob/main/src/ws61850/asn1/schema/ws_iec61850_tpaa_full.asn

Please check my blog for additional information on IEC 61850-8-3.
Any question? Please let me know.

IEC 61850 for Newbees - Traffic Engineering with IEC 61850-6 (SCL)

I agree: The standard series IEC 61850 is quite comprehensive ... some believe it is complex. Ok. What can I do to help you getting a better understanding? I will try to help you. 

Today I will show how IEC 61850-6 (SCL, System Configuration Language) can be used for traffic engineering - traffic means: "signals" are communicated back an forth: analogue measurements, status measurements, control, configuration, event-driven reports, event-driven logs, ... start and stop of event recorder, trip-signals, ... in IEC 61850 "signals" are named and a binding of an instance to the application process (e.g., Bay1 Circuit Breaker 2) is specified ...

I am using a brief prose language ... this description could be transformed to an SCL compliant (machine processable ) XML file.

The many "signals" are travelling from a source to a destination ... let's say the following valid (allowed) routes are:

1. A->B,
2. B->A,
3. V->A,
4. A->C, 
5. D->E, 
6. R->S, 
7. R->A

Each letter is representing a source or destination of the "signal" flow. The "->" is representing one of the specific "signals" standardized in IEC 61850. In the first route A sends an operate to B and B is reporting back to A a changed status information ...

In SCL we can configure now for each route in detail the sources, destinations, strongly typed "signals", communication services, ... The SCL compliant System Configuration Description (SCD) would list all details on all routes ... 

The source knows by the SCD document which "signal" is to be sent (when and how) to which destination. The destination knows by the SCD document which "signal" it receives (from which device, when and how).

What else can we do with the SCD file?

1. A tool could check if all source and destination (devices) are specified ... a source A is configured to send a signal to B ... Is B at all specified? Maybe it was forgotten.
2. A tool could check if for all source and destination devices the addresses are configured. 
3. Another tool could check if all traveling "signals" (messages) are specified in the SCD document. A "signal" that travels during online operation from X to B (here X tries to connect to B) is not specified and thus NOT ALOWED. The tool could rase the red flag telling the system engineer that an unknown device X is active on the network. 
4. ... many other possibilities are listed in the following figures from my seminar slides (some 10+) years old.

I hope you got an impression what IEC 61850-6 (SCL) could provide.

SCL is the backbone of IEC 61850!

Check HERE for a crucial use-case for SCL (cyber security ...).

Let me know if you have a question on this post.
P.S: Update

Sample of an IEC 61850-8-3 request-response message sequence using JSON

The standard IEC 61850-8-3 under preparation will use ASN.1 JER (JSON) encoding. In order to understand, what that means check the following message sequence of the service (copied from the Wireshark trace, without WebSocket, TCP/IP, ... headers).

Note that you can use the Open Source Software of the PoC (Proof of Concept) to let client and server exchange real messages ... enjoy!

getLogicalDeviceDirectory

    { "request": {

            "associateId": "cp1",
            "invokeId": 1,
            "service": {
                "getLogicalDeviceDirectory": {
                    "ldName": "LD0"
                }}}}

    { "response": {
            "associateId": "cp1",
            "invokeId": 1,
            "service": {
                "getLogicalDeviceDirectory": {
                    "lnName": [
                        "LLN0",
                        "LPHD1",
                        "DWMX1",
                        "DGEN1",
                        "MMXU1"
                    ]}}}}

setDataValues

   {"request": {

            "associateId": "cp1",
            "invokeId": 56,
            "service": {
                "setDataValues": {
                    "ref": {
                        "ref": "LD0/LLN0.Mod.ctlModel",
                        "fc": "cf"
                    },
                    "dataAttrVal": [
                        {
                            "data": {
                                "enumerated": "2"
                           }} ]}} }

    {"response": {
            "associateId": "cp1",
            "invokeId": 56,
            "service": {
                "setDataValues": null
            }}}

    

Any question? Guess there is likely no need to ask, what this is ...

Search for "8-3".

IEC 61850 for Power Quality — solving the PQA integration problem

IEC 61850 has solutions for a lot of systems where currents and voltages are crucial ingredients of a system. Click HERE for a list of use-cases.

One of the practical challenges for TSOs (Transport System Operators) and DSOs (Distribution System Operator) is the integration of Power Quality Analyzers into utility monitoring systems. 

Traditionally, each PQA (Power Quality Analyzer) manufacturer has its own communication interface, data structures and software tools, so integrating equipment from different vendors often requires developing and maintaining vendor-specific drivers, especially when detailed PQ parameters and events are involved. IEC 61850 offers a good way to address this problem. 

Vendors like SATEC offer PQA ... e.g., PM180 is an example of a Class A Power Quality Analyzer where IEC 61850 is used not only for basic electrical measurements, but also for Power Quality information. PQ parameters, harmonics, frequency-related information, events, alarms and status can become part of the IEC 61850 information environment instead of remaining accessible only through a proprietary PQA interface. 

Client/Server (Reporting etc.) can be used for measurements, PQ parameters, events and monitoring, while GOOSE provides fast exchange of event and automation information. PMU functionality is also available for synchronized measurement applications. For a TSO or DSO, the key benefit is architectural: instead of integrating every new PQA through another proprietary driver, Power Quality devices can become part of the same IEC 61850 infrastructure already used for other substation IEDs.

Click HERE for accessing the corresponding ICD document (IED Capability Document).

The new IEC 61850-7-440:
Basic communication structure –
Compatible logical node classes and data object classes – Power quality metering

will contain the following PQ specific Logical Nodes (currently in IEC 61850-7-4 Ed2.1):

• Flicker measurement Name: MFLK 
• Harmonics or interharmonics Name: MHAI .
• Non-phase-related AC harmonics and interharmonics Name: MHAN 
• Metering single phase Name: MMTN
• Metering 3 phase Name: MMTR 
• Frequency variation Name: QFVR 
• Current transient Name: QITR 
• Current unbalance variation Name: QIUB
• Voltage transient Name: QVTR 
• Voltage unbalance variation Name: QVUB 
• Voltage variation Name: QVVR

Other vendors have similar PQAs ...

Siemens PCS7 (TIA) PowerControl Station Gateway connects PLCs with IEC 61850 IEDs

In a post earlier today I wrote: "It does not make sense to decouple power systems from big(ger) applications." ... this reminded me to discuss another use case ... factory automation to substation ...

Siemens offers PLCs with the PCS7 family. They have developed gateways that bring the substation closer to the power user ... 

PCS 7 PowerControl Station Gateway connection of a SIPROTEC 5 protection device (speaking IEC 61850!)

The brochure states at the beginning: "In addition to the demanding process automation requirements in many industrial plants, it is also necessary to integrate the medium-voltage power supply switchgear into a complete automation system.

Components of such plants are electrical consumers with high energy requirements (factories, chemocal plants, ...). Individual consumers are monitored and controlled via protection devices, also known as IEDs (intelligent electronic devices)."

So, my statement on the post earlier today has been confirmed! 

The same is available for the integration of a substation into a Siemens TIA (Totally Integrated Automation) ... TIA Station Gateway: excerpt of that page:

"With the new IEC 61850 server functionality, you can extend your station gateway integration allowing you to reliably publish process data directly to IEC 61850 clients via GOOSE Publisher or MMS polling and reporting with a high degree of performance. Whether protection systems, instrumentation and control or automation environments: The publisher ensures that events are quickly transferred and facilitates fixed data models and the highest degree of interoperability."

WOW.