TECHNICAL REPORT GEIA-STD-001 0™ REV.

Issued 2008-1 0
Revised 201 8-1 0

Superseding GEIA-STD-001 0

(R) Standard Best Practices for System Safety

Program Development and Execution

RATIONALE

The primary purpose of this revision of standard GEIA-STD-001 0, of the same name, is to provide Task Data Descriptions
(TDDs) for System Safety Tasks detailed in Appendix B of this Standard. TDDs are analogous to Data Item Descriptions
(DIDs) found in military standards. The TDDs now appear in a new appendix (Appendix C). This revision also incorporates
numerous editorial corrections to the previous version of the standard.

TABLE OF CONTENTS

1. SCOPE .......................................................................................................................................................... 3

2. REFERENCE DOCUMENTS ........................................................................................................................ 3

3. TERMS AND DEFINITIONS ......................................................................................................................... 4

3.1 Acronyms Used in this Standard ................................................................................................................... 4
3.2 Definitions ..................................................................................................................................................... 5

4. GENERAL REQUIREMENTS ....................................................................................................................... 9

4.1 System Safety Program Elements ................................................................................................................ 9
4.1 .1 Element 1 - Program Initiation ...................................................................................................................... 9
4.1 .2 Element 2 - Hazard Identification and Tracking ............................................................................................ 9
4.1 .3 Element 3 - Risk Assessment ....................................................................................................................... 9
4.1 .4 Element 4 - Risk Reduction .......................................................................................................................... 9
4.1 .5 Element 5 - Risk Acceptance ...................................................................................................................... 1 1

4.2 Normative Information ................................................................................................................................. 1 1

4.2.1 Intended Use ............................................................................................................................................... 1 1
4.2.2 Data Requirements ..................................................................................................................................... 1 1
4.2.3 Subject Term (Key Word) Listing ................................................................................................................ 1 1
4.2.4 Use of System Safety Data in Certification and Other Specialized Safety Approvals ................................ 1 1

5. DETAILED REQUIREMENTS .................................................................................................................... 1 2

6. NOTES ........................................................................................................................................................ 1 2

APPENDIX A GUIDANCE FOR IMPLEMENTATION OF A SYSTEM SAFETY EFFORT ............................................... 1 3

APPENDIX B SYSTEM SAFETY TASKS.......................................................................................................................... 49
APPENDIX C TASK DATA DESCRIPTIONS .................................................................................................................... 87

__________________________________________________________________________________________________________________________________________
SAE Technical Standards Board Rules provide that: “This report is published by SAE to advance the state of technical and engineering sciences. The use of this report is entirely
voluntary, and its applicability and suitability for any particular use, including any patent infringement arising therefrom, is the sole responsibility of the user.”
SAE reviews each technical report at least every five years at which time it may be revised, reaffirmed, stabilized, or cancelled. SAE invites your written comments and
suggestions.
Copyright © 201 8 SAE International
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted, in any form or by any means, electronic, mechanical, photocopying,
recording, or otherwise, without the prior written permission of SAE.
TO PLACE A DOCUMENT ORDER: Tel: 877-606-7323 (inside USA and Canada) SAE values your input. To provide feedback on this
Tel: +1 724-776-4970 (outside USA) Technical Report, please visit
Fax: 724-776-0790 http://standards.sae.org/GEIASTD001 0A
Email: [email protected]
SAE WEB ADDRESS: http://www.sae.org
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 2 of 1 04
FOREWORD
This standard describes the best practices for applying system safety, the discipline of identifying and mitigating mishap
risk encountered in the development, test, production, use, and disposal of systems, subsystems, equipment, and facilities.
Risks are identified, evaluated, and mitigated to levels as low as reasonably practicable. Levels of risk should also be
compliant with federal laws and regulations, executive orders, treaties, and agreements. Program trade studies associated
with mitigating mishap risks should consider total life cycle cost in any decisions. Mishap risks associated with an individual
system should be reported to and accepted by the Managing Authority. When this standard is required in a solicitation or
contract and no specific references are included, then only those requirements presented in Section 4 are applicable.
Early identification and control of safety critical hardware, software, human systems integration, and operations is the key
to achieving a successful system safety program. Functional hazard analysis and assessment has historically been the
most effective technique to determine hazards and develop safety requirements to mitigate risks. Coupled with use of the
system safety risk mitigation order of precedence, functional hazard analysis lets a program identify early in the life cycle
those risks which can be eliminated by design, and those which should undergo mitigation by other controls in order to
reduce risk to an acceptable level. Finally, verification through documented evidence of compliance with safety requirements
and safety features is necessary.
The concepts, definitions and standards identified herein are not applicable to the development safety process used as
part of the civil aircraft development and certification. The Reader is referred to SAE ARP4754 and ARP4761 for these
commercial aviation safety activities. There are some overlaps between the practices herein and the safety management
process supporting transport airplanes in commercial service described in ARP51 50.
The G-48 System Safety Committee of SAE International developed this document.
BACKGROUND
This document outlines standard best practices for the setup, implementation, and management of system safety programs.
System safety is an engineering discipline that can be applied to any activity to reduce or manage the risk of harm to people,
property, or the environment. The formalization of system safety as a distinct discipline can be traced back at least as far
as the 1 940s. The 1 960s saw the development and publishing of the first widely used standards for the practice of System
Safety, including MIL-STD-882 in 1 969, which evolved from some earlier U.S. military and Air Force specifications.
Over the next 30 years, several revisions to MIL-STD-882 were published, the most recent (prior to the original issue of this
standard) being Revision D in 2000. The G-48 System Safety Committee played a key role in the development and
publishing of every revision of MIL-STD-882. In response to Acquisition Reform initiatives of the mid-1 990s, many military
standards were cancelled or threatened with cancellation. To spare MIL-STD-882 from cancellation, the G-48 Committee
prepared and submitted Revision D as a less prescriptive version, with the system safety tasks, data item descriptions
(DIDs), and a great deal of other specific guidance and standard practices from Revision C and earlier revisions removed.
By the mid-2000s, the G-48 Committee saw, in general, a need to prepare a major new revision of MIL-STD-882 that would
restore the specificity removed for the D Revision, and that would incorporate several other improvements. These
improvements included:
1 . adjusting the organizational arrangement of information to clarify the basic elements of a system safety program and
the process flow among them,
2 modernizing the document and its tools - such as the Risk Assessment Matrix - to bring them abreast of contemporary
best practice, and
3. introducing - though not requiring - the concept of risk summation.
A G-48 working group prepared a draft Revision E of MIL-STD-882 to incorporate these improvements. This Draft MIL-
STD-882E was prepared between August 2004 and February 2006 and regularly reviewed by the full G-48 Committee over
the course of several G-48 Committee meetings. All review comments received during this process were thoroughly
tracked, adjudicated, and incorporated as necessary. The resulting 1 February 2006 version of the G-48 Committee’s Draft
MIL-STD-882E was formally coordinated through and approved by nearly all the designated DoD standardization officials.
A key non-concurrence, from the DoD Acquisition Environment, Safety, and Occupational Health (ESOH) Integrated Product
Team (IPT), resulted in control of the document being transferred to the ESOH IPT for a rewrite.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 3 of 1 04
Amid concerns that the ESOH IPT’s rewrite would eliminate many of the extensive improvements of its Draft Revision E,
the G-48 Committee embarked on a parallel path to prepare a non-military system safety standard that would be published
independently of MIL-STD-882, and that would include the modernization and improvements of the Draft Revision E. The
approach followed was to start with the 1 February 2006 version of the G-48 Draft MIL-STD-882E, revise the text where
necessary to remove all DoD-specific and military-specific language, and submit for publishing as a GEIA standard. The
document originally published in October 2008 as the initial release was the result of that effort and was designated GEIA-
STD-001 0, “Standard Best Practices for System Safety Program Development and Execution.”
Beginning in 201 2, the G-48 Committee responded to comments from user and producer organizations represented on the
committee by adding a new Appendix C containing task data descriptions (TDDs), which are analogous to data item
descriptions (DIDs) associated with military standards. This change and various editorial corrections are incorporated in
the first revision of GEIA-STD-001 0, submitted for publishing in 201 7.
1 . SCOPE
This document outlines a standard practice for conducting system safety. In some cases, these principles may be captured
in other standards that apply to specific commodities such as commercial aircraft and automobiles. For example, those
manufacturers that produce commercial aircraft should use SAE ARP4754 or SAE ARP4761 (see Section 2 below) to meet
FAA or other regulatory agency system safety-related requirements.
The system safety practice as defined herein provides a consistent means of evaluating identified risks. Mishap risk should
be identified, evaluated, and mitigated to a level as low as reasonably practicable. The mishap risk should be accepted by
the appropriate authority and comply with federal (and state, where applicable) laws and regulations, executive orders,
treaties, and agreements. Program trade studies associated with mitigating mishap risk should consider total life cycle cost
in any decision.
This document is intended for use as one of the elements of project solicitation for complex systems requiring a systematic
evaluation of hazards and mitigating measures. The Managing Authority may identify, in the solicitation and system
specification, specific system safety requirements to be met by the Developer. These may include risk assessment and
acceptance criteria, unique classifications and certifications, or mishap reduction needs unique to their program. Additional
information in meeting program specific requirements is located in the Appendixes.
2. REFERENCE DOCUMENTS
Information on safety analysis techniques is available from the documents listed below.
Nothing in this section or the documents listed below supersedes applicable laws and regulations unless a specific
exemption has been obtained.
• System Safety Analysis Handbook. System Safety Society, P.O. Box 70, Unionville, VA 22567.
• Air Force System Safety Handbook, Air Force Safety Agency, Kirtland Air Force Base, NM. July 2000.
• Advisory Circular (AC) No. 25.1 309-1 A - “System Design and Analysis.” Washington D.C., FAA.
• SAE International Aerospace Recommended Practice, ARP 4754A, "Guidelines for Development of Civil Aircraft and
Systems," Issued Dec. 201 0.
• SAE International Aerospace Recommended Practice, ARP 4761 , "Guidelines and Methods for Conducting the Safety
Assessment Process on Civil Airborne Systems and Equipment," Issued Dec. 1 996.
• SAE International Aerospace Recommended Practice, ARP 51 50 “Safety Assessment of Transport Airplanes in
Commercial Service, Issued Nov. 2003.
• IEEE Standard for Software Safety Plans, IEEE Standard 1 228.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 4 of 1 04
3. TERMS AND DEFINITIONS
For the purposes of this document, the following terms and definitions apply.
3.1 Acronyms Used in this Standard
The acronyms used in this standard are defined as follows:
AC Advisory Circular
AE Architect and Engineering Firm
ALARP As Low as Reasonably Practicable
ANSI American National Standards Institute
ARP Aerospace Recommended Practice
CDRL Contract Data Requirements List
COTS Commercial Off-The-Shelf
CSCI Computer Software Configuration Item
CSI Critical Safety Item
ECP Engineering Change Proposal
ENG Engineering
EOD Explosive Ordnance Disposal
EPA Environmental Protection Agency
ESF Engineered Safety Feature
FAA Federal Aviation Administration
FHA Functional Hazard Assessment
FMEA Failure Modes and Effects Analysis
FMECA Failure Mode, Effects and Criticality Analysis
FTA Fault Tree Analysis
G-48 System Safety Committee of SAE International
GEIA Government Electronics and Information Technology Association
GOTS Government Off-The-Shelf
HF Human Factors
HHA Health Hazard Assessment
HSI Human Systems Integration
HTS Hazard Tracking System
IMS Integrated Master Schedule
IPT Integrated Product Team
IRS Interface Requirements Specification
ISSPP Integrated System Safety Program Plan
ITAA Information Technology Association of America
IV&V Independent Verification and Validation
MA Managing Authority
MGT Management
MRAL Mishap Risk Acceptance Level
N/A Not Applicable
NEPA National Environmental Policy Act
NSC Not Safety Critical
O&SHA Operating and Support Hazard Analysis
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 5 of 1 04
PHA Preliminary Hazard Analysis
PHL Preliminary Hazard List
PM Program Manager
PSSA Preliminary System Safety Assessment
PTR Program Trouble Report
QRA Quantitative Risk Assessment
SAR Safety Assessment Report
SCC Software Control Category
SCCSC Safety Critical Computer Software Component
SCF Safety Critical Function
SCI Software Criticality Index, Safety Critical Item
SCN Specification Change Notice
SDP Software Development Plan
SDR System Design Review
SHA System Hazard Analysis
SIAM Software Integrity Assurance Matrix
SOW Statement of Work
SPR Software Problem Report
SQA Software Quality Assurance
SRCA Safety Requirements/Criteria Analysis
SRR System Requirements Review
SRS Software Requirements Specification
SSA System Safety Assessment
SSI Safety Significant Item
SSG System Safety Group
SSHA Subsystem Hazard Analysis
SSMP System Safety Management Plan
SSPP System Safety Program Plan
SSR Software Specification Review
SSS System/Segment Specification
SSWG System Safety Working Group
STP Software Test Plan
TDD Task Data Description
WBS Work Breakdown Structure
3.2 Definitions
Definitions used in this standard may differ from those used in other standards. In interpreting and applying this standard,
care should be taken to ensure that use of these terms is consistent with their definitions as found herein. Within this
document, the following definitions apply:
ACQUISITION PROGRAM: A directed, funded effort designed to provide a new, improved, or continuing system in response
to a validated operational need.
AS LOW AS REASONABLY PRACTICABLE (ALARP): That level of risk which can be further lowered only by an increment
in resource expenditure that cannot be justified by the resulting decrement in risk. Often identified or verified by formal or
subjective application of cost-benefit analysis or multi-attribute utility theory.
ACCEPTABLE RISK: That level of residual safety risk that the Managing Authority is willing to assume on behalf of the
agency, users, and public.
ASSET: Something of value. Assets include but are not limited to personnel, facilities, equipment, operations, data, the
public, and the environment, as well as the system itself.
BLACK BOX TESTING: Testing software without the knowledge of the internal structure or coding inside the program.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 6 of 1 04
CRITICAL CHARACTERISTIC: Any feature throughout the life cycle of a Critical Safety Item, such as dimension, tolerance,
finish, material or assembly, manufacturing or inspection process, operation, field maintenance, or depot overhaul
requirement that if non-conforming, missing, degraded or absent could result in a mishap with consequences unacceptable
to the Managing Authority.
CRITICAL SAFETY ITEM: A part, subassembly, assembly, subsystem, installation equipment, or support equipment for a
system that contains a characteristic, any failure, malfunction, or absence of which could result in an mishap as defined by
the Managing Authority.
DE MINIMIS THRESHOLD: The level of mishap risk below which a hazard does not warrant any expenditure of resources
to track or mitigate. From the Latin phrase “de minimis non curat lex” which means “the law does not concern itself with
trifles.”
DESIGN CONTROL ACTIVITY: The entity (person, organization, or function) that is specifically responsible for ensuring
that all system requirements, including safety, are designed into a system or equipment.
DEVELOPER: The individual or organization assigned responsibility for a development effort.
DEVELOPMENT AGREEMENT: Formal documentation of the agreed-upon tasks that the Developer should execute for the
program. For a commercial Developer, this agreement usually is in the form of a written contract.
ENGINEERED SAFETY FEATURE (ESF): An actively functioning design feature included in the system to reduce the
mishap risk. ESFs generally involve a system element that is automatically actuated, though provisions for manual actuation
may exist. Examples of ESFs include the emergency core cooling system of a nuclear reactor and loss-of-tension braking
for elevators.
FAIL SAFE: A system attribute involving incorporation of a feature to automatically counteract the effect of an anticipated
possible source of failure, although at the otherwise harmless sacrifice of functions.
FUNCTIONAL HAZARD ASSESSMENT (FHA): A systematic, comprehensive top-down examination of functions to identify
and classify failure conditions of those functions according to their severity and assigning, to each failure condition
probability, requirements and applicable qualitative design requirements.
HAZARD:
1 . Potential for harm.
2. A condition prerequisite to a mishap.
HAZARD DESCRIPTION: A brief narrative of what the hazard is. The description should include Source of the threat of
harm, the Mechanism through which it can do harm, and the Outcome if that occurs.
HAZARD SOURCE: A condition or activity that creates the potential for harm.
HAZARD MECHANISM: The means by which a condition or activity can become a mishap.
HAZARD OUTCOME: The harm that might be suffered from a mishap.
HAZARDOUS: Containing some element of safety risk and capable of inflicting harm.
HAZARDOUS FUNCTION: A function that, if performed inadvertently, performed incorrectly, performed out-of-sequence,
or not performed, could result in a mishap unacceptable to the Managing Authority.
HAZARDOUS MATERIAL: Any substance that, due to its chemical, physical, or biological nature, causes safety concerns
that would require an elevated level of effort to manage.
HEALTH HAZARD ASSESSMENT (HHA): The application of biomedical knowledge and principles to identify and eliminate
or mitigate health hazards associated with systems in direct support of the life cycle management of materiel items.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 7 of 1 04
HUMAN FACTORS: A disciplined, unified, and interactive approach used to integrate human considerations into system
design, improve total system performance, and reduce costs of ownership. The major considerations of Human Factors
include: human factors ergonomics, manpower and personnel, training, and occupational safety and health.
LIFE CYCLE: All phases of the system’s life including concept refinement, technical development, system development and
demonstration, production and deployment, operations and support, and disposal.
MANAGING AUTHORITY: The entity that has management responsibility for the system, or Developer who imposes system
safety tasks on their suppliers.
MISHAP (ACCIDENT): An unplanned event or series of events resulting in death, injury, system damage, or loss of or
damage to equipment or property.
MISHAP FREQUENCY: Rate of mishap occurrence. Frequency is sometimes substituted for probability as a component of
risk (example: loss events per 1 0 6 operating hours).
MISHAP LIKELIHOOD: Likelihood of mishap occurrence 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 should 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 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, 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 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, property 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 mitigating measure or a mitigation.
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 and associated functions essential for support of designated systems. This term is normally 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 hazards. 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 (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 partial
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/or the probability of the risk posed by one
or more system hazards.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 8 of 1 04
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, subsystems, 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 applicable
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 part of the system, such as physical guards or barricades, should be distinguished from
those 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 ITEM (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 function 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 logical 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.
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 operational
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 needs. 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 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 techniques to identify and mitigate hazards, in order to reduce
the associated mishap risk.
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, acquisition, 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 with the overall program requirements.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 9 of 1 04
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, and 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 that 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 associated 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 mandatory requirements for an acceptable system safety program for any system. The
PM should 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 cycle 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 hazard analysis, risk assessment, and risk management.
4.1 System Safety Program Elements
The Managing Authority should 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 complete system safety program.
Within each of the elements, the Managing Authority and developer should tailor the system safety program to fit the system
context, unique hazards, and fiscal limitations. The Managing Authority should allocate sufficient resources to accomplish
each safety element. Additional guidance on system safety program tailoring can be found in A.3.1 .2.1 .
4.1 .1 Element 1 - Program Initiation
The Managing Authority should document the approved system safety engineering approach and other actions needed to
establish a fully functional system safety program. Guidance can be found in 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 use of a hazard tracking system
(HTS) and continuous tracking of the hazards throughout the life cycle. Guidance can be found in 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 (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 A.3.3.
4.1 .4 Element 4 - Risk Reduction
Risk reduction is achieved by accomplishing the following steps.
a. Understand the risk drivers.
b. Develop and document candidate mitigators.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 1 0 of 1 04
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 A.3.4.
4.1 .4.1 System Safety Mitigation Order of Precedence
In reducing risk, the cost, feasibility, and effectiveness of candidate mitigation methods should be considered. In evaluating
mitigation effectiveness, an order of precedence generally applies as follows.
4.1 .4.1 .1 Eliminate Hazard Through Design Selection
Ideally, the risk of a hazard should 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 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 Risk Through Design Alteration
If the risk of a hazard cannot be eliminated by adopting an alternative design, design changes should 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.
4.1 .4.1 .3 Incorporate Engineered Safety Features (ESF)
If unable to eliminate or adequately mitigate the risk of a hazard through a design alteration, reduce the risk using an ESF
that actively interrupts the mishap sequence. Examples include: the emergency core cooling system of a nuclear reactor;
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 mishap 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 barricades, 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 component 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 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 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.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 1 1 of 1 04
4.1 .5 Element 5 - Risk Acceptance
The Developer PM should 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 should consider the
risk of the individual hazard 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.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.
4.2.3 Subject Term (Key Word) Listing
• As low as reasonably practicable (ALARP)
• Environmental
• Hazard
• Mishap
• Mishap probability category
• Mishap risk category
• Mishap severity category
• Mitigator
• Risk
• System safety engineering
• System safety management
• Total system risk
4.2.4 Use of System Safety Data in Certification and Other Specialized Safety Approvals
Hazard analyses are often required for many related certifications and specialized reviews. Examples of activities requiring
data generated during a system safety effort include:
• Federal Aviation Administration (FAA) airworthiness certification of designs and modifications.
• Airworthiness determination.
• Munitions certification.
• Flight readiness reviews.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 1 2 of 1 04
• Flight test safety review board reviews.
• Test readiness reviews.
• Safety review boards for research, development, test, and evaluation.
• Nuclear Regulatory Commission licensing.
• Department of Energy certification.
• Third party (e.g., factory mutual, underwriters laboratories) subcomponent certification for specific items for support
equipment type risk.
5. DETAILED REQUIREMENTS
The Managing Authority should identify, in the solicitation and system specification, any specific system safety engineering
requirements including risk assessment and acceptance, unique classifications and certifications, or any mishap reduction
needs unique to their program. Additional information for use in developing program-specific requirements appears in
Appendices A and B, with task data descriptions (TDDs) appearing in Appendix C.
6. NOTES
6.1 Revision Indicator
A change bar (I) located in the left margin is for the convenience of the user in locating areas where technical revisions, not
editorial changes, have been made to the previous issue of this document. An (R) symbol to the left of the document title
indicates a complete revision of the document, including technical revisions. Change bars and (R) are not used in original
publications, nor in documents that contain editorial changes only.

PREPARED BY SAE COMMITTEE G-48, SYSTEM SAFETY

SAE INTERNATIONAL GEIA-STD-001 0™ A Page 1 3 of 1 04
APPENDIX A - GUIDANCE FOR IMPLEMENTATION OF A SYSTEM SAFETY EFFORT
A.1 SCOPE
This appendix provides rationale and guidance to fit the needs of most system safety efforts. It includes further explanation
of the effort and activities available to meet the general requirements described in Section 4 of this Standard. With the
exception of the paragraphs listed in Section A.4, this appendix is not a mandatory part of this guide and is not to be included
in solicitations by reference. However, portions of this appendix may be extracted for inclusion in requirement documents
and solicitations.
A.2 TERMS AND DEFINITIONS
A.2.1 Acronyms used in this appendix
No additional acronyms are used in this appendix (see 3.1 ).
A.2.2 Definitions
No additional definitions are used in this appendix (see 3.2).
A.3 GENERAL REQUIREMENTS
System safety applies engineering and management principles, criteria, and techniques to achieve ALARP (acceptable risk)
within the constraints of operational effectiveness, time, and cost, throughout all phases of the system life cycle. It draws
upon professional knowledge and specialized skills in the mathematical, physical, and scientific disciplines, together with
the principles and methods of engineering design and analysis, to specify and evaluate the mishap risk to people, systems,
and the environment associated with a system. Experience indicates that the degree of safety achieved in a system is
directly dependent upon the emphasis given and the proper allocation of specific planning, requirements, analysis, testing,
and verification tasks.
System safety program requirements can be grouped into the five major elements (Figure A1 ):
Element 1 - Program Initiation,
Element 2 - Hazard Identification,
Element 3 - Risk Assessment,
Element 4 - Risk Reduction, and
Element 5 - Risk Acceptance
Elements 1 and 5 are primarily system safety management-related functions and Elements 2, 3, and 4 are considered
system safety engineering functions.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 1 4 of 1 04
Program Initiation
• Docu men t th e

System Safety Approach

• Tasks
• Sch ed u l e
• Team
• Tool s

Hazard Identification
Risk Assessment
• Recog n i ze & Docu men t
Understanding
H azard s
Hazards • Assess M i sh ap Ri sk

Continuous Understanding
Maturing Risk Drivers
Design • H azard Iterative
Life Cycle Tracki n g
Risk Reduction
Monitoring Continuous Changes
Risk Reduction
Risk Acceptance
Understanding • I d en ti fy M i ti g ation M easu res
• Resi d u al Ri sk Revi ew
Risk Options • Red u ce Ri sk to Acceptabl e Level
& Acceptan ce
• Veri fy Ri sk Red u cti on

T-05-0051 2

Figure A1 - System safety program elements

A.3.1 Element 1 - Program Initiation
Program initiation is the foundation of the safety program. As shown in Figure A2, it is important to establish the key elements
and actions of the safety program in this element. Products of Element 1 may include an SSMP, if required, an SSPP, and
a charter for the System Safety Working Group (SSWG).
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 1 5 of 1 04

Element 1 – Program Initiation

Getting the Right Start
Key Elements Actions
Managing Authority SSMP
Program Prepare
Manager SSMP • Authority
• Organization
• Responsibilities
• Risk Management
Safety Approach
Professional • Government
Management Tasks
• IPT/SSWG Charter
Safety
IPT/SSWG Establish Safety
Provisions in Developer SSPP
CDRLs Contract Data
Prime Contract
Requirements List
• Organization
IPT Integrated Product • Resources
Team Request for Proposal • Analysis Tasks
SOW Statement of Work • Analysis Methods
• SOW • Hazard ID & Tracking
SSMP System Safety • CDRLs • Reports
Management Plan • Audits
• Clauses • Contractor Tasks
SSPP System Safety • Evaluation Criteria • Risk Assessment Methods
Program Plan • SSPP • Subcontractor Integration
• Milestones
SSWG System Safety
Working Group Specifications
T-05-00501

Figure A2 - Program element 1 - Program initiation

A.3.1 .1 Define Program Authorizations and Charters
The Managing Authority(ies) should establish and execute system safety programs that manage the risk of each single
hazard (r) as well as the total system risk (R). Provisions for system safety requirements and effort as defined by this
standard should be included in all applicable contracts. Properly initiated programs should be formalized in documentation
approved by the Managing Authority indicating the actions to be taken by the safety organization.
A.3.1 .2 Plan a System Safety Program
Before formally documenting the system safety approach in the SSMP and contract statement of work (SOW), the
Developer, in concert with system safety professionals, should determine what system safety effort and specific tasks and
activities are necessary to meet program and regulatory requirements. This requires the system boundaries and usage
context to be clearly defined within the plan, including assumptions that establish the depth and breadth of the analyses.
This effort includes developing a planned approach for safety task accomplishment, providing qualified people to accomplish
the tasks, establishing the authority for implementing the safety tasks through all levels of management, and allocating
appropriate resources to ensure that the safety tasks are completed. This is an on-going process to include additional
analysis based on findings from previous efforts. System safety planning includes the following.
A.3.1 .2.1 Tailor the Program
Selective tailoring of a system safety program is necessary to effectively achieve all of the safety objectives within the
constraints of performance, cost, schedule, and potential mishap loss. As such, tailoring becomes an important aspect of
establishing an effective and successful program. Some of the important aspects to consider include the following.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 1 6 of 1 04
A.3.1 .2.1 .1 Tasks
Individual tasks from Appendix B should be applied as needed for a particular program. A large and/or complex safety
critical system would likely require more tasks than a smaller system. The detailed task data descriptions (TDDs) are located
in Appendix C.
A.3.1 .2.1 .2 Analyses
Specify only those safety analyses necessary for the particular program. For example, a safety critical system (aircraft,
missile, air traffic control, ships, mass transit, etc.) may need a preliminary hazard list (PHL), preliminary hazard analysis
(PHA), functional hazard assessment (FHA), preliminary system safety assessment (PSSA), system safety assessment
(SSA), subsystem hazard analyses (SSHA), system hazard analysis (SHA), operating and support hazard analysis
(O&SHA), safety assessment report (SAR), health hazard assessment (HHA), safety requirements/criteria analysis (SRCA),
and Critical Safety Item (CSI) List. A less-safety-critical system may only need a PHL and PHA for an effective system
safety program.
A.3.1 .2.1 .3 Mishap Risk Assessment Matrix and Scaling
The method of risk assessment and representation used by the program should be selected and tailored to fit practical
program needs. For some programs, a quantitative risk assessment matrix may be appropriate, while others may require a
qualitative (subjective) matrix. Matrix axis scaling should also be tailored to match practical program needs. For example,
systems for which loss events carry very small penalties would require correspondingly lower matrix severity scale values
than those capable of producing very costly losses. Similarly, matrices for systems capable of high cost losses would
customarily require probability scaling at lower values than those for systems having only low cost loss expectancy.
A.3.1 .2.1 .4 Acceptance Levels
The risk acceptance levels that are appropriate to the particular product or system. Different size and complexity programs
may utilize different levels.
A.3.1 .2.1 .5 Preferred Formats
Determine the preferred format of the safety and hazard analyses. For example, the SSPP for a system of systems type
program may desire to standardize the analyses formats for all of the lower tier systems and elements involved.
A.3.1 .2.1 .6 Verification Methods
Determine the safety verification methods to be utilized. Depending upon the program size and level of risk, some programs
may require more testing while others may need less testing and more analysis.
A.3.1 .2.1 .7 System Safety Program Plan (SSPP)
The SSPP should describe and document the tailored system safety program. The SSPP should contain a description of
the planned methods to be used to implement the tailored requirements of this standard, including organizational
responsibilities, resources, methods of accomplishment, milestones, analyses, depth of effort, risk characterization and
integration with other program engineering and management activities and related systems.
A.3.1 .2.2 Establish Safety Performance Requirements
Establish specific safety performance requirements based on overall program requirements and system user inputs. These
are the general safety requirements needed to meet the core program objectives. The more closely these requirements
relate to a given program, the more easily the designers can incorporate them into the system. It may be helpful to start with
requirements from a similar system. In the appropriate system specifications, incorporate the safety performance
requirements that are applicable, and the specific risk levels considered acceptable for the system. Acceptable risk levels
can be defined in terms of a mishap risk category developed through a mishap risk assessment matrix; an overall system
mishap rate; demonstration of controls 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.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 1 7 of 1 04
A.3.1 .2.2.1 Quantitative Requirements
Quantitative requirements 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.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 assessment, 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 Xxxxxxxx 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 lines 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 organizational
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) should be included.
A.3.1 .2.4 Establish System Safety Milestones
Establish system safety milestones and relate these to major program milestones, program element responsibility, and
required inputs and outputs.
A.3.1 .2.5 Establish an Incident Alerting/Notification, Investigation, and Reporting Process
Establish an incident alerting/notification, investigation, and reporting process, to include notification of the Managing
Authority and Developer.
A.3.1 .2.6 Establish Acceptable Levels
Establish an acceptable level of mishap risk, mishap probability or frequency, and mishap severity thresholds, and
documentation requirements (including but not limited to hazards and mishap risk).
A.3.1 .2.7 Establish a Reporting Approach and Methodology
Establish an approach and methodology for reporting to the Managing Authority the following minimum information:
• Safety critical characteristics and features.
• Critical Safety Items.
• Operating, maintenance, and overhaul safety requirements.
• Measures used to eliminate or mitigate hazards.
• Selection, acquisition, and process management for hazardous materials.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 1 8 of 1 04
A.3.1 .2.8 Establish the Method for Formal Acceptance and Documentation
Establish the method for the formal acceptance and documentation of mishap risks and the associated hazards.
A.3.1 .2.9 Establish the Communication Method
Establish the method for hazards, the associated risks, and mishap risk to the system user.
A.3.1 .2.1 0 Specify Requirements for Other Specialized Safety Approvals
Specify requirements for other specialized safety approvals (e.g., nuclear, explosive, chemical, biological, electromagnetic
radiation, and lasers) as necessary (reference 4.2.4).
A.3.1 .2.1 1 Specify the Typical Boundaries and Assumptions
Specify the typical boundaries and assumptions for the system safety analyses and the typical limits of the analyses. These
may include whether or not the following are examined and/or analyzed:
• Hostile intentions or sabotage upon the system.
• Basic structural integrity.
• Hazards unique to factory support.
• The assumption that only trained, healthy, working-age adults will operate and support the system.
• Appropriate quality control and configuration standards are used in production, assembly and support.
A.3.1 .2.1 2 Establish the Plan for Updating the Hazard analyses
Hazard analyses have limited resolution depending on the system and details of the hazards. Analyses should be updated
as more information is acquired.
A.3.1 .3 Develop a System Safety Management Plan
This plan documents the Developer’s approved system safety engineering and management approach. It should include
the information called out in the following subparagraphs.
A.3.1 .3.1 Overall System Safety Integration
Information on system safety integration into the overall program structure.
A.3.1 .3.2 Software System Safety Integration
Where software controls or mitigates system hazards, include specific details on integration of system safety processes and
products into the software development life cycle. As a minimum address the following topics:
a. Identification and description of software contributors to hazards;
b. Definition of safety critical;
c. Identification of safety critical software functions and safety critical software requirements;
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 1 9 of 1 04
d. Identification of the software hazard criticality assessment process to include establishment of the software criticality
index matrix (see Section A.6) for each safety critical software function and safety critical requirement and how it would
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 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.
A.3.1 .3.4 The Mishap Risk Assessment Tool
Define the mishap risk 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 those risks. Programs may use one
matrix to assess risks from individual hazards, and another matrix to accept total system risk. These tools should 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. A software hazard criticality assessment and software safety integrity assessment should 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 integrity assurance tasks a final risk
assessment can be performed based on the confidence gained in the software (see A.6.3).
A.3.1 .3.4.1 Use of the Mishap Risk Assessment Matrix
The mishap risk assessment matrix is normally a two-dimensional graphic device. One axis is scaled to represent mishap
severity, and the other is scaled to represent mishap probability or frequency. The four principal uses of the matrix are:
a. Communicates the range of potential risks of the system in terms of mishap severity and mishap probability or
frequency;
b. Guides assessment of risk for single hazards;
c. Displays the results of risk assessments, risk mitigation and reduction; and
d. Delineates 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 should be used to characterize these risks. A pre-existing
matrix may be used or a uniquely tailored matrix may be developed. In developing and tailoring the risk matrix, these
elements should 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 probability (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. Assign the four levels of risk acceptance authority (high, serious, medium, low) to each cell of the matrix.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 20 of 1 04
A.3.1 .3.4.3 Mishap Risk Assessment Matrix Tailoring
New or tailored matrices should be developed by defining and scaling the severity and probability or frequency scales that
bound the risk of the 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 which 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 requirement 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 A1 0, A1 1 , and A1 2 for examples 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 software, safety devices, or other special safety features
(e.g., render safe and emergency disposal procedures).
• Describe the mishap or incident notification, investigation, and reporting process for the program, including notification
of the Managing Authority.
• Describe the approach for collecting and processing pertinent historical hazard, mishap, and safety lessons learned
data. Include a description on how a system hazard log is developed and maintained.
• Describe how the user is kept informed of mishap risk and the associated hazards.
• Describe the approach to the identification, management, and control of Critical Safety Items.
A.3.1 .4 Define a Strategy to Ensure Appropriate Safety Support
Elements of safety need to be embedded in the prime contractor’s SOW and, if necessary, supporting contracts. Contractors
should be required to submit with their proposal a preliminary plan (e.g., SSPP) that describes the system safety effort
required for the requested program. When directed by the PM, attach this preliminary plan to the contract or reference it
within the SOW; so it becomes the basis for a contractual system safety program.
A.3.1 .4.1 Individual Safety Support Tasks
Include selected tasks from Appendix B. Individual tasks should be applied as needed for the particular program. Some
programs may require only one or two tasks (e.g., a single PHA or a safety assessment report (SAR)), while other more
complex programs may require application of most or all of the tasks. The documentation of the system safety approach
should describe the planned tasks and activities of system safety management and systems engineering required to identify,
evaluate, and eliminate or mitigate hazards. The goal of this effort is to reduce the mishap risk to a level ALARP throughout
the system life cycle. The documentation should describe, as a minimum: a planned approach for task accomplishment,
qualified people to accomplish tasks, the authority to implement tasks through all levels of management, and the appropriate
commitment of resources (both manning and funding) to ensure that safety tasks are completed. Specifically, the
documentation must:
A.3.1 .4.1 .1 Scope
Describe the scope of the overall system program and the related system safety effort.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 21 of 1 04
A.3.1 .4.1 .2 Milestones
Define system safety program milestones. Relate these to major program milestones, program element responsibility, and
required inputs and outputs.
A.3.1 .4.1 .3 Safety Tasks and Activities
Describe the safety tasks and activities of system safety management and engineering. Describe the interrelationships
between system safety and other functional elements of the program. List the other program requirements and tasks
applicable to system safety and reference where they are specified or described. Include the organizational relationships
between other functional elements having responsibility for tasks with system safety impacts and the system safety
management and engineering organization including the review and approval authority of those tasks.
A.3.1 .4.1 .4 Program-Specific Safety Tasks
Select tasks to fit the program. In most cases, the need for the tasks is self-evident. While experience plays a key role in
task selection, it must be supplemented by a more detailed study of the program. Consideration must be given to the size
and dollar value of the program and the expected level of risk involved. The selection of tasks must be applicable not only
to the program phase, but also to the perceived risks involved in the design and the funds available to perform the system
safety effort. Table A1 provides examples of typically tailored system safety programs based on size or project risk. Once
recommendations for task applications have been determined and more detailed requirements identified, tasks and
requirements can be prioritized and a “rough order of magnitude” estimate must be made of the time and effort required to
complete each task. This information would be of considerable value in selecting the tasks which can be accomplished
within schedule and funding constraints.
A.3.1 .4.1 .5 Task Data Descriptions
For safety tasks that require a report or other formal data submittal, specific task data descriptions (TDDs) provide details
expected in the data delivery product. TDDs for applicable safety tasks are provided in Appendix C.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 22 of 1 04
Table A1 - Application matrix for system program development

Task Program Phase

Task Title Type 0 I II III IV
1 01 System Safety Program MGT G G G G G
1 02 System Safety Program Plan (SSPP) MGT G G G G G
1 03 Integration/Management of Associate Contractors, Subcontractors,
and Architect and Engineering (AE) Firms MGT S S S S S
1 04 System Safety Program Review /Audits MGT S S S S S
1 05 System Safety Group (SSG)/System Safety Working Group
(SSWG) Support MGT G G G G G
1 06 Hazard Tracking and Risk Resolution MGT S G G G G
1 07 System Safety Progress Summary MGT S G G G G
1 08 Launch Safety Program Requirements MGT S S S S S
1 09 Test Hazard Analysis Safety (Ground or Airborne Systems) MGT S S S S S
201 Preliminary Hazard List (PHL) ENG G S S S N/A
202 Preliminary Hazard Analysis (PHA) ENG G G G GC GC
203 Safety Requirements/Criteria Analysis (SRCA) ENG G S S S GC
204 Subsystem Hazard Analysis (SSHA) ENG N/A G G GC GC
205 System Hazard Analysis (SHA) ENG N/A G G GC GC
206 Operating and Support Hazard Analysis (O&SHA) ENG S G G GC GC
207 Health Hazard Assessment (HHA) ENG G G G GC GC
208 Functional Hazard Analysis (FHA) ENG G G G GC GC
209 Critical Safety Items (CSI) List ENG S G G G G
301 Safety Assessment Report (SAR) ENG S S S S S
302 Test and Evaluation Safety ENG G G G G G
Safety Review of ECPs, Specification Change Notices (SCN),
303 Software Problem Reports (SPR), Program Trouble Reports (PTR), ENG N/A G G G GC
and Requests for Deviations and Waivers
401 Safety Verification ENG S G G S S
402 Safety Compliance Assessment ENG S G G S S
NOTES: TASK TYPE PROGRAM PHASE APPLICABILITY CODES
ENG - System Safety Engineering O Concept refinement S Selectively Applicable
MGT - System Safety Management I Technology development G Generally Applicable
II System development and demonstration GC Generally Applicable to Design Change
III Demonstration, production, and deployment N/A Not Applicable
IV Operations and support

A.3.1 .4.1 .6 Analysis Techniques and Formats

Describe specific analysis techniques and formats to be used in quantitative or qualitative assessments of hazards.
A.3.1 .4.1 .7 Management Decision Process
Describe the process through which management decisions will be made (for example, timely notification of unacceptable
risks, necessary action, incidents or malfunctions, waivers to safety requirements, and program deviations). Include a
description of how mishap risk is formally accepted and this acceptance is documented.
A.3.1 .4.1 .8 Developer Support to Certification Boards
Identify special support from the Developer to support certification boards.
A.3.1 .4.2 Mishap Risk Assessment Procedures
Describe the mishap risk assessment procedures, including the mishap severity categories, mishap probability categories,
and the system safety mitigation order of precedence that should be followed to satisfy the safety requirements of the
program. State any subjective or quantitative measures of safety to be used for the mishap risk assessment process
including any associated criteria. Include system safety definitions that modify, deviate from, or are in addition to those in
this standard or generally accepted by the system safety community.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 23 of 1 04
A.3.1 .5 Preliminary Understanding of Hazards
Develop a preliminary understanding of hazards and a related description or identification. Each type of system has generic
hazards that can be recognized before the design details are developed. This understanding will lead to the generation of
a PHL.
A.3.1 .6 Attributes of an Effective System Safety Program
Attributes of an effective system safety program include the following:
• Management is always aware of the mishap risks associated with the system, and formally documents this awareness.
Hazards associated with the system are identified, assessed, tracked, monitored, and the associated risks are either
eliminated or mitigated to an acceptable level throughout the life cycle. Identify and archive those actions taken to
eliminate or reduce mishap risk for tracking and lessons learned purposes.
• Historical hazard and mishap data, including lessons learned from other systems, are considered and used.
• Mishap risk resulting from harmful conditions (e.g., temperature, pressure, noise, toxicity, acceleration, and vibration)
and human error in system operation and support is minimized. Design factors likely to contribute to human error are
identified and mitigated.
• System users are kept abreast of the safety of the system and included in the safety decision process.
A.3.2 Element 2 - Hazard Identification
Identify and track hazards through a systematic hazard analysis process encompassing detailed analysis of system
hardware and software, the environment (in which the system will exist), and the intended usage or application. Historical
hazard and mishap data, including lessons learned from other systems, should be considered and used. Identification of
hazards is a responsibility of all program members. During hazard identification and tracking; consider hazards that could
occur over the system life cycle. Products of this element may include a PHL and/or a functional hazard assessment and a
hazard tracking system (HTS). Figure A3 describes the process, methods, and products of this element.

Element 2 - Hazard Identification and Tracking

1 ) Process: Recognize and document hazards. This can be
achieved by a variety of methods. Key elements of
the risk assessment matrix are also defined.
Three parts of a hazard description
Identify
Identify Hazard
Hazard Source Mechanism Outcome
Hazards
Hazards Tracking
Tracking

2) Identification and Tracking Methods:

• Checklists Includes:
• System energy source inventory • Description
• Prior work with similar systems • Assessed risk
• Operating scenario walkthroughs • Potential and selected countermeasures
• Operational phase review • Accident experience
• Codes/standards/regulations • Lessons learned

3) Products: PHL HTS

T-05-00502

Figure A3 - Program element 2 - Hazard identification

SAE INTERNATIONAL GEIA-STD-001 0™ A Page 24 of 1 04
A.3.2.1 Identify Hazards
Hazard identification can be achieved by a variety of mutually complementary methods including the use of checklists, prior
work with similar systems, and operating scenario walkthroughs. Approaches have been developed and used to identify
system hazards. Commonly used approaches for identifying hazards can be found in the reference material listed in
Section 2 of this standard. A key aspect of many of these approaches is empowering the design engineer with the authority
to design systems whose mishap risk is ALARP and the responsibility to identify to program management the hazards
associated with the design. Hazard identification approaches often include using system users in the effort.
A.3.2.2 Describe Hazards
Hazards should be described in terms that identify: a potential source of harm, the mechanism whereby the harm may be
caused, and the outcome of the harm itself. Keep in mind that one combination of source and mechanism may have the
potential to cause harm to more than one asset, an asset being something of value. Assets include but are not limited to
personnel, facilities, equipment, operations, data, the public, and the environment, as well as the system itself. An effective
way to deal with these multiple outcomes from one source and mechanism is to treat each outcome, each harmful impact
on an asset, as a separate hazard. The importance of this becomes obvious during the risk reduction element (A.3.4) when
each potential mitigator is identified and its effectiveness in reducing the risk to each asset is weighed against the cost and
feasibility of the mitigator. In some cases outcomes may be tightly linked, for instance, “death or serious injury to personnel”
is linked to “serious damage to or loss of aircraft” when a hazard mechanism includes aircraft impact with the ground. In
this case, these two outcomes might best be treated as components of a single hazard.
A.3.2.3 Track Hazards, Hazard Closure, and Mishap Risk
Maintain a HTS that includes hazard descriptions, mishap severity and probability, hazard causes (which may relate to
hardware, software, or human-systems interface), mitigators for each cause, and verification for each mitigator, their closure
actions, and mishap risk throughout the system life cycle. The HTS should be maintained throughout the system life cycle.
A.3.2.3.1 Process for Tracking of Hazards and Mishap Risk
Each system should have a current log of identified hazards including an assessment of the mishap risk. As changes are
integrated into the system, this log is updated to incorporate added or changed hazards and the associated mishap risk.
The Managing Authority should formally accept residual mishap risk of system hazards. Users should be kept informed of
hazards and mishap risk associated with their systems.
A.3.2.3.2 Program Manager Responsibilities for Communications, Acceptance, and Tracking of Hazards and Mishap
Risk
The Developer PM is responsible for maintaining a log of all identified hazards of the system. The Developer PM should
communicate known system hazards and associated risk to all system developers and users. As changes are integrated
into the system, the Developer PM should update this log to incorporate added or changed hazards and the mishap risk
identified by the Developer. The Developer PM is also responsible for informing his team about his expectations for handling
of newly discovered hazards. The Developer PM should evaluate new hazards and the resulting mishap risk, and either
recommend further action to mitigate the hazards, or formally document the acceptance of these hazards and mishap risk.
The Developer PM should evaluate the hazards and associated mishap risk in close consultation and coordination with the
Managing Authority, to assure that the context of the user requirements, potential mission capability, and the operational
environment are adequately addressed. Copies of the documentation of the hazard and risk acceptance are provided to
both the Developer and the system user. Hazards for which the Managing Authority accepts responsibility for mitigation
should also be included in the formal documentation. For example, if the Developer decides to execute a special training
program to mitigate a potentially hazardous situation, this approach should be documented in the formal response to the
Managing Authority. Mishap risk and hazards should be communicated to system test efforts for verification of the
effectiveness of risk mitigation.
A.3.3 Element 3 - Risk Assessment
After hazards are identified in Element 2, the identified hazards are reviewed and mishap severities, and probabilities or
frequencies are assessed and documented. Figure A4 shows a simplified version of the risk assessment process. The
products of this element may include a PHA, O&SHA, SSHA, SCF list, CSI list, and an SHA.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 25 of 1 04

Element 3 - Risk Assessment The matrix defines the “risk space” for a Reduction
single-system and a declared exposure not needed
1 ) Process: duration (e.g., 1 year, 1 lifecycle).
Assess the mishap risk. Risk Assessment Matrix-Individual Hazards
H7 H2

H6 H3
Assess
H9 H1 risks of

Severity
hazards
2) Assessment Methods: H5

H8
H4

• Expert judgment
• Historical risk experience Probability
• System knowledge
• Engineering judgment Assessment Approaches Reduction
• What is known/not known
Event needed
• Numerical analysis FMEA FTA Trees Others
• Computer models

3) Products: Others
PHA O&SHA SSHA SHA

T-05-00503

Figure A4 - Program element 3 - Risk assessment

A.3.3.1 Risk Assessment Methods
Several methods are available to assess the mishap risk including expert judgment, numerical analysis, computer models,
failure modes and effects analysis (FMEA), and fault tree analysis (FTA). Mishap risk assessment matrices described in
Section A.5 may be used to assess mishap risk of a hazard in terms of severity, and probability or frequency. For each
identified hazard, consider the postulated outcomes to determine the range of severity of the hazard. For each mishap
severity category associated with the range of severity, consider the postulated sources, which may relate to hardware,
software, or human-systems interface, as well as the likelihood that given sources may lead to applicable outcomes, to
assess the mishap probability category. Determine which severity-probability pair has the greatest risk. This pair is the
assessed mishap risk of the hazard. If two or more severity-probability pairs are of equal risk then the one with the greatest
severity is the assessed mishap risk. Assessing a hazard in terms of one cell of a mishap risk assessment matrix associates
the risk with a cell of the matrix but stops short of actually determining the specific loss of assets over the life of the system.
If possible, estimate these losses to aid in the analysis of the effectiveness of risk reduction mitigators (A.3.4) and to better
inform the designated risk acceptance authority who decides whether to accept residual mishap risk or continue risk
reduction efforts. To ensure effectiveness of risk mitigation, the risk assessment process should clearly link each mitigator
with the hazard sources and mechanisms to which it applies.
A.3.3.1 .1 Mishap Risk Impact
The mishap risk impact is assessed, as necessary, using other factors to discriminate between hazards having the same
mishap risk index. One might discriminate between hazards with the same mishap risk index in terms of mission capabilities,
or social, economic, and political factors. Program management should closely consult with the using organization on the
decisions used to prioritize resulting actions.
A.3.3.1 .2 Mishap Risk Assessment Approaches
References for commonly used approaches for assessing mishap risk can be found in Section 3.
A.3.3.2 Assess Software Criticality
For systems with safety critical software (i.e., software controls safety critical functions), each safety critical software function
and requirement should be assigned a software criticality index (SCI). Guidance on software safety criticality assessment
is provided in Section A.6.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 26 of 1 04
A.3.3.3 Identify Critical Safety Items
A critical safety item (CSI, Task 209)) is defined as a part, subassembly, assembly, subsystem, installation equipment, or
support equipment for a system that contains a characteristic, any failure, malfunction, or absence of which could result in
mishaps with either catastrophic or critical outcomes. For systems required to have a CSI list, mishap risk assessment
should be used to develop that list.
A.3.3.3.1 Functional Hazard Analysis
To identify CSIs, the contractor performs a functional hazard analysis (FHA, Task 208) to identify the safety critical functions
(SCF) of the system, then maps the list of SCFs to the design to identify safety critical systems and sub-systems (hardware
and software). Hardware items that have critical characteristics that are essential to the SCF are CSIs. A critical
characteristic is defined as any feature such as dimension, tolerance, finish, material or assembly, manufacturing or
inspection process, operation, field maintenance, or depot overhaul requirement that if non-conforming, missing, or
degraded during the life cycle of a CSI, may cause the failure or malfunction of the item. In lieu of an FHA, a failure mode,
effects and criticality analysis (FMECA) may also serve to provide the list of CSIs.
A.3.3.3.2 Design Control Activity
The appropriate design control activity approves contractor-developed CSI lists. The design control activity is the systems
command of a military department that is specifically responsible for ensuring the military worthiness of a system or
equipment. Generating the CSI list is an iterative process that begins when SCFs are identified. The CSI List may be
finalized at critical design review but should be provided as timely inputs to supportability and maintenance planning
processes. Clear, consistent identification of CSIs is fundamental to ensuring proper priorities, treatment, and controls are
implemented throughout the product’s life cycle.
A.3.3.4 Total System Risk Consideration
Most hazard analysis techniques are designed to identify and assess the risk of individual hazards, considered one at a
time. Risk acceptance authorities, however, should also consider the overall, or total system, risk presented by the system
in its entirety. Consideration of total system risk is useful because the aggregation of a number of otherwise acceptable
individual risks may present an unacceptable risk when considered in total. Furthermore, the most cost effective approach
to lowering a system’s total system risk may be to further mitigate an otherwise acceptable individual risk. The program’s
treatment of total system risk should be identified in the SSMP and/or SSPP.
A.3.4 Element 4 - Risk Reduction
Risk reductions are achieved by understanding the risk drivers, reducing risk according to the system safety mitigation order
of precedence, and then reassessing the risks. Mitigators for reducing risk include design changes, engineered safety
features, safety devices, warning devices; and procedures or training. Mitigators may serve to eliminate the hazard or reduce
severity or probability of potential mishaps. The mitigators for each hazard should be selected based on effectiveness, cost,
and feasibility. Feasibility includes consideration of both means and schedule for accomplishment. After mitigators have
been selected, the residual mishap risks should be reassessed to ensure that risks are ALARP. Identify potential mishap
risk mitigation alternatives and the expected effectiveness of each alternative or method. Be aware that though the risk from
a hazard may have been reduced significantly, its assessment may remain in the same cell of the mishap risk assessment
matrix. This does not mean a mitigator will not be selected. Hazards should be prioritized so that corrective action efforts
can be focused on the most serious hazards first. A categorization of hazards may be conducted according to the mishap
risk potential they present. Mishap risk mitigation is an iterative process that culminates when the mishap risk has been
reduced to a level as low as reasonably practicable as determined by the appropriate authority. Typical products of this
element may include a SAR and hazard reports. The risk reduction element is shown in Figure A5 and discussed below.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 27 of 1 04

Element 4 - Risk Reduction

1 ) Process: Identify mitigation measures; reduce risk to an acceptable level; verify risk reduction.

Understand Risk Develop Candidate Select Verify Risk

Drivers Mitigators Mitigators Reductions

2) Reduction Understanding Mitigators Mitigators • Confirm

Methods: risk causation can Order of precedence: Selection Criteria: effectiveness
lead to prioritizing 1) Design selection • Cost • Ensure
hazard reductions 2) Design changes (vs. accepting risk) implementation
and/or direct 3) Engineered safety features • Effectiveness
countermeasure (In reducing risk)
selection. 4) Safety devices
5) Warning devices • Feasibility
• Means
6) Procedures/training • Schedule

Mitigators should not:

1) Introduce new hazards
2) Unacceptably impair system performance

3) Products Hazard
(typical): Reports SAR others
T-05-00504

Figure A5 - Program element 4 - Risk reduction

A.3.4.1 Understand the Risk Drivers
For the system, determine which hazards are the drivers of the total system risk (R). For each hazard, determine which
sources and mechanisms are the drivers of the single hazard risk (r). A good understanding of these risk drivers facilitates
effective development, selection and prioritization of risk mitigators.
A.3.4.2 Develop and Document Candidate Mitigators
Identify potential mishap risk mitigators and the expected effectiveness of each. Mishap risk mitigation is an iterative process
that culminates when the mishap risk has been reduced to a level ALARP as determined by the appropriate authority. As
hazard analyses are performed, hazards should be identified that would require mitigation. The system safety mitigation
order of precedence defines the order to be followed for satisfying system safety requirements and reducing risks. Evaluate
the alternatives for eliminating the specific hazard or mitigating its risk so that the most practicable mitigators can be
implemented. While the relative effectiveness, cost, and feasibility of specific mitigators may vary depending on the hazard,
the system safety mitigation order of precedence generally is as follows:
• Eliminate hazard through design selection.
• Reduce mishap risk through design alteration.
• Incorporate engineered safety features (ESF).
• Incorporate safety devices.
• Provide warning devices.
• Develop procedures and training.
Describe any potential risks introduced by mitigation approaches. For instance, pnuematic tools may be used in place of
electric tools, in wet environments, to eliminate risks of electrical shocks. A new risk introduced by this mitigation is that of
slightly higher noise levels.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 28 of 1 04
A.3.4.2.1 Software Safety Hazard Mitigation
The most effective approach to minimizing safety risk associated with software is to conduct the safety critical requirements
analysis (SCRA). The SCRA should be formally communicated with the software development team. An FHA should be
conducted to determine the effects on safety critical functions of the system to be commanded, controlled, and monitored
by software and to provide the software developer with clear concise derived safety requirements. The software safety
analyses (top-level, detail- level, code-level if required) are conducted as an integral part of the hazard analysis processes.
Only then can the software contributors to the hazards be understood. The software safety engineer should develop specific
safety requirements as part of software requirements to mitigate risk for these software contributors.
A.3.4.2.2 Specific Software Requirements
After the software contributors to hazards are understood, the software safety engineer should develop specific software
requirements to mitigate risk for these software contributors. The safety critical requirements should be communicated with
the software development team and tracked through the software development lifecycle down to the code and test
procedures. The software safety integrity assurance process (see Section A.6) should be used to provide assurance and
confidence that the specified safety critical software functionality and requirements have been implemented and verified.
Based on completion of all the software integrity assurance activities the software safety engineer can determine a level of
confidence that the software will perform as specified and that the associated hazards have been mitigated. The confidence
level can be used to perform a final risk assessment, as described in A.6.3. IEEE STD 1 228 is an existing commercial
standard that can be used as a guideline for Software System Safety.
A.3.4.3 Select Mitigators
Reduce the system mishap risk through mitigators mutually agreed to by the Managing Authority and the Developer.
Mitigators should be selected based on cost, effectiveness, and feasibility.
A.3.4.4 Verify Risk Reductions
Verify mishap risk mitigation through appropriate analysis, testing, and inspection. Mitigators should be evaluated to ensure
implementation and confirm effectiveness. Document the assessed residual mishap risk. The Developer PM should ensure
through the system test effort that the selected mitigators will produce the expected reduction in mishap risk. New hazards
identified during testing should be reported to the Managing Authority for further risk reduction efforts.
A.3.4.5 Testing
Mishap risk and associated hazards should be communicated to the system tester to verify mishap risk reduction of the
system undergoing testing and ensure that the mishap risk of the testing itself is ALARP.
A.3.4.5.1 Testing to Verify Risk Reduction
Tests and demonstrations should be defined and conducted to verify the effectiveness of selected mitigators. Test or
demonstrate safety critical equipment and procedures to determine the mishap severity or to establish the margin of safety
of the design. Consider induced or simulated failures to demonstrate the failure mode and acceptability of safety critical
equipment. When it cannot be analytically determined whether the corrective action taken will adequately mitigate a hazard,
conduct safety tests to evaluate the effectiveness of the mitigators. Where costs for safety testing would be prohibitive,
safety characteristics or procedures may be verified by engineering analyses, analogy, laboratory test, functional mockups,
or subscale and model simulation. Integrate testing of safety systems into appropriate system test and demonstration plans
to the maximum extent possible.
A.3.4.5.2 Conducting Testing
The Developer PM should ensure that test teams are familiar with unique mishap risks of the system. Review test plans,
procedures, and previous test results for all tests including design verification, operational evaluation, production
acceptance, and shelf-life validation to ensure that testing will be conducted with mishap risk ALARP. Mitigate all known
system hazards plus any additional hazards introduced by test procedures, instrumentation, hardware, and environments.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 29 of 1 04
A.3.4.5.3 Communication of New Hazards Identified During Testing
Testing organizations should ensure that hazards and safety discrepancies discovered during testing are documented and
communicated to the Managing Authority.
A.3.5 Element 5 - Risk Acceptance
The designated risk acceptance authority determines whether or not the mishap risks have been reduced to ALARP within
the constraints of operational effectiveness and suitability, time, and cost (or that the risk is acceptable). Figure A6 depicts
the risk acceptance element. Review and acceptance of each interim and residual single hazard risk (r) by the appropriate
authority is a necessary action in the risk management process. Consideration should also be given to requiring the review
and acceptance of total system risk (R) by the appropriate authority. The designated risk acceptance authority should be
kept informed regarding identified hazards and mishap risks.

Element 5 - Risk Acceptance

Residual Risk
Risk
1 ) Process: Residual Acceptance
Acceptance Other
Other Action(s)
Action(s)
Risk
Risk Decision
Residual risk review Decision
and acceptance. • Further reduce
How Safe is Safe Enough? • Deny approval
• Forward to higher authority
2) Acceptance Methods:
1 ) Compare to consensus standards for Risk Need
a) Protection of personnel
b) Societal risk
2) Balance risk with needs Example
Consensus
Standard
3) Product: De ci si o n
for Risk
Acceptance
Documented Risk-Based Decision Do cu m en t
Authority

T-05-00505

Figure A6 - Program element 5 - Risk acceptance

A.3.5.1 Review of Hazards and Acceptance of Mishap Risk by the Designated Authority
The Developer PM should know what interim and residual mishap risks exist in the system being delivered. The Managing
Authority provides resources to the Developer to mitigate hazards with significant mishap risk. The Developer PM is
obligated to report serious risk hazards to the Managing Authority who should then either accept the risk or take action and
allocate additional resources to reduce the risk.
A.3.5.2 Verify Review and Acceptance
The Managing Authority is responsible for formally documenting the acceptance of interim and residual mishap risks of the
system by the appropriate authority. The developer should reassess the risk of hazards whenever there are any changes
or modifications to the system or its use. The developer and Managing Authority organization should agree on the assessed
level of mishap risk prior to acceptance of the risk by the risk acceptance authority.
A.3.5.3 Accept Interim and Residual Mishap Risk
Residual risk is the mishap risk that remains after all planned mitigators have been implemented. Interim risk is that risk that
is present until planned mitigating actions have taken place. There should be documentation of the mishap risk acceptance
along with substantiation that mishap risk has been reduced as low as is reasonably practicable.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 30 of 1 04
A.4 SPECIFIC REQUIREMENTS
The Developer should ensure that all types of hazards are identified, evaluated, and mitigated to a level compliant with
acquisition management policy (federal, international, and state) laws and regulations, executive orders, treaties, and
agreements. The Developer is responsible for ensuring accomplishment of the following:
• Establishing, planning, organizing, implementing, and maintaining an effective system safety effort that is integrated
into all life cycle phases.
• Documentation of system safety planning to provide all program participants with visibility into how the system safety
effort is to be conducted.
• Establishing definitive safety requirements for the development, procurement, and sustainment of the system. The
requirements should be set forth clearly in the appropriate system specifications and contractual documents.
• Providing historical safety data.
• Monitoring the system safety activities, and reviewing and approving delivered data in a timely manner, if applicable, to
ensure adequate performance and compliance with safety requirements.
• Updating system specifications to reflect results of safety analyses, tests, and evaluations.
• Evaluating new lessons learned for inclusion into appropriate databases and submitting recommendations to the
responsible organization.
• Establishing system safety teams to assist in developing and implementing a system safety effort.
• Providing technical data to enable completion of the defined tasks.
• Documenting acceptance of hazard risk assessments.
• Providing appropriate notification or warning to users of identified system hazards and mishap risk.
• Meeting the intent of this Standard Practice.
• Making adequate resources available to support the program system safety effort.
• Verifying that the system safety technical and managerial personnel are qualified for the job.
A.5 EXAMPLE MISHAP RISK ASSESSMENT MATRICES
This section contains seven examples to show a spectrum of potential uses for the mishap risk assessment matrix. Mishap
risk assessment matrices are used to assess risks and also to determine who will accept risks. They may also serve as a
useful tool to combine the individual risks into a total system risk for the system. With this in mind, a well-designed mishap
risk assessment matrix should have the following features:
a. Mishap risk assessment matrices should be tailored 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 probability (or frequency) axes so that one axis increases upward and the other increases to the
right in accordance with the Cartesian coordinate system. Since René Descartes first developed this system in 1 637,
mathematicians, scientists and engineers have been trained to use this graphical orientation of data. It greatly reduces
confusion to orient the axes in this way.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 31 of 1 04
c. Use logarithmic scales on each axis with logical and proportional ranges for mishap severity categories and mishap
probability categories. This assures that the risk, which is a product of probability and severity, will also be proportional.
d. Assign the four levels of decision authority for risk acceptance (high, serious, medium, low) to each cell of the matrix.
Bear in mind that if the first three features described above are in place, a cell will have the same level of risk as the
cell diagonally up and to the left, and the cell diagonally down and to the right.
The following sections fully implement these features.
A.5.1 Example 1 : Mishap Risk Assessment Matrices
Programs using mishap risk assessment matrices from other standards may not contain all desirable features. Tables A2
through A5 describe typical risk matrices.
A.5.1 .1 Mishap Severity
Mishap severity categories are defined to delineate ranges of mishap outcomes in terms of fatalities, injuries, property
damage, or other loss. Example mishap severity categories are shown in Table A2. The dollar values shown in this table
should be established on a system-by-system basis based on the highest severity mishap of the system and the lowest
severity mishap that could be of concern.
Table A2 - Example - Mishap severity categories

Description Category Environmental, Safety, or Health Result Criteria

Catastrophic I Could result in death, permanent loss of system function,
permanent total disability, or loss exceeding $1 M.
Critical II Could result in major system damage, permanent partial
disability, injuries or occupational illness that may result in
hospitalization of at least three personnel, or loss
exceeding $200K but less than $1 M.
Marginal III Could result in minor system damage, injury or
occupational illness resulting in one or more lost work
days, or loss exceeding $20K but less than $200K.
Negligible IV Could result in injury or illness not resulting in a lost work
day, or loss exceeding $2K but less than $20K,

NOTE: These mishap severity categories provide guidance to a wide variety of programs. Other severity definitions may
be used.
A.5.1 .2 Mishap Probability or Frequency
Mishap probability is the likelihood of mishap occurrence over a standard or customer-defined exposure interval. Probability
is mathematically between zero and one. Mishap frequency is the rate of mishap occurrence. Frequency is sometimes
substituted for probability as a component of risk. Mishap probability categories delineate ranges of mishap probabilities
described in terms probability of one or more mishaps in a specified exposure interval or they delineate ranges of mishap
frequency described in terms of occurrences per unit of time, events, population, items, or activity. If unable to quantify
probability or frequency, mishap probability categories are defined in terms of subjective descriptors (see Table A3 and
Table A6). Assigning a quantitative mishap probability or frequency to a potential design or procedural hazard is sometimes
difficult due to lack of data. In this situation, a mishap probability or frequency may be derived from research, analysis, and
evaluation of historical safety data from similar systems. Supporting rationale for assigning a mishap probability or frequency
is documented in hazard analysis reports. Example quantitative and subjective mishap probability categories are shown in
Table A3, Table A6, and Figures A7 through A1 1 .
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 32 of 1 04
Table A3 - Example - Mishap probability categories

Description* Level Specific Individual Item Fleet or Inventory**

Very Likely A Likely to occur often in the life of an item, with a Continuously experienced.
probability of occurrence greater than 1 0 -1 in that life.
Likely B Will occur several times in the life of an item, with a Will occur frequently.
probability of occurrence less than 1 0 -1 and greater
than 1 0 -2 in that life.
Probable C Likely to occur sometime in the life of an item, with a Will occur several times.
probability of occurrence less than 1 0 -2 and greater
than 1 0 -3 in that life.
Unlikely D Unlikely but possible to occur in the life of an item, Unlikely, but can reasonably be
with a probability of occurrence less than 1 0 -3 and expected to occur.
greater than 1 0 -6 in that life.
Improbable E So unlikely, it can be assumed occurrence may not Unlikely to occur, but possible.
be experienced, with a probability of occurrence less
than 1 0 -6 in that life.
Impossible F Incapable of occurrence. This category is used when potential hazards are identified and
later eliminated.
* Definitions of descriptive words may have to be modified based on quantity of items involved.
** The expected size of the fleet or inventory should be defined prior to accomplishing an assessment of the system.
A.5.1 .3 Mishap Risk Assessment
Mishap risk classification in terms of mishap severity and mishap probability (or frequency) can be performed by using a
mishap risk assessment matrix. An example of a mishap risk assessment matrix is shown at Table A4. Using the matrix to
assess the risk for a hazard, the analyst selects the matrix cell representing the levels of combined severity and probability
of outcome for which risk is greatest. This is repeated for each individual asset threatened by the hazard (personnel,
equipment, etc.). For a hazard having a range of outcome severity covering more than one mishap severity category, the
severity-probability pair representing the greatest risk is selected as the assessed mishap risk of the hazard for that asset.
If two or more severity-probability pairs are equal as representing the greatest risk for a given asset, the declared mishap
risk is given by the pair having the greatest severity. In this example matrix, the assessed severity-probability pair is
designated by the Roman numeral and letter corresponding to the mishap severity category (from Table A2) and the mishap
probability category (from Table A3), e.g., I/D, IV/B, etc. Some matrices (Examples 3 and 5) use Arabic instead of Roman
numbers (e.g., 1 /D, 4/B, etc.). Also in this example, each cell of the matrix is assigned a number called a mishap risk index
(Table A4). Mishap risk indices can be used to rank order hazards according to their mishap risks.
Table A4 - Example - Mishap risk index values

Very Likely Probable Unlikely Improbabl Impossibl

PROBABILITY Likely B C D e e
SEVERITY A E F
I Catastrophic 1 2 4 8 12
II Critical 3 5 6 10 15
17 NA
III Marginal 7 9 11 14
IV Negligible 13 16 18 19 20

A.5.1 .4 Mishap Risk Categories

In this example, mishap risk indices are used to group individual hazards into mishap risk categories. Table A5 includes a
listing of mishap risk index, mishap risk category and mishap risk acceptance level as system management might assign
them. Mishap risk acceptance is discussed in A.3.5. The using organization should be consulted by the corresponding levels
of program management prior to mishap risk acceptance.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 33 of 1 04
Table A5 - Example - Mishap risk acceptance levels (MRALs)

Mishap Risk Index Mishap Risk Mishap Risk Acceptance Level

Category
1 -5 High Managing Authority
6-9 Serious Managing Authority
10 - 17 Medium Program Manager
1 8 - 20 Low Program Manager
A.5.2 Example 2: Mishap Risk Assessment Matrix
Figure A7 is four-by-five matrix. It features logarithmic probability (frequency) scales. The severity scale is based on mishap
class. It assigns numbers to the matrix cells in their order of decreasing risk. This allows comparisons of relative cell-by-cell
risks.

Severity
Hazard Categorization
Catastrophic (1 ) Critical (2) Marginal (3) Negligible (4)
Frequent (A) 1 3 7 13
= or > 1 00/1 00k Hrs
Probable (B) 2 5 9 16
1 0-99/1 00k Hrs
Frequency

Occasional (C) 4 6 11 18
1 .0-9.9/1 00k Hrs
Remote (D) 8 10 14 19
0.1 -0.99/1 00k Hrs
Improbable (E) 12 15 17 20
= or < 0.1 /1 00k Hrs

Managing Authority Program Manager or Designee

Unacceptable Acceptance Acceptable Acceptance
1 -5 HIGH SAFETY RISK With Review 1 1 -1 7 LOW SAFETY RISK

Managing Authority Program Manager or Designee

Undesirable Acceptance Acceptable Acceptance
6-1 0 MEDIUM SAFETY RISK Without Review 1 8-20 VERY LOW SAFETY RISK

Severity
Catastrophic -> $1 M / fatality / permanent total disability)
Critical -($200K < damage < $1 M / permanent partial disability / hospitalization of 5 or more personnel)
Marginal -($1 0K < damage < $200K / injury results in 1 or more lost workdays)
Negligible - All other injury/damage
Probability of occurrence for discreet events may replace Frequency based upon the chart below.
Frequent Probable Occasional Remote Improbable
1 /1 0 3 1 /1 0 4 1 /1 0 5 1 /1 0 6 1 /1 0 7

Figure A7 - Mishap risk assessment matrix

SAE INTERNATIONAL GEIA-STD-001 0™ A Page 34 of 1 04
A.5.3 Example 3: Generic Subjective Mishap Risk Assessment Matrix
Figure A8 is intended to illustrate the major components and methods of a tailored risk assessment matrix.

Lowest Highest
Probability
Mishap Probability Probability

F E D C B A
Impossible Improbable Unlikely Probable Likely Very Likely

Highest Catastrophic
Severity I High

Critical
Serious
II
Mishap
Severity
Marginal

III Medium

Lowest Negligible
Severity IV
Low

Hazard Risk Assessment Code Risk Level

IA, IB, IIA High
IC, ID, IIB, IIC, IIIA, I IIB, IVA Serious
IE, IID, IIE, IIIC, IIID, IVB, IVC Medium
IIIE, IVD, IVE Low
IF, IIF, IIIF, IVF NA
T- 05-0051 1

Figure A8 - Generic subjective mishap risk assessment matrix

A.5.3.1 Tailoring Process
As part of tailoring, the highest and lowest severity should be specified to establish the severity range. The range in Figure
A8 has been divided into subdivisions. Similarly, the probability scale has been subdivided into equal parts. This four-by-six
matrix serves the purpose of bounding, guiding, and displaying. The table below the matrix defines the low, medium, serious,
and high risk areas and lists the appropriate decision authorities for each level of mishap risk.
A.5.3.2 Matrix Axis Scaling
Matrix axis scaling may be either subjective, using key phrases to guide judgment as to levels of severity and probability,
or quantitative, using numbers.
A.5.3.2.1 Subjective Scaling
Severity and probability axes of the mishap risk assessment matrix can be scaled to guide subjective assessments of risk.
For example, Figure A8 could be used for subjective scaling where levels of mishap severity are ranked from negligible (IV)
to catastrophic (I). The mishap probability scale has been similarly treated, with probability categories ranging from
impossible (F) to very likely (A). The terms associated with the mishap probability scale represent likelihood rather than the
importantly different concept of frequency. Phrases to guide the selection of the subjective terms for probability appear in
Table A6.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 35 of 1 04
Table A6 - Example - Mishap probability categories

Level Descriptive Word* Defining Phase *

A Expected Approaching certainty
B Near Expectation Moderately certain
C Highly Probable A near expectation
D Very Likely Quite probable
E Likely Somewhat certain
F Probable Neither surprising nor assured
G Unlikely Conceivable, but not expected
H Improbable Approaching incredibility
I Impossible Incapable of occurring
* Probability statements, although dimensionless, should relate to an
expressed interval of item or system exposure, e.g.: a specified number
of hours of operation, cycles of use, miles driven, man-hours worked,
missions completed.
A.5.3.2.2 Quantitative Scaling
Subjective expressions for severity and probability (“Frequent,” “Occasional,” “Critical,” etc.) are of limited precision. Varying
interpretations of the terms can lead to substantial dispute over assessments of severity and probability. Therefore, when
assessing risk, use numerical expressions of severity and probability along with similarly quantitative scaling of the risk
matrix axes if possible. Logarithmic scaling of quantitatively distributed values along the axes of the risk assessment matrix
is to be preferred. This means major scale indices increase stepwise not by single integers (e.g., 1 , 2, 3, …) but by factors
of ten, called orders of magnitude (e.g., … 1 0 -7 , 1 0 -6, 1 0 -5, 1 0 -4… or…1 , 1 0, 1 00…or …2, 20, 200…). The scale steps could
also increase by two orders of magnitude (… 1 0 -8, 1 0 -6, 1 0 -4, 1 0 -2 , 1 , 1 00, 1 0,000…) or half orders of magnitude (1 0 -7, 1 0 -6.5,
1 0 -6, 1 0 -5.5… 1 , 3.1 6, 1 0, 31 .6, 1 00, 31 6…). Adjusting the scales in this way adjusts the resolution capability of the matrix.
Resolution is determined by the size of the smallest calibrated increment in mishap severity and probability (or frequency)
categories. Examples 3, 4, and 5 are at one order of magnitude resolution. Example 6 is at one-half order of magnitude
resolution. Matrix scale resolution should not be made finer than is justified by the quality of the data to be displayed nor
less than is needed to express data values serving a practical use.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 36 of 1 04
A.5.4 Example 4: Multi-Purpose Aircraft Mishap Risk Assessment Matrix
Figure A9 is nine-by-seven matrix intended for multiple aircraft systems. It features logarithmic scales and can be varied in
size based on the maximum severity mishap of the system. The mishap severity categories are numbered in reverse of the
other examples to enable uniform reporting of risk regardless of how large or small the matrix is tailored.

Figure A9 - Example multi-purpose aircraft family mishap risk assessment matrix

A.5.5 Example 5: Single Order of Magnitude Resolution Mishap Risk Assessment Matrix
Figure A1 0 is an eight-by-six matrix proposed for use with low probability and high consequence hazards. It features
logarithmic scales and four levels of decision authority. This matrix is designed for use where risk for most hazards has
been assessed subjectively, yet the scaling of each axis remains useful for summing total system risk.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 37 of 1 04

Many Deaths
Many Very Severe Injuries

Multiple Deaths
Many Severe Injuries
Less than $20M Loss
M i s h ap S e ve ri ty

Death (1 )
Less than $2M Loss

Severe Injury
Less than $200K Loss

Minor Injury
Less than $20K Loss

Less than $2K Loss

0 1 0 -7 1 0 -6 1 0 -5 1 0 -4 1 0 -3 1 0 -2 1 0 -1 1 00

Extremely Extremely
Near Zero Remote Unlikely Remote Unlikely Occasional Probable Very Likely

M i s h ap P rob ab i l i ty

Figure A10 - Example single order of magnitude resolution

mishap risk assessment matrix
A.5.6 Example 6: Half Order of Magnitude Mishap Resolution (1 4 x 1 4) Risk Assessment Matrix
Figure A1 1 is a half order of magnitude mishap risk assessment matrix that may be desirable where quantitative risk
assessment (QRA) or other quantified methods are used in quantifying risk. It features a resolution of half orders of
magnitude in both dimensions. The consequence scale is quantified in terms of fatalities, serious injuries, and dollars lost.
QRA methods may also be used with matrices having scales with full order or magnitude scale markings.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 38 of 1 04
Expected Severity
Serious Minor 14
Fatalities $Loss 1 2 3 4 5 6 7 8 9 10 11 12 13
injuries Injuries
>1 000 n

U n ou t C N eed
wi
>300 m

th
ac om
ce p
p ta e l
>1 00 l

bl e l i n g
k

Hig
>30

hR
j

isk
>1 0

-C
Se

AE
rio
>3 i

Ap
sR

p rov
i sk
>1 >1 0 h

al
-P
Me

EO
g

diu

Ap
>3

prov
Ri s
f

al
k–
>1 >1 0

PM
e

Ap
>3

Lo

pro
w

va
d

Ri s
>1 > 1 00K

l
k
c
De N o A u i re
> 30K M i c ti d
n i m on
b
Re

> 1 0K
is;
q

> 3K a
>3E

>3E

>3E

>1 E

>3E

>1 E

>1 E

>3E

>1 /1 0

>3/1 0
>1 E

>1 E

>3E

1
-7

-6

-5

-4

-4

-3

-2

-2
-6

-5

-3
T-05-00509
Probability of Occurrence Per ___ Uses (Estimate of Total Annual Exposure)

Figure A11 - Example half order of magnitude resolution

mishap risk assessment matrix
A.5.7 Example 7: Total System Risk Assessment Criteria
Where total system risks are calculated, the traditional method of plotting risks on a mishap risk assessment matrix may
prove unsatisfactory. Another method in common use is to establish criteria plotted as “iso-risk” lines using the same severity
and probability scales that define matrices. Published criteria defining “how safe is safe enough?” may be used to define
these lines; however, this may differ for each system type. This approach may be used for comparison of single hazard
risks, or total system risk. Figure A1 2 is an example of potential total system risk assessment criteria.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 39 of 1 04
1 0000

U n wi e l l i n
a c th o g N
Co

ce u t e e
mp

p ta
Hig
1 000

bl e
hR
Mishap Severity (Fatalities)

i sk
Se
ri o

-C

d
u

AE
sR
Me
1 00

diu

Ap
i sk

pro
m

-P
Ri s

va
EO

l
k–

Ap
PM

pro
10

va
Ap

l
Lo

pro
w
Ac t i

va
Ri s
on t

l
o re

k
1

duc
N o A De m i n e ri s
k ab
c ti o i m i s ove
n Re ; th i s
0. 1
quir th re
ed sho
ld
0. 01

1 . 0E+00
1 . 0E-07

1 . 0E-06

1 . 0E-05

1 . 0E-03
1 . 0E-04

1 . 0E-02
1 . 0E-09

1 . 0E-08

1 . 0E-01
Frequency (Annual) T-05-0051 0

Figure A12 - Example total system risk assessment criteria

A.5.7.1 Total Risk Criteria
The example was developed using risk acceptance criteria that have been previously published, and the numerical values
shown could be varied to fit the class of system. This approach may be tailored for use with single hazard risks (r) or total
system risk (R). The chart plots iso-risk lines on the diagonal. For example, the line extending from 1 0000 on the severity
axis to 1 x1 0 -3 on the probability axis represents an iso-risk expectancy of one fatality per year for the total system. The chart
could be useful in advising decision makers when the total system risk is above a certain iso-risk threshold.
A.5.7.2 Decision Making Areas
The system risk assessment criteria are also divided into six decision-making areas associated with the appropriate level
of acceptance authority.
a. De minimis. This approach uses a straight line to define the de minimis threshold for the system safety program. Below
this level, a hazard does not warrant any additional expenditure of mitigation resources.
b. Low risks. These risks are high enough to expend resources to reduce. Residual mishap risk should be accepted.
c. Medium risks. These risks are high enough to warrant some concern. Residual mishap risk acceptance is necessary.
d. Serious risks. These risks require risk acceptance at a senior management level.
e. High risks. These risks require risk acceptance at the highest management or Customer level.
f. Unacceptable risks. These risks are unacceptable without a compelling need.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 40 of 1 04
A.5.8 Example Measures of Total System Risk
To evaluate a system against the criteria in A.5.7.1 , a measure of system risk (R) is needed. The format of Figure A1 2
dictates that this measure should provide both a measure of severity and a measure of probability of occurrence to plot the
system risk. These measures assume summed hazards are totally independent. Valid measures of total system risk might
be, for example:
a. Expected loss rate. This measure computes the severity component as the average loss per system exposure interval
that would be realized if numerous copies of the system were operated for numerous life cycles. The probability to be
plotted is a value of 1 .0 since this method estimates the level of loss that, on average, will happen every time the system
is operated for the specified exposure interval.
b. Maximum loss. This measure assigns the severity component to be plotted as the level of loss corresponding to the
most severe single hazard. The probability of maximum loss is computed by dividing the expected loss rate by the
maximum loss level.
c. Most probable loss. To plot this measure, sum the probabilities of hazards at each level of severity. The severity level
with the highest probability is the most probable loss. Plot this severity level with a probability computed by dividing the
expected loss rate by the most probable loss level.
d. Conditional loss rate. The probability value is the sum of the probabilities for all hazards. The severity value is the
conditional expected loss and is computed by dividing the expected loss rate by the value of the summed probabilities.
The result displays the probability that a mishap will occur, and the expected amount of the loss, given that a mishap
does occur.
A.6 SOFTWARE SYSTEM SAFETY ENGINEERING ANALYSIS AND INTEGRITY
A successful software safety engineering activity is based upon both a hazard analysis process and a software integrity
process. Emphasis is placed on the context of the “system” and how software contributes to failures, hazards, and/or
mishaps. From the perspective of the system safety engineer and the hazard analysis process, software is considered as
a subsystem. In most instances, the system safety engineers should perform the hazard analysis process while the software
development, software test, and independent verification and validation (IV&V) team(s) implement the software integrity
process. The hazard analysis process is an activity that identifies and mitigates the exact software contributors to hazards.
The software integrity process increases the confidence the software will perform as specified (i.e., to software performance
requirements) while reducing the number of contributors to hazards that may possibly exist in the system. Both processes
are essential to reduce the likelihood of software initiating a propagation pathway to a hazardous condition or mishap.
A.6.1 Software System Safety Engineering Analysis
System safety engineers performing the hazard analysis for the system (PHA, SSHA, SHA, FHA, O&SHA, and HHA) should
accomplish the software safety engineering analysis tasks. These tasks ensure that software is considered in its contribution
to mishap occurrence. These tasks are well defined and common to most system safety programs. In general, software
functionality that directly or indirectly contributes to mishaps, such as the processing of safety critical data or the transitioning
of the system to a state which could directly lead to a mishap, should be thoroughly analyzed. Software sources and/or
specific software errors that cause or contribute to hazards should be identified at the software module and functional level
(functioning out-of-time or out-of-sequence, malfunctions, degrades in function, or does not respond appropriately to system
stimuli). In software-intensive, safety-critical systems, mishap occurrence will likely be caused by a combination of hardware,
software, and human errors. These complex initiation pathways should be analyzed for the purpose of identifying hazard
mitigation requirements and constraints to the hardware and software design and test teams. As a part of the functional
hazard analysis (FHA, Task 208) software functionality which has been identified to cause, contribute to, or influence a
hazard that could result in a major mishap should be identified as safety critical. Software requirements that implement
safety critical functions should also be identified as safety critical.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 41 of 1 04
A.6.2 Software Safety Integrity
Software developers and testers play a large role in producing safe software. Their contribution can be greatly enhanced
by the incorporation of a software safety integrity process within the software development plan (SDP) and task activities.
The software safety integrity process is based upon the identification and establishment of specific software development
and test tasks for each acquisition phase of the software development life cycle (requirements, preliminary design, detailed
design, code, unit test, unit integration test, system integration test, and formal qualification testing). All software safety
integrity tasks should be performed at an appropriate level of rigor based upon the safety criticality of the software functions
within each software configuration item or software module of code. The software safety integrity tasks are defined by
performing an FHA to identify safety critical functions (SCF); assigning a software control category (SCC) to each of the
software-related safety critical functions; assigning a software criticality index (SCI), software assurance level (SwAL) or
software integrity level (SIL); and the implementation of tasks for each SCF based upon the (SCI). These software safety
integrity tasks are further explained in the subsequent paragraphs.
A.6.2.1 Perform a Functional Hazard Analysis
Identify the SCF of the system (see Task 208). Once identified, each SCF is assessed and categorized against the software
control categories to determine the level of control of the software over safety-related functionality. Each SCF is mapped to
its implementing computer software configuration item (CSCI) or module of code for traceability purposes.
A.6.2.2 Perform a Software Criticality Assessment for Each SCF
The software criticality assessment should not be confused with mishap risk. “Mishap risk” is a measure of the severity and
probability of occurrence of a mishap from a particular hazard whereas software criticality is used to determine how “critical”
a specified software function is with respect to the safety of the system. The software criticality assessment combines the
mishap severity category from the mishap risk assessment with the SCC to derive an SCI as shown in the example software
criticality matrix in Table A7. The SCI is then used as a part of the software integrity assurance process to determine the
amount of analysis and testing required for verification of that specific software requirement/function. The SCCs are defined
in the bottom section of Table A7.
Table A7 - Example - Software criticality matrix

S oftware C on trol C ate g ory S W C ri ti ca l i ty

S u g g e s ted C ri teri a

IV IIIb IIIa IIa/IIb I

I n d ex

Requires requirements analysis, in-

Catastrophic

(1 ) High depth design and code analyses,

(5 ) (3 ) (2 ) (1 ) (1 )
and in-depth safety specific testing.
I

NSC M ed i u m S eri ou s High High

Requires requirements analysis,

M i s h ap S everi ty C ate g ory

(2 ) S eri ou s some design and code analyses,

and in-depth safety specific testing.
Critical

(5 ) (3 ) (3 ) (2 ) (1 )

Requires requirements analysis,

II

NSC M ed i u m High

some design and code analyses,

M ed i u m S eri ou s

(3 ) M ed i u m

and safety specific testing.

Requires safety-critical requirements
Marginal

be identified and tracked, developer

(5 ) (4) (4) (3 ) (3 )
III

follows normal development

NSC Low Low M ed i u m Mediu m
(4) Low

processes, and some safety specific

testing.
Negligible

(5 ) (4) (4) (4) (4)

No safety specific analyses or

IV

(5) N ot S afe ty

NSC Low Low Low Low

C ri ti cal

(N S C )
testing required.
T-05-0051 5

S oftware Con trol C ateg ori es

I Software exercises autonomous control over potentially hazardous hardware systems, subsystems or components without the possibility of
intervention to preclude the occurrence of a hazard. Failure of the software or a failure to prevent an event leads directly to a hazard's
occurrence.
IIa Software exercises control over potentially hazardous hardware systems, subsystems, or components allowing time for intervention by
independent safety systems to mitigate the hazard. However, these systems by themselves are not considered adequate.
IIb Software item displays information requiring immediate operator action to mitigate a hazard. Software failures will allow or fail to prevent
the hazard's occurrence.
IIIa Software item issues commands over potentially hazardous hardware systems, subsystems or components requiring human action to
complete the control function. There are several, redundant, independent safety measures for each hazardous event.
IIIb Software generates information of a safety critical nature used to make safety critical decisions. There are several, redundant, independent
safety measures for each hazardous event.
IV Software does not control safety critical hardware systems, subsystems or components and does not provide safety critical information.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 42 of 1 04
A.6.2.2.1 Software Criticality Matrix Tailoring
The software criticality matrix can, and will, be tailored for any given program. An SCI of “1 ” from the matrix implies that the
assessed software function or requirement is very critical to the safety of the system and requires more design and test
rigor than software which is less critical. Software with an SCI of “2” to “4” is less critical and requires less design and test
rigor than high-criticality software. Unlike the hardware related mishap risk index, a low index number does not imply that a
design is unacceptable. Rather, it indicates that greater resources need to be applied to the analysis and testing of the
software and its interaction with the system.
NOTE: The software criticality index matrix does not consider the likelihood of a software-caused mishap occurring in its
initial assessment. However, through the successful implementation of a software safety integrity process, the
likelihood of software contributing to a mishap can be greatly reduced.
A.6.2.3 Software Integrity Assurance Matrix (SIAM)
Once SCFs are identified and assessed against the SCC and assigned an SCI (all accomplished thus far by the system
safety engineer but agreed upon by the software developers and testers), the implementing software should be designed,
coded, and tested against software safety integrity criteria as shown in the SIAM. These criteria should be defined,
negotiated, and documented in the SDP and the software test plan (STP) early in the development life cycle.
A.6.2.3.1 SCI Assignment
An SCI (1 High, 2 Serious, 3 Medium, or 4 Low) should be assigned to each safety critical software function and the
associated safety critical software requirements. Assigning the SCI value of 5-NSC (not safety critical) to non-safety critical
software requirements provides a record that functionality has been assessed and deemed NSC. Individual safety critical
software requirements that track to the software hazard reports should be assigned an SCI. The intent of the SCI value of
4 (“Low”) is to ensure that requirements corresponding to this level are identified and tracked through the system. These
“low” safety critical requirements only need the normal reviews, analyses, and testing specified by the Developer’s standard
software development processes.
A.6.2.3.2 Example SIAM
Table A8 depicts an example of what can be placed in the SIAM. It should be noted that an SIAM will be tailored for each
individual system or system of systems based upon its complexity, safety criticality, available resources, and value added.
To assist in filling out the matrix the following example design requirements and tasks are provided for consideration in
A.6.2.4 below, and its subparagraphs.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 43 of 1 04
Table A8 - Example - Software integrity assurance matrix

Criticality Rating
****FOR EXAMPLE PURPOSES ONLY**** (1 ) (2) (3) (4)
Software Integrity Assurance Task
High Serious Medium Low
General
Peer Reviews of all development artifacts are conducted at each phase M M R R
(requirements, design, code, and test).
All design and software components containing safety critical functionality are M M R R
identified as safety critical and linked to the appropriate software requirements
specification (SRS) requirement(s).
All safety critical functions and components are documented and linked to the M M M R
individual hazards identified in the hazard analysis.
Requirements Analysis Phase
Independent analysis/verification of algorithms, limits, ranges, critical values, rate, M R R NR
units, frequency and volume via independent evaluation.
Traceability of safety critical requirements from hazard analyses to SRS, software M M M R
design, code, and test.
All safety critical software requirements are broken down to their lowest level and M M R R
linked to their higher level requirement.
All safety critical software requirements are analyzed for verifiability, testability M M R R
and potential confliction with other requirements.
All safety critical requirements are evaluated for timing, resource utilization, and M M M R
throughput.
Use of defined Safety related Requirements Guidelines. M M R NR
Architectural and Detailed Design Phase
Evaluate safety related components for reliability, maintainability, M M M R
understandability, and performance.
Peer reviews of software units identified as safety critical will require the M M M R
attendance of a reviewer independent from the Software Development Team.
For all safety critical requirements ensure that there are no common cause M M R R
failures between components (i.e., Fault Tree Analysis).
For all safety critical components, identify any or all dependencies. M M R R
Verify accuracy and correctness of all algorithms in safety critical components. M M M M
Verify that all data used in safety critical components are used as specified and M M M R
are consistently used between components.
Verify all interfaces between safety critical components. M M M R
Evaluate feasibility of safety critical design constraints. M M R R
Evaluate partitioning of safety critical software (goal is to minimize the number of M M M R
safety critical components).
Coding Phase
Conduct a safety critical function code review (with safety engineering M M R R
attendance).
Conduct an independent verification of: safety critical algorithms for accuracy, M M M R
correctness, and boundary values; data consistency between components; and
use of defined safety critical guidelines.
Software coding standards will require that software units that satisfy safety M M M M
critical requirements be identified as safety critical.
Safety critical software units should be evaluated for logic, data, and interface M M M M
errors.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 44 of 1 04
Criticality Rating
****FOR EXAMPLE PURPOSES ONLY**** (1 ) (2) (3) (4)
Software Integrity Assurance Task
High Serious Medium Low
Algorithms and mathematical computations should be analyzed and tested for M M M M
accuracy and correctness.
Testing Phase
Create a set of unit, unit integration, and software qualification test cases for M M M R
testing all the logic paths and all statements in the software. Complete coverage
testing.
At a minimum, unit test cases should exercise each line of executable source M M M M
code at least once and ensure there is no unused or dead code in the software.
For safety critical requirements that are time dependent, timing tests should be M M M M
included at the unit level.
For safety critical requirements, boundary value testing should be performed to M M M R
validate values at or near the limits of the valid range of their values.
White box testing to verify that every code loop is executed the correct number of M M R R
times and for every possible condition inside the loop.
Verify testing to ensure that safety critical data items are protected from being M M M M
overwritten by unauthorized operations.
Independent verification that all modules identified as safety critical are tested at M M M M
the required level at least once.
Error case testing should be performed to test the handling of unexpected values. M M M R
This should include analysis of all plausible errors that will be considered for the
test.
Perform stress testing to verify limits of safety critical modules. M M R R
Verification of the ability of the software to handle large and out-of-range values. M M R R
Perform black box tests written specifically for safety critical functions. M M R R
Test to ensure that every safety critical thread through the code is followed and M M R R
leads to a desired outcome.
Perform stress testing where inputs are varied to exceed the limits specified in the M M R R
SRS and to force system anomaly conditions (e.g., division by zero). The goal is
to discover where the software design and timing limits break down.
Test all modules and functions at least once. M M M M
For each new build, perform regression testing to verify subsequent builds do not M M R R
impact the previously tested safety critical functionality. Also perform safety
regression testing for software modifications or revisions within a build. Create a
minimum set of unit, unit integration, and software qualification regression test
cases for testing all safety critical software functionality.
Notes:
M - Mandatory task
R - Recommended task
NR - Not Required task, however, normal CMMI-based processes apply
“Independence” implies independence from the Software Development Team.
This is an EXAMPLE of what can be included in an SIAM but it must be reiterated that the contents of this matrix are
negotiated with the software development and test teams and approved by the PM. Further guidance of what can be
included in the matrix is provided below in A.6.2.4.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 45 of 1 04
A.6.2.4 Software Safety Integrity Requirements and Tasks
Some suggested software safety integrity tasks that can be applied to a program are listed in the following paragraphs for
consideration and applicability.
A.6.2.4.1 Design Requirements
The following design requirements should be considered: fault tolerant design, fault detection, fault isolation, fault
annunciation, fault recovery, warnings, cautions, advisories, redundancy, independence, N-version design, functional
partitioning (modules), physical partitioning (processors), design safety guidelines, design safety standards, best and
common practices.
A.6.2.4.2 Process Tasks
Consider the following process tasks: design review, safety review, design walkthrough, code walkthrough, independent
design review, independent code review, independent safety review, traceability of SCFs, SCF code review, SCF design
review, test case review, test procedure review, safety test result review, independent test results review, safety quality
audit inspection, software quality assurance (SQA) audit, safety sign-off of reviews and documents.
A.6.2.4.3 Test Tasks
The following are test task considerations: SCF testing, functional thread testing, limited regression testing, 1 00% regression
testing, failure modes and effects testing, safety critical interface testing, commercial off-the-shelf (COTS) and government
off-the-shelf (GOTS) input/output testing and verification, independent testing of prioritized SCFs, functional qualification
testing, IV&V.
A.6.3 Software Safety Risk Assessment
After completion of all the specified software safety engineering and integrity tasks (including system qualification tests),
results should be used as evidence (or input) to the residual safety risk associated with single hazard risk (r) and total
system risk (R). Software safety engineering with the software development team (and possibly the independent verification
team) should evaluate the results of all the safety verification activities and perform a qualitative assessment of confidence
for each safety critical requirement. This information should be integrated into the safety assessment report or safety case.
A.7 CONTRACT TERMS AND CONDITIONS
Some acquisitions include the following conditions in their solicitation, system specification, or contract as requirements for
the system design. These condition statements are used optionally as supplemental requirements based on specific
program needs, and are worded below as they would appear if used in this manner.
A.7.1 Unacceptable Conditions
The following safety critical conditions are considered unacceptable for development efforts. Positive action and verified
implementation is required to reduce the mishap risk associated with these situations to a level acceptable.
• Single component or multi-component single-point failure, common mode failure, human error, or a design feature that
could result in a mishap of critical or catastrophic severity.
• Dual independent component failures, dual independent human errors, or a combination of a component failure and a
human error involving safety critical command and control functions, which could result in a mishap of catastrophic
severity.
• Generation of hazardous radiation or energy, when no provisions have been made to protect personnel or sensitive
subsystems from damage or adverse effects.
• Packaging or handling procedures and characteristics that could cause a mishap for which no mitigators have been
provided to protect personnel or sensitive equipment.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 46 of 1 04
• Hazard categories that are specified as unacceptable in the development agreement.
• Component design or location that fails to address human physical, anthropometrics, physiological and/or perceptual-
cognitive capabilities or limitations.
A.7.2 Acceptable Conditions
The following approaches are considered acceptable for correcting unacceptable conditions and would require no further
analysis once mitigating actions are implemented and verified to an acceptance condition.
• For non-safety critical command and control functions: a system design that requires two or more independent human
errors, or that requires two or more independent failures, or a combination of independent failure and human error.
• For safety critical command and control functions: a system design that requires at least three independent failures, or
three independent human errors, or a combination of three independent failures and human errors.
• System designs that positively prevent errors in assembly, installation, or connections that could result in a mishap.
• System designs that positively prevent damage propagation from one component to another or prevent sufficient energy
propagation to cause a mishap.
• System design limitations on operation, interaction, or sequencing that preclude occurrence of a mishap.
• System designs that provide an approved safety factor, or a fixed design allowance that limits, to an acceptable level,
possibilities of structural failure or release of energy sufficient to cause a mishap.
• System designs that control energy build-up that could potentially cause a mishap (e.g., fuses, relief valves, or electrical
explosion proofing).
• System designs where component failure can be temporarily tolerated because of residual strength or alternate
operating paths, so that operations can continue with a reduced but acceptable safety margin. (When feasible, consider
providing a warning indicator when a primary control system fails or the alternative control system is engaged).
• System designs that positively alert the controlling personnel to a hazardous situation where the capability for operator
reaction can been provided.
• System designs that limit or control the use of hazardous materials.
A.8 EXAMPLE - SAFETY DESIGN REQUIREMENTS
The chief engineer, and utilizing systems engineering and associated system safety professionals, should establish specific
safety design requirements for the overall system. The objective of safety design requirements is, through the application
of design guidance, to establish a baseline of mishap risk from which risk can be further reduced to ALARP using an effective
system safety program. Design guidance includes standards, specifications, regulations, design handbooks, safety design
checklists, and other sources. Review these for safety design parameters and acceptance criteria applicable to the system.
Safety design requirements derived from the selected parameters, as well as any associated acceptance criteria, are
included in the system specification. Expand these requirements and criteria for inclusion in the associated follow-on or
lower level specifications. See general safety system design requirements below.
A.8.1 Hazardous Material
Hazardous material use is minimized, eliminated, or associated mishap risks are reduced through design, including material
selection or substitution. When using potentially hazardous materials, select those materials that pose the least risk
throughout the life cycle of the system.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 47 of 1 04
A.8.2 Hazardous Material Isolation
Hazardous substances, components, and operations are isolated from other activities, areas, personnel, and incompatible
materials.
A.8.3 Equipment Location
Equipment is located so that access during operations, servicing, repair, or adjustment minimizes personnel exposure to
hazards (e.g., hazardous substances, high voltage, electromagnetic radiation, and cutting and puncturing surfaces).
A.8.4 Safety Protection
Protect power sources, controls, and critical components of redundant subsystems by physical separation or shielding, or
by other acceptable methods.
A.8.5 Safety Devices
Consider safety devices that would minimize mishap risk (e.g., interlocks, redundancy, fail safe design, system protection,
fire suppression, and protective measures such as clothing, equipment, devices, and procedures) for hazards that cannot
be eliminated. Make provisions for periodic functional checks of safety devices when applicable.
A.8.6 System Final Disposition
System final disposition is considered in the design. A system final disposition plan should be developed and implemented
that addresses all areas of disposition (disposal, recycling, etc.).
A.8.7 Warning Signals
Implement warning signals to minimize the probability of incorrect personnel reaction to those signals, and standardize
within like types of systems.
A.8.8 Warning and Cautionary Notes
Provide warning and cautionary notes in assembly, operation, and maintenance instructions; and provide distinctive
markings on hazardous components, equipment, and facilities to ensure personnel and equipment protection when no
alternate design approach can eliminate a hazard. Use standard warning and cautionary notations where multiple
applications occur. Standardize notations in accordance with commonly accepted commercial practice or, if none exists,
normal military procedures. Do not use warning, caution, or other written advisory as the only risk reduction method for
hazards that could result in a major mishap.
A.8.9 Personnel Proficiency
Safety critical tasks may require personnel proficiency; if so, the Developer should propose a proficiency certification
process to be used.
A.8.1 0 Mishap Minimization
Severity of injury or damage to equipment or the environment as a result of a mishap is minimized.
A.8.1 1 Safety Requirements
Inadequate or overly restrictive requirements regarding safety are not included in the system specification.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 48 of 1 04
A.8.1 2 Acceptable Risk
Acceptable risk is mishap risk that is ALARP within the constraints of operational effectiveness, time, and cost as determined
by the appropriate authority. This level of mishap risk is achieved and maintained by implementing new technology,
materials, or designs in a system’s production, test, and operation. Changes to design, configuration, production, or mission
requirements (including any resulting system modifications and upgrades, retrofits, insertions of new technologies or
materials, or use of new production or test techniques) are accomplished in a manner that keep the level of mishap risk as
low as reasonably practicable. Changes to the environment in which the system operates are analyzed to identify and
mitigate the mishap risk of any new hazards or changes in the risk of known hazards.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 49 of 1 04
APPENDIX B - SYSTEM SAFETY TASKS
B.1 GENERAL
This appendix provides the tasks that can be selectively applied to fit a tailored System Safety Program. The sequence of
task and subtask accomplishment should be tailored to the individual program to which they are being applied. The 1 00-
series Tasks apply to safety program management and control. The 200-series Tasks apply to safety design and integration.
The 300-series Tasks apply to safety design evaluation. The 400-series Tasks apply to safety compliance and verification.
B.2 TASK STRUCTURE
Each individual task is divided into three parts: purpose, task description, and details to be specified.
a. The “PURPOSE” provides a brief reason for performing the task.
b. The “TASK DESCRIPTION” provides the actual subtasks that comprise the task that a contractor must perform if
specified by the Managing Authority. Task descriptions should be tailored by the Managing Authority as required by
governing regulations and as appropriate to particular systems or equipment, program type, magnitude, and funding. In
tailoring the tasks, the detail and depth of the effort is defined by the Managing Authority and incorporated in the
appropriate contractual documents. When preparing proposals, the Developer may include additional tasks or task
modifications with supporting rationale for each addition or modification.
c. The “DETAILS TO BE SPECIFIED” paragraph under each task description lists specific details, additions, modifications,
deletions, or options to the requirements of the task that should be considered by the Managing Authority when tailoring
the task description to fit program needs. This information is then included in the document in which the task is invoked.
The list provided with each task is not necessarily complete and may be supplemented by the Managing Authority.
"Details to be Specified" annotated by an "(R)" would be required and should be provided to the Developer by the
Managing Authority for proper implementation of the task, if the task is to be contractually implemented.
Task 1 01 - System Safety Program
1 01 .1 Purpose

The purpose of Task 1 01 is to establish the foundation for a system safety program. The total system safety program
consists of this task plus any other tasks from Sections 1 00, 200, 300, 400, or other source designated by the Managing
Authority.
1 01 .2 Task Description

1 01 .2.1 Establish a System Safety Program

Establish and execute a system safety program which meets the tailored requirements of Section 4, General Requirements,
and all other tasks/requirements designated by the Managing Authority.
1 01 .2.2 Develop a Planned Approach

Develop a planned approach for safety task accomplishment, provide qualified people to accomplish the tasks, establish
the authority for implementing the safety tasks through all levels of management, and allocate appropriate resources, both
manning and funding, to assure the safety tasks are completed.
1 01 .2.3 Establish a System Safety Organization

Establish a system safety organization or function and lines of communication within the program organization and with
associated organizations (Managing Authority and Developer). Establish interfaces between system safety and other
functional elements of the program, as well as between other safety disciplines such as nuclear, range, explosive, chemical,
biological, etc. Designate the organizational unit responsible for executing each safety task. Establish the authority for
resolution of identified hazards.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 50 of 1 04
1 01 .2.4 Define System Safety Program Milestones
Define system safety program milestones and relate these to major program milestones, program element responsibility,
and required inputs and outputs.
1 01 .2.5 Establish a Reporting Process

Establish an incident alerting/notification, investigation and reporting process, to include notification of the Managing
Authority.
1 01 .3 Details to be Specified
Details to be specified in the SOW should include the following, as applicable:
(R) a. Imposition of Task 1 01 .
(R) b. Tailoring of Section 4 to meet specific program requirements.
(R) c. Acceptable level of risk with reporting thresholds.
(R) d. Minimum mishap probability and severity reporting thresholds.
e. MA requirements for incident processing.
f. Requirement for and methodology of reporting to the Managing Authority the following:
(1 ) Mishap hazards/risks.
(2) Safety critical functions and safety features to mitigate risk.
(3) Operating, maintenance and overhaul safety requirements.
(4) Measures used to abate hazards.
(5) Acquisition management of hazardous materials.
g. Qualifications for key system safety personnel.
h. Other specific system safety program requirements.
Task 1 02 - System Safety Program Plan

1 02.1 Purpose

The purpose of Task 1 02 is to develop a System Safety Program Plan (SSPP). It must describe, in detail, the tasks and
activities of system safety management and system safety engineering that are required to identify, evaluate, and eliminate
or control hazards, or reduce the associated risk to as low as reasonably practicable as determined by the Managing
Authority throughout the system life-cycle. The approved plan provides a formal basis of understanding between the
contractor and Managing Authority on how the system safety program should be executed to meet contractual requirements,
including general and specific provisions.
1 02.2 Task Description
The Developer should develop an SSPP to provide a basis of understanding between the Developer and the Managing
Authority as to how the system safety program would be accomplished to meet contractual safety requirements included in
the general and special provisions of the contract. The approved plan must, on an item-by-item basis, account for all
contractually required tasks and responsibilities. The format and content requirements are defined in Appendix C, TDD-1 02.
The SSPP should include the following:
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 51 of 1 04
1 02.2.1 Program Scope and Objectives
Each SSPP should describe, as a minimum, the four elements of an effective system safety program:
1 ) a planned approach for task accomplishment,
2) qualified people to accomplish tasks,
3) authority to implement tasks through all levels of management, and
4) appropriate commitment of resources (both manning and funding) to assure that tasks are completed.
The SSPP should define a program to satisfy the system safety requirements imposed by the contract. This section must:
a. Describe the scope of the overall program and the related system safety program.
b. List the tasks and activities of system safety management and engineering. Describe the interrelationships between
system safety and other functional elements of the program. List the other program requirements and tasks that are
applicable to system safety and identify where they are specified or described.
c. Account for all contractually required safety tasks and responsibilities. A matrix should be provided to correlate the
requirements of the contract to the location in the SSPP where the requirement is addressed.
1 02.2.2 System Safety Organization
The SSPP should describe:
a. The system safety organization or function within the organization of the total program using charts to show the
organizational and functional relationships, and lines of communication. The organizational relationship between other
functional elements having responsibility for tasks with system safety impacts and the system safety management and
engineering organization should be shown. Review and approval authority of applicable tasks by system safety should
be described.
b. The responsibility and authority of system safety personnel, other contractor organizational elements involved in the
system safety effort, subcontractors, and system safety groups. Describe the methods by which safety personnel may
raise issues of concern directly to the PM or the PM’s supervisor within the corporation. Identify the organizational unit
responsible for executing each task. Identify the authority in regard to resolution of all identified hazards.
c. The staffing of the system safety organization for the duration of the contract to include manpower loading, control of
resources and a summary of the qualifications of key system safety personnel assigned to the effort, including those
who possess coordination and approval authority for Developer-prepared documentation.
d. The procedures by which the Developer should integrate and coordinate the system safety efforts including assignment
of the system safety requirements to action organizations and subcontractors, coordination of subcontractor system
safety programs, integration of hazard analyses, program and design reviews, program status reporting, and system
safety groups.
e. The process through which Developer management decisions should be made including timely notification of
unacceptable risks, necessary action, incidents or malfunctions, waivers to safety requirements, program deviations,
etc.
f. Details of how resolution and action relative to system safety would be affected at the program management level
possessing resolution authority.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 52 of 1 04
1 02.2.3 System Safety Program Milestones
The SSPP must:
a. Define system safety program milestones. Relate these to major program milestones, program element responsibility,
and required inputs and outputs.
b. Provide a program schedule of safety tasks including start and completion dates, reports, and reviews.
c. Identify subsystem, component, software safety activities as well as integrated system level activities (i.e., design
analyses, tests, and demonstrations) applicable to the system safety program but specified in other engineering studies
and development efforts to preclude duplication.
d. Provide the estimated manpower loading required to complete each task.
1 02.2.4 General System Safety Requirements and Criteria
The SSPP must:
a. Describe general engineering requirements and design criteria for safety. Describe safety requirements for support
equipment and operational safety requirements for all appropriate phases of the life-cycle up to, and including, disposal.
List the safety standards and system specifications containing safety requirements with which the contractor must
comply. Include titles, dates, and where applicable, paragraph numbers.
b. Describe the risk assessment procedures. The mishap severity categories, mishap probability levels, and the system
safety precedence that should be followed to satisfy the safety requirements of the program. State any qualitative or
quantitative measures of safety to be used for risk assessment including a description of the acceptable/unacceptable
risk levels. Include system safety definitions which modify, deviate from or are in addition to those in this standard.
c. Describe closed-loop procedures for taking action to resolve identified unacceptable risk including those involving non-
developmental items.
1 02.2.5 Hazard Analysis
The SSPP should describe:
a. The analysis techniques and formats to be used in qualitative or quantitative analysis to identify hazards, their causes
and effects, hazard elimination, or risk reduction requirements and how those requirements are met.
b. The depth within the system to which each technique is used including hazard identification associated with the system,
subsystem, components, software, hazardous materials, personnel and human systems integration, ground support
equipment, non-developmental items, facilities, and their interrelationship in the logistic support, training, maintenance,
operational and disposal (including render safe and emergency disposal) environments.
c. The method of ensuring flow down of safety critical functions and associated requirements to the supplier and integration
of subcontractor/supplier hazard analyses with overall system hazard analyses.
d. Efforts to identify and control hazards associated with materials used during the system’s life-cycle.
e. The boundaries and key assumptions used for hazard analyses and the limits of the analyses. This typically includes:
(1 ) Hostile intentions or sabotage upon the system are not examined.
(2) Basic structural integrity is not analyzed.
(3) Hazards unique to factory support are not analyzed.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 53 of 1 04
(4) It is assumed that only trained, healthy, working-age adults will operate and support the system.
(5) Appropriate quality control and configuration standards are used in production, assembly and support.
(6) The analysis should have a limit of resolution. The limit is dependent on the system and details of the hazard. It
may change as more information on the system is acquired.
f. A systematic approach to:
(1 ) Implementing the software system safety unique tasks, activities, and work products (software safety requirements
analysis; top-level, detailed, design-level, code-level analyses, change analysis, and test analysis).
(2) Identifying and describing the software hazards.
(3) Identifying safety critical software functions and safety critical software requirements.
(4) Identifying the Software Criticality Index (SCI) for each safety critical software function and its associated
requirements.
(5) Assigning safety critical functions and requirements.
(6) Specifying verification method of yielding objective evidence of correct software implementation and functions.
(7) Performing a final risk assessment for software related hazards.
1 02.2.6 System Safety Data

The SSPP should:

a. Describe the approach for collecting and processing pertinent historical hazard, mishap, and safety lessons learned
data.
b. Identify deliverable data by title and number, and means of delivery (e.g., hard copy, electronically, etc.).
c. Identify non-deliverable system safety data and describe the procedures for accessibility by the Managing Authority and
retention of data of historical value.
1 02.2.7 Safety Verification

The SSPP should describe:

a. The verification (test, analysis, inspection, etc.) requirements and method for providing concrete evidence in artifacts
and test results that safety is adequately demonstrated.
b. Procedures for making sure that safety-related verification information is transmitted to the Managing Authority for
review and analysis.
c. Procedures for ensuring that the mishap risk of the testing itself is as low as reasonably practicable.
1 02.2.8 Audit program

The SSPP should describe the techniques and procedures to be employed by the contractor to make sure that the objectives
and requirements of the system safety program are being accomplished.
1 02.2.9 Training

The SSPP should describe the safety training for engineering, technician, operating, and maintenance personnel.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 54 of 1 04
1 02.2.1 0 Incident Reporting
The contractor should describe, in the SSPP, the mishap/incident alerting/notification, investigation, and reporting process
including notification of the Managing Authority.
1 02.2.1 1 System Safety Interfaces

The SSPP should identify, in detail:

a. The interface between system safety and all other applicable safety disciplines.
b. The interface between system safety, systems engineering, and all other support disciplines such as: maintainability,
quality control, reliability, software development, human system integration, medical support (health hazard
assessments), and any others.
c. The interface between system safety and all system integration and test disciplines.
1 02.2.1 2 Contractor-Supplied Plan

The contractor should provide a plan that complies with the requirements in paragraph 1 02.2 in their reply to the solicitation
as part of their proposal or integrated master plan and should be made a part of the contract.
1 02.3 Details to be Specified

Details to be specified in the solicitation should include the following, as applicable:

(R) a. Imposition of Tasks 1 01 and 1 02.
b. Identification of additional information to be provided.
Task 1 03 - Integration/Management of Associate Contractors, Subcontractors, and Architect and Engineering
Firms

1 03.1 Purpose

The purpose of Task 1 03 is to provide the Developer and Managing Authority with appropriate management surveillance of
the system safety program, and the capability to establish and maintain uniform integrated system safety program
requirements. This task should also describe requirements for associate contractors, subcontractors, and architect and
engineering (AE) firms’ system safety programs. This task can also be used to require the flow down of system safety
requirements to subcontractors, suppliers, and vendors.
1 03.2 Task Description

1 03.2.1 Integrator

The integrator for the safety functions of all associate/subcontractors must:

a. Prepare an integrated system safety program plan (ISSPP) as the SSPP required by
Task 1 02 defining the role of the integrator and the effort required from each associate contractor to help integrate
system safety requirements for the total system. In addition to the other contractually imposed requirements, the plan
should address and identify:
(1 ) Definition of where the control, authority and responsibility transitions are from Developer to associates and
subcontractors.
(2) Analyses, risk assessment, and verification data to be developed by each associate contractor with format and
method to be utilized.
(3) Data each associate/subcontractor is required to submit to the integrator and its scheduled delivery, keyed to
program milestones.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 55 of 1 04
(4) Schedule and other information considered pertinent by the integrator.
(5) The method of development of system level (including software) requirements to be allocated to each of the
associate/subcontractors as a part of the system specification, end-item specifications, and other interface
requirement documentation.
(6) Safety-related data pertaining to non-developmental items (NDI).
(7) Integrated safety analyses to be conducted and support required from associate and subcontractors.
(8) Developer roles in test range, nuclear safety, explosive, or other certification processes.
b. Initiate action, through the Managing Authority, to make sure that each associate contractor is required to be responsive
to the ISSPP. Recommend contractual modification where the need exists.
c. When conducting risk assessments, analyze the integrated system design, operations, and, specifically, the interfaces
between the products of each associate contractor or subcontractor and the end item. Data or analyses provided by
associate contractors and subcontractors should be used in the conduct of this effort.
d. When performing a safety assessment, summarize the mishap risk presented by the operation of the integrated system.
Data or analyses provided by associate contractors or subcontractors should be used in the conduct of this effort.
e. Provide assistance and guidance to associate contractors regarding safety matters.
f. Resolve differences between associate contractors in areas related to safety, especially during development of safety
inputs to system and item specifications. Where problems cannot be resolved by the integrator, notify the Managing
Authority for resolution and action.
g. Initiate action through the Managing Authority to make sure that information required by an associate/subcontractor
(from the integrating contractor or other associate contractors) to accomplish safety tasks, is provided in an agreed-to
format.
h. Develop a method of exchanging safety information between associate/subcontractors. If necessary, schedule and
conduct technical meetings between all associate contractors to discuss, review, and integrate the safety effort. Use of
System Safety Group/System Safety Working Group (SSG/SSWG) meetings should be included as required.
i. Implement an audit program to make sure that the objectives and requirements of the system safety program are being
accomplished. Whenever the Developer believes an associate contractor has failed to meet contract requirements, the
Developer should notify the Managing Authority in writing. The integrator for the safety effort should send a copy of the
notification to the associate contractor.
1 03.2.2 Associate Contractor
Associate contractors should provide safety data and support (including participation in SSGs/SSWGs) needed by other
associate contractors and the Developer to the extent specified in the contract.
1 03.2.3 Subcontractors
Applicable provisions of this standard should be included in all contracts with major subcontractors. The “chain of
responsibility” for formally flowing down the system safety contractual requirements from the Developer to different levels
of subcontractors, suppliers, and vendors (who provide different applicable subsystems, equipment and/or parts) should be
identified.
a. All subcontractors are required to maintain suitable documentation of safety analyses they have performed in formats
that will permit incorporation of their data into the overall analysis program.
b. Major subcontractors are required to develop system safety program plans to be included as annexes to the prime
contractor’s SSPP.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 56 of 1 04
c. Lesser subcontractors and vendors are required to provide information on software, component and subassembly
characteristics, including failure modes, failure rates, and possible hazards, which will permit Developer prime contractor
personnel to evaluate the items for their impact on safety of the system.
d. All subcontractors should participate in the SSG and SSWGs, when required.
1 03.2.4 Architect and Engineering Firms

The AE should be responsible for conducting facility hazard analyses and other facility SSPP functions as specified in the
solicitation. The AE should be responsible for securing the expertise necessary to perform the required work and should
have the same responsibilities as a prime contractor in hazard identification, tracking, and resolution. The AE should assure
that design subcontractors or consultants maintain and provide suitable documentation of any safety analyses performed.
1 03.3 Details to be Specified

Details to be specified in the solicitation should include the following, as applicable:

(R) a. Imposition of Tasks 1 01 , 1 02 and 1 03 as tailored.
(R) b. Designation of the system safety contractor (Developer).
c. Designation of status of the other associate/subcontractors.
d. Requirements for any special integrated safety analyses.
e. Requirements to support test range, nuclear safety, explosive, environmental or other certification processes.
f. Description of specific integration roles.
Task 1 04 - System Safety Program Reviews/Audits
1 04.1 Purpose

The purpose of Task 1 04 is to establish a requirement for the Developer to perform and document system safety program
reviews/audits or support of reviews/audits performed by the Managing Authority. This task is also used to acquire support
for special requirements such as certifications and test/flight readiness reviews.
1 04.2 Task Description

1 04.2.1 Perform and Document System Safety Program Reviews/Audits

The Developer should perform and document system safety program reviews/audits as specified by the Managing Authority.
These reviews/audits should be performed on:
a. The Developer’s system safety program.
b. The associate contractors’ system safety programs.
c. The support contractors’ system safety programs.
d. The subcontractors’ system safety programs.
1 04.2.2 Support System Safety Reviews/Audits

The Developer should support system safety reviews/audits performed by representatives of the Managing Authority to the
extent specified in the contract.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 57 of 1 04
1 04.2.3 Support Certifying Presentations
To the extent specified by the Managing Authority in the contract, the Developer should support presentations certifying
activities such as phase safety reviews, munitions safety boards, nuclear safety boards, or flight safety review boards. These
may also include special reviews such as flight/article readiness reviews or preconstruction briefings.
1 04.3 Details to be Specified

Details to be specified in the contract should include the following, as applicable:

(R) a. Imposition of Tasks 1 01 and 1 04.
(R) b. Identification of reviews/audits, their content, and probable locations.
c. Method of documenting the results of system safety reviews/audits.
d. Frequency of system safety reviews/audits.
Task 1 05 - System Safety Group/System Safety Working Group Support

1 05.1 Purpose

The purpose of Task 1 05 is to require Developers to support System Safety Groups (SSGs) and System Safety Working
Groups (SSWGs), which are established in accordance with service regulations or as otherwise defined by the Managing
Authority.
1 05.2 Task Description

The Developer should participate as an active member of Managing Authority SSG/SSWGs. Such participation should
include activities specified by the Managing Authority such as:
a. Presenting the Developer safety program status, including results of design or operations risk assessments.
b. Summarizing hazard analyses, including identification of problems, status of resolution, and mishap risk.
c. Presenting incident assessments (especially mishaps and malfunctions of the system being acquired) results including
recommendations and action taken to prevent recurrences.
d. Responding to action items assigned by the chairman of the SSG/SSWG.
e. Developing and validating system safety requirements and criteria applicable to the program.
f. Identifying safety deficiencies of the program and providing recommendations for corrective actions or preventions of
reoccurrence.
g. Planning and coordinating support for a required certification process.
h. Documenting and distributing meeting agendas and minutes when required by the Managing Authority.
1 05.2.1 Subcontractors

The Developer should require that all major subcontractors participate in the SSG/SSWGs.
1 05.2.2 Associate Contractor

The Developer should require that all associate contractors participate in the SSG/SSWGs.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 58 of 1 04
1 05.3 Details to be Specified
Details to be specified in the solicitation should include the following, as applicable:
(R) a. Imposition of Tasks 1 01 and 1 05.
(R) b. Developer membership requirements and role assignments, e.g., recorder, member, alternate, or technical
advisor.
(R) c. Frequency or total number of SSG/SSWG meetings and probable locations.
(R) d. Requirement for the contractor to prepare and distribute the agenda and minutes of the SSG/SSWG.
e. Specific SSG/SSWG or other presentation support tasks.
Task 1 06 - Hazard Tracking and Risk Resolution

1 06.1 Purpose

The purpose of Task 1 06 is to establish a single, closed-loop, hazard tracking system.

1 06.2 Task Description

1 06.2.1 Documents
The Developer should develop a method or procedure to document and track hazards and their controls thus providing an
audit trail of hazard resolutions. A centralized file, computer data base, or document called a “Hazard Log” should be
maintained. The Hazard Log should contain as a minimum:
a. Description of each hazard, to include associated mishap risk.
b. Status of each hazard and control.
c. Traceability of resolution on each Hazard Log item from the time the hazard was identified to the time the risk associated
with the hazard was reduced to a level acceptable to the Managing Authority.
d. Identification of mishap risk.
e. Action persons and organizational element.
f. The recommended controls to reduce the hazard to a level of risk acceptable to the Managing Authority.
g. The signature of the Managing Authority accepting the risk and thus effecting closure of the Hazard Log item.
1 06.2.2 Data

The contractor should deliver a copy of the Hazard Log to the Managing Authority as required in the list of contract
deliverables.
1 06.3 Details to be Specified

Details to be specified in the solicitation should include the following, as applicable:

(R) a. Imposition of Tasks 1 01 and 1 06.
(R) b. Procedure by, and detail to, which hazards are entered into the log.
(R) c. Procedure by which the contractor should obtain close-out or risk acceptance by the Managing Authority of
each hazard.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 59 of 1 04
d. Complete set of data required on the hazard log, including format.
e. Identification of any special requirements involving a computerized log.
Task 1 07 - System Safety Progress Summary

1 07.1 Purpose

The purpose of Task 1 07 is to prepare a periodic progress report summarizing the pertinent system safety management
and engineering activity that occurred during the reporting period.
1 07.2 Task Description
1 07.2.1 Periodic System Safety Progress Report

The Developer should prepare a periodic system safety progress report summarizing general progress made relative to the
system safety program during the specified reporting period, and projected work for the next reporting period. The format
and content requirements are defined in Appendix C, TDD-1 07.
1 07.2.2 Data

The Developer should prepare a report in Developer format that contains the following information:
a. A brief summary of activities, progress, and status of the safety effort in relation to the scheduled program milestones.
It should highlight significant achievements and problems. It should include progress toward completion of safety data
prepared or in work.
b. Newly recognized significant hazards and significant changes in the degree of control of the risk of known hazards.
c. Individual hazard resolution status and status of all recommended corrective actions that have not been implemented.
d. Significant cost and schedule changes that impact the safety program.
e. Discussion of contractor documentation reviewed by the system safety function during the reporting period. Indicate
whether the documents were acceptable for content and whether inputs to improve the safety posture were made.
f. Proposed agenda items for the next system safety group/working group meeting, if such groups are formed.
1 07.3 Details to be Specified

Details to be specified in the contract should include the following, as applicable:

(R) a. Imposition of Tasks 1 01 and 1 07.
(R) b. Specification of progress reporting period.
Task 1 08 - Launch Safety Program Requirements

1 08.1 Purpose

The purpose of this task is to require the Developer to support special safety requirements specific to launch facilities and
range design and operation.
1 08.2 Task Description

The Developer should comply with the following requirements (as tailored by the Managing Authority) when this task is
called out in the contract.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 60 of 1 04
1 08.2.1 Unacceptable/Acceptable Conditions
a. Unacceptable conditions. The following safety critical conditions are considered unacceptable. Positive action and
implementation verification is required to reduce the risk to an acceptable level as negotiated by the Developer and the
Managing Authority.
(1 ) Single component failure, common mode failure, human error, or design features that could result in a mishap as
defined by the Managing Authority.
(2) Dual independent component failures, dual human errors, or a combination of a component failure and a human
error involving safety critical command and control functions, which could result in a mishap as defined by the
Managing Authority.
(3) Generation of hazardous ionizing/non-ionizing radiation or energy when no provisions have been made to protect
personnel or sensitive subsystems from damage or adverse effects.
(4) Packaging or handling procedures and characteristics that could cause a mishap for which no controls have been
provided to protect personnel or sensitive equipment.
(5) Hazard level categories that are specified as unacceptable in the contract.
b. Acceptable conditions. The following approaches are considered acceptable for correcting unacceptable conditions and
would require no further analysis once controlling actions are implemented and verified.
(1 ) For nonsafety critical command and control functions; a system design that requires two or more independent
human errors, or that requires two or more independent failures, or a combination of independent failure and
human error.
(2) For safety critical command and control functions; a system design that requires at least three independent
failures, or three human errors, or a combination of three independent failures and human errors.
(3) System designs that positively prevent errors in assembly, installation, or connections that could result in a
mishap.
(4) System designs that positively prevent damage propagation from one component to another or prevent sufficient
energy propagation to cause a mishap.
(5) System design limitations on operation, interaction, or sequencing that preclude occurrence of a mishap.
(6) System designs that provide an approved safety factor or fixed design allowance that limits, to an acceptable
level, possibilities of structural failure or release of energy sufficient to cause a mishap.
(7) System designs that control energy build-up that could potentially cause a mishap (fuses, relief valves, electrical
explosion proofing, etc.).
(8) System designs in which component failure can be temporarily tolerated because of residual strength or alternate
operating paths so that operations can continue with a reduced but acceptable safety margin.
(9) System designs that positively alert the controlling personnel to a hazardous situation for which the capability for
operator reaction has been provided.
(1 0) System designs that limit/control the use of hazardous materials.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 61 of 1 04
1 08.2.2 Associate Safety Programs.
1 08.2.2.1 Industrial Safety and Hygiene
The Developer should conduct the system safety program so that it augments and supplements existing industrial safety
and toxicology activities. This coordinated effort should assure that equipment or properties being used or developed under
contract are protected from damage or mishap risk. When Developer owned or leased equipment is being used in
manufacturing, testing, or handling of products developed or produced under contract, analysis and operational proof checks
should be performed to show that risk of damage to those products has been minimized through proper design maintenance
and operation by qualified personnel using approved procedures. This standard does not cover those functions that the
Developer is required by law to perform under Federal or State OSHA, DOT, or EPA regulations.
1 08.2.2.2 Operational Site Safety
The Developer system safety program should encompass operational site activities. These activities should include all
operations listed in the operational time lines, including system installation, checkout, modification, and operation. Particular
attention should be given to operations and interfaces with ground support equipment and to the needs of the operators
relating to personnel subsystems such as: panel layouts, individual operator tasks, fatigue prevention, biomedical
considerations, etc.
1 08.2.2.3 Facilities
The Developer should include facilities in the system safety analyses activity. Facility safety design criteria should be
incorporated in the facility specification. Consideration should be given to the test, operational, and maintenance aspects of
the program. Identified requirements should include consideration of the compatibility with standards equal to or better than
those specified by the most stringent of Federal, State, and Local Regulations. The test and operations safety procedures
should encompass all development, qualification, acceptance tests, and operations. The procedures should include inputs
from the safety analyses and should identify test, operations, facility, and support requirements. The procedures should be
upgraded and refined as required to correct deficiencies identified by the system safety analyses to incorporate additional
safety requirements.
1 08.2.3 Range Safety
Compliance with the design and operational criteria contained in the applicable range safety manuals, regulations, and
standards should be considered in the system safety analysis and the system safety criteria. System safety is concerned
with minimizing risk to on- or off-site personnel and property arising from system operations on a range.
1 08.2.4 Drone and Missile System Safety
a. Verification of system design and operational planning compliance with range or operating site safety requirements
should be documented in the SAR or as otherwise specified in the contract SOW and CDRL.
b. Ensure that flight analysis and flight termination systems comply with the requirements of the test range being utilized.
Such requirements are applicable to the system during all flight phases until vehicle/payload impact or orbital insertion.
The SAR or other safety report, as specified in the CDRL, should include all aspects of flight safety systems.
c. The Developer’s system safety representatives should be an integral part of the flight evaluation and assessment team
that reviews field/flight operations to correct any identified deficiencies and recommend appropriate safety
enhancements during the field/flight operation process.
1 08.3 Details to be Specified
Details to be specified in the contract should include the following, as applicable:
(R) a. Imposition of Tasks 1 01 and 1 08.
(R) b. Identification of the paragraphs in Task 1 08 that apply or do not apply.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 62 of 1 04
Task 1 09 - Test Hazard Analysis Safety (Ground or Airborne Systems)
1 09.1 Purpose

The purpose of Task 1 09 is to establish a requirement for the Developer to assess and document hazards associated
unique to test safety activities.
1 09.2 Task Description

1 09.2.1 Ground and/or Flight Test Safety Program

An effective ground and/or flight test safety program should be implemented any time support of unqualified systems or air
vehicles (manned or unmanned) are to be ground/flight tested with residual risk, spiral software, regression testing, or other
test operations.
1 09.2.2 Test Hazard Analyses

Test hazard analyses should be performed to determine ground or flight risk, and to recommend mitigation and any
restrictions, aircraft operating limitations, temporary operating procedures, special precautions, or emergency procedures.
1 09.2.3 Independent Aircraft Test Safety Review Boards
Independent aircraft test safety review boards should be convened as required to assess overall safety risk of the hardware,
software, system, human system integration, airworthiness, mitigations, flight clearances, and other areas as required.
1 09.3 Details to be Specified

Details to be specified in the contract should include the following, as applicable:

(R) a. Imposition of Tasks 1 01 and 1 09.
(R) b. Identification of the paragraphs in task 1 09 that apply or do not apply.
Task 201 - Preliminary Hazard List (PHL)

201 .1 Purpose

The purpose of Task 201 is to compile a list of potential hazards, very early in the system development cycle, on which
management emphasis needs to be placed.
201 .2 Task Description
The contractor must:
201 .2.1 Compile a PHL

Examine the system shortly after the concept definition effort begins and compile a list (PHL) identifying possible hazards
that may be inherent in the concept and their associated mishap potential, or identify hazards specified by the Managing
Authority.
201 .2.2 Review Safety Experience
Review safety experience on similar systems, including mishap/incident hazard tracking logs (if accessible), safety lessons
learned, etc., to identify possible hazards and their mishap risks. The sources of a hazard found in this review should be
referenced in the PHL.
201 .2.3 Investigate Hazards Identified in the PHL

Further investigate selected hazards or hazardous characteristics identified in the PHL as directed by the Managing
Authority to determine their significance.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 63 of 1 04
201 .2.4 Data
The Developer should prepare a Report that contains the results from the work task described by paragraph 201 .2 above
to include the following information:
201 .2.4.1 Hazard Analysis Results

This should consist of a summary or a total listing of the results of hazard analysis. Contents and formats should be as
agreed upon between the Developer and the Managing Authority. The following are the content requirements unless
otherwise modified:
a. A summary of the results.
b. A listing of identified potential hazards, in narrative or matrix (sometimes called columnar or tabular) format, to include
the following information:
(1 ) Hazard Description.
(a) A brief description of the hazard in terms that identify a source, mechanism, and an outcome, for example,
"Radiation leakage from radar set waveguide harming nearby personnel."
(b) The recommended action required to eliminate or control the hazard.
(c) Any information relating to the hazard not covered in other blocks; for example, applicable documents, previous
failure data on similar systems, or administrative directions.
201 .3 Details to be Specified

Details to be specified in the SOW should include the following, as applicable:

(R) a. Imposition of Tasks 1 01 and 201 .
b. Identification of special concerns, hazards, or undesired events that the Managing Authority wants listed or
investigated.
Task 202 - Preliminary Hazard Analysis

202.1 Purpose

The purpose of Task 202 is to perform and document a Preliminary Hazard Analysis (PHA) to identify safety critical areas,
to provide an initial assessment of hazards, and to identify requisite hazard controls and follow-on actions.
202.2 Task Description

202.2.1 Perform and Document a Preliminary Hazard Analysis

The Developer should perform and document a preliminary hazard analysis to obtain an initial risk assessment of a concept
or system. Based on the best available data, including mishap data (if assessable) from similar systems and other lessons
learned, hazards associated with the proposed design or function should be evaluated for mishap severity, mishap
probability, and operational constraint. Safety provisions and alternatives needed to eliminate hazards or reduce their
associated risk to a level acceptable to the Managing Authority should be included. The PHA should consider the following
for identification and evaluation of hazards as a minimum:
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 64 of 1 04
a. Hazardous components (e.g., fuels, propellants, lasers, explosives, toxic substances, hazardous construction materials,
pressure systems, and other energy sources).
b. Safety related interface considerations among various elements of the system (e.g., material compatibilities,
electromagnetic interference, inadvertent activation, fire/explosive initiation and propagation, and hardware and
software controls). This should include consideration of the potential contribution by software (including software
developed by other contractors/sources) to subsystem/system mishaps. Safety design criteria to control safety critical
software commands and responses (e.g., inadvertent command, failure to command, untimely command or responses,
inappropriate magnitude, or Managing Authority-designated undesired events) should be identified and appropriate
action taken to incorporate them in the software (and related hardware) specifications.
c. Operating conditions including the operating environments (e.g., drop, shock, vibration, extreme temperatures, noise,
exposure to toxic substances, health hazards, fire, electrostatic discharge, lightning, electromagnetic environmental
effects, ionizing and non-ionizing radiation including laser radiation).
d. Operating, test, maintenance, built-in-tests, diagnostics, and emergency procedures (e.g., human factors engineering,
human error analysis of operator functions, tasks, and requirements; effect of factors such as equipment layout, lighting
requirements, potential exposures to toxic materials, effects of noise or radiation on human performance; explosive
ordnance render safe and emergency disposal procedures; life support requirements and their safety implications in
manned systems, crash safety, egress, rescue, survival, and salvage). Those test unique hazards that would be a direct
result of the test and evaluation of the article or vehicle.
e. Facilities, real property installed equipment, support equipment (e.g., provisions for storage, assembly, checkout, or
proof testing of hazardous systems/assemblies that may involve toxic, flammable, explosive, corrosive, or cryogenic
materials/wastes; radiation or noise emitters; electrical power sources), and training (e.g., training and certification
pertaining to safety operations and maintenance).
f. Safety related equipment, safeguards, and possible alternate approaches (e.g., interlocks; system redundancy; fail safe
design considerations using hardware or software controls; subsystem protection; fire detection and suppression
systems; personal protective equipment; heating, ventilation, and air-conditioning; and noise or radiation barriers).
g. System, subsystem, or software malfunctions should be specified, the causing and resulting sequence of events
determined, the degree of hazard determined, and appropriate specification and/or design changes developed.
202.2.2 Report Requirements
The Developer should prepare a report that contains the results from the work task described by paragraph 202.2 above,
to include the following information (which is defined in Appendix C, TDD-202):
202.2.2.1 System Description
This should consist of summary descriptions of the physical and functional characteristics of the system and its components.
Reference to more detailed system and component descriptions, including specifications and detailed review
documentation, should be supplied when such documentation is available. The capabilities, limitations, and
interdependence of these components should be expressed in terms relevant to safety. The system, and its components,
should be addressed in relation to its mission and its operational environment. System block diagrams or functional flow
diagrams may be used to clarify system descriptions. Software and its roles should be included in this description.
202.2.2.2 Data
This should consist of summaries of data used to determine the safety aspects of design features.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 65 of 1 04
202.2.2.3 Hazard Analysis Results
This should consist of a summary or a total listing of the results of hazard analysis. Contents and formats may vary according
to the individual requirements of the program. The following are the content and format requirements for Hazard Analysis
Results:
a. A summary of the results.
b. A listing of identified hazards, in narrative or matrix (sometimes called columnar or tabular) format, to include the
following information:
(1 ) System/Subsystem/Unit. Enter the particular part of the system that this analysis is concerned with. For example,
if this items applies to a radar system modulator, enter "modulator." If there are several modulators in the system,
be sure to clearly specify which one the analysis pertains to.
(2) System Events Phase. The configuration or phase of the mission that the system is in when the hazard is
encountered; for example, during maintenance, during flight, during pre-flight, full-power applied, etc. The hazard
could be encountered in multiple or all system events.
(3) Hazard Description. A brief description of the hazard in terms that identify a source, a mechanism, and an outcome,
for example, "Radiation leakage from radar set waveguide harming nearby personnel."
(4) Effect of Hazard. The detrimental effects that could be inflicted on the subsystem, system, other equipment, facilities
or personnel, by this hazard. Possible upstream and downstream effects should also be described.
(5) Risk Assessment. A risk assessment for each hazard (classification of severity and probability of occurrence). This
is the assessment of the risk prior to taking any action to eliminate or control the hazard.
(6) Recommended Action. The recommended action required to eliminate or control the hazard. Sufficient technical
detail is required in order to permit the design engineers to adequately develop and assess design criteria resulting
from the analysis. Include alternative designs and life-cycle cost impact where appropriate.
(7) Effect of Recommended Action. The effect of the recommended action on the assigned risk assessment. This is
the risk assessment after taking action to eliminate or control each hazard. If the recommended action would result
in cost/schedule/performance penalties to the extent that the Developer requires Managing Authority approval prior
to incorporation, then these considerations should be addressed.
(8) Remarks. Any information relating to the hazard not covered in other blocks; for example, applicable documents,
previous failure data on similar systems, or administrative directions.
(9) Status. The status of actions to implement the recommended, or other, hazard controls. The status should include
not only an indication of “open” or “closed,” but also reference to the drawings, specifications, procedures, etc., that
support closure of the particular hazard.
202.3 Details to be Specified
Details to be specified in the SOW should include the following, as applicable:
(R) a. Imposition of Tasks 1 01 and 202.
(R) b. Minimum mishap probability and severity reporting thresholds.
c. Any selected hazards, hazardous areas, or other specific items to be examined or excluded.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 66 of 1 04
Task 203 - Safety Requirements/Criteria Analysis
203.1 Purpose

The purpose of Task 203 is to perform and document the safety design requirements/design criteria for a facility or system
under development/design.
203.2 Task Description

The Safety Requirements/Criteria Analysis (SRCA) relates the hazards identified to the system design and identifies or
develops design requirements to eliminate or reduce the risk of the identified hazards to an acceptable level. The SRCA
uses the Preliminary Hazard List (Task 201 ) or the Preliminary Hazard Analysis (Task 202) as a basis, if available. The
SRCA is also used to incorporate design requirements that are safety related but not tied to a specific hazard. The format
and content requirements are defined in Appendix C, TDD-203. The analysis includes the following efforts:
203.2.1 Generic System Safety Design Requirements

The Developer should determine applicable generic system safety design requirements and guidelines for facilities;
hardware, and software from federal, military, national, and industry regulations, codes, standards, specifications; and other
documents for the system under development. The Developer should incorporate these requirements and guidelines into
the high level system specifications and design documents as appropriate.
203.2.2 System Design Requirements Analysis

The Developer should analyze the System Design Requirements, System/Segment Specifications (SSS), Preliminary
Hardware Configuration Item Development Specification, Software Requirements Specifications (SRS), and the Interface
Requirements Specifications (IRS), or equivalent documents as appropriate, to include the following sub-tasks:
a. The Developer should ensure that the system safety design requirements and guidelines are developed; refined;
correctly and completely specified; properly translated into system hardware and software requirements and guidelines
where appropriate; and implemented in the design and development of the system hardware and associated software.
b. The Developer should identify hazards and relate them to the specifications or documents listed above and develop
design requirements to reduce the risk of those hazards.
c. The Developer should identify safety critical computer software components (SCCSCs) and ensure they are placed
under configuration control. Safety critical software functions and requirements should be identified, traced, analyzed,
tested, and verified at the appropriate levels (system integration, top level, detail design, unit level, code).
d. The Developer should analyze the preliminary system design to identify potential hardware/ software interfaces at a
gross level that may control, cause or contribute to potential hazards. Interfaces identified should include control
functions, monitoring functions, safety systems and functions that may have indirect impact on safety. These interfaces
and the associated software should be designated as safety critical.
e. The Developer should perform a preliminary mishap risk assessment on the identified safety critical software functional
requirements using the mishap risk matrix or software hazard criticality matrix of Appendix A or another process as
mutually agreed to by the Developer and the Managing Authority.
f. The Developer should ensure that System Safety design requirements are properly incorporated into the operator, user,
and diagnostic manuals.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 67 of 1 04
203.2.3 Safety Related Design Change Recommendations and Testing Requirements
The Developer should develop safety related design change recommendations and testing requirements and should
incorporate them into Preliminary Design Documents and the hardware, software and system test plans. The following sub-
tasks should be accomplished:
a. The Developer should develop safety-related change recommendations to the design and specification documents
listed above and should include a means of verification for each design requirement.
b. The Developer should develop safety related test requirements for incorporation into the test documents. Tests should
be developed for hardware, software and system integration testing.
203.2.4 Developer Support

The Developer should support the System Requirements Review (SRR), System Design Review (SDR) and Software
Specification Review (SSR) from a system safety viewpoint. The Developer should address the system safety program,
analyses performed and to be performed, significant hazards identified, hazard resolutions or proposed resolutions, and
means of verification.
203.2.5 Report Requirements

The Developer should prepare a report that contains the results from the work task described by paragraph 203.2 above to
include the following (which is defined in Appendix C, TDD-203):
203.2.5.1 System Description

This should consist of summary descriptions of the physical and functional characteristics of the system and its components.
Reference to more detailed system and component descriptions, including specifications and detailed review
documentation, should be supplied when such documentation is available. The capabilities, limitations and interdependence
of these components should be expressed in terms relevant to safety. The system and components should be addressed
in relation to the mission and operational environment. System block diagrams or functional flow diagrams may be used to
clarify system descriptions. Software and its roles should be included in this description.
203.2.5.1 .1 Generic System Safety Design Requirements and Guidelines
A list of the applicable generic system safety design requirements and guidelines for facilities; hardware and software from
federal, military, national and industry regulations, codes, standards, specifications; and other documents for the system
under development that have been determined to be applicable.
203.2.5.1 .2 Data

This should consist of summaries of data used to determine the safety aspects of design features.
203.2.5.1 .3 Hazard Analysis Results
This should consist of a summary or a total listing of the results of hazard analysis. Contents and formats may vary according
to the individual requirements of the program. The following are the content and format requirements for Hazard Analysis
Results:
a. A summary of the results.
b. Recommended action. The recommended action required to eliminate or control the hazard. Sufficient technical detail
is required in order to permit the design engineers to adequately develop and assess design criteria resulting from the
analysis. Include alternative designs and life-cycle cost impact where appropriate.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 68 of 1 04
203.3 Details to be Specified
Details to be specified in the SOW should include the following, as applicable:
(R) a. Imposition of Tasks 1 01 and 203 tailored to the developmental program.
(R) b. Definition of acceptable level of risk within the context of the system, subsystem, or component under analysis.
(R) c. Level of Developer support required for design reviews.
d. Specification of the types of risk assessment process.
Task 204 - Subsystem Hazard Analysis
204.1 Purpose

The purpose of Task 204 is to perform and document a Subsystem Hazard Analysis (SSHA) to: verify subsystem compliance
with safety requirements contained in subsystem specifications and other applicable documents; identify previously
unidentified hazards associated with the design of subsystems including component failure modes, critical human error
inputs, and hazards resulting from functional relationships between components and equipment comprising each
subsystem; recommend actions necessary to eliminate identified hazards or control their associated risk to acceptable
levels.
204.2 Task Description

The Developer should perform and document a subsystem hazard analysis to identify all components and equipment that
could result in a hazard or whose design does not satisfy contractual safety requirements. This should include furnished
equipment, non-developmental items, and software. Areas to consider are performance, performance degradation,
functional failures, timing errors, design errors or defects, or inadvertent functioning. The human should be considered a
component within a subsystem, receiving both inputs and initiating outputs, during the conduct of this analysis.
204.2.1 Required Elements

The analysis should include a determination:

a. Of the modes of failure including reasonable human errors as well as single point and common mode failures, and the
effects on safety when failures occur in subsystem components.
b. Of potential contribution of hardware and software (including that which is developed by other developers/sources)
events, faults, and occurrences (such as improper timing) on the safety of the subsystem.
c. That the safety design criteria in the hardware, software, and facilities specifications have been satisfied.
d. That the method of implementation of hardware, software, and facilities design requirements and corrective actions has
not impaired or decreased the safety of the subsystem nor has it introduced any new hazards or risks.
e. Of the implementation of safety design requirements from top level specifications to detailed design specifications for
the subsystem. The implementation of safety design requirements developed as part of the PHA and SRCA should be
analyzed to ensure that it satisfies the intent of the requirements.
f. Of test plan and procedure recommendations to integrated safety testing into the hardware and software test programs.
g. That system level hazards attributed to the subsystem are analyzed and that adequate control of the potential hazard
is implemented in the design.
204.2.2 Managing Authority Approval
If no specific analysis techniques are directed or if Developer recommends that a different technique than specified by the
Managing Authority should be used, the Developer should obtain Managing Authority approval of techniques to be used
prior to performing the analysis.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 69 of 1 04
204.2.3 Software Development
When software to be used in conjunction with the subsystem is being developed under other development documents; the
developer/subcontractor performing the SSHA should monitor, obtain and use the output of each phase of the formal
software development process in evaluating the software contribution to the SSHA. Problems identified that require the
reaction of the software developer should be reported to the Managing Authority in time to support the ongoing phase of
the software development process.
204.2.4 Required Updates
The Developer should update the SSHA as a result of any system design changes, including software design changes, that
affect system safety.
204.2.5 Report Requirements
The Developer should prepare a report that contains the results from the work task described by paragraph 204.2 above to
include the following information (which is defined in Appendix C, TDD-204):
204.2.5.1 System Description
This should consist of summary descriptions of the physical and functional characteristics of the system and its components.
Reference to more detailed system and component descriptions, including specifications and detailed review documentation
should be supplied when such documentation is available. The capabilities, limitations and interdependence of these
components should be expressed in terms relevant to safety. The system and components should be addressed in relation
to its mission and its operational environment. System block diagrams or functional flow diagrams may be used to clarify
system descriptions. Software and its roles should be included in this description.
204.2.5.2 Data
This should consist of summaries of data used to determine the safety aspects of design features.
204.2.5.3 Hazard Analysis Results
This should consist of a summary or a total listing of the results of hazard analysis. Contents and formats may vary according
to the individual requirements of the program. The following are the content and format requirements for Hazard Analysis
Results:
a. A summary of the results.
b. A listing of identified hazards, in narrative or matrix (sometimes called columnar or tabular) format, to include the
following information:
(1 ) Components Failure Modes. All component failure modes that can result in a hazard. Failure modes generally
answer the question of “how” it fails.
(2) System Events Phase. The configuration or phase of the mission that the system is in when the hazard is
encountered; for example, during maintenance, during flight, during pre-flight, full-power applied, etc., or it could be
encountered in all system events.
(3) Description. A complete description of the potential/actual hazards inherent in the item being analyzed, or resulting
from normal actions or equipment failure, or handling of hazardous materials.
(4) Effect of Hazard. The detrimental effects which could be inflicted on the subsystem, system, other equipment,
facilities or personnel, resulting from this hazard. Possible upstream and downstream effects should also be
described.
(5) Risk Assessment. A risk assessment for each hazard (classification of severity and probability of occurrence). This
is the assessment of the risk prior to taking any action to eliminate or control the hazard.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 70 of 1 04
(6) Recommended Action. The recommended action required to eliminate or control the hazard. Sufficient technical
detail is required in order to permit the design engineers to adequately develop and assess design criteria resulting
from the analysis. Include alternative designs and life-cycle cost impact where appropriate.
(7) Effect of Recommended Action. The effect of the recommended action on the assigned risk assessment. This is
the risk assessment after taking action to eliminate or control each hazard. If the recommended action would result
in cost/schedule/performance penalties to the extent that the Developer requires Managing Authority approval prior
to incorporation, then these considerations should be addressed.
(8) Remarks. Any information relating to the hazard not covered in other blocks; for example, applicable documents,
previous failure data on similar systems, or administrative directions.
(9) Status. The status of actions to implement the recommended, or other, hazard controls. The status should include
not only an indication of “open” or “closed,” but also reference to the drawings, specifications, procedures, etc., that
support closure of the particular hazard.
204.3 Details to be Specified
Details to be specified in the SOW should include the following, as applicable:
(R) a. Imposition of Tasks 1 01 and 204.
(R) b. Minimum mishap severity and probability reporting thresholds.
c. The specific subsystems to be analyzed.
d. Any selected hazard, hazardous areas, or other specific items to be examined or excluded.
e. Specification of desired analysis techniques and/or format.
f. The Managing Authority should provide the technical data on furnished equipment to enable the Developer to
accomplish the defined tasks.
Task 205 - System Hazard Analysis

205.1 Purpose

The purpose of Task 205 is to perform and document a System Hazard Analysis (SHA) to: verify system compliance with
safety requirements contained in system specifications and other applicable documents; identify previously unidentified
hazards associated with the subsystem interfaces and system functional faults; assess the risk associated with the total
system design, including software, and specifically of the subsystem interfaces; and recommend actions necessary to
eliminate identified hazards and/or control their associated risk to acceptable levels.
205.2 Task Description

The Developer should perform and document a system hazard analysis to identify hazards and assess the risk of the total
system design, including software, and specifically of the subsystem interfaces.
205.2.1 Analysis Requirements

This analysis should include a review of subsystems interrelationships for:

a. Compliance with specified safety design criteria.
b. Possible independent, dependent, and simultaneous hazardous events including system failures; failures of safety
devices; common cause failures and events; and system interactions that could create a hazard or result in an increase
in mishap risk.
c. Degradation in the safety of a subsystem or the total system from normal operation of another subsystem.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 71 of 1 04
d. Design changes that affect subsystems.
e. Effects of reasonable human errors.
f. Determination:
(1 ) Of potential contribution of hardware and software (including that which is developed by other contractors/sources,
or Commercial Off-The-Shelf hardware or software) events, faults, and occurrences (such as improper timing) on
safety of the system.
(2) That the safety design criteria in the hardware, software, and facilities specifications have been satisfied.
(3) That the method of implementation of the hardware, software, and facilities design requirements and corrective
actions have not impaired or degraded the safety of the system and have not introduced any new hazards.
205.2.2 Managing Authority Approval
If no specific analysis techniques are directed or if the Developer recommends that a different technique than specified by
the Managing Authority should be used, the Developer should obtain Managing Authority approval of techniques to be used
prior to performing the analysis. The SHA may be combined with and/or performed using similar techniques to those used
for the SSHA.
205.2.3 Software Development
When software to be used in conjunction with the system is being developed under other software development requirement
documents; the developer performing the SHA should monitor, obtain, and use the output of each phase of the formal
software development process in evaluating the software contribution to the SHA. Problems identified that require the
reaction of the software developer should be reported to the Managing Authority in time to support the ongoing phase of
the software development process.
205.2.4 Required Updates
The Developer should update the SHA as a result of any system design changes, including software design changes, that
affect system safety.
205.2.5 Report Requirements
The Developer should prepare a report that contains the results from the work task described by paragraph 205.2 above to
include the following information (which is defined in Appendix C, TDD-205):
205.2.5.1 System Description
This should consist of summary descriptions of the physical and functional characteristics of the system and its components.
Reference to more detailed system and component descriptions, including specifications and detailed review documentation
should be supplied when such documentation is available. The capabilities, limitations, and interdependence of these
components should be expressed in terms relevant to safety. The system and its components should be addressed in
relation to its mission and its operational environment. System block diagrams or functional flow diagrams may be used to
clarify system descriptions. Software and its roles should be included in this description.
205.2.5.2 Data
This should consist of summaries of data used to determine the safety aspects of design features.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 72 of 1 04
205.2.5.3 Hazard Analysis Results
This should consist of a summary or a total listing of the results of hazard analysis. Contents and formats may vary according
to the individual requirements of the program. The following are the content and format requirements for Hazard Analysis
Results:
a. A summary of the results.
b. A listing of identified hazards, in narrative or matrix (sometimes called columnar or tabular) format, to include the
following information:
(1 ) Subsystem Failure Modes. The subsystem failure mode descriptions for the SHA are similar to the component
descriptions provided in the SSHA. However, emphasis is now placed on failure affecting interfacing subsystem
operations.
(2) System Events Phase. The configuration or phase of the mission the system is in when the hazard is encountered;
for example, during maintenance, during flight, during pre-flight, full-power applied, etc., or it could be encountered
in all system events.
(3) Description. A complete description of the potential/actual hazards inherent in the item being analyzed, or resulting
from normal actions or equipment failure, or handling of hazardous materials.
(4) Effect of Hazard. The detrimental effects that could be inflicted on the subsystem, system, other equipment, facilities
or personnel, resulting from this hazard. Possible upstream and downstream effects should also be described.
(5) Risk Assessment. A risk assessment for each hazard (classification of severity and probability of occurrence). This
is the assessment of the risk prior to taking any action to eliminate or control the hazard.
(6) Recommended Action. The recommended action required to eliminate or control the hazard. Sufficient technical
detail is required in order to permit the design engineers to adequately develop and assess design criteria resulting
from the analysis. Include alternative designs and life-cycle cost impact where appropriate.
(7) Effect of Recommended Action. The effect of the recommended action on the assigned risk assessment. This is
the risk assessment after taking action to eliminate or control each hazard. If the recommended action would result
in cost/schedule/performance penalties to the extent that the Developer requires approval prior to incorporation,
then these considerations should be addressed.
(8) Remarks. Any information relating to the hazard not covered in other blocks; for example, applicable documents,
previous failure data on similar systems, or administrative directions.
(9) Status. The status of actions to implement the recommended, or other, hazard controls. The status should include
not only an indication of “open” or “closed,” but also reference to the drawings, specifications, procedures, etc., that
support closure of the particular hazard.
205.3 Details to be Specified
Details to be specified in the SOW should include the following, as applicable:
(R) a. Imposition of Tasks 1 01 and 205.
(R) b. Minimum mishap severity and probability reporting thresholds.
c. Any selected hazards, hazardous areas, or other specific items to be examined or excluded.
d. Specification of desired analysis techniques and/or format.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 73 of 1 04
Task 206 - Operating and Support Hazard Analysis
206.1 Purpose

The purpose of Task 206 is to perform and document an Operating and Support Hazard Analysis (O&SHA), to evaluate
activities for hazards or risks introduced into the system by operational and support procedures, and to evaluate adequacy
of operational and support procedures used to eliminate, control, or abate identified hazards or risks.
206.2 Task Description

The Developer should perform and document an O&SHA to examine procedurally controlled activities. The O&SHA
identifies and evaluates hazards resulting from the implementation of operations or tasks performed by persons,
considering: the planned system configuration/state at each phase of activity; the facility interfaces; the planned
environments (or ranges thereof); the supporting tools or other equipment, including software controlled automatic test
equipment, specified for use; operational/task sequence, concurrent task effects and limitations; biotechnological factors,
regulatory or contractually specified personnel safety and health requirements; and the potential for unplanned events
including hazards introduced by human errors. The human should be considered an element of the total system, receiving
both inputs and initiating outputs, during the conduct of this analysis. The O&SHA should identify the safety requirements
(or alternatives) needed to eliminate or control identified hazards, or to reduce the associated risk to a level which is
acceptable under either regulatory or contractually specified criteria.
206.2.1 Analysis Requirements

The analysis should identify:

a. Activities that occur under hazardous conditions, their time periods, and the actions required to minimize risk during
these activities/time periods.
b. Changes needed in functional or design requirements for system hardware/software, facilities, tooling, or support/test
equipment to eliminate or control hazards or reduce associated risks.
c. Requirements for safety devices and equipment, including personnel safety and life support equipment.
d. Warnings, cautions, and special emergency procedures (e.g., egress, rescue, escape, render safe, explosive ordnance
disposal, back-out, etc.), including those necessitated by failure of a computer software-controlled operation to produce
the expected and required safe result or indication.
e. Requirements for packaging, handling, storage, transportation, maintenance, and disposal of hazardous materials.
f. Requirements for safety training and personnel certification.
g. Effects of non-developmental hardware and software across the interface with other system components or
subsystems.
h. Potentially hazardous system states under operator control.
206.2.2 O&SHA Documents

The O&SHA should document system safety assessment of procedures involved in: system production, deployment,
installation, assembly, test, operation, maintenance, servicing, transportation, storage, modification, demilitarization, and
disposal.
206.2.3 Managing Authority Approval
If no specific analysis techniques are directed or if the Developer recommends that a different technique than specified by
the Managing Authority should be used, the Developer should obtain Managing Authority approval of techniques to be used
prior to performing the analysis.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 74 of 1 04
206.2.4 Updates
The Developer should update the O&SHA as a result of any system design or operational changes.
206.2.5 Report Requirements
The Developer should prepare a report that contains the results from the work task described by paragraph 206.2 above to
include the following information (which is defined in Appendix C, TDD-206):
206.2.5.1 System Description
This should consist of summary descriptions of the physical and functional characteristics of the system and its components.
Reference to more detailed system and component descriptions, including specifications and detailed review documentation
should be supplied when such documentation is available. The capabilities, limitations and interdependence of these
components should be expressed in terms relevant to safety. The system and components should be addressed in relation
to its mission and its operational environment. System block diagrams or functional flow diagrams may be used to clarify
system descriptions. Software and its roles should be included in this description.
206.2.5.2 Data
This should consist of summaries of data used to determine the safety aspects of design features.
206.2.5.3 Hazard Analysis Results
This should consist of a summary or a total listing of the results of hazard analysis. Contents and formats may vary according
to the individual requirements of the program. The following are the content and format requirements for Hazard Analysis
Results:
a. A summary of the results.
b. A listing of identified hazards, in narrative or matrix (sometimes called columnar or tabular) format, to include the
following information:
(1 ) System Component/Phase. The particular phase/component that the analysis is concerned with. This could be a
system, subsystem, component, software, or operating/maintenance procedure.
(2) System Operation Description. A description of what is normally expected to occur as the result of operating the
component/subsystem or performing the operating/maintenance action.
(3) Description. A complete description of the potential/actual hazards inherent in the item being analyzed, or
resulting from normal actions or equipment failure, or handling of hazardous materials.
(4) Hazard Identification/Indication. A description of operator/crew indications that include all means of identifying the
hazard to operational/maintenance personnel.
(5) Effect of Hazard. The detrimental effects that could be inflicted on the subsystem, system, other equipment,
facilities or personnel, resulting from this hazard. Possible upstream and downstream effects should also be
described.
(6) Risk Assessment. A risk assessment for each hazard (classification of severity and probability of occurrence).
This is the assessment of the risk prior to taking any action to eliminate or control the hazard.
(7) Recommended Action. The recommended action required to eliminate or control the hazard. Sufficient technical
detail is required in order to permit the design engineers to adequately develop and assess design criteria
resulting from the analysis. Include alternative designs and life-cycle cost impact where appropriate.
(8) Effect of Recommended Action. The effect of the recommended action on the assigned risk assessment. This is
the risk assessment after taking action to eliminate or control each hazard. If the recommended action would
result in cost/schedule/performance penalties to the extent that the Developer requires approval prior to
incorporation, then these considerations should be addressed.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 75 of 1 04
(9) Remarks. Any information relating to the hazard not covered in other blocks; for example, applicable documents,
previous failure data on similar systems, or administrative directions.
(1 0) Status. The status of actions to implement the recommended, or other, hazard controls. The status should include
not only an indication of “open” or “closed,” but also reference to the drawings, specifications, procedures, etc.,
that support closure of the particular hazard.
(1 1 ) Caution and Warning Notes. A complete list of warnings, cautions, and procedures required in operating and
maintenance manuals and for training courses.
206.3 Details to be Specified

Details to be specified in the SOW should include the following, as applicable:

(R) a. Imposition of Tasks 1 01 and 206.
(R) b. Minimum mishap probability and severity reporting thresholds.
c. Specification of desired analysis techniques and/or format.
d. The specific procedures to be evaluated (Reference 206.2.2).
Task 207 - Health Hazard Assessment

207.1 Purpose

The purpose of Task 207 is to perform and document a Health Hazard Assessment (HHA) to identify health hazards,
evaluate proposed hazardous materials, and propose protective measures to reduce the associated risk to a level
acceptable to the Managing Authority.
207.2 Task Description

A HHA should be performed and documented to identify health hazards and to recommend engineering controls, equipment,
and/or protective procedures, to reduce the associated risk to a level acceptable to the Managing Authority. An HHA should
also evaluate the hazards and costs due to system components materials, evaluate alternative materials for those
components, and recommend materials that reduce the associated risk. Materials should be evaluated if (because of their
physical, chemical, or biological characteristics; quantity; or concentrations) they cause or contribute to adverse effects in
organisms or off-spring, or result in damage to or loss of equipment or property during the systems life-cycle. Assessments
should include consideration of the generation of hazardous wastes.
207.2.1 Health Hazards to be Considered

A health hazard is an existing or likely condition, inherent to the operation, maintenance, transport, or use of materiel that
can cause death, injury, acute or chronic illness, disability, or reduced job performance of personnel by exposure to
physiological stresses. Specific health hazards and impacts that should be considered include:
a. Chemical hazards (e.g., hazardous materials that are flammable; corrosive; toxic; carcinogens or suspected
carcinogens; systemic poisons; asphyxiates, including oxygen deficiencies; respiratory irritants; etc.).
b. Physical hazards (e.g., acoustical energy, heat or cold stress, ionizing and non-ionizing radiation).
c. Biological hazards (e.g., bacteria, fungi, etc.).
d. Ergonomic hazards (e.g., lifting requirements, task saturation, etc.).
e. Other hazardous, or potentially hazardous, materials that may be formed by the introduction of the system or by the
manufacture, test, maintenance or operation of the system.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 76 of 1 04
207.2.2 HHA Evaluation Requirements
The HHA hazardous material evaluation must:
a. Identify the hazardous materials by names and stock numbers; the affected system components and processes; the
quantity, characteristics, and concentrations of the materials in the system; and source documents relating to the
materials.
b. Determine under which conditions the hazardous materials can release or emit materials in a form that may be inhaled,
ingested, absorbed by living organisms, or leached into the environment and if the materials pose a health threat.
c. Characterize material hazards and determine reference quantities and hazard ratings. Acute health, chronic health,
carcinogenic, contact, flammability, and reactivity hazards should be examined.
d. Estimate the expected usage rate of each hazardous material for each process or component for the subsystem, total
system, and program-wide impact.
e. Recommend the disposition of each hazardous material identified. If, for any scale of operation, the reference quantity
is exceeded by the estimated usage rate, material substitution or altered processes should be considered to reduce
risks associated with the material hazards while evaluating the impact on program costs.
207.2.3 Report Requirements
The Developer should prepare a report that contains the results from the work task described by paragraph 207.2 above to
include the following information (which is defined in Appendix C, TDD-207):
207.2.3.1 References
A list of source materials used in preparing the report. Include for example, contractor reports, standards, criteria, technical
manuals and specifications. If references are numerous, put them in a bibliography as an appendix.
207.2.3.2 System description
A brief identification of the system and its purpose. Address significant health hazard issues that are identified later in the
report.
207.2.3.3 Background
A description of the system and its intended operation. Include pertinent components or subsystems which contribute most
to a health hazard. The identity of the intended users and the type of protective clothing and equipment, if any, available to
the user. A summary of the evaluations or assessments performed on system prototypes or developmental models.
207.2.3.4 Identification of Health Hazard Issues
A description and discussion of each potential or actual health hazard issue of concern for each subsystem or component.
207.2.3.4.1 System Breakout
Use subparagraphs for each subsystem or component, with additional subparagraphs for each health hazard discussion.
Include sufficient detail to clearly define the specific problem, issue involved, and reasoning behind the analyses.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 77 of 1 04
207.2.3.4.2 Material Information
For each proposed and alternative material, include the following:
a. Material identification. Include material identity; common or trade name; chemical name; chemical abstract service
number; national stock number, or local stock number; physical form (solid, liquid, gas); and manufacturers and
suppliers.
b. Material use and quantity. Include component name, description, and code, and/or operations details for the material.
Total system and program, life-cycle quantities to be used. For mixtures, concentrations for each ingredient.
c. Hazard identification. The detrimental effects of the material on the system, personnel, environment, or facilities.
d. Toxicity assessment. A description of the expected frequency, duration, and amount of exposure. Include the reference
documentation and methods used to determine potency/toxicity assessment factors and calculations.
e. Risk calculations. Include classification of severity and probability of occurrence, acceptable levels of risk, any missing
information, and discussions of uncertainties in data or calculations.
f. Material substitutions. Discuss the rationale for using a hazardous material and long-term effects (such as potential for
personnel exposure, handling and disposal issues/requirements, protection/control measures, and life-cycle costs) over
a non or less hazardous material. The effects and costs should be considered over the life of the systems, including the
cost of handling and disposal. Identify potential non or less hazardous alternatives if they exist and provide a justification
why an alternative cannot be used.
207.2.3.4.3 Description of Physical Agent Stressors
Description of physical agents such as noise, vibration, ionizing and non-ionizing radiation, and temperature (heat/cold)
stressors should describe the intensity, location, affected operations, and, if feasible duration, of human exposures. A
diagram or map illustrating the location, field intensity and other relevant details should be provided. Where feasible, the
intensity of the power source, such as sound power in watts, should be calculated and reported. The presence and effect
of control measures, such as vibration isolation, acoustic insulation and barriers should be described.
207.2.3.5 Assessment of Health Hazard Issues
Include an analysis of data, observations, findings, reports, and other sources of information against health standards and
criteria. Include a discussion of the potential effect of the health hazards identified. Include an assessment of the risk of the
health hazards based on mishap severity and mishap probability. Indicate when the hazards may be expected under normal
or unusual operating or maintenance conditions.
207.2.3.6 Recommendations
Include a description of the system, facility, and personnel protective equipment design requirements (e.g., ventilation, noise
attenuation, radiation barriers, etc.) to allow operation and maintenance with mishap risk as low as reasonably practicable.
Specify the recommended actions that should be taken to eliminate, reduce, or control each actual or potential health hazard
described. Include a description of the effects that each action may have on the risk of the health hazards.
207.2.3.7 Summary
Include a summary of the major recommendations.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 78 of 1 04
207.3 Details to be Specified
Details to be specified in the SOW should include the following as applicable:
(R) a. Imposition of Tasks 1 01 and 207.
(R) b. Minimum mishap severity and probability reporting thresholds.
c. Any selected hazards, hazardous areas, hazardous materials, or other specific items to be examined or
excluded.
d. Specification of desired analysis techniques and/or report formats.
Task 208 - Functional Hazard Analysis (FHA)

208.1 Purpose

The purpose of Task 208 is to perform and document a functional hazard analysis (FHA) of an individual system or a
physical element of a system of systems. The FHA is used to identify and classify the system functions and the safety
consequences of functional failure or malfunction. These consequences should be classified in terms of mishap severity for
the purpose of identifying the safety critical functions (SCF), safety critical items (SCI), and safety significant items (SSI) of
the system. SCFs, SCIs and SSIs should be allocated or mapped to the system design architecture in terms of hardware,
software, and/or human interfaces to the system. The FHA should be accomplished as soon as possible in the acquisition
life cycle to enable the safety engineer to quickly account for the physical and functional elements of the system for hazard
analysis purposes, identifying and documenting SCFs, SCIs, and SSIs, allocating and partitioning SCFs in the software
design architecture, and identifying safety requirements and constraints to the design team.
208.2 Task Description

The Developer should perform and document an FHA to obtain an initial safety assessment of a concept or system.
Functions associated with the proposed functional or physical design should be analyzed based on the best available data,
including mishap data (if assessable) from similar systems and other lessons learned. This should include inputs, outputs,
critical interfaces, consequence of functional failure, and the mishap severity assessment for each consequence. Safety
requirements and safety constraints needed to mitigate the mishap risk to a level as low as reasonably practicable as
determined by the risk acceptance authority should be included. The format and content requirements are defined in
Appendix C, TDD-208. The FHA should consider the following to identify and evaluate functions within a system:
a. Hardware components (the physical decomposition of the system and its related subsystems to the major component
level). Note: Hardware decomposition identifies a great majority of the system’s functionality. However, once the
hardware is accounted for, software “managers” (i.e., software dedicated to managing particular features of a system,
such as weapons managers, device managers, display managers, bus managers, et al.) would need to be identified to
account for the functionality missed in the hardware assessment.
b. Functional description of each physical subsystem and component identified. Each physical subsystem and component
should possess one or more functional attributes.
c. Critical interfaces between physical subsystems and components. Interfaces should be assessed in terms of both
physical connectivity and functional inputs and outputs.
d. Functional description of interfaces between subsystems and components.
e. The safety consequences of loss of function, degraded function or malfunction, or functioning out of time or out of
sequence, for the physical subsystems, components, and their interfaces. In a manner similar to a failure modes and
effects analysis (FMEA), the list of safety ramifications should consider the next effect in a possible mishap sequence
and possibly the final mishap outcome.
f. An assessment of the mishap severity of the outcome associated with each identified failure of a function, subsystem,
or component, in terms of the mishap severity categories defined in the system safety program plan (SSPP). Note:
There is no assessment of mishap probability for the analysis at this time. Probability assessments can be added later.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 79 of 1 04
g. Identification of functions that, if performed incorrectly, performed out-of-sequence, or not performed, could result in a
mishap as defined by the Managing Authority (by definition, safety critical functions). Note: Physical items or system
functions with assessed mishap severities of marginal or negligible are considered “safety significant.” Hardware and
software supporting safety critical functions are normally identified as safety significant. The use of SCI and SSI terms
is useful for traceability purposes within the design architecture as well as assisting in the identification of systems
engineering requirements.
h. Assessment of whether the functions identified are to be implemented in the design hardware, software, or human
control interfaces. This assessment should “map” each function to its implementing hardware or software components.
Functions allocated to software should be mapped to the lowest level of technical design or configuration item prior to
coding: for example, implementing modules or use-cases.
i. Assessment of software control category (SCC) and software criticality index for each safety critical function mapped to
the software design architecture.
j. List of safety requirements and/or safety constraints for the design team (to be included in the specifications) that, when
successfully implemented, would reduce the likelihood of mishap occurrence for hazards later identified in the PHA,
SSHA, SHA, O&SHA and HHA. These requirements should be in the form of hazard mitigation, fault tolerance,
detection, isolation, annunciation, and/or recovery.
208.3 Details to be Specified
The Developer should prepare a report that contains the results from the work task described by paragraph 208.2 above to
include the following information:
208.3.1 System description
A system description is usually not required for an FHA as this information would be required in the delivery of a PHA, SHA
or SAR. If these deliverables are not required, a system description is warranted for the FHA. The system description should
consist of summary descriptions of the physical and functional characteristics of the system and its components. Reference
to more detailed system and component descriptions, including specifications and detailed review documentation can be
supplied when such documentation is available. The capabilities, limitations, and interdependence of these components
should be expressed in terms relevant to safety. The system and components should be addressed in relation to the
system’s mission and its operational environment. System block diagrams or functional flow diagrams should be used to
clarify system descriptions. Software and its roles should be included in this description.
208.3.2 Results
The FHA should produce as a minimum:
(R) a. A physical and functional decomposition of the system (or system-of-systems). A work breakdown structure
(WBS) format works well to account for all critical subsystems and/or components.
(R) b. A list of system functions.
(R) c. A list of safety critical functions. Note: mission critical functions can easily be identified from the same analysis
where the consequence is identified as “loss of mission capability.”
(R) d. A mapping of SCFs to the hardware and software design architectures. The SCF list and subsequent mapping
should also be used as inputs to reliability, integrity, assurance, and quality planning.
(R) e. An assessment of software control category and software criticality index for SCFs allocated to the software
design.
(R) f. A list of safety requirements and/or constraints of the system, based upon the safety risk ramification of loss of
function or malfunction.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 80 of 1 04
g. The FHA can further produce:
(1 ) A list of preliminary hazards for the PHL/PHA
(2) Inputs to the FMEA
(3) Methods to verify compliance with specific failure conditions or scenarios.
(4) Identification and design status of SCI/SSI interfaces of the system.
(5) Remarks
208.3.3 Completion Criteria
The FHA is “living document” that requires updating as the design matures or changes within the acquisition life cycle. The
generation of the FHA with its subsequent SCF, SCI, and SSI lists is an iterative task that begins prior to preliminary design
review. The document and its subsequent lists are finalized at critical design review but would require updates as changes
are introduced into the system through the configuration change control process.
208.3.4 Reference

SAE ARP 4761 provides guidance for accomplishing a functional hazard assessment (FHA), preliminary system safety
assessment (PSSA), and system safety assessment (SSA) for aircraft-related programs. This guidance is appropriate for
DOD aircraft-related programs or other acquisitions where the tasks of SAE ARP 4761 appear to be prudent alternatives or
tailored supplements to tasks assigned from this document.
Task 209 - Critical Safety Items (CSI) List

209.1 Purpose
The purpose of Task 209 is to identify, document, and track critical safety items.
209.2 Task Description

The Developer should accomplish the following:

a. Develop a list of Safety Critical Functions for the system (if not previously specified).
b. Map (link) Safety Critical Functions to implementing hardware items.
c. Develop a list of hardware Critical Safety Items.
d. Execute Critical Safety Item requirements for technical documentation, markings, and related analyses.
e. Maintain life cycle Critical Safety Item lists and associated information.
209.3 Details to be Specified

Details to be specified in the SOW should include the following, as applicable:

(R) a. Imposition of Tasks 1 01 and 209.
b. List of Safety Critical Functions.
c. Define what systems the Safety Critical Functions encompass.
d. List of hardware Critical Safety Items
e. Identify applicable requirements to fulfill Public Law 1 08-1 36, Task 802.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 81 of 1 04
Task 301 - Safety Assessment
301 .1 Purpose

The purpose of Task 301 is to perform and document a comprehensive evaluation of the mishap risk being assumed prior
to test or operation of a system, prior to the next contract phase or at contract completion.
301 .2 Task Description

301 .2.1 Perform and Document a Safety Assessment

The Developer should perform and document a safety assessment to identify all safety features of the hardware, software,
and system design and to identify procedural, hardware and software related hazards that may be present in the system
being acquired including specific procedural controls and precautions that should be followed. The Developer should identify
hazardous materials that would be used in the design, operation, or maintenance of the system or would be generated by
the system, and assess why a non or less hazardous material could not be used.
301 .2.2 Report Requirements

The Developer should prepare a Safety Assessment Report (SAR) that contains the results from the work task described
by paragraph 301 .2 above to include the following information (which is defined in Appendix C, TDD-301 ):
a. The safety criteria and methodology used to classify and rank hazards, plus any assumptions on which the criteria or
methodologies were based or derived, including the definition of acceptable risk as specified by the Managing Authority.
b. The results of analyses and tests performed to identify hazards inherent in the system, including:
(1 ) Those hazards that still have a mishap risk, and the actions that have been taken to reduce the associated risk to
a level contractually specified as acceptable.
(2) Results of tests conducted to validate safety criteria, requirements and analyses.
c. The results of the safety program efforts. Include a list of all significant hazards along with specific safety
recommendations or precautions required to ensure safety of personnel, property, or the environment. Categorize the
list of hazards as to whether or not they may be expected under normal or abnormal operating conditions.
d. Any hazardous materials generated by or used in the system, including:
(1 ) Identification of material type, quantity, and potential hazards.
(2) Safety precautions and procedures necessary during use, packaging, handling, storage, transportation, and
disposal (e.g., explosive ordnance disposal). Include all explosives hazard classifications.
(3) After-launch safety-related activity of expendable launch vehicles and their payloads including deployment,
operation, reentry, and recovery (if required) of launch vehicles/payloads that do not attain orbit (either planned or
unplanned).
(4) Orbital safety hazard awareness associated with space systems such as explosions, electromagnetic interference,
radioactive sources, ionizing radiation, chemicals, space debris, separation distances between space vehicles, and
natural phenomena.
(5) A copy of the Safety Data Sheet (OSHA form, or equivalent manufacturer’s format).
e. Conclude with a signed statement that all identified hazards have been eliminated or their associated risks controlled
to levels contractually specified as acceptable, and that the system is ready to test or operate or proceed to the next
acquisition phase. In addition, the Developer should make recommendations applicable to hazards at the interface of
his system with the other systems as contractually required.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 82 of 1 04
301 .2.3 References
A list of all pertinent references such as test reports, preliminary operating manuals and maintenance manuals.
301 .3 Details to be Specified

Details to be specified in the SOW should include the following, as applicable:

(R) a. Imposition of Tasks 1 01 and 301 .
b. Define the specific purpose of the requested assessment.
c. Identify at what level (system safety manager, PM, etc.) the statement (paragraph 301 .2e) should be signed.
Task 302 - Test and Evaluation Safety

302.1 Purpose

The purpose of Task 302 is to make sure that safety is considered (and safety responsibility assigned) in test and evaluation,
to provide existing analysis reports and other safety data, and to respond to all safety requirements necessary for testing
in-house, at other Developer facilities, and at Managing Authority/Government ranges, centers, or laboratories.
302.2 Task Description
The Developer should make sure that the test and evaluation safety activities recommend actions and assess actions taken
to eliminate or mitigate hazards in the test and evaluation environment that could result in an mishap as defined by the
Managing Authority. Hazards capable of causing mishaps should also be addressed as required by the Managing Authority.
302.2.1 Test and Evaluation Planning

Specific test and evaluation safety activities should include planning for test and evaluation safety from the beginning of,
and throughout, the contract period and should incorporate the following:
a. Test program milestones requiring completion of hazard analyses, risk assessments, or other safety studies.
b. Schedule for analysis, evaluation, and approval of test plans, procedures, and other documents to make sure safety is
covered during all testing.
c. Preparation of or input to safety, operating and test procedures.
d. Coverage of test equipment, installation of test equipment, and instrumentation in hazard analyses prior to test start.
e. Meeting specialized requirements designated by the Managing Authority and informing the Managing Authority of any
identified hazards that are unique to the test environment.
f. Coordination and status reviews with the cognizant test site safety representatives to ensure test safety requirements
are identified, monitored and completed as scheduled.
302.2.2 Safety Reviews

Provide assistance to the safety review teams to the extent necessary to support a system safety certification process and
validate, from a safety perspective that the system is ready to test.
302.2.3 Follow-up Actions

a. Analyze and document safety related test results.

b. Initiate follow-up action to ensure completion of the corrective efforts taken to reduce, correct, or control test and
evaluation hazards.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 83 of 1 04
302.2.4 Reports
Maintain a repository of test and evaluation hazard/action status reports.
302.3 Details to be Specified

Details to be specified in the SOW should include the following, as applicable:

(R) a. Imposition of Tasks 1 01 and 302.
(R) b. Designation of applicable specialized system safety requirements for testing or use of range facilities.
(R) c. Schedule for meeting requirements designated in 302.2 above.
d. Identification of hazard categories for which test and evaluation safety activities would take action.
Task 303 - Safety Review of Engineering Change Proposals, Specification Change Notices, Software Problem
Reports, and Requests for Deviation/Waiver

303.1 Purpose

The purpose of Task 303 is to perform and document analyses of Engineering Change Proposals (ECPs), Specification
Change Notices (SCNs), Software Problem Reports (SPRs), program or software trouble reports (PTRs, STRs), and
requests for deviation or waiver to determine the safety impact on the system.
303.2 Task Description

303.2.1 Engineering Change Proposals

The Developer should analyze each ECP (as specified by the Managing Authority) to determine the hazards associated
with it, assess the associated risk, and predict the safety impact of the ECP on the existing system. The Developer should
notify the Managing Authority when an ECP would decrease the level of safety of the existing system.
303.2.2 Specification Change Notices

The Developer should analyze each SCN to determine the potential effect on safety critical components or subsystems.
The Developer should notify the Managing Authority if the level of safety of the system would be reduced.
303.2.3 Software Problem Reports

The Developer should review each SPR to determine the potential safety implications. If negative safety impacts are
identified, the Developer should notify the Managing Authority of a decrease in the level of safety of the system.
303.2.4 Requests for Deviation/Waiver

The Developer should analyze each request for deviation/waiver to determine the hazards and assess the risk of the
proposed deviation from or waiver of a requirement, or a specified method or process. The change in the risk involved in
accepting the deviation or waiver should be identified. When the level of safety of the system would be reduced by deviation
from, or waiver of, the requirement, method, or process, the Managing Authority should be so notified.
303.2.5 Report Requirements

The Developer should prepare a report that describes the results of the work task described in paragraph 303.2 above. The
format of the report should be Developer-selected.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 84 of 1 04
303.3 Details to be Specified
Details to be specified in the SOW should include the following, as applicable:
(R) a. Imposition of Tasks 1 01 and 303.
b. Specify amount of change in the level of safety requiring Managing Authority notification and the method and
timing of such notification.
c. Identify class of ECP or type of deviation/waiver to which this task applies.
d. Identify who executes review and sign-off authority for each class of ECP or type of deviation/waiver.
Task 401 - Safety Verification

401 .1 Purpose

The purpose of Task 401 is to define and perform tests and demonstrations or use other verification methods on safety
critical hardware, software, and procedures to verify compliance with safety requirements.
401 .2 Task Description.

401 .2.1 System Compliance with Safety Requirements

The Developer should define and perform tests, demonstrations, develop models, and otherwise verify the compliance of
the system with safety requirements on safety critical hardware, software, and procedures (e.g., EOD and emergency
procedures). Induced or simulated failures should be considered to demonstrate the acceptable safety performance of the
equipment and software. Where hazards are identified during the development efforts and analysis or inspection cannot
determine the adequacy of actions taken to reduce the risk, safety tests should be specified and conducted to evaluate the
overall effectiveness of the actions taken. SSPPs (Task 1 02) and test plan and procedure documents should be revised to
include these tests. Where costs for safety testing would be prohibitive, safety characteristics or procedures may be verified
by engineering analyses, analogy, laboratory test, functional mockups, or models and simulations, when approved by the
Managing Authority. Specific safety tests should be integrated into appropriate system test and demonstration plans,
including verification and validation plans, to the maximum extent possible. Test plans, test procedures, and the results of
all tests including design verification, technical operational evaluation, technical data and requirements validation and
verification, production acceptance, and shelf-life validation should be reviewed to make sure:
a. Safety of the design (including operating and maintenance procedures) is adequately demonstrated, including
verification of safety devices, warning devices, etc. for all hazards which could result in mishaps as defined by the
Managing Authority and not eliminated by design. Hazards of lower severity should also be addressed as required by
the Managing Authority.
b. Results of safety evaluations of the system are included in the test and evaluation reports on hardware or software.
401 .2.2 Report Requirements

The Developer should prepare a Safety Assessment Report (SAR) that contains the results from the work task described
by paragraph 401 .2 above to include the following information:
a. An identification of the test procedures that were conducted to verify or demonstrate compliance with the safety
requirements on safety critical hardware, software, and procedures (e.g., EOD and emergency procedures). When
costs for safety testing would have been prohibitive, and alternate means of verification were approved by the Managing
Authority, the safety characteristics or procedures that were verified by engineering analyses, analogy, laboratory test,
functional mockups, or models and simulations should be identified, and a summary of the results provided.
b. Identification of those test and evaluation reports that contain the results of the safety evaluations with a summary of
the results provided.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 85 of 1 04
401 .3 Details to be Specified
Details to be specified in the SOW should include the following, as applicable:
(R) a. Imposition of Tasks 1 01 and 401 .
(R) b. Identification of safety critical equipment and procedures.
(R) c. Identification of hazard categories for which verification should be accomplished if paragraph 401 .2a is
specified.
d. Additional development of or inputs to test plans, procedures and reports to verify safety requirements.
Task 402 - Safety Compliance Assessment

402.1 Purpose

The purpose of Task 402 is to perform and document an assessment to identify and verify compliance with military, federal,
national, international, and industry codes to ensure design of a system whose mishap risk is as low as reasonably
practicable, and to comprehensively evaluate the mishap risk being assumed prior to test or operation of a system or at
contract completion.
402.2 Task Description

402.2.1 Safety Compliance Assessment

The Developer should perform and document a safety compliance assessment to identify and document compliance with
appropriate design and operational safety requirements. The assessment identifies the contractually imposed standards,
specifications, and codes appropriate to the safety of the system and documents compliance with these requirements. The
assessment includes necessary hazard analysis, design drawing and procedural reviews, and equipment inspections. The
assessment should incorporate the scope and techniques of the PHA, RHA, SSHA, SHA, and O&SHA to the extent
necessary to assure that the design, operation, maintenance, and support of the system has mishap risk as low as
reasonably practicable. A safety compliance assessment must:
a. Identify contractual military, federal, national, international, and industry safety specifications, standards, and codes
applicable to the system and document compliance of the design and procedures with these requirements.
b. Identify other military, federal, national, international, and industry safety specifications, standards, and codes applicable
to the system, which are required by law or the use thereof is considered good engineering practice, and document
compliance of the design and procedures with these requirements.
c. Identify and evaluate mishap hazards inherent in the system or that arise from system-unique interfaces, installation,
test, operation, maintenance, or support.
d. Identify necessary specialized safety design features, devices, procedures, skills, training, facilities, support
requirements, and personnel protective equipment.
e. Identify hazardous materials and provide justification for using such a material instead of a less or nonhazardous
material, and the precautions and procedures necessary for ensuring that the mishap risk of storage, handling, transport,
use, and disposal of the material is as low as reasonably practicable.
402.2.2 Data

The Developer should prepare a Safety Assessment Report (SAR) to include the following information:
a. A listing of the hazards identified in the system with a cross reference to the identified document that contains the safety
criteria to be used to reduce or eliminate the hazard.
b. A listing of the unique hazards for which there are no identified safety requirements, together with the approach the
Developer would take to minimize the hazard.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 86 of 1 04
c. A list of all specialized safety design features and devices.
d. Document the safety requirements that have been identified that relate to procedures, skills, training, facilities, support
requirements, and personnel protective equipment.
e. For all hazardous materials generated by or used in the system, the following information should be included.
(1 ) Material identification as to type, quantity, and potential hazards.
(2) Rationale of why the hazardous material is being used in lieu of a less or nonhazardous material.
(3) Safety precautions and procedures necessary during use, storage, transportation, and disposal.
(4) A copy of the Safety Data Sheet (OSHA Form or equivalent manufacturer’s format).
402.3 Details to be Specified
Details to be specified in the SOW should include the following, as applicable:
(R) a. Imposition of Tasks 1 01 and 402.
b. Identify applicable requirements.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 87 of 1 04
APPENDIX C– TASK DATA DESCRIPTIONS
C.1 SCOPE
This appendix provides task data descriptions (TDDs) associated with the data delivery products generated for the system
safety tasks. Not all tasks have an associated TDD.
C.2 TDD STRUCTURE
The TDDs contain format and content requirements.
Number: TDD-1 02
Title: System Safety Program Plan (SSPP)

Approval Date: August 201 4

Use/Relationship:

This plan details the tasks and activities of system safety management and system safety engineering required to identify,
evaluate, and eliminate or control hazards throughout the life cycle of the system. The System Safety Program Plan
describes fully the planned safety tasks and activities required to meet the System Safety Program requirements. This Task
Data Description (TDD) contains the format and content preparation instructions for the data product generated by the
specific and discrete task required as delineated in the contract.
Other Task Data Descriptions which relate to this TDD are: TDD-1 06, Hazard Tracking System and TDD-301 , Safety
Assessment Report.
Requirements:
1 . Format. The System Safety Program Plan (SSPP) should be presented in the Developer’s format.
2. Content. The System Safety Program Plan should contain the following:
a. System Safety Organization. The plan should describe:
(1 ) The system safety organization or function within the organization of the total program using charts to show
the organizational and functional relationships, and lines of communication.
(2) The responsibility, authority, and accountability of system safety personnel, other developer organizational
elements involved in the system safety effort, subdevelopers, and system safety groups. Identify the
organizational unit responsible for executing each task. Identify the authority in regard to resolution of all
identified hazards. Include the name, address, and telephone number of the lead System Safety Engineer.
(3) The staffing of the system safety organization for the duration of the contract to include manpower loading
and the qualifications of assigned key personnel.
(4) The process through which developer management decisions would be made to include notification of critical
and catastrophic hazards, corrective action taken, mishaps or malfunctions, waivers to safety requirements,
and program deviations.
b. System Safety Program Milestones. The plan shall:
(1 ) Identify safety milestones so that evaluations of the effectiveness of the system safety effort can be made at
Quarterly Program Reviews.
(2) Provide a program schedule of safety tasks showing start and completion dates, reports, reviews, and man
loading, in relationship to other program milestones.
(3) Identify integrated system activities (i.e., design analyses, tests, and demonstrations) applicable to the
System Safety Program but specified in other engineering studies to preclude duplication. Included as a part
of this section should be the estimated manpower loading required to do these activities.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 88 of 1 04
c. System Safety Requirements. The plan shall:
(1 ) Describe or reference the methods that would be used to identify and apply safety/hazard control. List the
safety standards and system specifications that are the sources of safety requirements with which the
developer is required to comply and any others he/she intends to use.
(2) Describe the risk assessment procedures. The hazard severity categories, hazard probability levels, and the
system safety precedence to be followed in satisfying safety requirements should be in accordance with
GEIA-STD-001 0A.
(3) Describe the integration of subdeveloper equipment safety information.
d. Hazard Analysis. The plan should describe:
(1 ) The analysis technique and format that would be used in qualitative and quantitative analysis to identify
hazards, their causes and effects, and recommended corrective action.
(2) The depth within the system to which each analysis technique would be used including hazard identification
associated with the system, subsystem, components, personnel, ground support equipment, government
furnished equipment, facilities, and their interrelationship in the logistics support, training, maintenance,
transportability, and operational environments.
(3) The technique for establishing a single closed-loop hazard tracking system.
e. Safety Data.
(1 ) Describe the approach for collecting and processing pertinent historical hazard, mishap, and safety lessons
learned data.
(2) Identify deliverable data by title and number, and means of delivery (e.g., hard copy, electronically, etc.)
(3) Identify non-deliverable system safety data and describe the procedures for accessibility by the Managing
Authority and retention of data of historical value.
f. Safety Verification. The plan should describe:
(1 ) The verification requirements for ensuring that safety is adequately demonstrated by analysis, inspection,
simulation, or test.
(2) The review procedures established by the system safety organization to ensure safe conduct of all tests.
g. Audit Program. The plan should describe the techniques and procedures to be employed by the contractor to
make sure that the objectives and requirements of the system safety program are being accomplished.
h. Training. Describe techniques and procedures to be used by the developer to ensure that the objectives and
requirements of the System Safety Program are met in the safety training for engineers, technicians, operating
and maintenance personnel.
i. Incident Reporting and Investigation. The plan should describe the mishap and hazardous malfunction analysis
process for mishaps prior to delivery of the craft.
j. System Safety Interfaces. The plan should identify, as addenda, the interface between system safety and all other
applicable disciplines, such as maintainability, quality assurance, reliability, human factors engineering,
transportability engineering, and medical support (health hazard assessments).
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 89 of 1 04
Number: TDD-1 06
Title: Hazard Tracking System

Approval Date: August 201 4

Use/Relationship:

System safety includes identification of the hazards associated with a system. Hazard Tracking and risk resolution are
accomplished with a single, closed-loop method or procedure that provides an audit trail of hazard resolutions throughout
the life cycle of the system. A centralized file, computer database, or document called a “Hazard Log” should be maintained.
This Task Data Description (TDD) contains the format and content preparation instructions for the data product generated
by the specific and discrete task required as delineated in the contract.
Other Task Data Descriptions which relate to this TDD are: TDD 1 02, System Safety Program Plan; TDD-202, Preliminary
Hazard Analysis Report; TDD-204, Subsystem Hazard Analysis Report; TDD-205 System Hazard Analysis Report; TDD-
206, Operating and Support Hazard Analysis Report; TDD-207, Health Hazard Assessment Report; and TDD-301 , Safety
Assessment Report.
Requirements:
1 . Format. Acceptable formats are noted below:
a. Standalone tracking mechanism using spreadsheet or word processing software such as Excel®, Word®, etc.
b. Database tracking mechanism using database software such as Access®, etc.
c. Web-based tracking which is hosted for multiple locations and users
2. Content. The HTS should contain the following:
a. Program Identifier
b. Hazard Log ID
c. Revision history (last update)
d. Responsible person (point of contract)
e. Description of each hazard (in terms of source, mechanism, and outcome)
f. Applicable mission phase(s)
g. Identification of explosive or prohibited material usage
h. Identification of hazard controls--the recommended controls to reduce the hazard to a level of risk acceptable to the
Managing Authority.
i. Status of each hazard and control
j. System requirement or derived requirement
k. Identification of mishap risk assessment (Initial RAC and Final RAC)
l. Identification of software level of rigor (LOR)/Development Assurance Level (DAL)
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 90 of 1 04
m. Action items (description and assignment)
n. Reference documents (safety documents, other hazard logs, etc.)
o. Recommendations from working groups or other review meetings
p. Signature of the Managing Authority accepting the risk and thus accepting closure of the Hazard Log item.
Number: TDD-1 07

Title: System Safety Program Progress Report (SSPPR)

Approval Date: August 201 4

Use/Relationship:

The SSPPR can be used to cover periodic reviews of safety activities and to monitor progress of developer system safety
efforts. This Task Data Description (TDD) contains the format and content preparation instructions for the data product
generated by the specific and discrete task requirements as delineated in the contract.
Other Task Data Descriptions which relate to this TDD are: TDD-204, Subsystem Hazard Analysis Report; TDD-205,
System Hazard Analysis Report; TDD-207, Health Hazard Assessment Report; TDD-301 , Safety Assessment Report; and
TDD-303, Engineering Change Proposal, Problem Report, and Deviation/Waiver System Safety Report.
Requirements:

1 . Format. The System Safety Program Progress Report should be presented in the Developer’s format.
2. Contents. The SSPPR should include a description of the general progress made relative to the System Safety Program
during the reporting period and the projected work for the next reporting period. The report should contain the following
information in narrative format:
a. A brief summary of activities, progress, and status of the safety effort. It should highlight significant achievements
and problems. It should include progress toward completion of safety data products prepared or in work.
b. Newly recognized significant hazards and significant changes in the degree of control on known hazards.
c. Individual hazard resolution status and status of all recommended corrective actions that have not been
implemented.
d. Significant cost and schedule changes that impact the System Safety Program.
e. Discussion of documents reviewed by System Safety during the reporting period. Indicate whether they were
acceptable for safety content and whether or not inputs to improve the safety posture were made.
f. Proposed agenda for future system safety meeting(s).
g. Minutes of previous system safety meeting.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 91 of 1 04
Number: TDD-202
Title: Preliminary Hazard Analysis (PHA) Report (PHAR)

Approval Date: August 201 4

Use/Relationship:

The Preliminary Hazard Analysis Report should document the results of the Preliminary Hazard Analysis (PHA). It should
be used to identify safety critical areas, to provide an initial assessment of hazards and to identify requisite hazard controls
and follow-on actions. The hazard analysis should be based on the best available data and usually begins from a Preliminary
Hazard List (PHL). It should include mishap data (if assessable) from similar system(s) and other lessons learned. Hazards
associated with the proposed design or function should be evaluated for mishap severity, mishap probability, and operational
constraints. This Task Data Description (TDD) contains the content and format preparation instructions for the data product
generated by the specific and discrete task requirement as delineated in the contract.
Other Task Data Descriptions which relate to this TDD are: TDD-1 07, System Safety Program Progress Report; TDD-204,
Subsystem Hazard Analysis Report; TDD-205 System Hazard Analysis Report; TDD-207, Health Hazard Assessment
Report; TDD-301 , Safety Assessment Report; and TDD-303, Engineering Change Proposal, Problem Report, and
Deviation/Waiver System Safety Report.
Requirements:

1 . Format. The Preliminary Hazard Analysis Report should be presented in the Developer’s format.
2. Contents. Hazard analysis reports should contain the following:
a. System description. This should consist of summary descriptions of the physical and functional characteristics of
the system and its components. Reference to more detailed system and component descriptions, including
specifications and detailed review documentation should be supplied when such documentation is available. The
capabilities, limitations and interdependence of these components should be expressed in terms relevant to safety.
The system and components should be addressed in relation to its mission and its operational environment. System
block diagrams or functional flow diagrams may be used to clarify system descriptions. Software and its role(s)
should be included in this description.
b. Data. This should consist of summaries of data used to determine the safety aspects of design features.
c. Hazard analysis results. This should consist of a summary or a total listing of the results of hazard analysis. The
following are the content and format requirements:
(1 ) A listing of identified hazards, in narrative or matrix (sometimes called columnar or tabular) format, to include
the following information:
(a) System/subsystem/unit. The particular part of the system that this analysis is concerned with. For example, if
this item(s) applies to a radar system modulator, use "modulator." If there are several modulators in the system,
be sure to clearly specify which one the analysis pertains to.
(b) System event(s) phase. The configuration or phase of the mission the system is in when the hazard is
encountered; for example, during maintenance, during flight, during pre-flight, full-power applied, etc., or it could
be encountered in all system events.
(c) Hazard description. A brief description, in terms of source/mechanism/outcome, of the hazard or hazardous
material; for example, "Radiation leakage from radar set waveguide harming nearby personnel."
(d) Effect of hazard. The detrimental effects which could be inflicted on the subsystem, system, other equipment,
facilities or personnel, resulting from this hazard. Possible upstream and downstream effects should also be
described.
(e) Risk assessment. A risk assessment for each hazard (classification of severity and probability of occurrence).
This is the assessment of the risk prior to taking any action to eliminate or control the hazard.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 92 of 1 04
(f) Recommended action. The recommended action required to eliminate or control the hazard. Sufficient technical
detail is required in order to permit the design engineers to adequately develop and assess design criteria
resulting from the analysis. Include alternative designs and life cycle cost impact where appropriate.
(g) Effect of recommended action. The effect of the recommended action on the assigned risk assessment. This is
the risk assessment after taking action to eliminate or control each hazard. If the recommended action would
result in cost/schedule/performance penalties to the extent that the developer requires approval prior to
incorporation, then these considerations should be addressed.
(h) Remarks. Any information relating to the hazard not covered in other blocks; for example, applicable
documents, previous failure data on similar systems, or administrative directions.
(i) Status. The status of actions to implement the recommended, or other, hazard controls. The status should
include not only an indication of "open" or "closed," but also reference to the drawing(s), specification(s),
procedure(s), etc., that support closure of the particular hazard.
Number: TDD-203
Title: Safety Requirements/Criteria Analysis Report

Approval Date: August 201 4

Use/Relationship:

This report should be used to document the safety design requirements/design criteria for a facility or system under
development/design. The SR/CA relates the hazards identified to the system design and identifies or develops requirements
to eliminate or reduce the risk of the identified hazards to an acceptable level. This task description provides a means to
ensure hazards have corresponding safety requirements identified and identify the need for derived requirements and/or
new requirements. This Task Data Description (TDD) contains the format and content preparation instructions for the data
product generated by the specific and discrete task requirement as delineated in the contract.
Other Task Data Descriptions which relate to this TDD are: TDD-202, Preliminary Hazard Analysis Report; TDD-204,
System Hazard Analysis Report; TDD-205, Subsystem Hazard Analysis Report; TDD-1 06, Hazard Tracking System; TDD-
301 , Safety Assessment Report; and TDD-303, Engineering Change Proposal, Problem Report, and Deviation/Waiver
System Safety Report.
Requirements:

1 . Format. The Safety Requirements/Criteria Analysis Report should be presented in the Developer’s format.
2. Contents. The Safety Requirements Design/Criteria Analysis Report should contain the following:
a. System description. This should consist of summary descriptions of the physical and functional characteristics of
the system and its components. Reference to more detailed system and component descriptions, including
specifications and detailed review documentation should be supplied when such documentation is available. The
capabilities, limitations and interdependence of these components should be expressed in terms relevant to safety.
The system and components should be addressed in relation to the mission and operational environment. System
block diagrams or functional flow diagrams may be used to clarify system descriptions. Software and its role(s)
should be included in this description.
b. Generic System Safety Design Requirements and Guidelines. This should be a list of the applicable generic system
safety design requirements and guidelines for facilities; hardware and software from federal, military, national and
industry regulations, codes, standards, specifications; and other documents for the system under development that
have been determined to be applicable.
c. Unique System Safety Design Requirements and Guidelines. This should be a list of the applicable unique system
safety design requirements and guidelines required for the system under development that are not covered by the
generic system safety design requirements.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 93 of 1 04
d. Identification of Manuals. This should be a table that provides the required implementation of the Generic and
Unique System Safety Design Requirements into the operator, user, and/or diagnostic manuals.
e. Data. This should consist of summaries of data used to determine the safety aspects of design features.
f. Identification of Safety Critical Functions and Interfaces. This should be a list or table that identifies the safety
critical functions, safety critical interfaces (from control function, monitoring function, safety systems, etc.), and the
correlating Safety Critical Computer Software Components (SCCSCs).
g. Hazard analysis results. This should consist of a summary or a total listing of the results of hazard analysis. The
following are the content and format requirements:
(1 ) Hazards. A summary of the identified hazards including a description of the hazard (in terms of source,
mechanism, and outcome).
(2) Recommended action.
i. The recommended action required to eliminate or control the hazard. Sufficient technical detail is required
in order to permit the design engineers to adequately develop and assess design criteria resulting from the
analysis. Include alternative designs and life cycle cost impact where appropriate.
ii. Identification of Safety related design change recommendations. Develop safety-related change
recommendations to the design and specification documents which include a means of verification for each
recommended design requirement. New safety-related test requirements should also be incorporated into
the test documents.
(3) Trace. Identification of the specifications or design documents that contain the requirements relating to the
hazard.
Number: TDD-204

Title: Subsystem Hazard Analysis Report (SSHAR)

Approval Date: August 201 4

Use/Relationship:
Hazard Analyses are used to systematically identify and evaluate hazards, both real and potential, for their elimination or
control. The Subsystem Hazard Analysis identifies hazards associated with the design of subsystems including component
failure mode, critical human error inputs, and hazards resulting from functional relationships between components and
equipment comprising each subsystem. This analysis should include furnished equipment, non-developmental items, and
software. Areas to consider are performance, performance degradation, functional failures, timing errors, design errors or
defects, or inadvertent function. The human should be considered a component within a subsystem, receiving both inputs
and initiating outputs, during the conduct of this analysis. The Subsystem Hazard Analysis Report documents these hazard
analyses. This Task Data Description (TDD) contains the content and format preparation instructions for the data product
generated by the specific and discrete task requirement as delineated in the contract.
Other Task Data Descriptions which relate to this TDD are: TDD-1 06, Hazard Tracking System; TDD-1 07, System Safety
Program Progress Report; TDD-202, Preliminary Hazard Analysis Report; TDD-205, System Hazard Analysis Report; TDD-
207, Health Hazard Assessment Report; TDD-301 , Safety Assessment Report; and TDD-303, Engineering Change
Proposal, Problem Report, and Deviation/Waiver System Safety Report.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 94 of 1 04
Requirements:
1 . Format. The Subsystem Hazard Analysis Report should be presented in the Developer’s format.
2. Contents. Hazard analysis reports should contain the following:
a. System description. This should consist of summary descriptions of the physical and functional characteristics of
the system and its components. Reference to more detailed system and component descriptions, including
specifications and detailed review documentation should be supplied when such documentation is available. The
capabilities, limitations and interdependence of these components should be expressed in terms relevant to safety.
The system and components should be addressed in relation to its mission and its operational environment. System
block diagrams or functional flow diagrams may be used to clarify system descriptions. Software and its role(s)
should be included in this description.
b. Data. This should consist of summaries of data used to determine the safety aspects of design features.
c. Hazard analysis results. This should consist of a summary or a total listing of the results of hazard analysis. The
following are the content and format requirements:
(1 ) A listing of identified hazards, in narrative or matrix (sometimes called columnar or tabular) format, to include
the following information:
(a) System/subsystem/unit. The particular part of the system that this analysis is concerned with. For example,
if this item(s) applies to a radar system modulator, use "modulator." If there are several modulators in the
system, be sure to clearly specify which one the analysis pertains to.
(b) Component(s) failure mode(s). All component failure modes which can result in a hazard. Failure modes
generally answer the question of "how" it fails.
(c) System event(s) phase. The configuration or phase of the mission the system is in when the hazard is
encountered; for example, during maintenance, during flight, during pre-flight, full-power applied, etc., or it
could be encountered in all system events.
(d) Hazard description. A complete description of the potential/actual hazards inherent in the item being
analyzed, or resulting from normal actions or equipment failure, or handling of hazardous materials.
(e) Hazard identification/indication. A description of operator/crew indications which include all means of
identifying the hazard to operational/maintenance personnel.
(f) Effect of hazard. The detrimental effects which could be inflicted on the subsystem, system, other
equipment, facilities or personnel, resulting from this hazard. Possible upstream and downstream effects
should also be described.
(g) Risk assessment. A risk assessment for each hazard (classification of severity and probability of
occurrence). This is the assessment of the risk prior to taking any action to eliminate or control the hazard.
(h) Recommended action. The recommended action required to eliminate or control the hazard. Sufficient
technical detail is required in order to permit the design engineers to adequately develop and assess design
criteria resulting from the analysis. Include alternative designs and life cycle cost impact where appropriate.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 95 of 1 04
(i) Effect of recommended action. The effect of the recommended action on the assigned risk assessment.
This is the risk assessment after taking action to eliminate or control each hazard. If the recommended
action would result in cost/schedule/performance penalties to the extent that the developer requires
approval prior to incorporation, then these considerations should be addressed.
(j) Remarks. Any information relating to the hazard not covered in other blocks; for example, applicable
documents, previous failure data on similar systems, or administrative directions.
(k) Status. The status of actions to implement the recommended, or other, hazard controls. The status should
include not only an indication of "open" or "closed," but also reference to the drawing(s), specification(s),
procedure(s), etc., that support closure of the particular hazard.
Number: TDD-205

Title: System Hazard Analysis Report (SHAR)

Approval Date: August 201 4

Use/Relationship:
Hazard Analyses are used to systematically identify and evaluate hazards, both real and potential, for their elimination or
control. The System Hazard Analysis identifies hazards associated with the subsystem interfaces and system functional
faults; assess the risk associated with the total system design, including software, and specifically of the subsystem
interfaces; and recommend actions necessary to eliminate identified hazards and/or control their associated risk to
acceptable levels. The System Hazard Analysis Report documents this hazard analysis including total system design,
software, and specifically, the hazards associated with subsystem interfaces. This Task Data Description (TDD) contains
the content and format preparation instructions for the data product generated by the specific and discrete task requirement
as delineated in the contract.
Other Task Data Descriptions which relate to this TDD are: TDD-1 06, Hazard Tracking System; TDD-1 07, System Safety
Program Progress Report; TDD-202, Preliminary Hazard Analysis Report; TDD-204, Subsystem Hazard Analysis Report;
TDD-207, Health Hazard Assessment Report; TDD-301 , Safety Assessment Report; and TDD-303, Engineering Change
Proposal, Problem Report, and Deviation/Waiver System Safety Report.
Requirements:

1 . Format. The System Hazard Analysis Report should be presented in the Developer’s format.
2. Contents. Hazard analysis reports should contain the following:
a. System description. This should consist of summary descriptions of the physical and functional characteristics of
the system and its components. Reference to more detailed system and component descriptions, including
specifications and detailed review documentation should be supplied when such documentation is available. The
capabilities, limitations and interdependence of these components should be expressed in terms relevant to safety.
The system and components should be addressed in relation to their mission and operational environment. System
block diagrams or functional flow diagrams may be used to clarify system descriptions. Software and its role(s)
should be included in this description.
b. Data. This should consist of summaries of data used to determine the safety aspects of design features.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 96 of 1 04
c. Hazard analysis results. This should consist of a summary or a total listing of the results of the hazard analysis. The
following are the content and format requirements:
(1 ) A listing of identified hazards, in narrative or matrix (sometimes called columnar or tabular) format, to include
the following information:
(a) System component/phase. The particular phase/component that the analysis is concerned with. This could
be a system, subsystem, component, software, operating/maintenance procedure or environmental
condition.
(b) System failure modes. The subsystem failure mode descriptions for the SHA are similar to the component
descriptions provided in the SSHA. However, emphasis is now placed on failures affecting interfacing
subsystem operations.
(c) System event(s) phase. The configuration or phase of the mission the system is in when the hazard is
encountered; for example, during maintenance, during flight, during pre-flight, full-power applied, etc., or it
could be encountered in all system events.
(d) Hazard description. A complete description of the potential/actual hazards inherent in the item being
analyzed, or resulting from normal actions or equipment failure, or handling of hazardous materials.
(e) Effect of hazard. The detrimental effects which could be inflicted on the subsystem, system, other
equipment, facilities or personnel, resulting from this hazard. Possible upstream and downstream effects
should also be described.
(f) Risk assessment. A risk assessment for each hazard (classification of severity and probability of
occurrence). This is the assessment of the risk prior to taking any action to eliminate or control the hazard.
(g) Recommended action. The recommended action required to eliminate or control the hazard. Sufficient
technical detail is required in order to permit the design engineers to adequately develop and assess design
criteria resulting from the analysis. Include alternative designs and life cycle cost impact where appropriate.
(h) Effect of recommended action. The effect of the recommended action on the assigned risk assessment.
This is the risk assessment after taking action to eliminate or control each hazard. If the recommended
action would result in cost/schedule/performance penalties to the extent that the developer requires
approval prior to incorporation, then these considerations should be addressed.
(i) Remarks. Any information relating to the hazard not covered in other blocks; for example, applicable
documents, previous failure data on similar systems, or administrative directions.
(j) Status. The status of actions to implement the recommended, or other, hazard controls. The status should
include not only an indication of "open" or "closed," but also reference to the drawing(s), specification(s),
procedure(s), etc., that support closure of the particular hazard.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 97 of 1 04
Number: TDD-206
Title: Operating and Support Hazard Analysis Report (O&SHAR)

Approval Date: August 201 4

Use/Relationship:

The Operating and Support Hazard Analysis Report is used to document the results of the Operating and Support Hazard
Analysis (O&SHA). The O&SHA is used to evaluate activities for hazards or risks introduced into the system by operational
and support procedures and the operational environment. It is also used to evaluate the adequacy of operational and support
procedures used to eliminate, control, or abate identified hazards or risks. The O&SHA should document a system safety
assessment of procedures involved in: system production, deployment, installation, assembly, test, operation, maintenance,
servicing, transportation, storage, modification, demilitarization, and disposal. The OSH&A should produce the system
safety caution and warnings which should be documented in this report and included in procedures or manuals, as
appropriate. This report should be updated whenever the O&SHA is updated as a result of any system design or operational
changes. This Task Data Description (TDD) contains the format and content preparation instructions for the data product
generated by the specific and discrete task required as delineated in the contract.
Other Task Data Descriptions which relate to this TDD are: TDD-1 06, Hazard Tracking System; TDD-208, Functional
Hazard Analysis Report; TDD-301 , Safety Assessment Report; and TDD-303, Engineering Change Proposal, Problem
Report, and Deviation/Waiver System Safety Report.
Requirements:
1 . Format. The Operating and Support Hazard Analysis Report should be presented in the Developer’s format.
2. Contents. Hazard analysis reports should contain the following:
a. System description. This should consist of summary descriptions of the physical and functional characteristics of
the system and its components. Reference to more detailed system and component descriptions, including
specifications and detailed review documentation should be supplied when such documentation is available. The
capabilities, limitations and interdependence of these components should be expressed in terms relevant to safety.
The system and components should be addressed in relation to its mission and its operational environment. System
block diagrams or functional flow diagrams may be used to clarify system descriptions. Software and its role(s)
should be included in this description.
b. Data. This should consist of summaries of data used to determine the safety aspects of design features.
c. Hazard analysis results. This should consist of a summary or a total listing of the results of hazard analysis. The
following are the content and format requirements:
(1 ) A listing of identified hazards, in narrative or matrix (sometimes called columnar or tabular) format, to include
the following information:
(a) System component/phase. The particular phase/component that the analysis is concerned with. This could
be a system, subsystem, component, software, operating/maintenance procedure or environmental
condition.
(b) System operation description. A description of what is normally expected to occur as the result of operating
the component/subsystem or performing the operating/maintenance action.
(c) Hazard description. A complete description of the potential/actual hazards inherent in the item being
analyzed, or resulting from normal actions or equipment failure, or handling of hazardous materials.
(d) Hazard identification/indication. A description of operator/crew indications which include all means of
identifying the hazard to operational/maintenance personnel.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 98 of 1 04
(e) Effect of hazard. The detrimental effects which could be inflicted on the subsystem, system, other
equipment, facilities or personnel, resulting from this hazard. Possible upstream and downstream effects
should also be described.
(f) Risk assessment. A risk assessment for each hazard (classification of severity and probability of
occurrence). This is the assessment of the risk prior to taking any action to eliminate or control the hazard.
(g) Recommended action. The recommended action required to eliminate or control the hazard. Sufficient
technical detail is required in order to permit the design engineers to adequately develop and assess design
criteria resulting from the analysis. Include alternative designs and life cycle cost impact where appropriate.
(h) Effect of recommended action. The effect of the recommended action on the assigned risk assessment.
This is the risk assessment after taking action to eliminate or control each hazard. If the recommended
action would result in cost/schedule/performance penalties to the extent that the developer requires
approval prior to incorporation, then these considerations should be addressed.
(i) Remarks. Any information relating to the hazard not covered in other blocks; for example, applicable
documents, previous failure data on similar systems, or administrative directions.
(j) Status. The status of actions to implement the recommended, or other, hazard controls. The status should
include not only an indication of "open" or "closed," but also reference to the drawing(s), specification(s),
procedure(s), etc., that support closure of the particular hazard.
(k) Caution and Warning Notes. A complete list of warnings, cautions, and procedures required in operating
and maintenance manuals and for training courses.
Number: TDD-207

Title: Health Hazard Assessment Report (HHAR)

Approval Date: August 201 4

Use/Relationship:

Health Hazard Assessment Reports are used to systematically identify and evaluate health hazards, evaluate proposed
hazardous materials, and propose measures to eliminate or control these hazards though engineering design changes or
protective measures to reduce the risk to an acceptable level. This Task Data Description (TDD) contains the format and
content preparation instructions for the data product generated by the specific and discrete task requirement as delineated
in the contract.
Other Task Data Descriptions which relate to this TDD are: TDD-1 07, System Safety Program Progress Report; TDD-204,
Subsystem Hazard Analysis Report; TDD-205, System Hazard Analysis Report; TDD-301 , Safety Assessment Report; and
TDD-303, Engineering Change Proposal, Problem Report, and Deviation/Waiver System Safety Report.
Requirements:

1 . Format. The Health Hazard Assessment Report should be presented in the Developer’s format.
2. Contents. The HHAR should contain the following.
a. References. A list of source materials used in preparing the report. Include for example, government and developer
reports, standards, criteria, technical manuals and specifications. If references are numerous, put them in a
bibliography as an appendix.
b. System description. A brief identification of the system and its purpose. Address significant health hazard issues
that are identified later in the report.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 99 of 1 04
c. Background. A description of the system and its intended operation. Include pertinent components or subsystems
which contribute most to a health hazard. Identify the intended users and the type of protective clothing and
equipment, if any, available to the user. Include a summary of the evaluations or assessments performed on system
prototypes or developmental models.
d. Identification of health hazard issues. A description and discussion of each potential or actual health hazard issue
of concern for each subsystem or component. A health hazard in an existing or likely condition, inherent to the
operation, maintenance, transport or use of material, that can cause death, injury, acute or chronic illness, disability,
or reduced job performance of personnel by exposure to physiological stresses.
(1 ) System breakout. Use subparagraphs for each subsystem or component, with additional subparagraphs for
each health hazard discussion. Include sufficient detail to clearly define the specific problem, issues involved,
and reasoning behind the analysis.
(2) Material information. For each proposed and alternative material, include the following:
(a) Material identification. Include material identity; common or trade name; chemical name; Chemical Abstract
Services number; national stock number, or local stock number; physical form (solid, liquid, gas); and
manufacturers and suppliers.
(b) Material use and quantity. Include component name, description, and code, and/or operations details for
the material. Total system and program, life-cycle quantities to be used. For mixtures, percentages of each
ingredient.
(c) Hazard identification. The detrimental effects of the material on the system, personnel, environment, or
facilities.
(d) Toxicity assessment. A description of the expected frequency, duration, and amount of exposure. Include
the reference documentation and methods used to determine potency/toxicity assessment factors and
calculations.
(e) Risk calculators. Include classification of severity and probability of occurrence, acceptable levels of risk,
any missing information, and discussions of uncertainties in data or calculations.
(f) Material substitutions. Discuss the rationale for using a hazardous material and long term effects (such as
potential for personnel exposure, handling and disposal issue/requirements, protection/control measures,
and life-cycle costs) over a non or less hazardous material. The effects and cost should be considered over
the life of the systems, including the cost of handling and disposal. Identify potential non or less hazardous
alternatives if they exist and provide a justification why an alternative cannot be used.
(3) Description of physical agent stressors. Description of physical agents such as noise, vibration, ionizing and
non-ionizing radiation, and temperature (heat/cold) stressors should describe the intensity, location, affected
operations, and, if feasible duration, of human exposures. A diagram or map illustrating the location, field
intensity and other relevant details should be provided. Where feasible, the intensity of the power source, such
as sound power in watts, should be calculated and reported. The presence and effect of control measures, such
as vibration isolation, acoustic insulation and barriers should be described.
e. Assessment of health hazard issues. Include an analysis of data, observations, findings, reports, and other sources
of information against health standards and criteria. A discussion of the potential effect of the health hazards
identified. An assessment of the risk of the health hazards based on hazard severity and hazard probability as
described in GEIA-STD-001 0A. Include when the hazards may be expected under normal or unusual operating or
maintenance conditions.
f. Recommendations. Include a description of the recommended actions that should be taken to eliminate, reduce or
control each actual or potential health hazard described. Identify the effect that each action may have on the risk of
the health hazard(s).
g. Summary. Include a summary of the major recommendations.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 1 00 of 1 04
Number: TDD-208
Title: Functional Hazard Analysis (FHA) Report (FHAR)

Approval Date: August 201 4

Use/Relationship:

The Functional Hazard Analysis Report should document the results of Functional Hazard Analysis (FHA). It should be used
to identify and classify the system functions and the safety consequences of functional failure or malfunction. The FHA is
used to obtain an initial safety assessment of a concept or system. The FHAR should be updated as the FHA is updated to
reflect maturity of the design. This Task Data Description (TDD) contains the format and content preparation instructions
for the data product generated by the specific and discrete task requirement as delineated in the contract.
Other Task Data Descriptions which relate to this TDD are: TDD-202, Preliminary Hazard Analysis Report; TDD-204,
Subsystem Hazard Analysis Report; TDD-205 System Hazard Analysis Report; TDD-206, Operating & Support Hazard
Analysis Report; and TDD-207, Health Hazard Assessment Report.
Requirements:
1 . Format. The Functional Hazard Analysis Report should be presented in the Developer’s format.
2. Contents. Functional Hazard Analysis Reports should contain the following:
a. System description. Usually not required because this information is already documented in Preliminary Hazard
Analysis (PHA), System/Subsystem Hazard Analysis (S/SHA), or Safety Assessment Report (SAR). If these
documents are not required, then a system description should be provided. This should consist of summary
descriptions of the physical and functional characteristics of the system and its components. Reference to more
detailed system and component descriptions, including specifications and detailed review documentation should be
supplied when such documentation is available. The capabilities, limitations and interdependence of these
components should be expressed in terms relevant to safety. The system and components should be addressed in
relation to its mission and its operational environment. System block diagrams or functional flow diagrams may be
used to clarify system descriptions. Software and its role(s) should be included in this description.
b. Results. As a minimum the following should be provided:
(1 ) A physical and functional decomposition of the system (or system-of-systems). A work breakdown structure
(WBS) format works well to account for all critical subsystems and/or components.
(2) A list of system functions.
(3) A list of safety critical functions (SCFs). Note: mission critical functions can easily be identified from the same
analysis where the consequence is identified as “loss of mission capability.”
(4) A mapping of SCFs to the hardware and software design architectures. The SCF list and subsequent mapping
should also be used as inputs to reliability, integrity, assurance, and quality planning.
(5) An assessment of software control category and software criticality index for SCFs allocated to the software
design.
(6) A list of safety requirements and/or constraints of the system, based upon the safety risk ramification of loss of
function or malfunction.
(7) The FHA can further produce:
(a) A list of preliminary hazards for the Preliminary Hazard List/Preliminary Hazard Analysis (PHL/PHA)
(b) Inputs to the Failure Mode and Effects Analysis (FMEA)
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 1 01 of 1 04
(c) Methods to verify compliance with specific failure conditions or scenarios.
(d) Identification and design status of Safety Critical Item/Safety Significant Item (SCI/SSI) interfaces of the
system.
(e) Remarks.
Number: TDD-301

Title: Safety Assessment Report (SAR)

Approval Date: August 201 4

Use/Relationship:

The Safety Assessment Report is a comprehensive evaluation of the safety risks being assumed prior to test or operation
of the system or at contract completion. It identifies all safety features of the system, design, and procedural hazards that
may be present in the system being acquired, and specific procedural controls and precautions that should be followed.
This Task Data Description (TDD) contains the format and content preparation instructions for the data product generated
by the specific and discrete task requirement as delineated in the contract.
Other Task Data Descriptions which relate to this TDD are: TDD-1 06, Hazard Tracking System; TDD-1 07, System Safety
Program Progress Report; TDD-202, Preliminary Hazard Analysis Report; TDD-203, Safety Requirements/Criteria Analysis
Report; TDD-204, Subsystem Hazard Analysis Report; TDD-205, System Hazard Analysis Report; TDD-206, Operating
and Support Hazard Analysis Report; and TDD-207, Health Hazard Assessment; and TDD-303, Engineering Change
Proposal, Problem Report, and Deviation/Waiver System Safety Report.
Requirements:

1 . Format. The Safety Assessment Report should be presented in the Developer’s format.
2. Contents. The Safety Assessment Report (SAR) should include the following information:
a. Introduction. State, in narrative form, the purpose of the safety assessment report.
b. System description. This section may be developed by referencing other program documentation such as technical
manuals, System Safety Program Plan, System Specification, etc., and should include the following:
(1 ) The purpose and intended use of the system.
(2) A brief historical summary of system development.
(3) A brief description of the system and its components. Include name, type, model number, and general physical
characteristics of the overall system and its major subsystems and components. Software and its roles should
be included in this description.
(4) As applicable, a description of any other system(s) which should be tested or operated in combination with this
system.
(5) As applicable, either photos, charts, flow/functional diagrams, sketches, or schematics to support the system
description, test, or operation.
c. System operations.
(1 ) A description or reference of the procedures for operating, testing and maintaining the system. Discuss the
safety design features and controls incorporated into the system as they relate to the operating procedures.
(2) A description of any special safety procedures needed to assure safe operations, test and maintenance,
including emergency procedures.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 1 02 of 1 04
(3) A description of anticipated operating environments, and any specific skills required for safe operation, test,
maintenance, transportation or disposal.
(4) A description of any special facility requirements or personal equipment to support the system.
d. System safety engineering. This section should include:
(1 ) A summary or reference of the safety criteria and methodology used to classify and rank hazardous conditions.
(2) A description of or reference to the analyses and tests performed to identify hazardous conditions inherent in
the system.
(a) A list of all hazards by subsystem or major component level that have been identified and considered from
the inception of the program in an appendix to this SAR.
(i) A discussion of the hazards and the actions that have been taken to eliminate or control these items.
(ii) A discussion of the effects of these controls on the probability of occurrence and severity level of the
potential mishaps.
(iii) A discussion of the residual risks that remain after the controls are applied or for which no controls
could be applied.
(b) A discussion of or reference to the results of tests conducted to validate safety criteria requirements and
analyses.
(i) An identification of the test procedures that were conducted to verify or demonstrate compliance with
the safety requirements on safety critical hardware, software, and procedures (e.g. EOS and
emergency procedures). When cost for safety testing is prohibitive and has been approved by the
Managing Authority, the safety characteristics or procedures that were verified by engineering analysis,
analogy, laboratory tests, functional mockups, or models and simulations should be identified and a
summary of the results provided.
(ii) Identification of those test and evaluation reports that contain the results of the safety evaluation with
a summary of the results provided.
e. Conclusions and recommendations. This section should include:
(1 ) A short assessment of the results of the safety program efforts. A list of all significant hazards along with specific
safety recommendations or precautions required to ensure the safety of personnel and property. The list of
hazards should be categorized as to whether or not they may be expected under normal or abnormal operating
conditions.
(a) For all hazardous materials generated by or used in the system:
(i) Material identification as to type, quantity, and potential hazards.
(ii) Safety precautions and procedures necessary during use, storage, transportation, and disposal.
(iii) A copy of the Safety Data Sheet (OSHA Form 20 or DD Form 1 81 3) as required.
(b) A statement that the system either does not contain or generate hazardous materials (i.e., explosive, toxic,
radioactive, carcinogenic, etc.), or if legitimately required, the hazardous materials have been identified and
their risk appropriately controlled.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 1 03 of 1 04
(c) A statement signed by the developer system safety manager and the Managing Authority stating that all
identified hazards have been eliminated or controlled and that the system is ready to test, operate, or
proceed to the next acquisition phase. In addition, include recommendations applicable to the safe interface
of this system with the other system(s).
f. Reference. A list of all pertinent references such as test reports, preliminary operating manuals and maintenance
manuals.
Number: TDD-303
Title: Engineering Change Proposal, Problem Report, and Deviation/Waiver System Safety Report

Approval Date: August 201 4

Use/Relationship:

The Engineering Change Proposal, Problem Report, and Deviation/Waiver System Safety Report is used to summarize
results of analyses, tests, and tradeoff studies conducted on proposed engineering design changes, problem reports, and
deviation/waiver requests through the system life cycle. This Task Data Description (TDD) contains the format and content
preparation instructions for the data product generated by the specific and discrete task required as delineated in the
contract.
Other Task Data Descriptions which relate to this TDD are: TDD-1 07, System Safety Program Progress Report; TDD-202,
Preliminary Hazard Analysis Report; TDD-203, Safety Requirements/Criteria Analysis Report; TDD-204, Subsystem Hazard
Analysis Report; TDD-205, System Hazard Analysis Report; TDD-206, Operating and Support Hazard Analysis Report;
TDD-207, Health Hazard Assessment Report; and TDD-301 , Safety Assessment Report.
Requirements:

1 . Format. The Engineering Change Proposal, Problem Report and Deviation/Waiver System Safety Report should be
presented in the Developer’s format.
2. Contents.
a. ECP Reviews. The Report should include the following information resulting from a review of each ECP. When it is
determined that there are no hazards, a description of the analysis process and factors which allowed this
conclusion should be included.
(1 ) A list, in narrative or tabular form, of all hazards associated with the ECP. This includes all new hazards as well
as hazards that were previously identified and were eliminated or controlled, and are affected by this ECP (i.e.
their risk has been reduced or increased).
(2) A risk assessment of these hazards. This should include a pre-ECP and post-ECP assessment with severity
and probability of occurrence.
(3) The safety impact of the ECP upon the existing system
(4) An historical system safety summary as it relates to the ECP and reason for ECP.
(5) An identification of any update(s) of existing hazard analyses required to incorporate the effect(s) of the
engineering change if the change is authorized.
b. Problem Reports. The Report should include the following information resulting from a review of each Software
Problem Report, Program or Software Trouble Reports:
(1 ) A summary f the documented problem/issue.
(2) A statement of the specific safety implication.
(3) The affected safety requirements and/or safety hazard analyses/reports.
SAE INTERNATIONAL GEIA-STD-001 0™ A Page 1 04 of 1 04
c. Waiver/Deviation Request. The Report should include the following information resulting from a review of each
waiver or deviation request.
(1 ) A statement of the specific safety requirement and its associated source document name and paragraph
number, as applicable, for which a waiver or deviation is being requested.
(2) A detailed technical justification for the exception.
(3) Analyses to show that the mishap potential of the proposed alternate requirement, method or process, as
compared to the specified requirement.
(4) A narrative assessment of the risk involved in accepting the waiver or deviation. When it is determined that
there are no hazards, the basis for such determination should be provided.
(5) A narrative on possible ways of reducing hazard severities and probabilities and existing compliance activities
(if any).
(6) Start and expiration date for waiver/deviation.