Re: [SystemSafety] RV: Preliminary Hazard Analysis - Approaches

From: M Mencke < >
Date: Mon, 29 Apr 2013 11:54:51 +0200


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.

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_xxxxxx

> 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_xxxxxx > wrote:
>
> Enviado desde mi BlackBerry® de Vodafone
> ------------------------------
> *From: *menckem_at_xxxxxx > *Date: *Thu, 25 Apr 2013 17:16:06 +0000
> *To: *nfr<felix.redmill_at_xxxxxx > *ReplyTo: *menckem_at_xxxxxx > *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_xxxxxx > *Date: *Thu, 25 Apr 2013 16:53:59 +0000
> *To: *M Mencke<menckem_at_xxxxxx > *Cc: *systemsafety_at_xxxxxx > systemsafety_at_xxxxxx > *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_xxxxxx >
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety_at_xxxxxx >
>
>



The System Safety Mailing List
systemsafety_at_xxxxxx Received on Mon Apr 29 2013 - 11:55:01 CEST

This archive was generated by hypermail 2.3.0 : Tue Jun 04 2019 - 21:17:05 CEST