Efﬁcient Multi-view Change Management

in Agile Production Systems Engineering

Felix Rinker

1,2 a

, Sebastian Kropatschek

3 b

, Thorsten Steuer

3 c

, Kristof Meixner

1,2 d

Elmar Kiesling

4 e

, Arndt L

uder

3,5 f

, Dietmar Winkler

1,2 g

and Stefan Bifﬂ

1,3 h

Institute of Information Systems Engineering, TU Wien, Vienna, Austria

CDL for Security & Quality Improvement in the Production System Lifecycle, TU Wien, Vienna, Austria

Center for Digital Production, Vienna, Austria

Institute of Data, Process, and Knowledge Engineering, WU Wien, Vienna, Austria

Institute of Ergonomics, Manufacturing Systems and Automation, OVGU, Magdeburg, Germany

Keywords:

Industry 4.0, Change Management, Multi-view Modeling, Multi-aspect Information System, Production

Systems Engineering.

Abstract:

Agile Production Systems Engineering (PSE) is a complex, collaborative, and knowledge-intensive process.

PSE requires expert knowledge from various disciplines and the integration of discipline-speciﬁc perspectives

and workﬂows. This integration is a major challenge due to fragmented views on the production system with

a difﬁcult a priori coordination of changes. Hence, proper tracking and management of changes to heteroge-

neous engineering artifacts across disciplines is key for successful collaboration in such environments. This

paper explores effective and efﬁcient multi-view change management for PSE. Therefore, we elicit require-

ments for multi-view change management. We design the agile Multi-view Change Management (MvCM)

workﬂow by adapting the well-established Git Workﬂow with pull requests with a multi-view coordination

artifact to improve over traditional document-based change management in PSE. We design an information

system architecture to automate MvCM workﬂow steps. We evaluate the MvCM workﬂow in the context of

a welding robot work cell for car parts, using a typical set of changes. The ﬁndings indicate that the MvCM

workﬂow is feasible, effective, and efﬁcient for changes of production asset properties in agile PSE.

1 INTRODUCTION

Flexible production and shorter product and produc-

tion development cycles are major goals of the Indus-

try 4.0 (I4.0) vision (Galati and Bigliardi, 2019). Con-

sequently, Production Systems Engineering (PSE) has

to become increasingly agile, requiring engineers

from several disciplines to work iteratively and in par-

allel (Eisentr

ager et al., 2018). PSE exhibits char-

acteristics of knowledge-intensive processes (Di Cic-

cio et al., 2015), as design activities typically involve

https://orcid.org/0000-0002-6409-8639

https://orcid.org/0000-0002-9049-8038

https://orcid.org/0000-0002-4847-5182

https://orcid.org/0000-0001-7286-1393

https://orcid.org/0000-0002-7856-2113

https://orcid.org/0000-0001-6537-9742

https://orcid.org/0000-0002-4743-3124

https://orcid.org/0000-0002-3413-7780

considerable tacit knowledge. However, in agile set-

tings, knowledge-intensive aspects are even more pro-

nounced in PSE due to the dynamics coming from

various domains after the completion of an activity.

This setting results in an unpredictable ﬂow of ac-

tivities (dos Santos Franc¸a et al., 2015). Effective

and efﬁcient PSE is covered in guidelines like the

VDI 3695 (VDI, 2009) that discusses the maturity

of PSE organizations. One aspect of the VDI 3695

is Change Management (CM) targeting the multidis-

ciplinary nature of PSE. A method increasingly ap-

plied to support PSE maturity is the Product-Process-

Resource (PPR) approach (Schleipen et al., 2015). It

aims to organize the heterogeneous aspects of prod-

uct designs, production process models, and produc-

tion resources across disciplines. To understand the

impact of collaborative design updates on production

system properties (e.g., on performance, cost, and

risk), changes across disciplines need to be managed

134

Rinker, F., Kropatschek, S., Steuer, T., Meixner, K., Kiesling, E., Lüder, A., Winkler, D. and Bifﬂ, S.

Efﬁcient Multi-view Change Management in Agile Production Systems Engineering.

DOI: 10.5220/0011074000003179

In Proceedings of the 24th International Conference on Enterprise Information Systems (ICEIS 2022) - Volume 2, pages 134-141

ISBN: 978-989-758-569-2; ISSN: 2184-4992

and integrated while supporting their heterogeneous

perspectives (Passow and Passow, 2017). Views on a

PPR properties (i) are often semantically similar, al-

though the engineering artifacts or measurement units

differ; and (ii) concern implicit domain knowledge

that may be difﬁcult to express. These dependencies

introduce challenges for efﬁcient Multi-view Change

Management (MvCM) in agile PSE:

Challenge 1: Scattered and Heterogeneous Domain

Knowledge. Scattered engineering views make it

difﬁcult to track changes’ origin and manage them

across stakeholder views (Wohlrab et al., 2020) prop-

erly. Consequently, MvCM requires comparison ca-

pabilities that go beyond best-practice text compari-

son for program source code (Toulm

e, 2006).

Challenge 2: Insufﬁcient Multi-view Change Man-

agement. The use of change management in PSE

has matured within individual disciplines. How-

ever, mechanisms for multi-view change management

across disciplines are currently not well understood.

PSE, typically organized along several disciplines, re-

quires engineers of different disciplines and organiza-

tions to cooperate, making change management much

more difﬁcult than for a single discipline (VDI, 2009).

To tackle these challenges, we raise the research

question: What process and information system de-

sign can improve the effectiveness and efﬁciency of

multi-view change management in agile PSE?

Aim. We follow the Design Science methodology

to address the research question aiming at improving

the effectiveness and efﬁciency of multi-view change

management in PSE by (i) adapting and evaluating the

Git workﬂow with pull request (Krusche et al., 2016);

(ii) building on a Multi-Domain Engineering Graph

(MDEG) as coordination artifact (Bifﬂ et al., 2021;

Rinker et al., 2021a) for change management.

Remainder of This Paper. Section 2 summarizes re-

lated work. Section 3 introduces an illustrative use

case and requirements for efﬁcient MvCM in agile

PSE. Section 4 introduces the MvCM process and

techniques to automate MvCM activities. Section 5

reports on the results of a feasibility study on a con-

ceptual MvCM prototype. The requirements and data

for the study come from use cases and domain experts

from automotive manufacturing. Section 6 discusses

the research results and limitations. Section 7 con-

cludes and raises directions for future research.

2 RELATED WORK

This section summarizes related work on PSE, on the

management of knowledge-intensive processes, and

on change management in Software Engineering.

Multi-view System Modeling in PSE. In PSE, in-

formation is encapsulated in discipline- and tool-

speciﬁc artifacts (Strahilov and H

ammerle, 2017).

The VDI 3695 guideline (VDI, 2009) describes ma-

turity levels for improving the capabilities of PSE or-

ganizations. In particular, it describes change man-

agement regarding the iterative exchange of engineer-

ing models/data, from single-discipline management

(maturity level B) towards tool-assisted management

across several disciplines (maturity level D). Change

management concerns version/change management

of systems engineering artifacts.

The I4.0 vision requires seamless and traceable

information exchange across disciplines (Bifﬂ et al.,

2017) Model-based Systems Engineering (MBSE)

provides the basis for domain-speciﬁc modeling and

setting up cooperative processes (Huldt and Stenius,

2019). I4.0 assets (Heidel et al., 2017) represent

the three main aspects of PSE: (i) products with

their properties, (ii) processes producing the products,

and (iii) resources that execute production processes.

Such assets can be deﬁned for the I4.0 Asset Admin-

istration Shell (AAS) (Plattform Industrie 4.0, 2020)

using PPR modeling (Schleipen et al., 2015). PPR-

based multi-view engineering networks seem promis-

ing to coordinate changes in artifacts and models, us-

ing markers according to a coordination policy (Bifﬂ

et al., 2021; Rinker et al., 2021a).

Knowledge-intensive Processes. A key character-

istic of I4.0 is to support highly conﬁgurable prod-

ucts with a low overhead for production system re-

conﬁguration (Gilchrist, 2016). Therefore, agile PSE

and production require agile and ﬂexible workﬂows.

Agile PSE exhibits characteristics of Knowledge-

Intensive Processes (KIPs) (Di Ciccio et al., 2015)

as PSE processes are not tightly framed and do

not follow predeﬁned, deterministic workﬂows. In-

stead, their execution depends heavily on knowledge-

intensive decision-making by experts coming from

multiple disciplines. To manage KIPs, it is neces-

sary to focus not only on tasks and workﬂows but to

capture a variety of interrelated elements (Di Ciccio

et al., 2015). In the agile PSE context, these elements

include data, actions, rules, processes, production re-

sources, and experts from various domains along all

phases of the PSE life cycle.

Change Management in Agile Software Engineer-

ing. In agile software engineering, the Git Work-

ﬂow With Pull Requests (Krusche et al., 2016) is a

best practice for quality assurance and coordination

of changes to source code, resulting from the parallel

work of several contributors in a distributed project.

This workﬂow consists of three phases: (i) scop-

ing of source code management by deﬁning main and

Efﬁcient Multi-view Change Management in Agile Production Systems Engineering

135

feature branches as context for the change manage-

ment workﬂow, including explicit dependencies of

code elements; (ii) pull requests by contributors to

trigger merging changes from feature branches into

the main branch, deﬁning the changescope to assess;

and (iii) a review process for assessing the change-

set regarding its impact on the main branch, including

dependencies to other code parts. In particular, this

concerns parallel changes, which may warrant con-

sidering the changesets of several pull requests that

concern related/dependent code.

The Git Workﬂow with Pull Requests has been

successfully used for source code, with text-based

identiﬁcation of changes. Popular code management

platforms, such as GitHub

or Bitbucket

, implement

this workﬂow. Code reviewing systems, such as Ger-

rit

, also incorporate the Pull Request concept. While

this approach could be useful in agile PSE, the follow-

ing limitations prevent its direct application: PSE re-

quires change management for changesets in hetero-

geneous multi-model, multi-domain engineering arti-

facts, not homogeneous source code.

In this paper, we build on a PPR based multi-view

engineering graph as integrated multi-view coordina-

tion artifact, to coordinate multi-view change man-

agement in agile PSE following the Git Workﬂow With

Pull Requests by mapping key concepts from soft-

ware engineering to PSE.

3 USE CASE AND

REQUIREMENTS

This section describes the use case laser welding

with a robot and derives requirements from a do-

main analysis at an industry partner from car man-

ufacturing. Fig. 1 illustrates the production process

laser welding automated by a robot with a welding

head (Kropatschek et al., 2021).

Multi-view Change Scenario 1: Change propaga-

tion between semantically similar properties. Engi-

neers work on semantically similar asset properties.

For instance, the welding head temperature proper-

ties in the process expert and the operator views (cf.

Fig. 1, violet circles with letter Y) are considered sim-

ilar. However, the properties might be represented in

different formats or units, e.g., degrees C or K, in arti-

facts, e.g., a speciﬁcation, plan, or log ﬁle. Therefore,

a change of the welding head temperature by the pro-

cess expert is a candidate for efﬁcient propagation and

https://github.com

https://bitbucket.org

https://www.gerritcodereview.com

notiﬁcation of the Operator.

Therefore, stakeholders require means to efﬁ-

ciently mark property changes (cf. Fig. 1, red dia-

monds) to semantically similar properties (cf. Fig. 1,

dependencies represented as violet circles). The prop-

agation typically occurs between stakeholder views of

a single PPR asset, e.g., welding speed, but could also

occur between property views of different PPR as-

sets. If there is a transformation function to represent

the semantic similarity relationship, the transforma-

tion can (i) notify the owner of the dependent prop-

erty of the required change; and (ii) provide a suitable

property value for a valid update. efﬁcient

Multi-view Change Scenario 2: Multi-view re-

validation of properties after changes. Engineers

change asset properties that relate to other properties

that then require re-validation. For example, welding

speed, temperature, and performance are (i) related

among each other and (ii) across stakeholder views

(cf. Fig. 1). For instance, the process expert, automa-

tion engineer, and operator work with these proper-

ties, but in different method and technology contexts.

Hence, stakeholders require means to efﬁciently

identify asset properties that need re-validation after

such changes (cf. Fig. 1, red diamond markers). Fig. 1

shows these multi-lateral change dependencies as cir-

cles in orange with a letter. For instance, the letter

F represents the dependency between welding speed,

temperature, performance, and seam quality. On a

property change, related properties could be marked

(cf. Fig. 1, yellow diamond markers). These change

markers can be used to indicate (i) a required re-

validation to the property’s “owner”; and (ii) possible

change conﬂicts if several markers are present, e.g.,

the welding robot’s PE.welding performance. Change

conﬂicts may occur if stakeholders change asset prop-

erties with dependencies in parallel, in particular, if

they span over engineering artifacts in several views.

For instance, the operator’s change to the welding

speed (cf. Fig. 1) needs to be re-validated and re-

leased by the quality manager, the process expert, and

the automation engineer. The quality manager needs

to approve the achieved quality, the process expert has

to check dependencies to connected processes, and

the automation engineer may have to adjust a program

to address new speed tolerances.

Requirements for Multi-view Change Manage-

ment. Based on the use case, we identiﬁed the fol-

lowing requirements (Rx) for an efﬁcient MvCM ap-

proach to achieve maturity level D (VDI, 2009) re-

garding changes to PPR asset properties. R1. Multi-

view conﬁguration management. The approach shall

represent domain knowledge for multi-view conﬁgu-

ration management of PPR assets and properties. R2.

ICEIS 2022 - 24th International Conference on Enterprise Information Systems

136

Process Resource

Product

Asset

Types:

Link

Types:

Functional

Asset Property

Process-Resource

Product-Process

Assembly

QM.Cycle_time

QM.Process_

Quality

QM.Welding_

Seam_Quality

Metal

Profiles

Welding

Robot

PE.Welding_Speed.min

PE.Welding_Speed.max

PE.Welding_Performance

PE.Welding_Direction

PE.Angle_of_Attack

PE.Lateral_Angle

Welding

Head

Quality

Manager

(QM)

Process

Expert (PE)

Automation

Engineer (AE)

Operator

(O)

Protective

Gas

Metal

Sheet

Welding

Filler

Material

PE.Cycle_time

PE.Process_

Quality

AE.Cycle_time

O.Cycle_time

Laser

Welding

PE.Temperature

_Welding_Head

PE.Welding_

Seam_Quality

O.Temperature

_Welding_Head

AE.Welding_Speed.min

AE.Welding_Speed.max

AE.Welding_Speed.default

AE.Welding_Direction

AE.Angle_of_Attack

AE.Lateral_Angle

O.Welding_Speed

O.Welding_Performance

Products &

Process

Production

Resources

Multi-lateral

Change Dependencies

(markers represent

arrow ends)

Re-validation

Dependency

Semantic

Similarity

V V

Property value changed

Property to re-validate

Stakeholders

Property value progated

Figure 1: Stakeholder view properties for (i) the Laser Welding process (and products); and (ii) the Robot and Welding Head

as main resources of a work cell, based on the Formalised Process Description (FPD) notation (Bifﬂ et al., 2021).

Change tracing. The approach shall facilitate trac-

ing change requests and changes in engineering arti-

facts across stakeholder views. R3. Change coordi-

nation. The approach shall facilitate representing and

manipulating the changestate of PPR assets and prop-

erties as a basis for deﬁning and executing change

coordination policies. In particular, change propaga-

tion for semantically similar properties, and change

re-validation analysis, to efﬁciently determine the po-

tential impact of a change on dependent PPR prop-

erties. R4. Efﬁcient multi-view change management

process. The approach shall provide an efﬁcient pro-

cess for change management across PSE stakeholder

views, building on domain knowledge represented ac-

cording to requirements R1 to R3.

4 MULTI-VIEW CHANGE

MANAGEMENT

This section introduces the MvCM workﬂow and the

MvCM system design to automate workﬂow tasks.

We adapted the Code Review Workﬂow introduced in

(Krusche et al., 2016) from the software engineering

domain to equivalent phases in multi-view manage-

ment in PSE.

MvCM Phase 0: Team Workspace Setup. Be-

fore the MvCM workﬂow can be conducted, the team

workspace, which is comparable to a Git repository,

needs to be set up.

Setting up the team workspace concerns: (i) De-

ﬁne the local concepts of each discipline; (ii) Ne-

gotiate Common Concepts (CCs) between the disci-

plines; (iii) Instantiate a Multi-Domain Engineering

Graph (MDEG) using Common Concepts (CCs); and

(iv) Deﬁne semantic links and dependencies between

properties in the graph (Rinker et al., 2021a).

The MDEG contains the multi-view domain

knowledge required for MvCM as a foundation for

efﬁcient analysis in a graph database. To facilitate

describing dependencies among a group of proper-

ties, we adapt the PPR Asset Network (PAN) meta

model (Bifﬂ et al., 2021) to represent multi-lateral de-

pendencies (cf. Fig. 1, dependency F), going beyond

bi-lateral dependencies, between PPR asset proper-

ties. Further, we deﬁne structured properties, such

as welding speed.min, to represent dependencies on

property welding speed, including property substruc-

tures, such as required, minimal, or maximal welding

Efﬁcient Multi-view Change Management in Agile Production Systems Engineering

137

Change

Welding_Speed

Calculate Diff to

unified model

Create Pull Request to

integrate changeset to

unified model

Test changeset to unified model

and calculate impact on

dependencies by following

previous defined semantic links

Process

Expert

Analysis related engineers and

assign review tasks

Automation

Engineer

Quality

Manager

Engineers review

assigned changes

Common

Integration

Operator

Changes

ok?

Request

Improvement

Rework

Operator

Request

justified?

yes

Escalate

Operator

has

impact ?

yes

need improvement

Start

1 1 1

End

Escalate

Figure 2: Multi-view Change Management (MvCM) workﬂow tasks and decisions, based on (Krusche et al., 2016).

speed. Fig. 2 depicts the MvCM workﬂow to address

changes in a MDEG.

MvCM Phase 1: Local Preparation. In this phase,

an engineer changes a property in a local, domain-

speciﬁc view. The local view is comparable to a fork

in the Git workﬂow in software engineering. For in-

stance, Figure 1 shows the property Welding Speed of

the operator view (O) to be changed, e.g., from 10 to

20 mm/s.

To initiate the integration of the local view

changes to the common view, the engineer creates

a Pull Request, which includes the origin and target

models and the set of change candidates. For instance,

the property O.Welding Speed in the common view

has to be changed to 20. The Pull Request is placed

into the main repository that holds the common view,

assigning the local view engineer as initial reviewer.

MvCM Phase 2: Multidisciplinary Change Anal-

ysis. In this phase, the Semantic Analyzer service

analyzes the impact of the changeset on dependent

properties following the previously deﬁned semantic

links in the MDEG. For instance, semantic links oc-

cur if properties are semantically equal, requiring the

propagation of a property value, or if a semantic re-

lation requires the re-validation of a property value

by an engineer of the corresponding discipline. If the

changeset has no impact on other properties, the next

phase is Common Integration. If the changeset con-

cerns other properties, the Semantic Analyzer service

marks these properties (i) changed due to an update of

a stakeholder artifact (cf. Fig. 1, red diamonds); (ii)

changed due to change propagation between seman-

tically similar properties (cf. Fig. 1, violet diamond);

or (iii) to re-validate due to a change dependency to

a changed property (cf. Fig. 1, yellow diamonds).

These marked changes are assigned for review to en-

gineers of the disciplines concerning marked proper-

ties, e.g., the Quality Manager, Process Expert, and

Automation Engineer.

MvCM Phase 3: Multidisciplinary Examination.

In this phase, the assigned engineers review the

multi-view changes. Review activities concern (i)

the validation of a changed property value due to a

value propagation initialized by the origin pull re-

quest changeset or (ii) the re-validation of a changed

property value due to a calculation, dependent on the

origin change set values. These changes can be (i)

marked as correct, which leads to the phase Common

Integration, (ii) marked as incorrect, which leads to

the task Request Improvement, or (iii) declined, which

terminates the pull request process and escalates the

workﬂow that requires the involved disciplines to dis-

cuss solution options.

MvCM Phase 4: Local Rework. This phase is

initialized by the Request Improvement as a result

of the Multidisciplinary Examination phase. A Re-

quest Improvement is ﬁled, if the initial change-

set results in implausible values in other disciplines,

e.g., after a change by the Operator the calculated

QM.Welding

Seam Quality is not in the range of the

required quality. The engineer, who submitted the

original change in our case the Operator, decides

whether (i) she can address the improvement request

or (ii) rework is impossible, and the pull request needs

to be escalated to project management. If rework is

possible, the engineer updates the open pull request

and triggers phase 2 Multidisciplinary Change Anal-

ysis.

MvCM Phase 5: Common Integration. In

this phase, the pull request applicant integrates the

changeset into the common view. The changeset con-

sists of a list of model differences, i.e., deltas of the

original modiﬁcation in the local view and the prop-

agated and calculated values. These model deltas are

displayed for a ﬁnal review and consistency check-

ing, following the Git Workﬂow staging step. If the

list of model differences is feasible, the pull request

applicant commits the changes to the common view

repository and adds a change description. Finally, the

ICEIS 2022 - 24th International Conference on Enterprise Information Systems

138

common view version is incremented, similar to the

Git Workﬂow using a semantic versioning number.

Multi-view Change System Design. Based on the

elicited requirements (cf. Section 3) we infer the

need for a lightweight and easy-to-manage system de-

sign that incorporates low-code solutions (Bucaioni

et al., 2022). The system design is inspired by the

techniques of the well-established Eclipse Modeling

Framework (EMF) for advanced meta-modeling and

model comparison and merging operations. However,

EMF is closely coupled to Eclipse

, which hinders a

custom-tailored integration into other system archi-

tectures (Batory and Altoyan, 2020). Also, the Git

change tracking system and workﬂow is the foun-

dation for the multi-view model change management

system.

Comparator Merger

Converter

Transformer Semantic Analyser

Multi-view Model

Framework

Graph Database Backend

External Tools

Git Model Backend

Change Management UI

Project Graph

Generator

Figure 3: MvCM System Design, based on MvMF (Rinker

et al., 2021b).

Fig. 3 depicts our design of the Multi-view Change

System architecture building on the Multi-view Mod-

eling Framework (MvMF) implementation (Rinker

et al., 2021b). The system consists of a Git Model

Backend, Graph Database Backend, a Multi-view

Modeling Framework adapted by the Semantic Ana-

lyzer and Change Management UI.

5 EVALUATION IN A

FEASIBILITY STUDY

This section reports on the evaluation of the MvCM

approach. The evaluation environment consists of a

MDEG, i.e., a PAN (Bifﬂ et al., 2021), for the laser

welding process (cf. Section 3). A Neo4J

instance

can be found online.

The case focuses on three PPR

assets and 30 to 40 properties from four stakeholder

views, 12 change dependencies, and a set of three

changes to asset properties. The input data for the

Eclipse IDE: https://www.eclipse.org

Git SCM: https://git-scm.com/

Neo4J: https://neo4j.com

Graph instance: https://github.com/tuw-qse/use-cases/

tree/main/laser welding

MvCM process are XML ﬁles from the use case, in-

cluding quality dependencies from an FMEA tool

The symbols in the diamond-shaped change markers

(cf. Fig. 1) represent a property changeset. The assets,

properties, and links in the PAN provide the basis to

specify graph queries answering questions concern-

ing the change workﬂow, e.g., which properties de-

pend on a changed property? The following Cypher

query retrieves a PAN sub-graph for marking PAN el-

ements that depend on a changed PAN element (cf.

Fig. 1, yellow diamonds).

MATCH (a:Attribute)

-[:has_PPRDependency *]

-(b:Attribute)

WHERE a.name="O.Welding_Speed" AND

a.ChangeState="Changed"

SET b.ChangeState="To Validate"

Listing 1: Cypher query for marking dependent properties

of a changed property for re-validation.

MvCM Efﬁciency in Comparison to Document-

based Change Management. The conceptual pro-

cess comparison estimates the effort for each MvCM

phase, analyzing for which scenarios MvCM is likely

to be more efﬁcient than the traditional approach.

Phase 0. Team Workspace Setup. The engineering

organization in the study context operates on maturity

level CM-B, with engineering toolchains within the

disciplines and data exchange among the disciplines.

Modeling the PAN took only a small extra effort, as

the data can be efﬁciently derived input data.

In the study context, the PAN of the robot cell can

be deﬁned as an output artifact of the data exchange.

For a typical robot cell, deﬁning the PAN requires up

to three workdays. If the PAN is ﬁlled automatically,

it should only take seconds. For the traditional ap-

proach, this task is not required.

Phases 1. Local Preparation and 2. Multidisciplinary

Change Analysis. For the MvCM approach, the con-

ceptual MvCM information system enables the an-

alyzing of PPR asset property value updates. The

conceptual Semantic Analyzer service uses Neo4J for

the change impact evaluation and sets change mark-

ers based on the dependency deﬁnitions coming from

Phase 1 (cf. Listing 1). Therefore, this analysis can

be conducted efﬁciently after each change to the team

workspace, taking a few seconds, to raise the aware-

ness of the involved domain experts.

For the traditional approach, change impact anal-

ysis on the level of PPR asset properties is time-

consuming and error-prone as the domain experts

APIS FMEA: https://www.apis-iq.com

Cypher language: https://www.opencypher.org

Efﬁcient Multi-view Change Management in Agile Production Systems Engineering

139

have to consider the impact of their local changes

to related disciplines. This is often tacit knowledge

or can only be decided by all involved domain ex-

perts. In the study context, domain experts from the

involved disciplines have to come together in a time-

consuming meeting to identify the changes in the use

case.

Phases 3. Multidisciplinary Examination, 4. Local

Rework, and 5. Common Integration. The review re-

quires an overview of changes and their impacts to

accept or reject a pull request and identify follow-up

tasks to address the change impact. All properties

with change dependencies receive markers to guide

the review on these changes (cf. Fig. 1, yellow di-

amonds). To inform planning a focused review, the

PAN provides an integrated view to identify which

stakeholders are required to discuss a speciﬁc set of

changes and to decide on reworking and integrating

the changes, or to reject the pull request.

For the traditional approach, all potentially in-

volved stakeholders have to meet to determine which

views could be affected by a change. Therefore, the

review meetings tend to become large and inefﬁcient.

Further, in a large meeting, it is easy for stakeholders

to overlook a dependency in their view, leading to the

risk of late and costly rework.

6 DISCUSSION

The MvCM process and system design introduced in

this paper facilitate dynamic cross-domain collabora-

tion of experts in KIPs (Di Ciccio et al., 2015) that

are typical in agile PSE. Speciﬁcally, we investigated

how the MvCM approach can improve multi-view

change management by tracking and organizing par-

allel changes by several stakeholders. The evaluation

in the context of a typical industrial joining process

showed the MvCM process to be feasible, effective,

and efﬁcient (cf. Section 5).

The traditional document-based approach works

well for treating isolated, sequential changes in small,

co-located project settings. However, distributed or

large projects in agile PSE, require fast, precise, and

automated analysis of changes on the level of model

property values, considering dependencies between

individual domains, i.e., maturity level CM-D (cf.

Section 2). Therefore, we expect the MvCM approach

to make up the one-time effort required for model-

ing the PAN within a typical large automation project

by reducing the effort for recurring change impact

analysis and avoidable rework due to uncoordinated

changes.

The results go beyond the state of the art in

the area of integrating data from and coordinating

multi-disciplinary changes in PSE (Kattner et al.,

2019; Meixner et al., 2021), in particular MvCM re-

validation, (i) by deﬁning a sufﬁciently ﬁne-grained

MDEG for analyzing changes of property values,

(ii) by considering multi-lateral dependencies, rather

than just bi-lateral dependencies between PPR as-

set properties, (iii) by efﬁciently describing seman-

tic constraints among a group of properties, and

(iv) by demonstrating the feasibility based on data

from changes to PSE artifacts.

Limitations. The following limitations require fur-

ther investigation. Feasibility study. The study fo-

cused on a use case abstracted from a large PSE com-

pany. This may introduce bias due to the speciﬁc se-

lection of the production process, stakeholder views,

or individual preferences of the domain experts. To

overcome these limitations, we plan case studies in a

wider variety of application contexts. Change Cases

and Workﬂow. The selected change cases may in-

troduce bias due to the speciﬁc selection of the data

sets and assumptions of parallel changes. Further, the

research focused on the Git Workﬂow with Pull Re-

quests, a best practice in software engineering, while

there is a wide variety of other engineering change

management approaches. Therefore, we plan to ex-

plore further change cases and change management

approaches to compare their beneﬁts and limitations

in diverse application settings.

7 CONCLUSION AND FUTURE

WORK

This paper investigated effective and efﬁcient Multi-

view Change Management (MvCM) capabilities to

integrate discipline-speciﬁc aspects in Production

Systems Engineering (PSE) into a uniﬁed view. The

MvCM process deﬁnition and evaluation builds on the

Software Engineering best-practice process Git Work-

ﬂow with pull request (Krusche et al., 2016). The

MvCM process and system design provide capabili-

ties for tracking the origin of changes and properly

managing changes in parallel PSE to achieve multi-

view maturity levels according to the PSE guideline

VDI 3695-3 (VDI, 2009).

Results of the feasibility on a typical scope of

changes in PSE to a robot work cell for welding car

parts indicate the MvCM process to be feasible, ef-

fective regarding requirements derived from the PSE

guideline VDI 3695, and efﬁcient in comparison to

traditional document-based change coordination.

Future Work. We plan to investigate approaches that

are semantically more expressive than Neo4J, such

ICEIS 2022 - 24th International Conference on Enterprise Information Systems

140

as Semantic Web technologies and domain-speciﬁc

model management options, to represent and query

larger change management use cases.

ACKNOWLEDGEMENT

The ﬁnancial support by the Christian Doppler Re-

search Association, the Austrian Federal Ministry for

Digital & Economic Affairs and the National Foun-

dation for Research, Technology and Development is

gratefully acknowledged. This work has been par-

tially supported and funded by the Austrian Research

Promotion Agency (FFG) via “Austrian Competence

Center for Digital Production” (CDP) under contract

nr. 881843. This work has received funding from the

Teaming.AI project in the European Union’s Horizon

2020 research and innovation program under grant

agreement No 95740.

REFERENCES

Batory, D. S. and Altoyan, N. (2020). Aocl : A Pure-Java

Constraint and Transformation Language for MDE. In

MODELSWARD 2020, pages 319–327, Set

ubal, Por-

tugal. SCITEPRESS.

Bifﬂ, S., L

uder, A., and Gerhard, D., editors (2017). Multi-

Disciplinary Engineering for Cyber-Physical Produc-

tion Systems, Data Models and Software Solutions for

Handling Complex Engineering Projects. Springer.

Bifﬂ, S., Musil, J., Musil, A., Meixner, K., L

uder, A.,

Rinker, F., Weyns, D., and Winkler, D. (2021). An In-

dustry 4.0 Asset-Based Coordination Artifact for Pro-

duction Systems Engineering. In 23rd IEEE Int. Conf.

on Business Informatics. IEEE.

Bucaioni, A., Cicchetti, A., and Ciccozzi, F. (2022). Mod-

elling in low-code development: a multi-vocal sys-

tematic review. Software and Systems Modeling.

Di Ciccio, C., Marrella, A., and Russo, A. (2015).

Knowledge-intensive processes: characteristics, re-

quirements and analysis of contemporary approaches.

Journal on Data Semantics, 4(1):29–57.

dos Santos Franc¸a, J. B., Netto, J. M., do ES Carvalho,

J., Santoro, F. M., Bai

ao, F. A., and Pimentel, M.

(2015). KIPO: the knowledge-intensive process ontol-

ogy. Software & Systems Modeling, 14(3):1127–1157.

Eisentr

ager, M., Adler, S., Kennel, M., and M

oser, S.

(2018). Changeability in engineering. In 2018 IEEE

International Conference on Engineering, Technology

and Innovation (ICE/ITMC), pages 1–8.

Galati, F. and Bigliardi, B. (2019). Industry 4.0: Emerging

themes and future research avenues using a text min-

ing approach. Computers in Industry, 109:100–113.

Gilchrist, A. (2016). Introducing industry 4.0. In Industry

4.0, pages 195–215. Springer.

Heidel, R., Hankel, M., D

obrich, U., and Hoffmeister, M.

(2017). Basiswissen RAMI 4.0: Referenzarchitektur-

modell und Industrie 4.0-Komponente Industrie 4.0.

Beuth Verlag.

Huldt, T. and Stenius, I. (2019). State-of-practice survey of

model-based systems engineering. Systems engineer-

ing, 22(2):134–145.

Kattner, N., Bauer, H., Basirati, M. R., Zou, M., Brandl, F.,

Vogel-Heuser, B., B

ohm, M., Krcmar, H., Reinhart,

G., and Lindemann, U. (2019). Inconsistency man-

agement in heterogeneous models. In Proc. Design

Society: Int. Conf. Eng. Design, pages 3661–3670.

Cambridge Univ.

Kropatschek, S., Steuer, T., Kiesling, E., Meixner, K.,

uhwirth, T., Sommer, P., Schachinger, D., and Bifﬂ,

S. (2021). Towards the representation of cross-domain

quality knowledge for efﬁcient data analytics. In

ETFA 2021, pages 1–4.

Krusche, S., Berisha, M., and Bruegge, B. (2016). Teaching

code review management using branch based work-

ﬂows. In Proceedings of the 38th International Con-

ference on Software Engineering Companion, pages

384–393.

Meixner, K., L

uder, A., Herzog, J., Winkler, D., and Bifﬂ,

S. (2021). Patterns For Reuse In Production Systems

Engineering. International Journal of Software En-

gineering and Knowledge Engineering, pages 1623–

1659.

Passow, H. J. and Passow, C. H. (2017). What competen-

cies should undergraduate engineering programs em-

phasize? a systematic review. Journal on Engineering

Education, 106(3):475–526.

Plattform Industrie 4.0 (2020). Part 1 - The exchange of

information between partners in the value chain of In-

dustrie 4.0 (Version 3.0RC01 Review). Standard, Ger-

man BMWI. https://bit.ly/37A002I.

Rinker, F., Meixner, K., Waltersdorfer, L., Winkler, D.,

uder, A., and Bifﬂ, S. (2021a). Towards efﬁcient

generation of a multi-domain engineering graph with

common concepts. In ETFA 2021, pages 1–4. IEEE.

Rinker, F., Waltersdorfer, L., Meixner, K., Winkler, D.,

uder, A., and Bifﬂ, S. (2021b). Continuous Integra-

tion in Multi-view Modeling: A Model Transforma-

tion Pipeline Architecture for Production Systems En-

gineering. In MODELSWARD 2021, pages 286–293.

SCITEPRESS.

Schleipen, M., L

uder, A., Sauer, O., Flatt, H., and

Jasperneite, J. (2015). Requirements and con-

cept for plug-and-work. at-Automatisierungstechnik,

63(10):801–820.

Strahilov, A. and H

ammerle, H. (2017). Engineering work-

ﬂow and software tool chains of automated produc-

tion systems. In Multi-Disciplinary Engineering for

Cyber-Physical Production Systems. Springer.

Toulm

e, A. (2006). Presentation of EMF Compare Utility.

In Eclipse Modeling Symposium, pages 1–8.

VDI (2009). VDI Guideline 3695: Engineering of industrial

plants - Evaluation and optimization. Standard, VDI-

Verlag, D

usseldorf, DE.

Wohlrab, R., Knauss, E., Stegh

ofer, J.-P., Maro, S., Anjorin,

A., and Pelliccione, P. (2020). Collaborative trace-

ability management: a multiple case study from the

perspectives of organization, process, and culture. Re-

quirements Engineering, 25(1):21–45.

Efﬁcient Multi-view Change Management in Agile Production Systems Engineering

141