What is ISA-95? The Five Levels, IEC 62264 and the Automation Pyramid

The functional hierarchy of ISA-95 orders a manufacturing company from the bottom up. The standard defines the levels by their functions; which systems typically sit on them is described by ISA on its standard page.

A distributed control system (DCS) is listed by ISA as a whole under Level 2. In the German automation pyramid, it spans the control level and the supervisory level. More in What is a Distributed Control System (DCS)?

Where SCADA sits depends on the source. ISA’s own description lists it under Level 3; widely used depictions based on the Purdue model place it on Level 2, and by function it does much of what the standard defines as Level 2. The HMI does not appear in ISA’s description at all.

What separates the levels is mainly their time scale rather than the software. A controller responds in milliseconds because otherwise a drive runs into its end stop. An ERP system plans in weeks because materials planning has to wait for delivery times. Roughly nine orders of magnitude lie between the two. Every connection between production and enterprise IT has to bridge that gap. The trouble starts where the ERP system polls a controller directly, with no buffer and no acknowledgment in between.

Planning horizon is not data age

The figure in the last row describes the planning horizon. For a long time it was also read as data age: whatever sits in the ERP system can be days old, since the books are only closed at the end of the month. That reading no longer holds. Many of the companies we work with expect a view into running production, at least at the order level: which order is running on which line, and when it will finish. Inventory postings should be in the system when the pallet is on the floor, not after an overnight batch run.

The reason is logistics. In our projects, production is planned just in time more and more often, and against a local warehouse less and less. Where a buffer sits on the shelf, it forgives a day of delay in the data. Where it is missing, an outdated stock figure turns into a shortage on the next shift. What changes is not the planning cycle but the freshness the data has to have. Seeing running orders in the ERP system requires tapping production where it happens.

Yes. ISA-95 is named after the organization that publishes it, the International Society of Automation; IEC 62264 is the international standard number. Both refer to the same body of work. Tenders and requirement specifications use both names, sometimes in the same paragraph. You will also see ANSI/ISA-95 and the short forms S95 or SP95; they refer to the same standard.

In ISA’s numbering, ISA-95 has eight parts. Part 1 is titled Enterprise-control system integration – Part 1: Models and terminology. It defines models and terms so that an MES vendor, an ERP vendor and a system integrator call the same thing by the same name. What an operation is then no longer has to be settled anew in every project. Part 2 specifies the objects and attributes exchanged between Level 4 and Level 3, Part 3 the activity models of manufacturing operations management, and Part 4 the objects and attributes exchanged between those activities. Parts 6 to 8 cover messaging services, aliases and information exchange profiles.

For an integration project, Part 5, Business-to-Manufacturing Transactions, is the most relevant: it defines the transactions between applications on Level 4 and Level 3, that is, which messages between enterprise IT and manufacturing operations are provided for at all. For exchanging these messages, MESA International publishes B2MML, an open-source XML implementation of the ISA-95 models. The OPC Foundation calls B2MML the de facto standard interface for the content ISA-95 defines.

A neighboring ISA standard is ISA-88, which covers batch control: recipes and how a batch runs. It answers a different question than ISA-95; ISA publishes a separate technical report on using the two together.

ISA-95 contains two different five-part hierarchies. Both have five steps, and both are casually called “the levels”. When they are mixed up, the people on a project talk past each other without noticing.

The first is the functional hierarchy of Levels 0 to 4, the layering from the table above. It orders systems by their job.

The second is the equipment hierarchy. It orders places and things:

ISA-95 applies to discrete manufacturing, the process industries and logistics. Line and machine are therefore examples from discrete manufacturing, not a definition of the two lower steps.

Once data has to be structured, this second hierarchy is the one that matters more in practice. A namespace for production data is typically built on it, not on Levels 0 to 4. A temperature belongs to a machine, which belongs to a line, which stands in an area of a site. That the sensor sits on Level 1 and the system evaluating it on Level 3 plays no part in naming it.

The automation pyramid is a teaching model that originated in the German-speaking world and is derived from the same idea: many devices at the bottom, few systems at the top. It became so widespread because it is quick to explain. Its layers carry names, not binding numbers:

A standard it is not. Nor is there a binding definition of its layers: the literature shows versions with four, five and six, and none of them is more wrong than the others. The five-layer version shown here has as many layers as ISA-95, which is why the two get treated as the same thing. At the bottom, they count differently:

At the top, the two agree. At the bottom, the pyramid is shifted by one layer and splits ISA’s Level 2 in two.

The pyramid shows where something sits. The standard defines how to talk about it.

One can be mapped onto the other, as in the table above. They are not interchangeable, and a level number is only unambiguous together with its model. The pyramid also covers only the functional hierarchy; the equipment hierarchy does not appear in it at all.

Level 3 is manufacturing operations management (MOM); in the pyramid, it corresponds to the operations level. It is typically handled by an MES (manufacturing execution system), and ISA’s description also lists SCADA here. The OPC Foundation’s ISA-95 Common Object Model (OPC 10030) adds batch systems and historians. This is where orders are broken down into operations, batches are tracked, quality data is recorded, people and material are assigned, and results are reported back to planning.

In projects, Level 3 is contested because it is claimed from two sides. An ERP vendor sees detailed scheduling as its job, and so does an MES vendor, and both have good arguments. Where the line falls is an organizational question rather than a technical one: it depends on who in the company owns the production schedule. ISA-95 provides the terms; the answer is left to the company.

Does Level 3 have to be an MES?

No. The standard describes tasks, not a product: breaking down orders, tracking batches, reporting back. It does not specify which system does that. Three options are common, and they do not exclude each other: a full MES; only the functions that are needed, built in-house, for example on a no-code platform such as manubes; or no separate system on Level 3. In that case, a data integration layer takes over the data path: it picks up values from production, translates them and hands them to the ERP system. When which option fits is covered in What is an MES?

When Level 3 is not a system of its own, the ERP system has to get its data somewhere else. The obvious place is the supervisory level: that is where the values are, and where they are already being collected.

The levels are useful once it is clear which question gets answered on which one. These three systems are easy to confuse:

The three differ mainly in context, less in the amount of data. The SCADA system shows that oven 3 is running at 180 degrees. The MES assigns those 180 degrees to batch 4711. The ERP system holds batch 4711 under an order for 5,000 units due on Friday. Each level adds context that the level below does not hold.

In practice the three overlap, and many systems have picked up functions from the neighboring level. The assignment is still useful: it determines which system applies when two numbers contradict each other.

In depth for each term: What is SCADA? · What is an MES?

As a model of responsibilities, ISA-95 holds. As a description of actual data paths, the level-by-level picture fits less and less often.

The use cases on opc-router.com show this. According to a use case published in July 2023, the integrator ZewaTec had first connected two Siemens systems and a Yokogawa control system at a wax technology manufacturer to SAP through a combination of several partial solutions, writing around 20,000 lines of code in the process. The many licenses for standard software made the combination expensive, and the data transfer stalled whenever one of the solutions stopped running. Graphically configured connections in the OPC Router eventually replaced over 90 percent of the programming.

The use case of a label manufacturer describes a direct link between PLC and SAP: the ERP system sends formulation and production speed to the machines, and the machines report flawed areas back with the roll number. The page cites around 15,000 data telegrams per day with processing intervals below 15 milliseconds, without saying when this was measured; the company figures on the same page are from the 2017 financial year. According to the use case of a film manufacturer, 50 machines at three locations were connected from the control and sensor level through to SAP; the systems went live at the beginning of 2019.

In our projects, the usual case does not reach as far down: the ERP system frequently talks to the supervisory level, meaning HMI and SCADA, and sometimes directly to the controller. The examples above reach down to the controller, and the first one to a control system as well. That deep variant does occur, but it is not the rule.

Both paths skip levels the model provides for. That does not make ISA-95 wrong: it still describes the responsibilities correctly, just no longer the route the data takes.

Why the levels no longer work as a data path

As long as each level serves the next, every connection is a project of its own, with its own coordination, its own maintenance and its own contact person. With ten machine types on the production side and five systems on the IT side, that makes fifty possible point-to-point connections, and each one can break when a version changes on either side.

On top of that comes a loss that weighs more than the effort: context gets lost on the way up. What was “temperature at extruder 3, order 4711, batch B” at the controller arrives in the ERP system as a column of numbers. The forms this takes are covered two sections further down.

And the path is designed as a one-way street. Data travels up, commands travel down. A company that sends a recipe from the ERP system to a machine and expects the confirmation within the same cycle no longer fits that picture.

No. It shifts the role of the levels. In a Unified Namespace, all systems publish their data into a shared namespace instead of passing it on from level to level. That namespace is typically organized along the ISA-95 equipment hierarchy, for example enterprise, site, area, line, machine; Levels 0 to 4 do not appear in it. A controller remains a controller, an MES remains an MES; only the role of data courier goes away. How data gets into such a namespace and back out is covered in Connecting to a Unified Namespace.

An ERP system calls and waits; a controller answers in its scan cycle. The two work with different time scales, and a record means something different on each side. The faults that arise at the boundary cannot be configured away, but they can be handled, and part of the handling always stays with the operator.

The timing gap: aborted above, still running below

An ERP system calls a function that triggers something in production and waits for the result. If its timeout expires before everything below has finished, the call ends, but the process in production does not. It keeps running and writes its result to a place nobody reads any more.

The cause: Each level has its own clock and its own timeout, and there is no transaction bracket across the boundary. A timeout above says how long a caller waits. It is not an instruction to the level below to stop doing something. No notice of the timeout reaches the other side.

In operation: An order the ERP system lists as failed, but which ran on the line anyway. Duplicate batches, because someone restarted by hand after the error message. Confirmations that match no transaction.

What stays with the operator: Evaluate the outcome. Middleware can report it, but without a program that checks the return value, the report has no effect. Then there is the basic question of whether the call should be synchronous at all: an architecture decision, not a setting on the side. And the timeout itself. In the OPC Router’s default hosting process, a fixed 60-second limit also applies to the internal handoff. If your own timeout is shorter than that, SAP sees a normal return with unassigned export parameters, in other words no error at all. The same applies in the other direction: if the acknowledgment to the controller does not arrive, the PLC program has to notice and send again.

In the OPC Router: It can report the outcome to both sides, through a return value rather than an abort. The return value only arrives where someone is still waiting, and the other side has to evaluate it. On the SAP RFC trigger, it returns the parameter TRANSFER_OK after each transfer and uses it to distinguish success, abort and error; for the error case, the manual adds that the request must be resubmitted later and must not be marked as completed. The gap does not arise when SAP does not wait: if SAP sends an IDoc, the OPC Router acknowledges receipt immediately, and no result travels back over that call. If IDoc Acknowledgment is enabled on the IDoc trigger, the OPC Router then writes the transfer result back to SAP as a status record of that IDoc, for example status 12 on success and 11 on failure. Toward the controller, related values can use a handshake through the bit or message trigger: the controller writes the values and sets the trigger last, the OPC Router waits for an additional read cycle, reads, and acknowledges through a response data point, or through an error bit if the transfer failed, provided both are enabled on the trigger. Whether the values belong together depends on the controller really writing the trigger as the last signal. The manual recommends always using the bit trigger with a response bit: if the trigger changes twice within one read cycle, the second transfer does not happen, and neither does the response; the controller has to react to that missing response. For the message trigger, the manual recommends recording the trigger value, which makes it possible to trace whether records were not transferred or transferred twice.

What it does not do: abort the process below when the time runs out above. The flow keeps running. The asynchronous route through the IDoc is meant for this case.

The validity of a value does not survive the boundary

As soon as a value is read over OPC, it carries a second piece of information: its quality. It says whether the value is a genuine current measurement, the last known value of a broken connection, a value outside the sensor’s accuracy, or a value forced by hand.

Once the same value moves into a database column, a JSON field or an ERP field, there is by default no room for that second piece of information, unless someone creates it. Above, there is a number that looks like any other.

The cause: OPC transmits value and status as a pair; the target systems of the upper levels, out of the box, only hold the value. At the boundary, that leaves a choice between two losses. Either the status is dropped, and a forced or stale value shows up above as an ordinary measurement. Or the values are filtered, and the affected ones disappear silently: the level above shows no fault, only a gap that cannot be told apart from “nothing happened”. A filter can pass or discard, but it does not pass on the reason.

In operation: A metric that stays exactly the same for days although the line is running. A defective sensor whose last value keeps flowing into the monthly report. The cross-check is simple: the same data point shows a fault color in the control system and an unremarkable number on the dashboard.

What stays with the operator: Make room above. An extra column in the table, a field in the JSON, a custom field in the ERP system. Then a business decision that no setting can make: does a value delivered outside the sensor’s accuracy count as a measurement or as a gap? And the evaluation has to read the new information. A report that ignores the quality column still shows forced and stale values as ordinary measurements.

In the OPC Router: Quality is a value in its own right next to the measured value. It can be output as text (Quality string) or as a number (Quality ID) and linked like any other value, including into a database column of its own; this is set on the trigger with “Output Metadata”. The distinctions above carry named values: “goodLocalOverride” for a forced value, “badLastKnownValue” for a frozen one. Two options target the two symptoms: “Trigger on Quality Change” transfers even when only the quality changes and the value stays the same, and the Data-Change-Missing trigger fires when a data point does not change within a check period. That turns the silent gap into an event.

The OPC Router can filter as well. In the OPC plug-in, “Allowed Qualities of Values” sets which states are processed at all. Whatever the setting excludes is ignored. That is why monitoring for missing values belongs with it, and its check period is a business quantity: a tank level that does not change for an hour is normal. A rotational speed is not.

A timestamp set above measures the transport

If the timestamp of a production value is assigned only where the value arrives, instead of where it originates, this goes unnoticed as long as nothing stalls.

As soon as anything buffers, batches or backfills, a whole series of values moves to almost the same point in time. In the extreme case, so close together that records overwrite each other.

The cause: Every boundary between levels has its own latency, and it is not constant. The problem is made worse by the mechanisms meant to close the gap: a backfill runs in parallel with live operation and therefore not in the original order. Where only the arrival time is recorded, the order in which things happened in the plant can no longer be reconstructed.

The remedy costs little but has to be decided up front: every record carries its own timestamp, assigned where the value originates. If this is added later, it is missing for the history before.

What stays with the operator: Only a source that has an origin time can pass one on. Either the OPC server keeps it, or the controller writes it into a data point of its own, together with the other values of a record. Middleware cannot invent it. At the target, the time needs a column, and the evaluation has to use it: a table whose only time is the insert time keeps measuring the transport. If backfilling is enabled after an interruption, it also has to be decided where it does not belong. Otherwise stale values end up in a visualization that only shows the current state.

In the OPC Router: Whether the timestamp measures origin or arrival is a choice here. When reading, it takes the Value Timestamp from the source server; when writing, the timestamp can be specified, explicitly for the case where the value comes from a history. When writing to a time series database, the timestamp source is selectable: the receiver’s time, the router’s time, or a timestamp supplied at runtime. The manual advises against the receiver’s time as soon as batch writing is used, and names the same damage as above: values processed within the same nanosecond, which are then aggregated.

What it does not do is stated in the manual. A backfill runs in parallel with live operation; backlogged and current values are explicitly not necessarily transmitted in their original order. The router does not restore the order of transmission. It can be reconstructed from the timestamp carried along, not from the arrival. And backfilling only happens where Store and Forward is enabled and the transfer object supports it. As a rule, every transfer object at the end of a flow supports it, including the SAP transfer objects; whether a specific one does is shown by the Store and Forward icon once the feature is enabled. The SAP IDoc transfer object adds the IDoc queue: IDocs that cannot be sent are temporarily stored there. Independent of the target, there is the transfer status trigger: when records come from a database table, it marks each one as transferred or failed after the transfer, and failed ones can be retried through a counter. Further attempts are also possible without Store and Forward: a Try/Catch transfer object re-executes the enclosed part of the flow up to four more times, including steps that had already succeeded. The manual therefore advises enabling retry only for flows that can safely run more than once.

Controllers speak fieldbus protocols and store values in registers; ERP systems work with business objects and documents. Middleware translates between the two and decouples them at the same time: when something is replaced on one side, the other side is left untouched. The fifty point-to-point connections from above become ten plus five.

According to the international use cases on opc-router.com, the OPC Router was used at an Italian manufacturer of polyethylene pipes to connect SAP S/4HANA with an MES, using SAP IDoc, SAP RFC and MS SQL Server. The overview lists several transactions configured in both directions, from item master data and production orders to the feedback of pieces produced, material consumption and product waste in kilograms. That is the interface between Level 4 and Level 3 as ISA-95 describes it.

A second case from the same overview: an insulation manufacturer in Japan used the OPC Router to replace the historian of its DCS with a time series database, relaying over 10,000 data points every few seconds.

What such a route looks like in detail is shown in SAP connection in industrial production. That page also covers where middleware differs from a vendor’s own connectivity component. What a setup costs is listed on the licensing and pricing page.

More on the basics: What is middleware? · What is IT/OT integration?