Lettura targhe ANPR: dalla telecamera alla centrale.

Chi cerca lettura targhe ANPR di solito non vuole un acronimo: vuole sapere se i varchi del Comune, dello stabilimento o del porto possono allarmare, autorizzare e ritrovare un veicolo tre giorni dopo. Questa guida parte da lì. Prima il flusso operativo, poi il ruolo del software LPR, poi i vincoli (multi-marca, on-prem, privacy). Nessuna percentuale di accuratezza e nessuna certificazione non documentata: dove manca una fonte trovi [DA CONFERMARE].

Cosa fa un impianto di lettura targhe

Un impianto utile è una catena, non un oggetto.

1. Ripresa — la scena del varco (corsia, velocità, luce, sporco sulla targa).
2. OCR / ANPR — estrazione della stringa targa, spesso a bordo camera o su appliance.
3. Transito — record con orario, varco, targa, eventuale crop e contesto.
4. Politica — liste, regole, aperture sbarra, allarmi verso operatori.
5. Ricerca e verifica — storico interrogabile, export controllato, audit di chi ha guardato cosa.

Se ti fermi al punto 2 hai “una targa in un log della camera”. Se ti serve Polizia Locale, facility o logistica, ti servono i punti 4 e 5. È lo stesso motivo per cui i competitor parlano di gestione portali, liste e app operatori: il valore sta dopo l’OCR.

Per il vocabolario (ANPR, OCR, LPR) leggi telecamere ANPR, OCR e LPR: le differenze. Per il cantiere, come progettare un varco.

Dove falliscono i progetti

I fallimenti ricorrenti non sono “l’algoritmo”. Sono di processo.

• Geometria sbagliata: contraluce, targa troppo piccola nel frame, IR assente di notte. Nessun software ripara un varco cieco.
• Un solo fornitore hardware che porta via anche il gestionale: cambi camera e perdi storico e liste. Vedi multi-marca e vendor lock-in.
• Allarmi senza destinatario: la watchlist esiste ma nessuno è di turno, o arriva solo una mail non letta.
• Storico non ricercabile: i transiti stanno in file sulla NVR e l’operatore non filtra per fascia oraria e varco.
• Privacy a posteriori: si accende l’impianto e poi si chiede al DPO i tempi di conservazione. Ordine inverso. Per l’inquadramento, lettura targhe, GDPR e DPIA.

Software LPR: cosa deve fare (minimo)

Un software LPR (lo strato di lettura targhe lato applicazione) dovrebbe, in sintesi:

• Acquisire transiti da più marche di telecamere o da gateway standard (protocolli e mapping: [DA CONFERMARE] per ogni modello).
• Normalizzare targa, varco, timestamp, qualità OCR, eventuale immagine.
• Liste e allarmi: white/black/watch, notifiche a centrale o app operatori.
• Ricerca: targa, intervallo, varco, e — se disponibile — marca/modello/colore.
• Accessi e audit: chi entra nel sistema, chi esporta, MFA se richiesto dalla PA.
• On-prem: il dato resta nell’infrastruttura del titolare, utile a PA e a chi non vuole cloud fuori perimetro.

Non deve spacciare l’OCR della camera per “intelligenza di centrale”. Non deve inventare collegamenti a banche dati nazionali se non sono in perimetro e contratti. Inquiris, in questa sede, si presenta come piattaforma di acquisizione, allarme e ricerca — non come sostituto di SCNTT, IVASS o analoghi [DA CONFERMARE: nessun collegamento dichiarato].

Multi-marca: perché conta in Italia

Il parco installato è eterogeneo: Selea, Tattile e altri brand convivono sullo stesso territorio. Un capitolato “tutto nuovo” è raro. Il requisito reale è: tenere i varchi che già leggono e dare a operatori un solo posto dove cercare e allarmare.

Il lock-in nasce quando OCR, liste e UI sono lo stesso SKU. Separare camera e software LPR è la mossa architetturale. Non è gratis: servono connettori, collaudo, gestione dei formati targa. Ma è la differenza tra un upgrade e una sostituzione totale.

Allarmi, accessi, indagini, logistica

Quattro obiettivi, quattro disegni.

• Allarmi — watchlist, tempi di reazione, canale (centrale, mobile). Vedi anche sicurezza urbana e PA.
• Accessi — white list, sbarra, fallback umano. Controllo accessi veicolari.
• Indagini / verifica — ricerca sullo storico, freeze, catena di consultazione.
• Logistica / parcheggi — coda, match prenotazione, gate merci. Parcheggi e porti e logistica.

Non comprimere tutto in un’unica “smart city box”. Il software può essere lo stesso; le regole e i tempi di vita del dato no.

AI veicolo: oltre la sola targa

Classificazione marca, modello e colore serve quando la targa è parziale, l’OCR sbaglia o l’operatore ha una descrizione. Non è una prova autonoma e non pubblichiamo accuracy. Dettaglio in ricerca veicoli marca modello colore.

On-prem, MFA, audit

Per la Pubblica Amministrazione il modello on-prem, i controlli di accesso e gli audit sono requisiti di conversazione, non slogan. Documentazione di conformità a supporto del DPO: da costruire sul caso, non copiata da una landing. Strumenti software (log, ruoli, retention configurabile) aiutano; non sostituiscono la DPIA.

Checklist prima di un assessment

Porta in riunione:

• elenco varchi e corsie;
• marca e modello camera (se già in campo);
• obiettivo prevalente (allarmi, accessi, indagini, logistica);
• chi riceve l’allarme e in che orari;
• vincoli di rete e di dove può stare il server;
• bozza tempi di conservazione (anche se ancora da validare col DPO).

Da lì si discute architettura, licenza canali e piano di deploy. La pagina prodotto è lettura targhe. Per una consulenza: racconta varchi e obiettivo, non “vorrei l’AI”.

Cosa non promette questa guida

• Accuratezza OCR in percentuale.
• Compatibilità universale con “tutte le camere del mercato” senza test.
• Integrazioni ministeriali o CDS non elencate.
• Referenze su numero di Comuni o telecamere installate.

Quelle cifre, se arriveranno, avranno fonte. Fino ad allora restano fuori dal testo.

Dal capitolato al collaudo: una sequenza realistica

Il percorso tipico di un ente o di un’azienda non inizia dal software. Inizia da un problema: code al gate, un’indagine che non trova il transito, una watchlist che vive in un foglio Excel, tre marche di camera e tre password. Il capitolato arriva dopo, spesso copiato da un bando vicino, e mescola ANPR, videosorveglianza generale e “intelligenza artificiale” senza dire chi allarma e chi conserva.

Una sequenza sana è questa. Primo: elenco varchi e finalità (allarme, accesso, ricerca, logistica). Secondo: verifica geometria e qualità OCR sul campo, di giorno e di notte. Terzo: decisione su dove vive il transito strutturato (camera, NVR, software LPR). Quarto: ruoli, MFA, retention — con il DPO in copia, non in calce. Quinto: collaudo con transiti noti, non con una demo da salone.

Il software LPR on-prem entra tra il terzo e il quinto passo. Non sostituisce il palo, non firma la DPIA, non “certifica” l’impianto. Centralizza ciò che i varchi già sanno fare e lo rende usabile da operatori che non vogliono entrare in dieci interfacce proprietarie.

Se stai scrivendo un capitolato, distingui i lotti: opere civili e pali; telecamere e illuminatori; rete; piattaforma di lettura targhe; formazione. Chi vince il lotto camera non dovrebbe, per default, vincere anche lo storico dei prossimi dieci anni. Questa è la lezione del vendor lock-in, ed è la ragione per cui Inquiris si presenta come strato applicativo.

Infine: forma gli operatori sul caso reale (liste del tuo ente, varchi del tuo territorio), non su un dataset di marketing. Un allarme ignorato è uguale a un allarme inesistente. La tecnologia, in quel punto, ha già fatto il suo.

Chi arriva da un bando già scritto sul modello “camera più software dello stesso marchio” può comunque aprire un lotto software a parte in variante, se il disciplinare lo consente. Altrimenti il lock-in è una scelta di gara, non un destino tecnico. Inquiris resta valutabile quando il requisito è centrale multi-marca on-prem, non quando il lotto è un bundle chiuso. Porta il testo di gara in assessment: a volte basta un chiarimento, a volte no.