MF Merged

Introduction to Formal Methods Dr-Ing.
Abderahman KRIOUILE
Scientists Quotes
“Software engineers want to be real engineers.
Real engineers use mathematics.
Formal methods are the mathematics
of software engineering.
Therefore, software engineers should use
formal methods.”
(Mike Holloway, NASA)
linkedin.com/in/akriouile @A_KRIOUILE Dr. Abderahman KRIOUILE - Introduction to Formal Methods - ENSIAS 2015/2016 2
Contents Today
• Need for Formal Methods • Overview of Critical-Systems
• Formal Methods Definition • Need for Formal Methods
• Formal Modeling • Formal Methods Definition
• Temporal logics • Examples of
• Model Checking Formal Techniques
• CADP toolbox
Dr. Abderahman KRIOUILE - Introduction to Formal Methods - ENSIAS 2015/2016 3 Dr. Abderahman KRIOUILE - Introduction to Formal Methods - ENSIAS 2015/2016 4
Motivations Desired properties of systems

• Problems in Developing Industrial Systems • Availability: a system must be working and
– Functionality Issues: Growing Size & Complexity able to provide its services
– Requirements issues: availability, reliability, safety, • Reliability: a system must correctly provide its
security
functionalities, as expected by users
– Application Domain Issues: Safety-Critical, Mission-
Critical or Business-Critical Systems • Safety: the system should do nothing very
– Market Issues: Time-to-delivery, Costs undesirable (causing damages to people,...)
– Maintenance Issues: Requirements change over time • Security: the system should resist to intruders
ENSIAS Systèmes Embarqués et Mobiles 2015/2016 1

Introduction to Formal Methods Dr-Ing. Abderahman KRIOUILE
Critical Systems Safety-Critical Systems
• Safety-critical: trains & planes control, nuclear

plants control, etc.
• Mission-critical: space craft navigation
• Business-critical: bank management software,
operating systems, Smartphone, etc.
Systems whose failure can cause life losses

or serious environmental damage
Business-Critical Systems Mission-Critical Systems
Systems whose failure can cause the loss of Systems whose failure can cause the failure
big or huge amounts of money of the goals of important missions
Avionic software standard

Developing Safety-Critical Systems
DO-178C: Design Assurance Level(DAL)
• DAL A / Catastrophic - Failure may cause multiple fatalities,
usually with loss of the airplane.
• DAL B / Hazardous - Failure has a large negative impact on
safety or performance, or reduces the ability of the crew to
operate the aircraft.
• DAL C / Major - Failure significantly reduces the safety margin
or significantly increases crew workload. May result in
passenger discomfort (or even minor injuries).
• DAL D / Minor - Failure slightly reduces the safety margin or
slightly increases crew workload.
• DAL E / No Effect - Failure has no impact on safety, aircraft
operation, or crew workload.

Avionic software standard

The Ariane 5 Case
DO-178C: Design Assurance Level(DAL)
• 4 June 1996: the first flight of the Ariane 5
failed. After 40 seconds the rocket changed
Level Failure condition Objectives With independence
trajectory and exploded
A Catastrophic 71 33
B Hazardous 69 21 • The SW of the Inertial Reference Systems
C Major 62 8
ceased to work after 36 seconds.
D Minor 26 5
E No Effect 0 0 • 800 Million US$ lost
• Cause:
a variable overflow!
Formal Methods Definition Formal Model: a utility by itself!

Formal Notation • Classical Development: the product is the unique
Formal Methods formal statement (code for software)
Formal Analysis – At the end of the development process
• Formal Model
• Formal Notation – Ambiguities detection
– Semantics defined mathematically – Earlier error detection
Unambiguous – Upstream phases consolidation
• Formal Analysis – Mature product earlier
– Automated processing of models expressed in – More expensive upstream phases
formal notation • But overall more effective development
Example: NASA projects budget

Modeling For Simulation
respect
• Correlation between effort spent in upstream phases • Prototyping, design choices exploration
/ budget compliance • Validation by model-based testing
SCADE Example

Code Generation Test Generation

• Automatic code generation from models • Automatic test generation from models
– Avoid manual coding error – Compliance code / model
– Productivity gain – Model Coverage
– Earlier verification on the model – Automated Verdict
Requirement Integration Tests Requirement Integration Tests
Design Unit Tests Design Unit Tests
Code Code
Verification Formal Verification

• Classic = dynamic • Syntax Analysis
– Simulation /testing
• Verification of generic properties
– None exhaustive
– Test run the hardware – Absence of run-time error
– WCET Computing
• Formal = static – Dedicated Analysis
– No run • Verification of specific properties
– Automated
– Defined by the user
– Exhaustive / consider properties
– Expressed formally
Formal Verification Techniques (1) Static Analysis

1. Static Analysis (SW) – Static Program Analysis
– Verify predefined safety properties “something
bad cannot happen” by over-approximation
2. Model Checking (SW & HW)
– If the property holds for the over-approximation it
holds for all behaviors
3. Theorem Proving (SW & HW) All violations detected
Infeasible behaviors
All behaviors of
the program
False negative

Static Analysis Properties Examples (2) Model Checking

• Absence of run-time errors • Formal V&V by exhaustive search over the
– Division never by 0
– Sqrt never of a negative number state space
– Arithmetic operation never causes overflow/underflow • Systems modeled as Finite State Machine M
– Array-index is never out of bounds
– Dereference never applied to null-pointer • Properties expressed with a formal
• Absence of timing accidents for WCET analysis representation φ (e.g. temporal logic)
– Memory access is a cache hit
– Bus access is not blocked Precise, unambiguous semantics
• Derived global program properties • Verification via logical reasoning: M |= φ
– Stacks do not overflow
– Program terminates within a given deadline
Temporal Logic A Temporal Logic can express

• Formalism for describing evolutions of • “an event A is always possible”
program states over (logical) time • “an event A will eventually happen”
– Atomic propositions over states
– Propositional logic operators (or, and, not …) • “an event A is always possible until an event B
– Tense operators (neXt, Until, Previous, Since, happens”
Once, …)
– Interpreted on state spaces Numerous temporal logics were proposed in the
• High-level specification style: literature.
abstraction and modularity
Model Checking Industrial Success of Model Checking

• Powerful debugging capabilities
– detecting problems in early stages of development
– exhaustive, thus effective
– provides counterexamples
• Can be integrated within industrial
p
development cycle
q
• Does not require deep training (Vs Theorem
proving)

(3) Theorem Proving Theorem Proving Example

• Consider the following argument (sequence of
• Theorem prover is based on libraries of propositions):
axioms and hypotheses. – If the prof offers chocolate for an answer, you answer the prof’s
question.
• Uses inference rules to prove the formal – The prof offers chocolate for an answer
– Therefore, you answer the prof’s question
description of the behavior of the system
• Let p be “the prof offers chocolate for an answer”
• Simplifying until reaching known axioms • And q be “you answer the prof’s question”
• The form of the above argument is :
• The argument is valid since ((p q)˄ p) q

is a tautology
Synthesis
• Formal Methods are introduced to industry
• Certification
– Security: Formal Methods are mandatory for high
certification level
– For example: FM recommended in railway area
– In Aeronautic, DO-333 is a technical supplement
of the DO-178C introducing Formal Methods.
Dr. Abderahman KRIOUILE - Introduction to Formal Methods - ENSIAS 2015/2016 33

Contents
• Need for Formal Methods
• Formal Methods Definition
• Formal Modeling
• Temporal logics
• Model Checking
• CADP toolbox
From Systems to Models

Today: Formal Modeling
to Formal Verification
• Modeling Concurrency
• Finite State Machines (FSM)
• Labeled Transition Systems (LTS)
• Petri Nets
• Process Calculus
Transformational programs Reactive programs

Input1 Output1
Input Program Output Input2 Program Output2
Input3 Output3
• Sequential behavior • Cyclic behavior

• Normal termination (except error) • Anomalous termination (except error)
• Receive Inputs and respond with Outputs
• Output function of the Input: Output=f(Input)
• Examples:
• Examples: – Operating Systems
– Algorithmic programs (C,C++,Ada, etc.) – Graphical interfaces
Dr. Abderahman KRIOUILE - Introduction to Formal Methods - ENSIAS 2015/2016 Dr. Abderahman KRIOUILE - Introduction to Formal Methods - ENSIAS 2015/2016

Reactive programs Reactive programs

• The same Input can produce different outputs Input(t)/Output(t)
Stat(t) Stat(t+1)
if the input happens in different moments
• Example:
• Notion of a stat (memory)
– Double clicking a GUI
– Stat(t): the stat of the program at the moment t
– Counter
• Output and current stat
– Output(t+1) = f(Input(t), Stat(t))
– Stat(t+1) = g(Input(t), Stat(t))
• Notion of a transition
Finite State Machines (FSM) Finite State Machines (FSM)
• Start of the Soda Machine FSM Model • Second Phase of the Soda Machine FSM Model
Finite State Machines (FSM) Finite State Machines (FSM)

Labeled Transition Systems (LTS) Labeled Transition Systems (LTS)

• State-transition graph Definition 2.
• no information attached to states (except the initial state) An LTS is a quadruple M = (Q,A,T,q0) where:
• information ("labels" or "actions") attached to transitions – Q is the set of states;
– A the set of actions (transition labels); the set A
contains the invisible action, which denotes
internal (unobservable) activity.
– T = Q × A × Q is the transition relation;
– q0 ϵ Q is the initial state.
Modeling Concurrency Modeling Time

• Synchronous models are good at: modeling • Synchronous models are intrinsically timed,
parallelism between processes that share a because of the existence of a global clock
common clock; describing synchronous circuits; • Asynchronous models are intrinsically
describing a “logical” parallelism that will be
untimed; adding time to an asynchronous
compiled into sequential code;
model requires ad-hoc modifications.
• Asynchronous models are good at: modeling
parallelism when no common clock exists (or
when does not want to rely on the clocks and
their synchronization when developing the SW);
Synchronous Product Asynchronous Product

M1 x M2 M1 x M2
M1 M2 M1 M2
(tM1, tM2)= (0,0)

t=0 0 0 t=0 0 tM1=0 0 0 tM2=0 0
a c
a. c (1,0) (0,1)
a c a c
1 2
b c a d
t=1 1
|| 1 = t=1 1 tM1=1 1
|| 1 tM2=1 = (2,0) (0,2)
3 4 5
b b.d b d
d b d c (1,1) a
t=3 t=3 6 7
2 2 2 tM1=2 tM2=2
2 2 (2,1) (1,2)
d b
8
(2,2)

Asynchronous Product Asynchronous Product

with communication with communication
M1 x M2
M1 M2
M1 M2 M1 x M2
0 0 0
0 a c
0 0
a a c 1 2
a c
1 1
|| 1 = c a
1
||
b=c
1 = b=c
b
b=d
d
3
b=d
2
b d 4
d 2 2
2 2
3
Petri Nets Petri Nets

• First introduced by Carl Adam Petri in 1962. • Example:
• A diagrammatic tool to model concurrency
and synchronization in distributed systems.
• Very similar to State Transition Diagrams.
• Used as a visual communication aid to model
the system behavior. – p0, p1, p2, p3 are called places
• Based on strong mathematical foundation. – t0, t1 are called transitions
– p0 =2 tokens, p1=1 token is the initial marking
Petri Nets Petri Nets Simulation

• A Change of State …
• is denoted by a movement of token(s) (black
dots) from place(s) to place(s); and is caused state 0
props p0 p3
by the firing of a transition. trans t0/1
Equivalent LTS
• The firing represents an occurrence of the state 1
des(0,2,3)
props p1
event or an action taken. trans t1/2
(0,"t0",1)
(1,"t1",2)
• The firing is subject to the input conditions, state 2
0
t0
t1
props p2 p3
denoted by token availability. trans
1
2

Contents
• Formal Modeling
• Temporal logics
• Model Checking
• CADP toolbox
Process Calculus
• Process refers to a behavior of a system
– execution of a software system
– actions of a machine
– the actions of a human being
• Behavior is the set of events or actions that a
system can perform
– We consider an abstraction or idealization of the
PROCESS CALCULI “real” behavior
– We have an observation of the behavior
• We call action the chosen unit of observation
Process Calculus Process Calculus

• Called also Process Algebra • Process calculi provide means for a high-level
• Theoretical formalisms used as based for multiple description of interactions, communications,
specification and verification tools
• Examples:
and synchronizations between a set of
– CCS (Calculus of Communicating Systems) [Milner-80, independent components of a concurrent
Milner-89] system
– CSP (Communicating Sequential Processes) [Hoare-85]
– ACP (Algebra of Communication Processes) [Bergstra-Klop-
• Provide laws to describe, manipulate, and
84] analyze processes
– Standard: LOTOS [ISO-88]
– Modern Language: LNT [abrev. LOTOS New Technology]

Equivalence Automate and Regular

Textual Formalisms (not graphical)
Expression
• In opposition to automata or Petri Nets,
Process calculi have a textual syntax 0
(≈ programs) In LNT:
a
• Advantages: 2 a; select b [] c; d end select; stop
– More expressiveness (structuring) b c
– Scalability (large specification) 3 4
• Disadvantages d
– Less intuitive syntax 5
Regular Expression Parallel Operator

• Process calculi use 3 operators similar to • Parallel operators are freely combined with
regular expressions: the other operators (choice, sequence, etc.)
– Choice (‘+’ in CCS, ‘[]’ in CSP, ‘select’ in LNT) • In LNT: par G1, …, Gn (≈ ⊗{G1, …, Gn} of automata)
– Sequence (‘.’ in CCS, ‘;’ in CSP and LNT) • Example …
– fixed point(recursive call of processes in CSS and
LNT, ‘loop’ in LNT)
Asynchronous Product In LNT

M1 x M2
M1 M2 M1 M2
par par
0 0 0 0 0
a c a; b M1
a c a c
1 2
b c a d || ||
1
|| 1 = 1
|| 1 = =
3
b
4
d
5 c; d M2
b d c a b d
6 7 end par end par
2 2 2 2
d b
8

Asynchronous Product
In LNT
with communication
M1 x M2
M1 M2 M1 M2
0
par b in par b in
0 0 0 0
a c
a; b M1
a c 1 2 a c
|| ||
1
|| 1 = c a 1
|| 1 = =
b 3 b c; b M2
b b b b b
End par End par
2 2 4 2 2
LNT LNT tutorial: Plan

• A modern formal specification language
• LNT: Language overview
• LNT is intended to be concise, expressive,
easily readable, and user-friendly 1. Modules
• The semantics of an LNT model is defined as 2. Types & Functions
an LTS, following a black box view of the 3. Processes
system
(1) LNT Modules Sample LNT Modules

• Modules module PLAYER is
– Compilation unit ... file “PLAYER.lnt”
module Team (PLAYER)
– One module = one file end module
(of the same name) is List of imported
modules
– Modules can import …
other modules end module module Team (PLAYER) is
– Principal module ... file “TEAM.lnt”
containing the root end module or (one of
process (“MAIN”) Or “team.lnt”

(2) LNT Types & Functions Sample LNT Types

• Types & Functions • Enumerated type
type Num is type Weekday is (* LOTOS-style comment *)
– Enumerated type one, two, three Mon, Tue, Wed, Thu, Fri, Sat, Sun
end type
– Record type with "==", "<=" • Record type
– Inductive type end type type Date is ‐‐ ADA‐style comment
date (day: Nat, weekday: Weekday, month: Nat, year: Nat)
– Automatic definition end type
of standard functions • Inductive type
function pi: Real is type Nat_Tree is
leaf (value: Nat),
return node (left: Nat_Tree, right: Nat_Tree)
3.14159265 end type
end function
(2) LNT Processes

• Processes
– symmetric sequential module hello_world is
composition
– variable assignment,
process MAIN [G:any]
“if-then-else”, “case”, is
“loop”, etc.
– communication:
G (”Hello, world!\n”)
rendezvous with value end process
communication
– parallel composition: end module
“par”
– nondeterministic choice:
“select”
Dr. Abderahman KRIOUILE - Introduction to Formal Methods - ENSIAS 2015/2016 21

Contents
• Formal Modeling
• Temporal logics
• Model Checking
• CADP toolbox
Example: Modeling using LTSs Peterson Algorithm

• Mutual exclusion problem var d0 : bool := false -- redden by P1, written by P0
– We consider 2 processes P0 and P1 sharing a var d1 : bool := false -- redden by P0, written by P1
var t ϵ {0, 1} := 0 -- redden/written by P0 and P1
memory
loop forever -- P0 loop forever – P1
– Can we ensure the mutual exclusion of the access { snc0 } { snc1 }
to the memory ? d0= true d1= true
t := 0 t := 1
• Several solutions “at software level” was wait (d1 = false or t=1) wait (d0 = false or t=0)
{ debutsc0 } { debutsc1 }
proposed to implement the mutual exclusion { finsc0 } { finsc1 }
(Peterson, Dekker, Knuth, etc.) d0=false
end loop
d1=false
end loop
G. L. Peterson. Myths about the mutual exclusion problem.

Information Processing Letters 12(3):115-116, June 13, 1981
Peterson: P0 and P1 Automata Peterson: d0, d1 and t Automata
P0 automaton: P1 automaton: d0 automaton: d1 automaton:

d0 := false ? d0 := false ?
1 snc0 1 snc1
d0 := false d1 := false
7 2 7 2 false false
finsc0 d0 := true finsc1 d1 := true d0 := false d0 := true d0 := false d0 := true
6 3 6 3 true true
debutsc0 t :=0 debutsc1 t :=1
d1 := false ? d0 := false ?
t automaton: t :=1
5 4 5 4
t :=0 ? 0 1 t :=1 ?
t=1? t=0?
t=0

Peterson: System Architecture Peterson: System Architecture (2)

• There are several ways to express the
d0
d0 := false d0 := false ? architecture as an automate product, depending
snc0
d0 := true
snc1
on the order of assembling automata
debutsc0 t=1 ? t=1 debutsc1
P0 t P1
finsc0 t=0 t=0? finsc1 (P0 ⊗Ø P1) ⊗{d0:=false, (d0 ⊗Ø d1 ⊗Ø t)
d1 := true d0=true,
d1 := false ? d1 := false t := 0 …}
d1
((P0 ⊗Ø P1) ⊗{d0:=false, (d0 ⊗Ø d1)) ⊗{t := 0, t)

• Synchronized actions : “d0 := false”, “d0 := true”, … d0=true, t := 1,
…} …}
• Non-synchronized actions: snc0, debutsc0, …
Construction of the product automate Peterson: Product Automaton

• Adopted Method: exhaustive stat enumeration • S = { F , T } x { F , T } x { 0 , 1 } x { 1..7 } x { 1..7 }
– Construction of the stat space by forward exploring • A = {snc0, snc1, …, “d0=true”, …}
starting by the initial state.
– Transitions are generated from transition od each • s0 = < F, F, 0, 1, 1 > = FF011
automate • T=
FF011
– When a new stat is attained, we verify if this stat snc0 snc1
already known. If it is the case return to the FF021 FF012
d0:=T snc1 snc0 d1:=T
existent state
VF031 FF022 FV013
– Different strategies to explore: breadth-first, depth- t:=0 snc1 d0:=T d1:=T snc0 t:=1
first, guided by a criteria. VF041 VF032 FV023 FF114
Example: Peterson Algorithm in LNT

Remarks
(1/3)
• The Product automaton of the system is fined module Peterson is
process D [R, W : bool] is
|S| ≤ 2 × 2 × 2 × 7 × 7 = 392
var b : bool in
• In general, the set of accessible states from the b := false;
initial state is very small compared to the loop
Cartesian product of the variable values (i.e., select R (b) [] W (?b) end select
forbidden transitions) end loop
end var
• Peterson : ~50 states, ~110 transitions end process
• Automated tools are used to construct the […]
product automaton and to explore the transitions

Example: Peterson Algorithm in LNT Example: Peterson Algorithm in LNT

process P [Wm, Rn: bool, RT, WT: nat, NCS: none, CS: nat] (m: nat) is process Main [NCS : none, CS : nat] is
var dn : bool, t : nat in hide R0, W0, R1, W1 : bool, RT, WT : nat in
loop NCS; Wm (true); WT (m); par R0, W0, R1, W1, RT, WT in
par
loop wait in
P [W0, R1, RT, WT, NCS, CS] (0)
Rn (?dn); || P [W1, R0, RT, WT, NCS, CS] (1)
RT (?t); end par
if not (dn) or (t != m) then ||
CS (m); Wm (false); break wait par
end if T [RT, WT]
|| D [R0, W0]
end loop
|| D [R1, W1]
end loop
end par
end var end par
end process end hide
end process
end module
Verification Different kind of choices

• Once the product automation is generated, • External choice (the environment decides
several properties can be verified automatically which branch will be taken)
• For Peterson algorithm: a b The proposed branch by the environment will be
– No deadlock: each state has at least one successor chosen (if a and b proposed, ND choice)
– Mutual exclusion: for i,j ∈ {0,1} not debutsci to
debutscj unless finsci
• Internal choice (the system decide)
– No starvation (pas de famine): no process can
monopolize the critical section a a if the environment propose a, the system will
choose non-deterministically
– Independent progress: each process can have access
to the critical section if the other processes
LTS Comparison Strong Bisimulation

• Due to ND, make attention when comparing 2 • Two state s1 an s2 are bisimilar (s1 ≈ s2) iff:
LTS – For each s1-l->s1’, there is s2’ with s2-l->s2’ and
a a
• A1= a A2= L(A1)={a.b, a.c} s1’ and s2’ are strong bisimilar
b c b c L(A2)={a.b, a.c} – For each s2-l->s2’, there is s1’ with s1-l->s1’ and
• A1 and A2 have a different behavior in s1’ and s2’ are strong bisimilar
practice. • If one condition: simulation
• The equivalence of language is not sufficient • Remark: a bisimulation is more restrictive than
for parallelism theory: more strong two mutual simulations
equivalence are proposed (bisimulations)

Strong Bisimulation: example Double Simulation: example

• ∀ s-l->s’, (∃ t’) such that t-l->t’ et s’ ≈ t’ • Definition: s simulate t (s ~ t) iff
• ∀ t-l->t’, (∃ s’) such that s-l->s’ et s’ ≈ t’ • ∀ t-l->t’, (∃ s’) such that s-l->s’ et s’ ~ t’
s0 t0 s0 t0
a a a a a a
t1 t1’ t1 t1’
s1 c s1 c
b b c b b c
s2 s3 t2 t3 s2 s3 t2 t3
• We have: s2 ≈ t2 and s3 ≈ t3
• We have: s3~t3, s2~t2, s1~t1, s1~t1’ and s0~t0
• We have not: s1 ≈ t1, s1 ≈ t1’ et s0 ≈ t0 t2~s2 and t3~s3
• We have not: t1~s1, t1’~s1 and t0~s0
Double Simulation: Exercise Strong Bisimulation: Exercise

• Definition: s simulate t (s ~ t) iff • s ≈ t iff
• ∀ t-l->t’, (∃ s’) such that s-l->s’ et s’ ~ t’ – ∀ s-l->s’, (∃ t’) such that t-l->t’ et s’ ≈ t’
s0
– ∀ t-l->t’, (∃ s’) such that s-l->s’ et s’ ≈ t’
t0
a a a s0 t0
t1 t1’
s1 a a a
b c b c c t1 t1’
s1 c
s2 s3 t2 t3 b b c c
s2 s3 t2 t3
• We have: s3~t3, s2~t2, s1~t1, s1~t1’ and s0~t0
t2~s2, t3~s3, t1~s1 and t0~s0 • We have: s1 ≈ t1, s2 ≈ t2 and s3 ≈ t3
• We have not: t1’~s1 • We have not: s1 ≈ t1’ et s0 ≈ t0
What is model checking?

“Model checking is the method by which a
desired behavioral property of a reactive
system is verified over a given system (the
model) through exhaustive enumeration
(explicit or implicit) of all the states reachable
by the system and the behaviors that traverse
MODEL CHECKING through them.”
Amir Pnueli
Foreword to Model Checking
[Clarke-Grumberg-Peled-00]

Basic Model Checking Flow
p TEMPORAL LOGICS
q
A Temporal Logic can express Temporal Logic

• “an event A is always possible” • Formalism for describing evolutions of
• “an event A will eventually happen” program states over (logical) time
– Atomic propositions over states
• “an event A is always possible until an event B – Propositional logic operators (or, and, not …)
happens” – Tense operators (neXt, Until, Previous, Since,
Once, …)
Numerous temporal logics were proposed in the – Interpreted on state spaces
literature. • High-level specification style:
abstraction and modularity
Two principal families Linear time logics

Linear time logics VS Branching time logics • LTL operators are evaluated over sets of paths
Traces Vs Branching • over infinite, linear sequences of states:
“s[0] -> s[1] -> ... -> s[t] -> s[t + 1] -> ...”,
– s[t] expresses the tth state of a sequence

Linear time logics Linear time logics

• LTL temporal operators
– “Finally” (or “future”): “F p” is true in s[t] iff
p is true in some s[t’] with t’ > t
– “Globally” (or “always”): “G p” is true in s[t] iff
p is true in all s[t’] with t’ > t
– “Next”: “X p” is true in s[t] iff p is true in s[t + 1]
– “Until”: “p U q” is true in s[t] iff
q is true in some state s[t’] with t’ > t and
p is true in all states s[t”] with t < t” < t’
Branching time logics Branching time logics

• Considers a tree-like structured model of time
• Future is not determined;
there are different paths in the future
• CTL operators are evaluated over trees
• Every temporal operator (F; G; X; U) is preceded by a
path quantifier (A or E)
• A expresses universal modalities (or necessity) (AF;
AG; AX; AU)
• E expresses existential modalities (or possibility) (EF;
EG; EX; EU)
Linear-time vs branching-time State-based vs action-based

Other Temporal logics Acknowledgements

• Handling “data” or not Some of the material presented in these slides is courtesy of the
following people, listed in alphabetical order:
• Handling “time” or not
• Pham Ngoc Hung
• Handling “probability” or not
• Frédéric Lang
• …
• Radu Mateescu
• Laurence Pierre
• Wendelin Serwe
• David R. Wright

MF Merged

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MF Merged

Uploaded by

Copyright:

Available Formats

Introduction to Formal Methods Dr-Ing.

(Mike Holloway, NASA)

Motivations Desired properties of systems

ENSIAS Systèmes Embarqués et Mobiles 2015/2016 1

Critical Systems Safety-Critical Systems

• Safety-critical: trains & planes control, nuclear

Systems whose failure can cause life losses

Business-Critical Systems Mission-Critical Systems

Avionic software standard

ENSIAS Systèmes Embarqués et Mobiles 2015/2016 2

Avionic software standard

Formal Methods Definition Formal Model: a utility by itself!

Example: NASA projects budget

ENSIAS Systèmes Embarqués et Mobiles 2015/2016 3

Code Generation Test Generation

Design Unit Tests Design Unit Tests

Verification Formal Verification

Formal Verification Techniques (1) Static Analysis

ENSIAS Systèmes Embarqués et Mobiles 2015/2016 4

Static Analysis Properties Examples (2) Model Checking

Temporal Logic A Temporal Logic can express

Model Checking Industrial Success of Model Checking

ENSIAS Systèmes Embarqués et Mobiles 2015/2016 5

(3) Theorem Proving Theorem Proving Example

• The argument is valid since ((p q)˄ p) q

Dr. Abderahman KRIOUILE - Introduction to Formal Methods - ENSIAS 2015/2016 33

ENSIAS Systèmes Embarqués et Mobiles 2015/2016 6

From Systems to Models

Transformational programs Reactive programs

• Sequential behavior • Cyclic behavior

ENSIAS Systèmes Embarqués et Mobiles 2015/2016 1

Reactive programs Reactive programs

Finite State Machines (FSM) Finite State Machines (FSM)

Finite State Machines (FSM) Finite State Machines (FSM)

ENSIAS Systèmes Embarqués et Mobiles 2015/2016 2

Labeled Transition Systems (LTS) Labeled Transition Systems (LTS)

Modeling Concurrency Modeling Time

Synchronous Product Asynchronous Product

(tM1, tM2)= (0,0)

ENSIAS Systèmes Embarqués et Mobiles 2015/2016 3

Asynchronous Product Asynchronous Product

Petri Nets Petri Nets

Petri Nets Petri Nets Simulation

ENSIAS Systèmes Embarqués et Mobiles 2015/2016 4

Process Calculus Process Calculus

ENSIAS Systèmes Embarqués et Mobiles 2015/2016 1

Equivalence Automate and Regular

Regular Expression Parallel Operator

Asynchronous Product In LNT

ENSIAS Systèmes Embarqués et Mobiles 2015/2016 2

LNT LNT tutorial: Plan

(1) LNT Modules Sample LNT Modules

ENSIAS Systèmes Embarqués et Mobiles 2015/2016 3

(2) LNT Types & Functions Sample LNT Types

(2) LNT Processes

Dr. Abderahman KRIOUILE - Introduction to Formal Methods - ENSIAS 2015/2016 21

ENSIAS Systèmes Embarqués et Mobiles 2015/2016 4

Example: Modeling using LTSs Peterson Algorithm

G. L. Peterson. Myths about the mutual exclusion problem.

Peterson: P0 and P1 Automata Peterson: d0, d1 and t Automata

P0 automaton: P1 automaton: d0 automaton: d1 automaton:

ENSIAS Systèmes Embarqués et Mobiles 2015/2016 1