Monitoring, Checking and Steering of Real-Time Systems Moonjoo Kim SECUi.com Insup Lee, Usa Sammapun, Jangwoo Shin, Oleg Sokolsky University of Pennsylvania Workshop on Runtime Verification 7/26/2002

Run-time Formal Analysis Run-time formal analysis ensures the run-time compliance of an execution of a system with its formal requirement. The analysis validates properties on the current execution of application. The analysis can detect incorrect execution of applications predict error and steer computation collect statistics of actual execution Run-time formal analysis ensures the run-time compliance of an execution to its formal requirement. Also, run-time formal analysis validates properties on the current execution of application. The analysis can detect incorrect execution of application. In railroad crossing system, the monitor can detect gate is not completely down when train enters the crossing. In addition , the analysis can predict error and steer the computation. In railroad crossing system, if we monitor the speed of train and the speed of lowering gate, we can expect whether or not the safety violation will happen. If violation is expected, we can decrease the speed of the train. Also, run-time formal analysis can measure the statistics of acutual execution. There are several issues of run-time formal analysis. Let us look at these issues. Workshop on Runtime Verification 7/26/2002

Workshop on Runtime Verification MaCS Methodology System Spec Formal verification Requirement Spec System Implementation Monitoring Data Design Event Recognizer + Checker System Filter Communication Run-time Check Workshop on Runtime Verification 7/26/2002

Workshop on Runtime Verification MaCS languages PEDL Run-time state: control locations object state local variables Abstract state: events conditions auxiliary variables SADL MEDL PEDL: abstraction MEDL: abstract transformation SADL: feedback Workshop on Runtime Verification 7/26/2002

Meta-Event Definition Language MEDL script: Declares abstract state variables var int controller; Defines events and conditions event invokeSafeController = start(outOfTrack || overVolts) when (controller == 1); Specifies updates to variables and steering invocations in response to events invokeSafeController -> { controller' = 0; invoke change2SC(); } Workshop on Runtime Verification 7/26/2002

Workshop on Runtime Verification Property checking A MEDL specification can be seen as an automaton with auxiliary store running on a stream of events provided by the event recognizer aux. variables Workshop on Runtime Verification 7/26/2002

Data extraction and event detection PEDL script describes monitored objects in the program, statically identifying them in the code defines events in terms of monitored objects Technical challenge: all updates to the monitored objects must be detected Workshop on Runtime Verification 7/26/2002

Steering Action Definition Language SADL script identifies object used in steering // the target of steering is the object dm of type DecisionModule // located in the class IP DecisionModule IP:dm; defines steering actions // setSC() method of dm is invoked steering action change2SC = { call (IP:dm).setSC(); } specifies steering conditions locations in the code where the actions can be executed before read DecisionModule:volts; Workshop on Runtime Verification 7/26/2002

Workshop on Runtime Verification Steering process action invocation received steering condition satisfied violation action executed system event received action invoked detection checker Workshop on Runtime Verification 7/26/2002

Implementation of steering Injector class: Action bodies as methods Listener thread accepts action invocations and sets invocation flags Calls to action bodies at fixed locations defined in the steering script, added by instrumentation Injector class Checker execution invoke Invocation flags test steering conditioni satisfied i n Action bodies steering conditioni satisfied i call n Workshop on Runtime Verification 7/26/2002

Steering as fault tolerance Application needs support Environment may be adverse Is it too late to steer after a violation? Faults and failures a failure is a disastrous event a fault is an abnormal behavior that may lead to a failure faults are tolerated, failures must be avoided Use monitoring to detect faults, use steering to prevent failures Workshop on Runtime Verification 7/26/2002

Steering as security watchdog Application needs restraint Behavior of the application is bad Security policy: An application cannot create files more than 5MB in size Solution: Monitor calls to FileOutputStream and calculate the number of written bytes Detect violations and steer What should the steering action be? Workshop on Runtime Verification 7/26/2002

Steering as security watchdog Possible steering actions: Kill the application call System.exit() or throw an exception Prevent the application from violating the requirement close the file X Quietly divert the application redirect output to /dev/null V Workshop on Runtime Verification 7/26/2002

Workshop on Runtime Verification Steering as recovery Application needs help We expect to have recovery functions to be included in the application Case study ([ICIIS99]): pattern formation Hexagonal formation of a large number of particles based on local interactions Particles cannot be controlled individually, but commands can be broadcast If a problem with formation is found, there is a command to re-form Workshop on Runtime Verification 7/26/2002

Workshop on Runtime Verification Steering as control Application needs guidance There are no violations per se, but rather a degradation of some quality measure The function computed by application is known The monitor observes the state of the application and computes control signal standard control-theoretic problem formulation Case study: inverted pendulum based on the Simplex architecture Workshop on Runtime Verification 7/26/2002

Simplex Architecture (courtesy L. Sha) us Safety x0 EX Decision Module u x Physical System Experimental ue SC Equilibrium state Experimental controllers provide improved performance but uncertain stability properties Can be dynamically added or replaced Safety controller has the largest stability region Workshop on Runtime Verification 7/26/2002

Inverted Pendulum (courtesy L. Sha) q x g M uf State vector: Hard constraints: The control problem is solved using LMI and LQR and the linearized dynamics of the system. Soft constraints: A performance index, e.g., Relative stability in time domain or frequency domain Bandwidth The stability region is given by Workshop on Runtime Verification 7/26/2002

Inverted Pendulum in MaCS Experimental Controller Experimental Controller Experimental Controller Safety Controller angle, track monitor Device Drivers J N I Decision Module Switching logic volts steer Workshop on Runtime Verification 7/26/2002

Workshop on Runtime Verification Case study results It works! Without disturbance, there is slightly more jitter partly due to instrumentation but mostly due to Java Switch to the safety controller takes 0.32s (16 control cycles) bad values compensated by the safety controller in general may not be good enough Workshop on Runtime Verification 7/26/2002

Workshop on Runtime Verification Future Work Synchronous vs. asynchronous steering currently: the application and may produce erroneous outputs when checking is slow May be unacceptable in critical situations alternative: before producing critical output, pause and wait for checker feedback IP case study suggests it is possible in some cases Need predictable checker turnaround Currently work in progress Workshop on Runtime Verification 7/26/2002

Workshop on Runtime Verification Future Work Static analysis to enhance steering currently, user is responsible for specifying steering locations – error prone control flow analysis can identify locations by code-independent criteria e.g. “steering location is visited once in each main loop iteration” or even “if action changes variable x, do not place before the system writes x” What are the right criteria? Study other uses of steering Workshop on Runtime Verification 7/26/2002