ISA-95 and ISA-99: Industrial Automation Standards Guide (2026)

Last Updated: October 2026

Most engineers can recite the Purdue model, and most of them are slightly wrong about it. They remember five or six boxes stacked on a slide, a firewall drawn between two of them, and a vague belief that “ISA-95 says Level 2 is the MES”. It does not. ISA-95 is a standard about responsibilities and information exchange, not about network topology, and the picture most people carry around fuses it with a different body of work, the Purdue Enterprise Reference Architecture and the security standard once called ISA-99.

That confusion is expensive. It produces integrations where every ERP-to-shop-floor interface is bespoke, and security architectures where a flat “Level 3” network holds forty unrelated systems because the diagram had one box there. In 2025 the ISA-95 Part 1 text was revised for the first time since 2010, and the security family, now IEC 62443, has kept growing, so the reference material in most blog posts is out of date.

This guide separates the three ideas properly, gives you the data models you actually code against, and ends with a worked integration. The thesis: levels describe who decides, zones describe who may talk, and a Unified Namespace is just ISA-95’s equipment hierarchy finally used as an address space.

What this covers: the correct ISA-95 level definitions, the part-by-part structure of IEC 62264, the object and activity models, B2MML, how ISA-99 became IEC 62443, a fair critique of the Purdue model, and a runnable worked example.

Context and Background

Three lineages get blended under the “ISA-95” label, so name them first.

The Purdue Enterprise Reference Architecture (PERA) came out of Purdue University’s work in computer-integrated manufacturing in the late 1980s, led by Theodore Williams. It is an enterprise modelling framework. The familiar layered “Purdue model” diagram, with its numbered levels and an enterprise zone at the top, is a simplification of that framework that the industrial security community adopted, and later extended with a “Level 3.5” demilitarized zone that appears in vendor reference designs rather than in the ISA-95 text.

ISA-95 is the ANSI/ISA standard family, adopted internationally as IEC 62264 and titled “Enterprise-Control System Integration”. It was developed by the ISA95 committee to answer one question: which information must pass between business planning and manufacturing control, in what structure, and who owns each piece. The first edition appeared around the turn of the millennium. Part 1 was updated as ANSI/ISA-95.00.01-2025 (IEC 62264-1 Mod), announced by ISA in April 2025 as an update to the 2010 edition that clarifies the boundary between enterprise and manufacturing domains and tightens consistency with other parts.

ISA-99 is the original name of ISA’s industrial cybersecurity committee. Its output was developed jointly with the IEC as the ISA/IEC 62443 series, and the committee and its documents are now commonly referenced as ISA/IEC 62443. When someone says “ISA-99 zones and conduits”, they mean what the IEC 62443 family defines. Our deeper treatment lives in IEC 62443 zones and conduits for industrial control systems, and the regulatory side is mapped in the EU CRA, NIS2 and IEC 62443 comparison.

The standards are complementary, not competing. ISA-95 tells you what a “production schedule” or “equipment capability” looks like as data. IEC 62443 tells you how to partition and harden the systems that carry it. PERA and its Purdue diagram are the mental scaffold both communities borrowed.

The commercial context matters too. MES, ERP, historian and quality vendors all claim ISA-95 alignment, which in practice ranges from “our equipment model has Site and Area” to full B2MML message support. Reading the standard yourself is the only way to judge those claims. The primary sources worth keeping open are the ISA-95 standards page at isa.org and the IEC 62443 overview, whose part table is a handy index even if you should buy the actual documents for normative detail.

A correction to a common pattern, including to an earlier version of this very post: many summaries place the MES at “Level 2” and ERP at “Level 3 and 4”. In the ISA-95 functional hierarchy, manufacturing operations management is Level 3, and Level 2 is monitoring and supervisory control. We use the correct assignment throughout.

The ISA-95 Functional Hierarchy and the Parts of IEC 62264

Direct answer. ISA-95 defines five levels, 0 to 4, as a functional hierarchy: Level 4 business planning and logistics, Level 3 manufacturing operations management, Level 2 monitoring and supervisory control, Level 1 sensing and manipulating, Level 0 the physical process. Levels group responsibilities by time horizon and decision type. They are not network segments, and the standard does not require one network per level.

Figure 1: The ISA-95 functional hierarchy. Solid arrows carry instructions down, dotted arrows carry results up.

Figure 1 shows the shape. Instructions flow down as increasingly specific commitments, and results flow up as increasingly aggregated facts. Each level exchanges information mainly with its neighbours, and the interesting boundary, the one the standard spends most of its pages on, is between Level 4 and Level 3.

Why the 3/4 boundary is the one that matters

Level 4 thinks in orders, due dates, cost and inventory valuation over days and months. Level 3 thinks in work orders, resources, quality holds and shift performance over minutes and hours. Levels 2 and below think in seconds and milliseconds. The qualitative break between “plan” and “do” sits at 3/4, and that is where integration projects fail: ERP wants to send a sales-driven production order, while the plant needs to know which lines, people, material lots and recipes can execute it today.

ISA-95 therefore defines the 4-to-3 exchange as a set of structured objects: what to make, with what, when, and what actually happened. Part 2’s object models cover those objects, Part 5 defines the transactions, and Part 3 describes the activities inside Level 3 that consume and produce them.

The parts at a glance

The current series, per the ISA standards page, is:

Part	Title	Edition noted by ISA
1	Models and Terminology	ANSI/ISA-95.00.01-2025 (IEC 62264-1 Mod)
2	Objects and Attributes for Enterprise-Control System Integration	2018 (IEC 62264-2 Mod)
3	Activity Models of Manufacturing Operations Management	2013 (IEC 62264-3 Mod)
4	Objects and Attributes for Manufacturing Operations Management Integration	2018
5	Business-to-Manufacturing Transactions	2018
6	Messaging Service Model	2014
7	Alias Service Model	2017
8	Information Exchange Profiles	2020

Editions for Parts 4 to 8 were inferred from product links on ISA’s page rather than stated in headings, and the IEC 62264 counterparts have their own edition years that differ, so check the exact edition against your purchase order before citing it in a contract. Treat the ISA/IEC mapping as “Mod” adoption: the ANSI documents are modified adoptions, not identical copies.

The equipment hierarchy: the quiet gem

Part 1 also defines a role-based equipment hierarchy: enterprise, site, area, then below area either process cell, production unit, production line or storage zone, and below those, units, work cells or storage units. This is separate from the functional levels, and it is the part of ISA-95 that the UNS community borrowed wholesale. An address like Acme/Hamburg/Packaging/Line3/Filler01 is an ISA-95 equipment path in disguise. We come back to that in the Unified Namespace section.

Two distinctions prevent most confusion. First, functional level answers “what kind of decision is this”, while equipment hierarchy answers “which physical or logical thing is it about”. A MES Level 3 function operates on a work center in an area. Second, the standard defines domains of control by who executes, so a function “belongs” to the level whose responsibility it is, even if the software runs on a server a continent away. Cloud deployment moves software, not responsibility.

Where the numbers come from: time horizons

The old summaries attach exact cycle times to every level. The standard itself is looser: it cites approximate time scales (months/weeks/days for Level 4, shifts/hours/minutes/seconds for Level 3, seconds down to sub-second for Levels 2 and 1, and “may be much faster” for Level 0). Use the following as an engineering rule of thumb, not a normative requirement:

Level	Typical decision horizon	Typical artefacts
4	days to months	forecast, order, inventory valuation
3	minutes to shifts	work order, lot genealogy, OEE, quality result
2	100 ms to seconds	alarms, trends, operator actions, batch phases
1	1 ms to 100 ms	control loops, interlocks, motion
0	physics	temperature, flow, position

The practical implication is that a Level 3 system should never sit inside a control loop. If your MES has to answer within 50 ms to keep a machine running, the function has been misallocated, and the architecture will be fragile no matter how fast the network is.

Object Models, Activity Models and B2MML

Direct answer. ISA-95 Part 2 models resources (personnel, equipment, physical assets, material) and four information flows between planning and operations: definition, capability, schedule and performance. Part 3 breaks Level 3 into generic activities. B2MML is the XML implementation of these models, maintained by MESA International, which lets two systems exchange them without custom parsing.

The resource and information model

The Part 2 data model is built from a small number of ideas that repeat. There are four resources: personnel, equipment, physical assets (the tangible things that equipment is made of, such as tooling, which have their own lifecycle), and material. There is a process segment, the smallest logical unit of work that a business cares about, such as “mix” or “fill”, which names the resources it needs. And there are four information families, each applying to production, maintenance, quality and inventory (the four operations categories Part 3 addresses):

Definition: what can be made or done and how (product definition, operations definition, work master).
Capability: what is available right now (equipment capability, material on hand).
Schedule: what is requested (production schedule containing production requests).
Performance: what actually happened (production performance containing production responses and segment responses).

The elegance is the symmetry: a request in the schedule has a matching response in the performance, structured identically so the two can be compared line by line. If the request asked for 10,000 units of product P on line 3 with two operators, the response reports actual quantity, actual equipment, actual personnel, actual start and end, and consumed material lots.

Part 3: the generic operations activity model

Figure 2: A simplified rendering of the Part 3 generic activity flow, from ERP request to performance report.

Part 3 describes Level 3 as eight generic activities. They are resource management, definition management, detailed scheduling, dispatching, execution management, data collection, tracking, and performance analysis. Figure 2 shows how the information families flow through them. Detailed scheduling takes the ERP’s coarse request and splits it into sequenced work against actual capability. Dispatching releases it. Execution management drives the work, data collection pulls measurements from Level 2 and below, tracking builds the genealogy, and performance analysis produces the response sent back to Level 4.

The model repeats for each of the four operations categories (production, maintenance, quality, inventory). That is why modern “MOM” (manufacturing operations management) platforms claim to cover more than a classic MES: the generic model says a maintenance work order and a production work order have the same lifecycle skeleton, so they can share engines. Whether a given vendor actually shares engines or just shares a marketing slide is something you should verify in a demo.

B2MML in practice

B2MML (Business To Manufacturing Markup Language) is a set of XML Schema (XSD) files that implement the ISA-95 object models, published by MESA International. The current line recommended on the MESA site at the time of writing is V0700, packaged with BatchML. Its structure follows Part 2 closely, with top-level documents such as ProductionSchedule, ProductionPerformance, EquipmentInformation, MaterialInformation and PersonnelInformation.

A simplified, illustrative ProductionPerformance (element names follow the B2MML style but this is trimmed for readability and will not validate against the full schema without the required wrapper elements) looks like this:

<ProductionPerformance xmlns="http://www.mesa.org/xml/B2MML">
  <ID>PP-2026-004711</ID>
  <ProductionResponse>
    <ID>WO-88231</ID>
    <ProductionRequestID>WO-88231</ProductionRequestID>
    <StartTime>2026-10-08T06:02:11Z</StartTime>
    <EndTime>2026-10-08T13:58:40Z</EndTime>
    <SegmentResponse>
      <ID>FILL</ID>
      <ProcessSegmentID>FILL</ProcessSegmentID>
      <EquipmentActual>
        <EquipmentID>Hamburg/Packaging/Line3/Filler01</EquipmentID>
      </EquipmentActual>
      <MaterialProduced>
        <MaterialDefinitionID>SKU-1204</MaterialDefinitionID>
        <Quantity>
          <QuantityString>9874</QuantityString>
          <UnitOfMeasure>EA</UnitOfMeasure>
        </Quantity>
      </MaterialProduced>
    </SegmentResponse>
  </ProductionResponse>
</ProductionPerformance>

Three things to notice. The equipment ID reuses the hierarchy path, so the performance record is addressable and joinable. The response ID matches the request ID, which is what makes request-versus-response reconciliation mechanical. And quantities carry units explicitly, which sidesteps the classic “kilograms versus pounds” interface bug.

Part 5 defines the transaction verbs that wrap such documents. In B2MML practice they appear as paired verbs, such as Get and Show, Process and Acknowledge, Change and Respond, Cancel and Confirm, and Sync. Part 6 defines the messaging service model (a transport-independent interface), and Part 8 introduces information exchange profiles, which are meant to let vendors pre-agree subsets of the models so that “supports ISA-95” becomes testable. I could not verify the exact current verb list against the 2018 edition of Part 5, so confirm it in the document before generating code from it.

What B2MML is bad at

B2MML is verbose and document-oriented. It is excellent for a nightly schedule download or an end-of-order performance report and poor for streaming a thousand state changes per second. Teams that force every telemetry value through B2MML create exactly the brittle, slow integration the standard was meant to prevent. The sensible split is: B2MML (or JSON equivalents of the same models) for Level 4/3 business transactions, and lightweight topic-based messaging for Level 3/2 events. That split is the core of the integration example later in this guide.

From ISA-99 to IEC 62443: Zones, Conduits and Security Levels

Direct answer. ISA-99 is the former name of the ISA committee whose work became ISA/IEC 62443. Its central idea is partitioning an industrial automation and control system (IACS) into zones of equal security requirement connected by conduits that are the only permitted paths between them, then assigning each zone a target security level and proving the design reaches it.

The series is a map of roles, not one document

IEC 62443 is organised by who has to act. According to the series overview, the published documents include these:

Part	Subject	Audience
1-1	Concepts and models (Technical Specification, 2009)	everyone
2-1	Security program requirements for IACS asset owners (Ed. 2.0, 2024)	asset owner
2-3	Patch management (Technical Report, 2015)	asset owner, integrator
2-4	Requirements for IACS service providers (Ed. 2.0, 2023)	integrator, maintainer
3-2	Security risk assessment and system design (2020)	integrator, owner
3-3	System security requirements and security levels (2013)	integrator, system supplier
4-1	Secure product development lifecycle requirements (2018)	product supplier
4-2	Technical security requirements for IACS components (2019)	product supplier

Further parts (1-5 profiles scheme, 6-1 evaluation methodology) exist, and others such as 1-6 on IIoT, 2-2 and 6-2 were listed as under development at the time of the source I used. Verify the live status before building a compliance plan around any of them.

Two practical points. The 2013 edition of 3-3 is still the system-level requirements document most buyers cite, and the 2024 refresh of 2-1 is the one that updated the asset owner’s program requirements. A product supplier proves itself against 4-1 (the process) and 4-2 (the component features); an integrator proves itself against 2-4 (service provider capability) and designs to 3-2 and 3-3; the owner runs the program under 2-1. If you only buy components that claim “62443-4-2 certified” you have addressed one cell of this matrix.

Zones, conduits and the risk-to-requirement chain

The design workflow in 3-2 runs in a fixed order, and each step feeds the next:

Define the system under consideration and inventory its assets and data flows.
Perform an initial high-level risk assessment to understand worst-case consequences, for example safety harm or environmental release.
Partition into zones and conduits. Group assets that share security requirements, communication patterns and criticality. A zone is a logical or physical grouping, and it can contain sub-zones.
Assign a target security level (SL-T) per zone and per conduit from a detailed risk assessment.
Select countermeasures from 3-3, and components that meet 4-2, until the achieved security level (SL-A) is at least SL-T.
Operate and maintain under 2-1 and 2-3, and re-assess when the system changes.

Security levels SL 1 to SL 4 describe resistance to progressively more capable adversaries: SL 1 protects against casual or coincidental violation, SL 2 against intentional violation using simple means with low resources, generic skills and low motivation, SL 3 against sophisticated means with moderate resources, IACS-specific skills and moderate motivation, and SL 4 the same with extensive resources and high motivation. Importantly the standard distinguishes target (SL-T), achieved (SL-A) and capability (SL-C) levels, and they should not be used as a generic product label; a PLC’s SL-C is a statement about what the component can support when configured correctly, not a claim that the plant is at that level.

The seven foundational requirements

Part 3-3 and 4-2 organise technical requirements under seven foundational requirements (FR): identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability. Restricted data flow is the one that directly implements the zone-and-conduit idea, because it demands segmentation and control of traffic between zones. Resource availability reminds you that in OT, availability and safety outrank confidentiality, which inverts the classic IT priority order.

A worked example of the SL arithmetic: suppose a packaging cell zone has SL-T 2, and the design uses a conduit to the site operations zone. For each of the seven FRs the zone gets a target vector, say (2,2,2,1,2,2,2) where data confidentiality is deliberately set lower because the signals are non-sensitive process values. The integrator then checks every component’s SL-C vector: a PLC that supports SL 2 on six FRs and SL 1 on resource availability (it cannot withstand a traffic flood) leaves a gap of one on FR7. Compensating controls, such as rate limiting at the conduit’s firewall, can close the gap on paper, but they must be documented, and the compensation belongs to the system design (SL-A), not to the PLC’s own capability.

Where the sequence goes wrong

The two common failure modes are scope and drift. Scope: teams define “the plant” as one zone, so SL-T becomes a blunt number that no one can verify. Drift: the model is accurate on commissioning day and wrong 18 months later because a vendor added a remote-access appliance. 62443-2-1 is explicitly a program standard to fight drift, which is why it is aimed at the asset owner rather than the integrator.

The Purdue Model Under Pressure: What Survives, What Breaks

Direct answer. The Purdue diagram survives as a reasoning aid for dependency direction and blast radius. It breaks as a literal network blueprint, because modern plants have cloud services reaching down, wireless sensors bypassing controllers, remote vendor access, and publish-subscribe data planes that make “one level talks to its neighbour” untrue in practice.

Four ways reality departs from the diagram

Vertical shortcuts. An IIoT sensor with a cellular modem sends vibration data straight to a vendor cloud, skipping Levels 1 to 3 entirely. A smart drive exposes OPC UA to the enterprise network. Whatever your diagram says, the data path decides the risk.

Horizontal data planes. A message broker accessible by many levels turns the stack into a hub. This is the essence of the Unified Namespace pattern; see Unified Namespace architecture with HiveMQ and Sparkplug B for a reference build and UNS versus data mesh versus data fabric for the data-architecture debate.

Level 3 is a catch-all. In the security reading of Purdue, everything from the MES to the historian to the patch server to the engineering workstation lands in “Level 3”. Those have wildly different trust profiles. A compromised engineering workstation can reprogram controllers; a compromised report server cannot. Treating them as one zone forgoes the one thing 62443 offers.

Remote access and supply chain. A vendor VPN into the line, an update channel for a robot controller, a SaaS maintenance platform: none have a natural slot in a five-level picture, yet they dominate real incident reports.

What to keep

Keep the dependency principle: lower levels should keep running when higher levels fail. A line must produce even when the ERP is down, so the MES buffers, the PLC never needs the MES to complete a cycle, and the safety function never depends on a network at all. This is a resilience rule long before it is a security rule, and it survives every architecture fashion.

Keep the DMZ. Even in a UNS world, a broker cluster in an industrial DMZ with outbound-only connections from the plant is the sensible default. Our zero trust architecture for industrial OT and IoT post shows how to layer identity on top of that segmentation rather than replacing it.

Keep zones as the unit. Replace “Level” with “zone” when you write security requirements. Levels classify function; zones classify trust and traffic. They often align, which is why people conflate them, and the places they diverge are where incidents happen.

UNS as ISA-95’s address space

A Unified Namespace organises current plant state as a hierarchical topic tree on a message broker, typically MQTT. The hierarchy is nearly always the ISA-95 equipment hierarchy: enterprise, site, area, line, cell. Publishers write state to the topic that represents the thing; consumers subscribe. That is the opposite of point-to-point integration, and it reduces the number of interfaces from N times M to N plus M.

Notice what has not changed. The meaning of a “production performance” payload, the identity of equipment, the work order lifecycle: those still come from ISA-95 Part 2 and Part 3. The UNS replaces the transport and topology assumptions, not the information model. If your UNS has topic names but no agreed payload semantics, you have rebuilt the problem ISA-95 was written to solve. For the transport details, compare Sparkplug B and plain MQTT topics and the OPC UA FX versus MQTT Sparkplug B and UNS analysis.

Figure 3: A zones-and-conduits view of an ISA-95 plant with a UNS broker in the industrial DMZ. Conduits, not levels, are the controlled paths.

Figure 3 redraws the plant as zones. The broker is not a level; it is a zone with its own target security level, TLS and access control lists, and it is the only entity both the enterprise and the plant talk to. Only the edge gateway initiates connections upward, and it initiates outbound, so no inbound path into the cell exists. Each arrow is a conduit with its own protocol, authentication and monitoring requirement.

Worked Integration: ERP Order to Line Counters and Back

Direct answer. Use B2MML-style documents for the ERP to MES business transaction, an ISA-95 equipment path as the UNS topic prefix for events between MES and the line, and a conduit-aware gateway between them. The same work order ID travels through every hop, so the ERP can reconcile the request against the performance response.

Figure 4: End-to-end sequence for one work order. Business documents travel at the edges and lightweight events travel in the middle.

The scenario

A plant in Hamburg runs Line 3. ERP releases work order WO-88231 for 10,000 units of SKU-1204. The MES schedules it on the filler, the PLC counts good and rejected units, and at completion the MES sends a performance report. Everything below is illustrative; the numbers are made up to show the arithmetic.

Step 1: derive the topic from the equipment path

The first piece of code is trivial and prevents the most common UNS defect, ad hoc topic names. It builds topics from the equipment hierarchy and validates that no segment contains MQTT wildcards or spaces.

import re

LEVELS = ("enterprise", "site", "area", "line", "cell")
SEGMENT = re.compile(r"^[A-Za-z0-9_-]+$")

def topic(path: dict, kind: str, name: str) -> str:
    """Build a UNS topic from an ISA-95 equipment path.
    kind is one of: state, metric, event, workorder
    """
    parts = []
    for lvl in LEVELS:
        seg = path.get(lvl)
        if seg is None:
            break
        if not SEGMENT.match(seg):
            raise ValueError(f"illegal segment {lvl}={seg!r}")
        parts.append(seg)
    if kind not in {"state", "metric", "event", "workorder"}:
        raise ValueError(kind)
    if not SEGMENT.match(name):
        raise ValueError(name)
    return "/".join(parts + [kind, name])

line3 = {"enterprise": "Acme", "site": "Hamburg",
         "area": "Packaging", "line": "Line3", "cell": "Filler01"}
print(topic(line3, "metric", "good_count"))
# Acme/Hamburg/Packaging/Line3/Filler01/metric/good_count

The validation matters more than it looks. MQTT’s + and # are subscription wildcards, and a stray space or slash inside a segment silently changes the hierarchy depth and breaks every wildcard subscription that assumed a fixed depth.

Step 2: the data-collection loop and a performance builder

The next sketch collects counters from the broker and builds a ProductionPerformance document for the work order. It uses the paho-mqtt client (version 2 callback API) and the standard library XML builder. It is a minimal teaching sketch, not a hardened service: it omits reconnect logic, persistence and schema validation.

import json, threading
import xml.etree.ElementTree as ET
import paho.mqtt.client as mqtt

NS = "http://www.mesa.org/xml/B2MML"
state = {"good": 0, "reject": 0, "start": None, "end": None}
lock = threading.Lock()
BASE = "Acme/Hamburg/Packaging/Line3/Filler01"

def on_message(client, userdata, msg):
    payload = json.loads(msg.payload)
    with lock:
        if msg.topic.endswith("metric/good_count"):
            state["good"] = int(payload["value"])
        elif msg.topic.endswith("metric/reject_count"):
            state["reject"] = int(payload["value"])
        elif msg.topic.endswith("event/run_state"):
            if payload["value"] == "RUNNING" and not state["start"]:
                state["start"] = payload["ts"]
            if payload["value"] == "COMPLETE":
                state["end"] = payload["ts"]

def build_performance(wo: str, sku: str) -> bytes:
    ET.register_namespace("", NS)
    q = lambda t: f"{{{NS}}}{t}"
    root = ET.Element(q("ProductionPerformance"))
    ET.SubElement(root, q("ID")).text = f"PP-{wo}"
    resp = ET.SubElement(root, q("ProductionResponse"))
    ET.SubElement(resp, q("ID")).text = wo
    ET.SubElement(resp, q("ProductionRequestID")).text = wo
    ET.SubElement(resp, q("StartTime")).text = state["start"]
    ET.SubElement(resp, q("EndTime")).text = state["end"]
    seg = ET.SubElement(resp, q("SegmentResponse"))
    ET.SubElement(seg, q("ProcessSegmentID")).text = "FILL"
    eq = ET.SubElement(seg, q("EquipmentActual"))
    ET.SubElement(eq, q("EquipmentID")).text = BASE.split("/", 1)[1]
    mp = ET.SubElement(seg, q("MaterialProduced"))
    ET.SubElement(mp, q("MaterialDefinitionID")).text = sku
    qty = ET.SubElement(mp, q("Quantity"))
    ET.SubElement(qty, q("QuantityString")).text = str(state["good"])
    ET.SubElement(qty, q("UnitOfMeasure")).text = "EA"
    return ET.tostring(root, xml_declaration=True, encoding="utf-8")

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2)
client.on_message = on_message
client.tls_set()                      # conduit C2 requires TLS
client.connect("uns.dmz.example", 8883)
client.subscribe([(f"{BASE}/metric/#", 1), (f"{BASE}/event/#", 1)])
client.loop_forever()

When the COMPLETE event arrives you call build_performance("WO-88231", "SKU-1204") and send the result to the ERP adapter over the HTTPS conduit. A real implementation would validate against the B2MML XSD for the exact version your ERP accepts, handle partial quantities and rework, and carry the material lot IDs that make recall genealogy possible.

Step 3: the arithmetic of why UNS beats polling here

Assume the filler exposes 40 tags, and the MES polls them at 1 Hz with a 60-byte average payload including protocol overhead (an assumption for illustration). That is 40 x 60 = 2,400 B/s per line, or about 19 kbit/s. For 25 lines, the traffic is about 480 kbit/s, trivial for the network but 1,000 request-response transactions per second for the MES to process. With report-by-exception, where a tag publishes only when it changes beyond a deadband, a typical mix of slowly changing process values and counters might publish only 5 to 10 percent of the time, cutting the MES’s inbound event rate by an order of magnitude. The saving is not bandwidth; it is the load on the consumer and the avoidance of request-response coupling. Your actual ratio depends entirely on the deadband and the process, so measure it before sizing anything.

Step 4: conduit enforcement in code and in the firewall

A zone-and-conduit design is only real if it is machine-checkable. A short script can compare a documented conduit list to observed flows from a flow log and fail a CI job on anything undocumented:

import csv, sys

ALLOWED = {  # (src_zone, dst_zone, proto, port)
    ("enterprise", "dmz", "tcp", 443),
    ("dmz", "ops", "tcp", 8883),
    ("ops", "cell", "tcp", 4840),
    ("cell", "dmz", "tcp", 8883),
}

def check(flow_csv: str) -> int:
    bad = 0
    with open(flow_csv) as f:
        for r in csv.DictReader(f):
            key = (r["src_zone"], r["dst_zone"], r["proto"], int(r["port"]))
            if key not in ALLOWED:
                print("UNDOCUMENTED CONDUIT:", key, "bytes", r["bytes"])
                bad += 1
    return bad

if __name__ == "__main__":
    sys.exit(1 if check(sys.argv[1]) else 0)

Notice the allowed list contains the cell-to-DMZ MQTT flow, the outbound-only gateway from Figure 3, and has no rule at all from the enterprise zone to the cell. The tests that matter are the negative ones. If the check passes because the flow log is empty, you have a logging problem, not a secure plant, so assert a minimum flow count as well.

Step 5: reconcile request against response

The business value of the symmetrical model shows up at the end. The ERP compares the 10,000-unit request to the response. Suppose the response reports 9,874 good units and 126 rejects, so yield is 9,874 / 10,000 = 98.74 percent against the order, and the shortfall of 126 units triggers a follow-on order. Availability, performance and quality terms for OEE come from the same data: if planned production time was 8.0 hours, run time 7.93 hours (the example uses 06:02:11 to 13:58:40), then availability is 7.93 / 8.0, about 0.991, before counting downtime events inside the window. Because every term derives from the same request and response objects, finance, quality and operations argue about decisions, not about whose spreadsheet is right.

Trade-offs, Gotchas, and What Goes Wrong

Standards are a vocabulary, not a product. ISA-95 compliance is not a certification a vendor holds. Claims range from using Site and Area labels to full Part 5 transactions with Part 8 profiles. Ask for the specific parts, message types and schema versions in writing, and test with your own sample documents.

Over-modelling. Part 2 can describe nearly everything, and teams sometimes try to. A 400-attribute equipment model that nobody maintains is worse than a 40-attribute model that is current. Model what a decision depends on. If no consumer reads an attribute, delete it.

Equipment identity drift. The most common production failure in UNS and MES projects is that the same machine has three names in three systems. ISA-95’s hierarchy only helps if one system is the authority for identifiers and the others reference it. Choose the authority (often the MES or an asset registry) before the first topic is created, because renaming a topic path later breaks every historian tag, dashboard and subscription.

Time and ordering. A performance document is only as good as its timestamps. PLC clocks, edge gateway clocks and the broker’s clock disagree by default. If you build lot genealogy from events with unsynchronised timestamps, a start event can appear after its first count. Use NTP or PTP appropriately for the zone and record both the device timestamp and the broker receive timestamp.

Security-level inflation. Setting SL-T 3 for every zone sounds safe and is not: it forces countermeasures that the legacy PLCs in the zone cannot support, so the design is quietly non-compliant. Differentiating SL-T by consequence, with justification, is both cheaper and more honest.

Treating the broker as a level. Putting the UNS broker in “Level 3” and giving it a flat trust boundary makes it the highest-value target in the plant: it can read everything and, if writes are permitted, change setpoints. Restrict writers per topic prefix, forbid control-affecting writes from enterprise identities, and keep command topics separate from state topics.

Transaction semantics. MQTT at-least-once delivery means duplicates. If your performance builder counts events rather than reading monotonic counters, a retransmitted message double-counts. Prefer cumulative counters with sequence numbers, and make consumers idempotent on message ID.

Availability versus confidentiality. Controls borrowed from IT can cause outages: aggressive account lockout on an HMI at 3 a.m., an endpoint agent scanning a controller’s engineering workstation during a batch, a certificate expiry that drops every OPC UA session. Test every control against the question “what happens to production if this fails closed”.

Practical Recommendations

Start by separating the three documents in your own organisation. Keep one page that states the information model (ISA-95 parts you adopt and which system owns each object), a second that states the zone model (zones, SL-T per zone, conduits), and a third for the transport and namespace conventions (topic grammar, payload schema, QoS rules). The three evolve at different speeds and are owned by different people, and mixing them is the origin of most “architecture diagrams” that satisfy no one.

Adopt the equipment hierarchy before any tooling. It is the cheapest, highest-leverage use of ISA-95, and it pays back immediately in the namespace, the historian tag model, the digital twin and reporting. For the twin-side payoff, see digital twin MES manufacturing execution reference architecture and digital twin and unified namespace as an industrial data fabric.

For brownfield sites with serial or Modbus equipment, put a gateway at the edge, publish to a namespace built on the hierarchy, and do not rewrite controllers; the brownfield Modbus to UNS gateway comparison covers the options.

Checklist:

Confirm which ISA-95 / IEC 62264 parts and editions each vendor actually supports, in writing.
Name an authority system for equipment, material and personnel identifiers.
Allocate every function to a level by responsibility, and keep Level 3 systems out of control loops.
Replace “Level” with “zone” in security requirements; assign SL-T per zone with a written rationale.
Put the broker in a DMZ zone, outbound-only from the cell, with per-prefix write permissions.
Use B2MML or equivalent only for business transactions; use topic events for telemetry.
Make the conduit list machine-checkable and fail builds on undocumented flows.
Re-run the 62443-3-2 assessment after any change that adds remote access or a new vendor.

Frequently Asked Questions

What is the difference between ISA-95 and ISA-99?

ISA-95 (IEC 62264) standardises the models and information exchanged between enterprise systems and manufacturing operations: levels, equipment hierarchy, objects and activities. ISA-99 is the former name of the committee whose work is published as ISA/IEC 62443, which standardises how industrial control systems are secured using zones, conduits and security levels. One defines what information moves where, the other defines how the paths and systems are protected. Most plants need both.

What are the levels of ISA-95?

ISA-95 defines five functional levels. Level 0 is the physical process, Level 1 is sensing and manipulating (field devices and controllers), Level 2 is monitoring and supervisory control (SCADA, HMI, batch control), Level 3 is manufacturing operations management (MES and MOM), and Level 4 is business planning and logistics (ERP). They group responsibilities by decision horizon. They are functional levels, not mandated network segments, which is a frequent misreading.

Is the Purdue model the same as ISA-95?

No. The Purdue Enterprise Reference Architecture is a separate enterprise modelling framework from Purdue University, and the popular layered Purdue diagram is a simplified derivative used heavily in OT security. ISA-95 borrows the layered view for its functional hierarchy. Additions such as a Level 3.5 industrial DMZ and a Level 5 cloud or internet tier appear in vendor and security reference designs, not in the ISA-95 text itself.

What is B2MML and do I need it?

B2MML is an XML schema implementation of the ISA-95 object models, maintained by MESA International, with V0700 the version recommended on its site at the time of writing. You need it, or an equivalent JSON mapping, when exchanging orders, schedules and performance reports between ERP and MES or between MES products. You do not need it for high-rate telemetry, where MQTT or OPC UA messaging is a better fit.

Is ISA/IEC 62443 mandatory?

The standard itself is voluntary, but it is increasingly referenced by regulation and procurement. In the EU, harmonised or referenced use under NIS2 and the Cyber Resilience Act is discussed widely, and many asset owners write 62443 conformance into supplier contracts. Check your sector and jurisdiction, because legal obligations come from the regulation, not from the standard. Our compliance mapping post compares the overlaps and gaps between the three regimes.

Does a Unified Namespace replace ISA-95?

No. A Unified Namespace replaces point-to-point integration and the assumption that data must climb the stack one level at a time. It typically uses the ISA-95 equipment hierarchy for its topic structure and still relies on ISA-95 style models for payload meaning. A UNS without shared semantics is just a faster way to move incompatible data, so the standard becomes more relevant, not less.