ISA-95 explained: how to connect PLC to ERP without breaking anything

When a customer tells us "we want the PLC to talk to the ERP", what they need is almost never a direct connection — it's a model. ISA-95 (international standard IEC 62264) has been solving exactly this problem for more than twenty years, and remains the most useful reference framework not to improvise an industrial data architecture.

The 5 levels of the ISA-95 model

ISA-95 organises a plant into hierarchical levels, each with its function and decision time horizon:

• Level 0 — Physical process: sensors and actuators. Milliseconds.
• Level 1 — Control: PLC, robots, drives. Milliseconds to seconds. Real determinism.
• Level 2 — Supervision: SCADA/HMI. Seconds to minutes. Visualisation, alarms, recipes.
• Level 3 — Operations management (MES/MOM): hours to shifts. Production orders, traceability, OEE, quality.
• Level 4 — Business planning (ERP): days to months. Purchasing, sales, financial planning.

ISA-95's central idea isn't just drawing these layers — it's defining which specific information crosses from one level to another (work orders going down, production results going up) so each system does its job without invading its neighbour's.

Mistake 1 · Connect everything to everything

The first expensive mistake is the "total connectivity" temptation: every PLC with an OPC-UA client talking directly to the ERP, every machine with its own Excel export script someone uploads manually. The result after two years is a mess of point-to-point integrations nobody documented, that break in cascade every time a software version changes at any endpoint. If you're starting out and not sure what role the PLC plays in this whole stack, start with What is a PLC and what is it for?.

Mistake 2 · Connect nothing

The second mistake, equally expensive but less visible, is not connecting at all and continuing with paper reports, manual Excel or isolated SCADA without centralised history. The cost isn't seen on an integration invoice — it's seen in days lost preparing an IFS/BRC audit gathering data by hand from half a dozen systems, as in the real case we describe in our food cases.

Which protocol to use at each level

There's no single "correct" protocol for the whole stack. What we do at DAXP is assign the tool per layer:

• Level 1 → Level 2: Profinet, EtherNet/IP, Modbus TCP — deterministic field protocols.
• Level 2 → Level 3: OPC-UA is the de facto standard. Structured information model, integrated security, vendor-independent.
• Level 3 → Level 4: REST APIs or native ERP connectors (SAP PI/PO, Dynamics, Odoo). Here you already speak in business terms: orders, batches, costs.
• Remote telemetry or IoT (aquaculture, scattered sensors): MQTT, for its lightness and tolerance to intermittent connections — the pattern we use in smart aquaculture projects.

A real architecture, layer by layer

On a typical food traceability project, the architecture looks like this: the Siemens S7-1500 PLC runs the machine in real time; the SCADA WinCC Unified centralises recipes, alarms and captures production events; an OPC-UA server exposes that data in a structured way; a SQL Server historian stores batch, temperature, operator and time; and a scheduled integration (not a direct cable) syncs production orders from the ERP and pushes production results up to it.

Each layer can fail, be updated or replaced without bringing down the others — which is exactly what doesn't happen in a point-to-point integration. And if the cell you're integrating includes safety — as always happens in automotive or food with robots — safety status also travels through these layers: we program that architecture with ProfiSafe and F-CPU according to the safety spec already defined for the project.

When do you need a real MES?

Not every plant needs a full MES. If you have few production orders per day and the SCADA already centralises traceability and history, it may be enough. A dedicated MES/MOM starts making sense when you have: multiple lines competing for the same resources, need for fine production scheduling, or inline quality integration with automatic batch blocking.

Frequently asked questions

Can the PLC write directly to the ERP?

Technically yes, but not recommended. It skips the MES/SCADA level that gives context to the data (batch, order, shift) and creates a fragile dependency: if the ERP changes, you have to touch the PLC program.

OPC-UA or MQTT for uploading plant data?

OPC-UA for structured exchange within the plant (level 2-3). MQTT for lightweight telemetry to the cloud or remote devices with intermittent connectivity (level 3-4). In large projects we use both, each at its layer.

Do I need a MES if I already have SCADA and ERP?

Not always. A well-designed SCADA with historian and traceability can cover much of level 3 in small plants. Depends on order volume and need for fine production scheduling.

What happens if I don't follow any layer model?

On small projects it may not show. With multiple lines or plants, the lack of a clear model produces point-to-point integrations impossible to maintain: every change breaks two or three undocumented connections.