Uppaal

Model Checking
with UPPAAL
Ulrik Hørlyk Hjort
Ulrik.H.Hjort@BestPractice-Consulting.com
BestPractice Consulting
—
Thursday 31st May, 2012

Background
Ulrik Hørlyk Hjort
Safety Critical and High Integrity system development since
1997
Defence industry from 1997
Space industry from 2003
Medical industry from 2006
Formal software development since 2003
VDM, Z, B-Method and UPPAAL
Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC
Model Checking

Overview
Use of Model Checking to add value to traditional testing.
Model Checking

Traditional Testing
Testing involves running a program with a set of inputs and
comparing the actual outputs from the program against the
expected outputs (as deﬁned in the speciﬁcation).
There are several limitations to using testing as the sole
approach to software error detection:
Model Checking

Testing Limitations
Testing cannot take place until some implementation is
available.
Correcting errors uncovered by testing could involve retracing
many steps and undoing work previously done.
If testing is the only approach to error detection then errors in
the speciﬁcation involve the greatest amount of work to
rectify.
Model Checking

Testing Limitations
Testing can only help to uncover errors it cannot guarantee
the absence of them.
Since, for any application, it is impossible to test every set of
input values, residual errors will always have to be accepted.
Model Checking

Testing Limitations
Testing is always carried out with respect to requirements as
laid down in the speciﬁcation.
If the speciﬁcation document is in any way ambiguous it is
open to interpretation, and hence misinterpretation, making
testing a rather inexact science.
Model Checking

Ambiguous Speciﬁcation
Model Checking

Testing Problems
Clearly the specification plays a vital role in the reliability of
the software produced.
The design, and subsequent implementation, is based upon
the information in the specification.
The testing process relies upon the developers understanding
of the specification to determine whether or not the software
is behaving correctly.
Misunderstandings in the specification can lead to the delivery
of final applications that do not match user requirements.
Model Checking

Formal Methods
A formal method provides a formal language in which to
express the initial specification and all future design steps
towards the final program in a unambiguous way.
More than just a specification language —it also includes a
proof system for demonstrating that each design step
preserves the formal meaning captured in the previous step.
Model Checking

Formal Methods advantages
The discipline required in producing a formal specification of
user requirements and the ability to analyse a specification
(which only arises if the specification language has a
well-defined semantics) allows for feedback on system
specifications at early development stages, increasing
confidence that the specification accurately captures the real
system requirements.
Model Checking

Important properties (such as internal consistency) of the
initial speciﬁcation can be checked mathematically and
incorporated as run-time checks in the ﬁnal program.
Model Checking

Proofs can help uncover design errors as soon as they are
made, rather than having to wait for testing of the ﬁnal
implementation.
Model Checking

A proof of program correctness can be constructed that is a
much more robust method of achieving program correctness
than is testing alone.
Model Checking

Formal speciﬁcations can help considerably in generating
suitable test cases.
Model Checking

Model Checking
In a model-based approach an abstract mathematical model is
built of the data, using abstract mathematical types such as
sets and abstract state machines.
The behaviour of the operations is then speciﬁed directly with
respect to this model.
Model Checking

The UPPAAL System
Integrated tool environment for:
System Modelling
Simulation of the model
Veriﬁcation of the model
Model Checking

The System Editor
The system editor is used to create and edit the system model
to be analyzed
A system model describe a network of a ﬁnite number of
non-deterministic ﬁnite state automata
Edges between states may be labeled with:
Guards
Synchronizations
Assignment statements
Model Checking

UPPAAL Model Items
Initial Location
Location
Edge
Synchronization
Model Checking

UPPAAL Model Items
class _Factorial {
int result;
public void Factorial()
{
for (int i = result-1; i > 1; i--) {
result *= i;
}
}
public _Factorial()
{
result = 5;
}
public voidShowResult()
{
System.out.println("Result:" + result);
}
public static void main(String args[])
{
_Factorial fac = new _Factorial();
fac.Factorial();
fac.ShowResult();
}
}
Model Checking

UPPAAL Model Items Subprogram Synchronization
class Hello {
private void Put_Line()
{
System.out.println("Hello World!n");
}
public Hello()
{
Put_Line();
}
{
Hello hello = new Hello();
}
}
Model Checking

UPPAAL Model Items Ada Tasks
task body TaskA is
begin
TaskB.WriteTaskName;
end TaskA;
task body TaskB is
begin
accept WriteTaskName do
Put_Line("Task B");
end WriteTaskName;
end TaskB;
Model Checking

UPPAAL Model Items Parametrised Synchronization
class Factorial {
int result;
public int Factorial(int N)
{
int result = 1;
for (int i = N; i > 1; i--) {
result *= i;
}
return result;
}
{
Factorial fac = new Factorial();
int result = fac.Factorial(5);
System.out.println(result);
}
}
Model Checking

The Model Checker (Verifier)
The main purpose of a model checker is to verify the model
with respect to a requirement specification.
Like the model, the requirement specification must be
expressed in a formally well-defined and machine readable
language.
The model checker support three path formulae expressed by
temporal logic quantifiers:
Reachability : Is the state formular ϕ satisfied from any
reachable state ?
Safety : ϕ is invariantly true in all reachable states
Liveness : ϕ is eventually sastified
Model Checking

Quantiﬁers
E : There exists a path
A : For all paths
G (♦ in UPPAAL) : All states in a path
F ( in UPPAAL) : Some states in a path
The following combinations are supported: A , A♦, E♦, and E
Model Checking

Reachability Properties: E ϕ “ϕ Reachable”
E ϕ: It is possible from the initial state to reach a state in
which ϕ is satisﬁed
ϕ is true in at least one reachable state
Model Checking

Safety Properties: A ϕ “Invariantly ϕ”
A ϕ: ϕ holds invariantly
ϕ is true in all reachable states
Model Checking

Liveness Properties: A ♦ ϕ “Inevitable ϕ”
A ♦ ϕ: ϕ will inevitable become true
The automaton is guaranteed to eventually reach a state in
which ϕ is true
ϕ is true in some states of all paths
Model Checking

E ϕ “Potentially always ϕ”
E ϕ: ϕ is potentially always true
There exists a path in which ϕ is true in all states
Model Checking

The Simulator
The simulator can be used in three ways:
Running the system manually and manually choose the
transitions to take
Going through a trace generated by the veriﬁer
Running the system at is own in random mode
Model Checking

ATM System
E X A M P L E
Model Checking

Actors: Customer, Bank
System: ATM
Model Checking

Customer
Model Checking

ATM
Model Checking

Bank
Model Checking

ATM System
Requirements:
1 Transaction is only valid with a bank balance greater than 10
euro
2 Customer gets cash when transaction is done
3 System may not be able to enter a deadlock state
Model Checking

Requirement 1
Transaction is only valid with a bank balance greater than 10
euro
A (Customer.READY and Bank.TRANSACTION OK)
imply Bank.balance >10
Model Checking

Requirement 2
Customer gets cash when transaction is done
E ♦ Customer.GET CASH and Bank.TRANSACTION DONE
Model Checking

Requirement 3
System may not be able to enter a deadlock state
A not deadlock
Model Checking

System
Automatic test of requirements and MMI flow of insulin pump
Javascript with user actions commands and verification of
expected result of these
First manually written from UML diagrams, MMI flows and
requirements
Model Checking

System
UPPAAL model made from UML diagrams, MMI ﬂows and
requirements
UPPAAL system locations was annotated with test script
actions
Full coverages paths of the model found by veriﬁer
A full coverage package of test Javascript generated from the
model
Model Checking

System
Model Checking

Test script example
expect_mainScreen() {
expect(Label(Welcome);
expect(Label(BatteryIndicator);
}
expect_callScreen() {
expect(Label(Calling ...);
}
// Main Script:
expect_mainScreen();
insert_card()
expect_enter_pincode_screen();
key(5);
expect(5);
key(1);
expect(1);
expect_trasactionscreen();
.
.
.
Model Checking

Uppaal

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Uppaal

Ähnlich wie Uppaal (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Uppaal