What It Is
DNP3 represents field information as typed data objects rather than a flat register table. Each data family is identified by object group and variation, and each point is addressed by index within that family.
This matters because a DNP3 point list is only really usable when it preserves the object structure the device exposes. A label by itself is not enough, especially once event classes and control operations enter the design.
Common Object Families
| Family | Typical Use | Why It Matters |
|---|---|---|
| Binary inputs | Status and alarm states | Common for breaker, contact, and digital status reporting |
| Analog inputs | Measurements and telemetry values | Often carry scaling, engineering meaning, and event behavior |
| Counters and frozen counters | Pulse totals, accumulators, and snapshots | Common in utility and flow-style telemetry |
| Binary outputs and control objects | Commands and control actions | Important for select-before-operate and command validation |
Group, Variation, and Index
Three fields usually matter during mapping:
- group: the broad object family
- variation: the precise representation the device exposes
- index: the point position inside that family
If the master asks for the wrong variation or the mapping ignores index detail, the resulting problem can look like bad communications even when the session is otherwise healthy. It also makes event flow harder to validate because the master may be asking for the wrong representation of the same underlying point.
Why This Matters For Point Lists
A good DNP3 schedule usually includes:
- point name
- group
- variation
- index
- event class when relevant
- scaling or engineering meaning
- control notes for writable points
Without that structure, the commissioning team has to reconstruct protocol meaning during testing, which is the wrong time to discover modeling gaps. That usually spills into addressing validation, class polling confusion, and wider commissioning delays.