Smart City Solution Engineering

Abstract

Many smart city applications have been proposed and demonstrated over the years; however, moving to large-scale deployment is still scarce. A contributing factor to this scarcity is the lack of well-established engineering methodologies for large-scale smart city applications. This paper addresses engineering methodologies and tools for large-scale smart city application engineering, implementation, deployment, and evolution. A model-based engineering approach based on IoT, SOA, and SysML is proposed and applied to a smart streetlight application. Engineering considerations for streetlight area enlargement and updated technology generations with additional capabilities are discussed. The proposed model-based engineering approach provides considerable scaling simplifications and opportunities for considerable savings on engineering costs. The model-based engineering approach also provides good documentation that enables technology evolution specifications that support both maintenance and emerging behaviours.

1. Introduction

Smart cities have been discussed for quite some time in the scientific community, industries, and societal groups, and a number of reviews on the topic are available. There are properties related to smart cities that distinguish them from other domains, such as Industry 4.0 production, smart energy grids, and smart houses. Such distinguishing properties are as follows:

• Very large number of devices and users >10⁵;
• Very large number of independent functionalities with emerging behaviours and interactions;
• Extremely heterogeneous technologies; and
• Extremely distributed environments >10 km².

Moving the smart city ideas and experiments into real-world realisation, while enabling the above properties, is a current challenge. The further enabling of widespread smart city functionalities and their integration will require economically and commercially sound implementations. This will put new demands on the engineering, deployment, operation, maintenance, and evolution of smart cities.

Such demands can be transferred into a number of more detailed requirements that need to be addressed. Such requirements are, e.g., as follows:

• Architecture for smart cities;
• Engineering of smart city solutions;
• Operation of smart city solutions;
• Maintenance of smart city solutions;
• Evolution of smart city solutions;
• Training related to smart city engineering, operations, maintenance, and evolution;
• Smart city security; and
• Smart city safety.

Clearly, the details of these requirements will be viewed differently depending on the “smart” city functionality. The enabling of integration between functionalities and their evolution will call for architectures allowing for run-time engineering, management, maintenance, and evolution. It is clear that smart city functionalities have to be addressed using some type of system of systems (SoS) thought and architecture. Fundamental properties of SoS can be found in [1,2].

Current technology trends point towards the usage of service-oriented architecture (SOA) and microservices, as a well-accepted approach. An interesting example of a detailed implementation architecture based on microservices is [3]. The engineering of SoS SOA solutions has been discussed since early 2000. SOA is, to a large extent, the dominant approach for creating automation and digitalization solutions in industrial production, smart grids, smart environments, etc. We currently find a smaller number of edge solution frameworks/platforms; a recent review of such industrial frameworks/platforms is [4]. However, in what way can these types of platforms be used for smart city engineering? The engineering of SOA/microservice-based solutions has some history in the area of business computing (e.g., banking) and cloud-based computing [5]. Moving SOA and microservice solutions to the edge has been a focus area of multiple European projects over the last decade. Important publications demonstrating this development are, e.g., Colombo et al. [6,7] and Delsing [8,9]. For the engineering of SOA-based solutions, Urgese et al. [10] recently published an approach for modelling and integrating a solution engineering process using an SOA approach. This approach allows for modelling and integrating various solutions at different stages of engineering, operations, and evolution.

This approach to smart city functionality and integration engineering is model-based. Service-oriented modelling has been addressed since early 2000. A prominent example is [11].

The smart city engineering approach applied herein is based on an SOA/microservice architecture. Thus, we need to consider an SoS SOA architecture. For the modelling thereof, SysML is used. As an SoS SOA architecture backbone, the Eclipse Arrowhead reference architecture and implementation platforms have been used [12].

The intention is to show how model-based engineering can serve in design and engineering of complex smart city solutions where advanced and dynamic boundary operational conditions are at hand. Thus, the focus of this paper is on how simple functionalities can be engineered to integrate into more complex functionalities in a smart city context.

In summary, this paper focusses on smart city engineering, both in design and run-time.

2. Related Work

The knowledge field of smart cities is very broad. Given the geographical size of smart cities, it is obvious that updates and extensions (e.g., geographically) of single functional solutions and installation of new functionalities have to occur in parallel to the operation of existing functionality solutions. Integration between existing, upgraded, extended, and new functionalities is one area that has a large dependence on interoperability, integrability, and composability of the involved functionalities. Thus, the engineering of smart cities has to consider not only design time engineering, but also maintenance of the smart city, its evolution, and emerging behaviours.

Current literature on smart city engineering is limited. One reason for this is the very early adoption phase of smart city solutions. Another reason for this can be found in the knowledge gap between the current city engineers and the smart city community [13].

Using engineering approaches from other domains, such as production and smart grids, is appealing. The current engineering process standards, such as ISO 81346, ISO 15288 [14,15], and others, do not consider smart city properties as indicated above. Thus, this paper can make a contribution to this open field of knowledge.

The SoS literature holds some interesting work related to SoS SOA engineering. Most of the engineering-related publications address SoS SOA engineering at higher levels in enterprises, prominent examples are [16,17]. Very few SoS SOA engineering papers related to production have been found, e.g., [18].

For each of the related requirement areas, some primary references are indicated below:

• Architecture for capturing, e.g., design, engineering, operation, and evolution. RAMI4.0 and IIRA [19,20] are such architectures for Industry 4.0 and, e.g., IEEE 1547 and IEEE2030 [21], which address the smart energy grid domain. There are a number of proposals for smart city high level architectures, see, e.g., [22,23], which seem to be quite simple compared to existing industrial and smart grid architectures.
• Operation of smart city solutions. Many experiments with single functionalities have been pursued. Experiments with multiple functionalities seem to be limited.
• Maintenance of smart city solutions. In this regard, substantial work on maintenance based on SOA and microservices addressing the production domain exists, see, e.g., [24,25,26]. The maintenance of microservice-based systems is reported by Tizzel et al. [27].
• Training related to smart city engineering, operations, maintenance, and evolution. This is an open field, primarily because of the immaturity of the market for smart city solutions.
• Security of smart city solutions. A comprehensive review can be found in [28].

Since the literature on engineering of smart city functionalities is limited, this paper is intended to provide a valuable contribution to the field.

3. SoS Engineering

Here, the engineering of IoTs and their interaction to form a System of Systems, SoS, in a complex smart city context is addressed. For this purpose, a smart streetlight use case is considered. Thus, the engineering of a complex SoS based on smart streetlight IoTs is elaborated in this paper.

The SoS engineering approach applied is model-based systems engineering (MBSE) [29]. To enable a structured approach to SoS engineering, a feasible engineering process is needed. The one adopted herein comes from Urgese et al. [10], and is depicted in Figure 1. This engineering process can be described using an SOA perspective. The use case architecture is based on SOA/microservices; thus, it follows the major architecture trends in the area. Further discussion of a smart city engineering process makes use of an SOA framework and implementation platform. The engineering process is based on some very recent developments in SOA modelling with SysML [30]. Thus, further description and discussion of the engineering process makes use of Eclipse Arrowhead framework and implementation platform [8,12]. This is facilitated by the available SysML profile and library for Eclipse Arrowhead (http://www.github.com/eclispe-arrowhead/SysML-profile-library (accessed on 29 April 2021)).

3.1. Smart City Application-Requirements and Evolution

The proposed engineering approach is discussed for a smart streetlight application. Here, each streetlight has a sensor that can detect the presence of a non-stationary object within the illumination area of the streetlight. The “smartness” is that streetlights should only be ON if there is a non-stationary object within its illumination area. It is assumed that there is a small overlap between the illumination areas of each streetlight. The handover of illumination should be made between streetlights when objects are moving from one illumination area to another.

To include the evolution aspect of the application, three generations of the streetlights’ sensors will be considered:

• Gen.1   IR sensor;
• Gen.2   Camera;
• Gen.3   3D camera.

Given these streetlight generations, the following scenario regarding design, installation, updates, extension, and segment integration is considered from an engineering perspective:

• Smart streetlights generation 1 deployed in multiple city sections. The primary objective is that streetlights should be ON when a person or moving object (e.g., bicycle, car, wheelchair) enters the streetlight illumination area.
• Smart streetlights generation 2 deployed in multiple city sections. In this case, both presence and object location within the illumination area can be detected. The primary objective is still that streetlights should be ON when a person or moving object (e.g., bicycle, car, wheelchair) enters the streetlight illumination area. The secondary objective is that the next street along the position trajectory of the object can be lit up before the object enters that streetlight illumination area.
• Smart streetlights generation 3 deployed in multiple city sections. In this case, in addition to presence and object location, velocity (speed and direction) within the illumination area can be detected. The primary objective is still that streetlights should be ON when a person or moving object (e.g., bicycle, car, wheelchair) enters the streetlight illumination area. The secondary objective is that the next street along the position trajectory of the object can be lit up before the object enters that streetlight illumination area. The third objective is improved and smoother illumination handover between light poles, resulting in improved illumination experience and reduced energy consumption.
• Integration between city sections using all smart streetlight generations. Here, we create a handover between city sections, allowing for seamless movement between city sections having different technology generations.
• Streetlight sections with cameras also provide the emergent capability of tracing the movements of identifiable individuals, which might be of interest as forensic information. This adds engineering requirements on, e.g., data security, storage, and lifetime.

The emerging installation plan for the smart streetlight areas is schematically depicted in Figure 2.

3.2. Engineering Approach

The engineering approach proposed herein is based on a two-dimensional perspective. The two dimensions considered are as follows:

• Architecture;
• Engineering process.

The engineering process dimension was briefly introduced above and depicted in Figure 1.

The architecture is based on the Eclipse Arrowhead. Fundamental parts of the architecture are depicted in Figure 3.

Core parts of the architecture are as follows:

• Software system: a software-based microsystem capable of producing and/or consuming microservices and executing its own functionality.
• Local cloud: a set of microsystems in a private network capable of jointly executing a set of functionalities. The local cloud always includes mandatory core microsystems to establish necessary SOA infrastructure. This is a local-scale SoS.
• System of local clouds: a set of local clouds capable of jointly executing a set of functionalities. This is a large-scale SoS enabling the architecture and its engineering to address the expected very large scale of smart cities.
• Device: a hardware hosting one or several software systems.
• Network: a network enabling private clouds with DMZ (De-Militarised Zone) and open internet with communication between the involved software systems and local clouds.

The engineering process, on one hand, and the architecture based on Eclipse Arrowhead, on the other hand, have been used to form a two-dimensional matrix approach to the engineering of complex SoS SOA-based smart city solutions; see Figure 4. The matrix has been captured in a SysML profile [31]. In addition, most of the Eclipse Arrowhead core SOA systems have been modelled and made available as a library, along with a number of templates for often-used constructs. The SysML profile, library, and templates are available at www.github.com/eclipse-arrowhead/profile-library-SysML (accessed on 29 April 2021).

The Eclipse Arrowhead SysML library provides all currently released core systems of Eclipse Arrowhead plus a number of the release candidate systems (expected release is Q3 2021). In this most fundamentals of SOA/micro-service architectures are supported including;

• Security:Authentication, authorisation, and accounting are supported down to individual service exchanges. Payload protection is provided based on chosen protocol, but for most modern protocols, TLS is used. Secure on-boarding for both hardware and software is supported. Monitoring of security standard compliance and some security issues is also supported by the Eclispe Arrowhead framework and the modelling thereof.
• Interoperability: Autonomous protocol translation, support for data model translation based on ontologies. Adaptors for multiple legacy protocols like, e.g., OPC-UA, Z-wave, Modbus-TCP are provided both as code and models by the Eclipse Arrowhead framework.

An extensive discussion of the SysML modelling of SOA/micro-service and SoS where Eclipse Arrowhead has been used as the validation implementation framework will be provided in a forthcoming paper [30].

Next, each of these dimensions is described in more detail.

3.2.1. Architecture Dimension

Here, we take an SoS architecture perspective and assume a solution approach based on service-oriented architecture and microsystem and microservices. In this context, a microservice is produced by a microsystem, which performs its functionality independently and can be stateful or stateless. The perspective is based on the Eclipse Arrowhead framework and makes use of network, devices, and microsystem with microservices, which are aggregated to independent local clouds which can be further integrated to a system of local clouds. The architecture is divided into these five levels, shown in

Table 1. The architectural view of the engineering approach. Here, the use case level and scale are indicated in green boxes with the corresponding architectural level from the Eclipse Arrowhead as stereotyped in SysML in yellow boxes.

Architecture Level	SOA/Eclipse Arrowhead Concepts	Smart Streetlight Use Case Concepts
Network functionality connecting hardware and its functional systems and services	Private local cloud networks with functionality enabling secure service exchanges to other local clouds	Local cloud routers, switches, cabling, wireless access points and access point to the open Internet
Hardware hosting one or more systems and associated services	Hosting one or more microsystems and associated services plus necessary SOA administrative and support systems	The sensor, controller, and light switch, and the necessary SOA administrative and support systems
Individual system (IoT system) and its produced and consumed services	Individual microsystems and their produced and consumed microservices	Individual streetlight poles and their sensor, controller, and the light source switch
Local-scale SoS composed of a number of microsystems	Local clouds’ private networks composed of a number of microsystems, each private network responsible for a set of functionalities that primarily can be performed in isolation	City section, e.g., a number of city blocks or streets and associated streetlights
Large-scale SoS interaction between the local-scale SoS networks responsible for a set of functionalities	System of local clouds: aggregated interaction between a number of local clouds and their private networks. In this way scalability to very large number and heterogeneous “smart devices and functionalities” is provided [32].	System of city sections, e.g., sets of streetlight city sections, thus enabling the capturing of very large number of “smart devices” and associated functionalities.

.

3.2.2. The Engineering Process

The engineering process is based on ISO 81346 and extended to the Eclipse Arrowhead SoS engineering process [10], depicted above in Figure 1. The process is detailed in

Table 2. The engineering process view of the engineering approach.

Engineering Phase	SOA/Eclipse Arrowhead Phase	Smart Streetlight Use Case Phase
Requirements	Formalised requirements for all architecture levels	Use case requirements for all architecture levels. As a part of the requirements, the SysML use case diagram model is provided in Figure 5
Functional design	Black box functional designs and models for each architecture level. Here, the system level details of one involved microsystem and its microservice are provided in Figure 6	Use case design and models for each architecture level
Functional engineering and procurement	White box design, models, and engineering for each architecture level, procurement of specified HW, SW, and services. Detailed modelling of functional and security policies, tests, and software instalment procedure. In Figure 7, the white box design of a local cloud is provided.	White box design, models, and engineering for each architecture level of the streetlight solution, procurement of streetlight poles and their sensor, controller, light switch and light source, network, etc. Detailed modelling functional and security policies, test, and deployment procedure
Implementation	Implementation, hardware, and code of the respective microsystems and deployment of code to the dedicated hardware	Implementation, hardware, and code of the smart streetlight microsystems and deployment of code to the sensor, controller, and light switch
Deployment	Physical deployment of hardware, software, functionality and security policies, network, etc. Final tests and operational commissioning according to procedures	Physical deployment of smart streetlight hardware, orchestration and security policies, network, etc. Final tests and operational commissioning according to procedures
Maintenance	Maintenance procedures and execution at all levels of the architecture and its implementation	Maintenance procedures and execution at all levels of the smart streetlight architecture and its implementation
Evolution	Functional and technology evolution and its execution at all levels of the architecture and its implementation	Functional and technology evolution and its execution at all levels of the smart streetlight architecture and its implementation

.

3.3. Engineering Details

This section details some of the engineering aspects and demonstrates a reasonably possible engineering flow through the architecture/engineering matrix, as shown in Figure 4.

Functional Design-Black Box

Taking the SysML modelling approach, the requirements are first transferred to a use case diagram. In the case of the smart streetlights, an example is shown in Figure 5.

Functionality modelling needs to start with individual systems and their produced and consumed services. This is exemplified herein by a model of the streetlight controller; see Figure 6.

When all black box designs of all involved microsystems and their produced/consumed microservices have been completed, we can move to the next level, namely, local SoS, which in Arrowhead architecture will be treated as a local cloud [32].

Here, the microsystem interactions-exchanges of microservices is modelled. Integrating the involved IoTs into an SoS based on SOA, we also need a model of the necessary SOA infrastructure to support fundamental SOA properties like lookup, loose coupling, and late binding, plus the important IoT security. An example is shown in Figure 7. This model now constitutes a functional Arrowhead local cloud having support for fundamental SOA properties and security. From our use case perspective, such local cloud can correspond to a city section and its smart street lighting.

The integration of functionality in one city section, namely, the local SoS architecture level, is done using orchestration of service exchanges and creation of associated security policies. Orchestration rules and security policy details can be automatically extracted and deployed from an engineering model, such as the SysML model used herein.

It is clear that multiple local clouds can be designed. Interaction between streetlight sections can be established using the Eclipse Arrowhead Gatekeeper and Gateways core systems [33].

The next step is to provide the white box design of our involved microsystem, its services, and its interaction within the local cloud. This includes definition of used service protocols, e.g., HTTP, CoAP, MQTT. Security policies for each designed service exchange are also defined at this stage. These definitions will enable partly automated code generation for the designed systems, thus supporting the coding of non-existing application systems. The Eclipse Arrowhead core systems used can simply be pulled from GitHub as docker containers.

Next, the created and identified micro-systems should be installed into some hardware. The hardware should in turn be connected to a network. Thus, we need a model of the hardware devices and the network design. Examples of black box, white box, and specific purpose hardware implementations are provided for hardware devices in Figure 8 and for networks in Figure 9. These models are required to provide necessary information for the deployment of the solution in the real world.

Next, the devices and network are integrated into a local cloud model that describes in which light pole individual hardware and its microsystems are installed. An example is depicted in Figure 10.

The final step is deployment. In this step, a number of metadata defining where and how each light pole is connected to power supply, network, etc., are provided.

The proposed engineering flow through the architecture–engineering process matrix is depicted in Figure 11.

4. Discussion

The proposed engineering approach addresses the knowledge gap identified in the related work Section 2. The very limited smart city engineering literature addresses engineering at design time. This paper provides an approach that supports not only design time engineering, but also in-time engineering, maintenance time engineering, and evolution time engineering. The approach can, to a very large extent, be implemented in SysML engineering tools such as MagicDraw [34] or Eclipse Papyrus [35]. We can identify a number of engineering actions in this approach that can be automated. Such automation has the potential to significantly reduce engineering efforts and cost of smart city features.

Above, the engineering approach for the first smart streetlight deployment in a city sector based on Eclipse Arrowhead architecture was described. To indicate engineering efficiency and use case evolution, the use case comprises three generations of deployment in different city sectors, as shown in Figure 2. The new generations of technology only require the additional modelling of generations 2 and 3 of the sensors and controllers. This is easily done by cloning the 1st generation models and adding the new functionality. Then, we can clone the first city sector local cloud and exchange the sensors and controllers to the new generations. In this way, it is possible to duplicate the engineering models for any number of city sections where smart streetlights are desired.

However, what about interactions between adjacent city sectors? Can handovers between city sectors (see Figure 2) be made using the technology approach? Making use of the Eclipse Arrowhead features, integration of functionality between local clouds and, thus, city sections is clearly possible and maintains security level. The required functionality is provided by the GateKeeper and Gateway systems [36], as indicated already at the functional design level, cf. Figure 7. In this way, service information can be exchanged between different city sections, thus enabling handovers from one city section to an adjacent city section, provided that the necessary functionality is supported by the controllers. Above is another example of SoS evolution and emergent behaviour, which is possible to address and engineer with the proposed approach of this paper. Notably, this type of integration across different technology frameworks is still an interoperable and composability challenge.

Integration between clouds with different technology generations can be managed with minimal engineering efforts, if proper requirements on the services data models are stated. This indicates that technology evolution can be handled positively, given the integration of the engineering process and the SOA-based architecture. These details will be the subject of upcoming papers.

The street light use case and its plan for different sections and technology generations provides a basis for showing the benefits and capability of the engineering process and architecture matrix. The use case construct enables us to show that the following parts of the engineering process can be captured:

• Requirements;
• Functional design;
• Engineering and procurement;
• Deployment;
• Maintenance;
• Evolution.

It further contains all the architecture levels of the architecture. Network and device level to a lesser extent but micro-system and associated micro-service, local cloud, and system of local clouds to a large extent.

For the smart streetlight scenario with its sensing capability, it is clear that other usage scenarios can be added to the light controllers and the data they can collect. Such extended functionality includes, e.g., surveillance information (of potential interest in forensic investigations) and capturing of city usage trends (of interest for city planning).

It is clear that integration of various smart city functionalities using interoperable and composable technology will provide numerous opportunities and risks. Thus, having a technology engineering approach that produces documentation of the design, its deployment, maintenance, and evolution is of value when considering both opportunities and risks.

Coming back to the distinguishing properties of smart cities these are supported by the proposed architecture and engineering procedure as follows:

• Very large number of devices and users >10⁵;
  Is enabled by the chosen architecture through the use of the local cloud concept where functional and security scalability is provided to system of local clouds.
• Very large number of independent functionalities with emerging behaviours and interactions;
  Is supported as indicated with the three generations of sensors in the smart street light use case. Since the architecture and the engineering process is independent from the choice of device and functionality technology, the approach can handle technology with a very large number of independent functionalities. Emerging behaviour and interactions are also supported as discussed above.
• Extremely heterogeneous technologies;
  (see 2) above.
• Extremely distributed environments >10 km²;
  (see 1) above. The only part not discussed is the choice of networking infrastructure enabling extremely distributing environments. Since the 4G and 5G telecom network provides such capabilities, this can be addressed by the engineering approach by adding such network interfaces.

In this way, the utilised SoS architecture, Eclipse Arrowhead, addresses the smart city distinguishing properties, while also providing support for smart city detailed requirements areas like:

• Maintenance of smart city solutions;
• Evolution of smart city solutions;
• Smart city security,

as discussed above.

5. Conclusions

An approach for the engineering of complex smart city solutions has been proposed herein. The engineering spans from design-time over run-time to maintenance and evolution time, thus extending most existing engineering processes to cover almost the whole life cycle of solution. This approach provides a structured integration between a basic SoS architecture applied to smart city use cases and a comprehensive SoS engineering approach based on SOA. The engineering approach has been demonstrated using a smart streetlight solution and its extension and evolution over time. The solution has been modelled in SysML, where it has been shown that functional properties can be addressed. It has also been shown that security policies can be captured in the model and extracted for subsequent deployment and operational use.

The evolution of SoSs and their emerging behaviours have been discussed. It has been noted that the model-based approach provides comprehensive documentation of the SoS solutions. Such documentation will become a valuable asset in the analysis of opportunities and risks connected to integration of various smart city functionalities using interoperable and composable technology.