Theme: Levels as an analytical tool, not a physical law
Quick definition
The Purdue Model is a hierarchical reference model for computer-integrated manufacturing, arranging physical processes, control, manufacturing operations and business planning into levels. ISA-95 builds on Purdue to describe activities and interfaces. They are closely related but not literally the same model.
In context: its relationship to ISA-95
ISA describes ISA-95 as a technology-independent standards series for integrating manufacturing control with logistics and enterprise systems. It focuses on activities, terminology and information exchange, particularly across levels 3 and 4. Purdue supplies a reference foundation; ISA-95 adds detailed business and information models.
What the levels reveal
A common reading places physical processes at level 0, sensing and manipulation at level 1, supervisory control at level 2, manufacturing operations at level 3, and business planning and logistics at level 4. This makes responsibilities and different time horizons discussable.
For example: following the levels
A valve affects the process, a controller regulates it, an operator display presents its state, operations management follows order results, and ERP plans resources. The model helps a team ask what information crosses each boundary and who owns the decision.
Not a mandatory topology
Activity levels do not require one product per level, a fixed number of firewalls or data moving only upwards. One system may support several activities, while modern flows may be distributed. Actual network design must follow risk, latency, availability and support capability.
Opportunity and limitations
The model provides shared language and can expose unclear interfaces. A pyramid drawing creates no security by itself and may hide remote access, cloud services or dependencies between sites. Segmentation and access controls must be verified in the real architecture.
HubMind’s view
Use the levels to test accountability and information exchange, not to win an argument about diagrams. Retain the lens where it clarifies consequences and boundaries; supplement it where reality is distributed. Document activities, flows and controls as they actually operate.
Next step in the architecture review
Which activity is performed? Which system is authoritative? What timing and physical consequence apply? Where are access rules enforced? How does local autonomous operation behave during an outage? These questions make the model operational without freezing the solution into a historical topology.
Related concepts
Sources and further reading
Scope and freshness
The Purdue reference model and ISA-95 using ISA’s public overview, with NIST SP 800-82 Rev. 3 as security context. No standards text is reproduced. Reviewed 31 August 2026.