Name: Covenant Systems
Address: US
Price range: $$

Question 1

Why does merging logs by timestamp go wrong?

Accepted Answer

Because every device stamps its log from its own clock, and those clocks are only as good as whatever is disciplining them. A relay on IRIG-B is good to microseconds. The same relay with a dead time source drifts seconds a week and nothing in its report says so. Merge several devices by timestamp alone and you get an order that looks authoritative and may be entirely wrong — which matters, because the order is the whole reason to merge them. The example incident here is built to show it: as loaded, the upstream relay picks up two and a half seconds before the feeder relay sees the same fault current, and the RTAC watches the breaker open a second and a half before the relay that tripped it issued the command. Neither is possible. Both are ordinary.

Question 2

What does pinning two events actually do?

Accepted Answer

It turns an assumed clock error into a measured one. You pick an event on a device you trust and the event on another device that happened at the same instant, and everything on the second device shifts to match. The pairs worth using are the ones justified by wiring or by physics rather than by the clocks: two relays looking at the same fault current pick up together to within a cycle, and a breaker auxiliary contact wired to both a relay input and an RTAC point is genuinely one event seen twice. There is an expected-delay field because not every useful pair is simultaneous — a breaker auxiliary contact does not change at the instant the trip coil is energised, and anchoring the two as though it did would fold that interval into the correction and make it disappear from the very timeline you were building to measure it.

Question 3

Why are some rows marked as orderings the clocks do not establish?

Accepted Answer

Because they are not established. Each device carries an uncertainty — how far its clock might be out — and where two events from different devices sit closer together than the sum of those uncertainties, the order shown is what the timestamps happen to say rather than something the logs demonstrate. Any other order of those rows is equally consistent with the evidence. Most tools draw the list and let you assume; this one highlights the stretch and says how wide it is, because the difference between “A then B” and “A and B, order unknown” is exactly the difference between a finding and a guess.

Question 4

If a relay's clock is wrong, why is its own sequence still trustworthy?

Accepted Answer

Because the error is common to both timestamps and cancels in the interval between them. A relay whose clock is three seconds fast still measures the gap between its own trip and its own breaker auxiliary contact correctly, because both were stamped by the same wrong clock. That is why this tool never flags a device's events as uncertain against each other — only against other devices — and it is why a single relay's SER remains the most reliable thing in an incident even when nothing in the station agrees about the time.

Question 5

Which log formats does it read?

Accepted Answer

It does not have a list, deliberately. There is no standard here — an SEL-351 writes a different SER table from an SEL-451, an RTAC writes something else, and a SCADA export is usually CSV with whatever columns someone picked — so a parser per vendor guarantees that the one log that matters on the night is the format nobody added. Instead it looks for the three things every such line actually has: a time, a point name, and a state. The example incident deliberately uses three different real layouts to exercise that. Anything it cannot read is listed under the device rather than dropped, because a log viewer that silently discards a third of a file is worse than one that opens nothing.

Question 6

How does it handle ambiguous dates?

Accepted Answer

It says so. A log that writes 03/04/26 is genuinely ambiguous, and if no date anywhere in the file has a value above twelve there is nothing in the data that settles month-first against day-first. Where a day above twelve does appear, the question is answered and no warning is raised. Where it does not, the file is read as month-first and the device panel says that it guessed — because a silent wrong guess puts the whole incident a month away from where it happened, and that is the kind of error that survives a review.

Question 7

Is this a substitute for proper time synchronisation?

Accepted Answer

No, and it should not be treated as one. The right fix for a station whose devices disagree about the time is IRIG-B or PTP into every device, checked. This tool is for the incident you are reconstructing now, from the logs you already have, where two of the devices were never synchronised and one of them lost its source months ago. What it can do is make the resulting uncertainty explicit instead of leaving it to be assumed away — and, often enough, show clearly that the clocks were wrong so somebody goes and fixes them.

Question 8

Does anything I load get uploaded?

Accepted Answer

No. The logs are read with the browser's own file API and parsed in local JavaScript; the merging, the clock corrections and the CSV export all run on your machine. Nothing derived from a file is transmitted — no device names, no station, no element names, no timestamps, no intervals. That matters more here than almost anywhere: an SER report names a station, a relay and every point that changed state during a fault, it describes a real incident on real plant, and in some jurisdictions it is evidence. This page carries the same anonymous usage analytics as the rest of the site, which records that a log was loaded and whether the parser coped with it. It cannot see the log.

Sequence of Events Merger

Feeder 52-F1 ground fault

The example is three real report layouts, parsed by the same code your files go through

Does it choke on your log?

Why this is hard

Pairs worth pinning

Questions