Scholarly article on topic 'Situation Adapted Field Service Support Using Business Process Models and ICT Based Human-Machine-Interaction'

Situation Adapted Field Service Support Using Business Process Models and ICT Based Human-Machine-Interaction Academic research paper on "Computer and information sciences"

CC BY-NC-ND
0
0
Share paper
Academic journal
Procedia CIRP
OECD Field of science
Keywords
{Service / Diagnosis / Human-Machine-Interaction / ICT / "Industrial Product-Service Systems"}

Abstract of research paper on Computer and information sciences, author of scientific article — Eckart Uhlmann, Claudio Geisert, Niels Raue, Christian Gabriel

Abstract The use of conventional service manuals is still common among service technicians during on-site support. If problems occur during the service process, service technicians have to analyze the situation and react accordingly. Problem analysis is subject to uncertainty in time, because the optimal course of action strongly depends on the current situation. Therefore, intelligent situation adapted support is needed to replace static guidance. This article describes a concept for the generation of interactive and situation adapted service instructions that are dynamically derived from a service process model. After a brief introduction to on-site service support, the article describes in detail how service processes can be modelled by using the method of Integrated Enterprise Modeling (IEM). Subsequently, it shows how and in which phases automated test routines can be used to support the service process, followed by a critical discussion of possible information and communication technology (ICT) architectures to implement human-machine-interaction. The concept includes an ICT-based approach for human-machine-interaction to trigger test routines on the machine to receive information about the condition of the machine. For Industrial Product-Service Systems (IPS2), the presented approach offers several benefits compared to existing approaches. These include the ability of tracking and influencing service processes as well as the simple adaption of new IPS2 modules in case of changing business models or customer requirements. The article concludes giving a specific scenario and an outlook on future research to be done.

Academic research paper on topic "Situation Adapted Field Service Support Using Business Process Models and ICT Based Human-Machine-Interaction"

Available online at www.sciencedirect.com

MHr ScienceDirect

ELSEVIER Procedía CIRP 47 (2016) 240 - 245

Product-Service Systems across Life Cycle

Situation Adapted Field Service Support Using Business Process Models and ICT Based Human-Machine-Interaction

Eckart Uhlmanna'b, Claudio Geiserta*, Niels Raueb, Christian Gabrielb

aFraunhofer Institute for Productions Systems and Design Technology IPK, Pascalstraße 8 — 9, 10587 Berlin, Germany institute for Machine Tools and Factory Management, Technical University Berlin, Pascalstraße 8 — 9, 10587 Berlin, Germany

* Corresponding author. Tel.: +49-30-39006-133; fax: +49 30-391-1037. E-mail address: claudio.geisert@ipk.fraunhofer.de

www.elsevier.com/looate/procedia

Abstract

The use of conventional service manuals is still common among service technicians during on-site support. If problems occur during the service process, service technicians have to analyze the situation and react accordingly. Problem analysis is subject to uncertainty in time, because the optimal course of action strongly depends on the current situation. Therefore, intelligent situation adapted support is needed to replace static guidance. This article describes a concept for the generation of interactive and situation adapted service instructions that are dynamically derived from a service process model.

After a brief introduction to on-site service support, the article describes in detail how service processes can be modelled by using the method of Integrated Enterprise Modeling (IEM). Subsequently, it shows how and in which phases automated test routines can be used to support the service process, followed by a critical discussion of possible information and communication technology (ICT) architectures to implement human-machine-interaction.

The concept includes an ICT-based approach for human-machine-interaction to trigger test routines on the machine to receive information about the condition of the machine. For Industrial Product-Service Systems (IPS2), the presented approach offers several benefits compared to existing approaches. These include the ability of tracking and influencing service processes as well as the simple adaption of new IPS2 modules in case of changing business models or customer requirements. The article concludes giving a specific scenario and an outlook on future research to be done.

© 2016 The Authors.PublishedbyElsevier B.V Thisisan open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/).

Peer-review under responsibility of the scientific committee of the 8th Product-Service Systems across Life Cycle Keywords: Service; Diagnosis; Human-Machine-Interaction; ICT; Industrial Product-Service Systems

1. Introduction

Services play an important role in today's manufacturing industry. They generate customer value and substantially contribute to ensuring long-term market success [1]. Industrial Product-Service Systems (IPS2) are characterized by the integrated development and delivery of product and service shares in the industrial area [2]. The IPS2 provider develops a solution that offers high customer individuality [2,3]. An objective of Industrial Product-Service Systems (IPS2) is the guarantee of a specific machine tool's availability.

Within the portfolio of industrial services especially maintenance, repair, and overhaul (MRO) activities are indispensable to reach a high technical availability of

production systems. They are often characterized by complex root cause analysis and situation-dependent measures. Even well-trained service technicians need a considerable amount of time for advanced analyses or even need to abort the service call due to an inaccurate preliminary diagnosis. Furthermore, many steps of a typical MRO process are carried out manually and are therefore time-consuming and error-prone.

One result of a recent survey, carried out within the research project on which this paper is based upon, is that even though almost 90 % of field service technicians are equipped with laptops, paper documents are the second most common information source within on-site service delivery. Another finding is that active assistance in the technical

2212-8271 © 2016 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/).

Peer-review under responsibility of the scientific committee of the 8th Product-Service Systems across Life Cycle doi: 10.1016/j.procir.2016.03.227

diagnosis, provision of information and checklists with process steps are regarded as the most helpful support functions [4]. A basic architectural approach to realize such functions is the concept of service-oriented architectures. Although the technology of web services has already been realized in industrial applications [5,6], it is novel for enhancing the process execution during service field deployments.

2. State of the Art

2.1. Process Modeling Methods

In the scope of the paper the process modeling method is an essential issue. The three methods Integrated Enterprise Modeling (IEM), Business Process Model and Notation (BPMN), and Event-driven Process Chain (EPC) were identified.

The method of IEM was developed in the late 1980s by the Fraunhofer Institute for Production Systems and Design Technology IPK, Berlin, Germany. It was originally designed to support the transparent description of business processes and their interdependencies to enterprise architecture elements, e. g. for organization, systems, products, and control [7]. The IEM is compliant with ISO 19440 "Constructs for Enterprise Modelling". IEM uses the four basic objects order, product, resource, and activity. These can be logically interconnected by using five basic linkage types to describe processes [8].

IBM, Armonk, USA, developed the BPMN method that was published in 2004 by the Business Process Management Initiative (BPMI). In 2006 the Object Management Group (OMG) recognized BPMN as a standard [9]. The description of processes according to BPMN consists of a set of activities, events, gateways, and sequence flows [9,10]. Since 2011, after publishing version 2.0, the BPMN standard additionally describes a meta model. As a consequence, the applicability of BPMN has been expanded, as process models are now executable in process engines [11]. A rising amount of IT tools exist for modeling, simulation, and execution of BPMN-based process models. Their functionalities differ mainly by means of simulation possibilities and whether they are open source or not. The increasing interest in BPMN has been underlined through company takeovers from Lombardi, Austin, USA, and Inubit, Berlin, Germany, performed by IBM, Armonk, USA, and Bosch Software Innovations, Berlin, Germany.

Another method for process modeling is EPC. It has been developed collaboratively at the Institute for Information Systems of the University of Saarland, Saarbruecken, Germany, together with SAP, Walldorf, Germany, and was published in 1992 [12]. According to EPC, a process consists of a sequence of events triggering business functions. Initial events are triggering the whole process. The modeling of boolean operators, e. g. and, or, exclusive or, allows complex control flows and therefore the representation of business relevant decisions [13]. A group of systems, that supports all stations of Business Process Management (BPM) with EPC, is called ARIS - Process Platform. The linkage between

modeling and execution has been realized among others by the development of ARIS for mySAP, which allows the implementation of processes within a SAP system [14].

2.2. Process Modeling Approaches for IPS2

In the IPS2 community several approaches for the modeling of service processes were developed and discussed. Thereby, two different types of solutions are mentionable. On the one hand methods and tools exist which consider heterogeneous service knowledge held by actors with very different expertise in the development phase. On the other hand approaches exist which provide reusable process models to configure different customer-provider-relationships over the entire lifecycle.

An approach developed by Laurischkat is referred to as Computer-aided Service Design (CASD). The goal is to systematically consolidate, archive and context-sensitively reuse heterogeneous service information during the early stage of the IPS2 development. Therefore, CASD offers interactive user assistance for the reduction of time and costs in the mentioned life cycle phase [15].

Beverungen et al. applied the concept of configurative modeling to the discipline of Service Engineering and proposed a procedure model for corrective maintenance service processes in the mechanical engineering industry. The application of configurable conceptual models allow the reduction of time and cost efforts for developing variant-specific organizational and IT infrastructures [16]. Uhlmann et al. developed a method to model the business process of a relationship between an IPS2 provider and a customer efficiently. Therefore reusable process fractals were applied. Furthermore, the method allows the simulation and optimization of the customer individual IPS2 business process

3. Scenarios

3.1. Field Service Scenario (Classical Case)

A service call from a customer is received by the service center of the machine tool manufacturer due to machine dysfunction. After an unsuccessful attempt to solve the problem via phone and remote access to the machine control system, an on-site service deployment is chosen as a remedial measure. The service technician procures information about the machine type and its service history from the local enterprise resource planning (ERP) system and prepares the paper-based diagnostic manual and needed tools before going to the customer. On-site the technician starts troubleshooting by working through the checklist of the diagnostic manual. Thereby the sequence of work steps is strongly depending on the particular diagnostic result. The technician has to interact with the machine in manifold ways for the diagnosis. Furthermore, the technician has to assess the current status by checking the alarm log of the machine control system and determining the condition of hardware component using component specific testing methods and tools. To do this the technician often has to bring the component under consideration into a defined state before measuring

parameters relevant for diagnosis. According to the particular result the process continuous by performing a repair process step or further diagnostic process steps. After finally having eliminated the failure, performed several verification tests, and brought the machine back to operation, the service technician completes his activities by drawing up a service report.

This course of action is very time consuming because it consists of many manual activities like preparing and performing tests as well as reading out parameters. It also bears the risk that the service technician does not take the optimal sequence of diagnostic process steps or makes a wrong decision due to incorrect reading or transferring of measuring data. Taking a closer look to the scenario described above, it is obvious that many of the process steps can be executed quite automatically. In addition, there exists a great potential to optimize the sequence of diagnostic process steps by substituting the paper-based diagnostic manual by an interactive software application that allows ICT based human-machine interaction, supports the service technician in decision making, and guides him through the diagnostic process. Having in mind these optimization measures the scenario, starting from the point of preparing the service deployment, changes towards the following.

3.2. Field Service Scenario (With ICT Based Support)

The service technician transfers the process model that contains all possible diagnostic process steps and their interdependencies for a specific machine tool from the ERP system to his mobile service device. Knowing the interdependencies between the single process steps the model is able to combine the process steps in the right order depending on the results of each single step. On-site the technician initiates troubleshooting by connecting his mobile service device to the machine's Human-Machine Interface (HMI) and starts the interactive software application. As a consequence, the application communicates with the HMI, checks its ID, and reads out parameters relevant for the diagnosis. Depending on the assessed machine state the next process step is calculated by the application, guiding the service technician through the process by displaying descriptive instructions on the mobile service device. Using services for test routines provided by a service platform on the HMI of the machine, the service technician is able to perform the test by clicking the start button on the mobile service device. A parameterized request is sent to the web service and triggers an automated test routine. During or after this test routine, measurement data from the control unit is acquired and processed by the service application and sent back to the interactive software application on the mobile service device. Depending on the transferred content the application calculates the next process step. In this way, the application guides the service technician through the whole diagnostic process until the failure cause is found and eliminated. By storing the result of each performed process step, a manual drawing of a service report becomes redundant. It is easy to see that a service deployment supported in such a way relieves the service technician and allows him to concentrate on activities that cannot be performed in an automated way. Due to the automated performance of test routines, data acquisition

and transfer, decisions within the diagnostic process are less prone to errors and the whole process becomes more transparent, efficient, and value adding.

4. Development of the Field Service Support System

The analysis of the state of the art shows comprehensive results for modeling methods useable in the IPS2 development. However, there exists a lack of approaches to support the IPS2 delivery. Therefore, the goal of this paper is the development of a service support system for the application in the IPS2 use phase.

In the next paragraphs it is shown how the service support system is built up for human-machine interaction in the context of field service. Starting from a concept and the selection of a process modeling method, a process model and the implemented web services will be described for a specific scenario in maintenance, repair, and overhaul of an automation system.

4.1. Concept of the Field Service Support System

The structure of the field service support system consists of a server-client principle, see Fig. 1. The mobile device of the service technician functions as a client which has access to a central server and the machine tool control. The central server is the data backbone as it provides the process models for the field support and historical data. The consideration of historical data is necessary to detect possible trends over time, e. g. the development of wear.

4.2. Approach for Service Process Modeling and Execution

The requirements of service technicians during field service deployment have to be considered for the implementation of a support system. Therefore, the attention to process modeling as well as execution is necessary.

Central Server

i j ¡ i

Service process model

Fig. 1. Principle structure of the ICT based support scenario.

Regarding process modeling, the process flow of field service support depends on the type of machine tool or devices. That leads to the requirement to model processes efficiently. Furthermore, during field service deployment a permanent linkage to IT resources of the service center via internet cannot be guaranteed. Thus, software-as-a-service solutions do not seem to be appropriate. Activities in field service deployment require a continuous interaction with the machine tool control unit. The sequence of these activities is not necessarily rigid. Therefore, the experience of the service technician should influence the chronological order in some cases.

For the implementation of the field service support system the usage of IEM seems to be fruitful. To model the service process the graphical modeling tool MO2GO, also developed by Fraunhofer IPK, is used [8]. Therefore, the structure of the XML (extensible Markup Language) exchange format is well known which is necessary for the data exchange between the different software applications. To generate a Graphical User Interface (GUI) with interactive and situation adapted service instructions the XML representation of a modeled service process is used. The application imports the XML file and interprets its objects and relations to build the above mentioned GUI. In case of a field service deployment a service technician usually performs different process steps in a sequence depending on the specific situation found on-site.

Table 1. IEM objects and linkage types used for service process modeling.

Objects and linkage types

Description

Product

Activity

Resource

Sequence

Parallel branching Distinction of cases Junction

All objects that are changed by activities during a field service deployment, e. g. the product "machine tool with failure" (start condition) is changed by the activity "performing service deployment" towards the product "machine tool without failure" (final condition)

Changes the condition of a product

All needed objects necessary to perform an activity, e. g. web service call to invoke a test routine on the machine tool

Activities are performed successively

Activities are performed parallel; parallel activities have to be completed before the next activity can be started

Depending on the result of the first activity only one of the following activities will be started

The last activity will only be started if all linked previous activities are completed

The activity in the loop will be performed until the condition for starting the next activity is met

A single process step can be regarded as an autonomous module that is activated by a start condition. During the service process this start condition is changed towards a final condition by activities that may use different resources.

Within the approach described in this paper only three objects but all linkage types are used for modeling a service process. Table 1 lists the used objects and linkage types and gives a description about how to interpret them in the context of the presented work.

4.3. Communication Architecture

To realize interaction between the client application on the mobile service device, the central server, and the machine tool, an appropriate communication architecture for distributed systems is needed. After shortlisting the two potential communication architectures, thin client and fat client, the fat client architecture was identified as the most suitable solution and was implemented. The main reason for this decision is that a thin client usually does not provide large system capacities which are needed for local data storage and processing. These abilities are required to locally handle additional data from the service center since it cannot be guaranteed, as already mentioned, that a permanent link to IT resources of the service center via internet is always available.

The interaction between the mobile device, the machine tool unit and the central server is comprehensible in a Unified Modeling Language (UML) sequence diagram, see Fig. 2. To start a test routine on the machine tool from the mobile service device a web server is implemented on the HMI on which a second application (INCOServer) for remote control of the machine control system (IMP-MAS) is also active. This application allows reading and writing of registered variables on the one hand and, on the other hand, starting of predefined procedures via Remote Procedure Call (RPC).

Service Configuration

SOAP Request

DLL Call (JNI)

RETURN Value i-------

RETURN Value k=---------

SOAP Response |<-----------

(Fault/Content)

Fig. 2. Interaction between mobile device client and machine tool control in a distributed environment.

Table 2. Web services for field service support.

Web service name Description

isAutomaticMode Verifies if the machine mode is

automatic mode

isReady Verifies if the machine is ready

getVersionByAxis Reads out the software version of a

feed axis

isEmergency Stop Verifies if the emergency stop is

pushed

setIdleMode Switches the machine tool to idle

isServiceDoorClosed Verifies if the service door is closed

gripperTest Checks the current status of the

gripper

lightBarrierTest Checks the current status of the

light barrier

softwareUpdate Checks the current version of the

control unit and updates it if needed

contouringTest Initiates an feed axis test run and

gives back the current contouring

RPC is a technology for inter-process communication while communication between the client application on the mobile service device and the web server is done using SOAP (Simple Object Access Protocol).

After having described the process steps in general to set up the MO2GO model, all steps with potential of being performed in an automated way have to be identified. Afterwards the routines have to be implemented on the INCOServer, and specific web services have to be defined to parameterize and trigger the routines. To describe the functionality of the web service the XML-based Web Service Description Language (WSDL) is used. Finally the web service call is modeled in MO2GO as an attributed resource whereby the attributes represent the web service call string with the Uniform Resource Locator (URL) of the specific web service as well as the needed input parameters.

5. Application of the Field Service Support System

The field service support system has been evaluated by means of its application for maintenance, repair, and overhaul of an automation system. That system allows the automatic

mounting of different machines and is suitable for work pieces, electrodes, and milling tools. To demonstrate the functionality of the system precisely, a part of an axis contouring test will be described. The frequent execution of this test is necessary for the detection of slippage inside the drive and the adjustment of the belt tension afterwards.

Table 3 provides a selection of realized web services and their description, which are relevant for the contouring test.

In the run-up of the contouring test the variable contouringTest_done is set to false, see Fig. 3. To start the test the service door has to be closed manually by the service technician. The condition of the automation system will be changed to service door closed. As it refers to a safety critical activity as well as it is performed manually, an additional check is necessary. Therefore, a web service will be executed which is called isServiceDoorClosed. If the service door is closed, the check has been succeeded. Otherwise, a feedback loop will be entered, to detect a possible dysfunction. In that manner the whole contouring test is implemented. Thus, the functionality of the presented approach has been evaluated.

6. Summary and Discussion

This paper describes an approach to generate interactive and situation adapted service instructions based on service process models to relieve service technicians from non-value-adding processes. Furthermore, a concept is presented that shows how to integrate web services for human-machine interaction in the context of field service.

This approach has been implemented in cooperation with a leading provider of project and service management systems. The evaluation, performed on a CNC controlled industrial handling system, showed that the interface between the machine tool control and the field service support system allows the visualization of additional action alternatives based on sensor data. Furthermore, the storage of executed field service delivery enables the building of an automatically expanded knowledge data base. Therefore, the software acts as a helpdesk for the service technician that provides information, video sequences, and links to additional data at the right time.

check service

contouringTest done={false} —o»—o close service door

service door closed

1 isServiceDoorClosed done={false}

execute web service

i sServiceDoo Closed r

isServiceDoorClosed _done={true}

Fig. 3. Process extract of the contouring test concerning the door status detection.

As a consequence diagnoses are more independent as decisions are subjected, not merely to the knowledge of a single service technician, but to the implemented knowledge management system. Nevertheless, it is important to note that modeling of service processes as well as the development of test routines for diagnostic purposes involves high effort and respective costs in the development phase. The advantage of saving time and money due to an optimized and therewith efficient field service delivery becomes apparent in the operational phase of a production system and takes some time to equalize the above mentioned costs. Taking this aspect into account, there is still substantial need for further research on more intuitive modeling technologies to decrease time for modeling.

BPMN and EPC seem appropriate as an alternative to model processes using IEM and MO2GO. BPMN and EPC focus on modeling while IEM is broader in scope. Furthermore, BPMN2.0 and EPC allow the development of executable models without the detour via an own developed application that has to interpret the XML representation of a MO2GO model.

7. Acknowledgements

We express our sincere thanks to the German Federal Ministry of Education and Research (BMBF) for funding this research within the collaborative research project "Wertschöpfungssteigerung im Maschinen- und Anlagenbau durch ganzheitliche Mensch-Maschine-Interaktion -Integration von Maschinendaten in Produktions- und Serviceprozesse" (Adding Value in Machine and Plant Manufacture by Holistic Human-Machine-Interaction -Integration of Machine Data into Production and Service Processes), funding code 01IS12048, under the SME-innovative program "Information- and Communication Technology".

References

[1] Schuh G, Gudergan G. Service Engineering as an Approach to Designing Industrial Product Service Systems. In: Rajkumar R, Essam S, editors. Industrial Product-Service Systems (IPS2) - Proceedings of the 1st CIRP IPS2 Conference. Cranfield: Cranfield University Press; 2009. p. 1-7.

[2] Baines TS, Lightfoot H, Steve E, Neely A, Greenough R, Peppard J, Roy R, Shehab E, Braganza A, Tiwari A, Alcock J, Angus J, Bastl M, Cousens A, Irving P, Johnson M, Kingston J, Lockett H, Martinez V, Michele P, Tranfield D, Walton I, Wilson H. State-of-the-art in product service-systems. Proc Inst Mech Eng, B J Eng Manuf 2007; 221:10 1543-1552.

[3] Tukker A, Tischner U. New business for old Europe - Product-service development, competitiveness and sustainability. Sheffield: Greenleaf; 2006.

[4] Uhlmann E, Raue N, Geisert C. Unterstützungspotenziale der Automatisierungstechnik im technischen Kundendienst. Summary of an explorative survey on best pactices in field service. Berlin: Fraunhofer IPK; 2013.

[5] Hohwieler E, Geisert C. Intelligent Machines Offer Condition Monitoring and Maintenance Prediction Services. In: Teti R, editor. Proceedings of the 4th CIRP International Seminar on Intelligent Computation in Manufacturing Engineering (CIRP ICME '04). 30 June -2 July 2004, Sorrento, Italy; 2004. p. 599-604.

[6] Hohwieler E, Berger R, Geisert C. Condition Monitoring Services for e-Maintenance. In: Zaremba M, Sasiadek J, Erbe HH, editors. A proceedings volume from the 7th IFAC Symposium, Gatineau, Québec, Canada, 6-9 June 2004. Oxford: Elsevier; 2005. p. 239-244.

[7] Spur G, Mertins K, Jochem R. Integrated Enterprise Modelling. Berlin: Beuth; 1996.

[8] Mertins K, Jaekel FW. MO2GO: User Oriented Enterprise Models for Organisational and IT Solutions. In: Schmidt G, Mertins K, Bernus P, editors. Handbook on architectures of information systems. Berlin, New York: Springer; 2006. p. 649-663.

[9] Allweyer T. BPMN 2.0 - Introduction to the Standard for Business Process Modeling. Norderstedt: Books on Demand; 2010.

[10] Object Management Group: Business Process Model and Notation (BPMN) - Version 2.0.2; 2013. URL: http://www.omg.org/spec/ BPMN/2.0.2/PDF/ (access: 16-01-06).

[11] Joschko P, Haan J, Janz T, Page B. Business Process Simulaton with IYOPRO and DESMO-J. In: Bruzzone AG, Buck W, Cayirci E, Longo F, editors. Proceedings of the International Workshop on Applied Modeling & Simulation, Rome, Italy, September 24th - 27th, 2012. Rende: DIME Universita die Genova; 2012. p. 125-132.

[12] Scheer AW, Thomas O, Adam O. Process Modeling Using Event-Driven Process Chains. In: Dumas M, van der Aalst W, ter Hofstede AHM, editors. Process-Aware Information Systems - Bridging People and Software through Process Technology. Hoboken: Wiley-Interscience; 2005, p. 119-145.

[13] Nüttgens M, Feld T, Zimmermann V. Business Process Modeling with EPC and UML - Transformation or Integration? In: Schader M, Korthaus A, editors. The Unified Modeling Language - Technical Aspects and Applications, Proceedings 1. GROOM-Workshop (Mannheim, Oktober 1997). Heidelberg: Physica; 1998, p. 250-261.

[14] Scheer AW, Schneider K. ARIS - Architecture of Integrated Information Systems. In: Bernus P, Mertins K, Schmidt G, editors. Handbook on Architectures of Information Systems. Berlin, New York: Springer; 2006, p. 605-623.

[15] Laurischkat K. Computer-Aided Service Design for the Development of Product-Service Systems - Motivation and Benefits. In: Meier H, editor. Product-Service Integration for Sustainable Solutions - Proceedings of the 5th CIRP International Conference on Industrial Product-Service Systems, Bochum, Germany, March 14th-15th, 2013. Heidelberg: Springer; 2013. p. 547-560.

[16] Becker J, Beverungen D, Knackstedt R, Matzner M. Configurative Service Engineering - A Rule-Based Configuration Approach for Versatile Service Processes in Corrective Maintenance. In: Proceedings of the 42nd Hawai'i International Conference on System Sciences (HICSS '09), Waikoloa, Big Island, Hawaii, USA; 2009.

[17] Uhlmann E, Gabriel C, Raue N. An Automation Approach Based on Workflows and Software Agents for Industrial Product-Service Systems. Procedia CIRP 2015; 30 341-346.