Wales Consulting Group · Real Ops. Real ROI.
WALES CONSULTING GROUP Start a conversation
Real ops. Real ROI.

We don't sell technology.We sell operational performance.

We focus on measurable return, not technology for technology's sake. Every engagement starts by identifying where operational problems are costing the business, through downtime, lost throughput, excess material use, maintenance costs, labor inefficiencies, or other constraints. We then quantify the opportunity and target solutions where the expected financial and operational impact justifies the investment.

Start a conversation What we do
OPERATIONAL LOSS · LIVE SIMULATION SCANNING
Losing
$0
Recovered / yr
$0
Line
Running
Capabilities

Five pillars. Every one of them built around your plant, not a template.

Get the data off the floor, turn history into warning, shorten the hunt when something breaks. We build on Inductive Automation's Ignition platform, then layer intelligence on top of it that runs on your own hardware.

PILLAR 01

Ignition Development

The foundation. Gateway architecture, Perspective screens, alarming, and the data capture layer everything else depends on.

  • Operator screens
  • Unified namespace
  • SQL historian
PILLAR 02

Local LLM

A language model running on your hardware, watching production data and PLC logic. On-premise, it can run fully air-gapped.

  • On-prem GPU
  • Your own cloud
  • Air-gap capable
PILLAR 03

Production Analytics

Performance trending, specialized reports written on request, and the analysis layer that makes a smart factory actually smart.

  • Trending
  • Custom reports
  • Process optimization
PILLAR 04

Guided Troubleshooting

The model has your PLC logic indexed alongside production history. When a fault hits, that context is what shortens the hunt.

  • PLC context
  • Root-cause ranking
  • Guided resolution
PILLAR 05

Predictive Maintenance

Everything above feeds this: spotting degradation weeks out, and custom tools that help your maintenance team act on it.

  • Degradation modeling
  • CMMS integration
  • Maintenance tooling
All five

They compound.

Each pillar is useful on its own. Together they turn a plant that reports what already happened into one that tells you what's coming.

Start a conversation
Results

What this has been worth to the plants that did it.

Results from iron manufacturing.

Cutting downtime, raising throughput

Mid-size manufacturer · real-time line visibility and maintenance response

15%
Increase in production throughput
$5.3M
Additional annual revenue from the throughput increase alone
20–25%
Further throughput with LLM integration
  • Built a custom tablet-based maintenance app for technicians.
  • Live line status, sensor data, active faults, and fault history in one place.
  • Built-in troubleshooting guide plus full work order and preventive maintenance management.
  • Throughput increased 15% on visibility alone.
  • Implemented guided troubleshooting and predictive maintenance monitoring.

Automated paint thickness control

Heavy industrial manufacturer · model predictive control for epoxy coating

$140K/mo
Coating cost overrun eliminated
$3.3M
Total material savings over two years, and climbing
2 years
In continuous production, savings still growing
  • The plant was running $140K a month over budget on epoxy coating.
  • We built a model predictive control system into the line's automation.
  • It calculates expected coating thickness from product dimensions and controls the machine directly.
  • Overrun eliminated, plus a noticeable improvement in coating quality.
  • Algorithmic control at the PLC and SCADA level.

Inventory tracking and stockout elimination

Mid-size manufacturer · hand-scanner inventory tied to maintenance work orders

45 min → 0
Time to locate a part
2% → 0%
Stockout rate, 2025 against 2026 to date
Live
Inventory linked directly to maintenance work orders
  • Deployed a hand-scanner inventory system tied directly into the maintenance platform.
  • Scan the job and the system tells the technician which part to pull and where it is.
  • Required mapping the full parts catalog to every machine before go-live.
  • Technicians no longer pull parts outside the tracked system, which is what eliminated the stockouts.

Figures throughout this section were reported directly by each client's engineering team. Company names are withheld by request.

Foundations

What SCADA actually is.

Plain language, because the acronym hides a simple idea.

SCADA stands for Supervisory Control and Data Acquisition. In practice it is the layer that sits above your equipment. It reads what every machine, sensor and PLC on the floor is doing, puts that on a screen your team can act on, raises an alarm when something moves out of range, and keeps a record of all of it.

Most plants already have pieces of this. A panel here, an HMI there, a spreadsheet somebody maintains by hand. What they usually do not have is one system where the data is complete, consistent and queryable.

That distinction is commercial, not technical. You cannot quantify downtime you never recorded, or prove a throughput gain you cannot measure. Every number in the results above came out of a plant that was capturing its data properly first. SCADA is the foundation the return is built on.

It sees

Reads every machine, sensor and PLC on the floor and brings them into one place, including equipment from different vendors and different decades.

It warns

Raises an alarm when a value moves outside the range it should be in, so a problem is caught by the system rather than by whoever happens to walk past.

It remembers

Keeps the history. This is the part that lets you prove a number to a customer, a regulator, or your own finance team.

Before you ask

The three things everyone asks first.

Do we replace our PLCs?

No. We sit above the control layer and read what you already have. Your PLC logic keeps running exactly as it does today. On most projects we don't touch controls at all.

Can it run beside our SCADA?

Yes, and that's the safest start. We read the same data in parallel, you evaluate it against the live system with no production risk, and you cut over only when your operators are satisfied.

Does this replace our techs?

No, and anyone saying otherwise is selling something. It makes a good technician faster and gives a newer one context they'd take years to build. Someone still fixes the machine.

Beyond the dashboard

A dashboard tells you what's happening. It doesn't tell you what's coming.

A screen full of live tags tells an operator what is happening right now. It doesn't tell them what's about to happen, or why last Thursday's batch ran 4 % under. That gap is where we build.

SENSOR 10 ms HISTORIAN 2 yr history MODEL continuous ACTION before failure
Why us

Operators, not theorists.

  • We have held the P&L

    Our team has owned the P&L of a heavy industrial manufacturing plant and run day-to-day operations, not consulted on them from the outside.

  • Turnaround track record

    We have led EBITDA-focused operational turnarounds at manufacturing plants across North America.

  • SCADA and controls, not just software theory

    Our technical side comes from industrial controls and SCADA. It understands plant-floor systems rather than only software models, and that pairing is hard to replicate with an in-house IT hire.

  • Weeks, not fiscal quarters

    Enterprise software rollouts take twelve to thirty-six months of committees and change orders. We move from diagnostic to a working pilot in weeks, and you are never funding a first-year analyst's education.

How we work

Three phases. You know the cost and the deliverable before each one starts.

No open-ended time-and-materials. Every phase ends with something you own and can evaluate on its own.

01

Diagnose

An on-site assessment of your operations and your software. We walk the floor instead of building a slide deck, find where the data stops, and rank what we find by the return it would produce.

02

Build

The right mix of SCADA, automation, and analytics. Production monitoring, inventory tracking, predictive maintenance, document processing. Fitted to the systems you already run rather than a template forced onto your floor.

03

Deploy & support

Roll out with your team, measure the result in dollars and hours saved, and stay on as an ongoing technical partner. Adding capability later and working through problems with anything we've built.

What you hold at the end of each phase
01 DIAGNOSE 02 BUILD 03 DEPLOY & SUPPORT ROI-ranked findings A working system A measured result useful even if you stop here fitted to what you already run plus an ongoing partner STOP AFTER ANY PHASE AND YOU STILL OWN WHAT IT PRODUCED
Platform

What we build on

Standard, well-documented industrial tooling, nothing proprietary to us, nothing you can't hire someone else to maintain.

IgnitionInductive Automation
MQTT Sparkplug BCirrus Link modules · broker
Allen-BradleyControlLogix · CompactLogix
SiemensS7 · TIA Portal
OPC UA · ModbusDevice integration
PostgreSQL · MSSQLHistorian & reporting
Contact

Let's find your highest-ROI operational opportunity.

Start with a diagnostic assessment, no obligation, and findings ranked by the return they would produce. A short call is usually enough to tell whether there's a real project here. If there isn't, we'll say so.

Please tell us your name.
We need a valid email to reply to.
Thanks. Your message is in.

We reply to everything, usually within a business day.

About

Small on purpose. You talk to the people doing the work.

There's no account manager relaying messages to a delivery team three time zones away. You deal directly with the people who understand your operation and the engineers writing the code. Between us that covers plant operations, Ignition and SCADA development, process and model predictive control, increasing production, cutting downtime, inventory management, and the analysis and troubleshooting work that ties those together.

The team

Based in
Utah
Company
Wales Consulting Group
Focus
Plant operations
Background
Manufacturing leadership
Photo to come

Eric Wales

President

Eric brings hands-on manufacturing leadership to the intersection of operations, automation, and industrial technology. Before founding WCG he held manufacturing leadership roles with responsibility for plant operations, production performance, maintenance, continuous improvement, and financial results.

That experience shaped how he approaches an engagement: technology should solve a real operational problem and deliver measurable business value. He works with manufacturers to find opportunities to improve uptime, throughput, equipment reliability, process efficiency, and operational visibility, then works alongside the technical team to turn those needs into something buildable.

He founded WCG on a simple principle: understand the operation first, quantify the opportunity, then build the right solution.

  • Plant operations
  • Continuous improvement
  • Opportunity scoping
Based in
Utah
Company
Wales Consulting Group
Focus
Ignition · SCADA · Analytics
Degree
Mechatronics eng.
School
Utah Valley Univ.
Photo to come

Logan Marquis

Automation Engineer

Logan is a professional Ignition developer who has put real SCADA and analytics systems into production on manufacturing floors. Working installations running live equipment, not pilots that stalled after the demo. He works across the results on this site, from the throughput build through to the inventory system.

He holds a degree in mechatronics engineering from Utah Valley University . A discipline spanning mechanical, electrical, computer, control, and systems engineering. That breadth is the practical difference on a plant floor: he can follow a problem from the sensor on the machine, through the PLC logic, into the database, and out to the model that interprets it. Most integrators hand that chain to three different people and lose something at every handoff.

His work covers Ignition development, SCADA architecture, SQL databasing, model implementation and management, inventory optimization, and custom automation solutions.

  • Ignition
  • SCADA
  • SQL
  • analytics systems
  • Mechatronics
Company
Wales Consulting Group
Focus
Process control · MPC
Notable
$3.3M material savings
Photo to come

Austin Crawford

Controls & Automation Engineer

Austin builds control systems that pay for themselves. He builds the control systems behind work like our paint thickness result, where a model predictive control system . It calculates expected coating thickness from product dimensions and drives the machine directly, which eliminated a $140,000-a-month coating overrun.

That system has run in continuous production for two years and has saved $3.3 million in material so far, with the number still climbing. It is algorithmic control at the PLC and SCADA level rather than a black box, which is the point. He starts from what the process actually needs, not from a technology he wants to use.

  • Model predictive control
  • PLC
  • SCADA
  • Process control
How we operate

Four things we hold to

You own everything

Source, documentation, and architecture decisions are yours. No proprietary wrapper that makes leaving us expensive.

Fixed scope, fixed price

Each phase is quoted before it starts. If we get the estimate wrong, that's our problem to absorb, not a change order.

Operators review the screens

The people running the line see the interface before commissioning. Screens designed without them get worked around within a month.

We'll tell you no

If the problem doesn't need the system you're asking for, we'll say that. A smaller honest project beats an oversold one.

Contracting

Who you are actually hiring.

Wales Consulting Group. One contract, one invoice, one point of accountability. You work directly with the people who scope the job and the people who build it, because they are the same small team.

Because you own the source, the documentation, and the architecture, nothing about that arrangement locks you in. If you ever wanted to bring the work in-house entirely, the handover is the same either way.

After it's built

We don't disappear at commissioning.

Handover isn't the end of the relationship. Clients come back to add capability to what's already running, extend a system to another line or site, or work through a problem with something we built, and that support is available on an ongoing basis.

Some clients prefer a retainer for predictable access and a standing block of hours. Others would rather call when something comes up. Either works, and we'll talk through which fits how your plant actually operates rather than pushing you into a contract you don't need.

Because you own the source and the documentation, this is a choice rather than a dependency. You can bring the work in-house or hand it to someone else whenever you want to.

Start a conversation
Solutions / Ignition Development
Pillar 01

Ignition is the most capable platform in the industry. Most plants run a fraction of it.

We implement Ignition end to end, and more importantly, we build on it the way your process actually runs, instead of dropping in a template screen set and calling it a SCADA system.

Talk through your system
Typical architecture Illustrative
PLC / RTU METERS LEGACY / OPC DA ETHERNET/IP · S7 · MODBUS IGNITION GATEWAY OPC UA SERVER PERSPECTIVE SQL HISTORIAN LOCAL LLM LAYER analysis · troubleshooting · prediction
What it is

One platform instead of five that don't talk.

Ignition is an industrial application platform from Inductive Automation. It handles SCADA, HMI, MES, reporting, and IIoT connectivity in one system, rather than the usual arrangement where visualization, historian, and reporting are three separate products with three licences and three vendors to call.

The part that matters commercially: licensing is per server, not per tag or per client. Add 400 tags or 40 operators to a full gateway and the cost doesn't move. Most legacy SCADA platforms charge for both, which is why so many plants monitor far less than they'd like to. The instrumentation is affordable, the licence to look at it isn't. Worth knowing up front: Edge and Cloud editions license differently, and modules are priced individually, so we map that to your architecture before you buy anything.

It's web-based, so screens run in a browser on a control-room monitor, a tablet on the floor, or a phone at 2 a.m. without a separate mobile product. And it's built on standard tooling. SQL databases, Python scripting, and OPC UA, so your data is queryable by anything, not locked inside a proprietary format.

How we work with it

Customization is the whole point.

Ignition ships as a toolkit, not a finished product. That's its strength and the reason a bad implementation is so easy to spot. It looks like the demo.

01

Model your process, not a generic asset tree

User-defined types built around how your equipment is actually organized. Lines, cells, and units that match what your operators call them. Get this wrong and every screen, alarm, and report built afterward inherits the mistake.

02

Screens designed for the person running the line

High-performance HMI principles. Muted backgrounds, colour reserved for abnormal conditions, and the information density an experienced operator wants. Not a photorealistic tank on a black background.

03

Alarming that people don't learn to ignore

Rationalized alarms with real priorities, shelving, and escalation. A system that cries wolf 200 times a shift is functionally the same as no alarm system at all.

04

Built so the intelligence layer has something to work with

Structured, contextualized, historized data is what makes the other four pillars possible. A model can't reason about a tag called FLOAT_47.

The same sensor, named two ways Illustrative
Template build
  • FLOAT_47
  • FLOAT_48
  • BOOL_12
  • INT_09
  • FLOAT_51

Nothing here says what it measures, which line it belongs to, or what normal looks like. Every screen and report built on top inherits that.

Modeled
  • Line_02
    • Filler
      • Fill_Head_3
        • Barrel_Temp  188–202 °C

Same sensor. Now an operator, a report, or a model can reason about it without asking anyone what it means.

Industries

Same platform, very different builds

Manufacturing

OEE, downtime capture with reason codes, changeover tracking, and production scheduling against real line rates.

Water & Wastewater

Distributed sites over cellular, store-and-forward for dropped links, regulatory reporting, and after-hours alarm callout.

Oil & Gas

Remote wellsite monitoring, MQTT over constrained bandwidth, tank levels, and automated production accounting.

Mining

Fixed plant monitoring, conveyor and crusher health, and energy tracking across process stages.

Common questions

What plants ask about Ignition.

0 PLCs
PLCs we typically need to replace. Ignition reads what you already have.
On most projects we never touch controls
Do we have to replace our PLCs?

No. Ignition sits above the control layer and reads from what you already have. Allen-Bradley, Siemens, Modbus devices, OPC UA servers. The PLC logic keeps running exactly as it does today. In most projects we don't touch controls at all.

Can it run alongside our existing SCADA?

Yes, and that's often the safest way to start. Ignition reads the same data in parallel, you evaluate it against the live system with no production risk, and you cut over only when your operators are satisfied. Nobody has to bet a plant on a first impression.

What does Ignition actually cost?

Licensing is Inductive Automation's, not ours, and it's published on their site. A server licence plus whichever modules you need, with unlimited tags and clients. We'll tell you honestly what your build needs and what it doesn't. We don't resell licences or take a margin on them.

We already have Ignition but it's not doing much. Can you help?

That's a common starting point, and usually more straightforward than a greenfield build. Typically the gateway is fine and the tag structure is the problem. We'd start with an assessment before proposing anything.

The foundation everything else sits on.

Analysis, troubleshooting, and prediction all depend on data that's structured properly at this layer. It's worth getting right first.

Start a conversation Or just email us
Solutions / Local LLM
Pillar 02

A model that knows your plant. Running on hardware you own.

We install and configure site-specific language models that continuously read your production data and your PLC programming. It runs on your GPU server or inside your own cloud tenancy. Your process data never goes to a third party.

Ask about deployment
Where the data goes Illustrative
YOUR NETWORK BOUNDARY PRODUCTION DATA PLC LOGIC MAINT. HISTORY LOCAL LLM ON-PREM GPU OPERATORS ON-PREM OPTION · NO EGRESS
Why local

Most plants can't send process data to a public API. So we don't.

Your PLC logic is the accumulated knowledge of everyone who has ever worked on that line. Your production data shows your yields, your rates, and your problems. For a lot of operations, anything with defence work, food safety documentation, competitive process IP, or a cautious corporate IT group, uploading that to a vendor's cloud is simply not on the table.

It's also often not practical. Plants have bad connectivity, remote sites have worse, and a model that stops working when the WAN link drops is a model your team stops trusting.

So we deploy the model where you control it. On-premise is the strongest version. A GPU server we spec and install in your rack can run fully air-gapped, nothing egresses, and there's no per-token bill because there's no model vendor involved. You pay for hardware and power. Your own cloud tenancy is the alternative when your IT group prefers it: your data stays under your contracts and controls rather than going to a model vendor's API, though it is your cloud account and your GPU-hour bill. We'll be straight with you about which one fits.

How we set it up

From bare hardware to something your team actually asks questions of.

01

Spec and install the hardware

We size the GPU server against your data volume and how many people will use it, then install and configure it. If you'd rather run in your own Azure or AWS tenancy, we deploy there instead. The architecture is the same, the data still never leaves your control.

02

Feed it your plant

Live and historical production data from the Ignition historian, exported PLC logic and tag documentation, alarm history, and maintenance records. This ingestion is continuous. The model sees today's production, not a snapshot from commissioning day.

03

Ground it so it doesn't guess

Answers are grounded in retrieved plant data with the source shown, so an operator can check where a claim came from. A model that invents a setpoint is worse than no model, and this is the part most demos skip.

04

Put it where the work happens

The interface lives inside Ignition Perspective. The same screens your operators already use. No separate app, no second login, no tab-switching during a fault.

Choosing where it runs
 On-premise GPUYour cloud tenancy
Process data leaves your networkNoYes. Into your own cloud account
Can run air-gappedYesNo
Keeps working if the WAN dropsYesNo
Who owns the hardwareYou doYour cloud provider
Ongoing costPower and eventual refreshGPU-hours, metered
Model vendor sees your dataNoNo

Both keep your data away from a model vendor's API. Only one keeps it inside the building. We'll tell you which one your situation actually needs.

What you get

Deliverables

  • Hardware specification and installation. Sized for your load, racked and configured, or deployed into your own cloud tenancy.
  • Model selection and tuning. Chosen for your hardware and your use case, tuned on your terminology and equipment names.
  • Continuous ingestion pipeline. Production data, PLC logic, alarm and maintenance history, kept current automatically.
  • Perspective interface. Built into the screens your team already uses.
  • Access control. Role-based, so what an operator can ask differs from what an engineer can.
  • Documentation and handover. How it works, how to maintain it, how to extend it. You own the whole thing.
Common questions

What IT asks before it approves this.

0 bytes
of process data leave the building on an on-premise deployment.
Air-gapped and demonstrable
Does any of our data leave the site?

With an on-premise deployment, no. The model runs on hardware inside your network, it can run completely air-gapped, and we'll demonstrate that with your network team watching. If you choose to run in your own cloud tenancy, the data does leave the building, but it goes to your cloud account under your contracts and controls, not to a model vendor's API. Those are genuinely different promises and we won't blur them.

What hardware do we need?

It depends on data volume, how many concurrent users, and how fast you want responses. We spec it against your actual requirements rather than selling you the biggest box available. For most single-site deployments this is one server, not a rack.

What happens when better models come out?

The model is a component, not the whole system. Your ingestion pipeline, grounding, and interfaces stay; we swap the model underneath. That's a deliberate design decision. This field moves fast and you shouldn't have to rebuild to keep up.

Will it make things up?

That's the real risk with this technology, and it's the failure mode we design against hardest. Answers are grounded in retrieved plant data with sources shown, and the system is built to say it doesn't know rather than fill a gap. We'd rather it be quiet than confidently wrong.

Do we need Ignition first?

Practically, yes. Something has to be capturing and structuring the data. If you already have a solid historian we can work with that. If your data is scattered across islands, that's the first pillar, and we'd start there.

This is the engine under the next three pillars.

Analysis, troubleshooting, and prediction are all things the local model does once it understands your plant.

Start a conversation Or just email us
Solutions / Production Analytics
Pillar 03

You're already collecting the data. This is where it starts paying for itself.

Continuous performance trending, reports written on request instead of requisitioned from IT, and cross-line analysis that turns a historian full of numbers into decisions people actually make.

Start a conversation
Line performance · 14-day trend Illustrative
TARGET 85% 3 DAYS FLAGGED
The problem

Most historians are write-only.

Plants collect enormous amounts of data and look at almost none of it. The reason isn't laziness. It's that getting a specific answer out means someone building a query, exporting to Excel, and spending an afternoon on it. So the question gets asked once, in a meeting, and then quietly dropped.

What gets watched is whatever fits on the dashboard someone built two years ago. Everything else. The shift-over-shift comparison, the correlation between ambient temperature and reject rate, the reason Line 3 underperforms Line 4 on the same product. Stays theoretically available and practically invisible.

With the local model already reading your production data, the cost of asking a question drops to near zero. That changes which questions get asked, and that's the actual value.

What it does

Three things, continuously.

01

Trends performance without being asked

Throughput, quality, energy per unit, and cycle time tracked continuously against target, with the model flagging what moved and, where the data supports it, what moved with it. It does not just say Tuesday was bad, it says what else was different about Tuesday.

02

Writes the reports you actually want

Ask in plain language, "compare reject rate by shift on Line 2 for the last quarter", and get the report, with the query behind it visible so an engineer can verify it. Anything useful becomes a scheduled report that lands in an inbox every Monday.

03

Compares things nobody had time to compare

Line against line, shift against shift, this month against the same month last year, one site against another. The comparisons that expose real opportunities are usually the ones too tedious to build by hand.

Throughput by line and shift · 14 days Illustrative
LINE 01 · SHIFT A
LINE 01 · SHIFT B
LINE 01 · SHIFT C
LINE 02 · SHIFT A
LINE 02 · SHIFT B
LINE 02 · SHIFT C
LINE 03 · SHIFT A
LINE 03 · SHIFT B
LINE 03 · SHIFT C
LINE 04 · SHIFT A
LINE 04 · SHIFT B
LINE 04 · SHIFT C

Twelve comparisons on one screen. The one that matters is Line 03 Shift B. Drifting down for two weeks while every other cell held. Nobody builds that report by hand, which is exactly why nobody catches it.

The smart factory part

A plant that reports on itself

"Smart factory" usually means a dashboard. We mean something narrower and more useful: the plant tells you what changed, before you thought to ask.

Daily brief

What ran, what didn't, what's different from yesterday. Ready before the morning production meeting starts.

Exception alerts

Notification when a metric moves outside its normal range, with the context needed to judge whether it matters.

Ad-hoc answers

Any question about production history, answered in seconds by whoever needs it, no query-writing, no waiting on an engineer.

Compliance reporting

Regulatory and customer reports generated from source data on schedule, in the format the recipient requires.

Common questions

What people ask about the numbers.

12 → 1
comparisons on one screen, and only one of them needed attention.
Line 03, Shift B. Two-week drift
How do we know the numbers are right?

Every answer shows the query and the source data behind it. An engineer can verify any figure before it goes in front of a customer or a regulator. We treat unverifiable output as a defect, not a limitation.

How much history do we need?

Trending is useful almost immediately. Seasonal patterns and year-over-year comparison obviously need a year. If you have existing historian data we can usually bring it in, which gives you a running start.

Can it work with data outside Ignition?

Yes. ERP, LIMS, quality systems, spreadsheets people maintain by hand. Some of the most valuable correlations cross those boundaries, and often nobody has ever looked at them together.

Who ends up using this day to day?

In practice: plant managers for the daily brief, process engineers for the ad-hoc questions, and quality for scheduled reporting. It's worth deciding this early. It shapes how we build the interface.

Analysis tells you what happened. Next is what to do about it.

Start a conversation Or just email us
Solutions / Guided Troubleshooting
Pillar 04

Your best troubleshooter is whoever wrote the PLC code. The model reads it too.

We give the local model the full context of how your PLC was programmed alongside your production history. When a fault hits at 2 a.m., that context is the difference between a three-hour hunt and a first-guess fix.

Start a conversation
Fault · ranked causes Illustrative
FAULT · LINE_02 · FILLER_JAM · 02:14:07 01 · INFEED CONVEYOR SPEED DRIFT matches 4 prior jams · drive current +12% over 6 days HIGH 02 · PHOTOEYE ALIGNMENT rung 214 timeout · last serviced 89 days ago MED 03 · UPSTREAM PRODUCT CHANGEOVER recipe changed 02:02 · 12 min before fault LOW
The problem

The knowledge is in one or two people's heads, and they aren't on nights.

Every plant has someone who can walk up to a stopped line, look at it for ninety seconds, and know what's wrong. That person is enormously valuable, and they are also a single point of failure. On holiday, on days, or three years from retirement with nobody trained behind them.

Everyone else works the problem the long way. Read the alarm, pull up trends, find the ladder logic, work out what rung 214 was waiting for, check whether anything changed upstream. On a night shift, with production stopped and pressure building, that's a long time to be reading code.

The model has already indexed all of it. Your exported logic, tag documentation, and fault history, and pulls up the relevant rungs the moment a fault fires. That's the context your best troubleshooter carries in their head, made available to whoever's on shift.

How it works

What happens when a fault fires.

01

It reads the fault in context

Not just the alarm text. The rung that threw it, the tags that rung depends on, and what those tags were doing in the minutes beforehand.

02

It checks what else was different

Recent recipe changes, upstream conditions, drive currents trending up over days, the maintenance done last week. Faults usually have a history, and it's rarely in the alarm log.

03

It ranks causes and shows its reasoning

A short ordered list with the evidence behind each one. Trends, prior occurrences, the specific logic involved. Your technician judges it. The system doesn't get a vote, and it doesn't pretend to be certain when it isn't.

04

It learns what actually fixed it

The resolution gets captured and feeds the next occurrence. Over time the plant accumulates institutional knowledge in a form that doesn't retire.

Same fault, same technician Illustrative
WITHOUT THE SYSTEM 1234 1 Read the alarm 0–152 Pull up trends 15–553 Read the ladder logic 55–1404 Fix it 140–180 WITH THE SYSTEM 123 1 Ranked causes 0–42 Verify 4–203 Fix it 20–45 04590135180 MINUTES FROM FAULT

The hunt is the expensive part, not the repair. Most of a night-shift outage is spent working out which thing broke, and that is the part the PLC context collapses.

Maintenance tooling

Custom tools that make your maintenance team better at their jobs.

Troubleshooting support only helps if it reaches the person holding the wrench. So we build the tools around it, custom-made for how your maintenance department actually runs rather than a generic CMMS bolted on the side.

That means job aids that pull up the right drawing and the right procedure for the fault in front of them, history for that specific asset rather than that asset class, and a record of what was tried last time. Where you already run a CMMS, we integrate with it. Where you don't, or where yours is a spreadsheet nobody updates. We build it into Ignition.

The goal isn't to tell technicians what to do. It's to make sure they aren't working blind because the person who knew this machine left in 2019.

What we build

Deliverables

  • PLC logic ingestion. Your programming, tag documentation, and rung comments made available to the model as context.
  • Fault-triggered analysis. Ranked probable causes with visible reasoning, surfaced on the alarm screen.
  • Asset-level history. What's failed on this machine, when, and what fixed it.
  • Guided procedures. The right drawing, the right steps, for the fault at hand.
  • CMMS integration or custom tooling. MaintainX, Fiix, SAP PM where you have one; built in Perspective where you don't.
  • Resolution capture. The feedback loop that makes the next occurrence faster.
Common questions

What maintenance managers ask first.

180 → 45
minutes on the same fault, with the same technician.
Measured on the same technician
Is this going to replace our maintenance techs?

No, and any vendor telling you otherwise is selling something. It makes a competent technician faster and gives a newer one access to context they'd otherwise take years to build. Someone still has to diagnose and fix the machine.

What if it's wrong?

It will sometimes be wrong, which is why it ranks possibilities with evidence rather than announcing an answer. Your technician makes the call. The system is a well-informed second opinion, and we build it to be honest about uncertainty.

Do you need our PLC source code?

Yes, that context is what makes this pillar work, and it stays on your hardware inside your network. Worth flagging early: Rockwell code exports cleanly, Siemens takes more work, and vendor-locked blocks may not come out at all. It changes what we can promise. If your code is vendor-locked or you don't hold the source, tell us early. It changes what's achievable here.

What about equipment we didn't program?

OEM skids and black-box equipment are harder because the logic often isn't available. We can still use production data, alarm history, and prior resolutions. Less context, but usually still better than starting cold.

Better still: don't have the fault at all.

Start a conversation Or just email us
Solutions / Predictive Maintenance
Pillar 05

The failure that stopped your line on Friday was visible three weeks earlier.

Equipment rarely fails without warning. It fails without anyone watching the warning. Everything in the previous four pillars feeds this one: spotting degradation while it's still a scheduled repair instead of an emergency.

Start a conversation
Degradation · detection lead time Illustrative
FAILURE THRESHOLD DETECTED · 3–4 WEEK WINDOW
The problem

Threshold alarms tell you it already broke.

A high-temperature alarm at 205 °C fires when the bearing is already failing. The useful information was in the six weeks it spent creeping from 188 to 199. A change no threshold catches, because at no point was any single reading out of range.

The alternative most plants use is time-based maintenance: replace it every six months whether or not it needs it. That works, and it's expensive in both directions. You throw away good components, and you still get failures from the ones that degrade faster than schedule.

Condition tells you more than the calendar. A model watching the actual signature of your equipment knows the difference between a motor that runs warm in August and a motor that's on its way out.

How it works

Four steps from signal to work order.

01

Establish what normal looks like

Per asset, not per asset class. Two identical pumps in different duties have different signatures, and treating them the same is why generic predictive tools produce so much noise.

02

Watch for departure from it

Slow drift across correlated signals. Current, temperature, vibration where instrumented, cycle time. The pattern matters more than any single reading, which is exactly what thresholds can't see.

03

Estimate the runway honestly

Not a false-precision failure date. A realistic window and a confidence level, so planning can decide between next weekend's shutdown and waiting for the scheduled outage. Overstated certainty destroys trust the first time it's wrong.

04

Turn it into work someone actually does

A work order in your CMMS, or a task in the maintenance tools we build, with the evidence attached, so the technician knows why they're there and what to look at first.

Where predictive coverage pays for itself Illustrative
HIGHEST RETURN Rotating equipment best-understood signatures Conveyance stops everything downstream Critical single points long lead time on parts Thermal process fouling shows early HIGH LOW CONSEQUENCE OF FAILURE RARE FREQUENT LIKELIHOOD OF FAILURE
Where it fits

Assets worth watching

Coverage costs money to build, so it belongs where failure is expensive, disruptive, or dangerous. We would rather scope a pilot on a handful of assets than sell you blanket coverage.

Rotating equipment

Pumps, motors, fans, gearboxes. The best-understood degradation signatures and usually the fastest payback.

Conveyance

Belts, drives, and gearboxes where a failure stops everything downstream of it.

Thermal process

Heaters, chillers, and heat exchangers where fouling shows up as efficiency loss long before failure.

Critical single points

Anything with no redundancy and a long lead time on replacement parts. Highest value, easiest business case.

Common questions

What reliability engineers push back on.

3–4 weeks
of warning before a threshold alarm would have fired.
A scheduled swap, not a stoppage
Do we need to add vibration sensors?

Sometimes, but start without them. Drive current, temperature, cycle time, and run hours are already in your PLC and carry more signal than most people expect. We'd rather prove value on existing instrumentation first and add sensors where the case is clear.

How much history before it's useful?

Enough to establish a baseline, typically a few months of normal operation per asset. If you have historian data going back further, that shortens it considerably. Assets that have already failed once are especially useful, because you know what the run-up looked like.

What's a realistic hit rate?

Depends entirely on the asset and the instrumentation, and anyone quoting you a percentage without seeing your plant is guessing. We'd rather scope a pilot on a handful of critical assets and measure it than promise a number we can't stand behind.

What about false alarms?

The real failure mode of predictive maintenance. Cry wolf twice and maintenance stops reading the alerts. We tune conservatively, show the evidence behind every flag, and would rather miss a marginal case than burn credibility on noise.

Five pillars, one system.

Each one is useful alone. Together they compound, and every one of them is tailored to how your plant actually runs.

Start a conversation Or just email us