Como lidar com extensões de fornecedores de CLP: UDT vs. USER_DEFINED na norma IEC 61131-3

A norma IEC 61131-3 padroniza linguagens de programação de CLP, não o comportamento completo de tempo de execução entre fornecedores. Estruturas de dados complexas, como UDTs, DUTs e tipos definidos pelo usuário específicos de cada fornecedor, permanecem dependentes da implementação, especialmente no que diz respeito ao layout de memória e ao acesso a blocos. O OLLA Lab fornece um ambiente de simulação delimitado para praticar o mapeamento de dados, a estruturação de tags e a validação de lógica antes da implementação específica do fornecedor.

A conformidade com a IEC 61131-3 não é o mesmo que portabilidade de código. A norma define famílias de linguagens e semânticas centrais, mas deixa detalhes importantes de tempo de execução e memória dependentes da implementação, que é exatamente onde as migrações entre plataformas tendem a falhar.

Uma correção prática ajuda aqui: a maioria das migrações fracassadas não é causada pelo degrau (rung) que liga um motor. Elas são causadas pela estrutura que o envolve. Em um benchmark interno da Ampergon Vallis, 68% das falhas simuladas em migrações entre plataformas foram associadas a incompatibilidades em estruturas de dados definidas pelo usuário aninhadas, conflitos de preenchimento (padding) ou suposições do modelo de endereçamento, em vez de erros de sintaxe de ladder [Metodologia: n=512 tarefas de migração simuladas envolvendo estruturas de múltiplas tags e remapeamento de E/S, comparador de linha de base = aceitação de ladder apenas por sintaxe, janela de tempo = jan. 2025 a fev. 2026]. Isso sustenta uma afirmação restrita: a modelagem de dados é um ponto de falha primário no ensaio de migração. Não prova uma taxa universal da indústria.

Essa distinção é importante porque a sintaxe é fácil de admirar e difícil de implementar. O layout de memória é o problema mais silencioso, e geralmente é o que espera pelo comissionamento.

A IEC 61131-3 padroniza linguagens de programação, não o comportamento idêntico dos fornecedores. Ela define linguagens como Ladder Diagram (LD), Function Block Diagram (FBD), Structured Text (ST), Sequential Function Chart (SFC) e conceitos de tipos relacionados, mas permite comportamento dependente da implementação em áreas que afetam a execução, o armazenamento e a interoperabilidade.

Na prática, "dependente da implementação" não é uma nota de rodapé. É o local onde os fornecedores tomam decisões diferentes sobre:

• alinhamento e preenchimento (padding) de dados,
• ordenação de bytes e convenções de armazenamento,
• acesso à memória otimizado versus absoluto,
• tratamento do compilador para estruturas e tipos aninhados,
• comportamento retentivo,
• implementações de blocos funcionais específicas de bibliotecas.

É por isso que dois controladores podem ser descritos como compatíveis com a IEC 61131-3 e ainda discordar sobre como uma estrutura complexa é armazenada ou endereçada.

Uma definição de engenharia útil decorre disso: lógica portátil não é a lógica que compila em dois lugares; é a lógica cujas suposições de dados, suposições de execução e suposições de interface sobrevivem a ambos os compiladores. Esse é um padrão mais elevado do que a maioria da linguagem de marketing sugere.

O que a norma realmente deixa em aberto?

A norma deixa espaço para a implementação específica do fornecedor em várias áreas relevantes para estruturas de dados e interoperabilidade. Dependendo da edição e da documentação do fornecedor, isso geralmente inclui:

• representação interna de tipos de dados,
• empacotamento e alinhamento de estruturas,
• métodos de acesso para variáveis e blocos,
• detalhes de comportamento de tarefas e varredura (scan),
• extensões de biblioteca e tempo de execução.

O resultado é direto. Uma declaração de tipo pode parecer padrão enquanto o comportamento de memória subjacente não é.

Por que isso importa em um sistema em operação?

Importa porque as interfaces externas não negociam com suas suposições. Um mapa de registros Modbus, um cliente OPC UA, uma faceplate de IHM ou uma troca entre CLPs espera uma interpretação estável dos dados. Se um lado preenche (pad) um campo `BOOL` ou reordena uma estrutura para acesso otimizado, a lógica pode até compilar, mas os dados do processo podem se deslocar por baixo dela.

Esse é o tipo de erro que sobrevive a uma revisão de código e aparece durante a inicialização.

A principal diferença não é apenas a nomenclatura. É como cada fornecedor vincula tipos personalizados à memória, regras de acesso e comportamento das ferramentas.

Diferentes ecossistemas usam termos diferentes para ideias amplamente semelhantes:

Divisão da terminologia por fornecedor

- Rockwell Automation (Studio 5000):

• Usa User-Defined Data Types (UDTs).
• As UDTs são centrais para a modelagem de tags do Logix.
• O comportamento da memória e o alinhamento dos membros seguem as regras do compilador específicas do fornecedor.
• Integradores frequentemente encontram suposições de alinhamento ao trocar dados empacotados com sistemas que não são da Rockwell.

- Siemens (TIA Portal):

• Usa PLC data types e UDTs na linguagem de engenharia comum.
• O "acesso otimizado ao bloco" pode alterar a forma como os dados são organizados internamente.
• Isso melhora a eficiência dentro do ambiente Siemens, mas pode quebrar fluxos de trabalho que dependem de offsets absolutos fixos.
• Se um sistema externo espera endereços fixos do estilo antigo, o acesso otimizado não é útil.

- Plataformas baseadas em Codesys, incluindo Beckhoff e WAGO em muitas implementações:

• Comumente usam DUTs (Data Unit Types) declarados com `TYPE ... END_TYPE`.
• A sintaxe é padronizada em estilo, mas o empacotamento em tempo de execução e o comportamento do alvo ainda dependem da plataforma e do compilador.
• A portabilidade entre alvos permanece condicional, não automática.

- Outros ambientes de fornecedores:

• Podem usar termos como `STRUCT`, `USER_DEFINED`, tipos de registro personalizados ou modelos de objetos específicos da plataforma.
• A diferença de nomenclatura é menos importante do que o comportamento resultante de armazenamento e acesso.

Qual é a distinção operacional com a qual os engenheiros devem se preocupar?

A distinção operacional é esta: um tipo definido pelo usuário não é apenas uma conveniência de nomenclatura; é um contrato sobre a forma dos dados, a ordem dos membros e as expectativas de acesso. Se dois sistemas discordam sobre esse contrato, a lógica em torno dos dados torna-se não confiável, mesmo quando o ladder em si é perfeitamente comum.

É aqui que os engenheiros frequentemente confundem compatibilidade de linguagem com capacidade de implantação. A primeira é textual. A segunda é física.

O preenchimento de memória quebra a lógica padronizada ao deslocar a localização esperada dos campos dentro de uma estrutura. A lógica pode permanecer sintaticamente válida, mas qualquer interface que assuma um layout de byte ou palavra diferente pode ler o valor errado.

Considere esta declaração simplificada:

TYPE Motor_Control_DUT : STRUCT Start_Cmd : BOOL; ( pode ser preenchido dependendo do fornecedor ) Speed_Ref : REAL; ( 32 bits ) Fault_Code : INT; ( 16 bits ) END_STRUCT END_TYPE

Esta declaração parece simples. Não é universalmente simples na memória.

Um compilador pode colocar `Start_Cmd` em uma localização de bit empacotada e colocar `Speed_Ref` imediatamente após o próximo limite válido. Outro pode alinhar o `REAL` em um limite de 32 bits e inserir preenchimento após o `BOOL`. Um terceiro pode otimizar a estrutura dentro de um bloco de uma forma que torna os offsets absolutos inseguros para consumidores externos.

Um modo de falha concreto

Um modo de falha comum aparece em comunicações baseadas em registros.

• Um controlador emissor expõe uma estrutura para um mapa Modbus TCP.
• O engenheiro assume que `Start_Cmd`, `Speed_Ref` e `Fault_Code` ocupam offsets esperados consecutivos.
• O controlador receptor importa ou reconstrói a mesma estrutura conceitual usando suas próprias regras de compilador.
• O `REAL` cai em um offset diferente porque a primeira plataforma preencheu o campo `BOOL`.
• O lado receptor agora lê dados de referência de velocidade corrompidos ou interpreta parte do valor de ponto flutuante como um código de falha.

O ladder pode estar "correto" e a máquina ainda pode se comportar incorretamente. Essa é a consequência prática do desalinhamento de dados.

Por que tipos aninhados tornam isso pior

Estruturas aninhadas multiplicam o risco porque cada estrutura filha pode introduzir seu próprio comportamento de alinhamento. Um objeto de motor simples pode ser gerenciável. Um objeto de skid de processo contendo comandos, permissivos, alarmes, valores analógicos, parâmetros PID e palavras de status torna-se muito mais frágil.

O padrão de falha é previsível:

• uma suposição incorreta no nível da estrutura pai,
• uma regra de alinhamento oculta em uma estrutura filha,
• um mapeamento externo construído sobre offsets absolutos,
• um longo dia de comissionamento.

As diferenças práticas aparecem na forma como os engenheiros definem, acessam e trocam dados estruturados.

Rockwell Automation

As UDTs da Rockwell são fortemente usadas para modelos de equipamentos reutilizáveis, faceplates e organização de tags adjacentes a AOIs. Na prática, os engenheiros frequentemente projetam em torno de estruturas de tags do Logix que são limpas dentro do ecossistema Rockwell, mas exigem remapeamento deliberado quando expostas a sistemas de terceiros.

As implicações práticas incluem:

• forte consistência interna para projetos Logix,
• uso frequente em padrões de objetos de motor, válvula e dispositivo,
• cuidado necessário ao mapear para protocolos externos ou consumidores que não são da Rockwell,
• suposições de alinhamento e empacotamento que devem ser verificadas, não adivinhadas.

Siemens

A Siemens introduz uma distinção importante entre acesso de estilo padrão e acesso otimizado ao bloco. O acesso otimizado pode melhorar o uso da memória e o desempenho interno, mas reduz a transparência do endereço para sistemas externos que esperam offsets fixos.

As implicações práticas incluem:

• manuseio interno eficiente de dados estruturados,
• confiabilidade reduzida de suposições antigas de endereços absolutos,
• necessidade de decidir explicitamente se a interoperabilidade externa ou a otimização interna tem prioridade,
• cautela extra ao integrar IHMs, historiadores ou CLPs pares que esperam endereços estáveis.

Codesys e plataformas relacionadas

As DUTs no estilo Codesys oferecem um modelo de declaração de tipo familiar e flexível. Elas são poderosas para engenharia estruturada, bibliotecas reutilizáveis e abstração de máquina. Elas não são, no entanto, uma garantia de que outro alvo armazenará a mesma estrutura de forma idêntica.

As implicações práticas incluem:

• sintaxe de declaração de tipo clara,
• portabilidade dentro de suposições de plataforma delimitadas,
• diferenças de tempo de execução específicas do alvo ainda relevantes,
• necessidade de verificação explícita ao cruzar fronteiras de fornecedores.

A migração de CLP "lift and shift" (copiar e colar) geralmente falha porque o software de controle industrial está acoplado ao comportamento do hardware, modelos de memória, convenções de E/S, suposições de varredura e ferramentas do fornecedor. A lógica é apenas uma camada do sistema.

Uma migração normalmente exige que os engenheiros reconciliem pelo menos cinco coisas:

- Sistemas de tipos: convenções de UDT, DUT, struct e bloco diferem. - Modelos de endereçamento: layouts absolutos, simbólicos, otimizados e expostos por protocolo diferem. - Comportamento da instrução: temporizadores, contadores, blocos PID e funções de biblioteca nem sempre são semanticamente idênticos. - Vinculação de E/S: dispositivos de campo, escalonamento e bits de diagnóstico são específicos da plataforma. - Suposições de comissionamento: sequenciamento de inicialização, comportamento de reset de falha e manuseio de permissivos são frequentemente codificados em padrões nativos do fornecedor.

Portanto, a versão honesta é esta: não existe "migração copiar-colar" industrial que valha a pena confiar em um processo em operação. Existe apenas tradução, verificação e redução de risco.

Pronto para Simulação deve ser definido operacionalmente, não aspiracionalmente. Um engenheiro "Pronto para Simulação" pode provar, observar, diagnosticar e fortalecer a lógica de controle contra o comportamento realista do processo antes que essa lógica chegue a um processo em operação.

Para o trabalho de estrutura de dados entre plataformas, isso significa que o engenheiro pode:

• definir tags estruturadas e membros aninhados claramente,
• rastrear causa e efeito entre o estado do ladder e o estado do equipamento,
• verificar o comportamento esperado sob condições normais e anormais,
• identificar onde as suposições de dados dependem de regras de empacotamento ou acesso específicas do fornecedor,
• revisar a lógica ou o mapeamento após uma falha injetada,
• documentar o que "correto" significa antes da implantação.

Isso é diferente de apenas ser capaz de escrever um degrau (rung). A sintaxe é necessária. Não é a linha de chegada.

Este enquadramento alinha-se com a literatura de engenharia mais ampla sobre validação baseada em simulação, uso de gêmeos digitais em sistemas industriais e verificação pré-implantação como uma medida de redução de risco em ambientes de automação complexos (por exemplo, Fuller et al., 2020; Jones et al., 2020; e princípios da IEC 61508 sobre redução sistemática de risco).

O OLLA Lab ajuda dando aos engenheiros um ambiente delimitado para ensaiar o design de tags estruturadas, simulação e validação consciente de falhas antes de passar para as restrições de IDE específicas do fornecedor. Não é um tradutor de código universal e não deve ser tratado como tal.

Seu valor aqui é mais restrito e mais credível: ele permite que os engenheiros pratiquem o hábito de engenharia que o trabalho de migração realmente exige.

O que o OLLA Lab está fazendo neste fluxo de trabalho

Dentro do escopo documentado do produto, o OLLA Lab fornece:

• um editor de lógica ladder baseado na web,
• modo de simulação para executar e parar a lógica,
• um Painel de Variáveis para monitorar e ajustar tags, E/S, valores analógicos e estados relacionados,
• exercícios industriais baseados em cenários,
• contextos de simulação estilo gêmeo digital para validar o comportamento contra equipamentos modelados.

Para o caso de uso deste artigo, o Painel de Variáveis é o que mais importa, pois permite que os engenheiros definam e inspecionem variáveis estruturadas em um ambiente agnóstico ao hardware antes de enfrentarem as regras de compilação e mapeamento específicas do fornecedor.

O que "agnóstico ao fornecedor" significa aqui

Agnóstico ao fornecedor não significa implantação livre de fornecedor. Significa que o ambiente de prática não está forçando o aluno a aprender as regras de memória da Rockwell, Siemens e Codesys de uma só vez, enquanto também aprende causalidade, sequenciamento e arquitetura de tags.

Essa separação é útil porque iniciantes e engenheiros juniores frequentemente falham por dois motivos ao mesmo tempo:

• eles ainda não entendem o comportamento do controle,
• e eles já estão enterrados em detalhes específicos da plataforma.

O fluxo de trabalho é modelar o comportamento de controle primeiro, depois modelar a forma dos dados e, em seguida, validar a causalidade sob simulação.

### Passo 1: Definir a lógica de controle bruta

Construa a lógica ladder no editor usando o conjunto de instruções necessário para o cenário:

• contatos e bobinas,
• temporizadores e contadores,
• comparadores e blocos matemáticos,
• elementos analógicos e PID quando relevante.

Nesta fase, concentre-se na sequência e na causalidade. Uma cadeia de permissivos de partida de motor deve se comportar corretamente antes de você se preocupar com como um fornecedor específico preencherá uma estrutura filha.

### Passo 2: Construir as tags estruturadas no Painel de Variáveis

Use o Painel de Variáveis para criar um modelo de tag aninhado que reflita o objeto do equipamento ou processo. Por exemplo:

• `Motor_Status.Running`
• `Motor_Status.Faulted`
• `Motor_Command.Start`
• `Motor_Command.Stop`
• `Motor_Analog.Speed_Ref`
• `Motor_Alarm.Overload`

É aqui que o OLLA Lab se torna operacionalmente útil. O engenheiro pode praticar a disciplina de nomenclatura, agrupar membros relacionados à lógica e observar como o estado do degrau (rung) mapeia para o estado do equipamento.

### Passo 3: Simular e observar mudanças de estado

Execute a simulação e alterne as entradas enquanto observa as saídas e variáveis.

Verifique:

• transições esperadas,
• permissivos falhos,
• comportamento de alarme,
• resposta analógica,
• temporização da sequência,
• incompatibilidade entre o estado pretendido e o comportamento real da tag.

Uma boa sessão de simulação responde a uma pergunta simples: quando o processo muda, a lógica muda pelo motivo certo?

### Passo 4: Injetar uma condição anormal

Introduza um caso de falha, como:

• feedback de prova falho,
• disparo de nível muito alto (high-high) analógico,
• perda de permissivo durante a execução,
• confirmação de partida atrasada,
• estado de comando obsoleto.

O objetivo é verificar se a estrutura e a lógica ainda fazem sentido quando o processo para de cooperar.

### Passo 5: Revisar a lógica e documentar as suposições de mapeamento

Ajuste o ladder, o agrupamento de tags ou o manuseio de estado após a falha aparecer. Em seguida, registre quais suposições são portáteis e quais precisarão de tratamento específico do fornecedor posteriormente.

Esse passo final é a diferença entre prática e evidência.

Um engenheiro júnior deve construir um corpo compacto de evidências de engenharia que demonstre raciocínio, validação e revisão. Capturas de tela são artefatos de suporte. Elas não são o argumento.

Use esta estrutura:

Declare o que o comportamento correto significa em termos observáveis. Exemplo: "A bomba só liga quando a habilitação principal, o disparo de sucção baixa e o comando de partida remota forem verdadeiros; as falhas travam até serem resetadas."

1. Descrição do Sistema Defina a máquina ou objeto de processo, seu propósito, estados principais e E/S chave.
2. Definição operacional de "correto"
3. Lógica ladder e estado do equipamento simulado Mostre os degraus (rungs) relevantes e as mudanças de estado simuladas correspondentes em tags, saídas ou equipamentos modelados.
4. O caso de falha injetado Descreva a condição anormal introduzida e por que ela importa operacionalmente.
5. A revisão feita Explique o que mudou na lógica, na estrutura de tags ou no manuseio da sequência após a falha ser observada.
6. Lições aprendidas Registre a conclusão da engenharia, especialmente onde a modelagem de dados, o sequenciamento ou as suposições de interface criaram risco.

Este formato é útil no treinamento porque demonstra julgamento de comissionamento, não apenas alfabetização em diagramas. Os empregadores não precisam de mais capturas de tela de bits verdes. Eles precisam de evidências de que o engenheiro consegue pensar quando o processo discorda.

A validação de gêmeos digitais é útil quando é definida como verificação de comportamento contra um modelo realista de máquina ou processo antes da implantação. Não é útil quando é tratada como cenário 3D decorativo anexado a uma lógica não testada.

Em um ambiente de treinamento delimitado como o OLLA Lab, a simulação estilo gêmeo digital ajuda os engenheiros a comparar:

• estado do ladder,
• estado de E/S,
• comportamento analógico,
• progressão da sequência,
• e resposta do equipamento modelado.

Essa comparação importa porque as falhas de comissionamento são frequentemente relacionais. O degrau (rung) parece bom isoladamente. A sequência do processo não.

Pesquisas sobre gêmeos digitais industriais e engenharia baseada em simulação têm consistentemente apoiado o valor da validação virtual para reduzir o risco de integração em estágio final, melhorar a compreensão do sistema e apoiar o treinamento de operadores ou engenheiros quando devidamente escopo (Fuller et al., 2020; Tao et al., 2019). A orientação de segurança funcional também reforça o princípio mais amplo de que falhas sistemáticas devem ser encontradas o mais cedo possível por meio de design e verificação disciplinados, em vez de descobertas no chão de fábrica (IEC 61508; exida, 2024).

A tradução de campo é simples: se uma falha pode ser encontrada antes da inicialização, esse é o momento correto para encontrá-la.

Os engenheiros devem tratar o OLLA Lab como um ambiente de ensaio e, em seguida, realizar a tradução e verificação explícitas específicas do fornecedor antes da implantação.

Use esta lista de verificação de entrega:

• confirme o sistema de tipos e as convenções de nomenclatura da plataforma de destino,
• verifique o comportamento de empacotamento e alinhamento da estrutura,
• decida se os sistemas externos exigem endereçamento fixo,
• revise as configurações de acesso ao bloco otimizado versus padrão,
• mapeie explicitamente os dados expostos pelo protocolo,
• valide o escalonamento analógico e as unidades de engenharia,
• compare o comportamento do temporizador, contador e PID com a semântica de destino,
• execute os casos de falha novamente no ambiente do fornecedor,
• documente quaisquer suposições que mudaram durante a tradução.

Este é o caminho disciplinado da simulação para a implantação. É mais lento do que o pensamento positivo e mais rápido do que uma inicialização ruim.

- UP: Explore o hub completo de Maestria em Lógica Ladder. - ACROSS: Artigo relacionado 1. - ACROSS: Artigo relacionado 2. - ACROSS: Artigo relacionado 3. - DOWN: Pratique este fluxo de trabalho no OLLA Lab.

- IEC 61131-3: Controladores programáveis — Parte 3 - Família de normas de segurança funcional IEC 61508 - Recursos de segurança funcional e validação da exida - Recomendação de sinalização de status NAMUR NE 107 - Gêmeo digital na indústria: estado da arte (DOI)