17 Sensor Fusion Architectures
17.1 Start With the Story
Picture an IoT team using the ideas in Sensor Fusion Architectures during a live operations review. A device has produced messy evidence, an analytic step is about to change an alert or control decision, and someone has to explain why the result should be trusted.
Read this page as that path from sensor evidence to accountable action. Start with what the system observes, keep the model or data treatment visible, and finish with the check that would convince an operator, maintainer, or auditor to act.
17.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.
If the architecture cannot explain which sensors contributed, when they were observed, and how uncertainty was combined, the fused estimate is difficult to trust even when the algorithm is sound.
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.
Centralised
All raw or lightly processed evidence reaches one fusion service with a global state view.
Hierarchical
Local fusion nodes summarise nearby sensors, then send estimates upward by room, floor, zone, or asset.
Distributed
Peers share estimates or beliefs and update locally without depending on one central service.
Decision-Level
Independent detectors or classifiers vote, arbitrate, or escalate when raw evidence cannot be shared.
Overview Knowledge Check
17.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.
Practitioner Knowledge Check
17.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.
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.
Data Level
Combines measurements before feature extraction, often after calibration and time alignment.
Feature Level
Combines derived features while preserving feature schema, window, and sensor coverage.
State Level
Combines estimates, tracks, covariance, and confidence from local filters or trackers.
Decision Level
Combines alarms, classes, votes, or abstentions when lower-level evidence is unavailable.
Under-the-Hood Knowledge Check
17.5 Summary
Sensor-fusion architecture determines where data, features, states, or decisions are combined. Centralised fusion gives one service a global view but depends on network and coordinator reliability. Hierarchical fusion reduces upstream traffic and isolates local failures when summaries carry time, uncertainty, and health evidence. Distributed fusion avoids a single coordinator but must handle peer disagreement, clock differences, and duplicated evidence. Decision-level fusion is compact, but it requires explicit label definitions, confidence, abstain rules, and voting policy.
Choose the fusion architecture by the bottleneck: estimator quality, bandwidth, latency, coordinator reliability, privacy, or auditability. Every fused output must preserve timing, uncertainty, contributing evidence, and rejection metadata.
17.6 See Also
Data Fusion Introduction
Review why multiple sensors are combined and what evidence must travel with the fused value.
Kalman Filters
Use state and covariance when fusing estimates over time.
Complementary IMU Fusion
Place fast and slow sensor corrections in a practical embedded fusion design.
Fusion Best Practices
Keep calibration, time alignment, uncertainty, and fallback behavior reviewable.