Traffic signal cabinets run continuously, and the storage media inside them is almost always mid-write when the grid drops. That moment, a power cut arriving partway through a file system transaction, is one of the most reliable ways to corrupt operational data. Yet backup power planning for cabinet storage is still treated as an afterthought on many Australian deployments, subordinated to controller uptime or communications continuity. The consequence is storage that survives the physical environment but fails at the software level, exactly when fault logs and event records are needed most.
Why power loss corrupts storage, not just clears it
The assumption that storage is simply "off" during a power loss is wrong. Modern NAND flash and industrial SSDs use write buffers and internal caches to batch operations for endurance reasons. When power disappears mid-write, those buffers don't flush cleanly. The result can be partial sectors written, metadata tables left in an inconsistent state, or journal entries that never committed. File systems designed for enterprise environments (ext4, NTFS) use journalling to reduce this risk, but journalling only protects the file system structure, not the data that was in transit at the moment of interruption.
Industrial SSDs marketed for transport applications address this with power-loss protection (PLP) circuitry. PLP uses onboard capacitors to hold enough charge to flush write buffers after main power is removed. It's a short window, typically 10 to 30 milliseconds, but that's enough to complete the in-flight transaction. Not all devices marketed as "industrial" include PLP. Procurement teams should ask for the specific capacitor specification and the datasheet's PLP test methodology, not just the label.
What backup power actually needs to cover
Cabinet-level UPS systems are common for keeping the signal controller alive during brief outages. What they're often not sized for is the additional draw of storage subsystems, communications modules, and logging hardware running through the transition. A UPS that holds the controller for 90 seconds may only provide 30 seconds if the full cabinet load is considered.
The storage-specific requirement is different from the controller requirement. The controller needs sustained power to keep the intersection running. The storage subsystem needs a controlled shutdown: enough time to close open file handles, flush caches, and unmount the file system cleanly. On a well-configured Linux-based controller, a clean unmount takes 2 to 5 seconds. On a system under heavy logging load, it can take longer. The UPS sizing calculation must account for this, and the shutdown sequencing must be scripted, not left to default OS behaviour.
Bob Panich Traffic Signals designs cabinet storage configurations with explicit shutdown sequencing as part of the electrical specification. Backup power capacity is calculated against the full cabinet draw, not the controller draw alone, and the storage subsystem is assigned a dedicated shutdown window before UPS exhaustion.
Redundancy doesn't substitute for power discipline
A common misconception is that redundancy in industrial data storage removes the need for backup power planning. RAID arrays and mirrored storage protect against device failure, not write corruption. If both members of a mirrored pair lose power simultaneously mid-write, both copies can carry the same corrupt transaction. The redundancy is intact; the data is still bad.
RAID and mirroring work on the assumption that at least one device completes its write successfully. That assumption holds against single-device failures. It does not hold against cabinet-wide power events. The two protections, redundancy and power continuity, address different failure modes and both are necessary.
Event logging under power stress
Traffic signal controllers write to storage continuously. Data logging in traffic signal cabinets covers a wide range of operational records: phase changes, detector activations, fault codes, timing adjustments. During a power event, this write activity is at its highest, because the controller is logging the fault itself. That's the worst possible moment for the storage system to lose coherence.
Some controllers address this by writing fault and power-event records to a dedicated non-volatile memory region separate from the main storage volume. This region is small, typically a few megabytes, but it's protected by its own capacitor and is written with a simpler, append-only structure that doesn't require a file system. The main log volume can be reconstructed or reconciled against this record after power is restored. This architecture is worth specifying explicitly rather than assuming it's present in any given controller platform.
Thermal interaction with backup power
UPS battery chemistry is sensitive to cabinet temperatures. Lead-acid and lithium-ion cells both derate at elevated temperatures, reducing the capacity available during a summer power event, which is precisely when grid instability from demand peaks is most likely. A UPS sized correctly at 20°C may deliver only 70 to 80 percent of rated capacity at 45°C, which is a realistic cabinet temperature on a hot Australian afternoon without active cooling.
Specifying sealed lead-acid cells for high-temperature cabinet environments without thermal derating calculations is a design gap. Lithium iron phosphate (LiFePO4) chemistry handles temperature variation better and cycles more predictably, but it costs more and requires a compatible charge controller. The right choice depends on the cabinet's thermal profile across the year, not just its nominal operating temperature. For guidance on how thermal conditions affect storage hardware more broadly, the analysis of temperature and humidity effects on industrial storage in traffic cabinets covers the hardware interaction in detail.
Testing the shutdown sequence
The shutdown sequence that runs during a power event is almost never tested in the field. It's configured during commissioning and assumed to work. That assumption is worth challenging. A controlled power-pull test, with storage examined afterwards for file system consistency, is straightforward to conduct and should be part of commissioning sign-off on any deployment that uses active data logging.
The test procedure is simple: run the cabinet under normal logging load, cut main power, allow the UPS shutdown sequence to complete, restore power, and mount the storage volume on a separate diagnostic machine. Run fsck or the equivalent file system checker and examine the results. A clean result on first pass confirms the shutdown sequence is working. Any errors indicate the UPS window, the shutdown script, or the PLP configuration needs adjustment.
Bob Panich Traffic Signals includes controlled power-loss testing in its commissioning checklist for cabinet deployments involving active data logging. The Australian Government's Department of Energy and state-level transport authorities both reference data integrity as a reliability requirement in infrastructure standards, and a documented test result supports compliance reporting against those requirements.
Specifying for power resilience
A storage specification that addresses power resilience covers four items: PLP circuitry with documented capacitor specifications on the storage device itself; a UPS sized to the full cabinet load with thermal derating applied; a tested and scripted shutdown sequence with a defined time budget; and a file system or logging architecture that separates fault records from the main log volume. None of these is exotic. All of them require an explicit decision at design time, because none will appear by default.
Procurement documents that specify "industrial SSD" without addressing PLP, or UPS capacity without thermal derating, leave the gap open. Closing it before procurement is straightforward. Closing it after a corruption event, when fault logs from a safety-critical intersection are missing or inconsistent, is not.