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.

Is IEC 61850 an old Standard?

What do you think? It depends ... IEC 61850 is a standard series of many parts ... published in different years ...

The other day I was reading that somebody on LinkedIn beliefs that IEC 61850 is old ... Oops. Here is what I answered:

I was involved in the development of MMS (ISO 9506, starting mid 1980s), later in ICCP (TASE.2, IEC 60870-6, using MMS), then IEC 61850 (starting 1995, using as well the "old" MMS). 

The AC interconnected power systems have been developed more than 130 years ago ... and improved since then ... AND: Yet we do not complain that they are OLD. They have done a great job. Old wine may be better than young wine ... or?

The standard series IEC 61850 has many aspects to consider: 

• System Configuration Language (SCL, IEC 61850-6) is brand new! 
• GOOSE and sampled values are brand new! 
• The many standard "signals" like MMXU.Hz for frequency measurement are old in the sense that frequency is a physical given.
• There is something we may call "old": the use of the "old" MMS as the protocol for client/server communication according to IEC 61850-8-1 (-8-2). ok.
• There is an alternative new web-based solution under way: IEC 61850-8-3 (a new protocol for client/server in IEC 61850 ... WebSocket transport, ASN.1 message schema, ASN.1 JSON encoding rules, and ASN.1 DER encoding rules).

If you want to learn why the Netherlands DSOs initiated the IEC 61850-8-3, check HERE.

A great reply says: "The transport choice is what stands out: MMS was never reachable from a browser, WebSocket with JSON encoding is, which changes what client tooling can be without an install."

There are other brand new parts of IEC 61850 just published, e.g., IEC 61850-7-410 for hydro, gas, and steam power plants.

Are WebSockets the future for real-time communication?

WebSockets provide a way for web browsers and cloud apps to talk directly to devices for automation and monitoring. A WebSockets create a two-way open communication channel. It wraps messages (according to various message schema, e.g. in ASN.1 notation) in web-friendly formats like JSON. This bypasses strict firewall rules without needing complex, heavy software.

WebSockets are used in many solutions like OPC UA, OpenADR, ... and soon in IEC 61850-8-3 (alternative for MMS). 

How do WebSockets perform in a PLC environment where usually special industrial communication protocols are used? An interesting paper discusses this question:

"Latency Analysis of WebSocket and Industrial Protocols ..."

WebSockets are likely to becoming the future standardized web-based "carrier". 

The Netherlands Distribution Service Operator have shown with a PoC (proof of concept, now used for the definition of IEC 61850-8-3) that standardized (!) WebSockets can exchange IEC 61850 standard(!) messages containing data values produced and consumed by the huge amount of standardized (!) IEC 61850 models, configured by a standardized configuration (!) language (SCL, IEC 61850-6), and encoded in a standard (!) JSON format.

Background information can be found in my video

Feedback on LinkedIn: "This presentation made everything much clearer! But seriously, using WebSockets as a transport for industrial protocols is a really good idea."

Free ASN.1 Browser for IEC 61850-8-3 ASN.1 Module from RTI2 PoC

If you want to browse easily the ASN.1 message schema for the new project IEC 61850-8-3 (DSM) underway, check out this free browser: 

https://www.nettedautomation.com/editor

A preliminary asn.1 module for IEC 61850-8-3 (from PoC of RTI2) is available for download:

This is how it looks like:

and ...

The schema is very simple compared to MMS for IEC 61850-8-1.

Let us know if you have any question.

Extended Video on IEC 61850-8-3 Available - Example Messages

 An extended version of the video on  

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

is available. I have added some five minutes ... total time is 23 minutes.

I have added mainly two examples of services for IEC 61850-8-1 (MMS) and IEC 61850-8-3 (DMS):

The figure above shows how a client can get the list of logical nodes from the server with MMS ... and with DMS:

Details can be watched in the video ... enjoy.

IEC 61850 Series for Any Automation Domain using Electric Power (two Examples)

The standard series IEC 61850 is applicable for simple applications and huge systems. The standard is not restricted to a specific domain. Like electric power is everywhere. So could IEC 61850 be everywhere.

I have discussed this briefly in the context of a LinkedIn post.

Now it's time to discuss briefly two simple applications ... just looking at the two models ... without further explanations.

The German FNN Steuerbox

The Steuerbox is mainly providing schedules for the interface between the grid and the power user:

This model is defined for a special use-case: Steuern (remote control). No need for an engineering tool ... it is just a fixed model ...

The Netherlands RTI (Real-Time Interface) for power generation (> 1 MW)

... this is a fixed model with some details:

The RTI models and services are currently using IEC 61850-8-1 (MMS) communication (RTI 1). The RTI 2 will finally use the IEC 61850-8-3 (DMS) once it is specified. A Task Force has started to specify the new standard in May 2026.

The fixed models allow for a high level of interoperability. The central systems (representing the IEC 61850 clients) can communicate with and IED following these specifications. In the case of the FNN Steuerbox it has been proven that the client application could talk to all steuerboxes in the field without paying attention to which vendors device it is talking to.

REAL INTEROPPERABILITY !!

Why is there an Need for an Additional Service Mapping in IEC 61850 (IEC 61850-8-3)?

The two service mappings for IEC 61850 are IEC 61850-8-1 (MMS) and IEC 61850-8-2 (MMS/XML). The mapping IEC 61850-8-1 is in operation from the first days when IEC 61850 was implemented and used ... all over ... in millions of devices and thousands of systems. Ok ... perfect.

Why is there an need for an additional service mapping in IEC 61850 (IEC 61850-8-3)? 

Simply because of the complex and tricky mapping to MMS (Manufacturing Message Specification, ISO 9506). 

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

In order to explain details of the new approach to be used for the new work item proposal IEC 61850-8-3 I have produced a 17 minute video (updated version 2026-06-04, 23 minutes).

It is likely that this will become a major shift in the use of IEC 61850.

Enjoy!

The PAC World Magazine Reports From the 30 Year Anniversary of IEC 61850 in September 2025

The 30 year anniversary of IEC 61850 in September 2025 was a big success.

The report mentions me: "The presentations were bracketed by the first one from Karlheinz Schwarz about how all of this started in the past Millenium ..."

I am very thankful for the invitation by Dr. Fred Steinhauser (Omicron) to speak about the history ... 

Click HERE for the Report in the PACW.

Click HERE for more photos and a link to my "Millenium" presentation.

When browsing the Web, I see many more papers, reports, posts, ... on IEC 61850 for substations and for applications beyond substations.

More to come: With IEC 61850-8-3

New Work Item Proposal on IEC 61850-8-3 has been accepted by 95 % of the TC 57 National Committees

In December 2025 the NWIP (57/2866/NP - proposed project number: IEC 61850-8-3) was published for voting and comments:
https://blog.nettedautomation.com/2025/12/long-awaited-christmas-gift-for-smarter.html

Today we are happy that the NWIP has been approved by IEC - only one country disagreed in the voting process.

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

The result of this work will very likely change the usability of IEC 61850 outside substations.

Stay tuned to follow the progress.

In order to explain details of the new approach to be used for the new work item proposal IEC 61850-8-3 I have produced a 17 minute video (2026-05-13).

IEC 61850: Work-around for MMS

Very interesting paper just published ... presenting a work-around for MMS ;-)

Integration Method for IEC 61850 into Legacy and Modern PLC Systems

I am a little bit surprised ... when I worked for Siemens (Karlsruhe) I published two papers in the year 1991 (35 years ago!) expecting that MMS could be implemented into a PLC:

Click HERE for the paper “Bridging MAP to Ethernet” [PDF, 720 KB, 1991]

Click HERE for the paper “Fieldbus standardization: Another way to go” [PDF, 720 KB, 1991].

Today we know that MMS could be integrated into PLCs ... 

Gateways work always - definitely.

The expected new work on IEC 61850-8-3 (another mapping than to MMS) would change the situation tremendously:

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

Click HERE for more information on the planned project.

Long Awaited Christmas Gift For Smart(er) Grids - IEC 61850-8-3 is on its Way

In order to explain details of the new approach to be used for the new work item proposal IEC 61850-8-3 I have produced a 17 minute video. (2026-05-13)

IEC TC 57 just published a long awaited and crucial new work item proposal: 

57/2866/NP - proposed project number: 61850-8-3

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

Closing date for voting on the NP: 2026-03-06

"IEC 61850-8-3 Ed.1 defines the direct mapping of the client/server services of the ACSI (Abstract Communication Service Interface) defined in IEC 61850-7-2. Direct mapping means that for every abstract client/server service of the ACSI a concrete message schema (for the request and the response) is defined in ASN.1 (Abstract Syntax Notation One). ...

The encoding of the messages according to IEC 61850-8-3 is using the ASN.1 JER (JSON Encoding Rule, ISO/IEC 8825-8:2021). The messages are exchanged through WebSocket (RFC 6455, The WebSocket Protocol). WebSocket is a communication protocol that enables a persistent, full-duplex communication channel over a single TCP connection, allowing both the client and server to send data to each other at any time. This differs from the standard HTTP request-response model, making it ideal for real-time applications."

Please contact your national IEC TC 57 committee for a copy of the NP.

The main differences between IEC 61850-8-1/8-2 and 8-3 are shown in the following table:

and here:

Enjoy!

Click HERE for additional information that discusses the need for a modern messaging solution ...

I look forward to continuing the editing work of this new part of IEC 61850. This closes the circle of my contribution to communication protocols: starting in the mid 1980s with MMS (base for IEC 61850-8-1/8-2) and now (40+ years later) involved in a modern approach using web technologies ... Wow ...

This NP is the result of a Proof of Concept (PoC) initiated and managed by the Netherlands Distribution System Operators (Netbeheer). I played a little role in the implementation of this PoC. The PoC demonstrated the great benefit that can be harvested from the solution!

It is very likely that this part IEC 61850-8-3 (once it is finished) will accelerate the application of IEC 61850 outside the substation domain. I have discussed IEC 61850 outside of substations for many years ... Let me know what you think.

I wish you a merry Christmas and the best for the year 2026.

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!

Looking for an Open Source Multi Protocol Gateway for IEC 104, TASE.2/ICCP, IEC 61850, OPC-UA ...?

The standards IEC 60870-5-104, IEC 60870-6 (TASE.2, ICCP), IEC 61850, OPC-UA and other (often legacy solutions) are crucial for the power delivery systems all over!

Therefore the ability to translate from one protocol to another is a key feature for every TSO (Transmission System Operator). As the needs are growing and the number of use cases are flourishing (e.g. RTE needs thousands of instances of MPG (Multi Protocol Gateways), they are incented to look for a highly cost effective solution. On this observation, Swissgrid and RTE decided to take over that challenge by initiating a Proof of Concept on an open source basis - according to a news published at LinkedIn the other day.

Title: "First step toward an Open Source multiprotocol Gateway initiated by Swissgrid and RTE"

Click HERE for more information posted at LinkedIn.

Sebastien HENRY (Directeur SI & Télécommunications chez RTE Réseau de Transport d'Electricité) said: "RTE is committed to invest in open source for the development of an ecosystem of IT solutions for the energy sector. I am very confident in the fact that with the multiprotocol gateway, a small piece of software widely needed in our infrastructures, will demonstrate this strategy worth being followed."

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

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

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

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

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

The Companion Standards have been developed for specific applications:

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

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

Cover page:



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



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



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

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

IXXAT Smart Grid Gateway With NEW Possibilities

IXXAT (HMS) has offered their Smart Grid Gateways for some time. Click HERE for some blog posts that give you a good overview of the possibilities so far (HERE for HMS or HERE for Beck).
The other day IXXAT has published an extended range of possibilities to share information between many different communication solutions in almost ALL automation applications:

SG-gateway IO
SG-gateway M-Bus Master
SG-gateway EtherNet/IP
SG-gateway PROFIBUS
SG-gateway PROFINET

New:

SG-gateway Media Converter
SG-gateway Switch

All types support as well:

Modbus-RTU master/slave via RS232/485
Modbus-TCP master/slave
DHCP server, SNTP, Network trace (pcap), SNMPv2c
OPC-UA server
MQTT
Codesys network variables

Optional:

IEC 60870-5-104 client/server with redundancy (Norwegian User Convention)
IEC 60871-5-101 master/slave
IEC 61850 client/server (both roles and GOOSE pub/sub are supported simultaneous)
IEC 61850 GOOSE publisher/subscriber
Outstation DNP3
Hardware versions with 3G or 4G modem

Click HERE to visit the IXXAT website for an overview (German).
Click HERE to download a new 12 page pdf bochure (German).

IEC 61850 For Monitoring Data - Private or Standard?

One of the most crucial issues in the management of energy systems is: HOW TO share or exchange useful information generated by a myriad of sensors and applications needed by hundreds of applications?

Lets assume that lakes of information are generated every second. Usually this information is stored in silos of vendors specific solutions and communicated using one or more vendor specific communication solutions ... as shown in the following sketch drawn by our grandson Jan Oliver:



The expectations to apply IEC 61850 are high! BUT quite often vendors argue, that it is easier to use their private solutions - faster and saves time and costs! This may be true for the first phase of a project - but in the long run and in the view of the life time cost it may be completely opposite.

Three experts from Vattenfall DSO (Sweden; Vincent GLINIEWICZ, David EROL Anders JOHNSSON) have reported at the CIRED conference 2019-06 in Madrid (Spain) from an implementation of a pilot project using IEC 61850 and CIM  with the title:

LEVERAGING INDUSTRY STANDARDS TO BUILD AN ARCHITECTURE FOR ASSET MANAGEMENT AND PREDICTIVE MAINTENANCE

Excerpt from the paper:

"... However the data unfortunately currently often remain unused and unshared outside of the substation or specific silos for various reasons, some technical (e.g. cyber security, system incompatibility), some and organizational (e.g. vendor lock-in, siloed applications and organizations).
Additionally, with an increasing number of use cases requiring access to information, there is a growing number of information flows needed not only between data sources and central level applications but also between these central level applications. Without an IT architecture that allows reuse of information flows, there are legitimate concerns that the opportunities that digitalization promises might be delayed and costly or even worse, not be achievable.
As a result, Vattenfall Eldistribution sees a standard based integration approach as a cost-effective approach that seems to offer in the long run low integration costs and more importantly a greater flexibility, going from supplier specific integrations to a more generic approach. ...

We would also like to highlight some of the deviations from the standards that were observed during this pilot:

The pilot made use of a REST API towards the real time data historian (RTDH in fig. 2), although there was no mention of REST in the 61968-100 standard. One could however expect, given the increasing popularity and use of RESTful services in most industries, that the standard will soon follow and that the mention will be added in a further edition on the standard.
The gateway used in the pilot was a prototype base on a technical report (IEC TR 61850-90-2) [Using IEC 61850 for communication between substations and control centres] which is not yet a standard. This might explain why there doesn’t seem yet to be a complete and robust 61850-90-2 compliant product on offer in the market. Another alternative considered for the pilot gateway was the use of IEC 61850/MMS towards the substation and the use of web services (either RESTful+ JSON or SOAP) to communicate northbound instead of the IEC 61850/MMS used in the pilot. SOA has indeed a robust and well developed architecture for distributed computing, and this should be leveraged. There however did not seem to be any products available on the market. This alternative will be explored in a coming pilot. ..."

The paper concludes:

"Although the pilot was made for a primary substation, the widespread use of the IEC 61850 standards series make the results of this pilot not only applicable for primary substations, but potentially also secondary substations and microgrid.
Following the successful pilot, the next step is to look at how to fully implement and verify the concepts in a real substation and to secure production grade components where prototypes have been used as well as test the architecture through other smart grid use cases."

Click HERE for the full paper.

I have run an UCA/IEC 61850 pilot project with Anders Johnsson some 20 years (!) ago:

Two reports out of this pilot project and other discussions have been published in 2002:

Wind Power Communication
Verification report and recommendation

Click HERE for the Report.

Wind Power Communication - Design & Implementation 
of Test Environment for IEC61850/UCA2

Click HERE for the Report.

Enjoy the reports.

By the way: It took some 20 years to understand that the mapping of IEC 61850 models and communication protocols to MMS (ISO 9506) should be extended by a much easier and simpler mapping to JSON and, e.g., MQTT or http ...

It is not too late for such an additional standardized mapping ... e.g., as IEC 61850-8-3.

It may take another 10 years before this becomes true! Hope it will happen a bit earlier!

Further reading on the subject see discussion of IEC 61850-8-1 versus 8-2 (by 2024-02-25: 4074 visits of the post since July 2019).

Other people have similar ideas and published the following paper:

International Electronical Committee (IEC) 61850
Mapping with Constrained Application Protocol
(CoAP) in Smart Grids Based European
Telecommunications Standard Institute
Machine-to-Machine (M2M) Environment

Beck IPC offers MQTT@CHIP in addition to IEC 61850 and other protocols

Beck IPC (Wetzlar, Germany, a subsidary of HMS) is known for their solutions on a single CHIP offering support for IEC 60870-5-104, IEC 61850, Modbus, CANBus, Profibus, Profinet, OPC UA, ... now offers MQTT@CHIP as an additional solution.



The MQTT can be configured on the WEB PLC like it is implemented for other protocols:



In the above example I have mapped a signal from an IEC 61850 Server the signal MMXU1.TotW.instMag.f to a MQTT message. This way you can tag the signal as a JSON Object!!

JSON Objekte:
{ „MMXU01.TotW.instMag.f“:  2325, „MMXU01.Hz.instMag.f“:  49.98 }

Message specification:



This way you can send MQTT messages with values from any other protocol or from the IEC 61850 client or server model. This way you can even map to/from GOOSE messages.

I have used the solution running on the IXXAT Smart Grid Gateway. The WEB PLC version 19.2 is required to run MQTT on the gateway.

Very well done!

Holistic Engineering and IEC Standards

One of the most crucial challenges in Electric Power Systems in the future is the fact that multiple aspects like planning, design, configuration, data acquisition, operation, protection, error detection, maintenance, ... security, ... at several layers (process, asset management, ...) are so co-joined with each other and interdependent.

Is this new? No! Some 400 years (!) ago, Rene Descartes was recommending to apply a holistic approach for all sciences ... he did not know the huge interconnected Power systems in Europe, China, USA, ... here is what he has written [extended by myself]:



I highly recommend to educate young people in a way that they get a holistic understanding of the many aspects of the electric power system ... focusing on one or two aspects may cause at the end of the day many problems. The main aspect still is to understand the physics of such a huge system. Any programmer of software impacting the safety of the power delivery system should be educated in physics and especially electrical systems. So, understanding MMS, IEC 61850 or OPC UA is good - BUT engineers should understand the process (electrical system) they are manipulating with some lines of code. Engineers should also be trained thoroughly in the many aspects.

Unfortunately there is quite often little budget for comprehensive training in several aspects. Ask your management for more training - better:more hands-on training!!

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.