Edge Computing for OT/IT Integration: Where Factory Data Should Be Processed
Industry Operations Note 5 of 6: edge, OT, and IT integration
Send every raw signal to a central system, or leave every decision on a field device? Neither extreme holds up for long. Latency and response requirements, network conditions, retention needs, and access control decide where each kind of data should be processed and kept.
NIST describes edge computing as placing processing resources between the data source and centralized services. An edge node can process, analyze, and act on data rather than merely forward it. So the useful starting point is not the device catalog but the role the edge will play.
Three layers, three different jobs
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 travel different paths for different purposes. An alert the field team needs now should stay close to the process; long-term trends and maintenance history belong where records connect across assets. Whether a use case needs raw data, a summary, or only events is a separate call each time.
What must survive a network outage
Edge processing does not wait for a network round trip, and it can buffer data through an interruption and forward it after recovery. That behavior is only trustworthy with rules behind it: what gets retained, for how long, and how gaps and duplicates are found.
Connecting history across assets and linking maintenance work is what central systems are for. Store only edge results, or raw signals too? Retain each for how long? Decide by use, because keeping everything indefinitely raises cost and makes access harder to control.
A closed network is not a security plan
OT environments put safety, reliability, and continuous operation first. That is why a security update or a network change gets an impact review and a recovery plan before it goes in. It is not a reason to skip authentication, access logs, or change control behind the phrase "closed network."
Define which data crosses between OT and IT and who manages the connection. The inventory of devices and services, identities and permissions, communication paths, change approvals, and recovery procedures belongs in one control model. A new monitoring connection gets no exception.
Keep the asset identity attached
A signal that loses its source equipment cannot lead back to a field action. Keep the asset identifier, sensor position, collection time, processing version, and operating state together, and align clocks between edge and central systems so event order stays trustworthy.
Access and retention are part of the same design. Define what the operations, maintenance, and data teams may view and who may change settings, then set retention for raw signals, alerts, and maintenance records by type and purpose.
Decisions to make before picking hardware
- The boundary between decisions made in the field and analysis done centrally
- Whether each use case ships raw data, summaries, or events
- What keeps working through a network loss, and how gaps and duplicates are reconciled after recovery
- The rule that keeps asset identity, sensor position, time, and processing version attached
- Communication paths and access rights across OT and IT, with owners for changes and recovery
- A purpose and retention period for each data type
Once that boundary is drawn, tool selection gets simpler. XyloZero facility monitoring processes acoustic, vibration, and environmental signals at the field gateway and hands results to existing PLC and SCADA systems, a design that assumes exactly this split between field processing and central records.