Highlights From Detection to Action: Using LLM Agents for Fault-Tolerant Control Javal Vyas, Milapji Singh Gill, Artan Markaj, Felix Gehlhoff, Mehmet Mercangöz • A multi-agent LLM framework for active fault-tolerant control is proposed. • Semantic knowledge grounding enables constraint-aware corrective actions. • Simulation-based validation ensures safety before control execution.
arXiv:2606.28011v1 [eess.SY] 26 Jun 2026
• The framework handles both discrete and continuous recovery tasks. • Effectiveness is demonstrated on mixing and CSTR case studies.
From Detection to Action: Using LLM Agents for Fault-Tolerant Control Javal Vyasa,∗ , Milapji Singh Gillb , Artan Markaja , Felix Gehlhoffb and Mehmet Mercangöza a Imperial College London, London, United Kingdom b Helmut Schmidt University, Hamburg, 22043, Germany
ARTICLE INFO
ABSTRACT
Keywords: Process Control Fault-Tolerant Control Process Plants Large Langauge Models Artificial Intelligence Knowledge Graphs Graph RAG Digital Twin
We propose an agentic Large Language Model (LLM) framework for active Fault-Tolerant Control (FTC) that transforms fault detection outputs into constraint-aware recovery actions grounded in plant-specific knowledge. The approach couples (i) a multi-agent workflow that decomposes operator duties into monitoring, planning, action synthesis, simulation, validation, and reprompting; (ii) a Digital Process Plant Twin (DPPT) that exposes plant data, models, and a simulation service for pre-execution testing; and (iii) a Graph Retrieval-Augmented Generation (Graph RAG) layer built on the CPSMod ontology, which organizes plant knowledge (structure, function, hybrid dynamics, control context, and fault semantics) into a graph that supports relation-aware, multi-hop retrieval for the agents. Corrective actions are generated as minimal-risk state-machine recovery paths and corresponding discrete commands or continuous setpoint adaptations, then validated deterministically against interlocks, envelopes, and dynamic feasibility before any actuation. If no acceptable plan is found within a bounded time window, control is handed to a safety fallback. The framework is evaluated in simulation on two representative benchmarks: a discrete batch Mixing Module and a Continuous Stirred-Tank Reactor (CSTR) under closed-loop PID regulation. Results with lightweight LLMs (GPT-4o-mini and GPT-4.1-mini) show that semantically grounded agents can derive valid recovery decisions within latency budgets compatible with the respective process dynamics, demonstrating a practical pathway from detection to validated corrective action across both discrete and continuous FTC tasks.
1. Introduction Despite advances in automation, many process industry operations remain heavily dependent on the expertise of human operators for accurate situation assessment and decision making under unforeseen conditions. This is particularly true where data is limited or system behavior deviates from expected patterns (Baldea et al. (2025)). Process plants exhibit tightly coupled flows of energy, materials, and information, so even small disturbances can propagate across subsystems. Faults in process systems often manifest through subtle, state-dependent symptoms that hinder early detection and diagnosis (Webert et al. (2022)), while alarm floods, where many alarms trigger in rapid succession, can overwhelm operators (Manca and Fay (2021)) and complicate timely decision making. In such situations, operators must interpret noisy and incomplete evidence, map it to plant topology and operating modes, and execute safe recovery procedures. This is compounded by uneven expertise across shifts and limited decision support (Markaj et al. (2024)). These challenges motivate greater autonomy and drive new approaches in active Fault-Tolerant Control (FTC) for process plants. FTC aims to preserve safe, autonomous operation in the presence of faults by compensating their effects online (Olivier and Craig (2017)). Acknowledgment: This research [project ProMoDi] is funded by dtec.bw – Digitalization and Technology Research Center of the Bundeswehr. dtec.bw is funded by the European Union – NextGenerationEU. Financial support from ABB for the Autonomous Industrial Systems Laboratory at Imperial College London is gratefully acknowledged. The first two authors contributed equally to this work. ∗ Corresponding author [email protected] (J. Vyas)
J Vyas et al.: Preprint submitted to Elsevier
Over the years, various Artificial Intelligence (AI)-driven techniques have been proposed for active FTC. Especially Reinforcement Learning (RL) and agent-based methods have been explored as complements to classical process control. RL agents can autonomously optimize complex process tasks such as reactor operation and crystallization (Alhazmi et al. (2022); Manee et al. (2022); Tang et al. (2024)). However, their broader adoption in process industries remains limited due to several fundamental challenges. In particular, RL approaches often exhibit low sample efficiency (Tang et al. (2024); Bloor et al. (2024)), limited generalizability across different systems (Tang et al. (2024); Sitapure and Kwon (2023)), and require carefully designed reward functions to ensure stable and interpretable policy learning (Tang et al. (2024); Manee et al. (2022)). Beyond RL, agent-based concepts are increasingly considered to replace or augment human operators ((Lee et al., 2021)). While these approaches highlight the potential of AI-driven autonomy in process plants, extensive training, simulation and validation remain essential before deployment. Recent advances in Large Language Models (LLMs), together with agentic tooling, enable end-to-end orchestration of control actions without large task-specific datasets (Xia et al. (2025)). In the context of active FTC, LLM agents can coordinate condition monitoring, reason over plant-specific context for plant recovery, and invoke tools for pre-execution validation, thereby improving sample efficiency and operational safety (Gill et al. (2025b)). However, effective deployment requires grounding agents in plant-specific knowledge that is distributed across heterogeneous engineering artifacts (Rupprecht et al. (2026)) and must be integrated into a unified representation. Artifacts include P&IDs, cause–effect Page 1 of 12
Using LLM Agents for Fault-Tolerant Control
matrices, interlock lists, operating envelopes, maintenance records and physics-based simulation models, which together encode structure, function, behavior and fault semantics (Gowaikar et al. (2024); Gill et al. (2025b)). Moreover, process plants combine continuous and discrete behaviors that make timely reasoning difficult. While document-level Retrieval-Augmented Generation (RAG) helps with grounding, it is less suited when recovery requires explicit traversal of distributed relations among equipment, faults, interlocks, operating modes, and control actions (Ovalle et al. (2025)) . Thus, the following research questions (RQs) need to be addressed in the context of FTC: • RQ1: How should plant-specific knowledge be linked, represented and retrieved so that LLM agents are properly grounded for active FTC? • RQ2: How can LLM agents synthesize safe recovery plans with corrective control actions and validate them prior to execution? • RQ3: Can LLM agents derive effective corrective actions within a reasonable time span in both openloop and closed-loop control scenarios? The following contribution is structured as follows. Sec. 2 reviews the state of the art on LLM-based engineering and control. Sec. 3 presents our LLM-based agent framework for active FTC and details its components. Sec. 4 evaluates the framework in two case studies: (i) a Modular Mixing Unit with discrete supervisory sequences and (ii) a Continuous Stirred-Tank Reactor with time-continuous dynamics. Sec. 5 reports results against predefined evaluation criteria. Sec. 6 discusses implications and limitations and answers the RQs. Sec. 7 concludes with a summary and an outlook.
2. State of the art 2.1. LLMs for process operations LLMs have moved into the scope for engineering applications as advances in natural-language processing, code generation, and multimodal reasoning mature. A recent overview by Rupprecht et al. (2026) highlights how LLMs are increasingly used to bridge unstructured engineering knowledge (e.g., manuals, reports, logs) and structured engineering workflows, supporting tasks in engineering design, system analysis, and operational decision support. Across these application areas, end-to-end workflows typically rely on three complementary technological paradigms. First, RAG grounds LLM outputs in external information sources to mitigate outdated training knowledge and hallucinations. Graph-based variants such as Graph RAG further enable relation-aware, multi-hop retrieval across dispersed facts (Srinivas et al. (2025)). Second, agentic architectures embed LLMs as reasoning components within orchestrated workflows, with specialized agents for tasks such as monitoring, validation, and reporting, to integrate heterogeneous tools and data sources (Vyas and Mercangöz (2025)). Third, planning capabilities support the generation and evaluation J Vyas et al.: Preprint submitted to Elsevier
of action sequences under constraints, enabling structured, goal-directed problem solving (Jobs et al. (2025)). In the context of engineering design, LLM agents have been applied to assist with the analysis and modification of process flow designs. For example, Lee et al. (2024) developed a multi-agent system that takes an existing process flow diagram (PFD) as input and generates suggestions for process improvements or alternative designs. By parsing the flowsheet structure and accessing external literature via tools, the agents proposed modifications such as heat integration steps or alternative separation sequences. Similarly, Gowaikar et al. (2024) demonstrated how LLM-based agents can generate engineering diagrams from naturallanguage descriptions. Their multi-step copilot translates textual process descriptions into structured P&IDs, which can subsequently be reviewed and corrected by human experts, enabling iterative refinement. Beyond design, LLMs have been leveraged for analysis and knowledge extraction from heterogeneous engineering data. Ovalle et al. (2025) constructed knowledge graphs from academic literature in the process systems engineering domain and employed an LLM agent with Graph RAG to synthesize information for answering optimization-related queries. Such approaches illustrate the potential of LLMs to formalize dispersed knowledge and support analytical reasoning over complex process information. LLM agents have also been explored as operator assistants and decision-support systems. Sakhinana et al. (2024) proposed a centralized LLM-based agent capable of answering ad-hoc operator queries and generating fragments of automation or control code on demand, using a Graph RAG mechanism to retrieve relevant documentation and code examples from a company knowledge base. At a higher operational level, Pajak et al. (2025) employed a multi-agent system to balance economic and environmental objectives in a gas–oil separation plant, where LLM agents interacted with simulation tools (e.g., Aspen HYSYS) to evaluate and negotiate operational trade-offs.
2.2. LLMs for control tasks While the focus of this work is on process systems, it is instructive to consider how LLM-based control concepts are explored in other Cyber-Physical System (CPS) domains. Across areas such as building automation, robotics, and manufacturing, LLMs are investigated for control-related tasks at different levels of abstraction, ranging from direct action selection to high-level planning and supervisory coordination. Many of the underlying challenges, e.g. uncertainty, changing operating conditions, and the need for safe decision making, are shared across these domains. In some studies, LLMs are used directly for control action selection. For example, the authors of this work have previously introduced an LLM-driven multi-agent framework for an industrial temperature regulation task, where agents monitored sensor readings and adjusted actuator settings in real time (Vyas and Mercangöz (2025)). Control decisions were generated through natural-language reasoning and Page 2 of 12
Using LLM Agents for Fault-Tolerant Control
validated against expected system behavior, illustrating how LLMs can be embedded directly into control loops. Similarly, in the context of building automation, Song et al. (2023) demonstrated that an LLM can function as a controller for HVAC systems. At each time step, the LLM received a structured prompt describing the control objective, selected state–action examples, and current sensor readings, and responded with a control action such as adjusting a thermostat or fan setting. Despite minimal task-specific tuning, the LLMbased controller achieved performance comparable to a RL controller and showed robustness across varying weather and occupancy conditions. In manufacturing and industrial automation, LLMs are increasingly explored as supervisory or orchestration layers. For instance, Xia et al. (2025) proposed an architecture in which an LLM operates above a hierarchical automation system, receiving textualized event streams from different levels of a production line and generating coordinated control or scheduling actions. In this role, the LLM does not replace existing controllers but supervises and adapts their interaction, with digital twins and simulation models providing situational awareness and evaluation of proposed actions.
2.3. Contributions of this study Recent work shows that LLMs can support process operation workflows by querying documentation, calling tools, and generating automation or control code, effectively bridging natural-language intent and machine execution. However, these capabilities do not yet amount to deployable fault handling in safety-critical process plants. Three gaps recur across the literature: 1. (i) Grounding: plant knowledge is fragmented across heterogeneous artifacts, and text-only retrieval often misses the relationships needed to derive corrective actions. 2. (ii) Assurance: actions are rarely accompanied by auditable traces and explicit feasibility checks against interlocks, operating envelopes, and process physics before execution. 3. (iii) Timeliness/Robustness: recovery must operate under hybrid dynamics, partial observability, and distribution shift, where plausible but delayed or incorrect actions can be unsafe. We address these gaps with three contributions. First, we enable relation-aware, multi-hop grounding via an ontology and Graph RAG to retrieve actionable dependencies linking equipment, control logic, operating modes, and fault semantics. Second, we enforce safety through minimal, explainable recovery plans with deterministic pre-execution validation (interlocks, envelopes, and dynamic feasibility) and an auditable decision trace, implemented via a multi-agent workflow (planning, action synthesis, simulation, validation, reprompting). Third, we support bounded-latency operation through tool-assisted monitoring, constrained action generation, runtime verification, and a safety fallback if no admissible plan is found. The resulting framework (see Sec. 3) connects fault detection outputs to validated corrective actions for hybrid process systems. J Vyas et al.: Preprint submitted to Elsevier
3. LLM-based agentic framework for fault-tolerant control 3.1. Overview The following Sec. 3 provides an overview of the framework used to integrate LLM agents into active FTC. We distinguish two spaces, the Physical and the Virtual one (see Figure 1). The Physical Space contains the Process Plant and a Safety System that executes a fail-safe strategy if no valid corrective action is found within a bounded time window. The Virtual Space is split into a Tool Layer (see Sec. 3.2) and an Agent Layer (see Sec. 3.3). Two types of information flows are distinguished: firstly, flows between the Physical Space and the Agent Layer, as well as among the agents themselves, which are depicted with solid lines. Secondly, flows between the Agent Layer and the Tool Layer, which are depicted with dashed lines. Moreover, the agent decision logic is categorized into rule-based/deterministic, data-driven/MLbased, and LLM-based, as indicated in the legend.
3.2. Tool layer The Tool Layer exposes two shared components. Firstly, a Digital Process Plant Twin (DPPT), which is an executable tool stack that provides plant data, physics-/data-driven models, and validation services to automate FTC tasks. Secondly, an ontology that integrates heterogeneous engineering artifacts into a machine-interpretable representation to ground LLM agents via structured, multi-hop prompt augmentation and context retrieval across structure, function, behavior, condition monitoring as well as fault information.
Digital Process Plant Twin: We ground our notion of a
DPPT in two complementary perspectives from the literature. Following the five-part view by Tao et al. (2019), a digital twin comprises the physical entity, its virtual counterpart, their bidirectional connection, a data space, and digital service capabilities. In parallel, we adopt the definition introduced by Kritzinger et al. (2018), which includes a digital model (no automatic coupling), a digital shadow (automatic one-way synchronization from physical to digital), and a digital twin (automatic two-way synchronization). The digital twin capabilities should be scoped to the decision problem and calibrated in fidelity, coverage, and services to meet the accuracy and latency requirements of the task (Reinpold et al. (2024), Gill et al. (2022)). Because we target active FTC, our DPPT instantiates only the data, models, and services needed to detect anomalies, localize faults, synthesize constraint compliant corrective actions, and validate them within prescribed latency budgets. In this configuration, the DPPT (blue rectangle in Figure 1) serves as the callable tool layer for LLM-driven agents and supports condition monitoring and simulation based validation. Operational data in the DPPT comprise time-synchronized sensor and actuator streams, including level, flow, pressure, temperature, valve states, and pump speed. They further include batch and sequence logs as well as alarms and events. Moreover, outputs from condition monitoring, such as detected anomalies and faults that are generated by Page 3 of 12
Using LLM Agents for Fault-Tolerant Control GraphRAG
Digital Process Plant Twin
Fault
Digital Models
Digital Services
Graph Data Base
System Function and Behavior
Monitoring Agent
Data
System Data
Monitoring Results
Fault
Fault
Yes
Agent Layer
Virtual Space
Tool Layer
System Model Information
Invoke Simulation Service
System Function and Structure
Planning Agent
Feasable Actions Paths
Action Agent
Corrective Actions
Get Simulation Results
Simulation Agent
Simulation Results
Validation Agent
Validated Corrective Actions
Safe
Yes
No
No Action Refinement Feedback
Planning Refinement Feedback
Reprompting Agent
Violations and Potential Causes
No
Iteration > n
Physical Space
Yes Safety Actions
Next Control Action
Safety Systems
Process Plant
Plant State
Validated and Safe Corrective Actions Legend
Information Flow Information Flow in Agent Layer
Agent Decision Logic
Information Flow between Agent and Tool Layer
Rule-based / Deterministic
Data-driven / ML-based
LLM-based
Figure 1: Framework for active FTC, structured into Physical Space and Virtual Space with Agent Layer and Tool Layer.
data driven models, are stored. Static engineering data include P&IDs, parameter limits, operating envelopes, causeand-effect matrices and the hierarchical plant breakdown structure. The DPPT maintains two types of digital models. The first type is the simulation model of the plant, which encodes structure, function, and dynamics at the granularity required to evaluate generated corrective control actions. Structural and functional descriptions capture equipment connectivity and unit roles. Behavioral abstractions capture supervisory modes and sequences as finite state machines. Physicsbased and reduced order models implement the continuous time mass and energy balances, constraints and actuation effects.The second type comprises data driven models for condition monitoring and fault detection.
Graph RAG: In order to address RQ1, we use an ontology
to integrate heterogeneous data and to represent the system in a machine interpretable way, enabling LLM agents to be grounded in plant specific knowledge. We distinguish between the terminological level of ontologies, the T-Box, which defines the schema, and the assertional level, the ABox, which contains the instance data for a specific plant. This separation lets us reuse the same schema for different assets while populating it with plant-specific instances for active FTC. Additionally, it enables semantic harmonization and contextualization: the T-Box assigns explicit meaning to the data by providing a shared vocabulary and formal relations, allowing the integrated information to be both machine- and human-interpretable. In order to depict the terminological knowledge of the knowledge graph, the modular alignment ontology CPSMod is reused. The ontology is modular, and its core concepts and relations are derived from industrial standards in order to maximize reuse and ensure a consistent vocabulary across J Vyas et al.: Preprint submitted to Elsevier
projects. The method introduced by Hildebrandt et al. (2020) was applied to model the ontology with different reusable standards-based ontology design patterns (ODPs). The ontology is specified using the W3C stack, namely RDF and OWL for modeling and is additionally annotated with naturallanguage metadata (e.g., rdfs:label and rdfs:comment) to make classes, relations and instances interpretable in text form. Prior studies (e.g., Reif et al. (2024)) indicate that such annotations can improve LLM-based interpretation of knowledge graph content. An excerpt of the model with information relevant for the task is depicted as an unified modeling language (UML) class diagram in Figure 2. This ontology, already introduced and applied by the authors in previous works (Gill et al. (2025a, 2024)) for other CPS from the process and the aviation domain, provides unified semantics with regard to the domain knowledge required. It connects structure (green classes), function (red classes), behavior (blue classes), as well as condition monitoring and fault (purple classes) information and therefore supports relation aware, multi hop retrieval. CPSMod links those classes from different ODPs by using object properties (e.g., owl:equivalentClass, rdfs:subClassOf, new object properties) so that agents can traverse multi-hop reasoning paths of specific subgraphs. ODPs included are: • ODP VDI 2206 for structural decomposition • ODP VDI 3682 for functions and product, energy or information flows • ODP UML State Machine for discrete behavior description • ODP OpenMath for continuous behavior description with mathematical equations • ODP DIN 17359 for condition monitoring and fault diagnosis
Page 4 of 12
Using LLM Agents for Fault-Tolerant Control CPSMod:SystemModel
CPSMod:consistsOf BehaviorModel
VDI2206:BasicSystem
VDI2206:Mechatronic System
owl:equivalent Class
VDI2206:Module
VDI3682:Technical Resource
VDI2206:Component
VDI2206:consistsOfModule
CPSMod:consistsOf StrcutureModel
CPSMod:consistsOf FunctionModel
OM:Application
VDI2206:consistsOfComponent
VDI2206:Mathematical Model UMLStateMachine:UML StateMachine
Legend:
VDI3682:Process
VDI3682:consistsOf ProcessOperator
Behavior Model
Function Model
CPSMod:technicalResource Realizes
VDI3682:consistsOf Process
VDI3682:Product
VDI3682:isAssignedto
VDI3682:Energy
VDI3682:Information
DIN17359:FaultIs Described BySymptom
DIN17359:Fault
DIN17359:Parameter
DIN17359:FeatureIndicates Anomaly
DIN17359:Reference Value
DIN17359:Feature
CPSMod:isCharacterizedByParameter
Condition Model
DIN17359:Anomaly
DIN17359:Symptom IndicatesFault
VDI3682:hasInput
VDI3682:hasOutput
VDI3682:State Structure Model
DIN17359:Symptom DescribesAnomaly
DIN17359:SymptomIsExtracted FromFeature
VDI3682:consistsOf
VDI3682:Process Operator
DIN17359:Symptom
DIN17359:ParameterIsDescribed ByRefValue
DIN17359:Feature IsComparedTo DIN17359:ParameterIsDescribed ByFeature
Figure 2: Excerpt from the CPSMod alignment ontology integrating five standards-based ODPs.
The CPSMod alignment ontology is intentionally kept generic across CPS domains. Domain-specific schemas such as DEXPI for process engineering can be aligned with CPSMod through its modular structure as a complementary extension. The Graph RAG pipeline (depicted in dark green in Figure 1) maps data and digital models from the DPPT into the ABox of the knowledge graph and keeps them aligned with the T-Box. Mapping languages such as RML and R2RML should be used to convert tables, engineering artifacts, simulation outputs, and condition monitoring results into RDF. The populated ontology is stored in a graph database and exposed through SPARQL 1.1. In order to interact with the established knowledge graph, a registry of predefined SPARQL templates (SELECT/CONSTRUCT/ASK/DESCRIBE) is included. Agents invoke these templates to fetch compact, relevant subgraphs that are appended as structured context to augment the prompt for the LLM. The interpretation of this knowledge graph is guided by a structured prompt that explicitly references the underlying T-Box, thereby specifying how entities and relations are to be understood and which semantics are relevant for the current task. Graph RAG is used because recovery requires traversing relations among equipment, functions, states, faults, guards, actuators, and limits, rather than retrieving isolated document chunks.
(e.g. rule-based reasoning, machine learning, and LLMs) whenever non-trivial cognitive capabilities such as interpretation, inference, or decision synthesis are required. LLMs are used primarily in the Planning Agent and the Action Agent because these roles require interpreting semantically enriched information and synthesizing of constraintcompliant recovery decisions rather than performing mere classification. The LLM is not intended to replace graph search, regulatory control, simulation, or safety validation. Rather, it acts as a supervisory candidate generator when recovery requires interpreting retrieved plant context and proposing discrete or continuous corrective actions. This regime is relevant when (i) symptom and fault descriptions must be interpreted over natural-language ontology annotations rather than over enumerated rules, (ii) recovery requires continuous setpoint trade-offs under interacting constraints rather than the selection of a discrete shortest path, (iii) operator-readable rationales are required for human oversight, or (iv) the framework must be extensible to new faults, sensors, or actuators through knowledge-graph augmentation rather than through controller re-design. In addition, LLMs can articulate intermediate rationales for each decision, which supports post-hoc interpretation, validation, and human oversight.
3.3. Agent layer
process context of each control loop and sequence. In the present implementation, it is not LLM-based, but a deterministic/data-driven component for processing synchronized sensor, actuator, alarm, and event signals. It ingests process values (PVs), setpoints (SPs), manipulated variables (MVs), actuator commands, and actuator feedback, covering both discrete states and continuous signals. The agent detects faults as deviations from nominal behavior using statistical baselines (e.g., change-point tests, residual monitoring) or data-driven models (e.g., autoencoders, isolation forests). If no fault is detected, normal operation continues; otherwise, the downstream recovery
With regard to RQ2, we introduce a structured, feedbackdriven method in the Agent Layer that iteratively refines recovery plans and control actions to reduce human intervention while maintaining operational safety. To this end, operator responsibilities are decomposed into distinct, interacting agents that reflect key cognitive functions in active FTC. The method incorporates a Monitoring, a Planning Agent, an Action Agent, a Simulation Agent, a Validation Agent, and a Reprompting Agent. These agents combine conventional deterministic software logic (e.g., rule execution, simulation orchestration, and constraint checks) with AI-based methods J Vyas et al.: Preprint submitted to Elsevier
Monitoring Agent: The Monitoring Agent acquires the
Page 5 of 12
Using LLM Agents for Fault-Tolerant Control
workflow is triggered and the plant state is set to "FAULT ". After a validated corrective action is applied, expected transient deviations are not treated as new faults unless hard safety limits are violated.
must provide command semantics (e.g., open V201 to 30%, start P301 at 50% n). These information are returned as an ordered action set per feasible path.
Planning Agent: The Planning Agent receives the typed
set of corrective control actions produced by the Action Agent together with the current fault mode and invokes the simulation service of the DPPT. Its purpose is to test whether the proposed corrective control actions can drive the system from the current faulty state to a valid operational state under the plant’s dynamics. The agent prepares a simulation job that includes the faultmode specification, initial conditions and control context (PVs, SPs, MVs, modes), the action sequence with timing and ramp profiles, relevant interlocks and envelopes to be enforced. The simulation service then executes the job and returns the resulting trajectories and end states, i.e., updated PV/SP/MV values and the resulting discrete plant mode/state after applying the proposed actions under the injected fault. If the run terminates in an operationally acceptable state without critical constraint violations, the plan is flagged as dynamically feasible. Otherwise, the service returns a structured failure report (e.g., violated constraints, unsafe modes reached, unmet terminal conditions) that is propagated back to the downstream agents to trigger refinement or reprompting.
fault symptom and fault produced by the Monitoring Agent and transforms them into a recovery plan with feasible corrective control actions. The agent is grounded in the plant’s control context by drawing on information from the ontology described in Sec. 3.2. It retrieves a knowledge graph extract that captures the relevant system functions (in openloop and closed-loop scenarios) and its supervisory behavior under normal and faulty conditions, represented by a state machine. This subgraph serves as the authoritative context for subsequent reasoning and constrains the decision space to the admissible corrective control actions supported by the plant. The retrieval pipeline proceeds as follows. The Planning Agent issues SPARQL queries to obtain (i) the implicated VDI3682:Process instance(s) and (ii) the associated UMLStateMachine:StateMachine fragment comprising UMLStateMachine:State and UMLStateMachine: Transition entities, including their guards, actions, and references to operating limits. Results are returned via a SPARQL CONSTRUCT, yielding a self-contained subgraph suitable for planning. Conditioned on this input, the prompt instructs the LLM to traverse the state-machine graph, enumerate guardsatisfying paths from the current (faulty) state to one or more target operational states, and propose a minimal-risk recovery path subject to operating constraints.
Action Agent: The Action Agent consumes the feasible
state-machine paths produced by the Planning Agent and synthesizes corrective control actions that can move the plant from the current faulty state toward an admissible operational state. Like the Planning Agent, it is grounded in the plant’s control context via Graph RAG. In addition to the proposed paths, it queries the knowledge graph to obtain a structure–function–actuation subgraph that links processes and behavioral paths to concrete control hardware. The agent issues symptom- and path-conditioned SPARQL queries to retrieve the implicated VDI3682:Process and its VDI3682:ProcessOperator elements, and to align them with the corresponding VDI2206:MechatronicSystem, VDI2206:Module, and VDI2206:Component instances that realize the functionality. This alignment exposes the relevant actuation interfaces (e.g., VDI3682:Actuator linked to modules/components), admissible commands, and operating limits. The retrieved subgraph is used as context for prompting and constrains the action search to what the plant actually allows. The prompt instructs the LLM to propose action sequences, including discrete commands and continuous setpoint adjustments, that enable the next transition(s) on the chosen path by satisfying guards and permissives, respect limits, rate constraints, and interlocks. As a result, the LLM J Vyas et al.: Preprint submitted to Elsevier
Simulation Agent: The Simulation Agent consumes the
Validation Agent: The Validation Agent decides whether
the proposed action set is safe and acceptable before any actuation on the plant is executed. It takes as input the candidate actions from the Action Agent and the structured simulation outputs (trajectories, end states, and constraintviolation flags). Because these outputs are machine-readable, the agent relies primarily on deterministic computational logic (i.e., rule- and metric-based checks) to evaluate feasibility and safety. Its first priority is to verify that the target operational state is reached without violating interlocks, permissives, or operating envelopes. Concretely, it evaluates criteria such as (i) continued satisfaction of interlocks and permissives with no limit violations, (ii) recovery time below a specified threshold, (iii) loop-performance bounds on overshoot, settling time, and steady-state error, and (iv) compliance of actuator commands with rate, travel, and dutycycle limits. The agent outputs a concise decision: Approve (safe and acceptable) with the selected action set, or Revise (not acceptable) with structured feedback identifying the blocking checks (e.g., envelope breach, excessive recovery time, unmet guard, actuator-rate violation) so downstream agents can refine the proposal. If no safe plan emerges within the latency budget, control is handed over to the safety system.
Reprompting Agent The Reprompting Agent coordinates
the iterative refinement loop when a recovery path or an action set is deemed unsafe or unacceptable. It consumes (i) structured blocking feedback from the Validation Agent (e.g., envelope breaches, unmet guards, excessive recovery time, actuator-rate violations) and (ii) simulation outputs Page 6 of 12
Using LLM Agents for Fault-Tolerant Control
(e.g., constraint violations, signature mismatches, sensitivity indicators). When the expected failure modes of the Planning and Action Agents are known, the reprompting mechanism can rely on predefined feedback templates. In this case, the Reprompting Agent selects an appropriate text block based on the structured violations returned by the Validation Agent and inserts it into the next planning or action prompt so the upstream agent can correct the specific issue that previously caused rejection. If such correction patterns are not available a priori, because plausible causes are unknown, too diverse, or highly context-dependent, the Reprompting Agent can instead use an LLM to generate the refinement text directly from the observed violations. The generated feedback is then included in the subsequent prompt to make explicit what failed, why it failed, and which aspect must be revised in the next iteration. Accordingly, the agent routes that feedback to the responsible agent: planning refinement feedback to the Planning Agent (e.g., revise the recovery path, explore alternative admissible UMLStateMachine:Transition sequences) or action refinement feedback to the Action Agent (e.g., re-parameterize setpoint profiles, add ramp/hold/purge steps, tighten tolerances to satisfy interlocks and envelopes).
4. Case studies 4.1. Mixing module The first case study uses the Festo Mixing Module (see Figure 3 ) from the Process Automation Laboratory at Helmut Schmidt University Hamburg as a reference and realizes the laboratory setup in a Python-based simulation. The simulation mirrors the laboratory setup and provides all information required to instantiate and evaluate the proposed framework. V_in0
V_in1
V_in2
LT5
LT3
B201
B202 LT4
LT2
B204
B203 LT6
FT LT8
V_B201
V_B202
V_B203
V_P V_out PT
P_101
P_102
Figure 3: Mixing Module Schematics.
It comprises four connected tanks (B201–B204), a central pump (P 1 01), a bypass pump (P 1 02) and controllable on–off valves (for example V_in0) that serve as actionable control inputs for the agents. During operation, liquid is filled into B201–B203 and subsequently transferred to B204 in a predefined sequence. Mode transitions are governed by discrete control logic that reacts to process conditions (see J Vyas et al.: Preprint submitted to Elsevier
t0
Fill B201
t1
Fill B202
t2
t7
Fill B203 t3
Empty B204
t6
Empty B203
t5
Empty B202
t4
Empty B201
Figure 4: State machine of the Mixing Module under normal operation, with eight states (Init, Fill B201–B203, Empty B201–B204) and transitions t0–t7.
Figure 4). Boolean level thresholds (e.g., sensor_discr ete_tank_B203_high(LT5)) trigger mode changes once predefined fill heights are reached. In addition, continuous measurements from pressure sensors (e.g., sensor_conti nuous_pressure(PT)), a volumetric flow sensor (sens or_continuous_volumeFlowRate(VT)), and the pumpspeed reference enable precise control and support anomaly detection by comparison to expected operating profiles. The simulation supports fault injection for clogging, leakage, pump_degradation, pump_failure, and sensor_fault. The agent framework operates by interpreting the current process state, including tank levels and fault conditions, to determine appropriate control actions. For planning, the state machine representing the plant’s behavior is stored in the knowledge graph. A SPARQL CONSTRUCT query extracts the relevant subgraph (states, transitions, and transition guards), capturing operational constraints such as fault-dependent path selection (e.g., via bypass). Based on this semantic context and the current fault condition, the Planning Agent selects the next target state. The target state is then passed to the Action Agent, which queries the knowledge graph for the actuator configuration associated with that state and returns the set of actuators to be activated.
4.2. Continuous stirred-tank reactor
LT7
LT1
Init
For the second case study, we draw on the continuous stirred-tank reactor (CSTR) (see Figure 5), implemented as a Python-based simulation. The CSTR is widely used to evaluate modeling and control methods and is well established in process systems engineering and process control communities (Markaj et al. (2024)). The system consists of a single reactor vessel R1 with variable liquid level, an inlet valve V1, an outlet pump P2, and a cooling jacket H1 supplied via a cooling valve V3. Two reactants, A and D, are fed into the reactor, where A reacts with D to form B while simultaneously undergoing a parallel conversion to C. The reactor temperature T1 and the liquid level L are measured continuously and constitute the primary controlled variables. Using the simulation, the following fault scenarios can be injected and analyzed: fouling, pump_degrade, and cool_stuck_closed. The CSTR is operated under regulatory control using three interacting PID control loops. The inlet-flow control loop regulates the feed flow by manipulating the inlet valve V1. The level control loop regulates the reactor liquid level by manipulating the outlet flow via pump P2, thereby compensating Page 7 of 12
Using LLM Agents for Fault-Tolerant Control
Figure 5: CSTR Schematics.
for deviations between inlet and outlet flow. The temperature control loop maintains the reactor temperature at a specified setpoint by adjusting the coolant flow through valve V3, which determines the heat removal via the jacket H1. All controllers are implemented as standard PID blocks and interact through the coupled mass and energy balances of the reactor. To enable condition monitoring, statistical reference parameters (mean, standard deviation, percentile-based thresholds, and three-sigma limits) were derived a priori from fault-free operation for key monitoring variables, including measured temperature and level, inlet and outlet flows, cooling flow, actuator positions, balance residuals, and temporal gradients. Deviations from these reference ranges are interpreted as fault symptoms and linked to fault descriptions used by the Planning Agent. Based on the identified symptom and the finite-state machine representation of the process behavior, the Planning Agent selects the target operating state. The Action Agent then determines suitable setpoint adaptations for the control loops to safely continue operation under the detected fault condition. The regulatory control loops, signal, material, and energy flows, as well as their transformations, are explicitly depicted in the knowledge graph. In addition, the underlying mathematical relations for every CSTR function are represented to provide the LLM agents with causal awareness of the control structure and process dynamics. The knowledge graph for both studies is stored in a graph data base (Ontotext GraphDB).
4.3. Evaluation criteria With regard to the RQs introduced at the beginning, three overarching properties of the proposed LLM-agent framework are evaluated: decision accuracy, added latency, and computational cost. Accuracy is assessed using four metrics capturing whether the agents synthesize safe and effective recovery decisions: (i) end-to-end success rate, (ii) recovery rate, (iii) plan correctness, and (iv) action correctness. The success rate indicates whether a run reaches the stabilized terminal condition without safety violations and without exceeding the reprompt limit. The recovery rate captures the fraction of reprompted J Vyas et al.: Preprint submitted to Elsevier
runs that can be successfully corrected. Plan correctness assesses whether the Planning Agent selects recovery paths and state transitions consistent with the formal process logic (admissible transitions/guards) and the observed plant state. Action correctness assesses whether the Action Agent implements the intended recovery decision while respecting admissible control constraints. Its operationalization depends on the case-study control character (binary actuator commands vs. continuous setpoint adaptation) and is specified in the corresponding results subsections. Latency addresses how rapidly safe corrective control actions can be produced. It is measured as both per-iteration decision time and total wall-clock time from fault onset (or detection) to successful stabilization (evaluated corrective control action), thereby separating local decision responsiveness from global recovery time. Costs are measured primarily via token consumption ( input token and output token) aggregated over a complete run and disaggregated by agent roles, with additional overhead attributed to reprompting triggered by invalid or infeasible intermediate outputs. For an exploratory study, each fault scenario was executed 𝑛 = 10 times per model configuration to assess the effectiveness and efficiency of the proposed LLM-agent framework for active FTC. Prior to fault evaluation, we ran 𝑛 = 10 fault-free baseline trials per model for both the CSTR and the Mixing Module, confirming that the agent system can reliably steer nominal operation in both cases. The subsequent evaluation therefore focuses exclusively on fault-handling behavior.
4.4. LLM selection The primary contribution of this work lies in the proposed framework architecture rather than a comprehensive LLM benchmark. Consequently, model selection was guided by proof-of-concept requirements, namely to demonstrate that lightweight LLMs can reliably execute knowledge-grounded decision tasks within active FTC constraints. The decision tasks addressed in this work are highly structured as relevant system knowledge, admissible actions, and operational constraints are explicitly provided via Graph RAG and task-specific prompts. Under these conditions, the ability to rapidly interpret structured context and produce consistent, constraint-compliant outputs becomes more critical than strong general reasoning capabilities. Importantly, fault localization is out of scope and assumed to be provided by the monitoring layer, as diagnosis typically requires broader evidence integration and stronger open-ended reasoning. Based on these considerations, two models from OpenAI’s efficiency-optimized tier were selected: GPT-4o-mini and GPT-4.1-mini. This pairing enables a controlled comparison within a single vendor ecosystem, isolating the effect of architectural model improvements while holding API behavior, tokenization, and tool-calling interfaces constant. Both models represent a cost–latency operating point that is highly relevant for industrial deployment, where inference costs and response times directly impact the feasibility of LLM-assisted control architectures. Page 8 of 12
Using LLM Agents for Fault-Tolerant Control
5.1. Mixing module results Table 1 summarizes the results for the Mixing Module. We evaluate the agent performance using the accuracy metrics introduced in Sec. 4.3. For the Mixing Module, action correctness is additionally quantified using action precision and action recall over the selected actuator set relative to a ground-truth action set (false positives vs. false negatives), reflecting the binary (on/off) nature of actuator commands. Looking at the results, GPT-4.1-mini achieved perfect performance with a 100% success rate across all 60 runs, requiring no corrective reprompts. All iterations exhibited flawless action execution, with both action correctness (iterations achieving 100% correct actuator configuration) and action precision (ratio of correct actions to total actions) at 100%. In contrast, GPT-4o-mini succeeded in 51 of 60 runs (85%), with failures concentrated in two scenarios: pump_degradation (50% success) and sensor_fault (60% success). The recovery rate metric reveals that these failures stem from systematic errors rather than correctable mistakes: only 44% of runs requiring correction in pump_degradation and 33% in sensor_fault could be recovered through reprompting, compared to 100% recovery in all other scenarios. Failure analysis identified two distinct error patterns corresponding to different agent responsibilities (see Figure 6). In pump_degradation, the Action Agent exhibited unnecessary activations. While correctly identifying all required actuators (100% action recall), it additionally activated the main pump despite the degradation condition, resulting in an action precision of only 61.4% (71 false positive activations out of 184 total). This represents a separation-of-concerns violation where the Action Agent re-interpreted fault conditions that had already been resolved by the Planning Agent’s state selection. Consequently, only 52% of iterations achieved a fully correct actuator configuration. In sensor_fault, the failure originated at the planning stage, where plan correctness dropped to 64.6% as the model incorrectly selected bypass paths when the normal operational path remained viable. Notably, the Action Agent performed flawlessly in this scenario (100% action correctness, 100% action precision), indicating correct execution of flawed planning decisions. A notable finding across all experiments is that action recall was 100% for both models across all fault scenarios: no required actuator was ever omitted. All 780 expected activations for GPT-4.1-mini and all 895 (including necessary iterations with reprompts) for GPT-4o-mini were correctly issued. This indicates that the knowledge graph grounding successfully conveyed which actuators are associated with each state. The failures made by GPT-4o-mini arose exclusively from additional, non-permitted actuator activations beyond those specified in the knowledge graph, rather than from missing required activations. This asymmetric error pattern suggests that while the semantic grounding reliably leads to necessary actions, weaker models may inject additional "common-sense" reasoning that conflicts with the
J Vyas et al.: Preprint submitted to Elsevier
Table 1 Mixing Module operational results (𝑛 = 10 per scenario). Fault
Model
Succ.
Rec.
Time
Tok. In
Tok. Out
pump_fail.
GPT-4.1-mini GPT-4o-mini
10/10 10/10
– 100%
35.5 s 38.6 s
54.1k 60.4k
1.7k 1.4k
pump_deg.
GPT-4.1-mini GPT-4o-mini
10/10 5/10
– 44%
34.0 s 33.2 s
54.2k 43.2k
1.7k 1.2k
clogging
GPT 4.1-mini GPT-4o-mini
10/10 10/10
– 100%
33.7 s 50.5 s
54.2k 60.5k
1.8k 1.5k
sensor
GPT-4.1-mini GPT-4o-mini
10/10 6/10
– 33%
30.7 s 42.4 s
54.1k 63.1k
1.6k 1.5k
leak
GPT-4.1-mini GPT-4o-mini
10/10 10/10
– 100%
32.2 s 45.0 s
54.2k 63.7k
1.8k 1.6k
All
GPT-4.1-mini GPT-4o-mini
60/60 51/60
– 80%
32.7 s 40.7 s
54.1k 58.0k
1.7k 1.4k
Succ.=runs completing without errors; Rec.=recovery rate (successful corrections / runs needing correction, – = none needed); Time=mean wall-clock time; Tok. In/Out=input/output tokens (×103 ).
formal process specification. This motivates stronger planconditioned action schemas that restrict the Action Agent to the actuator set admissible for the selected recovery path. Both models demonstrated comparable decision latencies (GPT-4.1-mini: 2.4 s planning, 2.2 s action; GPT-4o-mini: 2.4 s planning, 3.0 s action). Mean wall-clock time was 32.7 s for GPT-4.1-mini and 40.7 s for GPT-4o-mini, with the difference attributable to reprompting overhead. The remaining wall-clock time is due to graph retrieval, repeated supervisory steps, simulation rollout, validation, orchestration, logging, and reprompting overhead. Token consumption averaged 55.8k for GPT-4.1-mini and 59.4k for GPT-4o-mini. Failed runs consumed approximately 43.1k tokens due to additional reprompt cycles before termination. GPT-4o-mini Correctness (%) GPT-4.1-mini: 100% everywhere pump_fail
92
100
100
100
100
pump_deg
95
52
61
100
90
clogging
94
94
94
100
sensor
65
100
100
100
leak
90
94
94
100
Plan
Act
Act Prec
Act Rec
80 70 60
Correctness (%)
5. Results
50
Figure 6: Plan and action correctness per fault scenario for the Mixing Module (GPT-4o-mini), covering recovery-path correctness (Plan), actuator-configuration correctness (Act), action precision, and action recall. GPT-4.1-mini achieved 100% across all cells.
5.2. CSTR results Table 2 summarizes the performance of the CSTR case study for three injected fault scenarios (fouling, pump_degrade, and cool_stuck_closed). In contrast to the Mixing Module, the CSTR recovery task is continuouscontrol dominated. Once the Monitoring Agent triggers an intervention during normal operation because of a fault being detected, the Action Agent must propose corrected setpoints (𝑇𝑠𝑝 , 𝐿𝑠𝑝 , 𝐹𝑖𝑛,𝑠𝑝 ) that satisfy safety constraints and recover regulation despite actuator limitations. Page 9 of 12
Using LLM Agents for Fault-Tolerant Control
A run is counted as successful only if a validated LLM proposal is applied without exceeding the reprompt limit. Concretely, success rate requires that (i) a setpoint intervention was applied, (ii) the validation passed, and (iii) the run did not hit the configured reprompt limit (here 5). Importantly, runs that rely on the deterministic fallback policy after exceeding the reprompt limit are counted as failures (even though the plant may remain operational). This choice aligns the metric with the paper’s objective, demonstrating that safe recovery is achieved by the LLM-generated control action rather than by a hard-coded controller. GPT-4.1-mini achieved a success rate of 28∕30 (93.3%) across all runs, while GPT-4o-mini achieved 23∕30 (76.7%). Both models solved pump_degrade reliably (10∕10), indicating that moderate loss of pumping effectiveness can be compensated with stable setpoint adaptations under the given acceptance criteria. The dominant failure mode arises under cool_stuck_ closed, which emulates a cooling limitation (cooling valve constrained near the closed region). Here, GPT-4.1-mini succeeded in all runs (10∕10), typically requiring reprompting (mean ≈ 2 reprompts) to converge to a safe setpoint triple. In contrast, GPT-4o-mini succeeded in only 4∕10 runs, with failures largely attributable to hitting the reprompt budget, i.e., repeated proposals that did not satisfy the rollout recovery requirement within the acceptance thresholds. Across successful and failed runs, GPT-4.1-mini shows lower mean per-call action latency (2.1 s vs. 2.7 s). Token consumption per run is comparable across models, with mean Action Agent input on the order of ∼13–15k tokens and output on the order of a few hundred tokens, reflecting that the prompt is dominated by the structured snapshot and knowledge graph context while the completion is constrained to a short JSON response. Compared to the Mixing Module, overall token usage per run is lower because the agent workflow is invoked less frequently. In the Mixing Module, the agents are called at each discrete supervisory step whenever a state transition is required, whereas in the CSTR case the decision loop is typically triggered only once per run. Table 2 CSTR operational results (𝑛 = 10 per scenario). Fault
Model
Succ.
Rec.
Time
Act.Lat
Tok. In
Tok. Out
fouling
GPT-4.1-mini GPT-4o-mini
8/10 9/10
43% 50%
50.5 s 42.7 s
1.9 s 2.3 s
15.0k 13.7k
0.2k 0.2k
pump_degrade
GPT-4.1-mini GPT-4o-mini
10/10 10/10
– –
51.1 s 36.8 s
1.9 s 2.4 s
13.7k 11.6k
0.2k 0.2k
cool_stuck_closed
GPT-4.1-mini GPT-4o-mini
10/10 4/10
100% 0%
54.0 s 50.5 s
2.4 s 3.5 s
13.5k 14.9k
0.3k 0.3k
All
GPT-4.1-mini GPT-4o-mini
28/30 23/30
75% 50%
51.9 s 43.3 s
2.1 s 2.7 s
14.1k 13.4k
0.2k 0.2k
Succ.=runs in which a validated LLM action was applied without exceeding the reprompt limit (fallback runs count as failures); Rec.=recovery rate among runs that required at least one reprompt (successful / reprompted); Wall=mean wall-clock time per run; Act.Lat=mean per-call Action Agent latency; Tok. In/Out=mean input/output tokens for the action agent (×103 ).
Under the fouling fault, the effective heat-transfer capability of the reactor degrades over time, reducing the ability of the cooling circuit to remove heat. As shown in Figure 7, this loss of heat exchange causes the cooling actuator J Vyas et al.: Preprint submitted to Elsevier
(a) Reactor temperature 𝑇 and setpoint 𝑇𝑠𝑝 (𝑡). The dashed marker indicates the validated LLM intervention; setpoints are masked during shutdown.
(b) Actuator positions during recovery, illustrating constrained cooling and coordinated valve/pump adjustments. Figure 7: Action Agent setpoint intervention for temperature recovery in the CSTR.
to progressively increase toward its upper limit, while the reactor temperature continues to rise and eventually exceeds the nominal safety threshold despite maximal cooling effort. Once further actuation is no longer effective, recovery is achieved by reducing the inlet flow setpoint, thereby lowering the heat generation rate and restoring thermal feasibility at the cost of reduced production. The resulting operating point reflects a deliberate trade-off enforced by the validated LLM intervention: stable operation under degraded heat transfer rather than full nominal throughput.
6. Discussion Drawing on the case study results, this section addresses the RQs, interprets the findings, discusses implications for LLM-based active FTC, and highlights limitations of the proposed framework. RQ1 (Knowledge Representation and Retrieval for LLM Grounding): The results demonstrate that Graph RAG-based retrieval provides sufficient grounding for LLM agents to derive correct FTC decisions. In particular, GPT-4.1-mini achieved 100 % plan and action correctness across all fault scenarios (apart from fouling), indicating that the semantic representation captured the plant-specific knowledge required for decision-making. The ontology-based representation enabled an unambiguous interpretation of process states, fault conditions, and admissible control actions by providing a shared, formally defined semantic context for both agents. The ontology proved effective in integrating heterogeneous engineering artifacts, including P&ID information, sensor–actuator mappings, control loops cause–effect relations, and behavioral specifications, into a unified semantic layer. By preserving relational semantics between system components, the knowledge graph allowed the Planning Agent to identify fault-dependent constraints on operational paths and to reason about viable alternatives without requiring explicit enumeration of all fault scenarios. These findings indicate Page 10 of 12
Using LLM Agents for Fault-Tolerant Control
that Graph RAG is a viable mechanism for contextualizing dispersed plant knowledge and supporting first-principles reasoning in active FTC. A key limitation lies in the effort required to construct the knowledge graph. The current implementation relies on structured inputs that, in industrial practice, are often available only in unstructured or semi-structured form. While automated extraction using LLMs or vision-language models could significantly reduce this effort, such approaches were beyond the scope of the present study. RQ2 (Synthesis and Validation of Recovery Plans): The Planning and the Action Agent successfully synthesized correct recovery plans and validated them through the simulation prior to execution. The Planning Agent consistently selected fault-appropriate state transitions, while the Action Agent derived actuator configurations aligned with the selected operational mode. The simulation effectively detected infeasible actions before execution, and reprompting enabled recovery from transient decision errors. The recovery rate metric revealed an important distinction between correctable and systematic errors. In scenarios where GPT-4o-mini failed (e.g. sensor_fault: 33% recovery for the Mixing Module, cool_stuck_closed: 0% recovery for the CSTR), the low recovery rates indicate that reprompting within the applied limits could not resolve the underlying reasoning failure. This contrasts with other scenarios achieving 100% recovery, where initial errors were successfully corrected through feedback. The implication is that validation and reprompting provide effective safeguards against transient errors, but they cannot compensate when the model lacks reliable fault localization. If the LLM cannot attribute the fault to a specific component or subsystem, or is not provided with localization context that constrains which recovery actions are admissible, it may repeatedly propose plausible yet inapplicable actions. A key limitation concerns the evaluation of unknown faults. The digital twin can only validate control actions against fault conditions that have been modeled a priori. Truly novel faults cannot be simulated without prior characterization. Furthermore, establishing a ground truth for planning decisions requires expert specification of expected recovery paths, which may not be available for complex or unprecedented fault combinations. RQ3 (Effectiveness and Timeliness of Corrective Actions): The framework demonstrated effective derivation of corrective control actions for both the Mixing Module (openloop, sequential batch process) and the CSTR (closed-loop, continuous control). GPT-4.1-mini achieved 100% success across all scenarios with mean wall-clock times of 32.7 s for the mixing module, indicating that the approach generalizes across different process characteristics and control paradigms. Per-decision latencies are acceptable for batch and supervisory control scenarios, where the process evolves slowly and interventions are needed every few seconds or minutes. However, these latencies preclude application to processes with hard real-time constraints. Safety-critical systems requiring millisecond responses would necessitate alternative architectures, such as offline policy synthesis. J Vyas et al.: Preprint submitted to Elsevier
Finally, scalability remains only initially characterized. Larger plants increase the relevant decision context, including candidate actions, interacting constraints, coupled faults, and grounding requirements, so future work must evaluate how recovery success and decision latency scale with this complexity. The framework is feasibility-first rather than optimality-first and does not estimate globally optimal recovery paths. It also assumes a representative DPPT; deployment under model mismatch, sensor noise, actuator degradation, or unmodelled dynamics would require uncertainty-aware validation, such as robust envelopes, online calibration, or interval bounds. Cloud-hosted LLMs are used only for research evaluation; industrial deployment would require onpremise/edge models, IT/OT segmentation, access control, audit logging, prompt-injection mitigation, and deterministic fallback.
7. Summary and outlook The presented work introduced an active FTC framework combining LLM-based agents, a digital twin, and a Graph RAG knowledge layer. Specialized Planning and Action Agents synthesize corrective actions that are validated in simulation before execution. Structured knowledge is provided through the CPSMod ontology, which unifies structural, functional, behavioral, and fault-related information for agent use. Evaluation on a Modular Mixing Unit and a Continuous Stirred-Tank Reactor demonstrated safe recovery across discrete supervisory and continuous closed-loop tasks, indicating that semantically grounded LLM agents with simulation-based validation provide a promising basis for active FTC. Future work will target automated knowledgegraph construction, larger coupled process systems, and tighter integration of fault detection/localization with recovery agents.
CRediT authorship contribution statement Javal Vyas: Writing - original draft, Conceptualization, Methodology, Investigation, Software, Validation. Milapji Singh Gill: Writing - original draft, Conceptualization, Methodology, Investigation, Software, Validation. Artan Markaj: Writing - review & editing, Software. Felix Gehlhoff: Review-Editing, Funding, Supervision. Mehmet Mercangöz: Review-Editing, Funding, Supervision.
Declaration of Generative AI and AI-assisted technologies in the writing process During the preparation of this work the authors used Generative AI for minor text refinements. After using this tool, the authors reviewed and edited the content as needed and take full responsibility for the content of the publication.
Data availability The code necessary to generate the presented results is openly available under https://github.com/AISL-a Page 11 of 12
Using LLM Agents for Fault-Tolerant Control
t-Imperial-College-London/ctrl-alt-recover. The reused standards-based ODPs and tools for their use are publicly maintained at https://github.com/hsu-aut.
Declaration of competing interest The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.
References Alhazmi, K., Albalawi, F., Sarathy, S.M., 2022. A reinforcement learningbased economic model predictive control framework for autonomous operation of chemical reactors. Chemical Engineering Journal 428, 130993. doi:10.1016/j.cej.2021.130993. Baldea, M., Georgiou, A.T., Gopaluni, B., Mercangöz, M., Pantelides, C.C., Sheth, K., Zavala, V.M., Georgakis, C., 2025. From automated to autonomous process operations. Computers & Chemical Engineering 196, 109064. doi:https://doi.org/10.1016/j.compchemeng.20 25.109064. Bloor, M., Ahmed, A., Kotecha, N., Mercangöz, M., Tsay, C., del RíoChanona, E.A., 2024. Control-informed reinforcement learning for chemical processes. Industrial & Engineering Chemistry Research URL: https://pubs.acs.org/doi/10.1021/acs.iecr.4c03233. Gill, M.S., Jeleniewski, T., Gehlhoff, F., Fay, A., 2025a. Representing timecontinuous behavior of cyber-physical systems in knowledge graphs, in: 2025 IEEE 30th International Conference on Emerging Technologies and Factory Automation (ETFA), pp. 1–8. doi:10.1109/ETFA65518. 2025.11205677. Gill, M.S., Reiche, L.T., Fay, A., 2022. Method for selecting Digital Twins of Entities in a System-of-Systems approach based on essential Information Attributes, in: 2022 IEEE 27th International Conference on Emerging Technologies and Factory Automation (ETFA), IEEE. pp. 1–8. doi:10.1109/ETFA52439.2022.9921489. Gill, M.S., Vyas, J., Markaj, A., Gehlhoff, F., Mercangöz, M., 2025b. Leveraging llm agents and digital twins for fault handling in process plants, in: 2025 IEEE 30th International Conference on Emerging Technologies and Factory Automation (ETFA), pp. 1–8. doi:10.1109/ ETFA65518.2025.11205597. Gill, M.S., Westermann, T., Steindl, G., Gehlhoff, F., Fay, A., 2024. Integrating Ontology Design with the CRISP-DM in the Context of Cyber-Physical Systems Maintenance, in: 2024 IEEE 29th ETFA, IEEE. pp. 1–8. doi:10.1109/ETFA61755.2024.10710898. Gowaikar, S., Iyengar, S., Segal, S., Kalyanaraman, S., 2024. An Agentic Approach to Automatic Creation of P&ID Diagrams from Natural Language Descriptions. doi:arXiv:2412.12898. Hildebrandt, C., Köcher, A., Kustner, C., Lopez-Enriquez, C.M., Muller, A.W., Caesar, B., Gundlach, C.S., Fay, A., 2020. Ontology Building for Cyber–Physical Systems: Application in the Manufacturing Domain. IEEE T-ASE 17, 1266–1282. doi:10.1109/TASE.2020.2991777. Jobs, N., da Silva, L.M.V., Somashekaraiah, J., Weigand, M., Kube, D., Gehlhoff, F., 2025. Benchmark for planning and control with large language model agents: Blocksworld with model context protocol. URL: https://arxiv.org/abs/2512.03955, arXiv:2512.03955. Kritzinger, W., Karner, M., Traar, G., Henjes, J., Sihn, W., 2018. Digital twin in manufacturing: A categorical literature review and classification. IFAC-PapersOnLine 51, 1016–1022. Lee, D., Kim, H., Choi, Y., Kim, J., 2021. Development of autonomous operation agent for normal and emergency situations in nuclear power plants, in: 2021 5th International Conference on System Reliability and Safety (ICSRS), IEEE. pp. 240–247. doi:10.1109/ICSRS53853.2021. 9660722. Lee, D., Lee, J., Shin, D., 2024. GPT Prompt Engineering for a Large Language Model-Based Process Improvement Generation System. Korean Journal of Chemical Engineering 41, 3263–3286. doi:10.1007/s118 14-024-00276-1.
J Vyas et al.: Preprint submitted to Elsevier
Manca, G., Fay, A., 2021. Detection of Historical Alarm Subsequences Using Alarm Events and a Coactivation Constraint. IEEE Access 9, 46851–46873. doi:10.1109/ACCESS.2021.3067837. Manee, V., Baratti, R., Romagnoli, J., 2022. Learning to navigate a crystallization model with deep reinforcement learning. Chemical Engineering Research and Design 178, 111–122. URL: https://ui.a dsabs.harvard.edu/abs/2022CERD..178..111M/abstract. Markaj, A., Mercangöz, M., Fay, A., 2024. Design and implementation of an Autonomous Systems Training Environment framework for control algorithm evaluation in autonomous plant operation. Computers & Chemical Engineering 189, 108798. doi:10.1016/j.compchemen g.2024.108798. Olivier, L.E., Craig, I.K., 2017. Model-based fault-tolerant control with robustness to unanticipated faults. IFAC-PapersOnLine 50, 1157–1162. doi:10.1016/j.ifacol.2017.08.401. Ovalle, D., Seth, A., Kitchin, J.R., Laird, C.D., Grossmann, I.E., 2025. GRAPSE: Graph-Based Retrieval Augmentation for Process Systems Engineering. Systems and Control Transactions , 1598–1604. Pajak, E., Bahamdan, A., Hellgardt, K., Ro-Chanona, A., 2025. MultiAgent LLMs for Automating Sustainable Operational Decision-Making, in: van Impe, J., Lonard, G., Bhonsale, S.S., Polanska, M., Logist, F. (Eds.), Proceedings of the 35th European Symposium on Computer Aided Process Engineering (ESCAPE 35), PSE PressHamilton, Canada. pp. 1824–1829. doi:10.69997/sct.156776. Reif, J., Jeleniewski, T., Gill, M.S., Gehlhoff, F., Fay, A., 2024. Chatbotbased ontology interaction using large language models and domainspecific standards, in: 2024 IEEE 29th International Conference on Emerging Technologies and Factory Automation (ETFA), pp. 1–4. doi:10.1109/ETFA61755.2024.10711065. Reinpold, L.M., Wagner, L.P., Gehlhoff, F., Ramonat, M., Kilthau, M., Gill, M.S., Reif, J.T., Henkel, V., Scholz, L., Fay, A., 2024. Systematic comparison of software agents and Digital Twins: differences, similarities, and synergies in industrial production. Journal of Intelligent Manufacturing doi:10.1007/s10845-023-02278-y. Rupprecht, S., Gao, Q., Karia, T., Schweidtmann, A.M., 2026. Multi-agent systems for chemical engineering: a review and perspective. Current Opinion in Chemical Engineering 51, 101209. doi:https://doi.org/ 10.1016/j.coche.2025.101209. Sakhinana, S.S., Sri Vaikunth, V., Runkana, V., 2024. Knowledge Graph Modeling-Driven Large Language Model Operating System (LLM OS) for Task Automation in Process Engineering Problem-Solving. Proceedings of the AAAI Symposium Series 4, 222–232. doi:10.1 609/aaaiss.v4i1.31796. Sitapure, N., Kwon, J.S., 2023. Crystalgpt: Enhancing system-to-system transferability of reinforcement learning agents for crystallization control. arXiv preprint URL: https://arxiv.org/abs/2306.03099. Song, L., Zhang, C., Zhao, L., Bian, J., 2023. Pre-trained large language models for industrial control. URL: https://arxiv.org/abs/2308 .03028, doi:10.48550/ARXIV.2308.03028. Srinivas, S.S., Gupta, S., Runkana, V., 2025. Autochemschematic ai: Agentic physics-aware automation for chemical manufacturing scale-up. URL: https://arxiv.org/abs/2505.24584, arXiv:2505.24584. Tang, X., Tian, Y., D., V.S., 2024. Recent advances in reinforcement learning for chemical process control. Processes 13, 1791. Tao, F., Zhang, H., Liu, A., Nee, A.Y.C., 2019. Digital Twin in Industry: State-of-the-Art. IEEE Transactions on Industrial Informatics 15, 2405– 2415. doi:10.1109/TII.2018.2873186. Vyas, J., Mercangöz, M., 2025. Autonomous Industrial Control using an Agentic Framework with Large Language Models. IFAC-PapersOnLine 59, 349–354. doi:10.1016/j.ifacol.2025.07.170. Webert, H., Döß, T., Kaupp, L., Simons, S., 2022. Fault Handling in Industry 4.0: Definition, Process and Applications. Sensors 22, 2205. doi:10.3390/s22062205. Xia, Y., Jazdi, N., Zhang, J., Shah, C., Weyrich, M., 2025. Control industrial automation system with large language model agents, in: 2025 IEEE 30th International Conference on Emerging Technologies and Factory Automation (ETFA), pp. 1–8. doi:10.1109/ETFA65518.2025.11205 539.
Page 12 of 12