Monitoring, Checking and Steering of Real-Time Systems

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

2. 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 Workshop on Runtime Verification

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

4. MaCS languages PEDL • Abstract state: • events • conditions • auxiliary variables • Run-time state: • control locations • object state • local variables • PEDL: abstraction • MEDL: abstract transformation • SADL: feedback SADL MEDL Workshop on Runtime Verification

5. 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

6. 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. 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

8. 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

9. Steering process action invocation received steering condition satisfied violation action executed system event received action invoked detection checker Workshop on Runtime Verification

10. 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 0 i n Action bodies 0 steering conditioni satisfied i call n Workshop on Runtime Verification

11. 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

12. 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

13. 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

14. 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

15. 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

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

17. g l m q uf M x Inverted Pendulum (courtesy L. Sha) 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

18. 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

19. 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

20. 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

21. 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