The Purdue model vs ISA-95 question comes up on almost every integration project. Ask ten automation engineers whether the two are the same thing, and you’ll get a confident “yes” from about half and a confident “no” from the other half. Both camps are partly right, which is exactly why the question keeps coming up.
On the projects I’ve worked, the two terms get used interchangeably — in meetings, in network architecture drawings, and in MES integration specs — and most of the time nobody stops to separate them.
They are not the same thing, but they are tightly linked. One is a reference model; the other is an international standard that was built on top of that model. Getting the relationship straight matters, because the two are used for genuinely different jobs on a real project — one for network segmentation and security, the other for data integration between the plant floor and the business systems.
This guide draws the line clearly. If you’ve read our ISA-95 Enterprise Integration guide, this article is the companion that answers the specific question: how does the Purdue model relate to ISA-95, and when do you reach for each?
TL;DR — Quick Answer: Purdue Model vs ISA-95
The Purdue model and ISA-95 are related but not the same. The Purdue model (from the Purdue Enterprise Reference Architecture, or PERA) is a layered reference model that divides an industrial facility into hierarchical levels, from the physical process at the bottom to the business systems at the top. ISA-95 is an international standard (identical to IEC 62264) that adopted that layered hierarchy and built a formal framework on top of it for integrating control systems with enterprise systems.
Put simply: the Purdue model is the hierarchy; ISA-95 is the standard that uses the hierarchy to define how the levels exchange information. The Purdue model is also widely used on its own for network segmentation in OT cybersecurity, where ISA-95 plays no part. So they overlap heavily around the level hierarchy, but each has a job the other does not do.
Key points on Purdue model vs ISA-95:
- The Purdue model is a layered reference architecture; ISA-95 is a standard built on it
- ISA-95 is identical to the international standard IEC 62264
- Both share the same level hierarchy (Levels 0 through 4)
- ISA-95 focuses on the Level 3 to Level 4 integration — plant floor to business
- The Purdue model is also the basis for OT network segmentation under IEC 62443
- In casual use the terms are mixed, but they answer different engineering questions
What You Will Learn
This guide covers the Purdue model vs ISA-95 question at the depth a working controls or automation engineer actually needs:
- What the Purdue model is and where it came from
- What ISA-95 is and how it relates to IEC 62264
- The precise difference between the Purdue model and ISA-95
- What each of the hierarchy levels contains
- Where the two overlap and where they diverge, including cybersecurity
- The common misconceptions that cause confusion on real projects
What Is the Purdue Model?
The Purdue model comes from the Purdue Enterprise Reference Architecture (PERA), developed at Purdue University in the early 1990s under Theodore Williams. It was created to give manufacturing a common way to describe how the different layers of a facility — from field instruments up to corporate business systems — relate to one another.
Its central idea is a hierarchy of levels. At the bottom sits the physical process; at the top sit the enterprise business systems; and between them are the layers of control, supervision, and operations management that connect the two. Each level has a defined role and talks mainly to the levels directly above and below it.
Over time the Purdue model became the default mental map for industrial automation. When an engineer sketches a plant architecture on a whiteboard as a stack of layers, they are almost always drawing the Purdue model, whether they call it that or not. For the control layers it describes, see our What Is a DCS guide.
What Is ISA-95?
ISA-95 is the international standard for integrating enterprise and control systems, published by the International Society of Automation. It is identical in content to the international standard IEC 62264, so the two names refer to the same framework. Where the Purdue model gives the hierarchy, ISA-95 gives the detailed rules for how information moves across it.
ISA-95 took the Purdue hierarchy as its foundation and built on it a set of models — object models for equipment, material, and personnel, activity models for operations management, and the information exchanges between levels. Its particular focus is the boundary between Level 3 (manufacturing operations) and Level 4 (business planning and logistics), which is where the plant floor meets the enterprise.
The standard also defines B2MML (Business to Manufacturing Markup Language), the XML schema used to carry ISA-95 data between systems in practice. For the full treatment of the standard’s parts and object models, see our ISA-95 Enterprise Integration guide.
Purdue Model vs ISA-95 — The Key Difference
Here is the Purdue model vs ISA-95 distinction in one line: the Purdue model is a reference architecture, and ISA-95 is a standard that implements it for a specific purpose. The Purdue model tells you *what the layers are*. ISA-95 tells you *how the layers should exchange information* to integrate control and enterprise systems.
An analogy I use on site: the Purdue model is like a set of floor plans showing the storeys of a building, and ISA-95 is like the building code that governs how the plumbing and wiring run between those storeys. You can draw the floors without the code, and the code only makes sense because the floors exist. Neither replaces the other.
| Aspect | Purdue Model | ISA-95 |
|---|---|---|
| What it is | Reference architecture (from PERA) | International standard (= IEC 62264) |
| Origin | Purdue University, early 1990s | ISA / IEC, late 1990s onward |
| Primary purpose | Describe the level hierarchy | Integrate control with enterprise systems |
| Main focus | The whole layered stack | The Level 3 to Level 4 boundary |
| Defines data exchange? | No, conceptual only | Yes, with object models and B2MML |
| Common second use | OT network segmentation (IEC 62443) | MES and ERP integration |
| Status | Widely adopted convention | Formal, certifiable standard |
A common error, repeated even in some published explainers, is to treat “Purdue model” as simply another name for ISA-95. They are not synonyms: one is the architecture, the other is the standard built on it.
The reason the two get merged in conversation is that ISA-95 uses the Purdue level numbering so faithfully that the hierarchy looks identical in both. When someone points at “Level 3” they could mean the Purdue layer or the ISA-95 scope boundary — usually both at once.
The Hierarchy Levels Explained
Both the Purdue model and ISA-95 share the same level numbering, which is the source of most of the confusion and most of the usefulness. Understanding what sits at each level — and how fast each one works, from milliseconds at the bottom to days at the top — makes the relationship obvious.
| Level | Name | What lives there | Typical timescale |
|---|---|---|---|
| Level 0 | Process | Field instruments, sensors, actuators, the physical process | Continuous / real-time |
| Level 1 | Basic control | PLC and DCS controllers, safety systems, regulatory control | Milliseconds |
| Level 2 | Supervisory control | SCADA, HMI, operator stations, alarms | Around one second |
| Level 3 | Manufacturing operations | MES, MOM, batch management, historians, scheduling | Minutes to hours |
| Level 4 | Business planning | ERP, business logistics, plant scheduling, enterprise systems | Hours to days |
Level 0 through Level 2 is the domain of the control system itself — the sensors, the controllers, and the operator interface. This is where the DCS, SCADA, and PLC architectures live, where ISA-101 HMI design applies at Level 2, and where ISA-18.2 alarm management governs the alarm layer.
Level 3 and Level 4 are where ISA-95 does its real work. Level 3 is manufacturing operations — the systems that manage production, recipes, and historical data. Level 4 is the business — ERP and planning. The interface between these two is the single most important boundary in the whole model, and defining it cleanly is the core reason ISA-95 exists.
Many modern architectures also insert a Level 3.5, a demilitarised zone (DMZ) between operations and business networks. That layer is not part of ISA-95’s data model; it comes from the cybersecurity use of the Purdue hierarchy, which is where the two frameworks start to diverge.
Where They Overlap and Where They Diverge
On the Purdue model vs ISA-95 question, the overlap is the level hierarchy. ISA-95 uses the Purdue levels as its structural backbone, so any discussion of Levels 0 to 4 is common ground. If you only ever worked at that layer-naming level, you could be forgiven for thinking they were one and the same.
The divergence is in purpose, and it shows up most clearly in two places.
ISA-95’s own territory — data integration. ISA-95 goes far beyond the hierarchy. Its object models, activity models, and B2MML schemas define the actual information exchanged between Level 3 and Level 4. The Purdue model says nothing about this; it stops at describing the layers. When a project needs MES-to-ERP integration specified, that is pure ISA-95 work.
The Purdue model’s own territory — network segmentation. The Purdue model has a second life in OT cybersecurity, where its levels define network zones for segmentation under IEC 62443. The “Purdue model for ICS security” splits the network at the Level 3/3.5/4 boundaries to control traffic between OT and IT. ISA-95 plays no part in this; it is not a security standard.
So the honest answer to “are they the same” is: they share a hierarchy, but ISA-95 owns the data-integration job and the Purdue model owns the network-segmentation job. On a real project you will use the same level diagram for both conversations, but the deliverables are completely different documents produced by different teams.
How This Applies on Real Projects
The Purdue model vs ISA-95 split is clearest on a live project. The Purdue model shows up first, usually during the early network architecture and cybersecurity design. The level diagram becomes the reference for where firewalls sit, where the OT/IT boundary runs, and how the DMZ is structured. None of that touches ISA-95.
ISA-95 shows up later and in a different room — when the MES and ERP integration gets specified. That is when the Level 3 to Level 4 interface, the object models, and the B2MML exchanges matter, and when someone finally has to define exactly what production data crosses from operations to the business.
The practical lesson is that “which level” questions are Purdue questions, and “what data crosses between levels” questions are ISA-95 questions. Keeping that split in mind stops a lot of circular meetings. When a cybersecurity engineer and an MES integrator both say “Level 3” they mean the same layer but entirely different deliverables.
Does the Purdue Model Still Hold Up in the IIoT Era?
The strict hierarchy is under real pressure. IIoT sensors, edge computing, and cloud analytics increasingly let data skip levels — a field device streaming straight to a cloud historian breaks the “never skip a level” rule the model is built on. Initiatives like NAMUR Open Architecture (NOA) and the Module Type Package (MTP) deliberately add a second, parallel path for monitoring and optimisation data alongside the traditional pyramid.
But the Purdue model is not going away. It remains the dominant reference for both plant architecture and OT security, and ISA-95 still rests on its level structure. The pragmatic view on the projects I see is a split one: the core control path stays strictly layered for safety and determinism, while a separate, well-secured channel carries the IIoT and optimisation traffic. The hierarchy bends to accommodate the new data flows; it does not disappear.
Common Misconceptions
Based on project experience and the confusion I see most often, here are the recurring misconceptions about the Purdue model vs ISA-95:
“They’re the same thing.” They share the level hierarchy, but the Purdue model is a reference architecture and ISA-95 is a formal standard with data models. One describes the layers; the other defines the information flow across them.
“ISA-95 is a network security standard.” It is not. Network segmentation by Purdue levels belongs to IEC 62443. ISA-95 is about data integration between control and enterprise systems, not about firewalls or zones.
“The Purdue model defines data exchange.” It does not. It is a conceptual layering. The actual object models and B2MML schemas that define exchanges are ISA-95’s contribution, not the Purdue model’s.
“ISA-95 and IEC 62264 are different standards.” They are the same standard under two names. ISA-95 is the ISA designation; IEC 62264 is the international one, with identical content.
“The Purdue model is outdated.” The flat hierarchy is debated in the age of IIoT and edge computing, but the model remains the dominant reference for both architecture and OT security, and ISA-95 still rests on it.
“Level 3.5 is part of ISA-95.” The DMZ at Level 3.5 comes from the cybersecurity use of the hierarchy, not from the ISA-95 data model. It is a Purdue-for-security concept.
Frequently Asked Questions
Are the Purdue model and ISA-95 the same thing?
No, but they are closely related. On the Purdue model vs ISA-95 question, the Purdue model is a layered reference architecture that divides a facility into hierarchical levels. ISA-95 is an international standard that adopted that hierarchy and built a framework on top of it for integrating control and enterprise systems. The Purdue model is the hierarchy; ISA-95 is the standard that uses it.
What is the difference between the Purdue model and ISA-95?
The Purdue model describes what the levels are — a conceptual hierarchy from the physical process up to business systems. ISA-95 defines how those levels exchange information, with object models and B2MML schemas, focused on the Level 3 to Level 4 boundary. The Purdue model is also used for network segmentation; ISA-95 is not.
Is ISA-95 the same as IEC 62264?
Yes. ISA-95 and IEC 62264 are the same standard under two names. ISA-95 is the designation from the International Society of Automation; IEC 62264 is the international designation. Their content is identical, so references to either mean the same framework.
What are the Purdue model levels?
The Purdue model has five main levels: Level 0 (the physical process and field devices), Level 1 (basic control — PLC and DCS controllers), Level 2 (supervisory control — SCADA and HMI), Level 3 (manufacturing operations — MES and historians), and Level 4 (business planning — ERP). A Level 3.5 DMZ is often added for cybersecurity.
Why is the Purdue model used in cybersecurity?
The Purdue model’s levels map naturally to network zones, so it is used under IEC 62443 to segment OT networks and control traffic between the plant floor and the business. Firewalls are placed at the level boundaries, especially around a Level 3.5 DMZ. This network-segmentation use is separate from ISA-95.
Does ISA-95 replace the Purdue model?
No. ISA-95 is built on the Purdue hierarchy and depends on it; it does not replace it. The Purdue model continues to serve as the architectural and cybersecurity reference, while ISA-95 adds the data-integration standard on top. They are complementary, not competing.
Which one do I use for MES to ERP integration?
ISA-95. The Level 3 to Level 4 interface, the object models, and the B2MML schemas that define production data crossing from operations to the business are all ISA-95. The Purdue model only tells you that Level 3 and Level 4 exist; ISA-95 tells you what data moves between them. For the full treatment, see our ISA-95 Enterprise Integration guide.
Is the Purdue model still relevant with IIoT?
Yes, though it is debated. IIoT and edge computing allow data to move in ways the strict hierarchy did not anticipate, and some argue for flatter architectures. In practice the Purdue model remains the dominant reference for both plant architecture and OT security, and ISA-95 still rests on its level structure.
Conclusion
The Purdue model vs ISA-95 question has a clean answer once you separate the two jobs. The Purdue model is the layered reference architecture — the hierarchy of levels that everyone draws on the whiteboard. ISA-95 is the international standard, identical to IEC 62264, that takes that hierarchy and defines how the levels exchange information to integrate control with the enterprise.
The most important practical truths about the Purdue model vs ISA-95:
- The Purdue model is a reference architecture; ISA-95 is a standard built on it
- They share the same level hierarchy, Levels 0 through 4
- ISA-95 owns the data-integration job, focused on the Level 3 to Level 4 boundary
- The Purdue model owns the network-segmentation job under IEC 62443
- ISA-95 and IEC 62264 are the same standard under two names
- “Which level” is a Purdue question; “what data crosses” is an ISA-95 question
If you take one thing away, let it be that the same level diagram serves two very different conversations. When the cybersecurity team and the integration team both point at Level 3, they mean the same layer but entirely different deliverables. Keeping the Purdue model and ISA-95 straight in your head is what keeps those two conversations from talking past each other.
For the standard itself in full, see our ISA-95 Enterprise Integration guide. For the control layers the hierarchy describes, see our What Is a DCS guide, DCS vs SCADA vs PLC guide, ISA-101 HMI Design guide, and ISA-18.2 Alarm Management guide.
About the Author
Daniel Reed is an Instrument and Controls Engineer with 14+ years of oil and gas EPC experience across onshore and offshore projects in Asia and Africa. He currently works as a client-side I&C completion engineer on a large oil and gas mega-project in Asia, working with Honeywell Experion PKS and Safety Manager since 2018.
His earlier work covered Yokogawa CENTUM and Triconex SIS on an offshore brownfield in Africa, and Yokogawa CENTUM and ProSafe-RS on a gas-to-liquids facility in Africa. His focus is engineering deliverable review, control and safety system commissioning, HAZOP/SIL/SIF participation, FAT/SAT execution, and vendor coordination across Honeywell, Yokogawa, Triconex, Allen-Bradley, and Siemens platforms.