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

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.

MMS (ISO 9506) Introduction – Why to focus on the API?

Jan Tore Sørensen and Martin Gilje Jaatun (SINTEF ICT, Trondheim, Norway) have published a nice introduction to the basic architecture and definitions of MMS in a 46 page document – easy to read and understand.

This documents demonstrates that MMS is not complex. IEC 61850-8-1 (and IEC 61850-9-2) use MMS for specifying the message exchange between IEC 61850 servers (publishers) and clients (subscribers).

Implementing IEC 61850 compliant systems comprising SCL tools, servers, clients, publishers, and subscribers means to implement:

1. Upper layers on top of TCP/IP (or on Ethertype for publisher/subscriber)
2. Protocol machine (MMS, GOOSE and SV)
3. Encoding/Decoding ASN.1 BER messages
4. ACSI services (LD, LN, Control Blocks (reporting, Logging, service tracking, GOOSE, and SV), DataSets, Control, LOG –> mapped to protocols, mainly MMS)
5. Object model (dictionary in IED and behavior according to IEC 61850-7-4)
6. API (application program interface) for server, client, publisher, and subscriber
7. IED configuration using SCL file
8. SCL tool for system engineering and IED configuration

A ballpark estimate of the efforts needed to implement a reasonable subset of IEC 61850 (if one develops the software from scratch) is in the range of some 10 man-years. Only a small part of efforts (likely less than 10 per cent) deals with MMS and the underlying protocols required by MMS.

A different solution for the client-server messaging, e.g., by using a webservice, would have a minor impact on the total efforts. From a application point of view an efficient API should be in the focus when implementing of using IEC 61850!

Click HERE for the complete paper on MMS [pdf, 446 KB]

Note that IEC 61850 is much more than a protocol – and much more than MMS. MMS is just an international standard like Ethernet or TCP/IP.

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.

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.

What is a Stack?

The term Stack has many meanings, flavors,  … ask 10 experts and you may get 11 definitions. People talk about an IEC 61850 stack, an OPC UA stack, .... What do these mean? Are they comparable?

Let’s start with the general definition:

According to the Wikipedia: “The protocol stack is an implementation of a computer networking protocol suite. The terms are often used interchangeably. Strictly speaking, the suite is the definition of the protocols, and the stack is the software implementation of them.”

So, the software that processes the protocols is called the (protocol) stack.

With regards to IEC 61850 this can mean many things: Session, Presentation, ACSE, MMS, ACSI, MMS-SCSM, Model management and configuration language, API to the application, … let’s have a look at the server side of the communication:

	“Protocol” aspects	Remarks and Explanations
1	API to application	Control of Server SW, local services for read, write, events, control, … “Protocol” that defines how the application can communicate with the underlying IEC 61850 software.
2	Models, model management and model and ACSI configuration language	Describe the server’s information model and binding to application (LDs, LNs, DO, DA, …) Be aware that LNs have also services and protocols (see below for LN GLOG). The information models has to be organized in the IED’s software (including retrieving the self-description of the model)
3	ACSI (Abstract Communication Service Interface)	The (protocol) software has to implement the services Association control, retrieve self-description (Server, Client, Publisher, Subscriber, LD, LN, DO, DA, ControlBlocks, …), Get, Set, DataSet services, Reporting (events), Logging (events; historian), GOOSE, Sampled Values, Control, File services, time synchronization, … The implementation of the protocols that define the dynamical behavior of the services are one of the crucial parts of IEC 61850.
4	MMS SCSM	The ACSI services use MMS to carry the payload between client and server. MMS provides the serialization of (service) messages. Example: A Buffered Report Control Block is a quite comprehensive “Service” model with a set of service parameters (for control block attributes). The state machine of the Control Block requires a bit of a software!
5	MMS	Simple classes like NamedVariables, NamedDataSets, Journal, … Message schema (encoding using ASN.1)
6	ACSE	Kind of a remote procedure call
7	Presentation	Concrete encoding: ASN.1 BER
8	Session	Session between client and server
9	RFC 1006	Binding OSI upper layers to TCP
10	Security	Security according to IEC 62351 … TLS
11	TCP/IP	you know …!!
12	Lower layers	…

Note: GOOSE and Sampled Value messages are mapped directly to Ethernet!

What is the Logical Node GLOG? An application or a model with services and protocol (messages)? The GLOG is a standardized application that defines a model, services and a protocol! Guess you did not expect this … others may not agree with me …

IEC 61850-7-4 Edition 2 defines:

“5.7.4 LN: Generic log Name: GLOG
The LN GLOG refers to a function which allows to log not only changed data itself but also any related data being defined in the settings of LN GLOG. The logging is started by the changed data object (TrgRef1) or by the operator (LogTrg). The logged data are identified by the references to the related source data objects in the data model.” This in short the state machine of the GLOG service model and protocol (in abstract terms). The GLOG communicates with a client via services and a protocol …

The logged Data Values will be stored in an IEC 61850 Log … it can be queried by services from a client.

Let’s come back to our question, what is implemented in a stack?

Stacks from different vendors may be for free, may be reasonable priced, or may be expensive! What does this mean? Almost nothing! Because the CRUCIAL question is: WHAT would you get for your Euros or Dollars?

A stack of vendor X may cover the implementation described under bullets 1, 2, 3, 4, 5, 6, 7, 8, 9, and 10.

A stack of vendor Y may cover only 5, 6, 7, 8, 9, and 10.

The difference is tremendous: The efforts to implement the requirements listed in bullets 1, 2, 3, and 4 are (to my experience) likely more than 90 … 95 per cent of what needs to be implemented with regard to IEC 61850!

If you hear something like “the stack so-and-so is cheaper …” listen twice and then think about what you have heart three times and ask what that stack really provides four times AND ASK PEOPLE WITH EXPERIENCES WHAT IS LEFT FOR YOU TO DO to get a compliant IED !!! I have talked to many experts that were surprised that it took sooo long … and cost sooooo … much to get a compliant IED.

When it comes to the comparison of OPC UA and IEC 61850: Listen very carefully, and ask questions … and then … and then you may understand the difference from a standard and from an implementation point of view.

Click HERE if you want to experience what could be provided by a specific stack providing integrated software for issues 1 to 10 … with little left for you [German].
A workshop in English may be set up when you are interested … let Beck IPC know that you would attend a workshop in English.

What is the ACSI?

The ACSI is the "Abstract Communication Service Interface" defined in IEC 61850-7-2.

The ACSI was invented during a meeting of some experts that met here in Europe at the beginning of the project IEC 61850 (between 1995 and 1997). The reason was quite simple: We had TWO proposals for protocol profiles: (1) MMS TCP/IP and Ethernet (2) Profibus FMS. Each solution was supported by some 50 per cent of the members.

What to do now? I was deeply involved in the fieldbus standardization. We had so many fights since the late 80s ... which damaged the reputation of the standardization in the early 90s. I suggested NOT to fight in IEC 61850 but to define an abstract service model that could be mapped to MMS and to FMS. The first was specified in IEC 61850-8-1 and the second in IEC 61850-8-2. Even no official IEC draft has ever been published for IEC 61850-8-2.

Later we had a similar discussion in the project IEC 61400-25-4 in IEC TC 88 (Wind Turbines). We agreed to follow the approach of the abstract model of IEC 61850-7-2, to use the 8-1 MMS mapping, to add mappings for OPC XML DA, IEC 60870-5-101/104 and DNP3, and to define a concrete webservice for each abstract service of the ACSI.

The services of the ACSI and some explanation could be found here:

Click HERE for C/S and P/S
Click HERE for Data Acquisition
Click HERE for Webservices
Click HERE for MMS

By the way, the services in IEC 61850 are very general ... applicable almost everywhere!

My observation is, that (with some exceptions) ALL applications of IEC 61850 apply the MMS mapping ... that does not mean that everybody likes MMS ;-)

Most people using IEC 61850 do not care about MMS - and ALL should not care!