45 Sensor Fusion Architectures

45.2 Where Fusion Evidence Combines

A sensor-fusion architecture defines where readings become a shared estimate. In a centralised architecture, sensors send evidence to one fusion process. In a hierarchical architecture, local groups produce intermediate estimates that flow upward. In a distributed architecture, nodes exchange estimates with peers and converge without a single coordinator.

The best architecture depends on latency, bandwidth, failure isolation, time alignment, uncertainty, and review needs. A single central process may give the cleanest global view when the network is reliable. Hierarchical fusion reduces bandwidth and isolates local failures. Distributed fusion is useful when no coordinator can be assumed, but it requires careful handling of duplicated evidence and peer disagreement.

A useful architecture review produces a contract, not only a diagram. It names the fusion owner, input level, clock authority, uncertainty format, duplicate-evidence rule, degraded-mode behavior, and audit record that travels with the output. That contract is what lets a downstream dashboard, controller, or incident review distinguish a fresh global estimate from a local summary or a decision-level vote with hidden disagreement.

The placement decision also controls where bad evidence is stopped. A central service can quarantine raw readings in one place, but it depends on transport and storage capacity. A room gateway can reject stale local sensors before sending a compact state upward, but the building service must still see the rejected-input count and uncertainty. A distributed peer can keep operating during an outage, but it must publish estimate age and conflict state so later convergence is explainable.

Before comparing fusion algorithms, trace Figure 45.1 to locate where sensor observations become a combined claim.

Read Figure 45.1 from sensors through preprocessing and feature extraction into the fusion stage, then continue to the decision and feedback loop. Early stages align units, time, frames, and quality; fusion combines only that prepared evidence; the decision layer applies the result to an operational boundary; feedback tests whether the claim remained useful. The JDL levels describe different abstraction points along the same route. This connects architecture to the running narrative: fusion placement is defensible only when provenance and uncertainty survive every transformation.

The same centralised-versus-decision-level choice shows up inside a single learning task, not just across a building's sensor network. When a mobile-sensing system has readings from several sensors, one design concatenates every sensor's feature vector into a single input and trains one learner on the combined vector; that is centralised, feature-level fusion, and it lets the model learn interactions between sensors directly. The other design trains a separate learner per sensor and combines their individual outputs through an ensemble stage; that is decision-level fusion, and it tolerates one sensor going offline or changing without retraining the whole model, at the cost of discarding cross-sensor interactions the individual learners never see. Neither choice is automatically better: the review should record which pattern was used and why, because it changes what a single failed or drifted sensor does to the fused output.

Overview Knowledge Check

45.3 Match Fusion Pattern to Bottleneck

Start with the bottleneck. If the bottleneck is estimator quality and the network is dependable, centralised fusion may be simplest. If the bottleneck is bandwidth or local resilience, use hierarchical fusion and send state estimates upward. If the bottleneck is intermittent connectivity or organisational boundaries, use distributed or decision-level fusion and treat disagreement as explicit evidence.

Worked example: room-to-building hierarchical fusion
rooms: 50
sensors per room: 4
reading interval: every 10 seconds
raw payload: 32 bytes per sensor reading

centralised raw stream:
50 rooms * 4 sensors * 32 bytes / 10 s = 640 bytes/s

room-level fused state:
one 64-byte room state every 30 seconds
50 rooms * 64 bytes / 30 s = 106.7 bytes/s

building-level summary:
one 128-byte building state every 30 seconds
128 bytes / 30 s = 4.3 bytes/s

hierarchical upstream rate:
106.7 + 4.3 = 111.0 bytes/s

reduction:
1 - (111.0 / 640.0) = 0.827, about 83% less upstream traffic

Design consequence:
The bandwidth saving is useful only if each room state also carries time span,
sensor health, uncertainty, and rejected-input evidence.

The same arithmetic is easier to defend when it is drawn as traffic. Figure 45.2 follows the fifty-room building’s readings up both candidate paths and prices each hop.

Both columns of Figure 45.2 start from the same 50 rooms × 4 sensors source card. The baseline column ships everything for a 640 B/s uplink bill and perfect replay; the tiered column lets each Room gateway compress four readings into a 64 B state every 30 s, adds the Building service roll-up at 4.3 B/s, and lands on 111.0 B/s in total. The amber strip is the clause that keeps the 83% saving honest: every state must still carry its time span, sensor health, uncertainty, and rejected-input counts, because those fields are exactly what the baseline column was implicitly buying with its bandwidth.

Practitioner Knowledge Check

45.4 Fusion Level Sets Audit Trail

Fusion can happen at several abstraction levels. Data-level fusion combines raw or calibrated measurements. Feature-level fusion combines extracted features such as residuals, FFT bands, occupancy counts, or localisation features. State-level fusion combines estimates and uncertainty, such as Kalman filter tracks. Decision-level fusion combines labels, votes, or incident decisions.

Each level loses and gains information. Raw data supports the richest reprocessing but costs bandwidth and storage. Feature and state estimates reduce transport, but they must preserve uncertainty, time span, calibration, and feature version. Decision-level fusion is compact and sometimes necessary across organisational boundaries, but it is the easiest place to hide incompatible labels or weak confidence.

Those levels become easier to audit when each one is written as an input-output signature. The ladder diagram in Figure 45.3 names the five signatures and attaches one concrete transformation to each.

The top rows of Figure 45.3 stay in the data domain: DAI-DAO turns a noisy frame into a cleaner frame with a Gaussian or median filter, and DAI-FEO hands segmentation a raw frame and receives blobs with pixel sizes. Below them, FEI-FEO joins video and audio features for one activity window, FEI-DEO turns a feature vector into a fault label, and DEI-DEO lets two detector verdicts vote. The closing rule condenses the architecture decision into one line — fuse as high on the ladder as the links can afford and only as low as the audit duty permits — because a row once descended cannot be replayed from above.

Worked example: track-to-track covariance check
tracker A position: x = 10.2 m, sigma = 0.4 m
tracker B position: x = 10.4 m, sigma = 0.4 m

If the estimates are independent:
precision for each tracker = 1 / 0.4^2 = 6.25
combined position = (10.2*6.25 + 10.4*6.25) / 12.5 = 10.3 m
combined sigma = sqrt(1 / 12.5) = 0.28 m

If both trackers used the same upstream UWB anchor observation, that 0.28 m
confidence is optimistic because the same evidence was counted twice. The
architecture should mark common sources, correlation assumptions, and any
covariance inflation rule before publishing the fused state.

This is why architecture diagrams should show common sources and summary boundaries, not only arrows. A state-level fusion service needs to know whether two tracks came from independent sensors, from two gateways that shared one anchor, or from two classifiers trained on the same labeled incident set. When independence is unknown, a conservative design keeps the larger uncertainty, flags the common-source path, or routes the fused output for review before it drives actuation.

Under-the-Hood Knowledge Check