formal verification with uppaal
TRANSCRIPT
-
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
-
8/13/2019 Formal Verification with UPPAAL
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 -
8/13/2019 Formal Verification with UPPAAL
3/17
Figure1 UPPAAL GUI
Figure 2 - Automata timed create in UPPALL
1Quote of the Short UPPAAL introduction Andrs Voros 13/10/13
-
8/13/2019 Formal Verification with UPPAAL
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
-
8/13/2019 Formal Verification with UPPAAL
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
-
8/13/2019 Formal Verification with UPPAAL
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.
-
8/13/2019 Formal Verification with UPPAAL
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/13/2019 Formal Verification with UPPAAL
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);
Thread2 = Threads(1);
-
8/13/2019 Formal Verification with UPPAAL
9/17
Thread3 = Threads(2);
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
-
8/13/2019 Formal Verification with UPPAAL
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.
-
8/13/2019 Formal Verification with UPPAAL
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[]
-
8/13/2019 Formal Verification with UPPAAL
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
E Thread2.critical_section
E Thread3.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
Thread2.wait_autorization --> Thread2.critical_section
Thread3.wait_autorization --> Thread3.critical_section
Live lock?
(Thread1.wait_autorization & Thread2.wait_autorization & Thread3.wait_autorization)
--> (Thread1.critical_section | Thread2.critical_section | Thread3.critical_section)
-
8/13/2019 Formal Verification with UPPAAL
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):
-
8/13/2019 Formal Verification with UPPAAL
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
-
8/13/2019 Formal Verification with UPPAAL
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:
-
8/13/2019 Formal Verification with UPPAAL
16/17
Starvation (will be expose just one example for the first thread, figure 18):
Figure 18 Counter-example for starvation Thread 1
-
8/13/2019 Formal Verification with UPPAAL
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.