Cross-System Explainability
If an event crossed five systems today, could your architecture reconstruct one defensible sequence?
The PLC logged a fault. SCADA generated an alarm. The network recorded a timeout. The historian preserved a trend. The alarm system notified the operator. Every system passed. Every system did exactly what it was designed to do.
Yet the operation still cannot explain the event.
This is cross-system explainability. A system can explain itself. It takes skill to explain an event where evidence crosses multiple systems. Cross-system explainability is the ability of an architecture to preserve a coherent sequence of events across system boundaries.
Why Individual Compliance Is Not Enough
Each system performed exactly as specified. The PLC logged a fault. SCADA generated an alarm. The network recorded a timeout. The historian preserved a trend. The alarm system notified the operator.
Every system did exactly what it was supposed to do. Yet when the investigation began, the sequence of events could not be reconstructed. The PLC timestamp used one clock. The switch used another. The historian used a third. The operator logged the alarm at a different time. The maintenance record documented the repair in a separate system entirely.
The individual systems passed. The collective architecture failed.
The Gap Between Systems
The problem is not that any system was incorrect. The problem is that the architecture was never designed to preserve a coherent sequence of events across system boundaries.
The PLC may know what happened. The network may know what happened. The historian may know what happened. The alarm system may know what happened. But if the evidence is scattered across four different systems with four different timestamps, the operation has symptoms – not a root cause.
The boundary where systems meet and evidence fragments.
The Requirement That Never Existed
Nobody had the requirement: Can the commissioned architecture explain a cross-system event coherently?
This is not a criticism of vendors. Vendors can only be accountable for requirements they were given. The gap was not in the technology. It was in the project scope.
A requirement that specified common time across all systems would have changed the architecture from the start. A requirement for event retention across system boundaries would have changed logging configuration. A requirement for sequence reconstruction capability would have changed system selection, integration and testing.
What Cross-System Explainability Requires
Cross-system explainability requires three design elements that must be specified, designed and tested.
Proven Experience Across The Architecture
Cross-system explainability is not delivered by a single platform. It depends on whether the underlying architecture preserves time, context and evidence as an event moves between systems.
This is where specialist experience matters. Westermo has spent decades engineering communications infrastructure for operational environments where network behaviour, resilience and timing have real consequences. That experience provides an important foundation when the sequence of network events must be understood alongside the process they supported.
At the protocol boundary, ProSoft Technology brings extensive experience integrating industrial systems across different protocols and generations of automation. When part of the operational evidence remains inside a legacy controller or isolated protocol environment, the integration architecture determines whether that context remains available to the wider system.
Increasingly, correlation is also moving closer to the operation. Industrial edge platforms from specialists such as Welotec create the opportunity to process and contextualise operational data locally, before every raw event is pushed into a central system.
The technologies already exist. The engineering question is whether the architecture has been designed to make them work as one evidence chain.
What You Can Do Now
Cross-system explainability 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 sequence reconstruction. Simulate a cross-system event during commissioning. Can the architecture reconstruct the sequence? If not, the architecture has a gap.
Assign accountability. Ensure that someone owns cross-system explainability. It is not a vendor responsibility. It is an architecture responsibility.
The Takeaway
Individual system compliance does not guarantee cross-system explainability.
The requirement that was never written has become the most expensive requirement in the project.
Cross-system explainability must be designed into the architecture from the start. It cannot be added after the investigation begins.
DESIGN FOR CROSS-SYSTEM EXPLAINABILITY
Throughput advises on architectures that preserve cross-system explainability – aligning common time, event retention and sequence reconstruction with proven industrial technologies.
If an event crossed five systems today, could your architecture reconstruct one defensible sequence?