Il manuale olandese “Handboek Incident Management” costituisce uno degli esempi più significativi di descrizione del processo di gestione degli eventi incidentali. Questo manuale definisce i vari tipi di eventi ed esplicita gli enti coinvolti, le relative responsabilità specifiche e le “fasi del processo” durante un evento incidentale.

Problema dell’interoperabilità

Tra i vari enti, a causa della loro diversità, esistono numerose incompatibilità. Ne sono un esempio i processi aziendali e la terminologia utilizzata, che rendono complessa la “comunicazione” con altri enti, non solo “da persona a persona”, ma anche tra i sistemi informativi disponibili.

La maggior parte degli enti coinvolti sono dotati di sistemi di supporto all’informazione. Questi sistemi informativi sono stati sviluppati per le mansioni più complesse e possono, o sono, in parte utilizzati per la gestione degli eventi incidentali. Per motivi legali, organizzativi o tecnici, la maggior parte dei sistemi informativi dei partner della catena IM non sono interconnessi.

Lo scambio di informazioni tra questi sistemi informativi è strutturato principalmente sotto forma di “mansione eseguita dal personale” per mezzo vocale (telefono) o talvolta via fax.

Questo tipo di approccio richiede tempo e comporta la perdita (della qualità) delle informazioni. Questo aspetto in particolare può essere migliorato sostanzialmente, ma a tal fine devono essere compiuti notevoli sforzi per gestire i vincoli dei sistemi interconnessi sopra indicati.

Per poter essere in grado di cooperare e di comunicare in modo efficiente, le organizzazioni devono essere “interoperabili”. In questo settore in particolar modo, la Commissone Europea ha identificato numerose attività (di ricerca) per migliorare la comunicazone tra le amministrazioni, le aziente e i cittadini. Il programma IDABC fornisce le linee guida per raggiungere l'”interoperabilità”, definendone i 3 seguenti aspetti :

1. Interoperabilità tecnica, riguardante gli aspetti tecnici di collegamento dei PC, definizione di interfacce aperte, formati e protocolli dei dati, incluse le telecomunicazioni;

2. Interoperabilità semantica, avente lo scopo di garantire che il significato preciso delle informazioni scambiate sia comprensibile a qualsiasi altra applicazione non inizialmente sviluppata per questo fine; e

3. Interoperabilità organizzativa, riguardante la configurazione dei processi aziendali, l’allineamento dell’architettura delle informazioni con gli obiettivi organizzativi e la cooperazione tra i processi aziendali.

Oltre a questi aspetti dell’interoperabilità, IDABC fornisce le linee guida architettoniche e analizza vari aspetti tecnologici quali la sicurezza, la protezione dei dati, ecc.

Service Oriented Architecture (SOA)

Una delle interessanti conclusioni dell’attività IDABC è il riconoscimento degli sforzi in atto per passare dalle soluzioni IT “chiuse” tradizionali a “soluzioni interoperabili più aperte” basate sulla cosiddetta architettura SOA “Service Oriented Architecture”.

L’idea alla base di una SOA è che i processi informativi e aziendali sono forniti o “condivisi” in modo generico utilizzando standard aperti. I componenti di base sono costituiti da un “vocabolario” comune che utilizza il linguaggio (XML) per la relativa rappresentazione e servizi web ben definiti (e facilmente accessibili) attraverso un’infrastruttura di telecomunicazioni comune.

Nell’ambito della gestione degli eventi incidentali, ciò potrebbe significare che un qualsiasi ente non avrebbe più bisogno di creare accessi diretti ai propri sistemi IT, ma che potrebbe “condividere” specifiche informazioni con un sistema intermedio che ne consente l’utilizzo da parte di altri enti.

L’architettura SOA agevola la creazione di un’infrastruttura comune che fondamentalmente corrisponde all'”Interoperabilità tecnica” che abbiamo precedentemente accennato. Un altro aspetto che caratterizza le SOA è la necessità di un “vocabolario” comune che fornisca soluzioni per l'”l’interoperabiltà semantica”; il “significato” e la definizione esatti degli elementi informativi.

Per la gestione degli eventi incidentali, questo vocabolario è fondamentale. Gli enti coinvolti utilizzano fondamentalmente gli stessi elementi informativi, ma talvolta con una sintassi o un significato diverso. Un esempio di elemento informativo importante è la definizione della posizione di un evento incidentale. La descrizione e la definizione utilizzate non sono state oggetto di accordo tra gli enti, generando a volte confusione.

La definizione di un vocabolario può richiedere tempo, ma fortunatamente il settore dei Trasporti dispone già di una base solida per questo vocabolario. Il dizionario dei dati DATEX definisce gli elementi informativi più comuni, nonché il relativo significato e utilizzo. Tuttavia le specifiche DATEX non solo forniscono la definizione degli elementi informativi ma descrivono anche la piattaforma di scambio, che fondamentalmente è l’implementazione di una SOA.

Strumento di supporto alla presa decisionale

L’aspetto più importante dell’interoperabilità è l'”Interoperabilità organizzativa”, che riguarda fondamentalmente l’armonizzazione dei vari processi aziendali e modelli informativi esistenti.

Il modello aziendale descritto ad esempio nel “Manuale sulla gestione degli eventi incidentali” fornisce una chiara visione dell’utente, delle responsabilità, delle azioni e dei flussi d’informazioni e può essere facilmente passato agli analisti di sistema per la definizione di un sistema d supporto IT.

Fondamentalmente è in questa area “organizzativa” che uno strumento (automatico) di supporto alla presa decisionale può agevolare l’automatizzazione delle “politiche aziendali”. Questo sistema di supporto alle decisioni è basato sulla rappresentazione della conoscenza in modo conciso, chiaro e dichiarativo. Il “cervello” di questo sistema è un dispositivo di deduzione scalabile a un vasto numero di regole e fatti. Questo dispositivo associa fatti, vale a dire i dati, e regole, per dedurre conclusioni che comportano determinate azioni. Una Regola è una struttura bi-componente che utilizza un ordine logico prestabilito per la rappresentazione della conoscenza. Ciascuna regola ha una struttura semplice:

Tuttavia nel nostro caso, per la gestione degli eventi incidentali, il sistema di supporto alla presa decisionale deve gestire fatti provenienti da vari enti; inoltre il “proprietario” del sistema non è unico, e le azioni risultanti non sono intese per un solo ente.Nella maggior parte dei casi questo tipo di funzionalità di supporto è “nascosta” nei “meandri” di un sistema IT e quindi non esposta al mondo esterno.

Lo strumento di supporto alla presa decisionale, affinché sia utile, deve essere adattato al fine di operare come “servizio on-line”, con requisiti specifici per i “fatti” in entrata o le azioni in uscita.

Questa è la fase in cui entra in gioco il vocabolario comune. In assenza di dati concisi e privi di ambiguità, lo strumento di supporto alla presa decisionale non può trarre conclusioni. Oltre alle definizioni standard degli “eventi incidentali”, utilizziamo anche definizioni standardizzate per la localizzazione, i dati sul traffico, ecc.

Il sistema di supporto alla presa decisionale funziona come un’unità indipendente in grado di ricevere “fatti”, di elaborarli utilizzando una serie predefinita d “regole” e di inviare “azioni” agli altri sistemi connessi. Il termine azione non è corretto in questo specifico contesto, fondamentalmente il sistema compone uno scenario, contenente le misure sul traffico costituite da azioni separate.

L’attuale versione è in grado di elaborare un’informazione di base stabilita da un operatore, di validarne i contenuti e di attivare l’invio di messaggi differenti ai servizi coinvolti, quali la polizia, i vigili del fuoco e l’ambulanza. Inoltre supporta la generazione automatica di messaggi per i pannelli a messaggio variabile.

Le versioni future saranno anche in grado di fornire supporto durante il processo di gestione degli eventi incidentali. Sarà possibile operare modifiche nella posizione e/o nei tipi di eventi incidentali e prendere qualsiasi tipo di misura aggiuntiva.

Uno degli elementi di miglioramento maggiormente promettente è la definizione del cosiddetto “linguaggio settoriale specifico”. Attualmente la definizione delle regole non è complessa ma richiede la competenza di un programmatore di base per poter essere inserite nel sistema.

Tuttavia crediamo che l’operatore debba essere in grado di creare e modificare le regole. La comprensione di un linguaggio settoriale specifico è più semplice in quanto fondamentalmente si tratta di un “linguaggio naturale”.

Un’ulteriore miglioria riguarda l’utilizzo di un’interfaccia utente a basso costo che può essere utilizzata da tutti gli organismi coinvolti per visualizzare lo stato degli eventi incidentali in corso.

Scarica articolo intero >>