[SystemSafety] RV: Preliminary Hazard Analysis - Approaches

Mon Apr 29 11:54:51 CEST 2013

I agree with you that there is no universal definition of PHA.

Regarding your comment:

“In some industries, there may be sufficient past experience to allow a
checklist of top-level hazards to be drawn up. In the railway industry,
this might perhaps be done with high confidence that it is close to being
exhaustive of the principal causes of risk that a new model of train or
signalling system could throw up.”

I also consider a checklist useful as input to PHA, and as you say it would
be useful to start with such a checklist. However, I don’t consider such a
list to be close to being exhaustive of the principal causes of risk that a
railway system could throw up.

This checklist is a list of hazardous events. “Hazardous event” has been
used in the EN 50126 standard to mean an accident, and it is recommended to
be interpreted as such. Therefore, the checklist may be considered as a
list of accidents. If you consider the sequence: *Cause* – *Hazard* – *
Accident*, this list is focused only on the “Accident” scenario. It does
not consider the previous events in the sequence “Hazard” and “Cause”. Each
hazardous event could be generated by multiple and distinct causes.

The scope of such a checklist is the entire railway system. It is a generic
model whose relevance to the line must be examined. If you use this
checklist in order to perform a top-down analysis, as I mentioned
previously, you may overlook some hazards which could be generated
specifically by your system, as they depend on where the system will be
implemented (the application). It is possible to identify such hazards,
even at a relatively early stage in the design, using bottom-up analysis.
Particularly if specific functions related to the application have been
defined for the system (e.g. protection against extreme temperatures or
other environmental conditions). Identifying failure conditions of such
functions may aid in identifying potential hazards only associated with
your system, based on its application conditions.

Even though the checklist can be useful for including hazards identified
from past experience, it is limited to these hazards, it does not consider
the characteristics of the system you are supplying (except in a generic
way) and its application environment.

Regarding your other points, particularly (2):

2. Customers have a way of putting requirements into their specifications
simply because they are told that a standard demands them. Many, and
perhaps most, customers are not well informed in the matter of SILs, and
any intelligent supplier should challenge them if they make demands such as
those to which you refer. Sometimes it is a good idea for contractors to
arrange training for their customers.

In EN 50126-2, there is a section entitled “Misuse of SILs and warnings”
which states:

“*SILs should not be used for describing system attributes, e.g. “this is a
SIL 4 interlocking system” .. because SILs may only be allocated to
functions*.”

Requirements in customer specifications may be stated in a form similar to
“System X must be SIL Y”. In this case, the customer already has an
expectation of what the SIL of “System X” will be at the beginning of the
project.

I understand that the use of the SIL concept in this way is erroneous. I
mentioned in my previous email “*I have come across projects where it is
required to specify an estimated SIL of system functions to the client at
very early stages of the project*.” However, the situation may be even
worse. It could be expected to erroneously agree with the customers
expectation of “SIL Y” for “System X” (without differentiating between
“system” and “system functions”) and in order to comply with the
requirement, the subsequent safety analyses simply “confirm” the initial
requirement.

I agree with you, such demands should be challenged. However, a number of
factors should be taken into account.

-       You are challenging a customer who is unlikely to have an
understanding of the SIL concept in the first place. You may simply get a
response like “It’s a requirement, System A must have SIL B”.

-       Regarding your suggestion concerning training, you must consider
that in some cases there is no time, or funding assigned, for training.

-       (Other) political factors.

Your final point (3):

3. You ask, "Would it really be enough to assign an initial SIL only based
on the top hazards selected?" I don't know what you mean by "enough". And
you don't say what it is that the SIL would be assigned to. And I'm
confused by your reference to "an initial SIL" (singular) with respect to
"hazards" (plural). So I can't say that I understand your question.
However, I'll comment that a SIL is not determined from knowledge of one or
more hazard. If I were confronted with such a proposition, my initial
hypothesis would be that both supplier and customer need enlightenment.

By “enough” I meant “would you have enough information regarding system
functions/application conditions/etc.”, that is, you only have a list of
hazardous events without having performed any bottom-up analysis (see my
first point).

I do say what it is that the SIL would be assigned to, in the previous
sentence of that email I specify that sometimes the customer requires the
supplier to assign an initial SIL to system *functions*. I don’t consider a
SIL to be determined from knowledge of one or more hazards, although having
detailed knowledge of the hazards and their severity and frequency should
help to determine the probability of dangerous failure you are willing to
accept from your safety functions.

Thank you for your email.

Regards,

Myriam.

2013/4/27 nfr <felix.redmill at newcastle.ac.uk>

>  It seems that perhaps you are seeking a universal definition of PHA, with
> clear definitions of what you must do within it, but there is no such
> definition, and nor can there be - except to say that it is intended to
> provide confidence (to whatever stakeholders require such confidence) that
> it makes sense to proceed further.
>
>  All risk-based work requires judgement, which requires thought and
> discernment. Rues can take you to points along a path, but at those points
> decisions need to be made. And an important (crucial) decision is the
> determination of what is required from a risk investigation. Much time and
> treasure is wasted in full-scale analyses that do not answer the questions
> that need answering. And perhaps the worst circumstance is that in which
> those carrying out the investigation do not know what questions they need
> to answer.
>
>  An essential requisite at the start of any risk or hazard analysis is to
> define its purpose and its scope.
> So it is necessary to define what is required from a PHA, to plan and
> conduct the PHA accordingly, so as economically and efficiently to achieve
> the defined goals, and not blindly to follow some guidance that may not be
> appropriate in the circumstances.
>
>  In some industries, there may be sufficient past experience to allow a
> checklist of top-level hazards to be drawn up. In the railway industry,
> this might perhaps be done with high confidence that it is close to being
> exhaustive of the principal causes of risk that a new model of train or
> signalling system could throw up. Then, it would be useful to start with
> such a checklist - while not believing that it is the be-all and end-all
> with regard to safety.
> But in some other fields there may not be such historic experience, and
> then the way in which a PHA is conducted would need to be planned
> differently. Of course, if, at an early stage, there is not yet a full
> specification, let alone a design, and if there is limited relevant past
> experience, you would have to be careful in determining what it is feasible
> to expect from a PHA, how much to invest in it, and how much confidence it
> is reasonable to place in its results.
>
>
>  Regarding your questions about SILs, the following might be relevant:
> 1. If a developer (designer, project manager, manufacturer, etc.) is going
> to work with the SIL concept, he really had better understand it fully.
> 2. Customers have a way of putting requirements into their specifications
> simply because they are told that a standard demands them. Many, and
> perhaps most, customers are not well informed in the matter of SILs, and
> any intelligent supplier should challenge them if they make demands such as
> those to which you refer. Sometimes it is a good idea for contractors to
> arrange training for their customers.
> 3. You ask, "Would it really be enough to assign an initial SIL only based
> on the top hazards selected?" I don't know what you mean by "enough". And
> you don't say what it is that the SIL would be assigned to. And I'm
> confused by your reference to "an initial SIL" (singular) with respect to
> "hazards" (plural). So I can't say that I understand your question.
> However, I'll comment that a SIL is not determined from knowledge of one or
> more hazard. If I were confronted with such a proposition, my initial
> hypothesis would be that both supplier and customer need enlightenment.
>
>  All the best,
> Felix.
>
>
>  On 25 Apr 2013, at 18:16, <menckem at gmail.com>
>  wrote:
>
>  Enviado desde mi BlackBerry® de Vodafone
> ------------------------------
> *From: *menckem at gmail.com
> *Date: *Thu, 25 Apr 2013 17:16:06 +0000
> *To: *nfr<felix.redmill at newcastle.ac.uk>
> *ReplyTo: *menckem at gmail.com
> *Subject: *Re: [SystemSafety] Preliminary Hazard Analysis - Approaches
>
>  In that case I guess the question is what is the scope of a PHA. As far
> as I am concerned, if during PHA you pick out hazardous events from a
> defined list, such as the SMR one, then the amount of "analysis" performed
> is greatly reduced. For example, for a Signalling System, you could select
> Collision and Derailment and already know the outcome of the risk
> evaluation, as these are widely known events. At a Preliminary Design Stage
> you should have at least a preliminary list of system functions.
> Particularly in practice, where you have to specify the functions your
> system should provide to the client at very early stages, even if they are
> modified later. If you then later perform a bottom up analysis, is that
> then part of detailed design? Additionally, even though it is not
> recommended, I have come across projects where it is required to specify an
> estimated SIL of system functions to the client at very early stages of the
> project. Would it really be enough to assign an initial SIL only based on
> the top hazards selected? Just my two cents...
> Enviado desde mi BlackBerry® de Vodafone
> ------------------------------
> *From: *nfr <felix.redmill at newcastle.ac.uk>
> *Date: *Thu, 25 Apr 2013 16:53:59 +0000
> *To: *M Mencke<menckem at gmail.com>
> *Cc: *systemsafety at techfak.uni-bielefeld.de<
> systemsafety at techfak.uni-bielefeld.de>
> *Subject: *Re: [SystemSafety] Preliminary Hazard Analysis - Approaches
>
>  PLEASE NOTE THE INSERTION, INTO MY EARLIER EMAIL, OF THE WORD "NOT".
>
>  Consider the title - "Preliminary".
> At the preliminary (very early) stage, there is not yet a design - and,
> very likely, not even a definitive specification - so there is not much on
> which to base a bottom-up analysis.
> Doing a top-down analysis at this early stage, based on definable
> hazardous events, does not preclude one or more bottom-up analyses at a
> later stage, when there's more on which to base them. And nor does it
> suggest that other hazardous events will NOT later be identified.
>
>
>  On 24 Apr 2013, at 11:51, M Mencke wrote:
>
>
>  Dear all,
>
>
>  I have seen different approaches to Preliminary Hazard Analysis in the
> railway sector.
>
>
>  I have come across a top-down method, which (roughly) involves the
> following steps:
>
>
>  Use of an “Example Railway Hazard List” based on the hazardous events
> modeled by RSSB’s Safety Risk Model. The hazardous events are classified
> according to the type of event. For example, Collision, Fire, etc.
>
>
>  The events on this list are linked to the functions of the system being
> analysed. For example, avoiding a collision between two passenger trains
> can be considered a function of the signaling system.
>
>
>  The functions identified are broken down into components, modules, etc.,
> therefore linking them to the top hazard.
>
>
>  This sounds similar to a Fault Tree Analysis; my question is, is it
> useful to apply this approach during initial design stages?
>
>
>  From my point of view, if you select the top hazards which you consider
> to be mitigated by your system from a list at the beginning of your
> analysis, you could overlook some significant hazards which may be
> generated by a (sub)system/function failure that you did not initially
> identify.
>
>
>  Personally, I prefer a bottom-up approach. It seems to me that by
> analyzing failures of system functions through the application of keywords,
> etc., effects on the subsystem and the system can be easily identified,
> whereas the other way round, you have to be very familiar with the effects
> in order to be able to work downwards.
>
>
>  Any opinions would be appreciated.
>
>
>  Kind regards,
>
>
>  Myriam.
>
>
>  _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
>
>
>   _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20130429/33998761/attachment-0001.html>