Presentation is loading. Please wait.

Presentation is loading. Please wait.

Run Time Monitoring of Reactive System Models Mikhail Auguston Naval Postgraduate School Mark Trakhtenbrot Holon Academic Institute of.

Similar presentations


Presentation on theme: "Run Time Monitoring of Reactive System Models Mikhail Auguston Naval Postgraduate School Mark Trakhtenbrot Holon Academic Institute of."— Presentation transcript:

1 Run Time Monitoring of Reactive System Models Mikhail Auguston Naval Postgraduate School maugusto@nps.edu Mark Trakhtenbrot Holon Academic Institute of Technology marktr@openu.ac.il

2 Outline Problems in development of reactive systems Model-based development and analysis Our approach:  TL-based assertion language  Automatic generation of monitors for run-time verification Outline of translation scheme Further steps

3 Why development of reactive systems is difficult? Main problem: complex behavior  Intricate event-driven interaction with the environment  Concurrency and timing factors Typically:  Critical applications (embedded RT controllers, …)  Must fulfill tough reqs (safety, timeliness, … ) Challenges:  Capture reqs; design; check that system meets its spec

4 So, what to do? Apply formal methods! Precise spec of behavior:  TL [Pnueli, …] (future/past modalities: LTL; timing: MTL)  templates for typical properties [Avrunin, …] (response, precedence, existence, absence,…) Model-based development:  formal model of system (behavior, structure, …)  Harel statecharts to capture behavior; a renown standard  executable model; a basis for automated tools  model-level analysis (closer to problem domain)

5 Example: Early Warning System

6 Model-based analysis with Statemate Simulation: check, record and replay test scenarios Verification: based on predefined assertion templates Code synthesis: executable C, for host or target OS Watchdog charts for execution monitoring: - co-executed with the system model - property violation: entering into ERROR state

7 Sample monitor chart Assertion: Processing of a request must be accomplished - within 5 seconds - before receiving the next request WaitProcessError Request Processing Done Request or Timeout(5) /Violation Notification

8 Our approach: Statemate-based run-time verification Main new features:  TL-based assertion language to spec behavior  Automatic creation of monitor charts from assertions Used Statemate capabilities:  Co-translation of model and monitors to C  Monitoring of code execution

9 Advantages of the approach Flexible assertion language vs. predefined patterns Smooth transition: assertions  executable monitors Overcome limitations of simulation and verification

10  Analyze models reflecting design decisions (tasks/events mapping,…), in realistic target environment  Real time analysis - rather than SIM time SIM synch time (clock-driven systems): all reactions assume same duration SIM asynch time (event-driven systems): all reactions assume zero duration  No "finite state" limitation may connect to real input sources

11 Assertion language  Boolean expressions: system state properties in(S) and (x > 5) ; entered(S)  started(A) ; ch(d)  Regular expressions: describe sequences of states [SELECT (Open | Read | Write | Close) FROM execution] SATISFY Open (Read | Write )* Close  Temporal formulas: order properties ALWAYS (request  EVENTUALLY response) ALWAYS (execute  SOMETIME_WAS do_set_up)  Timed temporal formulas: real-time restrictions ALWAYS (request  EVENTUALLY (10) response)  Actions: to trace interesting events (e.g. property violation) reports, profiling info (based on objects’ attributes)

12 More on TL formula classification Basic formula: no temporal operators Restricted formula: EVENTUALLY(15) (ALWAYS(30) p) ALWAYS(30) (p  EVENTUALLY(15) q) Unrestricted formula:  nesting depth <= 2 for unrestricted future operators (following Manna&Pnueli for LTL)  unrestricted operator not embedded in a restricted one

13 Semantic issues  Monitoring: deals with finite runs; semantics of TL – based on infinite runs  [Eisner, et.al.]: reasoning on truncated executions  We follow the neutral view  Assume the run finishes 4 sec after the last p ALWAYS (p  EVENTUALLY(10) q) ; false if no q after the last p ALWAYS (p  ALWAYS(10) q) ; true if always q after the last p  In general: user responsible to provide proper actions

14 Example - assertion for EWS ALWAYS (OUT_OF_RANGE  EVENTUALLY (15) (RESET or started(PRINT_ALARM))) ON_FAIL [printf(“Violation after occurrence of OUT_OF_RANGE at time %f “, OUT_OF_RANGE.occur_time)]

15 Sample monitor construction ALWAYS (OUT_OF_RANGE  EVENTUALLY (15) (RESET or started(PRINT_ALARM))) / ERROR_MESSAGE

16 Translation of restricted formula ALWAYS (N) P

17 Translation of unrestricted formula ALWAYS (P)

18 Further steps Implementation:  done - experiments with manually created monitors  next step – actual implementation A more friendly assertion language  e.g. combine English with formulas Optimized translation for certain types of assertions Apply to other design paradigms using statecharts  e.g. in OO: monitor systems with dynamically created objects (problematic for model checking)

19 Run Time Monitoring of Reactive System Models Thanks for your attention

20 More on temporal properties Manna & Pnueli Classification (P – past formula) :  Safety: ALWAYS (P), Guarantee: EVENTUALLY (P)  Obligation: Boolean combination of safety & guarantee  Response: ALWAYS (EVENTUALLY(P))  Persistence: EVENTUALLY (ALWAYS(P))  Reactivity: Bool. combination of response & persistence  Any TL formula is equivalent to a Reactivity formula Limitations:  nesting depth <= 2 for unrestricted future operators  unrestricted operator not embedded in a restricted one


Download ppt "Run Time Monitoring of Reactive System Models Mikhail Auguston Naval Postgraduate School Mark Trakhtenbrot Holon Academic Institute of."

Similar presentations


Ads by Google