Keywords

1 Introduction and Motivation

Smart city concepts have been proposed by multiple researchers in recent decades to enhance the citizens’ quality of life by various smart technology management solutions (such as management of resource, data, and software) between end-users, city planners, and technological devices (e.g., sensors) [1, 2]. By those solutions, data are such primary feeds for smart cities and play a vital role for the smart cities developments. The data provide a massive opportunity for a city to be smart and agile through the different types of services for a city. Moreover, the services use data to build their service scenarios for the smart city stakeholders’ requirements by the appropriate information according to the contextual state, or some high-level knowledge discovered from different data analysis techniques. Therefore, we highlight that data and software management is one of the most significant and challenging issues ICT use in smart cities.

From the beginning, many smart technology management solutions in smart cities have been discussed by centralized facilities based on Cloud technologies [1, 2]. Various benefits that can be gained by using Cloud technologies. For instance, Cloud technologies provide (almost) unlimited resources capacity for a set of data processing and data storage, etc. [1,2,3]. However, there are several disadvantages with forwarding all data and services to Cloud technologies, including appraising the level of data quality, security, and privacy, and undesirable network communication latencies, etc. [4, 5]. Hence, the advent of edge computing has been added novel issues to the smart technology management solutions in smart cities [4,5,6]. For edge-dominant systems, the old smart technology management solutions and development will not work for software development life cycles, data life cycles, etc. [6,7,8]. Thereafter smart technology management solutions go beyond to ideas of distributed-to-centralized facilities to manage data, software, resources and so on. The core idea of distributed-to-centralized is to make contributions between the edge of networks (as a place which is nearest to the data sources) and centralized schemas (as a place which is furthest to the data sources, but possibly closer to data consumers and processing) through a unified strategy [9,10,11,12].

In this paper, we extend our proposed ICT architecture based on D2C-DM architecture for smart cities [9, 10, 13]. Several contributions have suggested in the paper to expand the ICT architecture through more detailed use cases in cities and focus on applicability to scenarios of software management. First, we draw a novel fully hierarchical software management architecture for smart cities based on Fog, cloudlet, and Cloud technologies. This new Distributed-to-Centralized Software Management (D2C-SM) architecture can generate different services layers (including local, historical, and combined) through using distinct data types gathered from physical (e.g., sensors) and non-physical (e.g., simulated data, and external databases) data sources in the smart city. Second, as our first discussion, we envisage that our proposed D2C-SM can fit the software’s requirements of the Zero Emission Neighbourhoods (ZEN) center [14]. Thereafter we use three different use cases of the ZEN center to depict the efficiency of our proposed ICT architecture, including D2C-SM and D2C-DM architectures.

The rest of the paper is structured as follows. Section 2 introduces the related work of different smart technology management (such as resource management, data management, and software management) with a focus on software management strategies in the smart city. Section 3 describes a particular smart city project in Norway (ZEN center), and its pilots. Section 4 explains the main insight of the Information and Communication Technology (ICT) architecture for ZEN center, including D2C-DM and D2C-SM. In addition, we propose a novel D2C-SM architecture for ZEN center (based on Fog, cloudlet, and Cloud technologies) as well as the smart city. Section 5 discusses three different use cases of ZEN pilots to illustrate easy adaption of the D2C-DM and D2C-SM architecture. Finally, Sect. 6 concludes the paper.

2 Related Work

Several smart technology management solutions suggest managing the resources, software, and data in the smart city. Those solutions make the interconnection between end-users to city planners, and technological devices in smart cities to develop the citizens’ quality of life [1,2,3,4,5, 9,10,11,12,13, 15] and can also be understood as a collaboration of citizens and technology [16].

There are two main views to design the smart technology management solutions in smart cities as shown below, centralized and distributed-to-centralized.

  • The centralized schema architectures are developed so that data is produced from many different data sources spread across the city but data is stored and reached from a centralized platform, mostly using Cloud technologies [1, 2]. This approach also exists in a partially decentralized or federated systems, often focused on database structures and replication, or separation of responsibility across systems [17, 18].

  • The distributed-to-centralized schema architectures use both potentials of centralized and distributed schema for processing and storage at the same time. For instance, this combined architecture highlights that the distributed technologies (such as Fog [5, 19], cloudlet [20], etc.) can contribute to centralized technologies (e.g., Cloud) at the same time to provide user requirements (e.g., data and software) from the smallest scale of the city to largest scale of the city.

With a focus on software management architectures in the smart city, a majority of the proposed architectures go beyond the Centralized Software Management (CSM) architectures which also centralizes the data management schemes [1, 2]. For instance, in [1, 2], the author designed an information framework for the smart city. This information framework used centralized schema architecture to organize data and software from city to cloud environments. This means that all applications and services obtain the data from a centralized cloud-computing platform through Centralized Data Management (CDM) architecture. Although the data is collected from different sources spread among the city, the data is accessible from a centralized platform, usually in the cloud. Alternatively, few proposals mentioned that a distributed schema for resource (few examples in [5, 19]) and data management (few examples in [9,10,11,12,13]) in smart cities by using distributed technologies such as Fog [5, 19], and cloudlet [20]; In addition, none of them have an explicit focus on software management architecture. One exception is found in [21] where the author explicitly address some initial issues related to a new health service model by using the potential of Fog (only sensors data considered in this example), and cloud technologies.

To sum up, we can highlight that almost all the available software management architectures for smart cities have the following limitations:

  • Almost all the software management architectures have been designed through or for centralized technologies (few examples in [1, 2]);

  • There are new schools of thought to propose a distributed-to-centralized software architecture by the contribution of Fog (sensors data) and cloud technologies (e.g., [21]) but they are not mature enough;

  • There is no proposed architecture to fit D2C-DM with D2C-SM architecture concerning using all data types and formats (including physical, and non-physical data sources) from distributed (the smallest scale of a city) to centralized (largest scale of a city) schema in smart cities.

For all discussed reasons, first, we suggest a novel hierarchical D2C-SM architecture by using Fog, cloudlet, and Cloud technologies for the smart city. In addition, this D2C-SM architecture can be matched with our proposed D2C-DM architecture [9, 10, 13]. Second, we envisage that this architecture can cover many of the above limitations. Finally, this architecture can be fitted to the idea of the ZEN center and its pilots [14].

3 Our Scenario Description: The ZEN Center

The ZEN Center is an example of smart cities projects in Norway. The ZEN center has a plan to develop the idea of the Zero Emission Building (ZEB) further towards neighborhoods [22]. The ZEN objectives have been to scale from buildings to neighborhood to reach the “zero energy” ambition. In addition, the European Union made a plan for buildings to reach the “nearly zero energy” level approximately in 2020 [14, 23]. In [13, 24], as shown in Fig. 1, the ZEN conceptual levels are depicted by three levels from the smallest scale of the city to the largest scale of the city, micro-, meso-, and macro. Furthermore, the ZEN center concentrates on meso-level of a city (neighborhoods) [14], constituting of varieties of city elements within buildings, streets, etc. The ZEN center has eight different pilot projects in distinct cities in Norway [14].

Fig. 1.
figure 1

An ICT architecture for ZEN center by using Fog, cloudlet, and Cloud technologies

Full size image

Six different work packages are defined by the ZEN center to fulfil its objectives [14]. The main tasks of this paper are in the work package on “ZEN Data Management and Monitoring: Requirements and Architecture” [14]. In [24], the authors mentioned that an efficient data management and monitoring is required for the ZEN center and its pilot projects. Two main roles are defined [24]. The first role is concerned with monitoring and evaluation and includes tracking the progress and success of ZEN along a set of important dimensions, identified through key performance indicators (KPIs). The next role is operational to support the work packages and pilots in the implementation of the project.

Our main responsibility for the ZEN center is to design a comprehensive ICT architecture for ZEN center and its related pilots. The ICT architecture includes different architectures (including data management, software management, etc.) to organize the ICT requirements for the ZEN center and its pilots concerning the ZEN business requirements and future requirements of the citizens in a smart city. In our previous work [9, 10, 13], we proposed a D2C-DM architecture to manage all produced data of the ZEN center and its pilots, from physical data sources (e.g., sensors) to non-physical data sources (e.g., simulated data). Then, in this paper, we start to draw a novel architecture for software management in the smart city, from distributed to centralized schema. Plus, we add this D2C-SM architecture to our ZEN ICT architecture.

4 The ICT Architecture for the ZEN Center

The conceptual background of the ICT architecture is structured into two main axes, “Time” and “Location,” as depicted in Fig. 1. In addition, the current proposal of our ICT architecture constitutes different inline architectures, including “data management architecture” and “software management architecture.” Also, in [9, 10, 13], we presented the different data types (consisting of the ZEN center and smart city) and technology layers (including Fog, cloudlet, and Cloud technologies) are required for the ZEN ICT architecture.

The bottom-up ICT architecture is designed to range from the very small scale to very large scale of the city. In addition, the proposed ICT architecture illustrates that the bottom layer (Fog-Layer) across the city has the lowest latency of the network communications and the limited resources capacities in terms of the processing and storage capabilities. Moving upwards from bottom to top makes the undesired level of the network latencies, while the capabilities of processing and storage will be improved.

This section is organized into two main subsections. First, we describe our previous works to design the D2C data management architecture for the ZEN center based on Fog, cloudlet, and Cloud technologies [13]. Second, we propose a novel software management architecture for the ZEN center based on the same technologies.

4.1 The D2C-DM Architecture for ZEN Center

In our previous work [13], we drew a fully hierarchical distributed (from sensors and IoT devices) to centralized (Cloud computing technologies) data management architecture for smart cities to organize smart city data types (including “real-time”, “last-recent”, and “historical”) as well as ZEN center data types (consisting of “context”, “research”, and “KPIs”) through the bottom-up ICT architecture.

As shown in Fig. 1, the F2c2C-DM architecture proposed data according to its age, ranging from real-time to historical data; and the data location and scope. The F2c2C-DM architecture [13] proposes the following three layers of architecture from Fog-Layer, to cloudlet-Layer, and Cloud layer. Those layers are covered by different data management strategies (including distributed and centralized):

  • Distributed data management: is the nearest neighbor to the end-users and IoT devices in the smart city and ZEN center pilots. Two different distributed technologies (including Fog and cloudlet) are used to handle the distributed data management for our proposed architecture. The core idea of the Fog and cloudlet are quite similar. This core idea is that the Cloud services could run closer to the users and data sources. Although, the main difference between Fog and cloudlet technologies is that the Fog uses the potential of available physical devices (such as traffic lights) in a city [5, 19], but the cloudlet installs new physical device(s), namely “data center in a box”, at the edge of the network [20].

    The distributed data management can provide facilities to do a set of processing and storage at the edge of networks. In [7], a data lifecycle model is proposed for the smart city (namely is SCC-DLC). This model offers three main blocks and their related phases as described below concisely.

    • Data Acquisition Block: The main responsibility of this block for the distributed data management is to collect all the available data (from physical and non-physical data sources) across the city. In addition, this block aims to prepare the collected data for the Processing and/or Preservation block concerning the capacity of the Fog and cloudlet resources in a city. This block has different phases as shown below:

      1. 1.

        “Data Collection” phase aims to collect different data types and formats across to the city by the available physical (such as sensors and IoT devices) and non-physical data (such as simulated data) sources. To apply this in our F2c2C-DM architecture, the Fog technology is responsible to handle physical data sources and cloudlet technology is active to add non-physical data sources in a city.

      2. 2.

        “Data Filtering” phase provides different types of facilities to perform different levels of optimizations (e.g., data aggregation, and cleaning) for the collected data in a city. In our architecture, a set of different algorithms can be defined within Fog and cloudlet technologies in each/all the local-domains to make optimization for the collected data concerning their resource capacities in each layer of Fog and cloudlet.

      3. 3.

        “Data Quality” phase has the intention to appraise the quality level of collected data. Plus, this phase can provide the facility to control the levels of security and privacy. To implement it in our architecture, a set of several different algorithms can be applied in each/all the local-domains by Fog and/or cloudlet technology.

      4. 4.

        “Data Description” phase has potential to do tagging data with some additional information and description of data (metadata), including data production time, data expiry time, data ownership, and so on. The Fog and cloudlet can handle this data description for physical and non-physical data sources locally.

    • Data Preservation Block: The main task of this block for the distributed data management is to store the collected data in local storage media for short-term (e.g., public data) and/or long-term (e.g., private data) usage purposes regarding the storage capacities of the data sources across the city. This block consists of four main phases as shown below:

      1. 1.

        “Data Classification” phase able to organize data (e.g., sorting and/or clustering data) for efficient storage at Fog and/or cloudlet layer.

      2. 2.

        “Data Archive” phase uses the capabilities of the local storage media at Fog and/or cloudlet layer to store the collected data for short and long terms consumption.

      3. 3.

        “Data Dissemination” phase brings a facility at Fog and/or cloudlet layer to publish data for public or private access through user interfaces.

    • Data Processing Block: The main objective of this block for the distributed data management is to establish a set of processing somewhere close to the data sources at Fog and/or cloudlet layer. This block includes two main phases:

      1. 1.

        “Data Process” phase prepares a set of processes to transform raw data into more sophisticated data/information at Fog and/or cloudlet layer.

      2. 2.

        “Data Analysis” phase offers analysis or analytic approaches for extracting further value and knowledge at Fog and/or cloudlet layer.

  • CDM: Normally, Cloud computing technologies are responsible for CDM tasks. The Cloud layer is located at the top level of the F2c2C-DM architecture. The Cloud technology offers the highest level of resources for the computing and storage that is positioned far away from the data sources and end-users. Furthermore, the Cloud can organize a variety of complex tasks (for instance, data processing) that sometimes cannot be organized in the lower layers (Fog and cloudlet) across the city.

4.2 The D2C-SM Architecture for ZEN Center

The ZEN center aims to provide several ICT applications/services/tools for the researchers, and partners regarding their requirements in the early future [14, 24]. By December 2018, there was a total of 18 tools available at ZEN center and their related pilots as described in [25]. Hence, the ZEN applications/services/tools must utilize a variety of data sources with different data types and formats from distributed to centralized through our proposed F2c2C-DM architecture.

As explained in Sect. 4.1, the F2c2C-DM architecture provided data according to its age, ranging from real-time to historical data; and the data location and scope. It means data can be available from the smallest scale of the city (e.g., room/building of pilots) to the largest scale of the city (e.g., the city through Cloud technologies). Thereafter, we envisage that we can design a new architecture for software management from distributed to centralized schema at cross-layers of our ZEN ICT architecture.

As shown in Fig. 1, we propose a D2C-SM on the right side of the ICT architecture. The D2C-SM architecture has been fitted to the D2C-DM architecture that highlights all that data (form real-time, to last-recent, and historical data) is available from the bottom (smallest scale of the pilot city location) to top (largest scale) of the cross layers of our ICT architecture. Our proposed D2C-SM architecture has three main layers to generate varieties of applications/services/tools as described below.

  • “Local Services” layer: Developers can use the locally stored data (the smallest data scale of the pilot city location) across the Fog, and cloudlet layers to create different types of services (including critical and private) in this layer as shown below.

    • Critical Services: The developers can build critical services (e.g., healthcare, fire, and accident) in a city at this layer. It means the service can be launched in this layer through the lowest network communication latencies.

    • Private Services: The developers can generate exclusive and privacy-aware services by using the private/locally stored data in this layer that is physically very close to the data sources and end-users. Thereafter, we can enhance data privacy levels through this kind of private services.

  • “Historical Services” layer: This layer uses the largest scale of stored data (cloud data storages) from all data sources (including physical and non-physical) in all city pilots. In addition, this layer can also contribute to other data sources that are out of the scope of the ZEN center. For instance, data sources from other Cloud service providers, etc.

  • “Combined Services” layer: This layer provides the facility for developers to use all data from distributed to centralized schema. For instance, in [21], the authors explained a particular medical application that needs to get data from medical sensors (real-time, local, and private data) as well as Cloud data (historical, large scale, and public data). Normally, this kind of services uses the history and background of particular data types in Cloud and then this data can be mixed with the local/real-time data to provide efficient services for the end-users.

5 The ZEN Center Use Cases

This section is organized into three primary subsections along with three different ZEN pilots in a micro-, meso-, and macro-level (from building, to neighborhood, and city) to illustrate the easy adaptation of the D2C-SM and D2C-DM architectures through ICT architecture as shown in Fig. 1.

5.1 The Micro-level (Use Case: The Living Lab)

The Living Lab is one building as a test facility located at NTNU in Trondheim, Norway [14]. The Living Laboratory is occupied by real persons using the building as their home and their consumption of novel building technologies, including smart control of installations and equipment, the interaction of end-users with the energy systems, and other aspects.

In the first example, we will use the living lab pilot (micro-level) as a case to illustrate the potential of our proposed D2C-DM and D2C-SM architectures:

  • With focus on our proposed data management architecture (D2C-DM), as shown in Fig. 2, the living lab is at the micro level (only building level). The data in the living lab pilot is currently produced by different numbers of sensors (IoT-Sources) at the micro level. At the micro level, Fig. 2 shows that the researchers can deal with context data (as real-time data) to build their research data concerning KPIs data and their requirements. Finally, for any future usage, the researchers can store the newly generated data (their research data) in the cloudlet technology. Also, the researchers have the possibility to store this in the local storage media (for instance their available storage at micro or/and meso level).

    Fig. 2.
    figure 2

    ZEN ICT architecture through the living lab scenario (one building case study)

    Full size image

  • With focus on software management architecture (D2C-SM), the developers can reach to the locally stored data (including real-time and last-recent data) through Fog and cloudlet technologies. Thereafter, the developers can create local services (including critical and private) concerning the business and users’ requirements and data privacy issues.

5.2 The Meso-level (Use Case: Campus Evenstad)

The campus Evenstad pilot is located in a rural area of Stor-Elvdal municipality [14]. The campus consists of seventeen buildings on 61,000 m2 of land. The campus provides a facility for administration, education, and sport, student housing and building operation. This campus aims to optimize energy production.

In the second example, we will use the campus Evenstad pilot (meso-level) as a case to illustrate the ICT architecture adaptation as described below.

  • With a focus on data management architecture (D2C-DM), as depicted in Fig. 3, the campus scope is in the meso level (including building and their neighborhoods level). Figure 3 illustrates that the huge number of data is generated by the different IoT-Sources of seventeen buildings and their related neighborhoods. The researchers can then use the context data (real-time data) to build their research data concerning KPIs and can store this data in their local storage media and their related cloudlet storages. Note that all data types (including context, research, and KPIs) of the Evenstad pilot are supposed to be for online access interface by different researchers through cloudlet technologies.

    Fig. 3.
    figure 3

    ZEN ICT architecture through the Campus Evenstad scenario (neighborhood case study)

    Full size image

  • With a focus on software management architecture (D2C-SM), the developers can have access to the locally stored data through Fog and cloudlet technologies to build their local services through the open data platform.

5.3 The Macro-level (Use Case: Smart City)

In the macro level, the ZEN partners might request to collect all data from each/all pilots of the ZEN centers by a single request. Therefore, we can use the potential of the Cloud technologies to keep all context, research, and KPIs data in their repositories for any future process and requirement. Consequently, all partners or other data stakeholders of the ZEN center can get access to the interface to use all obtained data from the pilots. In addition, many software and services can be launched by all obtained data (including historical, real-time, and last-recent data) at this level as depicted in Fig. 4.

Fig. 4.
figure 4

ZEN ICT architecture through the smart city case study

Full size image

6 Conclusion

In this paper, we further developed our proposed ICT architecture (including data management and software management architecture) for the ZEN center based on a distributed hierarchical schema by using Fog-to-cloudlet-to-Cloud technologies. The main points of this development are as following:

  • We illustrated that the potential of D2C-DM architecture could make data accessible from the smallest scale of a city to the largest scale;

  • The availability of data in all levels of a city provides desirable advantages to generate varieties of applications/services/tools across different layers of distributed to centralized schema;

  • We proposed a novel software management architecture to make different service layers (including local, historical, and combined) in each/all cross layers of distributed to centralized schema;

  • We envisage that D2C-DM and D2C-SM can adapt to ZEN center as well as other smart city environments.

As a part of our future work, we will discover more options related to developing our ZEN ICT architecture and its related inline architecture (including D2C-DM, and D2C-SM).