DOC PREVIEW
Berkeley COMPSCI 294 - Lecture Notes

This preview shows page 1-2-19-20 out of 20 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 20 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 20 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 20 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 20 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 20 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

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 viewenvironmentGlass box view (structure)Collection of components (which are themselves subsystems)Software componentsComputersSensors, actuatorsHumansCommunicationsSystem structure can be dynamic3Role of software in system safetyRole of software in system safetySoftware can be a source of failuresSoftware 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.5HazardsHazardsHazard - 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 identificationCannot make a system safe unless we know how it can be unsafe.Hazard identification attempts to make explicit the safety risks of the systemThis requires thinking about the system globally as well as locallyShould begin in early phases of design, when problems are relatively easy to fix.7Hazard identification, contHazard identification, contAfter identificationSystem can be redesigned to remove hazard. . . or reduce probability. . .and/or reduce effects of hazard.Hazards should be tracked Hazard analysis should be updatedTo reflect design and implementation changesIncreased understanding and experience (e.g. from observed accidents or malfunctions).Also, remedies for hazards should be logged.8Hazard identification methodsHazard identification methodsThere is no magic bulletDraw on past experienceStudy 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 viewpointsPresent the system in various waysTry 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.InputsSystem design objectivesequipment specsenvironmental conditionsregulations10<<Space shuttle example>><<Space shuttle example>>11Hazard Level: severity and likelihoodHazard Level: severity and likelihoodExample DoD MIL-STD-882BCategory 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-56Frequent: 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/ContainmentHazard elimination: e.g., robot arm is too slow to break a hole in the wall.Hazard reduction: e.g., add interlocksHazard control: e.g., pressure valveDamage reduction: e.g., evacuation procedures.14PHA evaluationPHA evaluationAdvantagesFocuses on hazardsDisadvantagesDetermining hazard categories may be hard.May make unrealistic assumptions about engineering, testing, operational procedures, etc.15HAZOPHAZOPGoal: To establish, by systematic examination of system components and operations, failure modes which can lead to hazardsWhen: during designInputs: results of previous safety analysisOutputs: 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 happensMore: a quantitative increaseLess: a quantitative decreaseAs well as: Design intent achieved, with additionsPart of: Only some of design intention is achieved.Reverse: The logical opposite of the intention is achieved.17HAZOP evaluationHAZOP evaluationAdvantagesSimplicity and ease of applicationCombines members from different teamsDisadvantagesLabor intensiveResults 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 evaluationAdvantagesEffective for analyzing single unitsCompletenessUsed to identify redundancy.DisadvantagesMultiple failures/common mode failures overlooked.Time consuming and costlyFailure modes must be known in advance.Hard for complex


View Full Document

Berkeley COMPSCI 294 - Lecture Notes

Documents in this Course
"Woo" MAC

"Woo" MAC

11 pages

Pangaea

Pangaea

14 pages

Load more
Download Lecture Notes
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture Notes and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture Notes 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?