IEC 61850 Interoperability: What the Standard Requires

What the standard means by interoperating

The goal of the IEC 61850 series is interoperability between devices from different manufacturers or, more precisely, between substation functions that reside in devices from different manufacturers. Part 5 (edition 1) breaks it down into three aspects:

• Syntax: the devices must be able to connect to a common bus with a common protocol.
• Semantics: they must understand the information the others deliver to them.
• Joint function: they must carry out a common function together when applicable, that is, distributed functions.

The standard makes clear that interchangeability is outside its scope. To replace one device with another without changes, besides interoperating, the functionality would have to be standardized, and IEC 61850 does not do that: it does not define how a protection operates, only how it communicates (see substation automation functions). The acronyms and terms of the standard (LN, LD, DO, CDC, SCL, ACSI) are grouped in IEC 61850 Glossary.

Three families of requirements

Because the standard does not restrict the structure of the system or the data exchange, it imposes requirements that must be met to ensure interoperability.

Static design requirements (clause 6.2 of part 5)

• The communication must allow any function to reside in any device. This does not oblige every device to support every function.
• The functions and their communication behavior are described without depending on an implementation in a specific device.
• They are described only as far as needed to identify the information that is exchanged.
• The interaction between distributed functions is described with logical interfaces, which can be freely assigned to physical interfaces or local networks. See levels and interfaces.
• The standard must remain open to the communication requirements of future functions.

Dynamic interaction requirements (clause 6.3)

• Define generic communication information and behavior, with extension rules, for planned or future extensions.
• Define the data with all its associated attributes (PICOM, see PICOM in IEC 61850-5).
• The exchanged data must carry all the attributes needed for the receiver to understand it without ambiguity.
• Define and guarantee in any situation the acceptable total transfer time. The times are in message types and performance classes.

Response behavior requirements (clause 6.4)

• The reaction of the receiving node must fit the overall requirement of the distributed function.
• The basic behavior of the function must be specified for degraded cases: erroneous messages, data lost due to a communication interruption, resource limitations, out-of-range data, a remote node that does not respond.

These last are local matters of each function and fall outside the series. What does fall to the series is delivering the quality attributes that travel with the data.

How the standard goes from requirement to test

Part 5 (clause 6.5) describes the path: identify the functions and categorize them according to their communication requirements; break them down into communicating entities (logical nodes); and define a data model and communication services (part 7). That model is mapped unambiguously to current communication stacks (parts 8 and 9).

A detail of part 1 (clause 7.1) explains why the standard has layers: it defines abstract services (ACSI), independent of a specific protocol, and then assigns them to concrete protocols through specific mappings (SCSM). The internal implementation of the device’s interface with the abstract services is a local matter. The standard offers several mappings for the substation, and the choice depends on the functional and performance requirements.

The conformance test and what it does not cover

Interoperability depends on two things: the properties of the device and the design and engineering of the system. That is why the standard separates two levels of verification.

Device conformance. Part 10 defines it as the type test of the device’s communication and, because communication forms a system, the test of the IEDs incorporated in it. The manufacturer delivers the device ready to test, a protocol implementation conformance statement (PICS), additional information for testing (PIXIT), a model conformance statement (MICS) and the manuals. Based on that documentation, the test suite is customized. The device tests include, as applicable and in positive and negative form:

• inspection of the documentation and of version control;
• verification of the device’s configuration file against the syntax schema and against the object model;
• verification of the communication stack against the applicable mapping;
• verification of the implemented ACSI services;
• verification of the manufacturer’s own extensions.

Part 10 points out that these tests concentrate on situations that are hard to test in a factory or site acceptance test and that prevent interoperability risks: delayed, lost, duplicated or out-of-order packets; names or data types that do not match; limits or timeouts exceeded; forced negative responses and simultaneous operations from several clients.

Project tests. The standard is explicit: conformance does not replace system-specific tests, FAT and SAT. These depend on the client’s requirements for a specific substation, are carried out by the integrator and are normally witnessed by the client. They increase confidence that potential problems were identified and resolved and establish that the system performs as specified.

What this means for the buyer, the designer and the commissioning engineer

• When buying: ask for the device’s PICS, MICS and PIXIT statements and compare what it implements with what your design needs. A conformance certificate does not show that the device implements what your project requires.
• When designing: define in writing what each function does on missing or invalid data. The standard leaves that behavior to the design.
• When integrating: use a single system engineering for all manufacturers and verify that the editions of the standard each device supports are compatible; see editions 1, 2 and 2.1 and GOOSE between relays of different brands.
• When commissioning: plan the end-to-end tests in FAT and SAT; the equipment and methods are in IEC 61850 test tools and in standards for FAT and SAT.

IEC 61850 integration testing with Tiza Group

Are you going to integrate devices from several manufacturers, or do you need to prove that your distributed functions respond properly to communication faults? At Tiza Group we carry out the FAT and SAT tests and the IEC 61850 engineering of your project, at medium, high and extra-high voltage, in substations and industry; field testing is done in Colombia, or elsewhere on request. In our quote, we recommend only the tests your project actually needs.

Related guides

• IEC 61850: what it is, parts of the standard and data model
• Substation automation functions in IEC 61850-5
• GOOSE between relays of different brands: what it takes
• IEC 61850 editions 1, 2 and 2.1
• IEC 61850 test tools
• IEC 61850 engineering: top-down and bottom-up
• IEC 61850 Glossary: Acronyms and Terms

References

• IEC 61850-5 (edition 1, 2003): clause 6, objectives and requirements.
• IEC TR 61850-1 (edition 1, 2003): clauses 7 and 9.
• IEC 61850-10 (edition 1, 2005): clauses 5 and 6.

Frequently asked questions