The Purdue Model — the hierarchical architecture that has structured industrial control systems for three decades — was designed for deterministic, isolated, hierarchical control. It is excellent at what it was built for. It is poorly suited to the data architecture that AI requires: high-frequency data access across levels, event-driven real-time processing, and the ability to feed AI models with context-rich, normalised data from multiple sources simultaneously.
Most industrial companies have the data their AI needs. The problem is that the data is trapped: in proprietary DCS historians, behind network architectures that do not allow cross-level communication, and in formats that differ between every vendor's platform. Getting that data to AI models — reliably, securely, and at sufficient frequency — is an architectural problem that precedes any AI algorithm selection.
Four principles address this problem systematically. They are not a prescription to replace existing OT systems — most legacy systems will remain in place for fifteen to twenty-five more years. They are a blueprint for the data and network layer that sits between OT systems and AI applications, enabling AI access without disrupting the deterministic control logic that keeps processes safe and stable.
Why Current OT Architecture Limits AI
Principle 1 — The "Data As-Is" Strategy: The DMK Lake
OT data is inherently messy. Tag naming conventions differ between every DCS and historian installation. Timestamps use different time zones, different resolutions, and different epoch references. Units of measurement are inconsistent. A temperature reading from one system is in Celsius with 1-second resolution; the same type of reading from a neighbouring system is in Kelvin sampled every 30 seconds.
The "Data As-Is" strategy deliberately avoids the temptation to fix this at the source — which would require modifying running production systems and creating extensive validation work. Instead, it captures raw data as it exists, then normalises it once in a unified "Data-Model-Knowledge (DMK) lake." The lake has three layers:
- Raw time-series store: All OT data is ingested and stored in its original format, with a source tag and timestamp. No transformation. This is the audit-complete record. Technologies: InfluxDB, Azure Data Explorer, OSIsoft PI, TimescaleDB.
- Context layer: The asset hierarchy — from the overall plant down to individual instruments — maps each raw data tag to its physical meaning. A tag named "FIC_101.PV" is annotated as "Feed flow controller 101, process variable, Distillation Column A." This context comes from the DCS configuration, the P&ID, and the CMMS Functional Location model.
- Knowledge layer: Relationships between assets are modelled — which pump feeds which vessel, which safety valve protects which line, which instruments affect which process parameters. AI models that need to understand the physical system query this layer for context.
Once the DMK lake exists, AI models consume data from a single, normalised source. Adding a new historian to the system requires only a new OPC-UA connection and source mapping — not a new custom integration for every downstream AI application.
Principle 2 — Event-Driven Interfaces for Real-Time AI
Traditional OT data integration relies on polling: system A asks system B "what is the current value?" at a fixed interval. If the interval is 60 seconds, the maximum freshness of the data is 60 seconds — and 99% of the polls return "same as before." This is fine for daily reports. It is not adequate for AI models that need to react to process anomalies in real time.
Event-driven architecture inverts the model: systems publish events when their state changes. Consumers subscribe to the events they care about and react immediately when an event arrives. There is no polling loop, no wasted bandwidth, and no artificial latency introduced by a polling interval.
For OT environments, event-driven integration using MQTT (for field devices) and OPC-UA PubSub (for DCS and SCADA systems) is the modern standard. When a sensor detects a condition that exceeds a threshold, it publishes an event to a message broker. The AI model subscribed to that topic receives the event within milliseconds, runs its analysis, and triggers the appropriate response — an alert, a work order, an operator notification, or a control signal — without any polling delay.
Principle 3 — Platform-Based OT Devices and Zero-Touch Provisioning
One of the most persistent security problems in OT environments is the device lifecycle: a controller or HMI is delivered from the manufacturer with default credentials, a specific firmware version, and a default network configuration. It is installed, given a static IP address, and configured manually by an engineer or integrator. The initial setup is rarely documented in enough detail to reproduce. Firmware updates require the same manual process. When the device reaches end-of-life, decommissioning is often not systematic — devices get disconnected from the physical process but remain connected to the network.
Platform-based OT devices change this model through "bare metal onboarding" and zero-touch provisioning:
- The device is powered on with no factory configuration loaded
- It contacts a secure provisioning server and authenticates using a hardware-based identity (TPM chip)
- The provisioning server delivers the operating system, application stack, configuration, and credentials over an encrypted channel
- The device comes online in a known, verified state — no default passwords, no undocumented configuration
This approach eliminates the most common source of initial OT device compromise (default credentials). It also enables rapid, repeatable deployment across multiple sites and simplifies patching — update the platform image centrally, redeploy to devices in the next maintenance window.
Principle 4 — Zero Trust and Microsegmentation
The traditional OT security perimeter — a firewall between IT and OT networks, with implicit trust inside the OT network — has two critical weaknesses in an AI-centric architecture. First, AI data pipelines require controlled, cross-boundary communication that a simple IT/OT firewall cannot easily accommodate without becoming a bottleneck. Second, the AI systems themselves — running on cloud infrastructure or enterprise servers — need to query OT data, creating new pathways that the old perimeter model was not designed to manage.
Zero Trust provides the framework: every user, every device, and every workload must be authenticated and authorised before accessing any resource, regardless of where it is on the network. Microsegmentation implements this at the network level: the OT network is divided into small, tightly defined zones with controlled, monitored conduits between them.
For AI data access, the DMZ is the key design element. The AI platform at the enterprise level queries the OPC-UA data gateway in the DMZ. The gateway proxies the query to the OT historian — the historian never receives a connection from the enterprise network directly. All queries are logged, filtered by protocol, and rate-limited. An AI model that needs real-time data gets it through this controlled channel; a compromised AI system cannot directly reach OT control systems even if it tries.
Building the Architecture in Stages
These four principles do not require a full OT transformation programme before the first AI model can run. A practical implementation sequence builds capability incrementally:
| Stage | What to Build | What You Enable | Typical Duration |
|---|---|---|---|
| 1 | OPC-UA / historian connection to a central data store (read-only, no OT network changes) | Single data source for first AI model; baseline for anomaly detection | 4–8 weeks |
| 2 | Context layer — tag-to-asset mapping, asset hierarchy | AI models can understand what each data point represents; search and query by asset | 4–12 weeks |
| 3 | Event-driven feeds for key assets (MQTT or OPC-UA PubSub) | Real-time AI response; anomaly detection with sub-second latency | 8–16 weeks |
| 4 | Network microsegmentation and OT DMZ | Secure, auditable AI data access; dramatically reduced attack surface | 12–24 weeks (with planned maintenance windows) |
| 5 | Zero Trust identity controls for all OT access | Vendor access controlled, all sessions recorded; full NIS2 Article 21 alignment | Ongoing programme |
Stage 1 can often be completed without any changes to running OT systems — only read-only connections to existing historians. This is the right starting point: gain data access, prove the AI use case, and then invest in the deeper architectural work with a validated business case behind it.
What These Principles Are Not
These architectural principles are not a case for making OT look like IT. The deterministic, validated, change-averse nature of OT control systems is not a flaw — it is a design requirement for safe industrial operation. A DCS running a refinery process column must behave predictably and safely at all times. Nothing in this architecture changes that.
The DMK lake, event-driven interfaces, platform-based provisioning, and zero-trust network model all operate above and around the OT control logic — enabling the data access and security posture that AI requires, without touching the control systems that cannot afford to be disrupted. The safety, reliability, and determinism of OT control remain fully intact. The architecture simply adds the data and security infrastructure that allows AI capabilities to run alongside it.