Model checking: Overview

1
Outline

• Model checking Overview
• Comparing LTL and CTL
• Verifying LTL using CTL model checking
• Formal Tropos
• KAOS and model checking
• Goals-Ops-Props-Scenarios

2
Outline

• Model checking Overview
• Comparing LTL and CTL
• Verifying LTL using CTL model checking
• Formal Tropos
• KAOS and model checking
• Goals-Ops-Props-Scenarios

3
Model Checking (Clarke and Emerson)
G(p -gt F q)
yes
MC

• output
• yes
• no counterexample
• input
• temporal logic spec
• finite-state model
• (look ma, no vectors!)

no
p
p
q
q
Source www.kenmcmil.com/cav98/tutorial/CAV98tuttr
ans.ppt
4
Linear temporal logic (LTL)

• A logical notation that allows to
• specify relations in time
• conveniently express finite control properties
• Temporal operators
• G p henceforth p
• F p eventually p
• X p p at the next time
• p W q p unless q

Source www.kenmcmil.com/cav98/tutorial/CAV98tuttr
ans.ppt
5
Types of temporal properties

• Safety (nothing bad happens)
• G (ack1 ack2) mutual exclusion
• G (req -gt (req W ack)) req must hold until ack
• Liveness (something good happens)
• G (req -gt F ack) if req, eventually ack
• Fairness
• GF req -gt GF ack if infinitely often req,
  infinitely often ack

Source www.kenmcmil.com/cav98/tutorial/CAV98tuttr
ans.ppt
6
Example traffic light controller
S
E
N

• Guarantee no collisions
• Guarantee eventual service

Source www.kenmcmil.com/cav98/tutorial/CAV98tuttr
ans.ppt
7
Controller program

• module main(N_SENSE,S_SENSE,E_SENSE,N_GO,S_GO,E_GO
  )
• input N_SENSE, S_SENSE, E_SENSE
• output N_GO, S_GO, E_GO
• reg NS_LOCK, EW_LOCK, N_REQ, S_REQ, E_REQ
• / set request bits when sense is high /
• always begin if (!N_REQ N_SENSE) N_REQ 1
  end
• always begin if (!S_REQ S_SENSE) S_REQ 1
  end
• always begin if (!E_REQ E_SENSE) E_REQ 1
  end

Source www.kenmcmil.com/cav98/tutorial/CAV98tuttr
ans.ppt
8
Example continued...

• / controller for North light /
• always begin
• if (N_REQ)
• begin
• wait (!EW_LOCK)
• NS_LOCK 1 N_GO 1
• wait (!N_SENSE)
• if (!S_GO) NS_LOCK 0
• N_GO 0 N_REQ 0
• end
• end
• / South light is similar . . . /

Source www.kenmcmil.com/cav98/tutorial/CAV98tuttr
ans.ppt
9
Example code, cont

• / Controller for East light /
• always begin
• if (E_REQ)
• begin
• EW_LOCK 1
• wait (!NS_LOCK)
• E_GO 1
• wait (!E_SENSE)
• EW_LOCK 0 E_GO 0 E_REQ 0
• end
• end

Source www.kenmcmil.com/cav98/tutorial/CAV98tuttr
ans.ppt
10
Specifications in temporal logic

• Safety (no collisions)
• G (E_Go (N_Go S_Go))
• Liveness
• G (N_Go N_Sense -gt F N_Go)
• G (S_Go S_Sense -gt F S_Go)
• G (E_Go E_Sense -gt F E_Go)
• Fairness constraints
• GF (N_Go N_Sense)
• GF (S_Go S_Sense)
• GF (E_Go E_Sense)
• / assume each sensor off infinitely often /

Source www.kenmcmil.com/cav98/tutorial/CAV98tuttr
ans.ppt
11
Counterexample

• East and North lights on at same time... (Safety)

E_Go
E_Req
E_Sense
NS_Lock
N_Go
N_Req
N_Sense
S_Go
S_Req
S_Sense
Source www.kenmcmil.com/cav98/tutorial/CAV98tuttr
ans.ppt
12
Another counterexample

• East traffic is never served... (Liveness)

E_Go
E_Req
E_Sense
NS_Lock
N_Go
N_Req
N_Sense
S_Go
S_Req
S_Sense
Source www.kenmcmil.com/cav98/tutorial/CAV98tuttr
ans.ppt
13
Computation tree logic (CTL)

• Branching time model
• Path quantifiers
• A for all future paths
• E for some future path
• Example AF p inevitably p

p
p
AF p
p

• Every operator has a path quantifier
• AG AF p instead of GF p

7
Source www.kenmcmil.com/cav98/tutorial/CAV98tuttr
ans.ppt
14
Outline

• Model checking Overview
• Comparing LTL and CTL
• Verifying LTL using CTL model checking
• Formal Tropos
• KAOS and model checking
• Goals-Ops-Props-Scenarios

15
Comparing CTL and LTL

• Complexity of CTL problem
• linear in size of model (FSM)
• linear in size of specification formula
• general LTL problem is exponential in formula
  size
• Therefore, CTL is easier to verify

Source www.kenmcmil.com/cav98/tutorial/CAV98tuttr
ans.ppt
16
Verifying LTL using CTL model checking

• Proposed by Edmund Clarke, et.al in Another Look
  at LTL Model Checking (widely cited)
• Method
• Convert LTL to Symbolic Model Verifier (SMV)
  program
• FSM (tableau for the LTL)
• Fairness constraints
• Formal Tropos adopted and extended this approach
  for converting LTL specified for i models

17
Outline

• Model checking Overview
• Comparing LTL and CTL
• Verifying LTL using CTL model checking
• Formal Tropos
• KAOS and model checking
• Goals-Ops-Props-Scenarios

18
Formal Tropos

• Extends the Tropos approach with formal
  specification and model checking
• Tropos uses the i framework for the
  early-requirements
• Agents
• Inter-agent dependencies
• Goals
• Resources
• Softgoals

19
Example
Source A. Fuxman, et. al, Specifying and
analyzing early requirements in Tropos, Journal
of RE 2004
20
Formal Specification

• Constraints
• Invariant
• Creation condition
• Fulfillment

Extended LTL
21
Constraints

• Invariant
• Conditions that should hold throughout the
  lifetime of all class instances
• Creation condition
• Conditions that should hold when an actor begins
  to desire a goal
• Fulfillment condition
• Conditions that should hold when the goal is
  achieved

22
Extended LTL
23
Properties

• Assertions
• Conditions that hold for all valid scenarios
• Possibilities
• Conditions that hold for at least one valid
  scenario

24
Assertions and possibilities

• Assertions
• Conditions that hold for all valid scenarios
• Possiblities
• Conditions that hold for at least one valid
  scenario

25
Model checking

• Goals
• Assertion validation
• Assertion properties hold on all possible
  scenarios
• If not, a counterexample is given, which is a
  scenario that violates the assertion
• Consistency check
• That the specification is not self-contradictory,
  e.g.
• At least one scenario that respects all of the
  constraints
• At least one scenario where all the class
  instances specified by input parameters will
  eventually be created
• Possibility check
• Whether the specification is over-constrained
  (rule out scenarios expected by the stakeholders)
• Animation
• Valid scenario for the specification

26
Model checking example assertion violation
Violated assertion
This assertion requires a passing mark to be
present if a PassGoal is fulfilled, but it does
not hold from t4-t5.
27
T-Tool Formal Tropos model checking tool

• Use an intermediate language (IL) to bridge
  between Formal Tropos (FT) specification and
  formal methods
• Stated advantages
• more compact than FT
• analysis language independent

28
T-Tool Intermediate Language

• Focus mainly on the dynamic aspect of the system
  
• Class generically represents entities, actors,
  and dependencies

Note Is it possible or make sense to reuse IL
for model check whatever formalization we
introduce in our group?
29
Outline

• Model checking Overview
• Comparing LTL and CTL
• Verifying LTL using CTL model checking
• Formal Tropos
• KAOS and model checking
• Goals-Ops-Props-Scenarios

30
KAOS and model checking policy refinement
Source Javier Rubio-Loyola, et. al, Using
Linear Temporal Model Checking for Goal-oriented
Policy Refinement Frameworks, Sixth IEEE
International Workshop on Policies for
Distributed Systems and Networks (POLICY05)
31
Policy graph, properties, model checking
32
Deriving Event-BasedTransition Systems from
goal-oriented requirements models (KAOS)
Source E. Letier, J. Kramer, et. al, Deriving
Event-BasedTransition Systems from Goal-oriented
requirements models, technical report,
www.doc.ic.ac.uk/research/ technicalreports/2006/D
TR06-2.pdf
33
Outline

• Model checking Overview
• Comparing LTL and CTL
• Verifying LTL using CTL model checking
• Formal Tropos
• KAOS and model checking
• Goals-Ops-Props-Scenarios

34
Goals-Ops-Props-Scenarios
Goals
Goals
Objects
liveness
liveness
safety
Scenarios
Scenarios
Properties
Properties
Operationalizations
Operationalizations
anti negative mis
35
Example
36
Some semantics
Goal model checking based satisficing 1) All
liveness properties are achieved or no safety
property is violated Here, ProtectCar is not
satisficed according to label propagation, but
satisficed according to model checking based
satisficing. (need some notation to indicate as
such) 2) Violate at least one safety property of
the anti-model Here, LockTransmissionCar
violates the liveness of the anti-model. (need
some notation to indicate as such)
37
Model checking issues

• Can we use Formal Tropos Intermediate Language
  (IL) to reuse its model checking engine? What
  does it mean?
• Need objects as context for the (generated)
  state-machine
• Possibly use Topic of the goal (both hard and
  soft) as its usually functional already. E.g.
  SecurityCar softgoal, LockDoor hardgoal

38
Metamodel

• Note
• Any subtype of Goal can have Property
• There should be some relationships between
  Properties of related goals

Source for scenario C. Rolland, Guiding Goal
Modeling using scenarios, TSE Dec. 1998