IEC 61850 Edition 2 and Engineering

Author: Wolfgang Wimmer, ABB Switzerland

Further there are additions to overcome problems experienced with Edition 1, and due to new functionality needed for other application areas. For backwards compatibility all additions are optional. Thus, if the new features shall be used, it should be checked if the envisioned Edition 2 IED has really implemented it.

In practice the first actual usage of the SCL language at system level was the functional and naming related specification of projects, leading to some unintended error prone usage of IED related SCL files during the engineering process. Thus one of the biggest issues for edition 2 was to better clarify the usage of SCL files and the responsibilities of system level and IED level tools for certain parts of an SCL file at different phases of the engineering process. This started in IEC61850-4 Edition 2 by taking up the basic engineering related concepts of part 6 and integrating these into the engineering process definition. It is continued in part-6 itself in the context of the SCL language. Below we will take the part-4 engineering process as a guide through this process and explain the basic new engineering related features of Edition 2 for these phases. As a start an overview across the whole process according to part-4 with additional consideration of corrective actions in individual phases is shown on page 38.

System Requirement Specification
The customer (project requirement engineer in part-4) defines the requirements for his system. Edition 1 already provided the SCL based SSD file (System Specification Description) as a formal means for defining the process related functional names of all switchgear, and define at IEC 61850 logical node and data object level which functions respective functional interfaces are expected for which part of the primary equipment. Edition 2 allows some more previously forgotten primary equipment to be modelled, however also broadens this to hierarchical modeling of arbitrary functions, e.g. bay protection / distance protection / protection zone / impedance protection with appropriate customer designations.  Further it supports additional customer function types as well as types standardized by other application areas, thus opening up SCL for modeling other primary processes and not just substation automation, as long as the function designations are hierarchically built according to IEC 81346. This formal system functional specification allows already automated consistency checks e.g. on signal names or missing function parts.

This enhancement of the SCL substation structure additionally allows to have unique, mainly customer defined functional names for each logical node, and thus for each data object. This is an important feature to have higher level respective application level engineering independent from the physical allocation of logical nodes to IEDs respective independent from the IED related names given by manufacturers, thus supporting functional application testing and simulation before any physical application architecture is decided. For more details see also PACWorld from spring 2008, Designing IEC 61850 systems for maintenance, retrofit and expansion


Specification of the System Design
The system design specification is the response of the system integrator (project design engineer in part-4) to the system requirement specification of the customer. Based on the requirement specification (e.g. including an SSD file) IEDs fulfilling the needed functionality are selected, the communication in between engineered, and the communication system designed to support the needed functionality and quality properties. The selection of IEDs can be built on the formal SCL description of an IED called ICD file provided typically by the IED manufacturer, describing the IED functionality in terms of logical node instances and its engineering and communication capabilities. Here Edition 2 has added more details and more options for the available communication redundancy protocols, available client services, limits of data flow engineering etc. allowing a more fitting IED selection as well as a more secure IED system engineering by a system tool. One should observe however that a performance check still has to be done. If IED performance limits are known, this can be automated to a certain extent, otherwise manual work or even IED (type) testing is needed. Edition 2 allows to model the communication system itself by introducing switches as IEDs and cables connecting the switches as well as the IEDs to the switches, even with redundant links. Thus a formal description of the communication system exists, offering a base for checking its consistency and redundancy as well as how it fits into the physical geography of the project. The result of this in terms of part-6 is the SCD file (System Configuration Description), even if the detailed data flow between the IEDs is still missing.

Power. Flexible. Easergy.
Let?s start with organization in protection testing