Summary

Module name: IEC 61850 Client Communication Protocol
Current Version: 1.3
DLL ImplementationP: T.ProtocolDriver.IEC61850.dll
ProtocolP: IEC 61850 Edition 2
InterfaceP: TCP/IP
Description: .NET implements the part of the IEC 61850 standard responsible for the ACSI service core, as defined in section 8-1 of that standard. It uses ISO/OSI transport layer encapsulated in TCP/IP transport layer. Performs communication with IEDs (intelligent Electronic Devices), RTUs (Remote Terminal Units,) and IO devices compatible with this protocol, acting as client station.
System Requirements: Use of the software Action.NET
Observation: This communication module was re-written for version an-2016.2, using a library other than the one previously used, and changes were also made in the configuration procedures of channels, nodes and points. The following item provides notes to assist in the migration of projects that already used the module from the previous version.

TagProviders and Device Channels

There are 2 independent ways to use this protocol. Using a TagProvider configuration, or as a Device-Channel.

TagProvider allows you to connect with data in devices directly, without create local tags, using the name definition on the remote device.

DeviceChannel allows to map tags in the project to external data addresses, giving more flexibility on name conventions and managing data blocks.

This document has the specific information about the device configuration on both methods. For a Generic Explanation on TagProviders, or about the Device Module, Channels, Nodes and Points, please refer to the reference users guide.

Migration

Users of the Action.NET who use the communication module of edition 1, need to update the registration of channels, nodes and project points. The migration should be done by following the steps below:

1. Copy all points for nodes from project Communication Module 61850 to an Excel spreadsheet.

2. Delete all points for nodes from project Communication Module 61850.

3. Copy the names of the project nodes and channels to the notebook.

4. Erase all nodes.

5. Delete all channels.

6. Create the channels with the previously copied names in step 3. Setting each channel according to session CHANNEL CONFIGURATION

7. Create the nodes with the previously copied names in step 3. Configuring each node according to session CONFIGURATION OF NODES

8. Paste the previously copied points into step 1.

9. When starting the Communication Module. Validations of registrations will be carried out. If there are inaccuracies in point definitions, they will be recorded in the Log (See session 7.1 - Records of operations and check how to fix them in the session CONFIGURATION OF POINTS.

IEC Standard 61850

This topic aims to briefly present some information of the IEC 61850 standard, which directly interferes in the definition and implementation of this communication module.
For more details and a formal description, refer to the standard texts or the documentation of the server IEDs.
The standard consists of ten parts, listed in the table below.

With regard to support for data communication, between computers and IEDs, standardized by the standard, the message types are defined, listed in the table below.

One of the great advantageous differentials introduced by the standard, in the definition of its data communication protocol, is the fact that the points internal to an FDI are not addressed by numbers, as in other protocols, but are considered "objects" and addressed by names that are standardized by the standard.
Internally to IEDs IEC61850 there is a map of objects, arranged in a hierarchical structure. In communication between a customer (e.g. Action.NET) and the server (for example a digital-IED shuttle) traffic in the protocol messages these object names (at least in the initial communication establishment).
To get a general idea about these object names, the structure of the hierarchy of iEC61850 address maps is presented here.

LD - Logical Devices – It is the logical devices within this physical server, which function as "containers" of functions (Logical Nodes) or even as "gateways" between LNs of different LDs. The internal Names of the IED are usually used in the initial part of the name (prefixes) and suffixes that indicate the main function of the LD. Examples of CTRL, MEAS, etc. suffixes.
LN - Logical Nodes – These are objects that implement the basic well-defined functions within logical device. Logical Nodes names are standardized. Each LN contains objects, datasets, definitions of Reports, Logs, parameter groups, and services that implement objects and functions. For example, a sectioning key, its state, its control, such as the one named "Q0CSWI1". The LN in this case is the CSWI - "Switch controller". Other examples of LNs would be those performing measurement functions (MMXU), voltage transformer (TVTR), overcurrent protection (PTOC), thermal protection (PTTR). A complete list of NLs for use in substations IEDs and the rules for the formation of their names are presented in IEC61850- Part 5.
FC - Functional Constraints – The Function defined by LN will contain several objects that are distributed into categories defined as FC-Functional Constraints. For example "CO" that will contain command objects, "ST" that will contain digital signage objects, "RP", for objects of type Reports. Figure 4 shows measuring objects that fall into the "MX" category. The following list of CFs was obtained in iEC61850 Part 7-2- 2003 - Table 18 - In the original table there are more details about each item.
ST Status information
MX Measurands (analogue values)
CO Control Attribute shall be operated (control model) and read
SP Setpoint DataAttribute shall represent a set-point: value may be controlled and read.
SV Substitution DataAttribute shall represent a substitution
CF Configuration DataAttribute shall represent a configuration
ANNO DOMINI Description DataAttribute shall represent a description
SG Setting group Logical devices that implement the SGCB class
IF Setting group
EX Xtended definition
BR Buffered report
RP Unbuffered report
LG Logging Attribute shall represent a log control
GO Goose control Attribute shall represent a goose control
GS Gsse control Attribute shall represent a goose control
MS Multicast sampled value control
US Unicast sampled value control
DO - Data objects - Data Objects are objects, with standardized names, that contain the information itself. These objects can be simple, such as the "Pos" object, which provides the circuit breaker position information. There are more complex objects "A", which represents a three-phase current. It consists of four Data Attributes, each of which, with data attributes children current information of each phase and a neutral. In the latter case, multiple levels of Data Attributes are found in the hierarchy below a Data Object.
Examples of DataObjects are:
Beh - Behavior of LN
Health - state of the logical node related HW and SW.
Loc - switchover between local and remote operation
Mod - Mode and behavior: On, Blocked, Test, Test/Blocked, Off
Pos - Switch position
A - Current
neut - phase neutral
phsA, phsB,PhsC – phases A, B and C
Hz - Frequency
PPV - Phase to phase voltages.
PhV - Phase to ground voltages for Phases 1, 2, and 3, including Angle
DA - Data attributes -Each object hierarchically below a Data Object or other Data Attribute, in the case "ctlNum" or a current phase as "phsC". Examples:
In the case of "Pos" you can see four Data Attributes:
stVal - which contains the state of the circuit breaker
q – the quality of the data
t – sampling timestamp
ctlNum - number of data object status exchange sequence
In the case of the current "pshC", besides being a Data Attribute itself, it still contains 4 Data Attributes below you:
cVal - the measurement of the current
instCval - instantaneous measurement of current in last acquisition
q – the quality of the data
t – sampling timestamp.

Communication Module

The communication module (Communication Module) consists of two libraries that work together: Communication and Integration.

Communication Library

The communication library is developed in the C++ programming language and is responsible for communication between the Communication Module and equipment. It has been designed according to standard series 2 edition 2 IEC 61850.

Supported objects

The following table provides an overview of the supported IEC 61850 objects.

Supported services

The following table provides an overview of the Supported Abstract Communication Service Interface (ACSI) services.

Integration Library

The integration library is developed in the C# programming language and the library is responsible for the integration between the Communication Module and SCADA. It aims to transpose the information read and written between the equipment and the Action.NET.

Implemented objects

The following table provides an overview of the Implemented IEC 61850 objects. The fields marked (✓) indicate the implementation of the service.

Implemented services

The following table provides an overview of the IEC 61850 (Abstract Communication Service Interface) (ACSI) services implemented. The fields marked (✓) indicate the implementation of the service.

Functional Constraints implemented

The following table provides an overview of the Functional Constraint property found in each attribute of a logical node. The marked fields (✓) indicate the implementation of reading or writing.

Operation

The communication module works briefly with the following sequence of steps.