Thesis

Universität AugsburgFakultä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 angegebenenQuellen 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 ofmodel checking. For this we use Hugo/RT, a prototype tool that translates UMLmodels for model checking, theorem proving, and code generation. We will focus ontranslation into PROMELA, the system language of the model checker SPIN. As casestudy we chose the TWINR© elevator system by ThyssenKrupp, which operates with twocabin per shaft.

v

Contents

1 Introduction 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 The TWIN Elevator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Preliminaries 32.1 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Model Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.3 Hugo/RT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Models for a TWIN elevator system 73.1 Direct UML implementation approach . . . . . . . . . . . . . . . . . . . . 73.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 somekind of error message, fails to work as expected or even halts completely. But in factthere are also far more subtle errors which do not present themselves in such an obviousmanner. For example it was not for 17 years until an error in the Needham-SchroederPublic-Key protocol was discovered and resolved by Lowe [Low95], [Low96]. This showsthat 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 sucherrors.Today, with software rapidly becoming more complex and its being used to ensure safetyfeatures, 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 criticalbehavior.Also as the “Unified Modeling Language” [Gro07] has become widely accepted as the defacto notation for analysis and design of object-orient software systems it seems feasibleto 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 integrationof 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 describethree models for the TWINR© 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 TWINR© elevator system [Thy07b] is a new type of elevator system where two cabinsoperate in one shaft, i.e. inside one shaft the cabins are arranged above each other andoperate independently. This design is chosen as to increase efficiency in terms of placeconsumed versus transport capacity provided. ThyssenKrupp states that – compared toa 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 TWINR© 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 includestowards each other) it has to ensure that the cabins do not collide and stay in safedistance to each other, such that in any circumstance (including the unanticipatedfailure of some of the various hardware components involved) a collision may beadverted by emergency braking.

2. It has to ensure that all passenger calls for the cabins are correctly allocated. Thiscan be difficult, e.g. when a request for transportation from the lowest to thehighest level is send to the system since the cabins cannot cross each other and atransfer between cabins is considered too inconvenient for the passenger. For thisspecial use-case a TWINR© system always incorporates an additional conventionalelevator shaft.

The architecture and requirements for a TWINR© system will be discussed in furtherdetail in the sections where we present the models.The choice for TWINR© was inspired by a paper from Kammüller and Preibusch [KP07].They use symbolic model checking to verify a TWINR© system. But at some points thepaper lacks of motivations for design decisions and statements and also seems to neglectthe aspect of communication.By using the capabilities of Hugo and UML as notation of choice we will try to make amore standardized approach and more clearly show the necessary steps in model checking.Due to the lack of a technical specification for the TWINR© system our approach will alsobe quite general and focus on main concepts that have to be considered when controllingtwo 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 orientatedModels. Though UML hast vast amounts of notations concerning static and dynamicpresentations of a system, we will mostly use the notation for state machines. Figure 2.1show an example of a state machine. The choice for this notation comes mostly fromthe 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 usedin 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 givenspecification. Compared to testing and simulation, model checking doest not only coverparts of a systems behavior but every possible state that can be reached and is relevantwith regard to the specification. It conducts ans exhaustive exploration of all possiblebehavior. It is usually applied on reactive concurrent systems (e.g. communicationprotocols, digital circuits).Compared to other formal verification techniques (e.g. interactive verification) modelchecking has two big advantages:

• The verification of a model is fully automatic. Once the model and specificationare available in format readable by some model checker the verification does notrequire further supervision.

• In case the specification is violated model checking delivers a counter exampledescribing the faulty behavior. This trace shows every step from initialization tothe error and so usually provides good insight to where the model might have tobe 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, whenmodeled naively, can produce such a huge state space that computational limits areexceeded. 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 infinitestate space. So one has to apply abstraction to find an adequate discrete presentationwhich still shows the behavior one wants to verify. In the discussion of our models thoughwhen this is achieved further abstraction and limitation of behavior may be required tomake verification feasible.

2.3 Hugo/RT

Hugo [Kna07a] is a tool which supports verification of UML models. For this task it takesa representation of an UML model, either XMI, ArgoUML or UTE, and translates it tothe system language of a model checker or theorem prover which then performs the actualverification. 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 codegeneration into Java and SystemC.

2.3. HUGO/RT 5

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

We used UTE [Kna07b] a proprietary textual UML nation which supports modeling ofactive classes with state machines, collaborations and interactions. Compared to theother formats UTE reflects all UML features Hugo supports and and also is easier tohandle when one is used to textual modeling.As underlying tool we used the the on-the-fly, LTL model SPIN [Hol03]. It supportsPROMELA (PROcess MEta LAnguage) a high level language for describing softwaresystems. Hugo translates each class of the given model to a process of the PROMELAlanguage together with the the event and transition handling conforming to the UMLsemantics. One could compare it to using a scaffold which handles events and transitionsof 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 weused the information publicly available from ThyssenKrupp [Thy07b] and from [KP07].We modeled a complete elevator system with all its components as one might do duringthe analysis or design phase of a software development process that precedes the actualimplementation of the software components of an actual TWIN elevator system. In doingso, we attempted to show how easily the models created in the development process couldalso be used for verification.But although we tried to reduce the state space that resulted from translating the UMLmodel to model checker input formats in several ways, first verification attempts alreadyindicated that such a model had too big a state space to be checked with availablecomputational resources. Still we think that the creation process of this exhaustivemodel proved meritful, especially as analysis of the various sub-models involved helpedto find several points at which we could abstract from a direct model. This proved helpfulto identify and understand the core elements of the system which need to be included ina 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 aDSC is positioned at each floor. It accepts the destination wishes of the passengersand sends those transport requests to the MCU.

• the Main Control Unit (MCU) is responsible for handling incoming requests. Itchooses 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 maintaininformation 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 thecabin. Once a cabin has completed its movement it sends a completion signal tothe MCU.

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

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

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

The UML class diagram of a TWIN elevator system is shown in figure 3.1As 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, theinput format of Hugo/RT, which so far provides no notation for expressing inheritance.Concerning model checking one has to deliberate whether the components not directlyrequired for verification should also be modeled. We excluded those components thathave no direct impact on the safety of the TWIN system (like the doors) in our secondmodel to significantly reduce the state space.The goal of our model is to simulate a real systems behavior in the processing of requestsand the ensuring of safety measures. To do so, a minimal TWIN system configurationwhich has one conventional and one TWIN-shaft are sufficient. Adding additional shaftswould not change the basic behavior of the system since it would not enable the systemprocess transportation requests which could not be handled before. It would only enableto increase throughput. Though this might seem desirable one has to keep in mind thatfor model checking a minimal state space is far more desirable, since a too complex modelmight have larger computational needs for verification than available.Since for conventional model checking a discrete system is required (non-discrete systemscan be checked by specialized model checkers, but for physical systems, most propertiesare undecidable and require severe simplifications, c.f. [HH]) and we also need to keepthe 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 problemsize but also brings benefits modeling request processing and cabin movement.

• We do not model cabin acceleration, meaning the cabins start moving and stopabruptly. This is a direct result from the above and greatly simplifies movementmodeling since now it simply becomes a matter of performing a transition intoanother.

• 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 statetransitions occur independent of a notion of duration.

In the first model that incorporates the abstractions mentioned, we chose to model 11levels 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 , whichmodels asynchronous communication. In a first attempt, modeling the communicationwith synchronous operation calls resulted in undesired blocking behavior.In the following section we will describe how we modeled the single components and theirbehavior in more detail.


3.1.1 DSC

In our model the DSC represents the input which comes from the passengers. For thiswe abstracted from the concept of having one DSC per level, but chose to model onesingle DSC for the entire TWIN system which represents the behavior of the actual 12DSCs which send their requests to the MCU in an interleaved way. This is justified bythe assumption that the MCU stores incoming requests in a queue which it operates in aFIFO (first in first out) fashion. We made this assumption because it seems reasonablethat the MCU only checks and dispatches one request at a time, which greatly facilitatescreating an algorithm for choosing a cabin, but does not significantly decrease perfor-mance because the time required for computation may be considered many magnitudessmaller 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 theorigin and destination of the request and then sends it to the MCU, thus modelingrandom requests generated by the passengers (which are not modeled).

The DSC constantly switches between these two states and thus simulates a never endingflow of passengers requesting all possible floor combinations. After some simulations runswe realized that this has some major disadvantages, which led to a throughout redesignof the DSC in our second model. The MCU gets flooded with requests even while it is notcapable of handling them, and more important this approach neglects the opportunity togreatly reducing state space without providing a significant safety-critical for verification.


Figure 3.2: DSC state and send entry activity


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 processingrequests and then also one for each cabin.

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

The WorkQueue region is responsible for storing requests in the queue and processingthem. 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 specificalgorithm which might change over time, e.g. due to optimization. We implement somerestrictions, though. We always pick the oldest request (first in the queue) that can behandled 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 beprocessed. For this we evaluate the following expressing for each request, indicatingif 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 ifa 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 anddestination of the request.

Choose Cabin Once a request that can be handled is chosen pick a cabin and dispatchit. For this we basically use the same expression as above to determine whichcabin can handle the request and then nondeterministically dispatch one by storing


the request parameters for that cabin and calling the MCU’s internal dispatchreception. In case of the TWIN cabins we also store highest (resp. lowest) levelto be reached during processing in lowerTarget (resp. upperTarget). This isnecessary to ensure that later requests are chosen correctly without forcing a crossover of the cabins or similar invalid behavior.

Dequeue Request Finally we have to dequeue the request. If the queue was full, weinform 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 incomingrequest but it introduces a severe problem for the actual model checking: due to thenature of queues the state space is greatly increased since during model checking everypossible permutation of possible requests creates a distinct state. The majority of theserequests are currently not being processed and therefore do not greatly effect the behaviorrelevant 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 modeledwithout queues.

In the three regions to manage the cabin movement the MCU keeps the cabins in avacant status until a internal dispatch call for the cabin is received. During processingthis call it checks if the cabin is already at the requests origin level, in which case itsends it directly to the destination level. Otherwise the cabin is first send to pickup thepassenger. It does so by sending a send call to the shaft holding the cabin. For safetyreasons the shaft may deny the call in case it finds a safety violation, e.g. a call for theupper TWIN cabin to move down even though both cabins are not allowed to furtherclose in on each other.Once a cabin has completed its movement its shaft notifies the MCU, which then eithersends it to the destination marks it as available again, depending on the state of thecabin (pickup or deliver).Additionally, the regions for the TWIN cabins can also reach an exit point due to theshaft containing them signals that the cabins have been stopped due to some safetyviolation. This marks them as unavailable so they are not further considered for requesthandling. We did not model this for the conventional cabin since they are a well knownconcept 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 onlymove with limited speed.

• In case the cabins go below a minimal distance, which could lead to a crash if thecabins keep moving, the shaft has to engage the brakes of the cabins. This way thecabins come to a controlled stop.


Figure 3.3: MCU state machine


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 ThyssenKruppmarketing web site. E.g., we could not find a reason for modeling a safety catch inaddition to the brakes since no circumstances are described in which the brakes mightfail. Therefore we decided to abstract from that and only model that the brakes are tobe 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 callis received it checks if the call is valid, e.g. in case of the lower cabin following expressionhas 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 0and 10. The expression for the upper cabin is analogous. If this expression evaluates tofalse 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 wasfor and if the other cabin is already moving the region transitions to a state representingthe 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 whichare 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 MCUby issuing a cabinDone call and again transitions to a state representing the currentmovement 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 safedistance threshold it tells them to slow down and once they return to safe distance tospeed up again.A critical situation arises when the cabins go below the minimal distance where furthermovement 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 theirbrakes, 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 therebyrendered inactive.


Figure 3.4: TWIN shaft state machine


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 stationarystate where it waits for incoming calls. Though stationary it has to handle incomingslowDown and speedUp calls from its holding shaft, so once it starts its movement itknows which is its currently allowed speed. On an incoming goto call it first closes itsdoor and then, depending on its current position and target, starts and up- or downwardmovement. During the movement it can receive slowDown or speedUp calls which tellsit to adjust its current speed. In case of a slowDown it reduces its movement to one levelper step and in case of a speedUp it increases it to two levels. On reaching the target itopens 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 onlyoccur with closed doors. Also we wanted to leave the possibility open to later includemodeling 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 theshaft it tells its brakes to engage and waits for a stopped as confirmation. Once thecabin is stopped it ensures that its doors are opened so passengers can safely leave thecabin.

Figure 3.5: TWIN cabin state machine


3.1.5 Other components

For the remaining components we will only show the state machine diagrams since theyare 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 problemsregarding the computational limits to verify this first model. In an early verificationrun, using bistate hashing to reduce memory usage, we already reached a state space ofover 750 million even though we did not fully cover the model as was indicated by codecoverage reported by SPIN. Still we analyzed the model using SPIN’s simulation modeto find out where problems arose and where could apply further abstraction.As already mentioned our first discovery was that the queue, though a common techniquein 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 thequeue ourselves. This was pretty straight forward but artificially increased state spacesince we had to model every single step of queue management which SPIN would handleinternally when using queues from PROMELA. Second there was the problem of thequeue itself. In many situations we observed during the simulations the queue was filledto its maximum. But since those requests in a queue are relevant for the future behaviorof 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 immediatelybut continue to send requests until the event queues, created by the Hugo translationto PROMELA, would also fill up increasing state space even further. Third due to theincreased number of operations performed it partially became hard to follow the relevantbehavior of the system when analyzing the simulation trails.

Another source which increased the state space was overhead which is caused by UML


Figure 3.7: conventional Cabin state machine

Figure 3.8: TWIN and coventional door state machine

Figure 3.9: TWIN brakes state machine


state machines and restrictions by the UTE syntax. For example the position updatesfrom the cabins to the shafts has to be modeled calling a reception or operation sincetheir is no way to directly access the variables of an object. In PROMELA one couldoptimize 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 acomponent 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 fortranslating UML state machines to PROMELA which again limits the possibilities toapply model specific optimizations. And applying such optimizations after the the trans-lation, the PROMELA code automatically generated by Hugo turned out to be an almostimpossible task.

After these insights we arrived at the realization that directly verifying a UML model ofthis size is not yet feasible. Hence we decided to make a second approach by designingthe 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 aTWIN system in PROMELA. This approach brought us several advantages:

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

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

Language specific constructs PROMELA provides constructs such as d_step andatomic which steer the interleaving of concurrent processes and allow for majordecreases in required states, since many interleaving sequences are ruled out. Al-though the PROMELA code as generated by Hugo/RT contains atomic to modelthat 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 disableinterleaving, 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 respectto 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 noweach single step during state transitions can be easily followed. Whith Hugo/RTsuch 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 TWINsystem 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 relativeto the TWIN cabins in combination with the distances between them and the top andbottom levels of the shaft. This does not only help to reduce state space but also madethe 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 thebottom resp. top level of a shaft. uTL represents the area beneath and oTL the positionat 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 distancebetween 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 thefollowing values cSAFE, cMINIMAL, cUNSAFE, cCRASH with cMINIMAL being theminimal distance between both cabins allowed while operating. Distance to bottom andtop level can be sSAFE, sREACHED, sCRASH where sREACHED is the situation wherethe 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 arequest from for example level 8 to level 4 anymore, but similar behavior can modeled inusing the relative levels depending on the current state of the system as shown for someexample in figure 3.11. In a in Figure 3.11 the the request would be similar to a bTC tobTC request and in both models this request could be handled by any cabin. b shows asituation where in both models only the upper and conventional cabin could handle therequest. In c and d only the conventional cabin could handle the request. In c this isobvious and in d the upper cabin could not handle the request because the cabins are inminimal 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 upperand twin cabin in our first model, but by mapping it to bTC to bTC we have the samesituation as in a. But all requests in the more abstract relative notation can be mappedto a request in the more concrete first model.But the new way of modeling has consequences for other aspects of the model. Movementcannot longer happen by moving up or down one level at a time, because e.g. oTL always


Figure 3.10: relative positions

represents the current position of the lower TWIN cabin. Instead of moving the cabinwe now have to change variables relevant the status of the system. For illustration wewill describe how we modeled the movement of the lower TWIN cabin on its way to thepickup 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. Incase distBTC was minimal (cMINIMAL) it must be set to cSAFE. In case it already wascSAFE nothing has to be changed.lowerDest is the destination point for the request currently handled by the lowerTWIN cabin. MCU are the pickup and destination points for the request currently beingprocessed by the MCU. If any of those variables point to the current position of the cabinit naturally has to be set to be to a value above it. Optionally a change from uTL tooTL may occur. The optional and required changes of a also apply in b and c not shownotherwise.In situation c we restricted the the pre-status of the system to prevent inconsistentbehavior. Otherwise those variables would have to be set to MIN or jump over oTLdirectly to bTC. By restricting that the cabin can only reach the bottom level when noother variable points to a position below or on it without being MIN easily eliminatessituations that would require special treatment.


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


Figure 3.12: lower TWIN cabin moving down


The upward movement of the lower cabin as well as the movement of the upper TWINcabin modeled similar as can be seen in the PROMELA code in the appendix.


3.2.2 Reducing components of the TWIN system

In addition to abstracting from the levels we also reduced the overall size of the systemby removing components which do not contribute behavior absolutely necessary.Because we focused on processing requests and cabin movement in the second modelwe first we disposed of the doors. Doors are a well known concept which do not showbehavior relevant for verification of TWIN system specific features. For similar reasonswe also removed explicit modeling of the conventional shaft and cabin. Both componentsare well known concepts and are only required to handle some specific requests whichthe TWIN cabins can not fulfill. Therefore we decided to treat requests which would bepassed 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 wealso to rid of the cabins. In the first model the cabins basic task was to handle the doorsand perform movement, but already in this model the shaft was monitoring the movementand enforcing safety. And because with the new model movement is no longer a singleincremental step which then propagates though the system, we used the possibility tointegrate 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 nowthe number orthogonal state regions was reduced and the number of states reachableinside 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 notalways be handled immediately which meant that such requests would have to be storedin the queue. So to reduce this kind of behavior we restricted the transport requeststhat the DSC produces dependent to the current state of the system. Because we nolonger explicitly model the conventional shaft and cabin we mostly prevent the DSC fromcreating 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 notcurrently processing another request. Also setting the pickup to MIN does not make sensewhen the lower cabin is already at the bottom of the shaft and the distance between thecabins is cMINIMAL because this would result in a request that could only be handled bythe conventional cabin. We use the following statement for nondeterministically selectingthe pickup level:


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 anotherrequest. This does not disable the capability for more than one request being handledbecause only selecting and dispatching the cabin is done one request at a time, as in thefirst 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 reducedto three orthogonal regions. The regions for the TWIN cabin are basically the same butdue to a change with the TWIN shaft we will discuss later, the exit transitions due toa stopped cabin have been removed. The other region handles communication with theDSC. It waits for an incoming request and on reception transitions to a state where itchecks the request and dispatches a cabin. Instead of using internal calls to trigger thedispatch of a cabin, we internally enable the firing of the needed transition. Though thisis not strictly UML conformant it helped to simplify the model. See figure 3.14 for thestate machine.We also modified the process for selecting a cabin to handle a request. Instead of makingan full nondeterministic choice we applied priorities to the cabins. We decided that was


Figure 3.13: redesigned DSC state machine

because this way we could down-size state space, without greatly modifying the possiblebehavior, also it seems reasonable that in a concrete realization some kind of prioritywould 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 onlyholds when all three cabins could handle the request, in case a cabin cannot currentlyhandle the request it drops out of the priority order.Though the conventional shaft appears here we do not model it. It is only required tohandle a few cases in which none of the other could handle the request. Such requestsare simply fulfilled once they have been appointed to the conventional cabin. For furtherstudies it would be interesting to see if one could completely remove the conventionalpart from the model.

The changes for the TWIN shaft are the most significant ones we discussed above. Itmodels the new movement paradigm discussed above and also holds changes regardingthe safety properties. Using relative positions makes modeling of braking pretty muchobsolete since cabins do not have any kind of speed and only their distance to eachother is modeled. So instead of modeling braking we decided to instead verify that therenever a situation arises where the distance between the cabins drops below cMINIMAL,a situation that would cause an emergency braking. The distance between the cabinscan only be reduced when the upper (resp. lower) cabin is moving down (resp. up). Thechoice happens nondeterministically.All these changes enabled us to reduce the TWIN shaft to two orthogonal regions. Onefor each cabin which responds to receptions of the MCU, performs the abstract movementand once the target floor is reached it signals this event to the MCU. Reaching (resp. notreaching) the target is again modeled by internally enabling corresponding transitionsto be fired. Also, to reduce redundancy of storing the target for the cabins locally,


Figure 3.14: redesigned MCU state machine


lowerTarget and upperTarget actually represent the pickup or destination storedin the MCU for the cabins current request, depending on if the cabin is going to itspickup 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 andrestrict behavior. Though one might argue that this is no longer a TWIM system, wethink 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 ofa TWIN system, but we can show that without regard to the number of levels or specificvelocities 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 greateror 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 toapproximately 4 million and fully covered the model since SPIN did not report unreachedcode.

Chapter 4

Conclusion

The approach to directly verify the UML models created during analysis and design holdsgreat potential, since it is based on a widely know notation and can uses artifacts whichin most software development processes are created any why.As our first model showed such a direct approach is currently not quite feasible. Thestate space a naive UML approach generates is just too big because usually not enoughabstraction 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 itreaches a checkable size produces results which enable the verification of basic systembehavior.The UML provides a scaffold for simply creating models in a familiar way. But the factthat the semantics of the UML for handling requests and transitions cause a significantoverhead without adding system specific desired behavior poses a problem. State spaceis increased because even in cases of small system changes we might have to create aserious 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 agood 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 TechnologyTool, 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/. visited14.08.2007

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

[KP07] Kammüller, F. ; Preibusch, S. An Industrial Application of Symbolic ModelChecking – 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 andFixing 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. visited14.08.2007

[Thy07b] ThyssenKrupp. http://www.thyssenkrupp-aufzuege.de/default.asp?id=75&nid=161. visited 14.08.2007

33

Date post:	03-Jul-2015
Category:	Documents
Upload:	blackjet2740
View:	132 times
Download:	1 times

Thesis

Documents