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