An Introduction to Model
Checking
application to business process verification
Sohei Ito
Institute of Interdisciplinary Research, OPF, SU
Department of Fisheries Distribution and Management, National
Fisheries University, Japan
Background
• Software is everywhere.
• From personal devices to infrastructures.
• The security of mission critical systems is important.
• Banking systems
• Air traffic management systems
• Power plant control systems
• How to build secure systems? By formal methods.
Formal methods
• Mathematically rigorous techniques to ensure the correctness of
software and hardware systems.
• Formal methods are based on theoretical computer science
fundamentals (i.e. mathematical theory on computations).
•
•
•
•
Mathematical logic
Automata theory
Program semantics
Process algebra
Model checking
• For a given model and a specification, to decide whether the model
meets the specification.
• A model is given as an automaton.
• A specification is given as a logical formula.
C
A
B
E
Model
Yes/No
D
Every path will reach to state E.
Specification
Model checker
Practicality of model checking
• Checking is fully automatic.
• It gives a counterexample if the property is not satisfied.
• Many model-checking tools are available.
• The usefulness is proven in several industrial applications.
• It can be applied to business process verification.
This seminar
• An (informal) introduction to model checking
• Automaton as a model
• Temporal logic as a specification language
• Some extensions of automata
• Application of model checking to business process verification
Automaton as a model
Automaton (state transition system)
• An automaton is a machine evolving from one state to another under
the action of transitions.
A
B, C
A
1
2
B
3
A
4
C
B, C
A model of a digicode. When ABA is keyed in, the door opens.
Execution of automata
• An execution is a sequence of states describing one possible evolution
of the system.
• In the model of digicode, 1123, 12234 and 112312234 are executions.
A
B, C
A
1
2
C
B, C
B
3
A
4
Execution tree
• The set of possible executions can be organized as a tree.
1
1
2
1
1
2
2
1
2
1
3
1
2
2
1
2
3
3
1
4
Elementary properties of states
• In the modeling process, we can associate with each state some
elementary properties which we know to be true or false.
• We suitably choose what properties we consider for our verification target.
• These elementary properties are called atomic propositions.
A
B, C
𝑃𝐴 : an A has just been keyed in.
𝑃𝐵 : a B has just been keyed in.
A
B
A
1
2
3
4
C
𝑃𝐴
B, C
𝑃𝐵
𝑝𝑟𝑒𝑑2
𝑃𝐴
𝑝𝑟𝑒𝑑3
𝑝𝑟𝑒𝑑2 : the preceding state in an execution is 2.
𝑝𝑟𝑒𝑑3 : the preceding state in an execution is 3.
Verify system properties
• Our main interest is that;
1. If the door opens (if an execution reaches state 4), then A, B, A were the last
three letters keyed in, in that order.
2. Keying in any sequence of letters ending in ABA opens the door.
Verification (manually)
• If the door opens (if an execution reaches state 4), then A, B, A were
the last three letters keyed in, in that order.
• Assume that we are in state 4. We prove ABA were the last three
letters of any execution.
4
Verification (manually)
• If the door opens (if an execution reaches state 4), then A, B, A were
the last three letters keyed in, in that order.
• Assume that we are in state 4. We prove ABA were the last three
letters of any execution.
• Since 𝑝𝑟𝑒𝑑3 holds in state 4, the previous state was 3.
3
4
Verification (manually)
• If the door opens (if an execution reaches state 4), then A, B, A were
the last three letters keyed in, in that order.
• Assume that we are in state 4. We prove ABA were the last three
letters of any execution.
• Since 𝑝𝑟𝑒𝑑3 holds in state 4, the previous state was 3.
• Since 𝑝𝑟𝑒𝑑2 holds in state 3, the previous state was 2.
2
3
4
Verification (manually)
• If the door opens (if an execution reaches state 4), then A, B, A were
the last three letters keyed in, in that order.
• Assume that we are in state 4. We prove ABA were the last three
letters of any execution.
• Since 𝑝𝑟𝑒𝑑3 holds in state 4, the previous state was 3.
• Since 𝑝𝑟𝑒𝑑2 holds in state 3, the previous state was 2.
• Since 𝑃𝐴 holds in state 2 and 4, and 𝑃𝐵 holds in state 3, we conclude the last
letters keyed in were ABA.
A
2
B
3
A
4
Automatic verification
• Model checking is a technique to automatically perform such
verifications.
• For this, the property to be checked must be given in “mathematical”
way.
• This is the topic of the next part.
Summary of the modeling process
• We create an automaton of the target system.
• States and transitions.
• With some abstraction of the reality.
• We associate with each state some propositions.
• Considering our verification target.
The model consists of states, transitions and properties on states.
Temporal logic as a specification
language
Properties to be verified
• In the modeling process, we associated “elementary” properties with
automaton states.
• However, our target of verification is a “complicated” properties such
as;
• For all execution, some “elementary” property (say, 𝑝) must be eventually
satisfied.
• When an execution arrives a state in which some “elementary” property (say,
𝑝) holds, another “elementary” property (say, 𝑞) must be satisfied in some
following state.
• Such “complicated” properties are composed of “elementary”
properties.
Mathematical specification
• To algorithmically solve the verification problem, it must be stated
mathematically.
• An automaton is a mathematical object. What about a property?
• One of the promising way is to use “temporal logic” [Pnueli ’77].
• There are several temporal logics but we introduce Computation Tree
Logic (CTL).
What is logic?
• Logic is a kind of language.
• Formulae (sentences)
• Interpretation (true or false)
• Example.
•
•
•
•
Formula: 𝑝 ∧ 𝑞
Interpretation: both 𝑝 and 𝑞 are true
At a state 𝑠 = [𝑝 ↦ 𝑡𝑡, 𝑞 ↦ 𝑓𝑓], 𝑝 ∧ 𝑞 is not true. We write 𝑠 ⊭ 𝑝 ∧ 𝑞.
At a state 𝑠 ′ = [𝑝 ↦ 𝑡𝑡, 𝑞 ↦ 𝑡𝑡], 𝑝 ∧ 𝑞 is true. We write 𝑠 ′ ⊨ 𝑝 ∧ 𝑞.
Computation Tree Logic (CTL)
• It uses atomic propositions to make statements about states.
• Atomic propositions are elementary statements which are determined as true
or false in a given state.
• We write 𝑠 ⊨ 𝑝 for proposition 𝑝 is true at state 𝑠.
s0
s1
p
p, q
𝑠0
𝑠0
𝑠1
𝑠1
⊨𝑝
⊭𝑞
⊨𝑝
⊨𝑞
Boolean combination of propositions
• The negation (“not”) ¬
• The conjunction (“and”) ∧
• The disjunction (“or”) ∨
• The logical implication (“if … then …”) →
s0
s1
p
p, q
𝑠0 ⊨ ¬𝑞
𝑠0 ⊨ 𝑝 ∨ 𝑞
𝑠1 ⊨ 𝑝 ∧ 𝑞
𝑠1 ⊨ 𝑝 ∨ 𝑞
𝑠1 ⊨ 𝑝 → 𝑞
Temporal operators
• In CTL, we can specify properties on executions using temporal
operators.
• An execution of an automaton is a sequence of states.
• We write 𝜎 ⊨ 𝜑 for formula 𝜑 is true in the execution 𝜎.
• There are three temporal operators.
• 𝑋 (next state)
• 𝐹 (some future state)
• 𝐺 (all future state)
s0
s1
p
p, q
Execution
𝜎0 = 𝑠0 → 𝑠1 → 𝑠1 → ⋯
𝜎1 = 𝑠0 → 𝑠0 → 𝑠1 → ⋯
𝜎0 ⊨ 𝑋𝑞
𝜎0 ⊨ 𝐺𝑝
𝜎1 ⊨ ¬𝑋𝑞
𝜎1 ⊨ 𝐹 𝑝 ∧ 𝑞
Path quantifiers
• In CTL, it is possible to make a statement like “for all executions, …” or
“there exists an execution such that …”
• There are two path quantifiers.
Execution tree from s0
• 𝐴 (for all executions)
• 𝐸 (there exists an execution)
s0
s1
p
p, q
s0
𝑠0 ⊨ 𝐸𝐹(𝑝 ∧ 𝑞)
𝑠0 ⊭ 𝐴𝐹𝑞
𝑠1 ⊨ 𝐴𝐺(𝑝 ∧ 𝑞)
s0
s0
s0
s1
s1
s1
s1
s1
Illustration of the meanings of CTL formulae
𝐸𝐹𝑝
𝐸𝐺𝑝
𝐴𝐹𝑝
𝐴𝐺𝑝
p
p
p
p
p
p
p
p
p
p
p
p
p
p
The model checking problem
• Given model (automaton) 𝑀 and a temporal logic specification 𝜑,
decide whether 𝑀, 𝑠0 ⊨ 𝜑.
• Where 𝑠0 is the initial state of 𝑀.
• There is an efficient algorithm to solve model checking problems for
CTL.
• The algorithm runs in time linear in the sizes of the given automaton and the
specification.
Frequently used properties
• Safety
• “Bad” situations never occur.
• Example. “Memory overflow will never occur.”
• 𝐴𝐺¬𝑜𝑣𝑒𝑟𝑓𝑙𝑜𝑤 in CTL.
• Liveness
• Some “happy” event will occur in the end.
• Example. “Any request will ultimately be satisfied.”
• 𝐴𝐺 𝑟𝑒𝑞 → 𝐴𝐹𝑠𝑎𝑡 in CTL.
Some extensions of automata
For realistic models
• When we deal with real-life programs or systems, they are often
broken up into modules or subsystems.
• To build a model of such systems, we firstly model the system
components.
• The global automaton is obtained by having the component automata
cooperate.
Cooperation by message passing
!Push
Push button
Idle
Light
?Red
?Push
Car traffic light
G
!Red
Y
R
Synchronized execution
(Idle, G)
!Push
Push button
Idle
Push
Light
(Light, Y)
?Red
Red
(Idle, R)
?Push
Car traffic light
G
!Red
Y
R
(Idle, G)
Other extensions
• Variables & clocks
• We can update them on transitions.
• We can impose conditions to fire transitions (guards).
• We can impose conditions on locations (invariants)
• We call it a timed automaton.
clock t;
Init
Reset
clock
t := 0
Guard
A
t >= 2
t <= 5
Invariant
Finish
Execution of timed automata
• A state is a pair of a location and an evaluation of variables.
Init
t := 0
A
t >= 2
Finish
t <= 5
(Init, [t↦0])
(Init, [t↦2.3])
(A, [t↦0])
(A, [t↦1.5])
(A, [t↦2.2])
(Finish, [t↦1.5])
(A, [t↦5.1])
(Finish, [t↦2.2])
Impossible due toImpossible
the guard.due to the invariant.
Important correctness: deadlock-freeness
• A state is a deadlock if there is no possible transition from that state.
• The deadlock-freeness property is written as 𝐴𝐺𝐸𝑋𝑡𝑟𝑢𝑒.
• For a single automaton, the detection of deadlock states is trivial.
Deadlocked state
For concurrent and real-time systems
((Idle,0), (G,0))
• To check deadlock-freeness is not trivial.
Push
x := 0
!Push
Push button
Idle
((Light,0), (Y,0))
Light
((Light,1.0), (Y,1.0))
?Red
x>2
t := 0
?Push
Car traffic light
G
t <=2
Y
((Light,2.0), (Y,2.0))
t >= 1
!Red
R
UPPAAL
• A model checker for timed automata.
• Jointly developed by Uppsala university and Aalborg University
[Larsen et al., 1997].
GUI of UPPAAL
GUI of UPPAAL
Application of model checking to
business process verification
Why we verify business processes?
• Business process design with time and resource constraints is error
prone task.
• Detecting errors at the design stage in prior to implementation makes
development of business processes more efficient.
• Verification of existing business processes sometimes reveals
bottleneck and thus may suggest further improvement.
Example. Verification of a generic trading
company model (our ongoing work)
Negotiation process
• Buyer sends a sales request.
• Seller responds with a sales quote.
• Buyer decides whether he accepts
the quote or not.
• If he does, the negotiation finishes.
• If he does not, Seller sends a new
quote.
• If the negotiation does not finish
within a certain time, Buyer
revokes it.
The customer model
The sales representative model
The purchase representative model
The supplier model
Verification of desirable properties
• No deadlock
• Correct termination
• Once the negotiation starts, it must be either accepted or revoked.
• Correct stock management
• The stock never becomes negative.
Research challenges in BP modeling and
verification
• Investigate a formal modeling language which can describe financial
characteristics of business processes.
• And related specification languages and verification techniques.
• Verification of profitability of BPs.
• With several uncertainties.
• How to fill the gaps between informal BP modeling languages and
formal modeling languages.
Conclusion
Conclusion
• Introduced basics of model checking.
• Automaton as a model
• Temporal logic as a specification language
• Extension of automata
• Application to business process verification
• Generic trading company
• Research challenges