All 2 entries tagged Rdd

Understanding system

Again another interesting day for RDD. Today we studied Markov model, reliability Block diagram RBD, and Petri net

I feel even with the simple examples we used in class today, we can begin to feel the power of these tools in helping us to unravel and understand the working of a complex system

reliability block diagram , markov model and Petri net seem to be an extension of the Fault tree analysis from yesterday but focusing on the series of intermediate events that happens between an operating system and a failed system. This is represented by the RBD. Markov model represent the system as different states and add statistical probability to system being in each state as well as the transition between different states. And lastly the Petri net tells us about the sequence of event leading to a systemic failure.

Today's session fit well well with the CBE especially in Deming's first theory of profound knowledge - appreciation for the system. Until now the system idea has been a rather fuzzy concept, we know it's important and very influencial but we don't fully understand how to change or improve it. Studing this RDD module put the concept of system in a better perspective. It allows use to see why an big event is usually a working consequence of many other smaller sub events (or subsystems). Vice versa, how smaller seemingly insignificant and discrete decisions can lead to a much bigger often unintended consequence. Although we study this in an enginering context, it isn't difficult to see how it can be applied to other scenarios or disciplines. Most importantly, it at least give us some idea about how to go about modifying the system for business improvement.

: 24 Mar 2009 18:42 |  Tags: Mbe Rdd |  Comments (0) |  Close comments |  Report a problem

fault tree analysis

Today's Robust design development RDD class was more than what I expected initially, considering yesterday I was contemplating dropping the module bcause I didnt think I was gonna find the material useful

But today we learnt how to do a fault tree analysis FTA. the FTA in principle is very similar to the Failure mode crtical analysis FMEA. Both helps us to understand a complex system by breaking it down into smaller more manageable componenets. For example , to understand how a water tank leakage could happen we would need to know what specific parts of the water tank (i.e. overflow pipe) could fail. And we get from the high level system down to low level part by continously asking questions like "what could go wrong with this?", or "why would this happen?" and drilling down to the lowest level failure mode until some event or failure mode requires no further explanation.

What I like particularly about the FTA is the addition of formal logics into the analysis. On a basic level we would need to think about for a certain event to happen, what needs to happen before it as pre-requiste, then we connect different levels events with the "AND" / "OR" symbols. For example, for the water tank to overfill, two events can happen simutaneouslt or individually

1. water valve mechanism fails
2. overflow pipe fails

If any one of the two event happen at one time , water will not overflow because the other back up mechanism will prevent water overflow. However when both event happen at the same time (denote by "AND" symbol), the higher level event (water overflow) will happen.

The most powerful bit with this analysis comes when the laws of logics is applied to the tree. We can discover the minimum "cut set" which is the minimum necessary event that has to happen before the high level event occurs. For example it may be contaminant in the water which leads to blockage of overflow pipe AND jamming the water valve. This information allows us to take rather specific and rational actions (as opposed to trial and error approach) to prevent the occurence of a particular event. Moreoever, combined probabality of all low level event in minimum "cut set" allows us to determine the probablity of occurence of a higher level event.

So how is FMECA different from FTA? In my opinion it seems FTA is a more powerful technique because it allows us to pin point exactly areas of design weakness whereas FMECA will tell us all the areas of potential failures. And the prioritisation of improvement effort in FMECA is based on a subjective judgement of importance (to safety) and criticality whereas FTA is based on rigorous logical analysis. In practice though, both are applied at the same time. Very often FMECA is carried out first to provide input data (i.e. what could go wrong) to the FTA. In addition, FMECA gives an additional consideration for importance to safety which tell us where the most critical area (may not be most common failure mode).

: 23 Mar 2009 17:16 |  Tags: Mbe Rdd |  Comments (0) |  Close comments |  Report a problem