D2.2 Concept for a Combined PLM/SLM Product-Service Lifecycle Management

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.2 Concept for a Combined PLM/SLM Product-Service Lifecycle Management Type Deliverable Document ID: D2.2 Workpackage: WP2 Leading partner: POLIMI Author(s): Laura Cattaneo, Sergio Terzi, Stefan Wellsandt Dissemination level: PU Status: Final Date: 18/07/2017 Version: 400 Copyright Manutelligence Consortium Manutelligence N

2 Versioning and contribution history Version Description Contributors 100 Table of Contents Laura Cattaneo 200 First Draft Laura Cattaneo, Stefan Wellsandt 300 Final Draft Laura Cattaneo, Stefan Wellsandt 400 Final Version Laura Cattaneo Reviewers Name Laura Calvo Louison Poudelet Affiliation FCIM FCIM Deliverable Peer Review Summary ID Comments Addressed (a) Answered (A) Few notes embedded in the text and some formal corrections. New scheme of Design Methodology (fig.1) with clearer image. A a Copyright Manutelligence Consortium Page 2 / 36

3 Table of Contents 1 Introduction and scope of this deliverable Objectives Structure of the deliverable Theoretical Background Product-Service System Lifecycle Model Methodology for PSS lifecycle oriented design Approach Activity 1: Business Model Design Activity 2: Requirements Definition Activity 3: IoT Capabilities Definition Lifecycle Modelling Practice Modelling domain knowledge Stakeholders and business processes Requirements and system components Cost and revenues Data, information and knowledge flows Data generation, storage and communication Methodology Application Ferrari case Business Model Design Requirements Definition IoT Capabilities Definition PSS lifecycle Model Lindbäcks case Business Model Canvas PSS lifecycle Model Conclusion References Copyright Manutelligence Consortium Page 3 / 36

4 1 Introduction and scope of this deliverable 1.1 Objectives The goal of the work described in this deliverable is to offer a design methodology for Product Service System (PSS), which takes into account the lifecycle perspective. Thanks to the analysis performed in Deliverable 2.1 ( Combined Lifecycle Model for Collaborative Product-Service Engineering ), we have identified existing Product Lifecycle Models, Service Lifecycle Models and Product-Service Lifecycle Models. Analysing the results, we have identified an important logical conflict of Lifecycle Models and we have proposed a solution: multi-lifecycle models. The introduction of multi-lifecycle models stresses 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. They have to be adapted from existing requirements depending on the application of the use case. 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. In order to identify data, information and knowledge to be managed, we performed different activities with a particular attention to the integration of Internet of Things (IoT) technologies. These preliminary activities are fundamental also to identify the knowledge domains and the knowledge requirements that should be taken into account. Data and information are collected to define the Lifecycle model. The approach that has to be applied in Manutelligence is a formal method to describe assets, activities and relations along the lifecycle. As we have reported in Deliverable 2.1, in Manutelligence the description of elements is done by applying and adapting existing modelling languages. An example for such a language is the Lifecycle Modelling Language (LML). Formal modelling serves as a basis for the work developed during Task 2.2 and described in this deliverable, where actual data, information and knowledge assets, as well as related flows are described. From the DoA Based on the formal method for modelling PS lifecycles and guidelines of collaborative engineering of PS lifecycles (D2.1) How we address it We will use LML and renown methods used for product design. Copyright Manutelligence Consortium Page 4 / 36

5 Data, information and knowledge types to be managed will be identified and analysed Actor s data, knowledge, and information generation, storage and communication will be mapped onto PS lifecycle model Information and knowledge requirements will be mapped onto PS lifecycle model. Knowledge domains will be taken into account Study of existing PLM and SLM approaches Study of use cases Information is refined into a holistic concept Could be derived from the IoT evaluation and the lifecycle models of Ferrari and Lindbäcks (including the product avatar). Could be derived from the lifecycle models. Generation is modelled as a sensor or manual process. Storage is modelled as a process. Communication is either modelled as a process or Conduit entity. Could be done by defining quality requirements for the models. It is necessary to build the models anyway. It is also part of the QFD approach to involve stakeholders from different domains. Done in D2.1. Done for Ferrari, Lindbäcks and FabLab The overall PSS design methodology should be extended to reflect a modular approach where different methods are combined while the lifecycle model is created concurrently Structure of the deliverable The deliverable is organized as follows: in Chapter 2, we propose a theoretical background, where the research statement is outlined, explaining the rational part of the research and introducing the proposed PSS design methodology. In Chapter 3 the methodology is explained in details, highlighting the different activities we propose to collect and manage data and information. In particular, we describe the different parts of the Lifecycle Model. In Chapter 4 the methodology is tested on the different use cases, i.e. Ferrari and Lindbäck. Chapter 5 outlines the research conclusions, putting in evidence some open issues and some critical aspects of the proposed methodology. Chapter 2, 3 and 4 (with some specific limitations about the use cases) have been presented as conference contributions, at the 23 rd International Conference of Engineering, Technology and Innovation (ICE/ITMC 2017). Copyright Manutelligence Consortium Page 5 / 36

6 2 Theoretical Background 2.1 Product-Service System A PSS is an integrated product and service offering that delivers value in use to the* customer. There are several potential benefits to PSS. First, there is an increase of revenues, because services tend to have higher profit margins and can provide a stable and countercyclical source of revenues. Second, they are means to differentiate offers in mass-markets, which are typically characterized by commodities and technologies. Last, services bring a decrease of variability and volatility of cash flow throughout the life of a product resulting in a higher shareholder value [1]. The business model of PSS is also promoted by the Internet of Things (IoT) technologies, which enable the introduction of new services related to the connectivity and the usage of environmental data. Connected products offer expanding opportunities for new functionality, greater reliability, higher product utilization and capabilities that cut across and transcend traditional product boundaries [2]. Terms like Cyber-Physical Systems (CPS), IoT and Virtual Reality have become ordinary in industries as everyday issues. IoT products raise a new set of strategic choices related to how value is created and captured, how the prodigious amount of data they generate is utilized and managed and what role companies should play as industry boundaries are expanded [2]. Product-Service System (PSS) is a complex matter, because it is composed of several parts that need to be handled: a product and one or more related services, a network of players and a supporting infrastructure [3]. The different product aspects, such as the concept and design phases and the lifecycle, have been analysed deeper by many authors [4], while the service topic is more recent and first attempts exist for structuring the service design [5]. Starting from the two studies conducted for T2.1 and described in D2.1, we have highlighted that the lifecycle concept is seen quite differently for products and services. The product-centric lifecycle concept is more material oriented and has a strong focus on activities before usage, especially design, production and maintenance, 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 are no commonly agreed standards on 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 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. 2.2 Lifecycle Model According to Wellsandt et al., a lifecycle model (LCM) describes the lifecycle of a product in a simplified way [6]. It contains elements that represent processes, stakeholders and flows of material, energy, and information. The elements are geometrically arranged, e.g. linear or circular shaped. A lifecycle model may integrate one or more lifecycles at once for instance, the lifecycle of a manufacturing machine and the created product. The complexity of a model depends on its purpose. The models investigated in [7], for instance, are mainly used to give an overview about different concepts discussed in the papers the models belong to. A lifecycle model with a much higher granularity is provided, for instance, by Anke, Wellsandt and Thoben [7]. The authors describe a lifecycle model that could be used in the course of a PSS design for a material replenishment service for 3D- Copyright Manutelligence Consortium Page 6 / 36

7 printers (in a theoretical case). Its purpose is to support stakeholders in understanding the effects of the interacting components of a PSS. From the literature the existence of some gaps emerges, since few models describe in detail how to identify and manage the key data to evaluate the PSS performance. Moreover, few models explain clearly and using step-bystep methodologies how to support companies in the utilization of IoT technologies. Thanks to the analysis performed during T2.1, we have identified an important logical conflict of LCMs and we have proposed a solution based on multi-lifecycle models. The introduction of multi-lifecycle models stresses 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. Copyright Manutelligence Consortium Page 7 / 36

8 3 Methodology for PSS lifecycle oriented design 3.1 Approach The main goals of the methodology is to structure the concept and design phase of the PSS and to identify the IoT technologies needed to catch and elaborate the useful data for the customer needs satisfaction. The idea is to connect different activities and methods, to elicit data and information. This methodology wants to be modular and the different activities performed are not mandatory and they do not need to be performed in a specific order. They allow managing multi-lifecycle models. In order to illustrate the methodology, three example activities will be covered in this deliverable. Within these three activities, we include elaborated techniques, such as the Business Model Canvas (BMC) and the Quality Function Deployment (QFD), as well as new tools like the definition of matrices used for identifying the IoT Capabilities. Figure 1 illustrates the three selected activities. Besides these three tasks there are other many important tasks to be considered, especially concerning the design of the actual solution components. The main three activities should be completed and integrated with other important information, as well as the addition of hard- and software functionalities and business processes. The lifecycle model is expressed with the Lifecycle Modelling Language (LML) [12]. LML is a derivative of the Systems Modelling Language (SysML) of the Open Group. Both are used to describe technical systems with formalized entities and relations. The specification of LML contains a formal description of concepts. These concepts and their relations are stored as an Ontology. The relations between concepts have different meanings, e.g. decomposed by or created by. Wellsandt, Anke and Thoben used LML in the context of PSSs conceptual design [7]. Figure 1: Design Methodology. Copyright Manutelligence Consortium Page 8 / 36

9 3.2 Activity 1: Business Model Design The goal of this activity is the definition of the PSS s Business Model. The Business Model will be designed through the use of the Business Model Canvas and the Value Proposition Canvas. The Business Model Canvas (BMC) is a method that assists a company in achieving a better business plan and it is described in the Business Model Generation book [8]. The Business Model Canvas enables the creation of a new Business Model or it improves an existing ones. Canvas elements are: Key partners, Key activities, Key resources, Value propositions, Customer segments, Customer relationships, Channels, Customer segments, Cost structure and Revenue stream. This information is necessary to construct the lifecycle model. A BMC template is illustrated in Figure 2. Figure 2: Business Model Canvas template. Supporting the Business Model Canvas, the Value Proposition Canvas [9] could be eventually developed, helping to create value for the customer. The Business Model Canvas and the Value Proposition Canvas are chosen in order to have a customer centric point of view, because the focus of the whole methodology should be the satisfaction of the customers needs. The output of Activity 1 is a Business Model at strategic level, which means having a view of: Who will be the actors, Which will be the product, Activities and services provided, Cost structure, Structure of the revenue streams. 3.3 Activity 2: Requirements Definition The goal of Activity 2 is to define the requirements derived from the Business Model Design step. In order to achieve this result, we decide to include the Quality Function Deployment (QFD) method [10]. QFD is a structured approach to define customer needs and translating them into product requirements. The basic QFD methodology involves four phases that occur over the course of the product development process. During each phase, one or more matrices are prepared to help communicate critical issues, process planning and design Copyright Manutelligence Consortium Page 9 / 36

10 information. Among these four phases, we use the first one, the Product Planning/Performance Requirements phase. This phase is also known as House of Quality (HoQ). It documents customer needs, which are then summarized in a product/planning matrix. The innovation of Activity 2 is the application of the HoQ to find the PSS requirements, so that some parts could be different from the classical HoQ, which typically involves only product specifications. The HoQ presented in this work has some peculiarities, in order to be suitable for the PSS characteristics. The parts composing the innovative HoQ are the following: Voice of the Customer. It documents a structured list of a product s customers requirements described in their own words. The list of requirements gathered in such an exercise must be structured before its entry into the HoQ Voice of the Company. It is also necessary to highlight the company s needs, for example data collectors, in order to develop suitable services. In some particular cases, the company could apply weights to the customers and to the company s needs, according to its goals. In our application, the Design Inputs part is divided between product technical requirements and service technical requirements. The new configuration permits to have a whole view on the Product-Service System. Product-Service Planning Matrix: this section forms the main body of the HoQ matrix and can be very time consuming to complete. Its purpose is to translate the requirements as expressed by the customer into technical characteristics of the product. Its structure is that of a standard matrix with cells that relate to combinations of individual customer needs and technical requirements. It is the task of the QFD team to identify where these interrelationships are significant. The inputs for the blocks of the HoQ come from the previous activity, particularly from the Value Proposition Building Block and the Key Resources Building Block, where the customers needs are defined at the strategic level. With the help of the HoQ, this information leads to the technical requirements and the engineering target values of the PSS. 3.4 Activity 3: IoT Capabilities Definition This activity represents the core part of the proposed methodology, since during this activity it is possible to define the bases for the Product-Service design phase. Three different processes could be simultaneously developed: the Product Design, the Service Design and the Product-Service Design. The outputs coming from these processes will be the Bill of Material of the product, the definition of the connected services and the identification of data, information and knowledge that should be managed and analysed during the Product- Service lifecycle. Smart products have three main components: physical components, smart components and connectivity components. Smart components are directly connected with services related to the physical parts, while connectivity allows to exchange information between the product and its operating environment and enables some services to exist outside the physical product itself [2]. Connect products require the design of a new technology infrastructure made up of multiple layers, therefore in order to properly design the PSS it is necessary to identify sensors, software, data storage, users interface as well as ports, protocols and kind of connections. In the meanwhile it is necessary to satisfy the stakeholders requirements derived from Activity 2. Usually the Product Design and the Service Design processes are separately developed, within different specialized team, which propose solutions that often are not really integrated. The innovation of the methodology aims to improve the integration between Product and Service Design in order to give to customers the best PSS solution. The methodology includes the classical System Engineering (Product Design) and Service Engineering Copyright Manutelligence Consortium Page 10 / 36

11 models (Service Design) [5, 11], which are led and integrated by an interdisciplinary group composed by product and service experts. Starting from the requirements defined in the previous phases, the team will implement the Product-Service Design with the primary aim of defining the IoT capabilities that should be integrate in the product lifecycle in order to properly design the connected services. Following the classification made in [2], the capabilities of smart product can be grouped into four areas: monitoring, control, optimization and autonomy. Monitoring: sensors and external data sources enable the monitoring of the product's conditions, the external environment and the product s usage. Monitoring also enables alerts and notifications of changes. Control: software embedded in the product enables control of product functions and personalisation of the customer experience. Optimization: monitoring and control capabilities enable algorithms that optimize product operations in order to enhance the performances and allow predictive diagnostics, services and repair. Autonomy: combine monitoring, control and optimization allows autonomous product operations, selfcoordination and self-diagnosis. Exploiting the Bill of Material, which is developed in the product design phase, we design a matrix structure for each product s systems and subsystems. The number of systems and subsystems automatically defines the number of levels and for each level we design a specific matrix (e.g. for a smart car, level 0: vehicle, level 1: Power Unit, Gear Box, Car Body, etc.). Figure 3: Matrix Example. For each level, the product s parts are reported as input for the designed matrix. The second axis includes data destination or the stakeholders who need a specific kind of information (real customer, companies teams-work and so on). Each matrix entry indicates if a specific part enables or not a specific service and, in the meanwhile, it indicates which IoT capability is activated, following the previous classification (Monitoring, Control, Optimization or Autonomy), as reported in Figure 3. A white box means that no IoT capabilities are defined for that entry. The IoT capability is selected in order to satisfy the product and service requirements. This classification is an important initial stage, since a specific IoT capability defines the correspondent technology to select, for example, sensors or data storage systems and clarify the kind of connection that must be developed. Copyright Manutelligence Consortium Page 11 / 36

12 3.5 Lifecycle Modelling Practice The approach applied in T2.2 uses LML as the common language to describe the PSS lifecycle. LML is an existing language derived from SysML. Further details about LML are provided in D2.1. In T2.2, the language was applied on PSS without changing its specification (version 1.1). Shortcomings of the current version were experienced during the Tasks 2.2 and 2.3. We will address these shortcomings in T2.4 changes to LML will be suggested (e.g. addition of entity types to the LML Ontology). The information created during the BMC, QFD and IoT assessments is used to model the PSS lifecycle with LML. The modelling procedure is performed concurrently with each step of the design methodology. Further, information collected outside the three steps may be integrated into the model at any time (e.g. to include information for the lifecycle analysis). Using BMC information in the lifecycle model In this deliverable, the starting point of the lifecycle model is the information created during the BMC task. This information may include more than the illustration of the resulting canvas. Table 1 contains a proposal for the relations between canvas elements and entities defined in the LML specification. Table 1: Relations between Business Model Canvas information and Lifecycle Modelling Language entities. BMC information LML entities Key partners => Assets Key activities => Activity Key resources => Resource, asset Customer segments => Assets Cost structure => Cost Revenue streams => Input/Output (I/O) The authors of this paper experienced the remaining canvas elements, i.e. value propositions, customer relationships, and channels, as difficult. This is mainly because the elements have no clear match with existing LML entities. The channels element, for instance, might be realized with Conduit and I/O entities or with a mix of I/O, Asset and Activity entities. At the end of the BMC the lifecycle model should contain key stakeholders (partners and customers), activities, resources and cost. Details about technical and organizational measures to realize the PSS are still missing. Using QFD information in the lifecycle model The purpose of this part of the modelling procedure is to derive stakeholder requirements and technical specifications of the PSS from the QFD (i.e. HoQ). The relation between QFD information and LML entities is outlined in the following list: Voice of the customer. The perspective of the customer (and other stakeholders) is expressed with the Statement entity. In this context, the statement is a description in the customer s language. Voice of the company. The statements of customers are translated into specifications. These are expressed in the company s language (e.g. technical wording). Specifications can be represented in LML by using the Requirement entity. The defined specifications (which may still evolve over time) feed into the design of the required solution components of the PSS. While they become clearer in the course of engineering design, service engineering, Copyright Manutelligence Consortium Page 12 / 36

13 software development and other processes, the lifecycle model becomes more detailed as well. This concerns, for instance, the addition of hard- and software functionalities, as well as business processes, such as procurement, maintenance and recycling. A list of potentially relevant business processes is provided in [1]. The solution-related elements of the model are connected to the formerly defined requirements, while the requirements are connected to customers (or other stakeholders ) statements. In the case that a stakeholder doesn t know why a PSS component was modelled, these relations become helpful. Using IoT information in the lifecycle model The purpose of this part of model building is to describe functionalities related to monitoring, control, optimization and autonomy of the PSS s hardware (the IoT components). For this purpose, Action and Asset entities may be added, such as data generation through measurement, and data processing that turns data into useful information. The resulting information is conveyed via communication channels these can be described through Conduit and I/O entities Modelling domain knowledge Maintainability is an important characteristic of a lifecycle model. It is enhanced if the model follows a general structure that allows the modeller to navigate through the model. In Manutelligence, two general structures are used. They are illustrated in Figure 4 and relate to the concepts defined in D3.1 and D2.1. Figure 4: General structures of the PSS lifecycle models in Manutelligence The left side represents a structure that describes a PSS as an entity with its own lifecycle phases (single-cycle). The PSS has a beginning, middle and end of life phase. Phases may consist of lifecycle processes and these processes can be further separated into tasks and subtasks. At the bottom of the hierarchy, there are decisions that may be related to equations. The processes and tasks integrate different components of the PSS, such as hardware and software. The right side represents a structure that describes a PSS as an assembly of different entities (multi-cycle). Each of these assemblies has its own lifecycle consisting of three phases. The phases may contain processes, tasks, decisions and equations as well. The main difference with the left-side structure is the separation of concepts such as hardware and software. Herein, separation means model-wise separation, i.e. relations between the lifecycle processes still exist. These relations reflect that the PSS is an integrated offer of products and services. Both approaches were useful in the context of Manutelligence. For further analysis, the sample of modelled cases is too small. Copyright Manutelligence Consortium Page 13 / 36

14 Apart from the general structure of the lifecycle model, the domain knowledge involved in the lifecycle is quite heterogeneous. In Manutelligence, important domains concern: Stakeholders and business processes Hardware and software functions related to the Internet of Things Cost and Revenues Data and Information flows Data processing and management These domains are described in the following sections Stakeholders and business processes Stakeholders and business processes provide the skeleton of the PSS model. The information is derived from the BMC in the form of key partners and key activities (tasks). Besides the partners, the customer and the PSS provider are also stakeholders that should be represented in the model, because they perform important tasks. Relations between partners and tasks are defined in the model through performs/performed by relations. Entity description Asset. Specifies an object, person or organization that is used to create value and perform Actions. This entity type represents stakeholders in the sense of a role played by an organization (e.g. supplier) or person/role (e.g. user). The illustration on the righthand side shows an excerpt from a PSS (PSS provider). Lifecycle model (excerpt) Copyright Manutelligence Consortium Page 14 / 36

15 Action (Business Process). Generates effects and may have pre-conditions before it can be executed. Can include transformation of inputs into outputs. This entity type expresses lifecycle phases, processes and tasks. The illustration on the right-hand side shows an excerpt from a PSS (maintenance). Time. Specifies a point or period when an Action or Asset exists, starts, finishes or continues. This entity type is mainly used to specify processes or describe events related to maintenance. The illustration on the right-hand side shows an excerpt from a PSS (design project start) Requirements and system components The starting point of a systematic modelling task is the identification of requirements for the PSS. These requirements are formalized expressions indicating what the PSS should be capable of. Requirements should meet quality criteria, such as clearness and objectivity. Requirements are typically phrased by the designer using his/her domain knowledge. They represent the basis for the system specification. The domain knowledge of stakeholders can be expressed in a less formal way through statements. Once the requirements are outlined, the definition of functions and related system components proceeds. Statements and requirements help stakeholders to understand if a PSS meets the needs of stakeholders and it helps to trace solution components and functions back to actual demands from the stakeholders. The latter supports PSS designs that only contain required functions and the related components to realize them. Copyright Manutelligence Consortium Page 15 / 36

16 Entity description Statement. Specifies a text contained in an artefact. The statement refers to stakeholder needs expressed in their domain language. Statements are used for tracing. The illustration on the right-hand side shows an excerpt from a PSS (be able to watch data from anywhere at any time). Lifecycle model (excerpt) Requirement. Identifies a capability, characteristic, or quality factor of a system that must exist for the system to have value and utility to the user. Requirements are used to justify functions and other characteristics of a PSS. The illustration on the righthand side shows an excerpt from a PSS (provide room temperature data to room user). Asset. Specifies an object, person or organization that is used to create value and perform Actions. This entity type represents system components. The illustration on the right-hand side shows an excerpt from a PSS (floor heating controller asset). Action (Function). Generates effects and may have pre-conditions before it can be executed. This entity type represents functions of the software and hardware. Can include transformation of inputs into outputs. The illustration on the right-hand side shows an excerpt from a PSS (floor heating system functions). Copyright Manutelligence Consortium Page 16 / 36

17 3.5.4 Cost and revenues Besides stakeholders and activities, the BMC contains a first estimate of the cost structure and the revenue streams. This information can be stored in the lifecycle model to support lifecycle cost analysis (see D2.3 for the specific approach applied in Manutelligence). Entity description Cost (Cost). Specifies the outlay or expenditure made to achieve an objective associated with another entity. Costs are associated with business processes and functions of the product (Action entities). They can be related to other Cost entities to represent hierarchies (operating cost consists of other costs). If the cost incur at a specific time a Time entity can be related to it. In line with the approach described in D2.3, the cost are differentiated into: - Investment cost. One time cost incurring at the beginning of life phase. - Operating cost. Regular cost related to the middle of life phase. - Disposal cost. One time cost during the end of life phase. The illustration on the right-hand side shows an excerpt from a PSS (production cost per unit). Cost (Revenue). Revenues are not supported by LML v As a workaround, they are described as Cost entities with negative value. Revenues are used in the same way as regular Cost entities. In line with the approach described in D2.3, the revenues are differentiated into: - Operating revenues. Regular revenues generated by the service (e.g. fees). - Disposal revenues. One time revenue generated when the service components are disposed. The illustration on the right-hand side shows an excerpt from a PSS (usage revenues). Lifecycle model (excerpt) Data, information and knowledge flows For IoT-based PSS, it is important to understand the implications of the integration of information and communication technologies. This means that the data, information and knowledge flows are recognized and Copyright Manutelligence Consortium Page 17 / 36

18 planned. From the technical perspective, the data flows are important. They reflect, for instance, where programmers and system architects need to be involved. Sooner or later, the data will likely be transformed into information and knowledge that can be applied in decision making during business processes. The topic extends further into information and knowledge management (which is not in the scope of this deliverable). For the ease of understanding, the terms data and information are used interchangeably. The term knowledge is left aside from the lifecycle modelling because it concerns communication between persons rather than IT-systems. The latter is the main scope of Manutelligence. Entity description Input/Output (I/O). Specifies material, energy and information input or output. It is connected to a source and/or sink. The source creates the data and is modelled using an Action entity (function or business process). The sink receives data and is modelled using an Action entity (function or business process). The illustration on the right-hand side shows an excerpt from a PSS (Cost data of the floor heating PSS). Conduit. Specifies a connection between Assets and carries an I/O. Technical means to transfer and make data available are represented as, for instance, communication channels or interfaces. They connect to one or more Asset entities and transfer I/O entities. The illustration on the right-hand side shows an excerpt from a PSS (REST API). Lifecycle model (excerpt) Data generation, storage and communication The integration of IoT functionality results in the need to generate, store and communicate data. Furthermore, data processing is needed to increase the value of data (turning it into meaningful information). Entity description Action (Function). The generation of data is related to a function of the hard- or software. The latter is represented as Asset entity. The illustration on the right-hand side shows an excerpt from a PSS (Room temperature measurement). Lifecycle model (excerpt) Artefact. Specifies a document or other source of information. Data is typically stored to ensure longterm usability. The storage refers to, for instance, documents and databases. The illustration on the right-hand side shows an excerpt from a PSS (Social Media database). Copyright Manutelligence Consortium Page 18 / 36

19 Resource. Some technical components are modelled as sizable/consumable components of the PSS. They are blocked for other users once they provide a function. A resource, such as an IT-system, can provide data storage, data processing and communication functions. Thus, it is connected to other entities, such as Action and Conduit. The illustration on the right-hand side shows an excerpt from a PSS (Smartphone App). Asset. Some functions of the PSS require specific hardware components to work. These include, among others, sensors, controllers, memory and WiFi antennas. These assets are related to Action entities that represent functions. The illustration on the righthand side shows an excerpt from a PSS (Room temperature sensor). The aforementioned model components are the main building blocks to describe the lifecycle of a PSS with LML and the modelling tool (Innoslate). The implementation of advanced lifecycle concepts, presented in D2.1, was not found as adequate or technically feasible (limitations of the tool). The inclusion of D2.1 content is summarized in Table 2. Table 2: Summary of advanced lifecycle model concepts used in the modelling task (T2.2). Advanced concepts of Carried out in the modelling task for the specific use cases lifecycle models in D2.1 Material, energy and - Information flows carried out. information flows - Material flows only in FabLab use case realized. - Other flows are not in the scope of T2.2 and would increase the model complexity significantly. Instance concept - Not carried out (or done), due to modelling tool limitations. State and sequence concept - All models are carried out as linear sequence of Actions (Action diagram). - Product states are defined using Characteristics. These are generated through Actions. Multi-lifecycle models - Carried out through data flows from usage to design. Time offsets - Partially done by using Time entities in the models. These times are used to initiate lifecycle analysis (T2.3). Product and part lifecycles - Partially done in the FabLab use case to explore the manageability of the model and to understand the added value for modelling. Process and stakeholders - Carried out using Actions (business process) and Assets (stakeholder). Copyright Manutelligence Consortium Page 19 / 36

20 4 Methodology Application The methodology presented in the previous chapters is texted on some pilot cases. Different activities are developed in order to identify the requirements, to define the smart components and to build the lifecycle model. We highlight the fact that this methodology should be considered as an initial stage of the development of a more comprehensive method. The modelling task was done in an explorative way, i.e. the model was created and refined iteratively. This section will describe how the proposed PSS design approach was applied in selected Manutelligence use cases. Out of the four use cases, two were selected as candidates for an application of the methodology (Ferrari and Lindbäcks). The FabLab case was modelled without the application of a formal BMC or QFD. The Meyer Turku case was out of scope of this particular task, due to its special set of technologies and use case requirements. The three lifecycle models differ in their complexity (number of entities and their relations). Partially, this reflects the explorative approach chosen for the lifecycle modelling. The most complex model is the one for Lindbäcks, the least complex one is the FabLab case. The models include the lifecycle analysis concept described in T2.3 (only Lindbäcks) and the product avatar concept described in T5.6. The models were created by different people, meaning that there are deviations in the way the model elements are named, arranged and related. Thus, modelling has a subjective component that depends, among other things, on the experience and background of the modellers. 4.1 Ferrari case The Ferrari case is an example of how a designer can take advantage of collected information to make decisions about a new component or just to improve an existing one, based on data coming from the real usage of the car. We captured data simulating a car customer testing on a circuit in order to improve the design and to obtain an enhanced "drive line" accuracy/driving comfort. The integration of the IoT technology that allows to collect technical data and to elaborate on it with the designer system tools in a single platform constitutes the innovative character providing a new way to design the product/service. The Ferrari case is explained in WP6, D6.2. The CAD+FEM model of the suspension of the FXX car is implemented in the Manutelligence platform to enable virtual simulation of the vibration mode of the suspension. The physically measured wheel displacements during the track test as well as the accelerations measured on the steering wheel will be used to fine tune the model. In the meanwhile, the IoT HX platform, which will be integrated in the overall Manutelligence platform, is used to retrieve data from the field. Actually, in order to develop the PSS design methodology, we initially have considered the Ferrari use case in a different scenario, analysing the Ferrari XX Programme. The Ferrari XX Programme is basically built on the pleasure of riding a Ferrari. It is not a simple test drive, but it consists of a two years project in which the most loyal customers of the brand have the opportunity to take part in dedicated and exclusive race sessions. During these events the customer has the opportunity to drive the limited edition Ferrari FXX. The company offers him a team of experienced technicians to manage every mechanical request and dedicated driving courses are provided. The support given to the driver in his experience with the Ferrari FXX car is the nearest to a professional experience, with a team of mechanics, engineers and driving courses dedicated to each customer in order to enhance his driving experience. The race takes part in the best circuits in the world and customers live a real race weekend, having free test, doing qualifiers and concluding with the grand prix between all the drivers. Copyright Manutelligence Consortium Page 20 / 36

21 During the sessions, the customer can benefit from accommodations in the most luxurious hotels and restaurants and can experience entertainment features. Beyond this experience, the aim of Ferrari within the XX project is to gather data from the field and from real drivers, in order to enhance the car performances. The idea of taken data from the field is the same that has been developed during Manutelligence project, where wheel displacements and accelerations are measured during track tests. These tests are, in the context of the Ferrari XX Programme, realized by customers themselves. This is an example of a service that also benefits the drivers if the steering system is optimized, less vibrations are transferred to the driver providing an overall better driving experience. This is a real service (rather than normal design optimization) because the drivers could pay with the driving data to receive a better experience in return and, at the same moment, Ferrari can use the knowledge about the steering system to improve product quality. The methodology is applied in all the three activities presented above (Business Model definition, Requirements definition and IoT Capabilities definition) with a specific focus on the IoT Capabilities Design. Some aspects of the classical PSS development are deliberately skipped. The methodology aims to structure the concept and design phase of the PSS, in order to enhance the performance of the Manutelligence platform, which should be able to collect and manage data from field, thanks to the IoT technologies. The lifecycle model is then developed Business Model Design Activity 1 starts with the definition of the Business Model of the PSS, in order to define actors, activities, goals, costs and revenues and to structure them. Business Model Canvas and the Value Proposition Canvas are constructed. The analysis starts with the definition of the customers needs. Part of the information directly comes from the company, while other parts are collected from similar cases found in literature. Figure 5 reports the Business Model Canvas and the Value Proposition Canvas developed for the Ferrari case. Figure 5: Ferrari Case Business Model Canvas. Copyright Manutelligence Consortium Page 21 / 36

22 4.1.2 Requirements Definition Figure 6: Ferrari Case Value Proposition Canvas. During this phase, the inputs coming from the BMC and the Value Proposition Canvas are translated into technical requirements. These requirements will then be used to design product and services in Activity 3. The HoQ presented in this work has some peculiarity, in order to be suitable for the Product-Service System characteristics. In particular, the HoQ developed for our test is reported in Figure 6. It presents some simplifications, such as The Competitive Assessment part is not developed because there is not a similar comparative real case in the automotive market. We have selected different scores in the Relationship Matrix part to indicate the magnitude of the interrelationship between the Voice of the Customer, the Voice of the Company and the Technical Requirements : strong inter-relationship (mark: 9), medium inter-relationship (mark: 6), weak interrelationship (mark: 3). Therefore, the entries of the table are the result of the product between the relationship scores and the Importance Weighting scores. Copyright Manutelligence Consortium Page 22 / 36

23 4.1.3 IoT Capabilities Definition Figure 7: Ferrari Case House of Quality (HoQ). The goal of this last activity is to define the IoT capabilities at each level of the BoM, in order to satisfy the specific requirements. It receives as inputs the requirements defined during Activity 2. In this specific application a simplified BoM and the connected capabilities matrices are introduced. The definition of the System Engineering and Service Engineering processes will be skipped, since they are not relevant for this example. The BoM is defined through a model car BoM analysis. It is composed by three levels (the 0 product level is not considered), which define the whole structure of the vehicle. After BoM definition, suitable matrices are used to identify the IoT Capabilities at each BoM level. Figure 8 summarizes some examples from the Ferrari case. Copyright Manutelligence Consortium Page 23 / 36

24 Figure 8: Example of matrices constructed for the Ferrari use case IoT capabilities definition. For each entry we have defined if a particular IoT capability is present or not. Referring to [2], IoT capabilities are classified as Monitoring, Control, Optimization and Autonomy. In Figure 8, green colour indicates the Monitoring activity while orange colour refers to Optimization activity. A white box means that no IoT Capabilities are defined for that entry. Copyright Manutelligence Consortium Page 24 / 36

25 4.1.4 PSS lifecycle Model The lifecycle model of the Ferrari case is a single-cycle model. On its first tier it is separated into three lifecycle phases (see Figure 9). Each phase is further detailed by business processes. Figure 9: First level of abstraction of the Ferrari PSS. The following subsections describe details of the three phases along the tiers of the model. Links to other tiers are indicated by the decomposed label in the activity diagram Beginning of Life phase Tier 2 (BOL1-4) The BOL phase consists of car and facilities preparation, in order to implement the customer experience. Further, there is a specific phase for designing an analysis software tool and the smartphone application. Tier 3 (BOL1.x-4.x) Figure 10: BOL phase of the Ferrari PSS (Tier 2) In this example the third tier illustrated in Figure 11 consists of three activities developed during the car preparation phase, i.e. the circuit reservation, the driving curses and the installation of the sensor system on the steering wheel. The circuit reservation and the driving courses are addressed to the customer, which can live the Ferrari driving experience. In the meanwhile suitable sensors are installed on the steering wheel in order to register data from the field. The sensor system is necessary to the Ferrari designers in order to monitor the steering wheel vibrations and to improve its design (e.g. adjust the vibration dampers in the system). Car requirements are integrated in the sensor system design. Figure 12 represents the design and development of the smartphone application. Application allows a customer to access data regarding his driving performance anywhere and anytime. Customer requirements must be integrated in the app design. Copyright Manutelligence Consortium Page 25 / 36

26 Figure 11: Car preparation phase (Tier 3). Figure 12: Design and develop Application phase (Tier 3) Middle of Life phase Tier 2 (MOL1-3) Copyright Manutelligence Consortium Page 26 / 36

27 This phase covers the deployment of PSS components, their use and maintenance. Tier 3 (MOL1.x 3.x) Figure 13: MOL phase of the Ferrari PSS (Tier 2). The usage process contains a description of the car functions, the customer driving experience, which returns a customer feedback, and the data collection and analysis phase. Each of these processes are further detailed. Figure 14: Usage process of the Ferrari PSS (Tier 3). The following Figure 15 represents the usage phase as a spider diagram. Thanks to this diagram we can visualize the different phases and how these are connected to the different requirements. Copyright Manutelligence Consortium Page 27 / 36

28 Tier 4 (MOL2.1.x-2.3.x) Figure 15: Usage process of the Ferrari PSS Spider diagram. The fourth layer contains details about the usage process. It describes user actions and data processing (Figure 16). Data Processing is relevant to use data collected from the field to give feedbacks and information to the Ferrari designers (refer to Task 6.1). These data are integrated with customers feedback, deriving from their particular driving experience. Copyright Manutelligence Consortium Page 28 / 36

29 Figure 16: Data collection and analysis of the Ferrari PSS Spider diagram (Tier 4) End of Life phase The end of life phase is not detailed for this PSS to reduce the complexity of the model. It will be important, though, to clarify how the Ferrari car is treated after usage and how sensors, software and other activities (Hotels and Restaurants agreements) are stopped once the PSS is no longer operated. 4.2 Lindbäcks case The PSS design methodology is applied on the pilot C (service for smart home end users) described in D6.7. It is based on the idea of a pay-per-use business model. It offers the customer (building user/tenant) the possibility to pay for building equipment on-demand instead of buying it or paying rent without using it. Example products included kitchen equipment, white goods, blinds and floor heating. The latter is selected further to be planned and realized in Manutelligence. A standard floor heating system (underfloor heating), as used by Lindbäcks, consists of electric heating elements (e.g. mat or cable) and a sensor and controller unit to keep the temperature stable. Copyright Manutelligence Consortium Page 29 / 36

30 4.2.1 Business Model Canvas The BMC for the Lindbäcks use case represents an initial overview about the planned PSS and its key elements. An illustration of the BMC is provided in Figure 17. Figure 17: Business Model Canvas for the Underfloor heating PSS. The model contains two key partners that are important to operate the PSS. The energy provider is important because he provides the energy used for the floor heating and thus influences the operating cost of the PSS. The sensor solution supplier provides the technology to collect and store energy consumption data. Key activities performed by the user concern the booking of the service, monitoring of the temperature and the energy consumption, as well as the related cost. In addition, the user may request maintenance if problems are recognized. The hardware/software performs a control function (to keep the temperature constant). Key resources include an interface that meets the expectations of stakeholders (mainly users). Furthermore, a sensor network in the building might be necessary to measure energy consumption and environmental parameters that influence energy consumption or the perceived heating performance (e.g. humidity and air temperature). The IT infrastructure should be scalable to cover hundreds of buildings/bathroom units. Infrastructure includes the servers to run the backend of the Smartphone app. Value propositions of the planned PSS concern a lower overall rent, because the floor heating system is not fully payed in advance by the building owner, and thus the cost may not be included in the apartment rent. The pay-per-use model allows the tenants of a building to buy the floor heating on demand. This is especially valuable for people that use the service occasionally rather than frequently. The ability to use a Smartphone app to control the floor heating gives the tenant the possibility to better customize the heating experience. In addition, the energy consumption and the related cost for the tenant become transparent in the Smartphone app. The collected energy consumption data from the PSS could also be sold (or otherwise offered) to the energy provider. This may encourage the provider to offer cheaper energy contracts to the tenant mainly as a compensation for the data about the energy consumption behaviour. The Copyright Manutelligence Consortium Page 30 / 36

31 customer relationships mainly concern the support in payment issues. In principle, extended service offers could also be provided in the form of consulting (e.g. how to reduce overall energy consumption). The channels related to the PSS are the Manutelligence platform (that helps to design/carried out the PSS) and distribution channel for the Smartphone app. The latter includes the App Store (Apple) and Play Store (Google). Relevant customer segments are the building operators/owners of the building e.g. in case a maintenance request is issued. Another segment are students that oftentimes live alone in an apartment. Finally, families are a customer segment. The family members can benefit from customized heating profiles managed via the Smartphone App. In this case, the App must support multiple users per PSS. The cost structure of the PSS includes several onetime cost, such as software development and production/purchase of hardware. Furthermore, continuous cost incurred by maintenance activities, server infrastructure and customer support are considered. Revenue streams cover a possible onetime payment of the Smartphone app and intermittent revenues through the booking of the floor heating service PSS lifecycle Model The lifecycle model of the Lindbäcks case is a single-cycle model. On its first tier it is separated into three lifecycle phases (see Figure 18). Each phase is further detailed by business processes. Figure 18: First level of abstraction of the Lindbäcks PSS. The following subsections describe details of the three phases along the tiers of the model. Links to another tier are indicated by the decomposed label in the activity diagram Beginning of Life phase Tier 2 (BOL1-5) The BOL phase consists of the hardware and software realization, as well as a lifecycle cost analysis (refer to D2.3). The hardware realization includes design, production and installation of the required floor heating system. The software realization concerns the design, development and distribution of a Smartphone app. Copyright Manutelligence Consortium Page 31 / 36

32 Tier 3 (BOL1.x + 3.x) Figure 19: BOL phase of the Lindbäcks PSS (Tier 2) The third tier consists of two activity chains. They detail the design and production of the floor heating system (see Figure ) and the design and development of the app. This level also includes a representation of maintenance and Social Media feedback to the design phase of the next generation of the PSS. Figure 20: Design and produce floor heating hardware with optional information feedback (Tier 3) Middle of Life phase Tier 2 (MOL1-4) The phase covers the deployment of PSS components, their use and maintenance and their decommissioning (removal from the building). Copyright Manutelligence Consortium Page 32 / 36

33 Tier 3 (MOL2.x-4.x) Figure 21: MOL phase of the Lindbäcks PSS (Tier 2). The usage process contains a description of the user behaviour, the functions of the floor heating system and the functions of the Smartphone app. Each of these processes is detailed further. Figure 22: Usage process of the Lindbäcks PSS (Tier 3). Concerning the maintenance process (see Figure 23), three subtasks were modelled to represent different scheduled maintenance activities. These happen at specific times (3 months, 2 years and 5 years after sale) and are related to cost, as well as a maintenance report. The maintenance reports are summarized as maintenance feedback (see Figure ). Tier 4 (MOL2.1.x-2.3.x) Figure 23: Maintenance process of the Lindbäcks PSS (Tier 3). The fourth layer contains details about the usage process. It describes, for instance, user actions, data processing and heating system functions. Data processing (see Figure 2) is relevant for the cost calculation of energy consumption (refer to Task 3.2) and for the extraction of Social Media data (refer to Task 5.6). Copyright Manutelligence Consortium Page 33 / 36

34 Figure 24: Software functions of the Lindbäcks PSS. The expected user actions are illustrated in Figure 2. The user can choose to order heating, monitor system usage and manage payments via the Smartphone app End of Life phase Figure 25: Expected user actions of the Lindbäcks PSS. The end of life phase is not detailed for this PSS to reduce the complexity of the model. It will be important though, to clarify how the hardware is treated after usage and how software or other activities are stopped once the PSS is no longer operated (e.g. inform customers about shut down of the software). Copyright Manutelligence Consortium Page 34 / 36