UCA 2.0 for Dummies

The Utility Communications Architecture version 2.0 (UCA 2.0trademark) is getting harder to ignore. What once may have appeared as a vague theoretical model promising easier integration and coordinated wide-area schemes is gaining utility and vendor backing at an appreciable rate.

Early RTUs (hamster optional).
Click here to enlarge image

The substation engineer sees the value in vendor-independent integration and software. The folks in finance like the idea of buying the same equipment that the computer industry has made cheap and efficient. System planners and buyers can get their information without dipping their fingers in the SCADA system, which makes all of them happy.

A growing number of people want to be familiar with the architecture. This article is the first in a two-part series presenting the basics of UCA 2.0. It describes UCA 2.0’s development history and the problems UCA 2.0 can help solve. The second article, which will appear in next month’s issue, will explain how the technology compares with existing proprietary and public domain protocols.

A Little History

Traditional RTU configuration.
Click here to enlarge image

In the 1980s and ’90s, the proliferation of digital electronic devices provided electric utilities with potential measurement, communication and control technologies. As vendors and utilities designed communications protocols best suited to their applications, they gave little thought to the ease of integrating such systems with others.

The first remote terminal units (RTUs) collected analog data from substations and transmitted that information over low bandwidth wires to proprietary software packages at control centers. They were expensive, required centralized control, and modification was difficult. A budgeting clerk or system planner who wanted to add revenue or energy demand information to the system would likely get the same response from a SCADA specialist as a man offering to help his wife cook Thanksgiving dinner-“No. Here’s a beer. Now get out of my kitchen.”

Public-domain register-based protocols were an improvement. Any hardware or software vendor can use DNP 3.0 or Modbus without paying exorbitant license fees or being locked into only a few suppliers. However, these protocols often require a lot of configuration at the substation to ensure software and hardware interoperability. Each vendor can implement the protocols differently, and someone must configure the RTU with the proper registers for each device. This again produces a relatively inflexible system. Once it’s up and running, modification is a headache. This, coupled with a reluctance to modify a system so essential to reliability, means that departments outside of SCADA often must gather information with their own secondary systems.

UCA was designed as a framework to address and help resolve these proprietary and interoperability issues using a de-centralized, object-oriented philosophy brought over from the general computer and information technology industry.


Hands off the SCADA, kid.
Click here to enlarge image

Object-oriented describes a philosophy of breaking down large problems into smaller blocks with defined interfaces that are easier to solve. Think of the mass production techniques that Eli Whitney developed during the Civil War. Instead of building or repairing every rifle from scratch, mass production made it possible to piece together a rifle from standard parts. Each part had a fixed interface to the other rifle parts. This made the rifles faster to repair, cheaper to build and more reliable than those produced using the older method. It also allowed for incremental improvement of the overall product because one part could be interchanged with an improved version without affecting the other parts. Similarly, instead of designing a SCADA system as a monolithic central point data database, UCA allows a system to be designed where the information is organized as a collection of devices containing objects that can be independently accessed by multiple systems. When the devices themselves contain the information, perform some of the system logic and negotiate their own communications, the monolithic database is decomposed into a collection of smaller blocks of information that are easier to use, resulting in a simpler, more flexible system.


Self-description is another dominant philosophy in UCA. A UCA-compliant device can provide a complete description of all the data it contains over the wire. Instead of spending days tediously entering arcane point numbers into a SCADA database, the SCADA system can simply request the list of points from the device and it will present the list to the SCADA programmer. To make it even easier, UCA point names follow a logical device model based on object-oriented techniques. Therefore, instead of having to remember (or configure) that the phase A voltage is wired to terminal block 40, wire number 33, in cabinet 24 in order to access a data point (as is the case with many traditional RTU protocols), UCA objects have functional names that are more easily recognized.

UCA as a Common Language

Data in UCA 2.0-compliant device.
Click here to enlarge image

It’s easier to integrate systems and access information if all devices on the network are speaking the same language and can easily interoperate. UCA makes this possible. UCA is a defined standard of terms and actions that apply to every function an electric, gas or water utility could need.

In the 1980s, EPRI set out to define what exactly that information would be. After collaboration with several utilities, it began the Integrated Utility Communications (IUC) program. The first project initiated under this banner was UCA.

UCA was a general scheme that outlined the type and flow of information within the utility. Many aspects of UCA were and remain protocol-independent, meaning that the functionality stands apart from any protocol used in its implementation. However, the initiative would have remained a theory if a protocol for real-world use had not been selected. Since one of the objectives of UCA was to avoid creating new, utility-specific protocols, existing candidates were evaluated to determine their ability to handle the data exchange needs outlined in UCA.


Manufacturing Message Specification (MMS) is an internationally standardized (International Organization of Standardization 9506) messaging system for real-time networked data exchange and supervisory control. It is among few candidates considered robust and prevalent enough to be suitable for UCA. It offers so much functionality, in fact, that it presented a problem at first. Without proper specification, MMS could have become another wide-open playing field in which new “islands of information” would develop without standardized object models and service usage conventions. The MMS Forum (now called the UCA Forum) was formed to more precisely define how MMS would be used to implement the functions desired in a UCA environment. These specifications, coming in the forms of documents like Common Application Service Model (CASM), Generic Object Models for Substation and Feeder Equipment (GOMSFE), and Inter-Control Center Communications Protocol (ICCP), are collectively known as UCA 2.0.


CASM is a document that specifies the step-by-step methodology, or more simply the “verbs,” of UCA 2.0. CASM is protocol-less; that is, its services are described so that any appropriate protocol could emulate them. However, since MMS is the current UCA implementation protocol, the documentation maps CASM services to MMS.

In CASM, opening a breaker using a UCA 2.0-compliant device requires the use of a “select-before-operate” (SBO) service. MMS offers two basic commands that are suitable for use in a SBO operation-read and write. These MMS commands are used to operate on specific variable objects within a device. CASM specifies MMS to the SBO mapping function so that a system implementing UCA would perform as follows:

1. On the SCADA display screen, a user clicks on the icon of an intelligent electronic device (IED) attached to a breaker, preparing to change the state of the breaker to “open.”

2. As a result, the SCADA system issues a MMS “read” command to a SBO object in the IED.

3. The IED verifies the user’s identity and access privilege for that SBO object, then it replies with a permissive (or a denial) in the MMS read response.

4. The SCADA system sees the permissive in the read response and allows the user to then click on open in his or her SCADA display screen.

5. The SCADA system then sends an MMS write command to the breaker object, causing it to open.

This is an example of how a relatively high-level operation-the select-before-operate that CASM describes- is mapped onto the simpler read-and-write functions of MMS. CASM specifies this mapping for every function in UCA 2.0. This approach allows CASM to eliminate variances in how the SBO function can be implemented using a given protocol.


If CASM represents the verbs of UCA 2.0, then GOMSFE can be thought of as the nouns. The GOMSFE document is a dictionary of standardized object modes and their associated names used to describe equipment and functions within a substation IED. Every UCA 2.0-compliant device uses the same naming conventions. Therefore, a generic UCA client can read the same information from multiple UCA 2.0-compliant devices supplied by different vendors using the same language.

The information is organized in a hierarchy of increasing detail similar to the folders in a desktop explorer application. For example, if phase A Amps are to be accessed from a Bitronics PowerServe IED, a specific route would be taken.

First, a device on the network would be accessed by using its physical network address or using a name that represents this network address. Within that physical device, CASM/GOMSFE would define a logical device that is identified via its domain name, which in this example is called PowerServe. This domain name corresponds to a logical device (meter, relay, RTU, etc.) that resides within a single physical network device. As is the case with a data concentrator, there can be more than one of these logical devices within a single physical device, like apartments within a building at one street address.

Within that device, the first level of hierarchy is the brick. A brick represents a functional grouping of information within a logical device. For example, the poly-phase measurement unit information for a meter is supplied in a brick called MMXU1 (Polyphase Measurement Unit #1). Within that brick are other subfunctions such as setpoints, descriptions, actual measurements, etc. Under measurements (MX) the next subgroup would be amps or “A,” which is then organized into individual readings for each phase, which would be referred to as PhsAf for the Phase A floating point value.

These elements can be combined to come up with a common name for the ampere reading of Phase A in any poly-phase measurement and can be easily recognized with just a little training:

  • Domain = PowerServe
  • Object = MMXU1$MX$A$PhsAf

The data objects defined by GOMSFE also describe the way information is presented. In this example, the Phase A Amps may also be available as an integer value in an object called MMXU1$MX$A$PhsAi.


ICCP is a UCA 2.0 standard that specifies point/tag-oriented communications methods for use between control centers. ICCP has been published as an international standard under IEC60870-6 Telecontrol Application Service Element #2 (TASE.2). It is known as TASE.2 internationally. Although ICCP-TASE.2 uses MMS in the application layer, it doesn’t use the CASM or GOMSFE object models. Instead, ICCP-TASE.2 treats data as a points list similar to traditional SCADA systems.

When two utilities need to exchange a subset of information, they must first generate a bilateral agreement that specifies all the points that each utility is willing to expose to the other, as well as all the points that a utility needs for the other. This list of points must exactly match the two utilities in order for ICCP-TASE.2 data exchange to occur. This bilateral agreement (called a “bilateral table”) creates a lock-and-key methodology that allows utilities to carefully control the information they exchange with each other. The contents of the bilateral table are specific to the two parties involved. The ICCP-TASE.2 standards do not specify naming conventions or other data models for the contents of the bilateral table. Therefore, unlike CASM/ GOMSFE, the list of points in the bilateral table represents an agreement between the two parties only and may or may not expose the internal data structures and models that might be used within that utility. For this reason, ICCP-TASE.2 has become the industry standard for inter-utility data exchange of real-time information around the world. Very large-scale ICCP-TASE.2 projects have been implemented in North American and other large regional projects are planned in Europe, South America and Asia.

Authors Note: The second article in this series will cover the nature of UCA 2.0 networking and compare the functional attributes of UCA 2.0 to more familiar systems. John Burger of AEP will co-author with Conrad Oakey.

Conrad Oakey is a freelance technical writer retained by Bitronics Inc., a UCA 2.0-compliant measurement IED manufacturer. More information can be obtained at www.bitronics.com.

Ralph Mackiewicz is the vice president of SISCO Inc., a software company specializing in MMS/UCA/ICCP-TASE.2 applications. More information can be obtained at www.sisconet.com.

Previous articlePOWERGRID_INTERNATIONAL Volume 5 Issue 2
Next articleELP Volume 78 Issue 4

No posts to display