How to transfer historian data from OT to IT
A step-by-step architecture for delivering trustworthy time-series data to enterprise analytics without exposing the operational historian.
From OT measurements to a trusted IT history
The pipeline preserves the source timestamp, quality and record identity from collection through delivery. OT remains protected below the one-way boundary; IT receives a new, replay-safe data stream above it.
- 1
Destination offlineIT writes stop; OT collection continues.
- 2
Queue growsPersistent storage retains approved records and raises capacity alarms.
- 3
Destination recoversIT-side delivery resumes without an inbound connection to OT.
- 4
Ordered replayDeterministic IDs prevent duplicates while historical gaps are reconciled.
1. Define the historian dataset
Start with tags, timestamps, quality values, required history and update frequency. Decide whether IT needs real-time values, periodic batches or both. Avoid replicating every available tag when only a governed subset supports the business objective.
Agree how late data, corrected values and time zones will be represented. These details determine whether analytics can trust the resulting dataset.
2. Collect inside the OT boundary
Place the collector close to the historian or industrial source. Use a supported read-only interface such as OPC UA, a historian API, database access or controlled file export. Do not allow enterprise consumers to query the production historian directly across zones.
The collector should map tag identities, retain source timestamps and preserve quality indicators before data crosses the security boundary.
- Read-only source integration
- Explicit tag allow-list
- Stable naming and timestamp rules
- Credential isolation
3. Buffer and cross the boundary
Persistent buffering protects the data stream when the IT destination is unavailable. For high-consequence environments, a data diode can carry the approved records across a hardware-enforced one-way link. Where bidirectional communication is required, use a tightly controlled conduit and terminate sessions on each side.
Monitor queue depth, oldest pending record, transfer rate and storage capacity so an outage becomes visible before retention is exhausted.
4. Deliver and reconcile in IT
The IT-side service writes to the enterprise historian, SQL database, message broker, files or API. Use idempotent delivery or deterministic keys to prevent duplicates during replay. Compare counts and time ranges so gaps can be detected automatically.
Test the complete recovery sequence: stop the destination, accumulate data, restore service and verify that history arrives in order without missing or duplicated records.
- Enterprise historian or SQL delivery
- Replay-safe writes
- Gap and freshness monitoring
- Documented recovery tests
Frequently asked questions
Can historian data cross a data diode?
Yes. Middleware packages time-series records into a one-way stream and delivers them through a separate IT-side session.
What happens when the IT historian is offline?
Persistent queues retain records and replay them after the destination recovers, subject to configured storage capacity.
Should timestamps be generated in IT?
Source timestamps should normally be preserved so the historical record reflects when the measurement occurred.
Apply the architecture to a real industrial data flow.
Start with one source, one destination and a measurable security or operations objective.