As in the data link layer, application layer fragments may be sent with a request for a
confirmation. An application layer confirmation indicates that a message has not only been
received, but also been parsed without error. (On the other hand, a data link layer confirmation, or
ACK, indicates only that the data link frame has been received and that it passes CRC error
checks.)
Each application layer fragment begins with an application layer header followed by
one or more object header/object data combinations. The application layer header contains an
application control code and an application function code. The application control code
contains an indication if the fragment is one of a multi-fragment message, contains an indication if
an application layer confirmation is requested for the fragment, contains an indication if the
fragment was unsolicited, and contains a rolling application layer sequence number. The
application layer sequence number allows the receiving application layer to detect fragments that
are out of sequence, or dropped fragments.
The application layer header function code indicates the purpose, or requested operation,
of the message. While DNP3 allows multiple data types in a single message, it only allows a
single requested operation on the data types within the message. Example function codes (as
shown in fig. 4) include: Confirm (for application layer confirmations), read and write, select and
operate (for select-before-operate, or SBO, controls), direct operate (for operation of controls
without SBO), freeze and clear (for counters), restart (both cold and warm), enable and disable
unsolicited messages, and assign class. The application layer header function code applies to all
object headers, and therefore all data within the message fragment.
2.6 Data object library
The DNP 3.0 data object library document describes the format of data presented within an
application layer message. A variety of qualifier codes and variations of data permit an
implementation of DNP 3.0 to make optimal use of bandwidth. DNP objects are not general-
purpose objects; they are defined specifically for RTU operation.
2.7 Subset definitions
The DNP 3.0 subset definitions document describes three basic levels of DNP 3.0 objects and
services that can be used to determine interoperability between devices, or to specify a minimum
required level of implementation in a request for proposals. The intended use of these subsets is
as follows:
Level 1 (L1): A minimum implementation, intended for a simple IED.
Level 2 (L2): Intended for a more sophisticated IED or a small RTU.
Level 3 (3): Intended for a larger RTU or data concentrator.
3. IEC 870-5-101 [ref. 1, 4 & 6]
The IEC Technical Committee 57 (Working Group 03) have developed a protocol standard for
telecontrol, teleprotection, and associated telecommunications for electric power systems. The
result of this work is IEC 870-5. Five documents specify the base IEC 870-5. The documents are:
IEC 870-5-1 Transmission Frame Formats
IEC 870-5-2 Data Link Transmission Services
IEC 870-5-3 General Structure of Application Data
IEC 870-5-4 Definition and coding of Information Elements
IEC 870-5-5 Basic Application Functions
IEC 870-5-101 (T101) is a companion standard generated by the IEC TC57 for electric utility
communication between master stations and RTUs. The IEC 870-5-101 is based of the five
documents IEC 870-5-1-- 5. Like DNP 3.0, T101 provides structures that are also directly
applicable to the interface between RTUs and IEDs. It contains all the elements of a protocol
necessary to provide an unambiguous profile definition so that vendors may create products that
interoperate fully.
