[SystemSafety] RV: Preliminary Hazard Analysis - Approaches

nfr felix.redmill at newcastle.ac.uk
Sat Apr 27 16:56:18 CEST 2013


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<mailto:menckem at gmail.com>>
 wrote:

Enviado desde mi BlackBerry® de Vodafone
________________________________
From: menckem at gmail.com<mailto:menckem at gmail.com>
Date: Thu, 25 Apr 2013 17:16:06 +0000
To: nfr<felix.redmill at newcastle.ac.uk<mailto:felix.redmill at newcastle.ac.uk>>
ReplyTo: menckem at gmail.com<mailto: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<mailto:felix.redmill at newcastle.ac.uk>>
Date: Thu, 25 Apr 2013 16:53:59 +0000
To: M Mencke<menckem at gmail.com<mailto:menckem at gmail.com>>
Cc: systemsafety at techfak.uni-bielefeld.de<mailto:systemsafety at techfak.uni-bielefeld.de><systemsafety at techfak.uni-bielefeld.de<mailto: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<mailto:systemsafety at TechFak.Uni-Bielefeld.DE>

_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE<mailto:systemsafety at TechFak.Uni-Bielefeld.DE>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20130427/3f84b6d1/attachment.html>


More information about the systemsafety mailing list