Fornitura di un sistema software per la programmazione e gestione del servizio di trasporto passeggeri

La Demo, verosimilmente, verrà programmata per la seconda metà di settembre.

1) Il sistema oggi utilizzato è in AS400. I parametri che si riesce ad esportare sono i programmi di esercizio in corso in formato GTFS.

2) Il sistema proposto dovrà consentire il caricamento di cartografie basate sia su dati vettoriali che su dati raster (o a griglia).

Si precisa che:

• I dati vettoriali sono costituiti da elementi semplici quali punti, linee e poligoni, codificati e memorizzati sulla base delle loro coordinate. A ciascun elemento è associato un record del database informativo che contiene tutti gli attributi dell'oggetto prescelto;

• I dati raster sono composti da matrici di pixel (chiamati anche celle), generalmente di forma quadrata o rettangolare. La dimensione del pixel, generalmente espressa nell'unità di misura della carta (centimetri, metri, chilometri ecc.), è strettamente correlata alla precisione del dato. 

Le banche dati geografiche regionali sono generalmente disponibili in file compressi (.zip), in formato shapefile per i dati vettoriali e TIFF o IMG o ESRI GRID per quelli raster.

3) Quando si fa riferimento al calcolo delle percorrenze s’intende l’assegnazione dei tempi di percorrenza da una fermata all’altra. In particolare in ATB la programmazione del servizio si effettua partendo dalle fermate di maggiore interesse poiché anche nodi di interscambio. Tali fermate, spesso ma non sempre, non coincidono con i capolinea della linea ma con la fermata posta nel mezzo del percorso, come già riportato nell’esempio un nodo fondamentale per la creazione delle corse è “Porta Nuova”.

Così facendo il cadenzamento delle linee è regolare nei nodi principali della rete ma potrebbe non esserlo ai capolinea.

I tempi di percorrenza tra una fermata e l’altra, successivi o antecedenti la fermata di riferimento, devono essere assegnati in automatico a seguito dell’elaborazione dei dati dell’AVM.

4) È frequente che l’autobus inizi il servizio su una tabella di marcia e finisca su una tabella di marcia diversa. Nello specifico non si tratta del rientro in deposito.

Per chiarire ulteriormente, si specifica che oggi le tabelle di marcia sono costruite sulle singole linee es. linea 1 tabella n. 2. Se la tabella n. 2 della linea 1 termina alle ore 18.00 è facile che si attacchi un’altra tabella di marcia di una linea diversa come potrebbe essere ad esempio linea 8 tabella n. 5, dalle 18.10 alle 23.00. Le due tabelle di marcia possono attaccarsi al capolinea o in una fermata comune ad entrambe le linee a metà percorso.

5) Con il termine “Esempio di pianificazione” s’intende la pianificazione del programma di esercizio, anche nel calendario dei programmi di servizio.

Per demo tecnica illustrativa s’intende quanto descritto a pag. 41 del capitolato tecnico. Non è possibile realizzarla con wireframe.

1. E’ corretto intendere che la fornitura del codice sorgente avverrà esclusivamente qualora l’Aggiudicatario non fosse più in grado di garantire il corretto funzionamento del software oggetto dell’Appalto (ad es. nel caso in cui l’Aggiudicatario cessasse la propria attività).
2. In caso di richiesta del codice sorgente da parte del Committente, l’Aggiudicatario avrà la facoltà di richiedere il deposito dello stesso presso un Notaio a tutela della proprietà intellettuale del sistema implementato.
3. Relativamente al capitolo 9 “Integrazione con sistemi esistenti” si riportano di seguito alcune informazioni utili alla valutazione della fattibilità tecnica dell’implementazione delle

interfacce richieste.

Tutti i dati utili all’integrazione con i sistemi esistenti potranno essere esportati come file di testo in un ambiente periferico condiviso, nello specifico si richiedono:

• file .txt conformi allo standard “GTFS” (Google Transit Feed Specification) per l’integrazione con “Google Transit”, con il sito web aziendale e con altri sistemi di info-mobilità;
• file .txt conformi allo standard previsto dal sistema “Fleet & Info”, coerente con il formato “GTFS”, per l’integrazione con il sistema AVM fornito dalla società Conduent Business Solutions Italia S.p.A.;
• file di testo in cui vengono riportate informazioni relative all’assegnazione vetture, ai turni macchina e alle corse programmate per l’integrazione con il sistema “DST Plus”;
• file di testo e in formato .csv in cui vengono riportate informazioni relative alle ore lavorate e alle ferie e permessi residui del personale gestito con il sistema software oggetto dell’appalto per l’integrazione con il programma paghe “BPoint”.

Per quanto concerne l’integrazione con il sistema di manutenzione della flotta (“Tour Data”), verrà reso disponibile un file di testo contenente informazioni relative allo stato dei veicoli (in servizio, in riparazione, etc.) e all’orario di rientro in deposito richiesto dal personale addetto alla manutenzione.

Si richiede inoltre l’esportazione automatica su cartella FTP dei seguenti file:

• Orari pieghevoli (.pdf);
• Orari paline (.pdf);
• Disegno di ciascuna linea in formato KML

Al fine di automatizzare i processi di integrazione, si richiede l’implementazione di procedure schedulate con evidenza di eventuali criticità in caso di errori.

Si precisa che, a tutela della proprietà intellettuale dei sistemi in uso, le specifiche tecniche di dettaglio verranno rilasciate in via confidenziale solo a seguito dell’assegnazione dell’Appalto in fase di implementazione del nuovo sistema.

Si precisa che è stato erroneamente indicato 30/70, anziché 40/70.

Si CONFERMA   quanto riportato all’art. 10.3 Riparametrazione e soglie di valutazione dell’offerta tecnica

La somma dei punteggi così ottenuti sarà soggetta alla c.d. seconda riparametrazione, per l’assegnazione del punteggio massimo complessivamente previsto per l’offerta tecnica, attribuendo il punteggio massimo di 70 punti all’offerta tecnica che ha ottenuto il punteggio più alto e ragguagliando i punteggi delle altre offerte in proporzione. L’offerta tecnica che, all’esito di tale seconda riparametrazione, non abbia ottenuto una valorizzazione pari ad almeno 40(quaranta) punti, non sarà ammessa all’apertura della busta contenente la proposta economica.

RISPOSTA 1

Tutta la documentazione è disponibile nella sezione DOCUMENTAZIONE DI GARA al link https://atbbergamo.acquistitelematici.it/tender/107

RISPOSTA 2

Si precisa che la frase “istruzioni trasmesse con la lettera di invito per visualizzare il dettaglio della procedura” è un refuso di una procedura negoziata con inoltro di lettera di inviti.

Si precisa che nessuna lettera d’invito è stata trasmessa trattandosi di Procedura aperta a tutti i partecipanti.

Il manuale con le istruzioni per partecipare alla procedura di gara è disponibile dopo aver eseguito l’accesso in piattaforma.

Accedendo al link https://atbbergamo.acquistitelematici.it/tender/107  nella sezione DOCUMENTAZIONE DI GARA sono disponibili tutti i modelli per partecipare alla procedura.

Si specifica che per eventuali chiarimenti tecnici può essere aperto un ticket all'assistenza tecnica, come da istruzioni pubblicate sul portale. Per chiarimenti di natura amministrativa può essere inviato un quesito a questa stazione appaltante

RISPOSTA 3

Accedendo al link https://atbbergamo.acquistitelematici.it/tender/107  nella sezione DOCUMENTAZIONE DI GARA sono disponibili tutti i modelli per partecipare alla procedura.

RISPOSTA 4

Si conferma quanto già indicato nel capitolato tecnico di gara.

RISPOSTA 5

Si richiede la conservazione dei dati relativi agli ultimi anni di esercizio che verranno meglio definiti in fase contrattuale. 

Come già specificato nella documentazione tecnica di gara, i dati risiedono sul database Oracle del sistema AS400.

• Con riferimento al Cap. 7.8 - Si conferma il contenuto del documento di gara “Allegato 1”.
• Con riferimento al Cap. 2.2 - E’ corretto intendere che le licenze Oracle sono già presenti nell’attuale infrastruttura e che non sono oggetto di fornitura.
• Con riferimento al Cap. 18 - Si precisa che il supporto da parte del personale designato dal Committente è previsto in tutte le fasi del progetto.
• Con riferimento al Cap 18: Oltre alle indicazioni già fornite per le FASE1 e FASE2, si precisa che relativamente alle FASI 3 e 6, dopo la fase “testing“, che prevede la verifica di tutte le funzionalità implementate, le attività connesse alla programmazione e produzione del servizio verranno eseguite utilizzando entrambi i sistemi (il sistema attuale e quello di nuova realizzazione). Appurata l’affidabilità della nuova piattaforma, il periodo di coesistenza dei due sistemi si concluderà nella FASE 6 con la dismissione di AS400.

Ai sensi dell’art. 93  comma 3 del D.Lgs 50/2016 l’impegno a rilasciare garanzia fideiussoria deve essere rilasciato da impresa bancaria o assicurative che rispondano ai requisiti di solvibilità previsti dalle leggi che ne disciplinano le rispettive attività o rilasciata dagli intermediari finanziari iscritti nell’albo di cui di all’articolo 106 del decreto legislativo 1 settembre 1993, n. 385 ecc…

Nella  sezione documentazione di gara è stato pubblicato un modello di dichiarazione d’impegno a rilasciare garanzia.

Con riferimento a pag.12 Cap.3 - Si conferma la possibilità di prevedere applicativi client basati su collegamenti di tipo “Terminal Server”.

Con riferimento al disciplinare di gara al paragrafo 9.7 si conferma che i documenti oggetto di valutazione sono esclusivamente la relazione tecnica di massimo 80 pagine e la relazione tecnica relativa alla Business Intelligence.

1. Si comunica che la copertina e l’indice sono esclusi dal conteggio delle 80 pagine.

2. Con riferimento al punto i) di pag. 15 del capitolato tecnico “avere algoritmi di ottimizzazione del calcolo degli orari dei percorsi dei mezzi”  s’intende che il software sia in grado di ottimizzare il calcolo degli orari di percorrenza tra le fermate di un determinato percorso in base a determinati parametri come potrebbe essere ad esempio la velocità commerciale o la percorrenza media storica di una tratta comune anche ad altri percorsi.

Si conferma quanto indicato nel disciplinare di gara.

Relativamente alla modalità di attestazione del possesso dei requisti nella compilazione del DGUE si conferma quanto richiesto.

• Come specificato all’art. 4.1 del Capitolato di gara gli operatori saranno 15, di cui gli addetti alla pianificazione del servizio almeno 5.
• Ogni operatore può lavorare su tutta la rete.
• Il numero massimo di veicoli inseriti in una programmazione, in questo frangente, è di 202 autobus. In futuro la numerosità dei veicoli potrebbe cambiare.
• In relazione alla programmazione delle linee si rimanda a quanto già scritto nel Capitolato di Gara e alle FAQ già pubblicate.
• La domanda relativa i costi del veicolo è troppo generica e non oggetto di gara.