Inquiry Now

ATS Rack PDUs for Redundant Equipment Power · Technical Explainer

ATS Rack PDU Source Priority: Testing Failure and Return Behavior

Gouache server-rack corridor with separate preference and active-source concept panels

Published October 22, 2026

Quick answer

An ATS rack PDU acceptance plan should check the selected source, the validity of both inputs and the documented behavior when a source fails or returns. Source preference is not the same as source validity, and transfer to a backup input is not the same event as retransfer after recovery.

Define the expected outcome for each state using the exact model's instructions and configuration. Record active-source indication, applicable alarms and the supported event evidence separately from the load-continuity result. Do not assume a network card, configurable preference or a particular retransfer delay exists on every ATS rack PDU.

This guide supplies an acceptance-plan structure, not live failure-injection steps. A qualified team must approve the test method, equipment state, interruption risk and restoration procedure before testing a populated rack.

Separate source preference from source availability

A preferred source describes a selection policy when the relevant sources are usable. Whether an input is usable depends on the exact device's documented conditions. A source can be physically connected while the device treats it as unavailable or unacceptable.

Review concept Required definition Do not confuse it with
Preferred source Documented selection policy or setting The source presently carrying the load
Valid source Exact permitted input conditions A connector being inserted
Active source Current supply path and indication Every source being healthy
Transfer behavior Response to a relevant source change Guaranteed equipment continuity
Retransfer behavior Policy after source recovery Immediate return in every model
Management evidence Supported indication, alarm or event field A standard network function on all units

Record the exact ATS reference and firmware or management configuration when applicable. The source labels on the device, drawings and records should refer to the same physical inputs. A correct indication with an incorrect input label can still mislead an operator during a later incident.

Also identify the attached equipment and acceptance objective. Maintaining a powered outlet and preserving a particular application's operation are different results. The relevant load requirements determine what evidence is needed in addition to the ATS indication.

Use the exact source-state logic

Schneider Electric's official AP44xx manual describes an ATS that evaluates source conditions, distinguishes an unused-source problem from a problem on the active source and applies a preferred-source return policy. Those are documented behaviors for the identified APC models, not operating specifications for LA-PD. No APC timing or voltage limit is assigned to a RITOKS product here. Schneider Electric, Rack ATS AP44xx user manual, 990-5844-001.

Use that distinction when reading the selected product's own instruction. Does losing the unused source only change redundancy status? What happens when the active source is disqualified? What conditions permit a recovered source to carry the load again? These should be separate acceptance questions.

A label such as “automatic transfer” does not provide the answers. Request the applicable state description or logic documentation and retain the conditions attached to it. If source priority is fixed rather than configurable, describe it as fixed. If the evidence does not establish preference or retransfer behavior, leave those functions unresolved.

What the LA-PD family page establishes

The RITOKS LA-PD dual-input ATS rack PDU page documents dual input with automatic source transfer for single-cord rack equipment and LED indication of the active source. Its network management card is an optional upgrade, not a standard function of every unit.

The public page does not publish a transfer time, complete source-validity thresholds or a model-specific preferred-source/retransfer policy. These items need exact-model documentation before the acceptance plan can specify numerical or behavioral criteria.

For an enquiry, provide the selected LA-PD reference, both source arrangements, outlet configuration, attached-equipment requirements and management option. Request the source-state logic, relevant limits and indication definitions. Do not copy an AP44xx manual into the LA-PD acceptance file as if it describes the supplied hardware.

Keep the commercial family distinct from other transfer architectures. The published LA-PD family is an ATS rack PDU; this article does not relabel it as an STS or import switching claims from an STS product. Architecture-specific evidence matters when evaluating continuity requirements.

Build cases for failure and return separately

The plan should distinguish a failed active source from a failed inactive source. It should also distinguish restoring the preferred source from restoring another source. The same initial input labels do not guarantee the same response after every event.

Planned state or transition Expected outcome to obtain from the exact instruction Evidence to record
Both inputs acceptable Selection policy and active input Configuration and active-source indication
Inactive input becomes unacceptable Alarm/redundancy behavior Input status and supported indication
Active input becomes unacceptable Permitted transfer behavior Before/after source state and load result
Preferred input becomes acceptable again Retransfer policy and relevant conditions Recovery state, event order and active input
Other input returns Applicable selection behavior Both source states and active input
Both inputs unacceptable Documented status and recovery behavior Applicable indication and load state
Management unavailable Functions independent of the management option Locally available evidence and limitations

This is a planning matrix, not a procedure for disconnecting live rack supplies. The authorized method should identify how each condition is represented safely and which cases are appropriate for the actual installation. An unapproved both-source interruption should not be created merely to complete a row.

Some cases may require a controlled laboratory or commissioning environment rather than a populated production rack. Record a case as not tested when that is the actual result, with the reason and responsible disposition. Do not report a complete state-matrix pass when only one event was observed.

Separate review questions for inactive input loss, active input loss and input recovery
These are acceptance-plan questions, not instructions to interrupt live rack supplies.

Keep load continuity separate from indication

An active-source LED can support identification of the selected input, but it does not by itself establish the interruption experienced by the attached equipment. The acceptance plan should specify what continuity evidence the project requires and how it is obtained using an approved method.

The attached load's requirements matter. A successful source change with one demonstration device does not establish compatibility with every server, network appliance or operating condition. Record the load configuration used for verification and avoid expanding the result beyond that scope.

Likewise, an application remaining available is evidence of that observed outcome, not a precise transfer-time measurement. If the project requires a numerical timing criterion, the exact specification and suitable qualified verification method must support it. The guide supplies no universal transfer-time limit.

Separate device indication, management reporting and application observations in the result. This makes it possible to identify whether a deviation concerns source behavior, feedback interpretation or the load's response rather than combine everything into “ATS worked.”

Separate evidence markers for device active-source indication and observed load outcome
Record both evidence scopes; an indication alone does not establish load continuity or a numerical transfer time.

Confirm the management option before asking for logs

A network interface can make event collection convenient, but it must actually be part of the selected configuration. Ask which firmware, protocol and event fields are supported, and what their timestamps represent. A management option should not be inferred from a related smart PDU family.

For a unit without a documented event log, define the available local evidence in the approved acceptance plan. Do not invent log names, timestamp resolution or alarm behavior. The absence of a particular remote field also does not automatically prove the power-transfer function has failed.

If a network card is supplied, distinguish management restart or communication loss from a source-transfer event. The exact manufacturer instructions determine whether any command affects the power path. Do not use a controller-reset command as an improvised transfer test based on another product's FAQ.

Keep access permissions and configuration records with the acceptance evidence where relevant. A displayed preference setting should be connected to the actual delivered configuration rather than a screenshot from a different unit or firmware.

Use a conditional acceptance example

Consider a fictional rack project requiring a preferred input and a reviewed return-to-source policy. The quotation identifies an LA-PD model and optional management, but the acceptance file only shows that an LED changed after one input event.

That observation is useful but incomplete. The reviewer still needs the exact preference/retransfer description, the relevant source conditions and the agreed load-continuity criterion. Optional management also needs confirmation before a log-based acceptance requirement can be assigned.

If the manufacturer provides the required logic and the approved test evidence matches it, the applicable cases can be accepted. If a policy or continuity condition remains unsupported, record that limitation rather than declare every failure-and-return state verified. This example describes no actual RITOKS installation and recommends no live interruption method.

Preserve the configuration behind the result

Retain the exact model, source labels, management option and applicable settings alongside the state-matrix results. A later configuration change can alter the basis of the acceptance record even when the physical rack wiring remains the same.

When replacing the ATS rack PDU, compare the old and new source-state policies rather than matching only plug type and outlet count. Identify any changed preference, recovery behavior or indication meaning before reuse of the old acceptance plan.

The final report should identify verified cases, excluded cases and open requirements. Attach deviations with the responsible disposition. This is more useful to operations than a broad pass statement that conceals which conditions were never evaluated.

FAQ

Is the preferred source always the active source?

Not necessarily. The exact validity and selection logic determine the active path. Record source preference, source status and active source separately.

Does LA-PD have a published universal retransfer delay?

The public family page does not establish one. Obtain the exact selected model's logic and conditions before assigning a criterion.

Is a network card standard on every LA-PD unit?

No. The published page describes it as an optional upgrade. Confirm the delivered option before requiring remote logs or network functions.

Does one successful transfer prove every return case?

No. Failure of an active or inactive input and recovery of a preferred or other source are separate states. Accept only the cases supported by exact instructions and actual approved evidence.

References

Scroll to Top