A data diode allows industrial data to leave a protected OT network while preventing anything from returning. That one-way design provides strong isolation, but it also removes the feedback normally used to confirm delivery, detect outages, and recover missing data.
The key question is if the sending system cannot receive an acknowledgement, how does it know the data arrived? With a true hardware data diode, it does not.
DataHub tunnel and mirroring can preserve protocol semantics, namespaces, and the latest value, timestamp, and quality on the receiving side. However, preserving an accurate current state is not the same as guaranteeing that every intermediate update arrived.
Approximate Reliability Ranking
The following configurations are ranked from highest to lowest reliability:
How does this effect the Store and Forward Feature
In a normal bidirectional network, store-and-forward can detect a failed connection, store data locally, detect when communication returns, and backfill from the correct point. A data diode breaks that feedback loop. With a diode, the sending DataHub cannot determine:
The local historian can retain the data, and the transmission point can be manually moved back to a time before the outage. However, that replay may resend records that were already received because the sending side cannot know exactly where the loss began. The destination must therefore be able to tolerate duplicates.
Store-and-forward can preserve a recoverable local history, but it cannot guarantee automatic, lossless, duplicate-free recovery through a true data diode.
What End Users and System Integrators Must Decide
Before finalizing the architecture, confirm:
A hardware data diode may provide the strongest one-way isolation, but that security comes with reduced delivery visibility and limited recovery options. That tradeoff should be designed into the architecture, not discovered after deployment.