Design and Pre-Design Safety Activities

The design and pre-design system safety engineering activities, are listed below:

• Activity 1 - Preliminary Hazard List (PHL)
• Activity 2 - Preliminary Hazard Analysis (PHA)
• Activity 3 - Requirements Hazard Analysis (RHA)
• Activity 4- Subsystem Hazard Analysis (SSHA)
• Activity 5 - System Hazard Analysis (SHA)
• Activity 6 - Operating and Support Hazard Analysis (O&SHA)
• Activity 7 - Health Hazard Assessment (HHA)

The completion of these activities represents the bulk of the SSP. The output and the effects of implementing the activities are the safety program. Review of the documented analyses provides the visibility into the effectiveness and quality of the safety program. It is recommended that these analyses be documented in a format compatible with an efficient review.

The following format features are recommended:

• Inclusion of a "road map" to show the sequence of tasks performed during the analysis.
• Presentation style, which may be in contractor format, consistent with the logic of the analysis procedure.
• All primary (critical) hazards and risks listed in an unambiguous manner.
• All recommended hazard controls and corrective actions detailed.

Questions that the reviewer should ask as the analyses are reviewed include the following:

• Do the contributory hazards listed include those that have been identified in accidents of similar systems?
• Are the recommended hazard controls and corrective actions realistic and sufficient?
• Are the recommended actions fed back into the line management system in a positive way that can be tracked?

The figure below illustrates the interrelationship of these tasks and their relationship to the design and contractual process.

Activity 1: Develop a Preliminary Hazard List

The Preliminary Hazard List (PHL) is generated at the start of each hazard analysis. It is basically a list of anything that the analyst can think of that can go wrong based on the concept, its operation and implementation. It provides an inherent list of hazards associated with the concept under consideration. The contractor may be required to investigate further selected hazards or hazardous characteristics identified by the PHL to determine their significance. This information is important in making a series of decisions ranging from "Should the program continue?" to shaping the post contractual safety requirements. The PHL may be generated by either the host employer or a contractor.

The PHL lists of hazards that may require special safety design emphasis or hazardous areas where in-depth analyses need to be done. Example uses of the PHL include providing inputs to the determination process of the scope of follow-on hazard analyses (e.g., PHA, SSHA). The PHL may be documented using a table-type format.

Activity 2: Conduct a Preliminary Hazard Analysis

The Preliminary Hazard Analysis (PHA) is the initial effort in hazard analysis during the system design phase or the programming and requirements development phase for facilities acquisition. It may also be used on an operational system for the initial examination of the state of safety. The purpose of the PHA is not to affect control of all risks but to fully recognize the hazardous states with all of the accompanying system implications.

The PHA effort should begin during the earliest phase that is practical and updated in each sequential phase. Typically, it is first performed during the conceptual phase but, when applicable, may be performed on an operational system. Performing a PHA early in the life cycle of a system provides important inputs to tradeoff studies in the early phases of system development. In the case of an operational system, it aids in an early determination of the state of safety. The output of the PHA may be used in developing system safety requirements and in preparing performance and design specifications.

In addition, the PHA is the basic hazard analysis that establishes the framework for other hazard analyses that may be performed.

A PHA must include, but not be limited to, the following information:

• As complete a description as possible of the system or systems being analyzed, how it will be used, and interfaces with existing system(s). If an OED was performed during predevelopment, this can form the basis for a system description.
• A review of pertinent historical safety experience (lessons learned on similar systems)
• A categorized listing of basic energy sources
• An investigation of the various energy sources to determine the provisions that have been developed for their control
• Identification of the safety requirements and other regulations pertaining to personnel safety, environmental hazards, and toxic substances with which the system must comply.
• Recommendation of corrective actions.

Since the PHA should be initiated very early in the planning phase, the data available to the analyst may be incomplete and informal. Therefore, the analysis should be structured to permit continual revision and updating as the conceptual approach is modified and refined. As soon as the subsystem design details are complete enough to allow the analyst to begin the subsystem hazard analysis in detail, the PHA can be terminated. The PHA may be documented in any manner that renders the information above clear and understandable to the non-safety community. A tabular format is usually used.

The following reference input information is helpful to perform a PHA:

• Design sketches, drawings, and data describing the system and subsystem elements for the various conceptual approaches under consideration
• Functional flow diagrams and related data describing the proposed sequence of activities, functions, and operations involving the system elements during the contemplated life span
• Background information related to safety requirements associated with the contemplated testing, manufacturing, storage, repair, and use locations and safety-related experiences of similar previous programs or activities.

The PHA must consider the following for identification and evaluation of hazards as a minimum.

• Hazardous components (e.g., fuels, propellants, lasers, explosives, toxic substances, hazardous construction materials, pressure systems, and other energy sources).
• Safety-related interface considerations among various elements of the system (e.g., material compatibility, electromagnetic interference, inadvertent activation, fire/explosive initiation and propagation, and hardware and software controls). This must include consideration of the potential contribution by software (including software developed by other contractors) to subsystem/system accidents.
• Environmental constraints, 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).
• If available, operating, test, maintenance, 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; life support requirements and their safety implications in manned systems, crash safety, egress, rescue, survival, and salvage).
• If available, facilities, support equipment (e.g., provisions for storage, assembly, checkout, proof testing of hazardous systems/assemblies that may involve toxic, flammable, explosive, corrosive, or cryogenic materials/; radiation or noise emitters; electrical power sources), and training (e.g., training and certification pertaining to safety operations and maintenance).
• Safety-related equipment, safeguards, and possible alternate approaches (e.g., interlocks, system redundancy, hardware or software fail-safe design considerations, subsystem protection, fire detection and suppression systems, personal protective equipment, industrial ventilation, and noise or radiation barriers).

Activity 3: Conduct a Requirements Hazard Analysis

The purpose of Activity 3 is to perform and document the safety design requirements/design criteria for a system or facility undergoing development or modification. It is also an opportunity to develop safety requirements from regulations, standards, Public Laws, etc. that are generic and not related to a specific identified hazard. In the early system design phase, the developer can usually anticipate the system design, including likely software control and monitoring functions. This information can be used to determine the potential relationship between system-level hazards, hardware elements and software control and monitoring and safety functions, and to develop design requirements, guidelines, and recommendations to eliminate or reduce the risk of those hazards to an acceptable level. Enough information can be collected to designate hardware and software functions as safety critical.

During the Demonstration and Evaluation and/or Full-Scale Development phases, the developer should analyze the system along with hardware/software design and requirements documents to:

• Refine the identification of hazards associated with the control of the system
• Safety-critical data generated or controlled by the system
• Safety-critical non-control functions performed by the system and unsafe operating modes for resolution.

The requirements hazard analysis is substantially complete by the time the allocated baseline is defined. The requirements are developed to address hazards, both specific and nonspecific, in hardware and software.

The requirements hazard analysis may use the PHL and the PHA as a basis, if available. The analysis 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 requirements hazard analysis is also used to incorporate design requirements that are safety related but not tied to a specific hazard. This analysis includes the following:

• Determination of applicable generic system safety design requirements and guidelines for both hardware and software from applicable military specifications, Government standards, and other documents for the system under development. Incorporate these requirements and guidelines into the high-level system specifications and design documents, as appropriate.
• Analysis of the system design requirements, system/segment specifications, preliminary hardware configuration item development specifications, software requirements specifications, and the interface requirements specifications, as appropriate, including the following sub-activities:
• Develop, refine, and specify system safety design requirements and guidelines; translate into system, hardware, and software requirements and guidelines, where appropriate; implement in the design and development of the system hardware and associated software.
• Identify hazards and relate them to the specifications or documents above and develop design requirements to reduce the risk of those hazards.
• Analyze the preliminary system design to identify potential hardware/software interfaces at a gross level that may cause or contribute to potential hazards. Interfaces to be identified include control functions, monitoring functions, safety systems, and functions that may have indirect impact on safety.
• Perform a preliminary risk assessment on the identified safety-critical software functions using the hazard risk matrix or software hazard risk matrix or another process as mutually agreed to by the contractor and the host employer.
• Ensure that system safety design requirements are properly incorporated into the operator, users, and diagnostic manuals.
• Develop safety-related design change recommendations and testing requirements and incorporate them into preliminary design documents and the hardware, software, and system test plans. The following subactivities should be accomplished:
• Develop safety-related change recommendations to the design and specification documents listed above and include a means of verification for each design requirement.
• Develop testing requirements. The contractor may develop safety-related test requirements for incorporation into the hardware, software, and system integration test documents.
• Support the system requirements review, system design review, and software specification review from a system safety viewpoint. Address the system safety program, analyses performed and to be performed, significant hazards identified, hazard resolutions or proposed resolutions, and means of verification.

For work performed under contract details to be specified in the SOW should include, as applicable:

• Definition of acceptable level of risk within the context of the system, subsystem, or component under analysis
• Level of contractor support required for design reviews
• Specification of the type of risk assessment process.

Activity 4: Subsystem Hazard Analysis

The Subsystem Hazard Analysis (SSHA) is performed if a system under development contained subsystems or components that when integrated function together in a system. This analysis examines each subsystem or component and identifies hazards associated with normal or abnormal operations and is intended to determine how operation or failure of components or any other anomaly that adversely affects the overall safety of the system. This analysis should identify existing and recommended actions using the system safety precedence to determine how to eliminate or reduce the risk of identified hazards.

As soon as subsystems are designed in sufficient detail, or well into concept design for facilities acquisition, the SSHA can begin. Design changes to components also need to be evaluated to determine whether the safety of the system is affected. The techniques used for this analysis must be carefully selected to minimize problems in integrating subsystem hazard analyses into the system hazard analysis. The SSHA may be documented in a combination of text and/or tabular format.

A contractor may perform and document a subsystem hazard analysis to identify all components and equipment, including software, whose performance, performance degradation, functional failure, or inadvertent functioning could result in a hazard or whose design does not satisfy contractual safety requirements. The analysis may include:

• A determination of the hazards or risks, including reasonable human errors as well as single and multiple failures.
• A determination of potential contribution of software (including that which is developed by other contractors) events, faults, and occurrences (such as improper timing) on the safety of the subsystem
• A determination that the safety design criteria in the software specification(s) have been satisfied
• A determination that the method of implementation of software design requirements and corrective actions has not impaired or decreased the safety of the subsystem nor has introduced any new hazards.

When software to be used in conjunction with the subsystem is being developed under standards, the contractor performing the SSHA will 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 response of the software developer should be reported in time to support the ongoing phase of the software development process. The contractor should update the SSHA when needed as a result of any system design changes, including software changes that affect system safety.

For work performed under contract details to be specified in the SOW should include, as applicable:

• Minimum risk severity and probability reporting thresholds
• The specific subsystems to be analyzed
• Any selected risks, hazards, hazardous areas, or other items to be examined or excluded
• Specification of desired analysis technique(s) and/or format.

Activity 5: System Hazard Analysis

A System Hazard Analysis (SHA) is accomplished in much the same way as the SSHA. However, as the SSHA examines how component operation or risks affect the system, the SHA determines how system operation and hazards can affect the safety of the system and its subsystems. The SSHA, when available, serves as input to the SHA. The SHA should begin as the system design matures, at the preliminary design review or the facilities concept design review milestone, and should be updated until the design is complete. Design changes will need to be evaluated to determine their effects on the safety of the system and its subsystems. This analysis should contain recommended actions, applying the system safety precedence, to eliminate or reduce the risk of identified hazards. The techniques used to perform this analysis must be carefully selected to minimize problems in integrating the SHA with other hazard analyses. The SHA may be documented in text and/or tabular format or a combination of both text and tables.

A contractor may perform and document an SHA to identify hazards and assess the risk of the total system design, including software, and specifically the subsystem interfaces. This analysis must include a review of subsystem interrelationships for:

• Compliance with specified safety criteria
• Independent, dependent, and simultaneous hazardous events including failures of safety devices and common causes that could create a hazard
• Degradation in the safety of a subsystem or the total system from normal operation of another subsystem
• Design changes that affect subsystems
• The effects of reasonable human errors
• The potential contribution of software (including that which is developed by other contractors) events, faults, and occurrences (such as improper timing) on safety of the system
• The determination that safety design criteria in the software specification(s) have been satisfied

The SHA may be performed using similar techniques to those used for the SSHA. When software to be used in conjunction with the system is being developed under software standards, the contractor performing the SHA should be required to monitor, obtain, and use the output of each phase of the formal software development process in evaluating the software contribution to safety. Problems identified that require the response of the software developer should be reported in time to support the ongoing phase of the software development process. A contractor should also be required to update the SHA when needed as a result of any system design changes, including software, which affect system safety.

When work is performed under contract, details to be specified in the SOW should include, as applicable:

• Minimum risk severity and probability reporting thresholds
• Any selected hazards, hazardous areas, or other specific items to be examined or excluded
• Specification of desired analysis technique(s) and/or format

Activity 6: Operating and Support Hazard Analysis

The Operating and Support Hazard Analysis (O&SHA) is performed primarily to identify and evaluate the hazards associated with the environment, personnel, procedures, operation, support, and equipment involved throughout the total life cycle of a system/element. The O&SHA may be performed on such activities as testing, installation, modification, maintenance, support, transportation, ground servicing, storage, operations, emergency escape, egress, rescue, post-accident responses, and training. The figure below shows O&SHA elements. The O&SHA may also be selectively applied to facilities acquisition projects to make sure operation and maintenance manuals properly address safety and health requirements.

The O&SHA effort should start early enough to provide inputs to the design, system test, and operation. This analysis is most effective as a continuing closed-loop iterative process, whereby proposed changes, additions, and formulation of functional activities are evaluated for safety considerations prior to formal acceptance. The analyst performing the O&SHA should have available:

• Engineering descriptions of the proposed system, support equipment, and facilities
• Draft procedures and preliminary operating manuals
• PHA, SSHA, and SHA reports
• Related and constraint requirements and personnel capabilities
• Human factors engineering data and reports
• Lessons learned, including a history of accidents caused by human error
• Effects of off-the-shelf hardware and software across the interface with other system components or subsystems.

Timely application of the O&SHA will provide design guidance. The findings and recommendations resulting from the O&SHA may affect the diverse functional responsibilities associated with a given program. Therefore, it is important that the analysis results are properly distributed for the effective accomplishment of the O&SHA objectives. The techniques used to perform this analysis must be carefully selected to minimize problems in integrating O&SHAs with other hazard analyses. The O&SHA may be documented any format that provides clear and concise information to the non-safety community.

A contractor may 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 following:

• Planned system configuration/state at each phase of activity
• Facility interfaces
• Planned environments (or ranges thereof)
• 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
• Potential for unplanned events, including hazards introduced by human errors.

The O&SHA must identify the safety requirements or alternatives needed to eliminate identified hazards, or to reduce the associated risk to a level that is acceptable under either regulatory or contractually specified criteria. The analysis may identify the following:

• Activities that occur under hazardous conditions, their time periods, and the actions required to minimize risk during these activities/time periods
• Changes needed in functional or design requirements for system hardware/software, facilities, tooling, or support/test equipment to eliminate hazards or reduce associated risks
• Requirements for safety devices and equipment, including personnel safety and life support equipment
• Warnings, cautions, and special emergency procedures (e.g., egress, rescue, escape), including those necessitated by failure of a software-controlled operation to produce the expected and required safe result or indication
• Requirements for handling, storage, transportation, maintenance, and disposal of hazardous materials
• Requirements for safety training and personnel certification.

The O&SHA documents system safety assessment of procedures involved in system production, deployment, installation, assembly, test, operation, maintenance, servicing, transportation, storage, modification, and disposal. A contractor must update the O&SHA when needed as a result of any system design or operational changes. If no specific analysis techniques are directed, the contractor should obtain approval of technique(s) to be used prior to performing the analysis.

For work performed under contract, details to be specified in the SOW should include, as applicable:

• Minimum risk probability and severity reporting thresholds
• Specification of desired analysis technique(s) and/or format
• The specific procedures to be evaluated.

Activity 7: Health Hazard Assessment

The purpose of a Health Hazard Assessment (HHA) is to identify health hazards, evaluate proposed hazardous materials, and propose protective measures to reduce the associated risk to an acceptable level.

The first step of the HHA is to identify and determine quantities of potentially hazardous materials or physical agents (noise, radiation, heat stress, cold stress) involved with the system and its logistical support. The next step is to analyze how these materials or physical agents are used in the system and for its logistical support. Based on the use, quantity, and type of substance/agent, estimate where and how personnel exposures may occur and if possible the degree or frequency of exposure. The final step includes incorporation into the design of the system and its logistical support equipment/facilities, cost-effective controls to reduce exposures to acceptable levels. The life-cycle costs of required controls could be high, and consideration of alternative systems may be appropriate.

An HHA evaluates the hazards and costs due to system component materials, evaluates alternative materials, and recommends materials that reduce the associated risks and life-cycle costs. Materials are evaluated if (because of their physical, chemical, or biological characteristics; quantity; or concentrations) they cause or contribute to adverse effects in organisms or offspring, pose a substantial present or future danger to the environment, or result in damage to or loss of equipment or property during the systems life cycle.

An HHA should include the evaluation of the following:

• Chemical hazards - Hazardous materials that are flammable, corrosive, toxic, carcinogens or suspected carcinogens, systemic poisons, asphyxiants, or respiratory irritants
• Physical hazards (e.g., noise, heat, cold, ionizing and non-ionizing radiation)
• Biological hazards (e.g., bacteria, fungi)
• Ergonomic hazards (e.g., lifting, task saturation)
• Other hazardous materials that may be introduced by the system during manufacture, operation, or maintenance.

The evaluation is performed in the context of the following:

• System, facility, and personnel protective equipment requirements (e.g., ventilation, noise attenuation, radiation barriers) to allow safe operation and maintenance. When feasible engineering designs are not available to reduce hazards to acceptable levels, alternative protective measures must be specified (e.g., protective clothing, operation or maintenance procedures to reduce risk to an acceptable level).
• Potential material substitutions and projected disposal issues. The HHA discusses long-term effects such as the cost of using alternative materials over the life cycle or the capability and cost of disposing of a substance.
• Hazardous material data. The HHA describes the means for identifying and tracking information for each hazardous material. Specific categories of health hazards and impacts that may be considered are acute health, chronic health, cancer, contact, flammability, reactivity, and environment.

The HHA's hazardous materials evaluation must include the following:

• Identification of the hazardous materials by name(s) and stock numbers (or CAS numbers); the affected system components and processes; the quantities, characteristics, and concentrations of the materials in the system; and source documents relating to the materials
• Determination of the conditions under which the hazardous materials can release or emit components in a form that may be inhaled, ingested, absorbed by living beings, or leached into the environment
• Characterization material hazards and determination of reference quantities and hazard ratings for system materials in question
• Estimation of the expected usage rate of each hazardous material for each process or component for the system and program-wide impact
• Recommendations for the disposition of each hazardous material identified. If a reference quantity is exceeded by the estimated usage rate, material substitution or altered processes may be considered to reduce risks associated with the material hazards while evaluating the impact on program costs. For each proposed and alternative material, the assessment must provide the following data for management review:
• Material identification. Includes material identity, common or trade names, chemical name, chemical abstract service (CAS) number, national stock number (NSN), local stock number, physical state, and manufacturers and suppliers
• Material use and quantity. Includes component name, description, operations details, total system and life cycle quantities to be used, and concentrations of any mixtures
• Hazard identification. Identifies the adverse effects of the material on personnel, the system, environment, or facilities
• Toxicity assessment. Describes expected frequency, duration, and amount of exposure. References for the assessment must be provided
• Risk calculations. Includes classification of severity and probability of occurrence, acceptable levels of risk, any missing information, and discussions of uncertainties in the data or calculations.

For work performed under contract, details to be specified in the SOW include:

• Minimum risk severity and probability reporting thresholds
• Any selected hazards, hazardous areas, hazardous materials or other specific items to be examined or excluded
• Specification of desired analysis techniques and/or report formats.

Source: FAA Office of System Safety

Certisafety Section Home Page