Manufacturing software is defined by the boundary between OT, the control systems that move machinery, and IT, where your code usually lives. Crossing that boundary safely is most of the job.
Steady demand21 min readControls engineer, MES engineer, Industrial data engineer, IIoT platform engineer, OT security engineer, Reliability engineerUpdated 2026-07-27
Assumes you know: Time-series data handling and basic statistics, Networking fundamentals (subnets, firewalls, brokers), Comfort with messaging and pub/sub systems
Overview
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 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.
Subsection
What it is for
Shop-floor Systems
The layered stack from PLC to ERP, and what each layer is authoritative for
OT/IT Integration
How data gets out of the control network without anything getting in
Industrial Protocols
What OPC UA, Modbus and MQTT are each for, and how each fails
Telemetry & Time Series
Storing and querying sensor data that is not shaped like application data
Predictive Maintenance
Anticipating failures, and why these projects fail on data rather than models
Quality & Traceability
Proving what went into a unit, and finding every unit like it
Safety & Availability
The constraints that make a plant unlike any other production environment
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.
Loading diagram…
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.
Protocol
What it is for
Modbus
The lowest common denominator: an old register read/write protocol over serial or TCP, with no security and no self-description, so you need a vendor document to learn that a register holds a temperature. Ubiquitous because it always works.
OPC UA
The modern interoperability standard. It carries an information model, not just values: a browsable address space of typed, named objects, plus authentication, encryption, and both client/server and publish/subscribe modes. Use it when you want a machine to describe itself.
MQTT
A lightweight publish/subscribe transport with a broker in the middle. It says nothing about payload meaning, so industrial users add a convention — commonly Sparkplug — for topics and device state. Use it to get data out over unreliable links.
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.
Loading diagram…
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.
Term
What it means
Tag
One named measurable value, such as a temperature on one vessel
Deadband
The change threshold below which a new value is not recorded
Scan cycle
The fixed loop in which a PLC reads inputs, evaluates logic and writes outputs
Setpoint
The target value a control loop is driving towards
Work order
An instruction to produce a defined quantity of a defined product
Batch
A quantity produced as one run, and the unit most traceability hangs off
Genealogy
The record of which inputs and conditions went into which output
Changeover
The time between one product run and the next, when the line makes nothing
Downtime
Time the line was not producing, classified as planned or unplanned
OEE
Availability times performance times quality, the headline efficiency measure
Takt time
The production rate required to meet demand
Historian
The time-series archive of process values
Asset hierarchy
Site, area, line, cell, machine, component, as a tree everything joins to
SPC
Statistical process control, detecting drift before it produces scrap
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.
Role
Background
What their week is mostly
Controls engineer
Electrical or mechatronics
PLC and SCADA logic, commissioning, line-down response
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.