CSE 812

Outline Defining Programs, specifications, faults, etc. Safety and Liveness based on the work of Alpern and Schneider Defining fault-tolerance

Defining Programs Goal of this discussion is to extend the concept of programs from programs such as that in C/C++/… to more abstract programs Consider the map of MSU shown on the next page. A robot needs to be programmed so that it can go from point A to point B –Identify a program for such robot

A B

A B

Issues Non determinism –At a certain state, the program is presented from a set of multiple options. –Assumption: the program may choose either of these options non-deterministically. Note that this does not imply any fairness unless assumed otherwise.

Abstraction Thinking of the program as a finite automata

Defining Safety Example: –Consider the arrows in previous picture Intuitively, safety identifies transitions that should not be executed by the program

Defining faults Transient faults Permanent faults –Need for extra variables for modeling

Assumption about Faults At any state, either program transition executes or a fault transition executes Finite occurrence of faults in any computation

Example 2 Peterson’s mutual exclusion algorithm –Two processes State can be n (non critical), t (trying), or c (critical) It is necessary to ensure that both processes are not in state c simultaneously If a process is in state t, then it must eventually go to state c When a process in state n (respectively, t, c) changes its state, it must change it to t (respectively, c, n) –Additional variable turn

Automata for Peterson’s Mutual Exclusion

Example 3 Car climate control –Driver side temperature –Passenger side temperature –Controls for increasing and decreasing temperature –A button for `Sync’ –Minimum and maximum temperature

Automata for Car Climate Control

Use of Invariants

Designing Programs Given an Invariant