Reliability Block Diagram

A prediction answers a question about parts: how often does this hardware fail. It cannot answer the question a programme is actually asked, which is about a mission: will the system still be doing its job in 720 hours. Between the two sits an assumption that the prediction makes silently and almost always wrongly, that every failure counts. A reliability block diagram is where that assumption gets replaced by an explicit one.

An RBD is a success-oriented logic model. Each block is an item that either works or does not; the blocks are connected so that an unbroken path from the input node to the output node means the system is doing its job. Nothing in the drawing is geometry. The blocks are not where the parts are, the lines are not cables or pipes, and the order left to right carries no time. The only thing the diagram encodes is which combinations of working items constitute success, and the only thing it computes is the probability that one of those combinations holds at the end of a stated mission.

That is a narrow job, and the narrowness is the point. Everything the model needs beyond its own logic (the rate on each block, the mission time, the target it is judged against) arrives from somewhere else, which is why the RBD is the most connected artefact in a reliability programme and the least self-sufficient.

What it is and why it exists

The technique is old enough to have been standardised twice. MIL-STD-756B, Reliability Modeling and Prediction, made the reliability model a formal deliverable in 1981 and drew the distinction the discipline still runs on: a basic-reliability model in which every item sits in series, used for sizing spares and maintenance, and a mission-reliability model in which redundancy appears, used for the success case. IEC 61078 carries the international definition, sets out the boolean evaluation of the structure, and is explicit about what the technique assumes: blocks that fail independently, a stated mission, and a success criterion fixed before anything is drawn.

The mathematics behind it is older still and belongs to the theory of coherent structures. Every RBD is one, and every coherent structure has two equivalent descriptions: its minimal path sets, the smallest groups of items whose survival is sufficient, and its minimal cut sets, the smallest groups whose failure is sufficient to stop it. The cut-set view is the same object a fault tree computes from the other side, which is why the two techniques answer the same question and read so differently: an RBD draws what has to work, a fault tree draws what has to fail.

Why the activity exists at all: because redundancy is invisible to arithmetic that only adds. Add up the eleven blocks of the worked example and the answer is 521 failures per 10⁶ hours, an MTBF of 1,919 hours and a 720-hour mission that succeeds 69 times in a hundred. Draw the same eleven blocks as the plant is actually built and the mission succeeds 98 times in a hundred. Neither number is wrong. They answer different questions, and only the diagram distinguishes them.

Where it sits in the programme

The diagram arrives once the architecture is stable enough to have a success criterion and stays for the life of the programme. At concept stage it is drawn from the candidate architecture and fed with generic rates, and its job is comparative: does the second dryer earn its place, does the vote need three transmitters or two. As the prediction matures the blocks inherit real rates, and the model turns from an architecture argument into evidence. In service it is re-run whenever field data moves a rate.

Its neighbours are worth naming precisely, because the RBD is often asked to do their work. Allocation hands it a target and reads back whether the architecture can meet it, the mission budget being the line that redundancy is allowed to reduce. A fault tree computes the same cut sets from the failure side and is the better tool once the logic stops being a two-terminal network. Availability needs what an RBD structurally cannot express, a repair that puts a failed block back, and a repairable redundant group belongs in a repair model or a simulation instead. And FMECA supplies the thing the diagram most often gets wrong: which failure mode of a block actually defeats the path it sits on.

How RAMSynapse approaches this

RAMSynapse's RBD module is an interactive canvas over the same project spine the other modules use. Blocks are drawn and wired from a start node to an end node, parallel paths branch and re-join at junctions, and a junction carries a voting setting so a 2-of-3 arrangement is a property of the join rather than a hand-expanded set of branches. A block can also stand for another diagram, so a large system is modelled as a hierarchy rather than as one unreadable canvas.

Blocks take their failure rates live: from a prediction element or a single prediction component, from an FHA budget where the target rather than the estimate is what matters, or typed in directly. Because the link is live rather than a copied number, re-running the prediction moves every block that references it and the diagram result follows. The engine evaluates continuously, so the canvas shows R(t) at the mission time and the effective failure rate as the structure is edited, and the comparison that matters most is one subtraction away: the diagram's result against the pure-series prediction of the same parts, which is the redundancy gain in a single number.