Safety - definitionsWhat is a system?Role of software in system safetySystem safetyHazardsHazard identificationHazard identification, contHazard identification methodsPreliminary Hazard Analysis (PHA)<<Space shuttle example>>Hazard Level: severity and likelihoodHazard likelihoodHazard Aversion/ContainmentPHA evaluationHAZOPHAZOP guide words (00-58)HAZOP evaluationFMECA (FMEA)FMECA example/more infoFMECA evaluation1Safety - definitionsSafety - definitionsAccident - an unanticipated loss of life, injury, or other cost beyond a pre-determined threshhold. If you expect it, it’s not an accident. Cost is high - generally higher than the value of the service provided by the system.Safety - absence of accidents.2What is a system?What is a system?Black box viewenvironmentGlass box view (structure)Collection of components (which are themselves subsystems)Software componentsComputersSensors, actuatorsHumansCommunicationsSystem structure can be dynamic3Role of software in system safetyRole of software in system safetySoftware can be a source of failuresSoftware can deal with error diagnosis and recovery.Interaction between software and rest of system can affect safety (e.g., GUI issues).4System safetySystem safetyPrinciple: software safety is meaningless without consideration of system-wide effects.GUI confuses operator.Wrong sensor reading causes inappropriate response from software.Bad error recovery code aggravates error.Loading the wrong software.5HazardsHazardsHazard - a condition that inevitably leads to an accident under some combination of environmental conditions (Leveson).Hazard may or may not lead to accident. . . but it is a matter of luck - assumes system cannot control environment.Example: Two aircraft are separated by less than minimum required distance.If exact position and velocity is “right”, they will collide.6Hazard identificationHazard identificationCannot make a system safe unless we know how it can be unsafe.Hazard identification attempts to make explicit the safety risks of the systemThis requires thinking about the system globally as well as locallyShould begin in early phases of design, when problems are relatively easy to fix.7Hazard identification, contHazard identification, contAfter identificationSystem can be redesigned to remove hazard. . . or reduce probability. . .and/or reduce effects of hazard.Hazards should be tracked Hazard analysis should be updatedTo reflect design and implementation changesIncreased understanding and experience (e.g. from observed accidents or malfunctions).Also, remedies for hazards should be logged.8Hazard identification methodsHazard identification methodsThere is no magic bulletDraw on past experienceStudy problems from previous systems.There may be checklists of common hazards.“Structured brainstorming”Form a committee of experienced people with a variety of expertise and viewpointsPresent the system in various waysTry to think of possible problems9Preliminary Hazard Analysis (PHA)Preliminary Hazard Analysis (PHA)Goal: Early identification of hazards so they can be taken into account in system specification and design.However, analysis should be updated to reflect increased understanding and design changes.InputsSystem design objectivesequipment specsenvironmental conditionsregulations10<<Space shuttle example>><<Space shuttle example>>11Hazard Level: severity and likelihoodHazard Level: severity and likelihoodExample DoD MIL-STD-882BCategory I: Catastrophic: may cause death or loss of system.Category II: Critical: May cause severe injury, severe occupational illnusess, or major system damage.Category III: Marginal: may cause minor injury, minor occupational illness, or minor system damage.Category IV: Negligable: will not result in injury, occupational illness, or system damage.12Hazard likelihoodHazard likelihoodBritish Std. 00-56Frequent: Likely to be continually experienced.Probable: Likely to occur often.Occasional: Likely to occur several times.Remote: Likely to occur some time.Improbable: Unlikely, but may exceptionally occur.Incredible: Extremely unlikely that the event will ever occur.13Hazard Aversion/ContainmentHazard Aversion/ContainmentHazard elimination: e.g., robot arm is too slow to break a hole in the wall.Hazard reduction: e.g., add interlocksHazard control: e.g., pressure valveDamage reduction: e.g., evacuation procedures.14PHA evaluationPHA evaluationAdvantagesFocuses on hazardsDisadvantagesDetermining hazard categories may be hard.May make unrealistic assumptions about engineering, testing, operational procedures, etc.15HAZOPHAZOPGoal: To establish, by systematic examination of system components and operations, failure modes which can lead to hazardsWhen: during designInputs: results of previous safety analysisOutputs: identification and elimination of events and failure modes leading to hazards.16HAZOP guide words (00-58)HAZOP guide words (00-58)No: Complete negation of design intention. No part of the intention is achieved, nothing else happensMore: a quantitative increaseLess: a quantitative decreaseAs well as: Design intent achieved, with additionsPart of: Only some of design intention is achieved.Reverse: The logical opposite of the intention is achieved.17HAZOP evaluationHAZOP evaluationAdvantagesSimplicity and ease of applicationCombines members from different teamsDisadvantagesLabor intensiveResults vary depending on quality of team.18FMECA (FMEA)FMECA (FMEA)“Failure Modes, Effects (and Criticality) Analysis”Goal: Systematically analyze the components of the target system with respect to attributes relevant to safety.When: Early design, after components identified.Input: Schematics, functional diagrams, component relationshipsOutput: List of failure modes and effects.19FMECA example/more infoFMECA example/more info20FMECA evaluationFMECA evaluationAdvantagesEffective for analyzing single unitsCompletenessUsed to identify redundancy.DisadvantagesMultiple failures/common mode failures overlooked.Time consuming and costlyFailure modes must be known in advance.Hard for complex
View Full Document