What is meant by a smart building, and where does it fit inside a smart city?
A smart building is one where the individual systems — HVAC, lighting, access control, life-safety, elevators — are networked together and share data through a common platform instead of running as separate, unconnected installations. That is the definition used by the Telecommunications Industry Association, which frames the smart building as an integration problem as much as a hardware one: the value comes from the systems talking to each other, not from any single sensor. Cisco describes the same idea from the network side — a smart building is one where IT and operational-technology networks converge so the building can make real-time decisions rather than run on a fixed schedule.
A smart city is the same pattern scaled up: a connected urban area using networked devices and the data they produce to run public services — traffic signals, street lighting, waste collection, water and air monitoring — rather than running each service on its own separate, unmonitored schedule. The mechanics are identical to a single smart building's: sensors, a network to carry readings, a platform to store and process them, and an application layer that turns the processed data into an action. The difference is scale and ownership — a smart building answers to one facilities team, a smart city answers to a procurement office, multiple departments, and often several contractors, which is exactly where vendor lock-in becomes a city-wide problem rather than a building-wide one.
It's also worth separating a genuine programme from a pilot. A single block of smart streetlights or one instrumented intersection is a pilot; a smart city deployment is what happens when that pattern is repeated across a network of assets on shared infrastructure, with the data feeding one operational platform rather than sitting in a spreadsheet from a single vendor demo.
Traffic congestion on arterial roads: the full sensor-to-action loop
Congestion on an arterial road isn't fixed by installing sensors — it's fixed by a loop that runs from the pavement to the signal controller and back, and every stage of that loop is a separate purchasing decision.
- Road and parking sensors — inductive loops, radar units, or camera-based counters — record vehicle flow, occupancy, and speed at intersections and parking bays.
- A connectivity network, usually cellular or a low-power wide-area link, carries those readings from the roadside device to the city's IoT platform.
- The platform ingests the readings, and an analytics layer compares current flow against expected patterns.
- Based on that comparison, the analytics layer adjusts signal timing, extends green phases on congested approaches, or routes drivers toward available parking through connected signage or a navigation feed.
- Congestion and vehicle idling time fall as the loop repeats continuously rather than running on the fixed timing plans that most legacy signal systems still use.
The reason this loop matters more than any single "smart traffic" product is that it only works end to end if each stage can be swapped independently. A traffic system where the camera, the roadside controller, and the analytics dashboard are all proprietary to one manufacturer means the city can't add a second sensor vendor, switch connectivity providers, or move the analytics workload elsewhere without renegotiating the whole contract. That single-vendor bundling is the first place lock-in enters a smart city programme, and it usually enters at the procurement stage, long before the first sensor is bolted to a pole.
High municipal energy and collection costs
Two of the most commonly cited savings in smart city pitches — street lighting and waste collection — rest on the same mechanism as the traffic loop: measure actual demand, then act on it instead of a fixed schedule.
Street-light controllers report usage and ambient light levels back to the platform, which can then dim or brighten fixtures based on real pedestrian and vehicle traffic rather than a preset dusk-to-dawn timer. Bin fill-level sensors report how full a container actually is, and the platform uses that to build collection routes around bins that need emptying rather than a fixed weekly round that visits every bin regardless of fill state. The result, in both cases, is that energy use and truck trips fall because the system is responding to measured demand instead of a calendar.
The lock-in risk here is quieter than in traffic systems, because streetlight and waste contracts are often signed asset-by-asset with the hardware vendor supplying both the sensor and the only platform it will talk to. When that contract ends, or when the city wants to add a second sensor type to the same network, the fixtures and bins already in the ground may not report to anything else. Specifying an open reporting protocol for street-light controllers and bin sensors at the point of purchase — rather than accepting whatever the fixture vendor bundles by default — is what keeps that hardware usable after a platform change.
Thousands of low-cost devices deployed across public infrastructure
A city-scale deployment means thousands of low-cost endpoints spread across public infrastructure, and each one is a device that has to be inventoried, monitored, and patched — which most cities are not set up to do at that scale. Cisco points out that connecting operational technology — the sensors, controllers, and building or infrastructure systems that were never designed to be networked — to IT networks widens the attack surface that a security team has to defend, because each connected endpoint is a potential entry point rather than an isolated appliance.
For a city, the consequence isn't abstract: a compromised traffic controller, streetlight gateway, or water sensor can disrupt a public service directly, and a compromised platform account can expose the urban data those thousands of devices were collecting. The mitigation isn't a single product — it's an operational discipline:
- Maintain a device inventory that records make, firmware version, and network segment for every deployed sensor and controller.
- Monitor for devices that stop reporting or start reporting outside expected ranges, which is often the first sign of tampering or failure.
- Patch or replace firmware on a defined schedule, and retire devices whose vendor has stopped issuing security updates rather than leaving them connected indefinitely.
Treating security this way turns it into a deployment requirement — something specified in the procurement contract alongside sensor accuracy and battery life — rather than something added after an incident.
The five layers of a smart city deployment
Every smart city application, from adaptive traffic signals to bin-fill routing, is built from the same five layers, and understanding them separately is what makes it possible to buy each one from a different supplier.
Smart city
The urban area itself, treated as the system: the connected devices, the networks, and the platforms working together to run public services like traffic, lighting, waste, water, and air-quality monitoring.
Internet of Things (IoT)
The general term for networked sensors and devices that collect and exchange data — the technology category a smart city is built on top of, not a product in itself.
IoT sensor
The field device that takes the actual measurement — a traffic counter, an air-quality node, a water-level probe, a fill-level sensor in a bin, or a meter on a streetlight circuit.
Connectivity network
The link that carries a sensor's reading to the platform — typically a cellular connection or a low-power wide-area network chosen for range and battery life rather than raw throughput.
IoT platform
The software layer that ingests readings from the connectivity network, stores them, and manages the fleet of devices, providing the data that the analytics and application layers act on. IBM describes this stack — sensors feeding a platform that stores and manages the data before analytics turns it into an operational decision — as the standard shape of a smart building's data flow, and the same shape holds at city scale.
Where vendor lock-in actually happens, layer by layer
Lock-in rarely happens all at once — it accumulates one layer at a time, and each layer has a different failure mode.
| Layer | Where lock-in creeps in | What keeps it swappable |
|---|---|---|
| Sensor | Proprietary radio or wired protocol that only talks to one gateway | Sensors specified against an open standard the platform must support, not the other way round |
| Connectivity | Long-term carrier or LPWAN contract bundled with the sensor purchase | Connectivity procured separately from the device and platform contracts |
| Platform | Closed data export, no documented API, per-device licensing tied to one vendor's dashboard | Platform contract requires documented APIs and full data export in an open format |
| Analytics | Proprietary models trained only on that vendor's data schema | Analytics run on exported data rather than inside a closed dashboard |
| Application | Dashboards and alerts that only display data from that vendor's own sensors | Application layer built to consume data from any platform meeting the same API contract |
The pattern across every row is the same: lock-in happens wherever a contract bundles two layers that don't need to be bundled. A sensor vendor that also insists on supplying the platform, or a platform vendor that also insists on supplying the analytics, is asking the city to give up the ability to renegotiate any one layer independently later.
Procurement choices that keep the layers swappable
Interoperability between vendor platforms is a purchasing decision made before any hardware ships, not something fixed after the fact. Autodesk lists the move toward open data standards and cross-system interoperability as one of the clearer trends in building technology, precisely because closed, single-vendor stacks have been the recurring complaint from owners who want to add a system later without ripping out the first one.
For a city or a building owner, the practical version of that trend is a short set of procurement requirements rather than a technology choice:
- Require that sensors and gateways support an open, documented protocol rather than a proprietary one exclusive to the platform vendor.
- Require full, machine-readable data export from the platform as a contract condition, not a paid add-on.
- Separate the connectivity contract from the device and platform contracts wherever the network technology allows it.
- Score bids partly on documented API access and exit terms, not only on unit price per device.
Retrofits and new-build districts differ mainly in how much of this can be enforced at once: a new district can specify open standards across every layer from day one, while a retrofit has to work around whatever wiring, conduit, and legacy controllers are already in the ground, and often has to add an open gateway layer on top of existing proprietary sensors rather than replacing them outright. UBE's overview of smart buildings frames this as a built-environment problem rather than a purely technical one — the constraint is as much about who controls the existing infrastructure as it is about the sensors themselves.
What to check before signing the next contract
Before any sensor is ordered, a city or building team can ask the same three questions of every vendor on the table: what open standard does the device speak, can the full dataset be exported without a paid connector, and what happens to the installed hardware if the platform contract ends. A vendor that can't answer all three in writing is proposing a bundle, not a component — and the bundle is the thing that becomes expensive to unwind five years into the deployment.