Re: [SystemSafety] Preliminary Hazard Analysis - Approaches

From: SPRIGGS, John J < >
Date: Wed, 24 Apr 2013 11:15:45 +0000

Hi Myriam,
I would suggest doing both. You start with your unwanted outcomes, or hazards, and assess whether they can arise from your proposed system. For those that can so arise, you can specify mitigations. Later on, when you have more detail, you can analyse the effects of functional failures and assess whether they ripple out to be unwanted outcomes. If all has gone well, you will then have validated your original hazard analysis. In practice, of course, they will not be a one to one correspondence of your top-down and bottom-up analysis results. You can then check if you need additional mitigations, so addressing your concern about overlooked hazards.

John

From: systemsafety-bounces_at_xxxxxx Sent: 24 April 2013 11:51
To: systemsafety_at_xxxxxx Subject: [SystemSafety] Preliminary Hazard Analysis - Approaches

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.

---

If you are not the intended recipient, please notify our Help Desk at Email isproduction_at_xxxxxx immediately. You should not copy or use this email or attachment(s) for any purpose nor disclose their contents to any other person.

NATS computer systems may be monitored and communications carried on them recorded, to secure the effective operation of the system.

Please note that neither NATS nor the sender accepts any responsibility for viruses or any losses caused as a result of viruses and it is your responsibility to scan or otherwise check this email and any attachments.

NATS means NATS (En Route) plc (company number: 4129273), NATS (Services) Ltd (company number 4129270), NATSNAV Ltd (company number: 4164590) or NATS Ltd (company number 3155567) or NATS Holdings Ltd (company number 4138218). All companies are registered in England and their registered office is at 4000 Parkway, Whiteley, Fareham, Hampshire, PO15 7FL.

---

---

The System Safety Mailing List
systemsafety_at_xxxxxx Received on Wed Apr 24 2013 - 13:16:18 CEST