3  Sensing Across Domains

Keywords

sensor applications, IoT sensors, sensing domains, sensor requirements, sensor data path, sensor validation

3.1 Start With the Domain Story

Picture the same sensor moved between a greenhouse, a cold room, and a machine cabinet. The hardware may look familiar, but the application story changes: the condition, placement, timing, decision, and proof all depend on the domain.

Domains Shape the Measurement Claim

A sensor application is a chain from a real-world condition to a decision. The domain gives the chain its context: a building, tank, machine, greenhouse, vehicle, phone, or field site changes what must be measured, where it is measured, how fast readings matter, how data quality is judged, and what action is allowed. The same sensor family can support different domains, but the evidence record is different each time.

The useful review question is not "which domain are we in?" The useful question is "what claim does this application need to make, and what sensor evidence would make that claim believable here?" A greenhouse humidity reading, a museum archive humidity reading, and a bathroom humidity reading may all use humidity sensors, but they have different placement, alert, maintenance, and validation boundaries.

That is why an overview chapter should keep domain examples tied to review evidence. In a cold-storage room, the application may need evidence that product temperature stayed within a handling rule, not merely that an air sensor reported a comfortable value near the door. In a greenhouse, the useful claim may combine humidity, soil moisture, light, and irrigation state before recommending an action. In equipment monitoring, a vibration reading means little until the record names the machine state, load, mounting point, baseline, and response rule. The domain is the shorthand; the measurement claim is the contract.

If you only need the intuition, start every domain overview with four nouns: condition, context, decision, and evidence. A domain label is helpful only when it sharpens those four items.

Sensor application reviews should move from the decision question to the measured condition, operating context, sensor fit, data-quality checks, action boundary, and retest record.

Common Domain Review Axes

Condition

Name the physical state, resource, equipment behavior, human context, or environmental signal the application needs to observe.

Decision

State whether the reading supports display, alerting, diagnosis, automation, reporting, maintenance, safety review, or model input.

Data Quality

Define freshness, plausibility, range, calibration, missing-data handling, noise tolerance, and context checks before the reading is trusted.

Evidence Record

Keep the sensor choice, placement, environment, data path, validation check, action rule, owner, and retest trigger together.

Beginner Examples

• In a room comfort application, temperature is not only a number; placement, airflow, sunlight, occupancy, and action rules affect what it proves.
• In a tank-level application, the useful claim may be "needs attention" rather than an exact volume, so validation and thresholds matter.
• In equipment monitoring, trend context and operating mode can matter more than a single outlier reading.
• In mobile sensing, permissions, phone placement, user behavior, and missing samples are part of the measurement evidence.

Overview Knowledge Check

Write the Application Record First

A practical sensor application review starts before hardware selection. The team writes a short application record that explains the domain, decision, measurand, environment, expected data path, action, validation checks, and retest triggers. That record keeps sensor choice tied to the claim the application must support.

The record should also state what the application does not prove. A room sensor may not represent nearby rooms. A tank-level sensor may not prove liquid quality. A phone accelerometer may not prove a person's activity without placement and context. These unsupported claims are not failures; they are boundaries that keep the design honest.

How to Review a Domain Application

1. State the decision. Write the display, alert, automation, diagnosis, report, or review question before selecting a sensor.
2. Name the measurand. Identify the physical condition, unit, location, expected range, and response speed that support the decision.
3. Describe the domain context. Record installation constraints, environment, privacy expectations, maintenance access, and operating modes.
4. Map the data path. Trace the reading from sensor through signal processing, gateway, storage, dashboard, alert, model, or actuator.
5. Define validation and retest. Decide how stale, impossible, noisy, missing, or contradictory readings are handled, and list changes that require review.

Application Review Ledger

Field

Question

Evidence to Keep

Common Failure

Decision

What question, action, or review does the application support?

Decision wording, threshold or rule, user or system owner, and allowed action.

Collecting sensor data because it is available, not because it supports a clear decision.

Measurand

What physical condition must be measured, where, and over what range?

Units, range, location, response time, expected variation, and application boundary.

Using a domain label such as smart building as a substitute for a measurement requirement.

Data path

How does the reading move from sensor to decision?

Signal path, preprocessing, timestamp, storage, dashboard, alert, or control connection.

Trusting raw readings before checking freshness, plausibility, identity, or context.

Retest trigger

What change makes the old evidence no longer sufficient?

Sensor replacement, relocation, rule change, enclosure change, calibration change, and domain change.

Letting a valid pilot record stand after the installation or decision has changed.

Practitioner Knowledge Check

Domain Context Becomes Data Quality Logic

Under the hood, a domain overview becomes software and operations logic. The application must know which sensor produced a reading, when it was sampled, what context was valid, whether the value is plausible, whether the reading is fresh enough, and whether the downstream decision is allowed to use it. Domain context turns into validation rules, metadata, and exception handling.

That logic should distinguish bad data from meaningful states. Missing data is not the same as zero. A stale reading is not the same as a stable condition. An impossible value is not the same as an extreme event. A sensor fault is not the same as an application alarm. Good sensor applications keep those states separate so people and automation do not overreact to weak evidence.

A simple implementation pattern is to carry a quality state beside every value. A tank application can store the level estimate, timestamp, device identity, installation zone, plausibility result, and allowed use. If the level has not updated recently, the dashboard can show the last known value while blocking an automatic refill command. If the value jumps faster than the tank can physically change, the application can mark the reading suspect instead of opening a work order. If maintenance moves the sensor or changes the alert rule, the retest trigger invalidates the old evidence until a new comparison run is recorded.

This separation also helps analytics. A model trained on accepted readings should not silently learn from missing values filled with zeros, stale values copied forward, or fault states mislabeled as real events. The domain overview therefore becomes a schema and policy problem: define the normal state, the uncertain states, the escalation path, and the minimum evidence needed before a reading can influence a user, report, or actuator.

Domain-to-Logic Checks

Identity

Confirm the reading belongs to the expected sensor, location, asset, phone, room, field, tank, or equipment item.

Freshness

Define how old a reading may be before it becomes stale for display, alerting, automation, or review.

Plausibility

Check range, rate of change, missing values, impossible combinations, and disagreement with related sensors or known operating modes.

Action Boundary

Define whether the reading can inform a dashboard, send an alert, open a work order, trigger control, or require manual review.

Failure Patterns

• Hidden missing data: replacing unavailable readings with a normal-looking value, then using that value in reports or alerts.
• Stale confidence: showing an old reading without labeling its age or excluding it from decisions that require freshness.
• Context loss: saving values without location, sensor identity, operating mode, calibration state, or domain notes.
• Action confusion: letting a reading that is good enough for display also trigger automation without stronger validation.

Under-the-Hood Knowledge Check

3.2 Summary

Sensor application domains help teams organize examples, but they do not replace requirements. A useful domain overview names the condition, context, decision, data path, validation checks, and evidence record. The same sensor type can support different applications when the domain changes the placement, action, quality threshold, maintenance rule, or retest trigger.

3.3 Key Takeaway

Start sensor applications from the domain decision, not the sensor catalog. The best application record explains what condition is measured, why it matters, how data is validated, and when the evidence must be reviewed again.

3.4 See Also

Sensor Applications

Review the module entry chapter for the sensor-to-action evidence path.

Sensor Application Architecture

Trace the data path from sensing node through gateway, processing, storage, and action.

Sensor Hardware Selection

Choose hardware that fits the domain requirement, environment, interface, and validation record.

Sensor Lab Workflow

Practice turning a domain application question into setup evidence and reviewable lab records.