1. What does UCA^TM stand for?
UCA stands for Utility Communications Architecture. UCA is specified and published in IEEE-SA Technical Report on Utility Communications Architecture (UCA TM ) - Version 2.0 - IEEE-SA IEEE-SA TR 1550-1999
The Utility Communications Architecture (UCA), a trademark of the Electric Power Research Institute, Inc. (EPRI), Palo Alto (CA).

2. What are the key words for UCA?
Communications, control centers, digital systems, distribution automation, feeder automation, power plants, substations, open communication, data integration, device description, re-useable device specifications, ...

4. What is the main objective of UCA?
UCA is a standards-based approach to utility communications that provides for wide-scale integration at reduced costs and solves many of the most pressing communications problems for today's utilities. Prepared under the auspices of the Profile Working Group of the MMS Forum, the UCA is designed to apply across all of the functional areas within the electric, gas, and water utilities. These functional areas include customer interface, distribution, transmission power plant, control center, and corporate information systems.
It is important to note that UCA is an architecture, rather than a simple protocol. UCA Version 2.0 incorporates a family of basic communications protocols to meet the requirements of a wide range of utility environments. The selection and organization of these protocols has been designed to provide great flexibility in choosing the appropriate technology to meet a utility's price/performance criteria, while maintaining consistency at the device and data level to reduce integration and vendor product costs.
In addition, the UCA includes detailed object models, which define the format, representation, and meaning of utility data. This modeling effort goes far beyond the scope of any other utility communications approach and provides for an unprecedented level of multi-vendor inter-operability. The combination of broad scope and detailed object modeling makes the UCA specifications more complex than a typical protocol document.

6. What does Device Modeling mean in the context of UCA?
Describing device functionality by specifying the data (syntax and semantic) and the dynamic behavior (state machines) of devices (as seem from remote) is one of the crucial challenges in UCA. The device modeling has crucial impacts (saving money!) on e.g.:
- Engineering (in the context of a plant),
- Commissioning,
- Configuration,
- Operation,
- Maintenance
A UCA compliant device model defines the device as it is seen from the outside. Device models in UCA allow to re-use the specifications defined and tested earlier, and that are in use in many applications (define once - use many times).

Every attribute has a specific semantic. Attributes are often derived from other classes. Many attributes are inherited from common classes. Common classes are composed out of some 150 common components. Common components are, e.g.:

These names, their semantic and their types are used to build the device classes of IEEE TR 1550 Volume 2 – Part 4 (GOMSFE – Generic Object Models for Substation and Feeder Equipment). This document could be understood as a class repository for substation and feeder equipment. The repository is a source of classes to be used to construct simple and complex devices.

8. What is the relation between UCA/GOMSFE and the future IEC 61850 (Substation Standard)?
About all services of UCA/CASM and about all attributes and classes of TR 1550 will be specified and published in IEC 61850-7-3 and 61850-7-4.

9. What is the relation between UCA and MMS (ISO/IEC 9506)?
Within UCA, all real-time data acquisition and control applications make use of the application layer standard ISO/IEC 9506: 1990, Manufacturing Message Specification (MMS). The MMS specification defines a common message format for providing a wide range of services to the applications. MMS services include, for example, reading, writing, and reporting of variables (simple or arbitrarily structured data types), event management, journaling, remote program control, and uploading/downloading of data and programs. The MMS protocol provides a rich real-time network-programming environment to support a very wide range of distributed applications. The various MMS models and services are independent of each other. Only those services and models that are actually required for a specific application need to be implemented. MMS is highly scalable, i.e., it can be applied for very simple field devices (using only a few services) as well as for most complex computers. The use of a common message format regardless of the underlying network structure again reduces integration costs for all, and also allows for general off-the-shelf vendor independent tools for configuring, managing, and maintaining both applications and networks.

10. What is the TRIM7 stack?
The TRIM 7 stack uses some modifications (usually called the FastByte options) to the upper layer stacks (layers 5-6) that allow for nearly eliminating the protocol for these layers. Most of the functionality of those layers is not used in most stacks, except for under certain application layer protocols such as RDA. When using the FastByte options, some special codes are used instead of the normal protocol during connection establishment. If the implementation recognizes the codes, the connection is established with no negotiation, and the protocol is basically skipped for the duration of the connection. If they are not recognized, the connection will be refused and the caller must revert back to the full 7 layer protocol.

11. What are the pros and cons between TRIM 7, 7-Layer, and stack with TCP/IP?
The TRIM 7 protocol saves some bandwidth on the wire, but most of the savings are really just during connection establishment.  In the OSI MMS profile, there is really very little protocol overhead to layers 5-7 during the operational phase of a connection.  It could also save some code space, although (at least in our implementation) the minimal subset of layers 5 and 6 required for MMS take up very little code space anyway.  We recommend including both into every product - the minimal code space required allows for much more product flexibility, and eliminates a major headache in product configuration and support in the field.

The TCP/IP stack has the primary advantage of being free on most desktop systems. There are two issues to consider, however:

1) While TCP/IP is free on the desktop systems, it is far from free on most embedded platforms. Unless you happen to use pSOS or VxWorks, you will likely have to buy a license for TCP/IP. While there are many TCP/IP product offerings, most are unsuitable for the embedded environment.

2) Most of the TCP/IP desktop implementations have problems with generating "keep-alive" messages.  Vendors of TCP/IP are not required to implement it. Furthermore, if it is implemented, the time interval is generally a system-wide parameter (making it a problem if you are also using TCP/IP for non-real-time traffic), and the default setting is supposed to be (by specification) larger than 2 hours.