The Protocol Gap
Utility and energy environments are dominated by DNP3 - IEEE 1815-2012. Substations, remote terminal units (RTUs), and grid infrastructure communicate using a protocol designed for reliability over constrained, high-latency links. Yet most industrial data platforms either ignore DNP3 entirely or treat it as a generic TCP data source.
The result: utility-grade SCADA data is excluded from the Unified Namespace, isolated in legacy historians, and inaccessible to modern analytics and AI systems.
What DNP3 Requires
DNP3 is not a simple request-response protocol. A correct implementation must handle:
- Application layer fragmentation - messages span multiple transport frames
- Unsolicited responses - outstations push event data without being polled
- Class-based data organization - Class 0 (static), Class 1/2/3 (events) with different priorities
- Outstation restart detection - IIN1.7 bit indicates the outstation has restarted and needs integrity poll
- Multiple transport modes - TCP, serial, and TLS with different framing requirements
A generic MQTT or OPC UA adapter cannot handle these semantics. DNP3 requires a purpose-built master station implementation.
Polling vs Unsolicited
DNP3 supports two fundamental data acquisition modes:
Polling mode operates like traditional SCADA - the master sends integrity and event polls at configured intervals. This is predictable and works well for static data (Class 0) and periodic status updates.
Unsolicited mode inverts the relationship - the outstation pushes event data (Class 1/2/3) to the master as events occur. This reduces latency for critical state changes and reduces unnecessary polling traffic over constrained links.
In practice, most deployments use both: unsolicited for real-time events and periodic integrity polls to ensure state consistency. The data plane must handle both modes simultaneously, per endpoint.
UNS Integration
Bringing DNP3 data into the Unified Namespace requires mapping DNP3's point-based addressing into the ISA-95 hierarchy:
- DNP3 points (binary inputs, analog inputs, counters) become tags in the namespace
- Outstation identity maps to the asset level (substation, RTU, feeder)
- Class membership determines update behavior and priority
- Quality flags (online, restart, local forced) map to the standard quality indicator
Once mapped, DNP3 data is indistinguishable from data acquired via OPC UA, Modbus, or any other protocol - it carries the same schema, the same quality metadata, and the same namespace context.
What Changes
When DNP3 data enters the Unified Namespace at the first mile:
- Substation telemetry joins the same data plane as generation, transmission, and distribution data
- Fleet-wide queries work across DNP3, Modbus, and OPC UA sources without per-protocol logic
- AI and analytics systems receive structured, contextualized utility data - not raw point values
- Durable buffering handles the intermittent connectivity that defines utility WANs
The protocol that connects to the device is an acquisition detail. The namespace is the contract. DNP3 belongs in that contract.