5/24/01 1 SDRL & RTG University of Pennsylvania Run-time Monitoring and Checking Based on Formal Specifications Insup Lee Department of Computer and Information Science University of Pennsylvania 24 May 2001 Joint work with M. Kim, M. Viswanathan, S. Kannan, and O. Sokolsky
28
Embed
SDRL & RTG University of Pennsylvania 5/24/01 1 Run-time Monitoring and Checking Based on Formal Specifications Insup Lee Department of Computer and Information.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
5/24/01
1
SDRL & RTGUniversity of Pennsylvania
Run-time Monitoring and Checking Based on Formal Specifications
Insup LeeDepartment of Computer and Information Science
University of Pennsylvania
24 May 2001
Joint work with M. Kim, M. Viswanathan, S. Kannan, and O. Sokolsky
5/24/01
2
SDRL & RTGUniversity of Pennsylvania
Objectives• Specification and verification
– complete analysis, all behaviors are correct– gap between abstract model and
implementation• Testing
– tested behaviors are correct– not complete
• Run-time behavior checking– consistency between abstract model and
implementation• To provide a framework for automatic generation
of monitors and checkers
5/24/01
3
SDRL & RTGUniversity of Pennsylvania
Fundamental Issues
• How does a monitor gather information from a running system?
• How does the monitor relate to requirements?
• How do we integrate dynamic monitoring with static analysis?
• Can monitor be used to steer a system?• What mathematical guarantees do monitors
provide?
5/24/01
4
SDRL & RTGUniversity of Pennsylvania
Monitorable Properties• Run-time monitoring and checking checks whether
properties are violated or not by observing only finite traces execution at run-time
• A class of monitorable properties is a Turing computable subset of safety properties – Safety property: finite trace reveals violations.– Monitorable property: violations Turing
computable.• Equivalent to class 1 in the Arithmetic Hierarchy
Liveness
Safety
MEDL = Monitorable property
Properties on Traces
Safety closure of the halting problem
5/24/01
5
SDRL & RTGUniversity of Pennsylvania
System SpecSystem
Spec
RequirementSpec
RequirementSpec
Formal verification
Design
SystemImplementation
SystemImplementation
MonitoringScript
MonitoringScript
Implementation
Checker/CorrectorChecker/Corrector
SystemSystem FilterCommunication
Run-time Check
MaCS Framework
EventHandler
EventHandler
CorrectorCorrector
CheckerChecker
5/24/01
6
SDRL & RTGUniversity of Pennsylvania
Design Issues
• Filter– passive versus active– when to take snapshot
• Event Handler– mapping between concrete state and
abstract event• Checker
– inclusion based on trace, ready semantics, bisimulation
• Corrector– how to provide feedback
5/24/01
7
SDRL & RTGUniversity of Pennsylvania
Overview of MaCS framework• Based events and conditions• Two types of abstraction
– time abstraction by instrument filter (IF)– data abstraction by event recognizer (ER)
• Meta Event Definition Language (MEDL)• Expresses requirements using the events and conditions,
sent by event recognizer.
• Describes the safety requirements of the system, in terms of conditions that must always be true, and alarms (events) that must never be raised.– property periodic = (period == 1000)
– alarm staleData = oldDataUsed when connected
• Auxiliary variables may be used to store history.– request_info -> { num_hits’ = num_hits+1; hit_ratio’ = num_hits/num_fails; }