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.

Mapping of IEC 61850-7-x to XMPP: Nice Paper in PACWorld Magazine

The XMPP technology (Extensible Messaging and Presence Protocol) has been selected as the communication solution to address the Smart Grid specific challenges and use cases, which deviate from a typical substation automation use case.

The additional mapping will be published as IEC 61850-8-2.

A nice overview can be found in a paper published recently in the PACWorld magazine:

Click HERE for the full paper.

Note that from a message encoding point of view the MMS-ASN.1-BER messages are mapped directly to ASN.1-XER coded messages. The ASN.1 Tag numbers are mapped to XML Element names. The whole message schema is the same in both mappings.

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.

Bandwidth Usage – IEC 61850 Object References versus Indexes in Messages

Beck IPC and NettedAutomation conducted two workshops on the latest development of IEC 61850 and IEC 60870-5-104 monitoring and automation IEDs and gateways. Experts from 12 companies (users and vendors) attended the workshops. The attendees appreciated the inside view into the standards and how easy it is to implement standard conformant IEDs.

One attendee responded the day after:

“Dear Mr Schwarz, I had a safe return fortunately. Thanks again for your documents and your very interesting presentations yesterday. It is very likely that I contact you in the near future for some questions/help.”

During the first workshop there was a very crucial question on the long names that are used as references to signals (data attributes) like: “MyLogicalDevice/QE1XSWI5.Pos”: How do these long names impact bandwidth needs and consumption? It seems to be quite in-efficient to use IEC 61850 for low bandwidth communication channels! Or?

Here is the solution for Reporting (Meldungen) in IEC 61850: The Report Message uses DataSets to describe the semantic content of the message and the syntactical position of each member of the DataSet. The example below shows five members. The order of the members in the DataSet is important!

A single change in a one of the signals represented by a hierarchical reference, e.g., “MyLogicalDevice/QE1XSWI5.Pos” causes a spontaneous report message with the value of exactly this member (Boolean=True in our example). The POSITION of the member within the DataSet is marked in an inclusion bitstring (or Index) in the message. For the five members we need one octet for the bitstring. The message also carries the name of the DataSet “SwitchPositions”.

The Client can interpret the semantic of the single Boolean (=True) by just looking into the DataSet configuration. The member number 5 means: “MyLogicalDevice/QE1XSWI5.Pos” (of the server). The client needs to understand the syntax (position of the member in the DataSet) and the semantic of the received value(s). The client uses the Configured IED Description (.cid) to understand the shipped package (report).

Any question. Please keep in touch.

For GOOSE and Sampled Value messages it is even more efficient: by just sending the values of all members of a DataSet (in the order of the DataSet) there is no need to provide any identifier (name or index) in the messages. The semantic is determined by the order of the corresponding DataSet. So, subscribers need to receive in the GOOSE or SV the reference of the DataSet used. The efficiency much better than what many people expect – people that know the efficient encoding of IEC 60870-5-104 or DNP3.

That’s it. You want to learn more about IEC 61850 and related standards – and how to implement them, please check the program for the next hands-on training on 07-09 May 2014 in Frankfurt/Germany.

IEC 61850-8-1 Signal Quality Encoding

Yesterday I received an email with a question on the encoding of the signal quality in MMS messages. Please find below the question and how the encoding is done in MMS made visible with the Wireshark:

 

Hope that give some deep inside knowledge for those that analyze the MMS message exchange needed for IEC 61850-8-1.

Need Help regarding MMS (ISO 9506)?

Experts that are looking for further helpful information on MMS (Manufacturing Message Specification – ISO 9506) can download a report published as part of MSc Thesis "Security in Industrial Networks" in Norway, 2007:

Click HERE for the links to two papers.

Unfortunately the authors did not mention IEC 61850 and IEC 61400-25 as the most crucial standard series that use MMS.

The security measures for MMS are defined in IEC 62351-4.

Click HERE for additional information on security and IEC 61850/MMS.

Click HERE for find more information on MMS.

Wireshark Analyzer and IEC 61850 Messages (MMS, GOOSE, SAV)

When you use Wireshark (I run Version 1.6.0) you may have had a problem to see GOOSE and MMS messages. There is a simple solution how to visualize the MMS and GOOSE messages:

You have to start the Wireshark first, start analyzing and THEN connect from a IEC 61850 client to a server to open a MMS association. Now you see the messages … strange but it works … as you can see:

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.