Pis paralelo para programação de produção; Cortando minutos e dólares da montagem

As linhas de montagem de produtos eletrônicos são feras complicadas, geralmente compostas de muitas ferramentas e acessórios personalizados. Normalmente, um microcontrolador deve ser programado com firmware e a placa de circuito testada antes da montagem no gabinete, seguida de testes funcionais antes de colocá-la em uma caixa. Essas plataformas de teste podem ser muito caras, chegando facilmente a dezenas de milhares de dólares. Em vez disso, este projeto usa um conjunto de 12 Raspberry Pi Zero Ws em paralelo para programar, testar e configurar até 12 unidades de uma vez antes de passar para o próximo estágio de montagem.

A empresa onde trabalho, Propeller Health, desenvolve produtos IoT que são montados de forma semelhante a muitas outras empresas; há uma placa de circuito e um invólucro de plástico. Os PCBs simples passam pelo SMT duas vezes (componentes na frente e atrás), depois passam pelo ICT (In-Circuit Test), onde são programados e os pinos pogo em cada um dos pontos de teste verificam todos os componentes do circuito. Eles também recebem um endereço MAC exclusivo para Bluetooth com base em um adesivo de código de barras 2D colocado na placa após o SMT. Depois disso, eles são montados nos plásticos e passam por um dispositivo de teste funcional antes de serem colocados no modo de inventário e embalados. Temos uma linha de produtos com cerca de uma dúzia de dispositivos diferentes e cada um usa uma PCB e um gabinete diferentes.

As execuções de produção precisam de acessórios de teste e programação, um tópico sobre o qual escrevi há alguns anos. Para aumentar a escala e reduzir custos, começamos a trabalhar mais de perto com nosso fabricante contratado para identificar e corrigir os gargalos no processo da linha de montagem, e percebemos que a etapa de TIC estava demorando 6 minutos para um painel de 6 placas. A seção ICT em si era relativamente rápida, mas a programação do firmware e do mac demorava muito porque a plataforma de teste não era capaz de múltiplas conexões de porta serial simultâneas.

Este foi um equipamento de US$ 30 mil com 6 programadores Segger, 6 scanners Keysight, em cima de uma plataforma Teradyne de US$ 100 mil, e foi nosso maior gargalo e maior despesa. Além disso, cada dispositivo da nossa linha de produtos requer acessórios diferentes. A combinação desses acessórios caros e o tempo de ciclo lento estava tornando nosso CPV (Custo dos Produtos Vendidos) insustentável.

Numa linha de montagem, tempo é literalmente dinheiro, pois cada tempo de ciclo de cada operador na linha é medido e adicionado ao custo do produto. Reduzir um ciclo mesmo que por um segundo aumenta rapidamente um volume de milhares. Acima de 10 mil unidades, a redução de 2 segundos equivale a 6 horas de mão de obra, a US$ 15/hora do operador custa US$ 0,01/unidade, e os CMs, especialmente os baseados nos EUA, estão cobrando mais de US$ 15/hora. Ter um tempo de ciclo de 6 minutos para 6 peças estava pronto para melhorias.

A primeira etapa foi mais uma prova de conceito. Poderíamos transferir parte da funcionalidade do equipamento de TIC caro para um equipamento mais barato e mais rápido, para que pudéssemos dimensionar em série em vez de comprar outro equipamento para dimensionar em paralelo?

Para esta etapa implementamos um recurso em nosso firmware que chamamos de autoteste, que é semelhante a uma varredura de limite JTAG. Em vez de colocar pinos pogo em cada rede, colocamos um recurso no firmware para executar um autoteste em tantos componentes quanto possível e relatar os resultados em série. Dessa forma, poderíamos conectar apenas com os pinos de alimentação e UART e obter uma leitura completa e muito rápida do que exatamente falhou. Oito Arduinos conectados por meio de um hub USB a um tablet PC com script e interface Python personalizados foram a solução.

Um único conector IDE de 40 pinos era suficiente para ter energia, um LED RGB, RX, TX e um único botão que iniciaria o ciclo para todos os 8 de uma vez. O Arduino solicitaria um autoteste do DUT (Device Under Test), que testaria seus componentes e reportaria. Os testes incluíram verificar se os sensores estavam lendo valores dentro da faixa esperada, mas também ligar o LED e a campainha e medir a queda de tensão para verificar se as saídas também funcionavam.

Isso funcionou e comprovou o conceito de criar uma caixa com a maior parte da eletrônica combinada com um acessório simples customizado para o painel, mas não foi suficiente. A retirada de alguns dos testes de circuito foi insuficiente para reduzir significativamente o tempo. Precisávamos retirar mais tarefas.