What do you think about an IEC 61850 Open Source Implementation?

I have been asked off and on, if there is an Open Source Implementation for IEC 61850 or one with a reasonable price. Yes these are available these days. There is a simple subset of IEC 61850 implemented in Java licensed under the LGPL implemented by Fraunhofer Institute ISE (Freiburg, Germany). This solution is a result of the e-Energy eTelligence research project funded by Germany's Federal Ministry of Economics and Technology (2009-2012).

There is at least one other affordable solution available that provides a full subset of IEC 61850 even applicable at small embedded controllers – from SystemCorp.

The Open Source IEC 61850 Server supports:

• MMS Associations
• (MMS) GetDirectory and (MMS) GetDataDefinition services
• (MMS) GetDataValues and (MMS) SetDataValues
• (MMS) DATA-SET model services
• Interpretation of ICD-File to build model

IEC 61850 Client supports in addition to Servers:

• Receiving (MMS) Reports

Visit the home page of the openIEC61850 Implementation.

We have tested the open source solution to some extend to see what it provides. The solution is mainly a MMS (ISO 9506) implementation. IEC 61850 contributes to the solution with its information models (logical devices, logical nodes, data objects, data attributes, …). The hierarchical information maps perfectly to MMS NamedVariables (NV)!! The corresponding MMS Services allow to manage retrieving the MMS object model (NVs), writing to the NVs and reading from NVs. Since MMS fits well to the information model of IEC 61850, it is natural that the MMS NV and NV services provide the needed services for IEC 61850 information model management.

IEC 61850-7-2 (ACSI) provides more elaborated services (not supported by the open source solution), e.g., Reporting, Logging, GOOSE, Sampled Value exchange, Control Model, and File transfer. The most comprehensive (complex) model is the buffered Report Control model. This model allows the optimized usage of bandwidth by providing a spontaneous (event) driven mechanism. A specific status information will be transmitted only when its value changes or when – for an analogue value – a configured limit is violated. This reduces the traffic tremendously and meeting a critical timeliness need.

Polling a huge number of devices in a huge distributed system does not scale at all. There is a crucial difference in applying polling or event driven reporting.

Sure, for accessing some values in a remote device once an hour or once a day or so, could be realized with polling.

If your need is focusing on fast (medium and hard real-time) information exchange, then you need high efficient reporting, GOOSE and Sampled Value exchange.

The OpenIEC61850 implementation uses the external access path (the complete path from LD/LN.DO,DA. …) also for the internal access of the real information in the application. The application uses the path at the boundary between communication and application. The application has to analyze the text strings (up to 2 x 64 characters) for each element to be written or read. An API that maps between the external name path and a kind of an internal pointer (maybe just a linear index) is therefore more efficient. One of the crucial objectives of IEC 61850 is to use a standardized model independent of the internal organization of the real data values.

It would be interesting to see a first device that implements the OpenIEC61850 solution to get an IEC 61850 Conformance Certificate. The current solution does not yet support the Control Model, which is required as a mandatory service. MMS does not have a model that is equivalent to the IEC 61850 Control Model. That’s why the IEC 61850 solution has to implement all the needed features of the Control Model according to IEC 61850-7-2 and IEC 61850-8-1. Having MMS does not mean that it is easy to implement the Control Model – I have seen many experts struggling with the Control Model.

The main reason why there was a decision made to implement an openIEC61850 using Java was (from my experience and understanding) simply because there was not a single software solution available that was affordable for R&D projects. Usually the solutions came in source code … meaning to spent a lot of efforts (money and time) to get what people (researchers, students, Phd students, …) were looking for.

This has changed a lot during the recent years. These days you could build on ready-to-go solutions that allow implementing affordable devices interoperable with other devices.

There is a FREE IEC 61850 evaluation software (Client and Server) available that could be used for building compliant clients and server: A DLL plus application software (executable and source code for the application).

http://blog.iec61850.com/2012/08/c-server-and-client-application-source.html

The DLL runs for six months … but could be purchased as well.

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

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.

MMS and ASN.1 Tutorial

The basics of MMS (Manufacturing Message Specification, ISO 9506) and ASN.1 (Abstract Syntax Notation 1) are available at the NettedAutomation Website.

MMS is a messaging system for modeling real devices and functions and for exchanging information about the real device, and exchanging process data - under real-time conditions - and supervisory control information between networked devices and/or computer applications. MMS is an international standard (ISO 9506) that has been developed and maintained by the ISO Technical Committee 184 (TC184) - Industrial Automation - of the International Organization for Standardization (ISO).

The object models and messaging services provided by MMS are generic enough to be appropriate for a wide variety of devices, applications, and industries. Whether the device is a Programmable Logic Controller (PLC) or a robot, the MMS object models, services and messages are identical. Similarly, applications as diverse as material handling, fault annunciation, energy management, electrical power distribution control, inventory control, and deep space antenna positioning in industries as varied as automotive, aerospace, petro-chemical, electric utility, office machinery and space exploration have put MMS to useful work.

MMS is the base standard to communicate all client/server information exchange for IEC 61850, IEC 61400-25 (in addition to other protocols) and IEC 60870-6 TASE.2 (ICCP). ASN.1 is used in MMS to specify the syntax of messages, ASN.1 BER defines the concrete encoding of the messages. Please note that only a small subset of MMS and ASN.1 is needed by IEC 61850, IEC 61400-25 and TASE.2.

Click HERE to begin the Tutorial ... enjoy.

International Standardized Profiles needed for IEC 61850-8-1 (MMS)

The mapping standard IEC 61850-8-1 (Mapping to MMS) requires in §6.2.2 to implement the MMS-specific Implementation agreements
requiring “This A-Profile shall conform to the agreements specified in ISO/ISP 14226-1, ISO/ISP 14226-2, ISO/ISP 14226-3, ISO/IEC ISP 11188-1 and ISO/IEC ISP 11188-3.”

The tree first ISPs can be downloaded from the NEMA website for free:

ISO/ISP 14226-1:1996, Industrial automation systems – International Standardized Profile AMM11: MMS General Applications Base Profile – Part 1: Specification of ACSE, Presentation and Session protocols for use by MMS

ISO/ISP 14226-2:1996, Industrial automation systems – International Standardized Profile AMM11: MMS General Applications Base Profile – Part 2: Common MMS requirements

ISO/ISP 14226-3:1996, Industrial automation systems – International Standardized Profile AMM11: MMS General Applications Base Profile – Part 3: Specific MMS requirements

IEC 61850 (MMS) running over LTE

Giang T. Pham did some research on running IEC 61850 (MMS) over LTE. The result is a Master Thesis at the University of Twente:

“Integration of IEC 61850 MMS and LTE to support smart metering communications”

“… The objective of this research is to integrate IEC 61850 MMS and LTE to support communications between smart meters and the central meter data management system. The research includes a literature study of IEC 61850 MMS protocol, focusing on its requirements to support smart metering communication, and simulation-based performance evaluation of IEC 61850 MMS smart metering traffic over LTE network. …

… Since both MMS and LTE support the use of TCP/IP communication profile, the mapping of MMS over LTE to support remote control communication is feasible … the simulation results prove that the integration of IEC 61850 MMS and LTE is not only possible but also provides good performance in term of delay, throughput and packet loss.

Click HERE to download the Master Thesis [pdf].

Do You Know ISO/IEC 9506-6 - The MMS Process Control Companion Standard?

Long time ago (may be when you still went to Kindergarten) there was an international standardization project defining a set of standards that offered comprehensive sets of services and models for Industrial Automation Systems:

ISO/IEC 9506 Manufacturing Message Specification (MMS)
- Part 1 (Services) and Part 2 (Protocol)

MMS was developed in the 80s and published in 1990. The standardization in ISO TC 184/SC5/WG2 took place in the context of the GM led MAP project.

Part 1 and Part 2 comprise the basic definitions for any application domain.
Click HERE for useful hints and explanations what MMS is and how it is used for IEC 61850.

The Companion Standards have been developed for specific applications:

Part 3 Companion Standard for robotics ISO/IEC 9506-3
Part 4 Companion Standard for numerical control ISO/IEC 9506-4
Part 5 Companion Standard for Programmable controllers ISO/IEC 9506-5
Part 6 Companion Standard for Process control ISO/IEC 9506-6

Part 6 seems to be a simple forerunner model of IEC 61850 for communication services models and applications models.

Cover page:



Excerpt of the application model related to a process variable (Data Model in IEC 61850):



Excerpt of the reporting model related to the report control block model in IEC 61850:



Unfortunately all MMS parts have (more or less) been ignored by the industrial automation domain. As one of the experts deeply involved since 1985 I know a bit what happened ... the most crucial reason was: many experts that did not (WANT to) understand the benefits of MMS have led to the situation today: No comprehensive unique standard for information models, services, protocols, ... has been offered for the industrial automation ... even in Industry 4.0 there is not yet one in preparation - as I see it. Even OPC UA is still looking for domain specific models ... may "copy" IEC 61850 models!?

Sure: IEC 61850 is much more than MMS !!! But MMS could be understood as a kind of forerunner for IEC 60870-6 (TASE.2/ICCP), IEC 61850 and IEC 61400-25 (Wind).

Java SDK for MMS and IEC 61850 available

Monfox (Cumming, GA, USA) implemented the DynamicOSI™ Java MMS SDK as a Standalone platform-independent software development kit and API which implements the core message defined in ISO 9506 Manufacturing Message Specification (MMS) required for implementation of most client and server MMS and IEC 61850 / 61400-25 applications.

The SDK is a simple Java MMS service-based API and OSI protocol stack for performing MMS operations over OSI/RFC1006 (TCP/IP). It provides a 100% Java, fully-interoperable, standard-compliant implementation for:

• Core MMS services from ISO 9506-1
• OSI Association Control Service Element (ACSE)
• OSI Presentation Layer
• OSI Session Layer
• OSI Transport Layer
• RFC1006 (OSI over TCP/IP)
• IEC 61850 Client/Server Support

More information on MMS in Java for IEC 61850 can be found here.

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:

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!

Open Source C-Code for IEC 61850

Some six weeks ago I reported about the open source Java code for IEC 61850. The group that developed the Java code has now also published the open source C code.

“In cases where Java is not an option (e.g. if you want to implement a server on very resource constrained systems) you can also consider libiec61850 which is an alternative implementation in C.”

libIEC61850 provides a simple API for MMS. This API is in no way specific to IEC 61850 but provides a generic MMS client API.

This MMS API seems to be an option in case you have to decide to use (on one side) Modbus, DNP3, Fieldbus, or CAN in Automation OR (on the other side) to use IEC 61850. It may help you to get started with IEC 61850. There is no reason anymore not to start with IEC 61850!! The cost argument has gone.

As a Siemens employee I wrote two remarkable papers on the standardization:
one about the future of Fieldbusses/MMS and one about MAP/MMS in 1991:

Click HERE for the paper “Fieldbus standardization: Another way to go”
[PDF, 720 KB].

Click HERE for the paper “Bridging MAP/MMS to Ethernet” [PDF, 720 KB]

It took some 30 years from the fist baby steps to the availability of open source MMS code and other IEC 61850 solutions like the one from SystemCorp that is quite powerful and comprehensive. The time where you have to pay high (“voltage”) prices is over! “High voltage” refers to the application domain high voltage substations – the domain that first used IEC 61850 some 10 or 15 years ago.

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.

Data And Communication Security for MMS is Speeding Up

IEC TC 57 is about to accelerate the publication of a new Standard on Security:
IEC 62351-4 ED1 (57/1860/CDV):
Power systems management and associated information exchange -
Data and communications security -
Part 4: Profiles including MMS
Closing date for voting: 2017-08-11

The current part 4 is just a TS (technical Specification). The need for a definitive solution for secure MMS communication is at hand.

"Scope
This second edition of this part of IEC 62351 substantially extents the scope of the first edition [KHS: TS only!]. While the first edition primarily provided some limited support for authentication during handshake for the Manufacturing Message Specification (MMS) based applications, this second edition provides support for extended integrity and authentication both for the handshake phase, and for the data transfer phase. In addition, it provides for shared key management and data transfer encryption and it provides security end-to-end (E2E) with zero or more intermediate entities. While the first edition only provides support for systems based on the MMS, i.e., systems using Open Systems Interworking (OSI) protocols, this second edition also provides support for application protocols using other protocol stacks, e.g., a TCP/IP protocol stack. This support is extended to protect application protocols using XML encoding [KHS: IEC 61850-8-2] and other protocols that have a handshake that can support the Diffie-Hellman key exchange. This extended security is referred to as E2E-security.
It is intended that this part of IEC 62351 be referenced as normative part of IEC TC 57 standards that have a need for using application protocols, e.g., MMS, in a secure manner.
It is anticipated that there are implementation, in particular Inter-Control Centre Communications Protocol (ICCP) implementations that are dependent on the first edition of this part of IEC 52315. The first edition specification of the A-security-profile is therefore included as separate sections. Implementations supporting this A-security-profile will interwork with implementation supporting the first edition of this part of IEC 62351.
Special diagnostic information is provided for exception conditions for E2E-security.
This part of IEC 62351 represents a set of mandatory and optional security specifications to
be implemented for protected application protocols."

By the way: The best security standard is useless if it is not implemented (and even worse when it is available but not used) in as many devices as possible! Talk to your management to get the resources (hardware, software, peopleware) to implement this new part - as soon as possible.

MOXA’s Dual Protocol Approach: MMS and SNMP

MOXA has announced to support a dual protocol approach in their communication infrastructure: IEC 61850/MMS and SNMP.

This is no surprise: already in the first year of standardization of IEC61850 EdF (France) proposed to use SNMP (simple network management protocol) to carry IEC 61850 payload modeled in a specialized MIB. There was very little support for SNMP.

It is natural that the communication infrastructure also provides IEC 61850/MMS access to the many data objects used in switches, routers and other equipment. IEC 61850-7-4 Edition 2 has a lot of new – communication related – logical nodes that are linked directly to network management like “Physical communication channel supervision” logical node (LCCH):

RxCnt - Number of received messages
RedRxCnt - Number of received messages on redundant channel
TxCnt - Number of sent messages

This is related to the communication infrastructure … Or?

Click HERE for details from MOXA.

MOXA concludes in a White paper:

“Moxa’s new line of PowerTrans IEC 61850 switches now come with full MMS compatibility, with a complete implementation of IEC 61850 data modeling and a built-in MMS server. Our entire line of substation computers, switches, and other associated hardware all still feature our own enhanced SNMP support (with custom MIB files), but Moxa welcomes any inquiry into further customizing our switches, embedded computers, and other substation IT hardware with full or enhanced MMS support, made to your order.”

When to use Operate Service and when SetDataValues?

The IEC 61850-7-2 abstract services Operate and SetDataValues are both mapped to MMS Write in IEC 61850-8-1. So, what makes a MMS Write service an Operate or a SetDataValues?

The two services and the mapping are sketched here:

The first mapping is showing the Operate service (as part of the control model):

The Operate service is used in conjunction with the control model (defining state machines, select-before-operate, time-activated control,…). Control service models require a special information model: controllable Common Data Classes, e.g., SPC – Controllable Single Point. The model comprises attributes defined by the CDC and the service parameter ctlVal: these are shown in the MMS Variable as a structure “Oper” with the components: ctlVal, origin, ctlNum, T, Test, Check. These have to written at MMS level. These are always required for Operate even if you need just ctlVal !!

The settable DataObjects require the MMS Write as shown in the following figure:

In IEC 61850-7-3 it is defined exactly which services are to be used for the various attributes in the Common Data Classes. Example for controllable DataObjects:

 
Note that the FC=CO is defined in 8-1 !

Note also that client user interfaces (like the IEDScout) may use different service names than 7-2 or MMS.

MMS, IEC 61850-8-1, and IEC 62351 (Security)

Just a brief information on security in the MMS mapping of IEC 61400-25-4 and IEC 61850-8-1.

ISO 8650-1 (ACSE) defines the details of Authentication referred to in IEC 62351-4:

Excerpt of 62351-4:

See example of ACSE AARQ  in Wireshark (connecting to an IEC 61850 IED, password “glue” – in plain text):

So, it would be sufficient to refer to IEC 62351-4 in IEC 61400-25-4 Edition 2 and in IEC 61850-8-1.

The following experience may be yours as well:

1. Think of an IEC 61400-25-4 / IEC 61850-8-1 MMS Server in an IED.
2. MMS allows to set a username and password.
3. The client is for example the Omicron IED Scout.
4. You can use a password to protect the access to that server (to some extent).
5. Many clients do not support to use a password to be sent to the server. So access from a couple of SCADA clients is not easy to manage … or even not possible at all.

It is highly recommended that the user community feeds back their experience with MMS passwords to the standardization groups like IEC TC 57 WG 10, 15, 17, 18, 19, ...

If you have a special experience or requirement on MMS password exchange, please let me know.

Thanks for your feedback.

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.

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.

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.

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.