ISA-95 for Software Engineers

If you’re a software engineer entering robotics, IoT, or industrial automation, you’ll encounter ISA-95 — the international standard for manufacturing systems integration. It’s the equivalent of the OSI model but for factories. Understanding it helps you architect systems that fit into existing production environments without breaking decades of industrial best practices.

This article translates ISA-95 into software engineering terms, maps each layer to familiar concepts, and explains how data flows through the stack.

Why Software Engineers Should Care

ISA-95 defines the boundaries between business systems and production systems. If you’re building:

• Industrial IoT platforms (collecting sensor data from factory floors)
• Digital twin simulations (real-time models of production processes)
• Robotics control systems (coordinating multiple machines)
• Supply chain optimization tools (bridging ERP and MES)

…you’re working at the intersection of ISA-95 layers. Violating the standard doesn’t make your code fail, but it makes integration painful. A system that tries to send ERP data directly to PLCs bypasses the Manufacturing Execution System (MES) layer, breaking traceability and regulatory compliance.

The payoff for learning ISA-95: you can design systems that slot into existing infrastructure, speak the same language as plant engineers, and avoid reinventing data models that already have ISO standards.

The Purdue Model: Five Levels

ISA-95 is based on the Purdue Enterprise Reference Architecture, which divides manufacturing systems into five levels:

Let’s translate each level into software terms.

Level 4: Enterprise Resource Planning (ERP)

What it does: Business-level planning. Order management, inventory forecasting, financial accounting, supply chain logistics. In software terms, this is your product roadmap and analytics dashboard. It knows what to build but not how to build it.

Examples: SAP, Oracle ERP, Microsoft Dynamics

Time horizon: Days to months. “We need to produce 10,000 units next quarter.”

Data it produces: Production orders (make 500 units of SKU X), material requirements (order 2 tons of raw material Y), shipment schedules.

Data it consumes: Actual production counts (did we make 500 units?), quality metrics (defect rate), equipment uptime.

Software analogy: Product management platform. The ERP is like Jira + Looker — it tracks high-level goals and measures outcomes but doesn’t execute tasks itself.

Level 3: Manufacturing Execution System (MES)

What it does: Translates business orders into production tasks. Tracks work-in-progress, enforces quality procedures, collects genealogy data (which raw materials went into which finished goods), manages labor and downtime.

Examples: Rockwell FactoryTalk, Siemens Opcenter, Dassault DELMIA

Time horizon: Hours to shifts. “This batch needs to run at 180°C for 45 minutes, then cool for 20 minutes.”

Data it produces: Batch recipes (step-by-step production instructions), work instructions (which operator should do what task), quality checkpoints.

Data it consumes: Equipment status (is the oven ready?), lot traceability (which lot of raw material was used?), operator confirmations (did the QA check pass?).

Software analogy: CI/CD orchestration. The MES is like Jenkins + Airflow — it takes a high-level job (production order) and breaks it into discrete tasks with dependencies, retries, and validation gates.

Level 2: Supervisory Control and Data Acquisition (SCADA)

What it does: Real-time monitoring and control. Displays live dashboards (HMIs), logs process variables (temperature, pressure, flow rate), triggers alarms when values exceed thresholds. Operators interact with this layer to start/stop equipment and adjust parameters.

Examples: Wonderware, Ignition, GE iFIX

Time horizon: Seconds to minutes. “Tank temperature is 185°C, trending upward at 2°C/min.”

Data it produces: Alarm notifications (high-pressure warning), trend charts (temperature over last 8 hours), operator actions (setpoint changed from 180 to 175).

Data it consumes: Live sensor readings from PLCs, batch status from MES, equipment health metrics.

Software analogy: Infrastructure monitoring. SCADA is like Grafana + PagerDuty — real-time dashboards with alerting. It doesn’t make control decisions (that’s Level 1) but gives humans visibility and manual override capability.

Level 1: Programmable Logic Controllers (PLCs) and Distributed Control Systems (DCS)

What it does: Direct machine control. Reads sensors, executes control logic (if temperature > 190°C, turn off heater), operates actuators (open valve, start motor), enforces safety interlocks (don’t open door while laser is active).

Examples: Allen-Bradley CompactLogix, Siemens S7, ABB AC800M

Time horizon: Milliseconds to seconds. “Pressure is 5.1 bar; open relief valve.”

Data it produces: Real-time process variables (1000+ tags updating 10x/sec), discrete states (valve open/closed), alarm signals.

Data it consumes: Setpoints from SCADA (target temperature = 180°C), recipes from MES (sequence: step 1, wait for level > 50%, then step 2).

Software analogy: Device drivers + operating system. PLCs are low-level, deterministic, and directly interface with hardware. They’re like Linux kernel modules that manage GPIO pins and I2C buses — fast, reliable, no GUI.

Level 0: Physical Process

What it does: The actual hardware. Sensors (thermocouples, pressure transducers, proximity switches), actuators (motors, solenoids, pneumatic valves), and the physical process itself (chemical reactions, material flow, heat transfer).

Examples: Temperature sensor outputting 4-20mA signal, servo motor with encoder feedback, conveyor belt.

Time horizon: Continuous. Physics doesn’t have discrete time steps.

Data it produces: Analog signals (0-10V, 4-20mA), digital signals (24VDC on/off), encoder pulses.

Data it consumes: Control signals from PLCs (set motor speed to 1500 RPM, energize solenoid coil).

Software analogy: Bare metal. This is the RAM, CPU, and peripherals. No abstraction layer. You’re directly manipulating voltages and currents.

MESA-11: The 11 Core MES Functions

ISA-95 defines 11 functions that an MES should provide. Here’s the quick reference:

If you’re building an MES or integrating with one, these 11 functions define the interface contract. Your system doesn’t need to implement all 11 (some plants use separate CMMS for maintenance), but you should know which ones you’re targeting.

Key Data Flows

The magic of ISA-95 is standardized data flow. Each layer produces outputs for the layer below and consumes inputs from the layer above. Here are the critical flows:

Product Lifecycle Management (PLM) → ERP: Product designs, BOMs (bill of materials), engineering change orders. This isn’t in the Purdue Model (it’s a horizontal integration) but critical for manufacturing. PLM systems like Teamcenter or Windchill define what to build; ERP schedules when to build it.

ERP → MES: Production orders (“make 500 units of SKU X by Friday”), material allocations (“use lot ABC-123”), shipping deadlines. The MES doesn’t care about financials or supply chain contracts — it just needs to know the work scope.

MES → SCADA: Batch recipes (step-by-step procedures), quality checkpoints (measure pH at step 5), operator instructions (add reagent B when level reaches 75%). The MES plans the work; SCADA visualizes its execution.

SCADA → PLC: Setpoints (target temperature = 180°C), mode commands (start batch, pause, resume), alarm acknowledgments. The SCADA doesn’t implement control logic — it just tells the PLC what the operator wants.

PLC → Level 0: Analog outputs (set heater to 75% power), digital outputs (energize valve solenoid), variable-frequency drive commands (motor speed = 1500 RPM). The PLC translates abstract goals (maintain 180°C) into concrete hardware actions.

Level 0 → PLC: Sensor readings (temperature = 182.3°C, pressure = 5.1 bar), limit switch states (door closed), encoder counts (motor at 1498 RPM). Physics provides feedback; the PLC closes the control loop.

PLC → SCADA: Real-time process variables (1000+ tags), alarm states (high-pressure warning active), discrete events (batch started at timestamp X). SCADA aggregates this for human consumption.

SCADA → MES: Event logs (operator changed setpoint at 14:37), batch completion confirmations (batch X finished at 15:02), downtime reports (line stopped for 12 minutes due to E-stop). The MES uses this for traceability and KPI calculation.

MES → ERP: Actual production counts (made 487 units, 13 defects), material consumption (used 2.3 tons of raw material Y), labor hours (operator Z worked 8.5 hours). The ERP updates inventory, costing, and planning models.

The key principle: no layer jumping. The ERP doesn’t send commands directly to PLCs. The SCADA doesn’t write to the ERP database. Each layer has a well-defined interface to its neighbors.

Integration Standards

ISA-95 defines what data to exchange but not how. That’s where protocol standards come in:

OPC UA (Open Platform Communications Unified Architecture): The dominant standard for real-time data exchange between SCADA and PLCs. Supports both polling (SCADA requests data) and subscriptions (PLC pushes data when it changes). Think of it as gRPC for industrial automation — type-safe, bidirectional, and firewall-friendly.

MQTT (Message Queuing Telemetry Transport): Lightweight pub/sub protocol common in IIoT. Sensors publish to topics (e.g., factory/line3/temperature), cloud services subscribe. Good for high-latency networks and edge devices. Less common at Level 1-2 (SCADA/PLC) but ubiquitous at Level 3+ (MES/cloud).

ISA-95/B2MML: XML schemas for MES ↔ ERP integration. Defines message formats for production orders, batch reports, and material transactions. If you’re building an MES, you’ll implement B2MML endpoints to talk to SAP or Oracle.

MTConnect: Open standard for CNC machines and robotics. Provides a REST API for querying machine state (position, speed, tool life). Designed for Level 1-2 (control systems) with Level 3 (MES) as primary consumer.

Ethernet/IP and Profinet: Industrial Ethernet protocols for PLC-to-PLC and PLC-to-drive communication. Real-time, deterministic (microsecond jitter), and fieldbus-level. You won’t use these in typical software development unless you’re writing PLC firmware or industrial network drivers.

Modern Overlays

ISA-95 was published in 2000. How does it hold up in 2026?

Industrial IoT (IIoT): The Purdue Model assumes on-premise systems. IIoT adds a cloud layer above Level 4. Sensor data streams to AWS/Azure/GCP for ML and analytics. This doesn’t replace MES/SCADA — it augments them. The edge gateway sits at Level 2-3, aggregating data before cloud upload.

Edge computing: Instead of sending all sensor data to the cloud, run analytics on-premise (at Level 2-3). Example: predictive maintenance model running on an edge server, consuming PLC data and sending alerts to SCADA. Reduces latency and bandwidth costs.

Digital twin: A real-time simulation of the production process. The twin consumes data from Levels 0-2 (sensor readings, equipment state) and provides what-if analysis to MES/ERP. Example: “If we increase batch temperature by 5°C, yield improves 2% but energy cost rises 8%.”

AI/ML: Anomaly detection (is this sensor reading normal?), quality prediction (will this batch pass QC?), dynamic scheduling (reorder jobs to minimize changeover time). These models sit at Level 3-4, consuming aggregated data from MES/SCADA.

The insight: ISA-95 remains the backbone. Cloud and AI are additive layers, not replacements. You still need PLCs for real-time control and MES for traceability. The cloud is for scale-out analytics that don’t fit on-premise.

Common Mistakes

Mistake 1: ERP directly querying PLCs

The finance team wants real-time production data in their SAP dashboard. They write SQL queries that poll the PLC database every 5 seconds. This bypasses the MES, breaking genealogy tracking (which raw materials went into which finished goods). Fix: ERP queries MES; MES aggregates data from SCADA.

Mistake 2: SCADA making business decisions

An operator uses the SCADA HMI to override a batch recipe because “it’s faster this way.” This violates quality procedures (not documented in MES) and breaks traceability. Fix: Recipe changes must flow through MES, which enforces approval workflows and logs deviations.

Mistake 3: Cloud services polling PLCs

An ML team wants to train a model on sensor data. They write a Python script that queries the PLC every 100ms via Modbus. This saturates the PLC’s network stack, slowing down real-time control. Fix: Use an edge gateway at Level 2 to buffer and batch data before cloud upload.

Mistake 4: Over-privileged access

A developer needs to test an integration. They get admin credentials to the MES, SCADA, and PLC network. Now a typo in their script accidentally stops production. Fix: ISA-95 layers map to security zones. Level 4 (ERP) is corporate IT. Level 0-2 (PLCs/SCADA) is OT (operational technology). Never mix credentials.

Practical Example: Batch Production

Let’s trace a single production batch through the stack:

1. ERP (Level 4): Sales order arrives for 500 units of SKU X. ERP checks inventory, generates a production order, and sends it to MES.

2. MES (Level 3): Receives production order. Looks up batch recipe for SKU X (heat to 180°C for 45 min, cool to 50°C, package). Checks resource availability (is reactor R-201 free? is operator qualified?). Schedules batch for 10:00 AM.

3. SCADA (Level 2): At 10:00 AM, operator logs into HMI, sees batch B-12345 in their queue. Clicks “Start Batch.” SCADA sends start command to PLC with recipe parameters (setpoint = 180°C, duration = 45 min).

4. PLC (Level 1): Receives start command. Begins executing control logic: read temperature sensor (currently 25°C), calculate error (180 - 25 = 155°C), output 100% power to heater. Every 50ms, recalculate.

5. Level 0: Heater element receives 240VAC. Temperature rises. Thermocouple outputs 4-20mA signal proportional to temperature. PLC reads analog input via A/D converter.

6. PLC → SCADA: Every 1 second, PLC publishes current temperature (now 150°C) to OPC UA server. SCADA subscribes, updates trend chart on HMI.

7. SCADA → MES: At 45-minute mark, PLC signals “heating phase complete.” SCADA logs event with timestamp. MES records phase completion in batch genealogy.

8. MES → ERP: Batch finishes at 11:30 AM. MES calculates yield (487 units, 97.4%), logs which raw material lots were used, updates work-in-progress inventory. Sends batch completion report to ERP.

9. ERP: Updates finished goods inventory (+487 units SKU X), posts labor hours (1.5 hours operator time), updates sales order (500 units committed, 487 complete, 13 short).

Notice: no layer was skipped. The ERP never talked to the PLC. The SCADA never wrote to the ERP database. Each layer did its job and passed data to its neighbor.

Conclusion

ISA-95 is the blueprint for manufacturing systems integration. It defines five layers — ERP, MES, SCADA, PLC, and physical process — and standardizes data flows between them.

For software engineers:

• Level 4 (ERP) = product management platform
• Level 3 (MES) = CI/CD orchestration
• Level 2 (SCADA) = infrastructure monitoring
• Level 1 (PLC) = device drivers
• Level 0 = bare metal

The key principles:

• No layer jumping — each layer only talks to its neighbors
• MES is the bridge between business (ERP) and operations (SCADA/PLC)
• SCADA visualizes; PLCs control; ERP plans; MES executes
• Modern additions (IIoT, digital twin, ML) augment but don’t replace the stack

If you’re building industrial software, ISA-95 is your Rosetta Stone. Learn it, respect its boundaries, and your systems will integrate smoothly into production environments that have been running for decades.