Smart Cities SIG Methodology Worksheet

This worksheet is the practical template for analysing a Service Domain — public lighting, irrigation, waste collection, parking, and so on — during Stage 1 and Stage 2.

Each step names the semantic capabilities it feeds. The capabilities are defined only in Stage 2; this worksheet asks the questions that surface them for a specific service. For a filled-in example, see the lighting vs irrigation comparison.

0. User stories and entities

Feeds: Service Outcome; the entities and properties it identifies are examined in the steps that follow

Collect user stories from the people who run the service, in their own words, then draw up the entity sketch.

Example pattern:

" want to under so that ."

Questions to fill in:

• Who needs to do what, under which conditions, and why?
• Which types of entities do the stories mention?
• For each entity type, which properties, actions, and events do the stories mention?

1. Service outcome (what we really care about)

Feeds: Service Outcome

Define the ideal end state for people or assets, not for devices. Think through what the Digital Twin should show.

Example pattern:

"The target area meets or exceeds the minimum service metric required by the reference standard, ideally measured directly where the service is actually delivered."

Questions to fill in:

• What is the real-world effect we want to guarantee?
• Where should it be measured physically (surface, roots, lane, bin, bay, etc.)?

2. Context that modulates the outcome

Feeds: Operational Context, Physical Context

List the environmental and operational conditions that change when or how much the system should act. Context refines default actions and handles edge cases; it does not replace a direct outcome measurement when one is available.

Questions to fill in:

• Which weather, usage, or environmental conditions change the need to act?
• When you do have direct outcome measurements, how does context only adjust the behaviour?

3. Primary physical quantity

Feeds: Service Outcome, Infrastructure Output, Resource Consumption

Identify the core physical quantity that best represents the service outcome. Keep device-centric quantities in a supporting role.

Questions to fill in:

• What single physical quantity best represents "service delivered" at the right place?
• Which related quantities describe device behaviour (infrastructure output) or cost (resource consumption), rather than the outcome itself?

4. Direct vs inferred measurement

Feeds: Observation Method

Separate direct measurements (observed at or close to the outcome) from inferred or derived values (calculated from other signals, models, or proxies), and make the method explicit for every value.

Questions to fill in:

• What do you measure directly at or near the outcome?
• What do you infer from other variables, curves, or models?
• How do you flag each value's observation method?

5. Observation level (where in the system you "look")

Feeds: Observation Point, Observation Scope

Describe at which system level measurements are taken, and at which level the service is evaluated. Common levels: device, component, segment or trunk, zone, site, city.

Questions to fill in:

• At what level do you usually measure (device, cabinet, sector, zone…)?
• At what level do you actually evaluate the service outcome for people or assets?

6. Typical raw data available

Feeds: Infrastructure Output, Resource Consumption, Network Operability

Enumerate the raw signals and events the infrastructure usually exposes: physical measurements, states, events, identifiers, and timestamps. Keep it technology-neutral but realistic.

Questions to fill in:

• What raw measurements do devices and platforms typically provide? Consider devices available on the market.
• Which states and events are observable (on/off, fault, mode, level…)?

7. Minimum metadata for comparability

Define the metadata required to compare data across vendors, deployments, cities, and time. For every value, record:

Questions to fill in:

• What do I need to know about a value so that two cities can safely compare it?
• How do I document how it was obtained in a machine-readable way?
• How can magnitudes with different margins and precisions be compared?

8. Typical KPIs (built from raw data)

Define service-oriented KPIs from the raw data and metadata above. KPIs aggregate over time and/or space, and KPI trust depends on knowing which inputs are measured versus inferred and their quality.

Questions to fill in:

• Which KPIs would a city manager or operator actually track for this service?
• For each KPI, what are the aggregation window, the scope, and the mix of measured and inferred inputs?

Next: mapping to semantic models

Mapping the service onto Smart Data Models and SAREF is part of Stage 4; see Mapping to Smart Data Models and Ontologies.