Public. 1 Introduction and scope of this deliverable Lifecycle models in engineering... 6

Transcription

1 Horizon 2020 Acronym: Manutelligence Project No: Call: H2020-FoF-2014 Topic: FoF-05 - Innovative product-service design using manufacturing intelligence Type of action: RIA Duration: D2.1 Combined Lifecycle Model for Collaborative Product-Service Engineering Type Deliverable Document ID: D2.1 Workpackage: 2 Leading partner: BIBA Author(s): Stefan Wellsandt, Daniele Cerri Dissemination level: PU Status: Final Date: Version: 1.0 Copyright Manutelligence Consortium Manutelligence N

2 Table of Contents 1 Introduction and scope of this deliverable Lifecycle models in engineering Product lifecycle models Introduction Study at a glance Methodology Findings Service and Product-Service lifecycle models Introduction Study at a glance Methodology Findings Conclusion Perspectives on lifecycle models Introduction Findings Matter, energy and information flows Class and instance concept (Type and Item) State and sequence concept Multi-lifecycle models Time offsets in multi-lifecycle models Product and part lifecycles Processes and stakeholders Differences between product and service/ps lifecycles Conclusion Combined lifecycle modelling Purpose of the approach Lifecycle Modeling Language Overview Key elements and features of LML Comparison of requirements and LML features Conclusion Guiding Example using LML Copyright Manutelligence Consortium Page 2 / 57

3 6 Methods used in service engineering Conclusion References Annex Glossary Copyright Manutelligence Consortium Page 3 / 57

4 1 Introduction and scope of this deliverable Increasing complexity of products and growing amounts of digital construction data challenge product development for the last 30 years. In its early days, the management of these data was handled through product data management (PDM) systems. Better understanding of products and their impact on environment caused product developers to extend their point of view, in order to cover product information beyond the point of sale. This extension became especially popular in the 1990s when the idea of product lifecycles reached a broad audience. Increasing awareness of ecological impacts also expressed by agreements upon the Kyoto Protocol in 1997 provided fertile grounds, consequently resulting in assessment approaches for the ecological impacts of products. These assessments from cradle to grave of products were finally standardized in 1997 through the first version of ISO Besides the increased awareness in academia and industry for ecological impacts of products, the growing economies of the BRIC countries raised the question of globally limited natural resources. Determined by this question, conservation of resources became an economic goal of companies. Along with increasing complexity of machinery, the integration of efficient maintenance, repair and overhaul strategies to conserve values became an integral part of the product lifecycle. Product data management, management of ecological impacts and the need to avoid resource wastage provide those three baseline phases, found in the majority of product lifecycle descriptions. These phases are typically labeled as beginning, middle and ending of a product s life. Managing product information related to these three phases, i.e. the whole product lifecycle, is defined as Product Lifecycle Management (PLM) (Kiritsis, 2011). Since the early days of PLM, dozens of authors introduced their understanding of the product lifecycle. Depending on the authors backgrounds and research topics, descriptive lifecycle models include different processes and typically focus on particular phases while leaving others largely unspecified. This however is not unexpected, since the product lifecycle concept is rather broad and therefore suitable to various collaborative business processes. The scope of this deliverable is to structure existing lifecycle models for products and services, in order to derive and justify a common methodology to describe lifecycles. This methodology will serve as a basis for the identification of relevant data, information and knowledge, meant to be managed by combined lifecycle management (see Manutelligence DoA Task 2.2). The following sections of this deliverable are considered to be published as journal or conference articles: a) Survey of product lifecycle models b) Survey of service and PS lifecycle models c) Perspectives on lifecycle models Copyright Manutelligence Consortium Page 4 / 57

5 d) Methodology for modelling product and service lifecycles in engineering This document has an appendix consisting of a Glossary. The Glossary contains definitions for important terms and concept, used in the Manutelligence project. The structure of the deliverable and the utilization of its outcome is illustrated in Figure 1. Figure 1: Structure of the deliverable Section 5 and 6 of this deliverable contain supportive material, e.g. about important techniques used in service engineering Copyright Manutelligence Consortium Page 5 / 57

6 2 Lifecycle models in engineering Lifecycle models are a way to describe, in a simplified way, important steps a product or service has to pass while it exists. From an engineering perspective, lifecycle models provide system boundaries for management tasks (e.g. information or resource management). In marketing, the lifecycle is understood different it is used to describe the situation of a market-launched product. The marketing perspective of the lifecycle is not further covered in this work. This section provides an overview about existing lifecycle models. Since products and services are traditionally seen as different entities, also the academic literature is divided thus, chapter 2 is divided into two sub-sections. The first one covers a study about the extensive literature on product lifecycles, while the second one concerns an investigation about the rather limited literature on service and Product-Service (PS) lifecycles. 2.1 Product lifecycle models Introduction This study of existing lifecycle models aims to: - retrieve different perspectives on the lifecycle - identify relevant elements and concepts used in lifecycle modelling (e.g. processes and stakeholders) - structure lifecycle models according to common characteristics The study is not meant to be comprehensive, as the body of literature on PLM is too extensive. A Google Scholar search reveals more than papers related to product lifecycle management, probably growing day by day. The study is, to our knowledge, the largest of its kind in PLM. A similar study comparing 17 lifecycle models was conducted by Qureshi, Gericke and Blessing in 2014 (Qureshi et al., 2014). The paper, however focuses on the design context while usage and end-of-life are weakly covered Study at a glance The conducted study on product lifecycle models, presented in this deliverable, is summarized in Table 1 according to important facts about the extent of the survey. Table 1: Facts about the study on product lifecycle models Facts Literature source Values Science Direct Copyright Manutelligence Consortium Page 6 / 57

7 Search date June Matching available literature 315 On-topic literature (total) 132 On-topic journal papers 62 On-topic conference papers 6 On-topic books 4 Selected papers (illustrative) 73 Selected papers (textual only) 59 In total, 73 extracted product lifecycle models are subject of the study. This study and its results are planned to be submitted as a Journal paper (e.g. International Journal for Product Lifecycle Management) Methodology The base literature was collected from the Science Direct database using the following search string: "product lifecycle model" OR ( ) ("product lifecycle management" OR "product lifecycle") AND ("beginning of life" OR "begin of life" OR "middle of life" OR "end of life" OR "smart product" OR "intelligent product") The base literature was screened to identify relevant documents. Relevancy criteria included the paper s topic (e.g. no life sciences and chemistry) and type of content (e.g. no editor summary). Another criterion was that the literature contains at least one complete lifecycle model. A product lifecycle model describes a product s transformation over time. The stages where transformation happens can be represented by processes and stakeholders. A lifecycle model is considered as complete, once it contains at least one process or stakeholder belonging to beginning of life (BOL), middle of life (MOL) and end-of-life (EOL). These three phases are selected because they are frequently used in literature to describe the product lifecycle on a general level (Borsato, 2014; Cavalieri and Pezzotta, 2012; Kiritsis, 2011; Kubler et al., 2015). The appearance of the model can be either illustrative (figure) or textual. 1 The search was conducted before the Manutelligence project officially started, the analysis was done in Task 2.1. Copyright Manutelligence Consortium Page 7 / 57

8 In consequence, the literature was initially divided into four categories: a) Sources with at least one illustration related to a complete product lifecycle model b) Sources with a textual descriptions of a complete product lifecycle model only c) Sources that are not relevant d) Sources without a clear product lifecycle model Literature in category d) was discussed among the authors (not all of them) and moved either to category a), b) or c). Dismissed papers, for instance, focus only one lifecycle phase without naming or explaining the other two; these documents do not include a holistic lifecycle model. Only literature of category a) was further investigated in the study as it is rich in content and potentially provides more perspectives, entities and concepts to analyze. Out of the remaining documents, the different illustrative lifecycle models were extracted and transferred into a text document. Besides the text document, a spread sheet with the relevant literature was created. Two workshops were used to discuss samples of the extracted models and decide on characteristics for further analysis of the remaining models. The resulting spread sheet was extended by several columns, one for each characteristic. All models were described according to the following characteristics: - Meta-information (author, year, title, keywords, source, source type) - Model contains o Material flows or stocks o Energy flows or stocks o Waste/emission flows or stocks o Information flows or stocks o Processes o Stakeholders - Geometry (e.g. circular, linear) - Model describes multiple lifecycles or not - Naming of lifecycle elements (phases/processes/stakeholders) Since the description of the models (according to the aforementioned characteristics) was done by several persons, definitions for potentially ambiguous characteristics were agreed. These definitions are summarized in Table 2. Table 2: Definitions of characteristics used to structure lifecycle models Category type Flows and stocks Category name Matter Description Comment Material including the product that is exchanged between processes or stakeholders. Material transformation and/or state. Stocks may look like boxes or blobs while flows are more like arrows. Energy Energy that is exchanged between processes or stakeholders or used for matter transformation (e.g. in production). Copyright Manutelligence Consortium Page 8 / 57

9 Information Waste and Emissions Information that is exchanged between processes and stakeholders. Information from material and/or energy consumption/properties Waste (including dismissed products, scrap, spare parts) and Emissions that are exchanged between processes or stakeholders. Entities Processes Activities that are performed Usually these are boxes or Stakeholders Organizations or Persons blobs that act as end points of arrows/flows. Other Geometry Multi-lifecycle Naming elements of Sequencing of processes and stakeholders. In most cases a separation into linear and circular sequencing is applicable. Contains products of different kinds or different instances of the same product type. Typically concerns processes and stakeholders. The identified characteristics are used to structure the models. Results of the analysis are illustrated in the following. Not further covered. The extracted models are not referenced back to their original authors, since the survey focuses on the authors understanding of the lifecycle rather than a comprehensive identification of unique models introduced in the past Findings An overview of the identified literature is provided as a word cloud of keywords and an illustration clustering algorithm s result. Figure 2: Word cloud of the top 20 keywords used in the selected papers with illustrations The word cloud reflects the important topics of relevant literature. Most notably the terms product, sustainable, design and lifecycle are mentioned. The words supply and chain are named less frequently but mark important synonyms for the product lifecycle approach. With respect to Manutelligence, the word service is used is only mentioned a few times, which also substantiates the objective of the project to develop a combined process for services and Copyright Manutelligence Consortium Page 9 / 57

10 products. Table 3 provides a quantitative result for the lifecycle models based on the characteristics summarized in Table 2. Table 3: Statistics about the investigated lifecycle models Type Values Description Number of elements Minimum 3 These numbers describe the detail of the lifecycle Median 7 models. Number of models with element type Number of models with flow type (multiples possible) Number of models with geometry type Maximum 19 Process 68 These numbers describe the perspective taken by Stakeholder 21 lifecycle models. Both 18 Matter 26 These numbers describe how dominant flows are in Energy 9 general for LCMs (flow vs. no flow) and what kind of Waste/emission 21 flows are dominant in the models. Information 17 No flows 32 Linear 40 These numbers describe the importance of closedloop Circular 29 aspects of the lifecycle models for the authors. other 4 Number of multi-lifecycle models 16 This number describes how well the aspect of managing multiple lifecycles is covered. Lifecycle models contain between 3 and 19 elements with a median of 7. The number of elements indicates the granularity of a model. The majority of lifecycle models includes processes, while only 18 models include processes and stakeholders. From the perspective of flow types, the matter and waste/emission flows are dominant. Only 17 out of 73 models feature information flows in an explicit way. A total of 32 models features no explicit flows at all. Concerning the geometry of the lifecycle models, the majority of the models is of a linear type not featuring closed-loop characteristics. Circular models contain different feedback flows or directly arrange processes/stakeholders in a circular way to indicate that the product and its components circulate. Four models contain other geometries, such as a cross. The cross geometry is used by models that combine two lifecycle models at once, e.g. product and factory. Finally, only 16 out of 73 models contain multiple lifecycle models in one illustration which substantiates the intention of Manutelligence to use a combined lifecycle modeling approach. Besides the analysis of characteristics of lifecycle models, also the actual content of the models has to be investigated. The contents concern processes and stakeholders (elements), as well as different flows. As the elements are not uniformly named, they are merged into classes of elements with a similar meaning. Table 4 contains a list of the suggested classes. Copyright Manutelligence Consortium Page 10 / 57

11 Table 4: Classes of processes and related color codes No. Color Processes 1 Ideation, Requirements, Conceptualization 2 Design 3 Raw material extraction 4 Primary industry, bulk material processing 5 Manufacturing 6 Assembly 7 Prototyping, testing 8 Procurement/sourcing, distribution, logistics 9 Marketing, sales, retail 10 Use 12 Maintenance, repair, overhaul, service 13 Reuse, remanufacturing, recycling, disposal There is a total of 13 classes while each class subsumes different processes of a similar meaning or scope. The class-building is based on the observations made during the survey. Granularity of the classes differs, i.e. some classes contain several processes while others consist of a single one. Following a qualitative approach, each class received a color code instead of a quantitative value. The suggested classes are applied to the identified lifecycle models and their elements. The result is a map of color-coded elements, as illustrated in Figure 3. Figure 3: Excerpt of color-coded lifecycle model elements As illustrated above, the color-coding cannot be applied for all models. Some models only contain lifecycle phases (e.g. BOL, MOL and EOL) that are too general to be coded, while other processes did not match with the pre-defined classes (e.g. embodiment, sourcing, amend and resource). In total, 45 elements could not be assigned to the abovementioned classes; 9 lifecycle models out of 73 could not be coded at all, for instance, because they only contain phases like BOL, MOL and EOL. Copyright Manutelligence Consortium Page 11 / 57

12 From the color-coding it can be recognized that certain classes of processes are much more frequent than others. It further becomes evident that some lifecycle model omit certain processes. Some models focus on processes related to material flows (e.g. raw material extraction and assembly) while others have a detailed design process consisting of up to 5 elements out of 8 in total. For another overview, the color-coded elements are sorted spatial, i.e. elements belonging to the same class are stored in columns. The resulting illustration is provided in Figure 4. Figure 4: Spatial sorting and color-coding of all covered lifecycle models The illustration is not meant to provide details for all 73 individual models. However, it highlights the coverage of the lifecycle models and the selected classes of lifecycle processes, in order to identify common and uncommon elements. For easier understanding, the sequencing of processes was changed for some lifecycle models. Most common in lifecycle modelling (>70% of models) is to cover manufacturing, use and endof-life activities. 45% of models contain a design process while around 30% coverage is achieved by conceptualization, extraction of raw materials, primary industry (e.g. metal smelting), distribution, and maintenance, repair and overhaul (MRO). The calculated coverage is summarized in Table 5. Table 5: Coverage of lifecycle process classes in lifecycle models Lifecycle processes Coverage Reuse, remanufacturing, recycling, disposal 90 manufacturing 88 use 77 Design 45 procurement/sourcing, distribution, logistics 34 Ideation, Requirements, Conceptualization 30 Copyright Manutelligence Consortium Page 12 / 57

13 Raw material extraction 26 maintenance, repair, overhaul, service 26 primary industry, bulk material processing 25 assembly 19 marketing, sales, retail 16 prototyping, testing models were analyzed in total The results in Table 5 must be seen in light of the subjective assignment of the classes. Since the assignment was quite clear for the majority of processes, some erroneous assignments are not considered as relevant for the objective of this survey. The fact that a large number of different processes are assigned to process class #13 (EOL), the high coverage has to be questioned. 2.2 Service and Product-Service lifecycle models Introduction This second study aims to complement the first one presented in section 2.1. It will provide contents that introduce additional perspectives that have to be taken into account for a combined lifecycle model. The second study is smaller compared to the first one, as the lifecycle concept is not so frequently applied to services or product services. The section will further highlight which methods can be used for service design. During the years, many approaches have been developed to support the design and development of services as a stand-alone system or a combined Product-Service (PS) system (Cavalieri and Pezzotta, 2012). First scientific studies about this topic were introduced during the 70s and the 80s, with the terminology New Service Development, Service Design and Service Engineering. - New Service Development is mainly market-driven and considers the overall process to develop new services, from idea generation to market launch. - Service Design, sees service from an outside-in point of view, focusing on end users. The previous approaches, however, are not able to design and develop services with a systematic and extensive perspective, considering not only user s requirements, but also service provider s requirements. Furthermore, New Service Development and Service Design have a lack of seamless integration of product and service. In this context, Service Engineering arose, with the aim to cover lacks. Contrary to the prevalent marketing perspective of New Service Development and user perspective of Service Design, Service Engineering aims to apply the engineering-scientific know-how to develop Product Service Systems (PSS) in a systematic and methodological way (Aurich et al., 2006; Bullinger and Warschat, 1995). Copyright Manutelligence Consortium Page 13 / 57

14 Concepts that are similar to PSS are Extended Product and Functional Products (definitions for both are provided in the Annex of this deliverable) Study at a glance The study has been conducted with the aim to find relevant works and contributions in the field of service engineering and product service systems, avoiding the repetition of similar studies. The objective is then to capture existing information on service engineering and product service systems, in order to build a strong base on this field and a robust starting point for the Manutelligence project Methodology The base literature was collected from academic online sources (ScienceDirect, Google Scholar, Springer, etc.) focusing on the most relevant works and contributions about product service systems and service engineering. In detail, the focus of this research was to find relevant contributions about the state of the art of service engineering and product service systems and about the lifecycle of service and product service systems. Therefore, the selection was focused on the collection of the top contributions in the fields mentioned above. The starting point was the relevant and extensive research conducted by Cavalieri and Pezzotta (Cavalieri and Pezzotta, 2012). In the next section, findings of the research are reported Findings About Product-Service Systems, three main elements of the systems have been identified by Cavalieri and Pezzotta: Entities, Lifecycle, and Actors. Entities. Service content is supplied by a service provider and delivered through a channel (transfer of the service from provider to customer). The physical product is part of the service content or the service channel itself. The combination makes up the added value for the customer (Sakao and Shimomura, 2007). Lifecycle. Cavalieri and Pezzotta claim that it is not feasible to have an exact separation between product and service, from design and development to delivery and use phase. In this sense, a PSS creates a win win situation for all the stakeholders involved in the process over the lifecycle (Meier et al.). Manufacturing firms, for example, have to provide services during the complete lifecycle of the physical product, such as operations on the installed base, in order to increase revenues (Oliva and Kallenberg, 2003). This means that companies have to shift their focus from merely designing and selling products, to supporting and accompanying their usage and end-of-life. What is really evident from the analysis of the approaches, and the phases they consider during the engineering process, is that they are focused mainly on an in-depth and detailed investigation of the BOL phase. Only a few approaches have been conceived with a Copyright Manutelligence Consortium Page 14 / 57

15 whole life cycle perspective of the development process and of the related methods and tools (Cavalieri and Pezzotta, 2012). Actors. PS systems are forcing a new understanding of relationships, and many stakeholders are involved in the provision of sustainable and ecological solutions. However, to consider customers and stakeholders as key resources, the development process has to be redefined, and new activities must be encouraged throughout the life cycle phases. The aim in service development is to create prerequisites for long-term profitable customer relations, and to attract and keep customers who are satisfied and loyal along the different lifecycle phases (Cavalieri and Pezzotta, 2012). An analysis of the most renowned Service Engineering process models is provided in Table 6. Table 6: Lifecycle phases considered by Service/PSS models 2 2 The terminology is not aligned with the glossary, since the table uses original wording from Cavalieri and Pezzotta. Copyright Manutelligence Consortium Page 15 / 57

16 An extensive list of phases along the lifecycle has been elicited by merging the single proposals. Most relevant phases investigated by these models are related to the BOL, with a great emphasis on the requirements engineering activities. Use, Maintenance and EOL phases, instead, have been considered only by recent publications (Aurich et al., 2006; Lindahl et al., 2007). A summary of the coverage for the different models is provided in Table 7. In order to harmonize the terminology, the term lifecycle phase is exchanged for lifecycle process (for definitions consult the Annex of this deliverable) in the table. Table 7: Coverage of tasks in service engineering process models Lifecycle processes Coverage Implement and measure 73 Concept development and evaluation 64 Requirements generation 55 Requirements analysis 55 Final design 55 Detailed design 45 Middle of life 36 Requirements identification 27 Concept generation and evaluation 27 Embodiment and evaluation 27 Test (Prototyping/Simulating) 18 End of Life support 18 Monitoring and Evaluation 9 Monitoring and feedback analysis 0 11 models were analyzed in total An important observation is that activities related to the end of life are not or only briefly covered by the 14 process models especially monitoring and evaluation is barely considered. In PSS literature, the lifecycles of products and services contain different phases. For the object product the following phases can be classified: requirements, product planning, development, process planning, production, operation and recycling. For the research object service the following phases can be defined: definition, requirements, conception, realization, operational usage and change (Deutsches Institut für Normung e.v., 1998; Zinke et al., 2013). A summary of the different phases is provided in Figure 5. Copyright Manutelligence Consortium Page 16 / 57

17 Figure 5: Product/Service Lifecycle (adapted from DIN) In every stage of the product lifecycle, different services are identified. Each of the services (A- G) has its own lifecycle. Figure 6 provides an example for this relation for service A. For example, service A is delivered during the requirements stage of the product lifecycle, service B during the product planning, etc. The different service and product lifecycles do not necessarily run synchronous. For example a service like customer consulting for product planning is realized and operationally used in the product planning phase of the product. But a service like maintenance should be defined and designed in the requirements and product planning phase, and executed in the product s operational phase (Zinke et al., 2013). Figure 5 introduces a lifecycle process for service that has no equivalent in the product lifecycle. Indeed, product and service are different: they are comparable for the so called BOL (design of product/service and realization of product/service) and the MOL (usage), but they are different in the EOL. Product can be reused, remanufactured or recycled, recovering materials. Service, on the other hand, are updated and improved after usage or a new service can substitute the old one. Furthermore, a service could be refused by the customer in consequence, the customer can request a service by another provider. Therefore, it is crucial to understand which similarities and differences have product and service lifecycles, in order to create an efficient and effective combined lifecycle model. Due to the temporal dependencies between product and service, multiple lifecycles have to be orchestrated to create a sustainable customer experience. The current literature on PSS (and synonyms) provides very limited answers to this problem. A first attempt to define a lifecycle for a related domain, i.e. Functional Products (see Annex for definitions), was made by Lindström et al. (Lindström et al., 2014). The proposed model is illustrated in Figure 6. Copyright Manutelligence Consortium Page 17 / 57

18 HW = Hardware, SW = Software, SSS = Service-support system, MO = Management of operation Figure 6: Technical perspective of a Functional Product Lifecycle (Lindström et al., 2014) Without discussing the Functional Product -concept in detail, the lifecycle model shows some interesting aspects that are relevant for PSS as well. According to the illustration, the Functional Product (FP) is affected by five elements, i.e. hardware, software, service-support, management of operations and the creation of win-win situations for provider and customer of the FP. The first four elements are initially developed concurrently. Once the development has finished, win-win agreements are realized and the elements follow different processes each element is operated and from time to time developed further along the lifecycle. If one element is not operating anymore, it has to be repaired or adapted not operating elements do not imply that the whole FP is obsolete. The following list contains a summary and assumptions about FP s from the lifecycle perspective (and PSS, since the concepts are similar): - Elements may run concurrently during development - Elements may run asynchronous after development - Relations between the elements can be weak if one element breaks the whole is still operating - Relations between elements can be strong if elements are critical for the operation of the whole 2.3 Conclusion The two studies conducted for T2.1 reveal that the lifecycle concept is seen quite different for products and services. The product-centric lifecycle concept is more material oriented and has a strong focus on activities before usage, especially production and design, as well as after usage (e.g. EOL scenarios). Service-centric lifecycle concept (including the PS domain) puts more emphasis on relations between product and service and the orchestration of these elements. Within the two domains, the lifecycle models differ significantly, indicating that there is no commonly agreed standards how to describe the lifecycle. A reason for these differences might be that each model was produced for a specific reason (e.g. describing a use case) and Copyright Manutelligence Consortium Page 18 / 57

19 with a specific background of the authors. Thus, several models use their own terminology and way of representing the lifecycle. For the creation of a combined model, the differences among the models lead to different perspectives that have to be respected. At the same time, the combined model has to be flexible, so that different use cases can be described. In order to proceed with the definition of a combined lifecycle modelling method, different perspectives of lifecycle modeling are described in the following section. Copyright Manutelligence Consortium Page 19 / 57

20 3 Perspectives on lifecycle models This section will use the findings from section 2, in order to derive specific perspectives on product lifecycles. These perspectives need to be considered in the method that has to be developed to model lifecycles in a combined way. 3.1 Introduction Products like automobiles and ships are made of thousands of components including subsystems (e.g. engines and control units) and software. Each of these components has an own lifecycle while, at the same time, each of these can be described by a number of specific processes (e.g. design, production, maintenance, recycling and disposal) literally, a myriad of processes exist next to each other. Each of these processes maintains and exchanges product information, such as technical product specifications, CAD models, software documentation, and service instructions. An example for the magnitude of the complexity is the current practice in ship building more than 20 different IT systems are used to create and maintain the digital model of a ship s structure and related interior components. The management of product information, from the early design phase to the disposal of the product, is covered by Product Lifecycle Management (PLM) (Kiritsis, 2011). Fundamental to each PLM implementation is the Lifecycle Model (LCM) that defines the system boundary of the management task. A LCM may contain, for instance processes, stakeholders and information flows. All three elements are case dependent, i.e., different products and companies have specific processes, stakeholders and information flows. Similarities within the LCMs may be caused by best practices applied, standards used and regulations followed. While there are dozens of examples for LCMs available, little attention was paid to the general structure and characteristics of the lifecycle concept as such. These general characteristics, however, must be clear before combined LCMs for today s interplay of products, software and value-adding services can be developed. 3.2 Findings This section is structured into different subsections dealing with particular perspectives and concepts used in the identified lifecycle models and derived from business practice Matter, energy and information flows The product lifecycle can be seen from at least two general perspectives, a resource-efficiency and an information management perspective. The resource-efficiency incorporates flows of matter and energy. It ranges from cradle (raw material extraction) to grave (disposal) and is concerned with the environmental impact along Copyright Manutelligence Consortium Page 20 / 57

21 the whole lifecycle process chain. Matter and energy can be further separated into three categories of products (see further Dyckhoff and Spengler, 2010): - Goods (e.g. raw material and electricity) - Bads (e.g. waste and CO2-emissions) - Neutrals (e.g. waste heat and scrap) The differentiation is not made explicitly in the investigated LCMs but it helps to clarify that most of the models follow a simplified approach when describing matter and energy flows. Figure 7: Lifecycle model from the resource-efficiency perspective (Pigosso et al., 2010) An example for a LCM from the resource-efficiency perspective is illustrated in Figure 7 (Pigosso et al., 2010). Starting point of the exemplary lifecycle is the material extraction (e.g., through mining). It is followed by different processing steps like smelting, casting, machining and assembly. Once the assembly is completed, the product is ready for use, though it has to be transported to its customer. Due to degradation and other value-decreasing influences, the product may enter the end of life (EOL) phase (product s discard). Depending on the remaining value of the product, different scenarios can be chosen to conserve material and energy they can be returned into the processing chain to avoid using costly raw material and other products, or they can be directly returned into the MOL. Parts and components that cannot be conserved are incinerated or disposed on a landfill. Copyright Manutelligence Consortium Page 21 / 57

22 The second perspective considers the flow of product information ranging from the design of a product to its disposal. An example of a LCM from the information management perspective is illustrated in Figure 8 (Wellsandt et al., 2015). Figure 8: Lifecycle model from the information management perspective (Wellsandt et al., 2015) In addition to the processes covered in Figure 7, the information management perspective includes planning activities. Most notably, the design process is additionally covered, since the (digital) product model is created and maintained during this task. The model is then used in subsequent processes to prepare, for instance the production plan. Backward-directed information flows are important to realize improvement processes, such as the improvement of a product due to frequent complaints from its customers Class and instance concept (Type and Item) Thinking in classes and instances is commonly done in computer science to simplify complex programming tasks. A similar concept is discussed in philosophy known as types and tokens (Wetzel, 2006). In order to avoid getting lost in a theoretical discussion, this paper suggests the following working definitions: A class describes a set of objects with common characteristics while an instance is as a single object with unique characteristics. The working definition of an instance is similar to the concept of an item in existing literature (Främling et al., 2012) therefore, the terms will be used as synonyms. The class and instance concept is important, in order to distinguish different kinds of product information created along the lifecycle. An example for class-level information is a CAD model. The model itself describes the whole class of products (e.g. a component inside a car or ship). The differentiation between item and class inside a CAD model is not covered in this section, in order to reduce the complexity of the analysis. In order to receive item level information, two requirements must be fulfilled: 1) a product item must be created and 2) the item must be recognizable. The creation of product items is done during the production process. During the production process, the design specifications are realized through manufacturing and assembly. The main output of production is a set of discrete physical products. Once these products can be recognized as unique items, information can be Copyright Manutelligence Consortium Page 22 / 57

23 Physical world Conceptual / digital world Public directly assigned to them these products are sometimes called Intelligent or Smart Products (Främling et al., 2012). The assigned information can be on class- and item-level. A summary of the class and item concept in PLM is provided in Figure 9. While the differentiation of class- and item-level makes sense in the conceptual world. Once a product is realized, it is an item per-se (Främling et al., 2012); any attempt to classify several physical products ends up in the conceptual world. Therefore, there is no equivalent for a class in the physical world. The closest would be a product batch, e.g., made from the same melt of a steel mill. However, even then, the individual products later deviate from one another to a certain extend. Not further covered. A special case, not further considered in this section, is the production of craft products craft products are unique (one of a kind). In consequence, the design documentation is on item-level from the very beginning State and sequence concept In traditional PLM, information about the product type is the dominant kind of information that is managed (e.g. CAD files, BOMs and part lists). The availability of item-level information puts more emphasis on the immediate situation of products, such as their current characteristics and operational environment. The lifecycle model, on the other hand, typically consists of a chain of processes the product has to pass (e.g. production, use and disposal). This situation can be described by using two concepts, i.e. product states and sequences. A product s state can be described by using item-level information, collected at a specific time and place. Each state consist of a set of relevant state characteristics measured at specific checkpoints (stage-gate model). The state concept is important to describe, for instance, the transformation of a product item during its production (Wuest et al., 2014). Figure 4 illustrates the state concept in a production scenario. Another example for state information is the parts list of a product. Originally, Item model Two unique items with reduced number of features Two unique & tangible product items Item-Level Product with feature round Product with feature square Product class model Describes multiple items of same kind No equivalent Class-Level Other features Figure 9: Class- and item-level concept in PLM Figure 10: Product state concept in PLM Copyright Manutelligence Consortium Page 23 / 57

24 the list is a class-level information valid for all products of the same type. Once the list is assigned to and maintained for a specific product item, it becomes item-level information that is valid for a single product item only. The parts list is Figure 11: Linear lifecycle model typically updated after the physical components of a product were changed. This can occur during maintenance or repair activities. An item-level parts list describes the current state of a product with respect to the components that are inside the product at a specific point in time. In addition to the fact that states describe product items, they have another purpose in LCMs. A product state can be used to define start- and end-conditions of processes. An example is the common situation that a product is broken. The term broken indicates that the product is in a certain state characterized by the fact that it is no longer able to be used. The related item-level information could be stored in a log file created by a control unit (computer). Once the product is broken, the actual use process ends and a repair process has to start to make it operational again. Once the product is in the operational state, repair is successful and a new use activity may start. If the repair is completed but not successful (i.e. product remains broken), an EOL scenario like recycling may start. While product states are typically valid for a specific time and place, the description of processes and process chains, requires another concept for a comprehensive description of lifecycles in this paper, this second concept is stated as the sequence concept. A sequence in PLM consists of multiple phases or processes that are logically related (e.g. design must be done before production). Sequences occur either with a linear or circular shape in a LCM. Linear sequences describe, for instance, that a product item is created, used and discarded. This sequence in particular is oftentimes expressed as beginning of life, middle of life and end of life. An example for a linear sequence is provided in Figure 11. A feature of linear sequences is that there is a distinct start and end point. Products start their existence (as class information) during the design and become unique identifiable items during or after the production process chain. Their existence as an identifiable item ends, once they are no longer recognizable as an item (e.g. after disassembly, recycling or disposal). Copyright Manutelligence Consortium Page 24 / 57

25 Cyclic sequences are needed to describe, for instance, the reuse of material. An example for a cyclic lifecycle model is illustrated in Figure 12. The illustration shows a lifecycle from the material flow perspective. Opposing to the linear representation, the recycling and the production phase are connected. The intention of this connection is to highlight that material, such as metal, plastics or paper, is reused. Cyclic sequences, and the differentiation of classes and items, introduce a problem on the logical level for modelling lifecycles. The recycling of one product item cannot be related to the production of the same item, since the production had finished in the past. A similar example is the feedback of item-level information (e.g. about a specific product s usage) into the design process of a new product generation (product class) Multi-lifecycle models Figure 12: Cyclic lifecycle model (contains logical problem) The aforementioned logical problem of cyclic sequences can be avoided by modelling multiple product items or classes into the representation. Representation of multiple lifecycles is covered in the following section The appearance of the model shifts from a single lifecycle (e.g. Figure 7 and Figure 8) to a multi-lifecycle model. An example of a multi-lifecycle Figure 13: Example of a multi-lifecycle model model is provided in Figure 13. The model depicts the relation of two linear lifecycles belonging to different product items; they are connected by information and matter/energy flows. The flows represent the cyclic behaviour that is illustrated in Figure 6. By adding two or more lifecycles, the cyclic model becomes linear resolving the logical problem. Two aspects that are not covered in Figure 13 are the duration of lifecycle phases, and the fact that products are typically build from parts that may come with own lifecycles. Not further covered. While the aforementioned multi-lifecycle model focuses on different product instances, multiple lifecycles can be created by, for instance, refurbishment of the product. A refurbished product remains as an instance, but is sold again and thus receives another user. This special case of a multi-lifecycle model is not covered in this section, as the case is relevant. Copyright Manutelligence Consortium Page 25 / 57

26 3.2.5 Time offsets in multi-lifecycle models Each lifecycle phase has a defined start and end time. Depending on the product class and item, the duration of phases can be highly different. While durable goods, for instance, feature very long usage phases of up to several decades, consumer goods can have a much shorter time span. Figure 14 introduces a representation that takes credit of the different duration of lifecycles. Figure 14: Multi-lifecycle model with timed phases Timing of lifecycle phases can result in offsets between different phases. Offsets can be mandatory or optional. A mandatory offset is the duration between the design phases of two product generations. The offset exists, as the second generation logically depends on the first one (i.e. design of the first generation must have started). An example for an optional offset is the different duration of the usage phase of two product items. This particular offset might be based on environmental factors that result in a breakdown of one item while the other is still operational Product and part lifecycles In many cases, products are built from parts or modules. Understanding the current state of parts along the lifecycle is important for activities such as maintenance, repair and refurbishment. In terms of lifecycle modelling, and depending on the detail of the actual model, parts are products with unique individual lifecycles. An illustration of multiple lifecycles for a product and its parts is provided in Figure 15. The illustration is similar to the graphical presentation in a Gantt-chart. The example can be mapped to a car (product) and its engine (part). At some point during the usage phase, the engine breaks and must be exchanged by another engine of the same specification and make. The beginning of each the three Figure 15: Lifecycles for one product item and two related part items lifecycles look like a cascade (stair or waterfall), since each item is produced at a different moment in time. The beginning of the usage phase, however, is the same for the product and the part item number one. Asynchrony is introduced once the first part (engine) breaks. From this moment on, the part number two enters the usage phase of its superordinate product while part item one enters its end of life. One can imagine the inherited complexity of many commonly used products, considering that an engine again consists of multiple individual parts, Copyright Manutelligence Consortium Page 26 / 57

27 each with its unique lifecycle. One reaches a large number of interrelated lifecycles rather quickly, accompanied with the known challenges of large amounts of information (e.g. storage, search, transmission and analysis). Managing concurrent lifecycles is important, in order to maintain the functionality of product items. The management of multiple product generations (class-level) of different product types was not covered by the provided example, however, a similar illustration is possible on classlevel rather than item-level Processes and stakeholders A lifecycle is frequently described as a sequence of processes. In some cases, however, lifecycle models contain stakeholders like designers, manufacturers and users. Stakeholders employ processes, such as a manufacturer that is responsible for the production of a product. Each of the lifecycle processes may be related to one or more stakeholders. Furthermore, one stakeholder might be related to multiple processes as illustrated in Figure 16. Figure 16: Relations between processes and stakeholders along the lifecycle The integration of stakeholders in a lifecycle model is furthermore related to the instance and class concept. Stakeholders, can be seen on a class-level (e.g. manufacturer and user) or on an instance-level (e.g. manufacturer A, B and C). For the management of lifecycle information (i.e. PLM) the relation of product items and stakeholder instances is important (Främling et al., 2012 provide an example where the concept is applied) Differences between product and service/ps lifecycles So far, most of the characteristics of lifecycles in engineering were derived with a product s lifecycle in mind. In current business environments, however, the paradigm of servitization is prevailing (Vargo and Lusch, 2004), (Wuest et al., 2015). Servitization aims to complement or substitute products by services. A service is [ ] an activity or benefit that one party can offer to another that is essentially intangible and does not result in the ownership of anything. Its production may or may not be tied to a physical product. (Kotler and Connor Jr, 1977). A recent extension of this perspective is the PS concept (see Cavalieri and Pezzotta, 2012 for an overview). A PS is a special offer to customers, consisting of interrelated services and products. It requires an integrated development approach to define a PS, though the development of the Copyright Manutelligence Consortium Page 27 / 57

28 individual product or service can be independent from each other. The integration is based on a specific business model. Business models. The concept of PSs enables different kinds of business models compared to the traditional sales of physical products. In general, a PS can be product-, use- or resultoriented (Van Ostaeyen et al., 2013). Product-oriented. Ownership of the product is with the customer. The PS provider is offering complementary services like maintenance, repair, consulting and training. Use-oriented. Ownership of the product is with the PS provider. The customer pays when using the product. Examples include car-sharing, as well as pay-per-use contracts for office photo copiers. Result-oriented. Ownership remains with the PS provider. The customer pays for a function al result that directly fulfils customer needs. An example is selling luminosity for buildings (Philips N.V., n.d.). The provider may take full responsibility for all product lifecycle related processes including design, installation and disposal. With respect to the development of the aforementioned business model, distinct differences from product lifecycles are intangibility and value co-creation. Intangibility. Due to the intangibility of a service, there is no immediate matter or energy flow along a service lifecycle. In case of a PS, however, the related business model causes interactions among product- and service-related processes (Wiesner et al., 2015). While Wiesner et al. focus on communication related interactions, the intangible service elements of the PS have influence on matter and energy flows as well. An example is an online shopping service for customization components that facilitates customers to order products more frequently in consequence more products have to be transported. The influences of PS on matter and energy flows are also a key concern of environmental impact assessment done using Life Cycle Assessment (LCA). Value co-creation. The customer of a service is involved in the value creation of the same service this principle is called value co-creation (Vargo et al., 2008). During usage, a specific service instance is created and consumed at the same time. Since creation and consumption take place at the same moment, service instances cannot be stored. Weak and strong relations. As in case of the FP, the elements that contribute to a PS can be weakly connected. This means that the PS keeps operating even though one element might be out of service. In other cases, the relation between two elements can be strong potentially resulting in severe consequences if one element stops working. Product- and service-dominant modelling. As the business environment of the use cases (and probably other companies as well) can be more or less familiar with services, the starting point of a combined lifecycle model is context-dependent. While traditional manufacturers are more familiar with the product-side, the product can be seen as more important for these companies. Copyright Manutelligence Consortium Page 28 / 57

29 On the opposite, a company traditionally offering services to customers might focus more on the service-side. These two extremes build up a continuum ranging from a product-dominant to a service-dominant perspective. 3.3 Conclusion The described perspectives on lifecycle models represent a first systematic analysis of the lifecycle concept as such. In this context, an important logical conflict of LCMs is highlighted and a solution proposed (i.e. multi-lifecycle models). As a consequence, the introduction of multi-lifecycle models will stress the importance of relations between different processes. Relations, especially those between products and services, as well as items and classes have to be considered in lifecycle modelling. The resource efficiency perspective is important for ecological and economic impact assessment, while the information management perspective is relevant for the coordination of distributed, concurrent lifecycle processes. The following requirements for lifecycle modelling are based on the above-mentioned perspectives. The following list is a draft that has to be consolidated during the project (e.g. depending on the application in the use cases). Consolidation may concern the adaption of existing requirements and addition of new ones. - Matter, energy and information flows must be represented - Matter, energy and information stocks must be represented - Processes and stakeholders must be represented - Class and instance separation on product and stakeholder level must be possible - Multiple lifecycles must be represented - Product states must be described - Sequencing of processes must be supported - Relations between lifecycle elements are different in their intensity - Business models (of PSS) must be credited While these requirements are derived from the perspectives on the lifecycle, their actual relevance for Manutelligence depends on the use cases and the targeted PSs. Therefore, the requirements list has to be considered as a preliminary list that is adapted in the ongoing work of WP2. Copyright Manutelligence Consortium Page 29 / 57

30 4 Combined lifecycle modelling This chapter will outline the approach used in Manutelligence to model combined lifecycles for products and services. 4.1 Purpose of the approach The approach that has to be applied in Manutelligence is a formal method to describe assets, activities and relations along the lifecycle. Since the lifecycle models described in Section 2 contain less than 20 elements, their level of detail is most likely too low to contain all the relevant perspectives on the lifecycle. Therefore, a more comprehensive approach is selected that is based on formal description of the lifecycle and all related and relevant elements (that depend on the use cases). In Manutelligence, the description of elements is done by applying and adapting existing modeling languages. An example for such a language is the Lifecycle Modeling Language (LML). Formal modeling serves as a basis for T2.2, where actual data, information and knowledge assets, as well as related flows are described. Since LML is a top-level standard with high flexibility, specific domains are not covered by it in particular. One of these domains is the Internet of Things a concept that is fundamental for the creation and communication of feedback information about product and service usage. Therefore, LML has to be complemented by more specific standards. Two examples of relevant standards are published by The Open Group Internet of Things (IoT) Work Group (The Open Group, 2015). - Open Data Format (O-DF) - Open Messaging Interface (O-MI) 4.2 Lifecycle Modeling Language The following sections will present LML briefly. Information about all the supported classes and visualization techniques are not covered in detail in this deliverable Overview LML is based on the Model-Based Systems Engineering (MBSE) approach (Lifecyclemodeling.org, 2015). MBSE is [ ] the formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases. MBSE is part of a long-term trend toward model-centric approaches adopted by other engineering disciplines, including mechanical, electrical and software. In particular, MBSE is expected to replace the document-centric approach that has been practiced by systems Copyright Manutelligence Consortium Page 30 / 57

31 engineers in the past and to influence the future practice of systems engineering by being fully integrated into the definition of systems engineering processes. (Object Management Group, 2015). LML was designed to meet the following six key requirements: 1. To be easy to understand, 2. To be easy to extend, 3. To support both functional and object oriented approaches within the same design, 4. To be understandable by most stakeholders, not just System Engineers, 5. To support systems from cradle to grave, 6. To support both evolutionary and revolutionary changes to system plans and designs over the lifetime of a system. LML integrates knowledge from disciplines like program management, systems and design engineering, testing, deployment and maintenance. Its basis is an entity, relationship and attribute meta-model. The remainder of this section is based on version 1.0 of the LML specification that was published in October The full specification of LML is publicly available online ( Key elements and features of LML LML contains an extensive description of the different elements of the language and visualization techniques. The most important fundamental elements are described briefly in this section. As the basis of LML is an extended entity-relationship model, there are three basic elements: Table 8: Basic elements of LML Element name Equivalents Description Entity Noun Something that exists by itself and is uniquely identifiable. Attribute Adjective Inherent characteristic or quality of an entity or relationship. Relationship Verb Connection between entities. Besides these basic elements, LML supports different attribute data types commonly used in lifecycle activities. The supported data types are summarized in the following list: - Text - Number - Boolean - Percent - DateTime - URI (Uniform Resource Identifier) - Enumeration (set of defined choices, where only one option is permitted) - GeoPoint Copyright Manutelligence Consortium Page 31 / 57

32 Another concept implemented into LML is inheritance. By applying inheritance, new entities can be created that share characteristics with their parent entities. An example is the child entity Resource that is based on the parent entity Asset. A summary of specified LML entities is provided in Figure 17 (excerpt). Figure 17: Excerpt of the LML Entities In order to utilize the LML elements, visualization techniques are needed. The LML specification suggests several standard techniques for illustration only one is newly introduced called Action Diagram. Each of the illustration techniques aims to highlight a certain aspect of the modelling. 4.3 Comparison of requirements and LML features In order to find out how suitable the existing LML specification is for combined lifecycle modelling, the features of LML are compared with the requirements defined in Section 3.3. Table 9 summarizes the comparison. Table 9: Comparison of modelling requirements and features of LML Requirements Features Copyright Manutelligence Consortium Page 32 / 57

33 Matter, energy and information flows must be represented Matter, energy and information stocks must be represented Processes and stakeholders must be represented Class and instance separation on product and stakeholder level must be possible Multiple lifecycles must be represented Input/Output, Conduit (Connection) Resource Action (as process), Asset (as organization) Hierarchy Diagram, Timelines This is a matter of modelling. Connections/Conduits could be used to create connected lifecycles (including-closed loop structures). State Machine Diagram Action Diagram, Timelines Intensity of relations could be modeled so that a Connection/Conduit is selected based on a Decisions. Product states must be described Sequencing of processes must be supported Relations between lifecycle elements are different in their intensity Business models (of PSS) must be credited The business model could be expressed through Requirements and Statements that result in Decisions. The decisions can affect LML classes are in italic. The comparison of requirements and features shows that the preliminary requirements can be addressed with the existing LML elements. However, the actual implementation will most likely introduce new problems and challenges for modelling that need to be addressed. 4.4 Conclusion Lifecycle modelling using LML is a promising approach to describe combined lifecycle models at least from the theoretical point of view that is taken in this deliverable. So far, the main requirements resulting from the different perspectives on the lifecycle are covered by LML. Any other conceptual findings (e.g. multi-lifecycle modelling) must be realized by the actual modelling of the lifecycles. The findings in section 2 provide a list of processes that must be taken into account during the modelling process. Depending on the targeted PSs of each use case, the listed processes have to be checked for relevance. Those processes that are considered relevant for a use case should be modeled with LML. The detail of modelling should be estimated based on the use case and the requirements of the LCA and LCC methodologies (see Manutelligence WP 5). The ranking helps to identify weakly covered aspects that might be of interest in the future (e.g. monitoring and feedback analysis in case of services, and testing in case of products). Copyright Manutelligence Consortium Page 33 / 57

34 Lifecycle processes Coverage Lifecycle processes Coverage Reuse, remanufacturing, recycling, disposal 90 Implement and measure 73 manufacturing 88 Concept development and evaluation 64 use 77 Requirements generation 55 Design 45 Requirements analysis 55 procurement/sourcing, distribution, logistics 34 Final design 55 Ideation, Requirements, Conceptualization 30 Detailed design 45 Raw material extraction 26 Middle of life 36 maintenance, repair, overhaul, service 26 Requirements identification 27 primary industry, bulk material processing 25 Concept generation and evaluation 27 assembly 19 Embodiment and evaluation 27 marketing, sales, retail 16 Test (Prototyping/Simulating) 18 prototyping, testing 12 End of Life support models were analyzed in total Monitoring and Evaluation 9 Monitoring and feedback analysis 0 11 models were analyzed in total Figure 18: Summary of potentially relevant processes for combined lifecycle modelling The actual implementation in the use cases and thus in a real PS context will most likely result in new requirements and challenges. As LML is a flexible top-level language (i.e. addresses a broad range of problems), more specific issues have to be addressed with specific techniques as well. Copyright Manutelligence Consortium Page 34 / 57

35 5 Guiding Example using LML This section contains a guiding example for LML in relation to combined modelling. The example is fictional and not related to any of the Manutelligence use cases. The example concerns a repair service for mass-produced bicycles. The combined lifecycle aspects, that are going to be modeled, take the product-side and the service side into account. A first formal description of the example case is the structure of the product. In LML this can be achieved by a Hierarchy diagram for assets, i.e. parts of a bike are described by a taxonomy. A Hierarchy Diagram for assets is illustrated in Figure 19. Figure 19: Hierarchy Diagram (class-level) In order to describe the example case further, a combination of a hierarchy diagram and a timeline is used. The combination is not specifically mentioned in LML. An illustration of the combined diagrams is provided in Figure 20. Figure 20: Combination of Hierarchy Diagram (item-level) and timeline (Gantt) The left side of the figure contains a hierarchy for the product and the service. Special about this diagram is that it focuses on the item-level, i.e. specific parts and services are described. On the right side, a variant of a timeline is shown. In this particular case, each item has its own timeline. Timelines are separated into important lifecycle phases stated as BOL, MOL and EOL. Phases can be substituted by processes to increase the level of detail (see Figure 18). Not all Copyright Manutelligence Consortium Page 35 / 57

36 timelines are synchronous, i.e. lifecycle phases do not necessarily share the same start and end points the timeline depends on the destiny of each individual item. In order to model the PS, a breakdown of the bicycle s rear tire is assumed that triggers the service request by the user. The repair service remains in the BOL phase as long as it is not requested by the user. Once a call is received by the service provider (A), a new tire is ordered or taken from stock (B). A service technician is taking the new tire and exchanges the old one (C). The old tire is taken back by the service provider and disposed (D). Finally, the payment for the service is completed (E). A summary of the actions is provided as a timeline in Figure 21. Figure 21: Timeline (actions) A more detailed representation of the necessary actions for the PS is provided through an LML Action Diagram as illustrated in Figure 22. Figure 22: Action Diagram of a product service The diagram contains different actions and related input/output entities describing the repair service once it is requested by the user. Starting point of the chart is the service call of the user. Two processes run in parallel: a) the check whether the replacement tire is available or not and b) the organization of the payment (e.g. gathering name, address and banking account). In case the warehouse does not contain any suitable tires, a new order must be placed before the service can be realized. During the exchange activity a tire is consumed and an old one produced. The take back of the old tire completes the payment process. After payment, the tire is subject of an EOL decision either refurbishing or recycling of the product. For this decision an assembly Copyright Manutelligence Consortium Page 36 / 57

37 plan is needed to estimate the difficulty of a potential recycling process. In case of recycling, additional processes have to be conducted where the old tire is transformed into parts. Finally, any parts or refurbished products are sold on the market. The Action Diagram describes how the repair service is performed on a functional level (i.e. including actions and input/outputs). In this example, actions concern the on-site actions taking place close to the user (e.g. call and exchange of tire), back-office actions such as payment and EOL decision-making, as well as production actions such as disassembly and separation of parts. An overview about different elements (e.g. assets, artifacts and actions) is provided by a Spider Diagram. Figure 23 contains several different elements and their relations among each other. Figure 23: Spider Diagram The relations are based on the LML open standard. Complementary to the Action Diagram, this diagram type provides information about the assets and artifacts used in the example. Design documents, for instance are produced by a design process and used during the repair action they contain the BOM, assembly plan and CAD model. Also the relation of technicians and the accounting office are illustrated in the diagram. The example presented in this section is only a brief demonstration how different aspects of PSs can be modeled and visualized for the purpose of lifecycle management. The actual use cases will most likely need more details to describe the targeted PS in a comprehensive way. Copyright Manutelligence Consortium Page 37 / 57

38 6 Methods used in service engineering In order to help use case partners to develop their own product-service portfolio, a set of existing methods used in PSS engineering is provided in this section. Cavalieri and Pezzotta identified frequently used methods in the PSS literature (Cavalieri and Pezzotta, 2012). Indeed, different methods or methodologies are applied into different service development phases in order to develop services. All the phases are covered by at least one method/methodology; some of them are covered by more methods/methodologies. Below, a list reported the methods. Quality Function Deployment (QFD) supports mainly requirements related phases (requirements generation, identification and analysis). It enables to design a product or a service, translating customer requirements into engineering characteristics, in order to hit customer s needs. (Fisher and Schutta, 2003; Geng et al., 2010). Ever for requirements generation and identification, it is possible to use the Critical Incident Technique (CIT) or the Sequential Incident Technique (SIT), in order to use a procedure for collecting respondents previous observation and then classifying them (Goldstein et al., 2002), or to identify in which steps customers and suppliers are directly in contact (Luczak et al., 2007). TRIZ is used during the requirement analysis and the concept development and evaluation. It enables to identify, generate and evaluate possible solutions to service problems (Chai et al., 2005). Analytic Network Process (ANP) or Analytic Hierarchical Process (AHP) are used for the requirement analysis and the concept development and evaluation, like TRIZ. They allow to evaluate new service concepts (Lee et al., 2010) or to determine the initial importance weights of engineering characteristics, considering the complex dependency relationships between and within customer requirements, product and service engineering characteristics (Geng et al., 2010). Pairwise comparisons method is used during the requirement generation and identification or during the concept development and evaluation. The main goal of the method is to prioritize customer s requirements, giving a rating of engineering characteristics final importance (Geng et al., 2010; Lee et al., 2010). Service Blueprinting is used during final design steps (embodiment, detailed and final design) to: o Clarify the influence of service processes on the receiver (Hara et al., 2009). o Model all processes, action and interactions inside and outside the company (Boughnim and Yannou, 2005). o Transfer function into service processes (Luczak et al., 2007). Service Blueprinting is a technique used for service innovation. It defines: o Customer Actions: Steps that customers take as part of the service delivery process. Copyright Manutelligence Consortium Page 38 / 57

39 o Front-stage (Visible Contact Employee) Actions: This element is separated from the customer actions by a line of interaction. These actions are face-to-face actions between employees and customers. o Backstage (Invisible Contact Employee) Actions: The line of visibility separates the on-stage from the backstage actions. Everything that appears above the line of visibility can be seen by the customers, otherwise it is invisible for the customers. o Support Processes: The internal line of interaction separates the contact employees from the support processes. These are all the internal services, phases and interactions needed to support contact employees to deliver service. o Physical Evidence: The physical element is the top layer of the service blueprint and represents the physical evidence that the customer came in contact with the organization. These influence quality perceptions of the customer. (Shostack, 1984). Failure Mode and Effect Analysis (FMEA) is used during the prototyping/simulating, in order to provide a detailed analysis of potential risks associated with service delivery processes (Luczak et al., 2007). Functional Analysis, used during detailed design and test, allows to map all the solution s elements, detailing and linking both physical elements and service units (Maussang et al., 2008). ServQual is used during the concept evaluation and the implementation and measure, to uncover different kinds of gaps in the service offers and to explain the perceived quality of service as deviation between expected service outcomes and perceived service outcomes (Becker et al., 2010). ServQual is an acronym for Service Quality and it is a methodology to measure perceptions of the quality of service across five dimensions: tangibles, reliability, responsiveness, assurance and empathy. The methodology is also called Rater, the acronym of the five factors of service quality (Zeithaml et al., 1990). Tangibles would include those attributes pertaining to physical items such as equipment, buildings, and the appearance of both personnel and the devices utilized to communicate to the consumer. Reliability relates to the personnel s ability to deliver the service in a dependable and accurate manner. The desire and willingness to assist customers and deliver prompt service makes up the dimension of responsiveness. Knowledgeable and courteous employees who inspire confidence and trust from their customers establish assurance. Finally, Empathy is the caring and personalized attention the organization provides its customers. The main criticism to ServQual methodology is that few researches validated the measuring tool (Nyeck et al., 2002). Table 10 summarizes how the abovementioned methods match activities in service development. Copyright Manutelligence Consortium Page 39 / 57

40 Table 10: Methodologies used in the service development To support of such PSS systems, information systems like PLM are often utilized and implemented. However, PLM systems are primarily designed to manage products. Tools and methodologies for services are often isolated applications without integration in PDM/PLM solutions. Therefore, it is necessary to redesign the PLM systems models, in order to take into account services (Zinke et al., 2013). A ½ day workshop was held at the General Meeting in Milan (25 th to 26 th June) to start the PS development process. The workshop contained an introduction of the PS concept, mostly dedicated to the use case partners, and a collaborative session. During the collaborative session, four groups (one per use case) were built. Each group developed ideas for potential PSs. Copyright Manutelligence Consortium Page 40 / 57

41 7 Conclusion For this deliverable, two surveys on lifecycle models were initially conducted to gain insight into the state of the art of lifecycle models. While one survey focused on the vast body of literature containing product lifecycle models, the second one addressed service and productservice lifecycle models. Based on the findings, important perspectives on the lifecycle were derived and described. These perspectives highlight aspects that have to be taken into account when modelling lifecycles. The perspectives were used to express requirements for the modeling approach that will be further used to describe combined lifecycles of services and products. With the modelling technique (LML) and the service engineering techniques (Section 6) at hand, processes and stakeholders, as well as different flows can be described in a uniform way respecting the most relevant perspectives on lifecycle models (both for services and products). In the upcoming Tasks of WP2, the LML language (and potentially other more specific techniques) will be used to describe the data, information and knowledge types that must be considered for combined lifecycle management. For the ongoing work in WP2 the work will be carried on following the process described in Figure 24. Figure 24: Planned procedure for Task 2.2 Copyright Manutelligence Consortium Page 41 / 57

42 8 References Aurich, J.C., Fuchs, C., Wagenknecht, C., Life cycle oriented design of technical Product-Service Systems. J. Clean. Prod. 14, doi: /j.jclepro Becker, J., Beverungen, D.F., Knackstedt, R., The challenge of conceptual modeling for product service systems: status-quo and perspectives for reference models and modeling languages. Inf. Syst. E-Bus. Manag. 8, Borsato, M., Bridging the gap between product lifecycle management and sustainability in manufacturing through ontology building. Comput. Ind. 65, doi: /j.compind Boughnim, N., Yannou, B., Using Blueprinting Method For Developing Product-Service Systems. Presented at the International conference of Engineering Design (ICED). Bullinger, H.-J., Warschat, J., Concurrent simultaneous engineering systems: the way to successful product development. Springer. Cavalieri, S., Pezzotta, G., Product Service Systems Engineering: State of the art and research challenges. Comput. Ind. 63, doi: /j.compind Chai, K.-H., Zhang, J., Tan, K.-C., A TRIZ-based method for new service design. J. Serv. Res. 8, Deutsches Institut für Normung e.v., Service Engineering: entwicklungsbegleitende Normung (EBN) für Dienstleistungen, 1. Aufl. ed, DIN-Fachbericht. Beuth, Berlin. Dyckhoff, H., Spengler, T.S., Typologie industrieller Produktionssysteme, in: Produktionswirtschaft. Springer Berlin Heidelberg, Berlin, Heidelberg, pp Fisher, C.M., Schutta, J.T., Developing New Services: Incorporating the Voice of the Customer Into Strategic Service Development. Asq Press. Främling, K., Holmström, J., Loukkola, J., Nyman, J., Kaustell, A., Sustainable PLM through Intelligent Products. Eng. Appl. Artif. Intell. Geng, X., Chu, X., Xue, D., Zhang, Z., An integrated approach for rating engineering characteristics final importance in product-service system development. Comput. Ind. Eng. 59, Goldstein, S.M., Johnston, R., Duffy, J., Rao, J., The service concept: the missing link in service design research? J. Oper. Manag. 20, Hara, T., Arai, T., Shimomura, Y., Sakao, T., Service CAD system to integrate product and human activity for total value. CIRP J. Manuf. Sci. Technol., Life Cycle Engineering 1, doi: /j.cirpj Kiritsis, D., Closed-loop PLM for intelligent products in the era of the Internet of things. Comput.-Aided Des. 43, doi: /j.cad Kotler, P., Connor Jr, R.A., Marketing professional services. J. Mark Kubler, S., Derigent, W., Främling, K., Thomas, A., Rondeau, É., Enhanced Product Lifecycle Information Management using communicating materials. Comput.-Aided Des. 59, doi: /j.cad Lee, H., Kim, C., Park, Y., Evaluation and management of new service concepts: An ANP-based portfolio approach. Comput. Ind. Eng. 58, Lifecyclemodeling.org, Lifecycle Modeling Language [WWW Document]. Simple Ontol. Common Graph. Not. Makes Des. Make Sense. URL (accessed ). Lindahl, M., Sundin, E., Sakao, T., Shimomura, Y., Integrated product and service engineering versus design for environment A comparison and evaluation of advantages and disadvantages, in: Advances in Life Cycle Engineering for Sustainable Manufacturing Businesses. Springer, pp Copyright Manutelligence Consortium Page 42 / 57

43 Lindström, J., Dagman, A., Karlberg, M., Functional Products lifecycle: Governed by sustainable win-win situations. Procedia CIRP 22, Luczak, H., Gill, C., Sander, B., Architecture for service engineering the design and development of industrial service work, in: Advances in Services Innovations. Springer, pp Maussang, N., Zwolinski, P., Brissaud, D., Evaluation of product-service systems during early design phase, in: Manufacturing Systems and Technologies for the New Frontier. Springer, pp Nyeck, S., Morales, M., Ladhari, R., Pons, F., years of service quality measurement: reviewing the use of the SERVQUAL instrument. Bi-Annu. Acad. Publ. Univ. ESAN 7, December Object Management Group, Model-Based Systems Engineering Wiki [WWW Document]. URL (accessed ). Oliva, R., Kallenberg, R., Managing the transition from products to services. Int. J. Serv. Ind. Manag. 14, doi: / Philips N.V., n.d.. Philips Light. URL (accessed ). Pigosso, D.C.A., Zanette, E.T., Filho, A.G., Ometto, A.R., Rozenfeld, H., Ecodesign methods focused on remanufacturing. J. Clean. Prod. 18, doi: /j.jclepro Qureshi, A.J., Gericke, K., Blessing, L., Stages in Product Lifecycle: Trans-disciplinary Design Context. Procedia CIRP, 24th CIRP Design Conference 21, doi: /j.procir Sakao, T., Shimomura, Y., Service Engineering: a novel engineering discipline for producers to increase value combining service and product. J. Clean. Prod. 15, Shostack, G.L., Designing services that deliver. Harv. Bus. Rev. 62, The Open Group, The Open Group Internet of Things (IoT) Work Group [WWW Document]. URL (accessed ). Van Ostaeyen, J., Van Horenbeek, A., Pintelon, L., Duflou, J.R., A refined typology of product service systems based on functional hierarchy modeling. J. Clean. Prod. 51, doi: /j.jclepro Vargo, S.L., Lusch, R.F., Evolving to a new dominant logic for marketing. J. Mark Vargo, S.L., Maglio, P.P., Akaka, M.A., On value and value co-creation: A service systems and service logic perspective. Eur. Manag. J. 26, doi: /j.emj Wellsandt, S., Hribernik, K., Thoben, K.-D., Sources and characteristics of information about product use, in: CIRP Procedia. Presented at the CIRP 25th Design Conference: Innovative Product Creation, Elsevier B.V., Haifa, Israel, p. in press. Wetzel, L., Types and Tokens. Wiesner, S., Freitag, M., Westphal, I., Thoben, K.-D., Interactions between Service and Product Lifecycle Management. Procedia CIRP, 7th Industrial Product-Service Systems Conference - PSS, industry transformation for sustainability and business 30, doi: /j.procir Wuest, T., Hribernik, K., Thoben, K.-D., Accessing servitisation potential of PLM data by applying the product avatar concept. Prod. Plan. Control Wuest, T., Irgens, C., Thoben, K.-D., An approach to monitoring quality in manufacturing using supervised machine learning on product state data. J. Intell. Manuf. 25, Zeithaml, V.A., Parasuraman, A., Berry, L.L., Delivering quality service: Balancing customer perceptions and expectations. Simon and Schuster. Zinke, C., Meyer, L.-P., Meyer, K., Modeling Service Life Cycles within Product Life Cycles, in: Collaborative Systems for Reindustrialization. Springer, pp Copyright Manutelligence Consortium Page 43 / 57

44 9 Annex The section will provide first definitions for important terms and concepts of Manutelligence (not necessarily for this deliverable). Definitions are based on literature and complemented by the experience of the project partners. The glossary is an annex of D2.1 and will be extended on a continuous basis. 9.1 Glossary Term/Concept Product Service Service-dominant logic approach Business ecosystem Description/Definition A product is a tangible commodity manufactured to be sold. It is capable of falling onto your toes and of fulfilling a user s need. [1] any goods or service [2] A service is an activity (work) done for others with an economic value and often done on a commercial basis. In this project, we include work done by human beings as well as by automated systems. [1] "A service is an activity or benefit that one party can offer to another that is essentially intangible and does not result in the ownership of anything. Its production may or may not be tied to a physical product." [2] "A service is an activity or series of activities of more or less intangible nature that normally, but not necessarily, take place in interactions between the customer and service employees and / or physical resources or goods and / or systems of the service provider, which are provided as solutions to customer problems. [3] We define services as the application of specialized competences (knowledge and skills) through deeds, processes, and performances for the benefit of another entity or the entity itself. [4] Moore defines business ecosystem as an economic community supported by a foundation of interacting organizations and individuals the organisms of the business world. According to Moore, a business ecosystem includes customers, lead producers, competitors, and other stakeholders. The key to a business ecosystem are leadership companies, the keystone species, who have a strong influence over the co-evolutionary processes. Moore states that these are just metaphors which can clarify certain issues and help understanding them. [5] As a conclusive definition we consider a business ecosystem to be a dynamic structure which consists of an interconnected population of organizations. These organizations can be small firms, large corporations, universities, research centers, public sector organizations, and other parties which influence the system. In different texts, business ecosystem is defined either consisting of several organizations or of only one organization. In the latter, individual organization should operate as an ecosystem, in order to survive. We define business ecosystem to contain a population of organizations. If we follow the principles of complexity business ecosystem should be self-sustaining. This means that no government interventions would be needed in order to survive in local or global markets. Business ecosystem develops through self-organization, emergence and co-evolution, which help it to acquire adaptability. In a business ecosystem there is both competition and cooperation present simultaneously. [6] Copyright Manutelligence Consortium Page 44 / 57

45 Product system Fitness for purpose Upgradability Product-Service Product-Service- System Industrial Product-Service- System The MSE is a non-hierarchical form of collaboration where various different organizations and individuals work together with common or complementary objectives on new value added combinations of manufactured products and product-related services. This includes the promotion, the development and the provision of new ideas, new products, new processes or new markets. Future Internet architectures and platforms enable the active participation of all stakeholders in all the phases of the product and service life cycle. The customer is part of the MSE, allowing for collaborative ideation and research in the ecosystem, based on the customer s requirements. The later steps of service innovation, like development, manufacturing and provision of the EP, are supported through the formation of a Virtual Manufacturing Enterprise (VME) structure (1). The VME flexibly adapts to changing requirements and can incorporate new partners from the MSE. Should a required service (2) or competency (3) not be available in the MSE, its permeable border allows for extension of the ecosystem. In addition, the broad variety of the ecosystem support the look beyond the own backyard. Thus, an EP 2.0 of interoperable products and services can be configured through the MSE members. Service innovation within the MSE is enabled via ICT through a Service Oriented Architecture (SOA) and the Digital Business Ecosystem (DBE) concept. SOA supports the processes and workflows in a Business Ecosystem through dynamic, on-the-fly compositions of the available ICT services. DBE amends the Business Ecosystems with a pervasive Internetbased environment, showing an evolutionary and self-organizing behavior. [7] collection of materially and energetically connected unit processes which perform one or more defined functions [8] ability of a product, process or service to serve a defined purpose under specific conditions [8] characteristic of a product [ ] that allows its modules or parts to be separately upgraded or replaced without having to replace the entire product [8] The Product service (PS): a mix of tangible products and intangible service designed and combined so that they are jointly capable of integrated, final customer needs. [9] A Product Service system (PS system) is a marketable set of products and services capable of jointly fulfilling a user s need. The PS system is provided by either a single company or by an alliance of companies. It can enclose products (or just one) plus additional services. It can enclose a service plus an additional product. And product and service can be equally important for the function fulfilment. The researcher s need and aim determine the level of hierarchy, system boundaries and the system element s relations. [1] A PSS is an integrated product and service offering that delivers value in use. A PSS offers the opportunity to decouple economic success from material consumption and hence reduce the environmental impact of economic activity. The PSS logic is premised on utilizing the knowledge of the designer-manufacturer to both increase value as an output and decrease material and other costs as an input to a system. [10] An Industrial Product-Service System is characterized by the integrated and mutually determined planning, development, provision and use of product and service shares including its immanent software components in Business-to-Business applications and represents a knowledge-intensive socio-technical system This means in detail: Copyright Manutelligence Consortium Page 45 / 57

46 An IPS2is an integrated product and service offering that delivers values in industrial applications. IPS2is a new product understanding consisting of integrated product and service shares. IPS2comprises the integrated and mutually determined planning, development, provision and use. IPS2includes the dynamic adoption of changing customer demands and provider abilities. The partial substitution of product and service shares over the lifecycle is possible. This integrated understanding leads to new, customer-adjusted solutions. Functional Product IPS2enable innovative function-, availability- or result-oriented business models. [11] A close concept to services is functional economy or functional sales (Mont 2004): In Functional sales the unit of transaction is a function of a product, not the product per se. For example, instead of paying per copy machine, customers pay per number of copies made. In functional sales the cost of the use phase becomes transparent, since customers pay per use/function. [12] Functional P = products, also known as total care products, are products that comprise combinations of hard and soft elements. Typically, they are described as comprising hardware combined with a service support system. The hardware element is clearly understood and is typified by the vast range of equipment presently on offer for sale to customers. The service support system is much more than the maintenance of the product and can include decision-making and operations planning, remanufacture and education. The customer purchases a function and the hardware plus service includes the totality of activities that enable the customer to benefit from a total functional provision. Software will also be a part of the functional product and is assumed to be integral with hardware (where appropriate) and the service support system. [13] Figure 25: Five states of service design Newer and more detailed definition [14]: Copyright Manutelligence Consortium Page 46 / 57

47 Figure 26: Emerging Functional Product hardware constituents Figure 27: Emerging Functional Product software constituents Figure 28: Emerging Functional Products service support system constituents Copyright Manutelligence Consortium Page 47 / 57

48 Figure 29: Emerging Functional Product management of operation constituents Extended Product The last part of the discussions refers to the attempt to define the term extended product. The new extended product includes: A combination of a physical product and associated services/enhancements in order to improve the marketability. Tangible extended products, which can be intelligent, highly customised, user-friendly and include embedded features like maintenance Intangible extended products, which are information and knowledge intensive and can consist of services, engineering, software, etc. Collaboration refers to both material and information flows in order to accelerate the cooperation within the value chain. The customer is not anymore looking for physical products but rather focuses on the benefit out of a value-adding service. Communication technology is available for the support of such complex inter-enterprise service networks. Altogether, this causes a new view on the product emphasising the utility of the package (product and services) instead of the product itself. [15] Core Product Tangible Product Non-tangible Product Kernel of Product Product Shell Services Including Materials and Technical Functions of a (Tangible) Product Including the Packaging of the Core Product Intangible Surroundings of the Tangible Product Product in a Narrow Sense (Tangible Entity to be Offered to the Market) E-Commerce Product in a Broader Sense (Product Solution, consisting of tangible as well as Intangible Assets) Copyright Manutelligence Consortium Page 48 / 57

49 Figure 30. Layered model of extended product [16] Evolving the Traditional Concept of a Product Core Product Tangible Product Tangible and Intangible Product Assets 39 % 39 % 32 % 32 % Manufacturing of Parts Offering of Products / Systems Offering of Solutions Provision of Benefits Shift of Business Focus Figure 31. Evolving into an extended product [17] Product-Service Bundle Cyber-Physical System Intelligent Products A set of service elements, which can be provisioned together is called a service bundle. [18] Cyber-Physical Systems (CPS) are integrations of computation with physical processes. Embedded computers and networks monitor and control the physical processes, usually with feedback loops where physical processes affect computations and vice versa. [19] The term cyber-physical systems (CPS) refers to a new generation of systems with integrated computational and physical capabilities that can interact with humans through many new modalities. The ability to interact with, and expand the capabilities of, the physical world through computation, communication, and control is a key enabler for future technology developments. [20] Together, these dimensions lead to a three-dimensional classification model for Intelligent Products, which covers all the main aspects of the field. This classification model is shown in Fig. 2[6]. [21] Copyright Manutelligence Consortium Page 49 / 57

50 Servitization Life cycle (engineering) Lifecycle phase Figure 32: Classification model of Intelligent Products Modern corporations are increasingly offering fuller market packages or bundles of customer-focussed combinations of goods, services, support, self-service, and knowledge. But services are beginning to dominate. [22] The process of creating value by adding services to products. consecutive and interlinked stages of a product system, from raw material acquisition or generation of natural resources to the final disposal [8] The lifecycle is divided into subsequent phases most commonly stated as beginning of life (BOL), middle of life (MOL) and end of life (EOL). Each phase consists of several lifecycle activities. For (physical) products: BOL: typically consists of the design and realization of the product. Realization can include production (e.g. smelting, machining) and assembly (integrating complete components). Transition from BOL to MOL: the moment the product is provided to the user [23]. User and customer (purchaser) can be separate persons, e.g. in case of pay-per-use scenarios. MOL: typically consists of the product s usage and related service activities (e.g. maintenance and repair) Transition from MOL to EOL: the moment the product no longer satisfies the first targeted user(s) [24]. Before other users can use the product, it enters the EOL and a decision has to be made about the desired EOL-scenarios. EOL: typically consists of several optional activities. Most common are: Product reuse by other customer (second hand), Upgrading, Downgrading, Remanufacturing (refurbish used product), Component reuse, Material recycling, Disposal (incineration, landfill). Transition from EOL to MOL: the moment the same product is provided to the next user [25]. Transition from EOL to BOL: the moment where product components or recycled materials are supplied to the product realization activity. Copyright Manutelligence Consortium Page 50 / 57

51 Lifecycle activity Lifecycle process Product Lifecycle Management One of several subsequent, concurrent or alternative processes describing how an entity proceeds through the lifecycle. The relevant lifecycle activities depend on the target company, the target product/service type and instance (depending on context, activities might be relevant other not). Synonymous with lifecycle activity. The production engineering and ICT perspective towards PLM differs from the organizational and marketing perspective. In production engineering and ICT, PLM is commonly understood as a concept which seeks to extend the reach of PDM [ ] beyond design and manufacturing into other areas like marketing, sale and after sale service, and at the same time addresses all the stakeholders of the product throughout its lifecycle (Golovatchev and Budde, 2007). In doing so, PLM inherits a cross-functional nature over various domains, for example business, marketing and manufacturing (Garetti et al., 2005). Classic PDM functionality encompasses object, component and document management, classification and search functionality, change management and tools for system administration and configuration (Abramovici and Sieg, 2001). PLM consequently includes strategically modeling, capturing, exchanging and using information in all decision-making processes throughout the product lifecycle (Stark, 2011; Moorthy and Vivekanand, 2007). It implements an integrated, cooperative and collaborative management of product data along the entire product lifecycle (Terzi et al., 2007). [26] Copyright Manutelligence Consortium Page 51 / 57

52 Closed-Loop PLM The concept of closed-loop PLM gives us the opportunities to maximize the benefits of the lifecycle operations. To seize these opportunities, it is important to know what the whole product lifecycle activities consist of, how its information is created, used, and modified during the product lifecycle, and which lifecycle information affects the product lifecycle operation. Simultaneously, it must not be overlooked that several operational issues of BOL, MOL, and EOL that we have addressed are important to make more accurate analyzing and decisions on a real-time basis. Table 3 shows the overview of research issues on the closed-loop PLM in terms of type, visibility, product lifecycle, and research tools. To solve these operational issues, it requires the wide spectrum of engineering knowledge throughout the whole product lifecycle such as lifecycle engineering, information and system modeling, production management, design for X, information exchange and knowledge retrieval, operations research technique, product design knowledge and design support methods, production planning and scheduling in BOL, statistical methods for predictive maintenance in MOL, planning and management for EOL, and so on. [27] Item-Level PLM Quantum Lifecycle Management Figure 33: Illustration of information flows along the product lifecycle In contrast to traditional PLM, item-level PLM takes the entire lifecycle of an individual instance of a product or service (item) into account, beginning with its conceptualization and manufacturing, over its usage to its recycling or disposal. Thus item-level PLM can be seen as an extension of traditional PLM which consolidates the class- as well as instance-based view on products and services under one umbrella. Typical examples of how item-level PLM is applied in industry today cover predictive and intelligent maintenance (Schuh, et al. 2005), design for X (Kiritsis, Bufardi und Xirouchakis 2003) or recycling. All of these application areas require a seamless access to data, information and knowledge related to certain instances of products or services. [28] Web site of the Open Group IoT Work Group (formerly QLM Work Group): Copyright Manutelligence Consortium Page 52 / 57

53 Functional Product Lifecycle As in many of the lifecycle definitions, covered in the introduction, the below proposed lifecycle for FP is built up of similar phases, i.e.: planning (business case, business modelling, investigations, etc.), design/development, realization (manufacturing, final testing and operations planning, etc.), operations/usage (monitoring, maintenance, upgrades, remanufacturing, optimizations, potential downcycling, etc.) and end-of-life (disposal, destruction, recycling etc.). FP comprise four main constituents: HW, SW, SSS and MO, each with different lifecycle characteristics (length, nature, need and possibility for maintenance/upgrades, etc.) [2, 4]. [29] Figure 34: FP lifecycle from a perceived value perspective Functional unit Unit process Figure 35: FP lifecycle from a technical perspective quantified performance of a product system for use as a reference unit in a life cycle assessment study [8] smallest portion of a product system for which data are collected when performing a life cycle assessment [8] Copyright Manutelligence Consortium Page 53 / 57