Sample of an IEC 61850-8-3 request-response message sequence using JSON

The standard IEC 61850-8-3 under preparation will use ASN.1 JER (JSON) encoding. In order to understand, what that means check the following message sequence of the service (copied from the Wireshark trace, without WebSocket, TCP/IP, ... headers).

Note that you can use the Open Source Software of the PoC (Proof of Concept) to let client and server exchange real messages ... enjoy!

getLogicalDeviceDirectory

    { "request": {

            "associateId": "cp1",
            "invokeId": 1,
            "service": {
                "getLogicalDeviceDirectory": {
                    "ldName": "LD0"
                }}}}

    { "response": {
            "associateId": "cp1",
            "invokeId": 1,
            "service": {
                "getLogicalDeviceDirectory": {
                    "lnName": [
                        "LLN0",
                        "LPHD1",
                        "DWMX1",
                        "DGEN1",
                        "MMXU1"
                    ]}}}}

setDataValues

   {"request": {

            "associateId": "cp1",
            "invokeId": 56,
            "service": {
                "setDataValues": {
                    "ref": {
                        "ref": "LD0/LLN0.Mod.ctlModel",
                        "fc": "cf"
                    },
                    "dataAttrVal": [
                        {
                            "data": {
                                "enumerated": "2"
                           }} ]}} }

    {"response": {
            "associateId": "cp1",
            "invokeId": 56,
            "service": {
                "setDataValues": null
            }}}

    

Any question? Guess there is likely no need to ask, what this is ...

Search for "8-3".

Looking for an Open Source Multi Protocol Gateway for IEC 104, TASE.2/ICCP, IEC 61850, OPC-UA ...?

The standards IEC 60870-5-104, IEC 60870-6 (TASE.2, ICCP), IEC 61850, OPC-UA and other (often legacy solutions) are crucial for the power delivery systems all over!

Therefore the ability to translate from one protocol to another is a key feature for every TSO (Transmission System Operator). As the needs are growing and the number of use cases are flourishing (e.g. RTE needs thousands of instances of MPG (Multi Protocol Gateways), they are incented to look for a highly cost effective solution. On this observation, Swissgrid and RTE decided to take over that challenge by initiating a Proof of Concept on an open source basis - according to a news published at LinkedIn the other day.

Title: "First step toward an Open Source multiprotocol Gateway initiated by Swissgrid and RTE"

Click HERE for more information posted at LinkedIn.

Sebastien HENRY (Directeur SI & Télécommunications chez RTE Réseau de Transport d'Electricité) said: "RTE is committed to invest in open source for the development of an ecosystem of IT solutions for the energy sector. I am very confident in the fact that with the multiprotocol gateway, a small piece of software widely needed in our infrastructures, will demonstrate this strategy worth being followed."

Update on OPC UA IEC 61850 Companion Specification

The OPC UA IEC 61850 Companion Specification of the OPC Foundation is focusing on gateways that are intended to be used to transfer information fully and accurately through gateways between devices that implement IEC 61850 or OPC UA respectively.

While IEC 61850 is focusing on electricity generation, transmission, distribution, distributed energy resources (DER), and consumption, OPC UA is dealing with non-electrical industrial process activities. It is clear that users require integration of the electrical aspects of a plant with non-electrical aspects.

The information models defined in IEC 61850 were focused during the late 90s on protection and automation of electric power systems. In the meantime the models provide a huge number logical nodes (e.g., STMP = Supervision of temperature with measurement, alarms and trips, or FPID = PID loop control) applicable in most non-electrical applications domains. The communication services (Reporting, Logging, GOOSE, Control, Setting Group Control, ...) are generic for any application domain.

OPC UA’s modelling capabilities is understood to make it possible to transfer data between different systems without losing the semantics of data. Thus the drafted companion specification document describes how IEC 61850 data can exchanged using OPC UA data modelling and services.

Click HERE for more information.

IEC TC 88 PT 25 is currently working on a technical specification: 

Wind turbines - IEC 61400-25-41: Communications for monitoring and control of wind power plants - Mapping to communication profile based on IEC 62541 (OPC UA)

Microsoft has provided an Open-Source OPC UA stack to OPC Foundation! 

The new OPC Foundation .NET reference stack, based on the new .NET Standard Library technology, was developed and optimized by Microsoft to serve as the complete platform-independent infrastructure, from the embedded world to the cloud. This new version is enabled on the following supported platforms: Various Linux distributions, iOS, Android, Windows 7, Windows 8, Windows 8.1, Windows 10, Windows Phone, HoloLens and the Azure cloud.

Click HERE for the press news from the OPC Foundation.

Click HERE for accessing the open source reference stack at Gidhub.

Brief comparison of IEC 61850 and OPC UA:
Standard? Yes for both in IEC.
Available since? IEC 61850 for some 15 years; OPC UA for a few years.
SCADA support? Yes for both.
Real-time support? Yes in IEC 61850; OPC UA is intended to run on TSN (IEEE 802).
Security? Yes for both (IEC 61850 refers to IEC 62351).
Semantic? IEC 61850 has huge, still growing list of models; OPC UA has not yet semantics.
Configuration Language? IEC 61850 has SCL (System Configuration Language); OPC UA has no.
Conformance testing? Yes for both.
Support: By many big and small companies.
Open Source Stack? Yes for IEC 61850 (http://libiec61850.com); yes for OPC UA (from Microsoft, see above).

IEC 61400-25-4 Mappings: IEC 610870-5-104 AND/OR IEC 61850-8-1 MMS?

As an engineer I have been involved in many discussions on protocols – for the last 30 years. Sometimes it seems to be better to just ignore the arguments pro and contra a specific solution. The mapping in IEC 61850 uses ISO 9506 (MMS) as the “transport layer” of the messages required for IEC 61850 client-server applications.

In IEC 61400-25-4 (WIND TURBINES – Part 25-4: Communications for monitoring and control of wind power plants – Mapping to communication profile) there are the following five options defined:

• Web-services
• OPC XML DA
• IEC 61850-8-1 (MMS)
• IEC 60870-5-101/104
• DNP3

Depending on the company you will find one or the other solution. Most applications use MMS – not all.

Yesterday I attended a presentation of a big (well known wind turbine manufacturer). The presentation showed the use of IEC 60870-5-104 to communicate information defined in IEC 61400-25-2 (Information Models). The fourth option expressively allows to use 104. So, does this mean the market will split in five parts? Why should this happen?

The following application running on the WEB-PLC of the Beck IPC com.tom shows that it is quite easy to support one or the other solution or BOTH – at the same time.

The com.tom 5.1 provides two servers: IEC 60870-5-104 AND IEC 61850. The decision which signal to communicate by which protocol is engineered by drawing a line (on a standard web browser!) from the source information (coming from the Janitza UMG 604 power quality analyzer) to the corresponding output signal: IEC 60870-5-104 and/or IEC 61850:

The two clients on top (left QTester104, right IEDScout) can tap the same information. It is no question anymore: either ONE or the OTHER. The communication of the signals can be decided by drawing a simple line – without programming a single line in C/C++ or IEC 61131-3. Sure, the applications to be run on the com.tom family of products can also be programmed in IEC 61131-3 (CoDeSys) and C/C++ … which means: it is more work.

The WEB-PLC Object at the bottom right in the above figure can be an IEC 61400-25-2 object like: WGEN1.PhV.cVal.mag. For the platform these are all just names. I will provide more examples soon.

This solution shows that there is no need to fight for one or the other solution: just use whatever fits with your needs. DNP3 will be available soon … Modbus RTU is already used (see above).

Workshop of USE61400-25 Users Group in Hamburg was a very big Success

The workshop on IEC 61400-25 (IEC 61850 extensions for wind turbines) at Senvion (former RePower, Hamburg) was a very big success! The 40 attendees appreciated the high level of presentations on several aspects of the standard: Information Models, Modeling, Information exchange services, Mappings, Applications, solutions, testing, and certification.

The USE61400-25 Users Group was very active in promoting the standard and how to reach a high level of interoperability and – of course – conformity!

It is very likely that this workshop has inspired several people present that are not yet members of the Users Group.

Membership in this Users Group provides an excellent platform to exchange experiences, educate experts, to support the standardization process, and the testing of devices.

Check the Users Groups website for news – you will find also news about the wind power applications on this blog. Several people thanked me for the great content they find on this blog! You are welcome!

Stay tuned.

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

Open Source Synchrophasor Framework for IEC 61850-90-5 under development

On October 02, 2011, I announced that the IEC TR 61850-90-5: “Use of IEC 61850 to transmit synchrophasor information according to IEEE C37.118” is on its way for official publication; expected by end of 2011.

To accelerate the application of the technology defined by IEC 61850-90-5, Cisco, Inc. (CSCO) and Systems Integration Specialists Company, Inc. (SISCO) have begun an open source project intended to provide an implementation framework for synchronized phasor measurement communications.

They expect that an “open source project will foster innovation and faster adoption of the standards using IP-multicast and a scalable security architecture´. … For the open source project, Cisco will provide source code for the Group Domain of Interpretation (GDOI) protocol. This protocol provides the type of advanced cyber key management services that are needed to secure communications for power system automation applications, including substation automation and protection, as well as for Smart Grid applications such as metering and demand response. SISCO will provide the source code for the IEC 61850-90-5 communication profile and the integration of that profile with the GDOI code. …”

Click HERE for the press complete release published by Cisco.

It is very likely that this project will push the application of IEC 61850 in North America and all over.