O deadlock de muting que prendeu um carro dentro do seu próprio campo de segurança

Uma cortina de luz tem exatamente um trabalho: parar a máquina quando uma pessoa está em algum lugar onde não deveria estar. Em um arranjo de muting em que trabalhei, ela fez esse trabalho perfeitamente. E ao fazê-lo, prendeu o carro que ela foi construída justamente para deixar passar.

Esta é a versão longa de algo que postei, porque a versão curta não deixa espaço para a parte que de fato importa — por que aconteceu, e por que a correção óbvia acabou se mostrando pior do que o problema. Se você trabalha com muting em qualquer lugar, esta é uma armadilha que vale a pena entender antes de encontrá-la numa máquina em operação, em vez de depois.

O que estávamos protegendo

Um carro de transporte ia e voltava através de uma zona protegida. A proteção era uma cortina de luz SICK deTec4 com um controlador de muting DMM4 alimentando o sinal de segurança para um CLP Siemens.

O problema de colocar uma cortina de luz na frente de um carro em movimento é óbvio: o carro interrompe os feixes toda vez que passa. Se a cortina tratasse o carro como uma pessoa, a máquina dispararia a cada ciclo e nada nunca se moveria. Então você precisa que a cortina deixe o carro passar sem baixar a guarda contra pessoas.

É para isso que serve o muting.

Por que o muting existe, afinal

Muting é a suspensão deliberada, automática e temporária de uma função de segurança para que um objeto esperado possa atravessar um dispositivo de proteção sem parar a máquina — enquanto uma pessoa ainda não pode. Não é um improviso nem uma trapaça. É uma função definida, com suas próprias normas por trás: a própria cortina de luz se enquadra na IEC 61496 (equipamento de proteção eletrossensível), e a aplicação do muting especificamente é coberta pela IEC 62046 (aplicação de equipamentos de proteção para detectar a presença de pessoas). O nível de desempenho que toda a função de segurança precisa atingir está na ISO 13849.

O truque do muting é distinguir um carro de uma pessoa. Você faz isso com sensores de muting — sensores separados, dispostos de modo que apenas o objeto esperado, chegando da maneira esperada, possa satisfazê-los. Tenha o padrão certo na ordem certa e o controlador diz é o carro, e aplica o muting. Uma pessoa se aproximando a pé não consegue reproduzir esse padrão, então a cortina continua ativa para ela.

Nesse arranjo era muting parcial: os feixes inferiores recebiam muting para que o carro pudesse passar rolando por baixo, enquanto os feixes superiores permaneciam ativos o tempo todo para proteger qualquer um que estivesse parado na zona. O muting em si era disparado por dois fotossensores em uma palheta — um arranjo de L-muting — que acionavam à medida que o carro entrava.

Funcionou bem por muito tempo. Até que não funcionou mais.

O deadlock

Alguém interrompeu os feixes superiores, que estavam ativos, enquanto o carro ainda estava parado dentro do campo.

Isso não é uma falha — é a cortina funcionando. Os feixes superiores estão ali exatamente para isso. As saídas OSSD (as saídas de segurança que dizem aos acionamentos “vocês estão autorizados a se mover”) foram desativadas. Comportamento completamente correto.

É aqui que tudo se embola:

• O DMM4 derruba o muting no instante em que dispara. Tudo bem por si só.
• Mas o carro ainda está ali, ainda bloqueando os feixes inferiores.
• Então, com o muting fora, a cortina agora também enxerga o carro como uma obstrução. O campo inteiro é lido como bloqueado. Vermelho total.
• Ela não aceita um reset, porque um reset quer ver o campo inteiro livre primeiro — a cortina precisa estar exibindo o amarelo piscante antes de aceitar uma confirmação.

Agora acompanhe o ciclo. O carro não pode se mover, porque os acionamentos precisam de um OK de segurança para funcionar. A segurança não pode ser confirmada, porque a cortina não está livre. E a cortina não pode ficar livre, porque o carro está parado no meio dela e não pode se mover.

Deadlock clássico. O carro fisicamente preso entre o emissor e o receptor, e nenhum botão no painel que o tire dali.

Borda, não nível

Demorei um pouco para realmente entender isso, em vez de só resolver na força bruta.

O L-muting no DMM4 é disparado por borda, não disparado por nível. Essa distinção é a história inteira, então vale a pena ser preciso quanto a ela:

• A lógica disparada por nível atua sobre um estado. Enquanto a entrada estiver em nível alto, a condição se mantém. Ela se importa com onde o sinal está.
• A lógica disparada por borda atua sobre uma transição. Ela dispara na mudança — uma borda de subida (0 → 1) ou uma borda de descida (1 → 0). Ela se importa com o momento em que o sinal se move.

O DMM4 arma o muting numa borda de subida dos sensores de muting — o momento em que eles passam de “sem carro” para “carro chegando.” Normalmente é exatamente o que você quer: isso comprova uma aproximação recente e sequenciada, em vez de algo apenas parado no feixe.

Mas percorra a nossa situação com isso em mente. O OSSD dispara. O carro nunca sai. Então os sensores de muting estão já em nível alto — eles foram para o nível alto quando o carro chegou e permaneceram em nível alto o tempo todo. Para o muting rearmar, o DMM4 precisa ver uma borda de subida. E não há nenhuma borda de subida disponível, porque o sinal já está no topo. Ele não pode subir a partir de um nível em que já está. Sem borda, sem muting, sem saída.

Comprovei isso da maneira rústica: puxei o carro para fora do campo com as mãos e, em seguida, conduzi-o de volta para dentro. Aproximação nova, borda de subida nova nos sensores de muting — e o muting voltou na hora. Isso confirmou. O sistema não estava com defeito. Ele estava fazendo precisamente o que a lógica disparada por borda faz. Ele só não tinha caminho de volta para um estado de muting sem uma transição que o próprio deadlock tornava impossível.

A correção de um botão — e o buraco que ela abriu

A correção óbvia parecia limpa. No SICK Safety Designer, converter a entrada de reset existente em uma entrada de reset/override — um botão, e o DMM4 decide qual é qual com base no estado atual. Faz o override da condição travada, coloca o carro em movimento, pronto. Limpo no papel.

Aí eu olhei o que o override realmente faz, e parei de gostar dele rápido.

Um override mantém o OSSD em verde enquanto o sensor de muting permanecer bloqueado. Ele só derruba o override quando o sensor vai de 1 → 0 — uma borda de descida, o carro finalmente saindo. O que é ótimo se a única coisa que algum dia bloqueia esse sensor for um carro real a caminho da saída.

Mas não há nada que force isso. Segure qualquer coisa na frente do sensor de muting e o override mantém o OSSD em verde basicamente para sempre. A cortina inteira — feixes superiores inclusos, os que protegem as pessoas — contornada, por tempo indefinido, com um sensor bloqueado e um aperto de botão.

E repare na simetria, porque é aqui que está a verdadeira lição enterrada. O deadlock original veio de uma lógica disparada por borda — ele precisava de uma transição que não estava disponível. A correção por override é disparada por nível — ela permanece ativa enquanto o estado for mantido. Eu havia trocado um modo de falha por outro. O primeiro te prende e você consegue vê-lo. O segundo contorna a sua proteção e você não consegue. É uma troca estritamente pior.

Por que o override é a correção errada

Eu até liguei para a SICK para conversar sobre isso, e nunca encontrei uma resposta de que eu gostasse — nenhuma que fechasse o buraco sem reintroduzir alguma versão do problema original.

É por isso que o override de um botão é a troca errada. Um paro visível que exige que alguém libere fisicamente o campo é irritante. Um bypass silencioso e mantenível de uma proteção que protege pessoas é uma categoria de coisa completamente diferente — não algo que valha a pena projetar para economizar alguns segundos de tempo de recuperação.

O que isso me ensinou sobre projeto de muting

Vou ser honesto: nunca encontrei uma correção da qual eu realmente gostasse, e ainda acho que existe uma resposta mais limpa por aí que eu não alcancei. Diante da escolha, eu fico sempre com um paro visível e recuperável em vez de um bypass que dá para manter aberto.

Mas saí dessa entendendo muting de um jeito que nenhum datasheet havia me ensinado. Muting é um buraco deliberado na sua função de segurança. Isso não é uma crítica — é o ponto inteiro dele, e é uma coisa legítima e padronizada de se fazer. A disciplina está em manter esse buraco firmemente delimitado: delimitado pela lógica dos sensores, pela sequência, pela geometria, pelo tempo, de modo que ele não possa ser falsamente aberto nem mantido aberto. Toda “conveniência” que você acrescenta para se recuperar de um caso de borda incômodo é uma candidata a alargar esse buraco, e o override foi um exemplo perfeito — ele resolvia uma irritação real removendo silenciosamente o limite.

E a coisa que eu diria a qualquer um que esteja configurando muting pela primeira vez: borda versus nível não é uma nota de rodapé. É o comportamento real da sua função de segurança nas condições que você não planejou. A lógica disparada por borda pode te deixar encalhado quando a transição que você espera não pode acontecer. A lógica disparada por nível pode manter um estado perigoso aberto enquanto algo o mantiver em nível alto. As duas estão corretas. As duas vão te morder. Saber qual delas você construiu, e exatamente o que acontece com ela quando a máquina acaba em algum lugar que você não imaginou, é a maior parte do trabalho.

O carro saiu. Nunca cheguei à correção elegante que eu queria — mas eu confio muito mais no muting agora, justamente porque sei exatamente onde estão suas bordas.