How to Commission a DNP3 Outstation Point Map
Every DNP3 integration lives or dies by its point map - the agreement that index 7 of the analog inputs is suction pressure and not discharge. Commissioning is where that agreement gets proven point by point, because a map that is one index off can look plausible for months while every value sits on the wrong tag. This guide is the walk-down procedure for a new outstation: verify the addressing, walk the points, test the controls, and leave an as-built record behind.
DNP3 Point Map Commissioning in one line: To commission a DNP3 point map, start from the outstation's exported point list, verify the master reaches the right device at the right addresses, then walk every point end to end: stimulate each input in the field and confirm the correct index, value, scaling, and event class at the master, then command each control and confirm the correct field action. The deliverable is an as-built point map that matches what was proven, not what was designed.
What You Need
You need the outstation's actual point configuration - an export from the device, not the design spreadsheet - plus the master's mapping, radio or network access, and a field technician who can safely stimulate inputs and observe outputs. Point walking is a two-person, two-location exercise: one at the process, one at the master, on the phone.
You also need the addressing basics confirmed before any point makes sense: the link addresses on both ends must match the plan, and mistakes here produce the especially confusing failure of a master happily talking to the wrong outstation. The addressing scheme is covered in DNP3 master and outstation addresses; verify it first, because every subsequent check assumes it.
Verify Addressing and Take a Baseline Snapshot
Connect, confirm the session establishes, and run an integrity poll to capture the full static image. Compare the returned point counts per type against the export: if the device reports fewer or more points than the map expects, resolve that before walking anything - a truncated map usually means a configuration was only partly loaded, and an oversized one means defaults are padding the list.
Sanity-check the snapshot against the process: values that should be live (pressures, temperatures) should look plausible, and values that should be static should be static. Ten minutes reading the baseline against reality catches transposed analogs before anyone drives to the far end of the site. How points are indexed within each type - and why analog input 7 and binary input 7 are unrelated points - is described in the DNP3 point index explainer.
Walk Every Input End to End
Stimulate each input at the field end and confirm at the master: the right index changed, the value is correct in engineering units, and the change produced an event in the expected class. For binaries, exercise both transitions - a stuck-open contact passes a one-way test. For analogs, use at least two well-separated stimulus values so scaling errors show up as slope, not just offset; a live process value alone cannot distinguish correct scaling from two errors canceling.
Check the variation each analog returns while you are there - a point mapped for 32-bit or floating-point delivery that actually returns a 16-bit variation will clip large values in a way commissioning-day values may not reveal; the mechanics are covered under object groups and variations. Log every discrepancy in a punch list as you go rather than fixing mid-walk, so the walk itself stays systematic and nothing gets a second undocumented change.
Test Controls with the Process Safe
Command every control point and confirm the correct field device acts - with the process in a state where the action is safe, under a permit where site rules require one, and with the field technician watching the equipment rather than the RTU. Controls deserve the same index skepticism as inputs: a command that operates the wrong pump is worse than one that fails, and it reports success. Where select-before-operate is configured, verify the full sequence works over the real link, not just direct operates from a bench tool.
Test the refusal paths too: put the device in local mode and confirm remote commands are properly rejected, then restore remote authority. A control that works when it should is half the test; a control that refuses when it should is the other half, and the half that protects field crews.
Verifying the Result and Documenting As-Built
Close with a second integrity poll and a comparison against the punch-list-corrected map: every point accounted for, every discrepancy resolved or formally accepted. Let the system run for a day and review the event log - points that chattered through the soak need deadband or debounce attention now, while the crew is still mobilized.
Then write the as-built: the point map as proven, with indexes, descriptions, units, scaling, classes, deadbands, and control behaviors, stored where the next integrator will find it. The as-built map is the single most valuable artifact this procedure produces - every future troubleshooting session, historian question, and master migration starts from it, and the sites that skip it pay for the omission for years.
Frequently Asked Questions
Do I really have to walk every point?
For a new outstation, yes - the whole failure mode this procedure exists to catch is the plausible-looking map with one systematic error in it, and sampling does not catch systematic errors reliably. For a change to an existing proven map, walking the changed points plus a spot-check of neighbors is a defensible scope. The judgment call should be recorded either way.
What is the most common error found during point walking?
Index misalignment - the field wiring or device configuration differs from the design spreadsheet by an insertion or deletion, shifting a block of points by one. Everything looks alive and plausible, but a range of tags carries its neighbor's value. Two-value analog tests and both-transition binary tests expose it quickly; glancing at live values does not.
Should commissioning use the real master or a test tool?
Both, in that order of authority: prove the map against the production master or gateway, because that is the configuration that must be right, and use a portable test tool for bench pre-checks and for isolating disagreements - when the tool and the master see different things, the difference localizes the fault to the master's mapping rather than the outstation. Time on the production path is the time that counts.
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.