Edge vs. Cloud in Manufacturing- Why the Wrong Architecture Costs You More

0:00 Picture a packaging line mid-shift, the conveyor stops. The operator sees a fault at the station, but the cloud dashboard still shows green. Why? Because the event is waiting on a network trip, an ingestion path, a rule, and a message back down. That delay costs more than the cloud bill ever will. It creates scrap. It holds people at a stopped line. It fills networks with data nobody needs. And when something fails, there's one awkward question left who actually owns the decision. A cloud first data project usually starts by sending everything upward. A factory needs the opposite starting point. A local decision path for anything that must act while the product is still in reach. In this video, I'm going to give you a workload placement test you can use for every factory decision. And there's one decision type that should never wait for fabric.

0:40 So let's stop debating platforms for a second and look at time. Stop asking edge or cloud. Most teams ask, should we run this at the edge or in the cloud? It sounds like a sensible question, but it pushes the discussion toward product choice before anyone has described the actual work. The better question is, what decision are we trying to make? Who needs it and what happens if it arrives late? That turns edge versus cloud into workload classification. You aren't picking a winner. You're placing each piece of work where it can do its job without creating a new weak point in the plant. Take a typical production line. At the bottom, a controller reads inputs and drives outputs. It runs the machine sequence, holds interlocks and responds inside the time limits the machine needs. That's control. Above that, you may have a system that shows line state, raises alarms, collects counts, or lets a supervisor see why a station paused.

1:26 That's supervision. It may need to respond quickly, but it doesn't always need the same deterministic behavior as the controller. Then you have analysis. Analysis looks across time and asks why a stop repeats, why a defect rate changes, or whether a motor trend looks different from last month. It can wait longer because it needs history and context. Planning works on another horizon. It takes orders, material limits, labor, maintenance windows, and machine capacity, then asks what should run next. Learning sits beside that. It uses historical data to improve a detection rule or train a model, then sends an approved version back to where it will run. Reporting comes last, though people often start there because dashboards are visible. Reporting tells the business what happened. It doesn't keep a line safe, reject a bad part in time, or keep production moving when the one drops.

2:10 These jobs don't belong in one place just because they touch the same machine. Think about a filler with a check-wear. The controller must stop or reject based on a direct local signal. Align lead needs to see the alarm and confirm the condition. Quality may review the trend across the shift. Maintenance may compare that station with similar stations in other plants. Planning may decide whether the order can still ship on time. One physical event, several decisions, different owners, different clocks, this is why a single architecture for the entire plant almost always turns into a compromised nobody likes. Put everything in the cloud and you create parts that depend on connectivity for work that should stay close to the machine. Put everything at the edge and you build local islands where each plant learns only from itself than someone exports spreadsheets to compare them anyway.

2:51 Vendor diagrams rarely show that part. They show clean arrows from PLC to gateway to cloud, then a dashboard and maybe a glowing AI icon floating above it. They don't show the night shift when a certificate expires. They don't show an operator who needs an answer now while the message queue backs up. They don't show a maintenance engineer trying to tell whether an alarm came from the machine, the edge node, the MES, or a cloud rule that ran against old data. Those are architecture questions. They don't disappear because the diagram uses more arrows. A hybrid architecture isn't two copies of the same system. One on-site and one in Azure. That waste effort and creates two versions of the same fact. Hybrid means rooted work. The controller handles deterministic control. The edge layer collects and interprets local signals, keeps local rules running and passes useful events upward.

3:36 Plant systems manage execution and local workflow where that belongs. Cloud and fabric hold shared history. Connect the dots between IT and OT and support questions that need data beyond one machine or one plant. Each layer needs a clear role. More importantly, each command path needs a clear limit. If a cloud service proposes a new threshold, that isn't the same as letting a driver machine output. If an edge node detects a condition that doesn't mean it owns the safety function, if MES receives a downtime event, it doesn't become the source for the raw controller state. You need to be precise here because vague ownership becomes a production problem later. Now, response time is usually the first test people use. Fair enough, if the machine needs an answer in milliseconds, don't send the question across the internet and hope the reply comes back in time.

4:20 But timing alone can still give you the wrong placement. A decision might have plenty of time, yet still need to run locally because the plant must continue during a network outage. Another decision might run fast at the edge, yet still need cloud history before anyone should change a process rule. So before you place a workload, you need to see the clocks already running inside the factory. The factory has more than one clock. Here's the thing about a factory floor. It doesn't run on a single timeline. It runs on several and each one handles delay differently. That distinction shapes the entire architecture and it's usually the first thing people get wrong. The machine cycle sits at the fastest end. A sensor changes state, the PLC evaluates the logic and an actuator responds while the machine keeps moving.

5:00 On a high speed line, that entire path lives in milliseconds. It's not a request for analysis. It's part of the physical process itself. Wove and into the control loop that keeps the line running, safety runs on an even tighter path, but that logic belongs in the controller and the dedicated safety system. Not in fabric, not in any general purpose edge application. If a guard opens or an emergency stop is pressed, the machine needs a deterministic response through a validated local path. A networked service can record what happened. It should never decide whether a person remains safe. Now, the operator clock often runs in seconds. Picture a vibration sensor on a motor. The local system detects a sharp change, compares it against a defined rule and fires an alarm at the station.

5:41 That operator needs enough context to act, which motor, what changed, how long it's persisted, and whether the line can keep running at reduced speed. An alarm that shows up 10 minutes later might look correct on a dashboard, but it missed the window where it could actually help. Quality has its own clock, too. A camera catches a defect. The local inspection process classifies it and the reject gate needs a signal before that part leaves the rejection zone. That could be milliseconds or a fraction of a second, depending on line speed and distance. The decision isn't, is this image interesting? It's, can we remove this physical part before it reaches the next station? That distinction changes the architecture. At the shift level, the time budget widens considerably. A supervisor can review patterns in stops, scrap, speed loss, or change over time over minutes or hours.

6:26 They need current data, but they don't need a response inside the machine cycle. This is where you calculate useful operational views, compare stations, and start seeing whether an issue belongs to one machine or the whole line. Maintenance planning stretches that clock even further. A planner might look at condition trends over days, then compare the likely work against spare parts, labor, production demand, and the next available maintenance window. That decision benefits from history. It may pull data from the CMS, ERP, MES, and the machine itself. And nobody needs that answer in 10 milliseconds, so think in time ranges. Milliseconds belong to control paths and local detection. Actions that must happen while the process is still moving. Seconds belong to operator alerts and supervised responses, where a person needs time to interpret what they're seeing.

7:11 Minutes and hours, fit shift management, production review, line balancing, and many MES workflows. Days and weeks fit maintenance planning, long-term quality trends, capacity analysis, and model training. And here's the trap most people fall into. They treat those clocks as a neat hierarchy, where slower always means cloud and faster always means edge. It's not that simple, but the clocks give you the first hard constraint. Every decision carries a deadline. Design for that deadline, or the system will fail when it matters most. Cloud round trips don't give you a fixed response time. You can estimate, monitor, and improve the network, but the path still crosses components outside the machine's local execution path. A signal leaves the station, passes through a connector or broker, crosses a network boundary, reaches a cloud service, waits for ingestion and processing, triggers a rule, then sends a command back through another set of systems.

7:56 Any single component can add delay, congestion, retries, a service issue, a certificate problem, or an overloaded queue can change the outcome. And a fast average isn't a safe maximum. That matters because engineers often quote the usual response time as if it describes the worst case. But the line doesn't care about the average when the one-late message arrives during the reject window. A local path has fewer moving paths. The signal stays within the plant, the rule runs near the source, and the action reaches the equipment without needing the one. That doesn't automatically make the local design correct, but it makes the time budget easier to control. When you map response time, don't start the clock at the moment your rule receives a clean event started at the physical change. The full response path includes sensing, transport, compute, action, and confirmation.

8:39 Did the sensor detect the condition quickly enough? Did the signal reach the logic without delay? Did the rule execute? Did the actuator receive the command? And did the system confirm that the reject gate, alarm, or machine state actually changed? Without confirmation, you don't have a closed response path. You have a hopeful message. A vibration spike might trigger a local alarm in seconds while its trend reaches central analysis later for a maintenance plan. A defect triggers a reject gate almost immediately while the image and production context travel upward for later review. Same source event, different decisions, different clocks. Timing gives you the first placement rule. The next test is harder. What happens when the network or a service disappears? Network loss is an architecture test.

9:19 Now take the network away. Picture a live production shift where the one link drops at 2.15 in the morning. The machine still have power. The PLC still run. Operators are loading material and clearing faults. But the cloud path is gone. Maybe because of a carrier issue, a fire wall change or plan work, nobody told the plan to but this is where a lot of cloud first designs reveal their real behavior. The dashboard stops updating, which is inconvenient. But if losing that dashboard also stops alarms, local checks, production records or a reject decision, then you didn't build visibility. You put production behind an internet dependency. Those are two very different failures. Loss of visibility means the central team can't see the current state for a while. Stale values, delayed events, or a clear offline indicator.

10:01 That needs handling, but the plant can keep running safely if local systems still have the information and authority they need. Loss of control is different. The plant can't perform a required action because a remote service is unreachable. That's a design failure. An operator shouldn't wait for a cloud round trip just to learn that a local machine crossed a known limit. And a controller should never need an outside connection to keep the sequence running. What you want is graceful degradation. Production continues within defined local limits. The edge layer keeps reading signals, running its local rules, and storing events that can't travel upstream. When the connection returns, it synchronizes those events in a controlled way. Without pretending the missing time never happened, that phrase graceful degradation gets thrown around loosely.

10:42 In practical terms, it means you document what continues, what pauses, what queues, and what needs human action during an outage. Say an edge node continues collecting machine states, cycle counts, local alarms, and inspection results. It writes those records to local storage with the source timestamp, quality state, and event identity. Upstream reporting may show a gap while the one is down, but the records haven't disappeared. They're waiting. That waiting period needs rules. How much local disk space exists? How long can the site remain disconnected? What happens when the buffer nears its limit? Does the node slow down capture, discard low priority telemetry, raise a local alert, or stop accepting new files? If you haven't answered those questions, the queue is just a future incident with a timestamp. Store and Ford also needs replay discipline.

11:24 When the connection comes back, you don't want a flood of old messages updating a current dashboard as though they just happened. Upstream systems need to know when the event occurred, when it arrived, if it's a retry, and whether it's already been processed. Use source timestamps where possible, keep an event ID, preserve sequence information when the process needs it, and mark data quality when a reading came from a buffered path rather than a live stream. Otherwise, a shift report quietly mixes yesterday's delayed events with today's real time events, and someone spends half a day arguing over a number that looked perfectly clean. Azure IoT operation supports edge processing and offline work, but don't read that as an unlimited offline guarantee. Microsoft's current reference guidance notes an offline limit of up to 72 hours with possible performance decline during that period.

12:09 That's not a flaw in the product. It's a reminder that your outage behavior belongs in the architecture. If your plant can lose the one for longer than that, design for it. Size local storage, define which workloads stay local, test recovery under load, and decide what the node does if it can't reconnect, can't renew a certificate, or can't forward a growing backlog. The test isn't whether the platform reconnects in a lab. It's whether the plant runs in a controlled state while it doesn't. And I'll be honest, I've walked into plans where the plan for network loss was, will just reconnect. That's not a plan that's hope, simulated, pull the cable, see what happens, the lab is cheap compared to a real production disruption. And here's one more problem that often hides inside a good buffer. You can retain every event, replay every message correctly, and still make poor decisions if the local layer doesn't know what that event means in the current production context.

12:55 Account without a work order is useless, a defect image without the product, recipe, or station state won't support later investigation. A machine alarm without the asset identity becomes another orphaned record in a data lake. So the next question isn't just what the edge can store. It's what the edge actually needs to know before it can act, retain evidence, and hand useful data back to the rest of the business. What the edge really is. Let's talk about what actually sits between a controller that has to keep running and enterprise systems that need a wider view. The edge is that local decision layer. It isn't just a gateway with a few tags wide into it, and it isn't simply a small server because someone wanted to put a server near the line. Its job is to take factory data, give it enough local meaning to act on, and move the right information to the systems above it.

13:37 That role needs a clear boundary. The PLC and safety controller stay closest to the machine. They handle deterministic sequence logic, interlocks, motion, and safety functions. The edge sits above that layer. It can observe machine state, combine signals from more than one source, apply local business rules, run a bounded inference model, and retain records when the upstream path goes down. Above the edge, sit, MES, ERP, quality systems, maintenance systems, and cloud data services. They need information from the floor, but they don't need direct access to every controller register. The edge gives them a controlled path, rather than turning the OT network into an extension of the corporate network. That distinction saves a lot of trouble later. Think about a simple condition monitoring case. A motor exposes current temperature and vibration through different devices.

14:21 The edge collects those signals, checks their units and timestamps, calculates a local health score, and raises a local event when the score crosses a defined limit. It can also retain a short window of source data around that event. That gives maintenance more than an alarm that says something looked odd. They can see the signal before the condition, during it, and after it. The machine controller still owns any direct protective action. The edge supplies context and local decision support. That is one form of ingestion. On a real shop floor, data doesn't arrive through one neat interface. You may have OPC UA from a newer machine, Modbus from an older drive, Profinet inside a control network, and a vendor specific device that exposes only the data its manufacturer chose to expose. None of that is unusual. It is a normal plant.

15:01 OPC UA helps because it can carry both data and a description of what that data represents. A temperature value can come with a node structure, data types, status, and engineering unit, if the machine builder modeled it properly. That gives you more than a flat list of tags. Modbus is much simpler. It often gives you registers and addresses. Then somebody needs to know that register 40127 means motor current and that the number needs scaling. It still works. But the meaning usually lives outside the protocol in a drawing a spreadsheet or the memory of the engineer who commissioned the line. Profinet operates close to the control world where predictable communication and device behavior matter. MQTT works differently. It moves messages through topics, which makes it useful for sharing events between local services and moving structured data toward other systems.

15:45 These are different shop floor languages. The edge acts as an interpreter, but it mustn't invent meaning while it translates. A good edge design maps the source signal to a known asset, applies the correct unit, carries a source timestamp, and keeps a quality flag with the data. It can filter noise and reduce needless traffic, but it should preserve enough evidence to explain why a rule fired. Otherwise, the edge becomes another black box between the plant and the data team. Local rules belong there when they need local inputs and a controlled response. That could mean detecting a state change, checking whether a machine has remained idle too long, or producing a local alert when a sensor combination points to a known fault condition. Infrains can belong there too if you have a trained vision model or an anomaly model with a defined input and output, the edge can run at close to the process.

16:27 The model reads local data, returns a score or class, and hands that result to the approved local workflow. It doesn't turn an industrial PC into a replacement for control engineering. That would be a very expensive way to rediscover why PLCs exist. Local storage is part of the same job. The edge needs enough disk, retention rules, and Q behavior to support its local services. Logs, event records, model output, and selected source evidence need a home that survives a short upstream interruption. A node with no storage plan isn't resilient. It's merely connected until it isn't. Once you deploy this across many lines, another issue appears. Every edge node can slowly become its own special case, a different script, a manual firewall rule, an undocumented connector version, and one password written somewhere nobody wants to discuss.

17:09 Avoid that. Run local services as managed modules or containers where it makes sense. Keep configuration declared in versioned. Group nodes by role, line type or site, then deploy changes in control batches with health checks and rollback. Remote management should give you visibility into node health and software state, but it shouldn't bypass plant change control. The goal isn't to make every edge node identical. A vision station and a simple protocol gateway have different needs. The goal is to stop those differences from turning into unmanaged exceptions. With that local layer defined, we can look upward. Cloud and fabric have a different job, and neither one needs to become the place where every raw tag goes to disappear. Well, what cloud and fabric actually do well? Cloud has a different kind of strength. It keeps history long enough to see patterns that a single shift, one line or even one plant can't see on its own, picture the same pump type running across five sites.

17:57 At one side, vibration looks normal. At another, the same pump needs more maintenance after a certain material change during a certain product family, or when ambient temperature sits within a certain range. No local node has enough scope to answer that well. That comparison work belongs above the plant. Cloud systems bring together data that lives in separate places and runs on different business clocks. They can compare asset behavior across sites, retain production history for years, train models against a larger set of evidence, and connect factory events with the systems that explain the business context around them. Microsoft fabric fits into that part of the architecture. It gives you a shared place for data products, analytics, semantic models, and reporting. So the people looking at production performance aren't each building their own extract from MES, ERP, and a folder of CSV files.

18:40 The dashboard is still only the visible part. Under it, you need a governed data layer where a downtime event, a work order, a quality record, and an energy reading can connect without each team changing the meaning halfway through the process. Fabric can support that shared layer, but it won't create it for you. You still need to decide what an asset is, what a production event means, and which system owns each fact. Cloud also works well for model training. A local inspection system may run a fixed model against each image because it needs an answer during production. Training a new version is a different job. It needs many examples, controlled labels, comparison across product variants, and enough compute to test whether the new model performs better before anyone sends it back to the plant. That work benefits from central history.

19:21 The same applies to quality drift. One line may show a small rise in a defect category that looks like random variation. Across several plants tied to a supplier lot or a recipe revision, the pattern may become obvious. Central analysis doesn't replace the local response. It gives engineering a wider field of view. Enterprise integration follows the same logic. ERP can tell you the order material, inventory position, cost center, and shipment commitment. MAs can tell you which operation ran, where work in progress sits, and what production state the line reported. Quality systems hold inspection results and disposition records. Maintenance systems hold work orders, spare parts, and asset history. Energy data can show what the line consumed during a run, not just what the site consumed over a month. Each system knows part of the story, none knows all of it.

20:04 When you connect them in the cloud data layer, you can ask questions that don't fit inside one system. Did a defect rise after a tool change for a certain material lot on night shift, while energy use increased and a specific machine state kept cycling? That is not a PLC question. It isn't really a dashboard question either. It's a data relationship question. Supply chain context expands the view again. A production issue might relate to a late material delivery, a substitute component, a changed supplier batch, or an order that now needs a different routing decision. Those links usually sit outside the control zone and they often need data from more than one site. But there is a trap here. Centralization doesn't mean sending every raw signal into one giant storage bucket and calling it a platform. Event ingestion and data retention are separate decisions, and event path brings data in.

20:45 It needs a defined purpose, a known producer, a clear schema, and a consumer that can use the event. Raw retention keeps original evidence for a defined period, often because engineers may need to inspect it later. Curated operational data turns those raw records into tables and measures people can trust for analysis and reporting. Those are different layers of work. Mix them together and people either lose the raw evidence they need or they hand business users a table full of machine-level noise and expect them to find the answer. A practical cloud path may retain raw machine events with their source details, then create curated operational records tied to asset, product, order, shift, and state. A semantic layer sits above that, so a production manager and a data analyst aren't calculating OEE or scrap from different definitions.

21:29 Fabric can help host and govern those layers. It gives you a common place to build a shared view, connect reporting to governed measures and support analysis across the business. Still, the platform can't resolve a disagreement that nobody has named. If MES and ERP disagree on what complete means, the data model needs to state which condition each system records and how they relate. If two plants use the same tag name for different units, ingestion won't fix the problem by moving it faster. Data only becomes useful for decisions when its meaning travels with it. The data model decides more than location. Here's a scenario that happens more often than you'd think. You have a tag called temperature, and it looks straightforward. But on one line, that tag reports degrees Celsius from the ceiling jaw.

22:09 On another line, its degrees Fahrenheit from a cabinet sensor, somewhere else. And somewhere else entirely, it's a calculated value from the MES, not a physical reading at all. Same name, different meaning, and that's how bad data spreads. So when people argue about edge versus cloud, they're really arguing about a data model problem. You can put a workload in the perfect spot, the edge, the cloud, wherever, and still get the wrong answer if your data shows up without enough context to explain what it actually describes. Think about it. A temperature reading needs an asset, a unit, a source timestamp, and a quality state. Usually, it also needs to know where it fits in the production process. Startup, normal running, cleaning, or fault condition. Without that context, a value is just a number moving through a pipeline.

22:50 ISE95 gives a useful structure for organizing that context without turning this into a standard's lecture. The idea is that data should connect to the asset that produced it, the material being processed, the work order, the operation, the shift, and the current state that changes what you can actually ask. Instead of did temperature rise? You can ask, did the temperature at this station rise during operation 40 while processing this material lot on this work order during night shift while the machine was running? That's a question an engineer can investigate. Picture a packaging line with two fillers that have the same model name. One runs a low viscosity product, the other runs a thicker product with a different recipe. Their current values might look similar, but the allowable range, expected cycle behavior, and quality risk are completely different.

23:32 If your data model only knows the tag name and timestamp, central analysis treats both conditions as if they're comparable. It might find a pattern that doesn't exist or miss one that does. The edge needs enough context for immediate local decisions, which asset a signal belongs to, what unit it uses, which local rule version applies, and whether the current machine state makes the signal relevant at all. That's not enterprise reasoning. It's the minimum information needed to avoid acting on nonsense. A local alarm shouldn't fire because a cleaning cycle looks unusual compared with production. The local layer needs to know the difference. Cloud and fabric need a broader version of that same context, connecting events across plants, systems, product lines, and time. That means linking a machine event to the work order in MS, the material record in ERP, the quality disposition, and maybe the maintenance history of that asset.

24:18 Neither layer owns all the context alone. The local layer uses just enough context to make a safe time bound decision, while the cloud layer uses shared context to reason across the business. A device registry helps keep that relationship stable. You need a reference point where an asset's identity doesn't change just because a PLC address changed, a gateway was replaced, or someone renamed a tag during a line upgrade. The registry can link the physical asset, its source systems, its location, its data points, and the metadata that explains how to interpret them. That metadata includes things people often leave in a commissioning file and then lose. Units, scale factors, asset hierarchy, calibration state, data owner, allowed value ranges, and the connection between a sensor and the machine function it observes.

24:59 As your device registry follows this general pattern by treating assets and devices as managed resources, whether you use that service or another registry, the architectural point is the same. Data needs a stable identity before it can move across OT and IT without losing its meaning. Now, this is also where digital twin and knowledge graph work become practical. A digital twin isn't a 3D model with some live colors on it. It's a model of an asset or process with current state and relationships. A knowledge graph takes that further by representing the links between assets, materials, operations, people, documents, and events. The useful part is the relationship. A defect isn't just a failed inspection result. It can connect to a specific station, a recipe revision, a material lot, a tool setting, and a work order.

25:40 A maintenance alert can connect to the motor, the line it serves, its prior work orders, and the product currently running through that line. That gives both people and systems a clear path to trace what happened. Without it, each system holds part of the story, and everyone ends up spending time joining records after the fact. But a weak data model gets even more expensive as data volume rises. One vague tag might not look like a problem, but thousands of vague tags streaming all day across dozens of lines create a massive pile of data that costs money to move, store, query, and later explain. And by the time you realize it, fixing the meaning means revisiting history you already collected. So let's follow one sensor stream from the machine to the cloud, because that's where a weak design becomes visible very quickly.

26:22 Raw telemetry is not a cloud strategy. Once a sensor stream leaves the machine, the obvious move is to send all of it upward. That works for a demo, but it rarely works as a factory data design. It takes vibration data from a motor. A conditioned sensor can sample at a rate that creates a steady stream of readings and raw waveform capture producers even more. Now add high-resolution images from an inspection station, cycle events from every machine, and energy readings from drives, compressors, and heaters. Pretty soon the question isn't whether you can send it all to the cloud you can. The question is, what anyone will actually do with it once it arrives? Most raw data has a short useful life. A normal vibration signal might show nothing new for hours. A camera may inspect thousands of good parts before one defect appears.

27:03 A machine can emit hundreds of state changes that only matter once they're tied together into a single downtime event, sending all of that upstream at full rate turns a data pipeline into a delivery truck full of packing material. The edge should reduce data close to the source, but reduction needs a purpose. For vibration, the local service can calculate a health indicator from the incoming signal, tracking overall level, change over time, or the presence of a known frequency pattern. The cloud doesn't need every sample just to know the condition stayed within its normal range for the last hour. For a vision system, the edge might keep the pass, fail result, defect class, confidence score, camera ID, and product ID. It can retain the image for failed parts plus a limited set of good ones for comparison and model checking.

27:44 That gives quality engineers evidence without treating every good image as permanent corporate history. Cycle data follows the same pattern. Instead of pushing every low-level transition into a reporting model, the local layer produces meaningful events. Cycle started, cycle completed, station blocked, station starved, reject triggered, machine stopped with duration, reason where known, and the current production context. That's data people can actually use. Energy data needs the same judgment. A local service collects frequent readings and calculates interval consumption, peak demand, idle load, or a change that crosses a defined limit. The central platform usually needs those measures, not every single sample from every device for all time. This doesn't mean raw data has no place.

28:24 Sometimes the raw signal is the evidence. If a bearing condition changes, you might need a window of waveform data before and after the event. If a camera rejects a part, you need the image and the inspection result. If a process excursion occurs, engineering needs the original readings to understand whether the calculation itself hit the problem. So retain evidence deliberately, keep a rolling local buffer where the use case requires it. When the condition triggers, preserve the bounded data window around it, along with how the local result was calculated, which rule or model version produced it, and which source signals fed it. That turns a local health score into something an engineer can inspect rather than a number they're expected to trust on faith. Then send the right forms of data upstream. Events, calculated features, summaries, alerts, and selected samples linked to a specific reason for retention.

29:09 That reduces network traffic, but bandwidth is only one part of the cost. Every raw message also lands somewhere. It consumes storage, goes through ingestion services, shows up in backups and later costs time and compute when someone queries it. And if the data crosses boundaries or needs to leave the cloud again, transfer charges add up to, I'm not going to throw out a single number for that. It depends on sampling rate, image size, retention rules, query patterns, and how many sites contribute data. But the direction is obvious. A design that collects everything forever ends up paying for every unnecessary bite more than once. There's a danger on the other side too. Teams sometimes filter too aggressively, sending only a single alarm bit and then discover they can't investigate the alarm. The event says a fault occurred, but nobody can trace the source signal, the local calculation, the product being processed, or the machine condition around that moment.

29:56 That doesn't reduce complexity. It moves the complexity into the next root cause meeting. Each filter needs a traceable rule. Each aggregate needs a clear window and method. Each event needs enough source detail to point back to the evidence that produced it. If you can't explain how a summary came into existence, it's not suitable for engineering decisions. Raw telemetry becomes useful when you decide what action, record, or question it supports. And that gives us a practical way to draw the boundary. Before placing any workload, ask what happens if the answer arrives late, disappears during an outage, or loses the context that made it meaningful. The six questions for every workload. So now you've got enough to ask a better question than edge or cloud. Here's the real challenge. Take each workload one at a time and run it through six questions.

30:40 The answers will usually point you to a clear placement, where they don't. That's where the real design work starts. Start with the response deadline, not the preferred response time, the actual deadline. Ask what happens if the answer arrives late. Does a part move beyond the rejection point doesn't operate or lose the chance to prevent damage or does the decision just show up later in a report with no physical consequence? Write that consequence right next to the time. Needs to be fast, doesn't tell anyone much. But action must reach the local process before the next station accepts the part, gives your team a clear boundary to design around. Next question. Does the work need to continue through a network outage? This is separate from speed. A workload might handle a delay of several minutes under normal conditions, but still need local operation because the plant can't lose that function when the one link goes down.

31:24 Think about local event capture, operator information, or a line level condition rule. If the site needs it while disconnected, its working path needs local compute, local data, and a defined fallback state. And be precise about what continue actually means. Does it run fully? Does it run with reduced data? Does it queue records for later? Or does it stop and force and operate it to take over? Any answer is fine as long as it's intentional. The dangerous answer is finding out what happens when the outage actually hits. Next up is data gravity. How much data does this workload create? And in what form does that data become useful? A small status event can travel almost anywhere without much worry. But a stream of images, vibration samples, or high rate process values brings a different set of constraints because the raw source data might be huge while the decision only needs a small calculated result.

32:08 Don't just ask, can we transmit it? Ask what actually has to move? Maybe the local process needs the raw signal for a short time. While central analysis just needs a health score and records tied to unusual conditions. Maybe the cloud needs selected evidence later, but not continuous full-rate data. The format matters just as much as the volume. Raw data, calculated features, events, and business records each belong in a different part of that path. Scope comes next. Is this decision about one sensor, one asset, a line, a plant or a group of plants? Local scope usually favors local placement because the inputs and action both live close together. Broaders scope pushes the work upward because you're comparing sources that don't share the same local environment. A machine can assess its own current condition.

32:48 A plant can compare its different lines. A central data layer can compare a process across sites, product families, and time periods. If you try to force a cross-site question onto every edge node, you end up with repeated logic and partial answers. And running a machine-level action through a central system just adds distance where you don't need it. The fifth question is context. What information does this decision need before it can be trusted? Some decisions depend on a local signal and the current equipment state. Others need the work order, product recipe, material lot, maintenance status, or customer requirement that lives in MES and ERP that doesn't automatically mean every decision that touches enterprise context belongs in the cloud. You might need to send a small, approved set of current context down to the plant before production starts.

33:32 Then the local service uses that context during the run without calling ERP every time a sensor changes. This is where you separate live reference data from live dependency. If the edge needs the current recipe or order identity, synchronize it as controlled reference data. If the edge has to query a distant business system for every local decision, you've created a fragile command path. That difference looks small on a slide. During a production issue, it's not small at all. The final question is risk and governance. Who can approve the rule? Who owns the source data? Who investigates when a decision looks wrong? What needs an audit trail? What happens if the rule changes the model changes or the identity used by the edge node expires? Safety requires validated local control paths. Security requires separated networks, known identities, and limited permissions.

34:13 Privacy or intellectual property might restrict what leaves the site. Audit needs a record of which version of a rule acted against what input and when. And ownership matters just as much. If OT owns safe machine operation, a cloud team can't quietly publish a change that affects a local action without an agreed approval path. If the data team owns the semantic definition of a production event, a gateway script can't change its payload just because it seemed convenient on a Friday afternoon. That's how integration turns into archaeology. So use the six questions together-- deadline, outage behavior, data gravity, scope, context, and risk. They don't give you a product recommendation. They give you an architecture decision you can explain. Once you apply that test, honestly, some workloads stop being edge versus cloud debates entirely.

34:57 They clearly belong close to the process. Own decisions that must stay at the edge. Once you put a workload through those six questions, some answers come back immediately. If a decision protects a person, prevents equipment damage, or acts on a part still moving through the line, it belongs close to the process. But let's keep the boundary clear. Safety and interlocks belong first in the controller domain using the safety system and validated circuits designed for that job. A cloud service has no place in an emergency stop path. Neither does a general edge server running a container that happens to be healthy today. The edge can observe safety-related state. It can record a guard door event, show the sequence of faults around it, and notify the right people. It can even support analysis that helps you find repeat causes. But it must not become an untested shortcut around deterministic safety logic.

35:40 That distinction often gets blurred when people talk about real-time edge control. Real-time compared to what? A local industrial PC may respond quickly enough for an alarm or a vision result, but that doesn't make it a safety controller. Physical risk needs a physical control path with known behavior under fault conditions. Machine protection sits close to that boundary. Take a bearing alarm. A condition monitoring service might detect a vibration pattern that suggests a developing problem, then prompt an operator or create a maintenance event. That's useful. But if the machine needs immediate protection from an extreme condition, the protective action has to follow a local, engineered path that doesn't depend on an analytic service, a broker, or a one connection. The same goes for temperature and pressure. A thermal limit on a heater, a pressure excursion in a process vessel, or a sudden current rise in a drive can go from normal to damaging very quickly.

36:26 The protection path needs to live where the sensor, logic, and actuator can still work together when every higher level system is unavailable. The edge can add intelligence around that path. It can collect the measurements, identify the event, preserve local records, and send a structured incident upward when the network comes back. It can help explain whether the thermal limit appeared after a recipe change, an operator action, or a change in ambient conditions, but it should never become the only thing standing between the process and damage. That's a much healthier use of the edge. It supports control without pretending to replace it. Close loop quality gives you another clear local decision. Imagine an inspection station where a part passes a camera, moves through a short section of conveyor, and reaches a reject mechanism.

37:06 The inspection result has to travel from the camera, or local inference process, to the reject logic before the part reaches that mechanism. If the signal comes late, the bad part moves on with the good ones. There is no useful excuse for that decision to wait on fabric. The local path needs the camera input, the inspection result, the part position, or encoder reference, and the reject action. It might involve a PLC, a dedicated vision controller, or an edge process depending on how you design the system. What matters is that the entire decision stays inside a time budget the line can meet every cycle. A cloud service can receive the result later. It can store defect evidence, compare defect types, and support engineering review. But the local system needs to reject the physical part, while it's still possible to reject it. Once the part has passed that point, the most accurate cloud result in the world is just a very detailed explanation of why you missed it.

37:51 Local operator prompts also belong here when delay creates waste or damage. Think about a setup condition that starts drifting. The system may not need to stop the machine immediately, but the operator needs a prompt while there's still time to adjust the setting, inspect the material, or slow the process before the issue creates a stack of scrap. The prompt should appear where the work happens, with enough context to support a decision. Not an alert that says anomaly detected and sends someone hunting through five screens. Show the station, the current condition, the relevant limit, and the action the operator is expected to take. Local doesn't mean automatic in every case. Sometimes the right response is an operator confirmation because a false stop costs more than a short review. Sometimes the right response is a controlled local action because the risk of waiting is too high.

38:33 You decide that through process knowledge, not because an AI model returned a confident score. That brings us to edge AI. Edge AI fits defined time bound detection work. A vision model can classify an image, and an anomaly model can score a local sensor pattern. A local classifier can identify whether a machine sound matches a known state. These are bounded tasks with known inputs, known outputs, and a clear action path. Keep the scope narrow. The model should not receive vague authority to optimize the line. It should detect a specific condition, return a result with confidence and version information, and pass that result into an approved local workflow. If the model is unavailable, the system needs a known fallback. Pause inspection, root to manual review, use a fixed rule, or place the machine in a safe operating state.

39:15 That fallback is part of the design, not an afterthought. A general edge platform can run rules, local analytics, and inference close to the process. It can reduce the distance between data and action. Yet deterministic PLC logic still owns the machine sequence, interlocks, and direct equipment control where timing and predictable behavior demanded. Keep those responsibilities separate, and the local architecture stays understandable under pressure. Some decisions can move upward after that. They just need a time budget that proves they can. Decisions that usually belong in the cloud. Now let's move up a level. From decisions that have to protect the process to decisions that need a wider field of view, a single motor can report its own condition. But it can't tell you whether that motor type fails more often at one side than another after a certain service procedure, or when a specific product mix runs through the plant.

40:00 That question needs history from many assets and often many plants. Fleet-wide asset analysis belongs in the cloud because the patent exists across the fleet. You might find that similar drives show the same current signature before failure, but only when running a certain load profile. Or a pump may appear healthy in isolation, but comparison shows it consumes more energy and gets more callouts than peer assets. That's not a local alarm problem. It's a pattern problem. The same logic applies to recurring failure modes. Maintenance teams usually know the painful ones by experience, but central history can test whether that experience holds across all sites, shifts, asset ages, and product families. It can separate a genuine repeat failure from a problem that just happened loudly last week.

40:41 Quality drift needs that same wider view. A defect rate can move slowly enough that nobody sees it in a single shift. Maybe one product variant begins showing a small surface defect after a supplier change. Maybe the rate rises only on one material lot with one tool revision at one site. Each system may hold part of the answer, but the pattern only appears when those records come together across time. That work needs product data, material data, supplier data, inspection records, process settings, and site context. It also needs a stable definition of the defect itself. If one plant classifies a Marcus cosmetic and another calls it a reject, central analysis just scales up the disagreement. Cloud data platforms give you room to hold that history and test the relationships without loading each plant with a copy of the same analytical workload.

41:24 Fabric can support the govern data layer for that work, where quality, production, maintenance, and business data connect through agreed definitions. Model training belongs there too. A local model may inspect a part or score a machine condition during production, but training a replacement model is a separate process with its own controls. You need historical samples, labels you can trust, a way to compare candidate models, and a record of why one version passed while another did not. Treat model approval like an engineering change, not like a file upload. Before a new model reaches a plant, someone needs to validate it against the right product range and operating conditions. They need to check false rejects, misdefacts, input changes, and the action that follows its output. If the model will influence quality release, maintenance spend, or process response, the approval path should name the people responsible.

42:08 The cloud gives you a controlled place to train, validate, document, and approve those versions. It can also hold the rollout record, which version went to which site, which line received it when it became active, and what happened when it was rolled back. That record matters when production changes. A model that worked well last year may behave differently after a camera replacement, new lighting, a recipe update, or a product design change. Central monitoring can spot those changes across the installed base, then root a reviewed version back to the places that needed. The plant receives an approved package, not an experiment disguised as a deployment. Corporate reporting belongs above the plant for a simpler reason. The audience and the data scope sit there. Finance may need production costs, scrap costs, energy use, labor data, inventory movement, and delivery performance in one view.

42:52 Compliance teams may need a durable history of quality records, process evidence, approvals, and changes. Plant teams supply parts of that record, but the company needs a consistent view across sites. That view has to preserve source and ownership. A corporate report shouldn't quietly rewrite a plant event because a financial calendar uses a different cutoff. You can combine the facts while still retaining where each fact came from when it happened and which system recorded it. Enterprise cost analysis also benefits from central context. A local line can show downtime. It usually can't calculate the full commercial effect without order priority, customer commitments, material availability, labor, energy rates, alternate capacity, and downstream impact. Those inputs live across business systems. Planning is where this becomes very clear.

43:34 ERP records what happened, orders, inventory, purchase, activity, confirmations, financial facts. It provides the business record of the company. APS asks a different question. Given current demand, available capacity, material limits, labor constraints, change over rules, maintenance windows, and routing options, what could happen next? That scenario analysis attests feasible plans across a planning horizon rather than treating the current schedule as fixed. A planner may ask whether an urgent order can fit without pushing another commitment late, whether a line can absorb a disruption or whether a maintenance window needs to move because the next few days leave no safe capacity. Those questions need enterprise scope. They need data from more than one system and often more than one plant. They also tolerate a slower decision cycle because the output is a proposed plan, not a direct command to a machine.

44:18 A plan can recommend work. Execution still needs to check the actual state of the floor. The useful factory workloads rarely sit in one place from start to finish. They cross the boundary several times with each layer doing the work it can actually support. The closed loop between edge and cloud. The useful pattern is a loop, but not a loop where every signal travels up to the cloud and waits for permission to come back down. The edge captures what happens at the process. It checks signals against local rules, acts where a local action is allowed, and retains the evidence around that event, cloud systems collect the longer history, compare it with other assets and sites, then produce a better rule, threshold or model. But only after someone has reviewed it. That revised logic returns to the edge as an approved update and the edge uses it during the next production run.

45:04 This keeps the immediate decision close to the physical process while still allowing the wider system to learn. You aren't choosing between local action and central analysis. You're giving each one a defined part of the same operational loop. Take predictive maintenance. A motor begins to show a vibration pattern outside the expected local range. The edge detects it, records the condition and raises the local alarm that maintains or the operator needs. If the process needs protection, the protective path already exists locally. Nothing waits for a remote trend calculation before the plant responds. Meanwhile, the edge sends the alarm, the health measures, and selected source evidence upstream when the path is available. Over time, cloud analysis can compare that motor with similar motors, inspect past maintenance records, and look for cases where the alarm preceded a real failure, as well as cases where it did not.

45:51 That work may show that the local threshold is too loose for one asset class or too sensitive under a known operating condition. But that doesn't mean a cloud job quietly edits a limit on a running line. An engineer reviews the finding. Maintenance confirms that the failure mode and response make sense. OT checks the local impact, then the team publishes a new threshold or rule version through a controlled release path. The edge receives that version, checks that it's valid for its asset and line configuration, and applies it under the release conditions you defined. If the new rule behaves badly, you need to know exactly how to return to the prior version. That's rollback, and it needs to be designed before the update looks necessary. Quality inspection follows the same loop, though the time pressure can be much tighter.

46:31 A local vision process inspects each part and produces the local result needed by the line. The inspection system records the decision, model version, confidence, product reference, and the evidence you chose to retain. If a part needs to leave the line, the local process acts within its own defined window. Cloud analysis looks at the larger pattern later. It can compare defect types across shifts, products, cameras, plants, and recipe versions. It can spot drift that is too gradual for one operator to notice, like a rise in a certain defect after a tooling change or a decline in model confidence after a lighting change. The outcome may be an updated inspection rule package. That package might contain a revised model, a new confidence threshold, a changed defect mapping, or a modified evidence retention rule.

47:13 It should carry a version and approval record, a target scope, and a defined way back if it fails in production. A rule package without those details is just a surprise delivered to the shop floor. This separation matters because automatic local action and a policy change are not the same thing. An approved local rule can reject a part because the rule already passed process quality and engineering review. The rule is acting inside a boundary that people agreed in advance. Changing that rule changes the boundary. It can alter scrap rates, operate a workload, product release decisions, and sometimes equipment behavior. That requires human approval. You can automate deployment mechanics without automating authority. A platform can distribute a signed package to the right nodes, stage it on a limited group of lines, report its health, and stop the rollout when defined checks fail.

47:56 People still decide whether the rule should exist, where it should apply, and what the fallback should be. The edge also needs a local fallback when the update path fails. If cloud access disappears, the edge keeps running the last approved version. If a new model won't load, it should not leave the station in an unknown state. It can return to the earlier model, use a fixed threshold rule, send uncertain parts to manual review, or raise a local fault that requires intervention. The right choice depends on the process, but keep trying the cloud isn't a fallback. Track these states clearly, which version is active, which version is staged, which rule produced this event, whether the edge applied the update rejected it or reverted after a health check failed. Without that record, an engineer reviewing a defect or alarm later cannot tell whether the process changed because the machine changed or because the software changed.

48:42 That's where many industrial AI discussions become vague. People talk about a model that learns continuously as if it should revise its own authority while production is running. In a factory, learning and acting need separate controls, the learning system can propose, the approved local system can act, the change path between them leads owners, versions, tests, and a way back. AI doesn't remove the edge cloud boundary. It makes the boundary easier to see because every model forces you to answer two questions, where does it learn and where does it make the decision? Those are not the same place. So let's separate training from inference. Industrial AI without the magic show. Let's cut through the AI hype for a second. Industrial AI is patent detection tied to a process decision.

49:22 That's the useful definition. It takes known inputs like a camera image, vibration signal, temperature trend, sound pattern, or machine state sequence, then returns an output a process can use. That output might be a defect class and anomaly score, a likely condition, or a confidence level that tells an operator to take a closer look. Sounds simple, and that's because it is. Most of the work sits around the model not inside it. You need to know what signal goes in, what the output means, how confident the model has to be before anyone acts and who owns the action that follows. If a model can't answer those questions, it might make an interesting demo, but it's not ready for a production decision. At the edge AI usually runs as inference. The model already exists. It takes a local input, performs the calculation, and returns a result fast enough for the process.

50:05 Think of a vision station that classifies a surface defect while the part is still within the inspection area, or a condition monitoring service that scores a vibration pattern and marks it as normal, uncertain, or out of range. A local classifier might sort machine sounds into operating states, so an operator can spot a developing issue before it becomes a failure. The edge doesn't need to invent new models while the line runs. It needs to apply a known version consistently, log the result, and follow a defined response path. That distinction is what keeps the system manageable. A model result should include more than just pass or fail. You want the model version, input source, time, confidence score, and the business or production reference at that moment. If a local action follows, record that too. Later when someone asks why a part got rejected or why an alarm went off, a screenshot from a dashboard won't cut.

50:50 Cloudwork is different because the questions need more history and more scope. Training a model means collecting examples over time, checking the labels, picking the input data, testing candidate versions, and comparing results against known cases. For a quality model, that could mean thousands of images across product variants, lighting conditions, camera positions, and actual defect types. For condition monitoring, it means comparing equipment data with confirmed maintenance findings over months or years. A single edge node rarely has that wider view. It sees its own process fine, but it can't easily tell whether its model works across different sites or a changing product mix. Central training brings those records together. Compare models under the same test conditions, keeps the approval history, and shows whether a proposed version actually improves detection without creating too many false alerts or false rejects.

51:36 Still, more data doesn't fix bad data. Model drift starts when the relationship between the input and the real process changes. A vision model can lose accuracy after a camera is replaced, a lens is cleaned differently or lighting shifts over time. An anomaly model might start flagging normal behavior after a machine gets a new motor, a recipe changes the load profile or the process itself changes. The model isn't confused, the world around it changed. Bad labels cause another problem. If inspectors disagree about what counts as a defect, the training set teaches that disagreement to the model. If a maintenance record says bearing issue because that was the nearest available code, even though the fault was actually misalignment, the model learns a weak connection between signal and outcome. This is why industrial AI depends on process knowledge.

52:17 Data scientists can test model behavior, but they need quality engineers, maintenance teams and operators to explain what actually happened on the floor. The same goes when product families change. A model trained on one finish, material, shape, or operating range may not apply clearly to the next one, treating it as universal because the input still looks like an image or a sensor stream is how models quietly start making bad decisions. Human review stays in the loop where the result affects safety, product release, or maintenance spend. A model can flag a condition, rank a set of images or suggest a motor needs attention, but a safety response still follows validated control design. A quality release decision may need an engineer to review the evidence. A costly maintenance action may need a planner to weigh the condition against production demand, available parts, and the actual failure mode.

53:02 Automation has its place. Authority needs a boundary. When you define those boundaries, industrial AI becomes useful engineering rather than a vague promise attached to a cloud diagram. And quality inspection shows the architecture problem more clearly than almost any other use case because the line keeps moving while the decision is being made. The quality inspection, where latency becomes scrap, take a vision station on a moving line, apart passes the camera, the image gets captured, the inspection logic decides whether that part meets the rule and a reject device has one short chance to remove it. After that, the part has moved on. The available time can be less than a second, sometimes a lot less. That window includes image capture, transfer, inference, result handling, part tracking, triggering the reject device, and confirming the action actually happened.

53:44 People talk about vision AI like the model as the hard part, but on a live line, the real question is whether the result reaches the physical part before the reject window closes. That whole path has to be local. The camera, local inference service, encoder or part tracking signal, and reject mechanism need a shared time reference and a known response path. If the vision system finds a defect, it has to link that result to the correct physical item, not just send a defect message into a queue and hope the rest of the system catches up. A late result can reject the wrong part, and that's worse than no result at all. Imagine a line inspecting printed labels on filled cartons. The camera spots a missing date code, the conveyor keeps moving, and the reject station sits a few meters downstream. Local logic has to attach that failed image to the cartons position, then fire the reject at the right moment.

54:28 It also has to confirm whether the actuator fired and whether the carton actually left the flow. That's a closed local process, even if the inspection model runs on an industrial PC rather than inside the camera. Local evidence matters too. For every failed inspection, keep the image or bounded image set, the defect class, confidence score, camera identity, lighting or inspection recipe where relevant and the local model version capture the time and part reference with it. That record lets someone later answer a basic question. Did the system find a real defect or did it misread glare, dust, motion blur or a changed package design? Without local evidence, a pass or fail result is a dead end. A plant might also keep a controlled sample of passing images, not every image forever because that creates a storage problem with no clear purpose.

55:12 But enough samples to monitor whether visual conditions are changing. Lensware, camera drift, lighting changes, a new surface finish, all these can shift the input away from what the inspection rule expects. The line still needs its local decision. Cloudwork begins after that decision has protected the process. Central systems can keep selected samples and inspection records over a longer period, comparing defect types between lines, products, sites, material lots and inspection settings. That's how a gradual change becomes visible before it turns into a customer complaint or a full shift of rework. Fabric can provide the shared data layer for this, but only when the inspection result arrives with enough process context. A defect record should connect to the batch or lot, the recipe, the tool or station setup, the operator shift and the work order.

55:55 That sounds like a lot of fields until you try to investigate a quality issue without them. Say quality sees a rise in seal defects. The image shows the defect but not the cause. Connect the record to a batch and you can check if the issue started with a material change, connected to the recipe and you can see if a parameter revision changed the process. Add tool state and shift and the problem might point toward where, setup or a condition that only shows up during a certain operating period. The goal isn't to blame a shift or a supplier from one chart. It's to stop treating inspection as an isolated pass fail machine. A good cloud data set lets quality engineers compare the same defect across time and conditions. It can show if one camera produces more uncertain results after a lighting change. It can reveal that a defect cluster follows a specific product variant and it can supply curated examples for retraining where confirmed effect and good images become part of the next model review.

56:44 That training path needs clean labels. If images enter the central store with no agreed defect code, product reference or way to tell if a human later overruled the machine result, they're weak training material. Stored files, not usable quality evidence. This is why sending only pass or fail limits improvement. Pass or fail can support account and feed a simple reject total but it can't explain which defect appeared, what the model saw, how certain it was, whether the reject action succeeded or what process conditions surrounded the part. And when defect rates rise, it can't help you separate a real process change from a vision system problem. The full architecture gives each layer a job. Local inspection catches the item while action is still possible. Local records preserve the immediate evidence, the cloud connects that evidence to production history and supports comparison, drift review and controlled retraining.

57:28 Maintenance follows a similar boundary, although its failure modes look very different. Predictive maintenance, protection here, learning there. So maintenance presents the same kind of boundary just in a different shape. The real question isn't just whether you can predict a failure, it's whether the machine needs protection right now or whether the team needs better evidence to schedule work later. You start near the asset. An edge service collects vibration, temperature and current from a motor, pump, fan or conveyor drive. Then turns those signals into local condition indicators people can actually use. The raw signals might arrive at different rates and from different devices. So the local service first checks the source timestamp, unit and signal quality before it calculates anything. And that work needs discipline.

58:08 Take vibration. The edge might calculate a measure that tracks change an overall motion or a known frequency band. For temperature, it might track the rate of rise instead of just the current value. Current can show load changes, a blocked mechanism, or a change in how hard the motor works under the same operating state. In practical terms, none of those indicators prove the failure by itself, but together they give the local system a much better view of condition than a single threshold on one tag. That indicator also needs operating context. A motor drawing more current during a heavy product run might be perfectly normal. The same current pattern during an idle state that deserves a different response. Local condition monitoring works when it knows enough about the machine state to judge the signal against the right baseline. Some conditions develop slowly and others don't.

58:50 A gradual change in vibration might give maintenance days or weeks to inspect and plan a repair. But a rapid temperature rise, severe vibration, or sudden current excursion requires an immediate local alarm in a protective path that doesn't depend on analysis outside the plant. And you need to keep those paths separate. The edge can detect the local condition, record the signal window, and notify the operator or maintenance team, while the controller and protection system handle any action that must protect equipment under a fault. You don't want a maintenance analytics service deciding whether a machine should survive a dangerous condition. That sounds obvious until someone sticks a cloud alert in the middle of the response chain. A local alarm should tell people what changed, where it changed, and what evidence supports it.

59:32 Motor health low isn't enough. The alert needs the asset identity, the condition indicator, the operating state, the time, and the rule version that produced it. If the local system can't explain the alarm, the next shift will learn to ignore it. So then the cloud takes on a different job. Over months, central history can track asset health across the actual operating life of equipment. It can compare like for like motors, pumps, gearboxes, or drives that work under similar conditions, then look for patterns a single machine can't reveal. Maybe one asset type shows a repeat current pattern before a certain failure. Maybe a maintenance action clears the symptom, but not the cause. Or maybe the same equipment lasts much longer at one side because a setup or lubrication practice differs.

1:00:12 Central analysis gives the maintenance team a way to test those questions against records instead of relying only on memory. Comparison only works when like for like means something. In practical terms, two pumps with the same nameplate might run different fluids, loads, schedules, or duty cycles. Their condition scores shouldn't enter the same comparison without that context. The cloud needs asset class, configuration, operating range, production conditions, and maintenance history. Otherwise, the analysis can produce a tidy chart that compares unlike machines. This is also where people confuse condition monitoring with maintenance workflow. Condition monitoring asks, what does this asset look like right now? And has that condition changed? It produces readings, trends, indicators, alarms, and evidence.

1:00:55 And that belongs close to the equipment for local awareness and fast response, while the longer history can move upward for analysis. Maintenance workflow asks something else. Should we create work? When can it happen? Who performs it? What parts are needed? And what does the production plan allow? And that decision reaches beyond the edge. The CMS holds maintenance plans, work orders, labor records, failure codes, and completion in history, while ERP may hold spare parts, purchasing data, inventory, supplier lead times, and cost records. And the production schedule tells you whether a maintenance window exists, or whether taking the asset down will disrupt an order that can't move easily. Those systems need to meet above the machine. A condition score can trigger a recommendation, but it shouldn't silently become a maintenance work order without a review of the production consequence.

1:01:40 A planner might see that the bearing condition looks worse, but the required spare isn't on site and the line carries an urgent order. The right action might be to run under tighter observation, move production, obtain the part, and schedule a controlled stop. That is a maintenance decision, not a sensor decision. So the edge keeps the asset visible and protected while disconnected. The cloud keeps the long view, connects condition evidence to maintenance history, and helps teams choose work that fits the operational situation. When those roles stay clear, predictive maintenance stops being a dashboard full of warnings and becomes a root from signal to planned action. And OE often gets treated as a cloud dashboard problem, but it starts much closer to the machine. OE and real-time visibility without fake precision.

1:02:21 So OE looks simple when it lands in a dashboard, availability, performance, and quality. But those numbers only mean something if the line states beneath them describe what actually happened. Start at the machine. You need a reliable view of running, stopped, faulted, blocked, starved, set up, cleaning, and any other state that changes how you interpret output, plus good counts, reject counts, cycle timing, speed loss, and downtime reasons where the process can provide them. That data begins close to the equipment because the equipment produces it. A PLC knows a machine stopped, a counter knows a unit passed, and a vision station may know a part failed inspection. But none of those signals automatically explains production performance without some local work to turn rapid, noisy changes into events people can trust.

1:03:03 A machine can flicker between running and stopped during a short jam, report a fault bit for a fraction of a second, then clear it before anyone sees it, and account may reset after a controller restart. If you send every raw state transition directly to a report, the result can look very precise while describing a machine that never existed. So the edge layer helps resolve that. It can apply rules for state duration, debount signals, correlate related changes, and create a bounded downtime event rather than a burst of unrelated bits. It can keep the original source data available for review, but publish the operational event that the MES and analytics layer can use. A short stop might only become a downtime event after it lasts beyond the agreed threshold, a machine fault, may need correlation with the actual run state before it counts as lost availability, and a reject count may need to connect to the product count from the same station and time window.

1:03:49 Those rules need to come from production reality, not from whatever fields happen to be easy to read. The edge also keeps the event trail intact when the network drops, because production doesn't pause politely because a one-root failed. Machine states continue changing, parts continue moving, and operators still need a view of what is happening. Local buffering lets the edge hold events with their original timestamps and sequence details then forward them when the connection returns, which prevents a false gap in the shift record and prevents later-riving events from looking like they happened after the outage, which can distort OEE calculations and confuse every investigation that follows. MES adds the production context that the machine cannot know alone. The machine can report that it produced 4,000 units, and MES can connect those units to an order, an operation, a work center, a planned quantity, and the current work in progress state.

1:04:37 It can guide the reason code workflow when a line stops, so the operator or supervisor can distinguish material shortage from change over, planned maintenance, quality hold, or an equipment fault. And that distinction changes the conversation. Without a reason code, downtime becomes a generic red bar, but with a reason code tied to a defined workflow and subject to review, the team can separate a recurring equipment issue from a scheduling problem or an upstream material issue. The data still needs care, because people will choose the fastest option when the list contains 20 vague choices. Keep the reason codes practical. They should describe decisions someone can act on, not create a taxonomy that only survives in a PowerPoint file. Fabric sits above that operational record and connects it to the wider business picture, joining line events with order data, material records, shift calendars, quality cost, energy use, and other facts that help explain the consequence of lost performance.

1:05:26 A 10 minute stop doesn't carry the same impact in every case. It may occur during a low priority run, with spare capacity, or during the final hours of an order that has no room left before shipment. The machine event stays the machine event, but the business context changes how teams prioritize the response. This is where real-time visibility can become useful without pretending it is perfect. A dashboard should show the current state, current counts, active stops, and whether incoming data remains healthy and it should also show uncertainty. If a source is offline, if events are still queued locally, or if a reason code remains pending, the display needs to say so. Don't fill the gap with a clean number. A dashboard that reports 87.3% OE, while the count source and MES production record disagree isn't giving management clarity.

1:06:11 It's giving them a decimal place. The argument should move upstream, toward the source state, count logic, time boundary, and ownership of the production record. The same applies when one report calls a machine idle while another calls it planned downtime. You don't solve that by averaging the two values in fabric. You define the state model, document the rule, and keep the source facts visible enough to test it. Real-time visibility means you can see what the process currently reports, how confident the system is in that record, and where the data came from. It doesn't mean every chart deserves blind trust because it updates every few seconds. Once that foundation is in place, OE can help teams find the right questions instead of producing another screen everyone argues about during the morning meeting. And scheduling needs a different type of decision boundary.

1:06:52 APS ERP, MES, and the decision horizon. Scheduling starts to break down when you expect one system to answer every question. ERP keeps the business facts. It tracks orders entered, inventory received or consumed, purchase activity, production confirmations, and cost and financial records. It tells the company what it committed to, what moved, and what closed. That record matters, but it doesn't run a line. APS, advance planning and scheduling, works with a different question. It looks forward asking what plan can still work given demand, available capacity, material limits, labor, changeover rules, maintenance windows, and routing choices. A plan is not a command. APS can test whether an urgent order fits before a promised chip date, and it can show the knock-on effect of moving a job from one line to another.

1:07:34 It can also compare options when a material delivery slips or a bottleneck asset loses capacity. The output is a feasible future scenario based on the constraints it knows, at that point. MES sits between that plan and the physical work. It dispatches work to the shop floor, tracks work in progress, records completion, and applies the production rules that belong to execution. If an order moves through several operations, a mess keeps track of where it is, what quantity passed, what quantity failed, and what still needs to happen before the order can close. The edge sees a much shorter horizon. It sees that a machine is faulted now, that a conveyor is blocked, that a tool change is taking longer than expected, or that a station can't accept the next part. Those facts can change fast, and they are not always visible in a planning model until someone sends them upward in a usable form.

1:08:18 Consider a line that loses a filler halfway through a shift. The local systems detect the fault and the line enters its defined response state. Operators work the immediate problem, while MES records the disruption against the active operation and work order once the event has enough context to be recorded properly. That event can trigger planning questions upstream. Can the remaining line capacity still complete the order? Should another line take part of the volume, does the change create a material issue later in the route? Is there a maintenance window that now needs to move? APS can test those options against the wider schedule because it sees constraints the line itself doesn't. But the plan must come back down as a proposal for execution, not as a remote hand on the machine. A central system may decide that order 4/7 should move to another work center. But before that change reaches the floor, MES needs to check whether the order is released, whether the material is available, whether the recipe applies, whether the work center can run it, and whether the current production state allows a safe handoff.

1:09:10 The edge needs to confirm the local conditions too. It checks whether the machine is actually available, whether a changeover is in progress, whether there is still product in the line, and whether the operator has completed the required checks. A plan built at 10 and 2 arc can already be wrong at 10/07 if the local state changed. This is where cloud first scheduling ideas become risky. A cloud planner may have good information about demand and capacity, but it should not issue direct machine command simply because it found a better schedule. Machines don't execute schedules, they execute validated sequences under current physical conditions. The controller owns the machine sequence while the edge reports local state and applies only the local logic it has been approved to apply. MES owns execution workflow and work in progress records.

1:09:51 APS evaluates future options across constraints. ERP remains the business system of record. Those roles can exchange information quickly without becoming the same system. A useful rescheduling loop looks like this. A local disruption occurs, the edge and plant systems capture the facts with the right time and asset context. MES records the execution impact. APS receives a planning relevant event, tests alternatives, and returns a revised plan or dispatch priority, and MES validates that plan against the live execution state before work changes on the floor. That may sound slower than letting the cloud control everything, but it is safer, easier to explain and far less likely to produce a schedule that looks perfect while the plant cannot run it. There is also a human decision in this path.

1:10:31 A plan may accept the proposed change, but a production supervisor may reject it because a line carries a quality hold, a changeover would create too much loss, or the local crew lacks the needed skill. Planning systems should expose those trade-offs, not hide them behind an automatic instruction that appears on the screen after the useful moment passed. The same separation appears when people talk about digital twins. A twin needs live-state close to the process, but it also needs a place to reason across relationships, history, and possible futures.