Uppaal

Model Checkingwith UPPAAL

Ulrik Hørlyk [email protected]

BestPractice Consulting—

Thursday 31st May, 2012

Background

Ulrik Hørlyk Hjort

Safety Critical and High Integrity system development since1997

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 [email protected] 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 andcomparing the actual outputs from the program against theexpected outputs (as defined in the specification).

There are several limitations to using testing as the soleapproach to software error detection:


Model Checking

Testing Limitations

Testing cannot take place until some implementation isavailable.

Correcting errors uncovered by testing could involve retracingmany steps and undoing work previously done.

If testing is the only approach to error detection then errors inthe specification involve the greatest amount of work torectify.


Model Checking

Testing Limitations

Testing can only help to uncover errors it cannot guaranteethe absence of them.

Since, for any application, it is impossible to test every set ofinput values, residual errors will always have to be accepted.


Model Checking

Testing Limitations

Testing is always carried out with respect to requirements aslaid down in the specification.

If the specification document is in any way ambiguous it isopen to interpretation, and hence misinterpretation, makingtesting a rather inexact science.


Model Checking

Ambiguous Specification


Model Checking

Testing Problems

Clearly the specification plays a vital role in the reliability ofthe software produced.

The design, and subsequent implementation, is based uponthe information in the specification.

The testing process relies upon the developers understandingof the specification to determine whether or not the softwareis behaving correctly.

Misunderstandings in the specification can lead to the deliveryof final applications that do not match user requirements.


Model Checking

Formal Methods

A formal method provides a formal language in which toexpress the initial specification and all future design stepstowards the final program in a unambiguous way.

More than just a specification language —it also includes aproof system for demonstrating that each design steppreserves the formal meaning captured in the previous step.


Model Checking

Formal Methods advantages

The discipline required in producing a formal specification ofuser requirements and the ability to analyse a specification(which only arises if the specification language has awell-defined semantics) allows for feedback on systemspecifications at early development stages, increasingconfidence that the specification accurately captures the realsystem requirements.


Model Checking


Important properties (such as internal consistency) of theinitial specification can be checked mathematically andincorporated as run-time checks in the final program.


Model Checking


Proofs can help uncover design errors as soon as they aremade, rather than having to wait for testing of the finalimplementation.


Model Checking


A proof of program correctness can be constructed that is amuch more robust method of achieving program correctnessthan is testing alone.


Model Checking


Formal specifications can help considerably in generatingsuitable test cases.


Model Checking

Model Checking

In a model-based approach an abstract mathematical model isbuilt of the data, using abstract mathematical types such assets and abstract state machines.

The behaviour of the operations is then specified directly withrespect to this model.


Model Checking

The UPPAAL System

Integrated tool environment for:

System ModellingSimulation of the modelVerification of the model


Model Checking

The System Editor

The system editor is used to create and edit the system modelto be analyzed

A system model describe a network of a finite number ofnon-deterministic finite state automata

Edges between states may be labeled with:

GuardsSynchronizationsAssignment statements


Model Checking

UPPAAL Model Items

Initial LocationLocationEdgeSynchronization


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 modelwith respect to a requirement specification.

Like the model, the requirement specification must beexpressed in a formally well-defined and machine readablelanguage.

The model checker support three path formulae expressed bytemporal logic quantifiers:

Reachability : Is the state formular ϕ satisfied from anyreachable state ?Safety : ϕ is invariantly true in all reachable statesLiveness : ϕ is eventually sastified


Model Checking

Quantifiers

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 inwhich ϕ is satisfied

ϕ 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 inwhich ϕ 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 thetransitions to take

Going through a trace generated by the verifier

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 10euro

2 Customer gets cash when transaction is done3 System may not be able to enter a deadlock state


Model Checking

Requirement 1

Transaction is only valid with a bank balance greater than 10euro

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 ofexpected result of these

First manually written from UML diagrams, MMI flows andrequirements


Model Checking

System

UPPAAL model made from UML diagrams, MMI flows andrequirements

UPPAAL system locations was annotated with test scriptactions

Full coverages paths of the model found by verifier

A full coverage package of test Javascript generated from themodel


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

Technology

Transcript of Uppaal