2 Sensing Across Domains

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.

Before comparing domain examples, inspect Figure 2.1 to see why the application decision must lead the review. The diagram turns a broad domain label into a sequence of evidence questions that can be checked before hardware claims are trusted.

Read Figure 2.1 from the decision question into the measurand and environment, then test sensor fit and the data path. The quality gate decides whether the reading can cross into an action boundary, while the retest record says when that permission expires. That order connects each domain example back to a bounded measurement claim instead of a catalogue of possible sensors.

Common Domain Review Axes

Beginner Examples

Begin with a room-comfort reading: temperature only becomes useful after placement, airflow, sunlight, occupancy, and the action rule explain what it represents. Apply the same sequence to a tank, where a validated threshold may support “needs attention” without claiming exact volume. Equipment monitoring adds operating mode and trend context before an outlier is interpreted. Mobile sensing adds permission, phone placement, user action, and missing samples. Across all four examples, the domain changes the context and evidence while the review still moves from a decision to a bounded measurement claim.

What Domains Actually Sense

Abstract axes are easier to trust once they are tied to real deployments. A widely used sensor-to-application catalog maps roughly sixty named IoT applications to the specific sensor types each one needs -- the same domain name can require very different sensors depending on the decision:

Reading down that table is a good check on the review habit above: "structural health" is not one sensor, it is a claim assembled from crack detection plus an accelerometer plus a displacement reading, each answering a different part of the question. A domain name is a filing label for a set of applications; the measurement requirement still has to be assembled application by application.

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

Review a domain application in dependency order. State the display, alert, automation, diagnosis, report, or review decision before selecting a sensor. Then name the physical condition, unit, location, expected range, and response speed that support it. Domain context adds installation constraints, environment, privacy expectations, maintenance access, and operating modes. Trace the resulting record through signal processing, gateway, storage, dashboard, model, alert, or actuator. Finally, define how stale, impossible, noisy, missing, and contradictory readings are handled and which changes force the whole claim to be tested again.

Application Review Ledger

Two Domain Records From Real Deployments

AgriSens, a funded smart-irrigation project (IIT Kharagpur, supported by India's Ministry of Human Resource Development), is a concrete example of an application record built before hardware. Its objective was stated as a decision, not a device list: more yield with less water, automatic irrigation, and irrigation treatments that change across a crop's vegetative, reproductive, and maturity phases rather than one fixed schedule. The sensor design followed from that decision -- a purpose-built water-level probe and an EC-05 soil-moisture sensor at the root zone -- and the field trial recorded exactly the kind of evidence this ledger asks for: average water level tracked a clear phase-shaped pattern (a steady 2-3cm through the vegetative phase, a sawtooth 2-6cm as irrigation cycled through the reproductive phase, then a drop toward zero as irrigation stopped before harvest), and the wireless data path was validated separately from the agronomy, with average packet delivery ratio across four sensor nodes over 113 days ranging from 89.75% to 98.75% against named noise sources (air flow, temperature, solar radiation, rain).

AmbuSens, a wireless body-area-network project from the same research group, shows the same discipline applied to a harder decision: ambulatory and emergency healthcare, where physical presence is the default assumption the application has to remove. Its measurand list names exactly what "physiological monitoring" means -- heart rate, a three-lead ECG, temperature, and galvanic skin response -- streamed over a Bluetooth-based body-area network. Rather than trusting the wireless path by assumption, its validation record compared real-time ECG traces from the wireless system directly against a wired hospital reference across both hospital and ambulatory field trials before the system was trusted for the decision it exists to support.

Other funded systems in the same catalog show how far the same review habit travels: an agricultural intrusion-detection prototype (AID) pairs a passive-infrared sensor to detect an object crossing a field's perimeter with an ultrasonic sensor to range its distance, then routes an SMS alert to the farmer's phone through a layered sense-process-route-alert architecture; a coal-mine fire-monitoring and alarm system places temperature sensors at the corners of each Bord-and-Pillar coal panel specifically because that geometry is where early fire risk concentrates. Neither reads as "we added a WSN"; both read as a decision, a measurand chosen to serve it, and a validated path between the two.

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

Failure Patterns

Separate four failure patterns during review. Hidden missing data replaces an unavailable reading with a normal-looking value and then lets it enter reports or alerts. Stale confidence displays an old value without its age or uses it for a decision that requires freshness. Context loss strips location, sensor identity, operating mode, calibration state, or domain notes from the record. Action confusion promotes evidence that is sufficient for display into automation without the stronger validation that action requires. Keeping these states distinct prevents a weak record from looking like a valid extreme condition.

Under-the-Hood Knowledge Check