AI assistants that search across historian data, alarm history, maintenance records and equipment manuals to propose a likely root cause for an abnormal situation — distinct from a general conversational HMI in that they're built specifically for diagnostic reasoning, not open-ended Q&A.
Natural-language conversational HMI / operator copilots
An operator interface that answers plain-language questions ('why is the reactor trending high?') by querying live process data, alarms and procedures, rather than requiring navigation through faceplates and trend screens.
Short entry. This page summarises our current placement. Full, sourced analyses are published first for the technologies closest to practical use; see the list of full analyses.
How it works
A conversational interface puts a language model between the operator and the plant's information systems. The operator asks a question in ordinary words. The system translates it into queries against the historian, the alarm journal, the operating procedures and the shift log, and composes an answer with the supporting trends or documents attached.
Two design choices decide whether it is safe to use. The first is whether the assistant is read-only or can also change something; almost all current pilots are read-only. The second is how firmly answers are tied to retrieved data, with sources shown, rather than generated from the model's general knowledge.
Why it matters
Could dramatically shorten the time a new or fatigued operator takes to understand an abnormal situation — directly addressing a leading root cause in major incident investigations.
Where it fits
The promising uses are outside the critical minutes of an upset: shift handover summaries, finding the right procedure, explaining an unfamiliar alarm, and helping a new operator learn a unit. It complements, and does not replace, a well-designed graphics hierarchy and a rationalised alarm system, which remain the foundation of operator awareness.
Why we place it at the Emerging Idea stage
Early pilots exist bolted onto existing SCADA/HMI platforms; validated performance under genuine upset conditions, versus a calm demo environment, is the open question. Estimated time to the Proven in Use stage: 5–10 yrs. What the stages mean.
Key risk
An operator interface that can be wrong, confidently, during an abnormal situation is a new and serious human-factors risk that has to be designed against explicitly.
Questions to ask before committing
- Does every answer show the data and documents it was based on, so the operator can verify it?
- What does the assistant say when it does not know, and has that been tested?
- Has the interface been evaluated with real operators in simulated upsets, not only in normal operation?
- Is there any path by which a spoken or typed request can change a setpoint or acknowledge an alarm?
Standards and terms to know
- ISA-101
- The standard for human-machine interfaces in process automation.
- ISA-18.2
- The alarm-management standard, also published as IEC 62682.
- Hallucination
- A fluent but unfounded answer produced by a language model.
Related technologies
See this entry on the full maturity map · All Control Systems entries · How placements are made. Stage and time-horizon placements are editorial judgements based on public information as of October 2026, not engineering, safety or investment advice; see the Terms of Use.