Scribd
Upload
14 views

Data Object Library

The document discusses application layer communication in DNP3 and IEC 870-5-101 protocols. It explains that in DNP3, application layer fragments can request confirmation that a message was received and parsed without error. Each fragment contains a header with control information like sequence numbers. Function codes indicate the purpose of the message, like read, write, or operate, and apply to all data in the fragment. It also provides an overview of IEC 870-5-101, which is based on the IEC 870-5 standard series and provides structures for communication between devices like RTUs and IEDs.

Uploaded by

alvin me
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
14 views

Data Object Library

The document discusses application layer communication in DNP3 and IEC 870-5-101 protocols. It explains that in DNP3, application layer fragments can request confirmation that a message was received and parsed without error. Each fragment contains a header with control information like sequence numbers. Function codes indicate the purpose of the message, like read, write, or operate, and apply to all data in the fragment. It also provides an overview of IEC 870-5-101, which is based on the IEC 870-5 standard series and provides structures for communication between devices like RTUs and IEDs.

Uploaded by

alvin me
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 1

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.

You might also like