Universität Augsburg

Fakultät für Angewandte Informatik

Model Checking of UML State Machines

A Case Study of the TWIN R Elevator System

Cornelius Nowald

Bachelorarbeit in Informatik und Informationswirtschaft

Aufgabensteller: Prof. Dr. Martin Wirsing

Betreuer: Moritz Hammer

Erstgutachter: Prof. Dr. Wolfgang Reif

Zweitgutachter: Prof. Dr. Martin Wirsing

Abgabedatum: 4. September 2007

Erklärung

Ich versichere, dass ich diese Bachelorarbeit selbständig verfasst und nur die angegebenen
Quellen und Hilfsmittel verwendet habe.

Augsburg, den 1. September 2007

.........................................................
Cornelius Nowald

iii
Abstract

Due to rising complexity of software, formal methods in the design and analysis of soft-
ware systems have become a necessity.
In this thesis we will describe the verification of UML state machines by the use of
model checking. For this we use Hugo/RT, a prototype tool that translates UML
models for model checking, theorem proving, and code generation. We will focus on
translation into PROMELA, the system language of the model checker SPIN. As case
study we chose the TWIN R elevator system by ThyssenKrupp, which operates with two

cabin per shaft.

v
Contents

1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 The TWIN Elevator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Preliminaries 3
2.1 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Model Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3 Hugo/RT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Models for a TWIN elevator system 7

3.1 Direct UML implementation approach . . . . . . . . . . . . . . . . . . . . 7
3.2 Case specific UML Modell in PROMELA . . . . . . . . . . . . . . . . . . 20

4 Conclusion 31

vii
Chapter 1

Introduction

1.1 Motivation
In public perception a software system seems to behave erroneous if it displays some
kind of error message, fails to work as expected or even halts completely. But in fact
there are also far more subtle errors which do not present themselves in such an obvious
manner. For example it was not for 17 years until an error in the Needham-Schroeder
Public-Key protocol was discovered and resolved by Lowe [Low95], [Low96]. This shows
that although a system persumably working correctly does not necessarily meet its re-
quirements. But it also shows that model checking can help to detect and resolve such
errors.
Today, with software rapidly becoming more complex and its being used to ensure safety
features, like in elevators, it becomes evident that special attention has to be paid dur-
ing analysis and design to ensure that such a software system meets those requirements.
Model checking techniques can provide such capabilities by automatically verifying for-
malized properties against a model, which is capable of simulating the systems critical
behavior.
Also as the “Unified Modeling Language” [Gro07] has become widely accepted as the de
facto notation for analysis and design of object-orient software systems it seems feasible
to use its mechanisms like class diagrams, state machines and collaborations for model-
ing. Thus, by using tools capable of verifying correctness of UML models, the integration
of verification into the software development process is greatly facilitated.
This is where Hugo/RT [Kna07a] comes into play. It provides mechanisms for automat-
ically translating a UML model (containing active classes with state machines, collabo-
rations, interactions, and OCL constraints) into a model checker specific input format,
running the verification and retranslating verification’s results back so they can be asso-
ciated with the UML model again.
The remainder of this thesis is organized as follows:
in the following section we will describe and motivate the case study for this thesis.
Chapter 2 addresses the technologies and methods used. In chapter 3 we will describe
three models for the TWIN R elevator system which increase in abstraction for reducing

1
2 CHAPTER 1. INTRODUCTION

state space. Chapter 4 contains a final conclusion.

1.2 The TWIN Elevator

The TWIN R elevator system [Thy07b] is a new type of elevator system where two cabins

operate in one shaft, i.e. inside one shaft the cabins are arranged above each other and
operate independently. This design is chosen as to increase efficiency in terms of place
consumed versus transport capacity provided. ThyssenKrupp states that – compared to
a conventional 4-shaft elevator design in a large building – either a 40% increase in pas-
senger transport capacity or a 25% reduction in building volume can be achived [Thy07a].
Obviously, compared to a conventional elevator the TWIN R system also has higher de-

mands on the software controlling it.

1. Due to the fact that both cabins in a shaft can move independently (this includes
towards each other) it has to ensure that the cabins do not collide and stay in safe
distance to each other, such that in any circumstance (including the unanticipated
failure of some of the various hardware components involved) a collision may be
adverted by emergency braking.

2. It has to ensure that all passenger calls for the cabins are correctly allocated. This
can be difficult, e.g. when a request for transportation from the lowest to the
highest level is send to the system since the cabins cannot cross each other and a
transfer between cabins is considered too inconvenient for the passenger. For this
special use-case a TWIN R system always incorporates an additional conventional

elevator shaft.

The architecture and requirements for a TWIN R system will be discussed in further

detail in the sections where we present the models.

The choice for TWIN R was inspired by a paper from Kammüller and Preibusch [KP07].

They use symbolic model checking to verify a TWIN R system. But at some points the

paper lacks of motivations for design decisions and statements and also seems to neglect
the aspect of communication.
By using the capabilities of Hugo and UML as notation of choice we will try to make a
more standardized approach and more clearly show the necessary steps in model checking.
Due to the lack of a technical specification for the TWIN R system our approach will also

be quite general and focus on main concepts that have to be considered when controlling
two cabins in one shaft.
Chapter 2

Preliminaries

2.1 UML
Today UML [M.H05] is used in almost in every software development process. There-
for it has become the de factor notation for analyzing and designing object orientated
Models. Though UML hast vast amounts of notations concerning static and dynamic
presentations of a system, we will mostly use the notation for state machines. Figure 2.1
show an example of a state machine. The choice for this notation comes mostly from
the fact that it is supported by UTE, a textural modeling notation supported by Hugo.
Also this notations has the advantage that its in many ways similar to automatons used
in model checking. For more detail on UML please refer to the literature.

2.2 Model Checking

Model checking is a approach to formally verifying that a given system satisfies a given
specification. Compared to testing and simulation, model checking doest not only cover
parts of a systems behavior but every possible state that can be reached and is relevant
with regard to the specification. It conducts ans exhaustive exploration of all possible
behavior. It is usually applied on reactive concurrent systems (e.g. communication
protocols, digital circuits).
Compared to other formal verification techniques (e.g. interactive verification) model
checking has two big advantages:

• The verification of a model is fully automatic. Once the model and specification
are available in format readable by some model checker the verification does not
require further supervision.

• In case the specification is violated model checking delivers a counter example

describing the faulty behavior. This trace shows every step from initialization to
the error and so usually provides good insight to where the model might have to
be redesigned or if the specification was not correct.

3
4 CHAPTER 2. PRELIMINARIES

Figure 2.1: State machine example

The biggest problem of model checking is state explosion. Even small systems, when
modeled naively, can produce such a huge state space that computational limits are
exceeded. For this reason when designing a model for verification one has to use abstrac-
tion. For example a analogous system can not be verified because they have in infinite
state space. So one has to apply abstraction to find an adequate discrete presentation
which still shows the behavior one wants to verify. In the discussion of our models though
when this is achieved further abstraction and limitation of behavior may be required to
make verification feasible.

2.3 Hugo/RT
Hugo [Kna07a] is a tool which supports verification of UML models. For this task it takes
a representation of an UML model, either XMI, ArgoUML or UTE, and translates it to
the system language of a model checker or theorem prover which then performs the actual
verification. Currents Hugo supports output for the real-time model checker UPPAAL,
the on-the-fly model checker SPIN and the theorem prover KIV. It also supports code
generation into Java and SystemC.
2.3. HUGO/RT 5

Once the model is translated Hugo can automatically start the verification process. After
verification it can take the results of the underlying tool and present them for example
as UML runs so one does not have to bother with the specifics notation of the underlying
tool.

We used UTE [Kna07b] a proprietary textual UML nation which supports modeling of
active classes with state machines, collaborations and interactions. Compared to the
other formats UTE reflects all UML features Hugo supports and and also is easier to
handle when one is used to textual modeling.
As underlying tool we used the the on-the-fly, LTL model SPIN [Hol03]. It supports
PROMELA (PROcess MEta LAnguage) a high level language for describing software
systems. Hugo translates each class of the given model to a process of the PROMELA
language together with the the event and transition handling conforming to the UML
semantics. One could compare it to using a scaffold which handles events and transitions
of the state machine in which the specific implementation of the class is embedded.
6 CHAPTER 2. PRELIMINARIES
Chapter 3

Models for a TWIN elevator system

3.1 Direct UML implementation approach

In our first approach we modeled a thorough system of a TWIN elevator. For this we
used the information publicly available from ThyssenKrupp [Thy07b] and from [KP07].
We modeled a complete elevator system with all its components as one might do during
the analysis or design phase of a software development process that precedes the actual
implementation of the software components of an actual TWIN elevator system. In doing
so, we attempted to show how easily the models created in the development process could
also be used for verification.
But although we tried to reduce the state space that resulted from translating the UML
model to model checker input formats in several ways, first verification attempts already
indicated that such a model had too big a state space to be checked with available
computational resources. Still we think that the creation process of this exhaustive
model proved meritful, especially as analysis of the various sub-models involved helped
to find several points at which we could abstract from a direct model. This proved helpful
to identify and understand the core elements of the system which need to be included in
a more abstract model.

A TWIN system is basically made up of the following components:

• the Destination Selection Control (DSC) which offers a user interface where pas-
sengers can select the floor which they wish be be brought to. In a TWIN system a
DSC is positioned at each floor. It accepts the destination wishes of the passengers
and sends those transport requests to the MCU.

• the Main Control Unit (MCU) is responsible for handling incoming requests. It
chooses a cabin in a specific shaft which can handle the incoming request and sig-
nals the shaft to dispatch the cabin. To complete this task it also has to maintain
information about the status of requests currently being processed and the posi-
tions of the cabins.

7
8 CHAPTER 3. MODELS FOR A TWIN ELEVATOR SYSTEM

• a shaft is a conventional elevator shaft. It contains only one cabin and has no spe-
cial features, but it is required to handle calls which a TWIN-shaft cannot handle,
e.g. when a transport request from bottom to top floor is issued.
The shaft responds to messages from the MCU and initiates the movement of the
cabin. Once a cabin has completed its movement it sends a completion signal to
the MCU.

• a conventional cabin resembles a cabin in the shaft that can move at a given speed
to a given target floor.

• contrary to a conventional shaft, a TWIN shaft holds two TWIN cabins and also
monitors the distance between them. This is a safety feature provided by the TWIN
shaft which ensures that the cabins are slowed down or brake entirely when they
move too close to each other.

• a TWIN cabin is similar to a conventional cabin, but may move in two different
speeds depending on the distance to the other cabin in its TWIN shaft. It also has
emergency brakes which are engaged by its TWIN shaft when the distance between
the two TWIN cabins becomes critical.

The UML class diagram of a TWIN elevator system is shown in figure 3.1
As one can see we did not use inheritance to model the cabin doors or the similarities
between a cabin and a TWIN-cabin. This is because of technical limitations of UTE, the
input format of Hugo/RT, which so far provides no notation for expressing inheritance.
Concerning model checking one has to deliberate whether the components not directly
required for verification should also be modeled. We excluded those components that
have no direct impact on the safety of the TWIN system (like the doors) in our second
model to significantly reduce the state space.
The goal of our model is to simulate a real systems behavior in the processing of requests
and the ensuring of safety measures. To do so, a minimal TWIN system configuration
which has one conventional and one TWIN-shaft are sufficient. Adding additional shafts
would not change the basic behavior of the system since it would not enable the system
process transportation requests which could not be handled before. It would only enable
to increase throughput. Though this might seem desirable one has to keep in mind that
for model checking a minimal state space is far more desirable, since a too complex model
might have larger computational needs for verification than available.
Since for conventional model checking a discrete system is required (non-discrete systems
can be checked by specialized model checkers, but for physical systems, most properties
are undecidable and require severe simplifications, c.f. [HH]) and we also need to keep
the state space as small as possible, we make the following abstractions:
3.1. DIRECT UML IMPLEMENTATION APPROACH 9

Figure 3.1: TWIN class diagram

• The positions of the cabins are discrete to the floor levels, i.e. a cabin cannot be po-
sitioned between two levels or something similar. This greatly reduces the problem
size but also brings benefits modeling request processing and cabin movement.

• We do not model cabin acceleration, meaning the cabins start moving and stop
abruptly. This is a direct result from the above and greatly simplifies movement
modeling since now it simply becomes a matter of performing a transition into
another.

• In order to abstract from concrete communication implementation details, we em-

ploy the UML abstraction of operation invocation. The communication is trans-
lated by Hugo/RT to message queues as provided by PROMELA, the input lan-
guage of the SPIN model checker we employed.

• We neglect the physical time in order to obtain a discrete model, where state
transitions occur independent of a notion of duration.

In the first model that incorporates the abstractions mentioned, we chose to model 11
levels since this is the smallest configuration of a real-world TWIN system we know of.
For the calls between the components we used the reception notation of UTE , which
models asynchronous communication. In a first attempt, modeling the communication
with synchronous operation calls resulted in undesired blocking behavior.
In the following section we will describe how we modeled the single components and their
behavior in more detail.
10 CHAPTER 3. MODELS FOR A TWIN ELEVATOR SYSTEM

3.1.1 DSC
In our model the DSC represents the input which comes from the passengers. For this
we abstracted from the concept of having one DSC per level, but chose to model one
single DSC for the entire TWIN system which represents the behavior of the actual 12
DSCs which send their requests to the MCU in an interleaved way. This is justified by
the assumption that the MCU stores incoming requests in a queue which it operates in a
FIFO (first in first out) fashion. We made this assumption because it seems reasonable
that the MCU only checks and dispatches one request at a time, which greatly facilitates
creating an algorithm for choosing a cabin, but does not significantly decrease perfor-
mance because the time required for computation may be considered many magnitudes
smaller than that for actual transportation.

Our DSC basically has two states:

• a Ready state in which it awaits incoming passenger requests.

• a Send state where it first nondeterministically chooses two level representing the
origin and destination of the request and then sends it to the MCU, thus modeling
random requests generated by the passengers (which are not modeled).

The DSC constantly switches between these two states and thus simulates a never ending
flow of passengers requesting all possible floor combinations. After some simulations runs
we realized that this has some major disadvantages, which led to a throughout redesign
of the DSC in our second model. The MCU gets flooded with requests even while it is not
capable of handling them, and more important this approach neglects the opportunity to
greatly reducing state space without providing a significant safety-critical for verification.
3.1. DIRECT UML IMPLEMENTATION APPROACH 11

Figure 3.2: DSC state and send entry activity

12 CHAPTER 3. MODELS FOR A TWIN ELEVATOR SYSTEM

3.1.2 MCU
The MCU is responsible for processing the incoming requests and managing the dis-
patching of the cabins. For it has 5 orthogonal regions. Two for receiving and processing
requests and then also one for each cabin.

The AcceptRequest region receives the requests from the DSC and then informs the
WorkQueue region with an internal call to store it in a queue. The objective of this
region is to keep the queue MCU from discarding requests once the queue is full. In this
case this region enters a busy state where it cannot receive further requests and waits
until a requests is dequeued by the WorkQueue area.

The WorkQueue region is responsible for storing requests in the queue and processing
them. For the processing we do not provide a specific algorithm but use a nondetermin-
istic approach to model the behavior. In doing so we stay independent from a specific
algorithm which might change over time, e.g. due to optimization. We implement some
restrictions, though. We always pick the oldest request (first in the queue) that can be
handled at the moment. The selection and dispatching of a cabin works as follows:

Choose a valid request Find the oldest request in the queue (if any) that can be
processed. For this we evaluate the following expressing for each request, indicating
if any cabin could handle it without violating safety conditions

convAvail
|| (lowerAvail && ((upperPos-from) >= MIN_DISTANCE)
&& ((upperPos-to) >= MIN_DISTANCE)
&& ((upperTarget-from) >= MIN_DISTANCE)
&& ((upperTarget-to) >= MIN_DISTANCE)
)
|| (upperAvail && ((lowerPos-from) >= MIN_DISTANCE)
&& ((lowerPos-to) >= MIN_DISTANCE)
&& ((lowerTarget-from) >= MIN_DISTANCE)
&& ((lowerTarget-to) >= MIN_DISTANCE)

The convAvail, lowerAvail, upperAvail are booleans which indicate if

a cabin is currently free or already handling a request.
upperPos, lowerPos, upperTarget, lowerTarget are the current posi-
tions resp. targets of the lower and upper TWIN cabin. from, to are origin and
destination of the request.

Choose Cabin Once a request that can be handled is chosen pick a cabin and dispatch
it. For this we basically use the same expression as above to determine which
cabin can handle the request and then nondeterministically dispatch one by storing
3.1. DIRECT UML IMPLEMENTATION APPROACH 13

the request parameters for that cabin and calling the MCU’s internal dispatch
reception. In case of the TWIN cabins we also store highest (resp. lowest) level
to be reached during processing in lowerTarget (resp. upperTarget). This is
necessary to ensure that later requests are chosen correctly without forcing a cross
over of the cabins or similar invalid behavior.
Dequeue Request Finally we have to dequeue the request. If the queue was full, we
inform the AcceptRequest Region so it may accept incoming requests again.

The use of a queue seems to be a pretty straight forward approach for handling incoming
request but it introduces a severe problem for the actual model checking: due to the
nature of queues the state space is greatly increased since during model checking every
possible permutation of possible requests creates a distinct state. The majority of these
requests are currently not being processed and therefore do not greatly effect the behavior
relevant for verification. For this reason one should always consider if the desired behavior
(that is mostly dominated by the nondeterministic input of the DSC) could be modeled
without queues.

In the three regions to manage the cabin movement the MCU keeps the cabins in a
vacant status until a internal dispatch call for the cabin is received. During processing
this call it checks if the cabin is already at the requests origin level, in which case it
sends it directly to the destination level. Otherwise the cabin is first send to pickup the
passenger. It does so by sending a send call to the shaft holding the cabin. For safety
reasons the shaft may deny the call in case it finds a safety violation, e.g. a call for the
upper TWIN cabin to move down even though both cabins are not allowed to further
close in on each other.
Once a cabin has completed its movement its shaft notifies the MCU, which then either
sends it to the destination marks it as available again, depending on the state of the
cabin (pickup or deliver).
Additionally, the regions for the TWIN cabins can also reach an exit point due to the
shaft containing them signals that the cabins have been stopped due to some safety
violation. This marks them as unavailable so they are not further considered for request
handling. We did not model this for the conventional cabin since they are a well known
concept and there seemed no special safety measure required.

3.1.3 TWIN shaft

The TWIN shaft is the component responsible for monitoring and controlling the move-
ment of the cabins and for ensuring the following safety requirements:
• Once the cabins are closer than a given safe distance to each other they may only
move with limited speed.
• In case the cabins go below a minimal distance, which could lead to a crash if the
cabins keep moving, the shaft has to engage the brakes of the cabins. This way the
cabins come to a controlled stop.
14 CHAPTER 3. MODELS FOR A TWIN ELEVATOR SYSTEM

Figure 3.3: MCU state machine

3.1. DIRECT UML IMPLEMENTATION APPROACH 15

In [KP07] a 4 level safety concept is mentioned for which we could not find a specification,
but which only seems to be modeled after the informal statements of the ThyssenKrupp
marketing web site. E.g., we could not find a reason for modeling a safety catch in
addition to the brakes since no circumstances are described in which the brakes might
fail. Therefore we decided to abstract from that and only model that the brakes are to
be engaged in the critical situation of the cabins converging below the minimal distance.
To complete its task the TWIN shaft has two orthogonal regions:

The ProcessRequest region handles the incoming send calls from the MCU. Once a call
is received it checks if the call is valid, e.g. in case of the lower cabin following expression
has to be true for a call to be valid:

lowerTarget >= minLevel

&& lowerTarget <= maxLevel
&& lowerTarget != lowerPos
&& (upperPos - lowerTarget) >= MIN_DISTANCE
&& (upperTarget - lowerTarget) >= MIN_DISTANCE
&& !lowerMoving

minLevel, maxLevel are the bottom resp. top level of the shaft in our case always 0
and 10. The expression for the upper cabin is analogous. If this expression evaluates to
false the MCU is notified with a deny call. Otherwise a goto call is issued to the cabin,
telling it to move to the given target level. Also depending on which cabin the call was
for and if the other cabin is already moving the region transitions to a state representing
the movement of both cabins.
In these states the TWIN shaft still receives and processes incoming calls from the MCU,
but more importantly also constantly receives position updates from the cabins which
are stored locally. These updates are required so the shaft can enforce the safety require-
ments since the distance between the cabins is calculated from their positions.
When a cabin signals that is has reached its target the TWIN shaft notifies the MCU
by issuing a cabinDone call and again transitions to a state representing the current
movement status of the cabins.

Inside the EnsureSafety region the shaft only transitions between Safe and Slow-
Movement as long as the cabins operate normally. When the cabins undercut the safe
distance threshold it tells them to slow down and once they return to safe distance to
speed up again.
A critical situation arises when the cabins go below the minimal distance where further
movement could lead to a crash. In this case the shaft exits the both orthogonal re-
gions and goes into an emergency braking procedure. It tells both cabins to engage their
brakes, waits until both cabins signal that they have stopped and then notifies the MCU.
Once the MCU is notified the TWIN shaft has reached its final state and is thereby
rendered inactive.
16 CHAPTER 3. MODELS FOR A TWIN ELEVATOR SYSTEM

Figure 3.4: TWIN shaft state machine

3.1. DIRECT UML IMPLEMENTATION APPROACH 17

3.1.4 TWIN cabin

The TWIN cabin is the component which models the movement. During normal oper-
ations it stays in its working region. That is after initialization it goes in a stationary
state where it waits for incoming calls. Though stationary it has to handle incoming
slowDown and speedUp calls from its holding shaft, so once it starts its movement it
knows which is its currently allowed speed. On an incoming goto call it first closes its
door and then, depending on its current position and target, starts and up- or downward
movement. During the movement it can receive slowDown or speedUp calls which tells
it to adjust its current speed. In case of a slowDown it reduces its movement to one level
per step and in case of a speedUp it increases it to two levels. On reaching the target it
opens it doors and once this is achieved issues a cabinDone to its shaft.
We explicitly modeled the doors here so we could verify that cabin movement would only
occur with closed doors. Also we wanted to leave the possibility open to later include
modeling of time events for showing that operations could be handled in given time lim-
its.

The safety critical part of the cabin is its braking procedure. On an brake call from the
shaft it tells its brakes to engage and waits for a stopped as confirmation. Once the
cabin is stopped it ensures that its doors are opened so passengers can safely leave the
cabin.

Figure 3.5: TWIN cabin state machine

18 CHAPTER 3. MODELS FOR A TWIN ELEVATOR SYSTEM

3.1.5 Other components

For the remaining components we will only show the state machine diagrams since they
are self explaining or similar to their TWIN counterparts.

Figure 3.6: convetional Shaft state machine

3.1.6 Discussion
As already mentioned at the beginning of the section we came across some problems
regarding the computational limits to verify this first model. In an early verification
run, using bistate hashing to reduce memory usage, we already reached a state space of
over 750 million even though we did not fully cover the model as was indicated by code
coverage reported by SPIN. Still we analyzed the model using SPIN’s simulation mode
to find out where problems arose and where could apply further abstraction.
As already mentioned our first discovery was that the queue, though a common technique
in programming, was causing problems. First since there is no notation in UTE for di-
rectly using queuing mechanisms provided by PROMELA language we had to model the
queue ourselves. This was pretty straight forward but artificially increased state space
since we had to model every single step of queue management which SPIN would handle
internally when using queues from PROMELA. Second there was the problem of the
queue itself. In many situations we observed during the simulations the queue was filled
to its maximum. But since those requests in a queue are relevant for the future behavior
of the system and not the current processing the increased the state space without rep-
resenting a required behavior. Also such a cases the DSC would not block immediately
but continue to send requests until the event queues, created by the Hugo translation
to PROMELA, would also fill up increasing state space even further. Third due to the
increased number of operations performed it partially became hard to follow the relevant
behavior of the system when analyzing the simulation trails.

Another source which increased the state space was overhead which is caused by UML
3.1. DIRECT UML IMPLEMENTATION APPROACH 19

Figure 3.7: conventional Cabin state machine

Figure 3.8: TWIN and coventional door state machine

Figure 3.9: TWIN brakes state machine

20 CHAPTER 3. MODELS FOR A TWIN ELEVATOR SYSTEM

state machines and restrictions by the UTE syntax. For example the position updates
from the cabins to the shafts has to be modeled calling a reception or operation since
their is no way to directly access the variables of an object. In PROMELA one could
optimize this for verification by using a global variable. This way it would not be neces-
sary to go through the several steps of placing the update call in the shafts event queue,
fetching the call and go through the state hierarchy until the change can finally be applied.

Because there is no notation in UTE for creating expressions regarding state in which a
component is, one has to use redundant variables like condAvail when making behav-
ioral decisions regarding the next step.
Just as well Hugo in combination with UTE naturally can only offer a generic way for
translating UML state machines to PROMELA which again limits the possibilities to
apply model specific optimizations. And applying such optimizations after the the trans-
lation, the PROMELA code automatically generated by Hugo turned out to be an almost
impossible task.

After these insights we arrived at the realization that directly verifying a UML model of
this size is not yet feasible. Hence we decided to make a second approach by designing
the UML model directly in PROMELA and also applying further abstraction.

3.2 Case specific UML Modell in PROMELA

For the second model we chose to directly implement the UML state machines for a
TWIN system in PROMELA. This approach brought us several advantages:

Less redundancy In a PROMELA process describing a UML state machine the current
state is saved in ordinary variables. This way one can now use this information
directly, e.g. instead of having to carry along an extra variable like upperAvail
one can now directly check if the upper TWIN cabins state as managed by MCU
is Vacant or not.

Reducing Queue usage Using PROMELA’s message channels and global variables
we tried to minimize the amount of queue like structures in the model. We could
now fine tune the event queues for each component instead of only setting global
parameters as supported by UTE.

Language specific constructs PROMELA provides constructs such as d_step and

atomic which steer the interleaving of concurrent processes and allow for major
decreases in required states, since many interleaving sequences are ruled out. Al-
though the PROMELA code as generated by Hugo/RT contains atomic to model
that internal operations of different UML state machines semantics do not inter-
fere with each other, it does not hold d_step constructs (which not only disable
interleaving, but also do not store intermediate states produced during the d_step-
annotated block). Inserting d_step whenever possible can help to reduce state
3.2. CASE SPECIFIC UML MODELL IN PROMELA 21

space because now parts of the internal operations are not only atomic with respect
to other state machines but also to the verification process.
Better insight In comparison to the UML runs provided by Hugo the trail files pro-
duced by SPIN give better insight into the operations of the system because now
each single step during state transitions can be easily followed. Whith Hugo/RT
such trail can also created but as they relate to the automatically generated code,
pursuing the trail through the code usually is quite wearisome.
Additionally we applied further abstraction trying to reduce the behavior of the TWIN
system to a minimum required for verification.

3.2.1 Abstracting from floors

In a first step we abandoned the idea of modeling concrete floors but positions relative
to the TWIN cabins in combination with the distances between them and the top and
bottom levels of the shaft. This does not only help to reduce state space but also made
the model independent from a concrete realization with a fixed number of floors.
The alignment of the new levels positions is shown in figure 3.10. min and max are the
bottom resp. top level of a shaft. uTL represents the area beneath and oTL the position
at the lower TWIN cabin. aTU and oTU are the equivalent for the upper TWIN cabin.
bTC represents the area between both cabins. Additionally to the positions the distance
between the cabins (distBTC) and from the lower (resp. upper) cabin to the bottom
(resp. top) (distTL, distTU) are now required. distBTC can be have one of the
following values cSAFE, cMINIMAL, cUNSAFE, cCRASH with cMINIMAL being the
minimal distance between both cabins allowed while operating. Distance to bottom and
top level can be sSAFE, sREACHED, sCRASH where sREACHED is the situation where
the cabin is at bottom (resp. top) level.
At first it seems that this greatly limits the capabilities of modeling the full behavior,
but this is not the case. Compared to the first model one can not directly model a
request from for example level 8 to level 4 anymore, but similar behavior can modeled in
using the relative levels depending on the current state of the system as shown for some
example in figure 3.11. In a in Figure 3.11 the the request would be similar to a bTC to
bTC request and in both models this request could be handled by any cabin. b shows a
situation where in both models only the upper and conventional cabin could handle the
request. In c and d only the conventional cabin could handle the request. In c this is
obvious and in d the upper cabin could not handle the request because the cabins are in
minimal distance to each other preventing it from moving down.
But this is no mapping in both directions. For example in a situation with cabins being
at top resp. bottom level, a call from level 9 to 8 could only be handled by the upper
and twin cabin in our first model, but by mapping it to bTC to bTC we have the same
situation as in a. But all requests in the more abstract relative notation can be mapped
to a request in the more concrete first model.
But the new way of modeling has consequences for other aspects of the model. Movement
cannot longer happen by moving up or down one level at a time, because e.g. oTL always
22 CHAPTER 3. MODELS FOR A TWIN ELEVATOR SYSTEM

Figure 3.10: relative positions

represents the current position of the lower TWIN cabin. Instead of moving the cabin
we now have to change variables relevant the status of the system. For illustration we
will describe how we modeled the movement of the lower TWIN cabin on its way to the
pickup point for the current request.
Figure 3.12 shows the changes which may or must be applied when moving down.
a shows a normal step in downward movement without reaching the pickup point. In
case distBTC was minimal (cMINIMAL) it must be set to cSAFE. In case it already was
cSAFE nothing has to be changed.
lowerDest is the destination point for the request currently handled by the lower
TWIN cabin. MCU are the pickup and destination points for the request currently being
processed by the MCU. If any of those variables point to the current position of the cabin
it naturally has to be set to be to a value above it. Optionally a change from uTL to
oTL may occur. The optional and required changes of a also apply in b and c not shown
otherwise.
In situation c we restricted the the pre-status of the system to prevent inconsistent
behavior. Otherwise those variables would have to be set to MIN or jump over oTL
directly to bTC. By restricting that the cabin can only reach the bottom level when no
other variable points to a position below or on it without being MIN easily eliminates
situations that would require special treatment.
3.2. CASE SPECIFIC UML MODELL IN PROMELA 23

Figure 3.11: possible mappings for requests from level 8 to 4

24 CHAPTER 3. MODELS FOR A TWIN ELEVATOR SYSTEM

Figure 3.12: lower TWIN cabin moving down

3.2. CASE SPECIFIC UML MODELL IN PROMELA 25

The upward movement of the lower cabin as well as the movement of the upper TWIN
cabin modeled similar as can be seen in the PROMELA code in the appendix.
26 CHAPTER 3. MODELS FOR A TWIN ELEVATOR SYSTEM

3.2.2 Reducing components of the TWIN system

In addition to abstracting from the levels we also reduced the overall size of the system
by removing components which do not contribute behavior absolutely necessary.
Because we focused on processing requests and cabin movement in the second model
we first we disposed of the doors. Doors are a well known concept which do not show
behavior relevant for verification of TWIN system specific features. For similar reasons
we also removed explicit modeling of the conventional shaft and cabin. Both components
are well known concepts and are only required to handle some specific requests which
the TWIN cabins can not fulfill. Therefore we decided to treat requests which would be
passed to the conventional a shaft as if they were immediately fulfilled.
Driven by the the abstraction from levels, new movement and disposal of the doors we
also to rid of the cabins. In the first model the cabins basic task was to handle the doors
and perform movement, but already in this model the shaft was monitoring the movement
and enforcing safety. And because with the new model movement is no longer a single
incremental step which then propagates though the system, we used the possibility to
integrate it into the shafts tasks and so further reduced the number of components.
Reducing of the number of components significantly down-sized state space because now
the number orthogonal state regions was reduced and the number of states reachable
inside on region multiplicative amount to the total number of system states.

3.2.3 Redesigned Components

Due the changes and to reduce state space even more we redesigned the components. In

our first model the DSC bombarded the MCU with transport requests which could not
always be handled immediately which meant that such requests would have to be stored
in the queue. So to reduce this kind of behavior we restricted the transport requests
that the DSC produces dependent to the current state of the system. Because we no
longer explicitly model the conventional shaft and cabin we mostly prevent the DSC from
creating requests that could only be handled by those.
For example the pickup level for a request can only be set to MIN if the lower cabin is not
currently processing another request. Also setting the pickup to MIN does not make sense
when the lower cabin is already at the bottom of the shaft and the distance between the
cabins is cMINIMAL because this would result in a request that could only be handled by
the conventional cabin. We use the following statement for nondeterministically selecting
the pickup level:
3.2. CASE SPECIFIC UML MODELL IN PROMELA 27

if
:: (MCU_lower_state == MCU_lowerA_Vac)
&&!(TSHAFT_distLower <= sREACHED && TSHAFT_distBTC <= cMINIMAL)
-> DSC_pickup=MIN
:: (MCU_lower_state == MCU_lowerA_Vac)
&& !(TSHAFT_distLower <= sREACHED)
-> DSC_pickup=uTL
:: (MCU_lower_state == MCU_lowerA_Vac)
&& !(TSHAFT_distLower <= sREACHED)
-> DSC_pickup=oTL
:: !(TSHAFT_distBTC <= cMINIMAL)
-> DSC_pickup=bTC
:: (MCU_upper_state == MCU_upperA_Vac)
&& !(TSHAFT_distUpper <= sREACHED)
-> DSC_pickup=oTU
:: (MCU_upper_state == MCU_upperA_Vac)
&& !(TSHAFT_distUpper <= sREACHED)
-> DSC_pickup=aTU
:: (MCU_upper_state == MCU_upperA_Vac)
&& !((TSHAFT_distUpper <= sREACHED) && TSHAFT_distBTC <= cMINIMAL)
-> DSC_pickup=MAX
fi

For selecting the destination point a similar statement is used.

Also to get rid of the queue for pending requests in the MCU, the DSC waits for confir-
mation that the request has been passed on to be handled a cabin before issuing another
request. This does not disable the capability for more than one request being handled
because only selecting and dispatching the cabin is done one request at a time, as in the
first model. Figure 3.13 shows the state machine of the redesigned DSC.

With the new DSC and removal of the conventional parts the MCU can be reduced
to three orthogonal regions. The regions for the TWIN cabin are basically the same but
due to a change with the TWIN shaft we will discuss later, the exit transitions due to
a stopped cabin have been removed. The other region handles communication with the
DSC. It waits for an incoming request and on reception transitions to a state where it
checks the request and dispatches a cabin. Instead of using internal calls to trigger the
dispatch of a cabin, we internally enable the firing of the needed transition. Though this
is not strictly UML conformant it helped to simplify the model. See figure 3.14 for the
state machine.
We also modified the process for selecting a cabin to handle a request. Instead of making
an full nondeterministic choice we applied priorities to the cabins. We decided that was
28 CHAPTER 3. MODELS FOR A TWIN ELEVATOR SYSTEM

Figure 3.13: redesigned DSC state machine

because this way we could down-size state space, without greatly modifying the possible
behavior, also it seems reasonable that in a concrete realization some kind of priority
would be applied to reduce complexity of choosing a cabin. The priorities in are follows:
first lower TWIN cabin , then upper TWIN cabin then conventional cabin. This only
holds when all three cabins could handle the request, in case a cabin cannot currently
handle the request it drops out of the priority order.
Though the conventional shaft appears here we do not model it. It is only required to
handle a few cases in which none of the other could handle the request. Such requests
are simply fulfilled once they have been appointed to the conventional cabin. For further
studies it would be interesting to see if one could completely remove the conventional
part from the model.

The changes for the TWIN shaft are the most significant ones we discussed above. It
models the new movement paradigm discussed above and also holds changes regarding
the safety properties. Using relative positions makes modeling of braking pretty much
obsolete since cabins do not have any kind of speed and only their distance to each
other is modeled. So instead of modeling braking we decided to instead verify that there
never a situation arises where the distance between the cabins drops below cMINIMAL,
a situation that would cause an emergency braking. The distance between the cabins
can only be reduced when the upper (resp. lower) cabin is moving down (resp. up). The
choice happens nondeterministically.
All these changes enabled us to reduce the TWIN shaft to two orthogonal regions. One
for each cabin which responds to receptions of the MCU, performs the abstract movement
and once the target floor is reached it signals this event to the MCU. Reaching (resp. not
reaching) the target is again modeled by internally enabling corresponding transitions
to be fired. Also, to reduce redundancy of storing the target for the cabins locally,
3.2. CASE SPECIFIC UML MODELL IN PROMELA 29

Figure 3.14: redesigned MCU state machine

30 CHAPTER 3. MODELS FOR A TWIN ELEVATOR SYSTEM

lowerTarget and upperTarget actually represent the pickup or destination stored

in the MCU for the cabins current request, depending on if the cabin is going to its
pickup or destination point.

Figure 3.15: redesigned TWIN shaft state machine

3.2.4 Discussion
To achieve a checkable we had to significantly reduce system size, apply abstraction and
restrict behavior. Though one might argue that this is no longer a TWIM system, we
think that by reducing the TWIN system to its basic we achieved a more general presen-
tation of it. Of course with our model we cannot directly verify a concrete realization of
a TWIN system, but we can show that without regard to the number of levels or specific
velocities a TWIN system can operate without reaching situations where software mal-
function would cause an emergency braking.
We verified this by checking the property that the distance of the cabins always is greater
or equal than cMINIMAL ([] distBTC >= cMINIMAL). The results of this verifica-
tion run also showed us that we successfully had achieved to reduce the state space to
approximately 4 million and fully covered the model since SPIN did not report unreached
code.
Chapter 4

Conclusion

The approach to directly verify the UML models created during analysis and design holds
great potential, since it is based on a widely know notation and can uses artifacts which
in most software development processes are created any why.
As our first model showed such a direct approach is currently not quite feasible. The
state space a naive UML approach generates is just too big because usually not enough
abstraction has been done. But as our second approach showed using such direct ap-
proach model as basis for further abstraction and so reducing the UML model until it
reaches a checkable size produces results which enable the verification of basic system
behavior.
The UML provides a scaffold for simply creating models in a familiar way. But the fact
that the semantics of the UML for handling requests and transitions cause a significant
overhead without adding system specific desired behavior poses a problem. State space
is increased because even in cases of small system changes we might have to create a
serious of events to propagate it.
But we think that with further work in the area, trying to optimize translation and pro-
viding mechanisms to more directly access the current state of the system, it can be a
good alternative the the established concepts.

31
32 CHAPTER 4. CONCLUSION
Bibliography

[Gro07] Group, Object M. http://www.uml.org/. visited 05.08.2007

[HH] Henzinger, Tom ; Ho, Pei-Hsin: HyTech: The Cornell Hybrid Technology
Tool, S. 29–43

[Hol03] Holzmann, Gerald J.: The SPIN model checker: primer and reference man-
ual. Boston, MA 02116 : Addison-Wesley, September 2003. – ISBN 0–321–
22862–6

[Kna07a] Knapp, Alexander. http://www.pst.ifi.lmu.de/projekte/hugo/. visited

14.08.2007

[Kna07b] Knapp, Alexander. http://www.pst.ifi.lmu.de/projekte/hugo/#UTE. visited

14.08.2007

[KP07] Kammüller, F. ; Preibusch, S. An Industrial Application of Symbolic Model

Checking – The TWIN-Elevator Case Study. Accepted for publication in In-
formatik Forschung und Entwicklung. 2007

[Low95] Lowe, Gavin: An Attack on the Needham-Schroeder Public-Key Authen-

tication Protocol. In: Information Processing Letters 56 (1995), Nr. 3, S.
131–133

[Low96] Lowe, Gavin: Lecture Notes in Computer Science. Bd. 1055: Breaking and
Fixing the Needham-Schroeder Public-Key Protocol using FDR. Springer Ver-
lag, 1996, S. 147–166

[M.H05] M.Hitz: UML @ Work. dpunkt.verlag, 2005. – ISBN 3–89864–261–5

[Thy07a] ThyssenKrupp. http://twin-elevator.com/New-buildings.368.0.html. visited

14.08.2007

[Thy07b] ThyssenKrupp. http://www.thyssenkrupp-

aufzuege.de/default.asp?id=75&nid=161. visited 14.08.2007

33