The UPS is installed. Nobody told the PLC it was about to lose power.

Open the cabinet door on a lot of sites, brand-new ones included, and the UPS is there: wired, fan running, status LED green. It still does not do half of what it was bought for.

The failures that follow are rarely spectacular. A database that will not mount. A recipe file truncated mid-write. A batch record with no end timestamp. A historian with a four-hour hole in it. Each one costs far more than the UPS did, and each one could have been prevented at the engineering stage.

A UPS does two jobs. Most installations use one.

The first job is power quality and ride-through. The UPS absorbs sags, surges, transients, noise and distortion, and it keeps PCs, PLCs, HMIs and network equipment alive through a short interruption. This part works on its own, out of the box, and it is the reason the UPS gets specified in the first place.

The second job is telling the system that the power is about to go. Every industrial UPS can do it, through a digital output, a relay contact, a USB or serial link, or SNMP over the network. It reports mains lost, running on battery, battery low and the estimated runtime left; the standard SNMP UPS MIB has had objects and traps for exactly that since 1994.

That signal is where the value is, and it routinely goes nowhere. The contact is not wired. The USB cable is plugged in but no service reads it. The SNMP trap has no destination. The UPS is holding the plant up for eight minutes and not one piece of software in the cabinet knows.

Riding through is not surviving

Buffering an outage only helps if the outage is shorter than the autonomy. When it is longer, and one day it will be, the UPS does exactly what it was designed to do: it runs the battery down and drops the load. The equipment is then switched off mid-operation, which is the same event as pulling the plug, a few minutes later.

Postponing an uncontrolled shutdown protects nothing. The aim is to turn it into a controlled one.

The shutdown is a sequence

This part has to be designed, because it is specific to each installation. “Shut down the PC” is a wish rather than a plan. The order matters:

1. Stop accepting new work. Block the operator interface, stop the acquisition, refuse new batches, so that nothing new enters the system.
2. Bring the process to a safe, declared state. Close the current step, flush the buffers, write the end-of-phase marker. A program halted between step 4 and step 5 with nothing on disk is what makes the restart painful.
3. Close the applications in dependency order: the application first, then the services it depends on, then the database engine, then the file shares. Always the reverse of the startup order.
4. Flush and unmount. Commit the transactions, sync the disks, release the locks.
5. Only then halt the operating system.

Then the same question in reverse, which almost nobody documents: on restart, what comes back, in what order, and what must a person authorise? An automatic restart into a process that was interrupted mid-phase is an incident of its own.

Measure the time you actually have

Two numbers decide whether any of this works.

• T_shutdown: how long your sequence really takes, measured on the real machine with the real database size. A PC that shuts down in 40 seconds when its database is empty can take six minutes with a large transaction to roll back.
• T_signal: how much autonomy remains at the moment the UPS raises the alarm. This is a parameter, and on most units the default is far too late.

T_signal must be comfortably longer than T_shutdown, with margin for an aged battery. If nobody has measured both, what the site has is a UPS and an assumption.

The gaps we find most often

The most common one: the PC is protected and the rest of the loop is not. An AC UPS sits under the workstation, while the 24 V DC rail feeding the PLC, the remote I/O and the managed switch has no buffer at all. The PC survives to watch the process disappear. On a control cabinet, that is the job of a DC UPS on the 24 V rail, and the reverse gap exists too.

The network gets forgotten. The server is up, the switch is not, so the shutdown command never reaches anything.

The battery has never been tested. Lead-acid ages, and it ages faster in a warm cabinet next to a drive. A battery that gave eight minutes at commissioning can give ninety seconds three summers later. Most units run a periodic self-test and report the result; use it, and put the replacement date in the maintenance plan.

The signal is wired but nothing handles it. The contact reaches a PLC input nobody programmed, or a shutdown script exists that has never run once since installation.

And the load has drifted. Two PCs, a printer and a screen were added to a UPS sized for one PC. Autonomy is now a fraction of the design figure, and nobody recalculated it.

What to check on your own installation

• Is the UPS alarm contact or interface physically connected to something that reads it?
• Does a defined, written shutdown sequence exist for this system?
• Has it been executed, end to end, on the real installation?
• How long does it take, and how much autonomy remains when the alarm fires?
• Does everything that matters sit behind the UPS (PLC, I/O, switch, server), or only the visible parts?
• When was the battery last tested, and when is it due for replacement?

A UPS that is never asked to do anything but hum only postpones the incident, and you pay for the delay.

References

• IETF, RFC 1628, UPS Management Information Base, May 1994 (on-battery and low-battery alarms, estimated minutes remaining): rfc-editor.org