Your Factory Cloud Bill Is Much Higher Than You Think

1
00:00:00,000 --> 00:00:02,880
Here's the problem, most manufacturers don't talk about.

2
00:00:02,880 --> 00:00:05,480
The IoT architecture diagram always looks clean.

3
00:00:05,480 --> 00:00:07,680
Senses sit at the bottom, a gateway in the middle,

4
00:00:07,680 --> 00:00:09,200
one neat arrow up to the cloud,

5
00:00:09,200 --> 00:00:11,440
and then dashboards and AI at the top.

6
00:00:11,440 --> 00:00:13,880
Storage looks cheap, so the plan feels obvious.

7
00:00:13,880 --> 00:00:15,160
Just send it all.

8
00:00:15,160 --> 00:00:18,360
But then dashboards multiply, analysts start exporting data,

9
00:00:18,360 --> 00:00:20,760
someone adds a second region for disaster recovery,

10
00:00:20,760 --> 00:00:22,840
remote teams pull files back to the plant,

11
00:00:22,840 --> 00:00:24,720
and pretty soon the bill starts carrying charges

12
00:00:24,720 --> 00:00:26,600
that nobody put in the first budget.

13
00:00:26,600 --> 00:00:27,960
It's not because the cloud failed,

14
00:00:27,960 --> 00:00:29,880
it's because that data path was never treated

15
00:00:29,880 --> 00:00:32,040
as part of the architecture in the first place.

16
00:00:32,040 --> 00:00:34,880
So the question isn't, can this data go to the cloud?

17
00:00:34,880 --> 00:00:36,480
It's what data earns that trip.

18
00:00:36,480 --> 00:00:37,920
Let's put a real cost model around it

19
00:00:37,920 --> 00:00:40,960
and build an edge first pattern that actually scales.

20
00:00:40,960 --> 00:00:43,640
Start with the charge most diagrams leave out.

21
00:00:43,640 --> 00:00:46,240
Egress is a boundary charge, not a storage charge.

22
00:00:46,240 --> 00:00:48,840
People often mix up storage cost and data movement cost

23
00:00:48,840 --> 00:00:50,840
because both show up on the same invoice,

24
00:00:50,840 --> 00:00:52,680
but they're completely different things.

25
00:00:52,680 --> 00:00:55,520
Ingress means data enters a cloud provider's network.

26
00:00:55,520 --> 00:00:57,880
A sensor gateway in the factory sends a payload

27
00:00:57,880 --> 00:01:01,280
to a cloud endpoint and that payload crosses into the provider.

28
00:01:01,280 --> 00:01:03,200
Major cloud providers commonly charge little

29
00:01:03,200 --> 00:01:04,480
on nothing for this direction,

30
00:01:04,480 --> 00:01:07,960
which is why cloud first data collection feels cheap at the start.

31
00:01:07,960 --> 00:01:11,360
Egress on the other hand means data leaves a network boundary.

32
00:01:11,360 --> 00:01:13,920
Maybe a cloud server sends a file to a plant server,

33
00:01:13,920 --> 00:01:15,920
a report goes to a user's browser

34
00:01:15,920 --> 00:01:18,200
or a data set travels to another region.

35
00:01:18,200 --> 00:01:21,080
And that movement may carry a per gigabyte charge

36
00:01:21,080 --> 00:01:22,480
that word boundary matters.

37
00:01:22,480 --> 00:01:23,960
Your factory boundary is one.

38
00:01:23,960 --> 00:01:25,680
The cloud provider boundary is another.

39
00:01:25,680 --> 00:01:27,480
A cloud region can be a boundary

40
00:01:27,480 --> 00:01:30,920
and separate availability zones inside one region can be boundaries too.

41
00:01:30,920 --> 00:01:35,160
Even a routing service in the middle may process every byte and charge for doing it.

42
00:01:35,160 --> 00:01:38,360
Picture a plant connector sending machine data into a cloud tenant.

43
00:01:38,360 --> 00:01:39,440
That's one path.

44
00:01:39,440 --> 00:01:43,440
Later, an engineer downloads raw data for root cause work to an on-prem tool

45
00:01:43,440 --> 00:01:45,000
so data travels back out.

46
00:01:45,000 --> 00:01:48,640
A disaster recovery setup copies the same data to a second region.

47
00:01:48,640 --> 00:01:49,840
Another path.

48
00:01:49,840 --> 00:01:53,400
A service deployed in a different zone reads it from a database replica

49
00:01:53,400 --> 00:01:55,200
crossing yet another boundary.

50
00:01:55,200 --> 00:01:59,200
The original telemetry didn't get more useful just because it crossed four places

51
00:01:59,200 --> 00:02:01,480
but it may have become more expensive four times.

52
00:02:01,480 --> 00:02:04,440
This catches teams because storage has a simple mental model.

53
00:02:04,440 --> 00:02:06,040
You store one terabyte for a month,

54
00:02:06,040 --> 00:02:08,200
you pay a price for one terabyte for a month.

55
00:02:08,200 --> 00:02:10,080
Network traffic doesn't behave like that.

56
00:02:10,080 --> 00:02:13,520
It follows use, routing, retries, replicas, exports,

57
00:02:13,520 --> 00:02:15,520
and architecture choices made by teams

58
00:02:15,520 --> 00:02:18,000
who may never see the network line items.

59
00:02:18,000 --> 00:02:20,840
A low storage bill can sit beside a high transfer bill,

60
00:02:20,840 --> 00:02:22,040
and that isn't strange.

61
00:02:22,040 --> 00:02:24,960
It's a normal result when data moves often and storage stays

62
00:02:24,960 --> 00:02:26,080
relatively cheap.

63
00:02:26,080 --> 00:02:28,560
Think of the network as a set of meter pipes.

64
00:02:28,560 --> 00:02:31,320
Each pipe has a source, a destination, a root, and a rate.

65
00:02:31,320 --> 00:02:35,560
The diagram line between an IoT platform and a data lake isn't just an integration.

66
00:02:35,560 --> 00:02:37,440
It's a pipe carrying bytes all day,

67
00:02:37,440 --> 00:02:39,840
whether those bytes support a decision or not.

68
00:02:39,840 --> 00:02:42,000
Internet egress is the familiar case.

69
00:02:42,000 --> 00:02:45,520
Data leaves the provider and moves across the public internet, perhaps to an office,

70
00:02:45,520 --> 00:02:48,320
supplier, customer portal, or plant network.

71
00:02:48,320 --> 00:02:51,640
Private connectivity changes the root and may change the commercial terms

72
00:02:51,640 --> 00:02:53,880
but it doesn't mean movement becomes free.

73
00:02:53,880 --> 00:02:57,240
You still need to understand the circuit, the traffic direction, and the price plan.

74
00:02:57,240 --> 00:03:00,960
Cross-region transfer happens when data moves from one cloud region to another.

75
00:03:00,960 --> 00:03:05,480
Teams use this for recovery, geographic access, or data residency plans.

76
00:03:05,480 --> 00:03:08,880
Those can be good reasons, but they still need an explicit traffic model

77
00:03:08,880 --> 00:03:13,760
because a continuous stream replicated across regions becomes a continuous charge.

78
00:03:13,760 --> 00:03:15,960
Cross-zone transfers it's closer to the workload.

79
00:03:15,960 --> 00:03:19,480
You might deploy services across zones for resilience, which is sensible,

80
00:03:19,480 --> 00:03:22,080
yet a broker in one zone, a processor in another,

81
00:03:22,080 --> 00:03:25,120
and storage in a third can create constant internal traffic.

82
00:03:25,120 --> 00:03:29,440
The cloud may look like one place on the slide, but physically and commercially, it isn't one place.

83
00:03:29,440 --> 00:03:32,200
None of this means you should avoid redundancy, private links,

84
00:03:32,200 --> 00:03:34,200
cloud analytics, or remote access.

85
00:03:34,200 --> 00:03:36,000
It just means each path needs a reason.

86
00:03:36,000 --> 00:03:39,840
Resilience has a cost, shared access has a cost, central analytics has a cost,

87
00:03:39,840 --> 00:03:41,360
those costs may be worth paying,

88
00:03:41,360 --> 00:03:44,360
but only after you know what crosses the boundary and why.

89
00:03:44,360 --> 00:03:48,000
In practical terms, stop asking only where data is stored.

90
00:03:48,000 --> 00:03:50,280
Start asking where it travels after storage,

91
00:03:50,280 --> 00:03:52,400
who consumes it and how often they need it.

92
00:03:52,400 --> 00:03:55,880
A data flow without a destination and a decision is just an open meter,

93
00:03:55,880 --> 00:03:58,360
so let's follow one machine signal through that meter.

94
00:03:58,360 --> 00:04:00,400
The factory data path is rarely one way.

95
00:04:00,400 --> 00:04:03,440
Take a normal machine signal, maybe a spindle vibration reading,

96
00:04:03,440 --> 00:04:05,800
or a simple state tag from a packaging line.

97
00:04:05,800 --> 00:04:08,760
An edge gateway publishes it to the cloud through MQTT

98
00:04:08,760 --> 00:04:13,680
and the project team checks the box, connected, but connected to what exactly.

99
00:04:13,680 --> 00:04:15,760
That first message might land in an IoT service,

100
00:04:15,760 --> 00:04:18,640
which roots a copy into time series storage for dashboards,

101
00:04:18,640 --> 00:04:21,000
another copy into a data lake for engineering work,

102
00:04:21,000 --> 00:04:23,560
and a third into an event stream for alerts.

103
00:04:23,560 --> 00:04:26,360
Each destination has a different team, a different retention rule,

104
00:04:26,360 --> 00:04:28,880
and usually a different idea of what the data is actually for.

105
00:04:28,880 --> 00:04:30,960
The stream keeps branching.

106
00:04:30,960 --> 00:04:33,520
A production manager opens a dashboard from the plant,

107
00:04:33,520 --> 00:04:36,440
a reliability engineer queries history from a laptop,

108
00:04:36,440 --> 00:04:39,040
a data team pulls a training set into a notebook,

109
00:04:39,040 --> 00:04:41,400
a supplier receives an extract through an API

110
00:04:41,400 --> 00:04:44,200
because their service agreement requires machine evidence.

111
00:04:44,200 --> 00:04:46,560
None of those uses sound unreasonable on their own.

112
00:04:46,560 --> 00:04:50,400
They put them together and one sensor feed turns into several active data flows.

113
00:04:50,400 --> 00:04:54,600
This is where the phrase, "We only send one MQTT stream becomes misleading."

114
00:04:54,600 --> 00:04:58,000
MQTT describes a message path between a publisher and a broker.

115
00:04:58,000 --> 00:05:00,080
It doesn't describe every subscriber, storage ride,

116
00:05:00,080 --> 00:05:02,480
replication job, export process, or downstream tool

117
00:05:02,480 --> 00:05:04,560
that touches the message after it arrives.

118
00:05:04,560 --> 00:05:07,040
The connection may be one stream from the factory,

119
00:05:07,040 --> 00:05:10,160
while the cloud estate creates many copies from that stream.

120
00:05:10,160 --> 00:05:12,200
Think about a line that produces status events,

121
00:05:12,200 --> 00:05:15,440
the cloud stores the events, then a reporting workload reads them,

122
00:05:15,440 --> 00:05:17,680
another job joins them to MS order data.

123
00:05:17,680 --> 00:05:20,840
A data science team copies a subset to another workspace.

124
00:05:20,840 --> 00:05:22,880
Later, somebody exports an investigation file

125
00:05:22,880 --> 00:05:25,320
because a customer asks why a batch was delayed.

126
00:05:25,320 --> 00:05:27,040
The machine generated the data once.

127
00:05:27,040 --> 00:05:28,680
The architecture moved it many times.

128
00:05:28,680 --> 00:05:31,520
Return traffic is easy to miss because it often starts later

129
00:05:31,520 --> 00:05:34,400
after the original IoT project has already gone live.

130
00:05:34,400 --> 00:05:37,360
The plant may retrieve cloud hosted reports each shift.

131
00:05:37,360 --> 00:05:39,440
A local application may pull reference data,

132
00:05:39,440 --> 00:05:42,040
thresholds, or model packages from a central service.

133
00:05:42,040 --> 00:05:45,000
Remote support staff may download logs and evidence files.

134
00:05:45,000 --> 00:05:47,640
A cloud dashboard viewed on a large screen in the control room

135
00:05:47,640 --> 00:05:49,720
is still a data path back into the site.

136
00:05:49,720 --> 00:05:51,440
Backups create their own return path.

137
00:05:51,440 --> 00:05:53,800
You may send plant data to the cloud for attention.

138
00:05:53,800 --> 00:05:55,960
Looks tidy during normal operation.

139
00:05:55,960 --> 00:05:58,880
Then a restore test begins, or a real incident forces the team

140
00:05:58,880 --> 00:06:00,960
to retrieve a large archive back to the factory

141
00:06:00,960 --> 00:06:01,840
or another environment.

142
00:06:01,840 --> 00:06:05,000
Recovery needs that data to move in the opposite direction

143
00:06:05,000 --> 00:06:07,000
at the moment when people are already under pressure.

144
00:06:07,000 --> 00:06:08,440
That's not an argument against backup.

145
00:06:08,440 --> 00:06:10,320
It's an argument for treating recovery

146
00:06:10,320 --> 00:06:12,480
like a real workload instead of a sentence

147
00:06:12,480 --> 00:06:13,640
in a policy document.

148
00:06:13,640 --> 00:06:15,600
Separate projects create another problem.

149
00:06:15,600 --> 00:06:17,840
The maintenance group installs a condition monitoring

150
00:06:17,840 --> 00:06:18,480
platform.

151
00:06:18,480 --> 00:06:20,600
The quality team builds a vision archive.

152
00:06:20,600 --> 00:06:23,840
Corporate IT creates a data platform for enterprise reporting.

153
00:06:23,840 --> 00:06:25,880
Each project connects to the same shop floor,

154
00:06:25,880 --> 00:06:29,280
often through its own collector, gateway, or vendor portal.

155
00:06:29,280 --> 00:06:30,920
Nobody intended to duplicate the data.

156
00:06:30,920 --> 00:06:33,320
Nobody sat in a room and chose to pay for the same machine

157
00:06:33,320 --> 00:06:34,680
state three times.

158
00:06:34,680 --> 00:06:36,560
Yet the result can be three parallel paths,

159
00:06:36,560 --> 00:06:38,800
each with its own credentials, cloud storage,

160
00:06:38,800 --> 00:06:40,360
exports, and support burden.

161
00:06:40,360 --> 00:06:42,800
Picture a plant with one PLC network and three teams

162
00:06:42,800 --> 00:06:44,680
asking for real time visibility.

163
00:06:44,680 --> 00:06:47,680
One collects tags for OEE, one pulls them for maintenance,

164
00:06:47,680 --> 00:06:49,480
one forwards them for a digital twin pilot.

165
00:06:49,480 --> 00:06:52,000
If they don't share a data model and a governed route,

166
00:06:52,000 --> 00:06:54,360
the plant becomes the source for three separate pipes.

167
00:06:54,360 --> 00:06:55,760
The cloud bill isn't the only cost.

168
00:06:55,760 --> 00:06:58,400
You also lose confidence when the three systems disagree.

169
00:06:58,400 --> 00:07:00,080
This is the part that gets uncomfortable.

170
00:07:00,080 --> 00:07:02,160
Data duplication rarely comes from bad intent

171
00:07:02,160 --> 00:07:04,000
or poor engineering in a single team.

172
00:07:04,000 --> 00:07:06,680
It comes from local success without shared architecture.

173
00:07:06,680 --> 00:07:08,720
Each team solves its immediate problem.

174
00:07:08,720 --> 00:07:11,080
And the full path only becomes visible when finance

175
00:07:11,080 --> 00:07:12,800
asks why network charge is climbed.

176
00:07:12,800 --> 00:07:15,880
So don't count connections, count movement.

177
00:07:15,880 --> 00:07:18,040
For every signal, list the original source,

178
00:07:18,040 --> 00:07:20,880
each processing hop, every copy, and every consumer.

179
00:07:20,880 --> 00:07:23,400
Include the dashboard, someone refreshes all day,

180
00:07:23,400 --> 00:07:25,440
the scheduled export that runs overnight,

181
00:07:25,440 --> 00:07:28,080
the data set copied for analysis, and the recovery workflow

182
00:07:28,080 --> 00:07:29,920
nobody has tested recently.

183
00:07:29,920 --> 00:07:33,040
That becomes the real unit of analysis, not a device,

184
00:07:33,040 --> 00:07:35,200
not a topic, not even a data lake.

185
00:07:35,200 --> 00:07:37,240
Each copy, each hop, and each consumer.

186
00:07:37,240 --> 00:07:39,600
Once you see the path that way, public pricing

187
00:07:39,600 --> 00:07:41,920
stops looking like a minor technical detail.

188
00:07:41,920 --> 00:07:44,080
Put those rates next to the actual volume,

189
00:07:44,080 --> 00:07:46,880
and the numbers start changing the design conversation set.

190
00:07:46,880 --> 00:07:49,360
Public pricing is only the starting point.

191
00:07:49,360 --> 00:07:51,720
Before we turn this into a spreadsheet exercise,

192
00:07:51,720 --> 00:07:53,320
use public prices for what they are,

193
00:07:53,320 --> 00:07:55,680
a warning sign, not a forecast.

194
00:07:55,680 --> 00:07:58,080
For a common reference point, AWS Internet egress

195
00:07:58,080 --> 00:08:00,480
from some regions starts around nine cents per gigabyte

196
00:08:00,480 --> 00:08:01,760
in its first volume tier.

197
00:08:01,760 --> 00:08:04,520
Azure Zone one lists roughly 8.7 cents per gigabyte

198
00:08:04,520 --> 00:08:06,200
beyond its included allowance.

199
00:08:06,200 --> 00:08:08,440
Google Cloud uses tiered rates too,

200
00:08:08,440 --> 00:08:10,400
and the rate depends on where the data starts

201
00:08:10,400 --> 00:08:11,520
and where it lands.

202
00:08:11,520 --> 00:08:13,320
Those numbers look small because they are small

203
00:08:13,320 --> 00:08:14,400
at the unit level.

204
00:08:14,400 --> 00:08:16,320
A single gigabyte at nine cents won't trigger

205
00:08:16,320 --> 00:08:18,600
an executive meeting, but factory data

206
00:08:18,600 --> 00:08:20,360
doesn't arrive as a single gigabyte.

207
00:08:20,360 --> 00:08:22,800
It arrives every second through every shift

208
00:08:22,800 --> 00:08:24,360
across every connected asset,

209
00:08:24,360 --> 00:08:27,680
and often it keeps moving long after the machine created it.

210
00:08:27,680 --> 00:08:29,840
Take a stream that sends 100 gigabytes per day

211
00:08:29,840 --> 00:08:31,760
out of a cloud environment to plant users

212
00:08:31,760 --> 00:08:34,040
a supplier or another external system.

213
00:08:34,040 --> 00:08:36,520
At a simple nine cents per gigabyte reference rate,

214
00:08:36,520 --> 00:08:39,200
that one path reaches about nine dollars per day.

215
00:08:39,200 --> 00:08:42,200
Over 30-day months, that's about $270.

216
00:08:42,200 --> 00:08:44,240
Then add another plant, another data consumer,

217
00:08:44,240 --> 00:08:46,560
another region, or an export job

218
00:08:46,560 --> 00:08:48,640
that nobody sees as a network workload.

219
00:08:48,640 --> 00:08:51,400
The unit rate didn't change, the architecture did.

220
00:08:51,400 --> 00:08:53,160
And that is only internet bound traffic.

221
00:08:53,160 --> 00:08:54,240
You may pay a different rate

222
00:08:54,240 --> 00:08:56,400
when traffic moves between cloud regions.

223
00:08:56,400 --> 00:08:57,480
You may face a separate rate

224
00:08:57,480 --> 00:09:00,400
when services exchange data across availability zones

225
00:09:00,400 --> 00:09:01,320
within a region.

226
00:09:01,320 --> 00:09:04,160
A private connection can change the commercial model again.

227
00:09:04,160 --> 00:09:07,080
A managed service may include its own data transfer rules

228
00:09:07,080 --> 00:09:09,080
and a gateway can introduce a processing charge

229
00:09:09,080 --> 00:09:10,880
on top of the underlying network route.

230
00:09:10,880 --> 00:09:12,280
So don't take a generic public rate,

231
00:09:12,280 --> 00:09:14,280
multiply it once and call it the budget.

232
00:09:14,280 --> 00:09:16,800
The actual price depends on the source region destination,

233
00:09:16,800 --> 00:09:19,680
service involved, monthly volume tier, currency,

234
00:09:19,680 --> 00:09:22,000
and the commercial agreement your company signed.

235
00:09:22,000 --> 00:09:23,680
Enterprise contracts may change the rate,

236
00:09:23,680 --> 00:09:25,320
credits may hide it for a while.

237
00:09:25,320 --> 00:09:27,480
One service may include a transfer path

238
00:09:27,480 --> 00:09:29,360
that another service builds separately

239
00:09:29,360 --> 00:09:31,600
even when both sit in the same provider.

240
00:09:31,600 --> 00:09:35,080
Cloud pricing has a talent for looking simple from 30,000 feet.

241
00:09:35,080 --> 00:09:37,720
You see data transfer out on a rate card.

242
00:09:37,720 --> 00:09:39,520
Then the invoice arrives with service names,

243
00:09:39,520 --> 00:09:42,040
region codes, usage types, and charges

244
00:09:42,040 --> 00:09:44,240
that don't resemble the clean architecture diagram

245
00:09:44,240 --> 00:09:45,480
from the project kickoff.

246
00:09:45,480 --> 00:09:47,080
That's not because someone is trying to make

247
00:09:47,080 --> 00:09:49,520
the invoice unreadable, although it can feel that way.

248
00:09:49,520 --> 00:09:51,400
It's because the provider meters real routes

249
00:09:51,400 --> 00:09:52,760
and real routes have detail.

250
00:09:52,760 --> 00:09:54,480
Your invoice and contract terms decide

251
00:09:54,480 --> 00:09:55,560
what you actually spend.

252
00:09:55,560 --> 00:09:57,360
That means your finance and cloud teams

253
00:09:57,360 --> 00:09:58,480
need to look at both.

254
00:09:58,480 --> 00:10:00,960
Public pricing helps you ask the right early questions.

255
00:10:00,960 --> 00:10:02,880
It helps you spot when a proposed design

256
00:10:02,880 --> 00:10:04,640
could become expensive at scale.

257
00:10:04,640 --> 00:10:07,080
But it cannot tell you the final cost of your environment

258
00:10:07,080 --> 00:10:09,360
without the actual route, the actual volume,

259
00:10:09,360 --> 00:10:10,720
and the actual agreement.

260
00:10:10,720 --> 00:10:13,520
There is another point that often confuses project teams.

261
00:10:13,520 --> 00:10:15,480
Inbound data commonly looks free.

262
00:10:15,480 --> 00:10:17,560
While the data leaving later carries a charge,

263
00:10:17,560 --> 00:10:19,800
that creates a very predictable behavior.

264
00:10:19,800 --> 00:10:21,880
A team begins by sending raw factory data

265
00:10:21,880 --> 00:10:23,520
into the cloud because the first transfer

266
00:10:23,520 --> 00:10:24,800
doesn't hurt the budget.

267
00:10:24,800 --> 00:10:26,160
Storage also looks manageable.

268
00:10:26,160 --> 00:10:29,160
Months later, users want dashboards outside the cloud boundary,

269
00:10:29,160 --> 00:10:30,360
engineering wants extracts.

270
00:10:30,360 --> 00:10:32,560
Another environment needs a copy and operations needs

271
00:10:32,560 --> 00:10:33,800
data back at the site.

272
00:10:33,800 --> 00:10:36,560
The cost appears when the data starts serving people

273
00:10:36,560 --> 00:10:38,160
and systems in other places.

274
00:10:38,160 --> 00:10:39,600
Free inbound transfer is not proof

275
00:10:39,600 --> 00:10:41,680
that the full data lifecycle is cheap.

276
00:10:41,680 --> 00:10:44,120
It only means the first leg has a favorable rate.

277
00:10:44,120 --> 00:10:46,560
For a manufacturing architecture, that distinction

278
00:10:46,560 --> 00:10:47,880
changes how you plan.

279
00:10:47,880 --> 00:10:51,480
You don't ask only, what does it cost to ingest this telemetry?

280
00:10:51,480 --> 00:10:53,320
You ask, who reads it later?

281
00:10:53,320 --> 00:10:56,600
From where, in what form, and how often?

282
00:10:56,600 --> 00:10:59,160
If the answer includes a daily export of raw records,

283
00:10:59,160 --> 00:11:01,160
or frequent retrieval of high rate files,

284
00:11:01,160 --> 00:11:03,320
the low cost ingest path tells you almost nothing

285
00:11:03,320 --> 00:11:04,960
about the total network cost.

286
00:11:04,960 --> 00:11:07,560
This is why provider arguments often start too early.

287
00:11:07,560 --> 00:11:10,520
Teams compare AWS, Azure, and Google Cloud rates

288
00:11:10,520 --> 00:11:12,160
before they have measured the data.

289
00:11:12,160 --> 00:11:15,720
They debate whether 7.8 or 9 cents per gigabyte is better,

290
00:11:15,720 --> 00:11:17,720
while the architecture still sends a stream

291
00:11:17,720 --> 00:11:20,760
that no named user needs in raw form.

292
00:11:20,760 --> 00:11:23,360
Saving a fraction of a cent on unnecessary movement

293
00:11:23,360 --> 00:11:24,880
is still unnecessary movement.

294
00:11:24,880 --> 00:11:26,880
If you first calculate the volume, then calculate

295
00:11:26,880 --> 00:11:28,840
the shape of that volume over time.

296
00:11:28,840 --> 00:11:31,440
Only after that should you compare providers, contracts,

297
00:11:31,440 --> 00:11:33,360
routes, and services.

298
00:11:33,360 --> 00:11:36,280
The unit error, counting devices instead of samples.

299
00:11:36,280 --> 00:11:38,600
When teams estimate factory data volume,

300
00:11:38,600 --> 00:11:40,440
they almost always start with the wrong number.

301
00:11:40,440 --> 00:11:41,880
They count devices.

302
00:11:41,880 --> 00:11:45,960
We have 400 machines, or we're connecting 12,000 tags.

303
00:11:45,960 --> 00:11:47,240
That tells you something about scope,

304
00:11:47,240 --> 00:11:49,400
but it tells you almost nothing about the actual bytes

305
00:11:49,400 --> 00:11:51,120
your architecture will move in store.

306
00:11:51,120 --> 00:11:52,400
Start with the signal itself.

307
00:11:52,400 --> 00:11:53,320
What's the sample rate?

308
00:11:53,320 --> 00:11:54,520
How big is each payload?

309
00:11:54,520 --> 00:11:56,120
How many channels sit behind that device?

310
00:11:56,120 --> 00:11:58,480
Does the signal run all day, only during production,

311
00:11:58,480 --> 00:11:59,960
or only when an event happens?

312
00:11:59,960 --> 00:12:02,120
Then ask how long you keep it at each layer?

313
00:12:02,120 --> 00:12:04,360
Those inputs determine your real volume.

314
00:12:04,360 --> 00:12:06,640
A status bit once per minute is practically free

315
00:12:06,640 --> 00:12:07,800
from a data point of view.

316
00:12:07,800 --> 00:12:09,920
You might record whether a conveyor is running,

317
00:12:09,920 --> 00:12:11,840
stopped, starved, or blocked.

318
00:12:11,840 --> 00:12:14,160
That record can carry a timestamp and asset ID,

319
00:12:14,160 --> 00:12:16,080
a state value, and a quality flag.

320
00:12:16,080 --> 00:12:17,680
Useful data, but low volume.

321
00:12:17,680 --> 00:12:19,240
Now compare that to a vibration sensor

322
00:12:19,240 --> 00:12:21,440
capturing a waveform at kilohertz rates.

323
00:12:21,440 --> 00:12:23,920
That sensor may look like one device in your asset list,

324
00:12:23,920 --> 00:12:25,840
right beside the conveyor status tag.

325
00:12:25,840 --> 00:12:28,440
Yet it produces a continuous stream of samples,

326
00:12:28,440 --> 00:12:29,920
often across several channels,

327
00:12:29,920 --> 00:12:32,400
with a very different storage and network profile,

328
00:12:32,400 --> 00:12:35,400
same number of devices, completely different data volume.

329
00:12:35,400 --> 00:12:37,840
That's why device count is a dangerous planning unit.

330
00:12:37,840 --> 00:12:40,240
A factory with 100 low rate state signals

331
00:12:40,240 --> 00:12:42,520
may produce less traffic than one machine fitted

332
00:12:42,520 --> 00:12:44,240
with high rate condition monitoring.

333
00:12:44,240 --> 00:12:47,520
If you use device count as the basis for a cloud budget,

334
00:12:47,520 --> 00:12:49,520
you can be wrong by several orders of magnitude

335
00:12:49,520 --> 00:12:51,400
before the project even starts.

336
00:12:51,400 --> 00:12:52,600
Here's the basic formula.

337
00:12:52,600 --> 00:12:55,000
Samples times bytes times times assets,

338
00:12:55,000 --> 00:12:56,400
that's the first calculation.

339
00:12:56,400 --> 00:12:58,320
You can expand it when you need more detail,

340
00:12:58,320 --> 00:12:59,360
but don't skip it.

341
00:12:59,360 --> 00:13:01,920
For each signal, take the number of samples per second.

342
00:13:01,920 --> 00:13:03,880
Multiply that by the payload size in bytes.

343
00:13:03,880 --> 00:13:06,360
Multiply again by the number of seconds the signal runs,

344
00:13:06,360 --> 00:13:09,240
then multiply by the number of assets that produce it.

345
00:13:09,240 --> 00:13:12,000
If one device has several channels, include them too.

346
00:13:12,000 --> 00:13:14,760
A three axis accelerometer isn't one stream in practical terms,

347
00:13:14,760 --> 00:13:17,640
it is three measurements, often sampled at the same rate.

348
00:13:17,640 --> 00:13:18,800
Let's keep this grounded.

349
00:13:18,800 --> 00:13:22,040
A machine state signal might send one record every few seconds,

350
00:13:22,040 --> 00:13:23,520
or only when the state changes.

351
00:13:23,520 --> 00:13:25,800
A temperature reading might arrive once each minute.

352
00:13:25,800 --> 00:13:27,000
Those are time series records,

353
00:13:27,000 --> 00:13:29,840
but they usually stay manageable because their cadence is low.

354
00:13:29,840 --> 00:13:32,040
High rate waveform capture is different.

355
00:13:32,040 --> 00:13:34,320
It records the shape of a signal over time.

356
00:13:34,320 --> 00:13:36,280
That matters when you need to see a bearing defect,

357
00:13:36,280 --> 00:13:38,640
a resonance pattern or a transient event

358
00:13:38,640 --> 00:13:40,000
that an average value would hide.

359
00:13:40,000 --> 00:13:41,880
The data can be useful, but you must budget it

360
00:13:41,880 --> 00:13:44,120
as a continuous stream, not as another tag.

361
00:13:44,120 --> 00:13:45,360
Then you have images in video.

362
00:13:45,360 --> 00:13:48,120
A vision station might create one image for each inspected part,

363
00:13:48,120 --> 00:13:49,760
perhaps more than one camera angle.

364
00:13:49,760 --> 00:13:51,520
A camera used for continuous observation

365
00:13:51,520 --> 00:13:53,120
creates a very different pattern.

366
00:13:53,120 --> 00:13:55,000
Video carries a sustained payload,

367
00:13:55,000 --> 00:13:58,480
and the file size depends on frame rate, image size, codec,

368
00:13:58,480 --> 00:13:59,720
and scene activity.

369
00:13:59,720 --> 00:14:01,960
Calling both camera data tells you nothing

370
00:14:01,960 --> 00:14:03,800
useful for capacity planning.

371
00:14:03,800 --> 00:14:05,440
Logs create their own surprise.

372
00:14:05,440 --> 00:14:08,040
Normal application logs may stay small until a fault,

373
00:14:08,040 --> 00:14:10,440
a debug setting, or a loop starts generating

374
00:14:10,440 --> 00:14:12,120
far more records than expected.

375
00:14:12,120 --> 00:14:14,120
Network captures can become large very quickly

376
00:14:14,120 --> 00:14:16,160
because they preserve raw traffic.

377
00:14:16,160 --> 00:14:17,800
Model artifacts matter too.

378
00:14:17,800 --> 00:14:20,240
A trained model, a model update, or a data set used

379
00:14:20,240 --> 00:14:22,560
for testing doesn't behave like telemetry.

380
00:14:22,560 --> 00:14:25,880
It tends to move in bursts, but those bursts can still be large.

381
00:14:25,880 --> 00:14:27,840
Data type changes the question you ask.

382
00:14:27,840 --> 00:14:30,200
For event data, ask how often events occur

383
00:14:30,200 --> 00:14:32,160
and how much context each event carries.

384
00:14:32,160 --> 00:14:34,800
For time series data, ask about rate and retention.

385
00:14:34,800 --> 00:14:38,320
For images, ask about count, resolution, and compression.

386
00:14:38,320 --> 00:14:40,400
For video, ask about duration encoding

387
00:14:40,400 --> 00:14:42,680
and whether anyone needs continuous footage.

388
00:14:42,680 --> 00:14:45,160
For logs, ask what happens during an incident,

389
00:14:45,160 --> 00:14:46,440
not just on a normal day.

390
00:14:46,440 --> 00:14:48,800
For model files, ask where the model needs to run

391
00:14:48,800 --> 00:14:50,320
and how often it changes.

392
00:14:50,320 --> 00:14:53,040
The raw signal calculation also isn't the final number.

393
00:14:53,040 --> 00:14:54,760
Real systems add overhead.

394
00:14:54,760 --> 00:14:57,040
Every message needs more than the sensor value.

395
00:14:57,040 --> 00:15:01,240
You may attach a timestamp, topic name, device ID, asset hierarchy,

396
00:15:01,240 --> 00:15:04,480
unit, quality code, schema version, and security data.

397
00:15:04,480 --> 00:15:07,000
For very small payloads, that surrounding information

398
00:15:07,000 --> 00:15:08,880
can outweigh the measurement itself.

399
00:15:08,880 --> 00:15:10,240
Protocols add bytes as well.

400
00:15:10,240 --> 00:15:12,520
Headers, framing, encryption, acknowledgments,

401
00:15:12,520 --> 00:15:15,120
and keep alive messages all consume network capacity.

402
00:15:15,120 --> 00:15:16,640
This doesn't make the protocol wrong.

403
00:15:16,640 --> 00:15:19,760
It simply means a spreadsheet that counts only the raw sensor value

404
00:15:19,760 --> 00:15:21,120
will understate the traffic.

405
00:15:21,120 --> 00:15:24,280
Retrieves matter when a plant network or one link drops.

406
00:15:24,280 --> 00:15:26,240
Store and forward systems should retry

407
00:15:26,240 --> 00:15:28,640
because lost production records are not acceptable.

408
00:15:28,640 --> 00:15:31,720
But if the receiving side can't identify a duplicate correctly,

409
00:15:31,720 --> 00:15:34,280
one interruption can create repeated cloud rights

410
00:15:34,280 --> 00:15:35,400
for the same data.

411
00:15:35,400 --> 00:15:38,040
Duplicate collectors cause the same effect in a quieter way.

412
00:15:38,040 --> 00:15:40,800
Two systems read the same source, package it differently,

413
00:15:40,800 --> 00:15:42,480
and both send it onward.

414
00:15:42,480 --> 00:15:44,800
You need to measure payloads where they actually move.

415
00:15:44,800 --> 00:15:47,440
Not only where they originate, take a representative hour

416
00:15:47,440 --> 00:15:50,440
from a real line, capture the records by class, count messages,

417
00:15:50,440 --> 00:15:52,640
bytes, retries, and duplicate deliveries,

418
00:15:52,640 --> 00:15:55,360
then project that data across a day, a production week,

419
00:15:55,360 --> 00:15:57,480
and the number of assets you plan to connect.

420
00:15:57,480 --> 00:16:00,160
That gives you a starting point that architecture and finance

421
00:16:00,160 --> 00:16:01,080
can both use.

422
00:16:01,080 --> 00:16:03,560
And once you run that formula against vibration monitoring,

423
00:16:03,560 --> 00:16:05,200
the numbers move very fast.

424
00:16:05,200 --> 00:16:08,160
Vibration data turns small signals into terabytes.

425
00:16:08,160 --> 00:16:10,080
Let's put real numbers on one type of signal

426
00:16:10,080 --> 00:16:12,320
because vibration data exposes the planning mistake

427
00:16:12,320 --> 00:16:13,480
very quickly.

428
00:16:13,480 --> 00:16:15,720
Assume one accelerometer captures a single channel

429
00:16:15,720 --> 00:16:19,400
at 32 kilohertz, that means 32,000 samples every second.

430
00:16:19,400 --> 00:16:22,080
Assume each sample uses 16 bits or two bytes.

431
00:16:22,080 --> 00:16:25,080
The raw stream works out to 64,000 bytes per second

432
00:16:25,080 --> 00:16:28,120
before you add timestamps, message headers, encryption,

433
00:16:28,120 --> 00:16:30,720
asset context, or any other system overhead.

434
00:16:30,720 --> 00:16:34,040
Over a day, that one channel produces roughly 5.5 gigabytes

435
00:16:34,040 --> 00:16:35,640
of raw waveform data.

436
00:16:35,640 --> 00:16:37,640
One sensor, one channel, one day.

437
00:16:37,640 --> 00:16:39,520
That number doesn't sound extreme in isolation.

438
00:16:39,520 --> 00:16:42,440
You can store 5.5 gigabytes without much trouble.

439
00:16:42,440 --> 00:16:45,200
But vibration monitoring rarely stops at one sensor,

440
00:16:45,200 --> 00:16:48,800
and it rarely stays limited to one asset once a pilot proves useful.

441
00:16:48,800 --> 00:16:51,640
Put sensors on 10 motors across one production line

442
00:16:51,640 --> 00:16:53,560
using the same capture rate and format

443
00:16:53,560 --> 00:16:57,080
and you're already near 55 gigabytes per day of raw data.

444
00:16:57,080 --> 00:16:59,440
Expand that pattern across several lines,

445
00:16:59,440 --> 00:17:01,840
then across a full site, and you move into hundreds

446
00:17:01,840 --> 00:17:03,640
of gigabytes or terabytes per day

447
00:17:03,640 --> 00:17:06,680
without adding vision systems, PLC logs, quality images,

448
00:17:06,680 --> 00:17:07,760
or anything else.

449
00:17:07,760 --> 00:17:09,200
The arithmetic isn't the point.

450
00:17:09,200 --> 00:17:11,360
Not every plant samples at 32 kilohertz,

451
00:17:11,360 --> 00:17:12,960
not every sensor runs continuously.

452
00:17:12,960 --> 00:17:15,360
Some systems use lower rates, event capture,

453
00:17:15,360 --> 00:17:16,920
or device side processing.

454
00:17:16,920 --> 00:17:19,240
The point is that a small physical sensor can create

455
00:17:19,240 --> 00:17:22,240
a large digital stream when it samples fast enough.

456
00:17:22,240 --> 00:17:25,240
This is where people get misled by the word telemetry.

457
00:17:25,240 --> 00:17:27,680
A machine state tag and a raw vibration waveform

458
00:17:27,680 --> 00:17:29,920
both get called telemetry, yet they don't belong

459
00:17:29,920 --> 00:17:32,360
in the same capacity discussion.

460
00:17:32,360 --> 00:17:34,040
A state tag answers a simple question,

461
00:17:34,040 --> 00:17:35,720
running stopped, faulted, or idle.

462
00:17:35,720 --> 00:17:38,040
A waveform preserves the actual motion of the machine

463
00:17:38,040 --> 00:17:40,040
across thousands of points each second.

464
00:17:40,040 --> 00:17:41,920
That raw waveform can be exactly what you need

465
00:17:41,920 --> 00:17:43,080
during an investigation.

466
00:17:43,080 --> 00:17:45,400
Say a maintenance engineer suspects a bearing issue.

467
00:17:45,400 --> 00:17:47,720
A broad health score may tell you something changed,

468
00:17:47,720 --> 00:17:51,120
but it may not show the frequency, pattern, impact behavior,

469
00:17:51,120 --> 00:17:53,880
or transient condition that helps narrow down the course.

470
00:17:53,880 --> 00:17:55,560
Raw evidence gives engineers a chance

471
00:17:55,560 --> 00:17:58,360
to inspect the signal, compare it against an earlier capture,

472
00:17:58,360 --> 00:18:00,200
and test whether the apparent fault is real

473
00:18:00,200 --> 00:18:01,760
or just noise from the process.

474
00:18:01,760 --> 00:18:03,920
For fault work, raw data earns its place.

475
00:18:03,920 --> 00:18:05,360
But during normal operation,

476
00:18:05,360 --> 00:18:07,360
the same question needs more discipline.

477
00:18:07,360 --> 00:18:09,840
If the motor runs within its expected range for weeks,

478
00:18:09,840 --> 00:18:12,600
what does a full permanent copy of every healthy waveform

479
00:18:12,600 --> 00:18:14,960
enable that a smaller record cannot?

480
00:18:14,960 --> 00:18:17,200
If no person, model, or maintenance process

481
00:18:17,200 --> 00:18:19,240
will inspect that raw stream, then sending it

482
00:18:19,240 --> 00:18:21,240
continuously to remote storage turns

483
00:18:21,240 --> 00:18:24,440
a possible diagnostic asset into a standing cost.

484
00:18:24,440 --> 00:18:26,800
You don't need to pretend raw data has no use.

485
00:18:26,800 --> 00:18:28,200
That's not the right argument.

486
00:18:28,200 --> 00:18:30,640
Raw waveform data can support failure analysis,

487
00:18:30,640 --> 00:18:33,640
model development, warranty review, and occasional engineering

488
00:18:33,640 --> 00:18:34,160
work.

489
00:18:34,160 --> 00:18:36,840
It can also help when a new monitoring method needs a baseline.

490
00:18:36,840 --> 00:18:38,120
But those are bounded needs.

491
00:18:38,120 --> 00:18:40,560
They do not automatically justify a permanent cloud

492
00:18:40,560 --> 00:18:43,360
journey for every second of normal machine behavior.

493
00:18:43,360 --> 00:18:45,480
Think about what an operator or maintenance planner needs

494
00:18:45,480 --> 00:18:46,360
most days.

495
00:18:46,360 --> 00:18:47,840
They may need a current condition score

496
00:18:47,840 --> 00:18:50,160
and alarm when the score crosses a limit,

497
00:18:50,160 --> 00:18:52,440
the asset identity, the time of the event,

498
00:18:52,440 --> 00:18:53,720
and enough context to act.

499
00:18:53,720 --> 00:18:55,160
They might need a short waveform window

500
00:18:55,160 --> 00:18:56,520
before and after the event.

501
00:18:56,520 --> 00:18:58,800
Those records can support a real maintenance decision

502
00:18:58,800 --> 00:19:00,840
without moving an entire continuous stream away

503
00:19:00,840 --> 00:19:01,760
from the machine.

504
00:19:01,760 --> 00:19:03,440
The distinction changes the architecture.

505
00:19:03,440 --> 00:19:05,280
Instead of treating the cloud as the first home

506
00:19:05,280 --> 00:19:07,960
for raw vibration, keep a local rolling buffer,

507
00:19:07,960 --> 00:19:11,400
near the asset or at the site, process the stream where it appears.

508
00:19:11,400 --> 00:19:13,520
When the system detects an unusual pattern,

509
00:19:13,520 --> 00:19:15,240
retain the bounded evidence window

510
00:19:15,240 --> 00:19:18,080
and transfer that package with the score, the time,

511
00:19:18,080 --> 00:19:19,480
and the operating context.

512
00:19:19,480 --> 00:19:22,000
Now the cloud receives something a person or another system

513
00:19:22,000 --> 00:19:22,680
can use.

514
00:19:22,680 --> 00:19:24,800
It receives evidence when evidence is needed,

515
00:19:24,800 --> 00:19:27,040
not an endless recording of normality.

516
00:19:27,040 --> 00:19:29,120
There's a practical reason for this beyond cost.

517
00:19:29,120 --> 00:19:31,320
Fault investigations often need local machine context

518
00:19:31,320 --> 00:19:32,000
as well.

519
00:19:32,000 --> 00:19:35,120
Speed, load, product type, tool state, maintenance history,

520
00:19:35,120 --> 00:19:37,280
and machine mode help explain a waveform.

521
00:19:37,280 --> 00:19:39,320
A raw file sitting alone in remote storage

522
00:19:39,320 --> 00:19:41,560
may look complete while the actual conditions

523
00:19:41,560 --> 00:19:43,400
that gave it meaning remain somewhere else.

524
00:19:43,400 --> 00:19:46,360
So don't ask whether vibration data belongs in the cloud

525
00:19:46,360 --> 00:19:47,720
as one broad category.

526
00:19:47,720 --> 00:19:50,040
Ask which part of the vibration data supports

527
00:19:50,040 --> 00:19:51,440
which decision and when.

528
00:19:51,440 --> 00:19:53,720
Because the answer depends on whether the signal changes

529
00:19:53,720 --> 00:19:54,400
a decision.

530
00:19:54,400 --> 00:19:57,440
Not all factory data has the same half-life.

531
00:19:57,440 --> 00:20:00,000
Here's a practical way to decide where data belongs.

532
00:20:00,000 --> 00:20:01,800
Look at how long it stays useful.

533
00:20:01,800 --> 00:20:03,480
I'm not talking about radioactive decay.

534
00:20:03,480 --> 00:20:05,120
I mean, the time before a piece of data

535
00:20:05,120 --> 00:20:07,120
loses most of its operational value,

536
00:20:07,120 --> 00:20:08,880
some data matters for milliseconds,

537
00:20:08,880 --> 00:20:10,280
some matters for a month.

538
00:20:10,280 --> 00:20:12,920
Treating both the same way creates bad architecture

539
00:20:12,920 --> 00:20:15,800
because the people, systems, and decisions around them

540
00:20:15,800 --> 00:20:17,000
are completely different.

541
00:20:17,000 --> 00:20:18,400
Start with the fastest class.

542
00:20:18,400 --> 00:20:21,520
Data tied to safety, control, interlocks, and local alarms.

543
00:20:21,520 --> 00:20:23,640
A machine detects an unsafe condition.

544
00:20:23,640 --> 00:20:26,280
A guard opens, pressure moves outside an allowed range,

545
00:20:26,280 --> 00:20:29,320
a drive reports a fault that needs an immediate reaction.

546
00:20:29,320 --> 00:20:31,200
That data belongs close to the machine

547
00:20:31,200 --> 00:20:33,360
because the decision belongs close to the machine.

548
00:20:33,360 --> 00:20:35,800
A cloud round trip might be fast on a good day.

549
00:20:35,800 --> 00:20:38,360
It still depends on a one-link, rooting service health,

550
00:20:38,360 --> 00:20:40,240
identity checks, and a number of components

551
00:20:40,240 --> 00:20:41,840
outside the control cell.

552
00:20:41,840 --> 00:20:44,240
None of that belongs in the path for a safety response

553
00:20:44,240 --> 00:20:45,800
or deterministic control.

554
00:20:45,800 --> 00:20:48,800
The PLC safety controller and local OT systems

555
00:20:48,800 --> 00:20:49,760
own that job.

556
00:20:49,760 --> 00:20:52,080
The cloud can receive a record that the event occurred.

557
00:20:52,080 --> 00:20:53,720
It can support later analysis,

558
00:20:53,720 --> 00:20:55,680
but it shouldn't sit between a dangerous condition

559
00:20:55,680 --> 00:20:57,920
and the action that protects people or equipment.

560
00:20:57,920 --> 00:20:58,880
That's a clean boundary.

561
00:20:58,880 --> 00:21:01,960
Now look at data with a half-life measured in minutes or shifts.

562
00:21:01,960 --> 00:21:04,360
Machine state production counts, downtime reasons,

563
00:21:04,360 --> 00:21:06,840
material consumption, and job progress fit here.

564
00:21:06,840 --> 00:21:08,800
You don't need each value, the instant it appears

565
00:21:08,800 --> 00:21:10,240
to make a safe machine decision,

566
00:21:10,240 --> 00:21:11,920
but the people running the line needed

567
00:21:11,920 --> 00:21:13,840
while the shift still has time to react.

568
00:21:13,840 --> 00:21:15,480
Picture a supervisor looking at a line

569
00:21:15,480 --> 00:21:17,520
that has stopped four times since lunch.

570
00:21:17,520 --> 00:21:19,320
They need to know whether loss occurred,

571
00:21:19,320 --> 00:21:20,800
what state the machine entered,

572
00:21:20,800 --> 00:21:22,280
which work order ran at the time

573
00:21:22,280 --> 00:21:24,440
and whether the same pattern keeps returning.

574
00:21:24,440 --> 00:21:26,720
That information supports real-time visibility

575
00:21:26,720 --> 00:21:28,720
without pretending every raw tag value

576
00:21:28,720 --> 00:21:30,000
needs long-term storage.

577
00:21:30,000 --> 00:21:32,720
This is where context starts doing more work than volume.

578
00:21:32,720 --> 00:21:36,840
A stop event with a timestamp, duration, reason code, asset ID

579
00:21:36,840 --> 00:21:39,320
and order context can tell a production team far more

580
00:21:39,320 --> 00:21:41,920
than a massive list of unchanged state values.

581
00:21:41,920 --> 00:21:44,120
The event becomes a usable operational fact.

582
00:21:44,120 --> 00:21:45,560
It explains something that happened

583
00:21:45,560 --> 00:21:47,600
and gives the next person a place to start.

584
00:21:47,600 --> 00:21:49,240
Then you have data whose half-life stretches

585
00:21:49,240 --> 00:21:50,640
into weeks and months.

586
00:21:50,640 --> 00:21:53,680
OEE trends, scrap patterns, energy baselines,

587
00:21:53,680 --> 00:21:55,360
throughput by product family,

588
00:21:55,360 --> 00:21:57,400
and recurring failure modes sit in this group.

589
00:21:57,400 --> 00:21:59,640
These records support planning, continuous improvement

590
00:21:59,640 --> 00:22:01,000
and cross-site comparison.

591
00:22:01,000 --> 00:22:02,640
They don't need a millisecond response,

592
00:22:02,640 --> 00:22:04,520
but they need consistency.

593
00:22:04,520 --> 00:22:06,920
This is a good place for shared cloud analytics

594
00:22:06,920 --> 00:22:08,320
because the question often reaches

595
00:22:08,320 --> 00:22:09,920
beyond one machine or one shift.

596
00:22:09,920 --> 00:22:11,800
Are two plans losing time for the same reason?

597
00:22:11,800 --> 00:22:14,920
Did a process change alter scrap rates over several months?

598
00:22:14,920 --> 00:22:17,920
Is energy used changing after a new product mix came online?

599
00:22:17,920 --> 00:22:19,480
Those questions need history, governance,

600
00:22:19,480 --> 00:22:21,280
and a common way to describe the work.

601
00:22:21,280 --> 00:22:23,280
A well-run cloud data platform can help connect

602
00:22:23,280 --> 00:22:25,200
the dots between IT and OT here,

603
00:22:25,200 --> 00:22:26,480
as long as the records arriving there

604
00:22:26,480 --> 00:22:28,080
mean the same thing across sites.

605
00:22:28,080 --> 00:22:30,000
Now, don't confuse age with value.

606
00:22:30,000 --> 00:22:31,400
All data can still matter.

607
00:22:31,400 --> 00:22:33,840
A production record may need to remain available

608
00:22:33,840 --> 00:22:36,800
for traceability, quality claims, warranty work,

609
00:22:36,800 --> 00:22:39,560
customer obligations, or internal audit.

610
00:22:39,560 --> 00:22:41,640
Its operational half-life may have passed,

611
00:22:41,640 --> 00:22:44,200
but its business retention period may continue for years.

612
00:22:44,200 --> 00:22:45,520
That distinction matters.

613
00:22:45,520 --> 00:22:47,160
Raw evidence is one category.

614
00:22:47,160 --> 00:22:49,440
It preserves the detailed signal, image, log,

615
00:22:49,440 --> 00:22:51,160
or machine context needed when someone

616
00:22:51,160 --> 00:22:53,120
must investigate a specific event.

617
00:22:53,120 --> 00:22:54,240
The rife facts are another.

618
00:22:54,240 --> 00:22:56,040
They turn that detail into a condition score,

619
00:22:56,040 --> 00:22:58,600
downtime event, count, aggregate, or quality result

620
00:22:58,600 --> 00:23:00,280
that people can use repeatedly.

621
00:23:00,280 --> 00:23:02,160
Long-term business records are different again.

622
00:23:02,160 --> 00:23:04,240
They preserve what was produced when it was produced,

623
00:23:04,240 --> 00:23:06,200
which material and work order applied,

624
00:23:06,200 --> 00:23:08,520
and what quality outcome the process recorded.

625
00:23:08,520 --> 00:23:10,200
Those records don't need the same data rate

626
00:23:10,200 --> 00:23:12,960
as raw evidence, but they need traceability and clear ownership.

627
00:23:12,960 --> 00:23:15,360
So a mature architecture doesn't ask one blunt question,

628
00:23:15,360 --> 00:23:16,440
cloud or edge.

629
00:23:16,440 --> 00:23:19,360
It asks how long the data stays useful in its current form,

630
00:23:19,360 --> 00:23:20,880
who needs it during that period,

631
00:23:20,880 --> 00:23:22,400
and what decision it supports.

632
00:23:22,400 --> 00:23:24,920
A local alarm may have seconds of operational value.

633
00:23:24,920 --> 00:23:27,240
A downtime event may matter across a shift.

634
00:23:27,240 --> 00:23:29,400
A monthly energy trend may support a planning decision

635
00:23:29,400 --> 00:23:31,600
long after the original readings disappear.

636
00:23:31,600 --> 00:23:33,560
Once you see those different half-lives,

637
00:23:33,560 --> 00:23:36,320
you can start placing data by its actual value,

638
00:23:36,320 --> 00:23:38,920
rather than by the fact that a sensor happened to produce it.

639
00:23:38,920 --> 00:23:41,320
That builds a hierarchy of data value.

640
00:23:41,320 --> 00:23:43,400
A data value hierarchy for the shop floor.

641
00:23:43,400 --> 00:23:45,440
Once you sort factory data by the decision

642
00:23:45,440 --> 00:23:48,120
it supports, a practical hierarchy starts to appear.

643
00:23:48,120 --> 00:23:50,120
It isn't a vendor model, and it won't look identical

644
00:23:50,120 --> 00:23:51,160
in every plant.

645
00:23:51,160 --> 00:23:52,760
But it gives you a disciplined default,

646
00:23:52,760 --> 00:23:55,920
instead of treating every bite as equally worthy of cloud storage.

647
00:23:55,920 --> 00:23:57,640
T-R-1 is raw, high-rate data.

648
00:23:57,640 --> 00:24:00,760
This includes continuous waveforms, unfiltered vision input,

649
00:24:00,760 --> 00:24:03,000
detailed diagnostic traces, and similar streams

650
00:24:03,000 --> 00:24:04,640
where the value sits in the fine detail

651
00:24:04,640 --> 00:24:06,640
rather than a simple result.

652
00:24:06,640 --> 00:24:08,680
Keep this local by default close to the source

653
00:24:08,680 --> 00:24:11,000
and close to the people who may need to inspect it.

654
00:24:11,000 --> 00:24:12,680
That doesn't mean deleted immediately.

655
00:24:12,680 --> 00:24:15,040
It means keep it where it can support local diagnosis

656
00:24:15,040 --> 00:24:17,320
without creating a permanent remote data burden.

657
00:24:17,320 --> 00:24:19,120
The data may be useful, but its useful form

658
00:24:19,120 --> 00:24:21,280
is often short-lived and site-specific.

659
00:24:21,280 --> 00:24:24,240
T-R-2 is filtered events and short interval aggregates.

660
00:24:24,240 --> 00:24:27,040
A condition score changes, a machine enters a fault state,

661
00:24:27,040 --> 00:24:28,840
a temperature trend crosses a limit,

662
00:24:28,840 --> 00:24:31,120
a one-minute record captures cycle count, runtime,

663
00:24:31,120 --> 00:24:33,840
energy use, and data quality for a defined asset.

664
00:24:33,840 --> 00:24:35,520
This tier often earns selective transfer

665
00:24:35,520 --> 00:24:38,160
because it has already become smaller and more meaningful.

666
00:24:38,160 --> 00:24:39,880
You aren't moving every measurement.

667
00:24:39,880 --> 00:24:41,960
You're moving a record that describes a change,

668
00:24:41,960 --> 00:24:44,760
an exception, or a bounded operational period.

669
00:24:44,760 --> 00:24:46,680
The receiving system also needs enough context

670
00:24:46,680 --> 00:24:47,800
to trust the record.

671
00:24:47,800 --> 00:24:50,040
An event without an asset ID timestamp unit,

672
00:24:50,040 --> 00:24:51,600
quality state, and production context

673
00:24:51,600 --> 00:24:53,640
can look precise while telling you very little.

674
00:24:53,640 --> 00:24:55,880
Small data isn't automatically good data.

675
00:24:55,880 --> 00:24:57,720
tier three is the part most enterprise systems

676
00:24:57,720 --> 00:24:59,360
should be very comfortable receiving.

677
00:24:59,360 --> 00:25:01,320
Shift KPI is a completed production records,

678
00:25:01,320 --> 00:25:04,040
traceable order facts, quality outcomes, downtime events,

679
00:25:04,040 --> 00:25:05,640
and material genealogy fit here.

680
00:25:05,640 --> 00:25:07,400
These records support reporting, planning,

681
00:25:07,400 --> 00:25:09,280
traceability, and coordination between functions

682
00:25:09,280 --> 00:25:11,040
that don't sit next to the same machine.

683
00:25:11,040 --> 00:25:12,760
Cloud storage and shared data services

684
00:25:12,760 --> 00:25:15,240
make sense for this tier because the consumer often

685
00:25:15,240 --> 00:25:16,680
sits outside the site.

686
00:25:16,680 --> 00:25:19,240
A central team may compare output across plants.

687
00:25:19,240 --> 00:25:21,480
A planner may need confirmed production facts,

688
00:25:21,480 --> 00:25:23,640
quality may need to trace a finished lot back

689
00:25:23,640 --> 00:25:24,760
through the process.

690
00:25:24,760 --> 00:25:26,440
These aren't just summaries for a dashboard.

691
00:25:26,440 --> 00:25:29,160
They are business records and they need clear definitions.

692
00:25:29,160 --> 00:25:31,640
If one plant records a microstop is downtime,

693
00:25:31,640 --> 00:25:33,640
while another ignores it, sending both records

694
00:25:33,640 --> 00:25:36,640
to the same cloud platform won't fix the disagreement.

695
00:25:36,640 --> 00:25:39,320
You get a polished report built on two different meanings.

696
00:25:39,320 --> 00:25:42,080
Tier four contains data where cloud use has a clear case,

697
00:25:42,080 --> 00:25:43,760
cross-plant trend work belongs here.

698
00:25:43,760 --> 00:25:46,240
So do carefully curated model training sets,

699
00:25:46,240 --> 00:25:48,760
shared reference data, and fleet level analysis

700
00:25:48,760 --> 00:25:51,760
where the question cannot be answered from one site alone.

701
00:25:51,760 --> 00:25:53,280
A cloud environment can bring together

702
00:25:53,280 --> 00:25:55,560
years of governed records from many plants,

703
00:25:55,560 --> 00:25:58,400
then let teams compare patterns across product families,

704
00:25:58,400 --> 00:26:00,760
equipment types, and operating conditions.

705
00:26:00,760 --> 00:26:03,000
That is a different job from reacting to what a machine does

706
00:26:03,000 --> 00:26:03,720
right now.

707
00:26:03,720 --> 00:26:05,800
It needs broad access, a common data model,

708
00:26:05,800 --> 00:26:08,040
controlled retention, and compute that can grow

709
00:26:08,040 --> 00:26:09,400
when the analysis grows.

710
00:26:09,400 --> 00:26:12,320
Model training belongs in this tier two with a bit of care.

711
00:26:12,320 --> 00:26:15,080
Training data should not mean copy every raw signal

712
00:26:15,080 --> 00:26:17,040
from every plant forever.

713
00:26:17,040 --> 00:26:20,680
A useful training set needs labels, known operating context,

714
00:26:20,680 --> 00:26:23,000
lineage, and a reason for each sample.

715
00:26:23,000 --> 00:26:25,880
More unfiltered data doesn't automatically produce a better model.

716
00:26:25,880 --> 00:26:28,280
Sometimes it just produces a larger storage account

717
00:26:28,280 --> 00:26:29,560
and a harder problem.

718
00:26:29,560 --> 00:26:31,560
So the hierarchy looks like this.

719
00:26:31,560 --> 00:26:34,880
Raw, high-rate streams stay local unless a defined case

720
00:26:34,880 --> 00:26:37,240
pulls them upward, filter events and aggregates

721
00:26:37,240 --> 00:26:38,520
move selectively.

722
00:26:38,520 --> 00:26:42,040
Traceable operational facts move into shared enterprise systems,

723
00:26:42,040 --> 00:26:44,880
cross-plant analysis and curated learning data justify

724
00:26:44,880 --> 00:26:47,400
cloud scale because they need a view beyond the site.

725
00:26:47,400 --> 00:26:49,840
The rule behind all four tiers is simple.

726
00:26:49,840 --> 00:26:52,160
Move data only when a named consumer needs it

727
00:26:52,160 --> 00:26:53,480
to make a named decision.

728
00:26:53,480 --> 00:26:57,520
Not someone might use it later, not the platform can ingest it.

729
00:26:57,520 --> 00:26:59,520
A real consumer, a real decision,

730
00:26:59,520 --> 00:27:02,200
and a minimum data form that supports that decision.

731
00:27:02,200 --> 00:27:03,480
If nobody can name those things,

732
00:27:03,480 --> 00:27:05,400
the transfer has not earned approval.

733
00:27:05,400 --> 00:27:08,080
Most cloud first diagrams reverse this logic.

734
00:27:08,080 --> 00:27:10,120
They begin with a broad arrow from every source

735
00:27:10,120 --> 00:27:11,480
into central storage.

736
00:27:11,480 --> 00:27:13,640
Then hope somebody finds a use for it later.

737
00:27:13,640 --> 00:27:15,840
Why send everything became the default.

738
00:27:15,840 --> 00:27:17,960
So why did so many factory architectures end up

739
00:27:17,960 --> 00:27:20,800
with that broad sensor to cloud pattern in the first place?

740
00:27:20,800 --> 00:27:22,160
Here's how it usually starts.

741
00:27:22,160 --> 00:27:24,720
Cloud services practically give away the first step.

742
00:27:24,720 --> 00:27:27,400
Sending data upward carries almost no direct cost.

743
00:27:27,400 --> 00:27:29,640
So a project team sees a simple path.

744
00:27:29,640 --> 00:27:32,720
Connect the gateway, publish the data, land it in storage,

745
00:27:32,720 --> 00:27:34,360
and sort out the use cases later.

746
00:27:34,360 --> 00:27:35,680
The first month looks fine.

747
00:27:35,680 --> 00:27:37,320
The first pilot looks even better.

748
00:27:37,320 --> 00:27:38,600
That leads to a false conclusion.

749
00:27:38,600 --> 00:27:41,200
If it's cheap to send data in, it must make sense

750
00:27:41,200 --> 00:27:42,200
to keep sending all of it.

751
00:27:42,200 --> 00:27:42,840
But here's the thing.

752
00:27:42,840 --> 00:27:44,000
Nobody flags at that point.

753
00:27:44,000 --> 00:27:46,760
A factory data stream doesn't end when it enters a cloud

754
00:27:46,760 --> 00:27:47,200
endpoint.

755
00:27:47,200 --> 00:27:48,240
It starts a life there.

756
00:27:48,240 --> 00:27:50,800
People query at services copy at reports pull from it,

757
00:27:50,800 --> 00:27:52,800
and new teams find it because it's available.

758
00:27:52,800 --> 00:27:54,640
A low friction ingest decision quietly

759
00:27:54,640 --> 00:27:56,920
becomes a long term data placement decision,

760
00:27:56,920 --> 00:27:59,760
often without anyone ever making that choice on purpose.

761
00:27:59,760 --> 00:28:02,040
IoT reference diagrams helped create this habit too.

762
00:28:02,040 --> 00:28:03,320
You've seen the diagram.

763
00:28:03,320 --> 00:28:05,320
Devices and PLCs at the bottom are gateway

764
00:28:05,320 --> 00:28:07,920
or broker in the middle cloud services at the top,

765
00:28:07,920 --> 00:28:11,480
with clean arrows moving upward through a neat stack of icons.

766
00:28:11,480 --> 00:28:13,760
It communicates connectivity well enough,

767
00:28:13,760 --> 00:28:16,000
but it leaves out the things an operating team actually

768
00:28:16,000 --> 00:28:17,280
has to deal with.

769
00:28:17,280 --> 00:28:21,480
Byte volume, retention windows, consumers, duplicate collectors,

770
00:28:21,480 --> 00:28:24,800
and the real path a record takes after it arrives.

771
00:28:24,800 --> 00:28:27,280
An arrow on a slide doesn't show a monthly meter.

772
00:28:27,280 --> 00:28:28,840
It also doesn't show who owns the data

773
00:28:28,840 --> 00:28:30,320
once the pilot team moves on.

774
00:28:30,320 --> 00:28:33,120
The diagram implies all source data follows the same path,

775
00:28:33,120 --> 00:28:35,920
because that makes the architecture easy to explain.

776
00:28:35,920 --> 00:28:38,440
Yet a machine state event, a camera frame, a diagnostic log,

777
00:28:38,440 --> 00:28:40,600
and a high-rate waveform don't have the same purpose,

778
00:28:40,600 --> 00:28:42,040
rate, or useful life.

779
00:28:42,040 --> 00:28:44,000
Drawing them all with one arrow makes them look

780
00:28:44,000 --> 00:28:45,320
equivalent when they aren't.

781
00:28:45,320 --> 00:28:48,320
This gets harder because pilot projects start small.

782
00:28:48,320 --> 00:28:50,840
A team connects a few machines and keeps every record

783
00:28:50,840 --> 00:28:53,440
because storage feels cheap and because having more data

784
00:28:53,440 --> 00:28:55,480
seems safer than having less.

785
00:28:55,480 --> 00:28:57,560
At that scale, even an inefficient route

786
00:28:57,560 --> 00:28:59,400
might not show up as a serious problem.

787
00:28:59,400 --> 00:29:02,400
The team proves the connection works, builds a dashboard,

788
00:29:02,400 --> 00:29:04,440
and gets approval to expand.

789
00:29:04,440 --> 00:29:06,400
Then the same pattern rolls out to the next line.

790
00:29:06,400 --> 00:29:09,080
Nothing changes in the design except the number of assets.

791
00:29:09,080 --> 00:29:10,880
The gateway configuration gets copied.

792
00:29:10,880 --> 00:29:12,280
The topic structure gets copied.

793
00:29:12,280 --> 00:29:13,720
The data route gets copied.

794
00:29:13,720 --> 00:29:16,520
Every signal travels upstream at the same cadence.

795
00:29:16,520 --> 00:29:18,440
Even when the new line has a different process,

796
00:29:18,440 --> 00:29:21,680
different failure modes, or no defined cloud consumer

797
00:29:21,680 --> 00:29:23,000
for most of the data.

798
00:29:23,000 --> 00:29:26,400
Success at pilot scale can hide a bad default at planned scale.

799
00:29:26,400 --> 00:29:29,320
I've seen this mindset in plenty of technical conversations.

800
00:29:29,320 --> 00:29:32,600
Someone asks why raw records need to stay available forever.

801
00:29:32,600 --> 00:29:34,560
And the answer is usually just in case.

802
00:29:34,560 --> 00:29:36,400
That answer comes from a reasonable fear.

803
00:29:36,400 --> 00:29:39,160
Nobody wants to delete evidence before an engineer discovers

804
00:29:39,160 --> 00:29:39,920
they need it.

805
00:29:39,920 --> 00:29:41,000
The issue isn't caution.

806
00:29:41,000 --> 00:29:43,280
The issue is leaving caution without an owner,

807
00:29:43,280 --> 00:29:44,840
a time limit, or a decision rule.

808
00:29:44,840 --> 00:29:48,560
If no one owns retention, every project keeps its raw data.

809
00:29:48,560 --> 00:29:50,600
The maintenance group keeps condition records.

810
00:29:50,600 --> 00:29:51,800
Quality keeps images.

811
00:29:51,800 --> 00:29:53,680
The platform team keeps message history.

812
00:29:53,680 --> 00:29:55,840
An external vendor retains a portal archive.

813
00:29:55,840 --> 00:29:57,480
Each group can explain its own choice,

814
00:29:57,480 --> 00:30:00,040
but nobody can explain the total amount, the overlap,

815
00:30:00,040 --> 00:30:02,160
or when the data should stop existing.

816
00:30:02,160 --> 00:30:04,800
Just in case turns into forever by default.

817
00:30:04,800 --> 00:30:05,920
That isn't a storage policy.

818
00:30:05,920 --> 00:30:07,200
It's the absence of one.

819
00:30:07,200 --> 00:30:08,480
There's also a cultural reason.

820
00:30:08,480 --> 00:30:10,880
Cloud teams often get measured on how fast they can connect

821
00:30:10,880 --> 00:30:12,960
systems and expose data for reporting.

822
00:30:12,960 --> 00:30:15,120
O.T. teams get measured on stable production.

823
00:30:15,120 --> 00:30:16,800
Neither group naturally owns the question

824
00:30:16,800 --> 00:30:19,440
of whether an unchanged sensor value should cross a site boundary

825
00:30:19,440 --> 00:30:21,240
every second for the next five years.

826
00:30:21,240 --> 00:30:23,200
So the broad arrow survives because nobody

827
00:30:23,200 --> 00:30:25,360
has a reason to challenge it during delivery.

828
00:30:25,360 --> 00:30:27,560
A fire hose looks tidy in the slide deck.

829
00:30:27,560 --> 00:30:29,880
It's less tidy when someone needs to explain

830
00:30:29,880 --> 00:30:32,120
why the same data appears in four places,

831
00:30:32,120 --> 00:30:34,080
why the raw archive keeps growing,

832
00:30:34,080 --> 00:30:37,080
or why an engineering request now involves retrieving files

833
00:30:37,080 --> 00:30:39,600
from a remote platform that the plant doesn't control

834
00:30:39,600 --> 00:30:40,800
directly.

835
00:30:40,800 --> 00:30:42,720
The better default starts with restraint.

836
00:30:42,720 --> 00:30:44,600
Collect what you need locally, turn it into the form

837
00:30:44,600 --> 00:30:47,200
the next decision needs, and move only that form

838
00:30:47,200 --> 00:30:48,480
when there's a clear reason to share it.

839
00:30:48,480 --> 00:30:50,880
You can always define an exception for a fault capture,

840
00:30:50,880 --> 00:30:53,040
a model study, or a traceability record.

841
00:30:53,040 --> 00:30:54,720
Those exceptions should be explicit, though.

842
00:30:54,720 --> 00:30:57,680
They shouldn't become the design pattern for everything else.

843
00:30:57,680 --> 00:31:01,120
Once data leaves the plant, it starts attracting more systems.

844
00:31:01,120 --> 00:31:04,480
Data gravity changes the architecture over time.

845
00:31:04,480 --> 00:31:06,640
Once data starts accumulating in the cloud,

846
00:31:06,640 --> 00:31:08,840
it changes the shape of the system around it.

847
00:31:08,840 --> 00:31:09,920
That's data gravity.

848
00:31:09,920 --> 00:31:12,600
Large data sets pull compute, tools, copies,

849
00:31:12,600 --> 00:31:14,680
and teams toward the place where the data lives.

850
00:31:14,680 --> 00:31:15,720
It's not magic.

851
00:31:15,720 --> 00:31:17,520
It's just friction.

852
00:31:17,520 --> 00:31:19,400
If six months of high rate machine data

853
00:31:19,400 --> 00:31:21,240
sits in a cloud store, the next analyst

854
00:31:21,240 --> 00:31:23,680
will naturally run a notebook near that store.

855
00:31:23,680 --> 00:31:25,440
The next dashboard team will point its model

856
00:31:25,440 --> 00:31:26,800
at the same data.

857
00:31:26,800 --> 00:31:29,160
An external platform will ask for a connector.

858
00:31:29,160 --> 00:31:30,720
Pretty soon somebody creates a replica

859
00:31:30,720 --> 00:31:32,920
because another workload needs better response time

860
00:31:32,920 --> 00:31:34,200
or a separate environment.

861
00:31:34,200 --> 00:31:37,480
The data attracts work because moving the work looks easier

862
00:31:37,480 --> 00:31:38,640
than moving the data.

863
00:31:38,640 --> 00:31:40,720
That can be a sensible choice when the data genuinely

864
00:31:40,720 --> 00:31:41,760
needs enterprise scale.

865
00:31:41,760 --> 00:31:44,040
If you are comparing performance across many plants,

866
00:31:44,040 --> 00:31:46,720
joining production records to supply chain data

867
00:31:46,720 --> 00:31:49,520
or preparing a control data set for model training,

868
00:31:49,520 --> 00:31:53,200
central compute near central data is often the right pattern.

869
00:31:53,200 --> 00:31:56,120
But raw factory data creates a different problem.

870
00:31:56,120 --> 00:31:58,160
Take a large high rate archive that started

871
00:31:58,160 --> 00:32:00,400
as a condition monitoring pilot.

872
00:32:00,400 --> 00:32:03,000
It may sit in cloud storage because nobody wanted to lose it.

873
00:32:03,000 --> 00:32:05,400
Then more consumers arrive, one team wants access

874
00:32:05,400 --> 00:32:06,480
for diagnostics.

875
00:32:06,480 --> 00:32:08,440
Another needs samples for a maintenance model.

876
00:32:08,440 --> 00:32:10,120
A third builds a dashboard.

877
00:32:10,120 --> 00:32:12,680
Each new use tends to create a new permission path,

878
00:32:12,680 --> 00:32:15,160
data pipeline, workspace or copy.

879
00:32:15,160 --> 00:32:18,040
That original stream becomes part of the enterprise estate.

880
00:32:18,040 --> 00:32:20,280
And that's when the cost of a casual early decision

881
00:32:20,280 --> 00:32:22,840
starts showing up, not just in storage or network charges,

882
00:32:22,840 --> 00:32:25,440
but in ownership, who defines the asset names,

883
00:32:25,440 --> 00:32:27,280
which timestamps are trusted, what

884
00:32:27,280 --> 00:32:29,520
happens when a sensor configuration changes?

885
00:32:29,520 --> 00:32:31,920
Who decides whether a downstream data set still

886
00:32:31,920 --> 00:32:33,320
has the right to exist?

887
00:32:33,320 --> 00:32:34,840
The cloud didn't create those questions.

888
00:32:34,840 --> 00:32:37,240
It exposed them at a much larger scale.

889
00:32:37,240 --> 00:32:39,320
Picture a reliability engineer who now

890
00:32:39,320 --> 00:32:41,920
needs historical waveform data back at the site

891
00:32:41,920 --> 00:32:44,440
because a machine issue needs hands-on diagnosis.

892
00:32:44,440 --> 00:32:46,520
The data might be technically available in the cloud,

893
00:32:46,520 --> 00:32:49,080
but getting it back can involve access approvals,

894
00:32:49,080 --> 00:32:52,600
a retrieval process, transfer time, local storage capacity,

895
00:32:52,600 --> 00:32:55,720
and proof that the restored files match the original record.

896
00:32:55,720 --> 00:32:58,360
By that stage, just bring the data back is no longer

897
00:32:58,360 --> 00:32:59,400
a small task.

898
00:32:59,400 --> 00:33:00,440
It becomes a program.

899
00:33:00,440 --> 00:33:02,760
Someone has to map dependencies, find every copy,

900
00:33:02,760 --> 00:33:05,440
validate schemers, check retention rules,

901
00:33:05,440 --> 00:33:08,480
deal with vendor tools, and confirm which system holds

902
00:33:08,480 --> 00:33:10,240
the authoritative version.

903
00:33:10,240 --> 00:33:11,960
The more teams build on the remote data,

904
00:33:11,960 --> 00:33:13,640
the more carefully you need to unwind it.

905
00:33:13,640 --> 00:33:15,880
That's why data gravity needs to be a design choice.

906
00:33:15,880 --> 00:33:18,440
You decide where data should accumulate based on its real use,

907
00:33:18,440 --> 00:33:20,840
not because a connector made the first route easy.

908
00:33:20,840 --> 00:33:23,520
Some data should pull work toward the cloud, enterprise

909
00:33:23,520 --> 00:33:26,720
reporting, fleet analysis, governed business records,

910
00:33:26,720 --> 00:33:29,000
and shared models all have a reason to live

911
00:33:29,000 --> 00:33:30,680
where many teams can reach them.

912
00:33:30,680 --> 00:33:32,240
Other data should remain near the plant

913
00:33:32,240 --> 00:33:34,760
because the operational needs stays near the plant.

914
00:33:34,760 --> 00:33:37,560
A high-rate history used mainly for machine diagnosis

915
00:33:37,560 --> 00:33:39,680
should stay close to the maintenance process

916
00:33:39,680 --> 00:33:41,000
that gives it meaning.

917
00:33:41,000 --> 00:33:42,680
The source of truth for that history

918
00:33:42,680 --> 00:33:44,600
can sit at the edge or site layer

919
00:33:44,600 --> 00:33:46,960
with defined windows and controlled access.

920
00:33:46,960 --> 00:33:49,360
You can still send selected evidence upward

921
00:33:49,360 --> 00:33:51,760
when a specific case needs wider review

922
00:33:51,760 --> 00:33:54,360
that is not isolation, it's proper placement.

923
00:33:54,360 --> 00:33:56,840
The factory keeps the data that supports local operation

924
00:33:56,840 --> 00:33:57,960
and local investigation.

925
00:33:57,960 --> 00:34:00,600
The cloud receives the data that supports shared analysis

926
00:34:00,600 --> 00:34:02,040
and enterprise decisions.

927
00:34:02,040 --> 00:34:03,440
Both layers can work together,

928
00:34:03,440 --> 00:34:05,760
but neither needs to pretend it owns every bite.

929
00:34:05,760 --> 00:34:07,560
This also gives you more freedom later.

930
00:34:07,560 --> 00:34:09,080
If a cloud analytics tool changes,

931
00:34:09,080 --> 00:34:10,800
you can move curated operational facts

932
00:34:10,800 --> 00:34:13,640
without dragging years of raw signals through a migration.

933
00:34:13,640 --> 00:34:15,800
If a site needs to investigate an event,

934
00:34:15,800 --> 00:34:17,880
the detailed evidence stays available

935
00:34:17,880 --> 00:34:20,080
where the process and people already are.

936
00:34:20,080 --> 00:34:22,880
Keep the source of truth close to the operational need.

937
00:34:22,880 --> 00:34:25,000
Move the derived facts to the shared need.

938
00:34:25,000 --> 00:34:26,720
Once that placement becomes deliberate,

939
00:34:26,720 --> 00:34:28,320
the next issue comes into view.

940
00:34:28,320 --> 00:34:30,000
Even inside one cloud provider,

941
00:34:30,000 --> 00:34:31,640
network topology can add charges

942
00:34:31,640 --> 00:34:34,320
that never appear in the first architecture diagram.

943
00:34:34,320 --> 00:34:37,240
Cross-zone traffic can tax your own architecture.

944
00:34:37,240 --> 00:34:39,800
Here's something that catches even experienced cloud teams

945
00:34:39,800 --> 00:34:40,600
off-guard.

946
00:34:40,600 --> 00:34:42,200
Data can move between two workloads

947
00:34:42,200 --> 00:34:44,040
you own inside one provider region

948
00:34:44,040 --> 00:34:46,000
and still create a transfer charge.

949
00:34:46,000 --> 00:34:48,520
A common public reference rate for cross-availability zone

950
00:34:48,520 --> 00:34:51,960
traffic runs about one cent per gigabyte in each direction.

951
00:34:51,960 --> 00:34:53,720
That sounds too small to worry about.

952
00:34:53,720 --> 00:34:55,960
And most per gigabyte numbers do right up

953
00:34:55,960 --> 00:34:57,760
until the traffic runs continuously

954
00:34:57,760 --> 00:34:59,160
between services that were never

955
00:34:59,160 --> 00:35:03,000
placed with their conversation pattern in mind.

956
00:35:03,000 --> 00:35:05,920
Availability zones exist to separate power, networking

957
00:35:05,920 --> 00:35:08,480
and failure domains within a cloud region

958
00:35:08,480 --> 00:35:10,880
so a service can survive a problem in one location.

959
00:35:10,880 --> 00:35:12,680
That's a sound resilience goal.

960
00:35:12,680 --> 00:35:14,800
The mistake comes when teams spread every part

961
00:35:14,800 --> 00:35:17,120
of a high volume data path across zones

962
00:35:17,120 --> 00:35:19,520
without looking at where the bytes actually travel,

963
00:35:19,520 --> 00:35:21,200
picture a factory telemetry workload

964
00:35:21,200 --> 00:35:22,720
after it reaches the cloud.

965
00:35:22,720 --> 00:35:24,280
Your message broker lives in zone A,

966
00:35:24,280 --> 00:35:25,880
the stream processor lives in zone B,

967
00:35:25,880 --> 00:35:27,440
and the time series database sits

968
00:35:27,440 --> 00:35:30,080
behind a replica arrangement that stretches into zone C.

969
00:35:30,080 --> 00:35:32,200
Every single message crosses zone boundaries

970
00:35:32,200 --> 00:35:34,280
before anyone even opens a dashboard.

971
00:35:34,280 --> 00:35:35,280
Nothing is broken.

972
00:35:35,280 --> 00:35:37,080
It may even meet the availability design.

973
00:35:37,080 --> 00:35:40,080
But here's the catch, the data is no longer moving once.

974
00:35:40,080 --> 00:35:41,600
It's moving through a distributed system

975
00:35:41,600 --> 00:35:43,680
where each hop has a physical placement

976
00:35:43,680 --> 00:35:46,080
and sometimes a charge attached to it.

977
00:35:46,080 --> 00:35:48,160
Message brokers make this easy to overlook,

978
00:35:48,160 --> 00:35:49,960
a factory gateway publishes a record.

979
00:35:49,960 --> 00:35:51,520
The broker accepts it, then copies it

980
00:35:51,520 --> 00:35:53,440
to another broker for replication.

981
00:35:53,440 --> 00:35:55,800
A processing service reads it from a different zone,

982
00:35:55,800 --> 00:35:58,160
writes a transformed result to a database,

983
00:35:58,160 --> 00:36:00,480
and that database may replicate the change again.

984
00:36:00,480 --> 00:36:02,240
The original payload might be small,

985
00:36:02,240 --> 00:36:05,800
but the system repeats that path thousands or millions of times.

986
00:36:05,800 --> 00:36:08,360
Replication isn't free just because it's internal.

987
00:36:08,360 --> 00:36:10,160
Database is create the same pattern.

988
00:36:10,160 --> 00:36:11,800
A service in zone A writes a record

989
00:36:11,800 --> 00:36:13,560
to a primary database in zone B,

990
00:36:13,560 --> 00:36:15,560
the response travels back to zone A,

991
00:36:15,560 --> 00:36:18,600
then the database sends changes to a replica in zone C.

992
00:36:18,600 --> 00:36:20,320
If another workload reads from that replica,

993
00:36:20,320 --> 00:36:22,800
the next request and response may cross zones again.

994
00:36:22,800 --> 00:36:24,480
You can end up paying for a round trip,

995
00:36:24,480 --> 00:36:26,880
a replication path, and a second request path

996
00:36:26,880 --> 00:36:28,280
around one operational fact.

997
00:36:28,280 --> 00:36:29,960
Processing jobs add more movement,

998
00:36:29,960 --> 00:36:32,600
a scheduled job reads a day of telemetry from storage

999
00:36:32,600 --> 00:36:35,480
in one zone, processes it in compute somewhere else,

1000
00:36:35,480 --> 00:36:37,800
then writes the output into a database or lake house

1001
00:36:37,800 --> 00:36:39,680
that sits across another boundary.

1002
00:36:39,680 --> 00:36:41,240
The job may only run once per day,

1003
00:36:41,240 --> 00:36:43,240
but the data volume can be large enough

1004
00:36:43,240 --> 00:36:45,240
that placement matters more than the schedule,

1005
00:36:45,240 --> 00:36:46,800
then retries enter the picture.

1006
00:36:46,800 --> 00:36:49,120
A consumer loses its connection, times out,

1007
00:36:49,120 --> 00:36:51,760
or can't confirm a right completed, so it tries again.

1008
00:36:51,760 --> 00:36:53,920
That's correct behavior for reliable delivery,

1009
00:36:53,920 --> 00:36:57,200
but each retry repeats request data, response data,

1010
00:36:57,200 --> 00:36:58,560
and downstream replication.

1011
00:36:58,560 --> 00:37:00,760
If the workload lacks idempotent handling,

1012
00:37:00,760 --> 00:37:02,440
you may also create duplicate records

1013
00:37:02,440 --> 00:37:04,960
starting another chain of reads, writes, and copies.

1014
00:37:04,960 --> 00:37:06,920
The bill follows the bytes, not your intent.

1015
00:37:06,920 --> 00:37:09,680
This is why I separate resilience from careless placement.

1016
00:37:09,680 --> 00:37:11,400
Multisone design can protect services

1017
00:37:11,400 --> 00:37:13,440
that need continuity through a zone failure,

1018
00:37:13,440 --> 00:37:16,120
and for many enterprise systems, that's a justified cost.

1019
00:37:16,120 --> 00:37:17,320
You shouldn't remove redundancy

1020
00:37:17,320 --> 00:37:19,040
just to make a billing chart look better,

1021
00:37:19,040 --> 00:37:20,840
but resilience has to match the workload.

1022
00:37:20,840 --> 00:37:22,760
You need to ask whether this high-rate stream

1023
00:37:22,760 --> 00:37:26,160
needs every component active across zones at all times.

1024
00:37:26,160 --> 00:37:28,440
Can the processing path remain close to the broker

1025
00:37:28,440 --> 00:37:29,840
that receives the message,

1026
00:37:29,840 --> 00:37:32,360
while the system keeps a controlled fail-over plan elsewhere?

1027
00:37:32,360 --> 00:37:34,160
Can readers prefer a local replica

1028
00:37:34,160 --> 00:37:35,680
without weakening recovery?

1029
00:37:35,680 --> 00:37:38,040
Can asynchronous workloads process data

1030
00:37:38,040 --> 00:37:39,680
near the storage that holds it?

1031
00:37:39,680 --> 00:37:41,640
Those questions don't weaken the architecture.

1032
00:37:41,640 --> 00:37:43,920
They force you to state what it protects against.

1033
00:37:43,920 --> 00:37:46,440
A lot of cloud diagrams use multiple zones

1034
00:37:46,440 --> 00:37:49,040
as a visual signal that the system is serious,

1035
00:37:49,040 --> 00:37:51,280
and fair enough, yet high availability

1036
00:37:51,280 --> 00:37:53,640
isn't achieved by scattering components randomly

1037
00:37:53,640 --> 00:37:55,440
and hoping redundancy sorts itself out.

1038
00:37:55,440 --> 00:37:58,600
It comes from understanding failure modes, data consistency,

1039
00:37:58,600 --> 00:38:00,560
recovery targets, and the traffic created

1040
00:38:00,560 --> 00:38:02,400
while the system operates normally.

1041
00:38:02,400 --> 00:38:04,720
For factory data, this matters because the volume often

1042
00:38:04,720 --> 00:38:07,040
begins at the edge, but grows inside the cloud.

1043
00:38:07,040 --> 00:38:09,520
You may have already filtered the raw stream correctly,

1044
00:38:09,520 --> 00:38:11,480
then lose the benefit because the reduced data

1045
00:38:11,480 --> 00:38:14,000
bounces between broker, processor, database,

1046
00:38:14,000 --> 00:38:17,640
and analytic service across zone boundaries all day.

1047
00:38:17,640 --> 00:38:19,840
So inspect the call path, not just the deployment count,

1048
00:38:19,840 --> 00:38:22,440
for each high volume workload, map where messages land,

1049
00:38:22,440 --> 00:38:24,120
where processing runs, where rights occur,

1050
00:38:24,120 --> 00:38:25,440
and where replicas live.

1051
00:38:25,440 --> 00:38:27,920
Look at the normal path first, failure handling matters,

1052
00:38:27,920 --> 00:38:30,160
but normal traffic is what you pay for every day.

1053
00:38:30,160 --> 00:38:33,640
And even a carefully placed workload can take an expensive detour

1054
00:38:33,640 --> 00:38:36,520
when it passes through certain managed network components.

1055
00:38:36,520 --> 00:38:39,960
NAT, gateways, and the cost of taking the long route.

1056
00:38:39,960 --> 00:38:43,080
Sometimes the expensive path isn't caused by a large sensor stream.

1057
00:38:43,080 --> 00:38:44,040
It comes from rooting.

1058
00:38:44,040 --> 00:38:46,880
A common public AWS reference rate for NAT gateway processing

1059
00:38:46,880 --> 00:38:49,200
is about four and a half cents per gigabyte.

1060
00:38:49,200 --> 00:38:50,960
That charge applies to every byte

1061
00:38:50,960 --> 00:38:53,680
the NAT gateway processes, and it sits on top

1062
00:38:53,680 --> 00:38:56,640
of the normal data transfer charges for the path beyond it.

1063
00:38:56,640 --> 00:38:59,560
So a road can cost more, not because the payload changed,

1064
00:38:59,560 --> 00:39:01,800
but because the packet took an extra stop.

1065
00:39:01,800 --> 00:39:03,760
This matters in factory connectivity patterns

1066
00:39:03,760 --> 00:39:06,720
because edge connectors often sit on a private subnet.

1067
00:39:06,720 --> 00:39:08,600
That's usually the right security posture.

1068
00:39:08,600 --> 00:39:10,960
You don't want a gateway on the shop floor exposed directly

1069
00:39:10,960 --> 00:39:13,360
to the public internet just to publish machine data,

1070
00:39:13,360 --> 00:39:16,120
but private subnet design has a rooting consequence.

1071
00:39:16,120 --> 00:39:17,400
Picture an industrial connector

1072
00:39:17,400 --> 00:39:19,480
that needs to reach a cloud IoT endpoint.

1073
00:39:19,480 --> 00:39:21,600
The connector sits in a private network segment,

1074
00:39:21,600 --> 00:39:23,760
and its outbound traffic routes through a NAT gateway

1075
00:39:23,760 --> 00:39:25,480
then reaches the cloud service.

1076
00:39:25,480 --> 00:39:28,080
Every telemetry record, acknowledgement, configuration

1077
00:39:28,080 --> 00:39:30,320
request, certificate check, and retry passes

1078
00:39:30,320 --> 00:39:31,440
through that component.

1079
00:39:31,440 --> 00:39:33,280
The route works, but the meter runs too.

1080
00:39:33,280 --> 00:39:35,040
Now at the usual factory behavior,

1081
00:39:35,040 --> 00:39:37,040
the edge connector publishes operational records,

1082
00:39:37,040 --> 00:39:38,720
pulls down a new configuration,

1083
00:39:38,720 --> 00:39:41,800
a central service sends a model package or rules update.

1084
00:39:41,800 --> 00:39:44,680
A local system asks for a small reference file.

1085
00:39:44,680 --> 00:39:47,360
Each exchange looks minor when viewed as an individual request,

1086
00:39:47,360 --> 00:39:49,920
but the NAT gateway processes the total volume,

1087
00:39:49,920 --> 00:39:51,680
not just the part that caught your attention.

1088
00:39:51,680 --> 00:39:54,680
The same issue appears with what I call a hairpin path.

1089
00:39:54,680 --> 00:39:56,520
A workload may need to reach a cloud service

1090
00:39:56,520 --> 00:39:57,760
that sits logically close,

1091
00:39:57,760 --> 00:39:59,600
perhaps in the same provider environment,

1092
00:39:59,600 --> 00:40:03,120
but the route still sends traffic out through a NAT device

1093
00:40:03,120 --> 00:40:05,240
and then back to what a service endpoint.

1094
00:40:05,240 --> 00:40:07,160
You end up paying to route internal cloud traffic

1095
00:40:07,160 --> 00:40:09,080
as though it needed a general outbound path.

1096
00:40:09,080 --> 00:40:11,400
That is a design problem, not a sensor problem.

1097
00:40:11,400 --> 00:40:13,120
For certain provider services,

1098
00:40:13,120 --> 00:40:15,320
a private endpoint or service endpoint

1099
00:40:15,320 --> 00:40:17,720
can give the workload a more direct route.

1100
00:40:17,720 --> 00:40:20,560
The exact option depends on the service and your network design,

1101
00:40:20,560 --> 00:40:23,080
so don't treat this as a universal configuration change.

1102
00:40:23,080 --> 00:40:24,400
The point is simpler.

1103
00:40:24,400 --> 00:40:27,520
Before you accept NIT processing as a permanent cost,

1104
00:40:27,520 --> 00:40:30,960
verify whether the traffic genuinely needs to go through NAT.

1105
00:40:30,960 --> 00:40:33,080
I've seen teams start with the correct security pattern,

1106
00:40:33,080 --> 00:40:35,920
then leave the first route in place as the architecture grows.

1107
00:40:35,920 --> 00:40:37,440
A connector goes through NAT

1108
00:40:37,440 --> 00:40:40,160
because that was the fastest way to get a pilot working.

1109
00:40:40,160 --> 00:40:43,480
Later, object storage, monitoring, identity services,

1110
00:40:43,480 --> 00:40:46,480
logging and internal APIs all use the same route.

1111
00:40:46,480 --> 00:40:49,840
The gateway stays in the middle because nobody revisits the network path.

1112
00:40:49,840 --> 00:40:51,720
Then, finance sees a growing NAT line

1113
00:40:51,720 --> 00:40:54,720
and somebody starts asking whether the factory sends too much data.

1114
00:40:54,720 --> 00:40:56,600
Maybe it does, but trace the route first.

1115
00:40:56,600 --> 00:40:58,600
You need packet level and flow level evidence,

1116
00:40:58,600 --> 00:41:00,520
not a guess based on service names.

1117
00:41:00,520 --> 00:41:02,960
Find the source subnet, identify the destination,

1118
00:41:02,960 --> 00:41:05,880
check the route table, firewall path, NIT processing,

1119
00:41:05,880 --> 00:41:07,920
private endpoints and the return path.

1120
00:41:07,920 --> 00:41:09,600
Measure bytes in both directions,

1121
00:41:09,600 --> 00:41:12,680
then map the traffic to the workload that created it.

1122
00:41:12,680 --> 00:41:15,400
A NIT charge tells you traffic passed through NAT,

1123
00:41:15,400 --> 00:41:18,120
but it doesn't tell you whether that traffic came from vibration data,

1124
00:41:18,120 --> 00:41:20,880
log uploads, dashboard refreshes, image transfers,

1125
00:41:20,880 --> 00:41:24,400
or a service that keeps downloading the same file because its cache is wrong.

1126
00:41:24,400 --> 00:41:26,480
That distinction saves a lot of wasted effort.

1127
00:41:26,480 --> 00:41:28,960
Think about a plant where the OT team spends weeks

1128
00:41:28,960 --> 00:41:31,480
reducing telemetry payloads by a few percent

1129
00:41:31,480 --> 00:41:35,120
while a cloud platform service sends large diagnostic archives

1130
00:41:35,120 --> 00:41:37,360
through a NAT path every night.

1131
00:41:37,360 --> 00:41:39,240
Both activities involve data movement,

1132
00:41:39,240 --> 00:41:42,040
but only one of them may explain the cost increase.

1133
00:41:42,040 --> 00:41:44,880
Without route tracing, the team optimizes the visible source

1134
00:41:44,880 --> 00:41:46,600
and misses the expensive route.

1135
00:41:46,600 --> 00:41:49,560
This is why your architecture diagram needs another job.

1136
00:41:49,560 --> 00:41:53,120
It shouldn't just show trust boundaries, protocols, and service names.

1137
00:41:53,120 --> 00:41:54,600
It should show the billing path.

1138
00:41:54,600 --> 00:41:56,560
Draw the edge connector, the private subnet,

1139
00:41:56,560 --> 00:41:58,720
the NIT gateway if traffic uses it,

1140
00:41:58,720 --> 00:42:01,880
the endpoint, the region, and the systems that pull data back.

1141
00:42:01,880 --> 00:42:03,600
Put expected byte volume on the arrows.

1142
00:42:03,600 --> 00:42:06,440
If an arrow crosses a meter at service, label that too.

1143
00:42:06,440 --> 00:42:08,320
An architecture diagram is a billing diagram.

1144
00:42:08,320 --> 00:42:11,280
The symbols may look different, but the bills follow the same path.

1145
00:42:11,280 --> 00:42:14,280
Once you see the route clearly, you can decide whether to keep it,

1146
00:42:14,280 --> 00:42:16,400
replace it with a more direct private path,

1147
00:42:16,400 --> 00:42:19,600
cache data locally, or change the workload itself.

1148
00:42:19,600 --> 00:42:22,080
None of those choices require weakening security.

1149
00:42:22,080 --> 00:42:25,240
They require treating network design as part of the operating cost

1150
00:42:25,240 --> 00:42:26,840
and routing is only one multiplier.

1151
00:42:26,840 --> 00:42:29,520
Replication can turn one stream into several streams

1152
00:42:29,520 --> 00:42:31,160
before anyone notices.

1153
00:42:31,160 --> 00:42:33,560
Replication and backup, the copy problem.

1154
00:42:33,560 --> 00:42:35,240
Replication sounds straightforward.

1155
00:42:35,240 --> 00:42:38,240
Take data from one place and keep another copy somewhere else.

1156
00:42:38,240 --> 00:42:42,320
In a factory setting, that copy might support availability, disaster recovery,

1157
00:42:42,320 --> 00:42:45,520
or a rule that requires data to live in a specific geography.

1158
00:42:45,520 --> 00:42:48,400
Those are all valid reasons, but they aren't the same reason

1159
00:42:48,400 --> 00:42:50,440
and mixing them up is where the trouble starts.

1160
00:42:50,440 --> 00:42:53,280
Cross-region replication usually appears when a team wants protection

1161
00:42:53,280 --> 00:42:57,520
from a regional outage, needs a recovery copy closer to another business location

1162
00:42:57,520 --> 00:43:00,080
or has to meet data residency requirements.

1163
00:43:00,080 --> 00:43:02,680
A cloud storage service can automatically copy new objects

1164
00:43:02,680 --> 00:43:05,080
from one region to another, and that feels reassuring.

1165
00:43:05,080 --> 00:43:09,280
It should, but every object copied is also data moving out of the source region,

1166
00:43:09,280 --> 00:43:10,520
and that movement has a cost.

1167
00:43:10,520 --> 00:43:15,360
Public examples for S3 cross-region replication can fall somewhere around two to nine cents per GB,

1168
00:43:15,360 --> 00:43:17,440
depending on the source and destination regions.

1169
00:43:17,440 --> 00:43:21,200
Don't use that range as your budget number, your provider, regions, service tier,

1170
00:43:21,200 --> 00:43:23,200
and contract decide the real charge.

1171
00:43:23,200 --> 00:43:26,120
Use it as a reminder that replication is an active data path,

1172
00:43:26,120 --> 00:43:28,240
not a free setting you tick once and forget.

1173
00:43:28,240 --> 00:43:32,560
For a small set of curated production records, that cost may be entirely reasonable.

1174
00:43:32,560 --> 00:43:36,760
For raw images, continuous waveforms or large local diagnostic buffers,

1175
00:43:36,760 --> 00:43:39,400
copying everything to a second region can double the movement

1176
00:43:39,400 --> 00:43:41,480
before a single person has used the data.

1177
00:43:41,480 --> 00:43:43,840
The same confusion shows up with backup.

1178
00:43:43,840 --> 00:43:46,040
A retention policy answers one question.

1179
00:43:46,040 --> 00:43:48,200
How long should this data remain available?

1180
00:43:48,200 --> 00:43:50,840
A replication policy answers a different one.

1181
00:43:50,840 --> 00:43:52,480
How many copies need to exist?

1182
00:43:52,480 --> 00:43:53,480
Where should they live?

1183
00:43:53,480 --> 00:43:56,840
And how quickly must one replace the other after a failure?

1184
00:43:56,840 --> 00:44:00,360
Those policies often get mixed together because both involve copies,

1185
00:44:00,360 --> 00:44:01,840
but they solve different problems.

1186
00:44:01,840 --> 00:44:05,520
You might retain a local raw waveform buffer for a short diagnostic period

1187
00:44:05,520 --> 00:44:07,120
then deleted when the window expires.

1188
00:44:07,120 --> 00:44:08,160
That is retention.

1189
00:44:08,160 --> 00:44:11,200
You might keep a curated set of anomaly records in a second cloud region,

1190
00:44:11,200 --> 00:44:15,560
so a regional incident doesn't remove your ability to investigate a serious quality event.

1191
00:44:15,560 --> 00:44:16,680
That is replication.

1192
00:44:16,680 --> 00:44:18,160
One does not imply the other.

1193
00:44:18,160 --> 00:44:22,520
A common failure pattern starts when teams decide to retain raw data for a long time,

1194
00:44:22,520 --> 00:44:25,920
then replicate it because long term data feels important,

1195
00:44:25,920 --> 00:44:30,600
then add another backup because the replicated copy doesn't meet the recovery rule.

1196
00:44:30,600 --> 00:44:35,320
Soon, one stream exists in primary storage, secondary storage,

1197
00:44:35,320 --> 00:44:39,520
a backup vault, an export location, and perhaps a vendor managed archive.

1198
00:44:39,520 --> 00:44:41,240
Every copy has a purpose on paper.

1199
00:44:41,240 --> 00:44:42,920
Few teams can explain the whole set.

1200
00:44:42,920 --> 00:44:44,880
Backup exports can create a similar problem,

1201
00:44:44,880 --> 00:44:47,200
a side sends data to a cloud backup service,

1202
00:44:47,200 --> 00:44:51,160
then a scheduled process exports it to another environment for compliance or independent recovery.

1203
00:44:51,160 --> 00:44:54,200
Again, that may be justified, but the export itself moves bytes,

1204
00:44:54,200 --> 00:44:55,920
and a restore can move even more.

1205
00:44:55,920 --> 00:44:58,440
The restore path deserves special attention

1206
00:44:58,440 --> 00:45:01,720
because it often remains theoretical until a drill begins.

1207
00:45:01,720 --> 00:45:04,080
Picture a recovery test after a production incident.

1208
00:45:04,080 --> 00:45:07,760
The team needs a historical data set back at the plant or in a recovery environment,

1209
00:45:07,760 --> 00:45:10,440
so they can rebuild the service and validate the records.

1210
00:45:10,440 --> 00:45:13,360
Suddenly, data that sat quietly in remote storage

1211
00:45:13,360 --> 00:45:16,200
must travel back across the network under time pressure.

1212
00:45:16,200 --> 00:45:19,080
The question is no longer just, do we have a backup?

1213
00:45:19,080 --> 00:45:20,560
It becomes,

1214
00:45:20,560 --> 00:45:25,080
can we retrieve the required data within the recovery target at an acceptable cost

1215
00:45:25,080 --> 00:45:26,920
and in a form the plant can use?

1216
00:45:26,920 --> 00:45:29,520
That is why disaster recovery drills matter.

1217
00:45:29,520 --> 00:45:32,960
They expose the difference between a backup object and a recoverable system.

1218
00:45:32,960 --> 00:45:36,480
They also reveal whether a large restore produces a transfer charge

1219
00:45:36,480 --> 00:45:38,360
that nobody included in the annual plan.

1220
00:45:38,360 --> 00:45:41,200
You don't need fewer copies by default, you need intentional copies.

1221
00:45:41,200 --> 00:45:44,760
For every replica, backup and export require four answers.

1222
00:45:44,760 --> 00:45:46,640
What risk does this copy protect against?

1223
00:45:46,640 --> 00:45:48,680
What recovery target does it support?

1224
00:45:48,680 --> 00:45:50,160
Who owns the decision to keep it?

1225
00:45:50,160 --> 00:45:53,880
When should the copy expire or move into a lower cost retention state?

1226
00:45:53,880 --> 00:45:55,720
If the team cannot answer those questions,

1227
00:45:55,720 --> 00:45:57,480
the copy has no operational contract.

1228
00:45:57,480 --> 00:46:00,360
It may still exist for a good reason, but nobody has proven it.

1229
00:46:00,360 --> 00:46:03,080
The aim isn't to make recovery cheap by weakening it.

1230
00:46:03,080 --> 00:46:06,920
The aim is to avoid replicating data that doesn't support a defined recovery need

1231
00:46:06,920 --> 00:46:08,720
while protecting the records that do.

1232
00:46:08,720 --> 00:46:14,200
That gives IT, OT, security and finance a shared way to talk about what each copy actually does.

1233
00:46:14,200 --> 00:46:16,720
And replication is only part of the movement story.

1234
00:46:16,720 --> 00:46:19,800
The factory also pulls data back for daily work.

1235
00:46:19,800 --> 00:46:23,240
The return path reports, exports and remote access.

1236
00:46:23,240 --> 00:46:25,600
A lot of cloud cost discussions stop at ingestion.

1237
00:46:25,600 --> 00:46:27,600
Data leaves the factory, lands in the cloud,

1238
00:46:27,600 --> 00:46:30,000
and the project team counts that as the root.

1239
00:46:30,000 --> 00:46:31,600
But people still need to use the data.

1240
00:46:31,600 --> 00:46:35,040
A production manager opens a Power BI dashboard from the plant network.

1241
00:46:35,040 --> 00:46:38,160
An engineer exports a data set to investigate a quality issue.

1242
00:46:38,160 --> 00:46:40,440
A supplier receives a file through an API.

1243
00:46:40,440 --> 00:46:42,680
A local tool pulls records from a cloud database

1244
00:46:42,680 --> 00:46:45,080
because someone connected it that way during a pilot.

1245
00:46:45,080 --> 00:46:47,160
Each of those actions creates a return path.

1246
00:46:47,160 --> 00:46:50,160
The cloud does not just collect factory data, it serves it back out.

1247
00:46:50,160 --> 00:46:51,960
Take a normal analytics pattern.

1248
00:46:51,960 --> 00:46:55,360
A central data platform processes production and quality records,

1249
00:46:55,360 --> 00:46:59,040
then sends a scheduled extract to an on-premises reporting tool every morning.

1250
00:46:59,040 --> 00:47:03,080
The file might contain a day of machine events, production facts and quality results.

1251
00:47:03,080 --> 00:47:04,000
That sounds harmless.

1252
00:47:04,000 --> 00:47:06,000
And for the right data set, it probably is.

1253
00:47:06,000 --> 00:47:08,480
The problem begins when the extract includes raw records

1254
00:47:08,480 --> 00:47:11,240
because nobody decided what the receiving tool actually needs.

1255
00:47:11,240 --> 00:47:14,320
A local report may only need downtime events by asset and shift.

1256
00:47:14,320 --> 00:47:17,520
Instead, it receives high detailed telemetry for every machine

1257
00:47:17,520 --> 00:47:20,080
because the source query selects everything available.

1258
00:47:20,080 --> 00:47:23,960
The report still shows one chart, the network still moves the full file.

1259
00:47:23,960 --> 00:47:25,680
And when the report refreshes every day,

1260
00:47:25,680 --> 00:47:28,040
that path becomes a recurring operating cost.

1261
00:47:28,040 --> 00:47:31,040
The same pattern appears with suppliers and external services.

1262
00:47:31,040 --> 00:47:35,160
A supplier may need evidence tied to a defect, a batch or a maintenance claim.

1263
00:47:35,160 --> 00:47:37,880
That is a defined request with a defined data set.

1264
00:47:37,880 --> 00:47:39,800
But APIs often grow without discipline.

1265
00:47:39,800 --> 00:47:42,160
Somebody starts with a useful integration,

1266
00:47:42,160 --> 00:47:45,520
then adds more fields, more history, more frequent calls,

1267
00:47:45,520 --> 00:47:49,080
and a retry process that asks for the same records again.

1268
00:47:49,080 --> 00:47:51,800
Soon the API becomes an export route nobody owns.

1269
00:47:51,800 --> 00:47:53,920
Remote dashboards deserve the same attention.

1270
00:47:53,920 --> 00:47:55,880
When people at the plant view a cloud dashboard,

1271
00:47:55,880 --> 00:47:58,600
the browser requests data, visuals, filters,

1272
00:47:58,600 --> 00:48:01,240
and refresh results across the site connection.

1273
00:48:01,240 --> 00:48:04,680
One person looking at a shift report isn't likely to concern anyone.

1274
00:48:04,680 --> 00:48:06,840
A control room wallboard repeated browser sessions,

1275
00:48:06,840 --> 00:48:09,960
auto refresh pages, and multiple teams checking the same detailed view

1276
00:48:09,960 --> 00:48:11,240
create ongoing traffic.

1277
00:48:11,240 --> 00:48:12,600
That traffic may be worth it.

1278
00:48:12,600 --> 00:48:14,320
Real-time visibility often is.

1279
00:48:14,320 --> 00:48:16,160
Still, ask what the screen must show.

1280
00:48:16,160 --> 00:48:19,040
Does an operator need years of raw history rendered in a chart?

1281
00:48:19,040 --> 00:48:21,920
Or do they need the current machine state, the active alarm,

1282
00:48:21,920 --> 00:48:24,840
the last stop reason, and a clear next action?

1283
00:48:24,840 --> 00:48:25,920
Those are different workloads.

1284
00:48:25,920 --> 00:48:28,680
For local operational use, a local cache can help.

1285
00:48:28,680 --> 00:48:32,400
If the same site users repeatedly read the same approved data set,

1286
00:48:32,400 --> 00:48:34,680
keep a controlled copy near the consumer,

1287
00:48:34,680 --> 00:48:36,680
rather than asking every browser session

1288
00:48:36,680 --> 00:48:40,080
to pull the same content across the wall.

1289
00:48:40,080 --> 00:48:43,280
That cache needs a refresh rule, a clear source, and a known limit.

1290
00:48:43,280 --> 00:48:46,040
Otherwise, it becomes another unofficial database,

1291
00:48:46,040 --> 00:48:48,280
which nobody enjoys discovering during an incident.

1292
00:48:48,280 --> 00:48:50,120
Scheduled extracts can work the same way

1293
00:48:50,120 --> 00:48:52,080
when they match the decision cadence.

1294
00:48:52,080 --> 00:48:54,920
If a planning team reviews yesterday's output each morning,

1295
00:48:54,920 --> 00:48:58,800
provide one defined extract at the right time in the smallest useful form,

1296
00:48:58,800 --> 00:49:00,400
don't keep a live stream open all day

1297
00:49:00,400 --> 00:49:02,760
because the architecture happened to make it possible.

1298
00:49:02,760 --> 00:49:05,520
A scheduled data product gives the consumer what they need

1299
00:49:05,520 --> 00:49:07,320
and makes the network path visible.

1300
00:49:07,320 --> 00:49:09,000
There is also a human habit behind this.

1301
00:49:09,000 --> 00:49:12,000
When cloud data is easy to access, people often assume

1302
00:49:12,000 --> 00:49:14,000
more detail produces a better answer.

1303
00:49:14,000 --> 00:49:15,040
Sometimes it does.

1304
00:49:15,040 --> 00:49:18,480
For investigation work, raw evidence may be exactly what an engineer needs.

1305
00:49:18,480 --> 00:49:21,680
For daily operations, excess detail can slow the decision down.

1306
00:49:21,680 --> 00:49:24,240
Imagine a line lead responding to a machine stop.

1307
00:49:24,240 --> 00:49:26,440
They don't need to download a large history file

1308
00:49:26,440 --> 00:49:29,080
and inspect every signal trend before they can act.

1309
00:49:29,080 --> 00:49:31,360
They need to know the asset, the condition, the order context,

1310
00:49:31,360 --> 00:49:33,600
the duration, and who needs to respond.

1311
00:49:33,600 --> 00:49:34,560
Give them that first.

1312
00:49:34,560 --> 00:49:37,000
Make deeper evidence available when the case calls for it.

1313
00:49:37,000 --> 00:49:39,720
This is not an argument for hiding data from people.

1314
00:49:39,720 --> 00:49:42,640
It is an argument for serving data in forms that match the job.

1315
00:49:42,640 --> 00:49:44,280
The operator needs a current decision.

1316
00:49:44,280 --> 00:49:47,160
The reliability engineer may need a bounded evidence package.

1317
00:49:47,160 --> 00:49:50,480
The central improvement team may need a govern trend set across sites.

1318
00:49:50,480 --> 00:49:53,200
One broad export cannot meet all three needs efficiently,

1319
00:49:53,200 --> 00:49:55,280
even if it technically contains everything.

1320
00:49:55,280 --> 00:49:58,320
So map every return path with the same care you apply to ingestion.

1321
00:49:58,320 --> 00:49:59,400
Who consumes the data?

1322
00:49:59,400 --> 00:50:00,120
Where are they?

1323
00:50:00,120 --> 00:50:01,280
How often do they read it?

1324
00:50:01,280 --> 00:50:02,520
What level of detail do they need?

1325
00:50:02,520 --> 00:50:05,720
Can a cache, a smaller view, or a scheduled extract meet the need

1326
00:50:05,720 --> 00:50:07,520
without repeated full transfers?

1327
00:50:07,520 --> 00:50:10,000
Once you start looking, cloud charges stop appearing

1328
00:50:10,000 --> 00:50:11,280
in one need category.

1329
00:50:11,280 --> 00:50:13,360
They hide across storage reads, network transfer,

1330
00:50:13,360 --> 00:50:16,200
gateways, reporting services, backup tools, and application

1331
00:50:16,200 --> 00:50:17,200
integrations.

1332
00:50:17,200 --> 00:50:19,480
Read the invoice as a data flow map.

1333
00:50:19,480 --> 00:50:21,800
Once charges start appearing across several services,

1334
00:50:21,800 --> 00:50:24,280
the invoice becomes more than just a finance document.

1335
00:50:24,280 --> 00:50:26,720
It becomes a partial map of how data actually

1336
00:50:26,720 --> 00:50:28,320
moves through your architecture.

1337
00:50:28,320 --> 00:50:31,080
Sure, start with the obvious labels, but don't stop there.

1338
00:50:31,080 --> 00:50:33,240
You need to look for things like data transfer,

1339
00:50:33,240 --> 00:50:35,280
out regional transfer, interzone traffic,

1340
00:50:35,280 --> 00:50:37,400
natty processing, private endpoint processing,

1341
00:50:37,400 --> 00:50:40,520
and charges tied to APIs, reporting tools, backup services,

1342
00:50:40,520 --> 00:50:41,800
or managed connectors.

1343
00:50:41,800 --> 00:50:43,720
The label names vary by provider and service,

1344
00:50:43,720 --> 00:50:45,560
which is annoying but perfectly normal.

1345
00:50:45,560 --> 00:50:47,480
And your job is to translate each billing line

1346
00:50:47,480 --> 00:50:49,160
into a real technical route.

1347
00:50:49,160 --> 00:50:51,400
When you see a line called regional data transfer,

1348
00:50:51,400 --> 00:50:53,840
it should lead to a specific question, which workload

1349
00:50:53,840 --> 00:50:57,040
moved data between regions, from where, and for what purpose.

1350
00:50:57,040 --> 00:51:00,040
A natty processing charge needs to point to a subnet root table

1351
00:51:00,040 --> 00:51:01,400
and set of destinations.

1352
00:51:01,400 --> 00:51:03,000
Zone traffic should map to workloads

1353
00:51:03,000 --> 00:51:05,000
that talk across availability zones.

1354
00:51:05,000 --> 00:51:06,600
And if you can't connect a billing label

1355
00:51:06,600 --> 00:51:08,360
to an architecture component, you still

1356
00:51:08,360 --> 00:51:09,760
don't know what you're paying for.

1357
00:51:09,760 --> 00:51:11,560
Don't accept the platform as an answer.

1358
00:51:11,560 --> 00:51:13,520
For every material transfer charge,

1359
00:51:13,520 --> 00:51:16,120
tag it with the same context you use to run the plant,

1360
00:51:16,120 --> 00:51:19,440
which plant created it, which line or cell produced the data,

1361
00:51:19,440 --> 00:51:22,600
which workload used the path, what class of data moved,

1362
00:51:22,600 --> 00:51:26,320
machine events, images, engineering files, logs,

1363
00:51:26,320 --> 00:51:30,160
MES facts, and who owns the cost decision.

1364
00:51:30,160 --> 00:51:31,920
That last part changes the conversation.

1365
00:51:31,920 --> 00:51:35,440
Here's the thing, an OT engineer may own the source signal,

1366
00:51:35,440 --> 00:51:37,680
a platform team may own the gateway and root,

1367
00:51:37,680 --> 00:51:39,920
and a data team may own the cloud pipeline.

1368
00:51:39,920 --> 00:51:42,720
Finance sees one invoice, while four teams each see only

1369
00:51:42,720 --> 00:51:43,760
their own piece.

1370
00:51:43,760 --> 00:51:46,040
Cost attribution gives those teams a shared object

1371
00:51:46,040 --> 00:51:48,960
to discuss instead of a vague complaint about cloud spend.

1372
00:51:48,960 --> 00:51:50,920
Use tags where the platform supports them,

1373
00:51:50,920 --> 00:51:53,520
but don't assume resource tags solve everything.

1374
00:51:53,520 --> 00:51:56,560
Network charges often attach to shared infrastructure.

1375
00:51:56,560 --> 00:51:58,360
One in Attic Gateway may carry traffic

1376
00:51:58,360 --> 00:52:00,400
for several workloads, and one message broker

1377
00:52:00,400 --> 00:52:02,160
may serve several plans.

1378
00:52:02,160 --> 00:52:04,560
To split shared costs in a way people can trust,

1379
00:52:04,560 --> 00:52:07,560
you'll need billing exports, flow data, application metrics,

1380
00:52:07,560 --> 00:52:09,520
and architecture records altogether.

1381
00:52:09,520 --> 00:52:11,360
That takes effort, but it's still less effort

1382
00:52:11,360 --> 00:52:13,480
than arguing from guesses every quarter.

1383
00:52:13,480 --> 00:52:15,960
A good review starts by linking billing account labels

1384
00:52:15,960 --> 00:52:18,800
to actual things, not product names, but actual things,

1385
00:52:18,800 --> 00:52:21,720
like this charge comes from the route used by LineForce edge

1386
00:52:21,720 --> 00:52:24,840
connector, or this charge comes from a cross-region copy

1387
00:52:24,840 --> 00:52:28,200
of defect images, or this one comes from a dashboard data set

1388
00:52:28,200 --> 00:52:30,640
pulled by the site reporting tool, and this one

1389
00:52:30,640 --> 00:52:32,560
belongs to a shared platform service

1390
00:52:32,560 --> 00:52:35,360
with cost divided across the plants that use it.

1391
00:52:35,360 --> 00:52:37,080
Once you can speak that clearly, the invoice

1392
00:52:37,080 --> 00:52:38,640
stops being mysterious.

1393
00:52:38,640 --> 00:52:41,720
Then compare bytes moved with bytes that served a named use case.

1394
00:52:41,720 --> 00:52:43,800
This is where many data paths fail the test.

1395
00:52:43,800 --> 00:52:45,560
You might find that a large volume of records

1396
00:52:45,560 --> 00:52:47,480
supports an active maintenance process,

1397
00:52:47,480 --> 00:52:50,240
a traceability requirement, or a cross-plant quality study.

1398
00:52:50,240 --> 00:52:52,600
Fine, that movement has a stated purpose.

1399
00:52:52,600 --> 00:52:54,480
Then you can decide whether the route, retention,

1400
00:52:54,480 --> 00:52:56,280
and cost match that purpose.

1401
00:52:56,280 --> 00:52:59,120
But you may also find traffic with no named consumer at all.

1402
00:52:59,120 --> 00:53:01,800
Data arrives because a collector was configured years ago.

1403
00:53:01,800 --> 00:53:04,360
A duplicate pipeline still runs after a migration

1404
00:53:04,360 --> 00:53:06,840
or a service exports more detail than the receiving system

1405
00:53:06,840 --> 00:53:07,560
reads.

1406
00:53:07,560 --> 00:53:09,240
The bytes exist in the bill, but nobody

1407
00:53:09,240 --> 00:53:10,880
can name the decision they support.

1408
00:53:10,880 --> 00:53:12,520
That is the traffic to challenge first.

1409
00:53:12,520 --> 00:53:15,040
I'd set up a monthly data flow review with IT, OT,

1410
00:53:15,040 --> 00:53:17,000
finance, and security in the same room,

1411
00:53:17,000 --> 00:53:18,480
or at least on the same call.

1412
00:53:18,480 --> 00:53:19,320
Keep it practical.

1413
00:53:19,320 --> 00:53:21,400
Bring the top transfer charges, the routes behind them,

1414
00:53:21,400 --> 00:53:23,960
the data classes involved, and the owners who can explain them.

1415
00:53:23,960 --> 00:53:26,080
OT can confirm whether a stream still supports

1416
00:53:26,080 --> 00:53:27,280
production or maintenance.

1417
00:53:27,280 --> 00:53:29,720
IT can explain topology and service behavior.

1418
00:53:29,720 --> 00:53:31,560
Security can check whether an easier route

1419
00:53:31,560 --> 00:53:33,240
creates unacceptable exposure.

1420
00:53:33,240 --> 00:53:35,040
And finance can show the trend and make sure

1421
00:53:35,040 --> 00:53:37,320
the charge reaches the right budget owner.

1422
00:53:37,320 --> 00:53:39,720
Nobody needs a two-hour governance ceremony.

1423
00:53:39,720 --> 00:53:42,240
They need a repeatable review where unexplained traffic gets

1424
00:53:42,240 --> 00:53:43,520
an owner in the next action.

1425
00:53:43,520 --> 00:53:46,000
That's how cost control becomes part of architecture work

1426
00:53:46,000 --> 00:53:49,360
rather than an emergency exercise after the invoice arrives.

1427
00:53:49,360 --> 00:53:51,160
And the first real step isn't a vendor meeting,

1428
00:53:51,160 --> 00:53:52,160
but it's a model.

1429
00:53:52,160 --> 00:53:54,240
It's a workload inventory.

1430
00:53:54,240 --> 00:53:56,200
Inventory the data before you move it.

1431
00:53:56,200 --> 00:53:58,400
Before changing a route, buying more edge hardware

1432
00:53:58,400 --> 00:54:00,560
or negotiating with a cloud provider,

1433
00:54:00,560 --> 00:54:03,240
build an inventory of the data you already collect.

1434
00:54:03,240 --> 00:54:05,080
Most plants don't lack data.

1435
00:54:05,080 --> 00:54:07,520
They lack a clear list of what exists, where it starts,

1436
00:54:07,520 --> 00:54:08,720
and why it keeps moving.

1437
00:54:08,720 --> 00:54:11,200
Started the sources list the PLC tags collected

1438
00:54:11,200 --> 00:54:14,280
from each machine or cell, including the historian feeds,

1439
00:54:14,280 --> 00:54:16,960
vibration sensors, cameras, machine logs,

1440
00:54:16,960 --> 00:54:19,800
each application logs, and MS events.

1441
00:54:19,800 --> 00:54:22,680
Don't stop at the systems your central ITT modes.

1442
00:54:22,680 --> 00:54:24,960
Include data from condition monitoring vendors,

1443
00:54:24,960 --> 00:54:27,240
quality systems, maintenance tools,

1444
00:54:27,240 --> 00:54:29,840
and any portal that pulls data from the plant.

1445
00:54:29,840 --> 00:54:32,640
The list will get longer than expected, and that's useful.

1446
00:54:32,640 --> 00:54:34,800
For each source, record its rate.

1447
00:54:34,800 --> 00:54:37,600
A tag may change once per shift, every second,

1448
00:54:37,600 --> 00:54:40,840
or many times per second, and capture payload size as well.

1449
00:54:40,840 --> 00:54:42,560
A simple state value and an image frame

1450
00:54:42,560 --> 00:54:45,440
shouldn't sit in the same column with the same assumed cost.

1451
00:54:45,440 --> 00:54:47,120
Then record burst behavior.

1452
00:54:47,120 --> 00:54:48,600
Some sources produce a steady stream,

1453
00:54:48,600 --> 00:54:51,720
while others stay quiet until a machine fault, network issue,

1454
00:54:51,720 --> 00:54:55,080
recipe change, or inspection failure, causes a sudden spike.

1455
00:54:55,080 --> 00:54:57,440
A camera system may send little during normal work,

1456
00:54:57,440 --> 00:55:00,040
then upload a sequence of defect images after an event.

1457
00:55:00,040 --> 00:55:01,520
A log collector may remain modest

1458
00:55:01,520 --> 00:55:03,520
until an application starts failing,

1459
00:55:03,520 --> 00:55:05,840
and turns into a very enthusiastic writer.

1460
00:55:05,840 --> 00:55:09,240
Those bursts shape storage, network capacity, and cost,

1461
00:55:09,240 --> 00:55:11,440
and they also shape recovery planning.

1462
00:55:11,440 --> 00:55:15,240
Add the retention rule next, even when the honest answer is unknown.

1463
00:55:15,240 --> 00:55:17,600
How long does the rule record remain at the source?

1464
00:55:17,600 --> 00:55:20,520
How long does it stay in the historian, the local server,

1465
00:55:20,520 --> 00:55:22,840
the cloud platform, or a vendor portal?

1466
00:55:22,840 --> 00:55:26,120
If a stream has no clear retention period, market.

1467
00:55:26,120 --> 00:55:29,000
That stream needs attention, because no rule

1468
00:55:29,000 --> 00:55:31,440
usually means it will continue accumulating.

1469
00:55:31,440 --> 00:55:33,640
Sensitivity belongs in the inventory, too.

1470
00:55:33,640 --> 00:55:35,320
Some data exposes machine settings,

1471
00:55:35,320 --> 00:55:37,320
recipes, product detail, customer orders,

1472
00:55:37,320 --> 00:55:39,520
or process knowledge that shouldn't travel freely,

1473
00:55:39,520 --> 00:55:41,040
while other data may appear harmless

1474
00:55:41,040 --> 00:55:44,560
until you combine it with MES context and production schedules.

1475
00:55:44,560 --> 00:55:47,280
The inventory needs to describe the data as a business asset,

1476
00:55:47,280 --> 00:55:50,120
not just as a technical payload, and name the consumer

1477
00:55:50,120 --> 00:55:53,520
who reads this data today, align supervisor, maintenance,

1478
00:55:53,520 --> 00:55:55,800
quality, a central engineering group,

1479
00:55:55,800 --> 00:55:59,160
an external equipment supplier, or a data scientist.

1480
00:55:59,160 --> 00:56:01,400
The cloud platform isn't a consumer,

1481
00:56:01,400 --> 00:56:03,360
and neither is analytics.

1482
00:56:03,360 --> 00:56:06,520
Name the role, system, or process that uses the record,

1483
00:56:06,520 --> 00:56:08,960
that one field cuts through a surprising amount of noise.

1484
00:56:08,960 --> 00:56:12,480
Next, identify the streams that already pass through an edge gateway,

1485
00:56:12,480 --> 00:56:14,480
industrial PC, or historian.

1486
00:56:14,480 --> 00:56:16,760
In many plants, local processing already exists,

1487
00:56:16,760 --> 00:56:18,840
even if nobody calls it edge architecture.

1488
00:56:18,840 --> 00:56:21,240
The historian may collect tags, apply compression,

1489
00:56:21,240 --> 00:56:23,200
and retain detailed records locally,

1490
00:56:23,200 --> 00:56:26,440
while an edge gateway may translate protocols, buffer messages,

1491
00:56:26,440 --> 00:56:30,000
or calculate a basic condition result before anything leaves the site.

1492
00:56:30,000 --> 00:56:33,360
Don't ignore those layers just because they predate the current IoT project.

1493
00:56:33,360 --> 00:56:36,760
They may already hold the right place to filter, shape, or retain data,

1494
00:56:36,760 --> 00:56:40,520
or they may create an extra collector that sends the same value somewhere else.

1495
00:56:40,520 --> 00:56:44,000
You need to see both cases before you add another component.

1496
00:56:44,000 --> 00:56:45,240
Now look for duplication.

1497
00:56:45,240 --> 00:56:47,000
This is where inventories get uncomfortable.

1498
00:56:47,000 --> 00:56:52,080
One PLC tag may feed the historian, an MES connector, an IoT gateway,

1499
00:56:52,080 --> 00:56:53,880
and a maintenance application.

1500
00:56:53,880 --> 00:56:56,800
Each connection might have started with a valid purpose,

1501
00:56:56,800 --> 00:56:59,480
but over time, teams often create parallel routes

1502
00:56:59,480 --> 00:57:03,240
because it feels faster than finding and reusing the existing one.

1503
00:57:03,240 --> 00:57:06,120
The same problem shows up outside the formal architecture.

1504
00:57:06,120 --> 00:57:09,800
Someone exports a spreadsheet each day, and uploads it to a shared site.

1505
00:57:09,800 --> 00:57:12,320
An engineer downloads data from a vendor portal

1506
00:57:12,320 --> 00:57:15,240
because the central system doesn't expose it in the right form,

1507
00:57:15,240 --> 00:57:17,480
or a supplier tool keeps its own archive,

1508
00:57:17,480 --> 00:57:20,080
while the plant retains another copy locally.

1509
00:57:20,080 --> 00:57:21,320
These are shadow exports.

1510
00:57:21,320 --> 00:57:23,520
They're often invisible until a data quality issue,

1511
00:57:23,520 --> 00:57:26,400
security review, or invoice forces someone to trace them.

1512
00:57:26,400 --> 00:57:29,080
Don't treat the people behind those workarounds as the problem.

1513
00:57:29,080 --> 00:57:32,160
They usually created them because the approved path didn't meet a real need.

1514
00:57:32,160 --> 00:57:34,880
The job is to capture that need, then decide whether the workaround

1515
00:57:34,880 --> 00:57:37,200
should become a supported data product or disappear.

1516
00:57:37,200 --> 00:57:39,760
For every stream, document the decision it supports,

1517
00:57:39,760 --> 00:57:41,400
and keep the wording plain.

1518
00:57:41,400 --> 00:57:43,640
Like, detect the developing bearing fault,

1519
00:57:43,640 --> 00:57:47,480
explain a quality reject, confirm production against a work order,

1520
00:57:47,480 --> 00:57:51,400
review energy used by shift, or provide remote support evidence.

1521
00:57:51,400 --> 00:57:54,680
If you can't write a sentence like that, flag the stream for review.

1522
00:57:54,680 --> 00:57:59,640
It may still deserve to exist, but it hasn't earned automatic movement, storage, or replication.

1523
00:57:59,640 --> 00:58:01,080
Once the inventory is real,

1524
00:58:01,080 --> 00:58:02,760
the next question gets much easier.

1525
00:58:02,760 --> 00:58:04,600
Where should the processing actually happen?

1526
00:58:04,600 --> 00:58:07,120
Edge is a processing layer, not a smaller cloud.

1527
00:58:07,120 --> 00:58:09,160
So you've got that inventory of what exists,

1528
00:58:09,160 --> 00:58:12,600
and now you need to decide where the first useful work should actually happen.

1529
00:58:12,600 --> 00:58:16,760
When I say edge, I mean compute and storage placed near the source of the data,

1530
00:58:16,760 --> 00:58:19,320
usually inside the plant or at the side boundary.

1531
00:58:19,320 --> 00:58:22,960
It might run on an industrial PC, a gateway, a local server,

1532
00:58:22,960 --> 00:58:24,960
or an existing historian environment,

1533
00:58:24,960 --> 00:58:28,680
and the hardware matters less than the role it plays in the data path.

1534
00:58:28,680 --> 00:58:33,280
Its job starts where the raw signal appears, which is usually in formats that enterprise systems

1535
00:58:33,280 --> 00:58:34,840
don't understand directly.

1536
00:58:34,840 --> 00:58:37,080
You may have OPC UA from a newer controller,

1537
00:58:37,080 --> 00:58:39,080
a vendor protocol from an older machine,

1538
00:58:39,080 --> 00:58:41,040
Modbus values from utility meter,

1539
00:58:41,040 --> 00:58:43,000
or files from an inspection station,

1540
00:58:43,000 --> 00:58:47,440
and the edge layer handles that local mess before it becomes someone else's integration problem.

1541
00:58:47,440 --> 00:58:49,560
That's exactly where protocol handling should live.

1542
00:58:49,560 --> 00:58:53,120
The edge can do the work of reading local signals, normalizing timestamps,

1543
00:58:53,120 --> 00:58:54,680
attaching an asset identity,

1544
00:58:54,680 --> 00:58:56,120
converting units where needed,

1545
00:58:56,120 --> 00:58:59,400
and keeping the context that tells you what a value actually means.

1546
00:58:59,400 --> 00:59:03,720
A temperature reading, without a sensor location, unit, tag definition,

1547
00:59:03,720 --> 00:59:05,880
and quality state is just a number,

1548
00:59:05,880 --> 00:59:08,120
traveling through expensive infrastructure.

1549
00:59:08,120 --> 00:59:12,680
That context is what turns a raw number into operational data you can actually use.

1550
00:59:12,680 --> 00:59:14,520
Now, the edge also buffers data,

1551
00:59:14,520 --> 00:59:17,880
when the outside connection drops, slows down, or becomes unavailable.

1552
00:59:17,880 --> 00:59:20,920
The plant continues producing because machines don't pause politely

1553
00:59:20,920 --> 00:59:24,200
when a one-rowed or cloud service has a bad afternoon,

1554
00:59:24,200 --> 00:59:28,680
and local storage gives the system somewhere safe to hold records until the connection returns

1555
00:59:28,680 --> 00:59:33,640
with a defined limit and a clear rule for what happens when that limit approaches.

1556
00:59:33,640 --> 00:59:36,600
That's plant continuity, not some optional extra feature.

1557
00:59:36,600 --> 00:59:39,080
Then the edge can apply the first processing step,

1558
00:59:39,080 --> 00:59:41,400
removing duplicates, detecting a state change,

1559
00:59:41,400 --> 00:59:43,720
combining related signals, creating a local event,

1560
00:59:43,720 --> 00:59:47,720
or retaining the most detailed form where the site can actually use it.

1561
00:59:47,720 --> 00:59:49,880
This work happens near the machine context,

1562
00:59:49,880 --> 00:59:53,960
before a generic cloud pipeline tries to infer what a stream meant after the fact.

1563
00:59:53,960 --> 00:59:58,440
Local state matters here too, because a machine doesn't exist as a set of disconnected values.

1564
00:59:58,440 --> 01:00:00,920
It runs through states, transitions, recipes,

1565
01:00:00,920 --> 01:00:03,560
changers, alarms, pauses, and recovery actions.

1566
01:00:03,560 --> 01:00:06,680
An edge service can retain the current state of a machine or cell

1567
01:00:06,680 --> 01:00:09,080
and interpret the next input against that state,

1568
01:00:09,080 --> 01:00:11,720
which lets it tell the difference between a brief sensor glitch

1569
01:00:11,720 --> 01:00:14,920
and a real operating change because it has seen the sequence locally.

1570
01:00:14,920 --> 01:00:17,720
That's a much better starting point for real-time visibility,

1571
01:00:17,720 --> 01:00:20,200
but let me separate two things that often get mixed together.

1572
01:00:20,200 --> 01:00:23,720
Edge processing is not a replacement for PLC control.

1573
01:00:23,720 --> 01:00:26,920
The PLC, safety system, and deterministic OT layer

1574
01:00:26,920 --> 01:00:29,320
still own the machine behavior they were built to own.

1575
01:00:29,320 --> 01:00:32,760
An edge system can observe in rich and support local applications,

1576
01:00:32,760 --> 01:00:35,000
but it shouldn't casually insert itself into parts

1577
01:00:35,000 --> 01:00:38,440
where predictable control behavior protects people, equipment, or product.

1578
01:00:38,440 --> 01:00:41,160
Keep that boundary clear, it matters.

1579
01:00:41,160 --> 01:00:44,600
At the other extreme, the edge isn't a miniature enterprise data center either.

1580
01:00:44,600 --> 01:00:47,560
You don't need to copy every central platform service into every plant

1581
01:00:47,560 --> 01:00:51,880
and then spend the next five years operating a distributed version of the same complexity.

1582
01:00:51,880 --> 01:00:54,920
The edge should run only the services that need local data,

1583
01:00:54,920 --> 01:00:57,080
local response, and local continuity.

1584
01:00:57,080 --> 01:00:58,920
Not just because a container can run there,

1585
01:00:58,920 --> 01:01:03,240
think of the edge as the first place where raw factory data becomes usable operational data.

1586
01:01:03,240 --> 01:01:07,880
Before that point, you have signals, packets, files, and protocol-specific records.

1587
01:01:07,880 --> 01:01:10,840
After that, you can have a machine state event,

1588
01:01:10,840 --> 01:01:13,720
a time bound production fact, a condition result,

1589
01:01:13,720 --> 01:01:16,840
or a controlled local record that other systems can understand.

1590
01:01:16,840 --> 01:01:18,360
That conversion is the real job.

1591
01:01:18,360 --> 01:01:20,040
The cloud still has a strong role.

1592
01:01:20,040 --> 01:01:23,080
Use cloud scale where you need shared history across sites,

1593
01:01:23,080 --> 01:01:25,000
broad access for enterprise teams,

1594
01:01:25,000 --> 01:01:27,320
governed reporting, long-running analysis,

1595
01:01:27,320 --> 01:01:31,000
or larger compute workloads that don't sit in the immediate plant path.

1596
01:01:31,000 --> 01:01:33,640
Those workloads benefit from central services

1597
01:01:33,640 --> 01:01:37,400
because their users and questions reach beyond one line or one factory.

1598
01:01:37,400 --> 01:01:39,960
The edge and cloud aren't competing destinations.

1599
01:01:39,960 --> 01:01:42,360
They perform different parts of the same system.

1600
01:01:42,360 --> 01:01:45,960
A good design lets the edge deal with the physical world in the form it arrives,

1601
01:01:45,960 --> 01:01:49,160
then sends well-formed operational data to shared platforms

1602
01:01:49,160 --> 01:01:51,720
when those platforms have a defined job to do.

1603
01:01:51,720 --> 01:01:55,240
That's how you connect the dots between IT and OT

1604
01:01:55,240 --> 01:01:58,680
without forcing every raw signal to become an enterprise record,

1605
01:01:58,680 --> 01:02:01,240
and filtering at the edge does more than drop rows.

1606
01:02:01,240 --> 01:02:05,000
Filter at the edge without throwing away evidence.

1607
01:02:05,000 --> 01:02:07,320
Filtering doesn't mean throwing data away blindly.

1608
01:02:07,320 --> 01:02:10,920
It means deciding, while the machine context is still close,

1609
01:02:10,920 --> 01:02:15,560
which records need to travel and which only need to remain available locally for a defined time.

1610
01:02:15,560 --> 01:02:18,120
Start with the simplest rule.

1611
01:02:18,120 --> 01:02:21,960
Threshold filtering, where a temperature, pressure, current, or vibration score

1612
01:02:21,960 --> 01:02:25,560
stays within its expected band, so the edge records it locally

1613
01:02:25,560 --> 01:02:28,360
and sends a compact health record at the agreed interval.

1614
01:02:28,360 --> 01:02:31,320
When it crosses a limit, the edge creates an event immediately

1615
01:02:31,320 --> 01:02:34,120
with the measured value and the context needed to understand it.

1616
01:02:34,120 --> 01:02:38,360
That works for clear limits, but many manufacturing signals need a different rule.

1617
01:02:38,360 --> 01:02:41,960
Change filtering sends data when the value changes by a meaningful amount.

1618
01:02:41,960 --> 01:02:44,440
A tank level, drifting by a fraction of a percent,

1619
01:02:44,440 --> 01:02:47,400
every few seconds may not need an upstream record each time,

1620
01:02:47,400 --> 01:02:51,080
but a rapid change or a change beyond a defined dead band does.

1621
01:02:51,080 --> 01:02:55,400
You keep the local history, but the shared system receives changes that might lead someone to act.

1622
01:02:55,400 --> 01:02:57,400
State change filtering is often even more useful.

1623
01:02:57,400 --> 01:03:00,600
A machine can sit in a running state for an hour,

1624
01:03:00,600 --> 01:03:03,880
and sending running over and over adds little operational meaning.

1625
01:03:03,880 --> 01:03:08,120
Instead, send the transition from running to blocked, blocked to faulted,

1626
01:03:08,120 --> 01:03:12,280
faulted to running, and attach the time in any reason code available at that moment.

1627
01:03:12,280 --> 01:03:16,040
The event tells you what changed, and duration comes from the next transition.

1628
01:03:16,040 --> 01:03:18,600
This is where filtering needs some engineering judgment.

1629
01:03:18,600 --> 01:03:22,600
A filter should remove repetition, not remove the signal that explains a problem.

1630
01:03:22,600 --> 01:03:25,640
If a machine state changes for half a second and then returns,

1631
01:03:25,640 --> 01:03:29,480
that may look like noise in a dashboard, but it could also be the start of a fault pattern

1632
01:03:29,480 --> 01:03:30,840
that maintenance needs to see.

1633
01:03:30,840 --> 01:03:34,920
So keep the local record even when you choose not to send every detail upward.

1634
01:03:34,920 --> 01:03:37,160
Event window filtering handles this well.

1635
01:03:37,160 --> 01:03:39,800
Instead of sending a continuous high-rate signal all day,

1636
01:03:39,800 --> 01:03:42,200
the edge maintains a rolling raw buffer.

1637
01:03:42,200 --> 01:03:47,160
When an anomaly, fault, quality, reject, or defined process condition occurs,

1638
01:03:47,160 --> 01:03:49,320
it preserves a time window around that event.

1639
01:03:49,320 --> 01:03:52,600
You might retain a period before the trigger and another period after it.

1640
01:03:52,600 --> 01:03:55,080
The exact window depends on the process,

1641
01:03:55,080 --> 01:03:56,760
but the principle stays the same.

1642
01:03:56,760 --> 01:03:59,240
Capture the lead-up, the event, and the recovery,

1643
01:03:59,240 --> 01:04:01,560
rather than only the point where a limit was crossed.

1644
01:04:01,560 --> 01:04:04,280
A single alarm value rarely explains a failure.

1645
01:04:04,280 --> 01:04:07,720
The useful evidence often sits just before it.

1646
01:04:07,720 --> 01:04:10,520
Did the vibration trend rise gradually?

1647
01:04:10,520 --> 01:04:12,040
Did motor current jump first?

1648
01:04:12,040 --> 01:04:13,640
Did the machine change recipe?

1649
01:04:13,640 --> 01:04:16,440
Did the sensor quality flag become uncertain before the fault?

1650
01:04:16,440 --> 01:04:19,480
A local event window keeps that sequence available

1651
01:04:19,480 --> 01:04:23,160
without turning every normal minute into a permanent cloud record.

1652
01:04:23,160 --> 01:04:26,040
Stable signals can also move through rolling aggregates.

1653
01:04:26,040 --> 01:04:30,040
The edge can calculate a minimum, maximum, average, count, duration,

1654
01:04:30,040 --> 01:04:31,880
or rate over a defined interval,

1655
01:04:31,880 --> 01:04:34,600
then publish that smaller record for shared reporting.

1656
01:04:34,600 --> 01:04:37,480
But don't send an aggregate without its data quality markers.

1657
01:04:37,480 --> 01:04:39,800
If the edge lost communication to a sensor,

1658
01:04:39,800 --> 01:04:43,000
detected a bad timestamp saw a missing sample range

1659
01:04:43,000 --> 01:04:45,080
or changed configuration during the interval,

1660
01:04:45,080 --> 01:04:46,600
the aggregate needs to say so.

1661
01:04:46,600 --> 01:04:50,600
Otherwise, a clean-looking average can quietly mix valid measurements

1662
01:04:50,600 --> 01:04:52,040
with a broken source.

1663
01:04:52,040 --> 01:04:53,720
Data quality is part of the record.

1664
01:04:53,720 --> 01:04:55,480
The same applies to derived events.

1665
01:04:55,480 --> 01:04:57,800
Every event or aggregate that leaves the site

1666
01:04:57,800 --> 01:04:59,400
should retain its timestamp,

1667
01:04:59,400 --> 01:05:03,080
asset ID, unit, and the configuration context that produced it.

1668
01:05:03,080 --> 01:05:05,080
If a condition score comes from a model,

1669
01:05:05,080 --> 01:05:06,440
include the model version.

1670
01:05:06,440 --> 01:05:08,200
If a threshold generated the event,

1671
01:05:08,200 --> 01:05:11,000
retain the rule version or configuration reference.

1672
01:05:11,000 --> 01:05:14,040
Six months later, someone will ask whether the event means the same thing

1673
01:05:14,040 --> 01:05:15,480
it meant when it was created.

1674
01:05:15,480 --> 01:05:18,520
Without context, you can't answer that question reliably.

1675
01:05:18,520 --> 01:05:19,960
Time also needs care.

1676
01:05:19,960 --> 01:05:22,680
Keep the event time from the source where possible,

1677
01:05:22,680 --> 01:05:25,320
distinguish it from processing time and upload time,

1678
01:05:25,320 --> 01:05:27,560
and make sure the site clock stays under control.

1679
01:05:27,560 --> 01:05:31,000
A record arriving late because the one link failed

1680
01:05:31,000 --> 01:05:33,160
is not the same as a machine event that happened late.

1681
01:05:33,160 --> 01:05:36,040
Those distinctions matter during root cause work.

1682
01:05:36,040 --> 01:05:39,080
Local raw buffers need a defined retention period.

1683
01:05:39,080 --> 01:05:41,320
Long enough for the team to investigate normal issues

1684
01:05:41,320 --> 01:05:43,080
and long enough to upload approved evidence

1685
01:05:43,080 --> 01:05:44,760
when a case needs wider review.

1686
01:05:44,760 --> 01:05:46,280
The buffer cannot grow forever,

1687
01:05:46,280 --> 01:05:49,960
and it cannot disappear before anyone has a realistic chance to inspect it.

1688
01:05:49,960 --> 01:05:52,920
Set the duration based on how the plant actually works.

1689
01:05:52,920 --> 01:05:55,720
If fault reviews happen each shift a short buffer may work,

1690
01:05:55,720 --> 01:05:58,440
but if quality investigations often begin days later,

1691
01:05:58,440 --> 01:06:00,600
the local window needs to support that cadence.

1692
01:06:00,600 --> 01:06:03,000
Write down the rule, monitor available disk,

1693
01:06:03,000 --> 01:06:06,680
and alert before the buffer starts overwriting data you intended to keep.

1694
01:06:06,680 --> 01:06:08,040
That gives you a better pattern,

1695
01:06:08,040 --> 01:06:10,760
retain detailed local evidence, trigger bounded captures

1696
01:06:10,760 --> 01:06:11,960
when something changes,

1697
01:06:11,960 --> 01:06:15,560
and send records that carry enough meaning for shared systems to use.

1698
01:06:15,560 --> 01:06:17,720
The next step turns those filtered streams

1699
01:06:17,720 --> 01:06:19,960
into operational facts through aggregation.

1700
01:06:19,960 --> 01:06:23,240
Aggregate for the decision, not for the database.

1701
01:06:23,240 --> 01:06:25,400
Once the edge decides something matters,

1702
01:06:25,400 --> 01:06:29,000
aggregation turns those raw tags into facts people can actually use.

1703
01:06:29,000 --> 01:06:31,080
We're converting machine signals into records

1704
01:06:31,080 --> 01:06:33,880
like machine state by minute, completed cycle count,

1705
01:06:33,880 --> 01:06:37,720
stop duration, stop reason, and energy used over a defined period.

1706
01:06:37,720 --> 01:06:40,440
You're not trying to build the smallest possible database.

1707
01:06:40,440 --> 01:06:43,080
You're creating a record that supports a real decision.

1708
01:06:43,080 --> 01:06:45,960
Think about a line supervisor checking the last hour.

1709
01:06:45,960 --> 01:06:49,800
They don't need a long list of every PLC value sample during that hour.

1710
01:06:49,800 --> 01:06:52,120
They need to see that station 12 ran for 43 minutes,

1711
01:06:52,120 --> 01:06:53,640
waited on material for 9,

1712
01:06:53,640 --> 01:06:57,640
stopped for a fault for 8 and produced 186 good parts with 2 rejects.

1713
01:06:57,640 --> 01:06:59,240
That's operational information.

1714
01:06:59,240 --> 01:07:02,120
The aggregation window should match the cadence of the decision.

1715
01:07:02,120 --> 01:07:04,360
If someone manages a line, minute by minute,

1716
01:07:04,360 --> 01:07:06,600
a per shift total shows up too late.

1717
01:07:06,600 --> 01:07:09,640
If a central operations team reviews performance each morning,

1718
01:07:09,640 --> 01:07:13,160
second by second records just add noise without improving the conversation,

1719
01:07:13,160 --> 01:07:15,400
so choose the time window from the job backward.

1720
01:07:15,400 --> 01:07:16,520
For a live production view,

1721
01:07:16,520 --> 01:07:19,480
you might need current state plus a short rolling period.

1722
01:07:19,480 --> 01:07:22,680
For OEE review, a minute-level event record often works well

1723
01:07:22,680 --> 01:07:24,360
because it preserves run time, stop time,

1724
01:07:24,360 --> 01:07:27,720
and reason codes without transferring a dense stream of raw values.

1725
01:07:27,720 --> 01:07:31,640
For energy reporting, a 15 minute or hourly total may suit the meter

1726
01:07:31,640 --> 01:07:32,840
and the decision much better.

1727
01:07:32,840 --> 01:07:34,280
There's no universal interval.

1728
01:07:34,280 --> 01:07:35,880
Here's a packaging line example.

1729
01:07:35,880 --> 01:07:40,120
The PLC publishes machine status, speed, cycle pulses, alarms,

1730
01:07:40,120 --> 01:07:42,600
and energy readings at a fast cadence.

1731
01:07:42,600 --> 01:07:46,120
The edge layer interprets those inputs against the local machine state

1732
01:07:46,120 --> 01:07:47,880
and produces a minute record.

1733
01:07:47,880 --> 01:07:50,600
Running time, plan, stop time, unplanned stop time,

1734
01:07:50,600 --> 01:07:53,240
count produced, reject count, energy used,

1735
01:07:53,240 --> 01:07:55,720
and the dominant stop reason where one applies.

1736
01:07:55,720 --> 01:07:58,200
That minute record feeds an OEE event model.

1737
01:07:58,200 --> 01:08:01,480
OEE needs availability, performance, and quality context.

1738
01:08:01,480 --> 01:08:03,880
It does not need a million copies of a running bit.

1739
01:08:03,880 --> 01:08:05,960
When the machine changes from running to blocked,

1740
01:08:05,960 --> 01:08:07,960
the edge records the transition.

1741
01:08:07,960 --> 01:08:10,040
When it resumes, the duration becomes clear.

1742
01:08:10,040 --> 01:08:11,480
When a reject counter changes,

1743
01:08:11,480 --> 01:08:14,680
the system links that outcome to the active order and machine state.

1744
01:08:14,680 --> 01:08:17,400
The cloud receives a production fact with context,

1745
01:08:17,400 --> 01:08:19,240
not a raw signal dump,

1746
01:08:19,240 --> 01:08:21,560
but aggregation has a failure mode.

1747
01:08:21,560 --> 01:08:24,840
People average away the very thing they later need to explain.

1748
01:08:24,840 --> 01:08:27,400
A short voltage dip, a brief motion fault,

1749
01:08:27,400 --> 01:08:29,560
or a half second mismatch between two sensors

1750
01:08:29,560 --> 01:08:31,560
can disappear inside a one-minute average.

1751
01:08:31,560 --> 01:08:34,200
The average looks normal, but the machine didn't behave normally.

1752
01:08:34,200 --> 01:08:36,840
For maintenance or quality work, that difference matters.

1753
01:08:36,840 --> 01:08:38,840
So use more than one aggregation method

1754
01:08:38,840 --> 01:08:40,200
when the process calls for it.

1755
01:08:40,200 --> 01:08:42,680
A temperature signal may need minimum, maximum,

1756
01:08:42,680 --> 01:08:45,080
an average rather than average alone.

1757
01:08:45,080 --> 01:08:47,320
A machine state needs duration by state,

1758
01:08:47,320 --> 01:08:50,360
not a numeric average of codes that mean nothing once blended.

1759
01:08:50,360 --> 01:08:53,000
A vibration score might need peak count, threshold crossings,

1760
01:08:53,000 --> 01:08:54,120
and event duration.

1761
01:08:54,120 --> 01:08:55,880
The record should preserve the characteristics

1762
01:08:55,880 --> 01:08:57,160
that indicate instability,

1763
01:08:57,160 --> 01:08:59,160
not just describe a calm-looking midpoint.

1764
01:08:59,160 --> 01:09:01,240
This is where domain knowledge enters the model.

1765
01:09:01,240 --> 01:09:04,520
Ask the process engineer which short events affect product quality.

1766
01:09:04,520 --> 01:09:07,240
Ask maintenance which signatures appear before a failure.

1767
01:09:07,240 --> 01:09:10,600
Ask the line team, which stops, count against plant production,

1768
01:09:10,600 --> 01:09:11,800
and which do not.

1769
01:09:11,800 --> 01:09:13,880
The aggregation logic should encode those answers

1770
01:09:13,880 --> 01:09:16,520
in a visible version rule rather than bury them inside

1771
01:09:16,520 --> 01:09:18,280
a no-pake dashboard calculation.

1772
01:09:18,280 --> 01:09:20,600
The record also needs its quality status.

1773
01:09:20,600 --> 01:09:22,600
If a minute included missing samples,

1774
01:09:22,600 --> 01:09:26,280
a lost device connection, a clock issue, or an invalid source value,

1775
01:09:26,280 --> 01:09:28,200
keep that status beside the aggregate.

1776
01:09:28,200 --> 01:09:30,520
Don't let a partial count look like a complete count.

1777
01:09:30,520 --> 01:09:33,400
Don't let a zero-energy reading look like efficient production

1778
01:09:33,400 --> 01:09:35,240
when the meter simply stopped reporting.

1779
01:09:35,240 --> 01:09:38,040
A number without its data condition invites the wrong decision.

1780
01:09:38,040 --> 01:09:40,200
For each aggregate, retain enough information

1781
01:09:40,200 --> 01:09:41,960
to answer simple questions later.

1782
01:09:41,960 --> 01:09:43,320
Which asset produced it?

1783
01:09:43,320 --> 01:09:44,600
Which time window does it cover?

1784
01:09:44,600 --> 01:09:46,360
Which source values contributed?

1785
01:09:46,360 --> 01:09:48,200
Did the system see a complete interval?

1786
01:09:48,200 --> 01:09:51,880
Which rule set converted the raw inputs into this operational fact?

1787
01:09:51,880 --> 01:09:54,360
Those fields matter when two teams compare results

1788
01:09:54,360 --> 01:09:56,200
and discover their totals disagree.

1789
01:09:56,200 --> 01:09:59,240
Aggregation should reduce volume and improve meaning at the same time.

1790
01:09:59,240 --> 01:10:02,840
If it only reduces volume, you may have created a smaller data set

1791
01:10:02,840 --> 01:10:04,040
that nobody can trust.

1792
01:10:04,040 --> 01:10:06,680
If it only adds meaning, but sends every raw point as well,

1793
01:10:06,680 --> 01:10:09,080
you haven't changed the cost or the architecture.

1794
01:10:09,080 --> 01:10:12,040
The aim is a deliberate data product for a clear decision.

1795
01:10:12,040 --> 01:10:15,400
Compression can reduce the size of whatever you decide to transfer.

1796
01:10:15,400 --> 01:10:18,200
It can't fix a bad decision about what should travel in the first place.

1797
01:10:18,200 --> 01:10:21,720
Compression, batching, and store and forward.

1798
01:10:21,720 --> 01:10:24,280
Compression comes after placement, not before it.

1799
01:10:24,280 --> 01:10:26,680
If a data stream has no reason to leave the plant,

1800
01:10:26,680 --> 01:10:29,560
compressing it only creates a smaller unnecessary transfer.

1801
01:10:29,560 --> 01:10:31,560
But once you've decided the cloud needs a record,

1802
01:10:31,560 --> 01:10:33,480
compression can reduce the bytes on the root

1803
01:10:33,480 --> 01:10:35,480
without changing the meaning of that record.

1804
01:10:35,480 --> 01:10:37,320
Text-heavy payloads usually respond well.

1805
01:10:37,320 --> 01:10:40,280
JSON event records, CSV extracts, structured logs,

1806
01:10:40,280 --> 01:10:43,480
and repeated tag names often contain a lot of redundant text.

1807
01:10:43,480 --> 01:10:45,880
A suitable compression method can reduce that overhead

1808
01:10:45,880 --> 01:10:48,200
before the edge connector sends the batch upstream.

1809
01:10:48,200 --> 01:10:50,200
Binary data needs a different expectation.

1810
01:10:50,200 --> 01:10:52,760
A JPEG image, video stream, compressed archive,

1811
01:10:52,760 --> 01:10:56,520
or encoded waveform file may already sit close to its practical size.

1812
01:10:56,520 --> 01:10:59,560
Trying to compress it again can consume CPU and add delay

1813
01:10:59,560 --> 01:11:02,280
without reducing the transfer enough to justify the work.

1814
01:11:02,280 --> 01:11:04,200
The edge should know the payload type

1815
01:11:04,200 --> 01:11:07,160
before it applies a generic, compress everything policy.

1816
01:11:07,160 --> 01:11:09,400
That sounds obvious, but it often isn't.

1817
01:11:09,400 --> 01:11:12,920
I've seen systems wrap a compressed file inside a text envelope

1818
01:11:12,920 --> 01:11:15,480
at base64 encoding, then compress the whole thing

1819
01:11:15,480 --> 01:11:18,040
and wonder why the network build didn't improve.

1820
01:11:18,040 --> 01:11:20,600
The data path became more complicated while the useful payload

1821
01:11:20,600 --> 01:11:21,560
barely changed.

1822
01:11:21,560 --> 01:11:23,720
Keep binary data binary where you can

1823
01:11:23,720 --> 01:11:25,240
and measure the actual result.

1824
01:11:25,240 --> 01:11:28,360
Batching also helps when the data doesn't need an immediate response.

1825
01:11:28,360 --> 01:11:30,600
A stream of low priority operational records

1826
01:11:30,600 --> 01:11:33,240
can collect locally for a short controlled interval,

1827
01:11:33,240 --> 01:11:36,600
then move as a batch rather than as thousands of tiny requests.

1828
01:11:36,600 --> 01:11:38,840
That reduces connection setup, protocol headers,

1829
01:11:38,840 --> 01:11:41,000
acknowledgements, and repeated encryption overhead.

1830
01:11:41,000 --> 01:11:43,400
It also gives you a smoother use of the site connection.

1831
01:11:43,400 --> 01:11:45,240
The batch window must fit the use case.

1832
01:11:45,240 --> 01:11:48,280
If a record supports a shift report sending it every few minutes

1833
01:11:48,280 --> 01:11:50,440
or at a scheduled time, it may work well.

1834
01:11:50,440 --> 01:11:51,960
If it supports a local intervention

1835
01:11:51,960 --> 01:11:53,640
that needs central escalation quickly,

1836
01:11:53,640 --> 01:11:55,400
waiting too long defeats the purpose.

1837
01:11:55,400 --> 01:11:56,600
Batching is not a blanket setting,

1838
01:11:56,600 --> 01:11:59,560
it's a delivery cadence tied to the consumer's decision window.

1839
01:11:59,560 --> 01:12:01,080
A plant network also benefits

1840
01:12:01,080 --> 01:12:03,400
when transfers avoid unnecessary peaks.

1841
01:12:03,400 --> 01:12:04,680
Picture several edge systems,

1842
01:12:04,680 --> 01:12:06,920
all finishing a local task at the same time,

1843
01:12:06,920 --> 01:12:08,120
each opening a connection

1844
01:12:08,120 --> 01:12:10,360
and pushing its backlog across the one.

1845
01:12:10,360 --> 01:12:12,920
The data volume may be acceptable across a full day,

1846
01:12:12,920 --> 01:12:15,080
but the burst can compete with other site traffic

1847
01:12:15,080 --> 01:12:16,680
and make troubleshooting harder.

1848
01:12:16,680 --> 01:12:19,400
Control-batch scheduling gives the network some breathing room.

1849
01:12:19,400 --> 01:12:21,800
Now consider what happens when the connection fails.

1850
01:12:21,800 --> 01:12:25,240
A factory cannot assume that every cloud route stays available.

1851
01:12:25,240 --> 01:12:28,600
One links fail, certificates expire, DNS does odd things,

1852
01:12:28,600 --> 01:12:31,720
and sometimes the remote service simply refuses to cooperate.

1853
01:12:31,720 --> 01:12:34,120
The edge needs store and forward behavior.

1854
01:12:34,120 --> 01:12:37,080
It writes approved outbound records to local storage,

1855
01:12:37,080 --> 01:12:38,760
then sends them when the route returns.

1856
01:12:38,760 --> 01:12:40,280
That local store needs limits.

1857
01:12:40,280 --> 01:12:43,480
Always define how much disk space the queue can use,

1858
01:12:43,480 --> 01:12:45,240
how long records can remain there,

1859
01:12:45,240 --> 01:12:47,000
which records take priority,

1860
01:12:47,000 --> 01:12:50,280
and what the system does as capacity approaches its limit.

1861
01:12:50,280 --> 01:12:52,200
Without those rules, store and forward

1862
01:12:52,200 --> 01:12:54,360
becomes store forever until the disk fills,

1863
01:12:54,360 --> 01:12:56,120
which is not a recovery strategy.

1864
01:12:56,120 --> 01:12:58,840
The edge should expose its backlog as an operating signal.

1865
01:12:58,840 --> 01:12:59,800
How many records wait?

1866
01:12:59,800 --> 01:13:01,000
How old is the oldest record?

1867
01:13:01,000 --> 01:13:02,840
Is the queue growing or clearing?

1868
01:13:02,840 --> 01:13:04,040
Has the system dropped anything

1869
01:13:04,040 --> 01:13:06,120
because a defined retention limit expired?

1870
01:13:06,120 --> 01:13:08,440
If you're monitoring, cannot answer those questions.

1871
01:13:08,440 --> 01:13:11,400
The buffer is invisible until it becomes an incident.

1872
01:13:11,400 --> 01:13:14,600
Reliable delivery creates another issue, retries.

1873
01:13:14,600 --> 01:13:16,760
When a connection drops after the edge sends a message,

1874
01:13:16,760 --> 01:13:18,440
but before it receives confirmation,

1875
01:13:18,440 --> 01:13:21,240
the edge cannot always know whether the cloud stored that message.

1876
01:13:21,240 --> 01:13:23,160
Retrying is the correct choice.

1877
01:13:23,160 --> 01:13:25,320
Yet the receiving system must handle the retry

1878
01:13:25,320 --> 01:13:27,400
without creating a second production event,

1879
01:13:27,400 --> 01:13:29,880
another alarm, or a duplicate energy total.

1880
01:13:29,880 --> 01:13:31,800
That's where idempotent delivery matters,

1881
01:13:31,800 --> 01:13:34,200
give each event a batch a stable identity.

1882
01:13:34,200 --> 01:13:36,040
The cloud consumer records that identity

1883
01:13:36,040 --> 01:13:38,600
and treats a repeated message as the same business record,

1884
01:13:38,600 --> 01:13:39,720
not as new data.

1885
01:13:39,720 --> 01:13:41,960
You can use sequence numbers, event IDs,

1886
01:13:41,960 --> 01:13:44,280
source timestamps combined with asset context,

1887
01:13:44,280 --> 01:13:46,840
or another stable identifier that fits your design.

1888
01:13:46,840 --> 01:13:49,560
The point is that delivery attempts and business events

1889
01:13:49,560 --> 01:13:50,680
are not the same thing.

1890
01:13:50,680 --> 01:13:52,440
De-duplication needs the same discipline.

1891
01:13:52,440 --> 01:13:54,760
Don't did duplicate only after data reaches a dashboard

1892
01:13:54,760 --> 01:13:55,640
or a lake house.

1893
01:13:55,640 --> 01:13:58,120
Detect duplicate messages as close as practical

1894
01:13:58,120 --> 01:13:59,400
to the ingestion point,

1895
01:13:59,400 --> 01:14:02,280
retain enough delivery history to identify repeats

1896
01:14:02,280 --> 01:14:04,520
and make sure the rules survive the connector restart

1897
01:14:04,520 --> 01:14:06,200
or a local queue replay.

1898
01:14:06,200 --> 01:14:09,480
Otherwise, a short outage can turn into a quiet data quality problem

1899
01:14:09,480 --> 01:14:11,480
that lives for years, compression, batching,

1900
01:14:11,480 --> 01:14:13,560
and store and forward reduced transfer waste.

1901
01:14:13,560 --> 01:14:15,880
They don't decide whether the data deserves transfer

1902
01:14:15,880 --> 01:14:16,920
in the first place.

1903
01:14:16,920 --> 01:14:19,480
You still need a named consumer, a clear purpose,

1904
01:14:19,480 --> 01:14:21,880
and a record form that supports the decision.

1905
01:14:21,880 --> 01:14:23,960
For some workloads though, the strongest filter

1906
01:14:23,960 --> 01:14:25,960
does not come from a rule or a batch.

1907
01:14:25,960 --> 01:14:29,000
It comes from running the first inference close to the machine.

1908
01:14:29,000 --> 01:14:31,080
Put real-time inference near the machine.

1909
01:14:31,080 --> 01:14:33,640
Here's the thing about high-rate data like vibrational vision.

1910
01:14:33,640 --> 01:14:35,400
A rule engine can handle some filtering,

1911
01:14:35,400 --> 01:14:38,040
but the real value is putting a model right at the edge,

1912
01:14:38,040 --> 01:14:40,440
scoring the input before it ever leaves the machine.

1913
01:14:40,440 --> 01:14:42,840
Otherwise, you're shipping noise across the network.

1914
01:14:42,840 --> 01:14:44,120
Take vibration monitoring.

1915
01:14:44,120 --> 01:14:45,720
The edge system reads the signal,

1916
01:14:45,720 --> 01:14:47,640
preps the sample the way the model expects,

1917
01:14:47,640 --> 01:14:50,120
and calculates a condition score right there.

1918
01:14:50,120 --> 01:14:51,880
A healthy pattern gets a normal score,

1919
01:14:51,880 --> 01:14:53,160
but once the pattern starts drifting,

1920
01:14:53,160 --> 01:14:54,360
that triggers an event,

1921
01:14:54,360 --> 01:14:56,200
and the raw waveform stays local

1922
01:14:56,200 --> 01:14:58,520
unless someone specifically asks for it.

1923
01:14:58,520 --> 01:14:59,960
Vision works the same way,

1924
01:14:59,960 --> 01:15:01,240
even though the payload is different.

1925
01:15:01,240 --> 01:15:03,000
A camera might inspect every part,

1926
01:15:03,000 --> 01:15:05,960
but the cloud doesn't need every frame from every good product.

1927
01:15:05,960 --> 01:15:07,960
The local system classifies the result,

1928
01:15:07,960 --> 01:15:10,280
records the defect type or confidence score,

1929
01:15:10,280 --> 01:15:11,800
and keeps a limited set of images

1930
01:15:11,800 --> 01:15:14,040
when it finds something that needs a closer look.

1931
01:15:14,040 --> 01:15:15,160
That's not AI magic.

1932
01:15:15,160 --> 01:15:17,880
It's a specific model applied to a specific stream,

1933
01:15:17,880 --> 01:15:19,480
right where the data is generated.

1934
01:15:19,480 --> 01:15:21,080
The record you send upstream needs

1935
01:15:21,080 --> 01:15:23,240
enough context for someone else to trust it.

1936
01:15:23,240 --> 01:15:25,080
That means the score, the event time,

1937
01:15:25,080 --> 01:15:26,600
the asset or inspection station,

1938
01:15:26,600 --> 01:15:28,360
the model version, and the outcome.

1939
01:15:28,360 --> 01:15:30,280
And when that result triggers an exception,

1940
01:15:30,280 --> 01:15:32,120
send along a limited evidence package,

1941
01:15:32,120 --> 01:15:34,440
the relevant waveform window, selected images,

1942
01:15:34,440 --> 01:15:36,920
or derive features that explain the classification.

1943
01:15:36,920 --> 01:15:39,080
Now, that limited part is important.

1944
01:15:39,080 --> 01:15:41,800
If every score automatically drags a big raw payload

1945
01:15:41,800 --> 01:15:42,600
into cloud storage,

1946
01:15:42,600 --> 01:15:44,680
you've only moved the filter a few inches downstream.

1947
01:15:44,680 --> 01:15:45,880
You need a rule that defines

1948
01:15:45,880 --> 01:15:47,480
what evidence travels with each event,

1949
01:15:47,480 --> 01:15:50,200
how much and how long the full local record stays available

1950
01:15:50,200 --> 01:15:52,600
in case an engineer needs to dig deeper.

1951
01:15:52,600 --> 01:15:54,360
Model version needs to be in every result,

1952
01:15:54,360 --> 01:15:57,080
because a score from one model isn't automatically comparable

1953
01:15:57,080 --> 01:15:58,440
with a score from another,

1954
01:15:58,440 --> 01:16:01,320
even if they are looking at the same asset and same input.

1955
01:16:01,320 --> 01:16:03,480
If you change pre-processing a threshold,

1956
01:16:03,480 --> 01:16:05,640
a camera setting, or the model itself,

1957
01:16:05,640 --> 01:16:07,880
you need to know which logic produced that outcome.

1958
01:16:07,880 --> 01:16:10,280
Otherwise, your trend chart can look perfectly stable

1959
01:16:10,280 --> 01:16:12,920
while the meaning of every number changed underneath it.

1960
01:16:12,920 --> 01:16:14,600
Now, the cloud still has its place here.

1961
01:16:14,600 --> 01:16:16,360
It just doesn't do the work that has to happen

1962
01:16:16,360 --> 01:16:18,360
before the machine context disappears.

1963
01:16:18,360 --> 01:16:21,160
Use central compute to train models on approved data sets,

1964
01:16:21,160 --> 01:16:22,520
test them against known cases,

1965
01:16:22,520 --> 01:16:24,920
control which version gets approved for production,

1966
01:16:24,920 --> 01:16:26,600
push that version to the right sides,

1967
01:16:26,600 --> 01:16:28,920
and compare results across lines or plans.

1968
01:16:29,880 --> 01:16:32,440
That separation makes the model life cycle transparent.

1969
01:16:32,440 --> 01:16:35,400
A central team can test a new model before it ever hits production.

1970
01:16:35,400 --> 01:16:37,160
They can track which sides run which version

1971
01:16:37,160 --> 01:16:39,720
and compare event patterns without needing every side

1972
01:16:39,720 --> 01:16:41,960
to constantly upload all raw sensor data.

1973
01:16:41,960 --> 01:16:43,880
And when a model needs new training data,

1974
01:16:43,880 --> 01:16:46,200
you request a controlled set of labeled cases

1975
01:16:46,200 --> 01:16:48,520
instead of treating every normal production cycle

1976
01:16:48,520 --> 01:16:49,640
as training material.

1977
01:16:49,640 --> 01:16:50,840
That gives you a feedback loop

1978
01:16:50,840 --> 01:16:53,560
without turning the factory into a permanent data upload service.

1979
01:16:53,560 --> 01:16:55,560
But here's a boundary that has to stay firm.

1980
01:16:55,560 --> 01:16:57,880
Local inference can support condition monitoring,

1981
01:16:57,880 --> 01:16:59,800
inspection and operational guidance,

1982
01:16:59,800 --> 01:17:02,280
but safety functions and deterministic machine control

1983
01:17:02,280 --> 01:17:04,920
should never depend on a remote cloud response.

1984
01:17:04,920 --> 01:17:07,400
A one connection is not a safety-rated control path

1985
01:17:07,400 --> 01:17:09,800
and no model score changes that.

1986
01:17:09,800 --> 01:17:12,920
The PLC safety controller and established OT safeguards

1987
01:17:12,920 --> 01:17:14,920
keep authority over anything that protects people,

1988
01:17:14,920 --> 01:17:16,200
equipment and product.

1989
01:17:16,200 --> 01:17:18,760
An edge model can raise an alert, block a suspect item

1990
01:17:18,760 --> 01:17:20,280
through an approved local workflow

1991
01:17:20,280 --> 01:17:22,520
or ask for a human review of that workflow exists.

1992
01:17:22,520 --> 01:17:24,040
It should never wait for a cloud service

1993
01:17:24,040 --> 01:17:26,200
to decide a critical machine action.

1994
01:17:26,200 --> 01:17:28,520
The same rule applies when the one link fails.

1995
01:17:28,520 --> 01:17:30,520
Your edge system needs a clear fallback mode.

1996
01:17:30,520 --> 01:17:33,400
If the cloud gets slow, goes down or becomes unreachable,

1997
01:17:33,400 --> 01:17:35,960
the local model keeps running with the last approved version,

1998
01:17:35,960 --> 01:17:38,680
records results locally, and queues only the records

1999
01:17:38,680 --> 01:17:40,680
that are approved for later upload.

2000
01:17:40,680 --> 01:17:43,880
If local capacity or model health drops below a threshold,

2001
01:17:43,880 --> 01:17:46,280
you've defined the system should signal that clearly

2002
01:17:46,280 --> 01:17:48,520
and follow the site's operating procedure.

2003
01:17:48,520 --> 01:17:50,200
Silence is not a fallback mode.

2004
01:17:50,200 --> 01:17:51,640
You also need to decide what happens

2005
01:17:51,640 --> 01:17:53,560
when the edge model itself can't run.

2006
01:17:53,560 --> 01:17:54,600
The local hardware fails,

2007
01:17:54,600 --> 01:17:55,800
an input source drops out,

2008
01:17:55,800 --> 01:17:58,280
or the model package can't load after an update.

2009
01:17:58,280 --> 01:18:00,280
The answer might be a simpler local rule,

2010
01:18:00,280 --> 01:18:02,840
a manual inspection step, or a controlled stop.

2011
01:18:02,840 --> 01:18:04,200
Depends on the process.

2012
01:18:04,200 --> 01:18:06,200
What it can't be is an undocumented assumption

2013
01:18:06,200 --> 01:18:07,800
that the cloud will save the day.

2014
01:18:07,800 --> 01:18:09,560
The three-layer factory data pattern,

2015
01:18:09,560 --> 01:18:10,760
let's zoom out for a second.

2016
01:18:10,760 --> 01:18:13,960
A hybrid design only works when each layer has a clear job.

2017
01:18:13,960 --> 01:18:15,480
The simplest way to make that job clear

2018
01:18:15,480 --> 01:18:17,080
is to break it into three layers.

2019
01:18:17,080 --> 01:18:19,480
The edge, the site, and the cloud.

2020
01:18:19,480 --> 01:18:22,040
The edge layer sits right next to the physical process.

2021
01:18:22,040 --> 01:18:25,160
It captures data from controllers, sensors, cameras,

2022
01:18:25,160 --> 01:18:26,600
and local applications,

2023
01:18:26,600 --> 01:18:28,600
and turns those inputs into something

2024
01:18:28,600 --> 01:18:30,440
the rest of the system can use.

2025
01:18:30,440 --> 01:18:33,320
This layer normalizes timestamps and asset IDs,

2026
01:18:33,320 --> 01:18:35,480
buffers records when the connection drops,

2027
01:18:35,480 --> 01:18:37,320
filters out repetitive signals,

2028
01:18:37,320 --> 01:18:39,560
and runs local inference where it's needed.

2029
01:18:39,560 --> 01:18:42,280
Its focus is immediate operational context.

2030
01:18:42,280 --> 01:18:44,520
It knows which machine produced the signal,

2031
01:18:44,520 --> 01:18:45,960
what it was doing at the time,

2032
01:18:45,960 --> 01:18:47,880
and whether a local system needs to react

2033
01:18:47,880 --> 01:18:51,000
before any external service has time to respond.

2034
01:18:51,000 --> 01:18:52,600
Above that, you've got the site layer.

2035
01:18:52,600 --> 01:18:55,160
This is the layer that most IoT diagrams skip

2036
01:18:55,160 --> 01:18:58,920
because drawing a line from gateway straight to cloud looks so clean,

2037
01:18:58,920 --> 01:19:01,720
but it rarely matches how a plant actually works.

2038
01:19:01,720 --> 01:19:04,920
Most factories already have shared systems at the site level.

2039
01:19:04,920 --> 01:19:07,880
A historian, MES, local reporting tools,

2040
01:19:07,880 --> 01:19:10,120
engineering workstations, quality systems,

2041
01:19:10,120 --> 01:19:13,800
and applications that connect production records to order context.

2042
01:19:13,800 --> 01:19:16,840
The site layer gives data a shared factory context

2043
01:19:16,840 --> 01:19:19,000
before it ever becomes enterprise data.

2044
01:19:19,000 --> 01:19:21,400
A historian holds site-wide process history.

2045
01:19:21,400 --> 01:19:25,240
MES provides the order, operation, material, and status

2046
01:19:25,240 --> 01:19:27,960
that turn a machine event into something meaningful.

2047
01:19:27,960 --> 01:19:30,200
A local application can combine a quality result

2048
01:19:30,200 --> 01:19:32,200
with a specific batch and machine state

2049
01:19:32,200 --> 01:19:34,600
then expose that result to teams inside the plant

2050
01:19:34,600 --> 01:19:37,160
without needing a round trip to a remote platform.

2051
01:19:37,160 --> 01:19:39,720
That middle layer also helps when multiple production cells

2052
01:19:39,720 --> 01:19:40,840
need the same data.

2053
01:19:40,840 --> 01:19:43,240
Instead of every edge device leaving its own direct path

2054
01:19:43,240 --> 01:19:46,280
to the cloud and every local consumer pulling records back down,

2055
01:19:46,280 --> 01:19:49,080
the site layer provides a controlled shared service

2056
01:19:49,080 --> 01:19:51,800
close to the people and equipment that actually use it.

2057
01:19:51,800 --> 01:19:53,720
This cuts down duplicate integration work,

2058
01:19:53,720 --> 01:19:55,960
and more importantly, it lets the plant stay coherent

2059
01:19:55,960 --> 01:19:57,640
when that external connection gets spotty.

2060
01:19:57,640 --> 01:19:58,840
Then you have the cloud layer.

2061
01:19:58,840 --> 01:20:00,520
The cloud is the right place for work

2062
01:20:00,520 --> 01:20:02,760
that reaches across sites or needs long term,

2063
01:20:02,760 --> 01:20:03,560
governed access.

2064
01:20:03,560 --> 01:20:06,120
That means fleet analysis across many factories,

2065
01:20:06,120 --> 01:20:08,280
enterprise reporting, model training,

2066
01:20:08,280 --> 01:20:10,680
when it needs big data sets in central compute

2067
01:20:10,680 --> 01:20:12,200
and retained business records

2068
01:20:12,200 --> 01:20:15,080
that need controlled access across teams or regions.

2069
01:20:15,080 --> 01:20:16,120
Think about it this way.

2070
01:20:16,120 --> 01:20:18,760
A maintenance engineer investigating one machine

2071
01:20:18,760 --> 01:20:21,560
needs immediate site context and detailed evidence.

2072
01:20:21,560 --> 01:20:24,120
A central reliability team looking for failure patterns

2073
01:20:24,120 --> 01:20:26,200
across a fleet needs comparable records

2074
01:20:26,200 --> 01:20:27,560
from many assets over time.

2075
01:20:27,560 --> 01:20:28,840
Those are different questions

2076
01:20:28,840 --> 01:20:30,280
and they deserve different layers.

2077
01:20:30,280 --> 01:20:33,640
The cloud should receive data shaped for that shared purpose.

2078
01:20:33,640 --> 01:20:35,400
It can also hold governed data products

2079
01:20:35,400 --> 01:20:37,000
that enterprise teams trust,

2080
01:20:37,000 --> 01:20:38,520
cross-plant OEE review,

2081
01:20:38,520 --> 01:20:40,520
quality trends, energy comparison,

2082
01:20:40,520 --> 01:20:43,240
planning analysis, and approved model training sets.

2083
01:20:43,240 --> 01:20:46,200
But it shouldn't have to decode every protocol detail

2084
01:20:46,200 --> 01:20:48,360
or reconstruct every local machine state

2085
01:20:48,360 --> 01:20:51,400
from raw messages that showed up without any context.

2086
01:20:51,400 --> 01:20:53,160
That is expensive detective work

2087
01:20:53,160 --> 01:20:55,000
and it usually produces arguments.

2088
01:20:55,000 --> 01:20:56,760
The architecture gets a lot easier to run

2089
01:20:56,760 --> 01:20:59,480
when each handoff between layers has a real contract.

2090
01:20:59,480 --> 01:21:01,800
Not a vague promise that data will show up somehow.

2091
01:21:01,800 --> 01:21:02,680
A real contract.

2092
01:21:02,680 --> 01:21:04,120
The contract defines the schema.

2093
01:21:04,120 --> 01:21:05,960
What fields arrive, what each one means,

2094
01:21:05,960 --> 01:21:07,240
what units apply,

2095
01:21:07,240 --> 01:21:08,280
how timestamps work,

2096
01:21:08,280 --> 01:21:11,240
and how the record identifies the asset and process context.

2097
01:21:11,240 --> 01:21:12,920
It also defines the cadence.

2098
01:21:12,920 --> 01:21:15,240
Whether the edge sends an event as it happens,

2099
01:21:15,240 --> 01:21:17,880
a minute record, a shift record, or a scheduled batch.

2100
01:21:17,880 --> 01:21:20,200
The receiving layer needs to know what the layer to expect

2101
01:21:20,200 --> 01:21:21,800
and what counts as late or missing.

2102
01:21:21,800 --> 01:21:23,240
Retention goes in the contract too.

2103
01:21:23,240 --> 01:21:26,120
The edge holds detailed evidence for a defined local window.

2104
01:21:26,120 --> 01:21:29,160
The site layer keeps operational history for a different period.

2105
01:21:29,160 --> 01:21:30,760
The cloud holds approved aggregates

2106
01:21:30,760 --> 01:21:32,680
and business records for much longer.

2107
01:21:32,680 --> 01:21:35,400
If each layer silently keeps everything forever,

2108
01:21:35,400 --> 01:21:37,000
that's not a retention design.

2109
01:21:37,000 --> 01:21:38,280
It's just a storage habit.

2110
01:21:38,280 --> 01:21:39,960
And every contract meets an owner.

2111
01:21:39,960 --> 01:21:41,400
Someone owns the source meaning,

2112
01:21:41,400 --> 01:21:43,000
someone owns the site service,

2113
01:21:43,000 --> 01:21:44,760
someone owns the cloud data product.

2114
01:21:44,760 --> 01:21:45,880
Without named ownership,

2115
01:21:45,880 --> 01:21:47,880
schema changes drift through the pipeline,

2116
01:21:47,880 --> 01:21:49,640
local teams lose trust in reports,

2117
01:21:49,640 --> 01:21:51,640
and the cloud becomes a big pile of records

2118
01:21:51,640 --> 01:21:53,880
that nobody feels responsible for explaining.

2119
01:21:53,880 --> 01:21:57,320
This is why edge-to-cloud is often too simple for a real factory.

2120
01:21:57,320 --> 01:21:59,480
It skips the layer where raw equipment data

2121
01:21:59,480 --> 01:22:01,960
meets the shared operational context of the plant.

2122
01:22:01,960 --> 01:22:03,880
That middle layer contains the historian,

2123
01:22:03,880 --> 01:22:05,000
the MES relationship,

2124
01:22:05,000 --> 01:22:06,280
and the local services

2125
01:22:06,280 --> 01:22:09,000
that tell you whether an event relates to an active order,

2126
01:22:09,000 --> 01:22:10,040
a plan stop,

2127
01:22:10,040 --> 01:22:11,160
a quality hold,

2128
01:22:11,160 --> 01:22:12,280
or a machine fault.

2129
01:22:12,280 --> 01:22:15,160
Skipping it doesn't remove complexity.

2130
01:22:15,160 --> 01:22:17,560
It just moves the complexity into cloud pipelines

2131
01:22:17,560 --> 01:22:19,480
where it costs more and arrives later.

2132
01:22:19,480 --> 01:22:21,240
Once you see these three layers clearly,

2133
01:22:21,240 --> 01:22:24,040
placing common data types becomes a lot less ideological.

2134
01:22:24,040 --> 01:22:26,920
You stop asking whether everything belongs at the edge or in the cloud,

2135
01:22:26,920 --> 01:22:29,240
and you start asking which layer can turn that data

2136
01:22:29,240 --> 01:22:31,000
into the right record for the next user.

2137
01:22:31,000 --> 01:22:34,360
Keep these data types at the edge by default.

2138
01:22:34,360 --> 01:22:36,360
Some factory data should never leave the edge,

2139
01:22:36,360 --> 01:22:38,600
unless someone makes a specific case for moving it.

2140
01:22:38,600 --> 01:22:40,600
But I'm not saying cloud services are bad.

2141
01:22:40,600 --> 01:22:44,440
It's that the original form of that data either has a short local use,

2142
01:22:44,440 --> 01:22:46,600
a large volume or both, usually both.

2143
01:22:46,600 --> 01:22:49,960
Start with high frequency waveforms,

2144
01:22:49,960 --> 01:22:52,520
vibration captures, acoustic signals,

2145
01:22:52,520 --> 01:22:53,960
high speed current traces,

2146
01:22:53,960 --> 01:22:56,040
that kind of detail pours out quickly.

2147
01:22:56,040 --> 01:22:59,320
A reliability engineer needs it when investigating an unusual condition,

2148
01:22:59,320 --> 01:23:00,680
but during normal operation,

2149
01:23:00,680 --> 01:23:02,920
shipping every healthy waveform to a remote platform

2150
01:23:02,920 --> 01:23:05,160
creates a massive transfer and retention burden

2151
01:23:05,160 --> 01:23:07,400
with almost no daily decision behind it.

2152
01:23:07,400 --> 01:23:09,560
Images and video fall into the same category.

2153
01:23:09,560 --> 01:23:11,560
A vision station might inspect every part,

2154
01:23:11,560 --> 01:23:13,880
a camera might record a process continuously.

2155
01:23:13,880 --> 01:23:16,040
Those raw files can help explain a defect,

2156
01:23:16,040 --> 01:23:18,360
train an inspection model or support and audit,

2157
01:23:18,360 --> 01:23:20,600
but they don't automatically need a permanent cloud route

2158
01:23:20,600 --> 01:23:22,520
just because the camera keeps producing them.

2159
01:23:22,520 --> 01:23:23,720
Here's what I recommend.

2160
01:23:23,720 --> 01:23:25,400
Keep the raw material near the process

2161
01:23:25,400 --> 01:23:27,400
with a defined local retention window.

2162
01:23:27,400 --> 01:23:30,040
Move selected evidence only when a reject,

2163
01:23:30,040 --> 01:23:33,160
anomaly or approved engineering request gives it a purpose.

2164
01:23:33,160 --> 01:23:34,920
That's it, debug logs and packet captures

2165
01:23:34,920 --> 01:23:36,200
deserve the same treatment.

2166
01:23:36,200 --> 01:23:39,080
They become useful almost exclusively after something breaks,

2167
01:23:39,080 --> 01:23:41,720
and they can get huge when a system is already under stress.

2168
01:23:41,720 --> 01:23:44,200
Sending every detailed log or network capture offsite

2169
01:23:44,200 --> 01:23:47,160
by default means you pay to store a lot of normal behavior,

2170
01:23:47,160 --> 01:23:48,840
then still have to dig through the noise

2171
01:23:48,840 --> 01:23:50,680
to find the few minutes that mattered.

2172
01:23:50,680 --> 01:23:53,480
A controlled local buffer works much better.

2173
01:23:53,480 --> 01:23:56,120
Control-related data also belongs close to the machine.

2174
01:23:56,120 --> 01:23:59,000
I'm talking about tags that describe immediate machine state,

2175
01:23:59,000 --> 01:24:01,640
interlock context, local alarm behavior,

2176
01:24:01,640 --> 01:24:04,280
and the signals local applications need to understand

2177
01:24:04,280 --> 01:24:06,120
what the equipment is doing right now.

2178
01:24:06,120 --> 01:24:07,960
That doesn't mean you hide operational state

2179
01:24:07,960 --> 01:24:09,000
from enterprise systems.

2180
01:24:09,000 --> 01:24:11,400
It means the detailed, low latency view

2181
01:24:11,400 --> 01:24:13,880
stays where the equipment and people needed first.

2182
01:24:13,880 --> 01:24:16,520
The enterprise receives an approved event or state record,

2183
01:24:16,520 --> 01:24:18,200
while the edge keeps the signal sequence

2184
01:24:18,200 --> 01:24:19,960
that explains how that state developed.

2185
01:24:19,960 --> 01:24:21,960
The difference matters during an incident.

2186
01:24:21,960 --> 01:24:23,960
A cloud dashboard can tell you that a cell

2187
01:24:23,960 --> 01:24:26,280
entered a faulted state at a given time.

2188
01:24:26,280 --> 01:24:28,600
The local system shows the interlock sequence,

2189
01:24:28,600 --> 01:24:30,120
sensor quality, command state,

2190
01:24:30,120 --> 01:24:32,120
and related inputs around that moment.

2191
01:24:32,120 --> 01:24:33,720
One supports fleet visibility,

2192
01:24:33,720 --> 01:24:35,160
the other supports diagnosis.

2193
01:24:35,160 --> 01:24:37,640
Short-lived local buffers give you that diagnostic depth

2194
01:24:37,640 --> 01:24:39,640
without turning every fault investigation

2195
01:24:39,640 --> 01:24:41,080
into a data retrieval project.

2196
01:24:41,080 --> 01:24:43,640
Keep the buffer long enough for how your plant actually works,

2197
01:24:43,640 --> 01:24:45,240
whether reviews happen during the shift

2198
01:24:45,240 --> 01:24:46,440
at the next morning meeting

2199
01:24:46,440 --> 01:24:48,840
or after quality links several events together.

2200
01:24:48,840 --> 01:24:50,520
Then let the buffer expire by rule.

2201
01:24:50,520 --> 01:24:52,200
There's one more category where local retention

2202
01:24:52,200 --> 01:24:53,320
should be the default.

2203
01:24:53,320 --> 01:24:54,760
Sensitive raw production evidence

2204
01:24:54,760 --> 01:24:57,400
with unresolved data residency or access rules

2205
01:24:57,400 --> 01:24:58,840
that may include process images,

2206
01:24:58,840 --> 01:25:01,080
recipe-related signals, detailed machine settings,

2207
01:25:01,080 --> 01:25:02,760
customer-specific product evidence

2208
01:25:02,760 --> 01:25:04,280
or records that become sensitive

2209
01:25:04,280 --> 01:25:05,960
when joined with order context.

2210
01:25:05,960 --> 01:25:07,640
If the legal location access model

2211
01:25:07,640 --> 01:25:10,120
supply access or customer terms aren't clear,

2212
01:25:10,120 --> 01:25:12,200
don't treat cloud storage as a temporary answer.

2213
01:25:12,200 --> 01:25:15,000
Temporary cloud storage has a habit of becoming permanent.

2214
01:25:15,000 --> 01:25:16,760
Keep the raw evidence under site control

2215
01:25:16,760 --> 01:25:19,800
until the ownership and policy questions have actual answers.

2216
01:25:19,800 --> 01:25:22,440
None of this means never send raw data to the cloud.

2217
01:25:22,440 --> 01:25:23,960
There are valid exceptions.

2218
01:25:23,960 --> 01:25:27,160
A central engineering team may need a bounded set of fault records,

2219
01:25:27,160 --> 01:25:30,440
a model training effort may need selected labeled samples.

2220
01:25:30,440 --> 01:25:33,640
A quality investigation may require evidence from several sites.

2221
01:25:33,640 --> 01:25:36,840
Those are real cloud use cases when the request names the consumer

2222
01:25:36,840 --> 01:25:39,080
defines the data set and explains

2223
01:25:39,080 --> 01:25:40,760
what decision or work it supports.

2224
01:25:40,760 --> 01:25:42,200
But the transfer needs a plan.

2225
01:25:42,200 --> 01:25:43,880
Define the exact data range,

2226
01:25:43,880 --> 01:25:45,320
not just all history.

2227
01:25:45,320 --> 01:25:47,320
Set a cost owner who accepts the full route

2228
01:25:47,320 --> 01:25:49,240
including copies and later retrieval.

2229
01:25:49,240 --> 01:25:51,480
Set a retention period, access rules,

2230
01:25:51,480 --> 01:25:54,040
and a deletion action before the upload begins.

2231
01:25:54,040 --> 01:25:56,120
If the request can't meet those conditions,

2232
01:25:56,120 --> 01:25:57,800
the data hasn't earned the trip.

2233
01:25:57,800 --> 01:25:59,480
So here's the practical default.

2234
01:25:59,480 --> 01:26:02,280
Keep detailed, fast, local and sensitive factory data

2235
01:26:02,280 --> 01:26:03,640
close to where it starts.

2236
01:26:03,640 --> 01:26:06,440
Send it out with only when a bounded purpose requires it.

2237
01:26:06,440 --> 01:26:10,600
Other data earns a cloud destination much more easily.

2238
01:26:10,600 --> 01:26:13,320
Send these data types to the cloud by default.

2239
01:26:13,320 --> 01:26:16,200
Some factory data gains more meaning when it leaves the site

2240
01:26:16,200 --> 01:26:19,240
because its consumer sits beyond one line or one plant.

2241
01:26:19,240 --> 01:26:22,040
The cloud earns its place when it holds shared facts

2242
01:26:22,040 --> 01:26:23,400
that people need to compare,

2243
01:26:23,400 --> 01:26:26,360
govern, retain or use across a wider operation.

2244
01:26:26,360 --> 01:26:28,680
Start with shift and order facts from MES.

2245
01:26:28,680 --> 01:26:30,600
A completed operation, a produced quantity,

2246
01:26:30,600 --> 01:26:32,280
a reject count, material consumption,

2247
01:26:32,280 --> 01:26:34,600
a work order status, a traceable lot relationship,

2248
01:26:34,600 --> 01:26:36,360
all of that carries business context.

2249
01:26:36,360 --> 01:26:38,280
It tells a story that reaches past the machine

2250
01:26:38,280 --> 01:26:39,080
that produced it.

2251
01:26:39,080 --> 01:26:42,040
Planning, quality, finance, supply chain,

2252
01:26:42,040 --> 01:26:44,520
and central operations may all need the same record,