Process-Driven Approach within the Engineering Domain by Combining Business Process Model and Notation (BPMN) with Process Engines

Abstract

Digitization within the framework of Industry 4.0 is considered the biggest and fastest driver of change in history of manufacturing industry. While the size of a company is becoming less essential, the ability to adapt quickly to changing market conditions and new technologies is more important than ever. This trend particularly applies to the companies’ software landscapes, where individual sub-processes and services must be orchestrated, seamlessly integrated, and iteratively renewed according to the ever-increasing user requirements. However, inflexible, closed monolithic software applications as well as self-programmed stand-alone tools that are difficult to integrate are still predominant in the engineering domain. A complete reimplementation of existing, proprietary engineering tools and their integration into monolithic applications of large software providers is often not economically feasible, especially for small and medium-sized machinery and plant manufacturers. In this context, the so-called Process-Driven Approach (PDA) offers a sustainable and tool-neutral opportunity for process and tool orchestration, enabling an easy integration of individual software applications by consistent utilization of the separation of concerns principle. The PDA, originating from business informatics, is mainly based on the standardized and machine-executable visual modeling language Business Process Model and Notation (BPMN). Using the semantic enhancements found in version 2.0, BPMN is not just used to model the business processes but also to model and execute the integration processes between different systems. After the PDA has already been successfully applied to large-scale projects in business informatics, it is now being transferred to the engineering domain. As shown in this paper, PDA allows to orchestrate the different processes in engineering and to integrate the underlying software tools, such as e-mail or spreadsheet applications, engineering tools, or custom microservices, using standardized interfaces like REST API. In doing so, engineering processes can be made more transparent, monitored, and optimized by means of appropriate key figures. The concept is validated by a prototypical implementation of a minimum functional PDA architecture for the engineering domain.

Full text

ScienceDirect
Available online at www.sciencedirect.com
Available online at www.sciencedirect.com
ScienceDirect
Procedia CIRP 00 (2017) 000–000
www.elsevier.com/locate/procedia
2212-8271 © 2017 The Authors. Published by Elsevier B.V.
Peer-review under responsibility of the scientific committee of the 28th CIRP Design Conference 2018.
28th CIRP Design Conference, May 2018, Nantes, France
A new methodology to analyze the functional and physical architecture of
existing products for an assembly oriented product family identification
Paul Stief *, Jean-Yves Dantan, Alain Etienne, Ali Siadat
École Nationale Supérieure d’Arts et Métiers, Arts et Métiers ParisTech, LCFC EA 4495, 4 Rue Augustin Fresnel, Metz 57078, France
* Corresponding author. Tel.: +33 3 87 37 54 30; E-mail address: paul.stief@ensam.eu
Abstract
In today’s business environment, the trend towards more product variety and customization is unbroken. Due to this development, the need of
agile and reconfigurable production systems emerged to cope with various products and product families. To design and optimize production
systems as well as to choose the optimal product matches, product analysis methods are needed. Indeed, most of the known methods aim to
analyze a product or one product family on the physical level. Different product families, however, may differ largely in terms of the number and
nature of components. This fact impedes an efficient comparison and choice of appropriate product family combinations for the production
system. A new methodology is proposed to analyze existing products in view of their functional and physical architecture. The aim is to cluster
these products in new assembly oriented product families for the optimization of existing assembly lines and the creation of future reconfigurable
assembly systems. Based on Datum Flow Chain, the physical structure of the products is analyzed. Functional subassemblies are identified, and
a functional analysis is performed. Moreover, a hybrid functional and physical architecture graph (HyFPAG) is the output which depicts the
similarity between product families by providing design support to both, production system planners and product designers. An illustrative
example of a nail-clipper is used to explain the proposed methodology. An industrial case study on two product families of steering columns of
thyssenkrupp Presta France is then carried out to give a first industrial evaluation of the proposed approach.
© 2017 The Authors. Published by Elsevier B.V.
Peer-review under responsibility of the scientific committee of the 28th CIRP Design Conference 2018.
Keywords: Assembly; Design method; Family identification
1. Introduction
Due to the fast development in the domain of
communication and an ongoing trend of digitization and
digitalization, manufacturing enterprises are facing important
challenges in today’s market environments: a continuing
tendency towards reduction of product development times and
shortened product lifecycles. In addition, there is an increasing
demand of customization, being at the same time in a global
competition with competitors all over the world. This trend,
which is inducing the development from macro to micro
markets, results in diminished lot sizes due to augmenting
product varieties (high-volume to low-volume production) [1].
To cope with this augmenting variety as well as to be able to
identify possible optimization potentials in the existing
production system, it is important to have a precise knowledge
of the product range and characteristics manufactured and/or
assembled in this system. In this context, the main challenge in
modelling and analysis is now not only to cope with single
products, a limited product range or existing product families,
but also to be able to analyze and to compare products to define
new product families. It can be observed that classical existing
product families are regrouped in function of clients or features.
However, assembly oriented product families are hardly to find.
On the product family level, products differ mainly in two
main characteristics: (i) the number of components and (ii) the
type of components (e.g. mechanical, electrical, electronical).
Classical methodologies considering mainly single products
or solitary, already existing product families analyze the
product structure on a physical level (components level) which
causes difficulties regarding an efficient definition and
comparison of different product families. Addressing this
Procedia CIRP 96 (2020) 207–212
2212-8271 © 2020 The Authors. Published by Elsevier B.V.
This is an open access article under the CC BY-NC-ND license (https://creativecommons.org/licenses/by-nc-nd/4.0)
Peer-review under responsibility of the scientific committee of the 8th CIRP Global Web Conference – Flexible Mass Customisation
10.1016/j.procir.2021.01.076
© 2020 The Authors. Published by Elsevier B.V.
This is an open access article under the CC BY-NC-ND license (https://creativecommons.org/licenses/by-nc-nd/4.0)
Peer-review under responsibility of the scientic committee of the 8th CIRP Global Web Conference – Flexible Mass Customisation
2212-8271 © 2020 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 the responsibility of the scientific committee of the CIRPe 2020 Global Web Conference
CIRPe 2020 – 8th CIRP Global Web Conference – Flexible Mass Customisation
Process-Driven Approach within the Engineering Domain by Combining
Business Process Model and Notation (BPMN) with Process Engines
Eike Schäffera,*, Volker Stiehlb, Peter K. Schwabc, Andreas Mayra, Josef Lierhammera,
Jörg Frankea
aInstitute for Factory Automation and Production Systems, Friedrich-Alexander University Erlangen-Nuremberg, Egerlandstr. 7, Erlangen 91058, Germany
bFaculty of Computer Science, Ingolstadt University of Technology, Esplanade 10, 85049 Ingolstadt, Germany
cChair of Computer Science 6 (Data Management), Friedrich-Alexander University Erlangen-Nuremberg, Martensstraße 3, Erlangen 91058, Germany
* Corresponding author. Tel.: +49 9131 85-28314; fax: +49 9131 302825; E-mail address: eike.schaeffer@faps.fau.de
Abstract
Digitization within the framework of Industry 4.0 is considered the biggest and fastest driver of change in history of manufacturing
industry. While the size of a company is becoming less essential, the ability to adapt quickly to changing market conditions and
new technologies is more important than ever. This trend particularly applies to the companies’ software landscapes, where indi-
vidual sub-processes and services must be orchestrated, seamlessly integrated, and iteratively renewed according to the ever-in-
creasing user requirements. However, inflexible, closed monolithic software applications as well as self-programmed stand-alone
tools that are difficult to integrate are still predominant in the engineering domain. A complete reimplementation of existing,
proprietary engineering tools and their integration into monolithic applications of large software providers is often not economically
feasible, especially for small and medium-sized machinery and plant manufacturers. In this context, the so-called Process-Driven
Approach (PDA) offers a sustainable and tool-neutral opportunity for process and tool orchestration, enabling an easy integration
of individual software applications by consistent utilization of the separation of concerns principle. The PDA, originating from
business informatics, is mainly based on the standardized and machine-executable visual modeling language Business Process
Model and Notation (BPMN). Using the semantic enhancements found in version 2.0, BPMN is not just used to model the business
processes but also to model and execute the integration processes between different systems. After the PDA has already been
successfully applied to large-scale projects in business informatics, it is now being transferred to the engineering domain. As shown
in this paper, PDA allows to orchestrate the different processes in engineering and to integrate the underlying software tools, such
as e-mail or spreadsheet applications, engineering tools, or custom microservices, using standardized interfaces like REST API. In
doing so, engineering processes can be made more transparent, monitored, and optimized by means of appropriate key figures. The
concept is validated by a prototypical implementation of a minimum functional PDA architecture for the engineering domain.
© 2020 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 the responsibility of the scientific committee of the CIRPe 2020 Global Web Conference
Keywords: Process-Driven Approach; PDA; BPMN; engineering; process engine; architecture; orchestration; Industry 4.0
1. Introduction
Despite the increasing importance of data continuity and
consistency within Industry 4.0, process modeling and exe-
cution is often still realized using different, non-continuous
modeling languagues and implementation tools. From the
management and process expert view, process specification,
development and documentation is primarily pursued [1,2].
From an IT perspective, implementation and execution is be-
ing covered [3]. The different viewpoints, modeling and ex-
ecution result in synchronization efforts, coordination and
communication errors, missing transparency, and thus to
high costs and technical debt for companies [4].
Continuous and consistent approaches applying the sepa-
ration of concerns principle while using one single process
modeling language which can also be compiled, are rather
unknown, even in the emerging domain of business informat-
ics [1,2]. Especially in engineering, successfully imple-
mented approaches for standardized process modeling and
execution are therefore even less known.
For this purpose, the so-called Process-Driven Approach
(PDA) [5,6] offers a sustainable and tool-neutral opportunity
for a transparent and consistent integration of engineering
2212-8271 © 2020 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 the responsibility of the scientific committee of the CIRPe 2020 Global Web Conference
CIRPe 2020 – 8th CIRP Global Web Conference – Flexible Mass Customisation
Process-Driven Approach within the Engineering Domain by Combining
Business Process Model and Notation (BPMN) with Process Engines
Eike Schäffera,*, Volker Stiehlb, Peter K. Schwabc, Andreas Mayra, Josef Lierhammera,
Jörg Frankea
aInstitute for Factory Automation and Production Systems, Friedrich-Alexander University Erlangen-Nuremberg, Egerlandstr. 7, Erlangen 91058, Germany
bFaculty of Computer Science, Ingolstadt University of Technology, Esplanade 10, 85049 Ingolstadt, Germany
cChair of Computer Science 6 (Data Management), Friedrich-Alexander University Erlangen-Nuremberg, Martensstraße 3, Erlangen 91058, Germany
* Corresponding author. Tel.: +49 9131 85-28314; fax: +49 9131 302825; E-mail address: eike.schaeffer@faps.fau.de
Abstract
Digitization within the framework of Industry 4.0 is considered the biggest and fastest driver of change in history of manufacturing
industry. While the size of a company is becoming less essential, the ability to adapt quickly to changing market conditions and
new technologies is more important than ever. This trend particularly applies to the companies’ software landscapes, where indi-
vidual sub-processes and services must be orchestrated, seamlessly integrated, and iteratively renewed according to the ever-in-
creasing user requirements. However, inflexible, closed monolithic software applications as well as self-programmed stand-alone
tools that are difficult to integrate are still predominant in the engineering domain. A complete reimplementation of existing,
proprietary engineering tools and their integration into monolithic applications of large software providers is often not economically
feasible, especially for small and medium-sized machinery and plant manufacturers. In this context, the so-called Process-Driven
Approach (PDA) offers a sustainable and tool-neutral opportunity for process and tool orchestration, enabling an easy integration
of individual software applications by consistent utilization of the separation of concerns principle. The PDA, originating from
business informatics, is mainly based on the standardized and machine-executable visual modeling language Business Process
Model and Notation (BPMN). Using the semantic enhancements found in version 2.0, BPMN is not just used to model the business
processes but also to model and execute the integration processes between different systems. After the PDA has already been
successfully applied to large-scale projects in business informatics, it is now being transferred to the engineering domain. As shown
in this paper, PDA allows to orchestrate the different processes in engineering and to integrate the underlying software tools, such
as e-mail or spreadsheet applications, engineering tools, or custom microservices, using standardized interfaces like REST API. In
doing so, engineering processes can be made more transparent, monitored, and optimized by means of appropriate key figures. The
concept is validated by a prototypical implementation of a minimum functional PDA architecture for the engineering domain.
© 2020 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 the responsibility of the scientific committee of the CIRPe 2020 Global Web Conference
Keywords: Process-Driven Approach; PDA; BPMN; engineering; process engine; architecture; orchestration; Industry 4.0
1. Introduction
Despite the increasing importance of data continuity and
consistency within Industry 4.0, process modeling and exe-
cution is often still realized using different, non-continuous
modeling languagues and implementation tools. From the
management and process expert view, process specification,
development and documentation is primarily pursued [1,2].
From an IT perspective, implementation and execution is be-
ing covered [3]. The different viewpoints, modeling and ex-
ecution result in synchronization efforts, coordination and
communication errors, missing transparency, and thus to
high costs and technical debt for companies [4].
Continuous and consistent approaches applying the sepa-
ration of concerns principle while using one single process
modeling language which can also be compiled, are rather
unknown, even in the emerging domain of business informat-
ics [1,2]. Especially in engineering, successfully imple-
mented approaches for standardized process modeling and
execution are therefore even less known.
For this purpose, the so-called Process-Driven Approach
(PDA) [5,6] offers a sustainable and tool-neutral opportunity
for a transparent and consistent integration of engineering
2212-8271 © 2020 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 the responsibility of the scientific committee of the CIRPe 2020 Global Web Conference
CIRPe 2020 – 8th CIRP Global Web Conference – Flexible Mass Customisation
Process-Driven Approach within the Engineering Domain by Combining
Business Process Model and Notation (BPMN) with Process Engines
Eike Schäffera,*, Volker Stiehlb, Peter K. Schwabc, Andreas Mayra, Josef Lierhammera,
Jörg Frankea
aInstitute for Factory Automation and Production Systems, Friedrich-Alexander University Erlangen-Nuremberg, Egerlandstr. 7, Erlangen 91058, Germany
bFaculty of Computer Science, Ingolstadt University of Technology, Esplanade 10, 85049 Ingolstadt, Germany
cChair of Computer Science 6 (Data Management), Friedrich-Alexander University Erlangen-Nuremberg, Martensstraße 3, Erlangen 91058, Germany
* Corresponding author. Tel.: +49 9131 85-28314; fax: +49 9131 302825; E-mail address: eike.schaeffer@faps.fau.de
Abstract
Digitization within the framework of Industry 4.0 is considered the biggest and fastest driver of change in history of manufacturing
industry. While the size of a company is becoming less essential, the ability to adapt quickly to changing market conditions and
new technologies is more important than ever. This trend particularly applies to the companies’ software landscapes, where indi-
vidual sub-processes and services must be orchestrated, seamlessly integrated, and iteratively renewed according to the ever-in-
creasing user requirements. However, inflexible, closed monolithic software applications as well as self-programmed stand-alone
tools that are difficult to integrate are still predominant in the engineering domain. A complete reimplementation of existing,
proprietary engineering tools and their integration into monolithic applications of large software providers is often not economically
feasible, especially for small and medium-sized machinery and plant manufacturers. In this context, the so-called Process-Driven
Approach (PDA) offers a sustainable and tool-neutral opportunity for process and tool orchestration, enabling an easy integration
of individual software applications by consistent utilization of the separation of concerns principle. The PDA, originating from
business informatics, is mainly based on the standardized and machine-executable visual modeling language Business Process
Model and Notation (BPMN). Using the semantic enhancements found in version 2.0, BPMN is not just used to model the business
processes but also to model and execute the integration processes between different systems. After the PDA has already been
successfully applied to large-scale projects in business informatics, it is now being transferred to the engineering domain. As shown
in this paper, PDA allows to orchestrate the different processes in engineering and to integrate the underlying software tools, such
as e-mail or spreadsheet applications, engineering tools, or custom microservices, using standardized interfaces like REST API. In
doing so, engineering processes can be made more transparent, monitored, and optimized by means of appropriate key figures. The
concept is validated by a prototypical implementation of a minimum functional PDA architecture for the engineering domain.
© 2020 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 the responsibility of the scientific committee of the CIRPe 2020 Global Web Conference
Keywords: Process-Driven Approach; PDA; BPMN; engineering; process engine; architecture; orchestration; Industry 4.0
1. Introduction
Despite the increasing importance of data continuity and
consistency within Industry 4.0, process modeling and exe-
cution is often still realized using different, non-continuous
modeling languagues and implementation tools. From the
management and process expert view, process specification,
development and documentation is primarily pursued [1,2].
From an IT perspective, implementation and execution is be-
ing covered [3]. The different viewpoints, modeling and ex-
ecution result in synchronization efforts, coordination and
communication errors, missing transparency, and thus to
high costs and technical debt for companies [4].
Continuous and consistent approaches applying the sepa-
ration of concerns principle while using one single process
modeling language which can also be compiled, are rather
unknown, even in the emerging domain of business informat-
ics [1,2]. Especially in engineering, successfully imple-
mented approaches for standardized process modeling and
execution are therefore even less known.
For this purpose, the so-called Process-Driven Approach
(PDA) [5,6] offers a sustainable and tool-neutral opportunity
for a transparent and consistent integration of engineering
2212-8271 © 2020 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 the responsibility of the scientific committee of the CIRPe 2020 Global Web Conference
CIRPe 2020 – 8th CIRP Global Web Conference – Flexible Mass Customisation
Process-Driven Approach within the Engineering Domain by Combining
Business Process Model and Notation (BPMN) with Process Engines
Eike Schäffera,*, Volker Stiehlb, Peter K. Schwabc, Andreas Mayra, Josef Lierhammera,
Jörg Frankea
aInstitute for Factory Automation and Production Systems, Friedrich-Alexander University Erlangen-Nuremberg, Egerlandstr. 7, Erlangen 91058, Germany
bFaculty of Computer Science, Ingolstadt University of Technology, Esplanade 10, 85049 Ingolstadt, Germany
cChair of Computer Science 6 (Data Management), Friedrich-Alexander University Erlangen-Nuremberg, Martensstraße 3, Erlangen 91058, Germany
* Corresponding author. Tel.: +49 9131 85-28314; fax: +49 9131 302825; E-mail address: eike.schaeffer@faps.fau.de
Abstract
Digitization within the framework of Industry 4.0 is considered the biggest and fastest driver of change in history of manufacturing
industry. While the size of a company is becoming less essential, the ability to adapt quickly to changing market conditions and
new technologies is more important than ever. This trend particularly applies to the companies’ software landscapes, where indi-
vidual sub-processes and services must be orchestrated, seamlessly integrated, and iteratively renewed according to the ever-in-
creasing user requirements. However, inflexible, closed monolithic software applications as well as self-programmed stand-alone
tools that are difficult to integrate are still predominant in the engineering domain. A complete reimplementation of existing,
proprietary engineering tools and their integration into monolithic applications of large software providers is often not economically
feasible, especially for small and medium-sized machinery and plant manufacturers. In this context, the so-called Process-Driven
Approach (PDA) offers a sustainable and tool-neutral opportunity for process and tool orchestration, enabling an easy integration
of individual software applications by consistent utilization of the separation of concerns principle. The PDA, originating from
business informatics, is mainly based on the standardized and machine-executable visual modeling language Business Process
Model and Notation (BPMN). Using the semantic enhancements found in version 2.0, BPMN is not just used to model the business
processes but also to model and execute the integration processes between different systems. After the PDA has already been
successfully applied to large-scale projects in business informatics, it is now being transferred to the engineering domain. As shown
in this paper, PDA allows to orchestrate the different processes in engineering and to integrate the underlying software tools, such
as e-mail or spreadsheet applications, engineering tools, or custom microservices, using standardized interfaces like REST API. In
doing so, engineering processes can be made more transparent, monitored, and optimized by means of appropriate key figures. The
concept is validated by a prototypical implementation of a minimum functional PDA architecture for the engineering domain.
© 2020 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 the responsibility of the scientific committee of the CIRPe 2020 Global Web Conference
Keywords: Process-Driven Approach; PDA; BPMN; engineering; process engine; architecture; orchestration; Industry 4.0
1. Introduction
Despite the increasing importance of data continuity and
consistency within Industry 4.0, process modeling and exe-
cution is often still realized using different, non-continuous
modeling languagues and implementation tools. From the
management and process expert view, process specification,
development and documentation is primarily pursued [1,2].
From an IT perspective, implementation and execution is be-
ing covered [3]. The different viewpoints, modeling and ex-
ecution result in synchronization efforts, coordination and
communication errors, missing transparency, and thus to
high costs and technical debt for companies [4].
Continuous and consistent approaches applying the sepa-
ration of concerns principle while using one single process
modeling language which can also be compiled, are rather
unknown, even in the emerging domain of business informat-
ics [1,2]. Especially in engineering, successfully imple-
mented approaches for standardized process modeling and
execution are therefore even less known.
For this purpose, the so-called Process-Driven Approach
(PDA) [5,6] offers a sustainable and tool-neutral opportunity
for a transparent and consistent integration of engineering

208 Eike Schäffer et al. / Procedia CIRP 96 (2020) 207–212
2Eike Schäffer et al. / Procedia CIRP 00 (2019) 000–000
processes and tools based on the well-known Business Pro-
cess Model and Notation (BPMN) standard [7]. Based on
BPMN 2.0, processes can be executed directly in a process
engine [8]. Especially in the engineering of machines and
plants, a structured orchestration of different engineering
tools or custom microservices is necessary but not yet state
of the art [9–11]. Therefore, the PDA, originating from busi-
ness informatics, is introduced into the engineering domain
and extended accordingly.
2. Relevant basics and need for action
The Product Emergence Process (PEP) is generally di-
vided into three steps: 1) product development, 2) production
planning, and 3) production [12]. Within the PEP, the syn-
chronization of the individual disciplines (planning, mechan-
ics, electrics, and software) has always been a challenge [13].
Due to mechatronic products with cognitive functions, digi-
tal services, and more sophisticated machines and plants, the
volatility, uncertainty, complexity, and ambiguity – also
known by the acronym VUCA [14] – in engineering contin-
ues to increase [11,15]. Thereby, the coordination effort
grows exponentially with the size of the project [16]. Thus,
efficient and transparent engineering processes as well as an
integrated tool chain, though which individual processes can
even be executed automatically, are all the more important.
2.1. Views and knowledge elements for process automation
In order to automate engineering processes, domain ex-
pert knowledge about the respective processes and data ob-
jects (process input and output) is required, which is usually
developed and documented textually or graphically (Fig. 1,
2nd row). The specified processes can then be transferred by
the IT department into executable program code using appro-
priate software tools and databases. (Fig. 1, 3rd row). [2,3,17]
Fig. 1. Roles and knowledge elements in traditional process automation
within business informatics [2,3,17]
2.2. Challenges in engineering due to inconsistent process
modeling, lacking tool integration, and missing automation
However, different terminologies, also known as lan-
guages, and tools for process modeling with the aim of doc-
umentation and execution create increased complexity and
effort due to the necessary synchronization (Fig. 2) [3]. Most
modeling terminologies have been developed for process
specification, design, and documentation [1,18] using mod-
eling tools like ARIS [3]. The Event-driven Process Chain
(EPC) was introduced in the 1992s with the aim of semanti-
cally modeling business processes by identifying and graph-
ically documenting business management interrelationships
in a company [1]. With the aim of graphical software speci-
fication, design, and documentation, the Object Management
Group (OMG) published UML 1.1 (1997), UML 1.4 (2001),
and UML 2.0 (2012) as major releases, standardized within
ISO/ IEC 19505-1 [18]. The 14 different UML diagram types
can be classified into seven structure and seven behavior (e.g.
activity or interaction) diagrams. While EPC is used for the
specification of business processes, UML is mainly used for
the initial specification of IT systems [2,3].
Fig. 2. Different tools for process modeling and execution
The Web Services Business Process Execution Language
(WS-BPEL), introduced in 2002, represents an XML-based
implementation-oriented standard to describe the interaction
of executable processes with web services, without providing
a graphical notation [19]. In contrast, for the automation of
engineering processes, Excel tools based on Visual Basic for
Applications (VBA) are often used because of their good us-
ability, availability and simple programming [20,21]. Never-
theless, poor processes in combination with isolated tools
lead to high costs, causing transfer and coordination errors.
According to the rule of ten (Fig. 3), in the case of a faulty
product development and re-design additional costs arise, in
particular with no defect prevention and a late defect discov-
ery [22]. In addition, a study by Reinema et al. [23] shows
the limitations of factory planning concepts and tools:
thereby, 60% of the automation projects failed to achieve
scheduled targets and 72% failed to be within budget. In fac-
tory planning, 52% of the deficits can be traced back to time
and information loss. In practice, factory planning achieves
correct solutions, but there is potential for improvement in
planning process efficiency [23].
Fig. 3. According to the rule of ten, costs increase by a factor of ten with
each phase in case of late or undiscovered defects [22]
2.3. Chances of a consistent process modeling and
automatic execution based on BPMN
Since 2004, the standard terminology BPMN is avaliable
for process modeling and execution, originating from
business informatics and defined by the OMG in ISO/
IEC 19510 [7]. Compared to EPC, the graphical notation
BPMN allows for the execution of modeled processes within
a process engine [2,7] (Fig. 4). The latter feature was
introduced in 2011 with BPMN 2.0 [24]. Despite the given
terminology and machine executability of BPMN, no
scalability of the software architecture is guaranteed by
default. For this purpose, the PDA represents a
superordinated BPMN software architecture, also usefull
within engineering.
Process
also known as workflow
Data object for process input
and output also known as item
Domain expert (e.g. busines s
or engineering knowledge)
Process description (text)
or model (graphical notation)
Data object description (text)
or model (graphical notation)
IT department
(implementation knowledge)
Executable processes e.g.
built hard-coded into software
Executable data handling
e.g. through databases
Knowledge element
View
Cost per defect
Defect prevention Defect detection
Planning
and development
Procurement
and production
1 € 10 €
100 €
1.000 €
Work preparationPlanning TestingDevelopment Production Customer
Testing
and delivery
Product development
10.000 €
100.000 €
Eike Schäffer et al. / Procedia CIRP 00 (2019) 000–000 3
Fig. 4. Consistent process automation using BPMN with process engine
3. Research method
Considering a case study on the PDA in the field of busi-
ness informatics at SAP [6], a sustainable strategy for the
PDA and a continuously executable architecture within en-
gineering domain based on the PEP is introduced. The stra-
tegic architecture and the continuously executable approach
are elaborated based on literature analysis and synthesis.
Based on our experience and various use cases within the re-
search project ROBOTOP [25,26] as well as other projects,
we have introduced and enhanced the PDA for the engineer-
ing domain as shown in section 4. In section 5, a minimal
functional architecture of the PDA within the engineering
domain is evaluated using a prototypical implementation.
4. Sustainable strategy and architecture for the Process-
Driven Approach within the engineering domain
The PDA has supported the project management and im-
plementation of digitization projects as well as their process
sequences in a structured business informatics architecture
[6]. To introduce and adopt the PDA within the engineering
domain based on the PEP, firstly, the strategic importance of
the PDA in process-based business strategies is outlined.
Secondly, a distinction between non- and executable process
approaches is elaborated with regard to relevant sub-goals
and roles. Thirdly, a general PDA architecture for the engi-
neering domain is introduced and, fourthly a minimum func-
tional PDA architecture (MFPA) and its components are de-
rived.
4.1. Sustainable strategy and significance of the PDA
Due to the global availability of information, the differen-
tiation from the competition through products and services is
becoming increasingly less important (Fig. 5). In contrast, ef-
ficient internal processes provide a sustainable competitive
advantage through higher quality services and products at
lower costs and higher profit margins. In addition, infor-
mation on products and services is usually distributed trans-
parently through advertising and marketing campaigns. In
contrast, internal company processes are usually secret, ra-
ther hidden from the competition, and therefore more diffi-
cult to imitate. Thus, the efficient, consistent automation of
processes is of great importance, generating strategic ad-
vantages to be more competitive in the long term.
Fig. 5. Relevance of internal processes for sustainable success
4.2. Process consistency through executable process models
In order to create a clearer understanding for the PDA, it
is necessary to compare non- and executable process
approaches and models (before/ after BPMN) based on
generic process goals, roles, and modeling terminologies.
Within process automation, four goals can be distinguished,
which are usually assigned to different roles: documentation,
analysis and optimization, implementation as well as
execution and monitoring (Fig. 6). As illustrated, the model-
ing of executable processes can be achieved by using BPMN.
In doing so, BPMN serves as a lingua franca (Fig. 6, right
column) for all consumers of the underlying process models.
Fig. 6. Process goals, roles, and modeling terminologies alternatives
The process model execution is performed within a pro-
cess engine, which orchestrates, monitors, compiles, reports,
and manages all the tasks (Fig. 7) [8].
Fig. 7. Process model execution including phases (1-4) according to [8]
4.3. General PDA architecture for the engineering domain
As shown in Fig. 8, the general PDA architecture is di-
vided into three process specific layers [5]; 1) the PDA Layer
(PDA-L), 2) the Service Contract Implementation Layer
(SCI-L), and 3) the Back-end Layer (B-L). These are ex-
tended with a user interaction-specific x) Front-end Shell (F-
S), which only communicates with the process engine and
thus with layer 1-3 as a whole. The division of the layers al-
lows a transparent and explicit separation of the processes
and the software-specific implementation. An explicit ser-
vice contract (SC) is created to express the input and output
needs for certain steps for general business or specific engi-
neering processes. In order to fulfill those needs, the SCI-L
implements the necessary functionality by mediating be-
tween the PDA-L and the already existing software-specific
applications, services, or systems on the B-L.
In [5], the motivation for the separation of layers is ex-
plained in great detail. Without SCI-L, the resulting pro-
cesses lose their clarity, flexibility, and adaptability to
change in the long run. Thus, the separation considers the
long-term maintenance costs of software.
BPM N
pro cess m odel
Pro ces s
engine
Autom atic pr ocess execution and m onitoring
Ta sk
list
Proces s
models
Executable
proces ses
Automatic synchronizat ion
Process
engine
Process
participants IT System
Monitoring of
the lead time
Modeling (BPMN)
Service
orchestration
Monitoring and
reporting
Human workflow
management
Executable
process model
Automatic
decision
Automatic
Task
allocation
Process
participants
Task
allocation
1
2 3 4
service
call
service
call
Model import
Visible to compe titors
and easy to imitate
Competitive advantage
through internal processes
not visible to comp etitors
and thus difficult to imi tate
Focus of a sustainable
business strategy
Products Services
Internal
(business)
processes
Business expert
Responsible role
Business analyst
Computer scientis t
EPC
BPEL/ UML
BPMN
BPMN
BPMN
Different modeling terminologies
Mediation
before BPMN after BPMNProcess goal
1) Documentation
2) Analysis and optimization
3) Implementation
4) Execution and monitoring Software Hard-coded Process engine

Eike Schäffer et al. / Procedia CIRP 96 (2020) 207–212 209
2 Eike Schäffer et al. / Procedia CIRP 00 (2019) 000–000
processes and tools based on the well-known Business Pro-
cess Model and Notation (BPMN) standard [7]. Based on
BPMN 2.0, processes can be executed directly in a process
engine [8]. Especially in the engineering of machines and
plants, a structured orchestration of different engineering
tools or custom microservices is necessary but not yet state
of the art [9–11]. Therefore, the PDA, originating from busi-
ness informatics, is introduced into the engineering domain
and extended accordingly.
2. Relevant basics and need for action
The Product Emergence Process (PEP) is generally di-
vided into three steps: 1) product development, 2) production
planning, and 3) production [12]. Within the PEP, the syn-
chronization of the individual disciplines (planning, mechan-
ics, electrics, and software) has always been a challenge [13].
Due to mechatronic products with cognitive functions, digi-
tal services, and more sophisticated machines and plants, the
volatility, uncertainty, complexity, and ambiguity – also
known by the acronym VUCA [14] – in engineering contin-
ues to increase [11,15]. Thereby, the coordination effort
grows exponentially with the size of the project [16]. Thus,
efficient and transparent engineering processes as well as an
integrated tool chain, though which individual processes can
even be executed automatically, are all the more important.
2.1. Views and knowledge elements for process automation
In order to automate engineering processes, domain ex-
pert knowledge about the respective processes and data ob-
jects (process input and output) is required, which is usually
developed and documented textually or graphically (Fig. 1,
2nd row). The specified processes can then be transferred by
the IT department into executable program code using appro-
priate software tools and databases. (Fig. 1, 3rd row). [2,3,17]
Fig. 1. Roles and knowledge elements in traditional process automation
within business informatics [2,3,17]
2.2. Challenges in engineering due to inconsistent process
modeling, lacking tool integration, and missing automation
However, different terminologies, also known as lan-
guages, and tools for process modeling with the aim of doc-
umentation and execution create increased complexity and
effort due to the necessary synchronization (Fig. 2) [3]. Most
modeling terminologies have been developed for process
specification, design, and documentation [1,18] using mod-
eling tools like ARIS [3]. The Event-driven Process Chain
(EPC) was introduced in the 1992s with the aim of semanti-
cally modeling business processes by identifying and graph-
ically documenting business management interrelationships
in a company [1]. With the aim of graphical software speci-
fication, design, and documentation, the Object Management
Group (OMG) published UML 1.1 (1997), UML 1.4 (2001),
and UML 2.0 (2012) as major releases, standardized within
ISO/ IEC 19505-1 [18]. The 14 different UML diagram types
can be classified into seven structure and seven behavior (e.g.
activity or interaction) diagrams. While EPC is used for the
specification of business processes, UML is mainly used for
the initial specification of IT systems [2,3].
Fig. 2. Different tools for process modeling and execution
The Web Services Business Process Execution Language
(WS-BPEL), introduced in 2002, represents an XML-based
implementation-oriented standard to describe the interaction
of executable processes with web services, without providing
a graphical notation [19]. In contrast, for the automation of
engineering processes, Excel tools based on Visual Basic for
Applications (VBA) are often used because of their good us-
ability, availability and simple programming [20,21]. Never-
theless, poor processes in combination with isolated tools
lead to high costs, causing transfer and coordination errors.
According to the rule of ten (Fig. 3), in the case of a faulty
product development and re-design additional costs arise, in
particular with no defect prevention and a late defect discov-
ery [22]. In addition, a study by Reinema et al. [23] shows
the limitations of factory planning concepts and tools:
thereby, 60% of the automation projects failed to achieve
scheduled targets and 72% failed to be within budget. In fac-
tory planning, 52% of the deficits can be traced back to time
and information loss. In practice, factory planning achieves
correct solutions, but there is potential for improvement in
planning process efficiency [23].
Fig. 3. According to the rule of ten, costs increase by a factor of ten with
each phase in case of late or undiscovered defects [22]
2.3. Chances of a consistent process modeling and
automatic execution based on BPMN
Since 2004, the standard terminology BPMN is avaliable
for process modeling and execution, originating from
business informatics and defined by the OMG in ISO/
IEC 19510 [7]. Compared to EPC, the graphical notation
BPMN allows for the execution of modeled processes within
a process engine [2,7] (Fig. 4). The latter feature was
introduced in 2011 with BPMN 2.0 [24]. Despite the given
terminology and machine executability of BPMN, no
scalability of the software architecture is guaranteed by
default. For this purpose, the PDA represents a
superordinated BPMN software architecture, also usefull
within engineering.
Process
also known as workflow
Data object for process input
and output also known as item
Domain expert (e.g. busines s
or engineering knowledge)
Process description (text)
or model (graphical notation)
Data object description (text)
or model (graphical notation)
IT department
(implementation knowledge)
Executable processes e.g.
built hard-coded into software
Executable data handling
e.g. through databases
Knowledge element
View
Cost per defect
Defect prevention Defect detection
Planning
and development
Procurement
and production
1 € 10 €
100 €
1.000 €
Work preparation
Planning TestingDevelopment Production Customer
Testing
and delivery
Product development
10.000 €
100.000 €
Eike Schäffer et al. / Procedia CIRP 00 (2019) 000–000 3
Fig. 4. Consistent process automation using BPMN with process engine
3. Research method
Considering a case study on the PDA in the field of busi-
ness informatics at SAP [6], a sustainable strategy for the
PDA and a continuously executable architecture within en-
gineering domain based on the PEP is introduced. The stra-
tegic architecture and the continuously executable approach
are elaborated based on literature analysis and synthesis.
Based on our experience and various use cases within the re-
search project ROBOTOP [25,26] as well as other projects,
we have introduced and enhanced the PDA for the engineer-
ing domain as shown in section 4. In section 5, a minimal
functional architecture of the PDA within the engineering
domain is evaluated using a prototypical implementation.
4. Sustainable strategy and architecture for the Process-
Driven Approach within the engineering domain
The PDA has supported the project management and im-
plementation of digitization projects as well as their process
sequences in a structured business informatics architecture
[6]. To introduce and adopt the PDA within the engineering
domain based on the PEP, firstly, the strategic importance of
the PDA in process-based business strategies is outlined.
Secondly, a distinction between non- and executable process
approaches is elaborated with regard to relevant sub-goals
and roles. Thirdly, a general PDA architecture for the engi-
neering domain is introduced and, fourthly a minimum func-
tional PDA architecture (MFPA) and its components are de-
rived.
4.1. Sustainable strategy and significance of the PDA
Due to the global availability of information, the differen-
tiation from the competition through products and services is
becoming increasingly less important (Fig. 5). In contrast, ef-
ficient internal processes provide a sustainable competitive
advantage through higher quality services and products at
lower costs and higher profit margins. In addition, infor-
mation on products and services is usually distributed trans-
parently through advertising and marketing campaigns. In
contrast, internal company processes are usually secret, ra-
ther hidden from the competition, and therefore more diffi-
cult to imitate. Thus, the efficient, consistent automation of
processes is of great importance, generating strategic ad-
vantages to be more competitive in the long term.
Fig. 5. Relevance of internal processes for sustainable success
4.2. Process consistency through executable process models
In order to create a clearer understanding for the PDA, it
is necessary to compare non- and executable process
approaches and models (before/ after BPMN) based on
generic process goals, roles, and modeling terminologies.
Within process automation, four goals can be distinguished,
which are usually assigned to different roles: documentation,
analysis and optimization, implementation as well as
execution and monitoring (Fig. 6). As illustrated, the model-
ing of executable processes can be achieved by using BPMN.
In doing so, BPMN serves as a lingua franca (Fig. 6, right
column) for all consumers of the underlying process models.
Fig. 6. Process goals, roles, and modeling terminologies alternatives
The process model execution is performed within a pro-
cess engine, which orchestrates, monitors, compiles, reports,
and manages all the tasks (Fig. 7) [8].
Fig. 7. Process model execution including phases (1-4) according to [8]
4.3. General PDA architecture for the engineering domain
As shown in Fig. 8, the general PDA architecture is di-
vided into three process specific layers [5]; 1) the PDA Layer
(PDA-L), 2) the Service Contract Implementation Layer
(SCI-L), and 3) the Back-end Layer (B-L). These are ex-
tended with a user interaction-specific x) Front-end Shell (F-
S), which only communicates with the process engine and
thus with layer 1-3 as a whole. The division of the layers al-
lows a transparent and explicit separation of the processes
and the software-specific implementation. An explicit ser-
vice contract (SC) is created to express the input and output
needs for certain steps for general business or specific engi-
neering processes. In order to fulfill those needs, the SCI-L
implements the necessary functionality by mediating be-
tween the PDA-L and the already existing software-specific
applications, services, or systems on the B-L.
In [5], the motivation for the separation of layers is ex-
plained in great detail. Without SCI-L, the resulting pro-
cesses lose their clarity, flexibility, and adaptability to
change in the long run. Thus, the separation considers the
long-term maintenance costs of software.
BPM N
pro cess m odel
Pro ces s
engine
Autom atic pr ocess execution and m onitoring
Ta sk
list
Proces s
models
Executable
proces ses
Automatic synchronizat ion
Process
engine
Process
participants IT System
Monitoring of
the lead time
Modeling (BPMN)
Service
orchestration
Monitoring and
reporting
Human workflow
management
Executable
process model
Automatic
decision
Automatic
Task
allocation
Process
participants
Task
allocation
1
2 3 4
service
call
service
call
Model import
Visible to compe titors
and easy to imitate
Competitive advantage
through internal processes
not visible to comp etitors
and thus difficult to imi tate
Focus of a sustainable
business strategy
Products Services
Internal
(business)
processes
Business expert
Responsible role
Business analyst
Computer scientis t
EPC
BPEL/ UML
BPMN
BPMN
BPMN
Different modeling terminologies
Mediation
before BPMN after BPMNProcess goal
1) Documentation
2) Analysis and optimization
3) Implementation
4) Execution and monitoring Software Hard-coded Process engine

210 Eike Schäffer et al. / Procedia CIRP 96 (2020) 207–212
4 Eike Schäffer et al. / Procedia CIRP 00 (2019) 000–000
Fig. 8. Three-layer PDA (1-3) architecture extended with the user interac-
tion-specific human machine interfaces, x) the Front-end Shell (F-S)
Although the first implementation of the architecture
might be costlier than putting everything in one process
model, it pays off in the long term. Initial implementation
costs are incurred only once. Maintenance costs, however,
accompany the software throughout the entire lifecycle. The
PDA is thus recommended for scenarios in which processes
extend across a wide variety of systems and in which changes
are foreseeable [5]. The user group-specific presentation of
the F-S can be implemented by using web technologies [27]
or apps, communicating with the process engine through in-
terfaces such as Representational State Transfer (REST)
based Application Programming Interfaces (API). The gen-
eral business and specific engineering processes are modeled
using BPMN within the PDA-L.
The SCI-L is responsible for implementing the Ser-
vice Contract, fulfilling a required domain driven function-
ality by communicating with existing systems. The SCI-L is
separated in a stateless (mandatory) and a stateful (optional)
part. The stateful part is needed if a wait state occures. This
is typically the case if a message is sent to a back-end system
and a response is expected. Fig. 8 gives an example for that
use case: The Simulation microservice is triggered by a mes-
sage and the process is waiting for the simulation result. Ag-
gregation is another example for a stateful process on the
SCI-Layer: The stateful process is waiting (wait state) for
several messages before one package of messages is sent to
its final destination in one go. However, not every integration
scenario requires stateful handling. If it is just about handing
over a message from PDA-L to one or several backend sys-
tems, no state is involved. Hence, the stateful part is obsolete.
The stateful part can be handled either by BPMN processes
(recommended to increase transparency) or specialized inte-
gration software, e.g. Camel (camel.apache.org). Only in
high-performance scenarios, a specialized integration soft-
ware should be used for better throughput reasons or high
performance integration needs. The stateless part covers the
three main aspects of every integration scenario: data trans-
formation, message routing to the right receiving back-end
systems, and technical connectivity such as REST (HTTP-
Protocoll with JSON) or Simple Object Access Protocol
(SOAP) communication or connecting via proprietary proto-
cols. The technical connectivity to the systems is typically
handled by a technical component called a connector. In or-
der to reduce the number of data transformations, it is rec-
ommended to agree on a neutral generic data format on the
PDA-L and SCI-L, also known a canonical data model [28].
As a consequence, data transformations happen from the
SCI-L to the B-L (and vice versa) only within the integration
software. This improves the maintenance of interfaces and
data mappings of process-driven applications. Excel is also a
frequently used exchange format in engineering; it can be
used on the F-S as well as in the PDA on the B-L. On the B-
L the usage of Excel is less problematic, wherease on the F-
S it should only be used in a restrictive manner, e.g. for early
prototypes and small projects, as it creates and hides depend-
encies, which should be avoided whenever possible.
4.4. Minium functional PDA architecture (MFPA) and its
components for process automation
To make the PDA more accessible for the engineering
domain, we have composed the minimally functional PDA
architecture (MFPA) and its components as depicted in
Fig. 9. The goal is to show how to create an initial functional
and useful PDA application within existing solutions and
tools, even with Excel tools, which frequently occur in
industrial software landscapes. The composition of the
components in Fig. 9 should demonstrate that a first start to
utilize the PDA is quickly achievable.
Fig. 9. MFPA and its components for the engineering domain
I) Necessary scope of components: For BPMN
modeling, different solutions are avaliable, e.g. from
Signavio (signavio.com), Camunda (bpmn.io), or ARIS
(ariscloud.com). For process and rule execution, different
process engines can be used, e.g. the open source engine
Activiti (activiti.org) or the freemium engine Camunda
(camunda.com). These engines support user and task
management as well as process execution and monitoring.
Decision Model and Notation (DMN) [29] can be utilized for
integrated, structured decision rules within process engines.
II) Additional components: Web browsers can be used
as a user interface into the PDA, e.g. for task management,
monitoring as well as administration. For external user com-
munication as well as data acquisition, processing, and dis-
tribution, further applications can be integrated, e.g. using e-
mails or user-centered websites and apps. The data exchange
with third-party applications is performed using for example
REST API with a pre-defined JSON or XML structure. Be-
sides DMN for decision tables, further logic and scripts can
be directly integrated into process engines using Java code.
Necessary scope of com ponents for process execution
1) Process and
decision rule model ing
2) User
management
4) Process and decision
rule execution
5) Process
monitoring
BPMN/ DMN modeler Admin view BPMN process engine and dashboard
Minimum functional PDA architecture (MFPA) and its components for process automation
9) Integrated
logic
7) External user
communication
8) Data
exchange
Process engine
integrated scripts
and logic e.g.
based on Java
Additional
application
e.g. e-mail, app,
website
Web interfaces
e.g. REST API
combined with
JSON
Additional component s
3) Task
management
Task list
6) User
interface
Web
browser
e.g.
Chrome
10) Complex logic and
expert knowledge
Engineering
tool integration
e.g. complex Excel tool s
or simulation tools
I
II
Eike Schäffer et al. / Procedia CIRP 00 (2019) 000–000 5
To integrate more complex logic and expert knowledge, ad-
ditional applications can be connected via REST API as well.
This is especially important in the engineering domain, since
the re-implementation effort of e.g. existing complex Excel
tools or complete simulation environments would not be eco-
nomically reasonable.
5. Prototypical implementation and validation
The following validatation is based on a specific use case
and a corresponding prototypical implementation.
5.1. Presentation of the validation use case
As validation use case, the risk assessment phase within
an automation project has been selected. The process has
been simplified to make the general idea behind the MFPA
more accessible and comprehensible. According to Fig. 10,
a new automation project is launched by a project manager.
In this example, the next process step is a risk assessment.
The PDA-L is not interested in the details of the evaluation
as it is not relevant from the pure functional view of this
layer. Hence, the process step has been separated. The engi-
neer assigned to the project receives an automatic order by e-
mail to perform a risk assessment. The risk assessment is per-
formed using an Excel tool developed internally by the com-
pany for such kind of automation projects. The engineer en-
ters the project ID into the Excel tool, also received in the
first e-mail. Based on the ID, the Excel tool imports the pro-
ject-specific information via a REST API call from the B-L
reusing an already existing project database. Then the engi-
neer performs the risk assessment in the Excel tool. After
completion of the evaluation, the essential results and key
performance indicators are sent back to the PDA-L via REST
API (step ‘Send confirmation’ in the SCI-L process) and the
SCI-L process is completed. Within the PDA-L, the project
manager is automatically notified to check and release the
results or in case of insufficient risk assessment to adapt the
requirements for a re-evaluation of the risk.
Fig. 10. Excerpt from PDA architecture exemplified by the use case
5.2. Validation through prototypical implementation
The validation through prototypical implementation of
the general PDA architecture for the engineering domain
(Fig. 8) and the MFPA (Fig. 9) is accomplished using the
Camunda Community Platform process engine as well as
BPMN and DMN modeling tools (Camunda modeler). The
web browser Chrome was used as front-end. The main test
project and integrated logic based on Java was built within
the programming environment Eclipse for Java JDK using
Maven archetype (Camunda-bpm) for direct build integra-
tion into Camunda. As a ready-to-run e-mail server, a Gmail
account was used for external communication based on a pre-
defined e-mail template. To demonstrate the integration and
communication of external engineering services with the
process engine through REST API calls, we used an exem-
plary Excel tool as well as the Postman API communication
testing tool (postman.com). The logic in the Excel tool and
the REST API connection (method: msxml2.ServerXMLhttp)
was built based on the programming language VBA.
In doing so, we demonstrated the easy integration and
communication of existing and newly created engineering
tools into the PDA (Fig. 10). In order to demonstrate the
MFPA within the engineering domain in a comprehensible
way, relatively simple and available software tools were
used, as described in the previous paragraph. These should
be replaced depending on the scope of the project through
more powerful alternatives. The replacement of tools has no
effects on the engineering process of the PDA due to the pro-
cess-driven architecture shown in Fig. 8, applying the sepa-
ration of concerns principle. This ensures high flexibility in
case of applying valuable engineering processes on top of
different back-ends and tools. The advantages of the PDA
became obvious during implementation, having transparent
BPMN-based process overviews and running process moni-
toring. In addition, it is possible to adjust and extend the pro-
cess or exchange services to simplify an agile development.
From a first Postman-based communication test service we
extended the prototpye to an Excel tool based service as input
provider, for the BPMN process engine.
5.3. General concept validation through expert discussions
To validate the general concept of PDA within engineer-
ing, we discussed it with three experts from the IT domain
and four experts from the engineering domain, i.e. end users.
The IT experts were asked if they know about PDA ap-
proaches within engineering and how they evaluate the tech-
nical feasibility. None of the interviewed experts knew PDA
attempts related to engineering. The technical feasibility was
rated medium to high. The use of Excel tools was considered
appropriate as an initial solution and for small applications,
but in the long run, the tools should be redesigned for scala-
bility reasons into web services, e.g. microservices.
Engineering experts, i.e. end users, were asked to evaluate
the potential for automation of project management tasks and
tool orchestration. In addition, they also tested the prototype.
The PDA approach was unknown to all interviewees, but af-
ter a detailed explanation, great potential was seen, espe-
cially because of the graphical process description and the
potential for engineering tool orchestration. In particular, the
manual transfer of data from one tool to another causes high
workloads and many potential errors. This problem could be
addressed successively and in a structured way using the
PDA within the engineering domain. However, without the

Eike Schäffer et al. / Procedia CIRP 96 (2020) 207–212 211
4 Eike Schäffer et al. / Procedia CIRP 00 (2019) 000–000
Fig. 8. Three-layer PDA (1-3) architecture extended with the user interac-
tion-specific human machine interfaces, x) the Front-end Shell (F-S)
Although the first implementation of the architecture
might be costlier than putting everything in one process
model, it pays off in the long term. Initial implementation
costs are incurred only once. Maintenance costs, however,
accompany the software throughout the entire lifecycle. The
PDA is thus recommended for scenarios in which processes
extend across a wide variety of systems and in which changes
are foreseeable [5]. The user group-specific presentation of
the F-S can be implemented by using web technologies [27]
or apps, communicating with the process engine through in-
terfaces such as Representational State Transfer (REST)
based Application Programming Interfaces (API). The gen-
eral business and specific engineering processes are modeled
using BPMN within the PDA-L.
The SCI-L is responsible for implementing the Ser-
vice Contract, fulfilling a required domain driven function-
ality by communicating with existing systems. The SCI-L is
separated in a stateless (mandatory) and a stateful (optional)
part. The stateful part is needed if a wait state occures. This
is typically the case if a message is sent to a back-end system
and a response is expected. Fig. 8 gives an example for that
use case: The Simulation microservice is triggered by a mes-
sage and the process is waiting for the simulation result. Ag-
gregation is another example for a stateful process on the
SCI-Layer: The stateful process is waiting (wait state) for
several messages before one package of messages is sent to
its final destination in one go. However, not every integration
scenario requires stateful handling. If it is just about handing
over a message from PDA-L to one or several backend sys-
tems, no state is involved. Hence, the stateful part is obsolete.
The stateful part can be handled either by BPMN processes
(recommended to increase transparency) or specialized inte-
gration software, e.g. Camel (camel.apache.org). Only in
high-performance scenarios, a specialized integration soft-
ware should be used for better throughput reasons or high
performance integration needs. The stateless part covers the
three main aspects of every integration scenario: data trans-
formation, message routing to the right receiving back-end
systems, and technical connectivity such as REST (HTTP-
Protocoll with JSON) or Simple Object Access Protocol
(SOAP) communication or connecting via proprietary proto-
cols. The technical connectivity to the systems is typically
handled by a technical component called a connector. In or-
der to reduce the number of data transformations, it is rec-
ommended to agree on a neutral generic data format on the
PDA-L and SCI-L, also known a canonical data model [28].
As a consequence, data transformations happen from the
SCI-L to the B-L (and vice versa) only within the integration
software. This improves the maintenance of interfaces and
data mappings of process-driven applications. Excel is also a
frequently used exchange format in engineering; it can be
used on the F-S as well as in the PDA on the B-L. On the B-
L the usage of Excel is less problematic, wherease on the F-
S it should only be used in a restrictive manner, e.g. for early
prototypes and small projects, as it creates and hides depend-
encies, which should be avoided whenever possible.
4.4. Minium functional PDA architecture (MFPA) and its
components for process automation
To make the PDA more accessible for the engineering
domain, we have composed the minimally functional PDA
architecture (MFPA) and its components as depicted in
Fig. 9. The goal is to show how to create an initial functional
and useful PDA application within existing solutions and
tools, even with Excel tools, which frequently occur in
industrial software landscapes. The composition of the
components in Fig. 9 should demonstrate that a first start to
utilize the PDA is quickly achievable.
Fig. 9. MFPA and its components for the engineering domain
I) Necessary scope of components: For BPMN
modeling, different solutions are avaliable, e.g. from
Signavio (signavio.com), Camunda (bpmn.io), or ARIS
(ariscloud.com). For process and rule execution, different
process engines can be used, e.g. the open source engine
Activiti (activiti.org) or the freemium engine Camunda
(camunda.com). These engines support user and task
management as well as process execution and monitoring.
Decision Model and Notation (DMN) [29] can be utilized for
integrated, structured decision rules within process engines.
II) Additional components: Web browsers can be used
as a user interface into the PDA, e.g. for task management,
monitoring as well as administration. For external user com-
munication as well as data acquisition, processing, and dis-
tribution, further applications can be integrated, e.g. using e-
mails or user-centered websites and apps. The data exchange
with third-party applications is performed using for example
REST API with a pre-defined JSON or XML structure. Be-
sides DMN for decision tables, further logic and scripts can
be directly integrated into process engines using Java code.
Necessary scope of com ponents for process execution
1) Process and
decision rule model ing
2) User
management
4) Process and decision
rule execution
5) Process
monitoring
BPMN/ DMN modeler Admin view BPMN process engine and dashboard
Minimum functional PDA architecture (MFPA) and its components for process automation
9) Integrated
logic
7) External user
communication
8) Data
exchange
Process engine
integrated scripts
and logic e.g.
based on Java
Additional
application
e.g. e-mail, app,
website
Web interfaces
e.g. REST API
combined with
JSON
Additional component s
3) Task
management
Task list
6) User
interface
Web
browser
e.g.
Chrome
10) Complex logic and
expert knowledge
Engineering
tool integration
e.g. complex Excel tool s
or simulation tools
I
II
Eike Schäffer et al. / Procedia CIRP 00 (2019) 000–000 5
To integrate more complex logic and expert knowledge, ad-
ditional applications can be connected via REST API as well.
This is especially important in the engineering domain, since
the re-implementation effort of e.g. existing complex Excel
tools or complete simulation environments would not be eco-
nomically reasonable.
5. Prototypical implementation and validation
The following validatation is based on a specific use case
and a corresponding prototypical implementation.
5.1. Presentation of the validation use case
As validation use case, the risk assessment phase within
an automation project has been selected. The process has
been simplified to make the general idea behind the MFPA
more accessible and comprehensible. According to Fig. 10,
a new automation project is launched by a project manager.
In this example, the next process step is a risk assessment.
The PDA-L is not interested in the details of the evaluation
as it is not relevant from the pure functional view of this
layer. Hence, the process step has been separated. The engi-
neer assigned to the project receives an automatic order by e-
mail to perform a risk assessment. The risk assessment is per-
formed using an Excel tool developed internally by the com-
pany for such kind of automation projects. The engineer en-
ters the project ID into the Excel tool, also received in the
first e-mail. Based on the ID, the Excel tool imports the pro-
ject-specific information via a REST API call from the B-L
reusing an already existing project database. Then the engi-
neer performs the risk assessment in the Excel tool. After
completion of the evaluation, the essential results and key
performance indicators are sent back to the PDA-L via REST
API (step ‘Send confirmation’ in the SCI-L process) and the
SCI-L process is completed. Within the PDA-L, the project
manager is automatically notified to check and release the
results or in case of insufficient risk assessment to adapt the
requirements for a re-evaluation of the risk.
Fig. 10. Excerpt from PDA architecture exemplified by the use case
5.2. Validation through prototypical implementation
The validation through prototypical implementation of
the general PDA architecture for the engineering domain
(Fig. 8) and the MFPA (Fig. 9) is accomplished using the
Camunda Community Platform process engine as well as
BPMN and DMN modeling tools (Camunda modeler). The
web browser Chrome was used as front-end. The main test
project and integrated logic based on Java was built within
the programming environment Eclipse for Java JDK using
Maven archetype (Camunda-bpm) for direct build integra-
tion into Camunda. As a ready-to-run e-mail server, a Gmail
account was used for external communication based on a pre-
defined e-mail template. To demonstrate the integration and
communication of external engineering services with the
process engine through REST API calls, we used an exem-
plary Excel tool as well as the Postman API communication
testing tool (postman.com). The logic in the Excel tool and
the REST API connection (method: msxml2.ServerXMLhttp)
was built based on the programming language VBA.
In doing so, we demonstrated the easy integration and
communication of existing and newly created engineering
tools into the PDA (Fig. 10). In order to demonstrate the
MFPA within the engineering domain in a comprehensible
way, relatively simple and available software tools were
used, as described in the previous paragraph. These should
be replaced depending on the scope of the project through
more powerful alternatives. The replacement of tools has no
effects on the engineering process of the PDA due to the pro-
cess-driven architecture shown in Fig. 8, applying the sepa-
ration of concerns principle. This ensures high flexibility in
case of applying valuable engineering processes on top of
different back-ends and tools. The advantages of the PDA
became obvious during implementation, having transparent
BPMN-based process overviews and running process moni-
toring. In addition, it is possible to adjust and extend the pro-
cess or exchange services to simplify an agile development.
From a first Postman-based communication test service we
extended the prototpye to an Excel tool based service as input
provider, for the BPMN process engine.
5.3. General concept validation through expert discussions
To validate the general concept of PDA within engineer-
ing, we discussed it with three experts from the IT domain
and four experts from the engineering domain, i.e. end users.
The IT experts were asked if they know about PDA ap-
proaches within engineering and how they evaluate the tech-
nical feasibility. None of the interviewed experts knew PDA
attempts related to engineering. The technical feasibility was
rated medium to high. The use of Excel tools was considered
appropriate as an initial solution and for small applications,
but in the long run, the tools should be redesigned for scala-
bility reasons into web services, e.g. microservices.
Engineering experts, i.e. end users, were asked to evaluate
the potential for automation of project management tasks and
tool orchestration. In addition, they also tested the prototype.
The PDA approach was unknown to all interviewees, but af-
ter a detailed explanation, great potential was seen, espe-
cially because of the graphical process description and the
potential for engineering tool orchestration. In particular, the
manual transfer of data from one tool to another causes high
workloads and many potential errors. This problem could be
addressed successively and in a structured way using the
PDA within the engineering domain. However, without the

212 Eike Schäffer et al. / Procedia CIRP 96 (2020) 207–212
6 Eike Schäffer et al. / Procedia CIRP 00 (2019) 000–000
concrete engineering example, most experts had problems
imagining the transferability from the business to the engi-
neering domain. It is therefore necessary to provide further
guidance for the use of the PDA and to elaborate additional
examples in future projects.
6. Conclusion and outlook on future research activities
Encouraged by the challenges in project management and
engineering tool integration, we have introduced the PDA
into the engineering domain. The PDA is based on BPMN,
which is directly executable using process engines. For a
transparent and explicit separation, the PDA is divided into
three layers: 1) the PDA Layer, 2) the Service Contract Im-
plementation Layer and 3) the Back-end Layer. Additionally,
the x) Front-end Shell for user interaction can be realized via
different approaches such as web technologies, apps, e-mail,
or even Excel. These can be optimized via user-centred ap-
proaches as shown using the example of a web-based robot
configurator [27]. Based on the PDA, a MFPA is derived and
prototypically implemented using an exemplary engineering
use case. To be able to transfer the concept to other use cases,
an easily accessible software setup for concrete implementa-
tion is derived. Thus, we demonstrated the integration and
communication of existing and newly created engineering
tools into the PDA based on the MFPA, with the goal to cre-
ate a first basis for a transparent and automatic process inte-
gration. A more flexible orchestration and coupling of soft-
ware tools contributes to the aim of flexible mass customiza-
tion through more consistent and adaptable engineering pro-
cesses.
For future research, process bottlenecks could be visual-
ized and optimized using a heat map provided by the Ca-
munda Enterprise Edition. In addition, consistent data mod-
els for the PDA as well as methods for their consistent devel-
opment should be established, optionally combined with Au-
tomationML for the engineering domain [30]. Supplemen-
tary, the use of the PDA is conceivable in the area of manu-
facturing as well, e.g. for connecting, scheduling or routing
manufacturing operations as a service.
Acknowledgements
The research project ROBOTOP (01MA17009E) is
funded by the German Federal Ministry of Economic Affairs
and Energy (BMWi). ROBOTOP is part of the technology
program “PAiCE Digitale Technologien für die Wirtschaft”
and is guided by the DLR Project Management Agency in
Cologne.
References
[1] Keller G, Nüttgens M, Scheer A.-W. Semantische Prozeßmodellier-
ung auf der Grundlage „Ereignisgesteuerter Prozeßketten (EPK)“.
Veröffentlichungen des IWi 1992.
[2] Gadatsch A. Grundkurs Geschäftsprozess-Management: Analyse,
Modellierung, Optimierung und Controlling von Prozessen. 8th ed.
Wiesbaden: Springer; 2017.
[3] Scheer A-W. ARIS - vom Geschäftsprozess zum Anwendungs-
system. 4th ed. Berlin: Springer; 2002.
[4] Walter A. Leitfaden zur Erstellung eines unternehmensspezifischen
PLM-Konzeptes: Product lifecycle Management; transparente
Prozesse und konsistente Informationen im Produktlebenszyklus.
Frankfurt, M.: VDMA-Verl; 2008.
[5] Stiehl V. Process-driven applications with BPMN. Springer; 2014.
[6] Stiehl V, Danei M, Elliott J, Heiler M. Effectively and Efficiently
Implementing Complex Business Processes: A Case Study. In:
Lübke D, Pautasso C, editors. Empirical Studies on the Development
of Executable Business Processes. Springer; 2019, p. 33–57.
[7] Object Management Group. ISO/IEC 19510: Information technology
- Business Process Model and Notation (BPMN);ICS: 35.020; 2013.
[8] Freund J, Rücker B. Real-life BPMN: Using BPMN 2.0 to analyze,
improve and automate processes in your company; 2012.
[9] Schäffer E, Mayr A, Fuchs J, Sjarov M, Vorndran J, Franke J. Mi-
croservice-based architecture for engineering tools enabling a collab-
orative multi-user configuration of robot-based automation solutions.
Procedia CIRP 2019;86:86–91.
[10] Schäffer E, Pownuk T, Walberer J, Fischer A, Schulz J-P, Klein-
schnitz M et al. System architecture and conception of a standardized
robot configurator based on microservices. Tagungsband des 3. Kon-
gresses Montage Handhabung Industrieroboter 2018:159–66.
[11] Schäffer E, Leibinger H, Stamm A, Brossog M, Franke J. Configu-
ration based process and knowledge management by structuring the
software landscape of global operating industrial enterprises with
Microservices. Procedia Manufacturing 2018;24:86–93.
[12] Steinwasser P. Modulares Informationsmanagement in der in-
tegrierten Produkt- und Prozeßplanung. Meisenbach; 1996.
[13] Lechler T, Fischer E, Metzner M, Mayr A, Franke J. Virtual Com-
missioning – Scientific review and exploratory use cases in advanced
production systems. Procedia CIRP 2019;81:1125–30.
[14] Bennett N, Lemoine J. What a Difference a Word Makes: Under-
standing Threats to Performance in a VUCA World. Business Hori-
zons 2014(57):311–7.
[15] Schäffer E, Bartelt M, Pownuk T, Schulz J-P, Kuhlenkötter B,
Franke J. Configurators as the basis for the transfer of knowledge and
standardized communication in the context of robotics. Procedia
CIRP 2018;72:310–5.
[16] Livesey PV. Insights of project managers into the problems in project
management. CEB 2016;16(1):90–103.
[17] Puppe F. Einführung in Expertensysteme. Springer; 1991.
[18] Object Management Group. ISO/IEC 19505-1: Unified Modeling
Language (UML), Infrastructure; 2012.
[19] OASIS Committee Specification. WS-BPEL Extension for People
(BPEL4People) V 1.1; 2010; Available from: www.docs.oasis-
open.org/bpel4people/bpel4people-1.1-spec-cs-01.pdf.
[20] Schäffer E, Mayr A, Huber T, Höflinger T, Einecke M, Franke J.
Gradual tool-based optimization of engineering processes aiming at
a knowledge-based configuration of robot-based automation solu-
tions. Procedia CIRP 2019;81:736–41.
[21] Fricke A, Schoneberger JC. Industrie 4.0 with MS-Excel? Chemical
Engineering Transactions 2015;43:1303–8.
[22] Clark KB, Fujimoto T. Product development performance: Strategy,
organization, and management in the world auto industry. Boston,
Mass.: Harvard Business School Press; 1991.
[23] Reinema C, Pompe A, Nyhuis P. Agiles Projektmanagement. ZWF
2013;108(3):113–7.
[24] Silver B, Fischli S. BPMN, Methode und Stil. 2nd ed. Aptos, Calif.:
Cody-Cassidy Pr; 2012.
[25] Schäffer E, Schulz J-P, Franke J. Robotiklösungen im Baukasten-
prinzip für den Mittelstand; (2019); In: bigdata-insider; Available
from: www.bigdata-insider.de/robotikloesungen-im-baukastenprin-
zip-fuer-den-mittelstand-a-882401.
[26] Schäffer E, Thi K, Franke J. Bedarf und Konzeptvorstellung des For-
schungsprojekts ROBOTOP für einen webbasierten Konfigurator für
den Massenmarkt 2020.
[27] Schäffer E, Shafiee S, Frühwald T, Franke. A development approach
towards user-centered front-ends for knowledge-based engineering
configurators: a study within planning of robot-based automation so-
lutions. In: Proceedings of the 22st ConfWS'20; 2020, "not yet pub-
lished".
[28] Hohpe G, Woolf B, Brown K. Enterprise integration patterns: De-
signing, building, and deploying messaging solutions. 16th ed. Bos-
ton, Mass.: Addison-Wesley; 2012.
[29] Object Management Group. Decision Model and Notation (DMN).
1st ed; 2016; Available from: www.omg.org/spec/DMN/1.1.
[30] Schäffer E, Penczek L, Mayr A, Bakakeu J, Franke J, Kuhlenkötter
B. Digitalisierung im Engineering: Ein Ansatz für ein Vorgehen-
smodell zur durchgehenden, arbeitsteiligen Modellierung am
Beispiel von AutomationML. I40M 2019;2019(1):61–6.