1 / 16

Software Engineering for Safety : A Roadmap

Software Engineering for Safety : A Roadmap. Presentation by: Manu D Vij. CS 599 Software Engineering for Embedded Systems. Introduction. Wide Spread Use of Safety - Critical Systems and their reliance on Software “The Nation depends on fragile software”. Keys Areas in SE for Safety.

zephania-estrada
Download Presentation

Software Engineering for Safety : A Roadmap

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. Software Engineering for Safety : A Roadmap Presentation by: Manu D Vij CS 599 Software Engineering for Embedded Systems

  2. Introduction • Wide Spread Use of Safety - Critical Systems and their reliance on Software • “The Nation depends on fragile software”

  3. Keys Areas in SE for Safety • Hazard Analysis • Safety requirements specification and analysis • Designing for safety • Testing • Certification and Standards • Resources

  4. Hazard Analysis • Core of the development of safe systems • Identification and Analysis: • Criticality • Likelihood of Occurrence • Which Hazards to avoid ? • Determination of s/w components that can contribute or prevent hazard • Safety requirements and constraints on design of system

  5. Safety Requirements Specification and Analysis • Formal Specification: • Ease and Accuracy • Investigate if safety properties are preserved • Automated check availability • Interactive theorem provers, Model checkers • Safety  Software Requirements Requirements • SpecTRM ----- Embedded Systems

  6. Designing for Safety • Design for Safety • Prevention • Detection and Control • Design Trade Offs • Safety Vs Other features e.g. Fault Tolerance • Issues involved are moral, legal, finance…… • Vulnerability to simple design errors • Tendency to neglect small errors • “Small Errors have small consequence”– not in Software • Limited use of known design techniques • Good design techniques are ignored

  7. Testing • Critical for safe system in: • Development • Certification • Assumptions about: • Environment • Users • Operations • Is it enough ?

  8. Certification and Standards • Certification • More complicated • Less well defined • Standards • “What standards are appropriate for large, safety-critical systems composed of subsystems from different domains” • Problems: • Lack of guidance in existing standards • Poor integration of software issues with system safety • Heavy burden of making a safety case for certification • Recommendations: • Classifying and evaluating standards according to products, process and resources • Constructing domain specific standards for products

  9. Resources • Books…. Levenson • Bowen’s website…. Publications, Conferences, RISKforum • IEEE video

  10. Directions for future Work • Integration of informal and formal methods • Key Areas: • Automatic translation of informal notation into formal models • Lightweight formal methods • Integration of previously distinct formal methods.

  11. Fault Trees • hazard events represented by nodes • AND/OR gates • domino effect • errors in the requirements phase example taken from: http://www.cs.cmu.edu/~koopman/des_s99/safety_critical/

  12. Directions…………. • Constraints on safe product families and safe reuse • Two key research areas: • Safety Analysis of product families • A Goal • Safety reuse of COTS software • Two Problems

  13. Directions…….. • Testing & Evaluation • Requirements-based testing • Evaluation from multiple sources • Model consistency • Virtual environment simulations • Runtime monitoring

  14. Directions….. • Education: • Scientific rather than methodical courses • Textbooks • Awareness • Related Fields • Security & Survivability • Techniques quite similar • Security Vs Safety • Software Architecture • Safety consequence of flexible architectures • Evaluation of architectures for safety critical product families • Partitioning to control hazards enabled by shared resources • Architectural solutions to the need for “techniques that augment the robustness of less robust components • Human Factors Engineering • Better understanding of usage patterns, and formal specification of operator's mental model can yield more accurate safety requirements and safer maintenance. • More research needed. • Other fields • Domain specific design for fault tolerance • Advances in OS, Programming Language

  15. Conclusion.... • Safety is system problem • Advancement in the other fields will enhance safety • Protecting devices….Are they enough ?? Safety into system! • Probabilistic risk assessment is not enough!! • Advancement is safety analysis is required

More Related