Available online at www.sciencedirect.com
ScienceDirect
Procedia 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
a
Fraunhofer 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
b
* Corresponding author. Tel.: +49-30-39006-133; fax: +49 30-391-1037. E-mail address: [email protected]
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 (IPS²), 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 IPS² 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.
©
Authors.
Published
by Elsevier
B.V This
is an open access article under the CC BY-NC-ND license
©2016
2016The
The
Authors.
Published
by Elsevier
B.V.
(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.
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 (IPS²) are characterized by the
integrated development and delivery of product and service
shares in the industrial area [2]. The IPS² provider develops a
solution that offers high customer individuality [2,3]. An
objective of Industrial Product-Service Systems (IPS²) 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 errorprone.
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
Eckart Uhlmann et al. / Procedia CIRP 47 (2016) 240 – 245
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 BPMNbased 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
241
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 IPS²
In the IPS² 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 IPS² 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 variantspecific organizational and IT infrastructures [16].
Uhlmann et al. developed a method to model the business
process of a relationship between an IPS² provider and a
customer efficiently. Therefore reusable process fractals were
applied. Furthermore, the method allows the simulation and
optimization of the customer individual IPS² business process
[17].
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
Eckart Uhlmann et al. / Procedia CIRP 47 (2016) 240 – 245
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 humanmachine 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 IPS²
development. However, there exists a lack of approaches to
support the IPS² delivery. Therefore, the goal of this paper is
the development of a service support system for the
application in the IPS² 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.
Service
technician
Service
Techniker
Service
Techniker
with
mobile
service
device
mit
mitmobilem
mobilemService
ServiceDevice
Device
Machine tool
Produktionsanlage
Produktionsanlage
Data
1
2
3
Internet
242
Instructions
Data
DB
XML
Data
MO²GO
Service process logic
Central Server
Service
S
i process model
d l
Fig. 1. Principle structure of the ICT based support scenario.
243
Eckart Uhlmann et al. / Procedia CIRP 47 (2016) 240 – 245
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 MO²GO, 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
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)
Produkt
Activity
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).
Changes the condition of a product
Client App
Aktion
Resource
All needed objects necessary to perform an
activity, e. g. web service call to invoke a
test routine on the machine tool
Ressource
Sequence
Activities are performed successively
Parallel branching
Activities are performed parallel; parallel
activities have to be completed before the
next activity can be started
Web Server
INCOServer
IMP-MAS
Service
Configuration
SOAP Request
DLL Call (JNI)
RPC
Distinction of cases
Depending on the result of the first activity
only one of the following activities will be
started
X=1
X=0
RETURN Value
Junction
The last activity will only be started if all
linked previous activities are completed
RETURN Value
SOAP Response
Loop
X=1
X=0
The activity in the loop will be performed
until the condition for starting the next
activity is met
(Fault/Content)
Fig. 2. Interaction between mobile device client and machine tool control in a
distributed environment.
244
Eckart Uhlmann et al. / Procedia CIRP 47 (2016) 240 – 245
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
isEmergencyStop
Verifies if the emergency stop is
pushed
setIdleMode
Switches the machine tool to idle
mode
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
error
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 MO²GO 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 MO²GO 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
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-valueadding 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.
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
check service
door
contouringTest
_done={false}
close service
door
service door
closed
isServiceDoorClosed
_done={false}
execute
web service
isServiceDoor
Closed
Fig. 3. Process extract of the contouring test concerning the door status detection.
isServiceDoorClosed
_done={true}
Eckart Uhlmann et al. / Procedia CIRP 47 (2016) 240 – 245
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 MO²GO. 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
MO²GO 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
ganzheitliche
Mensch-Maschine-Interaktion
–
durch
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 SMEinnovative 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 (IPS²) – Proceedings of the
1st CIRP IPS² 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.
245
[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 eMaintenance. 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. MO²GO: 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.