SAE GEIA-STD-0010-2008 Standard Best Practices for System Safety Program Development and Execution (Formerly TechAmerica GEIA-STD-0010).pdf

《SAE GEIA-STD-0010-2008 Standard Best Practices for System Safety Program Development and Execution (Formerly TechAmerica GEIA-STD-0010).pdf》由会员分享，可在线阅读，更多相关《SAE GEIA-STD-0010-2008 Standard Best Practices for System Safety Program Development and Execution (Formerly TechAmerica GEIA-STD-0010).pdf（116页珍藏版）》请在麦多课文档分享上搜索。

1、ANSI/GEIA-STD-0010-2009 Approved: February 12, 2009 TechAmerica Standard GEIA-STD-0010 Standard Best Practices for System Safety Program Development and Execution GEIA-STD-0010 October 2008 NOTICE TechAmerica Engineering Standards and Publications are designed to serve the public interest by elimina

2、ting misunderstandings between manufacturers and purchasers, facilitating interchangeability and improvement of products, and assisting the purchaser in selecting and obtaining with minimum delay the proper product for his particular need. Existence of such Standards and Publications shall not in an

3、y respect preclude any member or nonmember of TechAmerica from manufacturing or selling products not conforming to such Standards and Publications, nor shall the existence of such Standards and Publications preclude their voluntary use by those other than TechAmerica members, whether the standard is

4、 to be used either domestically or internationally. Standards and Publications are adopted by TechAmerica in accordance with the American National Standards Institute (ANSI) patent policy. By such action, TechAmerica does not assume any liability to any patent owner, nor does it assume any obligatio

5、n whatever to parties adopting the Standard or Publication. This TechAmerica Standard is considered to have International Standardization implications, but the ISO/IEC activity has not progressed to the point where a valid comparison between the TechAmerica Standard and the ISO/IEC document can be m

6、ade. This Standard does not purport to address all safety problems associated with its use or all applicable regulatory requirements. It is the responsibility of the user of this Standard to establish appropriate safety and health practices and to determine the applicability of regulatory limitation

7、s before its use. (Formulated under the cognizance of the TechAmerica G-48 System Safety Committee). This document is maintained under the ANSI/TechAmerica continuous maintenance program. Changes may be submitted at any time on any part of the standard using the TechAmerica Document Improvement Prop

8、osal at the back of this document or a similar method containing the same information. These comments shall be acted on for revision of the standard at the first meeting following working group resolution of the comment. Published by 2008 TechAmerica Standards the mechanism, a means by which the sou

9、rce can bring about the harm; and an outcome, the 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

10、 over a specified exposure interval. Probability is 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 th

11、e mishap risk assessment matrix. A categorization 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 severit

12、y and probability (or likelihood) of occurrence, and 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

13、risk acceptance. Mishap severity An assessment of 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, pr

14、operty damage, or other loss. Mitigator A feature 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

15、 mitigating measure or a mitigation. GEIA-STD-0010 7 Program manager An official who is responsible for managing a development program. Also, a general term of reference to those organizations directed by individual managers, exercising authority over the planning, direction, and control of tasks an

16、d associated functions essential for support of designated systems. This term will normally be used in lieu of any other titles, e.g.; 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 ha

17、zards. Risk is a combined expression of loss severity and probability (or likelihood). When expressed quantitatively, 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

18、 (r) Risk associated with a single hazard of the system. A single hazard risk is typically characterized by a severity-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 part

19、ial risks. Residual mishap risk The mishap risk that remains after all approved mitigators have been implemented and 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

20、/or the probability of the risk posed by one or more system hazards Safety Freedom from those conditions that can cause 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, su

21、bsystems, or systems whose failure and/or hazard may result in major system damage, death, severe injury, or could 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 applica

22、ble managing authority. Safety device In general, these are static interveners included in the system to reduce mishap risk. Examples include physical guards, revetments, guardrails, toeboards, machine guards, safety eyewear, hearing protection, and barricades. Safety devices installed onto or as pa

23、rt of the system, such as physical guards or barricades, should be distinguished from those GEIA-STD-0010 8 requiring personal use, such as safety eyewear, hearing protection, or other items of personal protective equipment because they are less dependent on user intervention. Safety significant ite

24、m (SSI) A function, subsystem, or component, the failure of which (including degraded functioning or functioning out of time or out of sequence) could result in a significant mishap as defined by the Managing authority. Software control category (SCC) The level of control a particular software funct

25、ion has over the identified hazard. Software criticality index (SCI) A measure of the degree of importance that the software will perform a specific function correctly to achieve mishap risk as low as reasonably practicable in the operation of the system. Subsystem A grouping of items satisfying a l

26、ogical group of functions within a particular system. System (1) An integrated composite of people, products, and processes that provide a capability to satisfy a stated need or objective. A composite, at any level of complexity, of personnel, procedures, materials, tools, equipment, and software. (

27、2) The elements of this composite entity are used together in the intended operational or support environment to perform a given task or achieve a specific purpose, support, or mission requirement. System engineering A comprehensive, iterative technical management process that includes translating o

28、perational requirements into configured systems, integrating the technical inputs of the entire design team, managing interfaces, characterizing and managing technical risk, transitioning technology from the technology base into program specific efforts, and verifying that designs meet operational n

29、eeds. It is a life cycle activity that demands a concurrent approach to both product and process development. System safety The application of engineering and management principles, criteria, and techniques to achieve mishap risk as low as reasonably practicable (to an acceptable level), within the

30、constraints of operational effectiveness and suitability, time, and cost, throughout all phases of the system life cycle. System safety engineering An engineering discipline that employs specialized professional knowledge and skills in applying scientific and engineering principles, criteria, and te

31、chniques to identify and mitigate hazards, in order to reduce the associated mishap risk. GEIA-STD-0010 9 System safety management All plans and actions taken to identify, assess, mitigate, and continuously track, control, and document mishap risks encountered in the concept, development, test, acqu

32、isition, use, and disposal of systems, subsystems, equipment, and facilities. System safety management plan (SSMP) A management plan that defines the system safety program requirements. The SSMP ensures the planning, implementation, and accomplishment of system safety tasks and activities consistent

33、 with the overall program requirements. System safety program plan (SSPP) A formal document that fully describes the planned safety tasks required to meet the contractual systems safety requirements including organizational responsibilities, methods of accomplishment, milestones, depth of effort, an

34、d integration with other program engineering and management activities and related systems. It may also define the minimum level of safety required by the program and the approaches for addressing the safety of complex integrated systems. Technical data package A technical description of an item tha

35、t is adequate to support an acquisition strategy, production, engineering, and logistics. The description defines the required design configuration and procedures required to ensure adequacy of item performance. It consists of all applicable technical data such as drawings or automated models and as

36、sociated lists, specifications, standards, performance standards, quality assurance requirements, software and packaging details. White Box Testing Testing software with the knowledge of the internal structure and coding inside the program. 4 General Requirements This section delineates the minimum

37、mandatory requirements for an acceptable system safety program for any system. The PM must establish and maintain a system safety program to achieve the overall system safety objectives for the program. This section prescribes the system safety program elements to be performed throughout the life cy

38、cle for any system. These guidelines are to ensure the identification and understanding of mishap hazards and their associated risks. The objective of system safety is to reduce mishap risk to an acceptable level (or alternatively as low as reasonably practical) through a systematic approach of haza

39、rd analysis, risk assessment, and risk management. 4.1 System Safety Program Elements. The Managing authority must establish and execute system safety programs that manage the risk of each single hazard (r) as well as the total system (R). The following five elements are necessary to conduct a compl

40、ete system safety program. Within each of the elements, the managing authority and developer must tailor the system safety program to fit the system context, unique hazards, and fiscal limitations. The Managing authority must allocate sufficient resources to accomplish each safety element. Additiona

41、l guidance on system safety program tailoring can be found in Section A.3.1.2.1. GEIA-STD-0010 10 4.1.1 Element 1 Program Initiation The Managing authority must document the approved system safety engineering approach and other actions needed to establish a fully functional system safety program. Gu

42、idance can be found in Section A.3.1. 4.1.2 Element 2 Hazard Identification and Tracking System safety includes a complete identification of the hazards associated with a system. In general this is accomplished by identifying the source-mechanism-outcome of each hazard. This element also includes us

43、e of a hazard tracking system (HTS) and continuous tracking of the hazards throughout the life cycle. Guidance can be found in Section A.3.2. 4.1.3 Element 3 Risk Assessment For each identified hazard, the mishap severity and probability or frequency are established. A mishap risk assessment matrix

44、(Section A.5) is used to assess and display the risks. The assessment methods may include models, numerical analyses, and subjective judgments based on history and system knowledge. Guidance can be found in Section A.3.3. 4.1.4 Element 4 Risk Reduction Risk reduction is achieved by accomplishing the

45、 following steps. a. Understand the risk drivers. b. Develop and document candidate mitigators. c. Select and implement mitigators in accordance with the system safety mitigation order of precedence. d. Verify that the risk has been reduced. Implementation details are described in Section A.3.4. 4.1

46、.4.1 System Safety Mitigation Order of Precedence In reducing risk, the cost, feasibility, and effectiveness of candidate mitigation methods must be considered. In evaluating mitigation effectiveness, an order of precedence generally applies as follows. 4.1.4.1.1 Eliminate Hazard Through Design Sele

47、ction Ideally, the risk of a hazard will be eliminated. This is often done by selecting a design alternative that removes the hazard altogether. Examples include: choosing pneumatic controls rather than electrical controls for application in an explosive atmosphere; preventing entrapment by equippin

48、g 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 Risk Through Design Alteration. If the ris

49、k 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 chemical 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. GEIA-STD-0010 11 4.1.4.1.3 Incorporate Engineered