Competing Solutions
Communications for the Utility Enterprise Operations

Dennis K. Holstein, Publisher  
June 1999

How did we get here?

In the late 1980s, the Electrical Power Research Institute (EPRI) published UCA (Utility Communication Architecture). The purpose was to define a data communications approach that could be used throughout the utility enterprise. In this document, EPRI recommended the use of a communication protocol based on ISO 9506 (Manufacturing Message Specification).

In the early 1990’s, responding to an urgent industry need, EPRI led the efforts to define a protocol for control center to control center communications (between utilities). The result was the creation of ICCP (Inter-control Center Communications Protocol). The international utility industry had a similar need, and ICCP was offered as input to an international standard. That work is now complete, and ICCP has been published as IEC Std 870-6 (TASE.2). From a network operations perspective, ICCP is a classic 'point list view' of all devices in the electrical network. That is – only devices or data included in the points list may be viewed by another utility.

This restriction is important – and desirable – so that only devices or data required for electric network operations is included in the points list and is thus available. Proprietary information, such as cost data, is not included in the points list and so cannot be read by a neighboring utility. As ICCP (or an equivalent) is necessary for utility network operations, EPRI calls it part of UCA.

 EPRI then began work on UCA 2.0 to use object-oriented technology to describe the behavior of each device. The objective of UCA 2.0, from a network operations perspective, was to change to a 'device view' of all devices in the electrical network. The objective was to capture in the data structures, communicated between IEDs (Intelligent Electronic Devices) in the utility’s internal network. The objection was also to capture, in the data structures communicated between IEDs, the behavior of the device.

To date, the bulk of the detailed work on UCA 2.0 data objects has been the substation and feeder equipment. Several UCA 2.0 reports, including GOMSFE (Generic Object Models for Substation and Feeder Equipment) have been submitted to IEC Technical Committee (TC) 57 and to IEEE Power Engineering Society (PES) for consideration as international standards.

Before discussion of IEC TC57’s consideration of the UCA 2.0 reports, we should first address the issue of inter-operability between ICCP version of UCA 2.0 (point list view) and the GOMSFE version (device view). This issue was first raised in a venue sponsored by EPRI called the UCA Forum. Unfortunately, a reasonable peer review of interoperability between ICCP and UCA 2.0 was not completed before the UCA Forum went out of business in 1997.

However, the consensus of the attending members was that only for special cases would the two implementations interoperate. This is best described by considering the following two situations. In a client-server environment, if the client implemented GOMSFE and the server implemented ICCP, the two could sometimes communicate -- but not always. If the implementation is reversed, ICCP in the client and GOMSFE in the server, most communications will NOT inter-operate. From a utility integration point of view this can get real ugly! Yet some utilities are considering the use of ICCP (TASE.2) from the EMS or SCADA master to the substation.

Interoperability between IEC specified protocols

Now consider the IEC work in TC57 Working Groups (WGs) 10, 11, 12, 13 and 14.   WGs 10, 11 and 12 are working on IEC 61850 a substation automation system (SAS) standard. WG 13 and 14 are working on energy management system (EMS) interfaces (IEC 61970) and distribution management system (DMS) interfaces (IEC 61968).

WGs 13 and 14 use the same IRM (Interface Reference Model), and are well harmonized by using UML (universal modeling language) for representing the object-interaction between business functions, including network operations. IDL (Interface Definition Language) is the method used by both WGs use to describe the interfaces. XML (Extensions to SGML), which is used for web publishing, was adopted by both WGs to describe the information published to a repository and then retrieved by a subscriber from the repository. This approach handles well documents with complex structure; e.g., graphical information system documents. XML encoding is not intended for high-speed exchange of data between IEDs, but does efficiently encode complex data structures for publication to a repository and subsequent retrieval by a subscriber.

Meanwhile, IEC WGs 10, 11 and 12 are using a 'UCA 2.0-like device view' for communication between IEDs. WG 10 is working on the overall requirements for SAS communications. WG 11 is working on communication between control units, protection units and substation computer (or bay controller) within the substation. WG 12 is working on the communication protocol for streaming data from the instrument transformers and switchgear into the control and protection units. Most of the work on 61850 is developed in joint task forces with representatives from all three WGs.

SAS specifications use UML to define device objects, but SAS does not use an IDL to define the interfaces. Instead, SAS uses a variation of UCA 2.0 to define interfaces. SAS also uses Abstract Syntax Notation One (ASN.1), IEC Std 8824 to formally define the data objects to be exchanged. The intent is to provide encoding of the data objects that will be efficient for high-speed communication between IEDs and the substation computer (or bay controller).

Clearly, SAS encoded data cannot be exchanged with XML encoded data. Thus a gateway for protocol conversion must be built into the architectural scheme. If EMS and DMS interface specifications dictate the interface between the substation and control center interfaces, then all information in the substation must reside in a repository (probably a substation computer) to service the external interfaces for EMS and DMS. The downside to this architecture is the loss of direct communication access between the EMS and DMS control centers and the devices in the substation.

Substation devices must now report ASN.1 encoded data to a substation host (or bay controller), which in turn must publish XML encoded data to a repository for retrieval by EMS or DMS control centers. Control action from EMS and DMS must first be delivered as XML encoded data to the repository, then retrieved by a substation host (or bay controller), converted to ASN.1 encoding and passed to the device to be controlled.

Enterprise interoperability is in trouble

Clearly, EPRI's vision of one 'mother-of-all-protocols' for the utility enterprise is no longer a viable option. In fact it was probably a bad idea to begin with. In the real world, gateways are always required to integrate legacy IEDs into the enterprise communication network; and more importantly, to provide a graceful migration to future communication technologies.

Interoperability is a great goal, but the utility should recognize that it would only be achieved by carefully engineering the communication architecture to be resilient to the rapidly changing technology. Where high-speed communication performance is needed for protection, the best protocol should be used on the local area network.

Where message delivery speed is not the critical issue, information should be published to a central or distributed repository, and other business processes should fetch the data from this repository through a subscription service.

To reduce risk, the utilities should rapidly prototype their architecture and test the communication performance before committing to its deployment.