ArticlePDF Available

Abstract and Figures

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.
Content may be subject to copyright.
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
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.
... BPMN suggests itself for being used throughout as a lingua franca, from process modelling to seamless integration into a process engine. [6] Fig. 1. Impact of BPMN: goals, roles and modeling terminologies [6] Thereby, a process engine handles the process model execution, as well as orchestration, persisting, process data, reporting and overall management of tasks. ...
... [6] Fig. 1. Impact of BPMN: goals, roles and modeling terminologies [6] Thereby, a process engine handles the process model execution, as well as orchestration, persisting, process data, reporting and overall management of tasks. (Fig. 2) [7]. ...
... (Fig. 2) [7]. (1)(2)(3)(4)(5) according to [6,7] Intuitively, one would start from the business process and refine it top-down until reaching the system level and directly calling the back-end systems from the BPMN models. This approach reveals several disadvantages: The models become hardly understandable for non-BPMN-experts, are hard to maintain, adjust, and operate and even worse, get an increasingly monolithic structure. ...
Article
Full-text available
One of the major trends in the 21st century is the trend towards digital transformation within Industry 4.0. In order to adapt to high volatile market conditions, especially in the context of COVID-19, companies do not only have to transfer their knowledge into digital systems. Furthermore, they have to be able to tailor their business processes rapidly to changing customer’s needs. The implementation of efficient and transparent processes is thereby known as the process of digital transformation and requires its underlying software-architecture to be highly flexible and scalable. Especially a web-based platform represents a highly user-centered application for multi-user purposes and can quickly adapt to its customer needs. While e-commerce and video-streaming platforms, like eBay or Netflix, often already provide a highly flexible, microservice-based architecture, common tools and platforms within the engineering-domain are usually still based on rather monolithic or service-oriented architectures (SOA). Therefore, an adaption to changing market conditions and the integration of proprietary tools is often technically demanding and economically not feasible, especially for small and medium-sized enterprises (SME). In this context, the so-called Process-Driven-Approach (PDA) offers a sustainable and tool-neutral blue-print for a system’s architecture strictly following the separations-of-concerns principle and allowing a user-centered layout. The PDA enables the integration of business processes and tools within an orchestrating framework, provided by a process engine. While the PDA within the engineering domain has been presented in a preceding paper, this paper supposes a reference architecture and agile development method for engineering-platforms via the PDA based on the BPMN-standard and process engines. These concepts are validated by a prototypical implementation of a platform-demonstrator for tool-supported planning of robot-based automation solutions.
... 2) Business Process Model: The business process model refers to the predefined subbusiness running sequences, subbusiness triggering rules, and the operating relationship between different subbusinesses in a complete business process [105], [106]. Business processes can be serial, parallel, or mixed. ...
Article
The application of automation technology and artificial intelligence technology has promoted the improvement of the business capabilities of enterprises in industrial scenarios. Compared with the improvement or innovation of the business process, in recent years, part of academic research and practical applications also have shifted their attention from a single point of business intelligence perspective to a comprehensive intelligent upgrade of the industrial system. To the best of our knowledge, however, there is little research on the concept and model of the industrial intelligent system (IIS). To make up for the lack, this paper presents the concept, and reference model of IIS by analyzing the intelligentization requirement of the industrial systems. Different from academic research on general intelligent system capabilities, the reference model given emphasizes factors that need to be considered when implementing IIS in the industry. By analyzing the reference model, knowledge as the core driving force of IIS is recognized. Then, the four main forms of knowledge in IIS, as well as the role and key technologies of knowledge in different stages of IIS, are discussed in detail. In addition, several important potential applications of IIS are pointed out in this paper.
... BPMN in combination with process engines could be used for process control of data acquisition as well as for coordinating individual user-centric data acquisition tools. BPMN in combination with process engines could be used for the management of data acquisition processes [25] as well as for the coordination of specialized developed user-centered data acquisition microservices [17,23]. ...
Article
Full-text available
Automation solutions in production represent a sensible and long-term cost-effective alternative to manual work, especially for physically strenuous or dangerous activities. However, especially for small companies, automation solutions are associated with a considerable initial complexity and a high effort in planning and implementation. The ROBOTOP project, a consortium of industrial companies and research institutes has therefore developed a flexible web platform for the simplified, modular planning and configuration of robot-based automation solutions for frequent tasks. In this paper, an overview of the project’s scientific findings and the resulting platform is given. Therefore, challenges due to the scope of knowledge-based engineering configurators like the acquisition of necessary data, its description, and the graphical representation are outlined. Insights are given into the platform’s functions and its technical separation into different Microservices such as Best Practice selection, configuration, simulation, AML-data-exchange and spec-sheet generator with the focus on the configuration. Finally, the user experience and potentials are highlighted.
... Especially the further development of engineering web platforms in combination with configurators still offers a lot of potential for future research. In particular, Business Process Model and Notation (BPMN)-based process automation still offers a lot of potential to be integrated into web platforms [32,33]. Also Scrum as an agile development approach becomes more and more important to develop innovative software systems for engineering as well as configurators [34]. ...
Article
Full-text available
Robot-centric automation solutions (RAS) promise more efficiency and quality in production as well as more economic stability and security through local production, especially in the times of COVID-19. Nevertheless, due to their high complexity and costs, RAS are only used to a limited extent by small and medium-sized manufacturing companies. As a rule, the high costs of RAS arise from individual engineering, which takes up to 70 percent of the acquisition costs. For this reason, it is necessary to optimise the engineering of RAS. Among other things, better software and less costly top-down engineering methods are needed for this kind of enhancement. Pure optimisation via more advanced simulation tools is not sufficient. Configurators in particular offer the possibility of automatically arranging individual solutions from existing experience. Up to now, however, configurators have been used primarily for the individualisation of products, such as automobiles or clothing, on the basis of the variants predefined by the manufacturer, and less for the engineering of automation solutions. To make top-down configuration and simulation functions easily available to small medium enterprises, a web platform is a convenient solution. Due to the high complexity within the engineering domain, it is reasonable to build this kind of web platform with different services from specialised companies, e.g. by using microservices (MS). Conceivable roles could be as following. The web platform operator (WPO) offers an industry-specific, turnkey complete web platform. The WPO combines, integrates and orchestrates various modules and MS like configuration, simulation, data exchange and other. The MS can be provided by MS providers. In particular, since data interoperability and exchange are very important for engineering, an AutomationML (AML) MS is used to implement both. AML particularly supports the generic exchange of data based on industrial standards. To provide a general solution, a MS and AML-based web platform reference architecture was developed. These concepts and MS architecture are validated via a prototypical implementation and utilisation of the web platform within the scope of the ROBOTOP research project. Thus, the potential for increasing efficiency in engineering for RAS could be demonstrated using this top-down approach.
... In the context of future developments, the ideas of the EC are to be linked more closely with process-driven approaches (e.g. [41]) in order to combine the advantages of configuration with those of scalable process automation platforms (e.g. [42]). ...
Article
Full-text available
Robot-centric automation solutions (RAS) promise greater efficiency and consistent quality in production, relieving workers of physically demanding and dangerous tasks, especially in the times of COVID-19. Nevertheless, due to their relatively high complexity and implementation costs, RAS are only used to a limited extent by small and medium-sized manufacturing companies. As a rule, the high costs of RAS arise from custom engineering efforts, which take up to 70 percent of the acquisition costs. For this reason, it is necessary to optimise the engineering of RAS. However, software tools such as configurators have been used primarily for the individualisation of products, such as automobiles or clothing, based on variants predefined by the manufacturer, and less for the engineering of automation solutions. The development of knowledge-based systems, in particular knowledge-based engineering configurators (EC), is usually performed by few proficient experts with high development effort. One of the primary challenges in the knowledge acquisition is that several experts possess partial aspects of knowledge in an inhomogeneous, implicit form. Furthermore, there is a lack of efficient development methods for EC. By reusing knowledge elements from previous development projects, a sustainable increase in efficiency is possible. In order to enable an efficient development process of EC, we introduce a structuring model consisting of four knowledge domains (KD): knowledge about specific business cases (KD1), Best Practices as case-specific solution knowledge (KD2), logical expert knowledge (KD3) as well as semantically consistent data models for interoperability of different IT systems (KD4). As the four KD are independent, their development can be agilely divided among several teams or companies. Finally, the agile development approach is validated individually for each KD as well as comprehensively within the scope of the ROBOTOP platform for planning RAS.
Book
Full-text available
Der Markt für roboterzentrierte Automatisierungslösungen (RA) ist ein globaler Wachstumsmarkt. Aufgrund der hohen Kosten und Komplexität von RA bleiben häufig kleine und mittlere Unternehmen (KMU) hinter diesem Trend zurück. Gegenstand und Zielstellung der Promotion ist die Schaffung von effizienten sowie skalierbaren Engineering-Konzepten und -Lösungen für die Planung von RA auf Basis von Webtechnologien. Hierfür wurden das Konzept des Engineering-Konfigurators, eine microservicebasierte Webplattform-Referenzarchitektur sowie eine für Engineering-Konfiguratoren benötigte Entwicklungsmethode basierend auf drei Teilmethoden (W1-W3) eingeführt. Über nutzerzentrierte Entwicklungsansätze, eine modulare Architektur für RA sowie Ansätze aus der wissensbasierten Konfiguration (Teilbereich aus der künstlichen Intelligenz (KI)) werden der Vertrieb, die Planung und das Engineering von RA einem breiteren Publikum zugänglich gemacht. Validiert wurden die Konzepte und Methoden im Rahmen der Webplattform ROBOTOP sowie anhand diverser 3D-Web-, AR (Augmented Reality)- und VR (Virtual Reality)-Mehrbenutzer-Demonstratoren. Die Konzepte und Methoden befähigen somit auch eine effiziente Digitalisierung bzw. Prozessautomatisierung des Engineerings von RA durch die eingeführten, strukturierenden Methoden zur Wissenserfassung, -modellierung sowie -implementierung und unterstützen dabei die Vision des digitalen Zwillings im Kontext von Industrie 4.0.
Article
Full-text available
Configurators are well-established strong researched expert systems due to the high popularity and gained benefits. Nevertheless, the aspects of user-centered design are rarely researched and applied during the development of configurator front-ends. However, when addressing a mass consumer market or non-experts end-users, the front-end represents the required crucial knowledge that bridges the end-user's current level of knowledge to the experts' knowledge. In order to push the application of knowledge-based engineering configurators for a mass market in SMEs, a user-centered configurator frond-end for the concept planning of robot-based automation systems is being developed within the platform project ROBOTOP. In this paper, the design of an architectural user-centered layer and a ten-step development approach of user-centered front-ends are presented.
Thesis
Full-text available
Die Gewährleistung größtmöglicher Flexibilität in allen Stadien der Entwicklung und Produktion gewinnt angesichts schwieriger Marktbedingungen und sich immer schneller ändernder Kundenbedürfnisse immer mehr an Bedeutung. In der vorliegenden Arbeit wird ein Modellkonzept erstellt, das auf abstrakter Ebene Informationen, Abläufe und funktionale Komponenten innerhalb der Produkt- und Prozeßplanung abbildet. Dieses Modell dient als Grundlage für den Aufbau rechnergestützter Werkzeuge und kann integrativ bis in die Produktion eingesetzt werden. Die im Kapitel 2 aufgezeigten Defizite bestehender Rechnerlösungen zeigen vor allem die Problematik sowohl der Heterogenität als auch der stark unterschiedlichen Sichtweisen der an der Planung beteiligten Personen auf. Eine frühzeitige Berücksichtigung von Realisierungs- und Implementierungsdetails in der Entwicklung dieser Werkzeuge verstärkt die Diversifikation in den Zielsystemen noch mehr. Eine umfassende Betrachtung und Überprüfung der korrekten Abbildung des realen Ausschnittes ist damit nicht mehr möglich. In den letzten Jahren nahm der Einsatz objektorientierter Methoden gerade im Bereich der Programmentwicklung zu. Die Elemente bei der Modellierung von Realitätsabschnitten entsprechen mehr der menschlichen Vorgehensweise im Vergleich zu den rein prozeduralen Sprachen herkömmlicher Softwaresysteme. Gleichzeitig ermöglichen sie die Abbildung komplexer Elemente, die mit Hilfe der modellinhärenten Abstraktion transparent bleiben. Die in Kapitel 3 aufgezeigten Elemente der Planung werden mittels der erwähnten objektorientierten Konstrukte abgebildet und für den Bereich der Produkt- und Prozeßplanung strukturiert. Es wird darauf Wert gelegt, daß eine Entkopplung zwischen Produkt- und Ressourceninformationen stattfindet. Diese informatorische Lücke wird durch ein Modul geschlossen, das in der Lage ist, nach beiden Seiten die jeweiligen Benutzersichten mit den entsprechenden Informationen zur Verfügung zu stellen. Die Beschreibung des Produktes innerhalb des Modells wird in Kapitel 4 aufgezeigt. Durch die Abbildung der Informationen als Objekte, die bei Instanziierung den Planungsfortgang steuern, kann der Produktplaner auf beliebigen Detaillierungsebenen und entsprechend seinem Informationsstand eine neutrale Beschreibung in Form von Produktzustandsübergängen definieren. Die neutrale Abbildung beinhaltet die Aufgaben, die durch die Prozesse innerhalb der Produktion erfüllt werden sollen. Im Gegensatz zu einer statischen Betrachtung, wird in Kapitel 5 zur Anbindung der Ressourcen eine Abbildung der funktionalen Eigenschaften in den Vordergrund gestellt. Ressourcenoperationen können damit als Bestandteil der Zielfunktion der Prozeßplanung direkt ermittelt und überprüft werden. Durch einen flexiblen hierarchischen Aufbau ist darüberhinaus eine beliebige Strukturierung nach verschiedenen technologischen Gesichtspunkten möglich. Die Verknüpfung der beiden beschreibenden Module durch eine neutrale Komponente, die Informationen aus fertigungs- und montagetechnologischen Anforderungen mit funktional operationsorientierten Komponenten verbindet, erfolgt in Kapitel 6. Der Vorteil des Moduls PROZESS ist einerseits die Darstellung der Menge an Technologiemöglichkeiten als Informationsbasis, die dem Produktplaner entsprechend seiner Benutzersicht prozeßorientiertes Wissen zur Verfügung stellt. Andererseits erfolgt durch die Abbildung der Technologien auf ressourcenneutrale Operationen eine Entkopplung von ressourcenbezogenen Randbedingungen, gleichzeitig aber auch die definierte Ausrichtung der Technologielösungen nach unternehmerischen Kriterien (Kosten, Standards usw.) Auf diese Weise verfügt der Prozeßplaner über ein Netzwerk an Lösungen, das ihm auf jeder Detaillierungsstufe die möglichen Alternativen aufzeigt und die gewählte Lösung wiederum in das System integriert. Die in den Kapiteln dargestellten Ausführungen für den Bereich des automatisierten Klebstoffauftrages werden in Kapitel 7 anhand einer beispielhaften Realisierung des Moduls PROZESS präzisiert. Die Ankopplung dieses Moduls an eine reale Montagezelle zeigt den über die Planung hinausgehenden Nutzen des Konzeptes für den Betrieb exemplarisch auf. Das in dieser Arbeit gezeigte Modellkonzept berücksichtigt in umfassender Weise die unterschiedlichen Strukturen und Sichtweisen im Planungsablauf. Bei der Entwicklung rechnergestützter Werkzeuge wird deshalb auf ein übergeordnetes Konzept gesetzt, das die Integration von Daten, Abläufen und Funktionen gewährleistet. Daraus leitet sich ein erhöhter Anspruch an Softwarelösungen ab, die künftig nicht mehr nur konkreten, isoliert betrachteten und spezialisierten Aufgaben genügen dürfen, sondern sich grundsätzlich auf übergeordneter Ebene in ein Gesamtkonzept mit einer dedizierten Funktion einordnen müssen. Die Nutzung eines objektorientierten Ansatzes ermöglicht die Detaillierung in jeder Phase der Entwicklung von Lösungen und stellt gleichzeitig ein besseres Äquivalent für die Abbildung menschlichen Planungsvorgehens dar. "Human Resources” können deshalb in das Modell problemlos eingegliedert werden. Ein Vorteil, der in Zukunft zunehmend an Bedeutung gewinnen wird, um die menschliche Kreativität als Rationalisierungspotential verstärkt nutzen zu können, was bei vorgegebenen, starren Strukturen in weitaus geringerem Maße möglich ist. Die Entwicklungen im Bereich des "Rapid Prototyping” haben in den letzten Jahren bereits zu erheblichen Einsparungen in der Produktentwicklung geführt. Für einen bestimmten Fertigungsprozeß werden rechnergestützte Werkzeuge miteinander gekoppelt und die Prozeßkette wird für einen dedizierten Bereich optimiert. Das Ergebnis der Planung ist ein physisches Modell, das allerdings immer wieder neu erstellt werden muß, sobald eine Änderung am Produkt erfolgt. Gefordert wird heute ein System, das in jedem Stadium der Produktentwicklung Änderungen an Design, Funktionalität, Gestalt, Material usw. erlaubt, ohne daß aufwendige Neuplanungen notwendig sind. Gleichzeitig sollen Wechselwirkungen mit anderen Bereichen in kürzester Zeit dargestelit werden können. Beim "Virtual Prototyping” wird ein Ansatz verfolgt, bei dem vollständig auf physische Modelle in der Planung verzichtet wird und verschiedene rechnergestützte Werkzeuge mit Hilfe eines rechnerinternen Modells verknüpft werden sollen. Das Rationalisierungspotential, das diese Entwicklungsmethodik bietet, läßt sich weiter deutlich erhöhen, wenn sich einzelne Komponenten beliebig austauschen lassen und alle Planungsinstanzen umfassend abgebildet sind. Dabei gilt es, eine Betrachtung weitaus umfassender Strukturen als bisher durchzuführen, diese zu beherrschen und zu koordinieren. Aufgrund der damit verbundenen Integration vielschichtiger, verteilter und heterogener Informationsobjekte (Text, Bild, Ton, Video, Netzwerke usw.) kann die Analyse und Entwicklung solcher Systeme nicht mehr ausschließlich auf datentechnischer Ebene erfolgen, sondern muß künftig auf einem Abstraktionsniveau durchgeführt werden, das dem Anwender alle Informationen in seiner Sichtweise und unabhängig von ihrem Ursprung zur Verfügung stellt. Systeme, die die geforderte Flexibilität bei gleichzeitiger Kontrolle der modularen Strukturen gewährleisten, stützen sich auf ein Informationsmanagement, das auf dem in dieser Arbeit entwickelten Modellkonzept aufbaut. Künftige Lösungen, sei es auf übergreifender Ebene oder nur für Teilbereiche, werden sich deshalb beim Aufbau von rechnergestützten Werkzeugen für die Produkt- und Prozeßplanung an dem hier beschriebenen Ansatz orientieren.
Article
Full-text available
Microservice (MS) architectures, especially in combination with micro front ends, are a modern, scalable and sustainable approach to software development. The modular development of individual components and the possibility of a simple, collaborative and iterative development represent a strategic advantage for companies. In addition, the MS approach allows the consistent use of current technologies, whereby new software functionalities can constantly be included. In this paper, the potentials of MS for engineering tools are shown using the example of a web-based configurator for robot-based automation solutions. On the one hand, the implemented prototype illustrates a possible MS architecture pattern and, on the other hand, clarifies how new functionalities such as the collaborative multi-user configuration or different role-based configuration sessions are enabled by such a concept. Using the example of the web-based configuration platform, it is finally shown how a MS architecture contributes to better development and easier deployment of engineering software solutions based on the divide and conquer principle.
Technical Report
Full-text available
The development of a modular, internet-based and open robot platform (ROBOTOP) serves to open up the mass market for robots in service and manufacturing applications. Through an intelligent standardization and reuse of software, hardware and peripheral components as well as the significant reduction of offer and engineering costs, significant cost reductions can be achieved in the planning and design of industrial robotics solutions. Lizenz: CC BY-NC-ND 4.0
Conference Paper
Full-text available
The design and integration of robotic-based automation solutions is a common problem for robotic component providers and especially for their consumers. In this work, a standardized robot configurator is introduced, based on a modular system architecture and best practice solutions. Due to this modular structure, as a backbone of an intuitive web-based configurator, customized robot applications can easily be planned, visualized, simulated and finally realized. The system architecture of the presented robotic configurator is based on microservices, which is a modern, scalable and complexity-reducing solution for the overall system. This paper demonstrates an exemplary configuration process to get an impression about the prospective use of pre-configured ro-botic solutions.
Article
Full-text available
Due to the growing individualization and ever shorter product life cycles, the engineering of automation solutions is facing increasing challenges. The rethinking of common engineering processes and the inclusion of knowledge-based approaches are considered inevitable. However, existing optimization measures often do not meet the actual problems as many approaches in academics are still too immature for practical use. Therefore, a rather simple procedure for the optimization of knowledge-intensive engineering processes is presented here, mainly relying on the incremental, tool-based creation of a common knowledge base. The procedure is validated using the example of a German automotive supplier. Building on this, the further development towards a knowledge-based configuration platform for robot-based automation solutions is illustrated in the outlook.
Article
Full-text available
Virtual Commissioning increases quality and efficiency in production engineering whilst also decreasing required time. Even though it is a foundation for state-of-the-art production systems, it is not in widespread use yet. In this contribution, an overview of current scientific approaches and use cases for Virtual Commissioning is given. Furthermore, additional fields of interest are derived and detailed on exploratory use cases. The findings show that Virtual Commissioning is a crucial factor to engineering of advanced, sustainable production systems as well as a cornerstone of the Digital Twin.
Book
Das Buch schlägt die Brücke zwischen den betriebswirtschaftlich-organisatorischen Methoden und deren digitaler Umsetzung, denn Prozessmanagement heißt zunehmend Gestaltung betrieblicher Aufgaben. Neben methodischen Grundlagen bietet das Werk viele Praxisbeispiele und Übungen. Das Buch von Prof. Gadatsch gilt mittlerweile als der "aktuelle Klassiker", DAS maßgebliche Standardwerk zur IT-gestützten Gestaltung von Geschäftsprozessen. Die neunte Auflage wurde überarbeitet und an die Anforderungen der Digitalen Transformation angepasst. Dabei wurden aktuelle Themen wie Agiles Prozessmanagement, Robotic Process Automation (RPA) oder Process Mining integriert. Die Ausführungen zu Cloud Computing wurden an aktuelle Entwicklungen angepasst und erweitert. Außerdem bietet das Kapitel zur Prozessmodellierung neue Beispiele auf Basis der Lehrerfahrungen des Verfassers. Das Werk deckt den gesamten „Business Process Management Life-Cycle“ ab. Es behandelt die Entwicklung und das Controlling der Prozessstrategie, die fachliche Modellierung der Prozesse sowie die Unterstützung des Prozessmanagements durch Informationssysteme. Für die Wissenskontrolle stehen den Leserinnen und Lesern digitale Lernkarten (Flashcards) zur Verfügung. Der Inhalt • Einführung in das Geschäftsprozessmanagement • Konzepte des Geschäftsprozessmanagements • Organisation und Einführung des Geschäftsprozessmanagements • Prozesscontrolling • Modellierung und Analyse von Prozessen • IT-Unterstützung für das Prozessmanagement Die Zielgruppen • Studierende und Dozierende der BWL und Wirtschaftsinformatik • Fach- und Führungskräfte, die mit der Einführung oder Weiterentwicklung des Geschäftsprozessmanagements und der „Digitalen Transformation“ betraut sind Der Autor Dr. Andreas Gadatsch ist Inhaber der Professur für Betriebswirtschaftslehre, insbesondere Wirtschaftsinformatik und Leiter des Masterstudiengangs Innovations- und Informationsmanagement sowie des Data Innovation Labs im Fachbereich Wirtschaftswissenschaften der Hochschule Bonn-Rhein-Sieg in Sankt Augustin. Er hat umfangreiche Erfahrung als Berater, Projektleiter, IT-Manager und Dozent.
Article
Robotiklösungen versprechen Effizienzsteigerungen und die Entlastung von Arbeitnehmern bei körperlich anstrengenden und gefährlichen Tätigkeiten. Außerdem ermöglichen sie den Erhalt der Produktion in Deutschland. Die Automatisierung von manuellen Tätigkeiten gehört deshalb zunehmend zum Alltag in deutschen Unternehmen. Vor allem für kleinere Unternehmen ist allerdings der hohe Aufwand problematisch. Das Projekt ROBOTOP hat deshalb eine flexible Webplattform entwickelt, die es ermöglicht „baukastenartig“ Hardware-Komponenten zu individuellen Automatisierungslösungen zu kombinieren. Online Link: https://www.bigdata-insider.de/index.cfm?pid=1&pk=882401&p=1
Chapter
The implementation of business processes has been neglected for many years in research. It seemed to be that only hard coding was the appropriate solution for business process implementations. As a consequence in classical literature about business process management (BPM), the focus was mainly on the management aspects of BPM, less on aspects regarding an effective and efficient implementation methodology. This has changed significantly since the advent of BPMN 2.0 (Business Process Model and Notation) in early 2011. BPMN is a graphical notation for modeling business processes in an easy to understand manner. Because the BPMN standard had the process execution in mind when it was designed, it allows for a new way of implementing business processes, on which the process-driven approach (PDA) is based. This approach has been applied in a huge project at SAP SE since 2015 comprising more than 200 business-critical processes. In order to get an impression about the power of the process-driven approach for really complex business process implementation scenarios, this chapter explains the basics about the process-driven approach and shares experiences made during the execution of the project.