Keywords

1 Introduction

Lifecycle Management is a concept [1] that evolved in 1990 s to improve several engineering aspects of an enterprise to manage its products across their lifecycles [2]. As per Li et al. [3], Product Lifecycle Management (PLM) is ideally used to manage the knowledge intensive process consisting mainly of market analysis, product design and process development, product manufacturing, distribution, product in use, post-sale service, and recycling. Despite what its name implies, PLM is not only about manufactured products; Stark [4] extends the definition of “product” to include services, package of services or a bundle of products and services. Isaksson et al. [5] also see “service” as part of the wider concept of “product”.

The transformation from product-oriented to more service-oriented economies is part of a complete “servitization” revolution, with more than 70% of global workers engaged in service tasks [6]. Therefore, traditional product-centric sectors evolve into service-centric sectors in order to meet the new challenges, with the aim to put customers and users at the center of their business models [7]. Through servitization, companies seek unique selling proposition for their products, in which the physical artifact is extended by a surrounding provision of services, thus defining the concept of Product–Service System (PSS) [8].

The advancement of ICT and the evolvement of Internet of Things (IoT) and Cyber Physical Systems (CPS) have made ordinary products smarter. Kiritsis [10] argues that smart products allow monitoring new parameters of the product and its environment along different phases of lifecycle. Similarly, IoT and CPS have an enabling role in public services in the city environment, and can exist in many forms [12]. The simplest form of CPS is the form of single objects, like sensors and actuators that collect data and execute commands respectively. CPS can also be in the form of smart systems that address domain-specific issues, like transportation, parking, energy, lightening, etc.

As it was proposed in previous research in [12,13,14], and in line with ambitions of many cities and states around the world, there is a need for a more holistic vision of smart city as a complete ecosystem. This paper carries on the proposed lifecycle approach to ensure systematic involvement and seamless flow of information between different stakeholders of the smart city ecosystem. Nevertheless, this holistic vision of smart city implies interrelations and interdependence between multiple smart systems that in many cases are independently developed, operated and managed [15]. Hence this paper proposes a step further to extend lifecycle functionalities to smart cities, in order to exchange not only generated data but also system data, versions, variants and business processes. This research aims to understand some lifecycle aspects in the smart city context, considering some features like heterogeneity of data sources, interdependence between smart systems and integration between cyber and physical components.

The remainder of this paper consists of four sections. Section 2 presents the different types of lifecycle management in the manufacturing and servitization context. Section 3 projects lifecycle management aspects on smart city systems and explains the proposed meaning of different lifecycle components and functionalities in the smart city context. Section 4 demonstrates the lifecycle approach in a smart parking use-case. Section 5 includes discussion and future work.

2 Lifecycle Management in Manufacturing and Servitization Context

The term lifecycle management has been mostly associated with “Product”, in Product Lifecycle Management (PLM) and “Service”, in Service Lifecycle Management (SLM). However, bi-directional coordination and interaction between PLM and SLM is needed for Product-Service Systems (PSS) [28], in which a manufacturing company sets its market proposition on extending the traditional functionality of its products by incorporating additional services for reaching new market competitive advantages [6]. As per the definitions listed in Table 1, “service” can be seen as a sub-set of “product”; and PSS can be seen as extended “Product”, where the product is a complex result of tangible and intangible components. Yet, due to the evolutionary process towards servitization, SLM and PLM-SLM are particularly required to address the special features of service systems and product service systems respectively.

Table 1. Scope of lifecycle management based on definitions of product, service and PSS.
Full size table

PLM is commonly referred to as a strategic approach that incorporates the management of data associated with products of a particular type, and perhaps the versions and variants of that product type, as well as the business processes that surround it [11]. As illustrated in Fig. 1, PLM has three main phases [2]: Beginning of Life (BOL), Middle of Life (MOL), and End of Life (EOL) [3].

Fig. 1.
figure 1

Phases of PLM [28].

Full size image

SLM is conceptually similar to PLM, however it manages the lifecycle of services instead of tangible products. SLM is part of Service Science, Management and Engineering (SSME); it creates a connection between Management and Engineering [28]. As illustrated in Fig. 2, SLM can be characterized by the same three main phases, like PLM: BOL, MOL, and EOL [16, 17].

Fig. 2.
figure 2

Phases of SLM [28].

Full size image

PSS.

As part of the servitization trend, manufacturing companies extend their traditional products by incorporating additional services. This approach supports the development of service-oriented sectors, switching the emphasis from the “sale of products” to the “sale of use” and resha** the same concept of customer values, from “possession” to “utilization” [6, 26]. Ownership stays with manufacturers who provide and guarantee functions/solutions instead of products; hence, efficient use, maintenance and repair, in MOL, are becoming prevailing in the value chain [5]. Figure 3, illustrates the different phases of PSS Lifecycle.

Fig. 3.
figure 3

PSS lifecycle model [28].

Full size image

3 Lifecycle Management in the Smart City Context

3.1 Smart City Context

Smart city is a composition of smart objects, smart systems, and smart services that focus on problems and issues that arise in service sectors, like transport, logistics, energy, waste management [18, 19]. Yet, smart city as a complete ecosystem goes beyond conventional product systems, service systems or PSS [20, 21]. Smart city service systems are particularly featured with being technology-intensive, information-driven, productivity-focused, customer-centric, innovative, modular, service-based, inter-disciplinary, heterogeneity, etc [22]. Moreover, smart city is a System of Systems (SoS), where individual, heterogeneous, functional service systems are linked together and organized in a hierarchy of subsystems to realize new features/functionalities [15, 17, 27]. For example, [20] propose a smart waste collection system that enable dynamic scheduling and routing of waste trucks. The proposed system features data exchange between waste management, surveillance/monitoring and transportation/routing smart systems. Another example, from [19], a CCTV camera video stream to feed to a video processing algorithm that extracts information such as numbers of cars/people/objects in a given street. Authors propose a middleware layer for selection and discovery of the appropriate data sources.

Like other engineering systems, smart city service systems share similar lifecycle concerns [3], like deployability, disposability, engineerability, maintainability, operatability, procureability, producibility, etc. Yet, the SoS feature of smart city brings some more concerns. One of the concerns, the loose coupling of information sources from real-time intelligence functions (i.e. the collected data for certain smart service can be used by other smart city services); hence, sensors collecting particular data might be part of another service system other than the smart service of concern. In such a case, dependence between connected smart city service systems and traceability and trustworthiness of data across these systems should be addressed.

3.2 Smart City Lifecycle Management (SCLM)

Lifecycle Management is proposed to be used in the smart city context to manage data, versions, variants and business processes associated with heterogeneous, uniquely identified connected objects. Nonetheless, extending lifecycle management concepts to smart cities requires special type of lifecycle management, where many of the aspects are defined/redefined to consider the particular features that differentiate the smart city context from manufacturing and servitization context. Table 2 summarizes some of the relevant aspects of SCLM.

Table 2. Different aspects of Smart City Lifecycle Management (SCLM).
Full size table

4 Smart Parking: Use-Case

To better understand some of the abovementioned SCLM aspects, this section carries on the use-case, presented in [13], for smart parking system. The proposed scenario was examined in collaboration with the on-going H2020 project named “bIoTope”Footnote 1 to use the O-MI/O-DF standards to exchange data between different nodes in the proposed smart parking system. Meanwhile, Aras Innovator® was used to examine some lifecycle management functionalities in the proposed case. This paper focuses only on the lifecycle aspect of the smart parking system.

As detailed in [13], the proposed smart parking system allocates parking spaces to users, based on the preferred entrance and eligibility to use allocated spots for people with disability. In this paper, we propose to use smart parking systems in FIFA World Cup 2022 stadia in Qatar. The main functions of the proposed system include: booking of parking spaces in-advance through online booking; parking space allocation as close as possible to entrance leading to the booked seat; fast track car entrance through gates that are equipped with plate number reader and only open to eligible cars; another plate number reading at each parking space to alert user in case of parking in a wrong space (not the allocated parking space). Figure 4 presents the high-level illustration of the proposed smart parking system.

Fig. 4.
figure 4

Smart parking: high-level illustration.

Full size image

BOM.

To develop the BOM, during the BoL, we detailed a hierarchical structure of the components that make up the smart parking system. The smart parking system was structured in zones (1…n); each zone has one gate equipped with plate number reader; and certain number of parking spaces (1…j), each has its plate number reader. Figure 5 shows a snapshot from BOM. Aras Innovator® was used for two purposes, first is to build and manage BOM; second is to export BOM in O-DF structure as XML file to build O-DF object tree. Figure 5 is a screenshot from Aras Innovator®, showing the user interface for smart parking system; and Fig. 6 shows the implementation of the O-DF structure into the smart parking O-MI node which relies on the first reference implementation of O-MI/O-DF standards.

Fig. 5.
figure 5

BOM: screenshot from aras innovator®.

Full size image
Fig. 6.
figure 6

O-DF object tree.

Full size image

Versions, Variants and Options.

During MoL, the BoM may be updated using the same methodology, presented in Figs. 5 and 6, as new versions, variants and options evolve. Normally, new versions, variants and options evolve to add new functionalities or to address certain problems. For this purpose, we denoted the smart parking system, as explained above, as version (V 1.0). We proposed a new scenario of users parking in parking spaces different than their allocated ones, disregarding the red light alert. For this, Problem Reports (PRs) were developed by parking zone administrators in three different stadia reporting the same problem. PRs were reviewed and verified by chief of staff in stadia. The manager of smart parking has approved PRs, as per the PR process shown in Fig. 7.

Fig. 7.
figure 7

PR process.

Full size image

As a response to the above mentioned PRs, an Engineering Change Request (ECR) was developed to overcome the mentioned problem, as per the ECR process shown in Fig. 8. The proposed solution was to add surveillance cameras to monitor violent parking cars in order to file cases against these cars. One stadium has rejected the ECR and decided to keep (V 1.0) smart parking system while dealing with the PR by increasing the number of security personnel who can immediately intervene and request violent cars to use their allocated parking spaces. The second stadium has approved the ECR through a fast track approval. Hence, the smart parking system evolved to version (V 2.0); accordingly, the BOM should be updated by adding 1 camera to each parking zone. The third stadium has approved the ECR and requested to add an option to connect the smart parking system with the traffic department system so that the applicable fine will go directly to the traffic department upon capturing the violent car. Hence, a new variant will evolve (V 2.1). Due to the relationship with other systems, the ECR in the last scenario should go through the Change Request Board (CRB) approval route that involve all relevant stakeholders.

Fig. 8.
figure 8

ECR workflow process.

Full size image

The Enterprise Change Notice (ECN) is a process by which changes are implemented within the smart parking system, as shown in Fig. 9. The change, in case of (V 2.0) and the variant (V 2.1), is the addition of cameras, as new parts to all parking zones. The ECN process is used to take the new parts from preliminary lifecycle state to a released lifecycle state. The relevant PRs and ECR can be attached to the ECN for tracking and reporting.

Fig. 9.
figure 9

ECN workflow process.

Full size image

Aras Innovator® was used to build the BoM at the BoL; manage PRs, ECR and ECN processes and accordingly update the BOM, during MoL. Hence, Aras Innovator® can be used as a master tool to manage all lifecycle aspects, across different phases, including BOM development and changes in case of new versions and/or variants.

5 Discussion and Future Work

As lifecycle management has enabled large enterprises to better manage their products, services and product-service bundles; similarly, lifecycle management can enable city operators to better manage public services and supporting infrastructure. The wide spread of IoT technologies and CPS systems in the city environment closes lifecycle data/information loops across different phases and between heterogeneous objects/systems. From engineering perspective, smart city as a service system has some features like heterogeneity and loose-coupling of data sources; complexity of systems and composability of parts; customer oriented and service based systems. For these particular features, this paper proposed Smart City Lifecycle Management (SCLM) to be used in the smart city context, instead of the general PLM and SLM.

This paper has described some aspects of SCLM, namely Phases; Bill of Materials (BOM); Object/Service/System data; Ownership and Rights; Policies and Regulations; Versions, Variants and Options; and, Processes. For better understanding, some SCLM aspects were demonstrated through a smart parking use-case.

The vision of applying lifecycle management in the smart city domain(s) is to better integrate people, processes, and systems; and assure information consistency, traceability, and long-term archiving. To achieve such a holistic vision of complete smart city ecosystem, there is a need for two types of data to be exchanged. First, data collected from heterogeneous data sources that can be used in different domains. Second, system data that include BOM, versions, variants, stats and other lifecycle related data. Future work will include expanding the use-case to ensure exchange of the two types of data between different systems in the smart city. Another required effort is to build general smart city BOM that includes as much as possible categories and parts that compose a smart city.