The plant needs to agree what time it is

I measured my own plant recently and found that the equipment whose timestamps end up in the historian had never once asked anything what the time was. Not in a day of watching. Meanwhile two paths into that same database were recording two different kinds of time, one of them drifting by about a minute and a half every hour.

That is a normal state of affairs, and it stays invisible for years. Time synchronisation is the cheapest thing in a plant that nobody owns: no vendor sells it hard, it never appears in a capital plan, and nothing breaks on the day it is missing. It becomes visible exactly once — when somebody is reconstructing an incident from timestamps, and the timestamps disagree.

So this is what to do about it, in the order the decisions actually get made.

First: how accurate do you need to be?#

This question comes before every other one, and skipping it is why time projects either never start or get badly oversized. There are two very different answers.

About a millisecond, which is what you need to put events in the right order. Time-tagging alarms, sequence of events, correlating a trip across a few panels. Ordinary network time synchronisation delivers this comfortably.

About a microsecond, which is a thousand times tighter, and which ordinary network time synchronisation cannot do at all. This is the domain of protection relays and measurement-grade applications — mostly, though not only, in electrical work. It needs a different protocol, and the network switches themselves have to participate rather than just forward packets.

The distinction matters commercially. The first is a configuration exercise you can complete this quarter with equipment you own. The second is a project with a hardware bill, because the switches are part of the timing system.

Most plants need the first for almost everything and the second for a small, well-defined set of equipment that will tell you it needs it. Work out which category each system falls into before anybody prices anything.

Where the time comes from#

The reference is a receiver that picks up time from satellites, which is as close to an unarguable source as a plant can own.

That means an antenna, and this is the part that turns a good idea into a job: it needs a clear view of the sky, which means a roof, which means a cable run, which means lightning protection and somebody's approval to drill something.

The two alternatives are worse in ways that are not obvious.

Taking time from the internet puts a dependency on an outside network into the part of your plant that is supposed to survive without one. It also means trusting a source you cannot inspect.

Taking time from the office — the domain controller everyone already uses — sounds sensible and quietly makes the plant depend on the corporate network being reachable and correct. It also drags a connection across the boundary you spent money building.

Where the server belongs#

Here is the part that gets designed by accident.

Time synchronisation is traffic that crosses boundaries. Every device in the plant needs to reach it, which means it is exactly the kind of flow that a segmentation project has to account for deliberately — and, in my experience, exactly the kind that nobody remembers until a rule blocks it.

So place it inside the plant, not outside. The plant should hold its own time and keep working if everything above it disappears — that is the same principle as any other plant-floor dependency, and time is the one people forget to apply it to.

If the office also wants time from the same source, let it take it from the plant's server rather than the plant reaching up for it. The dependency should point downward, never up.

Two is the worst number#

This is the finding I would most like people to take away, because almost every site that has thought about time at all has landed on exactly the wrong answer.

With one source you have no check. If it is wrong, everything is confidently wrong together, and nothing anywhere disagrees.

With two you have discovered a problem and no way to solve it. When they disagree — and they will — nothing can tell you which one is lying. A device looking at two disagreeing sources cannot make a decision, and that is not a configuration failure, it is arithmetic.

With three a majority becomes possible: two that agree, one that does not.

With four you can survive one source being wrong and still have a majority left over. That is the recommended minimum, and the reason is not belt-and-braces caution — it is what the selection maths actually requires.

Almost everyone configures two, calls it redundancy, and has in fact built the one arrangement that cannot resolve its own disagreement.

The short list#

• Decide your accuracy tier per system before pricing anything.
• Own your reference. A receiver on your own roof, not the internet and not the office.
• Put the server inside the plant, and let the dependency point downward.
• Configure at least three sources, ideally four. Never two.
• Treat it as a flow that crosses boundaries, so it survives the next segmentation project.
• Have a second reference, because an antenna is a single point of failure sitting on a roof in the weather.
• Watch it. A time source that has quietly stopped disciplining anything looks exactly like one that is working — the failure is silent, which is the whole problem with time.

What to check on Monday#

Ask what each system is pointed at, then confirm it by looking rather than by asking. This is a short exercise with a frequently surprising answer. On my own plant, the honest answer was nothing at all, and I only found that by watching the network rather than reading the configuration.

Count your sources. If the answer is two, you have the arrangement that cannot resolve a disagreement.

Find out which direction the dependency runs. If the plant reaches up to the office for the time, that is a line crossing a boundary that somebody should have had to justify.

None of this is expensive, and none of it is interesting until the day it is the only thing that matters.

What I actually measured on my own estate — the two kinds of time, the drift, and what the network showed about synchronisation — is in the companion piece and the lab notes. Why traffic that crosses boundaries deserves a name and a rule is in a conduit is not a cable.