ISA-95 for Modern Manufacturing: A Practical Integration Architecture Without Replacing ERP or MES

TL;DR

• ISA-95 provides a governance framework for functional hierarchy, operational scope, and system ownership. It does not define an industrial ontology or complete manufacturing data model.

• ISA-95 hierarchy cannot resolve inconsistent tag meanings, event definitions, or identifiers without semantic contextualization.

• A modern reference architecture connects PLCs, SCADA, edge infrastructure, MES, ERP, and a separate decision layer while preserving each tier’s authority and latency requirements.

• Humble Operations sits above existing systems of record. It combines contextualized operational data, constraints, and frontline input to produce auditable recommendations without replacing ERP, MES, SCADA, PLCs, or edge infrastructure.

What ISA-95 actually governs in a modern architecture

ISA-95 governs functional responsibility, operational hierarchy, and information exchange between manufacturing and enterprise activities. It provides a common structure for deciding where an activity belongs and which systems exchange the related information. It does not prescribe a deployable database schema, industrial protocol, event bus, or ontology.

IEC 62264 defines that structure across several parts. Part 1 establishes models and terminology, and Part 2 defines object model attributes. Part 3 describes activity models for manufacturing operations management. Part 4 defines object model attributes for manufacturing operations management integration, while Part 5 defines transactions between business and manufacturing systems. Parts 6, 7, and 8 address messaging services, alias services, and information exchange profiles.

The ISA-95 equipment model places sites, areas, work centers, and work units within an enterprise hierarchy. Related models describe material, personnel, and process segments so ERP, MES, and other applications can exchange production requirements and performance records using shared business concepts. These reference models help you assign scope and ownership, but they do not determine identifier syntax or database keys. Implementers must also define payload schemas, event meaning, timestamps, and delivery behavior.

B2MML provides XML schemas based on ISA-95 concepts. Its XML schemas implement portions of IEC 62264 for exchanges such as production schedules, material information, and performance responses. B2MML works well for structured transactions between business and manufacturing applications, especially when both sides need explicit document contracts.

Real-time OT/IT convergence usually requires additional mechanisms. B2MML does not define transport behavior, broker topic structure, retained state, or quality of service. XML document exchanges can also carry more parsing and payload overhead than live telemetry needs. A modern architecture can therefore use ISA-95 to govern hierarchy and system boundaries while OPC UA, MQTT, Sparkplug, APIs, or batch files carry information according to the required latency and reliability.

Where ISA-95 hierarchy ends and semantic modeling begins

ISA-95 hierarchy defines where an object belongs and which operational scope contains it. Equipment classes describe types such as fillers or packaging lines, while equipment instances identify installed assets. Material classes and definitions organize categories such as resin grades or finished products. Those models support consistent scope and ownership, but they do not fully define the meaning of a live value.

Semantic models define what a value represents, how systems should interpret it, and which relationships surround it. A semantic model can specify that Speed represents spindle revolutions per minute, carries a stated unit, describes a measured rather than commanded value, and remains valid only while the machine runs. An industrial ontology can extend that definition by relating the measurement to an asset type, process capability, material, and production state.

A Unified Namespace organizes operational data under stable topics, often using ISA-95 equipment levels as the topic structure. The namespace transports context but does not create meaning by itself. Sparkplug B adds state awareness, metric metadata, and birth and death certificates to MQTT communication. OPC UA information models can define typed objects, variables, units, methods, and relationships. You still need governed identifiers and shared semantic definitions across those technologies.

Consider two plants that both publish Enterprise/Site/Packaging/Line1/Filler/Speed. One PLC reports motor revolutions per minute. The other reports a percentage of rated line speed. Both paths satisfy the same ISA-95 hierarchy, but an application that compares the values will produce invalid analysis. Even matching engineering units would not resolve whether each value represents an actual speed, a setpoint, or a rolling average.

You can prevent that failure by pairing the ISA-95 path with a governed metric identity, unit, data type, calculation rule, source, and validity condition. ISA-95 supplies organizational context. The semantic layer supplies machine-readable meaning, while the Unified Namespace, Sparkplug B, or OPC UA carries the contextualized state.

Namespace and identifier strategy across sites

Treat the ISA-95 equipment hierarchy as a naming contract, not as the physical database schema. A path such as enterprise/site/area/line/cell gives publishers and consumers a shared way to locate an asset. Databases can store the same relationships in relational tables, graph structures, or document records without copying the topic path into every key.

Globally unique identifiers should remain stable when names or hierarchy positions change. Use controlled enterprise and site codes to prevent Plant1 at one company from colliding with Plant1 at an acquired company. Pair each readable path with an immutable equipment identifier, and maintain redirects or aliases when equipment moves between lines.

Equipment identity and configuration version require separate controls. A renamed machine keeps its identifier, while a physical replacement normally receives a new one. Routing revisions, recipe changes, and line reconfigurations should receive version identifiers and effective dates. Consumers can then reconstruct which equipment and routing definition applied when an event occurred.

Rigid hierarchical topics make discovery and access control easier, but they couple subscribers to the current plant structure. A line move can break subscriptions even when the underlying asset remains unchanged. Flexible Unified Namespace topics and metadata tags support alternate views, but loose tagging can produce duplicate labels and inconsistent queries.

A practical design combines both approaches. Publish a governed canonical path, include the immutable asset identifier in each event, and attach metadata for equipment class, capability, and current relationships. Keep path construction rules in a central registry rather than embedding them independently in PLC, SCADA, MES, and edge configurations.

System-of-record boundaries: what belongs in MES, ERP, and the edge

System ownership should follow the authority to create or approve a fact, not the application that happens to display it. The MES, ERP, and decision-layer comparison provides a broader guide to choosing the right authority model. ISA-95 provides functional boundaries, but each implementation still needs a field-level ownership matrix. When MES and ERP both edit the same status independently, delayed messages and retries can produce conflicting records.

Work order state needs separate ownership for separate transitions. ERP can authorize release, cancellation, or commercial closure, while MES owns started, paused, and completed execution states. An integration contract should specify which system may issue each transition, how duplicate events are handled, and what happens when either system rejects an update.

Genealogy belongs in MES when MES records actual material lots, equipment, operations, and production timestamps. ERP can retain the inventory and shipment references needed for recall or financial processes. Copying full genealogy into both systems creates two records that can diverge after rework, substitution, or late data correction.

Quality holds require similar separation. MES or a dedicated quality system should enforce the hold on the shop floor because production and material movement depend on current status. ERP should own the resulting inventory, shipment, or financial restrictions. A single disposition event should update both views without granting both applications authority to release the hold.

Edge infrastructure should own collection continuity, protocol normalization, timestamp handling, and temporary buffering. Edge software should not become the permanent authority for work orders, genealogy, or quality disposition. Offline edge logic may preserve safe local operation, but MES and ERP must reconcile buffered events after connectivity returns.

A decision layer consumes authoritative records without taking ownership of them. Humble Operations can combine contextualized operational data with constraints and frontline context, then return auditable recommendations. MES and ERP retain approval authority and record any accepted action in their existing histories.

Edge computing responsibilities in the ISA-95 stack

Industrial edge computing defines a deployment boundary near production assets, not a formal ISA-95 level. Edge nodes may serve functions associated with Levels 1 through 3, depending on the plant architecture. SCADA supervises equipment and gives operators control, while edge infrastructure moves, buffers, transforms, and analyzes data for other systems.

Protocol translation lets an edge gateway connect equipment that cannot publish a common format. A gateway might read Modbus registers or proprietary PLC tags, map them to stable equipment identifiers, and publish contextualized events through OPC UA or MQTT. Translation should preserve source timestamps, engineering units, quality codes, and equipment identity. Without those attributes, downstream systems receive values that they cannot interpret reliably.

Store and forward buffering protects event continuity during network loss. An edge node records events locally, retains their original timestamps and sequence, and forwards them after connectivity returns. Consumers must handle delayed and duplicate events because retries can deliver the same observation more than once. Buffer capacity should reflect the expected outage duration, data rate, and recovery bandwidth.

Deterministic control remains with PLCs or dedicated controllers. General-purpose edge software cannot safely assume responsibility for motion control, interlocks, or other loops that require bounded execution times unless the platform and application meet the required control guarantees. Edge applications can support lower-urgency responses, such as calculating a condition score every second or notifying SCADA when a threshold persists.

Offline operation requires explicit rules for each edge workload. Data acquisition may continue without upstream access, while local dashboards can read cached state. Applications that depend on MES orders, ERP material status, or centrally managed constraints should stop, degrade predictably, or use a time-limited cached copy. Each workload needs a defined authority boundary during disconnection.

Model inference fits at the edge when latency, bandwidth, or data sensitivity favors local execution. Vision inspection and anomaly scoring can produce events locally instead of sending raw streams upstream. The edge should return observations, scores, and evidence to the authoritative application. It should not create unofficial work order states, genealogy records, quality dispositions, or production schedules. Those actions would turn an inference service into a shadow MES and create conflicting records.

Event flow and latency classes across the stack

Latency requirements should follow the consuming function rather than a single plantwide target. Each tier should process events at the speed needed for its decisions, while slower tiers receive filtered or aggregated data.

Control tier | Milliseconds

PLCs, drives, and safety controllers execute deterministic logic locally. Control loops should never depend on an enterprise broker, MES response, or cloud connection because network jitter can violate process deadlines.

Edge and SCADA tier | Seconds

SCADA and industrial edge computing handle alarms, equipment state, protocol conversion, and short-term buffering. OPC UA suits structured equipment access when a client needs to browse, read, subscribe, or write specific values. Local applications can still operate during upstream outages.

MES tier | Minutes

MES consumes production events such as operation completion, material consumption, quality results, and work order state changes. MES transactions need ordering, idempotency, and traceable acknowledgments, but most do not require control loop timing.

ERP tier | Hours or batches

ERP exchanges schedules, inventory postings, costing data, and business master data through APIs, files, or scheduled jobs. ERP integrations should favor transaction integrity and reconciliation over event speed.

MQTT with Sparkplug B fits asynchronous distribution when several consumers need equipment state. MQTT provides publish-and-subscribe transport, while Sparkplug B adds topic conventions, typed payloads, and device lifecycle state. OPC UA supports direct access to structured industrial data, and OPC UA PubSub supports event distribution. ERP APIs suit bounded business transactions that require explicit validation and acknowledgment.

Routing every latency class through one undifferentiated bus creates avoidable coupling. Without separate topics, retention policies, consumer isolation, and flow controls, high-frequency telemetry can burden business integrations while retries and broker delays make time-sensitive actions unpredictable. A safer event flow publishes operational facts upward and sends commands downward only through validated interfaces with clear authority, acknowledgment, and timeout rules.

Security zones and OT/IT trust boundaries

ISA-95 hierarchy should not determine security trust. Enterprise, site, area, and work cell boundaries describe operational scope, while ISA/IEC 62443 zones group assets with common security requirements based on risk. Conduits define the permitted communication between those zones. A production line may span several security zones even when ISA-95 treats it as one equipment hierarchy.

You should define each conduit by source, destination, protocol, direction, and authentication method. For example, an edge gateway may read PLC data within a control zone and publish contextualized events through a broker in an industrial DMZ. A decision layer can consume those events from an IT zone. Any MES or ERP write back should use a separate, restricted conduit rather than an inbound session to a PLC.

The ISA/IEC 62443 series divides responsibility among asset owners, integrators, product suppliers, and service suppliers. The asset owner accepts risk and approves zone boundaries. The integrator configures conduits and verifies deployed controls. Product suppliers provide component security capabilities and supported update paths. Service suppliers follow the approved remote access, identity, and change procedures. Contracts should name the owner for each control because shared responsibility alone does not establish accountability.

Brownfield patch management requires a separate control plan. Legacy PLCs, SCADA servers, and engineering workstations may depend on vendor validated versions or operating systems that no longer receive updates. Production windows may also prevent timely deployment. ISA/IEC 62443-2-3 addresses patch management in industrial automation environments, where an IT patch schedule may conflict with safety and availability requirements.

When an asset cannot be patched promptly, you should document the exception and reduce exposure through tighter zone isolation. Application allowlisting or monitored jump access can add protection where the asset supports them. Greenfield designs can specify maintainable products and update procedures before commissioning, while brownfield designs must account for installed dependencies and limited outage windows.

A reference architecture: PLC to ERP to decision layer

An authority-preserving reference architecture separates operational data flow from command authority. Operational data moves through PLC and SCADA, edge contextualization, MES, and ERP. Commands follow governed paths in the opposite direction. Each tier retains responsibility for the decisions that require its latency, state, and controls.

PLCs own deterministic machine logic, interlocks, and direct input and output control. SCADA supervises equipment, presents current state, and records operator interactions. Neither tier should depend on ERP, MES, or a remote decision service to maintain safe control.

Edge infrastructure converts controller tags into contextualized events. The guide to monitoring versus decision-ready manufacturing data explains how contextualization turns telemetry into data that downstream applications can interpret. It assigns stable equipment and material identifiers, preserves source timestamps and quality codes, and buffers events during network loss. The edge can publish data to MES, historians, or other approved consumers without becoming an unofficial execution system.

MES owns the execution records assigned to it by the plant’s governance model. Those records commonly include dispatch state, production declarations, genealogy, and quality status. ERP remains authoritative for business objects such as customer demand, inventory valuation, purchasing, and financial commitments. When both systems represent a work order, the integration contract must name which system owns each field and state transition.

A decision layer reads selected data from the edge, MES, and ERP. It combines current operating conditions with constraints and frontline context, then produces a recommendation with its inputs, reasoning, and expected effect. Humble Operations fits at this tier. It operates above the existing stack rather than taking ownership of execution or transactional records.

Write-back should carry recommendations through controlled interfaces. A decision layer might create a proposed schedule, queue an approval task, or submit an accepted change through an MES or ERP API. The receiving system validates permissions and state before committing the change, while the audit record preserves the recommendation, approval, and final outcome.

The decision layer owns no system of record and holds no control loop authority. It also should not replace the MES or ERP data model with a private canonical model. Its internal representation may normalize inputs for analysis, but source identifiers and ownership boundaries must remain traceable. Read-mostly access and narrowly scoped write-back let the decision layer deliver recommendations without becoming a competing authority.

Brownfield implementation sequencing

Brownfield sequencing should prove one bounded integration path before you standardize the plant. A plant should also determine whether the first bottleneck requires new connectivity or whether existing data needs a decision layer, as explained in this system integration diagnostic.

1. Normalize identifiers on one production line. Inventory PLC addresses, SCADA tags, historian points, and MES asset records. Assign each asset a stable canonical identifier based on the ISA-95 equipment hierarchy, and retain source aliases so existing applications keep working. Avoid renaming PLC tags unless operations already planned a control change.

2. Contextualize data at the edge. Map source tags to equipment, material, operation, timestamp, unit, and quality definitions. Edge services should translate legacy PLC protocols, preserve source timestamps, and buffer events during network loss. Validate undocumented tag maps with controls engineers and operators rather than inferring meaning from tag names.

3. Integrate only the required MES and ERP records. Choose one use case and identify the authoritative sources it needs. A scheduling use case might consume work orders from ERP, execution status from MES, and current machine state from the edge. Keep ownership with each source system, and document how conflicts or stale records are handled.

4. Add decision layer consumption after the data path is trustworthy. The decision layer can combine contextualized operating data with constraints and frontline context, then return auditable recommendations. Start with read access and human approval. Introduce limited write-back only after you define permissions, validation rules, rejection handling, and an audit trail.

5. Scale the tested pattern by template. Reuse identifier rules, edge mappings, ownership boundaries, and interface contracts at the next line or site. Treat each rollout as a mapping exercise because identical machine types may expose different tags or firmware behavior.

Legacy protocols, undocumented tag maps, and partial historian coverage make greenfield sequencing unreliable. A greenfield design can assume consistent interfaces and complete telemetry. A brownfield plant must verify those assumptions at every boundary. Missing historian data may reflect collection gaps rather than downtime, while a familiar tag name may carry different units or state codes on another line. Sitewide rollout should wait until the pilot detects and handles those differences.

Failure modes in ISA-95 integration projects

ISA-95 integration failures usually appear at boundaries between hierarchy, meaning, timing, and authority. You can diagnose them through recurring operating symptoms.

• A rigid ISA-95 schema makes routine changes expensive. Designers sometimes encode the full equipment hierarchy and activity model into every database table and message payload. Moving a machine or revising a route then requires schema migrations across several applications. Repeated mapping work and delayed equipment changes indicate that the hierarchy has become an inflexible enterprise data model.

• A namespace without semantic context produces ambiguous data. An equipment path can identify a line and cell, but the path does not define a tag’s unit, state model, timestamp source, or quality status. Integrators compensate with custom mappings for each consumer. Conflicting dashboards, duplicate alerts, and line-specific analytics reveal missing contextualization.

• One event bus cannot satisfy every latency class. PLC control traffic, SCADA updates, MES transactions, and ERP messages operate on different timing and availability requirements. An undifferentiated bus can create backlogs when integrations lack consumer isolation, flow controls, or separate retention and routing policies. Stale dashboards, delayed work order updates, and alert fatigue indicate that designers collapsed latency tiers without buffering or routing policies.

• Unclear write authority creates MES and ERP sync drift. If both applications can change work order status, quality holds, or material consumption, retries and delayed messages can overwrite newer records. Repeated reconciliation jobs and oscillating statuses reveal an undefined system of record. Each business object needs one authoritative writer and explicit rules for acknowledgments, corrections, and exceptions.

• Recommendations become unauditable when integrations discard context. A decision layer cannot reproduce a recommendation without source identifiers, timestamps, constraint versions, and approval history. Operators then see different answers without evidence explaining the change. Controlled write-back should preserve the recommendation, supporting inputs, human decision, and receiving system response.

Comparison table: architecture layers, ownership, and evaluation questions

Each tier should own a bounded set of records and operate at the latency its decisions require.

See How Humble Fits Your Existing ISA-95 Stack

Humble operates as a decision layer above your existing ERP, MES, SCADA, PLC, and edge infrastructure. It consumes contextualized operational data, production constraints, and frontline knowledge to return auditable recommendations tied to supporting evidence. Your existing systems remain authoritative for transactions, production records, and control.

Take the 60-second fit test to see whether Humble fits your current ISA-95 architecture.

Vendor evaluation questions for an ISA-95-aligned decision layer

A credible decision layer should preserve existing authority boundaries and explain every recommendation. Ask vendors these questions before discussing models or dashboards.

1. Which records do you read, and which records do you write?

Require a field-level answer for MES, ERP, historian, and edge sources. The vendor should distinguish recommendations, approved transactions, and autonomous writes. Broad write access can create a second source of truth.

2. Can an operator inspect the reasoning behind each recommendation?

The audit record should include source data, active constraints, model or rule version, user approval, and write-back status. A confidence score alone does not explain why the system recommended a schedule change.

3. Which latency tier does the product support?

A decision layer that operates on minute-level production data should not claim control loop authority. Ask for measured ingestion and computation latency, plus write-back latency under normal conditions and during network loss.

4. What must we replace before deployment?

A decision layer should consume existing ERP, MES, SCADA, and edge data through bounded interfaces. Mandatory migration of work orders, genealogy, or master data may indicate a concealed MES replacement.

5. How does the product map plant identifiers and semantics?

Ask whether the vendor preserves ISA 95 equipment paths, handles site-specific tag meanings, and versions mappings when assets change. A dashboard that matches fields manually will become difficult to maintain across sites.

6. How are approvals, failures, and reversals handled?

The vendor should support human approval, idempotent writes, rejected transaction handling, and rollback procedures. Ask which system records the final state after a failed update.

Shortlists may span broad data platforms such as Palantir, frontline application platforms such as Tulip, machine monitoring products such as MachineMetrics, and connected workforce products such as Redzone. Compare each candidate by the authority it assumes, rather than by the category name it uses.

Talk to Humble About Your Integration Architecture

A call with Humble can help you evaluate whether a decision layer fits your current architecture. The discussion can cover data ownership, read and write boundaries, latency requirements, and how recommendations return to existing systems without transferring system-of-record authority.

Book a call with Humble to assess where decision intelligence fits above your ERP, MES, SCADA, PLC, and edge infrastructure.

Get ISA-95 and OT/IT convergence insights in your inbox

Get practical guidance on ISA-95 architecture, industrial edge computing, and OT/IT convergence through the Humble Operations newsletter.

FAQs

Is ISA-95 still relevant with Unified Namespace and MQTT architectures?

ISA-95 still provides useful boundaries for equipment hierarchy, operational activities, and ownership. A Unified Namespace and MQTT define how systems organize and exchange live data, but neither decides which application owns a production order, material definition, or equipment identity. You can use ISA-95 for governance while using MQTT topics and semantic models for transport and context.

Does a decision layer need to be ISA-95 compliant?

A decision layer does not need formal ISA-95 compliance, but it should preserve the hierarchy and ownership rules used by connected systems. Its data mappings should trace recommendations back to stable equipment, material, order, and personnel identifiers. The decision layer should adapt to the existing manufacturing data model rather than impose a replacement model on MES or ERP.

How does ISA-95 relate to IEC 62443 zones?

ISA-95 groups manufacturing functions by operational scope, while the ISA/IEC 62443 series provides cybersecurity requirements and guidance for industrial automation and control systems. Architects can use ISA-95 boundaries as inputs when defining security zones and permitted conduits, but the hierarchies do not automatically produce secure network segmentation. Security design still requires risk assessment, access controls, and explicit communication rules.

What breaks first when retrofitting ISA-95 onto a brownfield plant?

Equipment identity and tag meaning usually break before hierarchy design. Legacy PLC names, undocumented tag maps, reused identifiers, and inconsistent material codes prevent applications from resolving the same asset or production state. Start with one line, establish stable identifiers, document semantic mappings, and validate event quality before expanding the model.

Can a decision layer write back to MES or ERP safely?

A decision layer can write back safely when each action uses a narrow, authorized interface with validation and an audit trail. Human approval should govern consequential changes such as schedule release, quality disposition, or order status until operating evidence supports greater automation. MES and ERP should remain authoritative, and failed writes must not create conflicting state or bypass normal transaction controls.

Apply ISA-95 without replacing ERP or MES

Use ISA-95 to govern hierarchy, ownership, and system boundaries without treating it as a complete data model. Semantic contextualization then gives operational events consistent meaning, while a decision layer uses that context to produce auditable recommendations without taking authority from ERP, MES, or control systems.

When unclear identifiers, ownership disputes, or inconsistent site models block integration, start with one production area and prove the model before expanding it.

Plants should address foundational issues first when unreliable controls, undocumented tags, or missing source data prevent trustworthy contextualization. New ERP or MES software will not resolve those architecture problems by itself.