Key takeaways
- ISA-95 defines the systems of a manufacturing enterprise as a functional hierarchy from level 0 to 4; it is not a network architecture diagram.
- Level 2 and below is real-time control and monitoring, level 3 is manufacturing operations management (MES) and level 4 is business planning and logistics (ERP).
- In data flows between levels the most common problem is that nobody knows who owns the keys (order, batch, equipment).
- The model is valuable as a vocabulary; modern architectures (UNS, edge, cloud) may not map one-to-one onto the levels.
In a manufacturing plant data flows along a chain from the PLC to the ERP; every link has its own job and its own time scale. ISA-95 (internationally IEC 62264) is the most widely used model for describing this chain with a shared vocabulary. This article summarises the levels, the system roles and how you can use the model in integration design.
What ISA-95 is and is not
ISA-95 is a series of standards developed by ISA and standardised internationally as IEC 62264. It offers common terms, roles and object models for describing the integration between enterprise systems and control systems. Its best-known output is the hierarchy that divides enterprise functions into levels.
The model is a functional hierarchy: it answers the question “at which level is this job done?” It does not define network topology, security zones or product choice; those are separate subjects (for the security side see the article on secure data flows).
The levels
- Level 0, the physical process: The machine, motor, valve and the product itself.
- Level 1, sensing and actuating: Sensors and actuators.
- Level 2, monitoring and supervising: PLCs, HMI and SCADA. Control loops and operator visibility live here.
- Level 3, manufacturing operations management: MES and similar systems. Execution of production orders on the floor, material and equipment records, quality and traceability live here.
- Level 4, business planning and logistics: ERP. Orders, planning, purchasing, inventory and cost live here.
The time scale shortens as you go down: days and weeks are discussed at level 4, shifts and hours at level 3, seconds or shorter at level 2 and below. This difference explains why the questions “how often, with what outage tolerance” are answered differently at every boundary in an integration.
Data flows between levels
There are two main flows. Downwards, the production order planned in ERP descends through MES to the line and machine. Upwards, machine counters, states and quality results rise to MES and from there to ERP as confirmations.
Three problems are common in these flows:
- Skipping a level. Writing a PLC counter straight to ERP is usually not enough: order context, unit conversion and duplicate checking have to happen somewhere in between. That work can be done in an MES, in an integration layer or in the ERP interface itself; but it has to be done somewhere.
- Keys with no clear owner. It must be clear which system creates and may change the order number, the batch number and the equipment identifier.
- Mixed-up timestamps. The time the event happened at the source and the time it reached the upper system must be kept apart.
Equipment hierarchy and naming
ISA-95 also describes physical assets with a hierarchy: enterprise, site, area, production line or unit and work cell, among others. This hierarchy gives a natural basis for data naming: locating a measurement by site, area, line and cell helps different systems refer to the same asset in the same sense. In a Unified Namespace approach the topic hierarchy is often inspired by this structure.
Decide up front how many levels the hierarchy has and who manages the names; changing them later affects every flow that depends on them.
Limits of the model
Modern architectures do not map one-to-one onto the levels. An edge device can read level 2 data and also publish to a cloud application; a Unified Namespace merges data from different levels into one namespace; a cloud analytics service can sit above or beside ERP. That does not make the model useless, but it should be used as a vocabulary rather than as a rulebook.
The Purdue model, often used in network and security discussions, and the zones and conduits concept in IEC 62443 deal with network segmentation. Do not mix the three up: ISA-95 describes functions, while the Purdue model and IEC 62443 describe network and security.
How to use it in integration
At the start of a project answer these three questions in terms of the levels:
- At which level is the data produced and at which will it be consumed?
- Which key (order, batch, equipment) and which time rule applies at each boundary?
- Which layer performs the transformation: PLC, SCADA, MES, an integration layer or the ERP interface?
These questions form the core of the data contract and should be written down in the pilot scope. The integration planner gives that discussion a starting brief based on the sources and destinations you choose. The difference in roles between SCADA, MES and ERP is covered in a separate article.
Frequently asked questions
Is ISA-95 the same as the Purdue model?
No. They are related but do not serve the same purpose: ISA-95 defines functions and object models; the Purdue model is a reference arrangement used in network and security discussions.
Does a plant have to have every level?
No. The model is a vocabulary; a plant without an MES layer can run level 3 functions in ERP, in SCADA or in an integration layer. What matters is that every function has an owner.
At which level does OPC Router operate?
OPC Router is an integration layer; it is used to build data flows between levels (for example between level 2 and 3 or 3 and 4). Its placement is settled in the project together with network layout and the environment decision.