Most IIoT pitches skip straight to sensors and dashboards, leaving the network engineering and security work for you to discover later. Here’s what a platform should handle on its own, and the four questions that tell you before you sign.
Introduction
Vendors love to tell you that connecting your machines to the Industrial Internet of Things (IIoT), improves OEE. Fewer explain what your team actually has to do to make that happen, or how much of it a competent platform should be handling instead of you.
That’s the real question behind an IIoT-based OEE tracking system, and it’s a fair one to ask before you sign anything. Which sensors go where. What happens to the data once it leaves the machine. Whether your team needs to become network engineers to keep it running. This post walks through what connecting a plant floor actually involves, and draws the line between the parts you should expect a platform to own outright and the parts that stay yours regardless of who you buy from.
What actually needs to connect, and whose job that is
Not every signal on a machine matters for OEE. Three things do: whether the machine is running, how fast it’s producing against its rated speed, and how many of those units passed quality. Everything else is a bonus.
Getting those three signals off a machine takes one of a few common approaches: current sensors that read a motor’s power draw without touching the control logic, photoelectric sensors that count units passing a fixed point, or flow meters on continuous processes like a chemical line where there’s no discrete unit to count. Vibration and temperature sensors often go in at the same time for predictive maintenance, since the mounting work overlaps.
None of that needs to become your team’s homework. Here’s the evaluation question that matters more than the sensor catalogue: does your platform’s team select and install this hardware as part of the deployment, or does your maintenance team get handed a parts list and a shrug? A platform built for manufacturers, not IT departments, should be doing the sensor selection with you based on what your machines already report and what’s missing, not handing you a shopping list and calling it a rollout.
Watch for this specifically during a sales process. A vendor who walks your floor, looks at what your PLCs already expose, and comes back with a short list of gaps to fill is doing the job properly. A vendor who sends a generic bill of materials before ever seeing your lines is asking you to do their engineering for them.
Edge computing: the layer that decides whether this actually works
A gateway sits between the sensors and the network, and how well it’s built determines whether your OEE data is reliable or a source of gaps.
It has to aggregate signals from many sensors into one stream, translate between protocols since older machines rarely speak the same language as new sensors, filter out noise so a half-second blip doesn’t register as a stoppage, and buffer data locally when the network drops. That last point matters more on a plant floor than an office network, where connectivity is far less reliable and every dropped connection is a potential gap in your OEE record if the gateway can’t hold data through it.
This is engineering your team shouldn’t need to do from scratch. It’s the difference between a platform and a science project. When you’re comparing options, ask directly: what happens to my data during a network outage. If the answer is vague, that’s the gap that will eventually cost you a shift’s worth of clean data.
Getting the data off the floor reliably is one problem. What you do with it once it reaches a dashboard, how it’s classified, what surfaces as a root cause versus a raw downtime code, is a different problem, and one we’ve covered in detail separately.
Protocols: a detail that shouldn't become your problem
OPC-UA and MQTT are the common languages between plant equipment and IIoT platforms today, with older machines often running Modbus, needing a translation step somewhere in the chain.
You don’t need to become fluent in any of this. A platform that handles connectivity properly absorbs the protocol differences at the gateway, so a mixed fleet of old and new equipment connects without you standardising everything first. If a vendor’s answer to “we have older Modbus equipment” is that you’ll need to upgrade it first, that’s worth noting as a limitation of their platform, not a limitation of your plant.
Securing the connection, and who's accountable for it
Connecting a plant floor raises a question manual logging never did: what else can reach that network once it’s connected?
The standard approach is network segmentation. Sensors and gateways sit on their own network, separated from both the corporate IT network and the machine’s control network, with data flowing one direction only, from the floor up to the platform. The platform should never be able to write commands back to a PLC’s control logic. That’s a safety boundary as much as a security one, and it’s non-negotiable regardless of which vendor you choose.
This is exactly the kind of question to press a vendor on before signing anything, not after. Ask whether their gateway can ever accept inbound commands from the cloud, or only ever sends. Ask who owns the security posture once it’s deployed, your team or theirs. The right answer keeps that responsibility with the platform provider, not buried in a manual your IT team has to maintain on top of everything else they do.
What a rollout should look like from your side
The instinct is to connect everything at once. Don’t, and don’t let a vendor talk you into it either. A full-plant instrumentation project takes months to show results, and most steering committees lose patience before month three.
A properly scoped rollout starts with your constraint line, the one limiting total output, gets real numbers flowing there, and expands once that line has produced a visible result. From your side, that should look like a short deployment on one line, not a lengthy IT project. If a vendor’s proposal for line one looks like a multi-month integration effort, the connectivity layer isn’t as solved as they’re claiming.
Push on the timeline specifically. A platform that owns its own sensor selection, gateway configuration and security architecture can usually connect a first line and start surfacing clean data within weeks. A project that’s still scoping requirements three months in almost always means the vendor is discovering, on your line, work they should have already solved as a standard part of the product.
On what this actually costs your team’s time: with the sensor selection, gateway configuration and security setup handled by the platform, your part is mostly deciding which line goes first and agreeing on how the data gets defined. The engineering work underneath shouldn’t be sitting on your plate. If MES integration is on your longer-term roadmap, this same connectivity layer is what makes that step straightforward later, since the gateway data feeding OEE can feed an MES once you’re ready to add one.
Does this lead to a digital twin?
Eventually, and the order matters. A digital twin is a live virtual model of a machine or line, built on the same sensor data an OEE deployment already captures. Most Industry 4.0 conversations start with the twin and work backward, which gets the sequence wrong. A faithful model needs a reliable, contextualised data stream first, and that stream is exactly what an IIoT OEE deployment produces along the way.
So an OEE rollout isn’t a detour before the more advanced work. It builds the foundation that work needs, and the connectivity layer you’re evaluating now is the same layer a future digital twin would run on.
How OmniOEE handles the connectivity layer
The sensor selection, the gateway configuration, the security architecture, all of it comes as part of the deployment rather than as a separate project your maintenance and IT teams have to run in parallel. A chemical manufacturer running this setup saw actual production climb 20% and performance efficiency rise by the same margin, gains that came from finally seeing losses their previous instrumentation had never surfaced, without adding a connectivity team to find them.
The platform scales across assets, lines and sites on a cloud-native, no-CAPEX SaaS model, which tends to matter more to whoever signs the deal than any protocol detail.
What to ask before you commit
Whichever platform you’re evaluating, four questions cut through most of the marketing: who selects and installs the sensors, what happens to data during a network outage, can the gateway ever receive commands from the cloud or only send, and what does a first-line rollout actually require from your team’s time. If a vendor answers all four clearly and quickly, the connectivity layer is solved. If they can’t, you’re about to inherit a project you didn’t sign up for.
If you want straight answers to those four questions for your specific lines, book a demo of OmniOEE and we’ll walk through exactly what connecting them would involve.