What Is B2MML? The ISA-95 Data Exchange XML

Back to Blog

How B2MML Works

B2MML is a collection of XML schemas that mirror the ISA-95 information models. For each ISA-95 object, such as a production schedule or a report of production performance, B2MML provides a corresponding schema that says exactly which elements and attributes a valid document contains. When one system needs to send a production schedule to another, it produces an XML document that conforms to the B2MML schema, and the receiving system, knowing the same schema, can parse it reliably. The schema is the shared contract that makes the exchange unambiguous.

The reason this matters is that ISA-95 on its own is a set of models, not a wire format, so two vendors could both claim ISA-95 alignment yet still be unable to exchange a file. B2MML closes that gap by giving everyone the same XML structure to target. It is the practical companion that lets the ISA-95 model move from a whiteboard diagram to messages flowing between systems, which is why integrators reach for it when a real interface has to be built.

Where It Fits in the Integration

B2MML lives at the boundary between operations management and business planning, the Level 3 to Level 4 interface in ISA-95 terms. That is where production schedules flow down from planning and production results flow back up, and it is exactly the exchange ISA-95 was created to structure. B2MML is the format those messages take across that boundary, so it sits where MES and ERP meet rather than down on the plant floor with the controllers and SCADA tags.

Because it is XML, B2MML is transport-agnostic: the same document can move over a message queue, a web service, or a file drop, and the choice of transport is separate from the choice of format. This separation is deliberate and useful, because it lets an integration adopt the standardized content structure without dictating the plumbing. The equipment hierarchy that ISA-95 defines is reflected in how B2MML documents reference the equipment a schedule or result pertains to.

Design and Adoption Considerations

The main design decision with B2MML is which parts of it to use, because a full integration rarely needs every schema. Most projects adopt the schemas for the specific exchanges they perform, such as production schedule and production performance, and profile them to the fields their systems actually populate. Agreeing that profile up front, so both sides fill and read the same elements, is what turns a nominally standard interface into one that works in practice.

Adoption also means accepting XML's verbosity in exchange for its interoperability and tooling. B2MML documents are larger and more explicit than a bespoke format would be, but that explicitness is the point: any system that knows the schema can validate and parse them without a custom parser. For an ISA-95-aligned integration, that predictability is usually worth the extra size, especially where more than two systems have to understand the same messages.

Failure Modes

The common failure is two systems that both claim B2MML support but profile it differently, so one populates fields the other ignores or expects fields the other never sends. B2MML guarantees a shared structure, not a shared interpretation of every optional element, so an agreed profile is essential. When an interface passes validation yet the receiving system gets no useful data, a profile mismatch is the usual cause.

The other failure is treating B2MML as if it dictated transport or timing, which it does not. B2MML is a content format; how often documents are sent and over what channel are separate decisions. Blaming the format for a late or missed message usually points instead at the transport or the triggering logic, which live outside B2MML entirely and have to be designed on their own.

Frequently Asked Questions