Available online at www.sciencedirect.

com

ScienceDirect
IFAC PapersOnLine 54-1 (2021) 420–425
An
An FMEA-based
FMEA-based Methodology
Methodology for
for the
the
An FMEA-based
Development of Methodology
Control Software for the
Reliable
An FMEA-based
Development of Methodology
Control Software for the
Reliable
Developmentto of Control
Hardware Software Reliable
Developmentto of ControlFailuresSoftware Reliable
to Hardware
Hardware Failures
Failures
to Hardware Failures
Hussein David Tafur ∗∗∗ Giacomo Barbieri ∗∗∗
Hussein
Hussein David
David Tafur
Tafur Giacomo ∗∗ Barbieri
∗ Giacomo
∗ Barbieri ∗
Hussein Carlos
Hussein David
David
Carlos Eduardo
Tafur
Tafur
Eduardo ∗
Pereira
Giacomo
Giacomo
Pereira Barbieri
Barbieri ∗∗∗
∗∗
∗∗
Hussein Carlos
Hussein David
David
Carlos Eduardo Eduardo
Tafur
Tafur ∗
Eduardo Pereira Pereira
Giacomo
Giacomo
Pereira ∗∗ Barbieri
∗∗
Barbieri
∗∗
Carlos
∗
∗ Department of Mechanical
Carlos Eduardo
Carlos Eduardo
Engineering, Pereira ∗∗
Pereira
∗
∗ Department of
Department of Mechanical Engineering, Universidad
Mechanical Engineering, Universidad de
Universidad de los
de los Andes,
los Andes,
Andes,
Bogotá,
∗ Department
Department
Bogotá,
∗
Colombia
Colombia of (e.mail:
Mechanical
of Mechanical
(e.mail: {hd.tafur10,g.barbieri}@uniandes.edu.co)
Engineering,
Engineering, Universidad de los
Universidad
{hd.tafur10,g.barbieri}@uniandes.edu.co) de los Andes,
Andes,
Bogotá,
∗∗∗Department
DepartmentColombia of (e.mail:
Mechanical
of Federal
Mechanical {hd.tafur10,g.barbieri}@uniandes.edu.co)
Engineering,
Engineering, Universidad
Universidad de
de los Andes,
los Andes,
∗∗ Universidade
Bogotá,
Bogotá,
∗∗ Colombia
Colombia
Universidade (e.mail:
(e.mail:
Federal do
do Rio
Rio Grande
Grande do
do Sul,
Sul, Porto
{hd.tafur10,g.barbieri}@uniandes.edu.co)
{hd.tafur10,g.barbieri}@uniandes.edu.co)
Porto Alegre,
Alegre, Brazil
Brazil
∗∗ Universidade
Bogotá,
Bogotá, ColombiaFederal
Colombia (e.mail:
(e.mail:
(e.mail:do Rio Grande do Sul, Porto
{hd.tafur10,g.barbieri}@uniandes.edu.co)
{hd.tafur10,g.barbieri}@uniandes.edu.co)
cpereira@ufrgs.br) Alegre, Brazil
∗∗
∗∗
Universidade
Universidade Federal
Federal
(e.mail:do
do Rio
Rio Grande
Grande
cpereira@ufrgs.br)do
do Sul,
Sul, Porto
Porto Alegre,
Alegre, Brazil
Brazil
∗∗ Universidade Federal
Universidade (e.mail:
Federal do
do cpereira@ufrgs.br)
Rio
Rio Grande
Grande
(e.mail: cpereira@ufrgs.br)
cpereira@ufrgs.br)do
do Sul,
Sul, Porto
Porto Alegre,
Alegre, Brazil
Brazil
(e.mail:
(e.mail:
(e.mail: cpereira@ufrgs.br)
cpereira@ufrgs.br)
Abstract:
Abstract: In
In automation
automation systems,
systems, a
aa high
high number
number of
of faults
faults is
is induced
induced by
by hardware
hardware failures.
failures.
Abstract:
Their
Abstract: control In
In automation
software
automation can systems,
be utilized
systems, a high
to
high number
mitigate
number thisof
of faults
problem
faults is
by
is induced
making
induced by
it
by hardware
detect
hardware and failures.
manage
failures.
Abstract:
Their
Their control
control In automation
software
software can
can systems,
be
be utilized
utilized a high
to
to number
mitigate
mitigate this
thisof faults
problem
problem is
by
by induced
making
making by
it
it hardware
detect
detect and
and failures.
manage
manage
Abstract:
Abstract:
the
Their different
control In
In automation
automation
failure
software events
can systems,
systems,
bethat may
utilized a
a high
high
occur
to number
number
in
mitigate thethisof
of faults
faults
system.
problem is
is
However,
by induced
induced
making by
by
control
it hardware
hardware
software
detect and failures.
failures.
design
manage
Their
the
the control
different
different software
failure
failure can
events
events be utilized
that
that may
may to mitigate
occur
occur in
in the
thethis problem
system.
system. by
However,
However, making it
control
control detect and
software
software manage
design
design
Their
Their control
control
methodologies
the different software
software
have
failure can
can
mainly
events be
be utilized
utilized
focused
that may on to
to mitigate
mitigate
the
occur system
in thethis
this problem
problem
nominal
system. by
by
behavior,
However, making
making it
it
control detect
detect
marginally and
and
consider
software manage
manage the
design
the different
methodologies
methodologies failure
have
have events
mainly
mainly that
focused
focused may on
on occur
the
the in
system
system the system.
nominal
nominal However,
behavior,
behavior, control
marginally
marginally software
consider
consider design
the
the
the
the different
different
generation
methodologies of failure
failure
software
have events
events
reliable
mainly that
that to
focused may
may
hardware
on occur
occur
the in
in the
the
failures.
system system.
system.
In
nominalresponse However,
However,
behavior, to thiscontrol
control software
software
challenge,
marginally this
consider design
design
paper
the
methodologies
generation
generation of
of have
software
software mainly
reliable
reliable focused
to
to on
hardware
hardware the system
failures.
failures. nominal
In
In response
response behavior, to
to marginally
this
this challenge,
challenge, consider
this
this the
paper
paper
methodologies
methodologies
presents
generation a have mainly
have
methodology
of software mainly for
reliable focused
focused
the on the
on
development
to hardware the system
system
of nominal
nominal
reliable
failures. In behavior,
behavior,
automation
response to marginally
marginally
systems
this which
challenge, consider
consider
integrates
this the
the
paper
generation
presents
presents a
a of software
methodology
methodology reliable
for
for the
the to hardware
development
development failures.
of
of In
reliable
reliable response
automation
automation to this
systems
systemschallenge,
which
which this paper
integrates
integrates
generation
generation
the following
presents a of
of software
software
tools:
methodology (i) reliable
reliable
Failure
for to
to
Mode
the hardware
hardware
and
development Effect failures.
failures.
Analysis
of In
In
reliable response
response
(FMEA):
automation to
to
to this
this
identify
systemschallenge,
challenge,
the this
this
different
which paper
paper
failure
integrates
presents
the
the a methodology
following
following tools:
tools: (i)
(i) for the
Failure
Failure Mode
Modedevelopment
and
and Effect
Effect of reliable(FMEA):
Analysis
Analysis automation
(FMEA): to
to systems
identify
identify the
the which
different
differentintegrates
failure
failure
presents
presents
modes,
the a
a methodology
and
following methodology
the strategies
tools: (i) for
forfor
Failure the
the development
development
their
Mode detection
and Effect of
of
and reliable
reliable
management;
Analysis automation
automation
(FMEA): (ii)
to systems
systems
AutomationML:
identify the which
which
differentintegrates
integrates
to model
failure
the
modes,
modes, following
and
and tools:
the
the (i) Failure
strategies
strategies for
for Mode
their
their and Effect
detection
detection Analysis
and
and (FMEA):
management;
management; to
(ii)
(ii) identify the
AutomationML:
AutomationML: different to
to failure
model
model
the
the
modes, following
following
hierarchy
and tools:
tools:
theand (i)
(i) Failure
Failure
interfaces
strategies for Mode
Mode
of and
and
automation
their Effect
Effect
detection Analysis
Analysis
system’s
and (FMEA):
(FMEA):
components;
management; to
to
(ii) identify
identify
(iii) Virtual the
the
AutomationML: different
different
Commissioning
to failure
failure
model
modes,
the
the and
hierarchy
hierarchy theand
andstrategies
interfaces
interfaces for of
oftheir detection
automation
automation and
system’s
system’s management;
components;
components; (ii) AutomationML:
(iii)
(iii) Virtual
Virtual to
Commissioning
Commissioning model
modes,
modes,
and
the Faultand
and
hierarchy the
the
Injection:
andstrategies
strategies
to assess
interfaces for–oftheir
for their
before detection
detection
automation system and management;
and
deployment
system’s management;
–
components;the (ii)(iii)
(ii)
reliability AutomationML:
AutomationML:
of
Virtualthe control to
to model
model
software
Commissioning
the
and
and hierarchy
Fault
Fault and
Injection:
Injection: interfaces
to
to assess
assess of
–
– automation
before
before system
system system’s
deployment
deployment components;
– the
–– the (iii)
reliability
reliability Virtual
of
of the
the Commissioning
control
control software
software
the
the
in
and thehierarchy
hierarchy
presence
Fault and
and
of
Injection: interfaces
interfaces
hardware
to assess of
of automation
automation
failures.
– before Through
system system’s
system’s
its components;
components;
application
deployment the to a (iii)
(iii)
case
reliability Virtual
Virtual
study,
of it
the Commissioning
Commissioning
is demonstrated
control software
and
in
in the
theFault Injection:
presence
presence of
of to assessfailures.
hardware
hardware – beforeThroughsystem deployment
its application – the to reliability
aa case of the
study, it control
is software
demonstrated
and
and
that
in
in
that the
the
Fault
Fault
the Injection:
Injection:
methodology
presence
presence
the methodology of
of
to
hardware
hardwareassessfailures.
assess
to enables
enables
– before
–the
before
failures.
failures.
the
Through
system
identification
Through
Through
identification
its
system deployment
its
itsof
application
deployment
of failure
application
application
failure
––modes,
the
the
modes,
to
to
to
case
reliability
reliability
aa the
case
case
the
study,
of
of the
elicitation
study,
study,
elicitation
it
the
it
it
is
of
is
is
of
demonstrated
control
control software
software
requirements
demonstrated
demonstrated
requirements
that
in
in
for
that the
the the
their
the methodology
presence
presence
detection
methodology of
of and enables
hardware
hardware the
failures.
failures.
management,
enables the identification
Through
Through
and
identification the its
itsof
of failure
application
application
generation
failure modes,
of
modes,to
to a
a the
case
case
control
the elicitation
study,
study,
software
elicitation it
it of
is
is requirements
demonstrated
demonstrated
reliable
of requirementsto the
that
for the methodology enables the identification of failure modes, the elicitation of requirements
thattheir
for
that their detection
detection
the methodology
the
identified
for their methodology
failure
detection
and
and
modes.
and
management,
management,
enables
enables
and
and
the identification
the identification the
the generation
generation
of
of failure modes,
failure
of
of
modes, control
control software
software
the elicitation
the elicitation reliable
reliable
of
of requirements
requirements
to
to the
the
for their detection
identified
identified failure
failure and management, and the generation of control software reliable to the
modes.
modes.
management, and the generation of control software reliable to the
for
for their detection
their detection
identified failure and management,
and management,
modes. and the
and access generation
the generation of control
ofthecontrol software
softwarelicense reliable
reliable to the
to the
Copyright
identified
identified © 2021
failure
failure The
modes.
modes. Authors. This is an open article under CC BY-NC-ND
identified
Keywords: failure
FMEA,
(http://creativecommons.org/modes.
AutomationML,licenses/by-nc-nd/4.0)
Control Software, Hardware Failure, Virtual
Keywords:
Keywords: FMEA,
FMEA, AutomationML,
AutomationML, Control
Control Software,
Software, Hardware
Hardware Failure, Failure, Virtual
Virtual
Commissioning,
Keywords:
Keywords:
Commissioning, FMEA,
FMEA, Fault
Fault Injection.
AutomationML,
AutomationML,
Injection. Control
Control Software,
Software, Hardware
Hardware Failure, Failure, Virtual
Virtual
Commissioning,
Keywords:
Keywords:
Commissioning, FMEA,
FMEA, Fault Injection.
AutomationML,
AutomationML, Control
Control Software,
Software, Hardware
Hardware Failure,
Failure, Virtual
Virtual
Commissioning, Fault Fault Injection.
Injection.
Commissioning,
Commissioning, Fault
Fault Injection.
Injection.
1.
1. INTRODUCTION
INTRODUCTION ior
ior of
of the
the control
control software
software in
in response
response to
to hardware
hardware failures
failures
1.
1. INTRODUCTION
INTRODUCTION ior
ior of
(Rösch
of the
theand control
control software
Vogel-Heuser,
software in
in response
2017). With
response to
the
to hardware
goal
hardware of failures
bridging
failures
1. INTRODUCTION ior of
(Rösch
(Rösch theand
and control software
Vogel-Heuser,
Vogel-Heuser, in response
2017).
2017). With
With to
the
thehardware
goal
goal of
of failures
bridging
bridging
In today’s automation 1.
1. INTRODUCTION
INTRODUCTION
systems, an increasing number of ior
ior
this of
of the
the
gap,
(Rösch and control
control
this paper software
software
Vogel-Heuser, proposes in
in aresponse
response
2017). methodology
With to
to
thehardware
hardware
that
goal of failures
failures
combines
bridging
In
In today’s
today’s automation
automation systems,
systems, an
an increasing
increasing number
number of
of (Rösch
this
this gap,
gap, and this
this Vogel-Heuser,
paper
paper proposes
proposes 2017). With
aa methodology
methodology the goal
that
that of bridging
combines
combines
functionalities
In today’s is
automation
In today’s automation being shifted
systems,
systems, from
an pure
increasing
an increasing mechanics
number
numberand and
of
of athis (Rösch
a(Rösch
hardware
this gap, and
and this Vogel-Heuser,
Vogel-Heuser,
failure
paper analysis
proposes 2017).
2017). With
With
process,
a methodologya the
the goal
goal
modeling
that of
of bridging
bridging
tool
combines tai-
functionalities
functionalities
In today’s is being
is
automation being systems,
shifted from
shifted from
an pure mechanics
pure
increasing mechanics
number and
of athis gap, thisfailure
hardware
hardware paper proposes
failure analysis
analysis a methodology
process,
process, aa modelingthat combines
modeling tool
tool tai-
tai-
In today’s
electronics
functionalities
functionalitiesautomation
into is
issoftware.
being
being systems,
In
shifted
shifted an
particular,
from
from increasing
pure
pure the number
control
mechanics
mechanics of
soft-
and
and this
lored
a gap,
gap,
for
hardware this
this paper
paper
automation
failure proposes
proposes
systems,
analysis aa methodology
methodology
and
process, a a that
that
verification
modeling combines
combines
method
tool tai-
electronics
electronics
functionalitiesinto
into issoftware.
software.
being In
In
shifted particular,
particular,
from pure the
the control
control
mechanics soft-
soft-
and a hardware
lored
lored for
for failure
automation
automation analysis
systems,
systems, process,
and
and a
a a modeling
verification
verification tool
method
method tai-
functionalities
ware is
electronics
electronicsbeing
into
into is being
enhanced
software.
software. shifted
with
In
In from
particular,
particular, pure
functionalities the
themechanics
for
control
control handlingand
soft-
soft- aa hardware
hardware
consisting
lored for of failure
failure
virtual
automation analysis
analysis
commissioning
systems, process,
process,
and and
a aa modeling
modeling
fault
verification tool
tool
injection.method tai-
tai-
ware is
ware is being
being enhanced with functionalities for handling
handling lored for
consisting automation
of systems,
virtual commissioning and a
and verification
fault injection.method
electronics
electronics
failures
ware
ware is
is
failures in intoenhanced
into
hardware
being
being
in
software.
software.
enhanced
enhanced
hardware
with
In
components.
with
with
components.
functionalities
In particular,
particular,
For
functionalities
functionalities
For
the
instance,
instance,
for
the control
control
for
for Kormannsoft-
soft- lored
handling
handling
Kormann
consisting
lored for
consisting
consisting
of
of virtual
for automation virtual commissioning
automation
of virtual
systems,
systems, and
commissioning
commissioning and andand
and
fault
fault injection.
aa verification
verification
fault injection.
injection.
method
method
failures
ware
ware is in
is beinghardware
being enhanced
enhanced components.
with
with For instance,
functionalities
functionalities for Kormann
handling Since
consistingthis work
of virtual deals with
commissioning hardware andfailures,
and fault a
aa process
fault injection.
and
and
Vogel-Heuser
failures
failures
and in
in hardware
hardware
Vogel-Heuser
Vogel-Heuser
failures in hardware
(2011)
(2011)
(2011)
adopted
components.
components.
adopted
adopted
components.
it
For
For
it
it
For
to detect for
detect
instance,
instance,
to instance,
to detect
and handling
manage Since
manage
Kormann
Kormann
andKormann
and manage Since
must
Since
Since
this
consisting
this
be
this
this
work
of
selected
virtual
work
work
work
deals
deals
for
deals
deals their
with
commissioning
with
with
with
hardware
hardware
identification
hardware
hardware
failures,
failures,
and for
failures,
failures,
injection.
the
process
process
defini-
aa process
process
failures
the
and
and
the in
different hardware
Vogel-Heuser
Vogel-Heuser
different failure
failure (2011)
(2011)components.
events
events that
adopted
adopted
that may
may For
it
it to
to instance,
occur
detect
detect
occur in
in the
and
and
the Kormann
system.
manage
manage
system. must
must
Since be
be
this selected
selected
work for
for
deals their
theirwithidentification
identification
hardware and
and for
for
failures, the
the
a defini-
defini-
process
the
and
and different
Vogel-Heuser
Vogel-Heuserfailure events
(2011)
(2011) that
adopted
adopted mayit
it to
tooccur
detect
detect in the
and
and system.
manage
manage Since
tion
must
must
tion of
of this
be
be work
strategies
selected
selected
strategies deals
for
for
for
for their
their
their
theirwith hardware
management.
identification
identification
management. failures,
Failure
and
and for
for
Failure the
thea
Mode
Mode process
and
defini-
defini-
and
the different
the different failure
failure events
events that that may
may occuroccur in in the
the system.
system. tion
must ofbe strategies
selected for
for their
their management.
identification Failure
and for Mode
the and
defini-
Concerning
the different
Concerning
the different the
the development
failure events
development
failure events of
that
of
that control
may
control
may occur
occursoftware,
in
software,
in the
the different
system.
different
system. must
Effect
tion
tion
Effect of
ofbe selected
Analysis
strategies
strategies
Analysis for
(FMEA)
for
for
(FMEA) their
their
their identification
is the
management.
management.
is the process
process and
of for
Failure
of the
reviewing
Failure Mode
Mode
reviewing defini-
the
and
and
the
Concerning
approaches
Concerning the
have
the development
been
developmentproposed of
of control
spacing
control software,
from
software, modelsdifferent
for
different Effect
tion
tion of
of Analysis
maintainablestrategies
strategies items (FMEA)
for
foroftheir
their
a is the
management.
management.
physical process
asset to of reviewing
Failure
Failure
identify Mode
Modepotentialthe
and
and
Concerning
approaches the
have development
been proposed of control
spacing software,
from modelsdifferent
for Effect
Effect Analysis
Analysis
maintainable items (FMEA)
(FMEA)
of a is
is
physicalthe
the process
process
asset to of
of reviewing
reviewing
identify potentialthe
the
approaches
Concerning
Concerning
abstracting
approaches have
the
the
its
have been
development
development
behavior
been proposed of
of
towards
proposed spacing
control
control
design
spacing from
software,
software,
pattern
from models
models for
different
different
for the
for maintainable
Effect
Effect
failure Analysis
Analysis
modes, items
and of
(FMEA)
(FMEA)
theira physical
is
is
causes the
the andasset
process
process
effectsto identify
of
of reviewing
reviewing
(Carlson, potentialthe
the
2012).
approaches
abstracting havehave been
its behavior
behavior proposed spacing
towardsspacingdesign from from
patternmodels for
for the
the maintainable
maintainable
failure modes, items
items
and of
of
theira
a physical
physical
causes andasset
asset
effectsto
to identify
identify
(Carlson, potential
potential
2012).
abstracting
approaches
approaches
deployment
abstracting its
have
(Jack,
its been
been
2010).
behavior towards
proposed
proposed
Control
towards design
spacing
software
design pattern
from
design
patternmodels
models for
method-
for for
for
the failure modes,
maintainable
maintainable
Within this and
items
items
paper, their
of
of a
a
FMEA causes
physical
physical
is and effects
asset
asset
selected to
to
as (Carlson,
identify
identify
hardware 2012).
potential
potential
failure
abstracting (Jack,
deployment its behavior
(Jack, towards software
2010). Control
Control design pattern
software design method-for the Within
method- failure
failure modes,
modes,
this and
and their
paper, their
FMEA causes
causesis and effects
and effects
selected as (Carlson,
(Carlson, failure
hardware 2012).
2012).
deployment 2010). design Within this paper, FMEA is
abstracting
abstracting
ologies
deployment
deployment
ologies have
have
its
its
mainly
(Jack,
(Jack,
mainly
behavior
behavior
focused
2010).
2010).
focused
towards
towards
on
Control
Control
on the
the
design
design
software
software
software
software
pattern
pattern
as
design
design
as a
a
for
for the
mean the
method-
method-
mean to
to
failure
Withinmodes,
failure
analysis
Within
analysis modes,
this
thisprocess and
andand
paper,
paper,
process
their
their
andFMEA
FMEA
causes
causes
is
is is selected
adopted
is
and
and effects
selected
selected
adopted effects
to
to
as hardware
(Carlson,
(Carlson,
elicit
as
as requirements
hardware
hardware
elicit requirements
failure
2012).
2012).
failure
failure
ologies
deployment
deployment
satisfy
ologies have
the
have mainly
(Jack,
(Jack,
functional
mainly focused
2010).
2010).
focused on
Control
Control
requirementson the
the software
software
software
ofsoftware as
design
design
automation as aa systems;
mean
method-
method-
mean to
to analysis
Within
Within
based on this
thisprocess
the paper,
paper, and
recommended FMEA
FMEA is adopted
is
is selected
selected
actions toto elicit
as
as requirements
hardware
hardware
detect failures failure
failure
and
ologies have
satisfy the
the mainly
functional focused
requirementson the software
ofsoftware
automation as a mean
systems; to analysis
analysis
based on process
process
the and
and
recommended is
is adopted
adopted
actions to
toto elicit
elicit
detect requirements
requirements
failures and
satisfy
ologies
ologies
see
satisfy have
have
(Bonfe
the functional
andmainly
mainly
functional requirements
focused
focused
Fantuzzi, 2001;
requirementson
on the
the of
of automation
software
Barbieri, as
2016).
automation systems;
as aaWhereas,
mean
mean to
systems; based
to analysis
analysis
mitigate on the
process
process
/ recommended
eliminate and
and is
is
their actions
adopted
adopted
effects. to
toto detect
elicit
elicit failures
requirements
requirements and
satisfy
see the
(Bonfe functional
and Fantuzzi,requirements
2001; of
Barbieri, automation
2016). systems;
Whereas, based
based
mitigate on
on /the
the recommended
recommended
eliminate their actions
actions
effects. to
to detect
detect failures
failures and
and
see
the
see (Bonfe
satisfy
satisfy the
the
(Bonfe and Fantuzzi,
functional
functional
literatureand lacks of
Fantuzzi, 2001;
requirements
requirements
approaches
2001; Barbieri,
of
of
Barbieri, 2016).
automation
automation
concerning 2016).the Whereas,
systems;
systems;
develop-
Whereas, mitigate
based
based on
on / eliminate
the
the recommended
recommended their effects.
actions
actions to
to detect
detect failures
failures and
and
see
the (Bonfe
literatureand Fantuzzi,
lacks of 2001;
approaches Barbieri,
concerning 2016).the Whereas,
develop- mitigate
mitigate /
/ eliminate
eliminate their
their effects.
effects.
the
see
see
ment
the literature
(Bonfe
(Bonfe
of and
and lacks
functionalities
literature lacks of
Fantuzzi,
Fantuzzi,
of approaches
for 2001;
2001;
the
approaches concerning
Barbieri,
Barbieri,
detection
concerning 2016).
2016).
and the
the develop-
Whereas,
Whereas,
management
develop- With
mitigate
With
mitigate the
the /
/ goal
eliminate
goal
eliminate to
to gather
their
gather
their and
effects.
and
effects. sort
sort out
out the
the information
information
the literature
ment
ment of lacks of approaches
of functionalities
functionalities for the
for concerning
the detection
detection the develop- needed
and management
and management With
With the the for goal
the
goal to gather
toFMEA and
and sort
gatheranalysis, sortit out
out is the information
fundamental
the information to
the
the
of literature
literature
hardware
ment lacks
lacks of
failures
of functionalities
functionalities approaches
of(Vogel-Heuser
approaches
for the concerning
concerning
the detection et
detection al., the
the develop-
2015).
and develop- With
management With
needed the for goal
the to gather
FMEA and
analysis, sort it out is the information
fundamental to
ment
of
of of
hardware
hardware failures
failures for
(Vogel-Heuser
(Vogel-Heuser et
et al.,
al., and management
2015).
2015). needed
With
represent
needed the
the for
for the
goal
goal
all the
the to
toFMEA
gather
gather
different
FMEA analysis,
and
and
views
analysis, sort
sort
of it
the
it out
out is
is fundamental
the
the
automation information
information
fundamental system to
to
ment
ment
of of
of
hardwarefunctionalities
functionalities
failures for
for the
the
(Vogel-Heuser detection
detection
et al., and
and management
management
2015). needed
represent for
all the
the FMEA
different analysis,
views of it
the is fundamental
automation system to
of
Onehardware
of the failures
reasons for(Vogel-Heuser
this is the et
complexity al., 2015).
of the problem. represent
needed
needed
and their
represent all
for
for the
the
the different
FMEA
FMEA
interrelationships.
all the different views
analysis,
analysis,
viewsFor of
of the
it
it
instance,
the automation
is
is fundamental
fundamental
it
automation is system
estimated
system to
to
of
Onehardware
of the
of hardware
One of failures
the reasons
reasons
failures for(Vogel-Heuser
for(Vogel-Heuser
this is
this is the et
the complexity
complexity al., 2015).
of the
et al., 2015).
of the problem.
problem. represent represent
and their all the different views
interrelationships. For ofinstance,
the automation it is system
estimated
In
One fact,
of the
the inclusion
reasons for of
this functionalities
is the complexity for ofthe
the detection
problem. and
that
and their
represent
about
their interrelationships.
all
all50%the
the different
different
of the
interrelationships. total views
viewsFor of
of
failures
For instance,
the
the
of
instance, it
automation
automation
automation
it is
is estimated
system
system
systems
estimated
One
In of
In fact,
fact,the reasons
thereasons
the inclusion
inclusionfor this is the complexity
of functionalities
of functionalities of the
forofthe
for the problem.
detection
detection and
that their
about interrelationships.
50% of the total For
failures instance,
of it
automation is estimated
systems
One of
Onefact,
of the
the for this is
is the complexity the problem. that
and about
that their 50% of
of the
the total
interrelationships. failures
For of
of automation
For instance, it
it is systems
estimated
and
In
In
and
and fact, thereasons
management
the
management
management
inclusion
inclusionforhardware
of
of
of
this
of thefailures
complexity
of functionalities
functionalities
hardware
hardware failures
failures forofthe
within
for
within
within
the
the the
the
the
problem.
control
detection
detection
control that
control
and
occur
that
occur their
in
about
about
in interrelationships.
the
50%interfaces
50%
the of the
interfaces total
totalbetween
failures
failures
between instance,
hardware
of automation
automation
hardware is estimated
components
componentssystems
systems
In
In
and fact,
fact,
software the
the
management inclusion
inclusion
requires: (i)
of anof
of functionalities
functionalities
interdisciplinary
hardware failures for
for the
the
approach
within the detection
detection
due
controlto occur
that in
about
about
(Carlson,
occur in the
50%
50%
2012).
the interfaces
of
of the
the total
total
AutomationML
interfaces between
failures
failures
between hardware
of
of
(AML) automation
automation
hardware is components
a systems
systems
modeling
components
and management
software
software requires:
requires: of
(i)
(i) hardware
an
an failures
interdisciplinary
interdisciplinary within
approach
approachthe control
due
due to
to occur
(Carlson, in the
2012). interfaces
AutomationMLbetween hardware
(AML) is components
a modeling
and
and
the management
management
intrinsic
software nature
requires: of
of
(i) hardware
hardware
ofan the failures
failures
problem
interdisciplinary that within
within
merges
approachthe
the control
control
hardware
due to (Carlson,
occur
occur
language
(Carlson, in
in 2012).
the
the
that
2012). AutomationML
interfaces
interfaces
provides a
AutomationMLbetween
between (AML)
hierarchicalhardware
hardware
(AML) is aa modeling
components
components
representation
is modeling of
software
the requires:
the intrinsic
intrinsic nature
nature (i) an
ofanthe
of interdisciplinary
the problem that
problem approach
that merges
merges due
hardware
hardware to (Carlson,
language 2012).provides
that AutomationML
aa hierarchical (AML) is a modeling
representation of
software
software
and
the requires:
requires:
software
intrinsic nature (i)
(i)
components,ofan interdisciplinary
interdisciplinary
the including
problem approach
approach
electrical,
that merges due
due
mechanical
hardware to
to language
(Carlson,
(Carlson,
automation
language that
2012).
2012).
that provides
systems, AutomationML
AutomationML
provides integrating
a hierarchical
(AML)
(AML)
mechanical,
hierarchical representation
is
is aa modeling
modeling
electrical
representation of
and
of
the
and
and intrinsic
software
software nature
components,
components,of the problem
including
including that merges
electrical,
electrical, hardware
mechanical
mechanical language
automation that provides
systems, a
integrating hierarchical
mechanical, representation
electrical of
and
the
the
and intrinsic
intrinsic
pneumatic
software nature
nature
devices
components,of
of the
the
among problem
problem
others
including that
that merges
merges
(Vogel-Heuser
electrical, hardware
hardware
mechanicalet al., automation
language
language
software
automation that
thatsystems,
views, provides
provides
systems, and integrating
their aa mechanical,
hierarchical
hierarchical
interrelationships
integrating mechanical, electrical
representation
representation
(Drath
electrical et and
of
of
al.,
and
and
and software
pneumatic
pneumatic components,
devices
devices among
among including
others
others electrical,
(Vogel-Heuser
(Vogel-Heuser mechanicalet
et al.,
al., automation
software systems,
views, and integrating
their mechanical,
interrelationships electrical
(Drath et and
al.,
and
2020);software
software
(ii) components,
components,
verification
pneumatic devices including
including
techniques
among othersable electrical,
electrical,
to check
(Vogel-Heuser mechanical
mechanical
the behav-
et al., software
automation
automation
software views,
systems,
systems,
views, and
and their interrelationships
integrating
integrating
their mechanical,
mechanical,
interrelationships (Drath
electrical
electrical
(Drath et
et al.,
and
and
al.,
and pneumatic
2020);
2020); (ii) devicestechniques
(ii) verification
verification among others
techniques (Vogel-Heuser
able(Vogel-Heuser
able to check
to check the et al., software views, and their interrelationships (Drath et al.,
the behav-
behav-
and
and
2020);pneumatic
pneumatic devices among
among others
devicestechniques
(ii) verification
verification techniques othersable(Vogel-Heuser
to check
check the et
et al.,
the behav- al., software
behav- software views, views, and and their
their interrelationships
interrelationships (Drath (Drath et et al.,
al.,
2020); (ii) able to
2020); (ii) verification techniques able to check the behav-
2405-8963 Copyright © 2021 The Authors. This is an open access article under the CC BY-NC-ND license.
2020); (ii) verification techniques able to check the behav-
Peer review under responsibility of International Federation of Automatic Control.
10.1016/j.ifacol.2021.08.047
 Hussein David Tafur et al. / IFAC PapersOnLine 54-1 (2021) 420–425
2008). Due to these features, AML is applied within this
work as a tool to support the execution of the FMEA
analysis.
Finally, a strategy must be utilized to verify the behavior
of the control software in response to hardware failures.
The integration of virtual commissioning and fault injec-
tion is applied in this paper to assess the behavior of
the control software once the detection and management
functionalities have been included. Virtual Commissioning
(VC) is a verification strategy performed by interfacing
a discrete-event behavior model of the physical plant to
the hardware or emulated controller which contains the
control software to be validated (Lee and Park, 2014).
Whereas, Fault Injection consists in the system verification
by forcefully making it enter failure states (Svenningsson
et al., 2011). By injecting faults and analyzing the system
reaction through the VC simulation, the reliability of the
control software to hardware failures can be verified (Orive
et al., 2019). For reliable, we mean a control software
able to detect hardware failures, and able to mitigate or
eliminate the effects of the detected failures.
In the literature, few works propose the utilization of
tools applied within this paper to perform some of the
activities involved in the development of reliable automa-
tion systems. For instance, modeling languages have been
used to support the FMEA analysis (David et al., 2010;
Scippacercola et al., 2015), the integration of simulation
and fault injection has been adopted to check the relia-
bility of control software to hardware failures (Rösch and
Vogel-Heuser, 2017; Orive et al., 2019), etc. However, the
FMEA-based methodology proposed in this work consti-
tutes a complete approach to the problem since specifies all
the different phases involved in the generation of control
software reliable to hardware failures, starting from the
definition of the necessary information towards the code
deployment.
Given the above, the paper is structured as follow: sec-
tion 2 illustrates the proposed FMEA-based methodology
and section 3 applies it to a case study. Obtained results
are discussed in section 4 and finally, section 5 presents
the conclusions and sets the directions for future work.
2. FMEA-BASED METHODOLOGY
The methodology for the development of control software
reliable to hardware failures is depicted in Figure 1.
The methodology is meant to be applied to an already
designed / operating automation system in which the
control software must be enhanced with functionalities for
the detection and management of hardware failures.
2.1 Information gathering
The objective of this phase is to gather all the informa-
tion necessary for the FMEA analysis and for the subse-
quent system modifications. When this operation is imple-
mented, it must be considered that (Kernschmidt et al.,
2018): (i) systems are composed as assemblies of com-
ponents; (ii) components have properties and interfaces;
(iii) components of automation systems are characterized
with mechanical, electrical and software views. Therefore,
421
Fig. 1. Phases for the development of control software
reliable to hardware failures.
the following subdivision is proposed for the information
gathering:
• Component: (i) mechanical view: mechanical proper-
ties (e.g. dimensions, material, etc.) and mechanical
interface (e.g. screws, pipes, etc.); (ii) electrical view:
electrical interface (e.g. DC, AC, etc.): (iii) software
view: software interface (e.g. digital, analog, etc.);
• System: (i) process view: P&ID diagram to indicate
how the components interact for the implementation
of the automated process; bill of materials to ob-
tain the list of components utilized within the sys-
tem; requirement list to detail the information con-
cerning the system operation; (ii) mechanical view:
CAD models to represent the spatial configuration
of the components and how they are interfaced; (iii)
electrical view: electrical drawings to indicate how
the automated components are electrically assembled
and supplied; (iv) software view: control code and
eventual models that abstract it (e.g. state machine
diagrams, etc.) to identify the implemented control
logic and the interface variables.
2.2 AutomationML model
Once the information has been gathered, it must be inte-
grated and organized to generate a complete representation
of the system. This representation will be utilized for the
implementation of the FMEA analysis. AutomationML
enables the modeling of (Wimmer, 2018): (i) Components
with their properties and interfaces; (ii) Systems: hierar-
chical view showing the constituting components and how
they are interfaced both from a mechanical, electrical and
software perspective. Therefore, the information gathered
in section 2.1 is sorted out within this phase through the
implementation of an AML model.
2.3 FMEA analysis
The FMEA process is generally utilized for identifying
potential failure modes of maintainable items, and their
causes and effects (Carlson, 2012). Whereas, the FMEA
analysis proposed in this phase is mainly focused in defin-
ing: (i) Failure modes: the specific manner by which a
failure occurs in the hardware of the system; (ii) Effects:
the effects and severity of the identified failure modes;
(iii) Actions: actions to mitigate or eliminate the failure
effects. In fact, the information obtained from this analysis
will be utilized to define strategies for the detection and
422 Hussein David Tafur et al. / IFAC PapersOnLine 54-1 (2021) 420–425
management of failures modes, and not to identify their
causes and possible solutions to them – as in traditional
FMEA processes.
The information within the AML model constitutes the ba-
sis for the implementation of the FMEA analysis. In fact,
the AML model represents the interrelationships between
the different views of the system components – mechanical,
electrical and software – enabling the quantification of
the effects of the identified failure modes. Furthermore,
properties can be associated to components facilitating the
identification of abnormal behaviors.
2.4 FMEA synthesis
This phase synthesizes the information generated with
the FMEA analysis to define software strategies for de-
tecting and managing the failure modes of the inspected
hardware components. Figure 2 illustrates the operations
implemented within this phase and their relationship with
the FMEA analysis. These operations can be described
with the following sequential steps: (i) Failure Mode Set:
since different failure modes may be detected with the
same method, this step consists in grouping failure modes
based on the detection method; (ii) Detection method :
starting from the generated effects, detection methods
are defined by comparing the nominal and exceptional
behavior of selected control variables. When performing
this operation, it must be considered that the nominal
behavior is dependent from the system operational con-
dition; (iii) Management strategy: based on the severity of
the generated effects, a strategy to mitigate or eliminate
the effects of the considered failure modes is identified; e.g.
alarm / warning activation, switch off of actuators, etc.
Fig. 2. Representation of the relationship between the
FMEA analysis and the operations implemented
within the FMEA synthesis. The following nomen-
clature is utilized: HW stands for hardware, FM for
failure mode, D for detection method, and A for
alarm.
2.5 Requirement elicitation
The results obtained in the previous phase are converted
into requirements for the detection and management of
hardware failures through the control software. For in-
stance, it can be defined that the system must be able
to monitor selected control variables and to implement
specific actions based on the values acquired from the
control variables. Different strategies can be utilized to
formally specify the requirements (Fantechi et al., 1994);
e.g. temporal logic, etc.
2.6 System modification
In this phase, the identified requirements must be fulfilled.
Sensors are selected to monitor the necessary control
variables and actuators for the implementation of the ac-
tions defined for the management of the hardware failures.
These sensors and actuators may already be present in the
original system or may be integrated to it. Furthermore,
the control software is modified to include functionalities
for the detection and management of the identified hard-
ware failures by using the defined sensors and actuators.
2.7 Virtual verification
Once the modifications to the original system have been
identified, these must be checked before the deployment.
A virtual environment for the verification of the system
reliability to hardware failures is proposed by integrating
VC and fault injection. Virtual commissioning is imple-
mented by developing a simulation model of the physical
plant described at the level of sensors and actuators, and
by connecting it to the hardware or emulated controller
which contains the control software. Within the VC sim-
ulation, hardware failures are emulated with fault injec-
tion; i.e. hardware defects are simulated during runtime.
By inspecting the VC simulation, the system reaction to
hardware failures is verified.
2.8 Deployment
The control software is deployed once its modifications
and the integration of the additional sensors and actuators
have been verified through the described virtual environ-
ment.
3. CASE STUDY
In this section, the proposed methodology is validated by
applying it to a case study. The selected case study is
the filtration unit of a flexible test-bench for hydroponics
(Barbieri, 2019). The filtration unit is depicted in Figure 3
and contains an inverse osmosis filter for reducing the
water chloride and total suspended solid content. Digital
level sensors are utilized to detect the state of the system,
and a solenoid valve and a pump to respectively input tap
water and provide the necessary pressure to make the filter
properly work. The FMEA-based methodology proposed
in section 2 was applied to integrate functionalities for
the detection and management of hardware failures to the
control software of the system.
3.1 Information gathering
In this phase, the information listed in section 2.1 was
gathered. In particular, the technical specifications of the
components provided information concerning their inter-
faces and the relevant properties for identifying abnor-
mal behaviors. Examples of these properties are operative
 Hussein David Tafur et al. / IFAC PapersOnLine 54-1 (2021) 420–425 423

Fig. 3. P&ID diagram of the utilized water filtration unit.

pressure and flow rate, maximum tolerated current, etc.
Furthermore, the different domain-specific models were
collected; i.e. P&ID diagram, CAD model, electrical draw-
ings and PLC code.

3.2 AutomationML model

The AML model was built in AutomationML Editor 1 . A Fig. 4. AML model: hierarchical representation and inter-
class was generated for each component. In AML, a com- face of the V110 solenoid valve. A software interface
ponent is defined with custom properties and ports (viz. is represented with a blue line, an electrical interface
interfaces). In particular, key properties for the identifica- with a red line, and a mechanical interface with a
tion of abnormal behaviors were associated to the created black line.
components. Then, the components were instantiated to
build the hierarchical representation of the system. Finally,
the components were interfaced both from a mechanical,
electrical and software perspective as shown in Figure 4.
The CAD model, the electrical drawings and the PLC code
respectively provided the information concerning the me-
chanical, electrical and software interfaces of the different
components.

3.3 FMEA analysis

The FMEA process was implemented by following the

phases of preparation, procedure and execution defined Fig. 5. FMEA analysis for the V110 solenoid valve and the
in (Carlson, 2012). Failure modes were identified by indi- L110 level sensor.
vidually inspecting all the system components. Then, the
domain-specific and the AML models were analyzed to de-
fine the effects and to quantify the severity of each failure
mode. Finally, an action was recommended to mitigate
/ eliminate the effects of each failure mode. Part of the
implemented FMEA analysis is represented in Figure 5.

3.4 FMEA synthesis

By analyzing the effects encountered with the FMEA anal-
ysis, a detection method was defined for each failure mode,
and a nominal and exceptional behavior was identified
for its detection. For instance, different failure modes can
be detected based on the time taken to fill a tank as
shown in Figure 6. Then, failure modes that presented the
same detection method were grouped together into failure
mode sets. Finally, a management strategy was defined by
analyzing the severity of the generated effects.
1 https://www.automationml.org/o.red.c/dateien.html?cat=1
Fig. 6. FMEA synthesis for some of the failure modes of
the V110 solenoid valve and the L110 level sensor.
3.5 Requirement elicitation
In this phase, the table generated within the FMEA
synthesis process was converted into requirements. Even
if different formal methods can be utilized to specify
requirements, natural language was utilized since their
formal specification was outside the scope of the paper.
Two requirements were obtained for each failure mode set;
i.e. one for the detection and one for the management. For
424 Hussein David Tafur et al. / IFAC PapersOnLine 54-1 (2021) 420–425
instance, the following requirements were elicited for the
first failure mode set (see Figure 6): (i) Detection: “If L110
sensor is false, A110 alarm must trigger after 30s from
the activation of V110 solenoid valve”; (ii) Management:
“When A110 alarm is triggered, all the actuators must
be switched off, and the operator must inspect the V110
solenoid valve and the L110 level sensor”.
3.6 System modification
Based on the identified requirements, it was not neces-
sary to integrate additional sensors and actuators to the
original system. In fact, most of the failure modes were
detected with timers, and most of the management strate-
gies consisted in switching off all the actuators. Then, the
PLC software was modified to integrate the conditions
for detecting the failure modes, and to implement the
actions identified within the management strategy. Fur-
thermore, the system HMI (Human-Machine Interface)
was enhanced with leds indicating the different alarms
and warnings, and with pop-up windows suggesting to the
operator the components to inspect; see Figure 7.
Fig. 7. Example of failure message implemented within the
HMI. The suggestion of the components to inspect can
be appreciated.
Finally, few failure modes did not generate consequences in
the system functionality – at least in the short term. Some
examples of these not critical effects are noises, vibrations,
etc. In this case, we chose to insert their periodic inspection
within the system maintenance plan, and not to integrate
sensors and software functionalities for their detection.
Therefore, it can be noticed that a ‘side effect’ of the
proposed FMEA-based methodology is the refinement of
the system maintenance plan.
3.7 Virtual verification
In VC, a simulation model of the physical plant described
at the level of sensors and actuators must be built. Con-
sidering that a model constitutes an approximation of the
physical system, the correct abstraction must be identified
to properly reproduce the investigated properties (Lee and
Sirjani, 2018). In the presented methodology, failures are
manually injected through fault injection. Therefore, the
model only needed to replicate the sequence of events
that occur in the physical system; viz. its discrete-event
behaviour. Whereas, the model did not need to perfectly
mimic the continuous-time behaviour of the physical sys-
tem. For instance, it was not necessary to model the chem-
ical reactions that occur during the filtering of chloride.
Since kinematic consists in the description of the motion
without considering the efforts that cause it (Meriam and
Kraige, 2012), a kinematic model was selected.
Given the above, a kinematic model of the filtration unit
was implemented in Simulink 2 . Then, the VC simulation
was performed by interfacing Simulink and CoDeSys Win
Control V3 3 (i.e. the PLC emulated controller) using
the OPC protocol. Interrupters and gauges were inserted
in the Simulink model to inject failures during runtime;
see Figure 8. Finally, the system reaction to the injected
failures was analyzed to evaluate its reliability.
Fig. 8. Kinematic model and fault injection elements for
the failure to open and leakage failure modes of V110
valve.
3.8 Deployment
The deployment of the control software in the PLC of the
physical filtration unit was not included within the scope
of this work and is left as future work.
4. RESULTS AND DISCUSSION
The following results were obtained by applying the pro-
posed FMEA-based methodology to the case study of the
water filtration unit:
• FMEA and AML: by representing all the system in-
terfaces, the AML model facilitated the quantification
of the failure effects and severity, and consequently
the implementation of the FMEA analysis;
• Requirements: by following the FMEA synthesis pro-
cess, the generation of requirements consisted in a
conversion of the FMEA synthesis table into natural
language. After the inclusion of the detection and
management of hardware failures, the total number
of requirements was approximately increased by 40%,
showing the importance of considering these aspects
within the control software;
• Virtual verification: test cases were generated for
evaluating the reliability of the control software to
the hardware failures. The integration of VC and fault
injection enabled the simulation of all the identified
failure modes and the evaluation of the system reac-
tion to them;
• Maintenance Plan: a ‘side effect’ of the methodology
was the refinement of the system maintenance plan by
including the periodic inspection of not critical failure
modes.
Finally, it must be considered that the methodology pro-
vided all these benefits when applied to a simple automa-
tion system. Its scalability to an industrial application
2 https://mathworks.com/products/simulink.html
3 https://www.codesys.com/
 Hussein David Tafur et al. / IFAC PapersOnLine 54-1 (2021) 420–425
should be tested before certifying its ability to generate
control software reliable to hardware failures.
5. CONCLUSION AND FUTURE WORK
Considering the high percentage of faults caused by hard-
ware failures, the inclusion of functionalities for their de-
tection and management within the control software can
bring several benefits in terms of reliability and perfor-
mance of automation systems.
In this context, the objective of this research work was
to explore the role of FMEA, AutomationML, virtual
commissioning and fault injection for the generation of
control software reliable to hardware failures. By integrat-
ing these tools, an FMEA-based methodology was proposed
and applied to a case study of a water filtration unit to be
validated. The methodology resulted promising since its
application enabled the identification of failure modes, the
elicitation of requirements for their detection and manage-
ment, and the generation of a control software reliable to
the identified failure modes.
Notably, the proposed approach constitutes a preliminary
concept that in future should be better refined and vali-
dated. Some future works identified are:
• Trigger failure mode: different failure modes are de-
tected with the same method. The integration of
variables from different sensors should be investigated
for the identification of the failure mode responsible
for the alarm generation;
• Root alarm: in industrial automation, it is common
the scenario in which different alarms trigger after the
occurrence of a certain abnormal behavior. Strategies
for the identification of the root alarm (i.e. the one
related to the root cause) should be included in the
methodology;
• Further validations: the methodology should be de-
ployed to be further validated. Furthermore, it should
be applied to an industrial case study to certify its
ability to generate control software reliable to hard-
ware failures.
REFERENCES
Barbieri, G. (2016). Platform-based design: methodology
refinement and application to cyber-physical production
systems. PhD thesis.
Barbieri, G. (2019). A small-scale flexible test bench for
the investigation of fertigation strategies in soilless cul-
ture. International Journal of Agricultural and Biosys-
tems Engineering, 13(1), 5–9.
Bonfe, M. and Fantuzzi, C. (2001). Object-oriented
approach to plc software design for a manufacture
machinery using iec 61131-3 norm languages. In
2001 IEEE/ASME International Conference on Ad-
vanced Intelligent Mechatronics. Proceedings (Cat. No.
01TH8556), volume 2, 787–792. IEEE.
Carlson, C. (2012). Effective FMEAs: Achieving safe,
reliable, and economical products and processes using
failure mode and effects analysis, volume 1. John Wiley
& Sons.
David, P., Idasiak, V., and Kratz, F. (2010). Reliability
study of complex physical systems using sysml. Relia-
bility Engineering & System Safety, 95(4), 431–450.
425
Drath, R., Luder, A., Peschke, J., and Hundt, L. (2008).
Automationml-the glue for seamless automation engi-
neering. In 2008 IEEE International Conference on
Emerging Technologies and Factory Automation, 616–
623. IEEE.
Fantechi, A., Gnesi, S., Ristori, G., Carenini, M., Vanocchi,
M., and Moreschini, P. (1994). Assisting requirement
formalization by means of natural language translation.
Formal Methods in System Design, 4(3), 243–263.
Jack, H. (2010). Automating manufacturing systems with
PLCs. Lulu. com.
Kernschmidt, K., Feldmann, S., and Vogel-Heuser, B.
(2018). A model-based framework for increasing the
interdisciplinary design of mechatronic production sys-
tems. Journal of Engineering Design, 29(11), 617–643.
Kormann, B. and Vogel-Heuser, B. (2011). Automated
test case generation approach for plc control software
exception handling using fault injection. In IECON
2011-37th Annual Conference of the IEEE Industrial
Electronics Society, 365–372. IEEE.
Lee, C.G. and Park, S.C. (2014). Survey on the virtual
commissioning of manufacturing systems. Journal of
Computational Design and Engineering, 1(3), 213–222.
Lee, E.A. and Sirjani, M. (2018). What good are mod-
els? In International Conference on Formal Aspects of
Component Software, 3–31. Springer.
Meriam, J.L. and Kraige, L.G. (2012). Engineering me-
chanics: dynamics, volume 2. John Wiley & Sons.
Orive, D., Iriondo, N., Burgos, A., Saráchaga, I., Álvarez,
M.L., and Marcos, M. (2019). Fault injection in digital
twin as a means to test the response to process faults at
virtual commissioning. In 2019 24th IEEE International
Conference on Emerging Technologies and Factory Au-
tomation (ETFA), 1230–1234. IEEE.
Rösch, S. and Vogel-Heuser, B. (2017). A light-weight fault
injection approach to test automated production system
plc software in industrial practice. Control Engineering
Practice, 58, 12–23.
Scippacercola, F., Pietrantuono, R., Russo, S., and Silva,
N.P. (2015). Sysml-based and prolog-supported fmea.
In 2015 IEEE international symposium on software
reliability engineering workshops (ISSREW), 174–181.
IEEE.
Svenningsson, R., Eriksson, H., Vinter, J., and Törngren,
M. (2011). Generic fault modelling for fault injection.
In Springer (ed.), Formal methods for components and
objects, 287–296.
Vogel-Heuser, B., Böhm, M., Brodeck, F., Kugler, K.,
Maasen, S., Pantförder, D., Zou, M., Buchholz, J.,
Bauer, H., Brandl, F., et al. (2020). Interdisciplinary
engineering of cyber-physical production systems: high-
lighting the benefits of a combined interdisciplinary
modelling approach on the basis of an industrial case.
Design Science, 6.
Vogel-Heuser, B., Fay, A., Schaefer, I., and Tichy, M.
(2015). Evolution of software in automated production
systems: Challenges and research directions. Journal of
Systems and Software, 110, 54–84.
Wimmer, M. (2018). Multi-level modeling in the wild with
automationml. In Multi Level Modeling Workshop.