The ISA-95 Purdue model is a reference architecture that organizes industrial and manufacturing systems into layered levels, from physical process equipment up to business planning and logistics. It is widely used to structure responsibilities, data flows, and cybersecurity boundaries across OT and IT, especially in regulated and long-lifecycle environments.
Core idea
The model defines conceptual levels, each with a different role:
- Level 0: The physical process (machines, product, utilities, sensors as physical phenomena).
- Level 1: Basic sensing and actuation (field devices such as sensors, actuators, drives, instruments).
- Level 2: Control systems (PLCs, DCS, SCADA, local HMIs handling real-time control and interlocks).
- Level 3: Manufacturing operations management (MES, historian, scheduling, electronic batch records, OEE, local production IT).
- Level 4: Business planning and logistics (ERP, APS, financials, high-level planning and order management).
Some organizations also reference Level 3.5 or a demilitarized zone (DMZ) to separate plant-floor networks from enterprise IT, particularly for cybersecurity.
What the Purdue model is used for
- Architecture and integration planning: Clarifies where systems such as MES, ERP, historians, and PLM logically sit, and how data should flow between them.
- Cybersecurity zoning: Helps define network segments and trust boundaries, and is often used alongside IEC 62443 style zone/conduit models.
- Responsibility boundaries: Distinguishes IT vs OT ownership areas, support models, and change control responsibilities.
- Vendor and system scoping: Provides a shared language when specifying or evaluating MES, SCADA, or integration projects.
How it relates to ISA-95
The Purdue model often gets discussed in the same breath as ISA-95 because:
- ISA-95 defines interfaces and data flows between business (Level 4) and manufacturing operations (Level 3) and down to control.
- The Purdue model provides the layered architectural view that many ISA-95 implementations assume.
In practice, organizations use the Purdue levels to map where ISA-95 functions and data exchanges should live, but the model itself does not enforce any standard protocol or data model.
Constraints, caveats, and brownfield reality
The Purdue model is a conceptual guideline, not a prescriptive rule set or a compliance framework. Common realities in regulated, brownfield environments include:
- Layer blending: Legacy systems may perform functions from multiple levels (for example, an old SCADA acting like a mini-MES), which complicates clean layering.
- Mixed vendors and generations: Different control platforms, MES instances, and ERP systems often coexist, each mapped loosely to Purdue levels rather than perfectly.
- Limited downtime for re-architecting: Fully refactoring architectures to fit the textbook Purdue stack is rarely feasible due to qualification, validation, and production impact.
- No compliance guarantee: Using the Purdue model does not ensure regulatory compliance, security, or audit outcomes; those depend on implementation quality, procedures, and evidence.
Because of long equipment lifecycles and validation burdens, attempts to replace entire layers at once (for example, a full MES swap at Level 3) often encounter qualification effort, integration complexity, and downtime risk. Incremental, layered changes that respect existing Purdue-level boundaries tend to be more realistic.
Practical implications for your plant
- Clarify system placement: Map current systems to levels to understand overlaps, gaps, and where new solutions should sit.
- Plan integrations: Use levels to structure interfaces (for example, Level 3 MES to Level 4 ERP) and to document data ownership and traceability.
- Support cybersecurity zoning: Coordinate Purdue levels with network segmentation and IEC 62443-aligned zoning, especially around Levels 3 and 3.5.
- Inform change control: Use levels in change records and risk assessments to express impact across control, operations, and business systems.
The value of the ISA-95 Purdue model is in providing a common language and structure. Its usefulness in any given plant depends heavily on how well it is adapted to existing architectures, validated processes, and integration constraints.
