CANopen has two mechanisms for spotting when a node has gone quiet, and they work in opposite directions. Node guarding is the older, master-polled approach: the master repeatedly asks each node for its state, and the node replies with its network-management state and a toggling bit that proves the reply is fresh. Heartbeat is the newer, node-produced approach: each node emits its own state message at a regular interval, and anyone listening notices if it stops arriving. Both derive a node's health and network-management state from the timing of these messages, but heartbeat is generally preferred because it removes some of node guarding's weaknesses when feeding an alarm system.
Node guarding vs heartbeat in one line: CANopen node guarding is a master-polled method where the master requests each node's state and the node replies with its network-management state plus a toggle bit that alternates to prove the response is live. Heartbeat is a node-produced method where each node periodically broadcasts its own state message, and a listener detects a fault if it stops. Heartbeat is generally preferred for reliable dead-node detection.
Node guarding puts the master in charge of checking on its nodes. At a regular interval, the master sends a guarding request to each node it is monitoring, and the node is expected to respond. That response carries two useful pieces of information: the node's current network-management state, which tells the master whether the node is operational, pre-operational or stopped, and a toggle bit that flips between two values on each successive reply. The alternating toggle bit is there to prove that each response is a fresh answer to a fresh request, not a stale or repeated message.
The corresponding safeguard on the node's side is often called life guarding: the node itself expects to be polled within a set time, and if the master's requests stop arriving, the node can conclude that its connection to the master has failed and take a defined action. So node guarding actually provides mutual monitoring, with the master watching for missing replies and the node watching for missing requests, each side using a timeout to decide that something has gone wrong.
The weaknesses of node guarding are what motivated an alternative. Because it is request-and-response, every monitored node generates two messages per cycle, a request and a reply, which adds up to a fair amount of bus traffic when many nodes are guarded frequently. It also ties the health check to the master actively polling, so the scheme leans heavily on the master and its polling behaviour. These drawbacks are manageable, but they made a lighter, node-driven approach attractive as CANopen matured.
Heartbeat turns the monitoring around. Instead of waiting to be asked, each node acts as a heartbeat producer and sends out a message at a configured interval, and that message carries the node's current network-management state. Any device on the bus that cares about the node, typically the master but potentially others, acts as a heartbeat consumer, expecting that message to arrive regularly. If the expected heartbeat fails to appear within the consumer's configured timeout, the consumer concludes the node has failed and can raise the appropriate response.
This one-way, produced approach is simpler and lighter than the request-and-response of node guarding. There is a single message per node per interval rather than a request-reply pair, and there is no toggle bit to manage, because the freshness of the information comes naturally from the message arriving on schedule. The producer and consumer intervals are configured so that the consumer's timeout is comfortably longer than the producer's send interval, giving a little tolerance for a missed or delayed message before a fault is declared.
Heartbeat also decentralises the monitoring nicely. Because a node simply broadcasts its state, more than one consumer can listen to the same heartbeat, so several devices can independently track a node's health from the one message. This fits a design where different parts of a system want to know whether a node is alive without each having to poll it. The state carried in the heartbeat means consumers learn not just that the node is present but what mode it is in, which is exactly the information an alarm or supervisory layer wants.
When the goal is reliable dead-node detection that ultimately drives an alarm, heartbeat has clear practical advantages. Its lighter, one-way traffic scales better across many nodes, and it does not depend on the master faithfully polling everyone, which removes a single point of behaviour that node guarding relies on. For a supervisory layer whose job is to notice quickly and cleanly when a node stops responding, a steady stream of self-announced heartbeats is easy to watch and easy to reason about.
The information a heartbeat carries is also well suited to alarming. Each message reports the node's network-management state, so a consumer can distinguish a node that has gone completely silent from one that is present but has dropped out of operational mode. That distinction matters to an operator: a missing heartbeat suggests a dead or disconnected node, while a heartbeat reporting a non-operational state suggests a node that is alive but not doing its job. Both are worth an alarm, but they call for different responses.
For a cloud SCADA platform, this is where the field-level mechanism connects to operator-facing monitoring. A gateway that consumes node heartbeats knows in near real time which CANopen nodes are alive and what state they are in, and it can forward that status upward so a platform like Merobix can show node health across a site and raise an alert when a heartbeat goes missing. Because heartbeat gives a clean, node-driven signal of both presence and state, it maps naturally onto the kind of communication-fail and status alarms an operator relies on, which is a large part of why it is the preferred choice for modern monitoring.
The toggle bit alternates between two values on each successive guarding response, which proves to the master that the reply is a fresh answer to the latest request rather than a stale or repeated message. Along with the reported network-management state, it lets the master confirm the node is genuinely responding in real time.
Each node periodically broadcasts a heartbeat message carrying its network-management state, and a consumer expects that message within a configured timeout. If the heartbeat stops arriving, the consumer concludes the node has failed. The consumer's timeout is set longer than the node's send interval to tolerate an occasional delayed message.
Heartbeat uses lighter one-way traffic, does not depend on the master polling every node, and can be watched by multiple consumers at once, which makes it scale better and integrate more cleanly with alarm systems. It also reports the node's state, letting a supervisory layer distinguish a silent node from one that is present but not operational.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.