Como programar zonas de segurança dinâmicas de AMR em um CLP com lógica LiDAR

Uma cerca de segurança virtual para um AMR é uma estratégia de velocidade e parada controlada por CLP que mapeia violações de campo LiDAR para limites de movimento determinísticos. Na prática, o controlador reduz a velocidade do robô de sua velocidade máxima para um setpoint de velocidade de aviso ou para zero, com base em campos de proteção ativos e lógica de entrada à prova de falhas alinhada à norma ISO 3691-4.

Uma cerca de segurança virtual não é um círculo pintado em um software. É uma resposta de controle determinística a uma intrusão espacial e, se o caminho de resposta for fraco, a cerca é imaginária exatamente da maneira errada.

Para AMRs, a distinção útil não é "sensor instalado versus sensor ausente", mas sim desaceleração em campo de aviso versus parada em campo de proteção, executada através de um caminho de varredura que você pode realmente verificar. A ISO 3691-4 estabelece o objetivo de segurança; o CLP e a arquitetura de segurança decidem se a máquina se comporta corretamente quando alguém entra no caminho.

Métrica Ampergon Vallis: Na validação interna de um cenário de LiDAR de AMR no OLLA Lab, o roteamento da redução de velocidade da zona de aviso através de um caminho Ethernet padrão (não de segurança) adicionou atraso de comando suficiente para produzir ultrapassagem de zona em 3 de 12 testes de aproximação em alta velocidade, enquanto o mapeamento direto do sinal de aviso virtual para entradas locais do controlador eliminou essas ultrapassagens no mesmo conjunto de cenários. Metodologia: 12 testes de aproximação simulados a 2,0 m/s contra um layout fixo de campo de aviso/proteção, comparador de linha de base = limitador de velocidade roteado por rede, janela de tempo = sessão de validação de março de 2026. Isso sustenta um ponto restrito: o projeto do caminho de sinal afeta materialmente o comportamento de parada simulado. Isso não estabelece uma figura de latência universal para todas as arquiteturas de AMR.

O papel do OLLA Lab aqui é limitado e prático. É um ambiente de lógica ladder e gêmeo digital baseado na web para ensaiar tarefas de validação de alto risco — teste de lógica, rastreamento de E/S, injeção de falhas e revisão estilo comissionamento — antes que alguém tente executá-las em um veículo real. A sintaxe é barata. A capacidade de implantação segura não é.

Uma zona de segurança dinâmica é um envelope de proteção definido por LiDAR que altera o estado de movimento permitido do AMR com base na intrusão detectada e, em algumas arquiteturas, na cinemática do veículo, como velocidade ou ângulo de direção.

Em termos operacionais, a "cerca de segurança virtual" não é uma zona única, mas um conjunto de campos. Um arranjo típico inclui:

• um campo livre, onde o deslocamento comandado é permitido,
• um campo de aviso, onde a velocidade é reduzida, e
• um campo de proteção, onde o movimento é interrompido através de uma ação com classificação de segurança.

Essa distinção é importante porque nem toda intrusão deve produzir a mesma resposta da máquina. Um limitador de velocidade é frequentemente a resposta correta antes que uma parada brusca se torne necessária.

Como os campos de aviso e proteção diferem?

O campo de aviso é uma condição de desaceleração controlada. O campo de proteção é uma condição de parada.

| Estado do Campo LiDAR | Condição de Acionamento Típica | Resposta de CLP / Segurança | Comando de Velocidade do AMR | Propósito Típico | |---|---|---|---|---| | Zona Livre | Nenhuma intrusão detectada | Movimento normal permitido | Referência de 100%, ex: 2,0 m/s | Deslocamento normal | | Zona de Aviso | Objeto ou pessoa detectada no campo externo | Limitar velocidade, geralmente com alarme ou sinalizador | Setpoint reduzido, ex: 15% | Desaceleração controlada e redução de risco | | Zona de Proteção | Objeto ou pessoa detectada no campo interno | Parada de proteção, geralmente vinculada a STO ou caminho de parada segura equivalente | 0% | Evitar contato ou aproximação perigosa |

Como a ISO 3691-4 se relaciona com esta lógica?

A ISO 3691-4:2020 aborda os requisitos de segurança e verificação para veículos industriais autônomos e seus sistemas. Para este artigo, o ponto de engenharia relevante é direto: o AMR deve detectar perigos e transitar para um estado de redução de risco apropriado dentro de uma arquitetura validada.

Isso não significa "colocar um scanner nele e esperar que o acionamento se comporte". Significa que a lógica de campo, a categoria de parada, o comportamento de desaceleração e o método de verificação devem ser coerentes como um sistema.

O que significa "Pronto para Simulação" aqui?

"Pronto para Simulação" significa que um engenheiro pode provar, observar, diagnosticar e endurecer a lógica de zona contra o comportamento real da máquina antes que ela chegue a um AMR real.

Operacionalmente, isso inclui a capacidade de:

• observar mudanças no estado do campo LiDAR,
• rastrear essas mudanças nas entradas do CLP ou controlador de segurança,
• verificar a referência de velocidade ou comando de parada resultante,
• injetar condições anormais, como entradas obsoletas ou comandos atrasados,
• comparar o estado da ladder com o movimento simulado do veículo, e
• revisar a lógica após um teste malsucedido.

Esse é o limite útil: não apenas desenhar um degrau (rung), mas validar um caminho de resposta.

Você mapeia dados de campo LiDAR para a lógica do CLP convertendo as saídas do scanner em estados de entrada determinísticos que representam o status do campo, usando então esses estados para conduzir a limitação de velocidade ou o comportamento de parada.

Em muitos sistemas reais, os scanners de segurança expõem o status do campo através de saídas com classificação de segurança, como pares OSSD, fieldbus seguro ou uma interface de controlador de segurança. O caminho de hardware exato varia, mas o princípio de controle não: a camada de CLP ou de segurança deve receber um estado inequívoco que possa ser avaliado sem suposições interpretativas.

O que o CLP deve realmente receber?

O controlador deve receber sinais de estado de campo discretos e limitados, tais como:

• `LIDAR_CLEAR_OK`
• `LIDAR_WARNING_ACTIVE`
• `LIDAR_PROTECTIVE_ACTIVE`
• `SCANNER_FAULT`
• `FIELDSET_SELECT_VALID`

Isso é preferível a abstrações vagas. Se o nome da tag não puder lhe dizer qual estado da máquina ela representa, o comissionamento acabará fazendo isso por você.

Por que as convenções de entrada à prova de falhas são importantes?

O projeto de entrada à prova de falhas é importante porque um fio rompido, sinal perdido ou falha no scanner deve inclinar o sistema para um estado seguro em vez de movimento contínuo.

Para circuitos de segurança, isso geralmente significa projetar em torno do comportamento de lógica de segurança normalmente fechada (NC) no nível funcional, mesmo que a interface exata do dispositivo use saídas eletrônicas de canal duplo em vez de uma cadeia NC de contato seco literal. O princípio de engenharia é o ponto: a perda de um sinal saudável não deve ser interpretada como permissão para operar.

Um mapeamento prático pode ser assim:

• Canais de scanner saudáveis presentes = o movimento pode ser avaliado
• Campo de aviso violado = comando de velocidade reduzida
• Campo de proteção violado = comando de parada
• Discordância de canal ou falha do scanner = comando de parada
• Seleção de conjunto de campos inválida = parar ou inibir movimento, dependendo da avaliação de risco

E quanto à comutação dinâmica de campos?

A comutação dinâmica de campos significa que o conjunto de campos LiDAR ativo muda com o estado da máquina, comumente com base em:

• velocidade atual,
• ângulo de direção,
• direção de deslocamento,
• condição de carga,
• modo de corredor ou modo de área aberta,
• estado de acoplamento ou aproximação de precisão.

É aqui que o "dinâmico" na zona de segurança dinâmica se torna real. O envelope de proteção para uma manobra de acoplamento lenta não deve necessariamente corresponder ao envelope para deslocamento em piso aberto em velocidade máxima.

Você escreve a lógica de limitação de velocidade de AMR avaliando o estado da zona LiDAR ativa, atribuindo uma referência de velocidade limitada para cada condição válida e forçando um caminho de velocidade zero ou parada para qualquer estado de proteção ou falha.

A lógica ladder deve ser legível o suficiente para que outro engenheiro possa auditá-la rapidamente. A lógica adjacente à segurança não é o lugar para espertezas ornamentais.

### Passo 1: Ler e normalizar as entradas LiDAR

Comece trazendo o status do scanner ou do controlador de segurança para tags nomeadas.

Exemplo de tags de entrada:

• `LIDAR_Healthy`
• `Zone_Warning`
• `Zone_Protective`
• `AMR_Enable`
• `Drive_Permissive`
• `Scanner_Fault`

Nesta fase, normalize estados contraditórios. Se `Zone_Warning` e `Zone_Protective` estiverem ambos ativos, a lógica deve resolver para o estado mais restritivo.

### Passo 2: Criar uma decisão de estado de zona única

Use bits internos ou um registrador de estado inteiro para estabelecer uma condição de movimento autoritativa.

Exemplo de prioridade de estado:

1. Falha ou scanner não saudável
2. Zona de proteção ativa
3. Zona de aviso ativa
4. Zona livre

A prioridade é importante porque a lógica de movimento deve degradar com segurança sob ambiguidade.

### Passo 3: Mover o setpoint de velocidade correto

Use valores inteiros ou reais limitados para conduzir a referência de velocidade do AMR.

Conceito ilustrativo de ladder:

Linguagem: Ladder Diagram

// Lógica de parada de proteção |---[/]-------------------------------[MOV]---|     LIDAR_Healthy                       0                                             AMR_Speed_Ref

|---[ ]--------------------------------[MOV]---|     Zone_Protective                    0                                             AMR_Speed_Ref

// Lógica de limitação de velocidade da zona de aviso |---[ ]---[/]--------------------------[MOV]---|     Zone_Warning  Zone_Protective       15                                             AMR_Speed_Ref

// Velocidade normal da zona livre |---[/]---[/]---[ ]--------------------[MOV]---|     Zone_Warning Zone_Protective AMR_Enable                                             100                                             AMR_Speed_Ref

Isso é intencionalmente simples. Em uma arquitetura de produção, você frequentemente separaria a lógica de referência de velocidade padrão do caminho de parada com classificação de segurança e verificaria a interação cuidadosamente.

### Passo 4: Separar a limitação de velocidade do caminho de parada de proteção

Um comando de velocidade reduzida não é a mesma coisa que uma parada de segurança.

Essa distinção é fácil de confundir em um simulador e perigosa de confundir em uma máquina real. Uma referência de velocidade zero emitida sobre a lógica de controle padrão não é automaticamente equivalente a uma função de parada com classificação de segurança. Dependendo da arquitetura, a ação de proteção pode precisar acionar o Safe Torque Off (STO), Safe Stop 1 ou outra função de segurança validada sob princípios de projeto alinhados à IEC 62061 / IEC 61508.

### Passo 5: Adicionar diagnósticos e travamento onde justificado

Os diagnósticos melhoram o comissionamento e o isolamento de falhas.

Adições úteis incluem:

• alarme de scanner não saudável,
• alarme de estado inválido,
• registro de eventos de ultrapassagem de campo,
• registrador de causa de parada,
• requisito de reset manual após parada de proteção, onde a avaliação de risco exigir.

Uma máquina que para sem lhe dizer o porquê é apenas metade cooperativa.

O comportamento de parada correto depende da avaliação de risco da máquina, carga útil, dinâmica e projeto da função de segurança validada.

Um equívoco comum é que a parada mais rápida é sempre a mais segura. Não é. Uma parada de Categoria 0 remove a energia imediatamente; em alguns AMRs, especialmente aqueles que transportam cargas instáveis ou líquidos, isso pode criar riscos secundários através de inércia, deslocamento de carga ou perda de frenagem controlada.

Quando a redução de velocidade na zona de aviso é apropriada?

A redução na zona de aviso é apropriada quando o objetivo é diminuir a energia cinética antes que uma parada de proteção se torne necessária.

Usos típicos incluem:

• deslocamento em piso aberto onde a presença de pedestres é plausível,
• longas distâncias de parada em velocidades mais altas,
• ambientes com intrusão intermitente em campos de detecção externos,
• aplicações onde a desaceleração controlada melhora a estabilidade.

Quando uma parada de proteção é necessária?

Uma parada de proteção é necessária quando a intrusão atinge o campo interno ou quando o scanner ou caminho de segurança não pode mais garantir um movimento seguro.

Isso pode resultar em:

• Safe Torque Off (STO),
• uma parada controlada seguida pela remoção do torque,
• inibição de movimento mais sequência de reset,
• ou outra resposta de segurança validada definida pela função de segurança da máquina.

A norma não recompensa a improvisação. Ela recompensa a prova.

Você valida a lógica LiDAR do CLP contra um gêmeo digital comparando o estado do controlador, a velocidade comandada e o movimento simulado do AMR sob condições normais e de falha.

É aqui que o OLLA Lab se torna operacionalmente útil. Seu editor de ladder baseado em navegador, modo de simulação, painel de variáveis e cenários 3D/WebXR permitem que os engenheiros testem causa e efeito sem expor pessoas ou hardware ao primeiro rascunho da lógica.

O que você deve testar primeiro?

Comece com os casos determinísticos mínimos:

• zona livre ativa, sem estado de aviso ou proteção,
• violação da zona de aviso em velocidade nominal,
• violação da zona de proteção em velocidade nominal,
• falha do scanner,
• perda de sinal saudável,
• entrada de estado de zona contraditória,
• comportamento de reset e reinicialização após parada.

Use o painel de variáveis para observar:

• bits de zona ativa,
• `AMR_Speed_Ref`,
• estado de habilitação do acionamento,
• tag de causa de parada,
• bits de alarme,
• qualquer lógica de temporizador ou debounce.

Como é um teste de gêmeo digital válido?

Um teste válido não é "o robô desacelerou uma vez". É uma comparação repetível entre o comportamento esperado e o observado.

No OLLA Lab, isso significa que você pode:

• alternar ou induzir estados de zona,
• observar a transição da ladder,
• inspecionar o registrador de referência de velocidade,
• visualizar a resposta do AMR no cenário 3D,
• repetir o teste sob as mesmas condições,
• e revisar a lógica quando a resposta da máquina não corresponder à filosofia de controle pretendida.

Essa é a diferença entre animação e validação.

Por que o teste ao vivo em um AMR físico é um lugar ruim para aprender isso?

O teste ao vivo é caro, perigoso e geralmente intolerante a erros exploratórios.

Um engenheiro júnior não deveria precisar descobrir, em um veículo carregado em movimento, que um limitador de zona de aviso foi roteado através de um caminho lento ou não determinístico. O OLLA Lab fornece um ambiente de ensaio limitado exatamente para essa classe de erro: alta consequência, comum o suficiente para importar e difícil de praticar com segurança em equipamentos reais.

Você deve documentar um corpo compacto de evidências de engenharia, não uma galeria de capturas de tela.

Use esta estrutura:

Resuma o insight de controle, não apenas o resultado. Por exemplo: "a redução na zona de aviso sobre controle de rede padrão estava funcionalmente correta, mas muito lenta para este caso de velocidade de aproximação".

1. Descrição do Sistema Defina o modo do AMR, arranjo do scanner, lógica de campo, interface de acionamento e premissas relevantes.
2. Definição operacional de "correto" Declare exatamente o que deve acontecer nos estados livre, de aviso, de proteção e de falha.
3. Lógica ladder e estado do equipamento simulado Capture os degraus (rungs), tags e comportamento correspondente do AMR no simulador.
4. O caso de falha injetada Registre a condição anormal introduzida, como falha do scanner, bit de aviso obsoleto ou limitador de velocidade atrasado.
5. A revisão feita Mostre o que mudou na lógica, sequenciamento ou caminho de sinal.
6. Lições aprendidas

Esta forma de evidência é mais útil do que uma imagem de painel polida sem histórico de falhas. A memória de comissionamento é construída a partir de revisões, não de cosméticos.

As normas e estruturas técnicas primárias são segurança funcional e segurança de robôs móveis, não otimismo robótico genérico.

As referências mais relevantes incluem:

- ISO 3691-4:2020 para veículos industriais autônomos e seus sistemas,

• IEC 62061 para segurança funcional de máquinas,
• IEC 61508 como a estrutura fundamental de segurança funcional,
• manuais dos fabricantes de scanners de segurança para configuração de campo e comportamento de resposta,
• e avaliações de risco específicas da aplicação que definem as funções de segurança necessárias e o comportamento de parada.

A literatura acadêmica e industrial sobre gêmeos digitais e validação baseada em simulação também é relevante, mas deve ser usada com cuidado. A simulação pode melhorar a qualidade do ensaio, a visibilidade de falhas e a preparação para o comissionamento; ela não substitui a validação formal de segurança no sistema real.

O OLLA Lab se encaixa como um ambiente de validação e ensaio com risco contido para lógica ladder, comportamento de E/S, observação de gêmeos digitais e solução de problemas estilo comissionamento.

Limitado corretamente, essa é uma afirmação forte e útil. O OLLA Lab permite que os engenheiros:

• construam lógica ladder em um editor baseado na web,
• executem simulação sem hardware físico,
• monitorem tags e E/S no painel de variáveis,
• trabalhem através de cenários tipo AMR em ambientes 3D/WebXR,
• e testem como a lógica de controle mapeia para o comportamento da máquina antes da exposição no local.

Ele não certifica uma função de segurança, substitui uma avaliação de risco formal ou torna um AMR real seguro por associação. Um simulador é uma sala de ensaio, não um selo de conformidade.

Programar uma cerca de segurança virtual é um problema de controle com consequências de segurança. A tarefa principal é mapear estados de campo LiDAR para respostas determinísticas da máquina, e então verificar se o AMR realmente desacelera ou para como pretendido sob condições normais e de falha.

A distinção durável é simples: presença do sensor versus caminho de resposta validado. Muitos problemas de integração vivem nesse intervalo.

Um engenheiro útil neste domínio não é apenas fluente em sintaxe ladder. Um engenheiro útil pode definir o comportamento correto, testá-lo contra equipamentos simulados, injetar falhas, revisar a lógica e explicar por que o caminho de controle final é mais seguro do que o primeiro rascunho.

- Para contexto de segurança de robôs adjacente, veja ISO 10218-1:2025: Navegando pelas Novas Classificações de Segurança de Robôs. - Para integração em nível de planta e pressão de conformidade, veja Normas de Aplicação Colaborativa 2026: O Guia de Sobrevivência do OEM.

• Para colocar esta lógica dentro do comportamento mais amplo do sistema de controle, revise o Laboratório de Simulação PID e Controle de Processo Avançado.
• Testar isso em hardware físico é arriscado. Abra o cenário de LiDAR de AMR no OLLA Lab para validar a lógica de zona contra um gêmeo digital 3D.

- ISO 3691-4 requisitos de segurança para veículos industriais autônomos - IEC 62061 segurança funcional de sistemas de controle de máquinas - IEC 61508 Visão geral da segurança funcional - Revisão de Gêmeo Digital na Manufatura (IFAC-PapersOnLine) - Sistemas Ciber-Físicos na Indústria 4.0 (AQTR)