Tag Archives: FTA

Architecture RAMS Reliability Requirements Engineering Safety Video

[005] Risk Assessment Example: An Emergency Power System

July 17, 2012 – 10:22 pm

Potential hazard in case of Aux power failure in a nuclear power station, Fukushima I by Digital Globe BIn the last posts we emphasized the basic system engineering concept of a clear distinction between

  • system components – or items in the wider sense – and
  • system functions.

Today’s video post shows a way to support this concept by modular RAMS blocks in a basic risk assessment example: the analysis of an emergency power system. An auxiliary power bus has to provide the electricity used for internal operations in a nuclear power station, like cooling pumps, control system or manipulating the nuclear fuel elements. So power failure on this Aux bus is surely a safety-critical event or hazard.

 

Using a modular, graphical system model allows to easily evaluate the effects of a local component failure – which might remind you to the common FMEA procedure – and automatically determine all possible root causes of a system function failure. But the  risk assessment procedure is supported also quantitatively, by assigning

  • by assigning individual MTBF values and failure rates on component level and
  • defining an upper limit of the “to-be”-failure rate on function level.

The fault tree for each undesired event of a failed function – the hazard in this risk assessment example – is derived automatically. So we can easily check if the failure rate requirements are met by anticipated architectural design of the power supply system and the quality of the component.

Although this system is comparatively simple and has two fully separated and independent branches, the example shows the benefit of the option to quickly change parameters of components or functions and to – in a wider scope – support also the requirements engineering process. In a later contribution we will analyze also seemingly independent supply branches, but which have hidden dependencies in form of common components or even common cause of failure. (Please note that the selected failure rate values just serve as placeholders here.)



In post [006] we will introduce the idea of availability modeling and the appropriate layer in the SmartRAMS library that allows to quickly determine the availability of a system.

 

Tags , , , , , , , , | Permalink | Comments (2)
Architecture Product Development RAMS Reliability Safety Video

[004] From Root Cause Investigation to Fault Tree Analysis

July 10, 2012 – 8:51 am

Example Fault Tree Analysis FTA, generated automatically from a component modelIn post [003] we referred to “each directly or indirectly required componen“, when talking about determination of the system function’s failure rate. But which components are required? – Well, basically all these individual items or combinations of items whose local failure will affect the considered function in a way that it does not work any longer.

In other words, we have to find out those components that are crucial for the functionality. A common way of doing that is a so-called root-cause investigation, assuming the individual function has failed.

One aspect of this post’s video is the demonstration, how these root-causes can easily be derived from the functional system model, using a kind of automatic backward reasoning. For each detected root-cause – be it a single fault, double fault or even higher order fault – the graphic of the connected SmartRAMS-blocks displays the affected system parts for each particular scenario.

Root cause analysis is often performed during system operation – i.e. late in the product life cycle – during diagnosis or troubleshooting. However, its reasoning and findings are very related to the top-down investigation in the context of a Fault Tree Analysis FTA, usually performed very early in product development.

Risk analysis by FTA has the goal to check if the safety and reliability requirements are met by the anticipated architecture. The system model composed from the simple Boolean library items supports also this purpose. We can automatically derive the Fault Trees and – as a side effect – compute the function failure rates from the component’s lambda-values. This is the other aspect shown in the video:


In post [005] we are going to demonstrate these features using a emergency power system as a simple risk assessment example.

 

Tags , , , , , , , , , , , , | Permalink | Comment (1)
Reliability Standards

[003] Reliability Modeling from Fault to Failure

July 6, 2012 – 10:19 pm

Components And Functions In System Design, Determining the reliability of systemsOne of the core features to investigate in the context of RAMS analyses is the functional reliability of the system. Quantitatively represented by the failure rate lambda, it specifies the number of failures within a certain time period, e.g. “failures per million hours (fpmh)”.

Again as in post [001] we clearly have to distinguish between failure rates of system functions and of system components, as shown in the figure.

At the start of the design process what is given are probably upper limits of the failure rates of the functions – not the components (!) – of the designated system. These individual maximal values for lambda might be defined by the customer, by specification, by design rules, by standards (i.e. IEC 61508, ISO 26262, MIL882D etc) or otherwise. When developping a flexible block-library we need to represent this given parameter lambda_max by a value slot on function level.

On the other hand what has to be determined is each functions actual failure rate, say lambda_act. It depends mainly on 2 factors:

  1. the failure rate lambda of each directly or indirectly required component, i.e. its quality
  2. the system topology, how the components are connected and interact, i.e. the design architecture.

Concerning components quality, we simply provide a value slot on component level to represent the individual lambda. In the easiest case it will be just a fixed parameter for lambda. More ambitious approaches, like dependencies of the component’s failure rate on other environmental usage parameters, can be considered. In industrial practice also the “mean time between failures (mtbf)” is frequently used, which – under common conditions – is the inverse of the failure rate lambda.

Concerning system topology,. we need an arithmetic to consider the topology when determining the actual function failure rates. This is basically not too complicated, if we look at the system on a smaller, local or component scale instead trying to derive the calculation on global level. Assuming independence of the suppliers of a component, it follows simple rules, very similar to those applied in classical Fault Tree Analysis FTA:

  1. Add up the probabilities of the individual failures, if each of them separately might “kill” the output. Example: The probability that an individual component fails to deliver its output service, is the sum of its own failure rate and the probability that its immediate supply fails.
  2. Multiply the probabilities of the individual failures, if only the combination will “kill” the output. Example: The probability that the redundant supply of a component fails, is the product of the failure rates of the individual supplies.

Applying these rules recursively from the function viewpoint dependent on the individual redundancy situation at each component and its inputs, up to the first elements in the supplier-consumer-path, is a major step to modularize the failure rate computation of each function.

How closely related Fault Tree Analysis FTA and Root Cause Analysis are will be shown in post [004].

Tags , , , , , , , , , | Permalink | Comments (3)