Smart City Pilots That Can't Talk to Each Other

"Smart city" pilot projects — integrating sensor networks, data platforms, and automated decision systems to improve urban transportation, energy, water, and public safety — fail at an alarmingly high rate because the cyber-physical systems from different vendors, deployed for different functions, cannot interoperate. A traffic sensor network from one vendor generates data in a proprietary format that the city's analytics platform from another vendor cannot ingest in real time. An emergency response system cannot access building energy management data during a crisis because they operate on different network protocols with different security models. No standards exist for composing independently developed CPS into city-scale systems-of-systems, and no framework can verify that composed systems maintain safety and performance properties that held for individual subsystems.

Cities worldwide have committed over $200 billion to smart city initiatives, yet research by McKinsey and the Smart Cities Council finds that 75-80% of smart city projects stall or fail during integration. The NSF Smart and Connected Communities program has funded over 100 research projects, generating valuable individual system innovations that cannot be deployed together at community scale. The inability to integrate CPS across domains (transportation + energy + water + emergency response) means that the cross-domain coordination benefits that justify smart city investments — such as reducing energy consumption by coordinating traffic signals with building HVAC during peak demand — remain unrealized.

Open data standards (JSON-LD, SensorThings API, FIWARE NGSI-LD) enable data sharing between systems but don't address real-time control integration, timing requirements, or safety constraints that distinguish CPS from pure IT systems. Middleware platforms (FIWARE, CityOS) provide service-oriented architecture for smart city data but treat all data as equivalent, ignoring the hard real-time requirements of traffic control or emergency response. Digital twin platforms (Unity, Nvidia Omniverse) can visualize multi-domain city data but don't provide the formal guarantees needed for closed-loop control. API-based integration creates brittle point-to-point connections that break when any component is updated. The root cause is that CPS interoperability requires agreement not just on data formats but on timing, safety invariants, failure modes, and degraded-mode operation — none of which current standards address.

A formal framework for specifying and verifying CPS-of-CPS composition, defining how individual system guarantees (latency, safety, reliability) compose when systems are interconnected. Standard interface contracts that specify not just data formats but temporal requirements, safety preconditions, and degraded-mode behaviors. A reference architecture for community-scale CPS integration that has been validated in real deployments, not just simulation, providing a blueprint that communities can adapt rather than reinventing integration from scratch.

A student team could select two specific smart city subsystems (e.g., traffic signal control and building energy management) and develop an interoperability adapter that enables real-time data exchange and coordinated control, testing it on a campus or neighborhood-scale testbed. Alternatively, a team could analyze failure reports from 5-10 published smart city pilot projects and develop a taxonomy of integration failure modes, creating a design checklist for future deployments. Relevant disciplines include systems engineering, computer science, urban planning, and electrical engineering.