Como programar a coexistência segura entre humanos e robôs na Indústria 5.0

Para programar a coexistência segura entre humanos e robôs na Indústria 5.0, os engenheiros devem validar zonas de segurança dinâmicas, intertravamentos determinísticos e a lógica de monitoramento de velocidade e separação. O OLLA Lab fornece um ambiente de gêmeo digital delimitado onde a lógica ladder, a causalidade de E/S e as respostas a falhas podem ser testadas antes que o comissionamento físico comece.

A Indústria 5.0 não é um slogan sobre tornar as fábricas mais "humanas". É uma correção à suposição mais restrita de que a autonomia total é sempre a filosofia de controle ideal. A estrutura da Comissão Europeia é explícita: a indústria do futuro deve ser centrada no ser humano, resiliente e sustentável, não apenas automatizada na intensidade máxima (Comissão Europeia, 2021).

A razão prática é simples. Sistemas "lights-out" (totalmente automatizados) lidam bem com a repetibilidade, mas lidam mal com a variância quando ela não foi modelada com antecedência. Uma linha pode ser perfeitamente otimizada até que a realidade chegue, o que ela tende a fazer sem aviso.

Em testes de estresse recentes do OLLA Lab WebXR, engenheiros simulando violações de zonas dinâmicas descobriram que os degraus (rungs) de segurança gerados por IA falharam no comportamento de parada de emergência exigido em 7 de 32 tarefas quando deixados sem correção por revisão humana, uma taxa de falha de 21,9%. Metodologia: n=32 tarefas de intertravamento de célula colaborativa simuladas, comparador de base = conjunto de degraus determinísticos revisados por humanos, janela de tempo = janeiro-março de 2026. Isso sustenta apenas um ponto restrito: a geração de rascunhos não é prova de lógica de segurança implantável. Não sustenta uma alegação ampla sobre todo o trabalho de CLP assistido por IA.

A fábrica escura está em transição porque a otimização sem o julgamento humano adaptativo é frágil. A Indústria 4.0 enfatizou a conectividade, a automação e as operações ricas em dados. A Indústria 5.0 mantém esses ganhos, mas restaura o operador humano, o técnico e o engenheiro como componentes ativos na resiliência do sistema, em vez de mão de obra residual nas margens.

O modelo da Indústria 5.0 da Comissão Europeia é a declaração formal mais clara dessa mudança. Ele não rejeita a automação. Ele rejeita a ideia de que a automação por si só é o objetivo industrial mais elevado (Comissão Europeia, 2021).

Isso é importante na engenharia de controle porque os estados anormais são onde a filosofia se torna lógica ladder. Interrupções de fornecimento, desvio de sensores, produtos malformados, substituições de manutenção e intervenção manual parcial não desaparecem porque uma linha é altamente automatizada. Eles se tornam as condições que expõem se a estratégia de controle foi projetada para a realidade ou para um folheto.

### Filosofias de controle: Indústria 4.0 vs. Indústria 5.0

| Dimensão | Ênfase da Indústria 4.0 | Ênfase da Indústria 5.0 | |---|---|---| | Objetivo principal | Eficiência, conectividade, rendimento | Resiliência, operação centrada no humano, desempenho sustentável | | Papel do humano | Supervisor de ativos automatizados | Manipulador de exceções ativo, colaborador, tomador de decisão | | Papel do CLP/sistema de controle | Espinha dorsal de automação determinística | Espinha dorsal determinística mais coexistência segura homem-máquina | | Abordagem de segurança | Separação protegida, zonas de automação fixas | Colaboração dinâmica, espaços compartilhados com risco reduzido quando justificado | | Postura de falha | Minimizar interrupção | Recuperar-se com segurança da interrupção e da variância |

O equívoco que vale a pena corrigir é que a Indústria 5.0 significa "menos automação". Geralmente significa melhor alocação da cognição. Robôs repetem. Humanos interpretam. Bons sistemas usam ambos propositalmente.

Robôs seguros não existem isoladamente; aplicações seguras sim. Essa distinção não é um ajuste semântico. É o núcleo de como os sistemas colaborativos são avaliados, validados e comissionados.

Para aplicações de robôs colaborativos, a discussão sobre normas geralmente se concentra em:

• ISO 10218 para requisitos de segurança de robôs industriais
• ISO/TS 15066 para orientação de operação de robôs colaborativos
• IEC 61508 para segurança funcional de sistemas elétricos, eletrônicos e eletrônicos programáveis relacionados à segurança

A ISO/TS 15066 não concede a um robô um status místico de "seguro". Ela define conceitos de operação colaborativa, expectativas de redução de risco e considerações em nível de aplicação, como força, contato, velocidade, separação e estados monitorados. A IEC 61508, por sua vez, fornece a estrutura de segurança funcional mais ampla para comportamento de controle relacionado à segurança e disciplina de ciclo de vida.

Os quatro modos de operação colaborativa reconhecidos

1. Parada Monitorada com Segurança (SRMS) O robô para quando uma pessoa entra no espaço colaborativo, e o movimento é retomado apenas sob condições controladas.
2. Guia Manual (HG) O humano guia fisicamente o movimento do robô por meio de dispositivos de habilitação e lógica operacional restrita.
3. Monitoramento de Velocidade e Separação (SSM) A velocidade ou estado de movimento do robô muda dinamicamente com base na distância medida de uma pessoa.
4. Limitação de Potência e Força (PFL) O robô e as ferramentas são projetados para que as forças de contato permaneçam dentro de limites aceitáveis para a aplicação definida.

A carga de engenharia é mais pesada no SSM porque depende de sensoriamento dinâmico, resposta determinística e lógica de zona validada. "Dinâmico" não significa vago. Significa que a lógica muda de estado com base na separação medida sob restrições de tempo e segurança definidas.

O que essas normas significam em termos de CLP

Para um engenheiro de controle, as normas tornam-se comportamentos observáveis:

• o estado do scanner ou sensor de segurança deve ser representado por entradas à prova de falhas (fail-safe)
• permissivos devem colapsar para um estado seguro em caso de perda de sinal ou estado inválido
• comandos de redução de velocidade e parada devem ser determinísticos
• o comportamento de reset deve ser deliberado, limitado e não automático onde a avaliação de risco exigir
• condições anormais devem ser testadas, não ignoradas

É aí que muitas equipes descobrem a diferença entre sintaxe e capacidade de implantação.

A simulação em RV é útil para SSM porque o teste físico de violações de zona é caro, lento e, às vezes, desnecessariamente arriscado. Se a primeira vez que um engenheiro observa a lógica do scanner sob intrusão humana for durante o comissionamento real, o processo já está atrasado na curva de risco.

Em termos práticos, a validação de SSM exige que os engenheiros verifiquem:

• transições de estado de zona sob mudança de posição do operador
• comandos de redução de velocidade quando zonas de aviso externas são violadas
• comandos de parada quando zonas de proteção internas são violadas
• condições de reset e reinicialização após a liberação da zona
• comportamento à prova de falhas durante queda de sensor, estado obsoleto ou transições inválidas

O OLLA Lab é útil aqui como um ambiente de ensaio delimitado. Os engenheiros podem construir lógica ladder no navegador, executar a simulação, inspecionar variáveis e o estado de E/S, e observar como uma célula de trabalho 3D ou WebXR responde quando um operador virtual entra em zonas definidas. O ponto não é a novidade visual. O ponto é a causalidade.

O que significa "pronto para simulação" operacionalmente

"Pronto para simulação" deve ser definido pelo comportamento, não pela confiança. Um engenheiro está pronto para simulação quando pode:

• provar o comportamento de controle pretendido antes da implantação
• observar a causalidade de E/S durante estados normais e anormais
• diagnosticar por que um permissivo falhou ou permaneceu travado
• injetar uma falha realista e verificar o estado seguro resultante
• revisar a lógica após o caso de falha e testar novamente a sequência
• comparar o estado ladder com o estado do equipamento simulado sem rodeios

Essa é uma definição de comissionamento, não um adjetivo de currículo.

Por que WebXR e gêmeos digitais são importantes aqui

Um gêmeo digital é operacionalmente útil quando o estado do equipamento virtual é próximo o suficiente para testar suposições de controle, lógica de sequência e resposta a falhas antes do trabalho no local. Não é um substituto para o comissionamento final, e não deve ser descrito como tal. Mas é extremamente útil para detectar erros de categoria precocemente: ordem de permissivos errada, caminho de reset errado, estado padrão errado, expectativa de tempo errada.

Travar uma célula colaborativa virtual é mais barato do que travar uma física. Este não é um insight profundo, mas permanece subutilizado.

A lógica de zona de segurança dinâmica deve ser determinística, à prova de falhas e fácil de auditar. A estrutura geralmente separa a redução de velocidade da zona externa, o comportamento de parada da zona interna e as condições de reset manual, em vez de misturá-los em um degrau inteligente. A esperteza envelhece mal no comissionamento.

Por que a lógica normalmente fechada é comum para estados à prova de falhas

A representação normalmente fechada é frequentemente usada para status relevante à segurança porque a perda de sinal deve tender a um resultado seguro. Se um scanner falha, a integridade do cabo é perdida ou uma entrada de segurança cai, o permissivo deve abrir em vez de permanecer falsamente saudável.

Em termos simples:

• entrada saudável presente → permissivo pode permanecer verdadeiro se todas as outras condições forem satisfeitas
• entrada perdida ou com falha → permissivo colapsa
• permissivo colapsado → robô transita para estado de risco reduzido ou parada de acordo com o projeto de segurança

A implementação exata depende da arquitetura de segurança, do controlador e da avaliação de risco. Mas o princípio governante é estável: estado incerto não deve se disfarçar de estado seguro.

A causalidade mínima que um engenheiro deve ser capaz de explicar

Um engenheiro validando essa lógica deve ser capaz de responder:

• O que causa velocidade reduzida em vez de parada total?
• Qual estado exato causa parada de emergência?
• O que acontece em caso de falha do scanner versus violação de zona válida?
• O movimento pode ser retomado automaticamente ou é necessário reconhecimento?
• Quais condições devem ser verdadeiras antes que o reset seja aceito?
• Qual é o estado seguro se o sinal da zona se tornar contraditório ou obsoleto?

Se essas respostas não forem explícitas, a lógica não está pronta. Pode até ser executável. Isso não é a mesma coisa.

A validação com o humano no loop é importante porque os operadores nem sempre se comportam de acordo com o caminho ideal. Eles entram muito cedo, reiniciam muito rapidamente, ignoram as expectativas de sequência e, ocasionalmente, criam a condição exata que a revisão do projeto esqueceu de imaginar.

É aqui que o OLLA Lab se torna operacionalmente útil. Em um cenário de embalagem ou manuseio de materiais colaborativo, um engenheiro pode:

• construir a lógica ladder para permissivos de zona e comandos de estado do robô
• executar a simulação e observar as saídas em tempo real
• usar o Painel de Variáveis para forçar mudanças de estado do scanner, falhas e reconhecimentos
• comparar o estado ladder com a resposta do equipamento 3D ou RV
• revisar a lógica após uma condição anormal injetada

O valor do produto aqui é delimitado e credível. Ele oferece prática repetida em tarefas de alto risco que são difíceis de ensaiar em equipamentos reais, especialmente para engenheiros juniores. Não certifica competência, não substitui a supervisão no local nem elimina a necessidade de validação formal de segurança.

Um fluxo de trabalho prático de injeção de falhas dentro de uma célula colaborativa simulada

Uma sequência de validação útil é assim:

1. Comece com um estado de scanner saudável e permissivo de robô em velocidade total.
2. Viole a zona externa e verifique a transição apenas para velocidade reduzida.
3. Viole a zona interna e verifique o comando de parada e a queda do permissivo de segurança.
4. Limpe a zona, mas deixe o reset sem reconhecimento; confirme que não há reinicialização automática se o projeto a proibir.
5. Injete falha no scanner enquanto a zona estiver limpa; verifique se o sistema permanece em um estado inibido seguro.
6. Tente o reset sob condições inválidas; confirme que o reset é rejeitado.
7. Corrija a estrutura do degrau se qualquer reinicialização não intencional ou permissivo obsoleto permanecer.

Essa sequência é mais educativa do que dez capturas de tela de um degrau finalizado. A evidência de engenharia deve mostrar pensamento sob falha, não apenas sintaxe sob condições ideais.

Um registro de simulação útil é um corpo compacto de evidências de engenharia, não uma galeria de capturas de tela. A documentação deve mostrar o que foi testado, por que foi considerado correto, o que falhou e como a lógica mudou.

Use esta estrutura:

Declare os comportamentos esperados em termos observáveis. Exemplo: "Violação da zona externa força velocidade reduzida dentro da transição de estado simulada; violação da zona interna derruba o permissivo de segurança e comanda a parada; a reinicialização requer reset manual após a liberação da zona."

Descreva a condição anormal introduzida: queda do scanner, entrada de zona travada, reset prematuro, estado contraditório, reconhecimento atrasado ou reentrada do operador.

Documente a mudança exata na lógica. Exemplo: adicionada dominância de falha antes do permissivo de reset, separada a lógica de velocidade da zona externa da lógica de parada da zona interna, ou removido caminho de reinicialização automática não intencional.

1. Descrição do Sistema Defina a célula, máquina ou segmento de processo. Identifique o ativo controlado, entradas de segurança, pontos de interação do operador e modos de operação pretendidos.
2. Definição operacional de "correto"
3. Lógica ladder e estado do equipamento simulado Apresente os degraus relevantes e o estado correspondente do gêmeo digital. Mostre nomes de tags, permissivos, saídas e resposta visual da máquina.
4. O caso de falha injetado
5. A revisão feita
6. Lições aprendidas Declare o que o teste revelou sobre o design da sequência, suposições à prova de falhas, comportamento de reset ou interação do operador.

Esse formato é útil para aprendizado, revisão e conversas de contratação porque mostra julgamento de engenharia.

O modo de falha mais comum não é simplesmente "código ruim". É um design de estado ruim. A lógica pode compilar, simular e até parecer ordenada, enquanto ainda lida incorretamente com casos extremos.

Os modos de falha típicos incluem:

• erros de dominância do caminho de reset onde o reset ignora um permissivo ainda inválido
• mascaramento de falhas onde a falha do scanner e o estado de limpeza válido são tratados de forma muito semelhante
• hierarquia de zona pouco clara entre regiões de aviso, velocidade reduzida e parada
• suposições de reinicialização automática que nunca foram justificadas pela avaliação de risco da aplicação
• retenção de estado obsoleto onde as saídas permanecem travadas após a condição física ter mudado
• semântica de tag ruim que torna a revisão difícil e esconde a causalidade
• mistura de lógica de controle padrão com intenção de segurança sem limites arquitetônicos claros

O padrão corretivo é igualmente consistente:

• defina o estado seguro primeiro
• defina todas as transições válidas em segundo lugar
• defina a dominância de falha em terceiro lugar
• teste condições anormais antes de declarar a sequência completa

Essa ordem economiza tempo e pode reduzir o risco de comissionamento.

A assistência de IA é melhor usada para geração de rascunhos, explicação e suporte à revisão, não para julgamento final de segurança. Ela pode acelerar a estruturação de degraus, sugestões de tags e orientação instrucional. Ela não pode carregar o fardo da validação determinística por conta própria.

No OLLA Lab, a GeniAI pode ajudar a reduzir o atrito de integração explicando elementos ladder, sugerindo estrutura lógica e ajudando os alunos a passar por cenários. Isso é útil, especialmente para engenheiros em estágio inicial que ainda não sabem qual erro estão cometendo. Mas o teste de aceitação final permanece liderado por humanos e baseado em evidências.

Uma estrutura segura é:

• IA pode propor
• simulação pode expor
• engenheiros devem decidir

Essa é a hierarquia apropriada para o trabalho de segurança colaborativa.

A Indústria 5.0 expande o papel do engenheiro de controle de autor de sequência para designer de coexistência. O trabalho não é mais apenas automatizar o movimento. É definir quando o movimento é permitido, quando deve degradar, quando deve parar e como os humanos podem reentrar no processo com segurança sem criar riscos de estado ocultos.

Essa mudança altera o que conta como habilidade. Conhecer a sintaxe de instrução ainda é importante, mas a sintaxe é o básico. O sinal mais forte é se um engenheiro pode validar o comportamento sob falhas, explicar a causalidade dos permissivos e revisar a lógica após um evento anormal realista.

É por isso que a simulação é importante. Ela dá aos engenheiros um lugar para acumular experiência em falhas sem cobrar mensalidades em hardware danificado ou horas de comissionamento inseguras.

- IEC 61131-3: Controladores programáveis — Parte 3: Linguagens de programação - Família de normas de segurança funcional IEC 61508 - NIST AI Risk Management Framework (AI RMF 1.0) - Contexto da política da Indústria 5.0 da UE - Visão geral de gêmeos digitais (NIST)

Equipe de Engenharia do OLLA Lab.

Este artigo foi revisado por especialistas em segurança funcional e engenheiros de automação industrial para garantir a conformidade com as normas ISO/IEC vigentes e as melhores práticas de simulação de gêmeos digitais.