Ask a room full of controls engineers what ISA-95 is, and you’ll get a confident answer: it’s the standard that separates Level 3 (MES, operations management) from Level 4 (ERP, business planning). That’s true, and it’s also the least useful part of the standard if you’re the person actually wiring up an integration. The Level 3/4 pyramid is Part 1. The parts that tell you what data actually crosses that boundary — and in what shape — are Part 2 and Part 4. Almost nobody outside a standards committee has read them closely, which is exactly why vendors can write “ISA-95 compliant” on an RFP response with very little risk of being challenged.
That’s a problem right now because so many plants are touching their integration layer at once — S/4HANA migrations forcing a rethink of ERP-to-MES interfaces, MES re-platforming projects, Unified Namespace rollouts that promise to normalize everything into a common model. Every one of those projects generates a vendor claim of ISA-95 or B2MML compliance. Very few buying teams can actually check that claim against the schema. This piece is about closing that gap.
What ISA-95 Part 4 actually is
ISA-95 (formally ANSI/ISA-95, also published as IEC 62264) is a multi-part standard. Part 1 defines the models and terminology — the Level 3/4 hierarchy, equipment hierarchy, and role-based equipment models people usually mean when they say “ISA-95.” Part 2 defines object models and attributes for exchanging information between business and manufacturing systems: things like Personnel, Equipment, Material, and Process Segment. Part 4 takes those Part 2 object models and defines the activity models that actually move through a plant’s operations: Production Schedule, Production Performance, Product Definition, and — the one most people have never actually seen laid out — the Operations Request and Operations Response.
B2MML, Business To Manufacturing Markup Language, is not itself part of the ISA-95 standard. It’s an open-source XML implementation of the ISA-95 Part 2 and Part 4 object models, maintained under the World Batch Forum / MESA International umbrella. When a vendor says their integration is “B2MML-based,” they mean their XML payloads are structured according to these published schemas rather than some proprietary tag set. That distinction matters: ISA-95 defines the model, B2MML defines the wire format. A system can be conceptually ISA-95-aligned without using B2MML at all, and a system can throw B2MML tag names into an XML file without actually respecting the model underneath them. That second case is where most fake compliance claims live.
The Operations Request: what it actually contains
Here’s where it gets concrete. In Part 4’s Production Schedule model, the core exchange object is the OperationsRequest — essentially ERP or a planning system telling the MES layer “make this, this way, by this time.” It is not just a work order number and a quantity. The schema structures it as a hierarchy:
- OperationsRequest — the header: ID, description, priority, requested start and end, and a status.
- OperationsSchedule — one or more schedule entries under the request, each referencing a segment of work.
- SegmentRequirement — this is the real payload. It ties back to a ProcessSegment (defined in Part 2) and carries the personnel, equipment, material, and physical asset requirements for that segment — each expressed as its own sub-object (PersonnelRequirement, EquipmentRequirement, MaterialRequirement, PhysicalAssetRequirement).
- ProductionParameter — segment-level or request-level parameters, each with a name, value, and unit of measure, using a generic Property/Value pairing rather than fixed fields.
The corresponding response side, ProductionPerformance, mirrors this structure back with actuals: what personnel actually worked the segment, what material was actually consumed, what quantities were actually produced, and actual start/end timestamps, again organized into segments rather than one flat record.
Notice what’s not in there: there’s no field called “work order number” as a rigid, fixed schema element with that exact meaning baked in. ISA-95 deliberately keeps the model generic — IDs, descriptions, and a flexible property structure — because the standard has to accommodate discrete, batch, and continuous processes without assuming any one of them.
Mapping a real work order onto the schema
Say your MES has a work order: build 500 units of a subassembly on Line 2, third shift, using a specific lot of raw material, with a torque spec and a cure-time parameter that must be logged. Mapped honestly into B2MML, that becomes:
- An OperationsRequest with the work order ID as the request ID, and a requested start/end matching the shift window.
- One SegmentRequirement referencing a ProcessSegment for “Subassembly Build,” with a quantity of 500 in its associated quantity element.
- An EquipmentRequirement pointing at Line 2 (or its equipment ID per the Part 2 equipment hierarchy).
- A MaterialRequirement referencing the specific lot number, not just a material master ID.
- Two ProductionParameter entries — one for torque spec, one for cure time — each carrying a name, a value, and a unit of measure.
If a vendor’s “ISA-95-compliant” template instead ships you a flat XML file with a WorkOrderNumber, Quantity, and LineID as top-level siblings and stuffs torque and cure time into a generic “notes” or “custom fields” blob, that’s not a Part 4 Operations Request. It might be a perfectly serviceable integration, but it’s using B2MML-adjacent tag naming without the actual segment/requirement hierarchy that makes the standard useful — namely, the ability to swap process segments, reuse equipment and personnel requirement definitions across different requests, and let a receiving system parse structure rather than guess at field meaning from a flat file.
How to actually check a vendor’s claim
When “ISA-95 compliant” or “B2MML-based” shows up in an RFP response, ask for a sample payload — not documentation, the actual XML. Then check three things. First, does it nest SegmentRequirement objects under a schedule, or is everything flattened to one level? Second, are equipment, personnel, and material requirements expressed as distinct typed objects, or crammed into generic key-value pairs? Third, do parameters carry units of measure as structured attributes, or are they buried in free text? None of this requires you to memorize the full XSD. It requires knowing that the model is hierarchical and object-typed by design, and that flattening it defeats the purpose of adopting the standard at all.
The honest caveat: full B2MML compliance is genuinely heavy for a lot of shop-floor integrations, and plenty of well-run plants use a simplified, ISA-95-inspired schema rather than the literal B2MML XSDs, because their scope doesn’t need the full generality. That’s a legitimate engineering choice. What’s not legitimate is calling that simplified schema fully compliant on a procurement document without saying so. Once you’ve actually looked at Part 4, you’re one of the few people in the room who can tell the difference — and that’s worth more than the acronym on the slide.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
