Pergunta rápida: o que o seu WCS faz quando um pacote trava na junção às 2 a.m., o scanner começa a perder leituras e alguém aperta a parada de emergência — tudo na mesma hora? Se a sua resposta honesta for "vamos descobrir no dia da entrada em operação", continue lendo. Eu estava naquele prédio naquele dia, vendo dezenas de pessoas olhando fixamente para um transportador que simplesmente... havia parado. O WCS dizia uma coisa, o WMS dizia outra, e o rosto do gerente do projeto dizia tudo.
Quase todos esses desastres eram evitáveis. O método tem um nome pouco glamoroso: comissionamento virtual — e significa exatamente o que parece: antes de o aço subir, você faz o WCS real acreditar que o equipamento já existe, e o coloca para rodar pesado. Você roda pedidos, quebra coisas, corrige a lógica. Quebrar coisas em um ambiente virtual é grátis. Quebrá-las no local custa dinheiro a cada minuto.
O que você está realmente testando
Em uma frase: um software modela todo o seu sistema de transportadores e separadores, e o WCS real se conecta e o executa. A simulação constrói a sua linha conforme o projeto — comprimento, quantas calhas de desvio, onde ficam os scanners, onde é a via de rejeição — e o WCS emite comandos exatamente como faria no local. O modelo responde de acordo com a física: peso do pacote, velocidade da esteira, o que acontece quando o fluxo congestiona.
Uma distinção que as pessoas confundem o tempo todo: simulação é virtual sobre virtual, útil para validar a lógica do processo. Emulação é o WCS real dirigindo equipamentos virtuais, e é isso que valida a lógica de controle. Antes da entrada em operação, você quer emulação — e o WCS sob teste deve ser exatamente a versão que vai entrar em operação, nem uma linha de código diferente. Um teste verde em uma versão de demonstração seguido da troca para a versão de produção é um teste desperdiçado.
Insisto que o ambiente de emulação seja construído durante os testes de aceitação na fábrica, não depois de o equipamento ser embarcado. Uma vez que o aço começa a subir no local, a pressão do cronograma comprime o comissionamento a um terço do planejado, e cada problema não resolvido acompanha você até o dia da entrada em operação. Na fábrica, quando a lógica está errada, um engenheiro corrige o código do CLP ou a lógica do WCS em casa. No local, você faz isso cercado de guindastes, andaimes e um responsável de segurança — o custo psicológico de mudar uma linha de código é completamente diferente.
Injeção de falhas: teste no pior cenário, de propósito
Dez mil pedidos limpos ensinam menos do que cem pedidos feios. O maior valor do comissionamento virtual é a sabotagem sem consequências. Você travaria deliberadamente um separador em produção? No mundo virtual, trave o dia inteiro e reinicie com um clique.
A minha lista obrigatória de falhas é esta. Travamentos: bloqueie a calha de desvio, a rampa inclinada e a junção — um de cada vez — e observe quão rápido o WCS detecta, se o alarme é preciso e se a sequência de recuperação realmente funciona. Falhas de leitura: leituras perdidas consecutivas, códigos de barras danificados, dois pacotes parecidos um atrás do outro — a lógica de rejeição expulsa o pacote problemático de forma limpa, ou o recircula para sempre? Um pacote ruim recirculando sem fim é o modo de falha mais bobo que existe; um único item ruim pode derrubar o rendimento da linha inteira. Parada de emergência: aperte em momentos aleatórios — a sequência de desligamento está correta, o estado do pedido é preservado na recuperação, algum pacote é "esquecido" em um trecho de esteira? Perda de rede: corte o link WCS–WMS por alguns minutos — as mensagens se perdem ou entram em fila, e os dois sistemas se reconciliam depois?
Após cada categoria de falha, exija três coisas do fornecedor: os registros do sistema daquele momento, os registros de alarmes do WCS e quanto tempo a recuperação levou. Esse é o seu prontuário para a solução de problemas na entrada em operação. Um projeto sem esses prontuários rediagnostica do zero toda vez que algo quebra — meia hora de inatividade por palpite.
A interface WCS–WMS é onde os projetos morrem
Metade das falhas de automação é equipamento. A outra metade é a interface. O WCS move as máquinas, o WMS é dono dos pedidos e do estoque, e eles se reconciliam por mensagens. Quando a interface mente, o chão mente junto: o WMS acha que enviou o pedido, o WCS diz que nunca chegou; a separação termina, o estoque nunca baixa; uma oscilação de rede e cada lado mantém os seus próprios registros.
Teste a interface no pior cenário, em três partes. Primeiro, reconciliação de mensagens: após uma rodada em lote, compare o status dos pedidos, as contagens de peças e os resultados da separação linha por linha entre os dois sistemas. Nenhuma linha pode diferir — e note: linha por linha, não totais. Totais que batem com linhas embaralhadas são um problema pior e mais traiçoeiro. Segundo, heartbeat e reconexão: simule instabilidade de rede e observe mensagens perdidas na reconexão — e se as tentativas causam duplas separações. Uma dupla separação é o bug de interface mais caro que existe: um pedido separado duas vezes, o cliente recebe dois pacotes, e as devoluções mais o custo do atendimento chegam imediatamente. Terceiro, pedidos de casos extremos: superdimensionados, com excesso de peso, de múltiplas peças, cancelados no meio do caminho — os "pedidos estranhos" que o WMS com certeza vai enviar. Pedidos normais rodam em qualquer lugar. Pedidos estranhos são o verdadeiro teste.
Os critérios de aceitação pertencem ao contrato
Comissionamento virtual não é "está rodando, embarca". Os critérios de aceitação vão para o contrato na assinatura. Os meus têm três linhas, e eu não assino sem as três.
Primeiro, operação contínua sem supervisão. Rode a emulação no rendimento de projeto com zero intervenção humana — exijo oito horas no mínimo. Esta é a linha mais fácil de burlar: os fornecedores adoram a "operação contínua" com um operador por perto, pronto para salvar. Isso não é sem supervisão. A minha regra: durante o teste, os operadores podem observar, mas nunca tocar. Um toque reinicia o relógio. Duro? Claro. O dia da entrada em operação não oferece recomeços, e os pedidos da alta temporada não vão esperar por você.
Segundo, precisão de separação. Calha errada, desvio perdido, exceção não rejeitada — tudo conta como erro, e a taxa permitida vai para o contrato como um número, dimensionada à sua tolerância de negócio. "O mais preciso possível" não é um padrão. Um padrão sem número não é um padrão.
Terceiro, tempo de recuperação de falhas. Tempo máximo permitido do alarme de travamento ao retorno à operação normal — se exceder, reprovou. Esta linha é para a equipe de operação: quando o alarme das 2 a.m. tocar após a entrada em operação, a pessoa de plantão precisa saber quanto tempo isso deve levar, e quando escalar. Os tempos de recuperação medidos no comissionamento virtual são a base dessa linha.
O comissionamento virtual costuma consumir de cinco a dez por cento do tempo total do projeto. Parece custo; na verdade é a cobertura de risco mais barata que você vai comprar. Um dia de comissionamento no local — mão de obra, içamento, linhas paradas — compra centenas de milhares de pedidos virtuais. Lembre-se disto: cada erro que você não cometer no ambiente virtual se paga com juros no dia da entrada em operação.
Uma última pergunta para você: o comissionamento virtual foi ideia do seu fornecedor, ou você teve que exigi-lo? Se foi deles — parabéns, você escolheu o fornecedor certo. Se foi sua — vá pedir agora. Ainda há tempo, desde que o aço ainda não tenha subido.
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
