Connect ERP, MES, and IoT — Without Replacing Anything

0:00 A bottleneck machine stops mid-shift. Production does what it always does first. People react. An operator calls maintenance, a supervisor checks the plan. Someone opens the MES, someone else checks the ERP, then a dashboard appears because apparently every factory problem also needs one more dashboard. The systems don't describe the same situation. The ERP knows there is a customer order. It knows the material, the planned quantity, the promised date, maybe the customer priority. From the ERP view, the order is still planned work with a commercial consequence. The MES knows something else. Which operation is active? The quantity already reported. The operator who started the run, whether parts are sitting in a quality hold. It sees execution, not the full commitment. Then the IoT layer, sensors, PLCs, gateways, machine signals, sees the physical event.

0:43 The alarm appeared. The machine entered a stopped state. The cycle counter stopped moving. It can tell you when the technical condition changed, often far more precisely than the ERP or MES. All three systems can be correct and still nobody has a complete answer to a simple question. What should the factory do now? That's the integration problem in one moment. Not a lack of data but a lack of connected meaning. Before we talk about Broker's API's Microsoft fabric or an edge gateway, we need to respect the job each system already does. ERP holds the business commitment. Think about the ERP as the place where the factory's commercial promises become structured records. It holds customer orders, builds a material, inventory positions, purchasing data, cost data and financial postings. It holds the production order that tells the plant what needs to be produced in what quantity for which due date and under which planning rules.

1:28 That role matters because production doesn't happen in isolation. A machine may produce a part but the business needs to know whether that part belongs to a customer order, whether material consumption needs recording, and whether the finished goods can support shipment. The ERP is built for that kind of truth. It's also where master data tends to live. Material numbers, product descriptions, builds of material, routines, plants, work centers, priorities, supplier records. Some of that data may replicate into other systems but the ERP often remains where business ownership sits. Now a plant order isn't the same as an executed operation. An ERP might show that order 4827 should run today on a given resource. That's useful. But it doesn't prove the order has started, the correct tool is mounted the first parts past inspection or that the machine is currently cycling.

2:10 That difference causes a lot of confusion in integration projects. People see an ERP order and assume they can infer shop floor reality from it. The ERP describes intent and confirmed transactions. The shop floor deals with what's physically happening, including all the mess between those two points. A production plan might say a work center should produce 500 units during a shift. The plan may be perfectly reasonable when it leaves the planning process. Then a tool wears early, a material lot is delayed, an operator gets reassigned, or a quality check holds the first batch. The ERP didn't fail. It just wasn't designed to be the second by second record of physical execution. There's another issue that comes up constantly. The same resource may carry different names in different systems. In the ERP, a resource might be called press line 2.

2:51 In the MES, it may appear as asset PRS02. In the PLC program, the data point might sit under a technical tag built years ago by a control engineer who had very good reasons for naming it that way. Each name can be valid in its own system. The problem starts when nobody maintains the relationship between them. Then an outage on a PLC tag can't be tied with confidence to the MES asset and the MES asset can't be tied to the ERP work center. People bridge that gap manually, usually with local knowledge and a spreadsheet that has become far more important than anyone wants to admit. So when you integrate ERP with MES and IoT, don't start by pushing every ERP field toward the factory floor. Start by asking which business facts the factory needs. A production order may need to reach MES with its material, target quantity, routing context, approved revision, due date and priority.

3:36 The exact content depends on the process. A batch process needs different contexts than a discrete assembly line. But the principle stays the same. The ERP supplies the business commitment that execution needs to act on. And when execution confirms something that matters commercially, the ERP needs a controlled update. That might include a confirmed quantity, material consumption, completion status, equality disposition or a production variance. Those are business transactions. They need checks, permissions and a clear record of who or what confirmed them. You don't treat an ERP posting like a raw sensor message. If a machine counter changes that may be evidence, it may support a quantity confirmation, but it doesn't automatically become a financial or inventory transaction, just because a signal arrived.

4:18 That distinction keeps the architecture sane. The ERP should remain the source for commercial facts and planning records. It should not become a shadow scatter system, a machine historian, or a place where every PLC state gets copied every second. That creates noise, load and a false sense that business planning has turned into shop floor control. But it hasn't. Planned work now needs to become control work. That's where the MES enters the picture. MES holds the execution record. The MES takes the plan work from ERP and turns it into controlled execution on the shop floor. That sounds simple until you watch a real shift. An order arrives with a target quantity and a routing. But the MES has to handle what happens when that order meets machines, operators, tools, material lots, inspections and all the normal interruptions of production.

5:01 Its job is execution, plain and simple. A manufacturing execution system usually manages dispatching, deciding or helping a supervisor decide which operation runs next. It records starts and stops, captures operator actions, tracks quantities, enforces quality steps. In regulated environments it also handles electronic batch records, genealogy and sign-offs. That gives you a very different type of record from what you get in ERP. An ERP status might tell you an order has been released partially confirmed or closed. The MES status can show the order is active at operation 30, waiting for inspection, paused because material is missing or physically done but not yet quality released. Those states should never be forced into one generic word like complete. A part can be produced but not inspected yet, or pass inspection but wait for a material posting.

5:43 It can fail and move to scrap or go into rework where it still exists, still consumes capacity, still affects the delivery date but no longer follows the original route. The MES has to preserve that detail, think about a production run where the line makes a hundred parts, the machine counter shows a hundred cycles. That doesn't mean a hundred good parts and it finished goods. Maybe five got rejected at an in-process check, two sitting quarantine while quality reviews a measurement issue. Three need rework, the MES is where those execution facts become part of the production record with the right status and workflow. That distinction matters because a cycle count is a technical observation. A confirmed good part is a production and quality decision. Mix those two ideas and OEE, inventory, quality and delivery reporting all start drifting.

6:23 The dashboard might look clean, right up until production, quality and finance sit in the same meeting and discover each team has a different total. Nobody enjoys that conversation. The MES also carries the human side of execution. An operator confirms a setup, a supervisor pauses an order, a quality technician places a batch on hold, a maintenance tech marks equipment unavailable for a planned intervention. Those actions add intent and accountability that no PLC signal can provide alone. That doesn't mean operators should manually type every machine event. It means the MES combines automated evidence with the operational decisions people still need to make. For example, a machine stops at 10-14. The MES connects that stop to the active work order, the operation, the shift and the operator context.

7:04 Later, a supervisor may classify it as planned changeover, material waiting, tooling fault or an unknown event needing review. The raw stop time and the production reason are related but they're not the same fact. That's where integration design needs discipline. The MES should get enough ERP context to execute correctly and enough machine evidence to reduce manual reporting and build a trustworthy timeline. It should not become a dumping ground for every tag, vibration sample or network event from the plant. Execution systems need usable facts, so define the terms before you map the interfaces. What does "start" it mean? Is it an operator release, the first machine cycle or both? What does "complete" mean? Physical production ended, inspection passed, quantity posted or customer shipment released. There isn't one universal answer but there needs to be one agreed answer inside your factory.

7:49 Once that agreement exists, the MES can provide the execution record that links planned work to real production. Even the best execution record still needs evidence from the physical process. The machine doesn't know a workflow has been approved and the workflow doesn't always know what the machine is doing right now. IoT holds the physical signal. The IoT layer sits closer to the physical process than ERP or MES. It collects what equipment, sensors and control systems can observe. A motor running, a conveyor stopping, pressure moving outside a normal range, vibration shifting, a counter pulse arriving. That sounds straightforward but the source matters. The signal may come from a PLC running the machine logic from a sensor added to older equipment or through an industrial gateway that reads data from a controller and passes it on without changing the controller program.

8:34 This is physical evidence. A machine state tells you whether a line is running, idle, stopped or faltered depending on how the signal was designed. A temperature sensor reports, a temperature, a cycle counter reports a cycle, an alarm bit reports across limit and a vibration sensor streams values that may help maintenance investigator developing issue. But the signal doesn't know the business meaning of what it reports. Imagine a press stops. The IoT layer can record the stop time, the active alarm, maybe motor current before the stop and whether the safety circuit opened. That's useful, especially for maintenance. Yet the PLC doesn't know which customer order now faces a delivery risk. It doesn't know if the operation was producing a high priority product or if the parts before the stop passed inspection. The machine only knows what it can observe.

9:14 That's why I'm careful when people describe industrial IoT as if it replaces manufacturing execution. The IoT creates a path from physical equipment to digital systems. It observes, captures and transports data. It can support local processing when network conditions or response times demanded, but it does not automatically become the owner of work orders, production status, quality release or planning decisions. There's a related boundary that needs to stay clear. Reading a machine signal is one thing, controlling it is another. The PLC owns deterministic control. It must react with a known timing rules. It handles interlocks, sequence logic and safety related behavior according to the machine and process design. A cloud service should not sit in the middle of that. You can use IoT data to detect a stoppage, notify a supervisor, trigger a maintenance workflow or send context to planning.

9:59 None of that means a remote analytics layer should decide how the PLC responds to a fault. Physical processes don't wait politely while a cloud workflow checks its calendar. Now think about the equipment estate most factories actually run. You might have a new packaging line with a modern PLC and an OPC UA interface, which is a common industrial standard for exposing structured machine data. On the next line equipment that's run reliably for 20 years, with limited controller access and no safe reason to modify a working program. Both types belong in the architecture. For the new align, you can read selected tags through OPC UA using a gateway or edge service that handles identity, buffering and secure transport. For the older line, a basic digital input may be enough, a run signal, a stop signal, account pulse or a shared alarm, providing useful evidence without opening up a fragile controller program.

10:47 More data isn't always better data. If that brownfield machine only exposes a reliable run state and accounters start there, you can learn whether the signals are stable, whether operators trust the interpretation and whether the data supports a real production question. Trying to extract every possible address from an old PLC on day one often creates work for controls engineers and little help for the shift team. The IoT layer also needs to handle the unglamorous details. Network links fail, gateways reboot, sensors return invalid values, clock's drift, signals arrive late after a connection returns. Those conditions don't mean the architecture failed, they mean it needs to preserve evidence and report what it knows, including uncertainty. A gateway shouldn't quietly turn missing data into a normal machine state. It should retain the source time where possible marked data quality and buffer data if the upstream connection disappears.

11:32 Otherwise a network gap can later look like a production gap and the investigation starts from the wrong premise. The IoT gives you the physical signal, ERP gives you the commercial record, MES gives you the execution record, each can be correct on its own, but until those records connect around the same equipment, operation and point in time, three correct systems can still produce one answer nobody can use. The context gap between data and meaning, you can pull ERP, MES and IoT data into the same cloud platform and still end up with the same problem. The data arrives, that's all it does. A table of machine states sitting next to a table of work orders doesn't tell any system which state belongs to which order. Having data into one place isn't the same as building a shared understanding of the factory. Take one physical machine. In ERP it shows up as a work center.

12:14 In the MES it's an asset ID, the historian knows it by a tag group, a gateway might give it a device name and maintenance calls it by an equipment number from an older register. None of those teams name their records badly, they each name the thing for the specific job they needed to do. But the moment you want to ask one cross system question, those separate names become a real blocker. You want to know which production orders lost output because of a specific fault on this machine. The system first has to figure out that the ERP work center, the MES asset, the historian tag group and the maintenance equipment record are all pointing at the same physical asset. That link, that's context, time creates another gap. The PLC records a state change using its local clock. The MES logs an operator action a few minutes later. ERP groups confirmations around a business day or a reporting period.

12:56 If you haven't agreed on time zones, clock sync and what each time stamp actually means, one event can look like three different events. Was that a machine stop at 1002 and operator confirmation at 1006 or a production interruption that started before shift handover? All of those records could be correct. They just answer different questions. Units create the same kind of problem. A temperature reading of 82 means nothing until you know whether it's Celsius or Fahrenheit, where it was measured, which product was running and whether 82 falls inside the approved operating range. Without that information you have a number, not a quality inside or a process signal. A proper data model joins the facts that belong together. It links the asset to its line, the line to the process, the process to the active operation and the operation to an order material batch tool and shift.

13:37 It also captures the rules around those relationships. For example, a temperature value might belong to a curing oven that processes several product types. Each with a different approved range. The same sense of value could be normal for one product and a warning for another. No generic data pipeline can safely infer that from a tag name. Someone has to model it. This is where manufacturers often fall back on Excel and I'm not saying that as a knock against anyone. Excel stays useful because people can connect things when systems cannot. A planar knows machine A and machine B are similar but not identical. A process engineer knows which tool limits a routing step. A quality person knows why an order shouldn't be counted as complete yet. That knowledge usually ends up in spreadsheets, local notes, email threads and people's heads.

14:18 Excel becomes the unofficial integration layer because it can hold the relationships that formal systems never captured. It's flexible, fast and often built by the person who understands the situation best. It's also hard to govern, hard to audit and fragile when that person is on holiday or leaves. So the goal isn't to ban spreadsheets. The goal is to identify the relationships that production actually depends on, then move those relationships into a shared model where systems and people can use them consistently. This changes how you think about data quality too. A missing value is one kind of problem. A wrong relationship can be worse. If a sensor gets mapped to the wrong machine, the data might look clean, arrive on time and produce very confident nonsense. That's why data quality in manufacturing can't stop at checking whether a field contains a value.

14:59 You need to ask whether that value refers to the right asset, process, order, unit and time. One outage exposes all of this quickly. The alarm tells you a machine stopped. But the decision you need depends on the links around that alarm. Which operation did it interrupt? How much quantity is left? Is material available somewhere else? Is the order under equality hold? Does the stop affect a customer delivery date or only tomorrow's internal plan? Until those relationships exist, people will keep doing the integration work manually and they'll keep doing it under pressure when the machine is already down. Factory scenario, re-planning after a bottleneck failure. Let's make this concrete. Picture a plant with a bottleneck machining center. The resource that limits output for a family of high demand parts. The schedule around it is tied by design.

15:42 During the afternoon shift, the machine stops with a spindle alarm. Maintenance sees the technical alarm from the machine data. The machine stopped at a known time. The alarm code points toward a spindle cooling problem. And the current run can't continue until someone checks it. It gives maintenance a starting point, but not a production decision. The MES adds the next layer. It shows the machine was halfway through an operation for an active production order. Some parts have been produced and reported, but a smaller quantity is still waiting for inspection. There's also a quality hold on a previous batch from the same order, so the plan I can't simply assume every reported part is available downstream. Now the ERP adds the commercial side. The order supports a customer delivery date that's coming up fast. It shows the material, the required quantity, the routing and the demand linked to later operations. It might also show that another order needs the same machine later in the shift.

16:27 So the question changes quickly. It's no longer "why did the machine stop?" The real question becomes, "what can we still produce, where can we produce it, and what does each option do to the delivery commitment?" At first, moving the remaining work to another machine sounds obvious. There's another machine in the plant that appears to support the same process. But a planner needs more than a matching machine name before making that move. Can the alternate machine process this material and part revision, does it have the correct fixture and tooling available? Is the operator on that shift qualified to run the operation there? Will moving the job require a setup that eats up the remaining capacity window? Is the alternate machine already committed to a different order with an earlier due date? And does the routing allow the operation to move? Or does quality require the work to stay on the original resource?

17:10 This is where many integration projects stop too early. They connect an alarm to a work order and call it real-time visibility. Useful? Yes. Enough? No. An alarm tells you something changed. A usable planning option tells you what remains possible under real production constraints. Picture the planner at that point. They don't need another notification telling them the bottleneck is down. Everyone already knows that. They need a short, trusted picture of the production situation. The bottleneck machine is unavailable. The active order has a remaining quantity. Part of the reported quantity awaits inspection. The customer date is tomorrow. An alternate machine might run the operation, but only after a fixture change, and only if a qualified operator is available. Moving the work will delay another order that has a different priority and material dependencies. That's a decision frame. It doesn't automatically decide for the planner, and it shouldn't.

17:56 A good planning system can test scenarios, but the recommendation still needs to reflect production rules, quality rules, and trade-offs that somebody owns. Maybe maintenance expects a short repair. In that case, moving the work might create more loss than waiting. Maybe the repair has no reliable estimate yet, and the alternate machine has a narrow free window. Then the planner might reserve that window, prepare the fixture, and wait for maintenance confirmation before releasing the transfer. There could be another option too. The work stays on the original machine, while an upstream operation changes sequence, so material and people remain ready when the machine returns. That may not recover all lost time, but it could protect the delivery date better than a rushed transfer. Notice what happened here. The machine alarm started the conversation, but the decision depends on relationships across the plant. The IoT event provides technical evidence. The MES provides current execution and inspection status. The ERP provides demand, due date, material, and business priority.

18:46 Then the planner needs resource alternatives, tool fit, skills, routing rules, and sequence constraints. Without those links, the factory has data but no reliable option, and once you build a direct connection for this one case, the next question arrives almost immediately. Maintenance wants the same outage context. Quality wants it for batch review. Energy wants to compare machine states with consumption. Planning wants it for every bottleneck. That's when direct links start to look simple only from a distance. A why point-to-point integration grows into a problem. A direct ERP-to-MES connection can be the right call. Say that upfront because not every plant needs a full integration program with a new broker, a platform team, and a slide deck full of arrows. If one ERP sends release production orders to one MES, and that MES sends back confirmed quantities through a clean interface, that setup can chug along for years without anyone thinking twice about it.

19:35 The trouble starts when that single connection becomes the pattern for everything else. Take the bottleneck outage we talked about. First the MES needs machine status, then maintenance asks for the same machine events. It's just to compare alarms against work orders and repair history. Quality needs production context around a process deviation. Energy needs run states and counts so it can calculate consumption per unit. And planning once current status for capacity reviews. Every new consumer needs some version of the same basic information. The easy obvious move is to just build another connection. So the IoT gateway sends machine states to MES. It also sends them to the maintenance system. Maybe it sends them to a historian, a quality app, and a reporting database. Then the BITM builds an extraction from ERP and another one from ES because they need a combined report.

20:17 None of this looks unreasonable on its own. Each connection makes perfect sense in the moment. But after a while, that factory has a dozen connections. Each with its own mapping logic. One interface maps the PLC signal runs or one to running. Another maps that same signal to production active, a third treats it as machine available. Each consumer may have a reason for its interpretation, but nobody can easily prove which interpretation applies in which situation without digging through documentation that probably doesn't exist anymore. That's where the real maintenance burden settles in. Suppose the bottleneck machine gets replaced. The new controller exposes different addresses, the equipment name changes, and alarm code lists changes too. The controls engineer updates the machine connection. But now every downstream interface needs checking. Some fail right away.

21:00 Obviously, loud, easy to find, others keep running, but send incomplete or incorrectly mapped data. The dangerous failures are the quiet ones. A broken interface usually gets attention fast. But a connection that still sends data while sending the wrong asset ID or a changed unit that can live for weeks before anyone spots it. By then, the planning report, the maintenance review, and the OEE calculation may all tell different versions of the same story and nobody has a single source of truth to settle the argument. ERP changes create a similar kind of chaos. A field gets renamed, a rooting structure changes, a new status enters the order life cycle. One integration team updates its mapping, while another team has no idea the field logic changed.

21:40 The same business rule gets copied into several places, and every copy slowly becomes its own version. You end up with three implementations of the same rule all slightly wrong in different ways. Here's the thing, that's not mainly an API problem. It's a business contract problem. A technical connection answers simple questions, can system A send data to system B. Does the message arrive, can the receiver read the format? That's table stakes. A business data contract goes further, it defines what the message actually means. It says who owns the field when it can change, which values are allowed, what time the event refers to, and what a receiving system should do if information is missing or late. Take machine stopped. Sounds simple until you need to define it. Does it mean the controller enters the stop state? Does it exclude plan setup? Does it begin after a short delay to avoid counting minor pauses? Can MS override the reason later? Which system owns the final classification?

22:29 Without those rules, you don't have shared data. You have several systems exchanging words that may mean different things. And nobody knows who's right. Point to point integration also creates hidden dependencies between teams. A maintenance change may quietly break an ERP report. A quality rule change may affect a machine feed. A new plan or two may need data from five systems and each system owner has to approve a separate connection. The project slows down, not because anyone refuses to help, but because every new use case touches old interfaces that nobody wants to break during production. Still, don't treat direct integration as a mistake by default. For a small contained case, it can be the most sensible design. One line, one mes, one stable ERP interface, a narrow set of data, you may not need a broader integration layer. The right architecture should fit the problem you have right now, not the one a vendor hopes you'll have later.

23:14 But one several systems need the same operational facts repeating direct connections becomes expensive to change in hard to trust. You end up spending more time maintaining mappings than actually solving production problems. The next move isn't to take ownership away from ERP MS or the machine. It's to reduce the coupling between them while letting each system stay responsible for the work it was built to do. Keep system ownership where it belongs. The answer isn't to create one giant platform that takes over every job that looks clean in an architecture meeting, but it becomes dangerous fast when a data platform starts behaving like a second ERP, a second mess, and an unofficial control system all at once with nobody fully responsible when records disagree. Keep ownership close to the work your ERP owns business transactions and planning records. It owns the customer order, the approved bill of material, inventory movements, purchasing commitments, and the financial record behind production.

24:03 If an order changes priority or a material substitution needs approval, that decision belongs in the business process that governs those facts. But in some data pipeline that someone built last quarter and nobody remembers, your mess owns production execution. It owns the work order as it runs through the plant. It records operations, operator actions, quality checks, traceability events, and execution states. If a supervisor pauses an operation or quality puts a lot on hold, the MES should preserve that decision and the workflow behind it. That's its job. Let it do that job. Then there's the machine and the PLC. The PLC owns deterministic process behavior. It runs the sequence, it applies, interlocks, it responds to local inputs within the timing the equipment requires. Safety functions stay where they belong. In the engineered control and safety design.

24:45 A machine should not depend on a cloud connection before it can react to a fault. That boundary is non-negotiable. A data platform has a different role. It can collect, connect, contextualize, and assess information across these systems. It can help people answer questions that no single source can answer alone. But it should not quietly become the place where a planner edits production orders and operator changes execution status or an analyst updates inventory because it was easier than using the approved source system. That creates shadow ownership and shadow ownership feels efficient right until two systems contain different versions of the same order. Then the team spends time debating which record is real while the actual production problem waits on the shop floor. Think about the architecture as a controlled cycle. First, the platform reads facts from the systems that own them. It reads machine events, MES execution records, and ERP planning data.

25:30 Next, it adds context. Connecting an equipment state to an active operation, an order, a material, or a quality status. Then it can assess the situation. That assessment may be a downtime pattern, a capacity warning, a quality exception, or a planning scenario. It may result in a recommendation, an alert, or a work list for a planner or maintenance team. But when the recommendation requires a business or execution change, it should go back through a controlled path. For example, a planning service might identify that a bottleneck outage puts several orders at risk. It calculates options based on approved constraints. It tells the planner which orders need attention and what alternatives look feasible. But the planner still approves the change through the planning or ERP process. The MES receives the released execution instruction through its defined interface. Nobody should treat a message on a broker or a row in a data lake as permission to rewrite the live schedule.

26:18 The same principle applies to maintenance. An edge service may detect repeated alarms, a model finds a pattern worth investigating. That result can create a proposed maintenance action, but the maintenance system, the approved maintenance workflow, should own the work order, the technician assignment, the safety checks, and the closure record. If the trigger work, it shouldn't bypass the people and controls that make that work safe. This is also where Power Platform needs restraint. A Power app can be very useful for a bounded task. Capturing a downtime reason, asking a supervisor to review an exception, guiding a technician through a checklist. Power automate can root approvals and notifications. But if a low-code app starts writing freely into ERP, MES, and machine-connected systems with no clear owner, you haven't simplified the process.

27:01 To confuse, there's a practical test I use. For every data object and every action, ask two questions. Who owns this fact and who can change it? If the answer is unclear, don't build the integration yet. Sort out the ownership first. If several systems need to read the same fact, that's normal. If several systems can write that same fact, you need to deliberate rule and approval path and an audit trail. Read broadly, right narrowly. That gives you more freedom for analysis without weakening control of the factory floor. It also means you can improve visibility and decision support without forcing a replacement project onto systems that still do their job well. Now let's follow one machine event through that kind of architecture, from a raw signal all the way to a production decision.

27:41 From machine signal to production decision, let's follow that outage through the architecture because this is where integration stops being a set of interfaces and starts becoming useful to production. At the source, the machine sends a raw signal, maybe a boolean that flips from running to stopped, an alarm code or a counter that's frozen. The raw record needs to preserve where it came from, what it reported, and when the controller or sensor recorded it. That technical address matters for traceability because if someone later questions the event, you need to trace back to the original source. Not just trust a transformed message, nobody can explain. An edge component captures that signal close to the machine and its first job isn't to invent production meaning. It's to reliably collect the source data, buffer it if the upstream network drops and attach basic technical information like the asset identity, engineering unit and source quality.

28:29 Source quality is easy to ignore until you need it. A gateway can lose communication with a PLC, a sensor might return an invalid value or a controller may restart and publish an old state again. If the edge layer turns all that into clean looking data without marking the condition, downstream people receive a confident answer built on weak evidence. That's worse than a visible gap. Now the edge layer can frame that technical state change as a defined factory event. For example, the machine moved from running to stopped at a recorded source time with a specific alarm active. That event still belongs to the technical world, but it's now structured so other systems can consume it. It should include enough information to answer basic questions later, which asset reported it, which source produced it, when it occurred, whether the value was read directly or inferred or supplied by a gateway, and whether the event is final or could change with late data.

29:17 The next connection goes to me as context. At the time of the stop you need to know which operation was active on that asset, which production order was running, what quantity the MEAs confirmed, whether parts were pending inspection, and whether the operation was in setup, planned maintenance, production, or a quality hold. That's the moment a technical event becomes part of a production situation. You don't need to push every raw machine sample into the MEAs. That would be an expensive way to make an execution system less usable. Instead, connect meaningful events with the execution state the MEAs already owns. A stop event can then carry an operational reference. Machine PRS02 stopped during operation 20 of order 4827, the order had a remaining quantity, some output remained under quality review, and the event has evidence, execution context, and a clear link back to the system.

30:01 Then at the ERP context, the ERP can provide the material, requested quantity, due date, customer priority, and links to later operations or dependent demand. And it may also show whether the order affects a shipment, a stock replenishment plan, or downstream production order. Notice the sequence here. The raw signal stays traceable, the MEAs supplies the live execution context, and the ERP supplies the business consequence. No system needs to surrender ownership for the data to become more useful. By the time the information reaches a planner, they shouldn't receive a message that simply says "machine stopped". They should receive a production situation, the machine stopped at a known time, the active operation and order are identified, the current order status includes reported quantity and inspection state.

30:45 The customer date and business priority are known, and any later process that depends on this order can be identified for review. That is a different kind of alert, it doesn't tell the planner which decision to make, it gives them a reliable starting point with the facts already connected, and the source of each facts still clear. There is a practical detail that often causes trouble here. Events may arrive out of order. The machine might report the stop immediately, but the MEAs may take a moment to record that an operator paused the operation. A quality update could arrive later, and a delayed gateway message may appear after the machine already restarted. The architecture needs to retain both source time and arrival time. Source time tells you when the physical or operational event occurred, and arrival time tells you when your platform learned about it.

31:26 Without both, late data can quietly rewrite the story of a shift. You also need a rule for correlation. The system should not assume that any stop near an operation belongs to that operation. It needs a defined time window, an asset mapping, and a confidence rule. In some cases it should flag ambiguity instead of pretending it knows. That's mature integration. It preserves evidence, adds context in steps, and lets people see where uncertainty still exists before they act on it. Not every fact needs to move at the same speed though. The right flow depends on the decision waiting at the other end. Choose the data flow by the decision. Once you can follow an event from the machine to a planner, the next question is timing. You need to ask how quickly each fact needs to move and how fresh it needs to be when someone acts on it.

32:07 Teams often start with the phrase "real time" and treat it as a requirement, but real time is not one thing. A safety response may need milliseconds and must stay local, while a supervisor looking at a line interruption may need information within seconds. A planning review works fine with updates every few minutes, and finance may only need confirmed data at the end of a shift or day. So start with the decision, not the transport technology. Ask who will act, what they need to decide, and what happens if the data arrives later. That gives you a sensible latency target and stops the common habit of streaming every field from every system just because the platform can handle it. For stable master data, batch synchronization often makes sense. Material definitions, routings, approved resource relationships, and many planning records don't change every second.

32:49 So you might load them on a schedule or trigger an update when a controlled business change occurs. The point is not that batch is old fashioned. The point is that batch fits data where a short delay doesn't change the decision. History works the same way. You may need production, quality, and maintenance history for analysis, reporting, or model training, and that data needs reliable extraction, traceability, and clear time handling. It really needs to travel as a live stream from the source. A scheduled load can be easier to operate and reconcile, especially when the source system has its own posting and approval cycle, then there are events. An event flow suits a fact that changes state and needs attention. A work order is released, a machine enters a fault state, a quality hold starts, an operation completes, or a material shortage appears.

33:33 These are not continuous signals. They are meaningful changes in the factory situation. Event-driven flow helps because systems react when something relevant happens instead of constantly asking whether anything changed. And it also gives you a cleaner audit trail, provided the event contract states what happened, when it happened, who owns it, and how a receiver handles duplicates or late arrival. Now consider streaming. Streaming fits fast changing process values and machine states with a pattern over time matters. Temperature, pressure, vibration, power draw, high speed counts, and equipment state changes may need to flow continuously or near continuously into a technical data store or an analysis service. But even here, you need discipline. You probably don't need every raw value forever at full frequency. You may need detailed data during a fault window, sample data during normal operation, and derived events for production users.

34:22 The source data should remain available where engineering needs it, while downstream consumers receive a level of detail that fits their job. A planner usually doesn't need a vibration waveform. They need to know whether the asset is available, what confidence maintenance has in the repair estimate, and which production orders are exposed. Sending more technical data to the planner doesn't create a better planning decision. It just moves the burden from one system to another. This is why a single real-time integration label can cause bad design choices. A work order release may be an event, inventory reconciliation may run in batch, machine state may stream, and a management report may refresh at a planned interval. All of those flows can belong in the same architecture. The important part is that the data reaches the right person or system within the time window that supports the decision faster isn't always better if it creates more cost, more operational load, and more false urgency.

35:11 There is one boundary that should stay very clear. Local safety and deterministic machine response must not depend on cloud connectivity. If a guard opens, a pressure limit is exceeded, or an interlock needs to act, the response belongs in the control and safety design at the machine or process level. Cloud services can observe, analyze, alert people, and support later decisions. They should never become the path a machine needs before it can protect people or equipment. Once you decide what needs batch events or streaming, the protocol choice becomes much easier. transport comes after the data flow not before it. OPC UA, MQTT, REST, and Digital I/O. Once you know whether you need a batch update, an event, or a stream, you can choose the transport method with a lot less drama.

35:51 People often ask, "Which protocol should we standardize on?" That's a fair question, but it can lead you in the wrong direction. A protocol tells systems how to exchange information, but it doesn't tell them what a production order means, whether a part passed inspection, or who can approve a schedule change. transport is not meaning. Take OPC UA, which stands for Open Platform Communications Unified Architecture. It commonly sits close to equipment because it gives systems a structured way to expose industrial data, letting a machine or PLC publish variables with names, data types, and sometimes a richer information model behind them. For a modern machine, that can be a strong starting point. You might connect an edge service to an OPC UA server and read selected data points such as machine state, active alarm, cycle count, temperature, or speed.

36:35 That word "selected" matters because reading the whole controller address space just because it exists is usually not an integration design. Its data collection without a question attached. OPC UA works well when you need to understand the technical structure of a machine, but it doesn't remove the need for your factory model. An OPC UA node called Status might mean something precise to the controls team, yet it still needs mapping into a shared production state that MES maintenance and analytics teams can use. Then there is MQTT, which stands for Message Cueing Telemetry Transport. MQTT uses a publish and subscribe model, where a publisher sends a message to a named topic, and consumers subscribe to the topics they need. The publisher doesn't need to know whether the consumer is an MES, a maintenance app, a historian, or an analytics service.

37:18 That makes MQTT useful when one event needs several consumers. Imagine an edge gateway, publishes a machine state change. The MES may subscribe because it needs production evidence, a maintenance service may subscribe because it tracks alarms, and an analytics platform may subscribe because it stores the event for later analysis. None of those consumers needs a separate direct connection back to the gateway. The broker roots the message, but a broker doesn't fix poor naming or weak data definitions. If different gateways publish run, running, active, and machine on for the same concept, MQTT will move those messages very efficiently into a larger mess. So MQTT needs a govern topic structure and a shared payload contract. You might organize topics around plant area, line, cell, and equipment, but you still need to define the message itself, which assets sent it, what state changed, what time it changed, what unit applies, and whether the data is good, missing, or estimated.

38:10 MQTT moves events and your model gives those events a usable meaning. Rest is different. Rest API is user request and response pattern over web protocols. One system asks another for an object or asks it to perform a control transaction, then receives a response. This fits many ERP and MES interactions. For example, MES may request the current routing or approved material details for a released order, while an integration service may submit, a confirm production quantity through an ERP API and receive an acknowledgement or an error. These are business interactions where you need validation, permissions, and a clear outcome. A rest call is not the best fit for a fast machine signal. Polling a controller through layers of APIs every second can create needless load and delayed data.

38:50 And publishing an ERP posting to an MQTT topic, hoping it becomes a valid inventory transaction is not a serious control design. Use request and response when a system needs a specific object or a managed transaction, and use publish and subscribe when multiple consumers need timely event updates. The two patterns work together. Digital I/O belongs at the simple end of the spectrum and simple can be exactly right. Digital input and output means basic electrical signals like a machine providing a run contact, a stop contact, a common fault signal, or a pulse that indicates a completed cycle. An industrial gateway can read those signals and turn them into events that upstream systems understand. For older equipment, this may be safer than asking for changes inside a PLC program that has run without trouble for years.

39:31 You won't get a deep technical model from a few digital signals and you may not know the exact fault code or process value. Yet run, stop, count, and alarm can still support useful production visibility when they are mapped honestly and paired with MS context. That is the practical point. A factory does not need one protocol everywhere. A mixed estate will often use OPC UA near newer machines, digital I/O for older equipment, MQTT to distribute current events, and rest APIs for ERP and MES records. That isn't architectural failure. It's a normal factory. The job is to keep the protocol choice tied to the source, the decision, and the support model. When you deal with brownfield equipment, that usually means showing some restraint rather than forcing a technical upgrade onto a machine that still earns its place every shift.

40:13 Connect brownfield equipment without risking output. Brownfield integration starts with a simple respect for the machine that is already doing its job. If a press, mixer, or packaging machine has produced reliably for years, its age does not make it a problem that needs fixing. The question is narrower. What information do we need from it? And what is the least risky way to collect that information? That changes the tone of the project. You are not arriving with a plan to modernize every PLC, but rather adding a read path that helps production understand the equipment without putting output at risk. For many machines, passive signals are the right first step. A gateway can read an existing signal without writing anything back to the controller, collecting a run state, a stop state, a cycle pulse, or a common alarm contact. That small set of signals can answer a real question if the rest of the production context comes from MES and ERP, start with enough data, not all data.

40:59 Say you have an older forming machine with a controller that nobody wants to touch during a busy period. The controls documentation may be incomplete, the original programmer may have retired years ago, and the program contains logic that works perfectly well but has no spare capacity for someone else's integration experiment. In that case, a passive current sensor, a digital signal tap, or an external counter may be safer than a PLC change, letting you determine whether the machine runs, when it stops, and whether production cycles continue. That gives you evidence without changing the behavior of the machine, there are limits, and they should stay visible. A basic run signal cannot tell you every cause of a stop, and a counter cannot prove that every cycle produced a good part. Don't claim more than the signal supports.

41:39 Pair the machine evidence with the MES record and let operators or maintenance add the context that only they can confirm. That is still useful and it is also honest. The physical design matters as much as the data flow, someone needs to decide where the gateway sits, how it receives power, how it connects to the cabinet or sensor, and who can replace it at two in the morning if it fails. A gateway is not just a small computer that appears in an architecture document, it becomes part of the plants maintained equipment. So define ownership before installation. Maintenance may own the physical device and spare hardware, controls engineering may approve connection points and electrical drawings, IT may own network access, certificates, operating system patching, and central monitoring, and production needs to confirm that the data reflects what people see on the floor.

42:22 If none of those teams owns the gateway after go live, it will eventually become a mystery box with a blinking light. Every factory has a few of those already. When PLC changes are necessary, treat them as a production change, not a software task. You need a defined change request, you need to know which program version is live, what the proposed change does, how it will be tested, and how you will return to the prior version if the result is wrong. The control team needs time to validate the change under safe conditions. Ideally outside a production window where a failed test does not turn into a delivery problem, rollback is part of the design. That does not mean PLC changes are always too risky. Sometimes the controller contains the cleanest and most reliable signal source, and a controlled update is the sensible option, but the reason for the change should be clear.

43:05 We might need these tags later, is not a strong reason to touch a machine that is running well. Before any rollout, look at the network boundaries too. Can the edge device sit in the correct OT zone, which connection is permitted out of that zone? Does the gateway require a maintenance port? Who approves remote access? These questions need answers before hardware arrives, not when someone stands beside an open cabinet with a network cable. Maintenance windows matter for the same reason. Even a read-only installation can require a cabinet opening, a power connection, a network test, or a brief interruption while the equipment is checked. Plan those tasks with production, because a technically simple installation can still disrupt a shift if it happens at the wrong moment. The goal is measured progress. Connect one machine or one line, check that the signals remain stable across starts, stops, shift changes, and network interruptions.

43:50 Confirm that maintenance can support the hardware, confirm the production recognizes the events, and then repeat a pattern that people trust. And keep one line clear throughout, connecting to a machine does not give a platform authority to control it. Data access and control authority are separate decisions with very different consequences. Draw a hard line between PLC, MES, Edge, and Cloud. Once you connect a machine, teams often blur the line between collecting data and taking action, and that can cause real trouble. A signal leaves the line, shows up in a cloud service, triggers a workflow, and suddenly people start asking whether the same route could change a machine setting. The answer is usually no, at least not without a clearly defined operational path. The PLC handles deterministic control. That means it runs the sequence logic, reacts to inputs within known time limits, and enforces the interlocks built into the machine design.

44:37 If a sensor detects a dangerous condition, the PLC and safety system respond locally, no matter if the network is up, the Edge gateway is healthy, or the cloud is reachable. That is its job. The MES works at a different level. It manages which work should run, how an operation is recorded, which quality checks apply, and what traceability evidence needs to exist before production can move forward. It can tell an operator that a work order is released, block an operation when quality places a batch on hold, and record that a setup has finished. But the MES shouldn't become a fast control layer for a machine. If a conveyor needs to stop because a guard is open, that decision belongs in the machine control design. If an operator needs to select the next approved order, or a supervisor needs to authorise a routing exception that belongs in the MES workflow, these are separate timescales, separate responsibilities, and usually separate people.

45:24 Between those layers, the Edge has a practical role. An Edge gateway or industrial PC sits close to the equipment. It can read protocols, buffer messages, filter out noise, and translate data into a format other systems can use. It can also run limited local logic when that logic supports monitoring, data quality, or a local application that must keep working during a network interruption. Think of the Edge as the controlled boundary for data handling near the machine. For example, an Edge service can detect that a machine state changed, attached the source timestamp, and store the event until the connection returns. It can convert a raw counterpulse into a structured event, and reject a value that falls outside the physical range a sensor could plausibly produce. That supports production, but it does not take over the PLC. The cloud has another role again. It is where you combine history from several systems, compare lines or plans, run longer term analysis, and give planning, engineering, quality, and leadership teams access to shared data.

46:15 Cloud services let you ask questions that cross the normal boundary of one machine or one shift. For instance, you may want to compare recurring stops across similar assets and several plans, then connect those stops with work, order, impact, and maintenance history. That is a cloud scale analysis problem, doesn't it? It does not belong inside a PLC project. The mistake comes when people treat every digital layer as if it can safely write to every layer below it. A cloud analysis may identify a likely process issue. A planning service may find a better sequence for tomorrow. An AI model may detect a pattern that deserves a maintenance review. None of those findings should become a direct command to a live machine, just because a technical connection exists. A connection is not authority. When a recommendation needs to change production, root it through the workflow that owns that change. A planning recommendation goes to the planner or approved planning process.

47:00 A quality warning goes to the quality workflow, a maintenance finding goes to the maintenance process. If an MES instruction eventually leads to a machine parameter change, the handoff needs defined acceptance checks, permissions, machine side validation, and an audit record. That path may feel slower than sending an API call straight to a controller, but it is how you avoid an analyst, a dashboard rule, or an overly confident AI system changing a live process with no operator awareness. Factories can't treat production control like a web app deployment. You can't roll back a batch that has already failed, and you can't undo a safety incident after the command was technically successful. So keep the boundaries clear. The PLC controls the physical process, the MES controls work execution, the edge handles local connectivity and data preparation, the cloud connects wider data, history, and decision support.

47:45 Information can move across those layers with the right controls, but authority should not move by accident. A shared language helps teams maintain those boundaries, especially when IT, OT, production, and data teams all describe the same architecture from different angles. ISO 95 gives us a useful way to do that. Use ISO 95 as a language not a prison. ISO 95 gives teams a shared way to describe where information belongs in manufacturing. That sounds simple, but it helps when production, controls, IT, quality, and data teams use the same words for very different parts of the factory. At the lower end you have the physical process. Motors turn, valves open, parts move, temperatures change, and material becomes product. Above that sits control where PLC's sensors, drives, and local control systems manage the physical process. Then comes manufacturing operations management, the space where MES, quality execution, maintenance, coordination, and production records live.

48:36 Above that, enterprise planning handles customer demand, supply planning, financial records, purchasing, and the wider business commitments. You don't need to treat those levels like a rigid technical law. Use them as a language for asking better questions. What kind of data is this? Who acts on it? What happens if it arrives late? Who owns the change? And what path should it take before it can affect a physical process? That language becomes useful the moment someone proposes a new integration. Say an analytics team, once machine data in the cloud. ISO 95 does not mean every reading must move through every system above it before anyone can analyze it. That would often add delay and duplicate work. A read-side data path can move selected data from the edge to a data platform for monitoring, reporting, engineering analysis, or model development. The word selected matters. You don't need to extract every address from every PLC just because an edge gateway can connect to it. Start with the data that supports a named question.

49:25 If maintenance wants to study recurring spindle faults, collect the signals, alarm, states, and time context that help answer that question. If quality needs to investigate a process window, collect the approved process values and the product context needed to interpret them. The architecture should have two paths that work together. One path handles control and operational change. It stays structured, governed, and close to the system's responsible for the process. A production order is released, an operator follows approved instructions, a quality hold blocks and operation, a machine reacts locally to a safety condition. The other path supports observation and analysis. It moves read-only or carefully controlled data towards systems that can combine information across machines, shifts, sites, or business functions.

50:07 It supports real-time visibility without turning a reporting platform into a control system. Those paths have different jobs. A common mistake is to assume that direct edge-to-cloud data flow somehow breaks the manufacturing model. It does not, if the flow is designed for observation, approved by OT and IT, and isolated from control authorities. The data may travel more directly, but the security boundary and ownership rules still apply. Think about a vibration signal from a motor. An edge service can capture it near the asset, preserve its source time, and send it to a cloud data platform for analysis. The maintenance team can compare that pattern with prior work orders and production conditions. A model may flag a condition worth checking. None of that gives the cloud permission to change the motor control logic. If an action is needed, the finding enters the maintenance workflow. A technician checks the asset and the maintenance system records the work. If a production adjustment follows, the approved execution process handles it.

50:56 The data path can be broad. The control path remains deliberate. That distinction also helps with security discussions. Rather than asking, can I access the plant network? Ask which data needs to cross which boundary, in which direction, at what rate, and with what identity and logging. A read-only connection for a defined set of machine events is a very different design from unrestricted remote access to controllers. Is a 95 gives you a way to make that difference visible without pretending every factory must look identical. Some sites have mature scarter and historian systems. Some have a mix of older equipment, local databases, and a newer MES. Some run several plants with different automation vendors. The model helps you place responsibilities and define interfaces, but it does not erase the history of the plant. And that is fine. The goal is not a perfect hierarchy on paper.

51:38 It is an architecture where people know which system owns a fact, where control decisions happen, and how approved data can move across IT and OT without creating new risk. Once multiple systems need current events from the same equipment, though, another design question appears. You need a shared route for that information rather than a new direct connection every time another team needs to subscribe. Unified namespace, a shared event space. So here's where a unified namespace comes in. When you've got multiple teams all needing the same live machine events, a shared event space starts to make real sense. A unified namespace, UNS for short, is a govern shared event space. It gives machine data, MES events, and other current factory facts a common route, so a new consumer doesn't need to build a fresh direct connection to every single data source.

52:21 Think about the bottleneck machine again, but from the data flows point of view. The edge gateway publishes that the machine change from running to stopped. It sends that event once to a defined place in the shared namespace. From there, the MES can subscribe if it needs machine evidence for execution, maintenance can grab the alarm event, and an analytic service can subscribe to the same state change for a live operational view. The publisher doesn't need to know all of those consumers. That's the whole point of publish and subscribe, a source publishes an event, and any approved consumer subscribes to the events it needs. So adding a new maintenance app, energy tool, or planning service no longer means adding another connection into the machine or gateway. It connects to the shared event space instead. In most industrial designs, an MQTT broker handles that message distribution. MQTT is the transport, and the broker receives messages from publishers and routes them to subscribers based on the topic they use.

53:11 The broker is not a second mess, it does not decide whether an operation is complete, approve an inventory posting, or classify a quality hold. It distributes current information so the systems that own those decisions can receive what they need without being tightly coupled to every source. That difference matters. A broker can tell a subscriber that a machine is currently stopped or that a new alarm event occurred. The MES can then connect that with the active operation it owns, a data platform can store the event for analysis and maintenance can assess the technical condition. Each system still does its own job. For this to work, the shared event space needs structure. Otherwise the broker becomes a fast way to spread badly named data across the plant. A common approach follows the physical structure people already know. Start with the plant, then the area, then the line, cell, equipment, and the event or measurement beneath it.

53:56 So a message about a packaging machine might sit under a route that tells you which plant it belongs to, which area it runs in, which line it supports, and which equipment produced the event. You should be able to hear the topic path and understand where the signal came from before opening the message itself. That makes the data easier to find and also simplifies access control because a team can receive events from one line or area without automatically gaining access to everything across every plant. But the hierarchy should describe the factory as it operates, not force every local detail into a rigid template. A discrete assembly line and a batch process area may need different event structures, so a shared name space should give them a common frame while allowing the data to match the process. Otherwise teams work around the model and the model slowly loses its purpose. There's another benefit that often gets missed. A shared event space lets systems stay available independently.

54:44 If a reporting service goes down, the machine doesn't stop producing because it has no dependency on that service. And if one analytics project ends, the gateway doesn't need a redesign. It still publishes the defined operational events for the consumers that remain, that reduces coupling. It does not remove responsibility. You still need clear rules about which events belong there, who publishes them and which system owns the business meaning. But the transport layer becomes less tangled, which is a practical step toward an architecture that actually scales. A unified name space also gives you a better path for gradual change. You don't need to replace the ERP, remove the MIS, or rewrite every machine interface in one massive program. Instead start with one defined event stream, connect one or two consumers and prove that the topic structure and event flow work under real production conditions.

55:27 Then extend the pattern where it earns its place. Just don't confuse the broker with the architecture. The broker can distribute a message, but it cannot decide whether the names are consistent, whether a stopped state means fault or setup, or whether an asset record refers to the correct physical machine. That work still needs people, clear definitions, and named ownership. Yao-Wun's governance, names, states, and owners, a unified namespace only works when people can trust what they find in it. That trust starts with identity. The same physical asset often carries different names across the plant because each system grew around a different job and a different team. ERP may call it resource 110, MIS may call it line 2 press, the gateway may identify it by a device address, and maintenance may use an equipment number from an old asset register.

56:08 None of those names are automatically wrong. The problem starts when nobody records that they all refer to the same machine, so create an asset identity map. Give the physical asset one governed identity in the shared model, then maintain the links to the local identifiers used by ERP, MIS, gateways, historians, maintenance, and quality systems. You're not forcing every source system to rename its records, you're making the relationships explicit. That distinction saves a lot of pain later. When a machine is replaced, upgraded, moved to another line or split into sub-assets, the identity map gives you a controlled place to manage the change. Without it, one team updates in MIS asset, another updates a PLC address, and a report quietly continues to point to equipment that no longer exists. Names also need a clear rule. A topic path should identify location and asset in a predictable way, while the business meaning inside the message should use governed names and codes.

56:57 And avoid names that only make sense to the person who configured the first gateway. If a new engineer cannot understand the asset name without calling someone who retired five years ago, the naming scheme is already failing. States need the same discipline, running sounds simple until you ask whether the machine is producing approved parts, warming up, performing a test cycle or moving during setup. Stopped could mean a plan break, no material, no operator, a fault, a quality hold, or a scheduled maintenance task. Those are different operational conditions. A shared state model does not need to erase every local machine state. It should provide a common set of production states that downstream users can interpret consistently. For example, a machine can be in production, setup, plan, stop, fault, waiting, or an unknown state where the available evidence does not support a better classification. The unknown state matters.

57:44 Teams sometimes try to force every event into a need category because dashboards dislike blanks, but an honest unknown state is better than a false fault reason that later enters an OE calculation, a maintenance review and a planning report as if it were fact. Keep the technical state and the operational state separate when needed. The PLC might report a motor enabled signal, the MES might show that the operation is in setup, the shared model can retain both facts instead of pretending one replaces the other. Then a production rule can derive a broader state with the derivation documented and open to review, ownership comes next. For every event type, somebody needs to own the meaning and the right to publish a final status. The gateway may own the raw technical reading, MES may own the active operation and execution status, quality may own the release or hold decision, and ERP may own customer priority and confirm business transactions.

58:32 This avoids a familiar argument. Two systems publish different statuses and everyone assumes the broker should decide which one is correct. It cannot. The broker can root both messages, but the governance model needs to state which sources authoritative, for which fact, how a conflict is handled, and whether one source may enrich another without replacing it. Put those rules into versioned message contracts. A contract should define required fields, allowed values, units, timestamps, source identity, and message version. If a temperature appears, the receiving system should know whether it sells years or Fahrenheit, and if an event arrives, it should carry the source time and enough information to trace it back to the source. When the contract changes, version it deliberately. Don't change a field meaning in place and hope every subscriber notices that is how stable integrations become overnight incidents. Right rights need limits too.

59:18 A maintenance application may publish a maintenance assessment, but it should not publish a customer priority. An analytic service may calculate a suggested downtime class, but it should not override the approved MES record. Access follows system responsibility, not who happens to have credentials and allow local differences to exist. One plant may have a setup condition that another plant does not use, and one process may need a batch state that makes no sense on a discrete line. Document those differences instead of hiding them under generic labels that nobody believes. A unified namespace becomes useful when its structure matches the factory, its messages carry clear meaning and each fact has an owner, but even a well-governed namespace has a defined job. It should not become the answer to every integration problem.

59:58 What a unified namespace does not replace? A unified namespace is greater distributing current events, but it doesn't replace the systems that handle controlled business transactions. Take an ERP posting. Confirming material consumption or reporting a finished quantity touches inventory, cost, traceability and downstream planning. That action needs validation, permissions, error handling and a clear response from the ERP. An MQTT message can announce a production event, but it can't prove the ERP accepted a financial or inventory transaction. That distinction matters when a message gets delayed, duplicated, or arrives after a process restart. The receiving integration needs an idempotency rule. It has to recognize a repeat message and avoid posting the same result twice. It also needs retry handling escalation for rejected records and a way to reconcile what the source intended with what the ERP actually accepted.

1:00:48 That's transactional integration work. Keep it explicit. The same goes the other way. A work order release, a routing change, or an approved material substitution can't just show up as a current state message and become active on the shop floor with no acceptance process. MES needs to receive, validate and apply that change within its own execution rules. The namespace can publish the current context around that order, but the formal release still belongs in the system that governs production execution. Historical analysis creates a need a broker doesn't meet on its own. Imagine a quality engineer investigating a recurring defect pattern over several months. They need to retrieve events, machine states, process values, quality decisions and order context for a defined time range, maybe comparing batches, shifts, products and maintenance periods.

1:01:29 That requires stored data people can query reliably. A broker handles messages in motion that it's not designed to become your long term production archive, root cause, workspace or reporting database. You still need historical storage with retention rules, indexing and traceability back to the source. The namespace may feed that history, but it doesn't replace it. And it can't repair weak source data. If a sensor drifts, the namespace will distribute that drifting value with impressive efficiency. If machine clocks differ, the event stream preserves conflicting times unless you detect and manage the problem. If the site has vague rules for downtime reasons, moving records through a broker won't produce a better classification. A clean transport route doesn't create clean evidence, so data quality works stays close to the source and the people who understand it.

1:02:11 Check clocks, track signal quality, define state rules, mark estimated, missing and invalid data instead of quietly turning it into a neat looking number for a dashboard. You also still need APIs. A consumer might need the approved current bill of material, a planning service might need detailed routing data for a specific order, a maintenance application might need to retrieve a full equipment record, including permissions and history. Request response APIs remain a good fit when a system needs a defined business object and a confirmed answer. Trying to force every interaction through MQTT just because you have a unified namespace is another kind of over design. For one plant with one MIS and limited equipment scope, a direct OPC UA connection into the MIS might still be the cleanest option.

1:02:53 That connection supports a defined need, has named owners and doesn't create a web of hidden dependencies, it may be enough. There's no price for installing more architectural layers than the factory needs. The question is whether several consumers need shared current operational data and whether direct links are starting to multiply. When the answer is yes, a unified namespace helps reduce that load. When the answer is no, keep the design small and maintainable. In the long space solves the real time distribution problem. It doesn't replace transactional workflows, historical data services, source data discipline or practical engineering judgment. Once those boundaries are clear, we can look at the broader pattern that connects these parts without turning every new use case into another custom integration.

1:03:33 Manufacturing integration platform as an architecture pattern. Once you reach that point, it helps to think in terms of a manufacturing integration platform. In an architecture pattern here, not a product category you have to buy, the pattern creates a shared layer between shop floor systems and the applications that need factory data. So each new use case doesn't start with another direct connection into a machine, MIS database or ERP interface. The idea is simple. Connect data sources once, shape the data in a controlled place, then make it available to approved consumers through clear interfaces. That can support MS, maintenance, quality, energy reporting, planning and analytics. The systems stay different because they do different jobs. What changes is how information moves between them. Picture a plant with an MIS, a maintenance tool, a quality system, a historian and several reporting projects.

1:04:18 Without a shared integration layer, every team tends to build its own route to the same equipment and production data. One group reads a PLC through a gateway. Another export data from the MIS and someone else queries the historian directly. Each route might work on its own, but trouble starts when the same machine state, order status or quantity needs a different mapping in each project. One team uses one asset name and another uses a different one. A change to a line or machine then becomes a small integration project five times over. A manufacturing integration platform gives you a place to stop repeating that work. Close to the shop floor, you need a connectivity layer. This is where protocols, gateways, controller access and brownfield signal capture belong. It deals with the awkward physical facts of industrial integration, different PLC brands, old equipment, intermittent connections, local network rules and source signals that can be used.

1:05:06 And source signals that don't arrive in a useful format. That layer should shield downstream systems from unnecessary equipment detail. A maintenance application doesn't need to know whether a status came through an OPC UA server, a digital input or a gateway reading a legacy protocol. It needs a trusted equipment event with a clear source reference. The connectivity layer helps create that boundary. Above it, you need a data layer where raw inputs become consistent industrial records. As the links are managed, event times follow shared rules, units are converted in one controlled place. A temperature stays tied to its original source, but consumers can also receive a normalized value with a known unit and quality status. The goal isn't to make every source look identical, it's to make shared facts understandable without forcing every consumer to rediscover what a source system meant.

1:05:50 You preserve the original evidence, then publish a form that other systems can use safely. Then comes the integration in API layer. This is how other applications request approved objects, receive events or submit control transactions back to a source system. It can include APIs, event streams, message brokers and adapters, but the principle matters more than the tool. Consumers should not need direct database access just because they need an order status. They should use a defined interface that says what the data means, which version they receive and what happens when the source changes. That makes change manageable. A new quality application can connect through an approved interface rather than asking the controls team for another PLC connection and the ERP team for another database extract.

1:06:31 A new plan can follow the same pattern while still dealing with its own machine estate and local constraints. That's where the pattern starts to earn its cost. The platform also needs an operating model. Someone has to monitor data flows, deal with failed messages, manage credentials, approve contract changes and maintain the asset mappings. Integration doesn't stay finished just because the first release went live. Machines change, ERP fields change, production teams change how they classify events. If nobody owns those changes, the shared layer slowly turns into the same confusion it was meant to reduce. For a multi-site manufacturer, this becomes more obvious. One site may run a different MES, another may depend on a longstanding historian, a third may have newer automation equipment and a much better network.

1:07:11 You don't need to force them into one identical local system. You need repeatable integration rules. The shared platform pattern gives each site a way to connect its own sources while sending govern data to enterprise consumers. It gives central teams a common way to manage identity, data contracts, monitoring and access. It also lets local teams keep the systems they need to run production. That balance matters. A manufacturing integration platform should reduce repeated integration work. It should not become a central team that blocks every plant change or a giant data project that waits years before anyone can use it. Start from the consumers and decisions that already exist, then build shared services where repeated demand justifies them. You may implement this pattern with a dedicated industrial platform, a broker-based architecture, integration services, a data platform or a mix.

1:07:55 The architecture test stays the same. Can you add a new consumer without rebuilding the connection to every source? If the answer is yes, you are moving toward a reusable integration layer. And this is where Microsoft becomes relevant, not as a replacement for ERP, MES or industrial control, but as a set of building blocks for connectivity, governance, integration and shared data use. Microsoft's role, building blocks, not a replacement strategy. Think of Microsoft as a set of building blocks, not a replacement for your ERP, MES, historian, controls team or operating model. That sounds obvious, but it's easy to lose sight of when someone starts listing products. Azure gives you cloud infrastructure, integration services, identity monitoring, security controls and the services for connecting industrial data.

1:08:35 Microsoft Fabric provides a shared data plane where operational data and enterprise data can meet for analysis. Power BI puts the result in front of the people who need to make a decision. All useful roles, none of them changes who owns the underlying production facts. Let's be clear about that. Your ERP owns customer commitments, materials, planning records and financial transactions. Let it keep owning them, whether you run Dynamics 365 or another system. Fabric can consume a controlled copy of relevant ERP data for planning analysis, reporting or AI work. But Fabric should not quietly become the place where people edit the production order because the report looks more convenient. That is exactly how Shadow Systems start. The same logic applies to your MES. That system holds the execution record, operator workflows, quality steps and traceability rules that define how work moves through the plant.

1:09:21 Azure and Fabric can receive MES events, combine them with equipment signals and make the broader production picture easier to study. They don't replace the MES process that confirms the quantity, applies a hold or records a rework decision. So here's the practical view. Think of Microsoft Fabric as your shared analysis space, not the command center for every factory transaction. It brings together telemetry from the edge, events from MES and selected ERP records in one leg. Engineering investigates process behavior, quality compares conditions across batches. Planning studies the effect of recurring equipment constraints, data teams build govern models from a common data foundation. That's a strong use of Fabric. Now the hard part still sits before Fabric. Someone must map the asset identifiers, someone must define what counts as a production stop, someone must decide which system owns a quality status, someone must create the data contracts and keep them current when the line changes.

1:10:11 Microsoft provides the services to run and govern the platform. Your organization still provides the factory meaning. Power BI belongs near the decision end of that path. It gives a planner, maintenance lead or production manager a current view of a problem, with drill through to the facts behind it, but power BI should not hide production logic inside report formulas that only one report author understands. If a downtime classification and OEE rule or production state matters across the business, put the definition in a governed model. Then the report consumes that model. Otherwise you get the familiar result where three reports calculate the same number three different ways and the meeting becomes an argument about filters. Apparently dashboards can multiply faster than spare parts, power platform can also fit well as long as you keep the scope bounded.

1:10:51 A power app might help an operator record a downtime reason when the machine signal alone cannot explain the stop. A power automate flow might root in exception to a supervisor or create a task for review that can reduce manual handoffs without handing uncontrolled right access to every connected system. The line needs to stay clear, a low-code workflow can support people and approve processes. It should not bypass misvalidation, ERP transaction rules or the control logic at the machine. When a flow needs to change a source system, use a defined API, permissions, error handling and an audit record. The Microsoft Identity Stack matters here too. Microsoft, EntraID, Roll-Based Access and Logging help you manage who can access cloud data, who can approve a workflow and who can operate shared services.

1:11:33 In a multi-site environment that consistency removes a lot of ad hoc access work. But Identity in the cloud doesn't settle ownership on the shop floor. The plant still needs to decide which roles may view an event, classify a stop, approve a schedule change or access technical data from a restricted area. So the practical architecture uses Microsoft where Microsoft is strong, Azure supports connectivity, integration, cloud operations and security. Fabric supports shared storage, real-time and historical analysis, govern data products and AI ready data. Power BI supports decision output. Power Platform supports focused human workflows. Dynamics 365 can be the ERP where it is already the enterprise system of record, but it does not need to be there for the rest of the architecture to work.

1:12:14 That is the more useful conversation. You can connect a non-Microsoft ERP and existing MES and a mixed machine estate into Microsoft services without starting a replacement program. The architecture scales when the interfaces, ownership rules and operating model are clear, not because every layer comes from one vendor. The next decision sits much closer to the equipment, what should leave the plant, what should stay local and who will operate the edge layer that connects the two.