AI Error Diagnosis

When a machine reports an error, the answer is usually somewhere in the manual. AI diagnosis makes the gateway look it up: the viewer sends the error, and CONNECT answers with a probable cause, a remedy and the sources it used — the document, and where in it.

The knowledge base is your own PDF documentation. Operators can attach comments per error, so the second person to hit the same alarm finds what the first one did.

This feature is off by default and has to be enabled deliberately.

What it needs


Documents	PDF manuals in the gateway’s documentation folder. Subfolders act as categories
An LLM key	For the language model that phrases the answer
Nothing in the browser	The browser never holds the key, the index or the document text

Setting it up

Put the machine PDFs into the documentation folder of the gateway data directory. Use subfolders to separate, for example, mechanical from electrical documentation.
Enable the feature and enter the model key in the configuration.
Open the tray menu and choose Index Documentation now, or simply ask the first question — indexing runs on the first request.
Verify with Test AI Query… in the tray menu.

Indexing is incremental: unchanged PDFs are never processed twice, and adding one document does not re-process the rest.

Asking

In the viewer, an error signal offers the diagnosis. The answer names its sources, and each source points at the document and page it came from — the answer is checkable, which is the point.

Answers are limited to a few requests per minute per gateway, so a flapping error signal cannot trigger a request storm.

What the twin adds to the question

A question from the viewer rarely arrives alone. When a part is selected, the request carries what only the digital twin knows about it, and each piece is used differently:

What travels	What the gateway does with it
Document hints — the PDFs linked to that part and its parents	Gives those documents a small ranking bonus in the search. A bonus, never a filter: a passage from another document still wins if it is the better answer
Machine context — the part’s component type, its relevant configured values, the current values of its signals and its active alarms	Goes into the prompt as a clearly marked data block, so the answer can talk about the machine as it is right now rather than as the manual describes it in general
Node notes — what an assistant previously worked out about that part	Appended after the alarm lines, each line marked as author-written text so it can never be mistaken for a live alarm

Even without a selection, the documents of the parts that match the typed question are added as hints, so a question that names a part still gets a part-specific answer.

The context block is size-capped, and the viewer shows the person asking exactly what travelled with their question.

Keeping live machine state off the language model

The documentation search runs on the gateway; phrasing the answer does not. If live signal values must not reach the configured language model, switch the machine-context block off:

Diagnosis:MachineContext=false

With it off, document hints and the documentation search work unchanged — only the live state block is suppressed. It is on by default, because a diagnosis that knows the current machine state is a markedly better diagnosis; turning it off is a deliberate operator decision, and the right one where the model provider is outside your control.

A second, broader block that would carry general machine status beyond the selected part is off by default (Diagnosis:GlobalContext=true enables it). An existing installation therefore never starts transmitting more than it did before, and selected-part context stays available either way.

Comments

Operators can attach comments to an error id and read what others wrote. Comments are stored either in a file next to the gateway configuration or, when the historian is in use, in InfluxDB — where they sit next to the recorded signal history of the same moment.

What leaves the machine

This deserves a precise answer rather than a reassuring one:

Step	Where it runs
Reading and splitting PDFs	On the gateway
Embedding (turning text into vectors)	Through the configured cloud gateway — document text is sent for this step
Searching	On the gateway
Re-ranking (optional)	On the gateway, with a local model — no text leaves the machine
Phrasing the answer	Through the configured language model, with the retrieved passages

If your documentation is confidential, treat this as a decision, not a detail. The pipeline is prepared for a local embedding model, and re-ranking already runs locally today.

The index — which contains the full extracted document text — and the local models live in a private folder that the gateway never serves over HTTP.

Local re-ranking

With re-ranking enabled, the gateway retrieves broadly, ranks the candidates locally with a cross-encoder model, and hands only the best passages to the language model. This improves the answer noticeably on large documentation sets, and the ranking step involves no network at all.

A missing model file degrades gracefully: the pipeline runs without re-ranking and reports the model as missing rather than failing the request.

Prepared documentation

A gateway can be delivered with the documentation and its index already built in. The customer then gets working diagnosis on the first start, with no indexing wait and no re-processing. Documents added or edited on site survive later updates.