[SystemSafety] RV: Preliminary Hazard Analysis - Approaches

menckem at gmail.com menckem at gmail.com
Thu Apr 25 19:16:23 CEST 2013


Enviado desde mi BlackBerry® de Vodafone

-----Original Message-----
From: menckem at gmail.com
Date: Thu, 25 Apr 2013 17:16:06 
To: nfr<felix.redmill at newcastle.ac.uk>
Reply-To: 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

-----Original Message-----
From: nfr <felix.redmill at newcastle.ac.uk>
Date: Thu, 25 Apr 2013 16:53:59 
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<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/20130425/7d2ca951/attachment.html>


More information about the systemsafety mailing list