IoT & Smart Cities
City infrastructure that shares what it senses.
ColdAI designs connected infrastructure for cities, campuses and public assets: the sensor networks, interoperable data platforms, operational-technology security and public-data governance that let an operator add services one at a time. The aim is a city that owns its data and can replace any device, network or platform supplier without starting again, and that can explain to residents what it collects and why.
The opportunity
Start with a decision
worth improving.
A city wants to coordinate traffic signals, street lighting and air-quality monitoring bought from different suppliers. Each system works on its own; none can share data with the others.
From possibility to a working system
Follow the flow.
Three connected decisions. One considered architecture.
Conceptual flow, not a live system or measured result.
Connect the assets
Survey existing sensors, controllers and networks, then choose connectivity, such as LoRaWAN, NB-IoT, LTE-M or fiber, for each class of device based on range, power and data needs.
Share a common model
Publish observations through open data models and APIs, such as OGC SensorThings or NGSI-LD, so new services can use the same data without a bespoke integration for every supplier.
Operate in public
Secure operational technology against recognized standards such as IEC 62443, set clear rules for personal and location data, and publish what is collected and why. Plan for assets that outlast several software generations.
The work, made concrete
What we can build
with your team.
We agree scope, dependencies and acceptance criteria before delivery. Your project can start with an assessment, a pilot or an integration into an existing system.
Asset, network and data-flow assessment
Clarify the system boundary, the responsible owners and the decisions the architecture needs to support.
An interoperable urban data platform design
Turn the agreed design into reviewable work, evaluated against representative inputs and explicit success criteria.
Security, privacy and procurement guidance
Make the next step operable: document responsibilities, known limitations and the path from pilot to ongoing use.
In depth
Go deeper: networks and standards for city data
Two decisions shape every connected-city platform: which radio network each class of sensor uses, and which standards keep the data portable above it.
- 01ComparisonLoRaWAN vs NB-IoT vs LTE-M for city sensor networksHow LoRaWAN, NB-IoT, LTE-M and Wi-SUN compare for parking, waste, air-quality, metering and lighting sensors, and how to pick connectivity per device class.
- 02Deep diveSmart city interoperability standards: NGSI-LD to MIMsHow NGSI-LD, FIWARE Smart Data Models, OGC SensorThings, oneM2M and the OASC MIMs fit together in a city data platform, and how to test conformance.
Where a connected-city program should start
Start from a service someone is accountable for, not from a platform purchase.
- If
A large asset replacement is already funded, such as an LED streetlight program.
ThenSpecify controllers with open, standards-based interfaces and city-owned data as part of that replacement.
Adding connectivity during a planned replacement is usually cheaper and causes less street work than retrofitting later, and it sets the data rules for everything after.
- If
A specific public problem has an owner, such as air-quality complaints or parking enforcement.
ThenScope a bounded deployment around that service, with an agreed measure of whether it helped.
A named owner and a measurable outcome are what carry a pilot into the operating budget.
- If
Several departments already run sensor systems that cannot share data.
ThenPut an interoperable data layer above the existing systems before buying more devices.
Every new silo raises the cost of joining them later.
- If
Nobody owns operations, maintenance or the data once a pilot ends.
ThenPause and settle ownership first.
Unowned sensors decay quietly, and resident trust suffers when abandoned devices stay on poles.
Each platform layer runs on its own replacement clock
Street assets, networks and software age at very different rates. Designing for that mismatch is most of what avoiding lock-in means in practice.
| Layer | What forces change | Lock-in symptom | Design response |
|---|---|---|---|
| Field devices and controllers | Failure, battery end of life, new sensing needs | Only one vendor's devices can talk to the platform | Require open data models and documented device interfaces |
| Connectivity | Operator network retirement, coverage changes, contract renewal | Devices tied to one network server or operator | Choose per device class; keep provisioning exportable |
| Data platform | Contract end, scale, new integration needs | Applications written to a proprietary API | Standard context and observation APIs, tested before go-live |
| Applications | Changing services, policies and user needs | Dashboards that only work with one platform | Build on the city's APIs, not the vendor's internal ones |
| Data and identifiers | Should never be forced to change | History lost when a supplier leaves | City-owned identifiers, models and exports |
The bottom row is the one to protect at all costs; every other layer can be replaced if the data and identifiers stay with the city.
Operating a public sensor estate as a continuous cycle
- Register the purpose
Record what each sensor is for, who owns it and what it collects, before installation.
- Assess privacy and risk
Run a data protection impact assessment where personal or location data is involved.
- Install and secure
Harden the device and its network path, and record it in the asset system.
- Publish and share
Expose data through the city's APIs and, where appropriate, as open data.
- Monitor and patch
Watch device health, apply security updates and fix data quality issues.
- Review or retire
Check the sensor still serves its purpose; remove it and its data when it does not.
Securing controllers, cabinets and poles as operational technology
A traffic signal controller or a lighting gateway is operational technology: compromising it changes something in the physical world. Treat street equipment the way industrial sites treat control systems. The ISA/IEC 62443 series organizes this around zones and conduits, security levels and shared responsibilities between asset owners, integrators and product suppliers2. For consumer-grade connected devices that end up in public buildings, ETSI EN 303 645 sets a baseline covering default passwords, update policies and vulnerability disclosure3.
Regulation now reaches the suppliers too. The EU Cyber Resilience Act, Regulation (EU) 2024/2847, places security obligations on manufacturers of products with digital elements4, which gives cities a firmer basis for asking about support periods and vulnerability handling in tenders. Where a city or utility is itself in scope of NIS2, the NIS2 compliance guide covers the operator's side.
Public data rules to settle before the first sensor goes up
Why connected-city pilots stall after the demo
Pilot funded, operations not
Early signalNo budget line for maintenance, connectivity or batteries after the pilot year.
MitigationPrice the full life of the assets before approving the pilot, and assign an operating owner.
Supplier owns the dashboard and the data
Early signalData can only be seen in the vendor's portal, with no export path.
MitigationRequire standard APIs, city-owned data and a tested export before acceptance.
Technology looking for a problem
Early signalThe business case lists capabilities but no service owner or outcome.
MitigationTie every deployment to a service, a measure and the person who will use the data.
Public trust lost early
Early signalResidents learn about sensors from press coverage rather than the city.
MitigationPublish the sensor register and purposes before installation, and keep identifying technologies out unless clearly justified.
What ColdAI designs in connected-city work, and adjacent practices
Our part is design and integration: an asset, network and data-flow assessment, an interoperable urban data platform design, and security, privacy and procurement guidance1. We work from a specific public service to improve, an inventory of existing sensors and systems, and owners across IT, operations and policy. We do not manufacture devices or operate mobile networks, and we will say when an existing supplier's platform already meets the need.
Related work sits in neighboring practices: running inference on devices and gateways is covered by edge AI and IoT, simulation of networks and assets by digital twins, and equipment health by predictive monitoring.
Frequently asked questions
What does a smart city IoT engagement with ColdAI produce?
Typically an assessment of existing assets, networks and data flows, a design for an interoperable urban data platform, and guidance on security, privacy and procurement. The starting point is one public service to improve, an inventory of current sensors and systems, and named owners in IT, operations and policy.
How can a city avoid single-vendor lock-in on a smart city platform?
Separate the layers and standardize the boundaries between them. Keep identifiers, data models and data under city ownership, require standard APIs for context and observations, choose connectivity per device class and test a full export before accepting any platform. Contract terms should cover exit and data return as well as delivery.
Should a campus or university approach IoT differently from a city?
The principles are the same, but a campus usually controls its own buildings, networks and identity systems, which makes private networks and integration with building management easier. Governance still matters: students and staff need the same transparency about sensors, data and retention that residents should expect from a city.
Are cameras part of a smart city sensor network?
They can be, but they raise the strongest privacy concerns and often fall under specific surveillance and data protection rules. Prefer sensors that measure only what the service needs, such as counts or occupancy, and use video only where a documented assessment justifies it, with processing that discards images as early as possible.
Who should own the data from city sensors?
The city or public body should, with suppliers processing it only to deliver the contract. Ownership should be explicit in the contract and backed by technical means: data delivered into city-controlled platforms through standard APIs, with exports tested, so ownership does not depend on a supplier's cooperation at the end of the contract.
Sources
- IoT & Smart Cities — ColdAI
- ISA/IEC 62443 series of standards — International Society of Automation
- ETSI EN 303 645: Cyber Security for Consumer Internet of Things: Baseline Requirements — ETSI
- Regulation (EU) 2024/2847 (Cyber Resilience Act) — EUR-Lex
Connect the architecture
The next connection.
Explore the complementary capabilities that can turn an individual technology into a complete workflow.
Your next move
Bring us the
real problem.
A workflow that takes too long. A system that cannot connect. An idea that needs a technical path. Start there, and we can define what to investigate, build and measure.
- A specific public service to improve
- An inventory of existing sensors and systems
- Owners across IT, operations and policy