IEC TC 57 WG19 proposes CIM Profiles to JSON schema Mapping

IEC TC 57 WG is discussing the use of JSON for transferring message payload

DRAFT 62361-104:
POWER SYSTEMS MANAGEMENT AND ASSOCIATED INFORMATION
EXCHANGE – INTEROPERABILITY IN THE LONG TERM –

Part 104: CIM Profiles to JSON schema Mapping

The introduction says:

"This standard is one of the IEC 62361 series which define standards that may be used by all
Working Groups within TC57. These standards address areas of interest that impact multiple
standards and provide consistency for implementations.
This part 104 describes a mapping from CIM profiles to IETF JSON schemas and defines the
rules that CIM JSON message payloads must adhere to.
The principle objective of this part 104 is to facilitate the exchange of information in the form of
JSON documents whose semantics are defined by the IEC CIM and whose syntax is defined by
an IETF JSON schema. ..."

JSON is applicable for encoding of CIM (IEC 61968/70) message payload and - as I believe - also for IEC 61850 message payload!

By the way: The post on "IEC 61850-8-2 Versus IEC 61850-8-1" discussing the use of JSON in addition to MMS/ASN.1/BER and MMS/ASN.1/XER has been visited 2,000 times since July 5, 2019 --> or 16 times per day.

Click HERE for additional discussion on the use of JSON ...

Why Is It So Easy To Map IEC 61850 Signals to JSON Objects?

IEC 61850 defines Device Models for the exchange of information between any two or more entities. The Models are structured as unique branches of a tree.That means:

Each path from the Device (Root) to 

any node or leave of the trees is unique

The signals are composed of an access reference (LDName/LNName.DOI. ...) and the value that corresponds with the path.

Example of two leaves:
LDName/Tran1STMP1.Tmp.mag.f = 23.5 (Temperature value)
LDName/Tran1STMP1.Tmp.units.SIUnit = °C (Temperature engineering units)

These are key-value pairs that could easily map to JSON Objects:

"LDName/Tran1STMP1.Tmp.mag.f " : "23.5"
"LDName/Tran1STMP1.Tmp.units.SIUnit" : °C

These JSON objects are

• Light-weight
• Language independent
• Easy to process with Python, ...
• Text based and human readable 
• JSON Schemas could support automatic (syntax and semantic) checks
• JSON is supported by many controllers

The controller of our PV inverter from Fronius has an http/JSON interface. The following request (lines 1-3) returns many common inverter data (line 21ff):



Lesson learned: Controller in inverter could easily provide an http/JSON interface.

The Device Model is a virtual model that could be configured using the SCL (System Configuration Language, IEC 61850-6). The Device Model is implemented in an IED and could be accessed to get the self-description, read, write, send/receive reports, publish/subscribe, ...

An IEC 61850 Server hosted by an IED could easily map the model to JSON objects that may be communicated with MQTT, HTTP, ...

The mapping to JSON is quite easy. It could be implemented by a simple automatic process that parses the model (SCL/XML), searches for the paths and concatenates the names from the root to the leaves to get the reference! AND: the mapping preserves the semantic - the meaning represented by the path name.

The mappings of IEC 61850 Models to IEC 60870-5-104, DNP3 or Modbus would result in messages that have lost the semantic of the signals. These solutions have mainly numbers as reference - these numbers have no meaning in the communication.

TÜV SÜD closes their IEC 61850 / UCAIUG Test Lab

TÜV SÜD (Munich, Germany) a long time provider of IEC 61850 Interoperability and Conformity Testing Services closes their Test Lab.
They emailed today says: "... Unfortunately, we do not supply Interoperability and Conformity Testing Services according to IEC 61850 any longer, which have been replaced by other focus areas in our portfolio. ...".
There was no specific reason for their decision provided.
You may ask me about my opinion. Here it is first brief statement:

• The standard series IEC 61850 is very comprehensive - applicable in many different application domains. 
• Implementations of the communication software for Client/Server (MMS based), Publisher/Subscriber (GOOSE), general APIs, and appropriate IED specific configuration tools are very comprehensive (and very complex!) as well.
• The IEDs tested and certified will likely operate in applications that need many times more logical nodes (and associated FUNCTIONS) than what was tested to get a certificate.
• MMS is also very complex regarding services and protocol. Unfortunately requires a lot of best skills to implement ... it has been implemented very well by a few companies like SystemCorp.
• The most crucial aspect of IEC 61850 is the huge number of logical nodes (that represent so many functions). This semantic is of great importance to the energy industries.
• One of the key issues in the years to come is this: Use the semantic of IEC 61850 and configuration language and map the needed (usually very simple and restricted) semantic configured in a SCL file automatically to JSON-Objects and communicate the JSON encoded information via http(s) or similar protocols. 
• This will allow to use IEC 61850 in any project that requires to exchange the well defined semantic of IEC 61850. E.g., the semantic of the schedule logical node (FSCH and FSCC) can easily be configured in JSON. The underlying function (the SCHEDULING) needs to be implemented independently of using MMS/ASN.1 or JSON. The benefit of using JSON is here: Everybody that can program in Python or JS or ... can use the JSON encoded messages directly in the application program.
• I am working on such a solution that makes IEC 61850 really applicable for simple applications ... http(s) and JSON are used everywhere and can be applied by everybody.
• More to come!
• Stay tuned.

For those simple applications with a dozen of points or so ... there would be a need for just a very simple and basic interoperability and conformance test.

IEC 61850-8-2 Versus IEC 61850-8-1

Many people have complained that IEC 61850 is far too complex ... especially because of the mapping defined in IEC 61850-8-1 as the SCSM (Specific Communication Service Mapping) using ISO 9506 MMS as the carrier to exchange IEC 61850 client/server messages. MMS (Manufacturing Message Specification) offers generic objects (NamedVariables, NamedVariableLists, ...) and services (Read, Write, InformationReport, ...). The application of MMS for IEC 61850 requires to define very tricky mappings ...

Click HERE for downloading the FDIS of ISO 9506-1.
Click HERE for downloading the FDIS of ISO 9506-2.

As the convenor of ISO TC 184/SC WG2 (responsible for MMS for many years) I have supported MMS allover ... and I still do it. It is a solution that works well for years ... especially in the domain of substation automation. Other application domains, e.g., DER devices connected directly to a control center (without the need of horizontal communication with up to hundreds of devices), could make use of a lighter message service and mapping concept. The idea of using webservices was discussed many years ago. The IEC TC 57 set up a team to look into it.

The following document written in 2012 discusses the:

IEC 61850-8-2 Web Services Justification

Excerpt:
"IEC 61850/MMS is an open scalable suite of protocols that can support real-time operation. However, these protocols are not well understood by typical IT professionals that work in these stakeholder environments, even though the rich information models of IEC 61850 meets the semantic needs of the distributed applications. ...
Therefore it makes economic sense to map the rich abstract IEC 61850 information models to the more ubiquitously deployed and understood communication and security profiles.   This requirement can be satisfied by mapping IEC 61850 to web services, which are the most commonly implemented technologies.
IEC 61850/Web Services is not a replacement for MMS used in the substation.  Rather, IEC 61850/Web Services would be targeted to customer environments where information is used to interact with customer-owned equipment, including Distributed Energy Resources (DER) systems and facility energy management systems. In these situations, information flows between utility systems, customer systems, and third party systems, straddling utility and customer ownership, sometimes within a single application deployment.
The stakeholders deploying DER systems understand that IEC 61850 over web services provide least cost protocols to interact with their DER devices because:
• Web Services provide greater compatibility with widely deployed IT infrastructures, tools and skills, including cyber security.
..."

Finally the work ended in the following standard:

Communication networks and systems for power utility automation – Part 8-2: Specific communication service mapping (SCSM) – Mapping to Extensible Messaging Presence Protocol (XMPP)

The published document 8-2 uses principles of IEC 61850-8-1 as well as MMS services and protocols! Really? Yes. The main difference regarding message exchange is in the encoding of the MMS messages: 8-1 uses ASN.1 BER and 8-2 uses XML messages (with the structure of MMS services defined as XML Schema). Strange? Yes!

You can find the XML schema for the MMS messages using XML encoding here:

Code component of the IEC 61850-8-2, reflecting the XML namespace described in this document. It includes as well the virtual API with IEC 62351-4.

https://www.iec.ch/public/tc57/IEC_61850-8-2.2018_ed1.0.XSD.2018A1.full.zip

Summary on the protocol issues: IEC 61850-8-2 does NOT provide a direct mapping of IEC 61850-7-2 ACSI models and services to webservices!

I am involved in defining a third mapping (of a subset of services) ... to use JSON schema (and objects) for the models and the messages ... in order to offer really light weight messaging carrying a subset the original semantic of IEC 61850 models!!

We have successfully implemented client and server using http Get and Set services that carry JSON objects representing IEC 61850 Objects.

Example of DataSet and Report (showing the basic idea of mapping to JSON):



The decision to propose the JSON mapping officially to IEC TC 57 is expected later in 2019.

By the way, our granddaughter (20, Student in EE and IT) has implemented this example in Python running on Windows and on two Raspberry Pi3 (one playing the role of server and the other one as client).

We expect that this mapping will push the application of IEC 61850 models and services in domains that need simple solutions that can be programmed by many engineers and programmers.

The JSON mapping could easily be used as an interface from an original IEC 61850 Server (e.g., a bay controller or protection device) to underlying systems:



Sample JSON response from our Fronius PV Inverter with some values:

Request:
http://192..../solar_api/v1/GetInverterRealtimeData.cgi?Scope=Device&DeviceId=1&DataCollection=CommonInverterData

Response (JavaScript):



Stay tuned to learn more ...

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

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

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!

NEW IEC 61850 Demo Package for Windows available

The main purpose of the new demonstration and evaluation package is to provide a free of charge simple and easy to use IEC 61850 Client/Subscriber Tool (running on Windows PCs) that can be used to communicate with a Server/Publisher implemented on the platforms:

Beck IPC DK151 Development Kit for SC145 (DK61)
Beck IPC com.tom / IXXAT SG-gateways (WEB-PLC)
SystemCorp Smart Grid Controllers
Windows PC

Several other uses cases are possible:

The demonstration uses a single generic SCL model (and a derived JSON file [JavaScript Object Notation] that can (beyond the main purpose) be used on the above platforms to automatically configure (tree structured graphical applications) for Clients, Server/Publisher, and Client/Subscriber roles as shown on the next slides.

The specification of additional models (.icd and .json) could be provided for a fee. 

Contact NettedAutomation if you are looking for other models, please.

Click HERE for further details and instructions to download the new package including the documentation.

Click HERE for documentation only.

The package is used in our training courses.

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

Wow: IEC Goes XML and PSON

IEC provides access to crucial standardized information by modern web technologies:
The content of the Electropedia (The World's Online Electrotechnical Vocabulary) is now made accessible by XML documents and PSON (REST) through the opendata gateway.
“A json version of all subject areas (or IEV parts) in the Electropedia is available by calling the REST endpoint: “ https://opendata-api.iec.ch/v1/opendata/areas/ 



I expect that the PSON option will be made available for the complete vocabulary soon.

Enjoy!

More to come!

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.

40 Years Ago I Started Contributing To The MAP/MMS Standardization In Detroit (MI)

I have contributed to the MAP/MMS Standardization (Manufacturing Automation Protocols/Manufacturing Message Specification) from the very beginning. I was working for Siemens in the group dealing with communication solutions for process control and factory automation. In February 1985 I attended the first time a meeting of the MAP project at the GM TechCenter in Warren (Michigan, USA). As you can see, the first day was a very cold day (1985-02-14) with a lot of fresh snow:

I looked still young (40 years younger than today) ... 32 years old and father of four children.

The approach of MAP/MMS was very new ... even today a lot of people have difficulties with MMS ... especially because of using ASN.1 BER as the encoding notation for all messages exchanged according to IEC 61850 - Client/Server and Publisher/Subscriber messages!!

In 1993 I got also involved in the new IEC TC 57 project TASE.2 (Telecontrol Application Service Element 2) based on MMS ... called ICCP (Intercontrol Center Communication Protocol):

I attended the following meeting in Loveland (Colorado, USA):

30 years ago (March 1995) the IEC TC 57 decided to start a new project: IEC 61850 based on the EPRI UCA 2.0 Specification ... also using MMS/ASN.1/BER ... I got involved in UCA and IEC 61850 starting with the second IEC TC 57 WG 10 meeting end of 1995.

Many people in the electrical power world have complained since then that MMS/ASN.1/BER is toooo ... too much of ... and as a result many have departed from the approach.

I have suggested many times to use web services ... JSON encoding instead of ASN.1/BER and XML ... most people ignored the use of web services ... I guess it will come in the near future.

In many of the following standardization groups I have supported modern communication approaches ... in some cases it took some time ... or still is awaiting for a push:

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!

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.

IEC 61850 Products at CIRED June 3-6, 2019 - Madrid (Spain)

3-6 June 2019, Madrid, Spain

SystemCORP will participate together with Advantech in the CIRED Exhibition in Madrid, Spain. It promotes the SystemCORP ADH Software, a flexible and complete data communication and process automation package, fully integrated in Advantech data gateways.

Based on a distributed real-time database and application management system almost any SCADA communication protocol can now be used as client or server on Advantech modules. SystemCORP offers most commonly used communication protocols such as IEC 61850, IEC 60870-5, DNP3, Modbus and JSON/MQTT as part of a standard communication library for SCADA and Cloud integration. An integrated IEC 61131 compliant programmable logic controller (PLC) extends the capability of the ADH as a true virtual SMART Grid device ready to be installed in distribution automation and smart gird projects.

For application configuration, the eNode Designer, IEC 61850 ICD Designer and IED Configurator tools simplify system engineering and result in reduction of project costs and implementation time. No special tools are required for establishing secure communication with cloud applications.

To know more visit our booth no H1/G2 at the IFEMA North Convention Centre. Address: IFEMA, Av. Partenón, Nº 5, 28042 Madrid, Spain. Entrance is free.

For any more information please check the event website: http://www.cired2019.org/

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

New Application Example for EvaDeHon Package

We have posted a new example extending the use of the Evaluation, Demonstration and Hands-On (EvaDeHon) Package.

We will publish from time to time additional models and documentation for interesting applications. The objective is to help you to understand the various topologies and possibilities to use the IEC 61850 technology for the process information exchange.

One focus is on the application of the IXXAT (HMS) Smart Grid Gateways.

The example offers polling and reporting (Server on PC, Client on IXXAT WEB-PLC Gateway). The download contains the client CID for the gateway, the server CID and the JSON file for the PC. The gateway polls every 2 seconds and receives reports every 5 seconds - these intervals can be configured. Additionally it includes some specific documentation.



Click HERE for more information.