Content uploaded by Eike Wolfram Schäffer
Author content
All content in this area was uploaded by Eike Wolfram Schäffer on Oct 20, 2021
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 C IRP 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 103 (2021) 146–151
2212-8271 © 2021 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 9th CIRP Global Web Conference – Sustainable, resilient, and agile manufacturing
and service operations : Lessons from COVID-19 (CIRPe 2021)
10.1016/j.procir.2021.10.023
© 2021 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 scientic committee of the 9th CIRP Global Web Conference – Sustainable, resilient, and agile manufacturing
and service operations : Lessons from COVID-19 (CIRPe 2021)
Available online at www.sciencedirect.com
ScienceDirect
Procedia CIRP 00 (2021)000–000
www.elsevier.com/locate/procedia
2212-8271 © 2021 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 9th CIRP Global Web Conference –Sustainable, resilient, and agile manufacturing and service
operations : Lessons from COVID-19 (CIRPe 2021)
9th CIRP Global Web Conference – Sustainable, resilient, and agile manufacturing and service operations:
Lessons from COVID-19
Reference Architecture and Agile Development Method for a Process-
Driven Web Platform based on the BPMN-Standard and Process Engines
Eike Schäffera,*, Marvin Schoberta, Tobias Reichensteina, Andreas Selmaiera,Volker Stiehld,
Markus Herhofferb, Matus Malac, Jörg Frankea
aInstitute for Factory Automation and Production Systems, Friedrich-Alexander-Universität Erlangen-Nürnberg, Egerlandstr. 7, Erlangen 91058, Germany
bexentra GmbH, Löwenstr. 11, 85276 Pfaffenhofen an der Ilm, Germany
cFlowable Germany GmbH, Schloßstr. 70, 70176 Stuttgart, Germany
dFaculty of Computer Science, Ingolstadt University of Technology, Esplanade 10, 85049 Ingolstadt, Germany
* Corresponding author. Tel.: +49 9131 85-28972; fax: +49 9131 302528; E-mail address: Eike.Schaeffer@faps.fau.de
Abstract
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.
© 2021 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 9th CIRP Global Web Conference –Sustainable, resilient, and agile
manufacturing and service operations: Lessons from COVID-19 (CIRPe 2021)
Keywords: Process-Driven web platform; reference architecture; ROBOTOP; Process-Driven-Approach; PDA; agile; user-centered; development method
1. Introduction
The COVID-19 pandemic has had a heavy impact on the
handling of day-to-day-business. As a result, most companies
are having their employees work from home via different tools
and web platforms. The sudden change of habits has stressed
the previous existing urge to not only connect proprietary
systems to web-based infrastructures, but also to flexibly adapt
their business processes. Furthermore, the adaptability of
processes in a larger context enables a faster reaction to
Available online at www.sciencedirect.com
ScienceDirect
Procedia CIRP 00 (2021)000–000
www.elsevier.com/locate/procedia
2212-8271 © 2021 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 9th CIRP Global Web Conference –Sustainable, resilient, and agile manufacturing and service
operations : Lessons from COVID-19 (CIRPe 2021)
9th CIRP Global Web Conference – Sustainable, resilient, and agile manufacturing and service operations:
Lessons from COVID-19
Reference Architecture and Agile Development Method for a Process-
Driven Web Platform based on the BPMN-Standard and Process Engines
Eike Schäffera,*, Marvin Schoberta, Tobias Reichensteina, Andreas Selmaiera,Volker Stiehld,
Markus Herhofferb, Matus Malac, Jörg Frankea
aInstitute for Factory Automation and Production Systems, Friedrich-Alexander-Universität Erlangen-Nürnberg, Egerlandstr. 7, Erlangen 91058, Germany
bexentra GmbH, Löwenstr. 11, 85276 Pfaffenhofen an der Ilm, Germany
cFlowable Germany GmbH, Schloßstr. 70, 70176 Stuttgart, Germany
dFaculty of Computer Science, Ingolstadt University of Technology, Esplanade 10, 85049 Ingolstadt, Germany
* Corresponding author. Tel.: +49 9131 85-28972; fax: +49 9131 302528; E-mail address: Eike.Schaeffer@faps.fau.de
Abstract
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.
© 2021 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 9th CIRP Global Web Conference –Sustainable, resilient, and agile
manufacturing and service operations: Lessons from COVID-19 (CIRPe 2021)
Keywords: Process-Driven web platform; reference architecture; ROBOTOP; Process-Driven-Approach; PDA; agile; user-centered; development method
1. Introduction
The COVID-19 pandemic has had a heavy impact on the
handling of day-to-day-business. As a result, most companies
are having their employees work from home via different tools
and web platforms. The sudden change of habits has stressed
the previous existing urge to not only connect proprietary
systems to web-based infrastructures, but also to flexibly adapt
their business processes. Furthermore, the adaptability of
processes in a larger context enables a faster reaction to
Eike Schäffer et al. / Procedia CIRP 103 (2021) 146–151 147
2Eike Schäffer/ Procedia CIRP 00 (2019) 000–000
changing customer’s needs in volatile markets. Those
requirements demand ahighly flexible and scalable IT-
architecture. Nevertheless, common systems are still based on
monolithic or service-oriented architectures, complicating its
adaptability [1–3].Therefore, this paper shows a solution to
flexibly combine business processes with IT-infrastructure,
based on the Business Process Model and Notation (BPMN)
standard [4] and introduces a reference architecture as well as
a six-step method for its user-centered and agile development.
2. Relevant basics
During the past decades, digital transformation has yielded
many innovations. While computer aided tools have simplified
mass data handling, the coordination of individual processes
still remainsdifficult due to point-to-point integration problems
between different disciplines within planning, engineering,
control and production [5].For managing efficient and
transparent engineering processes as well as an integrated tool
chain, the Process-Driven Approach (PDA) offers a business-
process-first methodology for creating sustainable, domain-
oriented applications;potentially reducing adjustment costs.
2.1. BPMN-standard within the context of process automation
To establish anexplicit understanding for continuous
process automation, it is necessary to distinguish between non-
and executable process models (before/ after BPMN) based on
generic goals for using business process models, roles, as well
as modeling and implementation approaches.Relevant goals
can be differenciated in four general categories, with each
having different responsibilities (Fig. 1). 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. (Fig. 2) [7].
Fig. 2. Process model execution including phases (1-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 modelsbecome
hardly understandable for non-BPMN-experts, are hard to
maintain, adjust, and operate and even worse, get an
increasingly monolithic structure. Therefore, the PDA offers a
sustainable and tool-neutral blue-print for a system’s
architecture strictly following the separations-of-concerns
principle.
2.2. Process-Driven Approach
Previously, a three-layered architecture for PDA usage
within the engineering domain, based on the separation of
concerns principle, was introduced [6]: The PDA-Layer (PDA-
L), the Service Contract Implementation-Layer (SCI-L) and the
Back-End-Layer (B-L) (see Fig. 3). A user-specific Front-end
User Interface (F-UI) is used for human-machine interaction.
Fig. 3. Three-layered PDA architecture with human-machine interface [6]
The motivation for the division into layers is described in
[6] and [8] in further detail. This allows a transparent and
explicit separation of the business processes from the
respective service implementationsprovided by the existing
IT-landscape. Based on service contracts with input and output
derived from the business processes’ needs, the SCI-L
therefore mediates between the PDA-L and legacy software-
specific applications, systems or (micro-)services on the B-L.
To make the PDA more accessible for the engineering domain,
a minimally functional PDA architecture (MFPA) and its
components have been composed in paper [6]. Hereby, an
extendable framework with fundamental PDA functionalities is
provided.
2.3. User-centered design
User-centered design (UCD) is an iterative process of
system development, with the aim to identify and fulfil user’s
requirements in the best possible manner (see Fig. 4). [9]
Business expert
Responsible role
Business analyst
Comp uter sc ientist
EPC
BPEL/ UML
BPMN
BPMN
BPMN
Different modeling terminologies
Media tion
before BPMN aft er BPMNProcess goal
1) Documentation
2) Ana lysis and op timizatio n
3) I mplementat ion
4) Execu tion and operations Soft ware Hard-coded Process engine
Monitor ing and r eporting
Process
engine
Process
participants IT Sys tem
lead t ime
det ermination
Mode ling (B PMN )
Service
orchestration
Process data
management
Human workflow
management
Executable
process model
Auto matic
decis ion
Auto mat ic
Task
alloca tio n
Process
participants
Task
alloca tio n
1
2 3 4
service
call
service
call
Mode l import
5
SAP Non-SAP DBs
Process-Driven
Application
Layer (PDA-L)
Service Contract
Implementation
Layer (SCI-L)
Back
-
end
Layer (B
-L)
1
2
3
Web technology (HTML, CSS, JS) Mobile application (app)
Front-end User
Interface (F-UI)
Services
Stateful
BPMN
Stateless (a/ b) / -ful (b)
integration software (SW)
Stateful (a) / -less (b)
Integration SW
x
Event stream pro cessing (ESP)
Process engine
BPMN process mod el
Database (DBs)
Simulation
service
SCI-L
Monitoring Simulation
Simulation
microservice
Store
meta-
data
Save
simulation
DBs
Simulation
result
Simulate s cene
Simulate
finished
Project
ID
Simulation
result
Project
metadata
=Queue
b
b
b
b
a
a
a
a
= Data trans-
formation
Service Contract (SC )
Launch
project
Start new
project
Example business process
Engineer Manager
Engineer
3D scene
Check
quality
Build
simulation
Sufficient
quality?
yes
no
Project
finished
Simulation result
Communication based on connectors e.g. REST API web services (XML, JSON)
Other
Statistic
microservice
Project ID
Communication based on connectors e.g. REST API web services (XML, JSON)
148 Eike Schäffer et al. / Procedia CIRP 103 (2021) 146–151
Eike Schäffer/ Procedia CIRP 00 (2019) 000–000 3
Fig. 4. User-centered design [9]
A common method for early phases 0-2 is the definition of
exemplary personas, scenarios and use cases, which result in
user-specifications regarding a system’s usability, workflows
and user-interfaces. Usability can be used to measure a
system’s and intermediate prototype’s degree of requirement
fulfilment, by evaluating its efficiency, effectiveness and
satisfaction [9]. Nevertheless, since a developer usually will
not be the typical user, it is essential to frequently observe and
involve end-users throughout the entire development process.
This enables an enormous potential of complexity reduction for
the user and the developer. [10] The procedure of UCD can be
combined with common agile methods, e. g. Scrum. Hereby,
actions within steps 1-4 can be prioritized and handled within
planned sprints and lead to incremental improvements. [11]
3. Need for action and research methodology
Heterogeneous systems, data of different domains (Fig. 5),
lack of process automation and tracking lead to time and
information losses in the engineering domain as well as to
increased costs due to redundancies, errors and high
management overheads.
Fig. 5. Heterogeneous systems and data using the example of engineering
To reduce synchronization and communication overhead, a
sustainable Process-Driven platform-infrastructure is needed.
In a previous research a MFPA for the engineering domain
as well as an engineering-configurator was introduced [6,12].
The reference architecture and method for agile development
of user-centered engineering platforms presented within this
paper builds upon this MFPA and extending literature research.
In order to continuously improve the referenced content,
multiple development cycles as well as user demonstrations
and expert interviews have been performed. Based on
aggregation of common literature knowledge and insights of
different use cases within the ROBOTOP research project this
paper proposes a reference architecture as well as a
development method as shown in chapter 4 and 5. In section 6,
a minimal functional architecture of a web platform within the
engineering domain is evaluated using a prototypical
implementation. Through interviews and literature research,
improved understanding and potential evaluation was targeted.
4. Reference architecture for engineering-platforms
Since the PDA has successfully supported the digital trans-
formation, including project management, implementation of
process sequences as well as its overall architecture [13], it is
now being adopted within the development of flexible and
scalable engineering-platforms.
4.1. General concept for a Process-Driven web platform
The goal of the concept is to realize digital, cross-project
planning consistency, with simultaneous transparent and
comprehensible process coordination, automation, adaption
and optimization. Therefore, it is necessary that the
individualized information, task lists and tasks are visualized
for the decision-makers, the project management and the
respective users via suitable user interfaces. Especially in the
context of heterogeneous and highly specialized software
landscapes, it is necessary to integrate all existing software
tools, whether CAx or PLM/PDM, as far as possible.
Fig. 6. General concept of a Process-Driven web platform
The focus is a scalable PDA architecture for management
and engineering as well as the process modelling of continuous
management and engineering processes based on BPMN (Fig.
6). The processes are to be executed prototypically by means
of a suitable BPMN process engine. With the help of
transparent processes and standardized interfaces, different,
highly specialized management and engineering tools as well
as microservices and apps can be consistently and continuously
connected, controlled and replaced. The scalability of the
solution and distributed data storage in the sense of big data can
be guaranteed via a hybrid cloud solution, with simultaneous
aggregation of domain expertise. This can be realized by means
of cross-tool data aggregation and analysis services.
4.1. Requirements for modern web platform infrastructure
According to C
HOUDARY
[14] and T
AEIHAGH
[15], platform
infrastructures enable crowdsourcing as well as collaborative
consumption and generally function across three layers. Each
layer provides certain functionalities and therefore has different
requirements:
Project resultIterative system developmentProject definition
Identify need
of human-
centered
design
Understand and
specify
context of use
Specify user and
organizational
requirements
Produce
design s olut ion
Evaluate designs
against requirements System meets
specified
requirements
0
1
2
4
3
Eike Schäffer et al. / Procedia CIRP 103 (2021) 146–151 149
4Eike Schäffer/ Procedia CIRP 00 (2019) 000–000
The Network-Marketplace-Community layer comprises
the users and their interaction with each other. Therefore, a user
and identity management as well as a communication system
has to be provided (e. g. OAuth2/ OpenID Connect).
Furthermore, front-ends for different user devices have to be
designed and load balancing for optimizing response time has
to be considered. The Infrastructure layer enables the user’s
value creation by providing the platform’s core logic and
orchestrating the necessary tools and services. Lastly, the
Data layer contains and provides various goods, services or
content. Supporting (micro-)services for e. g. the exchange of
information or data transformation as well as external
communication build the platforms backbone.
4.2. Reference architecture for PDW within engineering
Fig. 7shows the reference architecture for a PDW,generally
based on the PDA with respect to the layer-specific
requirements mentioned in section 4.1.
Fig. 7. Reference architecture for PDW [6,12]
I) Client side front-ends: For a simplified user interaction
with the platform a suitable front-end visualization is needed.
User interfaces running via web browsers offer a device-neutral
front-end and can be implemented by using e. g. HTML, CSS
or TypeScript-based frameworks like Vue.js or React. Smart-
phone apps and individual interfaces to other devices provide
great mobility and “on-the-run” availability. The scope and
amount of information shown to the user should be considered,
depending on its status, role and accessibility rights. Load
balancing can be realized by e. g. Ingress in a Kubernetes
Hybrid Cloud or via NGINX.
II) Core process driven application: As depicted in section
2.1, the platform’s control of the process logic is exclusively
within the responsibility of the process engine. The connection
to back-end services and databases should be handled via an
asynchronous integration bus, as e. g. provided by Apache
Kafka or RabbitMQ.
III) Necessary back-end services: Platform-basic
components are handled within the back-end: Identity services
for user and role management, communication services for
platform-based messengers as well as further integrated scripts
taking care of the technical back-end execution of processes
and their logic.
IV) Additional back-end services: Depending on the use case,
certain functionalities have to be outsourced to third party
service providers. For instance, Google Maps API can be used
for location services or SendGrid API for external
communication. Furthermore, SQL or JSON-based databases
(like MongoDB) provide storage capabilities for business data
objects via e. g. REST. For better scalability, data exchange
should be realized by making use of the integration bus, e. g.
by integration patterns as provided by Apache Camel.
5. Agile and user-centered development method
For agile development of a scalable, sustainable and user-
centered PDW, a six-step method based on ISO 9241-210 [9],
ZIMMERMANN AND GRÖTZBACH [16] as well as insights from
previous research [17] is now being introduced (Fig. 8). While
step 1-3 set up the conceptual business case requirements, steps
4-6 concern the process design and the implementation of
iteratively increasing detail.Scrum is recommended to be used
for incremental improvements within the latter steps [11].
Fig. 8. Agile development method for user centered PDW
5.1. Business case and value creation network analysis
Within the first step the potential business cases should be
analyzed, considering stakeholders, data, product and payment
flows. This results in the business requirements and sets the
overall scope of the platform, as exemplary shown in Fig. 9.
Fig. 9. Potential value network of a robotics web platform [12]
5.2. Key user identification and prioritization
Within customer segments, the key user groups have to be
identified, e. g. by creating a business model canvas. In case
multiple ones can be identified, a prioritization e. g. by using
weighted decision matrix is recommended. Therefore,most of
all, value proposition, key activities, revenue streams and
channels should be considered, as illustrated in Fig. 10 [18].
Components of reference architecure for PDA-based web platfo rms
Client side front-ends
Core Process-Driv en Application
Process and deci-
sion rule mode ling
Process and deci-
sion rule execution
Task
management
BPMN/ DMN modeler BPMN Process engine
Additional back-end services
Identity
management
Commu-
nicat ion
Integrated
logic
External logic and
Third party services
e. g.
OAuth 2.0
e. g.
Chat , Email,
Whatsapp
Process engine
integrated scripts
and logic e. g.
based on J ava
Microservices for e. g .
complex tool-
integ ration, orderin g,
finances or marketing
Necessary back-end services
Registrated
user view
Admin
view
Process
monit oring
Public
view
Web browser, smartphone app or proprietary interfaces
Storage
services
Databases,
based on e. g.
REST with SQL
or JSON
Event bus
and caches
Other external clients
(e. g. iFrames or devices)
I
IV
Load
balancing
Integr ation
soft ware
III
II
Desig n
User requirements
Key users
Technical
requirements
Funct ional
Prototype
Process
-Driven Appro ach
Concept
Impleme ntation
Final
product
Business Case
UCD
Business
requirements
Business case analysis1
Key u ser ident ification and prio risation2
Target group analysis3
Pro cess mode lling4
Plat form initializat ion 5
Serv ice imple mentatio n and op timization
Front-E nd-
usablility
opt imizat ion
Back-End-
funct ionality
opt imizat ion
Integr ation of
external
services
6
Web platform
Systems provider
Producing
company (SME)
Part producer
Systems integrator
(Micro-)service
provider
Data
provider
Data
Payment
Product \
service
Flow of
150 Eike Schäffer et al. / Procedia CIRP 103 (2021) 146–151
Eike Schäffer/ Procedia CIRP 00 (2019) 000–000 5
Fig. 10. Generic business model canvas of a web platform [18]
5.3. Target group analysis
Next, the identified target group has to be analyzed
regarding their preferences, behaviors and needs. The goal is to
determine certain personas and user scenarios, which can be
carried on into usability, user and UI requirements [16].
Requirements concerning usability can be defined and
evaluated by determining the effectiveness, efficiency and
satisfaction needed. Information can be gathered by literature-
and market-research especially using user-surveys. Thus,
intense potential-user involvement at this point is essential.
5.4. Process modeling based on five steps of development
Based on S
ILVER
[19], processes modeled in BPMN should
be refined top-down in five steps with increasing process logic
detail: Firstly, the overall scope and function of the general
business process from start to different possible endings should
be agreed on. In step 2, the major activities should be
enumerated and described in a high-level list of activities with
well-defined inputs and outcomes. Next, the top-level BPMN
diagram should be modeled using (swim) pools and lanes,
including the high-level activities as individual sub-processes
or Send Tasks taken care of later. Besides the “happy path”,
possible exception paths should be considered as well. In
step 4, each sub-process should be hierarchically extended
within a child-level diagram. Finally, business context should
be visualized by message flows between different (sub-)
processes and service providers drawn as black boxes. Steps 4
and 5 can be repeated with additional nested levels, if needed.
5.5. Web platform initialization via minimal viable product
In order to get a functional prototype, the basic architecture
from section 4.1 as well as the most urgent services should be
implemented. For this, a detailed breakdown of the processes
of the respective domain in order to derive the required services
and UIs must be accomplished, as in previous research [17].
Some process engines (e. g. Flowable) with their enterprise
versions offer “all-inclusive” packages for process modelling
and execution, user and task management as well as complex
front-end design. This enables rapid prototyping to be closer to
the final product implementation.
5.6. (Micro-)service implementation and optimization
Iterative improvement to finish the product: Front-end-
usability and visual design should be optimized until living up
to the defined user’s requirements. Back-end microservices
should be further implemented and optimized for functionality
and performance, as well as external, third-party services
integrated if needed.
6. Validation
For validation purposes, a simple use case within the
ROBOTOP research project has been selected [20]. While the
development method’s conceptual steps 1-3 have been
processed in previous research [12], the validation described in
this paper mainly focuses on the implementation of a flexible
platform architecture. Firstly, the exemplified use case as well
as its implementation will be described and secondly, general
results from user and expert feedback cycles will be presented.
6.1. Validation through prototypical implementation
The exemplified implementation targets the establishment
of a PDW matching demand and supply of consulting services.
The simplified processes are shown in Fig. 11. The back-end
integration has been realized with Apache Camel and
messaging using the open source message broker Apache
ActiveMQ Classic.
Fig. 11. Exemplified contact mediation process based on the PDA
Fig. 12 shows the front-end visualization as seen by a user
with a consulting function. The user interface was designed to
have an intuitive overview over still unanswered inquiries
within a project feed and fast access to own projects.
Fig. 12. Front-end demonstration of exemplified use case implementation
Key Partners Key Activities Value Prop osition Customer
Relationships
Customer Segments
Cost Structure Revenue Streams
Key Resources Channels
Supply side actors
Demand side actors
Content creators
Edge funtionality
provide rs
Match supply and
demand
Engage cust omers
For supply side:
Additional income
Extended market
reach
For demand side:
Convenience
Lower prices
transp arency
time, tech nology,
money, goods ,
know how
In general:
Demand side
Supply side
Content creators
Other participants
Customer support
Transparency
Access and
Communication
(e. g. Web, Apps)
Cost of customer acquisistion
Ongoing subsidies
Platform development & expansion
Charging of t ransac tion fees and access
Revenue p artially based on value creat ion for
demand and supply side
Eike Schäffer et al. / Procedia CIRP 103 (2021) 146–151 151
6Eike Schäffer/ Procedia CIRP 00 (2019) 000–000
6.2. Validation through expert interviews and user tests
To qualitatively validate the results, the architecture,
development method and prototype were presented to and
discussed with several stakeholders.In this context, enterprise
software development, business process automation and
engineering experts were queried within a two-day workshop.
In general, it was seen as a very promising approach, as
graphical process models can increase agility as well as a better
separation of concerns in development. The potential for the
engineering domain was considered high due to the possible
coordination and combination of various existing tools. The
importance of a separated integration layer with e. g. Camel
and ActiveMQ was particularly emphasised. Using user
feedback, the flexibility of the architecture and agility of the
method have been proven. Thus, several times within the
framework of short-cyclic user feedback-based development
loops, the processes could be redesigned and implemented,
without any major additional effort compared to classic, non-
process driven development approaches.
7. Conclusion and outlook on future research activities
Building upon previous research of the Process-Driven
Approach (PDA) within the engineering domain, a reference
architecture and agile development method for a Process-
Driven web platform (PDWP) based on the BPMN-standard
and process engines has been introduced. Based on the PDA
principles, the process orchestration and execution of the
PDWPis conducted via process engine. Thus, the referenced
architecture features a three-layered structure, consisting of the
front-end layer, the core process components including the
process engine,and back-end (micro-)service implementations.
The introduced agile development method is achieved through
the direct process coupling of modelled and executed processes
in combination with user-centered front-end development. For
validation, a Process-Driven platform was implemented in the
context of the research project ROBOTOP.
Future research within the PDA-RobE research project aims
to develop a process-oriented digital twin for plant engineering
that stores, consolidates and makes available project-relevant
information about historical and current production lines as
well as the associated equipment along the Product
Development Process (see Fig. 13). This should significantly
reduce the planning effort of new projects as well as enable the
reusability of already existing equipment and the expertise
acquired through it.
Fig. 13. Process loop for platform-supported and automated planning,
orchestration, control and monitoring of engineering projects
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] Schäffer E, Mayr A, Fuchs J, Sjarov M, Vorndran J, Franke J.
Microservice-based architecture for engineering tools enabling a
collaborative multi-user configuration of robot-based automation
solutions. Procedia CIRP 2019;86:86–91.
[2] Schäffer E, Pownuk T, Walberer J, Fischer A, Schulz J-P,
Kleinschnitz M et al. System architecture and conception of a
standardized robot configurator based on microservices. Tagungsband
des 3. MHI-Fachkolloquiums 2018:159–66.
[3] Schäffer E, Leibinger H, Stamm A, Brossog M, Franke J.
Configuration based process and knowledge management by
structuring the software landscape of global operating industrial
enterprises with Microservices. Procedia Manufacturing 2018;24
[4] Object Management Group. ISO/IEC 19510: Information technology -
Business Process Model and Notation (BPMN);ICS: 35.020; 2013.
[5] Steinwasser P. Modulares Informationsmanagement in der integrierten
Produkt-und Prozeßplanung. Meisenbach; 1996.
[6] Schäffer E, Stiehl V, Schwab PK, Mayr A, Lierhammer J, Franke J.
Process-Driven Approach within the Engineering Domain by
Combining Business Process Model and Notation (BPMN) with
Process Engines. Procedia CIRP 2021;96(57):207–12.
[7] Freund J, Rücker B. Real-life BPMN: Using BPMN 2.0 to analyze,
improve and automate processes in your company; 2012.
[8] Stiehl V. Process-driven applications with BPMN. Springer; 2014.
[9] DIN EN ISO 9241-210, Ergonomie der Mensch-System-Interaktion.
Teil 210, Menschzentrierte Gestaltung interaktiver Systeme (ISO
9241-210:2019). 9241st ed. Berlin: Beuth Verlag GmbH; 2020.
[10] Nielsen J. Usability engineering (Interactive Technologies).
Amsterdam: Kaufmann; 2010.
[11] Ken Schwaber, Jeff Sutherland. The Scrum Guide: The Definitive
Guide to Scrum: The Rules of the Game; 2020.
[12] Schäffer E. Web‐und wissensbasierter Engineering‐Konfigurator
für roboterzentrierte Automatisierungslösungen. Dissertation.
Erlangen: FAU University Press; 2021.
[13] 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.
[14] Choudary SP. Platform scale: How an emerging business model helps
startups build large empires with minimum investment. Boston?:
Platform Thinking Labs Pte. Ltd; 2015.
[15] Taeihagh A. Crowdsourcing, Sharing Economies and Development.
Journal of Developing Societies 2017;33(2):191–222.
[16] Zimmermann D, Grötzbach L. A Requirement Engineering Approach
to User Centered Design.
[17] 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
solutions. In: Proceedings of the 22st ConfWS'20; 2020, "not yet
published".
[18] Eisape D. The Platform Business Model Canvas a Proposition in a
Design Science Approach. AJMSE 2019;4(6):91.
[19] Silver B, Fischli S. BPMN, Methode und Stil. 2nd ed. Aptos, Calif.:
Cody-Cassidy Pr; 2012.
[20] Schäffer E, Shafiee S, Mayr A, Franke J. A strategic approach to
improve the development of use-oriented knowledge-based
engineering configurators (KBEC). Procedia CIRP 2021;96:219–24.
New project
Planning
alter-
natives
Assistance system for
project planning
and process-control –
incl. validation
Align-
ment
Simu-
lation
…
Project planning and proce ss coordination
Status monitoring and optimization
Project-/ facility-/
equipment catalogue
Project status I ncl. progn osis
Decisions Sustainable,
initial planning
Project
progress
Plugin of status
data
Data analysis
and optimization
potential Instructions
Situation
„Digital Twin“
Controlling
Factory planningProjects Strategic planning
…