A 1% threshold froze the 138 kV bus on the SCADA: same rule, wrong voltage level
A SCADA does not store every analog value an RTU sends. It keeps a value when it moved by more than a threshold (often called a deadband in the SCADA) since the last value it kept, and drops the rest. Set too low, the historian fills with noise. Set too high, the screen stops moving while the field keeps changing. A percentage applied to every point of a type looks like a safe default. On voltages from different levels it is not.
The setup
A substation RTU reports two bus voltages as 16-bit integers (raw counts): the 138 kV bus on analog input 0 and the 13.8 kV bus on analog input 1. The SCADA converts them with a scale factor of 0.01 kV per count for the 138 kV point and 0.001 kV per count for the 13.8 kV point, so both read about 13,800 counts at nominal. The RTU's own deadband is 10 counts: it reports every change of 0.1 kV on the 138 kV bus and of 10 V on the 13.8 kV bus. In the SCADA, a threshold of 1% of nominal was applied to every analog voltage during commissioning, and never checked per voltage level.
Operators then reported that the 138 kV bus voltage "does not update". The RTU and the link were checked and found fine. Two hours of traffic were captured.
Raw counts against engineering units
The capture carries the raw value the RTU sends, not the kV the SCADA displays. To replay the SCADA's threshold on it, convert it to counts with the same scale factor:
| 13.8 kV bus | 138 kV bus | |
|---|---|---|
| 1% of nominal | 0.138 kV | 1.38 kV |
| Scale factor | 0.001 kV/count | 0.01 kV/count |
| Threshold in raw counts | 138 | 138 |
The same 138 counts on both points, and that is the trap: the number looks identical in the configuration, while it means 138 V on one bus and 1.38 kV on the other.
What the capture shows
| 2 hours | 13.8 kV bus | 138 kV bus |
|---|---|---|
| Updates sent by the RTU | 2,003 | 874 |
| Range in the field | 13.51 to 14.09 kV | 136.75 to 139.23 kV |
| Updates the SCADA keeps at 1% | 19 | 1 |
| Worst gap between screen and field | 0.14 kV (1%) | 1.29 kV |
- The 138 kV bus moved through almost 2.5 kV in two hours, in slow swings of about ±1.1 kV. None of them passed 1.38 kV from the last kept value, so the SCADA kept the first value and nothing else. The screen showed 137.94 kV for two hours.
- The 13.8 kV bus, with the same 1%, kept 19 values and never strayed more than 0.14 kV from the field. For a distribution feeder, that is an acceptable picture.
- The data was never lost: every update is in the capture, on time. The problem is entirely in what the SCADA decided to keep.
What to set
| 138 kV bus | Threshold | Kept in 2 h | Worst gap |
|---|---|---|---|
| As commissioned | 1% (1.38 kV, 138 counts) | 1 | 1.29 kV |
| Corrected | 0.2% (0.28 kV, 28 counts) | 53 | 0.27 kV |
- Set analog thresholds per voltage level, from the accuracy the operators need on that level, not as one percentage for the whole database.
- Check them in raw counts against a real capture before going live. A threshold that is right in kV and wrong in counts (or the other way round, after a scale factor change) is one of the most common commissioning errors.
- The RTU's deadband and the SCADA's threshold stack: the RTU decides what is sent, the SCADA decides what is kept. Look at both.
Try it on your own capture
ComputingSphere DNP3 replays any analog point of a capture through a threshold you choose, in the same raw counts the RTU sent, and shows the field value against what the SCADA would have kept, with the count of updates dropped. It only reads what already went over the wire. This capture is among the examples of every free account, to reproduce every number here; or upload your own: the Free plan covers 1,000 messages a month.