A sensor on a pump measures vibration twenty times per second. Before this value appears as a graph on the shift supervisor’s dashboard, it passes through several stages: data acquisition at the machine, preprocessing, transmission, storage, and analysis. Anyone who wants to collect machine data and use it in the dashboard must therefore plan the entire process chain.
The machine data chain has three levels: the edge at the machine, a local server at each location, and the cloud for cross-location metrics. Edge computing processes 80 to 90 percent of the raw data directly on-site; only aggregated metrics are transmitted further. Data is usually transmitted via MQTT, for structured control data via OPC UA.
Raw data is generated daily at a factory with 200 machines operating in two shifts. This volume of data cannot be transferred entirely to the cloud, nor can it be stored permanently on each machine.
ECOSIRE, 2026
Why Edge Computing Pre-Filters Machine Data
Edge computing processes 80 to 90 percent of the data generated directly at or near the machine before any of it is sent to a central network (ECOSIRE, 2026). Only aggregated metrics, anomalies, or alarms are forwarded to higher levels. A vibration sensor thus sends locally calculated metrics—such as the root mean square (RMS) value or peak value—to the cloud, supplemented by the rare instances in which the raw data is needed for a more in-depth analysis.
This setup not only saves bandwidth; it also reduces response time because a critical alarm doesn't have to pass through a data center on the other side of the country before triggering a response at the machine.
Protocol and Architecture
| Level | Task | What Remains There |
|---|---|---|
| Edge, at the machine | Initial processing, calculating parameters, triggering alarms | Raw measurement at full resolution |
| Local server, per location | Aggregate Data from Multiple Machines | Summary of Key Metrics, Trends Over the Past Few Weeks |
| Cloud, Across Locations | Plant Comparison, Key Metrics at the Company Level | Key Figures and Selected Events |
MQTT has established itself as the standard protocol for data transmission, in part due to its publish-subscribe pattern and the small size of its messages (ECOSIRE, 2026). A sensor publishes its values to a topic, and multiple systems can subscribe to it simultaneously without the sensor needing to be aware of each connection individually. For machines with more complex control data, OPC UA is often used in addition, as it provides structured information and security mechanisms.
Not every business needs all three tiers right from the start. A single location can often get by with just an edge server and a local server.
The Most Common Mistake in Sensor Selection
ECOSIRE cites a mismatch between the sensor and the actual failure pattern as the main reason why projects fail (ECOSIRE, 2026). If you select sensors based on machine type rather than on the fault you actually want to predict, you’ll end up collecting data that ultimately tells you nothing. A pump can fail due to cavitation, bearing damage, or imbalance; each of these causes manifests in a different frequency range and requires a different measurement technique.
In practice, therefore, the question that comes before sensor selection is which fault is actually relevant on this machine and how it makes itself felt physically. Only then can it be decided whether a simple vibration sensor is enough or whether temperature, current or sound have to be measured as well. Which parameters are suitable for rotating components is covered in the article on Vibration Analysis.
What ends up in the dashboard
A dashboard with too many graphs is rarely used because no one can tell which deviations are actually relevant. A tiered structure has proven effective. At the top level, there are just a few traffic-light indicators per machine; below that, individual sensor readings can be viewed in detail as needed.
The time perspective is also important. A single instantaneous reading doesn’t tell us much, but a trend over the past few days or weeks shows whether a machine is slowly moving toward a failure pattern. It is precisely this trend view that distinguishes a simple live display from a dashboard that actually helps with maintenance.
Data retention periods for machine data are a topic in and of themselves. Retaining raw data at full resolution for years is rarely practical and unnecessarily drives up storage costs. In contrast, aggregated metrics can be stored cost-effectively over long periods and provide the basis for later trend analyses or for a Predictive Maintenance Model.
What data do you already have on hand?We'll assess which of your machines are already providing usable data and what's still needed to create a functional dashboard.
Frequently Asked Questions
What protocols are used for machine data collection?
The most widely used protocols are MQTT for the lightweight transmission of measurement values and OPC UA for structured, safety-related machine data. Many architectures combine both protocols depending on the use case.
How much data actually needs to be stored?
Significantly less than the amount generated by the machine. With edge computing, 80 to 90 percent of the raw data is processed on-site, so that only aggregated metrics and selected raw data are transmitted and stored (ECOSIRE, 2026). In a factory with 200 machines and approximately 400 gigabytes of raw data per day, this difference is what makes operating a centralized analysis system economically feasible in the first place.
Who actually sets up this kind of data chain in practice?
This usually involves a collaboration between a maintenance team that is familiar with the types of faults and an integration partner who technically connects the sensors, network, and analysis systems. Pure software providers with no understanding of the machine rarely deliver the right architecture.
The Next Step
torck operates its plant monitoring as a standalone product and manages the entire process—from sensor selection to the dashboard—itself, with in-house teams in Maxhütte-Haidhof, Vienna, and Rabat that develop edge processing, protocol integration, and data analysis in-house. You can schedule an initial consultation via our page at Plant Monitoring .
German 
English 
French