Imyweb articles

I guess, many of you already heard about IEC 61850 and you may as well know a lot about the technical content and scope of IEC 61850. As a Convenor of the IEC working group that is responsible for the development and maintenance of IEC 61850, I will regularly address in this column topics related to IEC 61850 that are of interest for our readers.Topics that may be covered will include a large range. I will certainly highlight some important events related to IEC 61850. But it can as well be that I discuss a hot TISSUE. You don’t know what a TISSUE has to do with IEC 61850? So continue reading, I will explain below. If you have a specific topic you would like to hear about, you can send me an email and I may select that topic for one of my columns.
If you are familiar with IEC 61850, you may be impressed by the number of pages this standard consists of and you may wonder, how such a comprehensive specification is developed. In the Cover Story of this issue you will find more information about the history of IEC 61850. For those of you, which are not familiar with the standard and did not read the article, here are some brief explanations: IEC 61850 is an international standard with the title “Communication network and systems in substations”. It is a series of 14 parts dealing with different topics from communication services and communication protocol mappings, object models and configuration aspects to conformance testing.

The major parts of IEC 61850 have been published in 2002 / 2003. It is a total of more than 1000 pages. With the first implementations some inconsistencies and some ambiguities have been discovered. For these TISSUES (Technical ISSUES) have been created. The TISSUES are maintained in a database and they are the basis for preparing the second edition of the standard. Some of the TISSUES are as well important as a basis for conformance testing of products.

But there are other items that will go in the second and future editions. The concepts of IEC 61850 have been applied in other domains than substation automation. Object models are being developed for wind power plants, for hydro power plants and for distributed energy resources. While these new domain specific models will be individual parts of the standard, some basic new requirements will be incorporated in the basic documents. And with the expansion of the applications outside the substation, it was as well necessary to provide the standard with a new name. Although not yet finally decided, currently the favourite is “Communication network and systems for utility automation”.

Besides these new domains, we are currently also working on preparing reports on how to use IEC 61850 for communication between substations and for communication between substation and control centres or other system level applications. And in addition, a task force is working on preparing a technical specification for the mapping of IEC 61850 on IEC 60870-5-101/104 for a gateway.

Many of these issues are handled in the working group 10 (WG10) of the technical committee 57 (TC57) from IEC. WG10 has the basic responsibility to maintain IEC 61850. To achieve this work, WG10 is meeting typically three times a year as a whole working group and in addition, task forces and editor groups may have additional meetings. Members of the working group are from all over the world. The majority is from North America, Europe and Asia, but we have as well members from South Africa and South America.

While we are working on the future of IEC 61850, the current version is already in use in many projects around the world. The number of devices talking IEC 61850 that is put in service is increasing every week.

One of the key advantages of IEC 61850 based systems is the availability of the Substation Configuration Language that allows interoperability and a seamless integration process. The SCL is basically a system specification of the substation equipment connections in a single line diagram. It also documents the allocation of Logical Nodes to devices and equipment of the single line to define functionality, access point connections, and sub network access paths for all possible clients. And finally, it defines the instantiated data model of the different IEDs including optionally preconfigured values for configuration parameters.
What is of specific interest for protection and control applications is that it allows the development of engineering tools for configuration, protection coordination and testing that use a common standard data format.

SCL based configuration process

The overall functionality of any IEC 61850 compliant device is available in a file that describes its capabilities. This file has the extension “ICD” meaning IED Capability Description. The system specification tool supplies to the system configuration tool information such as the single line diagram of the substation and the required logical nodes. The file extension for this file is “SSD” meaning System Specification Description.
The system configuration tool then provides information to the IED configuration tools regarding all IEDs, communication configuration and substation description sections. This information is in a file with the “SCD” extension meaning Substation Configuration Description. This information also needs to be provided to the other tools in order to allow them to configure the set of functions to be performed.
The Standard IED configuration tool sends information to the IED upon its instantiation within a SAS project. The communication section of the file contains the current address of the IED. The substation section related to this IED may be present and then shall have name values assigned according to the project specific names. This file has an extension of “CID” meaning Configured IED Description. Currently there is ongoing work to expand the content of this file to include all settings, thus providing the required configuration data for both the IED itself, and also for the different functional tools
IEC 61850 is the new communications standard that allows the development of a new range of protection and control applications that result in significant benefits compared to conventional hard wired solutions.
It supports interoperability between protective relays and control devices from different manufacturers in the substation which is a necessity in order to achieve substation level interlocking, protection and control functions and improve the efficiency of microprocessor based relays applications.
The modeling of IEC 61850 based multifunctional distance protective relays requires good understanding of their functional hierarchy, as well as the modeling principles defined in the standard.
Complex devices, such as transmission line protection relays are modeled as servers with multiple Logical Devices that correspond to typical substation functions, such as Protection, Measurements and Recording.
The model needs to properly represent the functional hierarchy of the protection relay and at the same time use the available model hierarchy defined in the standard.
High speed peer-to-peer communications between IEDs connected to the substation LAN based on exchange of GSE messages can successfully be used to replace hard-wiring for different protection and control applications such as the protection of distribution buses, distributed recording or load-shedding in substations with varying configuration.
Sampled Measured Values communicated from Merging Units to different protection and control devices connected to the substation Process bus replace the copper wiring between the instrument transformers in the substation yard and the IEDs.
Such systems provide some significant advantages over conventional protection and control systems used to perform the same functions in the substations:

Reduced wiring, installation, maintenance and commissioning costs
Easy adaptation to changing bus configuration in the substation
The Substation Configuration Language allows interoperability and a seamless integration process. The common substation or IED configuration files can be exchanged between different configuration, coordination, analysis or testing tools in a way that significantly improves the efficiency of the engineering process.

The foundation of the IEC 61850 is the concept of virtualization, i.e. providing a virtual representation of the behavior of real primary or secondary substation devices.
As mentioned earlier, the virtualization covers only the relevant and communications visible components of the model. The figure below shows the use of this process to model an overcurrent stage of a protection relay from any vendor as an IEC 61850 logical node.

Virtualization of protection relays

The modeling approach in the standard uses the principles of functional decomposition and UML notation. It is used to understand the logical relationships between components of a distributed function and is presented in terms of the model hierarchy that describes the functions, sub-functions and functional interfaces.

The data flow is used to understand the communication interfaces that must support the exchange of information between the distributed functional components for different applications. The information modeling on the other hand is used to define the abstract syntax and semantics of the information exchanged. It is presented in terms of the data object hierarchy that includes data object classes, types and attributes.
A very important differentiating factor of IEC 61850 compared to other communication protocols is that everything in this model has a name. This allows the definition of standard device models that support self-description and use of meta-data to be used for development of different engineering tools.
The models of multifunctional protection IEDs that include both protection and non-protection functions such as control, measurements, monitoring and recording are discussed. Two basic modeling approaches are possible:

Single Logical Device based model
Multiple Logical Devices based model
The modeling of a complex multifunctional protection IED such as a modern distance relay is possible only when there is good understanding of the problem domain. At the same time we should keep in mind that the models apply only to the communications visible aspects of the IED.
The functions in relatively simple IED, such as a low-end distribution feeder or transmission line protection relays, are fairly easy to understand and group together in order to build the object model. That is not the case for the more complex devices like a distance protection. The distance protection function has different components that need to be taken into consideration in the model. Complex to represent are also advanced transmission line protection schemes that typically exist in distance relays, as well as distributed functions based on high-speed peer-to-peer communications between multiple IEDs.
IEC 61850 defines not only the object models of IEDs and functions in a substation automation system, but also the communications between the components of the system and the different system requirements. It is very important to understand that the fact that one can model a function in a device or substation automation system does not mean that the standard attempts to standardize the functions. This is especially true for the distance elements. There are so many different algorithms and characteristics, as well as preferences and opinions, that this will be an extremely difficult task. Instead, the model represents the communications visible attributes and behavior of the device. This is one of the main reasons that there is a difference in the modeling requirements between IEC 61850 configuration applications and analysis or testing tools.
It is important to also remember that the changing technology introduces new methods for interface between the instrument transformers or sensors in the substation and the distance or other protection relays. They need to be able to interface with conventional and non-conventional sensors in order to allow the implementation of the system in different substation environments.
A simplified diagram with the communications architecture of an IEC 61850 Process Bus based substation automation system is shown below.

Simplified IEC 61850 based communications architecture

The Merging Unit (MU) multicasts sets of measured sampled values to multiple IEDs in the substation over the substation local area network. In some cases it is called the “process bus”. Status information for breakers and switches is available through an input/output unit (I/O). In some cases the merging unit and the input/output unit can be combined in a single device.
The receiving devices then process the data, make decisions and take action based on their functionality. The action of protection and control devices in this case will be to operate their relay outputs or to send a high-speed peer-to-peer communications message to other IEDs in order to trip a breaker or initiate some other control function, such as breaker failure protection, reclosing, etc..
The modeling of complex multifunctional IEDs from different vendors that are also part of distributed functions requires the definition of basic elements that can function by themselves or communicate with each other. These communications can be between the elements within the same physical device or in the case of distributed functions (such as substation protection schemes) between multiple devices over the substation local area network. The basic functional elements defined in IEC 61850 are the Logical Nodes.
A Logical Node is “the smallest part of a function that exchanges data”. It is an object that is defined by its data and methods. When instantiated, it becomes a Logical Node Object. Multiple instances of different logical nodes become components of different protection, control, monitoring and other functions in a substation automation system. They are used to represents individual zones or steps in a protection function.
A multifunctional protection IED has a complex functional hierarchy that needs to be modeled according to the definitions of the IEC 61850 model. It has two main groups of functions - protection and non-protection. The protection functions can be further divided into main protection functions, backup protection functions and protection related functions.
Each device sub-function then can be split in functional elements. Functional elements can be defined as the smallest functional unit that can exist by itself and also can exchange signals or information with other elements within a device or a system.
The modeling of complex protection devices depends not only on their functionality, but also on the configuration of the substation where they are installed. The model will be different if the transmission line is connected to a bus with a single breaker compared to the case of a breaker-and-a-half or ring bus.
The modeling of multifunctional devices needs to reflect the functional and modeling hierarchy described earlier.

Distance protection relay - simplified object model

According to the names of the different parts of IEC 61850 it is a standard for communication networks and systems in substations. It was developed with the goal of meeting the requirements of all different functions and applications in the substation, such as:Protection
Control
Automation
Measurements
Monitoring
Recording
At the same time it should support different tasks related to the above listed substation functions, such as:

Engineering
Operations
Commissioning
Testing
Maintenance
Event analysis
Security
IEC 61850 was developed over a period of about 10 years and was the result of the combined efforts of numerous industry experts from around the world. Initially there were two separate activities:

The development of GOMSFE (Generic Object Models for Substation and Feeder Equipment) as part of UCA (the Utilities Communications Architecture)
The IEC 61850 project for development of a standard substation communications protocol under Technical Committee 57
The mix of professionals involved in the development included utility and manufacturer representatives, consultants and software developers. Many of them with a lot of experience and strong beliefs in their own opinions. So if you can imagine a group of such people in a room discussing a subject with high level of importance, it will be easy to compare it to multiple collisions over the shared media of the meeting room.

That is why Fred (the frog beanie-baby) played such an important role in the development of IEC 61850. When we realized that collisions are slowing down the development, we at least agreed to change to a token-passing communications method. And Fred was the token. So only the person that held the token could speak. Everybody else had to shut up. Without Fred probably we will still be arguing some issue in a meeting room somewhere around the world.

Fred

The good thing about heated discussions is that they create an atmosphere for great ideas. For example in a small room at O’Hare airport discussions gave birth to the UCA GOMSFE “bricks” - the building blocks of the device object models that can help us model even the most complex IED. And the concept of the high-speed peer-to-peer communications represented by another acronym - the GOOSE (Generic Object Oriented Substation Event).
One of the great accomplishments of the development process was that all involved companies were not just talking about the development of a standard for substation communications, but were actually building devices to see if it works. We can say that probably this is the best example of a successful multi-vendor project that the electric utility industry knows. And to make sure that it really works, a couple of times a year we had the interoperability demonstrations, with the main goal of each participant to win the great prize - Lucy - Goosy (another beanie-baby) given to a vendor that has demonstrate exchange of GOOSE messages with another vendor’s IED - verified by the present utility engineers, and to utilities implementing GOOSE messaging in their substations.

Lucy

The situation was not very different on the other side of the Atlantic. In 1995, new work item to develop an international standard for substation communication protocol was accepted by the IEC TC57 plenary meeting in Minneapolis, USA. Already at the second meeting in San Francisco, first contacts with the UCA efforts were initiated. However, at that time, the technical background of the experts involved was too different. The UCA experts with a strong background in TCP/IP based communication had little common vocabulary to share with the relay engineers and the experts for telecontrol protocols. So it was almost impossible to have real discussions.
So for the next two years, the three IEC working groups responsible for the development of IEC 61850 continued more or less independent from the UCA activities. Quite remarkable that they developed independent from the UCA activities the concept of the logical nodes, which is basically equivalent to the UCA GOMSFE “bricks”. The discussions in three working groups with a total of more than 70 experts were sometimes challenging. We realized soon, that the three working groups could not act independently. However, since you can not produce creative work with 70 experts, task forces were created. So each meeting was a mix of parallel working group meetings and task force meetings. While we started with two or three day meetings, we soon ended with having full week meetings in order to get the optimum out of a meeting.
In 1997 a conclusion was reached that due to the similarities of both activities it would be beneficial to the industry to have a single standard for substation communications and the members of the UCA working group were integrated in the IEC TC 57 working groups.
So the standard was completed with the efforts of three working groups:

Working group 10 focused on the definition of the functional architecture and general requirements
Working group 11 addressed the communications within and between Unit and Station levels that are now know as the Station Bus
Working group 12 developed the communications within and between Process and Unit levels known as Process Bus
After the publication of the standard and its wide spread application in hundreds of substations the UCA International Users Group is working on resolving the different technical issues. WG11 and WG12 have been integrated into WG10, so WG10 has now the full responsibility for IEC 61850. The solutions and new developments, such as the modeling of power quality monitoring functions addressed by WG 10 will be included in amendments and later in version 2 of the standard.
IEC 61850 was developed on the basis of some key requirements:

It should be technology independent
It should be flexible
It should be expandable
By meeting the above requirements the standard allows us to meet the changing needs of the electric power industry and take advantage of the developments in computers, communications and sensors technology.
The IEC 61850 standard consists of fourteen different documents that cover a wide range of issues and make it clear that it is much more than a communications protocol definition. It defines not only how to communicate over the substation local area network, but also what to communicate. It provides an abstract model of the substation equipment and functions that can be used as the foundation of the development of different tools.
The standard also addresses the substation integration and automation engineering process and specifies the conformance testing for intelligent electronic devices (IEDs) that support it.
It needs to be well understood that the IEC 61850 standard does not specify individual implementations, communication architectures or products. It also does not attempt to describe any details of the functionality of the different devices, such as algorithms, but focuses only on the specification of the externally visible functionality of primary or secondary equipment, functions or implementations in substation protection, control and automation systems.

IEC 61850 is an approved international standard for communications in substations that is creating opportunities for a revolution in the world of electric power systems protection and control. It represents the next step in integration of multifunctional IEDs based on the development and implementation of advanced distributed protection and control functions. But for this revolution to succeed, we need to understand what it is and how we can use it in order to take full advantage of its potential. That is why IEC 61850 and its applications are and will be one of the key topics for discussions in our industry in the future.When we plunge into the IEC 61850, we enter a world of numerous MLAs. Probably you never heard of MLAs - well this is nothing but a Multi-Letter Acronym. And you are going to see TLAs and FLAs (you have to figure these out). Coming up with these was one of the primary tasks in the development of the standard (actually this is a joke).
The reason we are starting by talking about acronyms is because their use can be very dangerous. If we look at a very typical use case - you need to take a new relay to a remote substation. So you put it in your carry-on bag and you go to the airport, check-in and get in line to go through security. Almost every time, someone will ask you what is this thing in your bag. The natural to a protection engineer answer will be to say that it is an IED (we all know that in our domain this means Intelligent Electronic Device). Well, in our use case situation this is definitely the wrong answer, since in the world of security the same three letter acronym (or TLA) means Improvised Explosive Device. So the moral of this story is - be careful and use an MLA only within the domain that you understand.
We hope that you are starting to realize that the standard was developed by some “out-of-the-box” individuals that were trying to transform the world of hard wired electromechanical relays into a world of virtual devices communicating over substation local area networks. When this all started many were saying that this is impossible. They were wrong. We just need to look around to see where the world is going.
So let’s try to get more serious and see why and how we got to where we are and where we are going. IEDs are the standard in new or upgraded integrated substation protection, monitoring and control systems. Protective IEDs are sophisticated multifunctional devices designed to protect substation equipment and the electric power system from the effects of different abnormal system conditions. Since fault conditions are very rare in the system, to take advantage of their data acquisition and processing capabilities they also include multiple non-protection functions like metering, disturbance and event recording and some built in fault analysis tools. This makes them the typical device at the process level of a substation automation system.
Specialized control, power quality monitoring and disturbance recording devices may complement the protection IEDs by providing some specific functionality that may not be available within the relays. This allows the optimization of the integrated substation automation system, while at the same time meets the strict requirements for reliability and security.
The selection of the communications protocol used at the substation level is one of the critical factors to consider in the design of the substation automation system. The protocol should provide all required services that will allow the optimal implementation of different substation functions. This requires:

Proper definition of the functional and performance requirements
Good understanding of the substation communications protocol
That is why we need to discuss IEC 61850 and its applications, as well as the challenges, benefits and opportunities for future developments.

An excellent group of TVA and vendor personnel made this Bradley project a success. Jim Kurtz, Manager of Protection and Control at TVA, had the following comments on the project: “I cannot stress how important collaboration like this is to the industry. For vendors and suppliers to work together to resolve issues will help not only them to provide a better product, but also to develop products that will meet the long term needs of the industry. While this effort has leaped TVA forward in technology, we still have work to complete.”The IEC 61850 substation communication standard is almost two years old. Worldwide, there are already over one hundred substations that have been commissioned and running with this new standard.

Several projects in North America have been implemented with IEC61850 by using products from a single manufacturer. This article reports on the status of a 500KV project - the first multi-vendor project in the United States to use this new standard.

The goal of the project is to utilize the new IEC61850 standard to its fullest (as practically possible) therefore confirming that the standard is much more than just a communication protocol. Interoperability, one of the major advantages of IEC61850, will be demonstrated. Our focus is not to describe or explain the theoretical background of the standard itself, but rather to show and demonstrate the practical use of an actual multi-vendor project and how the standard applies to protection engineers.

Substation Design & Layout
Another goal of this project is to eliminate or significantly reduce wiring between the relays, the control house and the breakers. The wires are replaced with the communication infrastructure fulfilling the requirements of the protection and control applications by exchanging IEC61850 GOOSE messages over Ethernet.

Protection & Control Scheme
Redundant protection, a TVA core protection requirement, is applied on all 500kV and 161kV transmission lines breakers and three single-phase 500/161/13kV power transformers within substation.

Transformer Protection
Two complete, comprehensive and independent transformer protection systems are implemented. Set “A” protection provides transformer differential protection, overcurrent protection, transformer sudden pressure protection, hot spot protection, LTC sudden pressure protection and restricted ground fault (RGF) protection for both neutral CT’s. Every transformer status and alarms, such as fan status, liquid levels, etc. are collected by the devices, which are located in cabinets mounted on each of the four single-phase 500/161/13kV transformers. Analog and digital data from the IEDs are available in IEC61850 format to the substation automation system.

Line Protection
Line protection relays provide distance/pilot protection, directional ground overcurrent, synchrocheck, breaker failure and reclosing. Additional pilot tele-protection devices are used for the Sequoyah 500 kV line (individual POTT schemes for both line protection relays) and the Conasauga 500 kV line (individual unblocking schemes for both line protection relays). Both line protection systems on each of the 161 kV lines will share a single communications device for their POTT schemes. Each line relay is operating in a breaker & ½ topology. (Fig. 2, Fig. 3)

Breaker Control
The substation contains redundant breaker control devices. The idea behind dual breaker control IEDs is to meet the same redundancy requirement as for line protection. The breaker control IED within the substation yard sends information to and receives information from the line relays using IEC61850 GOOSE messaging. (Fig. 4)

The only hardwire status input to each line relay is the breaker position statuses and this is only used if a digital IEC61850 state from either 52BCA or 52BCB devices are not available. A hardwire trip output from the line IED is wired directly to the breaker 1 and breaker 2 trip coils (for risk management purposes). With experience, future designs may provide the substation engineer the option to eliminate these hardwire inputs and outputs and to strictly use the GOOSE functionality.

Network Connections
All IEC61850 IEDs are connected via 100 MBps multi-mode fiber cables to substation hardened Ethernet switches located in the control house. VLANs are used within the IEC61850 GOOSE message configuration of each IEC61850 device to provide security within the network. Figure 9 shows a conceptual layout of the network.

Customer /Project Expectations
Since one of the goals of this multi-vendor project was to utilize the new IEC61850 standard to its fullest, it is clear that the customer had some key project expectations:

Open system for protection, control and data collection from any IED.
Interoperability between IEDs for protection and control functions. Ability to configure IEC61850 system with available manufacturer tools without need for on-site manufacturer support.
Comparable functionality with streamlined design. Eliminate panel control switches and lockout relays and incorporate functionality into IEC61850 IEDs. This dramatically reduces the panel layout design and allows for a smaller control house (about ½ the size vs. traditional design). For example, consider that just one set of protection, up to 12 breakers, can be protected and controlled using one single 19″ wide panel versus older designs with 1 breaker per panel with both Set A and Set B protection systems. Standard panel designs for any application can be created.
Accommodate multiple vendor IEDs
Comparable performance time
Secure & dependable overall system. Timely, secure flexible information transfers.
Flexible management/ operation
Economically viable solution
Common technology infrastructure
Reusable practices. Project established foundation of new substation practices oriented around IEC61850 and new procedures. Business case can be made for wholesale refurbishment with these new practices.
Effective data management system
Reduced wiring and installation costs. Besides the CT and PT wiring from switchyard breakers and motor operated disconnects, only breaker status and breaker trip wiring has been implemented. No inter-wiring exists between any of the IEC61850 IEDs.
High-speed local and remote downloads to IEDs over network
Improved Operations and Maintenance from remote and local monitoring and diagnostics via network to reduce service time
System health/status monitoring
Status communications between IEDs
Testing methodology. New test plan, tools and methodology needed to match systems new capabilities and plan to implement test cases. Ability to individually test any IED without the concern of operating other IEDs via the network.
On-Site LAB Workout Sessions & Configuration Tools Used
In August 2005, the TVA IEC61850 “project team” met for the first time (Fig. 6) to begin the process of designing the first IEC61850 based high voltage substation in the US. The team consisted of four major relay vendors and representatives from TVA’s relay and communication engineering departments. Besides all interoperability demonstrations organized previously by the UCA International Users Group or by CIGRE, the team’s objective for this project was to show that each relay vendor can demonstrate interoperability of the protection and automation devices from design to implementation in real life.

During the IEC61850 integration process the four relay vendors participated in three primary tests at the TVA “test lab” substation. The goal was to demonstrate that TVA could take the primary lead of configuring their substation with the available IEC61850 configuration tools using the manufacturers in a support role. This would be the first IEC61850 project where the customer would do the system engineering and IED integration. The integration during previous interoperability tests on other projects throughout the world had been implemented by members of the relay vendor’s development department using tools and programming language that were not always accessible or available for use by the customer. All participating vendors had previous experience with commissioning several IEC61850 based substation worldwide, but in almost all cases one of the vendors was the integrator and mainly used their own products, engineering tools and integration procedure to configure a substation. The integration of these previous projects was simpler because interpretation of the IEC61850 standard was uniquely confined to that vendor’s system architecture and product implementation. It is also important to note that trade show interoperability testing only covers a small portion of the functionality required for a complete substation solution. So, the TVA project in this respect was completely different from previous projects and the trade show interoperability tests. TVA was the system designer and system integrator and they would use the available tools from each vendor while at the same time deal with the unique interpretations of the new IEC61850 standard by each vendor.

Configuration Tools, ICD and SCD Files

The primary goal during the first test meeting (August 2005) of the “project team” was to configure all GOOSE links between the relays from the different manufacturers and to reach a minimal level of device interoperability. The procedure to achieve this is shown in Figure 1. All manufacturers had to supply an ICD file (IED Capability Description) that described the ability of the relays in a standard IEC61850 format. This ICD file is the interface between the relay manufacturers IEC61850 tools and the IEC61850 world. With the ICD files available, the customer can use any independent IEC61850 System Configuration tool to import the ICD files from each relay vendor and configure the system. (Fig. 7) Once the IEC61850 station is configured, a SCD file (Substation Configuration Description) can be created and exported describing the station in a standard IEC61850 format. The relay vendors must be able to use their proprietary tools to extract the information inside the SCD file and use it to configure the individual relays. TVA decided to use the only commercially available at the time IEC61850 station configuration tool with all the required functionality.

Lessons Learned & Testing Tools Used
During the first test meeting a significant amount of discussion was centered around the question of whether TVA wanted to use the GOOSE message implemented in UCA - called GSSE in IEC61850 to provide compatibility with UCA 2.0 implemented substations, or to use the real IEC61850 GOOSE message. After evaluation of all pros and cons, the decision was made to use the IEC61850 GOOSE message because of the advantages this new implementation has to offer.
Some discussions made it apparent that all relay vendors did not fully understand the power of the new standard. For example, it was thought that it was necessary to manually configure which information in a GOOSE message was to be sent first, the data information or the quality information. It was discovered that different manufacturers and, sometimes, different relays from the same manufacturer did it differently, so there was a fear that the information may get misinterpreted.

After a lot of discussions and phone calls, the team determined that the order of the information and quality data did not matter as long as it was declared in the ICD file. The receiving relay will get the information because it is defined via the SCD file and it knows how to process the information correctly.
During that meeting most relay vendors also did not have their tools ready to automatically export and import from their proprietary programming tools to the IEC61850 world via ICD and SCD files. This resulted in a significant amount of manual programming work. To validate the correctness of the ICD file, the team used the System Configurator as well as the IEC61850 Validator tool. It was determined initially that some of the ICD files had some format errors and during the import of the files, an IEC61850 Validator tool produced error reports.
These errors were the first hurdle that had to be resolved.
Even though the validation of the ICD files could verify the correct syntax of the file, it could not check for the semantics. Once we were able to import the ICD files and use the System Configurator tool to configure the required system, in some cases, we were not able to receive the programmed GOOSE message because the GOOSE message description was different than what was actually described in the ICD file. To analyze problems where one relay vendor claimed that they were sending a GOOSE message that the receiving vendor did not receive, the team used the network protocol analyzer tool Ethereal® with the MMS decoder functionality. Ethereal® allowed for the entire GOOSE structure to be displayed, so that a view of the specific relay IED including the value of the data and quality information could be analyzed.
By using Ethereal®, we were able to see where adjustments were necessary and finally all GOOSE messages were sent and received correctly between IEDs of the different manufacturers. The goal for the test week was achieved and the concept of IEC61850 was proven powerful. Even with this accomplished, configuration of the TVA system was not simple. However, the tools available would allow the customer to configure the system by themselves. During the design process, there were several firmware updates, patches and discussions between the development departments of each of the relay manufacturers. Without the great teamwork between all the manufacturers and the deep knowledge of the implementation details of IEC 61850, the interoperability goal could not have been achieved. But it was clear that this was not a practical procedure that a utility could use to configure their IEC 61850 substations.
The second test week was conducted in January 2006. The goal was to have TVA be the system designer/ integrator and configure the system with as little as possible support from the relay manufacturers. We have to admit that this goal was not achieved, because some of the manufacturers’ tools were still not mature enough. A lot of manual work was still required and detailed knowledge of IEC 61850 was also necessary in order for the correct ICD files to be extracted out of the SCD file for configuring each IED. With support of the relay manufacturers, the system was successfully configured and working at the end of the week, but the actual goal was not achieved. At the end of the meeting TVA requested that each relay vendor finish their tools, so that they can have the capability of configuring an IEC61850 system independent of the relay manufacturers.
All manufacturers met again in the TVA “test lab” substation in the third test week (March 2006). Focus was now on the tools of the manufacturers and if they were able to support TVA in configuring their IEC 61850 substation without any major support from the relay vendors and a need to have deep knowledge of the IEC 61850 implementation details.
The tools from ABB, GE Multilin and Siemens were found mature enough to fulfill the customer requirements. However, a new problem was discovered regarding different tools supporting different optional features of the IEC 61850 standard. For example, some IEDs need to know some hierarchical data like “voltage level”, “feeder name” in each IED. This data can be submitted to the IEC 61850 system configurator via the SSD files (System Specification Description). This file format is optional in IEC 61850 and doesn’t have to be implemented. The used system configurator in this case did not support this feature at this time. This made it necessary that after the SCD file was created by the system configurator that the file was edited by another tool to add this hierarchical data and then re-imported in the system configurator.
At the end, TVA was able to develop a procedure that allowed them to configure and design the system independently, without on-site support from the different relay manufacturers. This was demonstrated by TVA during the preparation for the May 2006 IEEE T&D show in Dallas, TX where the Bradley project configuration proved interoperability in the UCA International Users Group IEC 61850 demonstration.
TVA built the demonstration panels and configured the system that was placed on display at the show using the IEC 61850 tools provided by each vendor.
Overall, the process involved a number of hurdles, but demonstrated that by having a strong and determined team of relay manufacturers and excellent group of TVA engineers, future IEC 61850 project implementations can be successful and economically advantageous.

Lessons Learned Throughout the Project
This project was a tremendous learning experience for the participating vendors and TVA. In addition to those described in the on-site lab workout, the following are some of the additional lessons learned throughout the project.

VLAN issue with Ethernet switch - The Virtual LAN (VLAN), an advanced layer 2 function defined in IEEE 802.1Q, provides high priority tagging of a message and efficient means for data exchange in applications using the IEC61850 station bus and process bus profiles. In the IEC61850 standard, a VLAN tag was defined as part of a valid GOOSE message. Some vendors’ IED implementation required the VLAN tag in a received GOOSE messages to validate the information. The Ethernet switches used in the Bradley project initially did not pass the VLAN priority tag through the switch. This issue was identified early in the project and a firmware update was provided for the Ethernet switches.

Logical device names - Logical Device (LD) naming syntax is defined in IEC 61850 part 7-2. The logical device names in this system were to be named according to the customer’s standard practice for devices associated with breakers. The “99A” and “99B” breaker identification labels were preferred since this was TVA’s standard for naming multifunction microprocessor based relays. The naming syntax restrictions defined in the IEC 61850 standard does not allow these type of LD names (those starting with a number) due to constraints in MMS (Manufacturing Message Specification).
The solution for this issue was to name the breaker IEDs (Logical Device names) “LA99A” and “LA99B” respectively.

GOOSE ID naming - GOOSE ID naming is an attribute that is contained in the GOOSE message. One IED vendor uses this GOOSE attribute to display status of received GOOSE messages. In the Bradley project’s system engineering tool, the GOOSE ID was automatically assigned as a number, although the standard is not restrictive to numbers and allows strings.
The issue on utilization of IEC 61850 data is that one vendor usage or extension of the data may not be possible with another vendor’s implementation.
The GOOSE ID strings in the SCD file were renamed using a separate tool capable of manual modification of GOOSE ID names.

Status vs. quality order - It was thought that it was necessary to specify which information in a GOOSE message was to be sent first, the data information or the quality information. It was discovered that different manufacturers and sometimes different relays from the same manufacturer did it differently, so there was a fear that the information may get misinterpreted. After a lot of discussions and phone calls, the team determined that the order of the information and quality data did not matter, as long as it is declared in the ICD file. The receiving relay will get the information because it is defined via the SCD file and it knows how to process the information correctly.

The effect of the quality state on the status state - Conventional hard wiring states are either on or off without an indication of signal quality. The IEC 61850 standard does not provide rules for the interaction between quality and status bits. The question posed is should the loss of the quality state effect the state of the status value, thus a quality state of 0 results in a force of status state of 0 (even if the status is actually true or 1)? Or should a quality state of 0 result in staying at the last known status state (which is 1 in this example)?

Both vendors meet standard, but do not interoperate - Device (IED) conformance to the standard is accomplished by validating an IED at an accredited IEC 61850 test facility in accordance to the IEC 61850 Part 10 and the UCA International test procedures. It is important to note that the conformance testing does not validate conformity but only validates the IED testing has identified no “non-conformities”. An IEC 61850 device certificate is then issued by the accredited test facility providing the vendor a statement that no non-conformities were identified during the IED testing. The testing is limited to a single device in a test system and does not cover multi-device system level testing or interoperability in a multi-vendor system, i.e. the IEC 61850 certificate does not guarantee that a certified device will interoperate with another device. Device and client interoperability has been left to the vendors to validate. In the Bradley project, all vendors had IEC 61850 certified IEDs, but several issues as previously mentioned resulted from wrong interpretation or ambiguity in the IEC 61850 standard. Below are some examples of issues encountered during the Bradley project that impacted GOOSE interoperability between different vendor devices:

Supporting optional attributes in GOOSE - One example of the interoperability issues encountered was that one vendor could include both mandatory and optional attributes in the IED using GOOSE messaging. Then another vendor’s IED (GOOSE receiver) could only understand mandatory attributes and was not able to support the optional attributes; thus preventing interoperability. The resolution was to not use the vendor specific attributes in the GOOSE communication between these IEDs.

Adherence to name case sensitivity - Another issue encountered was in the adherence lower and upper case sensitivity. One vendor was more liberal and did not strictly adhere to the case sensitivity as defined in the standard. The other vendor’s engineering tool was rejecting the names when the case was opposite to that as defined in the IEC61850 Part 7. This was resolved by using a newer version of the SCL XML schema.

Quality in GOOSE versus no quality - The support of data item quality flags in GOOSE datasets was a major obstacle in the beginning of the Bradley project. Different vendors provided different levels of support for quality flag data. In this case, one vendor required quality information in their application to confirm validity of the data for each value received via GOOSE. At the same time, another vendor was not able to send quality information in the GOOSE message. This resulted in the inability to exchange GOOSE message between IEDs and thus, a major interoperability issue. It was decided to use both status and quality within the Bradley project for consistency. Both quality and status are now available in each vendor’s device and successful GOOSE interoperability between multiple vendors has been accomplished.

Length of names of GOOSE Control Blocks - The length of GOOSE control block names supported in the different vendor IEDs was an issue. The Bradley project’s system engineering tool automatically generates names for DataSets and GOOSE Control Blocks. The string length of these automatically generated names was too long for one vendor’s IED. The GOOSE Control blocks in the SCD file were renamed using a separate tool capable of manually modifying the GOOSE control block names.

Substation section - The substation section of a SCL file contains information about the substation layout, logical node references and device configuration and association information. One vendor’s IED tool required this substation section along with the Logical Node references to be imported from SCD file generated by the system engineering tool. The system engineering tool was not able to produce the needed information so manual manipulation of the SCD files was required to complete the IED engineering. The resolution was manual configuration of the SCD file adding the necessary information.

What vendors have to improve to make it easier? - Better preparation of the product and system technology is needed. IEC 61850 is a very comprehensive and complex standard that has the potential to revolutionize substation automation systems if the necessary tools and product functionality is available. The vendors involved in this project needed to collaborate to assure that the substation automation system functionality and interoperability capabilities were validated prior to the execution of the customer engineering and system build up.

What could have been done differently? - Clearly, the lessons learned in the multi-vendor TVA Bradley IEC 61850 substation project have been extremely valuable for the entire industry pushing for this new standard. The extent of the Bradley project provides complete functionality, with a goal to move into the digital substation.We can state that the Bradley project has explored all benefits made possible through the new standard that prior to this project has not been done in a multi-vendor environment. Most of the executed IEC 61850 projects have been turnkey homogenous vendor solutions where interoperability between one vendor’s products is much easier. In the other projects where multi-vendor projects have been executed, the foreign device has typically been a main 2 or backup protection terminal where the system functionality only required limited exposure of the IED functionality via the IEC 61850 system. On the other hand, industry expositions demonstrating multi-vendor IEC 61850 interoperability have set expectations that the complete IEC 61850 benefits are readily available. This is not the case since these demonstrations focus on simplistic applications and minimal functionality to prove vendor A can interoperate with vendor B.

What could have been done in this project is to set up an interoperability project to validate product and system functionality before starting the Bradley project. In this case, the project was conducting the interoperability validation. System engineering is the critical step in the Bradley project where an open discussion regarding system engineering tool to know the limitation in the integration of other vendor’s IEDs. The system engineering process is one area that multi-vendor exchange of IED and engineering data needs improvements. Today, a vendor’s system engineering tool works perfectly with their own devices but creates limitation when exposed to other vendor’s devices.

What needs to be done in the industry is a higher level of interoperability functionality and standard test cases that can assure a minimum level of interoperability. Here the recommendation is that the UCA International Users Group set up performance and functionality criteria for levels of interoperability. Device level conformance certification only validates a fraction of the overall substation automation capability. Figure 8 shows the final design deployed for the TVA Bradley Substation.

The industry should consider Ethernet switches as “protective devices” when it comes to implementations of critical protection schemes using IEC61850 standard and whether they are configured and maintained by protection/test engineer or IT department.