Reducing engineering costs using IEC 61850

BY ADAM GAUCI, Schneider Electric

As substation automation is moving towards software environments based on the International Electrotechnical Commission’s substation automation standard, IEC 61850: “Power Utility Automation”, the engineering process is becoming more complex. Consequently, a greater portion of the capital expenditure (CAPEX) budget is used to develop new—or upgrade existing—substations, especially in interoperable, multi-vendor environments. This can be attributed to the increasingly complex automation schemes which are now possible, and the learning curve associated with having to learn a multitude of different configuration tools currently required during the engineering process of a substation automation system.

One problem today is that many vendors of substation systems have tried to adapt proprietary methodologies into their native tools for configuring IEC 61850 communications within a substation. This leads to incompatibilities between devices and configuration tools from different vendors. It also increases the potential for incorporating human error into the process as engineers have to use multiple tools to configure a substation automation system.

DATA WITH CONTEXT
Preparing a tabulation of functions for monitoring and control of a substation by a central SCADA (supervisory control and data acquisition) system can be a complex task. With the multitude of new intelligent electronic devices (IEDs) with communications capabilities such as protection relays, controllers, remote terminal units (RTUs) and gateways, a lot of different players are now involved in the process. These players usually have very different roles and priorities. For example, a protection engineer may be involved with the data mapping of a protection relay, but his/her primary function is to configure the protection settings of the relay. As data flow progresses up the hierarchy from device to SCADA, data must be passed through many different systems, and through teams with different competencies which makes it difficult to ensure the data context stays intact.

With traditional SCADA protocols such as DNP3 (Distributed Network Protocol), many engineers would use spreadsheets and other forms of documentation to pass the context of the data from level to level. An alarm at a protection IED would be mapped to a DNP3 index; this index could be mapped to data concentrators by a controls engineer, and finally mapped to a SCADA front end processor. As the data is mapped from index to index, it is easy to lose the context of the data through human error when compiling such mapping tables.