On Methods for the Formal Specification of Fault Tolerant Systems
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

On Methods for the Formal Specification of Fault Tolerant Systems

on

  • 213 views

 

Statistics

Views

Total Views
213
Views on SlideShare
209
Embed Views
4

Actions

Likes
0
Downloads
2
Comments
0

1 Embed 4

http://www.linkedin.com 4

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

On Methods for the Formal Specification of Fault Tolerant Systems Presentation Transcript

  • 1. On Methods for the Formal Specification of Fault Tolerant Systems Manuel Mazzara - Newcastle University DEPEND 2011 – The Fourth International Conference on Dependability 24/8/2011 Nice, France [email_address]
  • 2.  
  • 3. Overall View Study on Methods (Formal) Methods Definitions HJJ paper (PF + RG + DC) Examples Motivations Tools and Ideas PF Robustness Rely Problem Diagrams Context Diagrams Patterns PQ Fault as interference Ideal FT operations Research Challenges Case Studies RG
  • 4. Our trip
  • 5. A schema for methods evaluation Defining precise steps for the method
  • 6. Formal Methods and SW life cycle
    • ” Formal methods are methods that use mathematics and
    • logic to introduce rigor into the software life cycle. By rigor
    • we mean logically accurate, precise and unambiguous”.
  • 7. Applications?
  • 8. Keeping an eye on the real world… “ Man has such a predilection for systems and abstract deductions that he is ready to distort the truth intentionally, he is ready to deny the evidence of his senses only to justify his logic” (Fyodor Dostoyevsky)
  • 9. Are Formal Methods actual methods?
    • The majority of formal methods are not methods at all because they lack one or more of the components defined in [*]
    • ” Most typically formal methods have a strong language and underlying computational model but lack defined steps and guidance for applying the method”
    [*] Klaus Kronl ő f, editor Method integration: concepts and case studies John Wiley & Sons, Inc., New York, NY, USA, 1993
  • 10. Definition of method
    • “ Dubium Sapientiae initium“
      • Doubt is the origin of wisdom (René Descartes)
    ” A method is a way, technique, or process of or for doing something” It is worth noting that the definition of method depends on the one of process: ” a series of actions or operations conducing to an end” Websters dictionary
  • 11. The method of science* * Rene Descartes: Discourse on Method and Meditations 1. Accept only that which you are sure of 2. Divide each difficulty into small parts 3. Solve problems in an ascending order 4. Assure nothing was omitted
  • 12. We worked on case studies…
  • 13. Descartes + Case Studies
    • 1. Structured
      • phases, steps, work-flow
    • 2. Formally defined
      • unambiguous
    • 3. Usable
      • by non experts
    • Scalability
      • non ”ad hoc”
    • 2. Abstractions
      • what and not how
    • 3. Extensibility to FT
      • LFTS
    Product Process
  • 14. The Evaluation Schema
    • An underlying computational model
      • the structures that are represented, manipulated and analyzed
    • 2. A language
      • the concrete means of describing the product of the method
    • 3. Defined steps and ordering
      • the activities performed by the user
    • 4. Guidance for applying the method
      • informal text description, example case studies
      • manuals, handbooks, guides
    Product Process
  • 15. In Paris now…
    • Problems in the real world are described in terms of what we perceive and do , not in terms our brain functioning!
    • Brain/mind system cannot acquire information about the world (it can only do that through eyes, ears…)
    • It can modify the world only through arms, voice….
    • Similar philosophy for computer systems consisting of sensors and actuators
  • 16. The Method’s Steps
    • Defining the boundaries of system
    • Identify and record assumptions
    • Derive the specification
    • (Make-it robust)
    Digital System Interface to the physical world Define system boundaries Derive spec of the digital system 3 1 Expose assumptions about the world 2
  • 17. From the Ideal World to the Real Thinking how to cope with Fault Tolerance
  • 18. The Plato’s Matrix
  • 19. Escape the cave (safely)!
    • A model of the system
      • Faults has to be viewed as interference
      • Determined abnormal situations considered
      • Error Injector contracted by R/G (or similar)
    • The basic idea of layering vs. monolithic
  • 20. “ There are no facts, only interpretations” (Friedrich Nietzsche)
  • 21. The Model
    • Error Injector: a model of the erroneous behavior of the environment
      • EI always plays its role respecting the provided R/G
    Global state P 1 “ Error” Injector RH 1 P 2 RH 2 Recovery mode Normal mode
  • 22. Monolithic vs. Layered
    • Monolithic specifications would not be intelligible
      • including high and low frequency situations all together
    • The specification can be organized in (at least) two layers (ideal/real)
      • Layered Fault Tolerant Specification (LFTS)
      • Specification organized considering normal/abnormal cases explicitly
  • 23. Main Achievements of this research
    • An understanding of what a method is
    • An evaluation schema
    • A formalization of the three step method
    • The addition of the fourth “make-it robust” step
    • 5. (Experimentation on a practical case studies)
  • 24. Questions? "Did science promise happiness? I do not believe it. It promised truth, and the question is to know if we will ever make happiness with truth." (Emile Zola)