Smart City Infrastructure: From Sensors to an Urban Data Platform

Smart city as infrastructure, not a collection of apps

Many smart city projects start with a single use case: smart parking, street lighting or remote meter reading. If every use case brings its own network, platform and data format, the city ends up after a few years with a set of isolated systems that do not talk to each other and each carry their own maintenance costs. An infrastructure view designs smart city infrastructure as a small number of shared layers:

1. Sensing and field layer: sensors, meters, controllers and actuators.
2. Connectivity layer: the networks that carry data from the field to the center.
3. Urban data platform: ingestion, device management, storage and data provision.
4. Application layer: dashboards, operational systems and citizen services.

Governance, security and privacy are not a separate layer. They have to be present in every layer.

The sensing layer: common use cases

• Air quality: particulate matter, NO₂, O₃ and environmental parameters. Low-cost sensors allow dense networks, but calibration and periodic comparison with reference stations are essential.
• Parking: per-space occupancy sensors or entry/exit counting to guide drivers and manage capacity.
• Street lighting: remote control, scheduled dimming and automatic fault reporting.
• Waste: fill-level sensors in containers to plan collection routes.
• Water networks: pressure, flow and leak monitoring in distribution networks and pumping stations.
• Metering: smart reading of water, electricity, gas and heat meters, including retrofitting existing meters.

Choosing sensors on datasheet specifications alone is not enough. Battery life under the real transmission profile, IP rating, mounting and vandal resistance, remote update capability and the manufacturer's product roadmap all matter for a device that may stay in the field for many years.

The connectivity layer: choose per use case

A city usually needs a mix of technologies. A network-neutral approach means checking, for each use case, which networks are actually available and which ownership model makes sense: a public operator network, city-operated gateways or a community network.

Before deciding, clarify existing coverage maps, take field measurements at difficult locations such as basements and meter pits, and define who operates and maintains the gateways.

Urban data platform and open standards

The urban data platform is the shared core for all use cases. Its main tasks are ingesting data from different networks, managing the device lifecycle, normalizing and storing time-series data, controlling access, and providing data to applications through APIs and, where appropriate, as open data.

Why open standards matter

The largest long-term risk is vendor lock-in. Open interfaces and data models reduce it. Examples used in this field include:

• NGSI-LD (an ETSI specification) and the FIWARE data models for describing urban entities.
• OGC SensorThings API for sensor observations.
• oneM2M as a service-layer framework for M2M and IoT.
• MQTT and LwM2M for transport and device management, and protocols such as DLMS/COSEM in metering.

Platform selection criteria

Whether the platform is open source, commercial or a combination, a few criteria help compare options: support for several network types and payload decoders, multi-tenancy so that departments and utilities can work separately on shared infrastructure, a documented API, scalable time-series storage, role and permission management, and a realistic operating model including updates, backups and monitoring. Self-hosting gives control over data location; managed services reduce operational effort. Both are valid, as long as the decision is deliberate.

Procurement documents can explicitly require access to raw data through documented interfaces, full data export and city ownership of the data. These clauses are far easier to include at the start than to negotiate later.

Privacy by design and data governance

Some urban data, such as a household's energy consumption profile or camera images, can be linked to individuals. Privacy by design, as required for example by Article 25 of the GDPR, means in practice:

• Collect only the data needed for a defined purpose (data minimization).
• Aggregate or anonymize at the edge wherever possible, for example counting instead of storing images.
• Define retention periods and delete data automatically.
• Encrypt data in transit and at rest and enforce role-based access control.
• Comply with the data protection law that applies in the respective country.

Data governance defines who owns each dataset, who is responsible for its quality, who may access it and which data is published openly. Without these roles, a technical platform alone will not lead to data sharing between city departments and utilities.

Operations, maintenance and the path from pilot to scale

Much of the cost and complexity of an urban IoT deployment begins after installation: battery replacement, recalibration, damaged or stolen devices, firmware updates, certificate renewal and user support. These need to be part of the design and the budget, for example by monitoring device health (battery level, last uplink, signal quality) on the same platform.

A staged roadmap

1. Define the problem: operational goal, stakeholders and measurable success criteria.
2. Reference architecture: decide on shared layers, standards and governance before the first purchase.
3. Limited pilot: one or two use cases in a defined area, with technical and organizational evaluation.
4. Evaluate and decide: compare results with the criteria and adjust the architecture instead of simply extending the pilot.
5. Scale: add use cases and areas on the same platform and networks.

A frequent failure pattern is the pilot that never ends: technically successful, but without an owner, budget line or operating model for the rollout. Planning operations during the pilot phase avoids it.

Conclusion

Smart city infrastructure is sustainable when layers are shared, interfaces are open, governance roles are clear and operations are planned from the beginning. The pages on smart city infrastructure, smart metering and IoT consulting describe the approach, and you can discuss a specific project via the contact page.