Slides - Åbo Akademi
Slides - Åbo Akademi Slides - Åbo Akademi
Software Reliability (ctd.) • Software, unlike hardware, can be fault-free (theoretically :)) • some formal methods can guarantee the correctness of software (proof-based verification, model checking, etc.) • Correctness of software does not ensure its reliability! • software can satisfy the specification document, yet the specification document itself might already be faulty • No independence assumption, i.e., copies of software will fail together • most hardware fault tolerance mechanisms ineffective for software • design diversity instead of component redundancy (e.g., N-version programming )
Design diversity Each variant of software is generated by a separate (independent) team of developers • higher probability to generate a correct variant • independent design faults in different variants Costly, yet leads to an effective reliability improvement Not as efficient as N-modular redundancy in hardware reliability engineering [J. C. Knight and N. G. Leveson, 1986]
- Page 1 and 2: Software Safety Lecture 8: System R
- Page 3 and 4: Reliability Definition Reliability:
- Page 5 and 6: Safety-critical Systems • Pervasi
- Page 7 and 8: Hardware Failures The system is sai
- Page 9 and 10: Failure Rate (ctd.) Classification
- Page 11 and 12: Most Important Distributions Discre
- Page 13 and 14: Reliability Parameters MTTF: Mean T
- Page 15 and 16: Exponential Distribution The distri
- Page 17 and 18: MTTF Example A system with a consta
- Page 19 and 20: Example: Failure Rate Calculation F
- Page 21 and 22: Series Systems Such a configuration
- Page 23 and 24: Series-Parallel Combinations The mo
- Page 25 and 26: M-of-N Arrangement A system consist
- Page 27: Failure rate The term failure inten
Software Reliability (ctd.)<br />
• Software, unlike hardware, can be fault-free (theoretically :))<br />
• some formal methods can guarantee the correctness of<br />
software (proof-based verification, model checking, etc.)<br />
• Correctness of software does not ensure its reliability!<br />
• software can satisfy the specification document, yet the<br />
specification document itself might already be faulty<br />
• No independence assumption, i.e., copies of software will fail<br />
together<br />
• most hardware fault tolerance mechanisms ineffective for<br />
software<br />
• design diversity instead of component redundancy<br />
(e.g., N-version programming )
Change language