A modern mid-size city runs somewhere between 40 and 200 separate technology systems from dozens of vendors — traffic signals, parking sensors, water meters, air quality monitors, energy meters, building automation, transit fleet management, public safety, emergency dispatch. Each one was bought to solve a specific problem. Each one came with its own data format, its own API, its own dashboard, its own login. Each one works. None of them talk to each other. The result is the most common pattern in smart city deployments today: a hundred working systems and zero working ecosystem. A traffic management platform that can't read parking sensor data. An emergency dispatch system that can't query building occupancy. A climate resilience model that can't access stormwater telemetry. Decisions get made on partial information because the rest of the information lives behind a proprietary API the city doesn't own. Interoperability standards exist precisely to dismantle this Tower of Babel. NGSI-LD, OASC's Minimal Interoperability Mechanisms, FIWARE Smart Data Models, oneM2M, SAREF — these are not abstract IT specifications. They are the published, ratified, open standards that determine whether a city's data is a strategic asset or a liability locked inside someone else's product. iFactory's smart city infrastructure platform is built standards-first — designed to read, write, and translate across the open specifications cities actually need, so the next vendor purchase doesn't create the next data silo.
NGSI-LD · MIMs · FIWARE · Smart Data Models · oneM2M · SAREF
A Hundred Systems. Zero Ecosystem. That's the Default. Standards Fix It.
iFactory speaks the open specifications cities depend on — so data flows between vendors instead of getting trapped inside them, and the next system you buy doesn't create the next silo.
The Silo Tax — What Cities Actually Pay for Lack of Interoperability
A vendor-locked smart city pays for the same data three times: once to collect it, once to integrate it, and once again every time the contract is renewed.
Integration Cost
Custom adapters built for each vendor pair, paid over and over for every new system added
Renewal Leverage
Vendor knows the city can't migrate without rebuilding everything, so contracts get priced accordingly
Lost Value
Cross-domain insights (parking + traffic + transit) never get built because the data can't be joined
SME Exclusion
Smaller, more innovative suppliers can't compete because procurement requires the existing vendor's stack
The Five Layers Where Smart Cities Need Interoperability
"Interoperability" sounds singular, but it's actually a stack of five distinct kinds of agreement. Two systems can speak the same network protocol and still fail to integrate because they don't share the same data model — and the data model can match while authentication and access policies don't. Every layer needs to align for true ecosystem behavior to emerge.
Meaning & Context
Do both systems agree on what "occupancy" means? SAREF and the FIWARE Smart Data Models define shared vocabularies for entities, properties, and relationships across smart city domains.
Structure & Schema
How is a "parking space" represented as a digital entity, with what attributes, and in what shape? Smart Data Models (over 800 ratified) provide the canonical answer per domain.
Query & Subscribe
How does a system fetch, update, or subscribe to context data in real time? NGSI-LD (an ETSI specification) is the de-facto API standard for cross-domain context information management.
Network Protocols
MQTT, HTTP/HTTPS, AMQP, CoAP, LoRaWAN — the wire-level protocols that move bytes between sensors, gateways, and platforms. Mature and rarely a true blocker by themselves.
Layer 01
Identity & Access
Who Can Read or Write What
OAuth 2.0, OpenID Connect, role-based access control, and MIM 4 (Personal Data Management) define how systems authenticate each other and authorize each data exchange.
The Open Standards Map: What Actually Solves the Problem
A handful of open standards now form the practical backbone of multi-vendor smart cities. Each was created by a different organization (ETSI, OASC, FIWARE, oneM2M, TM Forum) and each handles a different piece of the stack. Knowing which is which is the difference between a procurement spec that actually delivers interoperability and one that just claims to.
Standard 01 · API Layer
NGSI-LD
ETSI ISG CIM
A published ETSI specification for managing real-time context data. Defines entities, properties, relationships, and a query/subscription API. NGSI-LD is the closest thing the smart-city world has to a universal common language for "what is happening right now."
Standard 02 · Framework
OASC MIMs
160+ Cities
Minimal Interoperability Mechanisms — the framework adopted by 160+ cities across 30+ countries. Covers context information (MIM 1), data models (MIM 2), identity (MIM 3), personal data (MIM 4), Fair AI (MIM 5), and more. The procurement checklist that prevents vendor lock-in.
Standard 03 · Data Models
Smart Data Models
800+ Models
A joint initiative of FIWARE, TM Forum, IUDX, and OASC: over 800 ratified, royalty-free data models covering smart cities, energy, agriculture, mobility, water, and more. Each model includes schema, specification, and example payloads for NGSI-LD.
Standard 04 · Platform
FIWARE
Open Source
An open-source reference implementation built around NGSI-LD. The FIWARE Context Broker is the central component that breaks information silos and provides a real-time, cross-domain view of city data. Reference architecture for hundreds of European city deployments.
A global IoT service-layer standard maintained by an alliance of standards bodies including ETSI. Provides device management and semantic descriptions of IoT data — and a base ontology compatible with SAREF, making it bridgeable into NGSI-LD ecosystems.
Standard 06 · Ontology
SAREF
ETSI
Smart Applications REFerence ontology, with an extension (SAREF4Cities) focused specifically on urban environments. Provides the semantic vocabulary that lets devices and platforms agree on what their data actually means — the foundation of the semantic interoperability layer.
Procurement Audit · Standards Mapping · Migration Planning
Map Your City's Current Stack Against the Open Standards Cities Actually Use
iFactory's deployment includes a standards audit — identifying where your existing systems support NGSI-LD, where adapters are needed, and which vendor contracts contain hidden lock-in clauses.
Closed Silo vs. Open Ecosystem: What Actually Changes for the City
The difference between a proprietary, vendor-locked smart city and a standards-based one isn't an architectural diagram — it shows up in procurement, in operations, in the ability to actually use data across domains. The contrast below is what makes the case for standards at a budget meeting, not at an IT meeting.
| Dimension |
Closed / Proprietary Silos |
Open Standards Ecosystem |
| Adding a New Sensor Vendor |
Custom adapter required, weeks of integration |
Plug-in via NGSI-LD endpoint — days, not weeks |
| Cross-Domain Queries |
Manual data export, ETL, often impossible |
Single API query across the entity graph |
| Vendor Migration |
Rebuild from scratch; data trapped |
Data portable; replace components individually |
| SME Procurement |
Excluded — only legacy vendor qualifies |
Open competition on standards-conformant bids |
| Inter-City Solution Sharing |
Each city builds its own; no reuse |
Solutions portable across MIM-adopting cities |
| Compliance & Audit |
Each vendor reports differently |
Common schemas produce unified reporting |
“
The most expensive line item in our last decade wasn't sensors or software — it was integration. Every time we bought a new system we paid again for adapters, mappings, and custom code that did nothing the underlying systems didn't already know how to do. The day we wrote "must conform to NGSI-LD and provide Smart Data Model payloads" into the procurement template was the day that line item started shrinking. Standards aren't an architectural preference. They're a procurement strategy.
— Chief Information Officer, European Capital City — 21 Years — FIWARE iHub Advisor, OASC Technology Council Member
The Procurement Clauses That Actually Enforce Interoperability
Standards adopted on paper don't deliver interoperability in practice. The language inserted into procurement contracts is where it becomes real. Cities that consistently maintain ecosystem behavior require the same handful of clauses in every smart-city purchase.
A
NGSI-LD Endpoint Requirement
The vendor must expose all entity data through a conformant NGSI-LD API — read, write, query, and subscribe. Optional adapters do not count.
B
Smart Data Model Conformance
Data payloads must conform to a published Smart Data Model where one exists for the domain, with deviations documented as extensions.
C
Data Ownership & Portability
All data generated belongs to the city. Bulk export in NGSI-LD-compatible JSON-LD format is a contractual right, not a service request priced separately.
D
Open Source or Documented APIs
Where proprietary components are unavoidable, integration interfaces must be openly documented and remain stable across vendor releases.
E
Identity & Access Standards
OAuth 2.0 and OpenID Connect for authentication; role-based access aligned with MIM 4 for sensitive data categories. No custom auth schemes.
F
Conformance Testing on Acceptance
Final acceptance includes automated conformance tests against the agreed standards — not just functional acceptance, but interoperability acceptance.
Conclusion
A smart city without interoperability standards is an expensive collection of dashboards. A smart city with the standards is an operating system on which new services can be built without renegotiating with every vendor first. The open specifications — NGSI-LD, the OASC MIMs, the Smart Data Models, oneM2M, SAREF — are not aspirational documents. They are ratified, in production, and adopted by 160-plus cities across more than 30 countries. The question for every city procuring its next infrastructure system is no longer whether to require standards conformance, but how to write the procurement language that makes conformance real.
iFactory's platform is built standards-first — NGSI-LD native, Smart Data Models out of the box, OASC MIM-aligned, and designed to integrate with existing FIWARE Context Brokers, oneM2M services, and legacy systems through documented adapters. Book a Demo to walk through the standards audit on your city's current stack.
Frequently Asked Questions
Vendor lock-in isn't a technical accident. It's what happens when standards aren't in the procurement contract.
iFactory speaks NGSI-LD, conforms to Smart Data Models, and aligns with the OASC MIMs — so the data your city collects today remains your city's data tomorrow, regardless of which vendor you choose next.
