What industrial IoT actually is, and how to start

What it actually means

Industrial IoT describes connecting industrial equipment so that what it is doing can be observed, recorded and acted upon. The term covers a great deal of marketing, and underneath it the engineering is straightforward to state: measure something useful, get the measurement somewhere it can be kept, and put the result in front of somebody who can do something about it.

The distinction from consumer connected products is not the technology but the consequences. A consumer device is replaced every few years, tolerates an occasional fault, and lives in a comfortable environment. Industrial equipment runs for a decade or more, sits in heat, vibration, dust and electrical noise, and its failure can stop production or create a hazard. That changes how carefully each decision has to be made, not what the decisions are.

It is also worth saying what it is not. It is not a product you buy, and it is not a platform. It is a set of engineering choices about what to measure and what to do with the result, and the same platform can support an excellent system or a useless one depending on those choices.

How this became practical

Measuring industrial equipment is not new. Plants have had instrumentation, control systems and data historians for decades, and much of what is described as novel would have been recognisable to a process engineer in the 1990s.

What changed is cost and reach. Sensing that once required a cabinet and a specialist now fits on a small board. Processing that needed a plant computer runs on a component costing a few pounds. Connectivity that meant pulling cable can be a radio link. And storage that was constrained enough to require aggressive compression is now cheap enough that the constraint is deciding what is worth keeping rather than what can be afforded.

The practical consequence is that instrumenting a machine has moved from a capital project to an expense that can be justified against a single recurring problem. That is the real shift, and it explains why the same ideas that were uneconomic twenty years ago are now routine.

It also explains a common source of friction. Plants that already have control systems and historians frequently hear proposals that appear to duplicate what they own. Often they partly do. The useful distinction is usually that existing systems were built to run the process, and hold data shaped for that purpose, while the new question is about equipment condition, utilisation or losses that nothing was recording. Establishing what the existing systems already contain, before proposing anything, avoids both duplication and the impression of it.

The five layers

Thinking of a system as five layers makes it obvious where projects go wrong, because the failures cluster at the ends rather than in the middle.

1. Sensing: is the information even in the signal?

Everything rests on this. If the wrong quantity was measured, or the sampling rate missed the phenomenon, or the sensor was mounted somewhere that does not see what matters, no amount of processing recovers it. This is the layer where the most expensive mistakes are made and the one that receives the least attention.

The useful question is not “how do we measure X” but “what observable quantity changes when the thing we care about changes, and which of those is cheapest to observe reliably”. Motor current, for example, is measurable at a panel with a clamp and reveals a surprising amount about what a machine is doing mechanically.

Covered in detail in sensor selection and signal conditioning.

2. The device: will it run for years, unattended?

Whatever collects the measurement has to survive the environment, run without intervention, be powered somehow, and be updatable when something needs fixing. On battery devices the energy budget dominates the design; on mains devices the update path and security do.

See embedded firmware practice, battery life in connected devices, device security and OTA updates, PCB design in practice and EMC and compliance.

3. Connectivity: does it reach, here, within budget?

Getting data off the equipment and out of the building. This is decided by coverage at the actual installation point rather than by a specification comparison, and the recurring cost across a fleet usually exceeds the hardware difference several times over.

See choosing IoT connectivity and, for the protocols inside a plant, OPC UA, MQTT and Modbus.

4. Storage and analysis: can it be kept, queried and trusted?

Data accumulates faster than expected and costs more than expected, usually driven by message count rather than volume. It also has to remain interpretable: a reading without context, units or a known quality indicator is a number nobody can rely on two years later.

See cloud backends and dashboards.

5. Decision: does anyone act, in time?

The layer that determines whether any of the preceding work produced value. An alert that arrives somewhere nobody looks, a dashboard that is demonstrated and never opened, a report circulated and skimmed: all of these represent a system that works technically and achieves nothing.

This is where more programmes fail than at any technical layer, and it is the least discussed.

The vocabulary, briefly

This field has accumulated a large number of terms, several of which mean the same thing and several of which are used loosely enough to obscure rather than clarify. A short orientation.

The two rows at the bottom cause the most confusion in practice, and the distinction is worth holding on to. Condition monitoring needs only a baseline, which you can begin building today. Prediction needs examples of failures developing, recorded against the signals that preceded them, which takes years to accumulate for reliable equipment. A supplier who conflates them is selling something they cannot deliver on the timescale implied.

What people actually use it for

You probably do not need new machines

A persistent misconception is that this requires modern equipment. It rarely does.

Most useful information can be collected from machines already installed, either from a controller they already have or by measuring externally. Vibration, supply current, temperature, acoustic signature and cycle timing are all measurable without opening a machine or altering its control system, and between them they answer a large proportion of the questions operations actually have.

This matters because it changes the economics completely. Retrofitting a few representative machines is an expense that can be justified against a specific problem. Replacing equipment to gain visibility rarely can, and proposing it is how a promising idea becomes a capital project that never happens.

Who actually does this work

A practical question that shapes the approach: does this get built in-house, by a supplier, or some combination.

In-house suits organisations with engineering capacity and a long-term intent, and it has the advantage that the knowledge stays. Its risk is that the work competes with everything else the team is responsible for, and these programmes lose to urgent production problems every time.

A specialist supplier brings experience of the failure modes and can move faster, at the cost of a dependency and a knowledge transfer problem at the end. The mitigation is to be explicit at the start about what will be handed over and in what form.

A platform vendor with integration services is the fastest route to something working and the most constrained afterwards.

A combination is common and frequently sensible: a supplier builds the first installation and establishes the patterns, with your team taking over operation and extension. This works when handover is planned from the beginning rather than negotiated at the end.

Whichever route, one internal person needs to own the programme. Not necessarily to do the engineering, but to hold the objective, decide between competing suggestions, and keep it alive when attention moves elsewhere. Programmes without that person drift regardless of how good the technology is.

What to keep whoever builds it

Independent of who does the work, a few things should end up in your hands rather than a supplier’s: the data itself and a means to export it, documentation of what each measurement means and how each derived figure is calculated, the mapping between devices and assets, and the design rationale for anything unusual. Those are what allow a different supplier, or your own team, to continue the work later.

A supplier who is comfortable providing that is one worth working with. A reluctance to do so is worth understanding before committing.

Who needs to be involved

These programmes cross organisational boundaries more than most engineering projects, and the ones that stall usually stall at a boundary rather than at a technical problem.

• Maintenance will receive the alerts and already knows which machines misbehave. Their scepticism is informed and worth hearing before anything is specified.
• Operations own the schedule that any installation interrupts, and any interface on the floor competes with their actual work.
• Control systems engineering decide whether anything may connect to a controller, and they have usually seen what happens when something unexpected disturbs one.
• Whoever owns the network decides whether new devices may join it. Discovering their requirements after ordering hardware is expensive and entirely avoidable.
• Electrical and safety govern panel access, isolation and permits, which are not negotiable and are better planned than accommodated.
• Finance, ideally having agreed beforehand what evidence would justify the next phase.

The pattern across that list is that everyone is asking a version of the same two questions: what can this break, and can it be undone. A design that answers both plainly is approved faster than one that is technically superior and harder to reason about. Being able to say that the system can be switched off at any moment with no effect on production is the strongest single position available.

The question that changes the conversation

Rather than presenting a technology proposal, the most effective opening we have seen is to ask operations and maintenance a single question: what would you like to know that you cannot see today?

The answers are usually specific, already costed in people’s heads, and quite different from what a technology-led proposal would have addressed. They also come with the people who care about them already engaged, which is most of the organisational battle.

How to start without wasting the budget

The pattern that works is consistent across the programmes we have seen succeed, and it is unglamorous.

• Start from a problem that costs money now. Not from a technology, and not from a general desire for visibility. Name the loss.
• Instrument a few representative machines, chosen to be typical rather than most important, because a pilot on your most critical asset attracts caution that slows everything.
• Collect long enough to know what normal looks like, across the products, shifts and conditions you actually run.
• Route the result to where people already work. Into the maintenance system, not a new inbox.
• Record what was found every time something is investigated. This is the habit that makes everything later possible, and the one most often skipped.
• Review against criteria agreed beforehand, including what would mean stopping. Committing to that in advance is what makes approval easy, because it bounds the downside.

The corresponding list of what not to do is shorter: do not instrument everything at once, do not promise prediction before you have failure history, and do not build a system that connects to nothing.

A worked example from start to finish

An abstract description is less useful than a concrete one, so here is the shape of a programme that works, on a plant with a recurring problem and no existing measurement.

The problem. A packing line stops more than it should. Nobody can say why, because stoppages are resolved by operators and not recorded unless they exceed some duration. The production manager believes it is one machine; the maintenance supervisor believes it is a different one.

The survey. Half a day walking the line establishes what each machine exposes. Three have controllers with a usable interface; four have nothing. Power and network availability is noted at each point, along with where sensors could physically be mounted.

The pilot. Current measurement on all seven machines, giving run state and cycle timing without touching any of them. A small terminal at the line for stoppage reasons, with six options chosen with the operators using their own words. Data from the three modern machines taken from the existing controllers rather than adding sensors.

The collection period. A few weeks covering the products and shifts normally run, before drawing any conclusions. No alerts during this period, because there is no baseline to alert against.

The first findings. Typically: many more brief stoppages than anybody counted, concentrated on a machine neither manager had identified; cycle time varying more by product than the standard rates assume; and a changeover taking substantially longer on one shift than another.

The first action. One of those, chosen because it is fixable without capital expenditure, addressed and measured. This is what establishes that measurement leads to action, which determines whether the reason codes keep being entered.

The review. Against criteria agreed at the start. What did this show that we did not know, what was it worth, and does it justify extending to the rest of the plant.

Notice how little of that is about technology. The engineering is real but routine; the difficulty is in choosing what to measure, getting the floor interface right, and reaching a decision somebody acts on.

Scaling past the pilot

A successful pilot creates a different problem, and the difficulties that appear on scaling are predictable enough to plan for.

• Consistency becomes essential. A pilot installed carefully by an engineer who understood the intent does not automatically generalise to fifty installations fitted by whoever was available. Mounting standards, documented and checked, are what make comparison across machines meaningful.
• Configuration effort grows faster than the estate. Establishing a baseline per machine is straightforward for three assets and substantial for a hundred. Tooling that configures from a template rather than from scratch is what makes a site-wide rollout sustainable.
• Alert volume multiplies. A rate that was comfortable across three machines becomes overwhelming across a hundred, and grouping, prioritisation and suppression of related alerts stop being optional.
• Definitions have to be shared. Two areas computing the same measure differently cannot be compared, and somebody will compare them anyway.
• Somebody has to own it. Thresholds drift, sensors fail, products change and new equipment arrives. Programmes decay quietly when the person who cared about them moves on and nobody inherits it.

The last is the most common cause of a system that was valuable in year one and ignored by year three. An hour a month of deliberate ownership, reviewing what is reporting, what alerted and whether anything is drifting, is usually enough, and its absence is what separates systems that are still trusted from those that are quietly bypassed.

What it costs, honestly

We will not quote figures without seeing an installation, and it is still worth knowing where cost concentrates, because it is not where people expect.

Sensors are usually the smallest element. Integration with existing systems is commonly the largest and least predictable, because it depends on what your systems permit and how well documented they are. Installation labour, including qualified panel work and any production access, is substantial and varies most with site conditions. Ongoing costs for connectivity and storage scale with the fleet and with reporting rate. And the analysis and review effort is the part most often omitted from a budget and the part that determines whether the measurement produces anything.

The corollary: a proposal consisting mostly of hardware cost has probably not accounted for the work that actually makes it useful.

What the data is worth once you have it

Programmes are usually justified on a single application and turn out to be worth more than that, provided the data was collected in a way that allows other questions to be asked.

A plant that instrumented machines to catch bearing failures typically finds it can also answer where production time goes, which assets are under-utilised, how much energy is consumed while nothing is being made, and why one shift differs from another. None of those was the reason for the project, and collectively they are frequently worth more than the failures avoided.

That has a design implication. A system built narrowly around one alert type can be difficult to extend; one built around collecting good data and making it available tends to absorb new questions without redesign. The difference is modest at build time and substantial later, which argues for spending a little more effort on the data model and the integration than the first application strictly requires.

The counterweight is that this can become an excuse to collect everything and decide later, which produces cost without value. The balance we would suggest: collect what the first application needs, at a resolution and with enough context that it remains interpretable, and design the storage and naming so that adding a second application does not mean starting again.

The habit that compounds

One practice matters more than any technical decision for what a programme can eventually do: recording what was found whenever something was investigated. Not just that a machine was repaired, but what was wrong, when, and against which asset.

Sensor data without recorded outcomes is a large quantity of numbers about which little can be concluded. The same data with a history of findings becomes a dataset: this is what the signals looked like before we found a problem, and this is what they looked like when we investigated and found nothing. The second is as valuable as the first.

It is unglamorous, it takes seconds per occurrence if the mechanism is well designed, and it is the difference between a programme that matures over years and one that remains capable of exactly what it did on the day it was commissioned.

Buying a platform, or building something

A question that arrives early and is frequently answered before the requirements are understood.

Platforms are faster to a working system and remove a great deal of undifferentiated work: device management, storage, dashboards and alerting all exist already. For a first deployment, where the real question is whether the data is useful at all, that speed is worth a lot.

What they cost is flexibility and, at scale, money. Per-device pricing that is trivial for fifty units becomes a significant recurring line for five thousand. The data model is the vendor’s, which constrains what you can ask of it. And migrating away later is work that grows with the history you have accumulated.

Building gives control over cost, architecture and data, at the price of doing and operating it yourself.

The pattern we would suggest for most organisations is to start on a platform, because it answers the important question quickly, while keeping your own data model rather than adopting the vendor’s wholesale. That preserves the option to migrate without committing to it. Many systems never need to; the ones that do are glad the option existed.

Two questions worth asking any platform vendor before committing: can we export our data in bulk in a usable form, and what happens to it if we stop paying. The answers determine whether the decision is reversible.

The technical considerations are set out in cloud backends and dashboards.

Where AI fits, and where it does not

Machine learning appears in nearly every conversation about this subject and is necessary in rather fewer of them.

A well-chosen measurement with a threshold set from that machine’s own baseline catches a great deal. It is cheap, explainable to a sceptical engineer in one sentence, and does not degrade quietly when conditions change. For a large share of industrial monitoring, that is the correct answer.

Learned approaches earn their place where the relationship between signals and condition is genuinely complex, or where normal behaviour varies with operating context in ways a fixed threshold cannot follow. Even then, the constraint is almost never the algorithm; it is whether data exists that represents the thing you want to detect.

Covered in AI-enabled IoT development and, for running models on the device itself, edge AI on microcontrollers.

Security, stated plainly

Connecting industrial equipment to anything changes its risk profile, and this deserves a direct treatment rather than a reassuring sentence.

Older equipment was designed on the assumption that physical access was the security boundary. It typically has no authentication to enable, no encryption to configure and no patches available. That is not a fault to be corrected; it is a property to design around.

The protections that carry the weight are architectural. Segmentation between operational and business networks, with one controlled crossing point rather than a flat network. Data flowing outward, with nothing on the outside able to initiate a connection inward. Read-only collection, enforced at the account and network level rather than merely configured. And least privilege, so a collection account can reach exactly what it needs.

Two further points. A monitoring system that only reads cannot disturb a control loop, which removes an entire category of risk and makes approval considerably easier. And where formal frameworks apply, whether sector standards or your own organisation’s, they constrain the architecture rather than decorating it, so they belong in the conversation at the start.

We design with these requirements in view. We are engineers rather than an assessment body, and where formal certification is required that is separate accredited work. The detail is in SCADA and PLC integration and, for the devices themselves, device security and OTA updates.

What to ask any supplier

Including us. These questions separate suppliers who have done this from those who have read about it.

• What will you measure, and why that rather than something else? A specific answer tied to the failures you care about is a good sign; a standard package applied uniformly is not.
• Does anything write to our equipment? The answer should be no, or a precise account of exactly what writes and when.
• What happens when the network drops? Buffering depth and behaviour when it fills should be specified rather than improvised.
• Who owns the data, and how do we export it? Establish this before deployment, not when you want to change supplier.
• What happens if we stop paying? Whether the hardware keeps working locally and whether history remains accessible.
• Can it integrate with the systems we already run? A closed platform creates another island.
• What are you not promising? A supplier willing to state limits is usually more reliable about the things they do promise.

A note on expectations

Marketing in this field promises transformation, and the reality is usually more modest and more durable. A working programme does not remake a plant. It tells you a handful of things you did not know, some of which are worth acting on, and it keeps telling you as conditions change.

That is a genuinely good outcome and it is worth setting the expectation deliberately, because a programme judged against transformation will be considered a disappointment even when it is paying for itself. One judged against specific agreed criteria will be considered a success at a much lower bar, and will survive long enough to compound.

The failures that recur

• Instrumenting everything at once. Large bill, large data volume, no interpretation capacity, slow first result.
• Measuring the wrong thing. Or the right thing too slowly to see it.
• Building an island. A system that measures beautifully and integrates with nothing changes no decision.
• Nuisance alerts early. The fastest way to make a system invisible, and trust does not return easily.
• Promising prediction on day one. It requires failure history that most operations do not have.
• Never recording findings. The dataset never grows, so the programme cannot mature.
• No owner. Thresholds drift, sensors fail, and the system is quietly abandoned when its champion moves on.
• Starting from a platform. The tooling is rarely the constraint.

How we help

We work across all five layers, which is deliberate: the difficult problems in this field usually sit at the boundaries between them, where a sensing decision constrains the power budget, or a connectivity choice constrains what analysis is possible.

• Survey and scoping. What your equipment exposes, what can be sensed externally, and which losses justify instrumentation.
• Hardware and firmware. Sensing, gateways and devices where off-the-shelf equipment does not suit the environment or the interface.
• Connectivity and protocols. Including recovering undocumented register maps from older equipment.
• Backend and dashboards. Storage sized for the real message rate, and views built around the decision.
• Integration. Into the SCADA, historian and maintenance systems you already run.
• Analysis. Baselines and alerting first, learned approaches when the data supports them.

Service pages: industrial IoT, IoT development, legacy machine retrofit and SCADA and PLC integration.

Building a product rather than instrumenting a plant

Much of this article assumes you operate equipment and want to see what it is doing. The other common case is a manufacturer adding connectivity to a product they sell, and the engineering differs in several ways worth naming.

• You do not control the environment. The device will be installed on networks you cannot see, in conditions you did not specify, by people you will never meet. Everything has to tolerate that.
• Volume changes the economics. A few pounds of recurring cost per device per month is trivial for ten units and a serious business decision for ten thousand.
• Support has a duration. Customers increasingly ask how long updates will be provided, and answering requires keeping a build environment, signing capability and people who understand the code, for however long you state.
• Regulation applies to you. A product placed on a market carries obligations that equipment you operate internally does not, covering radio, EMC, safety and increasingly security.
• The data question is commercial. Who owns what the device produces, whether the customer can export it, and what happens if they stop paying are procurement questions as much as architectural ones.
• Field faults are expensive. A defect in a product you shipped is a warranty and reputation problem, not an internal inconvenience, which shifts the balance toward more testing and a reliable update path.

The relevant reading is industrial product development for the wider programme, and idea to working prototype if the product does not exist yet.

Where to read next

This article is deliberately broad. The detail lives in the pieces below, grouped by the layer they address.

• Getting data from equipment you already own: retrofitting legacy machines, SCADA and PLC integration, OPC UA, MQTT and Modbus.
• Connecting it to the systems that run the business: OT/IT integration with MES, ERP and historians.
• Measuring well: sensor selection and signal conditioning.
• Building the device: embedded firmware practice, PCB design in practice, battery life, security and updates, EMC and compliance.
• Getting the data out: choosing IoT connectivity.
• Keeping and using it: cloud backends and dashboards.
• Applications: predictive maintenance, OEE and energy, machine vision, asset tracking and remote monitoring.
• Analysis: AI-enabled IoT, edge AI on microcontrollers.
• Making it pay: product cost reduction.

If you take one thing away

The technology in this field is mature and rarely the constraint. Sensors work, radios work, databases work, and the tooling is good enough that a competent team can assemble a working system.

What separates programmes that produce value from those that produce dashboards is narrower than it looks: measuring something that genuinely carries the information, getting the result to a person who can act while acting is still useful, and recording what was found so the system gets better rather than merely older.

Start with a problem that costs money. Instrument a few machines. Agree in advance what would justify going further and what would mean stopping. That is unglamorous, and it is what works.

Questions we are asked about this

Common questions

What clients ask before starting

What is the difference between IoT and industrial IoT?

Mostly the consequences of failure and the lifespan. Consumer devices are replaced every few years and a fault is an inconvenience. Industrial equipment runs for a decade or more, sits in hostile conditions, and a failure can stop production or create a hazard. That changes the engineering rather than the underlying idea.

Do we need to replace our machines to do this?

Almost never. Most useful data can be collected from equipment already installed, either from a controller it already has or by measuring externally. Retrofitting is the normal case rather than the exception.

Where should we start?

With a problem that costs money now, on a small number of representative machines, for a defined period, with agreed criteria for what would justify extending. Starting with a technology rather than a problem is the most common way these programmes stall.

How long before it is useful?

Measurement and alerting on departures from normal usually become useful within months. Anything requiring accumulated history, such as predicting specific failures, takes considerably longer and depends on recording what was found each time something was investigated.

Is this the same as Industry 4.0?

Industry 4.0 is the broader term for connected, data-driven manufacturing, of which industrial IoT is the part that gets data out of equipment. In practice the terms are used loosely and the engineering work is the same.

What usually goes wrong?

Instrumenting everything at once, measuring something that cannot answer the question, and building a system that connects to nothing. The technical failures are less common than the failure to reach a decision anybody acts on.

Do we need AI?

Often not. A well-chosen measurement with a sensible per-machine threshold catches a great deal, is explainable, and is far easier to trust. Machine learning earns its place where the signal is genuinely complex or normal behaviour varies with conditions.

What does it cost?

The sensors are usually the smallest part. Integration with what you already run, installation labour and the analysis effort dominate, and they depend on your site rather than on any price list. A survey is the honest way to answer this.

Start a conversation

What would you want to know that you cannot see today?

Tell us what the equipment is, what losses or uncertainties cost you most, and what you already measure. That is usually enough to say whether this is worth pursuing.

Leave empty

Your name *

Email address *

Company

Country *

What are you working on? * I agree that iTechGeeks may use these details to respond to my enquiry. Privacy policy. Send enquiry ↗

Prefer email? Write to info@itechgeeks.in