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.