modelling of a smart service for consumables replenishment

Enterprise Modelling and Information Systems ArchitecturesVol. 13, No. 17 (2018). DOI:10.18417/emisa.13.17Modelling of a Smart Service for Consumables Replenishment 1Special Issue on Smart Service Engineering

Modelling of a Smart Service for Consumables ReplenishmentA Life Cycle Perspective

Jürgen Anke*,a, Stefan Wellsandtb, Klaus-Dieter Thobenb

a Hochschule für Telekommunikation Leipzig, Gustav-Freytag-Straße 43-45, 04277 Leipzig, Germanyb University of Bremen, Faculty of Production Engineering, Badgasteiner Straße 1, 28359 Bremen, Germany

Abstract. Smart services are an approach for the IT-supported provision of services based on networkedproducts. They enable new relationships between manufacturers and end users, as well as the establishmentof new value-creation networks. To gain benefits from these potentials, service providers face the challengesof designing and managing smart services. This is mainly due to the complexity of the underlying cyber-physical system (CPS) as well as the individual life cycles of components and third-party services it consistsof. Additionally, a number of actors and their tasks, various tangible and intangible benefits, as well asflows of material, information and money need to be considered during the planning and provisioning of theservice. In this paper, we investigate the potential of modelling smart services with the Lifecycle ModelingLanguage (LML). To this end, we analyse the fulfilment of information need of different stakeholders basedon a consumable material replenishment service for 3D printers.

Keywords. Life Cycle Modelling • Smart Services • Internet of Things • LML • Supply Chain Management

Communicated by M. Fellmann. Received 2017-03-10. Accepted after 2 revisions on 2018-06-10.

1 Introduction

1.1 MotivationAs part of the ongoing development of the “In-ternet of Things” (IoT), physical products getenhanced with embedded systems and commu-nication capabilities to turn them into intelligentand networked products. Such products provideglobally usable digital functions in addition totheir local physical functions (Fleisch et al. 2015).Services provided based on the data from con-nected products are called “Smart Services” inthis paper. For example, networked bicycles pro-vide smart services to track training data, warnat chain wear-out and to request assistance whensensors indicate a crash (Shaw 2014). Industrial

* Corresponding author.E-mail. [email protected] of this research was funded by the EU within theMANUTELLIGENCE project (grant No. 636951).Note: This work is based on Wellsandt et al. (2016).

products such as compressors, ventilators and ele-vators get upgraded with smart services for remotecontrol, monitoring, usage-based billing and otherservices (Herterich et al. 2015).

The transformation of product-based value of-ferings towards service-based ones is called “Servi-tization” (Neely 2008). It enables entirely newrelationships and interactions between manufac-turers, operators and users of physical goods andthus provides the basis for new data-driven busi-ness models (Velamuri et al. 2013; Zolnowski etal. 2016). Especially manufacturers of technicalproducts and devices can reshape the nature andquality of their customer relationship by offeringinnovative services and thus differentiate from thecompetition (Fischer et al. 2012; Herterich et al.2016). Additionally, such services can be pro-vided by third parties, which become part of newvalue-creation structures as service providers andintermediaries in platform ecosystems (Mikusz2015).

http://dx.doi.org/10.18417/emisa.13.17

[email protected]

International Journal of Conceptual ModelingVol. 13, No. 17 (2018). DOI:10.18417/emisa.13.17

2 Jürgen Anke, Stefan Wellsandt, Klaus-Dieter ThobenSpecial Issue on Smart Service Engineering

To design smart services, providers have tocombine the suitable functionality to create valuefor the respective customer groups and plan thesteps for service provisioning, which may involvepartners and third-party services. At the sametime, the financial impact of the new service has tobe estimated based on the necessary resources andthe expected sales volume. Particularly during thetransfer of demonstrators and prototypes into mar-ketable offers, a number of steps have to be takento provide a quality level demanded by customers.For that, the entire life cycle of development, man-ufacturing, usage, maintenance and disposal mustbe considered and flows of information, materialand money taken into account.

The resulting complexity is on one hand dueto the interdisciplinary design process, in whichdifferent departments of the company have tocollaborate. On the other hand, smart services arecomplex systems, which consist of many technicaland organisational subsystems that need to worktogether in order to provide the service. Each ofthe subsystems and the smart service as a wholehave different life cycles (Aurich et al. 2007). Asthe design of complex systems can be supportedwith appropriate models (Becker et al. 2010),we address the following research question inthis paper: Which benefits can stakeholders gainin the development of smart services through amodelling of the life cycle with LML?

Our main thesis is, that modelling life cycles ofsmart services with LML increases transparencyabout the processes of service delivery as well asthe dependencies of components with each other.Therefore, an LML model of smart services canfacilitate both the provision of information needsfor various stakeholders and the early identificationof risks.

1.2 MethodologyResearch Goal. The goal of this article is todemonstrate and discuss the benefits of makingsmart services transparent by modelling their lifecycles. This enables developers of smart servicesto better understand the effects associated withthe planned service. The underlying assumption

is that a better comprehension of relationshipsbetween various product-, software-, and processelements in a smart service improves the handlingof complexity, e. g. identification of risks.

As result of our research, we expect insightsregarding the potential benefits that a smart ser-vice life cycle model can provide for differentstakeholders. Identified shortcomings may at thesame time provide a basis for an extension of themodelling language.

This work focusses exclusively on the evalua-tion of a model of processes and structures for theprovision of smart services for networked products.The modelling procedure as such is explicitly notconsidered and therefore out of scope.

Research Approach. We address the researchquestion based on a case study in five steps:

1. At first, smart services for networked productsare characterised as product service systemsprovided by a cyber-physical system. For that,we identify the main system elements and therelevance of their life cycles.

2. From these two aspects we derive informationneeds for different stakeholders that participatein the design and operation of smart services.

3. Afterwards, we introduce a scenario for a smartservice, which provides automated replenish-ment of consumables for 3D printers. Thisscenario is modelled using LML.

4. Finally, the model is evaluated based on theobjectives which were elaborated in the secondstep. Furthermore, we evaluate benefits of themodel based on the fulfilment of informationneeds of different stakeholders.

5. From these results we draw conclusions aboutthe suitability of life cycle models in the designprocess for our chosen case study and furtherresearch needs.

This paper is structured according to this approach.

2 Life Cycles of Smart Services2.1 Characteristics of Smart Services

“Smart Services” denote the needs-based provisionof a combination of Internet-based and physical



services (Kagermann et al. 2015). Smart servicescan also be considered as product service sys-tems (PSS) as they are “an integrated offeringof tangible products, intangible services and en-abling infrastructure” (Tietze et al. 2013). PSSare means for transforming product-oriented of-ferings to service- and results-oriented offerings,especially for technical products (Adrodegari et al.2015).

Networked products are also referred to as “in-telligent products” (Meyer et al. 2009) or “smartobjects” (Vasseur and Dunkels 2010). The termsmay vary in detail, but they all share the ideathat physical products are equipped with digitalcommunication capabilities as well as IT-basedfunctionality to acquire or even influence the stateof a product and its environment. This allowsproducts to get integrated more efficiently in theusage-context of the customer (Kees et al. 2015).The networking of the products also enables theeasy integration of the product as an external factorand thus creates the basis for data-driven serviceofferings (Porter and Heppelmann 2014).

The provision of smart services is typicallybased on the following principle: A networkedproduct records its state using sensors and suppliesthe data using machine-to-machine communica-tion (M2M) over the Internet. Some devices alsoprovide actuators and respective control opera-tions. The communication between product andcentral server or cloud service is conducted viathe Internet (Wortmann and Flüchter 2015). Inthe cloud, the product state data serves as basisfor operational and analytical functions. A smartservice combines different functions on the cloud,augmented with data and functionality from otherInternet services. Customers can consume theservice via mobile apps or Web applications.

Smart services are thus socio-technical systems,consisting of sensors, actuators, embedded sys-tems, digital networks, Internet services as well ascoordination and management processes. Systemswith this set of elements are called cyber-physicalsystems (CPS) (Broy et al. 2012). Existing workon CPS deals mainly with technical aspects. How-ever, there is also the view of CPS as a basis for

service provision. This view focusses on a com-bination of products and services as well as theircoordination via of software to create value forcustomers (Mikusz 2014).

In this paper, we define smart services as PSS,which provide services using data from technicalproducts based on a CPS (cf. Mikusz 2015). Aprerequisite for the analysis and modelling of lifecycles in smart services is the understanding ofits system components. To this end, we haveconcretised the general CPS elements for the caseof a CPS facilitating the provision of smart services(see Tab. 1). These CPS elements will get mappedto LML elements later on.

2.2 Fundamentals of Life CyclesTerms and Concepts. A life cycle denotes different,successive periods of time that mark the way ofa product or a service. From this flow-based per-spective (Umeda et al. 2012), the life cycle can bedivided into phases. Kiritsis suggests the separa-tion into beginning-of-life (BOL), middle-of-life(MOL) and end-of-life (EOL) phases (Kiritsis2011). The three phases can be further subdividedinto processes. For example, material-, energy-,and information flows throughout the life cyclecan be mapped to the life cycle phases (Umedaet al. 2012). An example of a product life cyclemodel is shown in Fig. 1.

Fig. 1: Example of a product life cycle model (Well-sandt et al. 2015)

An even more specific perspective on the lifecycle is the consideration of individual products(Hans et al. 2010) rather than classes of prod-ucts. This so-called “item-level PLM” focusseson product information, which belong to a single,identifiable product or product component. This




General CPS item Manifestation of the CPS element for a smart service

Physical process Local, physical function of the productSensors and actuators forcapturing and controllingphysical processes

Various forms depending on the specific product, such as sensors for filllevel, temperature, pressure and actuators for switching and control

Embedded systems Embedded system for monitoring and control of the physical product withembedded software and communication module for data transmission

Digital networks Various technologies for the connection of embedded system and operatorcloud platform, e. g. mobile communications, Wi-Fi, or corporate networks

Utilization of globallyavailable data and services

(cloud-based) operator software platform and any additional Internet ser-vices, e. g. electronic marketplaces

Multi-modal human ma-chine interfaces

Various forms of user interaction on the product itself, via mobile apps orWeb applications

Management processes Management of the service (booking, configuration, billing)Coordination processes Provision of the service, control of service provisionLogistics processes Delivery of physical (e. g. spare parts, consumables) or digital components

(e. g. software updates)

Tab. 1: Manifestation of the CPS elements for a smart service

information, for example, is relevant for the indi-vidualisation and servicing of products (Corcelleet al. 2007).

Life cycles and smart services. The providerof a smart service is typically responsible for theentire life cycle of the underlying service system.The challenge in designing such a system is thatindividual components of the system are devel-oped separately but have to work together in orderto provide value to the customer. Each service sys-tem element can have an individual life cycle. Forexample, different versions of a component can ex-ist over time (e. g. software platform). Changes inthe life cycle of individual components may arisethrough new customer requirements, legal changesor availability of new technologies (Wolfenstetteret al. 2015).

In contrast to the product life cycle shown inFig. 1, several life cycles need to be consideredsimultaneously. These life cycles run in parallel orside by side with a temporal offset. Furthermore,there are relations between the stages of life cy-cles. The following list shows examples of effects

arising from changes in the life cycle of a smartservice system element:

• Customer or product reports problem: Identifi-cation of the associated elements, classificationinto potential physical or digital problem fixes.Remote control, configuration or update proce-dures or dispatching of technicians have to beperformed for affected components.

• Defect of the product: Replacement of the phys-ical product requires logistics for the delivery,return of the defective product, as well as updat-ing the service configuration to make it workon the new product.

• Defect of embedded system: Replacement ofthe affected hardware, update of the embeddedsoftware, transfer of service configuration, e. g.to preserve the product’s digital identity.

• Changes in the service management processes:Enhancement of the operator cloud-platformand service configuration for customers, updateof the embedded software, e. g. to facilitateadditional pricing models, such as prepaid orsubscriptions.



These examples show that modifying one el-ement can affect others, which may lead to dis-ruptions in the service provisioning. Being awareof these dependencies is of great importance forensuring a high availability of the system. Aswe will show in the analysis of information needsfor different roles, this holds true for activitiesin all life cycle phases. It also helps to preventunwanted side-effects and supports collaborationin the ongoing operation and optimisation of theservice system.

The types of relationships between life cyclesor parts of a life cycle are currently being dis-cussed. Westphal et al. (2015) and Wiesner et al.(2015) explain the importance of interactions be-tween product and service life cycle managementfor manufacturing companies. Kwak and Kim(2013) present an approach for life cycle costingand life cycle assessment to analyse the economicand ecological impact of PSS. Lindström et al.(2014) show interactions of life cycles in “Func-tional Products”. This type of PSS consists ofhardware, software, management operations anda service support system. Further challenges indealing with multiple life cycles in the product andservice development are investigated in currentresearch projects, e. g. the Manutelligence Consor-tium (2016), the Falcon Consortium (2016) andthe Psymbiosys Consortium (2016).

Classes and instances of service elements.While the aforementioned life cycle considerationsrefer to the management of smart service compo-nent types, the advances in information technologyprovide increasing possibilities to trace individualcomponents. These components will be referredto as “instances” in this paper – the same notionis already used for physical objects (Hans et al.2010). Each instance of a smart service com-ponent has information about its own life cycle,e. g. how and where it was produced, used anddisposed. Taking an instance-level perspectiveon smart services increases the complexity of thesystem under investigation. Herein, complexityrefers to the number and diversity of components,as well as their relations among each other (cf.Funke 2012, p. 683). Instead of managing types

of products, software and services, a plethora ofinstances with own life cycle information mustbe handled by the smart service provider. Thisincrease in complexity challenges the existinglife cycle management approaches. On the otherhand, access to instance-level information can bea valuable basis for additional smart services, e. g.predictive maintenance. Further, it enables smartservice designers to improve the service system(Lützenberger et al. 2016).

2.3 Modelling of Life CyclesFrom the previous sections, it can be seen that asmart service as CPS-based PSS is characterisedby high complexity due to two properties:

1. Diversity of system elements (e. g. mechanicaland electronic components, software, processesfor service provisioning and management) aswell as the number of relevant stakeholders.

2. Interdependencies caused by relationshipsamong system elements as well as the nec-essary consideration of information flows, ma-terial flows, and money flows between them (cf.Sect. 2.2).

These two aspects should be addressed by lifecycle modelling, to make the model useful forsmart services design. This is substantiated byfollowing objectives:

• Illustrate the complexity and thus improve itsmanageability. Complexity is characterisedby the number and by the variety of systemelements and by the number of relationshipsbetween them. The model should be able to rep-resent the required elements and relationships.

• Enable identification of risks through dependen-cies between system elements. Effects causedby modifying one component on other systemelements must be identifiable, e. g. the exchangeor upgrade of hardware or software.

A comparison of modelling approaches forservices from various disciplines showed that es-pecially the modelling of PSS, as well as therepresentation of life cycles were only weaklysupported (Hoffmann et al. 2009). Some basic




model types that can be used in the context ofservice modelling, are described by Scheer et al.(2004). More specific approaches used to describeprocesses are for example proposed by Gronauet al. (2010), Klingner and Becker (2012), andMeis et al. (2010).

Widely acknowledged modelling languages areBusiness Process Model and Notation (BPMN),Unified Modeling Language (UML) and SystemsModelling Language (SysML). A comparablynovel language is the Lifecycle Modelling Lan-guage (LML). A committee of systems engineer-ing practitioners and academics introduced it in2015. LML bases on SysML and the Departmentof Defense Architecture Framework, and it focuseson life cycle modelling in particular.

Very few academic papers mentioned LMLsince its release in 2015 (e. g. Hefnawy et al.2016). Therefore, we had little complementaryliterature to evaluate it. All four modelling lan-guages are potential tools to support life cyclemodelling. An important characteristic of a smartservice is the component diversity. Actors withdifferent backgrounds are involved to plan thesecomponents and their orchestration. Examplesare marketing experts, mechanical and electricalengineers, programmers, sales people, lawyersand customers. For this reason, the ease of use isan important criterion to evaluate the suitabilityof modelling languages. It means that a languageis, for instance, comprehensible and easy to learn.Tab. 2 provides an overview about the focus, type,page count, and the ease of use of the identifiedlanguages. We derived the focus and type valuesfrom the languages’ specification documents (seereferences). The page count refers to the pages ofthe specification document in PDF format – wedo not differentiate preface, content and annex.We consider it as a rough indicator for the time anactor needs to learn a language. Our estimation ofthe ease of use grounds on the page count and thescope of a language. In this context, more pageslead to a lower ease of use.

BPMN’s focus on business processes and theextensive documentation indicates the high com-plexity of the language. UML follows a general-purpose modelling approach and its specificationis even more extensive compared to BPMN. There-fore, we consider it as difficult to use as well.SysML is an extension of UML and a general-purpose modelling language. We identified itas easier to use compared to the other two lan-guages. The reason is that SysML aims to supportthe collaboration between systems engineers andsoftware engineers. This objective reflects theinvolvement of heterogeneous actors in a develop-ment task. LML is a general-purpose modellinglanguage meant for systems engineering with adedicated focus on the product life cycle. Thespecification has 70 pages, which indicates a highease of use. The preceding assessment identi-fies LML as the most promising candidate for alanguage in life cycle modelling.

One of the distinct features of LML is an on-tology that stores the specified entities and theirrelationships. The ontology includes twelve basicentity types. Each of these entities is related to allother entities in specific ways. LML supports in-heritance, for instance, the entity type “resource”is derived from the superordinate type “asset”.The LML ontology is supported by different vi-sualization methods to represent the behaviour aswell as the structure of systems. Examples includeactivity diagrams (how the system behaves) andhierarchy diagrams (how system elements relateto each other). Fig. 2 illustrates an excerpt of theentities and their relationships.

Fig. 2: Selected element classes and relationships



Characteristic BPMN 2.0 UML 2.5 SysML 1.4 LML 1.1

Focus Business processes Software-based sys-tems & businessprocesses

Systems engineer-ing problems

Systems engineer-ing problems alongentire life cycle

Type Process modelling General-purpose modellingSpec page count 538 pages 794 pages 346 pages 70 pagesReference OMG (2011) OMG (2015b) OMG (2015a) LML Steering

Committee (2015)Ease of use Low Low Medium High

Tab. 2: Application difficulty of systems modelling languages in life cycle modelling

The applicability of LML in the context of smartservice life cycle modelling is illustrated in Tab. 3.On the left column of the table the aforementionedelements of a smart service are listed. The middlecolumn contains examples of LML entities thatcan be used to represent the elements. For eachentity, there are examples provided in the rightcolumn.

3 Case Study

3.1 Replenishment for 3D PrintersIn this section, we present an example for a con-sumable replenishment service. Consumable re-plenishment is a commonly offered smart service.Tab. 4 summarises several examples of these ser-vices, which are currently offered.

One goal of a consumable replenishment ser-vice is to ensure that customers have access toa previously agreed service level. The serviceoperator charges the customer based on this ser-vice level agreement. An example for a servicelevel is the amount of printable pages in an officeprinter. In the case of intelligent products, em-bedded measurement devices monitor the servicelevel. An office printer, for instance, monitors theremaining amount of ink/toner to calculate theamount of printable pages. Once the ink/tonersupply reaches a threshold value, the printer ordersadditional consumables.

In this paper, we focus on a consumable replen-ishment service for 3D printers. We created theconcept and the life cycle model for this service

during the EU-funded research project Manutel-ligence. A producer of additive manufacturingmachines collaborated with us in this process. Forthem, the service concept was an opportunity toestimate the complexity of a consumable replenish-ment service. With this information, we supportedthem in their decision regarding the realization ofthe service. Thus, the life cycle model represents areal case for a consumable replenishment service.The following descriptions and models refer tomain components of the envisioned smart servicefor 3D printers, which serves as a representativefor similar cases.

3D Printers. Additive manufacturing processeshave been in use for many years for buildingprototypes. In consumer 3D printing, the “fusedfilament fabrication” (FFF) technology is mainlyapplied, for example in the open source 3D printer“RepRap” (RepRap Project 2014). The basis ofFFF is a heated printing head that melts solidmaterials, like thermoplastics. The print head canbe moved in all three spatial directions with thehelp of a moving frame structure. Once applied,the liquid material hardens and forms the body tobe manufactured layer by layer. In the following,we use the term “3D printer” as a synonym forFFF-based printers.

Consumables Replenishment. Similar to con-ventional paper printers, a 3D printer requires asteady supply of printing material. It is typicallyprovided in the form of a plastic wire coiled on aspool. Depending on the printer type, one or more




Tab. 3: Mapping of CPS elements to LML expressions.

General CPS Items LML Entities Examples

Physical processActivity Represents the actual process.Input/Output A consumable that is used up.Asset Hardware performing the process.

Sensors and actuators forcapturing and interactingphysical processes

Activity Measurement or actuation.Input/Output Sensor data.Asset Sensors and actuators are product parts.

Embedded systems Asset The hardware and software.

Digital networksConduit Internet, Wi-Fi, 5G network.Input/Output Data shared via network.Asset Software systems sharing data.

Use of globally availabledata and services

Activity Service integration.Input/Output Data.Asset Services, service market.

Multi-modal humanmachine interfaces

Conduit Human-machine interface.Input/Output Data shared via the interface.

Management processesActivity Represents the actual process.Input/Output Shared data/information.Asset Business unit, role, IT-system.

Coordination processesActivity Represents the actual process.Input/Output Shared data/information.Asset Business unit, role.

Logistics processesActivity Represents the actual process.Input/Output Parcel that is transported.Asset Truck, logistics provider, customer.

spools with filament can be stored in the printer,e. g. different colours or water soluble material forsupport structures. A service which is relevantto owners of personal 3D printers as well as forprofessional service providers, is the automateddeployment of filament. The provision of theservice does not only involve the customer andthe service provider (operator) but also other com-panies, e. g. the logistics provider and disposer ofempty spools. The service falls in the categoryof condition monitoring services, which requireexistence of distinct product instances, relevantproduct state properties and target levels for theseproperties (Knoke and Thoben 2014). The basisfor the performance of the service is a contractbetween the customer and provider, which defines

the technical requirements, performance levels,terms and conditions. As first step, the 3D printerhas to be connected to the ordering system of theoperator and registered as a new instance of theproduct. Afterwards, the state “remaining print-ing material” from the printer can be queried anddelivered for further monitoring to the operator’splatform.

The actual service provision is conducted ac-cording to the proposal of Knoke and Thoben: Atthe customer site, a purchase order is automati-cally triggered by the 3D printer when the stateof “remaining printing material” falls below athreshold value of e. g. 10%. Depending on theconfiguration, an approval of the order is requiredby the customer. At order receipt, the operator



Case Scenario Consumable Source

Winterhalter Pay-per-wash offering for industrial dishwashers Detergents (Winterhalter2016)

Canon Pay-per-page offering for industrial printers Ink, Paper (Canon Europe2017)

HP Pay-per-page offering for consumer ink cartridges Ink (HP Inc. 2016)

Tab. 4: Existing Cases of Smart Services for Consumables Replenishment

has to fulfil it by supplying the consumables tothe customer. The provider can delegate this taskto a wholesaler for plastics or to a plastic man-ufacturer. The purchased materials have to bedelivered to the customer via a logistics serviceprovider. The provision of consumables can ad-ditionally be bound to the obligation to take backthe emptied material spools to facilitate recycling.Depending on the contractual agreement, collec-tion points or a return shipping via a logisticsservice provider can be arranged for this. Thebilling in turn depends on the pricing model. Inthe example described, both individual order andsubscriptions are possible. Both variants are of-fered with comparable services such as “TotalService Care” (Canon Europe 2017) and “InstantInk” (HP Inc. 2016).

3.2 Information Needs of StakeholdersDesigning smart services is a interdisciplinaryproject. The service provider must involve differ-ent departments in order to get a comprehensiveunderstanding of the requirements for a new ser-vice (cf. Laurischkat 2013). With regard to ourresearch question, we need to evaluate the ben-efits of a smart service life cycle model for theinvolved stakeholders. In the following, we denotethe different stakeholders as roles. To derive theinformation needs of each role, we first identifysome of their main tasks and goals (cf. Jungingeret al. 2006):

• Marketing: Increase customer loyalty, sell ser-vice contracts, understand customer needs

• Development: Design and implement smartservice system technically

• Finance: Minimise required investment budget,ensure profitability of the service

• Procurement: Procurement of consumables andspare parts

• Logistics: Picking, packing and transporting ofconsumables and spare parts

• Customer Support: Solving customers’ prob-lems, improving service availability

From the tasks and goals, we have identifiedinformation needs in the different life cycle phases,which are summarised in Tab. 5. For a model tofulfil these information needs, we have derived amore general set of objectives as follows:

• O1: Support the conception of product-relatedservices. Modelling should support planningof smart services, as well as the preparation offurther analyses, e. g. life cycle assessment, orlife cycle costing.

• O2: Allow an assessment of the service concept.The model must be easy to comprehend, e. g.through clarity and unique labels for elementsand relationships.

• O3: Support the planning of required capacityfor resources. Required resources and capaci-ties such as person hours can be depicted in themodel.

3.3 LML Model of the Smart ServiceModelling Approach. The aim of this modelis to describe the elements and their relationswith respect to the features of the chosen smartservice example. The formally correct modellingis not the primary goal. Instead, we focus on the




Tab. 5: Examples of information needs of different roles by life cycle phase

Role BOL needs MOL needs EOL needs

Marketing customer needs, prices customer satisfaction, cus-tomer number

next generation products, re-cycling demands

Development system requirements, solu-tion approaches

identified problems andbugs

technical migration paths tonext version

Finance planned revenues and devel-opment cost

operating cost and actualrevenues

cost for warranties and recy-cling

Procurement type of items for procure-ment, planned lead times,potential suppliers

quantities and times for theprovision of intermediateconsumption

(no information need identi-fied)

Logistics required stock space, leadtime, package sizes, quanti-ties

Items to be delivered quan-tities and dates

removal of old equipmentfrom customer sites and / orrecycling

CustomerSupport

contact channels, availabil-ity, languages, responsetimes

current incidents / tickets (no information need identi-fied)

assessment of the life cycle modelling based on theobjectives and information needs listed in Sect. 3.2.The modelling of the example service is done bythe derivation of specific items from the LMLontology element classes. The correspondingrelationships are automatically created accordingto the LML specification by the modelling toolInnoslate (SPEC Innovations 2016), which wehave used for our research. Activity diagrams andgraphs are used to visualise the elements. Theterm “Graph” is used instead of “Spider Diagram”specified in LML. Spider diagrams typically havea different structure and meaning than the charttype in the LML specification.

Step 1 - Determine Stakeholders and their Rela-tionships. As the first step, relevant stakeholdershave been identified (similar to the perspectivesin a service blueprint). This way, the model isgiven an initial frame, which can be detailed fur-ther. The number of stakeholders to be includeddepends on the required level of detail in the mod-elling. It is not our intention to show how a servicecan be described as comprehensively as possible.Therefore, we have only taken a small numberof stakeholders taken into account. A selection

of stakeholders allows a first consideration of thelife cycle, i. e. stakeholder from different phasesof the life cycle should be considered (but ulti-mately not all have to be modelled). In additionto stakeholders, first relationships were also takeninto account. Relationships denote informationand material exchange between stakeholders. Anoverview of the stakeholder and their relationshipsof the example service is given in Fig. 3.

Besides the customer, who is at the centre of theservice, three companies are identified as externalpartners. The service provider communicates di-rectly with the customer and determines currentneeds for consumables. The provider passes therequest on to a wholesaler for plastics, which inturn informs a logistics provider. The logisticsprovider receives the required material from thewholesaler and delivers it to the customer. Emp-tied spools are returned by the customer to thelogistics service provider, who transports it to thewholesaler or disposer. Returning emptied spoolsis not part of the model.

Step 2 - Modelling Structure and Processes.Starting from the stakeholder network shown inFig. 3, some parts of the service were modelled



Fig. 3: Overview of stakeholder and important relationships

in more detail. Here, we differentiate static anddynamic elements:

Static elements comprise physical, software-based and abstract elements, which describe thestatic structure of a smart service system. In addi-tion to physical and software-based components,also abstract elements are defined. They are usedto realise different levels of detail in the form ofmodel layers. An overview of the essential ele-ments of the modelled smart service is providedin Tab. 6.

Dynamic elements relate to life cycle stages,processes and activities. The life cycle representsthe top level of the smart service. It consists of thethree phases of BOL, MOL, and EOL, as depictedin Fig. 4. The development phase of the smartservice generates a 3D printer which can determineand communicate information on the materialconsumption. Furthermore, a service platformis developed, to facilitate parts of the serviceprovisioning, e. g. billing. Service data is returnedfrom the operating phase into the developmentphase, where it is used for further improvementof the service.

The BOL and MOL phases of the top-levelmodel are further detailed into processes andinputs/outputs, as indicated by “decomposed”.Two model layers with details of the MOL phaseare shown in Fig. 5. The naming of child activitiesincludes the life cycle name and a sequentialnumber (top left of each box).

Graphs in LML represent the relationships be-tween the modelled elements. The relationshipsare specified by the LML ontology. If, for exam-ple, an element of the “Action” class is connectedto an element of the “Input/Output” class, the re-lationship is “generated” or its inverse “generatedby”. An example of a simple graph is shown inFig. 6. A disadvantage of the visualization viagraphs is the growing complexity if more thanjust the immediate neighbours of an item have tobe displayed. Fig. 7 shows the same example forthe input/output “Payment” with neighbouring el-ements of the second degree. The complete graphon the model represents all modelling levels. Tomake work with LML graphs meaningful, relevantparts must be filtered out.




Tab. 6: Core components of the smart service model

Description Form Note

3D printer Abstract Combines hardware and softwareHardware Physical Structure, mechanics and electronicsSoftware Software Data processingPrinting material Abstract Combines spool and plastic wireCoil Physical The plastic wire carrierPlastic wire Physical ConsumablesOperator platform Software Software of the service operator

Fig. 4: Representation of the life cycle as a top-level model

Relationships across life cycle phases are de-picted only for a case in our model: the materialfill level of the printer is created in the operationphase of the service and sent back in the devel-opment phase, together with the customer data,and performed orders for consumables. With theobtained information the service can be improvedin general or specifically for a certain customer.

An example of a possible data-based improve-ment is the use of the material fill level to optimisethe filament stock capacity in the printer. Thiscould be done, for example, on the basis of aparametrised CAD model of the printer. A design

approach for this purpose is provided by (Kleinet al. 2015). Another example is the adaptationof the smart service with regard to logistics: Ad-ditional material providers can be chosen basedon customer data and order quantities. Therewith,delivery times of consumables can be reducedaccordingly.

The way this improvement is depicted in themodel provides the benefit that the role of thelogistics provider (and optimization of relatedprocesses) is already considered in the design ofthe smart service. Therefore, a meaning and avalue can be assigned to data from the printer in



Fig. 5: Examples of MOL activities on different layers of the model

Fig. 6: Example of a graph for the input/output“Payment”

the development phase. Fig. 8 shows how the useof data for service improvements was modelled.

The complexity of the model and other charac-teristics are summarised in Tab. 7.

4 Discussion of the Modelling Approach

4.1 Review of Information NeedsIn this section, the proposed modelling approachfor the life cycles of smart services is discussedand evaluated. The hypothesis stated in the intro-duction will be verified. Its main assumption isthat life cycle modelling makes relations amongservice elements transparent and thus improvesthe identification of risks and fulfils various infor-mation needs. For the evaluation, the informationneeds of different roles (see Tab. 5) are compared

with the capabilities of the life cycle modellingapproach.

Marketing. In the BOL phase a key concernis the identification and documentation of cus-tomer needs. From the marketing perspective, theactivity diagram is not supporting this processsignificantly, as requirements cannot be modelledwith it. However, the graph diagram may contain“requirements” entities that are connected withother service components (e. g. activities). Thisway a traceability can be realised to support theidentification of problems introduced by changingrequirements or functions. Specific risks, such asmissing or erroneous requirements, may not beidentified through the graph. During the MOLphase, the feedback about customer satisfactionis a key indicator to measure success of the smartservice. For this purpose, the modelling approachmust consider dynamic data coming from themarket (e. g. a survey). Currently, the modellingapproach is not capable of satisfying this infor-mation need. In the EOL phase information isneeded, for instance, to understand the recyclingdemands of physical components. The modellingapproach supports the description of activitiesand input/outputs related to the EOL. Their rela-tion with other activities (e. g. redesign and legal




Fig. 7: Extended example of the graph for the input/output “Payment”

activities) may indicate risks, such as missing ac-tivities to manage legally mandatory take-back ofelectronics.

Development. During the BOL, the smart ser-vice hard- and software is designed. Activitydiagrams can help to visualise the functionalityand related technical requirements. In addition,data, material, energy and monetary flows canbe made transparent by establishing them as in-puts/outputs between activities. “Design for X”approaches, where “X” concerns, for instance lo-gistics, maintenance, recycling and reliability, canbe supported by incorporating specific activities,assets or characteristics into the life cycle model.

The MOL phase is interesting for designers, sincethe smart service components may be subject tofailures and insufficiencies. Since the life cyclemodelling approach is not supporting dynamicdata (e. g. field data), feedback from the MOLphase is not represented in the life cycle model.For the EOL phase, migration paths are an in-formation need. The developers need to plan,for instance, how non-supported service compo-nents (e. g. hardware and software) are exchanged.Possible migration paths can be described withactivities and by defining related requirement en-tities.



Tab. 7: Complexity of the LML model for consumables replenishment

Characteristic Manifestation in example LML model

Number of model elements 57 total: 31 actions, 7 assets, 19 inputs/outputsNumber of abstraction levels Maximum of 5 levels, e. g. smart service operation > customer processes

> printer > hardware-related functions > print object)Design of activity diagrams A maximum of 3 processes were used in activity diagrams, otherwise a

new abstraction layer was created.Used types of flows betweenprocesses

electronic and analogue information (e. g., sensor data, delivery note),material (e. g. consumables, empty spools), money (payment)

Fig. 8: Use usage information for the further develop-ment

Finance. During the BOL phase, the estimationof financial revenues and development cost can besupported by describing value streams in activitydiagrams with input/output entities. The activitiescan be related to assets representing different valuechain partners (e. g. suppliers). In addition, costentities can be assigned to almost any other entityto clarify, for instance, the amount, currency andfrequency of payments. The MOL phase and theEOL phase cannot be sufficiently supported withthe current modelling approach, since dynamicdata from business transactions (value streams)are not supported.

Procurement. In the BOL phase, LML maysupport the planning of the required types of itemsfrom different suppliers. The decomposition of

assets allows to model the service componentsand assign them with a “purchase” activity thatcan be performed by different suppliers (assets).Depending on the complexity of the supply chain,the model might become quite extensive and thusdifficult to manage (e. g. update in case a supplierchanges). The MOL phase is not supported well,due to the lack of real time data integration.

Logistics. During the BOL phase, specificvalues for the types and sizes of consumables mustbe identified. The different types of consumables,as well as their packages, can be defined as separateassets that are related to wholesalers. The sizeof the package or the products can be added withmeasure entities for length, width and height. Inaddition, the supply chain stakeholders and theiractivities can be modelled. The MOL and EOLphases, once more require dynamic data which isnot well supported in LML.

Customer Service. Important BOL-specific in-formation, such as contact channels, languagesand the definition of response time, can be de-scribed in a life cycle model with different entities.While channels can be modelled as resources,the language and response time can be definedwith characteristic or measure entities. DynamicMOL data, such as current incidents, are not wellsupported by LML.

The summary of evaluation results regardinginformation needs is shown in Tab. 8.

4.2 Review of General ObjectivesThe modelling approach is further evaluated ac-cording to the objectives defined in Sect. 3.2.




Tab. 8: Fulfilment of information needs of differentroles by life cycle phase

Role BOLneeds

MOLneeds

EOLneeds

Marketing No No YesDevelopment Yes No YesFinance Yes No NoProcurement Yes No NoLogistics Yes No -Customer Support Yes No -

• O1: Support the conception of product-relatedservices. The uniform description and expres-sions of LML, as well as the similarities withthe widely-used SysML standard, provide stake-holders involved in the design an easy access tothe creation and adaptation of the model. Fur-ther analyses during the conception phase maybenefit from the uniformly described model ele-ments. An example is the performance of a lifecycle cost calculation grounded on the informa-tion stored in the life cycle model (this possibil-ity is currently researched in the Manutelligenceproject). The specification of LML (version1.1) provides 12 entities and their relationshipsamong each other. In case that these originalentities are not sufficient to describe the conceptof an application case, new entities can be cre-ated by inheritance (i. e. the new entity inheritscharacteristics of its superordinate entity). In asimilar way, new relationships can be createdbetween entities. [fulfilled]

• O2: Allow an assessment of the service con-cept. The assessment of a service conceptcan be carried out from different perspectives(e. g. financially, technically, logistically andenvironmentally). Depending on the perspec-tive, different entity types must be added tothe model, for instance, cost entities in case ofthe financial department’s perspective. A keyissue of the modelling approach is that dynamiccharacteristics of service elements are not wellsupported. Each life cycle model is static, i. e.

it represents the system at a specific moment.Through the integration of additional softwaretools, the model may be updated with real timeinformation (a research question investigatedin Manutelligence). An example is the regularupdate of the market price of printing filament– this could be realized by updating the asso-ciated value of a cost entity. This way, thelife cycle model supports the assessment of thecurrent system status which is an informationneed emerging from the MOL and EOL phases.The assessment of risks, in particular, can berealised through risk entities. Whether all riskscan be modelled this way was not investigatedin this paper. Some risks may be relevant atcertain phases of the life cycle. In the case ofa complex smart service, risks may be causedby the relationship between service elements.For instance, if a service component that acts asan information source for other components isremoved, the whole service may be affected ina negative way unless the risk is addressed byappropriate measures. The time-dependencyof this example is related to the fact that onecomponent is in its EOL, while the others arestill in their MOL phase. [partly fulfilled]

• O3: Support the planning of capacity for re-sources. Resource planning and the identifi-cation of resource bottlenecks can be realisedwith resource entities. Modelling resourceswith LML is difficult, since they are eithercreated, seized or consumed. In the case of3D-printing, the consumable could be repre-sented by a resource entity that is created bythe wholesaler and consumed by the printingprocess. However, the logistics process nei-ther consumes nor seizes the consumable. Forthis reason, the consumable was representedby an input/output entity that moves betweenprocesses. The representation resources is notintuitive using LML. [not fulfilled]

The assessment of the objectives, given themodelled example case and the modelling envi-ronment (Innoslate), is summarised in Tab. 9. Forthe interpretation it must be noted that only one



example was modelled without a specific orga-nizational context. It is further worth of noticethat software support for LML is still rather poor(modelling environment).

Tab. 9: Assessment of general objectives

Objective Review

O1: Support the conceptionof product-related services

Fulfilled

O2: Allow an assessment ofthe service concept

Partly fulfilled

O3: Support the planning ofcapacity for resources

Not fulfilled

5 Conclusion and Outlook

The evaluation of the life cycle modelling of smartservices did not lead to a definite result. Theinitially stated hypothesis, information needs andgeneral objectives were assessed very differentlyfrom our perspective. The following paragraphscontain conclusions on aspects of the modellingapproach. At the end of each paragraph, potentialresearch questions and, in some cases, suggestionsfor literature are provided.

The collaborative design of life cycle models iswell supported by the applied modelling approach.LML’s ontology provides different entity typesand relations that reflect stakeholder perspectives.The relations are “speaking”, i. e. named to beeasily understood by stakeholders – they supportthe modelling process even though stakeholdersmight not have expert knowledge in modelling.Conflicts arising from discussions among differ-ent stakeholders were not covered in this paper.Research questions concern how a collaborativedesign of the life cycle model happens in practicalcases, which conflicts or problems occur and howthese issues could be mitigated. Previous work,for instance in Computer-aided Service Design(Laurischkat 2013), is a starting point for thisresearch.

The static nature of the model has been iden-tified as a weakness of the modelling approach.

However, it is an open question, whether a life cy-cle model should be designed more static or moredynamic. The integration of dynamic data, suchas product states, could satisfy several informationneeds of the MOL and EOL phase. An openresearch questions is how dynamic data could beintegrated into a life cycle model on the conceptuallevel and on the practical level (software).

The required level of detail of the life cyclemodel appears difficult to estimate in advance.We assume that the model itself evolves concur-rently along the life cycle, i. e. it starts simple inthe conceptualization phase and becomes morecomplex as new perspectives need to be consid-ered. With an increasing complexity of the model,the visualization methods proposed in the LMLstandard become difficult to read, especially thenet diagram. An option is to reduce the scope ofthe net visualization; however, the reduction maylimit the chances to identify potential risks andopportunities because a part of the system is nolonger visible to stakeholders. Research questionsconcern how risks and opportunities in smart ser-vices emerge and how their identification could besupported. During the research, a classification ofchallenges of PSS could be useful as proposed byKurak et al. (Di Francisco Kurak et al. 2013) aswell as previous work on understanding serviceuncertainties of PSS cost estimation (Erkoyuncuet al. 2011).

The lack of an item-level representation ofservice components and the limited functionsto consider dynamic system characteristics (e. g.data streams) are arguments against the use of thelife cycle model for the operational managementof a smart service. A research question is todetermine the benefits of using a common lifecycle model in the operation phase of a smartservice. The question is related to the existingresearch on Product Lifecycle Management, i. e.the management of product-related information(e. g. Demoly et al. 2013; Kiritsis 2011).

To gain more insight into life cycle modelling,additional real-world cases should be modelledand evaluated. Action-based research appear to be




a suitable methodology to determine how stake-holders develop and use the model. On this basis,best practices for modelling could be elaboratedto provide orientation to new users of LML re-garding structuring models and useful level ofmodel details. Finally, different modelling lan-guages (e. g. BPMN) should be evaluated againstthe requirements of different roles involved in theprocess of life cycle modelling. A starting pointcan be the information requirements identifiedin this paper. The result of such a comparisoncould clarify whether one language is sufficient todescribe the life cycles of smart services or not.In the latter case, the results might indicate thatdifferent modelling languages should be used inthe process.

References

Adrodegari F., Alghisi A., Ardolino M., SaccaniN. (2015) From Ownership to Service-orientedBusiness Models A Survey in Capital Goods Com-panies and a PSS Typology. In: Procedia CIRP 30,pp. 245–250

Aurich J. C., Schweitzer E., Siener M., Fuchs C.,Jenne F., Kirsten U. (2007) Life Cycle Manage-ment investiver PSS Gestaltung und Realisierunginvestiver Produkt-Service Systeme. In: wt Werk-stattstechnik online 97(7/8), pp. 579–585

Becker J., Beverungen D. F., Knackstedt R. (2010)The challenge of conceptual modeling for product–service systems Status-quo and perspectives forreference models and modeling languages. In:Information Systems and e-Business Management8 (1), pp. 33–66

Broy M., Cengarle M. V., Geisberger E. (2012)Cyber-Physical Systems: Imminent Challenges.In: Calinescu R., Garlan D. (eds.) Large-scalecomplex IT systems Development, operation andmanagement, 17th Monterey workshop 2012, Ox-ford, UK. LNCS 7539. Springer, Heidelberg andNew York, pp. 1–28

Canon Europe (2017) Total Service Care LargeFormat Solutions http : / / www. canon - europe .com/for_work/products/ large_format_printers/solutions_services/totalservicecare/ Last Access:2017-07-10

Corcelle C., Främling K., Rabe L., Anke J., PetrowJ. (2007) Assessment of item-specific informationmanagement approaches in the area of heavy loadvehicles. In: Garetti M., Terzi S., Ball P. D., Han S.(eds.) Proceedings of the International Conferenceon Product Lifecycle Management (PLM 2007).Inderscience Publishing, pp. 773–782

Demoly F., Dutartre O., Yan X.-T., Eynard B.,Kiritsis D., Gomes S. (2013) Product relationshipsmanagement enabler for concurrent engineeringand product lifecycle management. In: Computersin Industry 64 (7), pp. 833–848

Di Francisco Kurak C., Barquet A. P. B., Rozen-feld H. (2013) Challenges for PSS Implementation:Identification and Classification. In: Meier H. (ed.)Product-service integration for sustainable solu-tions Proceedings of the 5th CIRP InternationalConference on Industrial Product-Service Systems.Springer, Berlin, pp. 275–285

Erkoyuncu J. A., Roy R., Shehab E., Cheruvu K.(2011) Understanding service uncertainties in in-dustrial product–service system cost estimation.In: The International Journal of Advanced Manu-facturing Technology 52 (9-12), pp. 1223–1238

Falcon Consortium (2016) Feedback mechanismsacross the lifecycle for customer-driven optimiza-tion of innovative product-service design. http://www.falcon-h2020.eu/ Last Access: 2016-02-18

Fischer T., Gebauer H., Fleisch E. (2012) Ser-vice Business Development Strategies for ValueCreation in Manufacturing Firms. Cambridge Uni-versity Press, Cambridge

Fleisch E., Weinberger M., Wortmann F. (2015)Business Models and the Internet of Things. In:Podnar Žarko I., Pripužić K., Serrano M. (eds.)Interoperability and Open-Source solutions for theInternet of Things International Workshop, FP7


http://www.canon-europe.com/for_work/products/large_format_printers/solutions_services/totalservicecare/



http://www.falcon-h2020.eu/

http://www.falcon-h2020.eu/


OpenIoT Project. LNCS 9001 Vol. 9001. Springer,Cham, pp. 6–10

Funke J. (2012) Complex Problem Solving. In:Seel N. M. (ed.) Encyclopedia of the sciences oflearning. Springer reference. Springer, [Place ofpublication not identified], pp. 682–685

Gronau N., Bahrs J., Hake M., Heinze P., LembckeR., Scharff C., Vladova G. (2010) Wissensorien-tierte Modellierung im Lebenszyklus von Dien-stleistungen. In: Thomas O., Nüttgens M. (eds.) Di-enstleistungsmodellierung 2010. Physica-Verlag,Heidelberg, pp. 3–23

Hans C., Hribernik K. A., Thoben K. D. (2010)Improving reverse logistics processes using item-level product life cycle management. In: Interna-tional Journal of Product Lifecycle Management4 (4), p. 338

Hefnawy A., Bouras A., Cherifi C. (2016) IoT forSmart City Services. In: Boubiche D. E., HidoussiF., Guezouli L., Bounceur A., Cruz H. T. (eds.)Proceedings of the International Conference onInternet of Things and Cloud Computing the Inter-national Conference. ICC ’16. ACM, Cambridge,United Kingdom

Herterich M., Buehnen T., Uebernickel F., Bren-ner W. (2016) A Taxonomy of Industrial ServiceSystems Enabled by Digital Product Innovation.In: Proceedings of the 49th Hawaii InternationalConference on System Sciences (HICSS 2016).Koloa, HI, USA, pp. 1236–1245

Herterich M., Uebernickel F., Brenner W. (2015)The Impact of Cyber-physical Systems on Indus-trial Services in Manufacturing. In: Procedia CIRP30, pp. 323–328

Hoffmann H., Fähling J., Leimeister J. M., KrcmarH. (2009) Kundenintegration in die Innovation-sprozesse bei hybriden Produkten. In: Fischer S.,Maehle E., Reischuk R. (eds.) INFORMATIK -Jahrestagung der GI. LNI 154. GI, Lübeck

HP Inc. (2016) Instant Ink https : / / instantink .hpconnected.com/ Last Access: 2016-02-18

Junginger M., Loser K.-U., Hoschke A., WinklerT., Krcmar H. (2006) Kooperationsunterstützungund Werkzeuge für die Dienstleistungsentwick-lung: Die pro-services Workbench. In: BullingerH.-J., Scheer A.-W. (eds.) Service Engineering.Springer-Verlag, Berlin/Heidelberg, pp. 593–621

Kagermann H., Riemensperger F., Hoke D., Hel-big J., Stocksmeier D., Wahlster W., Scheer A.-W.,Schweer D. (2015) Smart Service Welt Umset-zungsempfehlungen für das Zukunftsprojekt Inter-netbasierte Dienste für die Wirtschaft, Abschluss-bericht Langversion

Kees A., Oberlaender A. M., Roeglinger M., Rose-mann M. (2015) Understanding the Internet ofThings: A Conceptualisation of Business-to-Thing(B2T) Interactions. In: Proceedings of the 23rd Eu-ropean Conference on Information Systems (ECIS2015). Münster, Germany

Kiritsis D. (2011) Closed-loop PLM for intelligentproducts in the era of the Internet of things. In:Computer-Aided Design 43 (5), pp. 479–501

Klein P., Luetzenberger J., Thoben K.-D. (2015) AProposal for Knowledge Formalization in ProductDevelopment Processes. In: Weber C., Husung S.,Cascini G., Cantamessa M., Marjanović D. (eds.)Proceedings of the 20th International Conferenceon Engineering Design (ICED15)

Klingner S., Becker M. (2012) Formal Modellingof Components and Dependencies for Configur-ing Product-Service-Systems. In: Enterprise Mod-elling and Information Systems Architectures 7(1), pp. 44–66

Knoke B., Thoben K.-D. (2014) Der Produktzus-tand als Basis für die Entwicklung produktnaherDienstleistungen. In: Thomas O., Nüttgens M.(eds.) Dienstleistungsmodellierung 2014 Vom Ser-vicemodell zum Anwendungssystem. Research.Springer Gabler, Wiesbaden, pp. 19–32

Kwak M., Kim H. (2013) Economic and Environ-mental Impacts of Product Service Lifetime: ALife-Cycle Perspective. In: Meier H. (ed.) Product-service integration for sustainable solutions Pro-ceedings of the 5th CIRP International Conference


https://instantink.hpconnected.com/

https://instantink.hpconnected.com/



on Industrial Product-Service Systems. Springer,Berlin, pp. 177–189Laurischkat K. (2013) Computer-Aided ServiceDesign for the Development of Product-ServiceSystems – Motivation and Benefits. In: Meier H.(ed.) Product-service integration for sustainablesolutions Proceedings of the 5th CIRP Interna-tional Conference on Industrial Product-ServiceSystems. Springer, Berlin, pp. 547–560Lindström J., Dagman A., Karlberg M. (2014)Functional Products Lifecycle Governed by sus-tainable Win-Win Situations. In: Procedia CIRP22, pp. 163–168LML Steering Committee (2015) Lifecycle Mod-eling Language (LML) Specification Version 1.1.http : / / www. lifecyclemodeling .org / spec / LML_Specification_1_1.pdf

Lützenberger J., Klein P., Hribernik K., ThobenK.-D. (2016) Improving Product-Service Systemsby Exploiting Information From The Usage Phase.A Case Study. In: Procedia CIRP 47, pp. 376–381Manutelligence Consortium (2016) Product Ser-vice Design and Manufacturing Intelligence Engi-neering Platform http://www.manutelligence.eu/Last Access: 2016-02-18Meis J., Menschner P., Leimeister J. M. (2010)Modellierung von Dienstleistungen mittels Busi-ness Service Blueprinting Modeling. In: ThomasO., Nüttgens M. (eds.) Dienstleistungsmodel-lierung 2010. Physica-Verlag, Heidelberg, pp. 39–64Meyer G. G., Främling K., Holmström J. (2009)Intelligent Products A survey. In: Computers inIndustry 60 (3), pp. 137–148Mikusz M. (2014) Towards an Understanding ofCyber-physical Systems as Industrial Software-Product-Service Systems. In: Procedia CIRP 16,pp. 385–389Mikusz M. (2015) Towards a Conceptual Frame-work for Cyber-Physical Systems from the Service-Dominant Logic Perspective. In: Proceedings ofthe 21st Americas Conference on InformationSystems. Puerto Rico

Neely A. (2008) Exploring the financial conse-quences of the servitization of manufacturing. In:Operations Management Research 1 (2), pp. 103–118

OMG (2011) Business Process Model and Nota-tion Version 2.0 http://www.omg.org/spec/BPMN/2.0

OMG (2015a) Systems Modeling Language Ver-sion 1.4 http://www.omg.org/spec/SysML/1.4/

OMG (2015b) Unified Modeling Language Ver-sion 2.5 http://www.omg.org/spec/UML/2.5

Porter M. E., Heppelmann J. E. (2014) How Smart,Connected Products Are Transforming Competi-tion. In: Harvard Business Review https://hbr.org/2014/11/how- smart- connected- products- are-transforming-competition

Psymbiosys Consortium (2016) Product-Servicesymbiotic systems http://www.psymbiosys.eu/Last Access: 2016-02-18

RepRap Project (2014) Fused Filament Fabri-cation http:/ / reprap.org/wiki /Fused_ filament_fabrication Last Access: 2015-12-21

Scheer A.-W., Grieble O., Klein R. (2004) Model-based Service Engineering. In: Geberl S. (ed.)Impulse aus der Wirtschaftsinformatik 1. Aufl..Physica-Verl., Heidelberg, pp. 17–33

Shaw N. (2014) Looking ahead: Is this the future?Canyon reveal new project bike http://enduro-mtb.com/en/ looking-ahead- is- this- the- future-canyon-presents-a-new-project-bike/ Last Access:2016-11-25

SPEC Innovations (2016) Systems Engineering& Requirements Management Tools | Innoslatehttps://www.innoslate.com/ Last Access: 2016-02-18

Tietze F., Schiederig T., Herstatt C. (2013) Firms’transition to green product service system inno-vators Cases from the mobility sector. In: Inter-national Journal of Technology Management 63(1/2), p. 51


http://www.lifecyclemodeling.org/spec/LML_Specification_1_1.pdf

http://www.lifecyclemodeling.org/spec/LML_Specification_1_1.pdf

http://www.manutelligence.eu/

http://www.omg.org/spec/BPMN/2.0

http://www.omg.org/spec/BPMN/2.0

http://www.omg.org/spec/SysML/1.4/

http://www.omg.org/spec/UML/2.5

https://hbr.org/2014/11/how-smart-connected-products-are-transforming-competition



http://www.psymbiosys.eu/

http://reprap.org/wiki/Fused_filament_fabrication

http://reprap.org/wiki/Fused_filament_fabrication

http://enduro-mtb.com/en/looking-ahead-is-this-the-future-canyon-presents-a-new-project-bike/



https://www.innoslate.com/


Umeda Y., Takata S., Kimura F., Tomiyama T.,Sutherland J. W., Kara S., Herrmann C., DuflouJ. R. (2012) Toward integrated product and processlife cycle planning—An environmental perspec-tive. In: CIRP Annals - Manufacturing Technology61 (2), pp. 681–702

Vasseur J.-P., Dunkels A. (2010) Interconnectingsmart objects with IP The next internet. ElsevierMorgan Kaufmann, Amsterdam, The Netherlands

Velamuri V. K., Bansemir B., Neyer A.-K.,Möslein K. M. (2013) Product Service Systems asa Driver for Business Model Innovation Lessonslearned from the Manufacturing Industry. In: In-ternational Journal of Innovation Management 17(1), pp. 1–25

Wellsandt S., Anke J., Thoben K.-D. (Feb. 2016)Modellierung der Lebenszyklen von Smart Ser-vices. In: Thomas O., Nüttgens M., Fellmann M.(eds.) Dienstleistungsmodellierung (DLM 2016).Springer, Berlin, Heidelberg, pp. 233–256

Wellsandt S., Hribernik K., Thoben K.-D. (2015)Sources and Characteristics of Information aboutProduct Use. In: Procedia CIRP 36, pp. 242–247

Westphal I., Freitag M., Thoben K.-D. (2015) Vi-sualization of Interactions Between Product andService Lifecycle Management. In: Umeda S.,Nakano M., Mizuyama H., Hibino H., KiritsisD., von Cieminski G. (eds.) Innovative Produc-tion Management Towards Sustainable Growth.IFIP Advances in Information and Communica-tion Technology 460. Springer, Cham, pp. 575–582

Wiesner S., Freitag M., Westphal I., Thoben K.-D.(2015) Interactions between Service and ProductLifecycle Management. In: Procedia CIRP 30,pp. 36–41

Winterhalter (2016) Pay-Per-Wash http://media.winterhalter.biz/mc/mediabase?assetId=418400&disposition=inline Last Access: 2017-07-10

Wolfenstetter T., Fuller K., Bohm M., Krcmar H.,Brundl S. (2015) Towards a requirements traceabil-ity reference model for Product Service Systems.In: Framinan J. M. (ed.) The road ahead: under-standing challenges and grasping opportunities inindustrial and systems engineering IESM (Seville,Spain). Piscataway, NJ, pp. 1213–1220

Wortmann F., Flüchter K. (2015) Internet ofThings. In: Business & Information Systems En-gineering 57 (3), pp. 221–224

Zolnowski A., Christiansen T., Gudat J. (2016)Business Model Transformation Patterns of Data-Driven Innovations. In: Proceedings of the 24thEuropean Conference on Information Systems(ECIS 2016). Istanbul, Turkey

This work is licensed undera Creative Commons“Attribution-ShareAlike 4.0International” license.


http://media.winterhalter.biz/mc/mediabase?assetId=418400&disposition=inline



https://creativecommons.org/licenses/by-sa/4.0/deed.en




modelling of a smart service for consumables replenishment

Documents