GEIA-STD-0010-2008 Standard Best Practices for System Safety Program Development and Execution (Formerly TechAmerica GEIA-STD-0010)《系统安全程序开发和执行的最佳标准实施规程》.pdf

《GEIA-STD-0010-2008 Standard Best Practices for System Safety Program Development and Execution (Formerly TechAmerica GEIA-STD-0010)《系统安全程序开发和执行的最佳标准实施规程》.pdf》由会员分享，可在线阅读，更多相关《GEIA-STD-0010-2008 Standard Best Practices for System Safety Program Development and Execution (Formerly TechAmerica GEIA-STD-0010)《系统安全程序开发和执行的最佳标准实施规程》.pdf（116页珍藏版）》请在麦多课文档分享上搜索。

1、 ITAA STANDARD GEIA-STD-0010 Standard Best Practices for System Safety Program Development and Execution GEIA-STD-0010 October 2008 INFORMATION TECHNOLOGY ASSOCIATION OF AMERICA Copyright Government Electronics the mechanism, a means by which the source can bring about the harm; and an outcome, the

2、harm itself that might be suffered. Mishap frequency Rate of mishap occurrence. Frequency is sometimes substituted for probability as a component of risk (example: loss events per 106operating hours). Mishap Likelihood Likelihood of mishap occurrence over a specified exposure interval. Probability i

3、s expressed as a value between zero and one. Probability is a component of risk and has no dimension but must be attached to an interval of exposure (example: one operating year, a million vehicle miles). Mishap probability category A component of the mishap risk assessment matrix. A categorization

4、that provides a range of probabilities (or likelihoods) for the occurrence of a mishap. Mishap risk assessment The process of characterizing hazards within risk areas and critical technical processes, analyzing them for their potential mishap severity and probability (or likelihood) of occurrence, a

5、nd prioritizing them for risk mitigation actions. Mishap risk category A specified range of risk associated with a given level (high, serious, medium, low) used to prompt specific action such as reporting hazards to appropriate management levels for risk acceptance. Mishap severity An assessment of

6、the potential degree of harm from a mishap. Severity is one component of risk. Mishap severity category A component of the mishap risk assessment matrix. A categorization that delineates a range of mishap outcomes in terms of fatalities, injuries, property damage, or other loss. Mitigator A feature

7、of a system that reduces risk for one or more hazards by lowering either the probability of a harmful outcome or the severity of such an outcome, should it occur. Also referred to as a control, a hazard control, a control measure, a countermeasure, a mitigating measure or a mitigation. Copyright Gov

8、ernment Electronics system support manager, system manager, and project manager. Risk (also referred to as mishap risk) A measure of the expected loss from a given hazard or group of hazards. Risk is a combined expression of loss severity and probability (or likelihood). When expressed quantitativel

9、y, risk is the simple numerical product of severity of loss and the probability that loss will occur at that severity level. This term has the following applications: Single hazard risk (r) Risk associated with a single hazard of the system. A single hazard risk is typically characterized by a sever

10、ity-probability pair, assessed using a mishap risk assessment matrix. Total Mishap risk (R) An expression of overall system risk, comprising the combined separate properties of all partial risks. Residual mishap risk The mishap risk that remains after all approved mitigators have been implemented an

11、d verified. (Interim risk is the risk that is present until final mitigation actions have been completed.) Risk driver A characteristic that meaningfully contributes to the severity and/or the probability of the risk posed by one or more system hazards Safety Freedom from those conditions that can c

12、ause death, injury, occupational illness, damage to or loss of equipment or property, or damage to the environment. Safety critical A term applying to those items, units, components, subsystems, or systems whose failure and/or hazard may result in major system damage, death, severe injury, or could

13、result in a mishap with consequences unacceptable to the Managing Authority. Safety critical function A function that, if not performed, could result in mishap as defined by the applicable managing authority. Safety device In general, these are static interveners included in the system to reduce mis

14、hap risk. Examples include physical guards, revetments, guardrails, toeboards, machine guards, safety eyewear, hearing protection, and barricades. Safety devices installed onto or as part of the system, such as physical guards or barricades, should be distinguished from those Copyright Government El

15、ectronics preventing entrapment by equipping refrigerator doors with magnetic strip gaskets rather than using positive latching hardware door closures; selecting a non-flammable hydraulic fluid rather than a flammable one; replacement of toxic materials with benign materials. 4.1.4.1.2 Reduce Mishap

16、 Risk Through Design Alteration. If the risk of a hazard cannot be eliminated by adopting an alternative design, design changes must be considered that reduce the severity and/or the probability of a harmful outcome. Examples include: minimizing the quantity of a hazardous intermediate agent in a ch

17、emical process; placing a current-limiting resistor in the discharge circuit of a high energy electrical circuit; providing flow-tripping flutes on discharge stacks to prevent resonant vortex shedding. Examples of safety design requirements used to reduce risk appear in Section A.6. Copyright Govern

18、ment Electronics loss-of-tension braking for elevators; full-time, on-line redundant paths; interlocks; ground-fault circuit interrupters; uninterruptible power supplies. 4.1.4.1.4 Incorporate Safety Devices If unable to eliminate or adequately mitigate the hazard through design or ESFs, reduce mish

19、ap risk by using protective safety features or devices. In general, safety devices are static interveners. Examples include: physical barriers; machine guards; barricades; safety eyewear; hearing protectors. Safety devices installed onto or as part of the system, such as physical guards or barricade

20、s, should be distinguished from those requiring personal use, such as safety eyewear, hearing protection, or other items of personal protective equipment. Use of installed controls is generally preferable and more consistent with the system safety order of precedence. Additionally, the training comp

21、onent of protective equipment use needs to be considered as a procedure and training element that requires more ongoing resource commitment and is subject to more variables than safety devices intrinsic to the system. 4.1.4.1.5 Provide Warning Devices If design selection, ESFs, or safety devices do

22、not adequately mitigate the risk of a hazard, include a detection and warning system to alert personnel to the presence of a hazardous condition or occurrence of a hazardous event. 4.1.4.1.6 Develop Procedures and Training Where other risk reduction methods cannot adequately mitigate the risk from a

23、 hazard, incorporate special procedures and training. Procedures may prescribe the use of personal protective equipment. For hazards that could result in mishaps as defined by the Managing authority, avoid using warning, caution, or written advisories or signage as the only risk reduction method. 4.

24、1.5 Element 5 Risk Acceptance The Developer PM must provide the Managing authority with sufficient information to make informed decisions regarding the acceptability of residual mishap risk and the costs of risk mitigating measures. Risk communication must consider the risk of the individual hazard

25、in context of the total system risk. 4.2 Normative Information This section contains information of a general or explanatory nature that may be helpful, but is not mandatory. 4.2.1 Intended Use This standard establishes a common basis for expectations of a properly executed system safety effort. 4.2

26、.2 Data Requirements Hazard analysis data may be obtained from various sources. The managing authority is encouraged to request any type of safety plan required to be provided by the Developer in the proposal. Copyright Government Electronics an overall system mishap rate; demonstration of controls

27、required to preclude unacceptable conditions; satisfaction of specified standards and regulatory requirements; or other suitable mishap risk assessment procedures. Examples of safety performance statements are in the following subparagraphs. A.3.1.2.2.1 Quantitative Requirements Quantitative require

28、ments may be expressed in terms of either risk, or the probability or frequency of a given mishap severity category. Risk measures are typically expressed as a loss rate, such as: “The expected dollar loss per flight hour must not exceed $XXXX” or “The expected fatalities per year must not exceed 0.

29、00X.” A.3.1.2.2.2 Mishap Risk Requirements Mishap risk requirements could be expressed as “no hazards assigned a catastrophic mishap severity as defined by the System Safety Management Plan are acceptable.” Mishap risk requirements could also be expressed as a level defined by a mishap risk assessme

30、nt, such as “no serious mishap risks or higher are acceptable.” A.3.1.2.2.3 Standardization Requirements Standardization requirements are expressed relative to a known standard that is relevant to the system being developed. Examples include: “The system must comply with the laws of the State of Xxx

31、xxxxx and be operable on the highways of the State of Xxxxxxxx” or “The system must be designed to meet American National Standards Institute (ANSI) STD XXXX.XX-XXXX as a minimum.” A.3.1.2.3 Establish a System Safety Organization Establish a system safety organization or function and the required li

32、nes of communication with associated organizations. Establish interfaces between system safety and other functional elements of the program, as well as with other safety related disciplines (such as nuclear, range, occupational health, explosive, chemical, and biological). Designate the organization

33、al unit responsible for executing each safety task. Establish the authority for resolution of identified hazards. Define resources needed, to include the SSWG and if necessary integrated product teams (IPTs). Organizational interface and an integrated master schedule (IMS) must be included. Copyrigh

34、t Government Electronics b. Definition of safety critical; c. Identification of safety critical software functions and safety critical software requirements; d. Identification of the software hazard criticality assessment process to include establishment of the software criticality index matrix (see

35、 Section A.6) for each safety critical software function and safety critical requirement and how it will be used to assign software integrity assurance tasks necessary to verify and validate the safety critical functions and requirements; e. Performing a final risk assessment for hazards which have

36、software contributors. A.3.1.3.3 Hazard Closure and Risk Acceptance Process Define how hazards and mishap risks are communicated to and accepted by the appropriate risk acceptance authority and how hazards and mishap risk will be tracked. .3.1.3.4 The Mishap Risk Assessment Tool Define the mishap ri

37、sk assessment tool used for risk assessment and acceptance. A key part of the approach for system risk management is the adoption of an appropriate mishap risk assessment matrix. Mishap risk assessment matrices provide a means to assess and communicate risks and establish authority for acceptance of

38、 those risks. Programs may use one matrix to assess risks from individual hazards, and another matrix to accept total system risk. These tools must be defined during the planning phase; however, they may need tailoring or refinement during Element 2 as the full set of hazards becomes more apparent.

39、A software hazard criticality assessment and software safety integrity assessment must be performed for each safety critical software function and associated safety critical requirement (see Section A.6). Upon completion of all the software safety engineering analyses tasks and the software integrit

40、y assurance tasks a final risk assessment can be performed based on the confidence gained in the software (see Section A.6.3). Copyright Government Electronics b. Guides assessment of risk for single hazards; c. Displays the results of risk assessments, risk mitigation and reduction; and d. Delineat

41、es risk acceptance decision authority. A.3.1.3.4.2 Guidance in Developing Mishap Risk Assessment Matrices All systems have unique risks. A mishap risk assessment matrix will be used to characterize these risks. A pre-existing matrix may be used or a uniquely tailored matrix may be developed. In deve

42、loping and tailoring the risk matrix, these elements must be considered: a. Tailor mishap risk assessment matrices to each system or class of systems based on the expected range of severity of potential mishaps and the range of probability or frequency of these mishaps. b. Orient the severity and pr

43、obability (or frequency) axes so that one axis increases upward and the other increases to the right in accordance with the Cartesian coordinate system. c. Use logarithmic scales on each axis with logical and proportional ranges for mishap severity categories and mishap probability categories. d. As

44、sign the four levels of risk acceptance authority (high, serious, medium, low) to each cell of the matrix. A.3.1.3.4.3 Mishap Risk Assessment Matrix Tailoring New or tailored matrices must be developed by defining and scaling the severity and probability or frequency scales that bound the risk of th

45、e system. Examples of a tailoring approach and tailored matrices are provided in Section A.5. A.3.1.3.4.4 De Minimis Threshold In defining the mishap risk assessment matrix, programs may also wish to define a de minimis threshold. The term de minimis is short for the Latin de minimis non curat lex w

46、hich means “the law does not concern itself with trifles.” This concept, adapted from the legal profession, helps define the action thresholds. Hazards below this threshold have risk so low that they do not warrant any additional expenditure of resources. Below this threshold, there is no requiremen

47、t to actively track the hazard, though it may be mitigated if minimal resources are required. Hazards above the de minimis line are the focus of the system safety program. Generally, for hazards with greater risk, greater risk reduction resources are warranted. See Figures A-10, A-11, and A-12 for e

48、xamples of a de minimis threshold. A.3.1.3.4.5 Additional Safety Plan Requirements Describe how changes to design, training, and technical manuals for the purpose of risk mitigation will be accomplished. Describe the verification (e.g., test, analysis, demonstration, or inspection) requirements for ensuring that safety is adequately attained. Identify any certification requirements for Copyright Government Electronics & Information Technology Association Provided by IHS under license with GEIA Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-