Two industrial systems can be technically connected and still fail to understand one another.
ERP can send a production order to MES.
MES can receive information from equipment.
A historian can store thousands of process tags.
A CMMS/EAM can maintain the asset hierarchy.
A quality system can hold inspection and conformity records.
Yet when somebody asks a basic operational question—
“Which material, on which equipment, under which production order and process conditions, produced this result?”
—the answer may still require several applications, a spreadsheet and somebody who understands how the plant is actually organised.
This is the difference between connectivity and semantic interoperability.
Connectivity allows systems to exchange data.
Interoperability requires that the receiving system can interpret that data with sufficient shared meaning to use it correctly.
That distinction is what makes ISA-95, B2MML and OPC UA particularly relevant to modern industrial architecture.
They address a persistent manufacturing problem:
How can different systems describe the same industrial reality without creating a new translation exercise every time they communicate?
The Integration Problem Is Often Semantic Before It Is Technical
Industrial integration discussions frequently begin with technology.
Which protocol?
Which middleware?
Which API?
Edge or cloud?
MQTT or OPC UA?
REST or messaging?
These questions matter.
But they are often asked before a more fundamental question has been resolved:
What exactly are the systems trying to communicate about?
Suppose ERP identifies a resource as:
LINE_04
MES calls it:
AREA2_PACK_LINE
SCADA refers to:
PLC17
The historian stores its signals under:
Packaging.Cell04.*
and maintenance represents the same physical production line through several equipment records.
Every system may be internally consistent.
The architecture can still be operationally incoherent.
The first challenge is identity: do these identifiers refer to the same physical or logical resource?
The deeper challenge is semantic: what does that resource represent within the manufacturing model, and how is it related to orders, operations, materials, events and production results?
A temperature value alone does not tell an enterprise application:
-
which equipment generated it;
-
which operation was being executed;
-
which material was being processed;
-
which production order was active;
-
whether the value represents normal production, setup or testing;
-
or how the measurement relates to the broader manufacturing context.
This is why digital manufacturing cannot be reduced to interface connectivity.
Data integration without shared semantics can move ambiguity faster without actually removing it.
ISA-95 Provides a Common Manufacturing Vocabulary
ISA-95 is valuable because it provides a structured way to describe important manufacturing concepts and the information exchanged between enterprise and manufacturing operations.
At a practical level, it gives architecture and operations teams a common vocabulary around concepts such as:
-
personnel;
-
equipment;
-
materials;
-
process segments;
-
production schedules;
-
production performance;
-
capabilities;
-
definitions;
-
and actual results.
That common vocabulary matters because different industrial layers require different levels of information.
ERP does not need every PLC tag.
A PLC does not need the financial structure of the enterprise.
MES/MOM requires enough business and manufacturing context to translate production requirements into execution and to return trustworthy evidence of what occurred.
The value of ISA-95 is therefore not that every plant must implement a theoretically perfect architecture.
Its practical value is that teams do not need to invent a completely different language for the same industrial concepts in every integration.
Without common definitions, every interface becomes a bilateral negotiation.
What does “equipment” mean in this system?
What constitutes an operation?
Is this quantity planned, dispatched, started, produced or completed?
Does a material identifier represent a product, raw material, intermediate material or production lot?
Which timestamp represents the relevant production event?
Which equipment hierarchy applies?
Which system owns the definition?
Every unresolved semantic question becomes integration debt.
Where B2MML Fits
B2MML—Business To Manufacturing Markup Language—provides XML schemas based on ISA-95 models.
The technical mechanism is less important than the architectural principle.
Without a common representation, two systems may describe equivalent manufacturing concepts using completely different structures, names and relationships.
One interface may refer to:
Order_Number
Machine_Code
Product_SKU
Target_Qty
while another uses:
WorkOrder
Resource
Material
Quantity
Both may be technically valid.
But every additional system now requires somebody to determine what each field means, which concepts correspond, how hierarchies map and how those mappings should be maintained.
B2MML provides a standardised representation for many ISA-95 concepts used in system exchange.
In simplified terms:
ISA-95 provides the conceptual manufacturing model. B2MML provides one structured way of representing many of those concepts electronically.
This can be particularly useful when structured manufacturing information must move between enterprise and manufacturing systems.
Production schedules.
Material information.
Equipment capability.
Operations definitions.
Production responses.
Performance information.
B2MML does not remove integration work.
Plant-specific models still exist.
Master data still requires governance.
System capabilities still differ.
Business rules still need to be agreed.
Mappings may still be necessary.
Its value is more practical: integration teams can begin from a shared model rather than redefining the manufacturing meaning of every interface from first principles.
Where OPC UA for ISA-95 Fits
OPC UA approaches industrial interoperability from another direction.
Its significance is not limited to transporting values between endpoints.
OPC UA can expose information models.
That distinction is fundamental.
A basic connectivity layer might expose something equivalent to:
Tag_123 = 72.4
The receiving system receives a value.
But what is Tag_123?
Which equipment does it belong to?
What does the measurement represent?
How is the equipment related to the rest of the production structure?
A richer information model can expose data as part of identifiable industrial objects and relationships rather than as disconnected signals.
ISA-95-oriented OPC UA information models extend this principle by bringing manufacturing concepts into that modelling environment.
Instead of communicating only individual values, applications can work with more structured representations of concepts such as:
equipment,
hierarchies,
capabilities,
materials,
operations,
and production context.
The important architectural shift is therefore from isolated tags towards contextualised industrial information.
That does not mean every consuming application requires every possible relationship.
It means the architecture has a mechanism for preserving meaning beyond the raw value itself.
B2MML and OPC UA Are Not Competing Answers to the Same Question
Industrial architecture discussions easily become technology competitions.
B2MML versus OPC UA.
OPC UA versus MQTT.
API versus messaging.
Edge versus cloud.
This framing is rarely useful.
Different technologies address different architectural concerns.
B2MML has traditionally provided a structured mechanism for representing and exchanging ISA-95-oriented enterprise and manufacturing information.
OPC UA is particularly valuable for structured industrial interoperability and information modelling around operational and equipment environments.
A manufacturing architecture may therefore use both, together with other technologies.
For example, enterprise systems may communicate production requirements towards manufacturing operations using structured business-to-manufacturing exchanges.
MES/MOM may manage execution context.
Industrial equipment and automation systems may expose contextualised information through OPC UA.
Historians may retain high-frequency process values.
Other mechanisms may distribute events, analytics results or cloud-bound information.
There is no requirement for one technology to perform every role.
The useful architecture question is not:
“Which standard wins?”
It is:
“Which information must move between which systems, at what level of detail, with what meaning, ownership, frequency and operational purpose?”
Technology selection should follow that question.
MES/MOM Often Provides Critical Execution Context
This becomes particularly important around manufacturing operations management.
A controller may know whether a motor is running.
A PLC may know an actual cycle time.
A machine may report an alarm.
Those signals do not necessarily contain the complete manufacturing context required by higher-level applications.
They may not independently know:
-
which production order is active;
-
which material lot is being consumed;
-
which operator qualification is relevant;
-
which recipe version is approved;
-
whether a stop is planned or unplanned;
-
which quantity is good, rejected or reworked;
-
or whether a process deviation affects product genealogy.
MES/MOM often provides an important part of this execution context.
It connects physical events with manufacturing objects such as orders, materials, operations, resources and production states.
This is why MES should not be reduced to a data-collection layer.
If the requirement were merely to acquire industrial values, modern connectivity technologies could satisfy much of that need.
Manufacturing execution requires something more:
context about what the plant is doing while those values are being generated.
A machine generates signals.
MES/MOM can help connect those signals to the manufacturing activity they represent.
Consider a Production-Completion Scenario
Imagine ERP schedules:
-
Product A;
-
5,000 units;
-
on Packaging Line 4;
-
for Order 45821.
MES executes the order.
During production:
-
two material lots are consumed;
-
three operators work across the shift;
-
one short equipment stop occurs;
-
37 units are scrapped;
-
a recipe parameter changes within approved limits;
-
and the final good quantity is 4,963 units.
At completion, several functions require different views of the same production reality.
ERP requires production confirmation.
Quality requires genealogy.
Operations requires performance information.
Maintenance requires the downtime context.
The historian contains detailed process trends.
If each system interprets line, order, lot, event, operation and time differently, reconstructing the production event becomes unnecessarily difficult.
A common information model helps preserve the relationships.
The important operational output is not merely:
4,963 units completed.
It is the evidence behind those 4,963 units.
Which equipment executed the order?
Which materials were consumed?
Under which process conditions?
Over which time period?
Which deviations occurred?
Which losses were recorded?
Which execution definition or version applied?
This is what allows digital manufacturing to move beyond isolated transactions towards a traceable representation of operational reality.
The Common Anti-Pattern: Build the Interface First
A familiar integration project begins with a simple requirement:
“We need ERP connected to MES by Q4.”
A technical team identifies fields.
Interfaces are developed.
Testing starts.
Only then do the difficult questions emerge.
Which ERP work centre corresponds to which MES equipment object?
Who owns that mapping?
What happens when the production hierarchy changes?
How are alternative resources represented?
Which material identifier is authoritative?
What does “completed” actually mean?
At which point should MES report production?
How should rework quantities be represented?
Which system owns the operations definition?
How should partially completed orders be handled?
The project discovers that transporting the message was never the hardest problem.
The difficult work was agreeing on the manufacturing semantics behind the message.
This is why production models and master-data governance are not secondary topics in MES/MOM programmes.
They are prerequisites for scalable integration.
Another Anti-Pattern: Expose Everything
Modern industrial connectivity makes it technically easy to expose large quantities of data.
That does not mean every value should cross every architectural boundary.
A production application does not necessarily need every PLC variable.
An enterprise analytics environment does not automatically need uncontrolled access to every automation namespace.
ERP should not need to understand the internal implementation of machine control.
Good architecture creates deliberate boundaries.
At each boundary, the organisation should ask:
What information must cross?
At what level of aggregation?
At what frequency?
Which system owns the definition?
What context must accompany the data?
How will structural changes be governed?
The objective is not universal connectivity.
It is sufficient, governed interoperability for a defined operational purpose.
That is a very different architecture principle.
Why This Matters for Operational Excellence
Standards such as ISA-95 may initially appear distant from Lean, TPM, reliability or daily operations.
They are not.
Consider downtime.
If MES and CMMS identify equipment differently, linking production losses with maintenance history becomes more difficult.
Consider quality.
If genealogy cannot consistently connect material, operation, equipment and production information, root-cause analysis becomes weaker.
Consider OEE.
If state models and loss classifications differ fundamentally between production lines, enterprise comparison becomes less reliable.
Consider process improvement.
If plants describe equivalent events differently, cross-site analytics and Process Mining become more difficult to scale.
Consider AI.
If an AI application receives large quantities of industrial data without stable context, it may identify statistical relationships while still lacking a reliable representation of what those relationships mean operationally.
Semantic discipline therefore supports Operational Excellence.
Not because standards improve process performance by themselves.
They do not.
Their value is that they can reduce avoidable ambiguity in the information used to understand losses, coordinate execution, analyse causes and support decisions.
Standards Do Not Eliminate Governance
There is an important limitation.
Adopting a standard does not remove the need for architecture governance.
ISA-95 cannot decide the correct equipment hierarchy for an organisation.
B2MML cannot repair inconsistent master data.
OPC UA cannot determine who owns an equipment definition.
No information model can compensate for uncontrolled naming conventions, ambiguous responsibilities or poorly governed production structures.
A technically standards-based architecture can therefore remain operationally incoherent.
The sequence matters.
First understand the manufacturing process.
Then define the relevant production and equipment models.
Clarify ownership.
Define master-data responsibilities.
Determine which systems are authoritative for which information.
Identify the required information exchanges.
Apply standards where they reduce unnecessary variation.
Then select and implement the appropriate technologies.
Reversing this sequence can produce technically elegant interfaces built on weak operational definitions.
Before Implementing the Architecture, Check Whether…
-
ERP, MES/MOM, SCADA and CMMS/EAM use equipment and production structures that can be related coherently;
-
ownership of material, equipment, operations and production master data is explicit;
-
the authoritative system for each important object or attribute is known;
-
production schedule and production performance concepts are consistently defined;
-
integration requirements describe business and manufacturing meaning rather than only field mappings;
-
transactional manufacturing information has been distinguished from high-frequency process data;
-
interface teams understand the operational process they are integrating;
-
identifiers and naming conventions can survive equipment, hierarchy and plant changes;
-
standards are being used to reduce unnecessary variation rather than becoming an additional technical layer;
-
and the receiving application can actually use the transmitted context to improve execution, analysis or decisions.
If several of these points are unresolved, the architecture probably has a semantic and governance problem before it has a protocol problem.
A Common Language Is Infrastructure for Scale
A single plant can survive custom mappings.
An experienced engineer may remember that ERP WC-440 corresponds to MES PKG-L4 and SCADA CELL17.
Ten plants are more difficult.
Fifty plants turn the same problem into an architectural constraint.
Now add additional MES applications, analytics platforms, cloud services, Process Mining, digital twins and Industrial AI.
Every ambiguous identifier, inconsistent hierarchy and local definition creates another dependency that somebody must interpret and maintain.
This is where common information models become strategically important.
They create the possibility of scaling manufacturing information without reconstructing meaning for every new connection.
Not perfectly.
Not automatically.
But systematically.
That is the practical promise behind ISA-95-based representations, B2MML, OPC UA information models and similar approaches.
Industrial systems have been moving data for decades.
The more difficult challenge is ensuring that systems agree sufficiently on what the data represents.
That challenge becomes more important, not less, as factories become increasingly connected.
The future Smart Factory is unlikely to suffer from a shortage of data.
Its architectural challenge will be preserving identity, relationships and operational meaning while assets, applications, people and algorithms exchange that data at increasing scale.
The strongest industrial architecture will therefore not be the one with the greatest number of interfaces.
It will be the one in which every important interface carries the right information, with sufficient context, governed ownership and a clear operational purpose.
Three Questions Worth Taking Back to the Architecture Team
-
Are our industrial integrations sharing manufacturing meaning, or are they primarily moving fields between systems?
-
When ERP, MES, SCADA and CMMS/EAM represent the same physical resource differently, do we know which system is authoritative for each definition and relationship?
-
Could our current information model scale across multiple plants and applications without depending on people who remember every local mapping?
#ISA95 #B2MML #OPCUA #MES #MOM #SmartFactory #IndustrialInteroperability #ManufacturingExcellence #OperationalExcellence #IndustrialData #DigitalManufacturing