Il sistema di catalogazione delle immagini

Nel precedente censimento ciascun blocco di verifica dei dati e immagini veniva consegnato dal fornitore del servizio in maniera sincrona tramite la spedizione di supporti magnetici. Il processo permetteva di circoscrivere alla singola fornitura la fase di controllo della qualità e imponeva altresì all’Istituto una più complessa gestione di conservazione off-line dei supporti fisici ed un aggravio di tempi nelle fasi di caricamento sui server locali dei Dvd consegnati.

L’architettura informatica approntata nell’ultimo censimento ha permesso di eliminare i supporti fisici mediante l’acquisizione on line delle informazioni presenti sui modelli (dati) e delle immagini output del processo di scansione. Il trasferimento dei pacchetti zip (immagini in formato multitiff ed i metadati in formato xml) è avvenuto tramite Vpn su una Nas (Network Attached Storage) dedicata di 40 terabyte.

Tale modello di trasferimento asincrono tra dati e immagini dello stesso blocco, ha così imposto di progettare un sistema di catalogazione delle immagini ad hoc. Il database del catalogo delle immagini ha quindi fornito informazioni e servizi indispensabili per tutto il processo di controllo di qualità.

Gli utilizzi principali di tale sistema di catalogazione sono:

 la verifica in tempo reale della qualità delle immagini fornite (ad esempio pagine mancanti all’interno di questionari);

 il controllo dei metadati a corredo delle immagini fornite;

 il processo di “versioning” dei file forniti nelle successive fasi di acquisizione;

 la verifica preliminare del numero di immagini ancora mancanti al momento della consegna dei blocchi di dati;

 la selezione delle immagini oggetto di verifica campionaria dei blocchi mediante il sistema “All-In-One”;

 l’individuazione delle immagini per la successiva fase di controllo interattivo effettuata con l’applicazione Corinto nell’ambito della successiva fase di controllo e correzione dei dati;

 la memorizzazione delle informazioni utili per la contabilizzazione delle immagini scansionate ai fini del pagamento del servizio al fornitore;



Il veicolo di trasmissione è composto da file di formato zip. Al loro interno la struttura prevedeva un file di metadati in formato xml, contenente la provenienza territoriale dei questionari allegati. Per ciascun file immagine in formato multitiff, rappresentante una lista, un questionario o parte di esso, veniva sempre allegato un file di metadati in formato xml contenente le informazioni utili a corredo della fornitura (ad esempio ID_Pacco, ID_Distinta, Codice_Comune, dati anagrafici del compilatore, ecc).

Il sistema prevedeva due distinte fasi di lavorazione definite come catalogazione e verifica delle immagini. La prima fase, la catalogazione dei pacchetti zip depositati in un’area di scambio, memorizzava nel database Oracle di Samor-Cqc tutte le informazioni necessarie al controllo del processo di acquisizione dell’ultima fornitura delle immagini (versioning). I principali controlli eseguiti in questa fase riguardavano:

 la presenza dell’identificativo provincia tra i metadati del file zip;  l’effettiva presenza del file immagine indicato nella lista;

 la presenza tra i metadati dei campi chiave tra cui ID_Questionario, Tipo_Questionario, Tipo_Questionario_Short, ID_Pacco, ID_Quest_Comune e ID_Distinta;

 il controllo che la dimensione dell’immagine sia diversa da zero byte;

 la verifica formale degli identificativi dei questionari in termini di lunghezza e presenza di caratteri non numerici;

 la verifica della coerenza del numero pagine del file multitiff con il tipo di modello di rilevazione corrispondente.

La verifica dei file immagine, processo molto più oneroso in termini elaborativi, analizza la presenza di anomalie all'interno dei singoli multitiff. I principali controlli eseguiti per ogni pagina dei file sono:

 la verifica della presenza di pagine bianche;

 la verifica della risoluzione minima di 300 Dpi dell’immagine;

 la scansione dei barcode della pagina al fine di verificare la corrispondenza biunivoca tra codice questionario e singola pagina inserita nel corrispondente multitiff.

Entrambi i processi memorizzavano nella corrispondente tabella del catalogo delle immagini le informazioni di sintesi per l'individuazione dei problemi. Mediante due tabelle analitiche di log venivano memorizzate le anomalie e le segnalazioni riscontrate. Tali informazioni erano disponibili in qualsiasi momento alla verifica puntuale da parte di operatori preposti al controllo.

La schedulazione dei processi, per tutto il periodo della fornitura, ha coinvolto contemporaneamente tre server. Il primo attivava il processo di catalogazione alle ore 8 e alle ore 20. Il secondo forniva supporto al primo, eseguendo un processo suppletivo di catalogazione alle ore 3 qualora il primo non avesse terminato la lavorazione dei nuovi arrivi iniziati alle ore 20; inoltre eseguiva il processo di verifica alle ore 21 ovvero una ora dopo l’avvio del processo di catalogazione avviato nello stesso giorno dal primo server. Il terzo server, impiegato solo nei periodi di picco delle forniture, supportava i primi due, eseguendo il processo di catalogazione alle ore 12 e 24 e la verifica alle ore 3. Inoltre è stato utilizzato un cluster di dodici personal computer in rete nei periodi in cui la fornitura ha toccato i picchi massimi di trasferimento immagini.

La scelta degli orari è stata dettata da una filosofia di ottimizzazione della componente hardware nelle ore di chiusura degli uffici. Gli stessi server durante il giorno venivano usati massicciamente per le attività di controllo di qualità campionaria con la procedura “All-In-One”.

Al fine di migliorare la qualità della fornitura, quotidianamente (alle ore 7) veniva eseguita una export del contenuto delle tabelle Oracle del catalogo, che veniva depositato in una specifica area, accessibile all’azienda fornitrice del servizio, come strumento di controllo alla produzione.

7.4.1 Il sistema di controllo dell’injection sul Sistema Gestione Immagini

La fase di caricamento, definita injection, sul Sistema Gestione Immagini è stata eseguita dall’azienda fornitrice attingendo ai file memorizzati nel repository di 40 terabyte e mediante la consultazione delle informazioni presenti nel sistema di catalogazione delle immagini.

Tale prima fase di caricamento ha impiegato circa due mesi e mezzo per il completo espletamento ed è avvenuta dopo complesse fasi di consultazione tra Istat e azienda fornitrice del servizio per le verifiche tra i contenuti presenti nel catalogo delle immagini ed i report provinciali del fornitore relativi al caricamento delle 109 province (Bolzano escluso), sul un totale di quasi 43 milioni di multitiff, recuperando gli eventuali file ancora mancanti e aggiornando per alcuni di essi i metadati mancanti. Inizialmente si prevedeva una verifica campionaria comparativa dei multitiff a video come avvenuto con la progettazione della procedura definita All-In-One, come descritta per il controllo della qualità della registrazione dei dati. Date le difficoltà nell’operabilità di questa modalità, si sono cercate soluzioni migliori in termini di praticità ed efficienza.

Nell’informatica forense, gli algoritmi di hash, in particolare Sha1 e Md5, sono largamente utilizzati per validare e in qualche modo firmare digitalmente i dati acquisiti, tipicamente le copie forensi. La recente legislazione impone infatti una catena di custodia che permetta di preservare i reperti informatici da eventuali modifiche successive all'acquisizione: tramite i codici hash è possibile in ogni momento verificare che quanto repertato sia rimasto immutato nel tempo. Se i codici hash corrispondono, entrambe le parti in un procedimento giudiziario hanno la certezza di poter lavorare sulla stessa versione dei reperti, garantendo quindi un’uniformità di analisi e in genere di risultati. I risultati dei codici hash sono ormai calcolati di default dalla maggioranza dei software per acquisizione forense e allegati alle copie forensi salvate.

Con lo stesso principio, le versioni originali dei multitiff presenti all’interno dei file zip nel file system dei 40 terabyte associati al sistema di catalogazione delle immagini, sono stati la fonte della copia certificata presente all’interno del Sistema Gestione Immagini.

Sono state sviluppate due distinte applicazioni software. La prima che calcolava il valore del Md5 di tutti i multitiff presenti all’interno degli zip nei 40 terabyte, memorizzando il codice hash all’interno di una tabella del database di Samor-Cqc. La seconda che come parametro di input aveva il path di una cartella presente sul secondo file system a nostra disposizione di complessivi 5 terabyte, che è stato utilizzato per l’estrazione massiva dei multitiff dal Sistema Gestione Immagini tramite l’applicativo Documentum. Il software calcolava il valore del Md5 dei file presenti nella cartella specificata e lo memorizzava in corrispondenza dell’istanza relativa al nome del file trattato su un’altratabella dello stesso database.

L’aspetto innovativo del processo è l’assoluta certezza della verifica, l’impossibilità dell’errore umano, l’estrema velocità di esecuzione rispetto al controllo visivo e la possibilità di giungere alla verifica esaustiva dei quasi 43 milioni di file.