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 has not yet posted the finished goods receipt. Those states can all be valid because they describe different moments in the same production process. DATA IS THE SIGNAL — CONTEXT IS THE SURROUNDING FACTORY A temperature value is data. Context explains which sensor produced it, which machine contains that sensor, which product was running, which recipe applied, what unit was used, whether the sensor was calibrated, and what operating range was acceptable for that production run. The same applies to a machine-down event. The signal tells you that something stopped. Context tells you which operation was affected, which order was running, what material was being used, whether the produced output is actually available, whether another resource could take over, and which customer commitment may now be at risk. Useful industrial context usually includes: • Asset context — what the physical thing is and where it sits • Process context — what the resource can actually do • Order context — what work is currently running • Material context — which lots and components are involved • Quality context — whether output is released, restricted, or held • Time context — which relationships were valid when the event happened Once those relationships exist, the same machine event becomes much more useful for planning and decision-making. SCHEMA, ONTOLOGY, AND GRAPH ARE DIFFERENT THINGS A schema defines the shape of a record. It can require fields such as asset ID, event timestamp, fault code, work-order ID, or engineering unit. An ontology defines the shared meaning of the concepts and relationships used across the factory. A graph provides a practical way to store and query those connected entities. For example, a machine can belong to a production line, a sensor can measure a component, an operation can belong to a work order, a material lot can be consumed during that operation, and finished output can have a quality status. A graph makes those connections easy to traverse, but simply choosing a graph database does not create meaningful relationships. The quality comes from the model, ownership, timing, identity, and governance around those links. FROM MACHINE ALARM TO A USEFUL PRODUCTION ANSWER If those relationships are modeled, the packaging-machine alarm can be traced through the wider production context. The fault event identifies the physical asset, the asset connects to the production resource, the resource connects to the active operation, the operation connects to the work order, and the work order connects to product, quantity, demand, and delivery commitments. Material relationships show what was consumed. Quality relationships show whether completed production is actually usable. Maintenance relationships provide service history and known issues. Instead of only saying “Packer 7 stopped,” the architecture can begin to explain which order was running, how much quantity remains, whether completed output is available, and which customer delivery may now be affected. That is the difference between event monitoring and actual decision support. SEMANTIC GOVERNANCE — WHO OWNS THE MEANING? Once these relationships start supporting production decisions, ownership becomes critical. Someone has to define which record represents the asset, which machine can perform which operation, which system owns work-order execution state, which system owns quality release, and who approves mappings between maintenance, MES, ERP, and automation records. The answer normally involves several business domains rather than one central IT team. That means the architecture needs clear ownership, source references, timestamps, version history, data contracts, and approval processes. AI can help suggest likely mappings between inconsistent records, but a suggested relationship should not automatically become a governed production fact without evidence and domain validation. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.
