1.2M sensors. 40 municipalities. One civic platform.
How XRDA3 designed and deployed a 1.2-million-sensor mesh across 40 municipalities — air quality, traffic, water, and energy — with cloud-side predictive analytics serving 1.4 million citizens through dashboards, mobile apps, and a public-API tier.
IoT + Data + AI
The challenge
Replace fragmented, vendor-locked municipal sensing systems across 40 cities with a single, regionally-owned mesh — without taking critical infrastructure offline and without abandoning sunk hardware investments.
Each municipality had been buying smart-city sensors from different vendors over a decade — air quality from one supplier, traffic from another, water meters from a third. None of these systems talked to each other. Decisions about pollution mitigation, traffic flow, and water conservation were being made on stale, disconnected data.
The brief was simultaneously ambitious and conservative: build one platform that all 40 municipalities could use, supports any sensor (not just new ones), runs on regional cloud infrastructure for data residency, and delivers value within the first 12 weeks — not the first two years.
The approach
A vendor-neutral edge gateway plus a unified cloud platform — designed to ingest legacy sensor protocols on day one and accept new LoRaWAN deployments as municipalities chose to expand.
The architectural choice that unblocked everything: stop trying to standardise the sensors. Standardise the gateway instead. We built a configurable LoRaWAN + cellular gateway that ingests common municipal protocols (Modbus, MQTT, CoAP, proprietary RS-485 dialects) and translates everything to a unified internal schema before sending it to cloud.
This let municipalities keep their existing sensor investments while still joining the platform. New deployments flow through the same gateway, just over LoRaWAN. The cloud-side platform has no idea — or care — what brand of sensor produced a reading.
Predictive models — congestion forecasting, pollution-event detection, water-leak inference — run as cloud services consumed by municipal dashboards, public-facing apps, and a paid-tier API for researchers and partner ministries.
What we built
- Edge gateway hardware spec — partnered with a regional contract manufacturer; designed firmware in Zephyr RTOS with secure boot and OTA updates
- 1.2M sensor onboarding across air quality, traffic flow, water meters, energy meters, smart streetlights, and noise sensors
- LoRaWAN backhaul network with 4,200 gateways covering urban, suburban, and rural municipalities
- Cloud platform on BigQuery ingesting 8B events / day with sub-2-minute end-to-end latency from sensor to dashboard
- Predictive ML models on Vertex AI — congestion forecasting (15 / 30 / 60 min horizons), air-quality event detection, water-leak inference, energy-demand prediction
- Municipal dashboards in Looker — one workspace per municipality with drill-down, alerts, and PDF / press-ready exports
- Citizen-facing mobile apps (iOS + Android, English + Arabic) — air quality near you, traffic, water alerts
- Public-API tier with rate limits, API keys, and OpenAPI spec — used by researchers, partner ministries, and journalism teams
- Operations centre 24/7 — mesh health monitoring, sensor anomaly detection, automated trouble-ticket dispatch to municipal field teams
Tech stack
Flutter · iOS + Android · English + ArabicOutcomes
Honest reflections
The hardest single technical problem was integrating the legacy sensor protocols. Some vendors had documentation; some had been acquired; one supplier had gone out of business in 2019, and the only working integration was a Python script running on a desktop PC in a municipal basement. We rebuilt that integration cleanly and now treat the gateway protocol library as a strategic asset the platform extends rather than a burden it tolerates.
The predictive ML work was the second-hardest. Smart-city models break in unexpected ways — sensor drift, holidays, construction, weather anomalies. We learned to ship every model alongside a "this prediction is unreliable today" signal, derived from input distribution monitoring. Operators trust models more when models tell them when not to trust them.
The lesson that travels: smart-city programmes fail when they treat data integration as an afterthought to sensor deployment. We treated it as the primary engineering challenge from week one — and that decision is why this programme is in production while others nearby remain in pilot.
Capabilities used
Smart-city or large-scale IoT programme on the horizon?
Whether you're starting from scratch or rescuing a stalled deployment — we'd like to hear about it.