410 likes | 494 Views
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. Outline of Presentation. Introduction Brief ASTRAL overview
E N D
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
Outline of Presentation • Introduction • Brief ASTRAL overview • Property classifications • Process classifications • Transition classifications • Conclusion
Real-Time Systems Untimed + Concurrency + Asynchrony + Time + Reactivity + Nondeterminism = Difficult to analyze
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
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
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
Classification Schemes • Distinct proof styles • Statically recognizable • ASTRAL classifications • Property classifications • Process classifications • Transition classifications
Outline of Presentation • Introduction • Brief ASTRAL overview • Property classifications • Process classifications • Transition classifications • Conclusion
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
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
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
Outline of Presentation • Introduction • Brief ASTRAL overview • Property classifications • Process classifications • Transition classifications • Conclusion
Property Classifications • Untimed properties • Timed liveness properties • Forward • Backward • Timed safety properties • Forward • Backward
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
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}
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
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
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
Forward vs. Backward • The execution tree of a process
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
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))
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))
Outline of Presentation • Introduction • Brief ASTRAL overview • Property classifications • Process classifications • Transition classifications • Conclusion
Process Classifications • Multi-threaded process • Iterative single-threaded process • Simple single-threaded process
Multi-Threaded Process • Multiple independent threads interleaved on a single process
Liveness Properties in a Multi-Threaded Process • Must take scheduling policy into account • Example: fixed priority scheduling
Iterative Single-Threaded Process • Cyclic behavior with stored iteration count
Liveness Properties in anIterative Single-Threaded Process • Properties may need to be proved between arbitrary values of the iteration count
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
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)
Outline of Presentation • Introduction • Brief ASTRAL overview • Property classifications • Process classifications • Transition classifications • Conclusion
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
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
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
Outline of Presentation • Introduction • Brief ASTRAL overview • Property classifications • Process classifications • Transition classifications • Conclusion
Conclusions • Three classification schemes were developed from existing specifications • Property classifications • Process classifications • Transition classifications • Statically recognizable • Each aids in the proof process
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?
The End • For complete details, see dissertation... • http://www.cs.ucsb.edu/~kolano