1 / 11

Talk Outline

Hints for Building Self-* Systems Vijay K. Garg The University of Texas at Austin Austin, TX 78712 email: garg@ece.utexas.edu. Talk Outline. Overview Hints for Self-* Systems Specify : Know your goals Observe : Know your state Keep choices : Know multiple ways Plan : Know your strategy

garima
Download Presentation

Talk Outline

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Hints for Building Self-* SystemsVijay K. GargThe University of Texas at AustinAustin, TX 78712email: garg@ece.utexas.edu

  2. Talk Outline • Overview • Hints for Self-* Systems • Specify: Know your goals • Observe: Know your state • Keep choices: Know multiple ways • Plan: Know your strategy • Control: reconfigure, reset, reorganize, adapt • Paradise

  3. Specify: Know your goals • Biological Systems: goals at multiple levels • Survival, happiness, money, job • Computer Systems are not aware of their goals • At best, we have specs of the programs • Need • Specs at multiple levels • Using Specs for Runtime Verification • Adapting to the environment

  4. Observe: Know your state • Self-awareness: is the state consistent with goals? • Monitoring for system properties • Stable Properties e.g. [Chandy,Lamport 85] • Unstable Properties • Single State based e.g. Linear Predicates [Chase, Garg 95], Relational Predicates [Tomlinson, Garg 96] • Temporal Logic based e.g. Regular CTL [Sen, Garg 04] • Need: • Integration with runtime environments

  5. Choices: Know multiple ways • Determinism considered dangerous • Nondeterminism allows the system to deal with • Faults • Uncertainty • Changing environment • Need • Nondeterministic choice in general prog. Languages (e.g. Dijkstra’s Guarded Command Language) • Support for selective communication (e.g. CSP) • Support for family of modules

  6. Plan: Know your strategy • Know your state space • Exploit what computers are good at • View program as two parts • Finite state part: computer analyzable • Infinite part: trust humans • Lookahead Execution • Computation slicing [Garg, Mittal 2001] • Need • Support for systems with lookahead • Support for on-the-fly model checking

  7. Control: Controlled Execution • Use nondeterminism to your advantage • Try different order of message processing • Impose additional synchronization [Tarafdar, Garg 04] • Supervisory Control of Discrete Event Systems [Ramadge and Wonham 89, Kumar and Garg 95] • Tunable parameters (adaptive control) • Need • execution environments with control • Programming languages that support feedback

  8. Paradise Project Key Abstraction: Global Properties • Model Checking and Verification: Check global properties against model of the program (Promela) • Simulation and Debugging: Global breakpoints, Trace analysis • Fault-Tolerance: Monitoring for global properties, Controlled Re-execution

  9. Observe Program Monitor Slicer Predicate Paradise Environment Control

  10. Paradise Tools • Trace Cover SPIN (Model Checker): alleviating state explosion • Visual Dashboard • Partial Order Trace Analysis (POTA): slicing • Paradise Library: tracking dependency, global snapshot, global properties • Paradise Execution Engine: control

  11. Conclusions • Current execution engines are too primitive to build self-* systems • Need more knowledge • Goals, multiple choices, current state • Research at PDSLAB • www.ece.utexas.edu/~garg/pubs.html

More Related