The Future of IoT in Indian Manufacturing

Start with the machine, not the sensor

Industrial IoT is usually pitched as a sensor problem. Put sensors on things, collect data, gain insight. In practice, the sensors are the easy part and they are not where projects fail.

Projects fail on the machine. The typical Indian factory floor runs equipment that is ten, twenty or thirty years old, works perfectly well, and has no digital interface of any kind. It was never designed to tell you anything. The engineering problem is not "which sensor" but "how do I extract a meaningful signal from a machine that has no interest in cooperating, without modifying it, without voiding its warranty, and without stopping production to install anything."

Any IIoT proposal that does not start from that constraint is describing a factory that does not exist.

Retrofit, do not replace

The good news is that you can learn a remarkable amount about a machine from the outside.

• Current sensing. A clamp-on current transformer around the motor supply tells you whether the machine is running, how hard it is working, and often that something is going wrong. It requires no modification whatsoever and it is frequently the highest-value single sensor you can fit.
• Vibration. An accelerometer on the housing detects bearing wear, imbalance and misalignment long before a human notices. This is the foundation of most genuine predictive maintenance.
• Temperature. Cheap, easy, and a reliable proxy for a great many developing faults.
• Acoustic. Underrated. Machines that are about to fail often sound different well before they behave differently.

Where the equipment does have a digital interface, use it. A great deal of installed industrial equipment speaks Modbus RTU over RS-485, and reading registers from a PLC is far richer than inferring state from the outside. Newer equipment may offer OPC UA. Realistically, a single plant will present you with all three situations, and your gateway has to cope with the mix.

What predictive maintenance actually means

The term is used loosely enough to have lost most of its meaning, so it is worth separating three quite different things.

Reactive maintenance is fixing the machine when it breaks. It is what most plants actually do, whatever their documentation claims.

Preventive maintenance is servicing on a schedule, whether or not the machine needs it. It is better, and it is wasteful: you replace parts with life left in them, and you still get surprised by failures that do not respect your calendar.

Predictive maintenance is servicing when the data says the machine is degrading. This is the prize, and it requires something the other two do not: a baseline. You cannot detect that a vibration signature has changed until you know what normal looks like for that specific machine, on that specific mounting, doing that specific job.

This has a scheduling consequence people rarely plan for. A deployment does not deliver predictive value on day one. It delivers monitoring on day one, and predictive value some months later, once you have observed enough normal operation to recognise abnormal. Set that expectation with whoever is funding the project, or the project will be judged a failure while it is still working correctly.

The architecture that survives a factory

Factories are electrically hostile. Motor drives inject noise, ground potentials differ across a building, and cable runs are long. An architecture that works on a bench will not necessarily survive a shop floor.

What works, in our deployments:

Two properties matter more than anything else here. Local buffering, because the network will go down and data collected during an outage is exactly the data you will wish you had. And local processing, because streaming raw vibration data to the cloud is expensive, slow and unnecessary when the node can compute the features you actually care about and send those instead.

Isolation deserves its own sentence. Optical or galvanic isolation on RS-485 lines and on any sensor input that runs near a motor drive is not optional. We have been called in to fix "unreliable sensors" that turned out to be perfectly good sensors on an unisolated bus sitting next to a variable frequency drive.

Security, stated bluntly

An IIoT deployment adds a network to a factory that previously did not have one, and that network touches production equipment. Get this wrong and you have not improved the plant, you have created a way to stop it.

The non-negotiable principle is segmentation: the monitoring network must not be able to reach the control systems. Data flows outward from the machines. Nothing flows inward to them. If your architecture allows a compromised sensor node to send a command to a PLC, the architecture is wrong, regardless of how good the encryption is.

Beyond that, the basics apply and are frequently skipped. TLS for data in transit. Per-device credentials, not one shared key copied onto two hundred nodes. A plan for rotating those credentials that does not require sending an engineer to every machine. Signed firmware updates, because an update mechanism without signature verification is a remote code execution feature you built on purpose.

What the returns really look like

Downtime reductions in the region of 30 to 40 percent and energy savings around 25 percent are figures we have seen achieved. They are real, and they are also entirely dependent on where you start.

A plant running to failure, with no maintenance discipline and no visibility, has enormous headroom, and even basic monitoring produces dramatic numbers. A plant already running a competent preventive maintenance programme with experienced operators has far less to gain, and the honest projection is correspondingly more modest.

Be sceptical of anyone who quotes you a return before they have walked your floor. The number depends on your machines, your current practice and your failure history, and none of those are knowable from a brochure.

The other thing worth saying is that the first value you get is rarely predictive. It is visibility. Simply knowing which machines are actually running, for how long, and at what load, routinely surprises plant managers who were confident they already knew. Utilisation data alone has justified deployments before a single failure was predicted.

How to start

Do not instrument the whole factory. Pick one machine: ideally the one whose failure hurts most, or the one that fails most often. Instrument it properly, run it for a few months, and find out what the data tells you about that one machine.

You will learn things that change your design. You will discover which sensors mattered and which produced noise. You will discover that the network coverage in the far corner of the shed is worse than you assumed. You will discover that the maintenance team has opinions about what would actually be useful, and those opinions are usually correct.

Then expand, with a design that has survived contact with your actual factory rather than an idealised one. Plants that instrument everything at once, on a vendor's recommendation, tend to end up with a large quantity of data that nobody uses and a system that nobody trusts.

Sources and further reading

Primary references for the standards, regulations and figures cited above:

• Modbus Organization — Modbus specifications — The Modbus RTU/TCP specification, the protocol most installed industrial equipment already speaks.
• OPC Foundation — OPC UA — The interoperability standard found on newer industrial equipment.
• MQTT specification — OASIS — The publish/subscribe protocol used for edge-to-cloud telemetry.
• Make in India — Electronics manufacturing schemes — Government of India reference on manufacturing and Industry 4.0 incentives.