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:
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
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.
|