Como programar lógica de máquina de estados em um CLP para um motor trifásico

Para programar a lógica de máquina de estados em um CLP, os engenheiros dividem a sequência da máquina em estados mutuamente exclusivos e realizam a transição entre eles de forma explícita. Para um motor trifásico, isso geralmente significa estados baseados em números inteiros como Desligado (Off), Partida (Starting), Operação (Running), Parada (Stopping) e Falha (Fault), que são mais fáceis de validar, solucionar problemas e robustecer do que a lógica de selo aninhada.

A lógica de selo aninhada não é "boa o suficiente" apenas porque funciona no primeiro teste. No controle sequencial, a lógica booleana que parece organizada em uma tela estática ainda pode produzir condições de corrida (race conditions), caminhos de recuperação ambíguos e comportamento dependente do ciclo de varredura (scan) quando as entradas oscilam ou falhas ocorrem no meio da sequência.

Durante os testes internos do preset de motor trifásico da Ampergon Vallis no OLLA Lab, a substituição de contatos de selo aninhados por uma máquina de estados finitos explícita baseada em inteiros reduziu os eventos de falha por condição de corrida observados em 87% durante testes de parada anormal simulada [Metodologia: n=30 execuções de simulação da mesma tarefa de motor trifásico, comparador de base de selo aninhado, janela de teste fevereiro-março de 2026]. Isso sustenta uma afirmação delimitada sobre um preset de treinamento interno sob injeção de falha simulada. Não estabelece uma taxa universal de redução de defeitos em todas as arquiteturas de CLP, plantas ou aplicações de motores.

Essa distinção é importante. As falhas de comissionamento geralmente nascem em condições de contorno, não no caminho ideal.

A lógica de máquina de estados finitos (FSM) é superior para controle sequencial porque torna o comportamento da máquina explícito, mutuamente exclusivo e determinístico. Uma FSM construída corretamente permite que o CLP avalie as regras para o estado atual e, em seguida, faça a transição apenas quando as condições definidas forem atendidas.

As rungs de selo aninhadas fazem o oposto. Elas frequentemente espalham a memória da sequência por vários bits, permissivos, selos e intertravamentos que interagem indiretamente. O resultado é uma lógica que pode até funcionar, mas apenas até que o tempo, a perda de feedback ou um desligamento anormal exponham o acoplamento oculto. Sintaxe não é a mesma coisa que capacidade de implantação.

A norma IEC 61131-3 não exige um padrão sequencial universal, mas seu modelo de organização de programa apoia fortemente a lógica de controle estruturada, legível e sustentável para sequenciamento baseado em estados em aplicações de CLP (IEC, 2013). Na prática, as FSMs tornaram-se uma arquitetura comum para sequências de máquinas porque são mais fáceis de raciocinar, testar e recuperar após falhas.

Uma definição operacional útil é esta:

- Máquina de Estados Finitos em lógica ladder: uma arquitetura de controle na qual uma variável de estado representa o modo atual da máquina, apenas um estado válido está ativo por vez e as transições ocorrem por meio de condições explícitas que atribuem o próximo estado.

Essa última cláusula é o ponto principal. Se a transição não for explícita, a máquina está dependendo de efeitos colaterais.

Lógica "Cebola" vs. Arquitetura de Máquina de Estados

| Fator de Engenharia | Selo Aninhado / "Lógica Cebola" | Máquina de Estados Finitos | |---|---|---| | Memória de sequência ativa | Distribuída entre bits e selos | Centralizada em uma variável de estado | | Comportamento do ciclo de varredura | Pode tornar-se sensível à ordem e ambíguo | Determinístico quando as transições são explícitas | | Recuperação de falha | Frequentemente inferida de várias condições | Estado de falha explícito, ex: `99` | | Solução de problemas | Rastrear muitos bits interativos | Ler o inteiro do estado atual primeiro | | Expansão da sequência | Frágil à medida que as ramificações crescem | Mais fácil inserir estados intermediários | | Validação em simulação | Mais difícil isolar o caminho da falha | Teste claro transição por transição |

Engenheiros de controle seniores rejeitam a lógica cebola pela mesma razão que rejeitam fiação de campo sem identificação: o sistema pode até funcionar, mas ninguém deveria ter que adivinhar o porquê.

Uma sequência de motor trifásico requer mais do que um bit de Liga e Desliga, porque o equipamento real possui comportamento de transição, temporização de feedback e tratamento de falhas. Mesmo um simples arrancador de motor geralmente precisa de tratamento explícito de permissivos, confirmação de partida, comportamento de parada e recuperação de desarme.

Uma FSM prática para um motor trifásico usa comumente estes estados:

1. Estado 0 — Desligado / Pronto O motor está desenergizado. Os permissivos necessários estão saudáveis. A sequência aguarda um comando de Partida válido.
2. Estado 10 — Partida A saída de partida foi emitida. A lógica aguarda o feedback esperado, como prova de contato auxiliar, status de operação, confirmação de velocidade ou uma janela de tempo de partida.
3. Estado 20 — Operação O motor está em operação em regime permanente. A lógica continua a monitorar comandos de parada, sobrecargas, perda de permissivos e feedback anormal.
4. Estado 30 — Parada Um comando de parada ou desligamento controlado foi iniciado. A lógica aguarda a confirmação de desenergização, feedback de velocidade zero ou conclusão do tempo limite.
5. Estado 99 — Falha Ocorreu um desarme, falha de prova, sobrecarga ou condição de sequência inválida. As saídas são levadas para a resposta segura definida, e a lógica de reset é tratada explicitamente.

Usar incrementos de 10 é um hábito prático de engenharia porque deixa espaço para a inserção posterior de estados como `15 = Verificação de Partida` ou `25 = Confirmação de Parada por Inércia` sem renumerar toda a sequência.

Por que os estados de transição são importantes no controle real de motores

Os estados de transição existem porque os motores interagem com a realidade elétrica e mecânica, não apenas com símbolos ladder. Dependendo da aplicação, a sequência de controle pode precisar considerar:

• tempo de fechamento do contator
• temporização de transferência estrela-triângulo
• aceleração e desaceleração de VFD
• feedback de prova de contatos auxiliares
• perda de permissivo durante a operação
• desarmes de relé de sobrecarga
• intertravamentos de processo a jusante
• confirmação de velocidade zero ou parado

É aqui também que "Pronto para Simulação" precisa de uma definição precisa.

- Pronto para Simulação: capaz de provar, observar, diagnosticar e robustecer a lógica de controle contra o comportamento realista do processo antes que ele chegue a um processo real.

Isso significa mais do que escrever uma rung que compila. Significa validar se o estado ladder, o estado de E/S e o estado do equipamento simulado permanecem coerentes sob condições normais e anormais.

Uma FSM baseada em ladder é construída lendo o estado atual com um comparador e escrevendo o próximo estado com um movimento (MOV) explícito. No OLLA Lab, esse trabalho ocorre no editor ladder, no painel de variáveis e no modo de simulação.

O OLLA Lab deve ser entendido aqui como um ambiente de validação e ensaio delimitado. É útil porque permite que os engenheiros pratiquem comportamentos de comissionamento de alto risco, como validação de lógica, observação de E/S, injeção de falhas e revisão, sem usar equipamentos reais como auxílio de ensino.

### Passo 1: Definir o inteiro de estado

Crie uma tag como:

- `Motor_State` : `INT`

Este inteiro é a única fonte da verdade para o estado da sequência atual da máquina.

Tags complementares recomendadas incluem:

• `Start_PB`
• `Stop_PB`
• `OL_Trip`
• `Aux_Run_Proof`
• `Reset_PB`
• `Motor_Output`
• `Start_Timer.DN`
• `Stop_Timer.DN`

### Passo 2: Construir a transição de Desligado para Partida

A primeira transição geralmente move o motor do estado pronto para o estado de partida quando os permissivos e uma solicitação de partida estão presentes.

Exemplo de conceito de lógica:

• Se `Motor_State = 0`
• e `Start_PB = TRUE`
• e nenhum desarme está ativo
• e os permissivos necessários estão saudáveis
• então `MOV 10` para `Motor_State`

Este é o padrão básico:

• `EQU(Motor_State, 0)`
• `XIC(Start_PB)`
• `XIO(OL_Trip)`
• `XIC(Permissive_OK)`
• `MOV(10, Motor_State)`

### Passo 3: Construir a transição de Partida para Operação

O estado de partida deve confirmar que o motor realmente atingiu a condição esperada. Essa confirmação pode ser um contato auxiliar, feedback de operação, prova de fluxo, prova de rotação ou uma condição de tempo, dependendo da aplicação.

Exemplo de conceito de lógica:

• Se `Motor_State = 10`
• e `Aux_Run_Proof = TRUE`
• então `MOV 20` para `Motor_State`

Se a prova não for recebida dentro do tempo permitido, transite para falha.

• Se `Motor_State = 10`
• e `Start_Timer.DN = TRUE`
• e `Aux_Run_Proof = FALSE`
• então `MOV 99` para `Motor_State`

### Passo 4: Construir a transição de Operação para Parada

O estado de operação deve monitorar tanto paradas comandadas quanto condições anormais.

Exemplo de conceito de lógica:

• Se `Motor_State = 20`
• e `Stop_PB = TRUE`
• então `MOV 30` para `Motor_State`

Inclua também o tratamento de desarme:

• Se `Motor_State = 20`
• e `OL_Trip = TRUE`
• então `MOV 99` para `Motor_State`

### Passo 5: Construir a transição de Parada para Desligado

O estado de parada deve aguardar o motor atingir a condição de parado esperada.

Exemplo de conceito de lógica:

• Se `Motor_State = 30`
• e a confirmação de parado for verdadeira
• então `MOV 0` para `Motor_State`

Onde não existe prova física de parado, um temporizador delimitado pode ser usado, mas isso deve ser uma escolha de projeto consciente em vez de um palpite disfarçado de certeza.

### Passo 6: Construir o estado de falha explícito

O estado de falha deve desenergizar as saídas e exigir um caminho de reset definido. Em muitas aplicações, isso significa que não há reinicialização automática após sobrecarga ou falha de prova, a menos que a filosofia de controle permita explicitamente.

Exemplo de conceito de lógica:

• Se `Motor_State = 99`
• force `Motor_Output = FALSE`
• exija `Reset_PB = TRUE`
• exija que o desarme seja limpo
• então `MOV 0` para `Motor_State`

Resumo do padrão ladder

Um padrão de rung de FSM limpo no OLLA Lab geralmente segue esta sequência:

• `EQU` para identificar o estado atual
• uma ou mais condições `XIC` / `XIO` para validar a transição
• `MOV` para escrever o próximo estado

Exemplo de padrão ladder:

• `EQU Motor_State 10` e `XIC Aux_Run_Proof` então `MOV 20 -> Motor_State`
• `EQU Motor_State 10` e `XIO Aux_Run_Proof` e `XIC Start_Timer.DN` então `MOV 99 -> Motor_State`

Texto alternativo da imagem: Captura de tela do editor de lógica ladder do OLLA Lab mostrando uma rung de máquina de estados finitos onde um bloco EQU verifica se Motor_State é igual a 10, uma condição de entrada verifica Aux_Run_Proof e um bloco MOV transita Motor_State para 20.

As saídas devem ser derivadas do estado ativo, não usadas como memória oculta para a sequência. Essa distinção é fácil de perder e cara de ignorar.

Um padrão comum é:

• energizar `Motor_Output` quando `Motor_State = 10` ou `Motor_State = 20`
• desenergizá-la em `0`, `30` e `99`, a menos que a filosofia de parada exija uma retenção controlada

Isso lhe dá uma relação direta entre a intenção da sequência e a saída comandada. Também torna a simulação e a solução de problemas mais limpas, porque a saída se torna uma consequência do estado, não uma segunda máquina de estados não documentada.

Exemplo de lógica de saída

• Se `Motor_State = 10` OU `Motor_State = 20`
• então `Motor_Output = TRUE`

• Se `Motor_State = 0`, `30` ou `99`
• então `Motor_Output = FALSE`

Para sistemas de motores mais complexos, como arrancadores reversíveis, transições estrela-triângulo ou arranjos de bypass de VFD, cada comando de atuador ainda deve permanecer derivado do estado e intertravado explicitamente.

A falha de FSM mais comum é um estado travado. Um estado travado ocorre quando a máquina entra em um estado válido, mas nunca satisfaz as condições necessárias para sair dele.

É por isso que a simulação é importante. Ela permite observar a causalidade antes que o hardware, a mecânica e a pressão do cronograma compliquem o diagnóstico.

No OLLA Lab, a solução de problemas de uma FSM deve seguir uma sequência simples:

1. Leia o inteiro do estado atual primeiro Verifique `Motor_State` no painel de variáveis. Não comece tentando adivinhar qual rung parece errada.
2. Verifique a condição de transição esperada Se o motor está no `Estado 10`, confirme se `Aux_Run_Proof` realmente muda, se o temporizador está rodando e se os permissivos permanecem verdadeiros.
3. Verifique o estado ladder contra o estado do equipamento simulado O ladder pode comandar uma saída de motor, mas o equipamento simulado pode ainda mostrar prova de falha, resposta atrasada ou comportamento de falha.
4. Injete uma falha deliberadamente Alterne `OL_Trip` durante o `Estado 20` e confirme se a sequência transita imediatamente para o `Estado 99`.
5. Verifique a resposta segura Confirme se as saídas do motor desenergizam conforme necessário e se a máquina não pode retomar a operação até que as condições de reset sejam atendidas.

É aqui que o OLLA Lab se torna operacionalmente útil. Ele permite que o aluno compare o inteiro de estado de controle, as condições de E/S e o comportamento do equipamento em um só lugar, o que espelha o trabalho que os engenheiros de comissionamento fazem sob pressão.

Um teste prático de injeção de falha

Use este caso de teste delimitado:

• Comece do `Estado 0`
• Emita um comando de partida válido
• Confirme a transição para o `Estado 10`
• Confirme o feedback de prova e a transição para o `Estado 20`
• Force `OL_Trip = TRUE`
• Verifique a transição imediata para o `Estado 99`
• Verifique `Motor_Output = FALSE`
• Limpe o desarme e emita o reset
• Verifique a transição de volta para o `Estado 0`

Se qualquer uma dessas etapas falhar, o problema não é mais abstrato. Você agora tem um caso de defeito reproduzível.

Validação de gêmeo digital, neste artigo, significa testar a lógica ladder contra um modelo de máquina simulado realista, para que o comportamento da sequência possa ser observado sob condições normais e anormais antes da implantação. Não significa que a simulação seja um substituto legal para aceitação no local, verificação de segurança funcional ou assinatura de comissionamento.

Esse limite é importante. Um gêmeo digital pode melhorar a validação de sequência, o realismo do treinamento e o ensaio de falhas, mas não elimina a necessidade de revisão específica da planta, verificação de dispositivos e atividades formais do ciclo de vida de segurança sob normas como a IEC 61508, quando aplicável (IEC, 2010; exida, 2024).

No OLLA Lab, a validação de gêmeo digital é operacionalmente útil quando o engenheiro pode fazer tudo o seguinte:

• comparar o estado ladder com o comportamento do equipamento simulado
• observar se as transições de E/S ocorrem como pretendido
• injetar falhas e verificar a resposta de estado seguro
• revisar a lógica após a falha
• reexecutar o mesmo cenário para confirmar a correção

Essa é a diferença entre prática de sintaxe e ensaio de comissionamento.

Uma galeria de capturas de tela não é evidência de engenharia. É apenas um registro parcial.

Se você deseja demonstrar competência real em controle, construa um corpo compacto de evidências usando esta estrutura:

1. Descrição do Sistema Defina a máquina ou unidade de processo, seu objetivo e as E/S relevantes.
2. Definição operacional de comportamento correto Declare o que a sequência deve fazer, qual feedback deve receber e o que constitui uma resposta segura válida.
3. Lógica ladder e estado do equipamento simulado Show a lógica de estado, a lógica de saída e o comportamento simulado correspondente.
4. O caso de falha injetada Documente a condição anormal que você introduziu, como desarme por sobrecarga, falha na prova de partida ou perda de permissivo.
5. A revisão feita Explique qual lógica mudou e por quê.
6. Lições aprendidas Registre o que a falha revelou sobre o projeto da sequência, suposições ou intertravamentos ausentes.

Esta estrutura é mais credível porque mostra raciocínio, tratamento de falhas e disciplina de revisão. Uma rung limpa, por si só, não mostra se a lógica sobrevive a condições realistas.

O controle sequencial estruturado, a validação baseada em simulação e o teste consciente de falhas estão bem alinhados com a prática de engenharia estabelecida, embora a implementação exata varie por setor e classe de risco.

O embasamento relevante inclui:

• IEC 61131-3 para linguagens de programação de CLP e princípios de implementação de controle estruturado (IEC, 2013)
• IEC 61508 para pensamento de ciclo de vida de segurança funcional, especialmente onde condições anormais e comportamento de estado seguro importam (IEC, 2010)
• Orientação da exida sobre disciplina de ciclo de vida de segurança, rigor de verificação e a diferença entre intenção lógica e comportamento validado em sistemas industriais (exida, 2024)
• Literatura de pesquisa em simulação industrial, gêmeos digitais e ambientes de treinamento imersivo mostrando que ambientes simulados podem melhorar a compreensão procedimental, o ensaio de falhas e o aprendizado em nível de sistema quando estão vinculados ao desempenho observável da tarefa, em vez de apenas à novidade (Tao et al., 2019; Jones et al., 2023; Villalonga et al., 2021)

A conclusão cuidadosa não é que a simulação substitui o trabalho no local. É que a simulação pode antecipar o aprendizado caro, onde os erros são mais baratos e mais visíveis.

- IEC 61131-3: Controladores programáveis — Parte 3 - Visão geral da norma de segurança funcional IEC 61508 - Perfil de Manufatura Inteligente do NIST - IEEE Access: Tecnologias habilitadoras de gêmeos digitais (DOI)

Especialista em automação industrial com foco em arquiteturas de controle determinísticas e validação de sistemas de segurança.

Este artigo foi revisado tecnicamente quanto à precisão da lógica de estados finitos em CLPs e conformidade com os princípios de simulação industrial.