UPS Firmware Update Revalidation: What Needs Re-Testing

A firmware update on a qualified UPS rarely requires repeating the qualification. What it always requires is a documented impact assessment through change control, and what it usually requires beyond that is targeted re-testing of the few functions UPS firmware can actually touch: mains-loss ride-through behavior, alarm and notification paths, the battery self-test schedule and charging setpoints, and the integration with your monitoring system. EU GMP Annex 15 puts utilities squarely in scope, and its re-qualification section says equipment, facilities, utilities, and systems should be evaluated at an appropriate frequency to confirm that they remain in a state of control. A firmware version is part of that state. The one indefensible answer is applying the update and recording the new version number with no assessment behind it.

This article is the utility-specific companion to our general guide on what to do when equipment gets a software update. That guide covers the three impact classes and the decision frame for any software change. This one applies them to the equipment where firmware updates most often arrive unannounced and least often come with a useful changelog: the UPS and its utility siblings.

Why a UPS is a qualified system in the first place

Annex 15 does not only govern process equipment. Its qualification sections run through equipment, facilities, utilities, and systems (the phrase both the qualification stages section and clause 4.1 use), and a UPS that protects qualified equipment earns its place on that list the moment a power event can affect product or data. A UPS feeding a filling suite, a stability chamber bank, a server hosting Part 11 records, or a temperature-controlled storage area is a direct-impact utility: its failure mode is not an inconvenience, it is an excursion, a lost batch record, or an uncontrolled shutdown mid-cycle.

That is why the original qualification of a UPS typically carries an IQ confirming installation, ratings, and battery configuration, and an OQ challenging the functions the process relies on: support of the load through a mains loss within the manufacturer's specification for the topology (a double-conversion unit carries the load from the inverter with no break, while a line-interactive unit transfers to battery within its specified transfer time), clean return to normal operation on restoration, alarm and relay outputs reaching the systems that are supposed to hear them, and runtime under representative load. Which document set a given UPS needs follows the same logic as any asset, covered in how to determine IQ-only versus full IQ/OQ/PQ. A PQ is rarely part of the package, for the same reason many utilities never need one: the performance demonstration lives in the OQ challenges, not in sustained production use.

The firmware inside that UPS is part of the qualified configuration. When the vendor updates it, the validated state has a new variable in it, and the question is what changed.

What UPS firmware can actually change

Firmware sits at the embedded layer, which our general guide flags as the layer that deserves extra scrutiny: changes there can alter behavior in ways that are invisible from release notes. On a UPS specifically, firmware plausibly touches five areas.

Transfer and inverter control logic. The core protected function. A firmware revision can change how the unit detects mains failure, how it carries or transfers the load when mains is lost, how it behaves on return to mains, and how it handles overload or bypass conditions.

Alarm thresholds and relay mapping. Which conditions raise alarms, at what thresholds, and which dry contacts or protocol messages they drive. A remapped relay is silent until the day it matters.

Battery management. Self-test schedules, charging voltage and temperature compensation profiles, and end-of-life estimation. A reset self-test schedule after an update is a classic quiet failure: everything works, and the battery degrades untested.

Communications and monitoring. The SNMP, Modbus, or BMS-facing behavior that feeds your monitoring and alarm forwarding. On many units this lives in a separately versioned network management card whose firmware updates independently of the main unit, so the equipment record should track both versions. Protocol-level changes can break the integration your alarm response SOP assumes, and if the UPS events feed an electronic record, the Part 11 controls around that record care about the change too.

Display and cosmetics. Panel text, menu layout, LED behavior. The only genuinely low-stakes category, and the one vendors describe most thoroughly.

The general guide's classification rule applies with full force here: without a function-level changelog, the safer default is to treat a firmware update as if the behavior of a qualified function has changed, until the vendor's documentation or your own verification proves otherwise. UPS vendors are better than most at publishing firmware release notes, but the notes are written for uptime engineers, not for validation. "Improved transfer performance under transient conditions" is a Class C sentence wearing a Class A costume.

The impact ladder, applied to utility firmware

The five outcomes from the general framework map cleanly onto a UPS update, with one systematic bias: because firmware changelogs are thin, utility updates land on the assessment-plus-targeted-testing rung more often than application software does.

Documentation update only fits a display-layer or cosmetic revision the vendor documents explicitly as such. Record the new version in the equipment record through change control. The executed IQ is not edited; it remains the historical record of what was installed at qualification, and the change control trail carries the current version.

Impact assessment without testing fits an update to functions your installation does not use, documented as such: a firmware fix for a parallel-operation mode on a standalone unit, or for an interface card that is not installed.

Impact assessment plus targeted re-testing is the workhorse for UPS firmware, and the targeted tests are mercifully short. A transfer test, an alarm path check, a battery-schedule verification, and a monitoring handshake can be executed in an afternoon against predefined acceptance criteria.

Partial revalidation applies when the vendor's notes or your assessment show the transfer or inverter control logic itself changed: re-execute the original OQ transfer and alarm challenges for the affected functions, with new acceptance evidence. The boundaries of that scoping decision follow the same rules as any revalidation trigger.

Full revalidation is rare for firmware alone. It belongs to changes that shift the qualification baseline: a controller board replacement that carries new firmware with it, or an update so extensive the vendor treats it as a new product generation.

One more distinction worth keeping crisp: GAMP 5 categories are a useful vocabulary for the software discussion, and firmware embedded in a purchased unit is generally assessed with the equipment rather than as standalone software. But category debates settle nothing by themselves. The impact assessment, not the category label, decides what gets re-tested. GAMP 5 is guidance; the requirements come from the GMP regulations and Annex 11, a distinction the general guide walks through in more detail.

Worked example: a 30 kVA UPS feeding a filling suite

The vendor publishes firmware 4.2 for a 30 kVA unit protecting a filling line and its associated monitoring server. The release notes list a fan-control defect fix and a new remote-notification feature, disabled by default.

The impact assessment, run through change control, works function by function. The fan-control fix touches thermal management, not transfer logic; the vendor's function-level changelog states transfer, alarm, and battery-management code paths are unchanged. The remote-notification feature is new functionality alongside existing qualified functions, the classic Class B situation: it stays disabled and unqualified until someone decides to use it, and the assessment records that the update leaves it off by default. Two carryover risks remain, both firmware-update classics: configuration survival (does the battery self-test schedule and alarm setup carry through the update intact) and monitoring continuity (does the SNMP integration still talk to the BMS the same way).

The targeted re-test list, with predefined acceptance criteria in a short protocol:

1. Mains-loss ride-through test under representative load: simulated mains loss, output disturbance within the manufacturer's specification for the topology (no measurable break for a double-conversion unit, within the specified transfer time for a line-interactive unit), clean return to mains operation on restoration, and the correct event logged with the correct timestamp.
2. Alarm path verification: trigger a battery-disconnect and a mains-fail alarm; confirm the mapped relay outputs and the BMS receive both, and that the alarm text matches the response SOP.
3. Configuration survival check: battery self-test schedule, charging setpoints, and alarm thresholds, as the unit exposes them, read back unchanged against the documented pre-update configuration export.
4. Monitoring integration check: the monitoring server still polls the unit, event forwarding still reaches the on-call route, and the event log carries the new firmware version.

All four checks belong in a planned maintenance window, with the process protected or a load bank standing in for it. A mains-loss challenge against a live filling line is a deviation waiting to happen.

The change record captures the assessment basis (vendor function-level changelog plus the configuration diff), the classification rationale, the executed re-test results against their acceptance criteria, the new firmware version in the equipment record, and the explicit note that the remote-notification feature remains disabled pending its own qualification. The executed original OQ is untouched; the trail from it to today runs through change control. That evidence chain, requirement to test to result, is exactly what a traceability matrix exists to keep walkable.

Fleets, failures, and the state of control

Three practical notes finish the picture.

Fleets. Sites rarely have one UPS. The impact assessment can be written once per firmware version and equipment model, but the verification evidence is per unit: each unit's configuration survival and transfer test stands on its own, because each unit's configuration and battery state is its own. One assessment, per-unit execution records.

Failed updates. An update that fails mid-flash, bricks a unit, or produces anomalous post-update behavior is a deviation, handled with the same discipline as any failing result against pre-defined criteria: record what happened, investigate, and document the recovery path, including whether the vendor's rollback restores the exact prior version.

The state of control. Annex 15 clause 4.1 expects utilities to be evaluated at an appropriate frequency to confirm they remain in a state of control, and clause 4.2 adds that the possibility of small changes over time should be assessed. Firmware currency belongs in that periodic evaluation. A unit five firmware versions behind is not safer for having been left alone: it means the next update carries five versions of accumulated change in one step, and the impact assessment for that jump is far harder to write honestly. Reviewing pending firmware during periodic review keeps each delta small enough to assess honestly, which is the whole point of the IQ/OQ/PQ structure staying live rather than archival.

The compact version: a UPS is a qualified utility, its firmware is part of the validated state, and an update earns one of five responses, decided by a documented impact assessment and biased, for firmware, toward a short targeted re-test of ride-through, alarms, configuration survival, and monitoring. New features stay off until qualified. The executed qualification is never edited. And the update you assess this quarter is always easier than the five-version jump you assess in three years.

Valiqa generates IQ and OQ protocols for equipment and utilities from their specifications, including the transfer, alarm, and monitoring challenges a UPS qualification carries, and its change-impact assessment flags which qualified requirements a change touches so the re-verification scope is derived instead of guessed. The protocols carry quantitative acceptance criteria with per-step rationale, so the targeted re-test protocol for a firmware update starts from the qualified baseline instead of template surgery.

---

Valiqa is an AI-powered validation lifecycle platform for regulated manufacturing. Learn more at valiqa.io

Get new validation guides in your inbox

One or two practical guides a week, written for validation engineers. Unsubscribe anytime.