Many embedded test rigs represent power control with two keywords:

Power Off
Power On

Those names are convenient at the test-case level. The implementation underneath them should be a state machine.

Opening a relay does not prove that the product is unpowered. Stored energy may keep parts of the circuit alive. A communication cable can back-power an interface. Multiple rails can collapse in an unexpected order. Closing the relay again does not prove that the supplies are stable, reset has been released, boot has completed, or the device is ready to receive the next command.

A repeatable power cycle must define and observe each transition.

Define what “off” means

The required off state depends on the test objective. A warm reboot, processor reset, ignition cycle, low-power transition, and full energy removal are different operations.

For a full power removal, the contract may require:

  • primary input below a defined threshold;
  • secondary rails discharged;
  • communication interfaces not back-powering the device;
  • reset asserted or processor inactive;
  • the state maintained for a minimum interval;
  • measurement channels still active enough to prove the condition.

The threshold and interval should come from product behaviour and electrical requirements, not from a convenient sleep in the automation.

If the product contains large capacitance, batteries, supercapacitors, or independent supplies, the off-state detector needs to account for them.

Observe before and after the relay

A programmable relay gives the automation control over a circuit. It does not prove the voltage delivered to the product.

Measure at the relevant product connection where practical. A complete power path may include:

  • supply output;
  • protection and switching;
  • harness and connectors;
  • fixture contact;
  • product input;
  • local regulators and reset circuitry.

Monitoring both command and measured effect allows the system to distinguish:

  • command not accepted;
  • relay failed to change;
  • output changed but the product connection did not;
  • input removed but a secondary path kept the device alive.

For multi-rail systems, capture the order and timing of the rails. Power-sequencing devices exist precisely because voltage thresholds, reset, and timing are meaningful system behaviour.

Model the cycle as explicit states

A robust sequence can use states such as:

  1. Ready: the device is operating and the rig has current evidence of its state.
  2. Shutdown requested: a graceful shutdown is commanded when the scenario requires it.
  3. Isolation: controlled power paths are opened and back-power paths are addressed.
  4. Discharging: voltage is observed until all required rails cross their off thresholds.
  5. Off dwell: the verified off state is maintained for the defined interval.
  6. Energising: input is applied and the rise of required rails is observed.
  7. Reset hold and release: reset behaviour is checked against the power state.
  8. Boot observation: boot signals, current profile, logs, or display transitions are collected.
  9. Ready verification: the product satisfies an explicit readiness contract.
  10. Failed or recovery: abnormal transitions are captured and handled safely.

Each state should have an entry condition, expected observations, timeout, and failure path.

Use conditions instead of arbitrary delays

Fixed delays encode an assumption about time without proving the state.

Replace “sleep for five seconds” with conditions such as:

  • wait until measured input is below the off threshold;
  • require that threshold to remain satisfied for the dwell interval;
  • wait until each rail enters its valid range;
  • wait for reset to release;
  • wait for the first boot event;
  • wait until communication responds with the expected device identity;
  • wait until the application reports the intended mode.

A maximum timeout still matters. It bounds the test and turns “never reached readiness” into a defined failure. Polling should have a reasonable interval and should preserve the sequence of observed values.

Use a monotonic clock for elapsed durations so changes to wall-clock time cannot move the measurement backward.

Synchronise electrical and software evidence

Boot problems often occur during a narrow transition. Correlate:

  • input voltage and current;
  • secondary rails and reset;
  • bootloader and application logs;
  • bus availability;
  • watchdog or diagnostic output;
  • display or indicator state;
  • host command and observation timestamps.

One shared timebase or measured offset between timebases makes the evidence far more useful. Without correlation, the team sees separate graphs and logs but cannot establish which event came first.

Detect back-powering explicitly

USB, serial, debug, network, GPIO, and measurement equipment can provide unintended current paths. Symptoms include a device that does not fully reset, rails that decay slowly, or a processor that remains partially powered.

Test the rig configuration:

  • compare discharge with interfaces connected and isolated;
  • measure residual voltage and current;
  • use appropriate isolation where the test requires full energy removal;
  • define which interfaces may remain connected in each scenario;
  • check that measurement inputs do not materially alter the circuit.

Do not automatically disconnect everything. Some requirements intentionally test recovery while communication remains connected. The point is to make the path deliberate and observable.

Separate cycle types

Give distinct operations distinct names:

  • software restart;
  • watchdog reset;
  • reset-pin pulse;
  • ignition cycle;
  • primary-supply interruption;
  • complete discharge cycle;
  • brownout or transient injection.

Each operation should have its own state contract. A test that says “power cycle” without specifying which one is difficult to reproduce and easy to misinterpret.

Preserve the failed transition

When the device does not boot, capture evidence before attempting another cycle:

  • final voltages and current;
  • last log and bus activity;
  • reset state;
  • time spent in each transition;
  • rig configuration;
  • product and software versions.

Then enter a controlled recovery sequence. A blind retry may erase the state that explains the failure.

Test the state machine itself

The device-control layer should be tested without depending entirely on the real product. Use simulated instrument responses, reference loads, loopbacks, or a controllable target to exercise:

  • relay command failure;
  • voltage that never falls;
  • rail that rises too slowly;
  • reset stuck active;
  • communication that appears before the application is ready;
  • timeout during boot;
  • successful recovery;
  • emergency interruption.

This is how the power-control system earns the right to judge the product.

At the test-case level, Power Cycle Device can remain one readable keyword. Its implementation should be a transparent, bounded, evidence-producing state machine. The relay is only one transition inside it.

Source notes for review