What Is ISA-95?

Back to Blog

The ISA-95 Levels

ISA-95 organizes an operation into a hierarchy of levels. Level 0 is the physical process itself - the wells, separators, and pipelines. Level 1 is the sensing and actuating layer: transmitters, valves, and instruments. Level 2 is monitoring and supervisory control - PLCs, RTUs, DCS, and SCADA. Level 3 is manufacturing operations management, where MES and MOM systems handle production scheduling, quality, and workflow. Level 4 is business planning and logistics, typically ERP.

The value of the model is that it clarifies which system owns which decision and on what timescale. Level 1 and 2 respond in milliseconds to seconds; Level 3 works in shifts and days; Level 4 in weeks and months. ISA-95 also defines standard object models - for production, material, equipment, and personnel - so a message about a batch or a run means the same thing on both sides of an interface.

Why ISA-95 Matters in Oil and Gas

Upstream and midstream operations rarely fit neatly into a factory model, but the layered thinking still applies. Field telemetry lives at Level 1 and 2, production volumes and allocation logic sit around Level 3, and hydrocarbon accounting rolls up into Level 4 financial systems. ISA-95 gives teams a clean way to describe where SCADA ends and the enterprise begins, which is exactly the seam where most integration projects succeed or fail.

In practice, a cloud SCADA platform occupies Level 2 and feeds structured data upward. Merobix reads field devices at Levels 1 and 2 over Modbus, DNP3, OPC UA, EtherNet/IP, S7, and MQTT, then exposes that data through APIs so Level 3 and 4 systems can consume it. Following ISA-95 boundaries keeps those handoffs predictable.

The Object Models: Where the Standard Earns Its Keep

The levels get all the attention, but the object models are what an integration team actually implements. ISA-95 defines resource models for personnel, equipment, material, and process segments, plus operations models for schedules, performance, and capability. When a Level 3 system requests a production schedule from Level 4, or reports back the quantities actually consumed and produced, the standard specifies what those messages contain and what each field means. That is what turns "send production data to ERP" from a months-long argument about spreadsheet columns into a mapping exercise between two structures that are already defined.

The common wire format for these models is B2MML, a set of XML schemas published by MESA that implements the ISA-95 object models directly. If an ERP integrator asks for B2MML documents, they are asking for ISA-95 objects serialized as XML. You are not obliged to use it - plenty of projects move the same objects over REST APIs or a message bus instead - but keeping field names and structures aligned with the standard means the next system that joins the conversation already speaks the language, and the integration survives a change of ERP vendor with far less rework.

A Worked Mapping: One Well Pad Through the Levels

Take a single well pad as a symbolic example. The wellhead pressure transmitter and the shutdown valve are Level 1. The RTU running local shutdown logic and the SCADA host polling it are Level 2. The allocation routine that takes daily meter volumes, applies shrink factors, and assigns production back to individual wells is doing Level 3 work, whether or not anyone in the office calls it an MES. The system that turns allocated volumes into royalty payments, joint-interest billing, and monthly statements is Level 4. Nothing in the model requires four separate products; it requires knowing which function is which.

Now trace one number upward. A raw differential pressure becomes a flow rate at Level 2, an allocated per-well daily volume at Level 3, and a revenue line at Level 4. At each boundary the data changes owner, timescale, and meaning, and each hop should be a defined interface rather than a nightly spreadsheet someone maintains by hand. A short exercise for finding the undocumented seams in an existing operation:

1. List every data flow that crosses a level boundary today, including the manual ones.
2. For each flow, name the producing system, the consuming system, and the ISA-95 object it resembles: schedule, performance, material, or equipment.
3. Mark the flows that travel as emailed files or get re-keyed by hand - that list is your integration debt.
4. Define each remaining flow as an interface with an owner, a format, and an agreed failure behavior when one side is down.

Common Misreadings of the Model

The most frequent mistake is treating ISA-95 levels as network segments. The levels describe function and decision timescale, not where servers sit. A hosted historian performing supervisory functions is still doing Level 2 work; moving software off site does not promote it to Level 4. Network zoning, conduits, and firewalls are the territory of the related reference architecture, and the distinction between the two frameworks is unpacked in ISA-95 vs the Purdue model.

A second misreading is assuming every operation needs a distinct product at every level. Smaller operators often run Level 3 functions inside their SCADA platform or a set of scheduled scripts; the model does not mandate five systems, it clarifies which functions exist so you can decide deliberately where each one lives and what happens when it moves. Batch-oriented facilities should also know that recipe and procedural control has its own companion standard, contrasted in ISA-88 vs ISA-95. For a walkthrough of the hierarchy applied to concrete site types, see the ISA-95 levels explained in practice.

Frequently Asked Questions