SIST EN 16602-40:2018

SLOVENSKI STANDARD
01-julij-2018
1DGRPHãþD
SIST EN ISO 14620-1:2004
Zagotavljanje kakovosti proizvodov v vesoljski tehniki - Varnost
Space product assurance - Safety
Raumfahrtsysteme - Sicherheit
Systèmes spatiaux - Sécurité
Ta slovenski standard je istoveten z: EN 16602-40:2018
ICS:
49.140 Vesoljski sistemi in operacije Space systems and
operations
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD
EN 16602-40
NORME EUROPÉENNE
EUROPÄISCHE NORM
April 2018
ICS 49.140
Supersedes EN ISO 14620-1:2002
English version
Space product assurance - Safety
Assurance produit des projets spatiaux - Sécurité Raumfahrtsysteme - Sicherheit
This European Standard was approved by CEN on 18 September 2017.

CEN and CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for
giving this European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical
references concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to
any CEN and CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN and CENELEC member into its own language and notified to the CEN-CENELEC
Management Centre has the same status as the official versions.

CEN and CENELEC members are the national standards bodies and national electrotechnical committees of Austria, Belgium,
Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany,
Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania,
Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom.

CEN-CENELEC Management Centre:
Rue de la Science 23, B-1040 Brussels
© 2018 CEN/CENELEC All rights of exploitation in any form and by any means Ref. No. EN 16602-40:2018 E
reserved worldwide for CEN national Members and for
CENELEC Members.
Table of contents
European Foreword . 7
1 Scope . 9
2 Normative references . 10
3 Terms, definitions and abbreviated terms . 11
3.1 Terms from other standards . 11
3.2 Terms specific to the present standard . 11
3.3 Abbreviated terms. 13
3.4 Nomenclature . 14
4 Safety principles . 15
4.1 Objective . 15
4.2 Policy . 15
4.2.1 General . 15
4.2.2 Implementation . 15
4.3 Safety programme . 16
5 Safety programme . 17
5.1 Scope . 17
5.2 Safety programme plan . 17
5.3 Conformance . 18
5.4 Safety organization . 18
5.4.1 Safety manager . 18
5.4.2 Safety manager access and authority . 18
5.4.3 Safety audits . 19
5.4.4 Approval of documentation . 19
5.4.5 Approval of hazardous operations . 19
5.4.6 Representation on boards . 19
5.4.7 Safety approval authority. 20
5.5 Safety risk assessment and control . 20
5.6 Safety critical items . 20
5.7 Project phases and safety review cycle . 20
5.7.1 Safety program tasks and reviews . 20
5.7.2 Progress meetings . 24
5.7.3 Safety reviews . 24
5.8 Safety compliance demonstration . 25
5.9 Safety training . 25
5.9.1 General . 25
5.9.2 Product specific training . 25
5.9.3 General awareness briefings . 26
5.9.4 Basic technical training . 26
5.9.5 Training records . 26
5.10 Accident-incident reporting and investigation . 26
5.11 Safety documentation . 26
5.11.1 General . 26
5.11.2 Safety data package . 27
5.11.3 Safety deviations and waivers . 27
5.11.4 Safety lessons learned . 28
5.11.5 Documentation of safety critical items . 28
6 Safety engineering . 29
6.1 Overview . 29
6.2 Safety requirements identification and traceability . 29
6.3 Safety design objectives . 29
6.3.1 Safety policy and principles . 29
6.3.2 Design selection . 29
6.3.3 Hazard reduction precedence . 30
6.3.4 Environmental compatibility . 32
6.3.5 External services . 32
6.3.6 Hazard detection - signalling and safing . 32
6.3.7 Space debris mitigation . 33
6.3.8 Atmospheric re-entry . 33
6.3.9 Safety of Earth return missions . 33
6.3.10 Safety of human spaceflight missions . 34
6.3.11 Access . 34
6.4 Safety risk reduction and control . 34
6.4.1 Severity of hazardous event and function criticality . 34
6.4.2 Failure tolerance requirements . 36
6.4.3 Design for minimum risk . 37
6.4.4 Probabilistic safety targets . 38
6.5 Identification and control of safety-critical functions . 39
6.5.1 Identification . 39
6.5.2 Inadvertent operation . 39
6.5.3 Status information . 39
6.5.4 Safe shutdown and failure tolerance requirements . 39
6.5.5 Electronic, electrical, electromechanical components . 40
6.5.6 Software functions. 40
6.6 Operational Safety . 42
6.6.1 Basic requirements . 42
6.6.2 Flight operations and mission control . 42
6.6.3 Ground operations . 43
7 Safety analysis requirements and techniques . 46
7.1 Overview . 46
7.2 General . 46
7.3 Assessment and allocation of requirements . 47
7.3.1 Safety requirements . 47
7.3.2 Additional safety requirements . 47
7.3.3 Define safety requirements - functions . 47
7.3.4 Define safety requirements - subsystems . 47
7.3.5 Justification . 47
7.3.6 Functional and subsystem specification . 47
7.4 Safety analyses during the project life cycle. 47
7.5 Safety analyses . 48
7.5.1 General . 48
7.5.2 Hazard analysis . 48
7.5.3 Safety risk assessment . 49
7.5.4 Supporting assessment and analysis . 49
8 Safety verification . 53
8.1 General . 53
8.2 Hazard reporting and review . 53
8.2.1 Hazard reporting system . 53
8.2.2 Safety status review . 53
8.2.3 Documentation . 53
8.3 Safety verification methods . 54
8.3.1 Verification engineering and planning . 54
8.3.2 Methods and reports . 54
8.3.3 Analysis . 54
8.3.4 Inspections . 54
8.3.5 Verification and approval . 55
8.4 Verification of safety-critical functions . 55
8.4.1 Validation . 55
8.4.2 Qualification . 55
8.4.3 Failure tests . 56
8.4.4 Verification of design or operational characteristics . 56
8.4.5 Safety verification testing . 56
8.5 Hazard close-out . 56
8.5.1 Safety assurance verification . 56
8.5.2 Hazard close-out verification . 57
8.6 Declaration of conformity of ground equipment . 57
Annex A (informative) Analyses applicability matrix . 58
Annex B (normative) Safety programme plan - DRD . 60
B.1 DRD identification . 60
B.1.1 Requirement identification and source document . 60
B.1.2 Purpose and objective . 60
B.2 Expected response . 60
B.2.1 Contents . 60
B.2.2 Special remarks . 61
Annex C (normative) Safety verification tracking log (SVTL) DRD . 62
C.1 DRD identification . 62
C.1.1 Requirement identification and source document . 62
C.1.2 Purpose and objective . 62
C.2 Expected response . 62
C.2.1 Contents . 62
C.2.2 Special remarks . 64
Annex D (normative) Safety analysis report including hazard reports -
DRD . 66
D.1 DRD identification . 66
D.1.1 Requirement identification and source document . 66
D.1.2 Purpose and objective . 66
D.2 Expected response . 66
D.2.1 Contents . 66
D.2.2 Special remarks . 67
Annex E (informative) Criteria for probabilistic safety targets . 68
E.1 Objectives of probabilistic safety targets . 68
E.2 Criteria for probabilistic safety targets . 68
Annex F (informative) Applicability guidelines . 69
Annex G (informative) European legislation and ‘CE’ marking . 75
G.1 Overview . 75
G.2 CE mark . 75
G.3 Responsibility of the design authority . 75
G.4 Declaration of conformity . 76
G.5 References . 76
Bibliography . 78

Figures
Figure C-1 : Safety verification tracking log (SVTL) . 65

Tables
Table 6-1: Severity categories . 36
Table 6-2: Criticality of functions . 36
Table 6-3: Criticality category assignment for software products vs. function criticality . 41

Table A-1 : Safety deliverable documents . 59

European Foreword
This document (EN 16602-40:2018) has been prepared by Technical Committee CEN/CLC/JTC 5
“Space”, the secretariat of which is held by DIN (Germany).
This document (EN 16602-40:2018) originates from ECSS-Q-ST-40C Rev.1.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by October 2018, and conflicting national standards shall
be withdrawn at the latest by October 2018.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such
patent rights.
This document supersedes EN ISO 14620-1:2002.
The main changes with respect to EN ISO 14620-1:2002 are listed below:
• new EN number,
• Complete and thorough review with the focus on simplification and streamlining to improve
clarity and consistency of requirements.
• Applicability guidelines to the different space systems has been defined (see applicability matrix
provided in Annex E).
• System safety programme requirements reworked, i.e. the system safety programme supports the
risk management process described in EN 16601-80 (based on ECSS-M-ST-80C).
• Space debris mitigation streamlined.
• Atmospheric re-entry addressed.
• Safety design principles reworked.
• Safety risk reduction and control updated.
• Safety analysis requirements and techniques updated.
• Common scheme for consequence severity classification used in EN 16602-30 and EN 16602-40
(based on ECSS-Q-ST-30C and ECSS-Q-ST-40C).
• Identification and control of safety-critical functions updated.
• Established link to EN 1602-10-04 “Critical-item control” (based on ECSS-Q-ST-10-04).
• Informative annex on European legislation and ‘CE’ marking added (Annex F).
• DRDs revisited and updated.
• Document reworked to be in compliance with ECSS standards drafting rules.
This document has been prepared under a standardization request given to CEN by the European
Commission and the European Free Trade Association.
This document has been developed to cover specifically space systems and has therefore precedence
over any EN covering the same scope but with a wider domain of applicability (e.g. : aerospace).
According to the CEN-CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of
Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Serbia, Slovakia, Slovenia,
Spain, Sweden, Switzerland, Turkey and the United Kingdom.

Scope
This Standard defines the safety programme and the safety technical
requirements aiming to protect flight and ground personnel, the launch vehicle,
associated payloads, ground support equipment, the general public, public and
private property, the space system and associated segments and the
environment from hazards associated with European space systems.
This Standard is applicable to all European space projects.
This standard may be tailored for the specific characteristic and constraints 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.

EN reference Reference in text Title
EN 16601-00-01 ECSS-S-ST-00-01 ECSS system – Glossary of terms
EN 16603-10 ECSS-E-ST-10 Space engineering – System engineering general
requirements
EN 16603-32-01 ECSS-E-ST-32-01 Space engineering – Fracture control
EN 16603-32-10 ECSS-E-ST-32-10 Space engineering – Structural factors of safety for
spaceflight hardware
EN 16603-40 ECSS-E-ST-40 Space engineering – Software general requirements
EN 16601-10 ECSS-M-ST-10 Space project management – Project planning and
implementation
EN 16601-40 ECSS-M-ST-40 Space project management – Configuration and
information management
EN 16601-80 ECSS-M-ST-80 Space project management – Risk management
EN 16602-10 ECSS-Q-ST-10 Space product assurance – Product assurance
management
EN 16602-10-04 ECSS-Q-ST-10-04 Space product assurance – Critical-item control
EN 16602-20 ECSS-Q-ST-20 Space product assurance – Quality assurance
EN 16602-30 ECSS-Q-ST-30 Space product assurance – Dependability
EN 16602-60 ECSS-Q-ST-60 Space product assurance – Electrical, electronic and
electromechanical (EEE) components
EN 16602-70 ECSS-Q-ST-70 Space product assurance – Materials, mechanical parts
and processes
EN 16602-80 ECSS-Q-ST-80 Space product assurance – Software product assurance
Terms, definitions and abbreviated terms
3.1 Terms from other standards
a. For the purpose of this Standard, the terms and definitions from ECSS-S-
ST-00-01 apply (see in clause 3.2 differences for "fail safe" and "system"),
in particular for the following terms:
1. accident
2. failure
3. catastrophic
4. critical
5. emergency
6. ground segment
7. hazard
8. hazardous event
9. inhibit
10. risk
11. safety
12. safing
13. severity
14. safety-critical function
15. space segment
16. system
3.2 Terms specific to the present standard
3.2.1 cause
action or condition by which a hazardous event is initiated (an initiating event)
NOTE 1 The cause can arise as the result of failure,
human error, design inadequacy, induced or
natural environment, system configuration or
operational mode(s).
NOTE 2 This definition is specific to this Standard,
when used in the context of hazard analysis.
3.2.2 criticality
classification of a function or of a software, hardware or operation according to
the severity of the consequences of its potential failures
NOTE 1 Refer to clauses 6.4.1 and 6.5.6.
NOTE 2 This notion of criticality, applied to a function
or a software, hardware or operation, considers
only severity, differently from the criticality of a
failure or failure mode (or a risk), which also
considers the likelihood or probability of
occurrence.
3.2.3 fail safe
property of a system (or part of it), which prevents its failures from resulting in
critical or catastrophic consequences
3.2.4 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
3.2.5 hazardous command
command that can remove an inhibit to a safety-critical function or activate a
hazardous subsystem
3.2.6 hazard reduction
process of elimination or minimization and control of hazards
3.2.7 hazard scenario
sequence of events leading from the initial cause to the unwanted safety
consequence
NOTE The cause can be a single initiating event, or an
additional action or a change of condition
activating a dormant problem.
3.2.8 operator error
failure of an operator to perform an action as required or trained or the
inadvertent or incorrect action of an operator
3.2.9 safety approval authority
entity that defines or makes applicable, for a given project, detailed technical
safety requirements, and reviews their implementation
3.2.10 safety audit
independent examination to determine whether the procedures specific to the
safety requirements are implemented effectively and are suitable to achieve the
specified objectives
3.2.11 safety risk
measure of the threat to safety posed by the hazard scenarios and their
consequences
NOTE 1 Safety risk is always associated with a specific
hazard scenario or a particular set of scenarios.
The risk posed by a single scenario is called
individual scenario risk. The risk posed by a set
of scenarios with the same top consequence is
called overall risk.
NOTE 2 The magnitude of a safety risk is a combination
of the severity and the likelihood of the
consequence.
3.2.12 safety status parameter
parameter that makes it possible to assess the status of an implemented hazard
control
3.3 Abbreviated terms
For the purpose of this Standard, the abbreviated terms from ECSS-S-ST-00-01
and the following apply:
Abbreviation Meaning
acceptance review
AR
configuration control board
CCB
critical design review
CDR
Conformité Européenne
CE
commissioning result review
CRR
electronic, electrical, electromechanical
EEE
end-of-life review
ELR
electro-magnetic compatibility
EMC
failure modes and effects analysis
FMEA
failure modes, effects and criticality analysis
FMECA
flight safety data package
FSDP
flight readiness review
FRR
fault tree analysis
FTA
ground safety data package
GSDP
ground support equipment
GSE
International Electrotechnical Commission
IEC
launch readiness review
LRR
low voltage directive
LVD
mandatory inspection point
MIP
nonconformance review board
NRB
US Nuclear Regulatory Commission contractor report
NUREG-CR
operational readiness review
ORR
preliminary design review
PDR
pressure equipment directive
PED
pressure ground support equipment
PGSE
preliminary requirements review
PRR
qualification review
QR
radio & telecommunications terminal equipment
R&TTE
restriction of certain hazardous substances
RoHS
safety data package
SDP
system requirements review
SRR
safety verification tracking log
SVTL
test review board
TRB
waste electrical and electronic equipment
WEEE
3.4 Nomenclature
The following nomenclature applies throughout this document:
a. The word “shall” is used in this Standard to express requirements. All
the requirements are expressed with the word “shall”.
b. The word “should” is used in this Standard to express recommendations.
All the recommendations are expressed with the word “should”.
NOTE It is expected that, during tailoring,
recommendations in this document are either
converted into requirements or tailored out.
c. The words “may” and “need not” are used in this Standard to express
positive and negative permissions, respectively. All the positive
permissions are expressed with the word “may”. All the negative
permissions are expressed with the words “need not”.
d. The word “can” is used in this Standard to express capabilities or
possibilities, and therefore, if not accompanied by one of the previous
words, it implies descriptive text.
NOTE In ECSS “may” and “can” have completely
different meanings: “may” is normative
(permission), and “can” is descriptive.
e. The present and past tenses are used in this Standard to express
statements of fact, and therefore they imply descriptive text.
Safety principles
4.1 Objective
The objective of safety assurance is to ensure that all safety risks associated with
the design, development, production and operations of space product are
adequately identified, assessed, minimized, controlled and finally accepted
through the implementation of a safety assurance programme.
4.2 Policy
4.2.1 General
The ECSS safety policy is to:
• ensure that space systems do not cause a hazard to, in order of priority:
 human life,
 the environment,
 public and private property (including launch facilities),
 spacecraft and launcher,
 ground support equipment and facilities,
• determine and evaluate the safety risks associated with project activities,
• minimize safety risks in a technically effective and cost effective manner,
• ensure adequate verification of safety control measures.
4.2.2 Implementation
The ECSS safety policy is implemented by applying a safety programme which
ensures that:
• safety is designed into the system,
• safety controls are adequately implemented in the verification plan,
• safety requirements including launch centre safety regulations are met,
• hazards are identified, and eliminated or, where this is not possible,
minimized, ranked and controlled in accordance with project objectives
in a manner acceptable to the customer and to the safety organisations
involved in the implementation of the mission.
4.3 Safety programme
The safety programme comprises the:
• identification and control of all safety related risks with respect to the
design, development and operations of space products,
• assessment of the risks based on qualitative and quantitative analysis as
appropriate,
• application of a hazard reduction precedence and of control measures of
the residual risks.
Safety programme
5.1 Scope
a. The supplier shall establish and maintain a safety programme to assure
conformance with project safety policy and requirements.
b. The safety programme shall establish a safety management system to
implement provisions of this Standard - commensurate with the
programme requirements and tailored by the customer
NOTE 1 For tailoring, refer to clause 1.
NOTE 2 The system safety programme requirements are
subject to tailoring, without diminishing the
intent to protect flight and ground personnel,
the launch vehicle, associated payloads, ground
support equipment, the general public, public
and private property, the space system and
associated segments and the environment from
hazards associated with space systems.
NOTE 3 As support to tailoring, informative Annex F
provides a guideline for determining the
applicability of this standard depending on the
type of project.
5.2 Safety programme plan
a. The supplier shall establish and maintain a safety programme plan in
conformance with the DRD in Annex B.
NOTE The plan can either be included as part of an
overall project product assurance plan or as a
separate safety programme plan.
b. The supplier shall cover, in his safety programme plan, the safety tasks
for the project phases in conformance with 5.7.1.
5.3 Conformance
a. The supplier shall comply with all applicable national or international
safety regulations.
NOTE This includes launch site safety regulations,
space debris mitigation and re-entry safety
regulations, etc.
b. <>
c. The implementation of safety requirements shall not be compromised by
other requirements.
NOTE For example: security requirements.
5.4 Safety organization
5.4.1 Safety manager
a. Each supplier shall appoint a safety manager who has appropriate
training or experience.
b. The safety manager shall have organisational authority and
independence to:
1. establish and maintain a safety programme in accordance with the
project safety requirements,
2. manage all safety assurance aspects of the design of the system
(including software) and its operation in accordance with the
Safety Plan,
3. coordinate the interfaces:
(a) with the relevant bodies involved in the project in
accordance with the safety plan,
(b) with the safety launcher authority.
NOTE Depending on the project safety criticality, the
safety manager can be combined with other
functions (e.g. PA manager) when agreed with
the customer.
5.4.2 Safety manager access and authority
5.4.2.1 Access
a. The safety manager shall:
1. have the right of access to safety-related data relevant to project
safety in conformance with ECSS-M-ST-40,
2. have unimpeded access to any management level without
organizational constraint on any aspect of project safety.
5.4.2.2 Authority
a. The safety manager or safety relevant authority shall have the authority
to:
1. reject any project document, or to stop any project activity that
does not conform to approved safety requirements or procedures,
2. interrupt hazardous operations when it becomes clear by the
Safety Manager that the operation does not conform to the agreed
measures defined in the corresponding hazard report and derived
approved hazard procedure.
5.4.3 Safety audits
a. The supplier shall perform safety audits or reviews to verify compliance
to project safety policy and requirements.
b. The safety audits shall be in accordance with ECSS-M-ST-10 and ECSS-Q-
ST-10.
NOTE The safety audits can be part of the project
audits.
c. The customer shall be informed of the audit schedule.
5.4.4 Approval of documentation
a. Documentation related to safety shall be approved by the safety manager
upon his verification of completeness, compliance with stated safety
requirements and formal closeout of open safety verification items (as
defined and agreed during safety audits and reviews).
5.4.5 Approval of hazardous operations
a. The safety manager (or a designated representative) shall have concluded
the review of, and approved, any hazardous operation before it is
executed.
5.4.6 Representation on boards
a. The safety manager or designated delegate shall be represented at
configuration control boards (CCBs), nonconformance review boards
(NRBs), test review board (TRBs), and at qualification, and acceptance
reviews, where safety requirements and safety-critical functions are
involved.
b. The safety function shall be further represented at all boards dealing with
health matters where exposure or endurance limits are defined for flight
and ground crews.
5.4.7 Safety approval authority
a. The safety approval authority shall:
1. review and disposes the safety data submittals,
2. approve the close-out of hazards,
3. decide on deviations and waivers, and finally
4. accept the statement of safety compliance.
5.5 Safety risk assessment and control
a. The safety risk identification, reduction and control shall be part of the
project's risk management process as specified in ECSS-M-ST-80.
b. Safety risk identification, reduction and control shall be a continuous and
iterative process throughout the project life cycle, encompassing
1. allocation of safety requirements;
2. hazard and safety risk identification;
3. evaluation (including categorisation) of consequence severity;
4. hazard and safety risk reduction and control;
5. close out and acceptance of residual risk.
c. For the identification of hazards and associated safety risks,
consideration shall be given to past experience, studies, ground and
flight tests, reviews, the industrial process as well as the operational use.
5.6 Safety critical items
a. The safety critical items shall be part of the project's overall critical items
control programme as specified in ECSS-Q-ST-10-04.
5.7 Project phases and safety review cycle
5.7.1 Safety program tasks and reviews
5.7.1.1 Mission analysis/Needs identification - Phase 0
a. Safety analysis shall support the identification of sources of safety risk as
well as the performance of preliminary trade-off analyses between
alternative system concepts.
b. The following safety programme tasks shall apply for human spaceflight
programmes and safety critical systems:
1. Analyse safety requirements and lessons-learnt associated with
similar previous missions;
2. Perform preliminary hazard analysis of the proposed system and
operations concept to support concept trade-offs;
3. Perform comparative safety risk assessment of the concept options;
4. Identify the relevant project safety requirements;
5. Plan safety activities for the feasibility phase;
6. Support the mission definition review.
NOTE These tasks also serve as a guideline for other
space programmes.
5.7.1.2 Feasibility - Phase A
a. Safety analysis shall support trade-off analyses in arriving at the concept
that has acceptable safety risk considering the project and mission
constraints.
b. The design technology selected and the operational concept to be
implemented shall be selected based on the analysis data for the safest
system architecture to eliminate or reduce hazards to acceptable levels.
c. The following safety programme tasks shall apply for human spaceflight
programmes and safety critical systems:
1. Commence hazard analyses of the design and operations concepts
in order to identify applicable system level hazards, hazardous
conditions, and potential hazardous events and consequences;
2. Support concept trades by identifying safety critical aspects of the
concept options;
3. Apply hazard elimination and minimization and make safety
recommendations;
4. Perform comparative safety risk assessments of the concept
options;
5. Identify system level safety critical functions;
6. Identify system level project specific safety requirements;
7. Plan safety activities for the project definition phase;
8. Support the preliminary requirements review.
NOTE These tasks also serve as a guideline for other
space programmes.
5.7.1.3 Preliminary definition - Phase B
a. The safety analysis shall support a continued and more detailed safety
optimization of the system design and operations and the identification
of technical safety requirements and their applicability.
b. The analysis shall also provide inputs to safety risk assessment in
support of safety risk evaluation, the identification of risk contributors in
the design and in the operational concept.
c. The following safety programme tasks shall apply for human spaceflight
programmes and safety critical systems:
1. Update hazard analysis in support of design and mission concept
definition activities; identify additional project specific safety
requirements;
2. Update safety critical functions identification, and define the
failure tolerance requirements;
3. Identify emergency, warning, and caution situations;
4. Update the system safety risk assessment as part of the
contribution provided by the safety domain to the risk
management process;
5. Identify project safety requirements;
6. Ensure that project requirement documentation and activities
comply with project safety requirements;
7. Support a system requirements review and preliminary design
review;
8. Plan verification of safety requirements implementation;
9. Prepare the safety plan for the detailed definition, production and
qualification phase.
NOTE These tasks also serve as a guideline for other
space
...