logo
Smart Cities SIG

Public Watering Walkthrough

Overview

This walkthrough shows how the Smart Cities SIG methodology was used to analyze city operations around public park irrigation and water metering.

The objective is to decide how water use should be represented in a city digital twin. Ultimately, the people who look after the plants want the model to reflect what really matters to them: the water around the roots under the right conditions, and the meaning behind what the twin is showing.

In this use case, we need to clearly distinguish between values that are directly measured, values that are estimated or predicted, and values that are generated by simulation or other synthetic processes.

Once the information is exposed as a Smart Data Model, every single data point should be fully described so that it stays interpretable from the device layer all the way up to the city digital twin. Each selected data object from the OMA IPSO catalogue will have a corresponding Smart Data Model entity, where the relevant context information is either captured explicitly or can be reliably derived.

Purpose of the use case

In public-space irrigation, the operational objective is not merely to know that a valve opened, but to characterize watering in a way that supports service efficiency, sustainability, and meaningful comparison between deployments. The key point is the physical reality of water delivery to vegetation and its representation in the digital twin, while acknowledging that many systems only observe proxies such as consumed water, valve-open time, or inferred flow, which are just tools to approximate that reality

From a modelling perspective, this means the data model must distinguish between what is directly measured, what is inferred from operation, and what is contextual information that explains why a watering event happened or whether it was appropriate. This is especially important for municipal reuse across departments, operators, and data spaces.

A KPI is not raw data; it is an aggregated value calculated from multiple data sources over a period of time.

What really matters is how valid and meaningful that KPI is, given how it was computed and which data went into it, so that we can reliably answer “how should I interpret what the Digital Twin is showing?”.

That interpretation depends on the underlying data: whether it comes from direct measurements, indirect estimates, or simulated information.

It is crucial to pick relevant data and to understand its minimum required precision and accuracy, how complete the dataset is, how consistent it is across sources, how timely it is, and the level of confidence or uncertainty we can attach to it.

In practice, the goal for this SIG is to define a data set that is rich enough to support a meaningful city digital twin, and to be explicit about the degree of certainty that users can assume when they work with it. And then map it with OMA objects, and their equivalent Smart Data Models counterparts.

Stage 1 - Operational Meaning Discovery

Main quantities to capture

The objective is to identify the following core quantities and dimensions for the irrigation use case:

  • Water volume per unit of time, or over a specified time interval; the unit must be made explicit, for example litres or cubic metres.
  • Timestamp of the observation, including whether it refers to the start instant, the end instant, or the period represented.
  • Soil-related environmental parameters such as temperature, pH, and other soil conditions relevant to irrigation decisions.
  • Water pressure in soil vs in pipes.
  • Weather at the time of measurement, plus weather forecast when relevant to irrigation planning.
  • Characteristics of the supplied water, such as whether it is recycled water or potable water.

The specification also makes clear that precision and temporal resolution must be standardized enough to preserve comparability. In practice, the minimum and maximum measurable values, the acceptable increment or precision, and the minimum temporal granularity should be explicitly stated for each deployment profile.

Dynamic range and resolution

The irrigation specification stresses that stating a nominal unit is not sufficient; the model should also define the valid measurement range and minimum meaningful precision. It gives the example that saying “1 litre per minute” is not enough if the error margin is larger than the intended operational value.

Likewise, temporal resolution should be explicit, because a system designed for minute-level reporting cannot later support second-level comparison in the digital twin. The document also notes that city platforms may aggregate older historical data into coarser intervals, but the real-time reference value still needs to be defined with awareness of energy use and battery-life implications in field devices.

Operational parameters

Beyond primary flow or volume, a set of operational parameters help explain irrigation behavior and interpret measurements correctly. These include soil temperature, soil pH, other soil environmental parameters, weather conditions at the time of irrigation, forecast weather, water pressure, and attributes of the water itself.

The irrigation method matters, for example drip irrigation versus sprinkler irrigation. That distinction affects both the interpretation of efficiency and the relation between measured consumption and the agronomic objective of delivering water to roots.

Measurement conditions

A key modelling issue is the difference between evidence and indication. In many installations, the directly known fact is that a valve opened for a given time, while the actual delivered flow may only be inferred from pipe section, nominal flow, and opening duration.

It is important to explicitly encode the measurement conditions or provenance of each value so downstream users can see whether the flow was directly metered or indirectly inferred. This distinction is key for trustworthy benchmarking, auditing, and digital‑twin interpretation across heterogeneous municipal systems.

Actuators and controllability

The valves that start or stop irrigation are relevant operational components even if they are not themselves direct value sources for water-flow measurement. Their role is to provide control context and, in some cases, support inference of delivered water when combined with known hydraulic characteristics and elapsed opening time.

Network-operation characteristics that may be relevant to the use case includes response latency, packet loss, and the device’s capacity to continue operating according to a programmed schedule even when advanced intelligent control is unavailable. This is important for exceptional situations such as drought conditions, breakdowns, or restricted-access operations requiring elevated permissions.

Context metadata

Special weight to context metadata should be given because location and installation conditions are not always generated by the device itself. Important contextual fields include installation location, management zone, responsible parties, associated contracts, incident-resolution channels, warranty and service-life information, vegetation type covered by the irrigation asset, orientation, slope, and shading from trees or buildings, as well as ambient air humidity and temperature.

This context is necessary to interpret whether a measured or inferred watering value is adequate for the vegetation served and the surrounding environment. Without it, the same flow value may mean very different things in different parts of a city.

Data-quality KPIs

For this SIG, in every use case and, of course, in the irrigation and water mettering case, a KPI-oriented section is mandatory, focused on data quality. This must include completeness, consistency, relevance, precision, timeliness and availability, and reliability, including lack of uncertainty or stated statistical confidence.

These criteria can be treated as cross-cutting acceptance conditions for any Smart Data Model mapping in this use case. They help distinguish a merely available signal from a signal that is fit for operational comparison, automation, and inter-city exchange.

Suggested entity view

A practical decomposition is the following:

  • Irrigation zone, representing the managed public-space area or vegetation area being watered.
  • Water meter or flow-observation point, representing direct metering of consumed or delivered water where available.
  • Valve or irrigation controller, representing the actuator that enables, disables, or schedules irrigation.
  • Soil or environmental observation, representing soil and weather measurements that condition watering decisions.
  • Watering event or watering session, representing the time-bounded operation that should be interpreted in the digital twin.

The SIG needs to map different municipal deployments without forcing every city to use the same hardware topology, but to be able to compare the service they provide been able to go from measurement, inferred values, actuation, and context distinguishable, to KPIs.

Several modelling rules shoul de madee explicit, so that implementers can build consistent examples:

  • Always declare whether the reported watering value is directly measured, estimated, predicted, or synthetic.
  • Always declare the unit and observation interval for water quantities.
  • Encode whether the value refers to consumed water, estimated delivered water, or another derived concept.
  • Include irrigation method, because drip and sprinkler systems are not semantically equivalent.
  • Include minimum resolution and dynamic range assumptions in the profile or implementation guidance.
  • Preserve context on vegetation type, shading, slope, and environmental conditions so the data remains meaningful in a digital twin.

References