ap-6-10.dvi


Acta Polytechnica Vol. 50 No. 6/2010

UML-oriented Risk Analysis in Manufacturing Systems

J.Jirsa, J.Žáček

Abstract

Wheneverwewant to avoid failures or hazardous events in today’s complex technological systems, it is advisable to carry
out appropriate risk management. One of the most important aspects of risk management is the risk analysis process.
The aim of this paper is to show a new risk analysis method based on the Unified Modelling Language (UML), which is
successfully used in software engineering for describing the problem domain. The paper also includes a small practical
example. It also shows a new risk analysis method based on an example of an unreeling process in cable manufacturing.

Keywords: risk analysis, Unified Modelling Language, manufacturing systems.

1 Introduction
Risk analysis and risk control have been very fre-
quently used words in recent years. It seems to
be a modern trend to speak about risk, mainly in
economics or in management of the environment.
However if we focus on our everyday lives, we will
find that there aremany situations when we subcon-
sciously make a risk analysis.
We do not usually recognise particular phases

of our intuitive risk analysis, and we cannot apply
this biological process directly in technical applica-
tions. The reason is very simple: we might omit
some important factorsduring our intuitive risk anal-
ysis which can lead to fatal consequences. Present-
day technologies are complex systems, and theywork
with various materials and utilise demanding pro-
cesses. During the life-cycle of these technologies,
hazardous events or failures can occur. So we try to
find ways to prevent all potential damage. For this
we need risk analysis.
The paper focuses primarily on risk analysis for

technological systems. Our aim is to present a new
application of standard software modelling tools to
improve and enrich computer processing, and to sim-
plify the steps in risk analysis. The paper therefore
provides a new interdisciplinaryviewof the risk anal-
ysis issue, as will be discussed below.

2 Risk analysis process

As mentioned above, each of us applies risk analy-
sis several times per day. We do this process fully
automatically (subconsciously). We usually do not
think about it in greater detail. For example, as we
leave home, we try to remember if all electric, gas
and water devices have been switched off or closed,
including the kitchen stove and the water taps. A
similar example is when we prepare for our holiday:

we think about possible hazards and we try to avoid
them or at least to be well prepared. It is obvious
that the same sort of thinking is applicable in tech-
nical branches. Let us take a look at three common
characteristic questions, mentioned by Tichý in [1]:
1. What failures can occur in the inspected object
or process?

2. How often can these failures arise?
3. What will happen after the failure occurs?
These questions are universal enough, and can be
applied to every human activity. However, for real
usage, especially in technical applications, it is nec-
essary to specify concrete steps with specific rules.
It is recommended to follow the general risk analysis
process for technological systems defined in the IEC
300-3-9 standard [2]. In particular, it is necessary to
take the following steps:
1. define the scope of the analysis,
2. identify the hazard and make an initial evalua-
tion of the consequences,

3. estimate the risk,
4. verify,
5. make documentation,
6. update the analysis.
As might be expected, each step can be subdivided
into more detailed tasks. Although these steps may
appear simple and easy, it is often quite difficult to
implement them.

3 Risk analysis techniques

In the course of history, many techniques have been
developed for making a risk analysis, especially in
the last hundred years. It is necessary to recognise
that this is an ongoing process. We can observe the
progress in risk analysis techniques in response to
rapid technical advances. Some modern techniques
are derived from older methods, which have been

41



Acta Polytechnica Vol. 50 No. 6/2010

Table 1: The most widely used risk analysis methods

Method

S
u
it
a
b
le
fo
r

co
m
p
le
x

sy
st
e
m
s

S
u
it
a
b
le
fo
r

n
e
w
sy
st
e
m
s

Q
u
a
n
ti
ta
ti
v
e

a
n
a
ly
si
s

T
o
p
-d
o
w
n
o
r

b
o
tt
o
m
-u
p

Event Tree Analysis (ETA) no no yes bottom-up

Failure Modes and Effects Analysis (FMEA) no no yes bottom-up

Fault Tree Analysis (FTA) yes yes yes top-down

Hazard and Operability Studies (HAZOP) yes yes no bottom-up

Human Reliability Analysis (HRA) yes yes yes bottom-up

Reliability Block Diagrams (RBD) no no yes top-down

Preliminary Hazard Analysis (PHA) yes yes no bottom-up

suitablymodified and enriched to fulfil current needs
andmakeuseofnewpossibilities. However, riskanal-
ysis techniques have originated in various fields of
activity and in various historical eras (in the scope
of technical and technological invention), but all of
them use the rules of systematic analysis and logic.
We can see the application of two main logical prin-
ciples: induction and deduction. Induction is used
when we investigate possible consequences of haz-
ardous events. On the other hand, deduction is ap-
plied to find out possible causes of hazards or failure
modes. In terms of risk analysis, these principles are
called bottom-up for induction, and top-down for de-
duction. Of course there are ways to combine these
twoprinciples, butwecanalsoapply themseparately.
In addition, risk analysis methods can be divided
from another point of view, as can be seen in [4].
The qualitative or quantitative character (or

both) of each method will now be discussed. This
distinction is based on whether the method provides
numerical results. Another aspect of risk analysis
methods is the output format. This issue is often de-
terminedby theprinciples that areapplied, the struc-
ture of the system (or process), and by the accom-
panying effort to achieve clear visualisation. Thus
we can find verbal, tabular or graphical outputs.
For a complex technological systemwith many parts
spread over a wide area, it can be a very hard task
to describe this system in purely textual form, and it
may be better to choose a suitable graphical repre-
sentation. The most widely used risk analysis meth-
ods are presented in Table 1, which has been taken
from [4, 2] and reduced.
All methods mentioned here strictly use logi-

cal principles. However, let us focus on an alter-

native way of making an analysis, which is widely
used in other technical branches: software develop-
ment.

4 Object-oriented principles

At the beginning of each software project, it is neces-
sary to make several analytical steps. In these steps,
software developers attempt to identify and describe
all desirable entities, their relationships and their be-
haviour. Here we can clearly see a basic similarity
with the risk analysis process: the initial steps are
the same — see section 2.
During the last three decades, object-oriented ap-

proaches have often been used for these purposes.
Object-oriented approaches are based on the idea
that theworld consists of objectswhich interactwith
each other. Objects are characterised by the follow-
ing features:
• encapsulation
• inheritance
• polymorphism

The term “encapsulation” indicates that the at-
tributes and functions of the entity are joined to-
gether into one specific object. Attributes describe
the state of the object, and functions can change the
state and behaviour of the object. Inheritance re-
flects the everyday reality of the evolution of objects.
It allowsa newobject to be derived fromone ormore
parent objects, and during inheritance somenew fea-
tures can also be appended. Polymorphism shows
the behaviour which different object types have in
common.
The idea of object-oriented approaches also in-

volves structural aspects, so we can consider basic

42



Acta Polytechnica Vol. 50 No. 6/2010

relationships, such as aggregation, association and
composition.
Interaction between objects is provided by send-

ing messages. The source object sends a request for
some function on the target object. The target will
react to the incoming event in accordance with its
state and conditions.
The same principle has been unconsciously ap-

plied in technically-oriented risk analysis for a long
time. We may inspect an object (e.g. a manufactur-
ing system, an engine, a component) in a view of its
properties, functions and interconnectionswith other
objects. In general, we can observe specific hazards
assigned to a specific object. Therefore we can say
that these hazards are encapsulated in the object.
Our experiencewith similar objects gives us a guide-
line for estimating the potential hazard, so we work
with inheritance. Polymorphism in risk analysis can
be seen in the followingway: the samehazard can be
caused by several different objects.
The Unified Modelling Language was developed

for graphical visualisation of previous concepts, and
also fits well for several other purposes.

5 UML modelling tools

Unified Modelling Language is a specific set of tools
which can help in several fields of activity, not only
in software engineering. It uses the object-oriented
approach mentioned above and adds some comple-
mentary tools for a better description of the struc-
ture and behaviour of the system. We demonstrate
that all these features canbeutilised in several stages
of risk management, mainly during a description of
the system (or process) and also in visual hazard sce-
nario modelling. Although UML is a very complex
language, let us take abrief look into its composition.
The language includes the following basic construc-
tion blocks [3]:
• subjects
• relationships
• diagrams

Subjects (or abstractions) can be further subdivided
to:
• structural abstractions— nouns e.g. classes, in-
terfaces, collaboration, use cases, etc.

• behaviour — modal verbs, e.g. interaction,
state;

• aggregations — packages for grouping signifi-
cantly related components;

• comments — additional useful annotations ex-
tending the model.

Diagramsareagraphical representationof themodel.
There are symbols with predefined syntax and se-
mantics to show the model in several views. Obvi-

ously, diagrams allow better orientation in a descrip-
tion of the system, especiallywhen several people are
participating in the project. In this case, diagrams
are an unambiguous formof description used in team
cooperation, and they are often more effective than
hugeparagraphsof text. An important difference be-
tween models and diagrams is that when we remove
a symbol from a diagram, it does not mean that the
corresponding parts in the model are automatically
discarded.
All descriptions, recommendations and simple ex-

amples canbe found in theUMLspecification [9]. We
can also see an interesting UML feature: the meta-
model approach. This means that a language defini-
tion can be described by its own means.

6 Risk analysis based on
UML

In this part of our paper we discuss the use of UML
as a helpful tool for risk assessment. We have tried
above to briefly describe the basic principles of the
risk analysis process andanobject-orientedapproach
used in software application design. Although there
are many similarities between these different pro-
cesses (both are usually organised as a project [6]),
it is not easy to apply the steps used in software de-
sign to a risk analysis. UML does not provide rec-
ommendedmethodologies for using its own tools and
the sequence in which to make the UML parts. Sev-
eral methodologies have been developed in software
engineering that aim to describe the right order, for
exampleRUP(RationalUnifiedProcess), see [7]. We
canalso take some inspiration from thesemethodolo-
gies, but the differences in our domain should not be
forgotten. Let us note that the RUP methodology
also includes some steps related to risk assessment.
An important consideration is that the whole pro-
cess of risk analysis cannot be finished at once and
cannot be done quickly. If we want to obtain ap-
propriate and valuable results, we have to iterate as
many times as necessary. We would now like to pro-
pose a new UML-based method for risk assessment.
This new method consists of the following steps:
1. describe the system structure by Class diagram
or Component diagram,

2. describe the behaviour by Activity, Sequence or
State diagrams,

3. identify, qualify and add potential hazards into
Class diagrams,

4. create rough hazard scenarios by Use Case dia-
grams,

5. describe detailed risk scenarios with the use of
Interaction or Activity diagrams,

6. evaluate the results and the documentation.

43



Acta Polytechnica Vol. 50 No. 6/2010

Fig. 1: NFA2X cable core processing line

7 Practical example

Let us take a look at a small practical example from
electro-technical manufacturing. We will be investi-
gating possible risks in a processing line that pro-
duces NFA2X cable core. This is an aluminium
twisted wire core with XLPE (cross-linked polyethy-
lene) insulation. A simple scheme of the processing
line topology is shown in Fig. 1, sketching its real
configuration at PRAKAB Pražská kabelovna, a.s.
company.
The drum (or reel) with the wire core is fastened

in the portal pay-off unit. The wire core is reeled
off by the pushing caterpillar and goes into the head
of the extrusion machine, where the insulation is de-
posited. In the next step, a new cable core is drawn
through the water-filled cooling trough. Then it is
dried up by the compressed air, tested for dielec-
tric strength by high voltage and wound up to the
drum. Appropriate tension of the wire core is pro-
vided by the draw caterpillar placed in front of the
portal winding unit. There are also two diameter
monitoringdevices anda lengthmeasurementdevice.
As the risk analysis process of the whole line is

very large,wewill focus only on the firstdevice in the
line – theportal pay-offunit. We limit our analysis in
order to focus on presenting UML as a risk analysis
support tool. For the same reason, we will not work
out the quantitative part. Our aim is to identify po-
tential hazards that could threaten the smoothness of
the operationand to showpossible realisation scenar-
ios. If, as inmost cases, we need a quantification, we
can make the Risk Priority Number (RPN) [8] cal-
culation used in Failure Mode and Effects Analysis
(FMEA). The results are given by equation (1)

RP N = Sv × Lk × Dt (1)
where the Sv is a severity value, Lk is a likelihood
value and Dt means detection. All three values are

estimated and assigned during risk analysis, usually
from a predefined degree scale. It is important to re-
member that the degree scale should not begin with
zero, and should have a suitable range.
First, we should start with object identification.

There are threemajor objects that participate in the
unwinding process:
• the portal pay-off unit,
• the cable reel,
• the operating staff.
Let us focus on the first of these. Fig. 2 shows

the design of the portal pay-off unit. For better un-
derstanding, a cable reel is also drawn in its working
position, but not fastened up. We can clearly see the
structure and the relationships between the compo-
nents. The portal consists of two movable intercon-
nected arms. Each armhas a lifter on its pole, which
is coupled to the other on the opposite side. One
arm is equipped with a compressed-air brake to sup-
ply reel braking. All movements are controlled by
electrical drives. The whole unit traverses on floor
rails across the unwinding direction. This feature is
necessary for correct unwinding, otherwise the cable
core can be damaged by the reel fronts at the termi-
nal points.

7.1 System description and hazard
identification

We can now go ahead, having in mind the steps de-
scribed in section 6. As afirst step, we shouldmake a
structural description of the systemusing a class dia-
gramandabehavioural descriptionby a sequence di-
agram. For the purposes of this paper, we canmerge
step 1 and step 3 of our former order, so we can
directly compose the identified hazards into the dia-
gram. Letusmake some simplifications. Wepresume
minimal failures of the electric drives and the power
supply. Thereforewe canconsider the three potential

44



Acta Polytechnica Vol. 50 No. 6/2010

Fig. 2: Portal pay-off unit [5] with a cable reel

Fig. 3: Class diagram showing a pay-off unit with possible hazards

45



Acta Polytechnica Vol. 50 No. 6/2010

Fig. 4: Sequence diagram describing preparation for unwinding

mechanical hazards shown in Fig. 3. The class dia-
gram includes standard UML notation [9] with rect-
angles as classes and junction lines as the symbols
for a relationship. The lines can be equipped with
short verbal phrases for better comprehension, and
also with special symbols. These symbols (e.g. di-
amonds) represent the type of relationship and op-
tionally the direction. It is sometimes suitable to
supplement amultiplicity of specific classes. This in-
dicates a possible count of the same classes in the
relationship. The notation of multiplicity can typ-
ically be expressed in the interval form, e.g. 0..1,
2..5, where the numbers represent lower and upper
bounds.
The important thing is that the diagram repre-

sents classes, not concrete objects. Hence we can
reuse this diagram for other similar devices that are
located in production lines.
The behavioural aspects will be presented as a

preparation for the unreeling process. The sequence
diagram inFig. 4 describes the sequence of steps that
an operator should take for the correctunreeling pro-
cess. The rectangleswith vertical dashed lines at the
top of the picture are called lifelines, and they repre-
sent participant objects in the interaction. The thin
vertical rectangles situated on the dashed lines show
the activity of the specific object.

7.2 Risk scenarios

In the following step we can create approximate risk
scenarios. They will be presented as Use Case dia-
grams with various focused objects and actors. The
left part of Fig. 5 shows the first case, where the cen-
tralpart is thepay-offunit andexternalobjects in the
role of actors can cause possible hazards. The right
side of Fig. 5 shows another situation. The central
investigated object is an operator, and the external
actors are the pay-off unit and the cable reel, which
can threaten the operator. We can note the same
graphical symbol (an icon of a “stick man” – see the
UML specification in [9]) for the human actors and
the technical object actors.
After the approximate scenarios, it is useful tode-

velop a more detailed description of potential hazard
occurrences, including their consequences. We can
use an activity diagram for this purpose. Formally,
activity diagrams arise fromPetri Nets, but they dif-
fer in several ways [9]. The common attribute is the
flow of a token. We will show here only the dia-
gram for the first scenario. It is drawn in Fig. 6. Let
us note that activity diagrams can, up to a point,
describe actions in terms of their location. This fea-
ture can also be very useful in risk analysis. Another
feature of activity diagrams is their ability to show
concurrent activities and activity branching.

46



Acta Polytechnica Vol. 50 No. 6/2010

Fig. 5: The first and second scenarios as a Use Case diagram

Fig. 6: The more detailed first scenario in an activity diagram

47



Acta Polytechnica Vol. 50 No. 6/2010

As was mentioned above, we will not make the last
steps (quantification, evaluation anddocumentation)
of ournewmethod,which lie outside theprimarygoal
of this paper. We have therefore completed our task.

8 Conclusion
In this paper, we have tried to present a new ap-
proach to a common interdisciplinary risk analysis
process. Our aim was to present the possibilities of
UnifiedModellingLanguageas a suitable tool for risk
analysis. We decided that the best way was to show
it on the basis of a small practical example. The
utilisation ofUML is very efficient, although the tool
itself comes froma different technical branch. Its ab-
stract concept allows the modelling of complex tech-
nical and other issues, e.g. from the field of biology.
It is impossible to show in a single paper the whole
range of possibilities of UML, so we tried to empha-
sise significant structural and behavioural modelling
considerations. Thanks to the origin of the Unified
Modelling Language, we can easily use it to convert
the model into further computer processing.
Although the application of UML seems to be

very beneficial, it is also necessary to discuss the
negatives. Obviously we have to learn UML, and
we have to understand it. Sometimes this could be
quite difficult, especiallywhen a risk analysis ismade
by a whole team of experts. Another consideration
is the need for a computer system. With the help
of available software tools we can work better with
UML-based risk models. Manipulation, storage and
advancedcomputationof themodels aremucheasier,
but professional software tools canbe veryexpensive.
We could also draw the diagrams on paper, but in
the case of huge systems this would involve a large
amount of work.
Futurework on this topic will involvemaking po-

tential hazard templates in electro-technical manu-
facturing. TheseUML-based templates could consist
of particular hazard classes and general risk scenar-
ios, which are typical for this branch of industrial
processing.

References

[1] Tichý, M.: Risk governance: analysis and man-
agement. 1st ed. Praha, C. H. Beck, 2006. 396 p.
ISBN 80-7179-415-5. in Czech

[2] IEC 300-3-9. Dependability management –
Part 3: Application guide – Section 9: Risk
analysis of technological systems. 1995. 28 p.

[3] Arlow, J., Neustadt, I.: UML2 and the unified
process: Practical object-oriented analysis and
design. 2nd Edition. Brno, Computer Press, a.s.,
2007. 567 p. ISBN 978-80-251-1503-9. in Czech

[4] IEC 60300-3-1. Dependability management –
Part 3-1: Application guide –Analysis techniques
for dependability – Guide on methodology. 2003.
55 p.

[5] Transportkabel DIXI a.s. [on-line].April 2nd2006
[cit. 2010–06–24]. Portal pay-off unit. Available
from WWW:
http://www.tkdixi.cz/Html ENG/OBD2800.htm.

[6] Jirsa, J.: Methods for Analysis and Modeling of
Failures in Manufacturing Systems. In Interna-
tionalConferencePelincec 2005 [CD-ROM]2005.
Warsaw, Warsaw University of Technology.

[7] IBM Rational Unified Process [on-line]. [cit.
2010–06–24] Available from WWW:
http://en.wikipedia.org/wiki/
IBM Rational Unified Process.

[8] FMEARPN [on-line]. [cit. 2010–07–09] Available
from WWW:
http://www.fmea-fmeca.com/fmea-rpn.html.

[9] Object Management Group, Inc. OMG Unified
Modeling Language, Superstructure, v2.1.2 edi-
tion, November 2007. [cit. 2010–07–09] Available
from WWW: http://www.omg.org/spec/UML/
2.1.2/Superstructure/PDF.

Ing. Jan Jirsa
Phone: +420 224 353 965
E-mail: jirsaj@fel.cvut.cz
Department of Electrotechnology
Faculty of Electrical Engineering
Czech Technical University in Prague
Technická 2, 166 27 Praha 6, Czech Republic

Doc. Ing. Jaroslav Žáček, CSc.
Phone: +420 224 352 198
E-mail: zacek@fel.cvut.cz
Department of Electrotechnology
Faculty of Electrical Engineering
Czech Technical University in Prague
Technická 2, 166 27 Praha 6, Czech Republic

48