TP 114398

IEEE-SA TR 1550 -- Technical Report
Utility Communications Architecture (UCA) Version 2.0

Volume 1
Part 1: Introduction to UCA Version 2.0
Part 2: UCA Profiles
Part 3: UCA Common Application Service Models (CASM)
Volume 2
Part 4: UCA Generic Object Models for Substation and Feeder Equipment
(GOMSFE)
IEEE-SA TR 1550-1999
IEEE-SA Technical Report on
Utility Communications
Architecture (UCA )
TM
Version 2.0
Volume 1
Part 1:
Introduction to UCATM Version 2.0
Part 2:
UCATM Profiles
Part 3:
UCATM Common Application
Service Models (CASM) and
Mapping to MMS
Published by
The Institute of Electrical and Electronics Engineers, Inc.

3 Park Avenue, New York, NY 10016-5997, USA.
"UCA" is a Trademark of the

Electric Power Research Institute, Inc. (EPRI)
Palo Alto, CA, USA
15 November 1999 SP1117

Utility Communications Architecture Version 2.0
Part 1: Introduction to UCATM Version 2.0
Prepared under the auspices of the Profile Working Group of the MMS Forum
Keywords: communications, control centers, digital systems, distribution automation, feeder

automation, power plants, substations
IEEE-SA
TR 1550-1999 UTILITY COMMUNICATIONS ARCHITECTURE (UCATM VERSION 2.0)
Introduction
The Utility Communications Architecture (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 todays utilities. 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 utilitys 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 multivendor interoperability.
The combination of broad scope and detailed object modeling makes the UCA specifications more complex
than a typical protocol document. This introduction provides background information to assist in under-
standing the overall document set and to guide the reader toward the most relevant sections.
The technical specifications described in this report represent a consensus of expert opinion at the time of
publication, as developed under EPRI sponsorship. This work will be carried forward through the standards
process of a number of organizations.
ii Copyright 1999 IEEE. All rights reserved.

IEEE-SA
PART 1: INTRODUCTION TR 1550-1999
Contents
1. Overview........................................................................................................................... 1-1
2. References ........................................................................................................................ 1-2
3. Definitions ........................................................................................................................ 1-3
3.1 Industry-Based Acronyms........................................................................................ 1-3

3.2 General Definitions .................................................................................................. 1-4
3.3 Definitions Specific to UCA Version 2.0 .................................................................. 1-6
4. History............................................................................................................................................... 1-7
4.1 UCA Version 1.0 ...................................................................................................................... 1-7

4.2 UCA Version 2.0 for Real-Time Database Exchange .............................................. 1-8
4.3 UCA Version 2.0 for Field Devices........................................................................... 1-8
5. UCA Version 2.0 Document Summary ........................................................................... 1-9
6. Implementors Guide to Version 2.0 Specifications ...................................................... 1-10
6.1 Implementing UCA Version 2.0 TASE.2 (ICCP) ................................................... 1-10

6.2 Implementing UCA Version 2.0 Field Devices ...................................................... 1-11
7. UCA Integrated Network Example .............................................................................. 1-12
Copyright 1999 IEEE. All rights reserved. iii

1. Overview
The UCA protocols are organized according to the open systems interconnection (OSI) reference model
developed by the International Standards Organization (ISO). The OSI model organizes communication
functions into seven layers. By utilizing the OSI reference model, various data link and media options, for
example, can be employed without modifying any of the upper communications layers and without modify-
ing the applications. Bridges, routers, and gateways provide seamless integration across various subnetworks
in ways that are invisible to the applications. The immediate benefits of the layered approach of UCA are:
Vendors products have access to wider markets, in that even when providing only a single protocol
choice, they can be integrated into a wide variety of networks using off-the-shelf bridges, routers,
and gateways.
Reduced utility integration costs, and the ability to choose the media/link combination that best
meets their cost/benefit range while still maintaining vendor and application independence.
The ability to incorporate future communications innovations by both utility and vendors while
maintaining their existing implementations.
When applying the OSI reference model to a given application environment, protocols must be selected for
each of the OSI layers, resulting in a communications profile for that environment. UCA Version 2.0
includes profiles employing protocols from both the OSI and TCP/IP families of protocols. Profiles are spec-
ified for both connection-oriented and connectionless (datagram, used in UCA for multicast) communica-
tions, running over common local area and wide area networks (LAN and WAN), as well as various utility
specific media such as radio. Reduced profiles, which eliminate the protocol of layers three through six (and
the underlying functionality), are identified for low bandwidth environments, and also for devices that may
not have the processing/memory capabilities to support the full 7-layer profiles.
The common protocol scheme of UCA provides significant additional benefits to utilities facing increased
communications requirements due to deregulation. The isolation of the applications from the underlying net-
work structure, combined with the inclusion of security/encryption methods in all of the UCA profiles, pro-
vides for the only comprehensive solution to open access communications requirements. UCA provides the
capabilities to allow secure access by foreign utilities to specific systems (and customers), while keeping
them isolated from the details of the network and device infrastructure.
The OSI application layer provides the top-level communications functions to software applications making
use of the network. The UCA profiles incorporate a variety of protocols at the application layer to support
utility applications. Electronic mail is provided by the ITU-T Recommendation X.400, while directory ser-
vices (location of addresses, etc.) is provided by ISO/IEC 9594: 1995, The Directory, along with the ITU-T
X.500 series Recommendations. Network Management capabilities make use of the ISO 9596: Common
Management Information Protocol (CMIP). The EPRI-sponsored Database Access Integration Services
(DAIS) is used to provide access to relational data models by specifying services using the Remote Data-
base Access (RDA) and Structured Query Language (SQL) standards.
Within UCA, all real-time data acquisition and control applications make use of the application layer stan-
dard 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 struc-
ture 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.
Copyright 1999 IEEE. All rights reserved. 1-1

IEEE-SA
The exchange of real-time data acquisition and control information within the utility industry breaks down
into two primary classes of applications: access to data in real-time databases [such as energy management
system (EMS) and supervisory control data acquisition system (SCADA)], and access to real-time end
devices [switchgear, meters, remote terminal units (RTUs), etc.]. The two classes of applications are charac-
terized by somewhat different data models and access control requirements. The rich set of MMS services
and data representation allows both classes of applications to be supported, but with different data formats
and different interpretations.
UCA supports models of real-time SCADA database elements as well as a variety of scheduling and other
data exchange models through the use of Telecontrol Application Service Element 2 (TASE.2, also known as
Inter-Control Center Communications Protocol, or ICCP in North America). TASE.2 is defined by the stan-
dards IEC 870-6-503, IEC 870-6-802, and IEC 870-6-702, developed for use with MMS through the efforts
of IEC Technical Committee 57 Working Group 07, with primary input from the EPRI-sponsored MMS
Forum Control Center Working Group.
For UCA real-time device access, detailed device object models have been developed that identify the set of
variables, algorithms, etc., required to support the basic functionality of the each device class. For example,
major voltage regulator/tap changer vendors have agreed to the base object model common to their devices.
Each of their devices, when accessed via MMS, provide a common set of variables, using common naming
(such as tap_position) and data formats, which allow the devices to be plug compatible when supporting
the basic regulation control, independent of vendor, model, or version. Vendors are encouraged to go beyond
the basic functionality and may provide extra vendor- and utility-specific capabilities. These extra innova-
tions may provide the basis for future standardization and allow for competition to advance the state of the
art without adding to the integration and migration costs of the utilities. The use of named variables (as
opposed to anonymous point lists) in device models greatly reduces planning, commissioning, documenta-
tion costs, and installation problems, in that validation of the mapping of SCADA database entries with field
device values becomes extremely simple. The combination of standardized device models and the rich ser-
vices of MMS provides even more benefits, in that the variables (and hence features, options, and additions)
provided by each device are available through simple interrogation. UCA devices are therefore self-describ-
ing, allowing for very powerful tools and operator/maintenance interfaces all vendor-, model-, and revi-
sion-independent.
The self-describing vendor-independent device object models, when combined with the highly flexible sup-
porting profiles, provide a seamless view of real-time data throughout the utility enterprise. Using standard
commercial off-the-shelf PC and/or workstation packages (e.g., MMS browsers), individual users anywhere
in the UCA enterprise can, subject to security and access controls, directly access real-time data from substa-
tion devices, feeder devices, or customer interfaceand beyond.
Portable software packages providing full UCA network interface support are available from a number of
third party vendors. Platforms supported range from large-scale systems (such as EMS), through PCs and
workstations, down to the smallest embedded systems such as pole-top field devices and low-cost meters.
2. References
This technical report shall be used in conjunction with the following publications:
EL-7547, Utility Communications Architecture (UCA) Version 1.0, Volumes 16. These docu-
ments describe the initial requirements and specifications for UCA.
EPRI RP3599, Substation Integrated Protection, Control, and Data Acquisition, Requirements
Specification. This document defines a conceptual model and performance requirements for IEDs
in substations.
IEC 870-6-503: TASE.2 Services and Protocol, Version 1996-04. Also known as Inter-Control Cen-
ter Communications Protocol (ICCP) Revision 6.0. This document provides the specifications for
1-2 Copyright 1999 IEEE. All rights reserved.

IEEE-SA
inter-control center exchange of data using MMS in standard UCA profiles.

IEC 870-6-802: TASE.2 Object Model, Version 1996-04. Also known as Inter-Control Center Com-
munications Protocol (ICCP) Revision 6.0. This document defines a set of object models for use in
control centers and power plant data exchange applications.
ISO/IEC 9506: 1990, Industrial Automation SystemsManufacturing Message Specification.
Definition of the MMS application layer standard, used in UCA for real-time data acquisition and
control.
3. Definitions
The following subsections cover various industry acronyms and definitions.
3.1 Industry-Based Acronyms
ANSI American National Standards Institute

ACSE association control service element
ASCII American National Standard Code for Information Interchange
ATMA asynchronous transfer mode
CCAPI control center application program interface
CCITT International Telegraph and Telephone Consultative Committee
CLNS connectionless network service
CLTP connectionless transport protocol
CMIP common management information protocol
CMISE common management information service element
DAIS Data Access Integration Services [DAIS is a Trademark of the Electric Power Research
Institute, Inc. (EPRI), Palo Alto, CA, USA]
DCS distributed control system
DisCo distribution company
DNS distributed name service
DXF drawing exchange format
EDI electronic data interchange
EMS energy management system
EPRI Electric Power Research Institute
FDDI fiber distributed data interface
FTAM file transfer, access, and management
GenCo generation company
HDLC high-level data link control
ICCP Inter-Control Center Communications Protocol
IEC International Electrotechnical Commission
IEC TC57 International Electrotechnical Commission Technical Committee 57
IED intelligent electronic device
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force

IEEE-SA
IP internet protocol
ISO International Organization for Standardization
ITU International Telecommunication Union
JPEG Joint Photographic Experts Group
LAN local area network
MMS manufacturing message specification
OASIS open access same-time information system
OSI open systems interconnection
RDA Remote Database Access standard [ISO 9579]
RTU remote terminal unit
SCADA supervisory control data acquisition system
SIDF system independent data format
SLIP serial line internet protocol
SNMP simple network management protocol
SQL Structured Query Language standard [ISO 9075]
TASE Telecontrol Application Service Element
TASE.1 first TASE developed by TC57 WG07, based on ELCOM-90
TASE.2 second TASE developed by TC57 WG07, based on ICCP
TCP transmission control protocol
TransCo transmission company
UCA Utility Communications Architecture [UCA is a Trademark of the Electric Power
Research Institute, Inc. (EPRI), Palo Alto, CA, USA]
UDP user datagram protocol
URL universal resource locator
3.2 General Definitions
3.2.1 application protocol data unit (APDU): An is an (N)-PDU, where N refers to the Application Layer.
3.2.2 application service element (ASE): A set of application functions that provide a capability for the
inter-working of application-entity-invocations for a specific purpose. ASEs are a component of application
service objects. An ASE can be considered to be a protocol module that is combined with others to form a
complete protocol.
3.2.3 application service object (ASO): An active element within (or equivalent to the whole of) the appli-
cation entity embodying a set of capabilities defined for the application layer that corresponds to a specific
ASO-type (without any extra capabilities being used). An ASO is a combination of ASEs and ASOs that per-
form a specific function. An ASO that provides the functions of the establishment and data transfer phases is
considered a complete protocol.
3.2.4 association control service element (ACSE): The common mechanism in the ALS for establishing
and releasing ASO-associations.
3.2.5 broadcast: Simultaneous transmission of data to all destinations on a network.
3.2.6 conformance test: A test used to ensure a product complies with a standard.

IEEE-SA
3.2.7 control function (CF): The component of an ASO that controls the interactions among the ASEs and/
or ASOs and the service provided by the containing ASO. The CF defines how the service primitive of the
Service Definition are mapped to the primitives of the component ASEs and ASOs.
3.2.8 data confidentiality: Security service that provides for the protection of data from unauthorized dis-
closure.
3.2.9 data integrity: Security service used to determine if data has been altered or destroyed in transit.
3.2.10 data transparency: Data transmission in which there are no restrictions on the bit patterns that user
data may have.
3.2.11 directory: Collection of open systems that cooperate to hold a logical database of information about
a set of objects in the real world (e.g., OSI users and network resources). The directory also provides ser-
vices for users (people and application processes) to access the information contained in the repository.
3.2.12 encryption: The transformation of data into an encoded form that requires knowledge not publicly
available to decode it.
3.2.13 frame relay: A packet-based interface standard that has been optimized for the transport of protocol-
oriented data.
3.2.14 gateway: A network station used to connect networks, systems or devices; may perform conversion
between different protocols at the application layer.
3.2.15 management information base: The set of managed objects in a system, together with their
attributes. It is a conceptual repository of management information at each system.
3.2.16 management information library: A document containing the specification of all defined managed
objects and a complete description of their behavior. Development of this library is currently being proposed
by groups such as the National Institute for Standards and Technology (NIST) OSI Implementors Workshop
Group.
3.2.17 multicast: Simultaneous transmission of data to a defined group of destinations on a network.
3.2.18 network topology: The physical and logical relationship of nodes on a network (e.g., star, ring, bus,
etc.).
3.2.19 nonrepudiation: Security service that prevents an entity involved in a data exchange from denying
that it participated in the exchange.
3.2.20 protocol data unit (PDU): A unit of data specified in an (N)-protocol and consisting of (N)-protocol-
control-information and possibly (N)-user-data, where N indicates the layer, sometimes referred to as a
packet, segment, or message.
3.2.21 polling: Communications access control procedure where a primary (master) station systematically
invites secondary stations, one at a time, to transmit data.
3.2.22 public data network: Network operated by common carriers or telecommunications administrations
for the provision of packet-switched circuits to the public.
3.2.23 quality of service: A parameter specifying the level of performance needed for communications,
such as transit delay, priority, accuracy, or reliability.

IEEE-SA
3.2.24 report-by-exception: Mode of operation in which an end system [e.g., RTU or intelligent electronic
device (IED)] only reports information that has changed since data was last transmitted.
3.2.25 response time: Time between the request and the response for a network transaction.
3.2.26 subnetwork address: The information needed to identify a particular real system attached to a sub-
network (e.g., token ring adapter address).
3.2.27 subnetwork: Collection of equipment and physical media that can be used to interconnect other sys-
tems for the purpose of communications between them. Subnetworks may be interconnected with each other
via network systems operating at the network layer or above.
3.2.28 timestamping: A field that contains the time that the data was measured or received.
3.2.29 unsolicited message: Message transmitted in response to a locally occurring event, rather than an
explicit remote request.
3.3 Definitions Specific to UCA Version 2.0

The following terms, which are specific to application services constructs, are defined as follows:
3.3.1 binary large object (blob): An arbitrarily large data element to be transported between client and
server.
3.3.2 DataObject (DO): An abstract element of a real device that is capable of providing (when read) or
accepting (when written) or both, a typed data value. A DataObject may represent a single data element (i.e.,
one measurement point) or a data structure (i.e., a complex set of data elements). The mapping of a DataOb-
ject to a real, physical entity in the device is defined by the model of the device being represented and is out-
side the scope of this document.
3.3.3 DataSet: An ordered list of references to DataObjects associated with a specific DataSet name. A
DataSet is a means of grouping data that is frequently accessed as a group.
3.3.4 DeviceModel: An aggregation of DataObjects that together represent the communications visible
functionality of a real device.
3.3.5 DeviceIdentity (DI): Contains the nameplate information of a device, such as make, model, and serial
number.
3.3.6 event control block (ECB): A DataObject residing in the server that is accessed by the client to con-
trol the criteria to be used in the detection of events. These events can be used to trigger unsolicited data
transfers from the server to the client, and/or storing of entries in logs.
3.3.7 event report: The report generated in the server by the action of a transfer set to be sent to the client.
3.3.8 functional component: A logical grouping of DataObjects within a server in which all of the objects
perform a similar function (e.g., the set of measurements or the collection of setpoints).
3.3.9 log control block: A DataObject residing in the server that is accessed by the client to control the con-
tent and format of data logging by the server. Specific services are defined that allow the client to retrieve the
logged data from the server.
3.3.10 logical device: A collection of DeviceModels within a server that appears on the network as operating
under a single nameplate.

IEEE-SA
3.3.11 report by exception (RBE) criteria: The values against which DataObjects in a DataSet will be
checked to determine if an event condition has occurred. When an event condition occurs, then specified
DataObjects in the DataSet are collected to be transmitted to the designated client.
3.3.12 report control block (RCB): A data structure that describes the criteria for the server to initiate unso-
licited data transfers by time and/or event. The data transmitted will either be the complete DataObject or
DataSet (no RBE), or it will be only the changed values within a DataObject or DataSet (if RBE is speci-
fied).
3.3.13 select before operate (SBO): A two-step device control mechanism consisting of the select service
followed by a control/operate service. The select service is used to arm the device. The device enters the
SELECTED state for some period of time. The control service is used to carry out a control command if and
only if the device is SELECED for the issuing client. This sequence has the effect that a client can lock-out
other clients from operating a point during a predetermined period of time so that it is the only client who
can operate that point during that time.
3.3.14 transfer set: A DataObject residing in a TASE.2 server that is accessed by the client to control the
criteria to be used in the detection of events and in the formatting of unsolicited reports of data. (IEC 60870-
6-503: 1996)
4. History
4.1 UCA Version 1.0
Advancements in computer and communications technology have been successfully applied by utilities in
the development of information systems. Many of these systems are dedicated to meeting the specific needs
of particular utility functions. These systems, however, have evolved based on proprietary and/or utility-
developed communications protocols. As a result, this process has created islands of information opti-
mized for various vendor-specific platforms only. These islands make communications between and internal
to them both complex and costlyor impossible, due to lack of available specifications and experts. The
problems associated with integrating these platforms are becoming more acute as the need for communica-
tions systems within a utility grows.
In order to promote and facilitate interoperability between computer systems supplied to the utility industry,
EPRI initiated the Integrated Utility Communication (IUC) program. The UCA project began in November
1988 as the first of a series of projects under this program. The project, conducted in conjunction with
Pacific Gas and Electric (PG&E) and Houston Light and Power (HL&P), resulted in the development of a
standard communications architecture, UCA Version 1.0, to meet the communications needs of the electric
utility industry. UCA Version 1.0 was based on information exchange requirements identified during inter-
views with representatives from 14 electric utility companies, including approximately 100 utility personnel
from PG&E and HL&P. A number of deliverables were created to help develop and support UCA.
As part of the UCA Version 1.0 effort, a detailed information exchange requirements analysis was per-
formed, based on extensive interviews with utility representatives. Based on the results of the requirements
definition, a standards assessment was performed to review relevant international standards from which a
suite of protocols was selected and a set of profiles defined. For most real-time data acquisition and control
applications, the standard ISO/IEC 9506: 1990 was adopted.
While the UCA Version 1.0 profiles supplied a great deal of functionality, industry adoption was limited.
One of the most significant barriers to adoption was in the lack of detailed specification of how the protocols
would actually be used in utility field devices. The rich functionality and broad generality of MMS in
particular meant that without further specification, field devices could implement utility applications using a
variety of services and procedures, resulting in a continued lack of interoperability.

IEEE-SA
4.2 UCA Version 2.0 for Real-Time Database Exchange
While the adoption of UCA Version 1.0 was limited, the needs for improved standardization within the util-
ity industry became more acute. In particular, the move toward a deregulated utility environment has signifi-
cantly increased the requirements for communications standards both within and between utilities.
The first major move to address these heightened requirements was in the area of communications between
control centers. Three primary standards were in use for inter-control center communications:
Western States Coordinating Committee (WSCC), used in the western North America
Inter-Utility Data Exchange Consortium (IDEC), used in eastern North America
Elcom 83 and Elcom 90, used throughout Europe
As the need for a unified standard became clear, the International Electrotechnical Commission (IEC) solic-
ited member bodies for contributions to be considered for international standardization. The lack of a con-
sensus standard in the US, as well as the perceived limitations of all of the existing candidate protocols, led
to the formation of a utility/vendor task force sponsored by EPRI, WSCC, IDEC, and a number of utilities.
This task force led the development of the Inter-Control Center Communications Protocol (ICCP). The name
was later changed to Telecontrol Application Service Element 2 (TASE.2) to conform to IEC TC57 WG07
taxonomy.
The TASE.2 specification defines a standardized use of MMS in UCA Version 2.0 compliant networks for
real-time exchange of data within and between control centers, power plants, and SCADA masters. TASE.2
has been standardized as IEC 870-6-503: TASE.2 Services and Protocol, IEC 870-6-802: TASE.2 Object
Models, and IEC 870-6-702: TASE.2 Application Profile. The documents are published independently of the
rest of UCA, but included by reference in UCA Version 2.0. Each of these documents was defined in close
coordination with the UCA working groups and, after revision as IEC Committee Drafts (CD), were balloted
and accepted as International Standards (IS). TASE.2 has considerable global vendor support and is cur-
rently either deployed or is being deployed in a number of utilities and power pools throughout the world.
TASE.2 is focused on the exchange of real-time data between EMS and SCADA databases, as well as power
plant Digital Control Systems (DCS), and large-scale substation hosts (perhaps even RTU level systems).
The object models supported by TASE.2 include SCADA points (such as status, analog, accumulator, and
control), generation and exchange schedules, availability and forecast reports, accounting information,
power plant curves, and general message and file data. TASE.2 does not (as currently defined) directly
include formal field device models; data is instead represented in the traditional form of points lists of each
of the various point types, independent of the actual physical device at which the data originated. This repre-
sentation is consistent with standard practice within most systems within and between control centers. Often
in such data exchange arrangements, the details of how data is acquired (including the type and physical
interconnection of field devices) is not known to the receiving party, particularly in data exchange between
utilities.
4.3 UCA Version 2.0 for Field Devices
The direct data acquisition and control of field devices (either substation, feeder, customer interface, or
power plant controls) is an area that has been undergoing significant transition. Traditionally, the end field
devices were directly connected to RTUs, which provided a network interface and performed initial process-
ing of the acquired data. The introduction of microprocessor technology has led to the development of IEDs,
effectively allowing for the direct network access to the devices, as well as more processing being performed
at the end device. As the end devices have become more complex, the cost of integrating the devices has

IEEE-SA
increased. Within the UCA framework, the definition of the data and control functions made available by the
device, along with the associated algorithms and capabilities, is known as the device object model.
As part of the EPRI-sponsored activities leading up to the publication of UCA Version 2.0, a number of
efforts were initiated to develop detailed object models of common field devices, including definitions of
their associated algorithms and communications behavior visible through the communication system. Most
notable of these efforts are the EPRI-sponsored MMS Forum Working Groups and the Substation Integrated
Protection, Control, and Data Acquisition (RP3599) project. The Forum provided an open and democratic
process, composed of representatives from utilities, vendors, consulting organizations, and the IEEE, that
enabled participants to create, debate, and critique the UCA technology. The results of these efforts are
contained in the Generic Object Models for Substation and Feeder Equipment (GOMSFE). Some examples
of GOMSFE models are RTU, Switch, Voltage Regulator/Tap Changer, Recloser, and Capacitor Bank
Controllers. The development of models for other substation and feeder automation field devices is an
ongoing process.
Modeling efforts within the customer interface area are in progress. These efforts include metering and inter-
faces to residential and commercial customer devices, being developed cooperatively within ANSI C12, IEC
TC57 WG9, and IEC TC13. There has been active industry participation in the customer interface modeling
effort. Significant work has been accomplished as part of several UCA pilot projects, and preliminary results
are available in draft form.
The device models developed within the UCA Version 2.0 effort make use of a common set of services to
describe the communications behavior of the devices. A standard mapping of these services onto the UCA
application layer protocol (MMS), when used in conjunction with the device models, completely specifies
the detailed interoperable structure for utility field devices. The services and mapping to MMS are defined in
UCA Common Application Service Models (CASM). The use of the CASM services within all UCA device
models simplifies the integration efforts across functional areas of the utility. An added benefit is that CASM
allows device models to be specified independent of the underlying protocol. This protocol independence
has encouraged active participation of groups outside the UCA activities, and will simplify migration
through the construction of gateways to older existing protocols. In addition, it may allow for the future
expansion of the UCA protocol suite to other application protocols such as Common Object Request Broker
Architecture (CORBA).
Finally, the UCA profiles have been revised to meet the requirements of a number of new operating environ-
ments. The new profiles include a fully detailed reduced (three-layer) stack for use with low bandwidth and/
or very small field devices, as well as additional profiles for operating in a UDP/IP or TCP/IP network envi-
ronment. The revised UCA profiles are defined in UCA Profiles, Version 2.0.
5. UCA Version 2.0 Document Summary

The following documents make up UCA Version 2.0:
Part 1: Introduction to UCATM Version 2.0Provides general background, history, and overview of UCA
Version 2.0.
Part 2: UCATM ProfilesSpecifies profiles for use in UCA networks including connection-oriented and
connectionless (multicast) versions for full seven-layer and three-layer forms, using both OSI and TCP/IP
protocols over a wide variety of media.
For real-time database access and control between and among control centers (EMS and SCADA), power
plant DCS, and other high-level systems within and outside the utility industry, UCA specifies Telecontrol
Application Service Element 2 (TASE.2, also known in North America as ICCP).

IEEE-SA
IEC 870-6-503: TASE.2 Services and Protocol, Version 1996-08 (IS)Outlines basic services and
protocol for remote control, accessing data, and organizing reporting functions. Makes use of ISO/
IEC 9506:1990.
IEC 870-6-802: TASE.2 Application Profile, Version 1996-08, (IS)Includes SCADA points
(such as status, analog, accumulator, and control), generation and exchange schedules, availability
and forecast reports, accounting information, power plant curves, and general message and file
data.
IEC 870-6-702: TASE.2 Application Profile, Version 1996-08, (IS)Defines detailed requirements
and options for TASE.2 applications and supporting OSI upper layers. (NB: Subset of UCA Profile
Specification, Version 2.0.)
For real-time data acquisition and control of substation field devices, UCA Version 2.0 uses the following:
Part 3: UCATM Common Application Service Models (CASM) and Mapping to MMSDefines
common application services used throughout all UCA device models, as well as mapping to appli-
cation layer protocol (MMS).
Part 4: UCATM Generic Object Models for Substation and Feeder Equipment (GOMSFE)
Defines standardized data models and methods for common substation and feeder automation
devices (RTUs, capacitor bank controllers, voltage regulators/tap changers, switches, etc.) in terms
of the CASM services.
6. Implementors Guide to Version 2.0 Specifications
6.1 Implementing UCA Version 2.0 TASE.2 (ICCP)
Vendors of EMS systems, SCADA master stations, power plant DCS systems, and other systems wishing to
incorporate TASE.2 (ICCP) into their products begin with their existing vendor product specification, which
defines the class and type of data that the system will exchange. A vendor selects the appropriate conform-
ance building blocks from the IEC 870-6-503: TASE.2 Services and Protocol, which defines the specific
TASE.2 services that must be supported. This results in the definition of the systems TASE.2 Service Inter-
face, which, when combined with IEC 870-6-802: TASE.2 Object Models, results in the TASE.2 application
definition for the system. The vendor must determine the lower protocol layers by evaluating the expected
operating environment of the device (i.e., WAN/LAN connectivity) and selecting the appropriate UCA pro-
files to be supported from the UCA Profile Specification, Version 2.0 (or IEC 870-6-702: TASE.2 Applica-
tion Profile). The selected profiles, combined with the application definition, yield the final product design.
See Figure 1.

IEEE-SA
Vendor Documents UCA Documents
Vendor Product
Information, Vendor Product IEC 870-6-503: Standardized
User Requirements Specification Selection of TASE.2 TASE.2 Services Services, Mapping to
Building Blocks and Protocol Application Layer
IEC 870-6-802: Specific Object

TASE.2 Services TASE.2 Service Types to be
Supported Interface Specific Mapping
TASE.2 Object
Supported
of Objects Models
Application UCA Version 2.0 UCA Version 2.0

Specific TASE.2
Data Objects Definition Selection of
Profile
Profiles Specification
Software Product
Implementation Design
Figure 1: Definition of UCA TASE.2 (ICCP) Products
It is important to note that for a device to be conformant to the UCA specifications, it must incorporate three
distinct specifications:
a) IEC 870-6-503: TASE.2 Services and Protocol

b) IEC 870-6-802: TASE.2 Object Models
c) IEC 870-6-702: TASE.2 Application Profile or UCA Profile Specification, Version 2.0.
6.2 Implementing UCA Version 2.0 Field Devices
Vendors of utility field devices begin with their existing vendor product specification, which defines the
functionality that the device performs. A vendor selects the appropriate model of the device from the various
UCA utility standard device models, such as Generic Object Models for Substation and Feeder Equipment
(GOMSFE) or UCA Customer Interface Device Models, developed either by an MMS Forum Working
Group, RP3599, or industry standards body. The vendor then (based on its own vendor product specifica-
tion), selects from the optional model components and adds its specialization to arrive at a product model.
The product model defines the communications behavior of the vendor product in terms of the common
application service models. The UCA Common Application Service Models (CASM) document describes
the mechanisms for representing the application services in the underlying UCA application layer protocol
(in this case, MMS). Based on that description, the vendor can produce an application definition, which
completely specifies the application layer communications software required to support the product as a
UCA compliant device, independent of the lower protocol layers. The vendor must determine the lower pro-
tocol layers by evaluating the expected operating environment of the device (i.e., high-speed substation
LAN, wide area distribution radio network, etc.) and selecting the appropriate UCA profiles to be supported
from Part 2: UCATM Profiles. The selected profiles, combined with the application definition, yield the final
product design. See Figure 2.

IEEE-SA
Vendor Documents UCA Documents
Vendor Product
Informtaion, Vendor Product Utility Standard Standardized
Specification Device Models Devices
Selection of Objects
User Requirements Data Types
and Services
Data Dictionary
Product Common Mapping Objects

Generic and Services to
Data Objects Model Application
Specific Mapping Application Layer
of Objects Service Models Protocols
Application UCA Version 2.0 UCA Version 2.0

Specific
Data Objects Definition Profile
Selection of
Profiles Specification
Software Product
Implementation Design
Figure 2: Definition of UCA Field Devices
It is important to note that for a device to be conformant to the UCA specifications, it must incorporate the
following three distinct specifications:
a) The appropriate UCA object model

b) One or more UCA profiles
c) The appropriate mapping of the common application services used in the Object Model to the appli-
cation layer protocol
7. UCA Integrated Network Example

The overall level of integration provided by UCA Version 2.0 is shown in the example network diagram in
Figure 3. The diagram shows examples of the types of applications that may be integrated, along with one
form of network topology. In each case, the application modeling approach is shown, as well as the LAN/
WAN technology. Note that many alternate applications, topologies, and modeling approaches are possible
within the UCA framework. This diagram is simply to illustrate general communications concepts.
The corporate network is shown using DAIS, which provides for seamless integration of relational database
models across multiple vendors. TASE.2 models are also used, in particular for scheduling and accounting
data provided by the EMS. The underlying protocols used within the corporate LAN environment are most
likely 7-layer UCA using TCP/IP, possibly coexisting with OSI protocols.

IEEE-SA
The example shows a WAN link between the corporate LAN and the control center through routers employ-
ing network level security. Note that UCA also provides for application layer encryption, providing addi-
tional security procedures even across unsecured networks. The UCA 7-layer profiles (OSI and/or TCP/IP)
are employed across these links.
The control center network environment is likely based on 7-layer UCA, containing a mix of OSI and IP
protocols, supporting a variety of systems ranging from personal computers to large-scale machines. Net-
work connections are also likely with neighboring control areas and power pools (not shown). The TASE.2
(ICCP) models within UCA were designed for use within and among control center environments.
The data object models for communications links between control centers and power plants are also
included in the TASE.2 specifications. These models include capabilities for reporting of status and avail-
ability, maintenance scheduling, forecasting, and exchange of various curve data (such as heat rate curves).
Within the power plant itself, communications between the plant DCS and plant floor equipment will be
based on CASM device level models. The plant floor communications makes use of LAN technology, as
well as possibly various field bus schemes, running 7- and/or 3-layer profiles.
Transmission substations (as well as high-end distribution substations) may incorporate LAN based net-
works, typically using 7-layer UCA profiles. The example shows the substation controlled by a substation
host, although this is not required. Substation hosts may be anything from an RTU to a local computer, and
may provide a first level control mechanism. The communication between the control center and a substa-
tion host may be based on models from either TASE.2 (if the host is operating as a SCADA submaster), or
CASM (if the raw device data is passed up). Substation IEDs interface to the network using CASM-based
models as defined in Part 4 of TR 1550 (GOMSFE). Substations may also be connected to the corporate net-
work using routers, with the Substation Host, if provided, connected only to the substation network.
Distribution substations and feeder networks provide SCADA data through WAN connections back to the
control center. This WAN connection may employ any of a variety of media, from low bandwidth radio to
high-speed fiber or direct connections. The link to the distribution network may employ a network interface
(see Figure 3) that could be a simple bridge (linking dissimilar media), radio repeater, or data concentrator
(such as an RTU). In many cases, no interface unit is required, such as when the control center directly com-
municates to the IEDs over radio. The communication within a distribution network is based on the
GOMSFE models, operating over 7- or 3-layer UCA profiles.
A variety of architectures are possible for customer interface communications. Example applications include
meter reading, electronic billing, power quality monitoring, outage detection, remote connect/disconnect,
and demand side management. The network infrastructure can also support a variety of other customer ser-
vices. The UCA modeling of customer interface devices will employ the CASM services, which can be used
over 7- or 3-layer profiles over a variety of media.

IEEE-SA
Corporate
Customer Interface
Automated Energy Residential Commercial Industrial
Engineering Accounting
Mapping Customer Customer Customer
Corporate LAN UCA LAN
DAIS and Security Data

Router Acquisition CASM Models
TASE.2 Models Customer Interface
Corporate WAN Metering WAN

TASE.2 Models CASM Models
Operation Control Center Distribution Substation and Feeders
Security
SCADA EMS Router IED RTU IED
IED
SCADA
Control Center LAN WAN Field Multidrop Network
Network
Interface
TASE.2 Data
DMS Acquisition
Models
CASM CASM Models
(GOMSFE)
Models
Security WAN (GOMSFE)
TASE.2 Models
Power Plant Transmission Substation

Plant
DCS IED IED
IED IED IED
SCADA
WAN
TASE.2 Substation LAN
Plant Control LAN Models
or Substation
IED IED Host IED
CASM CASM Models
CASM Models (GOMSFE)
(Power Plant) (GOMSFE)
Figure 3: UCA Integrated Network example

Architecture (UCA )
TM
Version 2.0
Volume 1
Part 1:
Part 2:
UCATM Profiles
Part 3:
Mapping to MMS
Published by


Palo Alto, CA, USA

Part 2: UCATM Profiles
Keywords: communications, control centers, digital systems, distribution automation, power

plants
IEEE-SA
Introduction
The purpose of this Part 2 of IEEE-SA TR 1550 is to identify a suite of internationally recognized open com-
munication protocols that meet the requirements of the utilities industry, including electric, gas, and water.
However, while the exact operational models and device object models may be specific to a utility industry,
the protocols are not and may be applicable to any industry with roughly the same kinds of constraints as
found in the utilities. This technical report provides a standard reference for the development and/or acquisi-
tion of UCA-compliant communication systems, equipment, and services.
This Part 2 of IEEE-SA TR 1550 has been developed during the course of the UCA project. The project is a
part of the larger Integrated Utility Communications (IUC) program initiated by the Electric Power Research
Institute (EPRI) with the intention of promoting interoperability between computer systems supplied to the
electric utility industry. In initiating and promoting this work, EPRI has been providing education to the
electric utility industry users on the UCA, and has been disseminating information to the vendor community
about the industry's commitment to adopting the UCA as a strategic direction. This technical report will fur-
ther promote the UCA by providing a procurement tool for users and a clear specification for manufacturers
on which to base strategic product development.
The first phase of the project identified the information requirements within an electric utility. To ensure that
the requirements gathered were representative of the entire industry, a series of interviews were conducted
with 14 utility companies across the country. The results of this work were presented in the first of the UCA
project deliverables, the functional definition, and reviewed at a workshop held on 21-22 March 1989, in St.
Charles, Illinois. Representatives from over 40 utility companies participated in the two-day workshop.
In August 1989, two host utilities, Pacific Gas & Electric Company and Houston Lighting and Power Com-
pany, were selected to participate on the project. The host utilities provided an industry perspective on a day-
to-day basis. This participation was invaluable in confirming the information requirements gathered and
identifying the communication requirements associated with these information flows.
Technical focus teams (TFTs), representing industry experts in each of the six defined utility functional areas
(i.e., corporate, power plants, control centers, transmission, distribution automation, and customer interface),
were formed to review the communications requirements gathered at the host utilities and broaden these
requirements to reflect an industry-wide perspective. Twenty-one participants from 11 different utilities
comprised the TFTs. The results of this phase of the project are documented in the EPRI EL-7547,
Volume 2: UCA Communications Requirements.
Subsequent phases of UCA work assessed open communication standards in light of the communication
requirements gathered and selected standards for inclusion as part of the UCA Version 1.0 specification. A
multi-volume users guide, which documents the UCA business case migration strategies and usage and pro-
curement guidelines, has also been developed to support the UCA specification. Valuable input into the busi-
ness case work has been provided by the host utilities as part of their role on the UCA project.
The overall project findings were presented to utilities and vendors in August 1990. Utility seminars were
held in San Francisco on 23 August 1990, and in Atlanta on 27 August 1990. The UCA was formally
released to the vendor community on 31 August 1990.
The effort to update UCA Version 2.0 began as part of the ongoing work of the MMS Forum and of other
EPRI projects and demonstrations. The EPRI projects in the areas of control center (TASE.2, also called
ICCP) and substation (RP3599) communication provided valuable extensions to the application of manufac-
turing message specification (MMS) over and above the profile work. The EPRI-sponsored Substation Initia-
tive Project provided significant input in the areas of object modeling and profile development. EPRI
sponsored several demonstration projects: North States Power, Oglethorpe Power Cooperative, United
Power Association, and City Public Service of San Antonio. These projects tested the profiles and indicated

IEEE-SA
PART 2: PROFILES TR 1550-1999
areas where improvements could be made or tested new standards that had been approved since UCA Ver-
sion 1.0. Several factors precipitated this work:
New versions of the standards were available that provided considerable improvement in perfor-
mance. This was especially true with the upper layers where much more efficient encoding schemes
were available and other enhancements such as FastByte considerably reduced overhead.
There were new network technologies to be accommodated in the lower layers of the reference
model.
The inclusion of additional transport mechanisms, such as Internet protocols.
The availability of work done in the Forum to create object models for the major elements of a
utility network, such as intelligent electronic devices (IEDs) and remote terminal units (RTUs), and
functional models, such as report by exception.
Additional input to this Part 2 of IEEE-SA TR 1550 was developed based on extensive public comment
within the EPRI-sponsored MMS Forum, as well as from technical review and implementation work within
a number of UCA pilot/demonstration projects. In addition, the UCS Working Group (now the MMS Forum
Control Center Working Group) and the ICCP demonstration project have made significant contributions.
Future additions to UCA are envisioned, based on experience with UCA Version 2.0emerging network
technologies, and further requirements and implementation definition in other functional areas beyond the
focus of the MMS Forum.

IEEE-SA
Contents
1. Overview........................................................................................................................... 2-1
1.1 Scope.......................................................................................................................... 2-1

1.2 OSI Overview............................................................................................................ 2-1
1.3 Document Organization ........................................................................................... 2-3
2. References ........................................................................................................................ 2-4
2.1 American National Standards Institute (ANSI)..................................................... 2-4

2.2 Internet Engineering Task Force (IETF)................................................................. 2-4
2.3 Electronic Industries Association (EIA) .................................................................. 2-5
2.4 International Organization for Standardization (ISO) .......................................... 2-5
2.5 International Telecommunications Union (ITU) .................................................... 2-9
2.6 National Institute of Standards and Technology (NIST) ..................................... 2-11
3. UCA Specification Overview ......................................................................................... 2-11
3.1 UCA Architectural Models ..................................................................................... 2-12

3.2 Specification Approach ........................................................................................... 2-15
4. UCA 7-Layer Specification ............................................................................................ 2-16
4.1 A-Profiles................................................................................................................. 2-17

4.2 T-Profiles ................................................................................................................. 2-23
4.3 L-Profiles ................................................................................................................. 2-27
5. UCA 3-Layer Specification ............................................................................................ 2-30
5.1 3-Layer Connection-mode Specification ................................................................ 2-31

5.2 Connection-mode and Connectionless-mode Application Layer .......................... 2-32
5.3 3-Layer Connectionless Specification .................................................................... 2-33
6. Guidelines ...................................................................................................................... 2-34
6.1 Overview ................................................................................................................. 2-34

6.2 Naming Guidelines................................................................................................. 2-34
6.3 Addressing and Registration Guidelines............................................................... 2-36
6.4 Multicast ................................................................................................................. 2-39
6.5 Network Management............................................................................................ 2-41
6.6 Security Architecture ............................................................................................. 2-43
6.7 Bridging Considerations ........................................................................................ 2-46
6.8 7-Layer/3-Layer Interworking ............................................................................... 2-47
6.9 Conformance and Interoperability Testing ........................................................... 2-48
Appendix A: UCA ASO Specification .................................................................................. 2-50
A.1 Definitions........................................................................................................ 2-50
A.2 Overview .......................................................................................................... 2-51
iv Copyright 1999 IEEE. All rights reserved.

IEEE-SA
A.2.1 The UCA ASO ......................................................................................... 2-51

A.2.2 UCA Service Definitions ........................................................................ 2-52
A.2.3 State Definitions for the Service............................................................ 2-52
A.2.4 State Definitions for the Control Function............................................ 2-53
A.3 Application Context......................................................................................... 2-54
A.4 Presentation Context ...................................................................................... 2-55
A.4.1 Abstract Syntax ...................................................................................... 2-55

A.4.2 Transfer Syntax...................................................................................... 2-55
A.4.3 Presentation-Context-IDs ...................................................................... 2-56
A.5 UCA Client ASO .............................................................................................. 2-56
A.5.1 UCA Client ASO Service Definition ...................................................... 2-56

A.5.2 UCA Client ASO Control Function Specification.................................. 2-59
A.6 UCA Server ASO ............................................................................................. 2-63
A.6.1 UCA Server ASO Service Definition...................................................... 2-63

A.6.2 UCA Server ASO Control Function Specification................................. 2-66
A.7 Supporting Service Mappings......................................................................... 2-70
A.7.1 Presentation Connection-mode2-70

A.7.2 Presentation Connectionless-mode........................................................ 2-73
A.7.3 Data Link Service (3-Layer)................................................................... 2-74
Appendix B: UCA Station Management ............................................................................. 2-77
B.1 UCA Station Management Service Procedures ............................................. 2-77
B.1.1 Prepare Service....................................................................................... 2-77

B.1.2 Prepare Service Procedure ..................................................................... 2-78
B.1.3 Measure Service...................................................................................... 2-78
B.1.4 Measure Service Procedures .................................................................. 2-78
B.1.5 Synchronize Service............................................................................... 2-79
B.1.6 Synchronization Error Responses......................................................... 2-80
B.1.7 Synchronize Service Procedures ........................................................... 2-80
B.1.8 Time Synchronization State Diagrams ................................................ 2-81
B.2 UCA Station Management Protocol ............................................................... 2-81
B.3 Mapping of Service Primitives to Protocol ..................................................... 2-83
Appendix C: Security Transformation ASE for MMS ....................................................... 2-84
Copyright 1999 IEEE. All rights reserved. v

1. Overview
The diversity of the electric utility industrys communication requirements necessitates a flexible architec-
ture. UCA has adopted the open systems interconnection (OSI) reference model to structure its architecture.
The UCA does not define new protocols but specifies the use of existing protocols with particular sets of
parameters and options called profiles. An architecture is described in terms of three kinds of these pro-
files: A-profiles, spanning the upper 3 layers (application, presentation, and session); T-profiles, spanning the
middle 2 layers (transport and network); and L-profiles, spanning the lower two layers (data link and physi-
cal). Any architecture (including UCA) defines one or more of each kind of these profiles. These profiles can
then be mixed and matched as required to achieve the goals of the network.1
1.1 Scope
The UCA is designed to provide seamless integration across all areas of the utility, including corporate net-
works, power plants, control centers, transmission, distribution, and customer interface.
1.2 OSI Overview

OSI standards and IETF RFCs (request for comment) are the foundation for TR 1550. These communication
standards enable dissimilar, heterogeneous computer systems to successfully interoperate. This allows end
users (whether an application program, device, or person) on one processor to communicate with end users
on another processor without specific knowledge of the communication characteristics of the other platform.
The benefits of such an approach include increased communications capability, reduced networking soft-
ware development costs, and greater availability of competitive products by computer vendors.
1.2.1 OSI Reference Model
The OSI reference model provides a generalized description of the functions needed to perform reliable data
communications between heterogeneous systems. The model is organized as a series of seven layers, each
addressing specific communications functions. Layers are built upon each other, such that any given layer
offers certain services to the higher layers, shielding the above layers from the details of how the offered ser-
vices are actually implemented, and using the services of the next lower layer. Each layer carries on a con-
versation with its peer, the corresponding layer on another machine. In general, layers one through four,
(physical, data link, network, and transport respectively) define the functions necessary for end-system-to-
end system movement of data; and layers five through seven (session, presentation, and application) define
user-oriented functionality. The seven layers are described below.
1.2.1.1 Physical
The physical layer provides the data path between communicating data link entities. It is responsible for the
transparent transmission of an arbitrary bit stream between adjacent data link nodes over some form of phys-
ical media.
1The only constraint on these combinations is that connection-mode A-profiles must be used with connec-
tion-mode T-profiles; and similarly connectionless A-profiles, with connectionless T-profiles.

IEEE-SA
1.2.1.2 Data Link
The data link layer is generally responsible for the error-free transmission of data between two adjacent OSI
systems. It can accomplish this by performing such functions as error checking and recovery, sequence
checking, media access control, and flow control.
1.2.1.3 Network
The network layer provides the routing and relaying of data between the communicating systems. To accom-
plish these functions, it uses knowledge of the network topology to deliver the data to the proper end system.
1.2.1.4 Transport
The transport layer is responsible for the end-to-end delivery of data packets between communicating ses-
sion entities. It uses the routing services of the network layer and adds functionality for moving the data effi-
ciently, insuring its correctness and order, and insulating the session layer from data delivery concerns.
1.2.1.5 Session
The session layer provides services to organize and manage dialogue session connections between end users
such that data and control information are transferred in an organized and synchronized manner. This is done
by providing mechanisms to establish, maintain, and terminate sessions connections.
1.2.1.6 Presentation
The purpose of the presentation layer is to provide for the common representation of data between end sys-
tems. This is achieved through the use of abstract syntaxes, which describe the data types and acceptable val-
ues to be transferred, and the use of transfer syntaxes, which are encoding rules defining the bit level
representation required to encode the data.
1.2.1.7 Application
The application layer is responsible for providing the window, or access, to the services provided by an open
systems communications architecture. It provides both common elements for the management and activation
of communication resources and specific elements for maintaining the context of the communication. The
combination of these services allow, for example, the underlying OSI-based communication resources to
support the transfer of files between two end systems and interactive terminal access from a terminal to a
remote host.
1.2.1.8 Network Components
Two types of systems are defined by OSI: end systems and intermediate systems (see Figure 1). An end sys-
tem (ES) implements all seven layers of protocol and originates or receives data messages. An intermediate
system (IS) implements physical, data link, and network layer protocols and allows interconnections
between two or more subnetworks. Subnetworks include both local area networks and wide area networks in
which a consistent access method is used to interconnect end systems and intermediate systems.

IEEE-SA
LAYER End System A End System B
Application 7 7
Presentation 6 6
Peer Protocols
Session 5 5
Transport 4 4
Intermediate System X Intermediate System Y
Network 3 3 3 3
Data Link
2 2 2' 2' 2" 2"
1 1 1' 1' 1" 1"

Physical
Physical Media
Figure 1: OSI Network Components
1.3 Document Organization

The remaining sections of Part 2 of IEEE-SA TR 1550 are organized as follows:
Section 3: Provides an overview to this document and provides information relating to the specification
approach.
Section 4: Provides the specification of standards to be implemented for compliance with the UCA 7-layer
specification.
Section 5: Provides the specification of standards and mappings to be implemented for compliance with the
UCA 3-layer architecture.
Section 6: Provides guidelines relating to implementing UCA conformant systems.
The appendices cover the following topics:
Appendix A: Defines the relationships and mappings of the upper layer architecture.
Appendix B: Specifies utility-specific protocol, used for UCA time synchronization.
Appendix C: Specifies the procedures for implementing security.

IEEE-SA
2. References
This technical report shall be used in conjunction with the following publications.
2.1 American National Standards Institute (ANSI)

ANSI T1.259-1997, Security Transformation Application Service Element for ROSE.
ANSI T1.403-1989, Carrier-to-Customer InstallationDS1 Metallic Interface.
ANSI T1.601-1988, Integrated Services Digital NetworkBasic Access Interface for Use on Metallic
Loops for Application on the Network Side of the NT-Layer 1 Specification.
ANSI T1.605-1988, Integrated Services Digital NetworkBasic Access Interface at S and T Reference
Points-Layer 1 Specification.
ANSI X3T9.5-1990, Fiber Distributed Data InterfaceStation Management (SMT)Working Document

84-49.
2.2 Internet Engineering Task Force (IETF)

RFC 768 (28 Aug 1980), User Datagram Protocol. J. Postel.
RFC 791 (1 Sept 1981), Internet Protocol. J. Postel.
RFC 793 (1 Sept 1981), Transmission Control Protocol. J. Postel.
RFC 1006 (1 May 1987), ISO transport services on top of the TCP: Version 3. M.T. Rose, D.E. Cass.
RFC 1070 (1 Feb 1989), Use of the Internet as a subnetwork for experimentation with the OSI network
layer. R.A. Hagens, N.E. Hall, M.T. Rose.
RFC 1155 (1 May 1990), Structure and identification of management information for TCP/IP-based inter-
nets. M.T. Rose, K. McCloghrie.
RFC 1157 (1 May 1990), Simple Network Management Protocol (SNMP). J.D. Case, M. Fedor, M.L.
Schoffstall, C. Davin.
RFC 1212 (1 Mar 1991), Concise MIB definitions. M.T. Rose, K. McCloghrie.
RFC 1213 (1 Mar 1991), Management Information Base for Network Management of TCP/IP-based inter-
nets:MIB-II. K. McCloghrie, M.T. Rose.
RFC 1240 (1 June 1991), OSI connectionless transport services on top of UDP: Version 1. C. Shue, W. Hag-
gerty, K. Dobbins.
RFC 1531 (1 October 1993), Dynamic Host Configuration Protocol: R. Droms.
RFC 1597 (March 1994), Address Allocation for Private Internets. Y. Rekhter, B. Moskowitz, D. Karrenberg
& G. de Groot.

IEEE-SA
2.3 Electronic Industries Association (EIA)

EIA-232-D, Interface between data terminal equipment and data communication equipment employing
serial binary data interchange.
EIA-422-A (December 1978), Electrical characteristics of balanced voltage digital interface circuits.
2.4 International Organization for Standardization (ISO)

ISO 3166-1: 1997, Codes for the Representation of Names of Countries.
ISO 7498: 1994, [ITU-T X.200 (1994)], Open Systems InterconnectionBasic Reference Model.
ISO 7498-2: 1989, Open Systems InterconnectionBasic Reference ModelPart 2: Security Architecture.
ISO 7498-3: 1997, [ITU-T X.650 (1992)], Information processing systemsOpen Systems Interconnec-
tionBasic Reference ModelPart 3: Naming and Addressing.
ISO 7776: 1995, High-level Data Link Control ProceduresDescription of the X.25 LAPB-Compatible
DTE Data Link Procedure.
ISO 8073: 1997, Connection Oriented Transport Protocol Specification.
ISO 8208: 1995, X.25, Packet Level Protocol for Data Terminal Equipment.
ISO 8348: 1996, Network Service Definition.
ISO 8473: 1988, Protocol for Providing the Connectionless-mode Network Service.
ISO 8571-1: 1988, File Transfer, Access and ManagementPart 1: General Introduction.
ISO 8571-2: 1988, File Transfer, Access and ManagementPart 2: Virtual Filestore Definition.
ISO 8571-3: 1988, File Transfer, Access and ManagementPart 3: File Service Definition.
ISO 8571-4: 1988, File Transfer, Access and ManagementPart 4: File Protocol Specification.
ISO 8571-5: 1990, File Transfer, Access and ManagementPart 5: Protocol Implementation Conformance
Statement Proforma.
ISO 8802-2: 1998, Local Area NetworkPart 2: Logical Link Control.
ISO 8802-3: 1996, Local Area NetworkPart 3: Carrier Sense Multiple Access with Collision Detection.
ISO 8802-4: 1990, Local area NetworkPart 4: Token-Passing Bus Access Method and Physical Layer
Specification.
ISO 8802-5: 1995, Local area NetworkPart 5: Token Ring Access Method and Physical Layer Specification.
ISO 8878: 1992, Use of X.25 to Provide the OSI Connection-mode Network Service.
ISO 9314-1: 1989, Fiber Distributed Data InterfacePart 1: Physical Layer Protocol (PHY).

IEEE-SA
ISO 9314-2: 1989, Fiber Distributed Data InterfacePart 2: Token Ring Media Access Control (MAC).
ISO 9542: 1988, End System to Intermediate System Routing Exchange Protocol for Use in Conjunction
with the Protocol for Providing the Connectionless-mode Network Service.
ISO/IEC 4335: 1993, High-level Data Link Control Elements of Procedures.
ISO/IEC 7498-4: 1989, Open Systems InterconnectionBasic Reference ModelPart 4: Management

Framework.
ISO/IEC 8327: 1996, Basic Connection Oriented Session Protocol Specification.
ISO/IEC 8602: 1987, Information processing systemsOpen Systems InterconnectionProtocol for pro-
viding the connectionless-mode transport service.
ISO/IEC 8649: 1996, [ITU-T X.226 (1992)], Information processing systemsOpen Systems Interconnec-
tionService Definition for the Association Control Service Element.
ISO/IEC 8650-1: 1996, [ITU-T X.227 (1992)], Protocol Specification for the Association Control Service
Element.
ISO/IEC 8823: 1994, Connection Oriented Presentation Protocol Specification.
ISO/IEC 8824-1: 1995, [ITU-T X.208 (1993)], Specification of Abstract Syntax Notation One (ASN.1).
ISO/IEC 8825-1: 1995, Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1).
ISO/IEC 8886: 1996, Data Link Service Definition for Open Systems Interconnection.
ISO/IEC 9066-2: 1989, Reliable TransferPart 2: Protocol Specification.
ISO/IEC 9041: 1997, Basic Class Virtual Terminal Protocol.
ISO/IEC 9072-2: 1989, Remote OperationsPart 2: Protocol Specification.
ISO/IEC 9314-3: 1990, Fiber Distributed Data InterfacePart 3: Physical Layer Medium Dependent
(PMD).
ISO/IEC 9506-1: 1990, Manufacturing Message SpecificationPart 1: Service Definition.
ISO/IEC 9506-2: 1990, Manufacturing Message SpecificationPart 2: Protocol Specification.
ISO/IEC 9545: 1994, Information technologyOpen Systems InterconnectionApplication Layer

Structure.
ISO/IEC 9548-1: 1996, Information technologyOpen Systems InterconnectionConnectionless Session

protocol: Protocol specification.
ISO/IEC 9574: 1992, Provision of the OSI Connection-mode Network Service by Packet Mode Terminal
Equipment Connected to an Integrated Services Digital Network (ISDN).
ISO/IEC 9576: 1995, Information technologyOpen Systems InterconnectionConnectionless Presenta-

tion protocol: Protocol Specification.

IEEE-SA
ISO/IEC TR 9577: 1996, Information technologyProtocol Identification in the network layer
ISO/IEC 9579: 1999, Information technologyRemote Database Access for SQL
ISO/IEC 9594-1: 1995, The DirectoryPart 1: Overview of Concepts, Models, and Services.
ISO/IEC 9594-2: 1995, The DirectoryPart 2: Models.
ISO/IEC 9594-3: 1995, The DirectoryPart 3: Abstract Service Definition.
ISO/IEC 9594-4: 1995, The DirectoryPart 4: Procedures for Distributed Operation.
ISO/IEC 9594-5: 1995, The DirectoryPart 5: Protocol Specifications.
ISO/IEC 9594-6: 1995, The DirectoryPart 6: Selected Attribute Types.
ISO/IEC 9594-7: 1995, The DirectoryPart 7: Selected Object Classes.
ISO/IEC 9594-8: 1995, The DirectoryPart 8: Authentication Framework.
ISO/IEC 9594-9: 1995, Information technologyOpen Systems InterconnectionThe Directory:

Replication.
ISO/IEC DIS 9594-10, Information technologyOpen Systems InterconnectionThe DirectoryPart 10:

Use of Systems Management for Administration of the Directory.
ISO/IEC 9595: 1991, Common Management Information Service Definition.
ISO/IEC 9596-1: 1991, Common Management Information Protocol Specification.
ISO/IEC 10021-1: 1990, Message Oriented Text Interchange SystemPart 1: System and Service Overview.
ISO/IEC 10021-2: 1996, Message Oriented Text Interchange SystemPart 2: Overall Architecture.
ISO/IEC 10021-3: 1990, Message Oriented Text Interchange SystemPart 3: Abstract Service Definition
Conventions.
ISO/IEC 10021-4: 1997, Message Oriented Text Interchange SystemPart 4: Message Transfer System:
Abstract Service Definition and Procedures.
ISO/IEC 10021-5: 1996, Message Oriented Text Interchange SystemPart 5: Message Store: Abstract
Service Definition.
ISO/IEC 10021-6: 1996, Message Oriented Text Interchange SystemPart 6: Protocol Specifications.
ISO/IEC 10021-7: 1997, Message Oriented Text Interchange SystemPart 7: Interpersonal Messaging
System.
ISO/IEC 10035: 1995, [ITU-T X.237 (1995)], Information Processing SystemsOpen Systems Intercon-
nectionConnectionless ACSE Protocol to provide to Provide the Connectionless ACSE Service.
ISO/IEC 10165-1: 1993, Information technologyOpen Systems InterconnectionManagement Informa-

tion ServicesStructure of management information: Management Information Model.

IEEE-SA
ISO/IEC 10165-2: 1992, Information technologyOpen Systems InterconnectionStructure of manage-

ment information: Definition of management information.

ment informationPart 4: Guidelines for the definition of managed objects.

ment information: Generic management information.

ment information: Requirements and guidelines for implementation conformance statement proformas asso-
ciated with OSI management.

ment information: General relationship model.
ISO/IEC 10589: 1992, Information technologyTelecommunications and information exchange between

systemsIntermediate system to Intermediate system intra-domain routeing information exchange protocol
for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473).
ISO/IEC 10731: 1994, [ITU-T X.210 (1993)], Information processing systemsOpen Systems Intercon-
nectionOSI Service Conventions.

systemsElements of management information relating to OSI Network Layer standards.

systemsElements of Management Information Related to OSI Transport Layer Standards.

systemsElements of management information related to OSI Data Link Layer standards.

systemsProtocol for exchange of inter-domain routeing information among intermediate systems to sup-
port forwarding of ISO 8473 PDUs.
ISO/IEC 11586: 1996, [ITU-T X.830 (1995)], Information TechnologyOpen Systems Interconnection
Generic Upper Layers Security.

systemsHigh-level data link (HDLC) procedures.
ISO/IEC 13239: 1997/DAM1, Information technologyTelecommunications and information exchange

between systemsHigh-level data link (HDLC) proceduresAmendment 1: Non-basic frame formats
General.

between systemsHigh-level data link (HDLC) proceduresAmendment 2Non-basic frame formats
Provision for multiple address fields.

between systemsHigh-level data link (HDLC) proceduresAmendment 3Provision for 8-bit FCS.

IEEE-SA

between systemsHigh-level data link (HDLC) proceduresAmendment 4: Frame format field.

between systemsHigh-level data link (HDLC) proceduresAmendment 5: Intra-frame timeout.

between systemsHigh-level data link (HDLC) proceduresAmendment 6: Header check sequence.
ISO/IEC DIS 13239, Information technologyTelecommunications and information exchange between

systemsHigh-level data link control (HDLC) procedures.
2.5 International Telecommunications Union (ITU)

ITU-T I.441-LAPD (Q.921) (1988), ISDN User-Network Interface Data link Layer Specification.
ITU-T V.35 (1976), Data transmission at 48 Kilobits per second using 60-108 kHz group band circuits.
ITU-T X.21(1984), Interface between Data Terminal Equipment (DTE) and Data Circuit-Terminating
Equipment (DCE) for synchronous operation on public data networks.
ITU-T X.21bis (1984), Use on Public Data Networks of Data Terminal Equipment (DTE) which is designed
for interfacing to synchronous V-Series modems.
ITU-T X.25 (1980), Interface between Data Terminal Equipment (DTE) and Data Circuit-terminating
Equipment (DCE) for terminals operating in the packet mode and connected to public data networks by ded-
icated circuit.
ITU-T X.200 (1994), ISO 7498:1994 Information processing systems Open Systems Interconnection
Basic Reference Model.
ITU-T X.208 (1993), ISO 8824, Information TechnologyOpen Systems InterconnectionAbstract Syn-
tax Notation One (ASN.1).
ITU-T X.210 (1993), ISO10731:1993, Information processing systemsOpen Systems Interconnection

OSI Service Conventions.
ITU-T X.226 (1992), ISO 8649: 1988, Information processing systemsOpen Systems Interconnection
Service Definition for the Association Control Service Element.
ITU-T X.227 (1992), ISO 8650: 1988 Information processing systems Open Systems Interconnection
Protocol specification for the Association Control Service Element.
ITU-T X.237 (1995), ISO/IEC 10035 Information Processing Systems Open Systems Interconnection
Connectionless ACSE Protocol to provide to Provide the Connectionless ACSE Service.
ITU-T X.400 (1984), Message Handling Systems: System Model-Service Elements. (Red Book)
ITU-T X.400 (1988), Message Handling System: System Model-Service Elements.
ITU-T X.401 (1984), Message Handling Systems: Basic Service Elements and Optional User Facilities.
(Red Book)

IEEE-SA
ITU-T X.402 (1988), Message Handling System: Overall Architecture.
ITU-T X.407 (1988), Message Handling System: Abstract Service Definition Conventions.
ITU-T X.408 (1984), Message Handling Systems: Encoded Information Type Conversion Rules. (Red
Book)
ITU-T X.409 (1984), Message Handling Systems: Presentation Transfer Syntax Notation. (Red Book)
ITU-T X.410 (1984), Message Handling Systems: Remote Operations and Reliable Transfer Server. (Red
Book)
ITU-T X.411 (1984), Message Handling Systems: Message Transfer Layer. (Red Book)
ITU-T X.411 (1988), Message Handling System: Message Transfer System: Abstract Service Definition.
ITU-T X.413 (1988), Message Handling System: Message Store: Abstract Service Definition.
ITU-T X.419 (1988), Message Handling System: Protocol Specifications.
ITU-T X.420 (1984), Message Handling Systems: Interpersonal Messaging User Agent Layer. (Red Book)
ITU-T X.420 (1988), Message Handling System: Interpersonal Messaging System.
ITU-T X.500 (1988), The DirectoryOverview of Concepts, Models and Services.
ITU-T X.501 (1988), The DirectoryModels.
ITU-T X.509 (1988), The DirectoryAuthentication Framework.
ITU-T X.511 (1988), The DirectoryAbstract Service Definition.
ITU-T X.518 (1988), The DirectoryProcedures for Distributed Operation.
ITU-T X.519 (1988), The DirectoryProtocol Specifications.
ITU-T X.520 (1988), The DirectorySelected Attribute Types.
ITU-T X.521 (1988), The DirectorySelected Object Classes.
ITU-T X.650 (1992), ISO 7498-3:1988, Information processing systemsOpen Systems Interconnection
Basic Reference Model Part 3: Naming and Addressing.
ITU-T X.691 (1993), ISO 8825, Information TechnologyOpen Systems InterconnectionSpecification of

Basic Encoding Rules for Abstract Notation One (ASN.1)Part 2 Packed Encoding Rules.
ITU-T X.830 (1995), ISO 11586, Information TechnologyOpen Systems Interconnection Generic
Upper Layers Security.
ITU-T Recommendation G.851.1 (11/96), Management of the transport networkApplication of the RM-
ODP framework.
ITU-T Recommendation G.852.1 (11/96), Management of the transport networkEnterprise viewpoint for
simple subnetwork connection management.
ITU-T Recommendation G.853.1 (11/96), Common elements of the information viewpoint for the manage-
ment of a transport network.

IEEE-SA
ITU-T Recommendation G.853.2 (11/96), Subnetwork connection management information viewpoint.
2.6 National Institute of Standards and Technology (NIST)

Stable Implementation Agreements for Open Systems Interconnection Protocols (December 1994).
Working Implementation Agreements for Open Systems Interconnection Protocols (December 1994).
3. UCA Specification Overview

The following tables summarize the profiles defined in this specification. Table 1 shows the profile combina-
tions that are defined for both ISO and IETF connection-mode use. Table 2 shows the 7 layer connectionless
mode profiles. Table 3 summarizes the connection- and connectionless-mode profiles for use in 3 layer con-
figurations. Each of the profile configurations are defined in more detail throughout this section. Note that in
all cases the physical layer standards are not shown, as they generally determined by the data link layer
choices.
Table 1: Connection Mode 7 Layer Profiles
Connection Mode 7 Layer
ISO 9506:MMS ISO 9594: ISO 9595: ITU-T-X.419: DAIS

ISO 8650: Direct CMIP MHS ISO 9579:1999
Appl
COACSE ISO 9072: ISO 9072: ITU-T X.410: RDA
ROSE ROSE RTSE ISO 8650: COACSE
ISO 8823:CO Presentation (may include Addendum 3: FastByte)
Pres ISO 8824:ASN.1
ISO 8825:BER
Sess ISO 8327:CO Session (may include Addendum 3: FastByte)
ISO 8073:COTS RFC 1006 ISO 8073:COTS

RFC ISO 8473:CLNP
Trans
793:TCP RFC 1070
RFC 768:UDP
Netw ISO 8473:CLNP ISO 8473:CLNP ISO 8473:CLNP RFC 791:IP RFC 791:IP
ISO 8208: ITU-T ISO 8208:

X.25 Q.931: X.25
ISDN
DL ISO 8802-2:LLC ISO 7776:LAPB ITU-T Q.921:LAPD

IEEE-SA
Table 2: Connectionless Mode 7 Layer Profiles
Connectionless Mode 7 Layer
ISO 9506:MMS
Appl
ISO 10035:CL ACSE
ISO 9576-1:CL Presentation
Pres ISO 8824:ASN.1
ISO 8825:BER
Sess ISO 9548:CL Session
ISO 8602:CLTP ISO 8602:CLTP

Trans RFC 1240
RFC 768:UDP
Net ISO 8473:CLNP RFC 791:IP
DL ISO 8802-2:LLC
Table 3: 3 Layer Profiles
Connection-Mode 3 Layer Connectionless-Mode 3 Layer

ISO 9506:MMS ISO 9506:MMS
Appl
ISO 8650: CO ACSE ISO 10035:CL ACSE
Pres
Sess
Trans
Netw
ISO 8802-2:LLC ISO 8802-2:LLC
DL
ISO DIS 13239:(non basic frame) ISO DIS 13239: (non basic frame)
3.1 UCA Architectural Models

The UCA requirements are accommodated by two architecture models. The first of these uses the full 7-
layer OSI reference model. This model is intended to provide full communications functionality and to be
capable of supporting the majority of the industrys data requirements by operating over a variety of lower
layer profiles including OSI and Internet. The second model is a 3-layer architecture that uses the services
provided by the application layer, data link layer, and physical layer of the OSI reference model, essentially
an application protocol operating over an L-profile. This model is intended to address a limited but signifi-
cant set of communications requirements within the industry.
Each of these models supports both connection- and connectionless-modes of operation. Connection-mode
operation means that some procedures are employed to ascertain the ability of the end-systems and the inter-
vening channel to send and receive messages. In addition, messages are delivered in sequence and (typi-
cally) are acknowledged. The connectionless-mode of operation means that no connection state is
maintained; messages may be delivered in any order, and are (typically) unacknowledged. In UCA, the con-
nectionless-modes of operation is currently limited to use in multicast functions of distributed control using
MMS.

IEEE-SA
The communication services provided by this architecture will allow a variety of different types of data
transfer among the open systems conforming to this technical report. These services are defined by the
protocols included at the application layer (layer 7) of this model. The UCA specification provides the
following types of application services:
Remote file transfer, access, and management (FTAM)

Store and forward messaging/electronic mail (MHS)
Messaging services for devices in real-time networking environments (MMS)
Additional application layer services are specified to support the data transfer services described above:
Identification and location of network resources (directory)

Exchange of network management information (CMIP)
Database Access Integration Services (DAIS)
Remote Database Access protocol (RDA) (ISO/IEC 9579-1: 1993)
Structured Query Language (SQL) (ISO/IEC 9075:1992)
Utility-specific services that are not supported by existing standards are included in Appendix B. These ser-
vices are defined to operate only in a 3-layer architecture. At the time of this publication, the only service
defined within UCA station management is the UCA time synchronization service. The UCA station man-
agement protocol will be an area of future standardization efforts.
Data interchange with real-time databases in control centers, power plants, and other SCADA and EMS sys-
tems is defined in the following specifications:
IEC 870-6-802: TASE.2 Object Models, Version 1996-04,which defines the object models used to
represent real-time data, schedules, and accounting information used in these environments
IEC 870-6-503: TASE.2 Services and Protocol, Version 1996-04, which defines the specific use of
the MMS protocol to support those applications
IEC 870-6-702: TASE.2 Application Profile, Version 1996-08, which defines specific requirements
for upper layer profiles supporting TASE.2, and is a proper subset of the application profiles defined
in this volume
Data interchange with devices in real-time networking environments is accomplished using the following
specifications:
Generic Object Models for Substation and Feeder Equipment (GOMSFE), which defines a set of
object models for use across a broad range of typical utility devices.
Common Application Service Models, (CASM), which defines a standardized set of abstract ser-
vices supporting the UCA object models, as well as the methods of mapping the services to MMS.
3.1.1 7-Layer UCA
The 7-layer UCA model is based on stable international standards and is illustrated in Table 1. As noted
above, it is intended to be the primary communications architecture used within an electric utility.
In support of these application services, the UCA 7-layer specification provides for both local and wide area
subnetwork alternatives and a variety of network services. The combination of these protocols will allow the
architecture to provide a peer-to-peer communications infrastructure for distributed computing throughout a
utility.

IEEE-SA
The connectionless profile is limited to a subset (unconfirmed services) of the manufacturing message spec-
ification (MMS) ISO 9506: 1990. These protocols provide unacknowledged service, with a robust address-
ing and routing capability.
Specifically, the UCA 7-layer specification may be used with any of the standard data link technologies,
such as CSMA/CD (ISO 8802-3: 1996), fiber distributed data interface (FDDI), X.25, integrated services
digital network (ISDN), or high-level data link control (HDLC) variants such as type 1 (ADLC). The only
constraints imposed on such lower layer technologies by UCA is that they:
Use LLC Class 1 (LLC1) to ensure consistent data link addressing

Be capable of carrying the network layer protocol data units (PDUs) transparently
Meet the error and bandwidth requirements for the subnet in which they are employed
It is strongly recommended that utilities restrict themselves to open, standard data link technologies for all of
the normal business reasons of lowering life cycle costs and having multiple vendors of equipment. It is rec-
ognized that utilities may have to accommodate legacy subnet technologies, some of which may be propri-
etary. In virtually all cases, these can be used to transmit the protocols found in UCA T- and A-profiles.
However, they are not considered to be part of UCA.2
This technical report will not attempt to explicitly indicate all of the growing list of network technologies
that may be used with UCA, but will only concentrate on those aspects unique to UCA. Unless otherwise
specified, any open standard data link and physical layer technologies can be used with UCA.
Specification details for the 7-layer UCA model are provided in Section 4.
3.1.2 3-Layer Connection Oriented UCA Model
UCA Version 1.0 identified the need to support a 3-layer architecture as an alternative to the 7-layer architec-
ture described above. This architecture is intended to be the secondary communications architecture for use
within a utility communications environment and is applicable for only a certain limited number of utility
functions. The 3-layer UCA model is based on international standards and is illustrated in Table 3.
The justification for this 3-layer architecture is derived from the need to support a large number of simple
end devices for certain utility applications. These applications are limited to those found in a utility's real-
time networking environments, such as on distribution feeders and substations. The communications dia-
logue with these individual end devices is simple in nature and is typically limited to communications over a
single subnetwork.
The communication services offered by this architecture are, however, much more limited than those pro-
vided by the UCA 7-layer specification. At the application layer of this model, the MMS application layer
protocol is specified to provide the necessary messaging services for devices in these environments. In addi-
tion, the UCA station management protocol is specified, which provides support for UCA time synchroniza-
tion services (see Appendix B).
To support these application services, the 3-layer architecture offers the following local and wide area sub-
network alternatives:
CSMA/CD (ISO 8802-3: 1996),

Token Ring (ISO 8802-5: 1995),
2 It should also be noted that the use of some L-profiles (those that do not conform to the OSI data link
service definition) may require the specification of additional protocol related procedures to properly trans-
fer the protocols of the UCA T- and A-profiles.

IEEE-SA
ADLC type 3, or
Any other data link protocol that meets the criteria described above.
Specification details for the 3-layer UCA model are provided in Section 5.
The 7-layer and 3-layer architectures are intended to work together to provide the necessary utility
communications functionality for certain utility applications. A brief description of how these architectures
are intended to interwork is provided as part of Section 6.
3.1.3 3-Layer Connectionless UCA Model

The 3-layer connectionless model provides similar functionality to the 7-layer connectionless model (broad-
cast and multicast MMS-based services in an unconfirmed network environment), although without the
robust addressing and routing capabilities. This model, shown in Table 3, is intended for use with processor
and/or memory constrained devices that cannot economically support the full 7-layer connectionless model.
The 3-layer connectionless model supports the same local area networking technologies as the 7-layer
model, and can coexist with all of the other UCA models on subnetworks.
3.2 Specification Approach
3.2.1 Sources of Specification
The primary source of protocol specification for standards included in the UCA Version 2.0 profile is the rel-
evant ISO/IEC, IETF, or ITU base standard. These references are provided for all protocols specified in the
UCA profile. The wide range of options provided in such standards, however, does not provide a suitable
basis for ensuring interoperability in procured products. Consequently, the UCA Version 2.0 specification
also references, where possible, Version 3 of the Stable Implementation Agreements for Open Systems Inter-
connection Protocols. This source document, which is maintained by the NIST Open Systems Interconnec-
tion Workshop for Implementors is a recognized document in both the international standards community
and by US vendors of OSI products. These agreements provide implementation specifications that are based
on the relevant ISO/IEC or ITU standards.
3.2.2 Format Of UCA Specification
Details of the 7-layer UCA architecture are presented in Section 4, organized by OSI layer. The initial sec-
tion, 4.1, presents the allowable protocol configurations for UCA compliant systems. Subsequent sections
provide details, specifying each layer of the UCA Version 2.0 profile. At layer seven, the application layer,
separate specifications are provided for each standard included in the profile.
The specification details are formatted in the following concise and nontutorial manner:
Name highlights the name of the layer or standard that is being specified.
Description provides a brief description of the functionality provided by the specified layer or
standard.
Reference provides the specific ISO or ITU base standard reference number(s) of the protocol(s)
that shall be implemented for compliance with this technical report. This section also includes ref-
erences to any specific stable implementation guidelines and agreements that have been developed
for the protocol(s) that should also be implemented for compliance with the UCA profile. Where
appropriate, this section also provides information concerning any additional specification details,
including, for example, any restrictions placed upon the use of the specified protocol(s).

IEEE-SA
Notations are included, where appropriate, to indicate any additional information, such as advice
and guidance to utility procurement personnel on aspects of the specified standard. These may indi-
cate, for example, if no stable implementation agreements currently exist for certain portions of the
specified standard.
Following the specification of each of the seven layers of the 7-layer UCA profile, Section 4 also provides
advice and guidance relating to providing network management and security support within UCA conform-
ant systems.
Section 5 then follows with the specification of the UCA 3-layer architecture. This architecture is not strictly
based on the OSI reference model (i.e., seven layers). Consequently, additional information related to the
mapping of services within the 3-layer architecture has been provided.
Interactions between the set of application layer protocols and the supporting layer (presentation) are speci-
fied in a control function specification, as required by ISO/IEC 9545: 1994. The detailed control function
specification is contained in Appendix A.
3.2.3 Future Specifications
The electric utility industry has a wide range of communication requirements that will not be completely
addressed by UCA Version 2.0 specification due to the ongoing process of OSI standards development. The
intent, however, is that this technical report will evolve and be enhanced to incorporate additional standards
as they become stable and practical to implement.
4. UCA 7-Layer Specification

The UCA specifies a 7-layer architecture based on the OSI basic reference model (ISO 7498: 1994). Within
each of the seven layers, appropriate protocols are specified. Many layers have multiple protocol alterna-
tives, i.e., there are multiple application alternatives as well as multiple subnetwork alternatives. As a result,
a variety of protocol combinations may be implemented. This section describes the various protocol combi-
nations that are allowed in UCA compliant systems.
The UCA specification does not define new protocols but specifies the use of existing protocols with partic-
ular sets of parameters and options called profiles. The architecture is described in terms of three kinds of
these profiles: A-profiles spanning the upper three layers (application, presentation, and session); T-profiles,
the middle two layers (transport and network); and L-profiles, the lower two layers (data link and physical).
The OSI reference model allows for two distinct modes of operation: connection-mode and connectionless-
mode. The connectionless mode may be used for either unicast or multicast. UCA does not at this time use
connection-mode for multicast.
UCA 7-layer connectionless mode is defined over two distinct levels of service, normal and reliable, both of
which operate as multicast services. When operating at the normal level of service, each connectionless-
mode Link Service Data Unit (DLSDU) is transmitted by the link layer as in typical OSI operation. Since
there is no acknowledgment of data in connectionless-mode, there is no error detection or recovery. When
operating at the reliable level of service, special link procedures are used to retransmit each DLSDU (ini-
tially very often, gradually increasing the period). This retransmission allows for a much higher probability
of reception over unacknowledged links. In circumstances requiring extremely fast response time (e.g.,
breaker operation), by the time a connectionless-mode times-out waiting for an acknowledgment, it is too
late to retransmit the DLSDU. A reliable connectionless-mode profile, however, may retransmit the message
within the time window regardless of whether or not the receiver has actually received the message. The spe-
cialized link procedures required for supporting a reliable connectionless-mode service are defined within
the definitions of the L-profiles.

IEEE-SA
Connection-mode A Profiles Connectionless-mode A Profiles
Connection-mode T Profiles Connectionless-mode T Profiles
Connection-mode L Profiles Connectionless-mode L Profiles
Figure 2: Allowable Mappings of A, T, and L Profiles
A profile is referred to as being connection-mode or connectionless-mode if the service provided by the

highest layer in the profile is connection-mode or connectionless-mode. It should be noted that many T-pro-
files will consist of a connection-mode transport protocol and a connectionless-mode network protocol. This
is consistent with the constraints allowed by the OSI reference model. As illustrated in Figure 2, the refer-
ence model imposes distinct constraints on how the two modes may be combined in the layers:
Connection-mode A-profiles may map only to connection-mode T-profiles.

Connectionless-mode A-profiles may map only to connectionless-mode T-profiles.
Any T-profile (regardless of connection-mode or connectionless-mode) may be mapped to any L-
profile.
The application layer has the broadest range of alternatives. Within the application layer of the UCA, each
application protocol is composed of association control service element (ACSE) for the establishment phase
and one or more additional application service elements (ASEs) for the data transfer phase. These are all
used over the presentation and session protocols.
4.1 A-Profiles
4.1.1 Connection-mode A-profiles
4.1.1.1 Full Upper Layers
The full upper layer A-profile consists of the following standards:
ACSE (ISO/IEC 8650-1: 1996) combined the specific ASEs to form an application protocol.
Presentation protocol (ISO/IEC 8823-1: 1995)
Session protocol (ISO/IEC 8327: 1996)
This profile may be used for those applications that require the use of session functional units of kernel and
beyond or that require the ability to change presentation context during the lifetime of the connection. Exam-
ples are message handling systems (MHS), directory, and some forms of file transfer, access and manage-
ment (FTAM) and remote data access (RDA). Applications that use only the session kernel (such as MMS)
will incur less overhead both in bandwidth and processing through the use of the efficiency profile (see

IEEE-SA
4.1.1.2 ), rather than the full upper layer profile. The full upper layer profile, however, is the most widely
available profile for local area network use. The profile is summarized in Figure 3.
Note: Interactions among ACSE, the ASEs and application service objects (ASOs) that constitute the appli-
cation protocol, and the supporting layer (presentation) are specified in a control function specification, as
required by ISO/IEC 9545: 1994.
ACSE Specific ASEs
Presentation ISO/IEC 8823
Session ISO/IEC 8327
Figure 3: Full Upper Layer A-Profile
4.1.1.2 Efficiency Upper Layers
The efficiency A-profile consists of the following standards:
ACSE (ISO/IEC 8650-1: 1996) combined the specific ASEs to form an application protocol.
Presentation protocol (ISO/IEC 8823-1: 1995, add. 3)
Session protocol (ISO/IEC 8327: 1996, add. 3)
This profile (shown in Figure 4) is for use with those applications that use only the session kernel. It requires
the least bandwidth and processing overhead and is applicable to for use with many applications, such as
MMS and CMIP.
Note: Interactions among ACSE, the ASEs and ASOs that constitute the application protocol, and the sup-
porting layer (presentation) are specified in a control function specification, as required by ISO/IEC 9545:
1994.
ACSE Specific ASEs
FastByte Presentation
FastByte Session
Figure 4: Efficiency A-Profile
4.1.2 Connectionless-mode A-profile
The connectionless-mode A-profile consists of the following standards:
ACSE (ISO/IEC 10035: 1995) combined the specific ASEs to form an application protocol.
Presentation protocol (ISO/IEC 9576-1: 1995)
Session protocol (ISO/IEC 9548: 1996)

IEEE-SA
The connectionless-mode profile (shown in Figure 5) is used in UCA for those unicast environments where
systems are so constrained that connection-mode transport cannot be used or for unicast or multicast appli-
cation messages. There is no guarantee of delivery when using the connectionless A-profile and recovery and
detection of a failed message delivery are left to the application. The reliable level of service, however, may
be used when a more robust service is required. The reliable level of service still does not detect message
delivery failures, but allows for a higher probability of delivery and allows some failures to be detected at the
receiver. See 6.4 for specific guidelines for upper layer addressing when using the connectionless-mode pro-
file with a reliable level of service.
Note: Interactions among ACSE, the ASEs and ASOs that constitute the application protocol, and the sup-
porting layer (presentation) are specified in a control function specification, as required by ISO/IEC 9545:
1994. See Appendix A for the UCA control function specification.
ACSE Specific ASEs
Connectionless Presentation
Connectionless Session
Figure 5: Connectionless-mode A-Profile
4.1.3 Summary of Upper Layer Protocols
4.1.3.1 Session Layer
Name: Session protocol (ISO/IEC 8327: 1996)

Description: The session protocol provides services for organized and synchronized data
exchange.
Reference: The protocol to provide the session layer service shall be ISO 8327: 1996 includ-
ing the additions specified in ISO 8327: 1996, add. 3.
Where appropriate, session layer implementations shall also conform to the addi-
tional specific requirements for each ASE as specified in the relevant part of 5.12
of the NIST OIW Stable Implementation Agreements, 1994.
Notations: None
4.1.3.2 Presentation Layer
Name: Presentation protocol

Description: The presentation protocol defines the representation of data in transit between
two end systems.
Reference: The protocol to provide the presentation layer service shall be ISO/IEC 8823:
1994, including the additions specified in add. 3.
In addition, implementations shall also conform to the specific guidelines and
agreements relating to the use of ISO/IEC 8824-1: 1995, Abstract Syntax Nota-
tion One (ASN.1) and ISO/IEC 8825-1: 1995 Basic Encoding Rules (BER) or
Packed Encoding Rules (PER).

IEEE-SA
Where appropriate, presentation layer implementations shall also conform to the

additional specific requirements for each ASE as specified in the relevant part of
5.12 of the NIST OIW Stable Implementation Agreements.
Notations: None
4.1.3.3 Application Layer
Name: Association control service element (ACSE)

Description: The ACSE provides the association establishment procedures for the application
protocol.
Reference: ACSE shall be used in conjunction with all other ASEs.
The protocol to provide the application association control service shall be ISO
8650-1: 1996.
Where appropriate, ACSE implementations shall also conform to the additional

specific requirements for each ASE as specified in the relevant part of 5.12 of the
NIST OIW Stable Implementation Agreements.
Notations: None
Name: Remote operations service element (ROSE)
Description: ROSE provides services to support interactive applications in a distributed open
systems environment.
Reference: ROSE shall be used in conjunction with the following application service ele-
ments:
Message handling systems based on the ITU-T X.400 (1988) series of recommendations
Directory services based on the ITU-T X.500 (1988) series of recommendations
Common management information protocol (CMIP)
The protocol to provide the ROSE shall be ISO 9072-2: 1989.
Implementations shall conform to the implementation guidelines and agreements
specified for ROSE in section 5.6 of the NIST OIW Stable Implementation
Agreements.
For message handling systems based on the X.400 (1988) series of recommenda-
tions, ROSE implementations shall also conform to the additional specific
requirements stated in 5.12.1.2.3 and 5.12.1.2.4 of the NIST OIW Stable Imple-
mentation Agreements.
For directory services based on the X.500 (1988) series of recommendations,
ROSE implementations shall also conform to the additional specific requirements
specified in section 11.10 of the NIST OIW Stable Implementation Agreements.
To provide support for the network management common management informa-
tion protocol (CMIP), ROSE implementations shall support ROSE operations
classes 1, 2, and 5 and association class 3.
Notations: At the present time, the NIST OIW Stable Implementation Agreements for net-
work management are incomplete. The above ROSE specification to support
CMIP operations has therefore been reproduced from section 18.6.5 of the cur-
rent NIST OIW Working Implementation Agreements, 1994. In order to maintain
alignment with these agreements, implementors should refer to the most recent
NIST OIW Stable Implementation Agreements to check the current status of
agreements and to ensure consistency with the above specification. If

IEEE-SA
discrepancies exist, the specification provided in the NIST OIW Stable Imple-
mentation agreements should supersede the above specification.
Name: Reliable transfer service element (RTSE)
Description: RTSE ensures that application protocol data units (APDUs) are transferred error-
free between two end systems.
Reference: RTSE shall be used in conjunction with message handling systems based on the
ITU-T X.400 (1988) series of recommendations.
The protocol to provide the reliable transfer service shall be ISO 9066-2: 1989.

specified for RTSE in 5.7 of the NIST OIW Stable Implementation Agreements.
RTSE implementations shall also conform to the specific requirements for ITU-T
X.400 (1988) based systems specified in sections 5.12.1.2.2, 5.12.1.2.4, and 8.14
of the NIST OIW Stable Implementation Agreements, 1994.
Notations: None
Name: Message handling systems (MHS), 1988
Description: The MHS 1988 group of standards support store and forward messaging between
two end systems and provide additional functionality to that defined in the mes-
sage handling system 1984 specification. Specifically, the 1988 standards add
support for:
Message store
Remote user agents
Distribution list processing
Use of directory
It should be noted that at the present time, international harmonization of the
MHS 1988 profiles is still in progress. Significant changes may therefore be nec-
essary to the NIST Stable Implementation Agreements referenced in this section
of the specification to ensure that the NIST agreements are consistent with the
ISP being developed for MHS. The inclusion of this standard at the present time
within the UCA specification is intended to highlight the UCAs strategic direc-
tion with regard to MHS and to encourage consistency in early 1988 based imple-
mentations.
Reference: The protocols to provide the MHS 1988 standard shall be based on the ITU-T
X.400 (1988) series of recommendations and the corresponding ISO 10021:
1990, Parts 1-7.

specified for X.400 1988 MHS in section 8 of the NIST OIW Stable Implementa-
tion Agreements [NIST-1].
Notations: At the present time, no NIST OIW Stable Implementation Agreements concern-
ing the use of distribution lists and directory services are available. Caution is
consequently advised when procuring 1988 MHS systems that provide this func-
tionality to determine the extent to which these features are provided by propri-
etary or nonstandard mechanisms. If necessary, appropriate agreements may be
reached between the vendor and involved utilities to determine how the function-
ality shall be implemented with the intention of being consistent with NIST sta-
ble agreements once they evolve.

IEEE-SA
Also at the present time, the NIST OIW Stable Implementation Agreements do
not include guidelines and agreements relating to the mapping of internal trace
information between systems implementing the 1984 and 1988 MHS. Until inter-
national harmonization has been achieved in this area, implementors should, if
possible, avoid implementing private management domains that support both sets
of standards.
It should be noted that at this time, this technical report is not intended to replace
the MHS 1984 specification, which is considered to be a legitimate alternative for
those users who do not require the additional functionality provided by the 1988
set of standards
Name: Directory
Description: The directory standard supports the interconnection of distributed OSI-based end
systems by providing directory services to OSI users and applications.
Reference: The protocols to provide directory shall be based on ISO 9594: 1995 Parts 1-8
and the corresponding ITU-T X.500 (1988) series of recommendations.

specified in section 11 of the NIST OIW Stable Implementation Agreements.
Notations: At the present time, efforts are underway to provide enhancements to the base
standards in the areas of access control and replication of directory entries to sup-
port distributed operations. The current NIST Stable Implementation Agree-
ments, therefore, do not provide guidelines and agreements relating to these
enhancements. Caution is consequently advised when procuring directory prod-
ucts that provide this functionality to determine the extent to which these features
are provided by proprietary or nonstandard mechanisms. If necessary, appropri-
ate agreements may be reached between the vendor and involved utilities to
determine how the functionality shall be implemented with the intention of being
consistent with NIST agreements once they evolve.
Name: Manufacturing message specification (MMS)
Description: The MMS standard provides a messaging service for communication to intelli-
gent devices in an industrial environment.
Reference: The protocol to provide the MMS service shall be ISO/IEC 9506-2: 1990.
Implementations shall conform to the Static Conformance Requirements as
defined in Clause 19, Section 19.3 of ISO/IEC 9506-1: 1990.
All MMS services specified shall meet the conformance requirements for calling
MMS-users and called MMS-users as specified in Clause 19, Section 19.4 of
ISO/IEC 9506-1: 1990.
An MMS server shall support the MMS server requirements for all services as
specified in Clause 19, Section 19.6 of ISO/IEC 9506-1: 1990.
An MMS client shall support the MMS client requirements for all services as
specified in Clause 19, Section 19.7 of ISO/IEC 9506-1: 1990.
Implementations shall use the presentation context, abstract syntax object identi-
fier and application context as specified in ISO/IEC 9506-1: 1990 and ISO/IEC
9506-2: 1990. An initiate-version number of one shall be used.
Implementations shall conform to Chapter 20 of the NIST Working Implementa-
tion Agreements and should, where possible, only use subsets of those MMS ser-
vices specified in the agreements.

IEEE-SA
Notations: Suppliers claiming conformance to this technical report should indicate conform-
ance by completing a protocol implementation conformance statement (PICS) in
the format specified in Clause 18 of ISO/IEC 9506-2: 1990.
4.2 T-Profiles
4.2.1 Connection-mode T-Profiles
4.2.1.1 TP4/CLNP Profile
The TP4/CLNP profile consists of the following as shown in Figure 6:
TP4 (ISO/IEC 8073: 1997)

CLNP (ISO 8473: 1988)
This is the profile used in OSI environments and in most UCA demonstration projects. This profile repre-
sents the most efficient T-profile both in terms of processing/memory and bandwidth and is most appropriate
where such constraints are tight and there is a strong requirement for reliability.
OSI Class 4 Transport (TP4)
OSI Connectionless Network Protocol (CLNP)
Figure 6: TP4/CLNP Profile
4.2.1.2 RFC 1006 Profile
The RFC 1006 profile consists of the following, as shown in Figure 7:
IETF RFC 1006: 1987

TCP (IETF RFC 793, 1981)
IPv4 (IETF RFC 791, Internet Standard 5, 1981)
This profile is utilized in environments operating an OSI upper layer over TCP/IP. IETF RFC 1006 1987 pro-
vides the conversion from the stream semantics of TCP to the record semantics of TP4.
RFC 1006 specifies the use of TCP port 102 (decimal). This is considered the default port within the scope
of this document. Additional information may be found within RFC 1006.
The OSI regional workshops (NIST OIW, EWOS, and AOW) have recommended that RFC 1006 be the pre-
ferred mechanism of utilizing OSI A-profiles over TCP/IP T-profiles. However, RFC 1006 does not mandate
the use of the TCP-KEEPALIVE function.
In order to allow maximum reliability to be achieved, implementations shall be able to configure the use of
the TCP-KEEPALIVE function and the interval at which the function shall be used. Implementations that
have no access to the use of the TCP-KEEPALIVE shall convey this via the PICS.

IEEE-SA
RFC 1006
TCP
IPv4
Figure 7: RFC 1006 Profile
4.2.1.3 RFC 1070
TP4 (ISO/IEC 8073: 1997)

CLNP (ISO 8473: 1988)
RFC 1070: 1989
UDP (RFC 768, 1980)
IPv4 (RFC 791, Internet Standard 5, 1981)
This profile is used in environments that need to operate OSI A- and T-profiles over an Inter-
net Protocol (IP) network. This might occur in an environment that was partially full OSI (in
the subnets where there were tight performance constraints) and IP (in the subnets where
there were no such constraints). For example, an IED might support the TP4/CLNP profile on
a subnet that was pure OSI, but be communicating with a control center that used this profile
on its subnet, with the CLNP PDUs being mapped to RFC 1070 at the border of the IP
subnetwork.
IETF RFC 1070 (1989) specifies the use of UDP port 147 (decimal). This is considered the default port
within the scope of this document and must be supported. Additional information may be found within RFC
1070.
OSI Class 4 Transport (TP4)
RFC 1070
UDP
IPv4
4.2.2 Connectionless-Mode profiles
4.2.2.1 CLTP/CLNP
The CLTP/CLNP profile consists of the following, as shown in Figure 9:
CLTP (ISO/IEC 8602: 1987)

CLNP (ISO 8473: 1988)
This profile is the standard OSI T-profile. It is used for unicast and multicast environments where reliability
is not an issue, either because the network can be assumed to be reliable enough or because the application
can tolerate the losses or has provided its own recovery mechanism.

IEEE-SA
OSI Connectionless Transport (CLTP)
Figure 9: OSI Connectionless Profile
4.2.2.2 RFC 1240
CLTP (ISO/IEC 8602)

IETF RFC 1240 (1991)
UDP (IETF RFC 768)
IPv4 (IETF RFC 791, Internet Standard 5, 1981)
This profile is used when it is necessary to operate a connectionless OSI upper layer over an IP network.
RFC 1240 (1991) specifies the use of UDP port 102 (decimal). This is considered the default port within the
scope of this document and must be supported. Additional information may be found within RFC 1240. The
RFC referenced in this section was written in regard to IP Version 4.
OSI Connectionless Transport (CLTP)
RFC 1240
UDP
IPv4
4.2.3 Routing Protocol Profiles
In general, UCA recommends the use of Intermediate System-Intermediate System (IS-IS, ISO 10589:
1992) and Internet Domain Routing Protocol (IDRP, ISO 10747:1994) for CLNP and IP routing. Experience
with the protocols indicates that IS-IS is simpler to configure and maintain than OSPF. Most ISPs are using
IS-IS.
4.2.4 Summary of T-profile Protocols
Network Layer
Name: Connectionless network service (CLNS)
Description: The CLNS performs network routing and relaying on a packet by packet basis
without establishing a network connection.
References: The UCA network layer service is the CLNS as defined by the network service
definition (ISO 8348: 1996). The CLNS shall be used in end systems and inter-
mediate systems within a utility for interworking between systems connected via
a variety of local and wide area subnetworks. The protocol to provide the CLNS
is ISO 8473.

IEEE-SA
ISO 8473 shall be implemented over HDLC LAPB (ISO 7776: 1995) point-to-
point links, logical link control type 1 (ISO 8802-2: 1998) local area networks, or
ITU-T X.25 (1984) subnetworks. In the case where X.25 1984 equipment and
services are not available, ITU-T X.25 (1980) subnetwork may be used. Imple-
mentations shall follow the guidelines given in ISO 8473 for the subnetwork
dependent convergence functions.
Implementation of ISO 8473 over an ISDN subnetwork shall be provided in con-
junction with the X.25 packet layer protocol (PLP) (ISO 8208: 1995) as specified
in the relevant sections of ISO/IEC 9574: 1992. More specifically, the PLP shall
act as the subnetwork access protocol (SNAcP) of the network service, and coor-
dination between the ISDN channel control and the network service must be as
defined in ISO/IEC 9574: 1992.
Implementations shall conform to the specific implementation guidelines and
agreements specified for the CLNS in section 3.5 of the NIST OIW Stable Imple-
mentation Agreements, 1994.
Because there is more than one possible network protocol, and because these net-
work protocols can be used in different capacities in providing the network ser-
vice, it is necessary to provide a mechanism for protocol identification. Network
layer protocol identification shall be performed as specified in ISO/IEC TR 9577:
1990.
agreements specified for protocol identification in section 3.9 of the NIST OIW
Stable Implementation Agreements, 1994.
Notations: None
Name: IPv4
Description: This protocol defined in IETF RFC 791(1981) provides the connectionless net-
work protocol functionality for TCP/IP networks. IP is a precursor of CLNP and
is characterized by the smaller address space.
Name: Routing data exchange
Description: The routing data exchange protocol performs the exchange of information neces-
sary to support the network protocol routing function.
References: For use with IP, we recommend that the exchange of routing data between end
systems (ES) and intermediate systems (IS) on local area networks and point-to-
point links shall be performed with Dynamic Host Configuration Protocol
(DHCP) as defined in IETF RFC 1531: 1993.
agreements specified for ES-to-IS routing in section 3.8.1 of the NIST OIW Sta-
ble Implementation Agreements.
Notations: The UCA recommends the use of IS-to-IS routing protocol. This is the most
widely used routing protocol in the Internet today and it is much easier to config-
ure and maintain than any of the alternatives.
A replacement for IPv4, the so-called IPv6, is in progress at this writing.
However, it is unclear whether it provides sufficient benefit to a utility network to
warrant the cost of conversion. For UCA networks using IPv4, it is recommended
that they use IPv4 addresses assigned by InterNIC or private address space to
meet their address requirements, in conjunction with firewalls and network
address translation (NATs). Since the transition plan to IPv6 requires dual stacks
and/or NAT boxes, this approach will be more than adequate for utility
requirements for the foreseeable future and is on the path to a transition to IPv6,
should it happen to prove beneficial.

IEEE-SA
Transport Layer
Name: Transport protocol, class 4.
Description: The transport protocol provides end-to-end reliable data transfer.
References: The protocol to provide the transport service shall be ISO 8073: 1997. Class 4
operation of the protocol shall be used with respect to the specifications in both
ISO 8073: 1997 and ISO 8073: 1997, add. 2.
agreements specified for transport protocol classes 4 and 0 in sections 4.5.1 and
4.5.2 respectively of the NIST OIW Stable Implementation Agreements, 1994.
Notations: The support of class 0 is necessary for conformance to the application layer stan-
dard MHS.
Name: Transmission control protocol (TCP)
Description: TCP provides end-to-end reliable data transfer.
References: The protocol shall be IETF RFC 793 (1981) used in conjunction with IETF RFC
1006 (1987).
Notations: TCP implementations, especially those used in SCADA, control, and related
applications should be careful to ensure that the Keep Alive option is used. In
addition, applications using TCP must ensure that applications use the Push
option (TCP_NODELAY in a SOCKETS interface) to ensure that messages are
transmitted by TCP as soon as possible, e.g., the last buffer of an MMS request or
response should be sent to TCP with the Push option set.
Name: Connectionless transport protocol (CLTP)
Description: The transport protocol provides end-to-end reliable data transfer.
References: The protocol to provide the connectionless transport service shall be ISO 8602:
1987.
agreements specified for CLTP and the NIST OIW Stable Implementation Agree-
ments.
Notations: None.
Name: Unit data protocol (UDP)
Description: The UDP provides connectionless transport data transfer.
References: The protocol shall be IETF RFC 768 (1980) used in conjunction with IETF RFC
1070 (1989) and IETF RFC 1240 (1991).
Notations: None.
4.3 L-Profiles
L-profiles consist of the data link and physical layers. These two layers are heavily media-dependent and
therefore it is not unusual to find that a given data link protocol is strongly associated with a given physical
medium, often uniquely identified. In addition, there is a wide variety of such media, and the number is
growing almost weekly. The issues that would drive a utility to choose a medium are for the most part
beyond the scope of this document. Most of the media would meet various criteria for bandwidth, delay,
error rate, etc., of a subnetwork where a utility might deploy it for a given set of applications. Beyond this,
criteria such as range of applicability, cost, maintainability, etc., become much more dominant. Thus, this
technical report will not attempt to explicitly discuss all of the growing list of network technologies that may

IEEE-SA
be used with UCA, but will only concentrate on those aspects unique to UCA. Unless otherwise specified,
any standard (and many proprietary) data link and physical layer technologies can be used with UCA as long
as they are capable of transferring network layer PDUs transparently and can support the use of LLC1 as
described below for SCADA and IED environments. Only those implementations supporting open standard
data link and physical layer technologies can, however, claim conformance to UCA.
4.3.1 Use of LLC1 in UCA
The LLC service primitives are aligned with those defined in ISO 8802-2: 1988. In general, the primitives
that shall be used are:
L_DATA.request/indication
UCA L-profiles make use of the LLC1 function to send data with no immediate acknowledgment. This class
of service shall be used for the contention avoidance schema set forth in other parts of this document. It
should be noted that this service does not guarantee delivery of link level packets, but is required for use for
communication multicasting (e.g., when bit 15 of DSAP is one).
The parameters, required by IEEE Std 802.2, for L_DATA are:
a) Local addressThis address parameter contains the local media access control (MAC) address, e.g.,
ADLC individual address for the initiating node. It also contains the link service access point
(LSAP) for the initiating node. UCA uses the following hex LSAP addresses:
LSAP Profile
0x06 ARPANET Internet protocol (IP)

0xF7 Connection mode 3-layer stack
0xFB UCA station management
0xFE OSI network layer
0xFF Broadcast
b) Remote addressThis address parameter contains the destination MAC address, e.g., ADLC indi-
vidual address for the destination node or group. It also contains the LSAP for the destination node.
c) Data Link Service Data Unit (DLSDU)This parameter specifies the DLSDU to be transferred by
the data link layer entity.
d) QualityThe quality parameter specifies the service class desired for the data unit transfer.
It should be noted that ADLC can easily map/convey the MAC addresses (both local and remote) and
DLSDU parameters, however the LSAP (local and remote) parameters are not part of the standard ADLC
frame format. Therefore, these parameters will be carried within the user information section of an ADLC
frame in the prescribed format set forth in LLC1.
4.3.2 Asynchronous data link control (ADLC)
The utility industry uses many subnet technologies that are characterized by half duplex, low bandwidth
(1200 to 9600 baud) and often noisy media (radio). It was found that none of the existing HDLC protocol
classes were applicable to such hostile environments. Over the past several years, the gas industry in the US
and Canada has developed for this environment extensions to HDLC, which they call ADLC. This work has
been adopted by the electric utility industry as well and they have continued experimentation and

IEEE-SA
development jointly. These HDLC enhancements have been field tested over error-prone radio media in
multiple demonstration projects.
The ADLC enhancements to HDLC are in three areas: addressing, error protection, and segmentation. These
have been incorporated in a new frame format that addresses the environment found in telemetry applica-
tions for the electric and gas industries, and others. Recent studies of error characteristics of HDLC indicated
that in the hostile environments encountered in a utility network, the IEEE Power Society criteria would not
be met by existing HDLC classes (primarily because of the bit stuffing of HDLC). In addition, the hostile
environment required the use of relative small PDU sizes, which in turn introduced a requirement to be able
to segment DL-SDUs.
The gas and utility industries, under the auspices of the UCA and GRI, have been working closely with the
ISO committee responsible for HDLC (SC6) to coordinate these enhancements with on-going HDLC stan-
dardization and to make ADLC part of HDLC. Thus, this technical report points to the Draft International
Standard version ISO/IEC DIS 13239, as it has been used in one or more demonstration projects. Utilities
and vendors who wish to utilize ADLC or learn more about it should contact EPRI, Gas Research Institute
(GRI), or one of the demonstration projects to learn more.
4.3.3 Extended Link Procedures Supporting Reliable Connectionless-mode

Service
When supporting a connectionless-model profile for a reliable level of service, some specialized link ser-
vices are required. The link procedures are as follows:
Upon receiving an L.Data request from the L-user, the link service must transmit the DLSDU at the earliest
opportunity. The link service must then continuously retransmit the DLSDU at an increasing period, up to a
configurable maximum period. When the maximum period is reached, the link service will continue to
retransmit the DLSDU at a fixed period until the next L.Data request from that L-user.
The formal specification of the extended link procedures is summarized in Figure 11.
The procedure for each state is defined by:
State IDLE No action, waiting for L.Data request from L-user. When L.Data request
received, proceed to state STARTING.
State STARTING Transmit the DLSDU as under normal link procedures. Start timer with interval
T0 and proceed to state CHANGING.
State CHANGING Wait for either timer expiration or L.Data request from L-user. If L.Data
Request, proceed to state STARTING.
If timer expiration:
1) Retransmit DLSDU
2) Compute new time interval
3) If new time interval is greater than Tlimit, proceed to state STABLE
Else continue in state CHANGING.
State STABLE Wait for either timer expiration or L.Data request from L-user. If L.Data
Request, proceed to state STARTING.
If timer expiration, retransmit DLSDU and start timer with interval Tstable.

IEEE-SA
IDLE
L.Data request
STARTING
Transmit LSDU
L.Data request Transmit old DLSDU

LSDU
CHANGING
at increasing period
Period at limit DLSDU
Transmit old DLSDU

LSDU
STABLE
at stable period
Figure 11: Extended Link Procedures State Diagram
The computation of the new time interval in state CHANGING is a local issue, although it is strongly recom-
mended that both a geometric and an arithmetic progression be supported, and that the parameters for com-
puting the progression be configurable. In addition, the following parameters shall be configurable:
T0 Time interval until first retransmission

Tlimit Limit for progressive retransmission interval
Tstable Time interval between retransmissions in the stable state
MAC Multicast MAC sublayer address of destination
5. UCA 3-Layer Specification

This section provides a specification for a 3-layer architecture (i.e., application, data link, and physical layers
only). Three layer architectures are widely implemented in current (proprietary) utility monitoring and con-
trol networks and are currently proposed in the ongoing IEC and ISA standards. The 3-layer architectures
described here are based, whenever possible, upon fully stable international standardization efforts. How-
ever, the manner in which they have been combined in order to assemble a 3-layer architecture has not been
approved or standardized by any official standards body. Therefore this specification is open to comment by
utilities and implementors. Comments based on practical implementation are encouraged and may prove
valuable in refining the specification, as needed.
The 3-layer architectures are intended to be used to support small field devices with limited processing and/
or memory capability, and hence are unable to utilize the full 7-layer architectures. Two models of the 3-
layer architecture are specified: connection-mode and connectionless. The connection-mode versions (like

IEEE-SA
their 7 layer MMS counterparts), may be used for standard UCA data acquisition and control applications.
The connectionless variations are strictly limited to supporting broadcast/multicast unconfirmed services. In
either case, the 3-layer architectures are limited to communications within a local network segment or over a
WAN link, unless gateways are provided.
The UCA 3-layer and 7-layer architectures can coexist on a single subnetwork.
5.1 3-Layer Connection-mode Specification

The 3-layer connection-mode architecture is intended to be used to support small field devices with limited
capability (and hence unable to support 7-layer architectures). The architecture utilizes the MMS, combined
with ACSE. In addition, the UCA station management protocol (defined in Appendix B) operates in a 3-
layer architecture. At the time of this publication, the only service provided by the UCA station management
protocol is time synchronization.
Link services are provided by the ADLC Type 3 link layer for reliable delivery of data on serial based envi-
ronments. This architecture operates over a standard asynchronous serial-based physical layer, which can be
a point to point serial (EIA-232-D), multi-drop serial (EIA-485), or other serial-based physical layers such
as radio systems. The basic architecture is depicted in Connection-mode 3 Layer Stack.
ACSE Specific ASEs
LLC1
ADLC or Equivalent
Physical Layer
Figure 12: Connection-mode 3 Layer Stack
The MMS standard provides a messaging service for communications to intelligent devices. Connection-
mode ACSE provides parameters for naming and security. LLC1 provides the same function as it does over a
LAN. ADLC type 3 defines a serial- based segmenting link protocol providing reliable communications
between nodes.
5.1.1 Physical Layer
For serial data communications below data rates of 20 Kbps, the EIA-232-D (equivalent to X.21bis [ITU-3])
physical interface is recommended whenever it is appropriate. To allow for the necessary flexibility for phys-
ical interface implementations, however, the UCA does not impose constraints by allowing only a limited
number of WAN physical layer interfaces. To accommodate requirements not met by the above physical
interface recommendation, other standard (non-proprietary) physical interfaces may be substituted.
5.1.2 Data Link Layer
The data link protocol for the 3-layer serial based architecture shall be ADLC type 3, as defined in ISO/IEC
DIS 13239 (non-basic frame formats). ADLC was developed as a modification to HDLC/NRM (currently
proposed to be incorporated into that standard) for use in SCADA environments. The ADLC protocol (like

IEEE-SA
HDLC/NRM) provides an unbalanced type of data transfer capability between logically unequal stations
(one primary, and one or more secondary) over a point-to-point or point-to-multipoint configuration. ADLC
differs from HDLC/NRM in that the frame format has been modified to include a length field, allowing the
protocol to operate transparently in an asynchronous environment without the use of escape sequences
(unlike HDLC/NRM).
ADLC is suitable for polled multipoint operation.
LLC1 shall be used, with 0xF7 for all link layers supporting the connection-mode UCA 3-layer architecture.
5.2 Connection-mode and Connectionless-mode Application Layer

The application layer for the 3-layer architecture is defined by the control function specification found in
Appendix A. This 3-layer stack uses the same control function as the 7-layer stack with the exception that
the mapping to the supporting service is the appropriate L-profile, not the presentation layer.
5.2.1 Implications of the 3-Layer Architecture

Various considerations and implications result from using MMS over ADLC in a 3-layer architecture. These
considerations are described below.
The available set of MMS services in the UCA 3-layer WAN architecture is exactly the same as
those available for MMS in the UCA 7-layer architecture.
The nature of ADLCs normal response operating mode means that there can only be one primary
station on a link. All other stations are secondary. Since the primary station is always the initiator of
the link communication, secondary stations are required to wait until spoken to in a master/slave-
like fashion. Likewise, secondary stations must queue DL-Data.request primitives until polled by
the primary. Once the connection is established by the primary, and as long as it is maintained,
either station may perform either the client or server MMS roles.
Unconfirmed MMS services (reject, InformationReport, UnsolicitedStatus, EventNotification) can
be initiated by either the primary or secondary station, but the timeliness of its delivery is strictly
determined by the polling actions of the primary. Likewise, applications that depend on unsolicited
services to determine critical device status must utilize the connection maintenance function of the
polling activity, along with ADLC idle time-outs, to track the link state.
Since the 3-layer connection-mode architecture provides for only one service access point (the
ADLC address), each MMS association must map to a unique ADLC source and destination
address pair. A particular station may, however, respond to more than one ADLC address.
To allow for simplified processing in very small devices, the restriction is imposed that only one
unacknowledged DLSDU (which may be segmented into multiple ADLC frames) may be allowed
outstanding for a source and destination address pair (and hence a given MMS association).
Routing frames to stations on another subnetwork cannot be accommodated as there are no network
layer routing capabilities. Gateways may be constructed which would map local ADLC connec-
tions to 7-layer associations, but it is the responsibility of such gateways to propagate aborts (i.e.,
link state failures and disconnects) accordingly. The specification of such gateways is outside the
scope of this document.
The MMS user cannot utilize the address structure of a 7-layer architecture. Within this document,
instances of called/calling addresses that are specified within the service primitives refer to the
actual ADLC level addresses. Addressing information about the 3-layer system shall be maintained
locally; resolution between names and addresses is also a local issue.
This technical report does not require any network management or directory services in a 3-layer
architecture. These functions are considered to be a local issue. The network management proposal
within the MMS-SIG of the OIW is being tracked for future use within UCA.

IEEE-SA
The maximum length of an ADLC type 3 frame is 2048 Bytes, although over many media the prac-
tical limitation is much smaller. Each MMS service may be segmented into multiple ADLC frames,
but no ADLC transmission window may contain segments from more than one MMS service. It
should be noted that frame size can impact performance.
ADLC can support group addresses for broadcast/multicast transmissions from the primary station
to multiple secondary stations, but such use is restricted to the 3-layer connectionless profile,
described in 5.3.
Retransmission procedures and link recovery mechanisms (where possible) are defined within the
ADLC specification. In order to detect exception conditions (i.e., fatal transmission errors, primary/
secondary malfunction, or operational situation), link state failures (lack of secondary response to
polls, ADLC FRMR conditions, lack of polls from the primary, and unexpected disconnects or con-
nects) are mapped to MMS Aborts. Configurable timers and procedures are defined within ADLC
to manage this process. In addition, critical applications may require response time-outs on MMS
services and may take appropriate recovery actions as locally defined.
Many of the concepts developed in this section are further described in ISO/IEC DIS 13239.
5.3 3-Layer Connectionless Specification

The 3-layer connectionless architecture is intended to be used to support small field devices with limited
capability (and hence unable to support 7-layer architectures). The architecture utilizes the MMS, operating
over connectionless ACSE, and utilizing the ADLC type 3 link layer for delivery of data. This architecture
operates over a standard asynchronous serial based physical layer, which can be a point-to-point serial (EIA-
232-D), multi-drop serial (485), or other serial based physical layers such as radio systems. Any of the UCA
local area network protocols used within the 7-layer model may also be applied by the 3-layer connection-
less model. The basic architecture is depicted in Figure 13.
ACSE 10035 Specific ASEs
LLC1
ADLC or Equivalent
Physical Layer
Figure 13: Connectionless-mode 3 Layer Stack
The connectionless 3-layer architecture provides for a mechanism to perform broadcast and multicast com-
munications to small devices. The 3-layer connectionless architecture supports the same local area network
link protocols as the 7-layer connection-mode architecture.
Note: The connection-mode 3-layer profile will have less overhead than the connectionless-mode because
there is no ACSE PCI in the data transfer phase, whereas the connectionless-mode requires ACSE on every
PDU.
5.3.1 ADLC Multicast Procedures

The link procedures for the broadcast mode of ADLC differ somewhat from those used in the 3-layer con-
nection-mode architecture. The primary station (any time), or any secondary station (when polled), may

IEEE-SA
issue a connectionless DL-Data.request by transmitting ADLC numbered I frames (information) with its
address as source address, and a group address as the destination, without having previously established an
ADLC connection with that address. The segments of the DLSDU will be carried in numbered I frames,
always starting with 0 as the first segment of each DLSDU, and each DLSDU fitting completely in the
ADLC modulus range (0 to 7). No ADLC acknowledgment of the DLSDU is permitted. DLSDUs with miss-
ing or out of sequence frames are discarded by the receiver. Valid DLSDUs that are received by stations
enrolled in the group address will be delivered to the corresponding manufacturing message protocol
machine (MMPM).
Type 1 LLC shall be used, with 0xF5 for all link layers supporting the connection oriented UCA 3-layer
architecture.
Bit 15 of the destination ADLC address shall be designated the individual/group address bit. An I/G value of
1 shall indicate that the destination is a group address. Bit 14 of the destination ADLC address shall be
designated the multicast/broadcast (M/B) bit. An M/B value of 1 shall indicate that an all station broadcast
address is present. Only the lower byte of the destination address shall be valid when the I/G = 1 and M/B =
0. The only valid destination address for I/G = 1 and M/B = 1 shall be 0xFFF hex. This value shall be the
ALL-STATION-BROADCAST address.
6. Guidelines
6.1 Overview
The following sections provide guidelines on topics relevant to implementing the UCA. Each section pro-
vides some background about the topic followed by recommendations. Topics covered are
Naming guidelines
Addressing and registration guidelines
Multicast
Network management
Security
Bridging considerations
7-layer/3-layer interworking
Conformance and interoperability testing
6.2 Naming Guidelines

Within an OSI environment, many different types of network objects must be assigned globally unambigu-
ous names. These include objects such as abstract syntaxes, transfer syntaxes, application contexts, and
FTAM document types. Names for these objects are, in most cases, assigned by the committee developing
the particular base ISO standard or by implementors workshops such as the NIST OSI Implementors Work-
shop (OIW). There are, however, some names that need to be assigned by an administrator of a UCA com-
pliant network. These include application entity (AE) titles and originator/recipient (O/R) names.
6.2.1 Application Entity (AE) Titles

The purpose of an AE title is to unambiguously identify a particular application entity within an OSI
network. To accommodate the requirements of users, three different types of AE titles are available for use in

IEEE-SA
an OSI environment. All three are globally unambiguous, but there are differences in the format and use of
each type.
The first form of an AE title is a value of the ASN.1 type OBJECT IDENTIFIER. AE titles in this form are
represented by a series of integers describing an unambiguous path in a tree structure. For example, an AE
title of this form may be written as {1 3 9999 1 7}. This type of AE title is intended to provides a compact
means of encoding the AE title. For the application layer standards specified in the UCA profile, AE titles of
this type are assigned by the administrators of the applications.
Understanding the use and format of the second form of an AE title is important in an OSI/UCA environ-
ment that implements X.500 services. ITU-T X.500 (1988) provides an accessible database for storing infor-
mation about a network and its users. An important use of this information repository is to store the
presentation address of each AE. To access this stored information, some kind of name must be given to act
as a key to the database. This name is called a distinguished name or, in some contexts, a directory name. A
distinguished name is the second form of an AE title. This form of AE title can be used to look up the AEs
presentation address. A distinguished name consists of a series of type/value pairs that describe an unambig-
uous path down the directory information tree defined by a particular group of X.500 directory systems. For
example, a distinguished name for an FTAM responder running on a system at the Diablo Canyon power
plant of Pacific Gas and Electric might be written as {Country = US, Organization = PGE, Organization-
alUnit = DiabloCanyon, ApplicationProcess = SystemApplication, ApplicationEntity = FTAMRe-
sponder}.
It should be noted that the tree structure associated with distinguished names is distinct from the single tree
structure from which OBJECT IDENTIFIER values are derived. Each group of X.500 systems can define its
own directory information tree. Although the X.500 standard gives some guidance for how the levels of this
tree should be constructed, in practice a utility is free to define the structure of the tree and thus the distin-
guished names of the entries in that tree. Definitive guidance to utilities in this area is unfortunately not pos-
sible since this problem is in essence an exercise in database design. However, one possible approach is to
design the database in a hierarchical fashion in a manner appropriate for the utility's use of X.500 services
and reflective of its organizational structure.
If X.500 services are used in a UCA implementation, each AE that provides some network service must be
assigned a distinguished name. In some cases, AEs may already be assigned AE titles of the OBJECT IDEN-
TIFIER form to comply with the relevant implementation agreements. Distinguished names are used in pro-
tocol when the recipient of an association request needs to be able to use the AE title in subsequent use of the
directory, and bandwidth considerations are not paramount.
In addition, ACSE also provides an AE title form that is of the syntax PRINTABLESTRING. This syntax is
primarily for local use and allows the system administrator to define local names for applications with a
local syntax. This form has the advantage that it can be adapted for use with the Internet domain name ser-
vice (DNS). In most cases, this will be moderate in overhead between the ObjectIdentifier form and the dis-
tinguished name form.
6.2.2 O/R Names
Implementors of X.400 services within UCA compliant networks will also need to assign an unambiguous
identifier O/R name to each potential user of an electronic messaging system based on the ITU-T X.400:
1988 protocol. This name is used by the X.400 system both to identify and route messages to a user.
O/R names have several options, but all of them define a hierarchical structure. An example O/R name might
be written as Country = US, ADMD = ATTmail, PRMD = PGE, Organization = Distribution, Organization-
alUnit = GoldenGRegion, PersonalName = A.N.Other.
O/R names can also be stored in a directory. They should not, however, be confused with the distinguished
names described above in the discussion concerning AE titles. A further point to note is that O/R names may

IEEE-SA
contain the names of the administrative management domain (ADMD), private management domain
(PRMD), and organization of the person named. This aspect of O/R names presents a number of issues for
administrators of X.400 networks. For the O/R name to be unambiguous, the names of ADMDs, PRMDs,
and, in some cases, even organizations must also be unambiguous within each country. Insuring this unam-
biguousness requires a national registration authority to assign these names. Within the US, the responsibil-
ity for registration rests with ANSI. At the time of writing, however, ANSI has yet to finalize procedures for
allocating these unambiguous names. Until then, public mail providers must invent their own ADMD names,
and utilities installing X.400 services within a UCA compliant network must establish and use their own
locally defined PRMD and organization names to best reflect the organization of their operations.
6.3 Addressing and Registration Guidelines

Addresses are used to locate objects. Network addresses, which consist of one or more network service
access point (NSAP) addresses, are used to locate systems, whereas upper layer addressing is used to iden-
tify the communicating AE within a system. Thus, a network address has to be unambiguous within the net-
work, but upper layer addresses need only be unambiguous within a particular end system.
6.3.1 UCA NSAP Address
An end system is located by its NSAP address. It is necessary that this address be unambiguous throughout
the network and indeed, globally unambiguous if the network is to be connected to networks outside the util-
ity. A formal procedure for registering addresses with designated addressing authorities exists to ensure the
unambiguousness throughout the network. These addressing authorities, in turn, can designate subaddress-
ing, or second level authorities, thus delegating authority to various other entities. The identification of regis-
tration authorities is provided for in the basic NSAP address format defined in ISO 8348: 1996, add. 2.
The NSAP address defined in the standard has a hierarchical structure, as shown in Figure 14.
AFI IDI DSP
Figure 14: NSAP Address Structure
The authority and format identifier (AFI) identifies the first level addressing authority and the abstract syntax
(i.e., binary or decimal) of the domain specific part (DSP). The initial domain identifier (IDI) stands for a
second level authority, which is recognized by the authority defined by the AFI.
The current first level authorities include ISO standards and ITU recommendations. One such first level
authority is ISO 3166-1: 1997, which is identified in the NSAP address by an AFI of 39. ISO 3166-1: 1997
further delegates its address registration authority by allocating IDI values on a country by country basis.
The IDI value identifying the US is 840. Within each country, there is an agency that then acts as the local
or second level addressing authority. Within the US, ANSI is this second level addressing authority.
It is recommended that UCA compliant systems use ISO 31663166-1: 1997 as a first level authority. In
doing so the UCA NSAP AFI shall then be 39, which unambiguously identifies ISO 3166 as the first level
authority and defines the DSP to be in binary abstract syntax. Furthermore, the IDI should take the value
840, which is the US country number designated by ISO 31663166-1: 1997. Since ANSI is the registration
authority in the US, the electric utilities should register with ANSI and obtain a 3-octet organization-identi-
fier, which will form a part of the DSP in OSI/UCA systems.

IEEE-SA
To obtain an organization-identifier, the network administrator should contact ANSI. There is a modest fee
for registering organization IDs.
The contents and structure of the DSP are not specified by ISO 8348: 1996. add. 2 or by ANSI, although the
organization ID will occupy some field in the DSP. In addition to the organization ID, a DSP format identi-
fier is useful as the first field within the DSP to indicate a particular structure or field layout of the DSP, and
it allows for additional structures to also be defined in the future. This 1-octet field shall have the value of
1000 000 for the UCA NSAP address structure described below.
Beyond DSP format ID and organization ID, it is useful to define the remaining structure of the DSP hierar-
chically in order to maximize routing efficiency. The following three address profiles are suggested for use:
a) The GOSIP format, which uses the entire 20 octet address space;
b) A globally unambiguous form that builds its address space from the private IP address space and
requires 14 octets; and
c) A local address, which uses six octets of which the last five octets of the global IP address are
formed. The GOSIP format is given in Figure 15.
AFI IDI DSP

DSP routing local system NSAP
39 840 org. ID reserved
format ID domain area ID ID Selector
Octets 1 2 1 3 2 2 2 6 1
Figure 15: UCA NSAP Address
Note: This format is for the USA only.
6.3.1.1 GOSIP Format
The GOSIP specification defines a format that uses all 20 octets. A reserved field is defined to extend the
length of the NSAP address to its maximum of 20 octets. Utilization of a fixed address size can simplify
routing. Additionally, should the need arise, the reserved field can be used in the future to define another
level of authority, or to increase the length of the organization-identifier/routing domain fields.
The routing domain, local area ID, and system ID fields are defined to reflect a hierarchical structure that can
be reflected in organizations networks. The routing domain unambiguously identifies one of the routing
domains defined within the organization. The local area ID is made up of two octets that identify a particular
local area or subnetwork within the routing domain. The system ID field includes the next six octets and
unambiguously identifies a system within the local area. The last octet represents the NSAP selector that
identifies the user of the network service (i.e., a transport entity) within the end system.
This structure is consistent with U.S. GOSIP version 2.0 and with the guidelines currently put forth in the
NIST Ongoing Implementation Agreements for the last nine octets of the DSP within an IS-IS routing
domain.
6.3.1.2 The IP Form of CLNP Addresses
Since it can be assumed that most utilities will also be using the IP address form, this can be used to good
advantage for the CLNP address. Utilities are strongly urged to use the IP private address space, i.e., Net 10,
for their IP addressing [see IETF RFC 1597 (1994)]. This has several advantages:

IEEE-SA
It is unlikely that the utility can get enough addresses allocated from IANA. Private address space
will provide a Class A IP address and, in fact, as many as necessary.
The utility requires a firewall between itself and the Internet, so doing address translation between
the global IP address space and the private address space is little additional work.
It buffers the utility from the requirement of renumbering as pressure increases to go to provider
based addresses.
It makes the task of changing providers much easier by not requiring that the entire utility network
be renumbered.
It buffers the utility from the current uncertainty in the addressing and routing structure of the
Internet.
For those utilities that do not have IP addresses assigned and wish to acquire them, they should consult their
local Internet service provider (ISP). No action is required to use private address space, but a small number
of IP addresses will be required if the utility wishes to have access to the global Internet. It is beyond the
scope of this document to provide further guidance on the pros and cons of attaching a corporate network to
the Internet and the design of an IP addressing plan.
6.3.1.3 The Global Form
The prevalence of the use of IP address presents an opportunity for simplifying the network administrators
work and producing a CLNP address that creates less overhead than the GOSIP format. The global IP
address form for CLNP consists of 14 octets with the following format:
AFI = 39 (1 octet)
IDI = 840 (2 octets)
DSP = 129 (1 octet)
Org Id = xx xx xx (3 octets)
Local Addr = 10.xx.xx.xx (4 octets)
Sel = xx (1 octet)
NSAP addresses are assigned according to Annex A of ISO 8348: 1996. The utility should get an Org-id
from ANSI and will administer the assignment of addresses below its Org-id. The next four octets are the IP
address. Thus, the IP address assigned to a device can be used to construct its CLNP address. (Because IP
addresses name interfaces and CLNP addresses name systems, a network will always require more IP
addresses than CLNP addresses.) Note that the IP address is indicated here as being from Net 10, however,
any IP-address can be used.
6.3.1.4 The Local Form
In some cases, the utility may not want or need for its CLNP network to have global visibility. This will
especially be true during the construction and testing phase and may also be true during the production phase
for security reasons. In this case, an even shorter address form can be used. The local address form will be
used only with traffic within a utility. The NSAP will consist of six octets with the following format:
AFI = 49 (1 octet)
Local Addr = 10.xx.xx.xx (4 octets)
Sel = xx (1 octet)
Note that most router implementations of CLNP do not support multiple AFIs in the same router. Thus, it is
not possible to use both the short and long form of CLNP addresses in the same network (although this
would be highly desirable). AFI = 49 can only be used if CLNP traffic is not intended to leave the utility.

IEEE-SA
The following NSELs shall be used:
00 = intermediate systems
01 = OSI transport
The utility maintains the addressing plan for the network and acts as the registration authority for the
addresses. The local addresses will be allocated from a space that is identical to the IP 24-bit private address
space (see RFC 1597). Note that the addresses are topologically significant. Therefore, moving equipment
may entail changing its address.
UCA systems that interwork with systems employing different NSAP address formats must be able to pro-
cess these alternate formats.
6.3.2 Upper Layers Addressing
The NSAP address unambiguously locates a system within a network. In an end system, the last part of the
network address, the NSAP selector, points to a transport entity. Other selectors are defined to allow the
selection of entities at the upper layers of the OSI reference model. They include:
The transport service access point (TSAP) selector

The session service access point (SSAP) selector
The presentation service access point (PSAP) selector
Such selectors have to be unambiguous within an end system in order to identify a service access point in
that particular system. The combination of NSAP address and upper layer selectors (PSAP selector, SSAP
selector, TSAP selector), called a presentation address, is used to locate AEs. Presentation addresses can be
made available to network users by means of directory services, using, for example, an AE title as a distin-
guished name, as defined in 6.2.
Since the above selectors do not have to be globally unambiguous, the values given to them are purely local
matters. However, it is useful for practical implementation reasons to specify a maximum length for a selec-
tor. UCA recommends that in all cases the S-selector and P-selector be assigned the value null and encoded
accordingly. (This will be consistent between both traditional OSI upper layers whether full or mOSI, and
the newer fast-byte upper layer option.) The T-selector should have a length of two octets and be assigned
locally.
6.4 Multicast
A multicast service requires that all service data units (SDUs) sent shall refer to a group-AE-title, and a
group- P-address. The calling address will be a unicast address. A group-P-address or AE title defines a set
of unicast addresses such that when the address is used all members of the set are selected. The delivery of a
multicast PDU:
Via connectionless communication profiles restricts the applicability of multicast to any profile
within this document which supports connectionless ACSE (e.g., IETF RFC 1240, 7-layer OSI con-
nectionless-mode, and 3-layer connectionless profile).
May resolve the multicast address into one or more unicast addresses.
Is typically resolved to a multicast address.

IEEE-SA
6.4.1 Multicast Enrollment/Management
The group-P-address and the set of unicast addresses it represents may be recorded in a directory. When an
application wants to communicate with the group, it can give the directory the group-AE-title and get back
the group-P-address.
This information must also be distributed to those end systems on which the applications in the group reside
and those application gateways that proxy applications in the group, so that they recognize PDUs that they
must accept. Because there are no standard enrollment protocols, this will have to be accomplished by ad
hoc means.
The use of multicast is to be restricted to within a single subnetwork, and propagation beyond a single sub-
net is an issue for intermediate systems. This multicast list, enrollment protocol, and remote configuration
are items for future study.
6.4.2 Upper Layer Multicast (Transport and Above)
The connectionless-mode upper layer profile for OSI stacks consists of the following:
1) A-unit-data at the application layer (the presence of AP and AE titles is optional).

2) P-unit-data with a null or default P-selector (there is no multiplexing at this layer so there is no
need for the selector).
3) S-unit-data with a null or default S-selector (there is no multiplexing at this layer so there is no
need for the selector).
4) T-unit-data (CLTP) with a group-T-selector (there is multiplexing at this layer, so there is a need
for the selector, which should be two octets).
Note: The use of a null or default P- and S-selector is not unique to multicast. The same considerations apply
to the unicast case.
The connectionless-mode upper layer profile for non-OSI stacks (i.e., the so-called 3-layer stack, which con-
tains ACSE) consists of the following:
A-unit-data at the application layer (the presence of AP and AE titles is required only if more than one
application-entity/process is supported by the system).
Profiles that do not contain ACSE are out-of-scope.
In all profiles, the sender of a multicast SDU will use group-addresses/titles as the called-address/title and
the unicast address/title of the sender as the calling-address/title.
In all profiles, the end systems that contain multicast receivers of a group must have the definition of the
group (at least as it applies to this end system) in order to know which unicast T-addresses on this end system
are members of the multicast group.
The connection-mode upper layer profile is left for further study.
6.4.3 Network Layer and Below
Multicast distribution occurs at the network and data link layers. The network layer may take advantage of
the multiaccess nature of specific subnetworks in their distribution mechanisms, e.g., send a single PDU to
an appropriate multicast LAN address.

IEEE-SA
There are two network layers that may be used with these T-profiles: CLNP or IP/UDP. (IETF RFC 1240,
1991 will be used to adapt IP to the OSI network layer service, using UDP.)
Utilities are strongly recommended to adopt IP private address space for their enterprise addressing scheme
and only use global IP addresses externally. This implies the use of address translation at the enterprise fire-
wall. (UDP will use a well-known socket for this service. This may already be allocated by IETF RFC
1240.) In IP, multicast addresses are termed Class D addresses. There are only 256 Class D addresses for IP.
This scarcity of Class D addresses will severely constrain the use of multicast groups among utilities. (These
256 addresses must be shared by the entire Internet.) In fact, 256 may also be constraining within a utility.
Note: Utilities should be aware that the IP multicast RFC and the CLNP multicast standard rely on flooding
as a multicast distribution mechanism. This approach cannot be considered safe for safety-critical utility net-
works and does not achieve the primary purpose of multicast, i.e., reducing the amount of traffic actually
sent on the network. Utilities may want to use specialized mechanisms until standard nonflooding multicast
distribution mechanisms are generally available.
CLNP addresses will consist of the normal preliminary parts of an NSAP-address specifying the AFI, the
country code, and an org-id. The rest of the address will be allocated from the same address space as the pri-
vate IP address, i.e., 4 octets, followed by one octet of selector.
As noted above, when multicast traffic is routed to inherently multiaccess subnetworks, such as LANs or
wireless, the multicast distribution may take advantage of this property.
At the boundary with 3-layer subnets, the gateway must have the definition of the group that applies to mem-
bers of the group that are on end systems on this subnet. The gateway will have to translate the network layer
multicast address to the appropriate data link address.
6.4.4 Multicast Operation
In order to allow DataLink communication multicast to translate into application multicasting, a local refer-
ence must be reserved to receive the multicast or broadcast.
The reserved destination TSEL shall be 0, SSEL shall be 0, PSEL shall be 0.
Upon reception of a multicast message, the application entity will perform local action to alert all other
application entities of the multicast.
Responses to the multicast shall include the local reference of the responding entities and shall not contain a
destination TSEL, SSEL, PSEL whose value is 0.
Should a device not support multicast, the receiving multicast entity shall discard the packet and no error
response shall be generated.
6.5 Network Management

The use of large complex networks in a typical utility environment necessitates management of network
resources using a range of sophisticated management services. This section provides information and guid-
ance relating to the provision of these types of services in an OSI, TCP/IP, and UCA environment.
The guiding principal of both ISO and TCP/IP network management is a foundation in the OSI management
framework standard ISO 7498-4: 1989. This framework, which is now a full International Standard, provides
the terminology and definitions that are intended to facilitate the development of management standards
consistent with the OSI basic reference model. The framework, however, is not intended to be an

IEEE-SA
implementation specification. A number of additional management standards based on the definitions

contained within the Framework need to be developed and finalized before OSI network management
implementations can be fully carried out as detailed within the framework. The functionality provided by
these additional standards will support the location and correction of faults, the establishment and
adjustment of configurations, the measurement and tuning of performance, the control of security, and
collection and reporting of billing and accounting information. However, no additional standards are
required in regard to communication parameters, attributes, or event notification.
The transfer of management information between end systems in an open systems environment is
accomplished using the common management information protocol (CMIP) defined in ISO/IEC 9596-1:
1991, simple network management protocol (SNMP) defined in IETF RFC 1157 (1990) and RFC 1240:
1991, or MMS (ISO/IEC 9506: 1990).
Other standards, however, including those describing managed objects, the operations that may be per-
formed upon them, and the notifications that they may emit are available as are products that implement
them. Such definitions may be found in:
ISO/IEC 10742: 1994

ISO/IEC 10737: 1994
ISO/IEC 10733: 1993
ISO/IEC 10165-2: 1992
ISO/IEC 10165-4: 1992
ISO/IEC 10165-5: 1994
ISO/IEC 10165-6: 1997
IETF RFC 1155 (1990)
IETF RFC 1212 (1991)
IETF RFC 1213 (1991)
ITU G.851.1 (1996)
ITU G.852.1 (1996)
ITU G.853.1 (1996)
ITU G.853.2 (1996)
Additional object definitions may need to be defined (e.g., for MMS management).
Implementors of UCA networks requiring management functionality are advised to procure management
products that are consistent with the OSI management framework.
In line with this recommendation, CMIP (ISO/IEC 9596-1: 1991), SNMP, or MMS shall be used as the pro-
tocol for communicating management information between end systems in UCA compliant networks. CMIP
implementations shall also conform to the specific guidelines and agreements specified for CMIP in Chapter
18 of the NIST OIW Stable Implementation Agreements, 1994.
The mapping of CMIP/SNMP management information base (MIB) to MMS/UCA objects is an item for
future work. However, the use of MMS for network management is the recommended management proto-
col for profiles/implementation that have resource constraints or desire to implement a single application
protocol.

IEEE-SA
6.6 Security Architecture

Client or server applications that implement security shall implement security in the application layer using
a well defined authentication parameter. This section restricts its discussion of the use of security to those
profiles that utilize ACSE. Other profiles are out-of-scope.
There is a specific list of security threats that this section is intended to counter. These are:
Authorization violationAn authorized peer attempts to perform actions/functions for which the
peer is not authorized.
The appropriate security mechanism to counter this threat is the use of peer authentication coupled
with application level access-control. The specification of application level access control is out-of-
scope for this section.
EavesdroppingThe communication packets are being monitored by a system intruder.
This threat impacts the confidentiality of sensitive information. The appropriate security mecha-
nism to counter this threat is the encryption of sensitive information.
Information leakageDisclosure of information to an unauthorized entity.
This threat impacts the confidentiality of sensitive information. The threat may need to be coun-
tered with security services at both the client and server.
The appropriate server security mechanism to counter this threat is the use of peer authentication
coupled with application level access control. The access control and authentication mechanisms
for client applications is out-of-scope of this document. The range of possible solutions from hav-
ing application password login to the use of encrypted cards.
Intercept/AlterThe communication packets are intercepted by an intruder. The information in the
packets is then modified and forwarded to the original destination application. This threat poses
data integrity issues. The appropriate security mechanism to counter this threat is encryption.
MasqueradeThis threat is typically referred to as spoofing. An intruder attempts to gain system
access by pretending to be a different entity.
This threat poses a severe control and data confidentiality risk. The appropriate security mechanism
to counter this threat is the use of strong authentication.
ReplayA communication packet that has been obtained through eavesdropping is retransmitted
onto the network at a later time.
This threat can have severe consequences, especially if the captured packet contains control com-
mands. This threat can be countered through appropriate encryption coupled with dynamic encryp-
tion key management.
The key management mechanisms are out-of-scope for this section. The following list represents a set of
threats that this section is not intended to counter.
Bypassing controls
Denial of service
EM/RF
Interception
Illegitimate use
Indiscretions by personnel

IEEE-SA
Media
Scavenging
Physical intrusion
Resource
Exhaustion
Service
Spoofing
Theft
Traffic analysis
Trapdoor
Trojan horse
The identified security mechanism that this section shall specify are:
a) AuthenticationProvides the capability to identify an entity.

Information leakage can occur if authentication is associated with a client application and not the
user of the application. Therefore, profile supported address resolution is not sufficient to provide
authentication. The ACSE authentication-value parameter shall be used.
The NIST OIW Security agreements allow support for both simple and strong authentication. All
implementations claiming conformance to this section shall implement simple authentication. The
ability to support strong authentication is a local issue.
b) EncryptionProvides protection against information being disclosed or revealed to eavesdropping
intruders. It also provides limited protection against intercept/alter.
c) Access controlProvides protection to unauthorized use or manipulation of resources. This service
is an application specification and implementation issue and is therefore out-of-scope of this section.
Profiles that support the use of ACSE shall use the authentication parameter of ACSE Edition 3 and
follow the guidelines of the generic upper layer security specifications (GULS) (ISO/IEC 11586:
1996) and the NIST OIW Security Special Interest Group (SIG) agreements. In particular, this pro-
file recommends that the procedures described in ANSI T1.259-1997 (STASE-ROSE) be used.
However, this section makes recommendations for strong authentication.
The ACSE Edition 3 authentication-value production is to be used. This production is required to be
used in order to pass complex authentication value sequences, such as are needed in this section, in a
well defined ASN.1 format.
There are three levels of security that will be specified within this section:
1) No securityNot within the scope of this section.

2) Weak securitySecurity based upon password authentication only, which does not make use of
any encryption.
3) Strong securitySecurity based upon the algorithms and methodologies as set forth within
ISO/IEC 9594-3: 1995 and ISO/IEC 9594-8: 1995 and ANSI T1.259-1997.
The procedures defined in ANSI T1.259-1997 (STASE-ROSE or security transformation ASE-ROSE) for
implementing strong security are also applicable to MMS. While this standard was defined for use with
ROSE, there is nothing in it that is specific to ROSE. Also, this specification defines straightforward rules for
the including security services in an application. First, it defines the ACSE authentication mechanism and
authentication value syntax and semantics to be used, and defines an ASE for providing security services for
ASEs and ASOs in the data transfer phase. To provide security, the STASE is simply included in the ASO.

IEEE-SA
All PDUs (IA-Data.submit primitives) emitted by the ROSE ASE are passed to the STASE, which in turn
passes them to the presentation layer.
UCA implementations that require strong security shall follow the STASE-ROSE procedures, substituting
MMS for ROSE. The specific text edits required to change the ANSI T1.259-1997 document into one appli-
cable to MMS (as well as the details of applying DES-CBC encryption) are defined in Appendix C.
The PIXIT information for an implementation shall indicate the level of security enforcement available.
Additionally, the PIXIT shall indicate the minimum level of security required to be used in order to establish
an association with the implementation.
6.6.1 WEAK Authentication
Weak authentication shall be implemented per ISO/IEC 8650-1: 1996, Annex B.
Note: ISO/IEC 8650 is the ACSE specification and requires that the ACSE parameters be of the following
types or values:
Mechanism-name ::= {2,2,3,1}, specifying password only

Authentication-value ::= [0] IMPLICIT GraphicString
The authentication-value (password) shall be no greater than 128 octets in length. It is recommended that no
value be sent that is less than eight octets in length.
6.6.2 STRONG Authentication
The OBJECT IDENTIFIER for this AuthenticationMechanism shall be:
{iso member-body usa(840) ansi-t1-259-1997(0) stase(1) stase-pci(1) abstractSyntax(4) version1(1)}
It is not recommended that the AuthenticationValue used with this profile contain the two optional
components:
encryptedSymmetricalKey
certificate
The procedures described in ANSI T1.259-1997 are to be used. Algorithms may be chosen to fit the con-
straints of the application.
Alternatively, the credentials production from ISO/IEC 9545-3 can be used as the AuthenticationValue. In
this case, it is recommended that the optional CertificationPath for StrongCredentials not be used.
6.6.3 Strong Security for Data Transfer
For all security services for the data transfer phase such as confidentiality, integrity, etc., the procedures for
the SR-TRANSFER should be used. It is recommended that default values be used to the greatest degree
possible (DES CBC, etc.)
Note: All uses of strong security in the data transfer phase will require the use of the distinguished encoding
rules (DES).
Use of ACSE for Security and ISO/9506: 1990 (MMS)

IEEE-SA
a) The ACSE-PDVs shall not be encrypted.

b) The AARQ user-information parameter shall contain an OCTET STRING that is optionally security
transformed (signed) MMS initiate-RequestPDU as defined in Appendix C. Also:
1) The AARQ mechanism-name parameter shall not be present.
2) The calling-authentication-value shall be as defined in Appendix C.
c) The AARE user-information parameter shall contain an OCTET STRING that shall be optionally
security transformed (signed) MMS initiate-ResponsePDU. or initiate-ErrorPDU.
d) The AARE mechanism-name parameter shall not be present.
e) The responding-authentication-value shall be as defined in Appendix C.
f) The value of &type carried in the responding-authentication-value shall be ignored.
g) No security parameters are required for an RLRQ or RLRE.
h) If a called implementation receives an ACSE-pdu with an unrecognized mechanism-name, the
implementation shall return the appropriate ACSE-response-pdu with associate-source-diagnostic
acse-service-user=authentication-mechanism-name-not-recognized or abort the association.
i) If a called implementation receives an ACSE-pdu with no authentication-value, and the implementa-
tion requires the value, the implementation shall return the appropriate ACSE-response-pdu with
Associate-source-diagnostic acse-service-user=authentication-required or abort the association.
j) The validation of an authentication value is a local issue. However, if authentication fails, the imple-
mentation shall return the appropriate ACSE-response-pdu with associate-source-diagnostic acse-
service-user = authentication-failure or abort the association.
k) Encryption key management is outside the scope of this section.
6.7 Bridging Considerations
6.7.1 Transparent vs. Source Routing
Two different MAC-layer bridging algorithms are commonly used to enable bridges to transmit frames cor-
rectly between subnetworks. The first scheme is known as spanning tree or transparent bridging. With the
spanning tree approach, bridges learn the relative position of stations on the network when they first
receive a frame from that station. Subsequent frames are then forwarded or filtered based on this knowledge.
Additionally, the spanning tree algorithm (developed by IEEE 802.1 working group) determines the overall
topology of the subnetwork and ensures that although there may be closed loops physically in the subnet-
work for the sake of redundancy, they are prevented logically so that frames cannot loop endlessly within the
subnetwork. This scheme accomplishes bridging in a manner transparent to the end systems (i.e., there is
nothing incumbent upon the end system when transmitting frames across a bridged subnetwork).
IEEE 802.5 token ring specifies an alternate technique for routing through a bridged network that uses a
source routing algorithm. In this case, the sending end system determines the route that the frame will follow
and includes routing information with the frame. Bridges then forward the frame depending on the routing
information received within the frame. In such a scheme, the routing knowledge must be contained in the
end systems;, thus the scheme is not transparent to the end systems.
The result of the two bridging algorithms is an incompatibility between different LAN systems. The IEEE
802.1 working group is the official IEEE body responsible for standardizing LAN bridging. Currently, the
standard [IEEE Std 802.1d (MAC bridges)], which is still in draft form, specifies the spanning tree method.
Recently a proposal aimed at rectifying the incompatibility has been submitted to the IEEE 802.1 working
group as an addendum to the 802.1d draft (known as the SRT standard). The proposal provides for a way to

IEEE-SA
accommodate both spanning tree and source routing techniques while maintaining compatibility with exist-
ing spanning tree bridges.
However, until this new technique is approved and available in the marketplace, it is recommended that care
be taken to prevent bridging incompatibilities. Utilization of only transparent bridging in a given subnetwork
is one way to ensure compatibility. Because this approach is completely transparent to the end systems, it
will insure compatibility with the installed base. If it is known that all systems (both end systems, intermedi-
ate systems, and bridges) in a given subnetwork will support the source routing scheme, source routing can
be effectively used within that subnetwork. However, it is very important to recognize that the future stan-
dard will most likely be able to accommodate existing transparent bridges, but not existing source route
bridges.
6.7.2 Other Bridging Considerations
With multiple types of LANs, bridges should be able to translate from one MAC frame format to another.
Because bridges cannot segment larger data frames into smaller ones, the information field size will be lim-
ited to that of the LAN with the smaller maximum MAC frame size. So, for example, when bridging
between a token ring (maximum frame = 4 KBytes) and CSMA/CD (maximum frame = 1518 Bytes) LANs,
the maximum frame transmitted that must traverse both LANs is 1518 bytes. This is usually a software con-
figurable parameter in end systems.
Some bridge products, particularly those interconnecting FDDI networks to the lower speed LAN types
(e.g., CSMA/CD), do not in fact translate the frames but instead encapsulate the CSMA/CD frame in an
FDDI frame without removing the CSMA/CD protocol information or overhead. A second bridge, adjacent
to the destination end system, performs the opposite function. It removes the FDDI protocol overhead as it
forwards the original frame onto another CSMA/CD LAN. An encapsulation scheme can increase bridge
frame forwarding performance, but will also seriously limit the network configuration alternatives as well.
Encapsulation bridges are intended to use the FDDI ring strictly as a backbone network without any end sys-
tems connected directly to it. Such an approach limits the configuration possibilities by preventing commu-
nication from an end system on the low speed LAN to an end system directly attached to the FDDI ring.
Furthermore, it prevents communication between dissimilar low speed LANs, for example from a CSMA/
CD LAN to a Token Ring LAN over an FDDI network. Given these limitations, it is important to recognize
whether a bridge offered in the marketplace is encapsulating or translating as it forwards frames.
6.8 7-Layer/3-Layer Interworking

The 3-layer UCA specification is intended to meet a specific set of communications requirements within the
electric utility industry. As noted in Section 3, however, the communications services offered by this archi-
tecture are considerably more limited than those offered by the UCA 7-layer specification. One principal
limitation of the 3-layer architecture is that no network routing functionality is provided within the architec-
ture. Communication is therefore only possible within a single subnetwork segment. In large utility networks
where extended communications are required, for example, multiple distribution automation field devices,
the 3-layer and 7-layer architectures must interwork. This can be achieved using an application layer gate-
way as illustrated in Figure 16.
The 3-layer node (system 3) will be at the end of the extended network and connected via a single subnet-
work to System 2 which acts as the application layer gateway. This gateway is not unlike the gateways
required between legacy equipment and the UCA network. This system must support both the UCA 3-layer
and 7-layer protocol suites. Interaction is accomplished via the application layer standard (MMS) which is
common to both architectures. In the above configuration, therefore, system 2 maintains two separate MMS
dialogues, supporting requests from system 1 using the full function 7-layer communications architecture

IEEE-SA
System 1 System 2
7-layer Both
MMS MMS MMS
Presentation Presentation
Session Session System 3
Transport Transport 3-layer

Network Network MMS
Data link Data link Data link Data link
Physical Physical Physical Physical
Figure 16: 7-Layer/3-Layer Interworking
and also manages interaction with system 3 using the 3-layer communications architecture. Consequently,
system 2 must also contain the necessary application logic to enable successful data communications to be
accomplished between systems 1 and 3.
6.9 Conformance and Interoperability Testing

Conformance and interoperability testing will generally be necessary to ensure that a particular solution con-
forms to the UCA specification.
A general policy regarding testing requirements for UCA compliant products does not exist at the present
time. Such a policy is likely to be created for participating utilities in the future as the UCA and associated
users groups develop and mature. It should be noted that the utility industry does not have a central procure-
ment authority. Requirements for conformance, interoperability, and performance testing are therefore likely
to vary between utilities and will need to be specified in requests for proposals (RFPs) created for the pro-
curement of UCA compliant products and systems.
6.9.1 Conformance Testing
Conformance testing verifies that a protocol implementation performs as the standard specifies. Conform-
ance to standards included in the UCA Specification can be demonstrated as a result of thorough vendor test-
ing and documentation or through certification from an independent testing agency. Such tests are routinely
performed as part of the product development cycle. Due to the absence of industry-wide guidelines for con-
formance testing, procurement officers from individual utilities will be responsible for specifying acceptable
conformance tests, testing agencies, and results.
Conformance testing will provide additional confidence that a products protocol suite implementation will
interwork with those offered by different vendors products. No conformance test system, however, can
detect all of the potential problems that may occur in a protocol implementation in order to guarantee
interoperability. Consequently, interoperability testing is also necessary to ensure that user requirements in a
multi-vendor environment can be fully met.

IEEE-SA
Conformance testing can, however, be used to test an implementations response to error conditions that are
unlikely to occur during interoperability testing, but which may occur infrequently in field use.
6.9.2 Interoperability Testing
Interoperability tests simulate conditions under which the vendors product will actually function, by dupli-
cating as closely as possible the multi-vendor environment in which the product is to be used. Again, since
no general guidelines or central authority exists to mandate interoperability testing, it is the responsibility of
a utility's procurement officer to specify the products to be tested, a description of the test scenarios to be
performed, the expected results, and the criteria for passing and failing.
Interoperability test results can be requested and obtained in several ways. Specific testing requirements for
the particular procurement may be identified to the vendor who would then be required to develop, perform,
and supply results for the outlined test. Alternatively, a request could be made for statements of completion
of general interoperability tests that include a list of vendors tested, the specific functions tested, and the
results. Like conformance tests, general interoperability tests are routinely performed during product devel-
opment by both OSI product vendors and independent testing organizations.

IEEE-SA
Appendix A
UCA ASO Specification
This appendix provides the specification of the UCA service definition and UCA ASO3 control function
(CF). It is part of a set of documents that provide guidance and details to facilitate the implementation of
the protocols to support the remote operation of SCADA devices for the electric industry. These protocols
and profiles can be used in other contexts simply by defining a set of object definitions specific to that
environment.
The service definition specifies the abstract interactions that will be seen by a user of this application service
object (ASO) or by the provider of this service. The service definition, in effect, specifies a partial state
machine that must be incorporated into the state machine of any user or provider. One can also view this ser-
vice definition as defining the minimal language-independent application programming interface (API) for
this service.4
The CF specified here combines two standard application protocol components: the ASO-association control
service element (ACSE) for establishing application-associations and the manufacturing messaging service
(MMS) for remotely controlling equipment. This combination of ASEs driven by the UCA service definition
constitutes the application protocol for controlling SCADA devices. The profile for the upper layers is spec-
ified in another document.5
A.1 Definitions
This section provides some basic definitions that are used in this document. For a fuller explanation, the
reader should consult the OSI reference model (ISO 7498: 1994) and the application layer structure docu-
ment (ISO/IEC 9545: 1994, Edition 2).
application layer structure (ALS): The internal architecture of the OSI application layer as described in
ISO/IEC 9545: 1994, Edition 2.
application protocol data unit (APDU): An (N)-PDU, where N refers to the Application Layer.
application service element (ASE): A set of application functions that provides a capability for the inter-
working of application-entity-invocations for a specific purpose. ASEs are a component of application ser-
vice objects. An ASE can be considered to be a protocol module that is combined with others to form a
complete protocol.
application service object (ASO): An active element within (or equivalent to the whole of) the application-
entity embodying a set of capabilities defined for the application layer that corresponds to a specific ASO-
type (without any extra capabilities being used). An ASO is a combination of ASEs and ASOs that perform a
specific function. An ASO that provides the functions of the establishment and data transfer phases is con-
sidered a complete protocol.
association control service element (ACSE): The common mechanism in the ALS for establishing and
releasing ASO-associations.
3Application Service Object. See A.1 for definitions.

4 However, it should be noted that specific implementations may consist of fewer primitives or calls (in
effect masking complexity from the user), more primitives (including local functions not directly required by
the protocol), or of no primitives at all in that no explicit API may exist in the implementation.
5This is done to facilitate the definition of profiles that use this ASO specification, but may differ from one
another by the number of optional facilities used and the richness of their object models.

IEEE-SA
control function (CF): The component of an ASO that controls the interactions among the ASEs and/or
ASOs and the service provided by the containing ASO. The CF defines how the service primitive of the ser-
vice definition is mapped to the primitives of the component ASEs and ASOs.
manufacturing message protocol machine (MMPM): An abstract machine that carries out the procedures
specified in the MMS protocol specification (an MMS version of the ASE).
protocol data unit (PDU): A unit of data specified in an (N)-protocol and consisting of (N)-protocol-con-
trol-information and possibly (N)-user-data, where N indicates the layer, sometimes referred to as a packet,
segment, or message.
A.2 Overview
A.2.1 The UCA ASO

An application protocol for controlling SCADA or EFM devices does not require a complex use of the ALS
structure, but benefits from its use. The UCA ASO (shown in Figure A.1) consists of the ACSE and the MMS
ASE. (ACSE, the edition of ACSE that supports the second edition of ISO 9545, provides the basic mecha-
nisms for establishing and releasing an application association.) The service provided by the UCA ASO rep-
resents an abstract description of the application programming interface (API) seen by the SCADA
application. The CF of the ASO specifies how the interactions at the UCA ASO service boundary invoke the
appropriate service primitives of ACSE or MMS, which in turn generate the actual protocol.
UCA ASO
ASO Service Inputs
Control Function
Component ASE Service Inputs
A2CSE MMS
Lower Layer Mapping
Figure A.1: Schematic of the UCA ASO
The reader should note that this specification is not a complete service definition of the ASO or its compo-
nents. It only defines the action of the CF as a result of inputs from the client application (specified in A.5)
and the server application (specified in A.6) to the CF. Thus, the specification is organized around specifying
these inputs (as illustrated in Figure A.2). Section A.5.1 specifies the services that can be invoked by the cli-
ent application. Section A.5.2 specifies the behavior of the CF in terms of inputs to it from the client applica-
tion. Section A.6.1 specifies the services that are invoked by the server application. Section A.6.2 specifies
the behavior of the CF in terms of inputs to it from the server application. Section A.7.7 defines the actions
that result from inputs generated by the supporting service.
Note: This CF specification uses the new service convention notation (ISO/IEC 10731: 1994) for the ASO.
However, because the old service convention notation (ISO TR 8509) is used for the ACSE and MMS stan-
dards, it is used in this document when referring to these standards. While slightly confusing here, it should
make referring to the other documents easier. The reader should bear in mind that a request or response in
the TR 8509 nomenclature is equivalent to a submit in the ISO 10731 nomenclature and an indicate or con-
firm corresponds to a deliver.

IEEE-SA
UCA Client ASO UCA Server ASO
Client Server
UCA Client ASO UCA Server ASO

Service Definition Service Definition
APDUs
ACSE MMS ACSE MMS

UCA Client UCA Server
ASO Control Supporting Service ASO Control
Function Specification Mappings Function Specification
Supporting Service Supporting Service
Figure A.2: Organization of the UCA ASO Specification
A.2.2 UCA Service Definitions

This service definition characterizes the primitives available at the top of the UCA ASO. This service
provides the basic primitives for controlling a remote device. The following list identifies the required
primitives:
Open, which creates an association with the device.

Release, which closes the association.
Abort, which abruptly terminates the association.
UCA MMS-request, which causes a request for an operation to be sent to a device.
UCA-MMS response, which causes the device to generate a response indicating whether the
requested operation has been performed.
UCA-MMS-information-report, which sends an unsolicited notification of the occurrence of an
event.
Note: This specification does not impose a master/slave model on the application. In some implementations,
however, only one side may generate requests and the other side may generate only responses. While not
always necessary, some profiles may want to make it explicit when this constraint is required.
A.2.3 State Definitions for the Service

This section defines the states for the UCA service definition. A service definition constrains both the service
user and the service provider. This service definition defines behavior that must be incorporated into the state
machine of any user or provider of this service. The following states are defined for each service boundary
(see Figure A.3).
NULLThis is the state of the service when there is insufficient shared state with a peer application
capable of supporting communication (i.e., there is no connection in place or pending). Only open or
abort primitives may occur in the NULL state.

IEEE-SA
ASSOCIATION PENDINGThe service enters this state either when the service user has made a
request to establish an association and is waiting for notification from its peer (i.e., remote application-
entity) or the service provider has notified the service user of an attempted association and is waiting for
notification from the service user as to the acceptance or rejection of the association.
DATA TRANSFERThe service enters this state once the connection establishment phase is complete
and there exists sufficient shared state with its peer to support communication.
RELEASE PENDINGThe service enters this state either when the service user has made a request to
release an association and is waiting for notification from its peer OR the service provider has notified
the service user of a request to release the association and is waiting for notification from the service
user that the release has been accepted.
Note: This document defines only the conditions under which service primitives are generated and any sub-
sequent action independent of the protocol.
Abort
Release
Open NULL Response (NG)
Request or Abort
Open RELEASE
Response (-)
or Abort Abort PENDING
ASSOCIATION Release
PENDING Response (-)
Release
Request(G)
DATA
Open TRANSFER
Response (+)
NG = Non-graceful release
G = Graceful release
+ = Positive response
UCA MMS Service - = Negative response
Primitives
Figure A.3: UCA Service State Diagram
A.2.4 State Definitions for the Control Function

For the UCA CF specification, the following states are defined (see Figure A.4).
NULLThis is the state of the protocol entity when there is no association either being created or cur-
rently established.
ASSOCIATION PENDINGThe protocol entity enters this state either when the service user has made
a request to establish a connection and is waiting for notification from its peer OR the service provider
has notified the service user of an attempted connection and is waiting for notification from the service

IEEE-SA
user as to the acceptance of the connection.

IDENTIFY PENDINGThe initiating protocol entity enters this state when the Association Response
primitive has been received and the user has requested the identification of the remote device.
TRANSFERThe protocol entity enters this state once the connection establishment phase is com-
plete. This condition is met when a control function in the CONNECTION PENDING state was the ini-
tiator and receives an A-associate confirm service primitive or is the recipient and receives an A-
associate indicate primitive.
RELEASE PENDINGThe protocol entity enters this state when the service user has requested the
termination of the connection and the protocol entity is waiting confirmation of the disconnect from its
peer protocol entity.
UCA Open-Req/ NULL A-Rls Rsp/

A-Assoc Req UCA Rls Rsp
RELEASE
A-Assoc Rsp (-)/ PENDING
UCA Open Rsp (-)
UCA Rls Req/
ASSOCIATION ARls-Req
PENDING Identify Rsp (-)/
A-Abort & UCA OpenRsp (-) A-Rls Rsp (-)/
UCA Rls Rsp (-)
* A-Assoc
Rsp (+)/
UCA Open Rsp (+)
IDENTIFY
A-Assoc (+)Rsp / TRANSFER
Identify Req PENDING All Other
Identify Rsp (+)/ MMS Services
UCA Open Rsp (+)
G = Graceful
NG = Non-Graceful MMS-Information-Report, if mapped to A-Unit Data may
be sent any time. Rls Req (NG) and an A-Abort may occur
in any state.
* This transition occurs if no Identify is required.
Figure A.4: UCA ASO State DiagramConnection-mode
A.3 Application Context

The ACSE (ISO/IEC 8649: 1996) establishes an application context for the application associations. The
application context identifies the set of ASEs their options, the rules for their usage, and the rules for their
effects that are available upon application association.
When an MMS application context is established, the rules for the establishment of an association and for
data transfer are as defined in ISO/IEC 9506-1: 1990 and ISO/IEC 9506-2: 1990. Each instance of commu-
nication is governed by the MMS core abstract syntax (defined in Clause 19 of ISO/IEC 9506-2). This stan-
dard uses the abstract syntax notation as defined in ISO/IEC 8824-2: 1995. No provision has been made for
companion standards.

IEEE-SA
For the purpose of being able to use an application that only contains the ACSE and MMS as ASEs (ASO),
the object identifier value
{iso standard 9506 part(2) mms-application-context-version1(3)}
and the object descriptor value
ISO MMS
are assigned to an information object of type
ACSE-1.ApplicationContextName
as defined in ISO/IEC 8650-1: 1996. Although this object identifier is assigned in this part of ISO/IEC 9506:
1990, and therefore includes the arc part (2), this application context name shall refer to the requirements
placed by ISO/IEC 9506-1: 1990 and ISO/IEC 9506-2: 1990.
For the purposes of mapping onto Fastbyte layers, this parameter shall be viewed as optional and shall be
ignored by the receiving entity.
A.4 Presentation Context
A.4.1 Abstract Syntax

No negotiation of the MMS abstract syntax is allowed, only acceptance or rejection of an association with an
MMS ASE. The initiate service provides the mechanism for entering the MMS environment. If the initiate-
request is not formed in accordance with the MMS core abstract syntax as defined in ISO/IEC 9506-2: 1996
or any other PDU is used, then an association is rejected out of hand. Otherwise, the request for communica-
tion is accepted or rejected by accepting or rejecting the associated presentation context. No other abstract
syntax is accepted for MMS data transfer.
This part of ISO/IEC 9506 assigns the ASN.1 object identifier value
{iso standard 9506 part(2) mms-abstract-syntax-version(1)}
as an abstract syntax for the set of presentation data values each of which is a value of the ASN.1 type MMS-
General-1MMSpdu. The ASN.1 Module defined in Clause 19 shall define this abstract syntax. The corre-
sponding ASN.1 object descriptor value shall be as follows:
mms-general-module-major-version1
A.4.2 Transfer Syntax

The transfer syntax for MMS is defined by the application of the ASN.1 basic encoding rules (ISO/IEC
8825-1: 1995) to the MMS abstract syntax.
The ASN.1 basic encoding rule object identifier and object descriptor values are as follows:
{joint-iso-ccitt asn1(1) basic-encoding(1)}
and

IEEE-SA
Basic Encoding of a single ASN.1 type
The ASN.1 packed encoding rule (BASIC-PER-ALIGNET) object identifier and object descriptor values are
as follows:
{joint-iso-ccitt asn1(1) packed-encoding(3) basic(0) aligned(0)}
and
Packed encoding of a single ASN.1 type (basic aligned)
The UCA profile uses the Fastbyte recommendations for the establishment phase. In the instance where
Fastbyte presentation is to be applied, the protocol version parameter values allowed shall be as identified in
Table A.1.
Table A.1
Protocol Version
MMS and ASN Represented
Parameter (Hex)
mms-general-model-major-version 1
00
via bilateral agreement (e.g., for encryption)
01*
{joint-iso-ccitt asn1(1) basic-encoding(1)}
02
{joint-iso-ccitt asn1(1) packed-encoding(3) basic(0) unaligned (1)}
03
{joint-iso-ccitt asn1(1) packed-encoding(3) basic(0) aligned (0)}
*Note the implementation agreement section on the sole use of the value of 01.
The major version number of this version of ISO/IEC 9506-1: 1990 and ISO/IEC 9506-2: 1990 shall be one.
The minor version number of this version of ISO/IEC 9506-2: 1990 shall be one.
A.4.3 Presentation-Context-IDs
For the data transfer phase, the UCA will generate a standard presentation data PDU (i.e., a PDV list). The
following P-context-ids will be assigned for this profile:
ACSE APDUs 1
MMS APDUs 3
A.5 UCA Client ASO

This section specifies the services and control functions that are invoked by the client application (a host
application SCADA or measurement control center) which, in general, initiates a request to the destination
application (generally the desired SCADA or EFM device).
A.5.1 UCA Client ASO Service Definition

This section specifies the services that can be invoked by the client application (see Figure A.5).

IEEE-SA
Control
RTU or EFM
Center
Application
Application
(Server)
(Client)
Request.submit Request.deliver
primitive primitive
Request PDU
ASO ASO
Figure A.5: Service Primitive and PDU Flow in a Typical UCA Client Application
A.5.1.1 Initiator UCA Open Service
These primitives are used by a client application to request an association with a server application.
A.5.1.1.1 UCA Open-Request.submit
This primitive is used to request the creation of an association between the initiator (generally a host applica-
tion SCADA or measurement control center) and the destination application (generally the remote device).
When invoked: This primitive is invoked when the client (the initiating service) is in the NULL state and
wishes to create an association with a remote application. The service transitions from the NULL state to the
ASSOCIATION PENDING state.
Action upon receipt: When the CF receives this primitive, it uses the information in the parameters to invoke
an MMS-Initiate Request primitive.
A.5.1.1.2 UCA Open-Request.deliver
This primitive is to notify the server application (generally the RTU) of a new request for an association.
When invoked: This primitive is invoked when the recipient application is in the NULL state to notify the
user that a request to create a new association to its application has been received.
Action upon receipt: When the server receives this primitive, it uses the information in the parameters of the
A-associate indication primitive to determine whether or not it will accept the new association. The server
transitions from the NULL state to the ASSOCIATION PENDING state.
A.5.1.1.3 Parameters
Destination-application-title: This optional parameter specifies the application on the RTU to be accessed. It
is sent if there is more than one application on the RTU.

IEEE-SA
Source-application-title: This optional parameter specifies the source application sending the request. It is
sent if there is more than one application on the RTU.
Password: This optional parameter specifies the user code and password for the application.
Concrete syntax: This optional parameter allows the user to specify that the protocol is to be encoded in a
concrete syntax other than the default bit-oriented PER.
QoS: This parameter specifies the quality of service (e.g., delay, error rate, etc.) required for this association.
RTU-info: This parameter specifies information about the remote application derived from the MMS initiate
and identify APDUs.
Reason: If a request for an association fails, this parameter is used to indicate the reason for the failure. See
the ISO/IEC 8650-1:1996 (ACSE) and ISO/IEC 9506-2:1990 (MMS) for the complete set of possible failure
reasons.
A.5.1.2 UCA Release Request Service
This request is used to release the association between the RTU and the control center.
A.5.1.2.1 UCA Release-Request.submit
When invoked: This primitive may be invoked by the user when it is in any state.
Action upon receipt: If the provider is in the NULL state, it will invoke a UCA Release-Response.deliver
primitive to the local application and remain in the NULL state.
If the graceful flag is set:
If the CF is in the association pending state, then the CF generates an A-abort to the peer and a positive
UCA Release-Response.deliver to the local application.
If the CF is not in the ASSOCIATION PENDING state, the CF will invoke an MMS conclude request
primitive and map the resulting MMS conclude request APDU to the user information parameter of an
A-release request primitive. The A-release request is invoked and the CF transitions to the RELEASE-
PENDING state.
If the Graceful flag is not set:
An A-abort is invoked and a positive UCA release response.deliver is invoked to the local application.
The CF transitions to the NULL state.
A.5.1.2.2 UCA Release-Request.deliver
When invoked: This primitive is invoked by the CF when it receives an A-release indicate primitive. The CF
transitions to the RELEASE PENDING state.
Action upon receipt: When a UCA Release-Request.deliver primitive is invoked, the application takes any
local actions to terminate the association which may or may not be successful. The user invokes a UCA
Release-Response.submit primitive. The CF transitions to the RELEASE PENDING state.

IEEE-SA
Graceful/non-graceful flag: This parameter indicates whether the release of the association is to be graceful
or not. If the nongraceful flag is set, then the association is abruptly terminated. If the graceful flag is set,
then the UCA protocol machine notifies its peer that it is releasing the association.
Reason: This parameter indicates the reason for the release. See ISO/IEC 8650-1:1996 (ACSE) for the com-
plete set of possible release reasons.
A.5.1.3 UCA-MMS Primitives
Since the MMS primitives are transparently invoked, the behavior for all MMS primitives, except initiate
and identify, and conclude, is the same. Thus, all MMS services used by the client/server except initiate,
identify and conclude will obey the behavior specified by this section.
A.5.1.3.1 UCA-MMS Request.submit
When invoked: The UCA-MMS Request.submit primitive is invoked by the initiating user/service when in
the DATA TRANSFER phase.
Action upon receipt: When the UCA-MMS Request.submit is received, the CF causes an appropriate MMS
Request operation to be generated and communicated to its peer.
A.5.1.3.2 UCA-MMS Request.deliver
When invoked: The UCA-MMS Request.deliver primitive is invoked when the responding device is notified
by the initiator that it wants an MMS operation performed.
Action upon receipt: When a UCA-MMS Request.deliver primitive is received, the appropriate MMS opera-
tion is performed and a UCA-MMS- Response.submit primitive is generated.
A.5.2 UCA Client ASO Control Function Specification

This section specifies the behavior of the CF in terms of inputs to it from the client application (either from
the user of the UCA ASO or the components of this ASO), as illustrated in Figure A.6. Section A.5.1.6
defines the actions of the CF that result from inputs generated by the user of this ASO. Section A.5.2.2
defines the actions that result from inputs generated by the ACSE component ASE of this ASO. Section
A.5.2.3 defines the actions that result from inputs generated by the MMS component ASE of this ASO.
A.5.2.1 UCA Service Inputs to the Control Function
This section defines the actions that result from inputs generated by the user of this ASO (see Figure A.6).
This is not a complete service definition of the supporting service, but only the inputs generated by the UCA
service to the CF.
A.5.2.1.1 UCA Open Service
This service is used to request the creation of an association between the initiator (generally a host applica-
tion SCADA or measurement control center) and the destination application (generally the desired SCADA
or EFM device).

IEEE-SA
Client
UCA Service
Inputs to the
Control Function
ACSE MMS
UCA ACSE UCA MMS

Inputs to the Inputs to the
Control Function Control Function
Supporting Service
Figure A.6: Client ASO Organization
A.5.2.1.2 UCA Open-Request.submit
When invoked: This primitive is invoked when the provider is in the NULL state and the user requests that
an association be created with the remote application.
Action upon receipt: When this request is generated, the CF invokes the MMS-initiate service.
UCA release service: This request is used to release the association between the RTU and the control center.
A.5.2.1.3 UCA Release-Request.submit
When invoked: This primitive can be invoked in any state.
Action upon receipt: When the CF receives this request and is in the NULL State, it generates a UCA
Release-Response.deliver to the user and remains in the NULL state.
Otherwise, the CF is not in the NULL state:
If the CF is in the ASSOCIATION PENDING state, the CF generates an A-abort and a positive UCA
Release-Response.deliver and transitions to the NULL state.
If the CF is not in the ASSOCIATION PENDING state, the CF will generate an MMS-Conclude
Request primitive for the MMS ASE, map the resulting MMS Conclude APDU to the User parameter of
an IA Data Submit primitive.
UCA abort service: The abort service is used to relinquish the association between the RTU and the control
center without negotiation (due to local or remote conditions). The effect of the abort service is to destroy
previously issued requests and/or responses issued by the service users. The UCA abort service is directly
mapped to the ACSE A-ABORT and A-P-ABORT services.

IEEE-SA
A.5.2.1.4 UCA Abort-Request.submit
When invoked: This primitive can be invoked when a service user chooses to terminate an association
abruptly. The CF can be in any state.
Action upon receipt: The UCA ASCE ASE will generate an A-abort request primitive (mapped to an ACSE
ABRT APDU) for the CF. The CF generates a UCA abort indication for the service user. The UCA ASO and
CF will transition to the NULL state.
If the abort request was generated by the local system, then the locally generated parameter in the UCA
abort indication primitive will specify true. Otherwise, this parameter will specify the value False.
UCA-MMS service primitives: Since the MMS primitives are transparently invoked, the behavior for all
MMS service primitives, except initiate, identify, and conclude, is the same. Thus, all MMS services used by
the client/server, except initiate, identify, and conclude, will obey the behavior specified by this section. For
the definition of each of the MMS services, refer to ISO/EIC 9506-1: 1990 and ISO/EIC 9506-2: 1990.
A.5.2.1.5 UCA-MMS-Request.submit
When invoked: This primitive may be invoked once the ASO is in the TRANSFER state.
Action upon receipt: When the CF receives this primitive, it will generate an appropriate MMS Request
primitive to the MMS ASE.
A.5.2.2 ACSE Inputs to the Control Function

This section defines the actions that result from inputs generated by the ACSE component ASE of this ASO
(see Figure A.6). This is not a complete service definition of this ASE, but only the inputs generated by this
ASE to the CF. For a detailed description of ACSE, the reader is directed to ISO/IEC 8649: 1996.
ACSE will be used to provide the application layer connection establishment and authentication. If required,
there are several optional fields in the association request of ACSE that may be used:
Application entity title: These naming fields will be used when there is more than one application
on the RTU that can be independently accessed.
Authentication fields: These will be used when it is necessary to carry passwords.6
Presentation context field: This field can be used to specify the encoding of encapsulated messages.
ACSE provides the protocol support for releasing or aborting the connection. For a detailed description of
ACSE, the reader is directed to ISO/IEC 8650: 1996 and ISO/IEC 8649: 1996.
A.5.2.2.1 A-Associate Indication
When invoked: This primitive is invoked when the provider is in the NULL state and a request is received for
an association to be created with a remote application. The CF transitions from the NULL state to the
ASSOCIATION PENDING state.
Action upon receipt: When the primitive is received, the initiate APDU is delivered to the MMS ASE. A UCA
Open-Request.deliver primitive is invoked to notify the application of the request for a new association.
6 This is provided as an initial facility. More sophisticated security mechanisms can be supported and are for
further study. The mechanisms required will depend on the specific network. One should consult generic
upper layers security specifications.

IEEE-SA
If the user data field of the A-ASSOCIATE.indication service primitive does not contain any correctly
formed MMS PDUs as defined by ISO/IEC 9506-1: 1990, the responder shall issue an A-ASSOCI-
ATE.response service primitive with the result parameter rejected and no MMS PDUs in the user data field.
A.5.2.2.2 A-Release Indication
When invoked: This primitive may be received in any state except the ASSOCIATION PENDING state.
Action upon receipt: When invoked, the CF will take the MMS conclude request APDU from the user-infor-
mation parameter of the A-release indicate and deliver it to MMS. The information from the resulting MMS
conclude indicate primitive will be mapped to the UCA Release-Request.deliver primitive delivered to the
application. The CF transitions to the RELEASE PENDING state.
A.5.2.2.3 A-Abort Indication
When invoked: This primitive may be invoked at any time.
Action upon receipt: When ACSE delivers an A-abort indication to the CF, it will notify the user with a pos-
itive UCA Release-Response.submit primitive and the ASO and the CF transitions to the NULL state.
A.5.2.3 MMS Inputs to the Control Function
This section defines the actions that result from inputs generated by the MMS component ASE of this ASO
ASE to the CF. For a detailed description of MMS, the reader is directed to ISO 9506.
A.5.2.3.1 MMS-Identify Indicate
When invoked: This primitive is invoked when the receiving ASO is in the TRANSFER state.
Action upon receipt: When the UCA ASO receives an MMS identify indication service primitive, it extracts
the device identification information and generates an MMS identify response primitive.
A.5.2.4 MMS Service Primitives
Since the MMS primitives are transparently invoked, the behavior for all MMS primitives is the same,
except initiate, identify, and conclude. Thus, all MMS services used by the client/server except initiate, iden-
tify, and conclude, will obey the behavior specified by this section.
A.5.2.4.1 MMS Service Indicate
When invoked: This primitive is invoked when the CF is in the TRANSFER state.
Action upon receipt: When the MMS indicate is invoked by the MMS ASE, the CF generates a UCA-MMS
Request.deliver to the application.
A.5.2.4.2 MMS Conclude Indicate
When invoked: This primitive is invoked by the CF as part of the release procedure.
Action upon receipt: When the indicate is invoked, the CF maps the information from the conclude indicate
to the UCA Release-Request.deliver primitive and delivers it to the application to notify it that the peer

IEEE-SA
intends to release the association. If the application and the CF are ready to release the association, the CF
should take any necessary steps to prepare for closing the association and respond positively with the UCA
Release-Response.submit. If the application or the CF cannot close the association at this time (e.g., due to
outstanding requests), the CF should respond negatively with the UCA Release-Response.submit.
A.6 UCA Server ASO

This section specifies the services and control functions that can be invoked by the server application (a
SCADA or EFM device) in reply generally to a request from the client application (usually a host applica-
tion SCADA or measurement control center).
A.6.1 UCA Server ASO Service Definition

This section specifies the services that are invoked by the server application (see Figure A.7).
Control RTU or EFM

Center Application
Application
(Server)
(Client)
Response.deliver Response.submit
primitive primitive

ASO ASO
Response PDU
Figure A.7: Service Primitive and PDU Flow in a Typical UCA Server Application
A.6.1.1 UCA Open Service Responses
These primitives are server responses to client UCA open requests.
A.6.1.1.1 UCA Open-Response.deliver
This response is delivered to the initiator to indicate the success or failure of a previous UCA Open-
Request.submit primitive.
When invoked: This primitive is invoked when the service is in the ASSOCIATION PENDING state and is
notified by the provider that an association request with the remote application has been successful or not.
Action upon receipt: If unsuccessful, the primitive transitions from the ASSOCIATION PENDING state to
the NULL state.

IEEE-SA
If successful, the user transitions from the ASSOCIATION PENDING state to the DATA TRANSFER state.
The application now has information on the capabilities supported by the remote application as well as the
type of device that it is.
A.6.1.1.2 UCA Open-Response.submit
The server invokes this primitive to indicate whether or not it is willing to accept the new association.
When invoked: This primitive is invoked when the service is in the ASSOCIATION PENDING state.
Action upon receipt: When the CF receives a UCA Open-Response.deliver primitive from the server, it uses
the information in the parameters to invoke an A-association confirm primitive. If the server has accepted the
association request, the service transitions from the ASSOCIATION PENDING state to the DATA TRANS-
FER state.
If the server has rejected the association request, the service transitions from the ASSOCIATION PENDING
state to the NULL state.
Destination-application-title: This optional parameter specifies the application on the RTU to be accessed. It
is sent if there is more than one application on the RTU.
Source-application-title: This optional parameter specifies the source application sending the request. It is
sent if there is more than one application on the RTU.
Password: This optional parameter specifies the user code and password for the application.
Concrete syntax: This optional parameter allows the user to specify that the protocol is to be encoded in a
concrete syntax other than the default bit-oriented PER.
QoS: This parameter specifies the quality of service (e.g., delay, error rate, etc.) required for this association.
RTU-info: This parameter specifies information about the remote application derived from the MMS initiate
and identify APDUs.
Reason: If a request for an association fails, this parameter is used to indicate the reason for the failure. See
ISO/IEC 8650-1:1996 (ACSE) and ISO/IEC 9506-2:1990 (MMS) for the complete set of possible failure
reasons.
A.6.1.2 UCA Release Service Responses
This response is used to release the association between the RTU and the control center.
A.6.1.2.1 UCA Release-Response.submit
When invoked: This primitive may be invoked by the user when the CF is in the RELEASE PENDING state.
Action upon receipt: When this primitive is invoked, the CF will invoke an MMS conclude response primi-
tive and map the resulting MMS conclude response APDU to the user-information parameter of the A-
release response primitive.
If the response is positive, the A-release response is invoked and the CF transitions to the NULL state.
If the response is negative, the A-release response is invoked and the CF transitions to the TRANSFER state.

IEEE-SA
A.6.1.2.2 UCA Release-Response.deliver
When invoked: This primitive is invoked by the CF to notify the application that the release has or has not
been successful.
Action upon receipt: If successful, the user transitions to the NULL state.
If unsuccessful, the user transitions to the TRANSFER state.
Graceful/non-graceful flag: This parameter indicates whether the release of the association is to be graceful
or not. If the non-graceful flag is set, then the association is abruptly terminated. If the graceful flag is set,
then the UCA protocol machine notifies its peer that it is releasing the association.
Reason: This parameter indicates the reason for the release. See ISO/IEC 8650-1:1996 (ACSE) for the com-
plete set of possible release reasons.
A.6.1.3 UCA-MMS Primitives
Since the MMS primitives are transparently invoked, the behavior for all MMS primitives, except initiate
and identify, and conclude, is the same. Thus, all MMS services used by the client/server, except initiate,
identify and conclude will obey the behavior specified by this section.
A.6.1.3.1 UCA-MMS Response.submit
When invoked: When the recipient user has performed the requested operation, it will invoke a UCA-MMS
Response.submit primitive to notify the initiator of the success or failure of the request.
Action upon receipt: When the UCA-MMS Response.submit is received, the recipient invokes the appropri-
ate MMS response primitive.
A.6.1.3.2 UCA-MMS Response.deliver
When invoked: A UCA-MMS Response.deliver primitive is generated when the initiator is notified that a
response to a UCA-MMS operation has been received.
Action upon receipt: Any action upon receipt of a UCA-MMS Response.deliver primitive is specific to the
initiating application and outside the scope of this specification.
A.6.1.3.3 UCA-MMS-Unconfirmed-Service.submit
This operation provides the means for an object to send unsolicited information to its SCADA controller.
When invoked: When an event occurs, a UCA-MMS-Unconfirmed-Service.submit primitive is invoked by

the RTU to its control application.
Note: Unconfirmed-services can use either connectionless or connection-mode supporting services. When
unconfirmed-services are mapped to a connectionless service, it is not necessary that there be an existing
application association between the two applications. A connectionless service, however, will not, in gen-
eral, have the reliability that a connection-oriented service will have.
Action upon receipt: The RTU will send an MMS unconfirmed-service to its control application.

IEEE-SA
A.6.1.3.4 UCA-MMS-Information-Report.deliver
When invoked: This primitive may be invoked once the initiator is in the TRANSFER state and an MMS-
unconfirmed-service indicate primitive is invoked.
Action upon receipt: The initiator delivers the information to the application. The MMS parameters are
mapped directly to the parameters of the information-report primitive. All action upon receipt of a UCA-
MMS Unconfirmed-Service.deliver primitive is specific to the receiving application.
Variable access specification: This parameter shall convey the object/attributes to be set.
List of access result: This parameter shall contain the values of the specified attributes in the order specified
by the VariableAccess Specification parameter. Each element of the list shall be an access result, which
either specifies the value of the real attribute at the time of access after applying the variables type descrip-
tion and alternate access (if applicable), or a reason for access error.
A.6.2 UCA Server ASO Control Function Specification

This section specifies the behavior of the CF in terms of inputs to it from the server application (either from
the user of this ASO or the components of this ASO), as illustrated in Figure A.8. Section A.6.1 defines the
actions that result from inputs generated by the user of this ASO. Section A.6.2.2 defines the actions that
result from inputs generated by the ACSE component ASE of this ASO. Section A.6.2.3 defines the actions
that result from inputs generated by the MMS component ASE of this ASO.
Server
UCA Service
Inputs to the
Control Function
ACSE MMS
UCA ACSE UCA MMS

Inputs to the Inputs to the
Control Function Control Function
Supporting Service
Figure A.8: Server ASO Organization

IEEE-SA
A.6.2.1 UCA Service Inputs to the Control Function
This section defines the actions that result from inputs generated by the user of this ASO (see Figure A.8).
This is not a complete service definition of the supporting service, but only the inputs generated by the UCA
service to the CF.
A.6.2.1.1 UCA Open Service
This service is used to request the creation of an association between the initiator (generally, a host applica-
tion SCADA or measurement control center) and the destination application (generally, the desired SCADA
or EFM device).
A.6.2.1.1.1 UCA Open-Response.submit
This response is delivered to the initiator to indicate the success or failure of a previous UCA Open-
Request.submit Primitive.
When invoked: When the application has been notified of a new request for an association, it responds with
a UCA Open-Response.submit primitive.
Action upon receipt: The CF will generate a response to the MMS-initiate response. The MMS-initiate
response APDU generated as a result will be mapped to the user information field of the ACSE A-associate
response primitive with the appropriate parameters to accept or to refuse the association. If the new associa-
tion is accepted, then the CF transitions to the TRANSFER state. If the new association is refused, the CF
transitions to the NULL state.
UCA release service: This response is used to release the association between the RTU and the control
center.
A.6.2.1.2 UCA Release-Response.submit
When invoked: This primitive is invoked by the application when the CF is in the RELEASE PENDING
state and is waiting to confirm the release of the association.
Action upon receipt: If the response is positive, an A-release response primitive is generated with an MMS
conclude response APDU mapped to the user information parameter and the CF transitions to the NULL
state.
If the response is negative, the CF transitions to the TRANSFER state and a negative UCA Release-
Response.deliver primitive is generated.
UCA-MMS service primitives: Since the MMS primitives are transparently invoked, the behavior for all
MMS service primitives, except initiate, identify, and conclude, is the same. Thus, all MMS services used by
the client/server, except initiate, identify, and conclude, will obey the behavior specified by this section. For
the definition of each of the MMS services, refer to ISO/IEC 9506-1: 1990 and ISO/IEC 9506-2: 1990.
A.6.2.1.3 UCA-MMS-Response.submit
When invoked: This primitive may be invoked once the ASO is in the TRANSFER state, an appropriate
UCA-MMS-Request.deliver primitive has been invoked, and the requested operation has been performed.
Action upon receipt: The CF maps the parameters of the UCA-MMS response primitive to the appropriate
MMS primitive and generates an appropriate MMS-response to the MMS ASE.

IEEE-SA
A.6.2.1.4 UCA-MMS-Information-Report.submit
This operation provides the means for an object to send unsolicited information to its SCADA controller.
When invoked: This primitive may be invoked once the ASO is in the TRANSFER state when using a con-
nection-mode service. This service can also be mapped to a connectionless supporting service which is, in
essence, stateless.
Action upon receipt: The CF will send an MMS information-report to the MMS ASE.
A.6.2.2 ACSE Inputs to the CF
This section defines the actions that result from inputs generated by the ACSE component ASE of this ASO
ASE to the CF. For a detailed description of ACSE, the reader is directed to ISO/IEC 8649: 1996.
ACSE will be used to provide the application layer connection establishment and authentication. If required,
there are several optional fields in the association request of ACSE that may be used:
Application entity title: These naming fields will be used when there is more than one application
on the RTU that can be independently accessed.
Authentication fields: These will be used when it is necessary to carry passwords.
Presentation context field: This field can be used to specify the encoding of encapsulated messages.
ACSE provides the protocol support for releasing or aborting the connection. For a detailed description of
ACSE, the reader is directed to ISO/IEC 8650-1: 1996 and ISO/IEC 8649: 1996.
A.6.2.2.1 A-Associate Confirm Primitive
When invoked: This primitive is invoked by ACSE when the CF is in the ASSOCIATION PENDING state.
Action upon receipt: If this primitive indicates that the association has been refused, the negative response
from the A-associate request and/or the initiate APDU are delivered to the MMS ASE, and a negative
response is invoked in a UCA Open-Response.deliver primitive to the application. The information from the
MMS initiate primitive is mapped to the RTU-info parameter. The CF transitions to the NULL state.
If the primitive indicates that the association has been accepted and the initiator has requested the identity of
the device, an MMS identify request service primitive is invoked to the MMS ASE and the ASO transitions
to the IDENTIFY PENDING state.
If the primitive indicates that the association has been accepted and the initiator has not requested the iden-
tity of the device, the results of the A-associate and MMS initiate primitives are included in the positive
UCA Open-Response.deliver primitive to the application. The information from the MMS initiate primitive
is mapped to the RTU-Info parameter. The CF transitions to the TRANSFER state.
A.6.2.2.2 A-Release Confirm
When invoked: This primitive is invoked by the ACSE ASE to confirm the release of the association.
Action upon receipt: When the CF is in the RELEASE PENDING state, the CF will take the MMS conclude
response APDU from the user information parameter of the A-release confirm and deliver it to MMS. The
information from the resulting MMS conclude confirm primitive will be mapped to the UCA Release-
Response.deliver primitive delivered to the application. The CF transitions to the NULL state.

IEEE-SA
A.6.2.3 MMS Inputs to the Control Function

This section defines the actions that result from inputs generated by the MMS component ASE of this ASO
ASE to the CF. For a detailed description of MMS, the reader is directed to ISO 9506.
A.6.2.3.1 MMS-Identify Confirm
When invoked: This primitive is invoked when the receiving ASO is in the TRANSFER state.
When the MMS ASE receives a response to the identify request, it generates an MMS identify confirm
primitive.
Action upon receipt: When the initiating UCA ASO receives an MMS identify confirm service primitive, it
maps the information from the previously received MMS initiate confirm and along with the information
from the MMS identify, maps it to the RTU-info parameter and delivers a UCA Open-Response.deliver ser-
vice primitive to the application.
If results of the A-associate confirm, MMS initiate confirm, and MMS identify were positive, the CF then
transitions to the TRANSFER state.
If the results of any of the A-associate confirm, MMS initiate confirm, and MMS identify were negative, the
CF generates an A-abort primitive and transitions to the NULL state.
A.6.2.4 MMS Service Primitives
Since the MMS primitives are transparently invoked, the behavior for all MMS primitives is the same,
except initiate, identify, and conclude. Thus, all MMS services used by the client/server except initiate, iden-
tify, and conclude, will obey the behavior specified by this section.
A.6.2.4.1 MMS Service Confirm
When invoked: This primitive is invoked when the CF is in the TRANSFER state.
Action upon receipt: When the MMS confirm is invoked by the MMS ASE, the CF generates a UCA-MMS
Response.deliver to the application.
A.6.2.4.2 MMS-Conclude Confirm
When invoked: This primitive is invoked by the CF as part of the release procedure.
Action upon receipt: When the conclude confirm primitive is invoked, the CF maps the information from the
conclude confirm primitive to the UCA release/response.deliver and delivers it to the application. If the
response is positive, the CF transitions to the NULL state. If the response is negative, the CF transitions to
the TRANSFER state.
A.6.2.4.3 MMS-Information-Report Indicate
When invoked: This primitive may be invoked when the CF is in the TRANSFER state.
Action upon receipt: When the indicate is invoked, a UCA-MMS-Information-Report.deliver is invoked to

deliver the information to the application. The MMS parameters are mapped directly to the parameters of the
UCA-MMS-Information-Report.deliver primitive. The processing of this information is specific to the appli-
cation.

IEEE-SA
A.7 Supporting Service Mappings

This section defines the actions that result from inputs generated by the supporting service. This is not a
complete service definition of the supporting service, but only the inputs generated by the supporting service
to the CF.
A.7.1 Presentation Connection-mode
A.7.1.1 Lower Mapping for MMS
With the exception of the initiate request and response primitives and the information-report request primi-
tive, all MMS primitives map to the supporting service data primitive. In most cases, this will be a P-Data.
Initiate is mapped to the user information field of the A-associate service. The MMS-information-report
indication service primitive may map to either the supporting service connection-mode (i.e., a data primi-
tive), or connectionless-mode service (i.e., a unit-data primitive).
A.7.1.1.1 MMS Initiate.request
When invoked: This primitive may be invoked when the initiator is in the NULL state.
Action upon receipt: When the CF gets an MMS-initiate request, it invokes an ASO A-associate request
primitive with the MMS-initiate APDU mapped as input for the user information parameter. The initiator
transitions from the NULL to the ASSOCIATION PENDING state.
A.7.1.2 Lower Mapping for ACSE
This section defines the specific lower boundary mapping to be used when using the presentation service as
a supporting service. The ACSE mapping to the lower layer service follows the mapping described in the
ACSE protocol specification.
A.7.1.2.1 Connection-mode Lower Boundary of UCA ASO to the Presentation Service
This section constitutes a specific application of Clause 8 of the ACSE protocol specification and defines the
lower mapping of ACSE to the presentation service. As an aid to the reader, the corresponding IA-primitives
used in ACSE Edition 3 are noted in parenthesis next to the appropriate presentation indicate and confirm
primitives.
A.7.1.2.2 IA-Bind-Request.submit
This primitive is invoked by an initiating ACSE to request an instance of the supporting service for the ASO-
association that it is attempting to create.
When invoked: The initiating ACPM will be in the AWAITING AARE (STA1) state, and the supporting ser-
vice may be in any state except RELEASE PENDING.
Action upon receipt: If the fast-associate mechanism is supported, the requesting ACPM identifies the
semantic content of the AARQ, including the user information field, in the user summary parameter of the
IA-Bind Request.submit primitive.
When this primitive is received, the CF inspects the naming parameters and a P-connect request is invoked to
create a P-connection using the addressing parameters provided in the IA-bind request. The presentation

IEEE-SA
parameters of the IA-bind are mapped to the corresponding parameters of the P-connect request primitive. In
particular, the P-context-definition-list parameter of the P-connect-request is set to the P-context required to
support the association request established by the IA-bind request. The user information parameter (contain-
ing the AARQ) is mapped to the user-data parameter of the P-connect request. The requesting ACPM waits
for a P-connect confirm primitive from the supporting service and does not accept any other primitive from
the requester other than an A-Abort request primitive. The ACPM is in the AWAITING AARE (STA 1) state.
A.7.1.2.3 P-Connect indicate (IA-Bind-Request.deliver)
This primitive is invoked to notify a recipient ACPM of a new distinct instance of the supporting service
capable of delivering APDUs to this ACPM.
When invoked: When the supporting service generates a P-connect indicate primitive, the primitive and its
parameters are mapped to an IA-Bind.deliver. The recipient ACPM will be in the Idle-UNASSOCIATED
(STA 0) state. The supporting service will be in the ASSOCIATION PENDING state.
Action upon receipt: The user-information parameter of the IA-Bind-Request.deliver primitive containing an
AARQ APDU is delivered to the ACPM.
A.7.1.2.4 IA-Bind-Response.submit
This primitive is invoked by a responding ACPM to confirm or deny a request for a supporting service.
When invoked: The responding ACPM will be in the AWAITING A-ASCrsp (STA 2) state, and the support-
ing service may be in the ASSOCIATION PENDING state or the ESTABLISHED state.
Action upon receipt: When this primitive is received and the supported service is in the AWAITING A-
ASCrsp (STA 2), then the CF will invoke a P-connect-response primitive to confirm the P-connection using
the addressing parameters provided in the IA-Bind-Response.submit primitive. The user information param-
eter (containing the AARE) is mapped to the user-data parameter of the P-connect response.
If the association is accepted, the P-connect response is positive and the ACPM transitions to the associated
(STA 5) state. If the association is refused, the P-connect is negative and the ACPM transitions to the UNAS-
SOCIATED (STA 0) state.
A.7.1.2.5 P-Connect Confirm (IA-Bind-Response.deliver)
This primitive is invoked to notify the ACPM of a request for a new association.
When invoked: When the supporting service generates a P-connect confirm primitive, the primitive and its
parameters are mapped to an IA-Bind.deliver. This primitive is invoked when the ACPM is in the awaiting
AARE state (STA 3) state.
Action upon receipt: The ACPM is able to use this instance of the supporting service. The user-information
parameter may contain an AARE APDU is delivered to the ACPM.
A.7.1.2.6 IA-Data.submit
When invoked: This primitive may be invoked when the ACPM is in the awaiting AARE (STA 1) or associ-
ated (STA 5) state and the supporting service is in the ASSOCIATION PENDING or ESTABLISHED states.
Action upon receipt: The CF maps this primitive to a P-data request primitive. Because the P-service is
blocking (i.e., no data will be sent until the association establishment completes) and the ACSE service is not
blocking, the CF must queue the IA-data until the supporting service (in this case, the presentation service)
transitions to the ESTABLISHED state.

IEEE-SA
A.7.1.2.7 P-Data Indicate (IA-Data.deliver)
When invoked: This primitive is invoked when the supporting service is in the ESTABLISHED state and has
received a P-data indication.
Action upon receipt: Upon receipt of an indication or confirm service primitive from ACSE or transport
other than an ACSE Abort.indication, the MMPM shall determine if the service primitive received contains
as user data a valid MMS PDU. A valid MMS PDU is one that meets the requirements of the MMS abstract
syntax for the definition of PDUs, is mapped to the correct ACSE or Transport service primitive (as defined
above), and arrives in conformance with all sequencing and service procedure rules defined in ISO/IEC
9506-1: 1990 and ISO/IEC 9506-2: 1990.
If the service primitive received does not contain a valid MMS PDU, the MMPM shall take the following
actions:
If an initiate-requestPDU and an initiate-responsePDU have been successfully exchanged via previ-

ous communications over the application association, the MMPM shall issue a Reject.indication to
the MMS-user and shall construct a rejectPDU (with parameters based on the error detected) and
send this PDU on a A-Abort.request service primitive.
Otherwise, the MMPM shall issue an Abort.indication to the MMS-user, and issue an ACSE A-
Abort.request service primitive if an application association does not exist.
If an MMS-provider receives a rejectPDU it shall issue a reject indication to the MMS-user. The
MMS-user shall use the abort service to abruptly terminate the MMS environment.
A.7.1.2.8 IA-Abort.submit
When invoked: An IA-Abort.submit may be invoked when the ACPM or the supporting service is in any
state to notify the supporting service that the supported service has been aborted.
Action upon receipt: This primitive is mapped to a P-U-abort request, and the ACPM transitions to the
UNASSOCIATED (STA 0) state.
A.7.1.2.9 P-U-Abort (IA-Abort.deliver)
When invoked: This primitive is invoked when the supporting service generates P-U-Abort Indication to
notify the ACPM that the supporting service has aborted the supporting association.
Action upon receipt: The contents of the P-U-abort are delivered to the ACPM. The ACPM transitions to the
IDLE UNASSOCIATED (STA 0) state and supported service transition to the NULL state.
A.7.1.2.10 IA-Release-Request.submit
When invoked: This primitive is invoked to notify the supporting service of the release of the supported ser-
vice. The ACPM may be in the ASSOCIATED (STA 5) state.
Action upon receipt: When this primitive is generated, the CF maps the user-information parameter (contain-
ing the RLRQ) to the user-data parameter and generates a P-release request primitive.
A.7.1.2.11 P-Release Indicate (IA-Release-Request.deliver)
When invoked: This primitive is invoked when a P-release indication is received to notify the ACPM that the
supporting service is being released.

IEEE-SA
Action upon receipt: When this primitive is received, the contents of the user-data field (an RLRQ) are deliv-
ered to the ACPM. The ACPM processes the RLRQ and transitions to the AWAITING A-RLSrsp (STA 4)
state.
A.7.1.2.12 IA-Release-Refuse.submit
When invoked: This primitive is invoked to notify the supporting service that the request for the release of
the supporting association has been refused. The ACPM is in the AWAITING A-RLSrsp (STA 4) state.
Action upon receipt: When this primitive is received in the AWAITING A-RLSrsp (STA 4) state, A P-release
response primitive is generated with a negative response (and with the user-information parameter contain-
ing the RLRE APDU) and the ACPM transitions to the ASSOCIATED (STA 5) state.
A.7.1.2.13 P-Release Confirm (IA-Release-Refuse.deliver)
When invoked: This primitive is invoked when a P-release confirm primitive, a P-resynchronize, a P-U-
exception report, or a P-P-exception report primitive is received.
Action upon receipt: If this is a P-release confirm primitive, then the user-data field (containing an RLRE) is
delivered to the ACPM. For the other primitives, the ACPM acts as if it has received an RLRE that refused
the release of the association. The ACPM transitions to the ASSOCIATED (STA 5) state and notifies the
ACSE user that the release has been refused.
A.7.1.2.14 IA-Release-Response.submit
the supporting association has been accepted. The ACPM is in the AWAITING A-RLSrsp (STA 4) state.
Action upon receipt: When this primitive is generated in the awaiting A-RLSrsp (STA 4) state, the user-
information parameter, (containing an RLRE APDU) is mapped to the user-data parameter of the P-release
response primitive is generated with a positive response and the ACPM transitions to the UNASSOCIATED
(STA 0) state.
A.7.1.2.15 P-P-Abort (IA-Unbind.deliver)
When invoked: This primitive is invoked to notify the supported service that the supporting service has
aborted.
Action upon receipt: When the ACPM receives an IA-Unbind.deliver, it is notified that the supporting asso-
ciation has been released. The ACPM cannot send any further APDUs on this association without first initi-
ating a new instance of the supporting service. It is a matter of the design of the ASO as to whether the
ACPM terminates, or waits for further action by its user for a new association, or the ASO initiates a new
association.
A.7.2 Presentation Connectionless-mode

This section defines the specific lower boundary mapping to be used when using the presentation service as
a supporting.

IEEE-SA
A.7.2.1 Connectionless Lower Boundary of UCA ASO to the Presentation

Service
This section constitutes a specific application of Clause 8 of ISO/IEC 8650-1: 1996 (ACSE) and defines the
lower mapping of ACSE to the presentation service. This mapping is used exclusively for multicast transmis-
sions. As an aid to the reader, the corresponding presentation indicate and confirm primitives are noted in
parentheses next to the appropriate IA deliver primitives.
A.7.2.1.1 IA-Unit-Data
When invoked: This is invoked by the ASO to convey an APDU to its peer.
Action upon receipt: The A-unit-data APDU contained in the IA-unit-data user data parameter is mapped to
the user-data parameter of a P-unit-data primitive and the P-unit-data primitive is invoked.
A.7.2.1.2 P-Unit Data Indicate (IA-Data.deliver)
When invoked: This primitive is invoked by the presentation service to deliver an A-unit-data PDU to the
ASO.
Action upon receipt: The A-unit-data PDU is delivered to the appropriate ACPM as determined by the nam-
ing parameters.
A.7.3 Data Link Service (3-Layer)

This section defines the specific lower boundary mapping to be used when using the data link service as a
supporting service.
A.7.3.1 Connection-mode Lower Boundary of UCA ASO to the Data Link

Service
This section constitutes a specific application of Clause 8 of ISO/IEC 8650-1: 1996 (ACSE) and defines the
lower mapping of ACSE to the data link service. As an aid to the reader, the corresponding data link indicate
and confirm primitives are noted in parentheses next to the appropriate IA deliver primitives.
A.7.3.1.1 IA-Bind-Request.submit
This primitive is invoked by an initiating ACSE to request an instance of the supporting service for the ASO-
association that it is attempting to create.
When invoked: The initiating ACPM will be in the AWAITING AARE (STA1) state, and the supporting ser-
vice may be in any state except RELEASE PENDING.
Action upon receipt: When this primitive is received, the CF inspects the naming parameters and a DL-con-
nect request is invoked to create a DL-connection using the addressing parameters provided in the IA-bind
request. The user information parameter (containing the AARQ) is mapped to the user-data parameter of the
DL-connect request. The requesting ACPM waits for a DL-connect confirm primitive from the supporting
service and does not accept any other primitive from the requester other than an A-abort request primitive.
The ACPM is in the AWAITING AARE (STA 1) state.

IEEE-SA
A.7.3.1.2 DL-Connect indicate (IA-Bind-Request.deliver)
This primitive is invoked to notify a recipient ACPM of a new distinct instance of the supporting service
capable of delivering APDUs to this ACPM.
When invoked: When the supporting service generates a DL-connect indicate primitive, the primitive and its
parameters are mapped to an IA-Bind.deliver. The recipient ACPM will be in the Idle-UNASSOCIATED
(STA 0) state. The supporting service will be in the ASSOCIATION PENDING state.
Action upon receipt: The user-information parameter of the IA-Bind-Request.deliver primitive containing an
AARQ APDU is delivered to the ACPM.
A.7.3.1.3 IA-Bind-Response.submit
This primitive is invoked by a responding ACPM to confirm or deny a request for a supporting service.
When invoked: The responding ACPM will be in the AWAITING A-ASCrsp (STA 2) state, and the support-
ing service may be in the ASSOCIATION PENDING state or the ESTABLISHED state.
Action upon receipt: When this primitive is received and the supported service is in the awaiting A-ASCrsp
(STA2), then the CF will invoke a DL-connect-response primitive to confirm the DL-connection using the
addressing parameters provided in the IA-Bind-Response.submit primitive. The user-information parameter
(containing the AARE) is mapped to the user-data parameter of the DL-connect response.
A.7.3.1.4 DL-Connect Confirm (IA-Bind-Response.deliver)
This primitive is invoked to notify the ACPM of a request for a new association.
When invoked: When the supporting service generates a DL-connect confirm primitive, the primitive and its
parameters are mapped to an IA-Bind.deliver. This primitive is invoked when the ACPM is in the AWAIT-
ING AARE state (STA 3) state.
Action upon receipt: The receipt implies that ACPM is able to use this instance of the supporting service.
The indication is delivered to the ACPM, with user-information parameter containing the AARE APDU.
A.7.3.1.5 IA-Data.submit
When invoked: This primitive may be invoked when the ACPM is in the AWAITING AARE (STA 1) or
Associated (STA 5) state and the supporting service is in the ASSOCIATION PENDING or ESTABLISHED
states.
Action upon receipt: The CF maps this primitive to a DL-Data Request primitive. Because the DL-service is
blocking (i.e., no data will be sent until the association establishment completes, and the ACSE service is not
blocking) the CF must queue the IA-data until the supporting service, in this case, the DL service, transitions
to the ESTABLISHED state.
A.7.3.1.6 DL-Data Indicate (IA-Data.deliver)
When invoked: This primitive is invoked when the supporting service is in the ESTABLISHED state and has
received a DL-data indication.
Action upon receipt: The user-data parameter is delivered to the MMS ASE.

IEEE-SA
A.7.3.1.7 IA-Abort.submit
When invoked: An IA-Abort.submit may be invoked when the ACPM or the supporting service is in any
state to notify the supporting service that the supported service has been aborted.
Action upon receipt: This primitive is mapped to a DL-disconnect request. The CF transitions to the
RELEASE PENDING state.
A.7.3.1.8 IA-Release-Request.submit
When invoked: This primitive is invoked to notify the supporting service of the release of the supported ser-
vice. The ACPM may be in the ASSOCIATED (STA 5) state.
Action upon receipt: When this primitive is generated, the CF maps the user-information parameter (contain-
ing the RLRQ) to the user-data parameter and generates a DL-disconnect request primitive.
A.7.3.1.9 DL-Release Indicate (IA-Release-Request.deliver)
When invoked: This primitive is invoked when a DL-release indication is received to notify the ACPM that
the supporting service is being released.
Action upon receipt: When this primitive is received, the contents of the user-data field (an RLRQ) are deliv-
ered to the ACPM. The ACPM processes the RLRQ and transitions to the AWAITING A-RLSrsp (STA 4)
state.
A.7.3.1.10 DL-Disconnect Confirm (IA-Release.deliver)
When invoked: This primitive is invoked when a DL-disconnect confirm primitive is received.
Action upon receipt: If the user-data parameter is not null, the contents of the parameter are delivered to the
ACPM; otherwise, the CF transitions to the NULL state.
A.7.3.1.11 IA-Release-Response.submit
the supporting association has been accepted. The ACPM is in the AWAITING A-RLSrsp (STA 4) state.
Action upon receipt: When this primitive is received in the AWAITING A-RLSrsp (STA 4) state, a the DL-
disconnect response primitive is generated with a positive response and the ACPM transitions to the UNAS-
SOCIATED (STA 0) state. The user-information parameter of the DL-disconnect response primitive will
contain an RLRE only if this was initiated by an IA-release; otherwise, it will be null.

IEEE-SA
Appendix B
UCA Station Management
The UCA station management protocol has been developed to support any additional utility-specific func-
tionality for which no existing standards-based solutions exist. The only requirement identified requiring
additional protocol at the time of this publication is support for time synchronization service. Others may be
identified in the future.
This section documents procedures and protocol for performing network-based time synchronization. The
algorithms set forth in this section may be impacted should communication be required to be conveyed
through an intermediate system (IS), and therefore these procedures are only recommended for a single net-
work segment. The segment time master shall use a local algorithm to determine when to actually perform
the synchronization procedure and this mechanism is out-of-scope for this document.
The time synchronization service procedures are defined in C.1. The protocol to be used to implement the
time synchronization service procedures is defined in C.2.
B.1 UCA Station Management Service Procedures

There are three services defined that are used together to perform the time synchronization procedure. The
services are: prepare, measure, and synchronize. The services are requested by the UCA time master (the
source of the time) and executed by the UCA time slave (the synchronization target). The service procedures
for each are defined below. Throughout these service descriptions, the time master and time slave are
required to record the time of transmission and reception of various service primitives. The accuracy of the
overall service is highly dependent on the ability of both systems to record the time as near as possible to the
actual network event. The following rules apply:
The recorded time shall be the time of transmission of the either the first or the last octet of the mes-
sage containing the service primitive. It is recommended that the last octet be used when the service
is being performed over local area network (LAN) link protocols, and that the first octet be used
when the service is being performed over serial-based link protocols.
In any case, the same octet (first or last) shall be used for recording both the time of reception and
the time of transmission of primitives on any single link protocol.
B.1.1 Prepare Service

The purpose of the (unconfirmed) prepare service is to allow the time master to request that the time slave
begin local procedures that may be required to record accurate time information regarding the ensuing ser-
vice primitives. The structure of the component service primitive is shown in the following table.
Parameter Request Indication Response Confirm

Request Mandatory Mandatory
B.1.1.1 Request
The request parameter shall indicate that the service has been invoked by the time master.

IEEE-SA
B.1.2 Prepare Service Procedure

The time slave shall begin any local procedures required to record accurate time information regarding the
ensuing service primitives. The definition of such procedures is a local matter.
B.1.3 Measure Service

The purpose of the (confirmed) measure service is to allow for the acquisition of accurate measurements of
the path delay between the time master and the time slave. The structure of the component service primitives
is shown in Table B.1.
Table B.1

Response (+) Mandatory Mandatory
Response (-) Mandatory Mandatory
ErrorType Mandatory Mandatory
B.1.3.1 Request
The request parameter shall indicate that the service has been invoked by the time master.
B.1.3.2 Response (+)
The response (+) parameter shall indicate that the request has succeeded. A successful response does not
supply specific parameters.
B.1.3.3 Response ()
The response () parameter shall indicate that the response failed. The ErrorType parameter provides the rea-
son for failure (see B.1.6).
B.1.4 Measure Service Procedures

The time master shall invoke the measure service by issuing a measure request service primitive and shall
record the time of transmission of that primitive.
The time slave shall perform the following validation check:
If the time slave is configured to use its own source of an accurate time, it shall return the Response ()
primitive with ErrorType value locally_synced.
Otherwise, the time slave shall record the time of reception of the measure request service primitive and
respond with the measure response (+) service primitive, and shall record the time of transmission of that
primitive.
The time master shall record the time of reception of the measure response service primitive.

IEEE-SA
B.1.5 Synchronize Service

The purpose of the (confirmed) synchronize service is to allow for the acquisition of accurate measurements
of the path delay between the time master and the time slave. The structure of the component service primi-
tives is shown in the Table B.2.
Table B.2

MeasureReqTime Mandatory Mandatory
MeasureResTime Mandatory Mandatory
Authentication Optional Optional
Response (+) Mandatory Mandatory
TimeSkew Mandatory Mandatory
Response (-) Mandatory Mandatory
ErrorType Mandatory Mandatory
B.1.5.1 Request
The request parameter shall indicate that the service has been invoked by the time master, and shall convey
the parameters for the service request:
B.1.5.1.1 MeasureReqTime
This parameter shall specify the time of transmission of the last measure service request as recorded by the
time master.
B.1.5.1.2 MeasureResTime
This parameter shall specify the time of reception of the last measure service request as recorded by the time
master.
B.1.5.1.3 Authentication
This parameter shall specify the authentication value used by the time slave to validate the rights of the time
master.
B.1.5.2 Response (+)
The response (+) parameter shall indicate that the request has succeeded. A successful response shall convey
the following parameter.
B.1.5.2.1 TimeSkew
This parameter shall convey the difference (as computed by the time slave) between the local free-running
clock maintained by the time slave and the MeasureResTime parameter supplied by the time master at the
time the time master received the last measure response primitive. The algorithm for computing this param-
eter is supplied in the service procedure defined in B.1.7.

IEEE-SA
B.1.5.3 Response ()
The response () parameter shall indicate that the response failed. The ErrorType parameter provides the rea-
son for failure (see B.1.6).
B.1.6 Synchronization Error Responses

The following service errors are defined for use in negative responses to Time Synchronization service
requests:
locally-synced - The device (Time Sync slave) that received the request uses local time synchronization
procedures, rather than UCA Station Management.
not authorized - The receiving device does not permit time synchronization with the supplied authentica-
tion values.
no-measurement-recorded - A SyncRequest.indication has been received without a prior MeasureRe-
quest.indication within the configured time window.
B.1.7 Synchronize Service Procedures

The time master shall invoke the service by issuing the synchronize request service primitive, including the
MeasureReqTime, MeasureResTime, and the authentication (optional).
The time slave shall perform the following validation checks:
If the authentication parameter does not meet the locally defined authentication criteria at the time
slave, it shall return the response () primitive with ErrorType value not_authorized.
If the time slave has not received a measure service request primitive since the last synchronize ser-
vice request, it shall return the response () primitive with ErrorType value no_measure_recorded.
If the time slave is configured to use its own source of an accurate time, it shall return the response
() primitive with ErrorType value locally_synced.
Otherwise, the time slave shall perform the following computation:
SlaveReqTime: Time of reception of the measure request service primitive as recorded by the time slave.
SlaveResTime: Time of transmission of measure response (+) service primitive as recorded by the time
slave.
MeasureReqTime: Time of transmission of the measure request service primitive as supplied in the syn-
chronize service request by the time master.
MeasureResTime: Time of reception of the measure response (+) service primitive as supplied in the
synchronize service request by the time master.
Path Latency = [(MeasureResTime MeasureReqTime) (SlaveResTime SlaveReqTime)] / 2
TimeSkew = SlaveReqTime Path Latency MeasureReqTime
The time slave shall maintain the value of TimeSkew and shall add this value to its local clock value for use
in application layer time stamps. The time slave shall further issue a synchronize response (+) service primi-
tive with this value as the TimeSkew parameter.

IEEE-SA
B.1.8 Time Synchronization State Diagrams

The following figures summarize the state transitions used in the Time Synchronization procedures. Figure
B.1 defines the transitions used by the Time Synchronization Master as it issues requests and waits for indi-
cations from the remote. Figure B.2 shows the corresponding transitions in the Time Synchronization
Slave.
IDLE 1) Local Time Sync service invoked on master

6 2) PrepareForTimeSyncRequest.request
1 3) MeasureRequest.request
7,8 4) MeasureResponse.indication
START
5) SyncRequest.request
W2 6) SyncResponse.indication
7) SyncErrorRequest.indication
7, 8 2 8) Time out
5
IDLEWaiting for PrepareforTimeSync.indication
STARTPreparing to issue MeasureRequest request
T2 T1
W1Waiting for MeasureResponse.indication
W2Waiting for SyncResponse.indication
4 3 T1, T2Local transition state
W1
Figure B.1: State Diagram for Time Master
IDLE 1) PrepareforTimeSyncRequest.indication
2) MearsureRequest.indication
3) MeasureResponse.request
1 4) SyncRequest.indication
6 2 5) SyncResponse.request
5 6) SyncError.request
W1 7) Time out
ERROR 7 2
IDLEWaiting for PrepareforTimeSync.indication
W1Waiting for MeasureRequest.indication
ERRORPreparing to issue error request to remote
W2Waiting for SyncRequest.indication
T2
2,7
T1 T1, T2, T3Local transition state
4 3 The local time synchronization Indication is given to the

local application(s) on the transition from T2.
W2
1
Figure B.2: State Diagram for Time Slave
B.2 UCA Station Management Protocol

The UCA station management protocol is intended to allow for low-level control of various station capabili-
ties that, for reasons of time sensitivity, media or link sensitivity, procedural requirements or other specific
reasons, cannot be managed through the normal UCA protocol stack. At this time, only the UCA time syn-
chronization services are defined, although future extensions may be added in later versions.

IEEE-SA
The LSAP that shall be used for UCA station management is 0xFB. Any system implementing UCA station
management, upon receipt of a PDU for the UCA station management LSAP shall:
If the service primitives are properly encoded and supported, execute the service procedures as
defined in this document.
If the service primitive is properly encoded but unsupported, respond with a UCA-ErrorPDU with
error code unsupported.
If the service primitive is properly encoded but unrecognized, respond with a UCA-ErrorPDU with
error code unrecognized.
If the service primitive is not properly encoded respond with a UCA-ErrorPDU with error code
pdu-error.
If UCA station management is unimplemented, all PDUs received for the UCA station management LSAP
shall be ignored.
The abstract syntax for the time synchronization protocol shall be as defined in the following. The transfer
syntax shall be ASN1 Basic Encoding Rules (BER) as defined in ISO/IEC 8825-1: 1995.
UCA-Mgmt-pdu ::= CHOICE {

uca-error [0] IMPLICIT ErrorPDU,
uca-timesync [1] IMPLICIT TimeSyncPDU
Note: This corresponds to the GI. In the future the
grammar to other such private station management
functions (i.e., RESET, etc.) may be extended.
}
ErrorPDU ::= INTEGER {

unsupported (1),
unrecognized-service (2),
pdu-error (3)
}
TimeSyncPDU ::= CHOICE {

measure-request [0] IMPLICIT Measure-RequestPDU,
measure-response [1] IMPLICIT Measure-ResponsePDU,
sync-request [2] IMPLICIT Sync-RequestPDU,
sync-response [3] IMPLICIT Sync-ResponsePDU,
sync-error [4] IMPLICIT Sync-ErrorPDU
prepare-sync [5] IMPLICIT Prepare-SyncPDU
}
Measure-RequestPDU ::= NULL
Measure-ResponsePDU ::= NULL
Sync-RequestPDU ::= SEQUENCE {

request-time [0] IMPLICIT TimeOfDay,
response-time [1] IMPLICIT TimeOfDay,
request-usec [2] IMPLICIT INTEGER DEFAULT 0,
response-usec [3] IMPLICIT INTEGER DEFAULT 0,
authentication [4] IMPLICIT OCTET-STRING
DEFAULT NULL
}

IEEE-SA
Note: The request-usec and response-usec parameters define the microsecond offset with the millisecond
defined by response-time and request-time, respectively. If they are present and the implementation does not
support microsecond timing, they shall be ignored.
TimeOfDay ::= OCTET STRING (SIZE 6)
Note: The interpretation of the TimeOfDay type shall be the same as defined in ISO/IEC 9506-2: 1990,
7.6.1, except that the only the 6-byte format shall be used.
Sync-ResponsePDU ::= NULL
Sync-ErrorPDU ::= IMPLICIT INTEGER {

locally-synced (1),
not-authorized (2),
no-measurement-recorded (3)
}
Prepare-SyncPDU ::= NULL
B.3 Mapping of Service Primitives to Protocol

Table B.3 shows the mapping of the service primitives and parameters to UCA station management protocol
elements. The associated UCA station management PDUs shall be encoded using ASN.1 Basic Encoding
Rules (BER) as defined in ISO/IEC 8825-1: 1995. The protocol is mapped directly to the data link layer
(UCA 3-layer profile). All requests and responses map to the data link primitive DL.Data Request, all indica-
tions and confirms are delivered via DL.Data Indicate.
Table B.3
Service Parameter Mapping

Prepare Request Prepare-SyncPDU
Measure Request Measure-RequestPDU
Response (+) Measure-ResponsePDU
Response () Sync-ErrorPDU
ErrorType parameter
Synchronize Request Sync-RequestPDU
MeasureReqTime request-time, request-usec*
MeasureResTime response-time, response-usec*
authentication
Response (+) Sync-ResponsePDU
Response () Sync-ErrorPDU
ErrorType parameter
*The request/response-time field conveys the date and number of milliseconds since
midnight. If microsecond precision is supported, then the request/response-usec field
conveys the number of microseconds since the last millisecond. The following rules
apply:
If microseconds are present in a primitive and the receiver does not support
microsecond precision, the value is ignored.
If microseconds are supported by the receiver and the field is missing from the
service primitive, the value zero is assumed.

IEEE-SA
Appendix C
Security Transformation ASE for MMS
The UCA security protocol is based upon ANSI T1.259-1997 (STASE-ROSE). However, the use of MMS,
which maps over both connection-oriented as well as connectionless profiles, requires certain revisions to
STASE-ROSE in order to achieve the level of security desired. Many of the changes, to be detailed, involve
the use of connectionless profiles. In addition, there is a requirement to have standardization of the use of
DES CBC. This appendix describes the changes to be applied to ANSI T1.259-1997 to create the required
functionality.
The result of applying these changes to the STASE-ROSE standard will result in a STASE-MMS standard.
General edits (applied to ANSI T1.259-1997):
Replace STASE-ROSE with STASE-MMS.
Replace ROSE with MMS.
Specific edits (applied to ANSI T1.259-1997):
Change 1.1, paragraph 2 to:
This standard supports security services for MMS PDUs and MMS objects within the application layer.
It is independent of the underlying communications protocol stack. This standard defines a new applica-
tion service element (ASE) called Security Transformations Application Service Element for MMS
(STASE-MMS), which resides between the MMS and the presentation layer in the OSI protocol stack.
This standard provides an approach for performing security transformations (STs) that imposes no
requirements on any of the six lower layers of the communications stack. This is in contrast to methods
[e.g., generic upper layers security (GULS)] that support security transformations through embedded
functionality in the communications stack at the presentation layer.
Delete 1.1, paragraph 3.
Change 1.2 to:
The purpose of this standard is to protect whole MMS PDUs and MMS objects.
This standard addresses the security of MMS protocol data units (PDUs) and access control on MMS
objects. The access control on MMS objects is modeled upon the role based access control (RBAC) rec-
ommendations. While this standard is motivated by the need to secure TMN interactions or message
exchanges, it can be used to provide security for any application that uses MMS.
Change 1.3 to:
This standard applies to MMS-based applications.
Add to 2.2:
ISO/IEC-9506-1: Industrial Automation SystemsManufacturing Message SpecificationPart 1:

Service Definition (1990).
ISO/IEC-9506-2: Industrial Automation SystemsManufacturing Message Specification Part 1:
Protocol Specification (1990).

IEEE-SA
Add to Clause 3:
STASE-MMS: An application service element residing between the OSI presentation layer and MMS that
provides the transformations necessary for secure transfer of MMS PDUs.
STASE-MMS-user; SR-user: The application service element that uses the services of STASE-MMS. The
manufacturing message specification (MMS) is the only user of STASE-MMS services.
STASE-MMS-provider; SR-provider: The provider of the STASE for MMS.
Add to Clause 4:
MMS Manufacturing message specification

STASE-MMS Security transformations application service element-MMS
Insert into 5.2.1, after item 2:
For MMSpdus that are normally transferred by A-ASSOCIATE and A-UNIT-DATA services, the
DES initialization vector (IV) shall be specified. The IV shall consist of 64 valued bits.
For MMSpdus that are normally transferred by A-RELEASE and P-DATA services, the DES ini-
tialization vector (IV) shall not be specified within all by MMS-ROSE. The IV shall consist of the
last 8 bytes of the previously decrypted MMS PDU, where at least one of the bytes is non-zero. If
the MMS PDU is less than 8 bytes then the IV shall be padded with bytes whose value is 0. The
padding shall be added after the MMS PDU bytes. The IV shall consist of 64 valued bits.
Note: The original text of this read: if no Initialization Vector (IV) is specified then the first IV of an associ-
ation shall consist of 64 zero valued bits, every subsequent IV shall consist of the last 8 bytes of the previous
encrypted MMS PDU. However, this did not address the issue of the use of A-UNIT-DATA in multicast/
connectionless operation nor the issue of BER encodings that used indefinite length SEQUENCE encodings.
The indefinite length use would always cause the IV to be 64 bits of 0 value bits. What is desired is to have
the IV rotate on a per PDU basis. Additionally, the text did not specify if the derived IV is to be based upon
the values found in the MMS-ROSE encrypted PDU or in the decrypted MMS PDU.
Change 5.2.1, items 9 and 10 to read:
Peer entity authentication shall occur at association set up time. Authentication information shall be
carried in the calling-authentication-value and responding-authentication-value fields of the authen-
tication FU of the ACSE AARQ, A-UNIT-DATA, and AARE PDUs respectively. The bit strings for
the sender-acse-requirements and responder-acse-requirements fields of the authentication FU shall
be DEFAULTED to include the authentication FU. The calling-authentication-value and respond-
ing-authentication-value fields are of type authentication-value, which is further defined in ISO
8650 as a CHOICE. The CHOICE for the authentication-value shall be EXTERNAL. The presenta-
tion context shall include a reference to the abstract syntax that is used for the EXTERNAL. When
the default values and conventions are used, it is not necessary to use the (optional) mechanism-
name field of the authentication FU of the ACSE PDUs.
If peer entity authentication with symmetric key is required, then the authenticator defined in a nor-
mative appendix shall be used to provide peer entity authentication and to identify the key that shall
be used for DES encryption; the authenticator shall be carried in the authentication-value field of
the ACSE authentication functional unit in the AARQ, A-UNIT-DATA, and AARE messages; the
same key shall be used for all DES encryption for all PDUs exchanged in the course of the associa-
tion unless otherwise specified via the EncryptionParameters. The module providing the access
control in Annex C which is proposed here has the following object identifier:

IEEE-SA
uca-secure-mms-asn ::= mmssig-abstract-syntax-1 ::=

{iso(1) identified-organiztion(3) oiw(14) mmssig(10) abstract-syntax (3) syntax1(1)}
and the abstract syntax is registered as:
{
iso(1) member-body(2) usa(840) ansi-t1-228-1992(10016)
specificAccessControlAbstractSyntax(4) encryptionMethod(1)
}
Note: While this standard specifies defaults for authentication in ACSE AARQ, A-UNIT-DATA, and AARE,
it does not provide any protection for whole ACSE PDUs. Protection for whole ACSE PDUs may be impor-
tant to the overall security of the association, but it is outside the scope of this standard.
Change 5.2.1, item 11, paragraph 2, sentence 2 to read:
The syntax for this authenticator is given in clause 5.2.1.1. The (optional) publicly encrypted symmetric
encryption keys in the AARQ, A-UNIT-DATA, and AARE messages can be different, allowing the initi-
ator and the responder of the association to use different keys in the course of the association.
Change 5.2.1.1, notation to read:
a symmetric encryption key encrypted with the receivers public key

maximum of 256 value bits
Delete 5.2.2, paragraph 7.
Add to 5.2.2:
Note: Negotiation shall not be used in conjunction with A-UNIT-DATA.
Change notations in 5.3 to set maximum size limits:
blockSize [13] INTEGER OPTIONAL,

-- for square mod-n hashing
-- maximum of 32 value bits
keySizes [14] SET OF INTEGER OPTIONAL,
-- for RSA
publicKeys [15] SET OF SEQUENCE
{
modulus INTEGER, -- 256 value bits

exponent INTEGER -- 256 value bits
} OPTIONAL,
sequenceNumber [16] INTEGER OPTIONAL,
-- 64 value bits
encryptedSymmetricKey [19] INTEGER OPTIONAL,
-- symmetric session key, encrypted with the receivers public key
-- maximum of 64 value bits.

IEEE-SA
KeyListId ::= CHOICE {

identifier OBJECT IDENTIFIER,
name GraphicString,
number INTEGER
}
Change 6, paragraph 2:
STASE-ROSE only deals with the secure transfer of remote operations service element (ROSE) applica-
tion-protocol-data-units.
to read:
STASE-MMS only deals with the secure transfer of the manufacturing message specification (MMS)
application-protocol-data-units.
Delete Clause 6, paragraphs 9 and 10.
Delete Clause 6, Figure 2.
Add to 7.4.2.1, Table 7.2:
RoleID U C
Add to 7.4.2.1:
roleID: This is an INTEGER value that represents an apriori agreement that forms the basis of a
simple signature.
Add 7.4.2.2:
The A-UNIT-DATA service of recommendation X.217 is invoked by the application process of an appli-
cation context involving STASE-MMS to establish a transient association with a peer application pro-
cess. A-UNIT-DATA is used over connectionless profiles to provide the capability of broadcast and
multicasting of the InformationReport and UnsolicitedStatus MMSpdus (unconfirmed services).
The use of A-UNIT-DATA, which is a nonconfirmed service, means that security algorithms requiring
negotiation shall not be used.
Change 7.4.4.1 to read:
This parameter identifies the MMS PDU to be transferred. This parameter has to be supplied by the
requester of the service and the data values shall be in conformance with the MMSapdus definition in
ISO/IEC 9506.
Change 8.1.1, item 1 to read:
1) The application process of the application entity involving STASE-MMS issues an MMS Initia-
teRequest-PDU to establish an MMS application association. If peer entity authentication is
desired, the application process provides ACSE with the value of the authenticator to be carried
in the authentication-value field of the AARQ PDU (using the ACSE authentication FU). Dur-
ing the same phase the application process may also inform STASE-MMS and the MMS user
ASE(s) (e.g., MMS) of the requested association and provide STASE-MMS with any proposed
values for (some of) the encryption parameters.

IEEE-SA
2) STASE-MMS provides ACSE and the MMS provider with the accepted values, if any, for the
encryption parameters in the AARQ. The mechanism by which STASE-MMS informs ACSE
and the MMS provider is an implementation matter and is not addressed by this standard. This
information will be carried in the ACSE user information field using the EncryptionParame-
tersSelection defined in Clause ???. During the same phase the MMS provider decodes the
IntiateRequest-pdu and generates either a InitiateResponse(+), InitiateResponse(-) or Initia-
teError-pdu. The generated PDUs are conveyed to STASE-MMS so that they may be transmit-
ted as part of the UserData in the AARE. The ACSE user information field defined in ITU-T
Rec. X.227 (1992), ISO 8650: 1988 consists of a SEQUENCE OF EXTERNAL. The informa-
tion for STASE-MMS, if any, shall be carried in the first EXTERNAL. The application context
shall specify which EXTERNAL(s) shall carry information for each of its other ASE(s).
3) The application process of the application context involving STASE-MMS issues a Conclude-
Request to the MMS provider, A-RELEASE request to ACSE to release an application associ-
ation.
Change 8.4 to reflect the use of P-DATA:
8.4 Data Transfer using P-DATA

Figure 7 shows the interaction between the application process, various ASEs and the presentation pro-
vider during data transfer phase.
Sender Receiver
Application Process Application Process
MMS user MMS user

Application
Layer 1 3
MMS MMS
2 2
2-ab STASE 2-dr
ACSE STASE ACSE
MMS MMS
3 1
Presentation
Layer
Figure 7. Interaction during data transfer
8.4.1 Sender
The following describes the interactions on the sending side in Figure 7.
4) The MMS user, prompted (not shown) by the application process, issues a MMS request or
response primitive to MMS, requesting transfer of data.
5) MMS issues the SR-TRANSFER request primitive to STASE-MMS, requesting secure transfer
of data.

IEEE-SA
6) STASE-MMS performs the required encoding and security transformation on the MMS PDU
(present in the request parameters) and issues a P-DATA request primitive to the presentation provider.
8.4.2 Receiver
7) The presentation-provider issues a P-DATA indication primitive to STASE-MMS, informing the
arrival of data from the peer application entity on an application connection.
8) STASE-MMS performs the reverse security transformations on the incoming data, checks for the
validity of the PDU (e.g., validity of the seal or signature, currency of the time stamp, value of the
sequence number), and if valid it issues a SR-TRANSFER indication primitive to MMS.
If the receiving STASE-MMS finds the incoming APDU unacceptable (e.g., decryption fails), then the
action to be taken by STASE-MMS is a local matter. However, this standard recommends the following
two alternatives:
The receiving STASE-MMS implementation may drop the incoming APDU as shown by 2-dr in
Figure 7.
The receiving STASE-MMS may issue an A-ABORT primitive to ACSE as shown in 2-ab in Figure
7.
In either case it is recommended (not shown) that the event be reported to the user element, that the
event be logged in a security audit trails, and that a security alarm be issued to the local security admin-
istrator.
1) If the SR-TRANSFER indication was delivered to MMS, MMS issues an MMS indication or
confirmation primitive to the MMS user which then informs (not shown) the application pro-
cess of the arrival of data from a peer application-entity.
Add 8.5:
8.5 Data Transfer using A-UNIT-DATA

Figure 8 shows the interaction between the application process, various ASEs and the presentation pro-
vider during data transfer phase.
Sender Receiver
Application Process Application Process
1 MMS user
MMS user
Application
Layer 1 4
MMS MMS
2 3
3 3-ab 3-dr
ACSE STASE ACSE STASE
MMS MMS
2
4 1
Presentation
Layer
Figure 8. Interaction during A-UNIT-DATA data transfer

IEEE-SA

2) The MMS user, prompted (not shown) by the application process, issues a MMS request or
response primitive to MMS, requesting transfer of data through the use of an A-UNIT-DATA ser-
vice primitive. Additionally, the user conveys to STASE-MMS which encryptionParameters are to
be used.
3) MMS issues the SR-TRANSFER request primitive to STASE-MMS, requesting secure transfer
of data.
4) STASE-MMS performs the required encoding and security transformation on the MMS PDU
(present in the request parameters) and issues a A-UNIT-DATA request primitive to the ACSE pro-
vider.
5) The ACSE provider issues an A-UNIT-DATA PDU through the use of an appropriate n-1 layer
service procedure.
8.5.2 Receiver
6) The n-1 layer issues a DATA indication primitive to the ACSE provider informing the arrival of
data from the peer application entity.
7) The ACSE provider conveys the encryptionParameters contained in the A-UNIT-DATA PDU to
STASE-MMS
8) STASE-MMS performs the reverse security transformations on the incoming data, checks for the
validity of the PDU (e.g., validity of the seal or signature, currency of the time stamp, value of the
sequence number), and if valid it issues a SR-TRANSFER indication primitive to MMS.
If the receiving STASE-MMS finds the incoming APDU unacceptable (e.g., decryption fails), then the
action to be taken by STASE-MMS is a local matter. However, this standard recommends the following
two alternatives:
The receiving STASE-MMS implementation may drop the incoming APDU as shown by 3-dr in
Figure 8.
The receiving STASE-MMS may issue an A-ABORT primitive to ACSE as shown in 3-ab in
Figure 8.
In either case it is recommended (not shown) that the event be reported to the user element, that the event
be logged in a security audit trail and that a security alarm issued to the local security administrator.
9) MMS issues a MMS indication or confirmation primitive to the MMS user which then informs
(not shown) the application process of the arrival of data from a peer application-entity.
Change Clause 9, paragraphs 1, 2, and 3 to read:
The protocol specified in this section supports the STASE-MMS services described previously. As men-
tioned previously, STASE-MMS uses the presentation layer P-DATA or ACSE A-UNIT-DATA service
for the transfer of secure MMS PDUs.
The STASE-MMS-protocol-machine (SRPM) communicates with MMS by means of the SR-TRANS-
FER service primitives described previously. The SRPM is driven by service requests from MMS and
by indication primitives from the presentation-service. The SRPM in turn, issues indication primitives
to MMS and request primitives to the presentation-service. P-DATA request or ACSE-service.A-UNIT-
DATA request and P-DATA/A-UNIT-DATA indication presentation service primitives are used.
The reception of a STASE-MMS service primitive or reception of a presentation-service or ACSE prim-
itive and the generation of the dependent actions are local matters outside the scope of this document.

IEEE-SA
Change 9.1, paragraph 1 and 2 to read:
In addition to the ASN.1 types defined in ITU-T X.229, the following types, based on types introduced
in T1.254, are defined for STASE-MMS.
Secure-MMS-APDUs {iso(1) identified-organization(3) oiw(14) mmssig(10) abstract-syntax(3) syn-
tax(1)}
Change 9.1, IMPORTS:
ROSEapdus
FROM Remote-Operations-ADPUs {joint-iso-ccitt remote-operations(4) apdus(1)}
To read:
MMSapdus
FROM ISO\IEC 9506 MMS-APDUs {iso standard 9506 part (2) mms-abstract-syntax-version1 (1)}
Change 9.1 to limit attribute sizes:
SimplePublicEnciphered ::= CHOICE

{
integers SEQUENCE OF INTEGER,
-- maximum of 64 value bits in each INTEGER
string OCTET STRING
}
SignedMMSpdu ::= SEQUENCE
{
data OCTET STRING,
signatureCHOICE
{
signature[1] Signature,
simpleSignature [2] SEQUENCE SIZE(1..4) OF INTEGER
}
}
ConfidentialSigned ::= SEQUENCE
{
encrypted OCTET STRING,
signature CHOICE
{
signature[1] Signature,
simpleSignature[2] SEQUENCE SIZE(1..4) OF
INTEGER
}
publicKey [15] SEQUENCE
{
modulus INTEGER, -- maximum of 64 value bits in each
INTEGER
exponent INTEGER -- maximum of 64 value bits in each

IEEE-SA
INTEGER
} OPTIONAL,
encryptedSymmetricKey [19] INTEGER OPTIONAL,
-- symmetric session key, encrypted with the receivers public key

KeyId ::= CHOICE {

name GraphicString,
number INTEGER
}
EncryptedAuthenticatedSymmetricKey ::= SEQUENCE
{
encryptedSymmetricKey INTEGER,
--symmetric session key, encrypted with the receivers
public key
time GeneralizedTime,
sender SenderId,
receiver ReceiverId,
signature Signature
-- the signature is computed over ASCII
representation of the
-- preceding four fields with the senders private key
}
Change 9.2 to read:
This standard assigns the following object identifier

{iso(1) identified-organization(3) oiw(14) mmssig(10) abstract-syntax(3) syntax1(1) version1(1)} as an
abstract syntax name for the set of presentation data values each of which is a value of the ASN.1 type
Secure-MMS-APDUs.SR-APDU
where the MMS PDUs argument components are filled by the user of MMS.
The corresponding object descriptor value shall be ST-MMS-PCI.
Change 9.4.1 title to read:
Secure MMS context
Change 9.4.1 to read:
The application context name where application entity is composed of MMS, STASE-MMS, and ACSE
shall have the following object identifier value assignment:
{iso(1) identified-organization(3) oiw(14) mmssig(10) abstract-syntax(3) stase-mms-context (2)
secureMMSContext (1)}
and the following object-descriptor value Secure MMS Application Context.
The ACSE user information field defined in ITU-T Rec. X.227 (1992), ISO 8650: 1988 consists of a
SEQUENCE OF EXTERNAL. This standard specifies that for this application context the order of the
EXTERNALs in the ACSE user-information field is: data supplied for STASE-MMS, if any; data sup-

IEEE-SA
plied for CMISE, as defined in ITU-T Rec. X.711 ISO 9596, if any; data supplied for SMASE, as
defined in ITU-T Rec. X.701 ISO 10040, if any.
Change 9.5.1.3.3 title to:
9.5.1.3.3 P-DATA/A-UNIT-DATA indication primitive
Change Clause 10 to read:
10. Mapping of MMS services to STASE-MMS Services

This clause defines how the STASE-MMS service primitives described in this standard are used by
MMS services defined in ISO/IEC 9506 make use of SR-TRANSFER request/indication service primi-
tives
The SR-TRANSFER service is a non-confirmed service.
Delete Clause 13.
Delete Annex C.
Add Annex E: Use of STASE-MMS and DES-CBC
(This annex is an integral part of this standard.)

The following ACSE authentication value shall be used to indicate DES CBC encryption and authenti-
cation/access control:
STASE-MMS-Authentication-value-des-cbc {iso(1) identified-organization(3) oiw(14) secsig(3) algo-
rithm(2) desCBC(7)}
The use of this authentication value shall indicate that the MMSpdus are being conveyed by STASE-
MMS access control and shall be defined as follows:
DEFINITIONS IMPLICIT TAGS ::= BEGIN
--EXPORTS everything
IMPORTS
SenderId, RecieverID, Signature

From ST-MMS-PCI
{iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) desCBC(7) stase-
pci(1)};
Authentication-value ::= SEQUENCE

{
senderID[0] SenderID,
receiverID[1] ReceiverID,
Time [3] GeneralizedTime,
Signature[5] Signature
}
END
Signature ::= SEQUENCE

{
` signatureValue SEQUENCE SIZE(1..4) OF INTEGER,

IEEE-SA
--maximum of 16 value bits

encryptionParameters EncryptionParameters
}
EncryptionParameters ::= SET
{
symmetricKeyId [0] KeyID,

signatureKeyID [3] KeyID,
passwordID [4] KeyID,
initializationVector [5] OCTET STRING (SIZE(8),
timeStamp [17] GeneralizedTime
}

Architecture (UCA )
TM
Version 2.0
Volume 1
Part 1:
Part 2:
UCATM Profiles
Part 3:
Mapping to MMS
Published by


Palo Alto, CA, USA

Part 3: UCATM Common Application Service Models
(CASM) and Mapping to MMS

plants
IEEE-SA
Introduction
As part of the EPRI-sponsored activities leading to the development of UCA Version 2.0, a number of efforts
were initiated to develop detailed object models of field devices, including definitions of their communica-
tions behavior. Most notable of these efforts are the EPRI-sponsored MMS Forum Working Groups and the
RP3599 project. The models developed within these projects make use of a common set of abstract applica-
tion services to describe the communications behavior of the devices. A standard mapping of these applica-
tion layer services onto UCA application layer protocols, when used in conjunction with the device models,
completely specifies the detailed interoperable structure for utility field devices.
This Part 3 of IEEE-SA TR 1550 defines the UCA Common Application Service Models (CASM) for use in
models of real-time utility field devices, and provides the detailed specification of how to implement the ser-
vices using MMS. It should be noted that while UCA at this time calls for the use of the MMS application
layer protocol for real-time data acquisition and control of field devices, CASM have been defined to be
independent of the underlying protocol. Future versions of UCA may include the mapping of these service
models to alternate application layer protocols.
This document was prepared by the MMS Forum Profiles Working Group, with funding from EPRI RP2949
and participation by members of the EPRI RP3599 project team. The participants deserve special acknowl-
edgment for many months of effort and strong personal commitment.

IEEE-SA
PART 3: COMMON APPLICATION SERVICE MODELS (CASM) AND MAPPING TO MMS TR 1550-1999
Contents
1. Overview........................................................................................................................... 3-1
1.1 Scope.......................................................................................................................... 3-1
2. References ........................................................................................................................ 3-2
3. Functional Requirements................................................................................................ 3-3
3.1 Distribution of End Systems.................................................................................... 3-3

3.2 Device/Processor Capabilities .................................................................................. 3-3
3.3 Dialog Characteristics .............................................................................................. 3-3
3.4 Addressing of Devices............................................................................................... 3-4
3.5 Network Traffic Characteristics .............................................................................. 3-4
3.6 Timing Issues............................................................................................................ 3-4
3.7 Application Service Requirements .......................................................................... 3-4
3.8 Application Data Format ......................................................................................... 3-5
3.9 Operational Requirements....................................................................................... 3-5
4. Basic Service Models ....................................................................................................... 3-6
4.1 DataObject model ..................................................................................................... 3-7

4.2 DataSet model .......................................................................................................... 3-8
4.3 Association Model ..................................................................................................... 3-9
4.4 Data Access Service Model..................................................................................... 3-10
4.5 Reporting Service Model ........................................................................................ 3-10
4.6 Device Control Service Model ................................................................................ 3-11
4.7 Multicast Service Model......................................................................................... 3-12
4.8 Time Model ............................................................................................................. 3-12
4.9 Blob Model .............................................................................................................. 3-12
5. Modeling Devices Using CASM .................................................................................... 3-12
5.1 Introduction to Object Modeling ............................................................................ 3-12

5.2 LogicalDevices ........................................................................................................ 3-15
5.3 DataObjects............................................................................................................. 3-17
5.4 DataSets.................................................................................................................. 3-24
6. Server Model .................................................................................................................. 3-25
6.1 Association Model ................................................................................................... 3-27

6.2 Reporting Service Model ........................................................................................ 3-36
6.3 Device Control Service Model ................................................................................ 3-58
6.4 Multicast Service Model......................................................................................... 3-64
6.5 Time Model ............................................................................................................. 3-65
6.6 Blob Object Model................................................................................................... 3-65
7. Standardized DataTypes ............................................................................................... 3-68
8. Mapping to MMS ........................................................................................................... 3-68
8.1 Service Conformance Codes ................................................................................... 3-68

IEEE
TR 1550-1999
8.2 MMS Conformance ................................................................................................. 3-68

8.3 Error Responses for Confirmed Services............................................................... 3-70
8.4 DataType Model Mapping...................................................................................... 3-71
8.5 Scope of DataObjects and DataSets ...................................................................... 3-72
8.6 DataObject Model Mapping ................................................................................... 3-72
8.7 DataSet Model Mapping ........................................................................................ 3-76
8.8 Server Model Mapping ........................................................................................... 3-77
8.9 Association Model Mapping ................................................................................... 3-78
8.10 LogicalDevice Model Mapping .............................................................................. 3-80
8.11 Device Control Model Mapping............................................................................. 3-80
8.12 BlobData Model Mapping ..................................................................................... 3-82
8.13 Reporting Model Mapping..................................................................................... 3-82

1. Overview
The UCA CASM provide a common set of communications functions (data access, data reporting, data log-
ging, control functions, etc.) that are found in most real-time utility field devices. The use of a standardized
set of application services allows for
a) Isolation of the modeling efforts from the communications details.

b) A high degree of application interoperability, not just in the message syntax but also in the semantics
of the data exchanged.
c) Reduced integration costs, in that there is a consistent access and representation mechanism across
all of the real-time data.
This Part 3 of IEEE-SA TR 1550 describes the models of the common utility communications services and
provides the mapping of those services to MMS.
These common utility communications services are generally supported in most utility communications
systems, except perhaps the services used to retrieve name and type information. Within UCA, these
services are defined independent of the protocols (below) and object models (above). This independance
provides an easier path to both incorporate new protocol stacks and to build well-structured gateways back
to older legacy systems.
1.1 Scope
The application services defined in this technical report are intended to support real-time communications in
devices performing data acquisition and control functions throughout much of the utility domain. The spe-
cific areas of intended use are:
a) Supervisory control data acquisition system (SCADA) and remote terminal unit (RTU) communica-
tions, where SCADA systems retrieve data from dumb RTUs and issue control commands through
these RTUs.
b) Substation automation, where intelligent electronic devices (IEDs) in the substation are networked
with each other and with control center systems.
c) Transmission and distribution automation, where IEDs are located beyond the fence of the substa-
tion on transmission lines and distribution circuits.
d) Power plant automation, where simple and complex equipment are networked throughout the plant
and linked to external systems.
e) Customer site communications, where utilities communicate with more or less intelligent customer
gateways located at customer sites, or customer equipment networked within customer sites.
Note: These gateways and customer equipment can range from very inexpensive appliances at resi-
dential homes, to more complex networking systems at commercial sites, to very sophisticated sys-
tems at industrial customer sites.
This environment has at least some of the following characteristics, although not all characteristics need to
be present:
Configuration: System design may be hierarchical, with a few central sites authorizing and man-
aging the interactions with a large number of field sites, or it may be networked with peer-to-peer
interactions. Communication media may have varying configurations, such as point-to-multipoint,
multidrop, mesh, hierarchical, WAN-to-LAN, intermediate nodes acting as routers, as gateways, or
as data concentrator databases, etc.

IEEE-SA
Media constraints: Communication media may have geographic and utilization constraints, such as
limited bit rates, proprietary data link layers, restricted times for use, and satellite hop delays.
Therefore, the utilization of the media is critical.
Compute and memory constraints: Field equipment will have varying capability levels, such as lim-
ited memory and limited computational capacity. Interactions between nodes of different levels
may require negotiations to determine the least common denominator in these capabilities.
Coexistence of simple and complex equipment on the same network: Communication facilities
must be used efficiently to communicate with equipment that has a wide range of capabilities.
Therefore, the communications architecture must support a wide range of capabilities and interac-
tions between simple equipment, and must be able to coexist on the same network with interactions
between far more complex equipment.
In this environment, the communications architecture must be designed around efficient use of computer
resources as well as minimizing the flow of data over the communications media. The CASM have been
designed to meet these constraints while still providing the functionality required to support common indus-
try practice in each of the areas within their scope.
Other utility communications environments will apply alternate UCA application layer models, services,
and profiles. The UCA Telecontrol Application Service Element 2 (TASE.2) defined in IEC 60870-6-
503:1996 (also called Inter-Control Center Communications Protocol, or ICCP) includes object models of
real-time SCADA data, as well as control center and power plant scheduling and event data, mapped to the
MMS application layer. The TASE.2 object models and services are designed specifically to meet the exter-
nal communications requirements of synchronizing databases between business entities (e.g., between utili-
ties or utility departments) with strict access control, but may be applicable elsewhere.
2. References
This Part 3 of IEEE-SA TR 1550 for CASM and mapping to MMS shall be used in conjunction with the fol-
lowing publications:
EL-7547, Utility Communications Architecture (UCA) Version 1, Volumes 16. These documents describe
the initial requirements and specifications for UCA.
EPRI RP3599, Substation Integrated Protection, Control, and Data Acquisition, Requirements Specification.
This document defines conceptual model and performance requirements for intelligent electronic devices
(IEDs) in substations.
EPRI RP3599, Generic Object Models for Substation and Feeder Equipment (GOMSFE). This document
defines the object definitions for IEDs in substations and on feeders.
IEC 60870-6-503: TASE.2 Services and Protocol, Version 1996-08. (Also known as Inter-Control Center
Communications Protocol, or ICCP). This document provides the specifications for inter-control center
exchange of data using MMS in standard UCA profiles.
IEC 60870-6-802: TASE.2 Object Model, Version 1996-08. (Also known as Inter-Control Center Communi-
cations Protocol, or ICCP). This document defines a set of object models for use in control center and power
plant data exchange applications.
IEC 60870-6-702: TASE.2 Application Profile, Version 1996-08. (Also known as Inter-Control Center
Communications Protocol, or ICCP). This document defines the application profiles and implementation
requirements.

IEEE-SA
PART 3: COMMON APPLICATION SERVICE MODELS AND MAPPING TO MMS TR 1550-1999
ISO/IEC 9506: 1990, Industrial Automation SystemsManufacturing Message Specification. Definition of

the MMS application layer standard, used in UCA for real-time data acquisition and control.
3. Functional Requirements
In general, the requirements for any specific utility field device are specified as part of the modeling process.
The functional requirements specific to CASM (as opposed to either the overall device requirements or
requirements imposed on the underlying profiles) in the utility real-time environment are derived from the
requirements analysis performed during the UCA Version 1.0 projects. This section first provides an over-
view of the key requirements.
3.1 Distribution of End Systems

CASM and their mapping to the UCA application layer protocol must support:
a) End devices and processors, situated anywhere within the utility territory, including in corporate
facilities, in control centers, within substations, within power plants, on transmission lines, on distri-
bution lines, and at customer premises.
b) Communications with systems external to the utility, including over public communications systems
and the public Internet.
c) An overall system environment, which may include high-speed communication channels, low-speed
channels, shared channels, media with unique transmission characteristics such as radio, mobile
radio, satellite, power line carrier, etc.
d) The current and future network configurations, which may include hierarchical subnetworks, peer-
to-peer communications within a subnetwork, and full peer-to-peer communications across the
enterprise.
3.2 Device/Processor Capabilities

CASM and their mapping to the UCA application layer protocol must:
a) Take into account that the processing, computational, and storage capabilities of specific devices
may range from very powerful to severely compute- and memory-constrained devices.
b) Be able to support from one to millions of devices on the same network or subnetwork.
Note: The requirement is based upon an analysis of customer interface meters within an urban envi-
ronment.
3.3 Dialog Characteristics

The CASM and their mapping to the UCA application layer protocol must:
a) Support different communications dialog and data flow requirements, including:

1) One-way only.
2) Two-way alternating (such as a hierarchical polled architecture).
3) Two-way managed by the network protocol or media (such as token passing, CSMA/CD, and
radio-based intelligent media, for handling unsolicited reporting)

IEEE-SA
4) Two-way simultaneous (such as a full duplex WAN).

b) Support messaging across a variety of intermediate devices, local subnetworks, and WAN links.
c) Support multiple concurrent communication sessions between the same devices.
d) Support prioritization of messages and/or the ability to interrupt long messages.
e) Support application level security.
f) Maximize network throughput by supporting efficient encoding or data compression techniques.
3.4 Addressing of Devices

a) Addressing of devices that range in number from a few to millions (e.g., customer meters) on the
same network.
b) Addressing schemes for handling short addresses valid only within local subnetworks, while permit-
ting access to these addresses across wide networks.
c) Addressing schemes for handling broadcast and multicast requirements.
3.5 Network Traffic Characteristics

a) Data rates from very low speeds (10s of bits per second or even less) to ultra high speeds (gigabits
per second) for transferring information and potentially images and graphics.
b) Differing frequencies of transmitting data ranging from low frequency transmissions (once or twice
a year) to high frequency transmissions (milliseconds) to ultra high frequency (in special cases, such
as in substations, on the order of every 50 microseconds).
c) Transmission of messages ranging from a few bytes of data to very large files.
3.6 Timing Issues

CASM and their mapping to the UCA application layer protocol must:
a) Support clock synchronization of devices.

b) Support timestamping with at least one millisecond of accuracy.
c) Minimize time measurement skew, with at least one millisecond of accuracy.
3.7 Application Service Requirements

a) Concurrent access of a system by multiple users

b) Data retrieval, on demand by the client
c) Unsolicited reporting of data, driven by events at the server
d) Report by exception transmission of data, in which only changed data is transmitted
e) Device control commands
f) Event recording and logging of events

IEEE-SA
g) Broadcast and multicast data to devices

h) Remote program control
i) Download and upload of device configuration files
j) Error management and reporting
3.8 Application Data Format

a) Object oriented data structures and functions

b) Data types common to utility applications
c) Self-defining naming conventions for data
3.9 Operational Requirements

a) Network management requirements, including:

1) Recording network protocol statistics, such as the number of temporary and permanent link
failures, data retransmissions, and link utilization.
2) Monitoring, detecting, and notifying of critical network failures to all appropriate users on the
network.
3) Dynamic bandwidth allocation.
4) Online reconfiguration of remote network devices.
5) Charge-back services to reallocate costs to network users or departments.
6) Accounting management facilities for use of third party network facilities.
7) Management of security services and mechanisms to ensure maintenance of overall network
system security.
b) Directory services, including:
1) Identification of applications, processors, devices, and data objects.
2) Integration with outside directory services, such as public e-mail providers.
3) Restriction of information only to authorized users.
4) Search and sort capabilities.
c) Security mechanisms, including mechanisms to ensure:
1) Confidentiality, by preventing the disclosure of transmitted data to unauthorized parties.
2) Integrity, by detecting the modification, insertion, deletion, or replay of transmitted data.
3) Data-origin authentication, by demonstrating that the origin of transmitted data is as claimed.
4) Nonrepudiation, by preventing either the sender or the receiver in a communication from deny-
ing their participation.
5) User authentication, by demonstrating that the identity of a user or system is as claimed.
6) Access control, by guarding against unauthorized access to resources including the attempted
use of resources in an improper manner.

IEEE-SA
4. Basic Service Models

UCA CASM are abstract definitions of common utility communications functions in field devices. Standard-
ized mappings of these abstract services to the UCA application layer communications protocols are
defined, so that common utility functions will be performed consistently across all field devices. Object
models of field devices developed for UCA devices (such as in EPRI RP3599 and the other MMS Forum
Working Groups), whenever possible, make use of these CASM to implement the standard functions.
CASM are defined using object modeling techniques1. Field device models can incorporate these services
by specifying which objects within their models inherit the class objects defined within this document. For
example, if a model of a utility field device contains a control object that requires a two-step commit (select-
before-operate), the object should inherit the attributes and methods associated with the class object select
before operate (SBO) defined in this document. Vendors implementing that device model will then have a
complete specification of the mapping of the service onto the UCA standardized objects.
This section provides an informal description of the abstract application services models. The descriptions
make use of the client-server model, in which the client initiates transactions that are then carried out by the
server at the appropriate time. In general, the services are defined by describing the server procedures that
are invoked by the transactions.
The server model of the common application services consists of nine submodels:
a) DataObject model, which describes the constructs and naming conventions for the field equipment
data and the special data required for the server model.
b) DataSet Model, which describes the constructs and services for grouping Data Objects within the
server for efficient communication of data.
c) Association model, which describes the constructs and services for establishing and relinquishing
connections between a client and the server.
d) Data access service model, which describes the constructs and services that must be supported by
the server to allow clients to retrieve data directly and set data values at the server.
e) Reporting service model, which describes the constructs and services that the server must support to
monitor conditions and generate reports in an ongoing manner, based on parameters initially estab-
lished by the client.
f) Device control service model, which describes the constructs and services that must be supported by
the server to allow clients to control devices connected to the server.
g) Multicast service model, which describes the constructs and services associated with multicast oper-
ation.
h) Time model, which describes the constructs and services that the server must support to allow access
to and synchronization of the implementations local time.
i) Blob model, which supports the transfer of arbitrarily large data that would otherwise not fit inside a
single message. Examples would include private configuration data transferred from client to server,
and transient data recordings transferred from server to client.
The server model is illustrated in Figure 1.
1Refer to books by Rumbaugh, Booch, COAD, or Yourdon for background information on object modeling tech-
niques and definitions.

IEEE-SA
Server Model
Data Set Device Control
Model Model
Association Multicast
Model Model Data
Object
Data Access Time Model
Model Model
Reporting Blob
Model Model
Figure 1: Server model
4.1 DataObject model

A DataObject is an abstract element of a real device that is capable of providing and/or accepting (being read
and/or written) a typed data value. A DataObject is defined to represent a single data element with no sub-
structure (i.e., one measurement point such as a voltage value DataObject), or a hierarchical data structure
using inheritance constructs (i.e., a complex set of data elements that together represent a common function-
ality such as a switch DataObject). If a DataObject is structured, it also contains DataObjects, which
together form a device/object hierarchy. Examples of these concepts are: a switch status DataObject (a single
element) within a switch DataObject, or the voltage measurements for three phases (a structure containing
three data elements).
The models of the real physical utility field devices are defined in other UCA documents, such as Generic
Object Models for Substation and Feeder Equipment (GOMSFE) from EPRI RP3599, and the other model-
ing documents being produced by the EPRI-sponsored MMS Forum (see Figure 1). These documents
describe the devices in terms of DataObjects and specify the network behavior of the devices by stating
which DataObjects within those devices inherit specific models of abstract services defined in this docu-
ment. This common use of the abstract services allows all of the UCA device models to be mapped to the
underlying communications protocols in the same way.
This technical report thus assumes that the specifics of each DataObject (including its relationship to physi-
cal measurements, etc.) which represents real utility data in the field device have been specified elsewhere.
When a DataObject is used with any of the abstract services defined in this document, however, a number of
things regarding its network behavior must be specified. Specifically, the DataObject model included in this
document provides for a common way of representing:
Models of common devices: What a device is and how it is structured so that a utility logical view
is obtained that maximizes interoperability between different systems.
Hierarchy: How the hierarchical aspects of device functionality and organization are implemented.
Self-description: How self-description of a DataObject is supported so that a complete model may
be discovered from a compliant device through the communications services.
Optional/custom components: How models can be extended and tailored without impacting the
interoperability between standard features.
Examples of DataObjects include:

IEEE-SA
a) A single direct point (e.g., the voltage on phase A of line ABC within voltage regulator XYZ, or a
text message).
b) A single calculated point (e.g., line status, calculated by Boolean operations on breaker and switch
status of the line).
c) A structure of a point that includes additional associated data (e.g., breaker UVW, including the
breaker status, the associated recloser status, multiple trip-close operations indication, data quality,
counter of operations, and timestamp of last operation).
d) A group of points (e.g., the group of all analog values in the RTU). This group is an efficient method
for transferring data, especially if the server is limited in memory and/or computational power, or if
the communications media is limited in bandwidth. The encoding of the group of data is performed
by an application in the server, while an application in the client is responsible for deciphering the
data, based upon the location of the data within the received group.
e) A control point that is associated with an action that the server could initiate with other devices.
Some DataObjects may have both a value plus an associated control point or setpoint. The control
point or setpoint is written to by the client, while the value is read by the client. For instance, a
breaker object has a status value (closed breaker), and the control point that can be used to change
the status (trip the breaker).
f) A time-series of a point (e.g., phase-angle values for a point for every one second over the last 30
minutes).
g) A graph with x-y coordinates (e.g., y-values associated with every x-value).
h) A common functionality (such as a recloser or switch).
i) Special server DataObjects used within the server to support the server model. These DataObjects
are described in each of the relevant sections.
A DataType is an abstract definition of the class of data values that may be conveyed by the DataObjects
value. A DataObjects DataType determines its abstract syntax, its range of possible values, and its represen-
tation while being communicated. The DataType of a DataObject may be hierarchical if the DataObject
itself contains DataObjects.
4.2 DataSet model

Some of the UCA abstract services require a mechanism to specify arbitrary, although ordered, groups of
DataObjects. A common example is when the same groups of arbitrary DataObjects are required to be trans-
mitted to one or more clients over and over again, possibly on an exception basis (e.g., all voltage and amp
measurements for a distribution feeder, or the MegaWatt values of all utility interchange points with other
utilities, or temperature readings inside and outside a house). It is convenient to establish a single name for
the collection, with a mutual understanding of its definition by both client and server.
A DataSet is an ordered list of references to DataObjects, organized as a single collection for the conve-
nience of the client. Note that the DataObjects referenced within a DataSet can be from anywhere in the
object hierarchy (i.e., substructures contained in more complex objects). The membership and order of the
DataObjects in a DataSet are known to both the client and the server, so that only the name of the DataSet
plus the actual values of the referenced DataObjects need to be transmitted. This capability thus permits
more efficient use of the communications bandwidth. DataSets may be predefined by the server, or may be
defined through requests by the client.
The following are the capabilities and constraints for defining DataSets:
a) The grouping of DataObjects into one or more DataSets is not constrained by the type of the
DataObject.
b) Any DataObject may have membership in one or more DataSets.

IEEE-SA
c) A DataSet may refer to the same DataObject one or more times.

d) Different DataSets can also be constructed for different clients in the same server.
e) DataSets may not be nested; for example, a DataSet may not reference another DataSet.
f) Certain requirements when using DataSets with the data reporting services dictate constraints as to
what level of substructures of a DataObject may be referenced in a DataSet (e.g., whether the
DataSet should have one reference to the single DataObject containing voltage, amps, and breaker
status, or whether it should have multiple references to separate DataObjects within the top level
DataObject: one to its voltage substructure DataObject, a second to its amp substructure DataObject,
and a third to its breaker status substructure DataObject).
Examples of DataSets:
Group of voltages, amps, and vars for all three phases in voltage regulator
Group of all breaker statuses in an RTU
Group of all statuses and measurements in a meter
Group of outside temperature measurements within a towns boundary
Group of maintenance parameters
Less capable servers may be limited to predefined DataSets whose definition is passed to the clients upon
startup. More capable servers may permit clients to pass DataSet definitions for creation at the server. Cli-
ents can determine the servers capabilities regarding the creation of DataSets during the initialization pro-
cess through determining the capabilities supported by the server.
For instance, a dumb RTU or a simple IED server may have predefined DataSet lists programmed into a
read-only memory as part of the database, while a more sophisticated RTU or IED server may be able to
dynamically establish DataSets based on interactions with different clients.
The client must either keep a copy of each DataSet name list definition or read them from the server, since
the DataObject names will not be sent with the data. The specific method used by clients for maintaining
consistency of DataSets definitions between the client and server is a local issue.
4.3 Association Model

The association model defines the environment of the CASM, as well as the services and capabilities pro-
vided for managing associations between clients and servers.
Different implementations will have different capabilities and constraints. One of the first steps in establish-
ing an association between two entities is the retrieval of what level of capabilities are available in the server.
For example, some classes of devices will not be required to handle complex reporting mechanisms and the
downloading of programs; simpler devices can have this type of information preprogrammed into them as
fixed capabilities. More intelligent devices can make use of the flexibility provided by the more sophisti-
cated capabilities.
Each association may have distinct security and access control attributes, based on the identity and authority
appropriate to the parameters presented by the client. The server may therefore grant only limited access to
capabilities for the association, or may present a different device model to the client. Some capabilities of a
server may not be available due to its current status. Servers may restrict reconfiguration or even write access
to data if the operational status is suspect. The association model specifies the attributes of an association
and how they must be supported.

IEEE-SA
4.4 Data Access Service Model

Clients may retrieve the data values of DataObjects from servers through direct requests (GetDataObjectVal-
ues), and may set the data values of DataObjects through direct set commands (SetDataObjectValues). This
data could be one or more explicitly specified DataObjects, or all DataObjects in a specified group
(DataSet). The following examples illustrate the use of the services:
a) A client may retrieve one or more DataObjects directly by name (e.g., one breaker object consisting
of breaker status, recloser status, momentary change detect, tagged condition, and counter of opera-
tions). The procedure is as follows:
1) The client issues a GetDataObjectValues request with a list of names of the DataObjects.
2) The server responds with the values of the DataObjects. Note that each DataObject may be
structured, so all subelements of the DataObject are returned.
b) A client may retrieve all data in a specified group of data from a server (e.g., groups consisting of all
status values, or all nameplate information, or all three phases in a voltage regulator). The procedure
is as follows:
1) The client issues a GetDataSetValues request with the name of one DataSet.
2) The server responds with the values of the DataObjects referenced by the DataSet. If a struc-
tured DataObject in the DataSet has more than one data element, all data element values are
returned in the response.
c) A client may set one or more DataObjects directly by name, (e.g., set the thermostat setting to a new
temperature, or set a report criteria deadband percentage, or set the time period for periodically
reporting a specific DataSet). The procedure is as follows:
1) The client issues a SetDataObjectValues request with a list of names of the DataObjects and the
values to set them to.
4.5 Reporting Service Model

The data retrieval service model described above is based on a request/response type of transaction, in which
each set of values sent from the server is in direct response to a single request by the client. The reporting
model provides an alternate method of transferring data from the server to the client. The reporting model
permits the client to perform a single transaction to set up report definition parameters, after which the server
repeatedly reports DataObject values without further client actions. The reporting model consists of:
a) An Event Agent, which monitors data within the server, and generates event notifications when spe-
cific criteria are met. The Event Agent is controlled through parameters that may be written by the
client into ECBs. The ECB parameters include which DataObjects to monitor, the particular moni-
toring algorithm to employ (e.g., deadband), parameters for the monitoring algorithm, timing values,
and which data to include in the event notifications.
b) A Report Agent, which enrolls with the Event Agent to receive event notifications of specific events.
Upon receipt of event notifications, the Report Agent generates reports for transmission to the client.
The Report Agent is controlled through parameters that may be written by the client into report con-
trol blocks (RCBs). The RCBs include formatting information for the report, as well as parameters
that allow for the bundling of multiple event notifications into single reports.
c) A Log Agent, which also enrolls with the Event Agent to receive event notifications of specific
events. Upon receipt of event notifications, the Log Agent stores the data for later retrieval by the cli-
ent. The Log Agent is controlled through parameters that may be written by the client into log con-
trol blocks. The log control block defines various aspects of the logging function, such as overflow/
wrap control, etc.

IEEE-SA
The elements of the reporting model may be used within device models to build very complex data reporting
schemes. Likewise, with appropriate specification of defaults and specializations, these same models can
define the simple schemes within the most memory constrained small devices.
In some cases in which most of the parameters of the event, report, and log control blocks are not used
within a device model, an additional data structure may be defined that represents a combined ECB and
RCB, but that only contains those fields accessible by the client. The TASE.2 transfer set object, for exam-
ple, is such a representation.
Figure 2 shows the constructs and relationships of these elements in the reporting model.
Reporting Model
Control Event
Blocks Agent
Field
Data Devices
Clients Objects
Report
Reports Agent
Server
Figure 2: Reporting Model
4.6 Device Control Service Model

Typical utility applications require specialized access methods for DataObjects that represent physical con-
trols in field devices. These access methods include such mechanisms as a two-step commit, device lockout,
and tagging out of service. The UCA device control service model provides such access methods for
DataObjects that represent physical controls within the UCA field device. The device control services con-
sist of four models: direct control, SBO control, time activated control, and device tagging.
The direct control model allows for a single-step control operation, with validation of the control command
in terms of access rights, operational status, and suitability of the control operation being requested. A typi-
cal application of a direct control is an analog setpoint.
The SBO control model allows for a two-step control operation, in which the device must be explicitly
selected before executing the control operation. Trip/close or raise/lower commands are typical applications
of SBO controls that may require an explicit select service before execution of the control.
The time activated control model allows a control operation to be scheduled to occur at a given time, allow-
ing for synchronous controls across different servers.
The device tagging model allows clients to set and remove the values of different types of tags on devices
that will inhibit remote operation. The current tag state of a device may also be retrieved by a client.

IEEE-SA
4.7 Multicast Service Model

Certain services (such as reporting) can be used in a multicast environment, delivering unconfirmed mes-
sages to multiple destinations in the network. The multicast model provides for definitions required to sup-
port group addressing and enrollment within CASM systems.
4.8 Time Model

The time model provides the elements required for providing and maintaining accurate time for use in
reporting (time stamps) and device control (time activated operations).
4.9 Blob Model

The blob model provides the classes that enable the transfer of arbitrarily sized data between client and
server. Applications requiring such a transfer include (as examples):
Downloading of a binary image containing private configuration information to a server

Transferring a large transient data record from a waveform recorder
Other potentially large data transfers often termed file transfers
The CASM blob transfer model allows the exchange of such data independent of the negotiated maximum
single message size by segmenting the object and transferring the segments sequentially. Either the client or
the server can initiate the transfer of the blob data and the transfer can be in either direction.
5. Modeling Devices Using CASM

This section describes the model for the representation of devices and device characteristics as viewed over
the network.
5.1 Introduction to Object Modeling

Object oriented terminology used in this introductory section include: class, object, method, attribute,
inherit, instantiate, and aggregate. They are briefly described:
A Class is a template for the creation of objects. Classes abstractly define attributes (data) and
methods (services) used to perform some related function. A class can be considered an agreed
upon description of some commonly observable thing or process. Attributes represent the state
information described by a class. They can be considered the things that a class has. The methods of
a class define the operations that the class supports. In other words, what you can do with it.
Classes can inherit from one or more classes by taking on the attributes and methods (and hence the
functionality) of the class(es) it inherits from. This inheritance may include generalization and spe-
cialization, in which the abstract attributes and methods are enhanced, restricted, or extended by
some further definition. An inheritance hierarchy can be defined in which simple classes can be
refined into more and more complex classes. An inheritance hierarchy is often presented as a pic-
ture of an inverted tree with the branches representing the path of inheritance from ancestor to
descendant and the leaves representing the classes in the hierarchy.
Classes may also aggregate other classes. This means that one class, the child, is contained in
another class, the parent. The properties of the child can be accessed through the parent by navigat-

IEEE-SA
ing down the containment, or aggregation, hierarchy. For this reason, aggregation provides another
kind of inheritance in that the parent can be considered to have the attributes and methods of the
classes that are contained. An aggregation hierarchy is often presented like a file system on a PC
where at each level of containment there are files (primitive classes) or folders (parent classes
aggregating more child classes).
An object is an instance of a class. The process of instantiation is the creation of an object from
its class. Each instance has a unique identity. For example, an RTU is a well-known class of utility
device. If I purchase one, I have an instance, or object, of the class RTU. Its unique identity might
be R1234, a reference number used by the owner to identify it among all the other devices it owns
and operates. While all RTUs may be similar, there is one, and only one instance R1234.
Device models based on CASM represent the behavior of real devices by defining standard classes and
objects (instances of classes) built up through inheritance and aggregation from the basic CASM class defi-
nitions. Users of CASM-based devices can access the device features through well defined network services
operating on the objects. The CASM data access model defines the rules for defining and organizing the
object models specified by industry groups into objects that can be used in communications.
In CASM, objects that are directly accessible by a client through a network are contained in an object from
the server class. The servers, and the object instances that they contain, are mapped to the UCA communica-
tions protocols through the procedures defined in this document.
Objects within a server inherit from the CASM classes LogicalDevice, DataObject, and DataSet, described
in this section. In addition, three special classes that inherit from DataObject are DeviceIdentity that contains
nameplate information, DeviceModel, which is the representation of the complete device function, and, FC,
FunctionalComponent, which groups common components of device functionality in an easy to use form
inside a DeviceModel.
A LogicalDevice is the way CASM represents the capabilities of a real device. As in real devices, Logi-
calDevices are a composite of the following parts: an enclosure, a nameplate, and one or more subassemblies
that together provide the functionality of the complete device. For example, a distribution relay device might
include several standardized relay functions. In addition, an electronic distribution relay would likely have a
capability to measure the voltages and currents in the conductors it is controlling. To represent this device in
CASM, a LogicalDevice would be created that contained a nameplate, DeviceIdentity, a measurement unit
DeviceModel, and one or more standardized relay function DeviceModels.
It should be noted that CASM allows for arbitrary assembly of DeviceModels into LogicalDevices. The
composition of a LogicalDevice is left to the manufacturer and can always be determined from an instance
of an LogicalDevice via the communications services of CASM. Figure 3 is a conceptual model of the com-
munications server as represented by CASM.

IEEE-SA
CASM Classes for Modeling Devices
Server LogicalDevice DeviceIdentity DeviceModel FunctionalComponent DataObject DataSet
Server@<address>
R1234 DI
AllValues Other
RTU RTU.MX.ACS1.i Models and

RTU.MX.ACS2.i Services
RTU.CF
RTU.CF.ACS1 RTU.MX.ACS3.i
RTU.CF.ACS1.d
RTU.MX
RTU.MX.ACS1
RTU.MX.ACS1.i
RTU.MX.ACS1.t

Object s representing devices through

communications are instance s of
CASM Class es
Figure 3: CASM device modeling classes and their relationship to objects
As shown in Figure 3, the server consists of one or more LogicalDevices, LD (e.g., R1234). Each Logi-
calDevice contains one DeviceIdentity, DI, one (typically) or more DeviceModels, DM (e.g., RTU), and zero
or more DataSets, DS (e.g. AllValues).
Each DeviceModel contains a set of FunctionalComponents, FCs (e.g., RTU.CF, RTU.MX), which in turn
contain sets of simpler DataObjects, DO, (RTU.MX.ACS1, ), which represent the behavior of the mod-
eled device.
The use of LD, DO, DM, DI, FC, and DS as abbreviations for the longer names simplifies tables and will be
used interchangeably from this point forward.
The DMs are described in other UCA device modeling documents and are templates for making objects that
represent the device functionality. In this regard, the RTU DeviceModel is not an RTU, but is the template
for an RTU. To make an object of the model, one needs to instantiate it. The act of instantiating an RTU is
like building an RTU from a set of blueprints. The RTU object is created according to the specifications of
the RTU DeviceModel template and is placed in a virtual version of an electronic device, a LogicalDevice.
However, just like placing a single board computer in an electrical enclosure in order to mount it to facilitate
its use, an RTU object is placed in a container to facilitate its use for communications purposes. The con-
tainer for the RTU object (and any other DeviceModel instance) is a LogicalDevice. Similar to the enclosure
that houses the circuit board, the LogicalDevice does not externally reveal much about the nature of what is
inside. It is only by using or browsing what is inside that makes the functionality of the assembly apparent.
As with most electronic enclosures, LogicalDevices have a nameplate that lists make/model/serial number
and other related information. Typically nameplates deal with information that is independent of the purpose

IEEE-SA
of the device. The nameplate class for CASM is the DeviceIdentity, DI.
Therefore, the LogicalDevice contains a nameplate and some contained functionality. In CASM the name-
plate is an instance of the DI class, and the functionality is an instance of one or more DMs.
Finally, DataSets, DS, represent lists of references to DOs that can be accessed by a single name in commu-
nications. The principal advantage is that, for these common groupings, a simple short message can request
a substantial amount of selected information.
Therefore, to summarize the classes that the CASM provides to use in modeling utility devices:
LogicalDevices (LD): Containers for objects representing device functionality, DeviceModels, and
nameplate, DI. In addition, LogicalDevices contain convenient lists of frequently accessed or
referred to information, DataSets.
DataObjects (DO): Used to represent the specific elements of functionality of the device. These
DataObjects may be hierarchical and may be nested in any number of levels.
DataType: The composition of a DataObjects value attribute. Interoperability of devices using
CASM basically comes from agreed upon DataObject names and DataType.
DeviceModels (DM): Used to represent the idealized functional models of real devices. DeviceMod-
els inherit the properties of DataObjects. DeviceModels are assembled from a reusable set of Func-
tionalComponents.
DeviceIdentity DataObject (DI): Contains the information that is commonly found on a nameplate
found on most equipment. The components of DI represent a guaranteed minimum set of interopera-
ble information available from all CASM compatible devices independent of device purpose.
FunctionalComponents (FC): Structured DataObjects that act as a framework to group common fea-
tures of a device and are the major components of a DeviceModel. A FunctionalComponent orga-
nizes information by purpose, such as measurements (MX), configuration information (CF), status
inputs (ST), or descriptions (DC), to name a few.
DataSets (DS): Used to group commonly used DataObjects for easy retrieval. A LogicalDevice can
have zero or more DataSets. DataSets are flat (nonhierarchical) ordered lists of references to
DataObjects (DOReferences).
The balance of this section describes these classes in detail.
5.2 LogicalDevices
A LogicalDevice is a virtual representation of a real underlying physical device. Servers may contain multi-
ple LogicalDevices. An example of such a server is a gateway device that presents the models of the devices
behind it onto the network.
The underlying object model of a LogicalDevice can be determined by reading the names and types of the
DataObjects and DataSets contained in it. That is, a browser can completely determine the composition and
data types of any DataObject. In this regard the structure of LogicalDevices is self-describing.
When there is more than one LogicalDevice representing a single physical device (i.e., one nameplate) then
the DeviceIdentity of the LogicalDevices will be the same.
LogicalDevices always contain one DI (always named DI), one or more DeviceModels, zero or more
DataSets, and zero or more other DataObjects.

IEEE-SA
For example, a LogicalDevice might contain a DeviceModel for an electric meter.
A load tap changer representation might be contained in a LogicalDevice. The LTCC DeviceModel com-
ponent represents the network view of this function of the device. If the device were connected to the UCA
network through an intermediate system that also must be managed, the intermediate system might also con-
tain a gateway component to manage its local operation, as well as an LTCC component representing
the actual tap changer behind the gateway. This LogicalDevice would have two DeviceModelsone to rep-
resent the LTC functionality, and one to represent the properties of the gateway. Since the gateway function
and the LTC function are closely related, it makes sense for them to be contained in a single LogicalDevice.
Another example might have an RTU that represents the multiple LTC functionality it is performing as well
as the underlying function of the RTU as a collection of analog and digital inputs and outputs. In this case it
would make sense to represent it as several LogicalDevices one for the RTU, and one for each of the
LTCs.
5.2.1 LogicalDevice Object Model
This section describes the formal object model for LogicalDevice:
Model: LogicalDevice
Key attribute: LDReference

Attribute: Deletable
Attribute: ListOfDataObjects
Attribute: ListOfDataSets
LDReference Identifier that unambiguously defines the LogicalDevice within the scope of the
server.
Deletable Attribute that defines if the LogicalDevice may be deleted through the use of
CASM services. If the attribute has a value of TRUE, then the LogicalDevice may
be deleted from the server through the use of the DeleteLogicalDevice service.
ListOfDataObjects List of DataObjects contained in the LogicalDevice.
ListOfDataSets List of DataSets contained in the LogicalDevice.
The set of abstract services defined for LogicalDevices are:
a) GetDataObjectsList: A client uses this service to retrieve the list of DeviceModels and other
DataObjects made available by this LogicalDevice.
b) GetDataSetsList: A client uses this service to retrieve the list of DataSets made available by this
LogicalDevice.
c) CreateLogicalDevice: This service is used to create a new LogicalDevice on a server.
d) DeleteLogicalDevice: This service is used to delete a LogicalDevice from a server.
5.2.2 LogicalDevice Naming Conventions
Each server within a network can represent multiple logical devices, each implementing one or more
DeviceModels. A LogicalDevice within a server is identified by the LDReference name. LogicalDeviceRef-
erence must be unambiguous within a server. It is also recommended that LDReference names be unique

IEEE-SA
within the scope of the network and use only the limited alphanumeric character set that includes (a-z, A-Z,
0-9, and _). It is recommended that LDReference names be definable at time of installation, rather than at
time of manufacture so that network uniqueness can be achieved.
One possible naming convention (not required) consists of naming the LDReference with a prefix that clas-
sifies it for some useful purpose, and a suffix that is an alphanumeric identifier that uniquely identifies this
instance of the same classification in the network. For example, a utility managing a network of electric
meters might find it useful to maintain the naming convention Mxxxxx, where the M represents the cat-
egory of devices, and the xxxxx is a five-character alphanumeric identifier (a-z, A-Z, 0-9), providing for
(26+26+10)5 unique names for that common device.
5.3 DataObjects
DataObjects, as discussed earlier, are arbitrarily complex aggregation hierarchies of primitive and other
DataObjects. The nature of the design of any DataObject is optimized to suit the needs of the modeler. That
is, the modeler designs DataObjects so that a reasonable representation of real devices can be obtained when
constructing CASM DeviceModels.
A DataObject is an abstract element that is capable of providing (when read) or accepting (when written), or
both, a typed data value. A DataObject may represent a single data element (i.e., one measurement point) or
a data structure (i.e., a complex set of data elements that together represent a common functionality such as
a switch). The mapping of a DataObject to a real, physical entity in the device is defined by the manufac-
turer of the device being represented and is outside the scope of this document.
Each DataObject also is defined to be in some scope. The scope of any subordinate object (i.e., contained
within a higher level DataObject) is defined to be that of its parent. DataObjects can have server scope (not
contained within a LogicalDevice), Local scope (contained within a LogicalDevice), or NonShared scope.
DataObjects with NonShared scope are defined as private to each association, and deleted when the associa-
tion is terminated. Each association has its own instance of the DataObject.
Examples of DataObjects include:
a) A single direct point (e.g., the voltage on phase A of line ABC within voltage regulator XYZ, or a
text message).
b) A single calculated point (e.g., line status, calculated by Boolean operations on breaker and switch
status of the line).
c) A structure of a point that includes additional associated data (e.g., breaker UVW, including the
breaker status, the associated recloser status, multiple trip-close operations indication, data quality,
counter of operations, and timestamp of last operation). This would be a DataObject that aggregates
other DataObjects.
d) A control point that is associated with an action that the server could initiate with other devices.
Some DataObjects may have both a value and an associated control point or setpoint. The control
point or setpoint is written to by the client, while the value is read by the client. For instance, a
breaker object has a status value (closed breaker) and a control point that can be used to change the
status (trip the breaker).
e) A time-series of a point (e.g., phase-angle values for a point for every one second over the last 30
minutes).
f) A graph with x-y coordinates (e.g., y-values associated with every x-value).
g) A structure containing the nameplate information of a LogicalDevice, DI.
h) A complete idealized functional model of a real device, such as a recloser or switch.
i) A FunctionalComponent, a group of DataObjects representing a common purpose (e.g., the group of
all measurements in the RTU).

IEEE-SA
5.3.1 DataObject Object Model
This section describes the formal object model for DataObject:
Model: DataObject
Key attribute: DOReference

Attribute: Ancestry
Attribute: Scope
Attribute: DataType
Attribute: Value
Attribute: Access Control (private)
Attribute: LocalResource
DOReference Identifier that unambiguously defines the DataObject within the scope of the server.
Ancestry The class hierarchy of DataObject classes from which this instance was derived.
Scope Attribute that defines the availability of the DataObject across multiple associations.
Instances of DataObjects must be unambiguously identified within their scope. Note that
the scope attribute of aggregated DataObjects is inherited from their parents. DataObjects
can have local, server, or nonshared scope.
DataType The abstract type of the value represented by the DataObject. The DataType can be primi-
tive (e.g., integer) or may be a complex structure.
Value The current value of this DataObject returned by a GetDataObjectValues method, or set by
a SetDataObjectValues method.
Access Control The network visibility and access privileges of the DataObject to calling clients. The rep-
resentation of access control is a local matter, since access privileges to DataObjects and
their associated components are implicit within the DataObject model. The capability to
refuse access is refined further in 6.1.1.
Deletable Attribute that defines if the DataObject may be deleted through the use of available server
services. If the attribute has a value of TRUE, then the DataObject may be deleted from
the server through the use of the DeleteDataObject service.
LocalResource An optional local reference, such as an address, used in the creation of new DataObjects
and their location within the server (definition is a local matter).
DataObjects may be acted upon directly or may be acted upon through their use within other classes of
objects as described in later sections. The set of abstract data access services defined for DataObjects are:
a) GetDataObjectValues: A client uses this service to retrieve the values of one or more DataObjects
from the server.
b) SetDataObjectValues: A client uses this service to set the values of one or more DataObjects being
made available by the server.

IEEE-SA
c) SetDataObjectValues (Unconfirmed): A client uses this service to set the values of one or more
DataObjects being made available by the server. No response is given to this request.
d) GetDataObjectAttributes: A client uses this service to obtain the type description attribute of a spec-
ified DataObject being made available by the server.
e) CreateDataObject: A client uses this service to create a DataObject.
f) DeleteDataObject: A client uses this service to delete a DataObject. The DeleteDataObject service
shall return a result indicating FAILURE if the service is applied to a DataObject that has a deletable
attribute with a value of FALSE.
5.3.2 DataType
A DataObjects DataType defines its format or structure, range of possible values, and representation while
being communicated.
DataTypes may be simple or complex. Complex DataTypes describe the value of DataObjects that aggregate
or contain subordinate DataObjects such as arrays or structures. The data types used in the UCA models are
shown in Table 1.
Table 1: Data Types in UCA Models
UCA Standard
Description, Range of Values (where applicable)
DataType Name
BOOL Boolean1 bit, True (1) or False (0)
BSTR2 Bitstring2 bits
BSTRn Bitstringvariable number of bits
INT8U Unsigned integer8 bits, 0 to 255
INT16U Unsigned integer16 bits, 0 to 65,535
INT32U Unsigned integer32 bits, 0 to 4,294,967,295
INT8S Signed integer8 bits, -128 to +127
INT16S Signed integer16 bits, -32,768 to + 32,767
INT32S Signed integer32 bits, -2,147,483,648 to +2,147,483,647
FLT32 Floating point, IEEE format, single precision
FLT64 Floating point, IEEE format, double precision
VSTR8 Printable ASCII text string8 characters
VSTR16 Printable ASCII text string16 characters
VSTR32 Printable ASCII text string_32 characters
VSTRn Printable ASCII text string1 to n characters
VSTR Null terminated, printable ASCII text
OSTRn Octet string1 to n length
BTIME4 Number of ms since midnight4 octets (GMT)

IEEE-SA
Table 1: Data Types in UCA Models (continued)
UCA Standard
Description, Range of Values (where applicable)
DataType Name
BTIME6 Number of ms since midnight and days since 1 January 19846 octets
(GMT)
ENUM8 Enumerated value, 8 bits, signedWell-known values positive, 0 always
reserved and unused
ENUM16 Enumerated value, 16 bits, signedWell-known values positive, 0 always
reserved and unused
IDENT A printable ASCII text string representation of a DOReferenceidentifies
a DataObject or subcomponent of a DataObject within the scope of the
server
STRUCT Structure
ARRAY <TYPE>[i][j][k] ..ARRAY elements for three dimensions of TYPE
BLOB A reference to a binary large object that can be transported in pieces rather
than a single messaging transaction
Note: The UCA standard data type name shown should always be presented in upper case
5.3.3 References to DataObjects
GetDataObject, SetDataObject, GetDataObjectAttributes, CreateDataObject, and DeleteDataObject take

one or more references to DataObject names as arguments. In addition, the DataSet model described in the
following sections makes significant use of DOReferences. The DOReference is formed according to the
rules of this section.
The DOReference is formed by prepending a scope designator to a name that describes the top level
DataObject and the nested components that are specified. When ancestry (inheritance) information is to be
specified, a suffix is appended to the reference.
A DataObject that is contained in a structured parent DataObject has its name constructed by appending the
name of the structure component to the name of the parent, separated by a . Note that the structures (and
hence the names) can nest arbitrarily deep.
This formal DOReference name may not always be explicitly used in the underlying application layer proto-
col but must be derivable from its representation.
5.3.3.1 References to DataObjects: Scope designator
The scope designator is constructed according to the following rules:
a) If the DataObject is of server scope (contained in the server model, but not in a LogicalDevice), its
scope is null.
b) If the DataObject is of local scope (contained in an instance of a LogicalDevice), its scope is the
LDReference of the instance of LogicalDevice.
c) If the DataObject is nonshared (private within the scope of a single communications association), its
scope is @.
d) The scope is completed by appending the /, slash character.

IEEE-SA
5.3.3.2 References to DataObjects: Ancestry suffix
When using the CreateDataObject service, and in return values of GetDataObjectsAttributes, the DORefer-
ence is extended to include its ancestry information as a suffix. The suffixes, therefore, represent the inherit-
ance hierarchy of the DataObject. They are constructed by appending the inherited class-object names from
the highest in the hierarchy down to the immediate ancestor. The rules for constructing the suffixes are:
a) The ancestry suffix begins with the colon, :.

b) The most recent ancestors DataObject name is then appended.
c) Each sequential ancestor is then appended to the suffix separated by a colon, :.
d) Ancestors are appended until an ancestor is reached that was part of the UCA2 standardized
DataObjects.
e) If a newly designed DataObject is created, it has the default ancestry of DO. This can be assumed
and not listed in the suffix.
f) The base class ancestor of all DataObjects, DO, is never listed and can be assumed.
5.3.3.3 Examples of References to DataObjects
The integer value, i, of the temperature of the temperature sensor in a thermostat:
ATempController/Thermostat.MX.TempSensor.i
The scale of a transformers second phase voltage measurement:
M1234/Txfrm.CF.Volts[2].s
The value of a transformers first and second phase voltage measurement:
ATransformer/Txfrm.MX.Volts[1..2].v
An ECB for the event reporting model with communications association scope:
@/block[1]
A new thermostat model myTx that is derived from the standard thermostat model and that adds a running
moving average value a:
For use in CreateDataObject, include inheritance (which will define the type):
ATempController/myTx:Thermostat.MX.TempSensor.a
For use in GetDataObjectValues:
ATempController/myTx.MX.TempSensor.a
5.3.4 DataObject Naming Conventions
While the correct operation of the CASM services does not depend on strict naming conventions, the follow-
ing guidelines are recommended when defining DeviceModels for use with CASM:
a) Each standardized name should be written using upper/lower case boundaries as opposed to spaces
or underscores. The elimination of spaces preserves the ability to use the names directly in program-
ming. The use of upper/lower case boundaries instead of underscores reduces the number of bytes
on the wire by one for each use. Concise nomenclature is desired because some transport mappings
will use the names in the message and this effects bandwidth.

IEEE-SA
b) Each standardized name can be used only onceindependent of the position the name may have in
an aggregation/hierarchy/structure. This preserves the future possibility of canonical addressing
which substitutes unique numbers for names in allowing for lossless compression of named binding
and thus bytes on the wire. This means that the same name, wherever it is used in a DataObjects struc-
ture, must always represent the same thing. This means that V cannot be voltage in some uses and
vapor pressure in others. It is useful to have, however, MX.V and CF.V. In this case V appears in
different DataObjects, but still represents the same classification of information. In fact it serves to
associate two related but independent pieces of information about the same thinga voltage, V.
c) Single character names are reserved for the most basic and often used common DataObjects, such as
i for integer value, u for units, etc.
d) Do not use $ or _ or other delimiters in standardized names since they may not translate easily
in some application layers or are reserved to assist in translation to specific application layers.
e) Names with three or fewer characters are reserved for standardization by standards bodies.
5.3.5 DeviceIdentity DataObject
The DeviceIdentity is a DataObject that represents the physical nameplate of the device. Each CASM
LogicalDevice contains a DeviceIdentity object named DI of the following structure, as shown in Table 2.
Table 2: DataObject Definition: DI
Component DataType Range

DI struct DeviceIdentity DataObject
DI.Name vstr32 Name of device
DI.Class vstr32 Product classification
DI.d vstr32 Description of device
DI.Own vstr32 Owner of device
DI.Loc vstr128 Location
DI.VndID struct Source of device
DI.VndID.Vnd vstr32 The manufacturers name
DI.VndID.Mdl vstr32 The model name/number
DI.VndID.SerNum vstr32 The unique serial number
DI.VndID.HwRev vstr8 The hardware version
DI.VndID.SwRev vstr8 The software version
DI.VndID.CommRev vstr8 The communications version
DI.CommID struct Present to show this is gateway
DI.CommID.CommAdd vstr16 Comm address on gateway side
DI.CommID.CommRev vstr8 The revision of the transport
DI.CommID.Prot enum8 Protocol used on gateway side
DI.CommID.Medium enum8 Medium used on gateway side
5.3.6 DeviceModels
A DeviceModel is a virtual representation of a function of a real underlying physical device. A LogicalDe-

vice may have one or more DeviceModels to represent the situation where one device presents more than
one function.
A DeviceModel contains sufficient detail to allow it to be recognized by its structure. That is, an RTU model
should have enough detail so that a knowledgeable person would recognize the set of definitions as an RTU.
DeviceModels represent one or more interconnected pieces of equipment (or internals of equipment) that

IEEE-SA
serve a single functional purpose. That is, for each major grouping of functionality, a new DeviceModel is
defined. The device model itself would contain all relevant information about it and the functionality it
represents. Internal to the DeviceModel are functional components that make up the representation of this
function.
5.3.6.1 DeviceModel Naming Conventions
Each standardized DeviceModel has a unique name. This name becomes the name of the top level
DataObject in the DeviceModel. The contents of this DataObject are the FunctionalComponents that make
up the model of device functionality. These names are unambiguously defined by those maintaining these
modeling agreements. However, new names can be invented by manufacturers as the need arises.
DeviceModel names should be relatively short, three to six characters, since they become the base name of
an aggregated hierarchy of DataObjects and will appear as part of the references to all individual compo-
nents of that hierarchy.
Some examples of DeviceModel names are LTCC (load tap changer controller), SWITCH (automated
utility switch), RTU (remote terminal unit), and EMETER (electric meter).
5.3.7 FunctionalComponents
DataObjects that are used to represent functionality within a DeviceModel fall into several common
categories:
Identity and description, measurement, control, status, configuration, control, access, setpoint,
reporting, logging
It is convenient to recognize this natural organization of information content so that browsers of CASM
DeviceModels can easily recognize information for use. The following DataObject captures this Functional
Component organization, as shown in Table 3.
Table 3: FunctionalComponents
Represents functionality grouping

FunctionalComponent DataType
inside a DeviceModel
AX STRUCT Access controls Overrides, etc.
AS STRUCT Associations (references)
CF STRUCT Configuration parameters
CO STRUCT Controls and control outputs
DC STRUCT Functional Description
EV STRUCT ECBs
LG STRUCT Log control blocks
MX STRUCT Measurements
RP STRUCT Report control blocks
SP STRUCT Setpoints
ST STRUCT Status points
Note: Although suggested as a useful organization, the individual device modelers can choose alternate
forms; this would be done to trade off some modeling need against the benefits of interoperability gained
from the uniformity of representation.

IEEE-SA
DeviceModels will contain a top level DataObject that has the same name as the DeviceModel. This top
level DataObject, a structure, will contain the appropriately substructured FunctionalComponents from the
above table. For example, a simple DeviceModel consisting of several analog measurements is modeled as
containing an MX Functional Component, (which contains the measured values), a CF Functional Compo-
nent, which contains the configuration parameters for the measurements (such as deadbands, scale factors,
etc.), and a DC Functional Component containing the descriptions of the measurements.
5.3.7.1 Example use of FunctionalComponents
The DataObjects for analog inputs, analog outputs, analog setpoints, and computed analog status values are
related. Interoperability and simple client requirements state that a common representation of such informa-
tion be achieved. Using FunctionalComponents, matched sets of DataObjects that separate the static infor-
mation from the dynamic information are defined to represent the set of relevant information to model a
piece of analog information. These related components are sorted into FCs and keyed by a common name.
Therefore, for each analog value, an appropriate set of the following DataObjects are defined (they, in turn,
would be aggregated under the DeviceModel being definede.g., LTCC). In the following example, infor-
mation about a voltage measurements connected to an LTCC in an electrical system is modeled:
LTCC.MX.V Contains the actual dynamic value(s) of measurements both externally sampled, and
internally computed such as integer value, time stamp, quality, etc.
LTCC.CF.V Contains the configuration information such as scale, offset, and units
LTCC.DC.V Contains additional descriptive information such as measurement type, reference, etc.
LTCC.SP.V Contains setpoints for fault detection, etc.
5.4 DataSets
A DataSet is a named list of ordered references to one or more DataObjects, and is provided to allow the cli-
ent to access a selected group of DataObjects by a single named reference. DataSets may be predefined by
the server, or may be defined through requests by the client.
The grouping of DataObjects into one or more DataSets is not constrained by the type description of the
DataObject. Any DataObject may have membership in one or more DataSets. A DataSet may refer to the
same DataObject one or more times.
DataSets may be nonshared in scope (defined as private to each association, and deleted when the associa-
tion is terminated), server scope (not contained within a DeviceModel), or local scope (contained within a
DeviceModel). The methods of handling DataSets and their linkages to DataObjects is a local implementa-
tion issue for the server.
Note that since DataObjects can contain references to other DataObjects to form a hierarchy, the model of a
DataSet appears similar to the model of a DataObject. The principal difference is that DataSets are a nonhi-
erarchical list of references to existing DataObjects. While DataObjects can contain DataObjects, DataSets
cannot contain DataSets.
5.4.1 DataSet Object Model

This section describes the formal object model for DataSet:
Model: DataSet
Key attribute: DataSet Reference

IEEE-SA
Attribute: Scope
Attribute: Access control
Attribute: ListOfDOReference
DataSetReference Identifier that unambiguously defines the DataSet within the scope of the server.
Scope Attribute that defines the availability of the DataSet across multiple associations and
internal/external to a DeviceModel. Instances of DataSets must be unambiguously
identified within the scope of the server. DataSets can have local, server, or nonshared
scope.
AccessControl Attribute that defines the network visibility and access privileges of the DataSet to call-
ing clients. The representation is a local matter.
Deletable Attribute that defines if the DataSet may be deleted through the use of available server
services. If the attribute has a value of TRUE, then the DataSet may be deleted from
the server through the use of the Delete DataSet service.
ListOfDOReference An ordered list of the DOReferences of the DataSet.
The Data Access services defined for DataSets are:
a) GetDataSetElementNames: This is a service in which the client requests a list of all the data identifi-
ers referenced by the specified DataSet.
b) GetDataSetValues: This is a service in which the client requests the values of the DataObjects refer-
enced by a specific DataSet.
c) CreateDataSet, in which the client requests the server to create a DataSet and specifies the
DataObjects to be referenced by the DataSet.
d) DeleteDataSet, in which the client requests the server to delete a specific DataSet. The service shall
return a result indicating FAILURE if the service is applied to a DataSet that has a deletable attribute
with a value of FALSE.
6. Server Model
This section defines the model of a generalized CASM server. This model includes the set of attributes and
services that are required to implement the CASM. Note that a conformant CASM server implementation
need only implement the standardized services and models that are called for in the UCA object model for
that class of device. The mapping of the server model to the UCA application layer protocol is defined in
Section 4.
Figure 4 shows the overall model of a UCA Server.
The server attributes are the following:
Model: Server
Attribute: Application layer model version

Attribute: DataObject model
Attribute: Association model
Attribute: Data Access model

IEEE-SA
Server Model
Data Set Device Control
Model Model
Association Multicast
Model Model Data
Object
Data Access Time Model
Model Model
Reporting Blob
Model Model
Figure 4: Server Model
Attribute: Reporting service model (optional)

Attribute: Device control service model (optional)
Attribute: Multicast service model (optional)
Attribute: Time model
Attribute: List of capabilities
Attribute: List of LogicalDevices
Attribute: List of DataObjects
Attribute: List of DataSets
Attribute: List of logs
Attribute: List of client associations
Application layer
model version This attribute identifies the specific document version number of this application
layer model implemented by the server.
DataObject model This attribute identifies the existence and availability of the set of server
DataObjects, including their organization into FunctionalComponents and
DeviceModels. See 5.3.
Association model This attribute defines the existence of the association model specific to the UCA
application services. See 6.1.
Data access model This attribute defines the existence of the data access model specific to the UCA
application services. See Section 5 for details.
Reporting service
model (optional) This attribute defines the existence of the reporting model specific to the UCA
application services. See 6.2 for details.
Device control service

model (optional) This attribute defines the existence of the device control model specific to the
UCA application services. See 6.3 for details.

IEEE-SA
Multicast service model This attribute defines the existence of the multicasts service model specific to the
UCA application services. See 6.4 for details.
Time model The time model provides the local timing elements required for use within the
reporting model and device control model.
List of capabilities This attribute identifies the different capabilities or constraints that the server
supports for the associated clients.
List of LogicalDevices This attribute identifies the LogicalDevices available at the server, as well as the
organization of the DataObjects used to represent the LogicalDevices.
List of DataObjects This attribute identifies the DataObjects that are made available by the server for
use with the supported services. See 5.3 for details.
List of DataSets This attribute identifies the DataSets that are made available by the server for use
with the supported services. See 5.4 for details.
List of logs This attribute identifies the logs that are made available by the server for use with
the reporting services. See 6.2.4 for details.
List of client associations This attribute identifies the clients with which the server is associated.
All application services are defined within the models included in the server model.
6.1 Association Model

A client initiates one or more associations with a server in order to make use of the server capabilities. Each
association is abstractly represented by the following model:
Model: Association
Key attribute: Association identifier

Constraint: Calling application identifier
Constraint: Called application identifier
Attribute: Capabilities supported
Attribute: Security methods and parameters supported
Constraint: Security mechanism name
Constraint: Security authentication value
Note: Security has been included as part of the association model since security is applied on a per associa-
tion basis and its application begins during the association establishment.
Association identifier Identifier that uniquely defines the association between the client, which is estab-
lishing the association (calling) and the server, which is responding to the associ-
ation request (called). The association identifier is a representation of the pair of
calling application identifier and the called application identifier.

IEEE-SA
Calling application
identifier Identifier that identifies which client has initiated the association. The representa-
tion of this identifier is a local issue.
Called application
identifier Identifier that identifies which server has responded to the association request.
The representation of this identifier is a local issue.
CapabilitesSupported List that identifies the capabilities provided by the server to the client. The list of
capabilities may vary between associations. This section defines standard named
capability parameters that are determined by the responding server.
a) C_DATA_OBJECT_ACC_RESTRICTED: This parameter, when included, indicates that the server

offers restricted access to components of complex DataObject and DeviceModels.
b) C_NEST: This parameter, when included, indicates that the servers capability to access data within
complex DataObject structures is limited to a Nesting Level that is the value of the parameter.
c) C_NO_DIRECT_CONTROL: This parameter, when included, indicates that the capability to per-
form direct device control is not available. For further details, refer to 6.3.1.
d) C_NO_SBO_CONTROL: This parameter, when included, indicates that the capability to perform
SBO control is not available. For further details, refer to 6.3.2.
e) C_TAGGING: This parameter, when included, indicates that the capability of device tagging is
available. For further details refer to 6.3.4.
f) C_BLOB: This parameter, when included, indicates that the capability of BlobData transfer is avail-
able.
Other capabilities may be added. The notation for the parameters shall be:
C_: for any capabilities that are defined within this document.
P_: for any capabilities that are defined within the UCA profiles documentation.
M_: for any capabilities that are defined as part of the MMS mapping.
D_: for any capabilities that are defined as part of standardized device models.
Nonstandardized capability parameters shall not have a _ in the second character location of the parameter
name.
Authentication value Identifier that is used to verify authorization of the client to create an association.
The default shall be the null password.
Security methods and

parameters supported Further details on the security mode may be found in 6.1.1.
Security mechanism
name Further details may be found in 6.1.1.2.1.
Security
authentication value Further details may be found in 6.1.1.2.1.
The association services are:
a) Initiate Association: This service establishes an application association between the client and the
server.
b) Conclude Association: This service concludes an association in an orderly manner.

IEEE-SA
c) Abort Association: This service aborts an association.

d) Get Capability List: This service allows a client to retrieve that list of server capabilities that are
available for use on the established association.
6.1.1 Security Model
There is a specific list of security threats that this section is intended to counter. These are:
a) Authorization violationAn authorized peer attempts to perform actions/functions for which the
peer is not authorized.
The appropriate security mechanism to counter this threat is the use of peer authentication coupled
with application level access-control.
b) EavesdroppingThe communication packets are being monitored by a system intruder.
This threat impacts the confidentiality of sensitive information. The appropriate security mechanism
to counter this threat is the encryption of sensitive information.
c) Information leakageDisclosure of information to an unauthorized entity.
This threat impacts the confidentiality of sensitive information. However, the security outlined in
this document does not counter the use of network traffic as a means of conveying information. The
threat may needs to be countered with security services at both the client and server.
The appropriate server security mechanism to counter this threat is the use of peer authentication
coupled with application level access-control.
d) Intercept/alterThe communication packets are intercepted by an intruder. The information in the
packets is then modified and forwarded to the original destination application.
This threat poses data integrity issues. The appropriate security mechanism to counter this threat is
encryption.
e) MasqueradeThis threat is typically referred to as spoofing. An intruder attempts to gain system
access by attempting to pretend to be a different entity.
This threat poses a severe control and data confidentiality risk. The appropriate security mechanism
to counter this threat is the use of strong-authentication.
f) ReplayA communication packet that has been obtained through eavesdropping is retransmitted
onto the network at a later time.
This threat can have severe consequences, especially if the captured packet contains control com-
mands. This threat can be countered through appropriate encryption coupled with dynamic encryp-
tion key management.
The key management mechanisms are out-of-scope for this section.
The following list represents a set of threats that this section is not intended to counter.
Bypassing controls
Denial of service
EM/RF interception
Illegitimate use
Indiscretions by personnel
Media scavenging
Physical intrusion
Resource exhaustion

IEEE-SA
Service spoofing
Theft
Traffic analysis
Trapdoor
Trojan Horse
The identified security functions that this section shall specify are stated in the following sections.
6.1.1.1 Application layer security model
Client Server
Application
User
Request for
Action
Request Accessed
Requesting Remote
Application Application
Figure 5: Security Interfaces
Security concerns arise at any exposed, via communication or other, interfaces within a system. A secure
system would enforce, at a minimum, authentication at all such exposed interfaces.
Figure 5 shows a client that consists of an application user, typically a human being, which interacts with an
application that issues request on the users behalf. The interface between the user and the application repre-
sents an exposed interface through which major security breaches could occur within the system. Therefore,
it is the responsibility of the requesting application to authenticate that the user has the authority to:
a) Make use of the application.

b) Make use of application services on an individual service basis.
Although such a restriction will aid in security, the rights to issue service requests of a remote appli-
cation shall be enforced by the requested remote application.
Requesting application service restriction is optional and does not increase the robustness of the
overall security integrity of the system. However, such restrictions may be useful as a migration path
towards system security for systems where the remote applications do not support the security ser-
vices as specified in this document.
Note: The mechanism for the authentication within the client is considered out of the scope of this document
but could be implemented through the use of security certificates or encrypto cards.
Once the application user has been authenticated, it is the responsibility of the application to perform a look-
up of the application users authentication versus the security parameter values required by the remote appli-
cation which the application user is attempting to access.

IEEE-SA
Although the implementation of this look-up is not in the scope of this document, the values that shall be
returned are the authentication value and authentication mechanism.
These security parameter values shall be conveyed by the requesting application to the accessed remote
application during association establishment. The remote applications security agent authenticates the asso-
ciation establishment and determines the access privileges that are associated with the security values.
6.1.1.2 Security Agent
The security agent is responsible for the enforcement of authentication, encryption, access control, mainte-
nance of security configuration, and the maintenance of security management parameters. In general, there
is a single instance of the security agent within a server. However, there shall be no behavioral differences
between a single instance and multiple instance implementation as the agent(s) shall behave in accordance
with association specific attributes.
6.1.1.2.1 Authentication
The security agent shall authenticate the establishment of an association through a local mechanism that is
outside the scope of this document. However, once authenticated, the appropriate access privileges shall be
enforced by the agent for the association.
Authentication is performed within an implementations application layer. Security procedures are enforced
based upon three parameters supplied by the communication profiles over which the application executes:
a) Authentication mechanism: Specifies the level of security to be applied and the method by which to
validate the authentication value. See Figure 6.
Note: The level of security (e.g., none, weak, or strong) may have a significant role in the security
functions executed within the server.
Authentication Mechanism
Name of Attribute Attribute Values
Key attribute: Mechanism Type None, Password, Certificate
Constraint: Mechanism Type= Password
Attribute: Encryption Key to Use Integer
Attribute: Password OCTETSTRING
Constraint: Mechanism Type=Certificate
Attribute: TypeofCertificate X.509, PGP
Figure 6: Authentication Mechanism Model

b) Authentication value: This value represents a logical security parameter that is to be supplied to the
appropriate security functions. This value shall be constrained by the mechanism type attribute of
the authentication mechanism.
If the mechanism type has a value of none, the authentication value shall have a value of NULL.
If the mechanism type has a value of password, the password value shall be a nonencrypted OCTET-
STRING whose maximum length shall be 64 octets. Additionally, an integer value representing the

IEEE-SA
encryption key to use shall be presented. The value of zero (0) is reserved to indicate that no key was
passed and that the security agent shall use the default encryption key to decrypt the PDU.
If the mechanism type has a value of certificate, the representation of the authentication value is not
within the scope of this document. An implementation, which claims support for certificate-based
authentication, shall support X.509 certificates. Other certificate types may be supported and shall be
declared in the implementations PICS.
Implementations claiming conformance to this section shall support the values associated with
mechanisms types of NONE and PASSWORD as a minimum.
c) Requester address: This value represent the originating address of the request that is being presented
to the application. The definition of this value is determined by the communications profile over
which the request is delivered.
Note: For profiles that use ACSE, the requester address shall be the calling AP-Title.
The representation of the requester address is a local issue but shall be a VISIBLESTRING and shall
have a maximum size of 128 octets.
Note: In the case of unconfirmed requests, a client may be receiving requests from a server. In this particular
case, the clients security agent shall be responsible for authentication. Additionally, the form and format of
the mechanism name and authentication values, for UCA communication profiles, may be found in the
amended Utility Communication Architecture, Volume 4.
A security agent uses the authentication method, authentication value, and TypeofRequest to perform its
authentication evaluation and to determine the procedures for security violations.
The TypeofRequest parameter value is a local issue but shall be capable of conveying the following values:
1) DYNAMIC ASSOCIATION: This value shall be used to indicate that an association is being
established that shall exist for a single application service. Typically, this value would be used
to indicate multicast or broadcast services.
2) ASSOCIATION REQUIRING CONFIRMATION: This value shall be used to indicate that an
association is being established that shall exist for a period of time which spans multiple com-
munication service transactions.
The security agent causes the following actions to occur based upon the aforementioned parameters:
a) If the local function determines that the authentication method and authentication value allow the
remote to establish or switch an association, the processing of the association establishment and sub-
sequent requests shall be processed as normal.
b) If the security agent determines that the authentication method and authentication value do not allow
the remote to establish or switch an association, the following actions shall be performed:
1) If the TypeofRequest=ASSOCIATION REQUIRING CONFIRMATION, the association shall
be refused with no reason or a reason of OTHER being given. This refusal shall cause the asso-
ciated communication profile to release any connections and network resources.
2) If the TypeofRequest=DYNAMIC ASSOCIATION, the request and associated data shall be
discarded with no error returned to the remote.
c) In the case where the application does not support security and an authentication method and/or
authentication value is presented, the application shall do the following:
1) If the TypeofRequest=ASSOCIATION REQUIRING CONFIRMATION, the association shall
be refused with no reason or a reason of OTHER being given. This refusal shall cause the asso-
ciated communication profile to release any connections and network resources.
2) If the TypeofRequest=DYNAMIC ASSOCIATION, the request and associated data shall be
discarded with no error returned to the remote.

IEEE-SA
In the cases where the security agent determines that authentication has failed, the parameter
APP_FAILED_AUTH shall be incremented. Additionally, the APP_FAILED_AUTH_ ADDRESS shall be
changed to reflect the requesters address for which the authentication failed.
6.1.1.2.2 Encryption
The implementation of encryption is considered to be a presentation layer function, and its implementation
is outside the scope of this section.
However, the security agent is responsible for determining and setting the encryption parameters needed by
the local presentation layer. These parameters shall be set during association establishment.
The appropriate encryption parameters shall be determined based upon the authentication method and
authentication value parameter values supplied during association establishment or association switch events.
The management of the encryption parameters is a local issue and out-of-scope for this document.
6.1.1.2.3 Access Control
The purpose of access control is to allow the capability to restrict an authorized user to a predetermined set
of services, objects, and object attributes.
In general, this document deals with the following privileges:
a) CREATE: This privilege, if granted, allows the authenticated user to create certain classes of appli-
cation objects. This privilege shall be granted on an individual class of object basis (e.g., DataObject
or DataSet) and the implementation of this access control is a local server issue.
If the CREATE privilege is not granted for a given object class, the server shall return an appropriate
error if the authenticated user attempts to create an object of that class.
b) DELETE: This privilege, if granted, allows the authenticated user to delete application objects. This
privilege shall be granted on an individual application object basis and the implementation of this
access control is a local server issue.
If the DELETE privilege is not granted for a given object, the server shall return an appropriate error
if the authenticated user attempts to delete the object.
c) VIEW: This privilege, if granted, allows the authenticated user to be informed of an object or object
attribute existence during a self-description process. If the VIEW privilege is granted, the authenti-
cated user shall be able to acquire the definition of the attributes of the object. This privilege shall be
granted on an individual object and object attribute basis.
If the VIEW privilege is not granted for a given object, the server shall not allow information of the
existence of that object to be returned during the self-description process. If the privilege is not
granted for an object attribute, information concerning that attribute shall not be returned during the
self-discovery process.
The denial of VIEW privilege also implies that the SET and GET privileges are also denied.
d) SET: This privilege, if granted, allows the authenticated user to set attribute values of an object. This
privilege may be granted on an individual object or object attribute basis.
If the SET privilege is not granted for a given object or object attribute, the server shall return an
appropriate error if the authenticated user attempts to set the object or object attribute.
e) GET: This privilege, if granted, allows the authenticated user to get attribute values of an object.
This privilege may be granted on an individual object or object attribute basis.
If the GET privilege is not granted for a given object or object attribute, the server shall return an
appropriate error if the authenticated user attempts to get the object or object attribute.

IEEE-SA
f) EXECUTE: This privilege is granted on a application service basis. This privilege, if granted, allows
the authenticated user to execute the permitted application service.
If the EXECUTE privilege is not granted, an application Service Error shall be returned or the appli-
cation service may be rejected.
Note: A user may be authenticated to EXECUTE the Get DataObject Values application service but
not be authorized to EXECUTE the Delete DataObject application service.
Table 4 shows the basis for determining each defined privilege. The application service basis privilege deter-
mination is a local issue of the security agent. The availability of a service to be used is validated for each
service request. If the EXECUTE privilege is not available for the service over the authenticated association,
an error of SERVICE_NOT_SUPPORTED shall be returned. This determination shall be performed on a
single authenticated user basis. The default value of the CREATE privilege for an application service shall
be ALLOWED unless the security agent has been configured otherwise.
Table 4: Authentication Privilege Checks
Granted on
Privilege Application Object Class Individual Individual Object
Service Basis Basis Object Basis Attribute Basis
CREATE x
DELETE x
VIEW x x
SET x x
GET x x
EXECUTE x x x
The restriction of privilege, on a per object class basis, allows the security agent to be configured to allow an
authenticated user to CREATE objects of a particular class (e.g., DataObject, report control block, ECB,
DataSet,....). If a authenticated user attempts to create a class of object for which the security agent deter-
mines that the CREATE privilege is not granted, the SERVICE_NOT_SUPPORTED error shall be returned.
If the creation service is successful, the authenticated user shall be granted the privilege to DELETE the cre-
ated object. The security agent may, through local means, determine that other users may also be granted the
DELETE privilege for the created object. The default value for the CREATE privilege shall be ALLOWED
unless the security agent has been configured otherwise.
The restriction of privilege on a per object basis allows the security agent to be configured to allow an
authenticated user to DELETE, VIEW, SET, GET, and EXECUTE based upon an object that has been unam-
biguously defined within the scope of the application (e.g., server). The default privileges for an authenti-
cated user shall be:
1) DELETE shall default to NOT_ALLOWED

2) VIEW shall default to ALLOWED
3) SET shall default to NOT_ALLOWED
4) GET shall default to ALLOWED
5) EXECUTE shall default to ALLOWED
The SECURITY control model consists of SECURITY control objects that may be associated with
DataObjects and local security operations, which represent a localized check for appropriate privilege levels.
The security control object is used by the security agent to denote where security privileges need to be vali-
dated within a DataObject hierarchy. The default privileges that shall be granted are: VIEW, GET, and EXE-
CUTE (e.g., enrolling for event notification).

IEEE-SA
For any privilege violation, the security agent shall increment the APP_FAILED_ACC_CONTROL
DataObject and shall set the APP_ACC_CONTROL_FAILED_ ADDRESS to the requester address.
6.1.1.2.4 Security Objects Required by Model
Any implementation claiming conformance to the security service model shall implement and support the
following objects:
APP_FAILED_AUTHThis is an Unsigned Integer32 value that shall be incremented when an association

fails authentication. This value is incremented locally by the security agent and is not allowed to be cleared,
set, or reset by any entity other than the security agent. The value shall be reset to a value of zero upon being
incremented beyond the maximum value.
APP_FAILED_AUTH_ADDRESSThis is a VisibleString that is set by the security agent with the

requester address of a requester for whom an association was not accepted due to authentication failure. This
DataObject shall be set by the security agent only.
APP_FAILED_ACC_CONTROLThis is an Unsigned Integer32 value that shall be incremented when

access is not granted due to privilege failure detected by the security agent. This value is incremented locally
by the security agent and is not allowed to be cleared, set, or reset by any entity other than the security agent.
The value shall be reset to a value of zero upon being incremented beyond the maximum value.
APP_ACC_CONTROL_FAILED_ADDRESSThis is a VisibleString that is set by the security agent with

the requester address of a requester for whom a requested privilege was not granted by the security agent.
This DataObject shall be set by the security agent only.
APP_SECURITY_SERVERITYThis is an INTEGER value that is used to indicate the severity of the

security violation that has been detected by the security agent. The usage of the definitions shall be defined
as part of the concrete object definition and mapping. The acceptable values are:
INDETERMINATE: Severity cannot be determined from the information available to the security
agent.
CRITICAL: Severity is critical in terms of safe operation, or data considered critical and privileged
was attempted to be accessed.
MAJOR: Severity is major in terms of safe operation, or data considered of major importance and
privileged was attempted to be accessed.
MINOR: Severity is minor in the sense that access control was denied to data considered privi-
leged.
WARNING: Is less severe that MINOR.
SECURE_ECBThis is a standardized ECB that shall be supported by the implementation. None of the
attributes of this ECB can be set and the values are locally defined. The ECB is permanently enabled and
shall cause the generation of a notification if any of the aforementioned DataObjects values change. The val-
ues reported shall be the values of the aforementioned DataObjects for which the values have changed. This
ECB shall be unambiguously identified within the scope of the server.
Note: These DataObjects and ECB in conjunction with the report model will allow security violations to be
reported and/or logged.
6.1.1.2.5 Severity
The security agent shall not assign severity codes based upon the class of security violations that have been
attempted. The assignment of such codes is the responsibility of the application that is receiving the security
violation reports or the object models.

IEEE-SA
If the Security Agent can determine the severity, based upon apriori object modeling or agreements, the
agent shall set the APP_SECURITY_SERVERITY object to the appropriate value. Otherwise, the usage of
the defined set of values for APP_SECURITY_SERVERITY object is a local issue. The default value shall
be INDETERMINATE.
6.2 Reporting Service Model
6.2.1 Overview
The UCA reporting service consists of three major abstract models that provide the tools for creating many
reporting schemes:
Event modelDetails the abstract methods/algorithms used to define, detect, and deliver notifica-
tion of events based on the states and values of data objects.
Report generation modelDetails the abstract methods required to generate event triggered reports
in an unsolicited manner to one or more clients.
Logging modelDetails the abstract methods required to perform local buffering of event trig-
gered information. Buffered information may be reported later (via the report generation model),
interrogated, and/or retrieved by a client.
Each of the three abstract models is defined in terms of:
One agent, which represents that portion of the DeviceModel that executes services at the request
of any client.
One or more control blocks, which are specialized DataObjects that may be read and/or written by
any client and which contain configuration information to control processing by the agent.
Methods that may be invoked relevant to the model.
The relationships of the various agents and methods are shown in Figure 7. The arrows depict the flow of
service requests. Note that most requests may also include responses and/or events flowing in the opposite
direction. Each of the three agent object models (event, report, and log) will be discussed throughout this
section, along with the associated methods and data models.
Note that the client can control the behavior of each of the agents by writing the associated control blocks.
The control blocks define both the internal parameters of the agents and the enrollment relationships
between them.
The Event Agent handles the detection of data changes and interval timeouts based on the ECB parameters
written by the client. The Report Agent and/or the Log Agent may enroll with the Event Agent to receive
notification of events. Upon receiving notification of an event, the Report Agent may (based on the report
control block parameters previously written by the client) formulate a report message for transmission to the
client. Likewise, upon receiving notification of an event, the Log Agent may (based on the log control block
parameters previously written by the client) store the data contained in the event notification in a buffer for
later query by the client.
The three models work together to allow for flexible configuration of event driven data acquisition, buffer-
ing, and reporting. For example, events may be defined and configured to occur when specific criteria are
met by data object values. The occurrences of these events can be used to trigger the sending of reports and/
or to trigger the logging of information. Logged information may be either read by the client at a later time,
or buffered for later reporting to the client.

IEEE-SA
Event
Agent
Set Control
Block
Enroll Notify
Set Control
Block Report
Client Enroll Notify
Agent
Report
Set Control
Block
Query
Log
Agent
Figure 7: Reporting model relationships
These generic agent models define capabilities that go beyond the requirements of any specific device. It is
presumed that standardized device models that are developed using these models will define specializations
which will limit the complexity of implementation to that appropriate to the device class. For simple devices,
the reporting services may be defined to always send some fixed data elements based on a single predefined
event condition. Most of the ECB and report control block parameters are fixed within such a device model
definition. In this case, the device model may define a specialized mapping of the client-accessible parame-
ters of an ECB and a report control block into components of a single, simplified data structure. An example
of such a specialized mapping is the TASE.2 (ICCP) transfer set model, which logically represents a subset
of the attributes of a combined ECB and report control block. Likewise, a device model can define a special-
ized mapping of an ECB and a log control block for a simplified log model. In both cases, the device model
must specify the exact format of the combined control block DataObject, as well as the predefined values for
all report control block (or log control block) and ECB components which are not used.
6.2.2 Event Model
The event model specifies the following capabilities:
a) The ability to raise conditions based on criteria established through the ECB
b) The ability to notify agents enrolled in ECBs when the criteria is met
Figure 8 shows a generic representation of the event model.
The event model provides services to control the definition and execution of components within the model.
The two major functions of the event model are:
Event detection processingDetection of local event conditions, either by the application of

criteria from the ECB to DataObject value changes, or by other local means.
Event notification processingSending of notification to agents that have enrolled in an event
condition.

IEEE-SA
Data
Objects
Event
Control Block
Event
Enrollments
Set Control Block Event Notify
(Client) (Log Agent)
Event Agent
Enroll
(Log Agent)
Enroll Event Notify

(Report Agent) (Report Agent)
Figure 8: Event agent
The following object models are used in the performance of these functions.
6.2.2.1 Event Control Block Object
An event control block is a specialization of a DataObject, available for reading and writing by the client. It
provides a mechanism for controlling the generation of event notifications by the Event Agent. The scope of
the event control block (local, server, or nonshared) is defined by the specific device model. Its attributes are
as follows:
Attribute DataType Range

ECB Name IDENT Event control block name
ECB.EvtEna BOOL Event enable
ECB.InDat IDENT Input data name
ECB.OutDat IDENT Output data name
ECB.EvaFct VSTR32 Evaluation function
ECB.EvaCri IDENT Criteria object
ECB.EvaPar IDENT Parameter object
ECB.EvaCns IDENT Constraints object
Event control block name: This is an identifier of the event control block object that unambiguously identifies
it within the scope of the server.
Event enable: If TRUE, the event will be generated whenever any term of the evaluation function evaluates
to INCLUDE, otherwise no event will be generated.
Input data name: An identifier of either a DataObject or a DataSet that will trigger the event. The evaluation
function will be applied to the values of the DataObject(s) specified.

IEEE-SA
Output data name: An identifier of either a DataObject or a DataSet that will be included in the notification
of the occurrence of the event.
Evaluation function: A set of DataObjects may be bound to an evaluation function by an ECB. An evaluation
function is an algorithm implemented by the server for establishing the reporting criteria for a DataObject or
DataSet. Each evaluation function consists of a set of sub-functions that can be independently enabled or
disabled by the client through the use of the evaluation function constraints.
Example 1: An example of an evaluation function is a deadbanding algorithm that includes a set of

subfunctions, namely, high limit, low limit, percent change rising, and percent change falling. This
deadband function can be applied to a set of analog values (input data). The client can enable or dis-
able each subfunction of the deadbanding algorithm for particular measurements in the set using the
constraints object. In addition, the client can also provide the specific limits to use in the deadband-
ing process (e.g., high limit of 100, low limit of 50, 5% change rising, 10% change falling) for each
point through the use of the criteria object. Global parameters to the evaluation function can be spec-
ified using the parameter object.
Example 2: An alternative example evaluation function is a timer algorithm that generates events at
specific intervals, either based in fixed periods of an absolute clock or on offsets from the start of the
hour. The input data may be a specific clock (or may be NULL), and the intervals specified using the
evaluation criteria. All other features are unused.
Example 3: A third example evaluation function could be specific to a breaker device model. When
the breaker trips (input data), a specific set of analog and status values (based on the evaluation func-
tion being used) are to be included in the event notification for later reporting to the client.
The specific approach to performing function evaluation (e.g., sampling vs. event driven, etc.) depends on
the specification of the evaluation function and is outside the scope of the generic model. Each evaluation
function, when applied to the current values of the input data, constraints, criteria, and parameter, determines
if event notifications are to be delivered to enrolled agents, and determines the contents of the event notifica-
tion object, including specific data values, if any.
Each event evaluation function may have unique requirements for the number and type of its input parame-
ters. The validity and consistency of the ECB attributes shall be checked by the server when the ECB is writ-
ten by the client. If the validation fails, the ECB is not modified, and a negative acknowledgment is returned
to the client.
Criteria object: This attribute is an identifier of an object whose type is determined by the definition of the
evaluation function (e.g., DataObject or DataSet). Each element of the criteria object specifies parameters of
the evaluation function to be used with the corresponding member of the input data (or to all members, if a
single evaluation criteria is used). The default values for the criteria object are dependent on the evaluation
function.
Parameters object: This attribute is an identifier of an object whose type is determined by the definition of
the evaluation function (e.g., DataObject or DataSet). It is used to specify parameters of the evaluation func-
tion to be used with all members of the input data. The default value for the parameters object is dependent
on the evaluation function.
Constraints object: This attribute is an identifier of an object whose class is determined by the requirements
of the evaluation function (e.g., DataObject or DataSet). Each element of the constraints object specifies
which, if any, sub-functions within the evaluation function shall be applied to the corresponding member (or
to all members, if a single constraint is used) of the input data. If no constraints are specified, then all sub-
functions are to be applied.

IEEE-SA
6.2.2.2 Event Notification Data
The event notification object model represents the output of the evaluation function that is delivered to all
agents enrolled in the ECB. The abstract method EventNotification is used to represent the communication
of this object to enrolled agents. Note that this transient object is not mapped in the underlying protocol; it
simply represents the communication between agents within the server. The actual mechanism used to
implement this communication is a local matter within the server.

ECB Name IDENT ECB name
EventInfo Eveinfo Sequence of event information
ECB Name: Identifier of the ECB that was used to trigger the Event Notification.
Sequence of Event Information: This represents the list of qualified values of DataObjects from the Output
Data list that the Evaluation Function determined should be included in the Event Notification. The contents
of the Event Information objects are:

Identifier IDENT DataObject identifier
Value (varies) DataObject value
ReasonForInclusion (varies) Reason for inclusion
DataObject identifier: This identifier unambiguously identifies the DataObject whose value is included in the
notification.
DataObject value: This attribute holds one or more values to be conveyed to enrolled agents through event
notifications. The data types depend on the type of the object being conveyed.
Reason for inclusion: This attribute details the reason that the DataObject has been included in the notifica-
tion. The values are determined by the evaluation function.
Example: Evaluation functions may be defined that incorporate a number of different types of data
monitoring as sub-functions, in which case the DataObject may be included for multiple reasons.
Some common examples of reasons for inclusion are:
a) PERIODICThis value indicates that an evaluation function subfunction included the DataObject
due to a sampling interval expiring. The interval may have been locally determined or specified as
part of either the criteria object or the parameter object.
b) INTEGRITYThis value indicates that an evaluation function subfunction included the DataObject
due to some alternate interval expiring.
c) CHANGEThis value shall indicate that a evaluation function subfunction included the DataObject
due to data value changes or deadband limits being detected. The basis of the comparison may be
based upon criteria as defined by the evaluation function. Alternately, specific reasons may be
defined for HI_LIMIT, LOW_LIMIT, PERCENT_CHANGE.
6.2.2.3 Event Model Services
Two classes of event model services are defined for the Event Agent: client services and internal methods.

IEEE-SA
6.2.2.3.1 Event Model Client Services
The following is a set of external application services that may be applied to the objects maintained by the
Event Agent:
a) Get event control block: Return the event control block attributes to the client (GetData Object
Values).
b) Set event control block: The Event Agent must validate all parameters, and return an appropriate
response. If the control block is enabled, the Event Agent must further initiate local procedures to
continuously perform the evaluation function and notification procedures as appropriate to the
device model (SetData Object Values).
c) Create event control block: Requests the Event Agent to create a new event control block (special-
ization of CreateDataObject).
d) Delete event control block: Requests the Event Agent to delete an existing event control block (spe-
cialization of DeleteDataObject)
e) Get event control block names: Returns the names of the event control blocks defined in the Event
Agent (specialization of GetDataObjectNames).
6.2.2.3.2 Event Model Internal Methods
The following event methods may be invoked internally by the report model agents (event, report, or Log
Agents):
a) EventNotification: This method is performed by the Event Agent whenever the criteria of an ECB
has been met for which there are agents enrolled. The event notification DataObject is delivered to
all enrolled agents.
b) EnrollforNotification: This service that allows an agent to request that event notifications and the
associated parameters be conveyed when the conditions specified in an ECB are met.
c) DisEnrollforNotification: This service allows an agent to request that event notifications and the
associated parameters are no longer to be conveyed when the conditions specified in an ECB are
met.
6.2.3 Report Agent Model
The Report Agent model specifies the following capabilities for controlling various aspects of the reporting
process:
a) The set of ECBs that cause reports to be generated

b) The ability to aggregate data from multiple ECBs, under control of the client
c) The ability for a client to control the report format
A client controls the Report Agent model via appropriate setting of the report control block attributes. When
the client sets the report control block, the server enrolls in the requested ECBs. The Report Agent then
aggregates the information from event notifications into reports, formats the reports, and sends the reports to
the appropriate client(s).
Figure 9 shows a generic representation of the report model.
6.2.3.1 Report Control Block
The report control block is a specialization of a DataObject, available for reading and writing by the client.
The persistence of the report control block may be either temporary or permanent.

IEEE-SA
Enroll Notify
(Event Agent) (Event Agent
Set Control Block

(Client)
RCBs
Report
(Client)
Report Agent
Figure 9: Report Agent

RCB Name IDENT Report control block name
RCB.RptEna BOOL Report enable
RCB.RptID VSTR32 Report identifier
RCB.OptFlds BSTR8 Optional fields to include
RCB.BufTim INT32U Buffer time
RCB.Trgs INT16U Num of triggers before send
RCB.SeqNum INT8U Sequence number
RCB.Enroll IDENT ECB name to enroll
RCB.CriRpt BOOL Critical report
RCB.DestAE VSTR32 Destination AE
RCB.EncOpt BSTR8 Encoding options
Report control block name: This is the identifier of the report control block that unambiguously identifies the
report control block within the scope of the server.
Report enable: If set to TRUE, the Report Agent shall enroll in the ECB referenced in the enroll attribute and
shall be capable of receiving the associated EventNotifications and generating the reports as specified in the
report control block. If set to FALSE, the Report Agent shall disenroll in any ECBs previously enrolled for
this report control block and shall stop issuing reports. If DestAE (see below) is NULL, the report enable
attribute shall be set to FALSE upon termination of the association (for any reason) between the client and
server.
Report identifier: This identifier is to be included in reports generated for this report control block. The
report identifier field may be used by clients to distinguish between reports from various report control
blocks. If the report identifier is set to NULL, the name of the report control block is used. The DEFAULT
value of this attribute is NULL.
Optional fields to include: This attribute defines a subset of the optional header fields that is to be included in
the report. The field identifiers are: SEQUENCE_NUMBER, REPORT_TIME_STAMP,

IEEE-SA
REASON_FOR_INCLUSION, and OUTPUT_DATA_SET. The bit assignments for optional fields to

include are:
Bit 0: Reserved
Bit 1: SEQUENCE_NUMBER
Bit 2: REPORT_TIME_STAMP
Bit 3: REASON_FOR_INCLUSION
Bit 4: OUTPUT_DATA_SET
Buffer time: This attribute specifies the time interval for buffering of EventNotifications by the Report Agent
for inclusion into a single report. Upon receipt of the first EventNotification, the Report Agent starts a timer
of duration BufferTime. When the timer expires, the Report Agent must combine all EventNotifications that
have been received during the time interval into a single report. The next EventNotification following the
timer expiration signals the start of a new timer. The DEFAULT value of zero (0) shall be reserved to indi-
cate that the buffer time attribute is not to be used by the Report Agent, and each EventNotification shall
cause the Report Agent to send a single report (unless Num of triggers before send is specified, below). The
value shall be settable in one msec increments and shall be able to convey up to one hour of buffer time. If
both BufferTime and Num of triggers before send are specified in the report control block, then the Report
Agent shall send the reports based on whichever criteria (timer expiration or count exceeded) occurs first.
Num of triggers before send: This attribute specifies the number of EventNotifications to combine in a single
report. Upon receipt of the first EventNotification, the Report Agent shall count and store EventNotifications
until the count reaches Num of Triggers Before Send, at which time all stored EventNotifications shall be
sent in a single report. The next EventNotification restarts the counter. The DEFAULT value of zero (0) shall
be reserved to indicate that the Num of triggers before send attribute shall not be used, and each EventNoti-
fication shall cause the Report Agent to send a report (unless BufferTime is specified).
Sequence number: The Report Agent shall maintain a sequence number for each report control block that
has report enable set to TRUE. This number is to be incremented by the Report Agent for each report gener-
ated and sent based upon the report control block. The increment shall occur once the server has formatted
the report and queued the report object to the N-1 protocol layer. The first report following the setting of the
report enable to TRUE shall contain sequence number 0. The sequence number shall rollover to zero at 232.
ECB name to enroll: This is an ECB identifier for which the Report Agent is to enroll. EventNotifications for
this event condition will contain the information to be included in each report.
Critical report: This attribute indicates that the report is critical, and that a confirmation of the receipt of the
report by the client is expected. If no confirmation of the report is received, the actions to be taken by the
Report Agent are outside the scope of this document, and must be specified in the device model.
Destination AE: This attribute shall be used by a client to indicate that a client (or set of clients) other than
that which requested the SetReportControlBlock service that set the report enable to TRUE shall receive the
reports as defined by the report control block. The DEFAULT value of this attribute shall indicate that the
client that set the report enable to TRUE is the only client that shall receive reports. The value of NULL shall
be reserved to indicate this default.
Encoding options: When mapping the CASM reporting model to various application layer protocols, it may
be possible to allow various encoding schemes for reports. This attribute allows for protocol-specific map-
ping options. The values it may take on are specific to the underlying protocol. Further definition is outside
the scope of this document.

IEEE-SA
6.2.3.1.1 Report Control Block Services
The following services are associated with the report control block:
a) GetReportControlBlock: This service retrieves the attributes of the report control block (GetData
Object Values).
b) SetReportControlBlock: This service sets the attributes of the report control block. If the service
changes the report enable attribute from FALSE to TRUE, the Report Agent shall request the Even-
tEnroll service for the event referenced in the enroll attribute. If the service changes the report enable
attribute from TRUE to FALSE, the Report Agent shall request the EventDisenroll service for the
event referenced in the enroll attribute.
c) CreateReportControlBlock: This service allocates a report control block from the server to the client
requesting it (specialization of CreateDataObject).
d) DeleteReportControlBlock: This service returns a report control block to the server (specialization
of DeleteDataObject).
e) GetReportControlBlockNames: This service retrieves the list of report control block objects avail-
able for use by the client (specialization of GetDataObjectNames).
6.2.3.2 Report Generation Processing
The Report Agent makes use of the attributes of a report control block and parameters delivered via an
EventNotification method (from the Event Agent) to generate a report. Note that whenever possible multiple
DataObject values that originate in a single EventNotification should be included in the same report. Table 5
shows the attributes/parameters that are available to the Report Agent.
Table 5: Attributes/Parameters Used by Report Generation Process
Supplied by Event Notification Supplied by Report Control Block

ECB name Report control block name
SequenceofEventInformation: Optional fields to include
DataObject identifier Encoding options
DataObject values Buffer time
Reason for inclusion Num of triggers before send
Destination AE
Report identifier
Output DataSet Critical report
Sequence number
Event notifications are delivered to the Report Agent by the Event Agent. Data from the event notification
must be buffered by the Report Agent until either BufferTime or Num of triggers before send criteria is met.
At that time, the Report Agent generates a report based on the setting of the optional fields to include
attribute. The report is then sent to the client(s) specified by the destination AE within the report control
block.
Specific requirements regarding handling of error conditions (loss of communications, flow control, etc.) are
defined by the device model making use of the Report Agent model. In some small devices, events that occur
while communication is lost or flow controlled are simply discarded; in other devices, all data is buffered for
later transmission. The following principles apply to most simple device implementations:
a) The UCA reporting model shall be used over pre-established associations. These associations may
be preconfigured or created through the association services as specified within UCA.

IEEE-SA
b) A server that has been configured and enabled for reporting, but that has no association established
or has lost an association with the application to which the information is to be reported, shall take
the following actions with respect to that application:
1) The Report Agent shall not issue a report.
2) The Report Agent shall not be responsible for maintaining buffered reports of the notified val-
ues. Clients that need to recover these values, in the advent of no association, shall make use of
the UCA logging model. Clients that need to recover the current values shall make use of direct
requests, periodic reports, or integrity scans.
3) The server shall not guarantee the maintenance of RCB configuration and enable states for
RCBs of all scopes. Upon loss association, the Report Agent shall default the RCB.Ena to
FALSE.
A Report Agent that has been configured, has been enabled for reporting, and has an established association
with the application to which the information is to be reported, shall take the following actions:
a) When notified by the Event Agent of a change in value of a DataObject that is to be reported with
REASON_FOR_INCLUSION=CHANGE, the Report Agent shall include the following in the
report:
1) For status value changes: the actual value of the DataObject that caused the event notification.
2) For analogs that exceed deadbands: the value of the DataObject at the time the report is queued
for transmittal.
3) For analogs that exceed or return within limits: the value of the DataObject at the time the
report is queued for transmittal.
b) The Report Agent, within the implementation resource limits, shall deliver all Event Agent notifica-
tions with REASON_FOR_INCLUSION=CHANGE.
c) The Report Agent, within the implementation resource limits, shall deliver all Event Agent notifica-
tions with REASON_FOR_INCLUSION=CHANGE in the time sequence order in which the Report
Agent was notified.
d) In the case where a second Event Agent notification of the same DataObject has occurred prior to the
expiration of RCB.BufTim and/or the satisfying of the RCB.Trgs criteria, a Report Agent may
behave as if RCB.BufTim has expired (and/or RCB.Trgs has been satisfied) and immediately queue
the report for transmittal. (For example, a second status change will cause the immediate queuing of
the report for transmittal; a second analog change will not.)
e) If the Report Agent behaves in this manner, RCB.BufTim shall restart the timer of duration
RCB.BufTim, and RCB.Trgs shall be reset to its original value. Upon completion of this procedure
the second notification shall be processed by the Report Agent.
f) A Report Agent may generate reports that contain DataObject values that are being reported for dif-
ferent reasons (e.g., CHANGE, PERIODIC, and INTEGRITY values may be contained in a single
report). Clients that need knowledge of the reason for inclusion shall set RCB.OptFlds to include
REASON_FOR_INCLUSION.
g) If there is a pending report that includes a notification for a DataObject with
REASON_FOR_INCLUSION=PERIODIC or INTEGRITY and if another notification of that
DataObject value occurs with REASON_FOR_INCLUSION=CHANGE, a Report Agent may sub-
stitute the old DataObject notification value for the new value within that report. This substitution
may occur prior to RCB.BufTim expiring and/or RCB.Trgs being satisfied.
h) If there is a pending report that includes a notification for a DataObject with
REASON_FOR_INCLUSION=INTEGRITY and if another notification of that DataObject value
occurs with REASON_FOR_INCLUSION=PERIODIC, a Report Agent may substitute the old
DataObject notification value for the new value within that report. This substitution may occur prior
to RCB.BufTim expiring and/or RCB.Trgs being satisfied.

IEEE-SA
i) If there is a pending report that includes a notification for a DataObject with

REASON_FOR_INCLUSION=CHANGE and if another notification of that DataObject value
occurs with REASON_FOR_INCLUSION=CHANGE, a Report Agent may substitute the old
DataObject notification value for the new value within that report, but only if the Report Agent does
not respond to a second event for the same DataObject by immediately queuing the first event for
transmittal (e.g., analogs may substitute new values, but status points may not substitute valuessee
item e). This substitution may occur prior to RCB.BufTim expiring and/or RCB.Trgs being satisfied.
j) The value of RCB.CriRpt shall be FALSE.
6.2.3.2.1 Report Format
The abstract report object allows all combinations of information from the event notification(s) to be
included in the report. The specific contents of the report is:

RptId VSTR32 Report identifier
OptFlds BSTR8 Optional fields to include
SeqNum INT8U Sequence number
RptTim BTIME6 Report time stamp
OutDat IDENT Output DataSet
Inclusion BSTR Inclusion bitstring
ListOfD Varies with class List of reported data
Reasons BSTR List of reason for inclusion
Report identifier: This shall be the client specified report identifier attribute of the report control block that
has caused the Report Agent to generate the report. If the report identifier value of the report control block is
NULL, the report control block name shall be reported as the report identifier. The report identifier is manda-
tory, and must always be present in the report.
Optional fields to include: This shall be the client specified optional fields to include attribute of the report
control block that has caused the Report Agent to generate the report. The optional fields to include field is
mandatory, and must always be present in the report.
Sequence number: The sequence number of this report with respect to the report control block. It is incre-
mented by one every time the Report Agent generates a report from that report control block. The sequence
number shall be included in the report if the optional fields to Include attribute of the report control block
included SEQUENCE_NUMBER; otherwise it shall be omitted.
Report time stamp: This specifies the time at which the report was generated. The report time stamp shall be
included in the report if the optional fields to include attribute of the report control block included
REPORT_TIME_STAMP; otherwise it shall be omitted.
Output data set: The name of the DataSet being reported.
Inclusion: A bitstring containing one bit for each member of the output DataSet. A bit value of 1 signifies
that the DataObject value for the corresponding member of the output DataSet is to be included in the report.
A bit value of 0 signifies that the DataObject value for the corresponding member of the output DataSet is
not to be included in the report.
List of DataObject values: The list of values of the DataObjects that are included in this report. Note that this
is derived from the event notification object(s) that caused the report to be generated.

IEEE-SA
List of ReasonForInclusion: An ordered list (rather than a single concatenation) of ReasonForInclusion

attributes from the event notification(s) included in the report. Each member in the list represents the Rea-
sonForInclusion of the corresponding member of the list of DataObject identifiers. The list of ReasonForIn-
clusion attribute shall be included in the report if the optional fields to include attribute of the report control
block included REASON_FOR_INCLUSION; otherwise it shall be omitted.
6.2.4 Log Model

Many automation field devices have requirements for the internal storage and retrieval of historical data over
communications channels. This data falls into two general categories: Periodic recordings (commonly
referred to in metering applications as profiles) and event-triggered or sequence-of-events (SOE) data.
Several criteria can be used to differentiate historical data logging requirements from report-oriented infor-
mation transfer:
a) Data recording is independent of external application associations or other communication transac-

tions. Even if communication is lost, historical events occur and must be logged.
b) The process of storing the historical records is completely asynchronous with retrieval over commu-
nications.
c) Rate of generation of historical records can in some cases (such as high speed fault recording) be
much faster than the ability of communication processes to report the values to an external data base.
d) The sheer volume of data, number of devices, and network bandwidth constraints may preclude data
retrieval with event-oriented communication techniques and continuous application associations.
This is particularly true in load control metering applications where periodic samplings must be
made of thousands or even millions of meters.
e) Record retrieval must allow external applications to request subsets of the entire historical database
for the purpose of maintaining an external, complete time, or event-sequenced historical record.
f) The source of the data may be external to the device. Thus the historical repository may simply be a
central point of storage.
g) Records have relative significance with regard to time or ordering, and may require the assignment
of a sequence number.
The UCA log model provides a standardized method of providing the logging capability. shows the Log
Agent model inputs and outputs.
Enroll
(Event Agent)
Set Control Block

(Client)
Notify
(Event Agent)
Query
(Client)
Log
Control Block
Logged
Data
Log Agent
Figure 10: Log Agent Model

IEEE-SA
Log agents maintain databases of historical data, as well as log control blocks for managing the logging
process.
6.2.4.1 Log Object
The UCA log object is an ordered sequence of event notifications, along with the associated methods for
controlling the logging process and interrogating the logged information. The local storage mechanism,
internal formats, etc., for log objects are all local issues and outside the scope of this technical report. How-
ever, a log object does have certain attributes which are standard:

LogName IDENT Log name
LogSize INT32U Log size
Enabled BOOL Enabled
LogOperationalMode ENUM Log operational mode
ListOfEntryReferences * List of entry references
FillLevelSetting INT16U Fill level setting
Status BSTR3 Log status
EntryIdentifier INT32U Entry identifier
LastEntryDiscarded INT32U Last entry discarded
Oldest LogEntry.EntryIdentifier INT32U Oldest log entry identifier
Newest LogEntry.EntryIdentifier INT32U Newest log entry identifier
OldestLogEntry.TimeOfLog BTIME6 Oldest log entry time of log
NewestLogEntry.TimeOfLog BTIME6 Newest log entry time of log
LogControlBlock LCB Log control block
LogName: The default value, in the instance where there is a single log for a logical device, shall be the
name of the logical device in server or association scope. The default scope is server.
In the instance where there are multiple logs for a single instance of a logical device, the name of the log
shall be of the format: <scope>/<logical device name>$<logname>.
Where:
<scope> = server or association

<logical device name> = name of the logical device
<logname> = actual logical device specific logname.
The overall size of <logical device name>$<logname> shall not exceed 32 characters.
LogSize: This is the maximum number of EntryReferences that an instance of a log object can store.
Enabled: This attribute indicates if the log is actually enabled to store entries.
If enabled indicates that the log is NOT-ENABLED, then the attempted addition of an entry shall cause the
EntryIdentifier to be incremented and the LastEntryDiscarded to be updated with the new EntryIdentifier
value.
A transition of FALSE to TRUE shall cause an entry of this event to be placed into the log.

IEEE-SA
A transition of TRUE to FALSE shall cause an entry of this event to be placed into the log.
The default value for this attribute is determined by the server, but may need to be standardized by the model
builders.
Examples:
An SOE log may need to have the default of ENABLE=TRUE for an RTU.
Power quality disturbance recording may need to have the default of ENABLE=FALSE.
Note: Since the server is responsible for determining the default values, these values shall be disclosed
within any given implementations PIXIT statement.
LogOperationalMode: A log can be operated in two different modes: WRAPPING and NON-WRAPPING.
WRAPPING: Wrapping mode indicates that the log will be filled on a first-in first-out basis. The
log starts being filled as an array of EntryReferences (e.g., this is the ListOfEntryReferences) with
EntryReference[0] being the first entry reference to be used. The log will continue to use EntryRef-
erences until the number of stored entry references reaches LogSize+1.
As long as the number of EntryReferences stored in the log is equal to LogSize, the WRAPPED
status shall be indicated. While WRAPPED=TRUE, the log shall indicate the most recent
EntryReference EntryIdentifier that was overwritten by updating the LastEntryDiscarded attribute.
The value of OVERFLOW shall be FALSE when LogOperationalMode = WRAPPING. A client
shall be able to the condition through the WRAPPED status, and through the non-sequential nature
of the EntryIdentifiers returned in response to a query.
The FILL_STATUS status shall be used to indicate that a percentage of the log has been filled with
additional entries since the last FILL_STATUS was indicated. The determination of additional
shall be based upon the relationship of FillLevelSetting and the number of maximum ListOfEn-
tryReferences:
Additional = [FillLevelSetting * (Maximum ListOfEntryReferences) ] /100
Note: It is intended for the FILL_STATUS and OVERFLOW status to be reported through the use of the
Reporting model.
NON-WRAPPING: Non-wrapping mode indicates that the Log will be filled on a non-circular
basis. The log starts being filled as an array of EntryReferences (e.g. this is the ListOfEntryRefer-
ence) with EntryReference[0] being the first entry reference to be used. The log will continue to
use EntryReferences until the number of stored entry references reaches LogSize.
When the number of stored entry references fills the ListOfEntryReference, no further data can be
logged until all or part of the ListOfEntryReference is emptied. This condition shall cause the
OVERFLOW status to be indicated. New entries, which are attempted to be added to the Log when
OVERFLOW is indicated, will need to be discarded through the following procedure.
a) A LogEntry addition will cause the Log.EntryIdentifier to be incremented.
b) The Log.LastEntryDiscarded attribute will be updated with the new Log.EntryIdentifier.
c) The LogEntry addition will fail.
The OVERFLOW state in status shall remain indicated until some of the ListOfEntryReferences are
removed through the use of the EmptyLog service.
The value of the WRAPPED state in status shall be FALSE when LogOperationalMode = NON-
WRAPPING.

IEEE-SA
The FILL_STATUS state in status shall be used to indicate that a percentage of the log has been
filled with additional entries since the last FILL_STATUS was indicated. The determination of
additional shall be based upon the relationship of FillLevelSetting and the number of maximum
ListOfEntryReferences:
Additional = [FillLevelSetting * (Maximum ListOfEntryReferences) ] /100
Note: It is intended for the FILL_STATUS and OVERFLOW status to be reported through the use of
the Reporting model.
ListOfEntryReferences: This attribute shall be a list of references to LogEntry objects. Such LogEntry
objects contain the information that makes up the log.
A log object contains information relating to a single logical device only. When retrieved through the Query-
Log service, each LogEntry contains the following information:
Attribute DataType Note

This is the ObjectName of the ECB that has
ECBName VisbleString32 caused the notification
ECBState ENUM ACTIVE, IDLE, DISABLED
TimeOfLog BTIME6 Time of Entry in GMT
Consecutive record number generated by Log
EntryIdentifier INT32U Agent
Constraint ECBState=ACTIVE
This is the list of DataObjects that have been
ListOfDataObjects VisibleString notified.
This is the list of data values associated with
ListOfObjectValues Data the ListOfDataObjects.
FillLevelSetting: This attribute determines the fill percentage of the log object at which point the
FILL_STATUS status shall be indicated. This is a percentage of the number of the maximum number of
EntryReferences that can be stored within the log. The recommended default value is 25.
Status: This attribute represents several statuses about the log object.
OVERFLOW: This status indicates a resource related issue has arisen with the log object. See the
description for LogOperationalMode to determine the procedures for indicating OVERFLOW.
FILL_STATUS: This status indicates that a specified number of additional LogEntries have been
added to the log since the last FILL_STATUS was indicated. See the description of LogOperation-
alMode. The FILL_STATUS state in Status should be reset by the server upon receiving a valid
Query service request for the log.
WRAPPED: This status shall only be indicated when LogOperationalMode=WRAPPING. See
LogOperationalMode for the actual procedure for setting this status.
EntryIdentifier: This is a unique numerical reference that is incremented each time an entry is attempted to
be added to the log object. This reference is incremented regardless of the success or failure of the addition.
LastEntryDiscarded: This attribute indicates the EntryIdentifier of the last LogEntry within the LogObject to
be discarded due to an overflow condition in the LogObject. If no entries have been discarded, it shall have
the value zero (0).
OldestLogEntry.EntryIdentifier: This attribute indicates the LogEntry.EntryIdentifier that has the oldest
LogEntry.TimeOfLog which is actually found within the ListOfEntryReferences.

IEEE-SA
NewestLogEntry.EntryIdentifier: This attribute indicates the LogEntry.EntryIdentifier that has the most
recent LogEntry.TimeOfLog which is actually found within the ListOfEntryReferences.
OldestLogEntry.TimeOfLog: This attribute indicates the LogEntry.TimeOfLog that has the oldest LogEn-
try.TimeOfLog which is actually found within the ListOfEntryReferences.
NewestLogEntry.TimeOfLog: This attribute indicates the LogEntry.TimeOfLog that has the most recent
LogEntry.TimeOfLog which is actually found within the ListOfEntryReferences.
LogControlBlock (LCB): This attribute represents the single LCB that controls the operation, size, etc., of
the log object and gives the appropriately reflected status of the log object.
6.2.4.2 Log Control Block (LCB)
The log control block (LCB) is written to control the operation of the Log Agent, and also may be read by
the client to get information about the status of the log. The name of the LCB shall be the same as that
assigned to the log object. The LCB shall be of the same scope as the log object.
The log control block shall be an ECB for the Log.Status attributes. The event evaluation of this ECB is
ENABLED.
Control Block Name: This is the name of the LCB that is associated with the log to which the client desires
information to be logged.
The default control block name shall be the same as that of the LOG to which it is associated The name of
the log shall be of the format: <scope>/<logical device name>$<logname>
Where:
<scope> = server or association

<logical device name> = name of the logical device
<logname> = actual logical device specific logname.
The overall size of <logical device name>$<logname> shall not exceed 32 characters.
The specific contents are shown in Table 6.
Table 6: Log Control Block Components
Mandatory/
Component DataType Range Setable
Optional
LCB struct Log control block m
Parameters
LCB.LogEna ENABLE See Log.Enabled m y
LCB.LogNam VSTRING64 Name of the log m o
LCB.LogEnr<n> VSTRING64 Names of ECBs into which to enroll m o
LCB.FillLvl INT8U See Log.FillLevelSetting m o
LCB.LogSize INT32U See Log.LogSize m o
LCB.LogWrp BOOL Log wrap enable o y
Status

IEEE-SA
Table 6: Log Control Block Components (continued)
Mandatory/
Component DataType Range Setable
Optional
OVERFLOW,
LCB.Status BSTRING5 LOG_MODE_WRAPPING, m n
WRAPPED, ENABLED
LCB.FillST BOOL See Log.Status = FILL_WARNING m n
RECORD_ENTRY_SUPPORT,
LCB. Opt BSTRING4 TIME_ENTRY_SUPPORT, m n
DATA_OBJECT_FILTER
LCB.EntOld INT32U See Log.OldestLogEntry. m n

EntryIdentifier
See Log.NewestLogEntry.
LCB.EntNew INT32U m n
EntryIdentifier
LCB.NumEnt INT32U Num current entries m n
LCB.NumOvr INT32U Number of overflow
n
LCB. LstEntDisc INT32U See Log.LastEntryDiscarded m
Constraint:
TIME_ENTRY__SUPPORT=TRUE
LCB.OldTim BTIME6 See Log.OldestLogEntry.TimeOfLog o n
LCB.NewTim BTIME6 See Log.NewestLogEntry.TimeOfLog o n
m = mandatory o = optional y = setable n = not-setable
6.2.4.2.1 Log Control Block Parameters
LogName (log name): This attribute is the name of the log to which the client desires information to be
logged. The default value, in the instance where there is a single LCB for a logical device, shall be the name
of the log object.
LogEnr(ECB to enroll): This references the ECBs whose notifications are to be logged.
In the instance where an ECB has been combined with an RCB to form a simplified structure, the reference
shall be to the simplified structure.
In the instance, where all ECBs are logged to the LOG, the reference LCB.Enr1 may be NULL to indicate
this condition. Otherwise, LCB.LogEnr1 shall be the name of the LCB, and LCB.LogEnr<2...n> shall be the
name of the other ECBs that the Log Agent has enrolled for the log object.
The default for these attributes is determined by the server.
The server may choose to default the values found in LogEnr and not allow a client to change these values.
<n> is the number of ECBs found within a given logical device.
LogWrp (Wrap): If this parameter is TRUE, and if the recording buffer overflows, the log entries that have
the lowest value of EntryIdentifier shall be automatically deleted and replaced with new entries. If entries are
deleted, then the attribute LstEntDisc shall be updated with the value of the EntryIdentifier that was just
deleted.
If FALSE, recording is suspended. In either case, once the buffer has filled to capacity and storage of

IEEE-SA
additional entries has been attempted, overflow will be set to TRUE.
The default for this attribute is determined by the server.
6.2.4.2.2 Log Control Block Status
The following attributes of the log control block are maintained by the Log Agent. They may be read by the
client to get the status of the logging process.
Status: This attribute represents the operational mode and other status indications pertaining to the log
object.
(0) Reserved. Set False.

(1) ENABLED. This bit reflects the state of Log.Enabled. When TRUE, this indicates that the
LCB and Log are enabled.
(2) LOG_MODE_WRAPPING. See Log.LogOperationalMode. LOG_MODE_ WRAP-
PING=TRUE indicates that the Log is operating in WRAPPING mode.
LOG_MODE_WRAPPING=FALSE indicates that the log is operating in NON-WRAP-
PING mode.
(3) OVERFLOW. See Log.Status (OVERFLOW).
(4) WRAPPED. See Log.Status (WRAPPED).
Opt (Supported options): This attribute represents operational mode and query support for the Log whose
name is found in the LogNam attribute. The bit values of this attribute are defined as follows:
(0) Reserved. Set FALSE.

(1) Unused.
(2) TIME_ENTRY_SUPPORT. A value of TRUE indicates that the log supports query based
upon a range specification based upon LogEntry.TimeOfLog. A value of false indicates
that a query based upon LogEntry.TimeOfLog shall be responded to with an error.
(3) DATA_OBJECT_FILTER. A value of TRUE indicates that a query of the log may contain
filtering criteria based upon DataObject identifiers.
NumOvr (number of overflows detected): This attribute holds the accumulated count of the number of transi-
tions of Log.Status (OVERFLOW) from FALSE to TRUE.
6.2.4.3 Log Control Block Services
The following services are defined for log control blocks:
a) GetLogControlBlock: This service retrieves the attribute values of log control block objects.
b) SetLogControlBlock: This service shall return failure if issued for any LCB attribute other than log
enable while log enable has a value of ENABLED. Otherwise, this service shall allow a client to
modify the value of the LCBs attributes. The transition of the log enable attribute from DISABLED
to ENABLED shall cause the following local processing to occur:
1) The Log Agent shall initialize the log contents and status attributes.
2) The Log Agent shall perform event enrollment for all ECBs contained in the list of enrollment.
3) The Log Agent shall begin recording events in the log.

IEEE-SA
The transition of the Log Enable attribute from ENABLED to DISABLED shall cause the following
local processing to occur:
1) The Log Agent shall cease records events in the log.
2) The Log Agent shall perform event disenrollment for all event conditions enrolled due to this
log control block.
3) The contents of the log shall be preserved until the log is re-enabled.
c) Create LogControlBlock: This service allocates a log control block from the server to the client
requesting it.
d) Delete LogControlBlock: This service returns a log control block to the server.
e) GetLogControlBlockNames: This service retrieves the list of log control block objects available for
use by the client.
f) QueryLog: This service reads a range of records from a log based on either time ranges (start and
end times) or entry numbers (starting or ending entry number) and optionally filtered on DataObject
identifiers or triggering ECB names.
g) Empty Log: This service requests that the Log Agent purge a range of entries from the log.
The QueryLog service allows for access by clients to the content of server logs. The basic service has the
parameters:
Service: QueryLog Comments

Request
LogName Name of log being accessed
TypeOfQuery Either ByTime or ByRecord
RangeStart See description below
RangeStop See description below
DataObjectFilters See description below
EntryToStartAfter See description below
Response
ListOfLogEntries A list of entries that meet the range criteria
An indication if there are more entries present in the
moreFollow log that meet the requested range criteria
ErrorResponse see 8.3.
The specific service primitives are:
LogName: The identifier that uniquely identifies the log in the context of the server.
TypeOfQuery: ENUMSpecifies the type of query operation being requested: ByTime or ByRecord.
RangeStart: VARIESIf the query is ByTime, RangeStart specifies a time of day. The first LogEntry
selected will be the first entry in the log with a time stamp greater than or equal to the RangeStart. If the
query is ByRecord, the RangeStart specifies the EntryIdentifier of the first LogEntry to select. In either case,
if no RangeStart is specified, the first LogEntry contained in the log will be the first entry selected.
RangeStop: VARIESIf the query is ByTime, RangeStop specifies a time of day. The last LogEntry selected
will be the last entry in the log with a time stamp less than or equal to the RangeStop. If the query is
ByRecord, the RangeStop specifies the EntryIdentifier of the last LogEntry to select. In either case, if no
RangeStop is specified, the last LogEntry contained in the log will be the last entry selected.

IEEE-SA
EntryToStartAfter: ENTRYIDENTIFIERWithin the range of selected LogEntry records, only those records
that fall logically after the EntryToStartAfter record will be retrieved. If no EntryToStartAfter is specified, all
selected records are retrieved.
If the LogEntries selected by the query operation exceeds the maximum size transferable due to communica-
tions constraints, the server shall return as many entire entries as possible and notify the client that more
LogEntries in the sequence follow. The client may then use the EntryIdentifier of the last LogEntry retrieved
as the EntryToStartAfter parameter on a subsequent QueryLog service request to retrieve more entries from
the log.
DataObjectFilters: This is the list of DataObject names that the client wishes to be returned in the Query-
Log.Response.
The EmptyLog service allows for the purging of contents by clients of server logs. The basic service has the
parameters:
Service: EmptyLog Comments

Request
LogName Name of log being accessed
InitializationRangeSpecification Either ByTime or ByRecord
Response
ConfirmationOfInitialization
ErrorResponse- see 8.3.
LogName: The identifier that uniquely identifies the log in the context of the server.
InitializationRangeSpecification: This specifies the range of the LOG entries that should be purged. If there
is no limit specified, then the entire contents of the LOG shall be purged.
Clients and servers claiming support for the logging model shall conform to the implementation of the fol-
lowing services:
Service Server Client Notes

GetLogControlBlock
Request m o
Response m C1
SetLogControlBlock
Request m m
Response m m
CreateLogControlBlock
Request o o
Response S1 C1
DeleteLogControlBlock
Request o o
Response S1 C1
GetLogControlBlockNames
Request m o
Response m C1
QueryLog
Request m m

IEEE-SA
Service Server Client Notes

Response m m
EmptyLog
Request m o
Response m o
C1 A client claiming the ability to issue the request shall be capable of processing
the response.
S1 A server claiming the ability to process the request shall be capable of issuing
the response.
6.2.4.4 Log Processing
The Client initiates the logging of information by writing the Loc Control Block parameters as follows:
a) LogNamSet to the name by which the log will be known

b) LogEnr[n]Set in each ECB name which should be used to generate events for the log
c) FillLvlSet to the percentage of the log at which the FILL_STATUS bit will be raised
d) LogSizSet to the maximum number of entries to allow in the log
e) LogWrpSet to WRAPPING if the log should wrap, and NON-WRAPPINg otherwise
f) LogEnaSet to TRUE to commence logging
The Client can then either begin polling the LCB Status field or set it up as part of a reporting DataSet.
Upon receiving a SetLogControlBlock request which sets the Log Enable attribute to ENABLED, the Log
Agent must enroll in the Event Control Block specified in the Log Control Block. As Event Notifications are
received for the specified Event Control Blocks, the Log Agent must:
a) Store the EventNotification information in the Log as a LogEntry. This includes the ECB Name that
has generated the notification, the ECB Event Notification State, and the Event Notification Data
Object. If the Event Notification Data Object represents a DataSet, the individual set members shall
be entered into the log and identified appropriately.
b) If the Log is full, either discard the EventNotification (if wrap is set to FALSE), or discard the oldest
entry in the log to make room for the new entry (if Wrap is set to TRUE).
c) Update the Log Control Block(s) Status parameters (Status, FillSt, EntOld, EntNew, NumEnt,
NumOvr, LstEntDisc, OldTim, and NewTim.
The Client can request the QueryLog service at any time. If, while monitoring (either through reporting or
polling) the Log Control Block Status, the FILL_STATUS bit is raised, then the log has reached the
requested fill percent. If the WRAP or OVERFLOW bit is raised, then the log has been filled. It is the
responsibility of the Client to Query the log as often as necessary to avoid overflow conditions.
6.2.5 Use of General Reporting Mechanisms
The following examples show how simple device models may make use of the agent models to define report-
ing capabilities.

IEEE-SA
6.2.5.1 Simple Analog Reporting
A simple device performing basic analog deadbanding and reporting by exception can be defined using the
Report Agent and the Event Agent. Note that for simple devices, many of the options and parameters may be
predefined and need not be remotely accessible by the client. Figure 11 shows the relationships.
Event
Agent
Write Event Enroll Notify

Control Block
Wr ite Report
Control Block Report
Client
Agent
Report
Device Model
Figure 11: Simple reporting model
In this simplified model, the event condition (analog deadband) is predefined for the Event Agent. The
write ECB establishes the analog DataSet to be monitored (input data), as well as the deadband algorithm
(evaluation function) and the settings for each analog (criteria). The write control block defines the format
of the report and initiates the processing. Reporting then proceeds, driven by changes in the analog values.
Figure 12 shows the basic transaction flow between the client and the server agents to perform the basic
reporting mechanism for a single report and event type:
Client Report Agent Event Agent

Write ECB---------------------------------------------------------------------------------------------->
Write RCB-------------------------------------------->
Event Enroll----------------------------------->
<------------------------------------------Event Notify
<-------------------------------------------------Report
<------------------------------------------Event Notify
<-------------------------------------------------Report
Figure 12: Simple Analog Reporting Transactions
6.2.5.2 Simple COS Reporting and Logging
A more complex device model may require simultaneous reporting and logging of data changes. A common
example is the reporting of status point changes as they occur, while maintaining a log of timestamped
changes for later retrieval if communication is disrupted or data is lost. For such a device model, both the
report control block and the log control block specify the same ECB: status changes. The evaluation function
may be fixed and predefined (simple change of state), and no criteria object or parameters need be specified.
Likewise, the report format may be fixed (reporting INDIVIDUAL events).
Figure 13 demonstrates the transaction flow for setting up and using the agents to allow for simultaneous
reporting and buffering of the same data driven events.

IEEE-SA
Client Report Agent Event Agent

Write ECB---------------------------------------------------------------------------------------------->
Write LCB-------------------------------------------->
Event Enroll----------------------------------->
Write RCB---------------------->
Event Enroll----------------------------------------------------------------->
<------------------------------Event Notify
Log Data
<----------------------------------------------------Event Notify
<------------------------------------------Report
Log Data
<--------------------------Event Notify
<----------------------------------------------------Event Notify
<------------------------------------------Report
Log Data
<----------------------------------------------------Event Notify
<------------------------------------------Report
Query Log---------------------------------------------------------------------->
<----------------------------------------------------Logged Data
Figure 13: Simple COS Reporting Transactions
6.3 Device Control Service Model

The device control model services consist of four capabilities: direct control, select before operate control,
time activated control, and device tagging. The local procedures required for the proper execution of each
capability are performed locally and whose implementation is a local matter.
6.3.1 Direct Control Capability
Direct control capability consists of one or more a direct control objects, which specifies the parameters to
use, and a direct control operation, which represents a direct control function. The direct control object is a
specialization of a DataObject which incorporates the semantics of the physical device functionality. Like-
wise, the direct control operation is a specialization of the set data values operation that incorporates the
validity checks required for control of the physical device. The following direct control procedure is used:
a) The client issues a direct control operation (set data values operation) for a direct control object that
is being made available by a server, including the type of command and optionally including a com-
mand parameter.
b) The server performs the validation of the direct control operation based on the access control privi-
leges (see 6.1.1.2.3 for details) of the client, the validity of the DataType being written (as in set data
values), the validity of the specific device function represented by the value being written, the state
of tagging (if applicable, see 6.3.4), and the operational status of the device,
If the direct control operation is valid, the server attempts to perform the direct control operation
requested, and responds with a positive acknowledgment; otherwise the server responds with a neg-
ative acknowledgment including a reason code indicating the type of failure.

IEEE-SA
c) The actual success or failure of the attempted operation of the physical device is not included in the
direct control operation model, but may be represented as a distinct DataObject model which may be
subsequently accessed by the client using either the data access services or the data reporting ser-
vices (see Section 5 and 6.2).
The availability of this capability, for use by the client, shall be listed as one of the association models list of
capabilities. Refer to 6.1 for further details.
The direct control object is structured as follows:
Object: Direct Control
Key attribute: Direct control device name

Attribute: Direct control command value
Direct control device name: Identifier that uniquely identifies the control point of the device to be directly
controlled.
Direct control command value: Attribute whose value will be set to indicate the control command to be
issued to the device. The type and interpretation of the direct control command value is outside the scope of
this document and must be specified in each device model that makes use of the direct control object model.
The direct control device services for the client are the following:
a) Get direct control object names: This service retrieves the list of direct control objects available in
the server.
b) Direct control operation: This service requests that a control function be performed on a direct
control object. Note that the direct control operation is a specialization of the set DataObject value
operation.
6.3.2 Select Before Operate (SBO) Control Capability

The SBO control capability allows for the modeling of controls that require a two-step commit procedure.
The SBO capability is modeled using an SBO control object and an SBO configuration object, along with
the select operation. A DataObject that contains an SBO control object may not be written by a client unless
the enclosed SBO control object is in the SELECTED state for that client. The state of the SBO control
object is set to SELECTED through the use of the select operation. Several conditions may cause the SBO
control object to be reset to the DESELECTED state, depending on the style of SBO being employed. The
SBO control object may be of type Operate_Once (deselect automatically after the DataObject containing
the SBO control object is written) or of type Operate_Many (stay selected until an explicit deselect or time-
out occurs).
The formal definitions are as follows:
Object: SBO:IDENTThe SBO object is used to represent the SBO control object within a control DataOb-
ject. When an SBO object appears within a DataObject, all peer and subordinate components of the DataOb-
ject require the SBO to be in the SELECTED state before allowing write access. SBO is an IDENT
DataObject that returns its DOReference as a value when read. The select procedure is implemented by per-
forming a GetDataObjectValues operation on the SBO object. The DOReference of an SBO object is always
<parent>.SBO, where <parent> is the DOReference of the containing DataObject. For example,
<anyDM>.CO.SBO would regulate access to everything under the <anyDM>.CO.
Object: SBOConfiguration
Key attribute: SBOName

IEEE-SA
Attribute: State
Attribute: SelTimeOut
Attribute: SBOClass
The SBOConfiguration object is associated with the SBO control object by naming convention. For exam-
ple, if the control containing the SBO control object has DOReference DM.CO.SwPos, then the configura-
tion element for the control is DM.CF.SwPos, and the SBOConfiguration is called DM.CF.SwPosSBO.
State:BOOLAttribute that indicates the state of selection of the associated SBO control object. When set to
DESELECTED, access to the associated DataObject is inhibited. When set to SELECTED, access to the
associated DataObject is allowed. The default state is DESELECTED. The SBOState shall be set to
SELECTED following a successful select operation on the associated SBO control object.
SelTimOut:INT8UTime attribute that specifies the maximum time (in seconds) the SBO control object can
remain selected before accessing the associated DataObject. The state of the SBO control object will revert
to DESELECTED following an expiration of the timeout interval after an SBO select operation.
SBO Class ENUM8Attribute that specifies if the SBO control object is implicitly deselected by the server
following an access of the associated DataObject (Operate_Once) or if the client must explicitly deselect the
SBO object after one or more accesses of the DataObject (Operate_Many). The specific values are defined
as:
Integer Value SBOClass

1 Operate_Once
2 Operate_Many
The following describes the procedures associated with the SBO select operation:
Select procedure
a) The client requests an SBO select operation to the server for an SBO control object. This is per-
formed by issuing a GetDataObjectValues request for the SBO component of the control.
b) The server determines if the client has appropriate access authority, that the SBO control object is
not currently selected by a different client, and that the device represented by the associated DataOb-
ject is operable and is not tagged so as to restrict operation. If the SBO select operation is valid, the
server issues a positive acknowledgment by returning DataObject reference for the SBO component,
sets the state of the SBO control object to SELECTED for that client, and starts a deselect timer for
either the interval defined by the SelTimeOut component of the associated SBOConfiguration object
or if unimplemented, some locally determined duration. Otherwise, the server responds with a nega-
tive acknowledgment containing a reason code for the failure.
c) If the deselect timer expires before a SetDataObjectValues operation (or its specialized form direct
control) on one or more of the other control components is requested by the selecting client, the state
of the SBO control object is set to deselected.
d) If a SetDataObjectValues operation is received from the selecting client while the SBO object is not
in the selected state for that client, the operation is denied.
e) If a SetDataObjectValues is received from the selecting client while the SBO object is in the selected
state for that client, one of the following procedures is performed upon completion of the set data
value operation, based on the SBO select class of SBO control object:
1) If the SBO control object is of the Operate_Once SBO Class, the SBO control object is set to
deselected.
2) If the SBO control object is of the Operate_Many SBO Class, the SBO control object is left in
the selected state.

IEEE-SA
capabilities. See 6.1 for further details.
The following services are defined for SBO Objects:
a) Get SBO object names: This service retrieves the names of the SBO objects available in the server.
b) SBO select operation: This service is invoked by the client to enable access to the associated
DataObject. The operation, if valid, causes the server to set the state of the referenced SBO control
object to SELECTED. The validity check procedure by the server includes checking the state of the
SBO control object (must not be SELECTED for a different client), checking the tagged status of the
DataObject (if applicable), and verifying the operational status of a device represented by the data
value (if applicable).
c) SBO deselect operation: This service is invoked by the client to place the SBO control object into
the DESELECTED state. The operation causes the server to set the state of the referenced SBO con-
trol object to DESELECTED. Note that the deselect operation is only defined if the server has
implemented the SBOConfigure DataObject for the control.
Table 7: DataObject Definition: SBO
Attribute DataType
SBOName DOReference to this component
State bool
SelTimOut int8u
SBOClass enum8
Figure 14 shows the interaction of a single client attempting to perform SBO.
6.3.3 Time Activated Control Capability

The time activated control capability consists of time activated control objects, which are associated with
DataObjects that support time activated control functions, and a time activation process, which initiates the
control command at the appropriate time.
The following time activated procedure is used:
a) The client issues a time activated operation command to a device that is handled by a server, includ-
ing the type of command, the date and time to activate the command, and (optionally) a command
parameter. The server sets the time activated command value to the type of command, sets the time
activated timer to the date and time, and sets the time activated command parameter to the command
parameter.
b) The time activation process in the server performs the validation of the command, including check-
ing of tags:
1) If successful, the server issues a time activated acknowledgment report to the client and starts
the time activated timer.
2) If not successful, the server issues a time activated error report, including an error code indicat-
ing how the control command was invalid.
c) When the time activated timer times out, the time activation agent issues the time activated
command.
d) Subsequently, the client accesses the results of the control action, which may be performed either by
the data retrieval services or the data reporting services (see 3.2 and 3.3).

IEEE-SA
SELECT ACCESS
Server check access
Client issues
SBO Select Request Access Denied Access Granted
Request
SELECT SELECTED
ACCESS ERROR Server Start Timer
UNSELECTED Server issues Server issue SBO
SBO Select Response- Select Response+
Timer Expire
or SBO Deselects
Client issues
SBO Operate Request
Request
DESELECTING
Server Stop Timer
OPERATING
Operational Server Local Procedure
OPERATE Success
Server issues
SBO Operate Response+
Not Operational
OPERATE ERROR
Server issues
SBO Operate Response-
Figure 14: SBO State Transition
The time activated control block is structured as follows:
Object: Time activated control block

Key attribute: Time activated device name
Attribute: Time activated command value
Attribute: Time activated command parameter
Attribute: Time activated command timer
Time activated device name: Identifier that uniquely identifies the control point of the device to be directly
controlled.

IEEE-SA
Time activated command value: Attribute whose value indicates the control command to be issued to the
device.
Time activated command parameter: Parameter whose value indicates the length of time of a pulse or the
number of pulses to issue to the device.
Time activated command timer: Time whose value indicates the time and date when the command is to be
executed.
The time activated device services for the client are the following:
Get time activated control object names: This service retrieves the list of time activated control
objects available in the server.
Time activated operation: This service sets the time activated command value and the time activated
timer, and optionally sets the time activated command parameter.
The time activated validation initiates the following actions:
Time activated acknowledgment report, which is used by the server to indicate to the client that the
requested time activated operation has been successfully initiated to the device.
Time activated error report, which is used by the server to indicate to the client that the requested
time activated operation is invalid. The appropriate error code is included in the report.
See Table 8.
Table 8: Time Activated Control, TimActCtl DataObject Model
Attribute DataType
Name TimActCtl
Cmd enum16
Parm btim4
When btim6
6.3.4 Device Tagging Capability
The device tagging capability consists of device tagging control blocks, which are associated with DataOb-
jects that support tagging control functions, and a device tagging agent, which validates the tagging authori-
zation whenever the different types of tags with different owners are set and removed.
capabilities. See 6.1 for further details.
The formal model of a tag is:
Object: Tag
Attribute: TagID
Attribute: TagTyp
Attribute: TagD
Attribute: TagOwn
TagID: Uniquely identifies the tag number for the device or point assigned to.

IEEE-SA
TagTyp: The permissible tag types. The bits representing TagTyp are:
Bit Number Bit Name

0 No switching tag permitted
1 Operation blocked tag permitted
2 Device failure tag permitted
3 Interlock active tag permitted
4-7 Unassigned (future use)
TagD: Free text description of tag.
TagOwn: Owner or person who placed the tag. Safety tags can only be removed by or with permission of the
TagOwn.
Table 9: Tag DataObject Model

Attribute DataType
Name Tag
TagID int8u
TagTyp bstr8
TagD vstr128
TagOwn vstr32
Model: DeviceTag
Attribute: Tags: ARRAY[4] of Tag
6.4 Multicast Service Model

The purpose and use of the set of multicast services is to allow an application to issue a single request and to
have the request transmitted and received by multiple remotes, and to allow for the reporting of information
from a server to multiple enrolled clients (see 6.2). In general, such requests must be unconfirmed at the
application protocol level.
UCA 7-layer connectionless mode is defined over two distinct levels of service: normal and reliable, both of
which operate as multicast services. When operating at the normal level of service, each connectionless-
mode LSDU is transmitted by the link layer as in typical OSI operation. Since there is no acknowledgment
of data in connectionless-mode, there is no error detection or recovery. When operating at the reliable level
of service, special link procedures are used to retransmit each Link Service Data Unit (LSDU) packet, ini-
tially very often, gradually increasing the period. This retransmission allows for a much higher probability of
reception over unacknowledged links. In circumstances requiring extremely fast response time (e.g., breaker
operation), by the time a connectionless-mode times-out waiting for an acknowledgment, it is too late to
retransmit the LSDU. A reliable connectionless-mode profile however may retransmit the message within
the time window regardless of whether or not the receiver has actually received the message.
The multicast model requires that all service data units (SDUs) are sent to a destination address that resolves
to a group-address or a set of unicast addresses. The method of resolution is out-of-scope for this section.
The calling address shall be a unicast address.
Note: For most UCA 2.0 profiles, a multicast service requires that all SDUs sent shall refer to a group-AE-
title, and a group P-address.

IEEE-SA
6.4.1 Multicast Enrollment/Management
The group-address and the set of unicast addresses it represents may be recorded in a directory. When an
application wants to communicate with the group, it can give the directory the group name and be returned
the group P-address.
This information must also be distributed to those end-systems on which the applications in the group
resides and those application gateways that proxy applications in the group, so that they recognize PDUs that
they must deliver. Because there are no standard enrollment protocols, this will have to be accomplished by
ad hoc means.
Note that multicast primitives shall not be propagated through routers, so that the use of multicast services
across multiple subnetworks requires specialized intermediate systems. Any specialized protocol required
for such intermediate systems is an area of further study.
The CASM service defined for multicast is the SetDataObjectValues (unconfirmed).
6.5 Time Model

The time model provides the local timing elements required for use within the reporting model and device
control model. Each server and device model shall have a specialization of a DataObject that represents the
local time, synchronized either by local means or through the time synchronization services of the underly-
ing communications mechanism. In addition, CASM models require accurate interval times, which implies
some free running clock mechanism that is not disturbed by time synchronization activities. The mainte-
nance of interval times is a local issue and is outside the scope of this document.
Object: Local time

Key attribute: Local time parameter name
Attribute: Btime6e (must be GMT time representation)
Since, the local time parameter is a specialization of a DataObject, there are no additional application ser-
vices required to get/set the value of the parameter.
See UCA Profiles, Version 2.0 for details regarding time synchronization in the underlying protocols.
6.6 Blob Object Model

This section describes the formal object model for BlobData. BlobData represents the data content refer-
enced by a blob DataObject within a LogicalDevice or server. While not independently visible from the
server, the BlobData class can be accessed through the reference obtained by reading the value of a blob with
the GetDataObjectValues service. The actual storage and management of BlobData is a local matter.
Model: BlobData
Key attribute: BlobDataReference
Attribute: Access control
Attribute: Data
Attribute: Format
BlobDataReference: This identifier unambiguously defines the BlobData within the scope of the server, for
use with the UploadBloc and DownloadBlob services. Note that this reference is not guaranteed to be con-
stant and must be retrieved just prior to issuing the UploadBlob or DownloadBlob service. The current refer-
ence is only obtainable by reading the DataObject of type BLOB.

IEEE-SA
AccessControl: This attribute defines the network visibility and access privileges of the BlobData to calling
clients. The representation is a local matter.
Data: This set of octets encodes the contents of the BlobData.
Format: This attribute defines the internal composition of the data if it is known.
The services defined for BlobData are:
a) DownloadBlob: This service is used to transfer the BlobData to the server.

b) UploadBlob: This service is used to transfer the BlobData to the client.
6.6.1 AccsBlob DataObject Class
The transfer of BlobData objects may require allocation from a limited pool of resources. Therefore, it can-
not be assumed that any single set of BlobData will be continuously available. Also, the ability of a server to
manage the segmented protocol for transfer of BlobData to simultaneous clients may be limited. To address
this difficulty, a structured DataObject class is defined that operates in a manner similar to SBO in that
access to a BLOB must be selected prior to transfer. This allows a server to serialize access to BlobData at its
discretion.
The AccsBlob DataObject class consists of:
Common Class: AccsBlob

Access Blob Object
Name Default
Blob m
State o
TimOut o
Fmt o
Blob : BLOBThis is the BLOB DataObject itself. When read, this provides a BlobDataReference that can be
used to transport the BlobData.
State : BOOLThis attribute indicates the state of selection of the BLOB. When set to Deselected, FALSE,
access to the associated DataObject is inhibited. The default state is Deselected.
TimOut : INT8UThis time attribute specifies the maximum time the BLOB can remain selected before
accessing the associated data. The units are in number of seconds.
Fmt : ENUM8This describes the format of the contents of the BLOB. The following format identifiers are
initially recognized:
OPAQUE Contents are private to the application

COMTRADE Contents follow the Comtrade standard definitions
PQDIFF Contents follow the PQDIFF standard used in describing transient data sets
BER Contents follow the ISO basic encoding rules of tag/length/data
TYPESPEC Contents are a CASM-type specification (can be used to exchange whole
DeviceModel composition)

IEEE-SA
Integer Value Format

1 OPAQUE
2 COMTRADE
3 PQDIFF
4 BER
5 TYPESPEC
6.6.2 AccsBlob State machine
Figure 15 illustrates the state machine that manages the BlobData transfer process.
SELECT ACCESS
Server check access
Client issues
AccsBlob Select Access Granted
Request
Request
Access Denied
Timer Expire SELECTED

or AccsBlob Deselects Server Start Timer
UNSELECTED
Server issue AccsBlob
Select Response+
Client issues
Transfer Completed InitiateBlobTransfer Request
TransferBlobData
Figure 15: AccsBlob and TransferBlobData state machine
Blob transfer error responses:
Select failure
1 TEMPORARILY_UNAVAILABLE
Operate failure due to non-select
2 OBJECT_ACCESS_DENIED

IEEE-SA
7. Standardized DataTypes
The set of standardized types can be found in a separate document CASM: Guide to Device Modelers.
8. Mapping to MMS
This section maps the objects and services of the CASM model to the MMS protocol objects and services.
Note that implementations claiming conformance to this document must also conform to one or more of the
standardized UCA device models (e.g., Generic Object Models for Substation and Feeder Equipment, as
well as UCA Profiles, Version 2.0. Further requirements regarding MMS and the mapping of MMS to under-
lying protocols is contained in the profile reference.
8.1 Service Conformance Codes

In the tables that follow, there is a column to represent conformance requirements of the client and of the
server. The following designations will be made in those columns.
supportedm: Any feature denoted by m is mandatory if the referenced construct is mandatory in

the standardized object model being implemented. However, it is not a requirement that the feature
shall be used in all instances of communication, unless mandated by the base standard.
optionally supportedo: Any feature denoted by o is left to the implementation as to whether that
feature is implemented or not.
conditionally supportedc: Any feature denoted by c<n> shall be supported under the condition
referenced c<n> specified in this document, where <n> stands for a number. If these conditions are
not met, the feature is outside the scope of this document.
excludedx: Any feature denoted by x is excluded in this document, i.e., an implementation shall
behave as if the feature is not implemented.
outside of scopei: Any feature denoted by i is outside the scope of this document, i.e., it may be
ignored and will therefore not be the subject of a document conformance test. However the syntax of
all parameters of supported PDUs shall be implemented, even if the procedures are not (i.e., the
receiver shall be able to decode the PDU).
8.2 MMS Conformance

This section contains an abbreviated set of MMS conformance requirements to support mapping CASM to
MMS.
The Value/Ref. column specifies constraints on values for the parameter and/or contains refer-
ences to text in this or other documents.
The F/S column reflects the requirements of this functional standard. Each entry in this column is
chosen from the following terminology:
The Client-CR stands for Client Conformance Requirement.
The Server-CR stands for Server Conformance Requirement.

IEEE-SA
8.2.1 MMS Services Required
Table 10 lists MMS service conformance requirements.
Table 10: MMS Service Conformance Requirements
MMS PDU Client-CR Server-CR

F/S F/S
Environment and general management
Initiate m m
Conclude m m
Abort m m
VMD management
GetNameList m m
GetCapabilityList m m
Domain management
InitiateDownloadSequence o o
DownloadSegment o o
InitiateUploadSequence o o
UploadSegment o o
TerminateDownloadSequence o o
TerminateUploadSequence o o
DeleteDomain o o
Journal management
InitializeJournal o o
ReadJournal o o
Variable access
Read m m
Write m m
InformationReport o o
GetVariableAccessAttributes o m
DefineNamedVariable o o
DeleteNamedVariable o o
GetNamedVariableListAttributes o o
DefineNamedVariableList o o
DeleteNamedVariableList o o
ServiceError m m
8.2.2 Parameter CBBS
Table 11 gives CBB parameters.

IEEE-SA
Table 11: Parameter CBB
Client-CR Server-CR
Parameter
F/S Value/ref. F/S Value/ref.
Str1 o m
Str2 o o
Vnam o m
Valt c1 c1
Vadr o o
Vsca x x
Tpy o o
Vlis o o
Real i i
Cei i i
c1 = Restricted use of alternate access: In order to facilitate the implementation of
CASM in small low-cost devices, a restriction on the required capabilities of alternate
access is defined. Specifically, index ranging shall only be required on the lowest level of
access.
8.3 Error Responses for Confirmed Services

In the service mappings that follow, the responses are shown for a positive response to the service. If for a
server determined reason there is an error that prevents a proper response, MMS defines a uniform error
response format that is used in all cases. The error response, therefore, is shown in Table 12.
Table 12: Error Response to MMS Model Mapping
Service: Error response MMS services/argument/results Server Client Note

Response ServiceError response
errorClass errorClass m m
errorCode errorCode m m
additionalCode additionalCode o o
additionalDescription additionalDescription o o
Table 13 enumerates response errorCodes that might result from an unsuccessful confirmed method.
Table 13: Error Response errorCode
Enum ID
0 OBJECT_INVALIDATED
3 HARDWARE_FAULT
4 TEMPORARILY_UNAVAILABLE
5 OBJECT_ACCESS_DENIED
6 OBJECT_UNDEFINED
7 TYPE_UNSUPPORTED
8 TYPE_INCONSISTENT
9 OBJECT_ATTRIBUTE_INCONSISTENT
10 OBJECT_ACCESS_UNSUPPORTED
11 OBJECT_NON_EXISTENT
12 COMMUNICATIONS_ERROR
13 OBJECT_VALUE_INVALID

IEEE-SA
8.4 DataType Model Mapping

Table 14 maps abstract primitive DataTypes to MMS primitive types.
Table 14: Primitive DataType Mapping
Abstract Type MMS Type MMS Size Server Client Note

BSTR[n] array-of-Boolean n bits m m 1
BSTR8 array-of-Boolean 8 bits m m 1
INT8U unsigned integer 8 bits o m
INT8S integer 8 bits o m
INT16U unsigned integer 16 bits m m
INT16S integer 16 bits m m
INT32U unsigned integer 32 bits o m
INT32S integer 32 bits o m
FLT32 floating-point 32 bits total, 8 bit exponent o m
FLT64 floating-point 64 bits total, 11 bit exponent o o
BOOL Boolean n/a m m
VSTR[n] visible-string -n octets (variable) m m
VSTR visible-string -32 max octets (variable) m m
OSTR[n] octet-string -n octets (variable) o m
BTIME4 binary-time 4 octets m m
BTIME6 binary-time 6 octets m m
STRUCTURE structure n/a m m 1
i x j elements for two dimensions
ARRAY[i][j] array o m
(or more)
ENUM8 integer 8 bits o m 2
ENUM16 Integer 16 bits m m
IDENT visible-string 64 m m 3
BLOB visible-string 32 o o
Notes:
1In encoding a structure that contains optional components with nonsequential optional components
included, the first element is an InclusionBitstring (IB) showing the included membership. To distinguish
between structures that contain a bitstring as its first element, the first bit is reserved as an indicator that, if
TRUE, this BITSTRING is an IB and denotes optional component inclusion. The balance of the bitstring is
thereby extended by a length of one to indicate it is not an inclusion bit map. See the detailed rules for the IB
later in this section.
2Enumerations are deliberately left signed to provide a natural partition between well-known and custom
values. Known, standardized values are positive, custom ones are negative.
3The IDENT can be used to reference any component of a DataObject within the scope of the server. The
MMS mapping of the IDENT is to a visible-string. However, the format of the identifier is in the abstract
notation of a DataObject presented in 2.3.1. See 8.6.1 for the translation of this string to an MMS Variable-
AccessSpecification.

IEEE-SA
8.5 Scope of DataObjects and DataSets

DataObjects can have one of three scopes: LOCAL, SERVER, and NONSHARED. These scopes map to MMS
name scope as shown in Table15.
Table 15: Mapping of Scope to MMS
CASM Scope MMS scope

local DOMAIN
server VMD
nonshared AA
8.6 DataObject Model Mapping

The DataObject object model is defined as shown in Table 16 through Table 22.
Table 16: DataObject to MMS Mapping
Object Class MMS Class Server Client Note

DataObject Named variable m m
Attribute MMS Object/Attribute
DOReference <see note 1> m m 1
Ancestry visible-string m o 2
Scope DOMAIN, VMD, AA 3
DataType Type specification m m
Value Data m m
AccessControl Access method
Deletable Deletable
LocalResource Address
Services MMS Services
GetDataObjectValues Read m m
SetDataObjectValues Write o o
SetDataObjectValues(Unconfirmed) InformationReport o o
GetDataObjectAttributes GetVariableAccessAttributes m m
CreateDataObject DefineNamedVariable o o
DeleteDataObject DeleteNamedVariable o o
Table 17: DataObject: GetDataObject
Service: GetDataObjectValues MMS Services/Argument/Results Server Client Note

Request Read request
SpecificationWithResult SpecificationWithResult m o
VariableAccessSpecification
ListOfDataObjects m m
Parameter = listOfVariable
Response+ Read response
VariableAccessSpecification
ListOfDataObjects c c 4
Param. = listOfVariable OPTIONAL
Values listOfAccessResult m m 5
Responsesee 8.3.

IEEE-SA
Table 18: DataObject: SetDataObjectValues
Service: SetDataObjectValues MMS Services/Argument/Results Server Client Note

Request Write request
ListOfDataObjects VariableAccessSpecification m m
ListofData listofData m m
Response+ Write response
Result Response m m
Responsesee 8.3.
Table 19: DataObject: SetDataObject (Unconfirmed)
Service: SetDataObjectValues
MMS Services/Argument/Results Server Client Note
(unconfirmed)
Request InformationReport
ListofData ListofData m m
Response
<None>
Table 20: DataObject: GetDataObjectAttributes
Service: GetDataObjectAttributes MMS Services/Argument/Results Server Client Note

Request GetVariableAccessAttributes request
DOReference ObjectName/Address m m
Response+ GetVariableAccessAttributes response
Type TypeSpecification m m
Responsesee 8.3.
Table 21: CreateDataObject: CreateDataObject
Service: CreateDataObject MMS Services/Argument/Results Server Client Note

Request DefineNamedVariable request
DOReference ObjectName m m
LocalResource Address m m
Type TypeSpecification m o
Response+ Def
Null
Responsesee 8.3.
Table 22: DataObject: DeleteDataObject
Service: DeleteDataObject MMS Services/Argument/Results Server Client Note

Request DeleteVariableAccess Request
DOReference ObjectName o o
Response+ DeleteVariableAccess Response
Null Null
Responsesee 8.3.

IEEE-SA
Notes for Tables 1622:
1See 8.6.1 on mapping of DOReference. Note that when it is the object of a message, it maps to the MMS
object described in the following section. When it is transferred as data, it is carried in a visible string and
follows the syntax described in 5.3.3.
2Ancestry contains a sequence of ancestors for the DataObject for which it is a specialization.
3See 8.5 for scope options.
4Conditional based on choice in request.
5Values are data that correspond to the type of the DataObject referenced by the DataObjectName.
8.6.1 Mapping of DOReference Notation
To translate a DOReference to an MMS object name:
The scope maps to the MMS scope.

Named Variable of the same name.
Any DataObject that is contained in a structured DataObject of less than 4 nesting levels maps to
named variable where the . in the nesting description maps to an ASCII $ as part of the name.
Any component of a DataObject that is a structure, of four or more nesting levels maps to an MMS
named variable using the previous rule, combined with additional levels beyond mapping to com-
ponent names transported using alternate access.
Any component of a DataObject that is an array maps to an MMS named variable by the previous
rules up to and including the array name. The balance of the object maps to an alternate access
specification.
Any component of a DataObject that is an array element or structure component may optionally be
accessed using an alternate access specification.
The MMS scope and MMS named variable name combine to represent an MMS ObjectName.
The inheritance suffix, if present, is ignored for this purposeit is for self description purposes
only and not part of normal messaging.
8.6.2 Mapping of Optionality: InclusionBitstring, IB
CASM implicitly support optionality of components of an aggregated DataObjects. When mapped to MMS,
the IB carries this information about which components are present and absent. The IB is present as the first
element in any MMS structured NamedVariable when:
The structure contains optional components for which some are present and some are not, and the
set of included components cannot be unambiguously determined from the size of the structure
(i.e., the optionally included components are not sequential and include the first nonmandatory
component).
The structure contains a SBO, tag, security, or CASMVersion components.
Table 23 shows the definitions of the bits of the IB. The total number of bits defined varies with the structure
and needs to be 8 plus the maximum number of components in the structure:
The beginning of the name is the NamedVariable for the structure in which it is contained followed by
$IB, when there are fewer than four levels of hierarchy in the combined name. Otherwise, the name IB
becomes a named component of the MMS structure NamedVariable.

IEEE-SA
Table 23: DataObject Definition: InclusionBitstring (IB)
Bit Values for InclusionBitstring Data Object

BIT Definition Description
0 IsInclusion TRUE if this is InclusionBitstring and first element of a structure
1 SBO SBO is present
2 TAG A list of TAGS is present
3 SECURE A security constraint is present (will not be visible)
4 CASMVersion The CASMVersion structure is present
5 <reserved>
6 <reserved>
7 <reserved>
8 1stPresent The first component of the structure is present
9 2ndPresent The second component of the structure is present
. . Continues for each sequential component
8.6.2.1 Read of structure with OptionalInclusion
Servers always include IB when the containing structure is read in total. The following cases apply:
If what is being read is a structure, then the contained IB is returned.

If what is being read is a component of a structure and it is not itself a structure, than no IB is
returned.
If what is being read is a component of a structure and it is itself a structure, than the structure
returned will contain IB.
Clients receiving the components of a structure read must check the first component to determine if it is the
IB (recognized by its being of type bitstring and the first bit being set to TRUE). If it is, then this IB must be
used in matching up the elements in the structure set transported with those in the reference model that
would contain the complete set.
8.6.2.2 Write of structure with OptionalInclusion
The server must fail a write to a complete structure that contains an IB or when the data elements transported
by the write begin with an IB.
The client never includes IB when the containing structure is written. When writing the values of DataOb-
jects whose DataType are structures, the client must use MMS alternate access to list all of the components
included in the write.
8.6.3 DeviceIdentity (DI)
DeviceIdentity maps to a DataObject with DataType STRUCTURE. It must always be a NamedVariable named
DI. See 8.6.
8.6.4 DeviceModel (DM)
DeviceModel maps to a DataObject, with DataType STRUCTURE. See 8.6.

IEEE-SA
8.6.5 FunctionalComponent (FC)
FunctionalComponent maps to a DataObject, with DataType STRUCTURE. See 8.6.
8.7 DataSet Model Mapping

The DataSet object model is defined as shown in Table 24 through Table 28.
Table 24: DataSet to MMS Model Mapping

DataSet Named variable list m m
DataSetReference variableListName m m
Scope DOMAIN, VMD, AA
AccessControl Access method
Deletable Deletable
ListofDOReference listOfVariable m m
GetDataSetElementNames GetNamedVariableListAttributes m m
GetDataSetValues Read m m
CreateDataSet DefineNamedVariableList o o
DeleteDataSet DeleteNamedVariableList o o
Table 25: DataSet: GetDataSetElementNames
Service:
GetDataSetElementNames
Request GetNamedVariableListAttributes request
DataSet variableListName m m
Response+ GetNamedVariableListAttributes response m m
Responsesee 8.3.
Table 26: DataSet: GetDataSetValues
Service: GetDataSetValues MMS Services/Argument/Results Server Client Note

SpecificationWithResult SpecificationWithResult o o
DataSet VariableAccessSpecification m m
Parameter = variableListName
Response+ Read response
ListofDOReference OPTIONAL VariableAccessSpecification c c
Parameter = variableListName
OPTIONAL
Values listofAccessResult m m
Responsesee 8.3.

IEEE-SA
Table 27: DataSet: CreateDataSet
Service: CreateDataSet MMS Services/Argument/Results Server Client Note

Request DefineNamedVariableList request
DataSetName variableListName m m
Response+ DefineNamedVariableList response
NULL
Responsesee 8.3.
Table 28: DataSet: DeleteDataSet

Service: DeleteDataSet MMS Services/Argument/Results Server Client Note
Request DeleteNamedVariableList request
ListOfDataSet listOfVariableListName m m
Response+ DeleteNamedVariableList response
NULL
Responsesee 8.3.
8.8 Server Model Mapping

Server model mapping is shown in Table 29 through Table 31.
Table 29: Server to MMS Model Mapping

Server VMD m m
CASMVersion NamedVariable m i
Association Model <not visible> m m
Data Access Model <not visible> m o
ReportingAgent <not visible> o o
DeviceControlAgent <not visible> o o
SecurityAgent <not visible> o o
ListOfCapabilities ListOfCapabilities m m
ListOfLogicalDevices DomainNames m m
ListOfDataObjects ListOfNamedVariables
ListOfDataSets ListOfNamedVariableLists
ListOfLogs ListOfJournal
ListOfClientAssociations Associations
GetLogicalDeviceList GetNameList class domain m m
GetCapabilities GetCapabilityList m m

IEEE-SA
Table 30: Server: GetLogicalDeviceList
Service:
GetLogicalDeviceList
Request GetNameList request
Null objectClass parameter = domain m m
objectScope parameter = vmdSpecific
Response+ Response
ListOfLogicalDevices sequence of { listOfIdentifier moreFollows } m m
Responsesee 8.3.
Table 31: Server: GetCapabilitiesList
Service: GetCapabilities MMS Services/Argument/Results Server Client Note

Request GetCapabilityList request
Null m m
Response+ GetCapabilityList response
ListOfCapability Levels sequence of { listOfCapabilities, moreFollows } m m
Responsesee 8.3.
8.9 Association Model Mapping

Association model mapping is detailed in Table 32 through Table 35.
Table 32: Association to MMS Model Mapping

Association Association m m
Attribute ACSE Object/Attribute
CallingApplicationTitle CallingApplicationTitle m m See below
CapabilityLevelsSupported CapabilityLevelsSupported
AuthenticationValue AuthenticationValue m m See below
Security MethodsAnd and Security MethodsAnd and parameters m m See below
parameters
Initiate Initiate m m
Conclude Conclude m m
Abort Abort m m
Note: See UCA Profile Specification, Version 2.0 for details of this mapping.

IEEE-SA
Table 33: Association: Initiate
Service: Initiate MMS Services/Argument/Results Server Client Note

Request Initiate request
localDetailCalling localDetailCalling m m
proposedMaxServOutstanding proposedMaxServOutstandingCalling m m
Calling
proposedMaxServOutstandingCalled proposedMaxServOutstandingCalled m m
proposedDataStructureNestingLevel proposedDataStructureNestingLevel m m
initiateRequestDetail initiateRequestDetail m m
proposedVersionNumber proposedVersionNumber m m
proposedParameterCBB proposedParameterCBB m m
servicesSupportedCalling servicesSupportedCalling m m
Response+ Initiate response m m
localDetailCalled localDetailCalled m m
negotiatedMaxServOutstandingCalling negotiatedMaxServOutstandingCalling m m
negotiatedMaxServOutstandingCalled negotiatedMaxServOutstandingCalled m m
negotiatedDataStructureNestingLevel negotiatedDataStructureNestingLevel m m
initiateResponseDetail initiateResponseDetail m m
negotiatedVersionNumber negotiatedVersionNumber m m
negotiatedParameterCBB negotiatedParameterCBB m m
servicesSupportedCalled servicesSupportedCalled m m
Responsesee 8.3.
Table 34: Association: Conclude
Service: Conclude MMS Services/Argument/Results Server Client Note

Request Conclude request
Null
Response+ Conclude response
Null
Responsesee 8.3.
Table 35: Association: Abort
Service: Abort MMS Services/Argument/Results Server Client Note

Request Abort (ACSE A-ABORT)
Null
Response
<none>

IEEE-SA
8.10 LogicalDevice Model Mapping

LogicalDevice model mapping is shown in Table 36 through Table 38.
Table 36: Mapping of LogicalDevice to MMS

LogicalDevice Domain m m See below
VMD OPTIONAL o o
LDReference Domain Name
Deletable Deletable
ListOfDataObjects DomainContent
ListOfDataSets DomainContent
GetDataObjectsList GetNameList m m
GetDataSetsList GetNameList m m
CreateLogicalDevice InitiateDownloadSequence
DeleteLogicalDevice DeleteDomain
Table 37: LogicalDevice: GetDataObjectsList
Service: GetDataObjectsList MMS Services/Argument/Results Server Client Note

LDReference objectClass parameter = namedVariable m m
objectScope parameter = domainSpecific
Response+ GetNameList response
ListOfDataObjects listOfIdentifier m m
Responsesee 8.3.
Table 38: LogicalDevice: GetDataSetsList
Service: GetDataSetsList MMS Services/Argument/Results Server Client Note

LDReference objectClass parameter = namedVariableL- m m
ist
objectScope parameter = domainSpecific
Response+ GetNameList response
ListOfDataObjects listOfIdentifier m m
Responsesee 8.3.
Note: LogicalDevice must map to domain; optionally, it can additionally map to VMD.
8.11 Device Control Model Mapping

The SBO, SBOConfiguration, TAG, and TimeActivatedControlBlock models are all derived models from
DataObjects. As such they are defined in the standard types section. Table 39 through Table 41 map the
abstract services for these objects to their CASM equivalents.

IEEE-SA
Table 39: SBO: Select
Service: Select MMS Services Server Client Note

<SBO component in desired DataObject> VariableAccessSpecification m m
Response Read response
<Name of parent DataObject component Values m m
to SBO>
Table 40: SBO: DeSelect
Service: DeSelect MMS Services Server Client Note

Request Write request
<SBO.state component in desired VariableAccessSpecification m m
DataObject>
FALSE Data m m
Response Write response
Success/Fail List of AccessResult m m
Table 41: SBO: Operate
Service: Operate MMS Services Server Client Note

Request Write Request
Data Data m m
Response+ Write Response
Result Result m m
Responsesee 8.3.

IEEE-SA
8.12 BlobData Model Mapping

Table 42: Mapping of BlobData to MMS

BlobData Domain m m
BlobDataReference MMS Named variable m m 1
Access Control Deletable o o
Data DomainContent m m
Format ListOfCapabilities m m
DownloadBlob MMS DownloadSequence m m 2
UploadBlob MMS UploadSequence m m 3
Notes:
1MMS Named Variable contains the domain name.
2Requires sequence of primitives (InitiateDownloadSequence, DownloadSegment, Terminate-
DownloadSequence, etc.)
3Requires sequence of primitives (InitiateUploadSequence, UploadSegment, TerminateUp-
loadSequence, etc.)
8.13 Reporting Model Mapping

The report control block, ECB, and log control block all are derived from DataObject and therefore map to
MMS named variables in the normal way.
The services get, set, create, delete, and GetNames, for each of these objects maps to the corresponding ser-
vices for the DataObject presented above.
The report object maps to an MMS information report of an MMS named variable list. The named variable
list being reported has name RPT. Note that this named variable list is effectively created at report genera-
tion time, and is immediately deleted upon generation of the report. The actual names of the members need
not be defined, as only the name of the list is transmitted, and the meaning of the contents can be inferred
from the structure of the report. The members of this temporary named variable list are basically some spe-
cial variables representing the header information of the report, a bitstring denoting which members of the
original DataSet (which was named in the output data attribute of the ECB) are being reported, along with
the values, quality codes, time stamps, and reasons for inclusion for each reported object. Specifically, the
information report will contain the named variable list name and the list of data items for values as shown in
Table 43.
Table 43: Information Report Contents
Component MMS DataType Range Usage Controlled by

RptID VisibleString Report identifier If RptID is NULL in RCB, use name of
RCB.always present
OptFlds BitString Same as OptFlds in RCB Always present
SeqNum Unsigned Sequence number Only if SEQUENCE_NUMBER
RptTim BinaryTime Report time stamp Only if REPORT_TIME_STAMP
OutDat VisibleString OutDat from RCB Only if OUTPUT_DATASET_NAME
Inclusion BitString InclusionBitstring Always present
ListOfD Sequence of data List of reported data Always present
Reasons BitString List of reason for inclusion Only if REASON_FOR_INCLUSION

IEEE-SA
Note that the list of reason for inclusion is a sequence of bitstrings, rather than a concatenation of reasons
into a single bitstring. See Table 44.
Table 44: DataObject: Report (Unconfirmed)
Service: Report (Unconfirmed) MMS Services/Argument/Results Server Client Note

Request InformationReport
Report VariableAccessSpecification m m
Parameter = VariableListName
ListofData ListofData m m
Response
<none>
The log object maps to an MMS journal, with each LogEntry being represented as an MMS journal entry as
shown in Table 45.
Table 45: Mapping of LogEntry
Mapping of LogEntry
Attribute MMS Notes
ECBName EntryContent.eventCondition- m
Name
ECBState EntryContent.currentState m
TimeOfLog EntryContent.occurenceTime m
EntryIdentifier entryIdentifier m The INT32U shall be encoded into the MMS
OCTETSTRING per INTEGER encoding
ASN.1 rules. There shall be 4 OCTETS
encoded. Leading zeros shall not be sup-
pressed.
Constraint: o
ECBState=NO CHANGE
ListOfDataObjects EntryContent.variableTag m The variableTag shall be the name of the
CASM DataObject without the CASM scope
specification. The limit is 32 characters.
ListOfObjectValues Data N1
N1Shall be present if ListOfDataObjects is present.
The log services map to MMS is shown in Table 46.

Table 46: Mapping of Log Services
Service MMS Notes

GetLogControlBlock
Request GetVariableAccessAttributes.Request
Response GetVariableAccessAttribute.Response
SetLogControlBlock
Request Write.Request
Response Write.Response
CreateLogControlBlock

IEEE-SA
Table 46: Mapping of Log Services (continued)
Service MMS Notes

Request DefineNamedVariable.Request
Response DefineNamedVariable.Response
DeleteLogControlBlock
Request DeleteVariableAccess.Request
Response DeleteVariableAccess.Response
GetLogControlBlockNames
Request GetNameList.Request
Response GetNameList.Response
QueryLog
Request ReadJournal.Request See Table 47 for actual mapping
Response ReadJournal.Response See Table 47 for actual mapping
EmptyLog
Request InitializeJournal.Request See Table 47 for actual mapping
Response InitializeJournal.Response See Table 47 for actual mapping
Table 47 defines the detailed mapping of the QueryLog service to MMS.
Table 47: QueryLog Mapping to MMS
Mapping of QueryLog
Attribute MMS Server Client Notes
QueryLog.Request JournalRead.Request
LogName JournalName m m
TypeOfQuery m m Local issue to client but
constrained by LCB.Opt
RangeStart rangeStartSpecification m m
MMS rangeStartSpecification
Constraint: LCB.Opt(RECORD_ENTRY_SUPPORT) m m
RangeStart startingEntry m m
Constraint: LCB.Opt(TIME_ENTRY_SUPPORT)
RangeStart startingTime o o
RangeStop rangeStopSpecification m m
Constraint: LCB.Opt(RECORD_ENTRY_SUPPORT) m m
RangeStop numOfEntries m m
Constraint LCB.Opt(TIME_ENTRY_SUPPORT)
RangeStop endingTime m o
Constraint: LCB.Opt(DATA_ENTRY_SUPPORT)
DataObjectFilters listOfVariables m o
QueryLog.Response JournalRead.Response
ListOfLogEntries EntryContent m m
moreFollow moreFollows m m

IEEE-SA
Table 48 defines the detailed EmptyLog mapping to MMS.
Table 48: EmptyLog Mapping to MMS
Mapping of EmptyLog
Attribute MMS Server Client Notes
EmptyLog.Request InitializeJournal.Request m o
LogName journalName m m
InitializationRangeSpecification limitSpecification m m (ALL or PARTIAL)
Constraint: ALL
InitializationRangeSpecification NULL m o NULL represents that
limit specification is not
present.
Constraint: PARTIAL and
LCB.Opt(RECORD_ENTRY_SUPPORT)
InitializationRangeSpecification limitingEntry m o Specifies the EntryIdenti-
fier that is not to initialize
(e.g., x->n-1 is initial-
ized).
Constraint: PARTIAL and
LCB.Opt(RECORD_ENTRY_SUPPORT)
InitializationRange limitingTime m o Specifies the TimeOfLog
Specification up to which the LOG is to
be initialized.
EmptyLog.Response InitializeJournal.Response m o
ConfirmationOfInitialization InitializeJournal.Response m o Returns the number of
entries actually initial-
ized (INT32U).
Table 49 defines the mapping of the log control block to an MMS named variable.
Table 49: LCB Mapping
Mapping of LCB to MMS Named Variable

Name Type m/o
LCB Struct
LogEna m
LogNam IDENT m
FillLvl INT8U m
LogSize INT32U m
Status BSTRING5 m
Opt BSTRING4 m
EntNew INT32U m
EntOld INT32U m
NumEnt INT32U m
LstEntDisc INT32U m
OldTim BTIME6 o
NewTim BTIME6 o
LogWrp BOOL o
LogEnr<n> VSTRING64 m

Architecture (UCA )
TM
Version 2.0
Volume 2
Part 4:
UCATM Generic Object Models
for Substation and Feeder
Equipment (GOMSFE)
Published by


Palo Alto, CA, USA

Part 4: UCATM Generic Object Models for
Substation and Feeder Equipment (GOMSFE)
Prepared under the auspices of the Substation and Feeder Working Group of the MMS Forum and
the Sunstation Initiative Project.

plants
IEEE-SA
Acknowledgements
The following participated in the authorship and review process of this document:
Mark Adamiak General Electric

Alex Apostolov GEC Alsthom
Alan Backlund Dacscan, Ltd.
Ron Baiar Schweitzer Engineering Laboratories
Drew Baigent General Electric
Shelly Barczak Commonwealth Edison Company
William Blair Electric Power Research Institute
Stuart Borlase KEMA Consulting
Mark Bowers Triangle MicroWorks, Inc.
Klaus-Peter Brand Asea Brown Boveri
Mark Browning Commonwealth Edison Company
John Bruder SISCO
Christoph Brunner Asea Brown Boveri
Michael Buchholz SIEMENS
John Burger American Electric Power
Marty Burns Hypertek
Bruce Campbell GE Multilin
Frances Cleveland Utility Consulting International
Kay Clinard KEMA Consulting
George Chirco Powertec
Ken Cooley Tampa Electric Company
Tom Dalton Tamarack
Stephen Dalyai QEI
Mike Darnell Indianapolis Power & Light
Doug Dawson
Rudolph Dinges Asea Brown Boveri
Randy Ehlers Landis & Gyr
Phil Engel Cinergy
David Evans City Public Service, San Antonio
Herb Falk SISCO
Grant Gilchrist GE - Harris Distributed Automation Products
Richard Gloff Mid-America Interconnected Network, Inc.
Dan Gregory DCG Technologies
Erich Gunter Electrotek Concepts
Jim Harlow Harlow Engineering Associates
Glen Harmon Basler
Jochen Haude VEW
Randy Heuser SRS Technologies
Gary Hitzfelder City Public Service, San Antonio
Gary Hoffman GEC Alsthom
Jerry Hohn Indianapolis Power & Light
Dennis Holstein SRS Technologies
Magnus Holurgren Asea Brown Boveri
Frederick James City Public Service, San Antonio

IEEE-SA
PART 4: GOMSFE TR 1550-1999
Marco Janssen KEMA T & D Power, the Netherlands

Jerry Jodice Doble
Mark Kempker Indianapolis Power & Light
Frank Kendall KEMA Consulting
Charles Kinne Northern States Power
Dean Klas Schweitzer Engineering Laboratories
Jeny Koruth Commonwealth Edison Company
Steve Kunsman Asea Brown Boveri
Mike Lalli Landis & Gyr
Ajay Madhwesh Asea Brown Boveri
Mike Maloney EnergyLine Systems
Fidel Marquez Commonwealth Edison Company
John McDonald KEMA Consulting
Jeff McElray
Jerry Melcher Electric Power Research Institute
Gary Michel Consultant
Sandrine Monnier GEC Alsthom, T & D
Bruce Muschlitz Bitronics
Curt Nail SRS Technologies
Dan Nordell Northern States Power
Hank Painchaud Cooper Power Systems
Ivan Pedersen Dacscan, Ltd.
Mark Peschman Siemens
Marzio Pozzuoli GE Multilin
Michael Putt Tasnet
Harnek Randhana SRS Technologies
Jack Robinson KEMA Consulting
Bob Ryan Schweitzer Engineering Laboratories
Kevin Rysdahl Siemens
George Schimmel Tamarack Consulting, MMS Forum
Jim Schnegg American Electric Power
Karlheinz Schwarz SCC
Graham Scott General Electric
Vadim Shilko U.S. Power, Inc
Mark Simon Commonwealth Edison Company
Charles Sufana Commonwealth Edison Company
John Tengdin Consultant
Mike Timson IPT
Eric Udren Cutler Hammer
Bob Uluski KEMA Consulting
Don Ware Florida Power Corp.
Jim Whatley Ontario Hydro
David Wood Schweitzer Engineering Laboratories
Robert Woodward Doble Engineering Company
Shaw Kang Wu Asea Brown Boveri
Murty Yalla Beckwith

IEEE-SA
Introduction
The development of intelligent electronic devices (IEDs) resulted in effectively allowing for direct network
access to field devices, as well as more processing being performed at the end device. Within the Utility
Communications Architecture (UCA) framework, the definition of the data and control functions made
available by the device is known as the device object model.
The DeviceModels developed within the UCA Version 2.0 effort make use of a common set of services to
describe the communications behavior of the devices. A standard mapping of these services onto the UCA
application layer protocol (manufacturing message specifications, MMS), when used in conjunction with the
DeviceModels, completely specifies the detailed interoperable structure for utility field devices. The services
and mapping to MMS are defined in Part 3 of IEEE-SA TR 1550: UCA Common Application Service Mod-
els (CASM) and Mapping to MMS. The use of the CASM services within all UCA DeviceModels simplifies
the integration efforts across functional areas of the utility. An added benefit is that CASM allows Device-
Models to be specified independent of the underlying protocol. This protocol independence has encouraged
active participation of groups outside UCA activities, and will simplify migration through the construction
of gateways to older existing protocols, and allow for the future expansion of the UCA protocol suite to other
application protocols.

IEEE-SA
Contents
1. Overview........................................................................................................................... 4-1
1.1 Objectives .................................................................................................................. 4-1

1.2 Scope.......................................................................................................................... 4-3
1.3 Relationship to Other Documents ........................................................................... 4-3
1.4 Document Layout ..................................................................................................... 4-4
1.5 How To Use This Document ..................................................................................... 4-4
2. Overview of Classes, Objects, and Object Models .......................................................... 4-5
2.1 Introduction .............................................................................................................. 4-5

2.2 Standard DataTypes and Common Abbreviations ................................................. 4-6
2.3 Common Components............................................................................................... 4-6
2.4 Common Classes....................................................................................................... 4-6
2.5 Basic Building Bricks ............................................................................................... 4-7
2.6 Object Models............................................................................................................ 4-7
2.7 Object Model View of Inputs and Outputs .............................................................. 4-8
3. Naming Conventions and Data Object Class Design .................................................... 4-9
3.1 DataObject Naming................................................................................................ 4-10

3.2 Other Naming Conventions ................................................................................... 4-19
3.3 LogicalDevice Naming............................................................................................ 4-22
3.4 DeviceModel Naming ............................................................................................. 4-22
3.5 Description of Physical Quantities ........................................................................ 4-23
3.6 FunctionalComponent Groupings for Analog Measurements
and Controls............................................................................................................ 4-24
3.7 FunctionalComponent Groupings for Binary Controls ........................................ 4-25
4. UCA Standard DataTypes............................................................................................. 4-26
5. Common Component Definitions .................................................................................. 4-27
5.1 Common Components in Data Models .................................................................. 4-27
6. Common Class Definitions ............................................................................................ 4-49
6.1 DeviceIdentity (DI) ................................................................................................. 4-49

6.2 Functional Components ......................................................................................... 4-50
6.3 Measurements (MX) ............................................................................................... 4-52
6.4 Status (ST) .............................................................................................................. 4-55
6.5 Setpoints (SP) and Settings Groups (SG).............................................................. 4-55
6.6 Controls (CO) .......................................................................................................... 4-60
6.7 Configuration (CF).................................................................................................. 4-61
6.8 Description (DC) ..................................................................................................... 4-63
6.9 Report Control Blocks ............................................................................................ 4-64
6.10Event Control Block (ECB) .................................................................................... 4-68
6.11Log Control Block (LCB) ........................................................................................ 4-69
6.12Access (AX).............................................................................................................. 4-69
Copyright 1999 IEEE. All rights reserved. v

IEEE-SA
7.Basic Building Bricks ............................................................................................................ 4-69
7.1 GLOBE .................................................................................................................... 4-71

7.2 Basic Bricks ............................................................................................................ 4-80
7.3 Generic Input/Output............................................................................................. 4-92
7.4 Measurement Functions ........................................................................................ 4-97
7.5 Transformer Functions ........................................................................................ 4-102
7.6 Switch Functions .................................................................................................. 4-111
7.7 Reactive Functions ............................................................................................... 4-118
7.8 Protection Functions ............................................................................................ 4-120
8. Measurement Unit....................................................................................................... 4-135
8.1 Measurement Unit (MU)...................................................................................... 4-135

8.2 DataSets................................................................................................................ 4-138
9. Basic RTU Object Models............................................................................................ 4-138
9.1 Description and Application................................................................................. 4-138

9.2 Device Function .................................................................................................... 4-139
9.3 Basic RTU Object Model ...................................................................................... 4-140
9.4 DataSets................................................................................................................ 4-143
10. Transformer Object Models......................................................................................... 4-143
10.1 Load Tap Changer Controller Object Model....................................................... 4-143

10.2 Description and Application................................................................................ 4-143
10.3 Device Function ................................................................................................... 4-144
10.4 Functional Component Descriptions .................................................................. 4-144
10.5 DataSets ............................................................................................................... 4-158
11. Switch Object Model .................................................................................................... 4-159
11.1 Switch Controller Object Model .......................................................................... 4-159

11.2 Automated Switch Controller Object Model....................................................... 4-161
11.3 Circuit Breaker Controller Object Model ........................................................... 4-164
11.4 Recloser Control Object Model............................................................................ 4-167
12. Reactive Component Object Models ........................................................................... 4-170
12.1 Capacitor Bank Controller Object Model ........................................................... 4-170

12.2 DataSets ............................................................................................................... 4-173
Appendix A: Example Mapping of a GOMSFE CapC Model To MMS ................................ 4-174
Appendix B: Glossary/Acronyms ........................................................................................... 4-186
vi Copyright 1999 IEEE. All rights reserved.

1. Overview
1.1 Objectives
This Part 4 of IEEE-SA TR 1550 defines generic object models that provide communications interfaces for
equipment in electric utility transmission and distribution substations as well as distribution feeders. These
models have been defined using the UCA Common Application Service Models which allow their mapping
to various underlying communications technologies.
It is expected that suppliers of equipment that supports the UCA object models defined in this document will
adapt these generic models by adding specific customizations to reflect their individual innovations. It is fur-
ther expected that these models could be extended to other areas of the electric utility (and to other utilities
such as water and gas), although the groups contributing to their development did not reflect that focus.
This Part 4 is intended to facilitate vendors in implementing the UCA substation and feeder elements of the
power system object model (PSOM) into a product design. Figure 1 illustrates the core PSOM used in the
UCA 2.0 Substation Integrated Protection, Control, and Data Acquisition Requirements Specification. The
PSOM was used to model the representation of substation field equipment, for the identification and devel-
opment of communication and performance requirements, and the generic services required for
communicating with substation field equipment. It does not describe the mapping of the objects onto the
application layer; this is the function of Part 3 of IEEE-SA TR 1550, Common Application Service Models
and Mapping (CASM) to MMS.
Controller
controllerID
m operatingParameters 1,m
m configurationParameters
state
Measurement 1
setAttribute
measurementID getAttribute Log
measurementParameter initialize
measurementDescription logID
reset logType
measurementScaleFactor connect
measurementOffset disconnect logItem
measurementAccumulatorValue monitor deleteItem
measurementAnalogValue report report
measurementTime
measurementQuality
setAttribute
getAttribute
1 m
VirtualDevice
m deviceID
m deviceOwner 0,m
deviceType
MeasurementUnit deviceDescription 1
measurementUnitID deviceFunctionNumber
configurationParameters Tag
deviceNameplate
operatingParameters circuitVoltage tagID
setAttribute deviceRating tagType
getAttribute tagTypePermitted tagDescription
calibrate activeTagArray createTag
convert setAttribute removeTag
sample getAttribute placeTag
Figure 1: Core Power System Object Model (PSOM)
Figure 2 illustrates a conceptual model of the communications server as represented by CASM. Part 4
(GOMSFE) defines the generic object models for communicating with field devices that are shown in the
CASM conceptual model.

IEEE-SA
CASM Classes for Modeling Devices
Server LogicalDevice DeviceIdentity DeviceModel FunctionalComponent DataObject DataSet
Server@<address>
R1234 DI
AllValues Other
RTU RTU.MX.ACS1.i Models and

RTU.MX.ACS2.i Services
RTU.CF
RTU.CF.ACS1 RTU.MX.ACS3.i
RTU.CF.ACS1.d
RTU.MX
RTU.MX.ACS1
RTU.MX.ACS1.i
RTU.MX.ACS1.t

Object s representing devices through

communications are instance s of
CASM Class es
Figure 2: CASM Device Modeling Classes and Their Relationship to Objects
Figure 3 illustrates the relationship of GOMSFE and CASM. GOMSFE provides the standard interface defi-
nition for the outside world to communicate with field device controllers and their representation of the field
devices. This figure depicts the GOMSFE 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.
GOMSFE
USER
CASM
CLIENT
CASM
FIELD DEVICE
CONTROLLER
SERVER
Figure 3: UCA 2.0 Common Application Services Model (CASM)

IEEE-SA
GOMSFE models the logical DeviceModels that are contained by the remote server, using the functional
components outlined in CASM. In constructing the LogicalDevice, several GOMSFE models may be con-
tained in a single LogicalDevice. Figure 4 illustrates the relationship of the GOMSFE object models with the
PSOM models.
CASM PSOM
B123
DI TOD Clock Controller
GOMSFE Object Models
BkrC
MU
IOC
TOC
Virtual Device
RecR
Dist_1
Dist_2
Dist_3
Data Sets Logs
Figure 4: GOMSFE Relationship with PSOM
The GOMSFE models were developed by combining models from various EPRI projects, the Substation
Initiative, and many other organizations and individuals.
1.2 Scope
This document 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.
1.3 Relationship to Other Documents

This document references other documents as follows.
1.3.1 EPRI Reports and Documents
EL-7547 (1991), Utility Communications Architecture (UCA) Version 1, Volumes 1 through 6.

These documents describe the initial requirements and specifications for UCA.

IEEE-SA
EPRI RP3599, Substation Integrated Protection, Control, and Data Acquisition, Requirements
Specification. This document defines a conceptual model and performance requirements for intelli-
gent electronic devices (IEDs) in substations.
UCA Version 2.0, Part 3: Common Application Service Models (CASM) and Mapping to MMS,
1999
1.4 Document Layout

This document presents the build-out of generic object models according to the hierarchy represented in Fig-
ure 5. The modeling process is based on the definition of standard, reusable, basic building blocks of objects
and models to add further levels of functional detail and specification. The objects and object components
are represented by standard types of data definitions. The objects and models are defined at the most simpli-
fied and common classification level to allow the construction of widely varying models. Some basic, stan-
dard device and application models are defined in this document as a guideline. Any other function or
application can be modeled using the objects defined in this document.
Logical Field Device Object Models
Basic Building Bricks
FunctionalComponents
Common Classes
Common Components
Standard DataTypes
Figure 5: Object Model Build-Out
1.5 How To Use This Document

The basic, common objects used for modeling substation and feeder protection, control, and data acquisition
are defined in this document. These objects are given machine readable names using standard abbreviations.
The client or user may use any name or language desired in developing their Human Machine Interface
(HMI) or Man Machine Interface (MMI). Vendors may also use any names desired within their products.
The GOMSFE object names, however, must be used at the communications interface. Vendor extensions to
the models may be made following the required GOMSFE model. The requirements and performance of the
communication of these objects are specified in the RP3599. The objects are mapped onto generic services
of the application layer using Part 2 of IEEE-SA TR 1550: CASM. CASM provides a generic application
layer service platform for communications throughout the utility architecture. CASM is mapped onto the
application layer protocol services specified by UCA for the particular application. Part 2 of IEEE- SA TR
1550 defines a set of communication profiles (protocol stacks) to support the application layer.

IEEE-SA
2. Overview of Classes, Objects, and Object Models
2.1 Introduction
This section covers basic techniques for class-object model construction, and defines the class-object
hierarchy.
2.1.1 Problem Domains
A problem domain is the application or process that is being modeled by object oriented representation
(classes and objects), e.g., protection, control, and data acquisition of substations and feeders in electric
utilities.
Data abstraction is the process of identifying data in the classes and objects to satisfy the behavior of the
problem domain.
Encapsulation is the definition of the components (or attributes) and services in the classes and objects to
appropriately capture the information and behavior, hide the implementation of the object, and restrict
access to the information of the classes and objects.
Polymorphism is the use of the same service name to interface with multiple objects. Polymorphism allows
the viewing of similar objects through a common interface.
2.1.2 Classes and Objects
A class is a template for the creation of objects. A class is the description of one or more objects with the
same definitions for information and behavior. A class itself may be an object.
An object is an abstraction of entities and functions in a problem domain. The object represents information
(components) and behavior (services) of the entity, i.e., encapsulation. An object is referred to as an
instantiation of a class.
An instance (or the process of instantiation) is the creation of an object from its class. The class defines the
information and behavior of the instance, while the current state of the instance is defined by the operations
performed on the instance. Each instance has a unique identity. For example, vehicle could be defined as a
class, with Ford and Chevrolet as instances (object instantiations) of the class.
Class-object is a term referring to the class and the possible object instantiations of that class. Components
(or attributes) represent the information and state of the class-object. A component is a data element. Ser-
vices represent the behavior of the object. Services are invoked by another object via messages.
2.1.3 Connections
An instance connection represents the mapping, or the association, of object data required to fulfill the
responsibilities of the problem domain. An object is said to be associated with another object by an
instance connection. Instance connections are related to the components of the object.
A message connection models the processing dependency of object services to fulfill the responsibilities of
the problem domain. A message connection is the mapping of one object to another object in which a sender
transmits a message to a receiver to execute some processing on the components. The required processing is

IEEE-SA
defined in the services of the object. Message connections are related to the services of the object and exist
solely for the benefit of the services of the object.
Instance connections and message connections model a specific problem domain. The same objects may be
used with different instance and message connections to model other problem domains. However, the hierar-
chy and inheritance of objects remains the same. There may be additional, different specializations of
objects for modeling other problem domains, but the object hierarchy remains the same.
2.1.4 Inheritance and Structures
Inheritance is a mechanism for expressing the commonality among classes in the problem domain structure.
This allows the simplification of classes based on classes already defined. Inheritance allows the common
components and services to be defined once, as well as specialized and extended into specific classes and
objects in the structure. The object hierarchy represents the class and object structure and inheritance for the
problem domain.
Hierarchy and inheritance is determined by two main types of mechanisms: generalization-specialization,

and structures. Generalization-specialization (Gen.-Spec) distinguishes between classes with the specializa-
tion being a type of the generalization (e.g., truck is a type of vehicle). Structures distinguish between
classes with physical or functional parts or components. Essentially, the Gen.-Spec and structures organize
and describe the complexity of the object model.
2.2 Standard DataTypes and Common Abbreviations

Standard DataType defines how the component values of all possible class-objects are represented. The stan-
dard DataType determines the format, the number of bits to communicate the value, and the range of possi-
ble values. (e.g., an unsigned 8-bit integer is defined as INT8U.) Standard DataTypes are the lowest common
denominator of the object definitions and hierarchy. The common abbreviations are used for constructing
concise names.
2.3 Common Components

Common components represent the elementary components used in the class-object definitions. The names
for common components are constructed from common abbreviations. Definition of these common compo-
nents allows them to be defined only once in the document, and then listed under the common class defini-
tions. Any changes in the common components therefore apply to all of the common classes. The list of
common components represent the minimum set of components to define the common classes. An example
of a common component is b, which represents a binary value with a data type of BOOL.
2.4 Common Classes

Common classes are groups or structures of components. The components are named variables associated
with data represented by the common classes. The components are specified according to the standard
DataTypes. Common classes represent the commonly used class-objects. AI is an example of a common
class used to define an analog input.

IEEE-SA
2.5 Basic Building Bricks

Basic building bricks are standardized reusable groupings of associated DataObjects that address a focused
function or use.
2.6 Object Models

Object models are specialized groupings of associated bricks that model devices, functions, or applications
of a specific function or application in the problem domain (i.e., protection, control and data acquisition).
The field device object models provide examples of an elementary modeling of the device function or appli-
cation. Many variations to the model are possible. Therefore, the object models are intended as guidelines to
commonly agreed functions and applications. Varying degrees of definition and application are not the scope
of this document, and will depend on the each users requirements and modeling preferences in their prob-
lem domain. Higher level and more detailed application models, such as Volt/VAr control, are essentially
groupings of several object models, i.e., capacitor bank control, tap changer control, switch control, etc.
These higher level application models are left to the user to implement according to the users specific
requirements.
Each field device object model includes a description of the field device function or application, a functional
block diagram, and the object model. The object model uses the class-object hierarchy and association
(instance connections) of the class-objects to define and describe the model function.
An object model is a model of a device function or application that receives control commands (binary and
analog), setting changes (binary and analog), and indication data (binary and analog) from other objects. The
object model maintains relevant data, such as configuration parameters, settings (binary and analog), and
indication data (binary and analog). The object model outputs control commands (binary and analog) and
indication data (binary and analog).
For example, when referring to a breaker object model, only the physical breaker device (power system field
equipment) is modeled using inputs and outputs associated with the physical device only, such as status.
When referring to a breaker control object model, the breaker controller object and the breaker (power sys-
tem field equipment) object are used with inputs and outputs associated with the control of the breaker, such
as measurements and control.
2.6.1 Object Model Components
Configuration parameters are values that determine the setup of the device and are not expected to change
often. Configuration parameters are usually changed when the operating environment of the device has
changed, the monitored system has changed, or the device has been relocated to another part of the system.
Configuration parameters can be read and written to, but can only be changed by authorized users or other
devices. Configuration parameters include:
Any data type (visible string, bit string, etc.)

Binary values
Analog values
Settings are values that determine the operation of the device and can change often. Settings are usually
changed when operating conditions change. Settings can be read and written to, but can only be changed by
authorized users or other devices. Settings include:

IEEE-SA

Binary values
Analog values
Operation represents the actual output decisions or commands of the model to perform its functions. These
may be binary or analog (setpoint) outputs. Operations include:
Binary control
SetPoints (analog values)
Status represents the indications or values directly concerned with the function of the device. Status values
are usually (but not always) on-off, set-not set, or true-false types of indication analogous to mechanical or
LED indications on devices. Boolean status values may be grouped into bit string. Status values are only
necessary for interaction with other objects and devices in the problem domain. These parameters are gener-
ated by the device, but are not values internal to the algorithms or processes of the device that are considered
proprietary by the manufacturer. Status values include:
Binary status values (Boolean or bit string)

Analog values
Associated parameters are values that are associated with the function of the model. These parameters are
only necessary for interaction with other objects and devices in the problem domain (i.e., values and indica-
tion for other objects and devices). These parameters may be calculated within the device or obtained from
other objects in some form, but are not values internal to the algorithms or processes of the device that are
considered proprietary by the manufacturer. Associated parameters can also be referred to as
pseudopoints. Associated parameters include:

Status values
Analog values
2.7 Object Model View of Inputs and Outputs

The sections that follow present field device object models based on the common elements and building
blocks presented in Sections 3 and 4. The object model perspective of Ins and Outs is taken from the net-
work port view of the IED.
2.7.1 Network Discrete (Binary) Inputs and Outputs
In general, IEDs will have discrete two-state isolated inputs connected to external field contacts such as
breaker auxiliary switches, control switch contacts, etc. These are physical inputs that may be used locally
within the IED and/or passed through to the LAN via the IEDs communication port for use by other IEDs in
the system. IEDs may also generate pseudo or virtual inputs as a result of intermediate internal states or
processes. In typical usage, these are functionally similar to physical inputs and may also be used locally
and/or passed through to the LAN.
Binary ins are defined as any two-state variable representing the state of a physical input to the IED or a vir-
tual input generated within the IED sent into the LAN out from the IED LAN interface port. Virtual digital
inputs are identified by means of a configuration flag.

IEEE-SA
IEDs will also have discrete two-state outputs in the form of isolated contacts and/or solid state semiconduc-
tor devices that will be connected to external devices, such as circuit breaker trip and close coils, transformer
tap changer raise/lower control circuits, etc. IEDs may also receive pseudo or virtual outputs that are used to
change or modify the internal state of the IED, without any direct reference to a physical output. In both
cases, these outputs are received from the LAN and used locally in the IED.
Binary outs are defined as any two-state variable representing the state of a physical output from the IED or
a virtual output to be used within the IED sent out from the LAN into the IED LAN interface port. Virtual dig-
ital outputs are identified by means of a configuration flag.
2.7.2 Network Analog Inputs and Outputs

In general, IEDs will produce direct analog representations (numerical) of various time-varying physical
input sources, such as current transformers, voltage transformers, thermocouples, etc., IEDs will also pro-
duce computed values of analog data based on internal processes, for example, metering information. Either
type of analog quantity, either based on a physical or virtual input, may be used locally within the IED and/
or passed through to the LAN via the IEDs communication port for use by other IEDs in the system.
Analog ins are defined as any numerical quantity representing the state of a physical input to the IED or a
virtual input generated within the IED sent into the LAN out from the IED LAN interface port. Virtual analog
inputs are identified by means of a configuration flag.
IEDs may also have physical analog outputs, typically implemented with semiconductor circuits capable of
producing a time-varying signal such as a low-level current loop (0-1 ma, 4-20 ma, etc.) IEDs will also have
virtual analog outputs used to change or modify the internal IED process, such as setpoint data. In both
cases, these outputs are received from the LAN and used locally in the IED.
Analog outs are defined as any numerical quantity representing the state of a physical output from the IED or
a virtual output to be used within the IED sent out from the LAN into the IED LAN interface port. Virtual
analog outputs are identified by means of a configuration flag.
3. Naming Conventions and Data Object Class Design

Naming strategy has an inherent tradeoff. The names want to be verbose for the purposes of allowing ease
of understanding by nontechnical and technical personnel. The names want to be concise so that when trans-
lated into MMS mapping, the minimum reasonable bytes on the wire are required.
In addition, it is desirable to make the names in a modeling document identical to names that will appear in
a program. The reason for this is to reduce the transposition of information in the model document to com-
puter programs. Instinct may say that the programmer needs no such protection, as the programmer is tech-
nically competent to get naming in programs right. However, experience has shown that this process is
exceedingly error prone. In addition, the same terms will appear in many documents and cross-references.
For this reason each name should be a unique variation.
Since there is a necessary description for each component anyway, standardized names must be kept terse,
allowing for expansion of meaning in the description provided.
Finally, terse naming of components and types is valuable for the reader of modeling documents since the
information commonly appears in tabular form. The reduced size in number of characters facilitates this pre-
sentation form.
When a description is provided, a maximum of 64 characters should be used to facilitate the eventual display
user interfaces.

IEEE-SA
The balance of this section describes recommended conventions for naming of the CASM classes and their
object instances.
3.1 DataObject Naming

There are three general rules for DataObject naming:
a) Capitalization: In general, when acronyms are developed and a single letter is used to represent an
abbreviation, the letter is capitalized. If multiple letters are used to represent a single word, only the
first letter is capitalized. There are a few exceptions to the rule, made at the sole discretion of the
GOMSFE editor in distinguishing the names of various models and common classes.
b) Name length: The maximum lengths (excluding delimiters) of various GOMSFE name convention
and components are listed in the table below. When combined with single delimiters between the
various name components, the maximum total name length is 32 characters.
c) Names: The intention is for a DataObject or component name to have one and only one meaning,
(i.e., no duplicate names with different meanings).
GOMSFE Maximum Number

Naming Component of Characters
5 (1 is reserved for multiple
Model name
instances of models)
Functional component 2
DataObjects 12
Common class components 10
3.1.1 DataObject Naming: Base Names
While the correct operation of the CASM services does not depend on strict naming conventions, the follow-
ing guidelines are used when defining DeviceModels for use with CASM:
Each standardized name should be written using upper/lower case boundaries as opposed to spaces
or underscores. The elimination of spaces preserves the ability to use the names directly in pro-
gramming. The use of upper/lower case boundaries instead of underscores reduces the number of
bytes on the wire by one for each use. Concise nomenclature is desired because some transport
mappings will use the names in the message and this effects bandwidth.
Each standardized name can be used only once, independent of the position the name may have in
an aggregation/hierarchy/structure. This preserves the future possibility of canonical addressing
which substitutes unique numbers for names in allowing for lossless compression of named binding
and thus bytes on the wire. This means that the same name, wherever it is used in a DataObjects
structure, must always represent the same thing. This means that V cannot be voltage in some
uses and vapor pressure in others. It is useful to have, however, MX.V and CF.V. In this case V
appears in different DataObjects, but still represents the same classification of information. In fact it
serves to associate two related but independent pieces of information about the same thinga volt-
age, V.
Single character names are reserved for the most basic and often used common DataObjects, such
as i for integer value, u for units, etc.
Do not use $ (dollar sign) or _ (underscore) or other delimiters in standardized names since
they may not translate easily in some application layers.
Names with three or fewer characters are reserved for standardization by standards bodies.

IEEE-SA
3.1.2 DataObject Naming: Suffixes (Inheritance)
The ability to recognize the derived nature and reuse of common DataObjects is valuable from the stand-
point of applications programming. Therefore, CASM provides a way to represent it and transport the infor-
mation. This is part of the self-description requirement.
Similar to C++, the CASM naming convention uses the colon, :, as a separator for describing inherited base
classes. Any DataObject that is based on a previously defined DataObject can advertise this fact by using this
notation. Thus, any client that knows the rules for using the base class (the previously defined one) can
directly apply those rules to the new DataObject (up until the point where the new class has extended the
base class). This can include the known set of component names, as well as rules of use and range of values
for them.
For convenience in messaging, these suffixes are not required. The previous naming convention guarantees
that the names of DataObjects are unambiguous. They are only returned during use of self description meth-
ods, GetDataObjectAttributes as part of the self-description of the DataObject.
3.1.3 CASM DataTypes
The following names are used for CASM DataTypes. DataTypes can be used to describe the class of a single
element DataObject. Note that they are always written using all capital letters:
BOOL, BSTR2, BSTR8, BSTR16, BSTR32, BSTRn, INT8U, INT16U, INT32U, INT8S, INT16S, INT32S,
FLT32, FLT64, BSTR16, VSTR32, VSTRn, OSTRn, BTIME4, BTIME6, ENUM8, ENUM16, IDENT,
STRUCT, BLOB
In addition, if the DataType is ARRAY[i][j][k] of <TYPE>, it would be written as <TYPE>[i][j][k]. For

example, an array of 16 signed integers of 16 bits would be INT16S[16]. A two dimensional array 16 2
of 32-bit precision floating point numbers would be FLT32[16][2].
3.1.4 Specifying Class and Type Definitions
This section summarizes how to specify CASM DataObject classes and data types for presentation in
DeviceModel documents.
3.1.4.1 Primitive DataObject Classes
Specify a name, description, and DataType using the standard UCA DataType names. Limit description to
64 characters to facilitate display in fixed-width user interfaces.
DataObject Name Description DataType

AnewDO What about this new DO BOOL
3.1.4.2 Structured DataObjects Classes
Specify a name for the class, the components of the structure, and whether each sequential element is man-
datory or optional by default. This mandatory or optional declaration can be overridden in derived classes
and is specified only for the default case. The components of the structure must have been previously defined
in the document or a referenced document. It is best to organize the components such that recommended
mandatory components occur at the beginning of the list.

IEEE-SA
When the structured DataObject is derived from a previously defined DataObject (inheritance), specify a
name for the class, followed by a :, followed by the base class (repeat the : base class sequence if the base
class is also derived). List the components of the structure and whether each sequential element is mandatory
or optional by default. This mandatory or optional declaration can be overridden in derived classes and is
specified only for the default case. The components of the structure must have been previously defined in the
document or a referenced document.
<NewClass>:<baseclass>[:<baseclass>]
*
description
Component Name Default
component1 m
component2 m
component3 m
component4 o
3.1.5 Enumeration Allocation and Naming
Use enumerations for DataObjects for which there is one and only one selection of choices to be repre-
sented. Use bit strings when a set of choices (i.e., more than one at a time is possible).
All enumerated types reserve the value zero (0) for future definition. Each additional positive value should
be defined with a less than 64 character string that can describe the enumerated value in a display or table.
This is so that these strings can be easily displayed in a fixed-width display on some user interface.
Positive enumerated values are reserved for standardization. Negative enumerated values are available to the
vendor for customization. The table below can be used as a template. The enumerated values representing
<Type> are:
Integer Value <Type>

1 Describe what one means
2 Describe what two means
3 .
4 .
3.1.6 Bit String Bit Allocation and Naming

Use bit strings when a set of choices (i.e., more than one at a time) is possible. Use enumerations for
DataObjects for which there is one and only one selection of choices to be represented.
All bit strings (BSTR8, BSTR16, ) reserve bit (0), the first bit for use in protocol translations. Each addi-
tional bit can be defined with a less than 64 character string that can describe the enumerated value in a dis-
play or table.
The table below can be used as a template. The bits representing <Type> are:
Bit Number Bit Description

1 Describe first bit
2 Describe second bit
3 .
4 .
57 Unassigned (future use)

IEEE-SA
3.1.7 Common Abbreviations for Forming Concise Names
Table 1 lists abbreviations used in constructing compound names of DataObjects. They are chosen to
allow for relatively short, yet expressive terminology. For example, using the table, a reasonable name for a
software revision DataObject might be SftRev.
Table 1: Common Abbreviations
Abbr Term
A Ampere
Abbr Abbreviation
Acc Accumulator
Acs Access
Act Active
Actn Action
Adr Address
Alm Alarm
Alw Allowed
Amb Ambient
An Analog
Ang Angle
App Applications
Ar Arrestor
Arc Arcing
Arr Array
Auto Automation
Avg Average
Batt Battery
Bctr Bandcenter
Bef Before
Blind Blinder
Blk Block, blocking
Bot Bottom
Buf Buffer
Bwid Bandwidth
Cal Calculated
Cap Capacitance
CapB Capacitor bank
CapC Capacitor bank controller
Char Characteristic
Chg Change
Circ Circulating
Ckt Circuit
CB Circuit breaker
Class Class
Cld Cold
Cls Close

IEEE-SA
Table 1: Common Abbreviations (continued)
Abbr Term
Cmd Command
Cnd Condition
Cns Constraint
Cnt Count
Coef Coefficient
Comb Combustible
Comm Communications
Comp Compensate
Con Connected
Cond Conductor
Conf Confidence
Consv Conservator
Cont Continuous
Crv Curve
CT Cur transformer
Ctl Control
Cur Current
Dat Data
DC Direct current
Del Delay
Den Density
Desc Descriptive
Dev Device
DF DevFct
Diel Dielectric strength
Diff Difference/differential
Dir Directional
Dis Disable
Disc Discrepancy
Diss Dissipation
Dist Distance
Dmd Demand
Dn Downed
DOW Day of week
DrO Drop out
DS DevSt
Dsch Discharge
Dst Destination
Dur Duration
Ena Enable
Enr Enroll
Ent Entry
Evt Event

IEEE-SA
Abbr Term
Ex Exchanger
Fact Factor
Fail Failure
Fct Function
Fld Field
Flg Flag
Flt Fault
Flw Flow
Fmt Format
FPF Fwd Pwr Flow
Frz Freeze
Fund Fundamental
Fwd Forward
Gas Gas
Grp Group
Ha Harmonics
Hdw Hardware
Hi High
Hrs Hours
Hum Humidity
Hyst Hysteresis
Hz Frequency
Id Identity
Img Image
In Input
Incr Increment
Ini Initiate
Ins Inside
Int Interval
Intg Integrity
Intlk Interlock
Intp Intertap
Inv Inverse
IOC Instantaneous over current
Kno Knowledge
L Lower
Lat Latch
LodCtr Load center
Ld Lead
LDC Line drop compensation
Leak Leakage
Len Length
Lev Level

IEEE-SA
Abbr Term
Lg Lag
Lin Line
Lmt Limit
Lo Low
Loc Location
Lod Load
Lst List of
M Main
Mag Magnitude
Maj Major
Max Maximum
Mdl Model
Med Medium (physical)
Min Minimum
Mnr Minor
Mot Motor
MR MxRef
MT MxTyp
Mtr Meter
Mult Multiplier
Mx Measurement
Na Name
Neg Negative
Neut Neutral
New Newest
Num Number
Nxt Next
OC Over current
OD OperDev
Off Off
Ofs Offset
Old Oldest
On On
Oper Operate
Opt Option
Optl Optional
Ots Outside
Out Output
OV Over voltage
Ovr Overflow
Own Owner
Pa Partial
PA Preventative autotransformer winding

IEEE-SA
Abbr Term
Par Parameters
Pct Percent
Pd Period
PF Power factor
Pfd PwrFlw direction
Phs Phase
Pk Peak
Pls Pulse
Po Polar coordinates
Pos Position
Posi Positive
Pres Pressure
Pri Primary
Pro Protocol
Prs Present
Pt Point
Pu Pickup
Pw Password
Pwr Power
Qu Quality
Quad Quadrilateral
Quan Quantity
R Raise
Rat Ratio
Rch Reach
React Reactive
Rec Reclosing
Recl Recloser
Rect Rectangular coordinates
Red Reduction
Ref Reference
Reg Regulation (%)
Rem Remote
Res Resistance
Rest Resistive
Req Required
Rev Revisions
Rnbk Runback
RPF Rvs pwr flow
Rpt Report
Rs Reset
Rtg Rating
Run Running

IEEE-SA
Abbr Term
Rvs Reverse
Rx Receive
SBO Select before operate
Sched Schedule
Se Series
Sec Secondary
Sel Select
Seq Sequence
Ser Serial
Set Set
Sft Software
Sg Surge
Sh Short
Slp Slope
Smp Samples
Src Source
St Status
Start Start
Stop Stop
Sub Substation
Sup Supply
Sus Sustained
Sw Switch
Sync Synchronizer
Sys System
Tag Tag
Temp Temperature
Ter Tertiary
THD TotalHarmonic distortion
Thre Threshold
Tim Time
Tmr Timer
Tot Total
Trfr Transfer
Trg Triggers
Torq Torque
Trp Trip
Tst Test
Tx Transmit
Txf Transformer
Typ Type
U Upper
Uneq Unequal

IEEE-SA
Abbr Term
Unit Unit
Unk Unknown
UPF Unk pwr flw
Use Usage
UV Under voltage
V Volts, voltage
VA VoltAmps
Vac Vacuum
VAr VAr
Vec Vector
Vnd Vendor
VR V regulator
VRed V reduction
VT Voltage transformer
W Watt
Wrn Warn
Wrp Wrap
Z Impedance
3.2 Other Naming Conventions
3.2.1 Specifying Class and Type Definitions

This section summarizes how to specify CASM DataObject classes and DataTypes for presentation in
DeviceModel documents.
3.2.1.1 Primitive DataObject Classes
A name, description, and DataType are specified using the standard UCA DataType names. In addition, if
the DataType is ARRAY[i][j][k] of <TYPE>, it would be written as <TYPE>[i][j][k]. For example, an array
of 16 signed integers of 16 bits would be INT16S[16]. A two dimensional array 16 2 of 32 bit precision
floating point numbers would be FLT32[16][2].
3.2.1.2 Structured DataObjects Classes
A name for the class, the components of the structure, and whether each sequential element is mandatory or
optional by default are specified. This mandatory or optional declaration can be overridden in derived classes
and is specified only for the default case. The components of the structure must have been previously defined
in the document or a referenced document.
3.2.1.3 Derived DataObject Classes (inheritance)
A name for the class is specified followed by a :, followed by the base class (repeat the : base class
sequence if the base class is also derived). The components of the structure are listed, and whether each
sequential element is mandatory or optional by default. This mandatory or optional declaration can be over-
ridden in derived classes and is specified only for the default case. The components of the structure must
have been previously defined in the document or a referenced document.

IEEE-SA
3.2.2 References to DataObjects
Naming of classes and components allows easy reference to the data by users and clients of the object
model, specifically in terms of the user interfaces and human configuration of the IEDs and communications.
The actual implementation of the naming scheme is left to the implementors or vendor of the client. The
implementors or vendor may decide to use index referencing once the system has been configured.
The naming of classes and components corresponds to the logical hierarchy reflected in the names of the
standard DataTypes and common classes. A component name must be assigned to all elements that are avail-
able for communications (i.e., any component that is to be read from, or to be written to).
Access to names is hierarchical starting with the common class name and adding each lower level name until
the data component is defined. Each class and component is separated using a period .. If a component is
optional and not available in a class, any reference to that component will cause a read response error.
When referring to a logical device instance containing an instance of a DeviceModel, a forward slash / is
used to separate the name of the Logical Device instance and the instance of the DeviceModel in the naming
convention, and periods are used to separate the names of the contained objects and components in the same
object.
A high level of hierarchy is defined using FunctionalComponents. FunctionalComponents define functional

groupings of classes to allow easier access to the classes in the functional group. Access to the classes in
functional group uses the FunctionalComponent name:
LogicalDevice name/DeviceModel name.FunctionalComponent name
To access complete common class derived objects, only the common object name is used:
LogicalDevice name/DeviceModel name. FunctionalComponent name.Common Object name
In this case, all of the components in the class would be returned with a read.
To access specific components, the name referenced would correspond to:
LogicalDevice name/DeviceModel name.FunctionalComponent name.Common Object name.Compo-

nent name
For example, the AI (analog input) class in the load tap changer control (LTCC) model may be instantiated
as LodA. AI is the common class name, and LodA (load amperes) is the name of the derived class instan-
tiated in the LTCC. In the LTCC case, where this instance of the LogicalDevice, Fdr1, the access would be:
Fdr1/LTCC.MX = all measurements for the specific LTCC on feeder 1

Fdr1/LTCC.MX.LodA = only one measurement, the LodA of the specific tap changer on feeder 1
(the LodA object is of the common class AI)
In order to access the actual common component (element/attribute) of i (the actual integer
value), it is necessary to use Fdr1/LTCC.MX.LodA.i (the LodA object is of the common class AI,
and i is the common component name)
3.2.3 Naming of Measurements
The naming of measurements, such as voltage, pressure, temperature, etc., is a common focus of the device
modeling process. To enable a degree of common approach, the following naming convention supports the
unique naming of measurements with commonly specified auxiliary information.

IEEE-SA
For example, electrical systems may have either single or multiple phases. When looking at a single phase,
the values of voltage and power are relative to neutral, or to another phase, except when referring to neutral,
in which case it is relative to ground. When the measurement is relative to another phase, the two phases are
part of the name, termed here the measurement reference. The generic naming convention for these measure-
ments is represented by the concatenation of a series of abbreviated fields (< > is component of name, [ ]
means optional):
[<measurement type>] [<measurement location>][< measurement reference>]<quantity>
where [see below]:
3.2.3.1 Measurement Type
Pres (present), Max (maximum), Min (minimum), Pk (peak), etc.
3.2.3.2 Measurement Location
Location of a measurement relative to the device it is attached to when there is more than one choicePri
(primary), Sec (secondary), Lod (load), Ots (outside), Ins (inside), Src (source).
3.2.3.3 Measurement Reference
Optional phase or named selection of measurements when more than one phase, for example, is available
G, N, L1, L2, L1L2, A, B, C, AB, AC, BC etc. For electrical measurements, if only a single phase is named
and the measurement is a two point measurement (such as voltage), the neutral conductor, N, is assumed as
the default reference.
3.2.3.4 Quantity
A name representing the physical quantity being measured V (volts), A (amps), W (watts), VA (volt
amps), VAr (volt amps reactive), T (temp), Pres (pressure).
For example, the integer value for voltage on the primary of a three phase transformer between the A and B
phases would be:
PriV.PhsABi
The floating point minimum reactive power measurement in VAr between phase C and neutral is:
MinPriVAr.PhsCf
The integer value for peak power measurement in between phase L1 and N on a transformer primary is:
PkPriVA.PhsAi
The ambient temperature is:
The primary discharge pressure is:
PriDschPres

IEEE-SA
3.2.4 Description of FunctionalComponents
Finally, when all DataObjects are defined, they are assembled into FunctionalComponent groupings to
present the finished DeviceModel. Table 2 can be used as a template.
Table 2: Device Model Organization
Device Model Definition : <Name>

Class
FC Object name m/o rwec Description
(DataType)
WYE
MX V.PhsAi m A phase voltage required
(STRUCT)
WYE
A.PhsAi o A phase current, optional
(STRUCT)
ACF
CF V.PhsA m Configuration of A phase voltage
(STRUCT)
.
.
3.3 LogicalDevice Naming

Each server within a network can represent multiple logical devices, each of which implement one or more
DeviceModels. A LogicalDevice (LD) within a server is identified by the LDReference name. LD reference
must be unambiguous within a server. It is also recommended that LDReference names be unique within the
scope of the network and use only the limited alphanumeric character set that includes (a-z, A-Z, 0-9, and
_). It is recommended that LDReference names be definable at the time of installation rather than at time of
manufacture, so that network uniqueness can be achieved.
One possible naming convention (not required) consists of naming the LDReference with a prefix that clas-
sifies it for some useful purpose, and a suffix that is an alphanumeric identifier that uniquely identifies this
instance of the same classification in the network. For example, a utility managing a network of electric
meters might find it useful to maintain the naming convention Mxxxxx, where the M represents the cat-
egory of devices, and the xxxxx is a 5 character alphanumeric identifier (a-z, A-Z, 0-9), providing for
(26+26+10)5 unique names for that common device.
3.4 DeviceModel Naming

Each standardized DeviceModel has a unique name. This name becomes the name of the top level DataOb-
ject in the DeviceModel. The contents of this DataObject are the FunctionalComponents that make up the
model of device functionality. These names are unambiguously defined by those maintaining these modeling
agreements. However, new names can be invented by manufacturers as the need arises.
DeviceModel names must be relatively short, at most four characters of the six allocated, with the remaining
two characters reserved for identifying multiple instances of the same model in a LogicalDevice (e.g., Dist1,
Dist2, Dist3). This is due to the model names becoming the base name of an aggregated hierarchy of
DataObjects and appearing as part of the references to all individual components of that hierarchy.
Some examples of DeviceModel names are LTCC (load tap changer controller), ASwC (automated switch
controller), RTU (remote terminal unit), EMtr (electric meter).

IEEE-SA
A large degree of modeling of remote devices involves representing measurements and controls. This section
discusses the recommended approaches to modeling physical quantities for measurement and control. Three
key topics are discussed:
How to partition a physical quantity into value, scale, and engineering units
How to group common information relating to the same physical quantity
How to group common information relating to binary controls
3.5 Description of Physical Quantities

Exchanging floating point values between devices can be difficult when at least one of the devices is based
on a low-cost, microprocessor-based design. These devices typically perform only integer arithmetic in hard-
ware, and if floating point is supported at all, it is implemented with performance-intensive software floating
point emulation. This guide to modeling therefore supports a way of transporting measurements that allows
for a robust description of engineering units, accuracy, and precision, along with the ability to facilitate the
nature of small and simple devices. The approach achieves the following goals:
Within the context of electric power distribution applications, the entire range and precision of
values, such as volts, amps, etc., must be represented.
All calculations must be able to be performed efficiently in low-cost hardware with only integer
arithmetic capability.
Data exchanged in normal operation must be as compact as possible to minimize network band-
width.
The representation must allow both the encoding and decoding of floating point values by low-cost
devices.
Devices without floating point hardware or software capability must be able to convert to/from the
representation without significant effort or loss of precision.
This approach models any physical quantity with an integer value, a floating point scale and offset, and an
enumerated value representing the Standard International (SI) units of measure.
The floating point representation f for the analog value may be obtained by applying the following for-
mula to the integer value i.
f= (i*s+o)*u
where
i is the actual value of the analog value in counts. A count is the primitive unit of local representa-
tion for the value. Each count represents some fractional number of units of the underlying physical
property being represented.
f is the actual value of the analog value represented as a floating point number.
u is an enumeration specifying the SI units for the corresponding value (1 = amps, 2 = volts, etc.see
SIUnits for complete list).
s is floating point scale constant to use in the conversion formula above.
o is floating point offset constant to use in the conversion formula above.

IEEE-SA
3.6 FunctionalComponent Groupings for Analog Measurements

and Controls
Besides simply obtaining the numeric value of a measurement, there are often several additional pieces of
relevant information. Typically, there are the scale and units associated with the measurement. In addition,
measurements often have dead bands and high and low limits associated with them. This is also true of con-
trolled analog outputs of control devices and computed parameters. Therefore, a measurement will have sev-
eral DataObjects components that reside in several FunctionalComponents to fully specify the
communications visible information necessary.
All the information that configures the representation of the measurement is separate from the measurement
itself. This separation allows the dynamic information to be separate from the mostly static configuration
information. The benefit here is in the segregated grouped access to parameters of similar persistence. An
additional benefit is that protection of configuration information by select before operate (SBO) or security
is easier when the information is separate and can be protected as a group.
The following set of FunctionalComponents, therefore, hold related information for a hypothetical measure-
ment <name>:
MX.<name> Contains the actual dynamic value(s) of measurements both externally sampled, and
internally computed
CF.<name> Contains the configuration information of the analog value, such as scale and units
DC.<name> Contains additional descriptive information of the analog value, such as measurement
type, reference, etc.
SP.<name> Contains setpoints relating for the measurement value
SG.<name> Contains setpoints for protective relays and other functions where multiple groups of
settings are selected for use, one group at a time
CO.<name> Controls selection of active settings group (SG).
Table 3 summarizes some common primitive DataObjects to be considered for placement in the above struc-
tures. Depending on the nature of the analog value being modeled, there may be one or more of these
DataObjects defined.
Table 3: Sample Functional Component Grouping
DataObject Class (DataType) Description

MX.<name> AI(STRUCT) Measurements
MX.<name>.i INT16S The integer value of the measurement
MX.<name>.f FLT32 A floating point representation of the value
MX.<name>.t BTIME6 A time stamp of the value
MX.<name>.q BSTR8 The quality description of the value
MX.<name>.fi FLT32 Frozen value
MX.<name>.ft BTIME6 Frozen timestamp
CF.<name> ACF (STRUCT) Configuration
CF.<name>.u ENUM16 The SI units of the analog value
CF.<name>.s FLT32 The scale, default = 1.0
CF.<name>.o FLT32 The offset, default = 0.0
SP.<name> AISP (STRUCT) Setpoints
SP.<name>.db INT16S Deadband
SP.<name>.hl INT16S High limit
SP.<name>.ll INT16S Low limit
CO.<name> ENUM8 Controls active SG
DC.<name>.d d (VSTR32) Description of analog

IEEE-SA
For example, given a voltage measurement AV (phase A voltage V), there may be the following DataOb-
jects defined for a given DeviceModel ADM:
ADM.MX.V.PhsAi The integer value of the voltage

ADM.CF.V.u The units (29 = volt)
ADM.SP.V.db The dead band for thresholding voltage (20)
ADM.SP.V.hl The high limit
ADM.SP.V.ll The low limit
Note that with these definitions, it is known that:
No floating point version of the number is present, since only i is defined

The scale is 1.0, and the offset is 0.0, since they are absent and only the u (units) is defined
3.7 FunctionalComponent Groupings for Binary Controls

Binary values are used for: Contact closure inputs, relay outputs, motorized transfer switches, pulsed out-
puts, control procedure initiation, etc.
The following FunctionalComponent groups might be used in defining binary valued DataObjects:
CF.<name> Contains the configuration information of the binary value, such as pulse on time,
pulse off time, etc.
DC. <name> Contains additional descriptive information of the binary value, such as a description
string, type of binary value, etc.
CO.<name> Contains binary values used as controlled outputs, such as control of switch position,
perform self test, etc.
ST.<name> Contains the current state of the switch for reading.
Table 4 summarizes common primitive DataObjects that might be specified for the above structures:
Table 4: Class Usage in Functional Components
DataObject Class (DataType) Description

CF.<name> CCF (STRUCT) Configuration
CF.<name>.OnDur INT32U Duration of on pulse
CF.<name>.OffDur INT32U Duration of off pulse
CF.<name>.NumPls INT16U Pulse repetition count
CO.<name> DCO (STRUCT) Controls
CO.<name>.OperDev b2 Double control output, set to desired state
CO.<name>.SBO IDENT Select before operate
DC.<name>.d d (VSTR32) Description of binary point
ST.<name> SIT (STRUCT) Status
ST.<name>.b2 b2 Current state (device status)
ST.<name>.q BSTR16 Quality flags
ST.<name>.t BTIMEn Binary time
In defining a given binary valued DataObject, the required groupings are selected to model the specific func-
tion required.

IEEE-SA
For example, control of a switch, SW. Assume that a switch is a 2-bit binary value.
Sw.ST.SwDS.b2 The status of the switchthis may be read only

Sw.CO.ODSw.b2 The control of the switch
4. UCA Standard DataTypes

Note: The UCA standard DataType name shown in Table 5 should always be presented in upper case
Table 5: UCA Standard DataTypes
UCA Standard Range of Values

Description
DataType Name (where applicable)
BOOL Boolean1 bit True (1) or False (0)
BSTR2 Bit string2 bits
BSTRn Bit stringn bits
INT8U Unsigned integer8 bits 0 to 255
INT16U Unsigned integer16 bits 0 to 65,535
INT32U Unsigned integer32 bits 0 to 4,294,967,295
INTnU Unsigned integern bits
INT8S Signed integer8 bits 128 to +127
INT16S Signed integer16 bits 32,768 to + 32,767
INT32S Signed integer32 bits 2,147,483,648 to +2,147,483,647
INTnS Signed integern bits
FLT32 Floating point, IEEE format, single precision
FLT64 Floating point, IEEE format, double precision
VSTRn Printable ASCII text string1 to n characters
VSTR Null terminated, printable ASCII text
OSTRn Octet string1 to n length
BTIME4 Number of ms since midnight 4 octets
Number of ms since midnight and days since 1
BTIME6
January 1984 - 6 Octets
Enumerated value, 8 bits, signedwell known
ENUM8
values positive, 0 always reserved and unused
Enumerated value, 16 bits, signedwell known
ENUM16
values positive, 0 always reserved and unused
VSTR65, identifies a DataObject or subcomponent of a DataObject within the scope
IDENT
of the server
STRUCT Structure
ARRAY <TYPE>[I][j][k] ..ARRAY elements for three dimensions of TYPE
A reference to a binary large object that can be transmitted separately in pieces rather
BLOB
than a single message transaction

IEEE-SA
5. Common Component Definitions
5.1 Common Components in Data Models

Table 6 contains a list of common components used in data models.
Table 6
Common Components
Name Description DataType
b Boolean BOOL
b<n> Bit string BSTRn
d Description VSTR32
db Deadband INT16U
f Floating point value FLT32
ff Frozen floating point value FLT32
hl High limit INT16S
hhl High high limit INT16S
ll Low limit INT16S
lll Low low limit INT16S
i Integer value INT16S
fi Frozen integer value INT16S
o Offset FLT32
q Quality BSTR16
r Running total INT32U
fr Frozen running total INT32U
s Scale FLT32
t Time stamp BTIME6
ft Frozen time stamp BTIME6
pp PsuedoPoint BOOL
u Unit ENUM16
AccRptEna Accumulator report Ena BOOL
AccRs Accumulator reset BOOL
AccSet Accumulator set IDENT
ActTagArr Active tag array BSTR8
Ancestry CASM class ancestry VSTR32
AnFmt Analog format VSTR6
BLOB Binary large object BLOB
BnkCon Bank connection ENUM8
BufTim Buffer time INT32U
CID Canonical addressing ID INT32S
CktID Circuit ID VSTR32
CktPhs Circuit phases ENUM8
Class Device class VSTR32
CommAdr Communication address VSTR16
CommRev Communications rev VSTR8

IEEE-SA
Table 6 (continued)
Common Components
ContCurRtg Continuous current Rtg VSTR16
Count Count of records INT16U
CurEnt Current entries INT32U
CriRpt Critical report BOOL
DatSet DataSet name IDENT
DestAE Destination AE title VSTR32
DevFct Device function INT16U
DevMdls DeviceModels VSTR128
DevSt (DS) Device state b2
DOW Day of week ENUM8
DOWSched Day of week schedule BTIME4[6]
DschTimDel Discharge time delay INT16U
Enable Enable some function BOOL
EncOpt Encoding options BSTR8
Enroll ECB name to enroll IDENT
Enumeration or bit string descriptive
EOrBDesc VSTR64[]
strings
EvaCns Evaluation constraints IDENT
EvaCri Evaluation criteria IDENT
EvaFct Evaluation function VSTR32
EvaPar Evaluation parameters IDENT
EvtEna Event enable BOOL
FillLvl Fill level INT8U
FillST Fill status warning BOOL
FltCurDur Fault current duration INT16U
FltCurRtg Fault current Rtg VSTR16
Fmt Format ENUM8
FrzEna Freeze enable BOOL
FrzPd Freeze period INT32U
FwdPwrHa Forward power Ha FLT32[31]
HwRev Hardware Rev VSTR8
HzRtg Frequency rating VSTR32
InDat Input data name IDENT
IntgPd Integrity period INT32U
LinLenm Line length in meters INT16U
Loc Device location VSTR128
LogEna Log enable BOOL
LogEnr ECB to enroll VSTR64
LogNam Log name VSTR64
LogOpt Log options BSTR4
LogSize Log table size INT32U
LogSt Log status BSTR5

IEEE-SA
Table 6 (continued)
Common Components
LogWrp Log wrapped enable BOOL
LstEntDisc Last entry discarded INT32U
MAC Medium access control INT8U
Mdl Model VSTR32
Med Physical medium ENUM8
MxRef Measurement reference ENUM8
MxTyp Measurement type ENUM8
Name Owner device name VSTR32
NetEnt Newest entry INT32U
NewTim newest time BTIME6
NumBits Number bits INT16U
NumEnt Number current entries INT32U
NumOvr Number of overflow INT32U
NumPls Number pulses INT16U
NumSmp Number samples INT16U
NumUnit Number of units VSTR32
OffDur Off duration INT32U
OldEnt Oldest entry INT32U
OldTim Oldest time BTIME6
OnDur On duration INT32U
OperDev (OD) Operate device b2
OperLogic Operating logic ENUM8
OptFlds Optional fields to include BSTR8
OutDat Output DataSet name IDENT
OvrST Overflow status BOOL
Own Owner VSTR32
Po Polar coordinates [Mag, Ang]
Pro Protocol ENUM8
PwrHa Power harmonics FLT32[31]
QuRptEna Quality report enable BOOL
RBEPd Report period INT32U
Rect Rectangular coordinates [x, y]
RptEna Report enable BOOL
RptID Report ID IDENT
RvsPwrHa Reverse power Ha FLT32[31]
SBO Select before operate IDENT
SBOEna SBO enable BOOL
SelTimOut SBO select time out INT8U
SeqNum Sequence number INT8U
SerNum Serial number VSTR32
SftRev Software rev VSTR8
SmpRate Sample rate INT16U

IEEE-SA
Table 6 (continued)
Common Components
StartTim Start time BTIME6
State State BOOL
TagD Tag description VSTR128
TagID Tag ID INT8U
TagOwn Tag owner VSTR32
TagTyp Tag type permitted BSTR8
TempRtg Temperature rating VSTR16
TimCrv Time curve ENUM8
TimOfFrz Time of freeze BTIME6
TimRptEna Time stamp report Ena BOOL
TrgOps Trigger options BSTR8
Trgs Num of triggers before report INT16U
TrpCoil Trip coil supervision BOOL
UnitVArRtg Unit VAr Rtg VSTR32
UnkPwrHa Power harmonics (direction unknown) FLT32[31]
UseST Utilization status BOOL
VArRtg VAr rating VSTR16
VARtg VA rating VSTR16
Vnd Vendor VSTR32
VRtg Voltage rating VSTR16
WrnLev Log warning level INT16U
WrnST Warn status BOOL
5.1.1 Accumulator Report Enable

An accumulator control itself is never reported spontaneously or logged. Reporting of accumulators is as
described in the table below:
Accumulator Report
Freeze Enable Behavior
Enable
TRUE TRUE Reporting occurs after each freeze.
Freezing continues without any reporting. Values may be
TRUE FALSE
read at the masters convenience.
Reporting occurs at the integrity period or after freezes on
FALSE TRUE
demand by the master.
FALSE FALSE No freezing or reporting.
The report shall contain the time of freeze from the first accumulator in the accumulator set, followed by the
frozen value or quality attributes of each accumulator in the accumulator set that have changed since the last
report.
Note: The time of freeze is not the same as the timestamp on the report itself.
5.1.2 AccRs
When set to TRUE, the running value of the selected accumulators is reset to zero (0) as the freeze operation
occurs.

IEEE-SA
5.1.3 AccSet
The name of a DataSet containing those objects that are to be frozen and/or reported. If a master attempts to
write to accumulator set the name of a DataSet that does not meet this criteria, the object shall reject the
write request.
5.1.4 ActTagArr
Identifies the active tags on the device. The bits representing active tag are:
Bit Number Bit Name

0 No switching tag active
1 Close operation blocked tag active
2 Device failure tag active
3 Interlock active tag active
5.1.5 AnFmt
For analog values, defines the format and length of the analog value, such as integer, bit length, signed or
unsigned (e.g., INT32U = unsigned integer of 32 bits).
5.1.6 b (Binary Value)
The actual binary values in a bit string. [N] can range from 1 to 32. Value can be a single bit, i.e., Boolean or
bit string [1]. Each bit can only be either a value of [0] (FALSE) or [1] (TRUE).
5.1.7 BLOB
The BLOB DataObject itself. When read this provides a BLOB data reference that can be used to transport
the BLOB data.
5.1.8 BnkCon
The integers representing the different types of capacitor bank connections are:
BnkCon Value
WYEungrounded 1
WYEgrounded 2
delta 3
delta-delta 4
T-connected 5
Autotransformer, with out tertiary 6
Autotransformer, with delta tertiary 7
delta-wye 8
wye-wye 9
(future) 1016

IEEE-SA
5.1.9 Buffer Time
The time duration for buffering input and output values for reporting.
5.1.10 Circuit ID
A description and identification of the circuit to which the device is connected.
5.1.11 Circuit Phases
Describes the phases the device is associated with on the circuit.
Integer Value Phase

1 A
2 B
3 C
4 All three
5 Neutral
6 Ground
7 Unknown
5.1.12 Communication Address

Uniquely identifies the class-object.
5.1.13 Communications Rev

The communications revision of the device.
5.1.14 Continuous Current Rating
The maximum current allowed through the device on a continual basis.
5.1.15 CurEnt
The number of entries present in the journal.
5.1.16 DatSet
The name of the DataSet monitored for reporting.
5.1.17 Day Of Week (DOW)

DOW is used to indicate the day of the week for control schedules. The enumeration of DOW is:

IEEE-SA
Value Day
1 Sunday
2 Monday
3 Tuesday
4 Wednesday
5 Thursday
6 Friday
7 Saturday
5.1.18 Day Of Week Schedule (DOWSched)

DOWSched is used to represent daily control cycles by specifying the on and off times in seconds since mid-
night. The format for the daily schedule is:
DOWSched: [StartTim1, StopTim1, StartTim2, StopTim2, StartTim3, StopTim3]]
5.1.19 Deadband
An optional component of the same length as the value component used to determine whether the associated
value has changed beyond the previously reported value by the amount in the deadband:
IF (new value > previously reported value + deadband)

or (new value < previously reported value deadband)
THEN notify that deadband has been exceeded
5.1.20 Device Class

Description of the type of virtual device, i.e., transformer, switch, etc.
Device Class
Generator
Transformer*
Reactive component
Switch
Protection relay
RTU
Electric meter
Gas meter
Water meter
Revenue electric meter
Revenue gas meter
Revenue water meter
*The device class transformer includes transformer,
step voltage regulator, and load tap changer.
The device class reactive component includes
capacitor, and inductor.

IEEE-SA
5.1.21 Description
A component that provides a brief text description of the object. Typically, the initial value of this compo-
nent is locally configured when the device is commissioned, but this is not a requirement.
5.1.22 Device Function
Defines the device function per IEEE Std C37.2-1996, IEEE Standard Electrical Power System Device
Function Numbers and Contact Designations devices. The integer representations of device function are
presented in Table 7.
Table 7
Integer Device Function per

Value IEEE Std C37.2-1996
1 Master element
2 Time-delay starting or closing relay
3 Checking or interlocking relay
4 Master contactor
5 Stopping
6 (unassigned)
7 (unassigned)
8 Control power disconnecting device
9 Reversing device
10 Unit sequence switch
11 Multifunction device
12 Overspeed
13 Synchronous speed
14 Under speed
15 Speed or frequency matching device
16 (unassigned)
17 (unassigned)
18 Accelerating/decelerating
19 Starting to running
20 (unassigned)
21 Distance relay
22 (unassigned)
23 Temperature control device
24 Volts per hertz relay
25 Synchronizing or synchronism-check dev
26 Apparatus thermal device
27 Undervoltage relay
28 (unassigned)
29 (unassigned)
30 (unassigned)
31 (unassigned)
32 Directional power relay
33 Position switch
34 Master sequence device

IEEE-SA
Table 7 (continued)

35 (unassigned)
36 Polarity or polarizing voltage device
37 Undercurrent or underpower relay
38 (unassigned)
39 Mechanical condition monitor
40 Field relay
41 Field circuit breaker
42 Running circuit breaker
43 Manual transfer or selector device
44 Bearing protective device
45 Atmospheric condition monitor
46 Reverse-Phs or Phs-Balance current relay
47 Phs-Seq or Phs-Balance voltage relay
48 Incomplete sequence relay
49 Machine thermal device
50 Instantaneous overcurrent or relay
51 AC time overcurrent relay
52 AC circuit breaker
53 (unassigned)
54 (unassigned)
55 Power factor relay
56 Field application device
57 Short-circuiting or grounding device
58 (unassigned)
59 Overvoltage relay
60 Voltage or current balance relay
61 (unassigned)
62 Time-delay stopping or opening relay
63 Pressure switch
64 Ground detector relay
65 (unassigned)
66 (unassigned)
67 AC directional overcurrent relay
68 Blocking relay
69 Permissive control device
70 (unassigned)
71 Level switch
72 DC circuit breaker
73 (unassigned)
74 (unassigned)
75 Position changing mechanism
76 DC overcurrent relay
77 Telemetering device

IEEE-SA
Table 7 (continued)

78 Phs-angle measuring or out-of-step relay
79 AC reclosing relay
80 (unassigned)
81 Frequency relay
82 DC reclosing relay
83 Automatic selective control or transfer
84 Operating mechanism
85 Carrier or pilot-wire receiver relay
86 Lockout relay
87 Differential protective relay
88 Auxiliary motor or motor generator
89 Line switch
90 Regulating device
91 Voltage directional relay
92 Voltage and power directional relay
93 (unassigned)
94 Tripping or trip-free relay
95 (unassigned)
96 (unassigned)
97 (unassigned)
98 (unassigned)
99 (unassigned)
5.1.23 Device Location
The description of the location of the device. This may include the GPS location in the future.
5.1.24 DevMdls
A list of DeviceModel names in this LogicalDevice. Part of the required DI structure. Example: A Logi-
calDevice containing an LTCC and RTU DeviceModels: LTCC; RTU.
5.1.25 DevSt (DS)
The operating state of a two state device expressed as a 2-bit status input (SIT), as defined in Table 8.

IEEE-SA
Table 8: Two State Device Interpretation
Bit Order 00 01 10 11
Value 0 1 2 3
Device State State State State
Switch Between Off On Invalid
Switch Between Open Closed Invalid
Switch Between Trip Closed Invalid
LTCC Invalid Raise Lower Invalid
LTCVRedMode Off Comm actuation Contact actuation Vendor specific
Operation Mode Invalid Automatic Manual Invalid
Control Mode Invalid Local Remote Invalid
Device Invalid Offline Available Invalid
Device Invalid Not Ready Ready Invalid
Function Invalid Disabled Enabled Invalid
Note: The left most bit is bit 0, and the most significant bit.
5.1.26 Fault Current Duration
The maximum duration of the fault current rating allowed through the device.
5.1.27 Fault Current Rating
The maximum fault current allowed through the device for the time specified in fault current duration.
5.1.28 Floating Point Value
For analog values, the floating point representation of the analog value is calculated by:
Floating point value = integer value * scale + offset
5.1.29 Fmt
Describes the format of the contents of the BLOB. The following format identifiers are initially recognized:
Integer
Format
Value
1 OPAQUE
2 COMTRADE
3 PQDIFF
4 BER
5 TYPESPEC
OPAQUE Contents are private to the application

COMTRADE Contents follow the COMTRADE standard definitions
PQDIFF Contents follow the PQDIFF standard used in describing transient data sets

IEEE-SA
BER Contents follow the ISO Basic Encoding Rules of Tag/Length/Data

TYPESPEC Contents are a CASM type specification (can be used to exchange whole Device-
Model composition
5.1.30 Freeze Enable
The command to freeze the accumulator, i.e., copy the running value into the frozen value.
5.1.31 Freeze Period and StartTim
The accumulator control permits freezing accumulators in several different ways, according to Table 9. In
each case, the object shall evaluate StartTim (BTIME6) and freeze period (ms) only at the moment when the
master station writes TRUE to Freeze Enable. In other words, a master must either write the entire control
block at once, or first write the other parameters before enabling the control block. The object shall reject a
write to freeze period, StartTim, reset or accumulator set when freeze enable is already TRUE, unless the
entire control block is being written at once.
Table 9: Freeze Parameters
StartTim Freeze Period
Operation Effect
set to: set to:
The RTU shall freeze the accumulators immediately
upon receiving the write of TRUE to freeze enable. The
Immediate freeze Midnight 1/1/84 0 ms
RTU shall return freeze enable to FALSE after the
freeze.
The RTU shall freeze the accumulators at StartTim. The
The required
Freeze at given time 0 ms RTU shall return freeze enable to FALSE after the
time and date
freeze.
The RTU shall freeze the accumulators immediately
The required upon receiving the write operation, and periodically
Freeze periodically Midnight 1/1/84
period in ms every freeze period thereafter. Freeze enable remains
TRUE until written FALSE by the master.
The RTU shall freeze the accumulators at the specified
Freeze periodically The required The required StartTim and periodically every freeze period thereaf-
with a given start time. start time. period in ms ter. Freeze enable remains TRUE until written FALSE
by the master.
Notes:
1If StartTim is less than the current time when freeze enable is written to TRUE, but is not midnight 1/1/84, the
RTU shall reject the write operation.
2If the time on the RTU is resynchronized after it has started periodic freezing, the RTU shall adjust its freezing
time to align to the new time. For example, suppose freezing began at 3:00 and is scheduled for every 15 minutes
thereafter. At 3:05 the time is resynchronized to 7:14. The RTU shall perform the next freeze in one minute at the
resynchronized time of 7:15, rather than waiting the remaining 10 minutes for what would have been 3:15.
5.1.32 Frozen Value and Running Value
Counts from 0 to (2n-1). When a freeze operation occurs, the running value is copied into the frozen value
and time of freeze is updated. If the reset component in the accumulator control block is TRUE when the
freeze occurs, the running value is cleared at the same moment. No counts shall be lost when a freeze or
freeze/clear operation occurs.

IEEE-SA
5.1.33 Hardware Rev
The hardware revision of the device.
5.1.34 Integer Value
The actual value of the analog point.
5.1.35 Integrity Period
If the integrity period has expired since the last report, the object assumes that all the frozen value and qual-
ity attributes in the accumulator set have changed, whether they actually have or not, and includes all this
data in the report. If integrity period is zero, integrity reports are disabled. Integrity period is started when
report enable is set to TRUE. A change is considered to be:
Any change to the quality attribute.

Any change to the frozen value compared to its last frozen value if reset is FALSE.
Any non-zero frozen value if Reset is TRUE. (Frozen value is measuring changes.)
All quality and frozen values if integrity period recently expired.
5.1.36 Log Enable
Flags whether logging is enabled or disabled during reporting.
5.1.37 Measurement Type
Identifies what the field device measurement represents, i.e., the present value, peak, zero sequence compo-
nent, etc., over the number of samples. The bits representing measurement type are:
Integer
Measurement Type
Value
1 Present value
2 Maximum value
3 Minimum value
4 Peak
5 Zero sequence
6 Positive sequence
7 Negative sequence
5.1.38 Measurement Reference
Describes the phase measurement, if any, associated with the SIUnits (i.e., phase 1, phase 1 to phase 2, 3
phase, etc.) and the location of the measurement (i.e., source side, load side, etc.) The integer representations
of measurement reference are:

IEEE-SA
Integer Measurement
Value Reference
1 Unknown
2 Phase 1
3 Phase 2
4 Phase 3
5 Neutral
6 Phase 1 to phase 2
9 Phase 1 to neutral
12 Neutral to ground
13 3 phase
5.1.39 Model
Describes the specific model of the device according to the manufacturer.
5.1.40 Number Bits
For binary values, the number of bits in the actual binary value can vary from 1 to n. As a default, the
number of bits is [1], i.e., the binary value is Boolean.
5.1.41 Number Pulses
For binary control, the number of output pulses to be sent. The default is 1.
5.1.42 Number Samples
If applicable, this is the number of samples used in the actual measurement associated with the measurement
type.
5.1.43 Off Duration
Specifies the length of time, in milliseconds, the output shall be disasserted after being asserted. The off
duration shall be ignored for the last count of the number of pulses. It is both readable and writable.
5.1.44 Offset
For analog values, the offset from zero of the analog value.

IEEE-SA
5.1.45 OldEnt
The entry number of the first valid entry present in the log control block (LCB) specified log.
5.1.46 On Duration
Specifies the length of time in milliseconds that the output shall be asserted. It is both readable and writable.
5.1.47 OperDev (OD)

A double bit command used to change the operating state of a two state device as defined in Table 10.
Table 10: Two State Control Interpretation
Bit Order 00 01 10 11
Value 0 1 2 3
Device Action Action Action Action
Switch Invalid Off On Invalid
Switch Invalid Open Close Invalid
Switch Invalid Trip Close Invalid
LTCC Invalid Raise Lower Invalid
LTCVRedMode Off Comm actuation Contact actuation Vendor specific
Operation Mode Invalid Automatic Manual Invalid
Control Mode Invalid Local Remote Invalid
Device Invalid Test Normal Invalid
Function Invalid Disable Enable Invalid
Note: The left most bit is bit 0, and the most significant bit.
5.1.48 Owner
The name of the company owning and implementing the device.
5.1.49 Owner Device Name

The name of the device according to the owner.
5.1.50 Phase Targets (PhsTar)

PhsTar is a ENUM8 that identifies the involved phases.
Value Name
0 None
1 Phase A
2 Phase B
3 Phase C
4 Ground only
5 A to ground
6 B to ground
7 C to ground

IEEE-SA
Value Name
8 AB
9 BC
10 CA
11 AB to ground
12 BC to ground
13 CA to ground
14 ABC
15 ABC to ground
5.1.51 PhysicalMedium
The physical medium used to communicate with the device. The integer representations of PhysicalMedium
are:
Integer
Physical Medium
Value
1 Twisted pair
2 Powerline carrier
3 Fiber optic
4 Infrared
5 Radio frequency
6 Coaxial cable
5.1.52 Protocol
The protocol used to communicate with the device. The integer representations of protocol are:
Integer
Protocol
Value
1 Unknown
2 MMS
3 DNP
4 PG&E
5 FMS
6 DLMS
7 BACNet
8 CEBus
9 LonTalk
10 X10
11 CASM + MMS
12 CASM + CORBA
13 CASM + DCOM
14 MODBUS
15 MODBUS PLUS

IEEE-SA
5.1.53 PwrHA, Power Harmonics
Power harmonics is an array of FLT32 values, representing the harmonic content of a variable. The first
value in the array is the first harmonic, or fundamental frequency; the second value is the second harmonic,
etc.
5.1.54 Quality
Quality is used to indicate if an object value is valid, and if not, the reason for being invalid. Each quality
indication is represented as a bit within the quality component. The bits representing quality are:
Bit Number Quality

0 Reserved
1 Invalid
2 Comm fail
3 Forced
4 Over range
5 Bad reference
615 Unassigned (future)
Invalid: Indicates whether or not the associated value is valid or not. If clear (0), the value of this
point is valid and can be used in calculations, alarms, etc. If set to (1), the reported value of this
point may not be correct and therefore should not be used.
Comm fail: Indicates communication status. If set (1), this bit indicates that one of the reasons the
validity bit is set is that the object has lost communications with the device actually gathering the
value of the point.
Forced: Indicates how the value was established. If set (1), this bit indicates that the reported value
of this point is not necessarily the actual value. The point has been forced to report this value
either locally or via a write operation from the master. The validity bit may be set or clear when
forced is set, since the forced value may or may not be valid.
Over range: This is only applicable to analog values. If set (1), this bit indicates that the value is
invalid because the value being measured has exceeded the physical capabilities of the hardware
performing the measurement. This bit thus indicates that one of the reasons the validity bit is set is
that the value is over range.
Bad reference: This is only applicable to analog values. If set (1), this bit indicates that the value is
invalid because the reference value used to calibrate the analog value is incorrect.
5.1.55 Quality Report Enable
Flags whether quality indication is enabled or enabled.
5.1.56 Report Enable
Flags whether reporting is enabled or disabled.
5.1.57 Sample Rate

If applicable, this is the number of samples per cycle associated with the measurement type.

IEEE-SA
5.1.58 SBO Class

Attribute that specifies if the SBO-object is implicitly deselected by the server following an access of the
associated DataObject (operate once) or if the client must explicitly deselect the SBO-object after one or
more accesses of the DataObject (operate many).
5.1.59 SBOEna
Specifies if SBO control access to the object attributes is required. If SBO enable is set to FALSE (0), SBO
control is not required. The actual SBO function is defined by the services of the object according to CASM.
The binary value attribute of the binary value common object cannot be written until the output is first
selected using the SBO service.
5.1.60 Scale
For analog values, the scale or multiplier of the analog value.
5.1.61 SelTimOut
Per device SBO select timeout in seconds. Or the maximum time for conducting a specified activity is valid.
5.1.62 Serial Number
The manufacturers serial number of the device.
5.1.63 SftRev
The software revision of the device.
5.1.64 SIUnits
A description of what the analog value represents, i.e., V, A, PF, %, etc. Default is [1] which is dimension-
less (which is the same as the analog value primitive object, i.e., in the case of an RTU analog value that rep-
resents a point, and not necessarily a specific measurement).
The integer representations of SIUnits and derived SIUnits are shown in Table 11.
Table 11: Representation of SI Units
Integer UCA
Quantity Unit Name Symbol
Value 2.0
Base Units
1 None Dimensionless None None
2 Length Meter m m
3 Mass Kilogram kg kg
4 Time Second s s
5 Current Ampere A A
6 Temperature Kelvin K T
7 Amount of substance Mole mol

IEEE-SA
Table 11: Representation of SI Units (continued)
Integer UCA
Value 2.0
8 Luminous intensity Candela cd cd
9 Plane angle Degrees deg deg
10 Plane angle Radian rad r
11 Solid angle Steradian sr
Derived Units
21 Absorbed dose Gray (J/Kg) Gy
22 Activity Becquerel (l/s) q
23 Relative temperature Degrees Celsius C
24 Dose equivalent Seivert (J/kg) Sv
25 Electric capacitance Farad (C/V) F
26 Electric charge Coulomb (AS) C
27 Electric conductance Siemens (A/V) S
28 Electric inductance Henry (Wb/A) H H
29 Electric potential Volt (W/A) V V
30 Electric resistance Ohm (V/A) W W
31 Energy Joule (N m) J
2)
32 Force Newton (kg m / s N
33 Frequency Hertz (1/s) Hz Hz
34 Illuminance Lux (lm/m2) lx lx
35 Luminous flux Lumen (cd sr) Lm Lm
36 Magnetic flux Weber (V s) Wb
37 Magnetic flux density Tesla (Wb/m2) T
38 Power Watt (J/s) W W
39 Pressure Pascal (N/m2) Pa
Extended Units
41 Area Square meter (m2) m2
42 Volume Cubic meter (m3) m3
43 Velocity Meters per second (m/s) ms-1
44 Acceleration Meters per second2 (m/s2) ms-2
45 Volumetric flow rate Cubic meters per second (m3/s) m3s-1
46 Fuel efficiency Meters / cubic meter (m/m3) ms3
47 Moment of mass Kilogram meter (kg m) M
48 Density Kilogram/cubic meter (kg/m3)
49 Viscosity Meter square/second (m2/s)
50 Thermal conductivity Watt/meter Kelvin (W/m K)
51 Heat capacity Joule/Kelvin (J/K)

IEEE-SA
Table 11: Representation of SI Units (continued)
Integer UCA
Value 2.0
52 Concentration Parts per million ppm ppm
Industry Specific Units Electric Units
61 Apparent power Volt ampere (VA) VA VA
62 Real power Watts (I2R) W W
63 Reactive power Volt ampere reactive (VISin) VAr VAr
64 Phase angle Degrees q q
65 Power factor (Dimensionless) Cos Cos
Volt seconds
66 Volt seconds Vs Vs
(W s/A)
67 Volts squared Volt square (W2/A2) V2 V2
68 Amp seconds Amp second (A s) As As
69 Amps squared Amp square (A2) A2 A2
70 Amps squared time Amp square second (A2s) A2t A2t
71 Apparent energy Volt ampere hours VAh VAh
72 Real energy Watt hours Wh Wh
73 Reactive energy Volt ampere reactive hours VArh VArh
74 Magnetic flux Volts per hertz V/Hz V/Hz
5.1.65 State
Attribute that indicates the state of selection of the object. When set to deselected, FALSE, access to the
associated DataObject is inhibited. The default state is deselected.
5.1.66 Tag Desc
Free text description of tag.
5.1.67 TagID
Uniquely identifies the tag number for the device or point assigned to.
5.1.68 Tag Owner
Owner or person who placed the tag. Safety tags can only be removed by or with permission of the tag
owner.

IEEE-SA
5.1.69 Tag Type Permitted
The permissible tag types for the device. The bits representing tag type permitted are:
Bit Number Tag Type Permitted

0 No switching
1 Operation blocked
2 Device failure
3 Interlock active
5.1.70 Temperature Rating
The maximum temperature in which the device can operate (not temperature rise).
5.1.71 TimCrv
Each time curve is of the form: time = f (current measurement). The integers representing the different
curves of TimCrv are:
TimCrv Value
ANSI extremely inverse 1
ANSI very inverse 2
ANSI normal inverse 3
ANSI moderately inverse 4
ANSI definite time (definite time
5
over current = default)
Long-time extremely inverse 6
Long-time very inverse 7
Long-time inverse 8
IEC normal inverse 9
IEC very inverse 10
IEC inverse 11
IEC extremely inverse 12
IEC short-time inverse 13
IEC long-time inverse 14
IEC definite time 15
Manufacturer-defined or user pro-
16->
grammable custom curves
5.1.72 Time of Freeze
A time stamp representing the last time the accumulator was frozen. If the accumulator was never frozen, it
shall report a time of freeze of midnight, 1 January 1970.
5.1.73 Time Stamp
An optional component used to indicate the last time the object was updated. A default of zero indicates that

IEEE-SA
no time stamp is available.
5.1.74 Time Stamp Report Enable
Flags whether time stamping is enabled or disabled during reporting.
5.1.75 Trgs
The number of triggers before the report is sent.
5.1.76 TrgOps
Trigger options are used to identify the conditions upon which an event will be logged for reporting. The fol-
lowing bits are defined as the default assignments for the TrgOps attribute. Note that the same bit assign-
ments apply for the definition of the reasons for inclusion bit strings in reports generated for the BasRCB
object. Note also that these default bit assignments may be redefined in any specific model if model specific
evaluation functions are defined.
Trigger
Bit # Definition
Condition
Reserved 0 Reserved
Change of any value, possibly with
CndDatChg 1
deadbanding
CndQuChg 2 Change of quality field
CndFrzChg 3 Change of frozen value
5.1.77 TrpCoil
Trip coil supervision provides an indication of trip coil continuity for circuit breakers. If the value is 0, the
trip coil continuity is good; if the value is 1, the continuity is bad.
5.1.78 VA Rating
The apparent power rating of the device.
5.1.79 VAr Rating

The reactive power rating of the device.
5.1.80 Vendor
The name of the manufacturer of the device.
5.1.81 Voltage Rating

The range of voltages for which the field device is rated.

IEEE-SA
6. Common Class Definitions

This clause defines the common class definitions that will be used in later clauses to construct basic building
bricks and device models. They are defined in terms of aggregations and specializations of the UCA Stan-
dard Data Types () and the Common Component Definitions (). Each component of every common class
defined in this clause additionally has the following characteristics:
m/o: Each component is defined as either mandatory (m) or optional (o). Items flagged as manda-
tory must be included. If the component is optional, then it is optional to the vendors implementa-
tion. If the component is optional and available in the object, then the component will be listed
when the device is queried. Note that just because DataObjects are present in the model, they are
only sent across the wire when requested.
rwec: Refers to the operations possible on a component: read, write, execute, and create.
These default permissions may be altered to suit the user of the data models, but the defined permis-
sions of the components can only be extended, not constrained. Note that when the rwec column is
blank, the default value of rw is in effect.
Default: This is the value of the component before configuration, or if the component is not avail-
able from a certain device. If a component is not implemented in an object, or an object is not
implemented in a field device object model, then its name is not included in the object or device
object model, so that any reference to the component or object by a client (e.g., read) will cause a
read error response.
6.1 DeviceIdentity (DI)

Every device in the problem domain has a unique identity that describes the device, its nameplate data, loca-
tion, and other data that seldom changes.
Owner identity describes the components associated with the owner of the device.
Note that All DI fields are variable length with a not to exceed maximum.
Common Class: DI
DeviceIdentity
Name m/o rwec
Name m rw
Class o rw
d o rw
Own o rw
Loc o rw
VndID m r
CommID o rw
6.1.1 VendorIdentity (VndID)
VendorIdentity describes the components associated with the vendor or manufacturer of the device.
Note that the serial number is required, however it may be filled with a null string to indicate that the device
serial number is not supplied.

IEEE-SA
Common Class: VndID

Vendor Identity
Name m/o rwec
Vnd m r
Mdl o r
DevMdls o rw
SerNum m r
HwRev o r
SftRev o rw
6.1.2 CommunicationIdentity (CommID)
CommunicationIdentity describes the communications interface used to communicate with the physical
device.
Common Class: CommID

CommunicationIdentity
Name m/o rwec
CommAdr m rw
CommRev o r
Pro o r
Med o r
MAC o rw
6.2 Functional Components

Table 12: Common Class Use by Functional Component
Functional
Common Class
Component
Name Description Name Description
MX Measurements AI {i, f, q, t} Analog input
AccI {r, q, fr, ft,} Accumulator input
HI {DC, PwrHa, t} Harmonic input
PFD {FPF, FPFTim, RPF, RPFTim, UPF,
Power flow direction
UPFTim}
PFD1 {FPF, FPFTim, RPF, RPFTim, UPF, Power flow direction, fundamental
UPFTim} frequency
WYE {PhsAi, PhsAf, PhsBi, PhsBf, PhsCi, PhsCf, Collection of single phase mea-
Neuti, Neutf, q, t} surements for WYE connection
DELTA {PhsABi, PhsABf, PhsBCi, PhsBCf, Collection of single phase mea-
PhsCAi, PhsCAf, q, t} surements for DELTA connection
Collection of positive, negative and
Seq {Posii, Posif, Negi, Negf, Zeroi, Zerof, q, t}
zero sequence components
ST Status SI {b1, q, t} Status input single bit
SIT {b2, q, t} Status input double bit
SIG {b16, q, t} Status input group

IEEE-SA
Table 12: Common Class Use by Functional Component (continued)
Functional
Common Class
Component
SP Setpoints AO {i, f, SBO} Analog output
or AISP {hhl, hl, ll, lll, db} Analog input SP
SG Settings groups SHOTS {Tmr1, Tmr2, Tmr3, Tmr4, Tmr5, RsTmr } Recloser shots
PUG {Phsi, Phsf, Neuti, Neutf, CldLodi, CldLodf,
Pickup group
Hzi, Hzf}
CBPUG {Maxi, Maxf, Mini, Minf, TimLmt} Capacitor bank pickup group
CBTim {SunSch, MonSch, TueSch, WedSch,
Capacitor bank time schedule
ThuSch, FriSch, SatSch}
XY {Xi, Xf, Yi,Yf} Rectangular coordinates
Vec {Magi, Angi} Polar coordinates
PoZ {PosiZ, NegZ, ZeroZ, q, t} Polar coordinate impedance
RectZ {PosiZ, NegZ, ZeroZ, q, t} Rectangular coordinate impedance
PoB {Angi, XOfsi, YOfsi} Polar blinder
Rect B{XY1,XY2} Rectangular blinder
Quadrilateral, polar definition of
PQuad {UReact, LReact, LtRest, RtRest}
line impedance boundaries.
Quadrilateral, rectangular defini-
RQuad {ULXY, LLXY, URXY, LRXY}
tion of line impedance boundaries
CURVE {CoefA, CoefB, CoefC, CoefD} Relay curve
CO BO {b<n>, SBO} Binary output
DCO {OperDev, SBO} Double control
PDCO {OperDev, NumPls, OnDur, OffDur, SBO} Pulsed double control output
ACF {s, o, u, db, min, max, Incr, MxTyp, MxRef,
CF Configuration Analog configuration
MxLoc, SmpRate, NumSmp, pp}
CCF {OnDur, OffDur} Control configuration
AcsBLOB {BLOB, State, SelTimOut, Fmt} Access binary large object
SBOCF {SBOState, SelTimOut, SBOClass} Select before operate configuration
Ratio {Prif, Secf, Ratiof} Ratio configuration
DC Description d Description
EqRtg {VRtg, ContCurRtg, HzRtg, TempRtg, Flt-
CurRtg, FltCurDur, VARtg, VArRtg, UnitVArRtg, Equipment rating
NumUnit, VTCktPhs, CTCktPhs}
ConCkt {CktID, CktPhs, LinLenm, ContCurRtg,
Connected circuit
VRtg, PosiSeqZ, NegSeqZ, ZeroSeqZ, Ko}
RCB {RptEna, RptID, OptFlds, BufTim, Trgs,
RP Reports Report control block
SeqNum, Enroll, CriRpt, DestAE, EncOpt}
BasRCB {RptID, RptEna, DatSet, OptFlds,
Basic report control block
BufTim, Trgs, SeqNum, TrgOps, RBEPd, IntgPd}
Basic accumulator report control
AccFCB {AccSet, FrzEna, StartTim, FrzPd, FrzRs}
block
PACT {SendingIED, t, SeqNum, StNum, HoldTim,
Protection action
BackTim, PhsID, DNA, UserSt}
XING {Tim, Dir, PhsID, FundVi} Zero crossing

IEEE-SA
Table 12: Common Class Use by Functional Component (continued)
Functional
Common Class
Component
ECB {EvtEna, InDat, OutDat, EvaFct, EvaCri, Eva-
EV Events Event control block
Par, EvaCns}
LCB {LogEna, LogNam, LogEnr, FillLvl, LogSize,
LG Logs LogWrp, LogSt, FillST, LogOpt, OldEnt, NewEnt, Log control block
NumEnt, NumOvr, LstEntDisc, OldTim, NewTim}
AX Access Tag {TagID, TagTyp, TagD, TagOwn} Tags
AS Associations
6.3 Measurements (MX)
6.3.1 Analog Input (AI)
Analog input represents a continuous input parameter that varies with time. AI is used to model values
involved in object interaction within IEDs, or among field devices. Note that the default is RMS values for
AC quantities.
Common Class: AI
Analog Input
Name DataType m/o
i INT16S o
f FLT32 o
q BSTR16 o
t BTIME6 o
6.3.2 Accumulator Input (AccI)
Accumulator input represents an unsigned value of an input parameter that always increases unless it rolls
over to zero. Unlike AI, the full range of an AccI is always used.
Common Class: AccI

Accumulator Input
Name DataType m/o
r INT32U m
q BSTR16 m
fr INT32U m
ft BTIME6 m
6.3.3 Harmonic Input(HI)
Harmonic input represents the harmonic content of a continuous input parameter that varies with time. Note
that DC is the direct current component, and the first harmonic is the fundamental frequency.

IEEE-SA
Common Class: HI
Harmonic Input
Name DataType m/o
DC FLT32 o
PwrHa FLT32[31] o
t BTIME6 o
6.3.4 Power Flow Direction (PFD)
PFD defines a collection of rms values segregated by power flow direction. The PFD is used to indicate the
direction of power flow with respect to the normal forward flow from source to load.
Common Class: PFD

Power Flow Direction
Name DataType m/o
FPF FLT32 o
FPFTim BTIME6 o
RPF FLT32 o
RPFTim BTIME6 o
UPF FLT32 o
UPFTim BTIME6 o
6.3.5 Power Flow Direction (PFD1)
PFD1 defines a collection of fundamental frequency values segregated by power flow direction. The PFD is
used to indicate the direction of power flow with respect to the normal forward flow from source to load.
Common Class: PFD1

Power Flow Direction
[fundamental frequency]
Name DataType m/o
FPF FLT32 o
FPFTim BTIME6 o
RPF FLT32 o
RPFTim BTIME6 o
UPF FLT32 o
UPFTim BTIME6 o
6.3.6 Wye (WYE)
Wye is a collection measurements of continuous time-varying input parameters that represent a wye con-
nected electric circuit. Wye is used to model values involved in object interaction within IEDs or among field
devices. Note that the default is RMS for AC quantities.

IEEE-SA
Common Class: WYE

Wye
Name DataType m/o
PhsAi INT16S o
PhsAf FLT32 o
PhsBi INT16S o
PhsBf FLT32 o
PhsCi INT16S o
PhsCf FLT32 o
Neuti INT16S o
Neutf FLT32 o
q BSTR16 o
t BTIME6 o
6.3.7 Delta (DELTA)

Delta is a collection of measurements of continuous, time-varying input parameters that represent a delta
connected electric circuit. Delta is used to model values involved in object interaction within IEDs or among
field devices. Note that the default is RMS for AC quantities.
Common Class: DELTA

Delta
Name DataType m/o
PhsABi INT16S o
PhsABf FLT32 o
PhsBCi INT16S o
PhsBCf FLT32 o
PhsCAi INT16S o
PhsCAf FLT32 o
q BSTR16 o
t BTIME6 o
6.3.8 Sequence (Seq)
Seq represents a collection of continuous input parameters about electric circuit parameters that vary with
time. Seq is used to model values involved in object interaction within IEDs or among field devices. Note
that the default is RMS values for AC quantities.
Common Class: Seq

Sequence
Name DataType m/o
Posii INT16S o
Posif FLT32 o
Negi INT16S o
Negf FLT32 o
Zeroi INT16S o
Zerof FLT32 o
q BSTR16 o
t BTIME6 o

IEEE-SA
6.4 Status (ST)
6.4.1 Status Input Single Bit (SI)
Status input single bit represents the single bit state of inputs.
Common Class: SI
Status Input Single Bit
Name DataType m/o
b1 BSTR1 m
q BSTR16 o
t BTIME6 o
6.4.2 Status Input Double Bit (SIT)
Status input double bit represents the 2-bit states of inputs. Common use of SIT for is defined by the com-
mon component DevST.
Common Class: SIT

Status Input Double Bit
Name DataType m/o
b2 BSTR2 m
q BSTR16 o
t BTIME6 o
6.4.3 Status Input Group (SIG)
Status input group represents a group of two or more bit states of inputs.
Common Class: SIG

Status Input Group
Name DataType m/o
b16 BSTR16 m
q BSTR16 o
t BTIME6 o
6.5 Setpoints (SP) and Settings Groups (SG)
6.5.1 Analog Output (AO)
Analog output represents the setting of a continuous output parameter that varies with time. AO is used to
model values involved in object interaction within IEDs or among field devices. If either i or f element is
written, the other element if present will be set to the equivalent value.

IEEE-SA
Common Class: AO
Analog Output
Name DataType m/o
i INT16S o
f FLT32 o
SBO IDENT o
6.5.2 Analog Input SetPoints
Analog input setpoints represents a collection of operating limits applicable to an individual MX point. The
limits can be used to trigger other actions.
Common Class: AISP

Analog Input SP
Name DataType m/o
hhl INT16S o
hl INT16S o
ll INT16S o
lll INT16S o
hhlf FLT32 o
hlf FLT32 o
llf FLT32 o
lllf FLT32 o
db INT16U o
6.5.3 Reclosing Intervals (INTERVAL)
INTERVAL represents the sequence of reclosing attempts and associated timing.
Common Class: SHOTS

Recloser Shots
Name DataType m/o
Tmr1 INT16S o
Tmr2 INT16S o
Tmr3 INT16S o
Tmr4 INT16S o
Tmr5 INT16S o
RsTmr INT16S o
6.5.4 Pickup Group (PUG)
PUG is a collection of values, associated with continuous time-varying input parameters being measured,
that when each value is exceeded, a specific protection control action is initiated. Note that the default is rms
for AC quantities.

IEEE-SA
CldLod is a pickup setting to allow for inrush of load current when the circuit has been off for a long time.
Common Class: PUG

Pickup Group
Name DataType m/o
Phsi INT16S o
Phsf FLT32 o
Neuti INT16S o
Neutf FLT32 o
CldLodi INT16S o
CldLodf FLT32 o
Hzi INT16S o
Hzf FLT32 o
6.5.5 Capacitor Bank Pickup Group (CBPUG)
CBPUG is a collection of values, associated with capacitor bank control input parameters being measured,
that when each value is exceeded, a specific capacitor bank control action is initiated. Note that the default is
rms for AC quantities. Maxi and Maxf are used to specify the upper control limit, Mini and Minf are used to
specify the lower control limit, and TimLmt is used for timers.
Common Class: CBPUG

Name DataType m/o
Maxi INT16S m
Maxf FLT32 o
Mini INT16S m
Minf FLT32 o
TimLmt INT32U m
6.5.6 Capacitor Bank Time Schedule (CBTim)
CBTim represents the daily time schedule for turning on (closing switch) and turning off (opening switch) a
capacitor bank. CBTim is used to model the daily operating schedule for a capacitor bank. Each of the com-
ponents represents the schedule for a weekday, using the DOWSch common component as follows:
Common Class: CBTim

Name DataType m/o
SunSch BTIME4[6] o
MonSch BTIME4[6] o
TueSch BTIME4[6] o
WedSch BTIME4[6] o
ThuSch BTIME4[6] o
FriSch BTIME4[6] o
SatSch BTIME4[6] o
DOW = Sun, Mon, Tue, Wed, Thu, Fri, Sat
DOWSch = BTIME4[6]

IEEE-SA
= BTIME4[StrtTim1, StopTim1, StrtTim2, StopTim2, StrtTim3, StopTim3]
6.5.7 Rectangular Coordinates (XY)
XY represents a collection of input parameters that define the location of a point in rectangular coordinates.
XY is used to model values involved in object interaction within IEDs or among field devices.
Common Class: XY
Rectangular Coordinates
Name DataType m/o
Xi INT16S o
Xf FLT32 o
Yi INT16S o
Yf FLT32 o
6.5.8 Polar Coordinates (VEC)
VEC represents a collection of input parameters that define a point in polar coordinates. VEC is used to
model values involved in object interaction within IEDs or among field devices.
Common Class: VEC

Polar Coordinates
Name DataType m/o
Magi INT16S o
Magf FLT32 o
Angi INT16S o
Angf FLT32 o
6.5.9 Rectangular Coordinate Impedance (RectZ)

RectZ represents a collection of input parameters that define the line impedance for electric circuit. RectZ is
used to model values involved in object interaction within IEDs or among field devices.
Common Class: RectZ

Rectangular Coordinate Impedance
Name DataType m/o
PosiZ XY o
NegZ XY o
ZeroZ XY o
q BSTR16 o
t BTIME6 o
6.5.10 Polar Coordinate Impedance (PoZ)

PoZ represents a collection of input parameters that define the line impedance for electric circuits. PoZ is
used to model values involved in object interaction within IEDs or among field devices.

IEEE-SA
Common Class: PoZ

Polar Coordinate Impedance
Name DataType m/o
PosiZ VEC o
NegZ VEC o
ZeroZ VEC o
q BSTR16 o
t BTIME6 o
6.5.11 Polar Blinder (PoB)

PoB represents a collection of input parameters that define a blinder or cutoff for impedance boundaries for
protection. YOfsi is used for reactive blinders, and XOfsi is used for resistive blinders. PoB is used to model
values involved in object interaction within IEDs or among field devices.
Common Class: PoB

Polar Blinder
Name DataType m/o
Angi INT16S M
XOfsi INT16S o
YOfsi INT16S o
6.5.12 Rectangular Blinder (RectB)

RectB represents a collection of input parameters that define a blinder or cutoff for impedance boundaries in
rectangular coordinates. RectB is used to model values involved in object interaction within IEDs or among
field devices.
Common Class: RectB

Rectangular Blinder
Name DataType m/o
XY1 XY o
XY2 XY o
6.5.13 Polar Quadrilateral (PQuad)
PQuad represents a collection of input parameters that define the line impedance quadrangle boundaries for
protection in polar coordinates. PQuad is used to model values involved in object interaction within IEDs or
among field devices.
Common Class: PQuad

Polar Quadrilateral
Name DataType m/o
UReact PoB m
LReact PoB m
LtRest PoB m
RtRest PoB m

IEEE-SA
6.5.14 Rectangular Quadrilateral (RQuad)
RQuad represents a collection of input parameters that define the line impedance quadrangle boundaries for
protection in polar coordinates. PQuad is used to model values involved in object interaction within IEDs or
Common Class: RQuad

Rectangular Quadrilateral
Name DataType m/o
ULXY RectB m
LLXY RectB m
URXY RectB m
LRXY RectB m
6.5.15 Curve (CURVE)
Curve is a collection of four input parameters that allow a user to define the characteristics of an equation
with four (4) coefficients. CURVE is used to model values involved in object interaction within IEDs or
Common Class: CURVE

Curve
Name DataType m/o
CoefA FLT32 o
CoefB FLT32 o
CoefC FLT32 o
CoefD FLT32 o
6.6 Controls (CO)
6.6.1 Binary Output (BO)
There are three forms of binary control: momentary, pulsed, and latched. The type of control is determined
by the control configuration for the point. Momentary or pulsed control is the configuration of either an
OnDur or OffDur in milliseconds in the control configuration. If both the OnDur and OffDur are greater than
0, the control will result in a pulsed output. The default for BO is b1.
Common Class: BO
Binary Output
Name DataType rwec m/o
b<n> BSTRn rw m
SBO IDENT r o
6.6.2 Double Control Output (DCO)
Double control output is a specialization of BO where the meaning of the binary value is defined by the com-
mon component OperDev. The contact closed duration in milliseconds is configurable. Common use of
DCO is defined by the common component OperDev.

IEEE-SA
Common Class: DCO

Double Control Output
OperDev b2 rw m
SBO IDENT r o
6.6.3 Pulsed Double Control Output(PDCO)
Pulsed double control output is a specialization of DCO that adds the number of pulses (NumPls), with the
shape of the pulses determined by the Control Configuration (CCF). Only RTU raise or lower commands to
a load tap changer or step-voltage regulator use this class.
Common Class: PDCO

Pulsed Double Control Output
OperDev b2 rw m
NumPls INT16U rw o
OnDur INT32U rw o
OffDur INT32U rw o
SBO IDENT r o
6.7 Configuration (CF)
6.7.1 Analog Configuration (ACF)
Analog configuration represents the configuration parameters for analog inputs and outputs.
Common Class: ACF

Analog Configuration
Name DataType m/o
s FLT32 o
o FLT32 o
u ENUM16 o
db INT16U o
min FLT32 o
max FLT32 o
Incr FLT32 o
MxTyp ENUM8 o
MxRef ENUM8 o
MxLoc ENUM8 o
SmpRate INT16U o
NumSmp INT16U o
pp BOOL o

IEEE-SA
6.7.2 Control Configuration (CCF)

Control configuration represents the configuration parameters for BOs. OnDur and OffDur define the shape
of the control pulse in milliseconds.
Common Class: CCF

Control Configuration
OnDur INT32U rw o
OffDur INT32U rw o
The table below defines the pulse control output.
Resulting control output OnDur OffDur

Momentary for number of seconds
>0 0
specified by OnDur
Pulse shape of the control >0 >0
Latched (default) 0 0
6.7.3 AcsBLOB DataObject Class (AcsBLOB)
The AcsBLOB DataObject is used for moving images that can contain anything. Often, BLOB DataObjects
will be allocated from a limited pool of buffers. Therefore, it cannot be assumed that any single set of data
will be continuously available. Also, the ability of a server to manage the segmented protocol for transfer of
BLOBs to simultaneous clients may be limited. To address this difficulty, a structured DataObject class is
defined that operates in a manner similar to SBO in that access to a BLOB must be selected prior to transfer.
This allows a server to serialize access to BLOB data at its discretion.
Common Class: AcsBLOB

Access BLOB Object
Name DataType m/o
BLOB BLOB m
State BOOL o
SelTimOut INT32U o
Fmt ENUM8 o
6.7.4 SBO Configuration (SBOCF)
SBO configuration represents the configuration parameters for optional SBO.
Common Class: SBOCF

SBO Configuration
SBOState BOOL rw m
SelTimOut INT32U rw m
SBOClass ENUM8 rw m

IEEE-SA
6.7.5 Ratio Configuration (RATIO)
RATIO represents the ratio between primary and secondary windings for the referenced measurements.
Common Class: RATIO

Ratio Configuration
Prif FLT32 rw o
Secf FLT32 rw o
Ratiof FLT32 rw o
6.8 Description (DC)
6.8.1 Analog Description (d)
Description is a text string that represents the description parameters for MX, ST, SP, and CO components.
Common Class: d
Description
Name DataType m/o
d VSTR32 m
6.8.2 Equipment Rating (EqRtg)
Equipment rating identifies the rating of the field equipment represented.
Common Class: EqRtg

Equipment Rating
Name DataType m/o
VRtg VSTR16 o
ContCurRtg VSTR16 o
HzRtg VSTR16 o
TempRtg VSTR16 o
FltCurRtg VSTR16 o
FltCurDur INT16U o
VARtg VSTR16 o
VArRtg VSTR16 o
UnitVArRtg VSTR16 o
NumUnit VSTR16 o
VTCktPhs CktPhs o
CTCktPhs CktPhs o
6.8.3 Connected Circuit (ConCkt)

Connected circuit identifies the circuit to which the field equipment is connected.
Ko is zero sequence compensation factor = (Zo-Z1)/3Z1, where Zo is zero sequence impedance, and Z1 is
positive sequence impedance.

IEEE-SA
Common Class: ConCkt

Connected Circuit
Name DataType m/o
CktID VSTR32 m
CktPhs ENUM8 m
LinLenm FLT32 o
ContCurRtg VSTR16 o
VRtg VSTR16 o
PosiSeqZ FLT32 o
NegSeqZ FLT32 o
ZeroSeqZ FLT32 o
Ko FLT32 o
6.9 Report Control Blocks

6.9.1 Report Control Block (RCB)
The RCB common class provides a generic report control block.
Common Class: RCB

Report control block
Name DataType m/o
RptEna BOOL m
RptID VSTR32 m
OptFlds BSTR8 m
BufTim INT32U m
Trgs INT16U m
SeqNum INT8U m
Enroll IDENT m
CriRpt BOOL m
DestAE VSTR32 m
EncOpt BSTR8 m
6.9.2 Basic Report Control Block (BasRCB)

The BasRCB common class provides a simplified front end object version of the RCB and event control
block (ECB) in which some of the values included in the generic RCB and ECB are fixed. Figure 6 shows
the relationship between the BasRCB attributes and those of the corresponding ECB and RCB attributes.
Note that the corresponding ECB and RCB need not be visible in the DeviceModel. Note also that each of
the attributes of the ECB and RCB are either completely specified in the model (i.e., fixed), unused, or
reflected in the BasRCB structure.

IEEE-SA
ECB
EveEna (TRUE)
InpDat
OutDat
EvaFct (Model Specific)
EvaCri
EvaPar (Param Name)
EvaCns(Model Specific)
RCB
BasRCB RptEna
RptID RptID
RptEna OptFlds
DatSet BufTim
OptFlds Trgs
BufTim SqNum
Trgs Enroll (ECB Name)
SqNum CriRpt FALSE
TrgOps DestAE (Client)
RBEPd EncOpt (Unused)
IntgPd
Params
RBEPd
IntgPd
Figure 6: Relationship of BasRCB attributes to ECB/RCB attributes
The detailed description of the BasRCB class object is shown below:
Common Class: BasRCB

Basic Report control block
Name DataType m/o
RptID VSTR32 m
RptEna BOOL m
DatSetNa IDENT m
OptFlds BSTR8 m
BufTim INT32U m
Trgs INT16U m
SeqNum INT8U m
TrgOps BSTR8 m
RBEPd INT32U m
IntgPd ING32U m
For the BasRCB, the following RCB values are fixed:
CriRpt is disabled
DestAE is single client
EncOpt is not applicable
Enroll is the name of the ECB for the report.

IEEE-SA
For the BasRCB, the following ECB values are fixed:
EvaEna is enabled
EvaFct is defined below
EvaPar is not applicable
EvaCri is not applicable
6.9.2.1 TrgOps
The following bits are defined as the default assignments for the TrgOps attribute. Note that the same bit
assignments apply for the definition of the reasons for inclusion bit strings in reports generated for the Bas-
RCB object. Note also that these default bit assignments may be redefined in any specific model if model
specific evaluation functions are defined.
Trigger Condition Bit # Definition

Reserved 0 Reserved
CndDatChg 1 Change of any value, possibly with deadbanding
CndQuChg 2 Change of quality field
CndFrzChg 3 Change of frozen value
6.9.2.2 Evaluation Function
DataObject values for the enrolled DataSet are reported whenever:
The i value for an included AI DataObject exceeds the corresponding db, or limit, and the Cnd-
DatChg bit of TrgOps is set.
The b value changes, and the CndDatChg bit of TrgOps is set.
The q value changes and the CndQuChg bit of TrgOps is set, or
The fr value changes and the CndFrzChg bit of TrgOps is set, or
The IntgPd expires.
When reporting due to a change in frozen value, all accumulators should be reported, even if their frozen
value has not changed.
Note: Using these evaluation functions, a variety of reporting schemes, as seen in Table 13, can be requested
by the client.
Table 13: BasRCP Reporting Schemes
TrgOps
IntgPd RBEPd Action
CndDatChg CndQuChg
1 1 0 0 Report data and quality changes immediately (by exception)
Report data and quality changes immediately (by exception), with
1 1 30000 0
30 second integrity scan
Report data and quality changes every 10 seconds (by exception),
1 1 60000 10000
with 60 second integrity scan
1 0 0 0 Report data changes immediately (by exception)
0 1 0 0 Report quality changes immediately (by exception)
0 0 5000 0 Report all data every 5 seconds
1 1 0 5000 Report all data and quality changes by exception every 5 seconds

IEEE-SA
The IntgPd attribute controls when an artificial change is assumed to occur to all of the enroll DataSet
DataObjects. RBEPd, BufTim, and Trgs do not control when this change data shall be reported. Note that
integrity scans are buffered in the order they are generated, along with other buffered reports.
The BufTim and Trgs attributes control when to send a nonintegrity report. When RBEPd is zero and a new
change is detected, the data shall not be sent until either:
The BufTim expires

The total number of buffered changes reaches the Trgs
The RptEna attribute controls whether the changes are reported spontaneously. No reports shall be generated
for the enroll DataSet until RptEna is set to TRUE. RptEna is initially FALSE whenever the device powers
up, to avoid flooding the network with reports until the master is ready.
In the case where a second event agent notification of the same DataObject has occurred prior to the expira-
tion of RCB.BufTim and/or the satisfying of the RCB.Trgs criteria, a reporting agent may behave as if
RCB.BufTim has expired (and/or RCB.Trgs has been satisfied) and immediately queue the report for trans-
mittal. (For example, a second status change will cause the immediate queuing of the report for transmittal; a
second analog change will not.)
If the reporting agent behaves in this manner, RCB.BufTim shall restart the timer of duration RCB.BufTim,
and RCB.Trgs shall be reset to its original value. Upon completion of this procedure, the second notification
shall be processed by the reporting agent.
6.9.3 Accumulator Freeze Control Block (AccFCB)
The AccFCB common class provides a basic control block for freezing accumulator data objects. There must
be a corresponding BasRCB (or RCB and ECB combination) to control the reporting of the values as they
are frozen. The ECB evaluation function must trigger upon the freezing of the DataSet members. All
members of the output DataSet (AccSet) will be included in the report.
Common Class: AccFCB

Accumulator Freeze Control Block
Name DataType m/o
AccSet IDENT m
FrzEna BOOL m
StartTim BTIME6 m
FrzPd INT32U m
FrzRs BOOL m
AccSet: The name of the DataSet of objects to be frozen.

FrzEna: The Boolean value that controls the overall freezing operation. If TRUE, freezing will
occur as specified in the other AccFCB attributes. If FALSE, no freezing will occur.
StrtTim: The starting time (BTIME6) of the freeze process. If the current time is later than the
StartTim, the first freeze must occur at the next freeze interval (FrzPd) expiration, computed from
the StartTim setting.
FrzPd: The time interval (in milliseconds) between freeze operations.
FrzRs: The used to reset the counter to zero.
Note that the freeze control block controls the freeze operation only. If the same DataSet (containing accu-
mulators) is referenced in a BasRCB (or ECB/RCB combination) which contains an appropriate accumula-
tor evaluation function (i.e., trigger on freeze), then all DataSet values will be reported following each freeze
operation.

IEEE-SA
6.9.4 Protection Action (PACT)
PACT is a special peer-to-peer communication report structure used by protection IEDs. PACT represents a
collection of parameters that define the digital input and digital output status of the sending IED. PACT is
used to model protection messages for peer-to-peer communications between and within protection IEDs.
Common Class: PACT

Protection Action
Name DataType m/o
Sending IED IDENT m
t BTIME6 m
SqNum INT32U m
StNum INT32U m
HoldTim INT32U m
BackTim INT32U m
PhsID INT16U m
DNA BSTR64 m
UserSt BSTR128 m
6.9.5 Zero Crossing (XING)
XING is a special peer-to-peer communication report structure used in synchronizing device operations.
XING represents a collection of parameters that enable the receiving IED to accurately predict when the cur-
rent waveform will cross zero.
Common Class: XING

Zero Crossing
Name DataType m/o
Tim BTIME6 m
Dir BOOL m
PhsID CktPhs m
FundVi INT16S m
6.10 Event Control Block (ECB)

Common Class: ECB
Event control block
Name DataType m/o
EvtEna BOOL m
InDat IDENT m
OutDat IDENT m
EvaFct VSTR32 m
EvaCri IDENT m
EvaPar IDENT m
EvaCns IDENT m

IEEE-SA
6.11 Log Control Block (LCB)

Common Class: LCB
Log Control block
Name DataType m/o
LogEna BOOL m
LogNam IDENT m
LogEnr<n> IDENT m
FillLvl INT8U m
LogSize INT32U m
LogWrp BOOL o
LogSt BSTR5 m
FillST BOOL m
LogOpt BSTR4 m
OldEnt INT32U m
NewEnt INT32U m
NumEnt INT32U m
NumOvr INT32U
LstEntDisc INT32U m
OldTim BTIME6 o
NewTim BTIME6 o
6.12 Access (AX)

6.12.1 Tags (Tag)
The purpose of Tag is to advise clients not to operate the device. Tag also provides background information
on why the device should not be operated, when the Tag was placed on the device and by whom, etc.
Common Class: Tag

Tags
Name DataType m/o
TagID INT8U m
TagTyp BSTR8 m
TagD VSTR128 m
TagOwn VSTR32 m
7. Basic Building Bricks

Basic building bricks are collections of DataObjects, common components, and structures based on common
classes that logical device models are assembled from. These bricks are aggregated together to form logical
device models that represent real world devices. This section includes a list of bricks and provides the
DataObject models for the bricks.
Note that all brick names are five characters in length. With the exception of the GLOBE brick that occurs
only once in a logical or physical device, the fifth character n is an index that may range from 09, and A
Z, for a specific instance of the brick within a LogicalDevice. If there is only one instance of a brick, the
default index is 0, and is always included and shown.

IEEE-SA
The following standard bricks are modeled as shown in Table 14.
Table 14: Building Brick Models and Descriptions
IEEE Std 37.2

Functional Area Model Description
Device Function
Global attributes GLOBE Global attributes for logical devices/servers
Basic OILCn Oil condition
IGASn Inert gas
VACUn Vacuum
CONCn Gas concentration
FINDn Fault indicator
INSUn Insulation
PSUPn Power supply
AUTOn Automatic control logic
Generic I/O GAINn Generic analog input
GACCn Generic accumulator
GSPTn Generic set point
GINDn Generic indication
GCTRn Generic control
Measurement PMXUn Polyphase measurement unit
EMTRn Polyphase energy measurement unit
SYNCn Synchronism check unit
TEMPn Temperature measurement unit
PQUNn Power quality measurement unit (TBD)
Transformer TANKn Transformer tank
BUSHn Bushings
HTEXn Heat exchanger
PUMPn Pump
CFANn Cooling fan
LTCHn Load tap changer
Switch SWITn Switch
SDRVn Switch drive mechanism
MOSWn Motorized switch
CBKRn Circuit breaker 52
BKRFn Breaker failure
Reactive CAPBn Capacitor bank
CAPLn Capacitor control logic
Protection BROBn Basic relay object (building block)
BTCOn Basic time curve object (building block)
DISTn Distance 21
VPHZn Volts per Hz relay 24
SYNCn Synchronizing or synchronism-check 25
UVRLn Undervoltage relay 27
DPRLn Directional power relay 32
UCPRn Under current or under power 37
PBRLn Rev. phase or phase balance current relay 46

IEEE-SA
Table 14: Building Brick Models and Descriptions (continued)
IEEE Std 37.2

Functional Area Model Description
Device Function
TTRLn Machine or transformer thermal relay 49
IOCRn Instantaneous overcurrent 50
TOCRn Time overcurrent 51
PFRLn Power factor relay 55
OVRLn Overvoltage 59
VCBRn Voltage or current balance relay 60
HIZRn Ground detector 64 HiZ
DOCRn Directional overcurrent 67
PAMRn Phase angle measuring relay 78
RECRn Reclosing relay 79
FREQn Frequency 81
CPWRn Carrier or pilot-wire relay 85
DIFFn Differential 87
7.1 GLOBE
GLOBE is a server or LogicalDevice level building block that is used to model attributes that are global to
the server or the LogicalDevice. See Figure 7. GLOBE includes data objects that are used to control the
access and use of data objects included in the Functional Component, SG (Settings Group). See Table 15.
CopySetGrp,
SaveSetGrp ModeDS
ActSetGrp LocRemDS
ActSG
EditSG
GLOBE
Figure 7: GLOBE

IEEE-SA
Table 15: GLOBE Model
FC Object Name Class rwec m/o Description

ST Operation Information
ModeDS SIT r m Device is: in test, off-line, available, or unhealthy
LocRemDS SIT r m The mode of control, local or remote (DevST)
ActSG INT8U r o Global active settings group in use
EditSG INT8U r o Global SG selected and visible for editing
AuxIn<n> BSTR16 r o Block of 16 auxiliary inputs
SP PreSetDNA DNA rw o Preset DNA output values if enabled
ForDNA DNA rw o Forced DNA input values if enabled
DefDNA DNA rw o Default DNA input values if enabled
CO CopySG INT8U w o Copies SG to visible buffer for editing
SaveSG INT8U w o Saves edit buffer SG as designated SG
ActSG INT8U w o Selects designated SG as the active SG
IndRs BOOL w o Resets indicators, targets, and LEDs
AuxOut<n> BOOL[16] w o Block of 16 individually auxiliary outputs
CF Img AcsBLOB rw o Proprietary information
ClockTOD BTIME rw o Global date and time for data logging
SelOutDNA DNA rw o Selects preset or real DNA output values
SelInDNA DNA rw o Selects forced, real or default DNA input values
NeutRef BOOL rw o Configures measurement reference to neutral/ground
CTRat RATIO rw o Global CT ratios
VTRat RATIO rw o Global VT ratios
DC All ST d rw o
AX SGEditor Tag rw o Controls access to editing capability
RP brcbMX BasRCB rw o Controls reporting of measurements
brcbST BasRCB rw o Controls reporting of status points
GOOSE PACT rw o Reports IED inputs and outputs
7.1.1 SelOutDNA
Select output DNA is used by the sending IED to select, on a per bit pair basis, whether the value of the bit
pair in the GOOSE DNA is from the real IED DNA or from preset DNA values. See Figure 8 and Table 16.

IEEE-SA
Table 16: SelloutDNA
Bit Order 00 01 10 11
Bit
Bit # Value 0 1 2 3
Pair
Definition State State State State
0, 1 1 OperDev Invalid Preset Pass through Invalid
2, 3 2 Lock Out Invalid Preset Pass through Invalid
4, 5 3 Initiate reclosing Invalid Preset Pass through Invalid
6, 7 4 Block reclosing Invalid Preset Pass through Invalid
8, 9 5 Breaker failure initiate Invalid Preset Pass through Invalid
10, 11 6 Send transfer trip Invalid Preset Pass through Invalid
12, 13 7 Receive transfer trip Invalid Preset Pass through Invalid
14, 15 8 Send perm Invalid Preset Pass through Invalid
16, 17 9 Receive perm Invalid Preset Pass through Invalid
18, 19 10 Stop perm Invalid Preset Pass through Invalid
20, 21 11 Send block Invalid Preset Pass through Invalid
22, 23 12 Receive block Invalid Preset Pass through Invalid
24, 25 13 Stop block Invalid Preset Pass through Invalid
26, 27 14 BkrDS Invalid Preset Pass through Invalid
28, 29 15 BkrPhsADS Invalid Preset Pass through Invalid
30, 31 16 BkrPhsBDS Invalid Preset Pass through Invalid
32, 33 17 BkrPhsCDS Invalid Preset Pass through Invalid
34, 35 18 DiscSwDS Invalid Preset Pass through Invalid
36, 37 19 Interlock DS Invalid Preset Pass through Invalid
38, 39 20 LineEndOpen Invalid Preset Pass through Invalid
40, 41 21 Mode Invalid Preset Pass through Invalid
42, 43 22 Event Invalid Preset Pass through Invalid
44, 45 23 Fault present Invalid Preset Pass through Invalid
46, 47 24 Sustained arc Invalid Preset Pass through Invalid
48, 49 25 Downed conductor Invalid Preset Pass through Invalid
50, 51 26 Sync closing Invalid Preset Pass through Invalid
52, 53 27 Reserved Invalid Preset Pass through Invalid

IEEE-SA
IED
DNA
Bit
Pair
1
2
3
4
.
. Select
. DNA
64 Bit Pair
1
2
GOOSE
3
DNA
PreSet 4
DNA .
Bit Pair .
.
1 64
2
3
4
.
.
.
64
Sending IED DNA value Selection
Figure 8: Sending IED DNA Value Selection
7.1.2 SelInDNA
Select input DNA is used by the receiving IED to select, on a per bit pair basis, whether the value of the bit
pair in the GOOSE DNA is from the real IED DNA or from preset DNA values, and what to do with real
IED values when the time for a messages validity expires. See Figure 9.
7.1.2.1 Default Values
Default values are values used under the following conditions:
The time for the message being valid has expired, and
The SelInDNA for the bit pair is set to default
7.1.2.2 PreSet Values
PreSet values are values used to force the value of a DNA bit pair to a preset value when the SelInDNA for
the bit pair is set to PreSet.
7.1.2.3 Pass Through
When the SelInDNA is set to Pass Through, the GOOSE DNA value is used. When the validity time for the
DNA has expired, the last GOOSE DNA value for the bit pair is used rather than the default value. See
Table 17.

IEEE-SA
Goose
DNA
Bit Pair
1
2
3
4
.
.
.
64
Default Select
DNA DNA
Bit Pair Bit Pair
1 1
2 2 Input
3 3 DNA
4 4
. .
. .
. .
64 64
PreSet
DNA
Bit Pair
1
2
3
4
.
.
.
64
Figure 9:IED
Receiving Receiving
DNA valueIED DNA Value
Selection Selection
Table 17: SellnDNA
Bit Order 00 01 10 11
Bit
Bit # Value 0 1 2 3
Pair
0, 1 1 OperDev Default value Preset Pass through Invalid
2, 3 2 Lock Out Default value Preset Pass through Invalid
4, 5 3 Initiate reclosing Default value Preset Pass through Invalid
6, 7 4 Block reclosing Default value Preset Pass through Invalid
8, 9 5 Breaker failure initiate Default value Preset Pass through Invalid
10, 11 6 Send transfer trip Default value Preset Pass through Invalid
12, 13 7 Receive transfer trip Default value Preset Pass through Invalid

IEEE-SA
Table 17: SellnDNA (continued)
Bit Order 00 01 10 11
Bit
Bit # Value 0 1 2 3
Pair
14, 15 8 Send perm Default value Preset Pass through Invalid
16, 17 9 Receive perm Default value Preset Pass through Invalid
18, 19 10 Stop perm Default value Preset Pass through Invalid
20, 21 11 Send block Default value Preset Pass through Invalid
22, 23 12 Receive block Default value Preset Pass through Invalid
24, 25 13 Stop block Default value Preset Pass through Invalid
26, 27 14 BkrDS Default value Preset Pass through Invalid
28, 29 15 BkrPhsADS Default value Preset Pass through Invalid
30, 31 16 BkrPhsBDS Default value Preset Pass through Invalid
32, 33 17 BkrPhsCDS Default value Preset Pass through Invalid
34, 35 18 DiscSwDS Default value Preset Pass through Invalid
36, 37 19 Interlock DS Default value Preset Pass through Invalid
38, 39 20 LineEndOpen Default value Preset Pass through Invalid
40, 41 21 Mode Default value Preset Pass through Invalid
42, 43 22 Event Default value Preset Pass through Invalid
44, 45 23 Fault present Default value Preset Pass through Invalid
46, 47 24 Sustained arc Default value Preset Pass through Invalid
48, 49 25 Downed conductor Default value Preset Pass through Invalid
50, 51 26 Sync closing Default value Preset Pass through Invalid
52, 53 27 Reserved Default value Preset Pass through Invalid
7.1.2.4 GLOBE DataSets
Components grouped to accommodate convenient access of related points. GLOBE contains DataSets for
retrieval by a client. Numerous DataSets may be defined for the LogicalDevice object model. The DataSets
provided by GLOBE contain the sum of ALL of the attributes contained in each of the DataSets contained
by the individual building blocks. The main DataSets defined for the GLOBE object model are as follows:
DataSet Components
DataSet No. DatSet
(Object Attributes)
1 LogDev.MX MX for all included bricks
2 LogDev.ST ST for all included bricks
7.1.3 Generic Object Oriented Substation Event (GOOSE)

There are a number of issues that must be addressed for peer-to-peer communications of protective relay
IEDs. In general, this type of communications:

IEEE-SA
Is mission sensitive and time critical

Supports variable time contact closures
Must be highly reliable
GOOSE is based upon the asynchronous reporting of an IEDs digital outputs status to other peer (enrolled)
IEDs. For the purposes of this discussion, input and output status is seen from the viewpoint of the reporting
IED. The associated IEDs receiving the message use the information contained therein to determine what the
appropriate protection response is for the given state. See Figure 10. Note that the decision of the appropriate
action to GOOSE messages, and the action to take should a message time out due to a communication fail-
ure, is determined by local intelligence in the IED receiving the GOOSE message.
RECEIVING
SENDING IED
IED GOOSE
(b)
(a)
RECEIVING
IED
(c)
"
"
"
Substation
LAN
RECEIVING
IED
(n)
Figure 10
Each system supporting GOOSE outputs must be able to support the transmission (whenever the status
changes) and repeated re-transmission (as long as the output is stable) of the GOOSE messages using multi-
cast techniques. Each transmission and re-transmission contains the status output, time of last status change,
sequence of the of the status change, sequence number of the re-transmission, time interval since the last sta-
tus change, and the hold time interval (interval during which the next retransmission is expected). The fol-
lowing communications parameters must be locally configurable:
Multicast destination address of the message.

The parameters for computing retransmission intervals, which must increase from a short interval
(10ms or less) up to a relatively large interval (up to one minute) while the status is stable.
7.1.3.1 Reliability
To achieve a high level of reliability, messages will be repeated as long as the state persists. Thus, GOOSE
messages need not be acknowledged and so may be multicast. To maximize dependability and security, a
message will have a time to live that will be known as hold time. After the hold time expires, the message
(status) will expire unless the same status message is repeated or a new message is received prior to the expi-
ration of the hold time.
The repeat time for the initial GOOSE message will be short (e.g., the order of 10 milliseconds) to help
ensure that the state is reported to all enrolled peers. Subsequent messages may have an increase in repeat
and hold times until a maximum is reached. (The times and progressions are parameterized.)

IEEE-SA
The GOOSE message will contain information that will allow the receiving IED to know that a message has
been missed, a status has changed and the time since the last status change. The time of the last status
change, called back time, allows a receiving IED to set local timers (e.g., a BFI timer), relating to a given
event even if repeat messages were missed.
7.1.3.2 Health and Status
A newly activated IED, upon power up or reinstatement to service, will send current status as an initial
GOOSE. Any IED can request a specific IEDs status at any time. Also, all IEDs will send out their status
message on a periodic basis (based on a configuration parameter), e.g., at least once each minute. This will
ensure that all associated IEDs will know the current status of their peers.
7.1.3.3 Common Components of GOOSE
The common components of the GOOSE class object are defined below. See Table 18.
7.1.3.3.1 Back Time
The time since the last status change. The receiving IED can use back time to set appropriate local times
associated with the original state even if intervening messages were lost.
7.1.3.3.2 Hold Time
The time that a particular message (status) is held before it is canceled. Cancellation, depending on the status
reported, may result in an automatic reset of the conditions (e.g., a BFI timer is canceled or the removal of a
block condition). In order for the status conditions within the message to remain valid, a repeat of the mes-
sage must be received before the hold time expires. The hold time is incremented each time the message is
sent and may follow geometric progression (e.g., 10, 20, 30, 40, 50...) up to a maximum of one minute. (The
timers and progressions are parameterized.) The progression timers reset when a new GOOSE is created.
7.1.3.3.3 Refresh Interval
The time between the repeat messages. The interval shall be less than 1/2 of the hold time. The refresh time
is parameterized and shall be randomized to minimize collisions.
7.1.3.3.4 Sequence Number
This number is incremented by one each time a message is sent. It rolls over after the maximum count is
reached.
7.1.3.3.5 State Number
The state number is incremented by one each time an IED sends information that is new or changed.
Thus, this number uniquely tags the GOOSE event. It rolls over after the maximum count is reached.
7.1.3.3.6 Sending IED IDENT
The sending IED IDENT uniquely names the device reporting the GOOSE. Therefore, a given reporting IED
may handle several devices.
7.1.3.3.7 t
Time stamp of the time the GOOSE message was sent.

IEEE-SA
7.1.3.3.8 User Status
User status is a group of 128 bit pairs defined as needed by the utility or vendor in conveying additional
information.
Table 18 includes the common components used to facilitate the GOOSE class object.
Table 18: Common Components Required for GOOSE

Sending IED Sending IED IDENT IDENT
t GOOSE time stamp BTIME6
SqNum Message sequence number INT16U
StNum Event sequence number INT16U
HoldTim Time to wait before RS INT16U
BackTim Time since event INT16U
PhsID Identifies faulted phases INT16U
DNA Protection DNA BSTR64
UserSt User defined bit string, used in bit pairs BSTR256
7.1.3.4 DNA
The goal is to have a single message that conveys all required protection scheme information regarding an
individual IED. This message uniquely reports the status of the devices in the IED to its peers per the enroll-
ment list. Table 19 defines the use of DNA for protection messages.
Table 19: Use of DNA for Protection Messages
Bit Order 00 01 10 11
Bit
Bit # Value 0 1 2 3
Pair
0, 1 1 OperDev Normal Trip Close Invalid
2, 3 2 Lock Out Invalid Normal LO Invalid
4, 5 3 Initiate reclosing Normal Cancel Auto reclosing Invalid
6, 7 4 Block reclosing Normal Cancel Block Invalid
8, 9 5 Breaker failure initiate Normal Cancel Initiate Invalid
10, 11 6 Send transfer trip Normal Cancel Set Invalid
12, 13 7 Receive transfer trip Normal Cancel Set Invalid
14, 15 8 Send perm Normal Cancel Send perm Invalid
16, 17 9 Receive perm Normal Cancel Receive perm Invalid
18, 19 10 Stop perm Normal Cancel Stop perm Invalid
20, 21 11 Send block Normal Cancel Send block Invalid
22, 23 12 Receive block Normal Cancel Receive block Invalid
24, 25 13 Stop block Normal Cancel Stop block Invalid
26, 27 14 BkrDS Between Open Closed Invalid
28, 29 15 BkrPhsADS Between Open Closed Invalid
30, 31 16 BkrPhsBDS Between Open Closed Invalid
32, 33 17 BkrPhsCDS Between Open Closed Invalid

IEEE-SA
Table 19: Use of DNA for Protection Messages (continued)
Bit Order 00 01 10 11
Bit
Bit # Value 0 1 2 3
Pair
34, 35 18 DiscSwDS Between Open Closed Invalid
36, 37 19 Interlock DS Invalid Noninterlock Interlock Invalid
38, 39 20 LineEndOpen Between Open Closed Invalid
40, 41 21 Mode Test Offline Available Unhealthy
42, 43 22 Event Invalid Normal Event Invalid
44, 45 23 Fault present Invalid Clear Present Invalid
46, 47 24 Sustained arc Invalid Normal Present Invalid
48, 49 25 Downed conductor Invalid Normal Downed Invalid
50, 51 26 Sync closing Normal Cancel Initiate Invalid
52, 53 27 Reserved
54, 55 28 Reserved
56, 57 29 Reserved
58, 59 30 Reserved
60, 61 31 Reserved
62, 63 32 Reserved
7.2 Basic Bricks

7.2.1 Oil Insulation(OILC)
OILC is the present measurements relating to oil insulation. See Figure 11 and Table 20.
T
Lev
Color
Diel
Tension
H2O
Acid
DissFactor
Oil Insulation (OILC)
Figure 11: Oil Insulation (OILC)

IEEE-SA
Table 20: OILC Model
FC Name Class rwec m/o Range Description

MX TopT AI r m -50 to 200C Tank top oil temperature
BotT AI r m -50 to 200C Tank bottom oil temperature
TkLev AI r m Level in mm relative to 20/25 C
ConsvLev AI r o Level in mm relative to 20/25C
Color AI r o 0 to 1.0 Oil color per ASTM D1500
Dielectric strength of the oil per ASTM
Diel1816A AI r o 0 to 50kV
D1816, 0.04 inch gap
Dielectric strength of the oil per ASTM
Diel1816B AI r o 0 to 100kV
D1816, 0.08 inch gap
Diel877 AI r o 0 to 50kV Oil Dielectric strength per ASTM D877
IfTen AI r o 0 to 50 Interfacial Ten mN/M per ASTM D971
ppm of dissolved moisture per ASTM
H2O AI r o 0 to 100
D1533
Acid AI r o 0 to 0.50 Oil acid mgKOH/g per ASTM D974
DissFact AI r o 0.00 to 0.02 Oil dissipation factor (tan) at Oper. T
CF All OILC.MX ACF rw o Configuration for all OILC.MX
DC All OILC.MX d rw o Description of all OILC.MX
RP brcbMX BasRCB rw m Controls reporting of measurements
7.2.1.1 Default Settings for RP Objects
Attribute brcbMX
RptID NULL
RptEna FALSE
DatSet MX
OptFlds All options
BufTim 0
Trgs 0
SeqNum 0
TrgOps CndDatChg
RBEPd 0
IntgPd 0
7.2.1.2 Report Evaluation Functions
brcbMX: Report all changes in value that exceed deadbands specified in CF for each data set
member.
7.2.1.3 DataSet
The OILC brick contains one DataSet, OILC.MX, for retrieval by a client.

IEEE-SA
7.2.2 Inert Gas (IGAS)
The IGAS brick represents inert gasses used for insulating high voltage power equipment. See Figure 12 and
Table 21.
Inert Gas
TankPres
BtlPres
Inert Gas (IGAS)
Figure 12: Inert Gas (IGAS)
Table 21: IGAS Model

TankPres AI r o 5 to 10 psig Pressure of gas blanket
MX
BtlPres AI r o 5 to 5000 psig Pressure of gas in bottle
CF All IGAS.MX ACF rw o Configuration for all included IGAS.MX
DC All IGAS.MX d rw o Description for all included IGAS.MX
Attribute brcbMX
RptID NULL
RptEna FALSE
DatSet MX
OptFlds All options
BufTim 0
Trgs 0
SeqNum 0
TrgOps CndDatChg
RBEPd 0
IntgPd 0
brcbMX: Report all changes in value that exceed deadbands specified in CF for each DataSet mem-
ber.
7.2.2.3 DataSets
The IGAS brick contains one DataSet, IGAS.MX, for retrieval by a client.

IEEE-SA
7.2.3 Vacuum (VACU)
The VACU brick represents vacuum when used for insulating high voltage power equipment. See Figure 13
and Table 22.
Vacuum
VacBtl1
VacBtl2
VacBtl3
Vacuum (VACU)
Figure 13: Vacuum (VACU)
Table 22: VACU Model

ST VacBtl1 SI r o Status of vacuum bottle, pole 1
VacBtl2 SI r o Status of vacuum bottle, pole 2
VacBtl3 SI r o Status of vacuum bottle, pole 3
DC All VACU.ST d rw o Description for all included VACU.ST
RP brcbST BasRCB rw m Controls reporting of measurements
Attribute brcbST
RptID NULL
RptEna FALSE
DatSet ST
OptFlds All options
BufTim 0
Trgs 0
SeqNum 0
TrgOps CndDatChg
RBEPd 0
IntgPd 0
brcbST: Report all change of state for each DataSet member.
7.2.3.3 DataSets
The VACU brick contains one DataSet, VACU.ST, for retrieval by a client.

IEEE-SA
7.2.4 Gas Concentration (CONC)
The Gas Concentration (CONC) brick is used for measuring the concentration of noninert gasses found in a
gas or liquid insulating medium, i.e., concentration of noninsulating gasses in insulating gas space or dis-
solved gasses in oil, in parts per million (ppm). See Figure 14 and Table 23.
O2 N 2
H2 CH 4
C 2 H6
C2H4 CO
CO 2 ppm
Tot
TotComb
Gas Concentration (CONC)
Figure 14: Gas Concentration (CONC)
Table 23: CONC Model

MX O2 AI r o 0 to 100,000 ppm of oxygen
N2 AI r o 0 to 100,000 ppm of nitrogen
H2 AI r o 0 to 10,000 ppm of hydrogen
CH4 AI r o 0 to 10,000 ppm of methane
C2H6 AI r o 0 to 10,000 ppm of ethane
C2H4 AI r o 0 to 10,000 ppm of ethylene
C2H2 AI r o 0 to 10,000 ppm of acetylene
CO AI r o 0 to 10,000 ppm of carbon monoxide
CO2 AI r o 0 to 10,000 ppm of carbon dioxide
Tot AI r o 0 to 100,000 ppm of total non inert gas
TotComb AI r o 0 to 100,000 ppm of total combustible gas
CF All CONC.MX ACF rw o Configuration for all CONC.MX
DC All CONC.MX d rw o Description for all CONC.MX

IEEE-SA
Attribute brcbMX
RptID NULL
RptEna FALSE
DatSet MX
OptFlds All options
BufTim 0
Trgs 0
SeqNum 0
TrgOps CndDatChg
RBEPd 0
IntgPd 0
brcbMX: Report all changes in value that exceed deadbands specified in CF for each DataSet
member
7.2.4.3 DataSets
The CONC brick contains one DataSet, CONC.MX, for retrieval by a client.
7.2.5 Fault Indicator (FIND)
See Figure 15 and Table 24.
FIRs FltMagA
FIPuThre
FIPuHyst
FIA
FIInrushDel
FIB
FIZeroThre
FIC
FltTmrRs
FIN
Fault Indicator (FIND)
Figure 15: Fault Indicator (FIND)

IEEE-SA
Table 24: FIND Model

MX FltMagA WYE o Fault magnitude amperes
ST FIA BSTR16 o Indicates normal or overcurrent fault types
FIB BSTR16 o Indicates normal or overcurrent fault types
FIC BSTR16 o Indicates normal or overcurrent fault types
FIN BSTR16 o Indicates normal or overcurrent fault types
SP FIPuThre PUG o Pickup Thre for phase A, B, C, N
FIPuHyst PUG o Pickup Hyst for phase A, B, C, N
FIInrushDel PUG o Inrush delay for phase A, B, C, N
FIZeroThre PUG o Zero Thre for phase A, B, C, N
FltTmrRs AO o Tim of no fault NumFltToLO is Rs
CO FIRs BO o Fault indicator reset
CF All FIND.MX ACF m Configuration of ALL included FIND.MX
All FIND.SP ACF m Configuration of ALL included FIND.SP
All FIND.CO CCF m Configuration of ALL included FIND.CO
DC All FIND.MX d o Description of ALL included FIND.MX
All FIND.ST d o Description of ALL included FIND.ST
All FIND.SP d o Description of ALL included FIND.SP
All FIND.CO d o Description of ALL included FIND.CO
RP brcbST BasRCB rw o Controls reporting of status points
AS LogDev<n> TBD o Defines path for peer-to-peer communication
7.2.5.1 Report Default Settings
Attribute brcbMX brcbST

RptID NULL NULL
RptEna FALSE FALSE
DatSet MX ST
OptFlds All options All options
BufTim 0 0
Trgs 0 0
SeqNum 0 0
TrgOps CndDatChg CndDatChg
RBEPd 0 0
IntgPd 0 0
member.

IEEE-SA
7.2.5.3 DataSets
A number of data sets are defined for FIND.
DataSet
DataSet
DatSet Components
No.
(Object Attributes)
1 FIND.MX All measurements
2 FIND.ST All status points
3 FIND.SP All setpoints
7.2.6 Insulation (INSU)
The INSU provides a logical representation of an field device insulation system. See Figure 16 and Table 25.
Pres
Den
Lev
PresAlm
DenAlm
LevAlm
Insulation (INSU)
Figure 16: Insulation (INSU)
Table 25: INSU Model

MX Pres AI r o Pressure of insulating medium
Den AI r o Density of insulating medium
Lev AI r o Level of insulating medium
ST PresSt SIT o The condition of the insulating medium pressure
Den SIT o The condition of the density of the insulating gas
LevSt SIT o The condition of the level of the insulating medium
SP LoPresAlm ACF o Thre below which an alarm is generated
LoPresLO ACF o Thre below which the Bkr is locked-out
HiPresAlm ACF o Thre above which an alarm is generated
LoDenAlm ACF o Thre below which an alarm is generated
LoDenLO ACF o Thre below which the Bkr is locked-out
HiDenAlm ACF o Thre above which an alarm is generated
LoLevAlm ACF o Thre below which an alarm is generated
LoLevLO ACF o Thre below which the Bkr is locked-out
HiLevAlm ACF o Thre above which an alarm is generated
PoleDiscTim ACF o The Tim between the Oper of the first and last Bkr pole
CF All INSU.MX ACF rw o Configuration for all included INSU.CO

IEEE-SA
Table 25: INSU Model (continued)

All INSU.SP ACF rw o Configuration of all included INSU.SP
DC All INSU.MX d o Description of all included INSU.MX
All INSU.ST d o Description of all included INSU.CO
All INSU.SP d o Description of all included INSU.SP
RP brcbMX BasRCB rw o Controls reporting of measurements
brcbST BasRCB rw o Controls reporting of status points
AX LogDev<n> TBD

RptID NULL NULL
RptEna FALSE FALSE
DatSet MX ST
BufTim 0 0
Trgs 0 0
SeqNum 0 0
RBEPd 0 0
IntgPd 0 0
brcbMX: Report all changes in value that exceed deadbands specified in CF for each DataSet member.
7.2.6.3 DataSets
Two DataSets are defined for INSU.
DataSet
DataSet No. DatSet Components
(Object Attributes)
1 INSU.MX All measurements
2 INSU.ST All status
3 INSU.SP All Setpoints

IEEE-SA
7.2.7 Power Supply (PSUP)
BattV
StartBattTest
PwrSupSt
Power Supply (PSUP)
Figure 17: Power Supply
Table 26: PSUP Model

MX BattV AI o Battery voltage
ST PwrSupSt SIG o Switch power supply status indication
CO StartBatTest BO o Start battery test
CF All PSUP.CO CCF o Configuration of all included PSUP.CO
DC All PSUP.ST d m Description of all included PSUP.ST
All PSUP.CO d m Description of all included PSUP.CO
RP brcbST BasRCB rw m Controls reporting of status points

RptID NULL NULL
RptEna FALSE FALSE
DatSet MX ST
BufTim 0 0
Trgs 0 0
SeqNum 0 0
RBEPd 0 0
IntgPd 0 0
member.

IEEE-SA
7.2.7.3 DataSets
Two DataSets are defined for PSUP.
DataSet
(Object Attributes)
1 PSUP.MX All measurements
2 PSUP.ST All status
7.2.8 Automatic Control Logic (AUTO)
The AUTO brick provides for the selection of automatic or manual device operation and the parameters for
automatic operation. See Figure 18 and Table 27.
Manual
CO
Device
Automatic
ODAutoMan
NumFltToLO
FltTmrRs
Automatic
OpenTimDel AutoManDS
Control
CommTimOut ReclDS
Logic
Automatic Control Logic (AUTO)
Figure 18: Automatic Control Logic
Table 27: AUTO Model

ST AutoManDS SIT o Manual or automatic operation (DevSt)
ReclDS SIT o Status of the reclose action
SP NumFltToLO AO o Number of faults before lockout
OpenTimDel AO o Time delay before open when in auto mode
CommTimOut AO o Communication time out period
CO ODAutoMan DCO o Sets Oper mode to automatic/manual
CF All AUTO.SP ACF o Configuration for all included AUTO.SP
All AUTO.CO ACF o Configuration for all included AUTO.CO
DC All AUTO.ST d o Description of all included AUTO.ST
All AUTO.SP d o Description of all included AUTO.SP
All AUTO.CO d o Description of all included AUTO.CO
RP brcbST BasRCB rw m Controls reporting of StatusPoints

IEEE-SA
Attribute brcbST
RptID NULL
RptEna FALSE
DatSet ST
OptFlds All options
BufTim 0
Trgs 0
SeqNum 0
TrgOps CndDatChg
RBEPd 0
IntgPd 0
member.
7.2.8.3 DataSets
The AUTO brick contains a number of DataSets available to clients.
DataSet DataSet Components

DatSet
No. (Object Attributes)
1 AUTO.ST All status points
2 AUTO.SP All setpoints
3 AUTO.SOELog All SOE points
4 AUTO.dbEvents All deadband events
5 AUTO.STEvents All status change events
7.2.9 Ratio (RATO)
The RATO provides a logical representation of primary and secondary winding ratios for measurements. See
Figure 19 and Table 28.

IEEE-SA
APhsV
BPhsV
CPhsV
APhsA
BPhsA
CPhsA
NeutA
ABPhsV
BCPhsV
CAPhsV
Ratio (RATO)
Figure 19: Ratio (RATO)
Table 28: RATO Model

CF APhsV RATIO rw o Primary/secondary winding ratio
BPhsV RATIO rw o Primary/secondary winding ratio
CPhsV RATIO rw o Primary/secondary winding ratio
APhsA RATIO rw o Primary/secondary winding ratio
BPhsA RATIO rw o Primary/secondary winding ratio
CPhsA RATIO rw o Primary/secondary winding ratio
NeutA RATIO rw o Primary/secondary winding ratio
ABPhsV RATIO rw o Primary/secondary winding ratio
BCPhsV RATIO rw o Primary/secondary winding ratio
CAPhsV RATIO rw o Primary/secondary winding ratio
7.3 Generic Input/Output
7.3.1 Generic Analog Input (GAIN)
GAIN provides a generic measurement of a single analog input or a group of analog inputs. See Figure 20
and Table 29.
In
Input
Generic Analog Input (GAIN)
Figure 20: Generic Analog Input (GAIN)

IEEE-SA
Table 29: GAIN Model

MX In<n> AI r o Generic analog input
CF GAIN.MX ACF rw o Configuration for GAIN.MX
DC GAIN.MX d rw o Description for GAIN.MX
Attribute brcbMX
RptID NULL
RptEna FALSE
DatSet MX
OptFlds All options
BufTim 0
Trgs 0
SeqNum 0
TrgOps CndDatChg
RBEPd 0
IntgPd 0
member.
7.3.1.3 DataSets
The GAIN brick contains one DataSet, GAIN.MX, for retrieval by a client.
7.3.2 Generic Setpoint (GSPT)
GSPT provides a generic setpoint output for either a single output, or a group of generic setpoints. See
Out
Generic Set Point (GSPT)
Figure 21: Generic Setpoint

IEEE-SA
Table 30: GSPT Model

SP Out<n> AI r o Generic analog input
CF GSPT.SP<n> ACF rw o Configuration for all GSPT.SP
DC GSPT.SP<n> d rw o Description for all GSPT.SP
Attribute brcbMX
RptID NULL
RptEna FALSE
DatSet MX
OptFlds All options
BufTim 0
Trgs 0
SeqNum 0
TrgOps CndDatChg
RBEPd 0
IntgPd 0
member.
7.3.2.3 DataSets
The GSPT brick contains one DataSet, GSPT.SP, for retrieval by a client.
7.3.3 Generic Accumulator (GACC)
The GACC brick provides a generic measurement of a single analog input. The optional configuration and
description may be used to uniquely identify what is being accumulated. See Figure 22 and Table31.
Cnt
000001
Generic Accumulator (GACC)
Figure 22: Generic Accumulator (GACC)

IEEE-SA
Table 31: GACC Model

MX Cnt<n> AccI r o Generic Accumulator Input
CF GACC.MX ACF rw o Configuration for GACC.MX
DC GACC.MX d rw o Description for GACC.MX
RP brcbMX BasRCB rw m Controls reporting of Measurements
Attribute brcbMX
RptID NULL
RptEna FALSE
DatSet MX
OptFlds All options
BufTim 0
Trgs 0
SeqNum 0
TrgOps CndDatChg
RBEPd 0
IntgPd 0
member.
7.3.3.3 DataSets
The GACC brick contains one DataSet, GACC.MX, for retrieval by a client.
7.3.4 Generic Indicator (GIND)
The GIND brick provides for generic indications of one or more points. The optional description may be
used to uniquely identify how the point is used. See Figure 23 and Table 32.
AuxIn
Figure 23: Generic Indicator (GIND)
Table 32: GIND Model
FC Name Class rwec m/o Description

ST AuxIn<n> SIG r o Generic indication [block of 16]
DC GIND.ST d rw o Description for GIND.MX

IEEE-SA
Attribute brcbST
RptID NULL
RptEna FALSE
DatSet ST
OptFlds All options
BufTim 0
Trgs 0
SeqNum 0
TrgOps CndDatChg
RBEPd 0
IntgPd 0
7.3.4.3 DataSets
The GIND brick contains a number of DataSets for retrieval by a client.
DataSet
DataSet
DatSet Components
No.
(Object Attributes)
1 GIND.ST All status points
2 GIND.SOELog All SOE points
7.3.5 Generic Control (GCTL)
GCTL provides binary or double control output for control of single or multiple control outputs. For OD, the
output takes on the context of the device class (i.e. SWIT, LTCH, etc.). See Figure 24 and Table 33.
Ctl
AuxOut
Figure 24: Generic Control (GCTL)
Table 33: GCTL Model

CO OD<n> DCO w o Generic operate device
AuxOut<n> BOOL[16] o Generic AuxOut [block of 16]
CF GCTL.CO ACF rw o Configuration for GCTL.CO
DC GCTL.CO d rw o Description for GCTL.CO

IEEE-SA
Attribute brcbST
RptID NULL
RptEna FALSE
DatSet ST
OptFlds All options
BufTim 0
Trgs 0
SeqNum 0
TrgOps CndDatChg
RBEPd 0
IntgPd 0
7.3.5.3 DataSets
The GCTL brick contains a number of DataSets for retrieval by a client.
DataSet
DataSet
DatSet Components
No.
(Object Attributes)
1 GCTL.SOELog All SOE points
7.4 Measurement Functions
7.4.1 Polyphase Measurement Unit (PMXU)
PMXU provides for the measurement of single phase or polyphase analog values (including neutral), per-
taining to a wye or delta connected field device or circuit. See Figure 25 and Table 34.
A
V
PhsPhsV
PF
Ang
Hz
W
A V Var
FltMagA
Figure 25: Polyphase Measurement Unit (PMXU)

Polyphase Measurement Unit (PMXU)

IEEE-SA
Table 34: PMXU Model

V WYE o Voltage on phase A, B, C to G
PhsPhsV DELTA o Voltage AB, BC, CA
A WYE o Current in phase A, B, C, and N
W WYE o Watts in phase A, B, C
TotW AI o Total Watts in all 3 phases
VAr WYE o VArs in phase A, B, C
TotVAr AI o Total VArs in all 3 phases
VA WYE o VA in phase A, B, C
TotVA AI o Total VA in all 3 phases
PF WYE o Power Factor for phase A, B, C
AvgPF AI o Average Power Factor of all 3 phases
Ang WYE o Angle between phase voltage and current
Hz AI o Power system frequency
FltMagA WYE o Fault magnitude in phase A, B, C, N
CF All PMXU.MX ACF m Configuration of all included PMXU.MX
DC All PMXU.MX d m Description of all included PMXU.MX
Attribute brcbMX
RptID NULL
RptEna FALSE
DatSet MX
OptFlds All options
BufTim 0
Trgs 0
SeqNum 0
TrgOps CndDatChg
RBEPd 0
IntgPd 0
member.
7.4.1.3 DataSets
As a type of server, the PMXU contains one DataSet, PMXU.MX, for retrieval by a client.

IEEE-SA
7.4.2 Polyphase Energy Measurement Unit (EMTR)
EMTR provides for acquiring of single phase or polyphase metering values pertaining to a field device or
circuit. See Figure 26 and Table 35.
V, PhsPhsV,
A
Rs
kWhr
kVAr
Polyphase
Figure Energy
26: Polyphase Measuremen
Energy Measurement (EMTR)
Table 35: EMTR Model

MX WHr WYE o
TotWHr AI o
VArHr WYE o
TotVArHr AI o
CF All EMTR.MX ACF m All EMTR.MX
DC All EMTR.MX d o Description of all included EMTR.MX
AS LogDev<n> TBD o Defines path for peer-to-peer IED communication
Attribute brcbMX
RptID NULL
RptEna FALSE
DatSet MX
OptFlds All options
BufTim 0
Trgs 0
SeqNum 0
TrgOps CndDatChg
RBEPd 0
IntgPd 0
member.

IEEE-SA
7.4.2.3 DataSets
The polyphase meter contains one DataSet, EMTR.MX, for retrieval by a client.
7.4.3 Synchronism Check Unit (SYNC)
The SYNC compares various voltages to ascertain whether or not they are synchronized with each other.
When a synchronous condition exists between the compared voltages, closing of the synchronism super-
vised breaker is permitted. See Figure 27 and Table 36.
Hz
BusbarV
BayV
RunV
IncomingV
AngDiff
SyncVDiff
SyncHzDiff
SyncChkDur
Synchronism Check Unit (SYNC)

Figure 27: Synchronism Check Unit (SYNC)
Table 36: SYNC Model

MX Hz AI o Frequency
BusV AI o
BayV AI o
RunV AI o The reference V for synchronism check logic
InV AI o V compared with RunV by the sync check logic
AngDiff AI o Diff in Phs Ang between the RunV and the IncomingV
SynVDiff AI o Diff in V magnitude between RunV and IncomingV
SynHzDiff AI o Diff Freq between RunV and IncomingV
SynChkDur INT16U o Time interval that the Sync process is in progress
ST SyncSt SIG o Status of the synchronization logic
CF All SYNC.MX ACF m All included SYNC.MX
DC All SYNC.MX d o Description of all included SYNC.MX
All SYNC.ST d o Description of all included SYNC.ST
brcbST BasRCB rw m Controls reporting of status points
AS LogDev<n> TBD o Defines path for peer-to-peer IED Communication

IEEE-SA

RptID NULL NULL
RptEna FALSE FALSE
DatSet MX ST
BufTim 0 0
Trgs 0 0
SeqNum 0 0
RBEPd 0 0
IntgPd 0 0
member.
7.4.3.3 DataSets
The SYNC contains two DataSets.
DataSet
DataSet
DatSet Components
No.
(Object Attributes)
1 SYNC.MX All measurements
2 SYNC.ST All status points
7.4.4 Temperature Measurement Unit (TEMP)
The TEMP provides measurement of either a single temperature or a polyphase temperature measurement
for three phase devices (i.e., transformers). See Figure 28 and Table 37.
T
T
PolyT
PolyT
Temperature Measurement Unit

Figure 28: Temperature Measurement Unit (TEMP)

IEEE-SA
Table 37: TEMP Model

MX T AI r o -50 to 200C Temperature
PolyT WYE r o -50 to 200C T of polyphase equip, Phs A, B &C
CF All TEMP.MX ACF rw o Configuration for all TEMP.MX
DC All TEMP.MX d rw o Description for all TEMP.MX
Attribute brcbMX
RptID NULL
RptEna FALSE
DatSet MX
OptFlds All options
BufTim 0
Trgs 0
SeqNum 0
TrgOps CndDatChg
RBEPd 0
IntgPd 0
member.
7.4.4.3 DataSets
The TEMP brick contains one DataSet, TEMP.MX, for retrieval by a client.
7.5 Transformer Functions

The basic bricks presented in this section are used to develop power transformers, step-voltage regulators,
and other devices using oil, gas, or vacuum as an insulating medium. See Figure 29.

IEEE-SA
Transformer
Figure 29: Transformer
7.5.1 Transformer Tank (TANK)
The main tank of a power transformer consists principally of the core and coil assembly, the insulating fluid
and other such passive constituents. See Figure 30 and Table 38.
T
Vib
AcuPres
AcuPaDsch
ElecPaDsch
CoreGndA
GIA
Figure 30: Transformer Tank (TANK)

Transformer Tank (TANK)
Table 38: TANK Model

MX T AI r o -50 to 200C Tank surface temperature, qty=n
Vib AI r o 0 to 50 m/s2 Tank surface vibration, qty=n
AcuPres AI r o 40 to 100 dBA Tank surface sound pressure level, qty=n
Counts above
AcuPaDsch AccI r o Partial discharge - acoustic, qty=n
threshold
EPaDsch AI r o 0 to 10,000pC Partial discharge - electrical, qty=n
CoreGndA AI r o 0.0 to 10,000mA Current in a core ground path
GIA AI r o 0 to 1000A Direct current in neutral of HV winding
CF All TANK.MX ACF rw o Configuration for all TANK.MX
DC All TANK.MX d rw o Description for all TANK.MX

IEEE-SA
Attribute brcbMX
RptID NULL
RptEna FALSE
DatSet MX
OptFlds All options
BufTim 0
Trgs 0
SeqNum 0
TrgOps CndDatChg
RBEPd 0
IntgPd 0
member.
7.5.1.3 DataSets
The TANK brick contains one DataSet, TANK.MX, for retrieval by a client.
7.5.2 Bushings (BUSH)
Transformers will usually include one bushing for each phase of each winding. Bushings are totally passive
components; there are no components for which control or set points are provided or for which a user speci-
fied configuration is expected. The model will most often describe a three-phase transformer and less
frequently describe a single-phase transformer. See Figure 31 and Table 39.
C1PF
C1DF
C1Cap
C2PF
C2DF
C2Cap
LeakCur
PaDsch
AcuEm
Bushings (BUSH)
Figure 31: Bushings (BUSH)

IEEE-SA
Table 39: BUSH Model

MX C1PF WYE r o 0.15 to 0.15 C1 insulation power factor
C1DF WYE r o 0.15 to 0.15 C1 insulation dissipation factor
C1Cap WYE r o 0 to 1000pF C1 capacitance
C2PF WYE r o 0.00 to 0.5 C2 insulation power factor
C2DF WYE r o 0.00 to 0.5 C2 insulation dissipation factor
C2Cap WYE r o 0 to 100,000pF C2 capacitance
LeakCur WYE r o 0 to 100mA Leakage current
PaDsch WYE r o 0 to 10,000pC Partial discharge
AcouEm WYE r o 0 to 100,000 Acoustic emission, counts/sec
CF All BUSH.MX ACF rw o Configuration for all BUSH.MX
DC All BUSH.MX d rw o Description for all BUSH.MX
Attribute brcbMX
RptID NULL
RptEna FALSE
DatSet MX
OptFlds All options
BufTim 0
Trgs 0
SeqNum 0
TrgOps CndDatChg
RBEPd 0
IntgPd 0
member.
7.5.2.3 DataSet
The BUSH brick contains one DataSet, BUSH.MX, for retrieval by a client.
7.5.3 Heat Exchanger (HTEX)
The power transformer usually consists of a heat exchanger (radiator) through which passes the insulating
fluid (oil) that has been heated by its interaction with the core/coil assembly. The oil may either pass to the
heat exchanger by natural convection, or it may be pumped for additional efficiency of cooling. In turn, the
heat exchangers may be equipped with fans to accelerate the air flow through the radiators, again to increase
the efficiency of the cooling. Often, multiple stages of fans and/or pumps will be provided. See Figure 32
and Table 40.

IEEE-SA
TopT
BotT
InT
OutT
InPres
OutPres
Heat Exchanger (HTEX)
Figure 32: Heat Exchanger (HTEX)
Table 40: HTEX Model

MX TopT AI r o -50 to 200C Heat exchanger top oil temperature
BotT AI r o -50 to 200C Heat exchanger bottom oil temperature
InT AI r o 0 to 100C Water inlet temperature
OutT AI r o 0 to 100C Water outlet temperature
InPres AI r o 0 to 20psig Water inlet pressure
OutPres AI r o 0 to 20psig Water outlet pressure
CF All HTEX.MX ACF rw o Configuration for all HTEX.MX
DC All HTEX.MX d rw o Description for all HTEX.MX
Attribute brcbMX
RptID NULL
RptEna FALSE
DatSet MX
OptFlds All options
BufTim 0
Trgs 0
SeqNum 0
TrgOps CndDatChg
RBEPd 0
IntgPd 0
member.

IEEE-SA
7.5.3.3 DataSet
The HTEX brick contains one data set, HTEX.MX, for retrieval by a client.
7.5.4 Pump (PUMP)
The use of pumps is usually predicated on the need for such to maintain an acceptable temperature or pres-
sure. See Figure 33 and Table 41.
T
ODAutoMan A
ODFan Pres
OnT DS
OffT Flow
PUMP
Figure 33: Pump
Table 41: PUMP Model

MX TopT AI r o 50 to 200C Heat exchanger top oil temperature
BotT AI r o 50 to 200C Heat exchanger bottom oil temperature
InPres AI r o 0 to 20psig Water inlet pressure
OutPres AI r o 0 to 20psig Water outlet pressure
A AI r o 0 to 50A Motor current for pump
ST PmpSt SIG r m Pumps OFF/ON status
PmpFlwSt SIG r o Pump flow status
SP OnT AO rw m 0 to 100C Temp at which pump turns on
OffT AO rw o 0 to 100C Temp at which pump turns off
CO ODAutoMan BO rw m Selects mode, auto/man
ODOnOff BO rw m Turns pump on/off
CF All PUMP.MX ACF rw o Configuration for all PUMP.MX
All PUMP.SP ACF rw o Configuration for all PUMP.SP
All PUMP.CO CCF rw o Configuration for all PUMP.CO
DC All PUMP.MX d rw o Description of all PUMP.MX
All PUMP.ST d rw o Description of all PUMP.ST
All PUMP.SP d rw o Description of all PUMP.SP
All PUMP.CO d rw o Description of all PUMP.CO

IEEE-SA

RptID NULL NULL
RptEna FALSE FALSE
DatSet MX ST
BufTim 0 0
Trgs 0 0
SeqNum 0 0
RBEPd 0 0
IntgPd 0 0
member.
7.5.4.3 DataSets
The PUMP brick contains two DataSets for retrieval by a client.
DataSet
DataSet
DatSet Components
No.
(Object Attributes)
1 PUMP.MX All measurements
2 PUMP.ST All status points
7.5.5 Fans (CFAN)
The use of the fans is usually predicated on the need for such so as to maintain an acceptable temperature of
a field device. The forcing of air may not be required at time of low load or low ambient temperature, but
will be expected to run as the temperature increases, due to the loading and the ambient conditions. See
T
A
OnT
OffT
ODAutoMan
ODFan DS
CFAN
Figure 34: CFAN

IEEE-SA
Table 42: CFAN Model

MX TopT AI r o 50 to 200C Heat exchanger top oil temperature
BotT AI r o 50 to 200C Heat exchanger bottom oil temperature
A AI r o 0 to 50A Motor current for fan
ST DevSt SIG r o Fan on/off status
SP OnT AO rw o 0 to 100C Temp at which fan turns on
OffT AO rw o 0 to 100C Temp at which fan turns off
CO ODAutoMan BO rw m Selects automatic/manual control
ODOnOff BO rw m Turns fan on/off
CF All CFAN.MX ACF rw o Configuration for all CFAN.MX
All CFAN.SP ACF rw o Configuration for all CFAN.SP
All CFAN.CO CCF rw o Configuration for all CFAN.CO
DC All CFAN.MX d rw o Description of all CFAN.MX
All CFAN.ST d rw o Description of all CFAN.ST
All CFAN.SP d rw o Description of all CFAN.SP
All CFAN.CO d rw o Description of all CFAN.CO

RptID NULL NULL
RptEna FALSE FALSE
DatSet MX ST
BufTim 0 0
Trgs 0 0
SeqNum 0 0
RBEPd 0 0
IntgPd 0 0
member.

IEEE-SA
7.5.5.3 DataSets
The CFAN brick contains two DataSets for retrieval by a client.
DataSet
DataSet
DatSet Components
No.
(Object Attributes)
1 CFAN.MX All measurements
2 CFAN.ST All status points
7.5.6 Load Tap Changer (LTCH)
T
A
OnT
OffT
ODAutoMan
ODFan DS
Load Tap Changer (LTCH)
Figure 35: Load Tap Changer (LTCH)
Table 43: LTCH Model

MX DrvMotA AI r o 0 to 20A Motor current for LTC drive motor
CircMotA AI r o 0 to 20A LTC oil circulation motor current
RvsSwT WYE r o 50 to 200C T of reversing switch, pole Ph A, B &C
RestT WYE r o 50 to 500C T of resistor, pole Ph A, B &C
TCTim AI r o 0 to 10,000ms Time of previous tap change operation
CO ODAutoMan BO rw m Selects automatic/manual control
CF All LTCH.MX ACF rw o Configuration for all LTCH.MX
All LTCH.SP ACF rw o Configuration for all LTCH.SP
All LTCH.CO CCF rw o Configuration for all LTCH.CO
DC All LTCH.MX d rw o Description of all LTCH.MX
All LTCH.ST d rw o Description of all LTCH.ST
All LTCH.SP d rw o Description of all LTCH.SP
All LTCH.CO d rw o Description of all LTCH.CO

IEEE-SA

RptID NULL NULL
RptEna FALSE FALSE
DatSet MX ST
BufTim 0 0
Trgs 0 0
SeqNum 0 0
RBEPd 0 0
IntgPd 0 0
brcbMX: Report all changes in value that exceed deadbands specified in CF for each DataSet member.
7.5.6.3 DataSets
The LTCH brick contains two DataSets for retrieval by a client.
DataSet
DataSet
DatSet Components
No.
(Object Attributes)
1 LTCH.MX All measurements
2 LTCH.ST All status points
7.6 Switch Functions

7.6.1 Switch (SWIT)
The switch represents a type of field device (physical equipment) that can make or break a circuit in the elec-
tric system. The description, vendor, owner, and nameplate information is defined by the DeviceIdentity
(DI). SWIT is the abbreviated name used for the switch field device. See Figure 36 and Table 44.
Table 44: SWIT Model
FC Object Name Class rwec m/o Range

ST SwDS SIT r o Indicates the position of the switch (DevSt)
DC SwRtg EqRtg m Description of the equipment
ConCkt ConCkt m Description of the circuit
SwDS d o Description of SwDS
AX TagTyp Tag r o The allowable tags on the switch
Tags Tag rw o The active tags on the switch
OpenIntlk SI rw o Opening of Sw prevented by interlock logic
CloseIntlk SI rw o Closing of Sw prevented by interlock logic
RP brcbST BasRCB rw m Controls reporting of status points

IEEE-SA
SwDS
Figure 36: Switch (SWIT)

Switch (SWIT)
Attribute brcbST
RptID NULL
RptEna FALSE
DatSet ST
OptFlds All options
BufTim 0
Trgs 0
SeqNum 0
TrgOps CndDatChg
RBEPd 0
IntgPd 0
7.6.1.3 DataSets
The SWIT brick contains one DataSet, SWIT.ST, for retrieval by a client.
DataSet
(Object Attributes)
1 SWIT.ST All status points
7.6.2 Switch Drive Mechanism (SDRV)
The SDRV brick is the logical representation of a switch drive mechanism. See Figure 37 and Table 45.

IEEE-SA
LocRemDS
CtlFailInd
ODSw CtlTagBlk
CtlIntlkBlk
M
Switch Drive Mechanism (SDRV)
Figure 37: Switch Drive Mechanism (SDRV)
Table 45: SDRV Model
FC Object Name Class rwec m/o Range

MX OperCnt AccI o Number of Sw operations
SwOperTim AI o The Tim in msec to complete Oper from ODSw Cmd
CtlCmdCnt AccI o The # of times the Sw has been Cmd to Oper
ST LocRemDS SIT o The mode of control, local or remote (DevSt)
FailInd SI o FailTmr expired w/o the control action occurring
TagBlk SI o Switch operation blocked due to a tag
IntlkBlk SI o Switch operation blocked by Intlk logic
TrpCoil SI r o Trip coil supervision
CO ODSw DCO m The command to open/close the switch
CF ClockTOD BTIME6 m Date and time for data logging.
FailTmr ACF o Control fail timer
All SDRV.MX ACF o Configuration for SDRV.MX
All SDRV.CO CCF o Configuration for SDRV.CO
Img AcsBLOB rw o Proprietary information
DC All SDRV.MX d m Description of all included SDRV.MX
All SDRV.ST d m Description of all included SDRV.ST
All SDRV.CO d m Description of all included SDRV.CO
AS LogDev<n> TBD o Defines path for peer-to-peer IED communication

IEEE-SA

RptID NULL NULL
RptEna FALSE FALSE
DatSet MX ST
BufTim 0 0
Trgs 0 0
SeqNum 0 0
RBEPd 0 0
IntgPd 0 0
member.
Brcbst: Report all change of state for each DataSet member.
7.6.2.3 DataSets
The SDRV brick contains a number of DataSets for retrieval by a client.
DataSet
DataSet
DatSet Components
No.
(Object Attributes)
1 SDRV.MX All measurements
2 SDRV.ST All status points
3 SDRV.SOELog All SOE points
7.6.3 Motorized Switch (MOSW)
The MOSW provides a logical representation of a switch that can be remotely operated to make or break
currents in the electric system. See Figure 38 and Table 46.
Table 46: MOSW Model

ST SwDS SIT o Switch device state
CF All MOSW.CO CCF rw m Configuration for all included MOSW.CO
DC Src ConCkt o
Lod ConCkt o
All MOSW.ST d o Description of ALL included MOSW.ST
All MOSW.CO d o Description of ALL included MOSW.CO
RP brcbST BasRCB rw m Controls reporting of Status Points
AX LogDev<n> TBD

IEEE-SA
ODSw
M SwDS
Motorized Switch (MOSW)
Figure 38: Motorized Switch (MOSW)
Attribute brcbST
RptID NULL
RptEna FALSE
DatSet ST
OptFlds All options
BufTim 0
Trgs 0
SeqNum 0
TrgOps CndDatChg
RBEPd 0
IntgPd 0
7.6.3.3 DataSets
The MOSW brick contains a number of DataSets available to clients.
DataSet
DataSet
DatSet Components
No.
(Object Attributes)
1 MOSW.ST All status points
2 MOSW.SOELog All SOE points
3 MOSW.dbEvents All deadband events
4 MOSW.STEvents All status change events

IEEE-SA
7.6.4 Circuit Breaker (CBKR)
The CBKR provides a logical representation of a circuit breaker that can make or break high currents in the
electric system. See Figure 39 and Table 47.
LocRemDS
CtlFailInd
ODSw CtlTagBlk
M CtlIntlkBlk
Circuit Breaker (CBKR)
Figure 39: Circuit Breaker (CBKR)
Table 47: CBKR Model

SP LoPresAlm ACF o Thre below which an alarm is generated
LoPresLO ACF o Thre below which the Bkr is locked-out
HiPresAlm ACF o Thre above which an alarm is generated
LoDenAlm ACF o Thre below which an alarm is generated
LoDenLO ACF o Thre below which the Bkr is locked-out
HiDenAlm ACF o Thre above which an alarm is generated
LoLevAlm ACF o Thre below which an alarm is generated
LoLevLO ACF o Thre below which the Bkr is locked-out
HiLevAlm ACF o Thre above which an alarm is generated
PoleDiscTim ACF o The Tim between the Oper of the first and last Bkr pole
ST SwDS SIT o Switch device state
SwPoleDS BSTR8 o Switch pole device state
Indicates if the individual poles of the breaker have operated
UneqPoleDS SI o
correctly
PwrSupSt SIG o Health of the Pwr supply, charger and battery
PresSt SIT o The condition of the insulating medium pressure
Den SIT o The condition of the density of the insulating gas
LevSt SIT o The condition of the level of the insulating medium
PmpMotSt SIT o The condition of the pump motor
PoleDiscSt SI o All CB poles did not operate within time interval
BlkSwSt SI o Status of the breaker blocking switch
TrpCoil SI r o Trip coil supervision
CF All CBKR.CO CCF rw m Configuration for all included CBKR.CO
All CBKR.SP ACF m Configuration for all included CBKR.SP

IEEE-SA
Table 47: CBKR Model (continued)

DC BkrRtg EqRtg m
ConCkt ConCkt m
All CBKR.ST d o Description of all included CBKR.ST
All CBKR.SP d o Description of all included CBKR.SP
All CBKR.CO d o Description of all included CBKR.CO
AX LogDev<n> TBD
Attribute brcbST
RptID NULL
RptEna FALSE
DatSet ST
OptFlds All options
BufTim 0
Trgs 0
SeqNum 0
TrgOps CndDatChg
RBEPd 0
IntgPd 0
7.6.4.3 DataSets
The CBKR brick contains a number of DataSets available to clients.
DataSet
DataSet
DatSet Components
No.
(Object Attributes)
1 CBKR.ST All status points
2 CBKR.SP All setpoints
3 CBKR.SOELog All SOE points
4 CBKR.dbEvents All deadband events
5 CBKR.STEvents All status change events

IEEE-SA
7.7 Reactive Functions

7.7.1 Capacitor Bank (CAPB)
The CAPB represents a type of field device (physical equipment) that is a source of leading reactive power
in the electric system. The CAPB can be applied at different voltage levels in the electrical system for power
factor correction and voltage support compensation. The description, vendor, owner, and nameplate informa-
tion is defined by the DeviceIdentity (DI) Object. CAPB is the abbreviated name used for the capacitor bank
field device. See Figure 40 and Table 48.
Figure
Capacitor 40: Capacitor
Bank (CAPB) Bank (CAPB)
Table 48: CAPB Model

DC CapRtg EqRtg rw m Rating of the capacitor bank
ConCkt ConCkt rw m Circuit ID of capacitor bank application
BnkCon ENUM8 rw o Capacitor bank connection (wye or delta)
7.7.2 Capacitor Control Logic (CAPL)
The CAPL represents the automatic control logic used to control the operation of the capacitor bank See Fig-
ure 41 and Table 49.
VPu OVDS
VArPu NeutAlm
NeutAPu DSTDS
HiBadV Capacitor SensorST
LoBadV Control DschBlkDS
TimSched Logic DoorDS
StartTS CBDS
StopTS
StartDST
StopDST
Capacitor Control Logic (CAPL)
Figure 41: Capacitor Control Logic (CAPL)

IEEE-SA
Table 49: CAPL Model

ST OVDS SI r o Indicates voltage override control status
NeutAlm BOOL r o Indicates neutral alarm is present
DSTDS SIT r o Indicates if DST is active
SensorSt SIG r o Indicates health of sensors
DschBlkDS SI r o Cap bank Sw close Blk due DschTimDel
DoorDS SIT r o Cabinet door open or closed
CBDS SIT r o Capacitor bank device state
SP VPu CBPUG rw o Voltage control setpoints
APu CBPUG rw o Current control setpoints
VArPu CBPUG rw o VAr control setpoints
NeutAPu CBPUG rw o Neutral current setpoints
HiBadV AO rw o V above which sensor has failed
LoBadV AO rw o V below which sensor has failed
TimSched CBTim rw o Schedule for time control
StartTS BTIME6 rw o Start time for time schedule
StopTS BTIME6 rw o Stop time for time schedule
StartDST BTIME6 rw o Start time for day light savings time
StopDST BTIME6 rw o Stop time for day light savings time
CF OperLogic SIG rw m Defines operating logic for automatic control
DschTimDel INT16U rw o Min CB Sw open time in seconds
MaxOper INT8U rw o Maximum number of daily operations
All CAPL.SP ACF rw o Configuration for all CAPL.SP
DC All CAPL.ST d rw m Description of all included CAPL.ST
All CAPL.SP d rw m Description of all included CAPL.SP
AS Related IEDs TBD rw m Associations with all related IEDs
Attribute brcbST
RptID NULL
RptEna FALSE
DatSet ST
OptFlds All options
BufTim 0
Trgs 0
SeqNum 0
TrgOps CndDataChange
RBEPd 0
IntgPd 0
7.7.2.2 Specification of Evaluation Functions

IEEE-SA
7.7.2.3 DataSets
The CAPL brick has a number of DataSets available for access by a client.
DataSet
DataSet
DatSet Components
No.
(Object Attributes)
1 CAPL.ST All status points
2 CAPL.dbEvents All deadband events
3 CAPL.STEvents All status change events
7.8 Protection Functions

There are many data elements required for protection device functions, however only the functional compo-
nents visible to the communications port are modeled.
Models for protective functions are provided in Table 50.
Table 50: Models for Protective Functions
Model IEEE Std 37.2 Device

Device Function
NAME Function #
BROB Basic relay object (building block)
BTCO Basic time curve object (building block)
DIST Distance 21
VPHZ Volts per Hz relay 24
SYNC Synchronizing or synchronism-check 25
UVRL Undervoltage relay 27
DPRL Directional power relay 32
UCPR Under current or under power 37
PBRL Reverse phase or phase balance current relay 46
TTRL Machine or transformer thermal relay 49
IOCR Instantaneous overcurrent 50
TOCR Time overcurrent 51
PFRL Power factor relay 55
OVRL Overvoltage 59
VCBR Voltage or current balance relay 60
HIZR Ground detector 64 HiZ
DOCR Directional overcurrent 67
PAMR Phase angle measuring relay 78
RECR Reclosing relay 79
FREQ Frequency 81
CPWR Carrier or pilot-wire relay 85
DIFF Differential 87
Any or all of the above protection function models may be combined as a single composite device, with the
models addressed individually. When the models are combined, only one reset (Rs) component is used for
the logical device.
Protective devices represent the protection associated with substation and feeder field equipment (field
devices), i.e., transformers, lines, feeders, buses, etc. Todays relays (protective devices), even the micropro-

IEEE-SA
cessor type, require direct physical connections to sensors (CTs and VTs) for acquiring the power system
measurements and physical connections between the relays digital inputs, output contacts, and switchgear
control logic (either directly hardwired or via PLCs, etc.) for initiating appropriate control actions.
The operation of a protective device results in the control of some type of field device, usually the opening of
a switch or breaker to interrupt the fault. Protection of the actual fault interrupting equipment is usually
included in the responsibilities of transformer, bus, and line protection schemes.
The description, vendor, owner, and nameplate information of the protective device is defined by the Device-
Identity (DI)
Note that the intent is to define the common interface and data format for protection, control, and data acqui-
sition IED communications to ensure interoperability. Therefore, how the vendor implements the methods
and stores the data elements in the protective devices is of no concern to the implementor or user and can be
proprietary to the vendor. The implementor or user will only be required to know the use of the methods and
data elements in the application of the protective device.
For protective device modeling, the physical location of the objects are disregarded, e.g., the breaker control-
ler object may coexist with the Protective Device object in the physical protective relay (as we know it
today). This approach avoids limiting the implementation of the functions to certain devices and physical
locations, and also avoids confusion in describing the inputs and outputs, and defining the communication
paths.
Protection schemes for field devices will therefore involve a combination of objects (some or all in the same
physical location), e.g., protection of transformers may include overcurrent protection, differential protec-
tion, overpressure protection, over-heating protection, etc.
The abbreviated name for the protective device is the DeviceModelName as included in Table 50.
The types of protective devices are categorized by their function. The different basic forms of protection
schemes are applied in combination to provide protection of the various types of field devices, e.g., capacitor
bank protection, transformer protection, bus protection, generator protection, etc.
7.8.1 Basic Relay Object (BROB)
The BROB provides a basic building block containing functionality common to many relays. This block is
then used either by itself or in combination with other basic building blocks and other object components
presented in Section 3 and Section 4 for building more complex relay objects. See Figure 42 and Table 51.
CONTROL OUT
BROB
(ENA, DIS)
(1, 0)
SETPOINT
(Pu) AUXOUT
AUXIN
(Bool [16]) TARGET
MONITORED INPUTS
Figure 42: Basic Relay Object

IEEE-SA
Table 51: BROB Model

Out BOOL r o Present output status of the element
Tar PhsTar r o Targets since last reset
FctDS SIT r o Function is enabled/disabled
PuGrp INT8U r o Settings PuGroup selected for use
SG Relay Settings
When the measurements exceed (or drop below, in the case
Pu PUG rw o of a dropout function) this value, the protection control oper-
ation is initiated.
PuDelTim INT32U rw o Pickup time delay
DODelTim INT32U rw o Drop out time delay
CO EnaDisFct DCO w o Enable/disable relay function
RsTar BO w o Reset all targets
RsLat BO w o Reset all latched outputs
EnaLatRs BO w o Enable/disable resetting latch inputs
AuxOut<n> BOOL[16] w o Block of 16 individually addressable auxiliary out puts
CF All BROB.SP ACF rw o Configuration for all included BROB.SP
All BROB.CO CCF rw o Configuration for all included BROB.CO
DC All BROB.ST d rw o Description of all included BROB.ST
All BROB.SP d rw o Description of all included BROB.SP
All BROB.CO d rw o Description of all included BROB.CO
AS All related IEDs TBD rw m Associations with all related functions and IEDs.
7.8.2 Basic Time Curve Object (BTCO)
The BTCO provides a basic building block containing time curve functionality common to many relays.
This block is used in combination with other basic building blocks and other objects for building more com-
plex relay objects. See Figure 43 and Table 52.
BTCO
SETPOINT
(CRVMULT ,
CRVTYP,
TIMDIAL )
BASIC TIME CURVE OBJECT
Figure 43: Basic Time Curve Object

IEEE-SA
Table 52: BTCO Model

SG Relay Settings
A scaling factor applied to the time axis of the setting char-
CrvMult PUG o
acteristic of the
This is a setting of the type of curve to be used in the over-
CrvTyp TimCrv o
current protection.
TimDial AO o Time dial setting (1-10)
RsTimDel AO o Reset time delay
RsChar ENUM8 o Reset type
CF All BTCO.SP ACF rw o Configuration for all included BTCO.SP
DC All BTCO.SP d rw o Description for all included BTCO.SP
7.8.2.1 RsChar
RsChar defines the time delay characteristic used for reset.
Description Value rwec m/o

Reserved 0 rw o
Instantaneous reset 1 rw o
Definite time 2 rw o
Linear reset 3 rw o
7.8.3 Protective Functions Represented by the BROB
Table 53 includes a list of protective functions that are modeled by the BROB. The detailed model for the
BROB is found in 7.8.1. See Figure 44.
CONTROL OUT
BROB
(ENA, DIS)
(1, 0)
SETPOINT
(Pu) AUXOUT
AUXIN
(Bool [16]) TARGET
MONITORED INPUTS
Figure 44: Basic Relay Object

IEEE-SA
Table 53: Models Represented by BROB
Monitored IEEE Std

Model Description
Inputs C37.2 DF #
VPHZ The voltage per hertz relay inherits the BROB building block. For Volts, hertz 24
VPHZ, the Pu value is the ratio volts/Hz
DPRL The directional power relay inherits the BROB basic building Volts (ag, bg, cg, 32
block. There are no settings, and the output status is PwrFlwDir. ab, bc, ca)
Amps (a, b, c, n)
UCPR The under current or under power relay inherits the BROB basic Amps, VA 37
building block. For UCPR, the Pu value is the dropout current or
power setpoint.
PBRL The reverse phase or phase balance current relay inherits the Amps 46
BROB building block.
PSVR The phase sequence voltage relay inherits the BROB building Volts 47
block.
TTRL The machine or transformer thermal relay inherits the BROB Temperature 49
building block. For TTRL, the Pu value is temperature.
IOCR The instantaneous overcurrent relay inherits the BROB basic Amps (a, b, c, n) 50
building block. For IORC the Pu value is in amperes.
VCBR The voltage or current balance relay inherits the BROB basic Voltage, amps 60
building block.
PAMR The phase angle measuring relay inherits the BROB basic building Volts, amps 78
block. For PAMR, the Pu value is phase angle.
FREQ The frequency relay (FREQ) inherits the BROB basic building Volts 81
block. For FREQ, the Pu value is hertz.
CPWR The carrier or pilot-wire relay inherits the BROB basic building Auxouts 85
block. For the CPWR, the Pu is AuxOuts.
7.8.4 Protective Functions Represented by the BROB plus the BTCO.

Table 54 includes a list of protective functions that are modeled by the BROB plus the BTCO. See Figure 45.
The detailed model for the BROB is found in 7.8.1 and the detailed model for the BTCO in 7.8.2.
Table 54: Models Built from BROB with BTCO

Monitored IEEE Std
Model Description
Inputs C37.2 DF #
The voltage per hertz relay inherits the BROB building block.
VPHZ Volts, hertz 24
For VPHZ, the Pu value is the ratio Volts/Hz.
The under voltage relay inherits the BROB and BTCO basic
Volts (ag, bg, cg, ab,
UVRL building blocks. For UVRL, the Pu value is the dropout voltage DF27
bc, ca)
setpoint.
The reverse phase or phase balance current relay inherits the
PBRL Amps 46
BROB building block.
The time overcurrent relay inherits the BROB and BTCO basic
TOCR Amperes (a, b, c, n) DF51
building blocks. For TOCR, the Pu value is in amperes.
The over voltage relay inherits the BROB and BTCO basic
Volts (ag, bg, cg, ab,
OVRL building blocks. For OVRL, the Pu value is the pickup voltage DF59
bc, ca)
setpoint.

IEEE-SA
CONTROL OUT
BROB
(ENA, DIS)
(1, 0)
SETPOINT
(Pu) AUXOUT
AUXIN
(Bool [16]) TARGET
MONITORED INPUTS
Basic Relay Object
+
BTCO
SETPOINT
(CRVMULT,
CRVTYP,
TIMDIAL)
Basic Time Curve Object
Figure 45: BROB Plus the BTCO
7.8.5 Distance (DIST)

The DIST inherits the BROB basic building block and adds:
PoRch
RectRch
PctRch
RchDir
Ofs
Slp
PoQuad
RectQuad
PoBlind
RectBlind
DIST corresponds to IEEE DF21.
See Figure 46.
The distance relay model contains a single zone of protection, or distance object, for all fault types, and con-
tains ohm, mho, blinder, and quadrilateral characteristics that can be used singly or in combination with each
other. Settings can be specified either in rectangular or polar form. See Figure 47 and Table 55.

IEEE-SA
CONTROL OUT
DIST
(ENA, DIS)
(1, 0)
SETPOINT
(Pu) AUXOUT
AUXIN
(Bool [16]) TARGET
MONITORED INPUTS
AMPS (A, B, C, N)
Volts (AG, BG, CG, AB, BC, CA)
Figure 46: Distance (DIST)
y y
yAng(+)
UPPER
yAng(-) REACTIVE
BLINDER
LOWER
REACTIVE
BLINDER(s) REACTIVE
yOfs BLINDER
LEFT
xOfs RESISTIVE
xAng(+)
BLINDER
x x
RESISTIVE RIGHT
BLINDER RESISTIVE
BLINDERS QUAD BLINDER
Rch
DIA=Rch + RchOfs
Slp (+)
x
RchOfs
REACH
Figure 47: DIST Characteristics

IEEE-SA
Table 55: DIST Model

Out BOOL r o Inherited from BROB
Tar PhsTar r o Inherited from BROB
FctDS SIT r o Inherited from BROB
AuxIn<n> BSTR16 r o Inherited from BROB
DistTyp BSTR8 r o Identifies element type
SG Relay Settings Groups
Pu PUG rw o Inherited from BROB
PoRch VEC rw o Polar reach
RectRch XY rw o Rectangular reach
PctRch AO rw o Percent reach
RchDir BO rw o Reach direction
Ofs AO rw o Offset
Slp AO rw o Slope
PoQuad PQuad rw o Polar quadrangle settings
RectQuad RQuad rw o Rectangular quadrangle settings
PoBlind PoB rw o Polar blinder settings
RectBlind RectB rw o Rectangular blinder settings
CO EnaDisFct DCO w o Inherited from BROB
RsTar BO w o Inherited from BROB
RsLat BO w o Inherited from BROB
EnaLatRs BO w o Inherited from BROB
AuxOut<n> BOOL[16] w o Inherited from BROB
CF All DIST.SG ACF rw o Inherited from BROB
All DIST.CO CCF rw o Inherited from BROB
DC All DIST.ST d rw o Inherited from BROB
All DIST.SP d rw o Inherited from BROB
All DIST.CO d rw o Inherited from BROB
AS ALL RELATED IEDs TBD rw m Inherited from BROB
7.8.5.1 DistTyp
DistTyp is represented by a bit string [8] of individual distance faults types:
(0 = inactive/off, 1 = active/on):

IEEE-SA
Command Status Bit # rwec m/o

Ground distance 0 r o
Phase A distance 1 r o
Phase B distance 2 r o
Phase C distance 3 r o
Three phase distance (V) 4 r o
Reserved 5
Reserved 6
Reversed 7
7.8.5.2 ChrTyp
ChrTyp is represented by a bit string [8] of individual distance faults types: ohm, mho, quadrilateral, offset,
etc.

Ohm 0 r o
Mho 1 r o
Quadrilateral 2 r o
Offset 3 r o
Reserved 4 r o
Reserved 5
Reserved 6
Reserved 7
7.8.6 Synchronizing or Synchronism-Check (SYNC)
The SYNC inherits the BROB basic building block and adds:
SlipHz
AngDiff
VDiff
The synchronous check function requires two voltage inputs, one on each side of the tie breaker, to deter-
mine whether a permissive close of this breaker is allowed. The input references (VGen and VBus) are typi-
cally configurable to one of the phase voltages (either AG, BG, CG, AB, BC, or CA). SYNC corresponds to
IEEE DF25. See Figure 48 and Table 56.

IEEE-SA
CONTROL OUT
SYNC
(ENA, DIS)
(1, 0)
SETPOINT
(Pu) AUXOUT
AUXIN
(Bool [16]) TARGET
MONITORED INPUTS
Volts (AG, BG, CG, AB, BC, CA)
Figure 48: Synchronizing or Synchronism-Check (SYNC)
Table 56: SYNC Model

SG Relay Settings
When the slip frequency drops below the SlipHz
SlipHz PUG rw o
value, one condition is met for permissive close
When the Bus to Gen Ang Diff is within a +/
AngDiff PUG rw o window defined by the AngDiff value, one condi-
tion is met for permissive close
When the Bus to Gen voltage difference drops
VDiff PUG rw o below the VDiff value, one condition is met for
permissive close
BkrClsTim INT8U rw o Breaker close time
CF All SYNC.SP ACF rw o Inherited from BROB
All SYNC.CO CCF rw o Inherited from BROB
DC All SYNC.ST d rw o Inherited from BROB
All SYNC.SP d rw o Inherited from BROB
All SYNC.CO d rw o Inherited from BROB

IEEE-SA
7.8.7 High Impedance Ground Detector (HIZR)
The HIZR inherits the BROB basic building brick and adds:
DnCond
ArcSus
OCTar
LOL
HROC
For HiZ, the Pu value is over current
HIZR corresponds to IEEE DF64HIZ. See Figure 49 and Table 57.
Table 57: HIZR Model

MX Measurements
ArcConf WYE r o Accumulated measure of arcing on phase
DnCond BOOL r o Arcing detected preceded by over-current or
loss of load
ArcSus BOOL r o Intermittent arcing detected
OCTar PhsTar r o Overcurrent related to arcing detection
LOL PhsTar r o Loss of Load
HROC PhsTar r o High Rate of Change
PuGrp INT8U r o Settings PuGroup selected for use
SG Relay Settings
PuDelTim INT32U rw o Pickup Time Delay
DODelTim INT32U rw o Drop Out Time Delay
CF All HIZR.SP ACF rw o Inherited from BROB
All HIZR.CO CCF rw o Inherited from BROB
DC All HIZR.ST d rw o Inherited from BROB
All HIZR.SP d rw o Inherited from BROB
All HIZR.CO d rw o Inherited from BROB

IEEE-SA
CONTROL OUT
HIZR
(ENA, DIS)
(1, 0)
SETPOINT
(Pu) AUXOUT
AUXIN
(Bool [16]) TARGET
MONITORED INPUTS
Figure 49: High Impedance Ground Detector (HIZR)
7.8.8 Directional Overcurrent (DOCR)
The DOCR inherits the BROB basic building block and adds:
PuDir
MaxTorqAng
PoQuan
For DOCR, the Pu value is the pickup amperes. DOCR corresponds to IEEE DF67. See Figure 50 and
Table 58.
CONTROL OUT
DOCR
(ENA, DIS)
(1, 0)
SETPOINT
(Pu) AUXOUT
AUXIN
(Bool [16]) TARGET
MONITORED INPUTS
AMPS (A, B, C, N)
VOLT (AG, BG, CG, AB, BC, CA)
Figure 50: Directional Overcurrent (DOCR)

IEEE-SA
Table 58: DOCR Model

SG Relay Settings
Pu PUG rw o Pickup amperes. Inherited from BROB
PuDir SIT rw o The direction that the Pu is valid for
MaxTorqAng AO rw o Maximum torque angle
PoQuan AO rw o Polarizing quantity
CF All DOCR.SP ACF rw o Inherited from BROB
All DOCR.CO CCF rw o Inherited from BROB
DC All DOCR.ST d rw o Inherited from BROB
All DOCR.SP d rw o Inherited from BROB
All DOCR.CO d rw o Inherited from BROB
7.8.9 Reclosing Relay (RECR)
The RECR inherits the BROB basic building block and adds:
ReclSeq
BkrTrip
IniRecl
RECR corresponds to IEEE DF79. See Figure 51 and Table 59.

IEEE-SA
CONTROL OUT
RECR
(ENA, DIS)
(1, 0)
SETPOINT
(Pu) AUXOUT
AUXIN
(Bool [16])
MONITORED INPUTS
BREAKER TRIP
Figure 51: Reclosing Relay (RECR)
Table 59: RECR Model

BkrDS SIT rw m Breaker status
SG Relay Settings
ReclSeq SHOTS rw m Reclosing sequence
IniRecl DCO rw o Initiate reclosing
EnaLatRs DCO w o Inherited from BROB
CF All RECR.SP ACF rw o Inherited from BROB
All RECR.CO CCF rw o Inherited from BROB
DC All RECR.ST d rw o Inherited from BROB
All RECR.SP d rw o Inherited from BROB
All RECR.CO d rw o Inherited from BROB
7.8.10 Differential Relay (DIFF)
The DIFF inherits the BROB basic building block and adds Slp. For DIFF, the Pu value is in amperes.

IEEE-SA
DIFF corresponds to IEEE DF87. See Figure 52 and Table 60.
CONTROL OUT
DOCR
(ENA, DIS)
(1, 0)
SETPOINT
(SLP, Pu) AUXOUT
AUXIN
(Bool [16]) TARGET
MONITORED INPUTS
AMPERES (A, B, C)
Figure 52: Differential Relay (DIFF)
Table 60: DIFF Model

SG Relay Settings
Slp AO o Slope
CF All DIFF.SP ACF rw o Inherited from BROB
All DIFF.CO CCF rw o Inherited from BROB
DC All DIFF.ST d rw o Inherited from BROB
All DIFF.SP d rw o Inherited from BROB
All DIFF.CO d rw o Inherited from BROB

IEEE-SA
8. Measurement Unit
This section includes the following:
Instrumentation metering: Instrumentation metering (not for revenue purposes), is a function that
may exist as a stand-alone measurement unit, as modeled in this section, or included as a part of
another field device controller. There is a trend is to make monitored and derived electrical mea-
surements and parameters available to local and remote users.
There are many measurements and calculations required for field devices, however only the func-
tional components and measurements visible to the communications port are modeled.
The following measurement units are modeled:
Model Description
MU Measurement unit
Measurement unit represents the mechanism for digitizing and acquiring measurements associated with sub-
station and feeder field equipment (field devices), i.e., transformers, lines, feeders, buses, etc. Todays mea-
surement units require direct physical connections to sensors (CTs and VTs) for acquiring the power system
measurements. This means that the objects are on the control system base for voltage and current, e.g.,
120 volts and 5.0 amperes. The phasing is dependent upon the CT and VT polarities for a particular installa-
tion and is not treated in the context of GOMSFE.
The description, vendor, owner and nameplate information of the measurement unit is defined by the Devi-
ceIdentIty (DI).
For measurement unit modeling, the physical location of the objects are disregarded, e.g., the measurement
unit at the end of a line may be providing measurements used by a remote field device controller located sev-
eral miles away. This approach avoids limiting the implementation of the functions to certain devices and
physical locations, and also avoids confusion in describing the inputs and outputs, and defining the commu-
nication paths.
The abbreviated name for the measurement unit is MU.
8.1 Measurement Unit (MU)

AMPS
A, B , C, N MU LOGS
A-B, B-C, C-A
VOLTS
AG, BG, CG,
AB , BC , CA
MEASUREMENT UNIT
Figure 53: Measurement Unit (MU)

IEEE-SA
Table 61: MU Model

MX Current Information
A WYE o Current in phases and neutral
ResA AI o Residual current
DmdResA AI o Present demand residual current
MaxDmdResA AI o Max demand residual current
DmdA WYE o Present demand amps (interval is DmdInt)
MaxDmdA WYE o Max demand amps (interval is DmdInt)
HaA HI r o Individual harmonic currents
KfA WYE o K factor in phases only
Voltage Information
V WYE o Voltage phase to ground
PhsPhsV DELTA o Voltages phase to phase
ResV AI o Residual voltage
HaV HI r o Individual harmonic voltages
DmdPhsV WYE o Present demand volts (interval is DmdInt)
MinDmdPhsV WYE o Min demand volts (interval is DmdInt)
MaxDmdPhsV WYE o Max demand volts (interval is DmdInt)
DmdPhsPhsV DELTA o Present demand volts (interval is DmdInt)
MinDmdPPV DELTA o Min demand volts (interval is DmdInt)
MaxDmdPPV DELTA o Max demand volts (interval is DmdInt)
Sequence Components
SeqA Seq r o
SeqV Seq r o
Energy Information
W WYE o Watts per phase
TotW AI o Total watts in all 3 phases
TotWHr AI o Total watt hours
VAr WYE o VAr per phase
TotVArHr AI o Total VArh
VA WYE o VA per phase
TotVA AI o Total VA in all 3 phases
DmdTVA AI o Demand
DmdInt INT16U o Demand interval in sections
TotPosiWHr AI o Total watt hours positive (in normal direction)
TotNegWHr AI o Total watt hours negative (in reverse direction)
TotLgVArHr AI o Total VAr hours positive (lagging)
TotLdVArHr AI o Total VAr hours negative (leading)
DmdTotW AI o Present demand total watts (interval is DmdInt)
MinDmdTotW AI o Min demand total watts (interval is DmdInt)
MaxDmdTotW AI o Max demand total watts (interval is DmdInt)
DmdTotVAr AI o Present demand total VAr (interval is DmdInt)
MinDmdTotVAr AI o Min demand total VAr (interval is DmdInt)

IEEE-SA
Table 61: MU Model (continued)

MaxDmdTotVAr AI o Max demand total VAr (interval is DmdInt)
MinDmdTotVA AI o Min demand total VA (interval is DmdInt)
MaxDmdTotVA AI o Max demand total VA (interval is DmdInt)
Power Factor Information
PF WYE o Power factor for each phase
TotPF AI o Total power factor of all 3 phases.
DispPf WYE o Displacement PF (using fundamental only)
TotDispPF AI o Total displacement PF (using fundamental only)
Frequency Information
Hz AI o Frequency
Miscellaneous Information
TDDA WYE o Total demand distortion amps by phase
TDDOddA WYE o TDD amp odd components
TDDEvenA WYE o TDD amps even components
THDA WYE o Total harmonic distortion amps by phase
THDOddA WYE o THD amp odd components
THDEvenA WYE o THD amps even components
THDPhsV WYE o THD volts phase-to-ground
THDOddPhsV WYE o THD volts odd components
THDEvenPhsV WYE o THD volts even components
THDPPV DELTA o THD volts phase-to-phase
THDOddPPV DELTA o THD volts odd components
THDEvenPPV DELTA o THD volts even components
TDDPhsV WYE o TDD volts phase-to-ground
TDDOddPhsV WYE o TDD volts odd components
TDDEvenPhsV WYE o TDD volts even components
TDDPPV DELTA o TDD volts phase-to-phase
TDDOddPPV DELTA o TDD volts odd components
TDDEvenPPV DELTA o TDD volts even components
SP MaxDmdLodA AO rw o Current used in TDD amp calculation
ShCktRat AO rw o Short circuit ratio
CO RsAllMinMax BO w o Reset all min and max values
CF MX ACF rw o Configuration for all included MX
ClockTOD BTIME6 m Date and time for data logging.
DC EqRtg EqRtg m Equipment rating
ConCkt ConCkt m Connected circuit
Same As MX d m Description of all included MX
RP brcbMX BasRCB m Controls reporting of analog inputs
8.1.1 Power Factor (PF, TotPF)
When using power factor (PF), or total power factor (TotPF), the power factor is the true power factor (TPF)
as follows: TPF = real power/apparent power, where apparent power is defined as Vrms*Irms.

IEEE-SA
8.1.2 Displacement Power Factor (DispPF, TotDispPF)

DispPF is the cosine of the phase delay angle between the voltage and current waveforms at power system
frequency (harmonics removed). This is expressed as a signed variable, where a positive (+) sign indicates
lagging power factor, and negative (-) sign indicates leading power factor.
8.1.3 Report Default Settings
Attribute brcbMX
RptID NULL
RptEna FALSE
DatSet MX
OptFlds All options
BufTim 0
Trgs 0
SeqNum 0
TrgOps Cnd Data Change
RBEPd 0
IntgPd 0
8.1.4 Report Evaluation Functions
member.
8.2 DataSets
DataSet are components grouped to accommodate convenient access of related points. As a type of server,
the MU contains DataSets for retrieval by a client. Some attributes may appear in several DataSets, while
other attributes may not be assigned to any DataSet. The basic DataSets defined for the MU are as follows:
Data DataSet Components

DatSet
Set No. (Object Attributes)
1 MU.MX All measurements
9. Basic RTU Object Models

This section describes the object model used to communicate with a basic remote terminal unit (RTU) using
UCA 2.0. The intended reader of this section is a vendor or user who wishes to model the RTU in a UCA cli-
ent or server implementation. The description, vendor, owner, and nameplate information is defined by the
DeviceIdentity (DI). RTU is the abbreviated name used for the basic RTU.
9.1 Description and Application

For the purposes of this model, a RTU is a device that provides remote monitoring and control (also called
supervisory control and data acquisition, or SCADA) of nonintelligent input/output devices such as relays,
transducers, alarms, tap changers, etc. The purpose and use of the data from these devices is not known to
the RTU. It anonymously numbers each piece of data, or point, reports it to a master station, and leaves the

IEEE-SA
interpretation of the data to the master. Most older SCADA protocols were developed around this model.
In recent years, the role of an RTU has expanded to also serve as:
A protocol converter, gateway, or data concentrator between master stations and various intelligent
electronic devices (IEDs).
A platform for running automation algorithms and distributing the intelligence in the utility net-
work.
With a few exceptions, this model does not attempt to address these functions of an RTU, and therefore
describes a basic RTU. Throughout this document, the term basic RTU will be used to distinguish the subset
of RTU functions being modeled from the wider set of functions that may be in use in various vendors
RTUs.
It is expected that when serving as a data concentrator or substation computing platform, RTUs will eventu-
ally use the other UCA substation object models to present IED data to a master stations. However, when
concentrating anonymous data from older SCADA protocols, it is appropriate to use the basic RTU model.
9.2 Device Function

This section describes the functions of a basic RTU without discussing in depth the actual object model. It
defines those functions of an RTU that will be modeled in 9.3.
The functions of a Basic RTU are to:
Gather the values of status, analog, and/or accumulator inputs and report them to a master station
spontaneously or on specific request. Analog inputs may optionally be spontaneously reported
when they change by a specified amount, i.e., exceeding Deadband. This data is anonymously
numbered and not interpreted by the RTU.
Allow a master station to operate analog or binary outputs, with the option to provide SBO protection.
Log status inputs in a time-stamped sequence of events (SOE) buffer for spontaneous reporting or
later retrieval by the master.
Allow a master station to change the RTUs configuration remotely. The definition of configura-
tion is vendor-specific and shall not be discussed here.
Allow a master station to read or change the RTUs local time and date.
Allow a master station to freeze the values of all or a portion of RTUs accumulator inputs.
A freeze may be performed on command, at a specified time, or periodically by the RTU. When a freeze is
performed, the current value of the accumulator is copied into another storage location for later retrieval by
the master. The running value of the accumulator may optionally be reset to zero when the freeze occurs.
The actual quantity being measured, and the portion of the possible range actually being used for each point,
are typically not known to a basic RTU. This information is configured by the master and scaled on a per
point basis into a user-friendly value. For instance, the master must know that a full-scale value of +32767
actually represents 150 volts for a particular point, or that the same value may be represented by +1500
(tenths of volts) on another point. The former is preferable because it gives better resolution, but the latter
case is not ruled out.
The basic RTU model described here captures the method described above, in which all scaling is done by
the master. However, it also allows for future growth in which:
Scaling information may be stored within the RTU.

RTUs may choose to report floating-point values.

IEEE-SA
In this area, the model is therefore slightly more enhanced than a basic RTU.
Associated with each analog input is a deadband value that can determine when the value of the analog input
is spontaneously reported by the RTU. If the value of an analog input changes by more than the deadband
from the last value that was reported, the RTU spontaneously reports the current value.
9.2.1 Accumulator Inputs
An accumulator input is an unsigned value that always increases, unless it rolls over to zero. Typically it
counts the number of openings and/or closings of a switch, although it may be used to count a variety of
events. The meaning of the actual event being counted is not known to the RTU, although as a local matter it
may know some specifics, e.g., whether transitions or pulses are being counted.
9.2.2 Accumulator Control Blocks
Accumulator control blocks are not a traditional part of an RTU but are a construct used in the basic RTU
model to implement the freezing functions required. They are discussed in more detail in 5.1.1.
Note: Freezing of analog inputs in addition to accumulators is occasionally performed in some RTUs but it is
not a common enough practice to be considered part of a basic RTU.
A typical RTU has many operating parameters that can be set by the power utility but are not usually acces-
sible over the communications network. Many of these parameters may be proprietary to the vendors hard-
ware and software and cannot be standardized. Common methods of setting these parameters are to:
Enter them using front panel switches and displays.

Use a proprietary program on a personal computer to generate a file and download the file via a
local serial port.
Log into a local maintenance port using a simple terminal and enter them on a command-line inter-
face.
The basic RTU distinguishes the subset of functions of an RTU described in this model from the total set of
RTU functions used in the industry. The basic RTU model provides a method to pass this proprietary infor-
mation to the RTU over the communications network. This saves the power utility time and resources by
eliminating the need to physically send personnel to the local port. Nevertheless, the proprietary nature of
the data is preserved because the master and intervening devices need not interpret it. A basic RTU allows a
master to read or set the local time and date at the RTU. The objects necessary to perform these functions are
defined in the UCA Version 2.0 Common Application Services document.
9.3 Basic RTU Object Model

This section describes in more detail the components of a basic RTU. Note that for RTU measurements, the
quality component of all classes is mandatory. See Figure 54 and Table 62.

IEEE-SA
CONTROLS OUTPUTS
RTU
ANALOGS
BINARY:
SETPOINTS
MOMENTARY
PULSED OR
LATCHED
W/WO SBO
MONITORED
ANALOGS, ACCUMULATORS, STATUS
Figure 54: Basic RTU
Table 62: RTU Model

MX AIs<n> AI r o 16 bit analog inputs
AIl<n> AI r o 32 bit analog inputs
AccIs<n> AccI r o 16 bit accumulator inputs
AccIl<n> AccI r o 32 bit accumulator inputs
ST SI<n> SI r o Status inputs
SIT<n> SIT r o Double-bit status inputs
SIG<n> SIG r o Status groups
AOQ<n> q o* Quality of AO<n>
BTCQ<n> q o Binary trip/close output quality
TCQ<n> q o Trip/close output quality
RLQ<n> q o Raise/lower output quality
PRLQ<n> q o Pulsed raise/lower output quality
BOLQ<n> q o Latched binary output quality
SP AO<n> AO o 16 bit analog outputs
CO BTC<n> BO o Binary trip/close outputs
TC<n> DCO o Trip/close outputs
RL<n> DCO o Raise/lower outputs
PRL<n> PDCO o Pulsed raise/lower outputs
BOL<n> BO o Latched binary outputs
CF ClockTOD BTIME6 m Date and time for data logging
Same As RTU.MX ACF o Configuration for RTU MX
Same As RTU.SP ACF o Configuration for RTU SP
Same As RTU.CO CCF o Configuration for RTU CO
DC RTURtg EqRtg r(w) o
ConCkt ConCkt o
Same As RTU.MX d m Description of all included RTU MX

IEEE-SA
Table 62: RTU Model (continued)

Same As RTU.ST d m Description of all included RTU ST
Same As RTU.SP d m Description of all included RTU SP
Same As RTU.CO d m Description of all included RTU CO
RP brcbAI BasRCB rw m Controls reporting of analog
brcbIND BasRCB rw m Controls reporting of ST not tagged for logging
brcbSOE BasRCB rw m Controls reporting of status tagged for logging
brcbOUT BasRCB rw m Controls reporting of output quality
brcbAcc BasRCB rw m Controls reporting of accumulator points
EV ACC AccFCB rw m Controls freezing of accumulator points
LG SOE LCB rw m Controls logging of SOE status points
*Mandatory if SP.AO<n> included (above)

See Table 63.
Table 63
Attribute brcbAI brcbIND brcbSOE brcbOUT brcbAcc
RptID NULL NULL NULL NULL NULL
RptEna FALSE FALSE FALSE FALSE FALSE
DatSet AI IND SOE OUT ACC
OptFlds All options All options All options All options All options
BufTim 0 0 0 0 0
Trgs 0 0 0 0 0
SeqNum 0 0 0 0 0
TrgOps Bits 1 & 2 Bits 1 & 2 Bits 1 & 2 Bits 1 & 2 Bit 3
RBEPd 0 0 0 0 0
IntgPd 0 0 0 0 0
brcbAI: If the CndDataChange bit of TrgOps is set, report all changes in value that exceed dead-
band as specified in CF. If TrgOps is TRUE, also report on change of quality.
brcbIND: If the CndDataChange bit of TrgOps is set, report all of state. If the CndQualityChange
bit of TrgOps is TRUE, also report on change of quality.
brcbSOE: If the CndDataChange bit of TrgOps is set, report all changes of state. If the CndQuality-
Change bit of TrgOps is TRUE, also report on change of quality.
brcbOUT: If the quality change bit of TrgOps is set, report all change of quality.
brcbAcc: If the CndDataChange bit of TrgOps is set, report all values that have frozen since the last
report. If the CndQualityChange bit of TrgOps is TRUE, also report on change of quality.
Notes:
1There are no defined defaults values for the AccFCB.

2Default values for the SOE LCB are currently under development.

IEEE-SA
9.4 DataSets
DataSets are components grouped to accommodate convenient access of related points. As a type of server,
the basic RTU contains DataSets for retrieval by a client. Numerous DataSets may be defined for the RTU
object model. Some attributes may appear in several DataSets, while other attributes may not be assigned to
any DataSet. The main DataSets defined for the Basic RTU are shown in Table 64.
Table 64: Main DataSets for Basic RTU
DataSet DataSet Components

DatSet Intended Use
No. (Object Attributes)
1 RTU.AI All analog (AIs and AIl in MX) Reading and/or reporting
2 RTU.ST All status (SI, SIT, and SIG in SP) Reading
3 RTU.SP All SetPoints in SP Reading
4 RTU.SOE All status (SI, SIT, and SIG in SP) flagged for log Reading, reporting and/or logging
5 RTU.IND All status (SI, SIT, and SIG in SP) not flagged for log Reading, and/or reporting
6 RTU.OUT All AOQ and AOSQ in SP Reading and/or reporting
7 RTU.ACC All accumulators (AccIs and AccIl in MX) Reading and/or reporting
Note: If the RTU contains a large number of points in any of the data classes (i.e., AT, ST, SOE, etc.) such
that the underlying protocol cannot support the Get DataSet members or report services for the entire set of
points, then the class of points shall be modeled using additional DataSets such that no single DataSet is too
large to be supported. In this case, the names of the DataSets shall be formed by concatenating the point
class name and a three digit number ranging from 001 up to but not including the total number of DataSets
required to represent the entire class of points (example: AI001, AI002, AI003...). The same naming conven-
tion also applies to the names of the BasRCB class objects (example: brcbAI001, brcbAI002, ...).
10. Transformer Object Models
10.1 Load Tap Changer Controller Object Model

Load tap changer (LTC) controller is a scheme for the control of LTCs on power transformers and step-volt-
age regulators. The LTC control is associated with one (only) load tap changer. The load tap changer is a sin-
gle-pole or three-pole high current switch that is integral to a single-phase or three-phase transformer, or a
step-voltage regulator.
All digital LTC controllers from the major suppliers provide appreciably more functionality than is available
in equivalent analog control schemes. Fortunately, there is considerable consistency in the available digital
LTC controllers; the differences are mostly associated with features defined for special applications and are
not often specified. LTCC is the abbreviated name used for the LTC controller.
10.2 Description and Application

The LTCC is an electronic device that compares real-time operating conditions to desired control settings.
The control is synonymous with the operation of a voltage regulating relay (IEEE Device 90) when used for
the control of the system voltage. The real-time operating conditions are derived from system voltage, cur-
rent, and other measurements. The control may also receive as input status signals to be used by the operator
to command a particular control operation. Once the settings are exceeded, control actions are performed on
the associated LTC on the power transformer or step-voltage regulator. The control action is determined by

IEEE-SA
the parameters configured in the devices. The principal outputs of the control are the raise and lower signals
used to power the mechanical drive of the LTC. The control scheme may also provide status signals indica-
tive of control operating conditions or particular operational limits.
10.3 Device Function

In the most fundamental sense, the function of the LTCC is to:
Receive scaled power system voltage and current signals. These measurements are always single
phase, although in three-phase applications, they may correspond to line-to-line voltage, and/or
cross-connected phase currents.
Accommodate numerous operator selected control set points, for example the output voltage to be
maintained within certain limits by the LTC action.
Calculate the system performance based on the voltage and current signals, and compare the perfor-
mance to the operation desired by the operator selected set points.
Issue RAISE or LOWER tap changer operation commands, as required, to maintain desired system
voltage.
The LTC control also performs many secondary functions. The LTC control object model includes almost
200 components, many of which may be expanded by use of harmonic order qualifiers.
10.4 Functional Component Descriptions

This section describes in more detail the communications components of a LTC control.
Table 65: LTC Model

MX Present line measurements. Note: There is only one phase of voltage and current to the control.
CtlV AI r m (120 V base) Voltage on load side of transformer
SrcV AI r o (120 V base) Voltage on source side of transformer
LodA AI r o (200 mA base) Current on load side of transformer
CircA AI r o (200 mA base) Circ cur in paralleling application
The following are not line measurements, but are other attributes which may be read from the control
TapPos INT8S r m 16L to 16R LTC tap position -=L, +=R
HiTapPos INT8S r o 16L to 16R Highest tap Pos since reset
LoTapPos INT8S r o 16L to 16R Lowest tap Pos since reset
CntOper INT32U r m 0 to 999,999 Oper Cnt #1. Tap change Oper
CntOperR INT32U r o 0 to 999,999 Oper Cnt #2. Resettable to 0 by operator
Elapsed time for R tap change. Conditional:
TmrR INT16U r o 0 s to 120 s
May be one with L timer.
Elapsed time for L tap change. Conditional:
TmrL INT16U r o 0 s to 120 s
May be one with R timer.
Elapsed time for multiple (second and subse-
TmrSeq INT16U r o 0 s to 10 s
quent) tap changes in sequence.
Present fundamental frequency line measurements calculated in the control. Note: There is only one phase of
voltage and current to the control.
LodCtrV PFD1 r o (120 V base) Calculated voltage at load center
CalSrcV PFD1 r o (120 V base) Calc Transf source side Voltage

IEEE-SA
Table 65: LTC Model (continued)

HV (L-L or L-G) transf secondary. In distribu-
PriV PFD1 r o tion substation will be primary distribution
voltage.
PriA PFD1 r m HV line current - transf secondary
PF PFD1 r m 0.00 to 1.00 Load PF, at transf, 0.01 incr., -= Ld; +=Lg
PriVA PFD1 r m Load on the transformer, 1 or 3 Phs
PriW PFD1 r m Real Pwr load on the transf 1 or 3 Phs.
PriVAr PFD1 r m Reactive load on the trans. 1 or 3 Phs.
Hz PFD1 r o 45.00 to 65.00 Fundamental freq. of the power line
Reg PFD1 r o +/- 20.0% % out V relative. to in V, -= buck, +=boost
THDCtlV PFD1 r o THD V, load side, % of fundamental
THDSrcV PFD1 r o THD V, Src side, % of fundamental
THDA PFD1 r o THD current, % of fundamental
Instantaneous harmonic frequency line measurements calculated in the control. Note: There is only one
phase of voltage and current to the control.
CtlHaV HI r o Harmonic V, load side, rms:
SrcHaV HI r o Harmonic V, source side, rms:
LodHaA HI r o Harmonic A, load side, rms:
Present line fundamental frequency integrated demand measurements.
DmdA PFD1 r m Load A integ Dmd, fundamental freq.
DmdVA PFD1 r m VA load integ Dmd, fundamental freq.
DmdW PFD1 r m W load integ Dmd, fundamental freq.
DmdVAr PFD1 r m VAr load integ Dmd, fundamental freq.
Drag hands (max and min) of particular components above and below
HiCtlV PFD r m (120 V base)
LoCtlV PFD r m (120 V base)
HiSrcV PFD r o (120 V base)
LoSrcV PFD r o (120 V base)
HiCalSrcV PFD r o (120 V base)
LoCalSrcV PFD r o (120 V base)
HiA PFD r o
LoA PFD r o
HiVA PFD r o
LoVA PFD r o
HiW PFD r o
LoW PFD r o
HiVAr PFD r o
LoVAr PFD r o
HiDmdCtlV PFD r o
LoDmdCtlV PFD r o
HiDmdSrcV PFD r o
LoDmdSrcV PFD r o

IEEE-SA

HiDmdCalSrcV PFD r o
LoDmdCalSrcV PFD r o
HiDmdA PFD r m High demand current record
LoDmdA PFD r o Low demand current record
HiDmdVA PFD r m High demand VA record
LoDmdVA PFD r o Low demand VA record
HiDmdW PFD r m High demand real power record
LoDmdW PFD r o Low demand real power record
HiDmdVAr PFD r m High demand reactive power record
LoDmdVAr PFD r o Low demand reactive power record
HiVAPF PFD r o 0.00 to 1.00 PF at max load 0.01 incr., -= Ld, +=lag
LoVAPF PFD r o 0.00 to 1.00 PF at min load 0.01 incr., -= Ld, +=lag
MostLdPF PFD r o 0.00 to 1.00 Most leading PF, 0.01 incr., - =Lead, + =Lag
MostLgPF PFD r o 0.00 to 1.00 Most lagging PF, 0.01 incr., - =Lead, + =Lag
HiReg PFD r o 100.0, up Highest % of out to in V in 0.1% incr.
LoReg PFD r o 100.0, down Lowest % of out to in V, in 0.1% incr.
HiHz PFD r o
LoHz PFD r o
HiLodCtrV PFD r o
LoLodCtrV PFD r o
HiDmdLodCtrV PFD r o
LoDmdLodCtrV PFD r o
Energy related quantities
VAHrs PFD r o Total energy of load
WHrs PFD r o Total real power energy of load
VArHrsLg PFD r o Total lagging VAr energy of the load
VArHrsLd PFD r o Total leading VAr energy of the load
ST AutoMan SIT r o Auto/manual device state
LocRem SIT r o Local/remote device state
VRed ENUM8 r o Status of voltage reduction
CmdSt SIG r m Controller commands status
TapChgSt SIG r m Tap changer status
PwrFlwSt SIG r m Pwr flow direction status
OperCnd SIG r m Controller operation conditions
AlertSt SIG r m Controller alert conditions
AlertSt1 SIG r o Alert status group #1, individual alarms
AlertSt2 SIG r o Alert status group #2, individual alarms
AlertSt[n] SIG r o Alert St group #n. vendor specific (TBD)
SP LTCC SetPoints for desired LTC operation

IEEE-SA

FPFBctr AO rw m 100.0 V - 135.0 V FPFBctr V to be held at the load
RPFBctr AO rw m 100.0 V - 135.0 V RPFBctr V to be held at the load
FPFBwid AO rw m 1.0 V to 6.0 V FPF allowable Bwid of the Bctr V
RPFBwid AO rw m 1.0 V to 6.0 V RPF allowable Bwid of the Bctr V
FPFTim (linear characteristic) after out-of-
FPFTimDel AO rw m 5 s to 120 s
band condition before LTC action
RPFTim (linear characteristic) after out-of-
RPFTimDel AO rw m 5 s to 120 s
band condition before LTC action
Delay after 1st tap Chg for subsequent tap
IntpDel AO rw o 0 s to 10 s
changes until V is in-band
FPFLDCR AO rw m -24 V to 24 V FPFMdl of line drop V due to line Rest
RPFLDCR AO rw m -24 V to 24 V RPFMdl of line drop V due to line Rest
FPFLDCX AO rw m -24 V to 24 V FPFMdl of line drop V due to line React
RPFLDCX AO rw m -24 V to 24 V RPFMdl of line drop V due to line React
FPFLDCZ AO rw o 0 V to 12 V FPF voltage rise at transf at rated current
RPFLDCZ AO rw o 0 V to 12V RPF voltage rise at transf at rated current
LTCC setpoints to select control operating modes
Red. Of Bctr V when invoked by contact clo-
VRedStep1H AO rw m 0.0% to 10.0%
sure, step #1
VRedStep2H AO rw m 0.0% to 10.0% As above, step #2
VRedStep3H AO rw m 0.0% to 10.0% As above, step #3
Reduction of Bctr voltage when invoked by
VRedStep1S AO rw m 0.0% to 10.0%
serial Comm, step #1
VRedStep2S AO rw o 0.0% to 10.0% As above, step #2
VRedStep3S AO rw o 0.0% to 10.0% As above, step #3
Red. Of Bctr V when volt. Red. Auto current
VRedStep1A AO rw o 0.0% to 10.0%
#1 exceeded
VRedStep2A AO rw o 0.0% to 10.0% As above, step #2
VRedStep1C AO rw o 20% to 320% %Cur for invoking VRedStep1A
VRedStep2C AO rw o 20% to 320% %Cur for invoking VRedStep2A
BlkRV AO rw m 100.0 V to 135.0 V CtlV above which auto R Cmd suspend
BlkLV AO rw m 100.0 V to 135.0 V CtlV below which auto L Cmd suspend
RnbkDbV AO rw o 1.0 V to 4.0V V above BlkRV, where L Cmd issued
RnbkRV AO rw o 100 V to 135.0 V V where L Cmd issued (higher than BlkRV)
RnbkLV AO rw o 100 V to 135.0 V V where R Cmd issued (lower than BlkLV)
100 mA to 640 mA, LodA cur above which automatic LTC Ctl
LimLodA AO rw o
incr. 1 mA suspended
TapBlkR INT8S rw o 8R to 16R (+) TapPos where auto R Cmd suspends. R
TapBlkL INT8S rw o 8L to 16L (-) TapPos where auto L Cmd suspends
0 = thermal (Lg),1 Selection of type of demand meter used.
Dmd BOOL rw m = sliding window Thermal technique requires use of technique
(opt) #1 or #2.

IEEE-SA

Demand interval, thermal technique #1. Inte-
DmdInt1 ENUM8 rw o gration time period for all thermal average
(lagged) or sliding window demand quantities.
Demand interval. Thermal technique #2. Inte-
1 to 999 minutes,
DmdInt2 INT16U rw o gration time period for all thermal average
incr. 1 min
(lagged) or sliding window demand quantities.
Number of subperiods for sliding window
DmdSubpd INT8U rw o 1 to 99 subperiods demand meter. Conditional: required if sliding
window used.
VA, power and reactive power displayed as: 0=
PriPwrDis BOOL rw m
1-phase (m), 1= 3-phase (o) quantities
LDC is based on: 0 = R & X model of line;
LDC BOOL rw m
1=Z model of line (optional)
TmrMode b2 rw m Control timing mode options
When voltage, comp comes into band: 0 =
timer integrates (decrements); 1 = timer resets
Tmr BOOL rw o
to zero. Conditional: one mode (r), or user
selection (rw), is satisfactory.
Time delay is: 0 = linear (equals time delay set
TmrDel BOOL rw m point); 1 = follows inverse characteristic as f(V
out-of-band) (opt)
RevPwr b3 rw m Reverse power flow regulation options
Magnitude % of Ctl Load Cur, at which FPF/
r,
RevCur INT8U m 1 to 5%, incr. 1% RPF transition occurs. Vendor may fix (r), or
opt w
make for user select (rw).
Parallel b2 rw m Parallel operating mode
Alert Setpoints
LmtCtlV AISP rw o
LmtLdPF AISP rw o
LmtLgPF AISP rw o
LmtPriA AISP rw o
LmtPriW AISP rw o
LmtPriVA AISP rw o
LmtPriVAr AISP rw o
LmtCntOperR AISP rw o
LmtTapPos AISP rw o
LmtTmrR AO rw o
LmtTmrL AO rw o
Remote command to R or L TapPos 1 step.
CO ODLTC DCO w m Requires TapPosKno = 1, enforcement of
which resides with the LTCC.
LTCBlk BO rw m Blocks/Inhibits all local automatic Ctl
VRedS DCO w o Controls voltage reduction state
LTCVRedMode DCO rw m Select mode of Oper for voltage red
LTCDragRs BO w o Resets HiTapPos & LoTapPos to TapPos
LTCCDragRs b64 w o Individually resets drag-hands

IEEE-SA

LTCOpRs BO w o Resets CntOperR to zero
CF MX ACF rw o Configuration for ALL included MX
SP ACF rw o Configuration for ALL included SP
Acs-
Img rw o Proprietary information
BLOB
LTCC setpoints to configure the control to the installation
VTCorrect INT16S rw o -10.0 V to 10.0 V V add to CtlV to adjust to desired base V
Current added to control load current to adjust
CTCorrect INT16S rw o -50 mA to 50 mA
to desired base current
Angle by which current signal lags voltage
Phasing INT8U rw o 0-330 degrees signal at 1.0 PF, FPF, incr. 30 degrees, 0=0,
1=3011=330
Select VT con, 0 = Ln - to - Ln or 1 = L -to-
VTCfg BOOL rw o
Gnd
Multiplier to Control Voltage for Load Side
VTRatio INT16S rw m 1.0 to 3260.0x
Primary Voltage. Incr. .1x
CTCfg BOOL rw o Select CT con 0= line, 1 = cross connected
1 to 32600x, incr. Multiplier to Ctl Load Cur, for Load Side Pri
CTRatio INT16S rw c
1x Cur. Conditional: Alternate to below
25 A to 2000 A, CT primary A rating - presume 0.2 A s. Condi-
CTPri INT16S rw c
incr. 1 A tional: Alternate to above
Set Oper Cnt to the Cnt of tap change Oper on
0 to 999,999, incr. 1 LTC (used on set-up to pre-establish Oper Cnt
CntOperSet INT32S rw o
count to existing tap changer operations). Compo-
nent may track operations count.
Tap changer position information, 000 indi-
TapInfo b3 rw m
cates no Pos is known
Set Ctl tap Pos to observed tap Pos; Ctl inter-
TapPosSet INT8S rw o 16L to 16R nal tap Pos algorithm used. Comp may track
tap Pos, incr. = 1 step
Select that operation Cnt increments by 1 or 2
r, 0=x1
CntOperIncr BOOL m with Lo - hi - Lo signal state change. Vendor
opt w 1=x2
may fix, or provide user capability to set.
ClockTOD BTIME6 rw m Date and time for min/max data logging.
LTCC limits for report initiation
Report threshold for tap position (high),
RptTapPosHi INT8S rw m
Default is +16
Report threshold for tap position (low),
RptTapPosLo INT8S rw m
Default is -16
Report threshold for transf load (high), Default
RptPriVAHi FLT32 rw m
is 12,000,000 VA
Report threshold for real Pwr transf load
RptPriWHi FLT32 rw m
(high), Default is 10,000,000W
Report threshold for reactive transf load
RptPriVArHi FLT32 rw m
(high), Default is 5,000,000 VAr

IEEE-SA

Report threshold for Circ cur (high), Default
RptCircAHi AO rw o
0.050 Amp
Report threshold for load side voltage (high),
RptCtlVHi AO rw m
Default is 128V
Report threshold for load side voltage (low),
RptCtlVLo AO rw m
Default is 116V
Report threshold for operation count (high),
RptCntOperRHi INT32U rw o
Default is 1000
DC MX d rw o Description for ALL included MX
ST d rw o Description for ALL included ST
SP d rw o Description for ALL included SP
CO d rw o Description for ALL included CO
CktRtg ConCkt rw m Power circuit ID
RP brcbRP BasRCB rw m Controls reporting
Logical Defines path for peer-to-peer IED Communi-
AS TBD o
Device<n> cation
10.4.1 AlertSt
AlertSt is represented by a bit string [16] of individual status points as follows:
(0 = OK, off, 1 = Problem, on):
Alert Status Bit # rwec m/o

Control self test 0 r m
Alert status 1 1 r o
Alert status 2 2 r o
Alert status n (future use) 3-15 r o
10.4.2 AlertSt1
AlertSt1 is represented by a bit string [16] of individual status points as follows:
(0 = OK, off, 1 = alarm, on):

Alert status Bit # rwec m/o
BlkVL 0 r o
BlkVR 1 r o
BlkTapL 2 r o
BlkTapR 3 r o
LimCur 4 r o
RPF 5 r o
VRed 6 r o
CommBlk 7 r o
Unassigned 8-15

IEEE-SA
10.4.3 AlertSt2
AlertSt2 is represented by a bit string [16] of individual status points as follows:
(0 = OK, off, 1 = alarm, on):

CndLodCtrV 0 r o
CndTapPos 1 r o
CndPriVA 2 r o
CndPriW 3 r o
CndPriVAr 4 r o
CndCircA 5 r o
CndCtlV 6 r o
CndCntOperR 7 r o
Unassigned 8-15
10.4.4 Command Status
Command status is represented by a bit string [16] of individual status points as follows:

Raise command status 0 r m
Lower command status 1 r m
VRedStep1S Status 2 r m
VRedStep2S Status 3 r m
Force lower command (V) 4 r o
Force raise command (V) 5 r o
Force lower (TapPos) 6 r o
Force raise (TapPos) 7 r o
Unassigned 8-15
10.4.5 Control Switches Status
Effectively, two position toggle switches are used, allowing four physical states:
10.4.5.1 Local/Remote: (set locally by person)
Local: Enables LOCAL control and disables REMOTE control.

Local control may be either MANUAL, by an operator, or AUTOMATIC by the IED.
Remote: Disables LOCAL control and enables REMOTE control. The remote control may be by
human intervention or by automatic algorithm.

IEEE-SA
10.4.5.2 Auto/Manual for the IED (enabled only when in LOCAL CONTROL)
Manual: Device only controlled manually

Automatic: Device is under control of local automatic control algorithm
The following table defines the relationship of the AutoMan and LocRem switches:
Operation Control
Description
Mode Mode
Manual Local LTC control is by operator at the location
Automatic Local LTC control is via local LTCC algorithm
Automatic Remote LTC operating under LTCC algorithm
Local LTCC algorithm blocked by remote command,
Manual Remote
and LTC under manual control by remote operator.
10.4.6 Dmd
Demand Value rwec m/o

Thermal 0 r m
Sliding Window 1 rw o
10.4.7 DmdInt1
Interval Value rwec m/o

Reserved 0 rw o
15 minutes 1 rw o
30 minutes 2 rw o
60 minutes 3 rw o
10.4.8 LDC

R&X 0 r m
Z 1 rw o
10.4.9 LTCCDragRs
LTCCDragRs is represented by a bit string [64] of individual control points as shown in Table 66. Each
DragHand is reset with the corresponding bit number set to 1.
Table 66: LTCCDragRs Bit Assignments
Reset DragHands Bit # m/o rwec

Reserved 0 w
HiCtlV 1 m w
LoCtlV 2 m w
HiSrcV 3 o w
LoSrcV 4 o w

IEEE-SA
Table 66: LTCCDragRs Bit Assignments (continued)
Reset DragHands Bit # m/o rwec

HiCalSrcV 5 o w
LoCalSrcV 6 o w
HiA 7 o w
LoA 8 o w
HiVA 9 o w
LoVA 10 o w
HiW 11 o w
LoW 12 o w
HiVAr 13 o w
LoVAr 14 o w
HiDmdCtlV 15 o w
LoDmdCtlV 16 o w
HiDmdSrcV 17 o w
LoDmdSrcV 18 o w
HiDmdCalSrcV 19 o w
LoDmdCalSrcV 20 o w
HiDmdA 21 m w
LoDmdA 22 o w
HiDmdVA 23 m w
LoDmdVA 24 o w
HiDmdW 25 m w
LoDmdW 26 o w
HiDmdVAr 27 m w
LoDmdVAr 28 o w
HiVAPF 29 o w
LoVAPF 30 o w
HiReg 31 o w
LoReg 32 o w
HiHz 33 o w
LoHz 34 o w
MostLdPF 35 o w
MostLgPF 36 o w
HiLodCtrV 37 o w
LoLodCtrV 38 o w
HiDmdLodCtrV 39 o w
LoDmdLodCtrV 40 o w
VAHrs 41 o w
WHrs 42 o w
VArHrsLg 43 o w
VArHrsLd 44 o w
Unassigned (future use) 45-63 o w

IEEE-SA
10.4.10 OperatingConditions
OperatingConditions is represented by a bit string [16] of individual status points as follows.
(0 = no, InBand, OperNotInhibited, not in effect, 1 = yes, OutOfBand, OperInhibited, InEffect):
OperatingConditions Bit # rwec m/o

In band condition 0 r m
Low band edge condition 1 r m
High band edge condition 2 r m
Low voltage limiting condition 3 r m
High voltage limiting condition 4 r m
High current limiting condition 5 r o
Voltage reduction condition 6 r m
Auto inhibit condition 7 r o
Unassigned 815
10.4.11 Parallel
Bit
Description rwec m/o
Order
Disable 00 r m
Circulating current 01 rw o
VAr balance 10 rw o
10.4.12 Power Flow Status
Power flow status is represented by a bit string [16] of individual status points as follows.
(0 = indeterminate, FPF, not blocked, 1 = determinate, RPF, blocked):
Power Flow Status Bit # rwec m/o

Power direction knowledge 0 r m
Power direction status 1 r m
Control power direction status 2 r m
RPF block 3 r o
Unassigned (future use) 4-15
In the interest of simplicity, the individual DataObjects for MX and SP configuration are omitted from this
object model. The configuration for all components previously identified are included.

IEEE-SA
Vendors should supply meaningful defaults for all Rpt threshold values.
Attribute brcbRP
RptID NULL
RptEna FALSE
DataSet Report
OptFlds All options
BufTim 0
Trgs 0
SeqNum 0
TrgOps All conditions enabled
RBEPd 0
IntgPd 0
brcbRP: The brcbRP evaluation function consists of eight subfunctions, each of which monitor a different
controller condition. Each subfunction can be enabled or disabled by setting the appropriate function condi-
tion bit in the TrgOps field of the BasRCB. Report all values in the DataSet (Report 1) when one or more of
the functions trigger. The reason codes reported must contain the function conditions for all functions that
have triggered. The bit assignments are:
Condition Bit # Definition

CndLodCtrV 0 Load center voltage limits
CndTapPos 1 Tap position limits
CndPriVA 2 Load on transformer limit
CndPriW 3 Real Pwr load on trans. limit
CndPriVAr 4 Reactive load on trans. limit
CndCircA 5 Circ current limit
CndCtlV 6 Load side voltage limits
CndCntOperR 7 Operation count limit
The definition of the evaluation subfunctions are:
CndLodCtrV: If PwrFlwSt(2) is equal to 0

and LodCtrV is less than FPFBctr - (0.5 * FPFBwid)
for a time duration greater than (FPFTimDel + 60 seconds),
Or LodCtrV is greater than FPFBctr + (0.5 * FPFBwid)
for a time duration greater than (FPFTimDel + 60 seconds),
Or If PwrFlwSt(2) is equal to 1
and LodCtrV is less than RPFBctr - (0.5 * RPFBwid)
for a time duration greater than (RPFTimDel + 60 seconds),
Or LodCtrV is greater than RPFBctr + (0.5 * RPFBwid)
for a time duration greater than (RPFTimDel + 60 seconds).

IEEE-SA
CndTapPos: If MX.TapPos attains RptTapPosHi from below,

or attains RptTapPosLo from above
CndPriVA: If MX.PriVA crosses RptPriVAHi from below
CndPriW: If MX.PriW crosses RptPriWHi from below
CndPriVAr: If MX.PriVAr crosses RptPriVArHi from below
CndCircA: If MX.CircA crosses RptCirAHi from below
CndCtlV: If MX.CtlV crosses RptCtlVHi from below
or if MX.CtlV crosses RptCtlVLo from above
CndCntOperR: If MX.CntOperR crosses RptCntOperR from below
10.4.15 RevPwr
Control Response Bit

Description rwec m/o
FPF RPF Order
Regulate Fwd & Rvs, V basis Fwd Rvs 010 rw m
Regulate Fwd, block Rvs Fwd Lock on tap 000 rw m
Ignore PwrFlwDir, forward lock Fwd Fwd 001 rw m
Ignore PwrFlwDir, reverse lock Rvs Rvs 101 rw o
Reverse, neutral return Fwd Run tap to Neut 110 rw o
Regulate Fwd & Rvs, VAr basis 011 rw o
Co-generation 100 rw o
10.4.16 Tap Changer Status

Tap changer status is represented by a bit string [16] of individual status points as follows.
(0 = not sealed/no/open/off neutral tap, 1 = sealed, yes, closed, on neutral tap):
Tap Changer Status Bit # rwec m/o

Motor drive seal-in 0 r o
TapPosKno 1 r m
Oper Ctl Ckt St 2 r o
Neutral tap position status 3 r o
Low tap position limiting 4 r o
High tap position limiting 5 r o
10.4.17 TapInfo
TapInfo is represented by a bit string [3].
Means of Knowing LTC Tap Position Bit Order m/o rwec

Disable 000 m r, opt w
Internal 001 m r, opt w
External #1 010 o r, opt w

IEEE-SA
10.4.18 Tmr
Note that only one timer is mandatory; if both are provided, rw is required.

Integrating 0 r m
Instantaneous reset 1 rw o
10.4.19 TmrDel

Linear 0 r m
Inverse 1 rw o
10.4.20 TmrMode
Bit
Mode rwec m/o
Order
Sequential 00 r m
Nonsequential 01 rw o
Sequential with delay (shorter delay) 10 rw o
Voltage averaging (control counts steps
11 rw o
required)
10.4.21 VRed
VRed is the combined status of voltage reduction mode and voltage reduction stage.
VRed Value rwec m/o

Off (no reduction) 1 r m
Step1H (contact closure) 2 r m
Step1S (serial comm) 5 r m
Step2S (serial comm) 6 r o
Step3S (serial comm) 7 r o
Step1A (auto - current #1 exceeded) 8 r o

IEEE-SA
10.4.22 VRedS
VRedS is voltage reduction via serial communication.
Bit
VRedS m/o
Order
No reduction 00 o
Stage 1 01 o
Stage 2 10 o
Stage 3 11 o
10.5 DataSets
the LTC and SVR controllers contain DataSets for retrieval by a client. Numerous DataSets are defined for
the LTC control object model. Some attributes may appear in several DataSets, while other attributes may
not be assigned to any DataSet. The main DataSets defined for the LTC and SVR control schemes are as
shown in Table 67.
Table 67: LTCC DataSets

DataSet Components
DataSet No. DatSet Intended Use
(Object Attributes)
1 LTCC.MX All measurements Reading
2 LTCC.ST All status points Reading
3 LTCC.SP All setpoints Reading
4 LTCC.LineStatus CtlV Reading
PriV
PF
PriA
PriW
PriVA
PriVAr
CircA
5 LTCC.LTCStatus CntOper Reading
CntOperR
HiTapPos
LoTapPos
TapChgSt
TapPos
6 LTCC.LTCCStatus CmdSt Reading
OperCond
TmrL
TmrR
7 LTCC.BasicSP FPFBctr Reading
RPFBctr
FPFBwid
RPFBwid
FPFLDCR

IEEE-SA
Table 67: LTCC DataSets (continued)

DataSet Components
DataSet No. DatSet Intended Use
(Object Attributes)
RPFLDCR
FPFLDCX
RPFLDCX
FPFTimDel
RPFTimDel
8 LTCC.Report1 All of LineStatus and LTCStatus Reading and reporting
11. Switch Object Model

The following object models for switches are provided:
Model
Switch Device
NAME
SwC Switch controller
ASwC Automated switch controller
BkrC Breaker controller
Recl Recloser
11.1 Switch Controller Object Model

This section describes basic control of a switch. The switch controller represents the simplest measurement,
setpoints, status, and control of switch devices, such as isolators/disconnectors. SwC is the abbreviated name
used for switch controller.
The SwC is used for normal operation of the switch, as in local control, SCADA control, automated function
control, or any other form of local or remote client command. The SwC is also used for operation of the
switch for protection purposes since the controller governs the switch interlocking and switch control failure
mechanisms.
The SwC is responsible for the management and verification of the interlocking and tagging (control access)
logic before the switch field device is allowed to operate.
Note: The physical switch field device and the control of the switch are modeled separately since the switch
may be a disconnector/isolator with no remote control mechanism (requiring human operation). The switch
controller represents the actual close and trip operations of the switch according to specific applications
associated with the field device, or from actions initiated by local, supervisory, or protective device clients.

IEEE-SA
Table 68: SwC Model

MX OperCnt AccI o Number of Sw operations
The Tim in msec for the switch to complete Oper from
SwOperTim AI o
when the ODSw Cmd was issued
The number of times that the controller has Cmd the
CtlCmdCnt AccI o
switch to Oper
ST SwDS SIT m Inherited from Sw
LocRemDS SIT o The mode of control, local or remote (DevSt)
CtlFailInd SI o CtlFailTime has expired w/o the control action occurring.
CtlTagBlk SI o Switch operation blocked due to a tag
CtlIntlkBlk SI o Switch operation blocked by Intlk logic
CF ClockTOD BTIME6 m Date and time for data logging
Same As SwC.MX ACF o Configuration for SwC.MX
Same As SwC.CO CCF o Configuration for SwC.CO
DC All Sw.DC m Inherited from Sw
Same As SwC.MX d m Description of all included SwC MX
Same As SwC.ST d m Description of all included SwC ST
Same As SwC.CO d m Description of all included SwC CO
AX All Sw.Ax Inherited from Sw
AS Logical Device<n> TBD o Defines path for peer-to-peer IED communication
11.1.1 Default Settings for RP Objects

RptID NULL NULL
RptEna FALSE FALSE
DatSet MX ST
BufTim 0 0
Trgs 0 0
SeqNum 0 0
TrgOps CndDataChange CndDataChange
RBEPd 0 0
IntgPd 0 0
member.

IEEE-SA
11.1.3 DataSets
the switch controller contains DataSets for retrieval by a client. Numerous DataSets are defined for the
switch control object model. Some attributes may appear in several DataSets, while other attributes may not
be assigned to any DataSet. The main DataSets defined for the switch control schemes are as follows:
DataSet Components
DataSet No. DatSet
(Object Attributes)
1 SwC.MX All measurements
2 SwC.ST All status points
3 SwC.SP All setpoints
4 SwC.SOELog All SOE points
5 SwC.dbEvents All deadband events
6 SwC.STEvents All status change events
11.2 Automated Switch Controller Object Model

This section describes the automated switch control object model that consists of a set of elements character-
izing the common capabilities of an automated switch on a distribution line. The Automated switch control-
ler represents an extension of the basic switch controller. ASwC is the abbreviated name used for automated
switch controller.
The ASwC is used for automatic operation of the switch, as in distribution automation.
The ASwC is responsible for the management and verification of the interlocking and tagging logic before
the equipment is allowed to operate.
See Table 69.
Table 69: ASwC Model

MX All SwC.MX Inherited from SwC
V WYE o Voltage on phase A, B, C to G
A WYE o Current in phase A, B, C, and N
W WYE o Watts in phase A, B, C
TotW AI o Total watts in all 3 phases
VAr WYE o VArs in phase A, B, C
VA WYE o VA in phase A, B, C
TotVA AI o Total VA in all 3 phases.
PF WYE o Power factor for phase A, B, C
AvgPF AI o Average power factor of all 3 phases
FltMagA WYE o Fault magnitude in phase A, B, C, N
ST All SwC.ST Inherited from SwC
AutoManDS SIT o Manual or automatic operation (DevSt)
FIA BSTR16 o Indicates normal or overcurrent fault types
FIB BSTR16 o Indicates normal or overcurrent fault types
FIC BSTR16 o Indicates normal or overcurrent fault types

IEEE-SA
Table 69: ASwC Model (continued)

FIN BSTR16 o Indicates normal or overcurrent fault types
PwrSupSt SIG o Switch power supply status indication
SF6GasLoAlm SI o SF6 low pressure condition indication
SP All SwC.SP Inherited from SwC
FIPuThre PUG o Pickup Thre for phase A, B, C, N
FIPuHyst PUG o Pickup Hyst for phase A, B, C, N
FIInrushDel PUG o Inrush Delay for phase A, B, C, N
FIZeroThre PUG o Zero Thre for phase A, B, C, N
NumFltToLO AO o Number of faults before lockout
OpenTimDel AO o Time delay before open when in auto mode
CommTimOut AO o Communication time-out period
CO All SwC.CO Inherited from SwC
ODAutoMan DCO m Sets Oper mode to automatic/manual
FIRs BO o Fault indicator reset
StartBatTest BO o Start battery test
CF ClockTOD BTIME6 m Date and time for data logging.
Same As ASwC.MX ACF m Configuration of ALL included ASwC MX
Same As ASwC.SP ACF m Configuration of ALL included ASwC SP
Same As ASwC.CO CCF o Configuration of ALL included ASwC.CO
DC SwRtg EqRtg m Inherited from Sw
ConCkt ConCkt m Inherited from Sw
Same As ASwC.MX d m Description of ALL included ASwC MX
Same As ASwC.ST d m Description of ALL included ASwC ST
Same As ASwC.SP d m Description of ALL included ASwC SP
Same As ASwC.CO d m Description of ALL included ASwC CO
AX All Sw.AX m Inherited from Sw
AS Logical Device<n> TBD o Defines path for peer-to-peer communication
11.2.1 Automation Parameters (AutoPar)

AutoPar contain various parameters associated with automation capabilities. These parameters are set by the
client to change the operating characteristic of the switch.
11.2.2 Communication Parameters

The SP.CommTimOut parameter sets the time-out time for switching from remote manual mode to local
automatic mode if communication is lost.

IEEE-SA
11.2.3 Fault Indicator (FI) Parameters

FI parameters are optional. They contain various parameters associated with fault indicators. These parame-
ters are set by the client to change the operating characteristic of the switch.
11.2.4 FI<Phase>
The bits represented by FI are:
Bit Name Bit Number

Inrush 0
Real Fault 1
Lockout 2
Forward 3
Reverse 4
If the bit is set to 1, it represents ON or asserted. If the bit is set to a 0, it represents OFF or not
asserted. The resetting of the bits can be done automatically when a condition no longer persists and the
exception is acknowledged by the client. Alternatively, they can be reset by the fault indicator reset com-
mand. The option is left open for the customer and vendor to decide.
11.2.5 Fault Indicator Reset (FIR)
The FIR is written to by the client in order to initiate a reset of all fault indicators. The control is momentary
with a default activation time of 1 second.
The controller may have been configured to automatically reset the fault indicators in which case the
CO.FIRs data component is not needed. The Co.FIRs DataObject resets all set fault indicators. The correla-
tion between this control command and the state of the ST.FI value is handled within the server.
11.2.6 PwrSupSt
This indicates the status of the power supply of the automated switch. The alarm is read only and is reported
as an exception when any changes occur in either direction. The bits representing PwrSupSt are shown in the
table below. Each bit is set to a 1 whenever the condition it represents is true, and returns to 0 whenever
the condition returns to false.
Bit Name Bit Number

AC On 0
Battery low 1
Battery high 2
Battery test in progress 3
Battery test fail 4
Future 5-15

IEEE-SA

RptID NULL NULL
RptEna FALSE FALSE
DatSet MX ST
BufTim 0 0
Trgs 0 0
SeqNum 0 0
RBEPd 0 0
IntgPd 0 0
member.
11.2.9 DataSets
the automated switch controller contains datasets for retrieval by a client. Numerous DataSets are defined for
the automated switch control object model. Some attributes may appear in several DataSets, while other
attributes may not be assigned to any DataSet. The main DataSets defined for the automated switch control
schemes are as follows:
DataSet Components
DataSet No. DatSet
(Object Attributes)
1 ASwC.MX All measurements
2 ASwC.ST All status points
3 ASwC.SP All setpoints
4 ASwC.SOELog All SOE points
5 ASwC.dbEvents All deadband events
6 ASwC.STEvents All status change events
11.3 Circuit Breaker Controller Object Model
11.3.1 Introduction
This section describes control of a circuit breaker. Circuit breaker controller represents the simplest mea-
surement, setpoints, status, and control of breaker devices. The abbreviated name for the circuit breaker con-
troller is CBC.

IEEE-SA
11.3.2 Description and Application
The CBC is a specialization of the automated switch controller since breaker is a specialization of the switch
in the field device object. The CBC is associated with more functionality, measurements, and status points
than the automated switch controller. The CBC defines the basic operation of the breaker field device. The
CBC is used for normal operation of the breaker, as in local UI control, automation, etc. The CBC is also
used for operation of the breaker for protection purposes since the controller governs the interlocking, tag-
ging, and breaker control failure mechanisms.
Note: The physical breaker device and the control of the breaker are modeled separately since the CBC rep-
resents the actual close and trip operations of the breaker according to specific applications associated with
the field device, or from actions initiated by local, supervisory, or protective device clients.
11.3.2.1 Synchronism Check
The CBC includes optional synchronism check. Synchronism check determines whether the following three
measurements are within prescribed limits before allowing closing or reclosing of the breaker to occur:
1) Phase angle difference across the breaker

2) Voltage magnitude difference across the breaker
3) Frequency difference across the breaker
If all three criteria are not met, the synchronization logic does not lock out, but waits for the measurements
to be acceptable within a certain defined time period.
11.3.3 Breaker Controller Functional Component Descriptions

Table 70: CBC Model

MX All ASwC.MX Inherited from ASwC
Hz AI o Frequency
BusbarV AI o
BayV AI o
RunV AI o The reference V for synchronism check logic
The V compared with the RunV by the synchronism
IncomingV AI o
check logic
AngDiff AI o Diff in Phs Ang between the RunV and the IncomingV
SyncVDiff AI o Diff in V magnitude between RunV and IncomingV
SyncHzDiff AI o Diff Freq between RunV and IncomingV
The time interval that the Sync process is in progress
SyncChkDur INT16U o
since the Bkr close or reclose Cmd was initiated.
ST All ASwC.ST Inherited from ASwC
SwPoleDS BSTR8 o Inherited from Bkr
Indicates if the individual poles of the breaker have oper-
UneqPoleDS SI o
ated correctly
BkrCtlFailSt SIG o Status of the breaker failure logic
IND set once the CtlFailTime has expired and no control
BkrCtlFailInd SI o
action occurred
SyncSt SIG o Status of the synchronization logic
ReclDS SIT o Status of the reclose action

IEEE-SA
Table 70: CBC Model (continued)

SP Same As CB.SP Inherited from BKR
CO All ASwC.CO Inherited from ASwC
BkrFailAction DCO o The action taken once the breaker has failed
CF Same As CBC.MX ACF m ALL included BkrC MX
Same As CBC.SP ACF m ALL included BkrC SP
Same As CBC.CO CCF o ALL included BkrC.CO
Img AcsBLOB rw o Proprietary Information
DC BkrRtg EqRtg m
ConCkt ConCkt m
Same As CBC.MX d o Description of ALL included BkrC.MX
Same As CBC.ST d o Description of ALL included BkrC.ST
Same As CBC.SP d o Description of ALL included BkrC.SP
Same As CBC.CO d o Description of ALL included BkrC.CO
11.3.3.1 BkrCtlFailSt
The bits representing BkrCtlFailureSt are:
Bit Name Bit Number

On 0
Off 1
Failure 2
Start order 3
Trip order 4
11.3.3.2 SyncSt
The bits representing SyncSt are:
Bit Name Bit Number

Running 0
On 1
Off 2
Fail 3
Start order 4

IEEE-SA
11.3.3.3 ReclDS
The bits representing RecloseDS are:
Bit Name Bit Number

Reclose inhibited 00
Successful reclose 01
Reclose and lock out 10

RptID NULL NULL
RptEna FALSE FALSE
DatSet MX ST
BufTim 0 0
Trgs 0 0
SeqNum 0 0
RBEPd 0 0
IntgPd 0 0
member.
11.3.4 DataSets
the breaker controller contains datasets for retrieval by a client. Numerous DataSets are defined for the
breaker control object model. Some attributes may appear in several DataSets, while other attributes may not
be assigned to any DataSet. The main DataSets defined for the Breaker control schemes are as follows:
DataSet Components
DataSet No. DatSet
(Object Attributes)
1 BkrC.MX All measurements
2 BkrC.ST All status points
3 BkrC.SP All setpoints
4 BkrC.SOELog All SOE points
5 BkrC.dbEvents All deadband events
6 BkrC.STEvents All status change events
11.4 Recloser Control Object Model

The recloser control is a specialization of the BkrC. The recloser control defines the basic operation of spe-
cialized Bkr. The recloser control includes components of a switch, along with protection, and reclosing

IEEE-SA
models in a single device object model. An integrated protection scheme controls the operation of a special-
ized breaker such that it will perform a predetermined trip and reclose sequence when subjected to sustained
faults.
The recloser control is considered a specialization of the BkrC since the reclosing scheme adds further logic
but must be subject to other conditions defined in the BkrC, i.e., interlocking, control failure, synchronism
check, etc. The abbreviated name of the recloser control object model is Recl.
Table 71: Recl Model

MX V WYE o Inherited from MU
SrcV AI o Inherited from MU
A WYE o Inherited from MU
W WYE o Inherited from MU
TotW AI o Inherited from MU
VAr WYE o Inherited from MU
TotVAr AI o Inherited from MU
VA AI o Inherited from MU
TotVA AI o Inherited from MU
PF WYE o Inherited from MU
AvgPF AI o Inherited from MU
SeqV Seq o Inherited from MU
SeqA Seq o Inherited from MU
WHr WYE o Inherited from MU
TotWHr AI o Inherited from MU
VArHr WYE o Inherited from MU
TotVArHr AI o Inherited from MU
Hz AI o Inherited from MU
BattV AI o Inherited from MU
FltMagA WYE o Inherited from MU
ST SwDS SIT m Inherited from Sw
LocRemDS SIT o Inherited from SwC
AutoManDS SIT o Inherited from SwC
CtlFailInd SI o Inherited from SwC
CtlTagBlk SI o Inherited from SwC
CtlIntlkBlk SI o Inherited from SwC
PwrSupAlm SIG o Switch power supply status indication
SF6GasLoAlm SI o SF6 low pressure condition indication
BkrCtlFailDS SIG o Status of the breaker failure logic
BkrCtlFailInd SI o Inherited from ASwC
ReclDS SIT o Indicates the status of the reclose action
IOCOut BOOL r o Inherited from IOC
IOCTar PhsTar r o Inherited from IOC
TOCOut BOOL r o Inherited from TOC
TOCTar PhsTar r o Inherited from TOC
RecROut BOOL r o Inherited from RecR
RecRTar PhsTar r o Inherited from RecR

IEEE-SA
Table 71: Recl Model (continued)

SP Same As Bkr.SP Inherited from BKR
IOCPu PUG rw o Inherited from IOC
TOCPu PUG rw o Inherited from TOC
ReclPu PUG rw o Inherited from RecR
CrvMult PUG o Inherited from BTCO
CrvTyp TimCrv o Inherited from BTCO
TimDial AO o Inherited from BTCO
ReclSeq SHOTS rw m Reclosing sequence
CO All ASwC.CO Inherited from ASwC
The action taken once it has been determined that
BkrFailAction DCO o
operation of the breaker has failed.
EnaDisIOCFct DCO w o Enable/disable relay function
EnaDisTOCFct DCO w o Enable/disable relay function
EnaDisFct DCO w o Enable/disable relay function
RsTar BO w o Reset ALL targets
RsLat BO w o Reset ALL latched outputs
IniRecl DCO rw o Inherited from RecR
Block of 16 individually addressable auxiliary
AuxOut<n> BOOL[16] w o
outputs
CF Same As Recl.MX ACF m ALL included Recl.MX
Same As Recl.SP ACF m ALL included Recl.SP
Same As Recl.CO CC o ALL included Recl.CO
DC ReclRtg EqRtg m
ConCkt ConCkt m
All MX d o Description of ALL included Recl.MX
All DC d o Description of ALL included Recl.ST
All SP d o Description of ALL included Recl.SP
All CO d o Description of ALL included Recl.CO
GOOSE PACT r o Generic object oriented substation event

IEEE-SA

RptID NULL NULL
RptEna FALSE FALSE
DatSet MX ST
BufTim 0 0
Trgs 0 0
SeqNum 0 0
RBEPd 0 0
IntgPd 0 0
member.
11.4.3 DataSets
the recloser controller contains datasets for retrieval by a client. Numerous DataSets are defined for the
recloser controller object model. Some attributes may appear in several DataSets, while other attributes may
not be assigned to any DataSet. The main DataSets defined for the recloser controller are as follows:
DataSet Components
DataSet No. DatSet
(Object Attributes)
1 Recl.MX All measurements
2 Recl.ST All status points
3 Recl.SP All setpoints
4 Recl.SOELog All SOE points
5 Recl.dbEvents All deadband events
6 Recl.STEvents All status change events
12. Reactive Component Object Models
12.1 Capacitor Bank Controller Object Model

This section describes basic control of a capacitor bank. The capacitor bank controller represents the mea-
surements, setpoints, status, and control of capacitor banks. CapC is the abbreviated name used for capacitor
bank controller.

IEEE-SA
12.1.1 Description and Application
The CapC is used in the operation of shunt capacitance on transmission and feeder lines and buses. The
CapC is used for local control, SCADA control, automated function control, or any other form of local or
remote client command. The algorithm for controlling the capacitor bank can depend on a single or combi-
nation of measurements, such as time of day, voltage level, power factor, and VAr flow. Capacitor bank con-
trol can also be initiated by a client, e.g., SCADA (manual control).
Note: The physical capacitor bank field device, the line or bus monitor, the switch to energize and de-ener-
gize the capacitor bank, the control of the switch, and the control of the capacitor bank, are modeled sepa-
rately. The capacitor bank switch is a type of switch field device and is modeled in the switch object model
section.
12.1.2 Functional Component Descriptions

Table 72: CapC Model

MX V WYE r o Inherited from measurement unit
PhsPhsV DELTA r o Inherited from measurement unit
A WYE r o Inherited from measurement unit
W WYE r o Inherited from measurement unit
VAr WYE r o Inherited from measurement unit
VA WYE r o Inherited from measurement unit
PF WYE r o Inherited from measurement unit
Ang WYE r o Inherited from measurement unit
AirT AI r o Inherited from measurement unit
OperCnt AccI r o Inherited form SwC
ST SwPoleDS BSTR8 r o Inherited from Bkr
LocRemDS SIT r o Inherited from SwC
AutoManDS SIT r o Inherited from SwC
CtlFailTimDS SIT r o IND CtlFailTim has expired w/o the Ctl Act occur
OVDS SI r o Indicates voltage override control status
Out BOOL r o Inherited from DOC relay
NeutAlm BOOL r o Indicates neutral alarm is present
DSTDS SIT r o Indicates if DST is active
SensorSt SIG r o Indicates health of sensors
DschBlkDS SI r o Cap Bank Sw close Blk due DschTimDel
DoorDS SIT r o Cabinet door open or closed
CBDS SIT r o Capacitor bank device state
PwrSupAlm SIG r o Inherited from ASwC
SP VPu CBPUG rw o Voltage control setpoints
APu CBPUG rw o Current control setpoints
VArPu CBPUG rw o VAr control setpoints
NeutAPu CBPUG rw o Neutral current setpoints
HiBadV AO rw o V above which sensor has failed
LoBadV AO rw o V below which sensor has failed
TimSched CBTim rw o Schedule for time control

IEEE-SA
Table 72: CapC Model (continued)

StartTS BTIME6 rw o Start time for time schedule
StopTS BTIME6 rw o Stop time for time schedule
StartDST BTIME6 rw o Start time for day light savings time
StopDST BTIME6 rw o Stop time for day light savings time
CO ODAutoMan DCO w m Inherited from ASwC
ODSw DCO w m Inherited from SwC
CF ClockTOD BTIME6 rw o Inherited from MU
OperLogic SIG rw m Defines operating logic for automatic control
DschTimDel INT16U rw o Min CB Sw Open Time in seconds
MaxOper INT8U rw o Maximum number of daily operations
Same as
ACF rw o Configuration for CapC MX
CapC.MXC.MX
Same As
ACF rw o Configuration for CapC SP
CapC.SP
Same As
DC d rw m Description of all included CapC MX
CapC.MX
Same As
d rw m Description of all included CapC ST CBPUG
CapC.ST
Same As
d rw m Description of all included CapC SP
CapC.SP
Same As
d rw m Description of all included CapC CO
CapC.CO
Img AcsBLOB rw o Proprietary Information
AS All related IEDs TBD rw m Associations with all related IEDs

RptID NULL NULL
RptEna FALSE FALSE
DatSet MX ST
BufTim 0 0
Trgs 0 0
SeqNum 0 0
RBEPd 0 0
IntgPd 0 0
12.1.2.2 Specification of Evaluation Functions
member.

IEEE-SA
12.1.2.3 OperLogic
The bits representing OperLogic are:
OperLogic Bit #
Reserved 0
Time schedule 1
Temperature 2
VAr 3
Voltage 4
Voltage override 5
(future) 6-15
12.1.2.4 SensorSt
The bits representing SensorSt are:
SensorSt Bit #
Reserved 0
Reverse current 1
Voltage bad 2
Current bad 3
Phase angle bad 4
(future) 5-7
12.2 DataSets
the CapC contains DataSets for retrieval by a client. Numerous DataSets are defined for the CapC object
model. Some attributes may appear in several DataSets, while other attributes may not be assigned to any
DataSet. The main DataSets defined for the CapC are as follows:
DataSet Components
DataSet No. DatSet
(Object Attributes)
1 CapC.MX All measurements
2 CapC.ST All status points
3 CapC.dbEvents All deadband events
4 CapC.STEvents All status change events

IEEE-SA
Appendix A
Example Mapping of a GOMSFE CapC Model to MMS
Table A.1 contains a complete model of a CapC with all optional components included. Note that most
applications will leave out most optional components. Refer to the definitions earlier in the document to
determine the minimum required components to include:
CASM Class Key
LD LogicalDevice
DI DeviceIdentity
DM DeviceModel
FC FunctionalComponent
DS DataSet
MMS Class Key
DO Domain
NV Named variable
NVL Named variable list
AA Alternate access used to obtain component
Table A.1: Mapping of CapC to MMS
CASM MMS
CASM Class MMS Class
Component Object MMS Variable Name
(DataType) (Type)
CapC00001 LD DO CapC_00001
DI DI (struct) NV (struct) DI
DI.Name Name (VSTR32) NV (vstr32) DI$Name
DI.Class Class (VSTR16) NV (vstr16) DI$Class
DI.d d (VSTR32) NV (vstr32) DI$d
DI.Own Own (VSTR32) NV (vstr32) DI$Own
DI.Loc Loc (VSTR32) NV (vstr32) DI$Loc
DI.VndID VndID (STRUCT) NV (struct) DI$VndID
DI.VndID.Vnd Vnd (VSTR6) NV (vstr6) DI$VndID$Vnd
DI.VndID.Mdl Model (VSTR32) NV (vstr32) DI$VndID$Mdl
DI.DevMdls (vstr32) NV (vstr32) DI$DevMdls
DI.VndID.SerNum SerNum (VSTR32) NV (vstr32) DI$VndID$SerNum
DI.VndID.HwRev HwRev (VSTR8) NV (vstr8) DI$VndID$HwRev
DI.VndID.SftRev SftRev (VSTR8) NV (vstr8) DI$VndID$SftRev
Di.CommID CommID (STRUCT) NV (struct) Di$CommID
CommAddr
DI.VndID. CommAdr NV (vstr16) DI$VndID$ CommAdr
(VSTR16)
DI.VndID. CommRev CommRev (VSTR8) NV (vstr8) DI$VndID$ CommRev
DI.CommID.Pro Pro (enum8) NV (enum8) DI$CommID$Pro
DI.CommID.Med Med (enum8) NV (enum8) DI$CommID$Med
DI.CommID.MAC MAC (int8u) NV (int8u) DI$CommID$MAC

IEEE-SA
Table A.1: Mapping of CapC to MMS (continued)
CASM MMS
(DataType) (Type)
CapC dm (struct) NV (struct) CapC
CapC.DC fc (struct) NV (struct) CapC$DC
CapC.DC.CBRtg ERtg (STRUCT) NV (struct) CapC$DC$CBRtg
CapC.DC.CBRtg.VRtg VRtg (VSTR16) NV (vstr16) CapC$DC$CBRtg$VRtg
ContCurRtg
CapC.DC.CBRtg.ContCurRtg NV (vstr16) CapC$DC$CBRtg$ContCurRtg
(VSTR16)
CapC.DC.CBRtg.TempRtg TempRtg (VSTR16) NV (vstr16) CapC$DC$CBRtg$TempRtg
CapC.DC.ConCkt ConCkt (STRUCT) NV (struct) CapC$DC$ConCkt
CapC.DC.ConCkt.CktID CktID (VSTR32) NV (vstr32) CapC$DC$ConCkt$CktID
CapC.DC.ConCkt.CktPhs CktPhs (VSTR16) NV (VSTR16) CapC$DC$ConCkt$CktPhs
CapC.DC.ConCkt.LinLenm LineLenm (INT16U) NV (INT16U) CapC$DC$ConCkt$LinLenm
ContCur-
CapC.DC.ConCkt.ContCurRtg NV (VSTR16) CapC$DC$ConCkt$ContCurRtg
Rtg(VSTR16)
CapC.DC.ConCkt.VRtg VRtg (VSTR16) NV (VSTR16) CapC$DC$ConCkt$VRtg
CapC.DC.ConCkt.PosiSeqZ (VSTR16) NV (VSTR16) CapC$DC$ConCkt$PosiSeqZ
CapC.DC.ConCkt.NegSeqZ (VSTR16) NV (VSTR16) CapC$DC$ConCkt$NegSeqZ
CapC.DC.ConCkt.ZeroSeqZ (VSTR16) NV (VSTR16) CapC$DC$ConCkt$ZeroSeqZ
CapC.DC.ConCkt.Ko (VSTR16) NV (VSTR16) CapC$DC$ConCkt$Ko
CapC.DC.V (struct) NV (struct) CapC$DC$V

CapC.DC.V.d d(VSTR32) NV (VSTR32) CapC$DC$V$d
CapC.DC.PhsPhsV (struct) NV (struct) CapC$DC$PhsPhsV
CapC.DC.PhsPhsV.d d(VSTR32) NV (VSTR32) CapC$DC$PhsPhsV$d
CapC.DC.A (struct) NV (struct) CapC$DC$A
CapC.DC.A.d d(VSTR32) NV (VSTR32) CapC$DC$A$d
CapC.DC.W (struct) NV (struct) CapC$DC$W
CapC.DC.W.d d(VSTR32) NV (VSTR32) CapC$DC$W$d
CapC.DC.Var (struct) NV (struct) CapC$DC$Var
CapC.DC.Var.d d(VSTR32) NV (VSTR32) CapC$DC$Var$d
CapC.DC.VA (struct) NV (struct) CapC$DC$VA
CapC.DC.VA.d d(VSTR32) NV (VSTR32) CapC$DC$VA$d
CapC.DC.Pf (struct) NV (struct) CapC$DC$Pf
CapC.DC.Pf.d d(VSTR32) NV (VSTR32) CapC$DC$Pf$d
CapC.DC.Ang (struct) NV (struct) CapC$DC$Ang
CapC.DC.Ang.d d(VSTR32) NV (VSTR32) CapC$DC$Ang$d
CapC.DC.AirTemp (struct) NV (struct) CapC$DC$AirTemp
CapC.DC.AirTemp.d d(VSTR32) NV (VSTR32) CapC$DC$AirTemp$d
CapC.DC.SwDS (struct) NV (struct) CapC$DC$SwDS
CapC.DC.SwDS.d d(VSTR32) NV (VSTR32) CapC$DC$SwDS$d
CapC.DC.LocRemDS (struct) NV (struct) CapC$DC$LocRemDS
CapC.DC.LocRemDS.d d(VSTR32) NV (VSTR32) CapC$DC$LocRemDS$d
CapC.DC.AutoManDS (struct) NV (struct) CapC$DC$AutoManDS

IEEE-SA
CASM MMS
(DataType) (Type)
CapC.DC.AutoManDS.d d(VSTR32) NV (VSTR32) CapC$DC$AutoManDS$d
CapC.DC.CtlFailTimDS (struct) NV (struct) CapC$DC$CtlFailTimDS
CapC.DC.CtlFailTimDS.d d(VSTR32) NV (VSTR32) CapC$DC$CtlFailTimDS$d
CapC.DC.OVDS (struct) NV (struct) CapC$DC$OVDS
CapC.DC.OVDS.d d(VSTR32) NV (VSTR32) CapC$DC$OVDS$d
CapC.DC.Out (struct) NV (struct) CapC$DC$Out
CapC.DC.Out.d d(VSTR32) NV (VSTR32) CapC$DC$Out$d
CapC.DC.NeutAlm (struct) NV (struct) CapC$DC$NeutAlm
CapC.DC.NeutAlm.d d(VSTR32) NV (VSTR32) CapC$DC$NeutAlm$d
CapC.DC.DSTDS (struct) NV (struct) CapC$DC$DSTDS
CapC.DC.DSTDS.d d(VSTR32) NV (VSTR32) CapC$DC$DSTDS$d
CapC.DC.SensorSt (struct) NV (struct) CapC$DC$SensorSt
CapC.DC.SensorSt.d d(VSTR32) NV (VSTR32) CapC$DC$SensorSt$d
CapC.DC.DschBlkDS (struct) NV (struct) CapC$DC$DschBlkDS
CapC.DC.DschBlkDS.d d(VSTR32) NV (VSTR32) CapC$DC$DschBlkDS$d
CapC.DC.DoorDS (struct) NV (struct) CapC$DC$DoorDS
CapC.DC.DoorDS.d d(VSTR32) NV (VSTR32) CapC$DC$DoorDS$d
CapC.DC.PwrSupAlm (struct) NV (struct) CapC$DC$PwrSupAlm
CapC.DC.PwrSupAlm.d d(VSTR32) NV (VSTR32) CapC$DC$PwrSupAlm$d
CapC.DC.Vpu (struct) NV (struct) CapC$DC$Vpu
CapC.DC.Vpu.d d(VSTR32) NV (VSTR32) CapC$DC$Vpu$d
CapC.DC.Apu (struct) NV (struct) CapC$DC$Apu
CapC.DC.Apu.d d(VSTR32) NV (VSTR32) CapC$DC$Apu$d
CapC.DC.VarPu (struct) NV (struct) CapC$DC$VarPu
CapC.DC.VarPu.d d(VSTR32) NV (VSTR32) CapC$DC$VarPu$d
CapC.DC.NeutAPu (struct) NV (struct) CapC$DC$NeutAPu
CapC.DC.NeutAPu.d d(VSTR32) NV (VSTR32) CapC$DC$NeutAPu$d
CapC.DC.HiBadV (struct) NV (struct) CapC$DC$HiBadV
CapC.DC.HiBadV.d d(VSTR32) NV (VSTR32) CapC$DC$HiBadV$d
CapC.DC.LoBadV (struct) NV (struct) CapC$DC$LoBadV
CapC.DC.LoBadV.d d(VSTR32) NV (VSTR32) CapC$DC$LoBadV$d
CapC.DC.TimSched (struct) NV (struct) CapC$DC$TimSched
CapC.DC.TimSched.d d(VSTR32) NV (VSTR32) CapC$DC$TimSched$d
CapC.DC.StartTS (struct) NV (struct) CapC$DC$StartTS
CapC.DC.StartTS.d d(VSTR32) NV (VSTR32) CapC$DC$StartTS$d
CapC.DC.StopTS (struct) NV (struct) CapC$DC$StopTS
CapC.DC.StopTS.d d(VSTR32) NV (VSTR32) CapC$DC$StopTS$d
CapC.DC.StartDST (struct) NV (struct) CapC$DC$StartDST
CapC.DC.StartDST.d d(VSTR32) NV (VSTR32) CapC$DC$StartDST$d
CapC.DC.StopDST (struct) NV (struct) CapC$DC$StopDST
CapC.DC.StopDST.d d(VSTR32) NV (VSTR32) CapC$DC$StopDST$d

IEEE-SA
CASM MMS
(DataType) (Type)
CapC.DC.ODAutoMan (struct) NV (struct) CapC$DC$ODAutoMan
CapC.DC.ODAutoMan.d d(VSTR32) NV (VSTR32) CapC$DC$ODAutoMan$d
CapC.DC.ODSw (struct) NV (struct) CapC$DC$ODSw
CapC.DC.ODSw.d d(VSTR32) NV (VSTR32) CapC$DC$ODSw$d
CapC.CF FC (struct) NV (struct) CapC$CF
CapC.CF.ClockTOD (btime6) NV (btime6) CapC$CF$ClockTOD
CapC.CF.OperLogic SIG (bstr8) NV (BSTR8) CapC$CF$OperLogic
CapC.CF.DschTimDel (int16s) NV (INT16S) CapC$CF$DschTimDel
CapC.CF.V ACF(STRUCT) NV (struct) CapC$CF$V
CapC.CF.V.s s(FLOAT32) NV (float32) CapC$CF$V$s
CapC.CF.V.o o(FLOAT32) NV (float32) CapC$CF$V$o
CapC.CF.V.u u(ENUM16) NV (enum16) CapC$CF$V$u
CapC.CF.V.db db(INT16U) NV (INT16U) CapC$CF$V$db
CapC.CF.V.MxType MxType(ENUM8) NV (enum8) CapC$CF$V$MxType
CapC.CF.V.MxRef MxRef(ENUM8) NV (enum8) CapC$CF$V$MxRef
CapC.CF.V.SmpRate SmpRate(INT16U) NV (INT16U) CapC$CF$V$SmpRate
CapC.CF.V.NumSmp NumSmp(INT16U) NV (INT16U) CapC$CF$V$NumSmp
CapC.CF.V.pp pp(BOOL) NV (BOOL) CapC$CF$V$pp
CapC.CF.PhsPhsV ACF(struct) NV (struct) CapC$CF$PhsPhsV
CapC.CF.PhsPhsV.s s(FLOAT32) NV (float32) CapC$CF$PhsPhsV$s
CapC.CF.PhsPhsV.o o(FLOAT32) NV (float32) CapC$CF$PhsPhsV$o
CapC.CF.PhsPhsV.u u(ENUM16) NV (enum16) CapC$CF$PhsPhsV$u
CapC.CF.PhsPhsV.db db(INT16U) NV (INT16U) CapC$CF$PhsPhsV$db
CapC.CF.PhsPhsV.MxType MxType(ENUM8) NV (enum8) CapC$CF$PhsPhsV$MxType
CapC.CF.PhsPhsV.MxRef MxRef(ENUM8) NV (enum8) CapC$CF$PhsPhsV$MxRef
CapC.CF.PhsPhsV.SmpRate SmpRate(INT16U) NV (INT16U) CapC$CF$PhsPhsV$SmpRate
CapC.CF.PhsPhsV.NumSmp NumSmp(INT16U) NV (INT16U) CapC$CF$PhsPhsV$NumSmp
CapC.CF.PhsPhsV.pp pp(BOOL) NV (BOOL) CapC$CF$PhsPhsV$pp
CapC.CF.A ACF(struct) NV (struct) CapC$CF$A
CapC.CF.A.s s(FLOAT32) NV (float32) CapC$CF$A$s
CapC.CF.A.o o(FLOAT32) NV (float32) CapC$CF$A$o
CapC.CF.A.u u(ENUM16) NV (enum16) CapC$CF$A$u
CapC.CF.A.db db(INT16U) NV (INT16U) CapC$CF$A$db
CapC.CF.A.MxType MxType(ENUM8) NV (enum8) CapC$CF$A$MxType
CapC.CF.A.MxRef MxRef(ENUM8) NV (enum8) CapC$CF$A$MxRef
CapC.CF.A.SmpRate SmpRate(INT16U) NV (INT16U) CapC$CF$A$SmpRate
CapC.CF.A.NumSmp NumSmp(INT16U) NV (INT16U) CapC$CF$A$NumSmp
CapC.CF.A.pp pp(BOOL) NV (BOOL) CapC$CF$A$pp
CapC.CF.W ACF(struct) NV (struct) CapC$CF$W
CapC.CF.W.s s(FLOAT32) NV (float32) CapC$CF$W$s
CapC.CF.W.o o(FLOAT32) NV (float32) CapC$CF$W$o

IEEE-SA
CASM MMS
(DataType) (Type)
CapC.CF.W.u u(ENUM16) NV (enum16) CapC$CF$W$u
CapC.CF.W.db db(INT16U) NV (INT16U) CapC$CF$W$db
CapC.CF.W.MxType MxType(ENUM8) NV (enum8) CapC$CF$W$MxType
CapC.CF.W.MxRef MxRef(ENUM8) NV (enum8) CapC$CF$W$MxRef
CapC.CF.W.SmpRate SmpRate(INT16U) NV (INT16U) CapC$CF$W$SmpRate
CapC.CF.W.NumSmp NumSmp(INT16U) NV (INT16U) CapC$CF$W$NumSmp
CapC.CF.W.pp pp(BOOL) NV (BOOL) CapC$CF$W$pp
CapC.CF.Var ACF(struct) NV (struct) CapC$CF$Var
CapC.CF.Var.s s(FLOAT32) NV (float32) CapC$CF$Var$s
CapC.CF.Var.o o(FLOAT32) NV (float32) CapC$CF$Var$o
CapC.CF.Var.u u(ENUM16) NV (enum16) CapC$CF$Var$u
CapC.CF.Var.db db(INT16U) NV (INT16U) CapC$CF$Var$db
CapC.CF.Var.MxType MxType(ENUM8) NV (enum8) CapC$CF$Var$MxType
CapC.CF.Var.MxRef MxRef(ENUM8) NV (enum8) CapC$CF$Var$MxRef
CapC.CF.Var.SmpRate SmpRate(INT16U) NV (INT16U) CapC$CF$Var$SmpRate
CapC.CF.Var.NumSmp NumSmp(INT16U) NV (INT16U) CapC$CF$Var$NumSmp
CapC.CF.Var.pp pp(BOOL) NV (BOOL) CapC$CF$Var$pp
CapC.CF.VA ACF(struct) NV (struct) CapC$CF$VA
CapC.CF.VA.s s(FLOAT32) NV (float32) CapC$CF$VA$s
CapC.CF.VA.o o(FLOAT32) NV (float32) CapC$CF$VA$o
CapC.CF.VA.u u(ENUM16) NV (enum16) CapC$CF$VA$u
CapC.CF.VA.db db(INT16U) NV (INT16U) CapC$CF$VA$db
CapC.CF.VA.MxType MxType(ENUM8) NV (enum8) CapC$CF$VA.MxType
CapC.CF.VA.MxRef MxRef(ENUM8) NV (enum8) CapC$CF$VA$MxRef
CapC.CF.VA.SmpRate SmpRate(INT16U) NV (INT16U) CapC$CF$VA$SmpRate
CapC.CF.VA.NumSmp NumSmp(INT16U) NV (INT16U) CapC$CF$VA$NumSmp
CapC.CF.VA.pp pp(BOOL) NV (BOOL) CapC$CF$VA$pp
CapC.CF.Pf ACF(struct) NV (struct) CapC$CF$Pf
CapC.CF.Pf.s s(FLOAT32) NV (float32) CapC$CF$Pf$s
CapC.CF.Pf.o o(FLOAT32) NV (float32) CapC$CF$Pf$o
CapC.CF.Pf.u u(ENUM16) NV (enum16) CapC$CF$Pf$u
CapC.CF.Pf.db db(INT16U) NV (INT16U) CapC$CF$Pf$db
CapC.CF.Pf.MxType MxType(ENUM8) NV (enum8) CapC$CF$Pf$MxType
CapC.CF.Pf.MxRef MxRef(ENUM8) NV (enum8) CapC$CF$Pf$MxRef
CapC.CF.Pf.SmpRate SmpRate(INT16U) NV (INT16U) CapC$CF$Pf$SmpRate
CapC.CF.Pf.NumSmp NumSmp(INT16U) NV (INT16U) CapC$CF$Pf$NumSmp
CapC.CF.Pf.pp pp(BOOL) NV (BOOL) CapC$CF$Pf$pp
CapC.CF.Ang ACF(struct) NV (struct) CapC$CF$Ang
CapC.CF.Ang.s s(FLOAT32) NV (float32) CapC$CF$Ang$s
CapC.CF.Ang.o o(FLOAT32) NV (float32) CapC$CF$Ang$o
CapC.CF.Ang.u u(ENUM16) NV (enum16) CapC$CF$Ang$u

IEEE-SA
CASM MMS
(DataType) (Type)
CapC.CF.Ang.db db(INT16U) NV (INT16U) CapC$CF$Ang$db
CapC.CF.Ang.MxType MxType(ENUM8) NV (enum8) CapC$CF$Ang$MxType
CapC.CF.Ang.MxRef MxRef(ENUM8) NV (enum8) CapC$CF$Ang$MxRef
CapC.CF.Ang.SmpRate SmpRate(INT16U) NV (INT16U) CapC$CF$Ang$SmpRate
CapC.CF.Ang.NumSmp NumSmp(INT16U) NV (INT16U) CapC$CF$Ang$NumSmp
CapC.CF.Ang.pp pp(BOOL) NV (BOOL) CapC$CF$Ang$pp
CapC.CF.AirTemp ACF(struct) NV (struct) CapC$CF$AirTemp
CapC.CF.AirTemp.s s(FLOAT32) NV (float32) CapC$CF$AirTemp$s
CapC.CF.AirTemp.o o(FLOAT32) NV (float32) CapC$CF$AirTemp$o
CapC.CF.AirTemp.u u(ENUM16) NV (enum16) CapC$CF$AirTemp$u
CapC.CF.AirTemp.db db(INT16U) NV (INT16U) CapC$CF$AirTemp$db
CapC.CF.AirTemp.MxType MxType(ENUM8) NV (enum8) CapC$CF$AirTemp$MxType
CapC.CF.AirTemp.MxRef MxRef(ENUM8) NV (enum8) CapC$CF$AirTemp$MxRef
CapC.CF.AirTemp.SmpRate SmpRate(INT16U) NV (INT16U) CapC$CF$AirTemp$SmpRate
CapC.CF.AirTemp.NumSmp NumSmp(INT16U) NV (INT16U) CapC$CF$AirTemp$NumSmp
CapC.CF.AirTemp.pp pp(BOOL) NV (BOOL) CapC$CF$AirTemp$pp
CapC.CF.Vpu ACF(struct) NV (struct) CapC$CF$Vpu
CapC.CF.Vpu.s s(FLOAT32) NV (float32) CapC$CF$Vpu$s
CapC.CF.Vpu.o o(FLOAT32) NV (float32) CapC$CF$Vpu$o
CapC.CF.Vpu.u u(ENUM16) NV (enum16) CapC$CF$Vpu$u
CapC.CF.Vpu.db db(INT16U) NV (INT16U) CapC$CF$Vpu$db
CapC.CF.Vpu.MxType MxType(ENUM8) NV (enum8) CapC$CF$Vpu$MxType
CapC.CF.Vpu.MxRef MxRef(ENUM8) NV (enum8) CapC$CF$Vpu$MxRef
CapC.CF.Vpu.SmpRate SmpRate(INT16U) NV (INT16U) CapC$CF$Vpu$SmpRate
CapC.CF.Vpu.NumSmp NumSmp(INT16U) NV (INT16U) CapC$CF$Vpu$NumSmp
CapC.CF.Vpu.pp pp(BOOL) NV (BOOL) CapC$CF$Vpu$pp
CapC.CF.Apu ACF(struct) NV (struct) CapC$CF$Apu
CapC.CF.Apu.s s(FLOAT32) NV (float32) CapC$CF$Apu$s
CapC.CF.Apu.o o(FLOAT32) NV (float32) CapC$CF$Apu$o
CapC.CF.Apu.u u(ENUM16) NV (enum16) CapC$CF$Apu$u
CapC.CF.Apu.db db(INT16U) NV (INT16U) CapC$CF$Apu$db
CapC.CF.Apu.MxType MxType(ENUM8) NV (enum8) CapC$CF$Apu$MxType
CapC.CF.Apu.MxRef MxRef(ENUM8) NV (enum8) CapC$CF$Apu$MxRef
CapC.CF.Apu.SmpRate SmpRate(INT16U) NV (INT16U) CapC$CF$Apu$SmpRate
CapC.CF.Apu.NumSmp NumSmp(INT16U) NV (INT16U) CapC$CF$Apu$NumSmp
CapC.CF.Apu.pp pp(BOOL) NV (BOOL) CapC$CF$Apu$pp
CapC.CF.VarPu ACF(struct) NV (struct) CapC$CF$VarPu
CapC.CF.VarPu.s s(FLOAT32) NV (float32) CapC$CF$VarPu$s
CapC.CF.VarPu.o o(FLOAT32) NV (float32) CapC$CF$VarPu$o
CapC.CF.VarPu.u u(ENUM16) NV (enum16) CapC$CF$VarPu$u
CapC.CF.VarPu.db db(INT16U) NV (INT16U) CapC$CF$VarPu$db

IEEE-SA
CASM MMS
(DataType) (Type)
CapC.CF.VarPu.MxType MxType(ENUM8) NV (enum8) CapC$CF$VarPu$MxType
CapC.CF.VarPu.MxRef MxRef(ENUM8) NV (enum8) CapC$CF$VarPu$MxRef
CapC.CF.VarPu.SmpRate SmpRate(INT16U) NV (INT16U) CapC$CF$VarPu$SmpRate
CapC.CF.VarPu.NumSmp NumSmp(INT16U) NV (INT16U) CapC$CF$VarPu$NumSmp
CapC.CF.VarPu.pp pp(BOOL) NV (BOOL) CapC$CF$VarPu$pp
CapC.CF.NeutAPu ACF(struct) NV (struct) CapC$CF$NeutAPu
CapC.CF.NeutAPu.s s(FLOAT32) NV (float32) CapC$CF$NeutAPu$s
CapC.CF.NeutAPu.o o(FLOAT32) NV (float32) CapC$CF$NeutAPu$o
CapC.CF.NeutAPu.u u(ENUM16) NV (enum16) CapC$CF$NeutAPu$u
CapC.CF.NeutAPu.db db(INT16U) NV (INT16U) CapC$CF$NeutAPu$db
CapC.CF.NeutAPu.MxType MxType(ENUM8) NV (enum8) CapC$CF$NeutAPu$MxType
CapC.CF.NeutAPu.MxRef MxRef(ENUM8) NV (enum8) CapC$CF$NeutAPu$MxRef
CapC.CF.NeutAPu.SmpRate SmpRate(INT16U) NV (INT16U) CapC$CF$NeutAPu$SmpRate
CapC.CF.NeutAPu.NumSmp NumSmp(INT16U) NV (INT16U) CapC$CF$NeutAPu$NumSmp
CapC.CF.NeutAPu.pp pp(BOOL) NV (BOOL) CapC$CF$NeutAPu$pp
CapC.CF.HiBadV ACF(struct) NV (struct) CapC$CF$HiBadV
CapC.CF.HiBadV.s s(FLOAT32) NV (float32) CapC$CF$HiBadV$s
CapC.CF.HiBadV.o o(FLOAT32) NV (float32) CapC$CF$HiBadV$o
CapC.CF.HiBadV.u u(ENUM16) NV (enum16) CapC$CF$HiBadV$u
CapC.CF.HiBadV.db db(INT16U) NV (INT16U) CapC$CF$HiBadV$db
CapC.CF.HiBadV.MxType MxType(ENUM8) NV (enum8) CapC$CF$HiBadV$MxType
CapC.CF.HiBadV.MxRef MxRef(ENUM8) NV (enum8) CapC$CF$HiBadV$MxRef
CapC.CF.HiBadV.SmpRate SmpRate(INT16U) NV (INT16U) CapC$CF$HiBadV$SmpRate
CapC.CF.HiBadV.NumSmp NumSmp(INT16U) NV (INT16U) CapC$CF$HiBadV$NumSmp
CapC.CF.HiBadV.pp pp(BOOL) NV (BOOL) CapC$CF$HiBadV$pp
CapC.CF.LoBadV ACF(struct) NV (struct) CapC$CF$LoBadV
CapC.CF.LoBadV.s s(FLOAT32) NV (float32) CapC$CF$LoBadV$s
CapC.CF.LoBadV.o o(FLOAT32) NV (float32) CapC$CF$LoBadV$o
CapC.CF.LoBadV.u u(ENUM16) NV (enum16) CapC$CF$LoBadV$u
CapC.CF.LoBadV.db db(INT16U) NV (INT16U) CapC$CF$LoBadV$db
CapC.CF.LoBadV.MxType MxType(ENUM8) NV (enum8) CapC$CF$LoBadV$MxType
CapC.CF.LoBadV.MxRef MxRef(ENUM8) NV (enum8) CapC$CF$LoBadV$MxRef
CapC.CF.LoBadV.SmpRate SmpRate(INT16U) NV (INT16U) CapC$CF$LoBadV$SmpRate
CapC.CF.LoBadV.NumSmp NumSmp(INT16U) NV (INT16U) CapC$CF$LoBadV$NumSmp
CapC.CF.LoBadV.pp pp(BOOL) NV (BOOL) CapC$CF$LoBadV$pp
CapC.MX fc (struct) NV (struct) CapC$MX
CapC.MX.V WYE(STRUCT) NV (struct) CapC$MX$V
CapC.MX.V.PhsAi i (INT16S) NV (INT16S) CapC$MX$V$PhsAi
CapC.MX.V.PhsAf f (FLOAT32) NV (FLOAT32) CapC$MX$V$PhsAf
CapC.MX.V.PhsBi i (INT16S) NV (INT16S) CapC$MX$V$PhsBi
CapC.MX.V.PhsBf f (FLOAT32) NV (FLOAT32) CapC$MX$V$PhsBf

IEEE-SA
CASM MMS
(DataType) (Type)
CapC.MX.V.PhsCi i (INT16S) NV (INT16S) CapC$MX$V$PhsCi
CapC.MX.V.PhsCf f (FLOAT32) NV (FLOAT32) CapC$MX$V$PhsCf
CapC.MX.V.q q (BSTR16) NV (BSTR16) CapC$MX$V$q
CapC.MX.V.t t (BTIME6) NV (btime6) CapC$MX$V$t
CapC.MX.PhsPhsV DELTA(STRUCT) NV (struct) CapC$MX$PhsPhsV
CapC.MX.PhsPhsV.PhsABi i (INT16S) NV (INT16S) CapC$MX$PhsPhsV$PhsABi
CapC.MX.PhsPhsV.PhsABf f (FLOAT32) NV (FLOAT32) CapC$MX$PhsPhsV$PhsABf
CapC.MX.PhsPhsV.PhsBCi i (INT16S) NV (INT16S) CapC$MX$PhsPhsV$PhsBCi
CapC.MX.PhsPhsV.PhsBCf f (FLOAT32) NV (FLOAT32) CapC$MX$PhsPhsV$PhsBCf
CapC.MX.PhsPhsV.PhsCAi i (INT16S) NV (INT16S) CapC$MX$PhsPhsV$PhsCAi
CapC.MX.PhsPhsV.PhsCAf f (FLOAT32) NV (FLOAT32) CapC$MX$PhsPhsV$PhsCAf
CapC.MX.PhsPhsV.q q (BSTR16) NV (BSTR16) CapC$MX$PhsPhsV$q
CapC.MX.PhsPhsV.t t (BTIME6) NV (btime6) CapC$MX$PhsPhsV$t
CapC.MX.A WYE(STRUCT) NV (struct) CapC$MX$A
CapC.MX.A.PhsAi i (INT16S) NV (INT16S) CapC$MX$A$PhsAi
CapC.MX.A.PhsAf f (FLOAT32) NV (FLOAT32) CapC$MX$A$PhsAf
CapC.MX.A.PhsBi i (INT16S) NV (INT16S) CapC$MX$A$PhsBi
CapC.MX.A.PhsBf f (FLOAT32) NV (FLOAT32) CapC$MX$A$PhsBf
CapC.MX.A.PhsCi i (INT16S) NV (INT16S) CapC$MX$A$PhsCi
CapC.MX.A.PhsCf f (FLOAT32) NV (FLOAT32) CapC$MX$A$PhsCf
CapC.MX.A.q q (BSTR16) NV (BSTR16) CapC$MX$A$q
CapC.MX.A.t t (BTIME6) NV (btime6) CapC$MX$A$t
CapC.MX.W WYE(STRUCT) NV (struct) CapC$MX$W
CapC.MX.W.PhsAi i (INT16S) NV (INT16S) CapC$MX$W$PhsAi
CapC.MX.W.PhsAf f (FLOAT32) NV (FLOAT32) CapC$MX$W$PhsAf
CapC.MX.W.PhsBi i (INT16S) NV (INT16S) CapC$MX$W$PhsBi
CapC.MX.W.PhsBf f (FLOAT32) NV (FLOAT32) CapC$MX$W$PhsBf
CapC.MX.W.PhsCi i (INT16S) NV (INT16S) CapC$MX$W$PhsCi
CapC.MX.W.PhsCf f (FLOAT32) NV (FLOAT32) CapC$MX$W$PhsCf
CapC.MX.W.q q (BSTR16) NV (BSTR16) CapC$MX$W$q
CapC.MX.W.t t (BTIME6) NV (btime6) CapC$MX$W$t
CapC.MX.Var WYE(STRUCT) NV (struct) CapC$MX$Var
CapC.MX.Var.PhsAi i (INT16S) NV (INT16S) CapC$MX$Var$PhsAi
CapC.MX.Var.PhsAf f (FLOAT32) NV (FLOAT32) CapC$MX$Var$PhsAf
CapC.MX.Var.PhsBi i (INT16S) NV (INT16S) CapC$MX$Var$PhsBi
CapC.MX.Var.PhsBf f (FLOAT32) NV (FLOAT32) CapC$MX$Var$PhsBf
CapC.MX.Var.PhsCi i (INT16S) NV (INT16S) CapC$MX$Var$PhsCi
CapC.MX.Var.PhsCf f (FLOAT32) NV (FLOAT32) CapC$MX$Var$PhsCf
CapC.MX.Var.q q (BSTR16) NV (BSTR16) CapC$MX$Var$q
CapC.MX.Var.t t (BTIME6) NV (btime6) CapC$MX$Var$t
CapC.MX.VA WYE(STRUCT) NV (struct) CapC$MX$VA

IEEE-SA
CASM MMS
(DataType) (Type)
CapC.MX.VA.PhsAi i (INT16S) NV (INT16S) CapC$MX$VA$PhsAi
CapC.MX.VA.PhsAf f (FLOAT32) NV (FLOAT32) CapC$MX$VA$PhsAf
CapC.MX.VA.PhsBi i (INT16S) NV (INT16S) CapC$MX$VA$PhsBi
CapC.MX.VA.PhsBf f (FLOAT32) NV (FLOAT32) CapC$MX$VA$PhsBf
CapC.MX.VA.PhsCi i (INT16S) NV (INT16S) CapC$MX$VA$PhsCi
CapC.MX.VA.PhsCf f (FLOAT32) NV (FLOAT32) CapC$MX$VA$PhsCf
CapC.MX.VA.q q (BSTR16) NV (BSTR16) CapC$MX$VA$q
CapC.MX.VA.t t (BTIME6) NV (btime6) CapC$MX$VA$t
CapC.MX.Pf WYE(STRUCT) NV (STRUCT) CapC$MX$Pf
CapC.MX.Pf.PhsAi i (INT16S) NV (INT16S) CapC$MX$Pf$PhsAi
CapC.MX.Pf.PhsAf f (FLOAT32) NV (FLOAT32) CapC$MX$Pf$PhsAf
CapC.MX.Pf.PhsBi i (INT16S) NV (INT16S) CapC$MX$Pf$PhsBi
CapC.MX.Pf.PhsBf f (FLOAT32) NV (FLOAT32) CapC$MX$Pf$PhsBf
CapC.MX.Pf.PhsCi i (INT16S) NV (INT16S) CapC$MX$Pf$PhsCi
CapC.MX.Pf.PhsCf f (FLOAT32) NV (FLOAT32) CapC$MX$Pf$PhsCf
CapC.MX.Pf.q q (BSTR16) NV (BSTR16) CapC$MX$Pf$q
CapC.MX.Pf.t t (BTIME6) NV (btime6) CapC$MX$Pf$t
CapC.MX.Ang WYE(STRUCT) NV (STRUCT) CapC$MX$Ang
CapC.MX.Ang.PhsAi i (INT16S) NV (INT16S) CapC$MX$Ang$PhsAi
CapC.MX.Ang.PhsAf f (FLOAT32) NV (FLOAT32) CapC$MX$Ang$PhsAf
CapC.MX.Ang.PhsBi i (INT16S) NV (INT16S) CapC$MX$Ang$PhsBi
CapC.MX.Ang.PhsBf f (FLOAT32) NV (FLOAT32) CapC$MX$Ang$PhsBf
CapC.MX.Ang.PhsCi i (INT16S) NV (INT16S) CapC$MX$Ang$PhsCi
CapC.MX.Ang.PhsCf f (FLOAT32) NV (FLOAT32) CapC$MX$Ang$PhsCf
CapC.MX.Ang.q q (BSTR16) NV (BSTR16) CapC$MX$Ang$q
CapC.MX.Ang.t t (BTIME6) NV (btime6) CapC$MX$Ang$t
CapC.MX.AirTemp AI (STRUCT) NV (struct) CapC$MX$AirTemp
CapC.MX.AirTemp.i i (INT16S) NV (INT16S) CapC$MX$AirTemp$i
CapC.MX.AirTemp.f f (FLOAT32) NV (FLOAT32) CapC$MX$AirTemp$f
CapC.MX.AirTemp.q q (BSTR16) NV (BSTR16) CapC$MX$AirTemp$q
CapC.MX.AirTemp.t t (BTIME6) NV (btime6) CapC$MX$AirTemp$t
CapC.ST FC (STRUCT) NV (struct) CapC$ST
CapC.ST.SwDS SIT(STRUCT) NV (struct) CapC$ST$SwDS
CapC.ST.SwDS.b2 b2(BSTR2) NV (BSTR2) CapC$ST$SwDS$b2
CapC.ST.SwDS.q q (BSTR16) NV (BSTR16) CapC$ST$SwDS$q
CapC.ST.SwDS.t t (BTIME6) NV (btime6) CapC$ST$SwDS$t
CapC.ST.LocRemDS SIT(STRUCT) NV (struct) CapC$ST$LocRemDS
CapC.ST.LocRemDS.b2 b2(BSTR2) NV (BSTR2) CapC$ST$LocRemDS$b2
CapC.ST.LocRemDS.q q (BSTR16) NV (BSTR16) CapC$ST$LocRemDS$q
CapC.ST.LocRemDS.t t (BTIME6) NV (btime6) CapC$ST$LocRemDS$t
CapC.ST.AutoManDS SIT(STRUCT) NV (struct) CapC$ST$AutoManDS

IEEE-SA
CASM MMS
(DataType) (Type)
CapC.ST.AutoManDS.b2 b2(BSTR2) NV (BSTR2) CapC$ST$AutoManDS$b2
CapC.ST.AutoManDS.q q (BSTR16) NV (BSTR16) CapC$ST$AutoManDS$q
CapC.ST.AutoManDS.t t (BTIME6) NV (btime6) CapC$ST$AutoManDS$t
CapC.ST.CtlFailTimDS SIT(STRUCT) NV (struct) CapC$ST$CtlFailTimDS
CapC.ST.CtlFailTimDS.b2 b2(BSTR2) NV (BSTR2) CapC$ST$CtlFailTimDS$b2
CapC.ST.CtlFailTimDS.q q (BSTR16) NV (BSTR16) CapC$ST$CtlFailTimDS$q
CapC.ST.CtlFailTimDS.t t (BTIME6) NV (btime6) CapC$ST$CtlFailTimDS$t
CapC.ST.OVDS SI(STRUCT) NV (struct) CapC$ST$OVDS
CapC.ST.OVDS.b b(BOOL) NV (BOOL) CapC$ST$OVDS$b
CapC.ST.OVDS.q q (BSTR16) NV (BSTR16) CapC$ST$OVDS$q
CapC.ST.OVDS.t t (BTIME6) NV (btime6) CapC$ST$OVDS$t
CapC.ST.Out (BOOL) NV (BOOL) CapC$ST$Out
CapC.ST.NeutAlm (BOOL) NV (BOOL) CapC$ST$NeutAlm
CapC.ST.DSTDS SIT(STRUCT) NV (struct) CapC$ST$DSTDS
CapC.ST.DSTDS.b2 b2(BSTR2) NV (BSTR2) CapC$ST$DSTDS$b2
CapC.ST.DSTDS.q q (BSTR16) NV (BSTR16) CapC$ST$DSTDS$q
CapC.ST.DSTDS.t t (BTIME6) NV (btime6) CapC$ST$DSTDS$t
CapC.ST.SensorSt SIG(STRUCT) NV (struct) CapC$ST$SensorSt
CapC.ST.SensorSt.b16 b16(BSTR16) NV (BSTR16) CapC$ST$SensorSt$b16
CapC.ST.SensorSt.q q (BSTR16) NV (BSTR16) CapC$ST$SensorSt$q
CapC.ST.SensorSt.t t (BTIME6) NV (btime6) CapC$ST$SensorSt$t
CapC.ST.DschBlkDS SI(STRUCT) NV (struct) CapC$ST$DschBlkDS
CapC.ST.DschBlkDS.b b(BOOL) NV (BOOL) CapC$ST$DschBlkDS$b
CapC.ST.DschBlkDS.q q (BSTR16) NV (BSTR16) CapC$ST$DschBlkDS$q
CapC.ST.DschBlkDS.t t (BTIME6) NV (btime6) CapC$ST$DschBlkDS$t
CapC.ST.DoorDS SIT(STRUCT) NV (struct) CapC$ST$DoorDS
CapC.ST.DoorDS.b2 b2(BSTR2) NV (BSTR2) CapC$ST$DoorDS$b2
CapC.ST.DoorDS.q q (BSTR16) NV (BSTR16) CapC$ST$DoorDS$q
CapC.ST.DoorDS.t t (BTIME6) NV (btime6) CapC$ST$DoorDS$t
CapC.ST.PwrSupAlm SIG(STRUCT) NV (struct) CapC$ST$PwrSupAlm
CapC.ST.PwrSupAlm.b16 b16(BSTR16) NV (BSTR16) CapC$ST$PwrSupAlm$b16
CapC.ST.PwrSupAlm.q q (BSTR16) NV (BSTR16) CapC$ST$PwrSupAlm$q
CapC.ST.PwrSupAlm.t t (BTIME6) NV (btime6) CapC$ST$PwrSupAlm$t
CapC.SP FC (struct) NV (struct) CapC$SP

CapC.SP.Vpu CBPUG(struct) NV (struct) CapC$SP$Vpu
CapC.SP.Vpu.i i (INT16S) NV (INT16S) CapC$SP$Vpu$i
CapC.SP.Vpu.f f (FLOAT32) NV (FLOAT32) CapC$SP$Vpu$f
CapC.SP.Vpu.SBO SBO (IDENT) NV (VSTR64) CapC$SP$Vpu$SBO
CapC.SP.Apu CBPUG(struct) NV (struct) CapC$SP$Apu
CapC.SP.Apu.i i (INT16S) NV (INT16S) CapC$SP$Apu$i

IEEE-SA
CASM MMS
(DataType) (Type)
CapC.SP.Apu.f f (FLOAT32) NV (FLOAT32) CapC$SP$Apu$f
CapC.SP.Apu.SBO SBO (IDENT) NV (VSTR64) CapC$SP$Apu$SBO
CapC.SP.VarPu CBPUG(struct) NV (struct) CapC$SP$VarPu
CapC.SP.VarPu.i i (INT16S) NV (INT16S) CapC$SP$VarPu$i
CapC.SP.VarPu.f f (FLOAT32) NV (FLOAT32) CapC$SP$VarPu$f
CapC.SP.VarPu.SBO SBO (IDENT) NV (VSTR64) CapC$SP$VarPu$SBO
CapC.SP.NeutAPu CBPUG(struct) NV (struct) CapC$SP$NeutAPu
CapC.SP.NeutAPu.i i (INT16S) NV (INT16S) CapC$SP$NeutAPu$i
CapC.SP.NeutAPu.f f (FLOAT32) NV (FLOAT32) CapC$SP$NeutAPu$f
CapC.SP.NeutAPu.SBO SBO (IDENT) NV (VSTR64) CapC$SP$NeutAPu$SBO
CapC.SP.HiBadV AO(struct) NV (struct) CapC$SP$HiBadV
CapC.SP.HiBadV.i i (INT16S) NV (INT16S) CapC$SP$HiBadV$i
CapC.SP.HiBadV.f f (FLOAT32) NV (FLOAT32) CapC$SP$HiBadV$f
CapC.SP.HiBadV.SBO SBO (IDENT) NV (VSTR64) CapC$SP$HiBadV$SBO
CapC.SP.LoBadV AO(struct) NV (struct) CapC$SP$LoBadV
CapC.SP.LoBadV.i i (INT16S) NV (INT16S) CapC$SP$LoBadV$i
CapC.SP.LoBadV.f f (FLOAT32) NV (FLOAT32) CapC$SP$LoBadV$f
CapC.SP.LoBadV.SBO SBO (IDENT) NV (VSTR64) CapC$SP$LoBadV$SBO
CapC.SP.TimSched CBTim(STRUCT) NV (struct) CapC$SP$TimSched
CapC.SP.StartTS (btime6) NV (btime6) CapC$SP$StartTS
CapC.SP.StopTS (btime6) NV (btime6) CapC$SP$StopTS
CapC.SP.StartDST (btime6) NV (btime6) CapC$SP$StartDST
CapC.SP.StopDST (btime6) NV (btime6) CapC$SP$StopDST
CapC.CO FC (struct) NV (struct) CapC$CO
CapC.CO.ODAutoMan DCO (struct) NV (struct) CapC$CO$ODAutoMan
CapC.CO.ODAutoMan.OperDev OperDev(BSTR2) NV (BSTR2) CapC$CO$ODAutoMan$OperDev
CapC.CO.ODAutoMan.Choose Choose(STRUCT) NV (struct) CapC$CO$ODAutoMan$Choose
CapC$CO$ODAutoMan$Choose.
CapC.CO.ODAutoMan.Choose.SBO SBO (IDENT) NV (VSTR64)AA
SBO
CapC.CO.ODAutoMan.Choose.Select- CapC$CO$ODAutoMan$Choose.
SelectState (ENUM8) NV (enum8) aa
State SelectState
CapC.CO.ODAutoMan.Choose. CapC$CO$ODAutoMan$Choose.
SelTimOut (INT8U) NV (int8u) aa
SelTimOut SelTimOut
CapC.CO.ODAutoMan.Choose.Select- CapC$CO$ODAutoMan$Choose.
SelectClass(ENUM8) NV (enum8) aa
Class SelectClass
CapC.CO.ODSw DCO (struct) NV (struct) CapC$CO$ODSw
CapC.CO.ODSw.OperDev OperDev(BSTR2) NV (BSTR2) CapC$CO$ODSw$OperDev
CapC.CO.ODSw.Choose.SBO SBO (IDENT) NV (VSTR64) AA CapC$CO$ODSw$Choose.SBO
CapC$CO$ODSw$Choose.
CapC.CO.ODSw.Choose.SelectState SelectState (ENUM8) NV (enum8) aa
SelectState
CapC.CO.ODSw.Choose. CapC$CO$ODSw$Choose.
SelTimOut (INT8U) NV (int8u) aa
SelTimOut SelTimOut

IEEE-SA
CASM MMS
(DataType) (Type)
CapC$CO$ODSw$Choose.
CapC.CO.ODSw.Choose.SelectClass SelectClass(ENUM8) NV (enum8) aa
SelectClass
CapC.CO.ODSw.Choose Choose(STRUCT) NV (struct) CapC$CO$ODSw$Choose
CapC.RP FC (struct) NV (struct) CapC$RP
CapC.RP.brcbMX BasRCB (STRUCT) NV (struct) CapC$RP$brcbMX
CapC.RP.brcbMX.RptID RptID(VSTR32) NV (VSTR32) CapC$RP$brcbMX$RptID
CapC.RP.brcbMX.RptEna RptEna(BOOL) NV (BOOL) CapC$RP$brcbMX$RptEna
CapC.RP.brcbMX.DataSet DataSet(VSTR16) NV (VSTR16) CapC$RP$brcbMX$DataSet
CapC.RP.brcbMX.OptFlds OptFlds(BSTR8) NV (BSTR8) CapC$RP$brcbMX$OptFlds
CapC.RP.brcbMX.BufTim BufTim(INT32U) NV (INT32U) CapC$RP$brcbMX$BufTim
CapC.RP.brcbMX.Trgs Trgs(INT16U) NV (INT16U) CapC$RP$brcbMX$Trgs
CapC.RP.brcbMX.SeqNum SeqNum(INT8U) NV (INT8U) CapC$RP$brcbMX$SeqNum
CapC.RP.brcbMX.TrgOps TrgOps(BSTR8) NV (BSTR8) CapC$RP$brcbMX$TrgOps
CapC.RP.brcbMX.RBEPd RBEPd(INT32U) NV (INT32U) CapC$RP$brcbMX$RBEPd
CapC.RP.brcbMX.IntgPd IntgPd(INT32U) NV (INT32U) CapC$RP$brcbMX$IntgPd
CapC.RP.brcbST BasRCB (STRUCT) NV (struct) CapC$RP$brcbST
CapC.RP.brcbST.RptID RptID(VSTR32) NV (VSTR32) CapC$RP$brcbST$RptID
CapC.RP.brcbST.RptEna RptEna(BOOL) NV (BOOL) CapC$RP$brcbST$RptEna
CapC.RP.brcbST.DataSet DataSet(VSTR16) NV (VSTR16) CapC$RP$brcbST$DataSet
CapC.RP.brcbST.OptFlds OptFlds(BSTR8) NV (BSTR8) CapC$RP$brcbST$OptFlds
CapC.RP.brcbST.BufTim BufTim(INT32U) NV (INT32U) CapC$RP$brcbST$BufTim
CapC.RP.brcbST.Trgs Trgs(INT16U) NV (INT16U) CapC$RP$brcbST$Trgs
CapC.RP.brcbST.SeqNum SeqNum(INT8U) NV (INT8U) CapC$RP$brcbST$SeqNum
CapC.RP.brcbST.TrgOps TrgOps(BSTR8) NV (BSTR8) CapC$RP$brcbST$TrgOps
CapC.RP.brcbST.RBEPd RBEPd(INT32U) NV (INT32U) CapC$RP$brcbST$RBEPd
CapC.RP.brcbST.IntgPd IntgPd(INT32U) NV (INT32U) CapC$RP$brcbST$IntgPd
CapC.AS FC (struct) NV (struct) CapC$AS
<<< to be determined>>> <<< to be determined>>>
CapC.MX DS NVL CapC$MX
CapC.ST DS NVL CapC$ST
CapC.dbEvents DS NVL CapC$dbEvents
CapC.STEvents DS NVL CapC$STEvents

IEEE-SA
Appendix B
Glossary/Acronyms
access: Specific interaction between a subject and an object that is intended to result in the flow of informa-
tion from one to the other.
access control: Means of restricting access to objects based on sensitivity (as represented by a label) of the
information contained in the object and formal authorization of subjects to access information of such sensi-
tivity.
accumulator: An integer value that counts the number of pulses or transitions of a binary input.
adaptive relaying: Protection system in which lower-level setpoints, relay logic, and relay action setpoints
are adjusted based on data either locally acquired, or provided by the neighboring device on the same level
locally or remotely, or sent down from a higher level.
addressing: Means to identify the source and sink (recipients) of all information transfers.
adjacent substation protection: Protection of power system equipment at one substation based on data
measured at others. Examples are line differential protection and teleprotection schemes.
agent: Servers that are designed to work with compatible client stubs known as user agents that share the
same server protocol. Agents are responsible for picking up and delivering messages between senders and
receivers.
alarm processing: Alarm analysis procedures to improve presentation of alarm data. It ranges from updating
alarm lists and producing group alarms up to more intelligent evaluations.
attribute: Represents a property or facility of an object (something that an object knows). It reflects both the
problem domain and the systems responsibilities as some data (state information) for which each object in a
class has its own value.
automatic reclosing: Automated closing of breakers after the trip by a relay fulfilling some local and/or
remote boundary conditions like synchrocheck reclose if applicable.
automatic switching sequences: Automatic sequential operation of groups of power system devices to
reduce operator workload and/or switching time and to avoid unsuccessful or unnecessary switching
attempts.
availability of data: State in which data are where the user needs them, when the user needs them, and how
the user needs them.
BFI: breaker failure initiate.
breaker : Device that connects and disconnects energized power circuits, with fault interrupting capability
under normal operational conditions (nominal values for current and voltage) and that is capable of inter-
rupting short circuits (synonymous with circuit breaker).
breaker (health) monitoring: Automated procedure to measure breaker operating times and accumulated
interrupting duty for maintenance scheduling or maintenance on request.
breaker failure protection: Backup protection scheme to trip all connected breakers if a breaker fails to trip
on a detected fault.

IEEE-SA
broadcast: Simultaneous transmission of data to all destinations on a network.
busbar fault isolation: Minimizing propagation of bus and feeder faults. Subset of the general term fault
isolation (transformer fault, etc.)
busbar protection: Scheme to detect busbar faults and trip all breakers attached to the faulted busbar.
busbar restoration: Formal procedures for service restoration after busbar trips, very often according to
fixed or load dependent priorities.
busbar voltage control: A) Automatics to maintain scheduled busbar voltage by any means (tap change,
VAr control, etc.) B) Network analysis to determine optimal settings of power system devices to maintain
bus voltage.
calibrate function: Process of adjusting internal parameters of a measurement unit to reduce errors in its
measured values.
capacitor bank: Group of capacitors used to adjust power circuit impedance.
circuit breaker: Device that connects and disconnects energized power circuits under normal operational
conditions (nominal values for current and voltage) and is capable of interrupting short circuits. Synonym:
breaker.
client: An IED object that requests information from another (i.e., from the server).
client/server architecture: An application architecture where one end system (the client) requests another
end system (the server) to perform operations and to give back results.
client/server concept: Communication management scheme in which multiple objects [i.e., the client(s)]
can request specified information from one or more other objects [i.e., from the server(s)]. Only clients may
issue unsolicited data; usually data flows primarily from the server to the clients.
client/server operation: Complete transaction consisting of a request followed by an information delivery

of requested information.
cold-load pickup: Automated procedure to change feeder relay settings to pick up load after an extended
outage. See also: adaptive relaying.
cold-load pickup control: Detection of the possibility of cold-load pickup (according to the cold-load
pickup time delay) before closing the feeder. Breaker refers to the need to either inhibit the instantaneous
setting of the OvercurrentProtection, or to raise the Overcurrent settings for a certain period of time when the
circuit is energized. By doing so, the protection settings can take into account transient current increases on
circuit energization, and the normal fault settings can be adjusted closer to the load profile.
communication interface: Serial interface of a device that allows exchange of information (physical and
logical) among devices of the same or different functional levels in a hierarchical system. An interface spec-
ifies the connection of a communication link, with regard to the mechanical connection as well as to the sig-
nals physical and functional characteristics. A well known example of an interface is CCITT V.24/V.28
whose US counterpart is EIA RS-232C.
configuration data exchange: A) Power system topology exchanges with other, usually neighbor, utilities.
B) Exchange of any kind of configurations from power system topology to device setups (parameters,
terminals).

IEEE-SA
critical: Three levels of data (delivery) criticality are required:
High, where delivery is essential to operation of the power system (e.g., delivery of a SCADA control
command). Examples are settings, commands switchgear states or positions, blocking, releases, trips,
synchrocheck detection, and total energy.
Medium, where later repetition by application of a failed data transfer is acceptable (e.g., delivery of a
stored data file). Examples are measured values (measurands) and disturbance recorder data.
Noncritical, where the recipient can tolerate occasional transfer failures (e.g., delivery of periodically
updated data to a data monitoring or averaging process). Examples are repeated continuously polled
data and display values.
See also: integrity.
CSOM: client-server object model.
CT: current transformer.
data: Information with specific physical representation.
data acquisition unit (DAU): General purpose data collector, often used for sensors.
data confidentiality: Security service that provides for the protection of data from unauthorized disclosure.
data integrity: Security service used to determine if data has been altered or destroyed in transit.
DataObject: An abstract element of a real device that is capable of providing (when read) or accepting
(when written) or both, a typed data value. A DataObject may represent a single data element (i.e., one mea-
surement point) or a data structure (i.e., a complex set of data elements). The mapping of a DataObject to a
real, physical entity in the device is defined by the model of the device being represented, and is outside the
scope of this document.
data transparency: Data transmission in which there are no restrictions on the bit patterns that user data
may have.
DataSet: An ordered list of references to DataObjects associated with a specific DataSet name. A DataSet is
a means of grouping together data that is frequently accessed as a group.
deadband: The amount by which an analog input must change from the last reported value to be spontane-
ously reported.
definite time OvercurrentProtection: Corresponds to the definition of IEEE Device Number 62. If there is
no intentional time delay, then the Overcurrent ProtectiveDevice corresponds to the definition of the IEEE
Instantaneous Overcurrent Device Number 50 and 50N.
denial of service: Accidental or intentional actions by a communication network node that disable normal
operation of any part of the network and can result in denial of (communication) service to other network
users.
device: Physical entity connected to the communication network composed of at least one communication
element (the network element) that may have a control element and/or a monitoring element (transducer,
actuator, etc.)

IEEE-SA
DeviceIdentity (DI): Contains the nameplate information of a device such as make, model, and serial
number.
digital fault recorder (DFR): Device that samples and stores analog and related binary sensor data during
power system transients for later replay and analysis.
directional overcurrent: Relaying of this is necessary for the protection of multiple-source feeders, when it
is essential to limit the tripping of faults in only one direction. Fault directional control is possible for faults
on each phase, as well as the neutral. Directional current sensing and control requires a voltage, current, or a
dual polarizing signal for selective detection of the direction or phase of the fault current. If directional over-
current control is enabled, the overcurrent protection is inhibited for faults in the nontrip direction.
directory: Collection of open systems that cooperate to hold a logical database of information about a set of
objects in the real world (e.g., OSI users and network resources). The directory also provides services for
users (people and application processes) to access the information contained in the repository.
EDC: embedded device controller.
EPRI: Electric Power Research Institute.
equipment clock synchronization: Automated procedure to maintain consistent time data throughout the
substation or power system, (e.g., for time tagging or synchronized sampling).
equipment diagnostics: Procedures that monitor the on-line operation of power system devices, perform
off-line tests, and provide early warning of potential failures. See also: breaker (health) monitoring. The goal
is optimized maintenance scheduling (maintenance on request).
event report: The report generated in the server by the action of a transfer set to be sent to the client.
fault identification and location: This is logic that determines the type of fault (e.g., phase-to-phase, etc.)
the distance to the fault, and the impedance of the fault.
fault isolating: Minimizing the impact of a fault on a power network device (transformer, busbar, switch-
gear, etc.).
fault recording: Procedures for collection, storage, and analysis of power system fault data.
feeder fault isolation: Automated procedure to operate feeder sectionalizing switches (isolators) to bypass a
faulted feeder section.
feeder fault location estimation: Procedure to locate feeder faults to minimize service restoration time.
feeder monitoring: Display of feeder breaker and connectivity status.
feeder switching: Automated procedure to manage feeder connectivity changes. See also: automatic switch-
ing sequences.
freeze: To copy the current value of an accumulator to another memory location.
functional block: An autonomous function, such as auto-reclosing, operational units, breaker failure protec-
tion, disturbance recording, etc., that might be implemented in separate hardware.
gateway: Processor providing communication protocol conversion services to permit communications

between dissimilar data systems.

IEEE-SA
generator protection: Schemes to protect generators from fault conditions such as loss-of-field, motoring,
and from all other potentially damaging conditions.
global positioning system (GPS) receiver: Device that acquires precision time and position data from the
US Department of Defense system of a constellation of low-orbit satellites for position determination world-
wide. For substations it is used as a time receiver for equipment clock synchronization.
GMT: Greenwich Mean Time
High Impedance Fault (HiZ) Detection: Reports possible high impedance arcing fault conditions on the
feeder. A high impedance fault is characterized as having an impedance sufficiently high that it is not
detected by conventional OvercurrentProtection. To date, this has been commercially applied to distribution
feeder ProtectiveDevices, and is mostly used in the monitoring and alarm mode.
IEC: International Electrotechnical Commission
IEC TC 57: International Electrotechnical Commission Technical Committee 57
instance of (when instantiated): Phrase used to denote that an abstraction (class-object) takes on a real-
world form and behavior of a person, place, or thing that it represents. Usually denoted by an attribute iden-
tifier that it inherits from the parent or is an attribute of the class-object instantiated.
integrity: Immunity requirements to the network of data transfer errors due to accidental or intentional
interference. Three levels are defined:
High, where a vanishingly small probability of undetected error must be achieved.

Medium, where inherent data redundancy provides adequate error immunity.
Low, where errors are merely a nuisance to the data recipient.
Intelligent Electronic Device (IED): Programmable monitoring, control, protection, or data processing
device with at least one serial communication interface.
interchangeability: Two IEDs are interchangeable when one can replace the other without changing exter-
nal functionality or performances.
interoperability: Two IEDs are interoperable when able to exchange information needed for their on-line
operation. This is normally achieved by using only published standard data and object definitions, standard
commands, and standard protocols at all relevant layers of the OSI reference model.
Inverse Time Overcurrent: This device determines whether a fault exists in its associated power apparatus
by comparing a current (ampere) measurement against a threshold (trip setting) value. However, the trip set-
ting is determined (characterized) by a settings curve (time versus measured current). The curves are charac-
terized by varying degrees of the inverse relationships of current to time duration. If the measured current
exceeds the trip setting (pickup current) for the corresponding time on the settings curve, a fault is indi-
cated.
The Inverse Time Overcurrent Protection corresponds to the definition of the IEEE Inverse Time Overcur-
rent Device Number 51 and 51N.
ISO: International Organization for Standardization.
isolator: Device that connects and disconnects de-energized power circuits.

IEEE-SA
journaling: Means to maintain an audit trail of all control activities.
kb: Kilobytes.
line fault location: Procedure to locate line faults to minimize service restoration time.
line load monitoring: Automated supervision procedure to support line operation close to limits.
line protection: Scheme to detect line faults and trip all breakers attached to the faulted line.
load flow control: Procedure to manage transmission or distribution line loading.
load tap changer (LTC): A power switch integral to an LTC transformer or step-voltage regulator that
accommodates adjustment of the voltage ratio while operating under load.
load tap changer (LTC) control: Electronic device that receives scaled system voltage, current, or other
signals, compares existing operating conditions to that desired, and a commands load tap changer action
accordingly.
load tap changer controller relay: Device that manages the operation of a load tap changer on a trans-
former or step-voltage regulator. Synonym: voltage regulating relay (when used for control of the system
voltage).
management information base: The set of managed objects in a system, together with their attributes. It is
a conceptual repository of management information at each system.
management information library: A document containing the specification of all defined managed objects
and a complete description of their behavior. Development of this library is currently being proposed by
groups such as the NIST OSI Implementor Workshop Group.
master: The remote client that requests information or a control operation from an RTU. Usually referred to
in the singular, but there may be more than one.
master/slave: Communication management scheme (called polling) in which one IED (the master) requests
a specified one of a group of IEDs (slaves) to deliver specified information. Only masters, not slaves, may
issue unsolicited data or commands; used where data flows primarily between the slaves and the master.
Quiescent reporting schemes use an implied initial data request solicitation by the master.
MB: megabyte.
meter: Device that uses sensor data to calculate real and reactive power and energy.
method: Specific behavior that an object is responsible for exhibiting. The central issue in defining services
is to define required behavior classified as follows: 1) on the basis of immediate causation, 2) on similarity or
evolutionary history change over time, and 3) on the similarity of function. A service also defines the neces-
sary communication between objects.
MMI: man-machine interface
MMS: manufacturing message specification
modem: Modulator/demodulator; electronic device that enables digital data to be sent over analog transmis-
sion facilities.

IEEE-SA
ms, msec: millisecond.
multicast: Simultaneous transmission of data to a defined group of destinations on a network.
NegativeSequence OvercurrentProtection: Negative sequence instantaneous and time overcurrent is used

to increase sensitivity in the detection of unbalanced load and fault conditions (e.g., in the unbalanced loading
of a generator, or unsymmetrical types of faults on a feeder). The negative sequence settings can be set below
load current levels since normal, balanced load currents do not generate negative sequence current. This relay
monitors the negative sequence current of each phase. Corresponds to the IEEE Device number 46.
nonrepudiation: Method by which the sender of data is provided with proof of delivery and the recipient is
assured of the senders identity, so that neither can later deny having processed the data.
object: A) Noun defining a person, place, or thing that represents what a system needs to know and do about
an actual object. B) Passive entity that contains or receives information.
OSI: Open Systems Interconnection.
out-of-step protection: Automated detection of potential generator phase slip to avoid generator damage, to
manage power network islanding, and to prevent undesired line relay action in the event of a stable power
swing.
peer-to-peer: Ability of arbitrary pairs of network nodes to manage communication mutual information in
contrast to the master/slave communication.
phase shifter control: Procedure to control the load tap changer of phase shifting transformers to manage
phase angles and load flows.
phasor measurement unit (PMU): Device that extracts line-frequency phase angle and magnitude data
from sensor signals.
pilot channel monitoring: Automated procedure that reports detected failures of protective relaying signal-
ing channels.
PLC: programmable logic controller
point: Physical input/output hardware or the data describing that hardware.
power flow control: Automated procedure to manage power transfers through power transmission and dis-
tribution networks.
power quality monitoring: Procedures for collection, storage, and analysis of power quality data at sub-
transmission and distribution load points.
priority: Ability of the communication network to support several levels of message priority. Higher priority
messages are given access to communication resources before lower priority messages.
protection facilities: Manual support of protection system operations.
quality of service (QOS): A parameter specifying the level of performance needed for communications,
such as transit delay, priority, accuracy, or reliability.
RCB: report control block

IEEE-SA
RCL: relay control logic
reactor/capacitor protection: Scheme for detailed monitoring of reactive devices to detect internal faults
and to trip all breakers connected to the faulted reactor/capacitor.
recloser: Special purpose breaker with integral relaying that automatically trips and recloses to minimize
service restoration time after temporary faults.
recloser control: Automated procedure to manage the setpoints of reclosers to minimize service restoration
time.
regulator: Abbreviated form for step-voltage regulator. Often incorrectly used when load tap changer con-
troller relay is intended.
relay: Device that uses sensor data to protect major power system equipment items.
relay setting control: Procedure to manage the adjustment of setpoints in protective relaying equipment.
relay setting update: Procedures that report existing setpoints of protective relays and support the delivery
of revised settings.
relay testing: Procedures that support testing of protective relay equipment.
remote terminal unit (RTU): A device that concentrates sensor data for transfer to, and accepts power sys-
tem device control commands from, an external SCADA system.
report by exception (RBE) criteria: Values against which DataObjects in a DataSet will be checked to
determine if an event condition has occurred. When an event condition occurs, then specified DataOb-
jects in the DataSet are collected to be transmitted to the designated client.
report control block: A data structure that describes the criteria for the server to initiate unsolicited data
transfers by time and/or event. The data transmitted will either be the complete DataObject or DataSet (no
RBE), or it will be only the changed values within a DataObject or DataSet (if RBE is specified).
report-by-exception (RBE): Mode of operation in which an end system (e.g., RTU or IED) only reports
information that has changed since data was last transmitted.
response time: Time between the request and the response for a network transaction.
RLC: reactive line component
RTU: remote terminal unit
SBO: select before operate
SCADA: supervisory control and data acquisition
scale: Multiplier used to convert a value from the measured value to the appropriate units.
scan group: RTU/SCADA term for a data set.
security: Immunity of network resources to accidental or intentional unauthorized access. Three levels are
defined:
High, where access is limited to predefined and validated clients.

Medium, where access is granted to any client meeting simple criteria.

IEEE-SA
Low, where access (usually read-only) is granted to any client.
select before operate (SBO): A sequence of control services consisting of the select service and the control/
operate service. The select service is used to arm an SBO device prior to operation. The control service is
used to carry out a control command after a Select has succeeded. This sequence has the effect that a client
can lock-out other clients from operating a point for a predetermined period of time so that it is the only cli-
ent that can operate the point.
sensor: Sensing device for physical variables such as ac and dc voltage and current, switch status, tempera-
ture, humidity, etc.
sequence of events (SOE): An ordered, timestamped log of the state changes of binary inputs (also known
as status inputs). Used to recreate or analyze the behavior of a power system over a period of time.
sequence of events (SOE) recorder: Device that samples and stores all events, such as contact status
changes, trips, limit violations, etc., for later replay and analysis. The events are time-tagged at the source.
sequence of events monitoring: Procedure to manage the collection, analysis, and presentation of SOE
data.
server: Object that provides information to another (i.e., the client). Typical examples of servers are station
computers and bay control/protection units. In substation applications servers have real-time requirements
and are running with real-time operating systems.
SQL: sequential query language
step-voltage regulator: Device used in the power circuit to regulate the system voltage, usually to within
+/-10% of its input voltage level.
supervisory control: Arrangement for operator control and supervision of remotely located apparatus using
multiplexing techniques over a relatively small number of interconnecting channels.
switch: Common denominator for circuit breakers and isolators (i.e., for the switching elements in the
power network).
synchro check: Automatic procedure to check if frequency, voltage, and phase match when interconnecting
energized portions of the power network.
synchronization: Automatic procedure to reach frequency, voltage and phase match when interconnecting
energized portions of the power network by active means (excitation, etc.)
syntax: Grammar or structure rules that must be adhered to by a language (e.g., transfer syntax).
TAL: time-allowed-to-live
tap changer: In general, may refer to a load tap changer or a deenergized tap changer. Used interchangeably
with load tap changer in this document.
tap changer controller: Device that manages the operation of load tap changers or voltage regulators for
control of voltage level. Used interchangeably with voltage regulation relay in this document.
tie tripping: Procedures to separate and reconnect the two parts of a split bus to minimize fault propagation
through the power network.

IEEE-SA
timestamping: Message containing a field that tells the age of the information that it carries.
transformer: Device that links power system circuits at different ac voltage levels.
transformer circulating reactive current control: Automated procedure to detect and reduce excessive
circulating reactive currents as may result from the parallel operation of nonidentical LTC transformers.
transformer protection: Scheme to detect transformer internal faults and to trip all breakers connected to a
faulted transformer.
UCA: Utility Communications Architecture
UF: under frequency
UMS: utility message specification
unit tripping: Automatic disconnection of a faulted generator unit.
unsolicited message: Message transmitted in response to a locally occurring event, rather than an explicit
remote request.
VAr controller: Device that manages the operation of banks of capacitors and/or inductors for control of
reactive power flow.
virtual device: Class of power system substation devices.
volt and VAr control: Procedures to manage bus voltages and VAr flows throughout the transmission or dis-
tribution network.
voltage regulating relay: Device that manages the operation of a load tap changer on a transformer or step-
voltage regulator when applied for the purpose of controlling system voltage.
voltage regulator: Abbreviated form for step-voltage regulator. Often incorrectly used when load tap
changer controller relay is intended.
VT: voltage transformer

TP 114398

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

TP 114398

Hochgeladen von

Copyright:

Verfügbare Formate

IEEE-SA TR 1550 -- Technical Report

Utility Communications Architecture (UCA) Version 2.0

IEEE-SA Technical Report on

"UCA" is a Trademark of the

15 November 1999 SP1117

Keywords: communications, control centers, digital systems, distribution automation, feeder

ii Copyright 1999 IEEE. All rights reserved.

2. References ........................................................................................................................ 1-2

3. Definitions ........................................................................................................................ 1-3

3.1 Industry-Based Acronyms........................................................................................ 1-3

4.1 UCA Version 1.0 ...................................................................................................................... 1-7

5. UCA Version 2.0 Document Summary ........................................................................... 1-9

6. Implementors Guide to Version 2.0 Specifications ...................................................... 1-10

6.1 Implementing UCA Version 2.0 TASE.2 (ICCP) ................................................... 1-10

7. UCA Integrated Network Example .............................................................................. 1-12

Copyright 1999 IEEE. All rights reserved. iii

Copyright 1999 IEEE. All rights reserved. 1-1

1-2 Copyright 1999 IEEE. All rights reserved.

inter-control center exchange of data using MMS in standard UCA profiles.

3.1 Industry-Based Acronyms

ANSI American National Standards Institute

Copyright 1999 IEEE. All rights reserved. 1-3

3.2 General Definitions

3.2.5 broadcast: Simultaneous transmission of data to all destinations on a network.

1-4 Copyright 1999 IEEE. All rights reserved.

3.2.17 multicast: Simultaneous transmission of data to a defined group of destinations on a network.

Copyright 1999 IEEE. All rights reserved. 1-5

3.3 Definitions Specific to UCA Version 2.0

1-6 Copyright 1999 IEEE. All rights reserved.

4.1 UCA Version 1.0

Copyright 1999 IEEE. All rights reserved. 1-7

4.2 UCA Version 2.0 for Real-Time Database Exchange

4.3 UCA Version 2.0 for Field Devices

1-8 Copyright 1999 IEEE. All rights reserved.

5. UCA Version 2.0 Document Summary

Copyright 1999 IEEE. All rights reserved. 1-9

6. Implementors Guide to Version 2.0 Specifications

6.1 Implementing UCA Version 2.0 TASE.2 (ICCP)

1-10 Copyright 1999 IEEE. All rights reserved.

Vendor Documents UCA Documents

IEC 870-6-802: Specific Object

Application UCA Version 2.0 UCA Version 2.0

Figure 1: Definition of UCA TASE.2 (ICCP) Products

a) IEC 870-6-503: TASE.2 Services and Protocol

6.2 Implementing UCA Version 2.0 Field Devices

Copyright 1999 IEEE. All rights reserved. 1-11

Vendor Documents UCA Documents

Product Common Mapping Objects

Application UCA Version 2.0 UCA Version 2.0

Figure 2: Definition of UCA Field Devices

a) The appropriate UCA object model

7. UCA Integrated Network Example

1-12 Copyright 1999 IEEE. All rights reserved.

Copyright 1999 IEEE. All rights reserved. 1-13

Corporate LAN UCA LAN

DAIS and Security Data

Corporate WAN Metering WAN

Power Plant Transmission Substation

Figure 3: UCA Integrated Network example

1-14 Copyright 1999 IEEE. All rights reserved.

IEEE-SA Technical Report on

"UCA" is a Trademark of the

15 November 1999 SP1117