How to Enable DNP3 Unsolicited Reporting Correctly
Unsolicited reporting turns a DNP3 outstation from a device you interrogate into one that speaks up on its own - the right design for quiet remote sites on expensive links. It is also the DNP3 feature most often left half-configured, because it must be enabled coherently at both ends and re-negotiated after every outstation restart. This guide is the commissioning procedure: enable it, prove the handshake, and leave a safety net behind.
Enable DNP3 Unsolicited in one line: To enable DNP3 unsolicited reporting, configure the outstation to generate unsolicited responses for the chosen event classes, configure the master to permit them and to send the enable-unsolicited request when the session starts, and verify the restart handshake: after a reboot the outstation announces itself with a null unsolicited response and holds event data until the master re-enables it. Keep a slow backup poll so a silent failure of the unsolicited path degrades to delayed data instead of no data.
What You Need
You need configuration access to both the outstation and the master, and the device profiles for each - unsolicited support, per-class enablement, retry behavior, and confirm timeouts all live in device-specific settings even though the mechanism itself is standard. Decide up front which event classes will report unsolicited; a common pattern pushes the urgent class immediately while bulk classes wait for routine polls.
Understand the moving parts before touching them: the outstation transmits unsolicited responses on its own initiative, the master must acknowledge them with application confirms, and after any restart the outstation opens with a null unsolicited response - an empty announcement that says I am here, re-enable me. Each of those three behaviors has a configuration knob, and all three must agree.
Configure the Outstation Side
Enable unsolicited generation per class on the outstation, and set the transmission triggers: most devices send when a number of events accumulate or a holdoff time passes since the first pending event, whichever comes first. Tight triggers give low latency and more transmissions; loose triggers batch events efficiently at the cost of delay. Set them from the operational need of the class - urgent classes tight, housekeeping loose - and from what the link tariff tolerates.
Configure the retry behavior deliberately: how long the outstation waits for the master's confirm before retransmitting, and how many retries before it gives up and holds events for polling. On high-latency links the confirm timeout must exceed the real round trip with margin, or the outstation will retransmit into a link that was about to deliver the confirm, doubling traffic exactly when the link is slowest.
Configure the Master and Prove the Handshake
On the master, permit unsolicited responses from this outstation and configure the session-start sequence: masters conventionally disable unsolicited, run an integrity poll to baseline the database, then enable unsolicited for the agreed classes. Confirm the master sends application confirms for every unsolicited response carrying events - without confirms the outstation cannot clear its buffer, and you get duplicate events followed by overflow, the failure chain described in the application confirm explainer.
Now prove the restart handshake, because this is where half-configured systems fail: power-cycle the outstation in a test window and watch the sequence - null unsolicited announcement from the outstation, integrity poll and enable-unsolicited from the master, then normal event flow. If the master ignores the announcement, the outstation will sit politely silent forever, which is the single most common way unsolicited reporting dies in production and stays dead until someone notices the data stopped.
Verifying the Result
Force a field event and measure the path: it should arrive at the master within the outstation's holdoff time plus link latency, without any poll having asked for it. Then verify under adversity - drop the link, generate events during the outage, restore, and confirm the buffered events arrive and the historian backfills. Finally repeat the restart test end to end and watch the re-enable happen automatically.
Leave a backup poll running - a slow supervisory poll every few minutes to tens of minutes per site economics. Its job is not data collection but failure detection: if the unsolicited path silently degrades, the backup poll both retrieves the stranded events and, by suddenly returning full buffers, tells you the push path needs attention. Alarm on that condition rather than merely absorbing it.
Common Mistakes
The classic: enabling unsolicited on the outstation and never configuring the master to permit and re-enable it - events then arrive only when a poll happens by, and everyone wonders why latency is minutes instead of seconds. Its sibling: a master that enables unsolicited but never confirms, filling the log with duplicates until the buffer overflows. Both are visible in one protocol capture, which is the first thing to collect when unsolicited behaves oddly.
The design mistake is pushing everything: unsolicited reporting for every class on a chatty outstation just moves the flood from poll responses to spontaneous traffic. Pair unsolicited enablement with honest deadbands and class assignments so the pushed stream is genuinely the important minority. And record the whole arrangement - classes, triggers, timeouts, direction - in the site documentation, because unsolicited configuration is precisely the kind of two-sided agreement that a later device swap breaks silently.
Frequently Asked Questions
Why does unsolicited reporting stop after every outstation restart?
By design, an outstation restarts with unsolicited reporting disabled and announces itself with a null unsolicited response, waiting for the master to re-enable it. If the master does not respond to the announcement with an enable-unsolicited request, the outstation buffers events and stays quiet indefinitely. Fix the master's restart handling and the symptom disappears - a manual poll rescuing the data each time is the workaround, not the fix.
Do I still need to poll if unsolicited reporting is enabled?
Keep two kinds of polls: an integrity poll at session start and on recovery events to baseline the static picture, and a slow supervisory poll as a safety net for the unsolicited path. The supervisory poll turns a silent unsolicited failure into delayed data plus a detectable symptom - buffers arriving full on a poll that should have found little - instead of an invisible gap.
Which event classes should report unsolicited?
Push the classes whose latency matters - typically the urgent class carrying alarms and critical status - and let bulk classes ride routine polls. Pushing everything sacrifices the bandwidth advantage that justified unsolicited reporting in the first place. The split should mirror your class assignment design: if a class was worth polling fast, it is a candidate for pushing; if it was polled slowly, polling it slowly remains fine.
Sources and verification
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
- Overview of DNP3 (IEEE Std 1815) - DNP Users Group
Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.