Your Predictive Maintenance Journey Starts with Getting the Data
Every vendor will sell you predictive maintenance. Dashboards that predict pump failures. ML models that spot bearing degradation. AI that optimizes your energy consumption. The demos are impressive.
Then reality hits. Six to twelve months extracting data from legacy PLCs. Most projects die right there — not because the analytics are hard, but because getting data out of a 15-year-old Modbus RTU is harder than anyone admits.
Why Phase 1 Kills Most Projects
A Reddit thread on r/IndustrialAutomation asked about predictive maintenance reality. The consensus from engineers who have been through it:
- 18-30 months is the realistic timeline for meaningful predictive maintenance from scratch
- Phase 1 (data collection from legacy PLCs) kills more projects than any other phase
- "Keep PLC for control, use independent gateways for data-heavy lifting" — the industry consensus
- Raw sensor readings are noisy and inconsistent — you need baseline data before any analytics matter
- "70% of firmware updates aimed at trade show simulations while shop floor stays broken"
The pattern is always the same: someone buys an expensive analytics platform, discovers their PLCs speak five different protocols across three network segments, and the project stalls for a year while someone figures out how to extract the data.
The Data Plumbing Problem
A typical industrial site has:
- Modbus TCP devices — power meters, inverters, VFDs, RTUs
- Siemens S7 PLCs — S7-300, S7-400, S7-1200, S7-1500 families
- Allen-Bradley PLCs — ControlLogix, CompactLogix via EtherNet/IP
- OPC-UA servers — bridges to everything else
- MQTT sensors — IoT edge devices, environmental monitors
Each protocol needs its own driver. Each driver needs configuration. Each configuration needs testing. And you need a system that can collect, store, and serve all of it without falling over at scale.
The standard approach is a pile of middleware: Kepware for protocol conversion, an MQTT broker for transport, InfluxDB for storage, Grafana for visualization. That is four separate systems, each with its own failure points, each needing updates, each needing someone to maintain it.
Voltrus Is the Pipe, Not the AI
Voltrus does not do predictive maintenance. We have no intention of adding ML models or AI-powered anomaly detection. The OT community has been clear: they do not want AI near safety-critical systems.
What Voltrus does is the unglamorous work that makes predictive maintenance possible:
The Architecture That Actually Works
Experienced SCADA engineers on Reddit agree on the architecture:
- Keep PLC for control. The PLC handles real-time control loops. Do not add data-heavy tasks to the PLC. It has a job to do.
- Use an independent gateway for data. A separate system polls the PLC for data without interfering with control logic.
- Edge validates and contextualizes. Raw sensor data is noisy. Add metadata, validate ranges, apply deadband filtering at the edge.
- Central system for analytics. Push cleaned data to whatever analytics platform you want. The SCADA system is the source of truth for current state.
Voltrus fits into step 2 and 3. It is the independent data gateway that polls PLCs, validates readings, stores history, and exposes clean data to whatever analytics platform your team chooses. For a broader overview of this data flow, see our guide to SCADA architecture.
Real Numbers from Real Deployments
- No dedicated server needed — the entire backend, embedded database, and live data stream
- <1 second cold start — binary boots and serves before your coffee is ready
- 1 binary, 0 dependencies — no Java, no Docker, no InfluxDB, no Grafana, no MQTT broker
- $249 lifetime — not per year, not per tag, not per module. Once.
Run it on a $4/month VPS or a Raspberry Pi next to your PLC cabinet. It runs on the edge because that is where the data is.
What Phase 1 Looks Like with Voltrus
Instead of spending 6 months building middleware, here is what Phase 1 looks like:
- Day 1: Download the binary. Edit the config file with your device IPs and register addresses. For guidance on setting up continuous Modbus TCP data collection, see our guide to monitoring Modbus TCP devices.
- Day 1 (continued): Run it. Data is flowing. Dashboard is live.
- Week 1: Configure alarms, set up data retention, connect your existing MQTT sensors.
- Week 2: Export historical data to CSV. Feed it to your analytics team or platform of choice.
- Month 1: You have a baseline. Real data, real history, real trends. This is what predictive maintenance needs. The same data pipeline also feeds OEE and downtime tracking dashboards for immediate operational visibility.
The analytics platform is your choice. Python, MATLAB, Azure IoT, whatever your data science team prefers. Voltrus provides the clean, validated, historical data through its REST API and CSV exports.
Why This Matters for System Integrators
If you are an integrator, Phase 1 is your opportunity. Your clients have PLCs that need monitoring. They have been told they need "predictive maintenance" by vendors selling $50K platforms. What they actually need first is someone to get the data out reliably.
That is you. Voltrus is the tool that makes it possible in days, not months, at a price that does not require board approval.
Start Phase 1 Today
Stop middleware assembly. Start collecting data. Voltrus handles Modbus TCP, MQTT, OPC-UA, Siemens S7, and Allen-Bradley from a single binary.
From $249. Lifetime license. No recurring fees.
Buy LicenseFrequently Asked Questions
Why do most predictive maintenance projects fail?
Most predictive maintenance projects fail at Phase 1: extracting data from legacy PLCs. Plants typically have equipment from multiple vendors speaking different protocols (Modbus, Siemens S7, Allen-Bradley EtherNet/IP, OPC-UA), spread across different network segments. Getting clean, consistent data out of this mix takes 6-12 months of middleware assembly, and many projects run out of budget or momentum before reaching the analytics phase.
What data do you need for predictive maintenance in manufacturing?
You need baseline time-series data from your existing sensors and PLCs: vibration readings, motor current, temperature trends, pressure cycles, flow rates, and production counters. The key requirement is continuous, timestamped historical data stored at regular intervals. Most analytics models need 3-6 months of baseline data before they can detect anomalies. Raw sensor readings also need validation and deadband filtering at the edge to eliminate noise before analytics.
How do you extract data from legacy PLCs for predictive maintenance?
Use an independent data gateway that polls PLCs for data without interfering with control logic. The gateway needs native drivers for the protocols in your plant: Modbus TCP for energy meters and RTUs, Siemens S7 for Siemens PLCs, EtherNet/IP for Allen-Bradley controllers, OPC-UA for bridges to other systems, and MQTT for IoT edge devices. A tool like Voltrus provides all five protocols in a single binary, collecting data into a local SQLite database with REST API and CSV export for downstream analytics.
How long does it take to set up data collection for predictive maintenance?
With the right tool, data collection can begin on Day 1: download a binary, configure device IPs and register addresses, and start collecting. By Week 2 you can export historical data for your analytics team. A meaningful baseline for predictive maintenance models typically requires 1-3 months of continuous data. The total timeline from scratch to actionable predictive insights is 3-6 months, compared to 12-18 months with traditional middleware stacks.