Timeouts de tarefa do WCS: quando o equipamento fica em silêncio por 30 segundos, tentar de novo ou esperar?

Deixe-me começar com um número que ainda dói: 47 segundos — foi aí que começou nosso pior erro de julgamento diante de um timeout de tarefa do WCS.

Em novembro passado, uma caixa ficou parada em um desvio da nossa esteira de segunda mão por 47 segundos. O WCS declarou um timeout de tarefa e disparou uma tarefa substituta. Mas a caixa não estava travada: um fotoolho empoeirado no desvio estava apenas lento para reagir. A segunda tarefa mandou o empurrador desviar a mesma caixa de novo, direto para a calha errada. Era um pedido urgente. O cliente em Los Angeles aguardava a estocagem. Pagamos frete urgente e perdemos uma tarde caçando uma única caixa.

Operamos um armazém de 3,000 metros quadrados. Não podemos nos dar ao luxo de queimar dinheiro assim. Desde aquele dia, desmontei toda a nossa bagunça de timeouts do WCS e montei de novo. Aqui está tudo o que aprendi.

Primeiro, nossa situação: esteira de segunda mão, elevador recondicionado e um único AMR novo, comprado a prazo. O padrão das grandes empresas de resposta de equipamento em milissegundos não existe no nosso mundo. O heartbeat do nosso PLC usado tira um cochilo de vez em quando, o WiFi cruzando duas fileiras de prateleiras atrasa tudo, e o AMR pode levar segundos para confirmar qualquer coisa. Os padrões do WCS assumiam equipamento novo. No nosso armazém, ele gritava timeout uma dúzia de vezes por dia, e nove em cada dez eram alarmes falsos.

Os limites de timeout de tarefa do WCS copiados dos grandes não vão servir para você

No início tentei ser preguiçoso e copiei uma tabela de timeouts recomendada pela indústria do nosso integrador. Só piorou: a esteira estourava o tempo em 5 segundos e gritava lobo o dia todo, enquanto o AMR recebia 30 segundos e o WCS ficava esperando bobamente quando ele realmente travava.

Depois levamos nosso integrador para beber algo, e foi aí que finalmente entendi: um timeout do WCS não é uma coisa só. São três camadas.

A camada um é o heartbeat: o equipamento está vivo? O heartbeat de um PLC normalmente pulsa a cada 1–3 segundos. Perder três seguidos e o dispositivo está basicamente offline. Essa camada não tem nada a ver com tarefas: é só um registro de presença.

A camada dois é o ACK: a tarefa chegou? O WCS despacha uma tarefa e o equipamento diz recebi. Uma esteira cabeada deve confirmar em 5 segundos: esse é o trabalho dela. Um AMR no WiFi está bem dentro de 15. Nosso elevador de segunda mão muitas vezes precisa de 8–10 segundos para confirmar. O padrão das grandes empresas diz timeout de 5 segundos; nós colocamos 12. Não há vergonha nisso. O equipamento é o que é.

A camada três é a confirmação de conclusão: o trabalho está feito? Essa é a grande. Uma tarefa de esteira pode levar 1–2 minutos do despacho até a caixa cair na calha. Um deslocamento de AMR entre zonas pode levar 5. O limite dessa camada tem de seguir o tipo de tarefa: não há tamanho único.

Aqui está a tabela em níveis em que ficamos. Roube-a e ajuste:

O ponto: os limites seguem a condição física do seu equipamento, não uma resposta padrão. Se todo o seu equipamento é novo, corte estes pela metade.

Timeout de tarefa: tentar de novo ou esperar? Verifique três coisas primeiro

Mesmo com bons limites, timeouts acontecem: o equipamento tem humores. A pergunta fatal é o que vem depois: reenviar ou esperar?

Aprendemos isso do jeito caro. Em 18 de novembro de 2025, por volta das 9 PM: nosso AMR pegou uma tarefa para mover um palete do recebimento até o saguão do elevador. Confirmou no saguão e esperou o elevador. Então o WiFi caiu por 40 segundos. O trabalho foi feito: só que a mensagem de concluído nunca chegou.

O WCS não viu confirmação de conclusão em 30 segundos, declarou timeout e enviou um segundo AMR (um aluguel de alta temporada) para mover o mesmo palete. Quando o WiFi voltou, a unidade um reportou tarefa concluída justo quando a unidade dois chegava. Dois robôs rodearam um palete. Depois a unidade dois fez seu trabalho: levantou o palete com o garfo, andou dois passos, encontrou o caminho bloqueado pela unidade um e largou o palete na faixa de incêndio.

Naquela noite: quatro pessoas, duas horas de retrabalho; uma faixa de incêndio bloqueada e uma multa por pouco do parque industrial; um AMR de aluguel cobrado por hora, queimando três horas à toa. Depois fizemos as contas: aquela única noite custou mais do que adicionar dois pontos de acesso WiFi em todo o armazém.

A causa raiz em uma frase: uma tarefa que já tinha ACK foi tratada como nunca executada e reenviada. Desde então, todo timeout passa por um quadro de decisão colado ao lado da nossa tela de controle: classificar primeiro, depois agir:

Primeiro, o ACK voltou? Sem ACK significa que o equipamento nunca recebeu a tarefa, provavelmente uma falha de comunicação. Reenviar é seguro. Mas verifique primeiro o heartbeat: se o dispositivo nem está mais se registrando, cem tentativas não vão ajudar. Mande um humano olhar o equipamento.

Segundo, a tarefa é reentrante? Consultas e sincronizações de estado: reenvie à vontade. Mas qualquer coisa que faça o equipamento se mover — transporte, desvio, empurrão — se já recebeu ACK uma vez, assuma que pode já estar fazendo e nunca tente de novo automaticamente. O WCS não sabe até onde o trabalho foi. Reenviar empurrar a caixa A para a calha 3 quando o empurrador já a empurrou, e o segundo empurrão pode atingir alguma caixa inocente B atrás dela.

Terceiro, olhe a onda. A carga travada ameaça o corte da onda? Se não, espere. Se sim, escale para um humano. Não feche uma linha inteira por uma caixa que ninguém está com pressa de receber.

Nossa solução barata: um pool de tarefas com timeout em um tablet aposentado

A resposta das grandes empresas são gêmeos digitais e retrofits de idempotência: seis dígitos. Não podemos queimar esse tipo de dinheiro. Nossa solução custou menos de $500.

Pegamos um tablet aposentado, montamos ao lado da esteira e colocamos exatamente uma tela nele: o pool de tarefas com timeout. Tarefas com timeout não tentam mais automaticamente. Elas caem no pool e ficam vermelhas.

O trabalho do operador é muito simples: ver vermelho, caminhar, olhar. Problemas de esteira são visíveis a olho nu: realmente travado ou só lento? Realmente travado: toque em manuseio manual, a tarefa vai para um humano. Só lento: toque em continuar esperando, e o WCS dobra a janela de conclusão. O equipamento nunca recebeu a tarefa: toque em confirmar reenvio.

Um mês depois que aquela tela humilde entrou no ar, os reenvios falsos passaram de uma dúzia por dia para zero. Cerca de 20 horas por mês de caça a despachos errados, sumiram. $500. Valeu a pena.

Nosso SOP de timeout, o colado na parede da sala de controle

Depois que a solução barata funcionou, escrevemos como SOP e colamos na parede:

L1 — automático: só tarefas sem ACK com heartbeat saudável podem tentar de novo automaticamente, no máximo 2 tentativas, com intervalos crescentes (30 segundos, depois 60). Ainda nada? Escale para L2.

L2 — confirmação humana: qualquer tarefa com ACK mas sem conclusão vai para o pool de timeout, e um operador confirma no local dentro de 5 minutos. O equipamento já fez → o WCS marca como concluído. Nunca executado → o humano toca em reenviar.

L3 — trave a via: o mesmo equipamento estoura o tempo 3 vezes em uma hora, ou dois veredictos L2 seguidos de falha de equipamento: trave a via, chame a manutenção, e o WCS desvia as tarefas para uma via reserva, se houver.

E uma regra de ferro: o WCS nunca pode disparar dois comandos de execução para a mesma tarefa dentro de 30 segundos. Essa regra foi comprada com aquela noite de novembro. Está na configuração agora, e ninguém pode mudá-la.

Uma lição contraintuitiva: limites de timeout mais curtos não são mais sensíveis. Um limite de gatilho fácil é um supervisor nervoso gritando sobre tudo. Bombardeie os operadores com alarmes falsos por um mês e eles aprenderão a ignorar cada alarme, inclusive os reais. A história do menino que gritava lobo acontece em armazéns todos os dias. O trabalho de um limite não é pegar anomalias instantaneamente: é pegá-las quando importa. Prefiro deixar um timeout real esperar 30 segundos a mais do que deixar os falsos moerem a atenção das pessoas até virar pó.

Nosso WCS é de segunda mão, nosso equipamento é de segunda mão, até o tablet está aposentado. Mas desde que arrumamos os timeouts, na alta temporada com 8,000 pedidos por dia, nenhum acidente de reenvio.

Armazéns pequenos têm seu próprio jeito de sobreviver: os grandes compram estabilidade com dinheiro; nós a compramos admitindo a realidade: o equipamento tem humores, os limites precisam de folga, e algumas coisas só precisam que um humano caminhe e olhe. Admitir isso não é vergonhoso. Acidentes são.

Por Xiao Ma, proprietário de um pequeno armazém

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