Milapji Singh Gill*, Javal Vyas ${}^{†}$, Artan Markaj*, Felix Gehlhoff*, Mehmet Mercangöz ${}^{†}$
*自动化技术研究所
Helmut Schmidt汉堡大学，德国
{milapji.gill, artan.markaj, felix.gehlhoff}@hsu-hh.de
${}^{†}$ 自主工业系统实验室,
伦敦帝国理工学院，英国
{j.vyas24, m.mercangoz}@imperial.ac.uk

索引词—LLM代理，工艺厂，自主性，数字孪生，人工智能，故障处理

摘要—自动化和人工智能领域的进步不断增强了工艺厂在处理各种操作场景时的自主性。然而，诸如故障处理等任务仍然具有挑战性，因为它们高度依赖于人类的专业知识。这突显了对系统化、基于知识的方法的需求。为了解决这一问题，我们提出了一种将大型语言模型（LLM）代理与数字孪生环境相结合的方法论框架。LLM代理持续解释系统状态并启动控制动作，包括对意外故障的响应，其目标是使系统恢复到正常运行状态。在此背景下，数字孪生既作为特定工厂工程知识的结构化存储库以供代理提示，也作为生成的纠正控制动作的系统验证和验证的模拟平台。使用工艺厂的一个混合模块进行的评估表明，所提出的框架不仅能够自主控制混合模块，而且还能通过少量重新提示生成有效的纠正措施以缓解管道堵塞。

I. 引言

现代自动化系统已经简化了许多工业环境中的常规操作，但故障处理仍然是认知要求高且主要为手动的过程。需要经验丰富的操作员立即对异常行为做出反应，并选择适当的纠正控制动作 [1]。这些任务通常是高度情境化的，难以概括，并且通常在时间压力下执行。在如工艺厂等复杂的技术系统中，相同的可观察症状可能源自多个根本原因，每个原因都需要不同的响应 [2]-[4]。这种模糊性很少被预定义的操作员指令或静态故障处理策略捕捉到，使得人类专业知识不可或缺 [1]。因此，故障处理不仅劳动密集型，而且容易出错，在某些情况下还涉及安全关键因素。这些挑战，加上工厂复杂性的增加以及劳动力人口结构的变化导致经验丰富的操作员短缺，突显了对更自主解决方案的迫切需求 [1], [3]。

为了应对这些局限性，最近的研究转向了人工智能（AI）方法 [3], [5], [6]。机器学习（ML）在检测异常方面有效，因为它可以识别与预期行为的偏差 [4]，但通常缺乏为新型故障类型提供具体、可执行响应的能力。相比之下，大型语言模型（LLMs）因其先进的推理和泛化能力而受到广泛关注。与传统的ML模型不同，LLMs提供了一个灵活的推理机制，使其适应各种工业控制应用 [7], [8]。然而，在工艺厂内的故障处理方面仍存在几个挑战。LLMs通常缺乏特定工厂的知识 [9]，这些知识可以从系统工程工件中提取 [10]，从而导致幻觉和不安全的工厂状态。此外，故障处理通常需要顺序推理步骤 [11]。自主可靠地执行这些步骤，特别是对未知故障类型的响应，需要的不仅仅是孤立的AI组件。它需要感知、推理和行动的结构化协调。因此，要有效地开发和部署基于LLM的故障处理解决方案到技术系统中，一个可重用的方法论框架是必不可少的。这引出了以下开放的研究问题（RQs）：

• RQ1: 如何设计一种方法论框架，使LLMs能够在工艺厂中处理未知故障类型，同时可靠地确保其提出的纠正措施的操作安全性？
• • RQ2: 系统工程信息是否可以帮助LLMs生成和执行有效的纠正措施？如果可以，它应该如何在提示中表示？
    本文其余部分的结构如下：第II节提供了关于工艺厂中的故障处理和最近LLM技术进展的背景，激励了其在自主故障处理中的潜在用途。第III节回顾了基于LLM的工厂控制的相关工作。基于这些见解，第IV节推导了所提议框架的要求。第V节介绍了该框架，包括一种提示工程方法。第VI节展示了使用混合模块的实验设置和评估结果。关键发现将在第VII节中讨论，第VIII节总结了本文并展望了未来的研究方向。

II. 背景

A. 工艺厂中的故障处理

在现代工艺厂中，故障处理依赖于通过控制系统、仪表盘和报警机制对过程参数进行连续监控。
偏离正常操作会触发警报，促使操作员评估情况并确定纠正控制动作 [1], [3]。此评估基于过程变量之间因果依赖关系的知识 [12]，并要求根据历史趋势和工厂特定经验解读实时数据 [3], [13]。基于此，操作员发起纠正动作以稳定系统或将系统转换到安全状态，通常手动或通过控制逻辑 [1]。
为了支持这项任务，操作员使用各种系统工程工件，包括管道和仪表图（P&ID）、状态机、控制逻辑、程序、仿真模型和警报日志 [13], [14]。这些涵盖了三个语义层：结构性（组件拓扑），功能性（材料、能量和信号流），以及行为性（系统动态）模型 [3], [4]。数字孪生概念已被探索以整合这些特定工厂的知识，包括数据、数字模型和服务，形成物理系统的结构化表示，以增强决策支持 [5], [15]。

B. 大型语言模型

最近，LLMs因其高级推理能力而备受关注，使其适用于跨多种上下文的复杂决策 [7], [8]。一般来说，LLMs是基于变压器架构的预训练模型，根据从大量文本数据集中学习到的模式预测序列中的下一个标记 [16]。LLMs仅基于语言模式运行，没有直接的物理环境基础 [17]。尽管它们不具备内部环境模型，LLMs可以从文本输入中推断出可能的延续或结论 [18]。
尽管如此，建议在提示中明确编码任务特定信息，从而使提示工程成为领域知识和模型行为之间的关键接口。根据任务复杂性、领域特异性和可靠性要求，使用零/少样本提示、链式思维推理、结构化模板和指令微调等技术来引导模型输出 [8], [19]。在此背景下，检索增强生成（RAG）机制可以动态补充提示，但在实时或安全关键应用中，延迟和复杂性可能会限制其使用 [9]。因此，在使用LLMs时，仔细平衡信息量和相关性至关重要。上下文不足会增加幻觉的风险，而不规则输入可能会削弱模型提取相关信息的能力 [18]。
虽然单独的LLMs仍然是被动的语言处理器，最近的LLM代理进展将LLMs与外部工具、内存、API和规划机制集成，以实现迭代问题解决和目标导向的行为 [7]。与静态提示不同，基于代理的架构允许主动任务分解、结构化数据检索和功能执行，支持更复杂的流程，例如技术系统的控制 [7], [8]。鉴于这些能力，LLM代理在自主故障处理方面显得特别有前景，因此构成了我们在以下章节中描述的方法的重点。

III. 相关工作

最近的研究调查了将LLMs集成到工业控制应用中的框架，这些框架将LLMs嵌入到自动化和控制工作流中。

例如，在加热、通风和空调（HVAC）系统中，LLMs已应用于控制任务，其性能与基于强化学习（RL）的方法相当甚至更优 [20]。与此同时，其他研究人员专注于使用LLMs生成可编程逻辑控制器（PLC）代码。通过迭代用户引导的管道和外部验证工具，解决了传统PLC编程的局限性。这项工作最终发展出了LLM4PLC包 [21]。以此为基础，Agent4PLC框架引入了一个由LLMs驱动的多代理架构，并扩展了代码级验证、链式思维提示和RAG技术，以支持更强大的工业控制场景 [22]。

其他针对模块化和批量生产过程的框架展示了如何通过LLM代理协调原子控制功能序列以完成复杂任务 [7]。在此背景下，端到端自动化也被提出，将LLMs嵌入工业控制管道以进行更广泛的系统管理任务。Xia等人 [7] 提出了一种基于LLM的代理用于协调模块化生产过程。在这里，LLM代理嵌入在数字孪生环境中和自动化系统中，根据结构化指令计划和控制操作。通过资产管理系统和REST接口实现了模块化控制。这种基于代理的系统在模块化生产环境中提供了更大的灵活性和适应性。尽管该框架强调了LLM的编排能力，但它不包括检测或响应操作中的故障的机制。在另一项工作中，Xia等人 [19] 还提出了使用LLM代理来增强技术系统中的失效模式与影响分析（FMEA）以进行风险管理。这种方法使用多代理架构和RAG方法丰富传统的FMEA表的内容。虽然这支持了系统的文档编制和风险识别，但该方法限于静态分析，并不包括操作。

总之，尽管最近取得了进展，当前的研究主要集中在过程规划和编排以及与过程工厂相关的文本文档的静态分析上。这凸显了需要概念来实现安全和适应性强的LLM代理故障处理。

IV. 需求

基于第二章和第三章的见解，我们定义了方法论框架的需求（R）：
(R1) 分布式任务分配：方法论框架必须能够将整体故障处理过程分解为独立解决特定子任务（如监控、故障检测以及控制和纠正控制动作）的相互作用组件 [11]。同时，协作是必要的，以确保这些子任务间的连贯决策。这种模块化反映了技术系统中故障处理的固有分布性质 [23]。
(R2) 适应性故障处理推理能力：方法论框架必须包含能够进行自适应推理和推断的智能组件，以便自主推导、调整和证明对先前未知或不确定故障情景的纠正控制动作 [11]。这种能力在故障处理中至关重要，因为刚性基于规则的系统往往无法解决新出现或特定于上下文的问题。
(R3) 闭环动作验证与验证：方法论框架必须支持所提出的纠正控制动作的自动验证和验证机制，以确保安全可靠的流程执行。这包括监控动作效果并在检测到不良行为时进行迭代改进 [8], [11]。此外，此循环必须考虑最大允许时间窗口，在此时间内必须识别出有效的纠正控制动作，以最小化故障检测与实施之间的延迟。如果在此时间范围内无法得出有效解决方案，则必须触发人工干预或预定义的安全机制 [8]。
(R4) 包含领域知识：方法论框架必须支持将特定领域的系统知识集成到推理过程中，这些知识与故障情境相关 [3], [4]。由于LLMs缺乏直接的物理系统基础 [17]，结构化的领域输入对于实现有效的推理和可靠的故障处理至关重要。
(R5) 透明且可追踪的决策制定：方法论框架必须确保决策制定过程的透明度和可追踪性，使人类操作员能够理解为何及如何提出或执行某些纠正控制动作。这对于系统验证和持续改进至关重要，同时也是在安全关键情况下实现人工干预的必要条件 [24]。

V. 工艺厂自主故障处理的方法论框架

A. 框架

接下来，我们介绍一种方法论框架，该框架集成了数字工艺厂孪生和一种结构化的方法来协调基于LLM的代理，以增强工业工艺厂中故障处理的自主性。图1展示了所提议框架的概述。遵循网络物理系统（CPSs）的常见结构，该架构分为物理空间和虚拟空间。物理空间包含现实世界的工艺厂，而虚拟空间则承载方法论框架的不同组件。两个空间紧密相连，并持续交换信息。物理工艺厂由各种相互连接的物理组件组成。除了管道系统外，关键元素还包括阀门、泵、混合器和储罐，它们相互作用以执行所需的操作。信息流在方法内由实线表示，指示代理之间的直接信息流。相反，虚线表示方法内数字工艺厂孪生的使用。

为了从手动故障处理过渡到自主故障处理，结构化的反馈驱动方法通过迭代改进代理响应来减少人工干预，同时保持操作安全性。为此，框架将操作员职责分布在反映常见故障处理认知能力的不同交互代理上（参见R1）。该方法包括监控代理、行动代理、验证代理和重新提示代理。当需要认知能力时，这些代理结合了人工智能方法。特别是，使用LLMs的原因在于它们能够从示例中泛化，并根据结构化上下文推断出可能的纠正控制动作，如第II节所述，并在R2中指定。这使它们特别适合于支持在数据不完整或故障症状模糊的系统中的故障处理。代理之间的核心交互遵循闭环结构，确保生成的纠正控制动作的可追溯性、有效性及可验证性（参见R3）。在方法中，代理可以访问封装在数字孪生数据、数字模型和服务中的特定工厂知识（参见R4）。此外，它们还可以反馈新的数据和见解。这种紧密集成确保代理在最新的工艺厂表示上运行，同时不断丰富数字孪生的知识库。为了确保决策过程的透明性和可追溯性，框架采用了链式思维提示策略（参见R5）。这种方法使LLM代理能够明确阐述每个纠正控制动作的推理，从而支持事后解释、验证和人工监督。

该方法始于虚拟空间中的监控代理。此代理使用传感器数据、性能监视器、警报指示器和诊断阈值观察物理工厂的当前状态。它根据与标称行为的偏差识别潜在的故障症状。如果没有检测到故障症状，则执行下一个控制动作以维持正常的过程操作。如果检测到故障症状，行动代理利用基于LLM的方法根据当前系统状态合成纠正控制动作。通过咨询数字工艺厂孪生提供的特定工厂信息、以前的交互和替代动作，代理生成一组潜在的有助于缓解故障的有效纠正控制动作。这些提出的动作在仿真中进行测试，该仿真作为服务从数字工艺厂孪生中访问，以评估其影响和潜在的意外后果。该仿真作为工艺厂的虚拟副本，提供了一个无风险的环境，在这里生成的纠正控制动作可以在不暴露工厂的情况下得到验证和验证

图1：基于代理的方法论框架用于自主故障处理。
额外的危害。此外，它允许在各种模拟故障条件下精细调整纠正控制动作。模拟后，验证代理在评估纠正控制动作的可行性、安全性和总体有效性方面发挥着至关重要的作用。它确保任何拟议用于实际部署的动作都严格遵守操作协议和安全标准。出于验证目的，可以应用各种方法。其中，可以包括一个成本函数，该函数综合了多个影响因素，如过程稳定性、能耗或控制努力，以评估生成动作的适用性。在初始纠正控制动作未能满足所需的验证标准的情况下，重新提示代理进行干预。该代理通过纳入来自模拟的反馈迭代优化纠正策略。通过连续的迭代，重新提示代理优化所提出的响应，直到识别出有效的解决方案。一旦纠正控制动作通过验证（见图1，决策点Safe），纠正控制动作就会传递给工艺厂。安全系统充当回退机制，当在规定的迭代次数后找不到有效的纠正控制动作时，这些系统实现预定义的紧急协议，包括关闭程序或人工干预。

在本贡献中，我们特别关注行动代理、模拟、验证代理和重新提示代理之间的迭代循环，因为这些执行了所提议框架的基本方法步骤。为了推导纠正控制动作，必须向LLMs提供有关工艺厂的相关信息。

以下子部分V-B详细说明了行动代理和重新提示代理采用的提示工程策略，这两个都是循环中的关键组件。

B. 使用数字孪生信息的LLM代理提示工程

为了有效和高效地生成纠正控制动作，我们设计了一种提示结构，为两个LLM代理（行动代理和重新提示代理）提供任务和工厂特定的知识。

提示通常分为三个主要部分：<代理描述>、<工厂描述> 和 <代理动作>。每个主要部分又包含更具体的子部分，提供详细的上下文信息，以支持LLM的推理和决策。图2展示了为行动代理使用的提示摘录。查看<代理描述>部分，代理接收到[角色]，概述其责任。然后以[目标]和[任务]的形式描述主要任务。<代理动作>部分指定了从LLM获得的[预期输出]，然后由第六节描述的脚本处理，以在循环中重新执行、验证和验证所提议的纠正控制动作。我们方法中提示的关键部分是<工厂描述>部分，它提供工厂特定的信息。它详细说明了[工厂功能]、[工厂结构]以及[工厂行为]中的预期过程序列。为了确保情境意识，提示动态地
整合了[当前工厂状态]。此提示结构符合系统工程原则，其中系统在概念上通过结构、功能和行为来描述 [10]。结构方面可以从工程工件如P&ID中得出。功能角色描述每个组件如何为过程目标做出贡献，而行为逻辑使用有限状态机等正式模型进行编码，以表示状态转换和因果依赖。这支持LLM代理理解允许的动作和转换条件。

提示设计的一个重要特点是，<工厂描述>被视为形式化程度不同的变量输入。这种方法使得可以在工厂生命周期中使用异构建模表示格式。

支持的输入格式范围从非正式的基于文本的规范和半正式模型如SysML类图到正式表示如仿真代码或领域特定本体 [5], [7]。虽然LLM并不直接操作这些模型，但它们的内容被转换为结构化的自然语言或图形到文本渲染以进行提示集成。这种设计选择将提示格式与底层建模形式主义解耦，从而增强了架构在不同领域和抽象层次上的通用性和可扩展性。将此信息直接嵌入提示中确保了LLM代理在推理时具有一致且完整的相关上下文，而不会因运行时检索而产生延迟或不一致性。

VI. 评估

A. 实验设置和实现

我们的实验设置基于Ehrhardt等人 [25] 引入的基准，旨在评估模块化工厂中基于AI的诊断、重新配置和规划。该基准中提供的模拟模型描述了一个混合模块，包含阻塞、泄漏和泵降级等参数化故障类型，使其适合评估所提出的方法论框架。图3所示的混合模块在Open Modelica中实现。它模拟了一个四罐系统（tank_B201 - tank_B204），带有一个中央泵（pump_P101）和可控阀门（例如valve_in0）。液体填充到tank_B201 - tank_B203，并依次转移到tank_B204。状态转换通过离散逻辑块管理，条件监测基于液位传感器（例如sensor_discrete_tank_B203_high）、压力传感器（例如sensor_continuous_pressure _tank_B202）和体积流量率（sensor_continuous_volumeFlowRate）。作为一个测试案例，我们专注于一个阻塞故障场景，该场景需要多步推理。在这种设置中，LLM必须首先根据传感器值独立检测异常条件，然后通过增加pump_P101的功率进行响应。鉴于潜在的控制

图2：提供给Action Agent和Reprompting Action的示例自然文本信息的提示结构。
选项数量，此场景呈现了一个非平凡的故障条件，用于评估基于实际重新提示次数生成的动作的可靠性和效率。

为了实现所提出的方法论框架，我们使用了用Python实现的模块化编排。在这个案例研究中，Action Agent被实现为PlantOperatorCrew，Validation Agent为validation_script.py，Reprompting Agent为PlantStrategyCrew。main.py脚本协调(i) 模拟植物模型、(ii) 数字孪生和 (iii) 使用CrewAI实现的基于LLM的代理之间的迭代交互。初始条件、执行器状态和故障参数通过基于字典的配置传递。在每次迭代中，当前植物状态传递给PlantOperatorCrew，后者使用LLM（在我们的情况下为GPT-40或GPT-40 mini）根据结构化的提示格式提出纠正控制动作。如第五节B部分所述，该格式通过两个YAML文件（agents.yaml和task.yaml）实现（见图2）。植物状态、故障配置和模拟参数在一个集中的JSON配置文件中定义，该文件作为模块之间的持久接口。

由代理提出的控制动作被写回到这个JSON文件并应用于数字孪生模拟。如果这些动作根据validation_script.py中指定的规则被认为是有效的，则相应更新模拟植物模型。否则，PlantStrategyCrew基于标记的问题生成改进的建议。

图3：包含所有相关执行器的混合模块

这个循环继续进行，直到达到停止条件（即tank_B204达到目标水平）。每一步都会记录工厂状态、控制动作和令牌使用情况。CSV导出（plant_op.csv、digital_twin_op.csv和11m_plant_op.csv）使工厂性能和提示效率的进一步分析成为可能。该控制循环的伪代码摘要显示在算法1中。为了最小化LLM响应的差异并确保模拟运行的可重复性，我们将GPT-40和GPT-40 mini的温度参数设置为零。这种确定性设置允许相同的提示始终产生相同的结果，减少了多次模拟运行的需要。所实现的框架可在GitHub上获取${}^1$。

算法1：用于混合模块的LLM引导控制循环
输入：带有故障参数的初始工厂状态（例如，阻塞）
输出：执行器设置、工厂轨迹、LLM令牌使用日志
初始化工厂状态并启动RouterFlow；
当未终止时做
监控：从工厂模拟中更新过程状态；
生成动作：调用PlantOperatorCrew根据当前状态和故障类型提出动作；
模拟：使用digital_twin()将动作应用于数字孪生；
验证：使用validation_script.py检查动作和泵功率的有效性；
如果动作有效，则
执行：使用plant()将动作转发到真实工厂模型；
否则如果reprop < max_itr 则
重新提示：使用PlantStrategyCrew生成新建议；
否则
强制执行：将当前动作传递给工厂（回退）；
记录过程数据（CSV）、令牌使用情况和重新提示统计信息；
如果tank_B204达到目标水平，则
终止 ← True;
导出结果：保存plant_op.csv、digital_twin_op.csv、11m_plant_op.csv；

B. 评估指标

为了评估该框架，我们定义了评估其生成纠正动作的可靠性和所需重新提示的效率的指标，直接解决了RQs。

RQ1针对的是LLMs在确保运营安全的同时自主管理不可预见故障的能力，这通过评估行动质量和闭环决策的效率来解决。在所展示的案例研究中，期望的纠正动作是增加Pump_P101的泵功率以补偿阻塞故障。为了评估目的，行动质量通过五个具体指标进行操作化：正确动作的数量、错误阀动作的数量、错误泵动作的数量、遗漏阀动作的数量和遗漏泵动作的数量。这些指标量化了代理控制的执行器设置是否解决了故障并稳定了工艺厂，而没有引入不良副作用。在此背景下，总动作数定义为正确和错误动作数之和，而预期动作数对应于正确和遗漏动作数之和。此外，我们跟踪重新提示数，代表达到有效纠正控制动作所需的迭代次数，作为效率的指标。较少的重新提示表示更快的决策，而较高的值反映增加的LLM推理努力。相比之下，RQ2探讨了启用有效和可靠控制决策所需的特定工厂信息的类型和表示。我们的假设基于系统工程原则，即功能、结构和行为导致有效的纠正动作。我们比较了三种<工厂描述>的提示格式：(i) 系统的自然语言描述（文本），(ii) 结构化的OpenModelica代码（Modelica代码），以及(iii) 现有的工程工件，例如状态机（SM）和P&ID提供的绘图的矢量格式。虽然所有格式都包含系统级信息，但它们的表示方式有所不同。评估旨在分析这些不同的格式如何影响结果的行动质量。此外，测量了令牌数以评估每种表示所需的输入量，提供潜在计算成本的指示。

C. 结果

表格I和II中的结果显示，所提出的框架在所有表示中大多数情况下成功产生了正确的动作。对于GPT-40，文本输入导致了完美的控制性能（15/15 正确动作），没有任何错误动作，并且只需要一次重新提示，表明优秀的循环收敛。SM+P&ID格式表现也很好（14/15 正确），几乎没有错误，并且重新提示次数适中（5）。Modelica代码格式取得了良好的结果（12/15 正确），尽管它引入了一些遗漏的泵动作（3）和更高的重新提示计数（6），表明Modelica代码中的行为信息更难让LLM可靠地解释。

${}^1$ https://github.com/AISL-at-Imperial-College-London/ fault-handling-agentic-llms-for-controlled-operations

指标	<工厂	描述>
	文本	Modelica代码	SM + P&ID
动作汇总
动作数	15	12	14
预期动作数	15	15	15
动作质量
正确动作数	15	12	14
错误阀动作数	0	0	0
错误泵动作数	0	0	0
遗漏阀动作数	0	0	0
遗漏泵动作数	0	3	1
效率
重新提示次数	1	6	5
令牌使用
令牌数(K)	16.2	81.4	27.2

表I：GPT-4o在不同输入表示下的性能。

GPT-40-mini表现出类似的趋势。SM+P&ID格式在正确动作方面取得了强劲的表现（13/15），但需要更多的重新提示（9），表明稍低的推理效率。同样，文本输入产生了13/15的正确动作，且重新提示次数适中（6）。再次，Modelica代码表示显示出最弱的表现，有多次遗漏的泵动作和错误的阀动作，以及最高的重新提示次数（10）。后者再次表明，Modelica代码格式对LLM解释嵌入的行为逻辑构成挑战，加强了早期的观察。

表I和表II中报告的令牌使用在表示之间变化很大。Modelica代码格式导致最高的令牌消耗（高达113 K），而文本格式保持最高效。这确认了表示方式不仅影响控制性能，还影响计算成本。

VII. 讨论

表I和表II表明，所提出的方法论框架能够可靠地生成工艺厂故障处理的纠正控制动作。GPT-40和GPT-40-mini在所有测试的<工厂描述>表示中都达到了大量的正确动作，特别是对于文本变体（GPT-40为15/15，GPT-40-mini为13/15）和SM+P&ID格式（GPT-40为14/15，GPT-40-mini为13/15）。大多数运行只需少量重新提示（1-6），表明稳定的循环收敛和最小的计算开销。即使面对更复杂的输入，如Modelica代码格式，该框架也能保持可接受的性能，尽管错误动作、遗漏动作和令牌数量有所增加。

GPT-40-mini表现出类似的趋势。SM+P&ID格式在正确动作方面表现出色（13/15），但需要更多重新提示（9），表明稍低的推理效率。同样，文本输入产生了13/15的正确动作，且重新提示次数适中（6）。再次，Modelica代码表示显示出最弱的表现，有多次遗漏的泵动作和错误的阀动作，以及最高的重新提示次数（10）。后者再次表明，Modelica代码格式对LLM解释嵌入的行为逻辑构成挑战，加强了早期的观察。

表I和表II中的令牌使用在表示之间变化很大。Modelica代码格式导致最高的令牌消耗（高达113 K），而文本格式保持最高效。这确认了表示方式不仅影响控制性能，还影响计算成本。

VII. 讨论

表I和表II表明，所提出的方法论框架能够可靠地生成工艺厂故障处理的纠正控制动作。GPT-40和GPT-40-mini在所有测试的<工厂描述>表示中都达到了大量的正确动作，特别是对于文本变体（GPT-40为15/15，GPT-40-mini为13/15）和SM+P&ID格式（GPT-40为14/15，GPT-40-mini为13/15）。大多数运行只需少量重新提示（1-6），表明稳定的循环收敛和最小的计算开销。即使面对更复杂的输入，如Modelica代码格式，该框架也能保持可接受的性能，尽管错误动作、遗漏动作和令牌数量有所增加。

指标	<工厂	描述>
	文本	Modelica代码	SM + P&ID
动作汇总
动作数	13	14	14
预期动作数	15	15	15
动作质量
正确动作数	13	12	13
错误阀动作数	0	2	1
错误泵动作数	0	0	0
遗漏阀动作数	0	0	0
遗漏泵动作数	2	3	2
效率
重新提示次数	6	10	9
令牌使用
令牌数(K)	33.9	113.0	40.5

表II：GPT-4o-mini在不同输入表示下的性能。

这些发现表明，如第五节所述的方法论框架可以成功应用于支持模块化工艺厂的自主故障处理，解决RQ1。尽管如此，尽管结果是可以接受的，但技术系统如工艺厂需要非常高的可靠性和安全性，这意味着需要进一步完善以实现一致的完美结果。关于RQ2，结果表明，根据系统工程原则结构化提示，特别是通过表示系统的结构、功能和行为，有助于生成适当的纠正动作。由于数字孪生通常维护此类结构化信息，它们为将生命周期工程数据整合到此类框架内的提示工程过程中提供了有价值的依据。

尽管结果令人鼓舞，但所提出的框架仍有局限性。首先，本研究重点放在批次生产过程上。连续时间系统表现出更复杂的动态特性，可能需要额外的领域知识、更多的重新提示，从而导致更长的延迟。其次，尽管结果支持选择性信息提供，但当前LLM的有限上下文窗口限制了每次迭代中可以处理的系统结构化内容的数量。RAG可能会缓解这一点，但会引入
额外的延迟。最后，实验设置只考虑了整个工厂的一个模块。更复杂的多模块设置，拥有更多的执行器和传感器，可能会增加故障处理的难度。

VIII. 总结与展望

为了逐步提高工艺厂故障处理的自主性并减少人工干预的需求，本文引入了一种将基于LLM的代理与数字工艺厂孪生集成的方法论框架。该框架旨在识别故障，推导出合适的纠正控制动作，并通过闭环模拟验证这些动作，然后再将其应用于物理工厂。该架构的核心是一个涉及行动代理、模拟、验证代理和重新提示代理的迭代周期，共同确保提出的动作不仅有效而且安全。为了增强LLM在这一领域的推理能力，开发了一种基于系统工程原则的定制提示工程，将从结构、行为和功能模型中提取的特定工厂知识嵌入其中。将该框架应用于模拟的模块化工艺厂表明，可以高效地生成有效的纠正控制动作。

未来的工作应纳入更具表现力的行为模型，如基于微分方程的描述，以更好地反映物理系统的连续动态并扩大基于模拟的验证。集成RAG可以使LLM代理实时访问结构化的工厂数据或文档，增强上下文推理。互补的符号AI方法，如基于ML的异常检测，可能进一步增强监控代理预测故障的能力。为了解决LLM代理和模拟之间闭环交互中的延迟问题，必须减少迭代时间。有希望的方法包括并行模拟、有针对性的状态更新以及用于更快响应估计的代理或降阶模型。

致谢

本研究[项目ProMoDi]由德联邦国防军数字化与技术研究中心（dtec.bw）资助。dtec.bw由欧盟-NextGenerationEU资助。感谢ABB对伦敦帝国理工学院自主工业系统实验室的资金支持。前两位作者对该工作做出了同等贡献。

参考文献

[1] A. Markaj, M. Mercangöz, and A. Fay, “Design and implementation of an Autonomous Systems Training Environment framework for control algorithm evaluation in autonomous plant operation,” Computers & Chemical Engineering, vol. 189, p. 108798, 2024.
[2] H. Webert, T. Döß et al., “Fault Handling in Industry 4.0: Definition, Process and Applications,” Sensors, vol. 22, no. 6, p. 2205, 2022.
[3] G. Manca and A. Fay, “Detection of Historical Alarm Subsequences Using Alarm Events and a Coactivation Constraint,” IEEE Access, vol. 9, pp. 46 851-46 873, 2021.
[4] T. Westermann, M. S. Gill, and A. Fay, “Representing Timed Automata and Timing Anomalies of Cyber-Physical Production Systems in Knowledge Graphs,” in IECON 2023-49th Annual Conference of the IEEE Industrial Electronics Society, 2023, pp. 1-7.
[5] M. S. Gill, T. Westermann et al., “Integrating Ontology Design with the CRISP-DM in the Context of Cyber-Physical Systems Maintenance,” in 2024 IEEE 29th International Conference on Emerging Technologies and Factory Automation (ETFA), 2024, pp. 1-8.
[6] Y. Liu, P. Ramin et al., “Transforming data into actionable knowledge for fault detection, diagnosis and prognosis in urban wastewater systems with AI techniques: A mini-review,” Process Safety and Environmental Protection, vol. 172, pp. 501-512, 2023.
[7] Y. Xia, M. Shenoy et al., “Towards autonomous system: flexible modular production system enhanced with large language model agents,” in 2023 IEEE 28th International Conference on Emerging Technologies and Factory Automation (ETFA), 2023, pp. 1-8.
[8] J. Vyas and M. Mercangöz, “Autonomous industrial control using an agentic framework with large language models,” 2024. [Online]. Available: https://arxiv.org/abs/2411.05904
[9] P. Lewis, E. Perez et al., “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks,” 2020. [Online]. Available: http://arxiv.org/pdf/2005.11401
[10] C. Hildebrandt, A. Scholz et al., “Semantic modeling for collaboration and cooperation of systems in the production domain,” in 2017 22nd IEEE International Conference on Emerging Technologies and Factory Automation. Piscataway, NJ: IEEE, 2017, pp. 1-8.
[11] L. Piardi, A. S. de Oliveira et al., “Collaborative fault tolerance for cyber-physical systems: The detection stage,” Computers in Industry, vol. 166, p. 104253, 2025.
[12] L. Abele, M. Anic et al., “Combining Knowledge Modeling and Machine Learning for Alarm Root Cause Analysis,” IFAC Proceedings Volumes, vol. 46, no. 9, pp. 1843-1848, 2013.
[13] J. Thambirajah, L. Benabbas et al., “Cause-and-effect analysis in chemical processes utilizing XML, plant connectivity and quantitative process history,” Computers & Chemical Engineering, vol. 33, no. 2, pp. 503-512, 2009.
[14] D. Kirchhübel, M. Lind, and O. Ravn, “Combining operations documentation and data to diagnose procedure execution,” Computers & Chemical Engineering, vol. 140, p. 106940, 2020.
[15] F. Tao, H. Zhang et al., “Digital Twin in Industry: State-of-the-Art,” IEEE Transactions on Industrial Informatics, vol. 15, no. 4, pp. 2405-2415, 2019.
[16] Ashish Vaswani, Noam Shazzer et al., “Attention is All you Need,” 2017. [Online]. Available: https://arxiv.org/abs/1706.03762
[17] J. Liang, W. Huang et al., “Code as Policies: Language Model Programs for Embodied Control.”
[18] S. Bubeck, V. Chandrasekaran et al., “Sparks of Artificial General Intelligence: Early experiments with GPT-4,” 2023. [Online]. Available: http://arxiv.org/pdf/2303.12712
[19] Y. Xia, N. Jazdi, and M. Weyrich, “Enhance FMEA with Large Language Models for Assisted Risk Management in Technical Processes and Products,” in 2024 IEEE 29th International Conference on Emerging Technologies and Factory Automation (ETFA), 2024, pp. 1-4.
[20] L. Song, C. Zhang et al., “Pre-trained large language models for industrial control,” 2023. [Online]. Available: https://arxiv.org/abs/2308.03028
[21] M. Fakih, R. Dharmaji et al., “Llm4plc: Harnessing large language models for verifiable programming of plcs in industrial control systems,” in Proceedings of the 46th International Conference on Software Engineering: Software Engineering in Practice, ser. ICSE-SEIP '24. ACM, Apr. 2024, p. 192-203.
[22] Z. Liu, R. Zeng et al., “Agents4plc: Automating closed-loop plc code generation and verification in industrial control systems using Ilm-based agents,” 2024. [Online]. Available: https://arxiv.org/abs/2410.14209
[23] M. Cerrada, J. Cardillo et al., “Agents-based design for fault management systems in industrial processes,” Computers in Industry, vol. 58, no. 4, pp. 313-328, 2007.
[24] L. Cummins, A. Sommers et al., “Explainable Predictive Maintenance: A Survey of Current Methods, Challenges and Opportunities,” IEEE Access, vol. 12, pp. $57574-57602,2024$.
[25] J. Ehrhardt, M. Ramonat et al., “An AI benchmark for diagnosis, reconfiguration & planning,” in 2022 IEEE 27th International Conference on Emerging Technologies and Factory Automation (ETFA), 2022, pp. 1-8.

参考论文：https://arxiv.org/pdf/2505.02076