Lettura targhe multi-marca: non rifare l’impianto per cambiare camera.
Perché OCR, liste e UI nello stesso SKU creano lock-in. Come separare telecamere ANPR e software LPR.
In Italia i varchi di lettura targhe si accumulano per bandi, urgenze e cambi di fornitore. Il risultato è un territorio (o uno stabilimento) con tre marche di telecamere ANPR e tre “centrali” che non si parlano. Il vendor lock-in non è un tema ideologico: è il costo di rifare liste, formazione e storico ogni volta che scade un contratto hardware.
Questa pagina spiega come separare i pezzi. Contesto generale: guida ANPR. Glossario: ANPR, OCR, LPR.
Come nasce il lock-in
Il produttore vende:
- la camera che legge;
- il protocollo proprietario del transito;
- il client per liste e ricerca;
- a volte l’app operatori.
Se 2–4 sono chiusi, sostituire 1 significa perdere 3. Gli operatori imparano un’altra UI. I transiti vecchi restano in un silos. Il bando successivo “riparte da zero”.
I siti dei competitor hardware insistono su completezza di catalogo (camera + software). È lecito. Il committente deve decidere se vuole un fornitore totale o uno strato LPR che sopravvive al cambio camera.
Cosa significa “multi-marca” in pratica
Non significa uno stream unico magico. Significa:
- ogni famiglia di camere ha un connettore (HTTP, SDK, file, middleware);
- il software LPR normalizza targa, varco, tempo, qualità, media;
- liste e ricerca vivono sopra i connettori.
La lista dei modelli supportati è un artefatto di collaudo, non uno slogan. Qui non pubblichiamo elenchi tipo “Hikvision, Dahua, Selea, Tattile…” come se fossero tutti già certificati Inquiris. [DA CONFERMARE: matrice di compatibilità ufficiale]. In assessment si testa il payload reale.
ONVIF, RTSP, “la targa nello OSD”
Errori frequenti:
- “È ONVIF, quindi è integrata.” Lo stream non è l’evento ANPR.
- “La targa è scritta in overlay.” L’overlay non è un record ricercabile.
- “Esportiamo CSV dalla camera una volta al giorno.” Non è un allarme in tempo utile.
Serve il transito come dato strutturato, con identificativo varco stabile.
Quando ha senso restare monomarca
- Impianto piccolo, un solo gate, stesso vendor per assistenza illuminatore+OCR.
- Nessuna prospettiva di mixare brand.
- Il gestionale del vendor copre già liste e export che ti bastano.
Fuori da questi casi, il lock-in diventa debito. Vale per Comuni e per accessi industriali.
Cosa chiedere in gara (senza nominare un software)
- Esposizione transiti in formato documentato (o impegno a documentarlo).
- Proprietà dello storico esportabile.
- Possibilità di secondo client in lettura (centrale terza).
- Collaudo su N varchi misti.
Poi valuti se un software di lettura targhe on-prem è lo strato giusto. Assessment: marche in campo, numero canali, obiettivo allarmi vs solo storico.
Come si valuta un connettore (senza una slide)
Chiedi una cattura reale: un transito JSON o un log, non un PDF. Verifica varco, tempo, targa, eventuale media. Chiedi cosa succede in ristarto della camera e in cambio firmware. Chiedi se lo storico nativo è esportabile in massa o solo da UI.
Un integrator serio fa un proof-of-concept su un varco, non una promise su venti. Il PoC deve arrivare fino alla lista e alla ricerca, non fermarsi al “ping ricevuto”.
Il lock-in ha anche un lato organizzazione: gli operatori imparano una UI. Cambiarla ha un costo. Meglio una centrale LPR stabile e camere sostituibili, che camere eterne e tre centrali. È lo stesso ragionamento dei sistemi di accesso badge: il campo si cambia, l’anagrafica no.
In PA il tema è politico oltre che tecnico. Un bando che obbliga un unico brand per dieci anni di varchi crea dipendenza. Un bando che chiede transiti documentati e software di centrale separato lascia concorrenza sul lotto hardware futuro.
Non promettiamo “qualsiasi camera”. Promettiamo un metodo: assessment, test payload, poi canali. La pagina lettura targhe descrive il metodo di prodotto. Questa pagina descrive perché il metodo esiste.
Contratti, firmware e fine vita
Il lock-in si aggrava quando il firmware della camera cambia il payload senza notice, o quando l’SDK è legato a una versione di Windows in sala operativa. Chiedi policy di deprecazione. Tieni una camera di scorta dello stesso lotto per test.
In fine vita hardware, lo strato LPR deve continuare. È il criterio di accettazione: spegni una marca, le altre restano in lista e in ricerca. Se non è vero, non è multi-marca, è un multiplexer temporaneo.
Gli operatori vanno formati sulla centrale, non su dieci app vendor. Il risparmio si vede in tre anni, non in tre settimane di gara al massimo ribasso sul pezzo camera.
Come scrivere il requisito senza chiudere il mercato
Chiedi acquisizione da più marche, normale transito (targa, varco, tempo, qualità), liste e ricerca in un’unica UI, dato on-prem, connettori documentati. Non chiedere “compatibilità universale” senza elenco modelli da collaudare: è un slogan. I modelli si verificano in campo [DA CONFERMARE per ciascun pezzo].
Chiedi cosa succede se spegni una marca. Se spariscono liste e storico, non è multi-marca. È un multiplexer temporaneo. Il collaudo deve includere quel giorno. Poi progettare il varco resta obbligatorio: il software non salva una geometria sbagliata.
Per l’assessment: inventario camere (marca, firmware se noto, protocollo), obiettivo operativo, vincolo di non sostituire tutto. Contact o lettura targhe.
In gara, un requisito multi-marca ben scritto riduce i ricorsi e i “non previsto” in corso d’opera. Allega l’inventario camere e accetta un collaudo su un sottoinsieme rappresentativo, non una dichiarazione universale. Poi estendi. È più lento in offerta, più onesto in esercizio. Il glossario aiuta la commissione a non comprare due volte l’OCR.