Download presentation
Presentation is loading. Please wait.
Published byPearl Bridges Modified over 9 years ago
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
Similar presentations
© 2024 SlidePlayer.com Inc.
All rights reserved.