The maintainability concept page defines the property: the repair-time distribution, its mean, its percentiles, and why a lognormal describes it. Those are measurements. This module is how the same numbers are produced from a design nobody has built yet, and the method is unglamorous: list the repairs, break each into the activities a technician performs, put a time on every activity, and weight the totals by how often each repair happens.
That last clause is the whole discipline. A repair that takes two hours and never happens costs nothing; one that takes ten minutes twice a week costs more than most people expect. The prediction is therefore not an average of repair times but a failure-rate-weighted average, and the ranking it produces routinely disagrees with the reliability programme's.
What the analysis produces
Two numbers and a list:
| Output | What it is |
|---|---|
Mct, mean corrective maintenance time | Σ λᵢ tᵢ ÷ Σ λᵢ, the number a specification usually names |
Mmax at a percentile | The 90th or 95th percentile of the fitted distribution, which is what sizes a maintenance window |
| The contribution list | Which items and which activities consume the time, which is what a designer can act on |
Where the method comes from
MIL-HDBK-472 is the source of the technique and carries five procedures, differing in how much design detail they need and how much confidence they return. Procedure V is the one most electronics programmes use: it synthesises a repair time task by task, and it comes in an early-design method and a detailed one. The other procedures exist for the cases where less is known, and choosing among them is a statement about how much design there is to analyse.
MIL-HDBK-470A is the other half and is often the more useful document: it is about designing for maintainability rather than predicting it, which is access, standardisation, fastener count, test points and the human at the end of the screwdriver. A prediction that produces a bad number and no design change has been run for its own sake.
MIL-STD-471 is the demonstration: a sample of induced faults, timed on real hardware by representative technicians, against the predicted mean and percentile. IEC 60706 carries the international treatment of maintainability requirements and studies through the design phase.
Where it sits in the programme
The prediction needs a maintenance concept, a repair-level decision and a parts list with failure rates, so it starts later than derating and earlier than any hardware exists. It is at its most useful when two design options are still open, because its absolute accuracy is modest and its comparative accuracy is good: this access scheme against that one, a plug-in card against a bolted assembly.
| Programme stage | What the prediction is for |
|---|---|
| Preliminary design | Comparing arrangements; establishing whether the MTTR requirement is even plausible |
| Detailed design | The full task-by-task synthesis, with the contribution list driving access decisions |
| Verification | The baseline the demonstration is measured against |
| In service | Corrected by observed repair times, which is when the assumptions get graded |
Its inputs come from three places. The failure rates come from the prediction, so the weighting is consistent with everything else. The fault-isolation performance comes from testability analysis, which is what makes the isolate activity short or long. And the task list itself comes from the maintenance concept, or from a maintenance task analysis where one exists.
How RAMSynapse will approach this
Maintainability Prediction is a roadmap module rather than a shipped one, so what follows is intent rather than description. It is planned to run on the same product structure as the prediction and the FMECA, so that each repairable item arrives with its failure rate already attached and the weighting cannot drift from the reliability model. The task-time breakdown would be held per item, with libraries of elemental activity times reusable across projects in the way the failure-mode library already works, and the isolation element would take its time from the testability model rather than from a separate judgement.
Until it ships, the analysis is done alongside the platform rather than in it, and the numbers on this page are the arithmetic that any spreadsheet or tool has to reproduce.