Classification Schemes to Aid in the Analysis of Real-Time Systems

1. Paul Z. Kolano Trusted Systems Laboratories paul.kolano@ trustedsyslabs.com Richard A. Kemmerer University of California, Santa Barbara kemm@cs.ucsb.edu Classification Schemes to Aid in the Analysis of Real-Time Systems

2. Outline of Presentation • Introduction • Brief ASTRAL overview • Property classifications • Process classifications • Transition classifications • Conclusion

3. Real-Time Systems Untimed + Concurrency + Asynchrony + Time + Reactivity + Nondeterminism = Difficult to analyze

4. Proof Assistance Is Needed • Need simplifications and manual abstractions • Need human guidance and intuition • Systematic analysis guidance • How analysis can be performed based on previous experience • How each approach can be used most effectively • How results from different approaches can be combined • Model checkers • Automatically check state space for violations • Theorem provers • Keep reasoning sound, finish off proof details

5. How Can Analysis Be Systematized? • Identify distinct proof patterns • Identify distinguishing features of system specifications that result in each pattern • Divide and conquer • Separate specifications with different patterns • Separate individual proofs into simpler pieces

6. Bakery algorithm Cruise control Elevator control system Olympic boxing scoring system Phone system Production cell Railroad crossing Stoplight control system Small/Large Simple/Complex Open/Closed Deterministic/ Nondeterministic Assumptions not needed/ Assumptions needed Testbed Systems

7. Classification Schemes • Distinct proof styles • Statically recognizable • ASTRAL classifications • Property classifications • Process classifications • Transition classifications

8. Outline of Presentation • Introduction • Brief ASTRAL overview • Property classifications • Process classifications • Transition classifications • Conclusion

9. Railroad Crossing

10. ASTRAL Specification • One or more process type specifications • Each defines an abstract state machine • A global specification • Defines types, constants, etc. shared among process types • Defines number of statically generated instances of each process type in the system • Example: Railroad Crossing specification • Process types  Process instances • Gate  1 Gate instance • Sensor  N_Tracks Sensor instances

11. Types Variables Define state of process Initialization Defines initial values Transitions Define changes to variable values TYPE gate_position: (raised, raising, lowered, lowering) VARIABLE position: gate_position INITIAL position = raised TRANSITION lower ENTRY [TIME: lower_dur] ~ ( position = lowering | position = lowered ) & EXISTS s: sensor_id (s.train_in_R) EXIT position = lowering Process Type Specification

12. Process Interactions

13. INVARIANT Change(train_in_R, now) & ~train_in_R  FORALL t: time ( now - ((dist_R_to_I + dist_I_to_out) / max_speed - response_time)  t & t < now  past(train_in_R, t)) ENVIRONMENT Call(enter_R, now) & EXISTS t: time ( 0  t & t  now & Call2(enter_R, t))  Call(enter_R) - Call2(enter_R) > (dist_R_to_I + dist_I_to_out) / min_speed Requirements Invariants Schedules Assumptions Environment Imported variable Specification of Properties

14. Outline of Presentation • Introduction • Brief ASTRAL overview • Property classifications • Process classifications • Transition classifications • Conclusion

15. Property Classifications • Untimed properties • Timed liveness properties • Forward • Backward • Timed safety properties • Forward • Backward

16. Context and Requirement Times • General form of a property context  requirement • Context times are times referenced in the timed operator expressions of the context • Requirement times are times referenced in the timed operator expressions of the requirement

17. Example of Context and Requirement Times FORALL t: time, s: sensor_id ( Change(s.train_in_R, now - dist_R_to_I / max_speed + response_time) & past(s.train_in_R, now - dist_R_to_I / max_speed + response_time)  EXISTS t: time ( now - dist_R_to_I / max_speed + response_time  t & t  now & past(position, t) = lowered)) • Context times = {now - dist_R_to_I / max_speed + response_time} • Requirement times = {t}

18. Untimed Properties • Context times and requirement times can only be the current time • With only local state variables FORALL d: direction ( Circle(d) = green  Arrow(opp(d)) = red) • With timed operators/imported variables Change(number, now) & Number = 0  ~In_critical

19. State variables only change when transitions end These properties hold if the exit assertion of each transition preserves the property maintaining_speed  cruise_on TRANSITION maintain_speed ENTRY [TIME: input_dur] cruise_on & ~maintaining_speed EXIT cruise_throttle = throttle & desired_speed = speedometer.speed & maintaining_speed Untimed Properties With Only Local State Variables

20. Forward vs. Backward FORALL t: time, s: sensor_id ( Change(s.train_in_R, now - dist_R_to_I / max_speed + response_time) & past(s.train_in_R, now - dist_R_to_I / max_speed + response_time)  EXISTS t: time ( now - dist_R_to_I / max_speed + response_time  t & t  now & past(position, t) = lowered)) Change(train_in_R, now) & ~train_in_R  FORALL t: time ( now - ((dist_R_to_I + dist_I_to_out) / max_speed - response_time)  t & t < now  past(train_in_R, t)) • Forward EXISTS ct: context time FORALL rt: requirement time ct  rt • Backward EXISTS rt: requirement time FORALL ct: context time rt  ct

21. Forward vs. Backward • The execution tree of a process

22. Safety vs. Liveness • Can abstract away details of execution • Must derive exact executions • Safety properties • Must hold at all times in an interval • Liveness properties • Must hold at least once in an interval

23. Safety Properties TRANSITION exit_I ENTRY [TIME: exit_dur] train_in_R & now - Start(enter_R)  (dist_R_to_I + dist_I_to_out) / min_speed - exit_dur EXIT ~train_in_R Change(train_in_R, now) & ~train_in_R  FORALL t: time ( now - ((dist_R_to_I + dist_I_to_out) / max_speed - response_time)  t & t < now  past(train_in_R, t))

24. Liveness Properties FORALL t: time, s: sensor_id ( Change(s.train_in_R, now - dist_R_to_I / max_speed + response_time) & past(s.train_in_R, now - dist_R_to_I / max_speed + response_time)  EXISTS t: time ( now - dist_R_to_I / max_speed + response_time  t & t  now & past(position, t) = lowered))

25. Property Classifications ofTestbed Systems

26. Outline of Presentation • Introduction • Brief ASTRAL overview • Property classifications • Process classifications • Transition classifications • Conclusion

27. Process Classifications • Multi-threaded process • Iterative single-threaded process • Simple single-threaded process

28. Multi-Threaded Process • Multiple independent threads interleaved on a single process

29. Liveness Properties in a Multi-Threaded Process • Must take scheduling policy into account • Example: fixed priority scheduling

30. Iterative Single-Threaded Process • Cyclic behavior with stored iteration count

31. Liveness Properties in anIterative Single-Threaded Process • Properties may need to be proved between arbitrary values of the iteration count

32. Simple Single-Threaded Process • May have cyclic behavior, but iteration count not stored • Properties usually need to be proved over only a single full cycle

33. Process Classifications of Testbed Systems • Multi-threaded processes (2/25) • Central_Control (phone system) • Controller (stoplight control system) • Iterative single-threaded processes (4/25) • Elevator (elevator control system) • Proc (bakery algorithm) • Timer and Tabulate (Olympic boxing system) • Simple single-threaded processes (19/25)

34. Outline of Presentation • Introduction • Brief ASTRAL overview • Property classifications • Process classifications • Transition classifications • Conclusion

35. Transition Classifications • Transition enablement • Local state (L) • External environment (E) • Imported state (O) • Current time (T) • Eight classifications based on these factors • L, E, O, T, EO, ET, OT, EOT TRANSITION lower ENTRY [TIME: lower_dur] ~ ( position = lowering | position = lowered ) & EXISTS s: sensor_id (s.train_in_R) EXIT position = lowering

36. Determining Transition Delays • e.g., L transitions • Local state only changes when transitions end • Must immediately follow previous transition • e.g., T transitions • Delayed from some local state/event • e.g., now – End(trans1)  delay1 • Other transition types • Examine relevant clauses

37. System L E O T EO ET OT EOT Total Bakery Algorithm 4 0 1 1 0 0 0 0 6 Cruise Control 2 9 2 1 0 0 0 0 14 Elevator 0 3 4 3 0 0 2 0 12 Olympic Boxing 0 0 2 2 0 0 1 1 6 Phone 0 2 16 0 7 0 5 0 30 Production Cell 14 0 11 20 0 0 10 1 56 Railroad Crossing 0 1 2 3 0 0 0 0 6 Stoplight 0 2 4 0 0 0 18 0 24 Total 20 17 42 30 7 0 36 2 154 Transition Classifications of Testbed Systems

38. Outline of Presentation • Introduction • Brief ASTRAL overview • Property classifications • Process classifications • Transition classifications • Conclusion

39. Conclusions • Three classification schemes were developed from existing specifications • Property classifications • Process classifications • Transition classifications • Statically recognizable • Each aids in the proof process

40. Future Work • Examine more real-time systems • Are there additional classification schemes that are useful? • Examine other specification languages • Are the existing classification schemes applicable to many specification languages?

41. The End • For complete details, see dissertation... • http://www.cs.ucsb.edu/~kolano