Formal Verification with UPPAAL

8/13/2019 Formal Verification with UPPAAL

1/17

Budapest University of Technology and Economics

Department of Measurement and Information Systems

Fault Tolerant Systems Research Group

Critical Embedded Systems

Formal modelling and verification in UPPAALReport homework

Pablo Henrique Antunes Silva

11. November 2013

Student funded by CAPES - Brazil


2/17

Formal modelling and verification

1 INTRODUCTIONIt is long known that problems in software can cause serious accidents including human and economic

cost. Therefore is very important use technics that can provide a correct verification in the no software

and find whether one is free of bugs.Ariane-51 is an example of the simple error in a software can cause.

Therefore this report covers techniques and tools necessary to create a formal modeling and verification

of software. Throughout the text will be specified a protocol for mutual exclusion between threads and

UPPAAL will be used to create such model.

2 MODELING WITH UPPALLUPPAAL is an integrated tool environment for modeling, validation and verification of real-time systems

modeled as networks of timed automata, extended with data types. The tool is developed in collaboration

between the Department of Information Technology at Uppsala University, Sweden and the Department

of Computer Science at Aalborg University in Denmark. In order to understand the techniques used in this

work some specification about UPPAAL will be covered below.

2.1 UPPAALGUI GRAPHICAL USER INTERFACE)REFERENCEUPPAAL allowed us to create an abstraction of some problem that we need deal with in the form of an

automata. Figure 1 show the workspace of the UPPAAL we use to create such automata. In order to

create our protocol on UPPAAL we had to use the mainly part of GUI such as the canvas (where we draw

the automata) and the project explorer (where we declare the variables and/or create new templates).

All elements and declarations used will be explained late on. The next sessions will cover a brief summary

of the GUI elements of the UPPAAL.

2.2 MODELING WITH AUTOMATA AND TIMED AUTOMATAIn UPPAAL it is possible create an abstraction of our protocol thought of an automata timed or no such

as one of the figure 2:

1more information in:http://en.wikipedia.org/wiki/Ariane_5; http://www.uppaal.org/
http://en.wikipedia.org/wiki/Ariane_5http://en.wikipedia.org/wiki/Ariane_5http://en.wikipedia.org/wiki/Ariane_5


3/17

Figure1 UPPAAL GUI

Figure 2 - Automata timed create in UPPALL

1Quote of the Short UPPAAL introduction Andrs Voros 13/10/13


4/17

That automata is compounds by the following elements for our case:

Locations1 They have a name, only one of them is active at a certain time point (Figure 3). Inside

of a location we can find a menu where it is possible modify some features of such location such

as name, invariants (which means in each reachable state it be true that), initial state and others

features (Figure 3).

Edges1they represent the possible state changes of the system (Figure3), guards and actions

can be assigned to them through an internal menu (Figure 3).

Figure 3 A location and its internal menu and an edge and its internal menu respectively

2.3 DECLARATIONSAll variables declared in the automata should be declared in the system too. For this, we use the section

declarations. A variable could be a clock or no and could be global or local. (Figure 4).

Figure 4 Declarations of variables and clocks.

1Quote of the Short UPPAAL introduction Andrs Voros 13/10/13


5/17

2.4 SYSTEM DECLARATIONSFinally we have a system declarations. In this section we can create instances and all process that will be

compound our system. Here we can also pass variables as parameters for our processes (Figure 5).

Figure 5 System Declarations

3 THE PROBLEM OF THE MUTUAL EXCLUSIONThe problem which needed to be solved is the following:

Engineers implemented the following protocol in an operating system to ensure the mutual

exclusion so that no two threads are in their critical section at the same time, no two threads access

to a shared resource simultaneously. In order to ensure this property, the designers implemented a

controller, which handles the requests and lets the threads to enter their critical section.

The working of the protocol is the following. When the operating system is started, it creates two binary

(Boolean) variables for each thread in the memory. Thread i will use these two variables ri and gi to

communicate with the controller. These variables are initialized to FALSE. Thread i sets the value of

variable ri to TRUE if it wants to enter the critical section. The controller can read the variable r of every

thread. If the controller recognizes that thread i has set its variable ri to TRUE, it can grant the right for

thread i to enter the critical section by setting the variable gi of thread i to TRUE. The thread periodically

checks if its variable g had been set TRUE, then the thread enters its critical section and uses the shared

resources. When thread i leaves the critical section, it sets the variable ri to FALSE and it proceeds with


6/17

its normal working. The controller periodically checks the variable ri, and if it is FALSE, it drawbacks the

grant from thread i by setting variable gi to FALSE.

The implementations are the following (pseudo) codes. Each line is an atomic operation in itself.

threadi controller1 other activity

2 ri := TRUE

3 wait until gi = TRUE4 critical section

5 ri := FALSE6 GO TO 1

1 wait until at least one ri is TRUE

2 let c be such that rc = TRUE

3 gc := TRUE

4 wait until rc = FALSE

5 gc := FALSE6 GO TO 1

If more than one thread set their variables ri to TRUE, the controller chooses not deterministically from

them (in line 2 of controller).

Let assume that our operating system runs 3 threads and one controller.

From the proposed problem we create two types of formal models: one with and one without time.

Furthermore we also should have done the formal verification of the models created in order to verify the

followings properties:

1. The model does not have deadlock?

2. Is it possible for every thread to enter their critical section?

3. Is it true that at most one of the threads can be in the critical section?

4. Is the system starvation and live lock free?

3.1 PHASE 1:MODELING NO TIMED AUTOMATAAccording to the pseudo codes we created the automata showings in the Figure 6 and Figure 7.


7/17

Figure 6 Automata that represents a Thread in our system

Figure 7 Automata that represents a Controller in our system

The rest of this section will be used to explain the logic applied in both automata.

3.1.1 Abstracting ThreadTo create the Thread automata the following logic was applied: we have three locations idle,

wait_autorization and critical_section. Initially the thread is idle and in determinate time it need to enter

on critical section and how as describe in the pseudo-code need to change the value of the variable r_ti

for true. Done that, then the thread goes to the location wait_autorization. Once in this state, the thread

need to wait until the controller change the value of its variable g_ti and so this happens it is allowed to


8/17

go for critical_section. After use the critical_section it goes to idle again and then its variable r_ti is

changed for false too. We can see that exists a directly relation with the controller how was requested.

3.1.2 Abstracting ControllerTo formalize the second part of our protocol, we have created a Controller automata and we used thefollowing logic: it have six locations idle, r_status, next_thr, acess_granted, wait and access_danied.

Firstly the controller is idle (initial state) then starts selecting not deterministically a Thread to give access

to the critical section and then goes to the r_status. In this location it need check if the Thread it have

chosen need access to the critical section. If yes the controller follows to the access_granted and this

make that value of the variable g_ti change for true ensuring the thread selected enter to the critical

section. When the controller is in such state, it has to wait until that the thread finish its processing on the

critical section and then when the controller verify and see that the variable r_ti of that thread has the

value false, it change for the state acess_danied and finally stay idle again changing the value of variable

g_ti to false what causes the thread in question has no more access to the critical section. And therefore

we can see again the relation with the thread and the controller how was expected to see.

3.1.3 Local, global and system declarationsThe section 2.3 talks about the declarations on GUI of UPPAAL. In order to finalize our model we have to

declare all variables that were created in ours automata. For this first case we didnt have to use local

variable once that we need our variables to be global because one automata has a directly relation with

another one. Thus our system is compounds of the following variables and instances:

Local declarations:

o int t

Receive the choice of the select, which means which thread the controller choose.

Global declarations:

o bool g_ti[3]

o bool r_ti[3]

The length of both arrays is the number of threads of our system have.

System declarations

o Instantiations

Thread1 = Threads(0);



9/17


Control = Controller();

o Processes

systemThread1, Thread2, Thread3, Control;

The instantiations are the number of threads we have and the controller respectively.

3.2 PHASE 2:MODELING TIMED AUTOMATAIn this phase we have the same elements, an automata that represents threads and other one that

represents a controller. Here what is different is that now we have clocks and invariants in both automata.

This is an important feature that permit us to handle models of real time systems. The clock variables has

some properties: its values increase monotonically and we can reset them explicitly; the system may stay

in a state for arbitrarily long (but finite) time or can step further immediately (staying in a state for 0 time

unit). The control under this kind of variables could be done with invariants, guards and special states.

Invariants guaranty certain minimum time of processing in a state that contains it. Figures 8 and 9 show

the new automata with modifications to include time expressions between the locations for the thread

automata and controller automata respectively.

Figure 8 Timed automata that represents a Thread in our real time system


10/17

Figure 9 Timed automata that represents a Controller in our real time system

We can see on the figures above that some changes had to be done in both automata. In the first one we

have had to create a new location processing because now each thread need to eight seconds to

processing the information acquired on the critical section and just after that, it can request for access to

the critical section again. There are also changes in the edges that now they have specific guards to control

the transitions from the time spent in each state. As we know, each action of each thread need 1 unit of

time to processing and because this some transitions have guards to just allowed the automata go from

one state to another when the clock variable reach minimum one unit of time and after that the clock

variable is reset to be possible to continue the process, therefore for can control this behavior we have

created invariants that determines our system stay in a state in the maximum 1 unit of time. Finally we

can see that each thread need to stay on critical section at least 8 unit of time and at most 10 unit of time

because we have a guard that guaranty this feature and we can forget that in the initial state idle the clock

variable is reset in order to start all process again.


11/17

In the second one we have some changes only in the transitions, no state was needed to be created

because we just needed put time in the operations of the controller and not create nothing new. Like in

the first one some guards and invariants was putted there to control the time between actions. As we

know each action of the controller need 2 unit of time to processing and this was guaranty with those

guards and invariants. Moreover the clock variable was reset between transitions to avoid deadlock and

also to create a cycle of execution. Figures 10 and 11 show where the clock variables were declared for

the thread automata and for the controller automata respectively, remembering that such variables are

locals.

Figure 10 Declaration of the clock variable for the thread automata

Figure 11 Declaration of the clock variable for the controller automata

4 SIMULATORAfter model ours two systems (one with time and another one without) we used the simulator to make

some tests and see if our system was apparently work. In this time we have had not make the

verifications yet, we just wanted to certify if the system works doesnt mattering if was the right or

wrong way. We can see on Figures 12 and 13 the screen execution of both system.

5 VERIFICATIONFinally we have done the formal verification of our model. In UPPAAL we have the following operatorsand some characters that we can combine and make some queries:

Operator Informal Semantics UPPAAL notation

AG For all paths,

For all states

A[]


12/17

AF For all paths, For a state

eventually

A

EG For an existing path, For all

states

E[]

EF For an existing path, For a state

eventually

E

AG( => AF ) After always -->

There is no deadlock A[] not deadlock

To verify we can create logical queries in UPPAAL using this table as reference. We have had to

deal with for kind of problem that our system could pass to. To verify the following problems

we have created the following queries in according to the table:

Deadlock?

A[] not deadlock

Is it possible for every thread to enter their critical section?

E Thread1.critical_section



It is true that at most one of the threads can be in the critical section? Correctness.

A[] not (Thread1.critical_section & Thread2.critical_section & Thread3.critical_section)

Starvation?

Thread1.wait_autorization --> Thread1.critical_section



Live lock?

(Thread1.wait_autorization & Thread2.wait_autorization & Thread3.wait_autorization)

--> (Thread1.critical_section | Thread2.critical_section | Thread3.critical_section)


13/17

5.1 RESULTS5.1.1 No timed system

Figure 12 show the screen result for our verification on the no timed system:

Figure 12 Screen result for verification of the no timed system

After each verification its possible see one counter-example for each query that it is not satisfied in our

system. Analyzing the figure 12 we can see that that our system doesnt satisfy the following properties:

Live lock (figure 13):


14/17

Figure 13 Counter-example for live lock

Starvation (will be expose just one example for the first thread, figure 14):

Figure 14 Counter-example for starvation Thread 1

Correctness (Race conditions, Figure 15):

Figure 15 Counter-example for correctness


15/17

For all these results we can conclude that the protocol implemented it is not efficient because presents

some serious errors. The verification is very important to see how our system works or if some problem

with it has. After made these verifications we have done the same ones for our real time system in order

to see if the time could be fix all or part of our problems. Next section covers it.

5.1.2 Real timed systemDoing the same queries we obtained the following results showing in the figure 16:

Figure 16 Screen result for verification of the real timed system

We can see the counter-examples for the properties that not satisfied our queries:


16/17

Starvation (will be expose just one example for the first thread, figure 18):

Figure 18 Counter-example for starvation Thread 1


17/17

Analyzing the results, we can conclude that time is a good change to solve some of problems of the our

protocol. With guards and invariants is possible give to system some kind of pseudo-synchronization and

thus problems as live lock and no correctness were solved. Problems like starvation need of more logic in

our protocol to be solved because in this case it is not a time problem dependent but a logical problem

dependent.

6 CONCLUSIONSThis report presents a completely modeling of a protocol of mutual exclusion in an ambient of modeling

and formal verification: UPPAAL. It is very clear that make a formal verification of our software it is part

fundamental when we want to create critical embed systems. The formal verification show to us such kind

of problems that could be decisive in a system as critical one. Accidents, economic losses, serious damages

and a large lack of problems could happens if this kind of verification stay be hidden in our development.

The protocol implemented and verified in this work, in the first case was needed some kind of

synchronization to work correctly and the solution found was put time to control the evolution of

processing of our system. This alternative solved some important problems but our protocol not work

totally correctly yet because some problems depends on more logical than time. It is a simple example

about how could our software present a serious wrong behavior and how we can find and solve such

problem when we use formal verification. Finally we can conclude that the UPPAAL is a good tool to usein order to verify our critical software and the verification should always have done when we are talking

about critical embed systems.

Formal Verification with UPPAAL

Documents

Transcript of Formal Verification with UPPAAL