Lesson 4 of 9

Telemetry: Polling, Report by Exception & Deadbands

A sensor in a substation can measure a voltage many times a second, but the link back to the control room carries only a fraction of that. Every value sent costs bandwidth and energy, and every value received costs the operator some attention, so a large part of telemetry design is deciding which readings are worth sending, and when. Classic SCADA protocols answer with three ideas: polling, report by exception and the deadband.

Polling: the master asks

The DNP3 protocol calls the control-centre computer the master and the device in the field the outstation. The master keeps its own copy of the outstation's values, and the simplest way to keep that copy current is to ask: it sends a request and the outstation answers with the contents of its database. The DNP3 primer calls this polling.

Polling is simple and predictable. Each point is refreshed at a rate the master chooses, and a missing answer is information in itself: something is wrong with the device or the link. The price is that the traffic depends on how many points are polled and how often, not on whether anything has changed, and a change is noticed only at the next poll.

Report by exception: only what changed

Most of the time, most measurements do not change in any way that matters. Report by exception uses that: the outstation compares each value with what it last reported and records an event only when something happens. For a breaker, an event is a change of state. For an analog value such as a voltage, the DNP3 primer describes an event as a change by more than the point's configured deadband, and it lists values exceeding some threshold among the kinds of event. The present value of a point, as opposed to a change, is called static data.

The master then spends most of its time polling for events, which are short and often empty, and only occasionally asks for the static data as an integrity measure. According to the primer, a master is updated faster this way, because few events have accumulated between polls and so little data has to come back.

The deadband: how big a change is worth reporting

A voltage reading wobbles a little from measurement noise alone. If the outstation reported every wobble, report by exception would be polling in disguise. A deadband δ sets the threshold: the sensor sends a new value only when it has moved by at least δ from the value it last sent. The research literature calls the same rule send-on-delta.

The rule has one clean property. On a link that delivers every message at once, the value the control centre holds is, at every sample, less than δ away from the sensor's latest measurement (the measurement, not the true voltage, because the noise stays in). It can also go wrong in two ways. If δ is smaller than the noise, the sensor reports its own noise and the saving disappears. If δ is large, a slow change that stays smaller than δ never triggers a message at all, however long it lasts. The deadband is therefore set per point, to suit the size of the signal and the noise on it.

When silence is ambiguous

Report by exception has a blind spot. No message can mean that nothing changed, that a message was lost, or that the sensor has failed, and the control room cannot tell which. If the one message that announced a voltage dip is lost, the operator's picture stays at normal until something else happens.

The usual remedy is an occasional check of the whole picture. In DNP3 the master now and then asks for the static data, the integrity measure the primer describes (practitioners call it an integrity poll). A sender can also do it by itself: repeat the current value whenever it has been quiet for a fixed time. This lesson and the Sense Lab call that a heartbeat. Either way it costs a few extra messages and buys a limit on how long the control room can be wrong.

Unsolicited reports: not waiting for the poll

Between two polls a change simply waits. A DNP3 outstation can instead transmit a response on its own, without being asked, called an unsolicited response. Not every outstation has this ability. It suits systems where the master needs to hear of a change as soon as possible, but the primer advises that such spontaneous transmissions should generally be infrequent: otherwise there is too much contention for the medium, and controlling access by polling is the better choice.

Polling: The master requests values from the outstation at a rate it chooses, whether or not they have changed.
Static data: The present value of a point, as returned when the master asks for the outstation's whole database.
Event: A change worth reporting: a change of state, or an analog value that has moved by more than its deadband.
Deadband (send-on-delta threshold): How far an analog value must move from the last reported value before it is reported again.
Integrity poll: An occasional request for the static data of all points, to confirm that the master's picture is complete.
Heartbeat: The current value, sent again after a fixed quiet time, so that silence cannot last indefinitely.
Unsolicited response: A report the outstation sends on its own initiative, without waiting to be polled.

Which rule is right depends on the task

What the receiver has to do with the data decides what is worth sending. A trend display or a state estimator needs a regular picture of the values. An alarm needs to know only that a limit was crossed. A rule that sends a message only when the value crosses a level, the idea behind level-crossing sampling, needs very few messages but leaves the receiver with a poor picture of the signal in between. A timer gives a regular picture but can miss a short event that falls between two samples. Neither is better in general: a fair comparison fixes the number of messages, and the link, and then looks at what each rule leaves the receiver knowing.

A small numerical example

In the Sense Lab's default scenario (a synthetic 70 V sag lasting 1.2 s in a 40 s record, a sample every 0.1 s, 60 runs with different noise), a timer that sends every 2 s uses about 21 messages and catches the sag in 36 of 60 runs. Send-on-delta with δ = 8 V needs 3 messages and catches all 60, and so does the level-crossing rule. If the link loses 10 % of the messages, both still send 3 but catch only 54 of 60, because the message that announced the sag was lost in six runs. A heartbeat every 1 s brings that back to 59 of 60, at a cost of 41 messages. The numbers come from a toy model, not from a real network; what carries over is the pattern, not the values.

Why this matters beyond SCADA

A smart grid adds many more sensing points: smart meters, phasor measurement units, inverters and other DER controllers, all reporting over networks of limited capacity. They do not all make the same choice. A PMU, as the PMU lesson in this track explains, streams time-stamped phasors at a fixed reporting rate, a regular picture chosen on purpose, while other points suit reporting by exception. Requirements for data rate, latency and reliability differ widely between smart-grid applications, so there is no single reporting strategy to copy. It is a design decision, made per application, with the cost of lost and late messages in view.

Key takeaways

Polling keeps the master's picture current by asking; report by exception sends only what changed.
A deadband δ decides what counts as a change: too small and the sensor reports its own noise, too large and slow changes go unreported.
Silence is ambiguous under report by exception, so the master still asks for the whole picture now and then (an integrity poll), or the sender repeats its value after a quiet time (a heartbeat).
Unsolicited responses deliver a change without waiting for a poll, but are meant to be infrequent on a shared medium.
No reporting rule is best in general: compare rules at the same message budget, on the same link, for the task the receiver has to do.