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

From: Peter Bernard Ladkin < >
Date: Sun, 28 Apr 2013 08:50:23 +0200

It might be worth while to consider the engineering context.

As far as I know, Myriam is working with and concerned with railway systems. Rail E/E/PE systems are designed, built and certified in a (at least in Germany) highly regulated environment. There are also in large part specific types of components required. There is a lot of careful but indirect "our balises are better than their balises" argumentation.

Let me simplify rather too much. When you put together a rail system, you are mostly working with existing, qualified components and configuring them in such a way as to meet the requirements, which often consist mostly of configuration and some target numbers. If you have a specific function you wish to provide (a requirement) then you mostly get to assemble and configure things you already have (certified, with officially approved reliability and safety levels for known "dangerous" failures) and demonstrate that that configuration will fulfil the function to the required reliability and safety levels.

Let me be even cruder. Suppose your kid wants a model-railway configuration that looks like this-and-this with this-connected-to-that and the train going through these-and-these. You have the track pieces with given geometry, and you know there is a certain amount of "give" in the geometry, that the pieces can take a slight mismatch in join angle without losing electrical or mechanical continuity (the reliability and safety properties). There is no point in doing much preliminary analysis before you have a design proposal (something you think might work). Then you can see if the design proposal fulfils the requirements spec (you discuss it with your kid; he gets to have the final say on compromises, that is, requirements modifications) and then you mostly perform a bottom-up hazard/reliability analysis (with some experimentation) as you are assembling the design.

Contrast this with US military systems over the last fifty years. In those systems, there is a lot of ab initio design (indeed, the US military along with NASA can be said to have driven the production of complex E/E/PE-based systems with brand new capabilities. Silicon Valley was established and supported largely on military funding right into the 1980's). Requirements are often brand new (that is, you are not providing similar functions in a new configuration), and there are few "certified components" - whether the system is accepted is up to the client alone, and the acceptance tests are part of the contract negotiation. In this context, analysing the requirements for safety and reliability properties, if you can, is important so that you have some guidance as to where you have to pay the most attention in design. (Think of a Mars lander; the top-level requirement is quite abstract - put the thing on the ground, don't break the bits that provide function after landing, and   make sure the mobile robot can exit the lander on its wheels. The designs that have achieved that have been very different and sometimes startlingly innovative.)

Now, the common protocols and procedures for system safety came out of this second tradition, including the importance and priority of a top-down PHA. I suspect Myriam is quite right in suggested that parallel bottom-up and top-down analyses bring benefit when one is performing a PHA of safety-related rail systems.

PBL Prof. Peter Bernard Ladkin, University of Bielefeld and Causalis Limited

The System Safety Mailing List
systemsafety_at_xxxxxx Received on Sun Apr 28 2013 - 08:50:28 CEST

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