1. CSE 812

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

3. 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

4. A B

5. A B

6. 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.

7. Abstraction Thinking of the program as a finite automata

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

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

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

13. 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

14. Automata for Peterson’s Mutual Exclusion

15. 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

16. Automata for Car Climate Control

17. Use of Invariants

18. Designing Programs Given an Invariant