Smart City Platform

The horizontal platform for Smart City management, built on the public ENEA SCPS 2.0 specifications: it collects, harmonizes and governs the city's data, connecting existing vertical solutions through a shared language and open standards.

Request a demo The ENEA specifications

The challenge of urban digital transformation

Breaking down fragmented vertical data silos, avoiding dependence on proprietary software and regaining control of public spending in procurement tenders.

Vertical information silos

Today municipal solutions (lighting, parking, waste management, environmental monitoring, mobility) live in isolated platforms. Data is locked inside each vendor's software, making it impossible to truly correlate information ("Data Fusion") to support the city's strategic decisions.

Recurring integration costs on every tender

Every new procurement or technology upgrade requires building custom connectors, driving up costs and delaying deployment. The public authority stays locked ("vendor lock-in") into proprietary solutions, paying every time to access or transfer its own urban data.

What is the Smart City Platform

A Smart City Platform (SCP) is a horizontal ICT platform for centralized city management, based on the SCPS specifications. ENEA defines and maintains the Smart City Platform Specification for Interoperability Layer and provides a reference prototype.

The Smart City Platform harmonizes data from the city's vertical systems into a shared, interoperable language

From the physical city to the digital city: lighting, mobility, environment and services converge into a single, shared and interoperable data language.

The city as a system of systems

The city is viewed as a set of heterogeneous vertical application contexts (mobility, public lighting, smart building, waste management, smart home and more), each managed by one or more Vertical Solutions.

The city becomes "smart" through the retrieval and observation of data: the SCPS specifications make it possible to harmonize and retrieve this data to the horizontal platform, breaking free from proprietary and closed solutions.

Two architectural layers

The SCPS reference architecture is conceptually split into two layers:

Interoperability Layer: the interoperable connection of Vertical Solutions to the SCP, the core of the five SCPS specifications.
Application Layer: the use of retrieved and harmonized data: Data Fusion applications, GUI and citizen services.

The key concepts

SCP

The horizontal ICT platform for centralized Smart City management.

Vertical Solution

The technologies that manage a single application context (mobility, lighting, building...).

UrbanDataset

The datasets exchanged in a shared format (JSON/XML), uniquely defined in the Ontology.

Registry

The SCP's internal register of users, Solutions, UrbanDatasets and collaborations.

The five SCPS specifications

Interoperability is organized into five modular layers, each covered by a public specification. Only by adopting all five do you achieve full interoperability between systems.

Functional

The Reference Architecture and the definition of key concepts (SCP, Solution, UrbanDataset, Registry, Ontology). It is the introductory specification: it describes the SCP's macro-functions as use cases.

Semantic

The semantic definition of UrbanDatasets in the central Ontology managed by ENEA: unique and unambiguous names, formats and units of measure, with code lists and naming rules.

Information

The abstract data model and the shared UrbanDataset format (JSON and XML), with validation on two levels: json-schema for the macro-structure and Schematron for the specific properties.

Collaboration

The set of information that defines the collaboration between the SCP and Solutions: UrbanDataset specification, Solution registration and the definition of productions and accesses in the Registry.

Communication

The interoperable communication protocol: the UrbanDatasetGateway RESTful web service, with push and request/response patterns, enabling the sending and retrieval of UrbanDatasets.

Gradual adoption

Each specification can be adopted independently of the others, enabling progressive integration of existing platforms without replacing the vertical solutions already in operation. You can start with a single application context (public lighting, mobility, environment) and extend progressively to the rest.

The five specifications, in progressive order

Functional Semantic Information Collaboration Communication

National standardization and adoption

An institutional and scientific guarantee. The SCPS specifications are not proprietary or experimental technology, but an approved standard backed by Italian public research.

UNI 11973:2025

Interoperability model recommended by the national standard

11

Funded national projects and over 10 scientific publications

Regions & Cities

Bologna, Ravenna, Palermo and regional scale in Umbria and Liguria

Successfully adopted in Italy

The SCP platform is already in operation in major urban centers such as Bologna, Ravenna and Palermo, and at regional scale in Umbria and Liguria. It also underpins 11 funded national projects (including PELL, DARE, ECOSISTER, RAISE and NEST) and more than 10 scientific publications in the field.

By adopting the platform, you join an national reuse ecosystem: best practices developed by one municipality can be replicated by others at no software cost.

Operational advantages in procurement tenders

The SCPS model turns municipal contracts from a source of recurring costs into a structural investment in interoperability.

Technical tender clauses

ENEA supports the municipality in drafting tenders, requiring awarded vendors to send data in the standard SCPS format.

Integration costs eliminated

Vertical vendors send data directly to the SCP server's public APIs, eliminating any future cost of building connectors for the authority.

Harmonized data, public ownership

Adherence to shared data models (UrbanDataset) to prevent data being trapped in raw or proprietary formats.

Data Fusion and decision-making

The ability to cross-reference heterogeneous data (e.g. air quality and traffic) in unified, high-level dashboards.

Traditional model vs SCPS solution

The comparison between the traditional vendor model and the ENEA + Heartwood Labs model.

Comparison between traditional vendor model and ENEA + Heartwood Labs model on costs, interoperability, data language and governance
Characteristic	Traditional Vendor Model	ENEA + Heartwood Labs Model
Server license cost	Expensive, recurring annual licenses	Free (instance provided by ENEA)
Connector development	Must be paid for every new tender/vendor	Zero cost (included via standard SCPS APIs)
Data language	Undocumented proprietary formats	National standard (UNI 11973:2025 norm)
Governance and constraints	Technological lock-in to the vendor	Full municipal sovereignty over its data

The lifecycle of an SCP

The SCP's macro-functions are organized into a path describing the platform's entire lifecycle, expressed in consecutive phases, each described with its own use case diagram.

UrbanDataset definition

The ENEA team gathers community input, defines the UrbanDatasets in the central Ontology and exports the JSON templates.

SCP configuration

First configuration: assignment of the SCP ID, definition of Administrator users and declaration of the supported UrbanDatasets in the Registry.

Solution configuration

Registration of Solutions and definition of Solution-UrbanDataset collaborations, both for production and access.

Interoperable communication

Operational exchange of UrbanDatasets via the UrbanDatasetGateway, with permission validation and data traffic monitoring between SCP and Solutions.

Collaboration removal

At the end of the agreed period, the removal of productions, accesses and the Solutions themselves, according to the rules on data ownership and retention.

Closing an SCP

Backup of the Registry and UrbanDataset databases, deletion of the SCP and release of the ICT resources in use.

Implementation roadmap for the municipality

A turnkey journey that takes the municipal IT department from data mapping to the rollout of operational dashboards.

Phase 1

Assessment

Identification of available data flows (UrbanDatasets) and a joint Heartwood–ENEA dialogue to plan the mapping.

Phase 2

Tenders and requirements

Support in drafting interoperability requirements in new municipal tender specifications.

Phase 3

Setup and data acquisition

SCP server activation, connection configuration and automatic data acquisition from vertical systems.

Phase 4

Dashboard

Rollout of high-usability SCP-DASH views and highly reusable Data Fusion jobs.

Strategic partner

Heartwood Labs is the operational arm for public administrations looking to adopt the Smart City Platform (SCP) model, ensuring technical compliance and scalability.

Starting from the public ENEA specifications, we guide municipalities through the entire journey: from data flow analysis to platform deployment, through to the development of Vertical Solutions and Data Fusion applications.

Mapping of UrbanDatasets and analysis of urban data flows
Configuration of SCPS nodes and Identity Providers
Dashboards for Lighting, Mobility, Environment and other application contexts
Development and integration of SCPS-compliant Vertical Solutions
Data Fusion services for decision-making
Onboarding paths and SCPS 2.0 compliance verification

Talk to our team

Benefits for the public sector

National standard

UNI 11973:2025 compliance and national reuse of solutions.

No vendor lock-in

Data sovereignty and reduced proprietary integration costs.

Data Fusion

Integration of heterogeneous data to support decision-making.

Open data

Data declared OPENDATA is accessible to citizens without registration.

System of systems

Existing vertical platforms keep running: the SCP makes them interoperable.

WCAG 2.2 AA accessibility

Dashboards and citizen services developed in compliance with the WCAG 2.2 AA guidelines (D.M. 123/2024), inclusive for everyone.

A proven infrastructure at scale

A robust platform that guarantees full security, scalability and reliability for the municipal IT department.

A secure, scalable and proven infrastructure supporting the city's digital governance

Every city that adopts the SCPS specifications joins a national ecosystem of shared reuse, data and solutions.

~10,000 users · more than 60 applications

Centralized ENEA authentication infrastructure (Single Sign-On) with full SPID and CIE integration.

11 national projects

Used in research and development projects such as PELL, DARE, ECOSISTER, RAISE and NEST.

UNI 11973:2025 norm

A validated interoperability model, cited in over 10 scientific publications in the field.

Frequently asked questions

Is it experimental or untested technology?

Absolutely not. The SCPS specifications are recommended by the UNI 11973:2025 norm and are already used in major urban centers (Bologna, Ravenna, Palermo) and entire regions (Umbria, Liguria). By adopting the platform you join an national reuse ecosystem.

Why do we need Heartwood Labs if ENEA provides the platform?

ENEA provides the engine, Heartwood is the driver. Implementation requires on-the-ground work: mapping municipal data, drafting tender specifications and building operational dashboards (SCP-DASH). Heartwood delivers a turnkey service to the authority's IT team.

We already have vertical platforms in operation: do we have to replace them?

No. The SCP does not replace the vertical solutions already in operation: it makes them interoperable through a shared format and protocol. The specifications are modular and allow gradual adoption, starting from even a single application context (e.g. public lighting or mobility) and extending progressively to the others.

In what format do vendors send data?

Data is represented as UrbanDatasets in JSON format (and XML per the specifications), validated on two levels: json-schema for the macro-structure and Schematron for the specific properties. Sending and retrieval happen through the standard APIs of the UrbanDatasetGateway web service, with no ad hoc connectors.

How are access and security managed?

Access goes through the centralized ENEA authentication infrastructure (Single Sign-On, ~10,000 users and more than 60 applications) with full SPID and CIE integration. Each collaboration defines granular permissions in production and access, and data traffic between SCP and Solutions is continuously monitored.

Who owns the data? How much control does the municipality have?

Data remains the property of the authority. When configuring collaborations, ownership, retention periods and production/access permissions are defined according to the SCPS Collaboration specification. The municipality thus retains full sovereignty over its data, with no vendor lock-in.

How much does the platform cost the municipality?

The SCP server is free: the instance is provided by ENEA and there are no recurring annual licenses. Costs only cover on-the-ground work: data mapping, drafting tender specifications and building operational dashboards.

How long does it take to get started with a pilot project?

We start with a short 20-minute working session to analyze data flows with a view to drafting the next tender. The full roadmap is organized into four phases: Assessment, Tenders and Requirements, Setup and Data Acquisition, Dashboard (SCP-DASH).