Keywords

1 Introduction

The Smart City (SC) concept becomes pivotal to the future improvement of quality of life in urban areas [7]. It can be defined as an urban development vision of integrating and connecting multiple ICT solutions and city’s assets in platforms enables governments, businesses and citizens to communicate and work together using data from heterogeneous sources to improve the quality of life and enhance efficiency and economic value [8,9,10]. To enable this improvement the concept relies on collecting and processing large amounts of data. ICT is considered central to many infrastructural, sustainable and economic challenges posed by the increasing urbanization [11].

Hence, continuously developing and adopting ICT technologies to create and use platforms for government, business and citizens can communicate and work together and provide the necessary connections between the networks that are the base for the services of the smart city [1] (Fig. 1).

Fig. 1.
figure 1

An example of an integrated urban district [2].

Full size image

The Smart City Platforms play an essential role, as they support data management and application development; e.g. a recent survey also shows as 80% of German cities see a need for action on data platforms, and 97% consider digitization as their “core business”, but 88% also claim that they depend on external support in concrete projects [12]. The main challenge for the successful implementation of SCs is the supply of their data platforms with comprehensive and consistent data. [13]. As the data often originates from heterogeneous sources, compatibility of various data sources and platforms is necessary [14]. However, current SC platforms have either limited functionality or are closed systems designed for a specific task and cannot be combined or extended [8]. This leads to fragmented silo or vertical solutions [15], data exchange limitations, and data accessibility for SC applications. A large number of different proprietary protocols and cloud services for SC applications (cf. e.g. [12]) further complicate the choice of the right platform [8]. Experience in other areas of public administration shows: in community-led projects, as it is also usual in SC, often no supra-regional standards are defined [16], but rather individual solutions developed. This also became true for SC data platforms, as literature shows (cf. e.g. [17]). Hence, standards alone will not enable more interoperability between SC data platforms in the coming years [18], as no consolidation of existing (pseudo) standards is expected [19]. Therefore, interoperability is a crucial feature of the underlying data platforms. Only linking the data from a wide range of different open and closed sources can lead to a valid, comprehensive and consistent database suitable for the development of various applications [8, 13]. In addition, interoperable solutions can prevent vendor lock-ins and help cut costs for services because they enable the reusability of solutions and applications in different cities and replicability [3, 9, 19, 20]. Thereby, it is also relevant to create open markets for third party services based on existing data [17]. Current many researches are conducted on interoperability and replicability; however the literature is lacking a comprehensive conceptualization of interoperability between SC platforms and also on the scalability and replicability issue.

The main features of a generic Smart City Platform (SCP) are in the following [9].

  • Make data, information, people and organizations smarter;

  • Redesign the relationships between government, private sector, non-profits, communities and citizens;

  • Ensure synergies and interoperability within and across city policy domains and systems (e.g. transportation, energy, education, health & care, utilities, etc.);

  • Drive innovation, for example, through so-called open data, living labs and tech-hub.

The ENEA-SCP is implemented following the Software as a Service (SaaS) paradigm, exploiting cloud computing facilities to ensure flexibility and scalability. Interoperability and communication are addressed employing web services, and data format exchange is based on the JSON data format. By taking into account these guidelines as references, this work provides a description of the SCP developed by ENEA [4] and its potential use for smart and IoT city applications. In summary, the ENA-SCP aim is to interact with most of components at the urban district level by a flexible and multipurpose data format. In this article the authors provide thought a practical approach to assess interoperability issue.

The paper is organized as follows. Section I provides an introduction to the addressed problem; in Section II, the authors conduct an literature review on interoperability topic of focuses; Section III a brief outline of the reference SCP model in terms of Interoperability, Scalability and Replicability issues for SCP is described; Section IV presents the ENEA-SCP experience in terms of replication of smart city data platform solution in different environment and ENEA projects; Section V reports an application case; finally, Section VI concludes the paper and gives some ideas for future works.

2 Background and Related Works

Smart City is a most popular discussed topic in scientific literature aiming to connect governments, businesses, and citizens using technologies such as IoT, Big Data, Cloud Computing, enabling the usage of a host of data from heterogeneous sources and intending to create a sustainable environment, improve the quality of life, as well as enhance efficiency and economic value [1, 2, 3, 4, 14, 17].

Thereby, SC literature concentrates on three main topics:

  1. 1.

    Open standards and Data Platforms for developing and deploying SC applications (e.g. [8, 12, 13]);

  2. 2.

    Theoretical models that are intended to support the selection and development of suitable SC applications (e.g. [21, 22]), in particular, through a criteria-based evaluating framework [22];

  3. 3.

    The implementation and analysis of prototypical SC applications, with a focus on energy, building, mobility and administration, but also many other fields of action (e.g. [8, 13, 23]).

A comprehensive list of projects and initiatives are presented in the literature, thanks also to the European project and initiative that compares the most relevant IoT platforms for SC projects.

Data platforms are a necessary component of SC solutions, indeed, they support data flow management and application development and enable government, businesses and citizens to communicate and work together using an enormous amount of diverse data of different types and from heterogeneous sources [3]. In literature, SC data platforms are mostly characterized as big data platforms (e.g. [21]) and/or IoT platforms (cf. e.g. [8, 14]). Both characterizations can apply since SC has – on the one hand, many overlaps with IoT technologies, such as the usage of information and communication technology to connect diverse physical objects like sensors and the internet. On the other hand, as described within the introduction, big amounts of different data are gathered, combined, and computed, defining a big data platform. Further, the platform must be able to deal with historical data and real-time data, as well as, being flexible to handle different scales/types of data [24].

2.1 Interoperability

Several different definitions of the term interoperability in the scientific literature (e.g. [25]). The International Organization for Standardization (ISO) [26] defines interoperability generically and with a focus on the exchange of information between units as the “capability to communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those”. In its definition of interoperability for the eGovernment sector, the European Commission [27] includes the concept of data exchange and sharing common knowledge and underlines the importance of harmonised business processes. Maheshwari and Janssen [25] define the term interoperability as: “the ability of entities to work together covering aspects ranging from the technical to the organisational level.” Combining these three definitions, interoperability is the ability of disparate and diverse system components, ICT systems, or organizations to communicate, transfer information/knowledge, execute programs, and work together, covering aspects ranging from the technical to the organizational level, to achieve mutually beneficial and agreed on common goals [25,26,27].

Chinnici et al. [3] and Brutti et al. [9] differentiate two dimensions of interoperability, horizontal at platforms modules (among platforms) and vertical at data level (between data source, platforms and data user). Bröring et al. [28] use this distinction, too, to discuss IoT systems. Although mainly focusing on vertical interoperability, they emphasize horizontal interoperability as equally crucial for the successful usage of IoT ecosystems, also not yet established.

3 ENEA Experience: Smart City Platform

The solution provided by ENEA- Smart City Platform (SCP) to exploit potentials in Smart City environments is based on four fundamental concepts:

  • Open Data

  • Interoperability

  • Scalability

  • Replicability

These four aspects, whose related issues were tacked in ENEA-SCP development, provide a reference framework of modular specifications [9] for stakeholders willing to implement ICT platforms to exploit the Smart City vision potentials and offer new services for the citizen.

3.1 Open Data: UrbanDataset

The starting point for providing interoperability into the SCP development has been to define an open data format able to guarantee a flexible and, at the same time, accurate communication between SCP and all data producers/consumers (named Solutions). For such a crucial issue, a JSON based data format, named UrbanDataset (UD), has been defined. A more structured and detailed classification of the concepts associated with properties and UDs has been outlined, to facilitate their reuse and search within an ontology. This classification, starting from standard taxonomies (such as ISO 37120 [5]) and the requirements of the UrbanDatasets themselves, clarifies the meaning of the property, explaining the type of represented concept, whether they are general meta-information (identifiers, descriptions, formats, etc.) or quantities related to specific Smart City application domains (telecommunications, energy, urban planning, etc.). In details, the JSON structure of a UD is composed of three fundamental fields; each one plays a role in order to define and characterize its information:

  • Specification contains the references, such as ID and URL of UD into the ontology;

  • Context has information about UD production, such as the ID of producer solution, timestamp and coordinates of the origin;

  • Values are the part of JSON where is inserted the real transported data. It contains a list of properties, in terms of a couple of key-value (propertyName, propertyValue), each of them reports a set of information concerning a single property defined for the particular UrbanDataset into the ontology.

Figure 2 is reported an example of UrbanDataset, belonging to the “Whatever” class, where are plain the three macro parts of JSON described above.

Fig. 2.
figure 2

An example of urbandataset structure.

Full size image

3.2 ENEA Platform Interoperability

One of the most innovative aspects of the proposed approach is related to the information and the semantic interoperability levels. The standard-issue, referring to interoperability through shared data formats, is how to find the correct balance between too prescriptive specifications (which guarantee interoperability, but the risk to inhibit innovation) and more elastic specifications (which have much potential deficit concerning real interoperability). This problem becomes urgent in a context, like Smart City, with many interacting heterogeneous systems. The proposed approach focuses on overcoming this issue; indeed, it has a very light and elastic format at the information level able to represent an extensive set of data, moving at the semantic level the strict definition of the data. The underlying idea is that this light approach can be easily applied also on existing systems with just a small intervention on them.

In detail, five sub-specifications concerning the interoperability levels have been implemented and validated. The list below shows the implementation progress made for each of the interoperability levels (Fig. 3) with the related specifications:

  1. 1.

    Functional: design of the SCP Reference Architecture and functionalities;

  2. 2.

    Collaboration: definition of the Registry and the basic GUI for the management of the collaboration;

  3. 3.

    Semantic: definition of the Ontology for centralized interpretation;

  4. 4.

    Information: data model managed by the SCP and XML and JSON formats to represent the data;

  5. 5.

    Communication: definition of the patterns and interfaces supported for data transport.

Fig. 3.
figure 3

Smart Grid Operation Layers structured for universal interoperability [6].

Full size image

3.3 Scalability

The ENEA Smart City Platform exploits computational resources of the ENEAGRID infrastructure [4], as it is deployed in the cloud-hosted in the Portici Research Center site. The creation of a customized environment ENEA-cloud-based platform is possible thanks to the virtualization technologies of VMWARE platform, which allows hosting management, transportation and the processing of project data services, ensuring their availability and protection over time. More in detail, the SCP is composed of six Virtual Machines (VMs), and each of them hosts a component with a specific role (Fig. 4). There are two access points, one for the Machine to Machine (M2M) interaction and one for the Human-Machine Interface (HMI) interaction, respectively named scp-ws-m2m (as web-services provider) and scp-gui (as web-accessible GUI). The scp-id is used as an identity provider while the scp-registry is the orchestrator that manages the production and the access of data by means a relational database. The scp-ud is the VMs that stores data by exploiting a No-SQL database. Finally, there is a private VM, the scp-ws-hmi, which is similar to scp-ws-m2m but is used only for internal HMI transactions.

This architecture presents the peculiarity of horizontal and vertical scalability; as the number of VMs and/or processing resources can be varied according to the volume and to the throughput of the handled data. Also, the flexibility guaranteed by this cloud solution, combined with integration in ENEAGRID resources, provides an immensely powerful and functional Smart City Platform, which exploits the main features of the whole environment.

Fig. 4.
figure 4

Scheme of ENEA-SCP architecture based on six VMs.

Full size image

3.4 Replicability

The open-source solutions have only been adopted to ensure the SCP replicability system, and the components have been developed in such a way; then, they can be easily reinstalled in a new pool of virtual machines.

In particular, the execution software of each VM is parametrized utilizing a configuration file that allows defining proper settings for a specific installation (e.g. the name of the virtual machines or particular access credentials to the various systems). This technological solution allows replicating overall SCP implementation in several different urban districts, both server-side (SCP replicability) and client-side (solution replicability) as depicted, e.g., in Fig. 5.

Fig. 5.
figure 5

Example of the replicability solution.

Full size image

To better explain how the interaction between these components takes place, a more descriptive scheme is reported in the following. As said, there are two entry points at ENEA-SCP: one for M2M interaction (as illustrated in the downside of Fig. 4) and one for HMI interaction (upside of Fig. 4). It is fully reported that only the M2M steps procedure for HMI is very similar and briefly said only the differences.

M2M Functional Schema:

There is three kind of primary services that a vertical/solution can ask:

  1. 1.

    Authentication (Login Service);

  2. 2.

    Insert a new UrbanDataset into SCP (Push Service);

  3. 3.

    Request an UrbanDataset previously inserted (Request Services).

Login Service

Every Solution action on SCP is granted by a JSON Web Token (JWT). SCP provides this token by sending username and password to a “login service” at UDGateway component of scp-ws-m2m VM. This component checks on the Indentity Server (scp-id) if credentials are correct, and in case of a positive answer, a valid token is returned.

Push Service

To insert an UD into SCP, a solution sends a “push service” of UDGateway (scp-ws-m2m) the UD, a valid token and a resourceID.

The resourceID is a control parameter to verify on Registry component (scp-registry) that the Solution is authorized to produce and insert the sent UD into SCP.

If Identity Provider validates the token; the resourceID is validated by Registry and UD JSON format is validated by UDGateway then the UD is inserted into UrbanDataset Storage (scp-ud VM) and a new record is inserted into history_production table of Registry to mark down the transaction.

Request Services

To retrieve one o more UDs from SCP, a solution sends to a “request service” of UDGateway (scp-ws-m2m) a valid token and a resourceID.

The resourceID is also used as a control parameter to verify on Registry component (scp-registry) that the Solution is authorized to access a subset of UDs stored on SCP.

If Identity Provider validates token; the resourceID is validated by Registry then the UD is selected from UrbanDataset Storage (scp-ud VM) and returned to solution; a new record is inserted into history_access table of Registry to mark down the transaction.

HMI Functional Schema:

For HMI interaction, only Authentication e Request services are authorized. The endpoint between Solution/SCP is the GUI Server (scp-gui). All the requests are addressed to an inner UDGateway (on scp-ws-hmi VM) that replicates the same operations of public UDGateway of scp-ws-m2m.

The replicability characteristic of the SCP allows its versatile use both in terms of management of the vast amount of smart city applications and for offering services to potential users such as public administration, citizens, and providers.

4 SCP-Template for SCP-Full and SCP-Light

The first prototype of ENEA Smart City Platform, deployed on six Virtual Machines at Portici Research Center, is called “Smart City Platform Smart Village Casaccia” [29] or shortly “SCP-Casaccia”. Starting from this SCP some new instances of platforms are created. The first one, called “SCP-Template”, is considered a reference platform. Indeed, other SCP-replicated platforms (“SCP-Bologna”, “SCP-PELL”, “SCP-DARE” [30], “SCP-COGITO” [31] and “SCP-ReggioEmilia”) are generated from SCP-Template as its clones and they share with it the same development process.

More specifically, from the six virtual machines of the SCP-Casaccia (ENEA Data Center of Portici) the SCP-Template (ENEA Data Center of Bologna) is prepared by assembling all the components of the original SCP in a single virtual machine. This procedure has been possible thanks to the modularity of architecture. In this way, two kind of SCP deployment are designed:

  • SCP-Light: it is an instance of Smart City Platform concentrated in a single virtual machine, exactly like the SCP-Template;

  • SCP-Full: it is an instance of Smart City Platform distributed on a pool of virtual machines, generally six, exactly as the SCP-Casaccia.

The first type of SCP is useful in application fields where an expensive contribution from the point of view of computational performance is not required and at the same time a reduced management cost is allowed.

The second type of SCP, on the other hand, is useful for ensuring the modularity of the components, allowing in a second phase expanding individual parts of the platform or integrating new independent modules.

Figure 6 illustrates the entire chain of the replication process that has been performed. The SCP-Bologna belonging to the SCP-Full type is created to test multi-server replication. The SCP-Light class, on the other hand, includes SCP-PELL (at ENEA-Bologna), SCP-DARE (at CINECA), SCP-COGITO (ENEA-Portici) and SCP-Reggio Emilia (at ENEA-Bologna), created for as many research and/or experimental applications.

Fig. 6.
figure 6

Replication process of all instances of SCP.

Full size image

5 SCP-COGITO as Application Case

The SCP-COGITO is a specifically platform created for the research project COGITO (COGnitive dynamIc sysTem to allOw buildings to learn and adapt). The aim of this project is to implement an IoT cognitive framework for the efficient management of buildings. The deployment of SCP-COGITO instance allows to test two fundamental aspects of platform architecture: the replicability and the interoperability.

Indeed, in this context, SCP-COGITO plays the role of cloud component that interoperates with the cloud-edge based COGITO platform as illustrated in Fig. 7.

The role of SCP within the COGITO Project is to store all data that are not immediately useful to make a decision. In other words, SCP-COGITO gives cloud-based support to the COGITO Platform when it is necessary to retrieve long time-series and compute some elaborations of a large amount of data. The goal of the COGITO Project, which is improving the management of public and residential buildings with cognitive and self-development functionality is guaranteed in by using “light” sensors/devices able to make fast decisions supported by an engine-core (SCP-COGITO) able to archive old data and to do fastly heavy data filter/aggregation (e.g. sum, min, max, avg, etc.).

A component on COGITO Platform, called SCP-BoundayAgent, is developed to interconnect the two platforms. It is a wrapper that transforms heterogeneous data produced by sensors in UrbanDatasets and send them to SCP-COGITO. It is also able to retrieve particular UDs from SCP-COGITO or query specific selection of properties at “Values” level as defined in Sect. 3.1. On the other hand, the SCP-COGITO is configured as web service that furnishes database features in order to store and provide data archived in UrbanDataset form. In this particular instance, it also has a new component installed that extends the platform functionality as computational core, able to filter and aggregate data at “Values” level.

Fig. 7.
figure 7

Scheme of interoperability between SCP-COGITO and COGITO platform.

Full size image

6 Conclusions

In this work, the authors presented the interoperability topic of Smart City platforms and attempted to provide their approach presented by the ICT ENEA Smart City Platform (SCP). This platform is able to interact with different stakeholders at the urban district level by a flexible and multipurpose data format. The ENEA-SCP milestones are the opportunity to scale the computational resources according to requests; interoperate, using five specification levels, with all the interesting parts; and replicate all the components in the different city context. For the future works, the aims of the authors are: to develop a “light” ENEA-SCP where all components described in this work are gathered in a single Virtual Machine (in this way the deployment of a new SCP became easier); to create a unique identity component (scp-id) for all SCP instances; finally, to create a “National SCP” (interSCP or iSCP) with the goal of collecting and elaborating data from all SCPs running at the urban level.