Concurrent maintainability in AI data centres is not a service-speed claim: a module replacement demonstrated in less than 3 minutes, with the system live under load and no transfer to shared bypass, is the visible output of three architectural properties that either exist in the design or do not: a self-contained fault domain per module, a per-module static bypass, and distributed control logic with no shared decision point. When any one of those properties is missing, the service action stops being local and becomes a system-level event, and in an AI hall running GPU training jobs continuously at 40–132 kW+ per rack, a system-level event during maintenance is the failure mode the UPS was procured to prevent. The engineering question is therefore not how fast the service truck arrives, but whether the architecture was designed so that module replacement time is a fixed physical constant and whether the specification requires proof of that under live load.
Where the Real Specification Gap Lives
- Hot-swap label versus bypass-free replacement in practice
- GPU density removes the scheduled maintenance window
- Three properties that make replacement time bounded
- MTTR as a design number, not a service SLA
- Overload headroom keeps surviving modules off bypass
- Density determines whether redundancy fits the room
The Scheduled Window No Longer Exists
A rack drawing 40–132 kW+ under a training job does not offer a nightly idle window. Legacy service schedules assumed the operator could pick a low-utilisation hour, coordinate a controlled transfer, and complete the work before the load returned. A diversity assumption underwritten by CPU workloads that ramped gently and predictably. GPU-dense halls remove that assumption entirely. StratusPower™ is engineered for the unpredictable GPU load spikes typical of HPC and AI workloads, in contrast to the predictable steady load of CPU-based cloud computing.
The operational meaning is that “safe service moment” is no longer a scheduling decision, it is a continuous architectural property the UPS either possesses or lacks. Once framed that way, the specification target moves from service-window coordination to equipment capability under live load. If the UPS cannot be serviced under load without affecting redundancy state, the site has no service moment at all.
What “Hot-Swappable” Actually Tells You
Consider how a GPU cluster handles a failed card. Pulling a faulty GPU from a live training job does not drain the job queue. The workload keeps running on healthy nodes while the faulty card is removed. A vendor whose service model requires bypass is asking the operator to pause the whole cluster to replace one part. That is the architectural distinction the datasheet label does not surface.
A UPS that routes module service through a shared static bypass exposes the entire load to raw mains during the transfer, even when the datasheet says hot-swappable. For a GPU cluster this is operationally equivalent to an unplanned mains event: the voltage and frequency excursions the utility can present during that window are exactly the excursions the double-conversion topology exists to isolate. The service action itself becomes the risk the UPS was procured to prevent.
The mechanism that removes bypass from the service path is a per-module static switch and a per-module parallel isolator that physically separate the module from the frame. A module can be replaced in a live system without transferring the load to bypass and raw mains, and any module added to a system can be fully isolated and tested within the running frame before it accepts any load. The remaining modules never see a shared switching event, and the load never leaves inverter protection. That is what makes the datasheet label operationally true rather than nominally true and it is why the specification must name the mechanism, not only the label.
Hot-swappable describes what can be removed, not what stays protected while it happens. The Power Resilience Guide names the mechanism that keeps the load on inverter during the swap.
Concurrent Maintainability in AI Data Centres: Three Properties That Bound Replacement Time
Per-module isolation on its own is not sufficient. A live module replacement becomes bounded and repeatable only when three properties hold simultaneously. Each closes a different failure mode; together they make the service duration a physical constant of the architecture rather than a variable that depends on operator skill or system state on the day.
Self-contained fault domain. Pulling one module should not trigger a control-state renegotiation, a bus-level switching event, or fault propagation into an adjacent module. That propagation occurs in topologies where modules share a control board, a bypass bus, or a parallel-arbitration point because the physical boundary of one module and the electrical boundary of the fault domain are not the same.
DARA™ (Distributed Active Redundant Architecture) closes that gap by making each UPS module independent, redundant and interconnected. A complete UPS in its own right with its own computing power, three independent power converters, a static bypass, and the hardware needed to safely isolate a fault without impacting the load.
Because the fault domain has a fixed physical boundary, the service action has a fixed physical scope and a fixed scope produces a fixed duration. The same property allows a replacement module to be fully isolated and tested within the running frame before accepting any load, so a fault in a replacement unit is identified before it can propagate.
Distributed control logic. In master-slave modular UPS designs, the master’s state during a service event introduces variables the technician cannot see or control: arbitration timing, handover logic, and re-election behaviour all sit in the critical path of the replacement.
DDM™ (Distributed Decision Making) removes that variable by removing the master entirely: DDM™ enables distributed, collaborative, majority decision-making among all modules and removes the single point of failure typically associated with master-slave modular UPS designs.
Each module decides locally, so the removal of one module does not require the remaining modules to reconverge around a new coordinator. That turns a job that requires less than 3 minutes into a repeatable duration under commissioning conditions, not a best-case figure.
MTTR Is a Design Number, Not a Contract Term
When the three properties hold and replacement time becomes a fixed physical duration, repair time moves from the service contract into the architecture column of the availability equation. Because availability responds more sensitively to reductions in repair time than to further MTBF gains once MTBF is already high, the availability figure becomes a design output the engineer can specify from the equipment schedule, not a number the vendor asserts on the cover page.
The failure state here is subtle: the availability calculation the design team ran assumed minutes to restore module-level redundancy, and the accepted equipment delivered hours because the specification named a service-response SLA and not an architectural repair duration.
A contracted service response begins after fault detection, dispatch, and site access. A bounded architectural repair duration is a fixed physical duration that begins the moment the technician reaches the module. The gap between the two can be hours, and the availability model does not reflect that until the first real service event.
Modular, plug-and-play internal components reduce time-to-repair and simplify routine maintenance. That is a statement about architecture, not about response time. A design aligned with supporting up to 9-nines availability (99.9999999%) with no single point of failure depends on concurrent maintainability in AI data centres and live-load UPS module replacement delivered through safe hot-swap capability and isolated fault domains, aligned with Uptime Institute Tier III/IV objectives on the UPS infrastructure within a Tier-certifiable facility design.
The correction is to name the bounded figure and its conditions in the equipment schedule: system live under load, no transfer to static bypass, replacement module isolated and tested in the running frame before accepting load, redundancy state preserved; so the number the availability model consumed and the number the accepted equipment delivers are the same number.
An availability model built on a service-response SLA and one built on a bounded architectural repair duration can differ by hours. The Power Resilience Guide shows how to tell which one the equipment actually delivers.
Overload Headroom and Density Are Maintainability Numbers
Bounded repair duration only translates into real availability when the maintainable configuration is physically deployable in the hall as designed. During a module replacement, N+1 headroom is reduced to N and that is precisely the moment the GPU cluster is most likely to present a training-step transient. A frame with no continuous margin above the working point has to protect itself when the transient arrives, and its protection response is the bypass transfer the service action was meant to avoid.
StratusPower™ modules provide 24% extra safety power, so each module carries continuous headroom above its nominal working point.[I1] Overload rating belongs in the maintainability section of the specification, not only in the load-handling section because it is what keeps the surviving modules in double-conversion during the sensitive service window.
The second physical constraint is density. A density shortfall forces a layout compromise: reduced redundancy count, split frames across rooms, or an N configuration where the design called for N+1, and that compromise removes concurrent maintainability in practice even if the equipment supports it in principle.
StratusPower™ delivers a 1 MW/m² footprint, supporting the footprint requirements of high-density AI hall configurations. The redundancy count that produces a bounded repair duration has to fit the room. If it does not, the availability model was never valid for the built site.
Specifying Maintainability So It Survives Procurement
Concurrent maintainability in AI data centres becomes a verified commissioning outcome, rather than a phrase in a datasheet, when the tender specification names the three architectural properties, the overload-headroom and density thresholds, and the bypass-transfer prohibition as pass/fail criteria, and requires a live-load module swap with redundancy state preserved as the acceptance condition at FAT, SAT, and integrated systems testing.
The tender must state, as pass/fail criteria: each module shall present a self-contained fault domain with its own converters, control, and static bypass; module replacement shall not transfer the protected load to a shared bypass or to raw mains; the surviving modules shall remain in double-conversion throughout the service action; the frame shall retain its declared redundancy state during the swap; and the module-replacement duration shall be demonstrated under load. Without that language, a vendor can satisfy the specification with a product that transfers to bypass during service, because no contractual criterion distinguishes the two behaviours.
The three commissioning stages form a sequential verification chain. FAT confirms module-level behaviour and per-module isolation in the factory; SAT confirms frame-level behaviour and the absence of shared bypass transfer during a swap on site; IST confirms the same behaviour under the actual load profile of the hall, with the compute team’s transient signature present.
In a running frame, service modules can be left on site for a local technician, redundancy is maintained during a swap, and any module being added to a system is fully isolated and tested before it accepts any load. A factory demo under partial load is not a substitute for live-load IST under GPU-cluster conditions. The specification should require both.
FAQ
Q: Is a live module replacement demonstrated in less than 3 minutes a service commitment or a technical specification?
A: It is best read as an architectural output: the visible consequence of self-contained fault domains, per-module static bypass, and distributed control; rather than as a service-speed promise. That is why it can be demonstrated with the system live under load, with no transfer to static bypass, and with the replacement module isolated and tested in the running frame before accepting load, and why it is repeatable under commissioning conditions.
Q: Does ‘hot-swappable’ mean the load stays protected during a module swap?
A: Not on its own. Hot-swappable typically means a module can be physically removed while the frame is energised. It does not, on its own, mean that the protected load remains on inverter, that the system avoids transfer to a shared bypass, or that the redundancy state is preserved. Those behaviours must be specified explicitly.
Q: Why does inverter overload headroom matter during a module replacement in an AI hall?
A: GPU clusters produce correlated transient swings. During a swap, the surviving modules carry the full load. Without continuous overload headroom above the working point, a transient can push the frame past its rated limit and force a bypass transfer, the exact failure mode concurrent maintainability is meant to prevent.
The specification has a clear trade-off to resolve: a bounded module-replacement duration is only as real as the commissioning test that verified it. Whether the per-module bypass path, the fault domain boundary, and the distributed control logic were designed to contain the service action, or simply to pass a capacity test, is a question the datasheet cannot answer.
That answer lives in the single-line drawing, the control-topology diagram, and the IST protocol. Whether those documents exist, and what they show, is what the next conversation needs to establish.
Download the AI Data Centre Power Resilience Guide to see how fault-domain separation and distributed control produce concurrent maintainability and a bounded module-replacement duration on live GPU loads.
A hot-swap claim and a bypass-free, redundancy-preserved replacement are two different pass/fail lines. The Power Resilience Guide lays out the specification language that tells them apart.
If you’re evaluating a live AI deployment, request an engineering review (ADR). Engineering-led · No sales pitch. Request an engineering review
References
- Live UPS module replacement in 2 minutes 35 seconds — demonstration page — Centiel
- Modular UPS Systems — architectural description — Centiel
- StratusPower 400V technical datasheet (2025) — Centiel
- Brochure — StratusPower Modular UPS 2026 — Centiel
- Brochure — StratusPower Modular UPS 2026 — Centiel
- Brochure — StratusPower Modular UPS 2026 — Centiel
- Product Page — StratusPower Modular UPS — Centiel
- Product Page — CumulusPower 480V UPS — Centiel
- Case Study — Musgrove Hospital UPS Protection — Centiel
- Brochure — CumulusPower 480V UPS 2026 — Centiel
- Solution Page — Colocation Data Centers — Centiel
- Case Study — Modular UPS Project 2021-002 — Centiel
This article is based primarily on Centiel’s own engineering documentation, design data and field experience in AI Data Centres / GPU Clusters / High-Density Compute Environments power infrastructure, supported by the external sources listed above.