Jumps at Two O'Clock
An approach control unit reports that one display channel, fed by a primary surveillance radar, shows occasional track jumps of 2–4 nautical miles followed by a freeze of one to three seconds. The fault began three weeks ago, appears two to five times per day, clusters between 14:00 and 16:00 local time, raises no alarm, and clears without intervention. Three line-replaceable units have already been swapped: the plot extractor card, the display processor and a network interface card - all three passed bench test (no fault found). The unit holds one spare of each card. The equipment room has no temperature monitoring, but the technician's own thermometer reads 31 °C on summer afternoons against a stated limit of 25 °C. A network capture shows 180–220 ms latency spikes on the shared site LAN starting within a minute of a newly scheduled 14:00 backup job. A software patch for the radar interface was released last month and is not yet installed.
1. The team wants to swap the fourth card. Set out how you would investigate instead, and specify the evidence to collect before any further hardware replacement.
Read the worked answer
Stop swapping. Three no-fault-found returns in three weeks is itself diagnostic: the probability that four independent units are faulty is low, while the cost of each swap is real - downtime, risk of introducing a fault, and consumption of the last spare. Swapping is being used as a substitute for measurement.
Build a fault signature first. Every event time-stamped to a common clock, with all layers logged to the same time base: radar head and plot extractor, communications, track server, display. Without a shared time reference, correlation between layers is guesswork.
Evidence to collect: application logs at debug level for the affected channel; interface counters (CRC errors, discards, queue drops); a packet capture with latency and jitter statistics, not just averages; power quality recording at the channel's feed; continuous temperature logging at both air intake and exhaust; the change log for the last six weeks - the new backup schedule is a change, and changes are the first place to look; and a controller diary recording exact times, so the events can be matched to telemetry.
One free diagnostic before any of this: move the affected display position to a different channel and a different position onto this channel. If the fault follows the position, the problem is downstream of the channel; if it stays with the channel, it is upstream. This costs nothing and halves the search space.
The governing principle is correlation in time, one variable at a time - not substitution of components in the hope of a hit.
2. Given the evidence - afternoon clustering, latency spikes starting with the 14:00 backup job, 31 °C against a 25 °C limit, no alarms - rank the hypotheses and give a discriminating test for each.
Read the worked answer
Ranked hypotheses.
Network congestion from the backup job. Latency spikes of 180–220 ms align with a change made around the time the fault started, and track freezes are consistent with delayed or dropped updates. Test: move the backup window to 02:00 for five working days without changing anything else, and compare event counts. Also check whether QoS or priority marking protects the radar traffic, and whether the backup saturates the same physical link.
Thermal. The 31 °C reading is six degrees above the stated limit and afternoons are the hot period. Test: continuous temperature logging time-aligned with the event log, plus temporary supplementary cooling. This is the critical confounder - both hypotheses peak in the afternoon, so the backup-window test also separates them: if events persist at 14:00 with the backup moved to night, thermal remains; if events stop, network dominates.
Power quality / aging UPS. Intermittent freezes with self-recovery fit supply disturbance. Test: power analyser on the feed, UPS battery age and transfer test, and comparison against other equipment on the same distribution board.
Latent software defect in the radar interface. The pending patch makes this plausible, but the timing correlation is weaker than for 1 and 2. Test: review vendor release notes for a matching symptom and check whether any other site on the same version reports it.
The discipline is to vary one factor at a time while holding the others constant; running the patch and moving the backup in the same week would leave the cause permanently unknown.
3. What operational and maintenance decisions do you take while the investigation runs - spares, patching, redundancy, recording?
Read the worked answer
Spares. Three consumed units with one spare left is a material availability risk. Raise it in the maintenance management system, order replenishment now (lead times are usually weeks), and consider a formal loan from a sister unit. Do not consume the last spare without a confirmed diagnosis - hold it for a genuine confirmed failure.
Redundancy and operations. Confirm whether the affected channel has a hot standby position and whether the display configuration can be re-mapped. If redundancy is reduced, ask the watch supervisor for an operational mitigation - capacity restriction, additional supervision, contingency procedures - and record that decision.
Patching. Do not install the radar interface patch as a "possible fix" while the root cause is unknown: it destroys the evidence baseline and introduces a second variable. Review the release notes; if they describe this exact symptom, plan the patch deliberately, with rollback, a defined before/after measurement period, and configuration control.
Recording. Keep a dated investigation log with evidence, hypotheses and decisions - including the decision not to act. Return the three no-fault-found units to the vendor with a request for extended test under load and temperature, since a bench test at ambient will not reproduce a thermal or load-dependent fault. If a display freeze could affect separation, file a safety occurrence, because the absence of an alarm is itself a safety finding: the system silently degraded and nobody was told.