1. Program verification in software-based experimental facilities
Dimitri Papadimitriou
Alcatel-Lucent Bell Labs
MERMAT Pre-FIA Workshop
May 7, 2013
Dublin, Ireland

2. Outline Context, motivations and objectives Definitions
Verification methods
Verification strategies
Research challenges
26/04/2019

3. Context: today's experimental systems and platforms
Repetition of functionality across multiple layers (e.g. monitoring, and security component associated to each protocol) and proliferation of protocol variants (at same layer) all derived from a kernel of common primitives
=> need for common and generic functional modules
Limited capability to functionaly evolve over time
=> need to program node (and network) functions at running time
Limited capability to meet perf.objectives and perform/operate under
Increasing variability and uncertainty of external events
Increasing variability of internal events (increasing heterogeneity of substrate)
=> need to automate functional adaptation
26/04/2019

4. Context: software-defined experimental systems and platforms
Today's Experimental System
Tomorrow's Programmable System
Application
Monitor
Security
Security
Store
TCP
Monitor
Security
Decide
Process
Network (IP)
Monitor
Security
Analyze
Data Link Layer
Monitor
Security
...
Monitor
Transmit
Mod1
Mod2
Modn …
Libraries
Libraries
Abstraction layer
Operating System
Operating System
System designed to support any protocol stack
Dynamic and variable binding between programmable functional modules
Sequence of programmable functions determined at running time
 Move from off-line verification at design-time to on-line verification at running time
System designed to support exactly this protocol stack
Static and invariant binding between modules (stacked layers)
Sequence of pre-programmed functions determined at design time
26/04/2019

5. Formal characterization: system and its dynamics
Functional organization : driven at running time by dynamic composition of relationships between programmable functions instead of being exclusively characterized by fixed / static relationships predetermined at design time
Characterization of the system dynamics taking into account
Variability of the different properties of the information
Impact on the relationship between the (sub-)functions of the system
Operations of adding/removing a set of functional relationships between existing functions can be performed as long as at least one directed (non-cyclic) path exists
x(t0) f1 f2
x(t1) f1 f2
x(t2) f1 f2 f3 f3 f3
F(x) f4
F(x) f4
F(x) f4
At t0: F(x)=f4(f3(f2(f1(x))))
At t1: F(x)=f4(f3(f2(f1(x))f1(x)))
At t2: F(x)=f4(f3(f1(x)))
26/04/2019

6. Reliability
Reliable: probability that the function F performs its intended operation during a specified period of time under stated conditions F F
x(t1)
y(t1)
...
x(tn)
y(tn)
Time t1
Time tn
 [t1,tn] such that  k  N, 1 ≤ k ≤ n
y(tk) = F(x(tk))  y(tk)  [a,b] F F
x(tk)
y(tk)
x'(tk)
y'(tk)
Time tk
Time tk
 [t1,tn] and , d << 0 such that  k  N, 1 ≤ k ≤ n
if x'(tk) = x(tk)  d then y'(tk) = y(tk)  e
26/04/2019

7. Verifiable
Verifiable: knowing the input, the output of function F: x(t) → y(t) = F(x(t)) can be confirmed against a formal model H: x(t) → H(x(t)) => correctness
One often considers that verifiability is achieved by comparing the output against a reference system RS (assumed as representative of the real system) 
x(tk) F
y(tk)
x(tk) H
H(x(tk))
Time tk
Time tk
 H: n → : x → H(x) and e << 0
such that H(x(tk))  [y(tk)-e;y(tk)+e] xu F yu
xrs RS
yrs
System u
Ref.sys
 u  S and e << 0 such that if xu = xrs
then yrs  [yu-e;yu+e]
26/04/2019

8. Verifiability Performance Fidelity Scale Real User Traffic? Complexity
Open
Simulation
medium no
yes
Emulation
low
Software Switches
poor
NetFPGA
high
Network Processors
Vendor Switches
Revision: Rob Sherwood, An experimenter’s guide to Openflow, GENI experimenter’s workshop 2010
26/04/2019

9. Verification Verification Distinction between
Demonstrates correctness of a design in conformance with its specification
Does not demonstrate correctness of specification itself
Distinction between
Formal verification = prove mathematically (in ideal case full coverage of the design space)
Formal equivalence verification (equivalence checking): compares two models to check their equivalence
Formal properties verification
Functional verification: black box
Structural (or architectural) verification: white box
26/04/2019

10. Functional Verification (1)
Functional verification: the function/procedure under verification is observed as a “black box”
The choice of input for functional verification is based on the requirement or design specification of the program under verification
Mainly focuses on external behavior of the function: treats the program as a "black box", examining functionality without any knowledge of internal implementation –
 Verification of what the function is supposed to do, not how it does it
Can prove presence of error, but cannot prove absence of errors
26/04/2019

11. Functional Verification (2)
Black-Box Approach
No knowledge of the internal operations or implementation
Examine the input and output in order to determine if the model is working correctly based only on information gathered from the outputs (must infer internal operations without being directly able to observe them)
Verification
Function is exercised over a range of inputs, and the outputs are observed for correctness
Need to understand the function and be able to predict the outputs based on the inputs
Motivations
Focused on verifying the intent of a design rather than the implementation => no reason to examine the internal state of the module
Separate the design from the verification
26/04/2019

12. Structural Verification
Structural verification: the function under verification is observed as a “white box”
Selection of input based on the realization of the function
Objective: cause the execution of specific sequences/paths or branches in the corresponding procedure(s)
Expected results are evaluated on a set of coverage criteria. Examples of coverage criteria include path coverage, branch coverage, and data-flow coverage
Structural testing highlights on the internal structure of the function/procedure under test
White-Box approach: examine inner workings of the program by directly monitoring internal states to determine if correct behavior can be observed
26/04/2019

13. Formal Property Verification
Objective: demonstrate correctness of a program design in conformance with its formal specification
Note: does not validate/demonstrate correctness of the specification itself
Basic steps
Property specification: using a formal language to specify the functional requirements (properties) and behaviors of a function taking into account performance constraints
Def.: a language is called formal if it has a precisely defined semantics that relates the syntactical form of a specification in the language with a precisely defined semantic domain
Analysis: using a procedure to establish that requirements (properties) hold
Example: model checking (MC) = method to automatically decide whether a temporal logic formula is satisfied in a FSM model
Automatic method for verifying finite state concurrent systems
Formal method for proving functional properties (specifications) on the behavior of the system design
Proving a property: show that it holds for all possible input combinations, across all execution paths
26/04/2019

14. Formal Verification Hierarchy
Space Coverage
Higher-Order (HO) Theorem Proving
Examples: Isabelle/HO Logic (HOL), Prototype VerificationSystem (PVS)
First-Order Theorem Proving
Examples: ACL2, Otter
Formal properties verification: TL-based model checking
Model Checking
Formal equivalence verification (equivalence checking): compares two models to check their equivalence
Equivalence Checking
Simulation
Degree of Automation
26/04/2019
source: ASPDAC/VLSI 2002 Tutorial, 2002

15. Model Checking: Overview
To overcome common errors in design of distributed systems
Deadlock
Livelock, starvation
Underspecification
Overspecification
Model checking [Clarke&Emerson 1981]: automated technique that, given a finite-state model of a system and a logical property, systematically checks whether this property holds for (a given initial state in) that model
Model checker: generates complete state diagram of model M (state transition graph or Kripke structure) and its property j; outputs
True (if property j holds)
False (and produces a counter- example=execution violating the property j)
System Design
Property j
Modeling
Model (M) of the system M
Model Checker
M ⊨ j
Yes/No
Check if M satisfies j
Program Code

16. Model Checking
Input
Model and Initial State: convert a design into a formalism accepted by a model checking tool
Program design modeled as an automaton
Representation as state graph: states and state transitions
Specification: state the properties that the design must satisfy; often expressed in temporal logic (which can assert how system behavior evolves over time)
Propositional logic with temporal aspect: describes ordering of events without explicitly using the concept of time
Linear Temporal Logic (LTL): add temporal operators to predicate logic (addition of predicates and quantifiers to basic Boolean logic)
Computational Tree Logic (CTL): formulas are constructed from path quantifiers and temporal operators
Verification (automatic): visit each state and evaluate specification
Proving a property: show this property holds for all possible input combinations, across all execution paths)
Output
Terminates with positive answer when property holds for the original state graph
It produces a counterexample, otherwise
26/04/2019

17. Explicit Model Checking
Model Checker input
Kripke structure M represents a finite state concurrent system
Kripke structure M = (S,I,R,L): a nondeterministic FSM whose states are labeled with boolean variables, which are the evaluations of expressions in that state
Define Kripke structure M = (S,I,R,L) over set of atomic propositions (AP) which model boolean properties of the system
S : finite set of states of the system
I  S : set of initial states of the system
R  S × S : state-transition relation
L : S → 2AP : function which labels each state to a set of properties (atomic propositions) that hold true in the corresponding state
26/04/2019

18. Model Checking Problem
Given a Kripke structure M = (S, I, R, L) that represents a finite state concurrent system and a temporal logic formula f expressing some desired specifications
Find all states s in S of M that satisfy f : { s  S | M, s |= f }
and check if initial states are among these (the system satisfies the specification provided that all of the initial states are in the set)
First algorithms for solving model checking problem
Explicit representation of Kripke structure M as a labeled, directed graph:
nodes represent reachable states S
edges represent state transition relation R (given by pointers)
labels associated to the nodes describe the function L : S → 2AP
26/04/2019

19. Explicit Model Checking
MC perform a full state-space exploration (visit each state and evaluate specification) based on which it decides whether the properties hold (or how could a property be violated – produces counterexample upon failure)
=> Explicit model checking tools face a combinatorial state-space explosion problem (number of states in the global state transition graph was too large to handle)
26/04/2019

20. TL-Based Model Checking
TL-based: method to automatically decide whether a Temporal Logic (TL) formula is satisfied in a FSM model
Automatic method for verifying finite state concurrent systems
Formal method for proving functional properties (specifications) on the behavior of program design
Model checker
Kripke Model 𝓜
Büchi
automaton A𝓜
True (property holds for the original state graph)
Check that 𝓜 ⊨ j
by checking that
ℒ(A𝓜) ∩ ℒ(A¬j) = ∅
False (produces a counter-example)
Convert a design into a formalism accepted by a model checking tool
Property j
LTL-formula ¬j
Informally: Check if language L of the system automaton M is contained in the language accepted by the property automaton
A_M is a Büchi Automaton equivalent to Kripke model M (which represents all and only the executions of M)
A_phi is a Büchi Automaton which represents all and only the paths that satisfy -phi (do not satisfy phi)
Input
Model and Initial State: convert a design into a formalism accepted by a model checking tool; design often modeled as automaton
- States and State transitions
- Often represented as state graph
Specification: properties that the design must satisfy; (often) expressed in temporal logic (which can assert how system behavior evolves over time)
 Propositional logic with temporal aspect
Describes ordering of events without explicitly using the concept of time
Several variants
i) Linear Temporal Logic (LTL): add temporal operators to predicate logic (addition of predicates and quantifiers to basic Boolean logic)
ii) Computational Tree Logic (CTL): formulas are constructed from path quantifiers and temporal operators
Automatic Verification
Visit each state and evaluate specification
Output
Terminates with a positive answer when the property holds for the original state graph
Otherwise, it produces a counterexample
Convert ¬j to Büchi automaton A¬j
so that ℒ(¬j) = ℒ(A¬j)
Property specification: using a formal language specify the functional properties and their behavior (taking into account performance constraints) that the design must satisfy
Analysis: prove a property by showing it holds for all possible input combinations, across all execution paths (visit each state and evaluate specification)
Def.: Temporal logic: propositional logic with temporal aspect (describes ordering of events execution without explicitly using the concept of time)

21. Symbolic Model Checking [McMillan, 1992]
McMillan: by using a symbolic representation (based on reduced ordered binary decision diagrams, Bryan, 1986) for the transition graphs, much larger systems could be verified
Symbolic MC
Uses Boolean encoding for sets of states (assuming that system behavior is determined by n Boolean state variables v1,v2,..., vn)
Represent state-transition relation T as a Boolean function in terms of the state variables: T(v1,v2,..., vn,v'1,v'2,..., v'n)
Select binary encodings of states and input alphabet
Next-state behavior described as a relation by characteristic function
Representation of the state transition graph by means of ordered Binary Decision Diagrams (BDDs): data structure representing a Boolean function by propositional directed acyclic graph (PDAG) consisting of several decision nodes and terminal nodes
current state
next state
26/04/2019

22. Limitations State explosion problem
Particularly in software design since less regularity than circuits
Formal verification more commonly used in hardware design
Models are (often) approximations of real systems; abstraction of details allows for tractable models
Incorrect models or specifications may produce incorrect results
Note: only checks specifications provided; no guarantee that specification covers all properties that should be satisfied
26/04/2019

23. Partial Order Reduction (POR)
Verifying software causes serious problems for model checking because of state explosion phenomenon
Software input "less predictible" (uncertainty)
Concurrent software is usually asynchronous, that is, most of the activities taken by different processes (functions) are performed independently, without a global synchronization (no clocking)
Note: in synchronous systems, concurrent transitions are executed simultaneously rather than being interleaved
The most successful techniques for dealing with this phenomenon are partial order reduction (POR) techniques
Make it possible to decrease the number of interleaving sequences that must be considered
Exploit the independence of concurrently executed transitions: two transitions are independent of each other when executing them in either order results in the same global state
When a specification cannot distinguish between two interleaving sequences that differ only by the order in which concurrently executed events are taken, it is sufficient to analyze only one of them
26/04/2019

24. Partial Order Reduction (POR)
Objective: reduce the size of the state space that needs to be considered in model checking while preserving the correctness of the property
Concept: dependency relation that exists between transitions
Exploits independence of concurrently executed transitions
Transitions do not disable each other
Commutativity of concurrently executed transitions, which result in the same state (best suited for asynchronous systems)
Method:
Construct a reduced state graph (typically generated using depth-first search)
Model checking algorithm is then applied to the resulting state graph (which has fewer states and edges)
Behaviors of the reduced state graph  subset of the behaviors of the full state graph
Note: the behaviors that are not present do not add any information
26/04/2019

25. Interleaving model Interleaving model for asynchronous systems
Allows concurrent events to be ordered arbitrarily (for synchronous systems, concurrent transitions are executed simultaneously rather than being interleaved)
To avoid discriminating against any particular ordering, events are interleaved in all possible ways (note: ordering between independent transitions is largely meaningless)
Main reason for state space explosion in asynchronous systems
Interleaving model of computation must consider all possible event orderings, in order to avoid the omission of any particular one
Note: for independent transitions this ordering is often irrelevant (since interleaving is introduced to model concurrency)
=> Allowing all possible orderings is a potential cause of the state explosion problem
26/04/2019

26. State Explosion Problem
Example: consider n transitions that can be executed concurrently
=> There are n! different orderings producing 2n different states (one for each subset of the transitions)
If the specification does not distinguish between these sequences (the specification only needs to establish a property that links the initial global state with the resulting state irrespective of the sequence taken between these states)
then it is much more efficient to consider only one sequence with n + 1 states
26/04/2019

27. => To be able to use partial order reduction
Depending on the specification language, it is possible that the property to be verified is actually able to discriminate between behaviors that only differ by this ordering
=> To be able to use partial order reduction
Necessary to have a specification that does not distinguish between such behaviors
Necessary to have procedure that selects a set of behaviors that constitutes the reduced model
Note: if some behavior is not present in the reduced model, an equivalent one has to be included in order to guarantee correctness
26/04/2019

28. State-transition graph M
System modeled as state-transition graph M = (S, I, T, L)
Transition a  T is enabled in state s
if  state s' such that a(s,s') holds
Otherwise, a is disabled in s
Set of transitions enabled in s: enabled(s)
Deterministic transition:  state s there is at most one state s' such that a(s,s')
Path: execution sequences of the system
A path in a state-transition graph M is a finite or infinite sequence p (starting from initial state s0) = s0 -a0-> s1 -a1-> s2 -> ... such that  i, ai(si, si+1) holds
26/04/2019

29. Reduced state-transition graph
Reduced state-transition graph: constructed by applying a modified DFS algorithm on explicit state representation of the system
The search starts with an initial state s0 and proceeds recursively
For each state s it selects only a subset ample(s) of the enabled transitions enabled(s)
The DFS explores only successors generated by these transitions
DFS algorithm constructs the reduced state graph directly
Model checking performed on the resulting reduced state transition graph
Terminates with a positive answer when the property holds for the original state graph.
Otherwise, it produces a counterexample counterexample that may differ from one obtained using the full state graph
26/04/2019

30. => Procedure to compute a suitable set ample(s) for every state s
With POR, only a subset of enabled(s) is expanded at each state s  set of ample transitions at each state (ample(s))
=> Procedure to compute a suitable set ample(s) for every state s
The reduced model is constructed by selecting at each step a subset ample(s) of the transitions which are enabled at the current state s
Systematic computation of ample(s)needs to satisfy three goals
1. When ample(s) is used instead of enabled(s), enough behaviors must be retained so DFS gives correct results
2. Using ample(s)instead of enabled(s)should result in a significantly smaller state graph
To obtain a much smaller state graph
ample(s)has to be significantly smaller than enabled(s)
To ensure correctness of the reduction, ample(s)has to include enough transitions such that for each behavior in the full state graph there is an equivalent behavior in the reduced state graph
Computing ample(s) with a reasonably small overhead so that verification time is not increased compared to full state space search
3. The overhead in computing ample(s) must be reasonably small
26/04/2019

31. Independence relation between transitions
Key issue in POR: select only a restricted number of orderings between transitions for analysis => formalize the concept of transitions that can be reordered
Concept of independence relation between transitions: two transitions a and b  T are independent if they satisfy the following two conditions for each state s  S:
Enabledness condition: two independent transitions that are enabled at a given state cannot disable each other
If a, b  enabled(s)
then a  enabled(b(s)) b  enabled(a(s))
Commutativity condition: the execution of two independent transitions in any order (which is guaranteed to be possible by the enabledness condition) leads to the same state
If a, b  enabled(s) then a(b(s)) = b(a(s))
26/04/2019

32. Independence relation between transitions
Transitions a and b are independent: possible reduction by considering only seq. s0 -a-> s1 -b-> s3 and not s0 -b-> s2 -a-> s3
This reduction may not be necessarily correct because
The checked property might be sensitive to the choice between the intermediate states s1 and s2 and not only the states s0 and s3
The intermediate states s1 and s2 may have other successors (which are significant for verification) in addition to s3, which may not be explored if either is eliminated
=> Additional conditions for the correctness of the reduction s1 s0 s3 s2
26/04/2019

33. Visible and Invisible Transitions
L : S -> 2AP  function that labels (assigns to) each state with a set of atomic propositions
A transition a  T is invisible with respect to some subset AP'  AP if its execution between any two states does not change the labeling with atomic propositions from AP':
a  T is invisible wrt AP'  AP if  pair s, s'  S | a = (s,s'), L(s)  AP' = L(s')  AP'
Thus, a transition is invisible when its execution from any state does not change the value of the propositional variables in AP'
Note: A transition is visible if it is not invisible
26/04/2019

34. Stuttering Equivalence (1)
Stuttering equivalence: two infinite paths p1 and p2 are stuttering equivalent if they have identically labeled states after in each of them, any infinite sequence of identically labeled states is collapsed to a single state
Refers to a sequence of identically labeled states along a path in a Kripke structure M
Can also be defined similarly for finite paths: a finite sequence of identically labeled states is called a block
Intuition: two paths are stuttering equivalent if they can be partitioned into blocks, so states in the kth block of one are labeled the same as states in the kth block of the other (corr. may have different length)
POR produces a structure that is stuttering equivalent to the original state transition graph
26/04/2019

35. Stuttering Equivalence (2)
If transitions a and b are independent: possible reduction by considering sequence s0 -a-> s1 -b-> s3 or s0 -b-> s2 -a-> s3
and transition a is invisible
Then
L(s0) = L(s1) and L(s2) = L(s3)
and paths s0 s1 s3 and s0 s2 s3 are stuttering equivalent s1 s0 s3 s2
26/04/2019

36. Stuttering Equivalence (3)
Commutativity and invisibility allow to avoid generating some of the states when the specification is invariant under stuttering
=> Systematic way of selecting ample(s) for any given state: the reduced model is constructed by selecting at each step a subset ample(s) of the transitions which are enabled at the current state s
Ample sets will be used by the DFS algorithm to construct a reduced state graph so that for every path not considered there is a stuttering equivalent path that is considered (guarantees that the reduced state graph is stuttering equivalent to the full state graph)
Note: state s is fully expanded when ample(s)= enabled(s)=> all successors of that state s will be explored by DFS
POR can be applied "on-the-fly" while performing model checking: generate the reduced state space at the same time as checking for counterexamples for the checked property
26/04/2019

37. Static vs Dynamic POR Static POR algorithms
Given the set of enabled transitions from a state s (enable(s), POR algorithms attempt to explore only a (proper) subset of transitions that are enabled at s, and at the same time guarantee that properties of interest will be preserved  persistent set
Static POR algorithms
Compute persistent set of a state immediately after reaching it (persistent sets computed statically can be very large)
For instance, static analyzer may not be capable to decide whether transitions are dependent or not
Dynamic POR (DPOR) algorithms
Dynamically computes a ample set ample(s) in each explored state
While model checker explores the program’s state space, it sees exactly which threads access which locations
Use to simultaneously reduce the state space while model-checking
26/04/2019

38. DPOR: Dynamic POR (1)
Systematic state space exploration can be performed in a stateless fashion by dynamically executing the program in a DFS order
Instead of enumerating reachable model states as in classic model checkers (static POR), dynamic model checking focuses on exhaustively exploring the feasible executions
Controlling and observing execution of visible operations of all threads
Entire program executed under the control of a dedicated scheduler
Gives permission to, and observes the results of all visible operations
Has full control of every context switch, systematic exploration becomes possible
In this context, backtracking or the rollback of a partially executed sequence is implemented by re-starting the program under different thread schedule
26/04/2019

39. DPOR: Dynamic POR (2) DPOR method
Given a state s, the persistent set of s is not computed immediately after reaching s: static POR restrict the search space to transitions contained in the statically-computed persistent sets for each visited state s, while using dynamic POR further refine these statically-computed persistent sets.
DPOR method
Populates persistent set of s while searching under s according to DFS
The scheduler maintains a search stack S of global states
Each state s in the stack is associated with
set enabled(s) of enabled transitions
set done(s) of thread id's: set of threads that have been examined at s; help generate different (non-equivalent) executions out of s
set backtrack(s): sets of threads that need to be explored from s
The thread identities recorded in backtrack(s)
Note: DPOR is implemented through stateless search, it is completely safe to explore the different transitions in the backtrack sets of states concurrently, and with no (or very little) synchronization
26/04/2019

40. Partial Order Reduction (POR) Usage
POR is typically applied to certain classes of properties
Verify absence of deadlock state
Local property, depends on state of a single process or state of single shared object: the property cannot be changed by the combined effect of two independent transitions, it only depends on local changes
26/04/2019

41. Context: software-defined experimental systems and platforms
Time t0
A node that processes and stores received data before transmission
Security
Store
Decide
Process
Analyze
Monitor
Tx - Rx
Time t1
A node that only processes received data before transmission
Security
Store
Decide
Process
Analyze
Monitor
Tx - Rx
26/04/2019

42. Case 1 Online verification of relations between functions
Detection of all the deadlocks and safety property violations to be guaranteed
Acyclic state sequence
x(t0) f1 f2
x(t1) f1 f2
x(t2) f1 f2 f3 f3 f3
F(x) f4
F(x) f4
F(x) f4
At t0: F(x)=f4(f3(f2(f1(x))))
At t1: F(x)=f4(f3(f2(f1(x))f1(x)))
At t2: F(x)=f4(f3(f1(x)))
26/04/2019

43. Case 1: Reliability ... Time t1 Time tn F F x(t1) y(t1) x(tn) y(tn)
 [t1,tn] such that  k  N, 1 ≤ k ≤ n
y(t1) = F(x(t1))  y(t1)  [a,b],...,y(tn) = F(x(tn))  y(tn)  [c,d]
x(t0) f1 f2
x(t1) f1 f2
x(t2) f1 f2 f3 f3 f3
F(x) f4
F(x) f4
F(x) f4
At t0: F(x)=f4(f3(f2(f1(x))))
At t1: F(x)=f4(f3(f2(f1(x))f1(x)))
At t2: F(x)=f4(f3(f1(x)))
26/04/2019

44. Case 2
Online verification of i) relations between functions and ii) re-programmed functions (f3)
Detection of all the deadlocks and safety property violations to be guaranteed
Acyclic state sequence
x(t0) f1 f2
x(t1) f1 f2
x(t2) f1 f2 f3 g3 g3
F(x) f4
F'(x) f4
F'(x) f4
At t0: F(x)=f4(g3(f2(f1(x))))
At t1: F'(x)=f4(g3(f2(f1(x))f1(x)))
At t2: F'(x)=f4(g3(f1(x)))
26/04/2019

45. Case 2: Reliability ... Time t1 Time tn F F' x(t1) y(t1) x'(tn) y'(tn)
At t1: y(t1) = F(x(t1))  y(t1)  [a,b] ,
At t2 and t3: y'(t2,3) = F'(x'(t2,3))  y'(t2,3)  [c,d] , ...
x(t1) f1 f2
x(t2) f1 f2
x(t3) f1 f2 f3 g3 g3
F(x) f4
F'(x) f4
F'(x) f4
At t1: F(x)=f4(g3(f2(f1(x))))
At t2: F'(x)=f4(g3(f2(f1(x))f1(x)))
At t3: F'(x)=f4(g3(f1(x)))
26/04/2019

46. Method Reactive Anticipative/predictive
Partial order reduction: on-the-fly or dynamic, incremental (preferred)
Incorrect function specifications may produce incorrect results
Only verifies sequences provided; without global state verification no guarantee that the specification (F) still covers all properties that should be satisfied
Anticipative/predictive
Partial order reduction: on-the-fly or dynamic, incremental or full --depends on change rate in relations
Incorrect function specifications may still produce incorrect results (but they can be corrected)
Can verify different sequences provided and possible alternatives (e.g., avoid deadlocks); still requires global state verification to guarantee that specification (F) still covers all properties that should be satisfied
26/04/2019

47. Conclusion Automated verification: we are not yet there… Reliability:
DPOR (suitable for node programs) -> what about network programs ?
Distributed DPOR: distributed verification but not verification of distributed algorithms (multi-agent)
How to account for "uncertainty": possible extension to non-deterministic transition (bounded time period)
Reliability:
Functional adaptation (relation): requires maintaining different "output space"
Functional adaptation (replacement also applicable to add/remove): invalidates classical notion of reliability (specified period not specifiable in advance)
26/04/2019

48. Conclusion
Experimental research (in particular, emulation) using software-defined platforms is confronted to three main challenges
These platforms do not offer sufficient functional flexibility -> need to provide means to program and compose functions at running time
⇒ Higher-level network programming languages and abstractions
2. Need to revisit conventional programming design process (conventional program testing method fails to prove program correctness, i.e., show the presence but not the absence of bugs)
⇒ Automated program verification
3. As experimented processes show increasing complexity, black box and white box techniques will become more time consuming than formal model checking techniques (runs at risk of slowing down the experimental phase)
26/04/2019