Industrial Connectivity: A Practical Guide for Manufacturers

A new automotive paint line goes live on a Monday. By Friday, the OEE dashboard has stopped updating during second shift. Production runs fine. The data that proves it does not arrive. The cause turns out to be three legacy PLCs that nobody wired properly into the data layer.

A small story, but not a small problem. While that data is missing, operations has no visibility into line performance, maintenance flies blind into the next shift, and finance reconciles shift productivity by hand. Each of those costs money. Together, they are the reason industrial connectivity has moved off the IT backlog and onto the executive agenda for mid-sized and large manufacturers.

Industrial connectivity is the integration layer that lets machines, sensors, controllers, and IT systems on the factory floor exchange operational data reliably and in a standardised form across vendors and protocols. For industrial enterprises in automotive, aerospace, pharmaceuticals, and consumer goods, it is the basis for real-time decisions, smart manufacturing, predictive maintenance, compliance, and cost control. This guide explains what industrial connectivity is, where projects fail around legacy equipment and the IT/OT divide, and which protocols and technologies matter. It then covers how to evaluate vendors, build the business case, and sequence a deployment that supports Industry 4.0 and IIoT use cases instead of joining the long list of stalled pilots.

What Industrial Connectivity Actually Means

Industrial connectivity is the integration of devices, machinery, and software on the factory floor so that data flows between them in a standardised, usable form. It sits underneath every smart factory initiative, whatever the brochure calls it.

In practice, it links four populations of equipment. Field instruments (sensors, drives, scanners) at the bottom. Controllers (PLCs, DCS, CNC) above them. Supervisory systems (SCADA, HMI, historians) on top of those. Enterprise IT (MES, ERP, analytics, cloud) at the crown. The job of the connectivity layer is to make all four talk to each other without the integration team rewriting the same translator twice.

What separates it from office networking is the environment. The equipment tolerates heat, vibration, dust, and electromagnetic interference, and the data is operational: live process values, alarms, and machine states that drive decisions in seconds, not after a quarterly review.

Why It Is Now on the Board’s Agenda

Three things moved this topic from the automation department to the boardroom.

Digital programmes consistently fail at the connectivity layer. McKinsey’s research with the World Economic Forum’s Global Lighthouse Network found that at least 70% of manufacturers remain stuck in pilot purgatory: digital initiatives that prove themselves in a pilot and never scale across the network. McKinsey’s operations practice calls the underlying cause the last IT/OT mile, noting that a typical medium-sized plant runs over 200 pieces of equipment from different suppliers, each with its own platforms and communication protocols. A predictive maintenance pilot that works with 50 tags stalls at 50,000 tags across three plants. The model is not the problem. The plumbing is. Boards that approved one round of digital investment without seeing returns ask harder questions before approving the next.

The cost of bad connectivity is measurable. The Siemens True Cost of Downtime 2024 report puts unplanned downtime losses at the world’s 500 largest companies at roughly 1.4 trillion dollars a year, or 11% of revenues, up from 8% in 2019. In automotive, an idle line costs up to 2.3 million dollars per hour. ABB’s Value of Reliability survey found two-thirds of industrial companies face unplanned downtime at least monthly, at a typical cost of around 125,000 dollars per hour. A meaningful share of that downtime traces back to data the team needed but did not have in time. A plant that cannot answer „why did yields drop on line 3 last week” without a two-day forensic exercise makes every operational decision slower and more expensive than it needs to be. Plants that answer in minutes shorten MTTR, improve first-pass yield, and free up engineering time for work that compounds.

Customers and regulators are asking. Large automotive and pharmaceutical buyers now require suppliers to demonstrate cybersecurity, traceability, and data-sharing controls. In the EU, regulation adds weight to that trend; we cover what NIS2 means for OT networks separately. Wherever you operate, a plant that cannot show auditable data flows from machine to cloud loses bids it used to win on price.

How Industrial Connectivity Works

Industrial connectivity works by translating proprietary device protocols into a common format through middleware, then handling data transmission to higher-level systems through standardised, vendor-neutral interfaces.

At the field level, devices speak whatever dialect the OEM chose: Modbus TCP, EtherNet/IP, PROFINET, IO-Link, and dozens more. A connectivity platform runs drivers that translate each dialect into a single internal data model, then serves it upward through two vendor-neutral standards: OPC UA for industrial client-server flows, and MQTT with Sparkplug B for publish-subscribe and cloud. The same standardised interfaces let robots, CNC machines, and other automated equipment publish their state data alongside the rest of the line, so downstream systems see one coherent picture instead of a dozen vendor silos.

The result: SCADA, MES, historians, and cloud analytics all consume the same plant data through one integration point, instead of each maintaining its own driver library. That decoupling is the entire economic argument. IT and OT stop fighting over data access and start sharing it.

Protocol	Layer	Typical use
Modbus TCP / RTU	Device	Legacy PLCs, drives, energy meters
EtherNet/IP	Device, controller	Allen-Bradley / Rockwell ecosystems
PROFINET	Device, controller	Siemens and European ecosystems
IO-Link	Sensor	Smart sensors and actuators
OPC UA	Data layer	Vendor-neutral OT/IT exchange
MQTT (Sparkplug B)	IIoT layer	Edge-to-cloud, Unified Namespace

Six protocols cover roughly 90% of a typical factory floor. The first four handle short conversations between controllers and equipment. OPC UA and MQTT carry contextualised data across the OT/IT boundary. Modern architectures use both, with a connectivity platform in the middle doing the translation.

For transport, industrial Ethernet remains the default among networking solutions built for industrial environments, with gigabit links supporting low latency for time-critical applications. Wireless (private 5G, Wi-Fi 6) takes over where cables are impractical, and edge computing closes time-critical loops locally while the cloud handles long-term analytics. Whatever the mix, IIoT solutions must bridge IT and OT while preserving interoperability in harsh conditions: the network has to keep transmitting data reliably through heat, interference, power events, and everything else a plant throws at it.

Why It Is Hard

The hard part is not the wires or the protocols. It is the operational reality.

Legacy equipment. A typical European manufacturer runs production gear from the 1990s. The PLC works, the OEM is gone, the protocol is undocumented. Connectivity platforms earn their keep by carrying drivers for these orphans, so the line stays in service while the data layer modernises around it.

The IT/OT divide. IT optimises for confidentiality and patch cycles. OT optimises for availability and a five-year change freeze. Both are right in their own remit, and both are wrong applying their playbook across the firewall. Successful projects treat this as a coordination problem, not a technology problem.

Harsh environments. A control cabinet in a steel mill runs at 50 °C with interference levels that destroy consumer-grade switches in weeks. A significant share of IIoT projects fail not because the architecture was wrong, but because the network was specified for an office.

Security exposure. Every field device with a network address widens the attack surface, and buyers increasingly audit for it. The era when an air gap counted as a security strategy ended around the time it stopped being real.

The cost of getting this wrong is concrete: downtime, scrapped batches, missed shipments, and lost bids all trace back, more often than people admit, to a connectivity layer that was never properly designed.

What Reliable Connectivity Enables for Digital Transformation

Once data flows reliably, the use cases that justify the investment become possible.

Predictive maintenance turns vibration, temperature, and current readings into early warnings, replacing fixed-interval servicing with condition-based interventions, and stronger data collection from connected assets improves decision making across maintenance and production. The Siemens downtime research credits predictive maintenance adoption with cutting the average large plant’s unplanned downtime from 39 hours a month in 2019 to 27 hours in 2024, which is the main reason total downtime costs have not spiralled even as the cost of each lost hour rose. Real-time production monitoring with OEE gives plant managers a working picture of performance instead of a yesterday-morning report, revealing bottlenecks and supporting faster product changeovers. Process optimisation becomes measurable, because the data that fuels it is consistent across machines and sites.

The same data layer feeds the newer use cases. Digital twins, virtual replicas of physical assets, need real-time connectivity to mirror and simulate performance. Connected energy monitoring cuts utility costs and emissions. Connected vision and sensor systems catch quality drift before it turns into scrap, and connected safety systems can trigger real-time alerts, slowing or stopping automated equipment when people enter a defined zone.

These outcomes are what people mean by Industry 4.0 or the Industrial Internet of Things. The label changes every few years. The requirement does not: a reliable, secure, vendor-neutral way to move data between machines, systems, and the people who make decisions in industrial processes.

Building the Business Case for Industrial Connectivity Solutions

A connectivity business case rests on three numbers your finance team can verify, not on a technology vision.

Your downtime cost per hour. Take a representative line, multiply lost throughput by contribution margin, add idle labour, expedited freight, and any contractual penalties. Most plants that run this exercise properly find the real figure is two to three times what the maintenance report shows, because indirect costs (scrap on restart, yield loss during ramp-up, premium parts) never appear in the downtime log. If your figure lands anywhere near the ABB median of 125,000 dollars per hour, even a modest reduction in incidents pays for the connectivity layer several times over.

Your engineering hours spent moving data by hand. Count the hours your process engineers, maintenance planners, and analysts spend each month exporting, reconciling, and re-keying data between systems. In our deployments, this is routinely the largest hidden line item: a mid-sized plant burning 200 to 400 engineering hours a month on manual data plumbing is common, and those are your most expensive and hardest-to-hire people doing work a middleware licence does for a fraction of the cost.

Your stalled initiative. If a predictive maintenance, quality analytics, or energy programme is already approved and stuck at the data layer, the connectivity investment inherits that programme’s business case. You are not funding new value; you are unblocking value the board already signed off.

Put those three together and the case usually writes itself. What kills connectivity proposals is not weak economics; it is framing the project as infrastructure spend instead of as the unlock for returns the organisation has already committed to.

The Deployment Sequence That Works

Most connectivity failures are sequencing failures. The pattern that works is the same across automotive, FMCG, and pharma, and it runs in six steps.

1. Audit (2-3 weeks). Map what you actually have: every data-producing asset, its protocol, its owner, and where its data currently goes (or does not). This is the step most organisations skip, and it is why their architecture diagrams describe a plant that does not exist. The output is an asset and data-flow inventory, plus a list of unmanaged devices nobody knew were on the network. No production downtime required.

2. Architecture (2-4 weeks). Decide the target pattern before choosing software. For most multi-site manufacturers, that pattern is the Unified Namespace: a single, centralised data layer that acts as the one source of truth for every system, so each producer and consumer of data connects once instead of maintaining point-to-point integrations. Define your naming conventions and data models here, because retrofitting them after 10,000 tags are live is miserable work. Keep the target architecture modular, to avoid vendor lock-in and leave room for future expansion.

3. Platform fit (1-2 weeks). Only now shortlist software, against the audit and the architecture rather than against a vendor demo. The section below covers how the main platforms differ.

4. Pilot (4-8 weeks). One line or one cell, but designed as a slice of the target architecture, not as a throwaway. The pilot must prove the naming conventions, the security model, and the handover to whichever team will operate it, because those are the three things that break at scale. A pilot that only proves „data can move” proves nothing you did not already know.

5. Scale (per site, 6-12 weeks each). Roll out site by site using the templates the pilot validated. This is where the earlier discipline pays: with conventions and models fixed, each additional site is configuration work, not design work, and remote configuration becomes a practical way to deploy and manage devices across sites.

6. Governance (permanent). Assign ownership for the namespace, the certificate lifecycle, and change management. Connectivity is not a project that ends; it is a layer that outlives every application built on top of it.

Get the sequence right and operational efficiency improves while internal resources stay focused on value, not rework. Get it wrong (typically by starting at step 3 because a vendor demo was persuasive) and you join the 70% in pilot purgatory.

Eight Questions to Ask a Connectivity Vendor

Before signing anything, put these to the shortlist. The answers separate production-grade platforms from lab-grade ones.

1. Which of the protocols in our audit do you support natively, and which need custom development? Ask for the driver list in writing, not a percentage.
2. What happens at 50,000 tags across three sites? Ask for a reference customer at that scale, not a benchmark slide.
3. How is security handled by default: certificates, encryption, user authentication? „Configurable” is not the same as „on by default”.
4. What does the licensing model do at scale? Per-tag, per-driver, per-server, and subscription models produce wildly different five-year costs; model your target estate, not the pilot.
5. How do you handle our legacy and orphaned equipment? Name the specific 1990s PLCs from your audit and watch the reaction.
6. What is the upgrade and patching story on the OT side? A platform you cannot patch without stopping production will not survive a security audit.
7. Who implements, and who supports it at 2 a.m.? A platform is only as good as the integrator and support chain behind it.
8. What is the exit path? If the answer to „how do we get our data models out” is silence, you are buying lock-in, not connectivity.

Choosing an Industrial Connectivity Platform

The software category behind all of this is industrial connectivity middleware. The market includes Kepware (Velotic), Ignition (Inductive Automation), HighByte, Cogent DataHub, and AVEVA PI System. For mid-to-large manufacturers building a vendor-neutral architecture, two platforms cover most decisions in practice, and they are the two TT PSC implements directly.

Kepware is connectivity middleware in the strictest sense. It translates over 150 industrial protocols into a single data stream and exposes it through OPC UA, MQTT, REST, and direct cloud connectors. It wins when the priority is broad legacy coverage, a production-grade OPC UA server, and a topology that scales from a single-server pilot to multi-site UNS architectures without rewrites.

Ignition takes a wider scope: connectivity plus SCADA, HMI, alarming, and reporting in one platform with unlimited-tag licensing. It wins when the requirement is a single platform for connectivity and visualisation, particularly in greenfield plants or when an ageing SCADA is due for replacement.

The honest answer to „which one” depends on the existing estate. A plant standardised on Allen-Bradley with a clean separation between connectivity and SCADA is usually a Kepware case. A regional FMCG operator consolidating vendors across five sites is usually an Ignition case. Many real estates use both.

TT PSC is a Kepware integrator and authorised reseller within the Velotic partner programme, and an Inductive Automation Gold tier integrator. We implement both platforms across automotive, FMCG, pharmaceutical, and discrete manufacturing in the UK, DACH, Nordics, Benelux, France, and Poland. The recommendation a customer gets from us is grounded in fit for the estate, not in licensing margin.

Where to Start

Industrial connectivity is where most digital transformation programmes either succeed or stall, and the difference is rarely the platform. It is the sequence: audit, architecture, platform fit, pilot, scale, governance. TT PSC works with manufacturers across that whole sequence as a consulting partner, not just a reseller.

If your digital or AI initiative has stalled at the data layer, the conversation starts with your current architecture: what you have, what you are trying to connect, and where the bottleneck actually is. If you are scoping a Kepware deployment, our licensing and implementation services cover the full path from sizing to production. And if you operate in the EU and OT security is on your compliance agenda, a free NIS2 readiness check takes ten minutes and tells you where you stand.