Chapters

44 Virtual Sensors and Service Models

emerging-paradigms
s2aas
core
concepts

44.1 Start Simple

This section: Start Simple — Imagine a farm team buying access to a soil reading collected by another company.

Treat a Shared Reading as a Service Promise

Imagine a farm team buying access to a soil reading collected by another company. The number is easy to reach. The farm still needs to know where it came from, how old it is, what quality was checked, and whether it may guide watering.

Sensing as a Service means offering access to measurements for other users or systems. The service owner should name the source, unit, place, update rate, quality rule, permitted use, price, and support contact. The user should name the decision that depends on it.

Test a fresh reading, a late one, a gap, a changed unit, and a withdrawn source. Make every weak or missing state visible. Keep a record when data is combined or sold again.

Try the service with a known field check. Compare time, place, and unit before comparing the number. Ask what happens when the source moves, a part is replaced, or the collection method changes. The user needs notice before such a change alters a decision.

Write an exit plan as well as a start plan. The farm should know how to save needed records, remove access, and replace the source without hiding a gap. The provider should know which copies may remain and for how long.

Make price changes visible beside quality changes. A cheaper source may update less often or offer less support. A more expensive one may still be wrong for the field decision. Compare the whole promise rather than one number on a sales page.

Let a second team trace one reading. They should find the source, collection time, checks, allowed use, and change history. If any step depends on a private message or memory, the service is not ready for safe reuse.

Use a sample offer before signing. Ask for ten known readings. Check their time and unit. Compare one with a field check. Find a missing item. See how the service marks it. Read the change notice. Try the support route.

Now test the buyer’s side. Store the source name with each value. Keep the use rule with each copy. Show age on the final screen. Block an old value from a fresh decision. Record who accepted the source and when the choice must be reviewed.

The offer should make limits easy to find. It should state places not covered. It should state checks not run. It should name planned gaps. A user can then choose a safe task instead of treating all reachable data as equal.

Availability does not make a reading trustworthy or lawful to reuse. Practitioner builds the service agreement. Under the Hood examines ownership, discovery, payment, quality, privacy, and combined sources.

Start with one sensor stream that another team wants to reuse. In Virtual Sensors and Service Models, the practical question is who owns the sensing resource, what quality is promised, and what policy keeps the service safe to consume.

In 60 Seconds

S2aaS becomes useful when a physical sensing system can be exposed as a governed service. The core model has five moving parts: physical sensors, virtual sensor resources, discovery metadata, subscription terms, and delivery interfaces. IaaS-style sensing provides raw observations, PaaS-style sensing provides managed data services, and SaaS-style sensing provides finished insights. The right model depends on how much control the consumer needs and how much responsibility the platform should carry.

Checkpoint: Minimum Viable Understanding
  • A virtual sensor is a contract. It describes what a consumer can request, where the data comes from, how fresh it is, and which use is allowed.
  • Service layers allocate responsibility. IaaS leaves more work with the consumer; SaaS moves more work into the provider.
  • Discovery is part of the product. A consumer must be able to search by capability, location, quality, time, policy, and price model.
  • Multi-tenancy needs controls. Sharing is only safe when tenants are isolated, rate-limited, metered, and audited.
  • Quality metadata prevents false confidence. Calibration, completeness, latency, sampling interval, and fallback behavior must travel with the data.

44.2 Learning Objectives

This section: Learning Objectives

By the end of this chapter, you will be able to:

  • Model an S2aaS platform as physical sensors, virtual resources, discovery metadata, service layers, and consumers.
  • Choose between IaaS, PaaS, and SaaS-style sensing for a given consumer responsibility level.
  • Define the minimum metadata needed for sensor registration and discovery.
  • Explain how multi-tenancy, metering, and policy controls make shared sensing safe enough to reuse.
  • Write a basic discovery request that filters by capability, location, quality, and rate.
  • Trace a subscription lifecycle from registration to renewal or revocation.
What Makes The Service Trustworthy?

44.3 Concept Map

This section: Concept Map — S2aaS core concepts are easier to manage when the model is separated into resources, contracts, and delivery.

S2aaS core concepts are easier to manage when the model is separated into resources, contracts, and delivery.

44.3.1 Resource

Physical sensors produce observations. Virtual sensors package those observations as logical resources with metadata, quality state, and allowed operations.

44.3.2 Contract

Discovery, subscription, service level, allowed use, metering, and audit rules define what each consumer is allowed to receive.

44.3.3 Delivery

The platform delivers raw readings, managed streams, or finished insights depending on the service layer chosen by the consumer.

44.4 Service-Layer Choice

This section: Service-Layer Choice — The service-layer decision is the main modeling choice in this chapter.

The service-layer decision is the main modeling choice in this chapter. It is not just a pricing label. It decides who owns data cleaning, storage, aggregation, anomaly checks, dashboards, support, and domain interpretation.

44.4.1 IaaS-Style Sensing

Choose this when the consumer wants raw or near-raw observations and has the engineering team to validate, store, process, and interpret them.

44.4.2 PaaS-Style Sensing

Choose this when the consumer needs normalized streams, aggregation, quality checks, storage, query, and event services but still builds the application.

44.4.3 SaaS-Style Sensing

Choose this when the consumer wants a finished dashboard, alert, report, recommendation, or compliance output with minimal sensor-data engineering.

44.5 Selection Workflow: Virtual Sensor Model

This section: Selection Workflow: Virtual Sensor Model — A virtual sensor is the stable object that consumers use.

A virtual sensor is the stable object that consumers use. It may map to one physical sensor, a redundant group, a fused stream, or a time-bounded dataset. The virtual sensor should not hide important uncertainty. It should expose enough metadata for consumers to decide whether the resource fits.

Minimum virtual-sensor fields:

  • Identity: stable resource id, owner, platform namespace, and version.
  • Observed property: what is measured, unit, range, and semantic definition.
  • Coverage: location, zone, asset, spatial resolution, and valid time window.
  • Quality state: calibration status, completeness, freshness, latency, accuracy class, and known gaps.
  • Policy: allowed use, retention, redistribution, privacy constraints, and tenant visibility.
  • Delivery: API path, stream topic, format, sampling interval, rate limits, and service layer.

44.5.1 Virtual Sensor Composition: CoV-I and CoV-II

Composition answers a harder question than discovery: after candidate sensors have been found, which changing set should fulfil one stable consumer contract? Two algorithms separate the local-homogeneous and cross-region-heterogeneous cases.

CoV-I forms one virtual sensor from homogeneous physical nodes inside one geographic boundary. “Homogeneous” means the candidates observe the same property with compatible units and semantics; it does not mean their quality is identical.

  1. Filter registered nodes to the required zone, property, unit, policy, and valid time.
  2. Reject stale, uncalibrated, unreachable, or disallowed candidates before scoring.
  3. Normalize each candidate’s quality vector—freshness, accuracy, completeness, latency, remaining energy, and price—to comparable scales.
  4. Score candidate ii, for example
Si=waAi+wfFi+wcCi−wlLi−weEi−wpPi,S_i=w_a A_i+w_f F_i+w_c C_i-w_l L_i-w_e E_i-w_p P_i,

where every term is normalized and the weights come from the consumer contract. Here EiE_i can represent expected energy cost rather than remaining energy, so its sign stays meaningful. 5. Select one primary plus enough redundant nodes to meet availability or spatial-coverage constraints. Define a fusion rule—median, quality-weighted mean, voting, or primary/fallback—before publishing observations. 6. Expose the chosen set, fusion method, aggregate uncertainty, and replacement trigger as virtual-sensor metadata.

For a quality-weighted mean, weights may be derived from calibrated variance:

x^=∑ixi/σi2∑i1/σi2,σx^2=1∑i1/σi2.\hat{x}=\frac{\sum_i x_i/\sigma_i^2}{\sum_i 1/\sigma_i^2}, \qquad \sigma_{\hat{x}}^2=\frac{1}{\sum_i 1/\sigma_i^2}.

That equation is valid only when error assumptions are defensible; correlated colocated sensors do not provide as much independent evidence as the formula suggests.

CoV-II forms a virtual-sensor group from heterogeneous nodes across regions. The output is a coordinated service, not a claim that unlike measurements can be averaged. A heat-risk service might require temperature and humidity in each district, plus occupancy in selected buildings.

  1. Decompose the service contract into required roles RR—property, region, time window, quality, and policy for each role.
  2. Build a candidate set CrC_r for every role. A sensor may satisfy several roles only if capacity and policy permit.
  3. Choose assignments xir∈{0,1}x_{ir}\in\{0,1\} that minimize cost while covering every role:
min⁡∑r∈R∑i∈Crcirxir\min \sum_{r\in R}\sum_{i\in C_r} c_{ir}x_{ir}

subject to

∑i∈Crxir≥kr∀r,\sum_{i\in C_r}x_{ir}\ge k_r\quad\forall r,

plus latency, budget, ownership, energy, and cross-region transfer constraints. krk_r is the redundancy or coverage requirement for role rr. 4. Compose each role into a named sub-contract, then assemble those outputs into the virtual-sensor group. Preserve units and provenance at every boundary. 5. Publish group completeness: if the humidity role is stale, return a degraded heat-risk service with an explicit missing input rather than a confident-looking number.

Both algorithms must be re-evaluated. Trigger recomposition when calibration expires, freshness crosses its bound, battery or price changes materially, a node leaves the region, policy is revoked, or observed quality drifts. Use hysteresis—a replacement margin and minimum dwell time—so two nearly equal candidates do not flap on every update. Change membership atomically, retain the old/new composition versions, and tell subscribers whether a value was produced before or after the hand-off. The consumer sees one stable virtual-sensor identity; the platform remains honest about the physical membership underneath it.

Discovery Rule

If the metadata is too weak to compare two candidate sensors, the platform is not yet ready for reliable discovery.

44.6 Discovery and Registration

This section: Discovery and Registration — Registration is the owner-side promise.

Registration is the owner-side promise. Discovery is the consumer-side search. The same metadata must support both. A consumer cannot compare two candidates unless each record names its capability, unit, location, freshness, and permitted use. The platform should reject a request when those fields do not establish a trustworthy match.

S2aaS discovery contract showing sensor owner registration metadata, platform indexing, and consumer discovery filters for capability, location, quality, policy, and rate.
Figure 44.1: S2aaS discovery contract showing registration metadata from sensor owners and discovery filters used by data consumers.

44.6.1 Selection Workflow: Owner Registration

  • What the sensor measures — include the unit and meaning so consumers can compare the offered capability with their sensing need.
  • Where and when it is valid — describe coverage and the valid time window; a reading may fit one place but not another.
  • Calibration and maintenance state — make quality records visible so the platform can validate the resource before discovery.
  • Allowed users and allowed uses — state sharing rights and restrictions so access can follow the owner’s policy.
  • Delivery formats and rate limits — describe how consumers receive data and the operational limits that subscription terms must respect.

44.6.2 Selection Workflow: Consumer Discovery

  • Capability and unit required — name the sensing need so the platform can compare it with registered measurement capabilities.
  • Location or asset scope — match the requested place to the resource’s coverage rather than assuming all available readings apply.
  • Minimum freshness and completeness — state the quality bounds needed for the decision; fresh data may still contain gaps.
  • Acceptable latency and sampling interval — compare delivery timing and observation timing with the application’s requirements.
  • Policy, retention, and redistribution needs — check whether the intended use and handling of copies fit the owner’s terms before subscribing.

44.6.3 Discovery Request Example

{
  "observedProperty": "pm25",
  "unit": "ug_per_m3",
  "area": {
    "type": "named_zone",
    "id": "central-district"
  },
  "quality": {
    "maxLatencySeconds": 300,
    "minCompleteness": 0.95,
    "calibrationStatus": "current"
  },
  "delivery": {
    "layer": "paas",
    "maxRateHz": 0.02,
    "format": "json"
  },
  "policy": {
    "redistribution": false,
    "retentionDays": 30
  }
}

The request is useful because it describes a sensing need, not a preferred device brand. The platform can map it to one or more physical resources and reject it if the quality or policy constraints cannot be met.

44.7 Marketplace Roles and Incentives

This section: Marketplace Roles and Incentives — S2aaS has three core roles.

S2aaS has three core roles. They should be modeled separately even when one organization plays more than one role.

44.7.1 Sensor Owner

Owns or controls physical deployment. Needs clear sharing rights, operational limits, quality duties, and visibility into how data is used.

44.7.2 Platform Operator

Runs registry, discovery, data intake, virtualization, access control, metering, billing, quality scoring, policy enforcement, and audit.

44.7.3 Data Consumer

Subscribes to a service outcome. Needs useful data, predictable delivery, quality records, and terms that match the application risk.

The incentive model fails when one role is ignored. Owners will not publish useful resources if policy and operational burden are unclear. Consumers will not rely on the service if quality and allowed use are vague. Operators cannot scale if every subscription requires manual negotiation.

44.8 Subscription Lifecycle

This section: Subscription Lifecycle — A subscription is not just an API key.

A subscription is not just an API key. It is the operational record that binds tenant, resource, quality expectation, allowed use, rate, retention, and renewal rules.

Inspect Figure 44.2 and look for the records that make revocation enforceable after delivery begins.

The S2aaS lifecycle moves through registration, validation, discovery, subscription, delivery, metering/audit and renewal or revocation. The subscription binds resource, policy and usage evidence.
Figure 44.2: Worked PM2.5 S2aaS subscription contract checks service scope, quality and rate limits, metering evidence, then renewal or revocation.

Trace Figure 44.2 from sign-up to renewal or removal. Sign-up binds the owner, sensor skill, and quality claim. The check covers age, gaps, place, privacy, and allowed use. Search ranks only sensors that meet those bounds. The subscription then saves the tenant, service layer, rate, data life, and policy. Delivery stays under tenant and rate limits. Metering saves use, failed calls, quality, access, and policy choices. The last gate checks consent, quality, tenant conduct, and end date again. Access is an ongoing record that can be checked, not a one-time API key.

Lifecycle checks:

  1. Register the sensing resource with owner, capability, quality, delivery, and policy metadata.
  2. Validate calibration, freshness, location, completeness, privacy, and allowed use.
  3. Discover resources through consumer filters and rank by fit, quality, and constraints.
  4. Subscribe with tenant identity, service layer, rate, retention, and policy terms.
  5. Deliver observations, streams, or insights while enforcing tenant isolation and rate limits.
  6. Meter and audit usage, failed requests, policy decisions, data quality, and access history.
  7. Renew or revoke based on quality changes, consent changes, tenant behavior, or contract expiry.

44.9 Quality Model

This section: Quality Model — Quality in S2aaS is multi-dimensional.

Quality in S2aaS is multi-dimensional. A reading can be accurate but too late, fresh but incomplete, allowed for internal use but not redistribution, or valid in one location but not another.

44.9.1 Technical Quality

  • Calibration state — keep calibration records visible; expiry can require validation and reconsideration of the selected source.
  • Sampling interval — compare the registered interval with the consumer’s requested timing requirements.
  • Latency and jitter — include these timing qualities when assessing delivery against the service contract.
  • Completeness — show known gaps because a fresh reading does not establish that all required data is present.
  • Outlier handling — make quality checks part of the stated provider responsibility so consumers know what processing is offered.
  • Fallback source behavior — expose the replacement source and change history so consumers can trace observations when physical membership changes.

44.9.2 Use Quality

  • Spatial fit — compare the resource’s coverage with the decision’s location; validity in one place does not establish validity elsewhere.
  • Time-window fit — check that observations fall within the period required for the intended use.
  • Allowed use — match the consumer’s task to explicit policy terms, including redistribution restrictions.
  • Retention limit — carry the rule with each copy and state which records may remain after access ends.
  • Privacy risk — consider whether shared data exposes behavior, location, occupancy, or process state when defining access constraints.
  • Auditability — retain source, collection time, checks, policy decisions, and change history so another team can trace a reading.

For low-risk analytics, a platform may allow degraded service with a visible quality flag. For safety-relevant or compliance-sensitive workflows, the platform should fail closed when required quality records are missing.

44.10 Worked Example: Choosing the Model

This section: Worked Example: Choosing the Model — Scenario: A logistics company wants temperature records for refrigerated deliveries.

Scenario: A logistics company wants temperature records for refrigerated deliveries. It has its own analytics team, but it does not own sensors in every region where partners operate.

Model choice:

  • Use IaaS-style sensing when the company needs direct readings to feed its own chain-of-custody model.
  • Use PaaS-style sensing when it needs normalized streams, gap detection, and event notifications across partner networks.
  • Use SaaS-style sensing when it only needs a compliance report that states whether each delivery stayed within policy.

Best initial fit: PaaS-style sensing. It gives the company managed ingestion and quality checks while preserving the ability to build its own logistics application.

Decision records:

  • The virtual sensor contract names unit, location scope, calibration state, and freshness.
  • The subscription specifies tenant, rate, retention, and allowed use.
  • The platform records missing data, late data, and policy decisions.
  • The consumer can export an audit trail for exceptions.

44.11 Knowledge Check

This section: Knowledge Check

44.13 Common Pitfalls

This section: Common Pitfalls

44.13.2 Hiding Provider Responsibility

If the service layer does not say who handles calibration, validation, storage, alerts, and support, consumers will assume guarantees the platform may not provide.

44.13.3 Missing Allowed-Use Rules

Sensor data can expose behavior, location, occupancy, process state, or health-adjacent signals. Allowed use must be explicit and enforceable.

44.13.4 Ignoring Quality State Changes

A subscription that was valid yesterday can become invalid after calibration expiry, device movement, privacy withdrawal, or persistent missing data.

44.15 Virtual Sensor as Contract

This section: Virtual Sensor as Contract — If you only need the operating rule, this layer is enough: S2aaS works when every virtual sensor carries the meaning, quality, policy, delivery, and subscription evidence a consumer needs before trusting shared sensing.

If you only need the operating rule, this layer is enough: S2aaS works when every virtual sensor carries the meaning, quality, policy, delivery, and subscription evidence a consumer needs before trusting shared sensing.

Inspect Figure 44.4 and ask which validation and interpretation duties move to the platform at each service layer.

S2aaS service-layer choice model showing IaaS raw observations, PaaS managed streams, and SaaS finished insights with responsibility moving from consumer to platform.
Figure 44.4: The service layer decides which responsibilities remain with the consumer and which become platform obligations.

Move across Figure 44.4 as the platform takes on more work. The IaaS offer gives raw or near-raw readings. The buyer must check, store, process, and explain them. The PaaS offer adds common streams, data merge, quality checks, storage, search, and events, while the buyer builds the app. The SaaS offer gives a finished screen, alert, report, or advice. These layers divide duties; they are not just price bands. Before choosing one, name who owns sensor checks, data quality, meaning, storage time, access, and fault work. A higher layer is simpler only when that contract is clear.

Mobile summary: IaaS exposes raw observations for consumer-owned validation and analytics, PaaS adds managed streams and quality checks, and SaaS delivers finished dashboards, alerts, reports, or domain outputs.

Resource contract

Name observed property, unit, source owner, physical mapping, location scope, valid time window, calibration state, and freshness expectation.

Discovery contract

Let consumers filter by capability, quality, latency, completeness, policy, retention, service layer, delivery format, and cost or quota terms.

Subscription contract

Bind tenant, resource, allowed use, rate, retention, redistribution, service level, audit fields, renewal, and revocation behavior.

44.16 Air-Quality Subscription Record

This section: Air-Quality Subscription Record — For the PM2.5 platform example, the same physical sensing estate may serve researchers, school dashboards, and compliance reports only if each consumer gets a subscription whose quality and policy terms match its risk.

For the PM2.5 platform example, the same physical sensing estate may serve researchers, school dashboards, and compliance reports only if each consumer gets a subscription whose quality and policy terms match its risk.

Virtual sensor proof

Record resource ID, PM2.5 definition, unit, sensor group, owner, calibration state, location scope, valid time window, and version.

Discovery proof

Record consumer filters for area, maximum latency, minimum completeness, sampling interval, delivery layer, retention, and redistribution need.

Quality proof

Expose freshness, completeness, calibration expiry, fallback source, missing-data behavior, and whether the service fails closed for the use case.

Policy proof

Record tenant identity, allowed use, rate limit, retention, redistribution, audit event, renewal date, and revocation trigger.

44.17 Why Shared Sensors Lose Trust

This section: Why Shared Sensors Lose Trust — Shared sensing fails when consumers see a convenient stream but cannot see whether the stream still matches their semantics, quality threshold, and policy terms.

Shared sensing fails when consumers see a convenient stream but cannot see whether the stream still matches their semantics, quality threshold, and policy terms.

Treat why Shared Sensors Lose Trust as one connected review. Begin with semantic mismatch: two resources with similar labels may differ by unit, averaging window, spatial scope, calibration procedure, or feature of interest. With that boundary fixed, examine quality drift: a once-valid subscription can become invalid after calibration expiry, device movement, missing data, or increased latency. Then connect it to policy bleed: a tenant uses data for redistribution, profiling, or retention beyond the allowed service terms. Close the review by checking subscription zombie: expired or revoked access keeps delivering data because renewal, revocation, and audit paths are not enforced. The order matters: each later judgment depends on the owner, state, constraint, or failure evidence retained by the preceding step, so the resulting record can support the next chapter decision.

Compare composition within one region and across regions in the diagram Figure 44.3.

Two-scale sensor-cloud composition workflow for a local virtual sensor and a cross-region heterogeneous virtual sensor group.
Figure 44.3: Two-scale sensor-cloud composition workflow for a local virtual sensor and a cross-region heterogeneous virtual sensor group.

In the diagram Figure 44.3, coV-I turns homogeneous candidates into One virtual sensor after freshness and quality filtering. CoV-II assembles a Virtual sensor group for a city exposure index, preserving per-source lineage even while condition changes trigger member replacement.

44.18 Summary

This section: Summary — S2aaS concepts and models are about responsibility boundaries.

S2aaS concepts and models are about responsibility boundaries. Physical sensors provide observations, virtual sensors expose governed resources, discovery metadata lets consumers find the right capability, subscriptions enforce tenant-specific terms, and service layers decide how much work stays with the consumer versus the platform. A strong S2aaS design is not measured by how many sensors it lists; it is measured by whether consumers can discover, trust, subscribe to, and audit the sensing capability they actually need.

44.20 Key Takeaway

This section: Key Takeaway — Sensing as a Service packages sensing hardware, data quality, metadata, access policy, and service obligations into a reusable product.

Sensing as a Service packages sensing hardware, data quality, metadata, access policy, and service obligations into a reusable product. The service is only valuable if users can trust the data.

Find help

3 reviewed answers.

Where should I start in a module?

Open the module page from the sidebar to see its chapters in order. Use the module map to return to a topic you need.

Modules and paths

Reviewed

What can I try when a project does not work?

Check the symptom, then work through the diagnostic steps. Keep the error message and the smallest example that reproduces it.

When you are stuck

Reviewed

How do interactive examples work?

Use the interactive guide to check how examples and simulations work before changing your project.

Interactive examples guide

Reviewed