Home

The Robot Must Know What Can Fail Together

Asset 001 title image
9F44F805 8D83 45CE A65B E56CDC0558CB
The Robot Must Know What Can Fail Together

Technical Article

The Robot Must Know What Can Fail Together

Common-Cause Failures, Fault Containment and the Architecture of Meaningful Redundancy

Author: Dirk Geiger · Date: 2026.09.06 · Contact: info@dxresearch.eu

Humanoid redundancy matters only when backup functions survive shared failures across power, timing, communication, compute, sensing, cooling, and supervision domains.

Executive Summary

Humanoid reliability cannot be designed by counting independent component failures when many failures share the same cause. One power rail, clock, network switch, cooling path, software service, connector, or corrupted state estimate can disable multiple supposedly redundant functions at once. This chapter argues that Physical AI needs dependency architecture: identify shared resources, define fault-containment regions, separate critical functions, detect cascading effects, and preserve enough independent capability for controlled degradation. Functional-safety practice already treats common-cause and dependent failures as central architectural concerns, while recent fault-tolerant robotics research shows how control can adapt when actuator effectiveness is lost. The semiconductor implications span power partitioning, redundant sensing, clock diversity, watchdogs, safety islands, network segmentation, diagnostics, isolation, memory protection, and independent shutdown paths. The goal is not maximum redundancy. It is independence. A humanoid becomes resilient when one hidden dependency cannot simultaneously remove perception, control, actuation, communication, and the mechanism intended to protect them.

Redundancy Is a Claim About Dependencies, Not Component Count

Two controllers, two encoders or two network links look redundant on a block diagram. That redundancy has value only if one channel remains usable after the failure that removes the other. Redundancy adds alternative means of delivering a function; Independence determines whether those alternatives survive the same event. Safety engineering has treated this problem for decades because assuming independent failures when an architecture contains hidden coupling produces optimistic reliability estimates. IEC 61508-6 includes a methodology for quantifying hardware-related Common-cause failure effects. [1] SAE work on safety-critical E/E architectures likewise makes independence particularly important between a function and its associated safety mechanism. [3] For a humanoid, a backup only counts if the resource that disables the primary does not disable the backup too.

Three Ways Failures Become Dependent

A Dependent failure can arise through several mechanisms. A common-cause failure begins with one shared initiating condition: loss of a DC rail supplying two controllers, a coolant loss heating two processors, or a connector failure interrupting several sensor paths. A Common-mode failure occurs when nominally separate channels share a vulnerability and therefore fail in the same way, such as identical sensors saturating under the same physical condition. A Cascading failure begins locally but propagates, such as a short circuit pulling down a shared supply or a corrupted network node forcing repeated resets. Classic work on “redundancy killers” shows why physically related failures can severely reduce the benefit expected from redundant subsystems. [4] Modern humanoids intensify the concern because power, compute, communication, timing, cooling and packaging are tightly integrated for mass and volume efficiency.

The Humanoid Has More Shared Dependencies Than the Schematic Shows

The obvious dependencies are electrical. A torso DC bus can supply both left and right limb controllers. A common clock may timestamp otherwise separate sensors. A central Ethernet switch may carry both primary and backup data paths. Less visible dependencies can be equally important: one software service can feed state to several controllers; one localization estimate can influence balance, manipulation and navigation; one heatsink or airflow path can cool multiple processors; one harness can carry several supposedly diverse channels through the same moving joint. These are Shared dependency relationships. They should be modeled explicitly because the functional graph of the robot differs from the component graph. High integration can reduce cost, mass and latency, but it can also enlarge the consequence of a single hidden dependency. Earlier research on highly integrated safety-critical E/E systems warned that consolidation can increase the impact of common-mode failures and therefore raises the importance of failure management. [5]
Visual pending: Systems concept

Meaningful Independence Has Several Dimensions

Independence is not one thing. Electrical independence asks whether channels share power conversion, return paths or protection. Temporal independence asks whether a shared clock or synchronization service can invalidate multiple channels together. Communication independence asks whether nominally separate paths cross the same switch, PHY, cable or connector. Computational independence asks whether tasks share memory, operating-system services, an accelerator or a common algorithmic assumption. The architecture can respond with separation and, where justified, diversity. Functional diversity uses different functional principles; Technological diversity uses different implementation technologies to break a credible common vulnerability. The IEC 61508 Edition 3 development process reflects the continuing need to address modern electronic architectures, with the Association reporting a revised structure and additional focus on complex semiconductors. [2] Diversity is valuable when it breaks an actual shared dependency, not when it merely increases part count.

Fault Containment Is the Architectural Countermeasure

A humanoid cannot eliminate every failure. It can reduce the radius of each failure. A Fault-containment region groups components so faults can be detected and isolated before they propagate into unrelated functions. Fault containment therefore combines electrical protection, communication segmentation, software partitioning, diagnostics and explicit reconfiguration. Consider a left-knee actuator node. A winding short or inverter fault should ideally trip local current protection, isolate the affected power branch, report the fault and update available torque. The rest of the robot should retain right-leg control, arm control, perception, central compute and independent safety supervision. If instead the knee fault collapses a shared rail, resets the network and interrupts compute, then the architecture has converted one local actuator fault into a robot-wide event. The difference is containment design.

The Semiconductor Architecture Defines the Fault Radius

Semiconductors provide many mechanisms that make containment real: zonal power switching, e-fuses, load switches, current and voltage monitoring, isolated interfaces where required, watchdogs, protected memory, independent timers, safety-capable MCUs, communication diagnostics and protected shutdown paths. A Safety island can supervise critical resources separately from high-performance compute. A Protection domain can limit which software or hardware element may corrupt another. Non-interference is especially important when different criticalities share compute or communication. SAE work explicitly distinguishes non-interference from stronger independence and explains why safety mechanisms need appropriate separation from the functions they protect. [3] For humanoids, this becomes practical when AI, motion planning, servo control and safety supervision share a SoC, memory hierarchy or network fabric.
Visual pending: Systems concept

Diagnostics Must Identify Impact, Not Just Fault Presence

A diagnostic bit that says “fault” is not enough for graceful operation. The robot must know what the fault actually removed. Fault detection and isolation should identify the affected node or dependency domain and support a revised capability model. Diagnostic coverage matters because undetected faults invalidate assumptions about independence, while false positives unnecessarily remove useful capability. The capability model should answer practical questions: Can this joint still deliver reduced torque? Is the sensor unavailable or merely degraded? Did the network lose one domain or the only path to safety supervision? Does a temperature alarm affect one processor or a cooling path shared by both? Diagnosis becomes system architecture when its output is a revised statement of what the robot can still trust, not merely a maintenance code.

Fault-Tolerant Control Starts After Architecture Has Preserved Something to Control

Control algorithms can compensate only if sufficient independent capability survives. Recent manipulator research addresses partial Loss of effectiveness while respecting actuator saturation and reports stability under the study assumptions as long as remaining actuation can overcome the required dynamics. [6] A 2025 adaptive time-delay-estimation strategy similarly aims to recover trajectory performance after actuator faults. [7] These results are important, but they do not remove the architectural prerequisite: if the same power or communication failure disables the remaining actuator channels, fault-tolerant control has no surviving authority to exploit. Whole-body robotics makes the problem more coupled. FT-WBC estimates lower-limb faults and adapts posture to maintain stability and preserve as much manipulation workspace as possible under weakening or locked actuator failures. [8] This is Reconfiguration in action: the robot changes how it uses its remaining body because available capability has changed.

Graceful Degradation Needs a Dependency-Aware Capability Map

Graceful degradation should not mean continuing operation at any cost. It means deliberately matching the task to what remains independently trustworthy. After one arm joint degrades, manipulation reach or payload may be reduced while locomotion remains available. After one perception sensor is lost, remaining modalities can support slower movement with larger uncertainty margins. After one communication domain is isolated, the robot may enter restricted operation if an independent safety path remains. The hard case is loss of a shared critical dependency. If safety supervision, control authority or power integrity cannot be guaranteed, the capability map must mark affected functions unavailable and transition toward a controlled minimum-risk condition. A dependency-aware robot should lose only the capability the failure actually removes—but it must acknowledge when one shared failure truly removes several capabilities together.
Visual pending: Systems concept

A Dependency Matrix Is More Useful Than a Redundancy Checklist

A practical engineering artifact is a dependency matrix. Put robot functions on one axis—locomotion, balance, manipulation, perception, communication, compute and safety—and shared resources on the other—power rails, clocks, networks, memory domains, cooling paths, connectors, state estimates and software services. Mark every dependency. Then ask whether one resource failure defeats both a function and its mitigation. This analysis often exposes surprising Single point of failure conditions. A duplicated sensor pair may share one cable through the hip. Independent processors may depend on one thermal-management controller. A safety task may use the same memory subsystem as the application it supervises. The matrix should feed FMEA, fault-tree analysis, dependent-failure analysis, physical routing decisions and verification tests. The point is to discover common dependencies while they are still cheap to remove.

Verification Must Inject Shared Failures, Not Only Single Component Faults

Testing each redundant channel independently can still miss the failures that matter most. Verification should intentionally inject shared-resource faults: remove a power rail, corrupt a common clock, reset a network switch, overload shared compute, interrupt cooling, break a harness segment, corrupt a common state estimate and stall a shared software service. Observe which functions disappear together and whether containment behaves as designed. Test cascading paths as well. Short one zonal branch and verify that protection prevents bus collapse. Flood one communication domain and verify that safety traffic remains available. Corrupt one software partition and verify Non-interference. Force both redundant sensors into the same environmental saturation condition and determine whether diversity or plausibility checks catch the common-mode failure. Meaningful redundancy is proven by surviving the same failure—not by passing two separate channel tests.

Architecture Should Optimize the Failure Surface, Not Maximize Duplication

Adding duplicate hardware everywhere increases mass, cost, connectors, software states and potential common dependencies. The better objective is to minimize the failure surface: identify which failures are safety-critical or mission-critical, isolate those dependencies, and add redundancy or diversity where the consequence justifies it. Some functions need full independence; others can share resources because their combined loss is acceptable. This leads to a sharper semiconductor design question. Instead of asking how many processors or sensors the robot contains, ask which faults each domain can tolerate, which dependencies cross domain boundaries, and which independent mechanisms remain after a shared failure. The resulting architecture is usually more deliberate and often simpler than indiscriminate duplication.

Conclusion

Humanoid resilience is not created by counting backups. It is created by understanding dependencies. Common power, timing, communication, compute, cooling, connectors and software can turn two channels into one failure domain. The design response is to map those relationships, create containment boundaries, preserve independent supervision and maintain a capability model that changes when faults occur. Semiconductor architecture is central because power partitioning, diagnostics, memory protection, watchdogs, isolation, zonal switching and safety islands determine whether a fault remains local or propagates. Fault-tolerant control then uses the capability that architecture has successfully preserved. Meaningful redundancy therefore has a simple test: when the primary fails, does the backup survive the same cause? If not, the robot never had two independent paths in the first place.

Glossary Concepts

Dependent failure; Common-cause failure; Common-mode failure; Cascading failure; Fault-containment region; Fault containment; Independence; Non-interference; Functional diversity; Technological diversity; Shared dependency; Redundancy; Diagnostic coverage; Fault detection and isolation; Reconfiguration; Graceful degradation; Loss of effectiveness; Safety island; Protection domain; Single point of failure.

References

  1. International Electrotechnical Commission. IEC 61508-6:2010 Functional safety of electrical/electronic/programmable electronic safety-related systems — Part 6. 2010-04-30. https://webstore.iec.ch/en/publication/5520
  2. The 61508 Association. Standards Development — IEC 61508 Edition 3. 2026. https://61508.org/knowledge/standards-development/
  3. SAE International. Independence and Non-interference: Two Cardinal Concepts to Develop EE Architectures Hosting Safety-Critical Systems. 2009-04-20. https://doi.org/10.4271/2009-01-0739
  4. SAE International. Redundancy Killers. 1998-04-06. https://doi.org/10.4271/981204
  5. SAE International. Definition and Failure Management of Highly-Integrated, Safety-Critical Systems. 2008-04-14. https://doi.org/10.4271/2008-01-0102
  6. ISA Transactions. Fault tolerant adaptive control under actuator saturation for robot manipulators. 2026-01. https://doi.org/10.1016/j.isatra.2025.12.004
  7. Nonlinear Dynamics. A new fault tolerant strategy using adaptive time delay estimation for robot manipulators with actuator faults. 2025-01-06. https://doi.org/10.1007/s11071-024-10751-3
  8. Zhong et al.. FT-WBC: Learning Fault-Tolerant Whole-Body Control for Legged Loco-Manipulation. 2026-06-23. https://arxiv.org/abs/2606.24466

Glossary

Common-cause failure
Multiple failures resulting from one shared initiating cause or condition.
Reconfiguration
Deliberate adaptation of control, topology, task allocation or operating limits after a fault changes available capability.
Protection domain
A hardware or software boundary that restricts access, faults or interference between execution or resource regions.
Non-interference
Assurance that one software or hardware element cannot improperly affect another through shared resources or execution.
Loss of effectiveness
Partial actuator fault in which delivered control authority is reduced relative to the commanded input.
Independence
A property in which one function or protection mechanism is not defeated by the same failure that defeats another function.
Graceful degradation
Controlled reduction of capability while preserving verified safety and as much useful operation as remains trustworthy.
Functional diversity
Use of different functional principles or sensing approaches to reduce susceptibility to the same failure mechanism.
Fault-containment region
An architectural region designed so faults can be detected, isolated and prevented from propagating beyond defined boundaries.
Fault detection and isolation
Detection that an abnormal condition exists and identification of the affected element or fault domain.
Fault containment
Detection, isolation, protection and architectural separation used to limit the scope of a fault.
Diagnostic coverage
Fraction of relevant faults expected to be detected by implemented diagnostic mechanisms under defined assumptions.
Dependent failure
Failure behavior in which one failure is not independent of another.
Common-mode failure
Multiple channels failing in the same way because they share a vulnerability, mechanism, design or environment.
Cascading failure
A failure that directly or indirectly causes additional failures in other components or subsystems.
Redundancy
Provision of additional components or channels intended to preserve function after one element fails.
Safety island
Architecturally separated hardware or software domain dedicated to independent monitoring, protection or safety-related control.
Shared dependency
A resource, service, assumption or environmental condition required by multiple nominally separate functions.
Single point of failure
A single element whose failure alone can remove a required system function without a surviving mitigation path.
Technological diversity
Use of different implementation technologies or mechanisms to reduce common vulnerabilities.

Sources

  1. A new fault tolerant strategy using adaptive time delay estimation for robot manipulators with actuator faults · 2025-01-06 · Nonlinear Dynamics
    https://doi.org/10.1007/s11071-024-10751-3
  2. Definition and Failure Management of Highly-Integrated, Safety-Critical Systems · 2008-04-14 · SAE International
    https://doi.org/10.4271/2008-01-0102
  3. Fault tolerant adaptive control under actuator saturation for robot manipulators · 2026-01 · ISA Transactions
    https://doi.org/10.1016/j.isatra.2025.12.004
  4. FT-WBC: Learning Fault-Tolerant Whole-Body Control for Legged Loco-Manipulation · 2026-06-23 · Zhong et al.
    https://arxiv.org/abs/2606.24466
  5. IEC 61508-6:2010 Functional safety of electrical/electronic/programmable electronic safety-related systems — Part 6 · 2010-04-30 · International Electrotechnical Commission
    https://webstore.iec.ch/en/publication/5520
  6. Independence and Non-interference: Two Cardinal Concepts to Develop EE Architectures Hosting Safety-Critical Systems · 2009-04-20 · SAE International
    https://doi.org/10.4271/2009-01-0739
  7. Redundancy Killers · 1998-04-06 · SAE International
    https://doi.org/10.4271/981204
  8. Standards Development — IEC 61508 Edition 3 · 2026 · The 61508 Association
    https://61508.org/knowledge/standards-development/