Sistema Informativo Mobilità
La Regione Toscana – Direzione Generale Politiche Territoriali e Ambientali, all’interno della strategia “i-mobility – Infrastruttura Geografica per l’Accessibilità Territoriale On Demand” ha individuato alcuni progetti esecutivi che concorrono alla realizzazione e alla gestione della stessa.
Tra questi il progetto “Mobility Information Integration Center” (MIIC d’ora in avanti) che ha il compito di realizzare una sala operativa dedicata:
a) alla raccolta in tempo reale delle informazioni relative alle flotte TPL, alle emergenze sulla rete viaria, alle condizioni del traffico sulla rete viaria (Sensori Traffico), alla disponibilità di posti auto nei parcheggi, e al tracking di flotte di pubblico interesse (es. mezzi di trasporto rifiuti o merci pericolose) provenienti da enti federati al MIIC come produttori di informazioni.
b) alla diffusione delle informazioni raccolte verso gli enti federati al MIIC come fruitori di informazioni.
Il progetto MIIC ha anche il compito di definire le specifiche tecniche ed organizzative delle interfacce di integrazione per la raccolta e redistribuzione delle informazioni relative all’infomobilità sul territorio regionale.
Gli attori potenzialmente coinvolti nei flussi di informazioni da e verso il MIIC sono, di fatto, tutte le tipologie di fornitori/fruitori previsti in i-mobility.
In particolare gli attori federati al MIIC come produttori di informazioni potranno essere:
- i gestori di sale di controllo (Autostrade, Aeroporti, Autorità portuali, ecc.),
- i gestori di flotte di trasporto (Aziende di TPL, Trenitalia, ecc.),
- i gestori di flotte di servizio (Vigili urbani, ecc.),
- sale operative di altri Enti/Aziende,
- le province e i comuni della Regione Toscana,
- i gestori di parcheggi,
- gli enti preposti alla gestione e segnalazione delle emergenze,
- gli enti che effettuano monitoraggio sulle condizioni atmosferiche.
Le interfacce di integrazione disponibili per gli enti federati come produttori di informazioni sono molteplici.
I servizi applicativi descritti rappresentano il canale di comunicazione esposto dal MIIC (Mobility Information Integration Center) per la gestione in ingresso ed in uscita dei dati relativi al TPL (Trasporto Pubblico Locale).
MIIC – DATEX2 Supplier Push Service
Il servizio applicativo “MIIC – DATEX II Supplier Push Service” è uno dei canali principali di comunicazione che hanno a disposizione gli enti federati al MIIC (Mobility Information Integration Center) per inviare dati relativi alla infomobilità alla sua sala operativa.
L’obiettivo generale del servizio “MIIC – DATEX II Supplier Push Service” è quello di fornire una interfaccia comune e standardizzata secondo il formato internazionale DATEX II per l’invio dei dati in modalità “Push” dagli enti federati al MIIC come produttori di informazioni alla sala operativa MIIC.
L’obiettivo specifico della versione attuale del servizio “MIIC – DATEX II Supplier Push Service” è quello di gestire l’invio dei dati in modalità “Push” limitatamente alle informazioni provenienti da:
- sistemi di rilevamento traffico a sensori
- sistemi di rilevamento in tempo reale dello stato di saturazione dei parcheggi
- emergenze viarie
- sistemi di rilevamento condizioni metereologiche
i file “Template_censimento_Parcheggi.xls” e “Template_censimento_Siti_e_Sensori.xls” sono disponibili nella scheda di dettaglio relativa a questo servizio.
MIIC – DATEX II Client Pull Service
L’obiettivo generale del servizio “MIIC – DATEX II Client Pull Service” è quello di fornire una interfaccia comune e standardizzata secondo il formato internazionale DATEX II per la esposizione di dati in modalità “Pull Exchange” dalla sala operativa MIIC agli enti federati.
Il servizio “MIIC – DATEX II Client Pull Service” espone i dati riferiti alle seguenti tipologie di informazioni:
- Sensori Traffico: dati relativi alla situazione della viabilità stradale provenienti da gestori disistemi di rilevamento a sensori.
- Parcheggi: dati relativi allo stato di occupazione dei parcheggi provenienti da gestori di areee parcheggio.
- Emergenze viarie: dati relativi a emergenze viarie e/o lavori stradali provenienti da gestori di tratte stradali (Autostrade per l’Italia s.p.a., ANAS, comuni e province, ecc.)
- Informazioni meteo: dati relativi alle informazioni metereologiche provenienti da gestori di centraline metereologiche (Consorzio LaMMA etc)
In previsione di una necessaria filtratura dei dati esposti, il criterio di estrazione dei dati del servizio “MIIC – DATEX II Client Pull Service” è basato sui concetti di Catalogo, di Utenza e di Sottoscrizione.
Un Catalogo è una contenitore logico che raggruppa uno o più entità oggetto di estrazione dei dati secondo un dato criterio di classificazione. Per esempio un Catalogo di Parcheggi può raggruppare varie entità Parcheggio secondo il criterio della identità geografica (stesso Comune), di vicinanza (stesso area geografica), di importanza (i principali parcheggi cittadini, o quelli con il maggior numero di posti), ecc.
Una Utenza è un identificativo univoco (Userid e Password) in possesso di un solo Ente fruitore al quale è associato un determinato Catalogo attraverso una procedura di Sottocrizione.
La procedura di Sottoscrizione viene condotta off-line in collaborazione con l’amministrazione del sistema MIIC. Al termine della procedura, l’ente fruitore entra in possesso di una Utenza sottoscritta ad un particolare Catalogo.
Le relazioni tra le entità coinvolte sono le seguenti:
Utenza / Catalogo relazione 1 – 1
Ogni Utenza potrà avere solo un Catalogo associato.
Ente/Utenza relazione 1 – 1..*
Un Ente potrà avere a sua disposizione una o più Utenze: ciò equivale a dire che potrà sottoscriversi a più Cataloghi.
Catalogo / Utenze relazione 1 – 0 …*Un Catalogo potrà essere pubblicato per un numero indefinito di utenze.
Nel servizio “MIIC – DATEX II Client Pull Service” sono i web service sono suddivisi in due categorie a seconda del criterio di estrazione utilizzato:
- estrazione non filtrata. Denominata d’ora in avanti “Catalogo Standard”.
- estrazione filtrata. Denominata d’ora in avanti “Catalogo in Publish/Subscribe”.
La versione Catalogo Standard può essere consumata da una Utenza generica poiché il servizio non effettua controlli di autenticazione e riconoscimento. Il set di dati esposti corrisponde ad un Catalogo Standard. Nella versione Catalogo in Publish/Subcribe il servizio effettua controlli di autenticazione e riconoscimento della Utenza che deve essere una utenza valida e sottoscritta ad un Catalogo esistente tramite procedura di Sottoscrizione. Il set di dati esposti corrisponde ad al Catalogo per il quale è sottoscritta l’Utenza.
Elenco dei web services
I web services che fanno parte del “MIIC – DATEX II Client Pull Service” sono quindi otto:
- Parcheggi a Catalogo Standard
- Parcheggi a Catalogo in Publish/Subscribe
- Sensori a Catalogo Standard
- Sensori a Catalogo in Publish/Subscribe
- Emergenze Viarie a Catalogo Standard
- Emergenze Viarie in Publish/Subscribe
- Informazioni meteo a Catalogo Standard
- Informazioni meteo Viarie in Publish/Subscribe
Prima di poter dare vita ad una interazione DATEX II è necessario che gli enti federati al MIIC e la sala operativa MIIC stessa, condividano alcuni dati per referenziare univocamente le entità oggetto di informative via DATEX II.
Nello specifico è necessaria una fase preliminare in cui la sala operativa MIIC fornisce agli enti federati interessati le anagrafiche di censimento e gli identificativi univoci delle entità (parcheggi e/o sensori traffico) gestite. L’uso successivo dei dati di censimento delle entità e la gestione della loro persistenza sui sistemi destinatari è a carico degli enti federati.
Per far fronte a queste operazioni preliminari è ovvio che siano necessarie delle comunicazioni personali ma, per renderle più agevoli e standardizzate, sono stati messi a punto due modelli per il censimento dei Parcheggi e per il censimento dei Sensori, siano essi i sensori del traffico o i sensori delle condizioni meterologiche, con le opportune spiegazioni. I file di censimento delle entità basati su questi template saranno forniti da MIIC agli enti federati.Nota: i file “Template_censimento_Parcheggi.xls” e “Template_censimento_Siti_e_Sensori.xls” sono disponibili nella scheda di dettaglio del servizio.
MIIC – AVM Real-time Services
I servizi applicativi “MIIC – AVM Real-time Services” rappresentano il canale di comunicazione esposto dal MIIC (Mobility Information Integration Center) per la gestione in ingresso e in uscita dei dati real-time relativi ai mezzi TPL (Trasporto Pubblico Locale) dotati di dispositivi AVM (Automatic Vehicle Monitoring).
L’obiettivo generale dei servizi “MIIC – AVM Real-time Services” è quello di fornire una interfaccia comune per lo scambio dei dati TPL-AVM tra enti federati e MIIC.
In questa ottica, in “MIIC – AVM Real-time Services” vengono definite specifiche regole di interoperabilità (Protocollo) e uno specifico formato dei messaggi (Modello Dati).
L’entità di riferimento di “MIIC – AVM Real-time Services” è dunque la corsa intesa come servizio TPL unitario realizzato da un mezzo attivo dotato di dispositivo AVM a bordo.
I servizi descritti sono due:
- Il servizio AVM Supplier Push dedicato ai dati AVM in ingresso al MIIC.
Il servizio AVM Supplier Push è implementato dal web service denominato avmsupplierPushService che espone un solo web method denominato putAvmMessage.
- Il servizio AVM Client Pull dedicato ai dati AVM in uscita dal MIIC.
Il servizio AVM Client Pull è implementato dal web service denominato avmclientPullService che espone un solo web method denominato getAvmMessage.
DB Corse
Prima di poter dare vita ad una interazione MIIC – AVM Real-time è necessario che gli enti produttori e/o fornitori di dati e il sistema MIIC stesso, condividano i dati per il reperimento delle entità oggetto delle informazioni.
Nello specifico, trattandosi di servizi TPL programmati, è necessario che i cosiddetti DB Corse generati e pubblicati periodicamente dalle Aziende TPL, vengano recepiti dal sistema MIIC attraverso gli opportuni meccanismi di aggiornamento e modifica. Questo stesso requisito riguarda anche gli eventuali fruitori di dati AVM real-time che, per poter interpretare correttamente i dati ricevuti, dovranno acquisire preventivamente i dati dei DB Corse di proprio interesse.I meccanismi di condivisione dei DB Corse non sono oggetto delle specifiche MIIC – AVM Real-time, ma dovranno essere analizzati e programmati su specifici tavoli tecnici congiunti.
Ordinanze Viabilità
La Regione Toscana utilizza uno strumento per la raccolta e comunicazione delle ordinanze temporanee sulla viabilità da parte degli enti responsabili, al fine di sviluppare un servizio capace di dare informazioni sullo stato del grafo di viabilità regionale.
Il servizio beneficia della partecipazione di enti gestori dell’infrastruttura viaria, i quali, attraverso lo strumento, pubblicano le ordinanze temporanee di viabilità. In questo modo il servizio permette ai proprietari, ai gestori, ai controllori e agli utilizzatori delle strade, di prendere conoscenza di tutte le ordinanze temporanee che modificano lo stato del grafo viario regionale.
Scopo dello strumento qui presentato è, quindi, fornire un’interfaccia attraverso la quale un ente abilitato possa rendere pubblica un’ordinanza temporanea, rendendola disponibile tramite il servizio, e fornire un’interfaccia attraverso la quale chi è interessato possa fruire del documento che rappresenta tale ordinanza.
Possono essere attori del servizio di Pubblicazione delle ordinanze temporali:
- Vigili Urbani,
- Provincia,
- Regione,
- Protezione Civile,
- Forze dell’Ordine,
- Prefetture,
- Motorizzazione,
- Aziende di Autotrasporto,
- Dipartimento di Assetto del Territorio,
- mezzi di comunicazione (RAI, radio, etc.),
- uffici dei Sindaci/Presidenti degli Enti coinvolti,
- uffici Viabilità degli Enti coinvolti,
- le ditte che effettueranno i lavori.
- Analisi
Il servizio “Ordinanze_Viabilità” è implementato dal web service denominato OrdinanzeViabilita. Il servizio espone due interfacce: publishOrdinanza e getOrdinanze.
PublishOrdinanza
publishOrdinanza è il web method che permette la pubblicazione di un’ordinanza tramite il servizio. Il metodo riceve in input un’ordinanza e ritorna un messaggio che indica l’esito di tale interazione.
La sua interfaccia è la seguente:
publishOrdinanza (MessagePubOrdinanza ord), return Message msg
Dove:
ord = parametro di Input di tipo MessagePubOrdinanza. Il tipo MessagePubOrdinanza implementa la pubblicazione dell’ordinanza da parte dell’attore pubblicante. Il parametro incapsula le seguenti entità: il codice ISTAT dell’attore pubblicante, un’entità di tipo Ordinanza (tale entità implementa l’ordinanza che si vuole pubblicare, nel pieno rispetto delle specifiche tecniche “specifiche_tecniche_per_la_trasmissione_delle_ordinanze_v1.2” [1]), la data di emissione dell’ordinanza, una copia digitale del documento cartaceo che costituisce l’ordinanza, il nome e le relative dimensioni espresse in byte per ognuno dei due file inviati;
msg = parametro di ritorno di tipo Message del web method. Il tipo Message implementa l’esito dell’iterazione avvenuta tra l’attore pubblicante l’ordinanza e il servizio. Gli esiti previsti sono due: ordinanza pubblicata con successo, oppure, insuccesso, comprensivo di breve didascalia dell’evento sopravvenuto.
GetOrdinanze
getOrdinanze è il web method che offre il servizio di fruizione delle ordinanze. Il metodo riceve come input i seguenti parametri: codice ISTAT dell’ente pubblicante, data inizio periodo, data fine periodo. Il metodo ritorna tutte le ordinanze pubblicate dall’ente specificato tramite il codice ISTAT e comprese nel periodo indicato.
L’interfaccia del web method:
getOrdinanze(MessageReqOrdinanze got), return MessageOrdinanze msg
dove:
got = parametro di input di tipo MessageReqOrdinanze. Il tipo MessageReqOrdinanze incapsula le informazioni necessarie per richiedere al servizio una o più ordinanze;msg = parametro di ritorno. In questo caso l’oggetto di tipo MessageOrdinanze, incapsula tutte le ordinanze che soddisfano i requisiti espressi tramite i parametri di input. In alternativa, nel caso di un evento inatteso sopravvenuto (errore), l’oggetto msg comunica l’insuccesso del servizio all’utente.
Mobilità Inter-operabile di Regione Toscana
Il progetto MIRTO, Mobilità Inter-operabile di Regione Toscana, è finalizzato alla realizzazione di un sistema per la gestione dei contrassegni per i disabili e degli stalli di sosta emessi dai comuni della Regione Toscana.
L’obiettivo del progetto MIRTO è facilitare la circolazione dei disabili nei Comuni della Regione Toscana attraverso l’interoperabilità dei singoli sistemi di riconoscimento dei contrassegni dei vari enti comunali.
L’interoperabilità è garantita da una banca dati centralizzata con i dati del rilascio dei contrassegni, alimentata dai Comuni, da condividere con tutti i sistemi dei diversi Comuni, consultabile da tutti i Vigili.
I servizi Mirto, quindi, sono finalizzati alla consultazione ed all’archiviazione dei contrassegni e degli stalli in ambiente regionale in modo da garantire l’allineamento costante tra gli applicativi comunali e la banca dati centralizzata.
Gli attori coinvolti sono:
– Regione Toscana – UNCEM, ANCI e i Comuni di Regione Toscana
Nel dettaglio, i servizi esporti:
- RicercaContrassegno
Fornisce i metodi per la ricerca in ambiente regionale dei dati di contrassegno e degli stalli associati.
- GestisciContrassegno
Fornisce i metodi per l’archiviazione e la movimentazione in ambiente regionale dei contrassegni e degli stalli associati.
Gli attori che prendono parte al processo sono i seguenti :
- Enti Comunali: rappresentano i fruitori dei servizi esposti dalla RFC, attraverso i quali comunicano a Regione Toscana le movimentazioni relative ai contrassegni ed agli stalli di sosta e richiedono al sistema regionale le informazioni aggiornate relative agli stessi.
- Regione Toscana: rappresenta l’ente erogatore del servizio.
Servizio RicercaContrassegni
- Operation RicercaCSPerIdentificativo
Permette di ottenere i dati di un contrassegno a partire dall’identificativo del contrassegno.
- Operation StoricoCSPerCFPossessore
Permette di ottenere lo storico dei contrassegni associato ad un soggetto a partire dal codice fiscale.
- Operation RicercaStalliPerIdentificativoCS
Permette di ottenere la lista degli stalli di sosta associati ad un contrassegno valido a partire dall’identificativo del contrassegno.
Servizio GestisciContrassegno
- Operation NuovoContrassegno
Permette di censire in ambiente regionale i dati relativi ad un nuovo contrassegno
- Operation ModificaContrassegno
Permette di modificare i dati relativi ad un contrassegno esistente
- Operation DuplicaContrassegno
Permette di censire in ambiente regionale un duplicato di un contrassegno scaduto o non più valido.
- Operation CessaContrassegno
Permette di esplicitare la cessazione di un contrassegno esistente.
- Operation InserisciStallo
Permette di censire uno stallo di sosta relativo ad un contrassegno esistente
- Operation ModificaStalli
Permette di notificare le modifiche agli stalli di sosta associato ad un contrassegno valido.