un approccio alla gestione del rischio in aree di lavoro · 2013-03-05 · parte delle quali (767...

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.


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.


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)


[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.


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


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-


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


Fig. 2.1: Architettura del Sistema di Gestione del Rischio[Fugini et al., 2011]


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


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-


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


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


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.


Fig. 2.2: Modello delle Entita per il Sistema di Gestione del Rischio


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


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


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.


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:


– 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


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;


• 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


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


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


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


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);


• 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;


• 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


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


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:


• 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.


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.


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.


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


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


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”


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-


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;


• 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;


Fig. 4.2: Diagramma delle classi del modello del modello delle entita


• 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.


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.


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;


Fig. 4.3: Diagramma delle classi necessarie alla realizzazione della fase dimonitoring


• 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.


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.


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


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


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


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


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


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-


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.


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.


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.


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-


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


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-


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-


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


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-


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


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


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.


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.


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


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.


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/.


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


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

http://commons.apache.org/digester/

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

http://code.google.com/intl/it-IT/webtoolkit/

http://code.google.com/intl/it-IT/webtoolkit/

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.

http://www.lavoro.gov.it/Lavoro/SicurezzaLavoro/MS/StudiRicerche/Rapporto_INAIL_2009.htm

http://www.lavoro.gov.it/Lavoro/SicurezzaLavoro/MS/StudiRicerche/Rapporto_INAIL_2009.htm

http://code.google.com/p/smartgwt/

http://www.oracle.com/technetwork/java/javaee/overview/index.html

http://www.oracle.com/technetwork/java/javaee/overview/index.html

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.

http://it.wikipedia.org/w/index.php?title=Sicurezza_sul_lavoro&oldid=38944967

http://it.wikipedia.org/w/index.php?title=Sicurezza_sul_lavoro&oldid=38944967

un approccio alla gestione del rischio in aree di lavoro · 2013-03-05 · parte delle quali (767...

Documents