The clock is now a control surface: AI’s impact on time synchronization in OT

A factory can forgive a late email. It won’t forgive a robot arm that arrives three milliseconds after the conveyor.

That sounds absurdly small. Three milliseconds barely qualify as waiting. Yet inside operational technology, tiny gaps can carry heavy consequences. A protection relay trips late. A vision system pairs an image with the wrong product. Two controllers record the same event in opposite order. The machines keep moving, but the story they tell about what happened begins to split.

I learned long ago that clocks in OT aren’t office furniture. They’re part of the control system.

Now AI is moving into that system, watching clock drift, network delay, oscillator health and odd timing patterns. The promise sounds attractive. Spot trouble earlier. Explain it faster. Correct it before operations feel the pain.

Then comes the awkward question.

What happens when a system built on probability begins advising infrastructure that depends on certainty?

Time is a control input

In IT, poor timekeeping often creates irritation. Logs don’t match. Certificates complain. Investigators lose an afternoon and develop strong views about whoever configured NTP.

In OT, the consequences can leave the screen.

Industrial devices need a common sense of time because they act together. Controllers, sensors, relays, drives and switches may sit in different cabinets, yet they must agree on when an event occurred and when the next action should begin. IEEE 1588 Precision Time Protocol exists for this reason. It gives networked measurement and control systems a shared clock with far greater precision than ordinary business systems usually need.

Power automation makes the point with little room for poetry. IEC/IEEE 61850-9-3 defines a PTP profile for power utility systems that must meet demanding synchronization classes.

That shared clock supports more than speed. It preserves sequence.

Suppose a pump fails, an alarm fires and an operator changes a setting. If three devices disagree on time, investigators may see the response before the warning and the warning before the fault. Every log can be accurate on its own while the combined record remains false.

That’s the quiet danger. Bad time can turn good evidence into fiction.

What AI can see

Traditional timing systems distribute time and measure variance. They follow rules. They don’t always explain why a clock has started to wander or why packet delay changed after lunch.

AI can watch the behaviour around the clock.

Oscillators drift as temperature changes, components age and workloads shift. Networks add delay through congestion, routing changes and uneven paths. Those effects don’t always arrive as clean threshold breaches. They creep. A model trained on normal device behaviour may spot the curve before an operator sees the cliff.

Research has already explored clock architectures that account for thermal change and non-stationary delay variation in industrial networks. Other work has used deep learning to improve clock synchronization where propagation delays and frequency offsets make classic methods struggle.

The practical use is simple. AI can estimate when a device is moving outside tolerance, compare its behaviour with peer devices and suggest the likely cause.

It may notice that a clock loses accuracy only when a cabinet warms. It may connect rising offset with a new network path. It may flag a grandmaster change that looks valid in protocol terms but strange in context.

This matters because most alarms report symptoms. Operators need causes.

“The clock is wrong” starts a search.

“The clock began drifting after the switch update, and the pattern matches path asymmetry” starts a decision.

That’s a better use of machine learning. Not an oracle. A sharper witness.

From fixed rules to context

Many timing controls treat every device according to a fixed schedule. Synchronize at this interval. Alert at that threshold. Escalate after so many failures.

Fixed rules are useful because people can understand them. They also assume the system behaves tomorrow as it did when the rule was written.

Factories rarely honour that assumption.

A robotic cell under full load behaves differently from one at rest. A substation during a fault does not resemble a quiet Tuesday morning. A clock that stays stable for months may need less attention than one mounted beside a heat source and fed through a changing network path.

AI can help vary monitoring based on context. It can recommend closer checks for unstable assets and reduce needless traffic around devices that remain steady. It can compare clock offset, packet delay, temperature and process state without forcing each signal into a separate queue.

But the word “recommend” carries weight.

Changing a monitoring interval is one thing. Correcting the clock that governs a protection function is another. The first may save bandwidth. The second may change how physical equipment behaves.

You need a boundary between insight and authority.

Without it, a useful model becomes a hidden controller.

The security problem hiding in the timestamp

Attackers don’t need to stop a process if they can make the process misunderstand time.

A forged signal can shift timestamps. A delay attack can make a legitimate clock appear accurate while pushing dependent devices away from the true reference. GPS spoofing can corrupt systems that trust satellite time. Research on time attacks in power grids has shown effects on fault detection, voltage monitoring and event location. Work on PTP delay attacks has also shown how targeted path asymmetry can move clocks without easy detection.

AI may help detect these patterns. It can compare timing behaviour across paths, devices and physical states. A sudden offset may look different from thermal drift. A slow malicious delay may leave a different trail from congestion.

Yet AI also adds targets.

An attacker may poison the data used to train the model. They may alter timing telemetry, suppress alerts or feed the system enough false anomalies that operators stop listening. They may tamper with a model update and teach the detector that hostile behaviour is normal.

That last risk deserves attention. OT teams often fear the loud attack. The subtler attack edits the baseline.

Once the model learns the lie, silence looks healthy.

When probability meets determinism

This is where enthusiasm needs adult supervision.

A timing protocol performs a defined function. A model estimates. Those are different forms of machinery.

If the model predicts drift incorrectly, it may request needless corrections, mask a real fault or make stable clocks chase one another. If operators can’t explain why it acted, they may hesitate at the exact moment speed matters.

The answer isn’t to ban AI from timing. That would confuse caution with wisdom. The answer is to place it where uncertainty can help without governing the final truth.

Keep approved time sources, PTP, NTP, local clocks, holdover capability and redundant grandmasters at the core. Let AI sit around that core and observe. It can score health, spot anomalies, connect signals and propose action.

Then bind it.

Set hard tolerances that the model cannot rewrite. Require human approval before material timing changes. Record every recommendation and the evidence behind it. Make sure the model’s loss does not stop the plant from keeping time.

NIST’s OT security guidance stresses that controls must respect OT’s distinct performance, safety and availability needs. Its work on positioning, navigation and timing also calls for organizations to identify dependencies, detect manipulation and prepare to respond when timing services fail.

The principle is plain. The clock must keep working when the clever layer goes missing.

A sensible route into production

Start with the timing estate, not the model.

Map every grandmaster, reference source, protocol, dependent asset and fallback path. Ask which processes need milliseconds, which need microseconds and which merely need logs that agree. Many firms can name their critical servers faster than they can name the clock those servers trust.

That inventory often exposes an uncomfortable fact. The plant has several sources of time, but no owner for timing risk. Everyone consumes the clock. Nobody governs the dependency. That is how a technical detail becomes an enterprise blind spot.

Then choose a narrow use case.

Drift detection is a good opening move. So is anomaly detection across redundant time paths. Incident correlation can also create value without touching live clock control.

Run the model in observation mode. Let it watch, report and explain. Compare its calls with engineering judgement. Test it during temperature shifts, network congestion, GNSS loss, grandmaster failure and planned maintenance.

Don’t test only the model. Test the disagreement.

What happens when the protocol says healthy and the model says danger? Who decides? What evidence do they see? How quickly can they restore the known state?

Scale only after those questions have real answers.

The clock should never need faith

AI can make OT timing easier to see. It can reveal drift before thresholds break, connect weak signals and help investigators rebuild events with less guesswork. Used with care, it may give operators something they rarely receive from industrial clocks: an explanation.

But explanation must not become sovereignty.

The safest design keeps time deterministic and makes oversight richer. Protocols distribute the clock. Engineers define the limits. AI watches the edges, where heat, delay, ageing and attack begin to bend the truth.

That arrangement may sound less dramatic than handing the system control. Good. OT has enough drama already.

A clock is trusted because everyone agrees to organize action around it. Once machines lose that agreement, the plant may still look busy. Motors turn. Screens glow. Logs fill.

Yet beneath the motion, cause and effect have started to divorce.

AI may help keep them together.

It should never be allowed to officiate the clock.