ISA-95 and the Purdue Model for Food Plants: The Levels, the Context and the Security Boundary

The Purdue model and ISA-95 are the two reference models most often used to describe how a manufacturing plant's systems fit together. The Purdue model sorts every system into levels, from the physical process at the bottom to business planning at the top. ISA-95, published internationally as IEC 62264, uses the same levels and defines the manufacturing operations layer in the middle and the information that crosses between the plant and ERP. This guide explains both on a real food line, shows where each piece of production context lives, and covers the security boundary the levels imply.

It is written for engineering managers, IT and OT leads and plant managers who are scoping a data, MES or ERP integration project and want a shared language for it.

Where the Purdue model comes from

The Purdue model grew out of the Purdue Enterprise Reference Architecture, developed at Purdue University in the early 1990s by Theodore J. Williams and industry partners to describe computer-integrated manufacturing. Its lasting contribution is the idea of levels: each level has its own job, its own timescale and its own systems, and information moves between adjacent levels through defined interfaces.

ISA-95 adopted that level structure when the standard was first published by the International Society of Automation in 2000. It then went further than Purdue in one area: it defined in detail the activities at Level 3, manufacturing operations management, and the objects exchanged with Level 4, business planning and logistics. That is why engineers use "Purdue" when they talk about network architecture and security, and "ISA-95" when they talk about MES, ERP integration and data models.

The levels on a food line

The levels are easiest to understand on one line. Take a yoghurt cup filling line in a mid-size dairy plant.

The timescales matter as much as the systems. The filler PLC decides in milliseconds whether to open a valve. Level 3 cares about what happened this shift. ERP cares about what the plant will make next week. Most integration problems come from asking one level to behave at another level's pace, such as a planning tool polling a PLC every second, or an operator waiting for ERP before a line can restart.

What ISA-95 adds at Level 3

ISA-95 divides Level 3 into four areas of operations management: production, maintenance, quality and inventory. Each has the same pattern of activities: define the work, schedule it, dispatch it, execute it, track it and analyse it. In a mid-size food plant these map to familiar jobs.

• Production operations: releasing orders to lines, tracking what each line made, OEE and downtime.
• Maintenance operations: work orders, preventive maintenance schedules and asset history in the CMMS.
• Quality operations: in-process checks, lab results, holds and releases.
• Inventory operations: material movements, lot tracking and stock on the floor.

A plant does not need a product called an MES to have Level 3. It already has one, even if it is a set of spreadsheets, a SCADA historian and a CMMS. ISA-95 is useful because it names those functions and shows how they should connect, whether they run in one MES or several simpler systems.

ISA-95 also defines the objects that cross between Level 3 and Level 4: production schedules and orders going down, and production performance, material consumption and equipment status coming back up. MESA International publishes B2MML, an XML implementation of those objects, which gives ERP and plant systems a common format when both support it.

Where the context lives

Most production data is useless until it is joined to its context. The difficulty is that each piece of context is created at a different level, by a different system, often on a different clock. On the yoghurt line:

Joining these reliably needs two things. The first is one equipment hierarchy, so a stop on "Filler 2" in the PLC, "FIL02" in SCADA and "Line 2 filler" in the CMMS are the same asset. ISA-95 provides the structure: enterprise, site, area, work centre and work unit. The second is one time base, so a stop at 06:59:58 on the PLC clock is not recorded in the wrong shift because the server clock is two minutes out.

When context is joined at the point of capture, a report can answer why output was low on a given order, not just that it was. When it is left to a reporting tool to guess later, the answer is usually a spreadsheet and an argument. A unified namespace is one modern way to organise this, and it still depends on the same hierarchy; our guide to plant data silos covers it in detail.

The levels as a security boundary

The Purdue levels are also the starting point for industrial network security. IEC 62443, the international series for industrial automation and control system security, groups systems into zones with similar security needs and controls the conduits between them. In practice most food plants draw their zones along the Purdue levels.

• Levels 0 to 2 sit in one or more control zones, segmented by line or area where the risk justifies it.
• Level 3 systems such as historians and MES sit in an operations zone.
• A demilitarised zone, often called Level 3.5, sits between the plant and the business network. Data leaves the plant through it; nothing on the business side connects straight through it to a PLC.
• Level 4 business systems, including ERP and corporate reporting, sit on the business network.

This is why a well-designed integration moves data outbound from Level 3 through the DMZ, and why ERP or cloud reporting never gets a direct path to a Level 1 controller. Our guide to OT network security for Australian manufacturing sites covers zones, conduits and remote access in more depth, and our OT networks work applies them on site.

Where the models are showing their age

The level model was drawn when each level ran on its own hardware. Today a single Ignition gateway can serve Level 2 screens and Level 3 reporting, edge devices publish Level 0 condition data over MQTT straight to Level 3, and cloud services sit outside the stack altogether. Some engineers argue the Purdue model is obsolete for that reason.

It is more accurate to say the model now describes functions and trust boundaries rather than boxes. A gateway that serves both screens and reports still needs its control functions protected, and data published from the edge still needs its context attached before anyone can use it. The levels remain the clearest way to agree what each system is responsible for.

Using the models on a real project

For a mid-size food plant, the models earn their keep in three practical ways.

1. Scoping. Listing which Level 3 functions exist today, and in which systems, shows the real gap before anyone buys software.
2. Integration design. Deciding which system owns each record, such as ERP for orders and stock and the plant for what happened, prevents the double-entry and reconciliation that most integrations create.
3. Security. Placing each new system in a zone before it is installed avoids the flat networks that make plants hard to secure later.

If you are connecting production data to ERP, the ERP and SAP integration page covers the transaction rules that sit on top of the ISA-95 boundary. For a practical view of how far to take Level 3 in a mid-size plant, see MES for mid-size food plants.

What this means

The Purdue model and ISA-95 give a plant one vocabulary for systems, data and security. Use the levels to decide what each system is responsible for, use the ISA-95 equipment hierarchy and one time base to join context at the point of capture, and use the same levels to draw the security boundary. Plants that do this find that each new report, integration or line is a small extension instead of a new project.

If you want an engineer who knows the control system to map your plant against these levels, speak with an engineer.