The Mantua Group

Simple Black and White Asset Management, Reliability Expertise, and Maintenance Execution Perfection.

Reliability Engineering

Vintage Experience

Decades of Engineering Memory (Vintage Experience) in Cross-Functional Teams: Why It Matters, How Modern Tenure Patterns Erode It, and the Disciplines That Preserve and Apply It

The accumulated engineering experience of long-tenured professionals, the veteran with 30 years (vintage experience) on the same equipment class, the consulting engineer who has worked across four industries and five regulatory regimes, is among the most consequential assets a cross-functional engineering team can have. It is also among the most fragile. Modern average employee tenure is shorter than the time required to develop deep institutional knowledge. The cultural assumption that experience is replaceable by documentation has hollowed out succession planning in many organisations. The natural friction between the older engineer’s deference to lessons already learned and the younger engineer’s enthusiasm for first-principles redesign reduces the value extracted from the experience that does exist. This white paper sets out what vintage experience contributes to engineering decision-making, why modern organisations under-utilise it, and the disciplines that recover and apply it.

Working on the Right Things

Why Reliability Engineers Should Move to the Bottleneck, Not the Job Description

The reliability engineer’s most consequential decision in any given week is rarely a technical one. It is the decision about which problem, of the many available problems, deserves the next hour of attention. Most reliability engineers are not explicitly asked this question. They are given a job description, a department, and a set of tools, and they work on whatever the inbox delivers. The result is that competent reliability work is routinely directed at problems whose solution would deliver only marginal benefit, while much larger sources of organisational loss go unaddressed because they are someone else’s department. This paper sets out 10 principles for working on the right things: knowing what reliability work the certifications actually cover, recognising that the work is often led by people whose titles say something else, moving to the bottleneck rather than the job description, partnering with finance to defend the value of the work, distinguishing systemic change from incremental improvement, and treating the question of return on each hour as the central question of the role. The principles are drawn from a Speaking of Reliability conversation between Philip Sage and Fred Schenkelberg and have been translated here into a structured engineering doctrine in the The Mantua Group (TMG) voice.

The Beta Factor CCF Model

A First-principles Derivation of the Beta Factor Common Cause Failure (CCF) Model: Boolean Expansion, Worked Example, and the Irreducible CCF Floor for a Two-Pump Redundant System

The Beta Factor model is the simplest and most widely deployed mechanism for representing common cause failure (CCF) in fault tree analysis. Its single parameter, the beta factor, partitions the unavailability of every component in a common cause group into an independent share and a shared CCF share. This note develops the model analytically from first principles using the canonical two-pump example, demonstrates that the Beta Factor implementation in fault tree software is shorthand for an explicit three-event topology that can be built by hand, derives the closed-form expression for the top event unavailability in both its rare-event-approximated form and the exact form retaining the cross term, computes the irreducible CCF floor that constrains every redundant system, and reports a sensitivity table that quantifies how rapidly the CCF term overwhelms the independent term as beta increases. A closing argument explains why the rare-event approximation, although introducing an eighth-significant-figure error against the exact form, is the appropriate level of detail for routine engineering work given the parametric uncertainty inherent in the inputs.

The MOCUS Algorithm for Fault Tree Analysis

A Python Implementation of the Fussell, Henry, and Marshall (1974) Minimal Cut Set Algorithm, with Worked Examples That Reproduce the Results of the Original ANCR-1156 Report

The MOCUS algorithm, introduced by Fussell, Henry, and Marshall in 1974, is the foundational top-down method for obtaining minimal cut sets and minimal path sets from a fault tree. It works by replacing each gate with its inputs in a list of cut sets, extending rows for AND gates and branching new rows for OR gates, then eliminating duplicate events and supersets. The original implementation was written in FORTRAN IV for the IBM 360/75 computer at the National Reactor Testing Station. This paper presents a faithful Python reimplementation of that algorithm in approximately 250 lines of code, exercises it on the worked example from Figure 1 of ANCR-1156, reproduces the published minimal cut sets {1,2}, {2,3}, {1,4} and minimal path sets {1,2}, {1,3}, {2,4}, and further verifies the implementation against the more complex five-event tree of Appendix A of the report, including correct handling of house events. The Python code is provided as a companion module, mocus.py, that can be audited line by line against Section III.2 of the original paper and used as a reference oracle for verifying the output of commercial fault tree analysis tools.

The Reliability Engineer Gene

What Makes Reliability Engineers a Recognisable Profession Across Industries, Cultures, and Decades

Reliability engineering is unusual among engineering disciplines in the breadth of its territory and the consistency of its practitioners’ temperament. The same fundamental traits, curiosity, fascination with failure, comfort with statistics, willingness to learn, and the ability to recognise patterns that cross industry boundaries, recur in reliability engineers regardless of the language they speak, the country they work in, or the kind of equipment they happen to be analysing this week. The episode that gave rise to this paper proposed a gene metaphor: if a credible scientist were to sequence the DNA of a thousand reliability engineers, a common gene would emerge. The metaphor is intentional hyperbole, but the underlying observation is real. This paper sets out the profession’s recognisable traits, the multidisciplinary nature of the work, the universality of the underlying problems, and the implications for organisations hiring or developing reliability engineers.