Manufacturing and industrial IoT fundamentals

The bill of materials is the structural recipe for a product, and it is a tree rather than a list — which is the whole reason explosion arithmetic exists.

Order: 250 x PUMP-A200

item                      level  type        qty per parent   total required
------------------------  -----  ----------  --------------  --------------
PUMP-A200                   0    finished           -               250
  HOUSING-SUB               1    assembly           1               250
    CASTING-88              2    purchased          1               250
    GASKET-12               2    purchased          2               500
    BOLT-M8                 2    purchased          6             1,500
  MOTOR-SUB                 1    assembly           1               250
    STATOR-40               2    purchased          1               250
    BEARING-6204            2    purchased          2               500
    BOLT-M8                 2    purchased          4             1,000
  LABEL-KIT                 1    purchased          1               250

BOLT-M8 appears twice:  1,500 + 1,000 = 2,500 required in total

Level zero is the finished item and each level below is what the level above consumes. Explosion is the recursive multiplication down that tree: quantity per parent times the parent's own requirement, all the way to purchased parts. That is the calculation material requirements planning performs, and it is why a single-table BOM design fails — a flat parts list cannot express that a gasket is consumed by a sub-assembly rather than by the pump.

BOLT-M8 is the detail that catches people. A common part appears at several places in the tree, so the requirement is a sum across branches rather than a lookup, and any query written as a join to one parent under-orders. The same applies to a sub-assembly that is also sold as a spare: it is both a level 1 component and a level 0 finished good, so the item master and the structure must be separate tables joined by a parent/child edge.

Two modelling consequences follow. The structure is effectively versioned, because engineering changes the BOM and a work order released last week must explode against the revision in force when it was released, not today's. And scrap allowance belongs on the edge, not the item: if welding loses 3% of castings, the requirement is 258 rather than 250, and storing that factor per item makes it wrong for every other product using the same casting.

A routing is the process half of the product definition: the ordered sequence of operations that turns the bill of materials into the finished item, each operation naming where it happens, how long it takes, and what setup it needs. A work centre is that where — a machine, a cell, a bench, or a group of interchangeable ones — carrying a capacity and a cost rate. The pairing matters because the BOM tells you what to buy and the routing tells you what to schedule, so capacity planning is entirely a routing question. The detail engineers miss is that operation time splits into setup time, which is per order, and run time, which is per unit; conflating them makes small orders look cheap and destroys every scheduling estimate. Routings are also versioned alongside the BOM, because moving an operation to a different machine changes both cost and capability.

An authorisation and a container: permission to consume defined materials and plant time to produce a defined quantity of a defined item, and the record of what actually happened while doing it. It is the central transaction of the domain in the way an order is in commerce, and almost every other manufacturing record hangs off it — material issues, labour bookings, machine data, quality results, scrap, genealogy. Its lifecycle is worth knowing by name: planned, released, in progress, completed, closed. The engineering consequence is that quantities are never a single number. A work order has an ordered quantity, a confirmed good quantity, a scrap quantity and a remaining quantity, and they disagree constantly. A schema with one quantity column on a work order is a schema that cannot answer whether the order is finished.

The same three words are used to describe production and they imply three different schemas, so the first question about any plant is which one it is.

                    discrete              batch                  continuous
------------------  --------------------  ---------------------  --------------------
unit produced       a countable item      a quantity made in     a flow, measured in
                                          one run                mass or volume
identity            serial number         lot or batch number    a time interval
recipe              quantity per unit     formula with a scale   ratios and setpoints
                                          factor
process definition  operations at work    phases and steps in    control loops
                    centres               equipment units
traceability key    serial -> component   batch -> input lots     timestamp -> lot
                    serials                                       assigned at packing
yield accounting    good units, scrap     yield per batch,        rate, and hours
                                          partial batches         spent off-specification
cost of a stop      WIP waits in queue    in-progress material    material is scrapped
                                          may be salvageable      and restart takes hours
example             pumps, cars, boards   paint, tablets, beer    steel, paper, refining

Read the identity row first, because it decides everything downstream. Discrete production can carry a serial per unit, so traceability is a graph of individual things and a recall can name exact units. Batch production cannot: the smallest identifiable thing is a run, so a defect means the whole lot is suspect. In continuous production even a lot is a fiction — it is a time window somebody assigned at the packing line, and the boundary is approximate by nature.

The cost-of-a-stop row is why deployment practice differs so sharply. Stopping a discrete line queues work; stopping a continuous process destroys in-progress material and buys hours of restart, which is the concrete reason a maintenance window in a refinery is quarterly and in an assembly plant may be nightly.

Most real plants are hybrids, and that is the trap. A pharmaceutical site makes tablets in batches and then packs them into serialised cartons, so the model must carry a batch-to-serial transition and the traceability query crosses it. Asking "where does batch identity become serial identity?" is a question that only someone who has built this asks.

A tree of physical things — enterprise, site, area, line, cell, machine, component — that gives every tag, event, work order and maintenance record a place to hang. It is the join key of the domain, in the way a customer identifier is in a commercial system, and its quality determines whether any analysis is possible. Without it you cannot answer "what was the output of line 2 last Tuesday", because the sensors know their own names and nothing else. The failure mode is that plants commissioned by different integrators over twenty years each invented their own naming, so the same machine class is FIL-02, Filler2 and L2-FLR in three systems and there is no key linking them. Building and owning that hierarchy is usually the largest unbudgeted task in an industrial data project, and it is not a lookup table — it changes as equipment moves.

Material that has been released to production and is neither raw stock nor finished goods: partly built units sitting in queues, in machines, or waiting for inspection. It matters commercially because it is capital tied up in something unsellable, and operationally because queue length is what turns a fast line into a slow lead time. It is hard to measure because it exists physically before it exists in any system: a unit is only recorded as having moved when someone books an operation, and bookings happen at the end of a shift, in batches, sometimes wrongly. So system WIP lags floor WIP, and the discrepancy is discovered at a stock count. Little's law is the useful framing — WIP equals throughput times lead time — because it shows that halving WIP at constant throughput halves lead time, which is why reducing it is a strategy rather than an accounting tidy-up.

Scrap is material that failed and cannot be recovered, so it is written off and the work order needs more input to hit its quantity. Rework is material that failed and can be corrected by additional operations, so it is recovered at the cost of unplanned labour and time. The distinction matters more than it sounds because they behave differently in every system: scrap consumes material and produces nothing, while rework consumes capacity that was not in the schedule and therefore silently steals it from other orders. Rework is also the standard place quality metrics are gamed, since a unit reworked into conformance counts as good at the end of the line while having failed in the middle. That is precisely what first pass yield exists to expose, and why a plant reporting high final yield and no first pass yield is telling you something.

The pyramid is not one system drawn at different zoom levels — each layer has its own software, its own owner, and a timescale that rules out the layer above it.

flowchart TD
    L0[Level 0<br/>Sensors, actuators, drives<br/>microseconds, physical] --> L1[Level 1<br/>PLC and safety logic<br/>scan cycle 1 to 50 ms, deterministic]
    L1 --> L2[Level 2<br/>SCADA and HMI<br/>sub-second refresh, supervisory]
    L2 --> L3[Level 3<br/>MES, historian, batch<br/>seconds to minutes, per site]
    L3 --> L4[Level 4<br/>ERP and planning<br/>hours to days, per enterprise]
    L1 -.-> H[Historian records on change<br/>with a deadband, not every scan]

The latency column is the argument. A PLC must complete its scan within a fixed budget every cycle forever, so nothing that can pause — a garbage collector, a network retry, a database query — belongs in it. That single requirement is why control logic is not written in the languages you know, and why "just call our API from the PLC" is not a proposal a controls engineer can accept.

Each level is authoritative for something and unreliable about everything else. Level 1 is the truth about the process right now. Level 3 is the truth about what was made and from what. Level 4 is the truth about what was ordered and what it cost. When two levels disagree about how many units exist, the answer is not that one is broken; it is that they are measuring at different moments with different definitions.

The dotted arrow is the detail that decides data quality. The historian does not archive every scan — it stores a value when it moves beyond a configured deadband — so the series you analyse is a lossy, irregularly sampled projection of the process, and its fidelity was fixed by somebody's configuration choice years ago. Every analysis you build inherits that choice.

ISA-95 also gives the vocabulary for the interface between levels 3 and 4: production schedule down, production performance up. Knowing that those are named message types rather than an integration you invent is worth saying, because it is how MES and ERP vendors actually describe their boundary.

It runs a fixed loop — read all inputs, evaluate the logic, write all outputs — within a guaranteed time budget, typically a few milliseconds, and it does that forever without stopping. That determinism is the entire point: a machine guard must be evaluated on a predictable schedule, not when a scheduler gets around to it. It is programmed in the IEC 61131-3 languages, most visibly ladder logic, and its memory is a flat map of addressed registers rather than objects. Two consequences matter to a software engineer. Its current state, not any database, is the truth about the plant at this instant, so everything you build is a reader of that truth arriving late. And a write to a register can move an actuator, so there is no such thing as a harmless test call against a live controller.

SCADA is the supervisory layer: it collects values from many controllers, presents them to operators through HMI screens, raises and manages alarms, and lets a human issue setpoint changes and start or stop commands. It supervises rather than controls, which is the distinction to hold — the PLC closes the control loops, and SCADA can be down while the process continues running correctly. What it does not do is keep history in any usable form. SCADA typically holds a short buffer for trending, so it is the wrong place to ask for last quarter's temperatures, and that is what a historian exists for. It is also not the whole stack, despite being used as shorthand for it; treating SCADA as a synonym for industrial software is one of the faster ways to sound like an outsider in a plant meeting.

It is a time-series archive specialised for process values, and the differences from a general database are substantive rather than branding. It stores on change with a deadband rather than at a fixed interval, so a flat signal costs almost nothing and the series is irregularly sampled by design. It carries a quality flag per value — good, uncertain, substituted, stale — which most application developers ignore and then average bad data into their results. Its aggregation functions are time-weighted, because with change-based sampling the mean of the samples is not the mean of the process. And it is expected to serve a query spanning ten years alongside a live trend. The consequence for your code is that a gap in the data means "unchanged", not "missing", and treating it as missing produces plausible, confident, wrong numbers.

An MES owns execution: turning a released production order into work orders and operations, dispatching them to specific equipment, downloading recipes or parameters, collecting what was actually produced and consumed, and assembling the genealogy record for each batch or serial. It works in units of minutes and machines. An ERP owns the commercial view — demand, materials planning, inventory, costing, invoicing — in units of hours and sites. The boundary is genuinely contested rather than settled, because ERP vendors sell shop-floor modules and MES vendors sell planning, so expect to have the argument rather than resolve it. The practical test is where the answer lives when the floor deviates from the plan: if the system that knows a machine broke and the order was resequenced is the MES, the MES owns execution regardless of what the licence says.

A physical quantity becomes a signal at a sensor, a value in a PLC register on the next scan, a subscribed update in SCADA or an edge collector, a stored point in a historian, a contextualised measurement joined to an asset and a product run, an aggregate in a warehouse, and finally a number on a management report. Each hop adds latency and loses fidelity, and exactly one hop adds meaning: the contextualisation step where a raw tag value acquires which machine it came from, which product was running, what the setpoint was, and whether the machine was in production, changeover or cleaning. That step is the unglamorous work that decides whether anything above it is worth reading, and it is almost always underestimated. A dashboard built on uncontextualised tags will average production and cleaning together and report a temperature nothing was ever at.

Because the consequence of failure is different in kind. IT security is conventionally ordered confidentiality, integrity, availability: the worst outcome is data leaking. OT inverts it to availability, integrity, confidentiality, and adds safety above all of them, because the worst outcome is a process stopping uncontrolled or a person being hurt. Determinism sits alongside availability as a hard requirement, since a control loop that responds late is a control loop that has failed. That inversion explains behaviour that looks negligent from an IT desk. Unpatched controllers, shared operator accounts, unencrypted protocols and twenty-year-old Windows machines are not oversights; they are the outcome of a rule that says nothing may risk stopping the line. The correct response is not to argue the ranking but to design around it: controls that go around the device rather than into it.

A register read/write protocol from 1979, running over serial or TCP, with a trivially simple message format: function code, address, count. It has no security, no authentication and — the part that costs you — no self-description. A register holds a sixteen-bit number and nothing in the protocol says whether that is a temperature in tenths of a degree Celsius, a scaled pressure, or a bitfield of alarm states, so you need a vendor document to interpret it. It survives because it always works and every device speaks it. The specific failure mode to name is silent misinterpretation: read a thirty-two-bit float as two registers in the wrong word order and you get a plausible number rather than an error, and that error can sit in a dataset for months. Legacy siblings such as DNP3 and Profibus behave similarly.

An information model rather than a register map. OPC UA exposes a browsable address space of typed, named objects with units, engineering ranges and relationships, so a client can discover what a machine offers instead of being told by a spreadsheet. It also brings the things Modbus lacks entirely: certificate-based authentication, encryption, per-node access control, structured events and alarms, and a subscription model where the server pushes changes rather than being polled. Later versions add publish-subscribe over MQTT for one-to-many flows. The costs are real and worth stating: it is a substantially heavier stack, certificate management becomes an operational duty nobody budgeted, and subscription tuning matters because an over-eager client asking thousands of nodes for millisecond updates can load a server that was sized for supervision.

MQTT is a lightweight publish-subscribe transport with a broker in the middle. It is excellent at getting data across an unreliable link and says absolutely nothing about what a payload means or how topics should be named, so every implementation invents its own convention and none of them interoperate. Sparkplug is the specification that fills that gap: a defined topic namespace, a defined payload encoding, and — the important part — a state model. Every publisher sends a birth certificate listing its metrics on connect and registers a death certificate the broker publishes if it disappears, so a consumer can tell a stale retained value from a live one. That solves the specific MQTT failure where a broker restart leaves subscribers reading retained messages that describe a machine which has been off for a day.

Polling asks each device for its values on a schedule, which is simple, predictable in load, and gives you a regular series. It also wastes most of its requests on unchanged values, imposes load on controllers that were sized for control rather than for being queried, and cannot see anything that happened between polls — a two-second pressure spike is invisible at a five-second poll. Event-driven collection has the device or server push on change, usually with a deadband, so bandwidth follows activity and transients are captured. Its costs are that load becomes unpredictable, a storm of changing values can overwhelm a subscriber, and your series is now irregular, which changes every aggregation you write. The industrial default is subscription with a deadband plus a slow heartbeat, so silence can be distinguished from a dead link.

A tag is one named measurable value — a single temperature on a single vessel — and it is the atom of industrial data. Naming decides the project because the tag name is usually the only metadata that exists: there is no schema, no foreign key to an asset table, just SITE2_L3_FLR_TT101_PV and a spreadsheet maintained by someone who has retired. If names encode site, area, line, equipment, measurement type and role consistently, you can parse them into an asset hierarchy and build everything on top. If they were invented per line by different integrators, your first six weeks are manual mapping that nobody will fund twice. The lesson to carry is that a naming convention is a data model, and imposing one on new equipment is cheaper than every downstream workaround it prevents.

A single, hierarchically structured, always-current representation of the whole plant, published to a broker, that every system reads from and writes to instead of integrating point-to-point. Instead of forty bespoke connections between systems, each publishes its state into an agreed namespace mirroring the physical hierarchy, and consumers subscribe to the branch they care about. The appeal is the same as event-driven architecture generally: adding a consumer requires no change to producers. What it actually requires is the part usually skipped — somebody must own the namespace as a schema, decide the hierarchy, and enforce naming and units, because a unified namespace without governance is a broker with a lot of inconsistent topics. It is a modelling discipline that happens to have a broker in it.

The plant link fails routinely, and whether that is a delay or a data loss is decided entirely by what the edge collector does next.

sequenceDiagram
    participant P as PLC
    participant E as Edge collector
    participant B as DMZ broker
    participant C as Cloud store
    P-->>E: Values on change, link healthy
    E->>B: Publish, acknowledged, buffer empty
    Note over E,B: Link down for 90 minutes
    E->>E: Persist to local disk, 54,000 messages queued
    E->>B: Reconnect, drain oldest first at a throttled rate
    B->>C: Backlog lands carrying original event timestamps

The fourth line is the whole design. An edge collector that holds its queue in memory loses ninety minutes of production data to a power cycle, and an edge collector that drops on a full buffer loses it silently. Persisting to local disk with a bounded, monitored queue turns an outage into latency, which is the only acceptable outcome when the data feeds a batch record somebody must sign.

The last line carries the detail candidates omit: the backlog must retain the original event timestamps, not be stamped on arrival. Otherwise ninety minutes of process history compresses into the second it was received, and every trend, every time-weighted average and every genealogy record built from it is wrong in a way that looks like a real production anomaly.

Draining needs a throttle, because a fleet of two hundred collectors reconnecting simultaneously after a site-wide network event delivers a thundering herd to ingestion at exactly the moment it is least expected. Rate-limited drain, oldest first, spreads it.

Two operational rules follow. Buffer depth and buffer age are the primary health metrics for a collector fleet, because a collector that is publishing happily and one that is quietly forty minutes behind look identical from the cloud. And consumers must be idempotent, since a reconnect after an unacknowledged publish resends.

Because almost every useful industrial question is a join on time — this vibration reading against that work order, this temperature against that batch phase — and the devices carrying the timestamps do not share a clock. PLCs often have no battery-backed time source and drift; historians stamp on receipt rather than on occurrence; ERP records a shift boundary in local time with its own daylight saving behaviour. Skew of a few seconds is normal and skew of minutes is common on unmanaged equipment. The symptom is the dangerous part: not an error, but a correlation that almost works, so an event appears to precede its own cause and a model learns from an alignment that does not exist. The fixes are unremarkable and must be deliberate — NTP or PTP across the plant, store UTC everywhere, and record both event time and ingestion time so skew is measurable rather than invisible.

Volume in this domain is easy to guess wrong in both directions, so the arithmetic settles whether you need a lakehouse or a single server.

Plant: 4 lines, 60 machines, average 180 tags per machine

  Tags total            60 x 180                           = 10,800
  Fast tags             15% at 10 Hz, vibration and drives = 1,620
  Normal tags           85% on change, ~0.2 Hz average     = 9,180

Samples per second      1,620 x 10 + 9,180 x 0.2           = 18,036/s
Samples per day         18,036 x 86,400                    ~ 1.56 billion
Bytes per sample        tag id, timestamp, value, quality  ~ 24 bytes
Raw per day             1.56e9 x 24                        ~ 37 GB
Raw per year            37 GB x 365                        ~ 13.7 TB
Compressed 8x, replicated 3x                               ~ 5.1 TB/year

Downsampled to 1-minute aggregates, 5 values per tag-minute
  min, max, time-weighted mean, sample count, bad-quality count
  10,800 tags x 1,440 minutes x 5                          = 77.8M rows/day
  at 24 bytes                                              ~ 1.9 GB/day

Retention decision
  raw                 30 days      hot, for incident investigation
  1-minute aggregates 2 years      the layer every dashboard reads
  1-hour aggregates   indefinitely for year-on-year comparison

Thirteen terabytes a year raw is not a big-data problem, which is the first useful conclusion — a single well-chosen time-series store handles this, and proposing a streaming lakehouse for it is over-engineering. The number that actually constrains you is the write rate at 18,000 points per second, because that is sustained and never pauses.

The twenty-fold reduction from downsampling is what makes the analytics layer cheap, and the aggregate list is where the domain knowledge shows. A plain mean is wrong on change-based sampling and must be time-weighted. Min and max must survive, because a specification breach is a peak and averaging destroys exactly the evidence quality needs. And the bad-quality count has to be carried forward, or a downsampled series silently launders sensor faults into confident numbers.

What you must not do is downsample and discard raw immediately. The first serious incident investigation will want the millisecond detail around one machine for one hour, and thirty days of raw is far cheaper than the alternative of not being able to answer.

The volume that genuinely surprises people is vibration. A single accelerometer sampled at 25 kHz for waveform analysis produces more data than the other 10,799 tags combined, which is why that data is normally processed at the edge into features and only the features are shipped.

Material requirements planning takes demand — orders and forecast — explodes it through the bills of materials, subtracts what is already in stock or on order, and offsets each requirement backwards by its lead time to produce a plan of what to buy and make and when. It is arithmetic rather than optimisation, and it has been the backbone of manufacturing planning for fifty years because the arithmetic is genuinely useful. Its assumptions are where it breaks: that lead times are fixed constants, that capacity is infinite, that inventory records are accurate, and that the BOM matches what the floor actually builds. Each is false to some degree, which is why MRP output is a proposal a planner edits rather than a schedule. Nervousness is the specific pathology — a small demand change reshuffles hundreds of downstream orders, so plans are frozen inside a horizon.

Finite capacity scheduling takes the orders MRP proposed and sequences them against real constraints — machine availability, changeover matrices, tooling, labour, shift patterns — to produce a sequence with times rather than a list with due dates. It is a genuinely hard combinatorial problem and the output is usually better than a human's on any measure you can define. The floor overrides it because the model is always a little behind reality: a machine developed a fault, a material arrived out of specification, the operator who can run that cell is off, the customer telephoned. A scheduler whose plan cannot be edited will be ignored entirely, so the design requirement is fast, cheap rescheduling and a record of the deviation. The engineering lesson is that the schedule is advice with a timestamp, and your data model must record what was planned and what happened as separate facts.

Takt time is demand-derived: available production time divided by the number of units the customer wants, so it is the rhythm the line must achieve to keep up. Cycle time is capability-derived: how long a station or the line actually takes per unit. The comparison is the whole point. If cycle time exceeds takt time you cannot meet demand however hard everyone works, and the answer is capacity or process change rather than exhortation. If cycle time is well below takt you have spare capacity, which is either waste or useful buffer depending on how variable demand is. The confusion to avoid is between station cycle time and line cycle time: the line's is set by its slowest station, not the average, which is why averaging station times to estimate output is always optimistic.

Throughput is the rate of good units leaving the whole process, and it is governed by the slowest step plus the variability around it, not by the sum or average of the stations. That is unintuitive because each station in isolation genuinely can run faster, and a spreadsheet adding capacities will promise output the line has never achieved. Variability makes it worse than the bottleneck alone suggests: a station that occasionally stops starves everything downstream and blocks everything upstream, so a line of five stations each 95% available is nowhere near 95% available itself unless buffers absorb the interruptions. The practical consequences are that buffers before and after the constraint are deliberate design rather than untidiness, and that measuring throughput as good units — not units — is what keeps quality problems from being reported as success.

Five stations in sequence, one piece flowing through all of them, and a capital request that would change nothing.

station     cycle time   utilisation at the line's actual rate
---------   ----------   -------------------------------------
S1 cut          38 s                63%
S2 weld         42 s                70%
S3 test         60 s               100%   <- the constraint
S4 paint        45 s                75%
S5 pack         35 s                58%

Line output = 3,600 / 60 = 60 units/hour, set by S3 alone.
Sum of station capacities would suggest 3,600/44 avg = 82/hour. It never has.

Improvement A: replace the cutter, S1 38 s -> 24 s, cost £180,000
  Line output = 60 units/hour.  Unchanged.
  WIP now accumulates in front of S2, which is unchanged at 42 s.
  The buffer in front of S3 is untouched, because S2 still gates it.
  S1 utilisation falls to 40%, which looks like a worse machine.

Improvement B: add a second test fixture, S3 60 s -> 30 s effective, cost £45,000
  New constraint is S4 paint at 45 s.
  Line output = 3,600 / 45 = 80 units/hour, up 33%.

Improvement A is the classic error and it is not a stupid one — S1 was the oldest machine, its operator complained about it, and its cycle time genuinely improved. It bought nothing because an hour gained at a non-constraint is an hour of extra waiting, which is the sharpest sentence in the theory of constraints.

The utilisation column is the trap that produces A. Managers who reward high utilisation per station will push S1 and S5 to run flat out, which produces WIP rather than output and makes the plant slower and more expensive at once. Only the constraint should be run to exhaustion.

Notice that B moved the constraint rather than removing it. That is always what happens, and the useful discipline is to identify where it lands next before spending: doubling the test station again would achieve nothing until paint is addressed. Naming the next constraint unprompted is what distinguishes someone who has done this.

The data engineering consequence is that finding the constraint from data is a question about queues, not cycle times. Cycle times come from a routing that may be years out of date; the station whose input buffer is always full and whose output buffer is always empty is the constraint, and buffer occupancy is observable from machine data.

A management method with one claim: every system has a constraint that determines its output, so improvement anywhere else is illusory. Its five steps are worth knowing by name — identify the constraint, exploit it fully, subordinate everything else to it, elevate it with investment, and then repeat because the constraint has moved. In practice it produces specific and slightly counter-intuitive behaviour: keep buffers in front of the constraint so it never starves, do not measure non-constraint stations on utilisation, and schedule the whole line from the constraint outwards rather than from the first station. The reason it appears in software interviews at all is that the same logic governs pipelines and services, and a candidate who optimises a component with 60% utilisation while the database saturates is making exactly the mistake it warns against.

Changeover is the time between finishing one product and running the next at full rate: physical retooling, cleaning, purging, first-article inspection and whatever it takes to get the process back in specification. During it the line makes nothing sellable. It sets batch sizes through a direct trade: long changeovers make long runs economic, because setup cost is amortised over the batch, and long runs mean more finished stock, longer lead times and less responsiveness. Halving changeover time therefore halves the economic batch size, which is why setup reduction is the standard lever for making a plant more flexible without buying capacity. The classification detail matters to your data too: changeover is usually recorded as planned downtime and thus excluded from OEE's availability, so a plant with terrible changeovers can post respectable numbers.

One shift on one machine, with each factor derived rather than asserted.

Shift: 8 hours = 480 minutes of scheduled time
  Planned downtime      30 min breaks and changeover  -> 450 min planned
  Unplanned stops       38 min breakdowns and jams    -> 412 min running

Availability  = 412 / 450                                     = 91.6%

Ideal cycle time 30 s per unit, so 2 units per minute
  Theoretical output in 412 running minutes = 824 units
  Actual total output                       = 700 units
Performance   = 700 / 824                                     = 84.9%

Of 700 produced, 21 were scrapped, 679 good
Quality       = 679 / 700                                     = 97.0%

OEE = 0.916 x 0.849 x 0.970                                   = 75.4%

Seventy-five per cent is a good number for a real machine, and on its own it is almost useless. The three factors have completely different remedies — availability is a maintenance and changeover problem, performance is minor stops and slow running, quality is a process capability problem — so a single figure tells you nothing about what to do. Always report the triple.

The largest thing it hides is in the denominator. Availability is measured against planned production time, so every minute someone classifies as planned downtime disappears from the calculation. Reclassifying a changeover from unplanned to planned improves OEE without changing anything physical, which is why downtime classification is a political artefact and why a pipeline that changes it will be noticed within a day.

Performance hides a chosen constant. Ideal cycle time is a number somebody recorded, often the machine's nameplate rate, often for a different product. If the true best cycle is 34 seconds, performance is really 96% and the improvement effort is being aimed at the wrong factor.

And OEE says nothing about whether the output was wanted. A machine running flat out building inventory nobody ordered scores near 100% while making the business worse, which is why OEE belongs on the constraint and nowhere else. Applying it to every station is how you get the utilisation pathology that produces WIP instead of throughput.

First pass yield is the proportion of units that pass every step correctly the first time, with no rework, no re-test and no adjustment. Final yield counts what eventually left the line as good, so it includes everything that failed and was recovered. The gap between them is the hidden factory: real labour, real capacity, real cost, invisible in the headline number. A line reporting 99% final yield and 82% first pass yield is spending a fifth of its effort fixing its own output, and the difference is where improvement money should go. The measure compounds across steps, which is what makes it uncomfortable — five sequential operations each at 97% first pass gives about 86% overall — and that arithmetic is the argument for reducing step count rather than tuning each step.

A method for distinguishing the ordinary random variation a stable process always shows from a real change worth investigating. You sample the process, plot a statistic over time on a control chart, and compute control limits from the process's own short-term variation, conventionally three standard deviations from the centre. A point outside those limits, or a pattern such as eight consecutive points on one side of the centre line — the Western Electric run rule, where Nelson and ISO 7870-2 use nine — or a steady trend, is evidence that something changed. What it detects is instability, not badness, and that is the distinction candidates miss: SPC tells you whether the process is behaving predictably, and says nothing on its own about whether it is producing acceptable parts. Its value is lead time — it catches drift while parts are still good, which is the only point at which intervention is cheap.

Control limits come from the process and specification limits come from the customer, and the four combinations are why they must never be drawn on the same axis casually.

Bottle fill. Specification 500 ml +/- 5, so LSL 495 and USL 505.
Twenty-five subgroups of 5 measurements, X-bar chart.

Case A: in control, out of specification
  process mean                  502.8 ml
  within-subgroup sigma           1.9 ml
  control limits, n = 5   502.8 +/- 3 x 1.9 / sqrt 5   = 500.3 to 505.3
  natural spread of units 502.8 +/- 3 x 1.9            = 497.1 to 508.5
  chart verdict   every point inside the limits, no rule violated, stable
  reality         about 12% of individual bottles exceed the 505 ml USL

Case B: out of control, in specification
  established centre line       500.0 ml
  within-subgroup sigma           0.8 ml
  control limits, n = 5   500.0 +/- 3 x 0.8 / sqrt 5   = 498.9 to 501.1
  mean drifts 500.2 -> 500.6 -> 500.9 across eight subgroups,
    every one above the centre line and inside the control limits
  chart verdict   eight consecutive points above the centre line, rule violated
  natural spread  500.9 +/- 3 x 0.8                    = 498.5 to 503.3
  reality         nothing is out of specification yet, and the drift continues

Case A is the more dangerous of the two and the one that catches engineers who have just learned control charts. The process is perfectly stable — it is reliably making the wrong thing. No control rule will ever fire, because control limits describe what this process does, and this process consistently overfills. The fix is to move the mean or reduce variation, and it is a capability question answered by an index such as Cp or Cpk, not by the chart.

Case B is what SPC exists for. Nothing has failed, nobody is scrapping anything, and the run rule has detected a real change with enough lead time to find its cause while parts are still good. Acting here is cheap; acting after the drift crosses 505 means scrap and an investigation.

The rule to state plainly: never compute control limits from specification limits, and never draw specification limits on a control chart. Doing so is the single most common SPC error, and it destroys the chart's ability to detect instability — a process well inside a wide tolerance will show no signal at all while degrading steadily.

The practical corollary is that both are needed. Control limits answer "has something changed?" and specification limits answer "is the customer going to accept this?" A quality system reporting only one of them is blind in a specific, predictable direction.

Traceability is the ability to answer two questions with evidence: for a given finished unit, what went into it and under what conditions — the backward trace — and for a given input lot or condition, which finished units are affected, the forward trace. Genealogy is the data structure that makes both possible: the recorded parent-child relationships between consumed materials, equipment, process conditions, operators and produced items, captured at the moment of consumption. The reason it is a design requirement rather than a reporting feature is that neither question can be reconstructed later from inventory balances. If the link between a specific serial and a specific consumed lot was not written at the time, it does not exist, and a regulator asking for it in three years will not accept an inference from stock movements.

Lot tracking identifies a quantity produced or received as one run, so the smallest thing you can name is the lot. Serial tracking identifies each individual unit. The difference is entirely about recall precision: a defect traced to a lot implicates the whole lot, and a defect traced to a serial implicates one unit and whatever shares its genealogy. Serialisation costs more — marking, reading, and a genealogy record per unit rather than per run, which is orders of magnitude more rows — and is mandated in some industries, notably pharmaceutical packaging and aerospace parts. The nuance worth offering is that most real products mix them: a serialised assembly consumes lot-tracked consumables, so the genealogy graph has both node types and a query must traverse across the boundary rather than assuming one identity scheme.

A customer returns one pump with a failed bearing, and the question the business needs answered in hours is how many others share its cause.

flowchart LR
    S[Finished serial<br/>PUMP-A200 SN 4471982] --> W[Work order WO-88120<br/>line 2, shift B, 14 March]
    W --> C[Consumed BEARING-6204<br/>supplier lot BR-2026-118]
    W --> G[Consumed GASKET-12<br/>supplier lot GK-2026-042]
    C --> R[Goods receipt GR-99143<br/>supplier heat number 7741]
    R --> F[Forward trace<br/>every work order that drew BR-2026-118]
    F --> U[1,842 serials in scope<br/>of which 1,206 already shipped]

The trace runs backwards first and then forwards, and the forward leg is the one that matters commercially. Backwards from the serial you learn which bearing lot was consumed; forwards from that lot you learn every other unit that could have the same defect. The recall scope is the output of the second query, not the first.

The numbers on the last node are the entire argument for genealogy as a design requirement. Without a per-serial consumption record you cannot say 1,842 — you can only say that the lot was received in February and issued to production over six weeks, so the scope is every pump built in that window. That is typically an order of magnitude more units, and the difference between the two figures is the cost of the recall.

Two schema details decide whether this query is possible. Consumption must be recorded against the producing work order at issue time, with quantity and lot, which means the floor must scan rather than back-flush a standard quantity at completion. And the shipped side must be linked too, since a trace that ends at the warehouse cannot tell you which customers to contact.

The test worth mentioning is the recall drill. Regulated manufacturers rehearse this against a randomly chosen serial with a clock running, because the requirement is usually expressed in hours. A schema that answers it with a recursive query over a properly indexed genealogy table passes; one that requires someone to join four systems by hand does not, and finding that out during a real recall is the failure this exercise exists to prevent.

Because a measurement is only evidence if the instrument that made it was known to be accurate at the time. A calibration record ties an instrument to a reference standard, with a date, a result, a tolerance and a next-due date, and it is what makes a quality result defensible rather than merely recorded. The consequence that surprises engineers is retrospective: when an instrument is found out of tolerance at its next calibration, everything it measured since the previous one is suspect, so the system must be able to find those results and those units. That is a genealogy query with an instrument as the node, which means your data model needs to record which device took each measurement. Storing only the value is what makes an out-of-tolerance finding turn into a blanket quarantine.

One asset, three strategies, and a final row that inverts the intuition people arrive with.

Asset: the bottleneck filler. A line stop costs £3,200 per hour.
A bearing change takes 1.5 h inside a maintenance window, or 4 h unplanned
with collateral damage, so £12,800 of lost production per unplanned failure.

                                reactive     planned      predictive
----------------------------  ----------  ----------  --------------
trigger                       it stopped   3,000 hrs  vibration trend
unplanned failures per year          2.1         0.3            0.15
lost production per year         £26,880      £3,840          £1,920
parts consumed per year           £1,700      £4,200          £1,700
monitoring and analysis                £0          £0          £4,000
----------------------------  ----------  ----------  --------------
total cost per year              £28,580      £8,040          £7,620
cost per unplanned failure       £13,610     £26,800         £50,800

Reactive is cheapest to set up and by far the most expensive to run, because every intervention happens at the worst possible moment and takes longer. Planned maintenance eliminates most of that by servicing on a fixed interval, and its cost shows up in the parts row: replacing a component that had half its life left, three times a year, wastes it. That waste is the price of ignoring condition.

Predictive narrows the gap by servicing on evidence rather than on a calendar, so parts run closer to their real life and the intervention is still scheduled. It is only marginally cheaper here, and that is the honest answer — on this asset the business case is thin, and it would be strongly negative on a non-constraint machine whose stop costs nothing.

The last row is the one to read aloud. Cost per unplanned failure rises as the strategy improves, because you are paying to not have failures and the few that remain each carry a share of the prevention spend. Anyone using cost per failure as a KPI will conclude that reactive maintenance is the efficient choice, which is the wrong answer arrived at from a correct calculation.

What decides the strategy is not the table but asset criticality. Reactive is entirely correct for a redundant pump nobody notices, and unacceptable on the constraint. Applying one policy across a plant is the mistake both directions.

Two numbers from a maintenance system, and the arithmetic that shows which one is worth spending on.

Asset: filler, twelve months of records
  Operating hours              6,200
  Failures                        31
  Total repair hours             118

MTBF = 6,200 / 31                                = 200 hours between failures
MTTR = 118 / 31                                  = 3.8 hours per repair
Availability = MTBF / MTBF + MTTR = 200 / 203.8  = 98.1%
  Lost production = 1.9% of 6,200 h              = 118 h, at £3,200/h = £378,000

Option 1: halve MTTR to 1.9 h by holding spares on site and pre-staging tools
  Availability = 200 / 201.9                     = 99.06%
Option 2: double MTBF to 400 h by redesigning the bearing mount
  Availability = 400 / 403.8                     = 99.06%

The two options are arithmetically identical and operationally nothing alike. Halving repair time is a logistics and preparation problem: a spares kit, a documented procedure, a trained crew, perhaps £15,000 and a month. Doubling time between failures is an engineering change requiring analysis, a modification and validation, likely a year and a great deal more money.

That is the practical value of separating the two metrics. Availability alone tells you there is a problem worth £378,000; the split tells you that this asset fails often and is slow to fix, and that the cheap half of the improvement is sitting in the parts store. Teams that track only uptime keep proposing the expensive option.

Two cautions about the numbers. MTBF is a mean and says nothing about the distribution, so an asset with 200-hour MTBF may fail predictably at 200 hours or randomly at anything from 5 to 900, and only the first is worth scheduling against. And MTBF derived from work orders is derived from free-text records written by whoever did the repair, where a single failure logged as three visits becomes three failures and quietly halves the figure.

Three properties, and a signal missing any one of them will not support a decision. It must observe the degrading component rather than something near it — a motor current signal will not see a coupling wearing. It must change monotonically and detectably before failure, with a lead time longer than the time needed to schedule the intervention, which is usually weeks rather than hours. And it must be separable from operating conditions, because a signal that also moves with speed, load, product and ambient temperature is a signal you cannot threshold without context. Vibration on rotating equipment, motor current signature, oil particle count, thermal images and acoustic emission are the established ones. The question to ask before any of it is what the intervention is and how long it takes to arrange, because that sets the lead time the signal must deliver.

A vibration threshold taken from a standards chart, applied without context, on forty pumps.

Alert rule: vibration RMS > 4.5 mm/s, evaluated on every reading

  alerts per week                                 31
  genuine developing faults per week               0.4
  precision                                       0.4 / 31        = 1.3%
  operator time per investigation                 25 min
  operator time consumed per week                 31 x 25 min     ~ 13 hours

What the 31 alerts actually were
  pump running at a different duty point          12
  clean-in-place cycle, 20 minutes of noise        9
  sensor mounting resonance on two assets          6
  transient at start-up                            3.6
  genuine bearing degradation                      0.4

Same signal, alerting only on a 24 h rolling median, only while the
machine is in steady-state production on the recorded product
  alerts per week                                  1.8
  genuine faults still caught                      0.4 of 0.4
  precision                                        22%

Thirteen hours a week of investigation for one real finding a fortnight is not a monitoring system, it is a tax. And the cost that matters is not the hours: it is that by week three the operators have learned the alert means nothing, so the alert that finally is real gets the same shrug as the previous thirty. Recovering that trust takes far longer than losing it, and it cannot be recovered by tightening the threshold afterwards.

The breakdown shows that none of the false alarms are sensor noise. Every one is a real vibration increase caused by something other than a fault — a different duty point, a cleaning cycle, a start-up transient. The threshold was not wrong about the physics; it was applied without knowing what the machine was doing, which is the contextualisation problem in its most expensive form.

The two fixes are unglamorous and both are context rather than modelling. Suppress evaluation outside steady-state production on the recorded product, and compare a rolling statistic against the asset's own baseline rather than an absolute number from a chart, because two pumps of the same model on different mounts have different normal levels.

The lesson to carry into any alerting design is that precision, not recall, sets adoption. A monitor at 22% precision catching the same faults is enormously more valuable than one at 1.3%, even though it detects nothing extra, because it is the version people still act on in month six.

Four things, and the absence of any one of them ends the project regardless of technique. Labels: a maintenance history where failure onset can be dated, which free-text work orders recording a repair date rarely give you. Positive examples: a well-run plant deliberately does not run assets to failure, so the class you want to predict is nearly empty and the imbalance is far more extreme than ordinary machine learning problems. Sensors that observe the failing component, which is not guaranteed since instrumentation was installed for control rather than diagnosis. And a stable process, because product and setpoint changes shift the input distribution so a model fitted last quarter describes a different machine. The modelling discipline itself — the split, the leakage checks, the metric on an imbalanced class — is general and covered elsewhere; what is domain-specific is that the split must be by failure event and by asset, since readings from one failure on both sides of the line guarantee an encouraging and worthless result.

A ranking of equipment by the consequence of its failure: lost production, safety, environmental impact, quality risk and repair cost, usually crossed with failure likelihood. It comes first because maintenance strategy is a per-asset decision and the correct strategy for most assets is to do very little. A redundant pump whose failure nobody notices should be run to failure; the constraint machine whose stop costs thousands an hour justifies monitoring, spares and prediction. Skipping this step is why predictive-maintenance programmes instrument the assets that were easiest to reach rather than the ones that matter, and then cannot demonstrate value. The reliability engineer holds this ranking, usually informally, and getting it from them in week one is the highest-value conversation available in the domain — it is not inferable from the data.

Because a prediction is only worth anything if there is time to act on it, and acting means finding a slot, a part and a person. A model that flags a bearing four hours before failure has produced an unplanned stop with extra paperwork; the same model at three weeks is worth a great deal, because the work can be folded into a scheduled window and the part ordered normally. So the requirement runs backwards from the intervention: establish how long scheduling actually takes at this plant, then ask whether the signal moves detectably that far ahead. Very often it does not, and the honest answer is condition monitoring against thresholds rather than prediction. That answer is unpopular and is frequently correct, which is why offering it is a stronger interview move than proposing an architecture.

The model is a segmentation scheme rather than a diagram of software, and its value is entirely in the right-hand column.

level  what lives there                     what may cross upward from it
-----  ----------------------------------   -----------------------------------------
0      sensors, actuators, drives           nothing directly, only via level 1
1      PLCs, safety instrumented systems    process values read by level 2 on
                                            subscription, no writes from above
2      SCADA, HMI, line controllers         aggregated values and alarms to level 3
3      MES, historian, batch, local domain  records to level 3.5 only, never
       controller, engineering workstations  straight to level 4
3.5    the DMZ: broker, historian replica,   the only place where a level 3 and a
       reverse proxy, patch and jump host    level 4 system may both connect
4      ERP and business systems              requests into the DMZ, never past it
5      internet, cloud, remote vendors       no path to level 3 or below, ever

Direction rule: connections originate low and terminate high. Nothing at
level 4 or 5 opens a socket to anything at level 3 or below.

The direction rule is the whole design, and it is what most integration proposals violate without noticing. A cloud service that polls a plant historian requires an inbound connection to level 3 and will be refused. The same requirement inverted — a plant-side collector that publishes outbound to a broker in the DMZ, which a cloud ingestion service reads — carries the same data and is routinely approved.

Level 3.5 is the part people forget exists and the part that makes the rest work. It is the only place a plant system and a business system are permitted to meet, and the meeting is always brokered: a replica, a queue, a proxy, never a direct session. Anything you want to send to the plant lands there and is collected by a plant-side system that chose to fetch it.

The boundaries also determine failure behaviour, which is the design consequence worth naming. If levels 4 and 5 vanish, production continues, because everything required to make things is at level 3 and below. That is a deliberate property and it is why plant systems keep local copies of what they need — an MES that cannot dispatch work when the corporate network is down would be an unacceptable design.

Two practical notes. Engineering workstations at level 3 are the most attacked asset in the plant, because they hold the project files and can program controllers, and they are frequently the least maintained. And the model says nothing about wireless or vendor remote access, which is where most real incidents arrive, so a genuine architecture needs those drawn explicitly rather than assumed away.

Because plants need data out and vendors need access in, so every genuinely isolated network acquires exceptions until it is a segmented network that people still describe as air-gapped. The exceptions are always the same: a vendor maintenance laptop, a cellular modem installed by a machine builder, an engineering workstation that is also on the office network, a USB stick carrying a program update, a wireless link somebody added for a handheld terminal. Each is individually reasonable and collectively fatal to the claim. The reason it matters is that believing in the air gap justifies not doing the work: no segmentation, no monitoring, no asset inventory, flat addressing, because none of it seemed necessary. The honest posture is to assume connectivity exists, know where it is, and control it — which is what zones and conduits and IEC 62443 are for.

The organising concept of IEC 62443, and the vocabulary to use when negotiating plant access. A zone is a grouping of assets that share a security requirement — a production cell, a safety system, the DMZ — and a conduit is a defined, controlled communication path between two zones, carrying an explicit list of what may traverse it. The point of the abstraction is that it replaces an argument about individual firewall rules with an argument about which zones exist and what they need from each other, which is a conversation a controls engineer and a security engineer can both have. It also makes the answer to "can I have access to the historian" concrete: you are asking for a conduit, with a direction, a protocol, an authenticated endpoint and a documented reason. Framing a request that way is the difference between being refused and being scheduled.

Because patching requires stopping the process, and stopping the process has a per-hour cost somebody on site can quote from memory. Beyond that, the software is frequently validated as part of a qualified process — in pharmaceutical, food, aerospace and automotive production, a change affecting product quality carries documentation and re-validation duties that make a casual patch impossible. Much of it is also unpatchable in principle: a controller whose vendor stopped supporting it in 2011, an HMI running an operating system with no updates, a machine whose warranty voids if anything changes. So the control moves off the device: segmentation so the vulnerable thing is unreachable, monitoring instead of agents, compensating controls, and patching confined to the maintenance window when the line is already down. The habit to unlearn is treating a patch level as the primary security metric here.

Because it satisfies both sides of an argument that otherwise has no resolution. The business needs plant data continuously; the plant cannot accept an inbound connection to a network full of unauthenticated, unpatchable controllers. A broker or replica in a demilitarised zone between them lets a plant-side collector publish outward and a business-side consumer read from the same place, with no session ever originating outside and terminating inside. The consequence for your architecture is that request-response against plant systems is not available to you: you subscribe to something that reads the plant, and anything you want to send travels as data a plant-side system chooses to fetch and a human or control program chooses to accept. Designs that assume they can query a PLC on demand are not slightly wrong, they are unapprovable, and discovering that after building is expensive.

Four reasons, all of them concrete. Bandwidth: a plant with high-rate vibration or vision data produces more than its link can carry, so features are computed locally and only features are shipped. Latency: a decision that must act on the process within a scan cycle cannot make a round trip to a region. Availability: production must continue when the link is down, so anything the line depends on runs locally. And data gravity plus policy — some sites will not permit raw process data to leave at all. What the edge therefore does is filter, aggregate, buffer and run the models whose output feeds back into operations, while the cloud does fleet comparison, training and long-horizon storage. The operational cost to name is fleet management: two hundred collectors across twelve sites need deployment, versioning, monitoring and certificate rotation over links you do not control.

Safety functions — emergency stops, guard interlocks, overpressure and overspeed protection — live in a dedicated safety instrumented system, separate from ordinary control, designed and assessed under functional-safety standards such as IEC 61508 and its sector derivatives with a rated integrity level. The separation is deliberate and architectural: the safety function must work when the control system does not, so it shares as little as possible with it. The consequence for anything you build is absolute rather than negotiable. Analytics may inform a human and may advise a control system that a human supervises; it does not get a vote in the safety chain, and a proposal that closes a loop through your model into a safety function will be rejected on principle. Knowing to say this unprompted is a strong signal in an interview, because it shows you know where the boundary is.

Because the machines have no security model to speak of and cannot acquire one. Many industrial protocols authenticate nothing, so a controller will faithfully accept a command to change a setpoint or stop from anyone who can reach its port, and the protocol offers no way to tell a legitimate engineer from anyone else. They cannot be patched on the corporate cadence, because patching means stopping production and, in regulated plants, re-validating. They tolerate scanning badly: a vulnerability scanner or an aggressive poll loop can disturb scan timing or crash an older controller outright, so ordinary IT hygiene is itself a hazard. And the blast radius is physical — the consequence of compromise is a process running uncontrolled rather than data being copied. What the interviewer is testing is whether you understand that the control cannot go into the device and must therefore go around it: segmentation, brokered outbound flows, monitoring without agents. A candidate who proposes putting an agent on the PLC has answered the question badly in one sentence.

Because it looks like application telemetry and behaves differently in four ways at once. It is recorded on change with a deadband, so a gap means "unchanged" rather than "missing" and treating it as missing drops the value that was actually in force. Aggregation must therefore be time-weighted; the mean of the samples is not the mean of the process, and the two differ by enough to change conclusions. Every value carries a quality flag that most code ignores, so substituted and stale readings get averaged in as fact. And clocks across controllers, historians and business systems are not synchronised, so joins on time almost work. None of these produce errors. They produce plausible numbers, which is why the first thing to do with any plant dataset is establish how it was sampled before computing anything from it.

Because the pilot succeeded on things that do not transfer. Tag names, units, equipment models, historian configuration and asset hierarchy were all specific to the first site, and the second site was commissioned by a different integrator in a different decade, so the mapping work restarts from zero. The pilot also ran with the enthusiastic site engineer standing next to it, and there is one of those. Meanwhile the payback has to be proven against a capital budget where the competing proposal is simply buying another machine, which has a known return. The engineering response is to make the contextualisation layer — hierarchy, naming, units, states — the deliverable rather than the dashboard, since that is the part whose absence blocks site two. When evaluating an employer here, asking how many of their pilots reached a second plant is the sharpest question available.

Because the category a stop is recorded under determines whose number it damages. Planned downtime is excluded from OEE's availability, unplanned is not; a stop attributed to material supply hurts procurement, the same stop attributed to machine failure hurts maintenance, and one attributed to changeover hurts nobody much. Those categories are entered by operators under time pressure, sometimes retrospectively, and the defaults matter enormously. The consequence for you is that a pipeline which re-derives classification from machine data — inferring a stop reason from sensor state rather than reading the operator's entry — will change published figures, and will be challenged within a day by whoever the new number embarrasses. That is not a reason to avoid it, but it is a reason to socialise the change first and to keep both the recorded and derived classifications rather than silently replacing one.

Proposing a streaming lakehouse, a feature store and a per-machine digital twin for a plant producing thirteen terabytes a year that has no asset hierarchy and no reliable tag dictionary. The volume almost never justifies the architecture — one well-chosen time-series store handles most single-site workloads — and the thing actually blocking value is context, which no amount of platform supplies. The senior move is to state the tag count, sample rates and resulting volume aloud, propose the simplest store that meets it, and spend the saved effort on the hierarchy, the naming, the units and the machine-state model. Restraint reads well here for a specific reason: an OT team's willingness to work with you depends on your proposal being small, reversible and outbound-only, and an elaborate architecture is harder to approve regardless of its merit.

"What would you do in your first two weeks on a plant data project?" A strong answer is unglamorous and specific: walk the line and watch an operator work, get the asset hierarchy and the tag dictionary and find out who maintains them, establish how the historian is configured — deadbands, sampling, retention — check clock synchronisation across the systems you will join, ask the reliability engineer which assets actually matter, and find out what the maintenance window is before proposing any deployment. It names people as well as data, because the controls team's permission is a dependency and not a formality. A weak answer describes a platform: connectors, ingestion, a lake, dashboards. That answer is not wrong about the eventual system and reveals that the candidate expects the hard part to be the pipeline, when in this domain it is always the meaning of the data and the trust of the people who own the equipment.