Skip to content
willowark

AI on the plant floor that earns its keep

Industrial AI applies machine learning to production problems: predicting failures from vibration and current signatures, detecting defects that resist rule-based inspection, optimizing setpoints across interacting variables, and pulling answers out of years of maintenance logs. It removes a specific frustration — knowing your data holds the answer while nobody has time to dig it out.

Willowark starts from the decision, not the model. What will someone do differently when the system speaks — schedule a bearing replacement, adjust an oven, quarantine a lot? We work backwards from that to the data required, and we are direct about readiness: many industrial AI projects should begin as data acquisition projects, and we will tell you when yours is one.

Illustrative: an industrial control cabinet with PLC modules and wiringIndustrial Automation

How the work gets done

The same way every time: scope, build, hand over.

The technical work is mostly data engineering: aligning time-series signals with quality outcomes, labeling events — failures, defects, changeovers — accurately enough to train on, and building features from raw signals, like spectral content from vibration or load profiles from current. Models range from anomaly detection on healthy-state baselines, useful when failure examples are scarce, to supervised models where history is rich, to fine-tuned vision models for defect classes. Deployment is industrial-grade: models run at the edge or on-prem where latency and IT policy demand, with versioning, drift monitoring, and a defined fallback when confidence drops.

Production success means the model's outputs change behavior and the change pays: maintenance scheduled from predictions with fewer surprise stops, defect detection with escape and false-reject rates measured against the manual baseline, energy or yield gains traceable to recommended setpoints. Every model ships with monitoring, because plants change — new products, new materials — and a model nobody watches degrades silently.

Scoping is a data-readiness review with a walk through the plant. We look at what is already logged and at what resolution, whether failures and defects are recorded with accurate timestamps, how labels are captured, and where the process data and quality outcomes can be joined. Just as important, we sit with the maintenance planner or process engineer who will act on the model's output and design what that output looks like — a ranked work list, an HMI indicator, a setpoint recommendation with a reason. If the data cannot support the decision yet, the scope becomes instrumenting and logging until it can, with a defined checkpoint.

Model outputs advise; they do not control safety functions, and setpoint recommendations are bounded by limits your process engineers set, typically running in advisory mode first. What usually goes wrong is drift: a new material, a rebuilt machine, or a seasonal shift changes the signal and the model's confidence quietly decays. We design against it with monitoring on input distributions and prediction rates, alerts when either moves, and a retraining procedure your team can run. Handover includes the data pipeline code, the trained model with its evaluation record, the monitoring dashboards, and documentation explaining the model's limits in plain language for the people relying on it.

  1. Scope it in writing

    What we agree before work starts

    • Use-case assessment with data-readiness evaluation
    • Data pipeline aligning process signals with outcomes
  2. Build with checkpoints

    Working results, not slide decks

    • Trained and validated model with documented performance
    • Edge or on-prem deployment with drift monitoring
  3. Hand over something you own

    Documentation, source, and training

    • Fallback logic and retraining plan
    • Model documentation covering inputs, limits, and evaluation results for operators and engineers

Sound familiar?

Where industrial ai earns its keep.

A gearbox that failed twice this year, each time with warning signs visible only in hindsight

A surface defect that inspectors describe as 'you know it when you see it'

An energy-intensive process run on setpoints inherited from a retired engineer

Five years of maintenance logs nobody has ever analyzed

Common questions

Asked before every industrial ai project.

Do we have enough data for AI to work?

It depends on the question. Anomaly detection can start with weeks of healthy-machine data; supervised failure prediction needs recorded failures; vision models need labeled defect examples, and modest numbers often suffice with modern approaches. We assess honestly upfront, and if the answer is not yet, the project becomes collecting the right data first.

Does our data have to go to the cloud?

No. Training can happen on-premises or in an isolated environment, and inference typically runs at the edge or on plant servers anyway for latency reasons. Your process data is competitively sensitive and we treat it that way — architecture follows your IT and IP policies.

How is this different from the AI features our equipment vendors sell?

Vendor features see one machine and optimize for that vendor's view. Custom industrial AI sees across your line — combining machine data, quality outcomes, and context no single vendor holds — and you own the models and the data pipeline. The two can coexist; we integrate vendor outputs where they are useful.

How do we know the model is right, and what if it is wrong?

Every model ships with an evaluation against held-out history and a defined fallback. Predictions typically run in advisory mode first — flagged alongside existing practice — so your team can compare them to reality for a period before anyone changes a maintenance schedule on the model's word alone. When it is wrong, the logged prediction and the actual outcome become training data, and the monitoring is designed to catch a pattern of misses rather than a single one.

Do we need data scientists on staff to keep this running?

Usually not for day-to-day operation. The system runs like any other plant application: monitoring dashboards show health, alerts flag drift, and a documented retraining procedure can be run by a capable engineer or by us on a support arrangement. Where you would need specialist skills is extending the model to new problems, and we hand over the pipeline and evaluation code so that work is possible with whoever you choose.

Where this sits

Industrial AI, inside a industrial automation system.

The whole system this service belongs to. Hover or focus a component to see what it is and what it talks to.

Machine data from the plant floor to the office4-20mAEtherNet/IPEtherNet/IPOPC-UARESTRESTMachinepress, cell, lineSensorscounts, temps, currentPLCcontrolHMIoperatorHistoriantag storeDashboardsOEE, downtimeMES / ERPorders

Hover or focus a component to see what it is and what it talks to. Arrow keys move between them.

Sensors and machines report into the PLC; the PLC drives the HMI and publishes tags to a historian; the historian feeds dashboards and, where it exists, the MES.

Components:

  1. Machine (press, cell, line): The equipment itself. Newer machines expose tags; older ones need a sensor or a serial tap.
  2. Sensors (counts, temps, current): Retrofit sensors where the machine offers nothing: proximity counts, current transformers, temperature.
  3. PLC (control): The controller: logic, safety, and the tag table everything else reads.
  4. HMI (operator): Operator screen at the machine.
  5. Historian (tag store): Time-series store of PLC tags: uptime, counts, faults, cycle times.
  6. Dashboards (OEE, downtime): Plant TV and office views: OEE, downtime reasons, shift comparison.
  7. MES / ERP (orders): Work orders down, production counts up.

Connections:

  • Sensors to PLC over 4-20mA
  • Machine to PLC over EtherNet/IP
  • PLC to HMI over EtherNet/IP
  • PLC to Historian over OPC-UA
  • Historian to Dashboards over REST
  • Historian to MES / ERP over REST, both directions
A typical architecture, drawn to explain the pattern — not a specific client's system.

Strategy. Software. Systems.

Have a system that should exist?

Tell us what your operation is doing manually, what isn't connected, or what you're trying to build. We'll tell you plainly whether and how we can help.