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

2. CSE 466 – Fall 2000 - Introduction - 2 What is a Safe System? Brake Pedal Sensor ProcessorBus Brake Engine Is it safe? What does “safe” mean? How can we make it safe? Add electronic watch dog between brake and bus Add mechanical linkage from separate brake pedal directly to brake Add a third mechanical linkage….

3. CSE 466 – Fall 2000 - 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 Probability of Continued Operation Low failure rate means nearly constant probability 1/(failure rate) = MTBF Pi(t)

4. CSE 466 – Fall 2000 - Introduction - 4 A Safety 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!) autopilot mp3 player PC

5. CSE 466 – Fall 2000 - Introduction - 5 More Precise Terminology  Accident or Mishap: (unintended) Damage to property or harm to persons. Economic impact of failure to meet warranted performance is outside of the scope of safety.  Hazard: A state of the the system that will inevitably lead to an accident or mishap  Release of Energy  Release of Toxins  Interference with life support functions  Supplying misleading information to safety personnel or control systems. This is the desktop PC nightmare scenario. Bad information  Failure to alarm when hazardous conditions exist

6. CSE 466 – Fall 2000 - 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.  Systemic faults  Design Errors (includes process errors such as failure to test or failure to apply safety design process)  Faults due to software bugs are always systemic  Random Faults  Random events that can cause permanent or temporary damage to the system. Includes EMI, radiation, component failure, power supply problems, security breech, etc.

7. CSE 466 – Fall 2000 - Introduction - 7 Component v. System  Reliability is a component issue  Safety and Availability are system issues  If a system has lots of redundancy the likelihood of a component failure (a fault) increases, but so may 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.

8. CSE 466 – Fall 2000 - 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?

9. CSE 466 – Fall 2000 - Introduction - 9 Think Again? Backup H2 Valve Control Main H2 Valve Control watchdog handshake common mode failures

10. CSE 466 – Fall 2000 - Introduction - 10 Now Safe? Backup H2 Valve Control Main H2 Valve Control watchdog handshake Separate Clock Source Power Fail-Safe What about power spike? Does it ever end? Is there another approach?

11. CSE 466 – Fall 2000 - Introduction - 11 Time is a Factor  The TUV Fault Assessment Flow Chart  T0: Fault tolerance time of the first failure  T1: Time after which a second fault is likely  Captures time, and the notion of “latent faults”  Built-in fault diagnosis and corrective action must occur within specific time frames. T act < T0 < T1

12. CSE 466 – Fall 2000 - 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 Backup H2 Valve Control Main H2 Valve Control watchdog handshake stuck valves could be latent if the controllers cannot check their state.

13. CSE 466 – Fall 2000 - Introduction - 13 Fail Safe  On reset process checks status. If bad, enter “safe mode”  power off  reduced/altered functionality  alarm  restart  Safe mode is application dependent Processor Watchdog protocol failure reset status

14. CSE 466 – Fall 2000 - Introduction - 14 Safety Architectures  Single Channel Protected Design  Redundancy  Diversity or Heterogeneity  Watchdog Brake Pedal Sensor Computer Bus Brake Engine Control watchdog embed checks into the channel

15. CSE 466 – Fall 2000 - Introduction - 15 Single Channel Protection  How to protect against corrupt code due to EMI?  perform period checksums on the code space  How long does this take?  Is T0<T1?  Feasibility of SCPD  Fault Tolerance Time  Speed of the processor  Amount of ROM/RAM  Redundant Memory Subsystems: special hw  Recurring cost v. Development cost tradeoff Computer (code corruption) Computer Bus Brake Engine Control parity/crc on the bus

16. CSE 466 – Fall 2000 - Introduction - 16 Multi-Channel Protection  Homogeneous Redundancy  Low development cost…just duplicate  High recurring cost  No protection against systemic faults Computer (code corruption) Brake Engine Control Computer Voting Bus could be implemented same as collision detect in I2C

17. CSE 466 – Fall 2000 - Introduction - 17 Multi-Channel Protection  Heterogeneous Redundancy  Protects against random and some systemic faults.  Best if implementation teams are kept separated Proc/SW 1 Brake Engine Control Proc/SW 2 Voting Bus

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

19. CSE 466 – Fall 2000 - Introduction - 19 Hazard Identification – Ventilator Example HazardSeverityTolerance Time FaultLikelihoodDetection Time MechanismExposure Time Hypo- ventilation Severe5 min.Vent FailsRare30secIndep. 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 Sever0.05secRelease valve failure Rare0.01secSecondary valve opens 0.01sec

20. CSE 466 – Fall 2000 - Introduction - 20 Fault Tree Analysis  Pacemaker Example

21. CSE 466 – Fall 2000 - Introduction - 21 System Risk Assessment  According to TUV: Risk factors are  Severity of the hazard  Duration of the period of exposure to the hazard  Prevention of the hazard  Probability of occurrence

22. CSE 466 – Fall 2000 - Introduction - 22 Define the Safety Measures  Obviation: Make it physically impossible (mechanical hookups, etc).  Education: Educate users to prevent misuse or hazardous cases  Alarming: Inform the users/operators of hazardous conditions  Interlocks: Take steps to eliminate the hazard when conditions exist  Restriction of Access. High voltage sources should be in compartments that require tools to access, w/ proper labels.  Labeling  Consider  Tolerance time  Supervision of the system: constant, occasional, unattended. Airport People movers have to be design to a much higher level of safety than attended trains even if they both have fully automated control

23. CSE 466 – Fall 2000 - Introduction - 23 Create Save Requirements: Specifications  Document the safety functionality