Protection History

Authors: Walter Schossig, Germany, and Thomas Schossig, OMICRON electronics GmbH, Austria

the Way to IEC 61850

In the last issue the history of interfaces for protection and control was covered. It finished with the the IEC 60870-5-103 standard, which was serial communication with 9600 or 19200 Baud. This article covers the introduction of Ethernet into the substation, resulting in the famous IEC 61850 series. We are aware that this is a huge task to describe this development. A lot of the people involved are still active in the industry. The article is based on material collected, and interviews with the experts. If we forgot something please let us know to be considered in the second part or a later issue. Thank you for your understanding, dear reader.

IEC 61850 was not starting from scratch. There are several predecessors to be considered here. So the story will start with the history of MMS and the early activities of UCA and EPRI. When young people in the early 2000s heard “MMS” they understood “Multimedia Messaging Service”, a standard for telephone messaging systems. But there is also a networking standard called MMS what means “Manufacturing Message Specification”. This MMS is an international standard (ISO 9506) dealing with messaging system for transferring real time process data and supervisory control information between networked devices and/or computer applications. The standard is developed and maintained by the ISO Technical Committee 184 (TC184).
MMS grew out of a need for a real-time messaging system that was generic enough to accommodate applications in discrete part and continuous process manufacturing. Existing protocols were mostly proprietary (Modbus was still proprietary in these days) and were very primitive. While the vendors were hesitant to add much complexity to their products, users wanted a better way to access data than just register numbers.

Manufacturing systems were becoming increasingly reliant on computer based automation and the users were dealing with the complexity of getting 100s of programmable logic controllers to coordinate their control actions over a network using register and bit numbers for communications. The evolution towards Computer Integrated Manufacturing (see Figure 1) had to be considered, ensuring that common standards are adopted by both vendors and users. As part of the Manufacturing Automation Protocol (MAP) Initiative (which, regrettably, also pushed the development of the 7-layer ISO/OSI protocol stack) GM and a few of their suppliers sat down and came up with a protocol called the Manufacturing Message Format Specification (MMFS which was called “Memphis”). It had services like Read and Write, Start and Stop, etc. But surprise, surprise: every vendor implemented MMFS a little bit different.

And it did not have a good way of handling complex data which users, especially in the process industries, desperately wanted (so they could model things like the data associated with a PID loop controller). Interoperability was difficult to achieve with MMFS.
The group realized that they needed to broaden participation in the standard and take a different approach that used a concept called “abstract modeling” to not only define the bytes used on the wire but also the behavioral aspects of how the protocol should actually be used in a device.
So the effort was moved into the ISO and the development of Manufacturing Message Specification proceeded in 2 parts: A service specification (part 1) that defined the services in an abstract way and a protocol specification (part 2) the defined how to encode MMS into a packet using the Abstract Syntax Notation Number 1. The MAP people got impatient with the progress so they release an updated MAP spec (V2.1) that referenced the Draft international standard version of MMS in 1985. MAP V3.0 was released in 1988 referencing the IS version of MMS. MAP V3.1 was released in 1991 and referenced MMS over Ethernet in addition to Token Bus. (Figures 1, 2 and 4).

SISCO (with Ralph Mackiewicz and Herb Falk) introduced the first MMS product in 1986. It was designed to run over an intelligent network controller card manufactured by Concord Communications that implemented IEEE 802.4 broadband technology. These cards had a full implementation of a 7-layer OSI stack but didn’t have any drivers for Operating Systems (primarily MS-DOS and later Win3.1 and OS/2).  It ended up porting MMS and drivers over a handful of boards from Concord, Computrol (later AEG), and Motorola.
So it was time for an OSI demonstration, or better an exposition of product interconnected and working seamlessly and, most importantly, available for sale. The Enterprise Networking Event (ENE) scheduled for June 5-9 1988 in Baltimore, Maryland, was to be the final coming out party for OSI networking. So this event was also the first public demonstration of MMS/MAP technology - the ENE88i event organized by the Society of Manufacturing Engineers (SME). 100 companies claiming they could do OSI and MAP (and TOP…the Ethernet version of MAP) although there were probably only 10 or so companies that could actually make this stuff work.

In 1989, SISCO introduced an MMS driver product for Lotus 1-2-3 spreadsheets that allowed data collection from PLCs using the Lotus @Factory add-in. It was called “F/MAP-TSR”.  Lotus @Factory allowed a “Terminate and Stay Resident” (TSR) program to feed data into 1-2-3 on a MS-DOS machine. SISCO and Lotus jointly developed the specs for this product and introduced MMS drivers for Lotus @Factory (later for Allen-Bradley and Modbus too). Here is an interesting tidbit: the very first live piece of data that ever flowed from a real-time device to a PC spreadsheet used the MMS protocol.

However, ENE88i was not really a plugfest. Most of the booths were isolated. Some people had demos, like SISCO, but most couldn’t even demo live links. The first plugfest was actually an event called the International Programmable Controller show in 1991 (IPC’91). This was the big event for PLCs (they were still called PCs then) and was sponsored by the Engineering Society of Detroit. Based on work with GM and GM vendors, SISCO organized a multi-booth network for the IPC’91 show where we strung coax between companies like Allen-Bradley, GE, Modicon (part of AEG by then), Lotus Development, Motorola and a few other. They called it “Connect ‘91” and printed up magnets and buttons with a lightning logo that said “We’re online with MMS”. There was a big MAP/MMS plugfest in Munich in 1992 called Systec ’92.  There was a large booth with a common network where each participant was given a space to show their stuff connecting to the network.

This was all Ethernet based. Most of the Ethernet connections were the original 10MB Coax with T-connectors. The show was organized by the European MAP Users Group (EMUG) which was a fairly active organization that was focused on promoting MMS-OSI over Ethernet. Token bus was dead at this time already. Siemens was the big name participant in this show and had an S7 controller with MMS in the event. Other European vendors included AEG (which had bought Modicon), Telemecanique, and Bosch. In 1991 Arthur Andersen Consulting contacted SISCO and asked if they could provide some technical expertise to help them write a spec that uses MMS. It turns out that they were working on a project for EPRI to develop a communications architecture for the newconcept of using a network inside substations, between substations, between substations and control centers and between control centers and each other. MMS was the only existing standardized protocol they could find that looked like it might work.

At the time it was the only protocol in existence that provided access to complex data (data with multiple attributes like value, quality and timestamp) for real-time systems. The UCA (Utility Communications Architecture) 1.0 roll-out by EPRI was in Atlanta in November of 1991. UCA was developed under the sponsorship of the Electric Power Research Institute (EPRI) through a process of broad industry involvement.
The objective has been to allow for seamless integration across the utility enterprise using off-the-shelf international standards to reduce costs. The process started with the creation of a requirements document that defined the communication requirements for the various functions inside a substation. The functional requirements document was followed by an implementation and evaluation phase that defined the “profile” of a communication structure for the substation. The profile that has been defined is shown generically in Figure5.

The publication of UCA 1 was in December 1991. UCA Version 2.0 has been published as IEEE technical report TR1550 in November 1999. Numerous utilities were driving the spec work.
At first there was resistance to the concept of using a network, especially based on IEEE 802.3 Ethernet. Many experts thought that you MUST use a technology that provided strictly deterministic access to the network. IEEE 802.4 token bus of MAP was ruled out because it was very costly. But there were several fieldbus systems that used a token passing mechanism to control network access where there was a maximum period of time during which a node on the network was “guaranteed” to be able to access the network. Profibus was suggested as a likely candidate.

Most companies with industrial automation products already had Profibus based products. Ethernet at the time was considered non-deterministic because it used a probabilistic mechanism for network access where each node would listen for silence and then try to transmit. If there was a collision it would back off a random period of time before trying again. In theory, there was no “guaranteed” maximum.
Again, EPRI came to the rescue and funded a major effort (as part of the UCA 2.0 work) to test Ethernet and Profibus for a substation use case where 100+ devices all connected to the same network had to be able to receive a fault signal generated by one device within 4 millseconds after a major fault that caused a network disruption.

A typical substation protection use case. System configurations at this time: 10MB/s shared media Ethernet, 10MB/s switched Ethernet, 100MB/s shared media Ethernet, 100MB/s switched media Ethernet and Profibus. The results were surprising: Because Ethernet did not have to undergo a process to reestablish the token passing ring it was able to far outperform the deterministic Profibus. The testing discovered that a 10MB/s switched Ethernet network and a 100MB/s unswitched Ethernet network (shared media) could both meet the requirements. A 10MB/s unswitched network (shared media) and Profibus could not meet the requirements. The 10MB/s switched Ethernet network just barely met the requirement. The 100MB/s Ethernet networks surpassed the requirements with a significant margin. EPRI also funded a statistical analysis of Ethernet which matched the observe results to a large degree.

Once this testing was completed in 1996 it became obvious Ethernet was the right choice and the work thereafter was about making Ethernet work for UCA2 GOOSE for protection messaging and MMS-TCP/IP for SCADA.
In 1993 SISCO unbundled the MMS decoders and packaged it with a protocol stack that was designed for embedded systems so that the MMS and protocol stack could be embedded into a device. The first device to run an embedded stack with UCA 2.0 was a Valmet RTU which was shipped in early 1994. It used a Trim-7 stack that was designed to run over RS-485 serial links. This may have been the first UCA device.

It was possible to get a large device running with MMS and a stack prior to this but probably the Valmet RTU was the first small embedded device with an UCA stack running MMS. Tamarack was the second company in business by then. SISCO had a UCA protocol stack running in early 1992 when UCA 1.0 was first introduced but there weren’t any device vendors embedding it until sometime later after the specs for UCA 2.0 got a bit closer to reality.
The discussions have been not only about the protocol to be used, but also for the data modelling. Under auspices of the EPRI UCA Generic Object Models for Substation and Feeder Equipment (GOMSFE) had been developed. The goal of the UCA2.0 projects was to lead to an implementable object model and supporting communication architecture throughout the electric utility enterprise. GOMSFE merges the substation and feeder automation work with that of UCA 2.0 in order to produce common generic object models for implementation of UCA 2.0 compliant field devices in electric utilities.

Figure 2 illustrates the core Power System Object Model (PSOM) used in the UCA 2.0 Substation Integrated Protection, Control and Data Acquisition Requirements Specification. The PSOM was the used model for the representation of communicating and performance requirements, and the generic services required for communicating with substation field equipment.
The development of GOMSFE was done by a group of experts in a task force chaired by Kay Clinard in regular meetings. In order to manage the active discussions, Kay introduced a “token” - a beanie baby frog called “Fred” (Figure 9.) Only the person holding Fred was allowed to talk.

The goal of GOMSFE was to facilitate vendors in implementing the UCA substation and feeder elements of the power system into a product design. It did not, however, describe the mapping of the objects onto the application layer. This mapping was described in the UCA 2.0 Common Application Services Model and Mapping to MMS (CASM).
Figure 7 illustrates a conceptual model of the Communications Server as represented by CASM. GOMSFE defines the Generic Object Models for communicating with field devices that are shown in the CASM conceptual model. It provides the standard interface definition for the outside world to communicate with field device controllers, and their representation of the field devices.
This interface occurs between the remote client or user and the CASM services, and between the CASM services and the server or field device controller. The interface is generic in nature and addresses object definitions and object hierarchy for modeling the protection, control and data acquisition requirements of substations and feeders. The requirements and performance specifications for substations are detailed in the UCA 2.0 Requirements Specification.

Figure 8 illustrates the relationship of GOMSFE and CASM. This figure depicts the Generic Object Models for Substation and Feeder Equipment as the interface between the remote client or user and the CASM services, and the interface between the CASM services and the server or field device controller. The field device controller can be considered an instantiation of the core PSOM model of a real field device.
The idea of building blocks was initially proposed by Alex Apostolov. They later became known as “bricks” in the GOMSFE model and are aggregated to form the logical device models that are contained by the remote server and represent real world devices.

The modeling process is based on the definition of a library of basic, common objects and standardized, reusable, bricks (basic building blocks built from common objects using standard data types, common data classes, and functional component groupings) to add further levels of functional detail and specification. The individual objects and object components are defined using standard types and the objects and models are defined at the most simplified and common classification level to allow the construction of widely varying models. These objects are given machine readable names using standard abbreviations. Vendor extensions to the models may be made following the required GOMSFE model. The GOMSFE objects are mapped onto generic services of the application layer using the UCA Common Applications Services Model (CASM).

The CASM provides a generic application layer service platform for communications throughout the utility architecture. The CASM is mapped onto the Application Layer protocol services specified by UCA for the particular application. UCA defines a set of communication profiles (protocol stacks) to support the application layer. The “building blocks” mentioned are that what we call “logical nodes” in IED 61850 today.
UCA presented interoperability during a demonstration held in Albuquerque, New Mexico on May 13, 1999. A total of 12 vendors participated and were able to connect over a UCA 2.0 complaint substation LAN via 10 MB Ethernet.
Before discussing how the GOOSE entered our substations we have to describe the history of standardization at IEC and we have to go back to May 1995, the TC57 plenary meeting in Minneapolis decided to create WG10, WG11 and WG12. The origin of this decision was the TC57 plenary in Nov 1993 in Sydney.  Germany issued a green paper asking to start investigating in standardization for substation automation.

At that meeting, the scope of IEC 61850 was expanded and an Ad hoc WG “Substation Control and Protection Interfaces” was created.

This AHWG had four meetings between March 94 and Feb 95 and proposed four new work items: The fourth lead to the development of IEC 60870-5-103 as short term solution, the others had the scope of:
a)   General requirements and architecture (WG10,) Figure 12
b)  Communication between station level and bay level (WG11,) Figure 13
c)  Communication between bay level and process level (WG12,) Figure 14

In November 1995 the three WGs had the first meeting in Baden, Switzerland. The goal of the standard agreed on can be seen on the title picture on page 70 of this article. Between 2002 and 2005, the original Edition 1 of IEC 61850, consisting of 14 parts, was published. A few milestones on the way to this publication are worth to be mentioned:
   April 1997: Washington, U.S. Coordination WG10 / WG11 / WG12. After a more than one year of work, it was figured out, that the work of the different working groups required more coordination. Therefore, a coordination meeting was held in Washington. At that meeting, the basic document layout of IEC 61850 was decided and it was agreed that some of the work would be done in joint task forces.
   February 1998 at the Tampa meeting:  IEC and IEEE delegates agreed that all further activities shall be done in the context of IEC 61850 (Figure 10) and the current state of UCA2.0 shall be published as IEEE TR1550
   February/ March 1999:  First CD of parts 1 to 5 and 7
    June 1999: The first CD of IEC 61850-9-1 published
  October 2001: The first FDIS (Part 3 and 4) was published, also CD of 8-1 and 9-2
  November-December 2003:  The remaining parts 6, 8-1 and 9-2 where published as FDIS
   January 2004:  Part 10 was published as CDV
   February 2005:  FDIS of part 10 was issued
With the publication of part 10 as standard in May 2005, the first edition of IEC 61850 was completed. In August 05, for the 10 anniversary celebration, there was a meeting in Baden, Switzerland and in Klaus, Austria (Figure11).

The detailed history of GOOSE, the implementations of GOMSFE and IEC 61850 will be covered in the next issues.     


Walter Schossig (VDE) was born in Arnsdorf (now Czech Republic) in 1941. He studied electrical engineering in Zittau (Germany), and joined a utility in the former Eastern Germany.  After the German reunion the utility was renamed as TEAG, Thueringer Energie AG in Erfurt. There he received his Masters degree and worked as a protection engineer until his retirement. He was a member of many study groups and associations. He is an active member of the working group “Medium Voltage Relaying” at  the German VDE. He is the author of several papers, guidelines and the book “Netzschutztechnik
[Power System Protection]”. He works on a chronicle about the history of electricity supply, with emphasis on protection and control.

Thomas Schossig (IEEE) received his masters degree in Electrical Engineering at the Technical University of Ilmenau (Germany) in 1998. He worked as a project engineer for control systems and as a team leader for protective relaying at VA TECH SAT in Germany from 1998 until 2005. In 2006 he joined OMICRON as a product manager for substation communication products. He is author of several papers and a member of standardization working groups.

Protecting your electrical assets? today and tomorrow