A connected factory can move machine signals in milliseconds and still fail to answer the operational questions that actually matter. A packaging machine stops, the PLC reports the fault, OPC UA exposes the event, MQTT distributes it, and the dashboard updates immediately. Maintenance receives an alert and everything appears connected. Then the planner asks which customer shipment is now at risk, and suddenly the answer requires MES data, ERP records, maintenance history, quality status, production quantities, delivery commitments, and often a spreadsheet. That gap is the focus of this episode: connectivity moves signals, while integration connects meaning, constraints, ownership, timing, and consequences.  

CONNECTIVITY MOVES SIGNALS — INTEGRATION CONNECTS MEANING
OPC UA, MQTT, edge gateways, brokers, and modern industrial connectivity platforms solve important problems. They make machine data accessible, standardize transport, reduce point-to-point connections, and allow events to move between machines, applications, and cloud services. But transporting an alarm does not explain its business consequence.

A fault code can arrive perfectly, keep the correct timestamp, and reach every subscriber within seconds. That still does not tell a planner whether the stopped machine affects an urgent order, whether approved inventory already exists, whether the current output is on quality hold, or whether another resource can take over. To answer those questions, the architecture needs relationships between the machine, the active operation, the work order, the product, material status, quality state, maintenance information, and customer demand.

ONE ALARM, MULTIPLE SYSTEMS, NO COMPLETE ANSWER
The episode follows one packaging-machine alarm through the systems that typically hold different parts of the production story. The PLC knows what happened at the machine. MES understands which operation and work order are active. ERP knows demand, due dates, inventory, and customer commitments. Maintenance knows service history and outstanding work. Quality decides whether the produced output can actually be released.

Each system can be correct while the factory as a whole still cannot answer the operational question. This is where people become the integration layer: someone checks MES, someone else opens ERP, maintenance searches the service history, quality verifies release status, and somebody eventually pulls the information together manually. That approach works until decisions need to happen quickly, systems change, or the person who understands all the hidden mappings is unavailable.   

UNIFIED NAMESPACE: A BETTER HIGHWAY, NOT THE FACTORY MAP
A Unified Namespace can improve this situation significantly by replacing many direct system-to-system connections with a shared publish-and-subscribe environment. Machines and applications publish information once, consumers subscribe to what they need, and new systems can join without another custom connection back to the equipment.

That reduces plumbing, but it does not automatically create context. An MQTT topic structure can tell you where information came from, but it cannot determine which production order was active, which material was involved, which quality state applied, or which customer delivery depends on that order. Publishing MES, ERP, quality, and machine events into the same broker does not automatically create the relationships between them. Those relationships still have to be modeled and governed.    

THE TAG NAMING TRAP
Good naming conventions help people discover data, but names are not identities. One system may call a machine Packer7, maintenance may use PK07, ERP may use a production-resource code, and a cloud platform may know the same equipment through a device identity. All of those records can refer to the same physical asset.

Without governed identity, organizations gradually build mapping tables, custom scripts, report-specific translations, and undocumented assumptions. Then the machine gets moved, rebuilt, renamed, or receives a new controller and the data still flows while the relationships quietly become wrong. Friendly names are useful for people, but stable identity is what keeps systems connected over time.

ERP AND MES HAVE DIFFERENT JOBS
ERP and MES are related but they should not be treated as the same system. ERP works at the business and planning level with demand, supply, inventory, customer commitments, production orders, and financial consequences. MES works closer to execution with operations, production resources, operators, downtime, quantities, material consumption, and the actual progress of work on the floor.

The architecture becomes more reliable when those responsibilities remain clear and the systems are deliberately linked instead of forcing one platform to own everything. A machine can report that production is complete while quality still has the output on hold. MES may show an operation as finished while ERP ...