Shop-Floor Copilots: On-Prem RAG for Maintenance and SOP Knowledge

Overview

The industrial copilot — a natural-language assistant that answers “what is the torque setting for bolt B?” or “how do I clear error 402?” from a plant’s own SOPs, manuals and maintenance history — is manufacturing’s fastest-spreading GenAI use case in 2026, with vendor ecosystems from Siemens’ Industrial Copilot to Tulip and ABB integrations normalising the pattern. Under the hood it is a domain RAG system with hard requirements the office version doesn’t have: multilingual voice on a noisy floor, resilience to plant-network isolation, and source data (maintenance logs) that is jargon-dense and inconsistently written. A single 2–4 GPU on-prem server covers most plants; the hard work is the data pipeline. This article sizes both.

Architecture: RAG with an industrial accent

The core follows the enterprise RAG recipe — hybrid retrieval, reranking, grounded generation with citations — over a corpus of SOPs, OEM manuals, P&IDs, quality procedures and the maintenance ledger, per the patterns in our RAG reference architecture. Two industrial extensions matter. Structured-data tools: torque tables, spare-part codes and error-code matrices answer better through direct lookup functions than through chunk retrieval — give the model tools, not just documents. And visual grounding: technicians photograph nameplates and defects; a compact vision-language model on the same server turns images into queries. Answer citations back to the source paragraph are non-negotiable — a confident wrong torque value is a safety incident, not a UX bug.

The data pipeline is the product

Research and practitioner reports agree on the failure mode: LLMs exposed to raw maintenance exports — jargon, abbreviations, inconsistent notation — hallucinate. The remedy is a preprocessing pipeline: normalise ERP/CMMS exports into clean tables, build a plant-specific technical dictionary (abbreviations, machine aliases, local slang), and extract problem→cause→fix triples with LLM prompting before anything is indexed. This is a batch GPU workload — days of small-model inference over years of records — that reuses the serving hardware off-peak, and it repays itself twice: better copilot answers now, and a structured failure-knowledge base that outlives any single tool. Budget it as half the project, because it is.

Floor requirements the office version skips

Voice first: gloved hands and noisy lines make typing marginal — on-server ASR (Whisper-class, noise-robust, validated on Indian-accented and code-switched speech, per the same evidence standards as our clinical scribe article) plus TTS turns the copilot hands-free. Multilingual: the workforce reads Hindi and regional languages more comfortably than English manuals — open multilingual models and translated snippets are a requirement, not a roadmap item. Resilience: plants run when WANs don’t; per-plant serving (or at least a cached fallback tier) keeps the copilot alive through outages, which is also the OT-security posture — plant networks are segmented, and an on-prem copilot respects that boundary where a SaaS endpoint fights it.

Sizing and rollout

Query traffic is human-paced and bursty: a 500-worker plant generates tens of concurrent sessions at shift change, trivial for a batched 8–13B model plus embedding/rerank/ASR models on a 2–4 GPU (L40S-class) server — the same consolidation profile as the air-cooled enterprise server class. Multi-plant groups choose hub-and-spoke: a central server for the shared corpus and heavy batch jobs, thin per-plant nodes for latency and outage resilience. Rollout sequencing that works: start with one high-value crew (maintenance), index their documents plus two years of cleaned logs, measure deflected escalations and mean-time-to-repair, then widen. Plants that skip the measurement step end up with a demo, not a tool.

Deployment tiers

Frequently asked questions