Most machine monitoring projects in Indian factories die at the dashboard. The data arrives, a screen lights up in the manager’s cabin, and nothing on the shop floor changes.
The projects that survive start with one machine, one question and one action. This guide covers what to measure, which signals you can get without touching the PLC, how to design a six-week pilot, what it costs, and the questions that separate a useful vendor from a dashboard salesman.
Start with the question, not the sensor
“We want Industry 4.0” is not a requirement. A requirement sounds like one of these:
- “Why did machine 4 stop for 90 minutes yesterday, and can we see it within five minutes next time?”
- “What is the real OEE of the press line, measured rather than estimated?”
- “How many parts did we actually make this shift, and where did the count disagree with dispatch?”
- “Which of our twenty machines has the worst unplanned downtime this month?”
Each question implies a different data set. The first needs state and reason codes. The second needs state, count and ideal cycle time. The third needs a reliable counter and a shift calendar. The fourth needs all of it, aggregated. Choosing the question first prevents buying sensors you will never look at.
Three levels of data collection
Almost every machine in an Indian SME falls into one of three categories. The category decides the cost and the effort far more than the software does.
| Level | Machine type | How you get data | Effort |
|---|---|---|---|
| Native | New CNC, robot, VFD with Ethernet | Read tags over Modbus TCP, OPC UA or EtherNet/IP | Low, needs a protocol map |
| Retrofit | Older machine with a PLC but no network | Add a gateway to the PLC port, or tap IO signals | Medium, needs electrical work |
| Sensor-only | Manual or very old machine | Clamp current, count parts, watch the stack light | Low cost, lower fidelity |
Do not assume a machine is “not ready”. A current clamp on the main spindle plus a photoelectric part counter gives you run state and production count on a machine built in 1998. It cannot tell you which fault occurred, but it answers the first question well enough to start.
Signals worth collecting
Keep the first version small. Six signals on one machine beats sixty signals nobody trusts.
| Signal | What it tells you | How to get it |
|---|---|---|
| Run / stop state | Availability, downtime duration | PLC bit, stack light, or current threshold |
| Part count | Production, cycle time, OEE performance | PLC counter or photoelectric sensor |
| Cycle time | Drift, tool wear, starvation | Timestamp between count events |
| Fault code | Reason for downtime | PLC register, alarm word, or HMI log |
| Spindle or motor current | Load, tool condition, jams | Clamp CT or drive parameter |
| Vibration | Bearing wear, imbalance | Accelerometer on the housing |
Two design rules make the data usable. First, timestamp at the edge, not in the cloud, so a network outage does not smear events. Second, store raw state transitions rather than one-minute averages, because averages hide the short stops that matter most to OEE.
Getting data out of the PLC
If the machine already has a networked PLC, you have three realistic options.
- Modbus TCP — simple, widely supported, register-based. Ideal for a pilot. The Modbus and RS-485 guide covers addressing and the classic pitfalls.
- OPC UA — richer data model, built-in security, better for multi-vendor sites. Slightly more setup on older controllers.
- EtherNet/IP or Profinet — native on many machines, but usually requires care because you are joining a control network that the machine expects to own.
Never read from a control network without agreeing the polling rate and the load with the machine builder. A gateway that polls too aggressively can add jitter to a control loop, and that conversation goes badly if it happens after installation. The industrial Ethernet overview explains the network families and where each belongs.
From data to an action
Design the response before the dashboard
For every metric on the screen, write down who acts on it and what they do. If the answer is “the manager looks at it”, delete the metric.
- Downtime over ten minutes — a message to the shift supervisor with the machine and fault code, within two minutes.
- Cycle time drift over eight percent — a notification to the maintenance lead, because it usually means tool wear or a starving upstream station.
- Count mismatch at shift end — an automatic reconciliation report, not a manual argument.
- Machine idle while a job is queued — a signal to planning, which is often worth more than all the OEE charts.
Alarms need an owner and a threshold that was tested against a week of real data. An alarm that fires fifty times a week is ignored within a fortnight, and after that the whole system is ignored with it.
Cloud, on-premise or hybrid
For a single plant, a small on-premise server or an industrial PC running an MQTT broker and a time-series database is often the simplest and cheapest option. It keeps working when the internet does not, and it avoids a monthly bill before the project has proved value.
Cloud makes sense when you need multi-plant roll-up, remote access for an OEM, or analytics you cannot run locally. A hybrid pattern works well: buffer at the edge, publish to a broker, and sync to cloud when connectivity allows. MQTT is the usual transport, and the MQTT telemetry walkthrough shows the publish and buffer pattern at a small scale.
| Option | Monthly cost | Works offline | Best for |
|---|---|---|---|
| On-premise PC | None after hardware | Yes | Single plant pilot |
| Cloud SaaS per machine | Recurring per machine | Partially, with edge buffer | Multi-site roll-up |
| Hybrid edge plus cloud | Hardware plus subscription | Yes at the edge | Scaling after a proven pilot |
Indicative costs
These are planning bands for a single-machine pilot, not quotations. Hardware prices in India vary with import duty and brand, and integration labour is the largest variable.
| Item | Indicative range | Notes |
|---|---|---|
| Edge gateway | ₹15,000 to ₹60,000 | Industrial PC or protocol gateway |
| Sensors and clamps | ₹5,000 to ₹40,000 | Depends on whether you need vibration |
| Wiring and panel work | ₹10,000 to ₹50,000 | Higher if the cabinet needs modification |
| Software licence | ₹0 to ₹1,50,000 per year | Open-source stack can start at zero |
| Integration and configuration | ₹50,000 to ₹3,00,000 | Protocol mapping, dashboards, alarms |
A pilot on one machine with a Modbus-capable PLC and an open-source stack can be done for well under a lakh in hardware. A turnkey multi-machine deployment with a commercial platform lands far higher, and the recurring licence is the number finance will question first.
A six-week pilot plan
- Week 1: pick one machine with a real, quantified problem. Write the question and the action. Agree who receives the alarm.
- Week 2: map the signals. Get the PLC tag list or install the sensors. Photograph the cabinet and label every cable.
- Week 3: install the gateway and buffer locally. Collect raw data with no dashboard at all.
- Week 4: validate against reality. Sit with the operator and check that each stop in the data matches a real stop.
- Week 5: build one screen and one alarm. Test the alarm fifty times, including at shift change and during a network drop.
- Week 6: measure. Compare downtime before and after, and decide whether to extend, change or stop.
Week 4 is the one teams skip and the one that decides the project. Data that does not match what the operator saw is worse than no data, because it destroys trust in everything that follows.
Questions to ask a vendor
- “Show me a plant where this is running, and the person who uses it daily.” A reference customer who does not use the system is not a reference.
- “What is your protocol coverage for my specific controller model?” Generic “supports all PLCs” claims usually mean Modbus only.
- “What happens to data during a network outage?” If the answer is “it is lost”, the OEE numbers will be wrong every time the line trips.
- “Who owns the data and the configuration, and can I export everything?” Lock-in is a commercial decision, not a technical one.
- “What is the annual cost per machine at 20 machines?” The pilot price is rarely the real price.
If the pilot also involves robot cells, the same discipline applies to the robot data. The robot maintenance checklist shows which signals are worth trending, and the integration checklist covers the interfaces that must be agreed before commissioning. For a financial view of the same decision, robot ROI calculation shows how to justify the spend to a plant manager.
Do I need a new PLC to monitor an old machine?
No. You can tap existing IO, add a photoelectric counter, clamp the motor current, or read the stack light. A networked gateway is only needed if the machine already has a controller you can query.
Can I start with one machine and scale later?
Yes, and you should. A single-machine pilot proves the data quality, the alarm discipline and the value before you commit to a plant-wide rollout.
Is cloud storage necessary?
No. A small on-premise server keeps working during internet outages and avoids a recurring bill. Cloud is useful for multi-plant roll-up and remote support.
How accurate is current-based run detection?
Good enough for availability and rough cycle counting when the thresholds are set from real data. It cannot identify fault reasons, so pair it with a fault code or operator input if that matters.
What is a realistic payback period?
For a machine with significant unplanned downtime, a single-machine pilot often pays back within months through faster response alone. That depends on the actual downtime cost, which should be measured before the project starts.
Fleet utilisation is measured with the same monitoring layer, described in the AMR and AGV guide and the machine monitoring overview.
Data collection only pays off when the cell reports why it stopped, and the SCADA section covers what to log first.
Dashboards only help once the definitions are agreed; the OEE calculation guide sets out the terms to lock down first.
Sources and further reading
- OPC Foundation — OPC UA specifications and companion specifications.
- MQTT — protocol specification and publish-subscribe design.
- Eclipse Mosquitto — open-source MQTT broker for on-premise deployments.
- International Society of Automation — ISA-95 enterprise-control integration framework.
