VisionControl e' un sistema di visione artificiale per il controllo qualita' in
linea: acquisisce l'immagine del pezzo sul trigger della macchina, decide entro
il tempo ciclo e comanda lo scarto del pezzo non conforme. Gira on-premise,
dentro il perimetro di fabbrica: le immagini di produzione non escono dallo
stabilimento.
Il differenziale non e' riconoscere il difetto — lo fa qualunque libreria di
visione — ma arrivare in produzione su una linea che gira: acquisizione
sincronizzata, decisione entro il tempo ciclo, scarto automatico e un modello
addestrato sui difetti veri di quel cliente, non su un dataset di laboratorio.
Cosa fa
| Area | A cosa serve |
|---|---|
| Acquisizione da campo | Scatto sincronizzato sul trigger GPIO della macchina, gestione di telecamere singole e di gruppi (griglia, viste multiple, composita) |
| Motore di ispezione | Confronto con il pezzo master, soglie geometriche, esito passa/scarta entro il tempo ciclo |
| Rilevamento anomalie | Modelli addestrati sui difetti reali del cliente (PatchCore, PaDiM, EfficientAd) per i difetti che non si descrivono con una regola |
| Plugin di ispezione | 21 plugin caricati a runtime: si aggiunge un controllo senza toccare il motore |
| Pipeline di scarto | Comando di reject verso la macchina, con backend GPIO reale o simulato per la messa a punto |
| Robustezza alla luce | Bilanciamento del bianco gray-world, CLAHE e aree di interesse, per reggere l'illuminazione ambientale non controllata |
| Ghosting temporale | Sovrapposizione master/acquisizione e mappa di calore dei difetti, per capire dove sta sbagliando la linea |
| Analisi di tendenza e deriva | Rilevamento della deriva sugli esiti con alert automatico via email, soglia per telecamera e cooldown |
| Active learning | L'operatore marca falsi positivi, falsi negativi e casi borderline: il modello si corregge sui difetti della linea reale |
| Import di dati di processo | Excel, CSV e database esterni, per correlare l'esito dell'ispezione con i dati di produzione |
| Tracciabilita' | Registro append-only delle operazioni e storico degli esiti |
Come si mette in linea
- Studio di fattibilita' sui campioni del cliente — si misura la resa sui
pezzi veri prima di impegnarsi, non su immagini di catalogo. - Addestramento del modello sui difetti reali — e' il lavoro che apre i
progetti, ed e' quello che separa una prova riuscita da un impianto che
produce. - Taratura sulla linea — sincronizzazione sul trigger, tempo ciclo,
illuminazione, comando di scarto. - Sorveglianza e ritaratura — i difetti cambiano quando cambia il processo:
il modello va riverificato nel tempo.
Architettura
- Backend: Python 3.11, FastAPI, SQLAlchemy 2 async, Alembic, Pydantic v2.
- Frontend: React 18, Vite, TypeScript, Tailwind, shadcn/ui.
- Elaborazione asincrona: worker Celery per inferenza e import.
- Plugin: moduli Python caricati a runtime dalla cartella dei plugin.
- Dati: PostgreSQL.
Requisiti
- Distribuzione on-premise nello stabilimento; PostgreSQL 14 o superiore.
- Telecamere industriali con trigger disponibile (GPIO), oppure sorgente video
in rete per le configurazioni di sola supervisione. - Per il comando di scarto: I/O digitali verso la macchina. In assenza, il
backend GPIO simulato permette di tarare tutto il resto. - Accesso ai pezzi campione, conformi e difettosi, per l'addestramento del
modello: e' il prerequisito che determina la resa del sistema.