Urban Open Platform for Borderless Smart Cities

Abstract

As a network of connected sensors to transform data into knowledge, Urban Platforms have been rooted in several smart city projects. However, this has often resulted in them being no more than IoT dashboards. More recently, there has been an increased interest in supporting the data governance and distributed architecture of Urban Platforms in order to adjust these with the administrative structure in a specific city. In addition, Urban Platforms also deal with data roaming between different stakeholders including other cities, different government levels, companies and citizens. Nevertheless, the first deployments have led to an inflexible “smart cities in a box” approach that does not help with building digital skills and causes vendor lock-in to products that do not scale. There is a need to start with simple and widespread urban services through a collaborative joint cross-border, hands-on effort. In order to meet the level of interoperability, international standards should be adopted. The aim of an Urban Open Platform (UOP), introduced in this paper, is to support not only data acquisition but also various types of data processing: data is aggregated, processed, manipulated and extended within the city context. Conceptually, special attention has been put on scalability, roaming and reliability in urban environments. This article introduces the UOP uniquely in the cross-border data exchange context of two European capital cities, Helsinki and Tallinn, and validates it with 10 real-life urban use cases.

1. Introduction

This paper is motivated by the challenge that the capabilities to collect and use urban data sources are low, while at the same time the volume of data is constantly increasing. This also applies to technical competences for data processing and data analysis. This is according to a survey conducted with Estonian municipalities (https://taltech.ee/en/finest-centre-for-smart-cities#p34631, accessed on 9 November 2021) in a European country with one of the most advanced digital public services, according to the pan-European DESI Index, which probably points to the global nature of this challenge. In this light, we have investigated which data collection and analysis tools cities could use to deal with this problem, starting with use cases in Estonia and Finland. In addition, the issue is much more complex when we start analysing cross-border cities and their data exchange, calling for research-based solutions. Therefore, the main contribution of this paper is an attempt to bring the level of analysis from the single-city Urban Platform to the multiple-cities level.

Data, including the means of processing it, is not a new phenomenon for cities—this has been at the central of urban governance since the industrial revolution began in the 19th century [1]. Therefore, the key question is how it is changing in the context of digital technologies that are redrawing the borders between cities, countries and companies; at least the virtual borders. This paper investigates how data can be exchanged, both within one city and also across cities and their stakeholders. Digital technology breakthroughs such as Facebook, Skype, Google and LinkedIn have clearly changed the understanding of the world map: if one is online, there are no borders, at least in online communications services. On the other hand, the picture is different if zoomed into urban levels where each department in each municipality tailors its own electronic services. Local services are often developed in isolation with minimal attempts to co-design the services jointly with other key stakeholders (other cities, different government levels, companies, citizens, etc.). Furthermore, digital urban services are often developed and analysed from the “closed-borders” perspective, disregarding, for example, everyday commuters from other regions and the fact that, at least technologically, services and data can be scaled over institutional borders [2].

According to Eicker et al. [3], an Urban Platform (UP) is a key software infrastructure for urban planning and maintenance, designed to handle and analyse large datasets from different domains. The authors argue that the main driver should be to help cities follow zero carbon strategies via the inclusion of all major sectors of CO₂ generation. Similarly, Hernández et al. [4] see the end goal of the digitalisation of cities is to become more environmentally friendly, which as a process can be achieved via the Open Standardized Urban Platform with the main functionalities of data ingestion, analytics and services. Badidi & Maheswaran [5] and Chenget al. [6] put the deployment of sensors as being more central in Urban Platforms’ applications, with the end goal to improve the quality of life. The wider goal is to enable the transition of cities to more sustainable systems (less CO₂, more energy efficient, more environmentally friendly, etc.—all better for the citizen). Nevertheless, there are still structural obstacles such as openness and interoperability in those Urban Platforms. The issue is brought out by Lee, Mackenzie, Smith, & Box [7], who mapped 100 urban data practices that contribute to “platform urbanism” by noting a concern dynamic of city administrators to be ”locked in” to specific corporate products and interests. In addition, Badidi & Maheswaran [5] argue that data interoperability and integration is the most challenging smart city problem.

In general, the literature on big data classifies sources under three broad categories: opportunistic sensing, purposely sensing and crowd sensing [8]. Opportunistic sensing leverages data running on existing systems, such as a telecommunication network, but can be used to better understand different systems. In other words, data is collected for one purpose and used for another. This approach to data collection is made possible largely by the fact that mobile phones have become ubiquitous (www.itu.int/ITU-D/ict/material/Telecom09_flyer.pdf, accessed on 9 November 2021)—citizens replace the need for purpose-built sensors, contributing real-time data through their portable devices. Other typical data providers include credit card companies recording user transactions, taxi fleets reporting vehicle GPSs, etc. In contrast to opportunistic sensing, purposely sensed datasets are derived from ad hoc sensor networks configured to study a specific phenomenon. Thanks to advances in microelectronics sensors, computations are becoming increasingly affordable and distributed, a phenomenon often referred to as “smart dust”. Hence, networks of remote sensing agents can now be embedded in the city fabric to extract large amounts of information. This data is channelled into central control stations where it is aggregated, analysed and used to make decisions on how the monitored terrain should be regulated and actuated. Here, the resulting datasets tend to be more uniform, with the stated use and actual end-use scenarios better aligned to decode various flows within the city.

In every city, the complete story cannot be told by figures and data alone. To adequately assess a situation, the voice of the citizen must be heard. Each urbanite can be thought of as a human sensor, capable of reporting on their experience of the city through content-sharing platforms such as Flickr, Twitter, Facebook or Wikipedia [9]. These actions offer a unique view of how citizens navigate their environment, bringing clarity to points of attraction or spontaneous migration. This approach describes the third data source known as crowd sensing. The crowd becomes a distributed network of sensors that allows understanding the dynamic patterns of the city and the experiences of its citizens at a quasi-real-time rate. In the absence or failure of top-down sensor networks, this grassroots approach to sensing leverages the millions of newly cyber-connected citizens to coordinate human activity on an unprecedented scale. Integrated cities perform with unparalleled efficiency (whether resources, transportation or infrastructure), enabled by digitally controlled circuitry and virtual operating systems, ultimately transforming urban space into an open living lab.

However, the question remains to what extent Urban Platforms attract participation of citizens in the provision of better services. In one study, citizen e-participation was positively associated with the clearance rate of urban service requests, although the effect size of participatory service performance varies between different types of city services—there was more involvement in complex problems compared to simple routine services [10]. Importantly, Urban Platforms can also be independent from the direct role of the city government. Velsberg, Westergren, & Jonsson [11] focus on the concept of “smartness” in the context of service provision, reflecting the ambition of the public sector to become more agile and resilient when applying novel technologies such as the Internet of Things—also central to Urban Platforms.

The Internet of Things (IoT) is a concept for connecting various sensors to the Internet using big data analytics [12] with applications in smart cities [13]; it can, at least theoretically, improve the urban services and reduce resources consumption [14]. There are also papers that take a more critical or realistic approach by claiming that building large-scale smart city IoT platforms remains empirically challenging [15], in addition to challenges of how to solve the privacy rights of residents [16].

According to Barns [17], platforms play a growing strategic role in the daily lives of cities via matchmaking between subjects, whether for mobility, accommodation, shopping and even dating, making these platforms wider data ecosystems of users, producers and consumers. Nevertheless, there is a lack of research in understanding the operational model of the Urban Platform that has different goals that also can be in conflict, e.g., city internal operation and service versus publishing public data [18].

This rest of this paper is structured as follows: Section 2 provides an overview of the vision and architecture of Urban Platforms, via introducing the concept of the Urban Open Platform; Section 3 applies this to the use case of the cities of Tallinn and Helsinki; and Section 4 wraps up with discussion and conclusions.

2. Urban Open Platform: Vision and Architecture

2.1. The Vision of Urban Open Platform

The vision of the Urban Open Platform (initially developed by Carlo Ratti Associati, under the label of Urban Operating System in 2016 for the H2020 project FinEst Twins) is quite simple. Deploying a network of sensors that can capture real-time data from a myriad of occurrences in the city and connecting such sensors to an urban information system helps to better analyse and transform such data into knowledge (see Figure 1). As a result, new types of urban efficiencies, products and services for city dwellers can be created. In turn, users can access an open-access digital services delivery platform via a smartphone or laptop all the way up to digitally enhanced infrastructures such as responsive public spaces, intelligent transport systems or smart energy infrastructure. The city becomes a permanent platform for interaction, providing a unique mix of services to each user. Furthermore, by giving users the capability to develop their own solutions and services, a more inclusive and bottom-up model of both social and economic development will be created while jumpstarting local dynamics.

Organisations that design systems tend to reflect the organisational structure in the architecture [19]. In a diverse organisation such as a city, this has caused challenges in both the enterprise and the data architecture. Common data warehouses have had a limited scope, such as supporting financial and HR functions, while the operational systems remain on their own. When data platforms have been created to support advanced analytics and business intelligence, the overall enterprise architecture has been split into two main functions: an operational plane (operational systems, often legacy) and analytical plane (data warehouses, data lakes, BI). The link between the two planes has typically been an ETL process defined for each data pipe. The larger the organisation, the more challenging this approach has been to govern and maintain. The vast amount of data coming in from IoT and automation systems has also raised the concern whether it is feasible to store everything on a central data lake.

An Urban Open Platform shifts the focus from centric data platforms towards cross-organisational capabilities and empowering domain specialists with data acquisition and manipulation functions. Cities cannot foresee a future where hundreds of data engineers would be employed to manage the new data pipelines required for situational awareness. The platform is a collection of components with connectors and APIs that can be “wired” together in different ways to meet the various and evolving data integration and context enhancement needs. These tasks should not require programming experience but be available for domain specialists as a user-friendly, self-service platform. The divisions and departments of the cities can continue maintaining their own data marts and lakes, but policy management and advanced data catalogues with discovery options make it possible to adopt the layers of data governance both at the unit and enterprise levels. The data analytics in the operational plane are supported by stream processing capabilities and data virtualisation. With this approach, it is more feasible to analyse large amounts of data, such as the current state of city street lights, without having to create a massive time-series data store. For this to be achievable, the following properties must be inherent to the system:

Architecture: The data management layer provides standardisation and a storage function for the platform, facilitating the analysis of long-term sensor data. The UOP would be the primary conductor of various data streams used by the various digital services between two cities.

Integrating data streams: Ubiquitous sensors and sensor networks such as building automation systems are increasingly providing data sources of different contents, formats and qualities. Integrating diverse data sources allows developing applications that would not be possible by using a single sensor network. When integrating data from heterogeneous sources, syntactic, schematic and semantic diversities of the data schemas are challenging problems. The past work on IoT platforms has evolved into generic capabilities supporting real-time stream and event processing. Through an UOP, data from diverse sources is translated into a common language, APIs and visual interface. The capabilities shift the focus from raw data acquisition towards reusable, high-quality data products.

Data processing functionality: The UOP will offer businesses, citizens and governments situational awareness with the ability to combine real-time data from across some data streams to create an up-to-the-minute picture of urban material flows and dynamics. In addition, carrying data from providers to consumers, the Urban Open Platform will allow clients to quickly process, manipulate and visualise the data of data streams. With the help of open APIs, applications can also be published and shared among users.

Scalability and flexibility: Agile development processes have dramatically changed the way technology is being implemented. Shorter cycles allow society to constantly adapt to change or new conditions. When applications and services are developed in an agile fashion, the architecture should be evolving as well. Ford et al. [20] see the architecture as a constant effort that can react both to changing requirements but also to feedback from programming. The UOP will be designed to meet current needs without compromising the ability of future generations to meet theirs. At the moment, we can assume there are hundreds of data streams, and with individuals contributing, this number easily rises into the thousands. Taking into account the overall input load and the number of potential clients, a quick approximation indicates that we could easily reach one million messages per second. An Urban Open Platform will be designed to initially deal with a small load but, at the same time, it will need to be designed to scale to hundreds of machines to accommodate the additional load.

Inhabitants as actors: Truly smart cities will emerge as inhabitants and their many electronic devices will be recruited as real-time sensors of daily life, agents for sensing and reporting their individual experience. Offering a real-time view of how human, material, digital and financial resources travel through the landscape of their daily lives will perceptually expand each citizen’s sphere of responsibility from the domestic space to the space of the city, with the city becoming the smart meter of all these factors. In a digitally augmented smart city, civic zones can be transformed into responsive environments through technological mediation. This would change the passive inhabitants of the city to active participants of spatial scenarios and the public spaces from areas of transit to urban destinations.

2.2. Urban Operating System as a Data Platform

In relation to Urban Platforms, there has been growing interest in better supporting the data governance and distributed architecture to best fit the needs of how cities operate organisation-wise. Cities are often seen as a single entity with a single voice, but this is not the case in terms of the ICT tools and platforms that cities operate on. The departments and units have had a lot of independence in their choices of systems. One core element of the UOP is its ability to handle legacy data sources and a variety of data formats. However, the data integration capability is a standard requirement on any data platform and does not depend on new innovation. For example, the extract-transform-load (ETL) is a process that has been around since the early 1970s. What is more difficult to tackle, however, is the governance, ownership and routes of the data between the city departments, platforms and systems with multiple stakeholders.

The publishing of open data on Urban Platforms has also brought in product thinking, i.e., seeing and developing the urban data as a product [21]. In general, datasets fit well with the definition of product: anything that can be offered to a market for attention, acquisition, use or consumption that might satisfy a want or need [22]. Data products are owned by product owners who may have a wider interest in defining the “features” of the product, including data quality, context, documentation in data catalogues, etc. Data product is seen as a result of value-driven analysis that generates added value from the underlying data (https://www.oreilly.com/radar/what-is-data-science, accessed on 12 June 2018) and is well aligned with service design concepts. The key mechanism of value creation is to create insights out of data using analytical methods.

Some recent terms introduced in data platform discussion are data mesh and data pipelines. Data mesh was introduced as a concept by technology consultant Zhamak Dehghani (https://martinfowler.com/articles/data-monolith-to-mesh.html, accessed on 9 November 2021). Her key message was that data platforms based on the central data lake architecture have common failure modes that have prevented them from being scaled up and widely used. Her suggestion was to consider data domains with a higher priority, to apply platform thinking to create self-service data infrastructure and to treat the data as a product.

2.3. The UOP’s Working Concept

The UOP’s working concept applied in this paper is based on the previous work of the European Innovation Partnership on Smart Cities and Communities (EIP–SCC). EIP–SCC has defined six Action Clusters as its key priority areas, including “Integrated Infrastructures and Open Data”. A general observation is that Urban Platforms are a prerequisite to support fast take-up of smart solutions in cities to allow many stakeholders to participate. It is also expected that Urban Platforms would have a key role in the integration of third-party vendor solutions.

The Urban Platform vision of EIP–SCC is that by 2025, 300 million EU citizens will be served by platforms within their cities and, in the short term, accelerate the adoption of Urban Platforms through an easy-to-implement template approach and cross-sector collaboration. Meanwhile, the cloud platforms will have picked up and the public sector will have started to move their services into AWS, Google or Microsoft Azure cloud services.

Urban Platforms are expected to form a core building block by which cities better manage the current explosion in the volume of city data and more easily share this data between city services in order to provide meaningful services to their residents. It should be noted though that the UP is not a single IT system or server. It is a collection of smart city services that communicate internally and externally with harmonised APIs. The platform should be distributed and decoupled for various reasons. The city organisational complexity does not support the idea of a single-owner, single-administrative platform but the operational models should be based on a governance model that takes this into account.

The Urban Platform initiative was supported by launching a memorandum of understanding that had 85 signatories, including both city- and smart-city-related vendors. In 2016, it was estimated that the UPs were fragmented, had uncertainties on the demand side and were lacking interoperability and common standards from the supplier side. At the moment, there is still work required on all these areas.

The Urban Platform concept has evolved through several Horizon 2020 and European Regional Development Fund (ERDF)-funded projects such as bIoTope, mySMARTLife, Select4Cities and SynchroniCity. In many of the projects, the usage of Urban Platforms has focused on being an IoT platform with dashboards. The support of spatial data and large-scale data utilisation have been somewhat limited and many of the pilots were experimental platform products that were not ready nor intended to be in full-scale production use. The limited vision of the scope also missed the opportunity to support cities in some of their new data-related responsibilities, such as maintaining Infrastructure for Spatial Information in Europe (INSPIRE) – compliant data services and providing support for Sustainable Energy and Climate Action Plan (SECAP)–reporting. The Urban Platform should also not be seen as a monolithic, single service but as a distributed and decoupled collection of services that can complement cities’ existing data platforms. In both Helsinki and Tallinn, a key question is how can the Urban Platform build on top of the Microsoft Azure data lakes and data warehouses that both cities have already invested in.

2.4. UOP Architecture

While the Urban Open Platform is an implementation of the Espresso preference architecture, based on the H2020 ESPRESSO project, some areas have evolved over the years. The Espresso architecture was seen to drive towards a monolithic, independent entity approach, yet the market trends are moving towards serverless, microservice and nanoservice architecture. The modern cloud architecture makes it harder to describe the entity as a layered capability matrix. Even the typical “hamburger model” of IoT platforms with southbound, data lake and northbound is misleading in many ways, especially in event-driven architecture that IoT platforms often are. The platform is expected to support not only data acquisition but also various types of data processing. Data is aggregated, processed, manipulated and extended with context. By default, any data can have a spatial reference—not only as origin defined with coordinates but also with the abstract city model feature as an origin. In addition, real-time data comes in many forms. Compared to other implementations of an urban data platform, the UOP platform is not expected to directly support IoT sensor connections. It is assumed that nowadays practically all large-scale installations would connect to the platform through gateways that the sensors connect with automation fieldbus networks such as BACnet in building automation.

The planned high-level architecture of the Urban Open Platform, illustrated in Figure 2, follows the conventions of previous projects such as H2020 ESPRESSO, H2020 SynchroniCity and H2020 mySMARTLife. Special attention has been put on scalability and reliability in large-scale production environments. The new data strategies from Helsinki and Tallinn have contributed to the planning and existing enterprise architecture and provided guidelines on relevant existing technologies and services to adopt and engage. In both cities, the central data platforms are based on Microsoft Azure, which now is also the basis of the Urban Open Platform.

The openness and distributed nature of the platform comes from components being defined for specific functionality. As an example, the data fusion stage can be implemented as an ETL process, a data integration task created with Apache Camel, data virtualisation product or software robotics. The brokering stage in the UOP is based on Apache Kafka, but it could be replaced with RabbitMQ or commercial broker or ESB products. An essential feature of the UOP concept is that the data catalogues and data processing functions are connected with the broker and router stage and not on the data lake. With this approach, data is processed while in motion. This approach supports real-time analytics and visualisation and situational awareness, but also the distributed nature of the platform since there can be several databases, data marts and lakes instead of one central data warehouse according to the needs of each business case.

This modular approach also allows cities to choose vendors and products that they already operate with. The role of open source is also a question that requires feasibility analysis. If the city is already operating on Microsoft Azure or Red Hat OpenStack, the added value of introducing new products developed as part of an innovation project can be questionable and the maturity of such products can even cause additional risks.

Due to the spatial nature of public sector data and the digital twins, the primary API for the UOP will be the OGC API Features.

3. Case Study of Tallinn and Helsinki

This paper applies a qualitative case study method where data is collected from primary sources (research and innovation project deliverables, conducted by authors themselves) and secondary sources (previous research and innovation deliverables, such as research papers and project reports). A core method is to validate the proposed UOP concept empirically with real-life and real-time sensing use cases implemented in the city of Helsinki, with the potential to be replicated in Tallinn and other cities globally.

Tallinn and Helsinki (two northern Europe capitals) were selected for the following reasons: proximity (the two cities are just 80 km apart by sea), high-level commuting frequency (there were 8 million passengers between Tallinn and Helsinki pre-COVID-19, whereas Estonia’s entire population is just 1.3 million) and digitalisation. (Finland has a very strong digital industry, strongly rooting from Nokia. Estonia, on the other hand, is highly appreciated because of its electronic government.) Economically, the cities are not the “in the same league”. Estonia is a post-Soviet country still trying to catch up whereas Finland is a well-developed western country, making the cities more heterogeneous with a bigger potential for a scale-up.

3.1. Data Exchange Platform for the Cross-Border Region

Local governments are more and more expected to be participatory, horizontal and collaborative with the help of digital technologies. For example, Lee & Lee [23] criticise the provider’s viewpoint in provision of urban services where organisation structures are constructed for the convenience of administration, instead of citizen, thus making the service provision vertical (e.g., departments of mobility and environment and their databases are fully disconnected). Therefore, Tallinn and Helsinki (and Estonia and Finland, respectively) provide an interesting case, as their public sector databases are interconnected (in the case of Estonia) or there are plans to connect them (in the case of Finland), which makes inter and intracity data exchange possible. It should be noted that achieving this assumes a change in organisations’ management practices and legal set-ups. While practically complex, especially when considering social and political resistance to change, it is not impossible.

Though initiated top-down, Estonia as a country is an interesting example of the horizontal exchange of data, as there is close to full interoperability between public sector databases via the data-exchange layer X-Road, both within departments in one city and across all national cities. For example, the national population registry (which stems from the population registry of Tallinn) is fully integrated with all cities and other government actors in Estonia. Therefore, cities cannot keep their own population registries, as there is one live database for all residents in Estonia, and every municipality must integrate their services based on this central registry (e.g., registration of new or departing residents). It is important to note that X-Road is not extraordinary because of its technological features (there are plenty of similar-logic enterprise service bus platforms available) but mainly because it is a case of successful implementation, both organisationally and legally. Essentially, it is a rule-based approach, and all these rules need to be defined (e.g., who can make inquiries to the population and the other thousand databases and how). In this perspective, X-Road is used as a lighthouse solution throughout the article, indicating how the twin cities (Helsinki and Tallinn) could conceptually benefit from it [2,24]). The X-Road platform is shown in Figure 3. Briefly, in Estonia, over 3000 government sector (including all cities) databases are interlinked via the Internet using the transport layer.

Inspired by X-Road (http://epl.delfi.ee/news/eesti/soome-votab-kasutusele-meie-x-tee-susteemi?id=67359844, accessed on 9 November 2021 (in Estonian)), Finland is also implementing its data exchange layer, with both countries agreeing to develop a federated solution. In 2017, this resulted in the formation of a joint organisation, The Nordic Institute for Interoperability Solutions, which has the mission to develop federated e-governance solutions connecting Estonian X-Road technology with its Finnish counterpart (Palveluväylä). The first pilots based on these federated two-country data exchange layers are live and focus on the exchange of business and population data (see specific use cases: Population Registry and Business registry). In addition, there are also use case of solutions that work only in one city/country, e.g., Smart Meters in Estonia and Environmental Services in Helsinki.

If the federation of data exchange layers between two countries (see Figure 4) was fully implemented, this would offer an experimental setting for a joint cross-border e-service between the two capitals (it also applies to all cities in Estonia and Finland). Currently, the two cities still operate as digital islands but the federation of data exchange platforms could effectively lead to joint digital services based on real-time data requests from urban and governmental databases, hence also benefiting the commuters and macro-regions. Continuing with the example of population registry, a person moving from Tallinn to Finland could automatically mean erasing residence status in Tallinn and transferring it to Helsinki. Again, the implementation of federated data exchange layers is not only a technological challenge, but the main assumption is that this is politically desirable (multiple parties agree on how data can be exchanged and are motivated to do so, that is, create novel institutions).

The next step for smart cities could be the integration of various sensor data by implementing an open and interoperable platform for connected sensors or a range of entities. That is, in addition to “citizen-based” databases, there could be interconnected registries, both public and private, for entities such as unity meters (gas, electricity, water), vehicles (cars, buses, trains, etc.), home appliances, heating, lighting and waste management systems, weather forecast data, etc. In Estonia, there is a first step towards this, namely the Estfeed platform, which connects close to 600,000 electricity users, with most end-users able to trace their energy consumption via connected meters over the Internet [25]. This platform, running on X-Road, links data sources and applications and provides a user interface for customers to see and manage their energy consumption data and rights. For perfectly federated smart cities, such a federation could be the next step, after having integrated the public registries.

3.2. AI Solutions for the Cross-Border Region

Conceptually, federated data platforms could automate processes radically with the application of artificial intelligence. The term “Kratt” (magical creature in old Estonian mythology, a treasure bearer) was introduced in Estonia in reference to practical applications based on artificial intelligence technologies (in the narrow meaning of artificial intelligence) performing a specific function. For the vison of Kratt to become reality, several technological challenges need to be resolved as mentioned in Kratt’s vision paper (https://www.kratid.ee/visionpaper, accessed on 9 November 2021). In the context of this paper, most relevant are issues with interoperability. At this stage, it is not even clear what will be the necessary interoperability framework. Secure data exchange protocol and governance will be necessary to join the AI applications and virtual assistants’ function together and transparently between government agencies, between private and public sectors and also across borders. There are also legacy issues as the development has to be built taking into account the existing Estonian governmental interoperability framework and X-Road data exchange foundations.

Another aspect that needs to be developed is a so-called digital twin of people. It is important to note that this twin would not duplicate all of people’s data but rather would hold data on consents, interactions and other preferences for public services that people have made as the basis for machine-to-machine interaction and queries. The future of digital government that is interoperable will be subject to constant change as bots or agents will be added and iterated. So, the underlying datasets and IT systems have to be flexible and ready for constant further development. That vision in mind, it would make sense to start with a microservice-based set-up of IT systems to ensure flexibility of development and fast-scaling capability. Even more important is the development of a data exchange based on a messaging room set-up, which could become an addition to the Estonian current X-Road based data exchange. At this stage it is unclear whether X-Road’s synchronous connections are sufficient to support parallel working of many AI applications at once.

Estonia has made an excellent effort to make different datasets openly available to encourage the development of commercial or non-profit digital solutions, conduct research or make data-driven decisions. As of 1 April 2021, there were 793 datasets available on the Estonian open data portal (https://avaandmed.eesti.ee/, accessed on 9 November 2021). For the successful development of Kratt AI, the availability and quality of open data will play a significant role. It is unclear how much data is required to train the machine learning algorithm, but depending on the complexity of the problem, it is realistic that thousands of data points may be needed. In the case of machine learning, it is a prerequisite that the training data is not biased towards certain decisions, is of high quality and complete and is marked accordingly. With the UOP, value in the context of the data will be improved. No data is perfect but if it comes with instructions about usability, it can still add value.

In Finland, the concept Aurora has many common denominators with Kratt’s initiative in Estonia. There exists an interest to collaborate between these two developments—at least exchanging ideas and experiences, but also, if possible, developing joint technical solutions. That would create the potential for interoperability between Estonian and Finnish national AI based e-services. Thus, the virtual assistants would operate across borders and help to create Estonian and Finnish common digital space. Estonia–Finland united digital space is already one of Estonia’s digital policy priorities and would continue in this way even in times of AI, especially in the context that Finland and Estonia’s data exchange layers were connected to one another in February 2018. Additionally, in 2019, the national business registers and tax boards in Estonia and Finland were moving towards cooperation that would allow the agencies to exchange data in a more accurate and efficient way by using X-Road Trust Federation. In European energy cooperation, digital solutions are being developed to build smart grids and to enable the effective use of renewable energy. New cross-border services are being developed in both the public and private sectors (https://sites.utu.fi/bre/estonia-and-finland-digital-forerunners-in-cross-border-cooperation/, accessed on 9 November 2021).

3.3. Helsinki Real-Life UOP Use Cases in the Beta Stage

The working concept of the UOP is demonstrated via real-life use cases that have been selected to support the current interests of the cities. The beta stage use cases have been developed based on real data from the Helsinki city operations and have been selected based on the availability of data from various sensors. It should be noted that not all the data is open. In the next stage, data sources from Tallinn are planned to be defined and utilised as feasible. In the beta stage, no dashboards, applications and services have been created to utilise the data.

The conducted cases help to validate the UOP working concept and also help the first pilot city to have more structured access to different sensor data in the varied fields of governance, energy, mobility and built environment.

4. Discussion and Conclusions

This paper introduced a vision of the Urban Open Platform that goes beyond typical IoT platforms with a dashboard. The UOP as a concept also involves a governance aspect of data platforms, as cities as institutions are very complex where “one-size-fits-all” solutions do not automatically apply. In addition, we also bring to the discussion the free roaming of data between key stakeholders of a city that can be other cities, companies, universities, government agencies, etc. Conceptually, an UOP can exchange data across different stakeholders, similar to how X-Road data exchange layer works in the case of Estonia. However, free urban data roaming in not a simple task but a true wicked problem where operational, technical, legal and also ethical challenges need to be solved. In addition, cities without strong data governance policies tend to be also locked into specific contracts and vendors. More often than not, cities have access barriers to the data owned by different city departments themselves. For example, public transport usage or city street construction data is often not accessible to city civil servants in real time, even within one city. Therefore, we need to start with small steps to make data roaming possible.

In the case of the UOP, we analysed the data-roaming potential between two nearby but heterogeneous European cities, Helsinki and Tallinn. First, we mapped services that are currently available between the two cities due to the similarities of data exchange layers and the potential to federate them. For example, population registries and business registries can exchange data in real time and there is a valid consent procedure for this via federated X-Roads. However, in order to test the concept with real-life sensor data based on the interests and use cases of the city of Helsinki in the beta stage. Therefore, the UOP as a concept was validated via integration of 10 use cases that pull real-time data from various sensors in the city environment. This, simply put, showcases that the different institutional barriers can be overcome for better data roaming in the case of IoT.

Smart city is often linked to the Internet of Things and sensors [26,27], whereas platforms have been developed that enable to connect different thematical databases [28], although these concepts often do not communicate and sync with each other. In this perspective, several authors [26,27] aim to develop joint protocols and architecture for linking various sensors to the Internet. This provides the ability to remotely manage devices based on real-time data coming from sensors [27] that have become contributors of large amounts of data [29,30]. Very often, cities are claimed to be smart cities when they open up more data, including data from wireless sensor networks [30]. Nevertheless, the city innovators should not only focus on ICT data or infrastructure but on how to create value for citizens. Conceptually, the combination of powerful and small microprocessors, smart mobile devices, low-cost sensing, data analytics, cloud technologies and advanced connectivity sets a conceptual framework for automatically connecting entities [31].

Furthermore, a very important lesson learnt is that a successful smart city implementation is a less specific software product or vendor specific but addresses actual urban challenges. Therefore, various software solutions for IoT in smart cities, such as Kafta or FME ET applied in our use cases, should be taken as a potential toolbox that is open for other solutions. In general, we have seen from previous research that closed IoT platforms tend not to mainstream, probably due to technological and operational lock-ins. Therefore, more focus should be put on distributed concepts, such as X-Road and data mesh.

For future empirical research, more focus could be put on how cross-border cities can offer joint services via an UOP. The cities of Tallinn and Helsinki are very different economically and, therefore, a joint platform for smart city services can effectively serve as a knowledge transfer mechanism from a more advanced region (Helsinki) to a developing region (Tallinn). A strong common element of both cities is their strong digital infrastructure and potential for interoperability of services.

The key point to understand a winning smart city is to understand that this is not a one-city nor one-country game [8]. No matter how big a city (Tokyo, Sao Paulo, etc.) is, any local government is too small to create a real ecosystem of cutting-edge agile and adaptive governance solutions (predictive analytics, Internet of Things and big data technologies). The first deployments have led to inflexible “smart cities in a box” or “smart countries in a box” which are ageing fast, and from which solutions do not scale elsewhere. There is a need to start from simple and widespread urban services through a collaborative joint cross-border, hands-on effort. Standardisation is also the key to cross-border urban services. The real threat is that if local municipalities do not manage to innovate from the bottom up jointly with neighbouring cities (both national and international), then all cross-border solution will be enforced top-down or aggressively linked to global business vendors.