Safety Assessment
Safety Assessment
The European Organisation for the Safety of Air Navigation
Safety Assessment
Safety Assessment is an EC1035/2011 requirement
EC1034-2011 helps understanding which changes
require a formal assessment that needs NSA review
Experience has shown that the “Safety
Consideration Process” provides good
understanding of the changes
Safety Assessment
The Only acceptable means of compliance to
ESARR4 (~EC1035/2011) as of today is SAM (with
limitations)
SAM is a toolbox mainly known for its FHA-PSSASSA processes
- Functional Hazard Assessment
- Preliminary System Safety Assessment
- System Safety Assessment
SAM most suitable for hardware changes for
which we can have an influence on the design,
usage much more difficult for many other
changes, procedures, airspace etc…
Safety Assessment
eSAM
• eSAM V2.1 helps navigating through the
documentation set of "ANS Safety Assessment
Methodology";
• http://www.eurocontrol.int/safety/public/site_prefer
ences/display_library_list_public.html#17
Safety Assessment
OPS Concept
(concept
elements)
Safety consideration
report
Argumented rationale for
not going further
Safety considerations
N
Brainstorming
Go further?
Y
Initial safety argument
Initial Safety argument
(termination)
Argumented rationale for
not going further
N
First attempt to construct
Safety Argument (high
level)
Go further?
Y
Safety Plan
Safety assessment
(activities as per Safety Plan)
SAFETY CASE
Safety Case Report
Translation of initial
argument into required
activities
Conduct of activities
Production of the report
Safety Assessment
Safety considerations process
Safety Assessment
Safety considerations
No operational concept
Scope unclear
Missing assumptions
Safety requirements unrealistic
Bad arguments
What are the needs for change?
What are the new system boundaries? (OPS Concept)
Are there (initial) assumptions? (OPS Concept)
Are (Initial) Safety requirements realistic?
Will it be possible to build an argument?
Little or no evidence
What evidence could be provided?
Errors in calculations
Would it feasible and beneficial to quantify?
No concept of operations
Impact at boundaries not addressed
Hazards classification questionable
SAFETY BENEFITS OF NORMAL OPERATIONS?
How shall the new system/change be operated?
What are the interfaces? What impact foreseeable?
How and who will assess hazards?
In what way is the proposed operational concept different from
current one?
Safety Assessment
How did we do things so far?
Good
Specifications
We have
tested the
system
System OK
We have
We have
RevisedWhat
trained
wethe
used
procedures
staff
to
We have
a fall-back
do
system
Staff
OK if
What
we
concluded
OK
breakdown
New center
will start
operations
Decision
to go
operational
On XX/XX/XX
We have
temporary
procedures
Switching over
should be OK
Safety Assessment
What are we asked to do today?
Good
Specifications
We have
tested the
system
System OK
Good
Specifications
We have
tested the
system
We have
Revised
procedures
It will be safe to
We have
We have
provide
operations
trained the
Contingency
from
staffnew center measures
Staff
OK
We have
Revised
procedures
OK if
breakdown
New center
We have
We have
will
start
operations
trained the
Contingency
staff
measures
On XX/XX/XX
We have
temporary
procedures
Switching over
should be OK
We have
temporary
procedures
Safety Assessment
OPS Concept
(concept
elements)
Initial safety argument
Is there anything that we
know we will only be able to prove
after implementation but
we are confident we are right
Caveats
Arg0
We need to
demonstrate that
change will be safe
Criteria for safety
(ESARR4)
Why do we want
to do this change?
CONOPS
How are we
going to do that?
Arg1
Safe by design
How are we
going to do that?
Arg2
Safe after
implementation
How are we
going to do that?
Arg3
Safe to migrate
operations
How are we
Life cycle
going to do that?
Safety Plan
Arg4 On-going
operations will be
safe
How are we
going to do that?
Safety Assessment
Safety Assessment for DQR
[DQR-REQ-300] The safety assessment process to support
the establishment of new or updated data quality
requirements shall be documented and include all the
necessary steps to derive the data quality requirements
to ensure data of sufficient quality are provided to meet
the intended use for each data item under
consideration, as a minimum:
Safety Assessment
Safety Assessment for DQR
1. Identify all relevant uses for the aeronautical data item or dataset.
2. Conduct Hazard Identification and Analysis.
3. Determine accuracy and resolution requirements taking into consideration:
a) The functionality, performance and availability required by the intended use
to achieve an acceptable level of safety.
b) The inherent limitations in originating the data item or dataset.
4. Determine the data integrity level, based on the results of step 1 and step 2, for
the most stringent use.
5. Consider the necessity to assign requirements for the ability to determine the
origin of the data, other than the ones already defined in Annex I Part C of
Commission Regulation (EU) 73/2010.
6. Consider the necessity to assign requirements for the level of assurance that the
data is made available to the next intended user prior to its effective start
date/time and not deleted before its effective end date/time, other than the ones
already defined in Article 7(3) and Article 7(4) of Commission Regulation (EU)
73/2010.
Safety Assessment
Initial safety argument
Let’s have a look at the MS-Visio figures
Safety Assessment
Change/Project
using the « data »
is « safe »
Arg – 1
Design of the
« Change/
Project » is safe
… Further development of Arg-1 ...
Arg – 1.X.X.Y.N
Data and associated quality
requirements are “adequate “
“
Arg – 2
Implementation of
the « Change/
Project » is safe
Arg – 3
Migration of the
« Change/
Project » is safe
Arg – 3
On-going
operations of the
« Change/
Project » are safe
Safety Assessment
C: Adequate is defined in the
context of the project
J :Introduction of new
applications require
changes to the DQR
Cr: Criteria for
Safety (ESARR4)
Data and
associated quality
requirements are
“adequate “
Risk assosiated
with this data is
managed
Risk assessment
has been
performed
Mitigation means
are in place
Data Quality
Requirements (as
in HL) are
« enough »
Process is trustful
Conops: User
Requirements
FHA/PSSA
FHA/
PSSA
New Data has
NOT yet a quality
label (i.e.: is not in
the HL)
Data is in the HL
SMS
Procedures
Data Quality Requirements (as in
HL) are NOT « enough »; risk has
been mitigated through additional
risk reduction measures
Data Quality
Requirements are
defined
FHA/
PSSA
FHA/
PSSA
Change/Project
Design
documentations
Process defining
the « Data Quality
Requirements » is
thrustworthy
SMS
Procedures
Change/Project
Design
documentations
Project
Management
Procedures
Safety Assessment
Q&A
The European Organisation for the Safety of Air Navigation