Como criar prompts de IA para programação de CLP com filosofias de controle para o Yaga

A criação eficaz de prompts de IA para programação de CLP exige filosofias de controle estruturadas, e não solicitações genéricas. Quando os engenheiros fornecem mapeamentos de E/S, permissivas, intertravamentos, estados de sequência e condições de falha explícitos, o Yaga pode gerar estruturas de lógica ladder que são materialmente mais fáceis de validar dentro do ambiente de simulação do OLLA Lab.

A IA não falha no trabalho com CLP porque é "ruim em programação". Ela falha porque a lógica ladder não é apenas geração de código; é um comportamento de controle determinístico sob restrições, ordem de varredura (scan) e estados anormais. Essa distinção é frequentemente ignorada.

Durante um exercício beta interno recente do Yaga Assistant do OLLA Lab, prompts que incluíam um dicionário de tags, estado seguro definido e pelo menos um intertravamento explícito produziram estruturas de primeira passagem utilizáveis em simulação em 22 de 24 tarefas (91,7%), enquanto prompts genéricos como "escreva uma sequência de bomba" exigiram correções importantes em 17 de 24 tarefas (70,8%) antes que a simulação pudesse prosseguir. Metodologia: n=48 execuções de tarefas de prompt em exercícios de bomba, misturador, esteira e nível de tanque; comparador de linha de base = prompt de linguagem natural genérico versus prompt de filosofia de controle estruturado; janela de tempo = janela beta interna, fevereiro–março de 2026. Isso sustenta uma afirmação restrita: a estrutura do prompt afeta fortemente a usabilidade de primeira passagem na simulação. Não prova a capacidade de implantação em campo, suficiência de segurança ou prontidão para produção.

Na automação, a engenharia de prompt deve ser definida de forma restrita: a tradução sistemática de restrições mecânicas, mapeamento de E/S e intertravamentos de segurança em parâmetros legíveis por máquina, para que um agente de IA possa gerar estruturas sintaticamente corretas e testáveis. Essa é uma ferramenta útil, não um substituto para o julgamento de engenharia. O OLLA Lab é importante aqui como o ciclo de validação, não como uma autorização.

LLMs gerais falham na lógica ladder porque preveem sequências de tokens plausíveis, enquanto CLPs executam lógica de varredura determinística contra entradas e saídas com estado. Um modelo de linguagem vê continuidade de texto; um controlador vê ordem de avaliação, bits de memória, condições de borda e estado do dispositivo.

A lógica ladder também é espacial. Ramos paralelos, caminhos de selo, cadeias de permissivas e estados mutuamente exclusivos carregam significado através da estrutura, não apenas através de palavras. Um LLM de uso geral tende a linearizar essa estrutura em texto e pode perder a intenção de execução no processo. Esta é uma das razões pelas quais a lógica ladder gerada por IA pode parecer competente enquanto se comporta mal.

Um segundo modo de falha é a fraca consciência do ciclo de varredura (scan cycle). A lógica do CLP é avaliada repetidamente, e as saídas podem ser escritas, redefinidas ou substituídas dentro da mesma varredura, dependendo da estrutura do programa. Sem restrições explícitas, um LLM pode gerar:

• escritas duplicadas na mesma bobina de saída,
• comportamento de pulso único (one-shot) ausente,
• condições de corrida entre modos automático e manual,
• temporizadores com condições de reset pouco claras,
• limites analógicos sem histerese (deadband) ou tratamento de falhas,
• intertravamentos que aparecem em comentários, mas não na lógica executável.

O resultado comum é familiar aos profissionais: lógica que é bem lida, mas que se comporta mal assim que as entradas mudam. A sintaxe é barata; o determinismo é mais difícil.

Essa limitação é amplamente consistente com a literatura sobre raciocínio de LLM e confiabilidade de código. Trabalhos publicados em sistemas de software e sistemas incorporados sugerem que a qualidade da saída degrada quando as tarefas exigem rastreamento de estado persistente, raciocínio espacial ou satisfação exata de restrições, em vez de preenchimento de padrões fluentes (Bubeck et al., 2023; Huang & Chang, 2023). A programação de CLP é especialmente implacável em todos os três.

Um prompt de IA de nível industrial é uma especificação funcional compacta. Ele deve dizer ao modelo o que é a máquina, o que significa "seguro", quais dispositivos existem, quais condições devem ser verdadeiras antes que a ação seja permitida e como a falha deve ser tratada. Se o prompt não puder suportar uma revisão básica de Especificação de Design Funcional (FDS), provavelmente é muito vago para uma geração de ladder confiável.

Na prática, um bom prompt de CLP se comporta menos como uma consulta de pesquisa e mais como instruções para um engenheiro de controles júnior. Engenheiros seniores não dizem "faça-me um programa de bomba". Eles especificam o processo, as tags, a sequência, os disparos (trips) e o estado de fallback esperado.

Os 3 pilares de um prompt de automação

#### 1. Contexto e objetivo

Declare a máquina ou unidade de processo, o objetivo operacional e o estado seguro.

Inclua:

• tipo de equipamento,
• modo de operação,
• objetivo de partida/parada,
• condição de desligamento seguro,
• expectativa de estado anormal.

Exemplo:

• "Bomba de transferência única enche um tanque diário."
• "Estado seguro é bomba desligada e válvula de saída fechada."
• "Se o transmissor de nível for inválido, iniba a partida automática."

#### 2. Dicionário de E/S e tags

Defina as tags explicitamente. A IA tem melhor desempenho quando a nomenclatura é inequívoca e tipada.

Inclua:

• entradas digitais,
• saídas digitais,
• entradas analógicas,
• saídas analógicas, se relevante,
• bits de memória interna,
• temporizadores e contadores,
• bits de alarme ou falha.

Exemplo:

• `DI_PB_Start`
• `DI_PB_Stop`
• `DI_EStop_OK`
• `AI_Tank_Level_Pct`
• `DO_Pump_Run`
• `M_Auto_Mode`
• `T_FillTimeout`

A disciplina de nomenclatura não é cosmética. É a diferença entre lógica rastreável e um custo de depuração.

#### 3. Permissivas e intertravamentos

Defina o que deve ser verdadeiro antes que a ação possa ocorrer e o que força a parada da ação.

Inclua:

• permissivas,
• disparos (trips),
• restrições de modo,
• requisitos de feedback,
• comportamento de timeout,
• condições de alarme.

Exemplo:

• A bomba só pode partir se `DI_EStop_OK = TRUE`
• A bomba só pode partir se `AI_Tank_Level_Pct < 80`
• A bomba deve parar se `AI_Tank_Level_Pct >= 95`
• Disparar alarme se o comando de funcionamento for verdadeiro e não houver feedback de funcionamento em 3 segundos

É aqui que muitos prompts colapsam. Engenheiros frequentemente especificam o caminho feliz e omitem as razões pelas quais a máquina deve se recusar a mover. Plantas reais passam muito tempo em condições fora do normal.

Para prompts de IA, uma filosofia de controle deve ser definida como a especificação funcional mínima necessária para gerar estruturas de controle testáveis. Não é uma frase de marketing e não é uma narrativa de design vaga. Operacionalmente, deve conter os mesmos comportamentos centrais que um engenheiro de controles espera em um documento estilo FDS:

• estado inicial,
• modos de operação,
• sequência de operações,
• permissivas,
• intertravamentos,
• alarmes e disparos,
• respostas a falhas,
• comportamento de reset,
• ações do operador,
• critérios de sucesso.

Essa definição é limitada por observáveis de engenharia. Se o prompt não disser ao modelo o que o processo deve fazer quando um sensor falha, uma tampa abre, um nível excede o limite ou um feedback nunca chega, então o prompt não é uma filosofia de controle.

Este enquadramento alinha-se com a prática estabelecida de documentação industrial. A norma IEC 61131-3 rege as linguagens de programação de CLP, mas uma boa lógica ladder ainda depende da clareza funcional a montante. Padrões não salvam intenções vagas.

Um equívoco útil para aposentar

A engenharia de prompt na automação não é sobre tornar a IA mais criativa. É sobre tornar a especificação menos ambígua.

A maneira mais eficaz de solicitar ao Yaga é fornecer um modelo restrito e reutilizável. O modelo deve ser informado sobre a função, o objetivo do processo, as tags, a sequência, as permissivas, os intertravamentos e o formato de saída esperado. Se qualquer um desses for deixado implícito, o modelo pode improvisar.

Modelo de prompt recomendado para o Yaga

Atue como um assistente de lógica ladder IEC 61131-3.

Objetivo: Crie uma estrutura de lógica ladder para a seguinte tarefa de controle.

Descrição do Sistema: - Equipamento: [máquina/unidade de processo] - Objetivo operacional: [o que o sistema deve fazer] - Estado seguro: [quais saídas/estados devem ser verdadeiros quando parado ou com falha]

Dicionário de E/S e Tags: Entradas Digitais: - [tag]: [descrição] - [tag]: [descrição]

Saídas Digitais: - [tag]: [descrição]

Entradas Analógicas: - [tag]: [descrição e unidades de engenharia]

Bits Internos / Temporizadores / Contadores: - [tag]: [propósito]

Modos de Operação:

• [Automático / Manual / Manutenção]
• [regras de modo]

Sequência de Operações:

Permissivas:

• [condição necessária antes da partida]
• [condição necessária antes da transição]

Intertravamentos / Disparos:

• [condição que deve parar ou inibir a operação]
• [condição de falha e resposta]

Alarmes:

• [condição de alarme]
• [condição de timeout]

Regras de Reset / Recuperação:

• [requisito de reset manual]
• [regra de reset automático, se permitido]

Requisitos de Saída:

• Use uma estrutura ladder clara, degrau por degrau
• Não escreva na mesma bobina de saída em vários locais conflitantes
• Use bits internos nomeados para estados de sequência, quando necessário
• Inclua comentários para cada degrau
• Identifique as suposições explicitamente

Este modelo não garante a lógica correta. Ele faz algo mais útil: torna os erros visíveis mais cedo.

1. [passo 1]
2. [passo 2]
3. [passo 3]

Prompt júnior vs. prompt sênior

| Estilo de Prompt | Exemplo | Resultado Provável | |---|---|---| | Prompt júnior | "Faça um diagrama ladder que liga um misturador por 10 segundos quando eu pressionar start." | Comportamento de parada ambíguo, falta de intertravamento de tampa, lógica de reset pouco clara, estrutura de tags fraca | | Prompt sênior | "Atue como um programador IEC 61131-3. Crie uma estrutura ladder para um misturador. Entradas: `PB_Start` (NA), `PB_Stop` (NF), `LS_LidClosed`, `EStop_OK`. Saída: `MTR_Mixer`. Intertravamento: o misturador não pode funcionar a menos que a tampa esteja fechada e o E-stop esteja saudável. Use TON para ciclo de funcionamento de 10 s. Pare imediatamente na abertura da tampa ou comando de parada. Estado seguro = motor desligado. Forneça comentários nos degraus e identifique as suposições." | Linha de base testável com permissivas explícitas, comportamento de parada mais seguro, caminho de simulação mais claro |

A diferença não é a eloquência. É a densidade de restrições.

Um bom prompt de CLP deve definir a máquina como um sistema com estado, não como uma tarefa verbal. Antes que o Yaga escreva qualquer degrau, o prompt já deve responder a seis perguntas de engenharia.

1. O que é o sistema?

Defina o equipamento, o limite do processo e a operação pretendida.

Exemplo:

• "Estação de bombeamento duplex lead/lag com alarme de nível alto e alternância."

2. O que é comportamento "correto"?

Defina a condição de sucesso operacional em termos observáveis.

Exemplo:

• "No modo automático, a bomba principal parte em 70% do nível do poço úmido e para em 30%; a bomba reserva parte em 90%; ambas param no E-stop ou sobrecarga do motor."

Isso importa porque "pronto para simulação" deve ser definido operacionalmente: um engenheiro está pronto para simulação quando pode provar, observar, diagnosticar e endurecer a lógica de controle contra o comportamento realista do processo antes que ele chegue a um processo real. Esse é um padrão mais forte do que conhecer a sintaxe ladder.

3. Quais são as tags e tipos de sinal?

Liste as tags, a direção do sinal e as unidades.

Exemplo:

• `AI_WetWell_Level_Pct` = entrada analógica, porcentagem
• `DI_P1_OL_Trip` = entrada digital, disparo de sobrecarga
• `DO_P1_RunCmd` = saída digital

4. Quais condições anormais existem?

Defina falhas, estados inválidos e respostas a falhas.

Exemplo:

• qualidade ruim do transmissor de nível,
• feedback de funcionamento ausente após comando,
• ambas as sobrecargas ativas,
• E-stop não saudável,
• conflito de chave HOA.

5. O que nunca deve acontecer?

Declare o comportamento proibido explicitamente.

Exemplo:

• "Nunca comande ambas as bombas na lógica de alternância manual."
• "Não reinicie automaticamente após o reset de sobrecarga sem ação do operador."
• "Não ligue o misturador com a tampa aberta."

6. Quais suposições são permitidas?

Exija que a IA declare as suposições em vez de escondê-las.

Exemplo:

• "Assuma que o botão de parada está saudável (NF), a menos que declarado de outra forma."
• "Assuma que o escalonamento analógico já foi realizado a montante."

Suposições ocultas são uma fonte comum de lógica ladder fraca gerada por IA.

O OLLA Lab valida a lógica gerada por IA colocando-a dentro de um ambiente de simulação onde entradas, saídas, variáveis e comportamento do equipamento podem ser observados e manipulados antes que qualquer implantação real seja considerada. Isso o torna um ciclo de validação com risco contido, não um oráculo.

O editor ladder fornece a superfície lógica. O Modo de Simulação fornece a execução. O Painel de Variáveis fornece observabilidade em tags, estados de E/S, valores analógicos e variáveis de controle. Juntos, eles permitem que um engenheiro teste se a lógica gerada se comporta conforme especificado quando as condições mudam.

Em termos práticos, isso significa que você pode:

• alternar entradas digitais,
• forçar condições de falha,
• inspecionar a resposta da saída,
• observar temporizadores e bits internos mudarem de estado,
• comparar o estado ladder com o comportamento simulado do equipamento,
• revisar a lógica após um teste falho.

Validação não é uma captura de tela de um degrau que parece correto. Validação é uma sequência de suposições refutadas seguidas por uma lógica mais rigorosa.

Como é o ciclo gerar-validar

1. Gerar estrutura com o Yaga Use um prompt de filosofia de controle estruturado.
2. Inspecionar o ladder gerado Verifique nomes de tags, propriedade de saída, estrutura de sequência e posicionamento de intertravamento.
3. Executar a lógica em simulação Comece com condições nominais.
4. Injetar condições anormais Force perda de sensor, permissivas inválidas, estados de tampa aberta, disparos de sobrecarga ou casos de timeout.
5. Observar se a lógica falha com segurança Confirme parada segura, travamento de alarme, inibição de reinicialização ou retenção de estado conforme necessário.
6. Revisar e testar novamente Reforce o prompt ou edite o ladder diretamente.

É aqui que o OLLA Lab se torna operacionalmente útil. Ele dá aos engenheiros um lugar para ensaiar tarefas de alto risco para as quais sistemas reais são maus professores.

Você testa definindo casos de falha antes de confiar na sequência nominal. Uma rotina ladder que funciona apenas quando cada sinal se comporta não é validada; ela é apenas incontestada.

No mínimo, teste estas categorias em simulação.

Falhas de integridade de entrada

• sensor travado em nível alto,
• sensor travado em nível baixo,
• transmissor fora da faixa,
• valor analógico ruim,
• feedback ausente após comando.

Falhas de intertravamento

• E-stop não saudável,
• proteção ou tampa aberta,
• permissiva perdida durante o funcionamento,
• disparo de sobrecarga ativo,
• prova de válvula não feita.

Falhas de sequência

• temporizador nunca reseta,
• bit de estado permanece travado,
• comando manual e automático se sobrepõem,
• reinicialização ocorre após disparo sem reset,
• saída permanece energizada após caminho de parada.

Falhas relacionadas a analógicas e PID

• variável de processo excede o limite de disparo,
• falta de histerese (deadband) analógica,
• oscilação de alarme perto do limite,
• saída do controlador satura,
• transferência de modo causa solavanco.

A presença de ferramentas analógicas e painéis PID no OLLA Lab é importante aqui porque muitos exemplos de IA permanecem presos na lógica discreta. O controle de processo real geralmente não é. Uma estação de bombeamento, AHU, malha térmica ou skid de dosagem geralmente inclui limites, atrasos, histereses e comportamento dependente de modo.

Um exemplo prático deve mostrar a tradução da intenção do processo para restrições legíveis por máquina. Abaixo está um exemplo de misturador compacto adequado para o Yaga.

Exemplo de prompt estruturado

Atue como um assistente de lógica ladder IEC 61131-3.

Descrição do Sistema: - Equipamento: Misturador de lote - Objetivo operacional: Operar o misturador por 10 segundos após o comando de partida do operador - Estado seguro: Motor do misturador desligado imediatamente na parada, perda de E-stop ou tampa aberta

Dicionário de E/S e Tags: Entradas Digitais: - DI_PB_Start: Botão de partida, normalmente aberto - DI_PB_Stop: Botão de parada, normalmente fechado - DI_Lid_Closed: Prova de tampa fechada - DI_EStop_OK: E-stop saudável

Saídas Digitais: - DO_Mixer_Run: Comando de funcionamento do motor do misturador

Bits Internos / Temporizadores: - M_Mix_Cycle_Active: Travamento de ciclo de mistura ativo - T_Mix_Run: Temporizador TON de 10 segundos

Sequência de Operações:

Permissivas:

• DI_Lid_Closed = TRUE
• DI_EStop_OK = TRUE
• DI_PB_Stop saudável

Intertravamentos / Disparos:

• Se a tampa abrir durante o funcionamento, desenergize DO_Mixer_Run imediatamente
• Se o E-stop não estiver saudável, desenergize DO_Mixer_Run imediatamente

Requisitos de Saída:

• Forneça estrutura ladder degrau por degrau
• Use um caminho de propriedade de saída para DO_Mixer_Run
• Adicione comentários nos degraus
• Declare quaisquer suposições

1. No comando de partida, inicie o ciclo de mistura apenas se a tampa estiver fechada e o E-stop estiver saudável
2. Opere o motor do misturador por 10 segundos
3. Pare o motor quando o temporizador terminar
4. Aborte imediatamente se houver comando de parada, tampa aberta ou E-stop não saudável

O que verificar após a geração

Após o Yaga gerar o ladder, inspecione:

• um caminho de propriedade claro para `DO_Mixer_Run`,
• habilitação do temporizador vinculada ao estado de ciclo ativo,
• queda imediata na abertura da tampa ou perda de E-stop,
• sem reinicialização automática oculta,
• comentários que correspondem ao comportamento real do degrau,
• suposições explícitas.

Em seguida, execute-o em simulação e force `DI_Lid_Closed` como falso durante o funcionamento temporizado. Se o comando do motor persistir, o prompt ou a lógica estão errados.

Os engenheiros devem documentar o trabalho de CLP assistido por IA como evidência de engenharia, não como uma galeria de capturas de tela de interface. Um registro credível mostra o que o sistema deveria fazer, como foi testado, como falhou e como foi corrigido.

Use esta estrutura:

Registre a falha exata introduzida: perda de sensor, sobrecarga, queda de permissiva, timeout, valor analógico inválido, e assim por diante.

1. Descrição do Sistema Defina o equipamento, o objetivo do processo, o modo de operação e o estado seguro.
2. Definição operacional de "correto" Declare os critérios de sucesso observáveis, incluindo condições de parada e comportamento de estado anormal.
3. Lógica ladder e estado do equipamento simulado Mostre o ladder gerado ou editado ao lado do estado da máquina simulada ou comportamento da variável relevante.
4. O caso de falha injetado
5. A revisão feita Documente a mudança de lógica ou refinamento de prompt usado para corrigir o comportamento.
6. Lições aprendidas Declare o que a falha revelou sobre a filosofia de controle original, suposições ou design de sequência.

Sua documentação produz um corpo compacto de evidências que é útil para revisores, instrutores ou gerentes de contratação.

Os prompts de CLP assistidos por IA são úteis para estruturação, rascunho e aceleração da estrutura lógica de primeira passagem. Não são suficientes para validação de segurança, aprovação de comissionamento ou decisões de implantação específicas do local.

Esse limite é importante tanto para a ética quanto para a engenharia. O OLLA Lab é descrito aqui como um simulador de lógica ladder e gêmeo digital interativo baseado na web, com suporte guiado através do Yaga, simulações 3D/WebXR/VR, exercícios baseados em cenários, ferramentas analógicas e PID, e fluxos de trabalho de instrutor. Esses recursos o tornam útil como um ambiente de ensaio e validação. Eles não convertem a lógica gerada em lógica de planta aprovada por associação.

Alguns limites devem permanecer explícitos:

• O ladder gerado por IA pode ser sintaticamente plausível e funcionalmente inseguro.
• A simulação pode expor muitos defeitos lógicos, mas não é idêntica ao comissionamento no local.
• A validação do gêmeo digital depende da fidelidade do modelo e do escopo do cenário.
• As obrigações de segurança funcional ainda exigem métodos formais, revisão competente e disciplina de ciclo de vida baseada em padrões.

Isso é consistente com a literatura de segurança mais ampla. A norma IEC 61508 e orientações relacionadas tratam falhas sistemáticas, erros de especificação e disciplina de verificação como preocupações centrais. Um modelo que produz código rapidamente não remove esses deveres.

Essa abordagem é mais útil porque muda a tarefa de uma geração sem restrições para uma engenharia delimitada. Quando você escreve uma filosofia de controle primeiro, você força as decisões importantes a virem à tona: estado seguro, permissivas, disparos, propriedade de sequência e resposta a falhas.

Isso tem três benefícios práticos:

• melhor estrutura de primeira passagem,
• depuração mais rápida em simulação,
• revisão mais clara por humanos.

Também ensina o hábito correto. A transição profissional não é apenas de não saber ladder para saber ladder. É de escrever degraus para defender o comportamento.

- Visão geral da norma IEC 61131-3 (PLCopen) - NIST AI Risk Management Framework (AI RMF 1.0) - Visão geral das Diretrizes de Acessibilidade para Conteúdo Web (WCAG) 2 da W3C - Portal de taxonomia e publicações do IEEE - Página da norma de gestão de risco de IA ISO/IEC 23894