Railyard

Power & thermal

See what's full before you order a rail.

Organisation power overview

Open Power at the organisation level for known modelled demand, rack-budget coverage, PDU and connection counts, and planning gaps across the estate. Racks needing attention appear first; search the list to open a rack's feeds and outlets. Unknown device demand is excluded from the subtotal, and a rack without a budget is shown as unbudgeted rather than as a percentage of capacity.

Below the racks, the Connections table lists every device inlet → PDU outlet connection in scope, with its rack, status and device demand, plus a row for each powered inlet that nothing feeds. Filter by Connected, Unfed or Needs review, or type to search; click a row to open its rack with the device selected, or the PDU name to select the PDU. ↓ CSV downloads the filtered rows. In a rack, open Connections table at the foot of the workspace for that rack's own list.

Feeding devices from PDUs

Switch to Power to keep the full rack on the left while inspecting a device's power connections or a PDU's outlets. On smaller screens, Show rack opens a touch-friendly device list. Choose Connect beside a device inlet, then click a PDU in the rack. Or start with Connect device beside a free PDU outlet and click the device. A single free socket connects immediately; when several are free, a small picker asks which one to use. Esc cancels the pending connection. Each completed connection is one undo step; adding a custom inlet is a separate undoable edit.

Equipment that takes no power, such as a carrier demarcation or an unpowered panel, needs no feed when it declares no power inlets and a draw of 0 W. The device's own inlets and draw count as well as its device type's: a device's own empty inlet list or 0 W draw overrides its type's, and a device without a type counts only when it declares both itself, its own empty inlet list and 0 W. The design review then does not ask for a connection; if the device is connected, it does not ask for a second feed either. The power schedule has no unfed row for it. A blank draw, or a device type missing from the project, means unknown rather than none, so such a device is still flagged until you fill it in.

To wire a whole rack at once, choose Auto-connect power… on the rack power summary. It connects only free inlets to free outlets on the rack’s own PDUs, alternating each device’s inlets across them (PSU A to PDU-A, PSU B to PDU-B) and balancing single-inlet devices, with outlets taken in U order from U1. With strips on both rails, the left and right strips take turns, so PDU-A1 and PDU-A2 on the left with PDU-B1 and PDU-B2 on the right put PSU A on A1 and PSU B on B1. A device never gets two feeds from one rail: once one rail’s strips are full, its other inlet waits rather than taking a second strip on the same side. The preview shows each PDU’s resulting load against its capacity, the rack budget, and any inlets that can’t be placed because outlets ran out. Applying it is one undo step. When you connect an inlet by hand, a strip on the same rail as the device’s other feed is marked Same rail; the other rail’s strips are suggested.

Device types supply the default power inlets (PSUs), shown whether connected or free. Use Add custom inlet for a device-specific input; it does not change the shared template. Types without inlet definitions do not get guessed PSU counts. Connections retain stable inlet identities when names change. Existing connections without an inlet label stay visible as unassigned and can be repaired. Occupied outlets cannot be silently replaced, and conflicting or out-of-range connections remain visible for repair or disconnection. Each connected inlet shows its complete modelled route directly. To change a valid route, disconnect it and reconnect through the rack; invalid connections retain a focused repair action.

Two PDUs do not by themselves prove independent A/B supplies. Upstream source independence and actual equipment failover behaviour are not modelled. Unconnected devices and single-PDU connections in racks that model power are highlighted by the design review so gaps remain visible after the last connection is removed.

0U side PDUs

Vertical 0U PDUs mount in the side channels rather than consuming rack units. Side-mounting is a position, not a role: a side-mounted device is a PDU when its device type has outlets or its role is PDU. A PDU-role strip whose type models no outlets is planned as a generic 24-outlet strip you can feed from. Other side-mounted equipment, such as a vertical cable manager, gets no outlets.

In the Power elevation, these strips sit on their recorded left or right side of the rack. Select a strip to inspect its outlets, or select a device to highlight its recorded local feeds. Occupied sockets stay filled, free sockets stay outlined, and blue numbered markers identify the selected device's feeds. An amber exclamation mark flags an occupied outlet whose connection needs review. If occupied sockets cannot all fit, a filled count summarises them; inspect the strip for the full outlet list. Multiple strips can share a side; rack-mounted PDUs stay in their U positions. Outlet spacing and connection lines are schematic, not measured cable routes, and left/right placement does not imply independent A/B feeds.

Load, heat and weight roll-ups

These are planning estimates, not live measurements:

  • Power (kW) — rack demand counts each device once. Estimated normal PDU load assumes equal sharing across the device's connected PDUs. A PDU's failover load is the most it carries if any one PDU fails, or one rail of a rack with PDUs on both rails (the rails are taken as the A/B supplies): each affected device's demand is shared equally across the PDUs it still has. A device on two PDUs moves in full to the survivor. A device on four PDUs, two on each rail, shares it among three when one PDU fails and between the other rail's two when a rail fails, so the rail failure is the figure shown. A rack-mounted PDU's supply is not modelled, so it is taken as possibly on either rail: each rail is also tried failing together with the rack's rack-mounted PDUs. Two inlets on the same PDU count as one supply. The power report keeps the full connected peak (every connected device in full on each PDU) beside the failover peak and the failure that gives it. Neither figure verifies real load sharing or failover. Unknown draw and invalid connections are shown separately, not treated as a healthy zero. A device's explicit 0 W override is retained.
  • Planned and peak draw — every device has two draws. Planned is the device's own expected draw, else its type's typical draw: the budget and failover figures above use it, as do the bill and cooling. Peak is the type's vendor maximum, else a ceiling of PSUs required × PSU rating (an upper bound, labelled as such), else unknown; a device's own expected draw never changes it. Rack, PDU, input circuit and bank breaker loads are also checked at peak, in normal operation and when one PDU (or one rail of a rack with PDUs on both rails) fails. Each device keeps only its PSUs on the surviving PDUs and shares its draw across them; a device without a peak figure counts at its planned draw on PDUs and is left out of rack peaks, never counted as 0 W. A PDU's input circuit is its voltage × current, × 3 for a 3-phase PDU (whose voltage is line to neutral). A bank's limit is its breaker × the voltage across its outlets: the input voltage on a single-phase PDU or a 230 V 3-phase PDU (line to neutral); on a 120/208 V 3-phase PDU, 208 V line to line for IEC outlets and 120 V line to neutral for NEMA 5-20R-style outlets. A bank whose wiring can't be told (unknown or mixed outlet types) is left unchecked. The power schedule, the power report and the build pack show both draws.
  • Heat (kW and BTU/hr) — for IT gear essentially all drawn power becomes heat, so Railyard derives the thermal load (watts × 3.412) that your cooling is sized against, from planned draw and, beside it, from peak draw. The peak heat is shown in full only when every device has a peak figure; otherwise it reads “at least” the known part. A device without a figure is left out and counted, never taken as 0 W. It's shown per device, in the rack inspector, in each space's summary (row, hall or estate), in the build pack and through MCP, and rolled up with power draw and load on the data-centre and estate dashboards.
  • Weight (kg) — each device's catalogue weight sums up per rack, and per row, hall or other space, against the rack's weight limit (or its rack type's load rating). A device whose type has no weight is counted as unknown, never as 0 kg: the rack shows “at least” its known weight and how many devices have none, on the rack's header, in the inspector and in the build pack.

A PDU over capacity, a rack over its power budget, or a rack over its weight limit each surface as an inline design finding — with a “near capacity” warning before you tip over the line.