How to Assign DNP3 Points to Event Classes 1, 2, 3
DNP3 gives you three event classes and one static class, and the protocol is completely silent about what belongs in each - that is your design decision, made point by point at commissioning. Done well, class assignment is a priority scheme: urgent things travel first, bulk data travels when there is room. Done by default, everything lands in one class and a chattering analog can delay a trip signal. This guide is a working method for making those assignments deliberately.
Assign DNP3 Event Classes in one line: To assign DNP3 event classes, rank each point by how quickly the master must learn about a change, then map that urgency to classes: class 1 for alarms and protection-relevant status, class 2 for operationally significant analogs, class 3 for slow housekeeping data, and no event class at all for values that only need to appear in periodic snapshots. Poll each class at a rate matching its urgency, and keep noisy points away from the class your alarms live in.
What You Need
You need the full point list for the outstation, an honest ranking of each point's operational urgency, and knowledge of how your master polls: which classes it requests, how often, and whether unsolicited reporting is in play. Class assignment and poll strategy are two halves of one design - a class you never poll is a bucket you never empty.
It helps to know the outstation's event buffer sizes per class, because the buffer a point shares is a consequence of its class. The background on what each scan retrieves is covered in the class data scan explainer; this page is about deciding what goes where.
Rank Points by How Fast the Master Must Know
Go through the point list asking one question: if this changes, how quickly does anyone or anything upstream need to know? Trip statuses, shutdown indications, intrusion and fire inputs, and anything an operator would act on within minutes belong at the top. Process analogs that drive trends, balances, and non-urgent alarms sit in the middle. Runtime counters, cabinet temperatures, battery voltages, and diagnostics sit at the bottom.
Be honest at the top of the ranking. The urgent tier only works if it is small; when half the point list is declared critical, the class carrying it becomes as congested as an unranked design. A useful discipline is to require a named consumer for every top-tier point: who or what acts on this within minutes, and what do they do? No answer means it is not top tier.
Map the Ranking onto Classes 1, 2, and 3
A widely used convention: class 1 carries the urgent tier - alarms and critical status changes; class 2 carries significant analog events; class 3 carries slow housekeeping. The protocol does not enforce this meaning, your polling does: the arrangement only becomes a priority scheme when the master polls class 1 noticeably faster than class 2, and class 2 faster than class 3, or enables unsolicited reporting for class 1 so urgent events push immediately.
Leave points out of event classes deliberately. A value that only needs to exist in periodic snapshots - a configuration echo, a slowly moving totalizer the master reads on schedule - can be static-only, visible to a class 0 poll but generating no events. Every point you exclude from event generation is buffer space and bandwidth returned to the points that matter. Just document the exclusions, because a static-only point that someone later expects to produce events is a classic why-is-my-data-missing ticket.
Keep Noisy Points Away from Your Alarms
Event buffers are shared per class, so a single chattering analog assigned to class 1 competes for buffer space with your shutdown signal. Put chatter-prone points - analogs with tight deadbands, fast-moving process values - in their own class, away from clean urgent status points, so a noise flood can never crowd out an alarm. This isolation is one of the strongest practical arguments for using all three classes rather than lumping everything into one.
The class map also has to respect the buffer arithmetic: a class polled slowly needs either few event sources or a deep buffer to ride out the interval between polls. If a class keeps overflowing, the options are poll it faster, widen deadbands on its members, enlarge its buffer, or move some members elsewhere - the same levers described in the event buffer overflow guide, applied at design time instead of after the loss.
Verifying the Result
After commissioning, watch each class for a week of normal operation. Class 1 should be nearly silent - events there should correspond to genuinely notable occurrences. Class 2 should track process activity. Class 3 volume barely matters as long as its buffer survives its poll interval. Any buffer overflow indication is a design failure worth fixing now, while the reasoning is fresh.
Then run a drill: force a representative alarm point and measure how long it takes to reach the master under normal load. That number - not the design intent - is your actual alarm latency, and it is the figure to compare against what operations expects. If it disappoints, the fix is usually polling the urgent class faster or enabling unsolicited reporting for it, not reshuffling the map.
Frequently Asked Questions
Do DNP3 class numbers imply priority by themselves?
No. Classes 1, 2, and 3 are just labeled buckets; the protocol assigns them no inherent urgency. Priority emerges from how the master treats them - polling one class faster than another, or enabling unsolicited reporting for one and not the rest. The common convention of class 1 as most urgent works only because masters are configured to service it most aggressively.
What happens to a point assigned to no event class?
It generates no events at all. Its current value still exists as static data and appears in class 0 reads such as integrity polls, but no change-of-state history is kept. That is a legitimate design choice for values that only need periodic snapshots - and a notorious source of confusion when someone later expects event history from a point that was deliberately left static-only.
Should all alarms be in class 1?
Genuinely urgent alarms, yes - that is the tier the master services fastest. But resist promoting every annunciation into class 1: the urgent tier protects its members only while it stays small and quiet. Lower-priority notifications can live in class 2 and still arrive within an acceptable time, while leaving class 1 clean for the events where minutes matter.
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.