Formally Specified Monitoring of Temporal Properties

1. Formally Specified Monitoring of Temporal Properties Moonjoo Kim, M. Viswanathan, H. Ben-Abdallah, S. Kannan, I. Lee and O. Sokolsky Computer and Information Science Department University of Pennsylvania

2. Outline • Motivation • Issues in Run-time Formal Analysis • Overview of Monitoring and Checking(MaC) Framework • The MaC Language • Primitive Event Definition Language (PEDL) • Meta Event Definition Language(MEDL) • The Current MaC Prototype System • Conclusion • Current and Future Work

3. Problems • Safety-critical real-time systems are hard to guarantee correctness. • Two traditional approaches to certify correctness of systems • Testing can not guarantee correctness of application completely. • Formal verification lacks scalability and does not apply to implementation directly • gap between models and implementations • We need a new approach - run-time formal analysis

4. Example Showing Deficiencies of the Traditional Methods • Railroad Crossing RRC = (Train | Controller | Gate) \ {nearSig,passSig, lower, raise} • Non-deterministic execution of RRC makes complete testing almost impossible. • Formal design of RRC assumes communication among a Train, a Controller and a Gate happens instantly. But, communication in actual implementation takes time !

5. Advantages of Run-time Formal Analysis • Run-time formal analysis validates properties on current execution of application. The execution is monitored for compliance with formal requirements. • The analysis can • detect incorrect execution of applications and • predict error and steer computation • measure statistics of actual execution (ex. a number of times train passes an intersection ) which can not be measured in either testing or formal verification • increase the assurance of applications

6. Issues in Run-time Formal Analysis • An expressive formal language describing correctness criteria • A proper granularity of monitoring • Automatic v.s. Manual instrumentation • Synchronous v.s. Asynchronous monitoring • Side effect of instrumentation to a target system Program Execution Abstract View Monitor Sees x=0,y=0 x < 2 x=1,y=0 Information Extraction x=2,y=0 x =2 x=2,y=1 x=3,y=1 x> 2 x=3,y=2

7. Human Monitoring Script low level description high level description Automatic Instrumentation Automatic Translation Automatic Translation low-level events high-level events System Filter Event Recognizer Run-time Checker Monitoring and Checking(MaC) Framework Java Program Requirement Spec Input Static Process Run-time Process

8. The MaC Language • Primitive Event Definition Language (PEDL) • The language maps the low-level state information of the system to high-level events used in describing the requirements. • Provides primitives to refer to values of variables and to certain points in the execution of the program • 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.

9. Primitive Event Definition Language (PEDL) • Information about the system comes in two different forms: • Conditions, which are true or false for a finite duration of time (e.g., is variable x >5?), and • Events, which are either present or absent at some instant of time (e.g., is the control right now at the end of method f?) • Provides primitives to refer to values of variables and to certain points in the execution of the program. • condition IC = (50<train_position) && (train_position<100); • Event endGD = start_m(Gate.gu()); • Provides primitive “time” to refer to time when events happen • condition slowTrain = (time(endIC)-time(startIC)) > 3000;

10. 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. • SafeProp safeRRC = IC -> GD; • alarm violation = start (!safeRRC); • Auxilliary variables may be used to store history. • endIC-> { num_train_pass++; }

11. Legend Green : program variables and methods Blue : event Orange : condition Red : property Railroad Crossing Example MonScr RailRoadCrossing export event startIC, endIC, startGD, endGD; MonVarDcl : float RRC.train_x; int RRC.train_length; int RRC.cross_x; int RRC.cross_length; MonMethodDcl: Gate.gd(); Gate.gu(); CondDef: Cond IC= RRC.train_x+RRC.train_length>RRC.cross_x&& RRC.train_x<=RRC.cross_x+RRC.cross_length; EventDef: Event startIC = start(IC); Event endIC = end(IC); Event startGD = end_m(Gate.gd()); Event endGD = start_m(Gate.gu()); End ReqSpec RailRoadCrossing import event startIC, endIC, startGD, endGD; AuxVar int num_train_pass = 0; CondDef: Cond IC = [startIC, endIC]; Cond GD = [startGD, endGD]; Cond slowTrain = time(endIC)-time(startIC) > 3000; SafePropDef: SafeProp safeRRC = IC -> GD; endIC -> { num_train_pass ++; } End

12. The Current MaC Prototype System • MaC instruments Java bytecode, not a source code. • Filter resides in the host of target program as a separate thread. • Whenever monitored variables are changed or specified execution points are reached, the filter sends updated value and time stamp to the event recognizer. • Whenever an event-recognizer receives new information from filter, it evaluates condition and event description and sends evaluation result to the run-time checker. • MaC works on multi-threaded applications

13. Conclusion • A MaC framework conducts a run-time formal analysis based on monitoring script written in PEDL/MEDL. • This framework can detect incorrect execution of applications and increase the assurance of applications. • Current MaC prototype works on target application written in Java. However, MaC framework can be extended to applications written in any language. • Case Studies: • Railroad Crossing Systems • Web-based Database Client • A simulator of Micro Air Vehicle of Naval Research Laboratory

14. Current and Future Work • Performance Tuning of Prototype Implementation • Three Valued Logic • Steering • Functional Checking • Monitoring Distributed Systems • Application Area • Monitoring security property in mobile program • http://www.cis.upenn.edu/~rtg/mac