Professional Documents
Culture Documents
Volume 2
Part 4: UCA Generic Object Models for Substation and Feeder Equipment
(GOMSFE)
IEEE-SA TR 1550-1999
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.
Prepared under the auspices of the Profile Working Group of the MMS Forum
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.
Contents
1. Overview........................................................................................................................... 1-1
4. History............................................................................................................................................... 1-7
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.
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
3. Definitions
The following subsections cover various industry acronyms and definitions.
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.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.6 conformance test: A test used to ensure a product complies with a standard.
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.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.
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.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.
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
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.
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.
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
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.
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).
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.
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.
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
Software Product
Implementation Design
It is important to note that for a device to be conformant to the UCA specifications, it must incorporate three
distinct specifications:
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.
Vendor Product
Informtaion, Vendor Product Utility Standard Standardized
Specification Device Models Devices
Selection of Objects
User Requirements Data Types
and Services
Data Dictionary
Software Product
Implementation Design
It is important to note that for a device to be conformant to the UCA specifications, it must incorporate the
following three distinct specifications:
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.
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.
Corporate
Customer Interface
Automated Energy Residential Commercial Industrial
Engineering Accounting
Mapping Customer Customer Customer
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
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.
Prepared under the auspices of the Profile Working Group of the MMS Forum
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
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.
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.
Contents
1. Overview........................................................................................................................... 2-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.
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.
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.
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.
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"
Physical Media
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.
Appendix A: Defines the relationships and mappings of the upper layer architecture.
2. References
This technical report shall be used in conjunction with the following publications.
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.
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 1597 (March 1994), Address Allocation for Private Internets. Y. Rekhter, B. Moskowitz, D. Karrenberg
& G. de Groot.
EIA-422-A (December 1978), Electrical characteristics of balanced voltage digital interface circuits.
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 8208: 1995, X.25, Packet Level Protocol for Data Terminal Equipment.
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-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).
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 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 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 9314-3: 1990, Fiber Distributed Data InterfacePart 3: Physical Layer Medium Dependent
(PMD).
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 9594-1: 1995, The DirectoryPart 1: Overview of Concepts, Models, and Services.
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 10731: 1994, [ITU-T X.210 (1993)], Information processing systemsOpen Systems Intercon-
nectionOSI Service Conventions.
ISO/IEC 11586: 1996, [ITU-T X.830 (1995)], Information TechnologyOpen Systems Interconnection
Generic Upper Layers Security.
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.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.401 (1984), Message Handling Systems: Basic Service Elements and Optional User Facilities.
(Red Book)
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.420 (1984), Message Handling Systems: Interpersonal Messaging User Agent Layer. (Red Book)
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.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.
Working Implementation Agreements for Open Systems Interconnection Protocols (December 1994).
Netw ISO 8473:CLNP ISO 8473:CLNP ISO 8473:CLNP RFC 791:IP RFC 791:IP
ISO 9506:MMS
Appl
ISO 10035:CL ACSE
ISO 9576-1:CL Presentation
Pres ISO 8824:ASN.1
ISO 8825:BER
DL ISO 8802-2:LLC
Sess
Trans
Netw
ISO 8802-2:LLC ISO 8802-2:LLC
DL
ISO DIS 13239:(non basic frame) ISO DIS 13239: (non basic frame)
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.
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:
Additional application layer services are specified to support the data transfer services described above:
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.
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.
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:
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.
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:
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.
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.
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.
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.
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).
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.
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.
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.
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
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
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 (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.
FastByte Presentation
FastByte Session
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)
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.
Connectionless Presentation
Connectionless Session
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
The protocol to provide the application association control service shall be ISO
8650-1: 1996.
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.
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.
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.
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
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.
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.
RFC 1006
TCP
IPv4
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.
RFC 1070
UDP
IPv4
4.2.2.1 CLTP/CLNP
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.
The RFC 1240 profile consists of the following, as shown in Figure 10:
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.
RFC 1240
UDP
IPv4
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.
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.
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.
Implementations shall conform to the specific implementation guidelines and
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.
Implementations shall conform to the specific implementation guidelines and
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.
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.
Implementations shall conform to the specific implementation guidelines and
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.
Implementations shall conform to the specific implementation guidelines and
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
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.
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).
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
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.
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
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.
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.
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.
IDLE
L.Data request
STARTING
Transmit LSDU
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:
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
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.
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.
LLC1
ADLC or Equivalent
Physical Layer
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.
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.
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
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).
LLC1 shall be used, with 0xF7 for all link layers supporting the connection-mode UCA 3-layer architecture.
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.
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.
LLC1
ADLC or Equivalent
Physical Layer
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.
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
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.
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
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.
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.
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.
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.
Octets 1 2 1 3 2 2 2 6 1
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.
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:
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.
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.
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.
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.
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:
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.
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.
The connectionless-mode upper layer profile for OSI stacks consists of the following:
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).
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.
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.
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.
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.
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.
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
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:
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.
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
Media
Scavenging
Physical intrusion
Resource
Exhaustion
Service
Spoofing
Theft
Traffic analysis
Trapdoor
Trojan horse
The identified security mechanism that this section shall specify are:
There are three levels of security that will be specified within this section:
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.
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.
Note: ISO/IEC 8650 is the ACSE specification and requires that the ACSE parameters be of the following
types or values:
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.
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.
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).
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
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.
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.
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
System 1 System 2
7-layer Both
MMS MMS MMS
Presentation Presentation
Session Session System 3
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.
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.
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.
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.
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.
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.
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
UCA ASO
ASO Service Inputs
Control Function
Component ASE Service Inputs
A2CSE MMS
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.
Client Server
APDUs
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.
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.
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
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
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.
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.
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 MMS
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.
This part of ISO/IEC 9506 assigns the ASN.1 object identifier value
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
The ASN.1 basic encoding rule object identifier and object descriptor values are as follows:
and
The ASN.1 packed encoding rule (BASIC-PER-ALIGNET) object identifier and object descriptor values are
as follows:
and
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)
mms-general-module-major-version1
01*
{joint-iso-ccitt asn1(1) basic-encoding(1)}
mms-general-module-major-version1
02
{joint-iso-ccitt asn1(1) packed-encoding(3) basic(0) unaligned (1)}
mms-general-module-major-version1
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
Control
RTU or EFM
Center
Application
Application
(Server)
(Client)
Request.submit Request.deliver
primitive primitive
Request PDU
UCA Client UCA Server
ASO ASO
Figure A.5: Service Primitive and PDU Flow in a Typical UCA Client Application
These primitives are used by a client application to request an association with a server application.
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.
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.
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.
This request is used to release the association between the RTU and the control center.
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 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.
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.
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.
A.5.1.2.3 Parameters
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.
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.
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.
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.
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.
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).
Client
UCA Service
Inputs to the
Control Function
ACSE MMS
Supporting Service
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.
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.
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.
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.
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.
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.
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.
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.
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.
This section defines the actions that result from inputs generated by the MMS 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 MMS, the reader is directed to ISO 9506.
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.
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.
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.
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
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.
Response.deliver Response.submit
primitive primitive
Figure A.7: Service Primitive and PDU Flow in a Typical UCA Server Application
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.
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.
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.
A.6.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.
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.
This response is used to release the association between the RTU and the control center.
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.
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.
A.6.1.2.3 Parameters
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.
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.
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.
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.
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.
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.
A.6.1.3.5 Parameters
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.
Server
UCA Service
Inputs to the
Control Function
ACSE MMS
Supporting Service
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.
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).
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.
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.
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.
This section defines the actions that result from inputs generated by the ACSE component ASE of this ASO
(see Figure A.8). 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.
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.
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.
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.
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.
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.
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.
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.
When invoked: This primitive may be invoked when the CF is in the TRANSFER state.
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).
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.
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.
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
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.
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.
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.
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:
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.
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.
When invoked: This primitive is invoked when a P-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.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.
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
When invoked: This primitive is invoked to notify the supporting service that the request for the release of
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
When invoked: This primitive is invoked to notify the supporting service that the request for the release of
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.
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.
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.1 Request
The request parameter shall indicate that the service has been invoked by the time master.
Table B.1
B.1.3.1 Request
The request parameter shall indicate that the service has been invoked by the time master.
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).
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.
Table B.2
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.
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.
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).
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.
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.
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.
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.
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
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.
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.
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.
Table B.3
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.
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.
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.
Add to 2.2:
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.
Add to Clause 4:
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.
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:
{
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.
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.
Add to 5.2.2:
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.
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.
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.
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.
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.
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.
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
The following describes the interactions on the sending side in Figure 7.
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:
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
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.
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)}
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)}
{
modulus INTEGER, -- maximum of 64 value bits in each
INTEGER
exponent INTEGER -- maximum of 64 value bits in each
INTEGER
} OPTIONAL,
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-
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.
Delete Annex C.
END
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.
Prepared under the auspices of the Profile Working Group of the MMS Forum
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.
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.
Contents
1. Overview........................................................................................................................... 3-1
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.
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.
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.
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.
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.
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.
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.
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.
1Refer to books by Rumbaugh, Booch, COAD, or Yourdon for background information on object modeling tech-
niques and definitions.
Server Model
Data Set Device Control
Model Model
Association Multicast
Model Model Data
Object
Data Access Time Model
Model Model
Reporting Blob
Model Model
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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-
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.
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
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
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).
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.
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.
Model: LogicalDevice
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.
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.
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
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.
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).
Model: DataObject
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.
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.
UCA Standard
Description, Range of Values (where applicable)
DataType Name
BOOL Boolean1 bit, True (1) or False (0)
BSTR2 Bitstring2 bits
BSTR8 Bitstring8 bits
BSTR16 Bitstring16 bits
BSTR32 Bitstring32 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)
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
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.
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.
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:
ATempController/Thermostat.MX.TempSensor.i
M1234/Txfrm.CF.Volts[2].s
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
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.
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.
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.
5.3.6 DeviceModels
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
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.
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
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.
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.
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.
Model: DataSet
Attribute: Scope
Attribute: Access control
Attribute: Deletable
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.
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.
Model: Server
Server Model
Data Set Device Control
Model Model
Association Multicast
Model Model Data
Object
Data Access Time Model
Model Model
Reporting Blob
Model Model
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.
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.
Model: Association
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.
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.
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 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.
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.
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
Service spoofing
Theft
Traffic analysis
Trapdoor
Trojan Horse
The identified security functions that this section shall specify are stated in the following sections.
Client Server
Application
User
Request for
Action
Request Accessed
Requesting Remote
Application Application
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:
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.
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.
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
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.
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.
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.
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.
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.
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:
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).
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.
Any implementation claiming conformance to the security service model shall implement and support the
following objects:
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.
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.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.
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.
Event
Agent
Set Control
Block
Enroll Notify
Set Control
Block Report
Client Enroll Notify
Agent
Report
Set Control
Block
Query
Log
Agent
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.
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
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:
Data
Objects
Event
Control Block
Event
Enrollments
Set Control Block Event Notify
(Client) (Log Agent)
Event Agent
Enroll
(Log Agent)
The following object models are used in the performance of these functions.
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:
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.
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.
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.
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: 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:
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.
Two classes of event model services are defined for the Event Agent: client services and internal methods.
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).
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.
The Report Agent model specifies the following capabilities for controlling various aspects of the reporting
process:
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).
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.
Enroll Notify
(Event Agent) (Event Agent
RCBs
Report
(Client)
Report Agent
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,
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.
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).
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.
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.
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.
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:
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.
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.
The UCA log model provides a standardized method of providing the logging capability. shows the Log
Agent model inputs and outputs.
Enroll
(Event Agent)
Query
(Client)
Log
Control Block
Logged
Data
Log Agent
Log agents maintain databases of historical data, as well as log control blocks for managing the logging
process.
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: 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:
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.
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:
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.
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:
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.
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.
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:
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
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
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
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 server may choose to default the values found in LogEnr and not allow a client to change these values.
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
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.
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:
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.
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.
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:
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.
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:
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:
The Client initiates the logging of information by writing the Loc Control Block parameters as follows:
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.
The following examples show how simple device models may make use of the agent models to define report-
ing capabilities.
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
Wr ite Report
Control Block Report
Client
Agent
Report
Device 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:
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.
<----------------------------------------------------Event Notify
<------------------------------------------Report
Log Data
<----------------------------------------------------Event Notify
<------------------------------------------Report
Query Log---------------------------------------------------------------------->
<----------------------------------------------------Logged Data
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.
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.
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.
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
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:
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.
The availability of this capability, for use by the client, shall be listed as one of the association models list of
capabilities. See 6.1 for further details.
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.
Attribute DataType
SBOName DOReference to this component
State bool
SelTimOut int8u
SBOClass enum8
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).
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-
Time activated device name: Identifier that uniquely identifies the control point of the device to be directly
controlled.
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.
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.
Attribute DataType
Name TimActCtl
Cmd enum16
Parm btim4
When btim6
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.
The availability of this capability, for use by the client, shall be listed as one of the association models list of
capabilities. See 6.1 for further details.
Object: Tag
Attribute: TagID
Attribute: TagTyp
Attribute: TagD
Attribute: TagOwn
TagID: Uniquely identifies the tag number for the device or point assigned to.
TagTyp: The permissible tag types. The bits representing TagTyp are:
TagOwn: Owner or person who placed the tag. Safety tags can only be removed by or with permission of the
TagOwn.
Model: DeviceTag
Attribute: Tags: ARRAY[4] of Tag
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.
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.
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.
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.
AccessControl: This attribute defines the network visibility and access privileges of the BlobData to calling
clients. The representation is a local matter.
Format: This attribute defines the internal composition of the data if it is known.
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.
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:
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
Client issues
Transfer Completed InitiateBlobTransfer Request
TransferBlobData
Select failure
1 TEMPORARILY_UNAVAILABLE
2 OBJECT_ACCESS_DENIED
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.
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.
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.
Table 13 enumerates response errorCodes that might result from an unsuccessful confirmed method.
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
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.
Service: SetDataObjectValues
MMS Services/Argument/Results Server Client Note
(unconfirmed)
Request InformationReport
ListOfDataObjects VariableAccessSpecification m m
Parameter = listOfVariable
ListofData ListofData m m
Response
<None>
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.
5Values are data that correspond to the type of the DataObject referenced by the DataObjectName.
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.
Servers always include IB when the containing structure is read in total. The following cases apply:
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.
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.
DeviceIdentity maps to a DataObject with DataType STRUCTURE. It must always be a NamedVariable named
DI. See 8.6.
Service:
MMS Services/Argument/Results Server Client Note
GetDataSetElementNames
Request GetNamedVariableListAttributes request
DataSet variableListName m m
Response+ GetNamedVariableListAttributes response m m
ListofDOReference listOfVariable m m
Responsesee 8.3.
Parameter = variableListName
OPTIONAL
Values listofAccessResult m m
Responsesee 8.3.
Service:
MMS Services/Argument/Results Server Client Note
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.
Note: LogicalDevice must map to domain; optionally, it can additionally map to VMD.
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.
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.
The log object maps to an MMS journal, with each LogEntry being represented as an MMS journal entry as
shown in Table 45.
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.
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
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.
Utility Communications
Architecture (UCA )
TM
Version 2.0
Volume 2
Part 4:
UCATM Generic Object Models
for Substation and Feeder
Equipment (GOMSFE)
Published by
The Institute of Electrical and Electronics Engineers, Inc.
3 Park Avenue, New York, NY 10016-5997, USA.
Prepared under the auspices of the Substation and Feeder Working Group of the MMS Forum and
the Sunstation Initiative Project.
Acknowledgements
The following participated in the authorship and review process of this document:
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.
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.
Contents
1. Overview........................................................................................................................... 4-1
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 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.
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
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
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
BkrC
MU
IOC
TOC
Virtual Device
RecR
Dist_1
Dist_2
Dist_3
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.
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
FunctionalComponents
Common Classes
Common Components
Standard DataTypes
2.1 Introduction
This section covers basic techniques for class-object model construction, and defines the class-object
hierarchy.
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.
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
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.
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.
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.
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:
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:
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:
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:
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.
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.
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.
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.
The balance of this section describes recommended conventions for naming of the CASM classes and their
object instances.
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).
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.
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.
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
This section summarizes how to specify CASM DataObject classes and data types for presentation in
DeviceModel documents.
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.
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.
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
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:
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:
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.
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
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
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
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
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
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
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
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].
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.
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.
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.
To access complete common class derived objects, only the common object name is used:
In this case, all of the components in the class would be returned with a read.
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:
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.
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):
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).
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
PriDschPres
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
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.
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).
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
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.
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.
For example, given a voltage measurement AV (phase A voltage V), there may be the following DataOb-
jects defined for a given DeviceModel ADM:
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:
In defining a given binary valued DataObject, the required groupings are selected to model the specific func-
tion required.
For example, control of a switch, SW. Assume that a switch is a 2-bit binary value.
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
Table 6 (continued)
Common Components
Name Description DataType
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
Table 6 (continued)
Common Components
Name Description DataType
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
Table 6 (continued)
Common Components
Name Description DataType
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
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.
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:
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).
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
The time duration for buffering input and output values for reporting.
5.1.10 Circuit ID
5.1.15 CurEnt
5.1.16 DatSet
Value Day
1 Sunday
2 Monday
3 Tuesday
4 Wednesday
5 Thursday
6 Friday
7 Saturday
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:
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.
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.
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
Table 7 (continued)
Table 7 (continued)
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.
The operating state of a two state device expressed as a 2-bit status input (SIT), as defined in Table 8.
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.
The maximum duration of the fault current rating allowed through the device.
The maximum fault current allowed through the device for the time specified in fault current duration.
For analog values, the floating point representation of the analog value is calculated by:
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
The command to freeze the accumulator, i.e., copy the running value into the frozen value.
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.
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.
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:
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
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:
Integer Measurement
Value Reference
1 Unknown
2 Phase 1
3 Phase 2
4 Phase 3
5 Neutral
6 Phase 1 to phase 2
7 Phase 2 to phase 3
8 Phase 3 to phase 1
9 Phase 1 to neutral
10 Phase 2 to neutral
11 Phase 3 to neutral
12 Neutral to ground
13 3 phase
1415 Unassigned (future use)
5.1.39 Model
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.
For binary control, the number of output pulses to be sent. The default is 1.
If applicable, this is the number of samples used in the actual measurement associated with the measurement
type.
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.
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.
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.
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
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
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:
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.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
5.1.61 SelTimOut
Per device SBO select timeout in seconds. Or the maximum time for conducting a specified activity is valid.
5.1.63 SftRev
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.
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
Integer UCA
Quantity Unit Name Symbol
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)
Integer UCA
Quantity Unit Name Symbol
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.67 TagID
Uniquely identifies the tag number for the device or point assigned to.
Owner or person who placed the tag. Safety tags can only be removed by or with permission of the tag
owner.
The permissible tag types for the device. The bits representing tag type permitted are:
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
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.
An optional component used to indicate the last time the object was updated. A default of zero indicates that
5.1.75 Trgs
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.80 Vendor
The name of the manufacturer of the device.
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.
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
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.
CommunicationIdentity describes the communications interface used to communicate with the physical
device.
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
Functional
Common Class
Component
Name Description Name Description
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
Functional
Common Class
Component
Name Description Name Description
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
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
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.
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.
Common Class: HI
Harmonic Input
Name DataType m/o
DC FLT32 o
PwrHa FLT32[31] o
t BTIME6 o
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.
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.
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.
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.
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
Status input double bit represents the 2-bit states of inputs. Common use of SIT for is defined by the com-
mon component DevST.
Status input group represents a group of two or more bit states of inputs.
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.
Common Class: AO
Analog Output
Name DataType m/o
i INT16S o
f FLT32 o
SBO IDENT o
Analog input setpoints represents a collection of operating limits applicable to an individual MX point. The
limits can be used to trigger other actions.
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.
CldLod is a pickup setting to allow for inrush of load current when the circuit has been off for a long time.
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.
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:
DOWSch = BTIME4[6]
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
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.
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.
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
among field devices.
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
among field devices.
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
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.
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.
Analog configuration represents the configuration parameters for analog inputs and outputs.
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.
RATIO represents the ratio between primary and secondary windings for the referenced measurements.
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
Ko is zero sequence compensation factor = (Zo-Z1)/3Z1, where Zo is zero sequence impedance, and Z1 is
positive sequence impedance.
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
CriRpt is disabled
DestAE is single client
EncOpt is not applicable
Enroll is the name of the ECB for the report.
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.
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.
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
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 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.
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.
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.
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.
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.
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.
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
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.
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
54, 55 28 Reserved Invalid Preset Pass through Invalid
56, 57 29 Reserved Invalid Preset Pass through Invalid
58, 59 30 Reserved Invalid Preset Pass through Invalid
60, 61 31 Reserved Invalid Preset Pass through Invalid
62, 63 32 Reserved Invalid Preset Pass through Invalid
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
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.
The time for the message being valid has expired, and
The SelInDNA for the bit pair is set to default
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.
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.
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
Bit Order 00 01 10 11
Bit
Bit # Value 0 1 2 3
Pair
Definition State State State State
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
Bit Order 00 01 10 11
Bit
Bit # Value 0 1 2 3
Pair
Definition State State State State
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
54, 55 28 Reserved Default value Preset Pass through Invalid
56, 57 29 Reserved Default value Preset Pass through Invalid
58, 59 30 Reserved Default value Preset Pass through Invalid
60, 61 31 Reserved Default value Preset Pass through Invalid
62, 63 32 Reserved Default value Preset Pass through Invalid
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
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:
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.)
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.
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.
The common components of the GOOSE class object are defined below. See Table 18.
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.
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.
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.
This number is incremented by one each time a message is sent. It rolls over after the maximum count is
reached.
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.
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
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.
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.
Bit Order 00 01 10 11
Bit
Bit # Value 0 1 2 3
Pair
Definition State State State State
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
Bit Order 00 01 10 11
Bit
Bit # Value 0 1 2 3
Pair
Definition State State State State
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
OILC is the present measurements relating to oil insulation. See Figure 11 and Table 20.
T
Lev
Color
Diel
Tension
H2O
Acid
DissFactor
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 data set
member.
7.2.1.3 DataSet
The OILC brick contains one DataSet, OILC.MX, for retrieval by a client.
The IGAS brick represents inert gasses used for insulating high voltage power equipment. See Figure 12 and
Table 21.
Inert Gas
TankPres
BtlPres
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.
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)
Attribute brcbST
RptID NULL
RptEna FALSE
DatSet ST
OptFlds All options
BufTim 0
Trgs 0
SeqNum 0
TrgOps CndDatChg
RBEPd 0
IntgPd 0
7.2.3.3 DataSets
The VACU brick contains one DataSet, VACU.ST, for retrieval by a client.
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
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.
FIRs FltMagA
FIPuThre
FIPuHyst
FIA
FIInrushDel
FIB
FIZeroThre
FIC
FltTmrRs
FIN
brcbMX: Report all changes in value that exceed deadbands specified in CF for each DataSet
member.
brcbST: Report all change of state for each DataSet member.
7.2.5.3 DataSets
DataSet
DataSet
DatSet Components
No.
(Object Attributes)
1 FIND.MX All measurements
2 FIND.ST All status points
3 FIND.SP All setpoints
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)
brcbMX: Report all changes in value that exceed deadbands specified in CF for each DataSet member.
brcbST: Report all change of state for each DataSet member.
7.2.6.3 DataSets
DataSet
DataSet No. DatSet Components
(Object Attributes)
1 INSU.MX All measurements
2 INSU.ST All status
3 INSU.SP All Setpoints
BattV
StartBattTest
PwrSupSt
brcbMX: Report all changes in value that exceed deadbands specified in CF for each DataSet
member.
brcbST: Report all change of state for each DataSet member.
7.2.7.3 DataSets
DataSet
DataSet No. DatSet Components
(Object Attributes)
1 PSUP.MX All measurements
2 PSUP.ST All status
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
Attribute brcbST
RptID NULL
RptEna FALSE
DatSet ST
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.
brcbST: Report all change of state for each DataSet member.
7.2.8.3 DataSets
The RATO provides a logical representation of primary and secondary winding ratios for measurements. See
Figure 19 and Table 28.
APhsV
BPhsV
CPhsV
APhsA
BPhsA
CPhsA
NeutA
ABPhsV
BCPhsV
CAPhsV
Ratio (RATO)
GAIN provides a generic measurement of a single analog input or a group of analog inputs. See Figure 20
and Table 29.
In
Input
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.3.1.3 DataSets
The GAIN brick contains one DataSet, GAIN.MX, for retrieval by a client.
GSPT provides a generic setpoint output for either a single output, or a group of generic setpoints. See
Figure 21 and Table 30.
Out
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.3.2.3 DataSets
The GSPT brick contains one DataSet, GSPT.SP, for retrieval by a client.
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
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.3.3.3 DataSets
The GACC brick contains one DataSet, GACC.MX, for retrieval by a client.
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
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
DataSet
DataSet
DatSet Components
No.
(Object Attributes)
1 GIND.ST All status points
2 GIND.SOELog All SOE points
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
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
DataSet
DataSet
DatSet Components
No.
(Object Attributes)
1 GCTL.SOELog All SOE points
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
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.4.1.3 DataSets
As a type of server, the PMXU contains one DataSet, PMXU.MX, for retrieval by a client.
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)
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.4.2.3 DataSets
The polyphase meter contains one DataSet, EMTR.MX, for retrieval by a client.
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
brcbMX: Report all changes in value that exceed deadbands specified in CF for each DataSet
member.
brcbST: Report all change of state for each DataSet member.
7.4.3.3 DataSets
DataSet
DataSet
DatSet Components
No.
(Object Attributes)
1 SYNC.MX All measurements
2 SYNC.ST All status points
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
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.
brcbST: Report all change of state for each DataSet member.
7.4.4.3 DataSets
The TEMP brick contains one DataSet, TEMP.MX, for retrieval by a client.
Transformer
Figure 29: Transformer
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
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.
brcbST: Report all change of state for each DataSet member.
7.5.1.3 DataSets
The TANK brick contains one DataSet, TANK.MX, for retrieval by a client.
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)
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.5.2.3 DataSet
The BUSH brick contains one DataSet, BUSH.MX, for retrieval by a client.
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.
TopT
BotT
InT
OutT
InPres
OutPres
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.5.3.3 DataSet
The HTEX brick contains one data set, HTEX.MX, for retrieval by a client.
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
brcbMX: Report all changes in value that exceed deadbands specified in CF for each DataSet
member.
brcbST: Report all change of state for each DataSet member.
7.5.4.3 DataSets
DataSet
DataSet
DatSet Components
No.
(Object Attributes)
1 PUMP.MX All measurements
2 PUMP.ST All status points
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
Figure 34 and Table 42.
T
A
OnT
OffT
ODAutoMan
ODFan DS
CFAN
brcbMX: Report all changes in value that exceed deadbands specified in CF for each DataSet
member.
brcbST: Report all change of state for each DataSet member.
7.5.5.3 DataSets
DataSet
DataSet
DatSet Components
No.
(Object Attributes)
1 CFAN.MX All measurements
2 CFAN.ST All status points
T
A
OnT
OffT
ODAutoMan
ODFan DS
brcbMX: Report all changes in value that exceed deadbands specified in CF for each DataSet member.
brcbST: Report all change of state for each DataSet member.
7.5.6.3 DataSets
DataSet
DataSet
DatSet Components
No.
(Object Attributes)
1 LTCH.MX All measurements
2 LTCH.ST All status points
SwDS
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
DataSet No. DatSet Components
(Object Attributes)
1 SWIT.ST All status points
The SDRV brick is the logical representation of a switch drive mechanism. See Figure 37 and Table 45.
LocRemDS
CtlFailInd
ODSw CtlTagBlk
CtlIntlkBlk
M
brcbMX: Report all changes in value that exceed deadbands specified in CF for each DataSet
member.
Brcbst: Report all change of state for each DataSet member.
7.6.2.3 DataSets
DataSet
DataSet
DatSet Components
No.
(Object Attributes)
1 SDRV.MX All measurements
2 SDRV.ST All status points
3 SDRV.SOELog All SOE points
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.
ODSw
M SwDS
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
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
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
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
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
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)
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
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.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
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-
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.
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
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 )
7.8.2.1 RsChar
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
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.
CONTROL OUT
BROB
(ENA, DIS)
(1, 0)
SETPOINT
(Pu) AUXOUT
AUXIN
(Bool [16]) TARGET
MONITORED INPUTS
+
BTCO
SETPOINT
(CRVMULT,
CRVTYP,
TIMDIAL)
PoRch
RectRch
PctRch
RchDir
Ofs
Slp
PoQuad
RectQuad
PoBlind
RectBlind
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.
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
7.8.5.1 DistTyp
(0 = inactive/off, 1 = active/on):
7.8.5.2 ChrTyp
ChrTyp is represented by a bit string [8] of individual distance faults types: ohm, mho, quadrilateral, offset,
etc.
(0 = inactive/off, 1 = active/on):
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.
CONTROL OUT
SYNC
(ENA, DIS)
(1, 0)
SETPOINT
(Pu) AUXOUT
AUXIN
(Bool [16]) TARGET
MONITORED INPUTS
Volts (AG, BG, CG, AB, BC, CA)
The HIZR inherits the BROB basic building brick and adds:
DnCond
ArcSus
OCTar
LOL
HROC
For HiZ, the Pu value is over current
CONTROL OUT
HIZR
(ENA, DIS)
(1, 0)
SETPOINT
(Pu) AUXOUT
AUXIN
(Bool [16]) TARGET
MONITORED INPUTS
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)
The RECR inherits the BROB basic building block and adds:
ReclSeq
BkrTrip
IniRecl
CONTROL OUT
RECR
(ENA, DIS)
(1, 0)
SETPOINT
(Pu) AUXOUT
AUXIN
(Bool [16])
MONITORED INPUTS
BREAKER TRIP
The DIFF inherits the BROB basic building block and adds Slp. For DIFF, the Pu value is in amperes.
CONTROL OUT
DOCR
(ENA, DIS)
(1, 0)
SETPOINT
(SLP, Pu) AUXOUT
AUXIN
(Bool [16]) TARGET
MONITORED INPUTS
AMPERES (A, B, C)
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.
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.
AMPS
A, B , C, N MU LOGS
A-B, B-C, C-A
VOLTS
AG, BG, CG,
AB , BC , CA
MEASUREMENT UNIT
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.
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
brcbMX: Report all changes in value that exceed deadbands specified in CF for each DataSet
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:
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.
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:
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.
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.
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:
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.
CONTROLS OUTPUTS
RTU
ANALOGS
BINARY:
SETPOINTS
MOMENTARY
PULSED OR
LATCHED
W/WO SBO
MONITORED
ANALOGS, ACCUMULATORS, STATUS
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:
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.
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, ...).
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.
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.
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.1 AlertSt
10.4.2 AlertSt1
10.4.3 AlertSt2
Command status is represented by a bit string [16] of individual status points as follows:
(0 = inactive/off, 1 = active/on):
Effectively, two position toggle switches are used, allowing four physical states:
10.4.5.2 Auto/Manual for the IED (enabled only when in LOCAL CONTROL)
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
10.4.7 DmdInt1
10.4.8 LDC
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.
10.4.10 OperatingConditions
10.4.11 Parallel
Bit
Description rwec m/o
Order
Disable 00 r m
Circulating current 01 rw o
VAr balance 10 rw o
Power flow status is represented by a bit string [16] of individual status points as follows.
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.
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:
10.4.15 RevPwr
10.4.17 TapInfo
10.4.18 Tmr
Note that only one timer is mandatory; if both are provided, rw is required.
10.4.19 TmrDel
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.
10.4.22 VRedS
Bit
VRedS m/o
Order
No reduction 00 o
Stage 1 01 o
Stage 2 10 o
Stage 3 11 o
10.5 DataSets
DataSets are components grouped to accommodate convenient access of related points. As a type of server,
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.
Model
Switch Device
NAME
SwC Switch controller
ASwC Automated switch controller
BkrC Breaker controller
Recl Recloser
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.
brcbMX: Report all changes in value that exceed deadbands specified in CF for each DataSet
member.
brcbST: Report all change of state for each DataSet member.
11.1.3 DataSets
DataSets are components grouped to accommodate convenient access of related points. As a type of server,
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
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.
11.2.4 FI<Phase>
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.
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.
brcbMX: Report all changes in value that exceed deadbands specified in CF for each DataSet
member.
brcbST: Report all change of state for each DataSet member.
11.2.9 DataSets
DataSets are components grouped to accommodate convenient access of related points. As a type of server,
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.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.
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.
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:
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.1 BkrCtlFailSt
11.3.3.2 SyncSt
11.3.3.3 ReclDS
brcbMX: Report all changes in value that exceed deadbands specified in CF for each DataSet
member.
brcbST: Report all change of state for each DataSet member.
11.3.4 DataSets
DataSets are components grouped to accommodate convenient access of related points. As a type of server,
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
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.
brcbMX: Report all changes in value that exceed deadbands specified in CF for each DataSet
member.
brcbST: Report all change of state for each DataSet member.
11.4.3 DataSets
DataSets are components grouped to accommodate convenient access of related points. As a type of server,
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
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.
brcbMX: Report all changes in value that exceed deadbands specified in CF for each DataSet
member.
brcbST: Report all change of state for each DataSet member.
12.1.2.3 OperLogic
OperLogic Bit #
Reserved 0
Time schedule 1
Temperature 2
VAr 3
Voltage 4
Voltage override 5
(future) 6-15
12.1.2.4 SensorSt
SensorSt Bit #
Reserved 0
Reverse current 1
Voltage bad 2
Current bad 3
Phase angle bad 4
(future) 5-7
12.2 DataSets
DataSets are components grouped to accommodate convenient access of related points. As a type of server,
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
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:
LD LogicalDevice
DI DeviceIdentity
DM DeviceModel
FC FunctionalComponent
DS DataSet
DO Domain
NV Named variable
NVL Named variable list
AA Alternate access used to obtain component
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
CASM MMS
CASM Class MMS Class
Component Object MMS Variable Name
(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
CASM MMS
CASM Class MMS Class
Component Object MMS Variable Name
(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
CASM MMS
CASM Class MMS Class
Component Object MMS Variable Name
(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
CASM MMS
CASM Class MMS Class
Component Object MMS Variable Name
(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
CASM MMS
CASM Class MMS Class
Component Object MMS Variable Name
(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
CASM MMS
CASM Class MMS Class
Component Object MMS Variable Name
(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
CASM MMS
CASM Class MMS Class
Component Object MMS Variable Name
(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
CASM MMS
CASM Class MMS Class
Component Object MMS Variable Name
(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
CASM MMS
CASM Class MMS Class
Component Object MMS Variable Name
(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
CASM MMS
CASM Class MMS Class
Component Object MMS Variable Name
(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
CASM MMS
CASM Class MMS Class
Component Object MMS Variable Name
(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
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.
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.
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.
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.
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).
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.
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.)
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.
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 switching: Automated procedure to manage feeder connectivity changes. See also: automatic switch-
ing sequences.
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.
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.
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.
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:
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.
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 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.
modem: Modulator/demodulator; electronic device that enables digital data to be sent over analog transmis-
sion facilities.
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.
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.
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.
quality of service (QOS): A parameter specifying the level of performance needed for communications,
such as transit delay, priority, accuracy, or reliability.
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.
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.
scale: Multiplier used to convert a value from the measured value to the appropriate units.
security: Immunity of network resources to accidental or intentional unauthorized access. Three levels are
defined:
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.
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.
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.
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.
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.