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

1
00:00:00,000 --> 00:00:02,880
Picture a packaging line mid-shift, the conveyor stops.
2
00:00:02,880 --> 00:00:04,480
The operator sees a fault at the station,
3
00:00:04,480 --> 00:00:06,440
but the cloud dashboard still shows green.
4
00:00:06,440 --> 00:00:06,940
Why?
5
00:00:06,940 --> 00:00:08,880
Because the event is waiting on a network trip,
6
00:00:08,880 --> 00:00:11,800
an ingestion path, a rule, and a message back down.
7
00:00:11,800 --> 00:00:14,000
That delay costs more than the cloud bill ever will.
8
00:00:14,000 --> 00:00:15,040
It creates scrap.
9
00:00:15,040 --> 00:00:16,800
It holds people at a stopped line.
10
00:00:16,800 --> 00:00:18,560
It fills networks with data nobody needs.
11
00:00:18,560 --> 00:00:21,160
And when something fails, there's one awkward question left
12
00:00:21,160 --> 00:00:22,800
who actually owns the decision.
13
00:00:22,800 --> 00:00:24,840
A cloud first data project usually starts
14
00:00:24,840 --> 00:00:26,600
by sending everything upward.
15
00:00:26,600 --> 00:00:29,080
A factory needs the opposite starting point.
16
00:00:29,080 --> 00:00:31,480
A local decision path for anything that must act
17
00:00:31,480 --> 00:00:33,200
while the product is still in reach.
18
00:00:33,200 --> 00:00:35,760
In this video, I'm going to give you a workload placement test
19
00:00:35,760 --> 00:00:37,720
you can use for every factory decision.
20
00:00:37,720 --> 00:00:40,520
And there's one decision type that should never wait for fabric.
21
00:00:40,520 --> 00:00:43,360
So let's stop debating platforms for a second and look at time.
22
00:00:43,360 --> 00:00:45,320
Stop asking edge or cloud.
23
00:00:45,320 --> 00:00:48,960
Most teams ask, should we run this at the edge or in the cloud?
24
00:00:48,960 --> 00:00:51,400
It sounds like a sensible question, but it pushes the discussion
25
00:00:51,400 --> 00:00:55,000
toward product choice before anyone has described the actual work.
26
00:00:55,000 --> 00:00:57,880
The better question is, what decision are we trying to make?
27
00:00:57,880 --> 00:01:00,520
Who needs it and what happens if it arrives late?
28
00:01:00,520 --> 00:01:03,280
That turns edge versus cloud into workload classification.
29
00:01:03,280 --> 00:01:04,520
You aren't picking a winner.
30
00:01:04,520 --> 00:01:07,000
You're placing each piece of work where it can do its job
31
00:01:07,000 --> 00:01:09,200
without creating a new weak point in the plant.
32
00:01:09,200 --> 00:01:10,680
Take a typical production line.
33
00:01:10,680 --> 00:01:14,080
At the bottom, a controller reads inputs and drives outputs.
34
00:01:14,080 --> 00:01:16,520
It runs the machine sequence, holds interlocks
35
00:01:16,520 --> 00:01:18,960
and responds inside the time limits the machine needs.
36
00:01:18,960 --> 00:01:20,120
That's control.
37
00:01:20,120 --> 00:01:22,360
Above that, you may have a system that shows line state,
38
00:01:22,360 --> 00:01:25,560
raises alarms, collects counts, or lets a supervisor see
39
00:01:25,560 --> 00:01:26,720
why a station paused.
40
00:01:26,720 --> 00:01:27,640
That's supervision.
41
00:01:27,640 --> 00:01:29,960
It may need to respond quickly, but it doesn't always
42
00:01:29,960 --> 00:01:32,480
need the same deterministic behavior as the controller.
43
00:01:32,480 --> 00:01:33,440
Then you have analysis.
44
00:01:33,440 --> 00:01:36,440
Analysis looks across time and asks why a stop repeats,
45
00:01:36,440 --> 00:01:39,960
why a defect rate changes, or whether a motor trend looks different
46
00:01:39,960 --> 00:01:41,240
from last month.
47
00:01:41,240 --> 00:01:44,160
It can wait longer because it needs history and context.
48
00:01:44,160 --> 00:01:45,960
Planning works on another horizon.
49
00:01:45,960 --> 00:01:49,360
It takes orders, material limits, labor, maintenance windows,
50
00:01:49,360 --> 00:01:52,000
and machine capacity, then asks what should run next.
51
00:01:52,000 --> 00:01:53,480
Learning sits beside that.
52
00:01:53,480 --> 00:01:56,960
It uses historical data to improve a detection rule or train a model,
53
00:01:56,960 --> 00:01:59,520
then sends an approved version back to where it will run.
54
00:01:59,520 --> 00:02:02,040
Reporting comes last, though people often start there
55
00:02:02,040 --> 00:02:03,640
because dashboards are visible.
56
00:02:03,640 --> 00:02:05,440
Reporting tells the business what happened.
57
00:02:05,440 --> 00:02:08,320
It doesn't keep a line safe, reject a bad part in time,
58
00:02:08,320 --> 00:02:10,240
or keep production moving when the one drops.
59
00:02:10,240 --> 00:02:11,920
These jobs don't belong in one place just
60
00:02:11,920 --> 00:02:13,640
because they touch the same machine.
61
00:02:13,640 --> 00:02:15,280
Think about a filler with a check-wear.
62
00:02:15,280 --> 00:02:17,040
The controller must stop or reject based
63
00:02:17,040 --> 00:02:18,640
on a direct local signal.
64
00:02:18,640 --> 00:02:21,480
Align lead needs to see the alarm and confirm the condition.
65
00:02:21,480 --> 00:02:23,680
Quality may review the trend across the shift.
66
00:02:23,680 --> 00:02:25,240
Maintenance may compare that station
67
00:02:25,240 --> 00:02:27,000
with similar stations in other plants.
68
00:02:27,000 --> 00:02:29,880
Planning may decide whether the order can still ship on time.
69
00:02:29,880 --> 00:02:31,680
One physical event, several decisions,
70
00:02:31,680 --> 00:02:33,320
different owners, different clocks,
71
00:02:33,320 --> 00:02:36,360
this is why a single architecture for the entire plant
72
00:02:36,360 --> 00:02:39,120
almost always turns into a compromised nobody likes.
73
00:02:39,120 --> 00:02:41,480
Put everything in the cloud and you create parts
74
00:02:41,480 --> 00:02:43,640
that depend on connectivity for work
75
00:02:43,640 --> 00:02:45,360
that should stay close to the machine.
76
00:02:45,360 --> 00:02:47,440
Put everything at the edge and you build local islands
77
00:02:47,440 --> 00:02:49,200
where each plant learns only from itself
78
00:02:49,200 --> 00:02:51,880
than someone exports spreadsheets to compare them anyway.
79
00:02:51,880 --> 00:02:53,760
Vendor diagrams rarely show that part.
80
00:02:53,760 --> 00:02:56,320
They show clean arrows from PLC to gateway to cloud,
81
00:02:56,320 --> 00:02:59,320
then a dashboard and maybe a glowing AI icon floating above it.
82
00:02:59,320 --> 00:03:02,120
They don't show the night shift when a certificate expires.
83
00:03:02,120 --> 00:03:04,000
They don't show an operator who needs an answer now
84
00:03:04,000 --> 00:03:05,600
while the message queue backs up.
85
00:03:05,600 --> 00:03:07,480
They don't show a maintenance engineer
86
00:03:07,480 --> 00:03:10,080
trying to tell whether an alarm came from the machine,
87
00:03:10,080 --> 00:03:12,800
the edge node, the MES, or a cloud rule
88
00:03:12,800 --> 00:03:14,800
that ran against old data.
89
00:03:14,800 --> 00:03:16,440
Those are architecture questions.
90
00:03:16,440 --> 00:03:19,200
They don't disappear because the diagram uses more arrows.
91
00:03:19,200 --> 00:03:22,440
A hybrid architecture isn't two copies of the same system.
92
00:03:22,440 --> 00:03:24,640
One on-site and one in Azure.
93
00:03:24,640 --> 00:03:27,720
That waste effort and creates two versions of the same fact.
94
00:03:27,720 --> 00:03:29,120
Hybrid means rooted work.
95
00:03:29,120 --> 00:03:31,200
The controller handles deterministic control.
96
00:03:31,200 --> 00:03:33,520
The edge layer collects and interprets local signals,
97
00:03:33,520 --> 00:03:36,760
keeps local rules running and passes useful events upward.
98
00:03:36,760 --> 00:03:39,080
Plant systems manage execution and local workflow
99
00:03:39,080 --> 00:03:40,160
where that belongs.
100
00:03:40,160 --> 00:03:42,160
Cloud and fabric hold shared history.
101
00:03:42,160 --> 00:03:44,320
Connect the dots between IT and OT
102
00:03:44,320 --> 00:03:45,840
and support questions that need data
103
00:03:45,840 --> 00:03:47,640
beyond one machine or one plant.
104
00:03:47,640 --> 00:03:49,080
Each layer needs a clear role.
105
00:03:49,080 --> 00:03:52,120
More importantly, each command path needs a clear limit.
106
00:03:52,120 --> 00:03:54,440
If a cloud service proposes a new threshold,
107
00:03:54,440 --> 00:03:56,920
that isn't the same as letting a driver machine output.
108
00:03:56,920 --> 00:03:58,560
If an edge node detects a condition
109
00:03:58,560 --> 00:04:00,360
that doesn't mean it owns the safety function,
110
00:04:00,360 --> 00:04:02,680
if MES receives a downtime event,
111
00:04:02,680 --> 00:04:05,280
it doesn't become the source for the raw controller state.
112
00:04:05,280 --> 00:04:06,600
You need to be precise here
113
00:04:06,600 --> 00:04:10,080
because vague ownership becomes a production problem later.
114
00:04:10,080 --> 00:04:12,800
Now, response time is usually the first test people use.
115
00:04:12,800 --> 00:04:15,840
Fair enough, if the machine needs an answer in milliseconds,
116
00:04:15,840 --> 00:04:17,840
don't send the question across the internet
117
00:04:17,840 --> 00:04:20,000
and hope the reply comes back in time.
118
00:04:20,000 --> 00:04:22,640
But timing alone can still give you the wrong placement.
119
00:04:22,640 --> 00:04:24,480
A decision might have plenty of time,
120
00:04:24,480 --> 00:04:25,800
yet still need to run locally
121
00:04:25,800 --> 00:04:28,640
because the plant must continue during a network outage.
122
00:04:28,640 --> 00:04:30,840
Another decision might run fast at the edge,
123
00:04:30,840 --> 00:04:32,280
yet still need cloud history
124
00:04:32,280 --> 00:04:34,400
before anyone should change a process rule.
125
00:04:34,400 --> 00:04:35,760
So before you place a workload,
126
00:04:35,760 --> 00:04:39,040
you need to see the clocks already running inside the factory.
127
00:04:39,040 --> 00:04:40,840
The factory has more than one clock.
128
00:04:40,840 --> 00:04:42,640
Here's the thing about a factory floor.
129
00:04:42,640 --> 00:04:44,360
It doesn't run on a single timeline.
130
00:04:44,360 --> 00:04:47,640
It runs on several and each one handles delay differently.
131
00:04:47,640 --> 00:04:50,000
That distinction shapes the entire architecture
132
00:04:50,000 --> 00:04:52,280
and it's usually the first thing people get wrong.
133
00:04:52,280 --> 00:04:54,440
The machine cycle sits at the fastest end.
134
00:04:54,440 --> 00:04:55,680
A sensor changes state,
135
00:04:55,680 --> 00:04:57,400
the PLC evaluates the logic
136
00:04:57,400 --> 00:05:00,440
and an actuator responds while the machine keeps moving.
137
00:05:00,440 --> 00:05:03,120
On a high speed line, that entire path lives in milliseconds.
138
00:05:03,120 --> 00:05:04,920
It's not a request for analysis.
139
00:05:04,920 --> 00:05:06,960
It's part of the physical process itself.
140
00:05:06,960 --> 00:05:08,400
Wove and into the control loop
141
00:05:08,400 --> 00:05:09,720
that keeps the line running,
142
00:05:09,720 --> 00:05:11,880
safety runs on an even tighter path,
143
00:05:11,880 --> 00:05:13,720
but that logic belongs in the controller
144
00:05:13,720 --> 00:05:15,360
and the dedicated safety system.
145
00:05:15,360 --> 00:05:18,440
Not in fabric, not in any general purpose edge application.
146
00:05:18,440 --> 00:05:21,160
If a guard opens or an emergency stop is pressed,
147
00:05:21,160 --> 00:05:23,080
the machine needs a deterministic response
148
00:05:23,080 --> 00:05:24,920
through a validated local path.
149
00:05:24,920 --> 00:05:27,280
A networked service can record what happened.
150
00:05:27,280 --> 00:05:30,440
It should never decide whether a person remains safe.
151
00:05:30,440 --> 00:05:32,880
Now, the operator clock often runs in seconds.
152
00:05:32,880 --> 00:05:34,880
Picture a vibration sensor on a motor.
153
00:05:34,880 --> 00:05:36,920
The local system detects a sharp change,
154
00:05:36,920 --> 00:05:38,680
compares it against a defined rule
155
00:05:38,680 --> 00:05:41,080
and fires an alarm at the station.
156
00:05:41,080 --> 00:05:43,400
That operator needs enough context to act,
157
00:05:43,400 --> 00:05:45,200
which motor, what changed,
158
00:05:45,200 --> 00:05:46,560
how long it's persisted,
159
00:05:46,560 --> 00:05:50,080
and whether the line can keep running at reduced speed.
160
00:05:50,080 --> 00:05:51,840
An alarm that shows up 10 minutes later
161
00:05:51,840 --> 00:05:53,200
might look correct on a dashboard,
162
00:05:53,200 --> 00:05:55,600
but it missed the window where it could actually help.
163
00:05:55,600 --> 00:05:57,120
Quality has its own clock, too.
164
00:05:57,120 --> 00:05:58,640
A camera catches a defect.
165
00:05:58,640 --> 00:06:00,800
The local inspection process classifies it
166
00:06:00,800 --> 00:06:02,440
and the reject gate needs a signal
167
00:06:02,440 --> 00:06:04,760
before that part leaves the rejection zone.
168
00:06:04,760 --> 00:06:06,720
That could be milliseconds or a fraction of a second,
169
00:06:06,720 --> 00:06:08,640
depending on line speed and distance.
170
00:06:08,640 --> 00:06:10,880
The decision isn't, is this image interesting?
171
00:06:10,880 --> 00:06:13,120
It's, can we remove this physical part
172
00:06:13,120 --> 00:06:15,120
before it reaches the next station?
173
00:06:15,120 --> 00:06:17,640
That distinction changes the architecture.
174
00:06:17,640 --> 00:06:20,520
At the shift level, the time budget widens considerably.
175
00:06:20,520 --> 00:06:24,280
A supervisor can review patterns in stops, scrap, speed loss,
176
00:06:24,280 --> 00:06:26,760
or change over time over minutes or hours.
177
00:06:26,760 --> 00:06:28,040
They need current data,
178
00:06:28,040 --> 00:06:30,520
but they don't need a response inside the machine cycle.
179
00:06:30,520 --> 00:06:33,160
This is where you calculate useful operational views,
180
00:06:33,160 --> 00:06:36,360
compare stations, and start seeing whether an issue belongs
181
00:06:36,360 --> 00:06:38,680
to one machine or the whole line.
182
00:06:38,680 --> 00:06:41,400
Maintenance planning stretches that clock even further.
183
00:06:41,400 --> 00:06:43,600
A planner might look at condition trends over days,
184
00:06:43,600 --> 00:06:45,840
then compare the likely work against spare parts,
185
00:06:45,840 --> 00:06:47,440
labor, production demand,
186
00:06:47,440 --> 00:06:49,920
and the next available maintenance window.
187
00:06:49,920 --> 00:06:51,640
That decision benefits from history.
188
00:06:51,640 --> 00:06:57,160
It may pull data from the CMS, ERP, MES, and the machine itself.
189
00:06:57,160 --> 00:06:59,280
And nobody needs that answer in 10 milliseconds,
190
00:06:59,280 --> 00:07:00,720
so think in time ranges.
191
00:07:00,720 --> 00:07:03,560
Milliseconds belong to control paths and local detection.
192
00:07:03,560 --> 00:07:06,200
Actions that must happen while the process is still moving.
193
00:07:06,200 --> 00:07:09,240
Seconds belong to operator alerts and supervised responses,
194
00:07:09,240 --> 00:07:11,680
where a person needs time to interpret what they're seeing.
195
00:07:11,680 --> 00:07:12,480
Minutes and hours,
196
00:07:12,480 --> 00:07:14,840
fit shift management, production review, line balancing,
197
00:07:14,840 --> 00:07:16,320
and many MES workflows.
198
00:07:16,320 --> 00:07:17,840
Days and weeks fit maintenance planning,
199
00:07:17,840 --> 00:07:21,000
long-term quality trends, capacity analysis, and model training.
200
00:07:21,000 --> 00:07:23,240
And here's the trap most people fall into.
201
00:07:23,240 --> 00:07:25,240
They treat those clocks as a neat hierarchy,
202
00:07:25,240 --> 00:07:28,160
where slower always means cloud and faster always means edge.
203
00:07:28,160 --> 00:07:29,480
It's not that simple,
204
00:07:29,480 --> 00:07:31,920
but the clocks give you the first hard constraint.
205
00:07:31,920 --> 00:07:34,040
Every decision carries a deadline.
206
00:07:34,040 --> 00:07:35,160
Design for that deadline,
207
00:07:35,160 --> 00:07:37,280
or the system will fail when it matters most.
208
00:07:37,280 --> 00:07:39,640
Cloud round trips don't give you a fixed response time.
209
00:07:39,640 --> 00:07:42,200
You can estimate, monitor, and improve the network,
210
00:07:42,200 --> 00:07:44,840
but the path still crosses components outside the machine's
211
00:07:44,840 --> 00:07:46,200
local execution path.
212
00:07:46,200 --> 00:07:49,040
A signal leaves the station, passes through a connector or broker,
213
00:07:49,040 --> 00:07:51,120
crosses a network boundary, reaches a cloud service,
214
00:07:51,120 --> 00:07:53,720
waits for ingestion and processing, triggers a rule,
215
00:07:53,720 --> 00:07:56,280
then sends a command back through another set of systems.
216
00:07:56,280 --> 00:07:58,920
Any single component can add delay, congestion,
217
00:07:58,920 --> 00:08:01,240
retries, a service issue, a certificate problem,
218
00:08:01,240 --> 00:08:03,720
or an overloaded queue can change the outcome.
219
00:08:03,720 --> 00:08:05,880
And a fast average isn't a safe maximum.
220
00:08:05,880 --> 00:08:09,160
That matters because engineers often quote the usual response time
221
00:08:09,160 --> 00:08:10,920
as if it describes the worst case.
222
00:08:10,920 --> 00:08:12,520
But the line doesn't care about the average
223
00:08:12,520 --> 00:08:15,240
when the one-late message arrives during the reject window.
224
00:08:15,240 --> 00:08:17,440
A local path has fewer moving paths.
225
00:08:17,440 --> 00:08:20,640
The signal stays within the plant, the rule runs near the source,
226
00:08:20,640 --> 00:08:23,360
and the action reaches the equipment without needing the one.
227
00:08:23,360 --> 00:08:25,680
That doesn't automatically make the local design correct,
228
00:08:25,680 --> 00:08:27,760
but it makes the time budget easier to control.
229
00:08:27,760 --> 00:08:30,480
When you map response time, don't start the clock
230
00:08:30,480 --> 00:08:32,880
at the moment your rule receives a clean event
231
00:08:32,880 --> 00:08:34,520
started at the physical change.
232
00:08:34,520 --> 00:08:37,240
The full response path includes sensing, transport,
233
00:08:37,240 --> 00:08:39,520
compute, action, and confirmation.
234
00:08:39,520 --> 00:08:41,520
Did the sensor detect the condition quickly enough?
235
00:08:41,520 --> 00:08:43,440
Did the signal reach the logic without delay?
236
00:08:43,440 --> 00:08:44,520
Did the rule execute?
237
00:08:44,520 --> 00:08:46,440
Did the actuator receive the command?
238
00:08:46,440 --> 00:08:48,960
And did the system confirm that the reject gate, alarm,
239
00:08:48,960 --> 00:08:50,560
or machine state actually changed?
240
00:08:50,560 --> 00:08:53,240
Without confirmation, you don't have a closed response path.
241
00:08:53,240 --> 00:08:54,440
You have a hopeful message.
242
00:08:54,440 --> 00:08:57,640
A vibration spike might trigger a local alarm in seconds
243
00:08:57,640 --> 00:09:01,280
while its trend reaches central analysis later for a maintenance plan.
244
00:09:01,280 --> 00:09:04,160
A defect triggers a reject gate almost immediately
245
00:09:04,160 --> 00:09:07,400
while the image and production context travel upward for later review.
246
00:09:07,400 --> 00:09:10,440
Same source event, different decisions, different clocks.
247
00:09:10,440 --> 00:09:12,720
Timing gives you the first placement rule.
248
00:09:12,720 --> 00:09:14,240
The next test is harder.
249
00:09:14,240 --> 00:09:17,760
What happens when the network or a service disappears?
250
00:09:17,760 --> 00:09:19,760
Network loss is an architecture test.
251
00:09:19,760 --> 00:09:21,400
Now take the network away.
252
00:09:21,400 --> 00:09:25,200
Picture a live production shift where the one link drops at 2.15 in the morning.
253
00:09:25,200 --> 00:09:26,520
The machine still have power.
254
00:09:26,520 --> 00:09:27,880
The PLC still run.
255
00:09:27,880 --> 00:09:30,640
Operators are loading material and clearing faults.
256
00:09:30,640 --> 00:09:32,000
But the cloud path is gone.
257
00:09:32,000 --> 00:09:35,400
Maybe because of a carrier issue, a fire wall change or plan work,
258
00:09:35,400 --> 00:09:37,200
nobody told the plan to but this is where a lot
259
00:09:37,200 --> 00:09:40,280
of cloud first designs reveal their real behavior.
260
00:09:40,280 --> 00:09:42,960
The dashboard stops updating, which is inconvenient.
261
00:09:42,960 --> 00:09:45,040
But if losing that dashboard also stops alarms,
262
00:09:45,040 --> 00:09:48,040
local checks, production records or a reject decision,
263
00:09:48,040 --> 00:09:49,560
then you didn't build visibility.
264
00:09:49,560 --> 00:09:51,920
You put production behind an internet dependency.
265
00:09:51,920 --> 00:09:53,400
Those are two very different failures.
266
00:09:53,400 --> 00:09:55,440
Loss of visibility means the central team
267
00:09:55,440 --> 00:09:57,400
can't see the current state for a while.
268
00:09:57,400 --> 00:10:01,360
Stale values, delayed events, or a clear offline indicator.
269
00:10:01,360 --> 00:10:04,520
That needs handling, but the plant can keep running safely
270
00:10:04,520 --> 00:10:08,680
if local systems still have the information and authority they need.
271
00:10:08,680 --> 00:10:09,960
Loss of control is different.
272
00:10:09,960 --> 00:10:11,720
The plant can't perform a required action
273
00:10:11,720 --> 00:10:13,640
because a remote service is unreachable.
274
00:10:13,640 --> 00:10:15,080
That's a design failure.
275
00:10:15,080 --> 00:10:17,280
An operator shouldn't wait for a cloud round trip
276
00:10:17,280 --> 00:10:19,960
just to learn that a local machine crossed a known limit.
277
00:10:19,960 --> 00:10:21,840
And a controller should never need an outside connection
278
00:10:21,840 --> 00:10:23,160
to keep the sequence running.
279
00:10:23,160 --> 00:10:25,080
What you want is graceful degradation.
280
00:10:25,080 --> 00:10:27,600
Production continues within defined local limits.
281
00:10:27,600 --> 00:10:30,840
The edge layer keeps reading signals, running its local rules,
282
00:10:30,840 --> 00:10:33,560
and storing events that can't travel upstream.
283
00:10:33,560 --> 00:10:36,200
When the connection returns, it synchronizes those events
284
00:10:36,200 --> 00:10:37,400
in a controlled way.
285
00:10:37,400 --> 00:10:39,600
Without pretending the missing time never happened,
286
00:10:39,600 --> 00:10:42,800
that phrase graceful degradation gets thrown around loosely.
287
00:10:42,800 --> 00:10:45,400
In practical terms, it means you document what continues,
288
00:10:45,400 --> 00:10:48,200
what pauses, what queues, and what needs human action
289
00:10:48,200 --> 00:10:49,120
during an outage.
290
00:10:49,120 --> 00:10:51,800
Say an edge node continues collecting machine states,
291
00:10:51,800 --> 00:10:54,880
cycle counts, local alarms, and inspection results.
292
00:10:54,880 --> 00:10:56,720
It writes those records to local storage
293
00:10:56,720 --> 00:10:59,120
with the source timestamp, quality state, and event
294
00:10:59,120 --> 00:10:59,920
identity.
295
00:10:59,920 --> 00:11:02,600
Upstream reporting may show a gap while the one is down,
296
00:11:02,600 --> 00:11:04,320
but the records haven't disappeared.
297
00:11:04,320 --> 00:11:05,000
They're waiting.
298
00:11:05,000 --> 00:11:06,640
That waiting period needs rules.
299
00:11:06,640 --> 00:11:08,360
How much local disk space exists?
300
00:11:08,360 --> 00:11:10,040
How long can the site remain disconnected?
301
00:11:10,040 --> 00:11:12,120
What happens when the buffer nears its limit?
302
00:11:12,120 --> 00:11:15,320
Does the node slow down capture, discard low priority telemetry,
303
00:11:15,320 --> 00:11:18,120
raise a local alert, or stop accepting new files?
304
00:11:18,120 --> 00:11:19,640
If you haven't answered those questions,
305
00:11:19,640 --> 00:11:22,400
the queue is just a future incident with a timestamp.
306
00:11:22,400 --> 00:11:24,800
Store and Ford also needs replay discipline.
307
00:11:24,800 --> 00:11:26,320
When the connection comes back, you
308
00:11:26,320 --> 00:11:28,880
don't want a flood of old messages updating
309
00:11:28,880 --> 00:11:31,080
a current dashboard as though they just happened.
310
00:11:31,080 --> 00:11:33,600
Upstream systems need to know when the event occurred,
311
00:11:33,600 --> 00:11:35,680
when it arrived, if it's a retry,
312
00:11:35,680 --> 00:11:37,520
and whether it's already been processed.
313
00:11:37,520 --> 00:11:40,680
Use source timestamps where possible, keep an event ID,
314
00:11:40,680 --> 00:11:43,200
preserve sequence information when the process needs it,
315
00:11:43,200 --> 00:11:44,640
and mark data quality when a reading
316
00:11:44,640 --> 00:11:47,080
came from a buffered path rather than a live stream.
317
00:11:47,080 --> 00:11:49,560
Otherwise, a shift report quietly mixes
318
00:11:49,560 --> 00:11:52,600
yesterday's delayed events with today's real time events,
319
00:11:52,600 --> 00:11:54,360
and someone spends half a day arguing
320
00:11:54,360 --> 00:11:57,400
over a number that looked perfectly clean.
321
00:11:57,400 --> 00:12:00,760
Azure IoT operation supports edge processing and offline work,
322
00:12:00,760 --> 00:12:03,320
but don't read that as an unlimited offline guarantee.
323
00:12:03,320 --> 00:12:05,720
Microsoft's current reference guidance notes an offline limit
324
00:12:05,720 --> 00:12:08,520
of up to 72 hours with possible performance decline
325
00:12:08,520 --> 00:12:09,360
during that period.
326
00:12:09,360 --> 00:12:10,680
That's not a flaw in the product.
327
00:12:10,680 --> 00:12:12,400
It's a reminder that your outage behavior
328
00:12:12,400 --> 00:12:13,840
belongs in the architecture.
329
00:12:13,840 --> 00:12:16,160
If your plant can lose the one for longer than that,
330
00:12:16,160 --> 00:12:17,280
design for it.
331
00:12:17,280 --> 00:12:20,000
Size local storage, define which workloads stay local,
332
00:12:20,000 --> 00:12:22,680
test recovery under load, and decide what the node does
333
00:12:22,680 --> 00:12:25,000
if it can't reconnect, can't renew a certificate,
334
00:12:25,000 --> 00:12:26,840
or can't forward a growing backlog.
335
00:12:26,840 --> 00:12:29,880
The test isn't whether the platform reconnects in a lab.
336
00:12:29,880 --> 00:12:32,320
It's whether the plant runs in a controlled state
337
00:12:32,320 --> 00:12:33,160
while it doesn't.
338
00:12:33,160 --> 00:12:34,600
And I'll be honest, I've walked into plans
339
00:12:34,600 --> 00:12:37,800
where the plan for network loss was, will just reconnect.
340
00:12:37,800 --> 00:12:40,480
That's not a plan that's hope, simulated, pull the cable,
341
00:12:40,480 --> 00:12:41,960
see what happens, the lab is cheap
342
00:12:41,960 --> 00:12:43,600
compared to a real production disruption.
343
00:12:43,600 --> 00:12:46,440
And here's one more problem that often hides inside a good buffer.
344
00:12:46,440 --> 00:12:49,800
You can retain every event, replay every message correctly,
345
00:12:49,800 --> 00:12:51,920
and still make poor decisions if the local layer doesn't
346
00:12:51,920 --> 00:12:55,920
know what that event means in the current production context.
347
00:12:55,920 --> 00:12:57,880
Account without a work order is useless,
348
00:12:57,880 --> 00:13:00,960
a defect image without the product, recipe, or station state
349
00:13:00,960 --> 00:13:02,800
won't support later investigation.
350
00:13:02,800 --> 00:13:04,600
A machine alarm without the asset identity
351
00:13:04,600 --> 00:13:07,200
becomes another orphaned record in a data lake.
352
00:13:07,200 --> 00:13:09,760
So the next question isn't just what the edge can store.
353
00:13:09,760 --> 00:13:11,760
It's what the edge actually needs to know
354
00:13:11,760 --> 00:13:15,200
before it can act, retain evidence, and hand useful data
355
00:13:15,200 --> 00:13:17,160
back to the rest of the business.
356
00:13:17,160 --> 00:13:18,480
What the edge really is.
357
00:13:18,480 --> 00:13:20,640
Let's talk about what actually sits between a controller
358
00:13:20,640 --> 00:13:22,520
that has to keep running and enterprise systems
359
00:13:22,520 --> 00:13:23,760
that need a wider view.
360
00:13:23,760 --> 00:13:25,480
The edge is that local decision layer.
361
00:13:25,480 --> 00:13:27,920
It isn't just a gateway with a few tags wide into it,
362
00:13:27,920 --> 00:13:29,480
and it isn't simply a small server
363
00:13:29,480 --> 00:13:31,520
because someone wanted to put a server near the line.
364
00:13:31,520 --> 00:13:34,640
Its job is to take factory data, give it enough local meaning
365
00:13:34,640 --> 00:13:36,680
to act on, and move the right information
366
00:13:36,680 --> 00:13:37,960
to the systems above it.
367
00:13:37,960 --> 00:13:39,400
That role needs a clear boundary.
368
00:13:39,400 --> 00:13:42,280
The PLC and safety controller stay closest to the machine.
369
00:13:42,280 --> 00:13:44,640
They handle deterministic sequence logic, interlocks,
370
00:13:44,640 --> 00:13:46,120
motion, and safety functions.
371
00:13:46,120 --> 00:13:47,480
The edge sits above that layer.
372
00:13:47,480 --> 00:13:49,400
It can observe machine state, combine signals
373
00:13:49,400 --> 00:13:52,280
from more than one source, apply local business rules,
374
00:13:52,280 --> 00:13:54,720
run a bounded inference model, and retain records
375
00:13:54,720 --> 00:13:56,800
when the upstream path goes down.
376
00:13:56,800 --> 00:14:00,120
Above the edge, sit, MES, ERP, quality systems,
377
00:14:00,120 --> 00:14:02,720
maintenance systems, and cloud data services.
378
00:14:02,720 --> 00:14:04,200
They need information from the floor,
379
00:14:04,200 --> 00:14:07,400
but they don't need direct access to every controller register.
380
00:14:07,400 --> 00:14:09,320
The edge gives them a controlled path,
381
00:14:09,320 --> 00:14:11,880
rather than turning the OT network into an extension
382
00:14:11,880 --> 00:14:13,000
of the corporate network.
383
00:14:13,000 --> 00:14:15,280
That distinction saves a lot of trouble later.
384
00:14:15,280 --> 00:14:17,440
Think about a simple condition monitoring case.
385
00:14:17,440 --> 00:14:19,160
A motor exposes current temperature
386
00:14:19,160 --> 00:14:21,040
and vibration through different devices.
387
00:14:21,040 --> 00:14:23,080
The edge collects those signals, checks their units
388
00:14:23,080 --> 00:14:25,640
and timestamps, calculates a local health score,
389
00:14:25,640 --> 00:14:29,000
and raises a local event when the score crosses a defined limit.
390
00:14:29,000 --> 00:14:31,280
It can also retain a short window of source data
391
00:14:31,280 --> 00:14:32,360
around that event.
392
00:14:32,360 --> 00:14:33,960
That gives maintenance more than an alarm
393
00:14:33,960 --> 00:14:35,480
that says something looked odd.
394
00:14:35,480 --> 00:14:37,280
They can see the signal before the condition,
395
00:14:37,280 --> 00:14:38,840
during it, and after it.
396
00:14:38,840 --> 00:14:41,480
The machine controller still owns any direct protective action.
397
00:14:41,480 --> 00:14:44,120
The edge supplies context and local decision support.
398
00:14:44,120 --> 00:14:45,600
That is one form of ingestion.
399
00:14:45,600 --> 00:14:48,800
On a real shop floor, data doesn't arrive through one neat interface.
400
00:14:48,800 --> 00:14:51,120
You may have OPC UA from a newer machine,
401
00:14:51,120 --> 00:14:52,720
Modbus from an older drive,
402
00:14:52,720 --> 00:14:54,360
Profinet inside a control network,
403
00:14:54,360 --> 00:14:56,880
and a vendor specific device that exposes only the data
404
00:14:56,880 --> 00:14:58,880
its manufacturer chose to expose.
405
00:14:58,880 --> 00:14:59,880
None of that is unusual.
406
00:14:59,880 --> 00:15:01,200
It is a normal plant.
407
00:15:01,200 --> 00:15:03,840
OPC UA helps because it can carry both data
408
00:15:03,840 --> 00:15:06,680
and a description of what that data represents.
409
00:15:06,680 --> 00:15:09,120
A temperature value can come with a node structure,
410
00:15:09,120 --> 00:15:11,440
data types, status, and engineering unit,
411
00:15:11,440 --> 00:15:13,440
if the machine builder modeled it properly.
412
00:15:13,440 --> 00:15:15,800
That gives you more than a flat list of tags.
413
00:15:15,800 --> 00:15:16,920
Modbus is much simpler.
414
00:15:16,920 --> 00:15:18,560
It often gives you registers and addresses.
415
00:15:18,560 --> 00:15:20,840
Then somebody needs to know that register 40127
416
00:15:20,840 --> 00:15:23,360
means motor current and that the number needs scaling.
417
00:15:23,360 --> 00:15:24,480
It still works.
418
00:15:24,480 --> 00:15:26,680
But the meaning usually lives outside the protocol
419
00:15:26,680 --> 00:15:29,040
in a drawing a spreadsheet or the memory of the engineer
420
00:15:29,040 --> 00:15:30,480
who commissioned the line.
421
00:15:30,480 --> 00:15:32,760
Profinet operates close to the control world
422
00:15:32,760 --> 00:15:35,880
where predictable communication and device behavior matter.
423
00:15:35,880 --> 00:15:37,480
MQTT works differently.
424
00:15:37,480 --> 00:15:39,200
It moves messages through topics,
425
00:15:39,200 --> 00:15:41,000
which makes it useful for sharing events
426
00:15:41,000 --> 00:15:43,760
between local services and moving structured data
427
00:15:43,760 --> 00:15:45,000
toward other systems.
428
00:15:45,000 --> 00:15:46,960
These are different shop floor languages.
429
00:15:46,960 --> 00:15:48,600
The edge acts as an interpreter,
430
00:15:48,600 --> 00:15:50,880
but it mustn't invent meaning while it translates.
431
00:15:50,880 --> 00:15:53,560
A good edge design maps the source signal to a known asset,
432
00:15:53,560 --> 00:15:56,160
applies the correct unit, carries a source timestamp,
433
00:15:56,160 --> 00:15:58,440
and keeps a quality flag with the data.
434
00:15:58,440 --> 00:16:00,800
It can filter noise and reduce needless traffic,
435
00:16:00,800 --> 00:16:02,360
but it should preserve enough evidence
436
00:16:02,360 --> 00:16:04,240
to explain why a rule fired.
437
00:16:04,240 --> 00:16:06,320
Otherwise, the edge becomes another black box
438
00:16:06,320 --> 00:16:08,120
between the plant and the data team.
439
00:16:08,120 --> 00:16:10,520
Local rules belong there when they need local inputs
440
00:16:10,520 --> 00:16:12,120
and a controlled response.
441
00:16:12,120 --> 00:16:13,960
That could mean detecting a state change,
442
00:16:13,960 --> 00:16:16,360
checking whether a machine has remained idle too long,
443
00:16:16,360 --> 00:16:18,760
or producing a local alert when a sensor combination
444
00:16:18,760 --> 00:16:20,560
points to a known fault condition.
445
00:16:20,560 --> 00:16:23,040
Infrains can belong there too if you have a trained vision model
446
00:16:23,040 --> 00:16:25,480
or an anomaly model with a defined input and output,
447
00:16:25,480 --> 00:16:27,240
the edge can run at close to the process.
448
00:16:27,240 --> 00:16:30,360
The model reads local data, returns a score or class,
449
00:16:30,360 --> 00:16:32,840
and hands that result to the approved local workflow.
450
00:16:32,840 --> 00:16:35,080
It doesn't turn an industrial PC into a replacement
451
00:16:35,080 --> 00:16:36,360
for control engineering.
452
00:16:36,360 --> 00:16:37,720
That would be a very expensive way
453
00:16:37,720 --> 00:16:39,760
to rediscover why PLCs exist.
454
00:16:39,760 --> 00:16:41,520
Local storage is part of the same job.
455
00:16:41,520 --> 00:16:43,760
The edge needs enough disk, retention rules,
456
00:16:43,760 --> 00:16:46,160
and Q behavior to support its local services.
457
00:16:46,160 --> 00:16:48,400
Logs, event records, model output,
458
00:16:48,400 --> 00:16:50,560
and selected source evidence need a home
459
00:16:50,560 --> 00:16:52,640
that survives a short upstream interruption.
460
00:16:52,640 --> 00:16:54,680
A node with no storage plan isn't resilient.
461
00:16:54,680 --> 00:16:56,360
It's merely connected until it isn't.
462
00:16:56,360 --> 00:16:58,280
Once you deploy this across many lines,
463
00:16:58,280 --> 00:16:59,600
another issue appears.
464
00:16:59,600 --> 00:17:02,480
Every edge node can slowly become its own special case,
465
00:17:02,480 --> 00:17:04,960
a different script, a manual firewall rule,
466
00:17:04,960 --> 00:17:06,720
an undocumented connector version,
467
00:17:06,720 --> 00:17:09,880
and one password written somewhere nobody wants to discuss.
468
00:17:09,880 --> 00:17:10,920
Avoid that.
469
00:17:10,920 --> 00:17:13,680
Run local services as managed modules or containers
470
00:17:13,680 --> 00:17:14,880
where it makes sense.
471
00:17:14,880 --> 00:17:16,680
Keep configuration declared in versioned.
472
00:17:16,680 --> 00:17:19,040
Group nodes by role, line type or site,
473
00:17:19,040 --> 00:17:20,760
then deploy changes in control batches
474
00:17:20,760 --> 00:17:22,240
with health checks and rollback.
475
00:17:22,240 --> 00:17:24,080
Remote management should give you visibility
476
00:17:24,080 --> 00:17:25,760
into node health and software state,
477
00:17:25,760 --> 00:17:27,760
but it shouldn't bypass plant change control.
478
00:17:27,760 --> 00:17:30,400
The goal isn't to make every edge node identical.
479
00:17:30,400 --> 00:17:32,560
A vision station and a simple protocol gateway
480
00:17:32,560 --> 00:17:33,720
have different needs.
481
00:17:33,720 --> 00:17:35,360
The goal is to stop those differences
482
00:17:35,360 --> 00:17:37,640
from turning into unmanaged exceptions.
483
00:17:37,640 --> 00:17:39,760
With that local layer defined, we can look upward.
484
00:17:39,760 --> 00:17:41,240
Cloud and fabric have a different job,
485
00:17:41,240 --> 00:17:43,080
and neither one needs to become the place
486
00:17:43,080 --> 00:17:45,320
where every raw tag goes to disappear.
487
00:17:45,320 --> 00:17:47,280
Well, what cloud and fabric actually do well?
488
00:17:47,280 --> 00:17:49,040
Cloud has a different kind of strength.
489
00:17:49,040 --> 00:17:50,840
It keeps history long enough to see patterns
490
00:17:50,840 --> 00:17:53,920
that a single shift, one line or even one plant
491
00:17:53,920 --> 00:17:55,000
can't see on its own,
492
00:17:55,000 --> 00:17:57,480
picture the same pump type running across five sites.
493
00:17:57,480 --> 00:17:59,640
At one side, vibration looks normal.
494
00:17:59,640 --> 00:18:02,000
At another, the same pump needs more maintenance
495
00:18:02,000 --> 00:18:03,720
after a certain material change
496
00:18:03,720 --> 00:18:05,200
during a certain product family,
497
00:18:05,200 --> 00:18:07,680
or when ambient temperature sits within a certain range.
498
00:18:07,680 --> 00:18:10,000
No local node has enough scope to answer that well.
499
00:18:10,000 --> 00:18:12,480
That comparison work belongs above the plant.
500
00:18:12,480 --> 00:18:15,440
Cloud systems bring together data that lives in separate places
501
00:18:15,440 --> 00:18:17,200
and runs on different business clocks.
502
00:18:17,200 --> 00:18:19,200
They can compare asset behavior across sites,
503
00:18:19,200 --> 00:18:20,920
retain production history for years,
504
00:18:20,920 --> 00:18:23,200
train models against a larger set of evidence,
505
00:18:23,200 --> 00:18:25,240
and connect factory events with the systems
506
00:18:25,240 --> 00:18:27,360
that explain the business context around them.
507
00:18:27,360 --> 00:18:29,800
Microsoft fabric fits into that part of the architecture.
508
00:18:29,800 --> 00:18:32,600
It gives you a shared place for data products, analytics,
509
00:18:32,600 --> 00:18:34,240
semantic models, and reporting.
510
00:18:34,240 --> 00:18:35,920
So the people looking at production performance
511
00:18:35,920 --> 00:18:38,720
aren't each building their own extract from MES, ERP,
512
00:18:38,720 --> 00:18:40,400
and a folder of CSV files.
513
00:18:40,400 --> 00:18:42,400
The dashboard is still only the visible part.
514
00:18:42,400 --> 00:18:44,160
Under it, you need a governed data layer
515
00:18:44,160 --> 00:18:47,120
where a downtime event, a work order, a quality record,
516
00:18:47,120 --> 00:18:48,720
and an energy reading can connect
517
00:18:48,720 --> 00:18:51,760
without each team changing the meaning halfway through the process.
518
00:18:51,760 --> 00:18:53,600
Fabric can support that shared layer,
519
00:18:53,600 --> 00:18:55,480
but it won't create it for you.
520
00:18:55,480 --> 00:18:57,400
You still need to decide what an asset is,
521
00:18:57,400 --> 00:18:59,000
what a production event means,
522
00:18:59,000 --> 00:19:01,280
and which system owns each fact.
523
00:19:01,280 --> 00:19:03,400
Cloud also works well for model training.
524
00:19:03,400 --> 00:19:05,800
A local inspection system may run a fixed model
525
00:19:05,800 --> 00:19:08,800
against each image because it needs an answer during production.
526
00:19:08,800 --> 00:19:10,600
Training a new version is a different job.
527
00:19:10,600 --> 00:19:12,440
It needs many examples, controlled labels,
528
00:19:12,440 --> 00:19:14,240
comparison across product variants,
529
00:19:14,240 --> 00:19:17,080
and enough compute to test whether the new model performs better
530
00:19:17,080 --> 00:19:19,360
before anyone sends it back to the plant.
531
00:19:19,360 --> 00:19:21,320
That work benefits from central history.
532
00:19:21,320 --> 00:19:23,160
The same applies to quality drift.
533
00:19:23,160 --> 00:19:25,640
One line may show a small rise in a defect category
534
00:19:25,640 --> 00:19:27,280
that looks like random variation.
535
00:19:27,280 --> 00:19:29,440
Across several plants tied to a supplier lot
536
00:19:29,440 --> 00:19:32,040
or a recipe revision, the pattern may become obvious.
537
00:19:32,040 --> 00:19:34,600
Central analysis doesn't replace the local response.
538
00:19:34,600 --> 00:19:36,960
It gives engineering a wider field of view.
539
00:19:36,960 --> 00:19:39,160
Enterprise integration follows the same logic.
540
00:19:39,160 --> 00:19:41,160
ERP can tell you the order material,
541
00:19:41,160 --> 00:19:44,080
inventory position, cost center, and shipment commitment.
542
00:19:44,080 --> 00:19:46,120
MAs can tell you which operation ran,
543
00:19:46,120 --> 00:19:47,360
where work in progress sits,
544
00:19:47,360 --> 00:19:49,240
and what production state the line reported.
545
00:19:49,240 --> 00:19:51,040
Quality systems hold inspection results
546
00:19:51,040 --> 00:19:52,400
and disposition records.
547
00:19:52,400 --> 00:19:54,920
Maintenance systems hold work orders, spare parts,
548
00:19:54,920 --> 00:19:56,080
and asset history.
549
00:19:56,080 --> 00:19:59,040
Energy data can show what the line consumed during a run,
550
00:19:59,040 --> 00:20:01,080
not just what the site consumed over a month.
551
00:20:01,080 --> 00:20:04,080
Each system knows part of the story, none knows all of it.
552
00:20:04,080 --> 00:20:05,760
When you connect them in the cloud data layer,
553
00:20:05,760 --> 00:20:08,320
you can ask questions that don't fit inside one system.
554
00:20:08,320 --> 00:20:10,120
Did a defect rise after a tool change
555
00:20:10,120 --> 00:20:12,120
for a certain material lot on night shift,
556
00:20:12,120 --> 00:20:13,320
while energy use increased
557
00:20:13,320 --> 00:20:15,400
and a specific machine state kept cycling?
558
00:20:15,400 --> 00:20:16,640
That is not a PLC question.
559
00:20:16,640 --> 00:20:18,320
It isn't really a dashboard question either.
560
00:20:18,320 --> 00:20:19,800
It's a data relationship question.
561
00:20:19,800 --> 00:20:22,160
Supply chain context expands the view again.
562
00:20:22,160 --> 00:20:24,880
A production issue might relate to a late material delivery,
563
00:20:24,880 --> 00:20:27,640
a substitute component, a changed supplier batch,
564
00:20:27,640 --> 00:20:30,240
or an order that now needs a different routing decision.
565
00:20:30,240 --> 00:20:32,160
Those links usually sit outside the control zone
566
00:20:32,160 --> 00:20:34,680
and they often need data from more than one site.
567
00:20:34,680 --> 00:20:36,000
But there is a trap here.
568
00:20:36,000 --> 00:20:38,640
Centralization doesn't mean sending every raw signal
569
00:20:38,640 --> 00:20:41,440
into one giant storage bucket and calling it a platform.
570
00:20:41,440 --> 00:20:44,000
Event ingestion and data retention are separate decisions,
571
00:20:44,000 --> 00:20:45,720
and event path brings data in.
572
00:20:45,720 --> 00:20:48,000
It needs a defined purpose, a known producer,
573
00:20:48,000 --> 00:20:51,360
a clear schema, and a consumer that can use the event.
574
00:20:51,360 --> 00:20:54,480
Raw retention keeps original evidence for a defined period,
575
00:20:54,480 --> 00:20:57,240
often because engineers may need to inspect it later.
576
00:20:57,240 --> 00:21:00,440
Curated operational data turns those raw records into tables
577
00:21:00,440 --> 00:21:02,880
and measures people can trust for analysis and reporting.
578
00:21:02,880 --> 00:21:04,520
Those are different layers of work.
579
00:21:04,520 --> 00:21:07,960
Mix them together and people either lose the raw evidence they need
580
00:21:07,960 --> 00:21:11,000
or they hand business users a table full of machine-level noise
581
00:21:11,000 --> 00:21:12,880
and expect them to find the answer.
582
00:21:12,880 --> 00:21:15,640
A practical cloud path may retain raw machine events
583
00:21:15,640 --> 00:21:19,080
with their source details, then create curated operational records
584
00:21:19,080 --> 00:21:22,120
tied to asset, product, order, shift, and state.
585
00:21:22,120 --> 00:21:24,720
A semantic layer sits above that, so a production manager
586
00:21:24,720 --> 00:21:27,200
and a data analyst aren't calculating OEE
587
00:21:27,200 --> 00:21:29,000
or scrap from different definitions.
588
00:21:29,000 --> 00:21:31,000
Fabric can help host and govern those layers.
589
00:21:31,000 --> 00:21:33,600
It gives you a common place to build a shared view,
590
00:21:33,600 --> 00:21:35,360
connect reporting to governed measures
591
00:21:35,360 --> 00:21:37,520
and support analysis across the business.
592
00:21:37,520 --> 00:21:39,880
Still, the platform can't resolve a disagreement
593
00:21:39,880 --> 00:21:41,520
that nobody has named.
594
00:21:41,520 --> 00:21:44,720
If MES and ERP disagree on what complete means,
595
00:21:44,720 --> 00:21:47,680
the data model needs to state which condition each system records
596
00:21:47,680 --> 00:21:48,720
and how they relate.
597
00:21:48,720 --> 00:21:51,600
If two plants use the same tag name for different units,
598
00:21:51,600 --> 00:21:54,360
ingestion won't fix the problem by moving it faster.
599
00:21:54,360 --> 00:21:56,120
Data only becomes useful for decisions
600
00:21:56,120 --> 00:21:58,120
when its meaning travels with it.
601
00:21:58,120 --> 00:22:00,520
The data model decides more than location.
602
00:22:00,520 --> 00:22:02,880
Here's a scenario that happens more often than you'd think.
603
00:22:02,880 --> 00:22:05,920
You have a tag called temperature, and it looks straightforward.
604
00:22:05,920 --> 00:22:08,800
But on one line, that tag reports degrees Celsius
605
00:22:08,800 --> 00:22:09,880
from the ceiling jaw.
606
00:22:09,880 --> 00:22:11,720
On another line, its degrees Fahrenheit
607
00:22:11,720 --> 00:22:14,320
from a cabinet sensor, somewhere else.
608
00:22:14,320 --> 00:22:16,520
And somewhere else entirely, it's a calculated value
609
00:22:16,520 --> 00:22:18,680
from the MES, not a physical reading at all.
610
00:22:18,680 --> 00:22:21,120
Same name, different meaning, and that's how bad data spreads.
611
00:22:21,120 --> 00:22:23,000
So when people argue about edge versus cloud,
612
00:22:23,000 --> 00:22:25,240
they're really arguing about a data model problem.
613
00:22:25,240 --> 00:22:27,200
You can put a workload in the perfect spot,
614
00:22:27,200 --> 00:22:30,040
the edge, the cloud, wherever, and still get the wrong answer
615
00:22:30,040 --> 00:22:32,440
if your data shows up without enough context
616
00:22:32,440 --> 00:22:35,280
to explain what it actually describes.
617
00:22:35,280 --> 00:22:36,160
Think about it.
618
00:22:36,160 --> 00:22:37,880
A temperature reading needs an asset,
619
00:22:37,880 --> 00:22:40,760
a unit, a source timestamp, and a quality state.
620
00:22:40,760 --> 00:22:42,560
Usually, it also needs to know where it fits
621
00:22:42,560 --> 00:22:43,800
in the production process.
622
00:22:43,800 --> 00:22:46,680
Startup, normal running, cleaning, or fault condition.
623
00:22:46,680 --> 00:22:49,200
Without that context, a value is just a number moving
624
00:22:49,200 --> 00:22:50,360
through a pipeline.
625
00:22:50,360 --> 00:22:53,840
ISE95 gives a useful structure for organizing that context
626
00:22:53,840 --> 00:22:56,000
without turning this into a standard's lecture.
627
00:22:56,000 --> 00:22:58,080
The idea is that data should connect to the asset
628
00:22:58,080 --> 00:23:00,440
that produced it, the material being processed,
629
00:23:00,440 --> 00:23:03,360
the work order, the operation, the shift, and the current state
630
00:23:03,360 --> 00:23:05,400
that changes what you can actually ask.
631
00:23:05,400 --> 00:23:07,400
Instead of did temperature rise?
632
00:23:07,400 --> 00:23:09,920
You can ask, did the temperature at this station rise
633
00:23:09,920 --> 00:23:12,640
during operation 40 while processing this material lot
634
00:23:12,640 --> 00:23:14,640
on this work order during night shift
635
00:23:14,640 --> 00:23:16,560
while the machine was running?
636
00:23:16,560 --> 00:23:18,760
That's a question an engineer can investigate.
637
00:23:18,760 --> 00:23:20,480
Picture a packaging line with two fillers
638
00:23:20,480 --> 00:23:21,960
that have the same model name.
639
00:23:21,960 --> 00:23:23,680
One runs a low viscosity product,
640
00:23:23,680 --> 00:23:25,880
the other runs a thicker product with a different recipe.
641
00:23:25,880 --> 00:23:27,760
Their current values might look similar,
642
00:23:27,760 --> 00:23:30,640
but the allowable range, expected cycle behavior,
643
00:23:30,640 --> 00:23:32,480
and quality risk are completely different.
644
00:23:32,480 --> 00:23:35,080
If your data model only knows the tag name and timestamp,
645
00:23:35,080 --> 00:23:36,880
central analysis treats both conditions
646
00:23:36,880 --> 00:23:38,280
as if they're comparable.
647
00:23:38,280 --> 00:23:40,480
It might find a pattern that doesn't exist or miss one
648
00:23:40,480 --> 00:23:41,280
that does.
649
00:23:41,280 --> 00:23:44,200
The edge needs enough context for immediate local decisions,
650
00:23:44,200 --> 00:23:47,320
which asset a signal belongs to, what unit it uses,
651
00:23:47,320 --> 00:23:49,200
which local rule version applies,
652
00:23:49,200 --> 00:23:50,640
and whether the current machine state
653
00:23:50,640 --> 00:23:52,560
makes the signal relevant at all.
654
00:23:52,560 --> 00:23:54,160
That's not enterprise reasoning.
655
00:23:54,160 --> 00:23:57,800
It's the minimum information needed to avoid acting on nonsense.
656
00:23:57,800 --> 00:23:59,000
A local alarm shouldn't fire
657
00:23:59,000 --> 00:24:02,040
because a cleaning cycle looks unusual compared with production.
658
00:24:02,040 --> 00:24:03,920
The local layer needs to know the difference.
659
00:24:03,920 --> 00:24:06,880
Cloud and fabric need a broader version of that same context,
660
00:24:06,880 --> 00:24:10,160
connecting events across plants, systems, product lines,
661
00:24:10,160 --> 00:24:10,680
and time.
662
00:24:10,680 --> 00:24:13,200
That means linking a machine event to the work order in MS,
663
00:24:13,200 --> 00:24:16,280
the material record in ERP, the quality disposition,
664
00:24:16,280 --> 00:24:18,600
and maybe the maintenance history of that asset.
665
00:24:18,600 --> 00:24:20,520
Neither layer owns all the context alone.
666
00:24:20,520 --> 00:24:22,440
The local layer uses just enough context
667
00:24:22,440 --> 00:24:24,280
to make a safe time bound decision,
668
00:24:24,280 --> 00:24:26,360
while the cloud layer uses shared context
669
00:24:26,360 --> 00:24:27,960
to reason across the business.
670
00:24:27,960 --> 00:24:30,680
A device registry helps keep that relationship stable.
671
00:24:30,680 --> 00:24:32,640
You need a reference point where an asset's identity
672
00:24:32,640 --> 00:24:34,600
doesn't change just because a PLC address
673
00:24:34,600 --> 00:24:36,840
changed, a gateway was replaced, or someone renamed
674
00:24:36,840 --> 00:24:38,760
a tag during a line upgrade.
675
00:24:38,760 --> 00:24:40,440
The registry can link the physical asset,
676
00:24:40,440 --> 00:24:42,680
its source systems, its location, its data points,
677
00:24:42,680 --> 00:24:45,080
and the metadata that explains how to interpret them.
678
00:24:45,080 --> 00:24:47,120
That metadata includes things people often leave
679
00:24:47,120 --> 00:24:49,120
in a commissioning file and then lose.
680
00:24:49,120 --> 00:24:51,600
Units, scale factors, asset hierarchy,
681
00:24:51,600 --> 00:24:54,920
calibration state, data owner, allowed value ranges,
682
00:24:54,920 --> 00:24:57,880
and the connection between a sensor and the machine
683
00:24:57,880 --> 00:24:59,880
function it observes.
684
00:24:59,880 --> 00:25:02,000
As your device registry follows this general pattern
685
00:25:02,000 --> 00:25:04,720
by treating assets and devices as managed resources,
686
00:25:04,720 --> 00:25:07,040
whether you use that service or another registry,
687
00:25:07,040 --> 00:25:09,200
the architectural point is the same.
688
00:25:09,200 --> 00:25:11,320
Data needs a stable identity before it
689
00:25:11,320 --> 00:25:14,560
can move across OT and IT without losing its meaning.
690
00:25:14,560 --> 00:25:16,520
Now, this is also where digital twin and knowledge graph
691
00:25:16,520 --> 00:25:17,920
work become practical.
692
00:25:17,920 --> 00:25:21,280
A digital twin isn't a 3D model with some live colors on it.
693
00:25:21,280 --> 00:25:23,040
It's a model of an asset or process
694
00:25:23,040 --> 00:25:24,880
with current state and relationships.
695
00:25:24,880 --> 00:25:26,400
A knowledge graph takes that further
696
00:25:26,400 --> 00:25:30,040
by representing the links between assets, materials, operations,
697
00:25:30,040 --> 00:25:31,640
people, documents, and events.
698
00:25:31,640 --> 00:25:33,400
The useful part is the relationship.
699
00:25:33,400 --> 00:25:35,480
A defect isn't just a failed inspection result.
700
00:25:35,480 --> 00:25:38,200
It can connect to a specific station, a recipe revision,
701
00:25:38,200 --> 00:25:40,960
a material lot, a tool setting, and a work order.
702
00:25:40,960 --> 00:25:43,280
A maintenance alert can connect to the motor,
703
00:25:43,280 --> 00:25:45,760
the line it serves, its prior work orders,
704
00:25:45,760 --> 00:25:48,160
and the product currently running through that line.
705
00:25:48,160 --> 00:25:50,720
That gives both people and systems a clear path
706
00:25:50,720 --> 00:25:52,000
to trace what happened.
707
00:25:52,000 --> 00:25:54,360
Without it, each system holds part of the story,
708
00:25:54,360 --> 00:25:56,440
and everyone ends up spending time joining records
709
00:25:56,440 --> 00:25:57,320
after the fact.
710
00:25:57,320 --> 00:25:59,360
But a weak data model gets even more expensive
711
00:25:59,360 --> 00:26:00,800
as data volume rises.
712
00:26:00,800 --> 00:26:02,920
One vague tag might not look like a problem,
713
00:26:02,920 --> 00:26:05,160
but thousands of vague tags streaming all day
714
00:26:05,160 --> 00:26:07,680
across dozens of lines create a massive pile of data
715
00:26:07,680 --> 00:26:11,800
that costs money to move, store, query, and later explain.
716
00:26:11,800 --> 00:26:13,880
And by the time you realize it, fixing the meaning
717
00:26:13,880 --> 00:26:16,400
means revisiting history you already collected.
718
00:26:16,400 --> 00:26:18,240
So let's follow one sensor stream from the machine
719
00:26:18,240 --> 00:26:19,640
to the cloud, because that's where
720
00:26:19,640 --> 00:26:22,000
a weak design becomes visible very quickly.
721
00:26:22,000 --> 00:26:24,280
Raw telemetry is not a cloud strategy.
722
00:26:24,280 --> 00:26:26,280
Once a sensor stream leaves the machine,
723
00:26:26,280 --> 00:26:28,280
the obvious move is to send all of it upward.
724
00:26:28,280 --> 00:26:30,160
That works for a demo, but it rarely works
725
00:26:30,160 --> 00:26:31,560
as a factory data design.
726
00:26:31,560 --> 00:26:33,120
It takes vibration data from a motor.
727
00:26:33,120 --> 00:26:34,960
A conditioned sensor can sample at a rate
728
00:26:34,960 --> 00:26:36,840
that creates a steady stream of readings
729
00:26:36,840 --> 00:26:39,560
and raw waveform capture producers even more.
730
00:26:39,560 --> 00:26:42,520
Now add high-resolution images from an inspection station,
731
00:26:42,520 --> 00:26:45,080
cycle events from every machine, and energy readings
732
00:26:45,080 --> 00:26:47,640
from drives, compressors, and heaters.
733
00:26:47,640 --> 00:26:49,120
Pretty soon the question isn't whether you
734
00:26:49,120 --> 00:26:51,400
can send it all to the cloud you can.
735
00:26:51,400 --> 00:26:53,360
The question is, what anyone will actually do with it
736
00:26:53,360 --> 00:26:54,920
once it arrives?
737
00:26:54,920 --> 00:26:56,880
Most raw data has a short useful life.
738
00:26:56,880 --> 00:27:00,000
A normal vibration signal might show nothing new for hours.
739
00:27:00,000 --> 00:27:01,840
A camera may inspect thousands of good parts
740
00:27:01,840 --> 00:27:03,320
before one defect appears.
741
00:27:03,320 --> 00:27:05,280
A machine can emit hundreds of state changes
742
00:27:05,280 --> 00:27:06,960
that only matter once they're tied together
743
00:27:06,960 --> 00:27:10,000
into a single downtime event, sending all of that upstream
744
00:27:10,000 --> 00:27:12,880
at full rate turns a data pipeline into a delivery truck
745
00:27:12,880 --> 00:27:14,120
full of packing material.
746
00:27:14,120 --> 00:27:16,120
The edge should reduce data close to the source,
747
00:27:16,120 --> 00:27:17,680
but reduction needs a purpose.
748
00:27:17,680 --> 00:27:20,080
For vibration, the local service can calculate
749
00:27:20,080 --> 00:27:22,480
a health indicator from the incoming signal,
750
00:27:22,480 --> 00:27:24,840
tracking overall level, change over time,
751
00:27:24,840 --> 00:27:27,160
or the presence of a known frequency pattern.
752
00:27:27,160 --> 00:27:29,480
The cloud doesn't need every sample just to know the condition
753
00:27:29,480 --> 00:27:31,560
stayed within its normal range for the last hour.
754
00:27:31,560 --> 00:27:34,240
For a vision system, the edge might keep the pass,
755
00:27:34,240 --> 00:27:37,600
fail result, defect class, confidence score, camera ID,
756
00:27:37,600 --> 00:27:38,680
and product ID.
757
00:27:38,680 --> 00:27:40,720
It can retain the image for failed parts
758
00:27:40,720 --> 00:27:43,200
plus a limited set of good ones for comparison
759
00:27:43,200 --> 00:27:44,320
and model checking.
760
00:27:44,320 --> 00:27:45,920
That gives quality engineers evidence
761
00:27:45,920 --> 00:27:48,920
without treating every good image as permanent corporate history.
762
00:27:48,920 --> 00:27:50,880
Cycle data follows the same pattern.
763
00:27:50,880 --> 00:27:52,880
Instead of pushing every low-level transition
764
00:27:52,880 --> 00:27:55,040
into a reporting model, the local layer
765
00:27:55,040 --> 00:27:56,560
produces meaningful events.
766
00:27:56,560 --> 00:27:58,960
Cycle started, cycle completed, station blocked,
767
00:27:58,960 --> 00:28:01,840
station starved, reject triggered, machine stopped
768
00:28:01,840 --> 00:28:03,440
with duration, reason where known,
769
00:28:03,440 --> 00:28:05,120
and the current production context.
770
00:28:05,120 --> 00:28:06,920
That's data people can actually use.
771
00:28:06,920 --> 00:28:08,920
Energy data needs the same judgment.
772
00:28:08,920 --> 00:28:10,760
A local service collects frequent readings
773
00:28:10,760 --> 00:28:14,600
and calculates interval consumption, peak demand, idle load,
774
00:28:14,600 --> 00:28:17,120
or a change that crosses a defined limit.
775
00:28:17,120 --> 00:28:19,480
The central platform usually needs those measures,
776
00:28:19,480 --> 00:28:22,360
not every single sample from every device for all time.
777
00:28:22,360 --> 00:28:24,520
This doesn't mean raw data has no place.
778
00:28:24,520 --> 00:28:26,120
Sometimes the raw signal is the evidence.
779
00:28:26,120 --> 00:28:27,600
If a bearing condition changes,
780
00:28:27,600 --> 00:28:29,400
you might need a window of waveform data
781
00:28:29,400 --> 00:28:31,200
before and after the event.
782
00:28:31,200 --> 00:28:33,280
If a camera rejects a part, you need the image
783
00:28:33,280 --> 00:28:34,680
and the inspection result.
784
00:28:34,680 --> 00:28:36,800
If a process excursion occurs, engineering
785
00:28:36,800 --> 00:28:38,840
needs the original readings to understand
786
00:28:38,840 --> 00:28:40,880
whether the calculation itself hit the problem.
787
00:28:40,880 --> 00:28:42,760
So retain evidence deliberately,
788
00:28:42,760 --> 00:28:45,680
keep a rolling local buffer where the use case requires it.
789
00:28:45,680 --> 00:28:46,840
When the condition triggers,
790
00:28:46,840 --> 00:28:49,200
preserve the bounded data window around it,
791
00:28:49,200 --> 00:28:51,480
along with how the local result was calculated,
792
00:28:51,480 --> 00:28:53,400
which rule or model version produced it,
793
00:28:53,400 --> 00:28:55,240
and which source signals fed it.
794
00:28:55,240 --> 00:28:57,000
That turns a local health score into something
795
00:28:57,000 --> 00:28:59,000
an engineer can inspect rather than a number
796
00:28:59,000 --> 00:29:00,920
they're expected to trust on faith.
797
00:29:00,920 --> 00:29:03,240
Then send the right forms of data upstream.
798
00:29:03,240 --> 00:29:06,720
Events, calculated features, summaries, alerts,
799
00:29:06,720 --> 00:29:09,040
and selected samples linked to a specific reason
800
00:29:09,040 --> 00:29:09,880
for retention.
801
00:29:09,880 --> 00:29:11,480
That reduces network traffic,
802
00:29:11,480 --> 00:29:13,880
but bandwidth is only one part of the cost.
803
00:29:13,880 --> 00:29:16,120
Every raw message also lands somewhere.
804
00:29:16,120 --> 00:29:18,880
It consumes storage, goes through ingestion services,
805
00:29:18,880 --> 00:29:21,360
shows up in backups and later costs time and compute
806
00:29:21,360 --> 00:29:22,640
when someone queries it.
807
00:29:22,640 --> 00:29:24,040
And if the data crosses boundaries
808
00:29:24,040 --> 00:29:25,760
or needs to leave the cloud again,
809
00:29:25,760 --> 00:29:27,000
transfer charges add up to,
810
00:29:27,000 --> 00:29:28,880
I'm not going to throw out a single number for that.
811
00:29:28,880 --> 00:29:31,640
It depends on sampling rate, image size,
812
00:29:31,640 --> 00:29:33,840
retention rules, query patterns,
813
00:29:33,840 --> 00:29:36,200
and how many sites contribute data.
814
00:29:36,200 --> 00:29:37,440
But the direction is obvious.
815
00:29:37,440 --> 00:29:39,080
A design that collects everything forever
816
00:29:39,080 --> 00:29:41,200
ends up paying for every unnecessary bite
817
00:29:41,200 --> 00:29:42,080
more than once.
818
00:29:42,080 --> 00:29:43,760
There's a danger on the other side too.
819
00:29:43,760 --> 00:29:45,440
Teams sometimes filter too aggressively,
820
00:29:45,440 --> 00:29:47,000
sending only a single alarm bit
821
00:29:47,000 --> 00:29:49,160
and then discover they can't investigate the alarm.
822
00:29:49,160 --> 00:29:50,280
The event says a fault occurred,
823
00:29:50,280 --> 00:29:52,040
but nobody can trace the source signal,
824
00:29:52,040 --> 00:29:54,320
the local calculation, the product being processed,
825
00:29:54,320 --> 00:29:56,760
or the machine condition around that moment.
826
00:29:56,760 --> 00:29:58,160
That doesn't reduce complexity.
827
00:29:58,160 --> 00:30:01,000
It moves the complexity into the next root cause meeting.
828
00:30:01,000 --> 00:30:02,760
Each filter needs a traceable rule.
829
00:30:02,760 --> 00:30:05,120
Each aggregate needs a clear window and method.
830
00:30:05,120 --> 00:30:06,800
Each event needs enough source detail
831
00:30:06,800 --> 00:30:08,920
to point back to the evidence that produced it.
832
00:30:08,920 --> 00:30:10,720
If you can't explain how a summary came
833
00:30:10,720 --> 00:30:13,520
into existence, it's not suitable for engineering decisions.
834
00:30:13,520 --> 00:30:15,600
Raw telemetry becomes useful when you decide
835
00:30:15,600 --> 00:30:18,560
what action, record, or question it supports.
836
00:30:18,560 --> 00:30:21,120
And that gives us a practical way to draw the boundary.
837
00:30:21,120 --> 00:30:23,720
Before placing any workload, ask what happens
838
00:30:23,720 --> 00:30:26,960
if the answer arrives late, disappears during an outage,
839
00:30:26,960 --> 00:30:30,280
or loses the context that made it meaningful.
840
00:30:30,280 --> 00:30:32,120
The six questions for every workload.
841
00:30:32,120 --> 00:30:33,880
So now you've got enough to ask a better question
842
00:30:33,880 --> 00:30:35,520
than edge or cloud.
843
00:30:35,520 --> 00:30:36,680
Here's the real challenge.
844
00:30:36,680 --> 00:30:38,560
Take each workload one at a time
845
00:30:38,560 --> 00:30:40,520
and run it through six questions.
846
00:30:40,520 --> 00:30:42,800
The answers will usually point you to a clear placement,
847
00:30:42,800 --> 00:30:43,640
where they don't.
848
00:30:43,640 --> 00:30:45,640
That's where the real design work starts.
849
00:30:45,640 --> 00:30:48,680
Start with the response deadline, not the preferred response
850
00:30:48,680 --> 00:30:50,360
time, the actual deadline.
851
00:30:50,360 --> 00:30:52,640
Ask what happens if the answer arrives late.
852
00:30:52,640 --> 00:30:54,680
Does a part move beyond the rejection point
853
00:30:54,680 --> 00:30:57,120
doesn't operate or lose the chance to prevent damage
854
00:30:57,120 --> 00:30:59,480
or does the decision just show up later in a report
855
00:30:59,480 --> 00:31:01,240
with no physical consequence?
856
00:31:01,240 --> 00:31:03,520
Write that consequence right next to the time.
857
00:31:03,520 --> 00:31:05,640
Needs to be fast, doesn't tell anyone much.
858
00:31:05,640 --> 00:31:07,520
But action must reach the local process
859
00:31:07,520 --> 00:31:09,680
before the next station accepts the part,
860
00:31:09,680 --> 00:31:12,160
gives your team a clear boundary to design around.
861
00:31:12,160 --> 00:31:13,000
Next question.
862
00:31:13,000 --> 00:31:15,560
Does the work need to continue through a network outage?
863
00:31:15,560 --> 00:31:16,960
This is separate from speed.
864
00:31:16,960 --> 00:31:18,960
A workload might handle a delay of several minutes
865
00:31:18,960 --> 00:31:21,240
under normal conditions, but still need local operation
866
00:31:21,240 --> 00:31:22,720
because the plant can't lose that function
867
00:31:22,720 --> 00:31:24,080
when the one link goes down.
868
00:31:24,080 --> 00:31:26,800
Think about local event capture, operator information,
869
00:31:26,800 --> 00:31:28,560
or a line level condition rule.
870
00:31:28,560 --> 00:31:30,640
If the site needs it while disconnected,
871
00:31:30,640 --> 00:31:33,680
its working path needs local compute, local data,
872
00:31:33,680 --> 00:31:35,240
and a defined fallback state.
873
00:31:35,240 --> 00:31:37,760
And be precise about what continue actually means.
874
00:31:37,760 --> 00:31:38,640
Does it run fully?
875
00:31:38,640 --> 00:31:40,120
Does it run with reduced data?
876
00:31:40,120 --> 00:31:41,720
Does it queue records for later?
877
00:31:41,720 --> 00:31:43,840
Or does it stop and force and operate it to take over?
878
00:31:43,840 --> 00:31:46,040
Any answer is fine as long as it's intentional.
879
00:31:46,040 --> 00:31:47,920
The dangerous answer is finding out what happens
880
00:31:47,920 --> 00:31:49,480
when the outage actually hits.
881
00:31:49,480 --> 00:31:50,600
Next up is data gravity.
882
00:31:50,600 --> 00:31:52,640
How much data does this workload create?
883
00:31:52,640 --> 00:31:55,080
And in what form does that data become useful?
884
00:31:55,080 --> 00:31:57,080
A small status event can travel almost anywhere
885
00:31:57,080 --> 00:31:58,080
without much worry.
886
00:31:58,080 --> 00:32:00,480
But a stream of images, vibration samples,
887
00:32:00,480 --> 00:32:03,400
or high rate process values brings a different set of constraints
888
00:32:03,400 --> 00:32:06,000
because the raw source data might be huge
889
00:32:06,000 --> 00:32:08,840
while the decision only needs a small calculated result.
890
00:32:08,840 --> 00:32:10,760
Don't just ask, can we transmit it?
891
00:32:10,760 --> 00:32:12,720
Ask what actually has to move?
892
00:32:12,720 --> 00:32:15,760
Maybe the local process needs the raw signal for a short time.
893
00:32:15,760 --> 00:32:17,920
While central analysis just needs a health score
894
00:32:17,920 --> 00:32:20,320
and records tied to unusual conditions.
895
00:32:20,320 --> 00:32:22,320
Maybe the cloud needs selected evidence later,
896
00:32:22,320 --> 00:32:24,040
but not continuous full-rate data.
897
00:32:24,040 --> 00:32:25,960
The format matters just as much as the volume.
898
00:32:25,960 --> 00:32:29,360
Raw data, calculated features, events, and business records
899
00:32:29,360 --> 00:32:31,320
each belong in a different part of that path.
900
00:32:31,320 --> 00:32:32,240
Scope comes next.
901
00:32:32,240 --> 00:32:35,000
Is this decision about one sensor, one asset, a line,
902
00:32:35,000 --> 00:32:36,560
a plant or a group of plants?
903
00:32:36,560 --> 00:32:38,400
Local scope usually favors local placement
904
00:32:38,400 --> 00:32:41,000
because the inputs and action both live close together.
905
00:32:41,000 --> 00:32:43,080
Broaders scope pushes the work upward
906
00:32:43,080 --> 00:32:44,360
because you're comparing sources
907
00:32:44,360 --> 00:32:46,600
that don't share the same local environment.
908
00:32:46,600 --> 00:32:48,920
A machine can assess its own current condition.
909
00:32:48,920 --> 00:32:50,960
A plant can compare its different lines.
910
00:32:50,960 --> 00:32:53,000
A central data layer can compare a process
911
00:32:53,000 --> 00:32:55,840
across sites, product families, and time periods.
912
00:32:55,840 --> 00:32:57,720
If you try to force a cross-site question
913
00:32:57,720 --> 00:33:00,320
onto every edge node, you end up with repeated logic
914
00:33:00,320 --> 00:33:01,560
and partial answers.
915
00:33:01,560 --> 00:33:02,960
And running a machine-level action
916
00:33:02,960 --> 00:33:06,320
through a central system just adds distance where you don't need it.
917
00:33:06,320 --> 00:33:07,840
The fifth question is context.
918
00:33:07,840 --> 00:33:09,560
What information does this decision need
919
00:33:09,560 --> 00:33:10,920
before it can be trusted?
920
00:33:10,920 --> 00:33:12,960
Some decisions depend on a local signal
921
00:33:12,960 --> 00:33:14,760
and the current equipment state.
922
00:33:14,760 --> 00:33:17,920
Others need the work order, product recipe, material lot,
923
00:33:17,920 --> 00:33:20,080
maintenance status, or customer requirement
924
00:33:20,080 --> 00:33:22,720
that lives in MES and ERP that doesn't automatically
925
00:33:22,720 --> 00:33:25,320
mean every decision that touches enterprise context
926
00:33:25,320 --> 00:33:26,600
belongs in the cloud.
927
00:33:26,600 --> 00:33:29,920
You might need to send a small, approved set of current context
928
00:33:29,920 --> 00:33:32,000
down to the plant before production starts.
929
00:33:32,000 --> 00:33:34,480
Then the local service uses that context during the run
930
00:33:34,480 --> 00:33:37,000
without calling ERP every time a sensor changes.
931
00:33:37,000 --> 00:33:38,840
This is where you separate live reference data
932
00:33:38,840 --> 00:33:40,200
from live dependency.
933
00:33:40,200 --> 00:33:42,600
If the edge needs the current recipe or order identity,
934
00:33:42,600 --> 00:33:44,640
synchronize it as controlled reference data.
935
00:33:44,640 --> 00:33:46,840
If the edge has to query a distant business system
936
00:33:46,840 --> 00:33:50,280
for every local decision, you've created a fragile command path.
937
00:33:50,280 --> 00:33:52,200
That difference looks small on a slide.
938
00:33:52,200 --> 00:33:54,280
During a production issue, it's not small at all.
939
00:33:54,280 --> 00:33:56,240
The final question is risk and governance.
940
00:33:56,240 --> 00:33:57,240
Who can approve the rule?
941
00:33:57,240 --> 00:33:58,760
Who owns the source data?
942
00:33:58,760 --> 00:34:00,640
Who investigates when a decision looks wrong?
943
00:34:00,640 --> 00:34:01,880
What needs an audit trail?
944
00:34:01,880 --> 00:34:04,240
What happens if the rule changes the model changes
945
00:34:04,240 --> 00:34:06,760
or the identity used by the edge node expires?
946
00:34:06,760 --> 00:34:09,720
Safety requires validated local control paths.
947
00:34:09,720 --> 00:34:11,840
Security requires separated networks,
948
00:34:11,840 --> 00:34:13,920
known identities, and limited permissions.
949
00:34:13,920 --> 00:34:15,280
Privacy or intellectual property
950
00:34:15,280 --> 00:34:17,280
might restrict what leaves the site.
951
00:34:17,280 --> 00:34:19,240
Audit needs a record of which version of a rule
952
00:34:19,240 --> 00:34:22,120
acted against what input and when.
953
00:34:22,120 --> 00:34:23,760
And ownership matters just as much.
954
00:34:23,760 --> 00:34:26,560
If OT owns safe machine operation, a cloud team
955
00:34:26,560 --> 00:34:29,520
can't quietly publish a change that affects a local action
956
00:34:29,520 --> 00:34:31,400
without an agreed approval path.
957
00:34:31,400 --> 00:34:33,520
If the data team owns the semantic definition
958
00:34:33,520 --> 00:34:35,480
of a production event, a gateway script
959
00:34:35,480 --> 00:34:37,520
can't change its payload just because it seemed
960
00:34:37,520 --> 00:34:39,240
convenient on a Friday afternoon.
961
00:34:39,240 --> 00:34:41,440
That's how integration turns into archaeology.
962
00:34:41,440 --> 00:34:43,120
So use the six questions together--
963
00:34:43,120 --> 00:34:47,440
deadline, outage behavior, data gravity, scope, context,
964
00:34:47,440 --> 00:34:48,000
and risk.
965
00:34:48,000 --> 00:34:49,800
They don't give you a product recommendation.
966
00:34:49,800 --> 00:34:52,240
They give you an architecture decision you can explain.
967
00:34:52,240 --> 00:34:54,080
Once you apply that test, honestly,
968
00:34:54,080 --> 00:34:57,280
some workloads stop being edge versus cloud debates entirely.
969
00:34:57,280 --> 00:34:59,240
They clearly belong close to the process.
970
00:34:59,240 --> 00:35:01,200
Own decisions that must stay at the edge.
971
00:35:01,200 --> 00:35:03,560
Once you put a workload through those six questions,
972
00:35:03,560 --> 00:35:05,320
some answers come back immediately.
973
00:35:05,320 --> 00:35:08,440
If a decision protects a person, prevents equipment damage,
974
00:35:08,440 --> 00:35:10,560
or acts on a part still moving through the line,
975
00:35:10,560 --> 00:35:12,360
it belongs close to the process.
976
00:35:12,360 --> 00:35:13,800
But let's keep the boundary clear.
977
00:35:13,800 --> 00:35:16,480
Safety and interlocks belong first in the controller domain
978
00:35:16,480 --> 00:35:19,240
using the safety system and validated circuits designed
979
00:35:19,240 --> 00:35:20,040
for that job.
980
00:35:20,040 --> 00:35:22,960
A cloud service has no place in an emergency stop path.
981
00:35:22,960 --> 00:35:25,280
Neither does a general edge server running a container
982
00:35:25,280 --> 00:35:26,760
that happens to be healthy today.
983
00:35:26,760 --> 00:35:29,000
The edge can observe safety-related state.
984
00:35:29,000 --> 00:35:31,520
It can record a guard door event, show the sequence of faults
985
00:35:31,520 --> 00:35:33,280
around it, and notify the right people.
986
00:35:33,280 --> 00:35:36,480
It can even support analysis that helps you find repeat causes.
987
00:35:36,480 --> 00:35:38,360
But it must not become an untested shortcut
988
00:35:38,360 --> 00:35:40,240
around deterministic safety logic.
989
00:35:40,240 --> 00:35:41,960
That distinction often gets blurred when people
990
00:35:41,960 --> 00:35:43,880
talk about real-time edge control.
991
00:35:43,880 --> 00:35:45,200
Real-time compared to what?
992
00:35:45,200 --> 00:35:47,640
A local industrial PC may respond quickly enough
993
00:35:47,640 --> 00:35:49,440
for an alarm or a vision result,
994
00:35:49,440 --> 00:35:51,480
but that doesn't make it a safety controller.
995
00:35:51,480 --> 00:35:53,280
Physical risk needs a physical control path
996
00:35:53,280 --> 00:35:55,280
with known behavior under fault conditions.
997
00:35:55,280 --> 00:35:57,520
Machine protection sits close to that boundary.
998
00:35:57,520 --> 00:35:58,600
Take a bearing alarm.
999
00:35:58,600 --> 00:36:01,760
A condition monitoring service might detect a vibration pattern
1000
00:36:01,760 --> 00:36:03,480
that suggests a developing problem,
1001
00:36:03,480 --> 00:36:05,960
then prompt an operator or create a maintenance event.
1002
00:36:05,960 --> 00:36:06,760
That's useful.
1003
00:36:06,760 --> 00:36:08,440
But if the machine needs immediate protection
1004
00:36:08,440 --> 00:36:10,400
from an extreme condition, the protective action
1005
00:36:10,400 --> 00:36:12,360
has to follow a local, engineered path
1006
00:36:12,360 --> 00:36:15,120
that doesn't depend on an analytic service, a broker,
1007
00:36:15,120 --> 00:36:16,640
or a one connection.
1008
00:36:16,640 --> 00:36:18,480
The same goes for temperature and pressure.
1009
00:36:18,480 --> 00:36:20,840
A thermal limit on a heater, a pressure excursion
1010
00:36:20,840 --> 00:36:23,800
in a process vessel, or a sudden current rise in a drive
1011
00:36:23,800 --> 00:36:26,560
can go from normal to damaging very quickly.
1012
00:36:26,560 --> 00:36:29,000
The protection path needs to live where the sensor, logic,
1013
00:36:29,000 --> 00:36:31,320
and actuator can still work together
1014
00:36:31,320 --> 00:36:33,720
when every higher level system is unavailable.
1015
00:36:33,720 --> 00:36:36,120
The edge can add intelligence around that path.
1016
00:36:36,120 --> 00:36:38,440
It can collect the measurements, identify the event,
1017
00:36:38,440 --> 00:36:41,360
preserve local records, and send a structured incident upward
1018
00:36:41,360 --> 00:36:43,000
when the network comes back.
1019
00:36:43,000 --> 00:36:45,360
It can help explain whether the thermal limit appeared
1020
00:36:45,360 --> 00:36:47,840
after a recipe change, an operator action,
1021
00:36:47,840 --> 00:36:49,640
or a change in ambient conditions,
1022
00:36:49,640 --> 00:36:51,360
but it should never become the only thing
1023
00:36:51,360 --> 00:36:53,120
standing between the process and damage.
1024
00:36:53,120 --> 00:36:55,000
That's a much healthier use of the edge.
1025
00:36:55,000 --> 00:36:57,760
It supports control without pretending to replace it.
1026
00:36:57,760 --> 00:37:00,120
Close loop quality gives you another clear local decision.
1027
00:37:00,120 --> 00:37:03,040
Imagine an inspection station where a part passes a camera,
1028
00:37:03,040 --> 00:37:04,960
moves through a short section of conveyor,
1029
00:37:04,960 --> 00:37:06,680
and reaches a reject mechanism.
1030
00:37:06,680 --> 00:37:09,080
The inspection result has to travel from the camera,
1031
00:37:09,080 --> 00:37:11,560
or local inference process, to the reject logic
1032
00:37:11,560 --> 00:37:13,400
before the part reaches that mechanism.
1033
00:37:13,400 --> 00:37:16,120
If the signal comes late, the bad part moves on with the good ones.
1034
00:37:16,120 --> 00:37:19,120
There is no useful excuse for that decision to wait on fabric.
1035
00:37:19,120 --> 00:37:20,760
The local path needs the camera input,
1036
00:37:20,760 --> 00:37:23,640
the inspection result, the part position, or encoder reference,
1037
00:37:23,640 --> 00:37:24,920
and the reject action.
1038
00:37:24,920 --> 00:37:27,920
It might involve a PLC, a dedicated vision controller,
1039
00:37:27,920 --> 00:37:30,640
or an edge process depending on how you design the system.
1040
00:37:30,640 --> 00:37:32,200
What matters is that the entire decision
1041
00:37:32,200 --> 00:37:35,040
stays inside a time budget the line can meet every cycle.
1042
00:37:35,040 --> 00:37:36,880
A cloud service can receive the result later.
1043
00:37:36,880 --> 00:37:38,920
It can store defect evidence, compare defect types,
1044
00:37:38,920 --> 00:37:40,360
and support engineering review.
1045
00:37:40,360 --> 00:37:43,320
But the local system needs to reject the physical part,
1046
00:37:43,320 --> 00:37:45,320
while it's still possible to reject it.
1047
00:37:45,320 --> 00:37:47,000
Once the part has passed that point,
1048
00:37:47,000 --> 00:37:49,040
the most accurate cloud result in the world
1049
00:37:49,040 --> 00:37:51,760
is just a very detailed explanation of why you missed it.
1050
00:37:51,760 --> 00:37:54,120
Local operator prompts also belong here
1051
00:37:54,120 --> 00:37:56,000
when delay creates waste or damage.
1052
00:37:56,000 --> 00:37:58,400
Think about a setup condition that starts drifting.
1053
00:37:58,400 --> 00:38:00,520
The system may not need to stop the machine immediately,
1054
00:38:00,520 --> 00:38:02,760
but the operator needs a prompt while there's still time
1055
00:38:02,760 --> 00:38:04,920
to adjust the setting, inspect the material,
1056
00:38:04,920 --> 00:38:08,120
or slow the process before the issue creates a stack of scrap.
1057
00:38:08,120 --> 00:38:10,120
The prompt should appear where the work happens,
1058
00:38:10,120 --> 00:38:12,600
with enough context to support a decision.
1059
00:38:12,600 --> 00:38:14,800
Not an alert that says anomaly detected
1060
00:38:14,800 --> 00:38:17,120
and sends someone hunting through five screens.
1061
00:38:17,120 --> 00:38:19,800
Show the station, the current condition, the relevant limit,
1062
00:38:19,800 --> 00:38:21,720
and the action the operator is expected to take.
1063
00:38:21,720 --> 00:38:23,960
Local doesn't mean automatic in every case.
1064
00:38:23,960 --> 00:38:26,520
Sometimes the right response is an operator confirmation
1065
00:38:26,520 --> 00:38:28,840
because a false stop costs more than a short review.
1066
00:38:28,840 --> 00:38:31,200
Sometimes the right response is a controlled local action
1067
00:38:31,200 --> 00:38:33,560
because the risk of waiting is too high.
1068
00:38:33,560 --> 00:38:35,400
You decide that through process knowledge,
1069
00:38:35,400 --> 00:38:38,000
not because an AI model returned a confident score.
1070
00:38:38,000 --> 00:38:39,400
That brings us to edge AI.
1071
00:38:39,400 --> 00:38:42,280
Edge AI fits defined time bound detection work.
1072
00:38:42,280 --> 00:38:43,960
A vision model can classify an image,
1073
00:38:43,960 --> 00:38:46,480
and an anomaly model can score a local sensor pattern.
1074
00:38:46,480 --> 00:38:48,400
A local classifier can identify
1075
00:38:48,400 --> 00:38:51,040
whether a machine sound matches a known state.
1076
00:38:51,040 --> 00:38:53,040
These are bounded tasks with known inputs,
1077
00:38:53,040 --> 00:38:55,040
known outputs, and a clear action path.
1078
00:38:55,040 --> 00:38:56,360
Keep the scope narrow.
1079
00:38:56,360 --> 00:38:58,320
The model should not receive vague authority
1080
00:38:58,320 --> 00:38:59,800
to optimize the line.
1081
00:38:59,800 --> 00:39:01,320
It should detect a specific condition,
1082
00:39:01,320 --> 00:39:04,000
return a result with confidence and version information,
1083
00:39:04,000 --> 00:39:06,880
and pass that result into an approved local workflow.
1084
00:39:06,880 --> 00:39:08,240
If the model is unavailable,
1085
00:39:08,240 --> 00:39:09,920
the system needs a known fallback.
1086
00:39:09,920 --> 00:39:12,280
Pause inspection, root to manual review,
1087
00:39:12,280 --> 00:39:14,160
use a fixed rule, or place the machine
1088
00:39:14,160 --> 00:39:15,680
in a safe operating state.
1089
00:39:15,680 --> 00:39:18,760
That fallback is part of the design, not an afterthought.
1090
00:39:18,760 --> 00:39:20,480
A general edge platform can run rules,
1091
00:39:20,480 --> 00:39:22,920
local analytics, and inference close to the process.
1092
00:39:22,920 --> 00:39:25,600
It can reduce the distance between data and action.
1093
00:39:25,600 --> 00:39:28,920
Yet deterministic PLC logic still owns the machine sequence,
1094
00:39:28,920 --> 00:39:30,640
interlocks, and direct equipment control
1095
00:39:30,640 --> 00:39:33,280
where timing and predictable behavior demanded.
1096
00:39:33,280 --> 00:39:34,960
Keep those responsibilities separate,
1097
00:39:34,960 --> 00:39:37,840
and the local architecture stays understandable under pressure.
1098
00:39:37,840 --> 00:39:39,600
Some decisions can move upward after that.
1099
00:39:39,600 --> 00:39:41,960
They just need a time budget that proves they can.
1100
00:39:41,960 --> 00:39:44,200
Decisions that usually belong in the cloud.
1101
00:39:44,200 --> 00:39:45,520
Now let's move up a level.
1102
00:39:45,520 --> 00:39:47,560
From decisions that have to protect the process
1103
00:39:47,560 --> 00:39:49,920
to decisions that need a wider field of view,
1104
00:39:49,920 --> 00:39:52,000
a single motor can report its own condition.
1105
00:39:52,000 --> 00:39:53,640
But it can't tell you whether that motor type
1106
00:39:53,640 --> 00:39:55,880
fails more often at one side than another
1107
00:39:55,880 --> 00:39:57,560
after a certain service procedure,
1108
00:39:57,560 --> 00:40:00,320
or when a specific product mix runs through the plant.
1109
00:40:00,320 --> 00:40:02,120
That question needs history from many assets
1110
00:40:02,120 --> 00:40:03,480
and often many plants.
1111
00:40:03,480 --> 00:40:05,920
Fleet-wide asset analysis belongs in the cloud
1112
00:40:05,920 --> 00:40:08,440
because the patent exists across the fleet.
1113
00:40:08,440 --> 00:40:10,040
You might find that similar drives show
1114
00:40:10,040 --> 00:40:12,040
the same current signature before failure,
1115
00:40:12,040 --> 00:40:14,640
but only when running a certain load profile.
1116
00:40:14,640 --> 00:40:16,880
Or a pump may appear healthy in isolation,
1117
00:40:16,880 --> 00:40:19,200
but comparison shows it consumes more energy
1118
00:40:19,200 --> 00:40:21,080
and gets more callouts than peer assets.
1119
00:40:21,080 --> 00:40:22,320
That's not a local alarm problem.
1120
00:40:22,320 --> 00:40:23,960
It's a pattern problem.
1121
00:40:23,960 --> 00:40:26,560
The same logic applies to recurring failure modes.
1122
00:40:26,560 --> 00:40:28,480
Maintenance teams usually know the painful ones
1123
00:40:28,480 --> 00:40:30,720
by experience, but central history can test
1124
00:40:30,720 --> 00:40:33,040
whether that experience holds across all sites,
1125
00:40:33,040 --> 00:40:35,960
shifts, asset ages, and product families.
1126
00:40:35,960 --> 00:40:38,680
It can separate a genuine repeat failure
1127
00:40:38,680 --> 00:40:41,400
from a problem that just happened loudly last week.
1128
00:40:41,400 --> 00:40:43,240
Quality drift needs that same wider view.
1129
00:40:43,240 --> 00:40:44,840
A defect rate can move slowly enough
1130
00:40:44,840 --> 00:40:46,680
that nobody sees it in a single shift.
1131
00:40:46,680 --> 00:40:49,480
Maybe one product variant begins showing a small surface
1132
00:40:49,480 --> 00:40:51,200
defect after a supplier change.
1133
00:40:51,200 --> 00:40:53,600
Maybe the rate rises only on one material lot
1134
00:40:53,600 --> 00:40:55,800
with one tool revision at one site.
1135
00:40:55,800 --> 00:40:57,960
Each system may hold part of the answer,
1136
00:40:57,960 --> 00:40:59,960
but the pattern only appears when those records
1137
00:40:59,960 --> 00:41:01,680
come together across time.
1138
00:41:01,680 --> 00:41:03,840
That work needs product data, material data,
1139
00:41:03,840 --> 00:41:06,400
supplier data, inspection records, process settings,
1140
00:41:06,400 --> 00:41:07,600
and site context.
1141
00:41:07,600 --> 00:41:10,640
It also needs a stable definition of the defect itself.
1142
00:41:10,640 --> 00:41:12,800
If one plant classifies a Marcus cosmetic
1143
00:41:12,800 --> 00:41:15,240
and another calls it a reject, central analysis
1144
00:41:15,240 --> 00:41:16,760
just scales up the disagreement.
1145
00:41:16,760 --> 00:41:19,480
Cloud data platforms give you room to hold that history
1146
00:41:19,480 --> 00:41:22,000
and test the relationships without loading each plant
1147
00:41:22,000 --> 00:41:24,560
with a copy of the same analytical workload.
1148
00:41:24,560 --> 00:41:27,400
Fabric can support the govern data layer for that work,
1149
00:41:27,400 --> 00:41:30,320
where quality, production, maintenance, and business data
1150
00:41:30,320 --> 00:41:32,360
connect through agreed definitions.
1151
00:41:32,360 --> 00:41:33,720
Model training belongs there too.
1152
00:41:33,720 --> 00:41:35,480
A local model may inspect a part
1153
00:41:35,480 --> 00:41:38,000
or score a machine condition during production,
1154
00:41:38,000 --> 00:41:40,640
but training a replacement model is a separate process
1155
00:41:40,640 --> 00:41:42,080
with its own controls.
1156
00:41:42,080 --> 00:41:44,520
You need historical samples, labels you can trust,
1157
00:41:44,520 --> 00:41:46,160
a way to compare candidate models,
1158
00:41:46,160 --> 00:41:48,960
and a record of why one version passed while another did not.
1159
00:41:48,960 --> 00:41:51,160
Treat model approval like an engineering change,
1160
00:41:51,160 --> 00:41:52,400
not like a file upload.
1161
00:41:52,400 --> 00:41:54,160
Before a new model reaches a plant,
1162
00:41:54,160 --> 00:41:56,840
someone needs to validate it against the right product range
1163
00:41:56,840 --> 00:41:57,960
and operating conditions.
1164
00:41:57,960 --> 00:42:00,640
They need to check false rejects, misdefacts, input changes,
1165
00:42:00,640 --> 00:42:02,600
and the action that follows its output.
1166
00:42:02,600 --> 00:42:04,560
If the model will influence quality release,
1167
00:42:04,560 --> 00:42:06,760
maintenance spend, or process response,
1168
00:42:06,760 --> 00:42:08,920
the approval path should name the people responsible.
1169
00:42:08,920 --> 00:42:11,520
The cloud gives you a controlled place to train,
1170
00:42:11,520 --> 00:42:14,600
validate, document, and approve those versions.
1171
00:42:14,600 --> 00:42:16,600
It can also hold the rollout record,
1172
00:42:16,600 --> 00:42:18,000
which version went to which site,
1173
00:42:18,000 --> 00:42:20,240
which line received it when it became active,
1174
00:42:20,240 --> 00:42:21,960
and what happened when it was rolled back.
1175
00:42:21,960 --> 00:42:24,000
That record matters when production changes.
1176
00:42:24,000 --> 00:42:25,600
A model that worked well last year
1177
00:42:25,600 --> 00:42:28,000
may behave differently after a camera replacement,
1178
00:42:28,000 --> 00:42:29,760
new lighting, a recipe update,
1179
00:42:29,760 --> 00:42:31,480
or a product design change.
1180
00:42:31,480 --> 00:42:34,720
Central monitoring can spot those changes across the installed base,
1181
00:42:34,720 --> 00:42:37,640
then root a reviewed version back to the places that needed.
1182
00:42:37,640 --> 00:42:39,360
The plant receives an approved package,
1183
00:42:39,360 --> 00:42:41,800
not an experiment disguised as a deployment.
1184
00:42:41,800 --> 00:42:44,600
Corporate reporting belongs above the plant for a simpler reason.
1185
00:42:44,600 --> 00:42:46,400
The audience and the data scope sit there.
1186
00:42:46,400 --> 00:42:48,600
Finance may need production costs, scrap costs,
1187
00:42:48,600 --> 00:42:51,080
energy use, labor data, inventory movement,
1188
00:42:51,080 --> 00:42:52,960
and delivery performance in one view.
1189
00:42:52,960 --> 00:42:56,000
Compliance teams may need a durable history of quality records,
1190
00:42:56,000 --> 00:42:58,320
process evidence, approvals, and changes.
1191
00:42:58,320 --> 00:43:00,440
Plant teams supply parts of that record,
1192
00:43:00,440 --> 00:43:03,120
but the company needs a consistent view across sites.
1193
00:43:03,120 --> 00:43:05,320
That view has to preserve source and ownership.
1194
00:43:05,320 --> 00:43:08,000
A corporate report shouldn't quietly rewrite a plant event
1195
00:43:08,000 --> 00:43:10,240
because a financial calendar uses a different cutoff.
1196
00:43:10,240 --> 00:43:12,280
You can combine the facts while still retaining
1197
00:43:12,280 --> 00:43:14,480
where each fact came from when it happened
1198
00:43:14,480 --> 00:43:15,920
and which system recorded it.
1199
00:43:15,920 --> 00:43:19,120
Enterprise cost analysis also benefits from central context.
1200
00:43:19,120 --> 00:43:20,600
A local line can show downtime.
1201
00:43:20,600 --> 00:43:22,960
It usually can't calculate the full commercial effect
1202
00:43:22,960 --> 00:43:25,000
without order priority, customer commitments,
1203
00:43:25,000 --> 00:43:27,960
material availability, labor, energy rates,
1204
00:43:27,960 --> 00:43:30,480
alternate capacity, and downstream impact.
1205
00:43:30,480 --> 00:43:32,720
Those inputs live across business systems.
1206
00:43:32,720 --> 00:43:34,640
Planning is where this becomes very clear.
1207
00:43:34,640 --> 00:43:36,080
ERP records what happened,
1208
00:43:36,080 --> 00:43:38,320
orders, inventory, purchase, activity,
1209
00:43:38,320 --> 00:43:40,160
confirmations, financial facts.
1210
00:43:40,160 --> 00:43:42,480
It provides the business record of the company.
1211
00:43:42,480 --> 00:43:44,120
APS asks a different question.
1212
00:43:44,120 --> 00:43:46,320
Given current demand, available capacity,
1213
00:43:46,320 --> 00:43:48,120
material limits, labor constraints,
1214
00:43:48,120 --> 00:43:49,840
change over rules, maintenance windows,
1215
00:43:49,840 --> 00:43:51,680
and routing options, what could happen next?
1216
00:43:51,680 --> 00:43:53,960
That scenario analysis attests feasible plans
1217
00:43:53,960 --> 00:43:56,040
across a planning horizon rather than treating
1218
00:43:56,040 --> 00:43:57,640
the current schedule as fixed.
1219
00:43:57,640 --> 00:43:59,720
A planner may ask whether an urgent order can fit
1220
00:43:59,720 --> 00:44:01,640
without pushing another commitment late,
1221
00:44:01,640 --> 00:44:03,520
whether a line can absorb a disruption
1222
00:44:03,520 --> 00:44:05,520
or whether a maintenance window needs to move
1223
00:44:05,520 --> 00:44:08,160
because the next few days leave no safe capacity.
1224
00:44:08,160 --> 00:44:10,120
Those questions need enterprise scope.
1225
00:44:10,120 --> 00:44:11,760
They need data from more than one system
1226
00:44:11,760 --> 00:44:13,280
and often more than one plant.
1227
00:44:13,280 --> 00:44:15,200
They also tolerate a slower decision cycle
1228
00:44:15,200 --> 00:44:17,280
because the output is a proposed plan,
1229
00:44:17,280 --> 00:44:18,840
not a direct command to a machine.
1230
00:44:18,840 --> 00:44:20,480
A plan can recommend work.
1231
00:44:20,480 --> 00:44:23,280
Execution still needs to check the actual state of the floor.
1232
00:44:23,280 --> 00:44:25,840
The useful factory workloads rarely sit in one place
1233
00:44:25,840 --> 00:44:27,000
from start to finish.
1234
00:44:27,000 --> 00:44:28,960
They cross the boundary several times
1235
00:44:28,960 --> 00:44:32,720
with each layer doing the work it can actually support.
1236
00:44:32,720 --> 00:44:34,760
The closed loop between edge and cloud.
1237
00:44:34,760 --> 00:44:36,240
The useful pattern is a loop,
1238
00:44:36,240 --> 00:44:38,720
but not a loop where every signal travels up to the cloud
1239
00:44:38,720 --> 00:44:40,320
and waits for permission to come back down.
1240
00:44:40,320 --> 00:44:42,600
The edge captures what happens at the process.
1241
00:44:42,600 --> 00:44:44,760
It checks signals against local rules,
1242
00:44:44,760 --> 00:44:46,680
acts where a local action is allowed,
1243
00:44:46,680 --> 00:44:48,840
and retains the evidence around that event,
1244
00:44:48,840 --> 00:44:51,040
cloud systems collect the longer history,
1245
00:44:51,040 --> 00:44:53,000
compare it with other assets and sites,
1246
00:44:53,000 --> 00:44:56,320
then produce a better rule, threshold or model.
1247
00:44:56,320 --> 00:44:58,640
But only after someone has reviewed it.
1248
00:44:58,640 --> 00:45:01,800
That revised logic returns to the edge as an approved update
1249
00:45:01,800 --> 00:45:04,560
and the edge uses it during the next production run.
1250
00:45:04,560 --> 00:45:07,520
This keeps the immediate decision close to the physical process
1251
00:45:07,520 --> 00:45:09,680
while still allowing the wider system to learn.
1252
00:45:09,680 --> 00:45:12,400
You aren't choosing between local action and central analysis.
1253
00:45:12,400 --> 00:45:14,200
You're giving each one a defined part
1254
00:45:14,200 --> 00:45:15,720
of the same operational loop.
1255
00:45:15,720 --> 00:45:18,280
Take predictive maintenance.
1256
00:45:18,280 --> 00:45:20,240
A motor begins to show a vibration pattern
1257
00:45:20,240 --> 00:45:22,000
outside the expected local range.
1258
00:45:22,000 --> 00:45:23,800
The edge detects it, records the condition
1259
00:45:23,800 --> 00:45:25,680
and raises the local alarm that maintains
1260
00:45:25,680 --> 00:45:26,720
or the operator needs.
1261
00:45:26,720 --> 00:45:27,920
If the process needs protection,
1262
00:45:27,920 --> 00:45:30,320
the protective path already exists locally.
1263
00:45:30,320 --> 00:45:32,320
Nothing waits for a remote trend calculation
1264
00:45:32,320 --> 00:45:33,840
before the plant responds.
1265
00:45:33,840 --> 00:45:36,640
Meanwhile, the edge sends the alarm, the health measures,
1266
00:45:36,640 --> 00:45:38,640
and selected source evidence upstream
1267
00:45:38,640 --> 00:45:39,920
when the path is available.
1268
00:45:39,920 --> 00:45:42,640
Over time, cloud analysis can compare that motor
1269
00:45:42,640 --> 00:45:45,600
with similar motors, inspect past maintenance records,
1270
00:45:45,600 --> 00:45:48,640
and look for cases where the alarm preceded a real failure,
1271
00:45:48,640 --> 00:45:51,440
as well as cases where it did not.
1272
00:45:51,440 --> 00:45:53,400
That work may show that the local threshold
1273
00:45:53,400 --> 00:45:55,120
is too loose for one asset class
1274
00:45:55,120 --> 00:45:57,680
or too sensitive under a known operating condition.
1275
00:45:57,680 --> 00:46:00,080
But that doesn't mean a cloud job quietly edits a limit
1276
00:46:00,080 --> 00:46:01,160
on a running line.
1277
00:46:01,160 --> 00:46:02,600
An engineer reviews the finding.
1278
00:46:02,600 --> 00:46:04,640
Maintenance confirms that the failure mode
1279
00:46:04,640 --> 00:46:06,160
and response make sense.
1280
00:46:06,160 --> 00:46:08,160
OT checks the local impact, then the team
1281
00:46:08,160 --> 00:46:09,960
publishes a new threshold or rule version
1282
00:46:09,960 --> 00:46:11,440
through a controlled release path.
1283
00:46:11,440 --> 00:46:13,960
The edge receives that version, checks that it's valid
1284
00:46:13,960 --> 00:46:15,880
for its asset and line configuration,
1285
00:46:15,880 --> 00:46:18,520
and applies it under the release conditions you defined.
1286
00:46:18,520 --> 00:46:20,640
If the new rule behaves badly,
1287
00:46:20,640 --> 00:46:23,200
you need to know exactly how to return to the prior version.
1288
00:46:23,200 --> 00:46:25,080
That's rollback, and it needs to be designed
1289
00:46:25,080 --> 00:46:27,280
before the update looks necessary.
1290
00:46:27,280 --> 00:46:29,520
Quality inspection follows the same loop,
1291
00:46:29,520 --> 00:46:31,520
though the time pressure can be much tighter.
1292
00:46:31,520 --> 00:46:33,680
A local vision process inspects each part
1293
00:46:33,680 --> 00:46:35,960
and produces the local result needed by the line.
1294
00:46:35,960 --> 00:46:38,640
The inspection system records the decision, model version,
1295
00:46:38,640 --> 00:46:40,720
confidence, product reference, and the evidence
1296
00:46:40,720 --> 00:46:41,760
you chose to retain.
1297
00:46:41,760 --> 00:46:43,400
If a part needs to leave the line,
1298
00:46:43,400 --> 00:46:47,000
the local process acts within its own defined window.
1299
00:46:47,000 --> 00:46:49,440
Cloud analysis looks at the larger pattern later.
1300
00:46:49,440 --> 00:46:51,680
It can compare defect types across shifts,
1301
00:46:51,680 --> 00:46:54,160
products, cameras, plants, and recipe versions.
1302
00:46:54,160 --> 00:46:56,040
It can spot drift that is too gradual
1303
00:46:56,040 --> 00:46:59,200
for one operator to notice, like a rise in a certain defect
1304
00:46:59,200 --> 00:47:02,120
after a tooling change or a decline in model confidence
1305
00:47:02,120 --> 00:47:03,600
after a lighting change.
1306
00:47:03,600 --> 00:47:06,120
The outcome may be an updated inspection rule package.
1307
00:47:06,120 --> 00:47:08,280
That package might contain a revised model,
1308
00:47:08,280 --> 00:47:11,360
a new confidence threshold, a changed defect mapping,
1309
00:47:11,360 --> 00:47:13,440
or a modified evidence retention rule.
1310
00:47:13,440 --> 00:47:15,600
It should carry a version and approval record,
1311
00:47:15,600 --> 00:47:17,840
a target scope, and a defined way back
1312
00:47:17,840 --> 00:47:19,440
if it fails in production.
1313
00:47:19,440 --> 00:47:20,960
A rule package without those details
1314
00:47:20,960 --> 00:47:23,240
is just a surprise delivered to the shop floor.
1315
00:47:23,240 --> 00:47:26,160
This separation matters because automatic local action
1316
00:47:26,160 --> 00:47:28,800
and a policy change are not the same thing.
1317
00:47:28,800 --> 00:47:30,560
An approved local rule can reject a part
1318
00:47:30,560 --> 00:47:32,560
because the rule already passed process quality
1319
00:47:32,560 --> 00:47:33,640
and engineering review.
1320
00:47:33,640 --> 00:47:35,320
The rule is acting inside a boundary
1321
00:47:35,320 --> 00:47:36,720
that people agreed in advance.
1322
00:47:36,720 --> 00:47:38,280
Changing that rule changes the boundary.
1323
00:47:38,280 --> 00:47:40,800
It can alter scrap rates, operate a workload,
1324
00:47:40,800 --> 00:47:43,840
product release decisions, and sometimes equipment behavior.
1325
00:47:43,840 --> 00:47:45,440
That requires human approval.
1326
00:47:45,440 --> 00:47:46,920
You can automate deployment mechanics
1327
00:47:46,920 --> 00:47:48,440
without automating authority.
1328
00:47:48,440 --> 00:47:51,600
A platform can distribute a signed package to the right nodes,
1329
00:47:51,600 --> 00:47:53,440
stage it on a limited group of lines,
1330
00:47:53,440 --> 00:47:55,240
report its health, and stop the rollout
1331
00:47:55,240 --> 00:47:56,840
when defined checks fail.
1332
00:47:56,840 --> 00:47:59,080
People still decide whether the rule should exist,
1333
00:47:59,080 --> 00:48:01,880
where it should apply, and what the fallback should be.
1334
00:48:01,880 --> 00:48:03,560
The edge also needs a local fallback
1335
00:48:03,560 --> 00:48:05,000
when the update path fails.
1336
00:48:05,000 --> 00:48:06,400
If cloud access disappears,
1337
00:48:06,400 --> 00:48:08,760
the edge keeps running the last approved version.
1338
00:48:08,760 --> 00:48:10,080
If a new model won't load,
1339
00:48:10,080 --> 00:48:12,480
it should not leave the station in an unknown state.
1340
00:48:12,480 --> 00:48:14,200
It can return to the earlier model,
1341
00:48:14,200 --> 00:48:15,720
use a fixed threshold rule,
1342
00:48:15,720 --> 00:48:17,800
send uncertain parts to manual review,
1343
00:48:17,800 --> 00:48:20,400
or raise a local fault that requires intervention.
1344
00:48:20,400 --> 00:48:22,200
The right choice depends on the process,
1345
00:48:22,200 --> 00:48:24,680
but keep trying the cloud isn't a fallback.
1346
00:48:24,680 --> 00:48:26,080
Track these states clearly,
1347
00:48:26,080 --> 00:48:28,440
which version is active, which version is staged,
1348
00:48:28,440 --> 00:48:30,120
which rule produced this event,
1349
00:48:30,120 --> 00:48:32,440
whether the edge applied the update rejected it
1350
00:48:32,440 --> 00:48:35,080
or reverted after a health check failed.
1351
00:48:35,080 --> 00:48:37,240
Without that record, an engineer reviewing a defect
1352
00:48:37,240 --> 00:48:40,000
or alarm later cannot tell whether the process changed
1353
00:48:40,000 --> 00:48:41,120
because the machine changed
1354
00:48:41,120 --> 00:48:42,680
or because the software changed.
1355
00:48:42,680 --> 00:48:45,880
That's where many industrial AI discussions become vague.
1356
00:48:45,880 --> 00:48:48,320
People talk about a model that learns continuously
1357
00:48:48,320 --> 00:48:50,120
as if it should revise its own authority
1358
00:48:50,120 --> 00:48:51,600
while production is running.
1359
00:48:51,600 --> 00:48:54,440
In a factory, learning and acting need separate controls,
1360
00:48:54,440 --> 00:48:56,120
the learning system can propose,
1361
00:48:56,120 --> 00:48:58,040
the approved local system can act,
1362
00:48:58,040 --> 00:48:59,920
the change path between them leads owners,
1363
00:48:59,920 --> 00:49:02,520
versions, tests, and a way back.
1364
00:49:02,520 --> 00:49:04,800
AI doesn't remove the edge cloud boundary.
1365
00:49:04,800 --> 00:49:06,440
It makes the boundary easier to see
1366
00:49:06,440 --> 00:49:08,960
because every model forces you to answer two questions,
1367
00:49:08,960 --> 00:49:11,360
where does it learn and where does it make the decision?
1368
00:49:11,360 --> 00:49:12,480
Those are not the same place.
1369
00:49:12,480 --> 00:49:14,920
So let's separate training from inference.
1370
00:49:14,920 --> 00:49:17,280
Industrial AI without the magic show.
1371
00:49:17,280 --> 00:49:19,240
Let's cut through the AI hype for a second.
1372
00:49:19,240 --> 00:49:22,840
Industrial AI is patent detection tied to a process decision.
1373
00:49:22,840 --> 00:49:24,240
That's the useful definition.
1374
00:49:24,240 --> 00:49:26,480
It takes known inputs like a camera image,
1375
00:49:26,480 --> 00:49:29,000
vibration signal, temperature trend, sound pattern,
1376
00:49:29,000 --> 00:49:30,560
or machine state sequence,
1377
00:49:30,560 --> 00:49:32,920
then returns an output a process can use.
1378
00:49:32,920 --> 00:49:34,800
That output might be a defect class
1379
00:49:34,800 --> 00:49:36,840
and anomaly score, a likely condition,
1380
00:49:36,840 --> 00:49:39,160
or a confidence level that tells an operator
1381
00:49:39,160 --> 00:49:40,480
to take a closer look.
1382
00:49:40,480 --> 00:49:42,640
Sounds simple, and that's because it is.
1383
00:49:42,640 --> 00:49:45,040
Most of the work sits around the model not inside it.
1384
00:49:45,040 --> 00:49:46,480
You need to know what signal goes in,
1385
00:49:46,480 --> 00:49:47,840
what the output means,
1386
00:49:47,840 --> 00:49:50,160
how confident the model has to be before anyone acts
1387
00:49:50,160 --> 00:49:51,960
and who owns the action that follows.
1388
00:49:51,960 --> 00:49:53,720
If a model can't answer those questions,
1389
00:49:53,720 --> 00:49:55,360
it might make an interesting demo,
1390
00:49:55,360 --> 00:49:57,440
but it's not ready for a production decision.
1391
00:49:57,440 --> 00:49:59,640
At the edge AI usually runs as inference.
1392
00:49:59,640 --> 00:50:00,800
The model already exists.
1393
00:50:00,800 --> 00:50:03,080
It takes a local input, performs the calculation,
1394
00:50:03,080 --> 00:50:05,280
and returns a result fast enough for the process.
1395
00:50:05,280 --> 00:50:07,840
Think of a vision station that classifies a surface defect
1396
00:50:07,840 --> 00:50:09,960
while the part is still within the inspection area,
1397
00:50:09,960 --> 00:50:11,440
or a condition monitoring service
1398
00:50:11,440 --> 00:50:12,800
that scores a vibration pattern
1399
00:50:12,800 --> 00:50:15,600
and marks it as normal, uncertain, or out of range.
1400
00:50:15,600 --> 00:50:17,840
A local classifier might sort machine sounds
1401
00:50:17,840 --> 00:50:19,120
into operating states,
1402
00:50:19,120 --> 00:50:21,280
so an operator can spot a developing issue
1403
00:50:21,280 --> 00:50:22,880
before it becomes a failure.
1404
00:50:22,880 --> 00:50:24,760
The edge doesn't need to invent new models
1405
00:50:24,760 --> 00:50:25,840
while the line runs.
1406
00:50:25,840 --> 00:50:28,480
It needs to apply a known version consistently,
1407
00:50:28,480 --> 00:50:31,640
log the result, and follow a defined response path.
1408
00:50:31,640 --> 00:50:34,240
That distinction is what keeps the system manageable.
1409
00:50:34,240 --> 00:50:37,400
A model result should include more than just pass or fail.
1410
00:50:37,400 --> 00:50:39,560
You want the model version, input source, time,
1411
00:50:39,560 --> 00:50:41,880
confidence score, and the business or production reference
1412
00:50:41,880 --> 00:50:42,720
at that moment.
1413
00:50:42,720 --> 00:50:44,840
If a local action follows, record that too.
1414
00:50:44,840 --> 00:50:47,240
Later when someone asks why a part got rejected
1415
00:50:47,240 --> 00:50:48,640
or why an alarm went off,
1416
00:50:48,640 --> 00:50:50,840
a screenshot from a dashboard won't cut.
1417
00:50:50,840 --> 00:50:52,520
Cloudwork is different because the questions
1418
00:50:52,520 --> 00:50:54,640
need more history and more scope.
1419
00:50:54,640 --> 00:50:57,240
Training a model means collecting examples over time,
1420
00:50:57,240 --> 00:50:59,480
checking the labels, picking the input data,
1421
00:50:59,480 --> 00:51:01,760
testing candidate versions, and comparing results
1422
00:51:01,760 --> 00:51:03,160
against known cases.
1423
00:51:03,160 --> 00:51:05,400
For a quality model, that could mean thousands of images
1424
00:51:05,400 --> 00:51:08,280
across product variants, lighting conditions, camera positions,
1425
00:51:08,280 --> 00:51:09,720
and actual defect types.
1426
00:51:09,720 --> 00:51:12,680
For condition monitoring, it means comparing equipment data
1427
00:51:12,680 --> 00:51:15,720
with confirmed maintenance findings over months or years.
1428
00:51:15,720 --> 00:51:18,120
A single edge node rarely has that wider view.
1429
00:51:18,120 --> 00:51:19,680
It sees its own process fine,
1430
00:51:19,680 --> 00:51:21,600
but it can't easily tell whether its model works
1431
00:51:21,600 --> 00:51:24,160
across different sites or a changing product mix.
1432
00:51:24,160 --> 00:51:26,360
Central training brings those records together.
1433
00:51:26,360 --> 00:51:28,640
Compare models under the same test conditions,
1434
00:51:28,640 --> 00:51:30,560
keeps the approval history, and shows
1435
00:51:30,560 --> 00:51:33,000
whether a proposed version actually improves detection
1436
00:51:33,000 --> 00:51:36,520
without creating too many false alerts or false rejects.
1437
00:51:36,520 --> 00:51:38,960
Still, more data doesn't fix bad data.
1438
00:51:38,960 --> 00:51:41,640
Model drift starts when the relationship between the input
1439
00:51:41,640 --> 00:51:43,400
and the real process changes.
1440
00:51:43,400 --> 00:51:46,040
A vision model can lose accuracy after a camera is replaced,
1441
00:51:46,040 --> 00:51:49,040
a lens is cleaned differently or lighting shifts over time.
1442
00:51:49,040 --> 00:51:51,400
An anomaly model might start flagging normal behavior
1443
00:51:51,400 --> 00:51:54,720
after a machine gets a new motor, a recipe changes the load profile
1444
00:51:54,720 --> 00:51:56,440
or the process itself changes.
1445
00:51:56,440 --> 00:51:59,360
The model isn't confused, the world around it changed.
1446
00:51:59,360 --> 00:52:00,720
Bad labels cause another problem.
1447
00:52:00,720 --> 00:52:03,280
If inspectors disagree about what counts as a defect,
1448
00:52:03,280 --> 00:52:05,720
the training set teaches that disagreement to the model.
1449
00:52:05,720 --> 00:52:07,560
If a maintenance record says bearing issue
1450
00:52:07,560 --> 00:52:09,600
because that was the nearest available code,
1451
00:52:09,600 --> 00:52:11,720
even though the fault was actually misalignment,
1452
00:52:11,720 --> 00:52:14,480
the model learns a weak connection between signal and outcome.
1453
00:52:14,480 --> 00:52:17,160
This is why industrial AI depends on process knowledge.
1454
00:52:17,160 --> 00:52:18,920
Data scientists can test model behavior,
1455
00:52:18,920 --> 00:52:21,000
but they need quality engineers, maintenance teams
1456
00:52:21,000 --> 00:52:23,720
and operators to explain what actually happened on the floor.
1457
00:52:23,720 --> 00:52:25,760
The same goes when product families change.
1458
00:52:25,760 --> 00:52:28,520
A model trained on one finish, material, shape,
1459
00:52:28,520 --> 00:52:31,840
or operating range may not apply clearly to the next one,
1460
00:52:31,840 --> 00:52:34,040
treating it as universal because the input still looks
1461
00:52:34,040 --> 00:52:36,520
like an image or a sensor stream is how models
1462
00:52:36,520 --> 00:52:38,480
quietly start making bad decisions.
1463
00:52:38,480 --> 00:52:39,720
Human review stays in the loop
1464
00:52:39,720 --> 00:52:41,840
where the result affects safety, product release,
1465
00:52:41,840 --> 00:52:43,840
or maintenance spend.
1466
00:52:43,840 --> 00:52:46,640
A model can flag a condition, rank a set of images
1467
00:52:46,640 --> 00:52:48,480
or suggest a motor needs attention,
1468
00:52:48,480 --> 00:52:51,720
but a safety response still follows validated control design.
1469
00:52:51,720 --> 00:52:53,800
A quality release decision may need an engineer
1470
00:52:53,800 --> 00:52:55,080
to review the evidence.
1471
00:52:55,080 --> 00:52:57,320
A costly maintenance action may need a planner
1472
00:52:57,320 --> 00:52:59,280
to weigh the condition against production demand,
1473
00:52:59,280 --> 00:53:02,080
available parts, and the actual failure mode.
1474
00:53:02,080 --> 00:53:03,560
Automation has its place.
1475
00:53:03,560 --> 00:53:05,080
Authority needs a boundary.
1476
00:53:05,080 --> 00:53:06,400
When you define those boundaries,
1477
00:53:06,400 --> 00:53:08,480
industrial AI becomes useful engineering
1478
00:53:08,480 --> 00:53:11,160
rather than a vague promise attached to a cloud diagram.
1479
00:53:11,160 --> 00:53:13,880
And quality inspection shows the architecture problem more clearly
1480
00:53:13,880 --> 00:53:16,920
than almost any other use case because the line keeps moving
1481
00:53:16,920 --> 00:53:18,560
while the decision is being made.
1482
00:53:18,560 --> 00:53:21,320
The quality inspection, where latency becomes scrap,
1483
00:53:21,320 --> 00:53:23,120
take a vision station on a moving line,
1484
00:53:23,120 --> 00:53:25,760
apart passes the camera, the image gets captured,
1485
00:53:25,760 --> 00:53:28,400
the inspection logic decides whether that part meets the rule
1486
00:53:28,400 --> 00:53:31,040
and a reject device has one short chance to remove it.
1487
00:53:31,040 --> 00:53:33,120
After that, the part has moved on.
1488
00:53:33,120 --> 00:53:35,440
The available time can be less than a second,
1489
00:53:35,440 --> 00:53:36,760
sometimes a lot less.
1490
00:53:36,760 --> 00:53:38,960
That window includes image capture, transfer,
1491
00:53:38,960 --> 00:53:40,960
inference, result handling, part tracking,
1492
00:53:40,960 --> 00:53:42,600
triggering the reject device,
1493
00:53:42,600 --> 00:53:44,720
and confirming the action actually happened.
1494
00:53:44,720 --> 00:53:46,520
People talk about vision AI like the model
1495
00:53:46,520 --> 00:53:48,400
as the hard part, but on a live line,
1496
00:53:48,400 --> 00:53:50,120
the real question is whether the result
1497
00:53:50,120 --> 00:53:53,200
reaches the physical part before the reject window closes.
1498
00:53:53,200 --> 00:53:54,800
That whole path has to be local.
1499
00:53:54,800 --> 00:53:57,040
The camera, local inference service,
1500
00:53:57,040 --> 00:54:00,160
encoder or part tracking signal, and reject mechanism
1501
00:54:00,160 --> 00:54:02,880
need a shared time reference and a known response path.
1502
00:54:02,880 --> 00:54:04,800
If the vision system finds a defect,
1503
00:54:04,800 --> 00:54:07,160
it has to link that result to the correct physical item,
1504
00:54:07,160 --> 00:54:09,120
not just send a defect message into a queue
1505
00:54:09,120 --> 00:54:11,120
and hope the rest of the system catches up.
1506
00:54:11,120 --> 00:54:13,160
A late result can reject the wrong part,
1507
00:54:13,160 --> 00:54:15,000
and that's worse than no result at all.
1508
00:54:15,000 --> 00:54:17,960
Imagine a line inspecting printed labels on filled cartons.
1509
00:54:17,960 --> 00:54:19,680
The camera spots a missing date code,
1510
00:54:19,680 --> 00:54:20,880
the conveyor keeps moving,
1511
00:54:20,880 --> 00:54:23,440
and the reject station sits a few meters downstream.
1512
00:54:23,440 --> 00:54:25,480
Local logic has to attach that failed image
1513
00:54:25,480 --> 00:54:27,600
to the cartons position, then fire the reject
1514
00:54:27,600 --> 00:54:28,400
at the right moment.
1515
00:54:28,400 --> 00:54:30,600
It also has to confirm whether the actuator fired
1516
00:54:30,600 --> 00:54:32,520
and whether the carton actually left the flow.
1517
00:54:32,520 --> 00:54:33,800
That's a closed local process,
1518
00:54:33,800 --> 00:54:36,440
even if the inspection model runs on an industrial PC
1519
00:54:36,440 --> 00:54:38,280
rather than inside the camera.
1520
00:54:38,280 --> 00:54:39,760
Local evidence matters too.
1521
00:54:39,760 --> 00:54:42,000
For every failed inspection, keep the image
1522
00:54:42,000 --> 00:54:45,240
or bounded image set, the defect class, confidence score,
1523
00:54:45,240 --> 00:54:48,120
camera identity, lighting or inspection recipe
1524
00:54:48,120 --> 00:54:50,520
where relevant and the local model version
1525
00:54:50,520 --> 00:54:52,800
capture the time and part reference with it.
1526
00:54:52,800 --> 00:54:56,000
That record lets someone later answer a basic question.
1527
00:54:56,000 --> 00:54:57,880
Did the system find a real defect
1528
00:54:57,880 --> 00:55:00,600
or did it misread glare, dust, motion blur
1529
00:55:00,600 --> 00:55:02,400
or a changed package design?
1530
00:55:02,400 --> 00:55:05,600
Without local evidence, a pass or fail result is a dead end.
1531
00:55:05,600 --> 00:55:07,680
A plant might also keep a controlled sample
1532
00:55:07,680 --> 00:55:09,920
of passing images, not every image forever
1533
00:55:09,920 --> 00:55:12,800
because that creates a storage problem with no clear purpose.
1534
00:55:12,800 --> 00:55:14,960
But enough samples to monitor whether visual conditions
1535
00:55:14,960 --> 00:55:15,720
are changing.
1536
00:55:15,720 --> 00:55:17,560
Lensware, camera drift, lighting changes,
1537
00:55:17,560 --> 00:55:20,320
a new surface finish, all these can shift the input away
1538
00:55:20,320 --> 00:55:22,160
from what the inspection rule expects.
1539
00:55:22,160 --> 00:55:23,960
The line still needs its local decision.
1540
00:55:23,960 --> 00:55:25,480
Cloudwork begins after that decision
1541
00:55:25,480 --> 00:55:26,960
has protected the process.
1542
00:55:26,960 --> 00:55:28,880
Central systems can keep selected samples
1543
00:55:28,880 --> 00:55:31,200
and inspection records over a longer period,
1544
00:55:31,200 --> 00:55:35,120
comparing defect types between lines, products, sites,
1545
00:55:35,120 --> 00:55:37,960
material lots and inspection settings.
1546
00:55:37,960 --> 00:55:39,960
That's how a gradual change becomes visible
1547
00:55:39,960 --> 00:55:41,640
before it turns into a customer complaint
1548
00:55:41,640 --> 00:55:43,240
or a full shift of rework.
1549
00:55:43,240 --> 00:55:45,560
Fabric can provide the shared data layer for this,
1550
00:55:45,560 --> 00:55:47,480
but only when the inspection result arrives
1551
00:55:47,480 --> 00:55:49,120
with enough process context.
1552
00:55:49,120 --> 00:55:51,480
A defect record should connect to the batch or lot,
1553
00:55:51,480 --> 00:55:53,360
the recipe, the tool or station setup,
1554
00:55:53,360 --> 00:55:55,200
the operator shift and the work order.
1555
00:55:55,200 --> 00:55:56,280
That sounds like a lot of fields
1556
00:55:56,280 --> 00:55:58,840
until you try to investigate a quality issue without them.
1557
00:55:58,840 --> 00:56:01,000
Say quality sees a rise in seal defects.
1558
00:56:01,000 --> 00:56:03,000
The image shows the defect but not the cause.
1559
00:56:03,000 --> 00:56:04,200
Connect the record to a batch
1560
00:56:04,200 --> 00:56:06,920
and you can check if the issue started with a material change,
1561
00:56:06,920 --> 00:56:08,040
connected to the recipe
1562
00:56:08,040 --> 00:56:10,920
and you can see if a parameter revision changed the process.
1563
00:56:10,920 --> 00:56:12,600
Add tool state and shift
1564
00:56:12,600 --> 00:56:14,880
and the problem might point toward where, setup
1565
00:56:14,880 --> 00:56:16,400
or a condition that only shows up
1566
00:56:16,400 --> 00:56:18,200
during a certain operating period.
1567
00:56:18,200 --> 00:56:21,360
The goal isn't to blame a shift or a supplier from one chart.
1568
00:56:21,360 --> 00:56:23,040
It's to stop treating inspection
1569
00:56:23,040 --> 00:56:24,920
as an isolated pass fail machine.
1570
00:56:24,920 --> 00:56:27,840
A good cloud data set lets quality engineers
1571
00:56:27,840 --> 00:56:30,960
compare the same defect across time and conditions.
1572
00:56:30,960 --> 00:56:32,640
It can show if one camera produces more
1573
00:56:32,640 --> 00:56:34,840
uncertain results after a lighting change.
1574
00:56:34,840 --> 00:56:38,320
It can reveal that a defect cluster follows a specific product variant
1575
00:56:38,320 --> 00:56:40,840
and it can supply curated examples for retraining
1576
00:56:40,840 --> 00:56:42,400
where confirmed effect and good images
1577
00:56:42,400 --> 00:56:44,120
become part of the next model review.
1578
00:56:44,120 --> 00:56:45,840
That training path needs clean labels.
1579
00:56:45,840 --> 00:56:47,240
If images enter the central store
1580
00:56:47,240 --> 00:56:49,280
with no agreed defect code, product reference
1581
00:56:49,280 --> 00:56:52,200
or way to tell if a human later overruled the machine result,
1582
00:56:52,200 --> 00:56:53,720
they're weak training material.
1583
00:56:53,720 --> 00:56:56,600
Stored files, not usable quality evidence.
1584
00:56:56,600 --> 00:57:00,240
This is why sending only pass or fail limits improvement.
1585
00:57:00,240 --> 00:57:01,840
Pass or fail can support account
1586
00:57:01,840 --> 00:57:03,080
and feed a simple reject total
1587
00:57:03,080 --> 00:57:04,720
but it can't explain which defect appeared,
1588
00:57:04,720 --> 00:57:06,640
what the model saw, how certain it was,
1589
00:57:06,640 --> 00:57:08,000
whether the reject action succeeded
1590
00:57:08,000 --> 00:57:10,240
or what process conditions surrounded the part.
1591
00:57:10,240 --> 00:57:11,680
And when defect rates rise,
1592
00:57:11,680 --> 00:57:13,760
it can't help you separate a real process change
1593
00:57:13,760 --> 00:57:15,160
from a vision system problem.
1594
00:57:15,160 --> 00:57:17,400
The full architecture gives each layer a job.
1595
00:57:17,400 --> 00:57:19,160
Local inspection catches the item
1596
00:57:19,160 --> 00:57:20,800
while action is still possible.
1597
00:57:20,800 --> 00:57:22,680
Local records preserve the immediate evidence,
1598
00:57:22,680 --> 00:57:25,200
the cloud connects that evidence to production history
1599
00:57:25,200 --> 00:57:28,680
and supports comparison, drift review and controlled retraining.
1600
00:57:28,680 --> 00:57:30,280
Maintenance follows a similar boundary,
1601
00:57:30,280 --> 00:57:32,600
although its failure modes look very different.
1602
00:57:32,600 --> 00:57:35,760
Predictive maintenance, protection here, learning there.
1603
00:57:35,760 --> 00:57:38,080
So maintenance presents the same kind of boundary
1604
00:57:38,080 --> 00:57:39,480
just in a different shape.
1605
00:57:39,480 --> 00:57:41,760
The real question isn't just whether you can predict a failure,
1606
00:57:41,760 --> 00:57:43,800
it's whether the machine needs protection right now
1607
00:57:43,800 --> 00:57:45,440
or whether the team needs better evidence
1608
00:57:45,440 --> 00:57:46,720
to schedule work later.
1609
00:57:46,720 --> 00:57:47,920
You start near the asset.
1610
00:57:47,920 --> 00:57:50,240
An edge service collects vibration, temperature
1611
00:57:50,240 --> 00:57:53,480
and current from a motor, pump, fan or conveyor drive.
1612
00:57:53,480 --> 00:57:56,040
Then turns those signals into local condition indicators
1613
00:57:56,040 --> 00:57:57,360
people can actually use.
1614
00:57:57,360 --> 00:57:59,480
The raw signals might arrive at different rates
1615
00:57:59,480 --> 00:58:00,600
and from different devices.
1616
00:58:00,600 --> 00:58:04,120
So the local service first checks the source timestamp, unit
1617
00:58:04,120 --> 00:58:07,160
and signal quality before it calculates anything.
1618
00:58:07,160 --> 00:58:08,840
And that work needs discipline.
1619
00:58:08,840 --> 00:58:09,960
Take vibration.
1620
00:58:09,960 --> 00:58:11,960
The edge might calculate a measure that tracks
1621
00:58:11,960 --> 00:58:14,720
change an overall motion or a known frequency band.
1622
00:58:14,720 --> 00:58:16,600
For temperature, it might track the rate of rise
1623
00:58:16,600 --> 00:58:18,560
instead of just the current value.
1624
00:58:18,560 --> 00:58:21,200
Current can show load changes, a blocked mechanism,
1625
00:58:21,200 --> 00:58:23,480
or a change in how hard the motor works under the same
1626
00:58:23,480 --> 00:58:24,320
operating state.
1627
00:58:24,320 --> 00:58:26,320
In practical terms, none of those indicators
1628
00:58:26,320 --> 00:58:28,400
prove the failure by itself, but together they
1629
00:58:28,400 --> 00:58:30,840
give the local system a much better view of condition
1630
00:58:30,840 --> 00:58:32,960
than a single threshold on one tag.
1631
00:58:32,960 --> 00:58:35,360
That indicator also needs operating context.
1632
00:58:35,360 --> 00:58:38,040
A motor drawing more current during a heavy product run
1633
00:58:38,040 --> 00:58:39,400
might be perfectly normal.
1634
00:58:39,400 --> 00:58:41,720
The same current pattern during an idle state
1635
00:58:41,720 --> 00:58:43,160
that deserves a different response.
1636
00:58:43,160 --> 00:58:45,400
Local condition monitoring works when it knows enough
1637
00:58:45,400 --> 00:58:47,280
about the machine state to judge the signal
1638
00:58:47,280 --> 00:58:48,520
against the right baseline.
1639
00:58:48,520 --> 00:58:50,960
Some conditions develop slowly and others don't.
1640
00:58:50,960 --> 00:58:52,520
A gradual change in vibration might
1641
00:58:52,520 --> 00:58:55,600
give maintenance days or weeks to inspect and plan a repair.
1642
00:58:55,600 --> 00:58:58,360
But a rapid temperature rise, severe vibration,
1643
00:58:58,360 --> 00:59:01,480
or sudden current excursion requires an immediate local alarm
1644
00:59:01,480 --> 00:59:03,880
in a protective path that doesn't depend on analysis
1645
00:59:03,880 --> 00:59:05,000
outside the plant.
1646
00:59:05,000 --> 00:59:07,360
And you need to keep those paths separate.
1647
00:59:07,360 --> 00:59:09,440
The edge can detect the local condition,
1648
00:59:09,440 --> 00:59:12,080
record the signal window, and notify the operator
1649
00:59:12,080 --> 00:59:14,720
or maintenance team, while the controller and protection
1650
00:59:14,720 --> 00:59:17,480
system handle any action that must protect equipment
1651
00:59:17,480 --> 00:59:18,560
under a fault.
1652
00:59:18,560 --> 00:59:20,560
You don't want a maintenance analytics service
1653
00:59:20,560 --> 00:59:23,320
deciding whether a machine should survive a dangerous condition.
1654
00:59:23,320 --> 00:59:25,680
That sounds obvious until someone sticks a cloud alert
1655
00:59:25,680 --> 00:59:27,360
in the middle of the response chain.
1656
00:59:27,360 --> 00:59:29,960
A local alarm should tell people what changed, where it
1657
00:59:29,960 --> 00:59:32,880
changed, and what evidence supports it.
1658
00:59:32,880 --> 00:59:34,520
Motor health low isn't enough.
1659
00:59:34,520 --> 00:59:37,480
The alert needs the asset identity, the condition indicator,
1660
00:59:37,480 --> 00:59:40,240
the operating state, the time, and the rule version
1661
00:59:40,240 --> 00:59:41,160
that produced it.
1662
00:59:41,160 --> 00:59:43,200
If the local system can't explain the alarm,
1663
00:59:43,200 --> 00:59:45,160
the next shift will learn to ignore it.
1664
00:59:45,160 --> 00:59:47,080
So then the cloud takes on a different job.
1665
00:59:47,080 --> 00:59:49,520
Over months, central history can track asset health
1666
00:59:49,520 --> 00:59:51,960
across the actual operating life of equipment.
1667
00:59:51,960 --> 00:59:54,720
It can compare like for like motors, pumps, gearboxes,
1668
00:59:54,720 --> 00:59:56,640
or drives that work under similar conditions,
1669
00:59:56,640 --> 00:59:59,240
then look for patterns a single machine can't reveal.
1670
00:59:59,240 --> 01:00:01,600
Maybe one asset type shows a repeat current pattern
1671
01:00:01,600 --> 01:00:03,000
before a certain failure.
1672
01:00:03,000 --> 01:00:05,120
Maybe a maintenance action clears the symptom,
1673
01:00:05,120 --> 01:00:06,480
but not the cause.
1674
01:00:06,480 --> 01:00:08,840
Or maybe the same equipment lasts much longer
1675
01:00:08,840 --> 01:00:11,280
at one side because a setup or lubrication practice
1676
01:00:11,280 --> 01:00:12,880
differs.
1677
01:00:12,880 --> 01:00:14,760
Central analysis gives the maintenance team
1678
01:00:14,760 --> 01:00:16,680
a way to test those questions against records
1679
01:00:16,680 --> 01:00:19,120
instead of relying only on memory.
1680
01:00:19,120 --> 01:00:22,280
Comparison only works when like for like means something.
1681
01:00:22,280 --> 01:00:24,760
In practical terms, two pumps with the same nameplate
1682
01:00:24,760 --> 01:00:27,480
might run different fluids, loads, schedules, or duty
1683
01:00:27,480 --> 01:00:28,280
cycles.
1684
01:00:28,280 --> 01:00:30,680
Their condition scores shouldn't enter the same comparison
1685
01:00:30,680 --> 01:00:32,200
without that context.
1686
01:00:32,200 --> 01:00:34,520
The cloud needs asset class, configuration,
1687
01:00:34,520 --> 01:00:36,720
operating range, production conditions,
1688
01:00:36,720 --> 01:00:38,160
and maintenance history.
1689
01:00:38,160 --> 01:00:40,880
Otherwise, the analysis can produce a tidy chart
1690
01:00:40,880 --> 01:00:43,120
that compares unlike machines.
1691
01:00:43,120 --> 01:00:45,560
This is also where people confuse condition monitoring
1692
01:00:45,560 --> 01:00:47,000
with maintenance workflow.
1693
01:00:47,000 --> 01:00:48,920
Condition monitoring asks, what does
1694
01:00:48,920 --> 01:00:50,560
this asset look like right now?
1695
01:00:50,560 --> 01:00:52,280
And has that condition changed?
1696
01:00:52,280 --> 01:00:54,760
It produces readings, trends, indicators, alarms,
1697
01:00:54,760 --> 01:00:55,680
and evidence.
1698
01:00:55,680 --> 01:00:57,960
And that belongs close to the equipment for local awareness
1699
01:00:57,960 --> 01:01:00,880
and fast response, while the longer history can move upward
1700
01:01:00,880 --> 01:01:02,400
for analysis.
1701
01:01:02,400 --> 01:01:04,280
Maintenance workflow asks something else.
1702
01:01:04,280 --> 01:01:05,560
Should we create work?
1703
01:01:05,560 --> 01:01:06,600
When can it happen?
1704
01:01:06,600 --> 01:01:07,520
Who performs it?
1705
01:01:07,520 --> 01:01:08,600
What parts are needed?
1706
01:01:08,600 --> 01:01:11,120
And what does the production plan allow?
1707
01:01:11,120 --> 01:01:13,000
And that decision reaches beyond the edge.
1708
01:01:13,000 --> 01:01:14,840
The CMS holds maintenance plans,
1709
01:01:14,840 --> 01:01:17,520
work orders, labor records, failure codes, and completion
1710
01:01:17,520 --> 01:01:21,240
in history, while ERP may hold spare parts, purchasing data,
1711
01:01:21,240 --> 01:01:24,480
inventory, supplier lead times, and cost records.
1712
01:01:24,480 --> 01:01:25,720
And the production schedule tells you
1713
01:01:25,720 --> 01:01:27,560
whether a maintenance window exists,
1714
01:01:27,560 --> 01:01:29,680
or whether taking the asset down will disrupt an order
1715
01:01:29,680 --> 01:01:31,120
that can't move easily.
1716
01:01:31,120 --> 01:01:33,040
Those systems need to meet above the machine.
1717
01:01:33,040 --> 01:01:35,560
A condition score can trigger a recommendation,
1718
01:01:35,560 --> 01:01:38,400
but it shouldn't silently become a maintenance work order
1719
01:01:38,400 --> 01:01:40,800
without a review of the production consequence.
1720
01:01:40,800 --> 01:01:43,360
A planner might see that the bearing condition looks worse,
1721
01:01:43,360 --> 01:01:44,960
but the required spare isn't on site
1722
01:01:44,960 --> 01:01:46,720
and the line carries an urgent order.
1723
01:01:46,720 --> 01:01:49,600
The right action might be to run under tighter observation,
1724
01:01:49,600 --> 01:01:53,160
move production, obtain the part, and schedule a controlled stop.
1725
01:01:53,160 --> 01:01:55,320
That is a maintenance decision, not a sensor decision.
1726
01:01:55,320 --> 01:01:57,920
So the edge keeps the asset visible and protected
1727
01:01:57,920 --> 01:01:59,120
while disconnected.
1728
01:01:59,120 --> 01:02:01,640
The cloud keeps the long view, connects condition evidence
1729
01:02:01,640 --> 01:02:04,200
to maintenance history, and helps teams choose work
1730
01:02:04,200 --> 01:02:06,040
that fits the operational situation.
1731
01:02:06,040 --> 01:02:08,560
When those roles stay clear, predictive maintenance stops
1732
01:02:08,560 --> 01:02:10,320
being a dashboard full of warnings
1733
01:02:10,320 --> 01:02:12,520
and becomes a root from signal to planned action.
1734
01:02:12,520 --> 01:02:15,440
And OE often gets treated as a cloud dashboard problem,
1735
01:02:15,440 --> 01:02:18,160
but it starts much closer to the machine.
1736
01:02:18,160 --> 01:02:21,560
OE and real-time visibility without fake precision.
1737
01:02:21,560 --> 01:02:24,120
So OE looks simple when it lands in a dashboard,
1738
01:02:24,120 --> 01:02:26,360
availability, performance, and quality.
1739
01:02:26,360 --> 01:02:27,920
But those numbers only mean something
1740
01:02:27,920 --> 01:02:30,640
if the line states beneath them describe what actually happened.
1741
01:02:30,640 --> 01:02:31,880
Start at the machine.
1742
01:02:31,880 --> 01:02:33,840
You need a reliable view of running, stopped,
1743
01:02:33,840 --> 01:02:36,120
faulted, blocked, starved, set up, cleaning,
1744
01:02:36,120 --> 01:02:38,920
and any other state that changes how you interpret output,
1745
01:02:38,920 --> 01:02:42,120
plus good counts, reject counts, cycle timing, speed loss,
1746
01:02:42,120 --> 01:02:45,280
and downtime reasons where the process can provide them.
1747
01:02:45,280 --> 01:02:46,760
That data begins close to the equipment
1748
01:02:46,760 --> 01:02:48,520
because the equipment produces it.
1749
01:02:48,520 --> 01:02:51,080
A PLC knows a machine stopped, a counter knows a unit
1750
01:02:51,080 --> 01:02:54,600
passed, and a vision station may know a part failed inspection.
1751
01:02:54,600 --> 01:02:56,360
But none of those signals automatically
1752
01:02:56,360 --> 01:02:59,280
explains production performance without some local work
1753
01:02:59,280 --> 01:03:03,720
to turn rapid, noisy changes into events people can trust.
1754
01:03:03,720 --> 01:03:05,200
A machine can flicker between running
1755
01:03:05,200 --> 01:03:07,440
and stopped during a short jam, report a fault
1756
01:03:07,440 --> 01:03:09,480
bit for a fraction of a second, then clear it
1757
01:03:09,480 --> 01:03:12,840
before anyone sees it, and account may reset after a controller
1758
01:03:12,840 --> 01:03:13,920
restart.
1759
01:03:13,920 --> 01:03:16,920
If you send every raw state transition directly to a report,
1760
01:03:16,920 --> 01:03:19,520
the result can look very precise while describing a machine
1761
01:03:19,520 --> 01:03:20,600
that never existed.
1762
01:03:20,600 --> 01:03:22,080
So the edge layer helps resolve that.
1763
01:03:22,080 --> 01:03:23,880
It can apply rules for state duration,
1764
01:03:23,880 --> 01:03:26,360
debount signals, correlate related changes,
1765
01:03:26,360 --> 01:03:27,960
and create a bounded downtime event
1766
01:03:27,960 --> 01:03:30,000
rather than a burst of unrelated bits.
1767
01:03:30,000 --> 01:03:32,880
It can keep the original source data available for review,
1768
01:03:32,880 --> 01:03:35,840
but publish the operational event that the MES and analytics
1769
01:03:35,840 --> 01:03:36,920
layer can use.
1770
01:03:36,920 --> 01:03:38,920
A short stop might only become a downtime event
1771
01:03:38,920 --> 01:03:41,640
after it lasts beyond the agreed threshold, a machine fault,
1772
01:03:41,640 --> 01:03:43,520
may need correlation with the actual run state
1773
01:03:43,520 --> 01:03:45,360
before it counts as lost availability,
1774
01:03:45,360 --> 01:03:47,400
and a reject count may need to connect to the product
1775
01:03:47,400 --> 01:03:49,960
count from the same station and time window.
1776
01:03:49,960 --> 01:03:51,880
Those rules need to come from production reality,
1777
01:03:51,880 --> 01:03:54,160
not from whatever fields happen to be easy to read.
1778
01:03:54,160 --> 01:03:56,800
The edge also keeps the event trail intact when the network
1779
01:03:56,800 --> 01:03:59,080
drops, because production doesn't pause politely
1780
01:03:59,080 --> 01:04:00,760
because a one-root failed.
1781
01:04:00,760 --> 01:04:03,840
Machine states continue changing, parts continue moving,
1782
01:04:03,840 --> 01:04:06,280
and operators still need a view of what is happening.
1783
01:04:06,280 --> 01:04:08,600
Local buffering lets the edge hold events
1784
01:04:08,600 --> 01:04:11,040
with their original timestamps and sequence details
1785
01:04:11,040 --> 01:04:12,840
then forward them when the connection returns,
1786
01:04:12,840 --> 01:04:15,040
which prevents a false gap in the shift record
1787
01:04:15,040 --> 01:04:16,960
and prevents later-riving events from looking
1788
01:04:16,960 --> 01:04:18,640
like they happened after the outage,
1789
01:04:18,640 --> 01:04:20,880
which can distort OEE calculations
1790
01:04:20,880 --> 01:04:23,280
and confuse every investigation that follows.
1791
01:04:23,280 --> 01:04:26,600
MES adds the production context that the machine cannot know alone.
1792
01:04:26,600 --> 01:04:29,360
The machine can report that it produced 4,000 units,
1793
01:04:29,360 --> 01:04:31,720
and MES can connect those units to an order,
1794
01:04:31,720 --> 01:04:34,880
an operation, a work center, a planned quantity,
1795
01:04:34,880 --> 01:04:37,040
and the current work in progress state.
1796
01:04:37,040 --> 01:04:39,720
It can guide the reason code workflow when a line stops,
1797
01:04:39,720 --> 01:04:42,760
so the operator or supervisor can distinguish material shortage
1798
01:04:42,760 --> 01:04:45,760
from change over, planned maintenance, quality hold,
1799
01:04:45,760 --> 01:04:47,200
or an equipment fault.
1800
01:04:47,200 --> 01:04:49,240
And that distinction changes the conversation.
1801
01:04:49,240 --> 01:04:52,160
Without a reason code, downtime becomes a generic red bar,
1802
01:04:52,160 --> 01:04:54,600
but with a reason code tied to a defined workflow
1803
01:04:54,600 --> 01:04:56,840
and subject to review, the team can separate
1804
01:04:56,840 --> 01:04:59,440
a recurring equipment issue from a scheduling problem
1805
01:04:59,440 --> 01:05:01,360
or an upstream material issue.
1806
01:05:01,360 --> 01:05:03,440
The data still needs care, because people will choose
1807
01:05:03,440 --> 01:05:06,680
the fastest option when the list contains 20 vague choices.
1808
01:05:06,680 --> 01:05:08,160
Keep the reason codes practical.
1809
01:05:08,160 --> 01:05:10,480
They should describe decisions someone can act on,
1810
01:05:10,480 --> 01:05:13,800
not create a taxonomy that only survives in a PowerPoint file.
1811
01:05:13,800 --> 01:05:15,440
Fabric sits above that operational record
1812
01:05:15,440 --> 01:05:17,400
and connects it to the wider business picture,
1813
01:05:17,400 --> 01:05:20,240
joining line events with order data, material records,
1814
01:05:20,240 --> 01:05:22,840
shift calendars, quality cost, energy use,
1815
01:05:22,840 --> 01:05:26,360
and other facts that help explain the consequence of lost performance.
1816
01:05:26,360 --> 01:05:29,560
A 10 minute stop doesn't carry the same impact in every case.
1817
01:05:29,560 --> 01:05:32,800
It may occur during a low priority run, with spare capacity,
1818
01:05:32,800 --> 01:05:36,720
or during the final hours of an order that has no room left before shipment.
1819
01:05:36,720 --> 01:05:38,600
The machine event stays the machine event,
1820
01:05:38,600 --> 01:05:42,520
but the business context changes how teams prioritize the response.
1821
01:05:42,520 --> 01:05:44,800
This is where real-time visibility can become useful
1822
01:05:44,800 --> 01:05:47,040
without pretending it is perfect.
1823
01:05:47,040 --> 01:05:50,000
A dashboard should show the current state, current counts,
1824
01:05:50,000 --> 01:05:53,040
active stops, and whether incoming data remains healthy
1825
01:05:53,040 --> 01:05:54,840
and it should also show uncertainty.
1826
01:05:54,840 --> 01:05:58,120
If a source is offline, if events are still queued locally,
1827
01:05:58,120 --> 01:06:01,680
or if a reason code remains pending, the display needs to say so.
1828
01:06:01,680 --> 01:06:03,320
Don't fill the gap with a clean number.
1829
01:06:03,320 --> 01:06:07,800
A dashboard that reports 87.3% OE, while the count source
1830
01:06:07,800 --> 01:06:11,400
and MES production record disagree isn't giving management clarity.
1831
01:06:11,400 --> 01:06:13,080
It's giving them a decimal place.
1832
01:06:13,080 --> 01:06:14,600
The argument should move upstream,
1833
01:06:14,600 --> 01:06:16,920
toward the source state, count logic, time boundary,
1834
01:06:16,920 --> 01:06:18,680
and ownership of the production record.
1835
01:06:18,680 --> 01:06:21,000
The same applies when one report calls a machine idle
1836
01:06:21,000 --> 01:06:23,120
while another calls it planned downtime.
1837
01:06:23,120 --> 01:06:25,840
You don't solve that by averaging the two values in fabric.
1838
01:06:25,840 --> 01:06:28,000
You define the state model, document the rule,
1839
01:06:28,000 --> 01:06:30,560
and keep the source facts visible enough to test it.
1840
01:06:30,560 --> 01:06:32,320
Real-time visibility means you can see
1841
01:06:32,320 --> 01:06:34,320
what the process currently reports,
1842
01:06:34,320 --> 01:06:36,360
how confident the system is in that record,
1843
01:06:36,360 --> 01:06:37,840
and where the data came from.
1844
01:06:37,840 --> 01:06:39,800
It doesn't mean every chart deserves blind trust
1845
01:06:39,800 --> 01:06:41,560
because it updates every few seconds.
1846
01:06:41,560 --> 01:06:44,640
Once that foundation is in place, OE can help teams find
1847
01:06:44,640 --> 01:06:46,880
the right questions instead of producing another screen
1848
01:06:46,880 --> 01:06:49,240
everyone argues about during the morning meeting.
1849
01:06:49,240 --> 01:06:52,000
And scheduling needs a different type of decision boundary.
1850
01:06:52,000 --> 01:06:54,960
APS ERP, MES, and the decision horizon.
1851
01:06:54,960 --> 01:06:57,840
Scheduling starts to break down when you expect one system
1852
01:06:57,840 --> 01:06:59,360
to answer every question.
1853
01:06:59,360 --> 01:07:00,960
ERP keeps the business facts.
1854
01:07:00,960 --> 01:07:03,840
It tracks orders entered, inventory received or consumed,
1855
01:07:03,840 --> 01:07:05,880
purchase activity, production confirmations,
1856
01:07:05,880 --> 01:07:07,720
and cost and financial records.
1857
01:07:07,720 --> 01:07:09,840
It tells the company what it committed to,
1858
01:07:09,840 --> 01:07:12,000
what moved, and what closed.
1859
01:07:12,000 --> 01:07:14,440
That record matters, but it doesn't run a line.
1860
01:07:14,440 --> 01:07:16,640
APS, advance planning and scheduling,
1861
01:07:16,640 --> 01:07:18,000
works with a different question.
1862
01:07:18,000 --> 01:07:20,440
It looks forward asking what plan can still work
1863
01:07:20,440 --> 01:07:23,000
given demand, available capacity, material limits,
1864
01:07:23,000 --> 01:07:25,000
labor, changeover rules, maintenance windows,
1865
01:07:25,000 --> 01:07:26,240
and routing choices.
1866
01:07:26,240 --> 01:07:27,440
A plan is not a command.
1867
01:07:27,440 --> 01:07:29,480
APS can test whether an urgent order fits
1868
01:07:29,480 --> 01:07:32,360
before a promised chip date, and it can show the knock-on effect
1869
01:07:32,360 --> 01:07:34,600
of moving a job from one line to another.
1870
01:07:34,600 --> 01:07:37,360
It can also compare options when a material delivery slips
1871
01:07:37,360 --> 01:07:39,840
or a bottleneck asset loses capacity.
1872
01:07:39,840 --> 01:07:42,240
The output is a feasible future scenario based
1873
01:07:42,240 --> 01:07:44,560
on the constraints it knows, at that point.
1874
01:07:44,560 --> 01:07:47,560
MES sits between that plan and the physical work.
1875
01:07:47,560 --> 01:07:49,440
It dispatches work to the shop floor,
1876
01:07:49,440 --> 01:07:51,840
tracks work in progress, records completion,
1877
01:07:51,840 --> 01:07:54,480
and applies the production rules that belong to execution.
1878
01:07:54,480 --> 01:07:56,280
If an order moves through several operations,
1879
01:07:56,280 --> 01:07:57,920
a mess keeps track of where it is,
1880
01:07:57,920 --> 01:08:00,120
what quantity passed, what quantity failed,
1881
01:08:00,120 --> 01:08:02,640
and what still needs to happen before the order can close.
1882
01:08:02,640 --> 01:08:04,400
The edge sees a much shorter horizon.
1883
01:08:04,400 --> 01:08:06,560
It sees that a machine is faulted now,
1884
01:08:06,560 --> 01:08:09,000
that a conveyor is blocked, that a tool change is taking
1885
01:08:09,000 --> 01:08:11,520
longer than expected, or that a station can't accept
1886
01:08:11,520 --> 01:08:12,200
the next part.
1887
01:08:12,200 --> 01:08:14,880
Those facts can change fast, and they are not always
1888
01:08:14,880 --> 01:08:17,160
visible in a planning model until someone sends them
1889
01:08:17,160 --> 01:08:18,720
upward in a usable form.
1890
01:08:18,720 --> 01:08:21,480
Consider a line that loses a filler halfway through a shift.
1891
01:08:21,480 --> 01:08:23,000
The local systems detect the fault
1892
01:08:23,000 --> 01:08:25,440
and the line enters its defined response state.
1893
01:08:25,440 --> 01:08:27,280
Operators work the immediate problem,
1894
01:08:27,280 --> 01:08:29,840
while MES records the disruption against the active operation
1895
01:08:29,840 --> 01:08:31,760
and work order once the event has enough context
1896
01:08:31,760 --> 01:08:33,160
to be recorded properly.
1897
01:08:33,160 --> 01:08:35,640
That event can trigger planning questions upstream.
1898
01:08:35,640 --> 01:08:38,320
Can the remaining line capacity still complete the order?
1899
01:08:38,320 --> 01:08:40,080
Should another line take part of the volume,
1900
01:08:40,080 --> 01:08:42,880
does the change create a material issue later in the route?
1901
01:08:42,880 --> 01:08:44,840
Is there a maintenance window that now needs to move?
1902
01:08:44,840 --> 01:08:47,040
APS can test those options against the wider schedule
1903
01:08:47,040 --> 01:08:49,280
because it sees constraints the line itself doesn't.
1904
01:08:49,280 --> 01:08:52,040
But the plan must come back down as a proposal for execution,
1905
01:08:52,040 --> 01:08:53,760
not as a remote hand on the machine.
1906
01:08:53,760 --> 01:08:55,920
A central system may decide that order 4/7
1907
01:08:55,920 --> 01:08:57,800
should move to another work center.
1908
01:08:57,800 --> 01:08:59,640
But before that change reaches the floor,
1909
01:08:59,640 --> 01:09:02,480
MES needs to check whether the order is released,
1910
01:09:02,480 --> 01:09:05,560
whether the material is available, whether the recipe applies,
1911
01:09:05,560 --> 01:09:07,120
whether the work center can run it,
1912
01:09:07,120 --> 01:09:10,400
and whether the current production state allows a safe handoff.
1913
01:09:10,400 --> 01:09:12,520
The edge needs to confirm the local conditions too.
1914
01:09:12,520 --> 01:09:14,560
It checks whether the machine is actually available,
1915
01:09:14,560 --> 01:09:16,520
whether a changeover is in progress,
1916
01:09:16,520 --> 01:09:18,720
whether there is still product in the line,
1917
01:09:18,720 --> 01:09:21,720
and whether the operator has completed the required checks.
1918
01:09:21,720 --> 01:09:23,000
A plan built at 10 and 2 arc
1919
01:09:23,000 --> 01:09:26,040
can already be wrong at 10/07 if the local state changed.
1920
01:09:26,040 --> 01:09:29,000
This is where cloud first scheduling ideas become risky.
1921
01:09:29,000 --> 01:09:30,920
A cloud planner may have good information
1922
01:09:30,920 --> 01:09:32,560
about demand and capacity,
1923
01:09:32,560 --> 01:09:35,040
but it should not issue direct machine command simply
1924
01:09:35,040 --> 01:09:37,000
because it found a better schedule.
1925
01:09:37,000 --> 01:09:38,560
Machines don't execute schedules,
1926
01:09:38,560 --> 01:09:40,160
they execute validated sequences
1927
01:09:40,160 --> 01:09:41,800
under current physical conditions.
1928
01:09:41,800 --> 01:09:43,440
The controller owns the machine sequence
1929
01:09:43,440 --> 01:09:45,120
while the edge reports local state
1930
01:09:45,120 --> 01:09:48,320
and applies only the local logic it has been approved to apply.
1931
01:09:48,320 --> 01:09:51,760
MES owns execution workflow and work in progress records.
1932
01:09:51,760 --> 01:09:54,280
APS evaluates future options across constraints.
1933
01:09:54,280 --> 01:09:56,640
ERP remains the business system of record.
1934
01:09:56,640 --> 01:09:58,480
Those roles can exchange information quickly
1935
01:09:58,480 --> 01:10:00,680
without becoming the same system.
1936
01:10:00,680 --> 01:10:03,000
A useful rescheduling loop looks like this.
1937
01:10:03,000 --> 01:10:04,400
A local disruption occurs,
1938
01:10:04,400 --> 01:10:06,280
the edge and plant systems capture the facts
1939
01:10:06,280 --> 01:10:08,000
with the right time and asset context.
1940
01:10:08,000 --> 01:10:10,040
MES records the execution impact.
1941
01:10:10,040 --> 01:10:13,440
APS receives a planning relevant event, tests alternatives,
1942
01:10:13,440 --> 01:10:16,080
and returns a revised plan or dispatch priority,
1943
01:10:16,080 --> 01:10:18,960
and MES validates that plan against the live execution
1944
01:10:18,960 --> 01:10:21,320
state before work changes on the floor.
1945
01:10:21,320 --> 01:10:23,760
That may sound slower than letting the cloud control everything,
1946
01:10:23,760 --> 01:10:26,280
but it is safer, easier to explain and far less likely
1947
01:10:26,280 --> 01:10:28,080
to produce a schedule that looks perfect
1948
01:10:28,080 --> 01:10:29,560
while the plant cannot run it.
1949
01:10:29,560 --> 01:10:31,840
There is also a human decision in this path.
1950
01:10:31,840 --> 01:10:33,800
A plan may accept the proposed change,
1951
01:10:33,800 --> 01:10:36,000
but a production supervisor may reject it
1952
01:10:36,000 --> 01:10:38,240
because a line carries a quality hold,
1953
01:10:38,240 --> 01:10:40,440
a changeover would create too much loss,
1954
01:10:40,440 --> 01:10:43,320
or the local crew lacks the needed skill.
1955
01:10:43,320 --> 01:10:45,840
Planning systems should expose those trade-offs,
1956
01:10:45,840 --> 01:10:47,960
not hide them behind an automatic instruction
1957
01:10:47,960 --> 01:10:50,800
that appears on the screen after the useful moment passed.
1958
01:10:50,800 --> 01:10:53,840
The same separation appears when people talk about digital twins.
1959
01:10:53,840 --> 01:10:56,120
A twin needs live-state close to the process,
1960
01:10:56,120 --> 01:10:58,920
but it also needs a place to reason across relationships,
1961
01:10:58,920 --> 01:11:00,440
history, and possible futures.