6 The Sensor Data Path
sensor application architecture, IoT data path, sensing node, gateway design, sensor data storage, validation evidence, retest trigger
6.1 Start With the Data Path Story
Follow one accepted reading as it leaves the sensor, passes through a gateway, gets processed, lands in storage, and reaches a display or action rule. The architecture is good only if that path keeps the reading’s source, time, unit, context, and quality state intact.
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. It is the set of handoffs that preserve what the reading means as it moves through a sensing node, gateway, processing step, storage record, and action.
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. 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. The gateway attaches room identity and buffers readings during a short network outage. A processing rule rejects impossible jumps, marks stale records unavailable, and passes only fresh accepted readings to storage. 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. If any handoff drops one of those fields, the architecture has turned a measurement into an unsupported claim. This framing also prevents architecture diagrams from becoming inventory drawings: a node, gateway, database, and dashboard are only evidence when the diagram says what each handoff must keep, what it may change, and how the result is checked.
An Airspeck-S-style environmental station makes the same boundary visible at outdoor scale. The enclosure is part of the measurement path: the solar panel recharges the battery and shades the box, the frame and inlet/outlet covers keep rain out while preserving airflow, and a shroud or fan pulls air across particulate, gas, temperature, and humidity sensors. The first record should not collapse PM10/PM2.5, NO2/O3, T/RH, GPS, battery state, Bluetooth or 3G/4G link state, SD-card fallback, and firmware cycle into one "air-quality value." A reviewable data path says when the firmware initializes the sensors, starts the fan, reads the optical particle counter and gas front end, reads temperature and humidity, opens a GPRS or HTTPS path, sends the record to storage, and then shows maps, traces, or health dashboards only with the source, timestamp, units, calibration state, and quality flag still attached.
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.
Architecture Roles
Sensing Node
Creates the first record: measured quantity, unit, timestamp, source identity, placement context, and validity state.
Gateway
Translates, buffers, filters, routes, attaches site context, or supports a local decision when that role is explicit and validated.
Action Path
Processes, stores, displays, alerts, reports, actuates, or queues review only when the evidence allows the action.
Beginner Examples
- A dashboard reading is weak if it lacks the source identity, unit, timestamp, and accepted-or-stale state.
- A gateway adds value when it translates, buffers, filters, or preserves context; it is weak if it only hides an unclear handoff.
- A local alert rule may belong near the node or gateway if the action cannot wait for a backend step.
- A storage record should preserve the meaning needed for later review, not just a number.
Overview Knowledge Check
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. 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.
How It Works: Review the Handoffs
- State the decision. Name the display, alert, report, control action, manual review, or model input the architecture supports.
- Map the path. Trace the record from sensing node through gateway, processing, storage, and action.
- Check each handoff. Confirm source, unit, timestamp, context, validity state, and rule version survive or are deliberately transformed.
- Place processing deliberately. Put checks near the node, gateway, or backend based on latency, bandwidth, power, connectivity, context, and review evidence.
- Validate the action. Test accepted, rejected, stale, missing, and boundary examples before allowing the action rule to operate.
Architecture Review Ledger
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. The dashboard displays accepted fresh readings, marks stale readings unavailable, and refuses to hide rejected readings as normal. The architecture is reviewable because the action can be traced back to the record that supports it.
Practitioner Knowledge Check
Quality States and Retest Boundaries
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. If they collapse into one normal value, dashboards, reports, alarms, and controls can become confident while the evidence is incomplete.
Retest triggers keep the architecture honest after change. 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. The record should name which changes reopen review.
Two records can carry the same number and still require different behavior. 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. Otherwise a technically correct numeric value can reach the wrong action boundary.
Advanced Example
A cold-storage alarm uses a sensor node, a local gateway, backend storage, and an alert service. During a gateway outage, the node buffers readings and the gateway replays them later. 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.
Validation Evidence Checklist
- Known input: A reviewed value passes through node, gateway, storage, and action without losing source, unit, or timestamp.
- Rejected input: An impossible or out-of-range reading is marked rejected and does not drive the normal action.
- Stale input: An old reading remains visible as stale or unavailable instead of appearing fresh.
- Gateway replay: Buffered records preserve original time, source identity, order, and replay status.
- Processing boundary: Boundary examples prove the rule accepts, rejects, and escalates as designed.
- Retest trigger: The record states which architecture changes require another validation run.
Quality-State Contract
Accepted
The reading passed the reviewed checks and may support the normal display, report, or action.
Rejected
The reading failed a quality rule and should keep its reason rather than disappear as a normal missing value.
Stale or Missing
The architecture should show unavailable or needs-review behavior, not silently reuse old evidence.
Retest Needed
A setup, path, rule, schema, firmware, or action change invalidates the old validation evidence until checked again.
Under-the-Hood Knowledge Check
6.2 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. If the action cannot trace to a reviewed record with source, unit, timestamp, context, quality state, and validation evidence, the architecture needs another pass.
6.3 Key Takeaway
Design sensor applications so every action can be explained from the data path. Values, quality states, rule versions, validation evidence, and retest triggers are architecture requirements, not cleanup details.
6.4 See Also
Sensor Applications
Use this for the broader sensor-to-action evidence path before reviewing the architecture in detail.
Sensor Applications: Domain Overview
Connect architecture decisions to common monitoring, alerting, automation, and review domains.
Applications and Sensors Hardware
Choose hardware that fits the architecture record and the evidence required by the application.
Sensor Lab Workflow
Practice building evidence packets that prove each sensor application handoff is reviewable.