The engineering evidence can look convincing.
Reliability predictions indicate acceptable failure behaviour.
Failure Mode and Effects Analysis (FMEA) provides comprehensive coverage.
Maintenance analysis establishes credible preventive and corrective maintenance requirements.
Reliability, Availability and Maintainability (RAM) modelling predicts that the required availability should be achieved.
Yet once the system enters service, operational availability starts to fall below expectations.
Maintenance takes longer than anticipated. Fault isolation becomes difficult. Logistics delays increase downtime. Operational tempo differs from the assumed profile. Workarounds gradually become part of normal operation. This is a pattern the sociologist Diane Vaughan described, in a different context, as the normalisation of deviance: departures from the intended way of working become accepted as standard practice.
The immediate question is often:
What was wrong with the model?
Sometimes the model does need correcting. But there is another possibility. The mathematics may have been sound, while the boundary conditions surrounding the analysis were incomplete.
The statistician George Box famously observed that all models are wrong, but some are useful. A RAM model is useful exactly to the extent that its assumptions keep representing the system that actually exists. When availability falls short, the more productive question is often not whether the model was wrong, but where its representation and reality have parted ways.
The Confidence Gap
Engineering confidence is built on evidence.
Component reliability data indicates expected failure behaviour.
FMEA and FMECA identify potential failure modes and their consequences.
Maintainability analysis estimates restoration times.
RCM develops maintenance requirements.
RAM models combine these inputs to predict system-level performance.
These disciplines are essential. Without them, availability planning becomes little more than assumption.
But operational availability is not produced by reliability statistics alone. It emerges from the interaction between the engineered system and its support and operating environment. That includes:
- equipment accessibility;
- fault detection and isolation capability;
- repair complexity;
- workforce availability and competence;
- spare parts availability;
- supply chain and logistics delay;
- maintenance facilities and support equipment;
- environmental severity;
- utilisation and operational tempo;
- system configuration; and
- the organisation's response to failures.
A RAM model can represent many of these variables. The question is whether the assumptions used to represent them remain credible once the system meets operational reality.
Reliability Is Not Availability
Reliability and availability are closely related, but they answer different engineering questions.
Reliability is the probability that a system or item performs its required function without failure for a specified period under stated conditions.
Availability is whether the required capability is actually there when it is needed.
The standard availability measures make the distinction explicit. Inherent availability considers only failure frequency and active repair time, and is often expressed as MTBF divided by the sum of MTBF and MTTR. It describes what the design could achieve in an ideal support environment. Operational availability replaces active repair time with total downtime, including logistics delay, administrative delay, waiting for spares, waiting for maintainers, and the time taken to find the fault in the first place. The gap between the two is where many in-service shortfalls live.
Failure frequency matters. So does recovery.
A component may have excellent reliability but sit where replacement requires extensive disassembly.
A subsystem may fail infrequently but have poor diagnostic capability, so technicians spend hours locating the fault.
A spare may be provisioned according to a statistically sound model, yet still cause extended downtime if replenishment lead times or operational demand differ from the original assumptions.
A redundant architecture may tolerate individual failures, until maintenance activity, configuration changes or common-cause dependencies erode the expected protection. Reliability engineers model this through common-cause failure methods, such as the beta-factor approach, precisely because redundancy on paper is not always independence in practice.
In each case, the reliability evidence may remain valid. What changes is the system's ability to detect, isolate, repair, replace, restore and return capability to service.
Availability is therefore not simply a reliability outcome.
It is a system outcome.
Where the Divergence Begins
When predicted and observed availability diverge, attention naturally turns to the RAM model. But the source of the divergence may lie much further upstream.
Consider the cumulative effect of apparently reasonable design decisions:
Equipment packaging is tightened to reduce footprint.
Access provisions are reduced because space is constrained.
Redundancy is removed to reduce acquisition cost or complexity.
Diagnostic capability is deferred to a later increment.
Standardisation is compromised by subsystem-specific design choices.
Support equipment requirements emerge only after the physical architecture has matured.
Each decision may be defensible in its immediate context. Together, however, they shape the system's recoverability.
By the time poor availability becomes visible in service, those decisions may be several years old.
What now looks like a maintenance problem may actually originate in equipment layout.
What looks like a supply problem may reflect assumptions about failure demand or operational tempo.
What looks like excessive repair time may come from inadequate testability or accessibility.
The operational symptom appears downstream. The engineering cause may have been built in much earlier.
Recoverability Is an Architectural Property
This is why maintainability, accessibility and diagnostic capability should not be treated only as sustainment concerns. They are architectural variables.
System partitioning determines what must be removed to reach a failed item.
Equipment layout determines whether maintainers can physically perform the required tasks.
Built-in test and instrumentation influence how quickly faults can be detected and isolated.
Modularity affects replacement strategy.
Interface design affects whether failures can be contained.
Redundancy determines whether capability can continue while repairs take place.
These characteristics directly affect restoration time, and therefore availability. They are difficult, and often expensive, to correct once the physical architecture has matured. The design literature has long recognised this. Maintainability and testability are most effectively designed in, and much harder to add later.
Programs seeking strong availability outcomes therefore need to ask these questions while the design is still flexible:
How will this system fail?
How will we know what has failed?
How will maintainers access it?
How quickly can the failed function be restored?
What resources must be available for recovery?
What happens when actual operating conditions exceed our assumptions?
These are not questions to defer until sustainment planning.
They are design questions.
The Assumption Problem
RAM modelling necessarily relies on assumptions. That is not a weakness. It is inherent in predictive engineering.
It helps to distinguish between two kinds of uncertainty. Aleatory uncertainty reflects the natural randomness of failure, which no amount of study will remove. Epistemic uncertainty reflects gaps in knowledge: about the operating environment, the support system, the true failure behaviour of a new design. Epistemic uncertainty can be reduced with evidence, but only if the organisation goes looking for it.
The risk arises when assumptions gradually come to be treated as facts.
A predicted repair duration may assume immediate access to trained personnel.
Logistics delay may assume established supply arrangements.
Failure rates may be based on environmental conditions that differ from actual operation.
Utilisation may be based on a representative mission profile that later changes.
Preventive maintenance effectiveness may assume tasks are carried out at the intended interval and under the intended conditions.
Each assumption may be reasonable when it is set. But long-life assets rarely operate for decades under the conditions originally predicted.
This is why RAM should stay connected to operational evidence throughout the lifecycle.
Closing the Loop with Operational Evidence
Once a system enters service, engineering gains something it did not have during design:
evidence of actual behaviour.
Observed failure rates can be compared with predictions.
Actual repair durations can replace estimated values.
No-fault-found events can expose diagnostic weaknesses.
Supply delays can reveal logistics assumptions that need revising.
Maintenance records can show whether planned tasks are achieving their intended outcomes.
Operational profiles can show whether utilisation assumptions are still representative.
FRACAS, maintenance data, configuration information and operational performance should therefore steadily challenge and refine the original RAM assumptions. A useful lifecycle loop is:
Predict → Observe → Compare → Investigate → Correct → Recalculate
The purpose is not to prove the original model wrong. It is to keep the engineering representation aligned with the system that actually exists, and to turn epistemic uncertainty into knowledge.
From Engineering Confidence to Operational Confidence
Engineering confidence and operational confidence are related, but they are not the same.
Engineering confidence comes from evidence that the design should perform as intended.
Operational confidence comes from evidence that the capability can keep performing, and recover effectively when things go wrong, under real operating conditions.
Strong lifecycle engineering connects the two.
Reliability predictions inform architecture.
Maintainability analysis influences equipment layout.
FMEA and FMECA inform failure tolerance and diagnostic requirements.
RCM establishes technically appropriate maintenance.
FRACAS and operational data then test those assumptions once the system enters service.
The result is not a static availability prediction. It is an engineering process that continually improves the organisation's understanding of the system.
Availability Must Be Architected
When availability falls below expectation, the RAM model should certainly be examined. But it should not automatically take the blame.
The more useful investigation is broader:
Which assumptions changed?
Which dependencies were left out?
Which operational conditions differed from those modelled?
Which design decisions increased restoration time?
Which support constraints became availability drivers?
And which early trade-offs shaped the system's ability to recover from failure?
These questions move the conversation beyond whether the original calculation was correct. They ask whether the system architecture, support system and operational environment together support the availability being demanded.
The philosopher Alfred Korzybski reminded us that the map is not the territory. In lifecycle engineering, the RAM model is the map.
The model describes what we expect.
The architecture determines what is possible.
Aerion Engineering Advisory
Aerion Engineering Advisory helps organisations understand the engineering drivers behind reliability, maintainability and operational availability across the system lifecycle.
Our approach connects RAM modelling, FMEA/FMECA, RCM, FRACAS, maintainability and Integrated Product Support with system architecture and operational evidence. We help organisations identify why predicted performance and actual asset outcomes diverge, and where engineering intervention can create the greatest lifecycle value.
