AI for PLC fault diagnosis: cited answers on the plant floor

The plant-floor diagnosis workflow, walked in order

A line goes down. The HMI shows a fault code. A technician has minutes, not hours, to isolate the cause before the downtime rolls through the standup meeting. The workflow below is what a good technician walks every time. The AI accelerates it.

1. Read the fault code from the HMI

   The controls engineer or maintenance tech notes the fault code, the asset, the line, and the timestamp. This is where the AI becomes useful: a chat interface at a shop-floor terminal, an iPad on a mobile cart, or a workstation in the maintenance shop takes the code, the asset tag, and any observed symptoms as input.

2. Look up the fault code in the vendor manual

   The AI pulls the specific passage from the equipment manual — Allen-Bradley, Siemens, Mitsubishi, Beckhoff, Omron, or any other vendor whose manuals are indexed — and returns the definition, the probable causes listed by the OEM, and the recommended diagnostic checks, cited back to the exact page of the manual. No context-switching to a support portal; no keeping the PDF open on a second monitor.

3. Cross-reference recent work orders on the same asset

   The same query pulls the last several work orders on the same asset and the last several instances of the same fault code anywhere on the site. The AI summarizes what the previous technicians did, what fixed the fault, what did not, and any notes about intermittent behavior. Every referenced work order is linked back to the CMMS record.

4. Check the alarm and shift-log context

   Alarm history for the last shift and the shift-log entries for the line surface any related pre-conditions — a temperature excursion an hour before the fault, an operator note about a recurring stall on a specific carrier, a vibration alarm from the same drive. The AI weaves these into the diagnostic hypothesis.

5. Get a cited answer with next steps

   The output is a diagnostic hypothesis with confidence, an ordered list of checks (starting with the fastest to disprove the most likely cause), and citations back to every source document the model used. The technician can click through to the manual page, the work order, or the shift-log entry to verify anything they want to verify.

6. Walk the checks and close the work order

   The technician runs the checks in order, confirms the cause, clears the fault, and closes the work order in the CMMS with a free-text note. That closeout note becomes part of the corpus the AI searches on the next occurrence of the fault. The organization gets smarter every time a work order closes.

Practitioners who have diagnosed faults on a controls system will recognize it as the same sequence they run today. The mental model stays the same; the retrieval friction between steps collapses.

The corpus: manuals, PLC docs, work orders, shift logs

Retrieval earns its place on the plant floor because the answer the technician needs never sits in one place. It is scattered across the OEM's equipment manual, the controls team's PLC documentation, the CMMS work-order history, the shift logs, and the vendor's application notes. Ordinary search forces the technician to check each source in turn. Hybrid vector + keyword retrieval over a unified corpus lets the model assemble the answer from all of them at once and cite each source.

A typical Onsite AI plant deployment indexes OEM manuals for the PLCs, drives, servos, VFDs, sensors, HMIs, robots, and process equipment on the line, alongside PLC program prints and tag databases, alarm and event history, shift logs and handover notes, plant SOPs, and OEM application notes and service bulletins. Vector similarity handles meaning; keyword search handles exact strings — fault codes, part numbers, asset tags — so a query like "F-52014 on line 3 conveyor drive" hits both the semantic neighborhood of drive faults and the exact-string match for that code and asset.

The largest untapped source in that corpus, in most plants, is five to ten years of free-text CMMS closeout notes — the paragraph the technician wrote when they finally cleared the fault at 03:12 on a night shift. Structured CMMS fields (asset, failure code, resolution code) are already searchable through the CMMS's own reports. The free-text notes, where the actual diagnosis lives, are not.

Onsite AI's CMMS integration reads records — work orders, closeout notes, PM histories, asset registries — through whatever path the CMMS exposes: a scheduled read against the database, the CMMS's REST or SOAP API, or a nightly export to a shared folder. Maximo, SAP PM, Fiix, eMaint, UpKeep, MaintainX, Limble, or a home-grown work-order database — the existing CMMS stays in place, and the maintenance planners keep working the way they already work. Free-text closeout comments are chunked, embedded, and indexed with the structured fields as filterable metadata. A note like "Replaced encoder on servo axis 2, was intermittently reporting F-24 under load, root cause was a chafed cable inside the drag chain" becomes retrievable the next time F-24 fires on any servo axis on any line. Cited answers point at the specific work-order number so the technician can open it in the CMMS and read the full record. New closeout notes flow back in on the sync schedule, and the diagnosis the crew wrote yesterday is available to the crew that hits the same fault today.

The effect: the plant's tribal knowledge stops being locked in one technician's memory of the last time they saw the fault, and becomes retrievable by every technician on every shift.

Schematics, wiring diagrams, and P&IDs

A lot of plant-floor documentation is visual, not textual. Wiring diagrams, ladder-logic printouts, hydraulic and pneumatic schematics, P&IDs, marked-up as-built drawings, and equipment general-arrangement drawings all live as PDFs, scanned images, or CAD exports on a plant file server. Text-only search misses them entirely.

Onsite AI's Enterprise RAG tier includes vision-language capability that runs on the same GPUs as the language model. Visual assets are indexed alongside the textual corpus, so a query about a specific fault code can pull the wiring diagram for the affected loop and the manual passage that defines the code in the same cited answer. What that lets a technician do in practice:

• Query a schematic by what is on it. Ask "which relay drops out first when the E-stop on line 4 opens" and the model can pull the relevant portion of the wiring diagram plus the vendor manual page describing the safety chain — cited to both.
• Cross-reference marked-up as-builts. Redlines on drawings are a first-class source. The model reads them the same way it reads a clean drawing, and gives the technician a heads-up when the redline contradicts the manual.
• Find the right ladder-logic rung. Ladder-logic printouts from PLC programming software are readable as text; scanned printouts are readable via vision. Queries can pull the specific rung tied to a fault-latching bit.
• Point at the loop on the P&ID. Process and instrumentation diagrams are indexed so a reliability engineer can query by loop tag and get the loop pulled up next to the relevant SOP and the last few work orders touching that loop.

Vision-language on drawings shortens the time between the question and the drawing being in front of a controls engineer. The engineer still owns the interpretation; the search bar just stops being the file server.

Downtime and OEE analysis: from single faults to recurring modes

Everything above is about diagnosing a single fault fast. One layer up, the reliability team is trying to identify the recurring failure modes that own most of the lost production hours across the fleet. The same corpus that answers "why did F-52014 fire on line 3 tonight" answers "which failure modes are eating our OEE."

The reliability-engineering questions the model is designed to help with:

• Which assets have the most repeat interventions on the same fault code this quarter? Retrieval pulls the work-order history, groups by asset and fault code, and summarizes what was tried and what fixed the fault each time — a shortcut to the top of the reliability team's backlog.
• Which OEE loss bucket owns most of the gap on a given line last month? The model looks at downtime logs, availability data, and the work orders tied to those downtime events, and surfaces the categories — availability, performance, quality — with the biggest contribution to the gap.
• What is the recurring failure mode behind the top downtime driver on a specific line? The AI pulls the work orders and CMMS closeout notes associated with the largest downtime bucket, clusters them by cause, and returns the recurring mode — cited to the underlying work orders so the reliability engineer can verify the pattern.
• Where should PM scope grow — and where should it shrink? Comparing PM completions with the corrective work orders that followed surfaces PMs that aren't preventing failures and PMs that are catching problems that would otherwise become downtime. Both directions inform the next PM optimization cycle.
• Which failure modes are cross-cutting the fleet? The same encoder cable failure that showed up on line 3 might also be showing up on line 5 and the packaging line — the AI can surface the pattern across assets that share a vendor or design, not just within an asset.

What the model removes is the multi-day corpus-scanning slog that today sits between the question and the analysis — the part where a reliability engineer pulls hundreds of work orders into a spreadsheet by hand and reads through them. With the corpus already indexed and citable, that work is done by the time the engineer starts thinking.

Capturing the senior technician's answer for the junior technician

The pressure sitting behind most maintenance-diagnosis initiatives is workforce turnover. The senior controls technicians who know which asset always throws which fault on hot days are retiring, and the technicians replacing them haven't seen the fault before. When a senior technician walks out the door for the last time, the fault history they carry in their head walks out with them.

Tribal-knowledge capture in this context is the deliberate ingestion of the artifacts that carry that knowledge. The obvious sources: the SOPs and work instructions the senior engineer wrote — including the informal ones that never made it into the QMS — and the shift-log entries logged during the shifts they worked, often the most compact record of the failure modes they saw. The less-obvious sources tend to matter more. Redlines on drawings and manuals — the marks that say "this is wrong, do it this way" — read through vision-language and indexed alongside the clean copy. Tuning notes and setpoint history in text files, spreadsheets, and photos of the whiteboard where the senior technician recorded which knob to turn under which condition.

Some plants go a step further and deliberately sit senior engineers down for an afternoon to record them walking through the top failure modes on their line. Transcripts become part of the corpus. After ingestion, when a junior technician asks about a fault, the answer weaves the OEM's official cause list with the senior engineer's recorded experience — cited to both. The junior technician doesn't have to know which SOP or which shift log had the right answer. The retrieval finds it.

Running inside the air-gapped OT network

Plant-floor OT networks are isolated from IT by design. PLC code, drawings, work orders, and shift logs stay inside the OT perimeter, and OT security teams veto anything that opens an egress path from the plant floor to the internet. Onsite AI is designed for exactly this environment.

The deployment posture, in short:

• Everything runs inside the OT VLAN. The inference plane, retrieval pipeline, embedding models, vector store, keyword index, and audit trail all live on plant-owned hardware inside the OT boundary. Nothing calls out to the public internet in normal operation.
• Signed offline update bundles. Model, runtime, and software updates arrive as signed offline bundles the plant applies on its own change window — the same posture the plant already uses for PLC firmware updates and SCADA patching. No forced upgrades.
• Enclave-local identity. SSO binds to the plant's own Active Directory or LDAP; RBAC follows the same groups the CMMS and SCADA HMI use; MFA uses enclave-local tokens. The AI lives inside the plant's existing access model, same as everything else on the OT VLAN.
• Audit logs stay in-enclave. Every authentication, every query, every retrieved document is logged locally. Log forwarding to the SIEM happens on the plant's terms.
• Read-only against production systems. The AI reads from the CMMS, historian, and file server. Writes back to production PLCs or SCADA are out of scope; the control system remains the system of record.

The deployment mechanics — how the update bundles are produced, signed, verified, and applied; how RAG operates without internet; how identity and audit are wired inside the enclave; and the failure modes teams hit — are covered in depth in the sibling reference, air-gapped LLM deployment: a practitioner's reference.

What the plant floor needs on the rack

Hardware sizing for plant-floor deployments follows the same rule as any air-gapped LLM install: the sizing target is concurrent users at the target context length. In a maintenance and reliability context, the concurrent users are the controls engineers, reliability engineers, maintenance planners, and shop-floor technicians who query the system during a busy shift.

The entry tier is a single 4U dual-GPU server that racks next to the plant's existing SCADA and historian infrastructure and supports a busy shift's worth of controls engineers, reliability engineers, and planners querying at once; plants running multiple lines under one roof, or multiple sites sharing a common corpus of manuals and PLC docs, scale up to a dual-node HA cluster. Every number behind that sizing — what drives VRAM, the GPU comparison, quantization tradeoffs, and the per-tier spec sheet — lives in the LLM hardware requirements buyer's guide. A Discovery & Scoping Engagement writes the sizing to match the plant's actual user count, corpus, and concurrency profile.

Frequently asked questions

How does AI-powered PLC fault diagnosis actually work on the plant floor?

A technician queries the fault code from an HMI or a mobile chat client as soon as the alarm surfaces. Retrieval runs against the plant's own corpus of equipment manuals, PLC documentation, prior work orders on the same asset, alarm history, and closeout notes. It returns a cited answer that names the manual page, the specific work orders, and the CMMS comments the model drew from. The technician walks the model's suggested checks, applies the fix, and closes the ticket in the CMMS. A concrete example on this page traces an F-24 encoder-feedback fault on a packaging-line servo axis end-to-end. Every hop stays inside the plant's OT network.

How does the system integrate with existing CMMS systems?

Onsite AI reads from the customer's existing CMMS on scheduled pulls from the database or its integration API. That covers Maximo, SAP PM, Fiix, eMaint, UpKeep, MaintainX, Limble, and home-grown work-order databases. Work orders, closeout notes, PM schedules, and asset histories are chunked and embedded alongside equipment manuals and PLC documentation. Free-text technician notes, historically the loudest silent knowledge in the plant, become searchable with cited answers. The CMMS stays where it is; there is no schema change and no rip-and-replace. When the AI surfaces a diagnosis, the technician still closes the ticket in the CMMS the same way they always have.

Does this run inside an air-gapped OT network?

Yes. The inference plane, retrieval pipeline, embedding models, vector store, and audit trail all run inside the plant's OT VLAN. Model and software updates arrive as signed offline bundles applied on the plant's change window, so no component reaches out to the public internet. PLC code, drawings, work orders, and shift logs stay inside the plant. The air-gapped LLM deployment reference on this site walks the bundle format, cryptographic verification, and rollback shape in more depth.