Pearl · CR-E-028

Source-Transfer Control-State Validation

Prove that source-transfer controls block every prohibited source combination and complete every required transfer before UPS autonomy becomes consequential.

Construction terms explained

UPS:: uninterruptible power supply
IST:: integrated systems testing
MOP:: method of procedure

Controls and OT Critical power UPS and batteries Generators

What to check before the work begins

Before this source-transfer sequence is released, has the project proved every allowed and prohibited breaker/source state, every required transition, and the response to credible failed or contradictory status inputs within the available UPS bridge time?

Approve a complete cause-and-effect and source-state transition matrix
Verify every breaker and source status input point-to-point against the controlled logic version
Prove positive close denial for every prohibited source combination
Verify dead-bus, source-available, voltage, frequency, phase-sequence, synchronism, and other required permissives
Challenge credible failed, stale, unavailable, or contradictory status inputs using a safe approved method
Execute staged energized and representative loaded transfers through required states
Measure end-to-end transfer time against the approved UPS bridge window and repeat after every correction

Use in the project example

What the sources describe

In a deidentified data-center commissioning case published by Dranetz, PLC sequencing allowed a 3,000 A generator bus and a 4,000 A utility bus to be connected while out of phase, producing currents beyond the monitored CT range, breaker trips, damage, and smoke odor. In a separate February 7, 2026 Microsoft Azure incident, an onsite transformer failure removed utility power; generators started, but a cascading control-system failure prevented automated load transfer until UPS batteries depleted.

Evidence to confirm

Approved source-state and transition matrix
controls integrator · Before the relevant work begins
Every permissible, prohibited, initiating, intermediate, fail, and completed state is defined with the expected controller and breaker response.
Controlled PLC/controller version and checksum
controls integrator · Before the relevant work begins
The tested version matches the released field version and every later change is traceable.
Point-to-point source and breaker status I/O results
controls integrator · Before the relevant work begins
Field state, controller input, displayed state, and command path agree for every consequential point.
Recorded close-denial proof for prohibited combinations
controls integrator · Before the relevant work begins
Independent interlocks and required synchronism supervision block every prohibited state under the approved fault cases.
Synchronized source, breaker, controller, UPS, voltage, current, and timing records
controls integrator · Before the relevant work begins
Each required transition completes without prohibited closure, unexplained operation, or exhaustion of the approved bridge window.
Closed anomaly and successful repeat-test record
controls integrator · Before the relevant work begins
Every failed or unexpected test is causally dispositioned and the governing sequence is repeated successfully after correction.

Conditions to resolve before proceeding

Any prohibited source state can issue or complete a close command
A required transfer cannot progress to load accepted
Breaker or source feedback disagrees with field state
The controlled PLC version, I/O mapping, or cause-and-effect matrix cannot be reconciled
Transfer completion exceeds the approved bridge-time allowance
An unexplained trip, close, lockout, overload, or manual intervention occurs

When this applies

Factory acceptance testing and submittals
Integrated systems testing
Functional performance testing
Installation turnover

Assess each lesson against your project, equipment, and local requirements with the people responsible for the work.

Limitations and context

Applies when: A programmable controller or equivalent logic directs consequential source changes
Applies when: Multiple source states or breaker combinations are possible
Applies when: UPS autonomy or another time-limited bridge depends on transfer completion
Outside scope: Purely manual systems whose source combinations are physically prevented and whose applicability has been confirmed separately
Outside scope: Systems with no consequential automatic source transition
Outside scope: Configurations the commissioning authority determines are not comparable
Customer impact times span service recovery and are not a direct measure of electrical transfer duration.
The Dranetz case does not identify the facility, event date, complete PLC code, breaker model, or raw downloadable waveform package.
The Microsoft report does not disclose the specific failed control component or dependency path.
The case study does not publish the full PLC program, breaker records, one-line, or downloadable raw waveform data.
The facility and event date are not disclosed.
The narrative is produced by the monitoring-system supplier and no independent owner investigation is public.
The report does not disclose the failed controller, dependent component, logic version, I/O path, or affected electrical one-line.
The report verifies a control-chain failure but does not state that PLC programming was the initiating defect.
The two incidents demonstrate complementary control-state failures but do not establish a universal transfer architecture or test method.
The project can obtain the controlled program version, cause-and-effect matrix, and consequential I/O map.
A safe staged transfer or validated simulation can exercise the required cases.
The commissioning authority will keep the Pearl inside existing FAT, SAT, MOP, and IST authority.

Where the lesson comes from

Sources

Use the original material to understand the evidence, scope, and context behind this Pearl. Suggested project actions are Build Pearls’ interpretation.

Post Incident Review - Power event impacting multiple services - West US
Microsoft Azure · Source date: 2026-03-01 · PIR, How are we making incidents like this less likely or less impactful?; PIR, What went wrong and why?; PIR, What went wrong and why? and response timeline · Accessed: 2026-08-08
Open source
Data Center Commissioning Case Study
Dranetz Technologies, Inc. · Source date: 2026-02-20 · Case study, concluding failure analysis; Case study, paragraphs describing commissioning transfer tests; Case study, waveform discussion and failure analysis · Accessed: 2026-08-08
Open source

Lesson updated 2026-08-11.