Analytics & ML · Study deck
Sensor Fusion Architectures
Picture three room sensors trying to report one temperature.
Data Dora is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: 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.
- Explain: 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.
- Explain: 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.
Major section
Start With the Story
One is beside a heater.
- One has an old clock.
- The system needs a shared estimate that keeps those limits visible.
- Latency means the time from new evidence to the result that needs it.: Bandwidth means the data capacity available on a link.
- A central service sees the broad set.
Major section
Start With the Story (continued)
A local group can cut network use and contain a fault.
- Peers can share work when no single owner is safe to assume.
- Each choice must keep source, time, uncertainty, and duplicate handling with the result.
- One fused value is not proof that all sources agreed.
- Those details can change the chosen owner.
Major section
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.
- 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.
Major section
Where Fusion Evidence Combines (continued)
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.
- 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.
Major section
Where Fusion Evidence Combines (continued)
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.
- 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.
- 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.
- This connects architecture to the running narrative: fusion placement is defensible only when provenance and uncertainty survive every transformation.
Major section
Where Fusion Evidence Combines (continued)
A distributed peer can keep operating during an outage, but it must publish estimate age and conflict state so later convergence is explainable.
- 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.
- 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.
Major section
Match Fusion Pattern to 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.
Major section
Match Fusion Pattern to Bottleneck (continued)
Design consequence: The bandwidth saving is useful only if each room state also carries time span, sensor health, uncertainty, and rejected-input evidence.
- Small or well-connected systems where one service can receive enough raw evidence.
- Losing detail when local summaries omit rejected inputs or uncertainty.
- Privacy boundaries, vendor systems, or classifiers that can share decisions but not raw data.
Major section
Fusion Level Sets Audit Trail
Fusion can happen at several abstraction levels.
- 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.
- Those levels become easier to audit when each one is written as an input-output signature.
Major section
Fusion Level Sets Audit Trail (continued)
If both trackers used the same upstream UWB anchor observation, that 0.28 m confidence is optimistic because the same evidence was counted twice.
- Decision-level fusion is compact and sometimes necessary across organisational boundaries, but it is the easiest place to hide incompatible labels or weak confidence.
- The architecture should mark common sources, correlation assumptions, and any covariance inflation rule before publishing the fused state.
- Overconfident fusion because shared evidence is counted twice.
Major section
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.
- 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.
Deck summary
Key takeaways
One is beside a heater.
- A local group can cut network use and contain a fault.
- A sensor-fusion architecture defines where readings become a shared estimate.
- Hierarchical fusion reduces bandwidth and isolates local failures.
- 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.
Retrieval practice
Recall check 1 of 3
Data Dora says: answer from memory, then check your reasoning.
Q1What is the main architectural question in sensor fusion?
Show answer
Answer: A Fusion architecture defines where evidence is combined and what evidence level is shared.
Retrieval practice
Recall check 2 of 3
Data Dora says: answer from memory, then check your reasoning.
Q2In the worked room-to-building example, what is the main risk of sending only room-level fused states upstream?
Show answer
Answer: C Fusion summaries reduce bandwidth only safely when they carry the evidence needed for review.
Retrieval practice
Recall check 3 of 3
Data Dora says: answer from memory, then check your reasoning.
Q3Why can state-level or track-to-track fusion become overconfident?
Show answer
Answer: D Fusing estimates safely requires knowing whether those estimates are statistically independent.
Print reference
Answers
Answer key.
- A · Fusion architecture defines where evidence is combined and what evidence level is shared.
- C · Fusion summaries reduce bandwidth only safely when they carry the evidence needed for review.
- D · Fusing estimates safely requires knowing whether those estimates are statistically independent.