Pagina 1 di 15 Procedura aperta per l’affidamento del servizio di trasporto riservato scolastico nel territorio di Roma Capitale, suddiviso in cinque lotti (n. 5 lotti). Capitolato Speciale Descrittivo e Prestazionale. Allegato 2 “Monitoraggio ai fini della certificazione del servizio”. Procedura aperta per l’affidamento del servizio di trasporto riservato scolastico nel territorio di Roma Capitale, suddiviso in cinque lotti (n. 5 lotti). Capitolato Speciale Descrittivo e Prestazionale Allegato 2 “Monitoraggio ai fini della certificazione del servizio” Indice 1 Premessa. 2 2 Il Sistema AVM: requisiti operativi e funzionali minimi. 2 2.1 Configurazione del sistema AVM. 3 2.2 Sistema di bordo. 3 2.3 Centrale Operativa. 5 3 Monitoraggio del servizio esercitato con veicoli in cui è implementato il Sistema AVM. 7 3.1 Dati che devono essere forniti dal Gestore. 7 3.1.1 Dati relativi al servizio ed alle percorrenze di ogni veicolo, prodotti dal Sistema AVM. 7 3.1.2 Assegnazione delle linee ai veicoli. 8 3.1.3 Stato dei veicoli disponibili per il servizio. 9 3.1.4 Elenco delle “corse giustificate”, ossia effettuate non in condizioni standard per cause esterne documentabili. 10 3.1.5 Dati di rendicontazione giornaliera del servizio. 12 3.2 Servizio effettuato, in base al quale è definito il corrispettivo da riconoscere su base mensile. 13 3.3 Indicatore di Regolare esecuzione del servizio sotto il profilo del rispetto degli Orari programmati (IRO). 13 4 Rapporto di Servizio Mensile. 14
13
Embed
Procedura aperta per l’affidamento dei servizi di ...
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Pagina 1 di 15
Procedura aperta per l’affidamento del servizio di trasporto riservato scolastico nel territorio di Roma Capitale, suddiviso in cinque lotti (n. 5 lotti). Capitolato Speciale Descrittivo e Prestazionale. Allegato 2 “Monitoraggio ai fini della certificazione del servizio”.
Procedura aperta per l’affidamento del servizio di trasporto riservato scolastico nel territorio di Roma Capitale, suddiviso in cinque lotti (n. 5 lotti).
Capitolato Speciale Descrittivo e Prestazionale
Allegato 2 “Monitoraggio ai fini della certificazione del servizio”
Indice
1 Premessa. 2
2 Il Sistema AVM: requisiti operativi e funzionali minimi. 2
2.1 Configurazione del sistema AVM. 3
2.2 Sistema di bordo. 3
2.3 Centrale Operativa. 5
3 Monitoraggio del servizio esercitato con veicoli in cui è implementato il Sistema
AVM. 7
3.1 Dati che devono essere forniti dal Gestore. 7
3.1.1 Dati relativi al servizio ed alle percorrenze di ogni veicolo, prodotti
dal Sistema AVM. 7
3.1.2 Assegnazione delle linee ai veicoli. 8
3.1.3 Stato dei veicoli disponibili per il servizio. 9
3.1.4 Elenco delle “corse giustificate”, ossia effettuate non in condizioni
standard per cause esterne documentabili. 10
3.1.5 Dati di rendicontazione giornaliera del servizio. 12
3.2 Servizio effettuato, in base al quale è definito il corrispettivo da riconoscere su base
mensile. 13
3.3 Indicatore di Regolare esecuzione del servizio sotto il profilo del rispetto degli Orari
programmati (IRO). 13
4 Rapporto di Servizio Mensile. 14
Pagina 2 di 15
1 Premessa.
Il monitoraggio è finalizzato ad accertare che il servizio sia erogato in conformità con la
programmazione definita da Roma Capitale.
Il sistema AVM (Automatic Vehicle Monitoring) è lo strumento prescelto dall'Amministrazione per
effettuare tale monitoraggio e deve essere operativo su tutti i mezzi, di ogni Affidatario, dall'avvio del
servizio.
I requisiti operativi e funzionali del Sistema e le modalità di effettuazione del monitoraggio qui definiti
(ovvero quelli migliorativi eventualmente offerti dal Gestore in sede di Offerta Tecnica) identificano
precisi obblighi per il Gestore.
Il mancato rispetto di tali obblighi comporta l’applicazione delle penali definite nell’art. 7 dello Schema
di Contratto e riconosciuti, in questo Allegato 2, con specifici acronimi.
2 Il Sistema AVM: requisiti operativi e funzionali minimi.
Il Sistema AVM dovrà rispettare tutti i requisiti minimi operativi e funzionali specificati in questo
Allegato 2.
Tali requisiti sono esposti nei seguenti paragrafi di questo capitolo e nel capitolo successivo.
Ad introduzione della specificazione dei requisiti minimi operativi e funzionali del Sistema si precisa
quanto segue:
Il Sistema deve essere operato e gestito dal Gestore con propria organizzazione e deve
consentirgli di gestire l’esercizio, di generare e registrare i dati, di elaborare i rapporti di
rendicontazione.
Il Gestore deve consentire a Roma Capitale il più ampio accesso ai dati prodotti dal Sistema,
anche in tempo reale ed anche in modalità remota sia fissa che mobile.
Il Sistema deve permettere a Roma Capitale di visualizzare in tempo reale la posizione di ogni
veicolo, di registrare in tempo reale tutti gli spostamenti dei veicoli per la completa ricostruzione
dei percorsi, di acquisire ogni altro dato registrato dal Sistema sia di dettaglio, sia aggregato.
Il Gestore deve mettere a disposizione di Roma Capitale, senza oneri aggiuntivi, spazi idonei
presso i depositi ed all’interno dei veicoli qualora dovessero manifestarsi esigenze funzionali,
relazionate al migliore espletamento delle attività di monitoraggio, che richiedano interventi [di
tipo tecnologico e/o infrastrutturali] che Roma Capitale potrà liberamente realizzare nel rispetto
delle norme.
Il Sistema deve garantire la piena compatibilità ed integrazione con i sistemi e le basi dati
utilizzati da Roma Capitale ed in particolare con le anagrafiche, i sistemi di infomobilità, i sistemi
di supporto alle decisioni, i sistemi di gestione dell’esercizio.
Il Sistema deve essere realizzato nel pieno rispetto delle normative vigenti nel campo di emissioni
elettromagnetiche e di sicurezza.
Non è concessa la possibilità di adottare un Sistema AVM funzionalmente diverso da quello
descritto nel presente Allegato 2 e comunque non concordato con Roma Capitale.
Pagina 3 di 15
2.1 Configurazione del sistema AVM.
La configurazione del Sistema AVM prevede le seguenti componenti:
Sistema di Bordo, installato sul veicolo, che gestisce i vari eventi e le periferiche di cui è
dotato il veicolo e la comunicazione mobile attraverso una rete pubblica o privata e mediante
sistemi di prossimità.
Centrale Operativa, che gestisce in tempo reale il flusso informativo.
Sistema di comunicazione che governa in modo bidirezionale la trasmissione mobile tra i
veicoli, la Centrale Operativa, i Depositi, specifici siti predisposti da Roma Capitale, e sovrintende
a tutte le comunicazioni di dati in tempo reale o in differita con i sistemi e le procedure definiti da
Roma Capitale.
2.2 Sistema di bordo.
Il Sistema di Bordo è costituito da dispositivi atti a realizzare ed elaborare varie operazioni di
Input/Output dei dati del veicolo. In particolare il Sistema di Bordo dovrà essere composto dai seguenti
elementi logico-fisici:
Unità di identificazione
Tale unità conterrà tutti i dati e parametri più importanti specifici del veicolo sul quale è installato il
Sistema di Bordo.
Unità di localizzazione
Tale unità è incaricata di acquisire in modalità del tutto automatica, con il minimo margine di
errore e con minime frequenze di aggiornamento (non superiore a 1 secondo) la localizzazione
GPS (secondo lo standard WGS84) del veicolo sul territorio. Dovrà essere garantita la
migrazione ad altro sistema di georeferenziazione (ad esempio: Galileo) qualora questo dovesse
rendersi necessario ai fini funzionali di Roma Capitale.
La localizzazione dovrà essere inviata al Sistema Centrale [Centrale Operativa] ad intervalli
regolari (non oltre 30 secondi e comunque parametrizzabili) o in base a specifici eventi che
potranno essere liberamente determinati o su richiesta diretta del Sistema Centrale. Tutte le
informazioni inviate al Sistema Centrale (ed eventuali informazioni aggiuntive) dovranno essere
memorizzate anche sul LOG a Bordo che potrà essere scaricato in caso di guasto dell’unità di
comunicazione in tempo reale.
L’ora, il minuto, il secondo e la data della localizzazione dovranno essere sincronizzate con data
e ora del sistema satellitare.
Unità di elaborazione
Il compito dell’Unità di Elaborazione è elaborare, memorizzare, archiviare ed interfacciare in
tempo reale i dati provenienti dall’unità di localizzazione e dalla linea CAN/FMS oltre che da altri
eventuali apparati installati a bordo.
L’Unità di Elaborazione dovrà disporre di idonea memoria per il mantenimento delle informazioni
per un periodo non inferiore a 3 giorni di attività.
Unità di comunicazione in tempo reale
Tale Unità si occuperà di comunicare in modalità bidirezionale con il Sistema Centrale.
In particolare la comunicazione avverrà su rete radiomobile pubblica/privata. L’invio delle
Pagina 4 di 15
informazioni dovrà essere in ogni caso garantito sia in tempo reale che in differita. In particolare,
in caso di temporanea mancata copertura del segnale, l’unità dovrà provvedere autonomamente
alla trasmissione dei dati al rientro in copertura.
L’Unità di comunicazione dovrà risultare compatibile con gli standard internazionali vigenti in
materia di terminali mobili e certificata dai maggiori operatori di telefonia mobile.
Unità di comunicazione a corto raggio
Le funzionalità di comunicazione a corto raggio dovranno essere rese possibili attraverso vari
standard (Wi-Fi, RFid, NFC, Bluetooth). La comunicazione dei veicoli con gli impianti che
utilizzano le suddette modalità di comunicazione potrà avvenire sia con veicolo in movimento che
in sosta e potranno essere scambiate informazioni di qualsiasi natura. L’avvio della
comunicazione da/verso il veicolo dovrà essere completamente automatica e non richiedere
alcun intervento da parte dell’amministratore. Se necessario il veicolo dovrà fungere da portale di
accesso verso la rete internet.
Unità Conducente
Il conducente dovrà disporre di una unità in grado di comunicare vari eventi tra i quali, a titolo di
esempio e non esaustivo:
- Guasto
- Richiesta intervento
- Inizio turno
- Fine turno
- Incidente
- Chiamata vocale
- Deviazione
- Inserimento corsa persa
- Fuori Servizio
- Deposito
- Tasti numerici ed alfabetici per messaggi liberi.
La presa in carico del veicolo da parte del conducente dovrà essere attestata in modo informatico
e potrà segnalare situazioni di emergenza mediante azionamento di un pedale/pulsante di
allarme nascosto alla vista del pubblico.
2.3 Centrale Operativa.
La Centrale Operativa sarà costituita da un complesso hardware e software in alta affidabilità,
alimentato da gruppi di continuità e governato da procedure di disaster-recovery.
La Centrale Operativa dovrà essere accessibile anche da Roma Capitale e da altre società indicate
dalla stessa mediante stazioni di lavoro client.
Gli applicativi software della Centrale Operativa dovranno consentire:
il controllo in tempo reale dello stato del servizio, sulla base dei dati di localizzazione
trasmessi dai veicoli;
la trasmissione a Roma Capitale dei dati di localizzazione e di servizio dei veicoli in tempo
reale, al fine di consentire a Roma Capitale la gestione dei propri sistemi di comunicazione con
Pagina 5 di 15
l’utenza (tempi di attesa alle fermate, etc.) ed il monitoraggio dell’esercizio;
la registrazione dei dati di vestizione, degli eventi e degli allarmi generati durante l’esecuzione
del servizio;
l’acquisizione e produzione dei dati richiesti per la rendicontazione del servizio.
La Centrale Operativa dovrà garantire le seguenti funzionalità minime:
Configurazione client-server, in grado di gestire simultaneamente, senza alcun conflitto, più
postazioni operatore. I requisiti di architettura sono i seguenti:
- postazione operatore
- server ad alta disponibilità per la gestione dello scarico dati e la generazione dei rapporti di
rendicontazione del servizio
- postazione per la gestione della manutenzione, che accumula le informazioni acquisite dai
veicoli e relative ad eventuali stati anomali dei sistemi o dei parametri di bordo
- stampanti.
Gestione delle comunicazioni:
- comunicazione mobile bidirezionale con i veicoli
- comunicazione con i sistemi per il trasferimento dei dati necessari alla rendicontazione del
servizio.
Gestione in tempo reale del servizio:
- selezione della linea o gruppo di linee da monitorare
- rappresentazione lineare dei percorsi con visualizzazione dei veicoli in linea, del relativo verso
di percorrenza, delle fermate definite sul percorso
- rappresentazione topografica (con base dati cartografica sincronizzata con le anagrafiche di
Roma Capitale) dei percorsi con visualizzazione geo-referenziata dei veicoli in linea, del
relativo verso di percorrenza e delle fermate definite sul relativo percorso
- possibilità di effettuare ingrandimenti e riduzioni della immagine topografia per meglio
visualizzare la posizione dei veicoli
- registrazione e visualizzazione del log degli eventi/allarmi scambiati tra il Sistema Centrale ed
i veicoli
- integrazione con il programma di esercizio previsto ed import dei dati mediante
sincronizzazione delle anagrafiche definite dal sistema
- possibilità di stampa delle informazioni presentate dal sistema.
Stato dei veicoli:
- scostamento rispetto all’orario programmato
- anomalie di servizio esplicite (ad esempio: fuoriuscita del veicolo dal percorso stabilito)
- rappresentazione dello stato di Anticipo/Ritardo.
Gestione messaggi conducente.
Gestione allarmi provenienti dal conducente o dalla diagnostica del veicolo.
Gestione dello scambio dati con i sistemi di riferimento di Roma Capitale:
- sistema di pianificazione del servizio
- sistema di informazione al pubblico
- sistema centrale
- sistema di data warehouse
Pagina 6 di 15
- sistema territoriale.
Gestione dei processi di consuntivazione del servizio e delle relative reportistiche.
Gestione automatizzata di tutto il processo di installazione, diagnosi e manutenzione dei
Sistemi centrale e di bordo. In particolare dovrà essere possibile gestire automaticamente la
segnalazione, l’intervento di manutenzione/installazione/collaudo affinché siano automaticamente
determinabili i tempi di intervento per il ripristino delle anomalie.
La Centrale Operativa dovrà inoltre offrire funzionalità di supporto all’intero ciclo di vita relativo
alla manutenzione del Sistema di Bordo.
Una postazione operatore dotata di tutte le funzionalità di visualizzazione in tempo reale del servizio
dovrà essere installata presso una sede di Roma Capitale o di altro Soggetto da Essa preposto al
monitoraggio.
La predisposizione della rete di comunicazione dati verso tale sede sarà a carico del Gestore, tale rete
dovrà assicurare prestazioni ed affidabilità adeguate al trattamento dati.
3 Monitoraggio del servizio esercitato con veicoli in cui è implementato il
Sistema AVM.
Il Monitoraggio è basato sui dati forniti dal Gestore e su riscontri effettuati da Roma Capitale.
Il Monitoraggio considera due aspetti inerenti all’erogazione del servizio:
L’entità del servizio effettuato, in base al quale è definito il corrispettivo da riconoscere su
base mensile.
La regolare esecuzione del servizio sotto il profilo del rispetto degli orari programmati.
3.1 Dati che devono essere forniti dal Gestore.
Per l’effettuazione del Monitoraggio dovranno essere messi a disposizione di Roma Capitale i
seguenti dati:
1. Dati relativi al servizio ed alle percorrenze di ogni veicolo, prodotti dal Sistema AVM;
2. Assegnazione dei veicoli alle linee (“vestizione dei veicoli”);
3. Stato dei veicoli disponibili per il servizio;
4. Elenco delle “corse giustificate”, ossia effettuate non in condizioni standard per cause esterne
documentabili;
5. Rendicontazione giornaliera del servizio.
Nei successivi paragrafi sono riportate le specifiche di tutte le informazioni sopra elencate.
I dati richiesti, in formato elettronico, dovranno essere messi a disposizione tramite web services.
Ogni web service dovrà essere interrogabile per data a partire dalle ore 09 del giorno lavorativo
successivo a quello di pertinenza per un massimo di 60gg.
Ogni web service dovrà essere raggiungibile tramite protocollo https con autenticazione tramite
username e password.
3.1.1 Dati relativi al servizio ed alle percorrenze di ogni veicolo, prodotti dal Sistema AVM.
Il Gestore ha l’obbligo di fornire a Roma Capitale per ogni veicolo in esercizio i dati giornalieri sul
Pagina 7 di 15
servizio effettuato dal veicolo, prodotti dal Sistema AVM.
I dati dovranno essere pubblicati su un apposito web service.
Il servizio, interrogato per singola data, dovrà restituire la seguente struttura:
{ “status”:{“codice”: “0”}, “message”:{“errore”: “Messaggio di errore”}, “response”: {} }
Dove:
id -> (int) identificativo univoco della giustificazione
data -> (date) data del giorno di esercizio in formato yyyy-mm-dd
linea -> (str) identificativo della linea
corsa -> (int) identificativo della corsa
note -> (str) eventuali note
causale -> (str) codice identificativo della tipologia di giustificazione. IL codice può assumere uno
dei valori della seguente tabella:
Pagina 10 di 15
Giustifiche per causa esterna
Codice Descrizione
A.1
Variazione programmazione (corse non coerenti con il Programma di Esercizio e che sono giustificate a causa di comunicazione di variazione del Programma di Esercizio da parte di Roma Capitale ritardata rispetto a quanto definito nel Capitolato (art. 3) )
A.2
Corsa senza studenti (corse non effettuate a causa dell’assenza di tutti gli utenti previsti nelle corse con partenza dalle scuole)
A.3
Deviazione percorso (corse completate, ma effettuate su percorsi diversi a causa di lavori stradali, incidenti, deviazioni, manifestazioni)
A.4
Accompagnatore assente (corse non effettuate a causa dell’assenza dell’accompagnatore)
A.5
Accompagnatore in ritardo (corse effettuate in ritardo se l’arrivo dell’accompagnatore supera la soglia di tolleranza prevista di 10 minuti)
A.6 Malore utente/accompagnatore
A.7
Utente disabile non presente/in ritardo (corse effettuate con ritardo a causa dell’assenza o dell'arrivo in ritardo dell’utente disabile
nel punto di prelievo) (tale giustificazione comprende anche l’eventuale continuazione della corsa da parte del veicolo e il suo successivo ritorno sul luogo previsto).
A.8
Genitore/Accompagnatore non presente/in ritardo (corse che subiscono ritardo a causa dell’assenza nel luogo previsto o dell’arrivo in ritardo rispetto all’orario prestabilito del genitore/accompagnatore autorizzato a prelevare il minorenne; tale giustificazione comprende anche l’eventuale continuazione della corsa da parte del veicolo e il suo successivo ritorno sul luogo previsto).
A.9 Sciopero nazionale/di settore
A.10 Altro (specificare)
Giustifiche per causa interna.
Codice Descrizione
B.1
Malore autista (in tale caso sarà possibile giustificare per ritardo anche le corse successive e previste in un intervallo di tempo pari a quello necessario ad aspettare i mezzi il mezzo di riserva e comunque non superiore ai 60 minuti)
B.2
Guasto veicolo (che subiscono un ritardo a causa del guasto del veicolo, il tempo tra l'avviso dell'avvenuto guasto e l'arrivo del mezzo sostitutivo non potrà essere comunque superiore ai 60 minuti. In caso di mancata sostituzione nei tempi previsti, la giustificazione non verrà ritenuta accettabile)
B.2 Autista assente/in ritardo (giustificabile entro i 10 minuti)
B.4 Sciopero aziendale
B.3 Altro (specificare)
Giustifiche per guasto apparato AVM.
Codice Descrizione
C.1 Dispositivo guasto / dati non disponibili
C.2 Tracciato gps irregolare
Pagina 11 di 15
La fornitura non corretta o ritardata del dato determina l’inadempienza riconosciuta con l’acronimo M-
IFCG [Monitoraggio-InidoneaFornituraCorseGiustificate] cui corrisponde l’applicazione della penale
definita nell’art. 7 dello Schema di Contratto.
Oltre al tracciato sopra specificato, il Gestore deve mettere a disposizione di Roma Capitale la
documentazione, in formato elettronico, necessaria a comprovare ciascuna giustificazione. La
documentazione dovrà essere inclusa in un archivio compresso identificata con il corrispondente
codice (id) associato alla giustificazione.
L’archivio sarà riconosciuto con un nome avente il seguente formato
Giustificazioni_id.zip
Dove “id” è il codice identificativo univoco della giustificazione.
L’archivio deve essere trasmesso giornalmente, entro le ore 09.00 del 2° giorno successivo a quello di
riferimento, tramite PEC all'Amministrazione o a Soggetti a tale fine incaricati da Roma Capitale e mail
dedicata.
La fornitura non corretta o ritardata dell’archivio determina l’inadempienza riconosciuta con l’acronimo
M-IFG [Monitoraggio-InidoneaFornituraGiustificazioni] cui corrisponde l’applicazione della penale
definita nell’art. 7 dello Schema di Contratto.
Qualora dalla documentazione contenuta nell’archivio oppure da altre evidenze risultasse che non
sono soddisfatte le condizioni per potere considerare giustificata la corsa non esercitata o esercitata in
modalità non standard, tale corsa sarà considerata come non esercitata e sarà inoltre comminata la
penale riconosciuta con l’acronimo M-ICG [Monitoraggio-InidoneitàCorseGiustificate] nell’art. 7 dello
Schema di Contratto.
3.1.5 Dati di rendicontazione giornaliera del servizio.
Il Gestore ha l’obbligo di fornire a Roma Capitale i rapporti di rendicontazione del servizio svolto
quotidianamente.
Tali dati sono strutturati per linea e costituiscono un riepilogo dei dati descritti nei paragrafi precedenti.
I dati dovranno essere pubblicati su un apposito web service.
Il servizio, interrogato per singola data, dovrà restituire la seguente struttura: