Pense na programação de tarefas do RCS como o balcão de triagem de um pronto-socorro. Os pacientes (tarefas) não param de chegar; a enfermeira da triagem (o programador) decide pela gravidade (prioridade) quem entra primeiro na sala de trauma (um robô). A via de emergência existe para emergências de verdade, mas se cada família gritar "o nosso é urgente", a triagem entra em colapso. A configuração de prioridade de tarefas do RCS faz exatamente esse trabalho: decide quem embarca primeiro e quem espera.
Como funciona: filas, pesos e o ciclo de despacho
O RCS é o cérebro da frota de robôs. A cada 100 ms até cerca de um segundo, ele executa um ciclo de despacho: pontua cada tarefa em espera, ordena e atribui as de maior pontuação aos robôs livres. A pontuação de uma tarefa é mais ou menos assim:
task score = priority weight × f(wait time, distance, battery, task type)
A preempção de pedidos urgentes significa literalmente tomar posse. Observe o que é tomado: não um lugar na fila, mas capacidade. O tempo de robô é fixo: cada minuto que um pedido urgente toma é um minuto que uma tarefa normal espera.
Dá para pensar nisso como uma praça de pedágio de rodovia: a pista ETC (alta prioridade) avança primeiro enquanto a pista de pagamento em dinheiro (tarefas normais) fica na fila. Mas não dá para continuar acrescentando pistas ETC: faça de todas as pistas ETC e ninguém estará furando fila nenhuma; a praça continua travada. Prioridade só significa alguma coisa quando é escassa.
O f() da fórmula merece um olhar mais atento: o tempo de espera protege contra "esperar para sempre", a distância escolhe o robô mais próximo, a bateria filtra unidades com pouca carga e o tipo de tarefa distingue trabalhos de transporte, elevação e carregamento. Uma tarefa P2 que espera há 10 minutos pode superar a pontuação de uma P1 recém-chegada quando o envelhecimento (aging) entra em ação: esse é todo o sentido do envelhecimento, e também o ajuste que a maioria desativa sem pensar e do qual mais se arrepende depois.
Três formas de configurar a preempção, e o que cada uma custa
Configuração A: ponderação por prioridade. Aumente o peso de prioridade do pedido urgente: por exemplo, tarefas normais em 5, pedidos urgentes em 50. Um único parâmetro, simples demais. O custo: se aumentar demais (por exemplo, 100), as tarefas de baixa prioridade nunca são atendidas. Isso é inanição (starvation), e vai arrastar uma onda normal até a morte.
Configuração B: reatribuição preemptiva. Quando chega um pedido urgente, requisite um robô que esteja trabalhando numa tarefa de baixa prioridade; a tarefa interrompida volta atrás e entra de novo na fila. A resposta mais rápida. O custo é o deslocamento vazio (deadhead): a viagem interrompida foi quilometragem desperdiçada, e agora precisa ser refeita.
Configuração C: capacidade reservada. Mantenha 10–20% da frota fora das ondas normais, dedicados a pedidos urgentes. A opção mais estável. O custo é capacidade ociosa em dias tranquilos: soldados que você alimenta por mil dias para um dia de batalha.
| Configuração | Resposta a urgências | Impacto nas ondas normais | Complexidade | Adequada para |
|---|---|---|---|---|
| A Ponderação | Rápida | Mata a onda se exagerada | Baixa | Participação de urgências estável abaixo de 5% |
| B Preempção | A mais rápida | Mais deslocamentos vazios, reversões de tarefas | Baixa | Urgências raras que exigem resposta de segundo nível |
| C Capacidade reservada | Sempre rápida | Quase nenhum | Baixa | Participação de urgências volátil com picos claros |
Um projeto que ajustei em 2025: um armazém de comércio eletrônico no leste da China, 180 AMR. Peso de urgências fixado em 50. Com uma participação normal de urgências de 3%, tudo ia bem; no dia do festival de compras 618, os pedidos urgentes saltaram para 15%, a espera média das tarefas normais subiu de 50 segundos para 4 minutos e a taxa de pontualidade das ondas caiu 12 pontos. Os registros mostraram uma tarefa de baixa prioridade esperando 47 minutos: inanição de manual. A causa raiz era uma única peça faltante: ponderação configurada, nenhum mecanismo de envelhecimento.
Como escolher entre as três? Olhe a participação de urgências: estável abaixo de 5%, use A: barata e suficiente. Rara, mas com necessidade de resposta de segundo nível (uma linha de produção prestes a parar), use B. Volátil com picos claros (grandes eventos de vendas, fim de trimestre), use C. A maioria dos armazéns termina com um híbrido A+C: ponderação em dias normais, capacidade reservada ligada duas semanas antes do pico. A linha divisória não é técnica, é o ritmo do negócio, e é por isso que nove em cada dez pessoas que copiam os parâmetros de outro armazém acabam revertendo.
A configuração de prioridade de tarefas do RCS testada em campo: níveis, envelhecimento e capacidade reservada
Níveis. P0 urgência de verdade (manter abaixo de 5% do volume) / P1 ondas prioritárias / P2 normal / P3 adiável (reposição, contagens cíclicas). A regra de ferro para o que conta como "urgente": não que vendas diga que é urgente, mas que o prazo do SLA esteja a menos de X horas. Quando vendas diz "este lote é urgente", faça primeiro duas perguntas: "qual é a penalidade do SLA e perdemos o cliente?" Não sabe responder? Vai para P2. É aqui que nascem os requisitos falsos, e nunca me contenho em denunciá-los.
Envelhecimento. Tarefas que esperam demais são promovidas automaticamente: o piso que evita a inanição:
effective priority = base weight + factor × wait time / threshold
Sem envelhecimento, mesmo pesos lindamente ajustados são uma bomba-relógio: tranquilos em dias normais, explosão garantida no pico.
Capacidade reservada. 15–20% na alta temporada, 5–10% fora dela, ajustada dinamicamente com a participação de urgências, nunca fixada em código. Lembre-se: os pesos reordenam a fila; não criam capacidade. Se a participação de urgências passar de 10% e você continuar apenas ajustando pesos, está usando a ferramenta errada.
As armadilhas de manutenção: configure uma vez, sofra para sempre
Armadilha 1: ajustar uma vez e rodar um ano. A alta temporada muda o mix de SKU e o ritmo das ondas, mas os pesos continuam os do ano passado. A configuração de prioridade deve acompanhar o plano de ondas: revisão pelo menos trimestral e sempre um novo ajuste antes do pico.
Armadilha 2: testar sem carga, então a inanição nunca aparece. Os testes só observam o tempo médio de espera, e médias são a métrica mais desonesta que existe. O número que importa é o tempo máximo de espera das tarefas de baixa prioridade. Quando ele sobe, a inanição está chegando.
Armadilha 3: blindar-se contra uma participação de urgências acima do limite. Se os pedidos urgentes ficarem acima de 10% do volume a longo prazo, isso não é um problema de programação, é um problema de capacidade: adicione robôs ou rebaixe alguns pedidos "urgentes" para P2. Não dá para tapar um buraco de capacidade com parâmetros do programador.
Armadilha 4: deixar qualquer um marcar P0. O maior inimigo da prioridade não são os parâmetros, são as pessoas. Os direitos de marcação P0 devem ser restritos: quem pode marcar, se exige aprovação e uma auditoria mensal da verdadeira participação de P0. Deixe a marcação aberta e P0 ultrapassará 20% em três meses; nenhum ajuste salva você depois disso.
Então, a configuração de prioridade vale a pena? Observe um par de números: a taxa de pontualidade dos pedidos urgentes atingindo a meta enquanto o tempo médio de espera das tarefas normais permanece estável. Ambos verdadeiros, e a configuração está certa. Só um verdadeiro, e você está se enganando.
Por Da Liu, Engenheiro de automação
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
