Politecnico di Milano
Facolta di Ingegneria
Corso di Laurea Specialistica in Ingegneria Informatica
Dipartimento di Elettronica e Informazione
UN APPROCCIO ALLA GESTIONE DELRISCHIO IN AREE DI LAVORO
Relatore: Tesi di laurea di:
Prof.ssa Mariagrazia Fugini Gianluca Tomasino
Matricola 674017
Anno Accademico 2009/2010
A Chiara
e ai miei genitori
Indice
1 Introduzione 1
1.1 La Gestione del Rischio . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Un Quadro Normativo . . . . . . . . . . . . . . . . . . . . . . 4
1.3 I Dispositivi di Protezione Individuale . . . . . . . . . . . . . 5
1.4 Obiettivo della tesi . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Un Approccio alla Gestione del Rischio 9
2.1 Caratteristiche Generali del Sistema di Gestione del Rischio . 9
2.2 Architettura Generale: il Ciclo mape . . . . . . . . . . . . . . 10
2.2.1 Le Fasi del Ciclo mape . . . . . . . . . . . . . . . . . . 12
2.2.2 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.3 Analyzing . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.4 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.5 Executing . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Modello delle Entita . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1 L’entita Entity . . . . . . . . . . . . . . . . . . . . . . 16
2.3.2 L’entita Environment . . . . . . . . . . . . . . . . . . . 16
2.3.3 L’entita Person . . . . . . . . . . . . . . . . . . . . . . 18
i
INDICE ii
2.3.4 L’entita Tool . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.5 L’entita Machinery . . . . . . . . . . . . . . . . . . . . 20
2.3.6 L’entita InformativeDevice . . . . . . . . . . . . . . . 21
2.3.7 L’entita ProtectionElement . . . . . . . . . . . . . . . 21
3 Modello Computazionale del Rischio 23
3.1 Definizione di Rischio . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Determinazione del Rischio d’Ambiente . . . . . . . . . . . . . 24
3.2.1 La Funzione di Rischio . . . . . . . . . . . . . . . . . . 25
3.2.2 La Generazione del Rischio . . . . . . . . . . . . . . . . 30
3.2.3 La Protezione dal Rischio con Dispositivi d’Ambiente . 32
3.2.4 La Mappa del Rischio Ambientale . . . . . . . . . . . . 33
3.3 Determinazione del Rischio Individuale . . . . . . . . . . . . . 34
3.3.1 Il Rischio Individuale . . . . . . . . . . . . . . . . . . . 34
3.3.2 La Protezione Individuale . . . . . . . . . . . . . . . . 35
3.3.3 Il Livello di Rischio Individuale . . . . . . . . . . . . . 36
3.4 Strategie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4 Architettura del prototipo 40
4.1 Funzionalita del Prototipo . . . . . . . . . . . . . . . . . . . . 40
4.2 Struttura del Prototipo . . . . . . . . . . . . . . . . . . . . . . 41
4.3 Parte Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3.1 Architettura del Modello delle Entita . . . . . . . . . . 45
4.3.2 Architettura della Fase di Monitoring . . . . . . . . . . 49
4.3.3 Architettura delle Fasi di Analyzing e Planning . . . . 52
INDICE iii
4.3.4 Architettura del Parser xml per la Definizione del-
l’Ambiente . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4 Parte Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.4.1 Struttura dei Package dell’Interfaccia Grafica . . . . . . 57
4.4.2 Struttura delle Classi dell’Interfaccia Grafica . . . . . . 58
4.5 Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.5.1 Struttura delle Servlet di Comunicazione con i Sensori 61
4.5.2 Simulatore . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.6 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . 62
4.6.1 Fase Monitoring : Lettura di un Parametro Ambientale 63
4.6.2 Fase Analyzing : Verifica Situazioni di Rischio . . . . . 64
4.6.3 Fase di Planning : Scelta della Strategia . . . . . . . . . 65
4.6.4 Calcolo della Mappa di Rischio . . . . . . . . . . . . . 66
4.6.5 Aggiornamento dell’Interfaccia Grafica . . . . . . . . . 67
5 Esempi 70
5.1 Monitoring dell’Ambiente . . . . . . . . . . . . . . . . . . . . 70
5.2 Simulazione: Una Fuga di Gas . . . . . . . . . . . . . . . . . . 73
5.2.1 Strategia . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6 Conclusioni 77
6.1 Sviluppi Futuri . . . . . . . . . . . . . . . . . . . . . . . . . . 78
A Librerie utilizzate 80
A.1 Google Web Toolkit . . . . . . . . . . . . . . . . . . . . . . . . 80
INDICE iv
A.2 Smart gwt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
A.3 Apache Digester - Commons . . . . . . . . . . . . . . . . . . . 82
Elenco delle figure
2.1 Architettura del Sistema di Gestione del Rischio [Fugini et al., 2011] 11
2.2 Modello delle Entita per il Sistema di Gestione del Rischio . . 17
3.1 Curva della distribuzione gaussiana, con il massimo in (0,1) . . 27
3.2 Somma di elementi di rischio. La linea verde e data dalla
somma delle altre curve gaussiane . . . . . . . . . . . . . . . . 29
4.1 Diagramma uml dei componenti del sistema . . . . . . . . . . 43
4.2 Diagramma delle classi del modello del modello delle entita . . 46
4.3 Diagramma delle classi necessarie alla realizzazione della fase
di monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.4 Diagramma delle classi della fase di analyzing e planning . . . 53
4.5 Diagramma delle classi per il parser del file xml di definizione
dell’ambiente . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.6 Diagramma dei Package dell’interfaccia utente . . . . . . . . . 58
4.7 Diagramma delle classi dell’interfaccia utente . . . . . . . . . . 59
4.8 Diagramma delle classi dell’area Environment . . . . . . . . . 61
4.9 Sequence Diagram della lettura di un parametro ambientale . 63
4.10 Sequence Diagram per il riconoscimento di situazioni di rischio 64
v
ELENCO DELLE FIGURE vi
4.11 Sequence Diagram per la scelta della strategia . . . . . . . . . 65
4.12 Sequence Diagram per il calcolo della mappa di rischio . . . . 67
4.13 Sequence Diagram per l’aggiornamento dell’interfaccia grafica 68
5.1 Interfaccia grafica del prototipo . . . . . . . . . . . . . . . . . 71
5.2 Mappa dell’ambiente e scheda del lavoratore . . . . . . . . . . 71
5.3 Evoluzione della mappa del rischio . . . . . . . . . . . . . . . 72
5.4 Situazione iniziale nella simulazione di una fuga di gas . . . . 73
5.5 Evoluzione della mappa del rischio nella simulazione di una
fuga di gas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.6 Situazione finale per la simulazione di una fuga di gas . . . . . 74
5.7 Scheda del lavoratore “Mario Rossi” . . . . . . . . . . . . . . . 75
5.8 Finestra della strategia mostrata dal prototipo nella simula-
zione di una fuga di gas . . . . . . . . . . . . . . . . . . . . . 76
A.1 Architettura delle classi per la comunicazione con il server . . 81
A.2 Esempio di una lista di dati creata con la libreria SmartGWT 82
Elenco delle tabelle
1.1 Il bilancio infortunistico 2009 (Fonte: INAIL Osservatorio
Statistico Infortuni) . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Proprieta degli elementi del rischio . . . . . . . . . . . . . . . 24
3.2 Esempi di combinazioni tra situazioni di rischio, strategie ap-
plicabili e condizioni di selezione che il sistema puo gestire . . 37
3.3 Esempio di strategie applicabili, in base al contesto . . . . . . 38
vii
Riassunto
Ogni anno in Italia piu di mille persone perdono la vita durante lo svolgimento
dell’attivita lavorativa e ben maggiore e il numero di coloro che rimangono
invalidi piu o meno gravemente. L’alto numero di incidenti sul luogo di lavoro
richiede quindi l’introduzione di tutta una serie di misure di prevenzione che
devono essere adottate dai lavoratori stessi. L’obiettivo di questa Tesi e quello
di realizzare un prototipo software di un Sistema per la Gestione del Rischio
in un ambiente di lavoro.
Nel capitolo 1 verra illustrata la normativa vigente in Italia a tutela della
sicurezza dei lavoratori e saranno descritti i dispositivi ambientali in grado
di fornire informazioni sull’ambiente di lavoro viene poi illustrato lo scopo e
il contenuto di questo lavoro di tesi.
Nel capitolo 2 viene introdotta la soluzione proposta in questo lavoro per
la gestione del rischio tramite la descrizione di un sistema informativo in
grado di utilizzare una rete di sensori al fine di rilevare e segnalare situazioni
di pericolo in un ambiente lavorativo.
Nel capitolo 3 viene presentato il modello computazione usato dal sistema
per il calcolo del livello di rischio, introducendo prima il concetto di rischio
e descrivendo come viene calcolata l’influenza di ogni singola entita nella
definizione del rischio.
Nel capitolo 4 viene illustrato il prototipo del Sistema per la Gestione del
Rischio da un punto di vista architetturale. Viene descritta la tipologia di
applicazione sviluppata e i livelli logici che la compongono, vengono descrit-
te le principali architetture implementate per ogni livello logico e vengono
viii
ELENCO DELLE TABELLE ix
mostrate le interazioni tra gli oggetti.
Nel capitolo 5 vengono mostrati alcuni esempi di utilizzo del prototipo.
In particolare viene simulata un’attivita lavorativa nell’ambito di un cantiere
o area di lavoro chiusa, evidenziando le informazioni che il prototipo rileva
per fornirle all’operatore. In una seconda simulazione viene mostrato come
il prototipo rileva e fornisce le informazioni necessarie per far fronte ad una
fuga di gas.
Segue il capitolo 6 in cui vengono mostrati alcuni utilizzi del prototipo e
indicati alcuni possibili sviluppi futuri.
La Tesi si conclude con l’appendice A in cui vengono descritte le librerie
utilizzate per lo sviluppo del prototipo.
Capitolo 1
Introduzione
L’attivita lavorativa comune prevede lo svolgimento di un insieme di compiti
individuali, che dipende dalla mansione del singolo. Nell’ambiente di lavoro,
piu e industriale l’attivita aziendale, maggiore e il rischio individuale a cui i
lavoratori sono soggetti. L’attivita svolta, per esempio, in un cantiere edile
oppure in una officina meccanica e estremamente piu rischiosa (in termini di
potenziali incidenti alla persona) dell’attivita svolta in un ufficio.
Ogni anno in Italia piu di mille persone perdono la vita durante lo svolgi-
mento dell’attivita lavorativa e ben maggiore e il numero di coloro che riman-
gono invalidi piu o meno gravemente. Nel 2009 si sono verificati 790.000 in-
fortuni e le morti accertate, imputabili al lavoro, sono state 1.050, la maggior
parte delle quali (767 pari al 73%) sono avvenute in all’interno di ambienti
di lavoro ordinario come fabbriche, cantieri, ecc. [INAIL, 2010].
Molti degli ambienti industriali in cui, statisticamente, si verificano in-
cidenti in numerosita significativa, sono connotati da elementi sistematica-
mente riconoscibili come sorgenti di rischio. Rilevando analiticamente questo
tipo di informazioni ambientali e comportamentali e possibile inquadrare il
problema con lo scopo di minimizzare i danni alle persone e agli impianti.
Molti degli incidenti che accadono nei luoghi di lavoro sono in genere
preceduti da eventi che possono essere interpretati come indicatori di poten-
ziali situazioni di rischio. Questi indicatori possono essere interpretati ed
1
CAPITOLO 1. INTRODUZIONE 2
opportunamente letti come segnali e, di conseguenza, e possibile affrontare
le situazioni di rischio adottando opportune strategie preventive. in questo
modo e possibile, in molti casi, evitare che le situazioni degenerino in veri e
propri incidenti. Tuttavia, in determinate circostanze, l’incidente non e evi-
tabile, perche non e preceduto da “pattern” di rischio identificabili a priori.
Anche in questi casi, puo risultare opportuno applicare delle strategie cor-
rettive. L’incidente stesso puo rappresentare, infatti, l’indicatore di quella
ulteriore situazione di rischio che si presenterebbe qualora, non gestito, il
danno dovuto all’incidente si propagasse.
I progressi fatti dall’IT, dalle telecomunicazioni, dalle reti di sensori e
dai dispositivi indossabili possono aiutare nell’identificazione delle situazioni
di rischio che in genere precedono gli incidenti sul lavoro, in questo modo
possono essere gestite in tempo per cercare di prevenire o limitare eventuali
danni all’ambiente e alle persone.
1.1 La Gestione del Rischio
Le leggi esistenti prevedono l’impiego di determinati presidi ambientali (come
ad esempio il “salvavita”che e un dispositivo che protegge l’impianto elettrico
da sovratensioni) e l’uso di adeguati indumenti a prevenzione degli incidenti
(come ad esempio l’utilizzo di giacche, scarpe o occhiali protettivi). Questi
dispositivi possono essere considerati elementi di sicurezza “passiva” poiche
sono in grado di prevenire e minimizzare le conseguenze di un evento rischio-
so, nel momento stesso in cui avviene. L’utilizzo degli occhiali protettivi, per
esempio, permette la salvaguardia degli occhi nel momento in cui avviene
un evento di generazione di schegge o simili, durante determinate attivita
lavorative industriali. Altro esempio, l’adozione di un dispositivo elettrico
“salvavita” consente di confinare e impedire il propagarsi della corrente elet-
trica sulle linee e sulle parti metalliche esposte a un sovraccarico o a un“corto
circuito”. In generale la caratteristica di questo tipo di dispositivi e quella di
proteggere il lavoratore da eventuali pericoli che potrebbero verificarsi dopo
che un evento potenzialmente dannoso e gia accaduto.
CAPITOLO 1. INTRODUZIONE 3
Una nuova generazione di dispositivi come le reti di sensori o i dispositivi
indossabili permettono di identificare ed evidenziare le situazioni di rischio
prima che avvengano eventi potenzialmente dannosi [Fugini et al., 2009b]. Si
ha infatti la possibilita di analizzare l’ambiente, il contesto, gli atteggiamenti
e lo stato di utilizzo di macchinari in modo da non delegare esclusivamente
al lavoratore le valutazioni di rischio. Cio permette di abbattere gli impatti
di valutazioni individuali superficiali dovute alla fretta, alla distrazione o al-
l’impossibilita di cogliere e intercettare determinati eventi esterni. E infatti
possibile utilizzare le reti di sensori e dispositivi indossabili per monitorare,
rilevare e reagire a situazioni di rischio in ambienti di lavoro. Utilizzando op-
portunamente le reti di sensori e i dispositivi indossabili e possibile realizzare
un sistema distribuito che comunichi i dati ambientali relativi a lavoratori e
macchinari tramite un insieme di nodi interconnessi. Questo tipo di reti di
sensori sono in grado di rilevare determinati eventi d’ambiente, evidenziando
le situazioni di rischio [Fugini et al., 2010].
La continua crescita delle richieste sul mercato di reti di sensori indossa-
bili necessarie per segnalare situazioni di pericolo, comprova la riconosciuta
efficacia di questi dispositivi, la cui diffusione e in crescita.
I sensori rilevano sul campo una moltitudine di dati relative all’ambiente,
ai lavoratori e ai macchinari che, tramite uno strato applicativo software
dedicato, possono essere raccolti, catalogati e gestiti. Opportuni algoritmi
permettono di trarne indicazioni efficaci per la segnalazione di potenziali
situazioni di rischio.
L’insieme di tutte queste tecnologie, sensori, dispositivi e strato software
viene definito Sistema per la Gestione del Rischio, cioe un sistema informa-
tivo basato sui sensori d’ambiente e sui dispositivi indossabili utilizzati dalle
persone, finalizzato all’identificazione della posizione dei macchinari e alla
rilevazione di eventi rischiosi per la persona. Piu in generale, un Sistema per
la Gestione del Rischio e costituito da un insieme di servizi informatici che
permettono di gestire il livello di rischio dell’ambiente e delle persone.
CAPITOLO 1. INTRODUZIONE 4
Modalita di evento Infortuni Casi mortali
In occasione di lavoro 696.863 829In itinere 93.137 283Totale 790.000 1.050
Tabella 1.1: Il bilancio infortunistico 2009 (Fonte: INAIL OsservatorioStatistico Infortuni)
1.2 Un Quadro Normativo
L’alto numero di incidenti sul luogo di lavoro richiede quindi l’introduzione
di tutta una serie di misure di prevenzione e protezione (tecniche, organizza-
tive e procedurali), che devono essere adottate dal datore di lavoro, dai suoi
collaboratori (i dirigenti e i preposti) e dai lavoratori stessi.
Le misure di tutela della salute e della sicurezza dei lavoratori hanno il
fine di migliorare le condizioni di lavoro, ridurre la possibilita di infortuni ai
dipendenti dell’azienda, agli altri lavoratori, ai collaboratori esterni (subcon-
traenti) ed a quanti si trovano, anche occasionalmente, all’interno dell’Azien-
da. Misure di igiene e tutela della salute devono essere adottate al fine di
proteggere il lavoratore da possibili danni alla salute e malattie professionali,
nonche preservare la popolazione generale e l’ambiente.
In Italia, la salute e la sicurezza sul lavoro sono regolamentate dal D. Lgs.
81/2008 (conosciuto come Testo Unico sulla Sicurezza del Lavoro), entrato in
vigore il 15 maggio 2008. Questo decreto, che ha avuto molti precedenti nor-
mativi storici (risalenti al 1955 e 1956) ed altri piu recenti (D. Lgs. 626/1994),
recepisce in Italia le direttive europee in materia di tutela della sicurezza e
della salute dei lavoratori, coordinandole in un unico testo normativo che
prevede anche specifiche sanzioni a carico degli inadempienti.
Gli artt. 17 e 28 del testo Unico sulla Sicurezza del Lavoro prevedono
che in tutte le aziende pubbliche e private venga predisposto un apposi-
to documento di valutazione dei rischi per i lavoratori, che ricade sotto la
responsabilita indelegabile del datore di lavoro (il quale puo farsi eventual-
mente supportare dalla consulenza di professionisti esperti della materia)
CAPITOLO 1. INTRODUZIONE 5
[Wikipedia, 2011d].
In particolare l’articolo 28 del Testo Unico della Sicurezza sul Lavoro prevede
che il documento di valutazione dei rischi abbia i seguenti contenuti:
• Relazione sulla valutazione dei rischi, che contiene l’indicazione
di tutti i rischi per la sicurezza e la salute durante l’attivita lavorativa.
Questa analisi e in genere divisa secondo piu fattori di rischio, ad esem-
pio: ambienti di lavoro, macchine, attrezzature, agenti chimici, fisici e
biologici, aspetti organizzativi e gestionali, ecc.
• Indicazione delle misure di prevenzione e di protezione attuate
al fine di eliminare i rischi individuati, o nel caso in cui non
sia possibile eliminarli completamente, ridurre il rischio ad un livello
accettabile.
• Elenco dei dispositivi di protezione individuale, che indica tut-
ti gli indumenti di protezione che i lavoratori indossano al fine della
sicurezza individuale (ad esempio: calzature antinfortunistiche, casco,
guanti, mascherine protettive, ecc.)
• Programma delle misure ritenute opportune per garantire il
miglioramento nel tempo dei livelli di sicurezza, in cui si indi-
cano tutte quelle misure che devono essere intraprese al fine di miglio-
rare i livelli di sicurezza nel tempo (manutenzioni, verifiche, attivita di
informazione e formazione dei lavoratori ecc.).
1.3 I Dispositivi di Protezione Individuale
Per alcuni rischi, quali ad esempio i rischi da agenti fisici (rumore, vibrazioni,
radiazioni), agenti chimici, agenti cancerogeni, movimentazione manuale dei
carichi, ecc. sono specificamente individuate nel Testo Unico della Sicurezza
sul Lavoro, le disposizioni inerenti la valutazione preventiva, gli eventuali
limiti all’esposizione dei lavoratori e le specifiche misure di prevenzione e
protezione, in relazione all’esposizione dei soggetti.
CAPITOLO 1. INTRODUZIONE 6
Le metodologie di valutazione dei rischi sono basate su metodi ingegne-
ristici di scienza della sicurezza, scienza delle costruzioni, sicurezza elettrica
e sull’impiego dei piu idonei dispositivi di sicurezza all’interno dell’edificio
aziendale o del luogo di attivita. Si tratta dei tipici dispositivi di sicurezza,
come, ad esempio, quelli rivolti alla prevenzione degli incendi (quali estinto-
ri, idranti, ecc.), quelli orientati alla sicurezza elettrica (come le resistenze di
terra, gli interruttori magnetotermici, ecc.), oppure i vari aspetti di sicurezza
dei macchinari per la produzione e dei mezzi di trasporto.
Nonostante la gestione preventiva del rischio che viene effettuata, come
descritto, con determinati presidi ed accorgimenti, il rischio non puo essere
sempre scongiurato preventivamente. I dispositivi di protezione individuale
sono previsti proprio a questo scopo. Si tratta, infatti, di tutte le attrezzature
indossate dal lavoratore allo scopo di proteggerlo contro uno o piu rischi
che, durante il lavoro, minacciano la sua sicurezza o la sua salute. Tali
dispositivi sono obbligatori ogniqualvolta non sia possibile eliminare il rischio
con accorgimenti preventivi [Wikipedia, 2011b].
Tutti i dispositivi di protezione individuale possono essere suddivisi in tre
categorie, in funzione del rischio presente nell’ambiente di lavoro:
• I categoria – rischio lieve
• II categoria – rischio significativo come ad esempio occhi, mani, braccia,
viso
• III categoria – comprende tutti i dispositivi per le vie respiratorie e
protezione dagli agenti chimici aggressivi
1.4 Obiettivo della tesi
Vista la disponibilita sul mercato di tecnologie basate su reti di sensori e
dispositivi, diviene oggi possibile immaginare di identificare le situazioni di
rischio nelle aree di lavoro che generalmente precedono gli incidenti. Tramite
CAPITOLO 1. INTRODUZIONE 7
l’applicazione di opportune strategie, e spesso possibile che i rischi evolvano
in incidenti, contenendo i danni che queste situazioni potrebbero provocare.
L’obiettivo di questa Tesi e quello di realizzare un prototipo software di
un Sistema per la Gestione del Rischio, che permetta di raccogliere tutte le
informazioni provenienti dalle reti di sensori e dai vari dispositivi indossabili,
allo scopo di identificare situazioni rischiose e individuare proattivamente le
strategie da applicare per la prevenzione degli incidenti.
Questo lavoro di Tesi e dunque incentrato sull’architettura e sulla realizza-
zione di un prototipo del Sistema per la Gestione del Rischio ed in particolare
sullo strato software applicativo che gestisce le informazioni che giungono dai
sensori, recependo i risultati di altri lavori che hanno gia trattato il livello
dei sensori.
Il prototipo utilizza un modello computazionale probabilistico del rischio
incentrato sulle persone presenti nell’ambiente interessate da rischio, svilup-
pato da [Fugini et al., 2010], ed e implementato realizzando il ciclo mape
[Cheng et al., 2009] composto dalle seguenti fasi: monitoring, analyzing, plan-
ning, executing.
Il software e basato sull’identificazione delle entita presenti nell’ambiente
e il modello di rischio viene elaborato ad ogni interazione del lavoratore con
gli strumenti di lavoro oppure nei casi di macchinari in movimento. Viene
calcolata una mappa del rischio per l’area di lavoro monitorata dalla rete di
sensori e vengono visualizzati tutti i parametri ambientali che sono tenuti
sotto controllo dal sistema.
Il prototipo inoltre analizza ad ogni cambiamento ambientale la nuova
situazione per capire se esistono segnali che evidenziano la presenza di pericoli
per la sicurezza dei lavoratori o che sono premonitori di eventuali situazioni
d’emergenza.
E inoltre compito del prototipo proporre la migliore strategia da adottare
quando si e in presenza di situazioni di pericolo. La scelta della migliore
strategia e basata sulla verifica da parte del prototipo della presenza nell’am-
CAPITOLO 1. INTRODUZIONE 8
biente di lavoro di particolari condizioni, che suggeriranno l’adozione di una
strategia piuttosto che di un’altra.
L’applicativo e rivolto ai site security manager che hanno la responsabilita
della sicurezza ambientale e della prevenzione degli infortuni sul lavoro dei
lavoratori. Sino ad oggi, questo tipo di attivita veniva svolta con un approccio
standard, cioe, per esempio, attraverso metodologie di processo, formazione
ai dipendenti, audit sulla sicurezza fisica e simulazioni periodiche. Questo
prototipo permette un nuovo approccio, basato sul monitoraggio istante per
istante di cio che accade nell’area operativa, per identificare i rischi al loro
insorgere.
Capitolo 2
Un Approccio alla Gestione delRischio
In questo capitolo viene introdotta la soluzione proposta in questo lavoro
per la gestione del rischio tramite la descrizione di un sistema informativo
in grado di utilizzare una rete di sensori e dispositivi hardware al fine di
rilevare e segnalare situazioni di pericolo in un ambiente lavorativo. Vengono
prima analizzate le caratteristiche principali che il sistema deve avere, per poi
presentare l’architettura generale del sistema e descrivere infine il modello
delle entita che il sistema e in grado di gestire.
2.1 Caratteristiche Generali del Sistema di
Gestione del Rischio
Le principali caratteristiche che deve avere un sistema per la gestione del
rischio sono l’identificazione e la classificazione delle minacce e la definizione
delle necessarie azioni correttive. Per raggiungere questo scopo la soluzione
che viene proposta in questa Tesi e basata sull’identificazione del rischio e
sulla sua gestione utilizzando il seguente ciclo di processi: monitoring, analy-
zing, planning, executing (mape) [Cheng et al., 2009]. Questo tipo di ciclo e
tipico dei sistemi di controllo e usato nell’ingegneria dei sistemi self-adaptive
e self-managing. Tramite questo insieme di processi saremo in grado di os-
9
CAPITOLO 2. UN APPROCCIO ALLA GESTIONE DEL RISCHIO 10
servare l’ambiente di lavoro, rilevare le anomalie tramite l’analisi dei dati che
vengono raccolti nella fase di monitoring, decidere se c’e una situazione di
rischio e, quando necessario, attuare gli opportuni cambiamenti mettendo in
atto le modifiche previste e pianificate. Le azioni preventive nascono dalla
considerazione che i parametri che vengono monitorati dal sistema, come ad
esempio la temperatura, possono essere gli indicatori di un rischio crescente.
Usando un approccio probabilistico per la valutazione dei parametri e dun-
que possibile calcolare la probabilita che un valore di un parametro fuori dal
proprio range evolva in una situazione pericolosa. Di conseguenza diviene
possibile definire le azioni preventive che permettono al valore del parametro
fuori range di ritornare in una condizione di normalita. Queste azioni posso-
no spaziare dal controllo di una tubatura dalla quale si sta verificando una
perdita di gas, all’invio di messaggi di allarme alle singole persone attraverso
l’uso di sistemi come i pda1.
In definitiva l’implementazione di un tale ciclo di processi permette di
ottenere un sistema self-healing per la gestione del rischio in grado di rilevare
e trattare situazioni di rischio attraverso l’uso di azioni preventive e correttive.
2.2 Architettura Generale: il Ciclo mape
L’architettura generale del sistema e quella proposta in figura 2.1.
Possiamo suddividere l’architettura generale in due principali livelli: il
primo livello, composto dai moduli non strettamente legati al ciclo mape
e piu correlato invece ai sensori e ai dispositivi di protezione e il secondo
livello, composto dai 4 moduli che realizzano il ciclo mape. Il primo livello
e stato oggetto di una precedente Tesi che ha affrontato il problema della
standardizzazione della raccolta dei dati dai differenti sensori e dispositivi
ambientali e personali. L’implementazione del secondo livello, che realizza il
ciclo mape, e l’obiettivo di questa Tesi. Poiche i due livelli sono interconnessi,
1 Personal Data Assistent
CAPITOLO 2. UN APPROCCIO ALLA GESTIONE DEL RISCHIO 11
Fig. 2.1: Architettura del Sistema di Gestione del Rischio[Fugini et al., 2011]
CAPITOLO 2. UN APPROCCIO ALLA GESTIONE DEL RISCHIO 12
per gli scopi di questa Tesi, il primo livello e stato simulato implementando
un’applicazione esterna al prototipo ma in grado di comunicare con esso.
2.2.1 Le Fasi del Ciclo mape
Il ciclo mape applicato al nostro contesto e composto dalle seguenti fasi:
1. Il monitoraggio (monitoring) dell’ambiente e realizzato attraverso l’u-
tilizzo di sensori (es. rfid2, videocamere) e dispotivi (es. pda, pc) che
chiameremo dispositivi informativi. Tutti i dispositivi e i sensori sono
distribuiti nell’area di lavoro (es. sui macchinari, sulle persone e sul lo-
ro equipaggiamento) [Franceschini et al., 2009, Laguna et al., 2009]. I
sensori sono distribuiti nell’ambiente in modo da essere in grado di rile-
vare dati significativi ai fini dell’identificazione del rischio. La raccolta
di dati puo riguardare, per esempio, il livello di saturazione di sostanze
gassose nocive, la rilevazione di allagamenti o altri dati ambientali. Re-
lativamente alle persone, possono essere identificate le azioni compiute
dagli operai, oppure l’utilizzo di determinati attrezzi, come ad esempio
martelli pneumatici o seghe elettriche. Anche i parametri vitali corpo-
rei possono essere oggetto di rilevazione e monitoraggio, per osservare
le condizioni di salute o di stress psicofisico dei lavoratori.
2. L’analisi (analyzing) dei dati e eseguita sui dati raccolti per verificare
se i valori si trovano entro determinati intervalli operativi di esercizio
standard. Ad esempio, viene rilevato se il livello di presenza di gas
nell’aria supera una certa soglia, oppure se un macchinario si muove
troppo velocemente in un area in cui si trovano delle persone o ancora
se la pressione arteriosa di un lavoratore e troppo elevata o troppo
bassa.
3. La pianificazione (planning) viene eseguita quando i dati dell’ambiente
mostrano valori al di fuori degli intervalli ammessi. In questa fase viene
2 Radio Frequency IDentification
CAPITOLO 2. UN APPROCCIO ALLA GESTIONE DEL RISCHIO 13
associata una funzione di rischio ad ogni elemento presente nell’ambien-
te. Combinando tutti i valori della funzione di rischio relativa alle varie
sorgenti, e possibile determinare se siamo in presenza di una situazio-
ne di rischio. In questo caso viene selezionata la strategia piu adatta.
Una strategia e un insieme di azioni che, se compiute, permettono di
ridurre il livello di rischio facendo rientrare la situazione di pericolo o
emergenza.
4. L’esecuzione (executing) e la fase in cui vengono applicate le strate-
gie identificate al passo precedente, utilizzando attivatori e dispositivi
informativi dislocati nell’ambiente.
Una volta eseguite le strategie, l’ambiente ne risultato mutato e il ciclo riparte
dalla fase di monitoraggio. Attraverso il continuo susseguirsi delle fasi descrit-
te in precedenza e possibile osservare e verificare il risultato dell’applicazione
delle strategie che portano alla riduzione o addirittura all’eliminazione del
rischio.
2.2.2 Monitoring
Questa fase viene gestita dall’Environment Data Manager, che e un modulo
composto a sua volta da due elementi: l’Environment Database e il System
Database. Questi due database contengono, rispettivamente, informazioni
sull’ambiente e sul contesto operativo, come di seguito descritto.
I valori dei parametri ambientali vengono raccolti dal modulo Data Col-
lector tramite i dispositivi informativi, che catturano i dati. I dispositivi in-
formativi sono sensori e allarmi (rfid, antenne, sensori di gas/temperatura)
che sono dislocati nell’ambiente per monitorarne lo stato, rilevare eventuali
situazioni di rischio e generare in casi di pericolo i necessari segnali di allarme.
Grazie a questi dispositivi, i dati possono essere anche inviati direttamente
dalle persone presenti nell’area di lavoro, sotto forma di segnali e allarmi. Il
modulo chiamato Data Collector invia tutti i dati raccolti all’Environment
Data Manager che li memorizza nell’Environment Database. Questo data-
CAPITOLO 2. UN APPROCCIO ALLA GESTIONE DEL RISCHIO 14
base raccoglie i valori istantanei dei dati relativi ai parametri ambientali
controllati (temperatura, pressione, concentrazione di gas, ecc.), mentre il
System Database gestisce i dati strutturali riguardanti il sistema oggetto di
osservazione, quali ad esempio, la topologia dell’area di lavoro oppure i ruo-
li dei lavoratori presenti nell’area. A differenza delle informazioni traccia-
te dall’Environment Database, i dati presenti nel System Database, durante
l’attivita ordinaria nell’ambiente operativo, sono soggetti a cambiamenti solo
sporadici e la frequenza nel tempo di queste variazioni e piuttosto moderata.
In questa fase, quindi, tutti parametri ambientali utili al riconoscimento
di situazioni di rischio vengono costantemente raccolti, memorizzati e resi
disponibili al sistema che li utilizzera per effettuare le necessarie analisi.
2.2.3 Analyzing
La fase di Analyzing e realizzata dal modulo denominato Data Analyzer Ma-
nager. Il suo obiettivo principale e quello di controllare continuamente i
valori rilevati dei parametri ambientali nella fase di monitoring, in modo da
verificare se sono all’interno dell’intervallo di confindenza consentito. Quan-
do il modulo rileva uno o piu di questi parametri al di fuori dell’intervallo di
confidenza, notifica al successivo modulo di Planning la potenziale presenza
di una situazione di rischio, perche venga opportunamente gestita.
2.2.4 Planning
La fase di Planning e realizzata dal modulo Risk & Emergencies Detector, che
e composto da tre ulteriori moduli: il Risk Detector, l’Emergency Detector
e lo Strategy Manager. I primi due hanno lo scopo di identificare eventuali
situazioni di rischio e di emergenza basate sui valori dei parametri ricevuti
dal modulo Data Analyzer. Il modulo Strategy Manager si occupa invece
di identificare la strategia piu appropriata da adottare per la situazione di
rischio rilevata. La scelta della strategia e basata su un insieme di regole
CAPITOLO 2. UN APPROCCIO ALLA GESTIONE DEL RISCHIO 15
definite nel Risk & Emergency Database che contiene le descrizioni di tutti i
rischi che possono essere riconosciuti dal sistema.
Una volta che una strategia e stata identificata, il Risk & Emergencies
Manager invia al modulo Execution Manager tutte le informazioni neces-
sarie per permettere che nella successiva fase di Executing venga applicata
l’opportuna strategia.
2.2.5 Executing
Questo modulo fa scattare tutte le azioni che devono essere eseguite per af-
frontare le situazioni di rischio rilevate. I moduli Risk Execution Handler
e Emergencies Execution Manager sono responsabili della corretta esecuzio-
ne delle azioni e dei passaggi elementari che compongono una strategia. I
messaggi che devono essere spediti alle varie entita presenti nell’ambiente
(persone, dispositivi informativi, elementi protettivi finalizzati alla preven-
zione e alla gestione del rischio) sono gestiti dal Communication Manager,
che sceglie ed utilizza il formato di invio piu appropriato per il messaggio
da inviare. I messaggi inviati dal Communication Manager possono avere
sia un connotato informativo che addirittura di allarme. Nel primo caso, il
Communication Manager utilizza per l’invio un formato quale per esempio
un’immagine, un suono, un sms. In caso di allarme, Communication Mana-
ger puo attivare spie luminose, sirene oppure altri generi di allarmi sonori
per attirare l’attenzione del lavoratore.
2.3 Modello delle Entita
Il prototipo e stato implementato utilizzando un modello a oggetti in cui ogni
entita presente nell’ambiente reale ha una corrispondente rappresentazione
nel modello informatizzato. Esiste pertanto una relazione tra gli oggetti in-
stanziati all’interno del prototipo e la corrispettiva entita presente nel mondo
CAPITOLO 2. UN APPROCCIO ALLA GESTIONE DEL RISCHIO 16
reale. In questo modo e possibile monitorare gli oggetti e le persone presenti
nell’area di lavoro.
2.3.1 L’entita Entity
Per rappresentare tutte le entita dell’ambiente il modello utilizza la classe
astratta Entity che viene poi estesa oppure implementata da altre clas-
si. Tutte le Entity sono potenziali sorgenti di rischio (ambiente, persone,
strumenti, macchinari, ecc.).
Entita “statiche” e “mobili”
Ogni elemento presente nell’ambiente e caratterizzato dalla propria posizione,
che ha grande rilevanza nel calcolo del rischio associato ad una determinata
area dell’ambiente stesso. E per questa ragione che l’entita Entity ha una
proprieta che ne identifica la caratteristica spaziale. In particolare, un’Entity
puo essere sia static, nel caso in cui la sua posizione non muta nel tempo
all’interno dell’area di lavoro, oppure mobile, qualora per sua natura l’Entity
si muove nell’ambiente operativo.
2.3.2 L’entita Environment
L’entita Environment rappresenta l’ambiente operativo e ne descrive le rela-
tive informazioni, come la dimensione. Un’area di lavoro, in generale, e un
ambiente complesso composto sia da aree aperte OpenArea che da aree chiuse
ClosedArea. Un ambiente di lavoro puo essere composto da piu Environ-
ment combinati tra di loro. La posizione relativa di ogni Environment che
partecipa al modello e rappresentata tramite coordinate cartesiane piane. In
definitiva, la completa topologia dell’ambiente di lavoro e definita specifican-
do la posizione e la dimensione di ogni singola area che compone l’ambiente
di lavoro.
CAPITOLO 2. UN APPROCCIO ALLA GESTIONE DEL RISCHIO 17
Fig. 2.2: Modello delle Entita per il Sistema di Gestione del Rischio
CAPITOLO 2. UN APPROCCIO ALLA GESTIONE DEL RISCHIO 18
Ogni area di lavoro ha almeno un varco (AccessPoint), necessario per
l’ingresso e l’uscita dall’area stessa. Il modello considera anche che ogni
varco, ai fini delle valutazioni del rischio operativo, potrebbe anche fungere
da uscita di emergenza (emergencyExit).
Nell’Environment, oltre agli AccessPoint, sono presenti numerosi altri
elementi da considerare ai fini delle valutazioni di rischio. Per rappresentare
questi elementi, il modello prevede l’entita PlantElement. I PlantElement
sono:
• tubature di gas;
• tubature di liquidi;
• prese elettriche;
• varchi, quali finestre, porte, uscite di emergenza, ecc.
Tutti i plant element sono generatori di rischio e in quanto tali influenzano
il calcolo del rischio nell’area di lavoro.
2.3.3 L’entita Person
L’entita Person rappresenta una persona che lavora all’interno dell’ambiente
operativo. Ad ogni persona e associato un profilo (realizzato dalla classe
Profile) che ne rappresenta le caratteristiche in termini di esperienza, ruolo
e capacita. La classe Profile e composta dalle classi Experience, Role e
Skill che rappresentano e gestiscono le caratteristiche del profilo associato
ad ogni persona.
L’entita Skill
L’entita Skill modella le capacita che il lavoratore dovrebbe possedere per
un utilizzo corretto (e quindi poco rischioso) degli strumenti e dei macchi-
nari ed e espressa da un indice che puo assumere i valori di basso, medio o
CAPITOLO 2. UN APPROCCIO ALLA GESTIONE DEL RISCHIO 19
alto. Gli Skill associati ad una persona sono destinati al confronto con gli
Skill necessari all’utilizzo di Tool e Machinery, per il calcolo del rischio
nell’ambiente operativo.
L’entita Experience
L’entita Experience modella le conoscenze individuali necessarie per operare
in modo sicuro relativamente alle procedure di sicurezza e all’organizzazione
del proprio lavoro. L’esperienza e espressa utilizzando un indice per ogni
aspetto, in relazione al numero di anni lavorativi e all’eta del lavoratore.
Anche questo indice di esperienza, come per quello inerente alle capacita del
lavoratore, puo assumere i valori di basso, medio o alto.
L’entita Role
L’entita Role rappresenta il ruolo ricoperto dal lavoratore e puo assumere
significati quali capo-team, visiatore, amministratore, ecc. Il Role non in-
terviene durante il calcolo del livello di rischio a cui la persona e soggetta.
Al contrario il Role viene utilizzato nella successiva fase di Planning per la
scelta della piu opportuna strategia comportamentale da far applicare alla
singola persona in caso di pericolo o emergenza.
2.3.4 L’entita Tool
L’entita Tool rappresenta uno strumento che si trova all’interno dell’ambiente
operativo e puo essere utilizzato da una Person nell’ambito della propria
attivita lavorativa. Alcuni esempi di strumenti sono martelli, seghe, trapani,
ecc.
Questo oggetto contiene alcune informazioni che caratterizzano lo stru-
mento, quali le funzionalita a cui esso e preposto (funcionality) e la data di
fabbricazione (fabricationDate), che servono al calcolo del rischio correlato
CAPITOLO 2. UN APPROCCIO ALLA GESTIONE DEL RISCHIO 20
all’utilizzo dello strumento (utilizzare uno strumento nuovo, per esempio, e
meno rischioso rispetto all’utilizzo di uno piu vecchio ed usurato!).
L’entita Tool e caratterizzata da una associazione di tipo “molti-a-molti”
con l’oggetto Skill, per rappresentare le competenze necessarie ad una per-
sona per l’utilizzo dello strumento di lavoro. Esiste anche un’altra relazione di
tipo “molti-a-molti” di questo oggetto con l’oggetto UsageInstruction, per
rappresentare le regole di utilizzo sicuro che le persone non devono violare
nell’utilizzo del tool.
L’entita UsageInstruction
L’entita UsageInstruction e una proprieta presente nella classe Machinery
e nella classe Tool che rappresenta l’insieme delle procedure di utilizzo sicure
di Tool oppure di Machinery. Si tratta delle procedure di corretto utilizzo
finalizzate a ridurre al minimo le probabilita che si verifichino situazioni di
rischio che possano coinvolgere le persone e l’area di lavoro.
2.3.5 L’entita Machinery
Questa entita modella un macchinario a disposizione dei lavoratori presen-
ti nell’ambiente operativo. Alcuni esempi di Machinery sono: automezzi,
muletti, ruspe, ecc.
Analogamente all’entita Tool, un Machinery contiene alcune informazioni
che lo caratterizzano ed e in relazione con le entita Skill e UsageInstruc-
tion (descritte nel precedente paragrafo 2.3.3) per descrivere i requisiti delle
competenze della persona che lo utilizza e le istruzioni operative da rispettare
nell’utilizzo. Differentemente da un Tool, un Machinery ha la caratteristica
di muoversi autonomamente e liberamente nell’ambiente operativo e infatti,
per questo motivo, e caratterizzato anche da una posizione.
CAPITOLO 2. UN APPROCCIO ALLA GESTIONE DEL RISCHIO 21
2.3.6 L’entita InformativeDevice
L’entita InformativeDevice modella i dispositivi tecnologici utilizzati nel
sistema informativo per tenere monitorato e per comunicare con l’ambiente
operativo. Questi dispositivi possono sia trasmettere informazioni dall’am-
biente verso il sistema informativo, ai fini della raccolta dei dati relativi ai pa-
rametri ambientali, sia ricevere segnali di allarme dal sistema informativo del
centro di sorveglianza, per notificare alle persone che operano nell’ambiente
di lavoro eventuali situazioni di rischio.
Ogni informative device e caratterizzato da i seguenti parametri:
• TransmissionMedium — indica il protocollo o la tecnologia trasmissiva
con cui il dispositvo comunica con il sistema (per esempio ethernet,
Wi-Fi, Bluetooth)
• InDataFlow — rappresenta il flusso di dati in input che il dispositivo
rileva nell’ambiente e invia al Sistema di Gestione del Rischio
• OutDataFlow — rappresenta il flusso di dati in output che il Sistema
di Gestione del Rischio invia al dispositivo per informare le persone su
allarmi o situazioni di pericolo in corso
2.3.7 L’entita ProtectionElement
L’entita ProtectionElement ha lo scopo di rappresentare i presidi finalizzati
a prevenire i rischi fornendo protezione fisica alle persone, agli strumenti e ai
automezzi, in modo da diminuire il livello di rischio proprio e quello da loro
stessi generato.
Il modello prevede tre tipi di ProtectionElement:
• PersonProtectionGarments — sono gli elementi che forniscono una
protezione fisica alle persone (es. caschi, scarponi, giacche, ecc.). I
PersonProtectionGarments possiedono le seguenti proprieta:
CAPITOLO 2. UN APPROCCIO ALLA GESTIONE DEL RISCHIO 22
– una descrizione;
– un intervallo di sicurezza all’interno del quale il PersonProtec-
tionGarments puo fornire un’adegauta protezione alla persona;
• EnvironmentProtectionKits — questi ProtectionElement permet-
tono alle persone di intervenire sull’ambiente di lavoro in caso di inci-
dente o di poter scappare. Esempi sono i kit di protezione da incendi
oppure kit di evacuazione;
• InstrumentProtectionKit — sono ProtectionElement che hanno lo
scopo di fornire una protezione agli strumenti e agli automezzi utilizzati
nell’area di lavoro, in modo da abbassarne la loro pericolosita.
Capitolo 3
Modello Computazionale delRischio
In questo capitolo viene presentato il modello computazione usato dal sistema
per il calcolo del livello di rischio, introducendo prima il concetto di rischio
e descrivendo come viene calcolata l’influenza di ogni singola entita nella
definzione del rischio. Vengono definiti alcuni concetti relativi al rischio come
la mappa del rischio, il livello di rischio e il livello di protezione che sono
associati con le entita che rappresentano l’ambiente di lavoro.
3.1 Definizione di Rischio
Per poter calcolare in modo analitico il livello di rischio generato nell’ambien-
te operativo da ogni entita presente nell’area di lavoro e necessario definire
con precisione il concetto di rischio. Nell’ambito di questo modello del Siste-
ma di Gestione del Rischio, il rischio e un effetto potenzialmente dannoso, o
comunque negativo, che deriva da processi, eventi o attivita in corso, e che
grava su una o piu entita presenti nell’area di lavoro.
Il rischio puo essere classificato in base ad alcune proprieta che lo carat-
terizzano, come riportato nella tabella 3.1. Si tratta delle proprieta, che de-
rivano dall’esperienza comune, che devono essere necessariamente rispettate
23
CAPITOLO 3. MODELLO COMPUTAZIONALE DEL RISCHIO 24
Elemento caratterizzante Proprieta
Indicatori di rischio Ogni dato interpretato come indicatoredi rischio deve essere proporzionale aldanno atteso.
Sorgenti di rischio Le misure di protezione devono esserespecifiche per ogni sorgente di rischio.Ogni sorgente di rischio deve esse-re identificata da un’entita presentenell’ambiente operativo.Ogni sorgente di rischio deve possedereun proprio pericolo intrinseco.
Danno I danni attesi devono essere proporzionalialla tipologia di sorgente di rischio.I danni attesi devono essere inversamenteproporzionali alla distanza dalla sorgentedi rischio.I danni attesi devono essere inversamenteproporzionali all’efficacia delle misure diprotezione impiegati dalle persone.
Tabella 3.1: Proprieta degli elementi del rischio
da ogni modello analitico finalizzato al calcolo dei livelli di rischio.
3.2 Determinazione del Rischio d’Ambiente
Nell’ambiente lavorativo reale, il rischio per un lavoratore e una conseguenza
della sua posizione nell’ambiente operativo, delle protezioni indossate, delle
procedure di sicurezza adottate e della presenza di entita potenzialmente pe-
ricolosi. La rischiosita per una persona, in ogni istante, dipende quindi dalle
proprieta del lavoratore (quali per esempio eta, skill, esperienza, ruolo, stato
di salute e protezione impiegate) e dalle entita presenti nell’ambiente con cui
interagisce. La combinazione di questi due fattori identifica gli elementi di
rischio che quindi possono essere rappresentati dal prodotto cartesiano tra le
proprieta del lavoratore e le entita presenti nell’ambiente.
Il livello di rischio di una persona RP calcolato in un certo istante di
CAPITOLO 3. MODELLO COMPUTAZIONALE DEL RISCHIO 25
tempo t, e dato dalla somma dei singoli elementi di rischio, ottenuti da una
combinazione di tutte le risorse pericolose presenti nell’ambiente attive al
tempo t, piu precisamente:
RP =∑∀r∈R
(Persone⊗ Ambiente) (3.2.1)
con R insieme di tutti gli elementi di rischio presenti nell’ambiente operativo.
Considerando le proprieta descritte nella tabella 3.1, questa definizione puo
essere esplosa in un’espressione analitica per il calcolo istantaneo del rischio
di una persona:
RP =∑∀r∈R
Pr · trdpr · sr
(3.2.2)
dove Pr indica la pericolosita della risorsa r; tr e un coefficiente legato al tipo
di pericolo della risorsa r; dpr e la distanza tra la persona p e la risorsa r;
sr e un coefficiente legato alle procedure di sicurezza che sono state messe
in atto e alle protezioni individuali indossate dal lavoratore per prevenire i
danni che la risorsa r puo provocare.
3.2.1 La Funzione di Rischio
La formula analitica del rischio risulta molto utile all’identificazione dei pa-
rametri del rischio. Tuttavia, essa presenta alcuni problemi:
• e difficile ottenere intervalli validi per i coefficienti tr e sr utilizzando
dati sperimentali;
• il coefficiente di rischio sr dovrebbe essere indipendente da qualsia-
si altro fattore nell’espressione, in quanto le protezioni indossate e le
procedure di sicurezza messe in atto dovrebbero offrire un supporto co-
stante alla riduzione del rischio della persona, indipendentemente dalla
sua distanza dal pericolo;
CAPITOLO 3. MODELLO COMPUTAZIONALE DEL RISCHIO 26
• il parametro distanza puo far oscillare i valori di rischio al di fuori del
range previsto. Infatti, anche brevi distanze possono far aumentare RP
a livelli molto alti. Anche se concettualmente corretta, questa variabi-
lita potrebbe portare a problemi durante l’elaborazione delle formule
di rischio.
Molti di questi problemi, come proposto da [] possono essere risolti at-
traverso l’utilizzo di una funzione di rischio modificata con i seguenti due
accorgimenti:
• il coefficiente sr relativo alle procedure di sicurezza viene separato dal
calcolo del rischio sottraendo a RP un valore numerico che dipende
dalle protezioni usate per prevenire i danni causati dalla sorgente r
considerata;
• la distanza dpr viene sostituita da un coefficiente gaussiano che dipende
dalla distanza dall’elemento di rischio e dal tipo di rischio, ottenendo
sempre un valore compreso tra 0 e 1. Questo valore viene poi moltipli-
cato per il fattore di pericolosita Pr relativo ad ogni risorsa r, in modo
da diminuire il suo contributo al crescere della distanza della persona
dalla sorgente di rischio.
Per semplicita considereremo un’area di lavoro bidimensionale e suppo-
nendo che la risorsa r, generatrice di rischio, sia localizzata nell’origine degli
assi possiamo utilizzare la distribuzione gaussiana, che ha la caratteristica di
avere il proprio massimo (cioe il suo valo medio µ) esattamente in corrispon-
denza all’origine del pericolo e decrementa il proprio valore allontanandosi da
esso. Piu la curva gaussiana e “piatta”, maggiore sara l’influenza del rischio
all’aumentare della distanza. L’apertura della curva gaussiana, e quindi la
distribuzione dei valori intorno alla media, dipende dal tipo di pericolo asso-
ciato alla risorsa (es. gas, fuoco, ecc.) e cioe dal coefficiente tr. Il coefficiente
tr e dunque la deviazione standard σ della campana gaussiana.
Infine, la curva gaussiana viene scalata in modo che il suo massimo coinci-
da con il punto (0, 1) e che quindi la rischiosita del singolo elemento di rischio
CAPITOLO 3. MODELLO COMPUTAZIONALE DEL RISCHIO 27
Fig. 3.1: Curva della distribuzione gaussiana, con il massimo in (0,1)
r possa assumere solo valori all’interno dell’intervallo [0, 1], come mostrato
in figura 3.1.
La nuova espressione per il calcolo del livello di rischio RP per una persona
P al tempo t e quindi:
RP =∑∀r∈R
[Nσ(dpr) · Pr − sr · br] (3.2.3)
dove Pr indica la pericolosita della risorsa r; sr e il coefficiente (indipendente
dalla distanza dalla sorgente di rischio r) legato alle procedure di sicurezza che
sono state messe in atto e alle protezioni individuali indossate dal lavoratore
per prevenire i danni che la risorsa r puo provocare; br e un coefficiente
booleano tale che:
br =
{1 se sono presenti presidi protettivi0 altrimenti
(3.2.4)
Nell’espressione precedente, per presidi protettivi si intende che viene
messa in atto una procedura di sicurezza oppure viene adottato un dispositivo
CAPITOLO 3. MODELLO COMPUTAZIONALE DEL RISCHIO 28
protettivo in grado di ridurre il rischio causato dalla risorsa r; dpr e la distanza
della persona P dalla risorsa r; Nσ e una funzione gaussiana con media uguale
a 0 e deviazione standard σ opportunamente scalata in modo che assuma
valori nell’intervallo [0,1]. Piu precisamente essa rappresenta la seguente
funzione, nella quale tr e la deviazione standard:
Nσ = e−dpr
2
2tr2
(3.2.5)
In questo modo tutte le proprieta della tabella 3.1 sono state mantenute, ossia
sono state rispettate tutte le dipendenze (dirette e indirette) tra il rischio e
ogni sua singola componente.
La somma di ogni funzione gaussiana (che ha come valore massimo pr)
diminuita di un fattore sr, rappresenta il valore del livello di rischio Rp nel-
l’ambiente di lavoro. Per esempio, assumiamo per semplicita che un lavora-
tore possa muoversi solo linearmente sulla dimensione rappresentata dall’asse
X di un piano cartesiano, in cui il valore del livello di rischio calcolato viene
rappresentato sull’asse Y . Assumiamo poi di avere tre sorgenti di rischio r
posizionate nei punti dell’asse X con valori −5, 0 e 3. Le deviazioni standard
σ delle sorgenti di rischio r siano rispettivamente 1, 2 e 5. Cosı facendo la
somma delle tre curve gaussiane Nσ delle sorgenti di rischio r rappresenta la
curva di rischio dell’area di lavoro, come mostrato in figura 3.2.
Applicando lo stesso metodo al caso di un lavoratore che puo muoversi
liberamente in un’area bidimensionale otterremo un grafico tridimensionale
nel quale l’asse Z rappresenta l’insieme dei valori che possono essere assunti
dal livello di rischio nell’intera area di lavoro. Per ottenere i valori del livello di
rischio in ogni punto dell’intera area di lavoro utilizzeremo una distribuzione
CAPITOLO 3. MODELLO COMPUTAZIONALE DEL RISCHIO 29
gaussiana bidimensionale, che ha la seguente espressione:
f(x, y) =1√
2π · σxe−
12
(x−µxσx
)2· 1√
2π · σye− 1
2
(y−µyσy
)2=
1
2πσxσye− 1
2
[(x−µxσx
)2+(y−µyσy
)2] (3.2.6)
Utilizzando come media (µx, µy) della distribuzione gaussiana la posizio-
ne della risorsa di rischio nell’area di lavoro e ipotizzando che le deviazioni
standard σx e σy siano uguali tra di loro, possiamo semplificare la funzione
ottenendo:
z = e−[
(x−xP )2
2·tr2+
(y−yP )2
2·tr2
](3.2.7)
dove P e il punto in cui risiede la risorsa r generatrice di rischio, le cui
coordinate sono (xP , yP ) e tr e la deviazione standard.
Fig. 3.2: Somma di elementi di rischio. La linea verde e data dalla sommadelle altre curve gaussiane
CAPITOLO 3. MODELLO COMPUTAZIONALE DEL RISCHIO 30
3.2.2 La Generazione del Rischio
In base a quanto detto sino ad ora, per ogni sorgente di rischio e necessario
definire una distribuzione di rischio caratterizzata dalle coordinate del valore
medio, dalla deviazione standard tr e da un coefficiente di proporzionalita
Pr.
Ognuno di questi valori e a sua volta una funzione f() di altri parametri,
che sono differenti per ogni sorgente di rischio identificata.
Plant Element
Consideriamo i vari plant element sorgenti di rischio relativi alla presenza di
tubi, finestre, porte, prese elettriche. Possiamo determinare le caratteristiche
della funzione f() nel seguente modo:
• coefficiente di proporzionalita Pr: il tipo di elemento influenza il livello
di rischio, ad esempio una presa elettrica puo essere considerata meno
pericolosa di un tubo del gas e quindi il coefficiente di proporzionalita
e funzione del tipo: f(type);
• valore medio: la posizione dell’elemento nell’area di lavoro;
• deviazione standard tr: il tipo e la posizione dell’elemento influenzano
il livello di rischio ad una certa distanza che dipende dalla deviazione
standard: f(type, position).
Persona
Ogni persona rappresenta una sorgente di rischio per la quale le caratteristi-
che della funzione f() sono le seguenti:
• coefficiente di proporzionalita Pr: maggiore e l’esperienza e gli skill
della persona, minore sara il rischio che generera con le proprie attivita,
pertanto si utilizzera una f(skill, experience);
CAPITOLO 3. MODELLO COMPUTAZIONALE DEL RISCHIO 31
• valore medio: la posizione della persona nell’area di lavoro;
• deviazione standard tr: l’utilizzo di strumenti da parte della persona
influenza la curva di rischio che interessa l’area circostante. Si utilizzera
quindi una f(tool).
Automezzi
Il rischio generato da ogni automezzo determina una funzione f() le cui
caratteristiche sono le seguenti:
• coefficiente di proporzionalita Pr: il livello di rischio generato da un au-
tomezzo in movimento e inversamente proporzionale al livello di adozio-
ne delle istruzioni per un utilizzo sicuro dell’automezzo stesso da parte
del conducente, e quindi si utilizzera una f(instruction usage);
• valore medio: la posizione dell’automezzo nell’area di lavoro;
• deviazione standard tr: il tipo di automezzo e le il livello di adozione
delle istruzioni per un utilizzo sicuro influenzano la curva di rischio, e
quindi sara utilizzata una f(type, instruction usage).
Stato Ambientale
Lo stato ambientale e rappresentato nel modello dalle informazioni che ven-
gono rilevate e trasmesse dai dispositivi informativi, come ad esempio i rile-
vatori di gas o di temperatura. Le caratteristiche della funzione f() sono le
seguenti:
• coefficiente di proporzionalita Pr: il livello di rischio derivante dai mo-
nitoraggi dei sensori ambientali dipende dal tipo di parametro rilevato e
dal valore del dato raccolto, quindi si utilizzera una f(type, in-dataflow);
• valore medio: la posizione del sensore nell’area di lavoro;
CAPITOLO 3. MODELLO COMPUTAZIONALE DEL RISCHIO 32
• deviazione standard tr: il tipo di sensore e le informazioni da esso
raccolte influenzano la curva di rischio, e quindi sara utilizzata una
f(type, in-dataflow).
3.2.3 La Protezione dal Rischio con Dispositivi d’Am-biente
In ogni ambiente operativo sono presenti entita che influenza il livello di
rischio, diminuendolo. Tipicamente, si tratta di elementi quali le uscite di
emergenza ed i dispositivi di pronto intervento (ad esempio gli estintori).
Queste diminuzioni del livello di rischio verranno modellate nuovamente con
distribuzioni di tipo gaussiano con il valor massimo localizzato sulla posizione
del dispositivo di sicurezza. La varianza di queste distribuzioni discende
dall’efficacia di questi dispositivi al crescere della distanza da essi. Pertanto,
coerentemente con quanto discusso per le sorgenti di rischio, anche in questo
caso i parametri di riferimento per definire la funzione di diminuzione del
rischio sono: le coordinate del valore medio, la deviazione standard ts e il
coefficiente di proporzionalita Ps.
Varchi e Uscite di Emergenza
I varchi e le uscite di emergenza hanno la caratteristica di abbattere il livello
di rischio perche permettono agli operatori di allontanarsi tempestivamente e
con successo da situazioni di pericolo ambientale. La protezione generata da
questo tipo di elementi e rappresentabile con una funzione f() dotata delle
seguenti caratteristiche:
• coefficiente di proporzionalita Ps: e un valore fisso che non dipende da
null’altro se non dalla presenza stessa dei varchi;
• valore medio: la posizione del varco all’interno dell’area di lavoro;
• deviazione standard ts: il tipo di varco ed il suo allestimento e influen-
zano la curva di rischio. Maggiore sara l’ampiezza e la percorribilita del
CAPITOLO 3. MODELLO COMPUTAZIONALE DEL RISCHIO 33
varco, maggiore risultera la sua efficacia in caso di emergenza, quindi
sara utilizzata una f(type).
Dispositivi di Pronto Intervento
I dispositivi posizionati all’interno dell’area di lavoro, come ad esempio gli
estintori, utili in caso di situazioni pericolose o di emergenza, permettono di
abbassare il livello di rischio perche permettono di poter intervenire tempe-
stivamente per risolvere o far fronte ad una situazione ad alto rischio. La
protezione generata da questo tipo di elementi e rappresentabile come una
funzione f() che ha le seguenti caratteristiche:
• coefficiente di proporzionalita Ps: e un valore fisso che dipende solo
dalla presenza stessa del dispositivo di pronto intervento;
• valore medio: la posizione del dispositivo di pronto intervento all’inter-
no dell’area di lavoro;
• deviazione standard ts: il tipo di dispositivo di pronto intervento in-
fluenza la curva di rischio. Piu il dispositivo e in grado di essere uti-
lizzato tempestivamente maggiore sara la sua efficacia, che decresce al
crescere della distanza, quindi sara utilizzata una f(type).
3.2.4 La Mappa del Rischio Ambientale
Una volta calcolate le funzioni f() di ogni sorgente di rischio e di tutti i
dispositivi protettivi d’ambiente, ottenendo quindi le distribuzioni gaussiane
di ogni elemento presente nell’ambiente, e possibile combinare le varie distri-
buzioni in modo da ottenere una mappa del rischio da associare ad ogni area
operativa.
Ipotizzando quindi che ogni sorgente di rischio ed ogni elemento protet-
tivo d’ambiente sia caratterizzato da una funzione di rischio indipendente,
la somma di tutte le curve gaussiane fornisce una vista istantanea del valore
CAPITOLO 3. MODELLO COMPUTAZIONALE DEL RISCHIO 34
di rischio in ogni punto di spazio bidimensionale. Nel dettaglio il livello di
rischio RP nel punto (x, y) risulta:
RP (x, y) =∑∀r∈R
Ntr
(dpr)· Pr −
∑∀s∈S
Nts
(dps)· Ps (3.2.8)
dove R e l’insieme di tutte le sorgenti di rischio presenti nell’ambiente; S e
l’insieme di tutti i dispositivi protettivi presenti nell’ambiente; N e la distri-
buzione gaussiana associata alla sorgente di rischio r oppure al dispositivo
protettivo s ed e funzione della distanza d dall’elemento di rischio r oppure
dal dispositivo protettivo s e della deviazione standard tr oppure ts; P e il
coefficiente di proporzionalita associato alla sorgente di rischio r oppure al
dispositivo protettivo s.
3.3 Determinazione del Rischio Individuale
Fino ad ora sono stati presi in considerazione tutti gli elementi di rischio
derivanti dal contesto operativo ambientale, in cui un lavoratore puo muoversi
per svolgere la propria attivita. Tuttavia, il rischio associato ad un persona
non deriva unicamente dalla sua posizione nell’ambiente, ma assume un peso
determinante anche la rischiosita dell’attivita che sta svolgendo.
Lo svolgimento di un’operazione lavorativa piu o meno pericolosa gene-
ra sull’individuo un livello di rischio che va considerato ai fini del modello.
Anche i presidi protettivi individuali adottati giocano un ruolo importante,
diminuendo il rischio del lavoratore.
3.3.1 Il Rischio Individuale
Il rischio individuale di una persona verra chiamato PRL, per Personal Risk
Level. Il PRL di una persona dipende da:
CAPITOLO 3. MODELLO COMPUTAZIONALE DEL RISCHIO 35
• il rischio d’ambiente RP , discusso nel paragrafo 3.2, che dipende dalla
posizione in cui il lavoratore si trova in un determinato istante e dalle
caratteristiche di rischio dell’ambienjte in cui opera;
• l’esperienza e gli skill posseduti dall’operatore specificamente in rela-
zione all’attivita che sta compiendo;
• caratteristiche di rischiosita di strumenti e macchinari che l’operatore
sta utilizzando nell’ambito della propria attivita;
• lo stato psicofisico della persona, che puo essere rilevato sul corpo
utilizzando specifici sensori indossabili.
Quindi, possiamo scrivere che:
PRL = f(posizione,
esperienza e skill,
strumenti e macchinari,
stato psicofisico)
(3.3.1)
3.3.2 La Protezione Individuale
Ogni persona e anche connotata dal livello di protezione individuale (PPL,
cioe Personal Protection Level) che rappresenta il grado di smorzamento del
rischio a cui e assoggettato per effetto dei dispositivi protettivi che indossa
oppure che ha a disposizione. Il livello di protezione individuale dipende da:
• dagli elementi protettivi indossati dal lavoratore durante la sua attivita
lavorativa;
• dai dispositivi informativi (es. pda) che permettono ai lavoratori di
comunicare con altri lavoratori o di essere raggiunti da messaggi infor-
mativi o di allarme in caso di emergenza.
CAPITOLO 3. MODELLO COMPUTAZIONALE DEL RISCHIO 36
Quindi possiamo scrivere che:
PPL = f(dispositivi protettivi,
dispositivi informativi)(3.3.2)
3.3.3 Il Livello di Rischio Individuale
Nel complesso, il rischio individuale totale, detto PRI, ossia Personal Risk
Index, rappresenta il livello di rischio a cui una persona e soggetta in un
determinato istante di tempo. Si tratta di una misura del rischio di una
persona che non tiene conto di come la stessa persona influenza l’ambiente
circostante, ma solo il rischio che l’ambiente (compresi altri individui che in
esso operano) genera nei confronti del singolo. Il PRI e calcolato nel seguente
modo:
PRI = PRL− PPL (3.3.3)
Se il PRI oltrepassa determinate soglie di rischio diviene necessario ope-
rare un intervento, applicando la miglior strategia per far rientrare il livello
di rischio del lavoratore.
3.4 Strategie
La presenza di parametri al di fuori dell’intervallo di confidenza previsto, di
per se, gia denota una situazione di rischio. L’eventualita di una situazione
di questo tipo viene costantemente monitorata dall’rms. Il sistema mantie-
ne sotto controllo, in ogni istante, la mappa completa del rischio ambientale
derivante dalla letture dei parametri dei sensori. Indipendentemente dalla
lettura del PRI, il sistema e in grado quindi di identificare una situazione
di rischio tale da rendere necessaria l’applicazione di una strategia di con-
tenimento del livello di pericolo a cui l’area, e soprattutto i lavoratori, sono
soggetti.
CAPITOLO 3. MODELLO COMPUTAZIONALE DEL RISCHIO 37
Situazione Nome del Pattern Condizione e strategie
Fuga di gas Risk Level Se il livello di rischio indivi-duale e maggiore di un sogliaviene applicata la strategia 2altrimenti la strategia 1
Scoppio di unacondotta
Risk Vicinity Se il lavoratore si trova vicinoalla sorgente di rischio viene ap-plicata la strategia 4 altrimentila strategia 1 o la strategia 2
Crollo Number of Persons Se il numero di lavoratori al-l’interno dell’area di lavoro emaggiore di n viene applica-ta la strategia 1 altrimenti lastrategia 3
Incendio Skills Se nell’insieme dei lavorato-ri all’interno dell’area di lavo-ro e presente un capo teamviene applicata la strategia 2altrimenti la strategia 1
Lieve radioatti-vita
Health Se nell’insieme dei lavoratoriall’interno dell’area di lavoroe presente un lavoratore conuna condizione di salute bas-sa viene applicata la strategia3 altrimenti la strategia 1
Tabella 3.2: Esempi di combinazioni tra situazioni di rischio, strategieapplicabili e condizioni di selezione che il sistema puo gestire
Nel momento in cui il modulo di Analyzing rileva dei valori oltre le so-
glie di guardia, si attiva il modulo Strategy Manager, e viene conseguente-
mente avviata la fase di Planning, perche la situazione di emergenza venga
opportunamente gestita.
Il valore del parametro PRI di un lavoratore, che viene influenzato dai
valori di rischio ambientali, anche se permette di individuare quali siano i
lavoratori in pericolo, non e sufficiente, di per se, per l’identificazione della
strategia piu efficace da adottare per riportare i parametri entro le soglie di
normalita.
CAPITOLO 3. MODELLO COMPUTAZIONALE DEL RISCHIO 38
Per la scelta della strategia piu adatta, e necessario individuare la tipolo-
gia di situazione di rischio con cui i lavoratori hanno a che fare. Questo pas-
saggio permette di individuare un insieme di strategie potenzialmente adatte
alla situazione, tra cui scegliere, in base al pattern strategico piu appropriato.
A questo punto, in base ad alcune condizioni relative alle rilevazioni ambien-
tali, alla dislocazione delle persone nelle aree operative, ai loro ruoli e skill,
e in base a tutte le altre informazioni disponibili, e possibile individuare la
strategia piu efficace tra quelle definite nel Risk & Emergency Database. La
strategia si sostanzia poi in un insieme ordinato di azioni, a cui viene dato
seguito di conseguenza. La tabella 3.2 riporta alcuni esempi di combinazioni
tra situazioni di rischio, strategie applicabili e condizioni di selezione che il
sistema puo gestire.
Le varie strategie si differenziano in base all’aggressivita nei confronti
della situazioni di pericolo e in base alla presenza di alcune condizioni che
rappresentano il livello rischio a cui far fronte. Ogni strategia puo essere piu
o meno efficace, ma va sempre ricordato che l’obiettivo e quello di applicare
Nome Azioni
Strategia S0001 Controlla il sensore del gasControlla il livello di concentrazione del gasManda un sms al capo teamRecupera gli strumenti di lavoroLascia l’area di lavoroSpostati nell’area di sicurezza
Strategia S0002 Chiudi il rubinetto del gasChiudi l’interuttore generale della correnteAttiva gli allarmiLascia l’area di lavoroSpostati nell’area di sicurezza
Strategia S0003 Attiva l’allarmeSpostati nell’area di sicurezza
Strategia S0004 Attiva l’allarmeGuida le persone fuori dall’area di lavoro
Tabella 3.3: Esempio di strategie applicabili, in base al contesto
CAPITOLO 3. MODELLO COMPUTAZIONALE DEL RISCHIO 39
la strategia che, nel contempo, massimizza l’efficacia nella diminuzione del
rischio e minimizza gli impatti sull’ambiente operativo e sulle attivita dei
lavoratori.
Se, per esempio, si rilevasse un principio di incendio in un magazzino di
logistica merci elettroniche destinate ai negozi (per esempio, telefoni cellulari
e dispositivi mobili), puo non essere adatta, anche se perfettamente effica-
ce, la strategia di attivazione immediata di tutti gli impianti antincendio ad
acqua di tipo “Sprinkler”. Se, per ipotesi, in prossimita del principio di in-
cendio fosse presente un lavoratore dotato di estintore portatile, potrebbe
essere possibile e preferibile domare le fiamme con un intervento locale, sen-
za allagare il magazzino e compromettere gravemente la merce ivi contenuta.
Quindi, la combinazione di tutti i fattori che possono essere letti nelle rileva-
zioni ed opportunamente interpretati puo permettere l’individuazione della
miglior strategia applicabile.
L’intervento derivante dalla scelta della strategia si sostanzia in un insieme
di azioni che devono essere eseguite in una sequenza predeterminata. Alcuni
esempi di strategie sono riportati nella tabella 3.3.
Capitolo 4
Architettura del prototipo
In questo capitolo viene illustrato il prototipo del Sistema per la Gestione
del Rischio da un punto di vista architetturale. Viene descritta la tipologia
di applicazione sviluppata e i livelli logici che la compongono, vengono de-
scritte le principali architetture implementate per ogni livello logico tramite
l’utilizzo dei diagrammi di classe e vengono mostrate le interazioni tra gli
oggetti utilizzando i sequence diagram al fine di illustrare come sono state
implementate le fasi previste dal ciclo mape.
4.1 Funzionalita del Prototipo
Il prototipo implementa le seguenti funzionalita:
• fase di monitoring : permette all’operatore tenere sotto controllo la si-
tuazione nell’area di lavoro, verificando su una mappa le zone che hanno
un livello di rischio piu elevato rispetto a quelle con un basso livello di
rischio. Inoltre e possibile ottenere le informazioni sulla composizio-
ne del livello di rischio individuale (pri) associato ad ogni lavoratore,
seguendone anche i movimenti all’interno dell’area di lavoro;
• fase di analyzing : il prototipo analizza in continuazione la situazio-
ne all’interno dell’area di lavoro alla ricerca di situazioni considerate
40
CAPITOLO 4. ARCHITETTURA DEL PROTOTIPO 41
pericolose e in tal caso ne da evidenza all’operatore;
• fase di planning : in presenza di una situazione considerata di pericolo
il prototipo propone all’operatore le azioni che compongono la miglio-
re strategia da adottare per abbassare il livello di rischio nell’area di
lavoro;
• caricamento ambiente di lavoro: sara possibile “caricare” nel prototipo
l’ambiente di lavoro che si vuole monitorare tramite l’utilizzo di un
file xml che descrive le entita e le aree che compongono l’ambiente di
lavoro stesso.
Nei paragrafi che seguono viene descritto il prototipo da un punto di vista
architetturale, mostrando gli strati software che lo compongono e la struttura
interna delle classi.
4.2 Struttura del Prototipo
Il prototipo e stato sviluppato realizzando un’applicazione che recupera e
fornisce le informazioni necessarie utilizzando il Web come canale di comu-
nicazione, e cioe un sistema informativo basato sul web (Web Information
Systemwis [Ardagna et al., 2009]). Questo tipo di architettura permette di
ottenere una serie di importanti vantaggi. Tra i principali, vanno sottolineati
l’apetto multipiattaforma dell’applicativo e la sua interoperabilita:
• applicazione multipiattaforma: tramite l’utilizzo di tecnologie web si
ha la possibilita di utilizzare la stessa applicazione su varie piattafor-
me software e hardware senza dover affrontare tutti i problemi deri-
vanti dall’eterogeneita e dall’incompatibilita delle diverse piattaforme
hardware e software;
• interoperabilita: tramite l’utilizzo di piattaforme, linguaggi e sistemi
diversi e utilizzando il paradigma dei servizi e la separazione fra aspetti
CAPITOLO 4. ARCHITETTURA DEL PROTOTIPO 42
di presentazione e accesso, di logica applicativa e di comunicazione, si
ottiene un’applicazione in grado di poter comunicare nativamente con
altre applicazioni;
Per realizzare l’applicazione e stato utilizzata la tecnologia Java2 Enterprise
Edition. La piattaforma j2ee e costituita da un insieme di specifiche che
definiscono le caratteristiche e le interfacce di un insieme di tecnologie pen-
sate per la realizzazione di applicazioni di tipo enterprise e mission critical.
Cio che distingue la tecnologia Java “tradizionale” (cioe Java2 Standard Edi-
tion – j2se) dall’edizione “enterprise”, sono tutte le librerie aggiuntive che
forniscono tutte le funzionalita necessarie per la realizzazione di applicazioni
fault-tolerant, distribuite e multi-livello. Per ottenere queste caratteristiche
j2ee prevede che vengano eseguiti dei componenti modulari su un Appli-
cation Server. Le specifiche della piattaforma j2ee sono definite da Sun
Microsystems, ora Oracle [Oracle, 2011].
Un Application Server e un software che fornisce l’infrastruttura e le
funzionalita di supporto, sviluppo ed esecuzione di applicazioni e componenti
server in un contesto distribuito. Si tratta di un insieme di servizi orientati
alla realizzazione di applicazioni multilivello ed enterprise, con alto grado di
complessita, orientate per il web, che le applicazioni possono utilizzare per il
loro funzionamento.
In figura 4.1 viene mostrato il diagramma uml dei componenti del pro-
totipo nel quale sono in evidenzia i principali “moduli” che costituiscono il
sistema e le loro dipendenze reciproche.
Il sistema puo essere logicamente suddiviso principalmente in tre compo-
nenti:
• application server : rappresenta il server che esegue l’applicazione, for-
nisce le informazioni al client (tramite l’utilizzo di chiamate http asin-
crone) e recepisce le informazioni relative all’ambiente che vengono in-
viate al sistema dalla rete di sensori posta nell’area di lavoro. I “servizi”
CAPITOLO 4. ARCHITETTURA DEL PROTOTIPO 43
Fig. 4.1: Diagramma uml dei componenti del sistema
che l’applicazione espone sono realizzati utilizzando il meccanismo del-
le servlet e cioe realizzando degli oggetti in grado di rispondere alle
chiamate esterne all’application server;
• client : rappresenta l’unita hardware (ad esempio un pc, un tablet,
ecc.) attraverso il quale l’operatore addetto al controllo dell’area di
lavoro interagisce con il sistema. L’applicativo potra essere consultato
tramite l’utilizzo di un broswer web standard. L’applicazione eroga e
mette a disposizione un’interfaccia web, tramite la quale e possibile
controllare i movimenti e il livello di rischio dell’area di lavoro e delle
persone che in esso operano;
• environment : rappresenta l’area di lavoro monitorata tramite l’utilizzo
della rete di sensori, che comunicano eventuali cambiamenti dei pa-
CAPITOLO 4. ARCHITETTURA DEL PROTOTIPO 44
rametri ambientali tramite l’utilizzo di chiamate http di tipo “post”,
effettuate verso l’application server.
4.3 Parte Server
Questa sezione costituisce il nodo centrale del prototipo quella che realizza il
ciclo mape. E composta da un application server che implementa le tecno-
logie JavaServer Page e Java Servlet, nelle quali risiede l’applicazione web.
L’application server fornisce il codice html e Javascript richiesto dal client
tramite il protocollo standard http. L’application server gestisce, inoltre,
le richieste che giungono dal client implementando le servlet che stanno alla
base del funzionamento delle Remote Procedure Call (rpc) provenienti dal
browser web. L’application server reagisce, infine, alle modifiche dell’ambien-
te che gli vengono segnalate tramite delle chiamate http-post che giungono
dalla rete di sensori. L’interazione tra client/sensori e application server av-
viene tramite l’utilizzo di Servlet, cioe di classi Java in grado di rispondere a
delle chiamate esterne tramite l’utilizzo del protocollo http.
Possiamo suddividere l’applicazione, che viene eseguita dall’application
server, in tre livelli:
• livello Servlet : contiene le servlet che si occupano di gestire le richieste
che giungono dal client e dalla rete di sensori realizzando di fatto il
modulo Data Collector del ciclo mape;
• livello Business Logic: contiene la logica applicativa, sia le funzionalita
che registrano cambiamenti al modello delle entita (fase monitoring del
ciclo mape) sia relativamente all’analisi dei dati alla ricerca di eventuali
situazioni rischiose (fase analyzing), sia infine alla pianificazione delle
corretta strategia da applicare nel caso ci si trovi in presenza di una
situazione di emergenza (fase planning). Tutte le funzionalita vengono
richiamate dal livello servlet per realizzare le richieste del client e della
rete di sensori;
CAPITOLO 4. ARCHITETTURA DEL PROTOTIPO 45
• livello Model : rappresenta il modello delle entita, esso contiene tutti gli
oggetti necessari a rappresentare il mondo esterno e indispensabili per
il calcolo del rischio e delle strategie.
4.3.1 Architettura del Modello delle Entita
In figura 4.2 e mostrato il diagramma delle classi che realizza il modello delle
entita.
La classe principale come mostrato in figura e la classe Entity da cui
derivano tutte le altri classi. Ogni classe derivata da Entity rappresenta un
elemento dell’ambiente di lavoro.
Classe Entity
Rappresenta un’entita presente nell’area di lavoro. Contiene le funzionalita
e gli attributi comuni a tutte le entita come la posizione, definita dalla classe
beneLocation e un identificativo (attributo id). La classe Entity, e quindi
anche tutte le sue specializzate, estendono la classe Observable, che permette
di implementare il design pattern Observer [Gamma et al., 2002], in questo
modo e possibile, per un’altro oggetto, essere informato quando un’entita
cambia il suo stato come ad esempio la sua posizione.
Classe Environment
E’ una classe astratta, che rappresenta un ambiente di lavoro. I suoi prin-
cipali attributi sono la dimensione, memorizzata attraverso la classe Dimen-
sion e l’elenco degli access point presenti al suo interno (attributo ac-
cessPoints). Le classi concrete che specializzano la classe Environment
sono:
• OpenArea: rappresenta un’area di lavoro all’aperto;
• ClosedArea: rappresenta un’area di lavoro chiusa;
CAPITOLO 4. ARCHITETTURA DEL PROTOTIPO 46
Fig. 4.2: Diagramma delle classi del modello del modello delle entita
CAPITOLO 4. ARCHITETTURA DEL PROTOTIPO 47
• ComplexEnvironment: rappresenta un’area di lavoro composta da piu
aree
Classe Usable
E una classe astratta che rappresenta un generico elemento che puo essere
usato da un lavoratore per compiere uno specifico compito all’interno dell’area
di lavoro. La gerarchia di classi specializzate si suddivide ulteriormente in:
• Tool: e una classe astratta che rappresenta un qualsiasi strumen-
to di lavoro utilizzato dal lavoratore, come ad esempio un martello
rappresentato dalla classe Hammer;
• Machinery: e una classe astratta che rappresenta un automezzo utiliz-
zato da un lavoratore all’interno dell’area operativa come ad esempio
un camion, classe Truck
Classe PersonalProtecionElement
E’ una classe astratta che rappresenta un qualsiasi elemento protettivo a
disposizione del lavoratore come ad esempio una giubbotto a prova di fuoco,
classe FireproofJacket.
Classe PersonalInformationDevice
E’ una classe astratta che rappresenta un dispositivo informativo o un senso-
re indossabile in possesso di un lavoratore, come ad esempio un pda (classe
PDA). Questa classe implementa l’interfaccia HasValue poiche, nel caso di un
sensore indossabile, deve essere possibile impostare il valore che il sensore
fisico rileva, come ad esempio il numero di pulsazioni al minuto o la tempera-
tura corporea. Poiche questi valori cambiano nel tempo, ogni qualvolta che
cio accade vengono notificati gli Observer per far si che venga ricalcolato il
valore di rischio e analizzata la situazione alla ricerca di eventuali situazioni
di rischio.
CAPITOLO 4. ARCHITETTURA DEL PROTOTIPO 48
Classe RiskSource
Questa classe e la generalizzazione di tutte le entita che generano un rischio
nell’ambiente. Il livello di rischio generato dall’entita nel punto (x, y) e otte-
nuto richiamando il metodo getRiskMapValue, che lo calcola utilizzando la
curva gaussiana che e stata descritta dal modello analizzato nel capitolo 3,
occorre quindi che ogni entita fornisca valore medio, deviazione standard e
un valore scalare. Per quanto riguarda il valore medio questo viene ricavato
calcolando la distanza della sorgente dal punto (x, y) mentre la deviazione
standard e il valore scalare devono essere calcolati dalle classi concrete tra-
mite i metodi getStandardDeviationValue e getScalingValue. Di seguito
vengono descritte le classi che compongono la gerarchia derivante dalla classe
RiskSource.
Classe EnvironmentInformativeDevice
Rappresenta un sensore ambientale come ad esempio un rilevatore di gas
(classe GasSensor) o un rilevatore di temperatura (class EnvironmentTem-
peratureSensor). Anche questa classe, cosı come la classe PersonalInfor-
mativeDevice, implementa l’interfaccia HasValue che permette al sistema di
memorizzare i valori che vengono rilevati dal sensore fisico posizionato nel-
l’ambiente di lavoro e proprio per questo motivo ogni qualvolta il valore viene
variato, la classe EnvironmenteInformativeDevice, notifica gli Observer
per permettere il ricalcolo del livello di rischio complessivo e analizzare il
sistema alla ricerca di situazioni pericolose.
Classe EnvironmentProtectionElement
Rappresenta quegli elementi posizionati nell’ambiente a protezione dei lavo-
ratori, come ad esempio un estintore o piu in generale un insieme di strumenti
a protezione di un incendio (classe FireProtectionKit). Poiche questi ele-
menti sono protettivi la loro curva risultera negativa in modo da abbassare
il rischio nelle immediate vicinanze.
CAPITOLO 4. ARCHITETTURA DEL PROTOTIPO 49
Classe PlantElement
Rappresenta gli elementi che sono fonte di rischio posizionati all’interno
dell’area di lavoro, come ad esempio tubi del gas (class GasPipe) e prese
elettriche (classe PowerPlug).
Classe Person
Rappresenta un lavoratore presente nell’area di lavoro, questa entita oltre ad
essere una sorgente di rischio, e anche un elemento che possiede un proprio
livello di rischio, e possibile infatti ottenere il livello di rischio personale
(Personal Risk Index o pri) del lavoratore tramite il metodo getPRI.
Classe AccessPoint
Rappresenta un accesso nell’area di lavoro come ad esempio una porta o
una finestra. L’attributo type indica se l’accesso e di solo d’ingresso (in),
di sola uscita (out) o sia di uscita che d’ingresso (in-out). In questo caso
l’entita Access Point contribuisce ad abbassare il rischio all’interno dell’area
di lavoro.
4.3.2 Architettura della Fase di Monitoring
In figura 4.3 e mostrato il diagramma delle classi che compongono l’architet-
tura della fase di monitoring dell’applicazione.
Possiamo suddividere in quattro macro responsabilita la logica dell’appli-
cazione:
• registrazione cambiamenti alle entita del modello;
• analisi dei cambiamenti alla ricerca di situazioni di pericolo;
• selezione della corretta strategia;
CAPITOLO 4. ARCHITETTURA DEL PROTOTIPO 50
Fig. 4.3: Diagramma delle classi necessarie alla realizzazione della fase dimonitoring
CAPITOLO 4. ARCHITETTURA DEL PROTOTIPO 51
• caricamento del modello delle entita attraverso l’utilizzo di un file xml
descrittivo dell’area di lavoro
Classe RMS
La classe RMS e l’oggetto centrale di tutta l’applicazione. Le principali fun-
zionalita di questa classe sono:
• interagire con il modello delle entita, interrogandolo e aggiungendo
nuovi elementi;
• creare il modello delle entita a partire da un file xml;
• ottenere la mappa del rischio dell’area di lavoro
La classe RMS viene quindi utilizzata da tutte le servlet sia per ottenere le
informazioni sul modello delle entita (come ad esempio la lista delle persone
presenti nell’area di lavoro, la mappa del rischio, ecc.) sia per modificare i
parametri legati alle entita che rappresentano l’ambiente di lavoro (come ad
esempio il valore di temperatura rilevato da un sensore, la posizione di un
lavoratore all’interno dell’area di lavoro, ecc.).
Classe EntityObserver
Questa classe implementa il design pattern Observer. Ha la responsabili-
ta di “osservare” tutte le modifiche che avvengono alle entita del modello.
Queste ultime infatti notificano i loro cambiamenti richiamando il metodo
update presente sulla classe EntityObserver. Questo metodo recupera l’en-
tita che ha subito un cambiamento e la inserisce in una coda rappresentata
dall’oggetto PushableQueue.
Classe PushableQueue
E la coda contenente l’elenco delle entita che hanno subito un cambiamento ai
loro parametri, come ad esempio la posizione all’interno dell’area di lavoro.
CAPITOLO 4. ARCHITETTURA DEL PROTOTIPO 52
Questa coda e utilizza dalla servlet RMSService che la controlla costante-
mente in modo da notificare il client quando e presente nella coda una nuova
entita. In questo modo le modifiche al modello vengono “spinte” dal server
verso il client realizzando cosı la tecnica “server push” [Wikipedia, 2011c].
Classe RiskMapper
Questa classe contiene l’algoritmo che calcola il valore di rischio di uno spe-
cifico punto dell’area di lavoro, per fare cio ha bisogno di interagire con la
classe RMS per ottenere le informazioni sulle entita presenti nell’area di lavoro
per poter poi calcolare la loro influenza, in termini di livello di rischio, nel
punto dell’area di lavoro oggetto del calcolo. Questa classe e principalmente
utilizzata dalla servlet WriteMapRisk che si occupa di creare l’immagine che
rappresenta la mappa di rischio dell’area di lavoro, che viene visualizzata sul
client.
4.3.3 Architettura delle Fasi di Analyzing e Planning
In figura 4.4 e mostrato il diagramma della classi che implementano le fasi di
analyzing e monitoring del prototipo.
Classe RiskSituationObserver
Questa classe implementa il design pattern Observer [Gamma et al., 2002],
e infatti l’Observer per tutte le entita del modello. Ha la responsabilita di
verificare se si e in presenza di una situazione di rischio (come ad esempio una
fuga di gas), e in tal caso crea l’oggetto relativo alla classe che rappresenta la
situazione di rischio in corso (come ad esempio la classe GasLeakageSitua-
tion). Quest’oggetto viene poi aggiunto alla coda PushableQueue in modo
che venga notificato il cliente della situazione di rischio che si sta verificando
nell’ambiente e delle strategie da adottare per far fronte a questa situazione.
CAPITOLO 4. ARCHITETTURA DEL PROTOTIPO 53
Fig. 4.4: Diagramma delle classi della fase di analyzing e planning
Classe GasLeakageSituation
Questa classe rappresenta una situazione di rischio. Ha la responsabilita di
fornire la migliore strategia da applicare per far fronte all’emergenza. Per fare
cio la classe utilizza un oggetto che implementa l’interfaccia ConditionPat-
tern (come ad esempio la classe RiskProximityPatter) per verificare alcune
CAPITOLO 4. ARCHITETTURA DEL PROTOTIPO 54
condizioni sull’ambiente di lavoro e sulle entita (come ad esempio la presenza
di lavoratori “vicino”al fonte di rischio) e scegliere la strategia migliore (come
ad esempio Strategy1 e Strategy2).
Interfaccia Strategy
L’interfaccia Strategy rappresenta una strategia che e, in generale, composta
da un insieme di Action. Una Strategy puo essere una strategia semplice
(come ad esempio Strategy1 e Strategy2) oppure una strategia compo-
sta, cioe una CompositeStrategy che consiste in una strategia derivante
dall’unione di strategie, a che loro volta possono essere semplici o composte.
Classe Action
Questa classe rappresenta un’azione da compiere nell’area di lavoro o per
un lavoratore per far fronte ad una situazione di pericolo o di emergenza.
La classe possiede gli attributi description e priority, il primo descrive
l’azione da compiere, il secondo la priorita con la quale eseguire l’azione
all’interno della strategia.
4.3.4 Architettura del Parser xml per la Definizionedell’Ambiente
La generazione iniziale delle istanze delle classi che descrivono l’ambiente
operativo viene effettuata a run-time in maniera “parametrica”. Esiste cioe
un file xml di configurazione iniziale dell’ambiente, che viene interpretato e
che descrive la configurazione stessa. In figura 4.5 e mostrato il diagramma
delle classi che implementano la funzionalita di lettura del file xml che serve
a definire il modello delle entita.
Il file xml di configurazione iniziale e strutturato in modo che sia possibile
definire, oltre alle aree che compongono l’ambiente di lavoro, anche le entita
presenti in esso, siano essi delle persone, degli strumenti di lavoro in possesso
CAPITOLO 4. ARCHITETTURA DEL PROTOTIPO 55
Fig. 4.5: Diagramma delle classi per il parser del file xml di definizionedell’ambiente
ai lavoratori oppure i sensori presenti nell’ambiente utili alle varie rilevazioni
di parametri.
Classe Parser
Questa classe ha la responsabilita di leggere il file xml, di creare le necessarie
entita con i relativi attributi e di aggiungerle al sistema utilizzando la classe
RMS. In alcuni casi la classe Parser si affida ad altre classi, come ad esempio
CAPITOLO 4. ARCHITETTURA DEL PROTOTIPO 56
EnvironmentCreationFactory per la costruzioni di entita piu strutturate,
come gli Environment.
Classi EnvironmentCreationFactory e InformativeDeviceCreationFac-
tory
Queste classi hanno la responsabilita di leggere parte del file xml e di creare le
entita a cui fanno riferimento con i relativi attributi e sono specializzate nella
creazione di particolari entita, che richiedono una creazione piu strutturata.
4.4 Parte Client
Quest’area e composta da un terminale hardware che tramite un browser web
interagisce con il sistema, quest’ultimo infatti mette a disposizione una serie
di interfacce grafiche realizzate tramite la tecnica ajax1. Questa tecnica pre-
vede che lo scambio dei dati tra web browser e server avvenga in background
(e cioe in modo asincrono rispetto agli invii di dati effettuati direttamente
dall’utente dell’applciazione) in modo da consentire l’aggiornamento dina-
mico di una pagina web senza esplicito ricaricamento da parte dell’utente
[Wikipedia, 2011a].
Per realizzare queste interfacce e stato utilizzato il framework open source
gwt (Google Web Toolkit, [Google, 2011]) che permette di sviluppare appli-
cazioni dotate di front-end Javascript per l’interazione ajax, scrivendo il
codice esclusivamente in Java. L’operazione di “trasformare” il codice Java
sorgente nel corretto mix di codice html e Javascript sara infatti poi compito
del compilatore, messo a disposizione nell’ambito del toolkit stesso.
Per la creazione delle interfacce grafiche, il toolkit mette a disposizione
un insieme di componenti, detti widget, che implementano e permettono di
realizzare tutti gli elementi tipici di una pagina web, come elementi Textbox
o elementi Button. Il framework possiede inoltre un potente meccanismo
1 Asynchronous JavaScript and xml
CAPITOLO 4. ARCHITETTURA DEL PROTOTIPO 57
per la comunicazione con la parte server dell’applicativo, chiamato gwt-
rpc. Questo sistema permette di passare istanze di oggetti da e verso il
server, utilizzando lo standard http e mascherando tutta la complessita che
si avrebbe, ad esempio, nel caso di utilizzo di piu obsolete metodologie di
scambio dati, quale la serializzazione degli oggetti. Questo meccanismo puo
essere utilizzato anche per effettuare in modo asincrono e in maniera del tutto
trasparente, delle chiamate a funzioni implementate nelle servlet Java.
Nella creazione del prototipo e stata utilizzata anche la libreria aggiun-
tiva SmartGWT [Isomorphic Software, 2011], che ha permesso di arricchi-
re l’insieme dei widget presenti nella versione base del framework GWT.
SmartGWT, infatti, mette a disposizione un insieme di componenti grafici
piu complessi (come ad esempio le griglie di dati), oltre a fornire tutta la
logica per gestire con semplicita il caricamento dei dati da e verso il server.
4.4.1 Struttura dei Package dell’Interfaccia Grafica
L’interfaccia grafica del prototipo e composta da una serie di aree che mo-
strano tutti i dati relativi all’ambiente operativo. Sono presenti tutte le
informazioni statiche sull’area di lavoro come la lista degli access point e dei
plant element, oltre alle informazioni dinamiche come la mappa del rischio
e l’elenco dei lavoratori e del loro livello di rischio. Le informazioni dina-
miche sono aggiornate ogni qualvolta un sensore comunica all’applicativo un
cambiamento del parametro che controlla (es. livello di gas nell’aria, o posi-
zione di un lavoratore). La composizione dei package costituenti le interfacce
grafiche e mostrata nel diagramma di figura 4.6.
Il package Panel contiene i pannelli che sono mostrati nella pagina prin-
cipale dell’applicazione, il package List e invece composto dall’insieme delle
classi che definiscono le liste di elementi da visualizzare. Per generare e ge-
stire gli elenchi, ogni lista ha bisogno di un Datasource e cioe di una classe
in grado di recuperare i dati dal server tramite l’utilizzo delle rpc. Que-
ste ultime sono dichiarate nel package Service. Il package TO contiene i
cosiddetti “Transfer Object” e cioe quegli oggetti che vengono serializzati e
CAPITOLO 4. ARCHITETTURA DEL PROTOTIPO 58
Fig. 4.6: Diagramma dei Package dell’interfaccia utente
passati da e verso il server contenente i dati da visualizzare, come ad esempio
i lavoratori con la loro posizione e il loro livello di rischio. Il package Win-
dow, infine, contiene la definizione della finestra che visualizza la strategia da
adottare quando il sistema rileva una situazione di rischio. Questa finestra
appare al centro dello schermo non appena viene riconosciuta una situazione
di pericolo.
4.4.2 Struttura delle Classi dell’Interfaccia Grafica
L’insieme delle principali classi costituenti l’interfaccia grafica e delle loro
dipendenze e mostrato in figura 4.7
Classe MonitorPanel
E responsabile della creazione del pannello principale costituito dalla mappa
del rischio e dall’insieme delle liste delle entita presenti nell’area operativa.
Per questo motivo e costituito dall’insieme di oggetti che derivano dalla clas-
CAPITOLO 4. ARCHITETTURA DEL PROTOTIPO 59
Fig. 4.7: Diagramma delle classi dell’interfaccia utente
se AbstractList. La mappa di rischio e invece visualizzata richiedendo la
relativa immagine al server che si occupa di aggiornarla ogni qualvolta questa
viene richiesta.
Classe AbstractList
Questa classe rappresenta una lista di entita. Esiste una classe specializzata
per ogni elenco di entita che devono essere visualizzate sul pannello, come
ad esempio le persone (gestite attraverso la classe PersonList). Ognuna di
queste classi deve avere associato un Datasource che rappresenta il modello
di dati della lista.
CAPITOLO 4. ARCHITETTURA DEL PROTOTIPO 60
Classe AbstractDS
Rappresenta il collegamento con il modello dei dati Datasource associato ad
una o piu AbstractList. Il suo compito e principalmente quello di aggior-
nare i dati della lista ogni volta che avviene un cambiamento al modello delle
entita. Per caricare i dati utilizza delle chiamate rpc implementate nelle
relative classi, come ad esempio la classe EnvironmentService. La classe
generica AbstractDS implementa inoltre l’interfaccia Observer che le per-
mette di essere “aggiornata” quando i dati di un’entita vengono modificati.
Quest’ultimo compito e gestito della classe ServerPush.
Classe ServerPush
Questa classe implementa il design pattern Observer permettendo cosı di es-
sere informato quando un elemento del modello dei dati viene aggiornato.
La classe infatti apre un canale di comunicazione con il server utilizzando il
servizio RMSService e il server, come spiegato nei paragrafi precedenti, tra-
smette su questo canale i dati delle entita che hanno avuto un cambiamento,
permettendo cosı all’interfaccia grafica di aggiornarsi visualizzando i nuovi
dati. Cio avviene richiamando gli opportuni Datasource.
4.5 Environment
Fanno parte di quest’area sia la rete di sensori e dispositivi informativi presen-
ti nell’ambiente e indossati dai lavoratori sia lo strato software predisposto
per comunicare con essi. Per gli scopi di questa Tesi, la rete di sensori e
stata simulata implementando un applicativo che “simula”, appunto, il com-
portamento dei sensori e richiama le opportune servlet, che fanno parte del
prototipo e sono preposte alle comunicazioni con i sensori. Le servlet del
prototipo sono mostrate nel diagramma delle classi di figura 4.8.
CAPITOLO 4. ARCHITETTURA DEL PROTOTIPO 61
Fig. 4.8: Diagramma delle classi dell’area Environment
4.5.1 Struttura delle Servlet di Comunicazione con iSensori
Il prototipo mette a disposizione due servlet per la comunicazione con la rete
di sensori. La servlet SetSensorValue viene chiamata e, di conseguenza,
utilizzata dai sensori che sono deputati a rilevare i parametri ambientali e
personali, come ad esempio la temperatura esterna e il numero di battiti
cardiaci di un lavoratore. La seconda servlet MoveEntity e utilizzata in-
vece dai dispositivi che rilevano la posizione delle entita mobili all’interno
dell’ambiente di lavoro, come i lavoratori.
CAPITOLO 4. ARCHITETTURA DEL PROTOTIPO 62
Classe SetSensorValue
E la servlet che permette di impostare il valore del parametro di un sensore,
come ad esempio il livello di gas nell’aria o il numero di pulsazioni di un
lavoratore. La servlet riceve in ingresso l’identificativo del sensore che vuole
comunicare con il prototipo e il valore rilevato. La servlet utilizza la classe
RMS e l’identificativo ricevuto per ricercare l’oggetto del modello delle entita
che rappresenta il sensore fisico. Una volta ottenuta l’entita concreta, la
servlet provvede ad aggiornarne il valore dei parametri.
Classe MoveEntity
E la servlet che permette di modificare la posizione di un’entita nel model-
lo dei dati. L’oggetto riceve l’identificativo dell’entita e la sua nuova po-
sizione all’interno dell’area di lavoro. La servlet, tramite la classe RMS e
l’identificativo, recupera la relativa entita e ne aggiorna la posizione.
4.5.2 Simulatore
Il simulatore e un’applicazione Java che riceve in ingresso la configurazione
degli eventi dei sensori desiderata. In particolare, l’inizializzazione del si-
mulatore avviene tramite un file xml che indica quali servlet devono essere
richiamate nei vari istanti temporali, definendo anche il valore dei parametri
da inviare. In questo modo e possibile simulare lo spostamento delle entita
all’interno dell’area di lavoro e il cambiamento dei parametri letti dai sensore.
4.6 Sequence Diagram
Di seguito vengono mostrati i sequence diagram uml che descrivono come gli
oggetti collaborano ed interagiscono tra di loro al fine di rilevare e memoriz-
zare i valori dei parametri ambientali (fase monitoring del processo mape),
calcolare i nuovi livelli di rischio (fase analyzing) e, nel caso si rilevi una si-
CAPITOLO 4. ARCHITETTURA DEL PROTOTIPO 63
Fig. 4.9: Sequence Diagram della lettura di un parametro ambientale
tuazione di pericolo, scelgiere la migliore strategia (fase planning). Vengono
inoltre mostrati i sequence diagram del processo che permette la creazione
della mappa di rischio e dell’aggiornamento dei dati nell’interfaccia grafica.
4.6.1 Fase Monitoring : Lettura di un Parametro Am-bientale
La figura 4.9 mostra quali oggetti sono coinvolti e come essi collaborano
durante la rilevazione di un valore ambientale proveniente da un sensore
posto nell’area di lavoro o indossato da un lavoratore.
Il processo ha inizio quando un sensore chiama la servlet SetSensorValue
dell’application server fornendo il suo identificativo e il nuovo valore rilevato
(ad esempio un nuovo valore del livello di gas nell’aria). A questo punto
la servlet utilizza l’oggetto RMS per ricercare l’entita associata all’identifica-
tivo inviato dal sensore. Una volta ottenuto l’oggetto Entity appropriato
(nel caso dell’esempio e un oggetto di tipo GasSensor) viene richiamato il
CAPITOLO 4. ARCHITETTURA DEL PROTOTIPO 64
Fig. 4.10: Sequence Diagram per il riconoscimento di situazioni di rischio
metodo setValue passandogli come parametro il nuovo valore rilevato. Que-
sta funzione, oltre ad impostare nell’oggetto Entity il nuovo valore, notifica
tutti i suoi osservatori informandoli del cambiamento. Vengono notificati in
particolare gli observer EntityObserver (utilizzato per aggiornare l’inter-
faccia grafica) e RiskSituationObserver (utilizzato per attivare la fase di
analyzing).
4.6.2 Fase Analyzing : Verifica Situazioni di Rischio
In figura 4.10 viene mostrato il sequence diagram che mostra come gli oggetti
coinvolti dal processo interagiscono tra di loro per riconoscere e segnalare una
situazione di rischio.
In figura viene mostrato come il sistema reagisce in seguito ad un ag-
giornamento del valore di gas nell’area, letto da un sensore. L’oggetto che
si occupa del riconoscimento delle situazioni di rischio e RiskSituationOb-
server. Quest’oggetto viene attivato tutte le volte che un’entita associata
ad un sensore cambia il suo valore, relativo ad un parametro ambientale.
Quando cio accade, vengono attivati i controlli sull’ambiente per verificare
se e in atto una situazione pericolosa. Ad esempio, se viene letto su un sen-
CAPITOLO 4. ARCHITETTURA DEL PROTOTIPO 65
Fig. 4.11: Sequence Diagram per la scelta della strategia
sore di gas un valore oltre una soglia limite, allora si e in presenza di una
probabile fuga di gas. In questo caso l’oggetto RiskSituationObserver crea
un oggetto che rappresenta la situazione di rischio in atto. In figura 4.10,
la situazione di rischio e rappresentata dall’oggetto GasLeakageSituation
che viene inserito nella coda PushableQueue. Questo permette di attivare
le procedure per far fronte alla situazione di rischio. Nel caso del prototipo,
viene notificato il client che visualizzera le informazioni sul tipo di pericolo in
atto e sulla strategia da adottare all’operatore, tramite una chiamata ajax
verso l’interfaccia grafica dell’applicativo.
4.6.3 Fase di Planning : Scelta della Strategia
In figura 4.11 viene mostrato il sequence diagram relativo alla fase di planning
per la scelta della strategia da adottare per far fronte ad una situazione di
pericolo rilevata dalla fase di analyzing.
Il processo ha inizio quando l’oggetto RiskSituationObserver ha rile-
vato una situazione di pericolo, ad esempio il valore di gas di un sensore ha
superato una certa soglia, come illustrato nel precedente paragrafo. In que-
CAPITOLO 4. ARCHITETTURA DEL PROTOTIPO 66
sto caso viene creato l’oggetto relativo alla situazione di pericolo, ad esempio
GasLeakageSituation. Quest’ultimo ha associato un’oggetto che incapsula
la logica per la scelta della strategia piu adatta. Nella figura viene crea-
to l’oggetto RiskProximityPattern che in base alla distanza dei lavoratori
dalla fonte di pericolo adotta l’opportuna strategia. Per effettuare questa
scelta l’oggetto recupera l’insieme delle persone coinvolte dal pericolo (ad
esempio le persone che lavorano all’interno dell’area in cui e posizionato il
sensore che ha rilevato la fuga di gas) e, per ognuna, calcola la distanza dalla
fonte di pericolo. A seconda del risultato della verifica l’oggetto GasLeaka-
geSituation puo prendere la decisione su quale strategia adottare. Nel caso
utilizzato per l’esempio riportato in figura 4.11, sceglie la strategia Strate-
gy1, che si occupa di creare l’insieme delle azioni, cioe di oggetti Action, che
la compongono.
4.6.4 Calcolo della Mappa di Rischio
In figura 4.12 e mostrato il sequence diagram per il processo di calcolo della
mappa di rischio.
Il processo ha inizio quando viene richiesta l’immagine delle mappa di ri-
schio dall’oggetto dell’interfaccia grafica MonitorPanel. Per fare cio l’oggetto
richiama la servlet WriteMapRisk che riceve dal MonitorPanel le indicazioni
necessarie per decidere l’area della quale calcolare la mappa di rischio. La
servlet, innanzitutto, recupera l’oggetto Environment associato all’area ri-
chiesta, richiamando lo specifico metodo dalla classe RMS. Successivamente,
la servlet richiede la creazione della mappa per la specifica area, con il metodo
writeRiskMap. L’oggetto RMS, crea un’instanza della classe RiskMapper che
contiene la logica algoritmica necessaria per calcolare il livello di rischio per
uno specifico punto dell’area di lavoro. L’oggetto RMS, per realizzare la map-
pa, richiama il metodo getValue(x, y) per ogni punto dell’area di lavoro
per la quale si vuole creare la mappa di rischio.
L’oggetto RiskMapper effettua i seguenti passaggi per calcolare il livello
di rischio: recupera l’elenco delle sorgenti di rischio presenti nell’area, cioe
CAPITOLO 4. ARCHITETTURA DEL PROTOTIPO 67
Fig. 4.12: Sequence Diagram per il calcolo della mappa di rischio
oggetti di tipo RiskSource, e per ognuno di essi richiede il livello di rischio
generato nel punto (x, y), per poi sommarli tra di loro, ottenendo cosı il livel-
lo complessivo di rischio nel punto richiesto. Le sorgenti di rischio calcolano
il valore di rischio da loro generato calcolando il valore della curva gaussia-
na generata utilizzando i parametri di deviazione standard ed utilizzando il
fattore di proporzione proprio di ogni sorgente. Come media di ogni curva
gaussiana viene utilizzata la distanza della sorgente dal punto in esame.
4.6.5 Aggiornamento dell’Interfaccia Grafica
In figura 4.13 e descritto il sequence diagram che mostra come gli oggetti
interagiscano tra di loro al fine di aggiornare l’interfaccia grafica, in seguito
a una modifica dei parametri ambientali rilevata dalla rete dei sensori.
L’aggiornamento dell’interfaccia grafica e guidato dall’oggetto Server-
CAPITOLO 4. ARCHITETTURA DEL PROTOTIPO 68
Fig. 4.13: Sequence Diagram per l’aggiornamento dell’interfaccia grafica
Push che tiene aperto un canale di comunicazione tra il client e il server.
A questo scopo l’oggetto effettua una chiamata gwt-rpc per sapere se si
sono verificati aggiornamenti alle entita del modello. La servlet predisposta
ad accogliere la chiamata dell’oggetto ServerPush e implementata dall’og-
getto RMSService, che, una volta ricevuta la richiesta, provvede a girarla
all’oggetto PushableQueue. Quest’ultimo non risponde alla chiamata fino a
che non esistono oggetti nella sua coda oppure allo scadere di un timeout.
Questo meccanismo di delay viene messo in atto attuo per evitare che il
client effettui in continuazione chiamate get-rpc che, essendo realizzate sul
CAPITOLO 4. ARCHITETTURA DEL PROTOTIPO 69
protocollo http potrebbero appesantire molto il carico computazionale del
browser web, con una riduzione dei tempi di risposta dell’applicativo. Se,
invece, nella coda e presente un’entita, questa viene immediatamente inviata
al client, che chiama il metodo di aggiornamento, refresh, del Datasource
associato al tipo di entita che e stata modificata. Nell’esempio rappresentato
nella figura 4.13, l’oggetto e PersonDS. Il Datasource effettua una chiamata
al server sfruttando l’oggetto PersonService per farsi restituire l’elenco ag-
giornato delle persone, in modo poi da aggiornare l’oggetto PersonList, che
e responsabile di visualizzare l’elenco nell’interfaccia grafica.
Capitolo 5
Esempi
In questo capitolo vengono mostrati alcuni esempi di utilizzo del prototipo.
In particolare viene simulata una attivita lavorativa nell’ambito di un cantiere
o area di lavoro chiusa, evidenziando le informazioni che il prototipo rileva
per fornirle all’operatore. In una seconda simulazione viene mostrato come
il prototipo rileva e fornisce le informazioni necessarie per far fronte ad una
fuga di gas.
5.1 Monitoring dell’Ambiente
In figura 5.1 viene mostrata la schermata che si presenta all’operatore quando
accede all’applicativo.
La schermata e suddivisa in sei aree:
• l’elenco degli environment;
• la mappa dell’ambiente;
• la mappa di rischio dell’area selezionata;
• l’elenco delle persone presenti nell’ambiente di lavoro;
• l’elenco dei machinery/tool usati dai lavoratori;
70
CAPITOLO 5. ESEMPI 71
Fig. 5.1: Interfaccia grafica del prototipo
• l’elenco dei dispositivi informativi presenti nell’area operativa;
• l’elenco dei plant element.
Tutti gli elementi con attributi dinamici, come ad esempio le persone, sono
aggiornate automaticamente dall’applicativo in background, cioe in modo
asincrono.
La mappa di rischio rappresenta con colori diversi i vari livelli di rischio
presenti nell’area di lavoro. Le tonalita variano dal blu, che rappresenta un
livello nullo di rischio, al rosso che rappresenta, invece, un livello di rischio
alto. Selezionando una persona dalla lista visualizzata nell’interfaccia, e pos-
sibile ottenere maggiori informazioni sul suo livello di rischio individuale pri,
oltre a seguire gli spostamenti del lavoratore sulla mappa dell’ambiente. Co-
Fig. 5.2: Mappa dell’ambiente e scheda del lavoratore
CAPITOLO 5. ESEMPI 72
Fig. 5.3: Evoluzione della mappa del rischio
me mostrato in figura 5.2, infatti, la persona selezionata viene evidenziata in
verde sulla mappa dell’ambiente e al posto della mappa di rischio compare la
scheda legata al lavoratore. Nella scheda del lavoratore sono elencate tutte
le varie componenti che compongono il livello di rischio individuale.
Il prototipo permette, quindi, di tenere sotto controllo sia un’area (tra-
mite la visualizzazione della mappa di rischio) sia di seguire l’andamento del
rischio di una specifica singola persona. La scheda sulla composizione del
pri di una persona permette inoltre all’operatore di individuare i fattori che
compongono il rischio individuale associato al lavoratore. Il prototipo evolve
nel tempo, aggiornando la mappa del rischio come evidenziato dalla figura
5.3 che mostra in sequenza l’andamento della mappa del rischio durante lo
svolgimento di una normale attivita lavorativa.
CAPITOLO 5. ESEMPI 73
Fig. 5.4: Situazione iniziale nella simulazione di una fuga di gas
5.2 Simulazione: Una Fuga di Gas
Per verificare le funzionalita del prototipo e stato simulata una situazione di
rischio dovuta alla rottura di un tubo di gas. Per semplificare il test l’am-
biente e costituito da una sola area nella quale sono presenti due lavoratori,
uno dei quali posizionato nelle vicinanze di una tubatura del gas e al relativo
sensore di rilevamento di sostanze nocive presenti nell’aria. La situazione
iniziale rilevata dal prototipo e mostrata in figura 5.4.
Come si vede analizzando la mappa del rischio, esiste solo un leggero
livello di rischio vicino alla tubatura del gas dovuto alla presenza della tuba-
tura stessa, mentre il rischio legato al rilevamento delle sostanze da parte del
sensore del gas e nullo. Le due macchie presenti al centro dell’area di lavo-
ro sono dovute alla presenza dei lavoratori stessi, mentre il livello di rischio
individuale dei lavoratori e praticamente nullo.
Avviando la simulazione, che prevede un innalzamento con andamento
lineare del livello di gas rilevato dal sensore, la mappa del rischio evolve
e l’area di lavoro assume una colorazione diversa che sta ad indicare un
innalzamento del livello di rischio, come si puo rilevare dalla figura 5.5 che
mostra l’evoluzione della mappa di rischio nel corso della simulazione.
CAPITOLO 5. ESEMPI 74
Fig. 5.5: Evoluzione della mappa del rischio nella simulazione di una fugadi gas
Come si puo notare dalla mappa del rischio, la zona immediatamente
vicina al rilevatore di gas ha un livello di rischio altissimo (colore rosso) che
decresce all’aumentare della distanza dal sensore. La zona presente in alto
nella mappa del rischio con un colore piu chiaro, e quindi con un livello di
Fig. 5.6: Situazione finale per la simulazione di una fuga di gas
CAPITOLO 5. ESEMPI 75
Fig. 5.7: Scheda del lavoratore “Mario Rossi”
rischio piu basso, e dovuta alla presenza di una porta (cioe di un access point),
che fornendo una via di uscita contribuisce ad abbassare il livello di rischio
nelle immediate vicinanze. La situazione finale che si presenta all’operatore
e mostrata in figura 5.6.
Leggendo i valori di pri presenti nella lista delle persone, si nota come il
lavoratore “Mario Rossi” abbia un valore piu alto rispetto al lavoratore “Giu-
seppe Verdi”. Questo comportamento del sistema e dovuto principalmente
alla vicinanza del primo lavoratore alla fonte di rischio e cioe al sensore del
gas. La conferma di quanto affermato si ha quando si consulta la scheda di
“Mario Rossi”, mostrata in figura 5.7, che evidenzia come il livello di rischio
sia elevato proprio per effetto della posizione del lavoratore in una zona ad
alto rischio.
5.2.1 Strategia
La simulazione della fuga di gas ci permette di verificare anche la fase di
planning del prototipo poiche il livello di gas nell’aria supera la soglia di at-
tenzione impostata nell’applicazione. Oltre questa soglia, viene riscontrata
una situazione di pericolo, per la quale diviene necessario attivare un’oppor-
tuna strategia. La figura 5.8 mostra la strategia che il prototipo mostra non
appena il livello di gas nocivo presente nell’aria sale oltre il limite previsto.
CAPITOLO 5. ESEMPI 76
Fig. 5.8: Finestra della strategia mostrata dal prototipo nella simulazionedi una fuga di gas
La finestra e suddivisa in due aree. La parte a sinistra elenca le perso-
ne coinvolte nella situazione di pericolo e il loro pri. Nell’area di destra e
possibile consultare l’elenco delle azioni da compiere, in ordine di priorita.
Capitolo 6
Conclusioni
Come illustrato nei capitoli precedenti, la capacita di poter prevenire even-
tuali situazioni di rischio o di riuscire a far fronte a situazioni di emergenza
nel minor tempo possibile e con le giusta strategia puo aiutare a ridurre il
numero di incidenti che si verificano durante le normali attivita lavorative.
Per raggiungere questi obiettivi e indispensabile affidarsi ad un modello
matematico in grado di calcolare il livello di rischio presente in aree di lavoro e
associato ad ogni lavoratore in modo da rilevare eventuali situazioni anomale
o di pericolo.
Purtroppo, la sola rilevazione del rischio non e sufficiente, anche se in-
dispensabile, per prevenire eventuali incidenti o per poter intervenire con le
giuste azioni in caso di situazioni di pericolo. Allo scopo, occorre adottare
dei pattern che siano in grado di riconoscere in anticipo le situazioni di ele-
vato rischio e fornire le giuste indicazioni per ridurre la probabilita che la
situazione evolva in un’emergenza.
Il prototipo che e stato sviluppato in questo lavoro di Tesi cerca di ri-
spondere a tutte queste esigenze basandosi sul modello matematico e sulla
definizione di rischio descritta nei capitoli precedenti.
Il risultato ottenuto dal lavoro di questa Tesi e un prototipo in grado
di monitorare un’ambiente di lavoro complesso riuscendo a calcolare sia il
77
CAPITOLO 6. CONCLUSIONI 78
livello di rischio individuale che quello legato alle aree operative, utilizzando
il modello matematico descritto nel capitolo 3.
L’applicativo e inoltre in grado di riconoscere le situazioni di pericolo e,
tramite l’analisi di determinate condizioni, e in grado di fornire la strategia
piu adeguata da adottare per far fronte all’emergenza.
Il prototipo puo gia essere utilizzato per l’analisi di situazioni di pericolo
in un ambiente di lavoro, in modo da poter studiare ed analizzare eventua-
li azioni correttive da intraprendere nell’area operativa, come ad esempio il
posizionamento di eventuali strumenti di protezione (estintori, kit di pron-
to soccorso, ecc.) o l’adozione da parte dei lavoratori di particolari sensori
indossabili e di dispositivi informativi. Il prototipo puo anche essere utilizza-
to per verificare se le procedure di emergenza previste, ove applicate in una
situazione di pericolo, portino effettivamente ad avere un’abbassamento del
livello di rischio (sia individuale che dell’intero ambiente). Il prototipo infine
puo essere usato anche per verificare, in opportune simulazioni, quali sono
i comportamenti dei lavoratori in particolari situazioni di pericolo, control-
lando l’aderenza dei loro comportamenti rispetto alle procedure di sicurezza
prevista o alla strategie proposte dal prototipo stesso.
6.1 Sviluppi Futuri
Il prototipo offre opportunita di sviluppo su alcuni fronti. Di seguito so-
no elencate le tematiche che potrebbero essere oggetto di ulteriore appro-
fondimento, allo scopo di rendere l’applicazione piu adatta ad un utilizzo
“real-time” in un ambiente di lavoro:
• fase di executing : il prototipo non implementa la fase di executing. Non
sono previste cioe “azioni” che l’applicativo puo compiere per attivare
eventuali allarmi o per inviare messaggi ai lavoratori. Per realizzare
questa funzionalita occorre analizzare e implementare lo strato software
che permetta all’applicativo di inviare “messaggi” verso l’esterno. Allo
CAPITOLO 6. CONCLUSIONI 79
scopo, e sufficiente ridefinire la classe Action sviluppando la tematica e
specializzandola in azioni che possono poi essere eseguite direttamente
dal prototipo (come ad esempio l’invio di sms);
• real-time: nonostante il meccanismo di “push” delle modifiche imple-
mentato nel prototipo sia molto reattivo, in una situazione realistica,
composta da centinaia di sensori disposti nell’ambiente e da decine di
lavoratori all’opera, questo meccanismo potrebbe avere tempi di rispo-
sta troppo elevati rispetto all’esigenza. Tempi non controllati in ottica
real-time possono compromettere la capacita di prevenzione del pro-
totipo. Diventa allora interessante valutare l’opportunita di gestire il
prototipo nell’ambito di un sistema real-time, prevedendo un modulo
che implementi uno scheduling real-time che sia in grado di gestire tutte
le computazioni previste (calcolo della mappa del rischio, analisi delle
situazioni di pericolo, ecc.) tramite code di priorita e che sia in grado di
gestire anche dei vincoli temporali [Brandolese and Fornaciari, 2007];
• multi-thread il prototipo e il modello matematico ben si presta ad essere
implementato tramite un’applicazione multi-thread che sia in grado cioe
di effettuare i calcoli del livello di rischio per tutte le entita previste dal
modello in thread separati. Questo calcolo “parallelo” permetterebbe
notevoli vantaggi sulla velocita di calcolo del prototito oltre che sul-
l’individuazione delle situazioni di pericolo. I requisiti di performance
computazionali, che non sono rilevanti nell’ambito della prototipazione
di questo lavoro di Tesi, potrebbero divenire determinanti nell’ambito
di un utilizzo in produzione.
Appendice A
Librerie utilizzate
A.1 Google Web Toolkit
Il Google Web Toolkit (gwt) e un toolkit opensource per lo sviluppo di
interazioni utente complesse in ambienti web based. L’obiettivo del progetto
e quello di permettere agli sviluppatori di realizzare applicazioni web ad alte
performance senza fare le spese della complessita di tecnologie che abilitano
l’interazione asincrona ajax come JavaScript.
Il framework mette a disposizione un compilatore che legge il codice scritto
in Java traducendolo in html e Javascript. Per fare cio, il toolkit fornisce
al compilatore una emulazione di un sottoinsieme di librerie del jre, percio
non tutti i metodi e la classi presenti nella JRE di Java possono essere usati
all’interno di progetti GWT.
Per la gestione delle interfacce grafiche il toolkit ha un approccio simile ad
altri framework come Swing e swt, con la differenza che i widget utilizzati
per la costruzione delle interfacce vengono poi costruiti dinamicamente in
html.
Un altro vantaggio che il toolkit offre e la capacita di mascherare alla
programmazione tutta la complessita dovuta alle tipiche incompatibilita tra
i vari browser di mercato.
80
APPENDICE A. LIBRERIE UTILIZZATE 81
Anche la gestione degli eventi risulta particolarmente semplificata gra-
zie all’utilizzo di “handler”, che definiscono uno o piu metodi che i widget
richiamano per segnalare un evento.
Infine gwt offre un potente e semplice metodo per la comunicazione con
il server. Infatti, e possibile effettuare delle chiamate asincrone verso il server
inviando e ricevendo i dati di cui si ha bisogno. Questo approccio permette
di non dover caricare completamente la nuova pagina html ad ogni modifica
e si possono cosı realizzare applicazioni ajax con la caratteristica di avere
un interfaccia molto piu reattiva e fluida, riducendo nel contempo il carico
di banda richiesto per la comunicazione con il server.
In figura A.1 e mostrato il diagramma delle classi che vengono utilizzate
per realizzare una Remote Procedure Call (rpc) con il framework GWT.
Fig. A.1: Architettura delle classi per la comunicazione con il server
Il progetto e tutta la documentazione si trova all’indirizzo web seguente:
http://code.google.com/intl/it-IT/webtoolkit/.
APPENDICE A. LIBRERIE UTILIZZATE 82
A.2 Smart gwt
Smart gwt e un framework opensource basato su gwt, che mette a dispo-
sizione una vasta libreria di widget per la creare applicazione con interfacce
grafiche ricche e di legare questi widget con il lato server per la gestione dei
dati.
Smart gwt e basato sulla potente e matura librearia Javascript Smart-
Client. Un esempio della potenza del framework e mostrato in figura A.2
dove e mostrata una tabella di dati.
Fig. A.2: Esempio di una lista di dati creata con la libreria SmartGWT
Il progetto e tutta la documentazione si trova a questo indirizzo web:
http://code.google.com/p/smartgwt/.
A.3 Apache Digester - Commons
La libreria Apache Digester fa parte del progetto Apache Commons Proper
che ha come obiettivo quello di creare e mantenere un insieme di librerie di
componenti Java riusabili.
In particolare la libreria Digester permette di creare un modulo che mappi
un file xml con una gerarchia di oggetti Java e che permette di eseguire
determinate azioni chiamate Rule, nel momento in cui un particolare pattern
APPENDICE A. LIBRERIE UTILIZZATE 83
viene riconosciuto all’interno del file xml. La libreria Apache Digester mette
a disposizione un ricco insieme di Rule predefinite ed e possibile crearne di
proprie. Le funzionalita avanzate della libreria permettono anche di:
• implementare e utilizzare un proprio motore di riconoscimento dei pat-
tern;
• incapsulare un insieme di Rule all’interno di un RuleSet che possono
essere facilmente riusate in piu applicazioni;
Il progetto e tutta la relativa documentazione si trova a questo indirizzo
web:
http://commons.apache.org/digester/.
Bibliografia
[Ardagna et al., 2009] Ardagna, D., Fugini, M., Pernici, B., and Plebani, P.
(2009). Sistemi Informativi basati su web, volume VI. FrancoAngeli.
[Brandolese and Fornaciari, 2007] Brandolese, C. and Fornaciari, W. (2007).
Sistemi Embedded. Pearson Prentice Hall.
[Cheng et al., 2009] Cheng, B. H., Lemos, R., Giese, H., Inverardi, P., Ma-
gee, J., Andersson, J., Becker, B., Bencomo, N., Brun, Y., Cukic, B.,
Marzo Serugendo, G., Dustdar, S., Finkelstein, A., Gacek, C., Geihs, K.,
Grassi, V., Karsai, G., Kienle, H. M., Kramer, J., Litoiu, M., Malek,
S., Mirandola, R., Muller, H. A., Park, S., Shaw, M., Tichy, M., Tivo-
li, M., Weyns, D., and Whittle, J. (2009). Software engineering for self-
adaptive systems. chapter Software Engineering for Self-Adaptive Systems:
A Research Roadmap, pages 1–26. Springer-Verlag, Berlin, Heidelberg.
[Cheng and Chu, 2008] Cheng, K. and Chu, C. (2008). A local likelihood me-
thod for estimating relative risk functions in case-control studies. Journal
of Statistical Planning and Inference, 138(12):3733 – 3748.
[Daft et al., 2007] Daft, R. L., Boldizzoni, D., and Nacamulli, R. C. (2007).
Organizzazione Aziendale (Idee e Strumenti). Apogeo.
[Foundation, 2011] Foundation, A. S. (2011). Apache commons – commons
digester. http://commons.apache.org/digester/.
[Franceschini et al., 2009] Franceschini, F., Galetto, M., Maisano, D., and
Mastrogiacomo, L. (2009). A review of localization algorithms for distri-
84
BIBLIOGRAFIA 85
buted wireless sensor networks in manufacturing. In International Journal
of Computer Integrated Manufacturing, pages 698–716. Taylor & Francis.
[Fugini et al., 2009a] Fugini, M., Conti, G. M., Rizzo, F., Raibulet, C., and
Ubezio, L. (2009a). Wearable services in risk management. In Proceedings
of the 2009 IEEE/WIC/ACM International Joint Conference on Web In-
telligence and Intelligent Agent Technology - Volume 03, WI-IAT ’09, pages
563–566, Washington, DC, USA. IEEE Computer Society.
[Fugini et al., 2011] Fugini, M., Israels, R., Raibulet, C., and Ramoni, F.
(2011). Simulation of risks for monitoring and prevention.
[Fugini et al., 2009b] Fugini, M. G., Maggiolini, P., Raibulet, C., and Ube-
zio, L. (2009b). Reflections on web-oriented architectures for risk mana-
gement. In Proceedings of the 2009 IEEE/WIC/ACM International Joint
Conference on Web Intelligence and Intelligent Agent Technology - Volume
03, WI-IAT ’09, pages 361–364, Washington, DC, USA. IEEE Computer
Society.
[Fugini et al., 2009c] Fugini, M. G., Maggiolini, P., Raibulet, C., and Ube-
zio, L. (2009c). Risk management through real-time wearable services. In
Proceedings of the 2009 Fourth International Conference on Software En-
gineering Advances, ICSEA ’09, pages 163–168, Washington, DC, USA.
IEEE Computer Society.
[Fugini et al., 2010] Fugini, M. G., Raibulet, C., and Ubezio, L. (2010). Risk
characterization and prototyping. In NOTERE’10, pages 57–64.
[Gamma et al., 2002] Gamma, E., Helm, R., Johnson, R., and Vlissides,
J. (2002). Design Pattern – Elementi per il riuso di software a oggetti.
Addison-Wesley.
[Google, 2011] Google (2011). Google web toolkit. http://code.google.
com/intl/it-IT/webtoolkit/.
[INAIL, 2010] INAIL (2010). Rapporto INAIL 2009. L’andamen-
to degli infortuni sul lavoro delle malattie professionali nel
BIBLIOGRAFIA 86
2009. http://www.lavoro.gov.it/Lavoro/SicurezzaLavoro/MS/
StudiRicerche/Rapporto_INAIL_2009.htm.
[Isomorphic Software, 2011] Isomorphic Software (2011). Smart gwt – gwt
api’s for smartclient. http://code.google.com/p/smartgwt/.
[Laguna et al., 2009] Laguna, M. A., Finat, J., and Gonzalez, J. A. (2009).
Mobile health monitoring and smart sensors: a product line approach.
In Proceedings of the 2009 Euro American Conference on Telematics and
Information Systems: New Opportunities to increase Digital Citizenship,
EATIS ’09, pages 8:1–8:8, New York, NY, USA. ACM.
[Li et al., 2004] Li, S., Lin, Y., Son, S. H., Stankovic, J. A., and Wei,
Y. (2004). Event detection services using data service middleware in
distributed sensor networks. Telecommunication Systems, 26:351–368.
10.1023/B:TELS.0000029046.79337.8f.
[Lundgren and McMakin, 2009] Lundgren, R., E. and McMakin, A. (2009).
Risk Communication. A Handbook for Communicating Environmental,
Safety, and Health Risks. Wiley Publ.
[Oracle, 2011] Oracle (2011). Java ee. http://www.oracle.com/
technetwork/java/javaee/overview/index.html.
[Vita and Salodini, 2009] Vita, A. and Salodini, I. (2008/2009). Un ambiente
di simulazione di gestione dei rischi in aree di lavoro. Tesi di laurea,
Politecnico di Milano. Relatore Mariagrazia Fugini.
[Wikipedia, 2011a] Wikipedia (2011a). Ajax — wikipedia, l’enciclopedia
libera. [Online; in data 10-marzo-2011].
[Wikipedia, 2011b] Wikipedia (2011b). Dispositivi di protezione individuale
— wikipedia, l’enciclopedia libera. http://it.wikipedia.org/w/
index.php?title=Dispositivi_di_protezione_individuale&oldid=
38230914.
BIBLIOGRAFIA 87
[Wikipedia, 2011c] Wikipedia (2011c). Push technology — wikipedia, the
free encyclopedia.
[Wikipedia, 2011d] Wikipedia (2011d). Sicurezza sul lavoro — wikipedia,
l’enciclopedia libera. http://it.wikipedia.org/w/index.php?title=
Sicurezza_sul_lavoro&oldid=38944967.