Mapping of IEC 61850 Models and Information Exchange Services to JSON, HTTP, and MQTT

After I published two sketch videos on IEC 61850 information exchange services and the mapping to MMS, I discuss simple interface options for the last meters between a device that implements the role of IEC 61850 server, GOOSE publisher, and GOOSE subscriber, and the underlying huge world of a myriad of other controllers.

The standard series IEC 61850 and IEC 61400-25 (Wind Power Plants) provide a comprehensive set of standardized information or device models (Logical Nodes, Data Objects, Data Attributes, ...) for a wide range of use cases in the electric power domain (protection, automation, supervision, monitoring, control, ...) and for general applications beyond the electrical world. By the way, tell me where electricity is not a crucial resource in factories, buildings, petrochemical plants, homes, ... it is all over ... required 24/7. These series also comprise information exchange mechanisms like Reporting, Logging, Control, GOOSE, Sampled Values, ... mapped mainly to MMS in IEC 61850-8-1 ... other mappings like mappings to XML and XMPP in IEC 61850-8-2 or MMS, Web Services, IEC 60870-5-104, DNP3, OPC XML DA, ... in IEC 61400-25-4. The most crucial part of IEC 61850 and IEC 61400-25 is the System Configuration Language (SCL, IEC 61850-6).

Many applications use only a very small set of models (a few measurements, control signals, and status signals), a small set of information exchange services, and a simple subset of SCL. Critic comes from experts of various domains: Why do I need to have a complex and comprehensive IEC 61850 stack to implement a simple subset of these standard series? Is there another solution? The wind power plant people developing and maintaining IEC 61400-25 believing that five (5) mappings would help in this regard - really? So, the discussion is still going on. 

A very simple solution has been implemented in various projects: Notation of a subset of the information models and the payload of the messages in JSON. The exchange services could be mapped to various transport mechanisms like MQTT or HTTP ...

This approach would KEEP the models as they are - NO mapping required, just another notation (JSON instead of MMS named Variables etc.). Even SCL could be used.

Whenever there is a need to communicate from a device that plays the role of an IEC 61850 server, GOOSE publisher, GOOSE subscriber, to an underlying (likely simple) device (for the last meters) the decision usually is to use some other communication stacks from a set of 100+ solutions like CAN, Modbus, many fieldbusses, EEBUS, Sunspec, ... and private digital solutions, or even wires only ...

Any of these need to MAP from one standard to another standard, e.g., map MyIED/myMMXU1.Hz.mag.f (measurement of frequency) to register 2246 in one application and to 9817 in another ... hm, that is feasible BUT means a lot of configuration and documentation ... outside the definitions and tools provided by IEC 61850. 

A more reasonable approach would be to use JSON, e.g., to define a DataSet (semantically equivalent to IEC 61850 and MMS) and the report message payload as shown in the figure below:

Please check a couple of blog posts published a few years ago for more details and discussions:

https://blog.nettedautomation.com/2019/07/iec-61850-8-2-versus-iec-61850-8-1.html

https://blog.nettedautomation.com/search?q=mqtt

https://blog.nettedautomation.com/2019/10/iec-61850-for-monitoring-data-private.html

Unfortunately the Beck IPC com.tom Web PLCs with support of IEC 61850, ... disappeared ...

Please let me know your opinion ...

Beck IPC offers MQTT@CHIP in addition to IEC 61850 and other protocols

Beck IPC (Wetzlar, Germany, a subsidary of HMS) is known for their solutions on a single CHIP offering support for IEC 60870-5-104, IEC 61850, Modbus, CANBus, Profibus, Profinet, OPC UA, ... now offers MQTT@CHIP as an additional solution.



The MQTT can be configured on the WEB PLC like it is implemented for other protocols:



In the above example I have mapped a signal from an IEC 61850 Server the signal MMXU1.TotW.instMag.f to a MQTT message. This way you can tag the signal as a JSON Object!!

JSON Objekte:
{ „MMXU01.TotW.instMag.f“:  2325, „MMXU01.Hz.instMag.f“:  49.98 }

Message specification:



This way you can send MQTT messages with values from any other protocol or from the IEC 61850 client or server model. This way you can even map to/from GOOSE messages.

I have used the solution running on the IXXAT Smart Grid Gateway. The WEB PLC version 19.2 is required to run MQTT on the gateway.

Very well done!

Smart Cars Under Attack- What Does it Mean for Power Systems?

We are quite often looking for smart things: cars, phones, power grids, ... expecting they make life easier or more comfortable. May be ... or may not be.
We have to understand and take into account that most of these smart things are under enormous pressure to become hacked.
Researchers have reported that "Smart car makers are faced with a potentially lethal hack that cannot be fixed with a conventional software security update. The hack is believed to affect all smart cars and could enable an attacker to turn off safety features, such as airbags, ABS brakes and power-steering or any of a vehicle’s computerised components connected to its controller area network (Can) bus. ... The hack is “currently indefensible by modern car security technology, and to completely resolve it would require broad, sweeping changes in standards and the ways in-vehicle
networks and devices are made,”"
Click HERE for the full report on computerweekly.
Click HERE for another detailed report also worth to read and FOLLOW.

Hm, that is no good news!

I hope that the power industry is using appropriate (security) standards to dramatically reduce the risk to hack devices used in power automation systems. One of them is IEC 62351. There are many other measures discussed on this block, e.g., the German BDEW Whitebook.
How many more wake-up calls do we need to change our ways how to secure energy delivery services? The more devices are brought into operation the more we need to care about security.

A lethal position of the management would be: "It could not happen to our systems - they are all safe. Really?

In the first years of open systems interconnection (OSI) ... early 1980s, I was quite unhappy with the Ethernet CSMA/CD method and the token bus solution. As a young engineer at Siemens here in Karlsruhe, I spent many hours and days of my free time (at home) to figure out how to improve the CSMA/CD to make the access deterministic - yes I found a solution! My colleagues and the management was supporting Tokenbus only ;-)

So, my patent was not used by Siemens ... but later I figured out that the CAN bus used the same algorithm I developed for my patent.

At that time almost nobody was expecting that years later people would intentionally hack media access protocols!! I remember one person complaining about OSI in the early 80s. He said (in German): "Wer offene Systeme haben will, der ist nicht ganz dicht!" This is not easily to be translated in English - I will try. "Offene Systeme" is "Open Systems". "Dicht" means "close" - and if someone is "nicht dicht" means: you are crazy. So: "If you want to have Open Systems - you must be crazy."

Click HERE to have a look at my patent (EP0110015).

I am really wondering that the old and for long time used protocols like CAN make that lethal trouble 30 years later! What will be next?

By the way, any Ethernet multicast shower in a subnetwork has the potential to crash a "smart" device. If the Ethernet controller has to filter out too many multicast messages it may stop to work.

Resume: Any system needs to be carefully designed, engineered and configured. Do you want to have a problem? No Problem!

The industry has to learn that a lot of changes in the way we automate today has to come!! That requires SMART People - and a lot more resources ... the costs of our living will definitely increase.

I question, if we have really made a lot of progress since the early 80s. Open Sytsems are too "open" ... we have to find ways to close the points where hacker could tap and "re-use" the messages in order to stop talking.

IEC TC 57 to take action in Smart Grids

The IEC TC 57 has proposed a new work with the title "System interfaces and communication protocol profiles relevant for systems connected to the Smart Grid".

The ballot closes on May 09, 2011.

Click HERE for the proposal.

The proposal states: "In order to achieve interoperable interfacing between the components, the consistent, cost efficient and unambiguous integration of the new domains into the IEC TC57 methods of energy management, architecture, data models and protocols is crucial."

The most prominent IEC TC 57 Data Models and Protocols are those defined in IEC 61850! New Domains are, e.g., Industry, Home and Building Energy Control Systems. My guess is that the various components in these domains have to communicate directly (interoperable) with IEDs in power systems. The Client/Server communication in IEC 61850 seems to be the most useful communication model applicable in the communication between power system IEDs and IEDs in the new domains. The application profile according to IEC 61850-8-1 requires just native TCP/IP !!

Since IP networks are (to be) installed everywhere, it is easy to apply IEC 61850-8-1 without any change in most applications. Many existing IEDs like the COM.TOMs from Beck IPC and others could be used right away! They can be used as IEDs for monitoring and control in the new domains or they can be used as gateways between IEC 61850 and protocols in the new domains like Backnet, Profibus, Interbus, EtherCAT, CAN, Modbus, ...

This will accelerate the application of IEC 61850! ... in order to make systems more energy efficient and smarter by seamless:

• System configuration (IEC 61850-6),
• Information (IEC 61850-7-4xx, IEC 61400-25-2), and
• Information exchange (IEC 61850-7-2)
• Communication protocol (IEC 61850-8-1).

Let YOUR Application speak IEC 61850 in hours

IEC 61850 has been implemented in hundreds of devices. The UCA Users Group lists some 181 certified devices with server functionality, 3 certified clients, and 2 Merging units (as per 2011-03-02; UCAIug Testing Quality Assurance Program).

Almost all of these devices provide a certain functionality like protection or control. Usually the devices do not provide a simple API (application program interface) that can easily be used by an application program written by a programmer. There is usually nor access to "IEC 6150 Stack". Some test tools may provide restricted access by manually entering values for a data attribute, or using a configurable simulation or providing a CSV (comma separated values) file for a profile. The evaluation licenses are usually quite restricted.

In contrast to this quite limited access to an API there is a free available server and client DLL (from SystemCorp) that runs for six (6) months. The DLL evaluation package comes with various client and server applications. The applications are provided in exe code and source code (C/C++ and C#). You have FULL control over the functionality YOU want to have for your client and server application.

Click HERE for details.

Any application YOU write could easily speak IEC 61850:

The following example shows the .Net / C# client application provided by NettedAutomation GmbH. The received sequence of values can easily be copied and pasted:

 

e.g., pasted into an Excel table and converted to a diagram:

Whatever you need - JUST program it ... or link the client and server applications to your real applications ... which may also be masters to any communication slaves like DNP.3, IEC 60870-5-101/103/104, Modbus, Profibus, CAN, ... This way you can easily and fast build your own GATEWAY. Just link the DNP.3 or 104 points to the DLL by YOUR IEC 61850 server application that is bound to corresponding Model. See next figure:

It is that easy. Just give it a try.

By the way, the API (and the underlying IEC 61850 stack) is also available on the embedded controller from Beck IPC for simple and FAST TO MARKET applications. All you program in C/C++ on a PC could be done on the Chip platform ... the Chip also supports IEC 61131-3 (CoDeSys) and soon ISaGRAF.

NettedAutomation offers public and in-house training courses using a comprehensive set of crucial evaluation tools - including the one shown here.

IEC61850@CHIP - Flyer

A new flyer from Beck IPC, SystemCorp and NettedAutomation explains the architecture of the IEC61850@CHIP. The platform is very powerful, offering a lot of integrated functions, modules, and services like TCP/IP, SSL, IPSec, HTTP(S) server, IEC 61850, CAN Bus, IEC 61131-3, ...

Additional components like the following ones are available for EASY integration ... because the integration is already done by Beck IPC:

More to come
Click HERE for the flyer [pdf, 0.9 MB].