Saturday, February 16, 2013

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

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

1 comment:

Maik G. Seewald said...

Karlheinz, in 2011, SISCO and CISCO initiated an open source project which covers an implementation of IEC TR 61850-90-5. The code as well as related information is hosted since 2012. The objective is to foster a broad and quick adoption of the TR which defines IP-multicast transmission of GOOSE/SV messages over WAN.