RAMS Core

PublishedSAE JA1011 · SAE JA1012 · MSG-3 · MIL-STD-3034A

Reliability Centred Maintenance

Which failures deserve a scheduled task, which one, and how often: the analysis that decides what the maintenance programme contains.

Every scheduled maintenance task in existence was put there by somebody. Reliability centred maintenance is the argument for why each one is there, and, far more often than practitioners expect, the argument for deleting it.

The method starts from a position that was radical when the airlines arrived at it in the 1960s and is still resisted today: most failures are not age-related, so most scheduled overhauls do nothing except introduce the failures that follow maintenance. What replaced the overhaul was not a different interval. It was a question about consequences, asked one failure mode at a time.

The chain

From an item to a maintenance task. Each step is a question with a recorded answer, and the strategy at the bottom is chosen per failure mode rather than per item.
From an item to a maintenance task. Each step is a question with a recorded answer, and the strategy at the bottom is chosen per failure mode rather than per item.
StepThe question
FunctionsWhat must it do, and to what standard, in this operating context?
Functional failuresIn what ways can it fail to do that?
Failure modesWhat causes each of those?
Failure effectsWhat happens when the mode occurs?
Failure consequencesWho does that hurt: safety, the environment, operations, or only the budget?
Decision logicGiven the consequence, what task, if any, is both applicable and effective?
Failure management strategyCondition-based, restoration, discard, failure-finding, servicing, run to failure, or redesign

The output is a maintenance requirement: a task with an interval and a reason. What the task costs in hours, people and parts is the task analysis; where it is performed is the level of repair analysis. Those two consume this module's output and neither can start without it.

What the standard is, and what it is not

SAE JA1011, Evaluation Criteria for Reliability-Centered Maintenance (RCM) Processes, is not a process. It is a set of minimum criteria that any process must satisfy before it may be called RCM, and it deliberately declines to prescribe how the analysis is performed. That is what makes it the right anchor for a generic engine: it is asset-agnostic, written for any organisation that owns, makes or uses physical assets, and it does not care whether the asset is an aircraft, a pump or a substation.

Its current revision is JA1011_202411, revised November 2024, which supersedes the widely cited 2009 revision and the 1999 original. Anything describing "JA1011 (2009)" as current is out of date. Its companion, SAE JA1012, A Guide to the RCM Standard, current revision JA1012_201108 of August 2011, amplifies and clarifies each criterion, and is explicit that it too is not a procedural manual.

The criteria were not invented in a committee room. The original issue names three sources: the 1978 United Airlines report by Nowlan and Heap that started the discipline, the US Navy standard and handbook lineage, and Moubray's RCM2.

One engine, several rule sets

The criteria standard underneath, sector logic on top. The analysis is the same shape in all of them; the question wording, the task codes, the approval route and the deliverables are not.
The criteria standard underneath, sector logic on top. The analysis is the same shape in all of them; the question wording, the task codes, the approval route and the deliverables are not.
Where you areWhat you work toWhat it adds
AnywhereSAE JA1011, guided by JA1012The criteria a process must meet, and nothing about how to run it
Civil aviationATA MSG-3Scheduled maintenance development for transport aircraft, with its own logic, task codes and certification route
DefenceMIL-STD-3034AThe RCM process as a defence requirement, structured to be run and audited as a procedure
S-series supportabilityASD/AIA S4000PPreventive maintenance analysis whose task requirements are handed on to task analysis through S3000L
Industrial, internationalIEC 60300-3-11The application guide an industrial programme cites for recognised practice

A tool that implements this well runs one analysis engine and several rule sets: the same chain of functions, failures, modes, effects and consequences, with the sector's question wording, task vocabulary and outputs applied on top. The generic engine is what makes the analysis portable; the rule set is what makes the result acceptable to whoever has to approve it.

Two practical notes on the rule sets. The civil aviation document is MSG-3 Volume 1 for fixed-wing aircraft, Revision 2022.1, and its revisions are dated rather than lettered: 2022.1 follows 2018.1, 2015.1, 2013.1, 2011.1 and back through 2001.1 to the 1980 original. There is no 2021.1 and no 2023.1, whatever a supplier's documentation may say. Revisions are driven by Issue Papers approved by the International Maintenance Review Board Policy Board, each with its own number, and a revision is the batch of papers accepted since the last one: a tool that claims MSG-3 support is claiming support for a specific revision and should say which. Its first-level analysis sorts each failure into one of five categories numbered 5 through 9, referred to as routes in maintenance review board reports. The numbering starts at five, which catches out anybody who assumes the categories run from one.

Where it sits

Programme stageWhat the analysis is doing
DesignFeeding back: modes with no acceptable task are design requirements, not maintenance ones
DevelopmentBuilding the initial scheduled programme, before there is any service experience
Entry into serviceConservative intervals, with age exploration planned to earn the right to extend them
In serviceRevising intervals and tasks against what the fleet actually did, through FRACAS

What it is not

  • It is not the whole maintenance programme. Corrective work exists because most modes are deliberately run to failure, and that work is analysed and planned like any other.
  • It is not task analysis. This module decides that a task exists and how often; the task analysis decides what it takes to do it.
  • It is not a preventive-maintenance optimiser. Nothing here computes the cost-optimal interval from a hazard function. The decision structure is qualitative first, and quantitative only where a number is available and relevant.
  • It is not a reason to do more maintenance. A properly run analysis usually removes tasks, and the ones it adds are mostly failure-finding checks on things nobody was looking at.

Want to see this on a live system model? Request a walkthrough.