Verification & Validation of Safety Critical Software：安全关键软件验证与确认.ppt

SEA99 Conference,Verification&Validation of Safety Critical Software,Verification&Validation of Safety Critical Software,Dr Peter LindsayAssistant DirectorSoftware Verification Research CentreSchool of Information TechnologyThe University of Queensland,SEA99 Conference,Verification&Validation of Safety Critical Software,Abstract of talk(1),The increasing trend towards systems integration,and increased automation of critical functions which were once performed by humans,means that more and more reliance is placed on software.Procurers of safety-critical systems are becoming more aware of the need for appropriate levels of safety assurance,and are increasingly requiring system developers to produce a Safety Case to document the reasons why a system is safe to be operated.,SEA99 Conference,Verification&Validation of Safety Critical Software,Abstract of talk(2),This talk looks at recent and emerging standards for safety-critical software,and will introduce listeners to the key principles of safety assurance,including:hazard and risk analysissafety integrity levelsthe structure and content of safety casesmanagement of the safety process,SEA99 Conference,Verification&Validation of Safety Critical Software,Computer Aided Disasters,Therac 25(1985-87,N.America)radiation therapy machine delivers severe radiation overdoses(x6)London Ambulance Service(1992)20+die unnecessarilly when dispatch system failsUSS Vincennes(1988)shoots down Iran Air airliner after faulty identificationAirbus A320(1988-)various crashesAriane 5(1996)software exception causes self-destructetcSee http:/lab.ox.ac.uk/archive/safety.html http:/,SEA99 Conference,Verification&Validation of Safety Critical Software,Whats Different About Software?,Broadly speaking,traditional safety engineering is concerned with physical failures:e.g.wear-out,corrosion,faulty manufacturemitigations include:well-tried designs,safety margins,redundant components,inspection,maintenancethis has little relevance for software On the other hand,software is typically:novel,complex,highly input-sensitive,not designed by domain expertsSoftware demands a new approach to safety engineering,SEA99 Conference,Verification&Validation of Safety Critical Software,Talk outline,Define main terms&concepts in safety engineering as they relate to software:hazards,risk,safety integrity levels,etcExplain the basic principles of safety management&the safety lifecycle for software systemsOutline 3 important safety analysis techniquesFailure Modes Effects Analysis(FMEA)Fault Tree Analysis(FTA)Hazard and Operability Studies(HAZOP)Summary,SEA99 Conference,Verification&Validation of Safety Critical Software,Reference Material,IEC 61508“Functional Safety:Safety-related Systems”(International Electrotechnical Commission,1998)Def(Aust)5679 Australian Defence Standard for Procurement of Computer-based Safety-critical SystemsUK MOD 00-55,00-56,00-58 Standards for software development and hazard analysis of safety-critical systemsNancy Leveson Safeware:System Safety and Computers,SEA99 Conference,Verification&Validation of Safety Critical Software,Safety,A system is unsafe if it can cause unacceptable harm.Harm:loss of life,injury,damage to the environment,etcSafety is a whole system issueonly physical objects can cause harmneed to consider all system components:software,hardware,operators,procedures,infrastructure,Safety is a whole lifecycle issuefrom concept through to decommissioningSafety and reliability are two different things,SEA99 Conference,Verification&Validation of Safety Critical Software,Hazards,Hazard:a situation with the potential for harmHazards are a state of the systemscope of system needs careful definitionother factors(outside system control)may affect whether hazard leads to an accidentFailure mode:the way in which something fails,SEA99 Conference,Verification&Validation of Safety Critical Software,Risk,Absolute safety is generally unachievableinstead,aim for acceptable risk Risk:a combination of the severity of consequences probability of failure of 10-2 in lifetime of equipment What constitutes acceptable risk is domain specific,SEA99 Conference,Verification&Validation of Safety Critical Software,Risk Assessment,1.Model the system:identify the major components and interfaces2.Identify hazards&how they ariseidentify potential failure modestrace consequences and control measuresbuild a cause-and-effect model of the system3.Analyse and assess riskassess component failure ratesassess likelihood&severity of hazardsIf some risks are not tolerable,its back to the drawing board!,SEA99 Conference,Verification&Validation of Safety Critical Software,Likelihood of Software Failure?,Theory of failure-rate prediction is almost non-existent for all but the simplest software same goes for complex hardware,operator procedures,system design,.Design faults now overtaking physical failures in impact on complex systemsCurrent best practice relies on the rigour of the development process-the Safety Integrity Level(SIL)Standards differ on exactly what SILs mean,and on what processes are requiredbut broadly speaking,SIL relates to degree to which system safety depends on the component,SEA99 Conference,Verification&Validation of Safety Critical Software,IEC 61508:Safety Integrity Levels,In IEC 61508,SILs correspond to acceptable failure rates:,SEA99 Conference,Verification&Validation of Safety Critical Software,Safety Management,Overall goal:to deliver a safe system,however“Like justice,safety needs not only to be done,but to be seen to be done.”A Safety Case documents the claim that the system is safe to be operatedMain ingredients of a Safety Case:identification of hazards,failure modes,failure mechanisms,safety features,safety targets&SILsreasoned arguments for risk assessmentsupporting evidence,including:hazard analysis,V&V results,SEA99 Conference,Verification&Validation of Safety Critical Software,Safety Management Lifecycle(1),From IEC 61508:,SEA99 Conference,Verification&Validation of Safety Critical Software,Safety Management Lifecycle(2),SEA99 Conference,Verification&Validation of Safety Critical Software,Software Engineering for Safety,All the regular good software-engineering practicesthorough requirements analysis,reviews&testingconfiguration managementInvolve all system stakeholders in safety managementDesign for safetyKISS(Keep It Simple,Stupid)no single point of failureisolate critical functionsbelts and braces diversity throughout design,implementation,reviewPay special attention to internal&external interfaces,SEA99 Conference,Verification&Validation of Safety Critical Software,Safety-Directed V&V,Safety Validation:are we building a safe system?all hazards&safety requirements identifiedsafety targets are appropriate:i.e.,if met,will achieve acceptable riskSafety Verification:are we achieving targets?safety requirements&targets are being flowed down through designappropriate evidence is being gathered that safety targets are being met(and no new hazards introduced)Safety Integrity Level determines the degree of rigour to be applied,SEA99 Conference,Verification&Validation of Safety Critical Software,Important Safety V&V techniques,The broad goals of Safety V&V are to identify(&prioritize)all hazards and trace their resolutionDifferent techiques are applicable at different stages of design,according to what design details are availableWill outline 3 techniques that apply well to software:Failure Modes&Effects Analysis(FMEA)Fault Tree Analysis Hazard&Operability Studies(HAZOP),SEA99 Conference,Verification&Validation of Safety Critical Software,FMEA Example:Speed Sensor,gearboxcontroller,sensor,signal processing unit,dashboard,gearbox,toothed wheel,SEA99 Conference,Verification&Validation of Safety Critical Software,FMEA Report:Speed Sensor,SEA99 Conference,Verification&Validation of Safety Critical Software,FMEA-Summary,Failure Modes and Effects Analysis Method:from known or predicted failure modes of components,determine possible effects on systemGood for hazard identification early in development,by considering possible failures of system functions:loss of function(omission failure)function performed incorrectly function performed when not required(commision failure)Not so good for mulitple failures,SEA99 Conference,Verification&Validation of Safety Critical Software,Example Fault Tree:tank-level sensors,Tank overflow,Inlet open,Inlet valve failed,Outletclosed,Wrong controlto inlet valve,Controllerfailed,SensorXfails,SensorYfails,Outlet Valve A,Inlet Valve B,Controller,X,Y,AND,OR,OR,AND,SEA99 Conference,Verification&Validation of Safety Critical Software,Fault Tree Analysis-Summary,Method:trace faults stepwise back through system design to possible causesa tree with a top event at the rootlogic gates at branches,linking each event with its“immediate”causesinitiating faults at leaves(eventually)Good for tracing system hazards through to component failures,and thus for allocating safety requirementsGood for checking completeness of safety requirementsbut can be difficult,time-consuming,hard to maintain,SEA99 Conference,Verification&Validation of Safety Critical Software,HAZard and OPerability Studies,Developed by ICI in mid60s for hazard identification for chemical process plants Method:given model of the system in terms of“flows”between componentsconsider possible deviations in flows,using guide words to steer analysis:no,more,less,as well as,part of,other than,reverseconsider both causes and effects of deviationsAdapts well as a systematic design-review technique for computer systems(CHAZOP)guidewords extended with:early,late,before,after,SEA99 Conference,Verification&Validation of Safety Critical Software,CHAZOP Example-Elevator,Data flow diagram showing internal structure of software,3Sequence controller,1Lift panelinterface,2Floor panelinterface,Request,Display,Lift request,Display,Floor request,Display,Movementcommands,Status,Door commands,Status,Pendingrequest,SEA99 Conference,Verification&Validation of Safety Critical Software,CHAZOP Example-Elevator Output,SEA99 Conference,Verification&Validation of Safety Critical Software,Talk Summary,Software Safety Engineering is a new disciplineStandards now require Safety Case prior to operation Safety is a system-wide,whole lifecycle issueSafety should be designed into a system,rather than added on laterstart developing safety arguments from earliest stages of designKISS,cost-effectivenessMain goals of Safety V&V are to identify all hazards and track their resolution,