ISA-95ANSI/ISA-95 — Enterprise-Control System Integration

ANSI/ISA-95 — published internationally as IEC 62264 — is the consensus reference model for how the business systems of a manufacturer connect to the systems that run the physical plant. It was developed by the International Society of Automation's SP95 committee starting in 1995, with Part 1 first published in 2000. The current edition of Part 1 is dated 2010 (and is functionally identical to IEC 62264-1). The standard is now eight parts, the most recent (Part 8 — Information Exchange Profiles) added in 2024.

ISA-95 does three things. First, it defines a layered functional hierarchy — the famous five-level pyramid — that lets architects, auditors and regulators argue about systems using the same vocabulary. Second, it defines the four object categories that the layers exchange: personnel, equipment, material and process segments (plus their physical-asset, capability and definition variants). Third, it specifies the XML serialisations (B2MML, maintained by MESA International) that turn the abstract objects into something a real ERP can actually post to a real MES.

The standard is deliberately implementation-neutral. It does not tell you which database to use, which message broker to deploy, or whose MES to buy. It tells you what an Operations Schedule looks like, what a Production Performance message must contain, and what "equipment hierarchy" means in a way that will survive a merger between two plants that previously used different words for the same thing. That neutrality is why every credible MES vendor — including V5 Ultimate — markets itself as "ISA-95 aligned" rather than "ISA-95 certified": the standard is a contract for integration, not a stamp on a product.

The image most engineers carry around in their head when they say "ISA-95" is the functional hierarchy pyramid. Each level has a distinct timescale, a distinct user, and a distinct system class.

The two boundary interfaces in this stack do most of the architectural work. The Level 3 ↔ Level 4 interface is the ERP-to-MES contract that Parts 1, 2, 5 and 8 specify in detail — and it is the interface where most enterprise-integration projects either succeed or fail. The Level 2 ↔ Level 3 interface is where MES meets SCADA/PLCs; ISA-95 leaves the wire protocol there to OPC UA and similar, and instead focuses on what the upper layer needs to receive (production segment responses, equipment events, alarms) to do its job.

Practitioners often talk about "ISA-95" as if it were one document. It is actually a family of eight, and the part numbers matter: a vendor that claims compliance with Part 1 is making a much weaker statement than one that implements Part 5. Here is the working set as of the 2024 revision.

Part 1 — Models and terminology (2010)

The foundation document. Defines the five-level hierarchy, the four object categories (personnel, equipment, material, process segments) and the umbrella vocabulary the rest of the parts rely on. Every conversation about ISA-95 implicitly cites Part 1.

Part 2 — Objects and attributes for enterprise-control integration (2018)

The data dictionary. Specifies, attribute-by-attribute, what a Material Definition, an Equipment Class, a Personnel Class and a Process Segment look like — and the eight transaction objects (Operations Capability, Operations Definition, Operations Schedule, Operations Performance and their plan/actual permutations) that move them between Level 3 and Level 4.

Part 3 — Activity models of MOM (2013)

Part 3 zooms inside Level 3 and decomposes it into the four MOM domains (production, quality, maintenance, inventory) and the eight activity groups every MOM system performs: definition management, resource management, detailed scheduling, dispatching, execution management, data collection, tracking and performance analysis. This is the part you point at when an auditor asks "what does your MES do?".

Part 4 — Objects and attributes for MOM integration (2018)

Where Part 2 standardises the L3↔L4 exchange, Part 4 standardises the intra-Level-3 exchange between the four MOM domains — so the production MES, the quality system (QMS/LIMS), the maintenance system (CMMS) and the inventory system (WMS) can share a coherent operations record without each one inventing its own object model.

Part 5 — Business-to-manufacturing transactions (2018)

The verbs. Defines the eight transaction patterns — Get, Show, Process, Acknowledge, Cancel, Confirm, Change, Response — and how they apply to each Part-2 object. This is the part that turns "we exchange a production schedule" into a state machine an integration team can actually build against.

Part 6 — Messaging service model (2014)

An abstract messaging model that says nothing about HTTPS or AMQP but tells you what guarantees (delivery, ordering, idempotency) the transport must provide. Most modern implementations satisfy Part 6 with REST + JSON or AMQP + B2MML over TLS.

Part 7 — Alias service model (2023)

Two plants merge; they have different codes for the same material. Part 7 standardises how a Level-3 system can present aliases to the Level-4 system without the operator having to know they exist. It is the part that becomes important the day a regulated manufacturer acquires another regulated manufacturer.

Part 8 — Information exchange profiles (2024)

The newest member of the family. Defines profile patterns that bundle the abstract parts above into concrete "what an ERP-to-MES integration must look like" packages — substantially reducing the contract surface every new integration has to negotiate from scratch.

ISA-95 Part 2 organises everything that moves between Level 3 and Level 4 into four categories. Each category has the same three forms: a class (the abstract type), a definition (the instance specification) and a property (the runtime measurement).

These four categories are the reason an ISA-95-aligned MES can claim to be "semantically interoperable" with any ISA-95-aligned ERP: the receiving system already knows what kind of thing each message is, what attributes it must carry, and how to relate it to the rest of its model.

ISA-95 Part 2 specifies eight named transactions for the ERP-to-MES boundary. Together they form the operational contract for "the ERP tells the MES what to make, the MES tells the ERP what got made".

1. Operations Capability — the MES tells the ERP what it can do right now (lines available, capacity, qualified personnel, materials on hand). Foundation for finite scheduling.
2. Operations Definition — the MES publishes the recipe / routing the ERP can plan against, including bill of materials, bill of resources and the process-segment sequence.
3. Operations Request — the ERP asks for execution of one or more operations segments ("make 5,000 units of SKU 1234 starting Monday 06:00").
4. Operations Schedule — the agreed plan: which Operations Request becomes which detailed schedule item, on which line, with which materials, using which personnel.
5. Operations Performance — the MES reports back: actual quantities, actual durations, actual material consumption, actual operators, actual deviations.
6. Operations Response — interim status (in-progress, paused, on-hold) sent back to the ERP for visibility.
7. Personnel / Equipment / Material master sync — the four object categories flow both ways so each side stays consistent.
8. Acknowledgements — every transaction has a defined acknowledgement so the integration can be made idempotent and recoverable.

Practitioners often conflate ISA-95 with its older sibling ISA-88 (Batch Control), but the two standards solve different problems and were designed to compose.

The two stitch together cleanly: an ISA-88 control recipe is a particular kind of ISA-95 Operations Definition; an ISA-88 batch report is a particular kind of ISA-95 Operations Performance. A regulated batch manufacturer needs both — ISA-95 to talk to the ERP, ISA-88 to express the recipe in a way the cell can execute it. The companion long-form page on /glossary/isa-88 covers the procedural model and the recipe hierarchy in detail.

ISA-95 is not itself a regulation, and no health authority requires you to implement it. It earns its place in regulated manufacturing for a different reason: it is the only widely-accepted vocabulary in which a CSV (Computer System Validation) report, a Part 11 / Annex 11 risk assessment, or a GAMP 5 system inventory can describe an MES without ambiguity. The regulations cited below all expect the regulated manufacturer to know where its electronic records live, who signs them, and how they relate to the ERP-side business record — and ISA-95 is the standard reference for that map.

• 21 CFR Part 11 (electronic records, electronic signatures) — applies to the Level-3 record because that is where operator interaction and electronic signature occur.
• EU GMP Annex 11 (computerised systems) — the same scope: the qualified validation focus is the Level-3 MES, not the ERP or the PLCs.
• 21 CFR 211 / EU GMP Part I (pharma cGMP) — the master production record, batch record, and review of production records all map to Level-3 artefacts; the inventory and procurement records map to Level 4.
• 21 CFR 820 / ISO 13485 (medical-device QSR) — the device history record (DHR) and device master record (DMR) are Level-3 artefacts; quality-system records sit on the boundary of Levels 3 and 4.
• 21 CFR 111 (dietary supplements cGMP) — the batch production record is a Level-3 artefact; supplier qualification and stability data span Levels 3 and 4.
• ISA-99 / IEC 62443 (industrial automation cybersecurity) — the network and trust-zone model in 62443 is layered on top of the ISA-95 functional hierarchy.

A defensible ISA-95 implementation does not mean printing the pyramid on a poster. It means making four concrete decisions and then living with them.

1. Draw the boundaries. Decide which system owns which object class. Materials are typically dual-mastered (ERP for SKU and price, MES for batch-specific lot data); personnel are usually mastered in HR, mirrored into MES; equipment is mastered in CMMS or MES; process segments live in MES.
2. Pick the transactions you will actually exchange. The Part-2 set has eight; most manufacturers start with Operations Schedule (down) and Operations Performance (up) plus material and personnel sync. Postpone Operations Capability and Operations Response until finite-capacity scheduling is genuinely on the roadmap.
3. Standardise the wire format. Pick B2MML XML or a JSON transposition of it; resist the urge to invent a bespoke schema. The point of the standard is that two systems built by two vendors can exchange messages without a per-customer mapping spreadsheet.
4. Make every transaction acknowledged and idempotent. Network blips happen; retries must not double-consume a lot. The Part-5 acknowledgement pattern is there for this exact reason — use it.

ISA-95 Part 3 names "performance analysis" as one of the eight MOM activity groups, but it deliberately stops short of standardising the KPIs themselves. That gap is filled by ISO 22400 (Key performance indicators for manufacturing operations management), published in two parts. ISO 22400-2 defines 34 KPIs — including the OEE family (Availability, Performance, Quality, OEE itself, NEE, TEEP) — with rigorous formulas, units and aggregation rules.

An MES that claims to be ISA-95 aligned and reports OEE should be using the ISO 22400-2 definitions. The most common subtle error in industry is computing Performance as "actual / theoretical" without specifying whether the denominator uses ideal cycle time, design cycle time, or nameplate speed — three different numbers that produce three different KPIs. ISO 22400 forces the question and gives the answer.

Mistake 1 — "We don't need MES, we have ERP"

An ERP cannot legally hold a 21 CFR 211 batch record, an ISO 13485 device history record, or a 21 CFR 111 batch production record, because those records require contemporaneous capture at the operator level and ERP UX is not designed for that. ISA-95 makes the architectural reason explicit: Level 4 timescales (days/months) cannot capture Level 3 events (seconds/minutes).

Mistake 2 — "Our SCADA is our MES"

SCADA owns supervisory control and alarms (Level 2). It does not own the procedural human work-order record, the electronic batch record, or the cross-equipment genealogy of a finished product. Treating SCADA as MES leaves a regulated record gap — and the fact that ISA-95 separates them by an entire level is the standard's way of saying "don't".

Mistake 3 — "We'll exchange Excel files"

Spreadsheet integration is the form-factor in which the most data-integrity findings are written. ALCOA+ (Attributable, Legible, Contemporaneous, Original, Accurate — plus Complete, Consistent, Enduring, Available) is much harder to satisfy when the integration layer is a manually saved .xlsx. ISA-95 Parts 5 and 6 exist precisely so the ERP-to-MES bridge does not have a human in the middle.

Mistake 4 — "Reinvent the recipe model"

ISA-88 already defines general / site / master / control recipes and the procedure / unit-procedure / operation / phase hierarchy. Most "custom" recipe models that vendors ship end up rediscovering this structure painfully. Use the standard.

Mistake 5 — "ISA-95 is just for batch"

ISA-95 is mode-neutral: it applies equally to batch (composed with ISA-88), discrete and continuous manufacturing. A medical-device manufacturer producing serialised units, a food-processor running a 24/7 mixing line, and a sterile-fill pharma plant all describe their operations in the same object vocabulary.

V5 Ultimate is a Level-3 MES/MOM platform built against the ISA-95 reference model. Its design choices are direct readings of the standard:

• Object model — Personnel, Items (Material), Equipment / Resources, and Formulas / Operations (Process Segments) are first-class, matching Part 2 categories one-to-one.
• Activity coverage — V5 covers all eight Part-3 activity groups: definition management (formulas, BOM, routings), resource management (personnel and equipment), detailed scheduling (planning board), dispatching (operator queues), execution management (kiosk + electronic work instructions), data collection (weigh, in-process check, deviation, photo, signature), tracking (lot genealogy, eBMR/eDHR), performance analysis (OEE/FPY/RFT to ISO 22400).
• ERP integration — V5's ERP bridge implements the Part-2/Part-5 transaction set against the major ERPs and emits B2MML-shaped payloads; the adapter layer maps to the customer's specific schema once.
• Level-2 ingress — V5's device bridge reads PLC tags, OPC UA endpoints, RS-232 scales and HID barcode readers; the readings are persisted with the operation-segment context Part 3 requires.
• Regulated record — eBMR (pharma), eDHR (medical device) and batch production record (food / dietary supplement) are the Level-3 records the standard expects an MES to own; V5 generates them as MMR-snapshotted, signed, immutable PDFs.