lecture: modelling and veri cation (advanced topic) · 2012-10-15 · lecture: modelling and veri...
TRANSCRIPT
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
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!
Martin Stigge <[email protected]> Modelling and Verification 15. October 2012 2
Error Introduction, Detection and Correction
Detect earlier?
Martin Stigge <[email protected]> Modelling and Verification 15. October 2012 3
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
Martin Stigge <[email protected]> Modelling and Verification 15. October 2012 4
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!
Martin Stigge <[email protected]> Modelling and Verification 15. October 2012 5
Software Development Process (Traditionally..)
Add Modelling & Verification!
ProblemArea
Analysis
Design
Implementation
Testing
RunningSystem
Martin Stigge <[email protected]> Modelling and Verification 15. October 2012 6
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, ...)
Martin Stigge <[email protected]> Modelling and Verification 15. October 2012 7
Fahrplan
1 MotivationErrors in Software DevelopmentModelling and Verification
2 ModellingFinite AutomataTimed AutomataAda Programs as Timed Automata
3 VerificationSpecificationsUPPAAL
Martin Stigge <[email protected]> Modelling and Verification 15. October 2012 8
Finite Automata: First Example
Intelligent Light Control
Off
Light
Brightpress? timeout
press?
press?
Martin Stigge <[email protected]> Modelling and Verification 15. October 2012 9
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)
Martin Stigge <[email protected]> Modelling and Verification 15. October 2012 10
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
Martin Stigge <[email protected]> Modelling and Verification 15. October 2012 11
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)→ . . .
Martin Stigge <[email protected]> Modelling and Verification 15. October 2012 12
Compositional Models
Synchronization models channels in composed models
A Bc
a
c: connectd: disconnecta: abort
A ‖ B
C
(A ‖ B) ‖ Cd
Martin Stigge <[email protected]> Modelling and Verification 15. October 2012 13
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.)
Martin Stigge <[email protected]> Modelling and Verification 15. October 2012 14
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)
Martin Stigge <[email protected]> Modelling and Verification 15. October 2012 15
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)→ . . .
Martin Stigge <[email protected]> Modelling and Verification 15. October 2012 16
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
Martin Stigge <[email protected]> Modelling and Verification 15. October 2012 17
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)
Martin Stigge <[email protected]> Modelling and Verification 15. October 2012 18
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
Martin Stigge <[email protected]> Modelling and Verification 15. October 2012 19
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
Martin Stigge <[email protected]> Modelling and Verification 15. October 2012 20
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()
Martin Stigge <[email protected]> Modelling and Verification 15. October 2012 21
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
Martin Stigge <[email protected]> Modelling and Verification 15. October 2012 22
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
Martin Stigge <[email protected]> Modelling and Verification 15. October 2012 23
Fahrplan
1 MotivationErrors in Software DevelopmentModelling and Verification
2 ModellingFinite AutomataTimed AutomataAda Programs as Timed Automata
3 VerificationSpecificationsUPPAAL
Martin Stigge <[email protected]> Modelling and Verification 15. October 2012 24
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
Martin Stigge <[email protected]> Modelling and Verification 15. October 2012 25
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 ...
Martin Stigge <[email protected]> Modelling and Verification 15. October 2012 26
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)
Martin Stigge <[email protected]> Modelling and Verification 15. October 2012 27
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)
Martin Stigge <[email protected]> Modelling and Verification 15. October 2012 28
Temporal Operators
A[] p E[] p E<> p A<> p
Martin Stigge <[email protected]> Modelling and Verification 15. October 2012 29
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
Martin Stigge <[email protected]> Modelling and Verification 15. October 2012 30
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
Martin Stigge <[email protected]> Modelling and Verification 15. October 2012 31
UPPAAL (cont.)
Demo.
Martin Stigge <[email protected]> Modelling and Verification 15. October 2012 32