44 Virtual Sensors and Service Models

emerging-paradigms

s2aas

core

concepts

44.1 Start Simple

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.

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

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

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

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 Virtual Sensor Model

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.

Filter registered nodes to the required zone, property, unit, policy, and valid time.
Reject stale, uncalibrated, unreachable, or disallowed candidates before scoring.
Normalize each candidate’s quality vector—freshness, accuracy, completeness, latency, remaining energy, and price—to comparable scales.
Score candidate $i$ , for example

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 $E_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:

\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.

Decompose the service contract into required roles $R$ —property, region, time window, quality, and policy for each role.
Build a candidate set $C_r$ for every role. A sensor may satisfy several roles only if capacity and policy permit.
Choose assignments $x_{ir}\in\{0,1\}$ that minimize cost while covering every role:

\min \sum_{r\in R}\sum_{i\in C_r} c_{ir}x_{ir}

subject to

\sum_{i\in C_r}x_{ir}\ge k_r\quad\forall r,

plus latency, budget, ownership, energy, and cross-region transfer constraints. $k_r$ is the redundancy or coverage requirement for role $r$ . 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

Registration is the owner-side promise. Discovery is the consumer-side search. The same metadata must support both.

Before discovery and Registration, inspect Figure 44.1 to compare “Platform” with “Index”. Their juxtaposition makes S2aaS discovery contract showing registration metadata from sensor owners and discovery filters used by data consumers visible.

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.

Read Figure 44.1 from “Platform” to “Index”. Taken together, “Platform” and “Index” express S2aaS discovery contract showing registration metadata from sensor owners and discovery filters used by data consumers. For discovery and Registration, the observed relationship between “Platform” and “Index” is evidence that “Platform” carries into the next decision.

44.6.1 Owner Registration

What the sensor measures
Where and when it is valid
Calibration and maintenance state
Allowed users and allowed uses
Delivery formats and rate limits

44.6.2 Consumer Discovery

Capability and unit required
Location or asset scope
Minimum freshness and completeness
Acceptable latency and sampling interval
Policy, retention, and redistribution needs

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

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

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.

Before subscription Lifecycle, inspect Figure 44.2 to compare “Validate” with “resource data”. Their juxtaposition makes S2aaS subscription lifecycle from resource registration through discovery, subscription, delivery, metering, audit, and renewal or revocation visible.

Read Figure 44.2 from “Validate” to “resource data”. Taken together, “Validate” and “resource data” express S2aaS subscription lifecycle from resource registration through discovery, subscription, delivery, metering, audit, and renewal or revocation. For subscription Lifecycle, the observed relationship between “Validate” and “resource data” is evidence that “Validate” carries into the next decision.

Lifecycle checks:

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

44.9 Quality Model

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
Sampling interval
Latency and jitter
Completeness
Outlier handling
Fallback source behavior

44.9.2 Use Quality

Spatial fit
Time-window fit
Allowed use
Retention limit
Privacy risk
Auditability

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

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

44.12 Concept Relationships

Physical sensors provide observations, but do not by themselves define a service.
Virtual sensors turn observations into governed resources.
Discovery metadata lets consumers find resources by capability and constraints.
Service layers divide responsibility between provider and consumer.
Subscriptions bind tenants to resources, rates, policies, and audit rules.
Quality models determine whether a resource is usable for the consumer’s risk level.

Match the Concepts

Sequence the Subscription Flow

Label the Core Model

Code Challenge: Build a Discovery Filter

44.13 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.14 References and Further Reading

OGC SensorThings API, for sensor observation modeling and queryable sensing resources.
W3C SOSA/SSN, for describing sensors, observations, features of interest, procedures, and observed properties.
IETF RFC 8428, for Sensor Measurement Lists (SenML) as a compact sensor-data representation.
oneM2M functional architecture, for common service-layer responsibilities relevant to shared sensing platforms.

44.15 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.

Before virtual Sensor as Contract, inspect Figure to compare "IaaS-Style" with "reports". Their juxtaposition makes the service layer decides which responsibilities remain with the consumer and which become platform obligations visible.

The service layer decides which responsibilities remain with the consumer and which become platform obligations.

Read Figure from "IaaS-Style" to "reports". Taken together, "IaaS-Style" and "reports" express the service layer decides which responsibilities remain with the consumer and which become platform obligations. For virtual Sensor as Contract, the observed relationship between "IaaS-Style" and "reports" is evidence that "IaaS-Style" carries into the next decision.

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

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

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.

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

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.19 What’s Next

Study adoption value and risks in S2aaS Value Creation and Challenges.
Check ownership and privacy constraints in S2aaS Data Ownership.
Move from concepts to implementation with S2aaS Implementations.
Compare architecture options in S2aaS Architecture Patterns.
Use S2aaS Readiness Check after completing the S2aaS section.

44.20 Key Takeaway

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.