ISA-95 Explained: The Levels, Models, and MES Integration
ISA-95 explained — the automation hierarchy levels (0-4), the functional and object models, ISA-95 vs the Purdue model, and how it frames MES/ERP integration.
ISA-95 is the international standard that defines how enterprise systems (ERP) and manufacturing control systems (MES, SCADA, PLCs) communicate, what data they exchange, and how the automation hierarchy is structured. If you work at Level 1 or Level 2 — writing PLC code, building SCADA screens, or commissioning field devices — ISA-95 is the framework that places your work in context and specifies exactly where your data goes next.
This guide covers the five levels of the ISA-95 hierarchy, the functional and object models, how ISA-95 relates to the Purdue model, and what the standard means in practice when a MES needs production data from your PLC.
What Is ISA-95?
ISA-95 (formally ANSI/ISA-95, also published as IEC 62264) is a multi-part standard developed by the International Society of Automation (ISA) to define a common language for integrating enterprise resource planning (ERP) systems with manufacturing operations management systems and the plant-floor control systems beneath them.
The standard was first published in 2000 and has grown to six parts. Its goals are:
- Reduce integration cost and risk by defining standard data models and interface content between business and production systems.
- Establish a common vocabulary so vendors, integrators, and end-users mean the same thing when they say "work order," "production schedule," or "material lot."
- Define the boundary — the Level 3/Level 4 interface — across which ERP and MES exchange information.
ISA-95 does not prescribe software architecture, communication protocols, or technology choices. It is a conceptual and data-model standard, not a wiring diagram. The technology choices — OPC UA, REST APIs, message brokers — are made by implementers. The data structures and information flows the standard defines are expressed in the Business to Manufacturing Markup Language (B2MML), an XML schema set that implements the ISA-95 object models.
The Five Levels of the ISA-95 Hierarchy
The hierarchy model is the most-cited part of ISA-95. It defines five levels (0 through 4), each with a distinct function and characteristic response time.
| Level | Name | Typical Systems | Time Horizon |
|---|---|---|---|
| 0 | Physical Process | Field devices, actuators, sensors | Milliseconds |
| 1 | Sensing & Manipulation | I/O modules, transmitters, drives | Milliseconds to seconds |
| 2 | Control | PLCs, DCS, SCADA, HMI | Seconds to minutes |
| 3 | Manufacturing Operations Management | MES, MOM, LIMS, historian | Hours to shifts |
| 4 | Business Planning & Logistics | ERP, supply chain, financials | Days to months |
Level 0 — The Physical Process
Level 0 is the actual process being controlled: the temperature of a reactor, the position of a valve, the speed of a conveyor. No programmable system lives at Level 0 — it is the physical world that every other level exists to monitor and influence.
Level 1 — Sensing and Manipulation
Level 1 comprises the field devices that observe Level 0 (sensors, transmitters, encoders, flow meters) and the final control elements that act on it (variable-frequency drives, solenoid valves, servo drives). In a modern installation these devices communicate over field buses such as PROFIBUS, PROFINET, EtherNet/IP, or IO-Link.
Level 2 — Control (Where PLCs and SCADA Live)
Level 2 is the domain of the controls engineer. PLCs, DCS controllers, safety systems (SIS/SIL), SCADA servers, and HMI stations all operate at this level. Control logic executes in real time — scan cycles of 1 ms to 100 ms are typical — and the scope is a single process unit, machine, or production line.
SCADA fits squarely at Level 2: it aggregates data from multiple PLCs, provides operator visibility, and manages alarms. For a deeper look at designing that layer well, see the SCADA best practices complete guide.
Level 2 systems are the primary data producers in the ISA-95 hierarchy. Every piece of information that rises through Level 3 to Level 4 originates here, from actual production counts and equipment states to quality measurements and alarm events.
Level 3 — Manufacturing Operations Management (MES)
Level 3 translates between the real-time world of Level 2 and the business world of Level 4. The systems that operate here — Manufacturing Execution Systems (MES), Manufacturing Operations Management (MOM) platforms, Laboratory Information Management Systems (LIMS), and production historians — work on a time horizon of minutes to shifts.
Core Level 3 functions include:
- Production dispatching — releasing work orders to the shop floor, sequencing jobs, allocating equipment.
- Performance analysis — computing OEE, yield, cycle time, and scrap from data collected from Level 2.
- Quality management — recording in-process quality checks, linking test results to material lots, triggering holds.
- Material tracking — tracing material genealogy from raw input through finished goods.
- Maintenance management — logging equipment events, scheduling preventive maintenance, recording corrective actions.
For a side-by-side breakdown of how MES and ERP responsibilities divide, the MES vs ERP guide covers the boundary in detail.
Level 4 — Business Planning (ERP)
Level 4 is the domain of enterprise software: ERP platforms, supply chain management, customer order management, and financial systems. Decisions made here — what to produce, in what quantity, by what date — drive work orders down to Level 3, which in turn dispatches production jobs to Level 2.
Level 4 systems do not communicate directly with PLCs. The information they need (actual production quantities, quality dispositions, material consumption) arrives aggregated and contextualized from Level 3.
The Functional Hierarchy and Timeframes
The ISA-95 functional hierarchy describes not just what lives at each level but how frequently decisions are made and executed at each level.
- Level 0–1: Continuous, real-time. Sensor readings and control outputs change in milliseconds. There is no concept of a "batch" or "shift" at this level.
- Level 2: Event- and time-driven. A PLC responds to an input change within its scan cycle. A SCADA alarm fires within seconds of the condition arising.
- Level 3: Shift-driven or event-driven at a production-order granularity. A MES might update production KPIs every minute, but it operates on the concept of a work order that has a start time and an end time measured in hours.
- Level 4: Day- and week-driven. An ERP production plan may be revised daily or weekly based on demand signals. The ERP does not care about individual scan cycles.
This mismatch in time horizons is one of the reasons the Level 3/Level 4 boundary matters. A naive integration that pushed raw PLC tag data directly into an ERP would produce millions of records per day that the business system cannot interpret or use. Level 3 exists to aggregate, contextualize, and translate that data into business-meaningful events.
The ISA-95 Object Models and B2MML
ISA-95 Parts 2 and 4 define the object models — the data structures used to represent production resources and to exchange information across the Level 3/Level 4 boundary.
Core Object Categories
Production resources — the things that make products:
- Personnel — individuals and their qualifications, shifts, and assignments.
- Equipment — physical assets organized into an equipment hierarchy (enterprise → site → area → work center → work unit).
- Material — raw materials, intermediates, and finished goods, described with material definitions and lots.
- Process segments — named steps in a production process and the resources they require.
Production information — the exchanges that cross the Level 3/Level 4 boundary:
- Production schedule — what ERP sends down to Level 3: which products, which quantities, in which time windows.
- Production performance — what MES sends up to Level 4: actual output, scrap, cycle times, resource consumption.
- Product definition — the bill of materials, routing, and process parameters that define how a product is made.
- Work masters / work definitions — the Level 3 representation of process instructions.
B2MML — Business to Manufacturing Markup Language
B2MML is the XML schema implementation of the ISA-95 object models. Maintained by the World Batch Forum (WBF, now part of MESA International), B2MML provides ready-to-use XML schema definitions for every ISA-95 information category.
In practice, a MES vendor who says "we support ISA-95" typically means their system can publish and consume B2MML-formatted messages for production schedules, work orders, and performance responses. An ERP integration that exchanges B2MML XML — whether over a message bus, REST endpoint, or file drop — is implementing the ISA-95 data model.
B2MML is not the only way to implement ISA-95. Some integrations represent the same object model in JSON, in OPC UA information models, or in proprietary database schemas. What makes them ISA-95 compliant is adherence to the data structure and semantics, not the wire format.
ISA-95 vs the Purdue Model
ISA-95 and the Purdue Reference Model are frequently mentioned together and are often confused. They are related but distinct.
| Purdue Reference Model | ISA-95 | |
|---|---|---|
| Origin | Theodore Williams / Purdue University, 1990s | ISA / IEC, 2000–present |
| Focus | Network segmentation and security zones | Enterprise-control integration and data models |
| Levels | Same 0–4 numbering (sometimes adds Level 3.5) | Levels 0–4 with defined functions |
| Use case | Network architecture, OT/IT security | MES/ERP integration, data exchange |
| Normative? | Reference model (informal) | Published standard (ANSI/IEC) |
The Purdue model was originally a network architecture model used to segment OT networks into security zones — it describes which systems should be able to talk to which other systems at a network level. ISA-95 uses a similar five-level numbering but focuses on what information flows between levels and how it is structured.
In practical terms: a network architect uses the Purdue model to design DMZ zones and firewall rules. An integration architect uses ISA-95 to define what a MES work order looks like and what production performance data the ERP should receive. They are complementary frameworks that happen to share a level numbering convention.
The Purdue model explained article covers the network-security perspective in detail.
A more modern architectural approach — the unified namespace — flattens the ISA-95 hierarchy by making all data available in a single semantic namespace regardless of level origin. See unified namespace explained for how that compares to the traditional ISA-95 integration model.
Why ISA-95 Matters for MES/ERP Integration
The Level 3/Level 4 boundary is where ISA-95 delivers its most concrete value. Without a standard, every MES-to-ERP integration is a custom project: bespoke data mappings, one-off API contracts, and integration logic that breaks every time either system is upgraded.
ISA-95 defines:
- What information must flow downward (production schedules, product definitions, work masters) so the MES knows what to produce and how.
- What information must flow upward (production performance, actual material consumption, quality results) so the ERP can close production orders and update inventory.
- The data structures for each exchange through the object models and B2MML schema.
- The vocabulary both sides use — "work order," "production response," "material lot" — so business analysts, MES configurators, and ERP consultants can write functional specifications that both sides understand.
The Information Flow in Practice
A simplified ISA-95 Level 3/Level 4 information cycle looks like this:
- ERP creates a production schedule (demand-driven, time-bounded) and sends it to the MES.
- MES converts schedule entries into work orders and dispatches them to the shop floor (Level 2).
- PLCs and SCADA execute the production and report status events (cycle complete, quantity produced, quality check result) back to the MES.
- MES aggregates the Level 2 data into a production performance response and sends it back to the ERP.
- ERP closes the production order, updates inventory, and records actual costs.
The controls engineer's work — writing PLC ladder logic, configuring SCADA historian tags, setting up OPC UA server nodes — is what makes Step 3 possible. The quality of that data (accuracy, latency, completeness) determines how well the entire ISA-95 information cycle performs.
The Controls Engineer's Place in ISA-95
Most controls engineers work entirely within Levels 1 and 2. Understanding ISA-95 matters for three practical reasons:
1. Designing the right data at the source. A MES that needs to track production quantities, downtime events, and quality measurements will only get that data if the PLC program and SCADA historian are configured to produce it. Knowing what Level 3 needs — the ISA-95 object model for production performance — helps you instrument the right signals from the start rather than retrofitting tags later.
2. Equipment hierarchy alignment. ISA-95 defines equipment as a hierarchy: enterprise → site → area → work center → work unit. When you name PLC programs, SCADA areas, and historian tag paths, aligning those names to the ISA-95 equipment hierarchy makes MES configuration significantly easier. A tag path like Site1/Area2/Line3/Cell4/CycleCount maps cleanly to an ISA-95 work unit. An arbitrary tag path like PLC_07_CNT_001 does not.
3. Interface ownership. The interface between Level 2 (your SCADA or PLC OPC UA server) and Level 3 (the MES historian connector or data integration layer) is a shared boundary. ISA-95 makes explicit that Level 3 is the consumer of Level 2 data — not the other way around. Level 2 systems should not be modified to satisfy Level 4 requests directly. That kind of "short-circuit" integration bypasses the contextualisation layer that Level 3 provides and creates maintenance problems.
For a broader view of how PLCs fit into the full industrial control systems stack and how automation decisions are made across the hierarchy, the industrial control systems guide covers those architectural choices in detail.
Practical Use of ISA-95 Today
Where ISA-95 Is Actively Used
ISA-95 is most consistently applied in:
- Discrete manufacturing — automotive, electronics, consumer goods — where work orders, routings, and production tracking are central.
- Batch and process manufacturing — food and beverage, pharma, specialty chemicals — where ISA-88 (batch control) and ISA-95 are used together.
- Regulated industries — pharmaceutical and medical device manufacturing, where ISA-95 terminology appears in validation documents, functional design specifications, and system integration test protocols.
Where ISA-95 Is Challenged
The traditional ISA-95 hierarchy assumes a relatively stable, hierarchical network topology. Several trends create friction with that assumption:
- Edge computing and IIoT push computation toward Level 1/2 devices, which can route data to cloud systems at Level 4 without going through Level 3.
- Unified namespace architectures (MQTT Sparkplug B, OPC UA PubSub) make data from all levels available in a single broker, flattening the hierarchy.
- Cloud-native MES platforms may be hosted outside the traditional network boundary, requiring the integration model to adapt.
ISA-95 is not obsolete in these architectures — the data models and vocabulary remain useful — but the strict level-by-level communication path is increasingly replaced by event-driven architectures that still follow ISA-95 semantics even if data does not travel in strict level order.
ISA-95 Parts 5 and 6 (published after the original four parts) address business-to-manufacturing transactions and work scheduling in more detail, partly in response to these evolving integration patterns.
For a grounding in how manufacturing automation decisions connect to the control layer, the manufacturing automation guide covers the technology selection and implementation side of the picture.
Frequently Asked Questions
What is ISA-95?
ISA-95 (ANSI/ISA-95, IEC 62264) is the international standard for integrating enterprise resource planning (ERP) systems with manufacturing control and operations management systems. It defines a five-level automation hierarchy (Levels 0–4), data models for production resources and information, and the information exchanges that cross the Level 3/Level 4 boundary between MES and ERP.
What are the levels of ISA-95?
ISA-95 defines five levels: Level 0 (the physical process), Level 1 (sensing and manipulation — field devices and drives), Level 2 (supervisory control — PLCs, DCS, SCADA), Level 3 (manufacturing operations management — MES, MOM, historians), and Level 4 (business planning — ERP and supply chain systems). Each level has a characteristic time horizon ranging from milliseconds at Level 0 to days and weeks at Level 4.
What is the difference between ISA-95 and the Purdue model?
The Purdue Reference Model is a network architecture model focused on OT/IT network segmentation and security zones. ISA-95 is a published international standard focused on the data models and information exchanges between manufacturing and enterprise systems. Both use the same 0–4 level numbering, but Purdue addresses who can talk to whom at a network level, while ISA-95 addresses what data is exchanged and how it is structured. They are complementary frameworks.
What is B2MML?
B2MML (Business to Manufacturing Markup Language) is an XML schema implementation of the ISA-95 object models, maintained by MESA International. It provides ready-to-use XML schema definitions for ISA-95 information categories including production schedules, work orders, production performance responses, and material definitions. MES and ERP vendors use B2MML as the data format for ISA-95-compliant integrations, though the underlying ISA-95 object model can also be implemented in JSON, OPC UA information models, or other formats.
