University of Paderborn Software Engineering Group II-25. Dr. Holger Giese. University of Paderborn Software Engineering Group. External facilities

Transcription

1 II.2 Life Cycle and Safety Safety Life Cycle: The necessary activities involving safety-related systems, occurring during a period of time that starts at the concept phase of a project and finishes when any safety-related system are no longer available for use. Standard V Development Process equirement analysis Specification equirements documents coarse design specification design spec. certification system test service verified system certified system Includes: Concept Development process Decommissioning system model, construction detailed design design Implementation modules modul test integration test tested modules integrated system system, quality management II-25 II-26 IEC 1508 Life Cycle 1 5 Concept System requirements allocation 2 4 Overall scope definition Overall system requirements IEC 1508 Safety Life Cycle Concept Overall system requirements Safety requirements allocation 2 3 Overall scope definition Hazard and analysis 6 Overall operation & maintenance Overall 7 Overall 8 Overall installation & validation commissioning ealization with electrical /electronic /programmable Overall installation & commissioning Overall validation 10 ealization with other technology 11 External facilities 6 Overall operation & maintenance Overall 7 Overall 8 Overall installation & validation commissioning ealization with electrical /electronic /programmable Overall installation & commissioning Overall safety validation 10 ealization with other technology 11 External reduction facilities Back to appropriate overall safety lifecycle phase 16 Decommissioning 14 Overall operation & maintenance 15 Overall modification & retrofit 16 Decommissioning 14 Overall operation & maintenance 15 Overall modification & retrofit II-27 II-28 Mapping of Phases to Activities (1/2) 1+2:Concept & Overall scope definition 3: Hazard and analysis Hazard Analysis and isk Analysis 4: Overall system requirements equirement Specification 5: Safety requirements allocation mapping to technology 9, 10 or 11 6: Overall operation & maintenance Maintenance 7: Overall validation Verification, Validation and Test 8: Overall installation & commissioning Mapping of Phases to Activities (2/2) 9: ealization with programmable components Design and Implementation 10: ealization with other technologies 11: External reduction facilities 12: Overall installation & commissioning 13: Overall safety validation Verification, Validation and Test and Certification 14: Overall operation & maintenance 15: Overall modification & retrofit Maintenance 16: Decommissioning II-29 II-30

2 Conceptual Development (Phase 1-5) Development of a system safety program plan Establish the safety information and documentation files Establish the safety log eview lessons learned (other projects) and applicable documents (standards, ) Establish certification and training for the personal involved Participate on system concept formation Establish working groups and other special structures Conceptual Development (Phase 1-5) Basic software system safety tasks: Trace identified hazards to the software -hardware interfaces and code Translate hazards into requirements and constraints Consistency between safety constraints and requirement specification Completeness of the requirements Identify parts of the system that control safety-critical operations Ensure traceability of safety requirements II-31 II-32 Conceptual Development (Phase 1-5) Delineate the scope of the safety analysis Planning of the hazard analysis process Objective of the analysis Basis for the analysis Hazard and cause types to be considered in the analysis equired standards of detail and certainty Criteria for acceptability Identify hazards and safety requirements Identify design, analysis and verification requirements, possible safety-interface problems, including the humanmachine interface, and operating support requirements Design (Phase 6-11) Update safety analysis Participate in system trade-off studies Ensure that safety requirements are incorporated into system and subsystem specifications, including human-machine interface requirements Ensure that identified hazards are being eliminated or controlled in the evolving design Identify safety-critical components II-33 II-34 Design (Phase 6-11) Trace system hazards into components. Identify there safety requirements and constraints. Identify part of the software that control safety-critical operations. eview test and evaluation procedures eview training and operation plans Evaluate Design changes for safety impact. Document all safety decisions and maintain safety information Full-scale Development (6-11) eview and update hazard analysis Perform interface analysis (also with subsystems) Ensure that safety requirements and constraints are incorporated into the subsystem safety requirements, constraints and documentation (software and engineering) Ensure that software developers and code developers understand software-related system safety requirements and constraints II-35 II-36

3 Full-scale Development (6-11) Trace software safety requirements and constraints through to the code. Identify critical components and variables to the code developers Update testing and verification requirements eview both system and subsystem test results. Trace them back to system hazards Evaluate changes for their impact on safety Design and evaluate training and operational procedures Perform final evaluation of product design Production and Deployment (Phase 6-11) Update hazard analysis Perform safety evaluation and verification at the system and subsystem level Perform safety inspections Ensure that safety-related information is incorporated into user and maintenance documents eview change proposals for safety impact Perform a final evaluation of the produced and developed system II-37 II-38 Operation (Phase 14-16) Update procedures Maintain an information feedback system. eview and analyse accidents and incidents Conduct safety audits (look for minor changes in the system, operations or environment on a periodic basis) eview changes and maintenance procedures II.3 Process Activities and Safety Hazard Analysis isk Analysis equirement Specification Design and Implementation Verification, Validation and Test Certification Operation and Maintenance II-39 II-40 II.3.1 Hazard Analysis Available techniques: Failure modes and effects analysis (FMEA) Failure modes, effects and critically analysis (FMECA) Hazard and Operability analysis (HAZOP) Event tree analysis (ETA) Fault tree analysis (FTA) Example: Chemical eaction Qualitative: Identification of hazards Quantitative: Probabilistic hazard analysis Hazard analysis continues throughout the development process In a container two chemicals react with each other over a period of 10 hours at a temperature of 125 C. If the temperature exceeds 175 C toxic gas is emitted. The temperature is controlled by a computer system. II-41 II-42

4 Fault Tree Analysis (FTA) FTA: A graphical representation of logical combinations of causes that may lead to a hazard (top-event). Can be used as a quantitative method. identification of hazards (top-events) analysis to find credible combinations which can lead to the top-event graphical tree model of parallel and sequential faults uses a standardized set of symbols for Boolean logic expresses top-event as a consequence of AND/O combination of basic events minimal cut set is used for quantitative analysis Symbols used within Fault Trees II-43 II-44 Identification of the Top-Event Identification of Lower-Level Events (1/2) Emission of poisonous gas is the top event Subtree for temperature measurement failure II-45 II-46 Identification of Lower-Level Events (2/2) Subtree for heating cut off failure Hazard Analysis & Process (1/2) All projects: Preliminary hazard identification (PHI) should be done for every embedded system recorded in the preliminary hazard list All safety-critical projects: Preliminary hazard analysis (PHA) preliminary hazard analysis report add preliminary hazard analysis report to safety log classify severity of hazards assign integrity levels to major functions Safety review develop safety plan II-47 II-48

5 Hazard Analysis & Process (2/2) All highly critical projects: System hazard analysis develop system hazard report add system hazard analysis report to safety log System isk assessment improve system hazard report Update system hazard analysis report in safety log Projects of highest level of criticality: Independent safety audit independent safety audit report independence: (1) person (2) department (3) organization Hazard Analysis & Process Preliminary hazard identification (PHI) Preliminary hazard analysis (PHA) Safety review Safety hazard analysis Safety assessment Independent safety audit Preliminary hazard list Preliminary hazard analysis report Safety plan Safety hazard analysis report Independent safety audit report safety log All projects All safetycritical projects All highly critical projects Projects of highest level of criticality II-49 II-50 II.3.2 isk Analysis Guideline: [IEC 1508] 1.) Classify hazards severity (its consequences) 2.) Classify hazards frequency (its probability) 3.) Combine to related 4.) Determine system safety integrity level 5.) Determine hardware, systematic and software safety integrity level 6.) Chose appropriate development techniques and process (Other standards (avionics, military) propose similar procedure) Severity: Consequences of Malfunctions Category Catastrophic Critical Marginal Negligible Definition Multiple deaths A single death, and/or multiple severe injuries or severe occupational illnesses A single severe injury or occupational illnesses, and/or multiple minor injuries or minor occupational illnesses At most a single minor injury or minor occupational illnesses Duration is considered here! II-51 II-52 Frequency: Probability of Malfunction Accident Frequency Frequent Probable Occasional emote Improbable Occurrence during operational life considering all instances of the system Likely to be continually experienced Likely to occur often Likely to occur several times Likely to occur some time Unlikely, but may exceptionally occur isk Classification (1/3) If only qualitative and no quantitative measures/values are available both are combined by means of tables Severity of hazardous event Frequency of hazardous event isk Incredible Extremely unlikely that the event will occur at all II-53 II-54

6 isk Classification (2/3) Consequences Frequency Catastrophic Critical Frequent I I Probable I I Occasional I II emote II III Improbable III III Incredible IV IV Marginal Negligible I II II III III III III IV IV IV IV IV isk Classification (3/3) isk class I II III IV Interpretation Intolerable Undesirable, and tolerable only if reduction is impracticable or if the costs are grossly disproportionate to the improvement gained Tolerable if the cost of reduction would exceed the improvement gained Negligible Only a generic interpretation Often more specific domain/sector dependent exist II-55 II-56 Acceptability of isk Process of isk eduction Negligible As low as reasonable practicable (ALAP) region or tolerable unacceptable region isk of the system without safety features Expected proportionally efforts for reduction equired reduction Assure that remains at this level Tolerable only when further reduction is impracticable or if its costs is grossly disproportionate to the improvement gained isk cannot be justified except in extraordinary circumstances Expected proportionally efforts for reduction Actual reduction Achieved Tolerable II-57 II-58 Safety Integrity Safety integrity is the likelihood of a safetyrelated system satisfactorily performing the required safety functions under all the stated conditions within a period of time. (Can be expressed quantitative, however, usually safety integrity levels numbers are used) Assignment of Integrity Levels Severity of hazardous event Frequency of hazardous event isk Integrity Hardware integrity is that part of system integrity relating to dangerous random hardware failures. Systematic integrity is that part of system integrity relating to dangerous systematic failures. Hardware Integrity Systematic Integrity Software Integrity Software integrity is that part of system integrity relating to dangerous software failures. II-59 II-60

7 Safety Integrity Levels (SILs) These are expressed in terms of Target Failure Measures, which in turn are expressed as probabilities of failure. Demand Mode of Operation indicates the probability of failure when the demands made on the system are counted. Continuous/High Demand Mode of Operation assumes a continuous mode of operation and then the failure is expressed as the probability of failure per year of operation. SILs - Target Failure Measures SAFETY INTEGITY LEVEL Demand Mode POB OF FAILUE/ DEMAND >=10-5 to < 10-4 >=10-4 to < 10-3 >=10-3 to < 10-2 >=10-2 to < 10-1 TAGET FAILUE MEASUES FO A SAFETY- ELATED SYSTEM Continuous/High Demand Mode POB OF FAILUE/ YEA >=10-5 to < 10-4 >=10-4 to < 10-3 >=10-3 to < 10-2 >=10-2 to < 10-1 Measures here mean preventative measures put in place to avoid hazardous situations, not quantitative measurements. II-61 II-62 SIL Implications The safety integrity level for the safety-related system determines the measures that need to be taken against both systematic and random hardware failures in the design. These recommendations link the safety integrity levels required of the system with techniques or measures to be adopted. The safety integrity level reflects the criticality of the system in terms of required failure rates. The safety integrity level selected for the development of the software will depend on that required for the entire system. ecommended Techniques Clause 7.7 : Software Safety Validation TECHNIQUE/MEASUE ef SIL1 SIL2 SIL3 1. Probabilistic Testing B Simulation/Modelling 1. Functional and Black- Box Testing D.6 D.3 SIL4 ( = Highly ecommended, = ecommended, - = No ecommendation, N = Not ecommended) One or more of these techniques shall be selected to satisfy the safety integrity level being used. II-63 II-64 Modelling Techniques D.6 : Modelling eferenced by Clauses 7.6 TECHNIQUE/MEASUE ef SIL1 SIL2 SIL3 1. Data Flow Diagrams B Finite State Machines 1. Formal Methods 1. Performance Modelling 1. Time Petri Nets 1. Prototyping/Animation 1. Structure Diagrams B.29 B.30 B.45 B.64 B.49 B One or more of the above techniques should be used. SIL4 II.3.3 equirement Specification The vast majority of accidents in which software was involved can be traced to requirement flaws and, more specifically, to incompleteness in the specified and implemented software behavior that is, incomplete or wrong assumptions about the operation of the controlled system or required operation of the computer and unhandled controlled-system states and environment conditions. [Leveson1995] Safety-related systems: Hazards Analysis additional (software) requirements II-65 II-66

8 equirements Specifications equirements specifications contains: (1) a basic function or objective (2) Constraints on the operating conditions (3) Prioritised quality goals to help make trade-off decisions Safety can be involved in both functional requirements and constraints Functional goals and constraints often conflict Process & Software equirements Software Hazard Analysis: 1.) Trace identified system hazards to the softwarehardware interface. Translate the identified software-related hazards into requirements and constraints on software behaviour. 2.) Show the consistency of the software safety constraints with the software requirements specification. Demonstrate the completeness of the software requirements, including the humancomputer interface requirements, with respect to system safety properties. II-67 II-68 equired equirements Non-ambiguous specification: The function must have been specified in sufficient detail to distinguish it form undesired behavior Complete specification: The provided information must be sufficient to exclude any unsafe realization Consistent specification: The provided information should contain the identified system specific requirements and constraints Ambiguity and Natural Language Shut off the pumps if the water level remains above 100 m for more than 4 seconds. 1.) Shut off the pumps if the mean water level over the past 4 seconds was above 100 m. 2.) Shut off the pumps if the median water level over the past 4 seconds was above 100 m. MAX [ ] [ ] ( τ 4, τ ) WL( t) + MIN ( τ 4, τ ) WL( t) / 2 > 3.) Shut off the pumps if the minimum water level over the past 4 seconds was above 100 m. More formal? τ τ WL ( t) dt / 4 > { } 100 MIN [Parnas+1991] [ WL( t) ] 100 ( τ 4, τ ) > II-69 II-70 equirement Model & EUC Input Equipment under control (EUC) Sensors Controller Actuators Internal model of EUC Disturbances Output Observation: If the internal model does not accurately reflect the EUC, an accident might result equirement model: State machine In/output Completeness (1/4) Human-computer interface: Will the system deliver appropriate information to the operator? State completeness: Are all system (classes of) states covered? Input/Output completeness: Are specified input/output channels are used? II-71 II-72

9 Completeness (2/4) Trigger Event Completeness Every possible input (even none) should be covered (obustness) The behavior of the state machine should be deterministic Check all incoming values (value assumptions) The reaction to all inputs should be bound in time (timing assumptions) Minimal/maximal load assumptions and minimum arrival times must be specified Violations of load assumptions must be detected and the system must react accordingly Completeness (3/4) Output Specification Completeness Check for legal values Ensure that environment capacity is not overloaded The used input data should be limited and delayed output must expire after a while Output to Trigger Event elationship A basic feedback loop should ensure that the software can detect effect on all outputs of the EUC to detect internal or external failures For each input expected in response to an output both the regular behavior as well as handling an timeout must be specified II-73 II-74 Completeness (4/4) Specification of Transitions between States All specified states must be reachable form the initial state (reachability) Desired recurrent behavior must be part of at least one cycle Output commands should be usually be reversible Path obustness: For all hazards reducing outputs we have to ensure that no single sensor failure can inhibit them. Multiple path should be provided that enhance or maintain safety Multiple inputs or triggers should be required for path from safe to hazardous states Consistency (1/2) Transitions must satisfy software system safety requirements and constraints A function is never executed Performing an unintended function Performing functions at the wrong time Failing to recognize a hazardous condition requiring corrective action Producing the wrong response to a hazardous condition II-75 II-76 Consistency (2/2) eachable hazardous states should be eliminated or, if that is not possible, their frequency and duration reduced Checking general safety policy (cf. security policy) There must be no path to unplanned hazardous states Every hazardous must have a path to a safe state If a safe state can not be reached from a hazardous state, all path from that state must lead to a minimum state. At least one such path must exist. II-77