The design and pre-design system safety engineering activities, are listed below:
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:
Questions that the reviewer should ask as the analyses are reviewed include the following:
The figure below illustrates the interrelationship of these tasks and their relationship to the design and contractual process.
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.
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:
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:
The PHA must consider the following for identification and evaluation of hazards as a minimum.
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:
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:
For work performed under contract details to be specified in the SOW should include, as applicable:
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:
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:
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:
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:
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:
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:
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:
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:
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:
The evaluation is performed in the context of the following:
The HHA's hazardous materials evaluation must include the following:
For work performed under contract, details to be specified in the SOW include:
Source: FAA Office of System Safety
Copyright ©2000-2019 Geigle Safety Group, Inc. All rights reserved. Federal copyright prohibits unauthorized reproduction by any means without permission. Disclaimer: This material is for training purposes only to inform the reader of occupational safety and health best practices and general compliance requirement and is not a substitute for provisions of the OSH Act of 1970 or any governmental regulatory agency. CertiSafety is a division of Geigle Safety Group, Inc., and is not connected or affiliated with the U.S. Department of Labor (DOL), or the Occupational Safety and Health Administration (OSHA).