Tempestade de alertas do RCS: quais alarmes de AMR silenciar — e quais nunca ignorar

Opere um armazém com 50 AMRs e seu RCS pode facilmente cuspir milhares de alertas por dia. É como instalar 20 apps no seu celular, cada uma enviando 10 notificações por hora — em uma semana, o operador da sala de controle aprende a descartar todas por reflexo. E é aí que uma falha real se afoga no ruído, invisível para todos.

Isso é fadiga de alertas. Os hospitais descobriram isso há uma década. A automação de armazéns é a próxima.

Por que os alertas do RCS explodem

O RCS é o guarda de trânsito e o despachante da frota — rotas, tarefas, carregamento. Pense assim: cada AMR carrega dezenas de sensores — LiDAR, para-choques de segurança, encoders, o BMS da bateria, rádios WiFi — cada um com seu próprio limite, cada um disparando eventos para cima. Cinquenta robôs vezes dezenas de sensores vezes 24 horas: essa é sua matéria-prima.

A inundação geralmente vem de três lugares.

Primeiro, a camada do robô. Eventos que o próprio AMR gera: oscilações de temperatura da bateria, desacelerações pontuais por obstáculos, relocalização, roaming WiFi. Alto volume, e a grande maioria se autocorrige.

Segundo, a camada da frota. Eventos que o RCS gera: tempos de tarefa esgotados, deadlocks de rota, congestionamento de zonas, esperas na fila de carga. Baixo volume, mas cada um toca diretamente o throughput.

Terceiro — e vou dizer sem rodeios — o instinto de autoproteção do integrador. Muitos projetos saem com regras de alerta configuradas para responsabilidade legal em vez de operação: "alerte quando o sinal WiFi cair abaixo de -70 dBm". Esse alerta não serve para nada além de treinar os operadores a ficarem insensíveis. Não tenho paciência para pseudo-requisitos: mais alertas não é mais diligência. Mil alertas que ninguém lê é o mesmo que zero.

Triagem: alarmes de AMR têm três níveis. Mais que isso é teatro

Três níveis: P0, P1, P2. Uma linha dura os separa: se ninguém olhar este alerta, a linha para em 30 minutos? Sim vai para P0. Não, mas o throughput sofre, vai para P1. Nenhum dos dois, vai para P2, direto para o log. Rústico, mas funciona.

Duas histórias de campo.

No fim de 2024, antes do pico do Dia dos Solteiros, um armazém de e-commerce no leste da China operava 60 AMRs com a política de alertas do RCS nos padrões de fábrica: tudo ligado, mais de 4,000 alertas por dia. O operador me contou depois que tinha aprendido a "olhar o popup com o canto do olho e fechar". Então o BMS de um robô sinalizou sobretemperatura da bateria — um P0 de verdade — enterrado sob milhares de entradas de "roaming WiFi" e "desaceleração por obstáculo". Mais de quarenta minutos depois, uma ronda encontrou o robô morto no corredor principal, meia linha de picking caída. A autópsia coube em uma frase: não é que não houvesse alertas; havia tantos que era o mesmo que nenhum.

O contraexemplo está no sul: um armazém 3C com 40 AMRs passou seu primeiro mês enviando popups de "relocalização bem-sucedida" — eventos autocorrigidos. Setecentos dos seus 800 alertas diários eram boas notícias. Nova regra: o autocorrigido vai para o log; só a recuperação falhada escala. Os popups caíram de 800 para cerca de 60 por dia, e o operador voltou a olhar a tela. O problema nunca foi "alertas insuficientes".

Silenciar não é apagar: três armadilhas no ajuste de alertas

Níveis definidos. Agora vem o trabalho manual de silenciar regras e ajustar limites — e três armadilhas que vi cada uma engolir pelo menos um projeto.

Armadilha 1: silenciar e esquecer. Silenciar é uma decisão de risco. Precisa de um registro de mudanças: quem aprovou, por quê e quando expira. É como tirar a bateria de um detector de fumaça sem avisar a administração do prédio — quando há um incêndio, a primeira pergunta é "quem tirou a bateria". Minha regra: cada silenciamento vai para um registro com um aprovador e uma data de revisão; silenciamentos vencidos se restauram automaticamente, forçando uma reavaliação.

Armadilha 2: copiar limites do armazém de outro. Planicidade do piso, cobertura WiFi, densidade de racks — não há dois sites iguais. "Alertar quando as desacelerações por obstáculos excederem 10 por minuto" pode ser perfeito no Site A e uma máquina de falsos alarmes no Site B. A sequência correta: rode as primeiras duas semanas com tudo logando mas nada notificando, e depois defina os limites com seus próprios dados. Observe primeiro, legisle depois — não o contrário.

Armadilha 3: deduplicação agressiva demais. Algumas equipes fundem "falha de navegação" e "tempo de tarefa esgotado" em uma única "anomalia de AMR" para reduzir a contagem, e depois choram ao solucionar problemas. Só deduplique repetições da mesma causa, no mesmo robô, com minutos de diferença. Nunca funda causas diferentes — você deduplica o ruído, não a informação.

Antes de silenciar um único alerta, passe-o por esta matriz de decisão:

A célula superior direita merece uma palavra: um alerta ao mesmo tempo frequente e grave significa que seu sistema em si está doente. Ajustar alertas ali é dar analgésico a um paciente crítico.

E uma ideia contraintuitiva para fechar a parte técnica: as pessoas assumem que "quanto mais você silencia, mais perigoso o sistema". Ao contrário. Silenciar não é perigoso; o perigoso é silenciar coisas que ninguém sabe que estão silenciadas. Um sistema com tudo em P0 e um sistema sem alertas morrem exatamente do mesmo jeito — ninguém está olhando.

Então o dinheiro valeu a pena? Um número diz: o tempo médio entre o disparo de um alerta P0 e um humano começar a tratá-lo. Baixe de 40 minutos para 5, e seu esforço de governança de alertas se pagou. Se não se mover, tudo antes disso — a triagem, o silenciamento, a deduplicação — foi teatro.

Por Da Liu, Engenheiro de automação

Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.