What Is the DNP3 Application Layer?

Back to Blog

The Application Fragment Structure

An application-layer message is called a fragment. It begins with an application control byte - carrying FIR/FIN bits for multi-fragment responses, a confirm-requested bit, and an application sequence number - followed by a function code. In a response, a two-byte internal indication field comes next. After that come one or more object headers, each naming an object group, a variation, and a range of points, followed by the point data itself.

That structure is why the same conceptual response can be encoded many ways. The object headers pull directly from the DNP3 object groups and variations model, so the group and variation you choose determine whether a value arrives with a timestamp and flags or as a bare number. Point numbering inside a group follows the DNP3 point index scheme.

Function Codes and Internal Indications

The function code is the verb of a DNP3 message. A master sends read, write, direct operate, select, operate, cold restart, and more; an outstation replies with response or unsolicited response. These verbs are covered in their own right by the DNP3 function code concept, and they are how one page distinguishes a poll from a command from a restart request.

Every outstation response also carries the DNP3 internal indication (IIN) field, two bytes of status bits that ride along with the answer. Those bits tell the master about buffer overflow, a device restart, a need for time, and other conditions - so a master reads not only the data it asked for but a health report on every reply. The application layer is therefore where both the data and the device state surface together.

Fragments, Segments, and Frames: Who Splits What

DNP3 splits a large message more than once on the way down the stack, and the vocabulary keeps the layers straight. The application layer produces fragments, each one a parseable unit with its own control byte and headers. The DNP3 transport function then chops a fragment into segments small enough to fit link frames, and the data link layer wraps each segment in a frame with source and destination addresses plus CRC protection. Reassembly runs the same path in reverse at the receiver, and only a completed fragment reaches the application parser.

The practical consequence is that one "message" in a protocol analyzer is often many frames, and trouble at different layers looks different. CRC failures point at the physical channel - noise, wiring, a marginal radio path. A fragment that starts arriving but never completes points at transport reassembly or at a mismatch in the maximum fragment size configured on each end. Since an integrity poll of a large outstation routinely spans several fragments flagged with FIR and FIN bits, a size mismatch tends to surface on exactly the polls that matter most.

Confirms, Retries, and Sequence Numbers

The application control byte carries a CON bit that requests an application-layer acknowledgement. An outstation typically sets it on responses that carry event data: the master must reply with a confirm before the outstation will clear those events from its buffer. If confirms go missing, events are retransmitted or the buffer creeps toward overflow, so a link that seems healthy on static data can still be quietly failing its event traffic. The mechanics and the failure symptoms are covered in the DNP3 application confirm page.

Application sequence numbers let each side pair confirms with the fragments they acknowledge and discard duplicates after a retry. Keep the application confirm distinct from the link-layer confirm, which acknowledges individual frames one layer down: running both on the same channel doubles the acknowledgement traffic for little benefit, and the usual engineering choice is application confirms for event data with link confirms left off. Whichever combination a channel uses, both ends must be configured to match, and that decision belongs to whoever engineers the channel as a whole.

Reading a Poll in a Protocol Capture

A worked symbolic example ties the structure together. A master's class poll is a request fragment with the read function code and an object header naming group 60 - variation 1 requests class 0 static data, and variations 2, 3, and 4 request event classes 1, 2, and 3. The request carries no point data at all, because it only names what it wants. The outstation's response fragment answers with concrete headers: perhaps a binary-input event group in a time-tagged variation, then an analog group, each header stating group, variation, qualifier, and range, followed by the points themselves.

A decode order that keeps you oriented in a capture:

1. Find the function code to learn the verb: read, write, select, operate, or response.
2. Read the application control byte for FIR, FIN, CON, and the sequence number.
3. On responses, decode the two IIN bytes before anything else - they flag restarts, buffer trouble, and time-sync needs.
4. Walk the object headers in order: group, variation, qualifier, range.
5. Only then interpret point values, using the variation to know the encoding.

Practicing on live traffic is the fastest way to internalize this, and capturing DNP3 traffic in Wireshark shows how to get a clean capture to work with.

Frequently Asked Questions