2. Real-time Systems Group University of Pennsylvania 10/13/98 1 Design-time and Run-time Assurance Insup Lee Department of Computer and Information Science University of Pennsylvania Philadelphia, PA

3. Real-time Systems Group University of Pennsylvania 10/13/98 2 People Dr. Funda Ergun (Bell Labs) Prof. Sampath Kannan Moonjoo Kim Hee Hwan Kwak Prof. Insup Lee Dr. Anna Philippou (University of Cyprus) Insik Shin Dr. Oleg Sokolsky Mahesh Viswanathan

4. Real-time Systems Group University of Pennsylvania 10/13/98 3 Run-time Monitoring and Checking (MaC)

5. Real-time Systems Group University of Pennsylvania 10/13/98 4 Motivation and Objective Specification and verification –complete analysis, all behaviors are correct –gap between specification and implementation Testing –tested behaviors are correct –not complete Monitoring and checking (MaC) –ensure the current behavior is correct –consistency between abstract model and implementation –provide a framework for automatic generation of monitors and checkers

6. Real-time Systems Group University of Pennsylvania 10/13/98 5 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?

7. Real-time Systems Group University of Pennsylvania 10/13/98 6 System Spec System Spec Requirement Spec Requirement Spec Formal verification Design System Implementation System Implementation Monitoring Script Monitoring Script Implementation Checker/ Corrector Checker/ Corrector System Filter Communication Run-time Check MaC Architecture Event Recognizer Event Recognizer Corrector Checker

8. Real-time Systems Group University of Pennsylvania 10/13/98 7 Design issues Filter –what, how and when to instrument –distributed monitoring –overheads Event recognizer –mapping between concrete state and abstract event Checker –safety properties, security properties, timing, resource use, QoS –local versus global checking –computation Corrector –how to provide feedback –steering to safe states

9. Real-time Systems Group University of Pennsylvania 10/13/98 8 MaC Prototype Requirement Specification Program (Java source code) Program (Java byte code) Monitoring Script (PEDL) Requirements (MEDL) PEDLCompiler MEDLCompiler Instrumented Code Run-time Checker Event Recognizer Filter Generator (JTREK) Instrumentation Information

10. Real-time Systems Group University of Pennsylvania 10/13/98 9 Primitive Event Definition Language The language maps the low-level state information of the system to high-level events used in describing the requirements. 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?).

11. Real-time Systems Group University of Pennsylvania 10/13/98 10 PEDL Features Provides primitives to refer to values of variables and to certain points in the execution of the program. –condition in_crossing = (train_position < 10) –event inCS = start_m(critical_method) Enables one to write expressions comparing the return value of a method invocation with its call arguments. –event correct = (value(io_m(mult),1) == (value(io_m(mult),2)*value(io_m(mult),3))) Allows the user to invoke methods of the system in the event recognizer for the purposes of program checking. –condition check = (mult(A, B*rand_vect) == A*(B*rand_vect))

12. Real-time Systems Group University of Pennsylvania 10/13/98 11 Meta-Event Definition Language Language used express the requirements of the system, in terms of the events and conditions recognized by the event recognizer. Has similar notions of events and conditions, but is more expressive than PEDL. –Unlike PEDL, it has constructs that help reason about the whole execution seen so far.

13. Real-time Systems Group University of Pennsylvania 10/13/98 12 MEDL Features 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 even = (x%2 == 0) –alarm accident = (enter_crossing) && (gate_up) Has primitives to manipulate auxiliary variables that may be used to record some aspects of the execution seen thus far. –request_info  num_hits++

14. Real-time Systems Group University of Pennsylvania 10/13/98 13 Demo: Railroad crossing RRC Filter Event Recognizer Event Recognizer Checker System Violation Position of trainIn Crossing Violation Train GateController

15. Real-time Systems Group University of Pennsylvania 10/13/98 14 Integration within the MaC framework Proxy server developed at Stanford University –mobile code, java applets Suite of checkers developed at Cornell University –computations such as matrix multiplication, longest common substring, depth first search, FFT, etc.

16. Real-time Systems Group University of Pennsylvania 10/13/98 15 The Specification and Analysis of Real-Time Systems

17. Real-time Systems Group University of Pennsylvania 10/13/98 16 Motivation Correctness and reliability of real-time systems depends on –Functional correctness –Temporal correctness –Failures Factors that affect temporal behavior: –Synchronization and communication –Resource requirements –Availability of resources and scheduling An integrated framework to bridge the gap between concurrency theory and real-time scheduling

18. Real-time Systems Group University of Pennsylvania 10/13/98 17 Objectives 1Development of Design Formalism for Distributed Real-time Systems  Process-Algebra-Based Formalisms  Executable Specifications  Logics for Specifying Properties 2Design of Analysis Techniques  Automated Verification Techniques  Parameterized End-to-end Schedulability Analysis 3Tool Implementation  Graphical & Textual User Interface

19. Real-time Systems Group University of Pennsylvania 10/13/98 18 Specification and analysis ACSR (Algebra of Communicating Shared Resource) –A real-time process algebra which features discrete time, resources and priorities –Timeouts, interrupts and exception handling –Graphical ACSR –PACSR (Probabilistic ACSR) –ACSR-VP (Value Passing) Hierarchical specification and analysis Tools: PARAGON, VERSA Analysis techniques - state space exploration, (symbolic) bisimulation, abstract interpretation, model checking Applications: safety, timing constraints, schedulability analysis, end-to-end design support, etc.

20. Real-time Systems Group University of Pennsylvania 10/13/98 19 Probabilistic ACSR (PACSR) It has two types of actions: –instantaneous events –timed actions PACSR supports probabilistic failure of resource Probabilistic information is defined separately to the specification and is only used during analysis Reachability analysis, model checking

21. Real-time Systems Group University of Pennsylvania 10/13/98 20 Examples A Scheduler A Faulty Channel where pr(channel)= 0.99.

22. Real-time Systems Group University of Pennsylvania 10/13/98 21 (FCh,     (P,       in 0.99 0.01

23. Real-time Systems Group University of Pennsylvania 10/13/98 22 Env AHAS... inout Sched P tc rc kill a A telecommunication example Two versions of the system S 1 : possibility of 1 alarm per time unit, buffer size of 3, capability of processing 2 alarms per time unit S 2 : possibility of 2 alarms per time unit, buffer size of 6, capability of processing 4 alarms per time unit

24. Real-time Systems Group University of Pennsylvania 10/13/98 23 Analysis results -

25. Real-time Systems Group University of Pennsylvania 10/13/98 24 ACSR-VP ACSR with data variables and value passing Provide the general frame for the analysis of real-time scheduling problems with –variable release and execution times –relative timing constraints –dynamic priorities –multiprocessor etc. Based on ACSR-VP and symbolic bisimulation algorithm.

26. Real-time Systems Group University of Pennsylvania 10/13/98 25 Overall Approach System Described with ACSR-VP Solution Space (Ranges of Free Variables) Predicate Equations with Free Variables Predicate Equations with Free Variables Symbolic Weak Bisimulation Linear/Integer Programming Linear/Integer Programming Constraint Logic Programming Theorem Prover

27. Real-time Systems Group University of Pennsylvania 10/13/98 26 Real-time System Design Problems Schedulability Analysis –verify that a system is schedulable, given a certain priority assignment method and execution synchronization method Priority Assignment –assign priorities to jobs so that the system schedulability is maximized Execution Synchronization –decide when to release jobs so that the precedence constraints are satisfied

28. Real-time Systems Group University of Pennsylvania 10/13/98 27 Example of execution synchronization Job 1 s1s1 s 1 +e 1 Job 2 s2s2 s 2 +e 2 [ 5,7 ][ 3,4 ]  25  14  10  12

29. Real-time Systems Group University of Pennsylvania 10/13/98 28 Predicate Equations  ( t < 5  t = s 1  X 2 (0,t+5,s 2 ) ) ) X 0 (t,s 1,s 2 ) = ( t  5  t < s 2 )  X 1 (t+1,s 1,s 2 )  ( t  5  t = s 1 )  X 2 (0,t+5,s 2 )  ( ( t  5  t < s 1  X 1 (t+1,s 1,s 2 ) ) X 1 (t,s 1,s 2 ) = …. X 2 (e,s 1,s 2 ) = …. By symbolic weak bisimulation with infinite idle process, the following set of predicate equations is generated.

30. Real-time Systems Group University of Pennsylvania 10/13/98 29 Solution Space Start time S 1 Start time S 2 34455 14 151415 5 16  The solutions for predicate equations can be obtained in various ways, linear/integer programming techniques or constraint logic programming techniques or theorem prover.  Following table shows the solution for previous example.

31. Real-time Systems Group University of Pennsylvania 10/13/98 30 Current and future work Tool support for ACSR-VP How to construct an ACSR-VP specification for a given scheduling problem? –Develop a general methodology of automated construction of the ACSR-VP specification of scheduling problems. –Develop and maintain a library of reusable template specifications for common scheduling algorithms and system configurations. General-purpose and domain-specific templates can be used.