How to Connect Two DNP3 Masters to One Outstation
A second master shows up in every fleet's life: a new SCADA platform runs in parallel with the old one during migration, a regional office wants direct visibility, or a monitoring system joins the control system on the same RTUs. Done casually - two pollers pointed at one outstation - it produces the classic mystery of each master seeing half the events. Done properly, with separate associations, it works well. This guide covers the difference.
Two DNP3 Masters in one line: To connect two DNP3 masters to one outstation, the outstation must support multiple master associations, each with its own event buffers and flag state, so that each master's confirms clear only its own copy of the events. Give each master a distinct address and session, decide which one owns controls and time synchronization, and never point two masters at a single shared association - shared-association polling makes each master steal the other's events.
What You Need
You need the outstation's documentation answering one decisive question: does it support multiple concurrent master associations with independent event buffering? Capable RTUs maintain per-association event queues, IIN state, and unsolicited configuration; limited ones accept one master, and some accept two connections while keeping only one event queue - the worst case, because it half-works. This capability, not network reachability, decides the architecture.
You also need an agreed division of authority between the masters before configuration starts: which one commands, which one writes time, and what the second one is actually for. The architectural background on the master-outstation relationship is covered in master-outstation architecture, and the redundancy-oriented variant in redundant polling with dual masters - this page is the configuration procedure for the shared-visibility case.
Configure Separate Associations and Addresses
Give each master its own identity: distinct DNP3 master addresses, and separate sessions - on TCP, typically separate connections, with the outstation configured to map each incoming master to its own association. The addressing layer that makes this unambiguous is described in DNP3 master and outstation addresses. Verify in the outstation's configuration that each association gets its own event buffer allocation, and size both: two masters means the event storage demand doubles, and buffer memory that comfortably served one master may now be tight on both sides.
Configure each association's class polling and unsolicited settings independently, matching each master's actual need - a monitoring master may happily poll slowly with deep buffers, while the operational master polls fast or receives unsolicited pushes. Independence is the point: each master's collection strategy should stand alone, sized as if the other did not exist.
Assign Control and Time Authority to One Master
Decide - and enforce in configuration, not just convention - that exactly one master issues controls. Outstations that accept controls from any connected association will faithfully execute contradictory commands from two systems, and during migrations that is a genuine operational hazard: the old system's operator and the new system's automation each believe they own the site. Where the outstation supports per-association control permissions, disable controls on the secondary association outright.
Give time synchronization a single owner too. Two masters with slightly different clocks alternately writing time produces sawtooth timestamps that corrupt event ordering - each sync snaps the outstation clock to a different reference. Let the master with the best clock discipline own sync, and configure the other to ignore or not service the Need Time indication. Document both decisions in the site record, because they are invisible in casual inspection and their violation looks like unrelated flakiness.
Verifying the Result
Test event independence directly: generate a burst of field events, let master A collect them, and verify master B still receives its full copy on its own schedule. Then reverse the order. If either master's collection empties the other's view, you do not have independent associations - you have the shared-queue failure this design exists to prevent, and the outstation configuration or capability needs revisiting before production.
Then test adversity: drop master B's link for an hour under normal event load and confirm its buffer rides out the outage and backfills on reconnect, without master A noticing anything. Finally, audit the outstation's load - two associations mean two polling streams and up to two unsolicited paths on one CPU and one radio; watch the device's responsiveness during simultaneous integrity polls from both masters, which is the realistic worst case after a regional outage.
Common Mistakes
The classic mistake is the invisible one: pointing a second poller at the same association and concluding DNP3 is flaky because both masters see event gaps. Each master's application confirms clear events the other never saw, so the loss is real, silent, and split between them. Any unexplained event gap on a shared outstation should prompt the question: what else is connected here? A connection log or a capture at the outstation answers it.
The other recurring mistakes: leaving controls enabled on both associations because commissioning was rushed; both masters servicing Need Time; and forgetting that the second association's buffers need the same overflow monitoring as the first - a secondary master that polls slowly with shallow buffers overflows quietly while the primary looks fine. Watch both associations' indications with the same seriousness, because each is a complete, independent DNP3 relationship.
Frequently Asked Questions
What happens if two masters poll the same DNP3 association?
Each master's application confirms clear the shared event queue, so events collected by one are gone before the other polls - both see gaps, roughly complementary halves of the event stream. Static reads still look fine, which is why the problem masquerades as intermittent event loss rather than an architecture error. The fix is separate associations with independent buffers, or a data-distribution layer instead of a second direct connection.
My outstation supports only one master - what are my options?
Put the fan-out upstream: connect the single allowed master or a protocol gateway to the outstation, and let it redistribute data to the second consumer over any suitable northbound interface. This preserves one clean association at the device while giving the second system its feed, and it is the standard pattern for adding cloud monitoring on top of an existing SCADA without disturbing the control path.
Can both masters send controls if operations needs a fallback?
Design it as failover, not sharing: one association carries control authority at a time, with a deliberate, procedural switchover - matching the pattern used for redundant masters - rather than two systems simultaneously enabled. Simultaneous control authority on one piece of field equipment invites contradictory commands, and no interlock at the outstation arbitrates intent between two SCADA systems.
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.