Smart manufacturing in Indian factories 2026: the IoT retrofit layer that comes before the AI
Summary. Every predictive maintenance pitch assumes a machine that already emits data. Most machines on an Indian plant floor do not. Before a model can predict a bearing failure, someone has to bolt a sensor to a machine built in 2004, get its output onto a network, and translate it from a protocol whose serial specification the Modbus Organization itself marks "FOR LEGACY APPLICATIONS ONLY" and dates to 1996. That layer is the project. A Modbus-to-Ethernet gateway lists at $275.00 and a vibration and temperature sensor at $195.00, so the hardware is not what stops anyone. Two things do. Sampling vibration at 10 kHz across 5,000 sensors and 30 plants produces roughly 1.5 TB a day by TDengine's illustration, which is why edge preprocessing that cuts data "by a factor of 10,000" is the difference between a pilot and a bill. And the Ministry of Heavy Industries stated in a Rajya Sabha reply on 13 December 2024 that "No financial assistance is given to any industry including MSME for adopting Industry 4.0 enabled technologies under SAMARTH centre initiative of the Scheme." India's flagship smart manufacturing programme gives you four centres, an assessment tool and training. Not a subsidy.
The layer everyone skips
There is a genre of Industry 4.0 content that starts at the model. It shows a dashboard, an anomaly score, a saved maintenance window. We have written some of it: our pieces on AI predictive maintenance ROI on the Indian factory floor and Industry 4.0 on the Indian factory floor both assume a working data feed, as does our look at physical AI and robot arms in Indian manufacturing.
This article is about the assumption underneath all of them. A brownfield plant is one with machines already installed, running, and paid for, most of which were specified before anyone intended to read them over a network. The AI question for those plants is not which model. It is whether the machine can be made to speak at all, and what that costs.
A note on evidence before we start, because it matters here more than usual. The statistic everyone quotes for this problem, some version of "85% of factory machines are not connected", does not survive a source check. Every instance we could trace leads to a vendor marketing post citing another vendor marketing post, not to a survey anyone published. We are not going to repeat it. The absence of a citable number for the central fact of brownfield manufacturing is itself worth knowing, and it should make you suspicious of any vendor deck that leads with one.
What the old machines actually speak
Modbus, and why it will not go away
Modbus is the floor you are standing on. The Modbus Organization's current application protocol specification is V1.1b3, and its own documents page is unusually candid about the state of the estate. The serial specification carries the heading "Modbus Over Serial Line FOR LEGACY APPLICATIONS ONLY", described as "This is the obsolete Modbus specification from 1996. Use only to address legacy issues. Please do not use it for new implementations."
Read that against a plant floor where machines from the 1990s and 2000s are still producing parts, profitably, today. The standards body says do not build new things on it. The capital equipment on your floor was built on it and will outlive the advice.
Security is the part to understand before you connect anything. Base Modbus has none. It was not weakened; it was specified for a serial cable inside a locked cabinet, where the network was the physical wire. Authentication was added later and separately: the Modbus Security protocol "provides protection through the blending of Transport Layer Security (TLS) with the traditional Modbus protocol", encapsulating Modbus packets for "authentication and message-integrity protection", using "X.509v3 digital certificates for authentication of the Server and Client", and running on its own port 802.
That is an opt-in, additional protocol. Almost nothing on a 2004 machine speaks it. When you put that machine on a network, you are putting an unauthenticated control protocol on a network. Design for that.
OPC UA, and what it is for
OPC UA is the modern answer, and it is a genuinely different class of thing. The OPC Foundation describes it as a specification "released in 2008" that is "a platform independent service-oriented architecture that integrates all the functionality of the individual OPC Classic specifications into one extensible framework", with stated design goals including "Platform independence: from an embedded micro-controller to cloud-based infrastructure", "Secure: encryption, authentication, and auditing", and "Comprehensive information modeling: for defining complex information".
The specification is alive and versioned in parts rather than as one number. As of July 2026 the OPC UA online reference lists Part 1 (Overview and Concepts) at 1.05.06, Part 2 (Security Model) at 1.05.06, Part 4 (Services) at 1.05.07, Part 6 (Mappings) at 1.05.07 and Part 14 (PubSub) at 1.05.06. The newer field-level family, UAFX, sits at 1.00.03 across Parts 80 to 84.
That field-level work is where 2026 activity is. The OPC Foundation's Field Level Communications Corner reported in June 2026 that "Following the successful completion of the OPC UA FX Controller-to-Controller (C2C) specifications, the FLC technical working groups are right now preparing a release candidate with extensions to support Controller-to-Device (C2D) communication and smooth integration of motion devices, remote I/O systems, sensors, actuators, and other field devices." A multi-vendor demo is being prepared for SPS 2026.
Controller-to-device is at release-candidate stage, not shipped. If a vendor tells you OPC UA FX solves your field devices today, ask which specification version they are shipping against.
The important structural point for retrofit is that OPC UA has two communication patterns, and the one most people mean is the wrong one for telemetry. In client-server, per the Foundation, "each notification is for a single client with guaranteed delivery", whereas PubSub "has been optimized for many-to-many configurations", where "Publishers send messages to a Message Oriented Middleware, without knowledge of what, if any, Subscribers there may be."
The polling problem
Here is the failure mode that turns a working pilot into a network incident, and it is inherent to the protocols, not to any product.
Dominik Obermaier, co-founder of HiveMQ, who "is a member of the OASIS Technical Committee and is part of the standardization committee for MQTT 3.1.1 and MQTT 5", put the case against poll/response plainly in February 2026: "Sparkplug uses the Pub/Sub architecture pattern for scalable and efficient communication, which is dramatically different to traditional Poll/Response protocols used in the last 40+ years in industrial automation, discrete manufacturing, and in industries like Oil & Gas. This means that the communication protocols of the last decades require a very tight coupling between the producer of data (often PLCs) and the consumers of data."
His stated disadvantages of polling are worth quoting exactly, because each one is a line item in your retrofit budget: "No state awareness", meaning "state needs to be polled all the time, sometimes multiple times per second for every device to make sure no important data or state change is lost"; "Massive amount of unnecessary data traffic"; "Compute intensive on the polled devices"; "Tight coupling between polled and polling components. If a data producer needs to be changed / replaced, multiple systems need to be reconfigured, possibly with downtime"; and "Doesn't scale to large amounts of data producers".
Note his last word on scope: "This polling approach is used widely in the industry and protocols like Modbus and OPC-UA." Moving from Modbus to OPC UA client-server does not fix polling. It upgrades what you poll with.
MQTT and Sparkplug
MQTT is the transport that breaks the coupling. MQTT Version 5.0 is an OASIS Standard dated 07 March 2019, described as "A Client Server publish/subscribe messaging transport protocol. It is light weight, open, simple, and designed to be easy to implement."
MQTT alone is not enough for a plant, and the Eclipse Foundation is direct about why: "By design, the MQTT specification does not dictate a Topic Namespace or any payload encoding." Two integrators will produce two incompatible plants using the same standard. Sparkplug closes that. It "defines an OT-centric Topic Namespace", "an OT-centric Payload definition optimized for industrial process variables", and "MQTT Session State management required by real-time OT SCADA systems". Eclipse's own framing: "Sparkplug can be thought of as the HTML of IIoT."
Versions confuse people, so be precise. The current specification is Sparkplug 3.0, dated 21 October 2022. "Sparkplug B" is not a version of the spec; it is the payload definition, added back in revision 2.1 on 10 December 2016. Anyone selling you "Sparkplug B support" in 2026 is describing a payload format from 2016, which is fine, but ask whether they are current with 3.0.
On lock-in, which a plant lead should ask about: the specification can be implemented "for any purpose without fee or royalty under the terms of the Eclipse Foundation Specification License (EFSL)". Cirrus Link Solutions holds a related patent, "Sparkplug-aware MQTT Server", granted as US 11121930 B1, and has granted "an irrevocable (subject to a defensive termination provision), non-exclusive, worldwide, royalty-free, transferable patent license with respect to the final specification". Eclipse Tahu provides reference implementations in C, C#, Java, JavaScript and Python.
The single most useful sentence for anyone planning a brownfield retrofit comes from Eclipse's own FAQ, and it settles the OPC-versus-MQTT argument that consumes so many meetings: "Sparkplug infrastructure will not replace OPC but will rather complement it. In existing brownfield industrial sites, OPC-UA polling engines are used to gain access to the raw process variables, for example."
You do not choose. You poll the old machine with whatever it speaks, then publish once.
What it costs to make one machine talk
Hardware is the cheapest part of this project, which is why leading with it is a mistake. Verified list prices as of 16 July 2026:
| Component | Function | Price | Source |
|---|---|---|---|
| AutomationDirect MB-GATEWAY | Modbus gateway, Ethernet to serial, 12 simultaneous Ethernet connections, 128 serial devices | $275.00 new | Vendor page, 16 Jul 2026 |
| AutomationDirect MB-GATEWAY, remanufactured | As above | $220.00 | Vendor page, 16 Jul 2026 |
| Banner QM42VT1 | Machine vibration and ambient temperature, IP67 NEMA 6, -40 to +105C | $195.00 | Authorised distributor listing |
| AutomationDirect STRIDE SGW-MQ1611 | Modbus RTU/TCP to MQTT, SSL/TLS, up to 32 Modbus devices | Not published | Vendor page; price not listed |
| Sparkplug specification | Topic namespace, payload, session state | Free, EFSL | Eclipse Foundation |
| Eclipse Tahu libraries | Reference implementation, C, C#, Java, JavaScript, Python | Free, open source | Eclipse Foundation |
Two honest caveats. Both hardware prices are United States distributor prices in dollars, not Indian landed cost, and we found no verifiable Indian list price for equivalent hardware. Add customs, duty and local distribution before you plan against these. The QM42VT1 figure is a distributor price rather than a Banner list price.
The point survives the caveats. A gateway and a sensor to instrument one machine is a few hundred dollars. If the hardware were the obstacle, every plant in the country would already be connected. The obstacle is the integration, the network design, and the data volume that arrives afterwards.
The data volume problem, and why the edge is not optional
This is where retrofits actually fail financially.
Vibration is the signal that predicts mechanical failure, and it is high-frequency. Jim Fan, VP of Product at TDengine, whose background includes PTC's IoT Division and Hexagon's Smart Manufacturing Division, describes sensors that collect "high-frequency data, often sampling at rates over 10 kHz, to detect machine abnormalities and prevent costly failures", and offers this illustration of scale: "a manufacturing network of 30 plants, each with 5,000 sensors sampling at 10 kHz, can produce over 1.5 million data points per second, or 1.5 TB daily."
That is a vendor's constructed example rather than a measurement, and it should be read as an order of magnitude, not a benchmark. But the order of magnitude is the whole argument. No Indian plant is shipping 1.5 TB a day to a cloud region over a leased line and calling it a business case.
The answer is to summarise at the edge, and the compression is not incremental. Anthony Cavin of ReductStore, writing on high-frequency vibration storage, gives the ratio: "For an original data chunk sampled at 10 kHz, the resulting data size can be reduced by a factor of 10,000." The standard summary metrics he describes are RMS, "the average magnitude of an alternating signal"; P2P, "the contrast between the minimum and maximum values of each signal data"; and Crest Factor, "a ratio of peak to RMS", which "indicates how much the peaks in the signal exceed the average (RMS) level".
The trade is real and you should make it deliberately. Raw data "is essential for in-depth diagnostics because it preserves all the nuances of the original signal", and with it "industries have the flexibility to revisit and re-analyze the data as new algorithms and diagnostic techniques are developed", supporting FFT, time domain analysis, wavelet transform, envelope analysis and modal analysis. Summarise everything and you have cheap storage and no ability to re-diagnose last quarter's failure with next quarter's method.
The workable pattern is a retention policy rather than a choice. Keep summaries forever, keep raw windows around events, and expire the rest. Cavin notes the failure mode that forces this: "local storage can also lead to disk overrun problems", managed with "First-In-First-Out (FIFO) data retention policies" that are "especially important in edge applications where devices can run out of disk space", plus replication of "important chunks of data based on key metrics such as RMS values, peak amplitude, or other critical indicators".
Design that policy before you buy sensors. It determines your gateway storage, your uplink, and your cloud bill, and it is very difficult to retrofit onto a retrofit.
India: what SAMARTH actually gives you
This is the section where most content about Indian smart manufacturing gets it backwards, and the primary source is unambiguous.
The Ministry of Heavy Industries, answering in the Rajya Sabha on 13 December 2024, described the SAMARTH Udyog Bharat 4.0 initiative under the Scheme for "Enhancement of Competitiveness in the Indian Capital Goods Sector". It has set up four Smart Advanced Manufacturing and Rapid Transformation Hub centres: "Centre for Industry 4.0 (C4i4) Lab, Pune; IITD-AIA Foundation for Smart Manufacturing, IIT Delhi; I-4.0 India @ IISc, Bengaluru; and Smart Manufacturing Demo & Development Cell, CMTI, Bengaluru." A further "10 cluster Industry 4.0 experience centres have been approved" under a hub and spoke model.
What those centres have produced, per the same reply: "Over 50 use-cases of Industry 4.0 solutions were compiled for implementation support by C4i4, Pune"; an "Industry 4.0 Maturity Model (I4MM) specific for Indian manufacturing companies"; a "Free Online Assessment Tool" for MSME self-assessment; "Over 100 Digital Maturity Assessments completed for Auto Companies; 500+ Improvement initiatives identified for industry; 500+ Digital Champions trained on Industry 4.0 by C4i4 Lab, Pune"; "6 Smart Technologies, 5 Smart Tools, 14 solutions developed by I-4.0 India @ IISc, Bengaluru"; and "CMTI Bengaluru trained about 5000 professionals on Smart Manufacturing & Industry 4.0". The centres also provide "consultancy (in areas such as IOT Hardware, Software development, data analytics) and incubation support to start-ups including MSMEs".
Then the sentence that should change your plan: "No financial assistance is given to any industry including MSME for adopting Industry 4.0 enabled technologies under SAMARTH centre initiative of the Scheme."
SAMARTH is an advisory and training programme. Free assessment, real expertise, no cheque. Budget the gateways yourself.
The other scheme people reach for is Production Linked Incentive, and it does not fit this use case either. PLI rewards incremental production and sales in named sectors. Per the Ministry of Commerce and Industry on 22 March 2025, "764 applications have been approved under PLI Schemes for 14 key sectors" with "176 MSMEs" among the beneficiaries, actual investment "of around Rs 1.61 lakh crore (US$ 18.72 billion)" reported "till November 2024", production and sales "of around Rs 14 lakh crore", exports "surpassing Rs 5.31 lakh crore", employment "over 11.5 lakhs (Direct & Indirect)", and "Incentive amount of around Rs. 14020 crore disbursed under PLI Schemes for 10 Sectors".
Nothing in that ties an incentive to instrumenting a machine. PLI may pay you for making more, which a working retrofit might help you do. It will not fund the retrofit.
One sobering line from the same release, worth keeping in view when a consultant projects your Industry 4.0 payback: in the specialty steel scheme, "14 of 58 projects withdrew from the scheme either because of change in business plans of the company and project execution delays."
Security: what you can actually stand behind
Putting a 2004 machine on a network is a security decision, and it deserves better than a diagram.
The citable anchor is NIST Special Publication 800-82 Revision 3, "Guide to Operational Technology (OT) Security", published September 2023, superseding Revision 2 from 2015, with a Revision 4 currently in draft. Its stated scope: "This document provides guidance on how to secure operational technology (OT) while addressing their unique performance, reliability, and safety requirements", covering "an overview of OT and typical system topologies", identifying "common threats and vulnerabilities to these systems", and providing "recommended security countermeasures to mitigate the associated risks".
We are deliberately not printing clause numbers from IEC 62443 or a Purdue level diagram here. Those standards sit behind paywalls, the versions and clause numbering matter, and the secondary sources that summarise them disagree with each other. If your retrofit needs a segmentation design certified against 62443, buy the standard or hire someone who has it. Do not build it from blog posts, including this one.
What you can act on without any standard: the unauthenticated protocol is the threat model. Base Modbus has no authentication, most brownfield machines cannot speak Modbus Security over TLS on port 802, and therefore the gateway is your control boundary. It is the last place you can terminate an untrusted protocol before it reaches anything routable. Treat it as a security device that also moves data, not as a data device that happens to sit on the network.
A sequence that works
Instrument one machine, not one plant. Pick the machine whose failure hurts most and put a sensor and a gateway on it.
Poll it with whatever it speaks, then publish once. Eclipse's own guidance is that Sparkplug complements OPC rather than replacing it, and that brownfield sites use OPC UA polling engines to reach raw process variables. Poll at the edge, publish north.
Decide the retention policy before the second machine. Summaries forever, raw around events, FIFO for the rest. This is the decision that sets your bill.
Terminate the old protocol at the gateway. It is the boundary. Nothing unauthenticated goes past it.
Only then ask what model to run. By that point you will have the thing every predictive maintenance vendor assumed you already had.
The AI is the easy part. It always was. The reason Indian plants are not full of it has nothing to do with models and everything to do with a $275 gateway that nobody was funded to install.
FAQ
Why do I need an IoT retrofit before AI on the factory floor?
Because predictive models need data that brownfield machines do not produce. A machine built in 2004 has no telemetry, and its serial protocol dates to a 1996 specification the Modbus Organization now marks for legacy applications only. Someone must fit a sensor, a gateway and a network path before any model has an input.
What does a basic machine retrofit cost?
Hardware is modest. As of 16 July 2026 an AutomationDirect MB-GATEWAY Modbus gateway lists at $275.00 new or $220.00 remanufactured, and a Banner QM42VT1 vibration and temperature sensor lists at $195.00 through an authorised distributor. These are United States distributor prices, so Indian landed cost adds duty and local distribution.
Should I use OPC UA or MQTT Sparkplug for a brownfield plant?
Both. Eclipse's FAQ states Sparkplug "will not replace OPC but will rather complement it", noting that brownfield sites use OPC UA polling engines to reach raw process variables. The workable pattern is polling the legacy machine locally with whatever it speaks, then publishing once northward over MQTT.
Is Sparkplug B the current version of the specification?
No. Sparkplug B is a payload definition added in revision 2.1 on 10 December 2016, not a specification version. The current specification is Sparkplug 3.0, dated 21 October 2022, which the Eclipse Foundation reorganised and moved to AsciiDoc with explicit normative statements. Ask vendors which version they implement.
Does the Indian government fund Industry 4.0 retrofits for MSMEs?
No. The Ministry of Heavy Industries told the Rajya Sabha on 13 December 2024 that no financial assistance is given to any industry including MSME for adopting Industry 4.0 technologies under the SAMARTH centre initiative. SAMARTH provides four centres, an assessment tool, consultancy and training. The capital is yours.
Can PLI pay for factory sensors and gateways?
Not for the retrofit itself. PLI incentivises incremental production and sales across 14 named sectors, with 764 applications approved and around ₹14,020 crore disbursed as of March 2025. It may reward output that a working retrofit helps you achieve, but nothing in the scheme funds instrumenting a machine.
Why is edge preprocessing necessary for vibration data?
Volume. Vibration sensors often sample above 10 kHz, and ReductStore notes that summarising a 10 kHz chunk can reduce data size "by a factor of 10,000". TDengine illustrates 30 plants with 5,000 sensors at 10 kHz producing roughly 1.5 TB daily. Shipping that raw to a cloud region is not a business case.
What is the security risk of connecting legacy machines?
Base Modbus has no authentication. It assumed a serial cable in a locked cabinet. Modbus Security adds TLS and X.509v3 certificates on port 802, but brownfield machines rarely speak it. So the gateway becomes your control boundary and should be treated as a security device, guided by NIST SP 800-82 Revision 3.
How eCorpIT can help
eCorpIT builds the data layer that factory AI depends on. Our senior engineering teams handle the unglamorous half of smart manufacturing: selecting and fitting sensors to machines that were never designed to be read, terminating legacy protocols safely at a gateway boundary, designing the retention policy that decides your storage bill before it arrives, and getting clean telemetry north over MQTT and Sparkplug into whatever analytics you already run. We work with brownfield plants where the machines are staying, because they usually are. If your Industry 4.0 programme stalled somewhere between a maturity assessment and a working data feed, talk to our team.
References
- Modbus Organization, Modbus specifications
- OPC Foundation, OPC Unified Architecture
- OPC UA Online Reference, specification parts and versions
- OPC Foundation, Field Level Communications Corner, June 2026
- OASIS, MQTT Version 5.0 OASIS Standard, 7 March 2019
- Eclipse Foundation, Sparkplug specification and revision history
- Eclipse Foundation, Sparkplug FAQ
- HiveMQ, Sparkplug Essentials Part 3: Poll/Response, Dominik Obermaier, February 2026
- AutomationDirect, MB-GATEWAY Modbus gateway
- AutomationDirect, STRIDE MQTT gateways
- Powermatic Associates, Banner QM42VT1 vibration and temperature sensor
- TDengine, Managing high-frequency vibration data, Jim Fan
- Control.com, How to efficiently store high-frequency vibration sensor data, Anthony Cavin, ReductStore
- Press Information Bureau, Ministry of Heavy Industries, SAMARTH Udyog Bharat 4.0, 13 December 2024
- Press Information Bureau, Ministry of Commerce and Industry, PLI scheme progress, 22 March 2025
- NIST SP 800-82 Revision 3, Guide to Operational Technology (OT) Security, September 2023
Last updated: 16 July 2026.
Top comments (0)