Reliability Allocation

Every reliability programme opens with an asymmetry: the customer states one number (a system MTBF, an availability, a probability of mission success) and the organisation that must deliver it is split across dozens of design teams, none of whom can do anything with a system-level figure. Reliability allocation closes that gap. It takes the top-level target and apportions it down the product structure, level by level, until every subsystem, assembly and unit carries a numerical budget its owner can design against.

Allocation is the mirror image of reliability prediction: prediction estimates what the design will achieve, allocation declares what each piece must achieve. One flows bottom-up, the other top-down, and a healthy programme runs both on the same product structure so the two can be compared line by line. The comparison: allocated versus predicted, element by element, is the earliest quantitative health gauge a programme has.

It is also the discipline that turns reliability from an aspiration into a contract. A budget that has been allocated, negotiated for feasibility, and released as a formal requirement is something a supplier can sign, a design review can test, and a verification programme can close. A system-level number that never got allocated is, in practice, nobody's problem.

What it is and why it exists

Reliability allocation (the older literature says apportionment; same thing) is the systematic division of a system reliability requirement among its constituent elements. The arithmetic is deliberately simple: under the series assumption, element failure rates add, so a system failure-rate budget can be divided the way money is divided, shares that sum to one, allocated down a hierarchy, conserved at every level. All the engineering content lives in how the shares are chosen, which is what the allocation methods are about.

The discipline is as old as reliability engineering itself. The Advisory Group on Reliability of Electronic Equipment (AGREE), a Department of Defense body established in 1952 under the Committee on Electronics, published its landmark report Reliability of Military Electronic Equipment in June 1957, and one of its lasting contributions is an allocation method that apportions a system reliability requirement by unit complexity, importance, and operating time. The ARINC apportionment technique, from ARINC Research Corporation's early-1960s reliability engineering literature, added the idea of weighting by observed or predicted failure rates. The feasibility-of-objectives technique, developed in the US Army's design-for-reliability handbook lineage for mechanical-electrical systems, contributed structured engineering-judgement ratings. All of these were later codified: alongside equal apportionment and an effort-minimisation algorithm, in the reliability allocation section of MIL-HDBK-338B, the electronic reliability design handbook, which remains the standard public reference for the method family. Programme standards made the activity mandatory long ago: MIL-STD-785B carries reliability allocation as a task in its own right, and every serious reliability programme standard since has kept some form of it.

Why does the activity exist at all? Because design teams need targets before designs exist. A prediction cannot be computed until there is a parts list; an allocation needs only a target and a product structure. It is therefore the first quantitative reliability act of a programme, and the one that forces the earliest, cheapest confrontation between what the contract demands and what the technology can plausibly deliver. An infeasible requirement exposed at allocation time costs a meeting; the same discovery at qualification time costs a redesign.

Where it sits in the programme

Allocation starts at the very front of the programme and never quite finishes. At concept stage, the system target (from the contract, from an availability requirement combined with expected repair times, or from safety targets that the functional hazard analysis assigns to critical functions) is allocated over the first-cut architecture with judgement-based methods. As the design matures and predictions appear, the allocation is re-run with methods that respect the emerging reality, and the budgets tighten from provisional to contractual. From then on the allocation lives as the requirements side of the reliability loop: predictions are measured against it, margins are argued over it, and design changes renegotiate it.

Downstream, the allocation's outputs are load-bearing far beyond the reliability group. Element budgets become formal requirements flowed to design teams and suppliers, the contractual backbone of the reliability case. Safety-critical budgets set the probability targets that fault trees are quantified against. And the allocation structure itself: the tree of owned elements, becomes the shared skeleton that prediction, hazard assessment and requirements management all hang from.

How RAMSynapse approaches this

RAMSynapse's Reliability Allocation module runs on the same shared product structure as Reliability Prediction: one BOM spine, so allocated targets and predicted rates always meet on identical elements. An MTBF goal is set on any element, one of six apportionment methods splits the budget with factor, share and allocated-MTBF previewed live, and the cascade repeats level by level. Methods can be mixed per level: ARINC where predictions exist, feasibility-of-objectives where only judgement does, which is how allocation is actually practised. A single click then turns allocated values into formal MTBF requirements in the project's requirements library and writes each element's FR, MTBF and R(t) targets into the requirement matrix, in the same unit and mission time the prediction module quotes.

On the live registry, the allocation elements anchor two flows: the functional hazard analysis allocates its functions onto them, and fault-tree top gates draw their probability budgets from them.