Block diagrams fail in a characteristic way: the arithmetic is right and the model is answering a different question from the one that was asked. Almost every entry below is a modelling error rather than a numerical one, which is why they survive review so easily; the numbers all add up.
| Pitfall | What it looks like | The guard |
|---|---|---|
| The schematic redrawn | Blocks positioned like the plant, parallel pipes drawn as parallel logic | Test every branch by function: if this block alone fails, does the system still meet the criterion? |
| One diagram, several criteria | Dispatch, mission success and safe shutdown argued off the same drawing | One criterion per diagram, written in the title block |
| The unstated mission time | Architectures compared on reliability, with no t anywhere on the page | R without t is not a result; put the mission in the figure caption |
| Redundancy assumed independent | Two identical units, same batch, same room, same maintainer, multiplied as if unrelated | A β-factor on every redundant group, and a sweep at 0, 0.05 and 0.1 reported with the answer |
| The shared support that is not a block | Power, cooling, control air, the operator, all outside the boundary and all assumed perfect | The boundary list is a list of claims; review it as one |
| A dormant block given a running rate | A standby unit or a protection channel carrying λt instead of a probability of failure on demand | Dormant items carry PFD from their dangerous-undetected rate and their proof interval |
| The switch that was not modelled | A standby pair credited with the perfect-switch formula because the switch is "simple" | The start or changeover probability appears explicitly; below 0.958 in the worked example it costs more than it buys |
| Repair credited to a non-repairable model | An RBD result quoted as availability, or as uptime | The structure function has no way back from a failed block; availability needs a state model |
| Mixed units and clocks | FIT on one block, per 10⁶ operating hours on another, calendar hours on a third | One declaration of unit, clock and mission time for the whole diagram, matching the prediction's |
| The bridge collapsed anyway | A cross-connected structure approximated as two parallel trains because the tool only does series and parallel | Condition on the cross element or enumerate; the approximation lost 0.6 points in the worked example |
| The block that appears twice | The same physical item drawn on two paths and treated as two independent blocks | One item, one block; a shared item makes the two paths dependent, which is the opposite of what the drawing claims |
| MTBF taken from a redundant model | The equivalent rate at one mission time quoted as the system's MTBF | A redundant system has no constant rate; publish R(t) with its t |
| Phases folded into one drawing | A mission with distinct phases modelled at the worst-case configuration throughout | One diagram per phase, multiplied, with survival carried across |
| The optimistic starting state | Every block serviceable at t = 0, on a fleet that dispatches with deferred defects | Model the dispatch state the operator actually allows, which is a second diagram |
Two of these deserve a closing sentence each. Assumed independence is the deepest, because it is the only error that gets worse as the design gets better: every path added multiplies the independent term down toward the shared term, until the answer is entirely determined by the number nobody measured. A model whose result is dominated by β is not a precise model with an uncertain input; it is a statement that the separation, not the redundancy, is the design.
And the criterion drift is the slowest. A diagram drawn for one success criterion gets reused for the next question, then quoted in a report, then cited in a case, and by then nobody can recover which of the plant's several missions it described. The guard is boring and works: the criterion sentence lives in the diagram, not in the email that requested it.