- 1 -

UNIVERSITA' DEGLI STUDI DI TRENTO

Facoltà di Scienze Matematiche, Fisiche e Naturali CORSO DI LAUREA IN INFORMATICA

ELABORATO FINALE

Descrizione del sistema informativo dei Vigili del Fuoco

della Provincia Autonoma di Trento

Relatore: Laureanda: Prof. Marco Aiello Francesca Rossi

ANNO ACCADEMICO 2003–2004

- 2 -

Indice

1. Introduzione pag. 04

2. Architettura del Sistema pag. 08

2.1 Componenti Software pag. 10

2.1.1 Interfaccia Web pag. 10

2.1.2 Interfacciamento locale pag. 11

2.1.3 Autenticazione pag. 12

2.1.4 Il primo livello: Server Citrix pag. 13

2.1.5 il secondo livello: Macchina MTS pag. 14

2.1.6 Database pag. 15

2.1.7 Il sistema Cartografico pag. 19

3. Il sistema Informativo dei Vigili del Fuoco pag. 23

3.1 Requisiti pag. 23

3.2 Utenti del Sistema pag. 24

3.3 Accenno al linguaggio di sviluppo: Visual Basic pag. 26 3.4 Struttura del Sistema pag. 27

3.4.1 L’interfaccia pag. 27

3.4.2 Componente sviluppato: Ricerca dei dati pag. 33

4. Stato dell’arte pag. 40

4.1 Soluzione ZEROgis On Line pag. 40

4.2 Soluzioni SIRIO pag. 42

4.3 Considerazioni e confronti pag. 43

4.4 Discussione pag. 44

5. Conclusioni pag. 46

- 3 -

Appendice: I Vigili del Fuoco. pag. 48

La Struttura pag. 48

Le competenze pag. 50

Le Attrezzature pag. 51

Gli Interventi pag. 52

- 4 -

Capitolo 1

Introduzione

Ogni qualvolta viene richiesto un intervento a Vigili del Fuoco o altre Corpi

della Protezione Civile questi sono chiamati ad operare con le loro attività

specialistiche mirate a far fronte alla chiamata di allertamento. Tutto è generalmente

coordinato da una struttura centrale localizzata in una “sala operativa”, dove si ha la

necessità immediata di individuare quali siano i singoli interventi da porre in essere

per far fronte all'evento che si è verificato, quali uomini, risorse e mezzi mettere in

campo per meglio ottimizzare le operazioni di soccorso e coordinarle sul territorio,

soprattutto quando la crisi è distribuita e comprende più giurisdizioni.

In questo tipo di interventi risulta rilevante riuscire a individuare l’entità dello

stato di crisi, recuperare il maggior numero di informazioni in merito utilizzando

regole e meccanismi predefiniti per meglio accedere ad una varietà di risorse

dislocate in posti diversi e provenienti da fonti eterogenee. Queste devono essere

facilmente reperite, verificate e utilizzate. Nel contempo è necessario generare per

ogni evento e in tempo reale, idonea documentazione che registri l’andamento della

situazione in atto, al fine di avere visione di quello che accade momento per

momento per poter prendere successive decisioni operative [07].

Le nuove tecnologie ed i sistemi informativi attuali possono dare un

contributo rilevante alla risoluzione di queste problematiche. Possono essere creati

diversi sistemi informativi con varie funzioni, ma tutte aventi lo scopo di fornire e

facilitare la condivisione di informazioni tra le squadre operative impiegate

sull’intervento. L’obiettivo è quello di agevolare il più possibile le operazioni di

soccorso costruendo un supporto professionale agli organismi interessati, al fine di

individuare tutte le risorse necessarie nel più breve tempo possibile, in modo sicuro

ed efficiente e considerando tutti i delicati fattori che potrebbero incidere

- 5 -

negativamente sulle operazioni di risoluzione dell’evento.

Esistono diversi metodi per raggiungere questi obiettivi. Applicazioni di

simulazione e sistemi di supporto che forniscono informazioni di tipo cartografico e

geografico possono essere usate per riprodurre in modo realistico tipiche situazioni di

eventi pericolosi permettendo di studiare a tavolino piani di intervento preventivi,

nonché verificarne la loro effettiva efficacia basandosi sulle esperienze precedenti.

Un altro importante esempio di funzionalità utile durante le operazioni di

soccorso è quello di dare la possibilità alle squadre locali e alle squadre dislocate in

altri siti di aggiornare contemporaneamente le informazioni relative allo stato della

crisi in atto. Una soluzione può essere quella di un sistema in grado di registrare e

visualizzare tutti i cambiamenti in tempo reale permettendo sia agli utilizzatori che ai

coordinatori dell’evento la consultazione dei dati in merito, sviluppando

un’applicazione che dinamicamente si corregge e si aggiorna in continuo sia sui dati

che sulle operazioni da porre in essere. Un database ben organizzato e chiaro da

leggere nel tempo, mantenendo una registrazione storica, diviene un’indispensabile

documentazione su cui basarsi per prendere iniziative in nuove e simili situazioni di

crisi.

In questo campo sono state avviate negli ultimi decenni molte ricerche per lo

sviluppo di sistemi di supporto in merito alla gestione delle emergenze. Impiegando

quindi le migliori tecnologie informatiche esistenti ed integrandole con il software

allo stato dell’arte, si ha la possibilità di ottenere risultati anni fa impensabili

migliorando in misura notevole gli standard di efficienza ed efficacia nella

risoluzione degli interventi e al contempo impiegando al meglio le risorse umane e le

attrezzature nella loro massima funzionalità.

Nella presente tesi viene appunto studiata e sviluppata un’applicazione di

supporto all’opera professionale dei Vigili del Fuoco della Provincia di Trento.

Viene descritto il sistema informativo realizzato per le operazioni decisionali

e di coordinamento degli interventi effettuati dai Vigili del Fuoco Permanenti e

Volontari. Vengono altresì individuati i problemi di integrazione del sistema

informativo con altri sistemi informatici, le caratteristiche a cui deve rispondere

l’applicazione per incontrare le esigenze concrete sia del personale responsabile del

coordinamento sia degli utenti finali ai quali deve esser data una soluzione semplice

- 6 -

ed atta ad ottimizzare i tempi delle operazioni di intervento in particolare nelle fasi

concitate iniziali. Il sistema informativo deve inoltre essere un supporto al fine di

determinare gli organi di competenza, l’individuazione del personale qualificato e

responsabile necessario, l’invio delle relative chiamate, la memorizzazione precisa e

puntuale delle “partenze” e cioè dei mezzi e delle squadre impiegate, ed infine

acquisire e fornire il maggior numero di informazioni cartografiche e gestionali

necessarie alla gestione dell’emergenza.

Nel secondo capitolo vengono descritti i problemi riscontrati nell’analisi

iniziale nella ricerca di soluzioni e prodotti elettronici che permettano di abbreviare i

tempi di elaborazione e di gestione della grossa mole di dati necessari nonché di un

numero variabile e crescente di utenti. L’applicazione permette infatti, anche al di

fuori dei momenti dell’emergenza, di aggiornare ed inserire nuove informazioni

anagrafiche e di supporto direttamente da parte degli enti di soccorso utilizzatori del

sistema. Tenendo conto del notevole numero dei Vigili del Fuoco Volontari della

Provincia di Trento (circa 6000) e delle relative informazioni necessarie si devono

quindi adeguare le strutture di memorizzazione dei dati in modo che esse siano

pronte ad una gestione di quantità crescente di elementi. L’applicazione è utilizzata

anche da locazioni remote. Quindi più utenti, di numero variabile a seconda

dell’emergenza e che utilizzano supporti informatici differenti per il collegamento

devono poter esser interconnessi senza problemi, attraverso un sistema che permette

di interagire e uniformare tecnologie diverse tutte connesse al sistema centrale.

Nel terzo capitolo viene illustrata l’applicazione in se stessa, sviluppata dopo

un’attenta analisi dei reali bisogni e problematiche rilevati con interviste dirette al

personale operante all’interno della struttura dei Vigili del Fuoco. Particolare cura è

stata impiegata per individuare le reali informazioni necessarie, calandosi nelle

specifiche e concrete esigenze operative del personale variamente impiegato: dal

personale nella centrale radio-telefonica al personale direttamente operativo negli

interventi. Di conseguenza l’applicazione è stata studiata tenendo conto di specifiche

funzionalità miranti ad ottenere un effettivo vantaggio operativo al personale

impiegato.

Il quarto capitolo mostra lo stato dell’arte sull’argomento dei sistemi

informativi sviluppati per la Protezione Civile, esempi di altre possibili soluzioni

- 7 -

esistenti sul mercato che assomigliano per funzionalità all’applicazione da noi

proposta. Questo confronto è risultato utile ad individuare i migliori metodi di

soluzione e gestione informatica dei vari tipi di emergenze, nonché per affinarne la

realizzazione pratica operativa.

Il presente elaborato intende mostrare e sottolineare l’importanza crescente

che ha acquisito questa applicazione all’interno della struttura dei Vigili del Fuoco di

Trento nella quale ha assunto ormai il carattere di strumento indispensabile.

L’applicazione infatti è nata da un attento lavoro di progettazione con l’intento di

attenersi scrupolosamente alle reali necessità professionali e l’obiettivo di ottenere

come risultato un’applicazione che si dimostrasse sul campo, così come si è in effetti

dimostrata, uno strumento di facile utilizzo e realmente utile nel lavoro quotidiano di

prevenzione e soccorso.

- 8 -

Capitolo 2

Architettura del sistema

È necessaria un’attenta analisi delle caratteristiche hardware su cui si basa il

sistema informativo, per comprendere successivamente i migliori componenti

software per lo sviluppo dell’applicazione.

Il sistema informativo dei Vigili del Fuoco della Provincia di Trento si basa

su un’architettura Client/Server a tre livelli. Dall’analisi del sistema esistente e

considerando i risultati da conseguire riusciamo a rilevare alcune caratteristiche

specifiche che devono essere soddisfatte. Requisiti fondamentali sono:

• Strumenti per la gestione del carico del Server, il monitoraggio dell’uso delle

risorse, l’automazione in termini di installazione dell’applicazione.

• Un’architettura che permetta la manutenzione centralizzata, la gestione e il

controllo del sistema senza necessità di intervenire nelle stazioni periferiche

distribuite sul territorio provinciale.

• Un sistema che permettesse di lavorare all’interno di ambienti eterogenei,

fornendo l’accesso ad applicazioni indipendentemente dal tipo di Client, dalla

tipologia di rete o protocollo.

• Un sistema con un buon livello di prestazioni in velocità e la possibilità di

gestire un numero di utenti relativamente elevato, ma senza compromettere la

trasmissione ed elaborazione veloce dei dati.

• Un’architettura e l’utilizzo di strumenti che permetta la suddivisione di carico

di elaborazione e che dia la possibilità di gestione degli utenti, permettendo il

riconoscimento di questi e applicando ad ognuno ‘policy’ diverse di accesso

ai dati.

- 9 -

Figura 2.1 Schema Architettura del Sistema

Nella figura precedente (Figura n. 2.1) viene mostrata l’architettura realizzata.

Tale sistema si compone principalmente di: 1. Componenti Hardware

- 3 Server (controllo accessi, gestione applicazione, elaborazioni)

- 2 Database (gestione dati generali, gestione cartografia) 2. Componenti Software

- un’interfaccia web per il collegamento in remoto da parte dell’utente

- un sistema Client per l’interfacciamento in locale dell’utente

- applicazione per il controllo del dominio

- Sistema Server per la pubblicazione di applicazioni e per la suddivisione del

carico di lavoro degli utenti

- 10 -

- una macchina per la gestione delle transazioni

- un sistema di database per la memorizzazione ed elaborazione dei dati

2.1 Componenti software

2.1.1 Interfaccia Web

È risultato indispensabile permettere ai Client periferici un facile accesso

all’applicazione eseguita sul Server, questo è risolto utilizzando come collegamento

un comune browser.

Il collegamento in remoto dell’utente avviene attraverso un’interfaccia web

che per mezzo di un collegamento HTTPs si collega al Server per il controllo del

dominio dove l’utente viene autenticato. La pagina iniziale è memorizzata sul Server

Web presente sulla stessa macchina per la gestione degli accessi al sistema ed è

indirizzato dal Firewall al momento del collegamento dell’utente. Una volta avvenuta

la connessione al Server Web questo si aggancia al Server Citrix Metaframe,

macchina che si occupa della gestione delle operazioni per l’avvio di applicazioni. La

prima volta che un qualsiasi utente si collega, si autentica e accede alla pagina web,

automaticamente scarica e installa (se già non è installato) un ActiveX Control nella

periferica Client, il download viene avviato da un’applicazione Java che verifica

prima se già esiste il componente all’interno del sistema Client.

L’ActiveX Control scaricato è un componente software nel quale sono

contenuti metodi che permettono la comunicazione attraverso il protocollo ICA . Il

protocollo ICA è uno standard di comunicazione del Server Citrix Metaframe per la

distribuzione delle applicazioni. Tale protocollo supporta vari tipi di connessione, è

sicuro e utilizza una banda trasmissiva limitata. Lo standard ICA permette di

condividere le risorse del Client (dischi, stampanti, porte di comunicazione), in modo

trasparente, come se fossero fisicamente connesse al server [05].

La configurazione dei parametri per la comunicazione inizia quando, avviata

l’applicazione, viene spedito un particolare file ICA generato dopo un analisi del

sistema Client. Un ICA file è un file di testo in formato .ICA che contiene i parametri

- 11 -

per la definizione di una connessione a un specifico Server Citrix Metaframe XP o a

un’applicazione pubblicata contenuta in esso, inviato questo file può avere inizio la

sessione Server-Client. Trasferendo questo particolare file vengono inviate

informazioni relative all’indirizzo IP/Porta della macchina connessa, ai dati di

autenticazione dell’utente e all’applicazione da avviare.

Tutto questo viene fatto in modo trasparente all’utente. Una volta connesso il

Client potrà utilizzare l’applicazioni pubblicate semplicemente selezionandola.

2.1.2 Interfacciamento locale

Per le macchine che utilizzano l’applicazione giornalmente, quindi quelle

installate nei locali della sede dei Vigili del Fuoco, non viene utilizzato un

interfacciamento tramite web, ma viene usata direttamente la rete locale. Questo è

permesso grazie a una relazione di fiducia tra i due Server per la gestione dei domini

in locale e remoto. L’utente locale si autentica al Server per il controllo del dominio,

il primo livello di codice è memorizzato direttamente nella macchina Client che si

può connettere direttamente al secondo livello, dove avvengono i processi di

transazioni verso il database della struttura, le connessioni, la preparazioni delle

stringhe di input da inviare al database e dove viene ricevuto l’output richiesto .

Questo permette di non appesantire il carico del Server Citrix, riservandolo

agli utenti esterni e, nel contempo, l’utilizzo dei Server Citrix dagli utenti esterni non

appesantisce la rete locale, distribuendo così maggiormente il carico d’utenza e di

elaborazione in modo ottimizzato.

Le macchine che lavorano in locale hanno più funzionalità rispetto a quelle

che si collegano tramite web. È infatti possibile tramite l’applicazione inviare

comunicazioni telefoniche senza digitare il numero sulla tastiera dell’apparecchio.

L’apparecchio telefonico è collegato alla macchina locale tramite una porta USB,

selezionando con il mouse il numero telefonico sullo schermo del terminale questo

viene composto automaticamente, quindi alzando la cornetta dell’apparecchio è

possibile avviare la normale comunicazione.

È, inoltre, possibile impostare un canale per la comunicazione utilizzando

- 12 -

radiotrasmittenti. Dall’applicazione vengono inviati i dati di configurazione per la

trasmissione al Server Radio. In questo server è presente un software per

l’allacciamento dei vari ponti radio. Vengono quindi “prenotati” i canali di

comunicazione e viene attesa una risposta della buona riuscita dell’allacciamento. A

quel punto è possibile, tramite l’apparecchio radio, iniziare una comunicazione

standard.

2.1.3 Autenticazione: Controller di dominio

L’autenticazione di un utente del sistema avviene collegandosi a un primo

Server. Il Server, che chiameremo ‘Dominio’, ha il compito di riconoscere l’utente

che si collega in locale o tramite web e di gestire i diritti di accesso a determinate

funzionalità, questo viene gestito tramite il servizio Active Directory presente in

Server Windows 2003.

L’Active Directory è il servizio directory di Windows che memorizza le

informazioni sugli oggetti della rete e ne permette la ricerca e l'utilizzo da parte di

utenti e amministratori, fornendo un archivio dati strutturato in modo logico e

gerarchico. Tale servizio è caratterizzato da prestazioni e scalabilità e consente una

maggiore flessibilità nella progettazione, implementazione e gestione della directory

dell'organizzazione [03].

A questo server accedono tutte le macchine della nostra architettura per il

controllo degli accessi e per la gestione dei diritti: il server Citrix nel momento che

l’utente si collega dall’esterno per il riconoscimento, la macchina MTS per il

controllo di accesso alle funzioni e al tipo di dati del database dei vari utenti e per la

gestione e identificazione dei permessi del Server di dominio locale.

Gli accessi sono organizzati in unità organizzative. Sono state individuate tre

diverse unità: i Corpi, i Distretti e la Federazione, che sono i gruppi di utenti esterni

che si collegano tramite web.

- 13 -

2.1.4 Il primo livello: Server Citrix Metaframe XP

Una volta che l’utente è autenticato entriamo nel primo livello

dell’architettura dove viene pubblicata l’applicazione. In questo livello della struttura

sono presenti due Server che permettono di suddividere il carico di elaborazione. Il

carico viene suddiviso tramite un processo che controlla il numero di utenti collegati

e indirizza la sessione dell’utente sulla macchina con meno lavoro in corso.

Questo livello viene sviluppato tramite il Server Citrix Metaframe. Il Server

Citrix è composto da un componente chiamato Farm che permette la pubblicazione

delle applicazioni sul server senza la necessità di scaricare applicazioni dal lato

Client. L’avvio di tutte le elaborazioni avviene in questo modo: una volta che

l’utente ha visualizzato l’interfaccia sul Client in cui compare l’icona del

programma, selezionandola esso invia il comando di inizio elaborazione

all’applicazione sul server, il quale a sua volta crea ed invia la visualizzazione

dell’applicazione sullo schermo della periferica Client. Il processo server continua a

inviare gli aggiornamenti e gli output dell’elaborazione sull’interfaccia Client

successivamente agli input ricevuti da quest’ultimo.

È stata costruita una struttura che permettesse l’utilizzo di un un’unica

applicazione per volta non permettendo la possibilità di accesso in modalità desktop,

ma sono in modalità applicazione. La Farm permette di pubblicare applicazioni senza

possibilità di accedere al sistema gestionale. Al suo interno mantiene un’istanza per

ogni utente connesso. Durante l’elaborazione viene riservata ad ogni utente la

quantità di memoria necessaria e cicli di CPU per un periodo di tempo strettamente

necessario all’elaborazione richiesta dopo di ché viene immediatamente liberata.

I benefici di questo tipo di sistema sono:

• un protocollo più leggero per la comunicazione Client/Server.

• il controllo di carico fra più server suddividendo gli utenti su due o più

macchine.

• la pubblicazione di applicazioni senza necessità di scaricarle sulle macchine

Client.

- 14 -

2.1.5 Il secondo livello: macchina MTS

Se la prima parte è rivolta principalmente all’interfacciamento del sistema,

successivamente si trova la parte il cui compito è quella di reperire ed elaborare le

informazioni direttamente dal database. Tutto questo viene effettuato con l’utilizzo di

una macchina MTS (Microsoft Transaction Server) che si occupa delle transazioni e

della comunicazione con la base di dati vera e propria. Questo livello risiede su una

macchina e viene sviluppata attraverso delle librerie (DLL) ed utilizzando dei

componenti software sviluppati tramite lo standard COM+ (Component Object

Model) che definisce funzioni per creare componenti e per controllare la

comunicazione fra questi e i loro Client [02]. I componenti MTS vengono organizzati

all’interno del codice in gruppi “package” raccolti in base a funzionalità simili,

regole comuni per l’attivazione e disattivazione, regole per la sicurezza.

Primo compito di questo livello è quello di connettersi al database. Questo

avviene attraverso un collegamento TCP/IP che si collega al database tramite un

canale ODBC.

Questo livello si connette regolarmente una prima volta al database per

l’elaborazione, una volta finito, la macchina mantiene ancora attiva la connessione

anche se non associata ad uno specifico utente, infatti sono tenute in memoria un

pool di connessioni attive. Questo permette un miglioramento dei tempi di accesso

alla fonte di dati, in quanto non richiede una continua connessione e rilascio, ma

utilizza collegamenti già in uso.

Le istanze degli oggetti sono generate solo quando l’applicazione ne ha

bisogno e rimangono attive il tempo necessario per l’esecuzione di un metodo, poi

vengono rilasciate. In questo modo a parità di risorse hardware è possibile servire più

Client.

La macchina MTS mantiene dei puntatori al codice e ai dati di ogni oggetto

istanziato nel primo livello, ma nel momento che un determinato oggetto finisce

l’elaborazione e termina il suo stato attivo, questo livello mantiene il suo stato e il

comportamento fino a quando la memoria a disposizione glielo permette. Nel caso lo

spazio disponibile per nuove istanze non fosse sufficiente, gli oggetti non attivi

vengono eliminati ed è quindi impossibile sapere, in un collegamento successivo, se

- 15 -

lo stato dell’oggetto precedente è ancora memorizzato. Quindi sarà il Server Citrix

nel primo livello a tenere aggiornato permanentemente lo stato di ogni elemento

dell’applicazione e verrà ripristinato nel secondo livello solo nel momento di una

chiamata passandolo come parametro di input, permettendo ancora una volta una

migliore gestione della memoria disponibile.

L’elaborazione di transazioni è una delle funzioni più importanti di MTS.

Una transazione termina quando l’applicazione esegue un commit o interrompe la

transazione. Nel caso di un’operazione di interruzione, MTS è costretta a

interrompere quel processo e a comunicare a tutti i gestori di risorse di effettuare il

rollback di qualunque operazione eseguita, annullando ogni tipo di elaborazione

avvenuta. Nel caso la transazione avvenga regolarmente ogni modifica o comunque

operazione verrebbe memorizzata [01].

In questo livello vengono anche definiti i permessi di accesso a determinate

procedure che vengono gestiti poi tramite il Server Dominio. Vari utenti hanno la

facoltà di modifica e lettura dei dati, altri solo di lettura, alcuni possono leggere

anche dati privati e altri solo pubblici. Questo sistema viene sviluppato tramite

software. Durante lo sviluppo di un oggetto MTS sono stati definiti dei ruoli e

utilizzati al fine di dare autorizzazioni di sicurezza specifiche, concedendo o negando

l’accesso a determinate funzioni. Nel momento in cui viene creato un nuovo utente

che utilizza l’applicazione, questo viene vincolato a seconda del ruolo inserendolo in

un determinato gruppo di utenti.

2.1.6 Database

Piattaforma del database è Microsoft SQL Server 2003.

Ancora una volta nella progettazione del database è stato considerato la

necessità di elaborazioni veloci, la trasmissione al Client della minor quantità

possibile di dati e di mantenere l’integrità dei dati durante la modifica di questi.

Ci si è voluti assicurare che:

• Tutti gli aggiornamenti del database siano eseguiti come un’unica entità.

Questo significa che tutte le transazioni cercano di raggruppare gli

- 16 -

aggiornamenti del database in una singola unità di lavoro e se un

aggiornamento non riesce, tutti falliscono.

• La gestione della consistenza dei dati anche in caso di errore dell'hardware

del server, del sistema operativo o del database. In caso di evento anomalo, al

momento del riavvio, vengono utilizzati i log delle transazioni per

l'esecuzione automatica del rollback delle operazioni non completate fino al

punto in cui si è verificato l'errore di sistema.

Questi obiettivi sono stati raggiunti garantendo che la transazione sia

completata nel tempo più breve possibile, bloccando il record appropriato e

ottimizzando l’interrogazione.

Per ottimizzare i tempi di elaborazioni nella struttura del database sono state

create Store Procedure, ossia piccoli programmi che si trovano all’interno del

database ed eseguono operazioni specifiche [04]. Lo spostamento del codice nel

database comporta sicuramente alcuni vantaggi:

• La possibilità di riutilizzo del codice, infatti tutti i moduli di codice possono

utilizzare la medesima procedura del database.

• Riduzione del traffico di rete. Il Server e il Client deve comunicare solo in

caso di errore, perciò il traffico è ridotto notevolmente.

• Precompilazione del codice. Le Store Procedure sono precompilate nel

server e funzionano in modo più efficiente rispetto al SQL dinamico, ossia la

possibilità di costruire interrogazioni al momento dell’esecuzione di un

programma [09].

• La limitazione del numero di dati recuperati dal database, vengono trasmessi

dati già elaborati e quindi semplicemente le informazioni necessarie,

diminuendo il numero di byte trasmessi, migliorando le prestazioni della

rete, del Client e del Server.

Oltre a Store Procedure sono state sviluppate delle Viste. Le Viste sono delle

query memorizzate con un proprio nome che possono essere considerate simili a

tabelle virtuali, vengono memorizzate all’interno del database e nel momento che

vengono utilizzate non occorrono lunghi tempi di elaborazione in quanto registrata

permanentemente sul database [04]. Sono una via efficace per mostrare informazioni

che arrivano da una o più tabelle. Grazie a questo strumento si è raggiunto l’obiettivo

- 17 -

di mostrare solo una parte di una o più tabelle, raccogliendo record già “pronti” , dati

utili per altre eventuali interrogazioni.

Il database è stato strutturato in modo che non ci fossero informazioni

duplicate, compiendo una normalizzazione fisica e logica dei dati, riuscendo a

eliminare la ridondanza di informazioni

Per il tipo di dati che il nostro database contiene è frequente la possibilità di

riscontrare dati duplicati. Due esempi rilevanti possono essere dati dalle tabelle

contenenti le anagrafiche e i numeri di telefono di personale di varia provenienza.

Figura 2.1.6.1. Diagramma database Anagrafiche

- 18 -

Si consideri il problema che la stessa persona può comparire con lo stesso

nome, essendo le stessa persona fisica, ma presente con ruoli diversi. Una persona

che svolge la carica di sindaco potrebbe anche svolgere il compito di Vigile del

Fuoco volontario, provocando in questo modo un duplicato di informazioni. Si è

risolto il problema inserendo in un’unica tabella le anagrafiche di tutte le persone

presenti nel database, inserendo il loro nome, cognome, indirizzo, data e luogo di

nascita, cittadinanza, codice fiscale e altre informazioni di carattere generale.

A questo punto sono state costruite diverse tabelle che ognuna raggruppa il

personale in base al ruolo svolto. La persona cercata nelle varie tabelle viene

riconosciuta con un codice univoco che lo identifica nell’anagrafica comune. Quindi

egli viene qui inserito una sola volta ed i dati identificativi della persona e il suo

codice di riferimento viene inserito nelle tabelle relative alle altre sue competenze.

Successivamente viene mostrato il diagramma (figura n. 2.1.6.1) relativo alla

struttura e alle relazioni di parte del database relativo alle anagrafiche comuni.

Simile al problema delle anagrafiche è il problema dei numeri telefonici. Anche in

questo caso ogni persona può avere più recapiti a seconda del ruolo svolto.

È importante riuscire a individuare il giusto recapito della persona che si

intende contattare a seconda della carica che svolge. Per esempio nel caso ci fosse

un’emergenza e fosse necessario avvertire il sindaco del comune di competenza su

quel territorio, occorre comporre il numero di telefono della sede comunale, invece

se fosse necessario comunicare con il comandante del corpo che presiede il comune,

che è la stessa persona che riveste la carica di sindaco, il numero per reperirlo

potrebbe essere diverso.

Questo è stato risolto inserendo in un’unica tabella i diversi numeri di

telefono. Questi vengono reperiti, quando necessario, a seconda del codice

identificativo della persona e del codice del ruolo ricercato per quel particolare

evento. Lo stesso meccanismo è stato implementato per quel che riguarda gli

indirizzi e-mail.

Successivamente viene mostrato il diagramma (figura n .2.1.6.2) relativo alla

struttura e alle relazioni di parte del database relativo ai numeri telefonici.

- 19 -

Figura 2.1.6.2. Diagramma database relativo alle relazioni numeri telefonici/Anagrafiche Comuni

2.1.7 Sistema cartografico

Nell’architettura è previsto un sistema sofisticato per la gestione di un

supporto cartografico con il quale è possibile visualizzare le carte topografiche di

tutte le località della provincia di Trento ove può accadere un evento.

Questo è stato sviluppato utilizzando un Sistema Informativo Geografico

- 20 -

(GIS) e più precisamente una tecnologia che permette di posizionare ed analizzare

oggetti su una mappa. Il GIS, strumento di organizzazione dei dati terrestri, integra

ricerche, analisi statistiche e permette la memorizzazione dei dati per la generazione

di analisi geografiche corredate da tabelle, documenti e mappe [13].

Uno strumento GIS è composto da vari componenti tra cui l’hardware che è

rappresentato dal nostro computer su cui opera il GIS e il software MapObject che

mette a disposizione le funzioni per memorizzare, analizzare e visualizzare le

informazioni geografiche e un sistema per la gestione del database contenete le

rappresentazioni geografiche.

La componente più importante di un GIS e' costituita dai dati. I dati

geografici e le informazioni alfanumeriche ad essi associate possono essere acquisiti

direttamente dall'utente o inserite tramite prodotti già esistenti sul mercato.

L'obiettivo generale del nostro sistema informativo geografico e'

essenzialmente quello di svolgere cinque funzioni:

• Inserimento

• Trattamento

• Gestione

• Ricerca e Analisi

• Visualizzazione

Il sistema permette di visualizzare diversi elementi di una carta geografica.

Questi potrebbero essere acquedotti, strade, ferrovie, ecc.. Questo è reso possibile

lavorando tramite una serie di Layer. Visualizzata la rappresentazione cartografica

principale a seconda di quello che si vuole rappresentare vengono sovrapposti alla

mappa i tematismi che si sono scelti. L’applicazione è in grado di individuare la

giusta locazione dei vari strati da visualizzare memorizzando all’interno del database,

contenete i vari tematismi cartografici, le coordinate e la giusta posizione geografica.

Il database è, infatti, organizzato memorizzando i dati come una collezione di tabelle.

Campi comuni in differenti tabelle ne consentono il collegamento individuando il

layer da visualizzare e sovrapporre.

Le immagini contenute nel database sono suddivise in quadrati di un

determinato chilometraggio ridotto in scala, per riuscire a caricare solo piccole parti

della cartina altrimenti la visualizzazione sarebbe troppo pesante, richiedendo un

- 21 -

tempo eccessivo per il caricamento ed per il passaggio di dati al Client. Nel momento

in cui viene diminuito lo zoom su un area, che ricopre quindi una superficie più

ampia di un unico riquadro, l’immagine viene visualizzata unendo più quadrati di

immagine. Scendendo viceversa al di sotto di una certa scala il disegno visualizzato

cambia, richiamando un tematismo memorizzato nel database con un maggiore grado

di precisione e accuratezza.

Tutto questo è possibile costruendo un database di immagini che

rappresentano le varie zone e queste vengono richiamate tramite software che passa

le coordinate della zona da visualizzare e dal database vengono estratte le immagini

che soddisfano gli input. Tutto questo è fatto con l’appoggio di un programma

studiato appositamente per la visualizzazione di cartografie: MapObject.

Se l’utente ne ha i diritti ha la possibilità di memorizzare nel database nuove

località inserendole e inquadrandole sulla mappa. Se vengono selezionare nuove

zone, il database provvederà a inserire all’interno dell’apposita tabella il nome e le

coordinate da visualizzare nel caso venga richiesto.

Le immagini mostrano come si presenta la visualizzazione tipica delle carte

topografiche (figura n. 2.1.7.1) e viene dato un esempio di sovrapposizione di layer,

mostrando la rete stradale della città di Trento ( figura n. 2.1.7.2).

Figura 2.1.7.1. Esempio di visualizzazione. Cartografia di Trento

- 22 -

Figura 2.1.7.2. Esempio di visualizzazione con Layer. Cartografia di Trento con rete stradale

- 23 -

Capitolo 3

Il Sistema Informativo dei Vigili del Fuoco

3.1 Requisiti

La struttura organizzativa di cui si compone il Servizio Antincendi e

Protezione Civile è complessa, in quanto composta da elementi diversificati che

devono coordinarsi ed interagire fra loro. La struttura stessa richiede

un’organizzazione che permetta una continuità nelle diverse competenze, attraverso

metodologie di lavoro efficienti atte a consentire uno scambio d’informazioni fra i

vari organi.

I problemi gestionali risultano molteplici e diversificati.

La prima considerazione fondamentale riguarda la formazione professionale

del personale addetto che opera all’interno della struttura dei Vigili del Fuoco, nei

diversi settori di competenza. Infatti, all’interno di questa struttura è presente

personale con livelli di istruzione e di addestramento diversificati. È necessario,

quindi, avviare un’attività di programmazione che consenta di uniformare le varie

conoscenze attraverso la creazione di mezzi e strumenti utilizzabili da tutti

indistintamente. Non è necessario solo fornire un buon sistema, ma affinché il lavoro

risulti completo ed esauriente, è necessario fornire agli operatori, in prima istanza le

nozioni informatiche di base, ed in seconda istanza, i mezzi idonei alla divulgazione

delle notizie.

Secondo punto da considerare è che all’interno del Servizio dei Vigili del

Fuoco il lavoro viene gestito sulla base di turni alterni, svolti ciclicamente da

ciascuna squadra, in orario diurno e notturno. Una struttura organica di questo tipo

consente di dare continuità al lavoro garantendo così agli utenti efficienza e

professionalità nella gestione delle singole emergenze.

- 24 -

Affinché ci sia realmente continuità nel lavoro di prevenzione ed intervento

nell’emergenze diviene fondamentale dar vita ad una rete di collegamenti tra le molte

unità operative presenti, attraverso la quale il passaggio di informazioni possa

risultare rapido ed esaustivo. Per questo è necessario pensare ad un’applicazione che

permetta il reperimento di informazioni in modo trasparente e veloce. I dati devono

essere strutturati in modo tale che possano essere interpretati tutti allo stesso modo e

rapidamente, per avere immediatamente una visione della situazione presente.

Quindi formazione del personale e realizzazione di una programmazione

negli interventi, sono due fattori strettamente correlati fra loro nonché una

condizione essenziale per la progettazione e il buon andamento dell’intero sistema. Il

miglior connubio fra questi due elementi si ottiene attraverso studi approfonditi

mirati ad individuare i più appropriati mezzi di comunicazione e le migliori tecniche

di apprendimento al fine di poter utilizzare al meglio, all’occorrenza, risorse umane e

risorse materiali.

Un altro aspetto fondamentale della progettazione consiste nell’attendibilità

delle informazioni rilasciate e quindi nella necessità di aggiornamento continuo dei

dati stessi, perché questo aspetto risulti davvero di utilità pubblica, è indispensabile

organizzare un’attività di controllo sulla gestione dei dati, svolto da personale

competente individuato all’interno del Servizio stesso. Occorre controllare l’accesso

ai dati e le modifiche apportate devono essere verificate, è necessaria la possibilità di

risalire ai dati originari in caso di errore sviluppando sistemi di controllo e ripristino

di tutti i mezzi messi a disposizione.

Da tutto questo se ne deduce che è indispensabile indirizzare il lavoro di

progettazione verso studi atti a sviluppare contemporaneamente i mezzi con cui

operare, le tecniche con cui addestrare il personale ed i controlli con cui garantire

l’operato del Servizio.

3.2 Utenti del sistema

L’applicazione è utilizzata principalmente dalla Centrale del Corpo

Permanente dei Vigili del Fuoco (centralino) a cui è data la responsabilità di inviare

- 25 -

il primo allarme in caso di necessità e a cui sono indirizzate le chiamate di soccorso

dei cittadini della Provincia di Trento. Sarà quindi il primo organo che dovrà venire a

conoscenza di tutto ciò che necessita l’intervento richiesto.

Il secondo organo a cui interessa questa applicazione è composto dai diversi

Corpi dei Vigili del Fuoco Volontari distribuiti nei vari comuni e nelle sedi dei vari

distretti. In questo caso l’applicazione viene utilizzata per il reperimento di

informazioni e per l’aggiornamento dei dati relativi alla propria struttura del

personale, alle loro attrezzature in uso e, nel caso questi vengano allertati per un

eventuale intervento, per il reperimento delle informazioni. La distribuzione del

programma alle strutture periferiche collegate è importante in quanto per la sede

centrale dei Vigili del Fuoco non è sempre facile reperire cambiamenti di personale,

attrezzature, localizzazione di particolari zone periferiche del territorio .

La distribuzione di questa applicazione attualmente non è programmata per

altre strutture oltre quelle citate, ma questa contribuirà all’invio di un’eventuale

allarme ad organi di soccorso interessati nell’intervento.

Figura 3.2.1. Use Case

- 26 -

L’utente autorizzato interagirà con l’applicazione visualizzando e

modificando i dati inseriti nella base di dati a seconda dei diritti di accesso che

possiede: è utile infatti suddividere utenti con permessi di sola lettura e permessi di

modifica. Sarà necessario un ulteriore suddivisione del tipo di utenza a seconda che

la modifica venga fatta dal personale dei Corpi volontari o dai comandanti dei vari

distretti dato che i secondi hanno l’autorità di modifica e aggiornamento su una

quantità di dati maggiore, relativi a informazioni che raggruppano più comuni.

Lo UseCase (Figura n. 3.2.1) mostra una visualizzazione stilizzata degli

utenti che accedono all’applicazione e i principali e fondamentali obiettivi che questo

sistema si prefigge di raggiungere.

3.3 Accenno al linguaggio di sviluppo: Visual Basic

Visual Basic è un linguaggio ad oggetti ad alto livello che permette lo

sviluppo di software basato su componenti. Un componente è un blocco riutilizzabile

di software che può essere innestato con relativa facilità in altri componenti esistenti.

Questi componenti mostrano le loro funzionalità attraverso delle interfacce [02].

Questo nello sviluppo della nostra applicazione è molto importante in quanto

molte parti del programma condividono elementi comuni, quindi ciò permette di

integrare facilmente diverse parti dell’applicazione con componenti testati e

sperimentati non ricreandoli nuovi e permettendo di apportare in caso di necessità

eventuali funzionalità specifiche.

Un’altra caratteristica di Visual Basic è quella di essere un linguaggio event-

driven. Con questo termine si intende che l'elemento che sta alla base del linguaggio

è l'evento, cioè, più in generale, l'azione: un evento è il clic dell'utente su un pulsante,

la digitazione in una casella di testo, la selezione di un comando di menu, ma anche

il cambiamento della risoluzione, l'aggiunta di una periferica al sistema, ecc. Gli

oggetti inseriti in un form Visual Basic sono in grado di riconoscere in automatico gli

eventi più comuni, senza bisogno che il programmatore si preoccupi, ad esempio, di

stabilire quando l'utente fa clic su un pulsante, seleziona un elemento da una lista,

ecc. [10]

- 27 -

Queste caratteristiche fanno di Visual Basic un linguaggio di facile utilizzo,

ma che mette a disposizione strumenti per la programmazione Client-Server

3.4 Struttura del Programma

Le funzionalità che questa applicazione richiede non sono molte, ma è

necessario che queste vengano organizzate in modo che permettano al programma un’elaborazione e visualizzazione veloce.

Considerando le informazioni di cui si ha bisogno occorre suddividere queste

per argomenti, progettando una diversa scheda per la visualizzazione, permettendo di

analizzarle e poterle modificare separatamente per i diversi argomenti di

appartenenza, creando una struttura chiara senza ambiguità.

Nella creazione dell’applicazione sono stati considerati alcuni problemi per

sviluppare un programma che raggiungesse alte prestazioni di velocità.

Uno dei problemi principali per consentire un miglioramento delle prestazioni

è la diminuzione del numero di passaggi dei dati dal Client al Server al database e

viceversa, contribuendo a una rilevante diminuzione del traffico di rete come già

specificato nel primo capitolo.

Un’altra questione considerata è il numero di utenti potenziali e il notevole

volume di informazioni gestite, da cui la necessità di evitare sovraccarichi del

sistema. Con la presenza contemporanea di ‘n’ utenti che richiedono operazioni al

server la quantità di dati e le elaborazioni richieste aumentano proporzionalmente, è

necessario quindi pensare ad un tipo di ‘visualizzazione minima’ limitata allo stretto

necessario richiesto.

3.4.1 L’interfaccia

Dallo studio dei requisiti richiesti dall’applicazione deduciamo la necessità di

un’interfaccia utente il più possibile intuitiva, che permetta il facile reperimento delle

informazioni, le quali devono essere visualizzate in modo semplice, chiaro e senza

- 28 -

possibilità di interpretazioni equivoche.

Figura 3.4.1.1. Interfaccia utente.

È stato scelto l’utilizzo di una grafica essenziale ma che permette una

elaborazione poco costosa in termini di risorse utilizzate, risolvendo così il problema

di tempi troppo lunghi per il caricamento di immagini non necessarie o di pesanti

elementi grafici non richiesti, evitando nel contempo di aumentare inutilmente i cicli

macchina necessari alle elaborazioni.

È stata quindi implementata un’interfaccia (figura n. 3.4.1.1) suddivisa in due

parti: la prima ha la funzione d’inserimento dei parametri di ricerca delle località di

interesse e la seconda è utilizzata per la visualizzazione dei risultati.

Nella parte dedicata alla ricerca si ha la possibilità di inserire anche in modo

parziale ed errato una stringa di testo relativa al nome di località della Provincia di

Trento al fine di poter selezionare gli organi competenti per quella determinata zona,

tutti i Corpi appartenenti al un comune ove essa si trova ed altre informazioni

concernenti il suo distretto. Le informazioni possono essere ulteriormente raffinate

- 29 -

utilizzando un filtro che permette di selezionare le località e corpi appartenenti ad un

determinato comune, in alternativa ad una visualizzazione generale di tutti i corpi e

di tutte le località. Le eventuali insicurezze sul nome esatto delle località possono

essere risolte ricercandone solamente la parte iniziale o inserendo una qualsiasi

stringa contenuta nel nome.

Nella parte dedicata alla ricerca è presente anche una finestra cronologie,

contenente tutte le località, corpi e distretti ricercati in precedenza, è quindi possibile

visualizzare e recuperare dati relativi a ricerche effettuate precedentemente.

Le informazioni trovate si riferiscono sempre ad un Comune ed ai Corpi di

soccorso esistenti in esso, nonché alle attrezzature a disposizione, mezzi, ecc. Il

Comune è cioè l’unità territoriale prescelta come base geografica sicura e

indiscutibile nei suoi confini per visualizzare con esattezza le informazioni relative

all’insieme degli organi di soccorso su di essa competenti. I risultati della ricerca

vengono raggruppate in diversi moduli (figura n. 3.4.1.2) a seconda a quale tipo di

argomento si riferiscono. La maggior parte delle informazioni riguardano numeri di

telefono ed indirizzi delle strutture competenti della zona ricercata.

Figura 3.4.1.2 Moduli per suddivisione delle informazioni ottenute tramite la ricerca

I moduli che a disposizione si dividono in:

• Generale: raccoglie le informazioni più importanti e utili riguardanti il

Corpo che presiede il comune ricercato

• Organico: visualizza il personale appartenente al Corpo selezionato.

• Carabinieri: visualizza tutte le informazioni relative alla corpo dei

Carabinieri che presiede nel comune e rende disponibili tutte le

informazioni necessarie per un eventuale comunicazione con la

centrale di comando della località ricercata

• Comune: visualizza tutte le informazioni relative alla sede comunale e

rende disponibili tutte le informazioni necessarie per un eventuale

comunicazione con il comune della località ricercata..

- 30 -

• Forestale: visualizza tutte le informazioni relative al corpo Forestale

che presiede nel comune e rende disponibili tutte le informazioni

necessarie per un eventuale comunicazione con la sede della località

ricercata

• Soccorso Alpino: visualizza tutte le informazioni relative alla struttura

del Soccorso Alpino che presiede nel comune e rende disponibili tutte

le informazioni necessarie per un eventuale comunicazione con la

sede della località ricercata.

• Mezzi: mostra un elenco dei mezzi a disposizione del Corpo ricercato

ed in più visualizza un elenco di tutte le vetture di cui si dovrebbe

avere la disponibilità, ma che non tutti possiedono. Nel caso il Corpo

ricercato non ha in dotazione un particolare mezzo, selezionandolo

dall’elenco, viene visualizzata una lista di tutti i Corpi che lo

possiedono in ordine crescente per distanza dalla località che si è

scelta.

• Attrezzature: mostra un elenco delle attrezzature a disposizione del

Corpo ricercato ed in più visualizza un elenco di tutti gli strumenti di

cui si dovrebbe avere la disponibilità, ma che non tutti possiedono.

Nel caso il Corpo ricercato non avesse in dotazione una particolare

attrezzatura, selezionandola dall’elenco, viene data una lista di tutti i

Corpi che la possiedono in ordine crescente per distanza dalla località

che si è scelta. .

• Radio: da qui è possibile inviare le selettive selezionando le radio

appartenenti ad ogni Corpo dalla località che si è scelta.

• Note Permanenti: il corpo Permanente di Trento ha la possibilità di

inserire annotazioni o promemoria in riferimento alla zona

visualizzata. Le note si potrebbero riferire a eventi successi, a mezzi in

manutenzione, ecc.

• Note Volontari: il corpo di giurisdizione della località scelta ha la

possibilità di inserire annotazioni o promemoria. Le note si potrebbero

riferire a eventi successi, a mezzi in manutenzione, ecc.

L’interfaccia mette a disposizione varie funzionalità per la gestione dei dati

- 31 -

visualizzati.

Funzione molto importante è quella di inviare Selettive o chiamate

telefoniche automatiche, il che significa che passando con il mouse sopra il numero

di telefono o il numero del canale radio e selezionandolo si invia direttamente la

chiamata senza comporre fisicamente il numero sulla tastiera dell’apparecchio o

impostando i ponti radio, permettendo quindi una selezione veloce e senza errori.

Le varie informazioni visualizzate possono essere ovviamente modificate.

Ciò può avvenire anche in remoto e con diversi livelli nei diritti di accesso e

modifica dei dati, in relazione al diverso grado di responsabilità dell’utente connesso

al sistema. Posizionati sulla scheda che si intende modificare e qualora si abbiano le

competenze e i diritti è possibile quindi visualizzare il modulo per la modifica dei

dati con relativa funzione di salvataggio. Ciò è utile nel caso di cambiamenti di

informazioni di recapito, del cambiamento dei mezzi a disposizione dei corpi,

dell’inserimento e modifica delle annotazioni di fatti occasionali e di qualsiasi altro

mutamento nei dati importante e rilevante.

È inoltre possibile, una volta individuata la località di interesse, visualizzarne

la posizione su cartografia. Per fare questo si seleziona semplicemente il pulsante

“Cartografia” presente nella barra superiore dell’interfaccia (Figura n. 3.4.1.3) e

automaticamente viene visualizzata una mappa con al centro la zona ricercata.

Figura 3.4.1.3. Barra degli strumenti per la scelta di visualizzazione

A questo punto è possibile richiedere la visualizzazione di altri elementi

(tematismi), cioè tipi diversi di informazioni grafiche relative al territorio mostrato

che potrebbero essere utili e rilevanti nell’emergenza. Ne sono un esempio: fiumi,

acquedotti, ponti, ferrovie.

E’ possibile scegliere gli elementi da visualizzare da un menu a sinistra

dell’immagine. Una volta visualizzato il tema interessato viene aggiornata

automaticamente la rappresentazione cartografica (figura n. 3.4.1.4).

L’applicazione cartografica permette di ricercare altre località una volta

- 32 -

visualizzata la zona iniziale. Tramite apposite icone è possibile selezionare vari

strumenti di manipolazione grafica della zona rappresentata per ingrandire o

diminuire la scala di rappresentazione per individuare meglio un determinato punto

della mappa, nonché spostarsi sulla mappa in tutte le direzioni.

È possibile infine passare dalla vista stilizzata in modalità cartografica di un

territorio ad una vera e propria fotografia aerea della zona stessa (figura n. 3.4.1.5),

permettendo anche la sovrapposizione di entrambe le viste e cioè mantenendo

disponibili tutte le funzioni che l’applicazione mette a disposizione per la cartografia:

la visualizzazione degli elementi, la ricerca di nuove località, ecc..

Figura 3.4.1.4. Immagine della città di Trento con visualizzazione dei corsi d'acqua e la rete stradale

- 33 -

Figura 3.4.1.5. Immagine reale della città di Trento

3.4.2 Componente sviluppato: Ricerca dei dati

È stato pensato un componente (figura n. 3.4.2.1) che permettesse il

reperimento di informazioni con la possibilità di inserire parametri di ricerca validi

per risultati generici come pure più specifici. Le possibili ricerche sono molteplici, si

va dalla ricerca di strutture organizzative provinciali, ai numeri telefonici, agli organi

di giurisdizione e competenza territoriali.

Questo componente è stato sviluppato con una serie di metodi e funzioni che

trasmettono una serie di richieste al database, e si occupa della visualizzazione dei

risultati della ricerca attraverso opportune tabelle e liste. Tale componente si allaccia

successivamente ad altri classi ed oggetti che si occupano dell’aggiornamento degli

altri moduli per mostrare i dati più esaustivi e specifici dei risultati inizialmente

prodotti con l’inserimento dei parametri.

- 34 -

Figura 3.4.2.1. Componente per la ricerca delle informazioni

Nello sviluppo di questo componente è stato molto importante considerare il

peso che ogni ciclo di istruzioni aveva sulla velocità di elaborazione

dell’applicazione, cercando di diminuire al massimo la richiesta di risorse della

macchina. Queste risorse sono la memoria, le chiamate al database, il numero di

componenti da visualizzare, elementi che devono esser considerati ma che comunque

non devono influire sul risultato della ricerca che deve soddisfare al meglio l’input.

È stato necessario ottimizzare al massimo il codice per permettere il minor

numero possibile di elaborazioni e di richieste al server, questo attraverso una

struttura del database non ridondante, l’aggiornamento dei vari elementi

dell’interfaccia facendo riferimento ad essi in un'unica chiamata o comunque nel

- 35 -

minor numero di sessioni possibili.

3.4.2.1 Simulazione del funzionamento

L’impostazione di default di questo componente è la lista di tutte le località

inserite nel database della provincia.

A questo punto è possibile selezionare attraverso varie opzioni cosa si vuole

ricercare: si può scegliere fra la lista delle località vere e proprie, l’elenco dei Corpi

Volontari o quella dei vari distretti (figura n. 3.4.2..1.1). Da questa prima scelta

vengono visualizzate nella lista principale le informazioni trovate: tutte le località

della Provincia, tutti i corpi dei Vigili del Fuoco Volontari del fuoco che

appartengono ai vari comuni o tutti i distretti che compongono la provincia.

Figura 3.4.2.1.1. Componente per la scelta del tipo di dati da visualizzare

Una volta visualizzata la lista principale, selezionando con il mouse uno dei

suoi elementi vengono aggiornate in automatico tutte le informazioni relative, sia

nella parte del componente dedito alla ricerca sia nei moduli collegati per la

visualizzazione di dati più specifici.

Se si vuole ottenere una selezione più specifica partendo dalla lista iniziale

generica sono possibili ulteriori ricerche più dettagliate.

Il componente permette di fare una ricerca inserendo parte di una parola.

All’interno del database vengono selezionate le parole che iniziano o che contengono

il termine inserito. La visualizzazione dei risultati avviene in ordine decrescente di

importanza. In questo caso per importanza si intende il fatto che i risultati della

ricerca si avvicinino il più possibile al termine inserito, più il criterio di ricerca è

uguale a una parola più acquisirà valore. Nella fase di ricerca verrà quindi valutato

- 36 -

tale criterio. Nel momento che viene analizzata la lista vengono generate tutte le

possibili forme alternative della parola cercata e visualizzate quelle che più si

avvicinano.

La ricerca può essere effettuata in due modalità: o inserendo la parola nella

finestra di testo e quindi viene cercata la parola che inizia con il termine inserito

(figura n. 3.4.2.1.3) oppure inserendo un termine più impreciso nella finestra che

compare selezionando il pulsante “Ricerca” (figura n. 3.4.2.1.2). In questo caso verrà

avviata una ricerca della stringa immessa, quale parola o parte di testo contenuta

nella denominazione della località che verrà trovata anche più volte con la completa

scansione della lista delle Località, Corpi o Distretti.

Figura 3.4.2.1.2 Pulsante e finestra per la ricerca di una stringa contenuta in una località

Figura 3.4.2.1.3. Casella di testo e lista principale per la ricerca di una stringa iniziale di una località

Sviluppando questa parte si è cercato di ridurre il meno possibile i risultati

errati o inesistenti dovuti ad errori commessi dall’utente nell’inserimento del termine

di ricerca. Sono stati considerati errori come l’inserimento di doppie inesistenti ed

accenti. Altro fattore considerato il fatto che alcune località possono essere ricercate

col nome dialettale, cioè il nome tipico utilizzato in zona, nome che può risultare

diverso da quello correttamente memorizzato in italiano. La soluzione a questo

problema è stato risolto analizzando le varie località e confrontandole con il termine

di ricerca considerando tutte le possibili soluzioni. Vengono generate più parole

togliendo inizialmente ogni accento e successivamente eventuali doppie contenute. A

- 37 -

questo punto il confronto con il termine di ricerca inserito avviene sia sulla parola

originaria, sia sulla parole ricavate togliendoli alcuni elementi. In questo modo

aumentano le probabilità di riuscire ad individuare la località ricercata.

La ricerca è implementata facendo una scansione sequenziale della lista delle

località del database alla ricerca della stringa immessa, nel caso essa venga trovata e

si trovi all’inizio del nome il record riceve una priorità maggiore, viceversa nel caso

essa venga trovata contenuta all’interno esso riceve un diverso e minore grado di

priorità. Esistono poi altri criteri che assegnano altri gradi di priorità in funzione di

diversi parametri e una serie di altre precedenze per somiglianze fra la stringa inserita

e il nome della località. Alla fine viene stilata una lista di quelle località, corpi o

distretti che soddisfano almeno uno dei vincoli. Per ognuna di queste ricerche

vengono quindi proposte sia le denominazioni delle località identiche al termine

inserito sia quelle simili o somiglianti secondo criteri prestabiliti. Esse vengono poi

visualizzate secondo l’ordine corrispondente al valore di priorità predefinito.

Figura 3.4.2.1.4 Lista Secondaria: vengono visualizzati i Corpi Volontari che presiedono nella località ricercata

Figura 3.4.2.1.5. Cronologia: lista delle ricerche effettuate precedentemente

Una volta selezionata una voce dalla lista principale è successivamente e

automaticamente aggiornata la lista secondaria (figura n. 3.4.2.1.4). Questa viene

visualizzata solo nel caso si tratti di una ricerca sulle località (non avviene cioè nel

caso di ricerca diretta di Corpo o Distretto). In questa lista secondaria viene

visualizzata l’informazione più importante ai fini dell’ immediato allertamento e cioè

il Corpo o i Corpi di competenza che presiedono al comune della località ricercata.

Tutte le selezioni effettuate e le ricerche vengono inserite nella finestra

- 38 -

relativa alla cronologia (figura n. 2.6.1.5), che raccoglie la sequenza storica. Dalla

cronologia selezionando una voce presente nella lista si può ritornare al termine

ricercato con tutte le opzioni prescelte precedentemente.

All’interno del componente è presente anche un filtro sui comuni (figura n.

3.4.2.1.6), utile nel caso si ricerchino località, oppure sui distretti nei casi in cui sia

stata prescelta la lista dei Corpi. Questi due filtri servono rispettivamente per ottenere

liste di località o di Corpi volontari relativi solamente al comune o al distretto

prescelto. Quindi nel primo caso è possibile selezionare un comune e

conseguentemente verranno visualizzate solamente le località riferite a quel comune

e analogamente nel secondo caso selezionando un distretto verranno visualizzati

esclusivamente i corpi volontari che presiedono a quel distretto.

Sempre al fine di velocizzare le ricerche nei filtri è stato implementato un

meccanismo di completamento automatico delle parole. Quando viene digitata una

prima lettera all’interno della casella di testo essa viene ricercata nel database e mano

a mano che si digitano le altre lettere si ottiene automaticamente il completamento

della parola, cioè della denominazione della del comune o del distretto. Nel caso in

cui essa non corrisponda alla località che si voleva cercare, continuando a digitare i

caratteri la ricerca automatica del termine viene mano a mano affinata. In pratica

viene sempre completata la parola e proposta all’operatore una località le cui lettere

iniziano in modo corrispondente alle lettere già digitate. Tale meccanismo funziona

anche nella normale ricerca al di fuori del filtro ma in questi caso la parola non viene

completata, ma semplicemente si viene posizionati automaticamente sulla località

corrispondente ai caratteri digitati. Qualora la stringa digitata non corrisponda a

nessun termine memorizzato nel database con quei caratteri iniziali, l’operatore,

come già spiegato, potrà comunque procedere tramite il pulsante “ricerca” ad

effettuare una scansione per testo contenuto.

Una limitazione delle possibilità di ricerca è data dal fatto che non è possibile

abbinare contemporaneamente la ricerca di una stringa e la ricerca tramite filtro.

Tutte queste procedure sono state implementate per permettere ricerche più

rapide e con meno possibilità di errori. Nel filtro l’errore viene evitato in quanto

qualora venga ricercato un comune o un distretto inesistente esso semplicemente non

verrà visualizzato quindi non c’è la possibilità di ricerca di dati inesistenti.

- 39 -

Figura 3.4.2.1.6. Finestre per la ricerca tramite filtro per comune o distretto

Questo componente risulta essere un elemento importante per il

funzionamento dell’interfaccia. Tutte le visualizzazioni dei dati ricercati partono da

qui.

- 40 -

Capitolo 4

Stato dell’arte

Il sistema informativo della Protezione Civile e dei Vigili del Fuoco non è

uniformato in tutta Italia. Non è cioè presente un identico software in tutti i comandi

provinciali sparsi sul territorio nazionale, cosa che in realtà permetterebbe fra l’altro

di uniformare anche le analisi statistiche. Ogni Corpo Provinciale italiano

generalmente studia una propria soluzione di gestione, utilizzando software spesso

realizzati in proprio o più spesso commissionati a ditte esterne e seguendo le proprie

esigenze e possibilità economiche.

Nel campo dei sistemi geograficamente distribuiti è possibile trovare varie

soluzioni sviluppate anche da aziende private, impegnate nello sviluppo di

applicazioni per enti sia pubblici che privati.

Se si fanno ricerche nel web o si leggono riviste specializzate della protezione

civile [08] si trovano sempre più spesso applicazioni che somigliano alla soluzione

implementata per il Corpo dei Vigili del Fuoco della Provincia di Trento, ma sono

spesso poco orientate alla concreta operatività professionale. Tutti gli applicativi

sviluppati cercano di seguire le disposizioni contenute nel regolamento denominato

“Augustus” della Protezione Civile, che fornisce l'insieme di normative alle quali è

indispensabile attenersi in caso di eventi calamitosi per facilitare le operazioni in

caso di emergenze ed interventi.

Di seguito vengono illustrati alcuni esempi.

4.1 Soluzione “ZEROgis On Line” [12]

Zerobyte Sistemi è un’azienda che si occupa della informatizzazione di enti

pubblici, sia nell'ambito gestionale che cartografico. L'azienda produce software

specifico per agevolare ed ottimizzare i lavori delle Amministrazioni.

- 41 -

Lo strumento software di seguito illustrato ricorre ad un sistema GIS per

pianificare ed ottimizzare le risorse a disposizione. L’applicazione sviluppata utilizza

la rete Internet e consente la gestione completa (lettura/scrittura/cancellazione dei

dati) di quasi tutti i settori amministrativi.

Con questo prodotto informazioni disomogenee provenienti da settori diversi

confluiscono in un insieme organico di dati, utilizzabili dai vari Uffici secondo le

loro specifiche competenze.

È possibile, mediante Internet, condividere informazioni prodotte da svariati

sistemi indipendentemente dalla collocazione geografica e temporale, dalla

piattaforma usata o dal sistema hardware adottato. Di seguito viene mostrata

l’immagine (figura n. 4.1.1) dell’interfaccia per la visualizzazione dei dati.

Figura 4.1.1. Interfaccia visualizzazione dati

Tramite la struttura di ZEROgis On Line è possibile l’aggiornamento dei dati,

con l’utilizzo di un collegamento Internet il prodotto è disponibile per tutti gli Utenti

abilitati.

Il motore cartografico (figura n. 4.1.2) utilizzato è di ultima generazione e in

grado di interagire con i formati cartografici più diffusi quali, ad esempio, i file SHP

(Arcview), DWG (Autocad), Geotiff, Gif, ECW etc.

ZEROgis On Line utilizza Oracle per la gestione di database, ed è

compatibile con file Access; per facilitare l’interazione e l’importazione degli archivi

già esistenti presso gli Enti.

Questo sistema mette a disposizione un metodo di comunicazione

diffondendo le informazioni in Rete, infatti sono a disposizione funzionalità per

- 42 -

pubblicare notizie (viabilità, linee guida ecc.) rendendole di pubblico dominio

Figura 4.1.2 Interfaccia visualizzazione dati geografici

Tramite questa applicazione è possibile interagire con sistemi di monitoraggio

mezzi e persone (tramite rete GPS GSM e/o Radio), e con ZEROmessage, software

per la comunicazione e la reperibilità (tramite SMS, FAX, E-MAIL e messaggi di

testo via Radio).

4.2 Soluzioni “SIRIO” [11]

Celesta è un’azienda italiana che sviluppa applicazioni per la Protezione

Civile. Ha varie opzioni di software per diverse funzionalità.

Un applicativo chiamato “Sirio Comunale” permette di realizzare piani

comunali e provinciali di previsione, prevenzione e di gestione dell’emergenza, è

indicato per gestire gli eventi, il Volontariato e la modulistica d’emergenza. Quindi

gestisce l’anagrafica degli ospiti, la stampa automatica di tesserini di identificazione,

le risorse, il personale di supporto. Si occupa della creazione e della gestione

dell’albo delle organizzazioni di Volontariato a livello Provinciale e/o Regionale.

All’interno dell’archivio esiste poi la possibilità di ricercare ogni associazione

secondo varie chiavi di filtro. Per ogni associazione esiste una completa anagrafe che

garantisce il coordinatore sulla conoscenza dei volontari; infatti, questi sono

identificati da una scheda con vari dati. E’ presente un completo archivio per la

gestione delle risorse disponibili, che permette di conoscere quelle esistenti e

- 43 -

verificarle tecnicamente, di identificare chi le detiene e le necessità di manutenzione.

Questa utilità può essere necessaria in caso di emergenza per la possibilità di ricerca

e risorse umane e materiali.

Inoltre permette di assimilare i più diffusi formati grafici esistenti dando la

disponibilità di utilizzare basi cartografiche. È disponibile l’inserimento di dati

direttamente dalla cartografia, referenziando automaticamente tutte le informazioni,

come ad esempio i tematismi, le reti tecnologiche, le zone a rischio, gli eventi, le

strutture, le località geografiche.

Un’altra applicazione sviluppata e denominata "SIRIO GPS" è un programma

software che gestisce una flotta di automezzi di qualsiasi tipo collegati ad una

centrale operativa e monitorati tramite sistema di radiolocalizzazione satellitare GPS.

In particolare il programma è strutturato per gestire la localizzazione dell’automezzo

più vicino ad una località, la localizzazione di un veicolo, la localizzazione di tutti i

mezzi. Ogni automezzo monitorato è identificato da una scheda che permette di

conoscerne ad esempio: il modello, il personale assegnatario del mezzo, la targa, un

eventuale numero automezzo interno, la funzione (ad es. trasporto prodotto grezzo),

l’eventuale codice di chiamata selettiva. Le località geografiche sono inserite e

georeferenziate direttamente dal supporto cartografico.

4.3 Considerazioni e confronti

Queste sono solo alcune della applicazioni esistenti sul mercato mirate al

supporto alle operazioni della Protezione Civile.

Queste soluzioni software sono simili nelle funzionalità al sistema da noi

sviluppato. Anch’esse permettono la visualizzazione, condivisione e gestione di

informazioni sia alfanumeriche che grafiche.

Il primo sistema analizzato gestisce funzionalità di reperimento tramite Sms o

telefonia di ultima generazione, ma per il momento la nostra applicazione non ne

sente l’esigenza.

Tra le soluzioni proposte nel secondo paragrafo si scopre l’utilizzo di

tecnologie per la localizzazione dei mezzi. Questo tipo di funzionalità richiede

- 44 -

particolari tecnologie, ma l’utilità che può esserci non risulta essere molto rilevante e

di uso comune in particolare per il Corpo dei Vigili del Fuoco. Il suo utilizzo non

risolve problemi quotidiani, ma potrebbe essere interessante solamente in particolari

situazioni. Tenendo conto anche della complessità della tecnologie utilizzate si

dovrebbe valutarne l’effettiva utilità calcolandone i reali costi/vantaggi apportati da

questo sistema all’operatività professionale. Ad esempio se è utile conoscere l’esatta

ubicazione di tutte le ambulanze operative contemporaneamente su un territorio

esteso come quello provinciale, al fine di dirottare una di queste sul luogo di un

incidente stradale, questa evenienza non si verifica in genere nell’attività dei Vigili

del Fuoco in quanto nel 99% dei casi i mezzi intervenuti sono in numero limitato.

Ancora meno frequentemente si ha contemporaneità di interventi tipo incendi o

simili con conseguente necessità di dirottare le squadre intervenute. E’ ovvio cioè,

che l’esatta ubicazione dei mezzi usciti per simili interventi è ben conosciuta dal

coordinatore delle operazioni che si trova in sede. Sono comunque attualmente in

progettazione metodi che attraverso dei comandi presenti sui mezzi permettono di

inviare al database dei dati tra cui la localizzazione del mezzo per riuscire a creare

della documentazione durante l’evento. Se per esempio durante un intervento parte

un veicolo, selezionando un comando è possibile memorizzare nel database l’ora e i

dati identificativi del mezzo in partenza. Una volta che la squadra ha raggiunto il

luogo dove prestare il servizio, attraverso un altro comando sarà possibile inviare e

memorizzare i dati relativi all’arrivo sul posto del mezzo. Otteniamo in questo modo

una procedura che diminuisce i tempi di comunicazione con la sala operativa dando

maggior spazio alle operazioni di soccorso.

4.4 Discussione

La caratteristica che differenzia maggiormente la applicazione descritta in

questa tesi rispetto a quelle in commercio è che essendo nata, analizzata e infine

sviluppata e realizzata direttamente all’interno della struttura operativa in cui essa

viene utilizzata, essa risulta più corrispondente alle reali esigenze operative dei Vigili

del Fuoco di Trento. La personalizzazione spinta del sistema unita ad una flessibilità

- 45 -

permette la perfetta integrazione del nostro software con il resto dei pacchetti

operativi. I database sono condivisi e non ridondanti nelle informazioni che risiedono

in copia unica. Sono stati raccolti i dati strettamente necessari al settore operativo

interventistico rendendo quindi il sistema snello e leggero.

Questa caratteristica rende particolarmente interessante l’applicazione per il

fatto che essendo costruita utilizzando il sistema informativo interno essa si integra

perfettamente condividendo i componenti che la compongono con le altre

applicazioni utilizzate in rete all’interno della sede centrale dei Vigili del Fuoco di

Trento. Infatti anche gli altri software utilizzati dal personale interno, sia operativo

che amministrativo, sono stati realizzati utilizzando risorse già implementate nel

software descritto. Esempi rilevanti e immediati di risorse riutilizzate sono oltre al

database delle località, quello del personale, degli automezzi, delle attrezzature.

- 46 -

Capitolo 5

Conclusioni

Il progetto nasce come esplicita esigenza interna del Corpo Permanente dei

Vigili del Fuoco. Ha inizio dall’analisi dalle esigenze del personale stesso, conscio di

una nuova e urgente necessità di miglioramento della propria attività professionale.

Tale esigenza, inizialmente espressa in modo poco formale e preciso, si riferisce alla

gestione delle emergenze e in particolar modo alle sue fasi iniziali più concitate, ove

maggiore è il rischio di errori ed inefficienze. Dai requisiti iniziali informali espressi

indipendentemente dal sistema informativo esistente si è riusciti a passare a una

specifica ingegneristica meglio definita. Dapprima vengono studiate le esigenze reali

attraverso le interviste al personale operativo. In contemporanea avviene l'analisi

dettagliata delle modalità operative così come esse si svolgono in assenza degli

strumenti richiesti. In tal modo si riescono a raccogliere tutte le informazioni

necessarie per individuare precisamente i target che si vogliono ottenere ed i requisiti

principali che il sistema dovrà possedere al fine di fornire quelle determinate

prestazioni.

Lo studio che ha portato all’implementazione dell’applicazione descritta in

questa tesi è stato curato in modo preciso e attento in tutti i dettagli. Ciò ha permesso

di ottenere come risultato un’applicazione che, a detta degli utilizzatori stessi, risulta

essere snella ed efficace. Il programma installato nelle unità operative del Servizio

Antincendi ha riscontrato un immediato successo. Il punto di forza dell’applicativo e’

la semplicità di utilizzo nonostante la complessità implementativa delle funzionalità

proposte, che pur restando trasparenti sono potenti senza con questo appesantire

l'interfaccia o creare sconcerto negli operatori non informatici. Caratteristica queste

che non sconvolgono la normale attività dei Vigili del Fuoco permettendo loro rapide

risposte assieme ad un'estrema facilità di utilizzo durante le emergenze. La

semplicità delle strutture utilizzate in questo caso, non sminuisce il risultato

professionale ottenuto, ma al contrario apporta un indiscutibile miglioramento e reali

- 47 -

vantaggi di efficienza operativa negli interventi richiesti.

Lo scopo e la filosofia seguiti fin dall'inizio hanno evitato di costruire un

software troppo pretenzioso e pesante che sviluppasse funzionalità perfette dal punto

di vista informatico, ma di raro o complesso utilizzo. L'uovo di Colombo è stato

quello di partire umilmente dalle reali e concrete esigenze del personale operativo e

tenendo costantemente presente che se così non si operava, il rischio sarebbe stato un

fallimento nell'introduzione del nuovo software. Nel momento di necessità il

personale, non avendo familiarità con gli strumenti informatici per i quali da sempre

vi è una istintiva diffidenza, avrebbe potuto reagire in modo controproducente e ne

avrebbe rilevato un troppo difficile utilizzo. Troppo spesso nel passato grossi ed

inutili pacchetti distribuiti dal Ministero o frutto di acquisti affrettati hanno avuto vita

breve. Nel tempo anche la applicazione presentata in questa tesi si è evoluta

arricchendosi di nuove e più complesse funzionalità, ma essendo ormai partiti bene i

pericoli erano superati. Tali innovazioni sono state comunque implementate in modo

graduale e sempre seguendo il personale che piano cresceva assieme all'applicativo

mantenendone una completa accettazione.

Attualmente il programma è in distribuzione presso tutti i Corpi Volontari

dei Vigili del Fuoco situati nei vari comuni della provincia di Trento. Da un primo

riscontro si è avuta la conferma di quanto sopra, appurando che il pacchetto veniva

accettato ed utilizzato con soddisfazione anche dal personale volontario. Dalle

statistiche di accesso al database si è riscontrato un significativo numero di accessi ed

anche l'aggiornamento dati risulta continuo ed esatto nelle regole di immissione. Ne

consegue che dopo l’istruzione iniziale fornita agli utenti abilitati e la prima prova

concreta sul campo, il feedback che abbiamo ottenuto finora risulta senz'altro

positivo. L’applicazione è stata accettata da tutti gli utenti e ne è stato avviato

l'immediato utilizzo. Si può desumerne quindi una loro prima soddisfazione e la

convinzione che il programma sia apparso loro utile e interessante.

- 48 -

Appendice

I Vigili del Fuoco

“

1. La struttura

La struttura dei Vigili del Fuoco si compone di vari elementi (figura n. 1):

• i Corpi Permanenti dei Vigili del Fuoco:

• I Corpi Volontari dei Vigili del Fuoco

• Le Unioni provinciali e distrettuali o comprensoriali dei Vigili del

Fuoco.

• Le Scuole Provinciali Antincendi: i compiti di tali strutture per legge

comprendono la formazione, qualificazione, aggiornamento ed

addestramento del personale permanente e volontario dei servizi

antincendi ed ad altre organizzazioni aventi per scopo il soccorso e la

protezione civile e la predisposizione di programmi didattici e

informativi rivolti alla comunità provinciale ed in particolare alle

scuole di ogni ordine e grado. Il Corpo docente conta oltre un

centinaio di soggetti, diversamente abilitati per livello di docenza e

argomentazioni.

• Le Squadre Aziendali.

Il Corpo Nazionale Vigili del Fuoco è la prima e fondamentale forza della

Protezione Civile Italiana, ha per scopo principale di prestare il soccorso immediato

a persone, animali e proprietà” (RDL 333 del 27/02/1939 - Legge n° 1570)

- 49 -

Figura 1. Struttura del servizio Antincendi e Protezione Civile

Il Corpo Permanente, comprende circa 170 unità esperte e costituisce le

"colonne mobili", formato da gruppi organizzati e appositamente attrezzati, a cui

spetta il soccorso alle popolazioni colpite e il ripristino dei servizi essenziali. Sono

presenti in questo Corpo squadre specializzate, per interventi in caso di situazioni

particolari, ne sono un esempio il nucleo elicotteri, il nucleo sommozzatori,

audioriparatori, ecc. organizzati in appositi turni di reperibilità che assicurano un

supporto specifico e continuo negli interventi.

Il Trentino è suddiviso in 223 comuni; per obbligo di legge ogni comune deve

istituire almeno un Corpo di Vigili del Fuoco volontari, infatti, vi sono 293 Corpi per

complessivi 6.100 Vigili del Fuoco volontari in servizio attivo.

I Corpi sono organizzati a livello distrettuale in Unioni, le Unioni distrettuali

sono 13 ed a capo di ogni Unione c’è un ispettore, a loro volta loro formano la

Federazione provinciale dei Corpi Vigili del Fuoco Volontari. E’ compito dei Corpi

provvedere alla sicurezza delle persone, alla protezione delle cose, alla prevenzione,

ed al combattimento dell’evento calamitoso. Ogni Corpo opera principalmente in

ambito comunale dove è pianamente responsabile del servizio. A seconda del tipo e

- 50 -

della dimensione dell’evento, i Corpi intervengono in modo singolo o collettivo a

livello distrettuale o provinciale; in tali casi partecipa anche il Corpo professionale di

Trento che ha la competenza sulla città di Trento. Le chiamate del soccorso fanno

riferimento alla centrale del Corpo permanente che smista ai vari Corpi dotati di

adeguata strumentazione attraverso una rete radio provinciale. Il servizio così

strutturato garantisce una prontezza operativa nell’arco di pochi minuti dalla

chiamata di soccorso, anche nelle zone periferiche del territorio Trentino. I Corpi

inoltre sono in stretta collaborazione con tutte le forze del soccorso operanti.

Tutte queste componenti sono complementari fra loro e, ovviamente

nell’ambito della propria rispettiva competenza territoriale, sono essenziali ad un

corretto sviluppo delle attività ad esse attribuite [15].

2. Le competenze

Secondo la Legge Provinciale è compito di tale struttura provvedere alla

prevenzione e all’estinzione degli incendi, di provvedere alla protezione, al soccorso

e all’assistenza in favore delle popolazioni colpite da calamità pubbliche, curare la

gestione e la manutenzione delle reti operanti sulle frequenze assegnate ai Vigili del

Fuoco, predisporre ed attuare, coordinandosi con gli altri servizi interessati, gli

interventi di competenza per l’estinzione d’incendi. In pratica le attività rilevanti del

Servizio Antincendi e Protezione Civile si possono suddividere nelle seguenti

categorie [14]:

• Attività d’intervento qualora si verifichino delle situazioni di emergenza, in

caso di calamità naturali o disastri. In questo caso il Corpo Permanente

opererà in collaborazione con i Vigili del fuoco volontari e le altre

componenti della Protezione Civile.

• Valutazione di situazioni di pericolo ed esecuzione di perizie.

• Esame di progetti di prevenzione incendi e sopralluoghi di verifica: i controlli

di prevenzione incendi permettono ai Vigili del Fuoco di conoscere e

preparare il terreno sul quale poter misurarsi in caso di incendio ma

soprattutto è utili per garantire al cittadino un accettabile livello di sicurezza

- 51 -

antincendio secondo le norme vigenti.

• Ricezione di richieste d’interventi e diffusione allarmi attraverso una sala

operativa che, raccolti, li trasmette ai soggetti competenti per il soccorso.

• Coordinamento con i vari gruppi Volontari vigilandone l’organizzazione e

l’andamento. Infatti risulta evidente che il Corpo Permanente sia il naturale

punto di riferimento tecnico-organizzativo per i Vigili del fuoco del Trentino,

e per tutte le altre forze del volontariato impegnate nel settore della

Protezione Civile, ma nella struttura della Protezione Civile il lavoro dei

Volontari è fondamentale, dato dalla struttura del territorio dove l’intervento

del Corpo Permanente potrebbe richiedere molto tempo.

• Gestione di un magazzino antincendio, mettendo a disposizione le proprie

competenze per la manutenzione e l’acquisto di mezzi ed attrezzature per i

Corpi dei Vigili del Fuoco Volontari: in questi ultimi anni i diversi gruppi dei

Vigili del Fuoco si sono sempre più adeguati in strutture, uomini e mezzi per

fronteggiare le più diversificate situazioni di rischio. La sua organizzazione

tende a garantire l’espletamento, nella massima efficienza, dei servizi

istituzionali richiesti dalla comunità.

3. Le Attrezzature

Al fine di poter intervenire in modo rapido i Corpi sono stati dotati

d’attrezzature e automezzi in relazione alle tipologie e alla specificità del servizio e

più dettagliatamente:

• dotazioni d’automezzi e attrezzature base per ogni corpo, adatto alle esigenze

dell’area di rispettiva competenza.

• dotazione d’automezzi e attrezzature alle sedi distrettuali come centri di

appoggio immediato

• dotazione d’automezzi e attrezzature alle Unioni distrettuali in caso di

utilizzo in vaste aree di intervento

• dotazione d’automezzi e attrezzature provinciali (Corpo Permanente e

Protezione Civile) in caso di calamità provinciali e nazionali.

- 52 -

4. Modo di operare: gli interventi.

Gli interventi sono gestiti all’interno della Centrale Radiotelefonica del Corpo

Permanente dei Vigili del Fuoco dove vengono ricevute le chiamate di soccorso 24

ore su 24, sia attraverso linee telefoniche che tramite apparati radio che ricevono

allarmi automatici trasmessi da rilevatori posizionati nelle zone a rischio in contatto

con i principali centri di chiamata della Provincia e del Corpo Nazionale dei Vigili

del Fuoco.

Compito della Centrale Operativa è di svolgere la funzione di centro raccolta

informazioni e controllo della situazione ed avviare eventuali segnali d’allarme

distinti secondo la gravità dell’intervento [14].

La gestione delle chiamate è affidata a personale appositamente qualificato

che provvede all’invio delle squadre predisposte nei piani d’intervento e

all’eventuale estensione dell’allarme a altri elementi rilevanti nel soccorso come i

Vigili del Fuoco Volontari, il Soccorso Sanitario, il Soccorso Alpino, ecc. La

chiamata avviene tramite selettive utilizzando sistemi informatici e specifici

programmi software gestiti direttamente dal laboratorio di informatica e dal

laboratorio radio del Corpo Vigili del Fuoco permanente di Trento.

- 53 -

Bibliografia

[01] Visual Basic 6: programmazione client/server

Autori: Michael Mac Donald – Kurt Cagle

Editore: McGraw-Hill

Anno: 1999

[02] Sviluppare componenti con Microsoft Visual Basic 6.0

Autori: Guy Eddon –Henry Eddon

Editore: Mondatori Informatica

Anno: 1998

[03] Windows 2000 Active Directory

Autore: Edgard Brovick – Doug Hauger – William C. Wade

Editore: Apogeo

Anno: 2000

[04] Microsoft SQL Server Training

Editore: Mondadori Informatica

Anno: 1998

[05] Citrix Metaframe XP for Windows Administrator

Manuale utente

Anno: 2001

[06] Gestione e soluzione dei problemi di rete

Autore: Feldman Jonathan

Editore: Tecniche Nuove

Anno: 2003

- 54 -

Riviste e Articoli

[07] Intelligent Mobile Crisis Response Systems

Autori: Yufei Yuan - DetlorBrian

Rivista: Communication of the Acm

Numero: No. 2 - Febbraio 2005

[08] Rivista “La Protezione Civile Italiana”

Editore: Edizioni Nazionali

Numero: No. 8 – ottobre 2004

Siti Web

[09] http://freeasp.html.it

[10] http://www.itportal.it

[11] http://www.celesta.it

[12] http://www.zerobyte.it

[13] http://www.esriitalia.it

[14] http://www.vigilifuoco.it

[15] http://www.protezionecivile.tn.it