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.
Do not turn the broker into a historian, the historian into a semantic graph, or the AI agent into an integration platform.
Prepare data once and expose stable information contracts instead of recreating source integrations for every consumer.
The same equipment, work order, batch and material should be recognizable across live, historical and semantic systems.
Live state, historical analysis and transactional workflows do not need to travel through the architecture in exactly the same way.
AI can reason and coordinate, but permissions, policies, interlocks and high-risk execution should remain deterministic and enforceable.
Centralize models, schemas and rules while allowing each plant to connect to its actual brownfield environment.
The architecture is best understood as a set of connected capabilities rather than a strict linear pipeline. Some data moves through the real-time path, some through the historical path, and some is accessed directly through systems of record. The semantic and AI layers operate across those paths.
The diagram is deliberately not a single straight data pipeline. Applications may subscribe directly to the UNS. Analytics may query the datastore. Agents may use all three, live data, history and semantic context, through a governed access layer.
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.
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 capabilities 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