Sensor Applications · Study deck
The Sensor Data Path
Picture a heat alert that reaches a phone with no room name and an old time.
Physics Phoebe is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- trace a reading's source, timestamp, unit, and quality state as it moves from sensing node through gateway, processing, storage, and action
- assign a gateway's role (translate, buffer, filter, route, local decision) explicitly instead of treating it as a black box
- identify which architecture handoff is responsible when a stored or displayed value loses its supporting context
- Explain: The number may be accurate, yet the person cannot know where it came from or whether it is safe to act.
Major section
Start With the Data Path Story
The number may be accurate, yet the person cannot know where it came from or whether it is safe to act.
- Architecture must protect meaning across every hand-off.
- A gateway is the device that joins a local sensing network to another system.
- The final action should stop or show doubt when its evidence is incomplete.
Major section
Start With the Data Path Story (continued)
This trace proves one decision path, not every use of the stored data.
- New reports or rules may create new duties.
- The deeper sections define roles, hand-off records, quality states, and review triggers so later uses remain tied to the original measurement claim.
- The architecture is good only if that path keeps the reading's source, time, unit, context, and quality state intact.
Major section
Architecture Preserves Meaning
Sensor application architecture is the reviewable path from a physical reading to a display, alert, report, automation rule, or human review.
- The architecture is not the list of devices.
- A strong architecture record says what each step owns, what evidence proves the handoff works, what quality states can occur, and what change requires retesting.
Major section
Architecture Preserves Meaning (continued)
This keeps the application tied to a bounded decision instead of a vague claim that data is available somewhere.
- For example, an equipment-room heat monitor may begin with a temperature sample from a wall-mounted sensing node.
- A processing rule rejects impossible jumps, marks stale records unavailable, and passes only fresh accepted readings to storage.
- If any handoff drops one of those fields, the architecture has turned a measurement into an unsupported claim.
Major section
Architecture Preserves Meaning (continued)
The display can then show the latest accepted state, while a maintenance reminder is allowed only when the stored record still has source, unit, timestamp, room context, quality state, and rule version.
- An Airspeck-S-style environmental station makes the same boundary visible at outdoor scale.
- If you only need the core idea, use this rule: a sensor application is ready only when every downstream action can trace back to a reading with source, unit, timestamp, context, quality state, and validation evidence.
- Gateway Translates, buffers, filters, routes, attaches site context, or supports a local decision when that role is explicit and validated.
Major section
Architecture Preserves Meaning (continued)
Action Path Processes, stores, displays, alerts, reports, actuates, or queues review only when the evidence allows the action.
- At the dashboard it remains weak unless source identity, unit, timestamp, and accepted-or-stale state survived.
- If an alert cannot wait for a backend round trip, its rule may belong near the node or gateway, but that placement still needs evidence and ownership.
- A gateway adds value when it explicitly translates, buffers, filters, or preserves context; otherwise it merely hides an unclear handoff.
Major section
Write the Architecture Record
A practical architecture review starts with the decision or action.
- A comfort display, cold-storage alarm, machine-protection shutdown, field inspection note, and maintenance report can all use sensor data, but they need different evidence strength.
- The architecture record should say exactly which decision the path supports.
- Once the decision is clear, map every handoff.
Major section
Write the Architecture Record (continued)
Action rule, blocked states, escalation path, validation example, and owner.
- The record should show the sensing node, gateway behavior, processing rule, storage fields, action rule, validation evidence, quality states, and retest trigger.
- If a handoff changes meaning, the record should keep the original meaning or explain the transformation.
- Triggering alerts or controls from stale or unreviewed readings.
Major section
Write the Architecture Record (continued)
At each boundary, confirm that source, unit, timestamp, context, validity state, and rule version survive or are deliberately transformed.
- Intermediate Example A room condition display receives temperature and humidity from a sensing node.
- The gateway attaches room identity and forwards accepted readings.
- Storage keeps source, unit, timestamp, room identity, validity state, and the rule version that accepted the reading.
Major section
Quality States and Retest Boundaries
Retest triggers keep the architecture honest after change.
- The hardest architecture mistakes happen when weak readings are allowed to look normal.
- Accepted, rejected, stale, missing, unavailable, saturated, contradictory, and needs-review states should stay distinct from the sensing node through the action.
- The record should name which changes reopen review.
Major section
Quality States and Retest Boundaries (continued)
Otherwise a technically correct numeric value can reach the wrong action boundary.
- If they collapse into one normal value, dashboards, reports, alarms, and controls can become confident while the evidence is incomplete.
- Two records can carry the same number and still require different behavior.
- Validation Evidence Checklist Validate the architecture with contrasting records.
Major section
Quality States and Retest Boundaries (continued)
A new sensor, remounted device, gateway rule, storage schema, processing threshold, dashboard action, firmware version, or validation method can change what the data path proves.
- A fresh accepted reading may drive the normal action, while a replayed reading from an outage may be useful for review but unsafe for an immediate alarm.
- The architecture has to preserve that state difference as data is transformed, compressed, summarized, and displayed.
- Advanced Example A cold-storage alarm uses a sensor node, a local gateway, backend storage, and an alert service.
- Boundary examples should demonstrate the intended accept, reject, and escalation paths.
Major section
Quality States and Retest Boundaries (continued)
The architecture should preserve original timestamps and mark replayed records so the alert rule does not treat old values as fresh.
- Storage should keep the validity state and replay note, while the alert action should use only accepted current readings for immediate alarms and route replayed evidence to review.
- Replay an old reading and keep it visibly stale or unavailable; replay a buffered batch and preserve original time, source identity, order, and replay status.
- Quality-State Contract Accepted The reading passed the reviewed checks and may support the normal display, report, or action.
Major section
Follow a Freezer Alarm Back to Ice
Each labelled boundary can delay, scale, drop, or rename the reading, so the alarm must retain its time and unit.
- The displayed reading needs its measurement time and queue delay.
Major section
Summary
Sensor application architecture is a data-path discipline.
- A strong architecture record shows how the sensing node, gateway, processing step, storage record, and action preserve measurement meaning.
- It keeps quality states distinct, validates each handoff, and names the retest triggers that make old evidence unsafe to reuse.
- The review should start with the decision or action, then work backward through the evidence.
Deck summary
Key takeaways
The number may be accurate, yet the person cannot know where it came from or whether it is safe to act.
- This trace proves one decision path, not every use of the stored data.
- Sensor application architecture is the reviewable path from a physical reading to a display, alert, report, automation rule, or human review.
- This keeps the application tied to a bounded decision instead of a vague claim that data is available somewhere.
- The display can then show the latest accepted state, while a maintenance reminder is allowed only when the stored record still has source, unit, timestamp, room context, quality state, and rule version.
Retrieval practice
Recall check 1 of 3
Physics Phoebe says: answer from memory, then check your reasoning.
Q1A sensor application dashboard shows values, but the stored records do not include unit, source identity, timestamp, or validity state. What is the strongest architecture review finding?
Show answer
Answer: B Architecture must preserve measurement meaning from node to action.
Retrieval practice
Recall check 2 of 3
Physics Phoebe says: answer from memory, then check your reasoning.
Q2A vibration sensor produces high-rate readings, but only threshold events need to reach the cloud. Where might processing belong?
Show answer
Answer: D Processing placement should match evidence, bandwidth, latency, power, and review needs while keeping rejected states reviewable.
Retrieval practice
Recall check 3 of 3
Physics Phoebe says: answer from memory, then check your reasoning.
Q3A sensor application stores timestamped readings, but its alert rule still fires on stale values after a gateway outage. Which architecture boundary should be reviewed first?
Show answer
Answer: A The architecture should keep stale, replayed, missing, rejected, and accepted readings separate through the action step.
Print reference
Answers
Answer key.
- B · Architecture must preserve measurement meaning from node to action.
- D · Processing placement should match evidence, bandwidth, latency, power, and review needs while keeping rejected states reviewable.
- A · The architecture should keep stale, replayed, missing, rejected, and accepted readings separate through the action step.