CSCI1600: Embedded and Real Time SoftwareLecture 31: Verification IV

Steven Reiss, Fall 2015

Working with Formula Assume we have a LTL/CTL formula for property

Assume we have a finite state program

Objective: Map the program to a Boolean formula

Create a combined formula for property + program

Prove the combined formula

Last time we showed how to create this formula

Ff(s’) is true if f holds in state s with bit repr s’

Making This Practical

The formulas can be generated but They are going to be very large

Need to both generate and use them efficiently

We need an efficient representation of a formula Easy to operate on (AND/OR/NOT/IMPLIES)

Space efficient

Easy to manipulate by computer

Decision Trees A formula can be written as a decision

tree Each node is labeled with a Boolean

variable

Each node has a true and a false branch out

Leaves are labeled either TRUE or FALSE

Example: A and (B or C) Try d AND (c OR (b XOR a))

What is the size of the tree? Does it have to be this size?

A

B F

CT

T

T

F

F

T

FT

F

Simplifying Decision Trees Most of the decision trees look the same

Extra variables just yield identical subtrees

Trees can be simplified

Simplify the tree into a DAG

There are only two real leaves (merge these)

If two nodes have the same children and the same labels, they can be merged

If both branches of a node go to the same node, the original node can be eliminated

This can be iterated

Worst case size is still exponential, actual size is generally much smaller

The results is a BDD (Binary Decision Diagram)

Ordered BDDs Place an a priori order on the variables as labels

Note that order affects the size

Optimum ordering is NP complete

Logical operations are easy to do on ordered BDDs Complement: flip TRUE and FALSE leaves

AND, OR: Merge the two trees level by level

Ordering makes this easy

Setting result to be AND/OR or merged result

EG and EU

Defined as iterative procedures on BDDs

Stopping at appropriate fixed points (no changes to BDD on next pass)

Model Checking BDDs

Compute the BDD for R(s,t) for the program

Inductively compute F(s) for the formula f

F(S) is true iff f is true in the program F(S) is true iff it is the singleton node True

Otherwise there is a path that shows false

Can use the BDD path to FALSE to find counterexample

BDDs have been used to verify programs with 2^80 states

Handling Real Time

The checking so far used relative time Sometime in the future, eventually

We can’t say after k ms or before k ms

Real time checking We’ve already seen some of this in terms of scheduling

Scheduling theory tells us when we can validly schedule periodic tasks

Provides necessary and sufficient conditions

Can accommodate non-periodic an sporadic tasks as well

How do we merge the two

Real-Time Model Checking

Augment Temporal Logic with real time operators

Discrete case: Count the number of steps

Do assertions in terms of number of steps

This assumes step size (time increment) is constant Hardware has real clocks

Each instruction takes a fixed number of cycles

If we can specify the number of cycles per instruction …

Alternatively, start with timed FSAs to deal with continuous real time

RTCTL: Real-time CTL

Add a new operator f U[a,b] g Called “bounded Until”

f and g are arbitrary formula

[a,b] is a time interval (expressed in steps)

f U[a,b] g is true on a path P = s0 s1 … IFF g holds at some future state s on the path

f is true in all states between s0 and s

The distance form s0 to s is within the interval [a,b]

RTCTL Add a new operator G[a,b] f

Bounded Globally

G[a,b] f is true on a path P = s0 s1 … IFF

f holds for state si where a <= i <= b

Label arcs with a time distance (default 1) This represents the number of cycles consumed here

Add self arcs where appropriate

Assume transition at each time

Note that this is not any more powerful than CTL Can use the X operator accordingly

Using BDDs for Timing Use BDDs to compute timing properties

Minimum and maximum delay

Compute the shortest (longest) path from a starting point to an ending point

Start when condition X holds

End when condition Y holds

Define a function to represent the set of states at distance k

Start with all states satisfying X

Compute from nodes at distance k-1 using R

Then check all these to see if Y holds

Continuous Real Time This is a more difficult problem

But is still approachable

Recall Timed Automata

Finite automata with a finite set of real world clocks

Notion of time

Transitions are instantaneous

Time elapses while automata is in a state

A transition may reset some of the clocks to zero

A clock has a value that is the time elapsed since last reset

Time passes at the same rate for all clocks

Only a finite number of transitions can occur in a finite amount of time

Timed Automata

Clock constraints Associate a guard with each transitioon

Associate an invariant with each state

Time can elapse at state only while invariant is true

Y <= 5Y <= 10X <= 8

Y >= 3, Y := 0

Y >= 4 && X >= 6; X := 0

Proving Properties

Map Timed Automata into infinite state transition graph State in the graph is a state in the TA + clock assignment

Transitions

Delay transition: just increment the clocks

Action: correspond to actual transitions

Problem: Clocks are real time, not discrete

Clock Regions Make all clock-related values integer

Assume all are rational to start with

Multiply by LCM

Identify clock regions representing sets of assignments

If two states corresponding to the same state of the timed automata agree on the integral parts of all clock values and also on the ordering of the fractional parts of all clocks, then the states will behave the same

This lets you create a finite representation

Can also be defined in terms of inequalities

This lets you solve reachability (defining valid transitions)

And you can do model checking on the finite representation

Fault Tolerance We’ve talked about proving properties of systems

This can’t always be done

And even so, it is an approximation

Assumes program is correct

Assumes real world model is correct

Assumes computer and other hardware work correctly

And you can’t prove everything

Embedded systems need to be fault tolerant No other recourse after failure

Fault Modeling

What can fail

How things can fail (failure modes)

Why things might fail (random or combined)

Faults might be permanent, intermittent, or transient

Faults might show up in different ways

Responding to Faults Fault confinement

Limit the effect of a fault to a local subsystem

Defensive programming

Fault detection and location Self tests

If transient, get enough information for later analysis

Fault masking Hide the effect of faults

Retry Transient faults might go away

Disk and memory problems may be transient

Fault Avoidance

Don’t write buggy code Serious testing, defensive programming

Verification

Avoid running devices at their limits

Fault Detection and Recovery

Extreme defensive programming Error checking codes (checksums) for messages

Self-checking and fail-safe logic

Watchdog timers and time-outs

Consistency and capability checks

Duplication (redundancy) This is important in critical, unsupervised systems

Redundancy Triple modular redundancy

Hardware is replicated three times

Outcome of each module (high-level routine) is a vote

If 2 agree on the answer, it is chosen

This fails when All 3 disagree (fail-stop)

Two modules fail together (byzantine)

The voting mechanism fails

Can handle k failures by having higher number of modules

Space Shuttle Redundancy Five computer implement the system

Four make up the primary system

Normally in command; Simultaneously execute identical code

Synchronize on I/O; Actuation is a physical vote

Priority-based OS

The fifth system is the backup

Completely independent implementation

Normally operates in listen-mode; Requires a manual switch-over

OS is time-sliced, not priority scheduled

Still have problems

Same language, same compiler

Fault Recovery What to do if something goes wrong

Keep the system running

Put the system into a stable state

Watchdog timer Monitor routine of sorts

Task code periodically sets a flag

Watchdog (high priority) checks and resets the falg

If flag is unset, restart the system

Care needed to not make things worse

Fault Recovery

Self-checking software With checkpoint and rollback

Correct data defects in memory and continue

Adaptive software

Safe backup state Failure isn’t just CPU failure

Might not want to reboot from stored state

Reset-reboot switches

Fault-Based Disk Partitioning SightPath CDN nodes (cache for media files)

Four disk partitions Boot partition that is never touched

Two OS partitions

Usually mounted read-only

Upgrades are written to the spare partition

Upgrade partition is then remounted read-only and marked clean

Boot partition will not boot from unclean partition

One data partition

All data is soft-state

Similar scheme used in flash-based devices

Next Time

Project status presentations Voluntary

If you aren’t going to be here or aren’t going to give one, provide a project status handin.

Following Wednesday: Guest Speaker

Understanding Faults

Next Time

Voluntary Project Status Updates

and Thanksgiving

Following Wednesday: GUEST LECTURE on SECURITY