What It Is
DNP3 addressing is the application-layer identity model that tells each endpoint who is talking and who the message is meant for. It is central to both serial and TCP deployments.
This matters because a network path can be fully reachable while the DNP3 session still fails if the endpoints disagree about identity. Addressing also has to stay aligned with the project’s roles and levels assumptions.
Where Addressing Shows Up
| Context | Why It Matters |
|---|---|
| Serial multidrop links | Distinguishes devices that share one physical segment |
| DNP3 TCP links | Still required even though the transport is IP-based |
| Gateway and protocol conversion work | Must align protocol identity with the upstream and downstream design |
What A Good Addressing Schedule Includes
A usable addressing schedule usually includes:
- master address
- outstation address
- transport path details such as serial line settings or IP endpoint
- device role
- any related point-index or object-model notes needed during commissioning
If the schedule only lists IP addresses or only lists device nicknames, it is not yet a complete DNP3 addressing handoff. It also makes control operations and event flow harder to validate later.
Common Failure Modes
- master and outstation addresses are reversed
- the field device is configured for a different address than the engineering schedule
- TCP routing is correct, but DNP3 application-layer identity is still wrong
- multidrop assumptions are copied from another segment without verification