Skip to main content

ISA-95 and IIoT Integration: Bridging IT and OT in Modern Manufacturing

· 9 min read
MachineCDN Team
MachineCDN Team
Industrial IoT Experts

ISA-95 was created in the late 1990s to solve a simple problem: how should enterprise systems (ERP) communicate with plant floor systems (PLCs and SCADA)? Two decades later, IIoT platforms have disrupted the neat hierarchical model that ISA-95 defined. Data now flows from sensors directly to the cloud, bypassing every layer in between. The question for manufacturing engineers in 2026 isn't whether ISA-95 is still relevant — it's how to reconcile a framework built for hierarchical, on-premises architectures with the reality of cloud-native, edge-computing IIoT platforms.

What ISA-95 Actually Defines​

ISA-95 (formally ANSI/ISA-95 or IEC 62264 internationally) defines a hierarchical model for manufacturing operations with five levels:

Level 0: Physical Process​

The actual manufacturing process — motors turning, valves opening, conveyors moving, temperatures rising. Sensors and actuators that interact with the physical world.

Level 1: Sensing and Manipulation​

PLCs, RTUs, and intelligent sensors that read process data and execute control logic. This is where your Allen-Bradley, Siemens, and Mitsubishi controllers live.

Level 2: Monitoring and Supervision​

SCADA systems, HMI screens, and local historians that provide operator visibility and supervisory control. Wonderware, FactoryTalk, and WinCC operate here.

Level 3: Manufacturing Operations Management​

MES (Manufacturing Execution Systems), batch management, quality management, and production scheduling. This layer manages what happens on the plant floor — work orders, batch records, quality checks, material tracking.

Level 4: Enterprise Business Planning​

ERP systems (SAP, Oracle), supply chain management, financial planning, and customer order management. This is the business logic layer that doesn't care about individual PLC registers.

ISA-95 automation pyramid showing IT and OT integration layers in manufacturing

The Purdue Model Connection​

ISA-95's hierarchy aligns with the Purdue Enterprise Reference Architecture (PERA), which adds network segmentation between levels. The key concept: each level communicates primarily with the levels directly above and below it. Level 4 (ERP) never talks directly to Level 1 (PLCs). Data flows through the hierarchy.

This architecture served manufacturing well for 25 years. It provided clear security boundaries, defined data ownership, and created manageable integration points. But it also created bottlenecks, latency, and rigidity that modern manufacturing can't tolerate.

Where IIoT Breaks the ISA-95 Model​

IIoT platforms fundamentally challenge the hierarchical model by enabling direct communication between the plant floor and cloud analytics — effectively drawing a line from Level 0/1 straight to the cloud, skipping Levels 2, 3, and sometimes 4 entirely.

Direct Edge-to-Cloud Communication​

Modern IIoT platforms like MachineCDN place edge devices at Level 1 (connected directly to PLCs) and stream data to cloud-based analytics, dashboards, and AI engines. This bypasses the traditional SCADA (Level 2) and MES (Level 3) layers entirely.

The practical impact:

  • Data latency drops from minutes (traversing the hierarchy) to seconds (edge to cloud)
  • New analytics capabilities don't require changes to existing Level 2 and Level 3 systems
  • Multi-plant visibility happens automatically (no cross-plant MES integration needed)
  • AI and machine learning operate on raw machine data, not pre-aggregated summaries

The "Flattened" Architecture​

What IIoT actually creates is a flattened architecture where the hierarchy still exists for control purposes but data flows freely for analytics:

Control path (still hierarchical):

PLC → SCADA → MES → ERP (ISA-95 compliant)

Data/Analytics path (flattened):

PLC → Edge Device → Cloud Analytics/AI (IIoT)

Both paths coexist. The ISA-95 hierarchy remains valid for operational control. The IIoT path adds a parallel data channel optimized for analytics, monitoring, and predictive maintenance.

Smart factory with converged IT OT networks and industrial controllers connected to cloud analytics

Reconciling ISA-95 with IIoT: A Practical Framework​

Rather than abandoning ISA-95 or ignoring IIoT, pragmatic manufacturing engineers blend both approaches. Here's how:

Principle 1: Control Stays Hierarchical​

Never send control commands (setpoints, recipe parameters, safety interlocks) through the IIoT data path. The ISA-95 hierarchy exists for control for good reasons: deterministic response times, safety certification, and clear accountability.

Rule: IIoT reads data from the plant floor. It does not write to it. If your IIoT platform needs to adjust equipment operation, it does so by sending recommendations to operators or MES systems — not by writing directly to PLCs.

Principle 2: Data Flows Freely for Analytics​

Read-only data can and should flow directly from Level 1 to the cloud. There's no operational or safety reason to force analytics data through the SCADA-MES hierarchy. Doing so adds latency, complexity, and cost without benefit.

What this looks like:

  • PLC tag data streams to cloud dashboards in real time
  • Vibration, temperature, and pressure data feeds AI models directly
  • OEE calculations happen in the cloud using raw machine signals
  • Alarm data flows to centralized monitoring platforms

Principle 3: Network Security Follows the Purdue Model (With Updates)​

Even when data bypasses the ISA-95 hierarchy logically, network security should still maintain segmentation. IIoT edge devices connect to PLCs inside the Level 1 network but communicate outbound through secured channels:

  • Cellular connectivity (MachineCDN's approach) eliminates the need for plant network access entirely
  • DMZ architecture for IIoT data if using plant Ethernet — outbound-only connections, no inbound access from the cloud to the plant floor
  • Network segmentation between IIoT data traffic and control traffic

Principle 4: MES Integration, Not MES Replacement​

IIoT platforms complement MES systems — they don't replace them. MES owns production scheduling, work order management, batch records, and quality workflows. IIoT owns real-time equipment monitoring, predictive maintenance, and AI-powered analytics.

The integration point: IIoT platforms provide equipment health data that MES systems use for scheduling decisions. MES provides production context (what product is running, what recipe is active) that IIoT uses for analytics.

Principle 5: Unified Namespace as the Integration Layer​

The emerging best practice is the Unified Namespace (UNS) — a single, hierarchical topic structure (typically MQTT-based) that serves as the central data bus for all manufacturing data regardless of source:

enterprise/plant-01/area-packaging/line-03/machine-wrapper-01/
  ├── status (running, idle, faulted)
  ├── oee (availability, performance, quality)
  ├── vibration (X, Y, Z accelerometer data)
  ├── production (count, target, scrap)
  ├── energy (kWh, power factor)
  └── maintenance (PM schedule, health score)

The UNS doesn't replace ISA-95 — it provides the data infrastructure that makes ISA-95 concepts work in a connected, cloud-enabled world. We covered this in detail in our article on Unified Namespace for Manufacturing.

Common Anti-Patterns to Avoid​

Anti-Pattern 1: IIoT as Shadow IT​

Some plants deploy IIoT platforms without IT or OT governance, creating shadow systems that duplicate data, introduce security risks, and create maintenance nightmares. Always involve both IT and OT stakeholders in IIoT architecture decisions.

Anti-Pattern 2: Replacing SCADA with IIoT​

IIoT platforms excel at monitoring and analytics. They are not SCADA replacements. Operators need local HMI screens with sub-second response times for process control. Cloud-based dashboards with 2–5 second latency are fine for monitoring but inadequate for real-time control.

Anti-Pattern 3: Forcing Everything Through MES​

Some manufacturers try to route all IIoT data through existing MES systems, treating MES as the single source of truth. This overloads MES, adds latency, and limits the analytics that IIoT can perform. Let IIoT and MES operate in parallel with defined integration points.

ISA-95 framework showing data flow between MES, ERP, and plant floor systems

Anti-Pattern 4: Ignoring ISA-95 Entirely​

Going fully "flat" without any architectural framework creates integration chaos at scale. ISA-95's concepts of functional levels, information models, and interface definitions remain valuable even when the strict hierarchy is relaxed.

Security Implications of IIoT in an ISA-95 World​

The biggest concern manufacturing cybersecurity teams raise about IIoT is that it creates new attack vectors by connecting plant floor equipment to the internet. This concern is valid but manageable:

Outbound-Only Communication​

Properly designed IIoT platforms use outbound-only connections. Edge devices initiate connections to the cloud — no inbound connections from the internet reach the plant floor. This maintains the security properties of the Purdue Model's DMZ concept.

Cellular Isolation​

MachineCDN's cellular connectivity approach provides physical network isolation. The edge device connects to PLCs via the plant-side Ethernet port and communicates with the cloud via a cellular modem. There is no bridge between the two networks. Even if the cloud platform were compromised, there is no network path to the plant floor.

Read-Only Data Acquisition​

IIoT edge devices read data from PLCs — they don't write to them. This eliminates the most dangerous attack vector: an external actor sending control commands to manufacturing equipment.

Certificate-Based Authentication​

Enterprise IIoT platforms use mutual TLS with X.509 certificates, not username/password authentication. Each edge device has a unique device certificate. Compromising one device doesn't grant access to others.

Practical Implementation: Where to Start​

If you're navigating the ISA-95 + IIoT integration for the first time, here's a practical starting sequence:

Phase 1: Monitor (Non-Invasive)​

Deploy IIoT edge devices alongside your existing ISA-95 architecture. Read PLC data without modifying any existing systems. This gives you cloud-based monitoring and analytics without touching your SCADA, MES, or control systems.

Timeline: 1–5 weeks with MachineCDN Risk: Near zero — you're adding read-only visibility

Phase 2: Analyze (Add AI)​

Once data is flowing, enable predictive maintenance, OEE optimization, and equipment health scoring. Use IIoT insights to inform (not automate) maintenance and production decisions.

Timeline: 4–8 weeks Risk: Low — recommendations, not automated actions

Phase 3: Integrate (Connect to MES/ERP)​

Create defined integration points between your IIoT platform and existing Level 3/4 systems. Equipment health data flows into maintenance scheduling. Production analytics feed capacity planning. Energy data informs sustainability reporting.

Timeline: 2–6 months Risk: Moderate — requires IT/OT collaboration

Phase 4: Optimize (Closed-Loop)​

With confidence in IIoT data quality and analytics accuracy, enable closed-loop optimization: IIoT-recommended recipe adjustments, AI-optimized PM scheduling, and automated reporting to enterprise systems.

Timeline: 6–12 months Risk: Higher — requires validation and change management

The Bottom Line​

ISA-95 isn't dead. IIoT isn't replacing it. The reality is more nuanced: ISA-95 defines the control architecture, and IIoT adds a parallel data architecture optimized for analytics and intelligence. Plants that figure out how to run both in harmony — hierarchical control, flat data access — will outperform those stuck in either extreme.

The key insight: you don't need to rebuild your entire architecture to benefit from IIoT. Start with non-invasive monitoring, prove value, and expand deliberately.

Ready to add IIoT intelligence alongside your existing automation? Book a demo and see how MachineCDN deploys in minutes without disrupting your control systems.