Glossary · Subscriptions

Heartbeat

A heartbeat is a client-side or gateway-side watchdog that re-emits a monitored item's last value when the server has reported nothing about it for a configured time. It exists because a subscription with the default DataChangeTrigger is silent both when a value is unchanged and when the source is dead. It is not an OPC UA service.

Why silence is ambiguous

With DataChangeTrigger StatusValue, a tag that has not moved for an hour produces no notifications - and neither does a tag whose device stopped updating. The subscription keep-alive proves the subscription lives, and a session keep-alive proves the server lives, but neither says anything about one particular item. Downstream consumers - historians, MQTT brokers, dashboards - cannot tell steady from gone without a heartbeat.

The timing rule that trips everyone

A heartbeat interval at or below the publishing interval makes the watchdog win the race every cycle: it fires before the server's own notification arrives and re-sends the stale value repeatedly. The correct rule, and what OPC Publisher implements, is to wait the heartbeat interval plus one publishing interval before declaring a node silent. Set the heartbeat to a comfortable multiple of the publishing interval, never to the same value.

The in-protocol alternative

Before building a watchdog, consider DataChangeTrigger StatusValueTimestamp on the items that need proof of life: the server then reports every sample even when the value is identical, giving a real cadence with real timestamps rather than a synthesised one. It costs bandwidth proportional to the sampling rate, which is why heartbeats exist - but for a handful of critical tags it is the more honest option.

Example

Heartbeat timing, wrong and right

PublishingInterval 1000 ms

Heartbeat 1000 ms   watchdog fires at t+1000 just as the server notification lands
                    -> stale value re-emitted nearly every cycle, duplicate timestamps

Heartbeat 30000 ms  declare silent at 30000 + 1000 = 31000 ms since last notification
                    -> real gaps detected, no race with the publishing cycle

Emitted heartbeat value: decide explicitly whether SourceTimestamp is the original
(honest, produces repeated timestamps) or the emission time (smooth, but invented).
The mistake people make: Re-emitting the last value with its original SourceTimestamp into a historian. You get repeated identical timestamps and zero-length gaps that break time-series maths, or - if you stamp emission time instead - a fabricated measurement that nobody downstream can distinguish from a real one. Whichever you choose, flag heartbeat copies so the consumer can tell.

Defined in: Not an OPC UA service; the underlying behaviour is Part 4 - Services, DataChangeFilter and the subscription keep-alive.

Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.

Free download
OPC UA Server Acceptance Test Pack
A 40-check acceptance test you run against a vendor's server before commissioning sign-off. Weighted scoring, three hard gates, and a one-page verdict for the supplier meeting.
Get the free test pack →
Free, no course, no login