Common Redundant Power Supply is the full form of CRPS, a family of modular server power-supply interfaces intended to make redundant, serviceable power building blocks more consistent across platforms. The word common refers to shared mechanical, electrical, signaling, and behavioral requirements within a defined specification—not to a universal replacement rule. The term now also appears as M-CRPS, Modular Hardware System Common Redundant Power Supply, in the Open Compute Project’s DC-MHS specifications. A safe interpretation therefore needs three identifiers: the CRPS generation or specification revision, the exact module, and the host platform that supports it.
Read the four words as separate engineering claims
Common establishes a shared target for interfaces and behavior. Redundant describes the architecture the module can participate in, not a promise that one installed unit protects a server. Power supply identifies the conversion module rather than the complete distribution subsystem. In the newer name, Modular Hardware System places that module inside a broader family of interchangeable infrastructure building blocks.
Separating the words prevents several common misreadings. A CRPS module may be used alone in a nonredundant configuration if the host supports that mode. Two modules may operate without source redundancy if both cords share one upstream failure domain. A module can conform to a physical family yet remain unsuitable for a host because its electrical or management contract differs. “Common” narrows integration variation; “redundant” still depends on system design.
Why the server industry needed a common module concept
Proprietary server supplies make a chassis dependent on one mechanical envelope, connector location, latch, airflow direction, signal scheme, and service method. Every new platform can then require a new PSU and a new qualification effort. A common modular target allows suppliers and server designers to work around a more stable boundary. It can simplify PSU-bay design, spare planning, automated insertion, PDB development, and multi-vendor sourcing where the relevant implementation supports it.
The benefit is not that every detail disappears. It is that key details become deliberate specification items rather than undocumented consequences of one chassis. A module designer knows which envelope, mating region, signals, behaviors, and environmental expectations must be addressed. A platform designer can build a repeatable bay and power path. Procurement can compare offers against a shared contract instead of judging only external resemblance.
This explains why the phrase belongs primarily to server and data-center infrastructure. Desktop ATX supplies standardize a different packaging and wiring relationship, while rack-scale power shelves centralize conversion at another layer. CRPS targets a compact, removable internal module that mates directly to a server-side interface.
Legacy CRPS and M-CRPS should not be collapsed into one label
CRPS terminology has evolved. Earlier implementations are often described as legacy CRPS. The Open Compute Project’s DC-MHS work now publishes the M-CRPS Base Specification for power-supply solutions and signaling expected in DC-MHS-compatible systems. OCP’s specification library is versioned and continues to change; the project page lists the current base specification and design packages rather than treating “M-CRPS” as a frozen idea.
The added M is meaningful. DC-MHS aims to provide consistent interfaces and form factors among modular data-center and enterprise building blocks. M-CRPS participates alongside platform-infrastructure, host-module, and other related specifications. This makes the PSU interface part of a coordinated system architecture rather than a standalone shape.
Legacy and M-CRPS relationships must be evaluated from the exact revisions. Some newer specifications discuss backward compatibility while using mechanical keying to prevent unsupported forward insertion, and electrical differences can matter even where a physical modification might make parts mate. The practical lesson is simple: never remove the revision and compatibility direction from an equivalence claim.
“Common” is a stack of contracts
Interoperability is strongest when several layers align at once. Treating only the enclosure as common ignores most of the system relationship.
| Contract layer | What it governs | What can fail when it differs |
|---|---|---|
| Mechanical | Envelope, guides, keying, latch, insertion, connector position | No fit, partial mate, poor retention, blocked service path |
| Main power | Output rail, contacts, sensing, sharing, isolation behavior | Incorrect output, unstable sharing, heating, bus collapse |
| Power states | Standby, enable, power-good, startup and shutdown behavior | Failed boot, unexpected shutdown, sequencing fault |
| Management | Addressing, PMBus commands, telemetry, status, identification | Missing data, false alarms, unsupported firmware behavior |
| Thermal | Airflow direction, impedance, fan control, derating | Hot spots, noise, reduced available power, thermal trip |
| Platform policy | Approved models, mixing rules, redundancy modes, firmware | Unsupported configuration despite apparent interface match |
A candidate must pass through the whole stack. The CRPS specification reference explains individual datasheet fields in depth; the key terminology point here is that those fields collectively define the scope of “common.” No single dimension, wattage, or connector photograph substitutes for that contract.
What redundancy means after a module is inserted
A CRPS module is designed to participate in redundant power, but redundancy exists only when the platform has independent usable paths and enough surviving capacity. In a common 1+1 server arrangement, either supported module must be able to carry the allowed server load after its partner is removed or isolated. The PDB or equivalent host interface joins the outputs, supports sharing or standby policy, and prevents one failing path from disabling the healthy path.
The installed state also depends on input feeds. Two modules connected to separate rack PDUs can protect against more upstream events than two modules connected to the same receptacle or power strip, provided the downstream architecture preserves continuity. The word CRPS does not describe that rack topology. Nor does it prove hot replacement under load; the module, connector sequence, PDB, controls, cooling, and service procedure must support the event together.
This is why product descriptions sometimes list 1+0, 1+1, and combined-capacity modes for the same CRPS hardware. The module family enables several system arrangements. The host’s approved configuration determines which arrangement is active and what failure it can tolerate.
Standardized does not mean identical
Conforming supplies can differ in output capacity, input range, efficiency level, acoustic behavior, firmware, telemetry, environmental limits, airflow, depth variants, and optional functions. Those differences are valuable: a common interface can support several platform power envelopes without forcing every module to be the same product. They also create a boundary around substitution.
A higher-rated module is not automatically a valid upgrade. The host may restrict recognized identities, lack the input or airflow required for the higher output, use a different keyed generation, or apply mixing rules. A physically smaller-depth variant may alter airflow or connector reach. Two modules from different suppliers may individually meet a broad standard while not being approved as a mixed pair by the server vendor.
Standards and platform support answer different questions. The standard describes the shared interface target. The module datasheet describes one implementation. The platform compatibility list and firmware describe supported combinations. All three sources are needed when interchangeability matters.
How to name the requirement without ambiguity
A procurement line that says only “common redundant power supply” leaves the supplier to infer generation, wattage, input, efficiency, airflow, management, and host. A useful requirement starts with the platform and then names the interface: exact server or PDB, governing CRPS or M-CRPS revision, approved module identities, required input and usable output under deployed conditions, airflow direction, redundancy mode, PMBus or discrete-signal expectations, and any mixing restriction.
For a spare, identify the installed module and host revision rather than searching by wattage alone. For a new custom server, identify the PDB and BMC contracts at the same time as the module family. For a multi-source design, define whether suppliers must work only as homogeneous pairs or also in mixed operation, then obtain explicit support evidence for that mode.
This terminology discipline also helps distributors. “CRPS compatible” should state the compatible interface revision and named systems or assemblies. “M-CRPS compliant” should cite the relevant specification version and compliance scope. “Redundant” should state the supported topology and surviving capacity. Each phrase then communicates a testable boundary.
Where M-CRPS fits in current modular server design
M-CRPS is part of a broader move toward modular platform infrastructure. OCP’s DC-MHS family coordinates the power supply with host and platform connectivity specifications so mechanical and electrical building blocks can be reused more systematically. This matters for enterprise, hyperscale, edge, and high-performance systems whose chassis configurations change faster than a completely proprietary power ecosystem can comfortably follow.
The architecture does not eliminate customization. A server can still require a specific PDB layout, cable topology, cooling path, management policy, or approved supply population. Modularity defines clearer seams between those choices. It gives the industry a common place to describe them and makes revision control more important, not less.
The durable meaning of CRPS
Common Redundant Power Supply means a modular server PSU built around a shared, versioned interface so it can participate in a redundant and serviceable host architecture. Its durable value is the contract between module and platform: mechanics, power, control, management, cooling, and operating behavior become defined interfaces. It also gives designers a stable vocabulary for changes that would otherwise be hidden inside a proprietary supply bay.
The acronym should therefore open a compatibility discussion, not end one. Add the specification revision, exact module, supported PDB, and host platform, and “common” becomes a useful engineering claim instead of an assumption of universal interchangeability. That fuller identity remains meaningful when a module is purchased as a production part, qualified as an alternate source, or stocked as a field spare years later.
