The Root Cause Was Recorded. Just Not In The Same Place.

The evidence exists. It is simply scattered across systems that were never designed to share it.

---

A pump trips. Maintenance blames the PLC. Automation blames the network. IT blames SCADA. Operations blames maintenance. Everyone has data. Nobody has the timeline.

Industrial failures rarely have one source. The evidence already exists. It is simply scattered. One clue is inside the PLC. Another in SCADA. Another in switch logs. Another in the historian. Another in the instrument. Another in operator notes. Another in maintenance history.

Nobody correlates them.

Why Investigations Stall

Industrial investigations stall because teams look for the cause inside their own domain. The PLC engineer looks at PLC logs. The network engineer looks at switch logs. The SCADA engineer looks at historian trends. Each finds a piece of the story. None finds the full story.

Different systems have different timestamps. Different clocks. Different log formats. Different vendors. Different teams. Different responsibilities.

The PLC logs a fault at 14:03:12. The network logs a timeout at 14:03:15. The SCADA log shows a communication loss at 14:03:18. The historian shows a pressure spike at 14:03:20. The operator note records the alarm at 14:03:22.

The displayed timestamps suggested the PLC fault occurred first. Once clock offsets were corrected and the records aligned to a common time reference, the pressure spike was found to have preceded the network timeout.

Each system captured a piece of the event. Each system recorded it differently. Each system is trusted by its owner. The problem is that the evidence is scattered across silos that were never designed to share data.

Fragmented Operational Data

Common time. Common visibility. Common evidence. Not one better dashboard. One better timeline.

When the PLC log, network log, SCADA log, historian, operator note, and maintenance record are aligned, the sequence of events becomes clear. The pressure spike occurred before the timeout. The timeout occurred before the communication loss. The root cause is not the PLC, the network, or SCADA. It is the pressure spike that started everything.

The timeline reveals what the silos hide. The silos fragment the story. The timeline reconstructs it.

Where This Happens

The pattern repeats across manufacturing, utilities, rail and mining because the organisational structure is remarkably similar.

Manufacturing: A production line stops unexpectedly. The PLC logs a communication fault. The network switch logs a timeout. The SCADA historian shows a temperature spike. The operator log records a manual intervention. Each system captured a piece of the event. None captured the full story.

Utilities: A substation protection relay misoperates. The relay logs show a current differential fault. The merging unit logs show a timestamp error. The PTP grandmaster logs a holdover event. The SCADA alarm log shows a voltage dip. The engineer arrives after the evidence has vanished. The root cause is never found.

Designing Systems For Forensic Visibility

Forensic visibility is not a product. It is an architecture. It is designed, not added.

A deterministic network infrastructure such as Westermo provides hardware timestamping and consistent timestamps across devices, enabling accurate correlation of network events.

Alarm correlation platforms such as Micromedia ALERT provide the operational context that connects alarms from multiple systems into a single, traceable timeline of events.

Protocol gateways such as ProSoft Technology enable legacy devices to participate in the correlated timeline.

Visibility is not one product. Visibility is architecture. The architecture that correlates data across layers is the architecture that reveals root cause.

What You Can Do Now

Forensic visibility begins with asking the right questions during project design.

Specify common time. Require that all systems synchronise to a common time source. Document the time source, accuracy and fallback arrangements.

Require event retention. Specify that logs must survive restarts and power cycles. Define retention periods. Test retention behaviour during commissioning.

Test correlation. Simulate a cross-system event during commissioning. Can the architecture correlate the evidence? If not, the architecture has a gap.

Assign accountability. Ensure that someone owns forensic visibility. It is not a vendor responsibility. It is an architecture responsibility.

The Takeaway

Engineers don't lack data. They lack correlation.

Root causes are rarely invisible. They are usually fragmented. The evidence exists. It is simply scattered across systems that were never designed to share it.

When the evidence is correlated, the root cause becomes visible. When the evidence remains fragmented, the root cause remains hidden. The difference is not technology. It is architecture.

DESIGN FOR FORENSIC VISIBILITY

Throughput advises on forensic visibility architectures – aligning common time, event retention and correlation with proven industrial technologies.

Where is your next root cause hiding – and who has the piece you need?

---

You May Also Be Interested In ...

---