Edge Computing for OT/IT Integration: Where Factory Data Should Be Processed
Industry Operations Note 5 of 6: edge, OT, and IT integration
Once a plant starts collecting equipment data, it needs to decide where that data will be processed and retained. Sending every raw signal to a central system is not always right, and neither is leaving every decision on a field device. Latency, response requirements, network conditions, retention needs, and access control should shape the split.
NIST describes edge computing as distributing processing resources between the data source and centralized services. An edge node can process, analyze, and act on data rather than merely forwarding it. The useful design therefore starts with the role of the data, not the device catalog.
Divide responsibility across three layers
Figure 1. Separate data generation, field processing, and operational systems while designing retention and access at the same time.
| Layer | Typical role | Design question |
|---|---|---|
| Equipment and sensors | Generate raw signals and operating context | Which asset and condition produced the data? |
| Field edge | Preprocess, make local decisions, buffer data | What must continue when connectivity is lost? |
| OT and IT systems | Support supervision, retain history, link maintenance records, and analyze trends | Who reviews the result and takes action? |
The same data can take different paths for different purposes. A field alert should stay close to the process that needs it. Long-term trends and maintenance history belong in systems that can connect records across assets. Decide separately whether a use case needs raw data, a summary, or only events.
Separate local decisions from central records
Edge processing can handle field data without waiting for a network round trip. It can also buffer data during an interruption and forward it after recovery. The design still needs rules for what is retained and how gaps or duplicates are identified.
Central systems are useful for comparing equipment history and connecting maintenance work. Choose whether to store only edge results or also retain raw signals according to the use case. Keeping all data indefinitely without a defined purpose increases cost and makes access harder to control.
Account for OT constraints
OT environments prioritize safety, reliability, and continuity of operation. Security updates and network changes need an impact review and a recovery method. At the same time, a closed network is not a reason to omit authentication, access logs, or change control.
Define the allowed data flows and management points between OT and IT. Keep an inventory of devices and services, identities and permissions, communication paths, change approvals, and recovery procedures. A new monitoring connection belongs inside the same control model.
Assign data ownership and retention
If the system loses the equipment identity behind a signal, the analysis cannot return to a useful field action. Keep the asset identifier, sensor position, collection time, processing version, and operating state together. Align time sources across edge and central systems so event order remains trustworthy.
Define what the operations, maintenance, and data teams may view, and specify who may change settings. Set retention by data type and purpose for raw signals, alerts, and maintenance records.
Architecture checklist
- Separate decisions needed in the field from analysis needed centrally.
- Decide whether each use case sends raw data, summaries, or events.
- Define behavior during network loss and data recovery after reconnection.
- Retain asset identity, sensor position, time, and processing version.
- Review communication paths and access rights across OT and IT.
- Assign owners for configuration changes and recovery.
- Set a purpose and retention rule for each data type.
For sites evaluating this architecture, XyloZero facility monitoring is one edge-to-PLC/SCADA implementation option. Start with a clear boundary between field processing and central records.