Contract

Autostrada Pedemontana Lombarda Spa (APL), con sede in Xxxxxx 00000 (XX), Xxx xxx Xxxxx Xxxxxxxxx n. 4/A, Palazzo U9 (Società sottoposta a direzione e coordinamento da parte di “Milano Serravalle – Milano Tangenziali S.p.A.) C.F. e Partita IVA 00000000000, tel. x00 00 0000000, fax x00 00 00000000, e‐mail:

xxxxx@xxxxxxxxxxx.xxx, sito web: xxx.xxxxxxxxxxx.xxx

Procedura per l’affidamento del servizio di gestione operativa del sistema di esazione dei pedaggi dell'Autostrada Pedemontana Lombarda, comprensivo della progettazione esecutiva e della realizzazione mediante fornitura e posa in opera del sistema per il rilevamento dei transiti in modalità free‐flow e della relativa manutenzione.

CUP: F11B06000270007 CIG: 53172193ED

MODELLO N. 8

RELAZIONE DI OTTEMPERANZA AI REQUISITI PRESTAZIONALI

Sommario

1 Istruzioni per la compilazione 3

2 Sistema di Esazione 4

3 Sistema di Pedaggio 5

3.1 Fornitura del sistema 5

3.1.1 Requisiti generali 5

3.1.2 Requisiti funzionali 8

3.1.2.1 Raccolta e trasmissione dei dati di transito 8

3.1.2.2 Gestione delle informazioni di sistema 13

3.1.2.3 Calcolo importo pedaggio 16

3.1.2.4 Enforcement 19

3.1.2.5 Interazioni con sistemi esterni 24

3.1.2.6 Monitoraggio e Gestione del cartellino problemi (trouble ticketing) 29

3.1.3 Requisiti non funzionali 30

3.1.4 Requisiti particolari 34

3.2 Servizio di manutenzione 37

3.2.1 Processi di manutenzione 37

3.2.2 Requisiti sul processo di sviluppo/manutenzione del software 38

3.3 Servizio di gestione operativa 41

3.3.1 Processi di gestione operativa 41

3.3.2 Requisiti sulla gestione operativa 42

4 Sistema di Gestione Clienti 44

4.1 Fornitura del sistema 44

4.1.1 Requisiti generali 44

4.1.2 Requisiti funzionali 49

4.1.2.1 Gestione del magazzino degli OBU 49

4.1.2.2 Gestione delle informazioni di sistema 51

4.1.2.3 Customer Relationship Management 52

4.1.2.4 Gestione dell’insolvenza, del contenzioso e delle non conformità 62

4.1.2.5 Interazioni con sistemi esterni 63

4.1.2.6 Monitoraggio e Gestione del cartellino problemi (trouble ticketing) 65

4.1.3 Requisiti non funzionali 66

4.2 Servizio di manutenzione 73

4.2.1 Processi di manutenzione 73

4.2.2 Requisiti sul processo di sviluppo/manutenzione del software 74

4.3 Servizio di gestione operativa 77

4.3.1 Processi di gestione operativa 77

5 Sistema di Gestione Utenti 79

5.1 Fornitura del sistema 79

5.1.1 Requisiti generali 79

5.1.2 Requisiti funzionali 83

5.1.2.1 Gestione delle informazioni di sistema 83

5.1.2.2 Customer Relationship Management 84

5.1.2.3 Gestione del recupero crediti e del contenzioso 91

5.1.2.4 Interazioni con sistemi esterni 93

5.1.2.5 Monitoraggio e Gestione del cartellino problemi (trouble ticketing) 94

5.1.3 Requisiti non funzionali 95

5.2 Servizio di manutenzione 100

5.2.1 Processi di manutenzione 100

5.2.2 Requisiti sul processo di sviluppo/manutenzione del software 102

5.3 Servizio di gestione operativa 104

5.3.1 Processi di gestione operativa 104

1 Istruzioni per la compilazione

• I requisiti prestazionali sono contenuti nelle tabelle dei capitoli seguenti. Ogni pagina è strutturata in tre colonne così individuate:

1. colonna 1: codice identificativo del requisito prestazionale come risulta dall’Allegato A al Capitolato Speciale d’Appalto

2. colonna 2: descrizione del requisito prestazionale;

3. colonna 3: testo di risposta del concorrente in merito all’ottemperanza al requisito. Il concorrente deve indicare se il requisito risulta “OTTEMPERATO” e specificare in modo sintetico come il requisito viene soddisfatto.

La descrizione deve risultare sufficientemente dettagliata in modo da consentire alla Commissione di gara di valutare l’attendibilità della dichiarazione di ottemperanza.

Sono quindi da evitare le descrizioni generiche o elusive.

Qualora il requisito riguardi un Livello di Servizio Atteso (LSA di cui al capitolo 6 del C.S.A.), il concorrente deve indicare il valore numerico del Livello di Servizio Offerto (LSO) che si impegna a garantire. Il LSO sarà quindi oggetto di attribuzione, da parte della Commissione di gara, del coefficiente stabilito dall’articolo 10 del Disciplinare di gara.

Qualora il concorrente non indichi alcun valore numerico per il corrispondente LSO, sarà attribuito il coefficiente pari a zero corrispondente al valore minimo richiesto.

2 Sistema di Esazione

# Req.	Descrizione	Risposta
A.1	Il Sistema di Esazione deve essere composto dai sistemi seguenti: • Sistema di Pedaggio • Sistema di Gestione Clienti • Sistema di Gestione Utenti
A.2	Il Sistema di Pedaggio deve comprendere: • fornitura e installazione del sistema • servizio di manutenzione • servizio di gestione operativa
A.3	Il Sistema di Gestione Clienti deve comprendere: • fornitura e installazione del sistema • servizio di manutenzione • servizio di gestione operativa
A.4	Il Sistema di Gestione Utenti deve comprendere: • fornitura e installazione del sistema • servizio di manutenzione • servizio di gestione operativa
A.5	Il Sistema di Esazione deve garantire che gli incassi derivanti dal pedaggio risultino in misura non inferiore al 97% del pedaggio dovuto dai veicoli transitati sulla rete APL, così come misurati dal contatore APL.
A.6	Il Sistema di Esazione deve garantire che il sistema di enforcement recupererà i crediti dovuti per il mancato pagamento del pedaggio e per le violazioni per un valore minimo pari ad almeno l’85% dell’ammontare complessivo dei crediti medesimi.

3 Sistema di Pedaggio

3.1 Fornitura del sistema

3.1.1 Requisiti generali

# Req.	Descrizione	Risposta
A	Requisiti generali
A1	Modello di pedaggio
A1.1	Tipo di sistema
A1.1.1	Il Sistema di Pedaggio deve essere un sistema aperto senza barriere. Nota: un sistema aperto di pedaggio rileva i veicoli in itinere non alle entrate/uscite.
A1.1.2	I veicoli sottosposti a pedaggio devono essere tutti i veicoli che utilizzano la rete di APL, dotati o no di OBU, eccetto i veicoli esenti descritti in apposite liste.
A1.2	Conformità al SET
A1.2.1	Per effettuare la transazione EFC, il Sistema di Pedaggio deve essere conforme ad almeno uno dei due standard seguenti: • EN 15509 • ETSI 200674-1.
A1.2.2	Il Sistema di Pedaggio deve supportare il livello 0 di security previsto sia da EN 15509 che da ETSI 200674-1.
A1.2.3	Per effettuare lo scambio di dati con i Service Provider SET, il Sistema di Pedaggio deve essere conforme a EN 12855.
A1.3	Supporto dei veicoli con OBU (electronic tolling)
A1.3.1	Il Sistema di Pedaggio deve essere capace di accettare: • OBU conformi al SET • OBU conformi allo/agli standard scelti per il Req. A1.2.1

# Req.	Descrizione	Risposta
A1.4	Supporto dei veicoli privi di OBU (video tolling)
A1.4.1	Per i veicoli privi di OBU, il Sistema di Pedaggio deve essere capace di rilevarli, determinarne la tariffa del pedaggio, incassare l’importo dovuto.
A1.5	Determinanti della tariffa
A1.5.1	Il Sistema di Pedaggio deve essere in grado di accettare, fra i determinanti della tariffa, le caratteristiche del veicolo come definite in EN 15509 e EN ISO 17575.
A1.5.2	Il Sistema di Pedaggio deve essere in grado di accettare, fra i determinanti della tariffa, gli intervalli di tempo come definiti in EN 15509 e EN ISO 17575.
A1.5.3	Il Sistema di Pedaggio deve essere in grado di accettare, fra i determinanti della tariffa, le categorie di utenti come definite in EN 15509 e EN ISO 17575.
A1.5.4	Il Sistema di Pedaggio deve essere in grado di accettare, fra i determinanti della tariffa, le caratteristiche dell’autostrada come definite in EN 15509 e EN ISO 17575.
A2	Leggi e standard
A2.1	Le leggi e gli standard europei ed italiani applicabili devono essere rispettati durante tutte le fasi della fornitura (progettazione, realizzazione, installazione) del Sistema di Pedaggio.
A2.2	Il Sistema di Pedaggio deve essere conforme alla direttiva europea 2006/38/EC. Nota: La Direttiva Eurovignette è attualmente in revisione.
A2.3	La tecnologia scelta per il Sistema di Pedaggio deve essere conforme alla direttiva europea Directive 2004/52/EC e alla decisione 2009/750/EC.
A2.4	Il Sistema di Pedaggio deve essere conforme alle raccomandazioni e alle decisioni dell’UE in tema di servizi SET. Il Sistema di Pedaggio deve essere progettato e realizzato in modo che possa essere facilmente adattato/modificato per la conformità a futuri standard, decisioni, migliori pratiche che riguardano il SET.

# Req.	Descrizione	Risposta
A2.5	Per il colloquio con i sistemi esterni al Sistema di Pedaggio devono essere utilizzati protocolli ed interfacce standard, ove disponibili.
A2.6	La direttiva R&TTE 1999/5/EC deve essere applicata per tutti gli apparati.
A2.7	Per tutti i dati raccolti, trasmessi, elaborati e memorizzati nel Sistema di Pedaggio deve essere applicata la direttiva 1995/46/EC sulla protezione dei dati individuali e la direttiva 2002/58/EC sulla elaborazione dei dati personali e sulla protezione della privacy nelle comunicazioni elettroniche.
A3	Impatto ambientale
A3.1	L’installazione e l’operatività del Sistema di Pedaggio non devono esporre persone, beni ed ambiente oltre rischi minimi necessari.
A3.2	L’installazione e l’operatività del Sistema di Pedaggio non devono nuocere all’ambiente oltre lo strettamente necessario.
A3.3	Lo smantellamento e lo smaltimento di componenti del Sistema di Pedaggio deve essere possibile senza uso di inquinanti ambientali e di sostanze tossiche.
A3.4	L’installazione del Sistema di Pedaggio non deve mettere a rischio la sicurezza del traffico.
A3.6	L’installazione del Sistema di Pedaggio non deve far aumentare i costi della manutenzione ordinaria della rete autostradale.
A3.7	Per tutte le apparecchiature devono essere applicate le Direttive 2002/95/EC e 2002/96/EC (sull’uso di sostanze pericolose e sui rifiuti elettronici).
A4	Condizioni operative
A4.1	Il Sistema di Pedaggio deve essere progettato ed operare in modo da lavorare in maniera affidabile per il periodo contrattuale in tutte le condizioni ambientali (comprese quelle atmosferiche) che possono presentarsi in Lombardia.

# Req.	Descrizione	Risposta
A4.2	Il Sistema di Pedaggio deve essere in grado di operare: • con tutti i tipi di veicoli sottoposti a pedaggio; • in tutte le situazioni di guida più comuni (per esempio: cambi di corsia, guida sulla corsia di emergenza, …); • in tutte le condizioni di traffico (per esempio: congestione, stop-and-go, traffico a flusso libero, guida in fila, guida in parallelo, …); • in situazioni di deviazione del traffico a causa di aree in costruzione; • in situazioni di restrizione del traffico a causa di opere di manutenzione della strada.
A4.3	Il Sistema di Pedaggio deve operare correttamente nelle seguenti condizioni di traffico: • massima velocità dei veicoli: 200 Km/h; • massima frequenza di veicoli per corsia: o picco: 3 veicoli/s, o media: 1 veicolo/s.
A5	Supporto della lingua
A5.1	La lingua del Sistema di Pedaggio utilizzata in tutte le interfacce interattive e in tutti i documenti stampati per l’Operatore di Sistema deve essere l’italiano.

3.1.2 Requisiti funzionali

3.1.2.1 Raccolta e trasmissione dei dati di transito

# Req.	Descrizione	Risposta
B	Raccolta e trasmissione dei dati di transito Nota: La funzione di Raccolta e trasmissione dei dati di transito è svolta da:

# Req.	Descrizione	Risposta
	• rilevatori, distribuiti sui segmenti elementari di autostrada, che raccolgono le informazioni relative ai transiti e • proxy, logicamente unico nel Sistema di Pedaggio, che concentra tutte le informazioni raccolte dai rilevatori.
B1	Raccolta dei dati di transito
B1.1	Transit Data Record
B1.1.1	La funzione di “Raccolta dei dati di transito” deve raccogliere tutti i dati relativi all’uso della rete APL da parte dei veicoli sia con OBU sia senza OBU.
B1.1.2	La funzione di “Raccolta dei dati di transito” deve generare il Transit Data Record al momento del passaggio del veicolo dal punto di rilevazione.
B1.1.3	Il Transit Data Record deve contenere almeno le informazioni seguenti: • giorno ed ora del transito; • identificatore del segmento elementare di autostrada; • identificatore del rilevatore; • tipo di rilevazione; • dati letti dall’OBU (se disponibili); • attributi del veicolo rilevati (se disponibili); • immagini del veicolo (se disponibili); • immagini di contesto (se disponibili).
B1.1.4	I valori ammessi dell’attributo “tipo di rilevazione” del Transit Data Record devono essere una codifica degli eventi seguenti – che possono presentarsi al momento della rilevazione –: • riconoscimento targa via videocamera e OCR (per tutti i veicoli); • transazione DSRC (solo per veicoli con OBU). Nota: Per uno stesso transito possono essere presenti anche due Transit Data Record: per esempio, nel caso di veicolo con OBU, uno relativo al riconoscimento targa via videocamera e OCR e uno relativo alla transazione DSRC.

# Req.	Descrizione	Risposta
B1.1.5	Il rilevatore che ha generato il Transit Data Record deve memorizzarlo per un tempo configurabile (almeno 48 ore) dal momento della generazione ed eventualmente ritrasmetterlo a richiesta del proxy.
B1.2	Transit Counter
B1.2.1	La funzione di “Raccolta dei dati di transito” deve contare tutti i veicoli che transitano ai punti di rilevazione.
B1.2.2	La funzione di “Raccolta dei dati di transito” deve aggiornare il Transit Counter al momento del passaggio di ogni veicolo dal punto di rilevazione.
B1.2.3	Il Transit Counter deve contenere almeno le informazioni seguenti: • giorno ed ora della rilevazione dei transiti (inizio); • giorno ed ora della rilevazione dei transiti (fine); • identificatore del segmento elementare di autostrada; • identificatore del rilevatore; • numero di veicoli transitati.
B1.2.4	Il rilevatore che ha generato il Transit Counter deve memorizzarlo per un tempo configurabile (almeno 48 ore) dal momento della generazione ed eventualmente ritrasmetterlo a richiesta del proxy.
B2	Trasmissione dei dati di transito
B2.1	Transit Data Record
B2.1.1	La funzione di “Trasmissione dei dati di transito” deve fornire al proxy tutti i Transit Data Record.
B2.1.2	In condizioni operative normali, la funzione di “Trasmissione dei dati di transito” deve fornire al proxy tutti i Transit Data Record con un ritardo configurabile ma non superiore a 5 minuti dopo il transito del veicolo sul segmento di autostrada. Nota: “Condizioni operative normali” significa che i componenti del sistema interessati non sono registrati come non disponibili nella Funzione di Gestione del cartellino problemi.

# Req.	Descrizione	Risposta
B2.1.3	Il proxy deve fornire un rapporto mensile con il numero totale dei Transit Data Record che sono stati inviati e con il numero di trasmissioni che hanno superato il limite di Req. B2.1.2.
B2.2	Transit Counter
B2.2.1	La funzione di “Trasmissione dei dati di transito” deve fornire al proxy tutti i Transit Counter.
B2.2.2	In condizioni operative normali, la funzione di “Trasmissione dei dati di transito” deve fornire al proxy tutti i Transit Counter con una frequenza configurabile, ma non superiore a 60 minuti. Nota: “Condizioni operative normali” significa che i componenti del sistema interessati non sono registrati come non disponibili nella Funzione di Gestione del cartellino problemi.
B2.2.3	Il proxy deve fornire un rapporto mensile con il numero totale dei Transit Counter che sono stati inviati e con il numero di trasmissioni che hanno superato il limite di Req. B2.2.2.
B3	Comunicazione fra rilevatori e proxy
B3.1	Il Partecipante deve specificare il tipo di canale usato per la comunicazione fra rilevatori e proxy ed indicare se le caratteristiche del canale scelto hanno impatto sui Req. B1.2.4, B2.1.2, B2.2.2.
B3.2	L’invio dei Transit Data Record e dei Transit Counter fra rilevatori e proxy deve avvenire su un canale sicuro.
B4	Stati dei rilevatori
B4.1	I rilevatori devono avere almeno i seguenti stati: • attivo: tutti gli apparati che compongono il rilevatore sono operativi e rilevano i veicoli in transito; • inattivo: tutti gli apparati che compongono il rilevatore non sono operativi e non rilevano i veicoli in transito.

# Req.	Descrizione	Risposta
B4.2	Lo stato dei rilevatori deve essere pilotabile dalla funzione di Monitoraggio.
B5	Apparati dei rilevatori
B5.1	Electronic tolling
B5.1.1	I rilevatori devono poter rilevare il transito dei veicoli che procedono sulle corsie di marcia, sulla corsia di emergenza e in tutte le altre situazioni che possono presentarsi (per esempio: durante il cambio di corsia ad inizio o fine sorpasso).
B5.1.2	La conformità delle RSE allo/agli standard scelti per il Req. A1.2.1 deve essere almeno autocertificata.
B5.1.3	Nella transazione EFC utilizzata deve essere supportato il livello 0 di security previsto sia da ETSI 200674-1 che da EN 15509.
B5.2	Video tolling
B5.2.1	I rilevatori devono poter rilevare il transito dei veicoli che procedono sulle corsie di marcia, sulla corsia di emergenza e in tutte le altre situazioni che possono presentarsi (per esempio: durante il cambio di corsia ad inizio o fine sorpasso).
B5.2.2	Ogni rilevatore per il video tolling deve essere costituito anche da almeno un sistema OCR (Optical Characters Recognition).
B5.2.3	Le videocamere devono catturare l’immagine della targa anteriore e della targa posteriore.
B5.2.4	Quattro videocamere di contesto devono essere previste per carreggiata.
B5.2.5	Almeno le targhe di tutti gli stati europei devono essere riconosciute. Nota: Gli stati europei sono: Albania, Andorra, Austria, Belgio, Bielorussia, Bosnia ed Erzegovina, Bulgaria, Cipro, Città del Vaticano, Croazia, Danimarca, Estonia, Finlandia, Francia, Georgia, Germania, Grecia, Irlanda, Islanda, Italia, Lettonia, Liechtenstein, Lituania, Lussemburgo, Macedonia, Malta, Moldavia, Monaco, Montenegro, Norvegia, Paesi Bassi, Polonia, Portogallo, Regno Unito, Rep. Ceca, Romania, Russia, San Marino, Serbia,

# Req.	Descrizione	Risposta
	Slovacchia, Slovenia, Spagna, Svezia, Svizzera, Turchia, Ucraina, Ungheria.
B5.2.6	Il sistema deve essere predisposto per il riconoscimento delle targhe di nazionalità extra-europea.
B6	Posizionamento dei rilevatori
B6.1	I rilevatori devono essere posizionati su ogni segmento elementare. Nota: Il segmento elementare è il tratto autostradale compreso fra uno svincolo di entrata e uno svincolo di uscita.
B6.2	I rilevatori non devono essere posizionati sugli svincoli di entrata o di uscita ad eccezione dello svincolo di Grandate.
B6.3	Ogni segmento elementare deve avere due rilevatori identici. Nota: Il segmento elementare è il tratto autostradale compreso fra uno svincolo di entrata e uno svincolo di uscita.
B6.4	Il posizionamento preciso dei rilevatori sui segmenti elementari dovrà essere concordato con APL. Nota: Il segmento elementare è il tratto autostradale compreso fra uno svincolo di entrata e uno svincolo di uscita.

3.1.2.2 Gestione delle informazioni di sistema

# Req.	Descrizione	Risposta
C	Gestione delle informazioni di sistema
C1	Informazioni del contesto di pedaggio
C1.1	Il Sistema di Pedaggio deve permettere la definizione e la modifica del Toll Context Overview, con gli attributi specificati in EN 17575-3.
C1.2	Il Sistema di Pedaggio deve permettere la definizione e la modifica della Tariff Table, con gli attributi specificati in EN 17575-3.

# Req.	Descrizione	Risposta
C1.3	Il Sistema di Pedaggio deve permettere la definizione e la modifica della Tariff Class Definition, con gli attributi specificati in EN 17575-3.
C1.4	Il Sistema di Pedaggio deve permettere la definizione e la modifica della Local Vehicle Class Definition, con gli attributi specificati in EN 17575-3.
C1.5	Il Sistema di Pedaggio deve permettere la definizione e la modifica della Time Class Definition, con gli attributi specificati in EN 17575-3.
C1.6	Il Sistema di Pedaggio deve permettere la definizione e la modifica della User Class Definition, con gli attributi specificati in EN 17575-3.
C1.7	Il Sistema di Pedaggio deve permettere la definizione e la modifica del Toll Context Layout, limitatamente al Section Layout, con gli attributi specificati in EN 17575-3.
C1.8	Vincoli di integrità
C1.8.1	Il Sistema di Pedaggio deve gestire differenti versioni dei gruppi di informazioni relative al contesto di pedaggio, descritte nei Req. C1.1 ÷ C1.7
C1.8.2	In ogni specifico istante di tempo, solo una versione dei gruppi di informazioni relative al contesto di pedaggio, descritte nei Req. C1.1 ÷ C1.7, deve essere attiva.
C1.8.3	Ogni versione non più attiva dei gruppi di informazioni relative al contesto di pedaggio, descritte nei Req. C1.1 ÷ C1.7, non deve essere cancellata.
C1.9	Interfaccia
C1.9.1	Il Sistema di Pedaggio deve fornire le funzioni necessarie per gestire (creazione, modifica e lettura) i gruppi di informazioni relative al contesto di pedaggio, descritte nei Req. C1.1 ÷ C1.7.
C1.9.2	Le funzioni di gestione dei gruppi di informazioni relative al contesto di pedaggio, descritte nei Req. C1.1 ÷ C1.7, devono essere disponibili: • sull’interfaccia interattiva disponibile all’Operatore di Sistema; • per mezzo di programmi di utilità di import/export.
C1.9.3	Il Sistema di Pedaggio deve assicurare la consistenza e l’integrità dei dati del

# Req.	Descrizione	Risposta
	contesto di pedaggio.
C1.9.4	Per ogni modifica ai dati del contesto di pedaggio deve essere registrato l’autore e la data.
C2	Service Provider
C2.1	Il Sistema di Pedaggio deve permettere la definizione e la modifica dei Service Provider supportati.
C2.2	Ogni Service Provider deve essere identificato con: • country code della nazione in cui opera, codificato secondo EN ISO 3166- 1; • identificatore univoco per nazione, contenuto nel registro ISO 14816.
C2.3	Interfaccia
C2.3.1	Il Sistema di Pedaggio deve fornire le funzioni necessarie per gestire (creazione, modifica e lettura) i Service Provider.
C2.3.2	Le funzioni di gestione dei Service Provider devono essere disponibili sull’interfaccia interattiva disponibile all’Operatore di Sistema.
C3	Liste di eccezioni
C3.1	Il Sistema di Pedaggio deve permettere la definizione e la modifica delle liste di eccezioni, con gli attributi specificati in EN 12875.
C3.2	I tipi di liste di eccezioni devono essere: • lista dei clienti del Service Provider non più accettati; • lista dei clienti del Service Provider che sono esentati dal pagamento del pedaggio.
C3.3	Vincoli di integrità
C3.3.1	Ogni lista di eccezioni deve essere logicamente collegata al Service Provider originatore.
C3.3.2	Il Sistema di Pedaggio deve gestire differenti versioni delle liste di eccezioni in

# Req.	Descrizione	Risposta
	funzione di: • Service Provider originatore; • periodo di validità.
C3.3.3	In ogni specifico istante di tempo, solo una versione di una lista di eccezioni deve essere attiva.
C3.3.4	Ogni versione non più attiva di una lista di eccezioni non deve essere cancellata.
C3.4	Interfaccia
C3.4.1	Il Sistema di Pedaggio deve fornire le funzioni necessarie per gestire (creazione e lettura) le liste di eccezioni.
C3.4.2	La funzione di lettura delle liste di eccezioni devono essere disponibili sull’interfaccia interattiva disponibile all’Operatore di Sistema.

3.1.2.3 Calcolo importo pedaggio

# Req.	Descrizione	Valutazione
D	Calcolo importo pedaggio
D1	Caratteristiche generali
D1.1	La funzione “Calcolo importo pedaggio” deve calcolare il pedaggio per ogni veicolo rilevato ricavando le informazioni sui transiti dai Transit Data Record non ancora elaborati.
D1.2	La funzione “Calcolo importo pedaggio” deve conservare i Transit Data Record elaborati in un archivio storico.
D2	Controlli di completezza e di consistenza
D2.1	La funzione “Calcolo importo pedaggio” deve effettuare il controllo di completezza nei transiti rilevati per uno stesso veicolo. Nota: il controllo di completezza consiste nel decidere se la mancanza di

# Req.	Descrizione	Valutazione
	registrazione (gap) della rilevazione del veicolo in uno o più punti di rilevazione è da considerarsi una malfunzione del Sistema di Pedaggio o no; il suo verdetto è (in alternativa): • la mancanza è un fallimento di rilevazione; • la mancanza non è un fallimento di rilevazione.
D2.2	La funzione “Calcolo importo pedaggio” deve effettuare il controllo di consistenza nei transiti rilevati per uno stesso veicolo. Nota: il controllo di consistenza consiste nel decidere se la presenza di registrazione della rilevazione del veicolo in uno o più punti di rilevazione è da considerarsi una malfunzione del Sistema di Pedaggio o no; il suo verdetto è (in alternativa): • la presenza è un fallimento di rilevazione; • la presenza non è un fallimento di rilevazione.
D2.3	I parametri usati dagli algoritmi dei controlli di completezza e di consistenza devono essere configurabili.
D3	Calcolo del pedaggio
D3.1	La funzione “Calcolo importo pedaggio” deve calcolare l’importo del pedaggio di ogni segmento elementare che compone il viaggio in base alla tariffa e ai quattro determinanti della tariffa in vigore al momento del viaggio: a. locazione; b. caratteristiche veicolo, compresa la classe di emissione (Eurox), in coerenza con la Direttiva 2011/76/EC; c. classe di utente; d. classe di tempo.
D4	Costruzione del Charging Data Record
D4.1	La funzione “Calcolo importo pedaggio” deve registrare il viaggio del veicolo con l’importo calcolato nel Charging Data Record.
D4.2	Il Charging Data Record deve contenere almeno le informazioni seguenti:

# Req.	Descrizione	Valutazione
	• identificatore del Charging Data Record; • una almeno fra: • identificatore dell’OBU; • Personal Account Number (PAN); • targa del veicolo; • identificatore del Service Provider; • giorno ed ora di inizio viaggio (prima rilevazione); • giorno ed ora di fine viaggio (ultima rilevazione); • per ogni segmento elementare di autostrada che compone il viaggio: • identificatore del segmento di autostrada; • importo pedaggio; • se rilevazione fallita: o segnale di “segmento elementare dedotto”; • se rilevazione effettuata con successo: o identificatore dell’apparato di rilevazione; o data ed ora della rilevazione; • attributi del veicolo dichiarati (se disponibili); • attributi del veicolo rilevati (se disponibili); • totale importo pedaggio; • totale importo pedaggio dei segmenti elementari dedotti (con rilevazione fallita); • immagini del veicolo (se disponibili); • immagini di contesto (se disponibili).
D5	Statistiche e reportistica
D5.1	La funzione “Calcolo importo pedaggio” deve produrre rapporti relativi a periodi temporali di lunghezza configurabile e contenenti la distribuzione del numero di veicoli riconosciuti (che hanno cioè un Charging Data Record ) e del numero totale

# Req.	Descrizione	Valutazione
	dei veicoli transitati (ricavato dai Transaction Counter) per tutti i segmenti dell’autostrada.
D5.2	La funzione “Calcolo importo pedaggio” deve essere in grado di visualizzare i rapporti di cui al Req. D5.1, di stamparli e di esportarne i dati contenuti in un formato compatibile con i più diffusi prodotti di office automation.
D5.3	La funzione “Calcolo importo pedaggio” deve produrre rapporti sui gap scoperti periodicamente o a richiesta. Il rapporto deve contenere: • numero totale di gap; • numero di gap: o per segmento elementare di autostrada; o per veicolo; o per PAN; o per intervallo temporale.

3.1.2.4 Enforcement

# Req.	Descrizione	Risposta
E	Enforcement
E1	La funzione di Enforcement deve: • scoprire i veicoli non conformi e fornire le informazioni che provano (anche legalmente) la violazione; • riconoscere le targhe non riconosciute dalla funzione “Raccolta dati di transito”; • generare i Non-Compliance Record e gli Unidentified Vehicle.
E2	Verifica automatica dei transiti
E2.1	Il Sistema di Pedaggio deve effettuare la funzione “Verifica automatica dei

# Req.	Descrizione	Risposta
	transiti”.
E2.2	Ricerca dei transiti di uno stesso veicolo
E2.2.1	La funzione “Verifica automatica dei transiti” deve ricercare – nei Transit Data Record che provengono sia dall’electronic tolling sia dal video-tolling – uno stesso veicolo, utilizzando una o più delle informazioni di identificazione del veicolo che i Transit Data Record mettono a disposizione: • identificatore dell’OBU; • Personal Account Number (PAN); • targa del veicolo; • identificatore del Service Provider.
E2.3	Classificazione dei Transit Data Record
E2.3.1	La funzione “Verifica automatica dei transiti” deve esaminare i Transit Data Record classificandoli nelle categorie seguenti: • veicoli con OBU che: o generano pedaggio e ▪ non sono in lista clienti non più accettati; ▪ sono in lista clienti non più accettati; o non generano pedaggio (sono in lista clienti esenti); o sono in anomalia perché: ▪ la transazione EFC non è terminata correttamente; ▪ la transazione EFC è terminata correttamente ma le caratteristiche del veicolo rilevate differiscono da quelle dichiarate; • veicoli senza OBU: o a cui è stata riconosciuta la targa e: ▪ generano pedaggio; ▪ non generano pedaggio (sono in lista clienti esenti);

# Req.	Descrizione	Risposta
	o a cui non è stata riconosciuta la targa.
E2.3.2	I Transit Data Record classificati dalla funzione “Verifica automatica dei transiti” devono essere instradati in maniera opportuna alle funzioni: • Calcolo importo pedaggio; • Verifica manuale dei transiti.
E3	Verifica manuale dei transiti
E3.1	Il Sistema di Pedaggio deve permettere la “Verifica manuale dei transiti”.
E3.2	Il processo di “Verifica manuale dei transiti” elabora i Transit Data Record e svolge le seguenti attività: • esame delle immagini; • verifica dell’applicabilità del pedaggio; • verifica delle caratteristiche del veicolo; • determinazione della targa; • controllo della targa all’interno delle liste di veicoli esenti; • verdetto finale sui dati valutati (conformità/non conformità/non riconoscimento).
E3.3	Poichè alcune delle attività precedenti richiedono l’intervento umano, l’Appaltatore deve provvedere ad attrezzare uno specifico reparto per questo compito.
E3.4	Il processo di “Verifica manuale dei transiti” deve essere supportato dalla funzione “Verifica manuale dei transiti”.
E3.5	I Transit Data Record elaborati mediante la funzione “Verifica manuale dei transiti” devono essere quelli che la funzione “Verifica automatica dei transiti” ha classificato come: • veicoli con OBU in anomalia perché: o la transazione EFC non è terminata correttamente; o la transazione EFC è terminata correttamente ma le caratteristiche del veicolo rilevate differiscono da quelle dichiarate.

# Req.	Descrizione	Risposta
	• veicoli senza OBU a cui non è stata riconosciuta la targa.
E3.6	Il processo di “Verifica manuale dei transiti” deve: • in caso di verdetto di “non conformità”, generare un Non-Compliance Record; • in caso di verdetto di “conformità” o di “non conformità”, colmare le informazioni mancanti nel Transit Data Record; • in caso di verdetto di “non riconoscimento”, generare un Unidentified Vehicle Record.
E3.7	La funzione “Verifica manuale dei transiti” deve fornire rapporti che descrivono l’esito del processo relativo ad un periodo temporale di durata configurabile, con confronti rispetto ai periodi precedenti.
E3.8	La funzione di “Verifica manuale dei transiti” deve fornire una misura della produttività (per esempio: quantità di Transit Data Record trattati / quantità di Transit Data Record da trattare) del personale addetto al processo, mediante un’interfaccia interattiva e rapporti periodici riepilogativi.
E3.9	La “Verifica manuale dei transiti” deve essere eseguita a campione anche sugli altri veicoli non compresi nell’elenco di Req. E3.5.
E3.10	La “Verifica manuale dei transiti” deve essere in grado di riconoscere almeno l’80,0% delle targhe dei veicoli non riconosciuti dalla funzione “Verifica automatica dei transiti”.
E4	Gestione delle non conformità
E4.1	Il Sistema di Pedaggio deve scoprire le non conformità, che possono derivare da violazioni o frodi. Nota: Esempi di non conformità sono: • non corrispondenza fra caratteristiche dichiarate e rilevate del veicolo; • rilevazione del transito di un OBU in lista veicoli non più accettati; • targa contraffatta. Alcune non conformità possono anche generare un pedaggio.

# Req.	Descrizione	Risposta
E4.2	Le non conformità devono essere registrate nel Non-Compliance Record che contiene almeno le informazioni seguenti: • giorno ed ora della rilevazione del transito; • identificatore del segmento di autostrada; • identificatore del rilevatore; • dati letti dall’OBU (se disponibili); • attributi del veicolo rilevati (se disponibili); • immagini del veicolo (se disponibili); • immagini di contesto (se disponibili); • tipo di non conformità.
E4.3	I Non-Compliance Record devono essere trasmessi ai Service Provider di competenza o al Sistema di Gestione Clienti o al Sistema di Gestione Utenti, secondo il protocollo stabilito di interfaccia.
E4.4	Il Sistema di Pedaggio deve produrre un rapporto periodico che indichi l’andamento dei Non-Compliance Record nel tempo e li classifichi per tipologia e/o gravità. Nota: Alcune non conformità possono generare anche un pedaggio.
E5	Gestione dei veicoli non identificati
E5.1	Il Sistema di Pedaggio deve conservare le registrazioni dei veicoli non identificati.
E5.2	L’Unidentified Vehicle Record deve contenere almeno le informazioni seguenti: • giorno ed ora della rilevazione del transito; • identificatore del segmento di autostrada; • identificatore del rilevatore; • dati letti dall’OBU (se disponibili); • attributi del veicolo rilevati (se disponibili);

# Req.	Descrizione	Risposta
	• immagini del veicolo (se disponibili); • immagini di contesto (se disponibili); • tipo di non identificazione.
E5.3	Il Sistema di Pedaggio deve produrre un rapporto periodico che indichi l’andamento degli Unidentified Vehicle Record nel tempo e li classifichi per rilevatore.

3.1.2.5 Interazioni con sistemi esterni

# Req.	Descrizione	Risposta
F	Interazioni con sistemi esterni
F1	Interazioni con Service Provider
F1.1	Supporto del SET e del SIT
F1.1.1	Il Sistema di Pedaggio deve essere conforme al SET, cioè alla Direttiva UE 2004/52 e alla Decisione UE 2009/750.
F1.1.2	Il Sistema di Pedaggio deve essere in grado di adottare futuri nuovi standard o specifiche SET.
F1.1.3	Il Sistema di Pedaggio deve essere in grado di accettare Service Provider SET e, in questo contesto, di dare supporto ad APL nel suo ruolo di Toll Charger.
F1.1.4	Il Sistema di Pedaggio deve essere in grado di accettare OBU SET.
F1.2	Scambio dati con Service Provider SET
F1.2.1	Il Sistema di Pedaggio deve essere in grado di scambiare con i Service Provider i dati back office secondo EN ISO 12855.
F1.2.2	Il Sistema di Pedaggio deve essere in grado di utilizzare un canale di comunicazione sicuro nello scambio dati secondo EN ISO 12855 con i Service Provider.

# Req.	Descrizione	Risposta
F1.2.3	Il Sistema di Pedaggio deve essere in grado di ricevere dai Service Provider le Exception List di tipo black list (liste di clienti del Service Provider non più accettati) secondo il protocollo e il formato dei messaggi previsto per questo scambio da EN ISO 12855 e di gestire le risposte possibili.
F1.2.4	Il Sistema di Pedaggio deve essere in grado di inviare ai Service Provider i Toll Context Data secondo il protocollo e il formato dei messaggi previsto per questo scambio da EN ISO 12855 e di gestire le risposte possibili.
F1.2.5	Il Sistema di Pedaggio deve essere in grado di inviare ai Service Provider i Billing Details secondo il protocollo e il formato dei messaggi previsto per questo scambio da EN ISO 12855 e di gestire le risposte possibili. Il Sistema di Pedaggio deve essere in grado di generare i Billing Details da inviare.
F1.2.6	Il Sistema di Pedaggio deve essere in grado di inviare ai Service Provider i Payment Claim secondo il protocollo e il formato dei messaggi previsto per questo scambio da EN ISO 12855 e di gestire le risposte possibili. Il Sistema di Pedaggio deve essere in grado di generare i Payment Claim da inviare.
F1.2.7	Il Sistema di Pedaggio deve essere in grado di inviare ai Service Provider i Retrieve User Details secondo il protocollo e il formato dei messaggi previsto per questo scambio da EN ISO 12855 e di gestire le risposte possibili. Il Sistema di Pedaggio deve essere in grado di generare i dati necessari per i Retrieve User Details.
F1.2.8	Il Sistema di Pedaggio deve essere in grado di ricevere dai Service Provider le Exception List di tipo white list (liste di clienti del Service Provider non soggetti a pedaggio) secondo il protocollo e il formato dei messaggi previsto per questo scambio da EN ISO 12855 e di gestire le risposte possibili.
F1.2.9	Il Sistema di Pedaggio deve essere in grado di ricevere/inviare dai/ai Service Provider i Trust Objects secondo il protocollo e il formato dei messaggi previsto per questo scambio da EN ISO 12855.

# Req.	Descrizione	Risposta
	I Trust Objects comprendono almeno le chiavi master per il colloquio in DSRC fra OBU e RSE. Il Sistema di Pedaggio deve essere in grado di: • usare i Trust Objects ricevuti; • generare i Trust Objects da inviare.
F1.2.10	Il Sistema di Pedaggio deve essere in grado di ricevere dai Service Provider i Provide User Details secondo il protocollo e il formato dei messaggi previsto per questo scambio da EN ISO 12855 e di gestire le risposte possibili.
F1.3	Accettazione di Service Provider SET
F1.3.1	Il Sistema di Pedaggio deve essere in grado di accettare i Service Provider conformi al SET che potranno presentarsi in futuro.
F1.3.2	Il Sistema di Pedaggio deve avere una procedura di accettazione “tecnica” del nuovo Service Provider.
F1.3.3	La procedura di accettazione tecnica deve essere composta da una serie di passi di test volti alla verifica dell’idoneità all’uso di: • OBU; • sistema back-end; del Service Provider.
F1.3.4	La verifica dell’idoneità all’uso deve comprendere casi di test per la verifica di almeno queste caratteristiche: • interoperabilità; • prestazioni (performance); • disponibilità (availability).
F1.4	Riscossione pedaggi
F1.4.1	Il Sistema di Pedaggio deve ricevere i pagamenti dei pedaggi dai Service Provider SET.

# Req.	Descrizione	Risposta
F2	Interazioni con i Sistemi di Gestione
F2.1	Interazioni con Sistema di Gestione Clienti
F2.1.1	Il Sistema di Pedaggio deve essere in grado di scambiare con il Sistema di Gestione Clienti i dati back office secondo EN ISO 12855.
F2.1.2	Il Sistema di Pedaggio deve essere in grado di utilizzare un canale di comunicazione sicuro nello scambio dati secondo EN ISO 12855 con il Sistema di Gestione Clienti.
F2.1.3	Il Sistema di Pedaggio deve essere in grado di ricevere dal Sistema di Gestione Clienti le Exception List di tipo black list (liste di clienti del Sistema di Gestione Clienti non più accettati) secondo il protocollo e il formato dei messaggi previsto per questo scambio da EN ISO 12855 e di gestire le risposte possibili.
F2.1.4	Il Sistema di Pedaggio deve essere in grado di inviare al Sistema di Gestione Clienti i Toll Context Data secondo il protocollo e il formato dei messaggi previsto per questo scambio da EN ISO 12855 e di gestire le risposte possibili.
F2.1.5	Il Sistema di Pedaggio deve essere in grado di inviare al Sistema di Gestione Clienti i Billing Details secondo il protocollo e il formato dei messaggi previsto per questo scambio da EN ISO 12855 e di gestire le risposte possibili. Il Sistema di Pedaggio deve essere in grado di generare i Billing Details da inviare.
F2.1.6	Il Sistema di Pedaggio deve essere in grado di inviare al Sistema di Gestione Clienti i Payment Claim secondo il protocollo e il formato dei messaggi previsto per questo scambio da EN ISO 12855 e di gestire le risposte possibili. Il Sistema di Pedaggio deve essere in grado di generare i Payment Claim da inviare.
F2.1.7	Il Sistema di Pedaggio deve essere in grado di inviare al Sistema di Gestione Clienti i Retrieve User Details secondo il protocollo e il formato dei messaggi previsto per questo scambio da EN ISO 12855 e di gestire le risposte possibili. Il Sistema di Pedaggio deve essere in grado di generare i dati necessari per i

# Req.	Descrizione	Risposta
	Retrieve User Details.
F2.1.8	Il Sistema di Pedaggio deve essere in grado di ricevere dal Sistema di Gestione Clienti le Exception List di tipo white list (liste di clienti del Sistema di Gestione Clienti non soggetti a pedaggio) secondo il protocollo e il formato dei messaggi previsto per questo scambio da EN ISO 12855 e di gestire le risposte possibili.
F2.1.9	Il Sistema di Pedaggio deve essere in grado di ricevere/inviare dal/al Sistema di Gestione Clienti i Trust Objects secondo il protocollo e il formato dei messaggi previsto per questo scambio da EN ISO 12855. I Trust Objects comprendono almeno le chiavi master per il colloquio in DSRC fra OBU e RSE. Il Sistema di Pedaggio deve essere in grado di: • usare i Trust Objects ricevuti; • generare i Trust Objects da inviare.
F2.2	Interazioni con Sistema di Gestione Utenti
F2.2.1	Il Sistema di Pedaggio deve essere in grado di scambiare con il Sistema di Gestione Utenti i dati back office secondo EN ISO 12855.
F2.2.2	Il Sistema di Pedaggio deve essere in grado di utilizzare un canale di comunicazione sicuro nello scambio dati secondo EN ISO 12855 con il Sistema di Gestione Utenti .
F2.2.3	Il Sistema di Pedaggio deve essere in grado di inviare al Sistema di Gestione Utenti i Toll Context Data secondo il protocollo e il formato dei messaggi previsto per questo scambio da EN ISO 12855 e di gestire le risposte possibili.
F2.2.4	Il Sistema di Pedaggio deve essere in grado di inviare al Sistema di Gestione Utenti i Billing Details secondo il protocollo e il formato dei messaggi previsto per questo scambio da EN ISO 12855 e di gestire le risposte possibili. Il Sistema di Pedaggio deve essere in grado di generare i Billing Details da inviare.
F2.2.5	Il Sistema di Pedaggio deve essere in grado di inviare al Sistema di Gestione

# Req.	Descrizione	Risposta
	Utenti i Payment Claim secondo il protocollo e il formato dei messaggi previsto per questo scambio da EN ISO 12855 e di gestire le risposte possibili. Il Sistema di Pedaggio deve essere in grado di generare i Payment Claim da inviare.
F2.3	Riscossione pedaggi
F2.3.1	Il Sistema di Pedaggio deve ricevere i pagamenti dei pedaggi dal Sistema di Gestione Clienti e dal Sistema di Gestione Utenti.
F3	Interazioni con sistemi di APL
F3.1	Versamento pedaggi ad APL
F3.1.1	Il Sistema di Pedaggio deve versare sul c/c bancario indicato da APL i pedaggi ricevuti da: • Service Provider SET; • Sistema di Gestione Clienti; • Sistema di Gestione Utenti.

3.1.2.6 Monitoraggio e Gestione del cartellino problemi (trouble ticketing)

# Req.	Descrizione	Risposta
G	Monitoraggio e Gestione del cartellino problemi (trouble ticketing)
G1	Monitoraggio
G1.1	La funzione di “Monitoraggio” deve informare in tempo reale l’Operatore di Sistema sullo stato corrente del Sistema di Pedaggio e deve generare automaticamente gli allarmi su eventuali malfunzioni.
G1.2	La funzione “Monitoraggio” deve monitorare: • tutti i rilevatori; • gli apparati di comunicazione;

# Req.	Descrizione	Risposta
	• il sistema centrale (principale e ridondato).
G1.2.1	La funzione di “Monitoraggio” deve monitorare le caratteristiche di disponibilità (availability) e di prestazioni (performance) di ogni funzione del Sistema di Pedaggio.
G1.3	L’interfaccia di accesso dell’Operatore di Sistema alle informazioni prodotte dalla funzione di Monitoraggio deve essere via browser. L’accesso deve essere regolato da diritti di accesso, definiti da APL.
G1.4	La funzione di “Monitoraggio” non deve interferire con le normali operazioni del Sistema di Pedaggio.
G2	Gestione del cartellino problemi (trouble ticketing)
G2.1	Il Sistema di Pedaggio deve avere la funzione di “Gestione del cartellino problemi” (trouble ticketing).
G2.2	La funzione di “Gestione del cartellino problemi” deve documentare ogni evento anomalo del Sistema di Pedaggio ed ogni attività di risoluzione problemi.
G2.3	Ogni evento od ogni azione legata alla gestione del cartellino deve essere documentata.
G2.4	APL deve avere libero accesso alla funzione di “Gestione del cartellino problemi”, comprese le funzionalità di reportistica.
G2.5	APL deve avere la possibilità di creare cartellini problemi.

3.1.3 Requisiti non funzionali

# Req.	Descrizione	Risposta
H	Requisiti non funzionali
H1	Portabilità

# Req.	Descrizione	Risposta
H1.1	Installazione e dis-installazione
H1.1.1	Il Sistema di Pedaggio deve avere una procedura documentata di installazione dell’intero sistema.
H1.1.2	La documentazione della procedura di installazione deve comprendere almeno: • prerequisiti d’installazione (diritti di accesso, hardware, software, strumenti, persone necessarie, durata, …); • dipendenze da altri sistemi, interfacce, applicazioni; • descrizione delle procedure automatiche e dei passi manuali dell’installazione; • punti di controllo per la verifica di correttezza dell’installazione. Ogni attività di installazione deve essere documentata appropriatamente.
H1.1.3	Ogni installazione (completa o parziale, cioè di una modifica – upgrade – o di una correzione di un errore – patch –) deve poter essere dis-installata. La procedura di dis-installazione non deve perturbare il resto dell’installazione.
H2	Affidabilità
H2.1	Salvataggio (backup) e ripristino (restore) dei dati
H2.1.1	Il Sistema di Pedaggio deve avere una procedura di salvataggio (backup) e di ripristino (restore) dei dati del sistema.
H2.1.2	Il backup deve poter essere eseguito senza perturbare le normali operazioni.
H2.1.3	L’Appaltatore dovrà eseguire periodici test di restore che forniscano l’evidenza che la funzione di restore funziona correttamente.
H2.1.4	L’Appaltatore dovrà eseguire almeno: • un backup giornaliero dei dati del Sistema di Pedaggio in sette generazioni; • un backup settimanale e uno mensile in tre generazioni.
H2.2	Disponibilità (availability) e business continuity

# Req.	Descrizione	Risposta
H2.2.1	L’Appaltatore dovrà progettare, realizzare e mantenere una descrizione dei principi di business continuity possibilmente basata su standard e migliori pratiche. In particolare, essa dovrà descrivere come sono assicurati i Service Level Agreement in caso di eventi come caduta del sistema, perdita della connessione di comunicazione e così via.
H2.2.2	Il sistema centrale deve essere costituito da un sistema principale e uno di backup o secondario con la funzionalità di hot-standby.
H2.2.3	I due sistemi, principale e di backup, devono essere ubicati in due località differenti. Nota: APL si riserva la facoltà di richiedere il trasferimento dei due sistemi in locazioni proprie.
H2.2.4	Il sistema di backup deve essere in grado di prendere in carico tutte le elaborazioni del sistema principale senza significative perturbazioni dei business process.
H2.2.5	Tutti i dati del sistema principale devono essere disponibili in tempo reale anche sul sistema di backup (mirroring).
H2.2.6	Il Sistema di Pedaggio deve assicurare caratteristiche di alta disponibilità in caso di disastro, in accordo al livello di servizio stabilito.
H2.2.7	L’Appaltatore dovrà progettare ed eseguire test del caso di disastro.
H2.3	Up-Time del sistema centrale
H2.3.1	Il sistema centrale del Sistema di Pedaggio deve avere una disponibilità (availability) di almeno il 99.5 %. Nota: La indisponibilità del sistema centrale significa l’ indisponibilità sia del sistema primario che del sistema secondario.
H2.3.2	Il sistema centrale del Sistema di Pedaggio non deve avere un down-time continuativo di più di 6 ore.
H2.3.3	Il sistema centrale del Sistema di Pedaggio deve avere funzioni per la supervisione remota della sua disponibilità da parte della funzione di

# Req.	Descrizione	Risposta
	Monitoraggio. Ogni evento di non disponibilità deve essere riportato in un cartellino problemi. La funzione Monitoraggio o la funzione Gestione del cartellino problemi devono fornire un rapporto annuale di tutti gli eventi di non disponibilità del Sistema di Pedaggio e delle loro durate.
H2.4	Affidabilità dell’infrastruttura dei portali
H2.4.1	Per l’electronic tolling, la funzione Raccolta dei dati di transito deve assicurare che l’Indice di Rilevazione dei Veicoli (IRV) sia almeno del 99,0 %. Nota: l’Indice di Rilevazione dei Veicoli è definito come rapporto fra il numero dei veicoli con OBU rilevati e il numero dei veicoli transitati. APL avrà un sistema, indipendente ed esterno alla fornitura, dedicato al conteggio dei veicoli, che sarà usato come denominatore dell’IRV.
H2.4.2	Per il video tolling, la funzione Raccolta dei dati di transito deve assicurare che l’Indice di Rilevazione dei Veicoli (IRV) sia almeno del 95,0 %. Nota: l’Indice di Rilevazione dei Veicoli è definito come rapporto fra il numero dei veicoli rilevati e il numero dei veicoli transitati. APL avrà un sistema, indipendente ed esterno alla fornitura, dedicato al conteggio dei veicoli, che sarà usato come denominatore dell’IRV, cioè come numero dei veicoli transitati.
H2.5	Affidabilità dell’intero sistema
H2.5.1	Il Sistema di Pedaggio deve assicurare che l’Indice di Rilevazione dei Veicoli (IRV) complessivo sia almeno del 99,0 %.
H3	Prestazioni
H3.1	Il Sistema di Pedaggio deve avere caratteristiche di scalabilità per adattarsi ad aumenti o decrementi progressivi o inattesi del carico di sistema (system load).
H3.2	Gestione del tempo di sistema
H3.2.1	La differenza di tempo fra tutti i componenti del Sistema di Pedaggio non deve superare un secondo. Questo si applica anche tutti i time-stamp generati.

# Req.	Descrizione	Risposta
H3.2.2	Tutte le interfacce HMI del Sistema di Pedaggio devono mostrare il tempo locale. Tutti i componenti del Sistema di Pedaggio devono essere capaci di convertire da CET (Central European Time) a CEST (Central European Summer Time) e viceversa senza generare malfunzioni nell’esecuzione delle funzioni del sistema.
H3.3	Data Retention
H3.3.1	Nel Sistema di Pedaggio deve essere presente una logica di data retention.
H3.3.2	La logica di data retention deve prevedere la capacità di configurare in maniera flessibile i periodi di data retention.
H3.3.3	I dati del Sistema di Pedaggio – sia quelli operativi che quelli di backup – devono essere cancellati o resi non più disponibili per mezzo di procedure automatiche che siano in accordo alla logica di data retention. Le attività di queste procedure automatiche (o il trattamento di ogni altro evento connesso) devono essere registrate su un log.
H3.3.4	APL deve avere la possibilità di verificare la correttezza sia della realizzazione sia del funzionamento della logica del data retention e delle sue procedure.

3.1.4 Requisiti particolari

# Req.	Descrizione	Risposta
I	Requisiti particolari
I.1	Alimentazione elettrica per l’infrastruttura dei portali
I1.1	I costi dell’alimentazione elettrica per l’infrastruttura dei portali sono a carico dell’Appaltatore. L’alimentazione elettrica per l’infrastruttura dei portali dovrà prevedere l’utilizzo di sistemi UPS (Uninterruptible Power Supply) per sopperire a eventuali interruzioni di erogazione di energia della rete elettrica per almeno 120 minuti.

# Req.	Descrizione	Risposta
I1.2	Per l’alimentazione elettrica dell’infrastruttura dei portali, l’Appaltatore dovrà provvedere alla stesura dei cavi elettrici entro le apposite tubazioni predisposte da APL. Tutte le connessioni a tale rete dovranno essere realizzate a responsabilità e costi dell’Appaltatore.
I1.3	L’Appaltatore non dovrà usare generatori di potenza a carburante per l’alimentazione dell’infrastruttura dei portali.
I2	Rete di comunicazione dati per l’infrastruttura dei portali
I2.1	L’Appaltatore dovrà farsi carico dei costi della comunicazione fra l’infrastruttura dei portali e il sistema centrale.
I2.2	Per la rete di comunicazione dati fra l’infrastruttura dei portali e il sistema centrale, l’Appaltatore dovrà provvedere alla stesura dei cavi ottici entro le apposite tubazioni predisposte da APL. Tutte le connessioni a tale rete devono essere realizzate a responsabilità e costi dell’Appaltatore.
I3	Infrastruttura dei rilevatori
I3.1	Il progetto esecutivo dei portali, che ospitano gli apparati necessari alla rilevazione dei veicoli, alla elaborazione e alla trasmissione dei dati, dovrà tenere conto del progetto definitivo elaborato da APL e allegato alla documentazione tecnica.
I3.2	L’infrastruttura dei rilevatori dovrà essere progettata in maniera che le attività di manutenzione ordinaria abbia il minimo impatto sul flusso del traffico.
I3.3	L’infrastruttura dei rilevatori dovrà essere progettata e costruita in modo da non avere impatto sulle attività di manutenzione ordinaria della rete autostradale e viceversa.
I4	Rete di comunicazione dati fra sistema centrale principale e secondario
I4.1	L’Appaltatore dovrà farsi carico dei costi della comunicazione fra sistema centrale principale e secondario.

# Req.	Descrizione	Risposta
I4.2	L’Appaltatore dovrà provvedere all’impianto della rete di comunicazione dati fra sistema centrale principale e secondario. Tutte le connessioni a tale rete dovranno essere realizzate a responsabilità e costi dell’Appaltatore.

3.2 Servizio di manutenzione

3.2.1 Processi di manutenzione

# Req.	Descrizione	Risposta
J	Processi di manutenzione
J1	L’Appaltatore dovrà assicurare: • la piena operatività del Sistema di Pedaggio mediante: o il monitoraggio del corretto funzionamento (sia hardware che software) di: ▪ tutti i rilevatori; ▪ gli apparati di comunicazione; ▪ il sistema centrale (principale e ridondato). o interventi in loco per la risoluzione di guasti o di malfunzioni, • il rispetto dei livelli di servizio concordati, • la sorveglianza continua di: o caratteristiche di prestazioni e di affidabilità dei sotto-sistemi, o minacce o pericoli di security per il Sistema di Pedaggio in tutte le sue articolazioni, in particolare per le componenti più esposte come i rilevatori, • la gestione strutturata ed ordinata del servizio IT, • l’attuazione di un continuo miglioramento (basato possibilmente su metriche verificabili) dell’efficienza e dell’efficacia della manutenzione del sistema che si basano su: o funzionalità e caratteristiche tecniche del sistema IT, o processi e procedure, o organizzazione e struttura del reparto di manutenzione, • l’evoluzione tecnologica del Sistema di Pedaggio, proponendo piani (annuali o pluriennali) di intervento.

# Req.	Descrizione	Risposta
J2	L’Appaltatore dovrà attuare appropriate procedure per la gestione dei processi del Req. J1.
J3	Requisiti sulla gestione del servizio IT
J3.1	L’Appaltatore dovrà progettare, realizzare e mantenere un sistema di gestione del servizio IT basato su ISO 20000.
J3.2	L’Appaltatore dovrà attuare appropriati processi di gestione del servizio IT.
J3.3	Il Partecipante deve descrivere tali processi, che comprendono (ma non sono limitati a): • incident and problem management; • release management; • capacity management; • configuration management; • SLA management.

3.2.2 Requisiti sul processo di sviluppo/manutenzione del software

# Req.	Descrizione	Risposta
K	Requisiti sul processo di sviluppo/manutenzione
K1	Ambienti di sviluppo/manutenzione e di esercizio
K1.1	Il Sistema di Pedaggio deve avere due ambienti: l’ambiente di esercizio e l’ambiente di sviluppo/manutenzione.
K1.2	L’ambiente di sviluppo/manutenzione deve essere distinto dall’ambiente di esercizio.
K1.3	Prima di essere installato in esercizio, una funzione o un componente del Sistema di Pedaggio deve essere provato con uno specifico test di accettazione nell’ambiente di sviluppo/manutenzione.

# Req.	Descrizione	Risposta
K1.4	I dati dell’ambiente di esercizio non devono mai essere usati come dati di test.
K2	Test
K2.1	L’Appaltatore dovrà fornire una descrizione dei principi che guidano le attività di test dei componenti del Sistema di Pedaggio.
K2.2	Il Partecipante deve fornire una sintesi dei principi di test che copra almeno i seguenti argomenti: • strategia di test; • ambiente di test; • tipi di test; • casi di test (funzionali e prestazionali); • procedure di approvazione; • piani temporali.
K2.3	L’Appaltatore dovrà dare la prova che il processo di test e i casi di test coprono tutti gli aspetti principali, sono completi e consistenti con la specifica.
K2.4	L’Appaltatore dovrà usare il più possibile procedure automatiche di test.
K2.5	La descrizione dei principi di test dovrà comprendere i test di sicurezza.
K3	Sicurezza
K3.1	L’Appaltatore dovrà fornire una descrizione dei principi di sicurezza (piano della sicurezza) e realizzare un sistema di gestione della sicurezza (security management system) basato su ISO 27001 e ISO 27002. Il security management system ed ogni specifica misura di sicurezza dovranno essere continuamente aggiornati allo stato dell’arte del settore. Il piano della sicurezza dovrà proteggere gli asset principali assicurando: confidenzialità, integrità, autenticità, controllo dell’accesso e disponibilità dei processi, sistemi e dati. Il piano della sicurezza si applica sia al sistema centrale (principale e secondario) sia ai rilevatori.
K3.2	Il piano della sicurezza e il security management system dovranno coprire

# Req.	Descrizione	Risposta
	almeno: • valutazione del rischio di ogni asset principale; • scelta delle misure appropriate per ridurre/annullare il rischio; • gestione dei processi IT della sicurezza (come security incident management). Per i rilevatori, i seguenti aspetti (fra gli altri) sono particolarmente delicati: • furto o danno dell’apparato; • furto o violazione di software o di dati; • memorizzazione ed elaborazione delle security key.
K3.3	L’Appaltatore dovrà adottare le migliori pratiche per la realizzazione di software sicuro. La documentazione di sviluppo del sistema dovrà comprendere una sezione che descrive le migliori pratiche che sono state realizzate (per esempio: controllo dell’input doloso – intenzionale o no – dell’utente).
K3.4	La descrizione dei principi di test dovrà comprendere i test di sicurezza.

3.3 Servizio di gestione operativa

3.3.1 Processi di gestione operativa

# Req.	Descrizione	Risposta
L	Processi di gestione operativa
L1	L’Appaltatore dovrà: • definire e mantenere i dati del contesto di tolling, secondo le indicazioni di APL; • se richiesto, rappresentare APL in associazioni di categoria o in organismi tecnici; • gestire il rapporto con i Service Provider, che comprende: o accettare nuovi Service Provider SET, secondo le procedure stabilite; o sorvegliare i livelli di servizio concordati con Service Provider SET; o gestire il contenzioso con: ▪ Servizio di Gestione Clienti o Servizio di Gestione Utenti (come secondo livello); ▪ Service Provider SET; • gestire il rapporto con i fornitori di tecnologie; • gestire il magazzino degli apparati dei rilevatori; • impiantare e rendere operativo ed efficiente il reparto per la Verifica Manuale dei Transiti; • attuare un continuo miglioramento (basato possibilmente su metriche verificabili) dell’efficienza e dell’efficacia della gestione operativa del Sistema di Pedaggio che si basano su: o funzionalità e caratteristiche tecniche del sistema IT; o processi e procedure;

# Req.	Descrizione	Risposta
	o organizzazione e struttura del reparto di gestione operativa; • curare l’evoluzione funzionale del Sistema di Pedaggio, proponendo piani (annuali o pluriennali) di intervento.
L2	L’Appaltatore dovrà attuare appropriate procedure per la gestione dei processi del Req. L1.

3.3.2 Requisiti sulla gestione operativa

# Req.	Descrizione	Risposta
M	Requisiti sulla gestione operativa
M1	Impatti di modifiche ai Toll Context Data
M1.1	La funzione “Raccolta dei dati di transito” deve essere adattabile ad eventuali modifiche della rete APL. Nota: Con modifica della rete APL si intende sia l’inversione temporanea del senso di marcia di una o più corsie di uno o più segmenti elementari della rete autostradale APL (tracciato delle corsie), sia il suo successivo ripristino.
M1.2	A fronte di richieste di APL di modifica del senso di marcia delle corsie dei segmenti autostradali, la funzione “Raccolta dei dati di transito” deve essere adeguata almeno entro 4 giorni dalla notifica. Il Partecipante deve descrivere la soluzione che intende adottare per la gestione della modifiche alla rete APL.
M1.3	La gestione delle modifiche della rete APL devono avvenire in modo da non perturbare la capacità di rilevazione dei veicoli che usano l’autostrada.
M2	Impatti di estensioni ai Toll Context Data
M2.1	La funzione “Raccolta dei dati di transito” deve essere adattabile ad eventuali estensioni della rete APL. Nota: Con estensione della rete APL si intende una variazione permanente dell’attuale tracciato della rete autostradale APL mediante l’aggiunta di nuovi

# Req.	Descrizione	Risposta
	segmenti elementari contigui o no agli esistenti.
M2.2	A fronte di richieste di APL di estensioni di segmenti autostradali contigui, la funzione “Raccolta dei dati di transito” deve essere adeguata nei tempi seguenti: • fino a 2 nuovi segmenti entro 120 giorni • più di 2 nuovi segmenti entro 200 giorni dalla notifica.
M2.3	A fronte di richieste di APL di estensioni di segmenti autostradali non contigui, la funzione “Raccolta dei dati di transito” deve essere adeguata entro 360 giorni dalla notifica.
M3	Modifiche alla funzione
M3.1	Le modifiche alle funzioni “Raccolta e trasmissione dei dati di transito” devono essere realizzate senza perdita di pedaggi e senza impatto sulle prestazioni e sulle funzionalità del Sistema di Pedaggio.
M4	Magazzino degli apparati dei rilevatori
M4.1	Per assicurare un pronto intervento in caso di guasti agli apparati ospitati sui portali dei rilevatori, l’Appaltatore deve predisporre un magazzino di tali apparati.
M4.2	L’Appaltatore deve risolvere (mediante sostituzione) l’evento guasto generico di un apparato al massimo entro 4 ore dallo scoperta del guasto.
M4.3	Per ogni apparato ospitato sui portali dei rilevatori, il Partecipante deve dichiarare la giacenza media stimata in magazzino.

4 Sistema di Gestione Clienti

4.1 Fornitura del sistema

4.1.1 Requisiti generali

# Req.	Descrizione	Rispsota
A	Requisiti generali
A1	Modello di servizio
A1.1	Servizio di EFC
A1.1.1	Il Sistema di Gestione Clienti deve fornire ai suoi clienti il servizio di pagamento del pedaggio sulla rete autostradale APL. Nota: Il cliente ha un contratto di servizio con ed effettua i pagamenti al Servizio di Gestione Clienti.
A1.1.2	Il cliente del Sistema di Gestione Clienti deve: • sottoscrivere un contratto di servizio e • fornire dati relativi a: o identità; o mezzi di pagamento (conto corrente bancario o carta di credito); o targa e caratteristiche del veicolo.
A1.1.3	Il servizio di pagamento deve essere effettuato per mezzo di un OBU, che – consegnato al cliente dal Sistema di Gestione Clienti all’atto della sottoscrizione del contratto di servizio – è in grado di interoperare con le RSU del Sistema di Pedaggio di APL.
A1.1.4	L’OBU deve essere installato a bordo del veicolo dal cliente.
A1.1.5	Il Sistema di Gestione Clienti deve sostituire l’OBU consegnato al cliente in caso di guasti o malfunzioni.

# Req.	Descrizione	Rispsota
A1.1.6	Il Sistema di Gestione Clienti deve rescindere il contratto con il cliente in caso di comprovate violazioni del contratto di servizio o di insolvenza.
A1.1.7	Il Sistema di Gestione Clienti deve monitorare il rispetto delle condizioni contrattuali da parte del cliente.
A1.1.8	Il Sistema di Gestione Clienti deve essere in grado di gestire in maniera flessibile business rule che regolano l’uso dell’OBU e che potranno essere decise da APL. Nota: Esempi di business rule sull’uso dell’OBU sono: • gratuità; • affitto annuo; • una tantum.
A1.1.9	Il Cliente deve avere accesso al Sistema di Gestione Clienti mediante: • Punti Servizio Cliente, distribuiti geograficamente; • Portale Web; • Call Centre; • Applicazione per mobile devices.
A1.1.10	Nei canali di accesso indicati nel Req. A1.1.9 devono essere offerti al Cliente i seguenti servizi: • informazioni sui singoli viaggi effettuati e sull’ammontare dei pedaggi per viaggio; • offerte, promozione nuovi servizi, …; • informativa (brochure, termini e condizioni, documenti legali, …); • toll calculator; • reclami.

# Req.	Descrizione	Rispsota
A1.1.11	In aggiunta ai servizi del Req. A1.1.10, i Punti Servizio Cliente devono offrire i seguenti servizi legati alla gestione dell’OBU: • sottoscrizione/rescissione del contratto (con consegna/restituzione dell’OBU); • sostituzione dell’OBU; • verifica del corretto funzionamento dell’OBU; • trattamento di OBU danneggiati o persi/rubati.
A1.1.12	Il Sistema di Gestione Clienti deve trasferire ad APL i proventi derivanti dai pedaggi pagati dai suoi clienti.
A1.1.13	La conformità degli OBU allo/agli standard scelti per interoperare con le RSU deve essere almeno autocertificata.
A1.1.14	Nella transazione EFC utilizzata deve essere supportato il livello 0 di security previsto sia da ETSI 200674-1 che da EN 15509.
A1.2	Servizi addizionali
A1.2.1	Il Sistema di Gestione Clienti può offrire ai propri clienti servizi addizionali – oltre quello primario di EFC – basati sull’OBU consegnato.
A1.2.2	In caso di offerta di servizi addizionali, questi non devono in alcun modo interferire con il servizio primario di EFC.
A1.5	Supporto del Sistema di Pedaggio APL
A1.5.1	Il Sistema di Gestione Clienti deve essere in grado di memorizzare le informazioni necessarie alla gestione dello scambio di informazioni (sia tra i front- end che tra i back-end) con il Sistema di Pedaggio APL.
A1.6	Interazioni con Produttore di OBU e con Trasportatore

# Req.	Descrizione	Rispsota
A1.6.1	Il Partecipante deve descrivere le interazioni con: • Produttore di OBU, per (se applicabile): o richiesta nuove forniture di OBU; o ricondizionamenti di OBU; o rese OBU difettosi; • Trasportatore, per il trasporto di OBU fra il Produttore e i magazzini del Sistema di Gestione Clienti (centrale e periferici).
A2	Leggi e standard
A2.1	Le leggi e gli standard europei ed italiani applicabili devono essere rispettati durante tutte le fasi della fornitura (progettazione, realizzazione, installazione) del Sistema di Gestione Clienti.
A2.2	Il Sistema di Gestione Clienti deve essere conforme alla direttiva europea 2006/38/EC. Nota: La Direttiva Eurovignette è attualmente in revisione.
A2.3	Per il colloquio con i sistemi esterni al Sistema di Gestione Clienti devono essere utilizzati protocolli ed interfacce standard, ove disponibili.
A2.4	La direttiva R&TTE 1999/5/EC deve essere applicata per tutti gli apparati.
A2.5	Per tutti i dati raccolti, trasmessi, elaborati e memorizzati nel Sistema di Gestione Clienti deve essere applicata la direttiva 1995/46/EC sulla protezione dei dati individuali e la direttiva 2002/58/EC sulla elaborazione dei dati personali e sulla protezione della privacy nelle comunicazioni elettroniche.
A3	Impatto ambientale
A3.1	L’installazione e l’operatività del Sistema di Gestione Clienti non devono esporre persone, beni ed ambiente oltre rischi minimi necessari.
A3.2	L’installazione e l’operatività del Sistema di Gestione Clienti non devono nuocere all’ambiente oltre lo strettamente necessario.

# Req.	Descrizione	Rispsota
A3.3	Lo smantellamento e lo smaltimento di componenti del Sistema di Gestione Clienti deve essere possibile senza uso di inquinanti ambientali e di sostanze tossiche.
A3.4	Per tutte le apparecchiature devono essere applicate le Direttive 2002/95/EC e 2002/96/EC (sull’uso di sostanze pericolose e sui rifiuti elettronici).
A4	Supporto della lingua
A4.1	Le seguenti lingue devono essere disponibili ai canali di accesso del Sistema di Gestione Clienti.
A4.2	Il language set #1 deve comprendere: • Italiano.
A4.3	Il language set #2 deve comprendere: • il language set #1 più • Inglese, • Xxxxxxx e • Francese.
A4.6	La lingua del Sistema di Gestione Clienti utilizzata in tutte le interfacce interattive e in tutti i documenti stampati per l’Operatore di Sistema deve essere il language set #1.
A5	Fatturazione
A5.1	Le fatture e le ricevute devono essere conformi alla legge italiana.
A5.2	Le fatture e le ricevute devono elencare separatamente il pedaggio totale e le varie voci costituenti il pedaggio in accordo con la Direttiva 2006/38/EC e la Direttiva 1999/62/EC (Direttiva Eurovignette) rispettivamente. Nota: La Direttiva Eurovignette è attualmente in revisione.
A5.3	Inoltre e se applicabile, le fatture e le ricevute devono elencare gli importi di: • affitto/costo dell’OBU; • IVA per le varie voci costituenti il pedaggio.

# Req.	Descrizione	Rispsota
A5.4	Per default, le fatture devono elencare solo il pedaggio per ciascun veicolo. A richiesta del Cliente, le fatture devono contenere: • tutti i segmenti autostradali usati; • l’orario del passaggio; • il pedaggio relativo. Nota: Tutte queste informazioni sono comunque disponibili presso il Portale WEB.
A5.5	La lingua di default per le fatture e le ricevute a stampa deve essere il language set #1.

4.1.2 Requisiti funzionali

4.1.2.1 Gestione del magazzino degli OBU

# Req.	Descrizione	Risposta
B	Gestione del magazzino degli OBU
B1	La funzione “Gestione del magazzino degli OBU” deve fornire almeno le seguenti sottofunzioni: • accesso alle informazioni sul magazzino centrale; • accesso alle informazioni sul magazzino dei Punti Servizio Cliente; • gestione degli ordini di OBU al Produttore, compresi tracciamento e storia; • gestione delle movimentazioni fra magazzino centrale e magazzino dei Punti Servizio Cliente; • visione d’insieme di tutti gli OBU nel Sistema di Gestione Clienti. Tutti i dati devono essere visibili mediante interfaccia interattiva.
B1.1	La funzione “Gestione del magazzino degli OBU” deve contenere tutte le informazioni sul magazzino centrale.

# Req.	Descrizione	Risposta
B1.2	La funzione “Gestione del magazzino degli OBU” deve contenere tutte le informazioni sui magazzini locali dei Punti Servizio Cliente.
B1.3	La funzione “Gestione del magazzino degli OBU” deve ricevere gli ordini di consegna di OBU dal magazzino centrale al magazzino dei Punti Servizio Cliente, se il numero degli OBU disponibili localmente va sotto una soglia configurabile.
B1.4	La funzione “Gestione del magazzino degli OBU” deve essere capace di verificare la compatibilità fra gli ordini di OBU richiesti dai Punti Servizio Cliente e la giacenza del magazzino centrale e la storia degli ordini di OBU fatti al Produttore. La funzione “Gestione del magazzino degli OBU” deve essere capace di modificare l’ordine e di inoltrarlo al magazzino centrale per l’effettiva fornitura.
B1.5	La funzione “Gestione del magazzino degli OBU” deve fornire informazioni aggiornate sul numero degli OBU disponibili nel Sistema di Gestione Clienti (presenti nei magazzini locali dei Punti Servizio Cliente o nel magazzino centrale, in trasporto fra i magazzini, in arrivo dal Produttore, …).
B1.6	La funzione “Gestione del magazzino degli OBU” deve ricevere gli OBU da ricondizionare provenienti dai magazzini dei Punti Servizio Cliente e diretti al magazzino centrale.
B1.7	La funzione “Gestione del magazzino degli OBU” deve ricevere gli OBU da rottamare provenienti dai magazzini dei Punti Servizio Cliente e diretti al magazzino centrale.
B1.8	La funzione “Gestione del magazzino degli OBU” deve essere capace di registrare l’arrivo nel magazzino dei Punti Servizio Clienti gli OBU provenienti dal magazzino centrale. La funzione “Gestione del magazzino degli OBU” deve confermare la ricezione fisica degli OBU presso il magazzino dei Punti Servizio Clienti al magazzino centrale.
B1.9	La funzione “Gestione del magazzino degli OBU” deve permettere la correzione del numero di OBU nel magazzino dei Punti Servizio Clienti.

4.1.2.2 Gestione delle informazioni di sistema

# Req.	Descrizione	Risposta
C	Gestione delle informazioni di sistema
C1	Informazioni del contesto di pedaggio
C1.1	Il Sistema di Gestione Clienti deve essere in grado di memorizzare le informazioni relative al conteso di tolling ricevute dal Sistema di Pedaggio, cioè: • Toll Context Overview; • Tariff Table; • Tariff Class Definition; • Local Vehicle Class Definition; • Time Class Definition; • User Class Definition; • Toll Context Layout; con gli attributi specificati in EN 17575-3.
C1.2	Vincoli di integrità
C1.2.1	Il Sistema di Gestione Clienti deve gestire differenti versioni dei gruppi di informazioni relative al contesto di pedaggio, descritte nel Req. C1.1.
C1.2.2	In ogni specifico istante di tempo, solo una versione dei gruppi di informazioni relative al contesto di pedaggio, descritte nel Req. C1.1, deve essere attiva.
C1.2.3	Ogni versione non più attiva dei gruppi di informazioni relative al contesto di pedaggio, descritte nel Req. C1.1, non deve essere cancellata.
C1.3	Interfaccia
C1.3.1	Il Sistema di Gestione Clienti deve fornire le funzioni necessarie per leggere i gruppi di informazioni relative al contesto di pedaggio, descritte nel Req. C1.1.
C1.3.2	Le funzioni di gestione dei gruppi di informazioni relative al contesto di pedaggio, descritte nel Req. C1.1, devono essere disponibili: • sull’interfaccia interattiva disponibile all’Operatore di Sistema;

# Req.	Descrizione	Risposta
	• per mezzo di programmi di utilità di import/export.
C1.3.3	Il Sistema di Gestione Clienti deve assicurare la consistenza e l’integrità dei dati del contesto di pedaggio.
C2	Liste di eccezioni
C2.1	Il Sistema di Gestione Clienti deve permettere la creazione e la modifica delle liste di eccezioni, con gli attributi specificati in EN 12855.
C2.2	I tipi di liste di eccezioni devono essere: • lista dei clienti non più accettati; • lista dei clienti che sono esentati dal pagamento del pedaggio.
C2.3	Vincoli di integrità
C2.4.1	Il Sistema di Gestione Clienti deve gestire differenti versioni delle liste di eccezioni in funzione del periodo di validità.
C2.4.2	In ogni specifico istante di tempo, solo una versione di una lista di eccezioni deve essere attiva.
C2.4.3	Ogni versione non più attiva di una lista di eccezioni non deve essere cancellata.
C2.4	Interfaccia
C2.4.1	Il Sistema di Gestione Clienti deve fornire le funzioni necessarie per gestire (creazione, modifica e lettura) le liste di eccezioni.
C2.4.2	La funzione di gestione delle liste di eccezioni devono essere disponibili sull’interfaccia interattiva disponibile all’Operatore di Sistema.

4.1.2.3 Customer Relationship Management

# Req.	Descrizione	Risposta
D	Customer Relationship Management

# Req.	Descrizione	Risposta
D1	Il Customer Relationship Management comprende le funzioni seguenti: • Punti Servizio Cliente; • Portale Web; • Help Desk per il Call Centre; • applicazione per mobile device.
D2	Punto Servizio Cliente
D2.1	Funzioni specifiche disponibili al Punto Servizio Clienti
D2.1.1	Le funzioni disponibili al Punto Servizio Clienti devono essere: 1) gestione dei dati Cliente/Veicolo; 2) gestione dei dati OBU/Veicolo; 3) personalizzazione di un OBU; 4) test di un OBU; 5) iscrizione di un OBU nella lista clienti non più accettati; 6) gestione del magazzino locale degli OBU; 7) richiesta di ricondizionamento di un OBU; 8) segnalazione di OBU danneggiato; 9) sostituzione di OBU per esaurimento batteria. Nota: La gestione dei dati Cliente/Veicolo e OBU/veicolo comprende l’apertura e la chiusura del contratto Cliente.
D2.1.2	Le funzioni del Req. D2.1.1 – eccetto la 3 e la 4 – devono essere realizzate con un’applicazione web-based acceduta dal personale del Punto di Servizio Clienti mediante un normale browser.
D2.1.3	Le funzioni 3 e 4 del Req. D2.1.1 devono essere realizzate mediante un apparato in grado di colloquiare con l’OBU e un’applicazione specifica su personal computer.
D2.2	Gestione dei dati cliente/veicolo

# Req.	Descrizione	Risposta
D2.2.1	La funzione “Gestione dei dati del cliente/veicolo” deve permettere la creazione, cancellazione e modifica dei dati Cliente costituiti da: • per clienti consumer: o nome, indirizzo e numero telefonico del proprietario del veicolo; o indirizzo di fatturazione; o mezzo di pagamento; o se non di lingua italiana, lingua preferita per la corrispondenza (per posta, fatture, …) dal language set #2. • per clienti business: o nome, indirizzo e ragione sociale dell’azienda proprietaria dei veicoli; o nome, indirizzo e numero telefonico della contact person; o dati e indirizzo di fatturazione; o mezzo di pagamento; o se non di lingua italiana, lingua preferita per la corrispondenza (per posta, fatture, …) dal language set #2.
D2.2.2	La funzione “Gestione dei dati del cliente/veicolo” deve permettere la creazione, cancellazione e modifica dei dati del Veicolo, costituiti dagli attributi previsti da EN 15509 e da ETSI 200674-1.
D2.2.3	La funzione “Gestione dei dati del cliente/veicolo” deve permettere il collegamento fra un Cliente ed uno o più Veicoli. Nota: Un Veicolo può essere collegato ad un solo Cliente in un dato istante e un Cliente può essere collegato a uno o più Veicoli in un dato istante.
D2.2.4	La funzione “Gestione dei dati del cliente/veicolo” deve essere in grado di gestire le modifiche possibili sui dati del Cliente e del Veicolo e sul loro collegamento (per esempio: indirizzo, mezzi di pagamento, cambio della proprietà del veicolo, …).
D2.2.5	La funzione “Gestione dei dati del cliente/veicolo” deve permettere il

# Req.	Descrizione	Risposta
	collegamento fra un Veicolo ed un OBU. Nota: Un Veicolo può essere collegato ad un solo OBU in un dato istante e un OBU può essere collegato ad un solo Veicolo in un dato istante.
D2.2.6	La funzione “Gestione dei dati del cliente/veicolo” deve essere in grado di generare rapporti a stampa sul Cliente e sul Veicolo.
D2.3	Personalizzazione di un OBU
D2.3.1	La funzione “Personalizzazione di un OBU” deve essere in grado di trasferire sull’OBU: • l’attributo di identificazione dell’OBU; • gli attributi del Veicolo; • tutti gli altri attributi necessari per la transazione EFC (per esempio: ContractProvider, ContractSerialNumber, …); • le chiavi derivate di security, necessarie per l’autenticazione dell’OBU.
D2.3.2	La funzione “Personalizzazione di un OBU” deve essere in grado di scrivere sull’OBU gli attributi elencati in Req. D2.3.1.
D2.3.3	La funzione “Personalizzazione di un OBU” deve essere in grado di leggere dall’OBU gli attributi scritti. Gli attributi letti devono coincidere con quelli scritti.
D2.3.4	La funzione “Personalizzazione di un OBU” deve generare le chiavi derivate di security a partire dalle chiavi primarie secondo l’algoritmo previsto da EN 15509 e da ETSI 200674-1.
D2.3.5	Il Partecipante deve descrivere i principi di sicurezza adottati per la gestione delle chiavi primarie, se esse sono presenti nei Punti Servizio Cliente. Tale descrizione comprende ma non è limitata a: • distribuzione sicura e • conservazione sicura delle chiavi primarie ai/nei Punti Servizio Cliente.

# Req.	Descrizione	Risposta
D2.4	Test di un OBU
D2.4.1	La funzione “Test di un OBU” deve essere in grado di effettuare test sull’OBU per scoprire malfunzioni o danni. Il risultato di questi test deve essere: • l’OBU funziona correttamente, o • l’OBU non funziona correttamente.
D2.4.2	Il Partecipante deve descrivere i principali tipi di test (compresi quelli di sicurezza) usati per poter emettere il risultato finale.
D2.4.3	Il risultato finale deve essere accompagnato da un rapporto che illustra l’esito dei singoli test e la causa probabile della malfunzione (se applicabile).
D2.5	Iscrizione di un OBU nella lista clienti non più accettati
D2.5.1	La funzione “Iscrizione di un OBU nella lista clienti non più accettati” deve essere in grado di immettere un OBU in tale lista.
D2.6	Gestione del magazzino locale degli OBU
D2.6.1	Per la funzione “Gestione del magazzino locale degli OBU” si vedano i Req. B.
D2.7	Richiesta di ricondizionamento di un OBU
D2.7.1	La funzione “Richiesta di ricondizionamento di un OBU” deve essere in grado di richiedere che un OBU deve essere ricondizionato.
D2.8	Segnalazione di OBU danneggiato
D2.8.1	La funzione “Segnalazione di OBU danneggiato” deve essere in grado di segnalare che l’OBU è danneggiato: • a causa di un’azione volontaria del Cliente; • per cause non dipendenti dal Cliente.
D2.9	Sostituzione di OBU per esaurimento batteria
D2.9.1	La funzione “Sostituzione di OBU per esaurimento batteria” deve essere in grado

# Req.	Descrizione	Risposta
	di segnalare che l’OBU con batteria esaurita è stato sostituito con un altro OBU.
D2.10	Altre funzioni disponibili al Punto Servizio Cliente
D2.10.1	Il Portale Web (con le sue funzioni di parte pubblica e di parte privata, Req. D3.3 ÷ D3.4) deve essere disponibile agli Operatori del Punto Servizio Cliente. Gli Operatori del Punto Servizio Cliente hanno accesso solo a queste funzioni della parte privata: • modifica dell’indirizzo del Cliente; • accesso ai dati relativi ai viaggi effettuati (per un periodo di tempo limitato – almeno 12 mesi – in formato PDF e CSV); • registrazione dei reclami Cliente ed avvio della procedura di trattamento reclami.
D3	Portale Web
D3.1	Il Portale Web deve contenere: • una parte pubblica e • una parte privata (Self-Care).
D3.2	Il Portale Web deve essere disponibile nel language set #2.
D3.3	Parte pubblica del Portale Web
D3.3.1	La parte pubblica del Portale Web deve fornire le funzioni seguenti: • supporto Cliente e informazioni generali; • download di brochure informative, termini e condizioni, documenti legali, …; • informativa su offerte, promozione nuovi servizi, …; • toll calculator.
D3.3.2	La parte pubblica del Portale Web deve fornire supporto Cliente e informazioni generali: • come risposta a specifiche domande sottoposte;

# Req.	Descrizione	Risposta
	• come ipertesto.
D3.3.3	La parte pubblica del Portale Web deve fornire al Cliente il toll calculator, che calcola il pedaggio in funzione di: • percorso; • tipo veicolo; • periodo temporale.
D3.3.4	Il toll calculator deve avere una user interface basata su mappe geografiche.
D3.3.5	Il toll calculator deve sempre usare i dati correnti dei contesti di tolling relativi al viaggio in esame (se disponibili).
D3.4	Parte privata del Portale Web (Self-Care)
D3.4.1	La parte privata del Portale Web deve fornire le funzioni seguenti: • pre-registrazione dei dati Cliente; • pre-registrazione dei dati Veicolo; • modifica dell’indirizzo del Cliente; • download dei dati relativi ai viaggi effettuati (per un periodo di tempo limitato – almeno 12 mesi – in formato PDF e CSV); • gestione delle opzioni specifiche di Portale Self-Care (per esempio: cambio della password, valori di default per viste personalizzate, …); • registrazione dei reclami Cliente ed avvio della procedura di trattamento reclami.
D3.4.2	L’accesso al Portale Self-Care deve essere protetto per mezzo di log-in name e password specifici per il Cliente.
D3.5	Il Portale Web (compreso il Portale Self-Care) deve permettere la stampa delle informazioni, form e documenti.
D3.6	Il Portale Web (compreso il Portale Self-Care) deve essere protetto da attacchi provenienti dal world wide web per mezzo di tecnologie allo stato dell’arte.

# Req.	Descrizione	Risposta
D3.7	La connessione fra il Portale Web e il sistema centrale deve essere protetto per mezzo di tecnologie allo stato dell’arte.
D4	Help Desk per Call Centre
D4.1	La funzione “Help Desk per Call Centre” deve essere disponibile agli Operatori del Call Centre.
D4.2	La funzione “Help Desk per Call Centre” deve essere un’applicazione Web acceduta tramite un normale browser.
D4.3	La funzione “Help Desk per Call Centre” deve fornire le funzioni seguenti: • supporto Cliente e informazioni generali; • informativa su offerte, promozione nuovi servizi, …; • toll calculator; • pre-registrazione dei dati Cliente; • pre-registrazione dei dati Veicolo; • modifica dell’indirizzo del Cliente; • accesso ai dati relativi ai viaggi effettuati (per un periodo di tempo limitato – almeno 12 mesi –); • registrazione dei reclami Cliente ed avvio della procedura di trattamento reclami; • se applicabile: prenotazione di orario e di luogo per l’installazione dell’OBU presso un’officina autorizzata.
D4.4	Le funzioni elencate in Req. D4.3 devono avere lo stesso contenuto funzionale di quelle corrispondenti descritte nel Req. D3.3 e D3.4.
D4.5	La funzione “Help Desk per Call Centre” deve avere l’interfaccia per l’operatore in language set #1.
D5	Applicazione per mobile device
D5.1	La funzione “App per mobile device” deve fornire le funzioni seguenti:

# Req.	Descrizione	Risposta
	• supporto Cliente e informazioni generali; • accesso a brochure informative, termini e condizioni, documenti legali, …; • informativa su offerte, promozione nuovi servizi, …; • toll calculator; • accesso ai dati relativi ai viaggi effettuati (per un periodo di tempo limitato – almeno 12 mesi –).
D5.2	I sistemi operativi mobile per la funzione “App per mobile device” devono essere: • Android; • iOS di Apple; • Windows Phone di Microsoft.
D5.3	La funzione “App per mobile device” deve essere disponibile sulle seguenti piattaforme di distribuzione: • Google Play per Android; • App Store per Apple; • Windows Phone Marketplace per Microsoft.
D6	Gestione dei reclami
D6.1	Il Sistema di Gestione Clienti deve avere la funzione di “Gestione dei reclami”. Nota: I reclami possono essere di vario tipo, per esempio (la lista non è esaustiva): • contestazioni su viaggi effettuati o su importi dovuti; • non funzionamento o malfunzioni ripetute dell’OBU; • attesa troppo lunga al Call Centre o al Punto Servizio Cliente; • scarsa cortesia o disponibilità alla risoluzione del problema o incompetenza da parte del personale del Call Centre o del Punto Servizio Cliente; • difficile navigabilità nel Portale Web; • malfunzioni nel Portale Web.

# Req.	Descrizione	Risposta
D6.2	La funzione di “Gestione dei reclami” deve documentare ogni reclamo generato dal Cliente ed ogni attività tesa al suo trattamento.
D6.3	Ogni evento od ogni azione legata alla gestione del reclamo deve essere documentata.
D6.4	APL deve avere libero accesso alla funzione di “Gestione dei reclami”, comprese le funzionalità di reportistica.
D6.5	La funzione di “Gestione dei reclami” deve avere uno schema di classificazione dei reclami in base alla gravità. Un reclamo classificato più grave di un altro in base a questo schema deve avere più priorità di trattamento.
D6.6	Il Cliente deve avere la possibilità di consulaltare lo stato del reclamo, cioè le attività interne tese al suo trattamento.
D6.7	La funzione di “Gestione dei reclami” deve chiudere il trattamento del reclamo con un verdetto: • reclamo accettato, accompagnato dalla proposta fatta al Cliente di soluzione (per esempio: rimborso pedaggio, sostituzione OBU, piano temporale di modifiche al sistema, …) del problema che aveva generato il reclamo; • xxxxxxx non accettato, accompagnato dalla motivazione.
D6.8	La funzione di “Gestione dei reclami” deve mostrare all’Operatore gli elenchi dei: • reclami aperti, il loro stato, le attività svolte e gli Operatori coinvolti su tali attività; • reclami chiusi, il loro verdetto e la documentazione di supporto.
D6.9	La funzione di “Gestione dei reclami” deve allertare l’Operatore quando la durata del trattamento di un reclamo aperto è prossimo alla durata massima prevista. La prossimità alla durata massima prevista deve essere un parametro configurabile.

# Req.	Descrizione	Risposta
D6.10	Il trattamento di un reclamo deve durare al più un intervallo di tempo configurabile.

4.1.2.4 Gestione dell’insolvenza, del contenzioso e delle non conformità

# Req.	Descrizione	Risposta
E	Gestione dell’insolvenza, del contenzioso e delle non conformità
E1	Gestione del Cliente insolvente
E1.1	Un Cliente deve essere considerato insolvente quando è stato classificato nella lista dei clienti non più accettati dall’Issuer del mezzo di pagamento.
E1.2	I Clienti insolventi devono essere inseriti nella lista dei clienti non più accettati.
E1.3	La lista dei clienti non più accettati deve essere comunicata al più presto al Sistema di Pedaggio e agli eventuali Toll Charger.
E1.4	Il Sistema di Gestione Clienti deve essere in grado di effettuare le opportune azioni (anche legali) per il recupero dell’eventuale credito dai Clienti insolventi.
E2	Gestione del contenzioso
E2.1	Il Sistema di Gestione Clienti deve essere in grado di ricevere eventuali contestazioni del pedaggio da parte del Cliente. Nota: Le contestazioni possono essere di varia natura, fra cui a titolo di esempio: • sull’importo del pedaggio; • sulla tariffa applicata; • sul percorso effettuato.
E2.2	Il Sistema di Gestione Cliente deve essere in grado di funzionare da filtro

# Req.	Descrizione	Risposta
	rispetto al Sistema di Pedaggio, cioè solo alcune (motivate) contestazioni del Cliente devono essere inoltrate al Sistema di Pedaggio.
E2.3	Il Sistema di Gestione Clienti deve tenere traccia: • di tutte le contestazioni pervenute dal Cliente attraverso qualsiasi canale; • del loro trattamento; • se sono state risolte o sono state inoltrate al Sistema di Pedaggio.
E2.4	Il Sistema di Gestione Clienti deve produrre periodicamente un rapporto su: • numero totale di contestazioni ricevute; • numero di contestazioni inoltrate al Sistema di Pedaggio; • tempo di risoluzione di una contestazione.
E3	Gestione delle non conformità
E3.1	Il Sistema di Gestione Clienti deve essere in grado di gestire eventuali non conformità (comunicate dai Toll Charger) relative ai Clienti. Nota: Esempi di non conformità sono: • non corrispondenza fra caratteristiche dichiarate e rilevate del veicolo; • targa contraffatta.

4.1.2.5 Interazioni con sistemi esterni

# Req.	Descrizione	Risposta
F	Interazioni con sistemi esterni
F1	Interazione con Sistema di Pedaggio
F1.1	Il Sistema di Gestione Clienti deve essere in grado di scambiare con il Sistema di Pedaggio i dati back office secondo EN ISO 12855.

# Req.	Descrizione	Risposta
F1.2	Il Sistema di Gestione Clienti deve essere in grado di utilizzare un canale di comunicazione sicuro nello scambio dati secondo EN ISO 12855 con il Sistema di Pedaggio.
F1.3	Il Sistema di Gestione Clienti deve essere in grado di inviare al Sistema di Pedaggio le Exception List di tipo black list (liste di clienti del Sistema di Gestione Clienti non più accettati) secondo il protocollo e il formato dei messaggi previsto per questo scambio da EN ISO 12855 e di gestire le risposte possibili. Il Sistema di Gestione Clienti deve essere in grado di generare i dati necessari per le Exception List di tipo black list.
F1.4	Il Sistema di Gestione Clienti deve essere in grado di ricevere dal Sistema di Pedaggio i Toll Context Data secondo il protocollo e il formato dei messaggi previsto per questo scambio da EN ISO 12855 e di inviare le risposte possibili.
F1.5	Il Sistema di Gestione Clienti deve essere in grado di ricevere dal Sistema di Pedaggio i Billing Details secondo il protocollo e il formato dei messaggi previsto per questo scambio da EN ISO 12855 e di inviare le risposte possibili.
F1.6	Il Sistema di Gestione Clienti deve essere in grado di ricevere dal Sistema di Pedaggio i Payment Claim secondo il protocollo e il formato dei messaggi previsto per questo scambio da EN ISO 12855 e di inviare le risposte possibili.
F1.7	Il Sistema di Gestione Clienti deve essere in grado di ricevere dal Sistema di Pedaggio i Retrieve User Details secondo il protocollo e il formato dei messaggi previsto per questo scambio da EN ISO 12855 e di inviare le risposte possibili.
F1.8	Il Sistema di Gestione Clienti deve essere in grado di inviare al Sistema di Pedaggio le Exception List di tipo white list (liste di clienti del Sistema di Gestione Clienti non soggetti a pedaggio) secondo il protocollo e il formato dei messaggi previsto per questo scambio da EN ISO 12855 e di gestire le risposte possibili. Il Sistema di Gestione Clienti deve essere in grado di generare i dati necessari per le Exception List di tipo black list.

# Req.	Descrizione	Risposta
F1.9	Il Sistema di Gestione Clienti deve essere in grado di ricevere/inviare dal/al Sistema di Pedaggio i Trust Objects secondo il protocollo e il formato dei messaggi previsto per questo scambio da EN ISO 12855. I Trust Objects comprendono almeno le chiavi master per il colloquio in DSRC fra OBU e RSE. Il Sistema di Gestione Clienti deve essere in grado di: • usare i Trust Objects ricevuti; • generare i Trust Objects da inviare.
F1.10	Il Sistema di Gestione Clienti deve essere in grado inviare al Sistema di Pedaggio i Provide User Details secondo il protocollo e il formato dei messaggi previsto per questo scambio da EN ISO 12855 e di gestire le risposte possibili.
F1.11	Versamento pedaggi ad APL
F1.11.1	Il Sistema di Gestione Clienti deve versare sul c/c bancario indicato da APL i pedaggi di competenza pagati dai Clienti.

4.1.2.6 Monitoraggio e Gestione del cartellino problemi (trouble ticketing)

# Req.	Descrizione	Risposta
G	Monitoraggio e Gestione del cartellino problemi (trouble ticketing)
G1	Monitoraggio
G1.1	La funzione di “Monitoraggio” deve informare in tempo reale l’Operatore di Sistema sullo stato corrente del Sistema di Gestione Clienti e deve generare automaticamente gli allarmi su eventuali malfunzioni.
G1.2	La funzione “Monitoraggio” deve monitorare: • tutti i Punti Servizio Clienti; • gli apparati di comunicazione;

# Req.	Descrizione	Risposta
	• il sistema centrale, in particolare il Portale Web e il Call Centre.
G1.2.1	La funzione di “Monitoraggio” deve monitorare le caratteristiche di disponibilità (availability) e di prestazioni (performance) di ogni funzione del Sistema di Gestione Clienti.
G1.3	L’interfaccia di accesso dell’Operatore di Sistema alle informazioni prodotte dalla funzione di Monitoraggio deve essere via browser. L’accesso deve essere regolato da diritti di accesso, definiti da APL.
G1.4	La funzione di “Monitoraggio” non deve interferire con le normali operazioni del Sistema di Gestione Clienti.
G2	Gestione del cartellino problemi (trouble ticketing)
G2.1	Il Sistema di Gestione Clienti deve avere la funzione di “Gestione del cartellino problemi” (trouble ticketing).
G2.2	La funzione di “Gestione del cartellino problemi” deve documentare ogni evento anomalo del Sistema di Gestione Clienti ed ogni attività di risoluzione problemi.
G2.3	Ogni evento od ogni azione legata alla gestione del cartellino deve essere documentata.
G2.4	APL deve avere libero accesso alla funzione di “Gestione del cartellino problemi”, comprese le funzionalità di reportistica.
G2.5	APL deve avere la possibilità di creare cartellini problemi.

4.1.3 Requisiti non funzionali

# Req.	Descrizione	Risposta
H	Requisiti non funzionali
H1	Portabilità
H1.1	Installazione e dis-installazione

# Req.	Descrizione	Risposta
H1.1.1	Il Sistema di Gestione Clienti deve avere una procedura documentata di installazione dell’intero sistema.
H1.1.2	La documentazione della procedura di installazione deve comprendere almeno: • prerequisiti d’installazione (diritti di accesso, hardware, software, strumenti, persone necessarie, durata, …); • dipendenze da altri sistemi, interfacce, applicazioni; • descrizione delle procedure automatiche e dei passi manuali dell’installazione; • punti di controllo per la verifica di correttezza dell’installazione. Ogni attività di installazione deve essere documentata appropriatamente.
H1.1.3	Ogni installazione (completa o parziale, cioè di una modifica – upgrade – o di una correzione di un errore – patch –) deve poter essere dis-installata. La procedura di dis-installazione non deve perturbare il resto dell’installazione.
H2	Affidabilità
H2.1	Salvataggio (backup) e ripristino (restore) dei dati
H2.1.1	Il Sistema di Gestione Clienti deve avere una procedura di salvataggio (backup) e di ripristino (restore) dei dati del sistema.
H2.1.2	Il backup deve poter essere eseguito senza perturbare le normali operazioni.
H2.1.3	L’Appaltatore dovrà eseguire periodici test di restore che forniscano l’evidenza che la funzione di restore funziona correttamente.
H2.1.4	L’Appaltatore dovrà eseguire almeno: • un backup giornaliero dei dati del Sistema di Gestione Clienti in sette generazioni • un backup settimanale e uno mensile in tre generazioni.
H2.2	Disponibilità (availability) e business continuity
H2.2.1	L’Appaltatore dovrà progettare, realizzare e mantenere una descrizione dei principi

# Req.	Descrizione	Risposta
	di business continuity possibilmente basata su standard e migliori pratiche. In particolare, essa dovrà descrivere come sono assicurati i Service Level Agreement in caso di eventi come caduta del sistema, perdita della connessione di comunicazione e così via.
H2.2.2	Il Sistema di Gestione Clienti deve assicurare caratteristiche di alta disponibilità in caso di disastro in accordo al livello di servizio stabilito.
H2.2.3	L’Appaltatore dovrà progettare ed eseguire test del caso di disastro.
H2.3	Up-Time del sistema centrale
H2.3.1	Il sistema centrale del Sistema di Gestione Clienti deve avere una disponibilità (availability) di almeno il 99.5 %. Nota: La indisponibilità del sistema centrale significa l’ indisponibilità sia del sistema primario che del sistema secondario.
H2.3.2	Il sistema centrale del Sistema di Gestione Clienti non deve avere un down-time continuativo di più di 6 ore.
H2.3.3	Il sistema centrale del Sistema di Gestione Clienti deve avere funzioni per la supervisione remota della sua disponibilità da parte della funzione di Monitoraggio. Ogni evento di non disponibilità deve essere riportato in un cartellino problemi. La funzione Monitoraggio o la funzione Gestione del cartellino problemi devono fornire un rapporto annuale di tutti gli eventi di non disponibilità del Sistema di Gestione Clienti e delle loro durate.
H2.4	Call Centre
H2.4.1	L’infrastruttura del Call Centre deve avere una disponibilità di almeno il 99.5% su base annuale (24 × 7).
H2.4.2	L’infrastruttura del Call Centre deve supportare il monitoraggio remoto da parte della funzione “Monitoraggio”. Ogni evento di non disponibilità deve generare un cartellino problemi. Le funzioni “Monitoraggio” e “Gestione del cartellino problemi” devono

# Req.	Descrizione	Risposta
	fornire un rapporto annuale di tutte le non disponibilità del Call Centre scoperte e della loro durata.
H2.4.3	L’infrastruttura del Call Centre non deve avere una non disponibilità per più di 2 ore continuative.
H3	Prestazioni
H3.1	Il Sistema di Gestione Clienti deve avere caratteristiche di scalabilità per adattarsi ad aumenti o decrementi progressivi o inattesi del carico di sistema (system load).
H3.2	Data Retention
H3.2.1	Nel Sistema di Gestione Clienti deve essere presente una logica di data retention.
H3.2.2	La logica di data retention deve prevedere la capacità di configurare in maniera flessibile i periodi di data retention.
H3.2.3	I dati del Sistema di Gestione Clienti devono essere cancellati o resi non più disponibili per mezzo di procedure automatiche che siano in accordo alla logica di data retention. Le attività di queste procedure automatiche (o il trattamento di ogni altro evento connesso) devono essere registrate su un log.
H3.2.4	APL deve avere la possibilità di verificare la correttezza sia della realizzazione sia del funzionamento della logica del data retention e delle sue procedure.
H4	Sicurezza
H4.1	L’Appaltatore dovrà fornire una descrizione dei principi di sicurezza (piano della sicurezza) e realizzare un sistema di gestione della sicurezza (security management system) basato su ISO 27001 e ISO 27002. Il security management system ed ogni specifica misura di sicurezza dovranno essere continuamente aggiornati allo stato dell’arte del settore. Il piano della sicurezza dovrà proteggere gli asset principali assicurando: confidenzialità, integrità, autenticità, controllo dell’accesso e disponibilità dei processi, sistemi e dati. Il piano della sicurezza si applica sia al sistema centrale

# Req.	Descrizione	Risposta
	sia ai sistemi presso i Punti Servizio Clienti.
H4.2	Il piano della sicurezza e il security management system dovranno coprire almeno: • valutazione del rischio di ogni asset principale; • scelta delle misure appropriate per ridurre/annullare il rischio; • gestione dei processi IT della sicurezza (come security incident management).
H4.3	L’Appaltatore dovrà adottare le migliori pratiche per la realizzazione di software sicuro. La documentazione di sviluppo del sistema dovrà comprendere una sezione che descrive le migliore pratiche che sono state realizzate (per esempio: controllo dell’input doloso – intenzionale o no – dell’utente).
H5	Architettura
H5.1	Punti Servizio Clienti
H5.1.1	L’Appaltatore dovrà fornire i sistemi necessari ai Punti Servizio Cliente in due configurazioni: • configurazione massima, con: o personal computer; o accesso ad Internet; o stampante; o terminale per il pagamento con carta di credito/debito; o unità per personalizzazione/test dell’OBU; o applicazione di controllo dell’unità di personalizzazione/test dell’OBU; o lettore di codice a barre; o registratore di cassa; • configurazione minima, con:

# Req.	Descrizione	Risposta
	o unità per la personalizzazione e il test dell’OBU; o applicazione di controllo dell’unità, utilizzabile su sistemi elaborativi già presenti Punto di Servizio Clienti.
H5.1.2	Nel caso della configurazione minima, deve essere in grado di operare sulle più diffuse versioni di Microsoft Windows. Il Partecipante deve indicare su quale di queste versioni di Microsoft Windows sarà in grado di girare l’applicazione di controllo dell’unità di personalizzzazione/test dell’OBU.
H5.1.3	Almeno 2 Punti Servizio Clienti devono essere fisicamente collocati sulla rete autostradale APL.
H5.2	Infrastruttura del Call Centre
H5.2.1	L’Appaltatore dovrà fornire l’infrastruttura del Call Centre, comprensiva di hardware and software, per: • direzionare le chiamate entranti agli operatori liberi; • guidare il Cliente fra le varie opzioni mediante un IVR; • accodare le chiamate entranti in attesa di un operatore libero; • monitorare il carico di lavoro e le prestazioni degli operatori. L’infrastruttura del Call Centre deve supportare il necessario numero di postazioni di lavoro per la funzione di Help Desk.
H5.2.2	L’infrastruttura del Call Centre deve avere un sistema Interactive Voice Response (IVR) configurabile. Nota: Un IVR è una tecnologia che permette ad un computer di interagire con l’uomo recitando al chiamante informazioni preregistrate e interagendo tramite tastiera telefonica DTMF.
H5.2.3	L’infrastruttura del Call Centre deve permettere la registrazione delle chiamate, cioè la conversazione fra il chiamante e l’agente. Le chiamate registrate devono essere memorizzate in un archivio e devono poter essere esportabili in un medium esterno.

# Req.	Descrizione	Risposta
H5.2.4	L’infrastruttura del Call Centre deve avere un monitoraggio real time delle attività degli agenti di Help Desk e delle code delle chiamate entranti.
H5.2.5	L’infrastruttura del Call Centre deve fornire almeno le statistiche seguenti (mensili, giornaliere ed orarie): • numero di chiamate; • prestazioni per specifico gruppo di agenti e per l’intero sistema; • numero di chiamate perse in caso di inoperatività del Call Centre; • numero di chiamate perse quando tutti gli agenti sono occupati; • lunghezza di ciascuna conversazione e lunghezza media delle conversazioni; • tempo medio di attesa delle chiamate in coda; • lunghezza media della coda di chiamate.

4.2 Servizio di manutenzione

4.2.1 Processi di manutenzione

# Req.	Descrizione	Risposta
I	Processi di manutenzione
I1	L’Appaltatore dovrà assicurare: • la piena operatività del Sistema di Gestione Clienti mediante: o il monitoraggio del corretto funzionamento (sia hardware che software) di: ▪ tutti gli apparati periferici; ▪ il sistema centrale (principale e ridondato). o interventi in loco per la risoluzione di guasti o di malfunzioni; • il rispetto dei livelli di servizio concordati; • la sorveglianza continua di: o caratteristiche di prestazioni e di affidabilità dei sotto-sistemi; o minacce o pericoli di security per il Sistema di Gestione Clienti in tutte le sue articolazioni; • la gestione strutturata ed ordinata del servizio IT; • un continuo miglioramento (basato possibilmente su metriche verificabili) dell’efficienza e dell’efficacia della manutenzione del Sistema di Gestione Clienti che si basano su: o funzionalità e caratteristiche tecniche del sistema IT; o processi e procedure; o organizzazione e struttura del reparto di manutenzione; • l’evoluzione tecnologica del Sistema di Gestione Clienti, proponendo piani (annuali o pluriennali) di intervento.
I2	L’Appaltatore dovrà attuare appropriate procedure per la gestione dei processi del Req. I1.

# Req.	Descrizione	Risposta
I3	Requisiti sulla gestione del servizio IT
I3.1	L’Appaltatore dovrà progettare, realizzare e mantenere un sistema di gestione del servizio IT basato su ISO 20000.
I3.2	L’Appaltatore dovrà attuare appropriati processi di gestione del servizio IT.
I3.3	Il Partecipante deve descrivere tali processi, che comprendono (ma non sono limitati a): • incident and problem management; • release management; • capacity management; • configuration management; • SLA management.

4.2.2 Requisiti sul processo di sviluppo/manutenzione del software

# Req.	Descrizione	Risposta
K	Requisiti sul processo di sviluppo/manutenzione
K1	Ambienti di sviluppo/manutenzione e di esercizio
K1.1	Il Sistema di Gestione Clienti deve avere due ambienti: l’ambiente di esercizio e l’ambiente di sviluppo/manutenzione.
K1.2	L’ambiente di sviluppo/manutenzione deve essere distinto dall’ambiente di esercizio.
K1.3	Prima di essere installato in esercizio, una funzione o un componente del Sistema di Gestione Clienti deve essere provato con uno specifico test di accettazione nell’ambiente di sviluppo/manutenzione.
K1.4	I dati dell’ambiente di esercizio non devono mai essere usati come dati di test.
K2	Test

# Req.	Descrizione	Risposta
K2.1	L’Appaltatore dovrà fornire una descrizione dei principi che guidano le attività di test dei componenti del Sistema di Gestione Clienti.
K2.2	Il Partecipante deve fornire una sintesi dei principi di test che copra almeno i seguenti argomenti: • strategia di test; • ambiente di test; • tipi di test; • casi di test (funzionali e prestazionali); • procedure di approvazione; • piani temporali.
K2.3	L’Appaltatore dovrà dare la prova che il processo di test e i casi di test coprono tutti gli aspetti principali, sono completi e consistenti con la specifica.
K2.4	L’Appaltatore dovrà usare il più possibile procedure automatiche di test.
K2.5	La descrizione dei principi di test dovrà comprendere i test di sicurezza.
K3	Sicurezza
K3.1	L’Appaltatore dovrà fornire una descrizione dei principi di sicurezza (piano della sicurezza) e realizzare un sistema di gestione della sicurezza (security management system) basato su ISO 27001 e ISO 27002. Il security management system ed ogni specifica misura di sicurezza dovranno essere continuamente aggiornati allo stato dell’arte del settore. Il piano della sicurezza dovrà proteggere gli asset principali assicurando: confidenzialità, integrità, autenticità, controllo dell’accesso e disponibilità dei processi, sistemi e dati. Il piano della sicurezza si applica a tutti i componenti del Sistema di Gestione Clienti.
K3.2	Il piano della sicurezza e il security management system dovranno coprire almeno: • valutazione del rischio di ogni asset principale;

# Req.	Descrizione	Risposta
	• scelta delle misure appropriate per ridurre/annullare il rischio; • gestione dei processi IT della sicurezza (come security incident management).
K3.3	L’Appaltatore dovrà adottare le migliori pratiche per la realizzazione di software sicuro. La documentazione di sviluppo del sistema dovrà comprendere una sezione che descrive le migliore pratiche che sono state realizzate (per esempio: controllo dell’input doloso – intenzionale o no – dell’utente).
K3.4	La descrizione dei principi di test dovrà comprendere i test di sicurezza.

4.3 Servizio di gestione operativa

4.3.1 Processi di gestione operativa

# Req.	Descrizione	Risposta
L	Processi di gestione operativa
L1	L’Appaltatore dovrà: • se richiesto, rappresentare APL in associazioni di categoria o in organismi tecnici; • gestire il contenzioso con i Clienti (come primo livello); • gestire il rapporto con i fornitori di tecnologie; • gestire il magazzino degli OBU; • impiantare e rendere operativo ed efficiente il reparto per Help Desk per il Call Centre; • gestire il rapporto con i Clienti, che comprende: o aprire e chiudere contratti di servizio; o conservare i clienti esistenti; o acquisire nuovi clienti, mettendo a punto specifiche offerte dirette soprattutto verso gli utenti senza contratti con Service Provider; o applicare sanzioni i clienti non conformi; • gestire il rapporto con i gestori dei Punti Servizio Clienti; • attuare un continuo miglioramento (basato possibilmente su metriche verificabili) dell’efficienza e dell’efficacia della gestione operativa del Sistema di Gestione Clienti che si basano su: o funzionalità e caratteristiche tecniche del sistema IT; o processi e procedure; o organizzazione e struttura del reparto di gestione operativa; • curare l’evoluzione funzionale del Sistema di Gestione Clienti, proponendo piani (annuali o pluriennali) di intervento.

# Req.	Descrizione	Risposta
L2	L’Appaltatore dovrà attuare appropriate procedure per la gestione dei processi del Req. L1.

5 Sistema di Gestione Utenti

5.1 Fornitura del sistema

5.1.1 Requisiti generali

# Req.	Descrizione	Risposta
A	Requisiti generali
A1	Modello di servizio
A1.1	Servizio di pagamento pedaggio
A1.1.1	Il Sistema di Gestione degli Utenti deve fornire il servizio di pagamento del pedaggio agli utenti della rete autostradale APL che: • non sono in possesso di OBU (utenti occasionali) o • sono in possesso di OBU (utenti particolari) ma: o sono in lista clienti non più accettati di un Service Provider o o la transazione EFC non è andata a buon fine in maniera tale che il Sistema di Pedaggio non è stato in grado di conoscere l’utente nè il Service Provider.
A1.1.2	Il Sistema di Gestione degli Utenti deve offrire agli utenti le seguenti modalità di pagamento: • pre-pagamento: o Conto Veicolo, ricaricabile; o abbonamento per pendolari (5 viaggi per settimana, 20 viaggi per mese, …); o acquisto di un viaggio in una data stabilita; • pagamento contestuale, durante il viaggio; • post-pagamento entro un numero prefissato e configurabile di giorni dopo il viaggio.

# Req.	Descrizione	Risposta
A1.1.3	Il Sistema di Gestione degli Utenti deve dare agli utenti di utilizzare i seguenti mezzi di pagamento: • contanti; • conto corrente bancario; • carta di credito/carta di xxxxxx; • mobile payment.
A1.1.7	Il Sistema di Gestione degli Utenti deve monitorare il rispetto delle condizioni contrattuali da parte degli utenti.
A1.1.9	L’utente deve avere accesso al Sistema di Gestione Utenti mediante: • Punti Servizio Utente, distribuiti geograficamente; • bigliettatrici, distribuite geograficamente; • Portale Web; • Call Centre; • Applicazione per mobile device.
A1.1.10	Nei canali di accesso indicati nel Req. A1.1.9 devono essere offerti all’utente i seguenti servizi: • informazioni sui singoli viaggi effettuati e sull’ammontare dei pedaggi per viaggio (solo per Xxxxx Xxxxxxx); • offerte, promozione nuovi servizi, …; • informativa (brochure, termini e condizioni, documenti legali, …); • toll calculator; • reclami.

# Req.	Descrizione	Risposta
A1.1.11	In aggiunta ai servizi del Req. A1.1.10, i Punti Servizio Utente devono offrire i seguenti servizi: • apertura/chiusura Conto Veicolo; • ricarica Xxxxx Xxxxxxx; • acquisto abbonamenti o singoli viaggi; • pagamento contestuale del pedaggio (se il Punto Servizio Utente si trova sulla rete autostradale APL); • post-pagamenti.
A1.1.12	Il Sistema di Gestione Utenti deve trasferire ad APL i proventi derivanti dai pedaggi pagati dai suoi utenti.
A1.2	Supporto del Sistema di Pedaggio APL
A1.2.1	Il Sistema di Gestione Utenti deve essere in grado di memorizzare le informazioni necessarie alla gestione dello scambio di informazioni con il Sistema di Pedaggio APL.
A2	Leggi e standard
A2.1	Le leggi e gli standard europei ed italiani applicabili devono essere rispettati durante tutte le fasi della fornitura (progettazione, realizzazione, installazione) del Sistema di Gestione Utenti.
A2.2	Per tutti i dati raccolti, trasmessi, elaborati e memorizzati nel Sistema di Gestione Utenti deve essere applicata la direttiva 1995/46/EC sulla protezione dei dati individuali e la direttiva 2002/58/EC sulla elaborazione dei dati personali e sulla protezione della privacy nelle comunicazioni elettroniche.
A3	Impatto ambientale
A3.1	L’installazione e l’operatività del Sistema di Gestione Utenti non devono esporre persone, beni ed ambiente oltre rischi minimi necessari.
A3.2	L’installazione e l’operatività del Sistema di Gestione Utenti non devono nuocere all’ambiente oltre lo strettamente necessario.

# Req.	Descrizione	Risposta
A3.3	Lo smantellamento e lo smaltimento di componenti del Sistema di Gestione Utenti deve essere possibile senza uso di inquinanti ambientali e di sostanze tossiche.
A3.4	Per tutte le apparecchiature devono essere applicate le Direttive 2002/95/EC e 2002/96/EC (sull’uso di sostanze pericolose e sui rifiuti elettronici).
A4	Supporto della lingua
A4.1	Le seguenti lingue devono essere disponibili ai canali di accesso del Sistema di Gestione Utenti.
A4.2	Il language set #1 deve comprendere: • Italiano.
A4.3	Il language set #2 deve comprendere: • il language set #1 più • Inglese, • Xxxxxxx e • Francese.
A4.6	La lingua del Sistema di Gestione Utenti utilizzata in tutte le interfacce interattive e in tutti i documenti stampati per l’Operatore di Sistema deve essere il language set #1.
A5	Fatturazione
A5.1	Le fatture e le ricevute devono essere conformi alla legge italiana.
A5.2	Le fatture e le ricevute devono elencare separatamente il pedaggio totale e le varie voci costituenti il pedaggio in accordo con la Direttiva 2006/38/EC e la Direttiva 1999/62/EC (Direttiva Eurovignette) rispettivamente. Nota: La Direttiva Eurovignette è attualmente in revisione.
A5.3	Inoltre e se applicabile, le fatture e le ricevute devono elencare gli importi di IVA per le varie voci costituenti il pedaggio.

# Req.	Descrizione	Risposta
A5.4	Per default, le fatture devono elencare solo il pedaggio per ciascun veicolo. A richiesta dell’Utente, le fatture devono contenere: • tutti i segmenti autostradali usati, • l’orario del passaggio, • il pedaggio relativo. Nota: Tutte queste informazioni sono comunque disponibili presso il Portale WEB.
A5.5	La lingua di default per le fatture e le ricevute a stampa deve essere il language set #1.

5.1.2 Requisiti funzionali

5.1.2.1 Gestione delle informazioni di sistema

# Req.	Descrizione	Risposta
C	Gestione delle informazioni di sistema
C1	Informazioni del contesto di pedaggio
C1.1	Per ogni Toll Charger con cui ha il contratto di servizio e, quindi, in particolare con il Sistema di Pedaggio, il Sistema di Gestione Utenti deve essere in grado di memorizzare le informazioni relative al conteso di tolling ricevute dal Toll Charger, cioè: • Toll Context Overview; • Tariff Table; • Tariff Class Definition; • Local Vehicle Class Definition; • Time Class Definition; • User Class Definition; • Toll Context Layout

# Req.	Descrizione	Risposta
	con gli attributi specificati in EN 17575-3.
C1.2	Vincoli di integrità
C1.2.1	Il Sistema di Gestione Utenti deve gestire differenti versioni dei gruppi di informazioni relative al contesto di pedaggio, descritte nel Req. C1.1.
C1.2.2	In ogni specifico istante di tempo, solo una versione dei gruppi di informazioni relative al contesto di pedaggio, descritte nel Req. C1.1, deve essere attiva.
C1.2.3	Ogni versione non più attiva dei gruppi di informazioni relative al contesto di pedaggio, descritte nel Req. C1.1, non deve essere cancellata.
C1.3	Interfaccia
C1.3.1	Il Sistema di Gestione Utenti deve fornire le funzioni necessarie per leggere i gruppi di informazioni relative al contesto di pedaggio, descritte nel Req. C1.1.
C1.3.2	Le funzioni di gestione dei gruppi di informazioni relative al contesto di pedaggio, descritte nel Req. C1.1, devono essere disponibili: • sull’interfaccia interattiva disponibile all’Operatore di Sistema; • per mezzo di programmi di utilità di import/export.
C1.3.3	Il Sistema di Gestione Utenti deve assicurare la consistenza e l’integrità dei dati del contesto di pedaggio.

5.1.2.2 Customer Relationship Management

# Req.	Descrizione	Risposta
D	Customer Relationship Management
D1	Il Customer Relationship Management comprende le funzioni seguenti: • Punti Servizio Utente; • Portale Web; • Help Desk per il Call Centre;

# Req.	Descrizione	Risposta
	• applicazione per mobile device; • bigliettatrice.
D2	Punto Servizio Utente
D2.1	Funzioni specifiche disponibili al Punto Servizio Utente
D2.1.1	Le funzioni disponibili al Punto Servizio Utente devono essere: • gestione dei dati Conto Veicolo; • gestione dei pagamenti in contanti o con carta di credito/debito: • pre-pagamenti per: ▪ carica iniziale del Conto Veicolo; ▪ ricarica del Conto Veicolo; ▪ acquisto di: o abbonamento per pendolare; o un singolo viaggio da effettuarsi in una data prefissata; • pagamenti contestuali (se il Punto Servizio Utenti si trova sulla rete autostradale APL); • post-pagamenti.
D2.1.2	Le funzioni del Req. D2.1.1 devono essere realizzate con un’applicazione web- based acceduta dal personale del Punto di Servizio Utenti mediante un normale browser.
D2.2	Gestione dei dati Conto Veicolo
D2.2.1	La funzione “Gestione dei dati Conto Veicolo” deve permettere la creazione, cancellazione e modifica dei dati del Veicolo. L’utente deve comunque essere riconosciuto per permettere l’accesso alle informazioni sui suoi viaggi al Portale Web o al Call Centre.
D2.3	Gestione dei Conto Veicolo
D2.3.1	Il Conto Veicolo deve essere non nominativo, cioè non devono essere raccolte e

# Req.	Descrizione	Risposta
	memorizzate le generalità della persona che lo apre.
D2.3.2	Il Conto Veicolo deve essere incrementato dalla ricarica dell’Utente.
D2.3.3	Il Conto Veicolo deve essere decrementato dell’importo del pedaggio dovuto.
D2.3.4	Il Conto Veicolo negativo non deve provocare sanzioni se è ricaricato con importo sufficiente a riportarlo in positivo entro un termine di tempo configurabile.
D2.3.5	Sul Conto Veicolo deve essere definibile, all’atto dell’apertura, un importo soglia superato il quale un avviso automatico (mediante e-mail) è inviato all’Utente.
D2.4	Altre funzioni disponibili al Punto Servizio Utente.
D2.4.1	Il Portale Web (con le sue funzioni di parte pubblica e di parte privata, Req. D3.3 ÷ D3.4.2) deve essere disponibile agli Operatori del Punto Servizio Utente. Gli Operatori del Punto Servizio Utente hanno accesso solo a queste funzioni della parte privata: • accesso ai dati relativi ai viaggi effettuati (per un periodo di tempo limitato – almeno 12 mesi – in formato PDF e CSV); • registrazione dei reclami Utente ed avvio della procedura di trattamento reclami.
D3	Portale Web
D3.1	Il Portale Web deve contenere: • una parte pubblica e • una parte privata (Self-Care).
D3.2	Il Portale Web deve essere disponibile nel language set #2.
D3.3	Parte pubblica del Portale Web
D3.3.1	La parte pubblica del Portale Web deve fornire le funzioni seguenti: • supporto Utente e informazioni generali; • download di brochure informative, termini e condizioni, documenti legali,

# Req.	Descrizione	Risposta
	…; • informativa su offerte, promozione nuovi servizi, …; • toll calculator.
D3.3.2	La parte pubblica del Portale Web deve fornire supporto Utente e informazioni generali: • come risposta a specifiche domande sottoposte; • come ipertesto.
D3.3.3	La parte pubblica del Portale Web deve fornire all’Utente il toll calculator, che calcola il pedaggio in funzione di: • percorso; • tipo veicolo; • periodo temporale.
D3.3.4	Il toll calculator deve avere una user interface basata su mappe geografiche.
D3.3.5	Il toll calculator deve sempre usare i dati correnti dei contesti di tolling relativi al viaggio in esame (se disponibili).
D3.4	Parte privata del Portale Web (Self-Care)
D3.4.1	La parte privata del Portale Web deve fornire le funzioni seguenti: • previo riconoscimento dell’Utente: o gestione dei dati Conto Veicolo; o accesso ai e download dei dati relativi ai viaggi effettuati (per un periodo di tempo limitato – almeno 12 mesi – in formato PDF e CSV); o gestione delle opzioni specifiche di Portale Self-Care (per esempio: cambio della password, valori di default per viste personalizzate, …); • definizione di un Conto Veicolo; • gestione dei pagamenti con carta di credito/xxxxxx:

# Req.	Descrizione	Risposta
	• pre-pagamenti per: ▪ carica iniziale del Conto Veicolo; ▪ ricarica del Conto Veicolo; ▪ acquisto di un abbonamento; ▪ acquisto di un singolo viaggio; • post-pagamenti.
D3.4.2	L’accesso al Portale Web Self-Care deve essere protetto per mezzo di log-in name e password di riconoscimento dell’Utente.
D3.5	Il Portale Web (compreso il Portale Self-Care) deve permettere la stampa delle informazioni, form e documenti.
D3.6	Il Portale Web (compreso il Portale Self-Care) deve essere protetto da attacchi provenienti dal world wide web per mezzo di tecnologie allo stato dell’arte.
D3.7	La connessione fra il Portale Web e il sistema centrale deve essere protetto per mezzo di tecnologie allo stato dell’arte.
D4	Help Desk per Call Centre
D4.1	La funzione “Help Desk per Call Centre” deve essere disponibile agli Operatori del Call Centre.
D4.2	La funzione “Help Desk per Call Centre” deve essere un’applicazione Web acceduta tramite un normale browser.
D4.3	La funzione “Help Desk per Call Centre” deve fornire le funzioni seguenti: • supporto Utente e informazioni generali; • informativa su offerte, promozione nuovi servizi, …; • toll calculator; • pre-registrazione dei dati Conto Veicolo; • accesso ai dati relativi ai viaggi effettuati (per un periodo di tempo limitato – almeno 12 mesi – in formato PDF e CSV); • registrazione dei reclami Utente ed avvio della procedura di trattamento

# Req.	Descrizione	Risposta
	reclami.
D4.4	Le funzioni elencate in Req. D4.3 devono avere lo stesso contenuto funzionale di quelle corrispondenti descritte nel Req. D3.3 e D3.4.
D4.5	Per l’accesso ai dati relativi ai viaggi effettuati, l’Utente deve essere riconosciuto.
D4.6	La funzione “Help Desk per Call Centre” deve avere l’interfaccia per l’operatore in language set #1.
D4.7	Gli operatori dell’“Help Desk per Call Centre” devono poter colloquiare con l’Utente in language set #2.
D5	Applicazione per mobile device
D5.1	La funzione “App per mobile device” deve fornire le funzioni seguenti: • supporto Utente e informazioni generali; • accesso a brochure informative, termini e condizioni, documenti legali, …; • informativa su offerte, promozione nuovi servizi, …; • toll calculator; • accesso ai dati relativi ai viaggi effettuati (per un periodo di tempo limitato – almeno 12 mesi –), previo riconoscimento utente.
D5.2	I sistemi operativi mobile per la funzione “App per mobile device” devono essere: • Android; • iOS di Apple; • Windows Phone di Microsoft.
D5.3	La funzione “App per mobile device” deve essere disponibile sulle seguenti piattaforme di distribuzione: • Google Play per Android; • App Store per Apple; • Windows Phone Marketplace per Microsoft.
D6	Bigliettatrice

# Req.	Descrizione	Risposta
D6.1	La bigliettatrice deve permettere il pagamento del pedaggio in base alla targa del veicolo.
D6.2	La bigliettatrice deve accettare il pagamento del pedaggio sia in contanti che con carta di credito/xxxxxx.
D6.3	La bigliettatrice deve permettere: • il pre-pagamento (ricarica Xxxxx Xxxxxxx, scelta e acquisto abbonamento, scelta e acquisto singolo viaggio), • il pagamento contestuale (scelta e acquisto singolo viaggio), • il post-pagamento (consultazione mediante targa).
D7	Gestione dei reclami
D7.1	Il Sistema di Gestione Utenti deve avere la funzione di “Gestione dei reclami”. Nota: I reclami possono essere di vario tipo, per esempio (la lista non è esaustiva): • attesa troppo lunga al Call Centre o al Punto Servizio Utente, • scarsa cortesia o disponibilità alla risoluzione del problema o incompetenza da parte del personale del Call Centre o del Punto Servizio Utente, • difficile navigabilità nel Portale Web, • malfunzioni nel Portale Web.
D7.2	La funzione di “Gestione dei reclami” deve documentare ogni reclamo generato dall’utente ed ogni attività tesa al suo trattamento.
D7.3	Ogni evento od ogni azione legata alla gestione del reclamo deve essere documentata.
D7.4	APL deve avere libero accesso alla funzione di “Gestione dei reclami”, comprese le funzionalità di reportistica.
D7.5	La funzione di “Gestione dei reclami” deve avere uno schema di classificazione dei reclami in base alla gravità. Un reclamo classificato più grave di un altro in base a questo schema deve avere

# Req.	Descrizione	Risposta
	più priorità di trattamento.
D7.6	L’utente deve avere la possibilità di consultare lo stato del reclamo, cioè le attività interne tese al suo trattamento.
D7.7	La funzione di “Gestione dei reclami” deve chiudere il trattamento del reclamo con un verdetto: • reclamo accettato, accompagnato dalla proposta fatta all’utente di soluzione del problema che aveva generato il reclamo; • xxxxxxx non accettato, accompagnato dalla motivazione.
D7.8	La funzione di “Gestione dei reclami” deve mostrare all’Operatore gli elenchi dei: • reclami aperti, il loro stato, le attività svolte e gli Operatori coinvolti su tali attività; • reclami chiusi, il loro verdetto e la documentazione di supporto.
D7.9	La funzione di “Gestione dei reclami” deve allertare l’Operatore quando la durata del trattamento di un reclamo aperto è prossimo alla durata massima prevista. La prossimità alla durata massima prevista deve essere un parametro configurabile.
D7.10	Il trattamento di un reclamo deve durare al più quattro settimane.

5.1.2.3 Gestione del recupero crediti e del contenzioso

# Req.	Descrizione	Risposta
E	Gestione del recupero crediti e del contenzioso
E1	Gestione del recupero crediti
E1.1	Il Sistema di Gestione Utenti deve essere in grado di effettuare le opportune azioni (anche legali) per il recupero del credito dagli utenti insolventi.

# Req.	Descrizione	Risposta
E1.2	Un utente deve essere considerato insolvente quando: • ha un Conto Veicolo con saldo negativo, • avendo scelto il post-pagamento, è trascorso il termine di post- pagamento.
E1.2	Gli utenti insolventi devono essere identificati mediante consultazione dei Pubblici Registri Automobilistici (anche esteri) con la targa rilevata del veicolo.
E1.3	Agli utenti insolventi deve essere applicata una penale prestabilita.
E2	Gestione del contenzioso
E2.1	Il Sistema di Gestione Utenti deve essere in grado di ricevere eventuali contestazioni del pedaggio da parte dell’utente. Nota: Le contestazioni possono essere di varia natura, fra cui a titolo di esempio: • sull’importo del pedaggio; • sulla tariffa applicata; • sul percorso effettuato.
E2.2	Il Sistema di Gestione Utenti deve essere in grado di funzionare da filtro rispetto al Sistema di Pedaggio, cioè solo alcune (motivate) contestazioni dell’Utente devono essere inoltrate al Sistema di Pedaggio.
E2.3	Il Sistema di Gestione Utenti deve tenere traccia: • di tutte le contestazioni pervenute dall’utente attraverso qualsiasi canale; • del loro trattamento; • se sono state risolte o sono state inoltrate al Sistema di Pedaggio.
E2.4	Il Sistema di Gestione Utenti deve produrre periodicamente un rapporto su: • numero totale di contestazioni ricevute;

# Req.	Descrizione	Risposta
	• numero di contestazioni inoltrate al Sistema di Pedaggio; • tempo di risoluzione di una contestazione.

5.1.2.4 Interazioni con sistemi esterni

# Req.	Descrizione	Risposta
F	Interazioni con sistemi esterni
F1	Interazione con Sistema di Pedaggio
F1.1	Il Sistema di Gestione Utenti deve essere in grado di scambiare con il Sistema di Pedaggio i dati back office secondo EN ISO 12855.
F1.2	Il Sistema di Gestione Utenti deve essere in grado di utilizzare un canale di comunicazione sicuro nello scambio dati secondo EN ISO 12855 con il Sistema di Pedaggio.
F1.4	Il Sistema di Gestione Utenti deve essere in grado di ricevere dal Sistema di Pedaggio i Toll Context Data secondo il protocollo e il formato dei messaggi previsto per questo scambio da EN ISO 12855 e di inviare le risposte possibili.
F1.5	Il Sistema di Gestione Utenti deve essere in grado di ricevere dal Sistema di Pedaggio i Billing Details secondo il protocollo e il formato dei messaggi previsto per questo scambio da EN ISO 12855 e di inviare le risposte possibili.
F1.6	Il Sistema di Gestione Utenti deve essere in grado di ricevere dal Sistema di Pedaggio i Payment Claim secondo il protocollo e il formato dei messaggi previsto per questo scambio da EN ISO 12855 e di inviare le risposte possibili.
F1.7	Versamento pedaggi ad APL
F1.7.1	Il Sistema di Gestione Utenti deve versare sul c/c bancario indicato da APL i pedaggi di competenza pagati dagli Utenti.

5.1.2.5 Monitoraggio e Gestione del cartellino problemi (trouble ticketing)

# Req.	Descrizione	Risposta
G	Monitoraggio e Gestione del cartellino problemi (trouble ticketing)
G1	Monitoraggio
G1.1	La funzione di “Monitoraggio” deve informare in tempo reale l’Operatore di Sistema sullo stato corrente del Sistema di Gestione Utenti e deve generare automaticamente gli allarmi su eventuali malfunzioni.
G1.2	La funzione “Monitoraggio” deve monitorare: • tutti i Punti Servizio Utenti; • gli apparati di comunicazione; • il sistema centrale, in particolare il Portale Web e il Call Centre.
G1.2.1	La funzione di “Monitoraggio” deve monitorare le caratteristiche di disponibilità (availability) e di prestazioni (performance) di ogni funzione del Sistema di Gestione Utenti.
G1.3	L’interfaccia di accesso dell’Operatore di Sistema alle informazioni prodotte dalla funzione di Monitoraggio deve essere via browser. L’accesso deve essere regolato da diritti di accesso, definiti da APL.
G1.4	La funzione di “Monitoraggio” non deve interferire con le normali operazioni del Sistema di Gestione Utenti.
G2	Gestione del cartellino problemi (trouble ticketing)
G2.1	Il Sistema di Gestione Utenti deve avere la funzione di “Gestione del cartellino problemi” (trouble ticketing).
G2.2	La funzione di “Gestione del cartellino problemi” deve documentare ogni evento anomalo del Sistema di Gestione Utenti ed ogni attività di risoluzione problemi.
G2.3	Ogni evento od ogni azione legata alla gestione del cartellino deve essere documentata.

# Req.	Descrizione	Risposta
G2.4	APL deve avere libero accesso alla funzione di “Gestione del cartellino problemi”, comprese le funzionalità di reportistica.
G2.5	APL deve avere la possibilità di creare cartellini problemi.

5.1.3 Requisiti non funzionali

# Req.	Descrizione	Risposta
H	Requisiti non funzionali
H1	Portabilità
H1.1	Installazione e dis-installazione
H1.1.1	Il Sistema di Gestione Utenti deve avere una procedura documentata di installazione dell’intero sistema.
H1.1.2	La documentazione della procedura di installazione deve comprendere almeno: • prerequisiti d’installazione (diritti di accesso, hardware, software, strumenti, persone necessarie, durata, …); • dipendenze da altri sistemi, interfacce, applicazioni; • descrizione delle procedure automatiche e dei passi manuali dell’installazione; • punti di controllo per la verifica di correttezza dell’installazione. Ogni attività di installazione deve essere documentata appropriatamente.
H1.1.3	Ogni installazione (completa o parziale, cioè di una modifica – upgrade – o di una correzione di un errore – patch –) deve poter essere dis-installata. La procedura di dis-installazione non deve perturbare il resto dell’installazione.
H2	Affidabilità
H2.1	Salvataggio (backup) e ripristino (restore) dei dati
H2.1.1	Il Sistema di Gestione Utenti deve avere una procedura di salvataggio (backup) e di

# Req.	Descrizione	Risposta
	ripristino (restore) dei dati del sistema.
H2.1.2	Il backup deve poter essere eseguito senza perturbare le normali operazioni.
H2.1.3	L’Appaltatore dovrà eseguire periodici test di restore che forniscano l’evidenza che la funzione di restore funziona correttamente.
H2.1.4	L’Appaltatore dovrà eseguire almeno: • un backup giornaliero dei dati del Sistema di Gestione Utenti in sette generazioni • un backup settimanale e uno mensile in tre generazioni.
H2.2	Disponibilità (availability) e business continuity
H2.2.1	L’Appaltatore dovrà progettare, realizzare e mantenere una descrizione dei principi di business continuity possibilmente basata su standard e migliori pratiche. In particolare, essa dovrà descrivere come sono assicurati i Service Level Agreement in caso di eventi come caduta del sistema, perdita della connessione di comunicazione e così via.
H2.2.2	Il Sistema di Gestione Utenti deve assicurare caratteristiche di alta disponibilità in caso di disastro in accordo al livello di servizio stabilito.
H2.2.3	L’Appaltatore dovrà progettare ed eseguire test del caso di disastro.
H2.3	Up-Time del sistema centrale
H2.3.1	Il sistema centrale del Sistema di Gestione Utenti deve avere una disponibilità (availability) di almeno il 99.5 %. Nota: La indisponibilità del sistema centrale significa l’ indisponibilità sia del sistema primario che del sistema secondario.
H2.3.2	Il sistema centrale del Sistema di Gestione Utenti non deve avere un down-time continuativo di più di 6 ore.
H2.3.3	Il sistema centrale del Sistema di Gestione Utenti deve avere funzioni per la supervisione remota della sua disponibilità da parte della funzione di Monitoraggio.

# Req.	Descrizione	Risposta
	Ogni evento di non disponibilità deve essere riportato in un cartellino problemi. La funzione Monitoraggio o la funzione Gestione del cartellino problemi devono fornire un rapporto annuale di tutti gli eventi di non disponibilità del Sistema di Gestione Utenti e delle loro durate.
H2.4	Call Centre
H2.4.1	L’infrastruttura del Call Centre deve avere una disponibilità di almeno il 99.5% su base annuale (24 × 7).
H2.4.2	L’infrastruttura del Call Centre deve supportare il monitoraggio remoto da parte della funzione “Monitoraggio”. Ogni evento di non disponibilità deve generare un cartellino problemi. Le funzioni “Monitoraggio” e “Gestione del cartellino problemi” devono fornire un rapporto annuale di tutte le non disponibilità del Call Centre scoperte e della loro durata.
H2.4.3	L’infrastruttura del Call Centre non deve avere una non disponibilità per più di 2 ore continuative.
H3	Prestazioni
H3.1	Il Sistema di Gestione Utenti deve avere caratteristiche di scalabilità per adattarsi ad aumenti o decrementi progressivi o inattesi del carico di sistema (system load).
H3.2	Data Retention
H3.2.1	Nel Sistema di Gestione Utenti deve essere presente una logica di data retention.
H3.2.2	La logica di data retention deve prevedere la capacità di configurare in maniera flessibile i periodi di data retention.
H3.2.3	I dati del Sistema di Gestione Utenti devono essere cancellati o resi non più disponibili per mezzo di procedure automatiche che siano in accordo alla logica di data retention. Le attività di queste procedure automatiche (o il trattamento di ogni altro evento connesso) devono essere registrate su un log.

# Req.	Descrizione	Risposta
H3.2.4	APL deve avere la possibilità di verificare la correttezza sia della realizzazione sia del funzionamento della logica del data retention e delle sue procedure.
H4	Sicurezza
H4.1	L’Appaltatore dovrà fornire una descrizione dei principi di sicurezza (piano della sicurezza) e realizzare un sistema di gestione della sicurezza (security management system) basato su ISO 27001 e ISO 27002. Il security management system ed ogni specifica misura di sicurezza dovranno essere continuamente aggiornati allo stato dell’arte del settore. Il piano della sicurezza dovrà proteggere gli asset principali assicurando: confidenzialità, integrità, autenticità, controllo dell’accesso e disponibilità dei processi, sistemi e dati. Il piano della sicurezza si applica sia al sistema centrale sia ai sistemi presso i Punti Servizio Utenti.
H4.2	Il piano della sicurezza e il security management system dovranno coprire almeno: • valutazione del rischio di ogni asset principale; • scelta delle misure appropriate per ridurre/annullare il rischio; • gestione dei processi IT della sicurezza (come security incident management).
H4.3	L’Appaltatore dovrà adottare le migliori pratiche per la realizzazione di software sicuro. La documentazione di sviluppo del sistema dovrà comprendere una sezione che descrive le migliore pratiche che sono state realizzate (per esempio: controllo dell’input doloso – intenzionale o no – dell’utente).
H5	Architettura
H5.1	Punti Servizio Utenti
H5.1.1	L’Appaltatore dovrà fornire i sistemi necessari ai Punti Servizio Utente in due configurazioni: • configurazione massima, con:

# Req.	Descrizione	Risposta
	o personal computer; o accesso ad Internet; o stampante; o terminale per il pagamento con carta di credito/debito; o registratore di cassa; • configurazione minima, con: o accesso ad Internet.
H5.2	Infrastruttura del Call Centre
H5.2.1	L’Appaltatore dovrà fornire l’infrastruttura del Call Centre, comprensiva di hardware e software, per: • direzionare le chiamate entranti agli operatori liberi; • guidare l’Utente fra le varie opzioni mediante un IVR; • accodare le chiamate entranti in attesa di un operatore libero; • monitorare il carico di lavoro e le prestazioni degli operatori. L’infrastruttura del Call Centre deve supportare il necessario numero di postazioni di lavoro per la funzione di Help Desk.
H5.2.2	L’infrastruttura del Call Centre deve avere un sistema Interactive Voice Response (IVR) configurabile. Nota: Un IVR è una tecnologia che permette ad un computer di interagire con l’uomo recitando al chiamante informazioni preregistrate e interagendo tramite tastiera telefonica DTMF.
H5.2.3	L’infrastruttura del Call Centre deve permettere la registrazione delle chiamate, cioè la conversazione fra il chiamante e l’agente. Le chiamate registrate devono essere memorizzate in un archivio e devono poter essere esportabili in un medium esterno.
H5.2.4	L’infrastruttura del Call Centre deve avere un monitoraggio real time delle attività degli agenti di Help Desk e delle code delle chiamate entranti.