50  Virtual Sensors and Service Models

Virtual Sensors, Discovery, Subscriptions, and Service-Layer Choice

emerging-paradigms
s2aas
core
concepts

50.1 Start Simple

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.

50.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?

50.3 Concept Map

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

50.3.1 Resource

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

50.3.2 Contract

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

50.3.3 Delivery

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

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

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

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

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

50.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.
Discovery Rule

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

50.6 Discovery and Registration

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

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

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

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

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

50.7 Marketplace Roles and Incentives

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

50.7.1 Sensor Owner

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

50.7.2 Platform Operator

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

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

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

S2aaS subscription lifecycle from registration through discovery, subscription, delivery, metering, audit, and renewal or revocation.
Figure 50.2: S2aaS subscription lifecycle from resource registration through discovery, subscription, delivery, metering, audit, and renewal or revocation.

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.

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

50.9.1 Technical Quality

  • Calibration state
  • Sampling interval
  • Latency and jitter
  • Completeness
  • Outlier handling
  • Fallback source behavior

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

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

50.11 Knowledge Check

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

Label the Core Model

Code Challenge: Build a Discovery Filter

50.13 Common Pitfalls

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

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

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

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

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

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

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.

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

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

  • Semantic mismatch: two resources with similar labels may differ by unit, averaging window, spatial scope, calibration procedure, or feature of interest.
  • Quality drift: a once-valid subscription can become invalid after calibration expiry, device movement, missing data, or increased latency.
  • Policy bleed: a tenant uses data for redistribution, profiling, or retention beyond the allowed service terms.
  • Subscription zombie: expired or revoked access keeps delivering data because renewal, revocation, and audit paths are not enforced.

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

50.19 What’s Next

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