Quantitative Risk Analysis

In some situations the qualitative risk analysis or the ALARP principle is insufficient: The safety people are torn and disagrees internally. Consequently, it is time to use the heavier "quantitative risk analysis"-tool.
The fault tree is integrated into Excel and models a scenario, where a passenger is trapped between closing doors. (All numbers and technical barriers are hypothetical).

Interpretation

The quantitative risk analysis is the right way to estimate the frequency of a hazard.
It removes personal obsessions from a safety problem and ensures that the discussions are conducted on an objective basis.
The fault tree above concerns a commuter fleet operating 365 days pr. year with 80 trains with 100 departures pr train pr. day. This result in c = 2.9E-06 departures every year pr. fleet.
In order to have an accident, there have to be squeezed a passenger arm, leg or items like e.g. a baby carriage, umbrella etc. between the closing doors. This is judged to happen continuously when passengers passes the doors, meaning d = 1.
There are three barriers that prevent the hazard:
A human based departure procedure, where the train driver looks out of the window and checks the doors before departure (e). It is estimated that the driver miss a check every 4'Th day due to distraction or lacking of concentration, meaning e = 1/(4*b).
There are also two technical functions:
- A traction blocking that prevents the train from driving if the door controllers indicate the doors are open (f). This function is part of the train computer and is expected to be reliable with a failure rate of 1 failure pr. 1,000,000 departures.
- A trap detection system in the door controller that prevents the passengers from being squeezed in a closing door (g). This function is sensitive to door mechanics; the FRACAS system indicates a failure rate of 1 failure pr. 10,000 departures.
As it can be seen we will end up having an accident where the train departs with a passenger trapped between doors every year. The Safety department has recorded an incident the recent year, indicating the fault tree is trustable.
Can we accept this? What are our quantitative acceptance criterion? It should be written and stated in the safety management system of the Operator.
The safety management now decides that the above result is unacceptable. We can only allow the hazard to occur every 10,000'End year.
A deeper analysis shows that the failures on the detection function only occurs for thin objects like a small child's arm.
It is judged that the detection system in the daily life is activated by large objects like a person; thin objects only occurs 3 times pr. day, meaning d = 3/b.
The sensors are adjusted and a maintenance program introduced; the following test result shows an improved reliability in the area of 1 failure pr. 100,000 departures (g).
An additional departure procedure is introduced stating the train conductor has to supervise the train doors before departure in front of a dedicated door. A new technical feature makes it possible to firstly close the other doors and finally, the train conductor enters the last door before departure. The improved procedure is expected to be more reliable with an estimated human failure rate of 1 failure pr. 10,000 departures (e).
These mitigating actions result in a dramatically lowering of the frequency of the hazard to app. 10,000 years between accidents, hereby fulfilling the acceptance criterion.
  

As a side effect, the analysis proves the importance of the departure procedure and the detection function.

The old rule, KISS, (Keep It Simple Stupid) is recommended for quantitative analysis. The fault trees easily swell up into large trees with several undocumented values based on engineering judgement. This only starts new discussions instead.

Next chapter >> 4.5 Common Cause Failures (CCF)

Focus on the Source

The "Guide to the application of EN 50126-1 for safety", TR 50126-2: Feb. 2007, concerns risk modelling and quantitative risk models.

Chapter 5.2, "Generic Risk Model" says:

Modelling predominantly represents a simplification and generalisation of reality but, enhances our understanding of causal relationships, highlights important factors and provides a useful tool for anticipation and potentially prediction of future.
A risk model may be created for a specific task (e.g., occurrence of a hazard, a combination of hazards, an operation, a sub-system, etc.) for a particular application or for a whole railway system by applying the risk assessment process to the relevant task or to the railway system.
[.....]
Developing a risk model for a whole railway system is a demanding task [....] the report does not recommend a single generic risk model for a whole railway system. [....]
Annex D lists essential steps for building such a model [....]

Read more...

Common Cause Failures (CCF)

Special precautions have to be taken against common cause failures.

It is a single failure that causes a safety function to collaps e.g. a mechanical or logic error in a product as shown below in Figure A.7 from EN 50129.

It can be handled by using redundant systems, inherited charactheristics of components, safety analysis, independent reviews, FRACAS system, etc.



Interpretation

Common causes failures can e.g. be a sleeping tricky error in Function A that cause a dramatic failure in Function B.
If we have installed hundreds of systems we have a possibly accident.

Train fleet example:

Let’s say the developer of a diesel traction system in a train uses the exhaust gas to power a turbo. The turbo powers an air inlet compressor. The compressed air enters the combustion chamber.
A hose clamp on the air tubes are under dimensioned, nevertheless the design passes design reviews and burn-in tests.
The hose clamp is slowly loosened during operation and this causes a decrease of air in the combustion chamber that again causes an overheated exhaust gas that again causes the turbo to overheat and crack and finally cause an oil leakage in the turbo driven power transmission to the compressor located near the exhaust pipe.
The operational staff reports of occasional small fires in the turbo driven power transmission, the maintenance staff discovers the cracked turbo, and it is concluded that cracked turbo's must be changed.
In this case we have an undisclosed common cause failure in the train fleet (the loose hose clamp).
One day, under the right circumstances, the oil leakage will cause a larger fire. If the daily train route furthermore passes a tunnel we might end up with a "fire in train in tunnel" scenario.

Interlocking logic example:

See "Quick guide to safety management based on EN50126"

Next chapter >> 4.6 Safety Integrity Levels (SIL)

Focus on the Source

See "Quick guide to safety management based on EN50126"



Read more...

Safety Integrity Levels (SIL)

The SIL concept is a way of categorizing safety functions into five discrete levels: SIL0 - SIL4. The SIL determination follows a complex, although systematic, process as shown below (Figure A.5 from EN 50129).

However, for many purposes the quantitative SIL value can be substituted with a more straightforward qualitative approach when categorizing safety functions. For example:
Safety critical functions kind of compare to SIL3/4 (as e.g. the emergency brake in a train or the logic in an interlocking system.)
Safety related functions kind of compare to SIL 1/2 (as e.g. emergency announcement speakers in a train or warning lamps for track crossing)


Interpretation

At high SIL, the heaviest measures to avoid random, systematic errors and common cause failures have to be used at all phases in the V-model.

The SIL determination often ends up in complicated mathematical discussions among risk analytics (e.g. is the human failure rate 1e-3 or 2e-4 [pr. action]).

These types of discussions narrow the number of persons, who participates in the safety discussions; which again might decreases the safety awareness among the other staff groups: Implementation engineers, maintenance staff, train drivers and sub suppliers as an unfortunate side effect.

In an operating organization, with many small projects and a few major projects, it can therefore be advantageously to simplify the categorization of the safety functions into the above described categories e.g. "Safety related" and "Safety critical".

Such a concept is easier to communicate to the staff groups and integrate into the used procedures and documents.

Note 1; the used categorization method should be described in the Safety plan and agreed upon by the Safety Authority.

Note 2; for product developers and suppliers it will most likely be necessary to make quantitative risk calculations and common cause analysis, see examples in e.g. TR 50451:2007.

Next chapter >> 5.1 What is the task of the Assessor?

Focus on the Source

The SIL levels are explained in EN 50129 in the normative Annex A, "Safety Integrity Level".
Related concepts like Systematic and random failures, Tolerable Hazard rates (THR), Common cause Failures (CCF), process independence and safety targets are also explained.

Annex B of EN 50129 explains about Detailed technical requirements to e.g. redundancy and CCF.

Annex C of EN 50129 explains about Identification of hardware component failure modes.

TR 50451:2007, "Railway applications. Systematic allocation of safety integrity requirements" explains how to calculate the needed SIL of a new product.



Read more...

The System Definition

The system definition is basically a drawing defining the system at block diagram level. It shows the internal sub systems and important interfaces to neighbouring systems.
At a first glance it seems like a simple document to produce, but once released and posted to interested parties, it can easily cause important discussions.


Interpretation

Let’s take a look at the rough system definition above. The blue line marks the system.

Furthermore, the blue line immediately shows the interfaces. The interfaces are marked with green circles. An interface occurs whenever the system interacts with other systems e.g. the wheels interact with the tracks and the train doors interact with the passengers.

Although the system definition is clear, there are still many issues it would be advantageous and time-saving to discuss as early as possible in the trains life cycle:

- Is the maintenance manual a part of the system?
- Should the system involve coupled trains?
- Should the mission definition be a part of the system?
- Is intentional misuse part of the system?

The system definition can be organized into Generic Product, Generic Application and Specific Application as described in the Safety Approval Process.

The system definition defines the hazards in the hazard log, because hazards occur at the system borders.

Finally, it might end up with a system definition at block diagram level as shown below. The example below shows the sub systems that were considered inside and outside of the electronic brake system of a Copenhagen commuter train type during a safety approval process.
The rectangle boxes are sub systems and the hexagons boxes are measuring sensors.



Please note the system definition is the basis for the hazard log, the safety requirements, the safety approval and other safety activities. Any ambiguity in the system definition will surely cause problems and delays later on in the Safety approval process.

Next chapter >> 3.3 The Safety Plan

Focus on the sources (EN 50129:2003)

See "Quick Guide to Safety Management"



Read more...

The key documents

A number of documents can be considered as "key" documents in a Safety Management system based on EN 50126.

The System definition: Defines the system on block diagram level.

The Safety Plan: Describes "Who does what and when".

The Hazard log: Contains all known hazards and their history.

The Risk analysis: Contains the risk analysis performed for each hazard.

The Safety Requirements: The safety requirements to the system

The Safety Case: The document that proves the system is safe.

Interpretation

An Operator, Infrastructure owner or Supplier organization might have thousands of small projects every year and maybe a few large projects.

It is some times asked: "Do who need all these documents for each single small project?".

The answer is "Yes" - however, it is allowed to simplify the documents to one A4 page.

Of course you need the documents! Imagine it was a small company saying: "We are so small that we do not need a yearly accounting report for the taxes authority".

If you do not have the key documents, everybody around you gets confused: The Safety authority, the safety department and the Assessor.

Next chapter >> 3.2 The System Definition

Focus on the source (EN 50126:1999)

In Figure 9 in EN50126, it is recommended to update the safety documents during the life cycle as shown below:



Information about the Safety organization and the FRACAS system can be included in the Safety Plan.

Infomation about relevant standards can be included in the Hazard log.

Information about the Risk acceptance criterion can be included in the Risk analysis.



Read more...

How to measure "Risk"

"Risk" is the measurable unit in a Safety Management System. - The unit we have to measure and control!

Although it is not as easy to measure! - We do not have any handy measuring instruments to measure "risk" - like e.g. a Geiger counter, which can measure radioactivity.

We only have the Statistics to measure back in time and the Risk analysis to measure ahead, see the Figure below.



Interpretation

The figure above shows the close relationship between statistics and risk analysis.

This relationship is often forgotten: In many projects, a "Risk department" from e.g. the Supplier creates a large hazard log for a complex interlocking system, filled up with complex fault trees with many hard-to-understand branches.

Afterwards, an independent Assessor is asked to assess the Risk analysis, and the Assessor creates a huge hard-to-understand assessment report.

However, it should not be that complicated; when the close relationship between statistic and the risk analysis is kept in mind, the statistics can be a helpful tool to get a feeling of the quality of a hazard log.

Let's say we have the statistics from

- "Passengers traps in doors for a train fleet",
- "Trains parsing a red signal on a certain line" or
- "Accidents in level crossings pr. year"
etc.

Once we have such statistical numbers, it is often possible to find the corresponding branch in the hazard log.

If the numbers are close, it indicates that the hazard log somehow reflects and models the "real life". - Or maybe it needs adjustment.

It is also worth an effort to screen the hazards and pick out the "Top 5" hazards, which has the highest risk level.
In order to reduce the complexity, all branches in the hazards fault trees, which gives a low risk contribution, can be removed or compiled together.
Finally, the fault trees are simplified, easy to understand, can be controlled through statistics and evidently models the "real life".

Next chapter >> 1.4 The Safety Management Circle

Focus on the source (/EN 50126:1999/)

See "Quick Guide to Safety Management"



Read more...

Using the ALARP principle

The ALARP-principle stands for "As Low As Reasonable Practible".

It means, that if it is practible, with reasonable effort, to reduce the risk from the "Tolerable" (Yellow) hazards in the risk table below, it should be done.
In all cases an "observation" should be foreseen in the sense that indicators of this special kind of risk should be more frequently and detailed supervised than others.

This goes particularly for the yellow hazards in the right-bottom corner.

Interpretation

In risk analysis you might end up with a risk matrix looking like above.

In a major project some years ago, it was necessary to decide, at a meeting, what to do with the "yellow" hazards in the ALARP region. The Project Manager looked at the table and said: "It is easy, - we have no money, and the customer has no time".

The Project Manager was interpreting "Reasonable Practible" in the ALARP-definition and came to the logic conclusion, that we didn't have to do anything.

The definition needs to be coupled with the general dislike of large accidents in society, also named: ("Differential Risk Aversion" (DRA)).
This principle concerns the "yellow" hazards in the bottom-right corner in the risk table above. This field contains all the controversial and unpleasant hazards; they are almost improbable, but the outcome is catastrophic.

For these hazards, the ALARP-principle should be implemented.


Driving through the tunnel

For example, let's say that hazard 1, in the risk table above, concerns the catastrophic scenario where a train is caught with fire while driving in a tunnel.
The risk analysis has revealed, that it is possible to reduce the frequency from 10 occasions pr. 1 Million year to 2 occasions pr. Million year by implementing an "Escape-button" on the Train driver panel.
The Escape-button allows the driver to speed up, even if the traction power has failures, in order to the help the driver escaping the tunnel.
The button is expected to cost 100,000 Euro's and taking 12 weeks to install.

The Project Manager, from above, might say: "It is not practible because of the budget and the time schedule. Furthermore, the reduction from 10 to 2 occasions pr. 1 Million years is so small that it's not worth the effort."

Acoording to the ALARP-principle, the button shall be implemented because the budget and time schedule is inside reasonable practible and because of the dislike of large accidents.

In order help the Project Manager, it would be reasonable to give the train a running permit for service for a limited time period of 12 weeks, until the button has been implemented; because the risk reduction, after all, constitutes a minor risk reducing contribution.

In any case the risk management should also ensure that indicators of hazards in the yellow area are supervised more frequently and detailed than others in the FRACAS system.
For the tunnel hazard, it would therefore be necessary to supervise activated smoke and fire alarms on the train fleet.

Next chapter >> 4.4 Quantitative Risk analysis

Focus on the Source (/EN 50126/)

See the quick guide.

Read more...