FIELD SERVICE COPILOT

The Business Problem

Where the work happensWhat the vehicle already knows

Maintenance technicians work in factories, oil and gas plants, mines, power stations, water treatment sites and remote installations. In most of them connectivity is unreliable. In many of them it is deliberately absent, because the operational network is air gapped or segmented as a matter of security policy.

That makes a cloud hosted copilot impractical precisely where expert help is most valuable. The assistant that works beautifully in a demonstration on the corporate network is unavailable in the plant room.

Why cloud assistants do not solve it

Phone a senior engineer. Who may be in another time zone, on another site, or unavailable.
Search paper or PDF manuals. Hundreds of pages, often for a slightly different equipment revision.
Guess from experience. Which works well for experienced technicians and poorly for new ones.
Escalate. Which converts a thirty minute inspection into a multi day specialist visit.

The consequence is that mean time to repair is driven by who is available rather than by what is actually wrong.

Where the cost sits

Cost	Driver
Unplanned downtime	Diagnosis time, not repair time, is usually the larger share of the outage.
Specialist travel	Escalations that turn out to be routine once someone experienced looks.
Repeat visits	First time fix rate falls when the technician cannot confirm the cause on site.
Unnecessary parts	Components replaced on suspicion rather than on evidence.
Expert time	Senior engineers spending their day answering the same questions by phone.
Knowledge loss	Decades of failure mode experience leaving with retirement.

The Requirement in One Sentence

Give the technician standing in front of the machine a grounded first hypothesis, drawn from live sensor readings, the equipment documentation and this asset's own incident history, with the manual section cited, and with no network of any kind.

Solution Overview

A Kria KR260 in a rugged enclosure, carried to the asset or installed in the plant room. It reads live state through the plant’s own protocols, searches a knowledge base built at commissioning, correlates the two, and answers out loud with citations. Nothing about the plant leaves the plant.

Layered architecture

Layer 6 Interaction

Voice in, voice and screen out

Industrial microphone and rugged tablet, usable with gloves and hearing protection.

Layer 5 Reasoning

4-bit quantized language model

Correlates live readings against documented failure modes and prior incidents.

Layer 4 Knowledge

Local retrieval over the plant corpus

Manuals, diagrams, SOPs, maintenance logs, sensor specifications and incident history.

Layer 3 Live state

Read only plant acquisition

Vibration, temperature, pressure, controller state and historian trend.

Layer 2 Acceleration

Fabric and DPU offload

Audio front end and dequantization, keeping the cores free for orchestration.

Layer 1 Platform

KR260 in rugged enclosure

Sealed, conduction cooled, certified for the area classification where required.

The hard boundary

The copilot observes. It does not write. There is no code path by which it can change a setpoint, force an output, acknowledge an alarm or modify a controller.

The copilot does	The copilot never does
Read sensor and controller values	Write to any controller
Search plant documentation	Change a setpoint
Retrieve incident history	Acknowledge or clear an alarm
Propose a likely cause	Authorise an intervention
Cite the manual section	Bypass a permit to work
Estimate downtime	Replace the technician's judgement

Why this boundary is non negotiable

Read only access is what makes the device approvable by an operations technology security team and by the site's safety authority. A copilot that could write would need to be treated as a control system, with all the assessment burden that carries, and it would not be permitted on most sites at all.

Hardware and Rugged Deployment

Compute and interfaces

Element	Configuration
Platform	AMD Kria KR260
System on module	Kria K26, Zynq UltraScale+ MPSoC
Memory	4 GB on-module DDR4
Acceleration	Programmable fabric with DPU
Storage	NVMe sized for the full plant knowledge base
Client	Rugged tablet over local wired or isolated wireless link
Audio	Industrial noise cancelling microphone and headset
Thermal camera	Optional, for surface temperature observation
Diagnostic interfaces	USB and serial for direct equipment interrogation
Plant interface	Read only tap onto the control network segment

Two deployment shapes

Portable. Carried to the asset in a sealed case, connected at the point of work. Suits sites with many assets and
few technicians.
Fixed. Installed in the plant room or motor control centre, accessed from a tablet anywhere on site. Suits
continuous process plants.

Environmental design

The enclosure is usually the harder engineering problem than the software, and it is frequently the item that determines whether the system can be deployed at all.

Ingress protection appropriate to the environment. Dust in mining and cement, washdown in food and pharmaceutical, salt in marine and offshore.
Conduction cooling. Sealed enclosures cannot use fans, so thermal design has to move heat through the case. This directly constrains sustained inference throughput.
Vibration and shock. Both for portable use and for fixed installation near rotating equipment.
Hazardous area certification. ATEX or IECEx where the site requires it. This is a long lead item and needs to be identified at the very start of the project.
Wide operating temperature. Plant rooms, outdoor installations and desert or arctic sites all sit outside commercial temperature ranges.

Identify area classification first

If any target location is a classified hazardous area, that decision drives the enclosure, the power architecture, the certification timeline and the cost more than every software choice combined. Establish it in the first week, not in the first pilot.

The Knowledge Base

What goes in

Equipment manuals Wiring and P&ID diagrams Standard operating procedures Maintenance logs
PLC and controller documentation Sensor specifications Historical incident records
Spare parts catalogue Vendor service bulletins

Answer quality in this architecture is determined far more by the quality of this corpus than by the size of the model. A larger model on a poor corpus performs worse than a small model on a well built one, and it costs more to run.

Ingestion pipeline

Layout aware document parsing

Tables, torque values, part numbers and procedure steps preserved as structure.

Diagram and scan handling

Optical character recognition on scanned drawings, with labels and tag numbers indexed separately from body text.

Asset tagging

Every chunk associated with the equipment tags it applies to, so retrieval can be scoped to the asset in front of the technician.

Section anchored chunking

Chunks follow document sections so a citation points somewhere findable.

Hybrid index build

Dense embeddings plus keyword matching, because tag numbers and part numbers are exact strings that similarity search handles badly.

Incident history is the differentiator

Manuals describe how equipment fails in general. The maintenance log describes how this specific asset has actually failed, on this site, under this duty. Indexing both and correlating them is what turns adocument search into something a technician finds genuinely useful.

Source	What it contributes
Manual failure mode table	The set of plausible causes for the symptom.
Sensor specification	What a normal reading looks like for this instrument.
Maintenance log	What has actually gone wrong on this asset before.
Prior incident record	What the fix was, how long it took, what parts were used.
Vendor bulletin	Known issues the manual predates.

Ingestion is a project, not a step

Most industrial documentation is a mixture of good PDFs, scanned drawings from the 1990s and a spreadsheet somebody maintains privately. Budget for the ingestion work explicitly. It is the single most common reason this class of deployment underdelivers, and it is entirely predictable in advance.

Live Plant State Acquisition

Protocol coverage

Protocol	Typical source
Modbus TCP and RTU	Instruments, drives, protection relays, legacy equipment.
OPC-UA	Modern controllers and the plant's structured data layer.
Siemens S7	S7 family controllers where OPC-UA is not exposed.
Rockwell	ControlLogix and CompactLogix platforms.
BACnet	Building services, HVAC and utilities.
MQTT	Existing plant telemetry brokers where present.
Historian query	Trend context, so the copilot can see how a reading has moved rather than only where it is now.
Direct diagnostic	USB or serial interrogation of the equipment itself.

Trend matters more than instant value

A vibration reading of 4.2 mm per second means little on its own. The same reading, having risen steadily from 1.8 over six weeks, means something specific. The acquisition layer therefore pulls a trend window from the historian wherever one is available, not just the current value.

Asset state object

Read only, enforced at several levels

Read only is enforced in the protocol client configuration, in the network segmentation, and where the site requires it in a hardware data diode. It is not a software policy that could be changed by a configuration mistake.

Correlation and Reasoning

What the model is asked to do

The reasoning task is narrow and well defined. Given a symptom, a set of live readings with their normal ranges and trends, the documented failure modes for this equipment, and this asset’s own history, produce a ranked hypothesis with the evidence for each and the manual section it comes from.

Symptom captured from the technician

In their own words, with the asset identified by tag or by scanning it.

Live state read, scoped to that asset

Only the tags belonging to the asset and its immediate system.

Retrieval scoped to the asset tag

The pump manual, not every pump manual on site.

Correlation

Readings matched against documented failure signatures and against prior incidents.

Ranked hypothesis with citations

Most likely cause first, with what supports it and what would rule it out.

Grounding contract

Condition	Required behaviour
Strong documentary support	State the hypothesis and cite the section.
Readings without documentary support	Report the anomaly, state that the documentation does not cover it, do not speculate on cause.
No relevant documentation	Say so, and flag the corpus gap for the next ingestion cycle.
Safety relevant condition	Give the documented instruction without softening it, and prompt for the permit to work requirement.
Multiple plausible causes	Rank them and state the discriminating test for each.
Conflicting documents	Prefer the most recent vendor bulletin and say that guidance was updated.

Citations are mandatory

Every substantive claim carries a document and section reference the technician can open on the tablet. That is what makes the answer verifiable before someone acts on it, and it is the single feature that most determines whether experienced technicians trust the system or ignore it.

Inference Stack and Memory Budget

Why four bit

A three billion parameter model at sixteen bit precision needs roughly six gigabytes for weights alone, against four gigabytes on the module. At four bit it comes down to approximately 1.7 gigabytes, leaving room for the speech models, the resident portion of a large retrieval index and the protocol stacks.

Throughput is bound by memory bandwidth rather than by arithmetic, because the full weight set streams out of DDR for every generated token. Halving the bytes per weight roughly doubles the
achievable rate.

Component	Allocation
Quantized model weights	~1.7 to 2.2 GB
Key value cache at working context	~200 to 350 MB
Speech recognition and synthesis	~135 MB
Retrieval index resident portion	~200 to 400 MB
Protocol stacks and runtime	~600 to 800 MB
Knowledge base on storage	Tens of gigabytes on NVMe, paged not resident

Context is the tight constraint here

This use case wants longer context than the others, because a good answer often needs a failure mode table, a wiring note and two prior incidents at the same time. The key value cache grows linearly with context and competes with the weights for the same bandwidth, so context length is treated as a
budgeted resource with a hard cap rather than as something to be extended when answers seem thin.

The DDR pipeline

Tiling

Weights tiled to BRAM and URAM

Double buffering

Transfer overlapped with compute over AXI

Prefetch

Next layer fetched during the current one

On-fabric dequant

Four bit bytes cross the bus, not sixteen

Sealed enclosure, thermal reality

A conduction cooled sealed enclosure will throttle before an open bench will. Sustained throughput in the final enclosure at plant ambient is the only figure worth quoting, and it is measured in Phase 2 rather than estimated.

Security Architecture

Network position

The copilot is an operational technology asset and is treated as one. It sits where a monitoring device sits, not where a control device sits, and it has no path to the internet.

Control	Implementation
Read only protocol clients	No write function is compiled into the acquisition layer.
Network segmentation	Placed on a monitoring segment with firewall rules permitting only the required read traffic.
Data diode	Available as a hardware option where the site requires physical enforcement of unidirectional flow.
No outbound path	No internet route in the reference design. Nothing to exfiltrate to.
Secure boot	On-module root of trust with signature verification at each stage.
Signed artefacts	Model, index and application verified before load, so a tampered corpus cannot change what the copilot tells a technician.
Physical security	Sealed enclosure, tamper evidence, encrypted storage at rest.

Why this is the whole approval argument

An operational technology security team assesses a new device on two questions. Can it change anything, and can anything reach it from outside. This architecture answers no to both, by construction rather than by configuration, which is what makes the assessment tractable.

Standards context

The design aligns to the segmentation and zone and conduit model that industrial control system security standards expect. The copilot is placed as a monitoring asset within an existing zone, with defined conduits, rather than introducing a new trust boundary. Its exact placement is agreed with the site security team as part of Phase 0.

Access and accountability

Technician identity recorded against every session, so answers can be traced to who received them.
Query and answer log retained locally, with the citations, for review and for corpus improvement.
No audio retained. Transcripts only, and only for the session unless diagnostic logging is explicitly enabled

Worked Example, End to End

Technician

"Why is Pump 6 vibrating?"

Step 1 Scope

Asset resolved to tag P-006

From the spoken reference, confirmed against the asset register.

Step 2 Read

Live vibration and temperature

4.2 mm/s against a normal below 2.8. Bearing housing at 71 degrees against a normal 45 to 60.

Step 3

Six week history from the historian

Both readings rising steadily rather than stepping, which discriminates wear from a discrete event.

Step 4 Retrieve

Manual and history for this asset

Failure mode table from the pump manual, plus one prior incident on P-006 seven months ago.

Step 5 Correlate

Signature matched

Rising vibration with rising bearing temperature matches the documented bearing wear signature, not the cavitation or misalignment signatures.

Copilot

"Most likely bearing wear on the drive end. Vibration is at 4.2 against a normal below 2.8, and the bearing housing is at 71 degrees against a normal of 45 to 60. Both have risen steadily over six weeks rather than stepping, which fits wear rather than a sudden fault. The same failure occurred on this pump seven months ago. Inspection is recommended. Estimated downtime is 35 minutes. See manual section 6.4, bearing failure modes."

Follow up

Technician

"Could it be cavitation instead?"

Copilot

"Less likely. The manual describes cavitation as a broadband vibration signature with suction pressure below the required margin, and suction pressure is currently within range. If you want to rule it out, section 6.2 gives the suction pressure check."

Offline Operation and Lifecycle

Keeping a disconnected system current

An offline system that is never updated becomes wrong. The design uses signed knowledge bundles delivered through whatever channel the site already trusts, rather than requiring a permanent connection.

Build

Corpus ingested and indexed centrally

New manuals, revised procedures and closed incident records folded into the next bundle.

Sign

Bundle signed and versioned

Model, index and application versioned together.

Transfer

Physical media or scheduled connection

Whatever the site's existing controlled update route is.

Verify and activate

Signature checked before load

Previous bundle retained for rollback.

Harvest

Local logs collected at the same visit

Refusals and corpus gaps drive the next ingestion cycle.

The feedback loop that matters

Every question the copilot could not answer is a documented gap in the plant’s knowledge base. Over time that list is more valuable than the copilot itself, because it identifies exactly which equipment the site cannot support from its own documentation.

Delivery phases

Phase	Scope	Exit criteria
Phase 0 Assessment	Asset scope, documentation audit, protocol survey, area classification, OT security engagement.	Corpus readiness report and agreed network placement.
Phase 1 Ingestion	Documentation collected, parsed, tagged and indexed. Gaps identified and closed where possible.	Retrieval accuracy measured on a real question set.
Phase 2 Bench and enclosure	Model characterised on KR260 in the target enclosure at plant ambient.	Sustained throughput and thermal behaviour measured.
Phase 3 Advisory pilot	Deployed on one asset class with a small technician group. Answers reviewed against outcomes.	Answer accuracy and citation quality accepted by maintenance leadership.
Phase 4 Site rollout	Additional asset classes, additional technicians, update cycle established.	MTTR and first time fix targets held.
Phase 5 Multi site	Bundle production industrialised across sites.	Repeatable deployment package.

Benefits and Measurement

Benefits realised

Completely offline

Works in plants and remote sites with no connectivity, by design rather than by degraded fallback.

Faster troubleshooting

Live readings and documentation correlated in one step instead of several.

Less expert dependency

A junior technician reaches a senior level first hypothesis without a phone call.

Secure plant deployment

Read only by construction, no outbound path, nothing about the plant leaves the plant.

Lower MTTR

Repair time driven by the fault rather than by who is available to answer the phone.

Higher first time fix

Cause confirmed on site before the technician leaves.

Institutional memory

Prior incidents on the same asset surface automatically instead of living in one person's head.

Documented knowledge gaps

Every unanswered question maps exactly where the site's documentation is thin.

KPI framework

Measure	What it tells you
Mean time to repair	The headline number, and the one the business case rests on.
Diagnosis time share	How much of the outage was working out what was wrong.
First time fix rate	Repeat visits avoided.
Escalation rate	Specialist callouts avoided.
Expert phone minutes	Senior engineer time recovered.
Unnecessary part replacement	Components changed on suspicion rather than evidence.
Refusal and corpus gap rate	Where to invest the next ingestion cycle.
Citation follow rate	Whether technicians are verifying, which indicates trust.

Baseline first

Capture current MTTR, first time fix rate and escalation rate before deployment. In maintenance these are usually recorded somewhere in the CMMS, which makes this the easiest of the four use cases to build a defensible before and after picture.

Engineering Considerations and Risks

Known hard problems

Risk	Mitigation
Documentation quality	Corpus audit in Phase 0 with an explicit ingestion budget. This is the dominant determinant of answer quality and it is knowable up front.
Area classification	Established in the first week, because certification is a long lead item that governs enclosure, power and cost.
Thermal throttling in a sealed case	Sustained throughput measured in the final enclosure at plant ambient, never on an open bench.
Technician trust	Mandatory citations, a visible refusal path, and an advisory pilot with a small group before wider rollout.
Stale knowledge base	Signed bundle cycle with a defined update cadence, and corpus revision recorded in every answer.
OT security approval	Read only enforced in the client, the segmentation and optionally in hardware. Engage the security team in Phase 0, not at deployment.
Acoustic environment	Close talking headset rather than far field capture, and hearing protection compatible hardware.
Tag naming inconsistency	Asset register reconciliation, with aliases learned from the query log.

Open questions for the customer

Which fleet manager is in use, and what interface does it expose for plan submission and state
subscription?
Does a warehouse management system integration exist that can supply load identifiers, or is the world
model limited to fleet state only?
Are instructions issued from fixed stations, roaming headsets, or both?
What is the authorisation model? Can any operator issue any instruction, or is it role based?
Which languages and how many sites are in scope for the first release?
Who is the safety authority for the installation, and what evidence will they want that the language
layer cannot reach a safety function?

Recommended first step

A corpus readiness assessment on one asset class. It costs little, it produces a measured retrieval accuracy against real technician questions, and it tells you honestly whether the documentation supports this before any hardware is bought. If the corpus is not there, that finding is worth having early rather than after a pilot underperforms.