After completing this chapter, you will be able to:
Imagine you have several sensors in a room – a thermometer, a motion detector, and a light sensor. Each one gives you a piece of the puzzle about what is happening. Sensor fusion is the process of combining these readings to get a more complete and accurate picture. The key question is: where do you combine them? You could send all raw data to one powerful computer (centralized), let each sensor make its own decision and then vote (distributed), or organize sensors into teams that summarize their findings before passing them up to a coordinator (hierarchical). Each approach has trade-offs in speed, reliability, and accuracy.
Centralized
Pros: Optimal fusion and the simplest processing pipeline.
Cons: Single point of failure with the highest bandwidth demand.
Best fit: Small-scale systems with dependable backhaul.
Distributed
Pros: Scalable, fault-tolerant, and efficient on the network.
Cons: More coordination logic and less globally optimal fusion.
Best fit: Large IoT networks spread across many nodes.
Hierarchical
Pros: Balanced accuracy, modular deployment, and manageable bandwidth.
Cons: Moderate system complexity across tiers.
Best fit: Smart buildings, campuses, and smart city rollouts.
A university deploys 800 environmental sensors across 12 buildings to monitor HVAC efficiency. Each sensor (BME680) reports temperature, humidity, pressure, and VOC every 30 seconds. The campus facilities team needs fused “comfort index” values per room, per floor, and campus-wide.
Data volume calculation:
Architecture A: Centralized – All 800 sensors send raw data to one campus server.
| Metric | Value |
|---|---|
| Network bandwidth | 64.5 MB/day (0.75 KB/s sustained) |
| Server compute | 2,304,000 readings/day, single Kalman filter instance |
| Latency (sensor to decision) | 2-5 seconds (network + queue + processing) |
| Failure impact | Server down = zero monitoring for all 12 buildings |
| Infrastructure cost | 1 server ($3,000) + campus-wide network backhaul |
Architecture B: Distributed – Each sensor independently computes its own comfort index and broadcasts its decision.
| Metric | Value |
|---|---|
| Network bandwidth | 9.2 MB/day (each sensor sends a 4-byte decision packet instead of 28 raw bytes: 86% reduction) |
| Edge compute | Each sensor runs local threshold logic (fits in 64 KB RAM) |
| Latency (sensor to decision) | <100 ms (local processing) |
| Failure impact | 1 sensor fails = 1 room unmonitored, rest unaffected |
| Infrastructure cost | $0 additional (runs on sensor MCU) |
Problem: No cross-room correlation. Cannot detect that Building A’s HVAC is pulling cold air into Building B through connected ductwork because each sensor only sees its own room.
Architecture C: Hierarchical – Sensors fuse per-room (4-8 sensors each), room nodes fuse per-floor, floor nodes fuse per-building.
| Metric | Value |
|---|---|
| Network bandwidth | 10.8 MB/day (room-level aggregates sent up, 83% reduction from centralized) |
| Compute distribution | Room: simple averaging (MCU). Floor: anomaly detection (Raspberry Pi). Building: cross-floor optimization (edge server) |
| Latency (sensor to room decision) | <200 ms |
| Latency (sensor to campus decision) | 3-8 seconds |
| Failure impact | Room node fails = 1 room dark, floor/building still functional |
| Infrastructure cost | 100 room gateways ($50 each = $5,000) + 12 building servers ($500 each = $6,000) = $11,000 |
Decision: The campus chose Architecture C (Hierarchical) despite higher infrastructure cost because:
6-month result: Hierarchical fusion detected that Buildings 3 and 7 shared a return air plenum, causing temperature oscillations (Building 3’s heater triggered Building 7’s cooler in a feedback loop). Fixing the plenum damper saved $14,200/year in energy waste – an insight impossible with per-sensor distributed fusion and discovered within 2 weeks of enabling cross-building correlation at the campus level.
The bandwidth savings from hierarchical aggregation are substantial. Raw data transmission (Architecture A):
\[\text{Bandwidth} = 800 \text{ sensors} \times 28 \text{ bytes/reading} \times 2 \text{ readings/min} = 44,800 \text{ bytes/min}\]
Daily bandwidth: \(44,800 \times 1440 = 64.5\) MB/day or 23.5 GB/year.
Hierarchical aggregation (Architecture C) reduces this through three stages:
Total bandwidth after aggregation: \(64.5 \text{ MB} \div 6 \approx 10.8\) MB/day. Over 3 years, the bandwidth saving is:
\[\text{Saved} = (23.5 - 3.9) \times 3 = 58.8 \text{ GB}\]
At $0.09/GB for cellular IoT data plans, hierarchical fusion saves $1.76/year in bandwidth alone – modest, but the real payoff is in analytics. The $11,000 infrastructure investment pays for itself in under 10 months solely from the $14,200 annual HVAC energy savings, not counting bandwidth.
Latency budget: Room decision in <200ms. Campus decision in 3-8 seconds. The 5-second difference allows for sequential processing: Room → Floor (1s) → Building (2s) → Campus (5s total). Each level has time to apply Kalman filtering with 10 samples (200ms × 10 = 2s window) before aggregating upward.
The Dasarathy taxonomy provides a formal framework for classifying sensor fusion systems based on their input and output abstraction levels.
DAI-DAO
Flow: Data -> Data
Raw sensor values are combined into a refined raw estimate.
Example: Two temperature sensors averaged together.
DAI-FEO
Flow: Data -> Feature
Raw readings are transformed into a higher-level feature.
Example: Accelerometer and gyroscope data become motion features.
FEI-FEO
Flow: Feature -> Feature
Multiple feature sets are merged into a richer description.
Example: Wi-Fi RSSI and BLE features combined.
FEI-DEO
Flow: Feature -> Decision
Features are classified into a discrete state or label.
Example: Heart rate and motion -> “User sleeping”.
DEI-DEO
Flow: Decision -> Decision
Independent decisions are fused into one final outcome.
Example: Camera and radar agree to BRAKE.
A smart home illustrates how the Dasarathy categories apply in practice. Temperature and humidity sensors fuse at the data level (DAI-DAO) to produce a comfort index. Motion, light, and door sensors extract occupancy features (DAI-FEO), which are then classified into states like “home,” “away,” or “sleeping” (FEI-DEO). Finally, the comfort system and security system each make independent decisions that are combined at the decision level (DEI-DEO) to determine actions like adjusting the thermostat or arming the alarm.
Information preservation
Early fusion: Maximum signal detail is retained.
Late fusion: Minimal detail remains once only decisions are shared.
Computational cost
Early fusion: Very high because raw streams must be aligned and processed together.
Late fusion: Low because each node publishes a compact result.
Sensor heterogeneity and timing
Early fusion: Difficult with mixed sensors and strict synchronization requirements.
Late fusion: Easier to mix sensors and tolerate asynchronous updates.
Failure handling
Early fusion: Harder because one bad stream can disturb the shared pipeline.
Late fusion: Easier because nodes can fail independently and degrade gracefully.
Choose Early Fusion when:
Choose Late Fusion when:
Latency
Sensor-level fusion: Lower because decisions stay local.
Central fusion: Higher because data must cross the network first.
Bandwidth
Sensor-level fusion: Lower by shipping compressed features or decisions.
Central fusion: Higher when raw sensor streams are transmitted.
Accuracy
Sensor-level fusion: Can be limited by local context and compute.
Central fusion: Benefits from the full dataset and richer cross-sensor correlation.
Reliability
Sensor-level fusion: Graceful degradation when one node drops out.
Central fusion: A single central failure can halt the whole service.
Choose Sensor-Level Fusion when:
Choose Central Fusion when:
Scenario: Design fusion architecture for autonomous forklift pedestrian detection.
Requirements:
Sensors:
Architecture Decision: Cascaded fusion
Fusion Logic:
Alert if:
(LIDAR AND Camera) OR
(Ultrasonic AND Camera) OR
(LIDAR confidence > 0.95)Result: 99.92% recall, 0.7 false alarms/hr, 155ms latency – meeting all three requirements.
Key Insight: Cascaded fusion leverages each sensor’s strengths – LIDAR for fast spatial detection, camera for visual classification, ultrasonic for close-range confirmation.
The Kalman filter is the most widely used algorithm for combining noisy sensor data. Here is a simplified implementation fusing a GPS and an accelerometer for position tracking:
predicted_pos = pos + velocity * dt + 0.5 * accel * dt**2
predicted_var = pos_var + process_noise
innovation = gps_pos - predicted_pos
kalman_gain = predicted_var / (predicted_var + gps_noise)
fused_pos = predicted_pos + kalman_gain * innovation
updated_var = (1 - kalman_gain) * predicted_varWhy Kalman filtering matters for IoT:
Delivery drone position
Without fusion: GPS jumps 5-10 m between readings.
With Kalman fusion: Smooth trajectory with less than 1 m drift between GPS updates.
Fitness tracker steps
Without fusion: Accelerometer-only counts miss 15-25% of steps.
With Kalman fusion: Gyroscope-aided fusion keeps the error below 5%.
Indoor-outdoor transition
Without fusion: GPS loss means the position becomes unknown.
With Kalman fusion: The IMU carries the estimate until GPS recovers.
Use this calculator to compare bandwidth requirements across the three fusion architectures for your own IoT deployment scenario.
Sensor fusion systems generate data at different rates and require different storage strategies:
InfluxDB
Best for: Time-series sensor data.
Write speed: 1M+ points/sec.
Query pattern: Time-range queries and downsampling.
Example: Raw sensor readings and aggregated metrics.
TimescaleDB
Best for: Time-series data with SQL joins.
Write speed: 500K+ points/sec.
Query pattern: Relational queries across sensor types.
Example: Fusion pipelines with metadata context.
MongoDB
Best for: Heterogeneous sensor documents.
Write speed: 100K+ docs/sec.
Query pattern: Flexible schema queries.
Example: Multi-format fusion results.
SQLite
Best for: Edge-local storage.
Write speed: 10K+ inserts/sec.
Query pattern: Simple on-device queries.
Example: Local buffering before cloud sync.
Redis
Best for: Real-time state caches.
Write speed: 1M+ ops/sec.
Query pattern: Fast key-value lookups.
Example: Current sensor states and fusion intermediates.
Storage capacity planning – adjust the parameters below to estimate storage needs for your fusion system:
Architecture Patterns:
Related Topics:
Decision Support:
Centralised fusion requires transmitting all raw sensor data to a single node — in large-scale IoT deployments this communication overhead can dwarf the processing cost. Calculate the communication budget before choosing centralised vs distributed fusion.
Each tier in a hierarchical fusion system reduces information as it aggregates. Verify that the accuracy achieved at the top tier is adequate for the application after all intermediate aggregation steps, not just in the best-case scenario.
In a distributed fusion network, the failure of a node that aggregates data from 50 sensors silently removes all those sensors from the system. Design explicit failure detection and isolation so that node failures are visible and handled gracefully.
Distributed fusion architectures require time-synchronised measurements from all participating nodes. The synchronisation protocol overhead (NTP, PTP) can consume a significant fraction of the communication budget. Include it in resource budgeting.
Sensor fusion architectures determine system performance:
Sensor fusion architectures are like different ways to organize a team of detectives solving a mystery together!
The Sensor Squad had a big mystery to solve: “Who left the window open in the Smart School?” Principal Processor gave them three plans to choose from.
Plan A – The Big Meeting (Centralized): Sammy the Sensor, Lila the LED, Max the Microcontroller, and Bella the Battery all bring their clues to ONE big meeting room. Sammy says, “I felt cold air at 3 PM!” Lila adds, “I saw extra light from outside!” Max reports, “I heard the wind sensor go crazy!” Principal Processor looks at ALL the clues together and figures it out. This works great for a small team, but what if Principal Processor gets sick? Nobody can solve the mystery!
Plan B – Neighborhood Watch (Distributed): Each squad member investigates their OWN hallway. Sammy checks the science wing, Lila checks the art room, Max checks the gym, and Bella checks the library. They each make their own guess about which window is open, then they VOTE on the answer. If Sammy gets confused, the others can still solve it!
Plan C – Team Captains (Hierarchical): The squad splits into two sub-teams. Team Temperature (Sammy and a thermometer friend) figures out WHERE it is cold. Team Light (Lila and a brightness buddy) figures out WHERE extra light is coming in. Then Team Captain Max combines the sub-team reports. This is balanced – not too slow, not too risky!
Principal Processor smiled: “Choose your architecture based on the mission! Small mission? Use Plan A. Big school? Use Plan B. Medium? Plan C!”
| Word | What It Means |
|---|---|
| Centralized | Everyone sends data to ONE boss who makes the decision |
| Distributed | Everyone makes their own decision, then they vote |
| Hierarchical | Small teams decide first, then team captains combine results |
| Architecture | The plan for how a system is organized |
Fusion architecture choice determines system reliability, scalability, and accuracy. Centralized fusion provides optimal accuracy but creates a single point of failure. Distributed fusion scales well and tolerates failures but may sacrifice accuracy. Hierarchical fusion balances both concerns and is the most common choice for production IoT systems. Use the Dasarathy taxonomy to classify what level of abstraction your fusion operates at.