Comprovar inspeção automatizada nos seus próprios produtos
Começa com um gate de viabilidade nas suas amostras reais, porque algumas tarefas visuais não são solúveis na velocidade da sua linha, e é mais barato saber isso na primeira semana. O que segue é design de imageamento, dados anotados, um modelo validado e um teste controlado de linha — reportado por classe de defeito, com defeitos perdidos e falsos rejeitados contados separadamente.
Verificar meu caso de uso de visãoFalar com um engenheiro de manufaturaEsse é o problema que você precisa resolver?
- A inspeção visual depende da atenção de uma pessoa no fim de um turno longo.
- O mesmo tipo de defeito continua chegando ao cliente e ninguém consegue dizer com que frequência.
- A inspeção é o motivo pelo qual a linha não pode rodar mais rápido.
- Um projeto de visão anterior foi aceito com base em um número de acurácia e falhou nos defeitos que importavam.
Interlocutor principal: Gerente da qualidade · Gerente de produção · Gerente de automação · Gerente de engenharia · Gerente de planta
O que este PoC vai comprovar
Escopo recomendado do piloto
- Uma estação de inspeção e uma família de produto, incluindo suas variantes reais.
- Um conjunto delimitado e nomeado de classes de defeito ou verificação — não "qualquer defeito".
- Câmera, lente e iluminação selecionadas, escolhidas após a etapa de design de imageamento.
- Um fluxo de rejeição ou confirmação do operador, para que uma decisão leve a uma ação.
- Amostras de treinamento, validação e aceite mantidas estritamente separadas o tempo todo.
O que estará em operação durante o PoC
Como este PoC acontece
As durações são típicas, não garantidas. O que estende o cronograma: dados faltantes ou incompletos, aprovações de segurança e de rede, prazos de entrega de hardware, coleta de amostras, acesso para instalação, o plano de produção, o acesso ao ambiente de testes do ERP e o tempo que a sua equipe precisa para avaliar os resultados.
Nenhuma parada não planejada é prevista. Qualquer janela de instalação ou interrupção controlada é combinada com você antecipadamente e programada em torno da produção.
Como o sucesso será medido
| Indicador | Como é definido | De onde vem o número | Tipo |
|---|---|---|---|
| Precisão por classe de defeito | Das peças sinalizadas para uma classe, a parcela que genuinamente pertence a ela — reportada por classe, nunca diluída em uma única cifra. | Conjunto de validação separado | Técnico |
| Recall por classe de defeito | Das peças que genuinamente apresentam uma classe, a parcela detectada — reportada por classe e por variante de produto. | Conjunto de validação separado | Técnico |
| Taxa de falso aceite | Peças defeituosas aprovadas como boas. Contada e reportada separadamente dos falsos rejeitados, porque seu custo de negócio é completamente diferente. | Conjunto de validação separado | Técnico |
| Taxa de falso rejeitado | Peças boas rejeitadas. O número que decide se os operadores vão manter o sistema ligado. | Conjunto de validação separado | Operacional |
| Matriz de confusão e contagem de amostras | Matriz completa classe a classe com o número de amostras por classe, para que o leitor julgue quanto vale o resultado. | Conjunto de validação separado | Técnico |
| Latência de processamento e conformidade com velocidade de linha | Tempo de inspeção por peça contra o tempo de ciclo disponível, medido na linha em vez de em uma estação de trabalho. | Dados da plataforma MSF | Técnico |
| Taxa de classificação incerta | Parcela das peças que o modelo não conseguiu decidir com confiança, o que o fluxo de confirmação do operador precisa absorver. | Conjunto de validação separado | Operacional |
| Disponibilidade e comportamento de confirmação do operador | Disponibilidade do sistema durante o teste de linha, e como os operadores de fato trataram confirmações e sobreposições. | Dados da plataforma MSF | Adoção |
Antes da implementação, a MSF e a sua equipe acordam como cada indicador é calculado, de onde vem a linha de base, quais dados ficam de fora e qual resultado sustenta uma decisão de rollout. Esta página lista o que será medido; as metas concretas ficam no escopo escrito do PoC, não em uma promessa de marketing.
O que você fornece
- Peças ou imagens OK e NOK representativas, cobrindo toda variante e toda classe de defeito no escopo.
- Definições de defeito, regras de severidade e os níveis aceitáveis de falso aceite e falso rejeitado.
- Tempo de ciclo, velocidade de linha, campo de visão e as condições ambientais na estação.
- Detalhes da interface de CLP ou rejeição e qualquer requisito de rastreabilidade.
Quem faz o quê
A Meta Smart Factory fornece
- Workshop de descoberta e facilitação da definição de escopo
- Configuração da solução para o escopo acordado
- Trabalho de integração e conexão dentro desse escopo
- Hardware MSF listado na proposta
- Treinamento dos usuários do piloto
- As definições de KPI e o método de validação
- Acompanhamento de ocorrências e suporte durante o piloto
- O relatório final de resultados e o desenho do rollout
- O veredito de viabilidade, design de imageamento e uma versão de modelo validada com sua avaliação reproduzível.
- Exemplos de falha — as imagens em que ele errou — em vez de só as que acertou.
Você fornece
- Um responsável de negócio e um responsável técnico nomeados
- Acesso no tempo certo a usuários, linha, máquinas e sistemas autorizados
- Uma explicação fiel do processo e do cadastro mestre
- Acesso de rede, energia, montagem e segurança do trabalho
- Documentação de ERP, CLP e fornecedores, e os especialistas que a conhecem
- Amostras representativas ou dados históricos
- A validação de que a linha de base é justa
- Retorno e a decisão de aceite
- Amostras NOK genuínas suficientes por classe; defeitos raros são os mais difíceis e os mais importantes de fornecer.
- Acesso à linha para o teste controlado na velocidade normal de produção.
Definido na proposta escrita
- Painéis PC, tablets, servidores e servidores com GPU
- Câmeras, lentes, iluminação e gabinetes
- Leitores, impressoras, dispositivos RFID, medidores e sensores
- Viagem, instalação, frete, impostos de importação e serviços elétricos locais
- Se o hardware é alugado ou comprado
- Se o valor do PoC é abatido de um rollout
Condições comerciais, propriedade do hardware, viagens, escopo de integração e qualquer abatimento no rollout são definidos na proposta escrita do PoC. Não são iguais para todos os produtos e esta página não os promete.
O que você recebe no final
- Veredito de viabilidade com o raciocínio por trás.
- Design de imageamento e iluminação validado em peças reais.
- Uma versão de modelo validada com uma avaliação reproduzível.
- Relatório de métricas por classe de defeito, com exemplos de falha incluídos.
- Lista de risco e limitação cobrindo as condições que degradam o resultado.
- Lista de materiais de hardware, arquitetura de integração e recomendação de rollout.
Dependências, exclusões e limites
Este PoC depende de
- Amostras NOK genuínas suficientes por classe — a causa mais comum de atraso em um PoC de visão.
- Apresentação estável da peça na estação, ou um dispositivo combinado para alcançar isso.
Não incluído neste PoC
- Classes de defeito não nomeadas no escopo, e variantes de produto não representadas nas amostras.
- Manuseio mecânico, fixação e construção do mecanismo de rejeição.
Acurácia geral nunca é usada como a métrica de aceite — em um conjunto de defeitos desbalanceado, ela pode parecer excelente enquanto perde todo defeito que importa. Resultados são reportados por classe com contagens de amostra, e nenhuma alegação é feita para tipos de defeito, variantes ou condições que não estavam no conjunto validado.
Seguir, ajustar ou parar: o ponto de decisão
Perguntas frequentes
Quantas peças de amostra vocês precisam?
Depende de quão variável é o defeito e o produto, e o gate de viabilidade dá um número específico para o seu caso. Como regra, a restrição não são peças OK — essas estão em todo lugar — mas exemplos NOK genuínos por classe, especialmente os defeitos raros que são todo o motivo do projeto.
Por que não simplesmente reportar acurácia?
Porque em uma linha que produz 2% de defeitos, um modelo que aprova tudo marca 98% de acurácia e não pega nada. Precisão e recall por classe, mais falsos aceitos e falsos rejeitados separadamente, são os únicos números que descrevem o que realmente vai acontecer na sua linha.
E se o gate de viabilidade disser não?
Vocês recebem o raciocínio, a evidência de imageamento e, onde existir, uma alternativa — um ponto de inspeção diferente, uma geometria de iluminação diferente, ou uma checagem baseada em sensor em vez de visual. Um não claro na primeira semana é um bom resultado comparado a uma célula que falha no nono mês.
Vai funcionar com novos tipos de defeito depois?
Não automaticamente, e isso está declarado na lista de limitações em vez de omitido. Um modelo detecta o que foi treinado e validado para detectar. Novas classes de defeito precisam de novas amostras, retreinamento e uma nova validação — o que é uma atividade normal e planejável, mas não é de graça.
Produtos e programas de PoC relacionados
Solicitar este Proof of Concept
Conte o escopo que você tem em mente e retornamos com um plano de PoC por escrito: o que será conectado, o que você fornece, como o sucesso é medido e como será a decisão no final.