How to Run a General Interrogation on IEC 60870-5-104
A general interrogation is IEC 104's full re-synchronization: the master asks the outstation for the current state of everything, and the outstation replies with the complete picture. It is the mechanism that turns a fresh connection into a trustworthy database and repairs the damage after an outage - and it is also a burst of traffic that should be triggered for reasons, not on reflex. This guide covers when to run one, what the exchange should look like, and how to know it worked.
IEC 104 General Interrogation in one line: To run an IEC 104 general interrogation, the master sends the interrogation command to the station's common address after data transfer is started; the outstation answers with an activation confirmation, then the current value of every interrogation-relevant point marked with the interrogated-by cause, and closes with an activation termination. Trigger it at session start, after outages and restarts, and on a modest periodic schedule as a divergence backstop - not as the routine data path.
What You Need
You need a session with data transfer active - STARTDT confirmed - because an interrogation into a stopped connection goes nowhere. You need to know the outstation's common address, and whether your system uses station interrogation only or also the group variants, which partition points into subsets that can be refreshed independently. Group membership is configured at the outstation, and using groups without knowing the membership refreshes something other than what you intended.
Have a capture or protocol log visible the first few times, so the sequence below is something you have watched rather than read about. The cause-of-transmission values are the checkpoints of the whole procedure; their vocabulary is laid out in the COT explainer.
Trigger It at the Right Moments
Run a general interrogation whenever the master's image of the station is or may be stale: immediately after connection establishment and STARTDT, after any communications outage, after an outstation restart or local configuration change, and when error causes or gaps suggest the database has diverged. These are the event-driven triggers, and a well-configured master fires them automatically - the same recovery philosophy as the DNP3 integrity poll described in the integrity poll explainer, translated into 104's vocabulary.
On top of the triggers, most systems schedule a periodic interrogation as a backstop against silent divergence - the cadence is a bandwidth decision, from hourly on capable links to daily on constrained ones. What the schedule should never become is the primary acquisition path: a master that learns about changes mainly through interrogations is paying full-image cost for change-sized information, and spontaneous reporting configuration deserves the attention instead.
Read the Sequence as It Runs
The exchange has a fixed grammar. The master sends the interrogation command (type C_IC_NA_1) with the activation cause to the station's common address, qualifier selecting station or a specific group. The outstation returns the same command with activation confirmation - the receipt. Then the data flows: every point in scope, sent with the interrogated-by cause that distinguishes this snapshot traffic from spontaneous changes arriving in parallel. Finally the outstation sends activation termination: the snapshot is complete.
Each checkpoint diagnoses its own failures. No confirmation: the command did not land or the device refuses interrogations - check session state and profile. Confirmation but thin data: points are excluded from interrogation scope at the outstation, a configuration surprise worth chasing point by point. Data but no termination: the device is lax about termination or was interrupted mid-sequence - and without termination the master cannot strictly know the snapshot ended. Spontaneous values with fresher timestamps arriving mid-interrogation should win over the snapshot's older ones; correct masters handle this ordering, and captures of a busy interrogation are where you verify yours does.
Verifying the Result
After termination, audit the database: every expected point updated with a fresh quality and timestamp, no stale flags remaining, and spot-checked values agreeing with the field or the local HMI. Points that stayed stale through an interrogation are excluded at the outstation or missing from its configuration - a mapping issue, not a comms issue, and the finding transfers to the punch list.
Then verify the automation: drop and restore the connection in a test window and confirm the master runs the full sequence unprompted - reconnect, STARTDT, interrogation, termination, database fresh. Manual interrogations rescuing stale data is a workaround culture; the triggers belong in configuration. For fleets feeding a central platform, that automated recovery is what keeps historian gaps bounded to the outage itself, the operational pattern described in connecting IEC 60870 stations to cloud SCADA.
Common Mistakes
The classic operational mistake is interrogation-as-polling: a short-cycle scheduled GI carrying the routine load because spontaneous reporting was never configured properly. It works, at many times the necessary traffic, and it buries the change events' timing information inside snapshots. The opposite mistake is trusting event-driven triggers exclusively: without any periodic backstop, one missed transition leaves the master divergent until someone notices a value that cannot be right.
The sequencing mistakes: interrogating before STARTDT (silence, then confusion); firing interrogations at every station simultaneously after a regional outage and saturating the shared network with the reconnect storm - stagger them; and treating the group mechanism casually, refreshing group 3 while believing it covers the whole station. When groups are in play, keep the membership documented next to the point map, because it is invisible on the wire until the response is thinner than expected.
Frequently Asked Questions
Does a general interrogation return event history?
No - it returns present state: the current value of each point in scope, marked with the interrogated cause. Changes that occurred and were transmitted spontaneously during an outage the connection missed are gone unless the device buffers them; the interrogation rebuilds a correct now, not the missing history. That is why spontaneous reporting and the interrogation are partners rather than alternatives: one carries the story, the other restores the baseline.
How long should a general interrogation take?
It scales with point count and link speed - from moments on a small station over Ethernet to noticeable stretches for thousands of points over constrained links. The practical concern is not the duration itself but concurrency: interrogation traffic competes with spontaneous data and with other stations' recovery on shared infrastructure. Measure yours at busy hour once, then treat significant growth in that time as a symptom worth investigating.
What are interrogation groups for?
They partition a station's points into subsets that can be refreshed independently - useful when one process area changes frequently or when full-station interrogations are too heavy for the link. The membership lives in outstation configuration and must be documented, because a group interrogation looks identical on the wire apart from its qualifier, and refreshing the wrong subset produces exactly the kind of partially-stale database that is hardest to notice.
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.