Software Engineering for Safety : A Roadmap Presentation by: Manu D Vij CS 599 Software Engineering for Embedded Systems.

Slides:



Advertisements
Similar presentations
Integra Consult A/S Safety Assessment. Integra Consult A/S SAFETY ASSESSMENT Objective Objective –Demonstrate that an acceptable level of safety will.
Advertisements

Trusted Computing in Government Networks May 16, 2007 Richard C. (Dick) Schaeffer, Jr. Information Assurance Director National Security Agency.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Object-Oriented Software Development CS 3331 Fall 2009.
What is software? Computer programs and associated documentation
1 Chapter 4 - Part 1 Software Processes. 2 Software Processes is: Coherent (logically connected) sets of activities for specifying, designing, implementing,
Chapter 4 Quality Assurance in Context
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Software Processes Coherent sets of activities for specifying, designing, implementing and testing software systems.
Extensibility, Safety and Performance in the SPIN Operating System Presented by Allen Kerr.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 24 Slide 1 Critical Systems Validation 2.
Presented by: Thabet Kacem Spring Outline Contributions Introduction Proposed Approach Related Work Reconception of ADLs XTEAM Tool Chain Discussion.
Software Reuse Building software from reusable components Objectives
CS599 Software Engineering for Embedded Systems1 Software Engineering for Real-Time: A Roadmap Presentation by: Mandar Samant Raghbir Singh Banwait.
SWE Introduction to Software Engineering
Ensuring Non-Functional Properties. What Is an NFP?  A software system’s non-functional property (NFP) is a constraint on the manner in which the system.
1 Software Architecture: a Roadmap David Garlen Roshanak Roshandel Yulong Liu.
Presentation R. R. Lutz. Analyzing Software Requirements Errors in Safety-Critical Embedded Systems. In Proceedings of the IEEE International Symposium.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Process Models.
SWE Introduction to Software Engineering
1 FM Overview of Adaptation. 2 FM RAPIDware: Component-Based Design of Adaptive and Dependable Middleware Project Investigators: Philip McKinley, Kurt.
Department of Computer Science & Engineering College of Engineering Dr. Betty H.C. Cheng, Laura A. Campbell, Sascha Konrad The demand for distributed real-time.
DITSCAP Phase 2 - Verification Pramod Jampala Christopher Swenson.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Course Instructor: Aisha Azeem
Testing safety-critical software systems
Chapter 3 Software Processes.
IT:Network:Microsoft Applications
© DEEDS – OS Course WS11/12 Lecture 13 – OS Dependability and Fault Tolerance 1 Administrative issues Lab 5 Friday, Feb. 10 th 13:00-15:00 (and 15:00-17:00)
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse.
What is Software Engineering? the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software”
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
Computer Science Open Research Questions Adversary models –Define/Formalize adversary models Need to incorporate characteristics of new technologies and.
Software Processes lecture 8. Topics covered Software process models Process iteration Process activities The Rational Unified Process Computer-aided.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 1 Software Processes l Coherent sets of activities for specifying, designing,
Protecting the Public, Astronauts and Pilots, the NASA Workforce, and High-Value Equipment and Property Mission Success Starts With Safety Believe it or.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
Proof Carrying Code Zhiwei Lin. Outline Proof-Carrying Code The Design and Implementation of a Certifying Compiler A Proof – Carrying Code Architecture.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
1 Introduction to Software Engineering Lecture 1.
Model Checking and Model-Based Design Bruce H. Krogh Carnegie Mellon University.
Secure Systems Research Group - FAU SW Development methodology using patterns and model checking 8/13/2009 Maha B Abbey PhD Candidate.
Safety-Critical Systems 7 Summary T V - Lifecycle model System Acceptance System Integration & Test Module Integration & Test Requirements Analysis.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 9 Slide 1 Critical Systems Specification 1.
Software Safety Case Why, what and how… Jon Arvid Børretzen.
Chapter 13: Software Life Cycle Models Omar Meqdadi SE 273 Lecture 13 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Software Architecture Evaluation Methodologies Presented By: Anthony Register.
Over View of CENELC Standards for Signalling Applications
Requirements Engineering-Based Conceptual Modelling From: Requirements Engineering E. Insfran, O. Pastor and R. Wieringa Presented by Chin-Yi Tsai.
1 INTRUSION TOLERANT SYSTEMS WORKSHOP Phoenix, AZ 4 August 1999 Jaynarayan H. Lala ITS Program Manager.
SAFEWARE System Safety and Computers Chap18:Verification of Safety Author : Nancy G. Leveson University of Washington 1995 by Addison-Wesley Publishing.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
Safety Assessment: Safety Integrity Levels
Choosing a Formal Method Mike Weissert COSC 481. Outline Introduction Reasons For Choosing Formality Application Characteristics Criteria For A Successful.
CEA LIST Expression of interest: dt-fof
Software Processes (a)
Component Based Software Engineering
Model-Driven Analysis Frameworks for Embedded Systems
The Extensible Tool-chain for Evaluation of Architectural Models
CSSSPEC6 SOFTWARE DEVELOPMENT WITH QUALITY ASSURANCE
The Extensible Tool-chain for Evaluation of Architectural Models
Automated Analysis and Code Generation for Domain-Specific Models
Software Engineering for Safety: a Roadmap
Reliability and Safety
Luca Simoncini PDCC, Pisa and University of Pisa, Pisa, Italy
Presentation transcript:

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 Wide Spread Use of Safety - Critical Systems and their reliance on Software “The Nation depends on fragile software” “The Nation depends on fragile software”

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

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

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

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

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

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

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

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

Fault Trees hazard events represented by nodes hazard events represented by nodes AND/OR gates AND/OR gates domino effect domino effect errors in the requirements phase errors in the requirements phase example taken from: man/des_s99/safety_critical/

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

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

Directions….. Education: Education: –Scientific rather than methodical courses –Textbooks –Awareness Related Fields Related Fields –Security & Survivability Techniques quite similar Techniques quite similar Security Vs Safety Security Vs Safety –Software Architecture Safety consequence of flexible architectures Safety consequence of flexible architectures Evaluation of architectures for safety critical product families Evaluation of architectures for safety critical product families Partitioning to control hazards enabled by shared resources Partitioning to control hazards enabled by shared resources Architectural solutions to the need for “techniques that augment the robustness of less robust components 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. 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. More research needed. –Other fields Domain specific design for fault tolerance Domain specific design for fault tolerance Advances in OS, Programming Language Advances in OS, Programming Language

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