OpenIEC61850 User Guide

After extracting the distribution tar file the OpenIEC61850 library can be found in the build/libs-all folder. For license information check the license directory in the distribution.

You can execute the console client and server through the scripts found in the folder run-scripts. Executing the scripts without any parameters will print help information to the screen. Note that under Unix/Linux you need root privilages if you want the server to listen on any port lower than 1000.

Instead of running the applications from the terminal you can create Eclipse project files as explained in our FAQs and run them from within Eclipse.

The OpenIEC61850 library includes an OSI stack implementation as it is needed by the IEC 61850 MMS mapping. The API of the OSI stack and the OSI transport layers are made public so that they can be used by other projects.

If you want to connect to an IEC 61850 server, you should first create an instance of ClientSap (SAP = Service Access Point) and configure it to your needs. Then you build up the association to the server using the associate() method.

First get a List of ServerSaps using the method ServerSap.getSapsFromSclFile(). This method reads in the SAP from the given ICD file. Take the ServerSap you want to run and configure it to your needs (e.g. set the port to listen on). The ServerSap includes the complete device model defined in the ICD file. Retrieve a copy of it using the method getModelCopy(). Tell the ServerSap to start to listen on the configured port using startListening(). This is a non-blocking function.

An IEC 61850 server contains a treelike data model that contains at its leafs the data (integers, boolean, strings etc) that can be accessed by clients. Clients can also retrieve the whole data model from the server.

The upper most model node ist called "server". In OpenIEC61850 it is an object of type ServerModel. The server node contains 1..n logical devices (LD). A logical device may contain 1..n logical nodes (LN). A logical node may contain 1..n data objects. In OpenIEC61850 the logical nodes do not contain complete data objects but instead contain so called functionally constraint data objects (FCDO). An FCDO is a data object that is split up by functional constraint. An FCDO can contain a combination of other FCDOs, arrays, constructed data attributes and/or basic data attributes.

All nodes of the server model in OpenIEC61850 are of one of the following seven types:

They all implement the ModelNode interface. The nodes FcDataObject, Array, ConstructedDataAttribute and BasicDataAttribute also implement the interface called FcModelNode because they are considered functionally constraint data in the standard. Many of the services of IEC 61850 can only be applied to functionally constraint data (e.g. GetDataValues and SetDataValues).

When programming a client you get a copy of the server model either through ClientAssociation.retrieveModel() or ClientAssociation.getModelFromSclFile(). When programming a server you get a copy of the server model through the ServerSap.getModelCopy() function.

You can then navigate through the model using several functions:

Data sets (DS) form a group/set of data. Data sets can be used to read or write several data objects/data attributes at once using a single request/response message exchange. The service used for this are GetDataSetValues and SetDataSetValues. Besides the data set services the reporting, logging, GOOSE and sampled value services also use the data set concept.

The data attributes or data objects that are part of a data set are called the members of a data set. Only functionally constraint data may be a member of a data set.

The IEC 61850 standard defines five ASCI services related to data sets:

Two types of data sets exist:

Reporting allows a server to send data based on events and without explict request by the client. What data is sent and the events that cause reports are configured through so called report control blocks (RCB).

The standard distinguishes between two types of reporting: buffered reporting and unbuffered reporting. With buffered reporting reports are buffered by the server in case a connection to the client is interrupted. This way reports can be sent after the client has connected again. Buffered reporting is configured through buffered report control blocks (BRCB). Unbuffered reporting is configured through unbuffered report control blocks (URCB).

RCBs are located within logical nodes of the server’s data model (i.e. the server’s ICD/SCL file). They are fixed and cannot be deleted or added at runtime. An RCB is blocked once a client has registered to receive reports (by enabling it). That means a single RCB cannot send reports to several clients in parallel.

RCBs are always associated with a specific data set that must be located in the same logical node as the RCB. A subset of the data set’s members will be reported if any of the configured events occures. The associated data set of the RCB can be dynamically changed by a client at run-time.

RCBs are located in logical nodes in the server’s model tree. Therefor the reference of an RCB is of the form LogicalDeviceName/LogicalNodeName.RCBName . Even though RCBs can only reference data sets located in the same logical node as the RCB itself, they can still monitor data from other logical nodes because the data set’s members can be located in other logical nodes.

The following events can cause a server to send a report:

Whether one of these events really causes a report to be sent is configured through the RCB.

A report control block contains the following fields:

A report always contains the following information fields:

A client that wants to receive reports from a certain RCB would usually first attempt to reserve the RCB. If successful he would then configure the RCB as he wishes. Finally he would enable reporting.