Data logging in traffic signal cabinets is one of the most practical but least-discussed aspects of signal system design. Every modern signal controller records a continuous stream of operational events: phase activations, detector triggers, fault flags, power anomalies, and timing overrides. That data sits on local storage inside the cabinet until it's retrieved, transmitted, or purged, and the decisions made during system design determine how complete and usable it is when an engineer actually needs it.
What a traffic signal cabinet records
Signal controllers don't log a single data type. They produce several distinct streams, each with different update rates and different downstream uses.
Phase and timing logs record every green, amber, and red phase, including the actual duration versus the planned timing plan. These logs are the primary source for post-incident analysis. If a near-miss or collision occurs at an intersection, the phase log shows exactly what state the signals were in and for how long.
Detector event logs capture vehicle and pedestrian detector activations, extension calls, and gap-out events. In intersections running adaptive signal control, detector logs are particularly dense because the system is polling sensors continuously and adjusting cycle times in response.
Fault and alarm logs record controller errors, communication dropouts, lamp circuit failures, and watchdog timer resets. These entries carry timestamps and fault codes that maintenance crews use to prioritise callouts. A recurring fault code logged at 03:15 on consecutive nights points to a very different problem than a single fault logged during a storm.
Power quality events, including supply fluctuations and UPS switchovers, are also captured by most controllers. These are easy to overlook during system specification but become critical when diagnosing intermittent resets or unexplained phase restarts.
Where the data physically lives
Most cabinet controllers write log data to onboard flash storage. The storage capacity available ranges widely depending on controller generation, from a few hundred megabytes in older units to several gigabytes in current-generation hardware. That difference matters more than it sounds. A controller logging at high resolution across all data streams can fill a small storage partition in days, not months.
Write endurance is a related concern. Flash storage has a finite number of write cycles per cell, and continuous logging accelerates cell wear. Write-endurance limits in industrial storage are a well-understood constraint, but they're not always factored into cabinet design early enough. Controllers that log at high frequency without wear-levelling or log rotation policies in place can degrade storage faster than expected.
Some deployments supplement onboard storage with removable media, typically industrial-grade SD cards or compact flash modules. Others offload logs to a central data management system over a SCATS or SCOOT communications network. Neither approach eliminates the need to think carefully about local storage capacity. Network links drop, and when they do, the cabinet needs enough local headroom to buffer data without overwriting it.
Log rotation and retention
Traffic signal logs don't keep themselves tidy. Without defined log rotation and retention policies, onboard storage fills, and the controller either stops logging or begins overwriting the oldest records. Both outcomes create gaps that are difficult to explain to a transport authority or a court.
Retention requirements vary by jurisdiction and data type. Phase timing logs may need to be kept for 90 days to support incident investigations. Fault logs may need to be accessible for 12 months for compliance auditing. Data retention policies for industrial traffic systems establish the minimum holding periods that storage sizing must accommodate, and those policies should be confirmed with the relevant road authority before any cabinet storage specification is finalised.
Practical log rotation works by rolling over to a new log file on a defined schedule (daily or weekly) while retaining a set number of historical files before deletion. Controllers that support this natively make retention management straightforward. Older controllers that write to a single flat file require a more hands-on approach, usually handled by the central management system during scheduled polling.
Data retrieval and formats
Logged data has no value if it can't be retrieved and interpreted. Signal controllers from different manufacturers store logs in different formats. Some use proprietary binary formats that require vendor-supplied tools to read. Others export to standard formats such as CSV or XML, which are more accessible for analysis in transport management software.
The Australian and New Zealand standards that govern traffic signal equipment, particularly AS 2578, address controller performance and testing but don't prescribe a universal log format. In practice, most Australian deployments running SCATS controllers store logs in formats compatible with the TMC (Traffic Management Centre) software suite, but field engineers should verify compatibility during commissioning rather than assuming it.
Retrieval can be local (USB or laptop connection at the cabinet), remote (via the traffic management network), or scheduled (automatic push to a central archive at defined intervals). Remote retrieval is preferable for operational efficiency, but it depends on a working network connection and a TMC configured to accept the data. Designing for local retrieval as a fallback is good practice.
Why log completeness matters for fault diagnosis
Intermittent faults are the hardest to diagnose in any electronic system. A cabinet that reboots once a week with no apparent cause can be attributed to dozens of different failure modes: power supply instability, a controller firmware bug, a detector short circuit, a communication watchdog timeout, or a storage fault causing the operating system to restart. Without complete logs covering the minutes before and after each event, diagnosing the root cause is largely guesswork.
Complete logs narrow the field quickly. A power quality event logged 90 seconds before every reboot makes the diagnosis clear. A fault code referencing a specific detector input, logged at the same time as a phase timing anomaly, points directly at the hardware to inspect. Engineers who have worked with well-configured logging systems spend less time on site and less time replacing parts that weren't the problem.
The investment in getting data logging right during cabinet design and commissioning pays off over the operational life of the system. Signal controllers in Australian deployments typically remain in service for 10 to 15 years. A well-configured logging setup continues to deliver diagnostic value across that entire period. A poorly configured one creates gaps from day one.