address: Airport Alexandar the Great – Skopje
P.O. Box 9, 1043, Petrovec, Macedonia
tel. +389 2 3148100
fax. +389 2 3148239
5.8 Preliminary
System Safety
Assessment
Procedure
Version 1.0
Contents
1 INTRODUCTION ................................................................................................. 3
2 PROCEDURE ........................................................................................................ 3
2.1 Overview ......................................................................................................... 3
2.2 Procedure Inputs .............................................................................................. 5
2.3 Procedure Initiation ......................................................................................... 5
2.4 Procedure Steps ............................................................................................... 5
2.4.1 PSSA Planning ......................................................................................... 5
2.4.2 PSSA Execution and Reporting ............................................................... 5
2.4.3 PSSA Verification & Validation .............................................................. 7
2.5 Procedure Outputs ........................................................................................... 7
3 ROLES ................................................................................................................... 7
4 COMPETENCIES ................................................................................................. 8
5 APPLICABILITY .................................................................................................. 8
6 REFERENCES ...................................................................................................... 8
Approvals ....................................................................................................................... 9
CHANGE RECORD ...................................................................................................... 9
1 INTRODUCTION
The purpose of this document is to define the instructions for analyzing the design of
an ATM system to determine whether it has the potential to meet its Safety
Objectives.
2 PROCEDURE
2.1 Overview
The objective of this Safety Procedure is to determine the extent to which a system or
change meets its Safety Objectives by analysis of design information. This allows any
unacceptable risks inherent in the system design to be identified and quantified prior
to the implementation of the system, so that the system design can be modified to
render the risks tolerable.
The Safety Objectives arise from a Functional Hazard Assessment (FHA) [1] and are
based on abstract system functions, such as Surveillance, Tactical Conflict Detection,
etc.. In PSSA, the abstract system functions are mapped onto the corresponding
elements of the system design, and the failure characteristics of the system elements
are then analyzed to determine whether the Safety Objectives are likely to be met. In
the event that the Safety Objectives are not met, PSSA reveals the system elements
that are causing the problem so that a different design solution can be sought. The
main purpose of the process is to devise Safety Requirements for the system
elements which, if satisfied during system implementation, will ensure that the Safety
Objectives are met.
Following system implementation, the satisfaction of the Safety Requirements and
Safety Objectives is demonstrated via System Safety Assessment (SSA) [2].
PSSA may reveal that the system or change far exceeds its Safety Objectives, thus
indicating that the design is too conservative from the safety viewpoint. Conversely, it
may reveal that there is no practicable design solution to the Safety Objectives. In
such a case the Safety Objectives will need to be revisited, or the SSA be relied upon
to furnish operational evidence of safety, if the system or change is not to be curtailed
at the design stage.
Since PSSA is conducted on a design representation of the system, rather than an
abstract functional model as used by FHA, it may reveal new hazards which were not
foreseeable during FHA. These hazards are then analyzed by PSSA to produce
additional Safety Requirements which supplement those derived from the original
Safety Objectives.
PSSA comprises the following main steps:
PSSA Planning
PSSA Execution and Reporting
PSSA Verification & Validation
The flowchart for this Safety Procedure is given in Figure 1.
PMP/SMP Request for Change
Procedure Initiation 2.3
PSSA Planning PSSA Planning 2.4.1
System Design
Description and other Map system functions
inputs to system elemetns
For each Safety
Objective:
Deduce casual failure
modes
Compute probabilities
of casual failure modes
No
All Safety
Objectives
considered?
Yes
For each system
element:
PSSA Execution &
Compute worst case Reporting 2.4.2
probability & integrity
level
No
All system
elements
considered?
Yes
Perform common cause
analizys
Formulate Safety
Requirements
Validate/Record
assumptions
Prepare PSSAR Draft PSSAR
PSSA V&V
Final PSSAR
PSSA Verification &
Validation 2.4.3
User PSSAR Signatories
Figure 1 Flowchart
2.2 Procedure Inputs
The inputs used by the procedure steps shall be as defined in Table 1.
PSSA Application Required Inputs
All FHAR
System Design Description
Previous FHAs or PSSAs conducted on the system,
other systems within its environment, or higher/lower
level representations
Information to assist in prediction of failure mode
effects, mitigations and causes (such as simulations,
trials, and operational/technical occurrence reports)
Project / new system Project Management Plan
Safety Management Plan, if separate form PMP
System change Request for Change
Table 1 Procedure Inputs
2.3 Procedure Initiation
This procedure shall be initiated by a Project Management Plan (PMP), a project
Safety Management Plan (SMP) if separate from PMP, the Change Management
process.
2.4 Procedure Steps
2.4.1 PSSA Planning
2.4.1.1 The user, as defined in section 3, shall not be a participant in the design activities of
the system.
2.4.1.2 The user shall collate and verify the adequacy of all required procedure inputs, as
specified in 2.2.
2.4.1.3 The user shall review the system’s FHAR (and the project PMP and SMP, where
applicable) for any system-specific requirements for performing PSSA, and shall
incorporate them into the conduct of the PSSA.
2.4.1.4 The PSSA shall use appropriate Safety analysis techniques (prescribed in the
document Review of techniques to support the EATMP Safety Assessment
Methodology [4]) unless otherwise specified in a PMP or SMP endorsed by the Safety
Manager.
2.4.1.5 The user shall perform all the procedure steps in 2.4.2.
2.4.2 PSSA Execution and Reporting
2.4.2.1 The PSSA shall be conducted against a System Design Description which has the
following properties:
It includes the System Functional Description used by FHA
It describes the system in terms of its architecture, comprising design elements
and their interrelationships
It defines the dependencies on external systems
It provides traceability between the system design and the system requirements
It describes any functions or elements included in the design which arise from the
design process rather than from the system requirements
It defines the function and performance requirements of the design elements
It defines any means provided in the design specifically to meet the Safety
Objectives
It defines the behavior of the system as a result of failures
It defines the design solution to the RMA requirements
It defines any failure rate targets assigned to the design elements to satisfy RMA
requirements
It permits the functional representation of the system used by the FHA to be
mapped to the design elements
It defines any external means of mitigating system hazards
It defines the ATCO’s operation of the system
It defines the engineering operation of the system
It is under configuration control
2.4.2.2 For each system function from the system’s FHA, analyze how the function is
provided by the design elements, their interrelationships, and external systems.
2.4.2.3 Determine the correct level of decomposition of the system design at which the Safety
Requirements are to be specified. Hereinafter, these are termed the system elements.
2.4.2.4 For each Safety Objective in turn:
Show how (or whether) the function failure mode referred to in the Safety
Objective can be caused by credible failure modes of the system elements which
implement the function, including the effects of failure mode combinations, latent
failures, and repair times
Show how (or whether) any external events to the system can lead to the function
failure mode
Verify qualitatively that the system architecture is capable of satisfying the Safety
Objective
Where there exists a (combination of) system element failure(s) which can give
rise to the function failure mode, compute the allowable probabilities of the
system element failure modes which would satisfy the Safety Objective, including
the effects of latent failures and exposure times
2.4.2.5 For each system element in turn:
Collate all the allowable probabilities of the system element failure modes arising
from the analysis of all Safety Objectives in 2.4.2.4
For each failure mode in the set, assign the most stringent of the allowable
probabilities as the required probability of the failure mode for the element
Assign a required failure rate to the element based upon the required probabilities
of each failure mode and the failure mode ratios being assumed for the element
For hardware elements only, assign a required maintenance check interval to any
element which is a latent failure contributor to the function failure modes
Assign a required integrity level to the system element based upon its required
failure rate
2.4.2.6 For the system as a whole:
Verify the absence (or acceptability, if present) of any common causes of function
failure modes arising from system element failure modes, or external systems
Verify the absence (or acceptability, if present) of any common causes of element
failure modes arising from the system design, or external systems
Verify the absence (or acceptability, if present) of common effects on function
failure modes and their expected means of mitigation arising from the system
design, or external systems
Verify the acceptability of any new hazards (i.e. not captured by FHA) arising from
failure of system elements introduced by the design process, rather than to satisfy
functional requirements
Identify and assess any new hazards (i.e. not captured by FHA) inherent in the
system design which are not related to discrete failures
2.4.2.7 Where the FHA has assumed factors that would act as mitigations to the function
failure modes, assess the adequacy of any design evidence for such mitigations.
2.4.2.8 Co-ordinate and record any Functional Hazard Assessment activities (and additional,
or revised, Safety Objectives) deemed necessary to verify the acceptability of
common cause failures and other new hazards identified in 2.4.2.6.
2.4.2.9 Formulate system Safety Requirements comprising:
quantitative Safety Requirements applicable to the system elements, comprising
the set of required failure rates and integrity levels (and maintenance check
intervals, where applicable) from 2.4.2.5
qualitative Safety Requirements arising from 2.4.2.4 or 2.4.2.6, which are
applicable to the system design or its individual elements, necessary to satisfy
the Safety Objectives
2.4.2.10 Formulate process Safety Requirements comprising:
requirements for performing further PSSAs on the system, or lower level PSSAs
on the system elements
system-specific requirements for performing SSA, where they would not be
covered by the SSA Procedure [2]
system-specific requirements for processes to produce the evidence required for
SSA, where they would not be covered by the PMP
2.4.2.11 Formulate Safety Requirements and/or assumptions related to any external
events which are contributors to the function failure modes.
2.4.2.12 Provide two-way traceability between the Safety Objectives and the Safety
Requirements.
2.4.2.13 Review all assumptions from the system’s FHA and validate them against the
System Design Description, where possible.
2.4.2.14 Record any non-validated FHA assumptions to be carried forward to SSA, plus
any new or modified assumptions made during PSSA, either of a general nature
or related to specific aspects of the system or its assessment.
2.4.2.15 Specify any recommendations related to the system design, external systems, or
safety assessment, including the implications on satisfying the Safety
Objectives/Requirements.
2.4.2.16 Record all the results from 2.4.2.2 to 2.4.2.15 in a Preliminary System Safety
Assessment Report (PSSAR).
2.4.3 PSSA Verification & Validation
2.4.3.1 The user shall ensure that all stakeholders involved in the project (including product
owners) are included in the review process.
2.4.3.2 The review process shall ensure that the content of the safety case is technically
correct, and of an appropriate quality for publication.
2.4.3.3 The review process shall ensure that Safety Requirements meet Safety Objectives.
2.4.3.4 The review process shall ensure that the safety requirements are (and remain) correct
and complete.
2.4.3.5 The review process shall ensure that all critical assumptions are credible,
appropriately justified and documented.
2.4.3.6 The review shall ensure that the PSSA procedure has been followed correctly.
2.5 Procedure Outputs
2.5.1 The output from the execution of this Safety Procedure is a Preliminary System
Safety Assessment Report.
2.5.2 The contents of the PSSAR shall satisfy the requirements given in the PSSAR
Template [3].
2.5.3 The PSSAR shall be subject to a formal Change Management process upon any
change to the FHAR or System Design Description.
2.5.4 The signatories required shall be as defined in the PSSAR Template [3].
3 ROLES
3.1 The role of the user referred to in sections 2.4.1, 2.4.3, and 4 shall be fulfilled by the
persons defined in Table 2:
PSSA Application User
New system Project Manager
Operations -Project or change Project Manager
Systems - Project or change Project manager
Change to existing equipment Change Manager
Table 2 Applicable Users
The user may delegate his responsibilities for the execution of the three PSSA steps
to a safety expert, in case such expert is assigned to the project.
4 COMPETENCIES
4.1 The user, or the PSSA leader if different, shall have completed a course of instruction
in the use of this Safety Procedure.
4.2 The user, or the PSSA leader if different, shall have completed a course of instruction
in safety analysis/assessment techniques and methods.
4.3 The user, and the leader of the PSSA if different, shall have demonstrable knowledge
of ATM systems design, operation, and maintenance.
5 APPLICABILITY
5.1 This Safety Procedure shall be applied to systems comprising any combination of
people, procedure, and equipment elements.
5.2 This Safety Procedure shall be applied to additions, modifications, replacements, and
removals of existing systems or system components.
5.3 The use of this Safety Procedure for projects is mandatory unless otherwise specified
in a PMP or SMP and endorsed by the Safety Manager.
5.4 This Safety Procedure is applicable to the ATM services provision at M-NAV facilities.
6 REFERENCES
[1] M-NAV, Functional Hazard Assessment Procedure,
[2] M-NAV, System Safety Assessment Procedure,
[3] M-NAV, Preliminary System Safety Assessment Report Template
[4] EUROCONTROL, Review of techniques to support the EATMP Safety
Assessment Methodology
Approvals
Position / Name Signature Date
DPS Expert
Prepared:
Aleksandar Palchevski
Executive Director -
Accepted: Operations
Toni Prgomet
Executive Director –
Accepted: Systems
Živko Poposki
Safety Manager
Endorsed:
Fahrudin Hamidi
Chairman of
Authorized: Management Board
Živko Poposki
CHANGE RECORD
Edition – Revision Revision date Pages/Sections Remarks
affected
Version 1.0 15/12/2009
