# Urban Open Platform for Borderless Smart Cities
## 2 Urban Open Platform: Vision and Architecture
### UDP 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  
Figure 2: Component diagram for use case building automation systems.  
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.