CSE 466 – Fall 2000 - Introduction - 1 Safety  Examples  Terms and Concepts  Safety Architectures  Safe Design Process  Software Specific Stuff 

Slides:



Advertisements
Similar presentations
Development of Tools for Risk Assessment and Risk Communication for Hydrogen Applications By Angunn Engebø and Espen Funnemark, DNV ICHS, Pisa 09. September.
Advertisements

EECE499 Computers and Nuclear Energy Electrical and Computer Eng Howard University Dr. Charles Kim Fall 2013 Webpage:
Chromium OS Chase Rogers. User Interface Unobtrusive Use small amount of screen space Combine apps and web pages into one tab strip Floating Windows Search.
Figures – Chapter 12.
Chapter 21: Product Issues Design of Biomedical Devices and Systems By: Paul H. King Richard C. Fries.
SWE Introduction to Software Engineering
Critical Systems Specification
CSE 466 – Fall Introduction - 1 Design for Safety 1.Hazard Identification and Fault Tree Analysis 2.Risk Assessment 3.Define Safety Measures 4.Create.
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...)
©Ian Sommerville 2004Software Engineering, 7th edition. Insulin Pump Slide 1 An automated insulin pump.
Testing safety-critical software systems
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 1 Systems engineering 1.
Software Dependability CIS 376 Bruce R. Maxim UM-Dearborn.
Pipeline Qra Seminar Title slide Title slide.
Software faults & reliability Presented by: Presented by: Pooja Jain Pooja Jain.
Design for Safety Injury, Hazards, Conditional Circumstances Legal Responsibilities Guidelines for Safe Products/systems Safety Hierarchy, Safe Design.
Reliability and Fault Tolerance Setha Pan-ngum. Introduction From the survey by American Society for Quality Control [1]. Ten most important product attributes.
EE551 Real-Time Operating Systems
1 Chapter 2 Socio-technical Systems (Computer-based System Engineering)
NATIONAL INSTITUTE OF AEROSPACE TECHNOLOGY Rosa Mª Rengel Gálvez Marina B. Gutiérrez García-Arias 11/09/2007 Rosa Mª Rengel Gálvez Marina B. Gutiérrez.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 9 Slide 1 Critical Systems Specification 2.
ERT 312 SAFETY & LOSS PREVENTION IN BIOPROCESS RISK ASSESSMENT Prepared by: Miss Hairul Nazirah Abdul Halim.
ERT 322 SAFETY AND LOSS PREVENTION RISK ASSESSMENT
CSE 403 Lecture 14 Safety and Security Requirements.
Software availability –the probability that a program is operating according to requirements at a given point in time. Availability = (MTTF/MTBF) x 100.
ENGR-11_Lec-12_Chp10_Design_for_X.ppt 1 Bruce Mayer, PE Engineering-11: Engineering Design Bruce Mayer, PE Licensed Electrical.
Socio-technical Systems (Computer-based System Engineering)
Ground loops Why grounding is so important ?DefinitionGround loops :(Introduction)where ground loops affect ?Ground loops are created by :Solutions.
CSE 466 – Fall Introduction - 1 Physical Layer API (same as Lab)  enq(), deq(), scan()  Periodically  if not currently master select non-empty.
GE 116 Lecture 1 ENGR. MARVIN JAY T. SERRANO Lecturer.
Safety-Critical Systems T Ilkka Herttua. Safety Context Diagram HUMANPROCESS SYSTEM - Hardware - Software - Operating Rules.
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.
Application – Identifying, Listing Equipment, and Documentation
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.
PLC Workshop at ITER, 4-5 th of December 2014 A. Nordt, ESS, Lund/Sweden.
Computer security By Isabelle Cooper.
University of Virginia Department of Computer Science Complex Systems and System Accidents presented by: Joel Winstead.
06/01/20161 Benny Hoff TÜV NORD Sweden AB AFS 2002:1 Use of pressure equipment.
RLV Reliability Analysis Guidelines Terry Hardy AST-300/Systems Engineering and Training Division October 26, 2004.
CSE 403, Software Engineering Lecture 6
CSE 466 – Fall Introduction - 1 Safety  Terms and Concepts  Safety Architectures  Safe Design Process  Software Specific Stuff  Sources  Hard.
©Ian Sommerville 2000Dependability Slide 1 Chapter 16 Dependability.
CSE 466 – Spring Introduction - 1 The Final  Hardware: probably something on memory mapped I/O (HW and SW)  OS: Probably a task diagram of some.
Risk and Precautions needed when installing hardware - P2
1 Software Testing and Quality Assurance Lecture 38 – Software Quality Assurance.
Fault Tree Analysis for Fatality Prevention Dr. Steven A. Lapp President - Design Sciences, Inc.
Process Safety Management Soft Skills Programme Nexus Alliance Ltd.
October 22, 2005 Parvaiz Ahmed Khand An Overview of Software Safety.
CSE 466 – Fall Introduction - 1 Safety  Example  Terms and Concepts  Safety Architectures  Safe Design Process  Software Specific Stuff  Sources.
HAZARD CONTROL HIERARCHY
Introduction to Safety Engineering for Safety-Critical Systems Seo Ryong Koo Dept. of Nuclear and Quantum Engineering KAIST Lab. Seminar.
Practical application of risk assessment: Use of pHA
Critical systems design
Hardware & Software Reliability
Discussions on Software Reliability
Dept. of Nuclear and Quantum Engineering
Safety and Risk.
Failure and Design Jaime Baber October 12, 2000
Quantitative Risk Assessment
Reliability and Fault Tolerance
Fault Tolerance Distributed Web-based Systems
Computer in Safety-Critical Systems
Definitions Cumulative time to failure (T): Mean life:
Mikael Olsson Control Engineer
Presentation transcript:

CSE 466 – Fall Introduction - 1 Safety  Examples  Terms and Concepts  Safety Architectures  Safe Design Process  Software Specific Stuff  Sources  Hard Time by Bruce Powell Douglass, which references Safeware by Nancy Leveson

CSE 466 – Fall Introduction - 2 What is a Safe System? Brake Pedal Sensor ProcessorBus Brake w/ local controller Engine w/ local controller Is it safe? What does “safe” mean? How can we make it safe?

CSE 466 – Fall Introduction - 3  Reliability of component i can be expressed as the probability that component i is still functioning at some time t.  Is system reliability P s (t) =  P i (t) ?  Assuming that all components have the same component reliability, Is a system w/ fewer components always more reliable ?  Does component failure  system failure ? burn in period Terms and Concepts time Pi(t) = Probability of being operational at time t Low failure rate means nearly constant probability 1/(failure rate) = MTBF

CSE 466 – Fall Introduction - 4 A Safe System  A system is safe if it’s deployment involves assuming an acceptable amount of risk…acceptable to whom?  Risk factors  Probability of something bad happing  Consequences of something bad happening (Severity)  Example  Airplane Travel – high severity, low probability  Electric shock from battery powered devices – hi probability, low severity severity probability danger zone (we don’t all have the same risk tolerance!) safe zone Nuclear power plant airplane mp3 player Desktop PC?

CSE 466 – Fall Introduction - 5 More Precise Terminology  Accident or Mishap: (unintended) Damage to property or harm to persons..  Release of Energy  Release of Toxins  Interference with life support functions  Damage to a credit rating (Does this fit the definition?)  Hazard: A state of the the system that will inevitably lead to an accident or mishap.  Hydrogen leak in fuel cell system  Backup battery dead on ventilator  Supplying misleading information to safety personnel or control systems. This is the desktop PC nightmare scenario. Bad information  Alarm bell broken

CSE 466 – Fall Introduction - 6 Faults  A fault is an “unsatisfactory system condition or state”. A fault is not necessarily a hazard. In fact, assessments of safety are based on the notion of fault tolerance.  Main H 2 Valve stuck, back up H 2 valve working  Systemic faults  Design Errors (includes process errors such as failure to test or failure to apply a safety design process)  Faults due to software bugs are systemic  Security breech  Random Faults  Random events that can cause permanent or temporary damage to the system. Includes EMI and radiation, component failure, power supply problems, wear and tear.

CSE 466 – Fall Introduction - 7 Component v. System  Reliability is a component issue  Safety and Availability are system issues  A system can be safe even if it is unreliable!  If a system has lots of redundancy the likelihood of a component failure (a fault) increases, but so may increase the safety and availability of that system.  Safety and Availability are different and sometimes at odds. Safety may require the shutdown of a system that may still be able to perform its function.  A backup system that can fully operate a nuclear power plant might always shut it down in the event of failure of the primary system.  The plant could remain available, but it is unsafe to continue operation

CSE 466 – Fall Introduction - 8 Single Fault Tolerance (for safety)  The existence of any single fault does not result in a hazard  Single fault tolerant systems are generally considered to be safe, but more stringent requirements may apply to high risk cases…airplanes, power plants, etc. Backup H2 Valve Control Main H2 Valve Control watchdog protocol If the handshake fails, then either one or both can shut off the gas supply. Is this a single fault tolerant system? Assume perfectly reliable valves

CSE 466 – Fall Introduction - 9 Is This? Backup H2 Valve Control Main H2 Valve Control watchdog handshake common mode failures

CSE 466 – Fall Introduction - 10 Now Safe? Backup H2 Valve Control Main H2 Valve Control watchdog handshake Separate Clock Source Power Fail-Safe (non-latching) Valves Does it ever end?

CSE 466 – Fall Introduction - 11 Time is a Factor  The TUV Fault Assessment Flow Chart  T1: Fault tolerance time of the first failure  T2: Time after which a second fault is likely  Captures time, and the notion of “latent faults”  T1 – tolerance time for first fault  T2 – Time after which a second fault is likely  Based on MTBF data  Safety requires that  T test <T 1 <T 2 System Unsafe yes no System Safe Fault Detected After T 2 ? yes no yes hazard? Hazard after T 1 ? First Fault 2 nd Fault

CSE 466 – Fall Introduction - 12 Latent Faults  Any fault this is not detectable by the system during operation has a probability of 1 – doesn’t count in single fault tolerance assessment  Detection might not mean diagnosis. If system can detect secondary affect of device failure before a hazard arises, then this could be considered safe Backup H2 Valve Control Main H2 Valve Control watchdog handshake stuck valves could be latent if the controllers cannot check their state. May as well assume that they are stuck!

CSE 466 – Fall Introduction - 13 Design for Safety 1.Hazard Identification and Fault Tree Analysis, FMEA 2.Risk Assessment 3.Define Safety Measures 4.Create Safe Requirements 5.Implement Safety 6.Assure Safety Process 7.Test,Test,Test,Test,Test

CSE 466 – Fall Introduction Hazard Identification – Ventilator Example MishapSeverityTolerance Time Fault Example LikelihoodDetection Time MechanismExposure Time Hypo- ventilation Severe5 min.Vent Fails – No pressure in reservoir. Rare30secIndep. pressure sensor w/ alarm 40sec Esophageal intubation Medium30secC02 sensor alarm 40sec User mis- attaches breathing hoses neverN/ADifferent mechanic al fittings for intake and exhaust N/A Over- pressuriza tion Severe0.05secRelease valve failure Rare0.01secSecondary valve opens 0.01sec Human in Loop