Australia operates two Canberra-class Landing Helicopter Docks, HMAS Canberra and HMAS Adelaide. They are two major amphibious platforms, nominally giving a degree of fleet redundancy for one of the Royal Australian Navy’s most significant capabilities.
At the time of writing, both are alongside at Fleet Base East, following what Defence has described as a technical issue in the propulsion system not previously encountered. Investigation and repair planning are reportedly under way.
From publicly available information, we do not yet know enough to draw conclusions about the cause of this specific issue. That uncertainty should be stated plainly, not filled with speculation.
But the cause is not actually the most interesting engineering question this situation raises. The more interesting question is structural:
How can a capability built around two major assets end up with both unavailable at the same time?
Put differently, two assets do not necessarily make two independent capability paths. Understanding why means moving past the incident itself and into a broader question of systems architecture.
Documented Context, Not Diagnosis
Before going further, one distinction needs to be held carefully throughout this article, because it is easy to blur in commentary on Defence capability: the difference between documented historical context and the cause of a current event.
The Australian National Audit Office has examined the Canberra class through its Major Projects Reports during acquisition and, in June 2025, through a dedicated sustainment audit (Auditor-General Report No. 50 2024–25). Its findings are a matter of public record.
The ANAO reported that the class entered service with substantial defects and deficiencies, some still unresolved when full operational capability was declared. LHD sustainment was placed on Defence’s Products of Interest list in March 2017, reflecting concerns about propulsion pod reliability and vibration at delivery, and about the maturity of the overall sustainment system. More recent findings documented an accumulation of urgent defects (223 open as of June 2025), maintenance backlogs, workforce shortfalls for organic-level maintenance, and availability targets missed since 2020–21. The audit also recorded total power failures during humanitarian missions to Tonga in 2022 and Vanuatu in 2023.
The ANAO’s own conclusion was that long-term LHD availability and reliability were at risk, mainly from accumulated urgent defects, maintenance backlogs and personnel shortfalls. It reached that conclusion independently of, and before, the current propulsion issue.
None of this establishes what caused the present problem. It would be methodologically unsound to draw that line, and this article does not attempt to.
What the documented history does provide is something different and, for this discussion, more useful: evidence that platform performance and support system performance have not historically been separable for this capability. That is the context in which a systems engineering question about redundancy is worth asking. It is not a retrospective explanation of the current fault.
Why Two Assets Are Not Automatically Two Independent Systems
The intuitive logic of redundancy is simple. If Asset A becomes unavailable, Asset B is still available, and the capability continues.
At the level of individual equipment, that reasoning holds. It becomes less reliable once the system boundary is widened to include what each asset depends on to stay operational.
Reliability engineering makes the hidden assumption explicit. For two units in parallel, the probability that both are unavailable at once is usually calculated as the product of their individual unavailabilities. If each asset were independently unavailable a quarter of the time, both would be down together only about one time in sixteen.
That arithmetic is valid only if the two are statistically independent. Independence is not a property of the hardware. It is a property of everything the hardware depends on.
Two platforms typically converge on a shared set of enabling systems:
- a maintenance workforce;
- specialist engineering knowledge;
- maintenance facilities and docks;
- diagnostic and support equipment;
- critical spares;
- OEM support arrangements;
- supply chains;
- configuration and technical data; and
- the engineering and certification authorities that release the asset for service.
Drawn structurally, the architecture is less often two parallel, independent paths. It is more often two assets converging on a common support dependency.
That shared dependency, not the hardware, can become the true single point of failure. And it typically sits outside the equipment diagram that redundancy assessments tend to examine.
Classical reliability theory has long shown how much this matters. In Barlow and Proschan’s treatment of repairable systems, a two-unit system served by a single repair facility performs measurably worse than the same two units with independent repair, because a second failure must queue behind the first. Nothing about the hardware has changed. Only the support architecture has. The same logic applies when two ships share one specialist workforce, one dock, or one pool of a critical spare.
Redundancy Is Not Resilience
This distinction deserves to be made explicit, because the two terms are often used interchangeably in capability discussions.
Redundancy asks whether another asset or path is still available if one fails.
Resilience asks whether the system as a whole keeps delivering the required outcome when disruption occurs.
Redundancy can contribute to resilience. It does not guarantee it.
The academic literature has drawn this line for decades. The ecologist C.S. Holling distinguished engineering resilience, the speed of return to a stable state after disturbance, from ecological resilience, the capacity of a system to absorb disturbance and keep functioning. In safety science, the resilience engineering movement associated with Erik Hollnagel, David Woods and Nancy Leveson reframed resilience as a property of the whole socio-technical system: its ability to anticipate, monitor, respond and learn. Neither definition can be satisfied by counting components.
A capability can hold duplicated equipment while staying exposed to common-cause failure, shared infrastructure, shared supply chains, shared maintenance capacity, shared technical authorities, or simply two simultaneous and competing demands on one scarce support resource.
Counting platforms is therefore not, on its own, enough evidence of capability resilience. That holds whatever is eventually found to have caused the present issue.
Drawing the Boundary Where Systems Engineering Actually Sits
A narrow system boundary, Canberra plus Adelaide, describes two ships.
A wider boundary includes the crews, maintenance organisation, engineering authority, supply chain, technical information, configuration management, OEM and contractor relationships, and workforce that together sustain them.
At that wider boundary, the governing question changes from:
Do we have two ships?
to:
Do we have two sufficiently independent capability paths?
That is a materially different engineering question, and it is the one systems engineering exists to answer.
It follows directly from the argument in this series’ earlier discussion of Integrated Product Support. Systems engineering cannot stop at the physical boundary of the asset. ISO/IEC/IEEE 15288 treats the enabling systems needed to sustain a system of interest as part of the systems engineering problem. Those enabling systems are part of the architecture that decides whether the capability can be delivered at all. A redundancy assessment done purely at equipment level will systematically understate the risk.
Common Cause Does Not Stop at the Hardware Boundary
Reliability engineers already have a well-developed vocabulary for this problem in hardware. Two identical components exposed to the same environmental condition, the same manufacturing defect or the same maintenance error are not truly independent. Common-cause failure analysis, including parametric approaches such as the beta-factor model, exists precisely because redundant hardware so often fails together. In the beta-factor model, a fraction of each component’s failure rate is assumed to be shared, and in many practical systems that shared fraction, not the independent failures, dominates the probability of losing both paths.
The same reasoning extends beyond the equipment boundary. Two assets may share:
- a supplier;
- a repair facility;
- a maintenance process;
- a software baseline;
- a workforce bottleneck; or
- an engineering decision process.
Common-cause failure does not stop where the hardware diagram ends. It reappears at whatever level the dependency is actually shared, hardware or otherwise.
Charles Perrow’s work on complex systems adds a further dimension. Where elements are tightly coupled, a disturbance in one spreads quickly to others. Two platforms that share a constrained support system are coupled through it, even though they never touch each other physically. A demand surge from one ship directly reduces the support capacity available to the other.
Safety-critical industries have also learned that duplication alone is weak protection against common cause. Nuclear and aviation practice relies heavily on diversity, using different designs, suppliers or methods for redundant paths, because identical paths tend to share identical weaknesses. Diversity is expensive, and it is not always appropriate. But it is the honest recognition that two of the same thing are not fully two separate things.
Toward a More Rigorous Test of Redundancy
A practical implication follows. When a review states that a capability “has redundancy”, that claim should be tested, not accepted at face value. Useful questions include:
- Redundancy against which failure mode?
- At what system level?
- For what required capability?
- Over what duration?
- Under what assumed repair, workforce, supply and infrastructure conditions?
- And which dependencies stay common to both paths regardless?
This turns redundancy from a count of physical assets into a capability-level engineering argument, one that has to be demonstrated rather than inferred from the number of hulls in the water.
The assurance community has a useful model for this. Assurance cases, structured arguments backed by evidence and widely used in safety engineering, require a claim to be broken down into sub-claims, each supported by evidence, with assumptions stated openly. A redundancy claim treated this way has to show its independence argument explicitly. Where the evidence for independence is missing, the gap becomes visible instead of being assumed away.
The right response to an identified common dependency is not necessarily full duplication, which is often uneconomic. It is a deliberate, documented risk decision, made through one or more of:
- duplication;
- alternative suppliers;
- a cross-trained workforce;
- additional inventory; or
- accepted and monitored risk.
A known dependency can be managed. An unexamined one cannot, because nobody has decided whether it is acceptable.
A Principle That Extends Well Beyond This Fleet
The same structural question applies across asset-intensive industries, whatever terminology each uses.
Two aircraft types may depend on one maintenance organisation or component supplier.
Parallel pumps or compressors may share power, cooling or control systems.
Multiple rail vehicles may share a depot, signalling infrastructure, or a single specialist repair capability.
Two production lines may depend on one critical spares supplier or one qualified technician.
In each case the principle is the same. Shared dependencies have to be identified and understood before redundancy can be claimed with confidence. The requirement is not that everything be duplicated. It is that nothing material be assumed independent without evidence.
For engineering leadership, the operative question is not how many assets exist. It is what must keep functioning, across the system of interest, its enabling systems, its interoperating systems, and the organisational and supply interfaces between them, for the capability to keep delivering its required outcome.
Redundancy Is Designed. Resilience Is What Remains.
To return to where this began: Australia has two Canberra-class LHDs, and both are currently alongside with a propulsion issue that Defence has described as not previously encountered. The cause has not yet been publicly established, and this article has deliberately avoided inferring one.
What the situation does usefully illustrate is a principle that holds whatever the cause:
Redundancy cannot be established by counting assets. It has to be demonstrated across the architecture needed to deliver the capability.
Redundancy is what is designed into the architecture.
Resilience is what remains when part of that architecture fails.
The difference tends to become visible only when the system boundary is drawn wide enough to see it, and ideally before something fails, not after.
Aerion Engineering Advisory
Aerion Engineering Advisory helps organisations test capability claims against the architecture that actually delivers them.
Our approach connects systems engineering, RAM, common-cause failure analysis, Integrated Product Support and operational evidence. We help organisations identify shared support dependencies, assess whether redundancy is real at capability level, and make deliberate, documented decisions about the risks they choose to accept.
