Your question implies that these items to be repaired are critical in some sense (event tree analysis is usually applied to safety critical items). If that is the case, then you are probably mischaracterising the decision to be made.

Someone made an original design decision that all of the items were necessary. You are proposing continuing operation without some of those items. The question that needs to be asked for each combination of un-repaired items is  "Is continued operation without these items acceptable?" Acceptability will be with respect to whatever local/industry benchmark determines acceptable levels of risk. 

See the linked publication for a discussion about making such decisions. The paper assumes an "As Low as Reasonably Practical ALARP" framework, but the broad approach is compatible with other risk acceptability criteria.

It is almost certain that the original design included some analysis that speaks to this question. You will be in a position to update that analysis, but you shouldn't ignore it as a source of information.

To answer your question directly, no, it is not valid to get risk priorities in this way, because you are comparing options without listing all of the options. You have the option to cease operation until an acceptable standard of repair is reached (or at the other extreme, to repair less than the budget allows for). You've framed the decision in a way that assumes you already know the right amount to spend, and there's no information that suggests that you do.

If applying event trees in this case, you can't use the item failure as initiating event, because it already needs repairs. You need to do event tree analysis for the system _with that item not available_, which may involve multiple trees with different initiating events. Like all safety analysis, the usefulness of event trees increases when you add review before using them as a decision making tool.

Conference Paper Making robust ALARP decisions for in-service systems

If one is estimating expected value of cost considering probability of occurrence and damage of the consequence, these values can be ranked. responses to top events can be selected whose expenses come within the available funds.

Your question implies that these items to be repaired are critical in some sense (event tree analysis is usually applied to safety critical items). If that is the case, then you are probably mischaracterising the decision to be made.

Someone made an original design decision that all of the items were necessary. You are proposing continuing operation without some of those items. The question that needs to be asked for each combination of un-repaired items is  "Is continued operation without these items acceptable?" Acceptability will be with respect to whatever local/industry benchmark determines acceptable levels of risk. 

See the linked publication for a discussion about making such decisions. The paper assumes an "As Low as Reasonably Practical ALARP" framework, but the broad approach is compatible with other risk acceptability criteria.

It is almost certain that the original design included some analysis that speaks to this question. You will be in a position to update that analysis, but you shouldn't ignore it as a source of information.

To answer your question directly, no, it is not valid to get risk priorities in this way, because you are comparing options without listing all of the options. You have the option to cease operation until an acceptable standard of repair is reached (or at the other extreme, to repair less than the budget allows for). You've framed the decision in a way that assumes you already know the right amount to spend, and there's no information that suggests that you do.

If applying event trees in this case, you can't use the item failure as initiating event, because it already needs repairs. You need to do event tree analysis for the system _with that item not available_, which may involve multiple trees with different initiating events. Like all safety analysis, the usefulness of event trees increases when you add review before using them as a decision making tool.

Conference Paper Making robust ALARP decisions for in-service systems

Excellent answer by Andrew. The simple answer is *no* just as mentioned above. There is more than one weakness as referred to - all options are not described *and* the value (or cost) of each option is determined outside of the event tree. To set priorities requires some metrics to be used related to some value and metrics. These metrics *and* judgement of *what metrics are relevant to use* have (as mentioned above) most likely already been dealt with - and this is *outside* of the event tree. So the event tree itself could *never* be enough in isolation. It would not be justifiable. Risk Priorities are not just based on inclusion of cost of action but also cost of no action. These points have all been referred to by Andrew above.

Making decisions based on risk tree analysis is in itself risky, since it depends on considering all possible events having potential bearing on the on decision outcomes.

I ran into this dilemma when I worked with a Russian postdoc who was on the design team for the Chernobyl reactor.  The disaster, I was told, occurred because during a test of the reactor control  the reactor's automatic control  was turned off and replaced by a human controller ( using sensor information). This human controller was not sufficiently fast, and the reactor "ran away".

In the risk tree analysis, the possibility of controlling the reactor "by hand" was not even considered ( being so blatantly unimaginable) and hence the consequences were not taken into account.

every item has it's life period with proper and periodic maintenance which is given by manufacturer. its always better to follow the same . the item may have longer life than mentioned by manufacturer but that is bonus period. so always follow manufacturer's norms.

If you want to evaluate the risk you must consider also the probability of occurrence of all failure modes and not only the consequences. Perhaps the best tool to do so is a simple FMEA (Failure Mode and Effects Analysis) where you estimate the probability of occurrence of the causes and the effects of the consequences of every failure mode. For these two factors you can use the fault tree analysis (FTA) and event tree analysis (ETA) respectively. There's a third factor that can also be considered that is the Detectability. Based on these two or three factors you reach a Risk Priority Number (RPN) that ranks the determined failure modes by its value of risk. Then you can make your decisions based on RPN.

Techniques such as Monte Carlo simulation and decision tree analysis to:

http://www.erm-strategies.com/blog/wp-content/uploads/2012/07/StrategicRiskManagementUofUWorkshop.pdf

OK - but looking too much on the probability of failure can be entrapment. Probability analysis does very often lead to false assumptions about risks and *prioritizing* management of risks. Because it the highly improbable can happen - and it might not matter if it is  almost impossible - the really important question is - can you *afford* it if it happens. Perhaps some failures are very improbable but cost of avoidance is affordable and the consequences of failure are not seen as affordable - as in death - of an organization or of human beings. So yes probability is relevant to look at - but the possibility of failure should be studied to. The weakest link is the foundation for disaster. The future does not limit itself to some probability metrics...

Interesting question and debate. You learn something new everyday, for example I never new there is a risk priority number (RPN) which can be deduced from event tree analysis. I certainly like to see a peer reviewed published reference on that one.

But as for your question Mr. Ahmadikhtiyar, when I first read it I was slightly confused. In fact I am still confused because you wrote:

   .....  each item has its 'Risk Value' or 'Risk Priority need-to-be-repaired'

If you have a priority attached to each item then you have your answer, you use that priority number to select the items with highest priorities for repair. It is obvious that if you can not repair everything then some of your operations will inevitably shut down and no amount of programming or analysis (be it top-down or bottom-up) will add cash in the bank. As the suited accountants say, the bottom line decides if you can open for business or you need to call in the liquidators.

Since I read that you are in a university department then I assume that your problem is most probably not one of cash-flow but an academic one and you wish to write a computer program that can help run some operation (most probably offshore) with less equipment than is really required, hence saving money.

Here is what I suggest you need to do. Go back to the so called drawing board and redesign the operation to run with less items. During the redesign you will have the opportunity to learn about risk acceptability criteria and how to determine those and then how to use them to decide which risks are acceptable and which ones are not. Another word of advice, do not forget to always determine your total residual risk as well.

With best wishes

Use of an event tree, like use of a decision tree, is quite an acceptable method upon which to make decisions based on cost, cost of repair, as well as safety and reliability.

The method is documented in my book: Choosing Safety: A guide to using probabilistic risk assessment and decison analysis in complex, high consequence systems, RFF Press (2008). People who have trouble with using event trees or decision trees simply do not know what they are doing.

Thanks for all the valuable answers.

Yet, there is no need to look for probability of occurence, because these items were already broken. And of course I'm aware about all of other option, but in my case, I need to get the system keep running no matter what.

So how much consequences I got to deal, if I keep running the system with some of item were not repaired. The idea is to get my system keep running, with as much as minimum probable consequences in future. The idea is to convert these consequences into numbers, so I can input into my Linear Programming.

Well, maybe I misspell it. Maybe the right word we’re “consequences”, not “risk priorities”. What I need is those converted consequences in number or level, so how can I get them? And again, is this selection method valid for your opinion? Had updated my question above.

Anyway thanks again for all the valuable answer and those articles linked.

Radiynal,

Now that you've rewritten the question, and with your additional explanation, it appears that by "consequences" you are confined to effects on the system itself. Event trees are useless here, since to prepare the event tree you already need to know what repair strategy you are using, and which failed components will lead to the system not working.

My restatement of the problem would be as follows:

You have a system which can survive with some combinations of failures, but not with others. You would like a repair regime that maximises the survival time of the system.

Once you start to work this out you'll realise quickly that the problem is ill-formed, because it needs to be expressed probabilistically, not as "keep running no matter what". What do you want to optimise? The expected value of the running time? The running time itself within a specified confidence interval? The likelihood of surviving for a particular length of time? 

The appropriate way of modelling a situation like this, with random state transitions (the failing components) and deliberate state transitions (the repair strategy) is using Markov models. Which item (if any) to repair at any given time is determined by all of the current failed components (ie the previous state transitions). The exact form of the model will change based on the outcome statistic you are optimising, but basically you vary the parts of the model that you have control over, iterate over repair strategies, and pick the strategy that gives the best outcome.

Thank you Andrew. Case closed.