Bus Load Monitoring

Why Availability Monitoring Matters

Frame authentication and integrity controls have no effect against an attacker who simply prevents legitimate communication. CRA Annex I lists availability among the essential cybersecurity requirements; IEC 62443 SR 7.x makes it a system-level property with explicit measurement expectations. On CAN, the easiest availability attack is also the cheapest: flooding the bus with high-priority frames, or driving error-frame storms, until legitimate traffic cannot get through. The same bus-side symptoms also appear under sabotage that is not strictly a cybersecurity attack at all: cutting the wiring, shorting the bus dominant, or injecting indiscriminate high-priority traffic to crowd out the rest. Bus load monitoring is the shell that surfaces this whole family of availability impairment, because the observable signal on the bus is the same regardless of intent. Directed attacks against specific frames or functions are the domain of Anomaly Event Monitoring; the line between the two shells is the line between coarse availability harm and targeted manipulation.

What Gets Monitored

The primary signal is bus load percentage: the fraction of bit time occupied by dominant states on the bus over a measurement window. A practical monitor watches several windows in parallel, for example 100ms, 250ms, and 500ms. Short bursts close to 100% are common in normal operation (a node transmitting a back-to-back burst after an idle period), so a narrow window alone produces false positives; a longer window confirms whether the saturation is sustained. The alert threshold is set per window: brief bursts are tolerated, while seconds of saturation are not. The simplest implementations stop here, working only on bus-dominant time statistics.

Depending on the monitor's capability, an optional secondary signal is error-frame rate on the bus. Error frames are emitted by any node that detects a protocol violation and are visible to every listener, so a snooper that wants to count them can do so directly. Simpler monitors omit this channel and rely on load percentage alone.

Reporting and the Security Event Log

Bus load anomalies should be combined with Anomaly Event Monitoring. Events should carry timestamps, the type of anomaly (sustained load above threshold, error-frame surge where the monitor counts them), and the measurement window that fired the threshold.

Where to Put the Monitor

For higher security levels, place the monitor on a dedicated bus snooper or hardware module with its own trust domain. A compromised node cannot silence what it does not control. For lower-risk products, a hardened software task on an existing node can be sufficient. Either way, the placement and its trust assumptions must be documented in the security justification.

IEC 62443 Reference

This shell directly addresses SR 7.1 (Denial of service protection) and SR 7.6 (Network and security configuration settings) for the bus-load aspect, and supports SR 6.x via the audit-log feed. SR 7.1 SR 7.6

What This Shell Does Not Catch

Bus load monitoring detects coarse availability impairment but does not classify intent: the same alert fires for a targeted DoS, a generic flood, and a cut wire. It also does not look at per-CAN-ID timing or at the content of individual frames. Per-ID frame inter-arrival timing, low-rate stealthy injection (a single spurious frame per second is invisible to a load-percentage threshold), and content-only manipulation of legitimate frames (the load profile is unchanged) are all out of scope here. Pair this shell with Local Injection Detection for per-ID injection alarms, with Anomaly Event Monitoring for directed attacks, frame-timing analysis, and cross-bus correlation, and with Frame Security for prevention of the underlying injection.

Frequently Asked Questions

What does bus load monitoring detect?

Availability impairment on the CAN bus, whether caused by a deliberate availability attack (high-rate flooding, error-frame storms, sustained abnormal load) or by sabotage such as cutting the wiring or shorting the bus dominant. The primary signal is bus load percentage, typically measured over several time windows in parallel (for example 100, 250, and 500 ms) so short bursts close to 100 % are not mistaken for an attack. Simpler implementations track only dominant-state statistics on the bus; more capable monitors also count error frames observed on the bus. Internal TEC and REC counters inside each CAN controller are local to that node and are not shared on the bus, so a global monitor cannot read them. Per-CAN-ID frame inter-arrival timing is not part of bus load monitoring; that belongs to Anomaly Event Monitoring.

Where should the bus load monitor sit?

For higher security levels, on a dedicated bus snooper or a hardware module with its own trust domain so a compromised node cannot silence it. For lower-risk products, a hardened software task on an existing node can be sufficient, but the trust-domain trade-off should be documented in the security justification.