What is OT DataOps? Bringing Data Engineering to the Factory Floor

Why OT data projects stall before analytics

Consider a familiar manufacturing scenario. A data or AI initiative begins, but the source data arrives as tag names, values, quality states, and timestamps with little shared operational context.

The Data Scientists spin up their Jupyter Notebooks and connect to the factory's Data Lake, expecting to find beautifully structured datasets. Instead, they find this:

• Tag ID: 49021. Value: 43. Timestamp: 12:00:01
• Tag ID: DB4.DBX2.1. Value: TRUE. Timestamp: 12:00:02
• Tag ID: VIB_01A. Value: ERR_COMM. Timestamp: 12:00:03

What is 49021? Is 43 degrees Celsius or Fahrenheit? What time zone is the timestamp in?

Machine data is optimized for control and diagnostics, not automatically for enterprise analysis. Data teams therefore need equipment identity, units, quality, production state, and lineage before the data can support a dashboard, workflow, statistical model, or AI consumer.

This recurring preparation problem is the scope of OT DataOps.

Observed performance depends on workload shape, node capacity, and deployment design.

What is OT DataOps?

DataOps (Data Operations) is a concept originally born in the IT world. It focuses on automating the flow, quality, and delivery of data so that analytics teams can work faster.

OT DataOps (Operational Technology DataOps) applies those principles to industrial sources and operating constraints. It is the discipline of connecting assets such as PLCs, SCADA systems, meters, and machines; validating and contextualizing their data; and delivering governed live and historical context to approved consumers.

OT DataOps is not a separate Proxus product category. It is an operating discipline implemented within an industrial data platform: source ownership, modeling, quality, delivery contracts, monitoring, and change control are managed as one lifecycle.

The 4 Stages of the OT DataOps Pipeline

A mature OT DataOps strategy-powered by an industrial data platform like Proxus-automates four critical stages of data engineering:

Extraction (Connectivity)

You cannot analyze what you cannot connect to. A factory might have a new controller next to a decades-old serial device. OT DataOps begins with an edge data collection layer selected for the required protocols, polling behavior, tag volume, network zones, and source-system limits. Connectivity must be validated against the actual product edition and driver inventory.

Normalization and Contextualization

This is the most critical step. Raw data typically should be translated into human-readable information before it leaves the factory. Instead of sending DB4.DBX2.1 = 120, an OT DataOps engine transforms the payload:

{
 "asset": "Extruder_A",
 "location": "Plant_Berlin",
 "metric": "Temperature",
 "value": 120,
 "unit": "Celsius",
 "status": "Warning"
}

Now, when this payload hits the cloud, the Data Scientist immediately knows exactly what they are looking at.

Smart Filtering and Deadbanding

Cloud providers (like AWS or Azure) charge you for every gigabyte of data you upload (Ingress) and store. If a temperature sensor reports the same exact value (22.1°C) every 10 milliseconds, sending all of those duplicate records to the cloud is a massive waste of money. OT DataOps utilizes Smart Filtering technologies like Deadbanding (only sending data when the value changes by a certain percentage) or Time-based Aggregations (sending a 1-minute average instead of 60,000 raw millisecond points).

Delivery via Unified Namespace (UNS)

Finally, the clean, structured data is not dumped into a monolithic, unsearchable database. It is published to a central Unified Namespace (UNS). The UNS provides a governed operational model that authorized consumers can reuse. ERP, MES, BI, workflows, dashboards, and approved Model Context Protocol (MCP) clients may consume different contracts; the UNS does not remove source ownership, authorization, lineage, or reconciliation requirements.

Operational outcomes to evaluate

• Less repeated preparation: Shared identity, units, quality, and state models reduce duplicated mapping work when those models are governed and kept current.
• Controlled upstream volume: Deadbands, aggregation, and event selection can reduce transmitted data, but the result must be measured against signal dynamics and retention requirements.
• Reusable delivery contracts: Authorized consumers can reuse contextualized data without reconnecting directly to every control source.

Conclusion

Building a modern, data-driven enterprise on a foundation of disorganized PLC tags is highly inefficient.

OT DataOps is useful when multiple operational consumers need consistent, governed data and source-by-source preparation is becoming difficult to maintain. Some processing belongs at the edge, while shared governance, historical retention, and consumer delivery may span edge and central layers. To evaluate the complete product boundary, start with the Proxus Industrial Data Platform and map approved outbound flows through the IT/OT Bridge.

When this may not be suitable

• Lower-frequency telemetry may not justify full distributed complexity.
• Small single-line plants may prefer simpler architectures first.
• Strict legacy constraints may require phased adoption.
• Safety-critical closed-loop control should remain in PLC/Safety PLC layers.

Outcomes depend on workload profile, hardware capacity, and deployment topology.

Frequently Asked Questions

How is OT DataOps different from IT DataOps?

IT DataOps optimizes software-generated data pipelines (databases, APIs, logs). OT DataOps handles machine-generated data from physical sensors and PLCs - dealing with proprietary protocols, real-time constraints, and environments where network outages are common. The Store and Forward pattern, for example, is an OT-specific resilience mechanism that has no IT equivalent.

How much OT data should be retained or transmitted?

There is no universal percentage. The decision depends on process dynamics, investigation needs, alarm and event requirements, sampling behavior, regulatory retention, and the cost of losing detail. Validate smart filtering rules against representative signals before applying them broadly.

Do I need a separate OT DataOps team?

Not necessarily. In most organizations, the existing automation/controls team collaborates with IT data engineers. The key is a shared namespace design (UNS) and clear ownership of the Edge-to-Cloud pipeline.

References

1. DataOps Manifesto - Community-driven principles for agile data engineering that OT DataOps adapts to industrial environments. dataopsmanifesto.org
2. ISA-95 / IEC 62264 - Standard defining the enterprise-control data model that structures the OT DataOps pipeline.
3. Eclipse Sparkplug - Payload standardization framework for MQTT-based OT data normalization. sparkplug.eclipse.org

Explore the Proxus Industrial Data Platform →