Introduction

The Standard has been developed to provide three key elements:

• The standardized language and files to exchange system configuration information at each stage of the engineering process
• The generic elements to build a domain specific, standardized information model that defines the syntax and semantic of the information that will be exchanged
• The fundamental aspects as a communication protocol to facilitate the exchange of the information

The Standard has reached a level of maturity that asset owners can have the confidence that it will work as it has done in thousands of substations and electrical installations already.  Certainly the vendors are rapidly increasing the scope of their implementations in the products and the tools are becoming far more capable in handling the complexities of system integration engineering and catering for the individual vendor solutions. There is of course scope for further work in all these areas as in the skills of engineers to use them.
While the scope of the first publication of IEC 61850 was limited to define information models for a substation automation system due to its generic characteristics, it soon attracted the interest of other domains. Between 2005 and 2010, new parts have been added to the standard that defined information models for hydro power plants, for distributed energy resources and for wind power plants.
In the meantime, a second Edition of most of the parts of IEC 61850 that have first been published between 2002 and 2005 has been prepared. The new Editions of those parts have added new elements that extend the capabilities of the standard such as: the description of concepts to define models for statistical evaluation of information; the possibility to have hierarchical structures of logical devices or the extension of the scope to be used as well for the communication between substations. Today, several working groups both within IEC and IEEE are working on the development of new features that will further extend the capabilities of IEC 61850 and that are important for the future role of IEC 61850 as the backbone for Smart Grids. In this article, we will describe the scope and approaches of a few of these activities. It has to be noted that many of the topics presented in this article are still under discussion in the working groups - so what is presented here may still change before the final publication as a standard.

Logic Modeling

A. Distributed Automation System in IEC 61850: In a distributed automation system, elements of the automation functions are implemented in physically separated devices. The functional elements realized in these devices need to exchange signals to operate correctly. In a substation automation system, a functional element can typically be realized as one of the following:

• An algorithm - e.g. the algorithm for a distance protection element or for the calculation of rms values of the current, voltage and other quantities of the power system. This algorithm will be implemented in the device specific software delivered by the IED vendor
• A logic or state machine – e.g. the behavior of a breaker failure function or the calculation of interlocking conditions. This logic or state machine can either be implemented as part of the device software or it can be a user configurable logic. It may also be the case that some elements of the logic are predefined by the vendor but may be customized by the user

In an IEC 61850 based system, logical nodes (LN) are the containers that describe the functional elements. While the internal implementation of the functional element represented by the logical node is out of the scope of IEC 61850, the standard defines the information interface of the functional element in terms of data objects and data attributes of the logical node. In IEC 61850-5, edition 1, a generic overview of the information interface for protection logical nodes has been provided as "communication structure" in Figure 6 of IEC 61850-5.

A summary of this figure is provided in Figure 1 which shows the information flow in a hierarchical context. Besides this hierarchical structuring, we can identify the following types of information:

• Binary or analog inputs as signals received from other LNs or from the process
• Settings, typically received from HMIs whilst in service or through pre-configuration
• Outputs as signals to other functions or to the process
• Outputs as data / values for HMI, gateway, archiving function

The above is not only valid for protection functions; it can be applied to all kinds of functions. In that case, we may also have controls as another type of input, typically received from HMIs and gateways. The IEC 61850 modeling approach does not differentiate between outputs as signals to other functions or to the process and outputs as values for HMI or gateway. Based on that, we can generalize the information structure of a logical node as shown in Figure 4.
Edition 1 is defined for each logical node outputs (status information, measured and metered values), controls (binary controls as well as setpoints) and settings. The difference between controls and settings is defined as follows:

• Controls are data changed by commands. They are typically changed remotely and during operation much more than the settings
• Settings are data needed for the function to operate. They may be changed remotely but normally not very often

Edition 1 of the standard did not define inputs. From a communication interoperability viewpoint, it is not needed to standardize inputs. To achieve interoperability on a communication level, an IED needs to know the data it can receive from another IED- so the output of the IED needs to be standardized. However, what the receiving IED does with this information is a local issue of the IED functionality defined by the vendor.

B. Building Applications with Logical Nodes: IEC 61850, applications are built by connecting logical nodes with signals. The signals exchanged are standardized with the full semantic meaning as data objects in the logical node that provides the output of the signal. An application example is provided in Figure 5. The data object TVTR.Vol is defined in the standard as the samples of the voltage waveform measured by the logical node TVTR; the data object PDIS.Str is defined as the information of when the distance element has detected a start condition.
The logical node PTRC represents the tripping logic of a multifunctional protection relay as shown as the combination of three PDIS in order to simplify the subsequent signals and provide certain conditioning of the trip signal. The data object PTRC.Str indicates that one of the protection LNs has picked up, i.e. detected a fault condition. The data object PTRC.Tr is the physical trip output to the circuit breaker and may be configured to be prolonged for a particular minimum period; the data object PTRC.Op indicates that the relay has operated – its semantic meaning is similar to PTRC.Tr, but it may also include a direction indication per phase. The data object PTRC.Tr or PTRC.Op can be used to interact with other functions like the initiation of a breaker failure protection or auto reclosing function. This is illustrated in Figure 2.
While the outputs of logical nodes have been standardized in Edition 1, the inputs have not been defined. From a communication interoperability viewpoint, this is sufficient. However, a significant advantage of IEC 61850 is in the semantic object definition provided by the part IEC 61850-7-4 and the engineering framework defined in part 6. This is a step beyond the pure communication interoperability as it could already be achieved by traditional SCADA protocols like IEC 60870-5 or DNP3. Edition 1 of IEC 61850 already supported the possibility to document the signal flow with inputs to logical nodes in the substation configuration description files (SCD files). Edition 2 added the possibility to document this as well with a data object InRef in the logical nodes as illustrated in Figure 2. Multiple instances of that data object may exist to document multiple inputs into a logical node.
The routing of signals between logical nodes is an important step in the design of an IEC 61850 system for the implementation of control, protection and measurements schemes. As part of the system design, this is typically done by the System Configuration Tool. If wires are replaced by GOOSE messaging, the System Configuration Tool will convert the routed signals in a dataset and associated GOOSE message. The result of the system design process shall be available in the SCD file so that it can be imported by the IED Configuration Tool for the final engineering of the IED.
Using these concepts, it is possible to provide the IED Configuration Tool, with the definition of signals that the IED shall receive. However from a system engineering perspective, it cannot be indicated, what the IED shall do with these signals. In the example of Figure 2 the signal has to be interpreted as "Initiate breaker failure function". For another receiving function, this same source signal could be interpreted differently, perhaps even as a blocking input rather than an initiate input. But this semantic interpretation of the input within the logical node receiving a signal cannot be declared today. In Edition 2 of IEC 61850, the only semantic definition of inputs is for inputs that are used for a dynamic blocking of the functional element represented by a logical node. For that purpose, a data object BlkRef has been added that can be used as illustrated in Figure 3. Here, the data object PDIS1.Str indicating that Zone 1 protection has detected a fault is used to block the protection function of IED 2.

In typical applications, multiple inputs will feed a logical node. These multiple inputs may have individual semantic meaning or they may be combined to be used as an input to the core function. As an example, a distance protection element (LN PDIS) needs the currents and voltages of the three phases. But in a 1.5 breaker scheme, it may receive current measurements from two current transformers where first a summation of the current has to be made before it is used for the distance algorithm. Or again in the 1.5 breaker scheme, the middle breaker may receive trip signals from two different protection functions – in that case, both signals have to be interpreted as trip signals.
A typical example, where different logic functions are required to implement a scheme at system level, is the breaker failure protection scheme. We will discuss this with the example of a double busbar configuration as shown in Figure 6. In that example, if a breaker fails, the breakers in the other bays need to be opened, if the feeder is connected to the same busbar as the feeder of the failing breaker. Assuming, bay Q1 and Q3 to be connected to busbar BB1 and bay Q2 connected to BB2, if the breaker of bay Q1 fails, the breaker of bay Q3 has to be opened, but not the breaker of bay Q2.
For the implementation, let's assume that each of the IEDs implements the breaker failure function for the local breaker (LN RBRF). The function supervises the breaker position and the current flow to determine a failure. It may then try a local retrip (object RBRF.OpIn) and if that fails, it has to request an external trip to the neighbor breakers (object RBRF.OpEx).

There are at least two possibilities, to realize this scheme.
1) The signal RBRF.OpEx is forwarded to the other bays together with the position of the busbar disconnecting switches QB1 and QB2. It is a logic function in each of the other bays to decide based on the positions of QB1 and QB2 both in the failed bay as well as in the own bay to open the local breaker
2) The signal RBRF.OpEx is conditioned with the position of QB1 and QB2 to forward a signal like "RBRF.OpExBB1" or "RBRF.OpExBB2". This requires a logic function in the failing bay and the creation of new signals. In each of the other bays, the logic function is then reduced to only verify the positions of the local QB1 and QB2

If the second solution is chosen, the data objects OpExBB1 or OpExBB2 do not exist in IEC 61850. To be able, to put them in a GOOSE message (and hence, in a data set) these signals need to be mapped to an IEC 61850 data object. Very often, the logical node GGIO will be used for that, with the significant disadvantage to future refurbishments and augmentations of loosing the semantic context of the signal (what does GGIO756.Ind1 represent?). In our example, a better approach would be to create two logical nodes PTRC (BB1PTRC and BB2PTRC) and forward the signals as BB1PTRC.Tr and BB2PTRC.Tr.

D.  IEC TC57 / WG10 Task Force on Logic Modeling: As seen from the previous example, if it shall be possible to design such a scheme with a system configuration tool, additional definitions are required for the standard. The system configuration tool needs to be able to describe scheme logic in addition to the pure routing of logical signals. This topic is addressed by a new task force in TC57 WG10 that will prepare a technical report IEC 61850-90-11 "Methodologies for modeling logics for IEC 61850 based applications".
In a first step, the task force is analyzing use cases and identifying requirements. As part of this, the principle structure of a logical node has been discussed. Referring to Figure 4, a logical node represents a functional element with inputs, outputs, controls and settings. The functional element is realized either as an algorithm or as a logic or state machine. If it is an algorithm, it is typically a software implemented by the IED vendor. The same may be true if it is a state machine or a logic function. In some cases, the system integrator may program the behavior using programmable logic.
Looking into more details, there is a core behavior of the logical node as a functional element and some logic or arithmetic evaluation of multiple inputs as e.g. the current summation of the inputs to a distance element. As a consequence, a generic distributed function will be realized as shown in Figure 10. Signals, as outputs from functional elements (e.g. Fct1 or Fct2; this would be logical nodes in IEC 61850) will be used by other functional elements either directly or through some logic functions.
Depending on the distribution of the functional elements on physical devices (IEDs), these signals need to be realized either as binary hard wired signals or as part of GOOSE messages. In the above example, let's assume Fct1 and Fct2 are realized in IED1, Fct3, Fct4 and Fct5 are realized in IED2 as indicated. A key decision is therefore, in which IED to place the logic. Outputs from logical nodes have a well determined semantic and can be easily integrated into a GOOSE message by reference to the data object in the data set. Outputs from a device internal logic function are not standardized and can therefore not be referred to in a dataset. In the example of Figure 10 this is the signal indicated in red as output of logic 1 that goes to Fct4.
As a consequence, generic logic functions should preferably be realized together with the functional element or logical node that receives the signals unless it is possible to realize the logic on the sending side in a way that some semantic information is available. An example for this is the use of a LN PTRC as explained earlier for the breaker failure function to forward a trip for e.g. busbar 1 or busbar 2.
So as a consequence, the task force of WG10 came up with the detailing of a logical node as shown in Figure 8 as one example. The grey box would be the logical node. As part of the Edition 2 functionality, references to generic input signals (InRef) and to blocking input signals (BlkRef) can be defined. If multiple blocking signals exist, it seems to be obvious that a logical OR function will apply on these signals to realize the one blocking signal to the core function of the LN.
For the other inputs, a logic function may need to be described. Methods to describe a logic function as part of an SCL file are currently discussed in the task force. The above example shows the logic function as part of the logical node itself. It could as well be possible to place it outside the logical node. A current proposal suggests using the logical node GAPC (Generic Automatic Process Control) for that purpose (Figure 11).  With that approach, it may be possible to have the logic function in a different IED - but the signal between the two IEDs will not have semantic meaning.

Setting and Setpoints

Edition 2 redefines the common data class APC (Analog Process Control). However there are still different interpretations which have necessitated creating a TISSUE to provide clarification.
It has been clarified that a setting is a configuration or system parameter where the value does typically not change within a certain context. As an example, settings for a protection function are defined based on the physical parameters of the power line and are configured during system commissioning and will not change as part of operational activities. An exception to this are setting groups, where it is possible to change from one set of values to another one depending on changes of conditions in the power system.
Setpoints will be set as part of the operation of the system. The values change based on process conditions. A possible setpoint may be the active power to be produced by a storage battery or the target voltage to be reached by the voltage regulation function. For analog settings, the common data class (CDC) ASG is used; the values can be changed through write services or through setting group changes. For setpoints, the common data class APC is used, the value can only be changed through control services.
The CDC APC is also used for controllable analog process values like e.g. the position of the Peterson coil or the position of a hydraulic gate. There is a significant difference about the semantic interpretation of the status information (the data attribute with the functional constraint MX). If the CDC APC is used for a process value, typically on objects with a direct control possibility, the MX attribute (or return information) contains the actual value of the controlled object, as an example, the actual position of the hydraulic gate.
If the CDC APC is used for setpoints, the situation is different. In that case, the setpoint is typically an input to a regulation function; the result is available as a measurement in a different logical node such as MMXU. Note that it is not guaranteed that the exact value can be reached. In that case, the return information – the MX attribute of the CDC APC – shall represent the value of the setpoint as it has been set.
It has been agreed that this behavior – whether a data object of the CDC APC is a setpoint or a controllable analog point – shall be clarified for each data object individually as part of IEC 61850-7-4 or other parts defining logical nodes.

Usage of the Functional Part of an SCL File for Application Domains Beyond Substations
A. The Extended Scope of a Process Section: A file based on SCL (System Configuration Language) as defined in IEC 61850-6 has three core sections:

• Communication section, that describes the communication topology and contains all the communication related configuration information like IP addresses for the different devices
• Multiple IED sections; each of them describing the capabilities and the data model of one IED
• One or multiple substation sections as process sections describing the topology of the substation and the binding of logical nodes realized in the IEDs to the process

While the first two sections are generic, the substation section so far is limited to applications within a substation. However, with the extension of the scope of IEC 61850, it becomes a desire to be able to describe as well process parts of other domains, e.g. the structure of a wind power farm or the details of a hydraulic power plant.
The modeling of a plant in a process section (as an extension of the already existing substation section) provides the possibility to create a naming hierarchy for functional names and allows the generic binding of all information in the IEDs to the process. Also, it will be possible to give generic logical nodes like e.g. a LN CALH (Alarm handling) a better semantic context.
A functional name for an object is using the process hierarchy rather than the physical device hierarchy (Figure 9).  Figure 7 shows a simplified example of a wind power plant. While it is possible today already to describe the details of the substation, in order to be able to describe the reminder of the plant, new elements need to be introduced in SCL.

B.  Extensions to SCL: To be able to model a generic process section, several extensions are proposed to be made to the substation configuration language (SCL). These extensions should be available with a further revision of the SCL schema and  IEC 61850-6. Since not all plants are substations, it was decided to add two new sections with the same level:

• One or multiple recursive process section to model non-substation physical structures
• One or multiple line sections to model lines between substations or other electrical connections which are not included in a substation

The new process element is a recursive structure. A process element can contain again Process elements, Line elements or Substation elements. Besides that, the process element may have LNodes, Function, GeneralEquipment or ConductingEquipment. A typical ConductingEquipment would be a generator.
Like the ConductingEquipment these new elements have a type attribute. While IEC 61850-6 already standardizes type attributes for ConductingEquipment (e.g. CBR for circuit breaker) and GeneralEquipment (e.g. VLV for valve), types for process and function elements should be standardized by the different domains.
The new line element may contain LNode, Function, GeneralEquipment, ConnectivityNode and ConductingEquipment elements. The ConnectivityNode and ConductingEquipment elements are used to further describe the line topology. Typical ConductingEquipment types to be used for line modeling are LIN (overhead line), GIL (gas insulated line) and CAB (power cable). Others are possible, e.g. it is possible to include switches as part of a line so that it is not required to create a substation section for e.g. a pole top switch in a distribution network. Not allowed however to be included as part of a line element are ConductingEquipments of type PTR (power transformer), PTW (power transformer winding) and LTC (load tap changer).

C.  Example: With these new elements, the example of Figure 7 could be modeled in principle as follows (table 2):
There exist many possibilities to define the hierarchical structure. In the example above, we have assumed that the wind power plant is grouped into multiple subplants and that the power line connecting the different wind turbines is part of the subplant. We could as well have assumed that the power line is an independent element at the same hierarchical level as the subplant. The two approaches would result in different functional names for the individual equipment.
Other variation can be made with the decision of what shall be modeled as process, what as function and what as general equipment. In the example above, it has been decided to model a windturbine as a process and not as general equipment, assuming it is intended to further model the tower, the nacelle, the yaw system, the transmission and the rotor. Therefore, it is important that the different domains develop standards or guidelines based on their existing modeling practice and naming conventions. These standards or guidelines shall define:

• Standardized types for the different process elements. WPPLT, WPSPLT, WTUR and MET as used above are just examples chosen for this article
• Standardized types for specific GeneralEquipment
• Standardized types for specific Functions and Subfunctions
• Modeling hierarchy

D. Usage of the New Extensions for Substation Automation: The benefit of extensions added to the SCL is not limited to new domains. Already in Ed. 2 of SCL, the possibility was added, to include at each element of the substation structure a Function / SubFunction structure.
A Function or SubFunction element can contain non electrical GeneralEquipment and can as well contain LNode elements.
With these extensions, a functional specification of a substation automation system provided by an SSD file can be more detailed. Types for Function / SubFunction elements are currently not yet standardized, but this is foreseen for substation automation like for other domains.
Table 1 shows an example of how a substation automation system could be modeled with these extensions: This provides several new possibilities. With the introduction of standardized types for functions and subfunctions it will be possible to better describe the semantic meaning of the many logical nodes of the same class that can be found in an IED. Typically in a protection IED you may find multiple logical nodes of the class PTOC. As it is shown in the example above, it is now possible to allocate these logical nodes to standardized functions and subfunctions and with that it becomes possible to identify e.g. which LNs are used for the phase related faults and which for the ground faults.
Another possibility is, to further structure the conducting equipment. If we have different secondary windings of CTs for protection and for control that are modeled as two conducting equipment of the type CTR, it is possible to allocate them to the protection or to the measurement function.
This is just a first example of what can be possible with the new extensions. WG10 decided recently to start developing the required guidelines and standards.

Biography

Christoph Brunner is the President of his own independent consulting company it4power LLC based in Switzerland. He has over 25 years of experience with knowledge across several areas within the Utility Industry and of technologies from the Automation Industry. He has worked as a project manager at ABB Switzerland Ltd in the area of Power Technology Products in Zurich / Switzerland where he was responsible for the process close communication architecture of the automation system. He is Convener of WG 10 of the IEC TC57 and is a  member of WG 17, 18 and 19 of IEC TC57. He is senior member of IEEE-PES and IEEE-SA. He is an IEEE Fellow and he is active in several working groups of the IEEE-PSRC and a member of the PSRC main committee and the subcommittee H. He is international advisor to the board of the UCA international users group.
                   

Sidebars:

Significant work is currently being done to further improve the engineering capability and the interoperability level.

A significant advantage of IEC 61850 is the semantic object definition provided by part IEC 61850-7-4 and the engineering framework defined in part-6.

IEC 61850 is a living standard. It provides interoperability for the communication between devices of a substation automation system.

IEC 61850 also provides a framework to facilitate the engineering of such a system. 

Methods to describe a logic function as part of an SCL file are currently discussed in the task force.

With the introduction of standardized types for functions and sub-functions it will be possible to better describe the semantic meaning of the many logical nodes of the same class that can be found in an IED.

Author:
Christoph Brunner, it4power, Switzerland