Reliability and Safety Software Download
Get a quote
Reliability and Safety Software Demo


 
 
 
 
Reliability Software, Safety and Quality Solutions  / Safety /Hazard Analysis

Hazard Analysis

Hazard analysis takes place, iteratively over the entire lifecycle of a program or product.  SoHaR engineers will perform a Preliminary Hazard Analysis (PHA) early in the design phase when very little of the design details are known.  As the design becomes more concise and more details are known we will perform System Hazard Analysis (SHA) and Subsystem Hazard Analysis (SSHA) which will cover both hazards resulting from system-wide behavior and hazards emanating from a single subsystem. The analysis also covers interfaces between subsystems and external interfaces with users and environment.  

What is a Hazard?

There are some variations on the definition of the "hazard" concept, whether it is considered an intrinsic property of an item or a set of conditions that involves both the item and the use environment. A definition that represents a wide spectrum of views defines a hazard as a "State or set of conditions of an item that, together with other conditions in the environment of the item will lead to an accident". Here "item" may refer to a system, subsystem, or object; and variations can include qualifications such as "inevitably". However, clearly a hazard must be defined with respect to the environment in which the item exists and/or is operating.  This definition also illuminates the fact that a hazard can exist without a system failure: it can be entirely due to a combination of operational system state and environmental conditions (e.g. landing in bad weather).

Preliminary Hazard Analysis (PHA)

PHA can start as early as concept exploration or at the very early design stage. The PHA identifies the critical system functions and broad system hazards. The results are used to include safety considerations in concept trade-off analyses and design alternative comparisons. Naturally hazards related to implementation details, that are not within the critical system functions, will not be identified at this stage. The results are qualitative and risk assessment  is usually not complete at this stage.

The PHA is evaluated and updated iteratively as the initial design steps are taken. The PHA also provides input to later stage analyses.

Despite limited detail, the PHA provides critical input at a critical time. A decision to skip the preliminary hazard analysis and wait for a time "when we know more about the details of the system" can lead to costly results as safety is not included in the concept and design tradeoff analyses. It can lead to:

  • Significant late stage design/engineering modifications

  • Costly operational and maintenance requirements in order to mitigate hazards

  • Failure at market due to cost, safety and liability issues

Although later stage hazard analysis yields more detail on the hazards the preliminary analysis offers information that is more likely to critically affect the success of the program in the long run.

SoHaR will work with your design team and requirement/design documents to assess, list, and prioritize hazards at the early stages of program lifecycle. Our engineers are experienced at focusing in on the hazards and identifying, even at the early stages of design, potential hazards that may be overlooked by design engineers intent on delivering the best functionality. We will bring to the table a safety-centric outlook to complement your design-efforts and ensure that your safety requirements are not left for last.

System Hazard Analysis (SHA)

System Hazard Analysis is commonly performed once design is fleshed out, in parallel with the preliminary design review. The analysis is iteratively updated with the design.  Whereas Preliminary Hazard Analysis focuses on critical functionality and broad system hazards, System hazard analysis focuses in on the details. Specifically we are interested in

  • Overall system operation with attention to users, modes and varying environments

  •  Interfaces between subsystems and their interdependent compliance with the overall safety requirements

  • Whether design changes have affected safety

The results of the SHA are used to recommend changes, identify required controls, and evaluate how the design responds to safety requirements.

SHA requires attention to details of the design, knowledge of operational environments and system mode changes that can lead to unforeseen combinations of conditions. It requires extensive experience with "typical" hazard scenarios combined with detailed knowledge of the domain. SoHaR safety engineers will collaborate with your design and system engineers to ensure no hazards are overlooked and their causes and consequences are adequately identified.

SHA will often include quantitative assessment of hazard: probability of occurrence and severity of consequence. These are required for follow-up risk assessment.

Subsystem Hazard Analysis (SSHA)

Subsystem Hazard analysis is similar to SHA in its goals and methods, however its scope is limited to subsystems as components. It is often initiated at a later stage when details of the subsystems become available. Failure modes as contributing to hazards are focused on at the subsystem level and the detailed interfaces between components are investigated for possible conditions leading to hazards. Here we investigate how each single component affects the safety of the entire system while in the SHA we focus on the collaborative effects of components working together.

Hazards identified in the SHA and linked to specific conditions of subsystems are investigated and their probability of occurrence are estimated based on such input as component reliability and human error. Quantifiable input is added as the specifics of the design emerge.

Subsystems may include a single "media-type" (electronics, software, mechanical) but are often integrated. Embedded software-hardware systems or electromechanical actuators are examples of mixed-media subsystems that require an integrated SSHA. Even when a subsystem is composed purely of one engineering field it is still recommended that the SSHA be performed by safety engineers rather than design or system engineers. The goal of the analysis is to isolate the hazards and safety issues from the design and functional operation of the system. A design engineer with a strong view of the design of the subsystem will have difficulty looking away from mainline operation, as will a system engineers. It is the role of the safety engineer to provide the unique view that focuses on potential mishaps and hazardous conditions.     

 
Customers
OOPS. Your Flash player is missing or outdated.Click here to update your player so you can see this content.