Manufacturing and Industrial IoT

What this area actually covers

Industrial software is everything between a machine that physically moves and a business that wants to know what the machine did. The defining fact of the domain is a boundary. OT — operational technology — is the equipment and control systems that make things happen in the physical world. IT is the systems that record, plan and analyse. They have different owners, different networks, different risk tolerances and often a low opinion of each other. Your value here is being able to work on both sides of that line without breaking either.

The scope runs from the control layer, through the plant-information layer that captures what control did, to the execution layer deciding what to make next and the analytics above it. What gets wrongly bundled in is consumer IoT: a connected doorbell and a bottling line share the phrase "IoT" and little else, because one can be rebooted and the other cannot. Machine design and robotics research are a separate profession.

Two more things sit just outside the boundary and are worth naming so you can place them. Supply chain and production planning are upstream, deciding what should be made and when, and they belong to the enterprise systems above this stack. Product design and engineering data management are alongside rather than below, describing what the thing is rather than how a plant makes it. You will integrate with both. You will not own either.

The seven areas underneath

The subsections move up the stack and then across it. The first three establish what exists on a plant floor, how you are permitted to reach it, and what language it speaks. The next two are the data engineering that follows once you have a feed. The last two are the outcomes the plant actually wants from you — provable quality and uninterrupted production — and they are where the domain's real constraints live.

Shop-floor Systems

This is the map, and it is the thing to read first because every other subsection assumes it. It covers PLCs and the scan cycle, SCADA and HMI as the supervisory layer, the historian as the archive of process values, and the manufacturing execution system that turns a production plan into work orders and records what was actually made. It also covers where the ERP boundary sits, which is a perennial argument rather than a settled fact. The reason this exists as its own subsection is that the layers are not a rendering of one system in different detail; each layer is authoritative for something different and lies about everything else. Open it for what each layer owns, for the ISA-95 levels people will reference in conversation, and for the difference between a system that controls and a system that records.

OT/IT Integration

The single most consequential design question in the domain is how data leaves the control network, and this subsection is entirely about that. It covers network segmentation into zones with controlled conduits between them, the demilitarised zone between plant and business, the instinct that flows should be outbound or broker-mediated so nothing initiates a connection into the control network, and the reasoning behind the more extreme options such as data diodes. It exists separately because it is where a software engineer's ordinary habits are most dangerous: polling a device, retrying aggressively, restarting a component to see if that helps. Open it for the safe extraction patterns, for how to negotiate access with a controls team that has every reason to refuse, and for the framing of zones and conduits that IEC 62443 formalises.

Industrial Protocols

Three names recur constantly and each solves a different problem. This subsection covers Modbus as the ancient lowest common denominator, OPC UA as the modern self-describing interoperability standard with a real information model and real security, and MQTT as a lightweight publish-subscribe transport that says nothing about meaning and therefore needs a convention layered on top. Underneath them sit deterministic fieldbus protocols such as PROFINET, EtherNet/IP and EtherCAT, which you consume rather than build on. Open it for what each protocol is for rather than its message formats, and for the failure modes — silent register misinterpretation, subscription overload, retained messages that lie about current state after a broker restart.

Telemetry & Time Series

Once data is flowing you have to store and query it, and industrial time series does not behave like application data. This subsection covers high tag counts and the cardinality problems they create, irregular sampling because historians typically record on change with a deadband, downsampling and aggregation that must be time-weighted rather than sample-weighted, retention policies that trade resolution against cost, and edge buffering so that a link outage delays data rather than losing it. It exists as a separate area because the correct query for "the average temperature last hour" is genuinely different here and getting it wrong produces plausible, confident, wrong numbers. Open it for how to model tags and units, and for the store-and-forward patterns that make an unreliable link survivable.

Predictive Maintenance

The headline use case, the most likely to disappoint, and almost never limited by the model. This subsection covers the honest version: where labels come from and why there are so few of them, how to construct a feature window that does not leak the outcome, how to split data by failure event rather than randomly, how to evaluate when the positive class is tiny, and what to do when the sensors were installed for control rather than for diagnosis and do not observe the degrading component at all. It exists separately because the surrounding rhetoric is loud and the practice is quiet. Open it for label archaeology in a maintenance system, for leakage detection, and for the decision of whether prediction is even the right ask.

Quality & Traceability

This is what much of the stack is really for. Genealogy is the record of which materials, machine settings, operators and process conditions went into which unit or batch, and it is what makes a targeted recall possible instead of a total one. This subsection covers batch and serial traceability, forward and backward trace, statistical process control and the control charts that detect a process drifting before it produces scrap, non-conformance handling, and the additional documentation duties that apply in regulated production. It exists separately because traceability is a data-modelling problem with legal teeth: the question "which units contain material from this lot" must be answerable in hours, years later. Open it for how genealogy is modelled and for what a recall drill actually demands of your schema.

Safety & Availability

The last subsection is about the constraints that make a plant unlike any environment you have deployed to before. Safety functions — emergency stops, guard interlocks, overpressure protection — live in dedicated safety systems assessed under functional-safety standards and deliberately separated from ordinary control and from anything you build. Availability is the other half: your deploy can stop a line, the cost per hour of that is a number someone on site can quote from memory, and in a continuous process a stop also scraps in-progress material. This subsection covers change control on a running line, maintenance windows, rollback that has to be genuinely instant, and validation duties in regulated production. Open it before you propose your first deployment schedule.

Where it sits in a real business

At the bottom are sensors and actuators, driven by PLCs (programmable logic controllers): small deterministic computers that run the process on a scan cycle — read inputs, evaluate logic, write outputs — every few milliseconds, forever. They are programmed in the languages standardised by IEC 61131-3, most visibly ladder logic, and a PLC's state, not any database, is the truth about the plant right now.

SCADA (supervisory control and data acquisition) and HMI software give operators a view of those PLCs and a way to issue supervisory commands. A historian is the time-series archive of process values, and it is where most software engineers first touch real plant data. Above it, an MES (manufacturing execution system) turns a production plan into work orders, records which materials and machine settings went into which batch — genealogy, which is what makes a recall possible — and computes measures such as OEE (overall equipment effectiveness: availability times performance times quality). ERP sits above MES with the commercial view: what was ordered, what stock exists, what it cost, what to invoice.

flowchart TD
  A[ERP plans and releases a production order] --> B[MES creates work orders and downloads a recipe]
  B --> C[PLC executes the process on its scan cycle]
  C --> D[Historian archives process values on change]
  C --> E[SCADA shows operators the live state]
  D --> F[MES assembles the batch record and genealogy]
  F --> G[ERP records yield, scrap and cost]
  G --> H[Quality releases or holds the batch]

The arrow worth studying is D to F rather than C to F. The batch record is assembled from an archive that sampled the process, not from the process itself, so the fidelity of your traceability is bounded by the deadband somebody configured on a historian years ago.

Goods move up that stack as records: a material receipt in ERP becomes a work order in MES, becomes a recipe downloaded to a PLC, becomes thousands of historian readings, becomes a batch record that must match a physical pallet. Where those disagree, someone counts things by hand. That reconciliation is the manufacturing equivalent of a settlement break, and a plant's tolerance for it is finite because inventory that exists in the system but not on the floor eventually stops a customer order.

An engineer arriving from web development gets this wrong predictably, assuming the PLC is a service to query, that reads are free and writes reversible, that the network is reliable, and that restarting a component is a safe first debugging step. None of it holds: a write to a PLC register can move an actuator, a poll loop a web backend would call gentle can disturb scan timing, and no staging environment behaves like the plant, because the plant is a physical process with thermal mass, wear and material variation.

Three protocol names recur, and what each is for matters more than its details.

Below these sit deterministic fieldbus protocols such as PROFINET, EtherNet/IP and EtherCAT, running between controllers and drives. You consume that layer's data rather than building on it.

How data actually leaves the plant

The pattern that survives contact with an OT team looks the same almost everywhere, and knowing it before you ask for access changes the conversation entirely.

sequenceDiagram
  participant PLC
  participant Edge as Edge collector in the plant
  participant DMZ as Broker in the DMZ
  participant Cloud as Cloud ingestion
  participant App as Analytics
  PLC-->>Edge: Values read on subscription
  Edge->>Edge: Buffer to local disk
  Edge->>DMZ: Outbound publish only
  DMZ->>Cloud: Forward, still outbound
  Cloud->>App: Stored and queryable
  App-->>Cloud: Requests never reach the plant

Every arrow that touches the plant points outward, and the last line is the whole point: analytics can ask the cloud anything and can ask the plant nothing. If a design requires the cloud to initiate a connection into the control network, it will be refused, and it should be.

The corollary is that anything you want to send to the plant — a setpoint recommendation, a schedule change — travels as data that a plant-side system chooses to fetch and a human or a control program chooses to accept. The habit to take away is that you do not connect to a PLC, you subscribe to something that reads it, and you do not command a plant, you publish an advisory that the plant may collect.

The vocabulary of the first week

Plant conversations move quickly and assume this vocabulary. None of it is difficult, but not having it makes you slow in exactly the meetings where you most need to keep up.

Two of these carry more weight than they look. Downtime classification is a political artefact as much as a technical one, because the category a stop is recorded under determines whose number it damages, and a data pipeline that changes the classification will be noticed within a day. And asset hierarchy is the join key for everything you will ever build here; a plant without a clean one is a plant where every analysis begins by rebuilding it.

Who does this work

Controls engineers write PLC and SCADA logic. They are usually electrical or mechatronics engineers rather than software engineers, they own the consequences when a line stops, and they will reasonably keep your code away from their equipment until you have earned it. Their working style will feel unfamiliar: change is infrequent, tested on the machine, and documented on paper as often as in a repository, and none of that is ignorance — it is a response to the cost of being wrong.

MES engineers configure and extend the execution layer, mostly vendor product work plus integration. Industrial data engineers and IIoT platform engineers build the pipe from plant to cloud and the storage and models at the far end, which is how a software engineer usually enters the domain. OT security engineers own the segmentation and the asset inventory, and their constraint is that they cannot patch their way out of a problem. Around them, process engineers specify what is wanted, quality engineers own the release decision, and maintenance crews and operators live with what you ship.

The pairing that produces most of the good work in this domain is a data engineer and a reliability engineer, because the reliability engineer knows which asset matters, which failure mode is expensive and what the maintenance record actually means, and none of that is inferable from the data alone.

Demand, adoption and how that is changing

Demand is steady and unglamorous, driven by three things that do not go away. Manufacturers keep equipment for decades, so integration work never ends. Regulators and customers keep demanding more traceability. Energy and labour costs keep making one percentage point of efficiency worth a project. The real platform shift of the past decade is that plant data now routinely leaves the plant, because OPC UA and MQTT gave a standard way out and cheap storage made keeping it all plausible.

Two newer pressures are visible in current hiring. Supply-chain disruption made manufacturers care more about knowing precisely where materials came from, which is traceability work with a commercial rather than a regulatory driver. And energy cost made per-machine consumption measurement worth instrumenting in industries that previously metered a whole site, which is a straightforward data engineering job with an unusually clear payback.

Be sceptical of the surrounding rhetoric, though. Pilots heavily outnumber production rollouts, and much "digital transformation" spend ends as a dashboard nobody opens. The constraint is rarely technology; it is that payback must be proven against a capital budget competing with simply buying another machine. When you evaluate an employer in this space, the useful question is how many of their pilots reached a second plant, because scaling from one line to a fleet is where most industrial software dies.

What makes it hard

Start with why you cannot just expose a PLC. Industrial networks are designed in layers, an idea from the Purdue reference architecture carried into ISA-95: field devices and control at the bottom, then supervisory and site operations, then enterprise IT, with a demilitarised zone between plant and business and traffic crossing through controlled conduits rather than directly. The reason is that a PLC has almost no security model — many industrial protocols authenticate nothing, and a controller will faithfully accept a command to stop or change a setpoint from anyone who can reach its port. Nor can it be patched on a Tuesday, because patching means stopping production. So the control goes around the device instead of in it: segmentation, a DMZ, and outbound or broker-mediated flows so nothing initiates a connection into the control network. IEC 62443 formalises this as zones and conduits.

Then the data. Volume is real but easy; shape and meaning are not. Historians typically store on change with a deadband, so your series is irregularly sampled and a long gap means "unchanged", not "missing". Tag names are cryptic and documented in a spreadsheet on somebody's laptop, and the person who wrote the spreadsheet has retired. Units are inconsistent between lines that were commissioned by different integrators. Clocks across controllers, historians and business systems are not necessarily synchronised, which quietly ruins anything that joins on time — and the symptom is not an error, it is a correlation that almost works.

Context is the deeper version of the same problem. A raw tag value is nearly meaningless without knowing which asset it belongs to, which product was running, what the setpoint was and whether the machine was in production, changeover, cleaning or standby at that moment. Building that contextual model — asset hierarchy, states, product runs — is the unglamorous work that decides whether any analytics on top will be worth anything, and it is almost always underestimated at the start of a project.

Predictive maintenance — catching a failure early enough to act — is the headline use case, the most likely to disappoint, and almost never model-limited. Labelled failures barely exist, because a well-run plant is designed not to run assets to failure, so the positive class is nearly empty. The labels you do have come from free-text work orders recording a repair date rather than a fault onset, and often not the failure mode. Sensors were installed for control, not diagnosis, and may not observe the degrading component at all. Product and setpoint changes shift the distribution, so a model trained last quarter describes a different process. And the encouraging early result is usually leakage: a feature that encodes the outcome, or a random split putting readings from one failure event on both sides of the train/test line. So the first weeks belong to data provenance, tag semantics, clock alignment and label archaeology in the maintenance system; a project that opens by choosing a model architecture has already decided how it will fail.

There is also an adoption problem that no amount of accuracy solves. A prediction is only useful if it arrives with enough lead time to schedule an intervention, and if the maintenance planner believes it. A model that flags a bearing four hours before failure has produced an unplanned stop with extra steps; the same model at three weeks is worth a great deal. Ask what the intervention is and how long it takes to schedule before you ask what the model should be.

Finally, availability. Your deploy can stop a line, and the per-hour cost of that is a number someone on site can quote from memory; in a continuous process a stop also scraps in-progress material. So changes go in during planned maintenance windows, sometimes quarterly, and rollback must be genuinely instant. In regulated production — pharmaceutical, food, aerospace, automotive — changes affecting product quality carry validation duties that make a casual patch impossible. Note too the boundary you must not cross: safety functions such as emergency stops, guard interlocks and overpressure protection live in dedicated safety systems assessed under functional-safety standards, deliberately separate from your software. Analytics may advise a human. It does not get a vote on the safety chain.

Why study it

Study it if you want your software to have physical consequences, if you prefer constraints that are real rather than self-imposed, or if you are joining a manufacturer, an industrial vendor or a cloud provider's manufacturing practice. The data engineering is interesting because the data is awkward, and the field is short of people fluent on both sides of the OT/IT line.

That scarcity is the honest career argument. A competent data engineer is not rare; a competent data engineer who can hold a credible conversation with a controls engineer about scan cycles and deadbands, and who will not propose anything that requires opening a port into the control network, is rare enough to be sought out. It takes about a year of exposure to acquire and it does not expire, because the plant equipment will still be there in a decade.

Do not study it if you want fast iteration and frequent releases; the cadence is set by the plant and you cannot argue with it. Do not treat it as a route into mainstream machine learning, because you will spend your time on data quality instead. And if the "Industry 4.0" framing is what appeals rather than the plant itself, the reality is slower and dirtier than the brochure — you will be on a factory floor in safety boots, and the most valuable hour of your week will frequently be one spent watching an operator do their job.

Your first hour

Get plant-shaped data and feel the sharp edges. Run an open-source MQTT broker locally and publish a simulated machine: two or three tags, published only when a value moves beyond a small deadband, with one multi-minute gap and a deliberate clock skew of a few seconds on one tag. Subscribe with a second client and append the messages to a file.

Now answer one question from your own data: what was the mean of tag one during the third minute? You will hit the real problem immediately — with change-based sampling you cannot average the samples, you must weight each value by how long it held.

Samples for TT101 during minute three
  t=120.0s  70.2   held 25.0s
  t=145.0s  70.9   held  5.0s
  t=150.0s  74.1   held 30.0s

Naive mean of samples      = (70.2 + 70.9 + 74.1) / 3        = 71.73
Time-weighted mean         = (70.2*25 + 70.9*5 + 74.1*30)/60 = 72.20

The gap before t=120 means "unchanged", so the value in force at the start
of the minute is the last sample before it, not missing data.

The two numbers differ, they will differ more on real data, and only one of them is the temperature the process was at. Write down what you did about the gap and the skewed tag. That page, plus the file of irregular samples you generated, beats a week of reading, because every industrial dataset you meet later has those properties.

What this is not

It is not consumer IoT at larger scale; the availability and safety constraints make it a different discipline. It is not SCADA — SCADA is one layer, and using it as a synonym for the whole stack marks you as an outsider.

Predictive maintenance is not condition monitoring: condition monitoring reports current state against thresholds, is well established, usually sufficient, and often the honest answer when someone asks for prediction. Nor is a digital twin necessarily a simulation; the phrase is used for anything from a live data model of an asset to a full physics model, so ask which is meant before agreeing to build one.

An MES is not an ERP module, whatever an ERP vendor prefers, and the argument about where the boundary sits is one you will have repeatedly rather than settle. And the air gap most people believe in largely does not exist, which is precisely why segmentation is the discipline that matters.

The PLC is the system of record for what is happening right now. Everything you build is a reader of that truth, arriving late.