Learn AI Create the Future — with Pranay
Main site

Manufacturing and Predictive Maintenance

Deploying a model inside a factory

A model that scores well in a notebook still has to fit inside a factory's real-time control loop, run on hardware with no internet connection, and earn the trust of the operators who have to act on it.

Read these first

On this page 6
  1. Why it exists
  2. How it works
  3. Where you have already seen it
  4. An honest warning
  5. Remember this
  6. What to learn next

One lesson, three depths. Pick the one that fits you today — you can switch any time.

Beginner — No maths. Plain English.

A model that scores well in a notebook still has to fit inside a running factory. A factory does not pause to let it settle in.

Think about a new head chef joining a busy restaurant kitchen and wanting to change how a signature dish is cooked. Even with a genuinely better recipe, they cannot swap it in the middle of Saturday night's dinner rush. The change needs testing during a quiet period, and buy-in from the rest of the kitchen staff. It also needs a fast way back to the old method, if something goes wrong on the first try.

Putting a machine learning model onto a real factory floor works the same way — the model being accurate is only the beginning of the job.

Why it exists

Every lesson in this section so far has focused on building a model that works well on data. A working factory adds a whole second layer of requirements that have nothing to do with accuracy.

Many factory decisions run on a strict timer, called a control loop. It is a system that must make a decision every few milliseconds, to keep machinery running safely and smoothly. A model that is highly accurate but too slow to answer within that window is unusable there, no matter how good its predictions are.

Factory floors also often run on air-gapped networks — deliberately disconnected from the internet, for security reasons. That means a model has to run entirely on local hardware, sometimes with far less computing power than a laptop. The people acting on a model's output are operators and engineers, not data scientists. If they do not trust or understand why an alarm fired, they will learn to ignore it.

How it works

A factory's control loop needs a decision every 20 milliseconds.

Small, simple model:   0.45 ms to answer   -> comfortably fits, plenty of room to spare
Large, complex model:  39.5 ms to answer   -> nearly TWICE the entire time budget

The complex model might be more accurate on paper.
It is completely unusable here, because it cannot answer in time.

Choosing the right model for a factory is not only "which one scores highest." It is "which one is accurate enough, while still fitting every real constraint the factory imposes."

Where you have already seen it

  • An airbag deploying within milliseconds of a crash sensor triggering. No matter how sophisticated a decision system could theoretically be, it has to decide in an extremely tight, fixed time window.
  • A traffic signal that cannot pause mid-cycle to "think longer" about a hard decision. It has to act within its cycle, using whatever it has computed by then.
  • A new safety procedure at a workplace. It typically needs a trial period, staff training, and a documented fallback plan, before it becomes the default way of working — not an overnight switch.

An honest warning

Any model that influences equipment behaviour, safety systems, or product quality decisions on a real production line needs more than a good accuracy score. It needs sign-off from qualified engineers, and in many industries, formal safety validation before it goes live. A model built and tested entirely on historical data has never had to prove itself under real, live, imperfect factory conditions. The gap between the two can be significant.

Remember this

  • A model has to fit inside real timing constraints, not only be accurate on a test set.
  • Factory hardware is often disconnected, limited, and very different from a data scientist's laptop or cloud server.
  • Trust from the people who act on a model's output has to be earned deliberately, through testing, transparency, and a working fallback plan.

What to learn next

Developer — Code and libraries.

Setup

bash
pip install numpy scikit-learn

Minimal runnable code

A factory's control loop needs a decision every 20 milliseconds. We measure how long a small model and a much larger, more complex model actually take to produce one prediction, and check both against that real budget.

factory_deployment_latency.py
import time
import numpy as np
from sklearn.ensemble import RandomForestClassifier

rng = np.random.default_rng(40)

# Some quick training data -- the model architecture is what matters here,
# not its accuracy.
X_train = rng.normal(0, 1, (2000, 6))
y_train = (X_train[:, 0] + X_train[:, 1] > 0).astype(int)
X_new = rng.normal(0, 1, (1, 6))   # one new reading, as it would arrive live on the line

# This factory's control loop makes a decision every 20 milliseconds --
# a real, hard budget set by the physical process, not a preference.
budget_ms = 20


def time_inference(model, X, n_repeats=200):
    # Warm up first, so one-time setup cost doesn't distort the measurement.
    model.predict(X)
    start = time.perf_counter()
    for _ in range(n_repeats):
        model.predict(X)
    elapsed_ms = (time.perf_counter() - start) / n_repeats * 1000
    return elapsed_ms


small_model = RandomForestClassifier(n_estimators=20, max_depth=4, random_state=0).fit(X_train, y_train)
large_model = RandomForestClassifier(n_estimators=2000, max_depth=None, random_state=0).fit(X_train, y_train)

small_latency = time_inference(small_model, X_new)
large_latency = time_inference(large_model, X_new)

print(f"control loop budget: {budget_ms} ms per decision")
print()
print(f"small model (20 trees, depth 4):   {small_latency:.2f} ms per prediction  "
      f"-> {'FITS the budget' if small_latency < budget_ms else 'TOO SLOW'}")
print(f"large model (2000 trees, no limit): {large_latency:.2f} ms per prediction  "
      f"-> {'FITS the budget' if large_latency < budget_ms else 'TOO SLOW'}")
print()
print(f"the large model is {large_latency / small_latency:.0f}x slower per prediction")
Output
control loop budget: 20 ms per decision

small model (20 trees, depth 4):   0.57 ms per prediction  -> FITS the budget
large model (2000 trees, no limit): 43.37 ms per prediction  -> TOO SLOW

the large model is 76x slower per prediction

Wall-clock timing depends on the machine running it — your exact milliseconds will differ from the ones above. What stays true on any laptop is the shape of the result: the small model fits comfortably inside the budget, the large model does not, and the gap between them is large.

What actually happened

time_inference measures wall-clock time for one prediction, averaged over 200 repeats to smooth out random noise from the operating system scheduling other work in between calls. The warm-up call before timing starts matters — the very first prediction after training often pays a one-time setup cost that would otherwise unfairly inflate the measurement.

The small model — only 20 shallow trees — answers in under a millisecond, comfortably inside a 20-millisecond budget. The large model — 2,000 unrestricted trees — takes over 40 milliseconds, more than double the entire available window. Neither number says anything about which model would have been more accurate. This measurement answers a completely different, equally important question: which model can even be used here at all.

Common mistakes

Choosing a model purely on accuracy metrics from a notebook, without ever measuring latency on the actual deployment hardware. A model benchmarked on a powerful development machine can behave very differently on the smaller, often years-older hardware common on a real factory floor.

Forgetting that this factory's hardware may have no internet connection at all. A model that calls a cloud API for inference is not an option on an air-gapped network — the entire model has to run locally.

Deploying straight to the full production line. A staged rollout — one machine, then one line, then the full factory, each stage watched closely with an easy rollback — catches problems while they are still small and recoverable.

Underestimating the trust-building work. An operator who sees a confusing or unexplained alarm a few times will start ignoring that alarm entirely, no matter how statistically sound the model behind it is. Clear, actionable alerts, not raw model scores, are what actually get acted on.

Try it yourself

Change n_estimators=2000 to n_estimators=200 for the large model, and re-run. Find roughly how many trees this specific model architecture can use while still comfortably fitting the 20-millisecond budget on your machine — a small, concrete taste of the trade-offs a real deployment engineer navigates constantly.

What to learn next

Researcher — Mathematics and papers.

The IT/OT divide

Factory deployment sits across the boundary between IT (information technology — servers, networks, the systems data scientists usually build for) and OT (operational technology — the programmable logic controllers, SCADA systems and industrial control networks that directly run physical equipment). The ISA-95 standard formalises this as a layered hierarchy, from field-level sensors and actuators up through control, supervisory (MES/SCADA), planning, and enterprise IT layers, with deliberately restricted, often one-directional data flow between them for safety and security reasons. A model trained on data pulled from the historian (a supervisory-layer system) but intended to influence a control-layer decision has to cross this boundary formally, typically through validated, restricted interfaces rather than direct network access — a materially different integration problem than deploying a model behind a typical web API.

Real-time systems and determinism

Control-loop timing, as measured in the developer example, is a specific instance of a real-time systems requirement: not only "fast on average," but bounded in the worst case. A hard real-time constraint means missing the deadline is a system failure, potentially a safety failure; a soft real-time constraint tolerates occasional misses with degraded but acceptable performance. This distinction matters enormously for model choice: an ensemble method's prediction time can vary run to run depending on tree depth reached and system load, which is acceptable for a soft real-time dashboard alert but potentially unacceptable for a hard real-time control decision, where worst-case latency, not average latency, is the number that must be bounded and verified.

Functional safety standards

Where a model's output can influence equipment behaviour with a safety consequence, international functional-safety standards apply: IEC 61508 generally, and IEC 61511 specifically for the process industries, define Safety Integrity Levels (SIL) — a graded classification of how rigorously a safety-related function must be designed, verified, and maintained, based on the severity and likelihood of the harm it is meant to prevent. A learned model used within or adjacent to a safety instrumented function typically cannot itself be SIL-certified in the way a traditional, deterministic control algorithm can, precisely because its behaviour on inputs outside its training distribution is not formally verifiable in the same sense — which is why, in practice, ML-based systems in safety-relevant roles are almost always architected as an advisory or monitoring layer feeding a separate, traditionally engineered, certified safety system, rather than as the safety function itself.

MLOps for industrial deployment

The general machine-learning operations practices covered in MLOps apply here with added constraints: model updates typically require a formal change management process common in regulated manufacturing environments, often including revalidation against a documented test suite before any updated model is allowed onto the production network. Combined with the air-gapped, resource-constrained deployment target discussed above, this generally rules out the continuous, automated retraining pipelines common in web-scale ML deployment — industrial model updates are usually a deliberately slower, more heavily gated process, trading deployment velocity for auditability and safety assurance.

Key references

  • ISA-95 / IEC 62264. Enterprise-Control System Integration. International Society of Automation.
  • IEC 61508. Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems. International Electrotechnical Commission.
  • Lee, E. A. (2008). Cyber Physical Systems: Design Challenges. IEEE International Symposium on Object-Oriented Real-Time Distributed Computing — a widely cited framing of the real-time, physically-grounded constraints distinguishing this class of system from conventional software.

What to learn next