Lecture: Modelling and Veri cation (Advanced Topic) · 2012-10-15 · Lecture: Modelling and Veri cation (Advanced Topic) Real-Time Systems, HT12 Martin Stigge

Lecture: Modelling and Verification (Advanced Topic)Real-Time Systems, HT12

Martin Stigge <[email protected]>

15. October 2012

Martin Stigge <[email protected]> Modelling and Verification 15. October 2012 1

mailto:[email protected]


Software Development Process (Traditionally..)

ProblemArea

Analysis

Design

Implementation

Testing

RunningSystem

Errors are detected late

The later the more expensive

30-50% of the time: Testing!



Error Introduction, Detection and Correction

Detect earlier?



Introduce Formal Modelling

Formal Modelling early in the design process

Use verification to detect errorsI (Potentially) reduces cost and time!

Emerging field in computer scienceI Methods and tools now available



Example: Deadlock in Ada Assignment

Producer

Buffer

Consumer

put get

stop!

stop!

Consumer at sum 100: Tell everyone to stop

... In which order?I Buffer first

F Producer might communicate with terminated Buffer

I Producer firstF Circular waiting possible

All initial approaches flawed, generations of students cluelessI Formal verification can detect the problem!



Software Development Process (Traditionally..)

Add Modelling & Verification!

ProblemArea

Analysis

Design

Implementation

Testing

RunningSystem



Modelling and Verification

Modelling:I Design Process: Systematic system descriptionI Abstraction of system behaviorI Only keep essential aspectsI Examples: Finite State Machines, Timed Automata, ...

Verification:I Check requirement specificationI ... in the given modelI Usually exact, unlike testingI Examples: Model Checkers (like SMV, SPIN, UPPAAL, ...)



Fahrplan

1 MotivationErrors in Software DevelopmentModelling and Verification

2 ModellingFinite AutomataTimed AutomataAda Programs as Timed Automata

3 VerificationSpecificationsUPPAAL



Finite Automata: First Example

Intelligent Light Control

Off

Light

Brightpress? timeout

press?

press?



Finite Automata: More formally

Theoretic model for systems (or whatever else)

Locations and transitions (drawn as nodes and edges)

Actions (or events) on the transitions (drawn as edge labels)

p

q

ra b

a

a

Accepted language: (ab|aaa)∗I Describes sequence of actionsI Regular languageI Cf. your favorite book about automata theory

View automaton as a task (actions are synchronization)



State Space

p

q

r

State space: Set of locations

Trace semantics:I One possible trace: p → q → p → q → r → p → . . .I Another one: p → q → r → p → q → . . .I Not a trace: p → r → p → . . .

Interesting if there are “good” and “bad” states



Networks of Finite Automata

Compose several automata into networks

Use synchronization on edges/transitionsI Write ? and ! for input/output actions (complementary)

p

q

r ‖ s t

a?

a!

State space: Product of location sets

Trace semantics:I Interleaving, i.e., one automaton at a timeI Synchronized edges are taken togetherI E.g.: (p, s)→ (q, s)→ (q, t)→ (r , t)

a→ (p, s)→ (q, s)→ . . .I Not a trace: (p, s)→ (p, t)→ (p, s)→ . . .



Compositional Models

Synchronization models channels in composed models

A Bc

a

c: connectd: disconnecta: abort

A ‖ B

C

(A ‖ B) ‖ Cd



Synchronization Example

Sync. execution may lead to deadlocks

A1 A2

A3

c!

d?a!

B1 B2

B3

c?

a?

C1

C2

d!

Consider trace:(A1,B1,C1)

c→ (A2,B2,C1)d→ (A1,B2,C2) ..Deadlock!

(Deadlock can be removed by adding another component.)



Timed Automata: Lamp Example

Extend finite automata with clocks:

highlow

offx>=5 x<5

x := 0

A finite number of clocksI Real valuedI All increasing at same rate, starting from 0I Can be reset (x:=0) and compared (x<5)



Timed Automata: Semantics

highlow

offx>=5 x<5

x := 0

State space: Location × Clock valuations

Trace semantics: Additional delay transitions

I (off , 0)δ→ (off , 1.2)→ (low , 0.0)

δ→ (low , 5.7)→ (off , 5.7)→(low , 0.0)

δ→ (low , 2.3)→ (high, 2.3)→ . . .



Networks of Timed Automata

Compose just like before, using synchronized edges

highlow

offx>=5

press?

press?

x<5

press?

press?

x := 0

Lamp automaton

‖idle

press!

User automaton



Additional Data Variables

Variables also possible, e.g., integers

doneincreasewait

i>=5

i<5

i:=i+1

press?

State space: Location × Clock valuations × Data domains

Example trace:I (wait, i = 0)→ (increase, i = 0)→ (wait, i = 1)→ . . .→ (wait, i = 5)→ (increase, i = 5)→ (done, i = 5)



Timed Automata Formally

A Timed Automaton is a finite graph withI finitely many vertices/locations V , labeled with

F location invariants,

I initial location l0 ∈ V ,I finitely many edges E ⊆ V × V , labeled with

F guards,F actions,F assignments.

Guards: Clock constraint or predicate over data variablesI Clock constraint: g ::= x 6 n | x > n | x < n | x > n | g ∧ gI Data predicate: “any logical expression” you would write in C

Actions: On channels for synchronizationI a? or a!

Assignments: Clock reset or data variable assignmentI x:=0, i:=i+1

Location Invariants: Clock constraints, like guards



Location Invariants

Time may only progress as long as invariant satisfied

Enter a location only if invariant satisfied

l

x 6 3x := 0

x > 2

x := 0

value of x

time0 1 2 3 4 5 6 7 8 9 10

0

1

2

3

lx := 0

x > 2x 6 3

x := 0

value of x

time0 1 2 3 4 5 6 7 8 9 10

0

1

2

3



Ada Programs as Timed Automata: Rendezvous

task body A is

begin

...

B.Call;

...

end A;

task body B is

begin

...

accept Call do

foo();

end Call

...

end B;

A1

A2

call!

B1

B2

call?foo()



Ada Programs as Timed Automata: Timeouts

loop

Temperature.read;

select

Controller.set;

or

delay 5;

...

end select;

end loop;

l1

l2

...x 6 5

read!x:=0

x > 5

x < 5set!

Message passing via variables



Ada Programs as Timed Automata: Periodic Behaviour

task body PeriodicTask is

T: constant Duration := 5.0;

Next_Time: Time;

begin

Next_Time := Clock + T;

loop

...

delay until Next_Time;

Next_Time := Next_Time + T;

end loop;

end PeriodicTask;

l1

...

x = 0

x = Tx := 0



Fahrplan

1 MotivationErrors in Software DevelopmentModelling and Verification

2 ModellingFinite AutomataTimed AutomataAda Programs as Timed Automata

3 VerificationSpecificationsUPPAAL



Specifications

Specify requirements as properties

Formulated over the state space

Safety propertiesI “Something (bad) should not happen”I Method: Reachability analysis

Liveness propertiesI “Something (good) must happen/be repeated”I Method: Loop detection



Computation Tree

Nondeterministic behavior is a tree

p

q

r

p

q

p

q

p r

r

p

q

p r...

...

ComputationTree

Automaton

Formulate properties over that treeI From r , always possible to come backI From anywhere, q always reachableI Possible to never visit rI No deadlock: always a child nodeI ...



Temporal Logic

Formal way of specifying properties

Propositional state properties:

p ::= A.n | gc | gd | not p | p or p | p and p

| p imply p

A.n: Automaton A is in location ngc: Clock constraint, e.g., x > 2gd: Data predicate, e.g., i == 100

Rest: Logical connectives (boolean)



Temporal Logic (cont.)

Temporal operatorsA[] p: p is an invariant

F In all executions, p always holds

E[] p: p may hold globallyF There is an execution in which p always holds

E<> p: p is reachable/possibleF There is an execution in which p eventually holds

A<> p: p is guaranteedF In all executions, p eventually holds

(UPPAAL can not nest them)



Temporal Operators

A[] p E[] p E<> p A<> p



Example Properties

1 It is possible that automaton A reaches location doneI E<> A.done

2 Automata A and B are never in locations critical at the same timeI A[] not (A.critical and B.critical)

3 It is possible that automaton C never reaches the reward locationI E[] not C.reward

4 The system does not deadlockI A[] not deadlock

5 ...? Whenever automaton B is in location foo, clock x is at least 3I A[] B.foo imply x >= 3

6 ...?No matter what, automaton C eventually reaches location rewardI A<> C.reward

7 ...? It is possible that clock x of automaton D is at least 5 but D isnot in location done

I E<> D.x >= 5 and not D.done



UPPAAL

Model Checker for timed automataI Developed at Aalborg University, Denmark and Uppsala UniversityI Started 1995, rather mature by nowI Different branches: Timed games, costs, statistical model checker, ...I GUI in Java, verification engine C++I Extensive online help. Use it!

Three panes:1 Automata editor2 Simulator3 Verifier

Free for private/academic use (but closed-source)

You can run it at home: http://www.uppaal.org


http://www.uppaal.org


UPPAAL (cont.)

Demo.



Documents

Lecture: Modelling and Veri cation (Advanced Topic) · 2012-10-15 · Lecture: Modelling and Veri cation (Advanced Topic) Real-Time Systems, HT12 Martin Stigge