Keywords

1 Introduction

Many cities are pursuing a path for becoming “smart” (by various definitions). Indeed, the city stakeholders have understood that this process provides a clear and strong opportunity, not only for improving the quality of life of the citizen, but also in the direction of economic growth and sustainable deployment.

Such cities are becoming promoters of investment and actions for passing from the phase of trial projects to the realization of “Smart Cities”. For example, Korea is investing 50 M€ for making smart the city of Busan [1] and the city of Wien has invested 46 M€ for upgrading homes (21.000 interested people) [2]. More generally, the broad international response to the United States National Institute of Standards and Technology (NIST)’s Global City Teams Challenge (GCTC) [3] provides clear evidence of the great interest on this topic.

This new kind of city activity raises the level of optimism about the future for deployment of Smart Cities: new and striking smart services could be realized if the different applications and solutions worked as a set of harmonized ecosystems; however, maximum benefits can only be achieved if this growth in deployment is accompanied by increasing interoperability and innovation. From this perspective, it becomes essential to define approaches and methodologies that support automated interaction between (new and pre-existing) systems and support the design and development of replicable and reusable solutions. Interoperability can be defined as “capability of two or more networks, systems, devices, applications, or components to exchange and readily use information, securely, effectively, and with little or no inconvenience to the user” [4]. Interoperable systems share a common meaning for the exchanged information, and this information must elicit agreed-upon types of responses. Clearly, interoperability is a complex property of a set of features and layers: semantic, informational, communications, and organizational.

Moreover, in a system of systems, like a Smart City, the interoperability levels must be implemented both within each system and across the different systems. It is essential for Smart City applications to be composable. That is, once an initial application is provided, it should be possible to build on the application by adding new features and function to the benefit of the city and its citizens. However, in many cases, the complexity of adding features that a supplier did not anticipate and provide can make the cost prohibitive. From a city stakeholder perspective, this can result in vendor lock-in. That is the only team that can expand a deployment in this sense is the one that created it. While this can be efficient in some cases, most often the prospect of vendor lock-in and the non-integrative nature of it can hinder cities from making purchases and, thus, slow market growth. Reducing the barrier to adding a second feature can help increase the viability in the market of the first feature.

As a consequence of this complexity, the path to interoperability needs, on the one hand, a cyclic interaction among research (where new ideas and architectures come up), pilots (where they are tested), standardization (where appropriate for a large scale application) and the availability of a set of tools (e.g. software tools to support adoption, conformance and interoperability tests for assuring interoperability and best practices) with the aim of facilitating the achievement of the a critical mass consensus for adoption [5]. On the contrary, what has emerged to date is the development of several independent and uncoordinated architectural designs. This is positive from the point of view of having a wide range of potential solutions to choose from, but the lack of convergence among them is an obstacle to achieving the critical mass needed for broad adoption.

Starting from these issues, a group of international partnersFootnote 1 led by NIST began work on the IoT-Enabled Smart City Framework (IES-City pronounced “Yes City”) with the objectives of providing a foundation of language/taxonomy and common architectural principles for supporting the creation of interoperable Smart Cities. The methodology for developing these principles is to distill them by comparing different architectural efforts [6].

This paper presents the activities completed to date in IES-City effort and is structured as follows:

  • Section 2 gives a quick overview of the problem and of the state of art;

  • Section 3 explains the IES-City approach;

  • Section 4 is focused on the results produced up-to-now by IES-City; and

  • Section 5 presents conclusions and the next steps.

2 The Problem and Current Solutions

Presently, Smart City projects focus mainly on vertical integration within existing infrastructures (for example, energy, transport, health, etc.), while horizontal interoperability, needed for cities to function as a cohesive ecosystem, is not well-developed [7]. Often this top-down approach lacks an integrated perspective, preferring a problem-oriented (or bottom-up) approach, since this one is more immediate, manageable and requires little or no analysis.

At the same time, many existing Smart City Information and Communications Technologies (ICT) deployments are based on closed, that is inextensible and proprietary systems, instead of open systems, in which may be unique to a particular vendor. This results in non-interoperable, poorly portable solutions, non-extensible within projects in a city and between cities.

As a result, vertical applications are proliferating and becoming disconnected ‘silos’ (i.e. vertical logical structures, implementing separately various layers of the Smart City applications: sensors, data filtering, etc.) and are not able to interoperate.

This situation diminishes the ability to achieve benefits available at the city scale by aggregation and re-elaboration of data collected by several and heterogeneous sensors, devices and applications. Thus, the urgent problem is how to break down the barriers among silos (see Fig. 1).

Fig. 1.
figure 1

Breaking down the barriers to creating Smart Cities

Full size image

While standards and open architectures can be interoperability enablers, broad adoption in the Smart City context is limited by the following:

  • Adequate standards are lacking.

  • Architectural efforts are not harmonized and there is no apparent convergence among them. So, even when ICT solutions are based on standardized open reference specifications, there remains a risk of insufficient interoperability.

  • Harmonization is impeded by a current lack of consensus on both common language/taxonomy and Smart City architectural principles (the definition of “Smart City” itself is not unique [9]).

  • Standardization agencies and consortia, like ISO/IEC JTC1, IEC, IEEE, ITUFootnote 2…, are working to generate the needed standards, but a mechanism for harmonizing or comparing them is lacking.

Approaches for addressing these critical issues have been attempted by different stakeholders, including:

  • Identification of an optimal implementation policy: The European project called ESPRESSO, for example, makes recommendations aiming to favor the adoption of a global Smart City Strategy [8]. These recommendations comprise the use of standards, specification of data formats and avoidance of supplier lock-in. This approach fits well with new Smart City projects and can prevent the creation of new silos but it does not give guidance on how to break down barriers between existing silos.

  • Understanding the Smart City standard landscape: The British Standards Institution (BSI) conducted an analysis of existing Smart City-oriented standards. The result was a report, called “Mapping Smart City Standards [10]”, in which the method for identification of the standards and their related gaps plus a summary of the inter-domain Smart City standards, was organized by three levels: technical standards, process standards, and strategic standards. These kinds of analyses are fundamental to facing barriers to interoperability.

  • Definition of reference technological frameworks for Smart City project implementations: many private and public or non-profit efforts are defining their implementation set of tools for building Smart Cities. An example of open source architecture is ‘KM4CITY’ developed by the University of Florence [11] and there are numerous others.

  • Initiatives putting together many cities around one common architecture: Various organizations are building cooperative groups of cities around various architectures. For example, the City Protocol Society [12] is developing a network of cities including Amsterdam, Dubai, Barcelona and Montevideo based on its Functional Platform and the Open & Agile Smart Cities (OASC) initiative comprises more than 50 cities using FIWARE based architectures [13]. Another approach being driven by the Global City Team’s Challenge, convenes sets of cities and providers as “super clusters” to produce open “blueprints” for sets of Smart City applications [3]. These approaches contribute to our reaching critical mass in the use of interoperable architectures, while not requiring that any one architecture “win the race”.

  • Architecture agnostic frameworks for catalyzing Smart City performance: The U.S. Green Building Council (USGBC) has launched the Leadership in Energy and Environmental Design (LEED) for Cities performance-based certification [14] on the Arc platform, enabling cities worldwide to measure and improve performance and make the outcomes from Smart City sustainability and quality of life applications visible.

The previous approaches are certainly useful, but no single one offers a globally consistent Smart Cities framework i.e., a globally shared set of requirements. Lacking is a higher-level perspective for assessing the relationship between the available approaches and architectures. A larger goal should be to identify and distill a common vocabulary and a set of common architectural principles, and promote consensus around standardized interfaces for interoperability. This is the approach chosen by the IES-City initiative.

3 The IES-City Framework Approach

3.1 The Working Groups

To analyse the Smart City Applications and Framework landscape from different points of view and provide results suitable for different kinds of stakeholders, the IES-City Framework activity has been split into different working groups with different scope and aims:

  • Application Framework Working Group: Assimilates and evaluates global frameworks that are facilitating urban decision making process and deployment of Smart City applications. It is compiling an initial list of applications and domains for Smart City applications. The application frameworks being utilized today, are analyzed based on their functional requirements, evaluating cities’ readiness while implementing such applications, and critically assessing benefits for the city and its citizens.

  • Consensus Pivotal Points of Interoperability (PPI) Working Group: Approaches the problem from the perspective of developers. It is producing distillations of prominent technology suites currently in use in Smart City applications worldwide. Through a technical investigation methodology, the suites are analyzed against the NIST Cyber-Physical Systems (CPS) Framework [15] Aspects and Concerns to expose potential PPI where a common concern is addressed with a common technical solution.

  • Deployed PPI Working Group: Analyzes significant and complex Smart City deployments, using a limited set of case studies, to identify potential PPI that were needed to make such complexity realizable.

3.2 The Starting Point: The CPS Framework

The CPS Framework [15] provides a holistic concern-driven analytical concept for conceptualizing, realizing and assuring cyber-physical systems. Cyber-physical systems are a superset of the Internet of Things (IoT) including all things which have both cyber and physical parts, whether they communicate with other systems or not. The IES-City Framework uses this reference as an analytical tool for reducing complex architectures to what is termed “CPS Framework Normal form” to expose potential PPI. That is, to identify support for Aspects/Concerns and the technical solutions identified by an architecture to help expose the PPI.

The framework (see Fig. 2) has two principle concepts – Aspects/Concerns, and Facets. Facets are modes of thinking applied during a systems engineering process for a cyber-physical system. They group various activities throughout the life cycle of CPS, from idea through creation through decommissioning. Note that a CPS can be a device, a system of devices, or a system of systems.

Fig. 2.
figure 2

NIST CPS framework

Full size image

The three Facets are conceptualization, realization, and assurance. There are many system engineering processes in use throughout the domains of CPS (i.e. Smart Cities, Smart Grids, Smart Manufacturing, Smart Transportation, etc.). Any given process involves a sequence of activities that typically include use case development, requirements analysis, design and test, and verification. These activities sort cleanly into the three Facets that group these activities and produce sets of linked artifacts that comprise a complete data set describing the CPS.

The Aspects group common Concerns that should be considered in any given CPS and drive their realization, through properties or requirements of the CPS that are verified through test and assured by relating those properties and artifacts to consensus methods for judging that the properties have been satisfied. To have the best requirements defining and satisfying the needs of technical development, it is important to evaluate a rich set of Concerns at each activity of conceptualization and at each level of functional decomposition of the CPS. This way, for example, cyber security is considered during business case development, use case development, CPS component decomposition, etc. This avoids the failure to consider important requirements which must later be ‘bolted on’ to a design when discovered late.

  • The Application Framework working group has used the Aspects/Concerns as a means of describing the high-level functional requirements for each application and sub-application reviewed.

  • The Consensus PPI working group is using the set of Aspects/Concerns as a means of normalizing approaches to enable a comparative analysis of the disparate technologies being reviewed. Each technology will have its own method of presenting a specification. These methods will have diagrams and detailed documentation that may be highly stylized to the community for which they are being presented. Yet, for example, they may all be using IP addressing to identify nodes in a network. This would correspond to the Functional/Communications/Network concern and ‘IP addressing of nodes’ would be a property or requirement that addresses the concern related to network layer interoperability.

  • The Deployed PPI working group is using the Aspects/Concerns to organize the analysis of several prominent complex Smart City deployments.

3.3 The Innovative Aspect: PPI Concept

Pivotal Points of Interoperability (PPI) introduces the notion that there are design choices made in Smart City technology deployments that are aligned with choices made independently in other Smart City deployments. This consensus provides a defacto standardization and knowledge of these common choices can reduce the complexity of smart City integration and thereby enhance the ability to acquire/sell, deploy, and use Smart City systems. In essence,

  • If you standardize everything, you get no innovation;

  • If you standardize nothing, you get limited interoperability or impeded integration.

The hypothesis of the IES-City Framework is that not only are there good candidates for PPI, but there may already be existing PPI that are consensus choices – not by agreement but by independent election. For example, the use of IP addresses for the identification of communications end-point addresses is one choice that all implementers of IoT have made. Some other possible PPI might include PKI infrastructure for authentication and confidentiality, the use of APIs and REST or Publish/Subscribe data exchange patterns, domain-specific semantic models, and a universal time reference. Note that these are possible examples and are not intended as recommendations.

By detecting potential PPI, IES-City intends to reduce the barriers to deployment of Smart City applications and thereby help streamline and grow the industry.

Each technology suite that is used to deploy a Smart City application has a set of requirements and documentation that, while essential, can be an obstacle to understanding by external parties who may want to integrate with the technology due to its overwhelming volume and style.

If you consider the left side of Fig. 3, the diagonal arrow, drawn from the lower left to the upper right exemplifies this notion of impenetrable complexity. Without being able to rely on some well-known interfaces, the complexity of adding a new feature, the “distance to interoperability” is large. Yet if there were a set of well-established common features, as illustrated on the right, the ‘distance to interoperability’ can be reduced.

Fig. 3.
figure 3

Benefit of PPI

Full size image

4 The Current Status

4.1 Application Framework Outcomes

The Application Framework Working Group analyzed the Smart City application space to provide needed tools and methodologies for stakeholders to choose and/or design Smart City applications. Mainly, it focuses on three aspects:

  • the breadth of the applications;

  • the city’s readiness to integrate Smart City applications; and

  • the benefits that can be expected from evaluated solutions.

Breadth of Applications.

The breadth of a Smart City application, provides a set of coordinates - features, to identify the list of requirements for an application category, to satisfy Smart City needs. A shared list of requirements offers a common base for developing and deploying PPI-focused Smart City applications. In this sense, each identified requirement, mapped on the CPS framework, can provide an opportunity to discover PPIs.

In order to assess the breath of applications, a list of Categories and Sub-categories (classifying the world of the applications for Smart Cities) has been identified starting from literature [16, 17]; then, overlaying it with “Aspects” and “Concerns” defined in the Framework for Cyber-Physical Systems, resulting in a set of requirements for each Sub-category. Based on this categorization, a tool is being developed, where features are used as inputs describing the kind of application to be evaluated. The tool will provide users with requirements needed to be supported by an application.

The tool has different potential users, with different needs. For example:

  • Developers: identifying a list of requirements needed to develop an application.

  • Urban decision makers: need to choose an application matching city requirements.

  • Vendors: evaluating the breadth of applicability of their offerings.

City Readiness.

After identifying the breadth of applications and their functional requirements, urban stakeholders should assess the city’s readiness from various perspectives, including but not limited to, infrastructure, institutional requirements, policies, finances and stakeholder adaptability. This is somewhat orthogonal to the functional requirements identified in earlier sections.

For example, a chosen application may rely on the existence of an emergency response communications infrastructure and the existing communications between response departments such as police and fire. While many cities may have such formal infrastructures, some may be lacking them.

The readiness dimension provides such indicators analyzed for each application, offering city stakeholders an ability to determine the viability and complexity of acquiring specific applications. Analyzing readiness provides guidance to a city in road-mapping the evolution and deployment of Smart City applications.

Benefits Metrics and Business Case.

Urban decision makers need to be equipped with essential frameworks, metrics, and tools to justify benefits of Smart City applications and to establish a viable business-case for practically deploying it in the city with the necessary public resources. Carefully crafted benefits metrics and business-cases are expected to bring win-win situation to all involved stakeholders - benefiting the city government, private sector enterprises and people. However, since priorities for each stakeholder group, for various applications, differ substantially, a wide set of benefits metrics and business-cases have been evaluated from global cities deploying Smart City applications:

  • A significant goal for the public sector is growth in economic activity. This includes increased and better jobs in the science, technology, engineering, and mathematics fields, local Gross Domestic Product (GDP) growth, increase in exports and quality of life, decrease in the cost of serving citizens (enabling greater services), sustainability (both environmental and social), and less negative externalities.

  • The private sector stands to benefit substantially from increased smart city technologies deployment. New markets and revenue potential become available. Through innovation, new services are developed and pursued. New capabilities lead to new approaches to performing existing services yielding increased productivity.

  • People living in smart communities benefit from improved service delivery and cost savings in areas such as energy and transportation. By empowering citizens through increased information about their lifestyles, greater productivity becomes a reality.

4.2 The Pivotal Points of Interoperability

The Consensus PPI working group defined a methodology for detecting PPI and is using it to evaluate four frameworks, namely oneM2M [18], FIWARE [21], US Department of Transportation’s Connected Vehicle Reference Interface Architecture (CVRIA) [19], and OpenIoT [20]. This list may be expanded later.

The methodology is based on the idea of “zone of concerns”. A zone of concerns is a concept related to where sets of technologies may apply. For example, the communications requirements (concerns) for connecting a sensor to a cellular network are different than those for connecting a cell-phone application to a cloud service provider. For a given technology suite, a determination is made by the proponent of the technology as to whether there is one or more than one “zone of concerns” for their analysis.

At a practical level, the analysis is done with a simple spreadsheet whose rows are the Aspects/Concerns from the CPS Framework. For each zone of concerns, a “tab” of the spreadsheet is created. Then the analyst, based on their own technology specifications, reviews each row for applicability. For example, does my technology address confidentiality? If the answer is yes, the analyst inserts a reference on how it applies and where it is discussed. Finally, if the solution that addresses the concern is an open standard, this standard(s) is identified. At the end of the activity, all the spreadsheets are combined revealing patterns of where technology suites have addressed similar sets of concerns, and, potentially, where the same or similar solutions were chosen.

A key benefit of this approach is the ability to compare not only standards and architectures, but also actual deployments of Smart City applications.

The result will expose candidates for PPI. The strength of consensus will be magnified by the number and reach of the solutions analyzed.

5 Conclusions and Next Steps

Interoperability is fundamental for Smart Cities and standards are a means to that end. An important issue is that if everything were standardized, innovation may be over-constrained. Thus, a trade-off between standardization and innovation must be found. The IES-City initiative takes on this challenge by focusing on the concept of Pivotal Point of Interoperability (PPI) that provides guidance for finding an agreement on standardized interfaces that enable the composition of Smart City systems without locking out innovation.

The IES-City work is still in progress, and PPI are being identified through a comparative analysis of existing architectural efforts and solutions including examples of application integration across cities, standards supporting the modular integration of functions at city scale, best practices, existing tools, and methodologies that enable users to understand and use Smart City capabilities and technologies. Once a consistent list of PPI is available, it will be submitted to the IES-City stakeholders (e.g. cities, ICT developers, Smart City project designers, etc.) to validate and further enrich it. The result will be a White Paper providing common architectural principles (PPI) and a vocabulary for Smart City technologies. Potential users include:

  • organizations and consortia developing standards, to give greater coherence to their standardization activities;

  • city decision makers, to choose Smart City solutions starting from common and shared principles; and

  • application developers, to design and deploy solutions suitable for improving the quality of Smart City services.