Software Safety CS3300 Fall 2015. Failures are costly ● Bhopal 1984 – 3000 dead and 200000 injured ● Therac-25 1987 – 6 dead ● Chernobyl / Three Mile.

Slides:



Advertisements
Similar presentations
Accident and Incident Investigation
Advertisements

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 20 Slide 1 Critical systems development 2.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 20 Slide 1 Critical systems development.
Chapter 7 - Software Development1 Chapter 7 Software Development A Textbook aimed at protecting consumers Software Quality Links Ian Foster and Grid Computing.
Safety in large technology systems October, 1999.
Reliability Risk Assessment
Overview Lesson 10,11 - Software Quality Assurance
Building Reliable Software Requirements and Methods.
Software Fault Tolerance – The big Picture RTS April 2008 Anders P. Ravn Aalborg University.
1 Software Testing and Quality Assurance Lecture 38 – Software Quality Assurance.
SWE Introduction to Software Engineering
CSC 402, Fall Requirements Analysis for Special Properties Systems Engineering (def?) –why? increasing complexity –ICBM’s (then TMI, Therac, Challenger...)
7/3/2015IENG 475: Computer-Controlled Manufacturing Systems 1 IENG Lecture 04 Manufacturing Safety.
©Ian Sommerville 2004Software Engineering, 7th edition. Insulin Pump Slide 1 An automated insulin pump.
 Lionel Briand Safety Analysis.  Lionel Briand Safety-critical Software Systems whose failure can threaten human life or cause serious.
Testing safety-critical software systems
1 Software Testing Techniques CIS 375 Bruce R. Maxim UM-Dearborn.
What is Fault Tree Analysis?
SAFE 605: Principles of Safety Engineering Overview of Safety Engineering Safety Engineering Concepts.
STAMP A new accident causation model using Systems Theory (vs
PHILOSOPHY OF ACCIDENT PREVENTION
Software Dependability CIS 376 Bruce R. Maxim UM-Dearborn.
Worksite Hazard Analysis
CSCI 5801: Software Engineering
SEDS Research GroupSchool of EECS, Washington State University Annual Reliability & Maintainability Symposium January 30, 2002 Frederick T. Sheldon and.
Hazard Identification
EE551 Real-Time Operating Systems
Quantitative Decision Making and Risk Management CS3300 Fall 2015.
Objectives Understand the basic concepts and definitions relating to testing, like error, fault, failure, test case, test suite, test harness. Explore.
SAFETY.
ESRD Network 6 5 Diamond Patient Safety Program
WHAT IS SYSTEM SAFETY? The field of safety analysis in which systems are evaluated using a number of different techniques to improve safety. There are.
HEALTH & SAFETY – LONE WORKING
Layers of Protection Analysis
Presentation of Failure- Oblivious Computing vs. Rx OS Seminar, winter 2005 by Lauge Wullf and Jacob Munk-Stander January 4 th, 2006.
FAULT TREE ANALYSIS (FTA). QUANTITATIVE RISK ANALYSIS Some of the commonly used quantitative risk assessment methods are; 1.Fault tree analysis (FTA)
Chapter 20 A Safe and Healthy Environment. Lecture Overview Employee Safety Principles of Safety Program Implementation of Safety Program Health Work.
Software Testing and Quality Assurance Software Quality Assurance 1.
1 Safety - definitions Accident - an unanticipated loss of life, injury, or other cost beyond a pre-determined threshhold.  If you expect it, it’s not.
Hazard Identification
Quality Assurance.
This Project is funded by the European Union Project implemented by Human Dynamics Consortium This project is funded by the European Union Projekat finansira.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 9 Slide 1 Critical Systems Specification 1.
Job Safety Analysis.
WHAT IF ANALYSIS USED TO IDENTIFY HAZARDS HAZARDOUS EVENTS
SAFEWARE System Safety and Computers Chap18:Verification of Safety Author : Nancy G. Leveson University of Washington 1995 by Addison-Wesley Publishing.
EFFECTIVE ACCIDENT/INCIDENT INVESTIGATION 15 FEBRUARY 2013 PHILIPPINE ASSOCIATION OF SAFETY ENGINEERS -QATAR- -QATAR- COMMITTEE ON SAFETY EDUCATION 2013.
1 Software Testing and Quality Assurance Lecture 38 – Software Quality Assurance.
Employee Safety Awareness Training. Welcome and Objectives Welcome to this web-based training about workplace safety. This course will:  Provide information.
Fault Tree Analysis for Fatality Prevention Dr. Steven A. Lapp President - Design Sciences, Inc.
Fault Tree Analysis for the BLEDP Student meeting Vegard Joa Moseng.
Failure Modes, Effects and Criticality Analysis
SENG521 (Fall SENG 521 Software Reliability & Testing Preparing for Test (Part 6a) Department of Electrical & Computer Engineering,
Safety Management Systems Session Two Safety Risk Management APTA Webinar April 28, 2016.
Process Safety Management Soft Skills Programme Nexus Alliance Ltd.
October 22, 2005 Parvaiz Ahmed Khand An Overview of Software Safety.
Recognizing and controlling workplace hazards. Objective To explain a job hazard analysis and encourage employees to recognize and evaluate workplace.
Introduction to Safety Engineering for Safety-Critical Systems Seo Ryong Koo Dept. of Nuclear and Quantum Engineering KAIST Lab. Seminar.
Testing Tutorial 7.
Dept. of Nuclear and Quantum Engineering
Layers of Protection Analysis
Safety and Risk.
Quality Risk Management
Air Carrier Continuing Analysis and Surveillance System (CASS)
Reporting Incidents and Hazards Accident Prevention
CAKE Q2 Total Awareness.
Critical Task Analysis
Knowing When to Stop: An Examination of Methods to Minimize the False Negative Risk of Automated Abort Triggers RAM XI Training Summit October 2018 Patrick.
NASA Secure Coding Rules
Layers of Protection Analysis
Presentation transcript:

Software Safety CS3300 Fall 2015

Failures are costly ● Bhopal 1984 – 3000 dead and injured ● Therac – 6 dead ● Chernobyl / Three Mile Island ● Challenger Shuttle

Culture ● The general attitude and approach to safety reflected by those who participate in that industry. ● Accidents come from: ● Overconfidence and complacency – Three mile island – faith in equipment – Shuttle – routine operations ● Disregard or low priority for safety – Bhopal – training cuts for staff ● Flawed resolution of conflicting goals – Challenger – pressure to lauch vs. safety

System Safety ● Build in safety, not add it on later ● Consider system as a whole, not subsystems ● Take larger view of hazards than just failures ● Analysis over experience and standards ● Qualitative over quantitative approach ● Tradeoffs and conflicts are important in design ● System Safety is more than systems engineering

Definitions ● Reliability: probability that a piece of equipment will perform its intended function satisfactorily for a prescribed time under stipulated conditions ● Failure: nonperformance or inability of the system to meet its intended function for a specified time under specified conditions ● Error: design flaw or deviation from intended state ● Accident: Undesired and unplanned (but maybe not unexpected) event that results in loss

More definitions ● Hazard: set of conditions that together with environment will lead to an accident ● Risk: hazard level combined with likelihood of accident (danger) and hazard duration (latency) ● Safety: Freedom from accident or loss

Models of Accident Analysis ● Domino Theory ● Environment > Person > Act > Accident > Injury ● National Safety Council ● background factors > initiating factors > intermediate factors > immediate factors > measurable results ● unsafe condition > agent of accident > increase in potential > unsafe act > injury ● Chain of Events – single event sets off path to accident

Fault Tree Analysis Wrong Treatment for patient Vital Signs show Incorrect state Correct state but Untimely reaction OR Measurement Frequency Too low Computer fails To raise alarm Vital signs Not reported Nurse does Not respond OR Computer does Not read within Time limit Human sets Frequency too low OR Sensor Failure Human error On input AND

Event Tree Pressure Too High Relief Valve 1 Relief Valve 2 Opens Fails Pressure Decrease Pressure Decrease Explosion

Software Safety ● Requirements Complete/Consistent ● Behavior deterministic ● Robustness ● Every state must have a transition for every possible event ● Transitions out of a state must form tautology ● Behavior specified for timeouts (no input for some period) ● HCI Criteria ● Safety critical outputs checked for reasonableness

● All specified states must be reachable from start state ● No paths to unplanned hazardous states ● Every hazardous state has a path to a safe state

Safety Design ● Hazard elimination (Substitution, Simplification, Decoupling, Human error, materials) ● Hazard reduction (Controllability, safety factors, redundancy, recovery) ● Hazard control (limit exposure, isolation, protection system) ● Damage minimization

New Model ● STAMP : Systems Theoretic Accident Model and Process ● STPA : System-Theoretic Process Analysis

STPA Step 1 ● Identify potential for inadequate control of the system ● A control action required for safety not provided or followed ● An unsafe control action is provided ● A potentially safe action is provided at wrong time ● A control action required for safety is stopped too soon or applied too long

STPA Step 2 ● Determine how each action in step 1 could occur ● Examine parts of control loop. Design controls and measures. For multiple controllers, identify conflicts and coordination problems ● Consider how controls could degrade over time and build in protection – Management of procedures – Audits – Accident and incident analysis

NASA 10 Rules of Development Language Choice == Not one of the rules but very important. Need mature compilers with extensive code checking. ● 1. Restrict all code to very simple control structures. No goto, setjmp/longjmp, direct or indirect recursion. ● 2. All loops must have a fixed upper bound. Must be able to prove a loop terminates. Exception are for loops not meant to terminate, then inverse of above must be true.

NASA 10 rules 3. No dynamic memory allocation after initialization. Garbage collectors and malloc can cause unpredictable issues. 4. no function longer than can be printed on a single sheet of paper. 5. code should average 2 assertions per function. Assertions must be side-effect free. 6. Data items must be declared at the smallest possible scope. 7. Return value of non-void functions must be checked.

NASA 10 rules 8. Use of preprocessor must be limited to header inclusion and simple macros 9. Use of pointers should be limited. No more than one level of dereferencing is allowed. Function pointers are not permitted. 10. Code must be compiled with all compiler warnings enabled at most pedantic setting. Code must not have any warnings. Code must be checked by 2 different code analyzers and pass with no warnings.