Space product assurance
Hazard analysis
Foreword
This Standard is one of the series of ECSS Standards intended to be applied together for the management, engineering and product assurance in space projects and applications. ECSS is a cooperative effort of the European Space Agency, national space agencies and European industry associations for the purpose of developing and maintaining common standards. Requirements in this Standard are defined in terms of what shall be accomplished, rather than in terms of how to organize and perform the necessary work. This allows existing organizational structures and methods to be applied where they are effective, and for the structures and methods to evolve as necessary without rewriting the standards.
This Standard has been prepared by the ECCS Executive Secretariat, endorsed by the document and discipline focal point and approved by the ECSS Technical Authority.
Disclaimer
ECSS does not provide any warranty whatsoever, whether expressed, implied, or statutory, including, but not limited to, any warranty of merchantability or fitness for a particular purpose or any warranty that the contents of the item are error-free. In no respect shall ECSS incur any liability for any damages, including, but not limited to, direct, indirect, special, or consequential damages arising out of, resulting from, or in any way connected to the use of this Standard, whether or not based upon warranty, business agreement, tort, or otherwise; whether or not injury was sustained by persons or property or otherwise; and whether or not loss was sustained from, or arose out of, the results of, the item, or any services that may be provided by ECSS.
Published by: ESA Requirements and Standards Division
ESTEC, P.O. Box 299,
2200 AG Noordwijk
The
Copyright: 2008 © by the European Space Agency for the members of ECSS
Change log
|
ECSS-Q-40-02A
|
First issue
|
|
ECSS-Q-40-02B
|
Never issued
|
|
ECSS-Q-ST-40-02C
|
Second issue
|
Introduction
Safety analysis comprises hazard analysis, safety risk assessment and supporting analyses as defined in ECSS-Q-ST-40. The objective of safety analysis is to identify, assess, reduce, accept, and control safety hazards and the associated safety risks in a systematic, proactive, complete and cost effective manner, taking into account the project’s technical and programmatic constraints. Safety analysis can be implemented through an iterative process, with iterations being determined by the project progress through the different project phases, and by changes to a given project baseline.
Hazard analysis comprises the identification classification and reduction of hazards. Hazard analysis can be implemented at each level of the customersupplier network. Hazard analysis activities at lower level can contribute to system level safety analysis. System level safety analysis can determine lower level hazard analysis activities.
Hazard analysis interfaces with dependability analysis, in particular FMECA. Safety risk assessment interfaces with quantitative dependability analysis, in particular reliability analysis. Safety risk assessment contributes to project risk management. Ranking of safety risks according to their criticality for project success, allowing management to direct its attention to the essential safety issues, is part of the major objectives of risk management.
Safety risk assessment is further addressed in ECSS-Q-ST-40.
Scope
This Standard details the hazard analysis requirements of ECSS-Q-ST-40; it defines the principles, process, implementation, and requirements of hazard analysis.
It is applicable to all European space projects where during any project phase there exists the potential for hazards to personnel or the general public, space flight systems, ground support equipment, facilities, public or private property or the environment.
This standard may be tailored for the specific characteristics and constrains of a space project in conformance with ECSS-S-ST-00.
Normative references
The following normative documents contain provisions which, through reference in this text, constitute provisions of this ECSS Standard. For dated references, subsequent amendments to, or revision of any of these publications do not apply, However, parties to agreements based on this ECSS Standard are encouraged to investigate the possibility of applying the more recent editions of the normative documents indicated below. For undated references, the latest edition of the publication referred to applies.
|
ECSS-S-ST-00-01
|
ECSS system — Glossary of terms
|
|
ECSS-M-ST-80
|
Space project management — Risk management
|
|
ECSS-Q-ST-40
|
Space product assurance — Safety
|
Terms, definitions and abbreviated terms
Terms from other standards
For the purpose of this Standard, the terms and definitions from ECSS-S-ST-00-01 apply, in particular for the following terms:
requirement
Terms specific to the present standard
consequence tree
set of hazard scenarios leading to the same safety consequence
detection time
time span between the occurrence of the initiator event and its detection through the observable symptoms
hazard
existing or potential condition of an item that can result in a mishap
- 1 [ISO 14620 2]
- 2 This condition can be associated with the design, fabrication, operation, or environment of the item, and has the potential for mishaps. [ISO 14620 2]
- 3 Hazards are potential threats to the safety of a system. They are not events, but the prerequisite for the occurrence of hazard scenarios with their negative effects on safety in terms of the safety consequences.
hazard acceptance
decision to tolerate the consequences of the hazard scenarios when they occur
hazard analysis
systematic and iterative process of the identification, classification and reduction of hazards
hazard control
preventive or mitigation measure, associated to a hazard scenario, which is introduced into the system design and operation to avoid the events or to interrupt their propagation to consequence
hazard elimination
removal of a hazard from a particular hazard manifestation
hazard manifestation
presence of specific hazards in the technical design, operation and environment of a system
hazard minimization
substitution of a hazard in the hazard manifestation by another hazard of the same type but with a lower potential threat
For instance high toxicity to low toxicity.
hazard reduction
process of elimination or minimization and control of hazards
hazard scenario
sequence of events leading from the initial cause to the unwanted safety consequence
The cause can be a single initiating event, or an additional action or a change of condition activating a dormant problem.
hazard tree
set of hazard scenarios originating from the same set of hazard manifestations
hazardous
property of an item and its environment which provides the potential for mishaps
[ISO 14620 2]
observable symptoms
evidence that indicates that an undesirable event has occurred
Observable symptoms appear during the propagation time.
reaction time
time span between the detection and the occurrence of the consequence
This is the time span available for mitigating actions after detection of the occurrence of the initiator event.
residual hazard
hazard remaining after implementation of hazard reduction
resolved hazard
hazard that is reduced, the reduction verified and the hazard considered acceptable
Resolved hazards are submitted for formal acceptance.
scenario propagation time
time span between the occurrence of the initiator event and the occurrence of the consequence
severity of safety consequence
measure of the gravity of damage with respect to safety
Abbreviated terms
For the purpose of this Standard, the abbreviated terms from ECSS-S-ST-0001 and the following apply:
|
Abbreviation
|
Meaning
|
|
CC&M
|
common cause and common failure mode analysis
|
|
DRD
|
document requirements definition
|
|
FMECA
|
failure modes, effects and criticality analysis
|
|
GSE
|
ground support equipment
|
|
NASA
|
National Aeronautics and Space Administration
|
|
OHA
|
operating hazard analysis
|
|
PHA
|
preliminary hazard analysis
|
|
SHA
|
system hazard analysis
|
|
SSHA
|
subsystem hazard analysis
|
Principles of hazard analysis
Hazard analysis concept
Hazard analysis is based on the following hazard analysis concept, which is depicted in Figure 41 to Figure 44.
Hazards, which are present through hazard manifestations in the system, are activated if initiating events (i.e. cause) occur. Hazard scenarios reflect the system behaviour to the activated hazards in terms of event propagation from causes to safety consequences, as depicted in Figure 41. The occurrence of events is coupled to observable symptoms in the system. Safety consequences are characterized by their severity.
Different hazard scenarios can originate from the same hazard. Furthermore, different hazard scenarios can lead to the same safety consequence. For an example, see Table 54. The collection of hazard scenarios originating from the same hazard manifestation is collated into a hazard tree, as illustrated in Figure 42. The collection of hazard scenarios leading to the same safety consequence is collated into a consequence tree, as illustrated in Figure 43.
Hazards are reduced by either eliminating them or, if this is not possible, by minimizing and controlling them, as shown in Figure 44. Hazards are eliminated through the removal of specific potentially safety threatening system characteristics. Hazards are minimized through reducing the level or amount of specific potentially safety threatening system characteristics. Hazards are controlled through the prevention of the occurrence or reduction of the likelihood and mitigation of the effects of events. Occurrence of the events can be detected through their observable symptoms.
For example: A hazard to driving a car is “poor weather conditions”, and the hazard is manifested by “ice on the road”. The cause “rapid change of direction” can lead to the event “loss of control” and finally to the consequence “death of driver”. Hazard elimination can be achieved by “delaying the journey”, and hazard minimization by gritting the road. There are various methods for hazard control which impact on different parts of the process: “driving slowly” impacts on the cause; “using snowchains” impacts on the link between cause and event; “fitting airbag” impacts on the link between event and consequence.
Figure 41: Hazards and hazard scenarios
Figure 42: Example of a hazard tree
Figure 43: Example of a consequence tree
Figure 44: Reduction of hazards
Failure causes as identified through FMECA and other analyses, such as common cause and common failure mode analysis (CC&M), can represent causes of hazard scenarios, as depicted in Figure 45.
Figure 45: Interface to FMECA and CC&M analysis
Role of hazard analysis
Hazard analysis is the principal deterministic safety analysis which assists engineers and managers in including safety aspects in the engineering practices and the decisionmaking process throughout the project life cycle in design, construction, testing, operation, maintenance, and disposal, together with their interfaces.
Hazard analysis provides essential input to the safety risk assessment for a system.
Hazard analysis process
Overview
The hazard analysis process comprises the steps and tasks necessary to identify and classify hazards, to achieve hazard reduction. The basic steps are:
Step 1: define the hazard analysis implementation requirements;
Step 2: identify and classify the hazards;
Step 3: decide and act on the hazards;
Step 4: track, communicate and accept the hazards.
The process of hazard analysis, including iteration of its tasks, is summarized in Figure 46.
Figure 46: The process of hazard analysis
Overview of the hazard analysis process
The iterative fourstep hazard analysis process is illustrated in Figure 47. The tasks within each of these steps are shown in Figure 48.
Step 1 comprises the establishment of the scope and purpose of hazard analysis, the hazard analysis planning (Task 1), and the definition of the system to be analysed (Task 2). Step 1 is performed at the beginning of a project. According to the scope and purpose, the implementation of the hazard analysis process consists of a number of “hazard analysis cycles” over the project’s duration, comprising the necessary revisions of the analysis requirements and the Steps 2 to 4, subdivided in the seven Tasks 3 to 9.
The period designated in Figure 47 as the “Hazard analysis process” comprises all the phases of the project concerned, as defined in ECSS-M-ST-10. The frequency and the events at which cycles are required in a project (only 3 are shown in Figure 47 for illustration purposes) depend on the needs and complexity of the project, and are defined during Step 1 at the beginning of the project.
Figure 47: The steps and cycles in the hazard analysis process
Figure 48: The nine tasks associated with the four steps of the hazard analysis process
Hazard analysis implementation
Overview
Implementation of hazard analysis in a project is based on single or multiple, i.e. iterative, application of the hazard analysis process. The tasks associated with the individual steps of the hazard analysis process vary according to the scope and objectives specified for hazard analysis. The scope and objectives of hazard analysis depend on the type and phase of the project.
Hazard analysis requires commitment in each actor’s organization, and the establishment of clear lines of responsibility and accountability. Project management has overall responsibility for the implementation of hazard analysis, ensuring an integrated, coherent hazard analysis approach.
General considerations
Hazard analysis is implemented as a team effort, with tasks and responsibilities being assigned to the functions and individuals within the project organization with the relevant expertise in the areas of safety and engineering concerned by a given hazard.
The results of hazard analysis are used as input to project reviews and project management during the evolution of the system.
Annex C provides background information on traditionally performed hazard analyses.
Type of project considerations
Hazard analysis activities differ according to the type of project and required safety effort. However, the hazard analysis process is the same in each case. Hazard analysis activities are linked to different types of projects, such as:
Hazard analysis at subsupplier level for safety of part of the spacecraft design and the operation of a manned or unmanned mission and as input to system safety efforts.
Hazard analysis at prime supplier level for system safety of total space system design and the operation of a manned or unmanned mission.
Hazard analysis at any supplier level for payload safety.
Hazard analysis at any supplier level for safety of spacecraft verification activities.
Hazard analysis at any supplier level for safety of other ground activities, operations and launch.
Documentation of hazard analysis
Hazard analyses are documented to ensure that all associated decisions are traceable and defensible.
Every task of the hazard analysis process is documented.
Example forms for summarizing the results of the tasks are presented in ECSS-Q-ST-40 DRD for Hazard reports. See Annex B of this Standard for examples.
Hazard analysis documentation
The hazard analysis process is documented to ensure that the scope and objectives of hazard analysis are established, understood, implemented and maintained, and that an audit trail can track the origin and rationale of all safety related decisions made during the life of the project.
Integration of hazard analysis activities
Hazard analysis activities are performed at different levels of the customersupplier chain. The lower level hazard analysis activities are integrated into the system level hazard analysis activities. The proper and effective integration of these tasks is of major importance and is typically achieved by applying the following:
The top down approach from the system to lower level is to identify the required lower level hazard analysis inputs. The required inputs are linked to knowledge of the domain.
The lower level task is to consider that domain and to develop and provide the required input to the next level up.
The system level task, using a bottomup approach, logically and effectively integrates the lower level hazard analysis inputs into the system level hazard analysis.
The above statements 4.6a to 4.6c assist in achieving the following results:
Proper allocation of the consequence severity categories at system level.
Proper development and implementation of hazard reduction.
Identification of the unresolved hazards in a timely manner.
Assurance that all aspects are considered in order to optimize and harmonize hazard reduction.
Objectives of hazard analysis
The general objectives of hazard analysis are to:
assess the level of safety of a system in a deterministic way;
increase the level of safety of a system through hazard reduction;
initiate the use of hazard reduction to drive the definition and implementation of, for example, design and operation requirements, specifications, concepts, procedures;
provide a basis for defining adequate safety requirements, determining the applicability of safety requirements, implementing safety requirements, verifying their implementation, and demonstrating compliance or noncompliance;
provide input to safety risk assessment and overall risk management;
support safety related project decisions;
support safety submissions and reviews through documented evidence; and
support safety certification of a system through documented evidence.
The specific objectives of hazard analysis with respect to a projectspecific application are determined under Step 1 of the hazard analysis process — see clause 4.3 and clause 5.
Requirements
Hazard analysis requirements
The supplier shall perform the hazard analysis according to the fourstep process comprising the nine tasks as defined in clause 5.2.
The supplier shall document the outputs of hazard analysis in conformance with the requirements of ECSS-Q-ST-40, Hazard report — Document requirements definition (DRD).
Hazard analysis steps and tasks
Step 1: Define hazard analysis implementation requirements
Introduction
The implementation of hazard analysis in a project starts with Step 1, which is performed at the beginning of the project and comprises Tasks 1 and 2.
Task 1: Define the scope, the objectives of hazard analysis and the hazard analysis planning
The supplier shall perform task 1 according to the following procedure:
- Establish the purpose and application boundaries of hazard analysis.
- Define the type of project and relevant part of the project life cycle.
For type of project considerations refer to clause 4.4.3.
- Identify applicable safety requirements.
- Define customer requirements and interfacing supplier requirements.
- Define the hazard analysis approach commensurate with the purpose and including the necessary depth of analysis.
- Identify relevant input data for hazard analysis.
Data such as FMECA and CC&M, similar analysis from, for example, other projects, experience data, system models and expert judgement.
- Establish scoring schemes for the severity of safety consequences for the classification of hazard scenarios commensurate with ECSS-Q-ST-40, “Severity of hazardous event” and the project risk management policy in conformance with ECSS-M-ST-80.
An example of such a scoring schema is given in Table 51, which is consistent with the “Severity of consequences” table specified in ECSS-Q-ST-40.
- Use the consequence severity categories “Catastrophic” and “Critical” in conformance with ECSS-Q-ST-40 for any space projects and applications.
In addition, other categories can be used to complete the assessment of the safety consequences.
Table 51: Example of a safety consequence severity categorization
|
Category
|
Severity
|
Severity of safety consequence
|
|
1
|
Catastrophic
|
Loss of life, lifethreatening or permanently disabling injury or occupational illness;
|
|
2
|
Critical
|
Temporarily disabling, but not lifethreatening injury or illness;
|
|
3
|
Marginal
|
Minor injury, minor disability, minor occupational illness;
|
|
4
|
Negligible
|
Less than minor injury, disability, occupational illness;
|
- Plan the hazard analysis application.
- Establish criteria to determine the actions to be taken on hazards, hazard reduction and the associated decision levels in the project structure.
- Define hazard acceptance criteria for individual hazards and hazard scenarios.
- Define the strategy, and the formats to be used for documenting hazard analysis data and communication of hazard analysis results to the decisionmakers, and for monitoring the hazards.
- Describe the review, decision and implementation flow within the project concerning all hazard analysis matters.
Task 2: Define the system baseline to be analysed
The supplier shall perform task 2 according to the following procedure:
- Define and describe the design and operation subjected to hazard analysis.
This can be drawings, procedures and test reports.
- Revise the system baseline definition for each hazard analysis cycle with the level of detail available at that time.
Refer to configuration files, as defined by ECSS-M-ST-40, for a valid configuration baseline definition.
Step 2: Identify and assess the hazards
Introduction
The purpose is to identify hazard manifestations and hazard scenarios and to classify them according to the consequence severity.
Task 3: Identify hazard manifestations
The supplier shall perform task 3 according to the following procedure:
- Identify generic hazards applicable to the system design and operation using a hazard matrix.
- 1 For examples of generic hazards refer to Annex A.
- 2 The example in Table 52 shows part of a hazard matrix, in this case for the ground operation phase. Each element of the matrix indicates the applicability of the generic hazard to the corresponding subsystem.
- Identify and give a detailed definition of system specific hazards and describe them in the form of hazard manifestations.
Table 53 shows an example of part of a list of hazard manifestations. Each row of the list describes the manifestation of the hazard for each subsystem within each specific mission phase.
Table 52: Example of a hazard matrix
|
Hazard matrix for ground operation
| |||
|
Generic hazards
|
Subsystem elements
| ||
|
Propulsion subsystem
|
Instruments
|
Communication subsystem
| |
|
High pressure
|
X
|
-
|
-
|
|
High temperature
|
-
|
-
|
-
|
|
Toxicity
|
X
|
X
|
-
|
|
Flammability
|
X
|
-
|
-
|
|
X = applicable - = not applicable
| |||
Table 53: Example of a hazard manifestation list
|
Hazard manifestation list
| ||
|
phase
|
Subsystem
|
Hazard manifestation
|
|
Ground operation
|
Propulsion
|
Filling of Y litres of toxic propellant into two tanks at a pressure of X1 Pa
|
|
Instruments
|
Painting and seal material used in instrument cabinet A emitting toxic fumes if exposed to fire
| |
|
Inorbit operation
|
Propulsion
|
Propellant lines under pressure at X2 Pa
|
|
Instruments
|
Painting and seal material used in instrument cabinet A emitting toxic fumes if exposed to fire
| |
Task 4: Identify and classify the hazard scenarios
The supplier shall perform task 4 according to the following procedure:
- Identify the hazard scenarios associated with the hazard manifestations by identifying the causes, events and safety consequences, according to the hazard analysis planning by performing the following procedure:
- Determine events triggering the hazards, i.e. causes, description of the causes in terms of definition of physical or functional failures or other physical phenomena, which bring about the activation of the hazards.
- Determine the physical propagation of events from a cause to the consequences, through investigation of the physical layout of the system and assessment of mechanisms involving physical damage propagation, and description of the physical behaviour of the system in response to the occurrence of the causes.
- Determine the functional propagation of events from a cause to the consequences through investigation of the functional layout of the system and assessment of mechanisms involving functional failure propagation, and description of the functional behaviour of the system in response to the occurrence of the causes.
A combination of the above cases 5.2.2.3a.1(a) to 5.2.2.3a.1(c) can also apply.
* Identify common-cause and common-mode phenomena and their propagation to safety consequences, and description of the physical and functional behaviour of the system in response to the occurrence of these events.
Refer to ECSS-Q-ST-40 for “Common-cause and common-mode failure analysis”.
* Determine timerelated event propagation and the description of the physical and functional behaviour of the system in response to the occurrence of these events.
* Determine operation sequence induced event propagation associated with operational steps and procedures, and description of the physical and functional behaviour of the system in response to the occurrence of these events.
* Determine failure events, as determined in the FMECA, propagating to safety consequences.
For details on the FMECA refer to ECSS-Q-ST-30-02.
- Identify the propagation time, the observable symptoms and the detection time for each hazard scenario.
- Determine the consequence severity of each hazard scenario according to the severity categorization defined in clause 5.2.1.2.
- Determine the hazard trees by identifying all hazard scenarios originating from one and the same hazard manifestation.
- Determine the consequence trees by identifying all hazard scenarios leading to one and the same safety consequence.
- Use the hazard and consequence trees to screen for additional hazard scenarios.
- Identify information sources, interfacing analysis and methods used to support the identification process and to justify the hazard scenarios.
- 1 Interfacing analysis can be a FMECA.
- 2 The example in Table 54 shows part of a hazard scenario list. Each row of the list describes the scenario for each manifestation of the hazard for each subsystem within each specific mission phase.
Table 54: Example of a hazard scenario list
|
Hazard scenario list for inorbit phase
| ||||
|
Hazard Manifestation
|
Cause Events Consequence
|
Consequence Severity
|
Observable Symptoms
|
Propagation and reaction time
|
|
Inorbit
|
Meteorite debris impact shell rupture explosion loss of spacecraft and astronauts
|
Catastrophic
|
None
|
Ptime: 1 s
|
|
|
Meteorite debris impact shell damage leakage loss of spacecraft and astronauts
|
Catastrophic
|
Module pressure drop
|
Ptime: 3 min
|
Step 3: Decide and act
Introduction
In this step the acceptability of hazards and hazard reduction options is analysed and the appropriate hazard reduction strategy is determined.
Task 5: Decide if the hazards can be accepted
The supplier shall perform task 5 according to the following procedure:
- Apply the hazard acceptance criteria to the hazards as defined in clause 5.2.1.2.
- Identify the acceptable hazards and those that are subjected to hazard reduction.
- For acceptable hazards, proceed directly to 5.2.4; for unacceptable hazards proceed to clause 5.2.3.3.
Task 6: Reduce the hazards
The supplier shall perform task 6 according to the following procedure:
- Determine measures in the form of design and operation features through which the hazards can be eliminated.
- Where hazards cannot be eliminated, determine measures in the form of design and operation features through which hazards can be minimized and controlled.
- For hazard control, identify the preventive and mitigation measures in the following order of precedence:
- Design and operation features that prevent the occurrence of a cause.
For example through safety features.
* Design and operation features that prevent or interrupt the physical propagation of a cause to an event.
For example through introduction of physical barriers.
* Design and operation features that prevent or interrupt the functional propagation of a cause to an event.
For example through introduction of functional redundancy.
* Design and operation features that prevent or interrupt the functional propagation of a cause to an event through introduction of an emergency, warning and caution function.
* Design and operation features that reduce the severity of a consequence through introduction of a safing, escape or rescue feature or function.
* Procedures or changes in operational steps and procedures.
- Determine hazard reduction success, failure and verification criteria.
- Determine verification means and methods for the implementation of hazard reduction.
- Select and prioritize the hazard reduction measures.
- Verify hazard reduction through application of the verification means and methods.
- Identify the resolved and unresolved hazards.
Task 7: Recommend acceptance
The supplier shall perform task 7 according to the following procedure:
- Submit the hazard analysis results data.
- Present the unresolved hazards for further action.
- Provide the rationale and supporting data for resolution and acceptance of the hazards.
Step 4: Track, communicate and accept the hazards
Introduction
The purpose of this step is to track, update, iterate and communicate hazards, and finally to accept the residual hazards.
Task 8: Track and communicate the hazards
The supplier shall perform task 8 according to the following procedure:
- Periodically assess and review all identified hazards and update the results after each iteration of the hazard analysis process.
- Identify changes to existing hazards, and subsequently initiate new hazard analysis.
- Verify the performance and the effect of the hazard reduction activities.
- Identify and communicate the evolution of hazards over the project life cycle.
Task 9: Accept the hazards
The supplier shall perform task 9 according to the following procedure:
- Submit the residual hazards to formal hazard acceptance.
- Assess the performance of the hazard analysis processes and implement improvement of the effectiveness based on experience with project progress.
ANNEX(informative)Examples of generic hazards
Thermodynamic and fluidic
Pressure (difference, high, low, vacuum)
Temperature (difference, high, low)
Heat transfer
Fluid jet
Thermal properties of materials
Electrical and electromagnetic
Voltage (high, medium, low)
Static electricity
Electric current (high, medium, low)
Magnetic field (induced, external)
Ionization
Radiation
Light (infrared, visible, ultraviolet, laser)
Radioactivity (alpha, beta, gamma rays)
Open fire
Chemical
Toxicity
Corrosiveness
Flammability
Explosiveness
Asphyxiant
Irritant
Mechanical
Physical impact or mechanical energy
Mechanical properties of materials (e.g. sharp, rough, slippery)
Vibration
Noise
Frequency and intensity
Biological
Human waste
Microorganism
Carcinogenic
Psychological
Physical
Confined space
Environment - space
Zero gravity
Vacuum
Atmospheric composition
Contaminants, pollutants
Meteorite and space debris
Temperature (difference, low, high)
Radiation
anomaly
Environment - Earth
Environmental extremes
Natural disasters
Lightning
ANNEX(informative)Hazard and safety risk register (example) and ranked hazard and safety risk log (example)
|
Project |
Organization |
Source |
Date and issue |
||||||||||||||||||||||
|
WBS Ref. |
|
|
|
Controlled by |
|
|
|||||||||||||||||||
|
|
|
|
|
Supported by |
|
Approved by |
|||||||||||||||||||
|
Hazard description and safety risk magnitude |
|||||||||||||||||||||||||
|
No. |
Hazard scenario title |
||||||||||||||||||||||||
|
Hazard manifestation |
Cause, events and safety consequence |
||||||||||||||||||||||||
|
Safety consequence severity (S) |
Likelihood (L) |
Risk Index |
Risk |
Red* |
Yellow* |
Green* |
|||||||||||||||||||
|
Negligible |
Marginal |
Critical |
Catastrophic |
Minimum |
Low |
Medium |
High |
Maximum |
(R = S x L) |
Safety
|
|
|
|
||||||||||||
|
IV |
III |
II |
I |
E |
D |
C |
B |
A |
Numerical risk and uncertainty contribution: |
||||||||||||||||
|
|
Numerical estimate: |
||||||||||||||||||||||||
|
Hazard and safety risk decision and action |
|||||||||||||||||||||||||
|
Accept hazard and safety risk |
Reduce hazard and safety risk |
||||||||||||||||||||||||
|
Hazard reduction measures Hazard elimination: Hazard minimization: Hazard control: |
Hazard reduction verification means |
Expected safety risk reduction Severity, likelihood, risk index: Numerical estimates: Safety risk rank: |
|||||||||||||||||||||||
|
Actions |
Status |
||||||||||||||||||||||||
|
Agreed by project management |
Hazard status |
|
|||||||||||||||||||||||
- Enter “R” in the appropriate column: correspondence of the risk index scores for red, yellow and green are defined in the project risk management policy
Figure: Example of a hazard and safety risk register (see also ECSS-M-ST-80)
|
Project |
Organization |
Date and issue |
|||||||
|
Rank |
No. |
Hazard scenario title |
Risk * |
Red |
Yellow |
Green |
Actions and status |
||
|
|
|
|
Safety |
|
|
|
|
||
|
|
|
|
Safety |
|
|
|
|
||
|
|
|
|
Safety |
|
|
|
|
||
|
|
|
|
Safety |
|
|
|
|
||
|
|
|
|
Safety |
|
|
|
|
||
|
|
|
|
Safety |
|
|
|
|
||
|
|
|
|
Safety |
|
|
|
|
||
|
|
|
|
Safety |
|
|
|
|
||
- Enter “R” from Hazard and safety risk registerFigure: Example of a ranked hazard and safety risk log
ANNEX(informative)Background information
Preliminary hazard analysis (PHA)
The purpose of the PHA is to identify safetycritical areas, to identify and evaluate hazards, and to identify design and operations requirements needed in the programme concept phase.
The PHA is performed to document an initial risk assessment of a concept or system. It is based on the best available data, including data from similar systems and lessons learned from other programmes The PHA provides consideration of the following, as a minimum, for the identification and evaluation of hazards:
Hazards sources (e.g. propellants, lasers, explosive, toxic substances, corrosives, hazardous construction materials, pressure systems and other energy sources).
Safetyrelated interface considerations among various parts or elements of the analysed item, facilities and GSE (e.g. material compatibility, contamination, electromagnetic interference, inadvertent activation, fire or explosion initiation and propagation, and hardware and software controls).
Environmental constraints, including the operating environment (e.g. drop, shock, vibration, extreme temperature, noise, exposure to toxic substances, confined space, fire, electrostatic discharge, lightning, electromagnetic effects, and ionizing and nonionizing radiation).
Operating test, maintenance, and emergency procedures.
Facilities, support equipment and training.
Safetyrelated equipment, safeguards and possible alternative approaches (e.g. monitoring, interlocks, redundancies, hardware or software failoperational — failsafe design consideration, fire protection, personal protective equipment, ventilation and noise or radiation attenuation).
Subsystem hazard analysis (SSHA)
The purpose of the SSHA is to identify hazards to personnel, vehicles, and other systems. The hazards can be caused by: loss of function; accidental activation; energy source; hardware failure; software deficiencies; interaction of components with subsystem; inherent design characteristics such as sharp edges and incompatible materials; and environmental conditions.
It defines the safetycritical functions, component fault conditions, generic hazard, safetycritical operations and environments associated with the subsystem.
System hazard analysis (SHA)
The purpose of the SHA is quite similar to the SSHA, but related to the system level. Once the subsystem levels have been established, a combination of subsystems makes up a system.
The SHA accomplishes the same purpose as the SSHA, but in terms of the interfaces and the overall system performance and operation.
Operating hazard analysis (OHA)
The purpose of the OHA is to identify hazards and recommend risk reduction alternatives in procedurally controlled activities during all phases of intended system usage. It can generally be part of the system hazard analysis (SHA), since it is interrelated with system safety features.
OHA identifies and evaluates hazards resulting from the implementation of operations or tasks performed by persons and equipment and considers the following:
planned system configuration at each activity phase,
facility interfaces,
planned environments,
supporting tools or other equipment specified in use,
operation or task sequence and limitations,
potential for unplanned events includinhazards introduced by human error, and
the requirements for warnings, cautions and special emergency procedures.
The OHA can be conducted in parallel with development of procedures for manufacturing, processing and operation.
Bibliography
|
ECSS-S-ST-00
|
ECSS system – Description, implementation and general requirements
|
|
ECSS-M-ST-10
|
Space project management — Project planning and implementation
|
|
ECSS-M-ST-40
|
Space project management — Configuration and information management
|
|
ECSS-Q-ST-30-02
|
Space product assurance — Failure modes, effects (and criticality) analysis (FMEA/FMECA)
|
|
ISO 14620-2:2000
|
Space systems — Safety requirements — Part 2: Launch site operations
|