Advertisement

Lifecycle Management in the Smart City Context: Smart Parking Use-Case

Conference paper
Part of the IFIP Advances in Information and Communication Technology book series (IFIPAICT, volume 492)

Abstract

Lifecycle management enables enterprises to manage their products, services and product-service bundles. IoT and CPS have made products and services smarter by closing the loop of data across different phases of lifecycle. Similarly, CPS and IoT empower cities with real-time data streams from heterogeneous objects. Yet, cities are smarter and more powerful when relevant data can be exchanged between different systems across different domains. From engineering perspective, smart city can be seen as a System of Systems composed of interrelated/interdependent smart systems and objects. To better integrate people, processes, and systems in the smart city ecosystem, this paper discusses the use of Lifecycle Management in the smart city context. Considering the differences between ordinary and smart service systems, this paper seeks better understanding of lifecycle aspects in the smart city context. For better understanding, some of the discussed lifecycle aspects are demonstrated in a smart parking use-case.

Keywords

Product Lifecycle Management Service Lifecycle Management Closed loop lifecycle management System of Systems Smart city 

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.

 

Definition/Scope

Product (PLM)

An output that results from a process. Products can be tangible or intangible, a thing or an idea, hardware or software, information or knowledge, a process or procedure, a service or function, or a concept or creation (ISO 9001:2000) [5]

Service (SLM)

An activity done for others with an economic value and often done on a commercial basis [6]

PSS (PLM-SLM)

An extended product, where the product is a complex result of tangible and intangible components [9]

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.

Phases of PLM [28].

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.

Phases of SLM [28].

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 reshaping 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.

PSS lifecycle model [28].

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).

Aspect

Description

Phases

To allow evolutionary development of smart city, in most cases, smart city is composed of independently developed, operated and managed service systems. Therefore, SCLM has no clear phases similar to PLM/SLM; instead, each component of the smart city has its own lifecycle; and, smart city components can be at different phases - BOL, MOL and EOL - in the same time. Therefore, the lifecycle of smart city is a lifecycle of lifecycles

Bill of Materials (BOM)

BOM is a hierarchical structure showing the components that make up the end item [14]. The end item in this case can be a smart city service system or a smart city SoS. In the smart city context, smart objects can be repurposed and reused [23]. Therefore, BOM in the smart city context should allow for loose-coupling, modularity, composability, scalability, interdependency and dynamic complexity [24, 25]

Object/Service/System data

The interdependence between different smart systems in the smart city context, as detailed in hierarchy structure of BOM, gives the right to interdependent systems to exchange product/service/system data that should be generated and used across lifecycle phases. Archiving and traceability requirements vary from one industry to another. Smart Object/Service/System data can be in various states, including in-work, in-process, in-review, released, as-designed, as-planned, as-built, as-installed, as-maintained, and as-operated [14]

Ownership and Rights

Ownership in the smart city context is an important issue. In light of heterogeneity, repurposing and reusing of data sources, certain components can belong to multiple smart systems. Due to the dynamic complexity of smart city, rights may change during lifecycle. Rights include rights to access, create and modify data, and also rights to approve and promote

Policies and Regulations

Smart city is subject to many policies and regulations related to the different utilities infrastructure, public services and applications. Cyber security, resiliency of ICT connectivity infrastructure and user data privacy are of absolute importance

Versions, Variants and Options

During SCLM phases, smart city components can be modified or upgraded, particularly software components. Smart city components can have multiple versions, options, variants, releases and alternatives

Processes

Processes include problem report, engineering change process and enterprise notification process. For these processes, it’s absolutely important to define actors and roles. In the smart city context, processes include notifications, verifications and approvals between actors from different domains

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”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.

Smart parking: high-level illustration.

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.

BOM: screenshot from aras innovator®.

Fig. 6.

O-DF object tree.

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.

PR process.

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.

ECR workflow process.

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.

ECN workflow process.

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.

Footnotes

References

  1. 1.
    Zhang, H., Sekhari, A., Ouzrout, Y., Bouras, A.: PLM components monitoring framework for SMEs based on a PLM maturity model and FAHP methodology. J. Mod. Proj. Manag. 2(1), 109–119 (2014)Google Scholar
  2. 2.
    Zhang, H., Ouzrout, Y., Bouras, A., Savino, M.: Sustainability consideration within product lifecycle management through maturity models analysis. Int. J. Serv. Oper. Manag. 19(2), 151–171 (2014)Google Scholar
  3. 3.
    Li, J., Tao, F., Cheng, Y., Zhao, L.: Big data in product lifecycle management. Int. J. Adv. Manuf. Technol. 81(1), 667–684 (2015)CrossRefGoogle Scholar
  4. 4.
    Stark, J.: Product Lifecycle Management: 21 Century Paradigm for Product Realization, 2nd edn. (2011)Google Scholar
  5. 5.
    Isaksson, O., Larsson, T.C., Öhrwall Rönnbäck, A.: Development of product-service systems: challenges and opportunities for the manufacturing firm. J. Eng. Des. Spec. Issue Prod.-Serv. Syst. 20(4), 329–348 (2009)Google Scholar
  6. 6.
    Sassanelli, C., Pezzottac, G., Rossi, M., Terzia, S., Cavalieric, S.: Towards a lean product service systems (PSS) design: state of the art, opportunities and challenges. Procedia CIRP 30, 191–196 (2015)CrossRefGoogle Scholar
  7. 7.
    Freitag, M., Kremer, D., Hirsch, M., Zelm, M.: An approach to standardize a service life cycle management. In: Enterprise Interoperability. John Wiley & Sons, Ltd., Chichester (2013)Google Scholar
  8. 8.
    Garetti, M., Rosa, P., Terzi, S.: Life cycle simulation for the design of product-service systems. Comput. Ind. 63, 361–369 (2013)CrossRefGoogle Scholar
  9. 9.
    Cassina, J., Cannata, A., Taisch, M.: Development of an extended product lifecycle management through service oriented architecture. In: The 1st CIRP Industrial Product-Service Systems (IPS2) Conference, Cranfield University, 1–2 April 2009Google Scholar
  10. 10.
    Kiritsis, D.: Closed-loop PLM for intelligent products in the era of the internet of things. Comput.-Aided Des. 43, 479–501 (2010)CrossRefGoogle Scholar
  11. 11.
    Främling, K., Kubler, S., Buda, A.: Universal messaging standards for the IoT from a lifecycle management perspective. IEEE Internet Things J. 1(4), 319–327 (2014)CrossRefGoogle Scholar
  12. 12.
    Hefnawy, A., Bouras, A., Cherifi, C.: Lifecycle based modeling of smart city ecosystem. In: IKE 2015: The 14th International Conference on Information and Knowledge Engineering, Las Vegas, 27–30 July 2015Google Scholar
  13. 13.
    Hefnawy, A., Bouras, A., Cherifi, C.: IoT for smart city services: lifecycle approach. In: The International Conference on Internet of things and Cloud Computing (ICC 2016), Cambridge, 22–23 March 2016Google Scholar
  14. 14.
    Hefnawy, A., Bouras, A., Cherifi, C.: Integration of smart city and lifecycle concepts for enhanced large-scale event management. In: IFIP PLM 2015 International Conference, Doha 19–21 October 2015Google Scholar
  15. 15.
    Lopes, J., Pineda, R.: Service systems engineering applications. In: Conference on Systems Engineering Research (CSER 2013), 19–22 March 2013Google Scholar
  16. 16.
    Mahut, F., Bricogne, M., Daaboul, J., Eynard, B.: Servicization of product lifecycle management: towards service lifecycle management. In: IFIP PLM 2015 International Conference, Doha, 19–21 October 2015Google Scholar
  17. 17.
    Freitag, M., Stadler, S.: Requirements for a service lifecycle management. In: Conference Paper: Fraunhofer IAO, January 2013Google Scholar
  18. 18.
    Cavalieri, S., Pezzotta, G.: Product–service systems engineering: state of the art and research challenges. Comput. Ind. 63(4), 278–288 (2012)CrossRefGoogle Scholar
  19. 19.
    Poncela, J., et al.: Smart cities via data aggregation. Wirel. Pers. Commun. 76(2), 149–168 (2014)CrossRefGoogle Scholar
  20. 20.
    Jin, J., Gubbi, J., Marusic, S., Palaniswami, M.: An information framework for creating a smart city through internet of things. IEEE Internet Things J. 1(2), 112–121 (2014)CrossRefGoogle Scholar
  21. 21.
    Sum, J.: Service systems engineering: framework & systems modeling. Institute of Technology Management, National Chung Hsing University Taichung 40227, Taiwan ROC, January 2014Google Scholar
  22. 22.
    BKCASE Editorial Board. The Guide to the Systems Engineering Body of Knowledge (SEBoK), v.1.3. R.D. Adcock (EIC). The Trustees of the Stevens Institute of Technology, Hoboken (2014)Google Scholar
  23. 23.
    Tao, F., Zuo, Y., Xu, L., Lv, L., Zhang, L.: Internet of things and BOM-based life cycle assessment of energy-saving and emission-reduction of products. IEEE Trans. Ind. Inform. 10(2), 1252–1261 (2014)CrossRefGoogle Scholar
  24. 24.
    Böhmann, T., Leimeister, J., Möslein, K.: Service systems engineering. Bus. Inf. Syst. Eng. 6, 73–79 (2014). doi: 10.1007/s12599-014-0314-8 CrossRefGoogle Scholar
  25. 25.
    Silcher, S., Minguez, J., Scheibler, T., Mitschang, B.: A service-based approach for next-generation product lifecycle management. In: IEEE IRI 2010, Las Vegas, Nevada, USA, 4–6 August 2010Google Scholar
  26. 26.
    Schmidt, D., Malaschewski, O., Fluhr, D., Mörtl, M.: Customer-oriented framework for product-service systems. In: 7th Industrial Product-Service Systems Conference-PSS, Industry Transformation for Sustainability and Business, Procedia CIRP30, pp. 287–292 (2015)Google Scholar
  27. 27.
    IEEE-Reliability Society. Technical Committee on “Systems of Systems” – White Paper, October 2014Google Scholar
  28. 28.
    Wiesner, S., Freitag, M., Westphal, I., Thobena, K.: Interactions between service and product lifecycle management. In: 7th Industrial Product-Service Systems Conference- PSS, Industry Transformation for Sustainability and Business. Procedia CIRP30, pp. 36–41 (2015)Google Scholar

Copyright information

© IFIP International Federation for Information Processing 2016

Authors and Affiliations

  1. 1.DISP LabUniversité Lumière Lyon 2LyonFrance
  2. 2.DCSE, College of EngineeringQatar UniversityDohaQatar
  3. 3.Ministry of Transport and Communications (MoTC)DohaQatar
  4. 4.Interdisciplinary Centre for Security, Reliability and TrustUniversity of LuxembourgLuxembourg CityLuxembourg
  5. 5.Aalto School of Science and TechnologyEspooFinland

Personalised recommendations