FORNITURA DI UN SISTEMA DI SUPERVISIONE DEL … Capitolato... · su questa base identificare e...

Pagina 1

PROGRAMMA ELISA PROGETTI S.I.MO.NE E WI-MOVE

FORNITURA DI UN SISTEMA DI SUPERVISIONE DEL TRAFFICO

E DI UNA PIATTAFORMA DI INFOMOBILITA’

CAPITOLATO SPECIALE D’APPALTO

Allegato 6 – “Specifiche Tecniche”

29 ottobre 2009

Pagina 2

Sommario

1 Premesse e quadro di riferimento...........................................................................................4 2 Descrizione generale della fornitura e delle sue finalità e caratteristiche ........................6 3 Ambito applicativo in cui si inserisce il Supervisore di traffico della Provincia e del Comune di Firenze............................................................................................................................8 3.1 Lista dei sistemi da interfacciare.....................................................................................8 3.2 Descrizione sintetica dei singoli sistemi ......................................................................10 3.2.1 Sistema di raccolta dati di traffico infrarossi/ultrasuoni – Comune di Firenze 10 3.2.2 Sistema di centralizzazione semaforica – Comune di Firenze ...........................13 3.2.3 Sistema di gestione di pannelli a messaggio variabile - Comune di Firenze ...16 3.2.4 Sistema di monitoraggio dei parametri ambientali – Provincia di Firenze......19 3.2.5 Sistema di gestione dei parcheggi in struttura – Comune di Firenze ...............22 3.2.6 Sistema di gestione delle ordinanze – Provincia di Firenze ...............................25 3.2.7 Sistema di gestione delle ordinanze – Comune di Firenze .................................27 3.2.8 Sistema di gestione della ZTL – Comune di Firenze ...........................................29 3.2.9 Sistema SICURTRAF di monitoraggio delle stradi provinciali - Provincia di Firenze 32 3.2.10 Sistema di monitoraggio del traffico sulla S.G.C. FI-PI-LI – Provincia di Firenze 37 3.2.11 Sistema di monitoraggio della flotta del trasporto pubblico (AVM) – ATAF..42 3.2.12 Sistema di videosorveglianza del traffico – Comune di Firenze.......................45 3.2.13 Sistema di monitoraggio della tramvia – Comune di Firenze...........................47 3.2.14 Sistema di centralizzazione semaforica degli impianti insistenti sul percorso della tramvia – Comune di Firenze ......................................................................................50 3.2.15 Modulo aggregatore di dati FCD...........................................................................53

4 Il grafo e la rappresentazione cartografica della rete........................................................54 5 Funzionalità del Supervisore.................................................................................................56 1. Configuratore.......................................................................................................................56 5.1 Acquisizione di dati da vari sistemi di gestione o regolazione del traffico e della mobilità. ........................................................................................................................................57 5.2 Acquisizione dati da flotte FCD....................................................................................59 5.3 Modulo di data entry dati di traffico............................................................................60 5.4 Filtraggio dati e normalizzazione .................................................................................61 5.5 Memorizzazione e archiviazione dei dati e relativa gestione...................................61 5.6 Ricostruzione dello stato del traffico ed identificazione di situazioni di criticità .63 5.7 Analisi statistica, elaborazione dei dati e reporting...................................................63 5.8 Rappresentazione grafica e interfaccia utente (MMI)................................................64 5.9 Costruzione e gestione dinamica di scenari di traffico..............................................66 5.10 Gestione di eventi............................................................................................................66 5.11 Invio comandi verso sistemi periferici.........................................................................67 5.12 Funzioni avanzate di on-line management .................................................................67 5.13 Interfaccia verso i sistemi di infomobilità ...................................................................68

Pagina 3

5.14 Interfaccia verso strumenti di pianificazione del traffico..........................................68 5.15 Centralizzazione dello stato dei sistemi collegati ......................................................68 5.16 Gestione allarmi ..............................................................................................................69 5.17 Amministrazione di sistema e reportistica di sistema...............................................69

6 Specifica funzionale della piattaforma di infomobilità .....................................................70 6.1 Caratteristiche della rete wireless della linea 1...........................................................70 6.2 Funzionalità di autenticazione e autorizzazione degli utenti ..................................72 6.3 Funzionalità di localizzazione degli utenti .................................................................73 6.4 Modalità di erogazione dei servizi ...............................................................................73 6.5 Canali di erogazione dei servizi....................................................................................74 6.6 Accesso ai servizi.............................................................................................................76 6.7 Profilazione e autenticazione ........................................................................................77 6.8 Catalogo dei servizi richiesti .........................................................................................79 6.8.1 Caratteristiche comuni a tutti i servizi...................................................................79 6.8.2 Descrizione dei servizi..............................................................................................80

6.9 Gestione del sistema .......................................................................................................87 6.10 Interfacce del sistema......................................................................................................87 6.11 Interfaccia web.................................................................................................................89

7 Architettura di sistema...........................................................................................................89 7.1 Architettura logica di sistema .......................................................................................89 7.2 Architettura hardware....................................................................................................90 7.3 Software di base e strumenti software di sviluppo e funzionamento.....................92 7.4 Rete di comunicazione ...................................................................................................93

8 Sviluppi futuri .........................................................................................................................93 9 Livelli di sicurezza e politiche di accesso al sistema.........................................................94 10 Affidabilità ...........................................................................................................................94 11 Specifiche prestazionali del sistema .................................................................................95 12 Configurazione iniziale di sistema ...................................................................................95 13 Verifica, avvio e collaudo del sistema..............................................................................96 14 Formazione e supporto ......................................................................................................96 15 Manutenzione in garanzia .................................................................................................97 15.1 Manutenzione ordinaria preventiva ............................................................................98 15.2 Manutenzione ordinaria correttiva ..............................................................................99 15.3 Manutenzione e assistenza fuori garanzia ..................................................................99

16 Documentazione di sistema.............................................................................................100 17 Consistenza della fornitura, limiti e modalità di fornitura.........................................100 18 Norme applicabili .............................................................................................................102 19 Tempistica e vincoli realizzativi......................................................................................102 20 Calendario dei pagamenti................................................................................................104 21 Penali – fattispecie e quantificazione .............................................................................104

Pagina 4

1 Premesse e quadro di riferimento Il presente capitolato fa riferimento all’acquisizione da parte della Provincia di Firenze (o più brevemente “Provincia”) di un sistema di supervisione del traffico stradale integrato con una piattaforma di infomobilità. Tale acquisizione si colloca nel contesto definito da alcuni progetti che la Provincia ha avviato negli ultimi tempi. In particolare, attraverso l’acquisizione del sistema di supervisione e dalla piattaforma di infomobilità la Provincia intende perseguire una parte degli obiettivi definiti all’interno dei progetti S.I.Mo.Ne e Wi-Move. Per entrambi i progetti la Provincia ha ottenuto dei cofinanziamenti dal Dipartimento degli Affari Regionali (DAR) nell’ambito del programma ELISA e dalla Regione Toscana. I partner del progetto sono i Comuni di Torino (capofila del raggruppamento) e Genova, e Bologna e le Province di Cagliari e per l'appunto di Firenze. I partner del progetto Wi-Move sono i Comuni di Roma (capofila del raggruppamento), Genova, Parma e Cagliari, e la Provincia di Firenze. Per quanto riguarda la Provincia di Firenze, entrambi i progetti interessano il territorio di competenza dell’Amministrazione Provinciale, con particolare riferimento alla zona del Comune capoluogo e dei comuni limitrofi. A tal proposito, tra l’altro, la Provincia ed il Comune di Firenze hanno sottoscritto uno specifico protocollo per lo sviluppo di una progettualità integrata di ambito metropolitano sul tema dell'infomobilità. Il Supervisore che la Provincia intende acquisire, tra le altre caratteristiche, ha quella di poter integrare dati di traffico provenienti da fonti di acquisizione diverse, ed in particolare anche da flotte di vetture equipaggiate con dispositivi di bordo in grado di inviare in tempo reale posizione e/o altri parametri quali la velocità. Il progetto S.I.Mo.Ne nella sua totalità mira a realizzare un’architettura aperta e generalizzabile di supervisione del traffico che possa acquisire dati da fonti molteplici, e su questa base identificare e predire lo stato del traffico sulla rete, con il duplice obiettivo di utilizzare queste informazioni a fini di infomobilità (cioè di diffusione di informazioni al pubblico) e al fine di migliorare la capacità di governo del traffico da parte degli Enti Locali preposti. Una caratteristica particolarmente innovativa del progetto è quella di includere tra i dati che il Supervisore è in grado di trattare ai fini di ricostruzione dello stato anche i dati provenienti da flotte di veicoli (le tecniche cosiddette di Floating Car Data o FCD); a tal fine parte integrante ed importante del progetto è rappresentata dalla definizione di protocolli logici e fisici standard di acquisizione da parte del Supervisore di traffico dei dati FCD, che sono stati impiegati come requisiti funzionali del presente capitolato. I vari Enti partner del progetto implementeranno queste tecniche FCD per la ricostruzione degli stati di traffico sui propri supervisori, in contesti applicativi ovviamente differenti, poiché ogni Ente è dotato di sistemi differenti di gestione del traffico e di acquisizione dati da campo, ed in generale di architetture particolari di sala controllo. Ciononostante è intenzione dei partner ed obiettivo del progetto realizzare supervisori di traffico che abbiano caratteristiche funzionali comuni. In particolare per i supervisori che saranno acquisiti dai vari Enti, tendenzialmente saranno richieste:

Pagina 5

• la stessa architettura fisica e logica del Supervisore;

• funzioni logiche identiche;

• impiego degli stessi protocolli di acquisizione dati da altri sottosistemi di governo/controllo del traffico e similari; in particolare gli stessi protocolli di acquisizione dati da centri di servizio che forniscano dati FCD;

• impiego degli stessi meccanismi di rappresentazione dati su grafo e/o su cartografia/GIS;

• impiego degli stessi protocolli per l’export dati verso applicazioni esterne di infomobilità.

Gli Enti partner del progetto, quindi, hanno reciprocamente collaborato alla stesura dei rispettivi capitolati per produrre documentazione ispirata ai principi sopra enunciati. Un altro principio ispiratore del progetto è quello della massima riutilizzabilità dei prodotti messi a punto. A tal fine, i requisiti funzionali definiti prevedono l’impiego di standard tecnologici ampiamente diffusi e privilegiano l’impiego da parte del fornitore di tools non proprietari e la realizzazione di sistemi che possano essere diffusi con il minor numero di vincoli tecnologici e contrattuali. Nel caso specifico, la gara cui fa riferimento il presente capitolato, è bandita dalla Provincia di Firenze. Come sopra indicato, l’ambito territoriale di applicazione del Supervisore, in questo caso, è quindi quello dell’intera Provincia di Firenze, incluso il Comune capoluogo ed i Comuni limitrofi. Nell’ambito dello sviluppo congiunto di progettualità sul tema dell’infomobilità i contenuti essenziali del presente capitolato sono stati condivisi tra la Provincia ed il Comune di Firenze, ed i sistemi che il Supervisore dovrà interfacciare fanno capo in parte alla Provincia ed in parte al Comune di Firenze, o a soggetti a loro collegati. Nella stesura delle presenti specifiche tecniche, si è inoltre tenuto conto delle applicazioni che la Regione Toscana sta sviluppando soprattutto per quanto riguarda l’infomobilità ed i sistemi GIS. In particolare la rappresentazione geografica dei dati e l’export dati verso applicazioni esterne tengono pertanto conto dell’interfacciabilità con le applicazioni sviluppate dalla Regione. Inoltre, sempre nell’ambito della presente procedura di gara, la Provincia si doterà di una piattaforma di distribuzione delle informazioni riguardante la mobilità, che qui brevemente chiameremo “piattaforma di infomobilità”. Questa piattaforma sarà strettamente integrata con il Supervisore sopra descritto, da cui attingerà dati, e si interfaccerà anche con altre applicazioni, come più dettagliatamente descritto nel seguito. Nel quadro di riferimento del protocollo già citato, la Provincia ed il Comune di Firenze hanno sottoscritto uno specifico protocollo per la realizzazione di un’infrastruttura di rete in tecnologia wireless da realizzarsi lungo la Linea 1 della tramvia di Firenze. Il primo obiettivo del progetto è quello di erogare – tramite la piattaforma di cui trattasi – servizi di infomobilità al pubblico attraverso tale rete; in aggiunta, si prevede che gli stessi servizi siano resi disponibili agli utenti dotati di connettività Internet personale. Successivamente la distribuzione delle informazioni potrà essere estesa ad altri canali ed altre modalità, fermo restando l’impiego della medesima piattaforma per la generazione e la gestione delle informazioni. La piattaforma di infomobilità, quindi, tra le altre cose, si propone quale strumento per veicolare all’utenza della rete realizzata nell’ambito del progetto Wi-

Pagina 6

Move i dati raccolti ed elaborati con le soluzioni sviluppate nell’ambito del progetto S.I.Mo.Ne. Attraverso l’acquisizione di un sistema integrato che comprenda sia il Supervisore che la piattaforma di mobilità la Provincia intende massimizzare i benefici attesi dal dispiegamento sul proprio territorio di soluzioni innovative nel campo dell’infomobilità.

2 Descrizione generale della fornitura e delle sue finalità e

caratteristiche L’oggetto della fornitura prevista dal presente capitolato è costituito da:

• Una piattaforma di supervisione del traffico a livello provinciale;

• Una piattaforma di gestione dell’infomobilità e di distribuzione dell’informazione;

• L’hardware di vario genere necessario ad ospitare le suddette piattaforme e ad interfacciarle con i vari altri sistemi con cui esse dovranno colloquiare, ivi inclusi i dispositivi di rete;

• I servizi di configurazione iniziale del Supervisore e della piattaforma di infomobilità e di taratura e messa a punto dei modelli impiegati nel Supervisore;

• La manutenzione in garanzia del sistema implementato ed un supporto on line per l’esercizio;

• Il training e la formazione al personale che sarà indicato per la gestione del sistema e il supporto all’avvio operativo dello stesso;

• La documentazione di sistema. Il sistema costituisce quindi un sistema integrato di acquisizione, elaborazione e distribuzione di informazioni sulla mobilità ed in particolare sullo stato del traffico. Data l’intrinseca dimensione sovra-comunale dei fenomeni di mobilità, l’ambito territoriale di applicazione e di funzionamento del Supervisore sarà quello della Provincia di Firenze, con una particolare attenzione all’area urbana fiorentina, ma in una prospettiva di integrazione non solo delle informazioni ma anche delle politiche di gestione. Al fine di garantire una gestione unitaria di questo strumento, nell’ambito del quadro di riferimento definito dal citato protocollo d’intesa, la Provincia ed il Comune di Firenze si apprestano a sottoscrivere specifici accordi attuativi. La piattaforma che si appronterà attraverso questa fornitura deve, nelle intenzioni delle Amministrazioni, diventare uno degli strumenti principali della gestione del traffico e della mobilità nel comprensorio. Attorno ad esso si costituirà infatti una sala di controllo capace di :

• Operare su una rappresentazione unitaria del grafo stradale e della relativa restituzione cartografica;

• Centralizzare le informazioni provenienti da tutti i sistemi che a vario titolo governano parti del sistema globale della mobilità, pubblica e privata, compresi i sistemi di rilevamento della qualità dell’aria;

• Elaborare tali informazioni in tempo reale a differenti scopi: o Ottenere un quadro sintetico dello stato del traffico; o Identificare con il massimo preavviso situazioni di eventuale criticità e

fronteggiarle in modo adeguato;

Pagina 7

o Sintetizzare informazioni utili al governo del sistema di mobilità e ad ottimizzare l’uso delle risorse da parte dell’utente ed inviarle ai cittadini o a particolari classi di essi sfruttando la grande varietà di canali di distribuzione delle informazioni impiegabili;

o Elaborare strategie di governo di singoli sottosistemi (ad esempio set point per i sistemi UTC, messaggistica, ecc.) in relazione all’occorrenza di determinati pattern del traffico;

• Processare i dati acquisiti e quelli elaborati in tempo reale al fine di: o Costituire un data repository di tutte le misure di traffico confrontabili tra di

loro e riferite ad un grafo unitario; o Costruire un repository dei dati di qualità ambientale rilevati per poterli

correlare con le situazioni di traffico; o Catalogare situazioni caratteristiche di traffico e le relative azioni correttive

adottate a livello di regolazione e di informazione; o Elaborare a fini statistici (nei termini di ingegneria del traffico) i dati; o Interfacciare il mondo della “pianificazione della mobilità”, e cioè fornire dati

e loro elaborazioni statistiche ai modelli di simulazione esistenti. Il sistema dovrà inoltre costituire la base per ulteriori possibili espansioni in termini di:

• possibilità di collegamento di ulteriori sistemi di acquisizione dati, di infomobilità o di governo della mobilità, nonché di ampliamento di quelli esistenti;

• possibilità di distribuire informazioni attraverso nuovi canali utilizzando la stessa piattaforma di generazione e trattamento delle informazioni e di gestione delle comunicazioni;

• possibilità di implementare sul sistema esistente nuove funzionalità; in particolare il sistema dovrà essere aperto a poter includere funzioni quali:

o routing dinamico con istradamento dei flussi sugli itinerari più appropriati mediante invio di informazione (ciò anche, come caso particolare, per quanto riguarda l’istradamento verso i parcheggi);

o assegnazione in tempo reale di matrici OD e loro eventuale tuning in funzione dei dati di carico di rete rilevati.

Si richiede espressamente che il sistema possieda caratteristiche di innovatività rispetto ai supervisori di traffico correntemente disponibili. Inoltre esso dovrà possedere caratteristiche di standardizzazione e possibilità di essere personalizzato in funzione dei differenti ambiti applicativi in cui sarà collocato. Il Supervisore dovrà quindi possedere le seguenti caratteristiche:

• capacità di integrare dati provenienti da flotte (FCD) all’interno della propria struttura dati e di utilizzare questi dati per la ricostruzione degli stati di traffico e per le altre funzionalità richieste;

• standardizzazione delle interfacce verso i sistemi di acquisizione/invio dati mediante l’utilizzo di protocolli e di un tracciato standard per lo scambio dati;

• standardizzazione delle interfacce verso i sistemi di dispatching delle informazioni attraverso adozione di protocolli e tracciati standard per lo scambio, tenendo anche conto dei protocolli di mercato impiegati nel settore dell’infomobilità per l’interfacciamento verso mezzi mobili.

Pagina 8

Dal punto di vista funzionale il sistema oggetto della fornitura può essere suddiviso in due parti principali, che nel prosieguo saranno specificate separatamente:

1. il Supervisore; 2. la piattaforma di generazione e diffusione delle informazioni (piattaforma di

infomobilità).

3 Ambito applicativo in cui si inserisce il Supervisore di traffico

della Provincia e del Comune di Firenze Il Supervisore della Provincia di Firenze si inserisce in un ambito caratterizzato dalla presenza di molti sistemi di gestione del traffico e della mobilità, piuttosto parcellizzati e gestiti da soggetti differenti. In questo capitolo saranno fornite le principali informazioni sui sistemi da interfacciare con il sistema di supervisione oggetto della presente specifica. Per ognuno di essi in una scheda sintetica vengono riportate le principali informazioni generali e quelle riguardanti i dati da acquisire e le relative modalità di interfacciamento che potranno essere utilizzate.

3.1 Lista dei sistemi da interfacciare

I sistemi che il Supervisore dovrà interfacciare sono i seguenti: o Sistema di acquisizione dati di traffico basato su sensori ad

infrarossi/ultrasuoni del Comune di Firenze, gestito da Silfi; o Sistema di centralizzazione semaforica del Comune di Firenze, che raccoglie

anche dati sui volumi di traffico mediante spire induttive, gestito da Silfi; o Sistema di gestione di pannelli a messaggio variabile del Comune di Firenze

gestito da Silfi; o Sistema di acquisizione di dati ambientali della Provincia di Firenze, gestito

da ARPAT; o Sistema di gestione dei parcheggi in struttura del Comune di Firenze, gestito

da Firenze Parcheggi; o Sistema di gestione delle ordinanze della Provincia di Firenze (il sistema

informativo che raccoglie le informazioni sulle variazioni di viabilità relative a cantieri, eventi, e così via);

o Sistema di gestione delle ordinanze del Comune di Firenze (il sistema informativo che raccoglie le informazioni sulle variazioni di viabilità relative a cantieri, eventi, e così via);

o Sistema di gestione della ZTL del Comune di Firenze gestito da Società Autostrade per l’Italia;

o Sistema di raccolta dati di traffico sulle strade provinciali della Provincia di Firenze gestito da Società Autostrade per l’Italia;

o Sistema integrato di acquisizione di dati di traffico, di pannelli a messaggio variabile e di telecamere per la videosorveglianza del traffico della Provincia di Firenze sulla Firenze-Pisa-Livorno, gestito da Società Autostrade per l’Italia;

o Sistema AVM per la gestione della flotta degli autobus del trasporto pubblico urbano di Firenze gestito da ATAF (lo stesso sistema AVM è

Pagina 9

impiegato anche da LINEA, una società partecipata da ATAF che eroga una parte del servizio, nelle zone suburbane);

o Sistema di videosorveglianza del traffico impiegato nella centrale della Polizia Municipale e gestito dagli Uffici Tecnici del Comune di Firenze.

Inoltre, benché al momento attuale non siano ancora attivi, vanno considerati altri due sistemi, integrati tra di loro:

o Sistema AVM della linea tranviaria in via di costruzione, che sarà gestito dalla Società GEST;

o Sistema di regolazione semaforica degli impianti attraversati dalla linea tranviaria stessa, con gestione della priorità al tram, che sarà gestito della stessa Società.

Ognuno di essi sarà nel seguito descritto separatamente, ricorrendo ove necessario ad allegati. La piattaforma di infomobilità, utilizzerà prevalentemente le informazioni acquisite dal Supervisore, ma a sua volta interfaccerà direttamente i seguenti sistemi:

o Sistema di gestione dei servizi di autenticazione, autorizzazione e accounting della infrastruttura wireless, o di altre basi dati utenti, tramite protocollo RADIUS;

o Sistema di gestione dei servizi di localizzazione utenti della infrastruttura wireless tramite web service;

o Sistemi di information providing e news-feeding tematico (notizie, sport, ecc.);

o Sistema AVM (sopra citato), per l’acquisizione “on demand” dei tempi di transito degli autobus/tram alla fermata.

La piattaforma dovrà inoltre essere aperta a poter acquisire informazioni da altre fonti e sistemi esterni.

Pagina 10

3.2 Descrizione sintetica dei singoli sistemi

3.2.1 Sistema di raccolta dati di traffico infrarossi/ultrasuoni – Comune di

Firenze

• Denominazione del sistema

o Sistema di rilevamento traffico con sensori ACITRAFF

• Ente proprietario del sistema

o Comune di Firenze

• Ente gestore del sistema

o SILFI S.p.A. – via dei Della Robbia - Firenze

• Azienda produttrice

o ITACO srl per ACICONSULT

• Stato di attuazione del sistema (in esercizio, in via di preparazione, ecc.)

o In esercizio.

• Localizzazione del server (o stazione centrale) del sistema con cui il Supervisore si

dovrà interfacciare

o Presso Società SILFI

• Disponibilità in sito di collegamenti di rete e relativi apparati, protocolli gestiti.

o Il server attualmente non è collegato in rete. Vi è comunque in prossimità un

accesso alla rete FiNet. Occorre verificare la possibilità di collegamento e la

disponibilità di accessi e indirizzi.

• Funzioni svolte dal sistema

o Il sistema è composto di 16 stazioni di misurazione del traffico realizzate da

sensori ACITRAFF a doppia tecnologia, infrarossi e ultrasuoni (si veda

allegato 1). I sensori sono installati sui portali dei pannelli posti in ambito

cittadino. I sensori sono collegati a una centralina che memorizza i dati

organizzati per giorno di rilevamento. La centralina è collegata ad un

modem GSM. Il server centrale giornalmente esegue il collegamento con le

centraline periferiche e scarica i file dati memorizzati creando un archivio dei

Pagina 11

dati di traffico sulle sezioni controllate. Nella figura che segue è illustrata

l’architettura del sistema.

I dati raccolti riguardano conteggio, tasso di occupazione, classificazioni dei veicoli su tre tipologie di lunghezza, velocità, e sono aggregati tipicamente su 15 minuti.

• Dati che devono essere inviati al / acquisiti dal Supervisore e relativa codifica

o Il Supervisore dovrà acquisire dal sistema almeno i seguenti dati statici (e

ovviamente tutte le loro eventuali modifiche dovessero occorrere):

� Configurazione e posizione degli apparati periferici

o Il Supervisore dovrà acquisire dal sistema i seguenti dati dinamici

� Su base giornaliera acquisire i dati raccolti il giorno precedente

riguardanti i dati di traffico volumetrici e classificati (per velocità e

tipologia).

• Frequenza di acquisizione degli stessi

o giornaliera

• Meccanismo e protocollo di scambio dati in input al Supervisore

Pagina 12

o Il meccanismo con cui il Supervisore acquisisce i dati avviene tramite file

transfert

NOTA : La Società Silfi è in procinto di integrare il sistema esistente mettendolo in grado di acquisire e trasmettere al centro dati in tempo reale con una frequenza programmabile. Quando questa versione del sistema sarà disponibile, il Supervisore dovrà essere in grado di acquisire i dati di traffico di cui sopra in tempo reale con i requisiti di frequenza definiti nel presente capitolato.

Pagina 13

3.2.2 Sistema di centralizzazione semaforica – Comune di Firenze


o SIGMA – Sistema di centralizzazione semaforica (UTC)


o Comune di Firenze




o ELSAG DATAMAT S.p.A. - Genova


o In esercizio.



o Presso SILFI


o Il server attualmente non è collegato in rete. Presso SILFI è attestata la rete

FiNet ed esiste un patch panel ottico del Comune di Firenze che è

utilizzabile. Sono a disposizione 4 indirizzi IP statici.


o Il sistema provvede alla regolazione di 105 impianti semaforici dislocati sul

territorio e connessi al centro mediante linee dedicate o affittate Esso

connette i regolatori semaforici locali ed acquisisce anche dati da 33 sezioni

di misura collegate agli impianti semaforici stessi . L’ allegato 2 contiene la

lista degli impianti centralizzati e delle sezioni di misura dei flussi di traffico

gestite dall’UTC.


o Il Supervisore dovrà acquisire dal sistema UTC almeno i seguenti dati statici

(e ovviamente tutte le loro eventuali modifiche dovessero occorrere):

Pagina 14

� Localizzazione e composizione degli impianti semaforici e

caratteristiche dei relativi regolatori

� Insieme dei piani semaforici associati ai vari impianti

� Localizzazione, tipologia e caratteristiche dei sensori di traffico gestiti

dall’UTC (così come descritto per i sistemi di acquisizione dati di

traffico)

o Il Supervisore dovrà acquisire dal sistema UTC i seguenti dati dinamici in

tempo reale

� Dati di traffico associati ai punti di misura gestiti dall’UTC secondo le

modalità descritte per i sistemi di acquisizione dati di traffico

� Piano semaforico attualmente vigente per ogni impianto

� Informazioni diagnostiche sugli impianti (attivo/in avaria)


o I dati statici andranno acquisiti in sede di configurazione e di eventuali

modifiche alla configurazione degli impianti e/o dei piani

o Per i dati dinamici di traffico (ferma restando la programmabilità della

frequenza di acquisizione), occorre prevedere la possibilità di acquisire con

un periodo minimo 1 minuto. I piani semaforici associati agli impianti

possono essere comunicati in modo sincrono in corrispondenza

dell’acquisizione dei dati di traffico o in maniera asincrona in occorrenza

dell’evento di variazione del piano attivo.


o Connessione al Data-Base UTC attraverso un processo middle-tier. Sul server

UTC verrà creato un processo che permetterà attraverso una connessione

TCP/IP la pubblicazione dei dati di interesse. Il processo middle-tier creato

sul server UTC riceve in input dal Supervisore, tramite la connessione TCP,

query al data base UTC in formato XML e invia al Supervisore nello stesso

formato il risultato delle query stesse.

• Dati che eventualmente devono essere inviati dal Supervisore al sistema su evento

o Il Supervisore deve essere in grado di inviare al sistema UTC i set point di

piano per i vari impianti semaforici. L’informazione consiste nella codifica

dell’impianto cui si fa riferimento e del piano che deve essere associato a

Pagina 15

quell’impianto. Tale scopo deve essere fatta un’analisi dettagliata e creare

sul Supervisore un set di comandi disponibili che possono essere inviati al

sistema UTC e aggiornare tale set in base allo stato del sistema e alle

modifiche di configurazione della regolazione operate dai gestori del sistema

UTC. I comandi, o meglio le richieste, del Supervisore verranno processate

dal sistema UTC secondo una soglia di priorità da definire.

• Meccanismo e protocollo di scambio dati output dal Supervisore

o Connessione TCP/IP. O attraverso lo stesso processo di accesso al Data base

o con altro processo da sviluppare sul server UTC.

NOTA : Il Comune di Firenze ha in programma l’upgrade dell’esistente software di

centralizzazione semaforica con la nuova generazione del prodotto SIGMA PLUS. In

funzione dei tempi di realizzazione del Supervisore e di questo upgrade, il Supervisore

stesso si dovrà poter interfacciare con la attuale o con la nuova versione del software di

centralizzazione.

Pagina 16

3.2.3 Sistema di gestione di pannelli a messaggio variabile - Comune di Firenze


o Sistema di gestione PMV


o Comune di Firenze




o Solari di Udine


o In esercizio.



o Presso SILFI


o Il server attualmente non è collegato in rete. Presso SILFI è attestata la rete

FiNet ed esiste un patch panel ottico del Comune di Firenze che è

utilizzabile. Sono a disposizione 4 indirizzi IP statici.


o Il sistema provvede alla gestione di 14 pannelli a messaggio variabile

dislocati sul territorio e connessi al centro mediante linee dedicate o affittate

(si veda allegato 3) . Esso connette i controllori locali dei PMV, cui dal centro

possono essere inviati messaggi mediante definizione di un programma

orario di invio dei messaggi stessi o mediante forzatura da parte di un

operatore di un messaggio su un singolo pannello .


Pagina 17

o Il Supervisore dovrà acquisire dal sistema di gestione PMV almeno i seguenti

dati statici (e ovviamente tutte le loro eventuali modifiche dovessero

occorrere):

� Localizzazione e id pannello

� Coordinate georeferenziate pannello

� Tipo di pannello (numerico/grafico)

� N. righe

� N. caratteri/riga/pagine

o Il Supervisore dovrà acquisire dal sistema di gestione PMV i seguenti dati

dinamici in tempo reale

� Messaggio corrente visualizzato per ognuno dei pannelli

� Informazioni diagnostiche sui pannelli (attivo/in avaria)




o Per i dati dinamici la acquisizione può avvenire in maniera asincrona nel

momento di variazione del messaggio visualizzato.


o Le informazioni saranno inviate in formato XML dal sistema pannelli

utilizzando un protocollo http in risposta a richieste del Supervisore. Le

modalità di dettaglio verranno concordate con i responsabili tecnici di Solari

di Udine.


o Il Supervisore deve essere in grado di inviare ai singoli pannelli messaggi

specifici; l’operatore di centrale dovrà essere in grado di selezionare un

singolo pannello e di compilare un messaggio da inviare ad esso, associato ai

relativi parametri (tempo di permanenza del messaggio).


o Anche in questo caso i comandi verranno transitati dal Supervisore al

sistema appoggiandosi ad un protocollo basato su http e formato XML da

Pagina 18

concordare. I comandi verranno messi in esecuzione secondo le modalità in

uso nel sistema pannelli. Il Supervisore avrà informazione della corretta

ricezione del comando e alla sua visualizzazione avrà informazione del

nuovo stato dei pannelli e delle informazioni esposte secondo quanto detto

sopra.

Pagina 19

3.2.4 Sistema di monitoraggio dei parametri ambientali – Provincia di Firenze


o Sistema di Rilievo Dati Ambientali Provincia di Firenze


o Provincia di Firenze


o ARPAT


o Project Automation S.p.A. - Milano


o In esercizio.



o Presso ARPAT via Porpora - Firenze


o Esiste una connessione con la rete regionale RTRT collegata a sua volta con

FiNet.


o Il sistema di monitoraggio dei dati ambientali è composto da 19 stazioni di

rilevamento localizzate sul territorio provinciale. Le centraline sono

attrezzate con sensori di misura degli inquinanti (CO, NOx, PM10, Ozono,

SO2) e su interrogazione inviano al centro i dati rilevati nel periodo

intercorrente dall’ultima rilevazione , aggregando i dati su media oraria. La

centralina, in ragione della posizione in cui è installata, ha una

configurazione di sensori diversa. Delle 19 stazioni ve ne sono 6 che rilevano

anche i dati meteo;

� Precipitazione totale

� Temperatura minima

Pagina 20

� Temperatura massima

� Temperatura media

� Velocità media del vento

� Direzione del vento (di velocità massima)

� Pressione media

� Radiazione globale

I dati meteo e degli inquinanti vengono centralizzati sul server e sono sottoposti a validazione prima di essere diffusi, come da normativa vigente, al fine di evitare false comunicazione a fronte si starature o imprecisioni evidenti della sensoristica a campo. In allegato 11 è riportata la tabella con il dettaglio della localizzazione e composizione della sensoristica.


o Il Supervisore dovrà acquisire dal sistema Dati Ambientali almeno i seguenti


occorrere):

� Localizzazione e configurazione delle centraline

o Il Supervisore dovrà acquisire dal sistema Dati Ambientali i seguenti dati


� Dati ambientali validati e ora di rilevamento

� Informazioni diagnostiche sulle centraline (attiva/in

avaria/degradata)



modifiche alla configurazione degli impianti

o Per i dati dinamici il rate di acquisizione è legato al processo di acquisizione

e validazione in uso in ARPAT; comunque il rate sarà di 60 minuti, intervallo

tipico di aggregazione delle rilevazioni acquisite. Un’ulteriore possibilità è

quella di trasferire pacchetti di dati relativi a periodi programmabili (ad

esempio un’intera giornata) qualora la validazione richieda questi tempi o

per recuperare successivamente ad una interruzione del processo di

acquisizione. Il Supervisore dovrà comunque, per questi dati, prevedere una

Pagina 21

funzionalità di abilitazione alla pubblicazione gestita da operatore

autorizzato, che rispecchi la normativa vigente.


o Il meccanismo con cui il Supervisore acquisisce i dati di suo interesse è

realizzato attraverso connessione al DataBase del server Dati Ambientali di

ARPAT. Sul server verrà messo a disposizione un account per l’accesso in

sola lettura del processo di acquisizione del Supervisore alle tabelle

contenente i dati di interesse. Il controllo dell’accesso è realizzato attraverso

la procedura di login al Data Base.

Pagina 22

3.2.5 Sistema di gestione dei parcheggi in struttura – Comune di Firenze


o Sistema di gestione parcheggi


o Firenze Parcheggi S.p.A.


o Firenze Parcheggi S.p.A.


o SKIDATA - Bologna


o In esercizio.



o Ogni parcheggio in struttura è equipaggiato con un sistema che contempla

una stazione centrale contenete le basi dati; tale stazione centrale è

localizzata presso il parcheggio stesso. I vari sistemi periferici non sono

centralizzati, per cui per l’acquisizione dati occorre accedere alle singole

stazioni centrali dei vari sistemi di gestione parcheggi. (si veda Allegato 4)


o Tutti i parcheggi sono collegati in rete in fibra ottica tra di loro e alla sede

centrale di Firenze Parcheggi . La rete è una VPN su rete IP.


o Per ogni parcheggio il sistema provvede alla registrazione di tutti gli accessi

e le uscite da tutti gli ingressi/uscite dei parcheggi e fornisce il saldo dei

posti disponibili. Questa informazione è anche inviata a pannelli a messaggio

variabile distribuiti sul territorio, associati in maniera statica ai singoli

parcheggi. Il sistema svolge poi anche tutte le funzioni di tipo

amministrativo e gestionale di scarsa importanza per l’applicazione in

questione.


Pagina 23

o Il Supervisore dovrà acquisire dal sistema di gestione dei parcheggi almeno i

seguenti dati statici (e ovviamente tutte le loro eventuali modifiche

dovessero occorrere):

� Nome parcheggio

� Id parcheggio

� Capienza

� Per ogni ingresso / uscita

• Nome via

• Id ingresso/uscita

• Arco grafo su cui insiste

• Coordinate georeferenziate

� PMV collegati al parcheggio

• Localizzazione georeferenziata

• Toponimo

• Id arco grafo

� Tariffe

� Orario apertura

� Orario chiusura

o Il Supervisore dovrà acquisire dal sistema di gestione dei parcheggi i

seguenti dati dinamici in tempo reale

� Posti liberi o occupati

� Per ogni ingresso / uscita

• Numero ingressi ultimo intervallo

• Numero uscite ultimo intervallo

� Info diagnostiche

• Per ogni parcheggio : chiuso/aperto/

Pagina 24

• Per ogni ingresso/uscita di ogni parcheggio : disponibile / non

disponibile




o Per i dati dinamici di traffico il fornitore potrà scegliere se acquisirli su

evento di variazione dello stato o su richiesta a frequenza o a polling, poiché

il sistema di gestione dei parcheggi prevede queste modalità di scambio dati.


o Il meccanismo più semplice è quello per cui fornitore potrà accedere ai dati

contenuti nel data base dei singoli impianti attraverso l’invio di un

messaggio che contiene la query in formato SQL operato sulla/e tabelle di

DataBase indicate dal produttore. In tal modo la richiesta potrà riguardare,

secondo le diverse esigenze, intervalli temporali o contenuti informativi

diversi. In alternativa sono realizzabili WEB SERVICES che forniscono a

tempo i dati di interesse.


o N/A


o N/A

Pagina 25

3.2.6 Sistema di gestione delle ordinanze – Provincia di Firenze


o SGO – Sistema Gestione Ordinanze






o Sinergis – loc. Palazzine 120 f 38014 Spini di Gardolo (TN)

www.sinergis.it


o In corso di realizzazione; completamento previsto nel corso del 2010



o Server interni alla provincia (via Cavour)


o Il sistema sarà collegato direttamente a Internet


o Sistema di gestione degli atti relativi a restrizioni, variazioni o cambiamenti

in atto sulla rete viaria provinciale (lavori in corso, cambi di corsia,

rifacimento strade, ecc). Il sistema si compone di una parte di back office,

gestita dagli operatori della Provincia, e un front-end web basato sul portale

WEGE della Provincia (attualmente in fase di installazione). Il sistema

mantiene sia una base dati alfanumerica (testo dell’atto, date di validità,

dirigente firmatario, ecc.), sia cartografica (tratti interessati dall’ordinanza e

relative chilometriche). Il sistema mette a disposizione le ordinanze inserite

in un formato XML, accessibile via Web Service da applicazioni di terze

parti. Tale formato sarà basato sullo standard GML (Geography Markup

Language), definito dal Open Geospatial Consortium.


Pagina 26

o In generale i dati che sono trasmessi da questo sistema al Supervisore sono

dati relativi a modifiche temporanee della viabilità, dei parcheggi o della

regolamentazione. Si tratta sempre di stringhe alfanumeriche di dati

caratterizzate da una codifica che contempla tutte le fattispecie di evento e

dalle informazioni accessorie per localizzarlo e caratterizzarlo. Per ogni

ordinanza, i dati di interesse per il Supervisore sono:

� Periodo di validità dell’ordinanza.

� Tratti di strada interessati e relative progressive di inizio/fine.

� Codice modifica viabilità (istituzioni sensi unici alternati, limitazioni

alla percorrenza, velocità ridotta, ecc.)

La codifica completa dei dati sarà messa a disposizione del fornitore in sede progettuale. In Allegato 5 è riportato il dettaglio del DataBase delle ordinanze.


o Asincrona, su evento “generazione nuova ordinanza”


o Il sistema di gestione delle ordinanze notifica al Supervisore mediante

chiamata WS l’introduzione di una nuova ordinanza. Su questa chiamata il

Supervisore interroga via WS il sistema, chiedendo la nuova ordinanza,

rappresentata in formato XML/GML.

o I web services opereranno mediante protocollo SOAP


o N/A


o N/A

Pagina 27

3.2.7 Sistema di gestione delle ordinanze – Comune di Firenze

Il Comune di Firenze si doterà di un sistema informatizzato di gestione delle ordinanze,

che adotterà gli stessi standard di interfacciamento descritti per l’omologo sistema della

Provincia di Firenze.


o SGO – Sistema Gestione Ordinanze


o Comune di Firenze


o Comune di Firenze


o Da individuare


o In corso di progettazione.



o Server farm del Comune di Firenze


o Il sistema sarà collegato direttamente alla rete comunale e a Internet


o Sistema di gestione degli atti relativi a restrizioni, variazioni o cambiamenti

in atto sulla rete viaria cittadina (lavori in corso, cambi di corsia, rifacimento

strade, ecc). Il sistema si compone di una parte di back office, gestita dagli

operatori della Provincia, e un front-end web basato sul portale WEGE della

Provincia (attualmente in fase di installazione). Il sistema mantiene sia una

base dati alfanumerica (testo dell’atto, date di validità, dirigente firmatario,

ecc.), sia cartografica (tratti interessati dall’ordinanza e relative

chilometriche). Il sistema metterà a disposizione le ordinanze inserite in un

formato XML, accessibile via Web Service da applicazioni di terze parti. Tale

Pagina 28

formato sarà basato sullo standard GML (Geography Markup Language),

definito dal Open Geospatial Consortium.


o In generale i dati che sono trasmessi da questo sistema al Supervisore sono

dati relativi a modifiche temporanee della viabilità, dei parcheggi o della

regolamentazione. Si tratta sempre di stringhe alfanumeriche di dati

caratterizzate da una codifica che contempla tutte le fattispecie di evento e

dalle informazioni accessorie per localizzarlo e caratterizzarlo. Per ogni

ordinanza, i dati di interesse per il Supervisore sono:

� Periodo di validità dell’ordinanza.

� Tratti di strada interessati e relativa toponomastica e civici (o altri

punti salienti) di inizio/fine.

� Codice modifica viabilità (istituzioni sensi unici alternati, limitazioni

alla percorrenza, velocità ridotta, ecc.)

La codifica completa dei dati sarà messa a disposizione del fornitore in sede progettuale.


o Asincrona, su evento “generazione nuova ordinanza”


o Il sistema di gestione delle ordinanze notifica al Supervisore mediante

chiamata WS l’introduzione di una nuova ordinanza. Su questa chiamata il

Supervisore interroga via WS il sistema, chiedendo la nuova ordinanza,

rappresentata in formato XML/GML.

o I web services opereranno mediante protocollo SOAP


o N/A


o N/A

Pagina 29

3.2.8 Sistema di gestione della ZTL – Comune di Firenze


o Sistema di gestione Zona a Traffico Limitato


o Comune di Firenze


o Società Autostrade per l’Italia




o In esercizio.



o Presso la direzione del IV tronco della Società Autostrade per l’Italia a

Calenzano.


o I server del sistema ZTL sono collegati sulla rete FiNet e attualmente si

accede ai dati attraverso una web application residente sulla intranet

comunale.


o Il sistema è destinato al rilevamento delle infrazioni di accesso a zona a

traffico limitato mediante uso di riconoscimento automatico del numero di

targa. In aggiunta a questa funzionalità principale, il sistema raccoglie tutti i

dati dei transiti nella sola direzione di ingresso all’area protetta lungo tutti

gli assi al cordone equipaggiati con gate di controllo accesso. Si tratta

complessivamente di 25 gate singoli o doppi. I dati di traffico raccolti sono

relativi alle singole corsie e sono classificati in categorie di veicoli in base alla

lunghezza in numero configurabile nei parametri di sistema . Al momento

attuale i dati vengono raccolti su base temporale di 15’, ma il sistema è in

grado di avere intervalli di aggregazione inferiori.

Pagina 30


o Il Supervisore dovrà acquisire dal sistema di gestione ZTL almeno i seguenti


occorrere):

� Localizzazione, tipologia e caratteristiche dei sensori di traffico gestiti

dal sistema di gestione ZTL (così come descritto per i sistemi di

acquisizione dati di traffico)

� Orari di vigenza della regolamentazione di restrizione degli accessi

(eventualmente per ogni singolo gate se diversificati).

o Il Supervisore dovrà acquisire dal sistema di gestione ZTL i seguenti dati


� Dati di traffico associati ai punti di misura gestiti dal sistema di

gestione ZTL secondo le modalità descritte per i sistemi di

acquisizione dati di traffico

� Informazioni sullo stato dei gates (attivo/funzionante ma non

attivo/in avaria)



modifiche alla configurazione degli impianti o di modifica della normativa



un periodo minimo 1 minuto, benché al momento attuale i dati siano

aggregati su base temporale di 15’.


o I sistemi sono entrambi appoggiati sulla rete FiNet. La modalità di

acquisizione dei dati verrà fatta attraverso moduli di interfacciamento che

appoggiandosi a protocolli IP (http, TCP..) e utilizzando formato XML

permettano di effettuare richieste di dati al sistema ZTL utilizzando query

SQL standard e avendo in risposta il risultato. Il meccanismo permette di

avere un accesso ai dati ZTL senza un accesso diretto al DB.


o N/A

Pagina 31


o N/A

Pagina 32

3.2.9 Sistema SICURTRAF di monitoraggio delle stradi provinciali - Provincia di

Firenze


o Sistemi di raccolta dati di traffico sulle strade interurbane








o In corso di graduale installazione. Alcune stazioni sono già in esercizio e le

rimanenti previste entreranno gradualmente in servizio nel corso del 2010



o Presso la Direzione del IV tronco di Società Autostrade a Calenzano


o L’accesso ai dati potrà essere realizzato attraverso l’impiego della rete a

banda larga della Provincia con cui è previsto un collegamento del sistema.

o Tutto gli apparati sono collegati con il centro attraverso una rete TCP/IP


o Il sistema Sicurtraf è un sistema composto da differenti tipi di sensori e di

sistemi di diffusione delle informazioni integrati tra di loro, per il

monitoraggio delle principali tratte delle strade della Provincia di Firenze.

In particolare il sistema dispone dei seguenti apparati di campo :

� Sensori di rilevamento traffico (54)

� Sensori di rilevamento ghiaccio/neve/meteo (7)

� PMV per informazione all’utenza su strada via (25)

� Telecamere (30)

Pagina 33

Inoltre il sistema può inviare SMS, MMS, alimentare pagine web e fare dispatching di messaggi radiofonici.

o Sensori di raccolta dati di traffico : il sistema raccoglie dati di traffico in

sezione stradali delle strade provinciali della Provincia di Firenze. che

raccoglieranno dati in entrambi i sensi di marcia e per ognuna delle corsie di

ogni senso di marcia. I dati raccolti sono classificati per tipologia di veicolo e

classi di velocità. Inoltre il sistema elabora automaticamente alcuni indici

globali. Il sistema genera tutti i dati in automatico al transito di ogni singolo

veicolo; essi sono poi aggregati su intervalli temporali programmabili.

I dati raccolti e calcolati sono i seguenti:

• ora di transito dei veicoli;

• data di transito dei veicoli;

• numero progressivo di transito dei veicoli (conteggio);

• corsia di transito dei veicoli;

• direzione di marcia dei veicoli;

• classificazione dei veicoli;

• velocità dei veicoli;

• distanza fra i veicoli;

• occupazione %;

• condizioni di “traffico rallentato”;

• condizioni di “traffico fermo”.

o Sensori di rilevamento meteo :

Sono in grado di rilevare i seguenti parametri:

• temperatura superficiale della pavimentazione;

• punto di congelamento;

• strato superficiale di acqua;

• condizione della superficie stradale (asciutta, umida, bagnata,

presenza di ghiaccio, presenza sostanze chimiche);

• allerta presenza acqua/ghiaccio;

• velocità e direzione del vento;

• pioggia;

• temperatura e umidità dell’aria;

• pressione atmosferica;

• punto di rugiada.

o Pannelli a Messaggio Variabile (PMV) : saranno del tipo “in itinere installati

a lato strada. I PMV saranno tutti composti da un modulo pittogramma e da

Pagina 34

un modulo testo. I PMV verranno gestiti da un software applicativo in uso

presso il centro di controllo Sicurtraf.

o Telecamere : il sistema delle telecamere consentirà di rilevare immagini a

colori e trasmetterle al centro di controllo. La codifica del segnale video sarà

di tipo standardizzato (MPEG, H.26x, ecc.) e ottimizzata per una

trasmissione da 9,6 Kbit/s a oltre 1 Mbit/s. L’encoder sarà in grado di

adeguare la velocità di trasmissione e/o la risoluzione, in funzione della

qualità e della quantità di banda disponibile sulla rete. Dovrà inoltre avere la

possibilità di gestire un canale bidirezionale di comunicazione per l’utilizzo

di brandeggio e zoom. I filmati delle telecamere, in modalità live oppure nei

formati rolling o registrazione, verranno resi disponibili agli applicativi

mediante l’utilizzo di Streaming Server e Video server con interfaccia web.

o Il sistema genererà messaggi SMS gestiti da un apposito modulo e distribuiti

all’utenza.

In allegato 12 sono riportate la localizzazione e la composizione delle postazioni del

sistema SICURTRAF.


o Il Supervisore dovrà acquisire dal sistema di raccolta dati di traffico sulle

strade interurbane almeno i seguenti dati statici (e ovviamente tutte le loro

eventuali modifiche dovessero occorrere):

� Localizzazione, tipologia e caratteristiche dei sensori di traffico, meteo,

dei PMV e delle telecamere (così come descritto per i sistemi di

acquisizione dati di traffico, dati ambientali, PMV)

� Frequenza di acquisizione e di aggregazione dei dati rilevati

o Il Supervisore dovrà acquisire i seguenti dati dinamici in tempo reale

� Dati di traffico associati ai punti di misura gestiti dal sistema raccolta

dati di traffico sulle strade interurbane secondo le modalità descritte

per i sistemi di acquisizione dati di traffico e tenendo conto dei dati

disponibili sopra elencati.

� Informazioni diagnostiche sulle postazioni di misura (attiva/non

attiva/in funzionamento degradato)

� Dati meteo associati ai vari punti di misura e alle misurazioni di

traffico acquisite, tenendo conto dei dati disponibili sopra elencati.

Pagina 35

� Informazioni diagnostiche sulle postazioni di misura (attiva/non

attiva/in funzionamento degradato)

� Messaggio corrente visualizzato per ognuno dei pannelli a messaggio

variabile

� Informazioni diagnostiche sui pannelli (attivo/in avaria)

� Messaggi SMS generati dal sistema.

� Il Supervisore dovrà poter inoltre visualizzare in apposite finestre i

flussi video provenienti da una qualunque delle telecamere collegate,

semplicemente mediante selezione da sinottico. Il Supervisore potrà

accedere ai flussi video in lettura e non potrà comandare le telecamere

brandeggiabili collegate.

� Informazioni sullo stato delle telecamere (attiva/in avaria)


o I dati statici riguardanti tutti i componenti del sistema andranno acquisiti in

sede di configurazione e di eventuali modifiche alla configurazione degli

impianti o dei loro parametri di funzionamento



un periodo minimo 1 minuto.

o I dati meteo potranno essere acquisiti sia con la stessa frequenza dei dati di

traffico, sia con una frequenza minore (ad esempio 5 o 10 ‘); ciò in funzione

del tipo di trattamento che l’offerente intende fare di questi dati a fini

predittivi e di analisi.

o L’acquisizione dei flussi video avviene invece in modo asincrono su richiesta

dell’operatore. La frequenza di acquisizione dei frame dovrà poi essere tale

da garantire una adeguata qualità della presentazione delle immagini,

ovviamente compatibilmente con la banda messa a disposizione sulla rete e

con la frequenza di acquisizione della sorgente. .

o I dati provenienti da pannelli saranno acquisiti ad ogni cambio di stato degli

stessi.

o I messaggi SMS saranno acquisiti in modo asincrono in corrispondenza con

la loro generazione.

Pagina 36


o Il meccanismo di scambio dati per tutti i dati sincroni che si ipotizza è quello

del web service attivato su base temporale. Per i dati di tipo asincrono legati

ai PMV e agli SMS si può ipotizzare, oltre alla stesso meccanismo operato

secono una logica di polling, anche ad un invio dal server del sistema verso il

Supervisore nel momento di occorrenza dell’evento da notificare. Per i flussi

video si può ipotizzare la generazione di flussi video mediante comandi http

sulle connessioni di rete che saranno rese disponibili.


o Il Supervisore deve essere in grado di inviare ai singoli pannelli messaggi

specifici; l’operatore di centrale dovrà essere in grado di selezionare un

singolo pannello e di compilare un messaggio da inviare ad esso, associato ai

relativi parametri (tempo di permanenza del messaggio). Tale meccanismo

andrà gestito attraverso una procedura di autorizzazione che sarà definita

tra le parti.


o Lo scambio dati delle richieste asincrone sarà operato attraverso connessione. Il Supervisore dovrà inviare i comandi/richieste di visualizzazione secondo le modalità e i formati utilizzati dal sistema pannelli. Questo a sua volta dovrà riconoscere e accettare il comando dal sistema e inserirlo nella coda comandi gestendola con i meccanismi interni di gestione dei pannelli.

Pagina 37

3.2.10 Sistema di monitoraggio del traffico sulla S.G.C. FI-PI-LI – Provincia di

Firenze


o Sistema di rilevamento traffico, gestione pannelli a messaggio variabile e di

videosorveglianza del traffico sulla S.G.C. FI-PI-LI






o Project Automation S.p.A. - Milano


o In esercizio.



o Presso la direzione del IV tronco della Società Autostrade per l’Italia -

Firenze


o Il server attualmente non è collegato in rete. In prossimità del centro è

attestata la rete FiNet. Occorre verificare la possibilità di collegamento e la

disponibilità di accessi e indirizzi.


o Il sistema ha come obiettivo quello di rilevare, tramite dispositivi installati

sui portali in itinere, le condizioni del traffico lungo l’asse stradale FI-PI-LI e

la centralizzazione dei dati raccolti sul server in un centro di controllo. Le

funzioni implementate riguardano il monitoraggio dello stato di scorrimento

del traffico al fine di generare una serie di informazioni e segnalazioni verso

gli operatori del centro. Tramite queste informazioni è possibile, nel caso in

cui i dispositivi riscontrino anomalie nel flusso veicolare lungo l’asse viario,

informare l’utenza tramite i pannelli a messaggio variabile installati sia in

itinere che agli svincoli dell’asse di scorrimento. L’analisi e l’elaborazione dei

Pagina 38

dati di traffico, riguardanti volumi e classificazione per velocità e tipologia

dei veicoli transitanti, permette di conoscere in dettaglio lo stato di carico e i

trend del traffico . Su alcuni portali sono installate telecamere che vanno a

formare un sistema di videosorveglianza, che consente agli operatori di

avere una diretta percezione di quanto accade lungo le carreggiate poste

sotto osservazione, utilizzando le telecamere posizionate a coppie sui portali

in itinere. Il sistema permette di generare automaticamente segnalazioni di

allarme all’insorgere di code, traffico intenso o bloccato in modo che

l’operatore possa attivare le procedure più consone per la gestione delle

diverse situazioni, sia attivando la visualizzazione dei flussi delle telecamere

che inviando la messaggistica del caso sui pannelli in itinere scegliendo fra

una libreria di messaggi preconfezionati. L’architettura del sistema è

riportata nella figura che segue, estratta dal documento di progetto

esecutivo.

I pannelli sono installati sugli svincoli e in itinere mentre le telecamere e i

sensori di rilevazione del traffico sono installati in itinere.

In allegato 6 è riportato l’elenco delle postazioni periferiche del sistema.

Pagina 39


o Il Supervisore dovrà acquisire dal sistema almeno i seguenti dati statici (e

ovviamente tutte le loro eventuali modifiche dovessero occorrere):

� Configurazione e posizione degli apparati periferici

� Parametri di funzionamento degli stessi

o Il Supervisore dovrà acquisire dal sistema i seguenti dati dinamici in tempo

reale

� Dati di traffico volumetrici e classificati (per velocità e tipologia)

� Segnalazioni correnti sui pannelli

� Stati di traffico lungo le sezioni rilevati dal sistema

� Dati diagnostici degli apparati periferici

� Flussi video (in prima istanza quelli derivanti dalle telecamere

installate nel tratto di viabilità attorno a Firenze)

� Informazioni diagnostiche su postazioni misura traffico(attiva/in

avaria/ in funzionamento degradato), pannelli (attivo/in avaria) e

telecamere (attiva/in avaria)




o I dati dinamici verranno acquisiti in maniera asincrona per quanto riguarda

allarmi, diagnostiche e stati di funzionamento mentre con il rate in uso nel

sistema per i dati di traffico. Il rate attuale è di 1 minuto sia per i dati

volumetrici che classificati.

o I flussi video andranno attivati in modo asincrono su richiesta dell’operatore.



realizzato attraverso connessione al DataBase del sistema di acquisizione

della Fi-PI-LI. Sul server verrà messo a disposizione un account per l’accesso

in sola lettura del processo di acquisizione del Supervisore alle tabelle

contenente i dati di interesse. Il controllo dell’accesso è realizzato attraverso

Pagina 40

la procedura di login al Data Base. Il meccanismo oltre alla semplicità

permette la massima flessibilità sulla tipologia e l’orizzonte temporale dei

dati da acquisire, utile nel caso il Supervisore voglia riallineare i dati a

seguito di una interruzione del collegamento fra i due sistemi. Riguardo ai

flussi video è necessario un approfondimento per verificare la possibilità di

poter generare flussi video verso il Supervisore attraverso comandi http

verso il Front-end video del sistema di videosorveglianza della FI-PI-LI e la

banda disponibile sulla connessione attraverso la connessione attraverso il

collegamento con il server e sulla rete Finet.

o Le informazioni di viabilità generate da eventi significativi sull’asse viario

sono al momento accessibili in due modalità:

� trasmissione via sftp di file EDIFACT secondo lo standard DATEX 1

ed il database TMC. Secondo questa modalità gli eventi di traffico,

comprensivi degli aggiornamenti, vengono trasmessi verso il server

del destinatario;

� trasmissione mediante l’utilizzo di un servizio web, interrogabile via

http, basato su XML opportunamente formattato. Secondo questa

modalità il client può interrogare liberamente il servizio che ritorna gli

eventi presenti in una determinata area secondo il formato riportato

all’allegato 7.

o Per quanto riguarda i meccanismi di interfaccia con il sistema si vedano gli

allegati 7 e 8.

• Dati che il Supervisore deve poter inviare al sistema di monitoraggio del traffico FI-

PI-LI

o Il Supervisore deve poter richiedere al Supervisore di visualizzare sui

pannelli informazioni su richiesta degli operatori. Tali richieste verranno

inserite nella lista comandi e daranno luogo a visualizzazione se non sono

attive richieste a più alta priorità. La priorità dei messaggi provenienti dal

Supervisore sarà definita in sede di progetto esecutivo

o Il Supervisore deve poter inviare anche richieste per richiedere la

generazione/interruzione di flussi video di telecamere presenti.

o Invio messaggi al sistema per un loro successivo invio ai PMV (solo per

quelli posti nel territorio di competenza), previa autorizzazione

dell’operatore.

Pagina 41

• Meccanismo e protocollo di scambio dati in output dal Supervisore.

o Lo scambio dati delle richieste asincrone è fatto attraverso connessione. Il

Supervisore deve inviare i comandi/richieste di visualizzazione secondo le

modalità e i formati utilizzati dal sistema pannelli. Questo a sua volta deve

riconoscere e accettare il comando dal sistema e inserirlo nella coda comandi

gestendola con i meccanismi interni di gestione dei pannelli.

Negli allegati 7 e 8 sono fornite rispettivamente le specifiche del protocollo di scambio

dati fra il Supervisore e il gestore dei sensori e delle telecamere e fra il Supervisore e il

gestore dei Pannelli.

Pagina 42

3.2.11 Sistema di monitoraggio della flotta del trasporto pubblico (AVM) – ATAF


o AVM ATAF – Sistema di Localizzazione Flotta Bus


o ATAF SpA via dei Mille Firenze


o ATAF


o Elsag Datamat S.p.A. - Genova


o In via di realizzazione.



o Presso Deposito ATAF viale Pratese 105 Firenze-Peretola


o Il server attualmente non è collegato in rete. Tuttavia il sistema prevede un

server WEB su cui sono consultabili informazioni sullo stato del servizio


o Il sistema provvede alla localizzazione dei veicoli della flotta dei mezzi

durante il loro servizio di linea. Il sistema ricava giornalmente dal Sistema

Informativo Aziendale il programma di servizio dei mezzi, il programma di

servizio dei conducenti, i percorsi delle linee e ogni altra informazione utile a

monitorare operativamente il servizio. Le comunicazioni dati e fonia fra il

centro e i mezzi è realizzato attraverso rete GSM/GPRS. Attraverso lo

scambio dati continuo fra il server centrale, i mezzi e i depositi, il server

monitora lo stato di esercizio dei mezzi sulle linee e l’ingresso e l’uscita dal

turno di guida dei conducenti. Le informazioni acquisite sono riportate su

postazioni operatore presidiate durante l’arco orario di esercizio. Su queste

postazioni la GUI del sistema fornisce all’operatore la possibilità di avere

diverse rappresentazioni grafiche del servizio, più o meno sintetiche

Pagina 43

(tabellari, lineari e topografiche) in modo che ogni operatore, attraverso

messaggi, comandi e comunicazioni foniche con i conducenti, possa

intervenire sulle linee di propria competenza per recuperare lo stato di

regolarità o per far fronte ad emergenze. Il sistema inoltre provvede a dare

informazioni all’utenza su paline elettroniche alle fermate, ai passeggeri a

bordo dei veicoli, tramite portale WEB e tramite SMS : sulle paline a terra

l’utente, per ciascuna linea in transito, viene informato sulla previsione di

arrivo della prossima vettura mentre a bordo l’informazione riguarda la

prossima fermata di cui viene fornita la descrizione, in genere nome della via

su cui si sta transitando e nome della via trasversale, e le linee di

interscambio che su quella fermata insistono. Le informazioni a bordo sono

date su un display grafico. Il servizio WEB e SMS consente di fornire le stesse

informazioni di cui ai precedenti punti ma per tutta la rete. Il sistema è

predisposto per inviare richieste di preferenziamento verso un sistema

centralizzato UTC. Attivando questa funzionalità il sistema AVM esegue le

previsioni di arrivo agli attestamenti semaforici, per gli incroci in cui è attivo

il preferenziamento, e al transito su punti definiti o con un tempo di

preavviso definito, invia le richieste di preferenziamento. Altra importante

funzione svolta dal sistema AVM è quella di raccolta ed elaborazione dei dati

di esercizio. Sul server sono raccolti tutti i dati provenienti dal campo al fine

di generare l’archivio dei dati di percorrenza su archi e percorsi e

dell’andamento del servizio effettivamente reso. Questi dati sono utilizzabili

in sede di analisi e programmazione del servizio. Il sistema è provvisto odi

un server WEB che pubblica le informazioni di posizione e stato dei mezzi

sulle linee e le previsioni di arrivo alle fermate. Inoltre sugli archi principali

il sistema calcola il tempo di percorrenza assegnandogli uno stato

(regolare/rallentato…) rispetto al tempo di percorrenza programmato.


o Il Supervisore dovrà acquisire dal sistema AVL almeno i seguenti dati statici


� Descrizione geografica dei percorsi con la posizione delle fermate e

delle paline elettroniche di informazione all’utenza

� Descrizione degli orari di linea

o Il Supervisore dovrà acquisire dal sistema AVL i seguenti dati dinamici in

tempo reale

Pagina 44

� Posizione e stato delle vetture sui percorsi (codificato mediante codice

colori in funzione dello stato di regolarità della vettura rispetto al

servizio programmato). Questi dati saranno visualizzati solo presso la

sala di controllo del Supervisore e saranno accessibili solo agli

operatori abilitati.

� Tempi di percorrenza sugli archi (limitatamente a quelli che insistono

sulle arterie cittadine principali)

� Previsioni dei tempi di transito delle vetture su un set di fermate

principali (da concordare e comunque in numero non minore di 60)

� Informazioni diagnostiche sul sistema (da concordare)

• Frequenza di acquisizione

o I dati statici andranno acquisiti in sede di configurazione e in occasione di

modifiche sulle linee o sugli orari

o Per i dati dinamici il rate di acquisizione sarà dello stesso ordine di

grandezza del polling radio per quanto riguarda lo stato dei mezzi.

o I dati relativi ai tempi di transito e ai prossimi arrivi alle fermate saranno

richiesti dalla piattaforma di infomobilità in maniera asincrona in funzione

delle richieste degli utenti.



realizzato attraverso connessione http ai Web Services con cui il sistema

pubblica le informazioni riguardanti il servizio. Andranno concordate con

ATAF e Elsag Datamat in sede di progetto esecutivo le modalità più idonee

per acquisire i dati necessari in modo da avere informazioni aggiornate

senza sovraccaricare il sistema.

• Dati che il Supervisore deve poter inviare al sistema AVM

o N/a

• Meccanismo e protocollo di scambio dati in output dal Supervisore.

o N/a

Pagina 45

3.2.12 Sistema di videosorveglianza del traffico – Comune di Firenze


o Sistema di videosorveglianza cittadina “Telecamera Amica”


o Comune di Firenze


o Comune di Firenze – Direzione Servizi Tecnici


o Comune di Firenze – Direzione Servizi Tecnici (realizzato in-house

impiegando componenti di varie ditte)


o In esercizio ed in fase di cambiamento come più oltre specificato.



o Via Giotto – Firenze (sito comunale)


o Il sito è collegato alla rete comunale, ma il sistema è un collegamento non in

rete ma basato su un sistema punto punto

• Funzioni svolte e architettura del sistema

o Le telecamere rilevano le immagini dello stato del traffico e le invia in tempo

reale ad un sistema centrale dal quale i client degli operatori possono

derivare i flussi video per visualizzarli sui loro monitor di centrale operativa.

Il sistema è costituito da 107 telecamere, la gran parte delle quali

brandeggiabili, centralizzate presso il sito sopra citato. La maggior parte

delle telecamere è collegata tramite link in fibra ottica punto-punto con il

centro. 12 telecamere sono invece telecamere IP collegate con il centro

mediante un anello in fibra ottica gestito come una rete IP. Tutte le

telecamere si attestano al centro su una batteria di 7 videoregistratori digitali

tipo Cieffe Spectiva. I client degli operatori derivano i flussi video dai

videoregistratori stessi mediante protocollo TCP IP. Ogni videoregistratore è

Pagina 46

in grado di gestire fino a 16 client. Il formato delle immagini in uscita è

MPEG4/WAVELET. Attualmente ci sono 14 client collegati.

• Dati che devono essere acquisiti dal Supervisore e relativa codifica

o Il Supervisore dovrà poter visualizzare in apposite finestre i flussi video

provenienti da una qualunque delle telecamere collegate, semplicemente

mediante selezione da sinottico. A tal fine il Supervisore dovrà disporre della

localizzazione delle telecamere. Il Supervisore potrà accedere ai flussi video

in lettura e non potrà comandare le telecamere brandeggiabili.

o I flussi video sono codificati in MPEG4 /WAVELET

o Il Supervisore deve inoltre acquisire informazioni sullo stato delle

telecamere (attiva/in avaria)


o La attivazione dell’acquisizione dei flussi video sarà ovviamente asincrona,

su richiesta dell’operatore. La frequenza di acquisizione dei frame dovrà poi

ovviamente essere tale da garantire una adeguata qualità della presentazione

delle immagini .


o I flussi video, allo stato attuale sono disponibili sulle uscite analogiche in

BNC dei videoregistratori. Prossimamente, in quanto siamo in fase di cambio

sistema di gestione, saranno disponibili su flusso video in IP con apparati di

conversione “Verint”


o N/A


o N/A

Pagina 47

3.2.13 Sistema di monitoraggio della tramvia – Comune di Firenze


o SMARTRAMS-TRAINMONITOR – Sistema di Localizzazione Veicoli

Tramviari (AVL)


o Comune di Firenze


o GEST (Joint-venture ATAF RATP)


o Project Automation S.p.A. – Monza (MB)


o In fase di collaudo.



o Presso Centrale Gestione linea Tramviaria (Scandicci deposito Vingone/

Villa Costanza). Un client


o Il server attualmente non è collegato in rete. Presso il centro è attestata la rete

FiNet., Occorre verificare la disponibilità di accessi e indirizzi.


o Il sistema provvede alla localizzazione dei veicoli lungo il percorso della

linea tramviaria 1, da Scandicci a Santa Maria Novella e viceversa. Le

comunicazioni fra centro e bordo sono realizzate in continuo via radio, e in

corrispondenza di punti attrezzati lungo la linea. I veicoli hanno a bordo una

unità di gestione e localizzazione basata su GPS e odometro che interrogata a

polling fornisce al centro la posizione del mezzo con la precisione fornita da

questi strumenti. Inoltre in corrispondenza degli incroci semaforizzati, delle

fermate e di altri punti sono installate unità di acquisizione attrezzate con

sensori in grado di rilevare con altissima affidabilità il passaggio del tram

sulla sezione e di comunicare con il mezzo al fine di ricavarne i principali

dati di esercizio (corsa, identificativo veicolo, stato di anticipo/ritardo etc..). I

Pagina 48

dati raccolti al centro e localmente forniscono perciò una localizzazione

precisa e continua dei mezzi sul percorso. Il sistema prevede oltre al

monitoraggio del servizio tramite client di visualizzazione e gestione, anche

la gestione delle richieste di preferenziamento semaforico verso il sistema

UTC che regola le intersezioni semaforizzate attraversate. La localizzazione

realizzata con il polling radio e la verifica del passaggio localmente sulle

sezioni lungo il percorso permettono di effettuare le richieste di

preferenziamento al sistema di regolazione semaforica con la massima

affidabilità sui tempi di arrivo dei mezzi agli attestamenti semaforici e sui

tempi di liberazione degli incroci stessi. Poiché tutto il percorso della linea

tramviaria è coperto da una dorsale in fibra ottica che connette in rete gli

apparati periferici e quelli centrali (UTC e AVL), le richieste di

preferenziamento possono essere inviate sia localmente ai singoli regolatori

che al sistema centralizzato UTC.


o Il Supervisore dovrà acquisire dal sistema AVL almeno i seguenti dati statici


� Descrizione topografica dei percorsi della linea e posizione degli

apparati periferici (fermate, sezioni di rilevazione passaggi,

intersezioni etc..) che dovranno all’occorrenza essere georeferenziate.

o Il Supervisore dovrà acquisire dal sistema AVL/AVM i seguenti dati


� Posizione e stato di anticipo/ritardo delle vetture




o Per i dati dinamici il rate di acquisizione sarà dello stesso ordine di

grandezza del polling radio o di 1 minuto nel caso questo sia inferiore



realizzato attraverso appositi Web-Services, che accederanno all’AVL/AVM

SMARTRAMS-TRAINMONITOR.. Il meccanismo oltre alla semplicità

permette la massima flessibilità sulla tipologia e l’orizzonte temporale dei

Pagina 49

dati da acquisire, utile nel caso il Supervisore voglia riallineare i dati a

seguito di una interruzione del collegamento fra i due sistemi

Pagina 50

3.2.14 Sistema di centralizzazione semaforica degli impianti insistenti sul

percorso della tramvia – Comune di Firenze


o SMARTTRAMS/TRAINWAY – Sistema di centralizzazione semaforica

(UTC)


o Comune di Firenze


o GEST (Joint-venture ATAF RATP)


o Project Automation S.p.A. – Monza (MB)


o In fase di collaudo.



o Presso Centrale Gestione linea Tramviaria (deposito Scandicci – Vingone/

Villa Costanza). Un client sarà installato anche presso gli uffici preposti del

Comune di Firenze


o Il server attualmente non è collegato in rete. Presso il centro è attestata la rete

FiNet., Occorre verificare la disponibilità di accessi e indirizzi.


o Il sistema provvede alla regolazione di 35 Impianti semaforici dislocati lungo

il percorso della linea tramviaria 1, da Scandicci a Santa Maria Novella. Il

sistema centralizzato gestisce la regolazione semaforica garantendo la

priorità semaforica ai veicoli tramviari. A tale scopo lungo la linea sono

installati una serie di sensori in grado di rilevare con altissima affidabilità il

transito dei veicoli tramviari e trasmettere l’informazione al centro e ai

regolatori semaforici interessati dal loro transito. Inoltre il server centrale in

cui sono implementate le logiche di regolazione è connesso con la centrale di

gestione del servizio tramviario che, attraverso un polling radio, conosce

Pagina 51

posizione e stato di esercizio di tutte le vetture in esercizio rendendo

accessibili questi dati, ove necessario, al gestore UTC. La priorità è

implementata su piani precalcolati. Non essendo a tutt’oggi l’impianto

dotato di rilevatori di traffico automobilistico sulle vie trasversali la linea

tramviaria la politica di regolazione di base è a fasce orarie, anche se il

sistema è in grado di implementare regolazioni attuate dal traffico. Tutte le

comunicazioni sono realizzate sulla rete appoggiata sulla dorsale a fibra

ottica stesa per tutto il percorso della Tramvia.


o Il Supervisore dovrà acquisire dal sistema UTC almeno i seguenti dati statici


� Localizzazione e composizione degli impianti semaforici e

caratteristiche dei relativi regolatori

� Insieme dei piani semaforici associati ai vari impianti

o Il Supervisore dovrà acquisire dal sistema UTC i seguenti dati dinamici in

tempo reale

� Piano semaforico attualmente vigente per ogni impianto

� Il Supervisore dovrà essere predisposto anche per acquisire dal

sistema UTC i dati statici e dinamici di sensori di traffico



modifiche alla configurazione degli impianti, dei piani semaforici di incrocio

o di gruppo di coordinamento.



un periodo di 1 minuto. I piani semaforici associati agli impianti possono

essere comunicati in modo sincrono in corrispondenza dell’acquisizione dei

dati di traffico o in maniera asincrona in occorrenza dell’evento di variazione

del piano attivo.



realizzato attraverso connessione al DataBase dell’UTC che metterà a

disposizione un account per l’accesso in sola lettura del processo di

Pagina 52

acquisizione del Supervisore alle tabelle contenente i dati di interesse. Il

controllo dell’accesso è realizzato attraverso la procedura di login al Data

Base. Il meccanismo oltre alla semplicità permette la massima flessibilità

sulla tipologia e l’orizzonte temporale dei dati da acquisire.


o Il Supervisore deve essere in grado di inviare al sistema UTC i set point di

piano per i vari impianti semaforici. L’informazione consiste nella codifica

dell’impianto cui si fa riferimento e del piano che deve essere associato a

quell’impianto.

o Il Supervisore deve anche poter inviare al sistema UTC richieste di

regolazione. Tali richieste dovranno far riferimento ad entità di pertinenza

dell’UTC, quali piani semaforici di incrocio o di gruppi di coordinamento;

tali piani devono essere notificati precedentemente al Supervisore,

tipicamente dopo ogni azione di creazione, modifica o cancellazione degli

stessi all’interno del sistema UTC.


o La messaggistica per la gestione delle richieste/comandi di regolazione

effettuate dal Supervisore verranno inviate attraverso una connessione TCP

specifica.

Pagina 53

3.2.15 Modulo aggregatore di dati FCD

La descrizione di questo modulo non segue lo standard adottato per gli altri sistemi, data l’originalità del modulo. Si dà quindi una descrizione del funzionamento del modulo rimandando per quanto riguarda le modalità di interfaccia all’apposito allegato 10 del presente documento. Come detto il Supervisore dovrà essere in grado di trattare dati di traffico provenienti da flotte FCD. Per omogeneizzare i dati che potenzialmente possono provenire da apparecchiature di bordo disomogenee e per poter riferire i dati al grafo cui fa riferimento il Supervisore, il partner di progetto Comune di Torino, attraverso l’Azienda 5T, sta sviluppando un pacchetto software che funge da “modulo aggregatore”. Si tratta di un software che ciclicamente, attraverso concentratori che assicurano l’interfaccia con il campo, acquisisce i dati provenienti dalle singole unità di bordo, li aggrega estraendone dati medi relativi al periodo di campionamento ed indici e li assegna univocamente sul grafo, fornendo così dati compatibili con la rappresentazione usata dal Supervisore. Il modulo aggregatore può fornire anche i dati sorgenti di posizione provenienti dalle unità di bordo, localizzate sulla cartografia. Il “modulo aggregatore” è quindi a tutti gli effetti un sistema fornitore di dati con cui il Supervisore si deve interfacciare; la fornitura deve quindi comprendere tutto il software necessario ad interfacciare il modulo aggregatore secondo le specifiche riportate all’allegato 10. 5T installerà il software del modulo aggregatore su una macchina collegata in LAN ai server del Supervisore (o comunque alle macchine previste dalla architettura progettata dall’aggiudicatario) e provvederà anche al collegamento del modulo con il front-end processor che gestirà il protocollo di raccolta dati da campo. E’ quindi in carico all’offerente solo la realizzazione del protocollo di interfaccia con il modulo aggregatore stesso.

Pagina 54

4 Il grafo e la rappresentazione cartografica della rete Il Supervisore opererà su una rappresentazione della rete mediante grafo. Dovrà inoltre essere in grado di rappresentare tutte le entità e le grandezze necessarie al suo funzionamento anche su una base cartografica. Nel caso specifico il grafo in oggetto sarà quello della Regione Toscana che sarà messo a disposizione del fornitore su supporto informatico. La Regione Toscana, infatti, ha commissionato il lavoro di costruzione del grafo regionale, che è tuttora in corso e che sarà completato entro la fine del 2009, all’interno del progetto di realizzazione delle banche dati per l’infomobilità, di cui si acclude all’allegato 9 una descrizione generale tratta dalla documentazione di gara. Per la precisione il grafo fornito sarà un sottoinsieme del grafo completo, e rappresenterà quantomeno la viabilità extraurbana della Provincia di Firenze, incluse le Autostrade, e la viabilità urbana del Comune di Firenze. Il grafo che dovrà essere utilizzato è composto da archi e nodi georeferenziati. I nodi e gli archi del grafo possono essere descritti anche topologicamente; nel grafo, quindi alla sede stradale sono associati diversi elementi quali il toponimo, la tipologia (parcheggio, incrocio, pedonale, ecc.), la classificazione funzionale, l’ente proprietario, il numero di carreggiate, la relazione spaziale con altre tratte (ad es. se è sottopasso di altre), la classe di larghezza, ed ai nodi sono associate informazioni relative al tipo di intersezione. La documentazione di dettaglio che descrive la rappresentazione del grafo è riportata in allegato 9; tale documentazione è un estratto della documentazione della gara che la Regione Toscana ha esperito, e contiene per l'appunto le caratteristiche tecniche del pacchetto dati di rappresentazione del grafo e dei dati ad esso associati. Ad un sottoinsieme di archi del grafo sarà anche associata la codifica TMC (indicativamente si pensa di avere tra i 400 ed i 500 punti codificati nella rete). Infatti il lavoro di codifica TMC di una serie di archi della rete stradale della Provincia di Firenze, inclusi gli ambiti urbani, sarà terminato entro la fine del 2009. Tale codice sarà reso accessibile nella descrizione del grafo alle varie applicazioni che se ne potranno servire per il dispatching delle informazioni a dispositivi mobili quali i navigatori. Il Supervisore dovrà essere in grado di importare le tabelle di interesse che definiscono il grafo ed i dati ad esso associati, mediante importazione dal Data Base cartografico Regionale, la cui struttura è riportata in allegato 9. Al grafo dovrà essere sovrapponibile una rappresentazione cartografica della rete. Nel caso specifico si tratta della Carta Tecnica Regionale (CTR), che rappresenta tutta la viabilità inclusa nel grafo di riferimento. La scala della CTR è nativamente 1:2.000 per i centri abitati e 1:10.000 per gli ambiti extraurbani. La CTR è georiferita secondo il sistema WGS84, che garantisce una maggiore coerenza tra il sistema di rappresentazione ed i dati acquisiti mediante tecniche di localizzazione satellitare. La CTR possiede una pluralità di layer, tra cui saranno resi disponibili quelli strettamente necessari a descrivere la viabilità (onde non appesantire la rappresentazione del Supervisore). In particolare saranno resi disponibili i layer riportanti:

• Isolati;

Pagina 55

• Centro strade;

• Altri layer che identificano punti salienti.

La CTR sarà resa disponibile dalla Provincia di Firenze su supporto informatico in formato dwg (o altro formato corrente da concordare) e dovrà essere automaticamente importata dal Supervisore. L’offerente dovrà chiarire se le rappresentazioni ipotizzate sono compatibili con la struttura del Supervisore offerto, se sono automaticamente importabili, con quali procedure e modalità. Dovrà inoltre indicare chiaramente tutti gli eventuali elementi aggiuntivi che debbano essere forniti dalla Provincia e/o dal Comune di Firenze. Il Supervisore dovrà permettere di operare modifiche sul grafo mediante operazioni quali:

• aggiunta/sottrazione di un arco e di un nodo;

• divisione di un arco in due mediante l’aggiunta di un nodo;

• Modifica dei parametri di descrizione di un arco e/o di un nodo.

A tal fine dovrà disporre di un editor di rete utilizzabile da operatore per apportare piccole modifiche, di cui l’offerente dovrà descrivere caratteristiche e modalità di funzionamento. Inoltre il Supervisore dovrà contemplare una funzionalità operativa di importazione del grafo e della cartografia, accessibile da parte di un operatore opportunamente abilitato utilizzabile per la sostituzione della rete di riferimento. Ciò permetterà di modificare durante l’esercizio il grafo e/o la cartografia ad esso associata. L’offerente dovrà descrivere il funzionamento di questa funzionalità, che dovrà operare correttamente con la rappresentazione del grafo fornita dalla Provincia di Firenze. Qualora questa funzionalità richieda il rispetto di eventuali vincoli, l’offerente dovrà chiaramente indicarli, esplicitando anche le eventuali operazioni che dovranno essere compiute per rendere la rappresentazione compatibile con l’importazione automatica da parte del Supervisore. Per tutti quegli archi/nodi condivisi tra vecchio e nuovo grafo, il Supervisore dovrà garantire la permanenza di tutti i dati di configurazione e dei dati dinamici storici ad essi associati nel passaggio tra la vecchia e la nuova configurazione. Inoltre il Supervisore dovrà gestire la storicizzazione delle vecchie configurazioni di rete e dei dati loro associati, e la gestione dei relativi archivi. Il sistema offerto dovrà comunque essere in grado di operare con le stesse modalità sopra descritte anche qualora il Committente decida di scegliere la base cartografica TELEATLAS. Tale decisione sarà comunque comunicata alla Ditta aggiudicataria prima della fase di progettazione esecutiva del sistema.

Pagina 56

5 Funzionalità del Supervisore Il sistema complessivamente ha la struttura illustrata nella figura che segue.

UTC

Server Farm

Servers

Storage

FiNet

Sala CentraleSupervisore

FI-PI-LI

ZTL

ZTL

DatiAmbientali

Gestione Video

Server

Sistemi collegatiServer

Sistemi collegati

Parcheggi

Sistema ……

Sistema ……

Sistema ……Sistema ……

WEB

Il Supervisore del traffico è un package software residente sull’architettura della piattaforma che ha le seguenti principali funzioni:

1. Configuratore

Benché la configurazione iniziale del Supervisore sia un compito che sarà affidato al fornitore, il Supervisore dovrà tuttavia essere configurabile sia in termini di sistemi ed apparati periferici collegati sia in termini di parametri di funzionamento. Dovrà quindi essere dotato di un editor (o comunque di un meccanismo che permetta di gestire questa fase di configurazione), che permetta sia di importare dati da files o acquisirli dai sistemi stessi sia di definirli mediante input manuale. La fase di configurazione interessa un gran numero di variabili, entità e parametri; fermo restando che l’offerente dovrà garantire la piena efficacia del modulo di

Pagina 57

configurazione, che dovrà gestire tutte le grandezze necessarie al corretto funzionamento del Supervisore, di seguito si citano i principali aspetti che il configuratore dovrà poter gestire.

• Import della rete sotto forma di grafo, secondo la rappresentazione più oltre descritta;

• Import della base cartografica, eventualmente organizzata su layer diversi;

• Import delle caratteristiche dei vari sottosistemi di acquisizione dati o comunque collegati al Supervisore, in termini di localizzazione dei dispositivi di campo e di loro caratteristiche tecnologiche, di formato dei dati scambiati, ecc. Questa caratteristica è ritenuta importante per poter permettere una agevole riconfigurabilità in caso di modifica del sistema di sensori e apparati collegati con il sistema;

• Definizione dei parametri di funzionamento del Supervisore in termini di tempi di campionamento e degli altri parametri temporali I parametri temporali su cui opera il Supervisore dovranno essere programmabili, sia in termini di acquisizione dei dati, sia di refresh della valutazione dello stato e delle altre principali operazioni. Per quanto riguarda l’interfaccia verso i sistemi di acquisizione dati, vista la loro molteplicità e difformità, il Supervisore dovrà essere in grado di associare ad ogni sistema interfacciato una frequenza di acquisizione dei dati, nonché di settare in fase di configurazione una frequenza di default. Lo stesso dicasi per gli altri parametri temporali di funzionamento del Supervisore;

• Definizione e composizione dei quadri sinottici desiderati e dei reports. Tutta la fase di configurazione dovrebbe auspicabilmente avvenire tramite un’interfaccia guidata che permetta all’operatore una agevole comprensione delle fasi e delle operazioni da svolgere. Il configuratore, nella sua accezione più generale, dovrebbe quindi essere uno strato software in grado di descrivere in modo logico tutte le interfacce con gli obiettivi di:

• limitare, in caso di cambiamenti nella configurazione degli apparati periferici sia di input che di output le modifiche a specifici moduli di interfaccia con gli stessi che implementino protocolli di scambio dati;

• non richiedere alcuna modifica del software del Supervisore e della piattaforma di infomobilità;

• agevolare l’operatore nelle fasi di modifica.

5.1 Acquisizione di dati da vari sistemi di gestione o regolazione del traffico e della mobilità.

Il Supervisore dovrà fungere da concentratore di tutte le fonti di dati riguardanti il traffico e la mobilità, per permettere di avere un quadro esaustivo ed aggiornato dello stato del traffico e della sua evoluzione. Esso dovrà quindi interfacciare tutti i singoli sistemi per acquisire dati e in alcuni casi per inviare informazioni o comandi; tale acquisizione, a seconda della natura dei vari sistemi, potrà avvenire in tempo reale o in tempo differito.

Pagina 58

Il Supervisore, quindi, dovrà essere anche in grado di gestire dati di tipo differente non solo per quanto riguarda accuratezza, frequenza di acquisizione, formati sorgenti, ma anche per quanto attiene alla tipologia stessa dei dati. In particolare per quanto riguarda i dati di traffico il sistema deve essere in grado di acquisire anche dati classificati. Infatti, oltre ai dati di traffico sulle principali arterie della Provincia e del Comune di Firenze provenienti da una molteplicità di fonti complementari, il Supervisore dovrà acquisire dati di tipo ambientale, occupazione dei parcheggi, e altre informazioni riferibili non solo alla viabilità, ma anche ad aree o a punti di interesse. Nel caso specifico e allo stato attuale le fonti di acquisizione dati da prevedere sono quelle che sono state descritte al capitolo 3 del presente documento. Il Supervisore dovrà essere quindi in grado di interfacciare ognuno di questi sistemi acquisendo in tempo reale o differito dagli stessi dati relativi allo stato del traffico. La presente specifica, al capitolo 3, riporta anche per ognuno dei sistemi da considerare:

• una breve descrizione,

• la definizione dei dati che devono essere acquisiti,

• il formato degli stessi,

• i protocolli logici di scambio dati utilizzabili,

• la connessione fisica utilizzabile ed i relativi protocolli, cui si rimanda per la definizione di dettaglio delle necessità di interfacciamento. Il modulo di acquisizione dati dovrà possedere le seguenti funzionalità:

• le frequenze di acquisizione dei dati dovranno, oltre che poter essere definite in fase di configurazione come sopra descritto, poter essere impostate per ognuno dei sistemi interfacciati in fase di esercizio e dovrà in automatico essere gestita la sincronizzazione con il sistema da cui sono acquisiti i dati stessi.

Ovviamente tutti i dati acquisiti dovranno essere associati ad un arco o ad un oggetto del grafo stradale in esame, come più oltre specificato. Data la caratteristica di mutabilità dei sistemi di raccolta dati o di gestione del traffico presenti sul territorio, il modulo di acquisizione dati del Supervisore dovrà necessariamente possedere caratteristiche di configurabilità tali da supportare facilmente il collegamento di nuovi sistemi di vario genere, o la loro eliminazione, o la modifica della loro configurazione (apparati collegati, ecc.), mediante operazioni di configurazione e scrittura di eventuali apposite interfacce. Al fine di minimizzare il lavoro di scrittura di questi moduli di interfaccia, ovviamente dipendenti dal tipo di sistema che dovrà essere interfacciato, è importante che il Supervisore possieda una rappresentazione standard di acquisizione delle varie classi di dati (ad esempio un formato per i dati di velocità, per quelli di flusso, classificato e no, per la disponibilità di parcheggi, e così via). Nel caso di sistemi di nuova realizzazione tale formato potrà essere richiesto come formato di output dei dati verso il Supervisore. Nel caso di sistemi già esistenti, un apposito modulo software convertirà il formato sorgente in quello standard utilizzato dal Supervisore.

Pagina 59

5.2 Acquisizione dati da flotte FCD.

Uno dei principali obiettivi del progetto S.I.Mo.Ne è l’integrazione nella struttura del Supervisore di traffico della capacità di acquisire dati da flotte di veicoli viaggianti equipaggiati con unità di bordo dotate di sistema di localizzazione e della capacità di trasmettere dati in tempo reale. Si vuole in questo modo cogliere l’opportunità di impiegare i dati provenienti dal gran numero di veicoli già così equipaggiati e attualmente circolanti. Si tratta in gran parte di veicoli equipaggiati da Aziende private a fini assicurativi, di sicurezza o per altri servizi. Alcune di queste aziende, inoltre, offrono già servizi di valutazione dello stato di traffico basate sui dati provenienti dalla flotta di veicoli equipaggiati da queste aziende. Nell’ambito del progetto S.I.Mo.Ne e dei suoi successivi sviluppi la Provincia intende portare avanti lo sfruttamento delle tecnologie FCD per la ricostruzione dello stato delle reti stradali sul proprio territorio. La Provincia, infatti, ha già realizzato un servizio accessibile via web che sulla base dei dati raccolti da veicoli in movimento opportunamente equipaggiati ricostruisce lo stato del traffico sulle principali strade provinciali ne produce una rappresentazione grafica. L’obiettivo del progetto S.I.Mo.Ne è quello di integrare questi dati nel Supervisore in modo standardizzato. Ciò darà la possibilità di acquisire dati FCD da provider diversi, e quindi da veicoli equipaggiati da Aziende differenti, con differenti sistemi di centralizzazione e rappresentazione dei dati. Ciò darà anche la possibilità di allargare l’utilizzo di queste tecniche anche a veicoli di flotte pubbliche o similari (flotte di Enti Pubblici o aziende pubbliche, flotte car sharing, ecc.) Il Supervisore, una volta acquisiti questi dati, dovrà essere in grado di utilizzarli alla stessa stregua di quelli acquisiti dalle altre fonti, ai fini elaborativi. Inoltre il Supervisore dovrà essere in grado di restituire ai provider di informazioni FCD, ancora attraverso il modulo “aggregatore” informazioni elaborate dal quali i tempi di percorrenza stimati dal Supervisore stesso, informazioni relative allo stato del traffico, alla ZTL ecc., per essere inviate agli stessi dispositivi di bordo che forniscono dati. Il Supervisore dovrà essere in grado di scambiare tali dati solo con il modulo aggregatore, che provvederà autonomamente a gestire le comunicazioni con il centro servizi dei provider che a sua volta gestirà le comunicazioni con il campo. Questo modulo sarà di fatto una specializzazione del modulo di acquisizione/invio dati, che si interfaccerà a sua volta con un “modulo aggregatore” che sarà realizzato nell’ambito del progetto SIMONE e che il fornitore dovrà considerare quindi disponibile, e da cui potrà acquisire/inviare i dati secondo le metodologie e gli standard che vengono riportati in allegato 10 a questo documento. Per il Supervisore il modulo aggregatore fungerà quindi nel caso specifico da sistema periferico da cui acquisire e a cui inviare i dati. Esso di fatto garantirà al Supervisore la possibilità di :

• Acquisire dati FCD indipendentemente dalla fonte da cui provengono e dai protocolli di rappresentazione dei dati e di trasmissione degli stessi utilizzati

Pagina 60

dai vari provider (si potranno quindi acquisire dati provenienti da dispositivi di bordo differenti che trasmettono con protocolli differenti);

• Acquisire i dati riferiti al grafo utilizzato dal Supervisore;

• Acquisire i dati con un protocollo standard;

• Avere un indicatore di qualità associato ai dati; esso è di fondamentale importanza nel caso di dati FCD, per i quali la numerosità del campione sugli archi è tempo-variante e determina in modo sostanziale la significatività dei dati;

• Inviare ai centri di servizio dei provider di dati FCD, attraverso l’aggregatore, informazioni che potranno poi essere ulteriormente diffusi agli stessi dispositivi di bordo collegati.

Il modulo aggregatore, in termini generali, potrà fornire al Supervisore due tipologie di dati:

• La velocità media sui vari archi del grafo con un indicatore associato che dà conto dell’accuratezza della misura in funzione della numerosità dei dati da cui è stata ricavata la stima di velocità media;

• L’insieme dei dati di posizione (x,y) georiferita di tutti i veicoli transitati nell’arco di tempo di campionamento sui vari archi (cioè i dati grezzi di posizione senza elaborazione).

Nel caso specifico del Supervisore in oggetto, si richiede che esso sia in grado di funzionare nella prima delle due modalità, acquisendo cioè ad ogni periodo di campionamento la velocità media ed i relativi parametri. Si richiede però che il Supervisore sia predisposto in termini di data base e di primitive software a poter gestire anche la memorizzazione di ampie moli di dati grezzi e renderli disponibili a successive elaborazioni che dovranno poter essere inserite mediante moduli aggiuntivi. Al momento non si richiede che il sistema sia dimensionato in termini di capacità di memorizzazione e di capacità elaborativa per poter gestire tali dati; si procederà pertanto ad un eventuale upgrade dell’hardware di sistema qualora si intenda perseguire questa via, ferma restando la possibilità di impiegare lo stesso software. Anche in questo caso, come per il modulo precedente, questo modulo dovrà poter definire i tempi di campionamento in modo coordinato con il modulo aggregatore, in fase di configurazione e in fase di esercizio. In allegato 10 sono riportate le specifiche del protocollo di interfaccia con il modulo di gestione dei dati FCD.

5.3 Modulo di data entry dati di traffico

Poiché la base dati (o per meglio dire il data repository del sistema) dovrà poter raccogliere e sistematizzare tutti i dati relativi allo stato del traffico, indipendentemente dalla sorgente da cui provengano, il Supervisore dovrà poter catalogare anche dati provenienti da campagne di misura e rilevamenti fatti con sistemi di misura non centralizzati od addirittura manualmente. A tal fine il Supervisore dovrà disporre di un modulo di data entry per dati di traffico. L’input dati avverrà di norma attraverso file transfer, previa definizione di un formato di input.

Pagina 61

Il sistema dovrà comunque permettere l’input dati anche manuale di singoli valori associati ad archi definiti.

5.4 Filtraggio dati e normalizzazione

I dati di traffico acquisiti potranno avere qualità differente in funzione delle diverse sorgenti. Per poter svolgere efficacemente le funzionalità richieste al Supervisore, i dati devono avere un buon livello di affidabilità e caratteristiche di omogeneità nei singoli punti di misura o in punti tra loro correlati. E’ quindi considerato elemento di merito la capacità del Supervisore di filtrare i dati acquisiti scartando dati inconsistenti, errati o inaffidabili, e di normalizzarli. Ai fini della ricostruzione degli stati di traffico (vedi paragrafo più innanzi), questa funzionalità deve essere svolta in linea, in tempo reale, con frequenza compatibile con i tempi di campionamento scelti.

5.5 Memorizzazione e archiviazione dei dati e relativa gestione

I dati acquisiti ed elaborati nei modi sopra descritti andranno adeguatamente memorizzati in una base dati (o struttura dati simile) che faccia riferimento al grafo stradale per tutti i dati riferiti ad archi e alla cartografia per il resto dei dati rappresentabili mediante aree ecc. Tutti i dati fanno quindi riferimento ad una struttura di tipo geografico. La base dati del sistema dovrà quindi essere interrogabile a partire da queste istanze di tipo geografico (archi e nodi del grafo o entità di tipo cartografico), cui sarà possibile associare informazioni statiche e dinamiche. La base dati dovrà contenere tutte le informazioni statiche e dinamiche necessarie alla configurazione e all’esercizio del sistema stesso. A titolo esemplificativo, per quanto riguarda la configurazione del Supervisore, dovrà contenere ovviamente almeno le seguenti classi di informazioni statiche:

• Descrizione del grafo della rete e relativi attributi;

• Descrizione dei sistemi di acquisizione dati collegati e dei relativi attributi e parametri

o Per ognuno dei sistemi definiti lista dei dispositivi di misura collegati e relativi attributi e parametri.

e in generale tutte le informazioni necessarie in relazione alla soluzione funzionale proposta dall’offerente. Durante il funzionamento in linea, nella base dati andranno progressivamente registrati i valori dei parametri via via acquisiti, correlati allo strumento di acquisizione e all’istanza geografica cui si riferiscono (tipicamente un arco del grafo stradale). A questi dati dinamici andranno anche associate le informazioni temporali necessarie a caratterizzarli (tempo di acquisizione, intervallo, ecc.). E’ importante ricordare che, per quanto riguarda i dati di traffico, devono poter essere trattati e memorizzati anche dati classificati su un differente numero di classi.

Pagina 62

I dati statici e dinamici che potranno essere acquisiti nell’attuale configurazione dei sistemi periferici della Provincia e del Comune di Firenze sono riportati nella descrizione dei singoli sistemi collegati. A queste classi di dati si aggiungono quelli che vengono calcolati attraverso funzioni di tipo statistico ed elaborativo (specificate in un apposita sezione di questo documento) o derivati dall’analisi in tempo reale dei dati di traffico (indici derivanti da incrocio di dati dinamici e statici, correlazioni, ecc.). Anche questi dati devono continuare a contenere i riferimenti alle entità relative geografiche. Come sopra citato la base dati deve poter accogliere anche dati provenienti da file o da input manuali, registrandone la provenienza. Questi dati non possono ovviamente essere impiegati nel funzionamento in tempo reale del sistema, ma devono poter essere integrati nelle serie storiche di dati ed essere gestiti in maniera integrata con quelli acquisiti in automatico. La base dati che si andrà così formando costituirà quindi il data repository di tutti i dati e le informazioni sul traffico provenienti da sorgenti diverse ed integrate tra di loro, riferite ad un grafo stradale unico ed ad una base cartografica. Proprio queste entità geografiche saranno l’elemento prioritario di accesso all’informazione. Proprio in questa ottica i dati devono essere gestiti in modo da assicurare l’integrità e la coerenza degli stessi, nonché le corrette relazioni tra dati ed entità cui sono correlate. In particolare i dati andranno progressivamente storicizzati e dovrà essere garantito l’accesso a questi dati mediante differenti chiavi. Inoltre dovrà essere garantita la storicizzazione dei dati in funzione di eventuali modifiche della rete o dei sistemi collegati, assicurando meccanismi di elaborazione e confronto di dati coerenti in relazione alla configurazione di rete. Ciò implica che il Supervisore dovrà mantenere la serie storica delle versioni di rete e di configurazione dei sistemi di acquisizione dati, in relazione ai dati dinamici acquisiti in quelle configurazioni. Per quanto riguarda le serie storiche di dati dinamici, esse dovranno essere recuperabili sia in relazione ad una data configurazione di rete, sia semplicemente in relazione alla sola variabile temporale (potendo quindi essere relative a differenti configurazioni di rete). Lo stesso dicasi per i dati statici riguardanti i sistemi di acquisizione dati ed i relativi dispositivi. Per l’implementazione di questa funzione di memorizzazione e gestione dei dati, l’offerente potrà impiegare tools e packages di sua scelta, siano essi DBMS integrati o meno in GIS. Saranno comunque privilegiate soluzioni non proprietarie ma di mercato e che adottino standard affermati per quanto riguarda la memorizzazione e l’interrogazione dei dati. In particolare le soluzioni proposte dovranno:

• permettere l’interrogazione diretta della base dati con query dirette SQL;

• permettere una chiara leggibilità della struttura delle tabelle e delle loro relazioni;

• permettere una facile modifica della struttura con l’aggiunta di nuove entità e la creazione automatica delle tabelle correlate;

• permettere una ampia espandibilità della mole e della sorgente dei dati;

Pagina 63

• garantire in automatico l’adeguamento della struttura dati in funzione di modifiche della rete o dell’insieme dei sistemi di acquisizione dati collegati.

Come citato nel paragrafo riguardante l’acquisizione dati da FCD, la base dati dovrà essere predisposta per accettare i dati di posizione provenienti da floating cars, georiferiti e associati all’arco di pertinenza. Tale funzione di acquisizione e memorizzazione non sarà però attivata nell’ambito della presente fornitura. Il Supervisore dovrà essere in grado di gestire la memorizzazione in questo repository di altri dati di mobilità non direttamente riguardanti il traffico, ma ad esso collegati, quali:

o Matrici OD; o Linee di desiderio; o Aree ZTL; o Linee del trasporto pubblico.

La base dati, infine, deve poter memorizzare e gestire “scenari”, cioè definite configurazioni dello stato della rete generate in automatico o da operatore, in linea o fuori linea. Tali scenari devono poter essere associati a una serie di “azioni”, cioè a comandi da inviare a sistemi collegati e/o informazioni da passare alla piattaforma di infomobilità.

5.6 Ricostruzione dello stato del traffico ed identificazione di situazioni di criticità

Sulla base dei dati acquisiti in tempo reale dai sensori di traffico disponibili, e quindi di informazioni disomogenee, il Supervisore dovrà essere in grado di ricostruire in tempo reale lo stato del traffico sugli archi stradali, con un buon grado di affidabilità. Con ricostruzione dello stato del traffico si intende la valutazione dei volumi di traffico insistenti sugli archi e delle relative velocità; inoltre, correlando questi dati con elementi strutturali della rete, quali le capacità degli archi, inferire indicatori significativi in grado di segnalare l’avvicinarsi di situazioni di criticità. Infatti una caratteristica importante del Supervisore dovrà essere la capacità di identificare tempestivamente queste situazioni di criticità e segnalarle all’operatore. In questo senso le capacità predittive del Supervisore rappresentano un elemento non imprescindibile ma qualificante dell’offerta. Il Supervisore, quindi, sulla base delle informazioni raccolte in tempo reale e della conoscenza del comportamento dinamico della rete e con l’applicazione di varie possibili tecniche, dovrà essere in grado di fare previsioni attendibili sull’evoluzione dello stato del traffico, soprattutto ai fini della “early detection” di situazioni di criticità.

5.7 Analisi statistica, elaborazione dei dati e reporting

Il Supervisore dovrà essere dotato di strumenti di analisi dei dati utilizzabili facilmente dagli operatori per svolgere operazioni quali:

o Analisi storica di dati sullo stesso arco; o Correlazione tra sezioni diverse; o Analisi statistica di serie;

Pagina 64

o Elaborazione di dati “giorno tipo”; o Filtraggio off line dei dati per migliorarne la qualità, integrare dati mancanti

da serie storiche, ecc.; o Ricostruzione di pattern di traffico su porzioni limitate della rete a partire da

dati parziali; o ecc.

Lo strumento utilizzato dovrà ovviamente garantire la visualizzazione grafica dei risultati delle elaborazioni mediante vari tipi di grafici. Il sistema dovrà garantire la disponibilità di un set di elaborazioni predefinite caratterizzabili dall’operatore mediante definizione parametrica delle serie di dati interessati (sezioni, intervalli temporali, ecc.) tramite semplice interfaccia che non richieda conoscenze informatiche specialistiche. Questo set dovrà coprire le funzioni statistiche più utilizzate nell’ingegneria del traffico. Sarà considerato elemento di merito la disponibilità di tools che permettano anche l’esecuzione di una qualunque funzione statistica o di analisi dei dati tramite linguaggi specializzati o simili interfacce. Il sistema dovrà essere in grado di produrre reporting sull’andamento nel tempo delle variabili di traffico, in forma tabellare e grafica, dando all’operatore la possibilità di selezionare le grandezze e gli intervalli temporali.

5.8 Rappresentazione grafica e interfaccia utente (MMI)

Tutti i dati provenienti dai sistemi collegati al Supervisore, le relative elaborazioni e le ricostruzioni dello stato di traffico, dovranno essere rappresentate su una base cartografica e sul relativo grafo stradale. Tutta la rappresentazione dovrà:

o essere georeferenziata; o utilizzare di strumenti software per la produzione di rappresentazioni

grafiche di ampia diffusione di mercato; o essere univoca; o essere compatibile con gli standard GIS degli Enti interessati, che saranno

dettagliati nel seguito di questo documento. Il Supervisore è destinato ad essere lo strumento primario di interfaccia per i gestori del traffico. Inoltre il Supervisore sarà utilizzato da soggetti differenti, interessati a vario titolo ai problemi del traffico. E’ quindi molto importante che le tecniche di rappresentazione utilizzate, ed in generale tutta l’interfaccia operatore, siano semplici ed intuitive, e facciano sempre riferimento alla rete come elemento base comune di riferimento dei dati e delle informazioni. Il Supervisore dovrà permettere di selezionare come sfondo della rappresentazione grafica:

• il grafo della rete;

• la cartografia della rete. Tutte le funzionalità del Supervisore dovranno vedere una rappresentazione dei fenomeni su queste mappe, utilizzando la tecnica della rappresentazione ad oggetti per tutte le entità ed i parametri loro associati. Alle varie entità dovranno poi essere

Pagina 65

associate rappresentazioni simboliche o numeriche accessibili mediante la selezione delle entità stesse. Tale tecnica si dovrà applicare alla rappresentazione di grandezze direttamente legate al grafo stradale (quali flussi, livelli di saturazione degli archi, velocità, ecc.), per le quali si utilizzeranno rappresentazioni mediante codici colori o simili, ma per le quali mediante selezione dovrà anche essere possibile visualizzare l’andamento grafico delle grandezze o dati tabellari. Essa si applicherà però anche a quelle entità quali parcheggi, impianti di acquisizione dati, centraline ambientali, ecc. Ognuna di queste entità sarà associata ad una simbolo che sarà collocato sulla base cartografica (o sul grafo) mediante la sue coordinate georiferite o mediante localizzazione da parte dell’operatore. Attraverso la selezione del simbolo associato all’entità l’operatore potrà accedere alle grandezze associate all’entità stessa e derivarne i valori, gli andamenti ecc. (ad esempio numero di posti disponibili nei parcheggi, valori di concentrazione di inquinanti registrati, ecc.). Alle varie entità dovranno essere associabili una o più grandezze i cui valori verranno visualizzati e aggiornati in continuo sul sinottico. Il sistema dovrà essere inoltre in grado di gestire contemporaneamente viste differenti sia dei dati statici che di quelli dinamici, mediante l’impiego di finestre. Inoltre il sistema dovrà permettere ai vari operatori (se abilitati all’operazione) di configurare la propria vista del sinottico; in particolare dovrà essere possibile selezionare le entità e le relative grandezze che si vogliono visualizzare. Dovrà quindi essere possibile ai vari operatori definire se visualizzare sullo sfondo la rete sotto forma cartografica o di grafo, quali entità visualizzare su di essa, quali grandezza associare visivamente alle entità (nella logica dei layer dei sistemi cartografici). Tale configurazione dovrà essere dinamicamente modificabile. Sarà considerato elemento preferenziale la possibilità, attraverso strumenti di grafica, di rappresentare graficamente sulla rete anche i risultati di elaborazioni dei dati (e non solo dei dati correnti), e dati legati ad elementi di superficie, oltre che lineari e puntuali. Ciò al fine di poter rappresentare elementi quali zone a traffico limitato, aree di rilevamento di dati ambientali, e così via. Come risulta evidente da quanto descritto, la maggior parte delle funzionalità di MMI sono svolte dall’operatore interfacciando direttamente la rappresentazione grafica della rete, operando sulla rappresentazione delle varie entità e dei parametri ed attributi ad essi riconducibili. A complemento di questa struttura principale dell’interfaccia, dovrà essere possibile attivare le varie funzioni mediante l’impiego delle usuali tecniche di MMI basate su rappresentazione grafica di tasti funzionali, menù a tendine, icone e così via. Tutta l’interfaccia operatore dovrà avere caratteristiche di semplicità ed immediatezza, nonché di facile apprendimento. E’ richiesta la disponibilità di help contestuale in linea. Il Supervisore sarà utilizzato da attori differenti ed interessati a differente titolo alla gestione del traffico. Dovrà quindi possedere caratteristiche di facilità di accesso da parte di utenti differenti anche geograficamente distribuiti, per cui l’impiego di browser per l’interfaccia operatore sembra essere la tecnica più indicata.

Pagina 66

5.9 Costruzione e gestione dinamica di scenari di traffico

Il Supervisore dovrà essere in grado di gestire dinamicamente la identificazione, la creazione e l’utilizzo in tempo reale di scenari di traffico. Questa funzionalità è richiesta ai seguenti fini:

o Sintesi di comandi da inviare a sistemi di regolazione e/o gestione del traffico;

o Sintesi di informazioni da rendere disponibili o inviare all’utenza attraverso i vari canali disponibili;

o Costruire una base di conoscenza disponibile a fini di pianificazione. Uno scenario di traffico si può definire come una configurazione (pattern) di valori di parametri (quali volumi di traffico, velocità, densità, ecc.) associati ad archi della rete, o ad insieme degli stessi (aree, direttrici, incroci, ecc.). Ad ognuno di questi pattern è possibile associare delle azioni da svolgere quali l’invio di set point a specifici sistemi per l’attuazione di azioni (tipicamente invio di piani semaforici di riferimento all’UTC) o la generazione di informazioni da diffondere all’utenza (ad esempio attraverso pannelli a messaggio variabile o SMS, ecc.) o la generazione di allarmi specifici, ecc. Il Supervisore dovrà pertanto essere almeno in grado di:

o Supportare l’operatore nella costruzione di scenari, anche attraverso l’analisi di pattern pregressi e di dati storici;

o Identificare in tempo reale l’avverarsi di situazioni che si possano catalogare come uno degli scenari definiti e gestire la generazione (normalmente previa conferma da parte dell’operatore e solo su specifica istruzione in automatico) delle azioni associate allo scenario;

o Gestire dinamicamente le librerie di scenari associandovi i pattern di traffico conseguenti alle azioni intraprese.

Sarà considerato elemento di merito la capacità di sintetizzare in automatico nuovi scenari da suggerire all’operatore in base all’analisi di situazioni di criticità; il Supervisore cioè, sulla base dell’identificazione di situazioni particolari della rete o di un suo sottoinsieme (ad esempio approssimarsi di stati di congestione) potrà suggerire all’operatore uno specifico pattern da catalogare come “scenario di riferimento”, cui associare un set di azioni da definire. L’efficacia di questa funzionalità è definita dalla capacità di identificare pattern significativi e di generare più o meno in automatico un set di azioni di diverso genere da associarvi a scopo informativo e/o di regolazione. Va sottolineato comunque che la generazione di uno “scenario” classificato e trattato come tale, andrà comunque validato da un operatore qualificato. In fase di gestione l’elemento fondamentale è la capacità di identificare la convergenza dello stato verso uno dei pattern classificati come “scenari”.

5.10 Gestione di eventi

Un caso particolarmente rilevante e semplificato della gestione di scenari è quello della gestione di eventi. Per eventi si intendono situazioni particolari e codificate di cui si conosce l’accadere, e che richiedono particolari strategie di gestione del

Pagina 67

traffico. Si tratta per esempio di manifestazioni sportive o musicali, grandi fiere, emergenze per maltempo, e così via. In questo caso al singolo evento vengono ancora associate una serie di azioni che devono essere attuate e di informazioni che devono essere diffuse. Il verificarsi dell’evento viene in questo caso segnalato in modo sincrono (memorizzazione di un calendario) o asincrono dall’operatore, ed il Supervisore non farà che attuare le azioni ad esso associate. Anche in questo caso il Supervisore dovrà possedere tutte le funzionalità necessarie a gestire dinamicamente la creazione, modifica, e memorizzazione di eventi, e la memorizzazione dei parametri di rete associati agli eventi stessi, nella logica della gestione di una libreria. Anche in questo caso sarà valutata positivamente la disponibilità di strumenti di interfaccia semplici per la creazione e la gestione degli eventi.

5.11 Invio comandi verso sistemi periferici

Così come delineato nei paragrafi precedenti riguardanti la gestione di scenari ed eventi, il Supervisore dovrà avere la possibilità di inviare “comandi” ai sistemi periferici ad esso collegati. In particolare i sistemi per cui si deve prevedere questa funzionalità sono:

• i sistemi UTC, verso i quali dovrà essere possibile inviare dei set di piani semaforici che saranno attuati poi dall’UTC stesso;

• i pannelli a messaggio variabile, verso i quali dovrà essere possibile inviare messaggi generati in automatico o creati dall’operatore di supervisione.

Per i sistemi UTC l’operatore potrà (per decisione autonoma o su suggerimento del Supervisore) selezionare un determinato piano tra quelli disponibili per un impianto (o piani per una serie di impianti) ed inviarli come set point all’UTC. Le indicazioni provenienti dal Supervisore dovranno avere priorità su quelle dell’UTC. Per i pannelli a messaggio variabile varrà lo stesso meccanismo; in particolare l’operatore potrà in questo caso inviare non solo messaggi precodificato, ma anche digitare testi che saranno visualizzati sui relativi pannelli. Il Supervisore dovrà pertanto supportare questa funzionalità.

5.12 Funzioni avanzate di on-line management

Oltre alle funzionalità sopra definite, sarà anche elemento di valutazione la capacità del Supervisore di gestire logiche di generazione in linea di strategie di gestione del traffico (ad esempio priorità a certe direttrici, deviazione mediante l’aumento dell’impedenza su determinate direttrici e così via). Queste funzioni al momento attuale non rappresentano una priorità per le Amministrazioni, ma sarà considerato elemento di merito la possibilità da parte del Supervisore di possedere funzionalità di questo tipo.

Pagina 68

5.13 Interfaccia verso i sistemi di infomobilità

Il Supervisore dovrà rendere disponibili le informazioni acquisite ed elaborate al software di gestione delle informazioni da diffondere all’utenza (software di infomobilità) che è parte di questa fornitura ed è descritto in sezione 6. Di norma la piattaforma di infomobilità potrà accedere alla base dati per acquisire direttamente i dati ritenuti importanti e da diffondere. Il Supervisore dovrà però attivare la piattaforma in relazione all’identificazione dell’avverarsi di un pattern definito come “scenario”. In tal caso, qualora tra le azioni associate allo scenario esistano invii casi di invio di informazioni attraverso uno dei canali gestiti dalla piattaforma, il Supervisore dovrà attivare in modo asincrono il tool di infomobilità, passandogli o permettendogli di accedere alle informazioni necessarie a svolgere le azioni previste. Tra i requisiti che il Supervisore dovrà rispettare in questo senso, vi è quello della capacità di produrre/ricevere informazioni in formato DATEX.

5.14 Interfaccia verso strumenti di pianificazione del traffico

Al momento attuale Provincia e Comune di Firenze, anche nell’ambito dell’Ufficio Speciale per lo Studio delle Mobilità Fiorentina (USSMAF), operano con uno strumento di assegnazione del traffico (VISUM della PTV) su cui hanno modellato la rete urbana e su cui possono condurre analisi simulative. Il Supervisore comunque dovrà essere in grado di interfacciare questo tool (e generalmente tools di micro e macro simulazione di questo tipo che dovessero essere acquisiti). In particolare la compatibilità dovrà risiedere in:

o Possibilità di esportare verso il tool la rete; o Possibilità di esportare verso il tool determinati insiemi (definibili

dall’operatore) di valori misurati e/o elaborati dei parametri di traffico; o Possibilità di utilizzare i valori misurati dei flussi di traffico per la sintesi o la

calibrazione di matrici OD; o Possibilità di utilizzare il tool di assegnazione o simulazione in tempo reale a

scopo di verifica o di previsione. Sarà considerato elemento di merito qualora il Supervisore integri queste funzionalità, cioè possieda uno strumento di assegnazione o di simulazione che utilizzi lo stesso grafo e sia in grado di operare nello stesso ambiente del Supervisore almeno le due ultime funzionalità sopra elencate, cioè la calibrazione delle matrici OD e l’assegnazione in tempo reale con confronto con i parametri di rete misurati.

5.15 Centralizzazione dello stato dei sistemi collegati

Dal sinottico del Supervisore dovrà essere possibile visualizzare lo stato dei sensori e dei dispositivi periferici collegati ai sistemi interfacciati dal Supervisore stesso.

Pagina 69

A tal fine sarà resa disponibile dai sistemi collegati al Supervisore, che la dovrà acquisire in tempo reale con una frequenza adeguata, una tabella con lo stato dei sistemi. Il Supervisore dovrà visualizzare un codice limitato di stati, definibile in generale come:

• Dispositivo funzionante;

• Dispositivo fuori servizio;

• Dispositivo in funzionamento degradato (se applicabile). Lo stato dei dispositivi dovrà essere visualizzabile sul sinottico in maniera grafica associata all’icona rappresentante il dispositivo stesso. In caso di dispositivo fuori uso potrà essere generata una segnalazione all’operatore, tenendo conto che la gestione vera e propria degli allarmi in questo senso sarà competenza dei singoli sistemi.

5.16 Gestione allarmi

Il Supervisore dovrà monitorare il proprio corretto funzionamento ed il corretto flusso delle informazioni. In caso registri un malfunzionamento, la mancanza di collegamento con uno dei sistemi o altro, dovrà generare un allarme codificando per quanto possibile il tipo di malfunzionamento. L’allarme dovrà essere gestito secondo le usuali procedure, fino alla presa in carico e alla registrazione della regolarizzazione, mantenendo comunque i log degli allarmi. Il sistema dovrà poter produrre report sugli allarmi registrati e sulla loro gestione.

5.17 Amministrazione di sistema e reportistica di sistema

Il sistema dovrà fornire tutte le primitive per l’amministrazione. In particolare dovranno essere garantite almeno le seguenti funzionalità:

• definizione di categorie di operatori e dei relativi diritti secondo una classificazione che sarà definita con la Provincia ed il Comune di Firenze;

• gestione della anagrafica operatori e dei relativi diritti;

• log delle operazioni di comando sistemi esterni svolte dagli operatori abilitati;

• associazione a singoli operatori di configurazioni di visualizzazione (cioè di sottosistemi di tutti gli elementi visualizzabili);

• gestione degli accesi al sistema mediante password;

• gestione della generazione e del rinnovo delle password;

• visualizzazione e reporting sulle performances di sistema;

• gestione dei meccanismi di salvataggio dati; il sistema dovrà garantire il salvataggio periodico in automatico della base dati in modo tale da garantire il ripristino degli stessi in caso di inconveniente senza perdita di dati.

L’amministratore di sistema dovrà poter ottenere report sulle prestazioni del sistema, sulle operazioni svolte, sullo stato della memoria ecc.

Pagina 70

6 Specifica funzionale della piattaforma di infomobilità Questa sezione descrive la piattaforma di infomobilità che, a partire dai dati prodotti dal Supervisore e da altri sistemi di acquisizione dati, fornirà i servizi agli utenti sulla mobilità, i percorsi, tempi d’arrivo e altro. Per i servizi richiesti vengono specificati sia i requisiti minimi che il proponente dovrà soddisfare nella proposta, sia eventuali indicazioni su elementi aggiuntivi che costituiranno elemento di merito in sede di valutazione. Tali indicazioni o suggerimenti sono nel seguito chiaramente identificabili nel contesto della descrizione. Si richiede al proponente di esplicitare in modo evidente nell’offerta se e come questi suggerimenti verranno recepiti dal progetto e in che misura. Nel seguito, ci si riferirà all’insieme dei servizi come ISM (Info-Sistema Mobilità). La sigla viene usata per indicare sia i servizi, che l’insieme degli applicativi software che implementano i servizi stessi.

6.1 Caratteristiche della rete wireless della linea 1

Come specificato nell’introduzione, i servizi di infomobilità verranno inizialmente veicolati attraverso un infrastruttura telematica con rete di accesso in tecnologia wireless che sarà sviluppata sulla Linea 1 della tramvia di Firenze ed in altre aree del territorio; in particolare si evidenzia che sul territorio del Comune di Firenze sono già stati attivati alcuni access-point Wi-Fi. Il proponente dovrà far riferimento a questa infrastruttura per la realizzazione degli applicativi ISM. La Figura 1 mostra come i servizi ISM sono inseriti all’interno dell’architettura di rete in cui verranno installati gli applicativi.

Figura 1: Schema generale del sistema di infomobilità. I servizi ISM saranno accessibili sia attraverso l’infrastruttura wireless della tramvia (o sue estensioni), sia attraverso Internet. Per fornire servizi personalizzati gli applicativi dovranno sfruttare i sistemi di autenticazione e localizzazione che la infrastruttura wireless in via di realizzazione metterà a disposizione.

Pagina 71

La linea 1 connette Scandicci con il centro di Firenze, con un percorso di 7,6 km e 12 fermate, oltre ai due capolinea, ubicati a Villa Costanza ed alla stazione di Santa Maria Novella. I 17 tram in esercizio sono convogli del tipo “Sirio”, costruiti da Ansaldo Breda, in versione a 5 casse, lunghi 32 metri, con 42 posti a sedere e 160 posti in piedi (con una densità di 4 passeggeri/mq).

Figura 2: Sistema tramviario fiorentino - linea 1

Avvalendosi della fibra ottica già posata lungo il tracciato della tramvia si realizzerà un’infrastruttura di rete per il trasporto e l’accesso, in grado di erogare il servizi di connettività Wi-Fi sia alle fermate a terra che a bordo del tram. La connettività alle fermate sarà erogata attraverso access point Wi-Fi installati alle fermate, mentre la connettività a bordo tram è erogata attraverso access point Wi-Fi installati a bordo tram, che si appoggiano agli access point installati lungo il tracciato per il collegamento alla rete di trasporto. Per quanto riguarda il meccanismo di accesso, la rete di sarà realizzata in tecnologia standard IEEE 802.11 b/g, eventualmente n negli ambienti compatibili (indoor), per garantire un accesso standard ampiamente diffuso fra i più comuni dispositivi multimediali degli utenti. Tale rete sarà pianificata in maniera da garantire una copertura completa, senza soluzioni di continuità dell’intero tragitto tramviario, incluse le stazioni e l’interno dei tram; inoltre, la rete garantisce un handover trasparente per l’utente durante tutto il suo percorso all’interno della rete, dalla stazione di salita alla stazione di discesa. L’infrastruttura wireless dispone di un sistema di controllo centrale, che permette di gestire tutta l’infrastruttura di trasporto e di verificare la corretta interazione con le applicazioni che saranno veicolate sulla rete stessa. Oltre all’infrastruttura della tramvia, il Comune di Firenze ha attivato una serie di access point wireless collocati in un certo numero di spazi aperti in area urbana.

Pagina 72

Questi access point dovranno condividere la stessa base utenti rispetto a quelli autenticati nell’infrastruttura della tramvia. In Figura 3 sono riportati il tracciato della Linea 1 della tramvia di Firenze e le altre zone in cui sono già stati attivati gli access point wireless.

Figura 3: Access point wireless installati o in corso di installazione nel territorio cittadino.

6.2 Funzionalità di autenticazione e autorizzazione degli utenti

L’infrastruttura wireless dispone di un sistema di controllo deputato alla gestione, in modalità centralizzata, degli accessi (AAA, autenticazione, autorizzazione, accounting) degli utenti alla rete, basato sul protocollo RADIUS1. Si prevede inoltre che altre basi dati di utenze registrate correntemente in uso presso gli enti interessati (Linea Comune, ARPA, Unifi, ecc.), possano essere integrate in modo da allargare la base di utenza dei servizi di infomobilità, senza richiedere registrazioni multiple. Anche queste fonti saranno comunque interfacciabili tramite RADIUS. Nell’ambito dell’infrastruttura di rete wireless della tramvia, il protocollo RADIUS è utilizzato per gestire le credenziali di accesso, e autorizzare o meno gli utenti all’uscita su rete Internet, tramite un dispositivo NAS (Network Access Server). In pratica, l’utente in mobilità che si è già registrato presso una delle basi di utenti predisposte, ha la possibilità di utilizzare la rete wireless per la navigazione su Internet, introducendo le proprie credenziali.

1 RFC 2865 Remote Authentication Dial In User Service (RADIUS), RFC 2866 RADIUS Accounting

Pagina 73

6.3 Funzionalità di localizzazione degli utenti

L’infrastruttura wireless renderà disponibile in un formato standard la localizzazione degli utenti, a tutte le applicazioni che possono farne uso per la fornitura di servizi profilati e/o georeferenziati. In particolare le applicazioni possono ottenere le informazioni necessarie alla localizzazione tramite interrogazione di web service. Con localizzazione si intende la conoscenza della posizione, intesa come area (cella) in cui l’utente si trova. Questo significa che per gli utenti in stazione viene indicato l’AP cui sono collegati, mentre per un utente sul tram viene indicata la posizione del tram cui è associato in quel momento, insieme all’informazione dell’AP di terra cui a sua volta il tram è collegato. Inoltre viene fornita l’informazione relativa alla direzione di viaggio per riuscire ad individuare non solo la cella attuale ma anche quella precedente e quella successiva. Sono previsti due tipi di informazioni di localizzazione: 1. Localizzazione su base cella: il sistema permette all’applicazione chiamante di

dialogare con tutti gli utenti associati a una certa cella;

2. Localizzazione su base utente: il sistema permette all’applicazione chiamante di ottenere la posizione (e la direzione nel caso di utenti a bordo tram) di un certo utente. In questo modo, l’applicazione può fornire informazioni personalizzate ad utenti autenticati, ed eventualmente profilati. In ogni caso, tramite le funzionalità di localizzazione il sistema ha conoscenza (con una certa approssimazione) della posizione geografica dell’utente. Nel caso di utenti a bordo del tram la posizione sarà nota grazie alla conoscenza della posizione del tram, mentre nel caso di utenti a terra si avrà una accuratezza dell’ordine di alcune decine di metri (corrispondenti alla portata degli access point).

6.4 Modalità di erogazione dei servizi

I servizi ISM dovranno garantire la possibilità di essere utilizzati secondo tre distinte modalità:

1. On demand: è da considerarsi la modalità privilegiata per l’erogazione di informazioni. L’utente utilizza il proprio dispositivo dotato di interfaccia Wi-fi, e interroga il servizio per ottenere le informazioni di proprio interesse (es., l’orario di una certa linea dell’autobus).

2. Broadcasting: le informazioni in broadcast (es., news sul traffico) che vengono veicolate attraverso i mezzi di informazione al pubblico (I.a.P), quali pannelli informativi, monitor, ecc., dovranno essere proposte anche sulle pagine immediatamente visibili all’utente a seguito della connessione. La consultazione di tali informazioni non richiede l’autenticazione dell’utente. Le informazioni saranno (ove questo sia utile) filtrate secondo la localizzazione degli utenti. Ad esempio, per gli utenti sul tram diretti verso Scandicci le informazioni sul traffico saranno quelle relative a Scandicci, viceversa per quelli diretti a Firenze.

Pagina 74

3. Push: Questa modalità prevede l’utilizzo di canali che possano essere trasmessi verso l’utente senza che questo ne faccia ogni volta esplicitamente richiesta (es. Email, SMS). Si possono ulteriormente differenziare le modalità di tipo push in due tipologie:

a. Trasmissione del servizio a uno o più utenti specifici, in base alle preferenze definite dagli utenti stessi. Ad esempio l’invio di e-mail sulle condizioni del traffico agli utenti che ne hanno fatto richiesta rientra in questa tipologia. Il sistema conosce l’identità dell’utente e la utilizza per inviare il servizio.

b. Trasmissione del servizio a tutti gli utenti identificati attraverso informazioni di contesto. Ad esempio, l’invio del servizio a tutti gli utenti che sono posizionati in una certa cella wireless dell’infrastruttura, o posizionati in un certo raggio rispetto a una posizione di interesse.

In entrambi i casi, la fruizione del servizio potrebbe avvenire attraverso l’uso di particolare client installati sul dispositivo dell’utente, che funzionano da “ricevente” dei servizi erogati dal sistema. Costituirà elemento di merito la presenza nella proposta di client dedicati alle piattaforme HW/SW mobili più diffuse sul mercato (es. I-Phone, Java ME, Android, etc.).

Indipendentemente dalla modalità di erogazione, dovrà essere privilegiata la possibilità per l’utente di interagire in tempi rapidi con il sistema per ottenere le informazioni desiderate.

6.5 Canali di erogazione dei servizi

La Provincia di Firenze già si avvale di una piattaforma multicanale per l’erogazione dei servizi di infomobilità ai cittadini. I canali utilizzati sono tutti quelli attualmente disponibili (web, call center, radio, tv, televideo, SMS, videomessaggi, pannelli a messaggio variabile, navigatori, ecc..). Attraverso i progetti “SIMONE” e “Wi-Move”, nell’ambito dei quali si colloca il presente appalto, la Provincia intende estendere in maniera significativa l’infosistema della Provincia di Firenze in termini sia del bacino d’utenza che di modalità di fruizione dei servizi, nonché in termini di quantità e qualità dell’informazione. Questo obiettivo si potrà raggiungere sia attraverso l’erogazione delle informazioni attraverso la realizzanda infrastruttura telematica con rete d’accesso in tecnologia Wi-Fi, sia integrando in un’unica piattaforma di gestione i principali canali di erogazione già attivati sul territorio – tanto di tipo infrastrutturale (es. pannelli a messaggio variabile), quanto con connotazione di servizio (es. call center). Si richiede pertanto che la Piattaforma di infomobilità oggetto dell’appalto sia capace di supportare i sopra citati sviluppi in termini di ampliamento, consolidamento ed integrazione dei canali di comunicazione. Più spcificamente, quindi, si richiede che la Piattaforma sia in grado di effettuare il delivery delle informazioni attraverso la rete Wi-Fi della Linea 1, e capace di dialogare con i dispositivi personali degli utenti (in generale, terminali portatili dotati di interfaccia Wi-Fi e telefoni cellulari).

Pagina 75

Si richiede altresì che la Piattaforma rappresenti uno strumento attraverso il quale il call center telefonico della Provincia di Firenze e dei Comuni del territorio (denominato “055055”, e gestito dal centro servizi territoriale Linea Comune), possa veicolare anche attraverso gli altri canali gestiti dal medesimo call center le informazioni disponibili sulla piattaforma di infomobilità – eventualmente anche attraverso l’integrazione in cooperazione applicativa con gli strumenti software già in uso presso Linea Comune. In ambito Internet/intranet, si individuano i seguenti canali potenziali di erogazione servizi. Il proponente dovrà obbligatoriamente includere nell’offerta le modalità indicate come richieste, mentre costituirà elemento di merito la proposta di ulteriori modalità aggiuntive, tra quelle qui indicate e/o altre descritte dal proponente: Web:

o Portale dei servizi della mobilità (richiesto). Consultabile dagli utenti non necessariamente in mobilità (a casa, lavoro, ecc.), tramite computer dotato di schermo di dimensioni standard. Riporta in modo esteso tutte le informazioni che i servizi ISM forniscono. Permette agli utenti di individuare le informazioni di maggior interesse, e inserire il proprio profilo in modo da ottenere un flusso di informazioni selezionate quando entrano nel raggio della rete wireless della tramvia.

o Portale servizi mobile (richiesto). Versione per dispositivi mobili del portale della mobilità. Questo portale sarà disponibile sia sulla intranet della tramvia, sia su Internet. Nella descrizione dei servizi si farà in particolare riferimento a questo strumento di erogazione, poiché appare sicuramente come la modalità privilegiata di accesso al servizio.

o Applicazioni web esistenti di uso comune, p.es. Google maps, Google transit, Google calendar, Twitter, Facebook, etc. L’utilizzo di queste applicazioni come canali di erogazione di informazioni risulta essere sempre più frequente, soprattutto nell’ambito degli utenti più giovani. Ad esempio, applicazioni come Google maps e calendar possono essere utilizzate per creare mappe spaziali e calendari in cui sono elencati elementi che hanno impatto sulla mobilità urbana (cantieri, deviazioni strade, ecc.). L’integrazione delle applicazioni menzionate costituirà un elemento di merito.

• E-mail (richiesto): questo strumento è considerato essenziale per l’erogazione di servizi in modalità push, dato il costo essenzialmente gratuito dell’invio, e la sempre crescente disponibilità di client di posta elettronica sui terminali portatili.

• SMS/MMS: nei vari scenari d’uso della piattaforma si prevede anche la possibilità di invio di messaggi SMS/MMS agli utenti tramite reti di telefonia mobile. Tale ipotesi deve pertanto essere prevista sin dall’inizio a livello architetturale, e deve contemplare la possibilità di differenziare l’invio dei messaggi in base alle preferenze degli utenti (registrati e profilati) e ad eventuali vincoli definiti dal gestore del servizio (es. numero massimo di invii quotidiani, ecc.). Più spcificatamente, si richiede che siano previste e documentate le interfacce (API) che

Pagina 76

consentano l’invio dei messaggi – secondo le preferenze impostate dagli utenti ed i vincoli definiti dal gestore del sistema – ai sistemi hardware (modem GSM/GPRS) o software (sia presso il committente sia in modalità ASP) che il Committente individuerà per l’invio dei messaggi.

• Dispositivi IaP (Informazione al Pubblico) (richiesto): Fanno parte di questa categoria dispositivi quali pannelli a messaggio variabile, monitor, touch screen, ecc. Poiché si prevede che la diffusione di tali dispositivi vada a aumentare rapidamente nel breve/medio termine, è necessario prevedere un servizio realizzato con tecnologia Web Service o similari, che fornisca in modo standard la possibilità di accedere a tutte le informazioni che vengono prodotte dal sistema di infomobilità, e in ultima analisi fornite agli utenti. In questo modo, eventuali piattaforme di palinsesto che dovessero essere installate per la gestione della IaP potranno collegarsi al servizio e fornire a loro volta le informazioni ritenute di maggior interesse per gli utenti. Questo servizio sarà inoltre utilizzato per tutte le applicazioni di terze parti che dovessero essere abilitate in futuro all’accesso ai dati del sistema. La specifica precisa delle informazioni da rendere disponibili sarà definita in fase di avviamento del progetto. In questo ambito il requisito minimo è costituito da un modulo che consenta, ad operatori appositamente individuati dal soggetto individuato dal Committente quale gestore della Piattaforma (ed ai quali saranno quindi assegnati necessari privilegi), di definire dei messaggi (ed eventualmente di selezionarne da varie fonti) ed inviarli ai PMV di cui nel presente documento (tutti, gruppi selezionati o singoli).

6.6 Accesso ai servizi

L’accesso ai servizi erogati via web, dovrà essere possibile sia attraverso l’infrastruttura wireless della tramvia o sue estensioni, sia attraverso una generica connessione a Internet che l’utente ha a disposizione, come mostrato in Figura 1. A chiarificazione ulteriore di questo aspetto, si prevedono i seguenti scenari per l’accesso ai servizi web:

• Utente in mobilità dotato di un dispositivo con interfaccia wireless (palmare, telefono, PC portatile, ecc.). L’utente accede al portale web (standard o mobile) utilizzando il proprio dispositivo connesso alla rete wireless. Nel caso l’utente sia registrato, gli viene permesso l’accesso a qualsiasi risorsa web. Nel caso non lo sia, l’infrastruttura gli mette comunque a disposizione il set di servizi ISM.

• Utente connesso a Internet mediante connessione propria (ADSL, LAN, GPRS/3G, ecc.). In questo caso l’utente accede al portale web (standard o mobile) analogamente a quanto avviene per un normale sito web.

In entrambi gli scenari il sistema dovrà essere in grado di rilevare il tipo di dispositivo di accesso, e re-indirizzare l’utente sulle pagine standard o per dispositivi mobili in accordo al tipo di dispositivo stesso. Per quanto riguarda l’autenticazione al sistema, i servizi ISM dovranno essere in grado di recuperare il profilo dell’utente a partire dalle credenziali di autenticazione scambiate con il server RADIUS in occasione dell’accesso alla rete. Questo in modo da evitare che l’utente debba inserire due volte le proprie

Pagina 77

credenziali, la prima per accedere alla rete e la seconda per accedere ai servizi. L’utente in mobilità, dotato di un dispositivo di dimensioni ridotte, vede così accrescere l’usabilità e l’accessibilità del sistema. Questo meccanismo ovviamente vale solo per gli utenti che accedono ai servizi tramite la rete wireless della tramvia.

6.7 Profilazione e autenticazione

Un aspetto di importanza cruciale dovrà essere la possibilità da parte del sistema di fornire informazioni pre-filtrate a seconda delle preferenze personali specificate dagli utenti. A questo fine gli applicativi ISM dovranno supportare un meccanismo basato su due livelli di profilazione, descritti come segue:

• Profilo terminale: Con questa tipologia di profilazione il sistema non conosce i dati relativi all’identità dell’utente, ma solo del suo terminale. Questo profilo viene prodotto “on-line” da parte del sistema, mentre l’utente sta usufruendo dell’applicazione. Ad esempio, se l’utente interroga il sistema riguardo gli orari di una certa linea del servizio pubblico, il sistema proporrà all’utente la possibilità di salvare questa preferenza (utilizzando meccanismi basati su cookie o similari). Il sistema provvederà poi a utilizzare questa preferenza per i successivi accessi al servizio effettuati con lo stesso terminale.

• Profilo utente: in questo caso l’utente si è effettivamente registrato presso l’applicazione di infomobilità, ed ha inserito le proprie preferenze personali. Il sistema dovrà essere in grado di gestire almeno le seguenti informazioni:

• Identità dell’utente;

• Itinerari di interesse;

• Modi di trasporto preferiti;

• Giorni e orari tipici di viaggio. Una differenza fondamentale tra le due tipologie di profilo è data dal meccanismo di persistenza del profilo stesso. Nel caso del “profilo terminale” infatti la persistenza è necessariamente implementata sul terminale (utilizzando meccanismi basati su cookie o similari), mentre nel caso del profilo utente la persistenza è realizzata lato server. In fase di registrazione, il sistema dovrà proporre all’utente la possibilità di salvare le informazioni di “profilo terminale” all’interno del proprio profilo utente (ove questo sia applicabile). Quando l’utente accede al servizio, inserisce le proprie credenziali di autenticazione e il sistema provvede a restituire informazioni personalizzate, indipendentemente dal dispositivo con cui l’accesso è stato eseguito. Le preferenze registrate a priori dall’utente, e che riguardano solitamente tragitti ricorrenti (es. casa-lavoro), potranno essere integrate con informazioni raccolte in tempo reale sia direttamente dall’utente sia automaticamente (es. posizione attuale dell’utente, determinata in base alla cella Wi-Fi presente sul mezzo e/o alla fermata su/presso cui si trova l’utente), in maniera tale da fornire un adeguato supporto anche nei tragitti occasionali.

Pagina 78

Il primo livello di profilazione è ovviamente preferibile, in quanto non richiede che l’utente esegua le operazioni di inserimento delle informazioni, e soprattutto che non debba effettuare l’accesso tramite login e password mentre si trova in mobilità. E’ importante notare come in questo contesto la localizzazione può costituire una prima informazione implicita di profilo: il sistema dovrà ove opportuno filtrare le informazioni trasmesse sfruttando la posizione e la direzione degli utenti fornita dall’infrastruttura wireless, indipendentemente dallo stato di autenticazione/profilazione dell’utente. La seguente tabella riassume i principali scenari d’uso in cui può trovarsi l’utente in mobilità, e il rispettivo comportamento richiesto del sistema: N Scenario Descrizione Requisiti

1

Utente in mobilità, situato all’interno della infrastruttura wireless, non registrato.

Si tratta dello scenario di riferimento. E’ il caso dell’utente occasionale (o comunque non ancora fidelizzato) che si trova ad utilizzare i servizi di infomobilità senza essersi registrato. L’utente non è abilitato all’accesso a Internet, ma può accedere solo alle pagine intranet che fanno parte fornite dalla rete della tramvia.

Il sistema dovrà acquisire le preferenze dell’utente tramite il meccanismo di profilo di livello 1 descritto sopra (profilo terminale). Dovrà in particolare essere proposto all’utente di salvare le proprie scelte per quanto riguarda i tragitti ricorrenti. Il sistema dovrà inoltre utilizzare l’informazione di localizzazione fornita dalla infrastruttura wireless per contestualizzare per quanto possibile l’informazione fornita rispetto alla posizione e direzione dell’utente.

2

Utente in mobilità, situato all’interno della infrastruttura wireless, registrato e autenticato.

Rispetto allo scenario precedente, l’utente ha ottenuto le credenziali di autenticazione, e le ha inserite al momento dell’accesso al servizio. L’utente ha quindi pieno accesso a web. Inoltre, l’utente ha specificato al momento della registrazione quali sono le proprie preferenze personali (orari, linee, ecc.).

Oltre a quanto specificato nel caso dello scenario precedente, il sistema dovrà fare uso delle informazioni relative all’identità dell’utente e delle sue preferenze per produrre le informazioni personalizzate.

3 Utente situato L’utente ha pieno accesso al web, Analoghi allo scenario 1,

Pagina 79

all’esterno della infrastruttura wireless, non autenticato.

ma accede tramite una connessione personale. Si tratta di uno scenario analogo allo scenario 1, con la differenza che il sistema non conosce le informazioni di posizione e direzione fornite dall’infrastruttura wireless.

a parte l’uso delle informazioni di localizzazione.

4 Utente situato all’esterno della infrastruttura wireless, autenticato.

L’utente ha pieno accesso al web, ma accede tramite una connessione personale. Si tratta di uno scenario analogo allo scenario 2, con la differenza che il sistema non conosce le informazioni di posizione e direzione fornite dall’infrastruttura wireless.

Analoghi allo scenario 2, a parte l’uso delle informazioni di localizzazione.

6.8 Catalogo dei servizi richiesti

Questa sezione descrive in dettaglio l’insieme dei servizi ISM, in termini delle funzionalità utente che questi servizi dovranno essere in grado di fornire. Ove necessario, si farà riferimento ai servizi stessi come generiche applicazioni di tipo web-based (indipendentemente dal client usato per l’accesso), poiché questa appare essere la modalità più indicata per il contesto d’uso in oggetto. Per ogni servizio viene descritto uno scenario d’uso riferito all’utente in mobilità, dotato di terminale personale equipaggiato con interfaccia Wi-Fi e localizzato nel raggio di copertura della rete wireless. I servizi saranno disponibili anche per gli utenti connessi a Internet attraverso una connessione propria di altro tipo (ADSL, GSM/GPRS, ecc.), e in questo caso ovviamente non saranno utilizzate dal sistema le informazioni di autenticazione/localizzazione utente proprie della infrastruttura wireless descritte in sezione 6.a . Per alcuni servizi sarà comunque necessario prevedere una modalità per utenti autenticati e/o profilati, e una per utenti senza informazioni di profilo associate. Per tutti i servizi, costituirà elemento di merito l’offerta di un alto livello di personalizzazione del servizio in base all’eventuale profilo specificato e alle informazioni di localizzazione messe a disposizione dall’infrastruttura di rete.

6.8.1 Caratteristiche comuni a tutti i servizi

• Tutti i servizi dovranno garantire la fruibilità sia dal portale web che dal portale mobile di tutte le funzionalità previste;

• Tutti i servizi dovranno prevedere, ove necessario, una modalità di inserimento dati “semplice” (es. Origine e destinazione nel servizio calcola percorso), e una “avanzata”, eventualmente raggiungibile navigando in una pagina apposita, in cui l’utente ha la possibilità di raffinare la propria interrogazione. Per quanto riguarda

Pagina 80

la modalità semplice, dovranno essere previste funzionalità di inserimento assistito dei dati (autocompletamento, suggerimenti, ecc.), in modo da favorire la fruizione dei servizi con i dispositivi mobili.

• Per i servizi che richiedono una connessione a Internet, dovrà essere prevista una modalità “degradata”, che presenti all’utente solo le informazioni disponibili in rete locale. Si richiede di descrivere in modo preciso sia la modalità normale che quella degradata dei servizi offerti;

• Tutti i servizi (ove applicabile) dovranno prevedere la presentazione delle informazioni sia in formato testuale (es. Diario di viaggio, elenco bus, ecc.) che geografico (cioè su mappa). Si richiede di fornire all’utente le informazioni in termini di “layer” su una mappa del territorio urbano, che l’utente può attivare o meno a seconda delle proprie necessità. Il servizio di mappa dovrà essere disponibile indipendentemente dalla connessione web.

• Tutti i servizi dovranno prevedere la possibilità di diffondere (tramite l’interfaccia utente) degli avvisi all’utenza relativi allo specifico servizio (es., avviso che riguarda l’entrata in vigore della ZTL stagionale);

• Tutti i servizi dovranno prevedere una specifica interfaccia utente dedicata agli operatori di call center, per i quali in generale sarà importante disporre di tutte le possibilità di interrogazione di un certo servizio, in modo da poter erogare il servizio stesso agli utenti del call center. Tale interfaccia dovrà essere raggiungibile ad un indirizzo URL diverso da quello della normale interfaccia per gli utenti generici, e l’accesso dovrà in ogni caso essere protetto tramite un meccanismo di autorizzazione/autenticazione.

6.8.2 Descrizione dei servizi

Nome Profilazione

Descrizione Permette all’utente di inserire le proprie preferenze personali

Scenario d’uso

L’utente accede al portale dei servizi utilizzando un pc standard, oppure il proprio terminale portatile quando si trova nella rete della tramvia. Dopo essersi autenticato (tramite inserimento di username e password), l’utente ha a disposizione una sezione “Preferenze personali”, in cui può inserire in maniera completa o parziale le informazioni di profilo descritte nel paragrafo § 6.7.

Nome Orari trasporto pubblico

Descrizione Permette all’utente di consultare gli orari di tram, autobus e treni

Scenario d’uso

Permette agli utenti di accedere agli orari del trasporto pubblico, divisi per tram, autobus e treni in partenza/arrivo dalle stazioni cittadine. L’utente può scegliere di consultare gli orari in modalità on-demand, eseguendo una interrogazione al sistema per ottenere i mezzi e linee di interesse. L’utente autenticato a questo punto può salvare il risultato di

Pagina 81

una interrogazione, inserendolo tra i propri contenuti preferiti, in modo da poter richiamare tale contenuto successivamente senza bisogno di effettuare di nuovo l’intera procedura. Dovranno essere chiaramente indicate le deviazioni delle linee rispetto all’orario programmato (causa chiusura strade, lavori, ecc.).

Nome Calcola percorso multi-modale

Descrizione Permette all’utente di calcolare l’alternativa migliore per un certo itinerario

Scenario d’uso

Questo servizio consente all’utente in mobilità di individuare l’itinerario ottimale per raggiungere la propria destinazione, utilizzando i modi di trasporto offerti dal servizio pubblico e i percorsi pedonali. Il sistema dovrà fornire un percorso multi-modale, nel senso che gli itinerari proposti saranno composti da una serie di tratte, ognuna delle quali da percorrersi con uno dei mezzi previsti dal servizio ed eventualmente selezionati dall’utente. Il sistema dovrà gestire i seguenti modi di trasporto:

• Tram;

• Autobus;

• Percorsi pedonali; Il numero dei modi di trasporto gestiti dovrà essere personalizzabile nel caso si renda opportuno eliminarne alcuni o inserirne di nuovi (es. bicicletta, treno). L'utente potrà indicare origine, destinazione ed eventuali tappe intermedie con modalità a scelta fra le seguenti:

• Indicando un qualsiasi indirizzo, espresso come combinazione di Via + Numero civico + Comune;

• Indicando due vie (intersezione tra le due vie);

• Scegliendo un luogo registrato come punto di interesse (museo, albergo, stazione, ecc...).

L’utente potrà specificare eventuali tappe intermedie che l’itinerario dovrà comprendere (es. “dal capolinea di Scandicci della tramvia all’aeroporto passando per la stazione di Rifredi”). Il sistema dovrà selezionare gli itinerari ottimali, minimizzando (a scelta dell’utente) uno dei seguenti criteri:

• tempo di percorrenza;

• numero di cambi di mezzo;

• attese tra i cambi;

• distanza da percorrere a piedi. Oltre alla destinazione e alla preferenza sul criterio da minimizzare, l’utente potrà specificare l’orario di arrivo desiderato. Rispetto ai sistemi tradizionali, questo servizio dovrà essere in grado di fornire una risposta dinamica, che tiene cioè conto anche dello stato attuale della rete – e quindi dello stato complessivo elaborato dal

Pagina 82

Supervisore – così come di altre informazioni rese disponibili dagli altri sistemi tributari (es. condizioni di traffico intenso determinate dal Supervisore lungo alcune direttrici, scostamento attuale del tempo di arrivo dei mezzi del TPL interessati dall’itinerario risultanti dal sistema AVM rispetto a quanto specificato nell’orario vigente del servizio pubblico, ecc.). Ove l’utente richieda un itinerario da compiersi in orario diverso da quello attuale (ad esempio dopo qualche ora rispetto all’interrogazione), lo stato in tempo reale non risulta più utile, e quindi il sistema dovrà rifarsi ai dati statici (es. orario del trasporto pubblico) o semi-statici (es. ordinanze della viabilità). Costituirà elemento di merito la possibilità di utilizzare per questi casi non solo i dati statici, ma anche i dati storici, raccolti in questo caso a partire dagli scenari del Supervisore. Ad esempio, il sistema potrebbe suggerire l’utilizzo di itinerari diversi in momenti diversi della giornata, per evitare situazioni di traffico congestionato ricorrenti nelle ore di punta. Il software proposto, comunque dovrà dare all’amministratore di sistema la possibilità di attivare e disattivare le funzionalità di calcolo dinamico dei percorsi abilitando e disabilitando separatamente almeno le funzioni di calcolo correlate a:

• valutazione del tempo di transito dei mezzi pubblici basati sullo stato del servizio acquisito in tempo reale;

• valutazione del tempo di percorrenza basato sulle condizioni di traffico stimate, sulle ordinanze (cioè tutte le funzionalità aggiuntive legate allo stato della rete);

Qualora tali funzionalità vengano disattivate, il modulo dovrà operare un calcolo statico del percorso e dei relativi tempi. Le interrogazioni potranno essere salvate dall’utente all’interno delle proprie informazioni di profilo. In questo modo il sistema potrà aggiornare automaticamente l’itinerario migliore, ad ogni accesso dell’utente alla rete, in modo dinamico e contestualizzato alle attuali condizioni del trasporto pubblico. A seguito di una interrogazione, il sistema dovrà riportare all’utente un elenco di scelte possibili, ordinate rispetto al criterio che l’utente ha scelto di ottimizzare tra quelli disponibili. Dovrà essere possibile visualizzare l’itinerario su mappa e tramite diario di viaggio (sequenza testuale che descrive le singole tratte). Di ogni tratta dovranno essere indicati i tempi di partenza e arrivo, e le indicazioni necessarie alla percorrenza della tratta. Per i percorsi a piedi potranno essere utilizzate delle stime predefinite sui tempi di percorrenza, personalizzabili dall’utente (permettendo ad esempio di modificare la velocità di camminata). Dovranno essere previsti elementi per accedere a itinerari “precedenti” o “successivi” rispetto a quello correntemente visualizzato. I servizi di mappa dovranno essere configurabili dal gestore del sistema e potranno accogliere dati geografici nei formati vettoriali e raster più

Pagina 83

diffusi. Il sistema dovrà essere fruibile sia dal portale web che da quello mobile. In entrambi i casi dovrà essere posta particolare cura nella progettazione dell’interfaccia utente, con il rispetto di standard di usabilità ed accessibilità allo stato dell’arte2. Nel caso della versione per terminali mobili, dovranno essere previste delle modalità di inserimento dei dati quanto più possibile assistite e di facile utilizzo per l’utente, utilizzando ad esempio funzionalità di autocompletamento, presenza di tasti di inserimento rapido per destinazioni ricorrenti, ecc. Il sistema dovrà essere estendibile attraverso l’implementazione di interfacce software semplici e documentate, in particolare per quanto riguarda l’aggiunta di:

• modalità di trasporto (es. treno, altri servizi di linea, bicicletta, carrozzella per disabili, ecc.);

• criteri di ottimizzazione (es. solo percorsi ciclabili, percorsi accessibili, ecc.).

Costituirà elemento di merito l’adozione di un’architettura software modulare che preveda l’aggiunta di tali funzionalità tramite plug-in sviluppabili da soggetti anche successivamente coinvolti dalla pubblica amministrazione. Il sistema dovrà inoltre disporre di interfacce software che permettano in futuro l’interoperabilità con sistemi analoghi, che dovessero essere resi disponibili in futuro da altri soggetti o enti operanti sul territorio. Tali interfacce dovranno in particolare essere progettate con l’obiettivo di permettere sia l'esposizione dei dati disponibili, sia l'acquisizione dei dati provenienti dall'esterno. Si favorirà in questo modo la possibilità di estendere il sistema utilizzando ulteriori modalità di trasporto. Si dovrà quindi prevedere meccanismi di rappresentazione e scambio dei dati basati su formati e protocolli.

Nome Coincidenze autobus, con tempi di attesa

Descrizione Permette all’utente di conoscere i tempi di attesa degli autobus in passaggio dalle fermate in prossimità della propria posizione.

Scenario d’uso

Attraverso le informazioni specificate in fase di profilazione, il sistema conosce le linee e gli orari di interesse dell’utente. A seconda di queste informazioni e della posizione dell’utente stesso, il sistema determina se l’utente si trova in prossimità di una fermata in cui transita una o più linee d’interesse per l’utente. Quando l’utente accede alla sezione dedicata ai propri itinerari, la pagina proposta presenta automaticamente i tempi di attesa degli autobus preferiti. Vengono segnalati i prossimi mezzi in arrivo, ciascuno con il proprio tempo di attesa stimato, e il tempo stimato

2 Decreto ministeriale 8 luglio 2005. Requisiti tecnici e i diversi livelli per l'accessibilità agli strumenti informatici. Disponibile all’indirizzo http://www.pubbliaccesso.it/normative/DM080705-A.htm

Pagina 84

di percorrenza per l’itinerario da compiere. Nel caso in cui l’utente non sia localizzato, il servizio presenterà una interfaccia standard di interrogazione per il recupero dei tempi di attesa delle linee a cui l’utente è interessato.

Nome Bollettino del traffico

Descrizione Permette all’utente di conoscere la situazione del traffico nell’area urbana e extraurbana

Scenario d’uso

L’utente in mobilità può interrogare il sistema per conoscere la situazione del traffico nell’area urbana e extraurbana in prossimità della città. Il sistema mantiene uno stato dettagliato della situazione del traffico lungo gli assi viari in ingresso/uscita alla città, con particolare riferimento alla SGC FIPILI che è dotata di un proprio sistema informativo. Oltre alla tradizionale modalità di consultazione su richiesta, l’utente viene notificato (tramite Email o sms) in modo automatico di particolari situazioni di anormalità o congestione lungo le direttrici che è solito prendere. Gli orari e le modalità di notifica vengono specificate dall’utente in fase di profilazione, insieme alle direttrici per cui si decide di ricevere il servizio.

Nome Rivendite titoli

Descrizione Permette all’utente di consultare le rivendite di titoli di viaggio più vicine alla sua posizione attuale.

Scenario d’uso

L’utente in mobilità ha necessità di acquistare dei titoli di viaggio per uno dei mezzi di trasporto pubblico cittadino (tram, autobus, treni). Il sistema fa uso delle funzionalità di localizzazione dell’infrastruttura wireless, e propone all’utente l’elenco delle rivendite a lui più vicine, organizzate per tipologia di mezzo pubblico. Le informazioni vengono proposte sia in forma testuale che su mappa.

Nome Orari e mappa ZTL

Descrizione Permette all’utente di consultare le correnti limitazioni al traffico dovute alla ZTL

Scenario d’uso

Il sistema fornisce la rappresentazione di orari e varchi attivi della ZTL, in forma testuale e cartografica. L’utente ha la possibilità di selezionare un varco di interesse, e consultare ulteriori dettagli relativi alle limitazioni che interessano quel varco. Il sistema fornisce anche una rappresentazione cartografica della ZTL.

Nome Stato parcheggi cittadini

Pagina 85

Descrizione Permette all’utente di conoscere il numero di posti auto disponibili nei parcheggi cittadini.

Scenario d’uso

Si tratta di un servizio rivolto principalmente agli automobilisti, che sono già in viaggio o che si accingono a prendere la propria auto per spostarsi nel tessuto urbano. Per questo motivo, la fruizione del servizio dovrà essere possibile sia dal portale web che dal portale mobile, anche in situazioni in cui il collegamento al servizio avviene tramite un’infrastruttura diversa da quella wireless della tramvia.

Il sistema dovrà fornire all’utente la collocazione geografica (testuale e su mappa) dei parcheggi cittadini e dei parcheggi scambiatori. Dovranno inoltre essere previste notifiche basate sul profilo utente, inviabili tramite e-mail o sms a orari predefiniti, attraverso le quali l’utente è automaticamente avvertito dello stato dei parcheggi di interesse. Il sistema dovrà eventualmente proporre parcheggi alternativi, nel caso quelli usualmente utilizzati risultino pieni.

Per quanto riguarda i parcheggi scambiatori, il sistema dovrà indicare all’utente quali sono le alternative a disposizione per raggiungere la destinazione prescelta, utilizzando le varie modalità di trasporto pubblico.

Nome Stato car sharing

Descrizione Permette all’utente di accedere al servizio car sharing

Scenario d’uso

Tramite questo servizio l’utente in mobilità sarà in grado di:

• Accedere alle informazioni generali del servizio car sharing di Firenze (condizioni d’uso, tariffe, ecc.)

• Consultare la mappa dei parcheggi car sharing cittadini

Dovrà inoltre essere prevista una interfaccia automatica, basata su web service o similari, che possa essere utilizzata per fornire al sistema indicazioni dinamiche circa la disponibilità effettiva delle vetture.

Nome Consultazione ordinanze

Descrizione Permette all’utente di consultare e ricercare le ordinanze attive sul territorio provinciale e comunale.

Scenario d’uso

La Provincia e il Comune di Firenze dispongono di sistemi informativi per la gestione delle ordinanze sul traffico relative alle strade cittadine e provinciali. I dati delle ordinanze sono esposti dalle interfacce descritte nelle sezioni 3.2.7 e 3.2.8. Il servizio richiesto prevede di fornire agli utenti della piattaforma di infomobilità le informazioni principali riguardo le limitazioni al traffico e i cantieri cittadini. Dovrà essere possibile per l’utente ricevere informazioni di interesse sul proprio terminale relative a strade o zone di interesse indicate in fase di profilazione. Data la mole di

Pagina 86

dati potenzialmente presentabili, l’enfasi dal punto di vista dell’interfaccia utente dovrà essere posta sulla possibilità di eseguire semplici interrogazioni (es., relative alla presenza di limitazioni su una certa strada a una certa data), in modo veloce e intuitivo.

Nome Informazioni generali

Descrizione Permette all’utente di accedere a news di carattere generale (notiziari, meteo, sport, ecc.)

Scenario d’uso

Il sistema raccoglie e pubblica sul portale mobile dei servizi, notizie di attualità, economia, sport, ecc.. Le notizie vengono agreggate per tema, e se necessario adattate per la pubblicazione su dispositivo mobile. L’utente in mobilità può accedere alle notizie dal proprio terminale, anche senza essersi autenticato tramite login e password. In questo caso, il sistema funziona da proxy informativo per l’utente senza connessione diretta a Internet, ma solo alla intranet locale all’infrastruttura wireless. Le notizie saranno acquisite attraverso un feed RSS da uno o più provider, e riportate sulle pagine dell’applicazione di infomobilità.

Nome Integrazione servizi di mappa

Descrizione Utilizza un servizio di mappa per creare la visualizzazione cartografica delle informazioni.

Scenario d’uso

I servizi di mappa costituiscono uno strumento sempre più diffuso per la diffusione di informazioni geolocalizzate. Grazie alla semplicità d’uso, questi strumenti favoriscono l’adozione di servizi innovativi da parte degli utenti, che si ritrovano una interfaccia intuitiva, e soprattutto uniforme rispetto a diversi servizi. Inoltre, tale interfaccia è spesso disponibile sia per dispositivi mobili, che per terminali tradizionali.

Molti dei servizi descritti in questa sezione, prevedono la comunicazione di informazioni in forma di mappa: percorsi dei mezzi pubblici, collocazione fermate, percorsi suggeriti, ecc. Si richiede di fornire all’utente queste informazioni in termini di “layer” su una mappa del territorio urbano, che l’utente può attivare o meno a seconda delle proprie necessità. Il servizio di mappa dovrà essere disponibile anche per gli utenti che non hanno un accesso diretto a Internet, perchè non autenticati.

Nome Contatti e segnalazioni

Descrizione Servizi di utilità

Scenario d’uso

Il sistema permette di accedere, sia dal portale web che dal portale mobile, a una serie di servizi di utilità generale di tipo statico o interattivo, quali:

• Contatti e numeri utili

Pagina 87

• Help desk 055055

• Invio segnalazioni/reclami

• Segnalazione oggetti smarriti

• Domande frequenti

• Opinioni/sondaggi

• Dati ambientali raccolti dalle stazioni di monitoraggio Queste informazioni saranno inserite dagli operatori del sistema attraverso l’interfaccia di gestione specificata nel paragrafo § 6.9.

6.9 Gestione del sistema

Tutti gli applicativi ISM dovranno essere dotati delle apposite interfacce operatore per la configurazione e la gestione dei servizi. Nell’ambito dell’architettura specificata, si suggerisce che tale interfaccia di gestione venga realizzata in tecnologia web e accessibile con un normale browser. Dovrà essere possibile la gestione di operatori con profili di accesso differenti, in modo da abilitare o disabilitare alcune funzionalità a seconda delle credenziali di accesso. La gestione degli operatori e delle credenziali sarà separata e indipendente rispetto a quella prevista per gli utenti in mobilità. Dovrà inoltre essere possibile per gli operatori di attivare e disattivare l’erogazione di un particolare servizio agli utenti, in modo dinamico e senza necessità di procedure di installazione o riconfigurazione del sistema. Oltre alla configurazione dei singoli servizi, l’interfaccia di gestione dovrà prevedere la possibilità di inserire contenuti informativi di tipo generico.

6.10 Interfacce del sistema

Gli applicativi ISM dovranno prevedere l’interfacciamento diretto con il Supervisore e con altri sistemi, sia in ingresso che in uscita. Le interfacce previste sono evidenziate in Figura 4, e descritte brevemente in Tabella 1. Per una descrizione dettagliata dei sistemi da interfacciare si rimanda alla sezione 3.2. Indipendentemente dal protocollo e dalle tecnologie utilizzate, tutte le interfacce dovranno essere progettate e realizzate in modo da non causare degradazioni del servizio fornito dai sistemi connessi (es. a causa di politiche di interrogazione troppo frequenti).

Pagina 88

Figura 4: Architettura generale e interfacce del sistema di infomobilità. Le interfacce di ingresso (acquisizione dati) sono a sinistra nella figura, quelle di uscita (pubblicazione) a destra.

Interfaccia Protocollo Descrizione

Gestione applicativi

HTTP Gestione degli applicativi ISM tramite un browser web.

News feeder RSS, HTTP Acquisizione news tematiche (attualità, cronaca, sport, ecc.).

Map server HTTP/Web Service Acquisizione dati cartografici.

Gestione ordinanze

HTTP/Web Service Acquisizione degli atti relativi al traffico attivi sul territorio

Infrastruttura wireless

RADIUS/Web Service Acquisizione dati di autenticazione e di localizzazione degli utenti

AVM Web Service Acquisizione dati di passaggio autobus e tempi di attesa

Supervisore RDBMS/SQL Acquisizione dati traffico

Terminali utenti HTTP, SMTP, SMS.. Comunicazione informazioni agli utenti

Dispositivi i.a.p Web Service Comunicazione informazioni ai dispositivi di Informazione al Pubblico

Tabella 1: interfacce degli applicativi ISM

Per quanto riguarda l’interfaccia con il Supervisore, si prevede di acquisire i dati direttamente dal database che sarà gestito e alimentato dal Supervisore stesso. Si richiede comunque che l’architettura prescelta preveda la possibilità di remotizzare

Pagina 89

il modulo di acquisizione dati, separandolo dal core degli applicativi ISM. Questo si potrebbe rendere necessario nel caso in cui per esempio il database del Supervisore e gli applicativi ISM vengano dispiegati in locazioni geograficamente differenti.

6.11 Interfaccia web

Per quanto riguarda la progettazione grafica delle pagine del portale web, l’aggiudicatario dovrà presentare un progetto grafico del sito che sarà subordinato ad accettazione da parte del committente; questo vale sia per le pagine dell’interfaccia standard che per quelle della versione per dispositivi mobili. Nel cronoprogramma deve essere esplicitamente prevista anche una fase in cui il progetto grafico dell’interfaccia degli applicativi ISM viene concordata e approvata da parte del committente. Si richiede inoltre che anche le fasi di analisi e progettazione dell’interfaccia siano svolte a stretto contatto con il Committente. Il layout grafico e l’organizzazione dell’informazione dovranno essere progettati secondo criteri riconosciuti di usabilità e architettura dell’informazione. Accanto alle sezioni delle pagine che ospitano le effettive form di inserimento dati e presentazione dei risultati dei servizi descritti, l’interfaccia dovrà prevedere un layout che permetta di ospitare contenuti informativi di tipo generico inseriti dal gestore del sito tramite l’interfaccia di gestione. Il sito dovrà inoltre recepire e soddisfare i requisiti minimi specificati dalle normative vigenti in tema di accessibilità, in particolare dal decreto ministeriale del 8 luglio 2005. Per i criteri di applicazione della normativa, il proponente potrà fare riferimento alla metodologia presente nel Decreto ministeriale 8 luglio 2005. “Requisiti tecnici e i diversi livelli per l'accessibilità agli strumenti informatici”3. Si precisa comunque che il livello di rispondenza ai requisiti tecnici previsti dalla normativa sarà concordato in fase di definizione del progetto, di concerto tra l’aggiudicatario e i responsabili di progetto della Provincia.

7 Architettura di sistema

7.1 Architettura logica di sistema

Sulla base delle funzioni richieste, una possibile architettura logica del sistema potrebbe essere la seguente:

• Front-end server: gestisce l’interfaccia con i sistemi esterni che acquisiscono i dati, li elabora e li memorizza sul data base; Questo modulo si interfaccerà con i sistemi esterni secondo le specifiche fornite in questo documento (cap. 3);

• Data base server: gestisce i processi ed i servizi relativi alla base di dati e contiene la base di dati stessa secondo le modalità sopra descritte;

• Map server: gestisce le elaborazioni relative alla cartografia (generazione mappe, richiesta di dati georeferenziati, etc) e le funzioni dell’interfaccia operatore relative alle funzioni cartografiche (zoom, pan, etc.);

3 disponibile all’indirizzo http://www.pubbliaccesso.it/normative/DM080705-A.htm

Pagina 90

• Processing server: gestisce tutte le funzionalità del Supervisore e le elaborazioni richieste;

• Infomobility server: gestisce le funzioni di infomobilità come descritte in sezione 6.

• Web server: gestisce le comunicazioni web secondo le strategie definite dall’infomobility server

• Interface server: gestisce le interfacce con gli operatori del sistema. Il fornitore non è vincolato a questa architettura logica e può proporne un’altra alternativa, motivandola adeguatamente.

7.2 Architettura hardware

Dal punto di vista hardware si richiede la fornitura di tutti i componenti e gli apparati necessari a supportare le funzionalità software descritte e la mole dei dati che occorre trattare. Sono comprese nella fornitura hardware gli apparati di visualizzazione, come più oltre descritto, e gli eventuali apparati di rete per connettere il sistema al resto ella rete (così come descritto nell’apposito capitolo ad essa dedicato). Sarà a carico del fornitore l’installazione dell’hardware nei locali messi a disposizione e già cablati (premettendo sin d’ora che non necessariamente le postazioni operatore ed i sistemi server e di archiviazioni saranno posizionati in locali contigui, e che quindi il collegamento fra questi potrà essere realizzato anche tramite una rete geografica). In generale l’architettura proposta dovrà prevedere macchine server dedicate alle specifiche applicazioni e connesse tra di loro in rete locale. Una delle macchine potrà essere dedicata alla gestione delle basi dati, con una adeguata dotazione di memoria di massa. Il sistema deve prevedere un server apposito per l’applicazione di infomobilità, ed un web server che ospiti il sito web. Tale server dovrà poter essere accessibile sa Internet garantendo tutti gli adeguati livelli di sicurezza. Sarà compito dell’offerente definire i componenti hardware e software necessari a tale scopo. Oltre ai server di sistema, si dovranno prevedere stazioni operatore; il sistema dovrà avere caratteristiche di espandibilità in tal senso. Dovranno pertanto potersi aggiungere e togliere stazioni operatore mediante semplici operazioni di configurazione del sistema garantite via software. Il sistema dovrà premettere di collegare anche stazioni operatore remote senza degrado delle prestazioni (ferma restando la disponibilità di adeguata banda sulla connessione). Il sistema dovrà inoltre prevedere una specifica stazione dedicata all’amministrazione di sistema e al monitoraggio dello stesso. Dovranno essere infine previsti grandi schermi per la visualizzazione condivisa da parte degli operatori. Al momento attuale non è prevista l’installazione di un vidiwall. Il sistema deve però essere concepito in modo da permettere un’agevole integrazione di un sistema vidiwall; in particolare dovranno essere previsti meccanismi che possano rendere disponibili in modo agevole informazioni grafiche, immagini, sinottici e quant’altro visualizzabile sui monitor del sistema al controller esterno del vidiwall per la composizione della matrice di visualizzazione. Globalmente quindi la fornitura dovrà prevedere i seguenti componenti:

Pagina 91

• Application server di sistema in numero adeguato alla soluzione proposta

• Data server dotato di dischi per la memorizzazione e di unità per il backup dei dati

• Web server

• Dispositivi di rete per il collegamento con la rete IP e la gestione delle comunicazioni con i sistemi esterni connessi

• 3 stazioni operatore costituite da PC con monitor triplo

• 3 monitor LCD 40”

• 1 stazione per amministrazione di sistema costituita da PC con monitor duale Saranno privilegiate architetture che presentino caratteristiche di:

• Facile espandibilità in termini di: o Numero di stazioni operatore (anche remote) o Memoria di massa o Capacità elaborativa in funzione delle moli di dati e delle frequenze di

operazione del sistema L’architettura inoltre dovrà essere progettata in modo da garantire la massima sicurezza ed integrità dei dati, il loro backup periodico su adeguati supporti. Tutto l’hardware dovrà essere di primario produttore e di qualità industriale. In ogni caso le macchine server dovranno essere contenute in rack e possedere almeno le seguenti caratteristiche:

• Processori Quad Core 2.1 GHz

• Memoria centrale 4 GB

• Dischi SAS 10K RPM

• Schede di rete Ethernet Gigabit

• Controller RAID

• Alimentazione ridondata

• Unità ottica DVD-ROM drive SATA I server saranno contenuti in unità rack 24/42 U completi di condizionamento, UPS e monitor 17”, tastiera e mouse con switch console per la connessione ai server contenuti. Le postazioni operatore dovranno possedere almeno le seguenti caratteristiche:

o Processor Quad Core Intel Xeon X5482 (3.20GHz,2X6M L2,1600) o Scheda video, Quad Monitor DVI Capable o Memoria centrale 6GB, DDR2 SDRAM FBD, 800MHz, ECC o Disco 350 GB SATA, 7.200 RPM o Tre monitor:

� Un monitor centrale 30” Ultra Sharp 2560x 1600 pixel � Due monitor 20” Ultra Sharp 1600x 1200 pixel

o Tastiera o mouse wireless o unità DVD

La postazione di memorizzazione e archiviazione dovrà possedere almeno le seguenti caratteristiche:

o Processor Quad Core Intel Xeon X5482 (3.20GHz,2X6M L2,1600) o Scheda video Quad Monitor DVI Capable

Pagina 92

o Memoria centrale 1GB, DDR2 SDRAM FBD, 800MHz, ECC o Disco 250 GB SATA 3.0Gb/s,7200 RPM o Due monitor 27” Ultra Sharp 2560x 1600 pixel o Tastiera o mouse wireless o unità DVD

7.3 Software di base e strumenti software di sviluppo e funzionamento

Farà parte della fornitura anche tutta la dotazione di software di base, application tools e altri packages necessari per l’implementazione ed il funzionamento operativo del sistema. Ogni eventuale licenza per questi software dovrà essere inclusa nella fornitura e dovrà garantirne l’utilizzo senza ulteriori aggravi per le Amministrazioni. L’offerente potrà proporre le proprie soluzioni di software di base ed applicativi. Sarà comunque considerato come titolo di merito l’impiego per l’ambiente di sviluppo e di funzionamento del software di prodotti facilmente reperibili, non proprietari, che utilizzino standard di mercato, e che siano eventualmente Free/Open Source. E’ esplicitamente richiesto che la soluzione proposta non contenga alcun prodotto software e/o hardware destinato a gestire i servizi rivolti all’utenza finale i cui termini di licenza prevedano, in qualsiasi modo, la dipendenza dal numero di utenti finali che utilizzano i servizi erogati dalla piattaforma (o altri servizi a loro volta basati su di essa), ovvero le licenze devono essere illimitate rispetto al numero di utenti. Parimenti le licenze legate al Supervisore devono essere illimitate rispetto al numero di utenti e/o di dispositivi fisici collegati al Sistema (siano essi client, accessi web, postazioni operatore in generale, dispositivi di acquisizione dati sul campo e qualsivoglia altro dispositivo possa essere collegato al sistema). Per il sistema operativo, qualora si scelga una piattaforma Windows, si dovrà prevedere Windows Advanced Server nella versione più attuale. Sarà richiesta la certificazione da parte degli sviluppatori della compatibilità delle applicazioni sia con la versione usata nel progetto sia con le versioni future. Qualora si scelga una piattaforma Linux, si deve prevedere preferibilmente la distribuzione Red Hat. I data base dovranno essere a standard SQL, con preferenza Oracle e MySQL nel caso di prodotto open-source. Per la fornitura di servizi web-based saranno considerate di maggior interesse soluzioni che siano basate a livello architetturale su tecnologie selezionate nell’ambito degli standard di fatto attualmente presenti sul mercato. Tali tecnologie dovranno garantire il soddisfacimento dei requisiti architetturali, prestazionali, funzionali tipici di applicazioni di scala enterprise, con riferimento ad esempio a criteri di affidabilità, scalabilità, manutenibilità, adeguatezza ad un contesto distribuito, ecc. I sistemi di cartografia dovranno poter supportare i più comuni standard di rappresentazione in uso.

Pagina 93

7.4 Rete di comunicazione

Per la stessa natura del Supervisore e della piattaforma di infomobilità, esse dovranno operare in un ambiente geograficamente distribuito. Il Supervisore dovrà quindi essere concepito per lavorare in ambiente distribuito, con apparati e sistemi collegati sia su LAN che su WAN, cui dovrà poter accedere sia mediante connessioni su rete fissa che mobile o wireless, agevolmente riconfigurabili. Parte integrante del Sistema dovrà quindi essere una rete geografica che colleghi tra di loro i vari sottosistemi, permettendo lo scambio di dati in tempo reale (intendendosi come tale le frequenze necessarie per l’acquisizione ed il dispatching delle informazioni dai vari sottosistemi collegati). L’architettura di rete si baserà sulla rete comunale in fibra ottica FiNet; essa si collega inoltre alla rete della Provincia di Firenze e a quella di alcuni soggetti aziendali coinvolti nel progetto. Su tali collegamenti fisici sarà configurata una VPN progettata ed implementata a cura del Comune e della Provincia di Firenze. Al fornitore sarà quindi messa a disposizione una rete configurata che collegherà tutti i sottosistemi che il Supervisore e la piattaforma di infomobilità dovranno interfacciare. Al fornitore sarà chiesto di includere nella fornitura solo gli apparati di rete necessari a interfacciare la architettura centrale del sistema e le postazioni operatore con la rete locale presente nel sito in cui questi saranno collocati . La rete che sarà configurata sarà vista dal fornitore come una rete IP che garantisce gli adeguati standard di sicurezza negli accessi ai sistemi remoti. La connettività locale resa disponibile presso i vari siti sarà di tipo Gigabit Ethernet.

8 Sviluppi futuri Il Sistema dovrà avere caratteristiche architetturali, prestazionali e funzionali tali da consentirne lo sviluppo e la valorizzazione anche in nuovi scenari – ulteriori rispetto a quelli descritti nel presente documento. In particolare si ritiene che un tale Sistema possa rappresentare la premessa – e quindi lo strumento abilitante – per la realizzazione di innovative forme di gestione nei diversi ambiti di intervento sul territorio da parte delle PP.AA. locali e dei soggetti ad essa collegate (es. aziende partecipate, aziende del servizio pubblico locale, ecc.). In tale prospettiva risulta determinante anche la possibilità di realizzare analisi ex post dei dati (e quindi l’analisi di pattern pregressi e di dati storici), anche al fine di effettuare simulazioni tattiche per l’identificazione e la classificazione di scenari di criticità (es. incidenti, manifestazioni, ecc.); questo consentirebbe, fra l’altro, la riconfigurazione – anche in tempo reale (o quasi) – dei percorsi delle diverse flotte (es. trasporto pubblico collettivo, inclusi pullman turistici; mezzi di raccolta e movimentazione rifiuti; taxi; polizie locali; sistema dell’emergenza) basandosi sull’attivazione di scenari tattici pre-configurati. L’attivazione degli scenari operativi di “contingency” dovrebbe quindi consentire da un lato il regolare svolgimento dei diversi servizi anche in condizioni di criticità (routing dinamico) e dall’altro contribuire a ridurre le criticità che affliggono il sistema della mobilità.

Pagina 94

Pertanto, si ipotizza che i dati elaborati dal Sistema possano essere messi a disposizione dei diversi attori, ed in particolare ai relativi uffici competenti sulla programmazione di esercizio ed alle relative sale controllo. Relativamente ai possibili sviluppi futuri in questo senso si informa che le aziende del territorio che si occupano della raccolta rifiuti e dello spazzamento delle strade hanno avviato il percorso che le porterà a dotarsi di un sistema AVM. Si evidenzia che oltre che per supportare una efficace ed efficiente gestione dei servizi, gli ulteriori sviluppi prospettati per il Sistema possono contribuire ad incrementare il livello di informazione nei confronti dei cittadini. Ad esempio, con riferimento ai servizi di igiene urbana, questo potrebbe tradursi in informazioni relative agli orari dello spazzamento delle strade, alla localizzazione dei centri di raccolta dei rifiuti differenziati, così come alla localizzazione ed agli orari di svuotamento delle campane interrate.

9 Livelli di sicurezza e politiche di accesso al sistema Il sistema di supervisione da realizzare dovrà connettersi via rete ad una molteplicità di sistemi esterni attraverso connessioni in rete sia per acquisire i dati di interesse che per inviare richieste o informazioni. Inoltre potrà essere acceduto sia localmente che da remoto da utenti aventi diversi profili e privilegi. Il sistema si appoggerà principalmente sulla rete FiNet e dovrà adeguarsi alle procedure e modalità di interfacciamento in uso. Dovranno essere previsti adeguati criteri di sicurezza delle comunicazioni analizzando per ciascun singolo sistema la soluzione idonea in dipedenza del tipo di collegamento e se trattasi di sistema inserito gestito dall’amministrazione o da ditte esterne. Gli utenti remoti accederanno al sistema attraverso interfaccia WEB. Si dovranno prevedere modalità di accredito e di profilazione che permettano l’accesso controllato ai soli dati consentiti e di interesse per ciascun profilo utente.

10 Affidabilità Il sistema, pur non richiedendo caratteristiche di faut tolerance, deve essere progettato per offrire caratteristiche di alta affidabilità e disponibilità. Il sistema in esercizio sarà operativo e presidiato 24/24 ore, e quindi l’indice di disponibilità deve essere superiore al 99,5%. Il fornitore deve dichiarare l’indice di disponibilità del sistema fornito illustrando le scelte architetturali, sistemistiche e organizzative per raggiungerlo. Saranno valutate favorevolmente le soluzioni che si integrino con architetture e prodotti in uso per le infrastrutture ICT della Provincia e del Comune di Firenze, con particolare riferimento al tema dell’affidabilità e della virtualizzazione. A tal proposito si rende noto che presso entrambi gli Enti sono presenti infrastrutture di virtualizzazione basate su VmWare. Particolare attenzione deve essere posta per garantire la integrità e completezza dei dati predisponendo le opportune ridondanze e bakup. Dovranno essere debitamente illustrate le architetture di memorizzazione indicando i livelli di RAID previsti per le unità dove risiederanno il S.O e i programmi applicativi e quelle di archiviazione dati, contenenti i DataBase e gli archivi storici. Inoltre devono essere previste opportune procedure di backup periodiche che si appoggeranno su supporti hardware e software da prevedere e descrivere nella fornitura. Da un punto di vista implementativo deve essere considerata

Pagina 95

anche la completezza dei dati a fronte di cadute di connessione con le fonti esterne, prevedendo procedure di riallineamento e recupero dei dati persi.

11 Specifiche prestazionali del sistema Il sistema dovrà al momento attuale operare nel contesto descritto al capitolo 3 del presente capitolato. Esso dovrà comunque essere in grado fin dal momento della sua installazione di soddisfare almeno le seguenti specifiche prestazionali.

• Periodo di acquisizione dati dai sistemi periferici < 1 min.

• Periodo di stima dello stato del traffico < 5 min.

• Tempo di latenza tra la registrazione in memoria di un cambio di stato e sua presentazione su postazione operatore < 1 sec.

• Capacità di gestire nei tempi sopra definiti acquisizione dati da almeno 5000 sezioni di misura (inclusi gli archi su cui insistono FCD) , di cui 500 classificate.

• Capacità di considerare almeno 500 impianti semaforici e 200 pannelli di segnalazione

• Capacità di mantenere in linea dati per almeno 2 anni

• Capacità degli archivi dati per almeno 10 anni

• Capacità di definire almeno 10 profili operatori diversi cui associare diverse viste dei dati del Supervisore.

• Capacità di gestire senza degrado delle prestazioni almeno 500 utenti contemporanei che utilizzano i servizi di infomobilità.

• Capacità degli applicativi ISM di garantire un tempo massimo di risposta (invio al programma di navigazione client di una pagina html completa) inferiore a 5 secondi per pagina, al netto di eventuali ritardi dovuti alla congestione o latenza delle linee di trasmissione.

12 Configurazione iniziale di sistema La fornitura oggetto dell’appalto è da intendersi in opera, e quindi fa parte integrante della fornitura la configurazione iniziale del sistema che dovrà essere personalizzato e inizializzato in tutti i suoi componenti ed i suoi aspetti per poter procedere all’avvio del funzionamento operativo. L’Amministrazione potrà richiedere che alla fase di configurazione di sistema possa partecipare proprio personale che affiancherà il personale del fornitore nell’ottica del “training on the job”. L’Amministrazione metterà a disposizione tutti i dati e le informazioni disponibili per supportare questa fase, ma sarà esclusiva responsabilità del fornitore procurarsi dati eventualmente mancanti. Dalle descrizioni fornite nel presente documento l’offerente può inferire i dati a disposizione. A titolo puramente esemplificativo elenchiamo le categorie di dati che saranno messi a disposizione del fornitore:

• Grafo stradale e informazioni correlate (come sopra descritto);

• Cartografia della CTR (come sopra descritto);

Pagina 96

• Informazioni di configurazione dei sistemi di acquisizione dati ed in generale dei sistemi da collegare con il Supervisore;

• Matrici OD esistenti;

• Profili dei diritti degli operatori. Ove i dispositivi periferici non siano georiferiti sarà onere del fornitore procedere all’acquisizione delle loro coordinate secondo gli standard necessari. In ogni caso il reperimento di qualunque dato o informazione necessaria al funzionamento del sistema ulteriore rispetto a quelli dichiarati come disponibili in questo capitolato è ad esclusivo carico dell’offerente, fermo restando che l’Amministrazione offrirà per quanto possibile la propria collaborazione.

13 Verifica, avvio e collaudo del sistema Il Sistema deve essere verificato prima di essere installato. Le verifiche in fabbrica riguarderanno le funzionalità base, partendo dalla gestione della base cartografica, dagli elementi georeferenziati configurati nel sistema e dal DataBase del sistema e da moduli ad hoc che simulino l’acquisizione dei vari dati (dati di traffico, flussi video, dati di riempimento, stato dei pannelli, ecc.) che il fornitore eventualmente può predisporre. Nella fase di installazione dovranno essere verificati i moduli e le procedure di interfaccia ai vari sistemi esterni collegati. Successivamente, dopo una fase di calibrazione e apprendimento dei parametri di traffico degli algoritmi di predizione, il sistema verrà collaudato nella sua interezza. Il fornitore dovrà predisporre accanto al sistema target di un sistema minimo di sviluppo in cui le patch e le modifiche che si renderanno necessarie possono essere testate prima di essere messe in linea.

14 Formazione e supporto Il Fornitore dovrà supportare l’Amministrazione nella fase di avvio del servizio operativo in tutto il periodo che precede il collaudo finale ed assisterla durante la successiva fase di pre-esercizio, anche mediante addestramento in affiancamento del personale addetto. In particolare il fornitore dovrà provvedere ad effettuare le seguenti prestazioni:

• FORMAZIONE: somministrazione di corsi di formazione e di addestramento agli operatori che saranno individuati dalla Provincia e dal Comune di Firenze. Si dovranno prevedere almeno i seguenti differenti corsi dedicati alle relative figure professionali:

o corso per operatori del sistema di supervisione, destinato a personale con una formazione di base in merito ai problemi della gestione del traffico, destinati a operare sul sistema, con l’obiettivo di fornire loro tutte le conoscenze delle potenzialità di impiego del Supervisore;

o corso per operatori della piattaforma di infomobilità, destinato a personale con la stessa preparazione di base, ma destinato principalmente alla gestione della piattaforma di infomobilità;

o corso per amministratori di sistema, secondo le usuali procedure per questa figura professionale.

Pagina 97

Si richiede all’offerente di compilare una proposta esauriente e dettagliata dell’offerta sul tema della formazione e dell’addestramento indicando la durata e l’articolazione del percorso formativo, il numero di partecipanti massimo, la tipologia di insegnamento somministrato, il materiale didattico fornito, le eventuali verifiche di apprendimento. E’ da intendersi compresa nella fornitura almeno un’edizione per ciascuno dei corsi suddetti, per un numero di partecipanti non inferiore a 12.

• SUPPORTO NELLA FASE DI PRE-ESERCIZIO: assistenza agli operatori per un periodo di tempo corrispondente con l’avvio del funzionamento operativo del sistema (periodo di pre-esercizio), anche mediante addestramento in affiancamento, con funzione di addestramento sul lavoro e di supporto alla soluzione delle varie problematiche che si dovessero presentare. Sarà parte integrante del supporto da fornire in questa fase anche il lavoro di calibrazione del Sistema per tutte quelle funzionalità (principalmente di supervisione) che richiedano un periodo di osservazione e un affinamento parametrico o algoritmico in funzione delle reali condizioni di operatività. L’offerente potrà formulare la propria offerta in tal senso in funzione del tempo che egli riterrà necessario in base alla sua esperienza per mettere a regime il funzionamento del sistema, precisando al meglio la durata e contenuto e limiti del supporto fornito durante l’affiancamento.

15 Manutenzione in garanzia Il Fornitore è tenuto a proprio carico alla buona conservazione delle opere eseguite sino alla data di accettazione del sistema a termine del collaudo. Il compenso per tale prestazione si intende compreso nel corrispettivo previsto per l’appalto. Il periodo di garanzia dovrà essere di almeno tre anni “on site”e dovrà comprendere materiali e manodopera. Il periodo di copertura della garanzia compresa nella fornitura decorrerà dalla data di accettazione del sistema, cioè con il positivo esito delle prove di collaudo. Un eventuale esito negativo del collaudo interromperà il periodo di garanzia, fino al ristabilimento del corretto funzionamento del sistema. In ogni caso l’offerente dovrà assicurare nel periodo di garanzia gli interventi preventivi e la sostituzione immediata di ogni componente o apparecchiatura che risultasse difettosa, e di tutte le eventuali altre parti che risultassero danneggiate dal malfunzionamento di un qualunque componente del sistema, senza onere alcuno per la Provincia, restando esclusi solo gli atti di vandalismo o eventi calamitosi. La garanzia dovrà coprire eventuali errori o vulnerabilità del software che dovessero essere rilevati anche successivamente al collaudo e per tutto il periodo di garanzia. Sono inoltre incluse nella manutenzione in garanzia le modifiche al software che si rendessero necessarie per garantire la sicurezza del sistema a fronte di minacce che dovessero rendersi evidenti nel corso della validità del contratto di manutenzione stesso. Durante il periodo di garanzia tutte le spese di trasporto e/o spedizione di materiale a necessario per la manutenzione del sistema, nonché le spese di trasferta sono a carico del fornitore.

Pagina 98

Durante il periodo di garanzia dovranno essere effettuate tutte le operazioni di manutenzione preventiva e/o correttiva che il Fornitore riterrà necessarie ad assicurare il corretto funzionamento del sistema. I termini di garanzia dovranno necessariamente prevedere anche il rilascio – senza oneri aggiuntivi per il Committente – di eventuali aggiornamenti e upgrade software del sistema che si dovessero rendere necessari per far fronte ad anomalie di qualsiasi tipo (es. errori negli algoritmi, vulnerabilità in termini di sicurezza, ecc.) riscontrate nell’uso e/o nel funzionamento del Sistema, e che dovranno essere eseguiti secondo i programmi di rinnovamento dell’azienda fornitrice, e dell’hardware di sistema, che dovrà essere sostituito in occasione di guasti, di manutenzione preventiva o per obsolescenza. Al fine di consentire al Committente l’accesso al servizio di assistenza, il Fornitore affidatario dovrà indicare un numero di telefono, un numero di fax, un indirizzo di posta elettronica ed eventualmente un sito web, ai quali il Committente potrà inoltrare richieste di intervento e – in generale – richieste di assistenza relativamente alla soluzione fornita. Inoltre, in sede di gara l’offerente dovrà specificare chiaramente tutte le condizioni di garanzia migliorative che potranno costituire elemento di merito, rispettando quanto specificato nel presente capitolato quale requisito minimale, nonché le modalità con le quali vengono gestite le richieste di intervento e di assistenza in genere (es. CRM, issue tracking, ecc.). Il Fornitore è inoltre tenuto ad erogare il servizio di manutenzione in garanzia avvalendosi di una soluzione di teleassistenza computerizzato, collegato in sicurezza al sistema in oggetto con la possibilità di intervenire da remoto sul Sistema. Qualora il Committente decidesse di attivare il servizio di manutenzione ordinaria post-garanzia (opzionale), questa dovrà essere sarà erogata con le stesse modalità ed alle stesse condizioni previste dal Capitolato e dall’Offerta Tecnica presentata in sede di gara, ed alle condizioni economiche riportate nell’Offerta Economica. I canoni annuali per la manutenzione indicati nell’Offerta Economica non potranno essere soggetti ad aumento – fatta salva la rivalutazione annuale in base agli indici ISTAT (con decorrenza dalla scadenza del periodo garanzia).

15.1 Manutenzione ordinaria preventiva

La manutenzione ordinaria comprende gli interventi atti a contenere il normale degrado d’uso degli impianti. Il servizio deve prevedere ispezioni periodiche direttamente sul sito allo scopo di verificare la piena funzionalità delle apparecchiature del sistema, con manutenzione dei componenti soggetti ad usura. La frequenza minima di tali interventi dovrà essere semestrale. Si devono prevedere almeno i seguenti interventi periodici:

• Riparazione /sostituzione in generale dei cablaggi dell’impianto che lo richiedano;

• Sostituzione delle schede elettroniche o parti dell’impianto che lo richiedano;

• Aggiornamento del software di gestione delle apparecchiature di trasmissione/ricezione immagini comandi;

• Tuning dei parametri di funzionamento del sistema e dei componenti del software di base.

Pagina 99

15.2 Manutenzione ordinaria correttiva

La manutenzione correttiva ha lo scopo di ripristinare il corretto funzionamento delle apparecchiature e l’eliminazione degli inconvenienti meccanici o elettronici che hanno determinato la richiesta di intervento, sostituendo componenti o parti guaste ed eseguendo prove e controlli necessari per garantire la funzionalità e l’efficienza dell’impianto. In caso di segnalazione di fermo sistema, deve essere garantito l’intervento entro il giorno lavorativo successivo ed il ripristino delle condizioni di normale e completa operatività del Sistema entro il tempo massimo di:

• 1 (un) giorno lavorativo dall’intervento nel caso di problematiche che riducano in modo grave l’uso del Sistema (malfunzionamenti bloccanti);

• 3 (tre) giorni lavorativi dall’intervento nel caso di problematiche che riducano in modo lieve l’uso del Sistema o per qualsiasi altra richiesta di assistenza riguardante il Sistema (malfunzionamenti non bloccanti ed altre problematiche in genere).

In ogni caso il ripristino dovrà avvenire nel più breve tempo possibile nel rispetto dei requisiti di disponibilità dichiarati. In ogni caso dovranno essere prese le necessarie precauzioni per evitare la perdita delle informazioni. In caso di eventi e/o guasti particolari, non dipendenti dal fornitore stesso, cui il Fornitore non potrà fare fronte nel tempo stabilito (ad esempio guasti contemporanei di molti componenti dello stesso tipo, danni generalizzati al sistema dovuti a problemi di alimentazione, ecc.), egli dovrà darne sollecita informazione scritta al responsabile indicato dalla Provincia di Firenze, descrivendo esaurientemente la natura del guasto e giustificando l’impossibilità di rispettare i normali livelli di servizio. In questa evenienza il periodo eventuale di fermo del sistema verrà determinato caso per caso in contraddittorio fra Provincia e Fornitore, ma dovrà comunque essere lo stretto indispensabile per permettere l’intervento e comunque non superiore a 15 (quindici) giorni lavorativi dalla chiamata. Per ogni periodo di disattivazione ulteriore rispetto ai tempi sopra definiti, il Fornitore sarà soggetto a penalità specificata nel presente Capitolato. La risoluzione delle problematiche non bloccanti che comportano l’aggiornamento del software fornito potrà avvenire nell’ambito del programma di rilascio degli aggiornamenti del software stesso (patch o minor release), e comunque non oltre 2 (due) mesi dal momento in cui si ha evidenza dell’anomalia. Il termine di 2 (due) mesi sopra indicato è ridotto ad 1 (un) mese per le problematiche di sicurezza che riguardano la parte della piattaforma di infomobilità rivolta all’utenza finale e gli altri elementi (anche di back-office o di interconnessione) affacciati sulla rete pubblica. Sono altresì da intendersi compresi nella manutenzione in garanzia – senza ulteriori oneri per il Committente – gli eventuali aggiornamenti (upgrade) a major release del prodotto nonché le eventuali attività accessorie necessarie ad effettuare la migrazione qualora non venisse più garantita dal Fornitore la manutenzione della release fornita.

15.3 Manutenzione e assistenza fuori garanzia

Si chiede all’offerente di esporre le procedure e le prestazioni offerte per la manutenzione fuori garanzia. Esse dovranno rispettare i requisiti minimi già esposti per la manutenzione in garanzia. La Provincia non resta in alcun modo impegnata a ordinare le prestazioni di

Pagina 100

manutenzione ed assistenza fuori garanzia, mentre le condizioni esposte sono impegnative per il Fornitore in caso di accettazione da parte della Provincia.

16 Documentazione di sistema L’azienda aggiudicataria dovrà fornire tutta la documentazione necessaria, tra cui almeno:

• Progetto esecutivo del sistema complessivo;

• Schemi elettrici dei collegamenti in sala di controllo;

• Data sheet di tutti i componenti elettronici utilizzati e relative certificazioni di conformità (se previste dalle normative);

• Manuale per operatori di sistema comprendente l’elenco parametri di funzionamento programmabili;

• Manuale per amministratori di sistema;

• La documentazione originale relativa ad autorizzazioni, licenze, ecc, eventualmente necessarie. L’intestazione di tale documentazione dovrà avvenire secondo le prescrizioni che saranno fornite dal Committente all’Appaltatore. E’ esplicitamente richiesto che la titolarità delle eventuali licenze d’uso dei vari software che compongono il Sistema possano essere trasferite – senza oneri e/o vincoli – ad altro Ente o soggetto in genere al quale la Provincia decidesse in futuro trasferire o delegare le competenze nell’esercizio delle quali trova impiego il Sistema di cui al presente appalto;

• Dischi di installazione del software e relative istruzioni; essi dovranno essere aggiornati in caso di aggiornamenti del software successivi alla consegna acquisiti in garanzia o manutenzione.

Data la specificità del Sistema in oggetto, è anche richiesta la disponibilità di un manuale riportante

• Una dettagliata documentazione della base dati, di cui dovranno essere forniti i tracciati record e la struttura delle tabelle e delle relazioni tra di esse, nonché una dettagliata descrizione, tali da consentire lo sviluppo in autonomia di report e/o moduli di estrazione dati;

• Documentazione tecnica di alto livello del software di infomobilità, con descrizione dell’architettura di sistema, linguaggi, librerie e framework utilizzati.

• Documentazione tecnica di dettaglio di tutte le interfacce (API) realizzate per la piattaforma di infomobilità.

• Manualistica di configurazione, uso e manutenzione delle applicazioni di infomobilità. La manualistica dovrà essere consegnata almeno in triplice copia cartacea, oltre che su supporto informatico. Dovrà essere garantita la coerenza tra la manualistica e l’help contestuale in linea, che dovrà fornire anche eventuali indicazioni di consultazione della manualistica stessa.

17 Consistenza della fornitura, limiti e modalità di fornitura La fornitura in oggetto consiste dei seguenti beni e prestazioni.

• Architettura informatica necessaria a supportare il funzionamento dei pacchetti software richiesti, inclusi cablaggi e installazione, test e messa in funzionamento della stessa, nei locali della sala di controllo che saranno messi a disposizione dalla

Pagina 101

Provincia e/o dal Comune di Firenze. Resta esclusa dalla fornitura la predisposizione ed il cablaggio della sala, sia per quanto riguarda l’alimentazione che la rete di comunicazione, che saranno installate a cura dell’Amministrazione. Il fornitore sarà quindi tenuto a fornire quantomeno:

o tutti i server previsti dalla soluzione proposta; o 3 postazioni operatore; o 1 postazione per manutentore; o 3 monitor 40” per visualizzazione; o apparati di rete per il collegamento con la rete messa a disposizione; o apparati di continuità per l’alimentazione elettrica; o eventuali opere di cablaggio elettrico e di rete aggiuntive a quelle che

saranno fornite dall’Amministrazione nella sala di controllo.

• Tutte le licenze del software di base, di software tools o di software applicativi necessari al funzionamento del sistema nella soluzione proposta dal fornitore

• Software di supervisione del traffico così come descritto nel Capitolato e nei relativi allegati;

• Piattaforma software di distribuzione delle informazioni (di infomobilità) così come descritto nel Capitolato e nei relativi allegati;

• La documentazione di sistema e la manualistica;

• Tutti i servizi, di ingegneria e non, necessari a garantire il perfetto funzionamento e l’avvio in esercizio dell’intero sistema, così come specificato nel presente capitolato e nell’offerta presentata dal fornitore, fra cui:

o i servizi di configurazione iniziale del Supervisore e di taratura e messa a punto dei modelli impiegati nel Supervisore;

o i servizi di configurazione iniziale della piattaforma di infomobilità; o il training e la formazione al personale che sarà indicato per la gestione del

sistema; o i servizi di assistenza all’avvio del servizio operativo del sistema; o l’assistenza al collaudo;

• La manutenzione in garanzia del sistema implementato ed un supporto on line per l’esercizio.

Tutto il sistema andrà fornito “chiavi in mano”, debitamente installato e testato, ed il fornitore sarà tenuto a prestare la massima assistenza per il collaudo dello stesso. Il fornitore sarà pienamente responsabile del sistema fino ad accettazione dello stesso da parte dell’amministrazione, che avverrà a positivo esito del collaudo. L’Amministrazione nominerà un Responsabile Unico di Procedimento (RUP), cui il Fornitore farà riferimento sia per gli aspetti amministrativi che di gestione della fornitura. Egli potrà a suo insindacabile giudizio avvalersi del supporto di personale interno od esterno all’Amministrazione, con cui il fornitore sarà tenuto a collaborare. Il fornitore nominerà un Responsabile di Commessa che sarà l’interfaccia unica verso il fornitore per qualsiasi problematica di tipo normale o straordinario. Il RUP potrà richiedere relazioni periodiche con cadenza massima mensile sull’andamento della fornitura e dei lavori. La Provincia ed il Comune di Firenze provvederanno in proprio a commissionare tutti i lavori da svolgere sui sistemi periferici da interfacciare con il sistema di supervisione. Sarà

Pagina 102

responsabilità del fornitore concordare con i soggetti che saranno incaricati degli sviluppi sui sistemi periferici e definire le specifiche di interfacciamento e dell’eventuale software che andrà sviluppato. A tal fine il responsabile di Commessa sarà tenuto a controfirmare per approvazione le specifiche di interfacciamento e di sviluppo del software che la Amministrazioni commissioneranno. Il fornitore sarà l’unico responsabile di provvedere ai rapporti con gli Enti gestori dei sistemi che dovranno essere interfacciati, anche se il Comune e la Provincia di Firenze si impegnano a fare quanto in loro potere per facilitare le relazioni con questi soggetti.

18 Norme applicabili Le caratteristiche degli apparati forniti dovranno soddisfare le norme di legge ed i regolamenti vigenti alla data di installazione.

19 Tempistica e vincoli realizzativi La fornitura in opera del Sistema, la relativa configurazione e calibrazione dovranno essere completate nell’arco di 18 (diciotto) mesi dalla data di assegnazione della stessa. Successivamente inizierà un periodo di pre-esercizio della durata di 6 (sei) mesi, nell’ambito del quale sarà verificata nell’uso la corretta messa a punto del Sistema. I tempi della fornitura, globalmente dovranno quindi essere i seguenti.

1. Entro 3 (tre) mesi dalla data di affidamento l’affidatario è tenuto a consegnare la documentazione di progettazione esecutiva, ivi incluso il computo metrico di dettaglio (redatto secondo le specifiche indicazioni che saranno fornite dal Committente), nonché il progetto grafico e la struttura del portale web. Il RUP, o il direttore dell’esecuzione eventualmente individuato dall’Amministrazione, potrà formulare osservazioni e chiedere chiarimenti ed integrazioni. Ferma restando la responsabilità dell’affidatario sul progetto, egli dovrà fornire quanto richiesto entro 15 (quindici) giorni dalla data della richiesta.

2. Poiché la fornitura si inquadra nell’ambito di un progetto che pone vincoli di tempi, essa dovrà essere organizzata in modo da fornire funzionanti entro 8 (otto) mesi dalla data di assegnazione almeno i seguenti moduli del sistema (nell’ambito del presente documento l’insieme di tali moduli sarà chiamato anche “primo lotto funzionale”): per il Supervisore di traffico

• Acquisizione dati dai vari sistemi esterni per quanto riguarda l’interfaccia con i sistemi di acquisizione dati di traffico;

• Integrazione con il sistema FCD;

• Ricostruzione dello stato di traffico della rete ed identificazione di situazioni di criticità;

• Invio comandi verso sistemi periferici;

• Interfaccia verso i sistemi di pianificazione del traffico. Essi dovranno operare sul grafo e sulla cartografia di riferimento, quindi il sistema dovrà anche supportare tutte quelle funzioni di

• Memorizzazione e gestione dei dati,

Pagina 103

• Rappresentazione grafica e interfaccia utente, necessarie a poter dare una dimostrazione completa della catena del sistema, dalla acquisizione dati, inclusi quelli FCD, alla loro fusione e alla sintesi dello stato di rete, alla sua rappresentazione sui sinottici in sala di controllo e all’invio di informazioni verso sistemi periferici di informazione all’utenza, compresi quelli mobili. per la piattaforma di infomobilità

• Realizzazione di tutti i servizi descritti in sezione 6.8, escluso l’eventuale strato di adattamento software verso sistemi esterni.

Per tutti quei moduli o servizi per i quali, per motivi non dipendenti dalla volontà del Fornitore, non risulteranno disponibili dati o informazioni acquisibili in tempo reale, dovranno essere realizzati degli opportuni moduli stub che permettano il test degli applicativi simulando il comportamento dei sistemi esterni. Al termine di questa fase verrà effettuato il collaudo preliminare delle componenti comprese nel primo lotto funzionale.

3. Il completamento della fornitura in opera dell’intero Sistema dovrà avvenire entro 18 (diciotto) mesi dalla data di assegnazione. Per completamento si intende il sistema provvisto di tutti i componenti hardware e di tutti i moduli software, debitamente installato e testato. Tale completamento sarà attestato da apposito verbale sottoscritto dal RUP o dal direttore dell’esecuzione e dal Fornitore. Prima del collaudo, ovvero nel periodo che intercorre tra la consegna del primo lotto funzionale (previsto entro 8 mesi dall’aggiudicazione) ed il completamento della fornitura, l’aggiudicatario dovrà svolgere le attività di formazione descritte al paragrafo § 16, fermo restando quanto indicato al punto successivo relativamente all’assistenza in fase di avvio del sistema.

4. Il collaudo finale del sistema avverrà successivamente alla sottoscrizione del

verbale di cui sopra. Resta inteso che la risoluzione di eventuali anomalie che saranno riscontrate dopo il collaudo sarà compresa nell’attività di manutenzione in garanzia come precisato al paragrafo § 14;

5. Dalla data di conclusione con esito positivo del collaudo decorrerà un periodo di

pre-esercizio di ulteriori 6 (sei) mesi, nei quali sarà verificata nell’uso la corretta messa a punto del Sistema e si provvederà alla calibrazione di tutte le funzionalità del Sistema che lo richiederanno.

L’offerente dovrà indicare chiaramente i tempi di consegna delle forniture e le eventuali precondizioni necessarie, rispettando ovviamente le scadenze massime sopra riportate, allegando un dettagliato cronoprogramma delle forniture e delle attività accessorie; in tale programma dovrà individuare anche eventi significativi nel processo di fornitura e di installazione del sistema che diano la possibilità all’Amministrazione di controllare lo stato di avanzamento del progetto. Successivamente all’aggiudicazione, nell’ambito dell’attività finalizzata alla produzione del progetto esecutivo, il cronogramma potrà essere oggetto di revisione e dovrà recepire

Pagina 104

le eventuali ulteriori informazioni ed indicazioni fornite dal Committente. Tale nuova revisione sarà parte integrante del progetto esecutivo.

20 Calendario dei pagamenti Il pagamento dei corrispettivi dovuti al Fornitore sarà effettuato secondo stati di avanzamento, ovvero secondo il calendario e le percentuali di seguito indicate

- 60% del valore della fornitura al completamento della fornitura del primo lotto funzionale (previsto entro 8 mesi dalla formalizzazione dell’affidamento);

- 30% del valore della fornitura al completamento della fornitura in opera dell’intero Sistema e delle attività accessorie previste dal Capitolato (e relativi allegati) e dall’offerta (previsto entro 18 mesi dalla formalizzazione dell’affidamento);

- 10% del valore della fornitura ad esito positivo del collaudo.

21 Penali – fattispecie e quantificazione Per il mancato rispetto dei livelli di servizio previsti dal Capitolato e dai relativi allegati, l’Appaltatore è soggetto all’applicazione di penali con le modalità descritte nel Capitolato. Di seguito sono riportate le fattispecie delle penali ed i relativi importi. Fatto salvo quanto previsto negli in altri paragrafi del presente documento e/o nel Capitolato e negli altri allegati, il Committente potrà applicare le seguenti penalità in corso di esecuzione dell’Appalto: - Euro 250,00 (duecentocinquanta/00) per ogni giorno di ritardo nella consegna del

progetto esecutivo – prevista al 3° (terzo) mese giorno dalla data di affidamento della fornitura – e per ogni giorno di ritardo nella fornitura di integrazioni oltre il 15° (quindicesimo) dalla data di richiesta da parte del Committente;

- Euro 750,00 (settecentocinquanta/00) per ogni giorno di ritardo nella consegna del primo lotto di fornitura – prevista entro il termine dell’8° (ottavo) mese dalla data di affidamento della fornitura;

- Euro 500,00 (cinquecento/00) per ogni giorno di ritardo nel completamento della fornitura – prevista al termine del 18° (diciottesimo) mese dalla data di affidamento della fornitura;

Potranno essere inoltre applicate le seguenti penali nel periodo di manutenzione in garanzia e post-garanzia (qualora richiesta dal Committente): - Euro 500,00 (cinquecento/00) in caso di mancata effettuazione di uno degli interventi

di manutenzione periodica programmata; - Euro 50,00 (cinquanta/00) per ogni ora lavorativa di ritardo nell’intervento a seguito

della chiamata oltre il termine fissato dal presente Capitolato – e cioè oltre il 1° (primo) giorno lavorativo successivo alla chiamata – o dall’offerta presentata in sede di gara qualora quest’ultima sia migliorativa;

- in caso di problematiche che riducano in modo grave l’uso del Sistema (malfunzionamenti bloccanti), Euro 50,00 (cinquanta/00) per ogni ora lavorativa di ritardo nel ripristino delle condizioni di operatività del Sistema oltre il termine fissato dal presente Capitolato – e cioè oltre 1 (un) giorno lavorativo dall’intervento – o dall’offerta presentata in sede di gara qualora quest’ultima sia migliorativa;

Pagina 105

- in caso di problematiche che riducano in modo lieve l’uso del Sistema o per qualsiasi altra richiesta di assistenza riguardante il Sistema (malfunzionamenti non bloccanti ed altre problematiche in genere), Euro 25,00 (venticinque/00) per ogni ora lavorativa di ritardo nel ripristino delle condizioni di normale e completa operatività del Sistema oltre il termine fissato dal presente Capitolato – e cioè oltre 3 (tre) giorni lavorativi dall’intervento – o dall’offerta presentata in sede di gara qualora quest’ultima sia migliorativa;

- Euro 500.00 (cinquecento/00) per ogni giorno lavorativo di ritardo nella risoluzione delle problematiche determinate da eventi e/o guasti particolari, non dipendenti dal fornitore stesso, oltre il termine fissato dal presente Capitolato – e cioè oltre 15 (quindici) giorni lavorativi;

- Euro 250,00 (duecentocinquanta/00) per ogni settimana di ritardo nel rilascio di aggiornamenti software per la risoluzione di problematiche non bloccanti che comportano l’aggiornamento del software oltre il termine fissato dal presente Capitolato – e cioè oltre 2 (due) mesi dal momento in cui si è avuta evidenza dell’anomalia;

- Euro 500,00 (cinquecento/00) per ogni settimana di ritardo nel rilascio di aggiornamenti software per la risoluzione di problematiche non bloccanti che riguardano la parte della piattaforma di infomobilità rivolta all’utenza finale e gli altri elementi (anche di back-office o di interconnessione) che si affacciano sulla rete pubblica e che comportano l’aggiornamento del software oltre il termine fissato dal presente Capitolato – e cioè oltre 1 (un) mese dal momento in cui si è avuta evidenza dell’anomalia.

Si precisa che nell’ambito dell’appalto di cui al presente documento si definiscono lavorativi tutti i giorni feriali dal lunedì al venerdì. Per le festività a carattere locale si considerano come riferimento quelle del Comune di Firenze. Inoltre, considerato lo specifico campo di applicazione del Sistema, l’orario lavorativo di riferimento è 8:00–20:00.

FORNITURA DI UN SISTEMA DI SUPERVISIONE DEL … Capitolato... · su questa base identificare e...

Documents

Transcript of FORNITURA DI UN SISTEMA DI SUPERVISIONE DEL … Capitolato... · su questa base identificare e...