Smart Cities as Hubs: A Use Case in Public School Buildings

Abstract

Contextual data are receiving increasing attention in Smart Cities as they enable the development and delivery of smart services for their citizens. The homogenization of contextual data flows has become an important topic for standardization bodies as they attempt to enable data flow control and vendor-independent solutions. Buildings are a critical component of cities, due to their role in several dimensions of Smart Cities (including the United Nations Sustainable Development Goals); these may include the monitoring of their operation, maintenance, energy consumption, ability to respond in emergencies, and people flows, all of which affect the sustainability of a Smart City’s ecosystem. In this respect, Building Information Management Systems and Building Infrastructure Management Systems can benefit from this standardization. This paper presents how a novel solution named Smart-City-as-Hub can homogenize building contextual data and enable smart services’ development and delivery based on these data. The analysis of the data from several IoT deployments in public school buildings is the method used to highlight the segmentation and fragmentation of the IoT landscape and to present the benefits that the Smart-City-as-Hub provides in this context. The ways in which the Smart-City-as-Hub concept can mitigate these challenges and enable Smart City stakeholders to concentrate their efforts on developing value-added services is presented in the discussion section. By providing real-life data of the IoT devices deployed in Smart City projects, this study aims to further advance research pursuing the homogenization and standardization of Smart City flows.

1. Introduction

Sustainable cities have been identified as one of the 17 Sustainable Development Goals (SDGs) of the United Nations’ 2030 Agenda for Sustainable Development. One of the key challenges identified by the UN is urban energy consumption and pollution as “cities occupy just 3 per cent of the Earth’s land, but account for 60–80 per cent of energy consumption and 75 per cent of carbon emissions” [1]. In this context, the evolution of cities into Smart Cities is expected to contribute towards the more sustainable use of natural resources.

There are several definitions of a Smart City depending on the perspective from which they are approached. ITU and ISO standardization bodies define the Smart City as a model that uses cutting-edge Information and Communication Technology (ICT) to “improve living, efficiency, and competitiveness with regard to future generations” [2] and ”facilitate planning, construction, management, and smart services” [3]. A city’s “smartness” is defined as its capacity to utilize all of its resources efficiently in order to accomplish its objectives. A Smart City improves quality of life for its citizens in a number of ways, including efficacy, efficiency, and safety as well as citizen-centric services that promote active involvement in the Smart City’s evolution and governance.

A Smart City can provide the necessary data to measure and monitor metrics and Key Performance Indicators (KPIs) related to the energy consumption and pollution of the city. The gathered data can feed AI/ML models with datasets to allow for the modeling of the city’s current state as well as predicting the impact that technological or policy changes will have on these metrics. This can in turn empower local and central authorities to make informed decisions in order to meet their regulatory and sustainability goals.

The free flow of information in a unified, barrier-free environment is a key enabler for the accomplishment of the Smart City’s goals because it facilitates the integration of data from various sources and the consumption of these data in a frictionless way; ultimately, it allows for the development of value-added applications and services. However, the current Smart City literature suggests that the Smart City and buildings data landscapes are both segmented and fragmented, thus hindering the development of smart services and integration with Building Information Management Systems and IoT platforms.

This article is based on the Smart-City-as-Hub (SCHub) concept, as presented in [4], which introduces it specifically for the use case of IoT sensors deployed in public school buildings, and aims to answer the following research questions:

• RQ1: is the IoT landscape’s fragmentation described in the literature confirmed in practice?
• RQ2: can the SCHub concept become a layer for homogenizing building contextual data?

The empirical data used to answer RQ1 were collected by the authors in the context of the SCHub research project as described in the acknowledgements section. They come from six independent Smart City municipality projects in Greece focusing specifically on public school buildings. The deployed sensor capabilities, communication and information technologies, and generated data are presented in detail in the Appendix A.

This paper is structured as follows: in the next section, a literature review of this domain is undertaken. In the materials and methods section, we will discuss the high-level architecture of SCHub, present the six Smart City projects for school buildings, and analyze in detail the deployed devices that make up their Internet of Things (IoT) layer. Following that, an analysis of the use cases of the SCHub in relation to the data that are available in these projects is performed, and the benefits and challenges of this architecture are discussed. The paper concludes with a summary of the results, wherein directions for future work will be presented.

2. Literature Review

Large, complex buildings are a key characteristic of modern cities in the 20th and 21st centuries. From high-rise, landmark, privately owned structures to the numerous widely distributed public buildings used to support the city’s various functions, modern buildings have a multitude of installed devices that provide information about various physical properties and parameters. The collected data can be used to calculate KPIs in multiple dimensions including physical infrastructure, information and communication technology, environmental sustainability, productivity, quality of life, equity, and social inclusion [5,6,7]. These devices are connected to either private or public networks in order to transmit the data they collect, and they make up the IoT layer of the Smart City. There are a wealth of studies in the literature that use sensors deployed in buildings for use cases ranging from air quality [8]; thermal comfort [9]; fire hazards [10]; and design, operation, and maintenance [11] to full-scale IoT architectures for smart building operations [12]. A common theme in all these studies is that the sensors used do not have a standardized way of describing the data they produce, even if they refer to the same physical properties. The management of the content and quality of the data produced in Smart Cities and buildings is not standardized, leading to challenges when it comes to their integration, usage and interpretation [13,14,15,16]. In fact, the authors of [17] have proposed that the integration of IoT data in Building Infrastructure Management:

Is still described as isolated and segmented as currently there exists no generic interoperable IoT framework that can be reused and redeployed in different Building Infrastructure domains.

In addition, the authors of [17] have identified a gap between academia and industry as the former propose their ideas for the implementation of IoT in Building Infrastructure without verifying and evaluating their solutions in practice, while the latter design products that use vendor-specific solutions with limited interoperability. Similar gaps and challenges have been observed at the Smart City level. As the authors of [18,19] highlight, in practice, both the Smart City landscape in general and the IoT layer in particular are fragmented, with incompatible solutions being implemented both across and within Smart Cities. This fragmentation in turn negatively affects the engagement and participation of citizens, as discussed in [20], wherein it is suggested that

Information availability influences an individual’s attitude toward citizenship, and is positively associated with participation behaviour.

The cyber security of the multitude of sensors and devices deployed in Smart Cities and buildings is an important aspect of the research performed in this domain. The importance of cyber security in the IoT layer is emphasized in the European Cyber Security strategy [21] as well as studies from both academic and international organizations [22,23]. Research from the literature on the standards, protocols, and technologies used in the IoT space further highlight the fragmentation of the landscape, which in turns introduces additional difficulties in implementing an effective strategy against cyber attacks [24,25,26,27]. Recent advances in the cyber threat mitigation strategies increasingly make use of statistical and machine learning methods, which rely on access to large datasets and real time information from the IoT layer [28,29,30,31]. The complexity and lack of transparency in the security aspects of Smart City metropolitan-scale deployments raise concerns related to data privacy, particularly for the data that are related to Personal Identifiable Information [32,33]. Similar concerns have been raised in the use of data collected by Building Information Modeling platforms in the construction lifecycle context [34].

Two notable initiatives that aim to address the interoperability challenges in the IoT layer are FIWARE and Smart Applications REFerence ontology (SAREF). FIWARE aims to define, develop and provide open-source components for the acceleration of the development of solutions that are interoperable. According to its mission statement, [35]:

FIWARE Foundation drives the definition—and the Open Source implementation—of key open standards that enable the development of portable and interoperable smart solutions in a faster, easier and affordable way, avoiding vendor lock-in scenarios, whilst also nurturing FIWARE as a sustainable and innovation-driven business ecosystem.

On the other hand, SAREF is positioned as follows [36]:

The Smart Applications REFerence (SAREF) ontology is a shared model of consensus that facilitates the matching of existing assets in the smart applications domain.

Both these initiatives introduce abstractions and ontologies into the smart services layer that assist in organizing information and services so that they can be interoperable. However, the smart services layer consumes data retrieved from devices that make up the IoT layer of the Smart City or building. The intricacies, incompatibilities and proprietary vendor solutions of the IoT layer are not addressed within the scope of these initiatives.

The above findings from the literature support RQ1 with regard to the segmentation and fragmentation of the IoT landscape both on the Smart City and the Building Infrastructure Management level. With regard to RQ2, current initiatives for the homogenization of data used for smart applications and services do not focus on the IoT layer but rather build on top of it, which raises the question of how the information from the IoT infrastructure can flow to the higher-level layers and enable the development of smart solutions and services.

3. Materials and Methods

3.1. SCHub’s High-Level Architecture

SCHub’s high-level architecture has been presented and analysed in detail in [4]. The SCHub concept draws comparisons between the interactions among different network resources and a network hub in a typical computer network within the framework of Smart Cities. The network nodes in a computer network use a hub in an agnostic way to achieve communication among them using various protocols and payloads. Similarly, a Smart City uses a multitude of data sources, IoT devices, and communication protocols. The task of connecting them with one another, exchanging data, and undertaking the development of integration services is highly complex. The purpose of SCHub is to serve as the layer that homogenizes and standardizes the available information, simplifying and facilitating the communication among all the Smart City’s components.

In a nutshell, SCHub offers open and standardized northbound APIs to enable easy data consumption and customizable and dynamic southbound APIs to support connectivity with a variety of devices and protocols.

The generic IoT architecture, whose key elements have been thoroughly covered by [37,38,39], served as the model for SCHub’s design. To meet the unique requirements of the Smart City deployment environment and scale, its use in the SCHub concept requires extra care. More precisely, SCHub has to fulfill the following requirements:

• Generality: for the SCHub to facilitate the integration of current and future data sources, it must be extensible and independent of technology.
• Scalability/Elasticity: SCHub must be usable in both small-scale pilot projects as well as large-scale Smart City implementations. Because of this, the architecture has to be elastic, i.e., able to adjust to changes in demand, and scalable, i.e., able to grow its capacity as needed.
• Privacy: Sensitive and Personally Identifiable Information may be present in the data and metadata generated by Smart City components. This information must be carefully managed in compliance with local laws and regulations. At the same time, these data are essential in facilitating the development of services with added value. For this reason, SCHub needs to keep a balance between these two competing requirements.

The SCHub layer core elements depicted in Figure 1 include the following:

• Sensors that offer the raw data gathered by a building’s or Smart City’s IoT sensing layer;
• Building Management Systems/IoT platforms which represent the current ICT infrastructure that buildings and Smart Cities deploy to manage their IoT devices;
• SCHub gateways which are the points of entry where data from the southbound components are provided in the SCHub.
• SCHub API which is the internal SCHub service layer that allows data providers and consumers to communicate in a decoupled fashion
• Data consumers which are the clients of the SCHub API that gain access to the data provided by the IoT layer

A summary of the main design fundamentals of the SCHub reference architecture, which are discussed in detail in [4]:

• API-first design to guarantee that the information is readily available to integrate with external services;
• Baked-in security to be capable of meeting the most stringent standards for data availability, consistency, and integrity;
• Privacy by default to guarantee that any concerns about how personally identifiable information is handled are taken into account.
• Functional Requirements

  –

  Modular design in order to enable the independent deployment of connectors and gateways in accordance with the selected data sources and use cases;

  –

  Role-based access in order to provide fine-grained data consumption, allowing SCHub users to access just the information that is necessary;

  –

  Support for both on-premises and cloud environments to provide a flexible deployment model tailored to the requirements of each use case.

• Non-functional Requirements

  –

  The SCHub must be able to grow horizontally to provide the capacity needed for the use cases that have been discovered.

  –

  To increase availability and reduce the possibility of any component becoming a single point of failure, the SCHub must support both geo-separation and high availability for deployment failover.

3.2. Public School Smart City Projects in Greece

The European Commission in alignment with the UN Sustainability Agenda has created the European Green Deal, which has the strategic goal of [40]

Making Europe the first climate-neutral continent in the world (which) is a binding commitment under the EU Climate Law.

Within this European framework, Greece has kicked off the Greece 2.0 National Recovery and Resilience Plan, which includes an integrated and coherent set of reforms and investments structured in four pillars that make up eighteen components [41]. The first pillar is dealing with the country’s “Green Transition” and, more specifically, component 1.4 focuses on “Sustainable use of resources, climate resilience and environmental protection”. In pursuit of this strategic goal, a number of projects have been initiated by Greek municipalities in order to improve the energy efficiency of their infrastructure. For the public buildings in particular, there are both active interventions (including upgrading buildings’ insulation, replacing energy-inefficient equipment, and introducing renewable energy sources) and passive actions, which include installing sensors in order to monitor energy consumption and efficiency and avoid wasting natural resources.

The six municipalities listed in

Table 1. Number of schools with IoT sensors by municipality.

Municipality	Number of Public School Buildings
Municipality of Herakleion	8
Municipality of Kordelio–Evosmos	2
Municipality of Korydallos	10
Municipality of Piraeus	20
Municipality of Thermi	2
Municipality of Thessaloniki	2
Total	44

are among those that have recently completed pilot projects for the installation of energy-monitoring sensors in a subset of their public school buildings.

These municipalities span from the north part of Greece to the southern island of Crete, as shown in Figure 2. In each public school, sensors that monitor air quality, diesel consumption for heating, electricity, water consumption and water tank level monitoring have been installed. The types of sensors selected by each municipality are summarized in

Table 2. Installed sensors in public schools by municipality.

Municipality	Air Quality	Diesel Consumption	Electricity Consumption	Water Consumption	Water Tank Monitoring
Herakleion	no	yes	yes	yes	yes
Korydallos	no	yes	no	no	no
Kordelio–Evosmos	yes	yes	no	yes	no
Thermi	yes	yes	no	yes	no
Piraeus	yes	yes	yes	no	no
Thessaloniki	yes	yes	no	yes	no

.

The capabilities of the installed sensors, summarised in

Table 3. Communication capabilities by sensor type.

Sensor Type	Things Layer, [17]	Transport Layer	Application Layer
Air quality type I	NB-Iot/LTE Cat-M1	TCP/UDP	Manufacturer proprietary
Air quality type II	Zigbee	TCP	MQTT
Diesel consumption	NB IoT	UDP	Manufacturer proprietary
Electricity consumption	NB IoT	TCP	MQTT
Water consumption	NB IoT	UDP	Manufacturer proprietary
Water tank monitoring	NB IoT	UDP	Manufacturer proprietary

, are as follows:

• Air quality sensors: Air quality sensors are of two types provided by two different manufacturers. The Type I sensor is battery-operated and measures temperature and humidity levels. The Type II sensor is connected to the mains utility power and measures temperature, humidity, and CO₂ levels. The Type I sensor transmits the data using either NB-IoT of LTE Cat-M1 depending on the Wide Area Network (WAN) coverage. The Type II sensor uses a local, private Zigbee network that connects to the Internet via a gateway. In terms of transport layer protocols, Type I sensors can be configured to use TCP or UDP, while Type II sensors use TCP only. Finally, in the application layer, Type I sensors use a manufacturer proprietary protocol while Type II sensors use MQTT.
• Diesel consumption sensors: The diesel consumption sensors used in all municipalities are from the same manufacturer. They are battery-operated and use ultrasound to measure the distance between the sensor and the diesel surface in the tank. The communication protocol used is NB-IoT, the transport layer protocol is UDP, and the application layer protocol is manufacturer proprietary.
• Electricity consumption sensors: The electricity consumption sensors used in all municipalities are from the same manufacturer. They are connected directly to the mains utility line to measure voltage, current, power, and active and reactive energy in all three phases of the alternating current supply. The communication protocol used is NB-IoT, the transport layer protocol is TCP, and the application layer protocol is MQTT.
• Water consumption sensors: The water consumption sensors used in all municipalities are from the same manufacturer. They are battery-operated and connect to water meters installed in the schools using the MBus-Eco protocol in order to retrieve the water meter’s reading. The communication protocol used is NB-IoT, the transport layer protocol is UDP, and the application layer protocol is manufacturer proprietary.
• Water tank-monitoring sensors: Water tank-monitoring sensors are used only in the Herakleion municipality. They are battery-operated and use ultrasound to measure the distance between the sensor and the water surface in the tank. The communication protocol used is NB-IoT, the transport layer protocol is UDP, and the application layer protocol is manufacturer proprietary.

In addition to their primary objective, each sensor is also measuring additional properties. In particular, the Type I air quality and energy consumption sensors measure the NB-IoT or LTE Cat-M1 network coverage while the diesel consumption, water consumption and water tank level sensors measure temperature and NB-IoT network coverage. The primary and additional measurement capabilities of the installed sensors are summarized in

Table 4. Primary and additional measurements by sensor type.

Sensor Type	Primary Measurements	Additional Measurements
Air quality type I	Temperature (°C)	Battery level (mV)
	Humidity (%)	Network coverage (dBm)
Air quality type II	Temperature (°C)	None
	Humidity (%)
	CO2 (ppm)
Diesel consumption	Available fuel (m3) Consumption (m3/h)	Battery level (%)
		Network coverage (dBm)
		Temperature (°C)
Electricity consumption	Voltage (V)	Network coverage (dBm)
	Current (A)
	Power (kW)
	Energy (kWh)
Water consumption	Consumption (m3)	Battery level (%)
		Network coverage (dBm)
		Temperature (°C)
Water tank monitoring	Available water (m3) Consumption (m3/h)	Battery level (%)
		Network coverage (dBm)
		Temperature (°C)

.

Regarding the payloads that each sensor generates, they are encoded in either binary, text/csv, or text/json format. The measurement data are sent either in a single or in separate messages. The payload-specific information is summarized in

Table 5. Payload encoding by sensor type.

Sensor Type	Payload Encoding	Measurements’ Grouping
Air quality type I	Binary	Single message type
Air quality type II	Text/json	Multiple message types
Diesel consumption	Text/csv	Multiple message types
Electricity consumption	Text/json	Multiple message types
Water consumption	Text/csv	Multiple message types
Water tank monitoring	Text/csv	Multiple message types

. Additional details with regard to the raw payloads from each sensor type and their parsed data are available in Appendix A.

4. Results and Discussion

The data that was studied from the 44 schools of the six municipalities confirm the findings from the literature with respect to the fragmentation of the IoT landscape and the challenges of interoperability among the deployed IoT devices. Although there are different approaches in the things [17], transport, and application layers, as shown in Table 3, these are expected and to some extent justified as the manufacturers select the most appropriate technology in each layer to optimise their devices. For example, the TCP and MQTT protocols in the transport and application layer, respectively, are more advanced and easy to use than UDP and text/csv or manufacturer proprietary protocols. On the other hand, both TCP and MQTT require more energy to operate and transmit, which does not make them efficient for devices that are battery-operated. In the things layer, NB-IoT is a valid approach for devices that are deployed in a wide area where mobile network coverage is available; however, local Zigbee networks can be more cost-effective in cases in which there are multiple devices deployed in the same building.

There are, however, two areas that have room for improvement in terms of standardization, namely the payload structure and the message types. The payload structure varies greatly among the different sensor types, even for the same measured quantity, like temperature or network coverage, as can be verified by the generated payloads listed in Appendix A. Lacking any widely adopted standard, each manufacturer has structured the payloads for their devices as they see fit without taking into account interoperability requirements with other devices and Building Information Management Systems or IoT platforms. The same applies for the message types which group the measured information in an arbitrary way, ranging from a single message type that contains all the data measured by the sensor (Appendix A.1) to separate message types for each component of the measurement (Appendix A.4). Note that this distinction is not related to the encoding of the payloads (which, depending on the sensor’s capabilities, may be binary, text/csv, or text/json) but rather to the payload content itself. The payload encoding should in fact be optimised by each manufacturer to make sure the sensor is operating in an optimal way. For example, binary encoding is much more efficient than text/json in terms of energy consumption both at the sensor’s micro-controller level and during transmission. On the other hand, text/json encoding is more easily parsed by a web service or IoT platform than binary encoding. The compatibility of payload contents among different sensors, however, is what will make the flow of the information generated by the sensor easier to consume and more effective for use. In this regard, the RQ1 can be answered affirmatively as the IoT landscape fragmentation discussed in the literature is confirmed by the collected empirical data.

As discussed in the previous section and depicted in Figure 1, the SCHub layer is positioned between the southbound IoT devices and the northbound API interface and is responsible for the homogenisation of the Smart City IoT data. The benefits of this architecture in the public buildings use case are many. An API that abstracts the differences of the various manufacturer’s payloads and provides a uniform interface for the same kind of data independently of the device that produced them makes it easier to integrate them in third platforms and services. For instance, the diesel, electricity and water consumption data of each public school in each municipality could be integrated once with their Building Information Management Systems platform, regardless of the sensor type that is deployed. This helps the municipality to avoid vendor lock-in and increase competition as it allows different manufacturers to provide their solutions. On the other hand, the unification of the northbound data payloads enables the creation of additional services across municipalities in a frictionless way. As SCHub can provide both the primary as well as the additional data each device produces (Table 4), it can support use cases that were not foreseen within the initial project’s scope. For example, although network coverage was not among the goals of the municipalities’ school buildings projects, these data could be used for studies by network operators across the whole country since most of the devices measure this quantity anyway.

With regard to the cyber security aspect of the IoT layer, the introduction of the SCHub layer can be beneficial in two ways. The introduction of the SCHub layer between the producers and the consumers of the data does not expose the underlying infrastructure and thus reduces the attack surface, making it easier to defend against cyber attacks. The second benefit is related to the access rights that can be implemented at the SCHub layer, meaning which users have access to which type of information can be finely controlled. Both these benefits can be provided in a vendor- and protocol-agnostic way as they are not dependent on the design decisions and implementation details of each individual component of the IoT layer but are enforced at the SCHub layer in a uniform way across all sensors and devices, further promoting seamless access to the Smart City and building contextual data in a secure way.

The free flow of the information produced by the Smart Cities’ IoT layer that SCHub provides leads to the democratization of the data, which can now be shared in a consistent and standardized way with research institutions and public or private organisations. Another example from the public school buildings data is the temperature that almost all sensors measure regardless of if this is their primary purpose or not. A SCHub that aggregates data from a multitude of Smart City sensors (which, among other things, provide temperature measurements with varying levels of accuracy) can provide a huge dataset of real-time or near-real-time heat maps of a whole city or country simply by using the IoT devices that are already deployed. The SCHub can become a platform for experimentation and citizen science initiatives as it facilitates access to the wealth of data produced by the Smart City. A straightforward extension of this architecture would be the provision of a business service that focuses on a particular set of data and makes them accessible to students in order to design experiments and gain insights into how their city works and evolves. In summary, the RQ2 can also be answered affirmatively because the SCHub layer can provide the homogenization of the Smart City alongside building contextual data.

Naturally, this concept can also be extended to privately owned buildings, both commercial and residential, in order to tap into the data generated by Smart Home sensors. This includes the numerous kinds of smart meters used for electricity, gas, or water; occupancy sensors in parking lots; environmental sensors; and even health and biometric information from smart watches. It should be emphasized that the centralization of Smart City Building Information Management Systems and IoT platforms can negatively affect citizens’ privacy and data sovereignty. This is an important topic that will make creating the SCHub layer for Smart Cities more difficult. The abundance of sensors installed in Smart Cities makes it possible to gather information and metadata that may be correlated with individuals. For this kind of data, the SCHub layer can guarantee the anonymization and sanitization of the provided information to ensure that citizens’ privacy is respected. As the SCHub concept expands and affects the private sphere of Smart Cities’ citizens, the cyber security mechanisms described above need to be put in place to avoid the exploitation of data for monitoring the behavior of individual citizens. This is one of many high-level design principles involved in SCHub, but its success depends heavily on its practical implementation and the technologies used.

5. Conclusions

The SCHub concept is an ongoing project. To obtain the broadest possible perspective of the Smart City data provision landscape, it is beneficial to identify and gather additional real-world use cases. Continuous effort is also required for the standardization of northbound APIs, which will facilitate easy and consistent access to the available data sources. Concerning the SCHub architecture itself, an aspect that needs further analysis is its scalability requirements, i.e., how it can grow to support the ever-increasing number of sensor and devices deployed in buildings and Smart Cities. Furthermore, the empirical data collected from the devices deployed in school buildings projects can provide the basis for further research on methods and practices that can be used to explore, visualize, and utilize these data for building new value-added services.

The introduction of the SCHub layer in a Smart City project mitigates the segmentation and fragmentation of the IoT landscape, as we have established using data from practical projects for energy monitoring in public school buildings that have deployed IoT devices in the field. The simplicity in data consumption that SCHub provides enables Smart City stakeholders to concentrate their efforts on developing value-added services instead of struggling with data manipulation and API incompatibilities. The SCHub architecture supports the process of discovering and consuming data and at a macro level acts as a layer enabling new collective intelligence use cases and other creative ideas for buildings, Smart Cities, and communities.