# Turning machine sensor streams into decisions
A CNC spindle (the rotating tool holder in a computer-controlled milling machine) is spinning at 12,000 RPM, cutting aluminum. A tiny accelerometer bolted to its housing feels a vibration: 0.8 g at 200 Hz. That single reading is about to travel from steel to screen. Whether it ends up preventing a $40,000 spindle failure or drowning in noise depends entirely on choices made in the next few milliseconds.
Let's follow it.
The accelerometer converts physical motion into a voltage. But a voltage is continuous, and computers need discrete numbers. So the sensor samples: it measures the signal many times per second.
How many times matters enormously. The sampling rate (measurements per second, in Hz) must be high enough to capture the frequencies you care about.
The rule here is the Nyquist theorem: to capture a signal at frequency *f*, you must sample at least twice as fast (2*f*). Miss this, and you get aliasing: fast vibrations masquerade as slow ones, and your data lies to you.
Practical translation:
Sampling too slow hides problems. Sampling too fast floods your network and storage with data nobody uses. A spindle sampled at 20 kHz on three axes generates roughly 60,000 numbers per second, per machine. Multiply by 200 machines. You see the problem.
Sending raw 20 kHz streams from every machine to the cloud is expensive and slow. So we process near the machine, at the edge (a small industrial computer or gateway sitting on the plant floor).
The edge does the triage:
This is the difference between drowning and drinking. The raw reading stays local (or is stored briefly); a compact, meaningful feature travels onward.
Here is what edge feature extraction looks like conceptually:
import numpy as np
# 4096 raw samples from the accelerometer, sampled at 20 kHz
rms = np.sqrt(np.mean(samples**2)) # overall vibration energy
spectrum = np.abs(np.fft.rfft(samples)) # frequency breakdown
peak_hz = np.argmax(spectrum) * (20000 / len(samples))
# Only escalate if it matters
if rms > SPINDLE_LIMIT:
publish("plant1/line3/cnc07/spindle/vib_rms", rms)Notice that last line. The reading now has a name.
This is the least glamorous and most important part of the whole journey.
A tag is the label attached to a data point so systems know what it represents. plant1/line3/cnc07/spindle/vib_rms tells you the site, line, machine, component, and measurement. Compare that to a tag named SENSOR_4471 or TAG00293.
Bad tag naming is the single biggest reason plant-floor IoT projects stall. When an analyst three months later cannot tell whether TEMP2 is a coolant temperature or a motor winding temperature, the data is worthless.
Good naming conventions are:
Many manufacturers align to standards like the ISA-95 hierarchy (a framework for structuring enterprise-to-plant-floor information). A useful free primer on the modern approach is the Unified Namespace concept, which organizes all plant data into one consistent, hierarchical structure.
Get naming right once, and every dashboard, alert, and model afterward becomes easy. Get it wrong, and you pay forever.
The named reading now travels over a messaging protocol. The two you will hear most:
For a broad audience: think of MQTT as a mailroom where machines drop labeled letters and interested parties pick them up, without needing to know each other directly.
🎬 [VIDEO: "MQTT Explained in 5 Minutes" — youtube.com — a concise, vendor-neutral intro to how publish/subscribe messaging works for IoT]
Our reading arrives at a database. But not just any database.
Sensor data is time-series data: every point is a value stamped with an exact time. A regular business database (rows of customers, orders) handles this poorly. It bloats fast and struggles to answer questions like "average spindle vibration per minute over the last 90 days."
A time-series database (TSDB), such as InfluxDB or TimescaleDB, is built for exactly this:
A typical query is refreshingly readable:
SELECT time_bucket('1 minute', time) AS minute,
avg(vib_rms)
FROM spindle_vibration
WHERE machine = 'cnc07'
AND time > now() - interval '24 hours'
GROUP BY minute;One more critical detail: time synchronization. If cnc07's clock drifts from cnc08's, you cannot correlate events across machines. Plants use protocols like NTP or PTP to keep every device on the same clock. When a whole line hiccups at 2:14:03 PM, synchronized timestamps let you prove it.
Knowledge check
1. A team wants to diagnose a bearing defect that produces a characteristic frequency at 5,000 Hz. According to the Nyquist theorem, what is the minimum sampling rate they must use?
2. What is the primary consequence of aliasing in a sensor data stream?
3. Why is feature extraction (e.g., computing RMS) performed at the edge rather than shipping all raw samples to the cloud?
4. Select ALL correct answers about choosing a sampling rate for a monitoring application.
Select all the correct answers.
5. Select ALL correct answers describing what the edge (a plant-floor gateway or industrial computer) typically does.
Select all the correct answers.
Storage is not the goal. A decision is. Our vibration reading now feeds three layers of usefulness.
A dashboard shows live spindle RMS per machine. An operator glances and sees cnc07 trending orange. This is descriptive: the data reports reality.
A rule fires when RMS crosses a threshold, or better, when it deviates from the machine's own normal baseline. The maintenance lead gets a message before the part scraps. This is where downtime and cost actually fall.
With months of clean, well-tagged, well-timestamped history, you can train models to spot the vibration signature that precedes a bearing failure. This is predictive maintenance: acting before the breakdown, not after.
Note the dependency chain. Prediction needs history. Good history needs correct sampling, sane tags, and synchronized time. The unglamorous early steps are what make the impressive final step possible. Teams that skip to "let's do AI" without fixing tag naming almost always fail.
Physical vibration to accelerometer to sampled signal to edge feature to named tag to MQTT to time-series database to dashboard to decision.
Every handoff can add value or destroy it. A too-slow sampling rate erases the fault frequency. A vague tag orphans the data. An unsynchronized clock breaks correlation. A missing retention policy either loses history or bankrupts your storage budget.
The lesson for a manufacturing leader: data quality on the plant floor is an engineering discipline, not an IT afterthought. The most valuable predictive model is worthless if TAG00293 was pointing at the wrong axis all along.
You do not need to instrument every machine at 20 kHz on day one. Start where failure is expensive and predictable:
Pilot on a handful, prove the tag structure and storage approach, then scale. This staged approach is widely recommended precisely because early tagging and architecture mistakes are expensive to unwind later.