ISA-95 in Practice: Wiring the Plant Floor to the ERP

Walk into the control room of almost any processing plant and you'll find the same drawing somewhere. Taped to a cabinet, or buried in a commissioning binder. A pyramid. Sensors at the bottom, the business system at the top, a few layers in between. Someone sketched it years ago and nobody has questioned it since. That pyramid is ISA-95, whether the people leaning on it know the name or not.

We see it on most sites we instrument. The plant floor runs fine on its own. The business systems run fine on their own. The trouble lives in the gap between them, where a batch record has to become a production order, or a tank level has to turn into an inventory figure the planners actually trust. Get that handoff wrong and you end up with two versions of the truth: the one the operators believe, and the one the finance office believes. ISA-95 exists to stop those two from drifting apart.

This is a field note on how the standard is built, where it earns its keep, and where we've watched it cost more time than the project plan allowed for.

The pyramid everyone draws

ISA-95, published internationally as IEC 62264, sorts a plant into functional levels and then defines how information should move between them. In its 2016 survey of smart-manufacturing standards, NIST describes it as a commonly used reference model for developing automated interfaces between enterprise and control systems, built to apply across batch, discrete, and continuous processes alike. The level scheme itself borrows from the older Purdue Reference Model for computer-integrated manufacturing, which the ISA-95 committee still cites as its hierarchical backbone.

Five levels make up the model. At the bottom sits Level 0, the physical process: the reactor, the kiln, the conveyor, the actual chemistry and mechanics. Level 1 is the instrumentation layer, the sensors and actuators wired to it. Level 2 is supervisory control, the PLCs, DCS, SCADA and HMI screens that watch the process and react in seconds or less. Level 3 is where manufacturing operations management lives: scheduling, dispatch, quality, the production record. Level 4 is business planning and logistics, the ERP world of orders, costing and procurement. Each level runs on its own clock.

But the point of the standard isn't the picture. It's the seam. The OPC Foundation's reference documentation puts it plainly: ISA-95 typically deals with information exchange across Level 3 systems, or between Level 3 and Level 4 systems. That's the line between the plant and the business. It's also the line where most integration projects get into trouble, because the two sides speak different dialects. The shop floor thinks in tags, alarms and equipment states. The ERP thinks in materials, orders and cost centers. Somebody has to translate, and ISA-95 is an attempt to write the dictionary down once instead of re-inventing it on every project.

What the standard actually puts on paper

So what do you get when you open it? Not software. That's the first thing to be clear about. ISA-95 is a set of models and definitions, split across numbered parts. Part 1 sets out the models and terminology. Part 2 details the object attributes. Part 3 covers the activity models of manufacturing operations management, and a later part defines the business-to-manufacturing transactions that move data between the levels.

At its heart is a small set of resource models. The companion documentation built on the standard notes that it conforms to the common object models defined in ANSI/ISA-95.00.02-2010, covering personnel information, role-based equipment information, physical asset information, and material information. Four buckets. Who's on shift, what equipment exists and what it can do, which physical assets are installed, and what material is moving. Get those four described the same way on both sides of the seam and a production order from the ERP can land on the floor without a human re-keying it into the MES.

Alongside the resource models sits the idea of a process segment. A segment is the standard's way of describing a chunk of production as a recipe of resources: this much personnel, this equipment, this material, for this step. It's the bridge between what the business wants (an order for so many units) and what the floor has to marshal to make it. Get the segment definitions right and the production schedule from Level 4 maps cleanly onto Level 3 capability. Get them vague and the schedule becomes a wish list the floor quietly ignores.

That phrase, manufacturing operations management, is worth pinning down because people use it loosely. NIST's definition is blunt: MOM refers to the applications that control plant-level operations. It's the Level 3 band, the home of the MES, sitting between the control system and the enterprise. The same report notes that IEC 62264 defines activity models, function models and object models in exactly that domain. When a vendor sells you an MES, what they're really selling is an implementation of these models, tuned to a sector. So the standard is the grammar, and the MES is one way of speaking it.

Why does this matter on a real site? Because the models are what make integration testable. You can point at a personnel record or a material lot and ask whether both systems agree on what it means. Without that shared definition, every interface becomes a private agreement between two engineers, and private agreements leave with the engineers. And on a plant that's been running for decades, the engineers who made the original agreements are often long gone, taking the only copy of the logic with them.

Getting the data across the line

A model on paper still needs a wire. There are two common ways the ISA-95 object models actually cross the Level 3 to Level 4 boundary, and most plants we work on use one or the other.

First comes B2MML, the Business to Manufacturing Markup Language, published by MESA International. It's a set of XML schemas that implement the data models in the ISA-95 standard, and any company can use it royalty-free as long as it credits MESA. In practice B2MML is the lingua franca for ERP-to-MES messaging: a production schedule, a material definition, a performance report, all expressed as XML that both ends have agreed to parse. It's been the default for a long time, and for batch-heavy plants it's still a sensible starting point.

Then there's OPC UA. The OPC Foundation released its ISA-95 companion specification in early 2013, mapping the physical-asset, equipment and personnel models into the OPC UA information model. The appeal is reach. Where B2MML is a document exchanged between two business systems, OPC UA is a live protocol that already runs down on the control network. The companion spec lets ISA-95 information move securely between Levels 3 and 4 and, as the Foundation notes, be extended down to Level 2. So the same object that describes a piece of equipment up at the MES can be tied to the live data coming off it, without a second integration layer in the middle.

The two aren't interchangeable, and the OPC documentation is honest about it: the B2MML mapping doesn't always align well with OPC UA technology requirements, which is why a separate UA mapping had to be written at all. If you're standing up a new integration today, that's a real fork in the road. B2MML if your exchange is document-shaped and batch-oriented. OPC UA if you want one information model running from the instrument up to the planner. Picking the wrong one isn't fatal, but it does mean rework.

A second thing the transport choice drags in is security, and it's easy to forget until an audit raises it. The moment you open a path from the control network up to the business systems, you've created a route an attacker would love. NIST's review lists ISA/IEC 62443, the OT security series, as a cross-level standard that applies across the whole pyramid rather than at any one band. That's the right instinct. An ISA-95 integration is exactly the kind of north-south traffic that 62443's zone-and-conduit thinking is meant to govern. So when we design the seam, the data model and the segmentation get drawn at the same time. Bolting security on afterwards is how a tidy integration turns into a finding.

Worth remembering, too, is that the traffic isn't one-way. Orders and schedules flow down from Level 4, but production performance has to flow back up, and that return path is where a lot of plants under-invest. The standard's transactions cover the reporting side as much as the dispatch side: what was actually made, how much material it consumed, where the line stopped. NIST notes that ISO 22400 sits alongside ISA-95 to define the key performance indicators used in operations management. Pair the two and the numbers your planners see (yield, availability, consumption) trace back to events the floor recorded, rather than to a spreadsheet someone reconciled by hand on a Friday. That traceability is half the reason to do the integration at all.

Where RAMI 4.0 picks up

ISA-95 was drawn for a factory with a fixed shape. The German Plattform Industrie 4.0 initiative argued that the shape itself is changing, and built the Reference Architectural Model Industrie 4.0, RAMI 4.0, around that argument. It's a three-axis model, and one of the axes is a stack of six layers describing any asset: Asset, Integration, Communication, Information, Functional and Business. It reads like the OSI stack for industrial things, from the physical object up to the business process it serves.

Here's the part that surprises people coming from a clean ISA-95 pyramid. RAMI keeps the familiar factory hierarchy (field device, control device, station, work centers, enterprise) but it doesn't stop there. It adds a level below for the Product itself, and a level above the enterprise for the Connected World. The neat five-band pyramid gets a basement and an attic. The product becomes a participant in the network rather than a passive thing being made, and the enterprise becomes one node among many beyond the plant fence. That reframing is the whole point of the Industrie 4.0 case, and it's why RAMI gets cited alongside ISA-95 rather than replacing it. One describes today's plant; the other sketches where the connections are heading.

For a working engineer, RAMI isn't something you install. It's a map for arguing about scope. When a digitalization project starts sprawling, the layers and axes give you a shared coordinate system to point at and say: this work is the Communication layer of the control device, that work is the Information layer of the product. It keeps the conversation honest about what's actually being built.

Where it breaks

Now the uncomfortable part. ISA-95 is a good standard, but the way it gets used on real projects has a few recurring pitfalls, and we've sat in the meetings where they surfaced.

The first common mistake is treating the standard as something you buy. You don't. You buy an MES, a historian, an integration broker, and each vendor claims ISA-95 alignment. Alignment is not conformance, and conformance is not the same as your two specific systems agreeing on what a material lot means. The models still have to be mapped by hand to your equipment, your materials, your shift structure. That mapping is the project. Underestimate it and the schedule slips. In our experience the first-year integration nearly always takes longer than the kickoff estimate, because the gap between a clean reference model and a plant with thirty years of accumulated naming conventions is wider than anyone wants to admit.

The second is semantic drift at the seam. Two systems can exchange perfectly valid B2MML and still disagree about meaning, because the same word, "batch" or "lot" or "downtime", carries different definitions on each side. The standard gives you a place to record the agreement. It can't force you to actually have the conversation. Skip it and you get the two-versions-of-the-truth problem the whole exercise was meant to prevent.

The third is the one NIST flags directly, and it's structural. In its review, the agency notes that within the manufacturing pyramid, communication standards are well established but interoperability among systems is somewhat limited, meaning that manufacturers typically are locked into a single vendor solution. ISA-95 narrows that gap; it doesn't close it. A standard tells you what the message should contain. It doesn't guarantee that two compliant products will swap messages without a custom adapter. So budget for that adapter, and don't assume the logo on the box does the work for you.

None of this is a reason to skip the standard. It's a reason to be sober about what it does. ISA-95 buys you a shared vocabulary and a tested set of models, which is a great deal more than starting from a blank page. What it doesn't buy you is an integration that works without engineering. Not every plant needs all of it either; a small single-product line may only ever touch the material and equipment models, and forcing the full apparatus onto it just adds cost.

How we approach it

When we scope a plant-floor-to-business integration, the standard is the frame, not the deliverable. We start by mapping the four resource models to what's physically on site, because that mapping is where the real disagreements hide. Then we decide the transport, B2MML or OPC UA, based on how the data is actually shaped and how far down the stack it needs to reach. Live telemetry from the instrument layer is where a lot of the value sits, and pulling it cleanly into the Level 3 picture is the kind of edge work our edge telemetry and analytics platform is built around. We treat the security zoning and the data model as one design, not two phases, because retrofitting either onto the other is where the cost overruns hide. The standard keeps everyone honest about the seam; the engineering is still the engineering.

One more habit worth keeping: write the mapping down as if the people who built it will leave, because they will. The single most durable thing an ISA-95 project produces isn't the running interface. It's the documented agreement about what each object means, kept somewhere the next engineer can find it. We've walked onto sites where the integration worked perfectly and nobody could explain why, which is its own kind of risk. A standard is only as useful as the team's willingness to keep its definitions current.

If you take one thing from this, take the seam. The plant runs. The business runs. The money and the risk live in the handoff between them, and ISA-95 is the best-tested way we have to make that handoff repeatable. Treat it as a dictionary, not a product, and it'll serve you for years.