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:

IEC TC 88 Published Edition 2 Documents for the Series IEC 61400-25

IEC TC 88 has published the edition 2 of the following two parts of the series IEC 61400-25:

IEC 61400-25-4: Wind energy generation systems -
Part 25-4: Communications for monitoring and control of wind power plants -
Mapping to communication profile
The mappings specified in this part of IEC 61400-25 comprise:

•  SOAP-based web services,
•  OPC/XML-DA,
•  IEC 61850-8-1 MMS,
•  IEC 60870-5-104,
•  DNP3.

Click HERE for the Preview.

IEC 61400-25-6: Wind power generation systems -
Part 25-6: Communications for monitoring and control of wind power plants -
Logical node classes and data classes for condition monitoring

Click HERE for the Preview

Note that the mapping to MMS according to IEC 61850-8-1 is the most used communication protocol for applications in the Wind Power Industry.
The modeling approach and the models are now in general compatible with those defined in IEC 61850-7-x. This is a major step forward.
General gateway solutions for IEC 61850 could be used for wind energy generation systems to bridge from Profibus, ProfiNet, Modbus, CAN bus, ... to IEC 60870-5-104 or IEC 61850-8-1.

XMPP, XML, and MMS: Two New TC 57 CDVs available for Public Comments

IEC TC 57 has published the following two CDV documents and allows you access to them:

57/1823/CDV
IEC 61850-8-1/AMD1 ED2: Amendment 1 - Communication networks and systems for power utility automation - Part 8-1: Specific communication service mapping (SCSM) -
Mappings to MMS (ISO 9506-1 and ISO 9506-2) and to ISO/IEC 8802-3

57/1833/CDV
IEC 61850-8-2 ED1: Communication networks and systems for power utility automation - Part 8-2: Specific communication service mapping (SCSM) -
Mapping to Extensible Messaging Presence Protocol (XMPP) 

You can study these two documents and provide comments.

Click HERE for the access (need to register only).

XMPP is used here to transport the XML message payloads between IEC 61850 server and client. The main contents of the messages are MMS messages (defined in ASN.1) and encoded with ASN.1 XER (XML encoding rule) - instead of ASN.1 BER (basic encoding rule). 

Example (excerpt):

Quite interesting. Most of what you have understood of MMS (subset used in IEC 61850-8-1) is applicable for 8-2 as well.

Click HERE for an introduction to ASN.1 and a discussion of why we need encoding rules.

XMPP - IEC 61850-8-2 Defines Additional Communication Mapping

IEC TC 57 has published a first draft for an additional mapping of IEC 61850 information models and communication messages.

IEC 61850-8-2 (57/1583/CD):
Communication networks and systems for power utility automation - Part 8-2: Specific Communication Service Mapping (SCSM) – Mapping to Extensible Messaging Presence Protocol (XMPP)

Closing date for comments is 2015-09-11

The new mapping defines (relies on) the following definitions:

Service mapping (unchanged)
The abstract (client-server) services of IEC 61850-7-2 are mapped to MMS as defined in the existing IEC 61850-8-1 Ed2.

Message Encoding (new concrete encoding)
The encoding of the messages uses ASN.1 XER (XML encoding rule) – in addition to ASN.1 BER according to IEC 61850-8-1 Ed2. The encoding defines an XML schema – contained in the draft.

Model mapping (unchanged)
As in IEC 61850-8-1 Ed2. This applies to the flattening of the object identification and adding Functional Constraint (FC=ST or MX) in the path name and using “$” for “.”:

Bay5_MMXU1$MX$Hz$mag$i

Underlying Transport (new T-Profile)
The transport (exchange) of the XER encoded messages uses a new approach: using XMPP.

This new transport mechanism and encoding will be used between all kinds of utility Distributed Energy Resource devices and related power management systems, over any communication infrastructure including public networks.

The coming IEC 61850-8-2 can be understood as an (encoding and transport) extension of the existing IEC 61850-8-1.

It is very crucial that most parts of implementations and tools can be re-used! Re-Use is one of the basic approaches used in IEC 61850! Don’t start always from scratch – use what is available and add something.

So, to read the frequency of Bay5 is almost the same .. using the reference
“Bay5_MMXU1$MX$Hz$mag$i”
encoded in ASN.1 BER (IEC 61850-8-1) and in ASN.1 XER (IEC 61850-8-2).

See also example of encoding.

A second document explains the needs and background for an additional mapping:

IEC 61850-80-3 TR (57/1584/DTR):
Communication networks and systems for power utility automation -
Part 80-3: Mapping to Web protocols – Requirements and technical choices

It describes the requirements and the technical principles for a new specific communication service mapping (SCSM) based on Web Protocols.
For more information about the candidate technologies which have been analyzed but not selected as well as about the selection process used for choosing the technology, national committees are invited to consult document 57/1585/INF which is circulated in parallel:

Accompanying document to 57/1584/DTR, Proposed IEC TR 61850-80-3

It mainly describes the technical solutions which have been investigated but finally not selected for the SCSM of the IEC 61850 based on Web Protocols.

1. IEC 61400-25-4 Annex A (Web services)
2. DPWS (Devices Profile for Web Services)
3. REST (Representational State Transfer)
4. XML messaging over Websocket
5. ACSI XML Messaging
6. OPC UA

The finally chosen solution  “MMS XER payload over XMPP as transport” was recognized after several years of work as the preferred solution – especially from a fast time-to-market point of view.

What does XMPP provide?

XMPP (RFC 6120) is a middleware messaging and presence protocol supporting decentralized architectures and provides:

• Registering resources in publicly reachable servers
• Resolving resources based on names
• Security (authentication, integrity, confidentiality) for the communication with the XMPP server

This fits well to the information models defined in IEC 61850.

MMS & ASN.1 & XER & XMPP selected as the second SCSM of IEC 61850

The second SCSM for the ACSI Client-Server information exchange service models will be the mapping of the ACSI service models to MMS ASN.1 XER and XMPP. IEC TC 57 just released the 122 page document 57/1497/DC:

Draft IEC 61850-80-3 TR, Communication networks and systems for power utility automation – Part 80-
3: Mapping to web protocols – Requirement analysis and technology assessment

The document mainly lists the crucial needs and why the mapping to “MMS ASN.1 XER and XMPP” has been chosen to be published as IEC 61850-8-2 soon.

Chapter 7 presents the future SCSM 8-2, including an overview of the main selected technology: XMPP.

The following goals have been particularly considered for the definition of this SCSM:

• Identify a single profile supporting all the services required by the domains and defined today in ACSI.
• Cover the full life cycle of a IEC 61850 system, in collaboration with the System Management work in WG10 (from configuration, through conformance testing, down to maintenance). For this purpose, the present document may recommend some changes in other parts of IEC 61850 like part 6, part 10, etc.
• Deploy cyber-security to ensure a secure environment (in conjunction with IEC TC 57 WG 15 work).
• Propose rules for cohabitation with other mappings such as IEC 61850-8-1 and IEC 61850-9-2, and possibly recommend communication profiles depending on specific application context (pole-top equipment, inside DER, connection of DER, …).

Check with your national IEC TC 57 mirror committee for a copy of the above mentioned document.

Congratulation for the tremendous success of the web service mapping team!!! Great work!

That means: IEC 61850 will be the preferred solution in substations and many applications outside!!

Web Services for IEC 61850: MMS/XER over XMPP?

Some 18 months ago I have reported on a standardization project within IEC TC 57 defining web services as a second SCSM (Specific Communication Service Mapping) for IEC 61850. In the meantime it seems very likely that a mapping to XMPP (Extensible Messaging and Presence Protocol) will be used as the only mapping in the future IEC 61850-8-2.

The secretary of IEC TC 57 has presented a slide (slide 5) with the following requirements during a public event at the Hannover Messe 2014:

• “Part 8-2 Specific communication service mapping (SCSM) – Mappings to web protocols
• Comply with the new edition of IEC 61850-7-1, IEC 61850-7-2, IEC 61850-7-3, and IEC 61850-7-4
• Support the existing application data model defined in IEC 61850-7-410, 7-420 and 61400-25-2
• Identify which web services specification should be considered to deploy cyber-security, in conjunction with IEC TC 57 WG 15 work
• complementary to the existing SCSM (8-1), not competing”

He reported on the status of work: “Konsens bei XMPP als Lösung” (consensus to apply XMPP as solution).

Click HERE for the complete presentation of the secretary of IEC TC 57 during the Hannover Messe 2014 [German, pdf]

MMS messages encoded in XML (XER – XML Encoding Rules for ASN.1, ISO 8825-4) may be used as payload of the XMPP messages.

What would that mean for IEC 61850-8-1 (MMS ASN.1 BER encoded messaging) implementations? First: the 8-1 solutions would continue to be used. Second: an additional ASN.1 encoding rule would add some software at the encoding layer … and finally the addition of the “transport or middle layer” XMMP would offer a new “transport mechanism”. That’s it.

This way most of the IEC 61850 related software (API, datasets, reporting, logging, control, system configuration language, modeling and models, …) would be used unchanged!

By the way, using ASN.1 XER in addition to BER has been proposed and discussed some 20 years ago within ISO TC 184 SC5 WG2. It was too early.

Since MMS is independent of encoding, there seems to be no (technical) question to using XER.

Next Step towards a Web Service Mapping in IEC 61850

IEC TC 57 has published the

Draft IEC TR 61850-80-3 (Document 57/1292/DC):
Communication networks and systems for power utility automation – Part 80-3: Mapping to Web Services – Requirement Analysis and Technology Assessment

This document will serve as a basis for the creation of a new Specific communication service mapping (SCSM): the future IEC 61850-8-2.

The document (written by WG 17) is circulated in order to get feedback from a wider range of experts, mainly on the global approach and on the requirements of each involved domain.
The TC 57 P-members are invited to submit comments to this draft
by 2013-01-04 at the latest.

The following solutions are considered as candidates:

1. OPC UA
2. IEC 61400-25-4 Annex A
3. DPWS (Devices Profile for Web Services)
4. IEC 61968-100 (TC 57 WG 14 approach of using XML)
5. RESTful Web Services over Websockets
6. XMPP (Extensible Messaging and Presence Protocol)

It is still the objective to chose ONE of these solutions and publish it as IEC 61850-8-2 in the future.

Plug and Play for IEC 61850 – Supported by Siemens

Siemens pushes for a crucial extension of IEC 61850: to allow Plug and Play features for IEDs according to a future IEC 61850:

IEC 61850’s primary focus (in the late 90’s) was on Substation Automation – this is still the crucial application domain today and for a long time. The application of IEC 61850 in various power generation and distribution application domains is likely to require further features – not yet defined. Several projects (E-Energy in Germany, SGIP’ Priority Action Plan (PAP), and other) have investigated in finding gaps in the standard definitions. One result is the definition of a Plug&Play extension developed by Siemens. Siemens has registered their ideas at the ip.com website. What does that mean? “Defensive publishing is a low cost way to prevent competitors from obtaining patents and protect your freedom to practice.”

Click HERE for a description what “Defensive Publishing” means.

Excerpt:

“The Plug and Play reference architecture based on well-known protocols like UPnP (Universal Plug and Play) and DPWS (Devices Profiles for Web Services) is used. Several exchanges and additions, e.g. with respect to discovery mechanisms, are proposed enabling IEC 61850 to support Plug & Play for "Smart Distribution".”

Click HERE for more information.

The work on Web Services that has been proposed by a New Work Item Proposal will become a crucial work for future applications.

New Work Item Proposal on IEC 61850-8-2 – Mapping to Web Services

As expected, the New Work Item Proposal on Web Service Mapping has been officially published on 2011-10-07 for ballot:

Future IEC 61850-8-2: Specific communication service mapping (SCSM) – Mappings to web-services (Document 57/1181/NP).

Closing Date of ballot: 2012-01-13

In order to get a copy of the NP document contact your TC 57 national committee.

Major German RTU Vendor implements IEC 61850 instead of phased-out model IEC 60870-5-101 and 104

The IDS company based in Ettlingen (Germany) offers a gateway to collect data from many underlying protocols and converts them into IEC 61850 Models for the communication with control centers. They wrote in a recent publication that the classical RTU protocols IEC 60870-5-101 and –104 are phase-out solutions for the communication with control centers. One crucial issue they highlight is the semantic information models and self-description services defined in IEC 61850.

The same company was a very strong supporter for using IEC 60870-5-101 and –104 for the communication with control centers – and partly within substations. What I see these days: More and more people are changing their mind!

The protocol gateway (which is a server) uses for the uplink to the control center IEC 61850 information objects and web services according to IEC 61400-25-4 Annex A for the protocol. This combination (IEC 61850 models and IEC 61400-25-4 mappings) is technically feasible. Formally it is not defined in any standard!

That is why the gateway (server) cannot interoperate with any IEC 61850 client. It is a product that can communicate with a client according to IEC 61400-25-4 Annex A only.

The first reason they provided why they did not use MMS is as follows: MMS would require to have permanent TCP and MMS connections maintained! That is true for substation automation, where short reaction times for crucial spontaneous event reports are required. If the required reaction is in the seconds, there is no reason why a permanent connection should be required! MMS does not require permanent connections! A MMS client can close the connection as soon as a service is completed.

Click HERE for the paper published in the etz magazine [German only].

It is also important to know that (to my knowledge) most vendors implementing IEC 61400-25 are using the mapping according to IEC 61400-25-4 Annex C (MMS, IEC 61850-8-1): Bachmann, Beckhoff, Ingeteam, Siemens, …

Finally: a new work item has been proposed to IEC TC 57 (home of IEC 61850) to standardize a web service mapping as IEC 61850-8-2. The question is now: Which solution should be chosen or developed? Three candidates are already discussed and proposed for further investigation:

1. DPWS (Device Profile Web Services)
2. OPC UA WS
3. IEC 61400-25-4 Annex A (as a starting point)

Nobody knows which solution will finally be standardized for IEC 61850 and how long it will take. There may be additional candidates proposed during the official ballot on the new work item once it is out for ballot … may be by end of 2011. Hopefully we will see a single solution being published in 8-2. Nobody knows.

Having multiple standards for the mappings means: split the market in non-interoperability domains!

Click HERE for a further a discussion on web services.

Mapping IEC 61850 on Web Services

Just a few hours after my post on

Message Specification and Encoding – A Never Ending Story

earlier today I received an email with a very interesting contribution on the mapping of IEC 61850 on Web Services from my friend Wolfgang Maerz (Dortmund/Germany). Wolfgang is one of the few senior utility experts involved in IEC TC 57 – even after he retired from RWE many years ago, he is still very active in IEC TC 57 standardization work. He has implemented protocols on his own … to study the details! He “hired” me as a consultant in the early nineties to support IEC 60870-6 (ICCP) and later IEC 61850.

Please find his very detailed contribution on the Web Service mapping (I post this information with his permission):

“Here are some fundamentals to IEC 61850 over MMS versus IEC 61850 over Web Services:

As I wrote in my last email Web Services is a strongly typed communication system using a WSDL (Web Service Definition Language) XML type and service specification for mainly two purposes: (1) check the correct syntax of XML-messages, (2) allow the creation of the SEI (Service Endpoint Interface) including the binding (or mapping) of XML to the application business object types of any language (Java, C#, ..).

Fundamental of Web Services is the strict separation of XML message values and their XML type schema which is part of the type declaration of the WSDL implemented at both sides of the communication system using document / literal style. This means that for Web Services the types of communicated values must be known “before” any communication takes place by its WSDL.

The problem is that some services of IC 61850 are of dynamic nature as shown by the example of the 61850 Report-Control-Block (RCB) class model. The report service of the RCB sends reports from the server to the client based on the dynamic structure of the Report Format Specification to allow spontaneous transmission of altered event-driven objects of any type. The receiving application to decode this dynamically created type must know this type!

This cannot be mapped to static WSDL specifications. Possible would be a WSDL with a sequence of choice types as in MMS but a possible implementation is not known and is even conceptual impossible. Of course you can use any-type in the WSDL and use Web Services as a simple type transparent messaging service but that only moves the problem with no communication interface as SEI directly to the application.

So, what is then the fundamental difference between IEC 61850 over MMS and IEC 61850 over Web Services when it comes to dynamically created types? The point is the encoding!

MMS is written in ASN.1 using the Basic Encoding Rules (BER). With BER, the encoding of every data value in an abstract syntax is constructed in TLV-style (Tag, Length, Value): The three parts here are actually termed identifier (I), length (L) and contents (C). The important thing to mention here is the identifier part which consists of one single octet with three parts: tag class (2 bit for universal, application-wide, context-specific, private-use), form (1 bit for primitive or constructed), and INCLUDES the tag number defining the type (5 bit, e.g. decimal 16 means type Integer)!

THAT MEANS:

With MMS / BER the type information is INCLUDED in the message and allows the client / server to even understand dynamical event-driven or service created messages of any type not even known before runtime!

This is in contrast with Web Services / WSDL where the type of XML-message values is defined separately BEFORE runtime in the WSDL’s XML type and service definition used to implement the (static) SEI (Service Endpoint Interface).

If all this is true this would mean that IEC 61850 over Web Services would be restricted to a specific domain or to certain use cases with reduced requirements where only a subset of IEC 61850 can be used. Most think Web Services is simple compared with MMS, I do not think so.”

Comments are welcome.