Some Hints on the use of Wireshark for IEC 61850-8-1 (MMS)

Please note the following preferences ... and have fun:

Version I used today:

Set the mms filter so see mms/IEC61850 only:

In case the MMS server is using a different port number: e.g., 12001 instead of standard port 102:

Analyze/Decode/ set other port number accordingly:

Check if presentation users context is correct:

Analyzing MMS/ASN.1/BER is sometimes tricky ... here is an example I figured out the other day ... if the length of a value is three (3) octets then the ASN.1 BER encoded message should indicate a length of 3 ... not 2 ... one single error in the length could damage the communication ...

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:

Second Sketch (Video) on Some Basics: The Mapping of IEC 61850 to MMS

IEC 61850 is well accepted globally in the power utility domain. One key issue has always been discussed and criticized: The mapping of the information models (Logical Devices, Logical Nodes, Data Objects ... ) and information exchange services to MMS (Manufacturing Message Specification defined in the standards ISO 9506-1 and ISO 9506-2, developed in the 1980s).

This video (58 minutes) explains the concepts of the mapping to MMS ... ASN.1, ASN.1 BER ... MMS for GOOSE and Sampled Values !?

Click HERE to access the video.

I will continue to produce more sketches (videos) and make them available through Screencast.

I look forward to your feedback.

Enjoy.

IEC TC 57 WG19 proposes CIM Profiles to JSON schema Mapping

IEC TC 57 WG is discussing the use of JSON for transferring message payload

DRAFT 62361-104:
POWER SYSTEMS MANAGEMENT AND ASSOCIATED INFORMATION
EXCHANGE – INTEROPERABILITY IN THE LONG TERM –

Part 104: CIM Profiles to JSON schema Mapping

The introduction says:

"This standard is one of the IEC 62361 series which define standards that may be used by all
Working Groups within TC57. These standards address areas of interest that impact multiple
standards and provide consistency for implementations.
This part 104 describes a mapping from CIM profiles to IETF JSON schemas and defines the
rules that CIM JSON message payloads must adhere to.
The principle objective of this part 104 is to facilitate the exchange of information in the form of
JSON documents whose semantics are defined by the IEC CIM and whose syntax is defined by
an IETF JSON schema. ..."

JSON is applicable for encoding of CIM (IEC 61968/70) message payload and - as I believe - also for IEC 61850 message payload!

By the way: The post on "IEC 61850-8-2 Versus IEC 61850-8-1" discussing the use of JSON in addition to MMS/ASN.1/BER and MMS/ASN.1/XER has been visited 2,000 times since July 5, 2019 --> or 16 times per day.

Click HERE for additional discussion on the use of JSON ...

IEC 61850 For Monitoring Data - Private or Standard?

One of the most crucial issues in the management of energy systems is: HOW TO share or exchange useful information generated by a myriad of sensors and applications needed by hundreds of applications?

Lets assume that lakes of information are generated every second. Usually this information is stored in silos of vendors specific solutions and communicated using one or more vendor specific communication solutions ... as shown in the following sketch drawn by our grandson Jan Oliver:



The expectations to apply IEC 61850 are high! BUT quite often vendors argue, that it is easier to use their private solutions - faster and saves time and costs! This may be true for the first phase of a project - but in the long run and in the view of the life time cost it may be completely opposite.

Three experts from Vattenfall DSO (Sweden; Vincent GLINIEWICZ, David EROL Anders JOHNSSON) have reported at the CIRED conference 2019-06 in Madrid (Spain) from an implementation of a pilot project using IEC 61850 and CIM  with the title:

LEVERAGING INDUSTRY STANDARDS TO BUILD AN ARCHITECTURE FOR ASSET MANAGEMENT AND PREDICTIVE MAINTENANCE

Excerpt from the paper:

"... However the data unfortunately currently often remain unused and unshared outside of the substation or specific silos for various reasons, some technical (e.g. cyber security, system incompatibility), some and organizational (e.g. vendor lock-in, siloed applications and organizations).
Additionally, with an increasing number of use cases requiring access to information, there is a growing number of information flows needed not only between data sources and central level applications but also between these central level applications. Without an IT architecture that allows reuse of information flows, there are legitimate concerns that the opportunities that digitalization promises might be delayed and costly or even worse, not be achievable.
As a result, Vattenfall Eldistribution sees a standard based integration approach as a cost-effective approach that seems to offer in the long run low integration costs and more importantly a greater flexibility, going from supplier specific integrations to a more generic approach. ...

We would also like to highlight some of the deviations from the standards that were observed during this pilot:

The pilot made use of a REST API towards the real time data historian (RTDH in fig. 2), although there was no mention of REST in the 61968-100 standard. One could however expect, given the increasing popularity and use of RESTful services in most industries, that the standard will soon follow and that the mention will be added in a further edition on the standard.
The gateway used in the pilot was a prototype base on a technical report (IEC TR 61850-90-2) [Using IEC 61850 for communication between substations and control centres] which is not yet a standard. This might explain why there doesn’t seem yet to be a complete and robust 61850-90-2 compliant product on offer in the market. Another alternative considered for the pilot gateway was the use of IEC 61850/MMS towards the substation and the use of web services (either RESTful+ JSON or SOAP) to communicate northbound instead of the IEC 61850/MMS used in the pilot. SOA has indeed a robust and well developed architecture for distributed computing, and this should be leveraged. There however did not seem to be any products available on the market. This alternative will be explored in a coming pilot. ..."

The paper concludes:

"Although the pilot was made for a primary substation, the widespread use of the IEC 61850 standards series make the results of this pilot not only applicable for primary substations, but potentially also secondary substations and microgrid.
Following the successful pilot, the next step is to look at how to fully implement and verify the concepts in a real substation and to secure production grade components where prototypes have been used as well as test the architecture through other smart grid use cases."

Click HERE for the full paper.

I have run an UCA/IEC 61850 pilot project with Anders Johnsson some 20 years (!) ago:

Two reports out of this pilot project and other discussions have been published in 2002:

Wind Power Communication
Verification report and recommendation

Click HERE for the Report.

Wind Power Communication - Design & Implementation 
of Test Environment for IEC61850/UCA2

Click HERE for the Report.

Enjoy the reports.

By the way: It took some 20 years to understand that the mapping of IEC 61850 models and communication protocols to MMS (ISO 9506) should be extended by a much easier and simpler mapping to JSON and, e.g., MQTT or http ...

It is not too late for such an additional standardized mapping ... e.g., as IEC 61850-8-3.

It may take another 10 years before this becomes true! Hope it will happen a bit earlier!

Further reading on the subject see discussion of IEC 61850-8-1 versus 8-2 (by 2024-02-25: 4074 visits of the post since July 2019).

Other people have similar ideas and published the following paper:

International Electronical Committee (IEC) 61850
Mapping with Constrained Application Protocol
(CoAP) in Smart Grids Based European
Telecommunications Standard Institute
Machine-to-Machine (M2M) Environment

IEC TC 57 just published FDIS IEC 61850-8-2 (Mapping to XMPP)

IEC TC 57 just published FDIS IEC 61850-8-2 (Mapping to XMPP) - 253 pages !

(57/2020/FDIS)

Voting ends: 2018-08-24

Part 8-2: Specific communication service mapping (SCSM)
– Mapping to Extensible Messaging Presence Protocol (XMPP)

The long wait for a second SCSM is over!

The new mapping of IEC 61850 describes a specific communication service mapping
(SCSM) over the Extensible Messaging and Presence Protocol (XMPP), providing detailed
information on how to create and exchange concrete communication messages that
implement abstract services and models specified in IEC 61850-7-4, IEC 61850-7-3, and
IEC 61850-7-2.

Note that the MMS messages (defined using ASN.1) are used in IEC 61850-8-1 AND -8-2 ! The only crucial difference between the two message and model mappings (in 8-1 and 8-2) is this:

8-1 uses BER (Basic Encoding Rule) for the messages on the wire, while 8-2 uses (XER (XML Encoding Rule). The complexity of the MMS messages is the same in both mappings - because the structure and how to build messages and how to carry the 7-2 services and 7-x models are the same!

The challenges to implement 8-2 message mapping are more or less the same as with 8-1. Note that the messages in XER are far longer than with BER.

There is - of course - a difference between the two: The transport of messages in 8-2 uses XMPP.

Some may argue, that there are more tools available for XER than for BER. Ok.

IEC 61850-8-2 is far away from something simple and easy to implement and use - especially when you need only a few simple services and models.

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.

Draft IEC 61850-8-2 SCSM – Mapping to XER and XMPP

Some 20 years after the first draft IEC 61850-8-2 SCSM (Mapping to Profibus FMS) we could expect the real IEC 61850-8-2 to be available by end of 2015.

The draft 8-2 provides an additional mapping of the messages of MMS by XER (XML Encoding Rule) and XMPP.

The MMS messages for IEC 61850-8-2 (above TCP/TLS/XMPP) are just differently encoded as in IEC 61850-8-1, as can be seen by the following example:

ASN.1 BER uses a binary encoding that produces less overhead compared to XER. But there will be many benefits provided by IEC 61850-8-2.

According to a presentation by Siemens during the Hanover Fair 2015, these are the main conclusions:

1. It provides a secure and powerful communication for public networks considering end-to-middle and end-to-end security relations
2. IEC 61850-8-2 is intended to use for power management and demand response of DER (distributed energy resources)
3. In 2015 the IEC TC57 working group WG17 will finalize and publish this new specification

Click HERE for the full presentation [pdf, 3 MB]

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.

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.

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.

The many Abstract and Concrete Layers in IEC 61850 (61400-25)

A new Comprehensive Overview of the many different layers in the definition of IEC 61850 has been provided by Karlheinz Schwarz. The various levels of models, the services, the mappings to MMS services and protocols, mapping of MMS messages to ASN.1, ASN.1. BER, ... are confusing - if you don't understand them. This presentation provides a lot of details and examples. 15 Slides bring light to the - often not understood - IEC 61850 layering:

1. Abbreviations
2. Hierarchy of definitions, protocols, …
3. Model (Standard)
4. Model (SCL)
5. Model (IED)
6. Services (ACSI)
7. Model and Service Mapping
8. Services and Protocols (MMS)
9. ASN.1 BER (Basic Encoding Rule)
10. Encoded MMS Message

Slide #1 of 15:

Click HERE to browse all 15 slides.

All these details are hidden in the implementation of IEC 61850 (IEC 61400-25) provided by SystemCorp (Perth, WA, Australia) and by the Smart Grid "Beck-Bone". The IEC 61850 API just needs 8 services:

IEC61850_Create	API to create a client or server object with call-backs for reading, writing and updating data objects
IEC61850_LoadSCLFile	API to read the SCL XML file to get the configuration of server or client
IEC61850_Start	API to start the server or client
IEC61850_Stop	API to stop the server or client
IEC61850_Free	API to delete a client or server object created
IEC61850_Read	Read the value of a specified data attribute
IEC61850_Write	Write the value to a specified data attribute
IEC61850_Update	Update the value of a specified data attribute

The three last API services are the crucial services an Application programmer has to deal with. The Beck Development Kit DK61 and the DLL demos provide application examples (in C/C++ source code).