Allocation in practice is a top-down ritual with a fixed grammar: fix the target, split it into its basic and mission lines, fix the structure, choose the method the data can support, weight honestly, cascade, feasibility-check, release. Each pass is quick; the value is in doing it deliberately and in expecting to do it again.
1. Fix the system-level target
The cascade can only be as good as the number at its top, so the first step is forensic: establish what the target is, where it binds, and in what currency.
| The target comes from | What it converts to |
|---|---|
| A contractual MTBF or failure-rate clause | The rate budget directly; check the clause's clock (operating vs calendar hours) |
| An inherent-availability requirement Ai plus a repair concept | λ* = (1/Ai − 1)/MTTR at steady state; an operational-availability clause carries logistics and administrative delay, so it converts through MTBM and MDT instead, and either way the maintainability assumption is written down beside the budget |
| Mission-success probability over a defined mission | λ* = −ln(R*)/t at the declared mission time, under the constant-rate assumption |
| Safety targets on critical functions (from the FHA) | Probability budgets for the specific functions, allocated alongside, not instead of, the basic-reliability budget |
Two disciplines at this step save months later. Declare the unit and the clock once (the same declarations the prediction side makes), because the allocated-versus-predicted comparison dies quietly when the two sides quote different currencies. And where both a basic-reliability target and mission-critical safety targets exist, keep them as separate budget lines: a box can be reliable enough for the logistics case and still too failure-prone for the safety case, and one number cannot police both.
2. Split the target into basic and mission budgets
Step 1 produced the hardware-reliability number, and any safety-function budgets riding alongside it. Almost every programme has to carry a second hardware line as well, because a system generates two different failure counts and they diverge precisely where the architecture gets interesting.
Basic reliability counts every failure the hardware produces, with nothing excused: a failure the system rode through, a failure in a channel nobody was using, a failure a partner unit covered for. Each one still raises a fault report, consumes a maintenance action, pulls a spare off a shelf and creates a logistics event. Mission reliability counts only the failures that abort the mission (or the dispatch, or the safe state, whichever the contract defines). The two budgets cascade down the same product tree and apply opposite rules to one structure: redundancy. A redundant group is one line in the mission budget and as many lines as it has members in the basic budget, because two boxes are two boxes to the supply chain however gracefully the pair degrades. This is why MIL-STD-785B asks for a basic-reliability model in which every hardware element sits in series, redundant members included: that model exists so spares, maintenance manpower and training can be sized off it.
The rules therefore do not conflict, they belong to different lines. Budgeting the redundant group as a single element, the guard in the foundations chapter, is the mission budget's rule. Summing redundant members as though they were series elements, the error the pitfalls chapter names, is an error in the mission budget only; in the basic budget that sum is the definition.
The divergence, on the worked example
Take the worked example at the point its feasibility check bites. The trackside power module could not honestly promise the 152,500 hours the ratings handed it, the rebalance bought the shortfall from the communications gateway, and the level closed at 9.56 + 17.49 + 11.00 + 11.95 = 50.0 f/10⁶ h. Redundancy is the other escalation route the feasibility step allows, and laid on top of that rebalanced level it settles the same finding a second way: two trackside power modules in active parallel, each built to the 11.00 f/10⁶ h (90,900 h) that sits inside demonstrated capability, either one sufficient to hold the signals. The mission line for the pair is then computed over the 730-hour reporting month the gateway's AGREE split already declares.
Each module's probability of failing inside the month:
FC = 1 − e^(−11.00 × 10⁻⁶ × 730) = 0.007998
The pair stops the system only if both are down, and its equivalent rate over the declared window follows from that, on two conditions worth stating with the number: no credit is taken for repairing the first module inside the month, which makes the figure a conservative ceiling, and the equivalent rate scales with the window chosen, so the window travels with the budget:
Fpair = FC² = 6.40 × 10⁻⁵
λpair = −ln(1 − 6.40 × 10⁻⁵) / 730 = 0.088 f/10⁶ h
| Element | Basic budget λ (f/10⁶ h) | Mission budget λ (f/10⁶ h) |
|---|---|---|
| A · Axle-counter interface | 9.56 | 9.56 |
| B · Interlocking logic unit | 17.49 | 17.49 |
| C₁ · Trackside power module | 11.00 | 0.088 for the C₁ + C₂ group |
| C₂ · Trackside power module | 11.00 | (no line of its own) |
| D · Communications gateway | 11.95 | 11.95 |
| Σ | 61.00 | 39.09 |
| System MTBF budget | 16,400 h | 25,600 h |
The pair contributes 22.00 f/10⁶ h to one budget and 0.088 to the other, a factor of 250 between two readings of the same two boxes. Rolled up: 10⁶ / 61.00 ≈ 16,400 h of basic reliability against 10⁶ / 39.09 ≈ 25,600 h of mission reliability. One architecture, two verdicts: the mission line lands 28% above the 20,000-hour contract target and the basic line 18% below it. Which verdict the contract meant is exactly what step 1's clause forensics has to settle, and a well-written specification states both.
Redundancy is the loudest case, not the only one. The two budgets separate wherever an item is less than fully mission-essential: the gateway's fallback cellular path carries an AGREE importance of 0.4 because losing it alone does not stop the system, yet every one of its failures is a full line of maintenance work. That separation sits one level below the table above, which carries the gateway's single level-1 figure in both columns; split D's own AGREE units into the two currencies and its basic line lands near 36 f/10⁶ h against the 11.95 its mission line carries. Allocating both budgets is what makes that trade visible at concept stage, when it is still cheap: the second power module has to buy its basic-budget line from a sibling's allowance, or the basic target has to move.
Who reads which budget
| Downstream consumer | Budget it reads | Why |
|---|---|---|
| Spares provisioning, maintenance manpower, support cost | Basic | Every failure is a removal, a spare and a labour hour, whether or not the mission continued |
| Level of repair and maintenance policy decisions | Basic | These trade repair locations and task intervals against the volume of maintenance events, not against aborts |
| Mission-success and dispatch cases, the RBD roll-up | Mission | Only aborting failures reach the structural model's top event |
| Fault tree top-gate probability budgets | Mission | A top event names a mission or safety consequence, not the maintenance action a failure generates |
| Availability | Both | Uptime is driven by the mission line; the repair workload that produces the downtime comes off the basic line |
| Allocated-versus-predicted comparison | Both, separately | A parts-count prediction is a basic-reliability roll-up; only the structural model turns it into the mission number |
| If the programme allocates | What breaks |
|---|---|
| The mission budget only | Redundancy looks free. Nobody owns the failure count, so the spares list, the manpower estimate and the support cost arrive unbudgeted; the system meets its mission target and misses its cost of ownership, and the miss surfaces in service, where it is most expensive to fix |
| The basic budget only | Redundancy is pure penalty (22.00 against a simplex 11.00), so the architecture that rescued the mission case is rejected by the only budget on the table, and improvement effort chases whatever fails most instead of whatever aborts most: the rarely energised fallback path competes for attention on equal terms with the radio carrying the traffic |
Both budgets descend the structure of the next step, on identical elements and in the same unit and clock. Only the rule at redundant groups and non-essential items differs, never the tree.
3. Establish the allocation structure
The tree the budget cascades down is not the CAD tree or the cost breakdown; it is the ownership structure: every element on it must have exactly one owner who can sign for a number. Practical consequences: elements are drawn at the boundaries where responsibility changes hands (in-house team, subcontractor, COTS vendor); shared services that several branches depend on, a power bus, a cooling loop, a system computer, get their own budget lines rather than being smeared across their consumers; and the structure is the same one the prediction rolls up, so the two flows meet on identical elements.
| Structuring rule | Why |
|---|---|
| One owner per element | A budget nobody signs is a wish |
| Split at responsibility boundaries | Budgets become flow-down requirements verbatim |
| Shared services are elements | Otherwise their failures are double-counted or orphaned |
| Same spine as prediction | Allocated-vs-predicted must compare identical nodes |
4. Choose the method per level
Method choice is a per-level decision, not a per-programme one, and mixing methods across levels is normal practice, not a compromise: at the system level predictions for its children may already exist (ARINC), one level down only judgement does (feasibility of objectives), and a consortium boundary may impose a contractual split (weighted factor) regardless of engineering.
| Situation at this level | Sensible method |
|---|---|
| Nothing known yet | Equal apportionment, flagged as provisional |
| Part counts only | Equal failure rate |
| Judgement available, data thin | Feasibility of objectives |
| Duty cycles and criticality differ between children | AGREE |
| Predictions exist for the children | ARINC |
| The split is negotiated or contractual | Weighted factor |
5. Gather the weights honestly
The pipeline is only as honest as its weights. Part counts should come from the current structure, not last quarter's. ARINC weights inherit every defect of the prediction they read; an ARINC allocation over a stale or padded prediction is that garbage, scaled. And ratings deserve process: written ground rules per factor (what earns a 3, what earns an 8), scored independently by more than one engineer where the stakes justify it, reconciled openly, and archived with the allocation, because six months later the question will not be "what is B's share" but "why is B's share 35%", and the ratings sheet is the only good answer.
| Weight source | Honesty check |
|---|---|
| Part counts | From the current BOM revision |
| Predicted rates (ARINC) | Prediction current, same units, same mission time |
| FOO ratings | Written criteria · independent scoring · rationale archived |
| Explicit weights | The scheme's justification written next to the numbers |
6. Apply and cascade
Compute shares, allocate the budget, and hand each child its number as its own goal; then repeat one level down, child by child, until the tree bottoms out. Two boundary rules govern the descent. Stop where design freedom stops: a COTS unit's budget cannot exceed what its datasheet or field history supports, allocating 200,000 hours to a unit whose vendor demonstrates 90,000 is not ambition, it is a feasibility finding waiting to be escalated. And stop at the level where verification will happen: a budget below the level anyone will ever predict, test or measure against is bookkeeping without a customer.
7. Feasibility-check every budget
An allocation that has not been checked against reality is a wish list with arithmetic. Every budget line gets held against the best available evidence (similar-equipment experience, an early parts-count prediction, vendor data), and the failures of that check are the point of the exercise:
| Finding | Response |
|---|---|
| One child's budget is infeasible, siblings have slack | Rebalance: shift rate allowance between siblings, re-run the level |
| The whole level is infeasible | Escalate: the architecture cannot meet the target; redundancy (an RBD decision) or target renegotiation |
| Everything passes comfortably | Suspect the target, then bank the slack as management reserve rather than gifting it |
The reserve point is worth making explicit: mature programmes deliberately allocate slightly tighter than the requirement, holding back a few percent of the rate budget, so that the first surprise consumes reserve instead of reopening every sibling's contract.
8. Release and re-allocate
Budgets earn their keep only when released as formal requirements ("MTBF shall exceed X hours at the stated conditions") flowed to design teams and suppliers, each with a named verification route (early: prediction; later: test, demonstration, or field data). From that moment the allocation is under change control: it gets re-run at design milestones, when the structure changes, when predictions move materially, or when a feasibility finding forces a rebalance, and each re-run updates the existing requirements traceably rather than spawning parallel truths. An allocation last touched at the proposal is not a baseline; it is an artefact.