Resumo Técnico: Da Detecção à Ação – Utilizando Agentes de LLM para Controle com Tolerância a Falhas

Declaração do Problema

Apesar dos avanços na automação, as operações da indústria de processos ainda dependem fortemente da experiência humana para a tomada de decisão sob condições imprevistas, particularmente quando os dados são limitados ou o comportamento do sistema desvia dos padrões esperados. As plantas de processo enfrentam desafios como fluxos de energia e materiais fortemente acoplados, sintomas de falhas sutis dependentes do estado e inundações de alarmes que sobrecarregam os operadores. As abordagens atuais de Inteligência Artificial (IA), como o Aprendizado por Reforço (RL), enfrentam barreiras à adoção, incluindo baixa eficiência de amostragem, generalização limitada e a necessidade de funções de recompensa cuidadosamente projetadas. Além disso, embora os Grandes Modelos de Linguagem (LLMs) ofereçam potencial para orquestração de ponta a ponta, sua implantação em Controle com Tolerância a Falhas (FTC) de missão crítica é dificultada por três lacunas específicas:

1. Fundamentação (Grounding): O conhecimento da planta está fragmentado em artefatos heterogêneos (P&IDs, listas de intertravamento, registros de manutenção), e a recuperação apenas de texto frequentemente falha em capturar as relações complexas necessárias para ações corretivas.
2. Garantia (Assurance): As ações propostas carecem de rastros auditáveis e verificações explícitas de viabilidade contra intertravamentos, envelopes operacionais e física do processo antes da execução.
3. Tempestividade/Robustez: A recuperação deve operar sob dinâmica híbrida e observabilidade parcial, onde ações atrasadas ou incorretas podem ser inseguras.

Metodologia

Os autores propõem um framework de agentes de LLM para FTC ativo que transforma saídas de detecção de falhas em ações de recuperação conscientes de restrições. O framework opera em dois espaços: um Espaço Físico (a planta de processo e sistemas de segurança) e um Espaço Virtual (contendo uma Camada de Agente e uma Camada de Ferramentas).

1. Camada de Ferramentas (Tool Layer)

A Camada de Ferramentas fornece a infraestrutura necessária para os agentes:

• Gêmeo Digital do Processo Industrial (DPPT): Uma pilha de ferramentas executável contendo dados da planta, modelos baseados em física/dados e serviços de simulação. Ela suporta o monitoramento de condições e a validação pré-execução de ações corretivas.
• Geração Aumentada de Recuperação Baseada em Grafos (Graph RAG): Para abordar a lacuna de fundamentação, os autores utilizam um grafo de conhecimento baseado em ontologia construído sobre a ontologia CPSMod. Esta integra artefatos de engenharia heterogêneos em uma representação interpretável por máquina. A ontologia combina cinco Padrões de Design de Ontologia (ODPs) baseados em padrões que cobrem estrutura (VDI 2206), função e fluxos (VDI 3682), comportamento discreto (Máquina de Estados UML), comportamento contínuo (OpenMath) e diagnóstico de falhas (DIN 17359). Os agentes utilizam consultas SPARQL para recuperar contexto orientado a relações e de múltiplos saltos, vinculando equipamentos, lógica de controle, modos de operação e semântica de falhas.

2. Camada de Agentes (Agent Layer)

O framework decompõe os deveres do operador em um fluxo de trabalho multi-agente envolvendo seis agentes especializados:

• Agente de Monitoramento: Um componente determinístico/baseado em dados que detecta falhas comparando valores de processo contra linhas de base estatísticas ou modelos baseados em dados.
• Agente de Planejamento: Um agente baseado em LLM que recupera funções relevantes do sistema e comportamentos de máquina de estados do grafo de conhecimento. Ele percorre o grafo de máquina de estados para propor caminhos de recuperação de risco mínimo do estado de falha atual para um estado operacional alvo.
• Agente de Ação: Um agente baseado em LLM que sintetiza ações de controle corretivas específicas (comandos discretos ou adaptações de setpoint contínuas) com base no caminho selecionado e nas capacidades de atuação da planta. Ele garante que as ações respeitem intertravamentos, limites e restrições de taxa.
• Agente de Simulação: Invoca o serviço de simulação do DPPT para testar se as ações propostas podem levar o sistema a um estado válido sem violar dinâmicas ou restrições.
• Agente de Validação: Um agente determinístico que avalia as saídas de simulação contra critérios de segurança (intertravamentos, envelopes, tempo de recuperação, desempenho de malha) para aprovar ou rejeitar a ação.
• Agente de Reprompting: Coordena um loop de refinamento iterativo. Se a validação falhar, ele gera feedback estruturado (ex: "violação de envelope", "guarda não atendida") e solicita novamente ao Agente de Planejamento ou de Ação para refinar o plano.
  Se nenhum plano aceitável for encontrado dentro de uma janela de tempo delimitada, o controle é entregue a um sistema de fallback de segurança.

Principais Contribuições

O artigo apresenta três contribuições primárias para abordar as lacunas identificadas:

1. Fundamentação Orientada a Relações: O uso de uma ontologia e Graph RAG permite a recuperação de dependências acionáveis de múltiplos saltos, vinculando equipamentos, lógica de controle e semântica de falhas, fundamentando assim os agentes de LLM no conhecimento específico da planta.
2. Garantia de Segurança via Validação: O framework impõe segurança através de planos de recuperação mínimos e explicáveis que passam por validação pré-execução determinística (intertravamentos, envelopes, viabilidade dinâmica) e mantêm um rastro de decisão auditável através de um fluxo de trabalho multi-agente.
3. Operação de Latência Limitada: O sistema suporta a operação sob restrições de tempo através de monitoramento assistido por ferramentas, geração de ação restrita e um mecanismo de fallback de segurança caso um plano válido não possa ser sintetizado a tempo.

Resultados Experimentais

O framework foi avaliado em dois benchmarks: um Módulo de Mistura discreto e um Reator de Tanque Agitado Contínuo (CSTR) contínuo. Dois LLMs leves foram testados: GPT-4.1-mini e GPT-4o-mini.

Módulo de Mistura (Controle Discreto)

• O GPT-4.1-mini alcançou uma taxa de sucesso de 100% em 60 execuções (10 por cenário de falha), com 100% de correção e precisão de ação. Não exigiu reprompts corretivos.
• O GPT-4o-mini alcançou uma taxa de sucesso de 85% (51/60 execuções). As falhas concentraram-se em pump_degradation (50% de sucesso) e sensor_fault (60% de sucesso). A análise mostrou que, embora o GPT-4o-mini tenha identificado corretamente os atuadores necessários (100% de recall), ele ocasionalmente ativava atuadores desnecessários (menor precisão) ou selecionava caminhos de bypass incorretos durante o planejamento.
• Latência: O tempo médio de relógio (wall-clock time) foi de 32,7s para o GPT-4.1-mini e 40,7s para o GPT-4o-mini.

CSTR (Controle Contínuo)

• O GPT-4.1-mini alcançou uma taxa de sucesso de 93,3% (28/30 execuções). Ele lidou com sucesso com os cenários de fouling, pump_degrade e cool_stuck_closed, muitas vezes exigindo reprompting para convergir para setpoints seguros.
• O GPT-4o-mini alcançou uma taxa de sucesso de 76,7% (23/30 execuções). Ele teve dificuldades significativas com o cenário cool_stuck_closed (4/10 sucessos), atingindo frequentemente o limite de reprompt devido a propostas repetidas que falharam em satisfazer os requisitos de recuperação.
• Desempenho: O GPT-4.1-mini demonstrou menor latência de ação por chamada (2,1s vs. 2,7s) e consumo de tokens comparável.

Significância e Alegações

O artigo alega demonstrar um caminho prático da detecção de falhas à ação corretiva validada para tarefas de FTC tanto discretas quanto contínuas. Os autores afirmam que:

• Agentes semanticamente fundamentados podem derivar decisões de recuperação válidas dentro de orçamentos de latência compatíveis com a dinâmica do processo (segundos a dezenas de segundos), tornando-os adequados para controle supervisório e de lote (batch), mas não para sistemas de tempo real estrito.
• Graph RAG é um mecanismo viável para contextualizar o conhecimento disperso da planta, permitindo que os agentes raciocinem sobre restrições dependentes de falhas sem a enumeração explícita de todos os cenários de falha.
• A validação baseada em simulação filtra efetivamente ações inviáveis, e o reprompting pode corrigir erros de decisão transitórios, embora não possa compensar falhas de raciocínio sistemáticas ou falhas não modeladas.

Os autores mantêm uma postura modesta, observando que o framework é focado primeiro em "viabilidade" e não em "otimalidade". Eles reconhecem limitações quanto ao esforço necessário para construir grafos de conhecimento, a incapacidade de simular falhas verdadeiramente novas sem caracterização prévia e a dependência atual de modelos hospedados em nuvem para pesquisa, o que exigiria implantação on-premise e segmentação IT/OT para uso industrial. O trabalho não pretende substituir totalmente os operadores humanos, mas sim fornecer uma camada robusta de suporte à decisão autônoma para FTC ativo.