Designing IEC 61850 systems for maintenance, retrofit and extension

Usage of names

Names are used at system engineering time to establish relations between the different parts of the system: Relations between the switch yard (primary system) and the IED signals (secondary system), and data flow between IEDs for communication engineering respective online communication association establishment. A name change at a data source therefore leads to reengineering of all IEDs connected to the changed one respective replaced one. In former master slave architectures all data flowed between the bay level IEDs and one single central place, only the IED to be replaced and the central IED were concerned. For IEC 61850 however already for availability reasons several station level IEDs might be connected to the same bay level IEDs, and the new communication services GOOSE and SMV (Sampled Values) allow new substation functionality or existing functionality with less engineering effort and higher reliability, however introduce multiple sinks for certain signals, which might be concerned by a change at the signal source, as illustrated in Figure 1.

IEC 61850 object types and data identification

IEC 61850-7 introduces IED and communication modelling concepts, and standardized data semantics by standardized names. However, the concrete instance names are additionally dependent on the physical and logical structuring of the data and therefore not a priori stable when replacing IEDs or changing the architecture. What is long term stable (as least as long as the switch yard itself), is the functional meaning of the data in relation to the switch yard respective the power delivery process. Further the substation automation functionality related to the switchyard is normally long term stable, although extensions are not excluded. Therefore IEC 61850-6 introduces a second way of identifying the same data, namely by functional designations as defined in IEC 61346.

IED related objects and their identifications

IEC 61850 as a communication standard in first line addresses data identification at communication level, i.e. at interface level between a server or publisher IED and the data receivers (clients, subscribers). To make this naming independent from the physical structure, the concept of a logical device (LD) is introduced as a management unit for functional parts. Figure 2 shows the resulting internal structure of an IED.

The communication function uses IED access points to connect clients with servers. In principle each logical node can be a client to other logical nodes on some server. IEDs which only receive data, like the OPC server AA1KA1 in Figure 1, can also be pure clients without a server.

To reach the goal of having standardized semantics, the DATA names as well as the names of DATA attributes are completely standardized. Also the semantic of the logical nodes is standardized by means of a logical node class, which is part of the logical node instance name. A real system needs instances of logical node classes, which are associated to different parts of the switch gear; therefore the LN instance identification has non standardized parts. The logical device name as a manufacturer / organization related structuring is completely free within some syntactical limits. This is illustrated in table 1 with an example designation for a switch position value within the switch control function:

MyControl LD1/Q0CSWI3.Pos.stVal

A product manufacturer typically provides IEDs as products with some predefined functionality, however with no context to the project specific usage. Therefore the LD relative name and some parts of the LN instance identification need to be given by the manufacturer independent of the unknown project, and might be needed after project engineering to associate the project specific data to the project independent preconfiguration of the IED. Therefore it is manufacturer dependent, which parts of the LN instance identification can be adapted specifically for a project.

Although this designation is mainly used for communication establishment, we might call it a 'product related' designation in the sense of IEC 61346-1, especially if the IED designation is used as part of the LD name.

From this discussion we see how the physical architecture influences the communication level naming. Table 2 illustrates this with two logical nodes for the control function: the CSWI handling control commands from the operators and the XCBR executing these commands at the circuit breaker. The architectures referenced in the table are illustrated in Figure 5.

Consequence: different physical architectures by grouping on IEDs as well as different organisational structures by means of logical devices lead to different names, even if an IED and its tool supports free naming for the non standardized parts. And the free naming is not mandatory according to IEC 61850, and naturally introduces additional engineering and testing effort - especially at LN instance level.

Function related objects and identifications

According to IEC 61346 the functional designation is at least as important for operation of a process as the product related naming for maintenance. IEC 61850-6 therefore introduces application related names of data by typically following the functions of the switch yard, however allowing additionally (with Edition 2 practically at all places) functions which are not directly switch yard related, like protection, control and automation functions, but also supervision functions outside the substation function itself like fire supervision, or functions belonging to power generation. The functional names are completely project / customer specific within the structural restrictions given by IEC 61346-1. The transition object, i.e. the place where product related name and function / application related name matches the same object, is the logical node instance. From here on all DATA and attribute names are completely semantically defined in IEC 61850. If we look into the functional names of figure 3 for the same control function handled by the IED related names of table 2, these are:

AA1E1Q3QA1CSWI.Pos

AA1E1Q3QA1XCBR.Pos

The protection related name of the operation of distance protection for Zone 1 is:

AA1E1Q3F1Z1PDIS.Op

All these names are completely independent from the distribution of logical nodes and logical devices to IEDs, and also from the LD and LN instance names.

A complete SCL file for a substation automation system, called an SCD file, includes the functional name, the IED related name, the communication related (LD) name, and the relations between them - thus serving as a data base for translation between the different designations for the same LN respective DATA object. This is shown in Figure 4 for the above example, illustrating the independence of the functional name from the IED related name up to the point where IEC 61850 provides complete semantic standardization.

Communication engineering

IEC 61850 MMS based services allow an interactive browsing of the IED data model to retrieve all communication related names. Due to the unique LD name these can be translated into IED related names as well as functional names by means of the SCD file. However, normally operational traffic is based on preconfigured data flow for services allowing spontaneous sending. These are typically:

• Reporting service for status update and time stamped events to station level IEDs like HMI, or gateways to network control centers.
• GOOSE real time service for real time functions typically between bay level IEDs, or down to process level IEDs, e.g. interlocking related data or protection trips and blockings.
• SMV services, if analogue samples are needed directly from the process, e.g. for protection, synchrocheck and  measurement functions.
  
  

To evaluate the importance of the DATA names for these services, we have to look a bit into their definition:

All services are configured by means of a data set, defining the data to be spontaneously sent, and a control block, defining when and how it shall be sent, as illustrated in Figure 6.

• The reporting service only sends the changed data values. A bit pattern in each report identifies the place of the data set to which the sent data values belong.
• For GOOSE and SMV services always all values of the whole data set are sent. The order of values in the message  corresponds to the order of the data items in the data set definition.

This means, that essentially the values sent on the wire do not contain any of the names considered earlier, just the relation between the sent values and their place in the data set definition. For correct message interpretation the receivers only have to know, to which data set the message belongs, and how this data set looks like. For reports this can be established dynamically by means of the browsing services or data set creation services, however also by static configuration with a common SCD file as base. The relation between the online message and the data set definition then is established as follows:

• Reports are MMS based and MMS associations must be dynamically established. A report client either builds its own data sets dynamically (if the servers support this), or uses preconfigured data sets. If he relies on preconfigured data sets, he can check at start-up the control block revision number on any discrepancies between static definition and actual definition on the IED.
• GOOSE and SMV messages work according to the subscription principle and are permanently sent. The message contains Ethernet level identifications like Multicast address and application identification (APPID), and the dat a set identification in the form <LD name>/<LN Name>.<Data set name>, which allows the subscribers to identify and filter the correct message fitting to the DATA they want to use from their static configuration based on the SCD file. A control block revision number, always sent in the message, allows receivers to detect any discrepancies in data set layout configuration between sender and receivers.

This interpretation of messages relative to a data set definition allows to replace e.g. a GOOSE publisher by any other IED without having to reconfigure the receivers, as long as the new IED.

• Contains the data of the old GOOSE message with same data types and same semantics (functional equivalence).
• Contains or allows configuring a data set with the same type of data values in the same order and same semantics related to the project as the old IED.
• Uses the same Ethernet level addressing (Multicast address, APPID, VLAN).
• Has the same full data set name: same LD name (if freely configurable on the IED), same LN name (LLN0 for all GOOSE and SMV messages), the same data set name (mostly configurable at the IED for GOOSE and SMV data sets), and the same configuration revision number (needs free setting by the tool creating the data set, or some tool support for the replacement).

This means that the replacing IED has beneath the requirements on compatible semantics and data types to fulfil some engineering related requirements, which are not mandatory according to IEC 61850. Further it should be considered that errors at the reconfiguration of the data set when keeping the old revision number and data set identification can be safety critical, because the receivers do not demand to be newly configured. So, a good tool support or testing in a simulated environment is recommended.

The problem of binding GOOSE or SMV receivers to the data set layout does not appear for reporting clients, because they can perform this binding dynamically. However, if the names have changed, the binding to the functional semantics, especially binding of LN instances to instances of switch yard equipment and functions, is still a problem. One means to solve this binding to the application function is to re-establishing the link between functional names and IED related names also for the new IED(s). This is supported in IEC 61850 better than in other protocols in so far, as this binding is done on the level of logical nodes instead of signals, and will in all cases, where application specific LNs are used (e.g. no GAPC and no GGIO), reduce to a selection of LN instances with the same LN class, thus minimizing the amount of work as well as that of errors.

For good implementations of station level clients, which internally work with the functional names as defined above, it is then sufficient to reload them at driver level with the SCD file resulting from this re-mapping of LN instances.

Even better client implementations allow to do this reload per IED e.g. when communication with the (new) IED is (re-) established. In any case, the probability of errors is restricted to the remapped IED, and this probability is quite low, because the remapping is performed on the relatively high level of LN instances, supported in most cases by the needed LN class. It should however be considered that the new IED should contain at least the same DATA per remapped LN instance as needed by the application.

Impact on engineering and used products

The following points are important to minimize the efforts in case of SA system retrofit:

• Use functional naming for system engineering and the IED related names, so that the SCD file provides a translation between them in a standardized format.
• Use functional naming at application level, i.e. within application functions. Let the (MMS based) communication drivers translate the IED names into functional names by means of SCD file(s). In case of (station level) clients which do not support this, use a tool to create the new configuration from the SCD file, by using the functional name as common key between old and new configuration.
  
  The safety of this approach can be supported by a system tool which supports the IED replacement at the functional structure on LN level, with a check of the same respective correct LN classes.
  
  

As we have seen, the replacement of GOOSE servers without having to reconfigure all GOOSE receivers needs some optional features from the IED respective its tool:

• Support free LD naming
• Support free data set naming, at least for GOOSE and SMV data sets
• Support free (guided) setting of GOOSE confRev

To make this procedure safer, the tool should support remapping the new IED to the functional names and, after this remapping, automatically (re-)create the GOOSE / SMV data sets with identical layout and name, set the LD name property identical and take over all 'old' addresses.

Unfortunately, all these features do not help for the GOOSE / SMV case, if a changed architecture leads to another logical device structure, so that the requirement on uniqueness of the LD name forbids the proposed LD renaming, or if due to a new physical structure the GOOSE messages have to be split onto different IEDs.

Some impact on system modeling principles

A relatively safe tool-supported binding of the LN instances of the new IED to the functional names by using the old IED's binding as template is only assured, if GGIO and GAPC LN classes are avoided as far as possible. This is also in the sense of IEC 61850, which demands using a fitting LN class wherever one is defined. Here also some improvements of manufacturer IED tools might help, which allow replacing a GGIO by a more appropriate LN class at IED (pre-) engineering time.

However, if the old structuring into logical devices does not fit to the new structuring, this does not help. Therefore, already at the initial system design, the logical device structure in relation to the used GOOSE and SMV messages should be set up to support the most distributed structure which is intended to be used during the switch yard life time. Further, GOOSE and SMV data sets should not reference data outside the LD in which they are defined - else these may later reside on different IEDs, and therefore force a redefinition of the data sets with appropriate re-engineering of the receivers.

The general concept of a maximal distributed system, even if it is implemented centrally, also helps in having a common behavior of distributed and central systems concerning functionally connected logical nodes, because it makes the functional behaviour independent from the fact if internal functional connections between the LN implementation are used or external explicit communication connections. This has also been considered at the more detailed definitions of IEC 61850 Edition 2 for the influence of the test and block quality of incoming signals, and should also be used when implementing test and block modes on internally connected logical nodes.

If these additional system structuring rules are considered, then the consequent usage of functional naming for application related functions in parallel to the usage of product related naming for automation system maintenance, as foreseen in IEC61850-6, supports easy retrofit and system extension with minimum engineering, modification and (re-) testing effort even if the underlying physical architecture is changed or IEDs of a different type or a different manufacturer are used.

Biography

Wolfgang Wimmer works for ABB Switzerland in Baden. He is principle engineer in the development of substation automation systems. He has a M. Sc. degree as well as a Ph.D. in Computer Science from the University of Hamburg. After some years developing Computer networks at the German Electron Synchroton DESY in Hamburg he changed to ABB (former BBC) for development of train control systems, later Network Control Systems. He has more than 20 years experience with development of substation automation systems. He is a member of IEC TC57 WG 19 and WG 10, and editor of IEC 61850-6.