A practical architecture for turning fragmented industrial data into trusted operational information, contextual intelligence and governed AI capabilities that can support people, applications and autonomous workflows across manufacturing.
Industrial Intelligence Architecture is a layered but interconnected set of capabilities for acquiring industrial data, contextualizing and distributing it, preserving history, representing operational meaning, and making those capabilities safely available to analytics, applications and AI agents.
Most plants already contain the information required for better decisions: process values in controllers and historians, production records in MES, quality events in QMS, maintenance history in CMMS, planning context in ERP and engineering knowledge in documents and models. The challenge is that those systems were built for different purposes and rarely present their information through one reusable operational architecture.
As manufacturers add enterprise analytics, machine learning and AI agents, the integration problem grows. Connecting every new application directly to every source system creates more point-to-point interfaces, duplicated transformations and inconsistent interpretations of the same operational reality.
What reusable capabilities should sit between industrial source systems and the applications, analytics and AI systems that need operational intelligence?
Industrial Intelligence Architecture answers that question by separating the major responsibilities, connectivity, data engineering, live distribution, history, semantics, intelligence and agent access, while making them work together through shared identities and governed interfaces.
The Industrial Intelligence Architecture brings together the capabilities required to turn operational data into information, intelligence and action. It is not a single technology stack or a prescribed flow of data, but a way of organizing the different responsibilities involved in building modern industrial data and AI systems.
At the foundation are the industrial operations and IT systems where operational information originates and actions are executed. These include machines, PLCs, DCS and SCADA systems, as well as MES, historians, laboratory systems, ERP and other plant and enterprise applications.
Above them, the industrial data infrastructure provides the common foundation for acquiring, contextualizing, distributing and persisting operational data. Connectivity, Industrial DataOps, the Unified Namespace and operational datastores each perform different roles within this layer.
The data intelligence and models layer turns that foundation into decision-ready information through operational analytics, models and reasoning services. Agentic AI for industrial operations builds on those capabilities by giving AI agents governed access to context, memory, tools and orchestration.
At the top are industrial applications, where these capabilities are applied to problems such as process optimization, root cause analysis, quality intelligence and production traceability.
The Semantic Data Layer spans the architecture rather than sitting in a single step of the pipeline. It provides shared meaning and relationships across operational data, analytical models and AI systems so that the same equipment, processes, materials and production activities can be understood consistently throughout the stack.
The layers are therefore connected, but they should not be interpreted as a rigid sequence through which every piece of data must travel. Applications may consume live information directly from the Unified Namespace, analytics may work primarily with historical data, and AI agents may combine live state, history, analytical outputs and semantic context depending on the task.
Each capability has a specific role. Products may combine several of them, but keeping the responsibilities conceptually separate makes the overall architecture easier to design and govern.
Protocols, drivers and interfaces for acquiring data from controllers, SCADA, DCS, historians, databases and plant IT systems.
Contextualize, transform, validate, model and route industrial data into trusted operational information.
Provide a discoverable, event-driven interface to current operational state and meaningful events.
Persist time-series, states, events and operational entities for historical queries and evidence.
KPIs, analytics, anomaly detection, root-cause analysis, optimization and other derived intelligence.
Semantic models, ontologies and knowledge graphs that connect entities across operational domains.
Identity, policy and tool interfaces for live data, historical queries, semantics and approved actions.
Agents use models and governed tools to investigate, recommend, orchestrate workflows and perform bounded actions.
Language, vision, time-series, multimodal and specialized models that agents and applications can invoke.
Dashboards, copilots, engineering tools, maintenance workflows, planning applications and autonomous services.
Industrial intelligence begins with access to source data. Connectivity includes the protocols, drivers and interfaces required to communicate with PLCs, OPC UA servers, SCADA systems, DCS platforms, historians, relational databases, MES, CMMS and other plant or enterprise systems.
Connectivity is necessary, but it is not enough. A successfully retrieved tag can still be cryptic, uncontextualized or inconsistent with equivalent data from another plant. That is why the architecture separates connectivity from DataOps.
Industrial DataOps sits between heterogeneous source systems and reusable downstream interfaces. It resolves identities, attaches plant and production context, normalizes structures and engineering units, applies common models, validates the result and routes information to the destination that needs it.
DataOps prevents each application from having to understand local tag names, proprietary database structures and plant-specific integration logic.
The Unified Namespace provides a shared real-time interface through which systems publish and discover current operational information. MQTT is commonly used because its publish/subscribe model decouples producers from consumers and allows applications to react to change as it happens.
The UNS is where consumers can discover information such as equipment state, current KPIs, active production context and meaningful events such as WorkOrderActivated, BatchStarted or QualityHoldPlaced.
The UNS is the live operational backbone. It is not the historian, enterprise lakehouse, transaction engine or complete semantic model of the factory.
Real-time information becomes much more useful when it can be compared with what happened before. The Operational Datastore persists contextual operational history: measurements, state transitions, production events, batches, work orders, equipment definitions and other records needed for traceability and analysis.
Time-series platforms, relational databases, historians and hybrid approaches can all play this role. The important design principle is that historical workloads have a durable, queryable home rather than forcing consumers to reconstruct history from the live message layer.
Once operational information is trusted and contextualized, the architecture can support analytics that go beyond simply displaying raw values. This is where data becomes operational intelligence.
Calculate throughput, availability, quality, cycle time and other operational measures consistently.
Combine process history, states and events to understand why performance changed.
Use statistical and machine-learning models to detect abnormal behavior and emerging risk.
Identify settings, schedules and operating conditions associated with better outcomes.
Compare equivalent assets, products and production lines across sites using shared models.
Analyze measurements together with the batch, work order, product and equipment state that produced them.
The Semantic Data Layer gives software and AI a structured representation of what operational entities are and how they relate. It combines shared semantic models, machine-readable ontologies and knowledge graphs populated with real operational entities.
Shared identifiers connect those semantic relationships to live UNS messages, historical data and system-of-record records without copying every data point into the graph.
AI agents should not receive unrestricted direct connections to PLCs, brokers, databases and enterprise applications. The AI Agent Access Layer turns the underlying architecture into narrow, governed capabilities that an agent can safely invoke.
This layer handles identity, permissions, tool contracts, data scoping, audit and policy enforcement, keeping the model's reasoning separate from the complexity and risk of direct system integration.
Industrial AI agents combine foundational models with governed data and tools so they can pursue multi-step goals. An agent might receive a production event, resolve the affected entities, traverse semantic relationships, retrieve live and historical evidence, compare with previous runs, and recommend the next action.
The agent layer relies on models with different strengths. Large language models can reason over instructions and natural language. Vision models can interpret images. Time-series or anomaly models can identify process patterns. Multimodal models can combine several forms of operational evidence.
Planning, reasoning, explanation, tool selection and interaction with people.
Inspect images, video, diagrams, screens and other non-tabular evidence.
Anomaly detection, forecasting, classification and equipment-specific analytics.
The architecture should allow the right model to be used for the right subtask rather than assuming one general-purpose model should solve every industrial problem.
Applications consume the shared capabilities beneath them. Some are conventional deterministic applications; others embed AI agents. The architecture should support both.
Consume current state and events from the UNS together with derived KPIs.
Use historical data, semantic context and models for investigations and optimization.
Allow people to query operational information through natural language and guided workflows.
Combine live condition, history, asset context and work-management workflows.
Connect scheduling, work orders, material, equipment and process conditions.
Use agents to coordinate predefined low-risk actions under explicit policy.
One of the most important architectural ideas is that industrial data does not need to flow through every layer before it becomes useful. The destination and workload determine the path.
Source → DataOps → Unified Namespace → dashboards, workflows and agents that need to react as conditions change.
Source or UNS → DataOps → historian or operational datastore → analytics, ML, root-cause analysis and agent evidence.
ERP, MES, QMS, CMMS and other transactional systems retain authoritative records and expose approved business operations.
The Unified Namespace does not need to carry every historical dataset, and the operational datastore does not need to become the transaction engine. The layers cooperate without absorbing one another's responsibilities.
| Capability | Owns | Should not become |
|---|---|---|
| Connectivity | Protocols, drivers and data access. | The enterprise information model. |
| DataOps | Context, transformation, validation and routing. | A duplicate system of record. |
| Unified Namespace | Live state, events, discovery and pub/sub distribution. | The historian, lakehouse or universal transaction bus. |
| Operational Datastore | Historical operational evidence and queryable context. | The live pub/sub backbone. |
| Semantic Data Layer | Meaning, identities, classes and relationships. | The high-frequency time-series store. |
| Agent Access Layer | Governed data and action capabilities for AI. | An unrestricted infrastructure gateway. |
| AI Agents | Reasoning, planning, tool use and coordination. | The source of operational truth or safety logic. |
Some capabilities are not separate boxes in the architecture because they apply everywhere. Security, identity, governance, observability and lifecycle management form a cross-cutting control plane.
Large manufacturers rarely have identical technology stacks across sites. The scalable pattern is to standardize what the enterprise expects to receive while allowing each plant to implement the mappings needed for its local environment.
This lets plants retain appropriate local autonomy while the enterprise gains common identities, models and contracts that make analytics, semantic integration and AI reusable across locations.
Consider an agent asked to investigate why a production line is running below target. The architecture gives it a disciplined path from question to evidence.
The agent is useful because the architecture underneath it has already made the plant discoverable and queryable through trusted interfaces.
Connectivity → DataOps → UNS → Datastore → KPI analytics → dashboards.
DataOps → historical store → condition models → semantic asset context → maintenance workflow.
Datastore + Semantic Layer + operational events + analytical models.
Connectivity → DataOps → UNS → MES, with shared persistence and reuse by other applications.
UNS + Datastore + Semantic Layer → Agent Access → Agent and orchestration.
Multi-site DataOps + common models → historical platform → analytics and ML → applications and agents.
That is why the architecture should not be implemented as a giant platform program before any use case begins. Each use case should establish and reuse the capabilities it actually needs.
No broker, historian, lakehouse, graph database or AI platform is naturally optimized for every workload in the architecture.
The UNS is a critical real-time layer, but history, semantics, transactions and AI access remain separate concerns.
AI needs identity, context, quality, semantics and provenance, not simply more tags in a cloud store.
Every new application becomes another custom integration if the data foundation remains source-specific.
Use shared identity and governed APIs to connect systems without turning every layer into a duplicate data lake.
Plants can remain heterogeneous as long as the enterprise models, identities and interfaces are consistent.
Expose bounded tools and retain deterministic safety, authorization and workflow controls outside the model.
Prove reusable patterns with one site and one use case, then deliberately parameterize and govern them for reuse.
You do not need all ten components before delivering value. The architecture should grow through use cases while deliberately establishing reusable patterns underneath them.
Connect one production area, contextualize the required data and establish stable identities and models.
Publish selected live state and events through the UNS and connect the first operational consumers.
Persist contextual history and build repeatable analytics, KPIs and investigation workflows.
Add the semantic layer where cross-domain relationships, flexible discovery or AI grounding require it.
Expose governed live, historical and semantic tools through an AI Agent Access Layer.
Introduce agents first as investigative copilots, then expand into approved and bounded operational workflows.
Move models, schemas, namespace rules, ontology patterns and DataOps templates into enterprise governance while sites retain local mappings.
This page provides the umbrella architecture. The pillar guides below go deeper into the capabilities that make it work.
The leading IIoT & AI educational platform for digital manufacturing teams